Misc #20436
openDevMeeting at RubyKaigi 2024
Description
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:
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.
Updated by ko1 (Koichi Sasada) 14 days ago
- Related to Misc #20287: DevMeeting before or after RubyKaigi added
Updated by hsbt (Hiroshi SHIBATA) 14 days ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by Eregon (Benoit Daloze) 13 days ago
- [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.
Updated by andrykonchin (Andrew Konchin) 13 days 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 hasUS-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 haveEUC-JP
encoding but actually hasUS-ASCII
.
- It isn't clear enough how a Regexp encoding (what
-
[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.
- It isn't clear enough how a Regexp encoding (that Regexp#encoding method returns) is calculated in case an encoding modifier (e.g.
-
[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 andoffset
out of scope should clear the$~
global variable. - But
String#index
andString#byteindex
don't clear$~
whenoffset
> size, only whenoffset
<-size
.
- It seems
-
[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 themaxlen
argument isnil
.
-
-
[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.
- When an object becomes frozen (with
Updated by kddnewton (Kevin Newton) 13 days 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) 10 days 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 thanfoo(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?
- Introduces optimization to avoid allocations regarding
Updated by eightbitraptor (Matthew Valentine-House) 7 days 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)
- New methods, eg.
- @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) 6 days 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?