Misc #19599


DevMeeting-2023-05-10 @ Matsumoto, Japan

Added by mame (Yusuke Endoh) about 1 year ago. Updated 12 months ago.



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.)
See also:

  • 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.)


* [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 open0 closed)

Related to Ruby master - Misc #14770: [META] DevelopersMeetingOpenActions
Actions #1

Updated by mame (Yusuke Endoh) about 1 year ago

  • Related to Misc #14770: [META] DevelopersMeeting added
Actions #2

Updated by mame (Yusuke Endoh) about 1 year ago

  • Subject changed from DevMeeting-2023-05-10 to DevMeeting-2023-05-10 @ Matsumoto, Japan
  • Description updated (diff)
Actions #3

Updated by mame (Yusuke Endoh) about 1 year ago

  • Description updated (diff)

Updated by peterzhu2118 (Peter Zhu) about 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) about 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) about 1 year ago

  • [Bug #19616] Remove ext/readline from Ruby 3.3
    • Any opinion about this?
  • [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?

Updated by st0012 (Stan Lo) about 1 year ago

  • [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.

Updated by jaruga (Jun Aruga) about 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) about 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 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 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.

Updated by Eregon (Benoit Daloze) about 1 year ago

[EDIT] Jemma Issrof will talk about YARP ( at the meeting.

Updated by jeremyevans0 (Jeremy Evans) about 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) about 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) about 1 year ago

  • [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.
Actions #15

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) 12 months ago

  • Description updated (diff)

Is a log going to be posted?

I've just posted it at


Also available in: Atom PDF