Misc #20436
closed
DevMeeting at RubyKaigi 2024
Added by ko1 (Koichi Sasada) 7 months ago.
Updated 6 months 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 (Matt V-H) 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.
- Status changed from Open to Closed
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0