prev: https://zenn.dev/okuoku/scraps/e76cf143d106aa
next: https://zenn.dev/okuoku/scraps/403b0454a0cf85

★ 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

Qiita記事メンテ

okuoku

WASM環境

直球で大草原。まぁSimpleとはもう言い難いよな。。

Big-endian

Big-endian modeのWASMがあったらどうだろうというのは割と出るけどまぁスレッドのコメント( https://github.com/WebAssembly/design/issues/1212#issuecomment-691740955 )で結論されてるよね

Wasm is a little-endian platform, by design. The LLVM Wasm backend is focused on that.

ARMv8にJS専用命令があるとか話題になったけど、何気にエンディアン論争も知らない間に終っているような気はする。

仮にメガドライブでWebAssemblyを動かしたいとして、ゲームロジック等のパフォーマンス依存の強いポイントでなければ単純なVMでも十分な性能が出る可能性が高いのではないかという気がする。スプライト制御のようなパフォーマンスが必要なところはそもそも移植性が不要なので素のCで書いてFFIすれば良いし。

ツールチェーン

まぁ確かに。昔TCG向けにnmoshのバインディングを書いたときもマンデルブロ集合描いたし、

Pypyもコンパイル中にマンデルブロ集合出してたな。

okuoku

prev: https://zenn.dev/okuoku/scraps/e76cf143d106aa#comment-f6240ff8f0d994

Reposoup / Reposauce

GitAsBackend だと既存の用法とまぎらわしいので Reposoup を実装全体にあげて、リポジトリビューアを Reposauce に分離するのが良いかな。略称は rs に統一、プロダクトとしては Reposoup だけで訴求。

全文検索

英語やgeolocation用の検索機能はMongoDBや相当するDBにだいたいある。問題は日本語で、

Amazon CloudSearchは2-gram検索ができる ...が日本語で2-gramはちょっと。。(中身はSolrなのにKuromojiとか無いの。。？)
GCPは有力な製品が無い。マジで！？検索の会社じゃん。。
AzureはいきなりCognitive Searchになる

もうElasticとSolr以外の検索エンジンは死んでしまったのだろうか。。

いっそのことファイルツリーとして検索インデックスを構築するツールを作り、GitHubを無料のファイルストレージとして使って無料で構築できる検索エンジンを作った方が面白いかもしれない。 ★

現状のスケーラビリティ目標が1000万ドキュメントで、通常の単語クエリは(単語1つだけでも)数万ドキュメント程度まで数が減るので、モバイルを無視するならANDや時系列抽出はローカルで処理できる。ただし、GitHubは巨大ファイルをホストできない(100MiBとかでpushできなくなる)ので、適当にページング処理が必要。

曖昧検索には弱くなるが、ソースコードには曖昧検索は不要なので問題ないはず。

okuoku

Glitch.com プライベートプロジェクトの有料化

割とGlitch.comは経営について強気でいたと思うけど、あんのじょうプライベートプロジェクトは有料化の運びになった。

プライベートプロジェクトがないとコードがパクられるじゃんという指摘はその通りかもと思った。forkボタンに相当するRemixボタンがGlitchにはあり、プロジェクトが未完成のうちにRemixされるのをイヤがるユーザは居そうではある。

Bring your own free tier ？

どこのベンダもfree tierを動的なサイトのために用意しているので、その持ち込みを前提としたプラットフォームにすれば良いじゃないかという気はする。

例えば crowdbotics はGitHubのパブリックリポジトリをユーザが作成したアプリのストレージとして使用している (https://github.com/crowdbotics-apps -- プロジェクトが多すぎて常にUnicorn出る) 。

https://crowdbotics.github.io/docs/

How do I get started?

... Sit back and enjoy while we create your application, the associated GitHub repository, Trello board, and the dev-ops pipeline.