部屋さっむ
ボンクラプログラマー
頭とお腹が弱い。
最近は個人鯖の @shibafu528 がメインです。
⚠️ CW設定のない下品な発言が非常に多いです。これは仕様ですのでご了承下さい。
ℹ️ spam対策でフォロー承認制にしています。上の一文が構わないという方ならお気軽にどうぞ。
FINAL FANTASY XIV 関連の著作物は
(C) SQUARE ENIX CO., LTD. All Rights Reserved.
2.5GBくらいのレスポンスをストリーミングで送ってくるRPCをFloraRPCでリクエストしてみたら、なんか普通に受け止めきれたので驚いている
164040のProtobufメッセージを間髪入れずに送ってくるのだいぶ意味分からんけどな
Wombatで試したら、こいつ全レスポンスをGUIに表示するのでレンダリングが止まって死んだ
というかGUIフリーズしたままワーカースレッドが走り続けてメモリをスワップ込みで20GBくらい食われた
Wombat、Svelte Nativeでレスポンスのレンダリングに……monaco-editor使ってんのかよwwwww
FloraRPCはレスポンスがどんなに増えてもGUIには1つしかレンダリングしてないから、GUIが原因で受け切れずに死ぬことはないんだな
最後に受信したぶんに自動的にページ遷移もやってないから、ページカウントの更新しかGUIへの作用がない
Floraも素の関数呼び出しの連続じゃなくてQtシグナルのスレッド間メッセージング挟んでるから多少オーバーヘッドあるんだがな
grpc::ByteBufferをひたすらQVectorにpush_backする程度のメモリコストしかないのか
grpc::ByteBufferってstd::stringだった気がするな、ほぼ素のバッファが増えてるだけだな
BloomRPCはElectronのrendererはもう操作に応答せずCSSアニメーションだけが走ってる感じになってるけど、意外と沈みもしない
あいやこれ全部renderer processで処理してるからすっげーーー遅いだけだわ
といってもgrpc-c++とgrpc-nodeって書かれてるやつはどっちもgrpc core使ってるから変わらんのか
最終的にはWebフロントエンドくっつけようと思ってるけど、いつにしようかなあ バックエンドで考えついてる機能は一通り作ってからで間に合うなあ
コアRust製だけど表層に行くに従ってやりたい事の割に大袈裟になってだるくなるからgoにするとかでバランスを取る
Envoyなしで直接フロントがgRPC喋れるならもうBFFなしで特攻できるのになー
Envoy置くのとBFF書いて調停するのどっちがマシかというのは一考の余地あるか
gtk依存が前提のmastodon pluginをごまかしロードするために、いろいろな場所のgtk pluginへのdependencyを切ったり、Autoloadにしたりして動かすとこまでやった
mastodon plugin、バンドルになっているのだからもうちょっと切り分けてもいいのかもしれんな
mikutterdを作るためにmikutterコアの依存関係の知識が必要になってる
あれがモノリスなのはサードパーティで分割していい感じに扱う現実的な手段がないからだった気がするし
明細をガシガシ打ち出すタイプの帳票だとセクションで定義するタイプのレポートエンジンは便利で、既にシンレポはGUIデザイナを備えてるんだからこれがあればRubyも帳票業界で戦えるんちゃうかと思ってる
なさそう、単にこのスクショのmikutter_plugin_unload()が発火されねーなと思って
mikutter_shutdownはKernel.at_exitにフックしたから発火されたんだけど
@shibafu528
Failure Sucess 繰り返し
今は別れたブランチたちも
生まれ変わってマージされるよ
This account is not set to public on notestock.
昔検索でヒットしたとき「ちゃうんや俺がやりたいのGLES1.1だからUTで説明されても何もわからん…」と涙した
当時の俺にポストプログラマブルシェーダ時代を理解する知性はなかったので1.1で探してたんだよなあ
集合の話してる1コマ目くらいまでは何か知ってることの話をしてる気がするけどやっぱり寝てた奴
寝る前に思いついて、朝ffi gemを調べて、ガッと書いて呼び出せたので仕事に向かった
Plugin.create単位でnativeに降りることができて、その単位ごとにvoid*が1つ確保されていて、あとはイベントハンドラが仕掛けられれば何でもできると思いませんか
Ruby側で購読してnativeに降ろしてもいいし、nativeから直接購読できてもいいような気がします
ffi使うかfiddle使うかはちょっと悩んだけど、つついさんが苦しんでて記憶にあったからffiにした
int mikutter_init(*mikutter_t)
int mikutter_plugin_create(*plugin_t)
void mikutter_plugin_unload(*plugin_t)
void mikutter_shutdown()
が呼べるDLLなら何でも適当にdlopenなりLoadLibraryすりゃ良くねーかくらいに思ってるので、だからFFIであう必要性もあんましな…
つついさんに嫌な顔させるためにffiを使い、もぐのさんに嫌な顔させるために関数をなるべくエクスポートしない OK!
ウィンドウを持つプログラムなら任意のWndProcをフックとして滑りこませることできますね
ネイティブ側から型定義みたいなのをセットで渡してやればRuby側で解釈変えられるな
ところで確認したいんだけど、mikutterで直接Cに特攻した例そんなにないんですかね?
COMプログラミング、世代的なあれもあり殆どやったことがないんだけど、Windowsで育った身としては一度くらい真面目にやってみたい
WinRTですらCOMに基づいてるんだからWindowsはCOMやってこそでしょ
ffiで疎にして変にインターフェースを複雑にすると面倒だな。Pluggaloidは非同期なのでメモリ管理の問題もあるし。
もうもっと素直なC拡張の形でNative Pluginを表現して、VALUE構造体をやりとりしたほうが話が早い気がする
通信、Pluggaloidが通信できるようになればこれはやらなくてもいいんだよなあ
C拡張入門みたいなページ見てるんだけど、なんでこのサイトサンプルコードがK&Rなんだよ
なんだろう、mrubyを見てたせいかCRubyのC APIすげえ既視感しかないぞこれ……!