カラクリスタ・ソーシャル

最近 beam 系 vm (Erlang とか Elixir のバックエンド) を使う Gleam と言う言語を使ってみたさがあるんだけど、さて何を作ったら良いんだ？で手が止まっている

• https://gleam.run/

自分のブログのコンパイル速度を改善できないか、と思って bun (JavaScript rutime) を試してみたんだけど、自分の環境の場合、 bun を使った方が遅くなってしまった……

しばらく前から自分のブログ用にPerl 用の cmake-gfm の FFI Binding を作ろうと思って結局作業してなかったな、と思い出すなど:

• https://github.com/github/cmark-gfm

Perl で FFI するためのモジュール、今だと Affix が便利そう、と言う印象を持っている:

• https://metacpan.org/pod/Affix

Perl で FFI する用のパッケージってどうやって作るんだろう、と思って軽く調べたんだけど、今だと alienfile って言うのがあるのか:

• https://metacpan.org/pod/alienfile

強いて言うならインターネット知人との縁が切れてしまう部分があることだけど、そもそもの話として私はインターネットで知人と交流する機会なんてほぼないし、基本的には誰に対しても話かけたりはしないので、まぁこれも困らなかったりする

X(鳥)が完全有料化したとしても、まぁ今はほぼ見てないし、自分用に Fedivese を持ってるから別に困らんな、と言う結論になった

AudioGridderPlugin for Windows が wine-staging で上手く動かなかった件、どうも wine の version とか関係なくて、Reparse point とか junction 周りの扱いの問題だったっぽい。とりあえずで proton wine ge 8.15 を使ったらなんとかなった:

• https://github.com/GloriousEggroll/proton-wine/tree/Proton8-15

Windows Software on Wine 、大体は動くようになれば動き続けるんだけど、さりとて動かなくなるものは動かなくなる、と言う感じなので、まぁ時の運みたいな所はありそう

wine、あるバージョンで動いていたソフトウェアが次のバージョンでは動かない、などが普通にあるので、割と厳しみはある

wine-stating 6.13 の頃に作った wine prefix で AuidoGridder Plugin for Windows が 動くのに、 wine-staging 6.14 以降で作った wine prefix だと何故か動かないと言う事案に遭遇しており、今 wine 6.12 をビルドする破目になっている

自分のブログ、GitHub Workflows でも生成できなくは無いんだろうけど、それをやりだすとコストが大爆発するか時間掛かりすぎワロタになる予感しかないので、完全ローカルでやってます

とは言え自分のブログは Perl で自作した静的サイトジェネレータを使っていて、具体的にはRyzen 9 3950X の 30 Threads ぐらいをしばいて高速にブログを生成しています

個人的にはプログラミング言語への好き嫌いはあっても良いとは思っていて、私も Ruby と Python と PHP は食わず嫌いしてる。

まぁ昔ちょっとだけ齧った事はあったけど全部忘れてるし、出身母体が Perl コミュニティなので、なんとなくのライバル意識みたいなのがある。

とは言え近年では AI 関連は Python が必須、元スタートアップでは Ruby (Rails) 、普通の Web サイト保守では PHP が使われている印象で、Perl はあんまり居場所が無いんだけどね……

プログラミング言語、 複数修得しておくとプログラムでの表現力が上がる印象。あと言語 A だと使える技法だけど別の言語 B だと別の方法を採る必要がある、みたいなケースでは修行になるので、その点でも良い

今回の LRU Cache の実装ではポインタベースの無限リストを作る際に next や prev を使うと混乱する、と分かったので、今回は front と back と言う表現を使った

つか Go で Zero Allocation がカチっとはまると楽しいので、業務ではなく趣味ならそう言う道を通り続けても良いと思う。ただ実装に時間は掛かるけどね

Go 言語で Zero Allocation をするやつ、最初から Zero Allocation を意識して作らないと allocation をが 1〜3ぐらい残って削れないとか良くあるので、結構難しいところではある。

ただ慣れの部分もあるので、Go でライブラリを作るときは常に Zero Allocation で作るようにはしている。その方が早いし、修行にもなるので

今回作ったものは In-Memory な LRU Cache の Go 実装なんだけど、どこかにバグを作り込んでいる予感しかない……

あと Zero Allocation で作ってるので、たぶん早い（？）はず

ライセンスとか API のドキュメントとか何一切用意していないんだけど、 この辺りはまた後で用意する予定です

• https://github.com/nyarla/tinylru