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 2024/03/11. 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.
[Feature #20275] Avoid extra backtrace entries for rescue and ensure (eregon)
OK to hide/avoid the extra backtrace entries?
I think it helps to avoid confusion (there is no call semantically for a rescue or ensure section). e.g. ["-:4:in '<main>'", "-:4:in '<main>'"] seems unclear (it looks like a recursive call of <main>)
Doing so would make it consistent with other Ruby implementations.
Note: The next meeting will be held not only at P.M. but also at A.M. (09:00-12:00) in JST. We will try this time slot once for those who want to attend from the U.S. (It has not been decided if this slot will be permanent, though.)
[Feature #20265] Deprecate and remove rb_newobj and rb_newobj_of (peterzhu2118)
These two APIs are difficult to use, fragile to use, and requires internal knowledge of internal implementation of data types in Ruby.
The rb_newobj function creates a T_NONE object. T_NONE objects cannot be marked and are not reclaimed by the GC, which can leak memory.
The rb_newobj_of function requires the developer to understand flags of objects. Many flags for objects are also not public, preventing direct use by developers.
Very few C extensions use these APIs, and are from over a decade ago.
If this is approved, should the ivar name match the method named exactly? For example, should it behave like def foo = (@foo ||= :value) or should we use special naming conventions like def foo = (@_foo ||= :value)?
[Bug #20090] Anonymous arguments are now syntax errors in unambiguous cases
I'm not sure this is the best place to ask, but can we release 3.3.1? There are a couple of bugs that have been holding me back from updating to 3.3 in some projects. In particular, this one (#20090). It even affects Rubocop.
I think this is better than passing an Array of String because with strings Exception#backtrace_locations returns nil, making backtrace_locations unreliable.
However, this is only called for the current execution context (i.e. the thread/fiber which is performing the GC work). Machine stacks for other threads & fibers are not yet marked in this way.
I propose to unify all the machine stack marking for all kinds of machine stacks into a single function in gc.c, rb_gc_mark_machine_context. PR for this is here: https://github.com/ruby/ruby/pull/10122. All machine-stack marking for all fibers/threads flows through the same code path with this PR.
Alternative approach would be to write a helper for marking ASAN fake stack values, and call it from various places in cont.c and vm.c.
I would like a decision on whether the refactoring of machine stack marking into a single function is worthwhile, or whether it's too ASAN specific and I should just add ASAN-related code to each place we do machine stack marking currently.
(sorry, this is my first dev meeting agenda item, so apologies if this is not the kind of thing discussed in dev meetings!)
I would like to propose that we use prism for mk_builtin_loader.rb.
There are lots of different thoughts on the issue — using bundler/using the Ruby library/using the C library. I would like to get a direction/understanding of what to do.