prev: https://zenn.dev/okuoku/scraps/2fc30326438b4a
next: https://zenn.dev/okuoku/scraps/ef68eab5cc0b5b

★ queue

• DryScheme(C++): SECDV Scheme VM バイトコードの復習 → 共通bootstrap I/Oフレームワーク設計 → Scheme-on-Scheme 実装。 callout intrinsicの設計(VM命令？)。
• YuniFFI: libclangでのAPIスクレイピング → API request packer の仕様決め → packer実装とbytevector APIの見直し → バインディング実装(apidataリポジトリ分離)
• Reposoup(GitAsBackend): XMLどうすんのか問題、index hintsの書き方問題、MongoDB + Groonga アプライアンスを作ってGitのコミットメッセージ検索をしてみるとか。。？
• RISC-V: https://qiita.com/okuoku/items/0aaa76c34f8ee3aa330a の続き。
• WASM: Yunibaseに相当する実装アーカイブが必要だけど死んでる実装が多く難しい。Scheme処理系みたいになってないかコレ。各インタプリタ向けに実装する、null libcを移植、LLVM libcの調査。 setjmp / longjmp の出力コード比較の会。
• Tew: Behaviour TreeベースのAIに替える。Atari記事化とドロップ。
• deCoda: JUCE部分の音声出力が不調すぎる。RTL Utilityでも同様だったのでJUCE側かな。
• GameSynth: ライセンスが割と不安。外部VSTと合わせてAmbisonicsの制作を試す。

★ fork

https://zenn.dev/okuoku/scraps/bb32535f0cd2ae

ゲームエンジンの一覧

https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74

面白い。MonoGameベースが多いな。。MSはXNAをMacに展開できていればUnityは作られずに済んだのかもしれない。まぁ現実にはMono自体を吸収する方向で解決したわけだけど。

小さいCコンパイラの比較

https://twitter.com/yukihiro_matz/status/1387209728950865920

I have found that some people prefer to use the C language instead of MIR for their JIT implementations.

[誰によって？]

実際C文字列で進める方がインテグレーションがやりやすそうではある。ただモチベーションの項に書かれているように、

Standard Ruby methods implemented in C can be translated into MIR and can be inlined with MIR code generated from Ruby bytecode. The combined code can be optimized and just-in-timed into high-performance machine code.

C言語とRubyを共通のバイトコード(MIR)に落し込むことがキモではあるので、JITとしてCコードを使うのは余計な目標と言えなくもない気がする。まぁ当のCRubyのJITCがCベースだけど。。

https://k0kubun.hatenablog.com/entry/ruby26-jit

<video> 要素の可能性

https://b.hatena.ne.jp/entry/s/sbfl.net/blog/2021/04/30/javascript-html-picture-in-picture/

前書いた Nosleepもvideoだった。