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) 12 months ago
- Related to Misc #14770: [META] DevelopersMeeting added
Updated by mame (Yusuke Endoh) 12 months ago
- Subject changed from DevMeeting-2023-05-10 to DevMeeting-2023-05-10 @ Matsumoto, Japan
- Description updated (diff)
Updated by peterzhu2118 (Peter Zhu) 11 months 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) 11 months 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) 11 months ago
Updated by st0012 (Stan Lo) 11 months 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) 11 months 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) 11 months 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) 11 months 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) 11 months ago
[EDIT] Jemma Issrof will talk about YARP (https://github.com/Shopify/yarp) at the meeting.
Updated by jeremyevans0 (Jeremy Evans) 11 months 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) 11 months 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) 11 months 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) 10 months ago
- Status changed from Open to Closed
Updated by Dan0042 (Daniel DeLorme) 10 months ago
Is a log going to be posted?
Updated by k0kubun (Takashi Kokubun) 9 months 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.