RubyKaigi 2024 will be at Okinawa, Japan, May 15th - 17th. We would like to try to hold a face-to-face dev meeting at Okinawa. (@matz (Yukihiro Matsumoto) will also participate!)
Date: 2023/05/14 (Tue.) 14:00-18:00 (The day before RubyKaigi)
Location: SAKURA innobase Okinawa, Haseko Naha Building 1F, 1-2-13 Matsuyama, Naha City, Okinawa
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 2023/05/10. I'll ask Matz which should be discussed on this meeting and reorder them.
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.
[Misc #20406] Question about Regexp encoding negotiation (andrykonchin)
It isn't clear enough how a Regexp encoding (what Regexp#encoding method returns) is calculated in case an encoding modifier (e.g. u, e, etc) is specified.
The documentation states that a Regexp with only US-ASCII characters has US-ASCII encoding, otherwise a regular expression is assumed to use the source encoding. This can be overridden with encoding modifiers.
But these rules seem don't work in the following example: /#{} a/e - it's supposed to have EUC-JP encoding but actually has US-ASCII.
[Misc #20407] Question about applying encoding modifier to an interpolated Regexp (andrykonchin)
It isn't clear enough how a Regexp encoding (that Regexp#encoding method returns) is calculated in case an encoding modifier (e.g. u, e, etc) is specified to a Regexp with interpolation (e.g. /a #{ "b".encode("windows-1251") } c/e).
The encoding modifier might be applied in some cases and might be not in other ones what seems confusing at first glance.
It seems result depends on a source encoding, characters of the Regexp literal fragments and encoding of Regexp interpolated fragments as well.
[Bug #20421] String#index and String#byteindex don't clear $~ when offset > size (or bytesize) (andrykonchin)
It seems String#{index,rindex,byteindex,byterindex} methods when called with Regexp argument and offset out of scope should clear the $~ global variable.
But String#index and String#byteindex don't clear $~ when offset > size, only when offset < -size.
IO#read and similar methods when called with buffer argument preserve its encoding.
But IO#read doesn't do so in case the maxlen argument is nil.
[Bug #20319] Singleton class is being frozen lazily in some cases (andrykonchin)
When an object becomes frozen (with #freeze method call) only its own singleton class becomes frozen immediately.
Classes in the singleton classes chain become frozen only when they are returned to user with #singleton_class method call.
The object's singleton class' singleton class (and so on) doesn't become frozen even if it was already instantiated
This lazy freezing can be observed by a user when he gets a singleton class of the object's singleton class before freezing the object. After freezing the object the instantiated singleton class is still not frozen.
There might be several options (1) don't change anything, 2) freeze all the instantiated singleton classes in a chain immediately or 3) don't freeze singleton classes in a chain at all and stop freezing even an object's singleton class) and there is a PR with fix (https://github.com/ruby/ruby/pull/10245) but it's unclear what option is the best one.
gc_impl.c contains the implementation of Ruby's GC.
gc_impl.c only uses public APIs in Ruby and a limited set of functions exposed in gc.c. This allows us to build gc_impl.c independently of Ruby and plug Ruby's GC into itself.
[Misc #20432] Proposal for workflow changes related to teeny releases (ufuk)
Can we discuss the proposals to make branch maintainers' lives easier, so that we can target 6-7 teeny releases per stable version per year?
[Feature #19979] Allow methods to declare that they don't accept a block via &nil(ufuk)
I realize [Feature #15554] "warn/error passing a block to a method which never use a block" is going in the right direction.
Can we at least get runtime introspection for methods that should not be accepting a block? Something like: method(:foo).parameters #=> [:noblock] maybe?
Many topics so we can't discuss all of them. The purpose of this meeting is knowing each other. Please discuss detailed topics with the people involved during free time.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by