部屋さっむ
shibafu528(@shibafu528@social.mikutter.hachune.net)の投稿
ボンクラプログラマー
頭とお腹が弱い。
最近は個人鯖の @shibafu528 がメインです。
⚠️ CW設定のない下品な発言が非常に多いです。これは仕様ですのでご了承下さい。
ℹ️ spam対策でフォロー承認制にしています。上の一文が構わないという方ならお気軽にどうぞ。
FINAL FANTASY XIV 関連の著作物は
(C) SQUARE ENIX CO., LTD. All Rights Reserved.
2.5GBくらいのレスポンスをストリーミングで送ってくるRPCをFloraRPCでリクエストしてみたら、なんか普通に受け止めきれたので驚いている
164040のProtobufメッセージを間髪入れずに送ってくるのだいぶ意味分からんけどな
というかFloraが大丈夫なら大抵大丈夫だと思うんだけど、Web系は分からんが
Wombatで試したら、こいつ全レスポンスをGUIに表示するのでレンダリングが止まって死んだ
というかGUIフリーズしたままワーカースレッドが走り続けてメモリをスワップ込みで20GBくらい食われた
あのーM1 Macには物理メモリ16GBしかないんですけどー
Wombat、Svelte Nativeでレスポンスのレンダリングに……monaco-editor使ってんのかよwwwww
テキストをいい感じに表示できる……できるけどさあw
FloraRPCはレスポンスがどんなに増えてもGUIには1つしかレンダリングしてないから、GUIが原因で受け切れずに死ぬことはないんだな
最後に受信したぶんに自動的にページ遷移もやってないから、ページカウントの更新しかGUIへの作用がない
Floraも素の関数呼び出しの連続じゃなくてQtシグナルのスレッド間メッセージング挟んでるから多少オーバーヘッドあるんだがな
grpc::ByteBufferをひたすらQVectorにpush_backする程度のメモリコストしかないのか
grpc::ByteBufferってstd::stringだった気がするな、ほぼ素のバッファが増えてるだけだな
BloomRPCはElectronのrendererはもう操作に応答せずCSSアニメーションだけが走ってる感じになってるけど、意外と沈みもしない
あいやこれ全部renderer processで処理してるからすっげーーー遅いだけだわ
けっこう実装によってheader metadata違いますね
といってもgrpc-c++とgrpc-nodeって書かれてるやつはどっちもgrpc core使ってるから変わらんのか
dtvault、最小セットのプロトタイプとしてはできてきた感あるな
番組情報とTSの対を保存できて、それが取り出せるまでは実装できたわけだ
適当なWebフロントエンドでもくっつければもうTSストレージを主張できる
最終的にはWebフロントエンドくっつけようと思ってるけど、いつにしようかなあ バックエンドで考えついてる機能は一通り作ってからで間に合うなあ
goでBFF書いてフロントは適当にやろうと思ってるが
コアRust製だけど表層に行くに従ってやりたい事の割に大袈裟になってだるくなるからgoにするとかでバランスを取る
というかオマケだから真面目に書いて時間かけたくない
Envoyなしで直接フロントがgRPC喋れるならもうBFFなしで特攻できるのになー
Envoy置くのとBFF書いて調停するのどっちがマシかというのは一考の余地あるか
mikuttermごりおしで動かしたら大変な感じになった
✅ gtkを使わなければM1 Macでarm nativeで動く
gtk依存が前提のmastodon pluginをごまかしロードするために、いろいろな場所のgtk pluginへのdependencyを切ったり、Autoloadにしたりして動かすとこまでやった
mastodon plugin、バンドルになっているのだからもうちょっと切り分けてもいいのかもしれんな
mikutterdを作るためにmikutterコアの依存関係の知識が必要になってる
あれがモノリスなのはサードパーティで分割していい感じに扱う現実的な手段がないからだった気がするし
SectionReport出たらしんれぽ検討してえなあ
明細をガシガシ打ち出すタイプの帳票だとセクションで定義するタイプのレポートエンジンは便利で、既にシンレポはGUIデザイナを備えてるんだからこれがあればRubyも帳票業界で戦えるんちゃうかと思ってる
おーすごいmikuttermからmastodonに投稿できるやん
mikuttermにMastodonの投稿流れてこんくなった
on_unloadって明示的にunloadした時以外は呼ばれないのか
なさそう、単にこのスクショのmikutter_plugin_unload()が発火されねーなと思って
mikutter_shutdownはKernel.at_exitにフックしたから発火されたんだけど
更新放置してるPixel3、バージョンがだいぶちぐはぐになってきたな
@shibafu528
Failure Sucess 繰り返し
今は別れたブランチたちも
生まれ変わってマージされるよ
Tissueのソースに爆乳入れたらRejectしますよ
精液をかけたときに乳がどれくらいあるのが映えるのかはちょっと結論出してない
fish便利だけど自宅のshellを置き換えるには至っていない
会社では弊チーム共有の関数群がないと捗らないのもあってfishなんだなあ
このアカウントは、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であう必要性もあんましな…
なんかこの4関数がエクスポートされてる任意をネイティブプラグインとして使いたい
関数テーブル置換が残されていますよ Win32なら簡単だよ
簡単か?いやどうなんだろうkernel32の関数とっかえたことはあるけど…
つついさんに嫌な顔させるためにffiを使い、もぐのさんに嫌な顔させるために関数をなるべくエクスポートしない OK!
ウィンドウを持つプログラムなら任意のWndProcをフックとして滑りこませることできますね
前の職場に置いていった謎グローバルフック元気してるかな
nativeから帰ってくるとデータ型どうするか面倒だな
この辺の繋ぎこみがいい感じになれば可能性の塊になるな
ネイティブ側から型定義みたいなのをセットで渡してやればRuby側で解釈変えられるな
ところで確認したいんだけど、mikutterで直接Cに特攻した例そんなにないんですかね?
COMプログラミング、世代的なあれもあり殆どやったことがないんだけど、Windowsで育った身としては一度くらい真面目にやってみたい
やんごとなき事情でC#でCOMサーバ1つ書いたことはあるけど、C#はにわかやろ
WinRTですらCOMに基づいてるんだからWindowsはCOMやってこそでしょ
まあ面倒だからあらゆる隠蔽が生まれたわけで、触ったら負けなのは絶対的にそう
ffiで疎にして変にインターフェースを複雑にすると面倒だな。Pluggaloidは非同期なのでメモリ管理の問題もあるし。
もうもっと素直なC拡張の形でNative Pluginを表現して、VALUE構造体をやりとりしたほうが話が早い気がする
通信、Pluggaloidが通信できるようになればこれはやらなくてもいいんだよなあ
俺よりよっぽどうぇっぶやさんのほうが言語跨いでますよ
C拡張入門みたいなページ見てるんだけど、なんでこのサイトサンプルコードがK&Rなんだよ
なんだろう、mrubyを見てたせいかCRubyのC APIすげえ既視感しかないぞこれ……!
あれ?もしかしてffiよりC拡張のほうがハードル低くない?
