Misc #20436: DevMeeting at RubyKaigi 2024

• Status: Open
• Assignee: -

[ko1 (Koichi Sasada)]

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
  • Near by RubyKaigi venue (not a RubyKaigi venue).
  • Japanese page: https://www.sakura.ad.jp/innobase/

Program

• 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:

• RubyKaigi 2024 前夜祭 Asakusa.rb Welcome Drinkup - connpass

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.
https://docs.google.com/spreadsheets/d/1qXuvXvigP80CFNwseJDKm2YNkpQmzSg9WSI1pJsh5ZI/edit?usp=sharing

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

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

[ko1 (Koichi Sasada)]

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

[hsbt (Hiroshi SHIBATA)]

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

[Eregon (Benoit Daloze)]

• [Feature #6648] Provide a standard API for retrieving all command-line flags passed to Ruby (eregon)
  • @Dan0042 (Daniel DeLorme) made a clear proposal in https://bugs.ruby-lang.org/issues/6648#note-10 can we accept it?
  • This has been needed for a while and there are 3 real use cases presented on the ticket.

[andrykonchin (Andrew Konchin)]

• [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 (https://github.com/ruby/ruby/pull/10245) but it's unclear what option is the best one.

[kddnewton (Kevin Newton)]

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

[tenderlovemaking (Aaron Patterson)]

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

[eightbitraptor (Matthew Valentine-House)]

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

[Eregon (Benoit Daloze)]

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