Misc #19599
closedDevMeeting-2023-05-10 @ Matsumoto, Japan
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.
Updated by mame (Yusuke Endoh) over 1 year ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by mame (Yusuke Endoh) over 1 year ago
- Subject changed from DevMeeting-2023-05-10 to DevMeeting-2023-05-10 @ Matsumoto, Japan
- Description updated (diff)
Updated by peterzhu2118 (Peter Zhu) over 1 year ago
- [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).
Updated by zverok (Victor Shepelev) over 1 year ago
- [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?
Updated by hsbt (Hiroshi SHIBATA) over 1 year ago
Updated by st0012 (Stan Lo) over 1 year ago
- [Feature #19572] Add a new TracePoint event for rescued exceptions (st0012)
- I want to add a new
rescue
event type toTracePoint
. - 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.
- I want to add a new
Updated by jaruga (Jun Aruga) over 1 year ago
[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.
Updated by byroot (Jean Boussier) over 1 year ago
- [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 onGC
?
- [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.
- Seems there was some concern about bloating
Updated by yui-knk (Kaneko Yuichiro) over 1 year ago
I want to introduce my parser project including https://github.com/yui-knk/lrama and https://rubykaigi.org/2023/presentations/spikeolaf.html#may11.
Updated by Eregon (Benoit Daloze) over 1 year ago
[EDIT] Jemma Issrof will talk about YARP (https://github.com/Shopify/yarp) at the meeting.
Updated by jeremyevans0 (Jeremy Evans) over 1 year ago
- [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?
Updated by ufuk (Ufuk Kayserilioglu) over 1 year ago
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.
Updated by shioyama (Chris Salzberg) over 1 year ago
- [Feature #19633] Allow passing block to
Kernel#autoload
as alternative to secondfilename
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.
- Something like this would remove the need for Zeitwerk to monkeypatch
Updated by hsbt (Hiroshi SHIBATA) about 1 year ago
- Status changed from Open to Closed
Updated by Dan0042 (Daniel DeLorme) about 1 year ago
Is a log going to be posted?
Updated by k0kubun (Takashi Kokubun) about 1 year ago
- Description updated (diff)
Is a log going to be posted?
I've just posted it at https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-05-10.md.