prev: https://zenn.dev/okuoku/scraps/b485da18176fdc
next: https://zenn.dev/okuoku/scraps/c236209827218e

★ 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のコミットメッセージ検索をしてみるとか。。？
WebGL-C: EGL部分の抽象化をどうすんのか問題。 ... SDLとかを抱えるしかないかな。。
RISC-V: https://qiita.com/okuoku/items/0aaa76c34f8ee3aa330a の続き。
WASM: Yunibaseに相当する実装アーカイブが必要だけど死んでる実装が多く難しい。Scheme処理系みたいになってないかコレ。YuniFFI stubの呼び出しプロトコルを決める、各インタプリタ向けに実装する、null libcを移植、LLVM libcの調査。 setjmp / longjmp の出力コード比較の会。
Tew: Behaviour TreeベースのAIに替える。Atari記事化とドロップ。
deCoda: JUCE部分の音声出力が不調すぎる。RTL Utilityでも同様だったのでJUCE側かな。
GameSynth: ライセンスが割と不安。外部VSTと合わせてAmbisonicsの制作を試す。

okuoku

★ fork

今週のyunibase

Gaucheが0.9.10リリース。

Kawaがビルド失敗 → 一旦 revertかな。

okuoku

Mesh Drawing API の作戦変更

もうちょっとWebGL1をリサーチすることにした。既存のゲームエンジンでWebGLエクスポートがあるものはだいたいWebGL1前提で、最大公約数として機能しているように見える。

たぶんハイエンド向けには WebGPUが2021年以降にfinalizeされるのを待った方が良い 。いくつかの重要なポイントが未解決で現実的なアプリケーションに耐えない(webgpu-nativeにおけるオブジェクトのRef/Release等)。例えば特定の実装(dawnかwgpu)にフォーカスするのが良いかもしれないがちょっとリスキーに見える。

逆に言えばハイエンドはWebGPU一本に絞っておいてそのうちfinalizeを待てば良いわけで、WebGLに集中するのが良い気がしている。ただ、WebGL2はSafariに載ってないためWebGL1を選択せざるを得ず、かつ、WebGL1は超クッソ激烈に重要ないくつかの要素が無い。

WebGLでdEQP(AOSPのOpenGL test suite)を動かそうという提案はあるが、マージされていないようだ。

頂点シェーダをCPU実行できるか？

デバッグ用に頂点シェーダをCPU側に持っていけないかと思ったけど、前書いた

でVTFがあったな。。↑ のケースではテクスチャに書き込みがないけど、よくあるVTFのユースケースとしてアニメーション用のパラメタの受け渡しがあるので、GPU側でVTF用のテクスチャを生成するケースがあるかもしれない。

okuoku

Debug Session Control Protocol

LSP( https://microsoft.github.io/language-server-protocol/ )とかDAP( https://microsoft.github.io/debug-adapter-protocol/ )のようなHTTP 風開発プロトコルはあるのに、ビルドやデバッグターゲットのディスカバリをカバーしたプロトコルは無いのは何故か。。

実際にはLSPはビルドに関する情報を持っているし、DAPにはデバッグターゲットを制御する機能もある。マルチプレクサに相当する機能性が無いのかな。Seleniumあたりをwrapできると良いけど、スケジューラ / IOトレースを取りながら実行というのも欲しい。。

LSPとかDAPの謎言語サポートが面白い

Broadcom製のCobolサポートって何だよ。。

エラーメッセージのパーサを持ってエラーをリストするだけのLSPサーバ。任意のlintツールをLSPにできる。かしこい。

https://github.com/mattn/efm-langserver

okuoku

特集: こんなのがコンテンツになるのか。。

Promiseとasync/await論争

Schemeプログラマ要するに自分の悪い癖はこういう議論の可能性を見落す点な気がした。この手のbuilding blockに不満があれば自前の抽象で常にどうにかしてしまうため、共通語彙が貧弱であり続ける。

Lispプログラマにはカッコが見えないがSchemeプログラマにはライブラリも見えない。 ... 実際には処理系の実装者自身はかなり意見を持ってる事は多いけど。。

Rubyと漸進的型付け

議論自体はRubyにとってスーパーどうでも良い(エコシステムになってるかどうかの問題であって言語機能の問題でない)ポイントだけど、書かれている場所とか立場は割と味わいぶかい。

今日(もう昨日だけど)という日がRubyの命日になったかは何とも言えない。もっとも、単に批判する側が圧倒的有利というだけの話で、割と制御のしようがない。将来Webブラウザが消えてなくなって別のエコシステムが勃興したとして、その立場からRoRを批判するのも今と同じように容易だろう。Twitterのトレンドに入るかどうかはわからないけど(Webブラウザが無くなっているため)。

okuoku

Immediate-mode GUI vs. Qt

↑ の激論に何か覚えがあると思ったらIMGUIだった。

My prediction is that in a few years Insomniac's tools team will come up with another GDC postmortem explaining what's wrong with Qt, and why they switched from Qt to IMGUI. I'm just joking here, but you never know... :)

(実際にはプレゼンを書いた当人(Andreas Fredriksson)は既にUnityに移った。)

実際Immediate-mode GUIの用語自体わりとフラフラとしていて、IMGUIの最大手実装Dear Imguiでも、Immediate-modeはタグラインから外している。

https://github.com/ocornut/imgui

Dear Imguiは超コンパクトなGUIライブラリとして主にゲーム方面で重宝されている。他の実装としてはNuklearもある。

... で、Qt vs. Imguiのような論争もあんまり大きな意味合いがなくて、適材適所としか言いようがない。意味の無い議論をBikeshedのように言うことがあるけど、これは。。何と言うんだろうな。。とにかく、よくあるフレームの類型なんじゃないかと思う。