Matsuyama Is Nice!

Ruby Taught Me About Encoding Under the Hood

This is my RubyKaigi keynote presentation. Thank you!https://t.co/Ld7X6QNyMf
— ima1zumi (@ima1zumi) 2025年4月16日

深掘りは楽しい！というのがすべてを表してるなと思った。むしろ、こういう深堀りの塊みたいな発表で殴られるのが快感になってるから、毎年 RubyKaigi に自腹 & 1w 有給取得してまで来てるのはある。

「セマフォが本来の方で出てくるんだ」というみんなのポストで笑った。
「糸柳さん」というワードが聞けて良かった。

Bringing Linux pidfd to Ruby

Just published my #RubyKaigi 2025 presentation slides on "Bringing Linux pidfd to Ruby" - exploring how to solve process race conditions and PID reuse security issues with modern Linux APIs 🔒

Check it out: https://t.co/DD3ntgztDH #ruby #linux pic.twitter.com/ES1rFsCI5n
— Maciej Mensfeld (@maciejmensfeld) 2025年4月23日

pidfd は PID が再利用による問題などを解消できるものらしい。

たしかに便利だけど Linux API である & overkill という面もあるよとのこと。

The Evolution of the CRuby Build System

The Evolution of the CRuby Build System https://t.co/LUV7C7PvYV #rubykaigi
— Yuta Saito (@kateinoigakukun) 2025年4月16日

CRuby 自体をビルドするのに時間がかかる & ルールファイルが autotools (主にm4) でカオスなので何とかしたいという話で、主に C 言語層を触ってるコミッタやコントリビュータがターゲットになるため、母数が少ないと思ってたのに、なんかけっこう人が入ってた。

もしかして、ビルドシステムの話ということで extension とかの話だと思って聴きに来た → 思ってたのと違ったという人が多かったんじゃないかと思ってる。

tarball と git source は違うよという話は本当にそうで CI で git source はチェックしてるけど、tarball はチェックしてないので tarball だけで問題が発生するというはある。実際に 3.4.1 では tarball だけで問題が発生していた。

bugs.ruby-lang.org

tracemake というのを自作されて、いろいろ調べられたっぽいので、この gem はあとで通読したい。

github.com

configure.ac とか tools/m4 を一番触っているコミッタは誰かわかりますか？→ 誰かが速攻で「中田さん」とシャウトしてたけど、自分も同じタイミングで中田さんと確信してた。

個人的にはすごい面白そう & 野良で cygwin 環境でビルド & テストの CI を回してるコントリビュータとして、ビルドの時間を短くしたい要望はあるため、協力したいなと思ってる。

parser gangs に対抗して build gangs とかを立ち上げられませんかね？

Lunch

鯛めし & じゃこ天 & みかんジュース

アンドパッドは Drinks スポンサーとして #rubykaigi 期間中、みかんジュース蛇口を提供します！
本日 12:00 からスタートです！ pic.twitter.com/FkSIbbYKBP
— ANDPAD (アンドパッド)開発部 (@andpad_dev) 2025年4月16日

Goodbye fat gem 2025

14:00からのGoodbye fat gem 2025の資料だよ！ #rabbit #rubykaigi #rubykaigiC https://t.co/ANpeqDsNqP
— す (@ktou) 2025年4月16日

自分はビルドできる場合は手元でビルドするのが当たり前だと思ってる過激派の (というか古い人間なので、プリビルドされたバイナリが手元できちんと動くという信用をあまりしていない) ため、fat gem を使ったことが実はない。

デプロイ先にビルド環境を入れたくないというのはわかる。というか当然の気持ち。
御本人は「gemの開発は大変ですねーに共感して！という話ではない」とコメントされていたが、やはりメンテナがけっこうなコストを払っているということは知っておいてもらいたいとは感じる。*1
rubygems-requirements-system も面白そうな gem なのであとで読む。

github.com

SDB: Efficient Ruby Stack Scanning Without the GVL

SDB: Efficient Ruby Stack Scanning Without the GVL#rubykaigi https://t.co/druNSSIWOm
— Mike Yang (@yfractal) 2025年4月17日

github.com

圧

サインする人がさらに増えてて、圧がすごいことになってる。 https://t.co/NoR5984Uee
— いけむらさん (@fd0) 2025年4月16日

写ってはいないですが、写真の右奥に行けば行くほど、圧が強くなっていってました。

State of Namespace

今年の #rubykaigi でのtalkです
State of Namespace - Speaker Deckhttps://t.co/gfaVN0nwzA
— tagomoris (@tagomoris) 2025年4月17日

前回の発表以降、ひたすらデバッグされてたということでやはり大変な新機能になりそうというのを感じた。
make exam は知らなかったので手元の cygwin ビルドで試してみたら、案の定途中でハングした。
元々グローバルに 1 つしか存在することを想定していなかったクラス情報を複数存在できるようにするには、やはりデータ構造の大規模な改修が必要で、そこらへんの話を聴けたのがとても良かった。
so も namespace 毎にロードしないといけないため、コピーして prefix をつけるという話だったが、cygwin だと rebase してない so をロードすると動作が保証されない可能性があるため、デフォルトで有効になったら cygwin プラットフォームだとどうするべきか？とか聴きながら考えてた。