linux用のgitクライアント(2週間後)

AIにgitのグラフを表示できるプログラムを作ってもらった(前回)。そのまま要りそうな機能を追加していっている。思い付きで機能を追加しているのでUIがいまいち分かりにくい。

とりあえずは忘れないうちに取説代わりに機能を書いておく。

windows対応

linux用に作ってはいるが、pythonなのでwindowsでも動いた。ついでにpyinstallerでwindowsバイナリも作っておいた。別途graphvizをダウンロードして入れる必要がある。レジストリに設定しておけばフォルダ右クリックコンテキストメニューから起動できる。

windowsで動かすと、gitはlinuxで使う方が圧倒的に早い事が分かる。

グラフとログ

クリックしたノードのログが出る。デフォルトではマージはグラフにならない。あくまでもブランチ間の関係を示すグラフ。

マージがどこから来ているのかは一応右ペインには表示される。でかいプロジェクトだと線だらけになってわけがわからないし幅をとる。なので遠いマージは省略して、クリックしたときだけ出るようにした。（苦肉の策）

デフォルトではマージは線になってないので、右のコミットをクリックしても左の図には対応するものがない場合がある。その場合は、図ではマージ元のブランチを示す。（ときもある。現状適当） 

上図のようにマージもグラフに出るように切り替えできるが、ある程度でかいプロジェクトだと図が異常にでかくなってgraphvizが死ぬ。仕方ないのでgraphvizが死なない程度の大きさになるように年とか日とかの単位でまとめるようにしている。（クリックしたら中身は展開される。代わりにどこかが閉じられる）

グラフに表示したければブランチを作る。 

undo / redo

ブランチ削除とかリベースとかをした後、undoできる。やってみるとまあまあ出来るが、過信は禁物。リモートブランチの操作はundoできない。ローカル変更だけundoできる。

AB操作

ブランチを2つ選んでいろいろできるようにした。が、何がどうだったかわからなくなる機能がいくつかある。UIと名前の付け方が悪いんだと思う。
ドラッグアンドドロップか、2つ目をctrlクリックで選べる。右クリックでも選べる。マージコミットが混ざっていると操作がうまく行かない場合が有るらしい。

AB操作/ABログ比較

ログを二つ並べてどこまで一緒か見る。遅くなるのでコミットのコメントで比較してから内容を比較するようにしていたはず。なので、中身が同じでもコメントが違ったら違うもの扱いのはず。

AB操作/A..HEADをBにリベース

 

単にBにリベースすると分岐からAまでの変更が衝突するとき用のリベース。1つくらいなら別に対話的リベースしてもいいけど、いくつもあったときに、面倒だったので入れた。filter-branchとかで書き換えて移動したいブランチが大量にできたときに使う。

AB操作/A..末端をBにリベース

 上記のようなリベースしないといけないものがたくさんあったときに面倒になって入れた。囲ってあるが青で示したリモートブランチは移動しない。filter-branchとかで書き換えて移動したいブランチが大量にできたときに使う。

AB操作/AをB側へ寄せる

 filter-branchとかでAとBでほとんど同じログなのに別系統のログになってしまった時、Bの中から共通の親を探して、そこにAを付け替える。

AB操作/AとBで同じ親を探す

上記AをB側へ寄せる一歩前の、付け替える共通の親を探すまでの処理

Bの中からAに近いものを探す

「AをB側へ寄せる」の処理をするときに、どれに寄せるか探すために入れた。探したい分岐の根本をBに指定すると、その子を探して、一番長くAと一致するものを探すはず。そこで見つけたBへ寄せる。

まとめ

結局なんだったのかというと、filter-branchを迂闊に使うとぐちゃぐちゃになってしまうので、変なものを作る羽目になるという話であった。

claudeやらgithub copilotやらcodexやらgrokやらgeminiやらperplexityやら、あらゆるAIの無料枠を2週間つぎ込んでしまった。プログラムも大きくなってきてしまい、割とすぐにトークンが尽きてしまう状態になった。これ以上大きいプログラムだと、無料では工夫しないとしんどいかもしれない。（待てばいいだけだが）

無料枠で使える度で比較すると、個人的には以下の順。使い方の問題もあると思う。

claude >= github copilot > grok > codex > gemini > perplexity

• claude: コーディング性能は一番いいような気がする。ほぼほぼ致命的なバグは入らないので何も確認せずいきなりpushしている。ただし割とすぐトークンが尽きる。無料だとCLIも使えないしgithubにpushもできない？が、5時間くらいで回復するので良。指示を投げておいて、トークンが尽きたら5時間後に「続ける」を押すだけの作業で割とやれる。待っている間どうしようか考えられるのも逆に良かったかもしれない。このアプリは旅行先の空き時間にclaudeをポチポチして大枠は完成している。
• github copilot: かなり無料で使わせてくれる。コーディングもまあまあ。無料でもCLIが使えたりvscodeで使えたりするので、往復のやり取りが必要そうな作業（微調整とか）はこっちでやると効率が良い。
• grok(cursor?): そこそこの量を使えて1週間で回復する。コードはあとでclaudeに直してもらわないといけなそうなレベルのようだ。githubへのpushを頼むと延々考えた挙げ句ファイルを壊す。追記: cursorで使うと一瞬で無くなるが、grokでパッチで出してもらうようにすれば、結構使える。
• codex: なかなか回復しない。1ヶ月待つ必要がある。他で使ってたのか割とすぐに切れてあまり使えてない。
• gemini:  確認せずに出してくるのでエラーが出まくる。それもあってすぐにトークンが尽きる。claudeも別枠で使えるが、一瞬で無くなり何もできない。
•  perplexity: コーディングはまあまあ。githubにpushしてくれた。1週間で回復するはずだと思ったが、なんかgithub使えなくなってまともなパッチも出してくれなくなった。最初はよかったと思う。

金を払ってない人の感想なので、この感想に意味が有るかと言われると、無いような気はする。ただ、もしgeminiとかgrokに金を払ってたら、腹立つだろうなとは思った。

追記: grokはpushさえ頼まなければ結構使えるので評価が上がった。難しいコードは(無料だと)無理だが、数をこなせる。 

linux用のgitクライアント

linuxメインで使うようになり、大抵のことは問題ないが、今のところの最大の問題はtortoisegitが使えない事である。特にコミットグラフは必須で、これが無いと迷子になってしまう。(2番めの問題はWinMergeが使えない事)

いくつかlinux用のクライアントを試したが、大体全コミットが表示されて、どのブランチとどのブランチが繋がっているのかぱっと見て分からないものばかりだった。

とりあえずグラフになって見れればいいだけなので、AIに作ってもらった。https://github.com/tthogehoge/git_graph_server

コミットグラフ

これが無いと何が何だか分からなくなる。ノードの間で何個コミットが省略されているか出ている(個数はどうでもいいがclaudeが勝手にやった)。

ノードをクリックすると右にログが出る。

コミット詳細

ログのコミットをクリックすると、そのコミットの内容がでる。+ボタンでブランチを作ったり出来る。

差分表示

ファイルをクリックするとdiffが表示される。

あとはコミット同士の比較したりが出来るようにしてもらった。tortoisegitには遠く及ばないが、個人的にはこれでまあまあ使えそう。

要は分岐に関係ないコミットをグラフから省略出来ればそれでいいんだけど、linux用のクライアントでこんなやつないのかなあ。 

追記: その後色々機能追加した。 

みんな使おうfirefox

firefox (+拡張機能 ublock origin)

 

google chrome

なんにも見えん 

同条件で比較してないからずるい？いや、ずるくない。そもそもandroidのchromeにublockを入れられないのが悪い。 

firefoxにも色々問題はあるが、広告で何も見えないことに比べたら全て無視できる。 

続6：中華linuxゲーム端末Anbernic 353PSでセガサターン（完？）

以下のあたりの続き 

https://tthhfugapiyo.blogspot.com/2025/04/5linuxanbernic-353ps.html

https://tthhfugapiyo.blogspot.com/2025/04/cfor.html

sega saturnのエミュレータでGRANDIAのムービーが遅い原因がSCUのエミュレーションにあるということまで突き止めたが、どうにもならんという結論になっていた。 30FPSくらいまでしか出ず、スロー再生になる。

今ならAIがめんどくさいこともやってくれるんじゃないかという気がして再チャレンジ。

AIをしばく

とりあえず無料枠内でclaudeやらgithub copilotやらに指示を出しまくって改善をやらせた。「mednafenみたいに関数ポインタで分岐なくしてみて」とかやらせてみようとしたが、改造が大規模すぎるということで拒否される。多分無料枠内だと無理。（これをやらせたかったんだが。）

GRANDIA特化でSCUコードを埋め込ませたりして無理やり時間を縮めてみたが、45FPSくらいが限界そう。というかよく計算したらSCUの処理時間が0になってようやく60FPSが達成できるので、そもそも無理があった。

諦めてスレッドにする

SCUとCPU(SH2)は結構密接に絡んでいるらしく、それぞれ数サイクルずつ順番に処理していく動作となっている。これをSCUが遅いからと言ってそのままSCUを別スレッドにしてCPUと同期を取りながら進めると同期のコストで逆に激しく遅くなる。

もうシミュレーション精度はある程度切り捨て、完全に元コードの通り同期させるのは諦めて、ある程度のサイクル数まとめてスレッドで動かすようにした。（グランディアはそれである程度動くっぽい。）

1 フレーム分をまとめてしまうと、CPUがなにかSCUを待っているらしく、かなり遅くなってしまったので、適当に40000サイクルずつくらいSCUを動かすという感じ。もうめんどくさくなって動けばいいやという動きになっている。

スレッド間の排他とか何もやってないが、結構動いている。 もともとスレッド前提で書かれていたのか、たまたま奇跡的に動いているのか。

結果

AIをしばき回してチリツモで稼いだ時間と、スレッド化によってムービーが60FPSくらいで動くようになった。(https://github.com/tthogehoge/yabause/releases/tag/grandia)

苦節1年、なんとか遊べるようになった気がする。ただ、オープニングムービーとちょっとした戦闘くらいしかテストしてない。色々変えたので動かない箇所が出てくるかもしれない。コードの整理もできてないが、もはや疲れたのでおしまい。 めでたしめでたし。 

スタンドアロンでカメラ監視したい

誰も住んでない実家の草取りが面倒くさい。草が生え始めたくらいのときに除草剤を撒けば、ある程度マシになるかもしれない。が、誰も住んでないのでタイミングがつかめない。

一日一回でいいのでカメラで確認できるといいが、そのためだけにwifiやら電気を通すのは勿体ない。スタンドアロンでなんとかならないか。

とりあえずESP32マイコンでsimが使えそうなLILYGO T-SIM7080G-S3というのを見つけたのでやってみようとした。 

普通のSIMは使えない？

用途にちょうど良さそうってことでT-SIM7080G-S3を勢いで買ってしまったが、届くまでの間に検索しているとNB-IoT？とかCAT-M1？とやらで普通のSIMは使えないという話が見えてきた。

CAT-M1とかのSIMで探すと、1NCE?とかいくつか出てくるが、大半は業務用で、個人では契約できなそう。実質SORACOM一択なのではないかという気がしてくる。

7670Gとかにしておけばよかったのかも。微妙に高かったっから7080Gにしてしまった。致命的なミス。

SIMによっては使える？

まあ買ってしまったものは仕方ないので、試しに別件で買ったプリペイドSIMを入れてみたらなぜか動いた。普通にスマホで使っているbiglobeのSIMは動かなかった。期限切れになって新しく買ったプリペイドSIMも動いたので、IIJ-docomoのプリペイドはCAT-M1対応しているのかもしれない。金を無駄にする可能性があるので、他は試してない。

HTTP送信プログラム

書くのが面倒だったので、claudeに投げてみた。

• ESP32開発
• httpで送信
• wifiじゃなくてsimで
• tailscale使いたい 

これだけで割とベースは作ってくれる。課金してないので自動でログを読んで修正とかまではしてくれないが、ログを渡すと無課金でもかなりの部分を直してくれる。 

claudeは初めて使ってみたが、「DERPサーバー(tailscaleのサーバーらしい)のリージョンが違う？」とか「タイムスタンプがuptimeになっていてサーバーで無視されている」とか素人には分かりようもない原因をバンバン当ててくる。いや、すげーな。話題になるだけある。プログラマなんか不要になるというのも頷ける。課金したくなるのも分かる気がする。

ということでclaudeの無料枠を使い切ったらgithub-copilotを使って、という感じで作っていった。(https://github.com/tthogehoge/t-sim7080g-s3_tailscale_sample)

機能はざっくり以下の様な感じ。ほぼやりたいことはできた。

• カメラ画像をtailscale http postで定期的に送信
• tailscale http serverでカメラ画像確認
• tailscale http serverでOTA更新 

 microlinkについているhttpサーバにカメラ画像を入れただけ。

何か温度も表示されている。マイコンとSIMくらいしか見てないが割と70℃くらいまでは大丈夫そう？ 

消費電力は100mAちょいくらい、160くらいまでは行くこともある。5秒周期で2秒位100mA超えで高くて、残り低いときは30〜50mAくらい。多分eDRXとか言うやつで制御されてそう。

USBのソーラー電源を買ってきて、保冷箱とかに入れて日陰においておけば、何かいい感じになるんじゃないだろうか？なるといいが。 

ちなみにT-SIM7080G-S3は充電セルを入れるソケットもあってソーラー充電可能らしいが、火事になりそうでなんか怖いので入れない予定。 

あとは、半年ごとにプリペイドsimを入れ替えるのかSORACOMを契約するのかという問題が残っている。うーむ。

eSIM非対応の端末でeSIMを使いたい

 楽天の株主優待でeSIMがもらえるらしい。子供に持たせるスマホには良さそうだが、お下がりの古い端末ではeSIMは使えない。

eSIMをSIMに入れることができるアダプタみたいなものが売ってるようなので、使えるかどうか試した。

SIM geek

色々あるようだが、SIM geekとかいうやつを買ってみた。(写真は抜け殻。nanoSIMで使ったが、他のサイズでも使えそう。やってみた感じでは、テープとかで補強すれば再度組み立てることもできなくはなさそう。)

 

スマホに入れてこのsimの中身を書き換えるようだ。EasyEUICCとか言うアプリを推奨と書いてあったが、google playストアには無いようだった。直に入れれば良さそうだが、面倒だったので、かわりにそれを使った商品？の9eSIMとか言うやつ用のアプリがgoogle playストアにあったのでそれで入れてみた。

eSIMを使ってみる

eSIMは使ったこと無いので勝手がわからないが、とりあえず適当に一番安そうなやつを買ってみる。syesim?とかいうところのeSIMのようだ。amazonで発送済みくらいのステータスになったら（1日半くらい待った）、 activationのページで登録する。 

メールでQRコードが送られてくるので、9eSIMとかいうソフトで読んで追加する。

simフリー端末だったからか、APNは自動で設定されて通信できた。（メールに書いてあるAPNと違う設定だったんだけど、なぜか繋がったようだ）

後日封筒でも上記の説明書が送られてくるが、必要ない。

期限が切れたあと1日くらいは使えたような気がする。 

本当は楽天のeSIMで試さないと意味なさそうだが、とりあえずは良しとする。  

QtのQThreadとQTimerについて

QtつかっててQThreadとタイマー使ってると以下のエラーが出ることがある。

QObject::~QObject: Timers cannot be stopped from another thread

何がなんだか分からないまま闇雲になんとかしてたけど、なんか気持ち悪いので調べ直した。素人調べなので間違っているかもしれない。

QThreadの使い方

そもそもQThreadがどういうものなのか？調べた限りでは「slotで動かしたものがスレッドで動く」という仕組みのもののようだ。

class Worker : public QObject
{
/* 略 */
public slots:
    void exec();
    void exec2();
};

こんなのがあったとして、MainWindowから使う場合、

// worker作る
auto obj = new Worker();

// スレッドに移動
auto thr = new QThread();
obj->moveToThread(thr);
thr->start();

obj->exec(); // MainWindowのスレッドで動く
obj->exec2(); // MainWindowのスレッドで動く

// connect & emit
connect(this,&MainWindow::exec,obj,&Worker::exec);
connect(this,&MainWindow::exec2,obj,&Worker::exec2);

emit exec(); // Workerのスレッドで動く
emit exec2(); // Workerのスレッドで動く

emitでexec,exec2をslotで動かした場合にWorkerスレッドで動く 。execが終わるまではexec2は動かないようなので、同一スレッド内では通常は同時に動かないっぽい。

※ ただし、QEventloopでイベントを受け付けたりするとその限りではないようだ。QTcpSocketとかのwaitForConnect中とかでも他のスロットが動いたりした。内部でイベントループがあるのかもしれない。同時に動いて困る場合は念の為QMutexとかで排他したほうが良いだろう。

サンプルで、startedのsignalにconnectしたりしてるのをよく見る。下記の例だと単にthr->startを実行する時にexecも実行するというだけでしかない。

ちなみにobj->quit()したときにスロットを実行するsignalでfinishedというのもある。
以下だとexecは2回動く（はず）。

connect(thr, &QThread::started, obj, &Worker::exec);
connect(thr, &QThread::finished, obj, &Worker::exec);
thr->start();
thr->quit();

QThreadを継承する場合

WorkerをQThreadの子クラスにするやり方もあるようだが、上記の使い方だとそんなに違いはない。

class Worker : public QThread
以下略

// worker作る
auto obj = new Worker();
// スレッドに移動
obj->moveToThread(obj);
obj->start();

obj->exec(); // MainWindowのスレッドで動く

// connect & emit
connect(this,&MainWindow::exec,obj,&Worker::exec);

emit exec(); // QThreadのスレッドで動く

QThreadを継承しても、moveToThreadするまではMainWindowのスレッドで動くっぽい。moveToThreadしないとQThreadの意味はない。上記はMainWindow側でmoveToThreadをやっているが、Workerのコンストラクタでやっても良さそう。

この使い方なら別でスレッドオブジェクトを作らなくていいくらいしか違いはなさそうだが、runをオーバーライドする場合は違いがある。

class Worker : public QThread
{
/* 略 */
void run() override;
};

この場合はthr->start();するだけでrunが実行され、関数終了でsignal finishedが発行される。よく見る例で便利そうに見えるが、run以外の処理を実行するにはQEventloopを使わないといけない。関数一つだけ別スレッドで動かすやり方のようだ。関数一つだけのためにクラスを作らないといけない。こういう用途だとQtConcurrent使ったほうが簡単じゃないのか。個人的にはあんまり実用的じゃない気がする。

QThreadでタイマーを使うとき

さて、このQThread上でタイマーを使おうとしたとき、 「Timers cannot be stopped from another thread」と出てきて、なんでだよこのクソ野郎が！と思うことが稀によくある。

以下のような場合だ。QtのタイマーはQObjectに備え付けのstartTimer/killTimerとQTimerのstart/stopを使ってみている。

class Worker : public QThread
{
    Q_OBJECT
    QTimer mtimer;
    int m_id;
    void timerEvent(QTimerEvent *event) override;
public slots:
    void exec();
/* 略 */
};

Worker::Worker(QObject *parent)
    : QThread{parent}
{
    m_id = startTimer(200);
    connect(&mtimer,&QTimer::timeout,this,&Worker::exec);
    mtimer.start(200);
}

Worker::~Worker()
{
    mtimer.stop();
    killTimer(m_id);
}

MainWindowから以下のように使う

    auto obj = new Worker();
    obj->moveToThread(obj);
    // start thread
    obj->start();
    QThread::msleep(1000);

    // end
    qDebug() << "stop thread";
    obj->quit();
    obj->wait();
    qDebug() << "delete worker";
    delete obj;

deleteするときにmtimerは止められるが、killTimerはエラーになる。 逆にQThread上でタイマーを止めようとするとmtimerは止められず、killTimerは止められる。mtimerはWorkerのスレッドではなく、コンストラクタを動かしたMainWindowのスレッドで動いているということになる。

moveThreadでobjはQThreadに移動されたが、その中のmtimerは移動してくれなかったということだ。 

MainWindowからしかstart/stopしないという使い方の場合はむしろこのままmtimerを使うというのでも良いのかもしれないが、以下のようにmtimer作成時に親を自分に設定すると、moveThreadのときに一緒に子どもであるmtimerも動いてくれる。
そうでなければコンストラクタを動かしたMainWindowが親になってしまう。

Worker::Worker(QObject *parent)
    : QThread{parent},mtimer(this)
{
/* 略 */

これでスレッドの中ではstart/stopができるようになるが、やはりデストラクタでは止められない。むしろkillTimerもmtimer.stopも両方NGになる。

結局はこれらもデストラクタでストップするのではなく、スレッドの中で止めなければならないということだ。停止するslotを作成し、slotで止めてからdeleteすれば問題ない。

    connect(this,&MainWindow::kikktimer,obj,&Worker::killtimer);
    connect(this,&MainWindow::mtimer_stop,obj,&Worker::mtimer_stop);

    // stop timer
    emit mtimer_stop(); // タイマーを止めるslot
    emit killtimer(); // タイマーを止めるslot
    QThread::msleep(1000);

    // end
    qDebug() << "stop thread";
    obj->quit();
    obj->wait();
    qDebug() << "delete worker";
    delete obj;

runをオーバーライドしている場合はイベントループとか使わないと別のスロットを動かせない。何かフラグを立てて、run関数の中で止めるか、finishedシグナルでrun関数が終わったあとに何とかするしかない。 

finishedで後始末 

runをオーバーライドしているとか、面倒くさいからスレッドが終わったら止まれよ。という人向けにfinishedシグナルがあるんだろう。finishedでタイマーを止める。

    connect(obj,&QThread::finished,obj,&Worker::killtimer);
    connect(obj,&QThread::finished,obj,&Worker::mtimer_stop);
    // end
    qDebug() << "stop thread";
    obj->quit();
    obj->wait(); // この辺でタイマーが止まる
    qDebug() << "delete worker";
    delete obj; 

終わったらdeleteもやれよという人にはdeleteLaterがあるが、ちょっと罠がある。 

    connect(obj,&QThread::finished,obj,&Worker::killtimer);
    connect(obj,&QThread::finished,obj,&Worker::mtimer_stop);
    connect(obj,&QThread::finished,obj,&Worker::deleteLater);
    // end
    qDebug() << "stop thread";
    obj->quit();
    // obj->wait(); // これやると死ぬ

obj->quit()した時点でkillTimer/mtimer_stop/deleteがWorkerスレッドのタイミングで始まる。MainWindowスレッドのobj->waitしている間にdeleteまでされるので、obj->wait実行中にobjが消えることになる。finishedでdeleteLaterを呼ぶ場合はquitしたらもうobjには触ってはいけないということだろう。 

一回スタートしたらあとはsignal/slotで自動で消えてくれる。Qtをうまく活用した処理と言えるけど、個人的にはスレッドが終わるのを確認しないと気持ち悪いし、ちゃんと自分でdeleteしないと気持ち悪いんだけどな。