komagataのブログ

RubyのParser周りの動きを追っかけた - komagataのブログ

parse.yは大幅に変えずにbisonをlramaに切り替えられたってこと？

ちょっと前になっちゃうのですが、STORES Tech Conf 2024に参加しました。

席についた時、たまたま隣がkanako.yさんで、「あ、隣kanakoさんだ」と思ってたんですが、

見ていた発表が終わってkanekoさんが、

「(lramaは)parse.y、bisonと互換性あるので読めますよ」

と言って立ち去りました😆

疑問点が作者本人によって解決するとは思いませんでした。

しっかし、その方法ってparse.yが変わらないわけだから、マルっと変えちゃうよりもこれまでrubyを開発してる人大満足の方法だなと思いますが、僕にとっては、

「理屈はわかるけど現実的に可能ものなの？」ってレベルの難しさ・大変さな感じでびっくりです。凄すぎ。

prismは"A new compiler for CRuby 3.3+"と書いてあるけど、YJITと競合するってこと？ https://speakerdeck.com/kddnewton/why-prism?slide=32

こちらの方はアフターパーティーで@joker1007さんに教えてもらいました。

prismはデータ構造を変えてるので、その部分をVMへのバイトコードにコンパイルする部分は自前で用意する必要がある（用意してる）のでその辺りのことを示してるそうです。

お二人に感謝です。やっぱりイベント行くとお得なことがありますね〜。

先日、福岡Rubyist会議04に行って @yui-knkさんや@kddnewtonさんのParserの話を聞きました。

僕はRubyKaigi2023は松本まで行ったものの中耳炎で発熱してずっとホテルでダウンし、RubyKaigi2024はギックリ腰で中途半端にしか参加できませんでした。つまり一連のParserの話に完全に乗り遅れてしまっていました。

これまでのRubyKaigiの動画やブログエントリーなどを見て追っかけて見ました。ruby内部や言語実装について詳しくないので理解が間違ってるかもなのと、いくつか疑問点が出てきたのでXなどでご指摘いただければありがたいです。

現状の理解

rubyのparserには下記の問題がある。

• メンテナンス性
• エラー許容性
• 処理系ごとにparserが別

これらを解決する手始めとして@yui-knkさんが既存のbisonを置き換えるlramaを作った。 @kddnewtonさんとshopfyはprism(旧yarp)を作った。

ruby3.3でbisonがlramaに置き換わった。prismはdefault gemになった。

疑問点

prismは"A new compiler for CRuby 3.3+"と書いてあるけど、YJITと競合するってこと？
https://speakerdeck.com/kddnewton/why-prism?slide=32

prismは「3.3ではオプション、3.4プレビューではデフォルト」って書いてあるけど、これはparserの話？compilerとしての話？
https://speakerdeck.com/kddnewton/why-prism?slide=100

parse.yは大幅に変えずにbisonをlramaに切り替えられたってこと？

追記：いろいろ解決しました Parser周りの疑問が少し解決 - komagataのブログ

車を修理に出していて、代車のダイハツのタントで@machidaとのお台場ランチに行った帰り道。

首都高から永福ICで20号に下りてすぐの辺りでボンネットから煙が出てきてガッタンガッタンいったあと、車が全く動かなくなった。ボロいボロいとは思っていたけど止まるほどとは。クッソ暑い昼間だったのでエンジンにも厳しかったんでしょうな。

妻が110番して警察がすぐに駆けつけた。

安全な場所まで車を押してくれる警察の方々。

消防も駆けつけてなんだかえらいことになった。

レッカーを呼んで車屋さんまで行って新しい代車の日産マーチを借りて帰りました。

車屋さんの

「代車はマーチでいいですか？あ、もうウチの車乗りたくないですかね？（笑）」

という自虐ジョークに苦笑い。

早く慣れた自分の車に帰ってきて欲しいです😭

7月1日にFBC（フィヨルドブートキャンプ）でフロントエンドエンジニアコースをオープンしました。

既存のRailsエンジニアコースではTypeScriptをやらないし、ReactやNextをがっちりやるコースとして作りました。

また、Railsエンジニアコースでは実質バックエンド・フロントエンドやってインフラもちょっとみたいなフルスタックコースになっているので必要な技術が多くて、卒業までの時間が2年とかかかる方もいたりと長過ぎになってたのでフロントエンドエンジニアコースではフロントエンドだけでバックエンドやインフラは意識的に入れませんでした。

このあと、Railsエンジニアコースの方はフロントエンド関連はHotwireにしちゃってReactからStimulusに変える予定。これができれば役割分けがすっきりして両方とも卒業までの期間を圧縮できそう。

あとは、生徒の方がコードの問題をたくさん解くことができるように、ブラウザ上で競プロみたいに問題を出す機能を作っています。Rubyの方はwasmでJSはそのまま実行。競プロだと実行時間や不正対策が難しそうですが、スクールの練習問題としてはそこまで厳密でなくていいので使えそうです。

フロントエンドエンジニアになりたいって人が新しいコースに入ってくれれば嬉しいなあと思います。

今年もRubyKaigi行きます。

RubyKaigi 2024 - RubyKaigi 2024

沖縄ってのがすごいですね。楽しみです。

フィヨルドブートキャンプでは今年もスポンサーシップしていて、フィヨブーハウスもやります。

フィヨルドブートキャンプは RubyKaigi 2024 を応援してます📢 | FJORD BOOT CAMP（フィヨルドブートキャンプ）

前日の14日に沖縄に行って、フィヨブーハウスドリンクアップをやって、永和さんのクルーズに参加予定です。RubyKaigi後は石垣島に三泊しに行って帰る予定です。

今回はスポンサーイベントもたくさんでいろいろ豪華そうで気になります。いつものRubyistやフィヨルドブートキャンプの生徒の方も直接会う方が多いと思うので楽しみです。去年は高熱が出てしまい、現地に行ってるのにホテルにこもってたので二年ぶりといった感じです。

Mac vs WSL2、system testの速さ対決 - komagataのブログ

これ今の14th core i9の24コアでやったらどうなるか気になるなぁ。

これが気になって用意してみたが、Windows上では24コアを認識するが、WSL2内では16コアまでしか認識していない。

Windowsのタスクマネージャー

WSL2のUbuntu内

$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i9-14900K
    CPU family:          6
    Model:               183
    Thread(s) per core:  2
    Core(s) per socket:  16 <=== コレ

実際にrailsのテストでも16並列しかしない。

.wslconfigでprocessorsを設定しても16以上にはならない模様。また、16以下で設定した数字の半分になるのも謎。（20に設定すると10コアになる）

Ubuntu in WSL2 only sees 12 of 16 cores of 12th Gen Intel CPU · Issue #9544 · microsoft/WSL

上記のように似たような話はちらほら見つかるが、まだよくわかっていない。

16という数字が何なのかも気になる。Pコアが8個でEコアが16個なのでPコアを認識していないということかな？でもPコアだけ認識するならわかるが逆ってのは無い気もする。

パソコン作りました。

前回作ったのは６年前とのこと。

動いた自作PC - komagataのブログ

• ケース：LIAN LI O11 VISION
• CPU：Core i9 14900K
• マザボ：Z790 Steel Legend WiFi
• グラボ：PNY GeForce RTX 4060 8GB OC XLR8
• メモリ：CORSAIR VENGEANCE RGB 32GB (2x16GB) DDR5 x 2
• ストレージ：Monster Storage MS950 M.2 SSD 4TB
• 電源：CORSAIR RM850x White
• CPUクーラー：NZXT KRAKEN360 RGB

ミーハーな感じの白くて光るやつにしてしまった。いっかいやってみたかった。

三面ガラスのケースはめっちゃデカいけど意外と剛性がある。余ってるスペースには最近ハマってるグッズを入れられる。

CPUの電圧があがると？問題が出るんだけど下記の問題っぽい。BIOSでCPUのTurbo Boostを切ると大丈夫なんだけど、もっと安いCPUと同じぐらいしかパワーが出ないってことなので辛い。

Intel 第13と第14世代のハイエンドCPU中心に不安定になる不具合多発。高クロックによりCPUが劣化？

あとはNZXTのファンコントローラーを買ったんだけど、ファンの回転数を認識してくれない。同様の症状が報告されてるのでこれも外れを引いてしまったっぽい。

ゲームはFactorioばっかりなので変化はない。最近のグラボは高いですね～。今までは常にミドルクラスだったけど、遂にローエンドクラスになってしまった。

信者としてDHHに影響されて僕もWSL2環境をまた探ってみたくなった。

VSCode + WSL makes Windows awesome for web development

我々Web Developerが気になるパフォーマンスというと、やっぱり遅くて仕方がねぇsystem testのスピードだ。（Dockerの速さとかもありますね）
そこで自分の持ってるM1MaxのMacBookProと11th core i7のAlienware x17 R2でbootcampのシステムテストの速度を測ってみた。

どっちも2021年ぐらいのラップトップです。

MacBook Pro 16inch

• Apple M1 Maxチップ
• 32GBユニファイドメモリ
• 1TB SSD

      435.36 real      1331.03 user      1058.93 sys

Alienware x17 R2

• 第11世代 インテル(R) Core(TM) i7 11800H (8-コア, 24MB L3 キャッシュ, Turbo Boostで最大 4.6 GHzまで)
• NVIDIA(R) GeForce RTX(TM) 3060 6GB GDDR6
• 32GB DDR4 3200MHz
• 512GB M.2 PCIe NVMe SSD + 1TB M.2 PCIe NVMe SSD

real    7m15.354s
user    30m20.487s
sys     7m48.728s

結果

MacBookPro vs Alienware X17 R2

7分15秒 vs 7分15秒

意外。大体おんなじだった。Flakyなテストもあるし、どちらも実行するたびに10～20秒ぐらいの差は出るので厳密にはわからないが、同じぐらい。
事前の勝手な想像として、コア数の分だけ並列実行するので10コアのMacBookProがちょっと有利かなと思ってた。Terminalのキビキビ具合はWSL2の方が良い印象。
CIでは2並列x3コンテナでやってて12分ぐらい。

これ今の14th core i9の24コアでやったらどうなるか気になるなぁ。

Slackの新UIでワークスペース一覧をサイドバーに常に表示したい #Slack - Qiita

Slack上で 「Ctrl(Commmand⌘) + Shift + S」それだけです。

できた。よかった。

Discordメインなんですが、他社さんとSlack Connectを使うために有料プランにしました。

最近ブログで写真をたくさん使うので書いた。

#!/usr/bin/env ruby

dir = ARGV[0]

Dir.chdir(dir) do
  system "mogrify -format jpg *.HEIC"
  system "rm -f *.HEIC"
  system "mogrify -path '#{dir}' -resize 1920x1920 -quality 90 -auto-level -normalize '#{dir}/*'"
end

bin/resize_blog_pictures at main · komagata/bin