おはよー！おはよー！そこにいるの？まぶしー！まぶしー！夢があるの！冒険が＼はい！／挑戦を＼はい！／つーれーてーきーたー＼問☆題☆解☆決！／＼(ﾟヮﾟ)＞＼(ﾟヮﾟ)／＼(ﾟヮﾟ)／＜(ﾟヮ^)

23時に寝たのでめちゃくちゃ早起きになった

いやでも群馬にいたときは7時ちょいで起きてたな…

家中の家電を外出先から制御できる、エレコム「スマホでかんたんどこでもリモコン」 - エルミタージュ秋葉原 http://www.gdm.or.jp/pressrelease/2020/0310/341185

昔Dropbox課金してなかった頃、容量に困ってOnedriveに分散させてたやつが今になって却って面倒になってきた (LinuxでOnedrive同期やりたくないし…)

https://aur.archlinux.org/packages/onedrive-abraunegg/ これを使えばいいんだろうけど

ま1回Windows起動してガッとmvしたほうが環境にパッケージ増えなくてクリーンだな

Well Known Messageもなんかしてパース環境に取り込んであげないといけないのか

protocがどうやっているかを読めばいけそう？

protoc、自身のファイルパスから相対で../include/とかを検索してるというオチだった

だいたいシステムのパケマネでいれると/usr/bin/protocになるから/usr/includeにwell-known messageのprotoが入ってる想定みたいな

#ifdef _WIN32
#elif defined(__APPLE__)
#else
の三段構えを見てしまったよ

そう、実行時

// Get the absolute path of this protoc binary.
bool GetProtocAbsolutePath(std::string* path)

っての発見してああああお前実行時解決かよってなった

えーこれサードパーティアプリ作るのに普通に都合悪い

/usr/includeとか仮定するわけにもいかんし、そもそもこのためだけにシステムの都合を気にしたくないな

CMakeのPROTOBUF_INCLUDE_DIRをそのままコンパイル時のマクロまで引き回すことにした。システムにだいぶ依存するが、一旦は…

これ絶対Windowsとかで動かねえだろ

ん、これもしかしてImporterを継承するなりしてカスタムImporter作れば何とかなるな

コンストラクタくらいしか差し込みできるポイントなさそうだけど

生成コードのDescriptorが入ってるプールからルックアップするDescripotorDatabaseをImporterに認識させればいけるはず
実際にWell known messageをリフレクションして使いたいときもどうせそっち参照することになるし

libprotobuf完全に理解したい

libprotobufなかなか楽しいっちゃ楽しい

libgrpc++は覚えてもgRPCしかできないけど、libprotobufはProtobufが何かと使い道はありそうなので価値がある

リクエスト部別スレッドにしてえな

今のままだと田舎ITのUIフリーズクラサバアプリになってしまう

別に都市かは関係ないんですけどね

COBOLを笑う人は十進演算が必須な場所で浮動小数点数とか使って怒られたことがないのだろうか あのような手間を払わずとも最初に習うデータ型がそれを担保しているのすごく特定ドメインでは強いと思うんですよ

最初に覚えるデータ型がコンピュータの二進数世界の都合に縛られてないんだぜ

本質的な強みはもっと他にあると思うが、俺はこれで仕事をしたことがないのでまあ分からん

ただ間違いなく汎用言語としての価値は現代にはないぞ

俺はあの言語をプログラミング言語というよりDSLとして扱っているので…

出社

トイレ行列の恨みをぶつけて爆音うんこしてる

ﾌﾞﾁﾐｺﾌﾞﾁではない

家に帰ったらmikutterが落ちていた

通販の日用品終わってるの普通にキレるんだよな

こっちは通販をプライマリな経路にしてるんや、普段ドラッグストアやらイオンいってるやつはすっこんでろという気持ち

(まあそういう話じゃないけど…)

Qt 5.14、QML環境ES7マジ？

ES5書かされたらどうしようって思ったけど思ったより新しいやん

JavaScript Host Environment | Qt QML 5.14.1
https://doc.qt.io/qt-5/qtqml-javascript-hostenvironment.html

> The QML runtime implements the 7th edition of the standard.

ほんとぉ？

作ってるgRPCクライアントでQML使うか悩んでる あまりフットプリント大きいならC++で頑張ります……みたいな気持ちがあり

「Electronアプリを起動するより軽い」が目標なので

起動するよりっつか使っててのコストも

qmlsceneでQMLロードするとQtQuick.Controlsがネイティブの見た目になるのに、QQmlApplicationEngineクラスでロードすると独自になるな なんだこれ

main関数で使うやつをQGuiApplicationじゃなくてQApplicationにしたらネイティブになった……えっなにこれ

QApplication extends QGuiApplication の継承関係で、QApplicationはQt Widgetsに所属しているのか なるほどなるほど

QtQuick.Controls.TextField、右クリックコンテキストメニューが提供されていないとのことで解散です

そんなもの再発明したくないが

いや難しくはないけど…

右クリックしたらCut/Copy/Pasteくらい標準でできててほしいよね、ができないらしい……

コンテキストメニューくれってチケット起票されてるけど、2013年だしQt6でも載ることはなさそう https://bugreports.qt.io/browse/QTBUG-35598

はい、じゃあC++でいきます

ちなみにQMLロードしてもメモリはそんなに食わないみたいで、Chromiumを抱えこんで立ち上げるよりはよっぽど低コストのようだ

まあ、そりゃそうだよな。

うーんImporter細工してwell-known proto仕込めるかと思ったが、なんかちゃんとカプセル化されてるな…

protobufのリポジトリから基本型のprotoファイル全部コピーしてきて、Qt Resource Fileにパックしてそれをロードできるように仕込みをするのは現実的にできそう

ウオーーーーーよし勝った

Qt Resourceからprotoファイルロードできるようにした

libprotobufのImporterはファイルロードの処理をSourceTreeというクラスで抽象化していて、基本実装としてはファイルシステム上のパスから仮想マップを作ってそれでパス解決するやつがある

パス解決+fopenして読めるようにするところ だな

これは好きに実装できるので、Qtのリソースの特定prefixから探索してヒットすればそこから、無ければ前述のファイルシステムから読むやつに全部委譲するやつを書いたらうまくいった

fopenするとはいったけど、InputStreamの操作もJavaとかのそれみたいな感じで抽象化されてるのでまあどうにでもなるやつですね…

このアカウントは、notestockで公開設定になっていません。

toshi_aやな

<T extends SourceTree> を表すにはこれでいいんか？

https://github.com/shibafu528/florarpc/blob/10611b378395b0687e6466db294315437074e18c/entity/Protocol.cpp#L75-L77

ZeroCopyInputStream (ただしZeroCopyかどうかは実装者に委ねられている)

じゃあなんでそんな名前にしたんだ…

うるせえ政治はTwitterでやれモード発動した

まあ……まあ……それもまた自由ですから……ハァハァ

努力しろ、たしかにそうなのかも