Misc #20436
open
DevMeeting at RubyKaigi 2024
Added by ko1 (Koichi Sasada) 29 days ago.
Updated 4 days ago.
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
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.
- Related to Misc #20287: DevMeeting before or after RubyKaigi added
- [Feature #6648] Provide a standard API for retrieving all command-line flags passed to Ruby (eregon)
-
[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.
- [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.
- [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?
- [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.
- [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?
- [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.
- [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.
- [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?
- [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?
- [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.
- [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?
I asked Matz and here is a reordered agenda: https://hackmd.io/CoLraFp_QrqyHBcv3g8bVg?both
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.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0