Misc #19599
closed
DevMeeting-2023-05-10 @ Matsumoto, Japan
Added by mame (Yusuke Endoh) over 1 year ago.
Updated over 1 year ago.
Description
The next dev meeting¶
**Date: 2023/05/10 14:00-17:00 @ ** (JST)
Location: M2 meeting room in Matsumoto Performing Arts Centre (Access to M2 meeting room: Please take the elevator on the left of the main entrance to the floor "M2", get off the elevator and go straight.)
Log: https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-05-10.md
See also: https://bugs.ruby-lang.org/issues/19431
- 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.
-
DO NOT discuss then on this ticket, please.
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/07. We hold a preparatory meeting to create an agenda a few days before the dev-meeting.
- 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 issues
1 (1 open — 0 closed)
- Subject changed from DevMeeting-2023-05-10 to DevMeeting-2023-05-10 @ Matsumoto, Japan
- Description updated (diff)
- Description updated (diff)
- [Feature #19610] GC.delay_promotion (peterzhu2118)
- This feature changes the GC to not immediately promote young objects referred from old objects.
- We tested on production traffic on Shopify's Storefront Renderer.
- We saw significant improvement in GC time (0.81x on average, 0.88x for p99, 0.45x for p99.9).
- [Feature #18368] Range#step semantics change for non-Numeric ranges (zverok)
- Implementation is provided, but no movement is seen in months. Can we agree (or provide the adjustments) on the final spec and the implementation?
- [Bug #19616] Remove ext/readline from Ruby 3.3
- [Misc #19608] Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode
- I'm +1 to this proposal. Does anyone have objection?
- [Feature #19572] Add a new TracePoint event for rescued exceptions (st0012)
- I want to add a new
rescue
event type to TracePoint
.
- When the event is triggered,
TracePoint#rescued_exception
can be used to access the exception.
- It will be helpful for building debugging tools and can enhance
ruby/debug
's tracer too.
[Misc #19608] Being a co-maintainer of the ruby/openssl for the OpenSSL FIPS mode
I'm +1 to this proposal. Does anyone have objection?
Thanks for adding the agenda! Note I opened the issue ticket. And I plan to attend this meeting to explain the topic's context in a later timing of the meeting, as I live in a different time zone, Czech Republic.
- [Feature #18885] End of boot advisory API (byroot)
- I'm planning to merge the first optimizations for 3.3
- Are we still good with the
Process.warmup
name? Or would we rather expose something on GC
?
- [Feature #19236] Allow to create hashes with a specific capacity from Ruby (byroot)
- We exposed this capability in the C API in 3.2, but never agreed on a similar API on the Ruby side.
- The logical API would be
Hash.new(capacity: 1000)
but there are some backward compatibility concerns.
-
Hash.create(capacity: 1000)
was proposed as well.
- [Feature #19435] Expose counts for each GC reason in GC.stat (byroot)
- Seems there was some concern about bloating
GC.stat
- This data would be very useful for instrumenting GC performances cheaply.
- [Misc #18248] Add Feature Triaging Guide (jeremyevans0)
- Last discussed during October 2021 developer meeting, no decision made at the time.
- I think it would be useful to triage features, so that features in the issue tracker are things we would actually want.
- [Bug #595] Fiber ignores ensure clause (jeremyevans0)
- Last discussed back in 2018.
- It appears agreed that doing this automatically (when the fiber/thread is GCed) is a bad idea.
- Do we want to add Fiber#kill to allow for explicit fiber kills (including going through each ensure block)?
- How should we handle fiber yield/transfer inside ensure blocks in that case?
I would like to talk a little bit about Ruby Governance and what improvements we can make to how it is communicated to the public.
- [Feature #19633] Allow passing block to
Kernel#autoload
as alternative to second filename
argument`
- Something like this would remove the need for Zeitwerk to monkeypatch
Kernel#require
- Connects autoloads directly to any callbacks on them, rather than having the connection be implicit via
require
. I think this is an improvement.
- I am implementing autoloads on anonymous modules via a similar monkeypatch; this would make that monkeypatch unnecessary and simplify other logic via the block's closure.
- Status changed from Open to Closed
Is a log going to be posted?
- Description updated (diff)
Also available in: Atom
PDF
Like1
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like2Like0Like0Like1Like1