Misc #20436


DevMeeting at RubyKaigi 2024

Added by ko1 (Koichi Sasada) about 2 months ago. Updated 10 days ago.



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


  • 1:45pm door open
  • 2:00pm opening and self introduction
  • 2:30pm discuss topics
  • 5:00pm closing and free time (closing time is depends on topics)
  • 5:50pm door close

There are several RubyKaigi related events after that so let's continue on the party:

How to participate

Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss.
Please write your name on this spreadsheet to count the number of participants.

Call for agenda items

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.)


* [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.
  • The format is strict. We'll use this script to automatically create an markdown-style agenda. We may ignore a comment that does not follow the format.
  • 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.

Related issues 2 (1 open1 closed)

Related to Ruby master - Misc #20287: DevMeeting before or after RubyKaigiClosedActions
Related to Ruby master - Misc #14770: [META] DevelopersMeetingOpenActions
Actions #1

Updated by ko1 (Koichi Sasada) about 2 months ago

  • Related to Misc #20287: DevMeeting before or after RubyKaigi added
Actions #2

Updated by hsbt (Hiroshi SHIBATA) about 2 months ago

  • Related to Misc #14770: [META] DevelopersMeeting added

Updated by Eregon (Benoit Daloze) about 2 months ago

Updated by andrykonchin (Andrew Konchin) about 2 months ago · Edited

  • [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.
  • [Bug #20416] IO#read doesn't preserve buffer encoding if maxlen = nil (andrykonchin)

    • 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 ( but it's unclear what option is the best one.

Updated by kddnewton (Kevin Newton) about 2 months ago

  • [Misc #20434] Deprecate encoding-related regular expression modifiers (kddnewton)
    • The relationship between regexp encoding, file encoding, string encoding, and matchee encoding is very confusing.
    • A migration path is proposed in the ticket.

Updated by tenderlovemaking (Aaron Patterson) about 2 months ago

  • [Feature #20425] Optimize forwarding callers and callees
    • Introduces optimization to avoid allocations regarding ... callers and callees
    • Stack size for a method like def foo(...) depends on the caller (foo(1,2) has different stack size than foo(1))
    • Ko1 is worried about complex code and incompatibilities because of stack size and offered a different solution
    • Aaron thinks Ko1's solution is of similar complexity but moves complexity to GC
    • Can we try the current solution and refactor / revert if there are incompatibilities?

Updated by eightbitraptor (Matthew Valentine-House) about 2 months ago

  • [Feature #20443] Allow Major GC's to be disabled
    • Introduces the ability to "turn off" Major GC's, so that only minors will run. This is useful for applications that are using Out-of-band GC.
    • Discussion has focussed around the method names, can we make a decision about what the interface should be? Options proposed are:
      • New methods, eg. GC#disable_major, GC#enable_major, GC#need_major?, GC#disable_major_gc etc.
      • Keyword Args, eg. GC#disable(type: major)
    • @eightbitraptor (Matthew Valentine-House) and @byroot (Jean Boussier) prefer new methods that will respond_to?, and are able to be undefined.

Updated by Eregon (Benoit Daloze) about 2 months ago · Edited

  • [Bug #20455] rb_errinfo() inconsistent with $! in the caller Ruby code (eregon)
    • Could we make them consistent? Or completely separate?
    • If not, what is the current semantics (in English) and is it something we want to keep?

Updated by peterzhu2118 (Peter Zhu) about 1 month ago

  • [Feature #20470] Extract Ruby's Garbage Collector (peterzhu2118)
    • Splits GC into two files gc.c and gc_impl.c.
    • gc.c only contains code not specific to Ruby GC.
    • 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.

Updated by byroot (Jean Boussier) about 1 month ago

  • [Feature #20415] Precompute literal String hash code during compilation (byroot / etienne)
    • Simple optimization that closes most of the performance gap between symbol indexed hashes and string indexed ones for string literals.
    • Multiple ways it could be implemented, either can be done for all string literals or just the ones that have enough free space.

Updated by nobu (Nobuyoshi Nakada) about 1 month ago · Edited

  • [Feature #20437] Could be the licensing conditions be made less ambiguous?
  • [Bug #20438][Bug #20439] String format "%\n" and "%\0" does not raise format error
    • "%\n" has been treated as "%%" since commit:554b989ba162 , probably Tue Aug 6 01:12:32 1996 according to the commit log.
  • [Feature #20460] Ripper eval option
  • [Bug #20468] Segfault on safe navigation in for target
    • Also constants are valid?

Updated by ufuk (Ufuk Kayserilioglu) about 1 month ago

  • [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?

Updated by kddnewton (Kevin Newton) about 1 month ago

  • [Misc #20238] Use prism for mk_builtin_loader.rb
    • This was discussed at a previous dev meeting, but not everyone was present, so I would like to discuss it again.
  • [Bug #20401] Duplicated when clause warning line number
    • Is it okay to change the warning message? The current phrasing is confusing.

Updated by tenderlovemaking (Aaron Patterson) about 1 month ago

  • [Bug #20424] ZLib::GZipReader always double allocates strings when passed outbuf, significantly increasing memory usage
    • Lots of discussion on the GitHub PR here
    • What do we need to do to get it merged?

Updated by ko1 (Koichi Sasada) about 1 month ago

I asked Matz and here is a reordered agenda:

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.

Actions #16

Updated by hsbt (Hiroshi SHIBATA) 10 days ago

  • Status changed from Open to Closed

Also available in: Atom PDF