Dev meeting IS NOT a decision-making place. All decisions should be done at the bug tracker.
Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly.
Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue).
We will write a record of the discussion in the file or to each ticket in English.
All activities are best-effort (keep in mind that most of us are volunteer developers).
The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time.
If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format:
* [Ticket ref] Ticket title (your name)
* Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.)
Example:
* [Feature #14609] `Kernel#p` without args shows the receiver (ko1)
* I feel this feature is very useful and some people say :+1: so let discuss this feature.
It is recommended to add a comment by 2024/07/08. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion.
[Bug #20606] Thread#thread_variable_get and Thread#thread_variable? don't raise TypeError exception for incorrect argument value when thread-local variable storage is not initialised yet
These methods raise is not a symbol nor a string (TypeError) when called with a key that is not a String or a Symbol only when there are some thread local variables already assigned for a thread. And don't raise any exception (and return nil or false correspondingly) if there is no any variable assigned yet.
Is it expected behaviour? If not - is it OK to fix this issue (and validate the argument value before checking whether a storage is initialised) in the next Ruby release (3.4)? Or a deprecation warning should be added instead in 3.4 to have the issue fixed later?
[Feature #20594] A new String method to append bytes while preserving encoding (byroot)
When working with binary (messagepack, protobuf) or mixed encoding protocols (Redis, Memcached, etc), it's common to assemble string with different encodings.
Typical example is to have a BINARY buffer and assemble some UTF-8 strings in it.
In such cases Encoding::ASCII_8BIT is very inconvenient as it will do encoding negociation.
I propose a String#byteconcat method that appends string content while preserving the left hand side encoding.
The logical signature would be to behave like String#concat (take varg args, accept String or Integer, return self)
YJIT team is concerned about the performance implication of varargs, and would prefer a single argument.