Misc #21100: DevMeeting before RubyKaigi 2025

• Status: Open
• Assignee: -

[ko1 (Koichi Sasada)]

RubyKaigi 2025 will be at Matsuyama, Japan, Apr 16th - 18th.
We would like to try to hold a face-to-face dev meeting at Matsuyama. (@matz (Yukihiro Matsumoto) will also participate!)

• Date: 2025/04/15 (Tue.) 16:00-19:00 (The day before RubyKaigi)
• Location: Ehime Prefectural Convention Hall (same as RubyKaigi 2025 venue) 3F 8th meeting room

How to participate

Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss.
Please sign up on the doorkeeper page:
https://rubyassociation.doorkeeper.jp/events/181721

The meeting will be held in a hackathon event.
Please enjoy Ruby hacking with friends if you want before the meeting.

Note: Do not forget to register RubyKaigi ticket too (see "[ruby-core:120816] Invitation to RubyKaigi 2025" from Akira).

Program

• 10:00am door open and start the Hackathon event
• 3:00pm(?) Matz will arrive
• 4:00pm opening and self introduction
• 4:30pm discuss topics
• 6:00pm closing and free time (closing time is depends on topics)
• 7:00pm door close

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 2025/04/10. I'll ask Matz which should be discussed on this meeting and reorder them.
• 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.

[ko1 (Koichi Sasada)]

• Subject changed from DevMeeting before or after RubyKaigi2025 to DevMeeting before RubyKaigi2025
• Description updated (diff)

Venue changed!!

Thank you for RubyKaigi organizers, they offer us the great meeting room at the same venue of RubyKaigi 2025! (Ehime Prefectural Convention Hall)

[sorah (Sorah Fukumori)]

• Subject changed from DevMeeting before RubyKaigi2025 to DevMeeting before RubyKaigi 2025

[mame (Yusuke Endoh)]

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

[jeremyevans0 (Jeremy Evans)]

• [Feature #21216] Implement Set as a core class (jeremyevans0)
  • I propose to implement Set as a core class.
  • I have a pull request that adds a value-less st_table (named set_table), for a 33% memory savings.
  • Core Set speeds up the majority of Set methods, with 47% of benchmarked cases being at least twice as fast.
  • Open questions are:
    • How to expose this in the C-API.
    • Whether to share types with st.c (currently, all types are renamed from st_* to set_*).
    • Where the code should live (potentially st.c if types are shared).
    • Where to use this internally (potentially, fstring table and proposed refinement call cache).

[maximecb (Maxime Chevalier-Boisvert)]

• [Feature #21221] Proposal to upstream ZJIT
  • The YJIT team has been working on ZJIT, a more advanced Ruby JIT
  • We aim for this JIT to be in a usable state in time for 3.5
  • We would like to discuss upstreaming it after RubyKaigi to make development easier

[tenderlovemaking (Aaron Patterson)]

• [Feature #21254] Inline YARV instructions for Class#new
  • Patch inlines YARV instructions for calls to new
  • Allocation performance is very good (24% faster, at minimum but reaches 3x depending on parameters)
  • Memory usage increases but not significantly
  • caller changes inside initialize

[byroot (Jean Boussier)]

• [Feature #21219] Object#inspect accept a list of instance variables to display (byroot)
  • Redefining #inspect can be important to avoid secret leak or to avoid very large inspect representations
  • Right now implementing a custom #inspect isn't as simple as it seems (e.g. circular references, object_id, etc)
  • Should we make it easy to keep the default #inspect but hide some instance variables?

[ko1 (Koichi Sasada)]

• [Feature #21262] Proposal: Ractor::Port (ko1)
  • Considering with Channel, Port concept seems better for me.
  • I found that take/yield is so difficult to implement correctly and efficiently enough to support Ractor.select in 4 years, so I'm voting to remove them.

[ko1 (Koichi Sasada)]

I'd like to go through the discussion in the order written in this HackMD (with Matz's approval).

https://hackmd.io/nHt6KYE8RmOcp_gcO344lw

See you in Matsuyama city!