Dev meeting IS NOT a decision-making place. All decisions should be done at the bug tracker.
Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly.
Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue).
We will write a record of the discussion in the file or to each ticket in English.
All activities are best-effort (keep in mind that most of us are volunteer developers).
The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time.
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/04/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
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.
[Bug #4040] SystemStackError with Hash[*a] for Large a (jeremyevans0)
@ko1 (Koichi Sasada) fixed this issue for iseq methods accepting splats in Ruby 2.2.
We fixed this issue for cfunc methods in January.
I found this issue applies to all other method calls.
I developed a fix for all cases I could identity (yjit will need updates for it).
The fix results in a minor performance decrease in microbenchmarks.
I have attempted to offset this performance decrease with major optimizations to bmethod, send, symproc, and method_missing calls, using knowledge gained from fixing this bug.
Do we want to fix this issue, and if so, how much of a performance loss are we willing to accept?
I propose we should accept this fix if it doesn't result in more than 0.2% performance decrease in production benchmarks such as railsbench.
[Bug #19533] Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2 (jeremyevans0)
Do we want to make beginless+endless Range#include? return true for all objects?
A decision was made in August 2022 to have include? raise exception for beginless/endless ranges.
Looking back, it's possible that it was desired for the beginless^endless case and not the beginless+endless case.
[Bug #19564] Range.cover? fails for Range wrapped in SimpleDelegator (jeremyevans0)
Do we want to handle delegate objects in Range#cover??
If so, do we want to add Range#to_range and have Range#cover? check for that method and call it if it exists?