最近の出来事

2025/11/02

AM中に起床。

掃除したり。

そういえば Emacs31系はまだmasterから分岐はしていませんが いつ出す予定だろうか？

Qwen3-VLで画像の内容ではなくフォーマットについて尋ねたところ、なんだかモンヤリした推測交じりの 回答が返って来たり。恐らく画像認識にはデコード済の状態で渡されるので、デコード前のフォーマットに ついては知りえないという事なのだろうと思われます。「仕組み的に元の画像ファイルフォーマットは判らない」と 回答してくれれば良いようにも思うのですが、何やら頑張って推測するようです。

先日アップデートした新しい gptelのチャットでは回答結果に「#+begin_reasoning ～ #+end_reasoning」というブロックが 表示されるようになっているようです。推論の過程が表示されているようで、これらを踏まえて回答結果が表示される という感じになっているようです。gpt-oss:20bでは割とあっさりとした内容ですが、 qwen3:30bでは割と長めの(場合によっては最終的な回答よりも長い)自問自答を行っているようです。 英語で表示されていますが、HTMLにエクスポートしてChromeで表示してページ翻訳すると人間にも意味が判るように 推論していて面白いなぁと思いました。画像認識の場合は色々推論して間違えてるってパターンもあるようです😓。 さておき、reasoningブロックは HTMLにエクスポートすると非表示にはできないので、 回答結果を読むのに邪魔になる場合があります。カスタム変数 gptel-include-reasoning を nilに設定すると reasoningブロックは出力されなくなるようです。

qwen3の推論(reasoning)の中でEmacsユーザーである可能性について触れられている事があったので 「なんで分かるんだ？🤔」と思ったのですが、gptel-directives という変数の中で 「(default . "あなたはEmacs上で動作する大規模な言語モデルで、役立つアシスタントです。詳しく教えてください。")」 って記してあるからっぽい。 言ってなければ判る訳が無いので、判っているという事はどこかで言っているって事になるのかなと思います。 これって対人の時は逆の方向で気を付ける所かも。 直接会話ではない公開チャットのようなもので言ったつもりになったところで、 それをみんなが読んでいるとも 意図通りに解釈しているとも 限らないってのはよくある事です😓。

AM中に起床。

Ollamaのv0.12.7というアップデートが来ていたのですが(ついさっき見たらv0.12.8が出てましたが😅)、 Qwen3-VLというモデルを使用可能になったらしい。 どんなモデルなのかと思って調べてみたら画像も認識できるらしいというのを知り試してみたり。 話は一瞬逸れますが モデルのファイルサイズってダウンロードしてみるまで判らないのだろうか？🤔 さておき、適当に試しながらダウンロードしてみたところ 以下のようなサイズのようです。

$ ollama list
NAME            ID              SIZE      MODIFIED
qwen3-vl:8b     901cae732162    6.1 GB    7 hours ago
qwen3:30b       ad815644918f    18 GB     7 hours ago
qwen3-vl:30b    eda0be100877    19 GB     8 hours ago
gpt-oss:20b     17052f91a42e    13 GB     2 weeks ago
gpt-oss:120b    f7f8e2f8f4e0    65 GB     6 weeks ago

テレワーク。早めに終了。

調べ事。

テレワーク。早めに終了。

GoogleのDoodleがハロウィン仕様のパックマン。ハロウィンは判るのですが何故パックマン？ と思ったところ、1980年の稼働(日本では7月、アメリカでは10月26日)から45周年という事らしい。

テレワーク。早めに終了。

先日のorg-modeで attachment: のファイルがHTMLエクスポートすると絶対パスになる件。 expand-file-nameで展開しているというのもあるのですが、他にも絶対パスになっている事をチェックしているようで、 ちょっと弄れば相対パスにできるという感じでは無さそうだったり。LaTeXの式をレンダリングした画像と 同じような扱いなのかと思いきや全然扱いが違ってて挫けました😓。

テレワーク。早めに終了。

調べごとをして終了。

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

AM中に起床。

掃除したり洗濯したり。

現在開発中の Emacs31系のWindows向けビルドでは yank-media というクリップボード画像の貼り付けがサポートされる予定です。 org-modeでは貼り付けに対応しているのですが、.orgファイルに貼り付けた後にHTMLにexportすると 画像のリンクが expand-file-name で展開された絶対パスになってしまいます。 Cygwinビルドでは ewwで見るのは大丈夫ですが、EdgeやChromeなどの外部ブラウザを使用すると ファイルパスがCygwinパスになっている為、画像が表示されないという事が起こっています。 クリップボードから貼り付けた画像はデフォルトでは.orgファイルと同じディレクトリの dataという ディレクトリ内に保存されます。 画像の参照は「[[attachment:clipboard-20251026T121446.png]]」のような感じで、attachment:という 特別なキーワードと clipboard-yyyymmddThhmmss.* という形式の自動生成名から成り、 途中のパスは何かしら自動生成されるハッシュ値的な物(UUIDっぽくも見える)を使用しているようです。 HTMLにexportする際に 相対パスで「src=./data/.../clipboard-...」と記してくれれば良いのですが、 色んなところで expand-file-name で展開した絶対パス名を使用しているようです。 また、設定値の書き方とかで対応できる感じにもなっていないようです。 CygwinパスとWindowsパスの違いの問題もありますが、そもそも絶対パスだと 画像ファイルの置き場所を移動すると 表示できなくなってしまうし、公開Webページとしてアップロードしてもリンク切れになってしまうなど、 デメリットしか無いように思われます。なんとかならないっすかね？とは思ったりも。

minibufferでファイルパス名に文字「?」を入れようとしたら minibuffer-completion-help 実行にバインドされているなぁ？ と思ったり。以前シェルのglobstarなるものを知り、 時々find-diredの代わりに使う事があるのですが、正規表現を少し細かく「**/*.??g」のような指定をしたい と思ったところ、文字「?」が入れられないので気づいた次第。 .emacsに「(define-key minibuffer-local-completion-map "?" nil)」を記して無効化する方向で。

AM中に起床。通院。

Web巡回していたら、PlemolJPのv3.0.0が 今年の6月29日に出ていたというのに気づいたり。 元になっているIBM Plexの「IBM Plex Sans JP」 がv2.0.0になったのに追従したアップデートだった模様。グリフが大量に追加されているらしいですが、 異体字セレクタに対応している訳では無さげ。 因みに、IBM Plex Sans JP の方はv3.0.0が今年の9月2日に出ているようです (Releases @ibm/plex-sans-jp@3.0.0)。 また、IBM PlexはGoogle Fontsでもダウンロードできるように なっているっぽいですが、v1.001なのでちょっと古いのが置かれているようです。

テレワーク。早めに終了。

Emacs30.2で zlc-modeの補完がうまく動いていない件。 29.4の lisp/minibuffer.el を読み込むと解消したので、30.2との差分を調べてみたところ、 なにやら余計なテキストプロパティが追加されるようになっているようです。 以下のようなパッチでひとまず機能するようになりましたが副作用があるかも知れません。

$ diff -u lisp/minibuffer.el.orig  lisp/minibuffer.el
--- lisp/minibuffer.el.orig     2025-03-15 22:19:26.000000000 +0900
+++ lisp/minibuffer.el  2025-10-24 19:31:05.140339100 +0900
@@ -703,12 +703,12 @@
                    ;; on the first character of the completion.  Make
                    ;; sure the quoted completion has these properties
                    ;; too.
-                   (add-text-properties 0 1 (text-properties-at 0 completion)
-                                        qcompletion)
+;                   (add-text-properties 0 1 (text-properties-at 0 completion)
+;                                        qcompletion)
                    ;; Attach unquoted completion string, which is needed
                    ;; to score the completion in `completion--flex-score'.
-                   (put-text-property 0 1 'completion--unquoted
-                                      completion qcompletion)
+;                   (put-text-property 0 1 'completion--unquoted
+;                                      completion qcompletion)
                   ;; FIXME: Similarly here, Cygwin's mapping trips this
                   ;; assertion.
                    ;;(cl-assert

$ echo test_message > test.txt

$ ls -l
合計 1
-rw-rw-r-- 1 TANE-HP なし 13 10月 24 22:23 test.txt

$ /usr/bin/diff -u -N test.txt.orig test.txt
--- test.txt.orig       1970-01-01 09:00:00.000000000 +0900
+++ test.txt    1970-01-01 09:00:00.000000000 +0900              ★★★★日付が変
@@ -0,0 +1 @@
+test_message

$ /usr/bin/diff -v
diff (GNU diffutils) 3.12
Packaged by Cygwin (3.12-1)
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

$ ~/develop/work/diffutils/diffutils-3.8/src/diff -u -N test.txt.orig test.txt
--- test.txt.orig       1970-01-01 09:00:00.000000000 +0900
+++ test.txt    2025-10-24 22:23:11.567447100 +0900              ★★★★ファイルの日付通り
@@ -0,0 +1 @@
+test_message

$ ~/develop/work/diffutils/diffutils-3.8/src/diff -v
diff (GNU diffutils) 3.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

テレワーク。早めに終了。

Emacs30.2で zlc-modeの補完がうまく動いていないのに今頃気づきました😓。 以前、31系では上手く動かなくなっているというのに気づいて lisp/minibuffer.el の方を対応するしかないなぁという事があったのですが、 その時の「候補文字列のテキストプロパティが無くなっていて、余計な文字列が補完される。」が 30.2でも起こっている予感。と思ったのですが、 テキストプロパティの中に変なプロパティが含まれているのが原因のようです。なんだこれ？🤔 29.4では大丈夫そうで、上手く動くようにした31系と同じテキストプロパティが返っているみたい。 30系で壊れてる感じになっていた模様。

テレワーク。早めに終了。

今更ですが、bashの入力キーバインドに「C-/」でUndo ができるのを知りました。 因みにEmacsスタイルです。今まで押し間違いで存在に気づいたことは無かったので、 コマンドライン編集でUndoを期待するようなことは無かったのだと思いますに、 個人的にはあまり使う場面は無いかも知れません。

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

AM中に起床。

掃除したり洗濯したり。

Emacsのキーボードマクロの中に isearchで W32-IMEから文字を入力するという要素を含めると うまくマクロ実行できないのを調べたり。キーボードマクロを調べると、 なにやら「with-keyboard-coding」というのが記録されていて、 ./lisp/international/isearch-x.el の中でそのキーコードを受け取ったら 関数isearch-with-keyboard-coding を実行するような事が記されているのですが、そもそも「with-keyboard-coding」というキーが どこに定義されているのか判らなかったり。どういう事？🤔

AM中に起床。

ちょろり買い物にお出かけ。

あまり数がある訳では無いのですが、使用済みのボタン電池を回収してもらおうと持ち込んだ所、 雑にマスキングテープで包んでいたので穴に入らず一旦断念。それにしても資源ゴミ回収では コイン型のリチウム電池(CR2032とか)は回収OKらしいのですが、一般的にもよく使うと思われる LR44とかは回収しないというのがよくわかりません。
ボタン型電池を資源ゴミで回収しないのなんでだっけ？と調べていたところ、 川崎市では 2025年11月からリチウムイオン電池などの二次電池も回収するようになるのを知ったり (川崎市ページ)。 髭剃りなどは分解不要で回収してもらえるようです。ありがたや。 で、ボタン型電池は水銀を含む場合があるので回収しないという事みたい。 水銀フリーなボタン電池も存在するのですが、見た目で区別がつかないのでダメっぽい。

カラーシャープ芯。先週買った水色は薄すぎたので、 赤と青を購入してみました。色んな色入りってのもあったのですが、0.7mmのが無かったので試せず。 ついでにもう一本0.7mmのシャープペン本体も購入。今回買ったのは300円でまぁ普通。 赤も青も想像した通りの色の濃さだったので、あまり色分けすることはありませんが普段使いしてみようと思ったり。 それよりもシャープペン本体の色が 白と青で、白の本体は重いので青の本体をよく使うだろう色に した結果、青の本体に赤芯、白の本体に青芯 を入れました。が、絶対に一回は思ったのと違う色の方を選んで 「あぁ...💦」ってなる気がします😓

Emacsの テーマのカスタマイズメニューでは、チェックボックスの描画は絵文字フォントではなくて 画像で表示されています。何気に masterブランチ(31.0.50相当)のEmacsで表示しているのを見ると なんだかズレた位置にレンダリングされた画像になっているなぁ？と思ったり。 30.2ではそんな事になっていないので、何が違うのか調べようと思ったのですが、 どこで画像を選んでレンダリングして表示しているのかよく分からず。
どうやら lisp/wid-edit.el でwidgetとして管理されるっぽい。なのですが表示の実体は SVG画像を create-imageやinsert-imageでレンダリングしているようです。さておき、以下のような感じに見えます。

• 30.xではフォントのサイズによらずレンダリングされる画像のスケールは一定。 この為、「C-x C-+」(text-scale-adjust)でフォントを大きくしても画像のサイズはスケールしません。
• 31.xではフォントサイズに応じてレンダリングされる画像もスケールする。 この為、「C-x C-+」(text-scale-adjust)でフォントを大きくするとレンダリングされる画像も スケールしているのですが、描画領域が広がっていない為、描画領域外にレンダリングされている模様。 レンダリング位置もズレていて :ascent プロパティで位置調節してもズレている。

テレワーク。気持ち早めに終了。

そういえば先日知った超連射68kの Ver1.10 って、いつ頃出ていたのかしら？ と思い調べてみたり。 超連射68kのページには 特に明記は無さそうで、クレジットは「©1995 1998」となっていたので、その頃に出ていたのかな？ と思ったわけですが、ゲーム本体が X68000用の xdf形式で置かれていたので、エミュレータでxdfの中を 見てみたところ、CRS68K/DOC/readme.txt に 散逸していたソースとデータを2021年頃からサルベージした 事が記されていました。全てのファイルの日付が「2023-01-01 00:00」になっていたので、 それくらいにビルドされたのだろうと想像します。 Wikipedia によると、X68000 Z EARLY ACCESS KITに 同梱されていたようで、正確なリリース日は分かりませんが 2023年4月頃だったのだろうと思われます。 という訳で、Ver1.10が出たのは 2023年なので、約27年間気づかなかった訳では無い (2年くらいは気づいてませんでしたが😅)という事でした。

背景グラフィックが変わっていたりするのですが、リプレイデータは互換があるという事で、 大昔に草の根BBSで知り合った めっちゃシューティングゲームの上手い方の ウルトラ超絶プレイの リプレイデータを食わせてみたところ ちゃんと再生されました。

テレワーク。気持ち早めに終了。

Web巡回して終了。

テレワーク。気持ち早めに終了。

Windows Update。Emacsのハングテストを継続していたのを一旦終了させて Update後にテスト再開。

テレワーク。早くもなく遅くもなく終了。

全然関係ない流れで見つけた 「【X68000】超連射68k Ver1.10【エンディングまで】」 という動画。ん？エンディングって何？と思って最後の方を観てみたところ、ラスボス倒した後に見たこと無い映像が。 そういや背景画像も見たことない感じになっていて、TANEが知ってるのはver1.00(SZ2.Xの日付は97-12-28 19:57) だったというのに今頃気づきました😅。

AM中に起床。

NHK総合で「大阪・関西万博閉会式」を放送していたのをBGVで観たり。 結局GoogleEarthでは完成版は見られるようにならなかったですが、GoogleMapの航空写真は完成版になっていたようです。

そういえばGoogle検索で期間指定ができますが、終了日を過去に指定して古い情報を探そうとしてみたのですが、 フィルターが効いていないような気が。

AM中に起床。

掃除したり。

ちょろり買い物にお出かけ。「これ描いて死ね(8)」捕獲。 気にはなっていた「カラーのシャープ芯」をどんなもんかと試しに購入。0.5mmのもあったのですが 0.7mmを選択。でも0.7mmのシャープペン本体は持っていないので本体も購入。 値段を見ていなかったのですが、シャープペンの方が825円だというのに後で気づいて驚いたり😅。 なんでこんなに高いんだ？と思ったのですが、振ると芯が出てくる機構が付いているものだったらしい。 でも手持ちの他のシャーペンは普通のなので振る機構は多分使わない😓。

カラーシャープ芯。水色を買ったのですが色が薄いな。下書きを消さなくても印刷に出ないという利点が あるようですが薄くてよく見えない😅。他の色も試してみたくなりました。

AM中に起床。

そういえば gpt-ossのモデルって更新されてたりするのだろうか？と思い、 ollama pull してみたところアップデートされたり。pullできるという事は何かしら変わっているという事なのかしら？ 「ollama show -v gpt-oss:20b」でモデルの情報を表示してみても、 モデルのバージョンに関する情報は含まれていないようなので、いつ時点のモデルを使用しているか？は判らない予感。 因みに ollama list で出てくる MODIFIEDは pullした時点からの経過時間を示しているので、モデルが更新された 日時が判れば pullした日付と合わせてどの時点のモデルを使用しているかを判別できるかも知れません。

テレワーク。早くもなく遅くもなく終了。

CygwinパッケージのImageMagickが更新されていたので、インストールする前に同じバージョンで 野良パッチの確認をしたり。HEICフォーマットの色化けはバージョンアップで直る予定だったので そちらのパッチは不要になりますが、透明度付きグレースケールのTGAフォーマットは野良パッチとして 引き続き取り込む感じに。
で、ImageMagickをインストールしようと思ったところ、Cygwin本体も 3.6.5-1 が出ていたので、 インストール前に git pullでログの確認をしたり。pull前から2つの修正が追加されていたのですが Emacsハング修正には関係していなさげ。インストールしてみて一応ハング再現するか少し様子を見る方向で。 因みに gdb上でemacs-w32を動かすと謎のSIGTRAPが発生するのは変わりないようです。 後、先週から実行していたEmacsハング回避パッチの様子見では 約1週間 Emacsハングは再現していませんでした。

いくつかEmacsを立ち上げてパッケージオリジナルの Cygwin3.6.5-1 でハング再現の様子を見てみたのですが、 数時間でハング再現しました🥺。仕方ないのでワークアラウンドパッチを当てて野良ビルドしたcygwin1.dllと 入れ替えて様子見開始。まぁ大丈夫だろうと思いますが。

テレワーク。気持ち早めに終了。

調べごとをして終了。

テレワーク。早くもなく遅くもなく終了。

GIMP 3.0.6がリリースされているのに気づいたり (GIMP 3.0.6 Released)。 ちょろっと触った感じでは特に問題無さげ。安定してきている気も。

テレワーク。早くもなく遅くもなく終了。

全く気付いていなかったのですが、magitでの「Tracked files」表示が途中までしか出てないようだったり。 以前、gptelを試すために Transientを更新した後、 magit-20250912.1136ではダメになっている箇所があったので、magit-20230410.857に更新しました。 以前のmagitではディレクトリの中は非表示の状態になっていて、展開したり折りたたんだりできたのですが、 現在のではサブディレクトリのファイルも含めて全て表示しようとしています。 しかし、100までしか表示されていない為、トラッキングしているファイルを探す事ができなくなっています。 なんだこれ？🤔
どうやら カスタム変数magit-status-file-list-limit てのが新しく定義されているようで、 この値がデフォルトで100になっている模様。ここを20000とかに設定すれば 5000以上のファイルがある Emacsのリポジトリでもトラッキングしている全てのファイルを表示できました。 「Tracked files (xxxx)」の行で TABキーを押せば展開したり折りたたんだりできるので、 全部表示するか 全く表示しないか の二択という感じになるようです。なぜ 操作仕様を変えたのかは不明。 パフォーマンスを理由にしているみたいですが、中途半端なリストを出されても役に立たないし、 リストが必要な人は パフォーマンスを理由にして リストの取得を諦める訳が無いと思います。 考え方が理解できません。

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

Windows11の「ペイント」ってレイヤーを使えるようになってたのか。AI補助とか何気に色々変わっているっぽい。

AM中に起床。

掃除したり洗濯したり。

ちょろり生活備品の調達。本屋に寄ったところ「アオイホノオ(32)」が置かれていたので捕獲。 31巻はなかなか捕獲できず (1, 2, 3, 4)、死に筋判定されているのか？と思ったのですが、置かれてたので タイミングの問題だったのか？と思ったりも。ただ、書棚には30巻はあるのに31巻は無かったので やっぱり31巻には何かあるのかも知れない😅。

AM中に起床。

ノートPCで継続していたCygwinパッチの確認。合計で約3週間(478時間) 3つのEmacsを動かし続けて ハングしなかったのですが、先日副作用が見つかったので 一旦確認は終了。

Emacsハング対応のCygwinパッチ再考。 前のパッチは SIGALRM の場合は処理を完全にスキップするような感じでしたが、 スレッド数が1の場合は発動しないという条件を追加してみたり。 元々、複数のスレッドでロックが競合した場合に、何故かスレッドが切り替わらない為に ロックループがいつまでも脱出できないという動きになっていそうな感じでした。 ロックされていた場合はスキップするみたいなコードを入れてみたものの、 ロック状態確認とロック実行の間の時間を理論上0にする事ができない為、ハングしにくくはなるものの 完全対応にはなりませんでした。そこで、ダメもとで SIGALRMの場合は処理を完全スキップする としてみたところ(以前のメモ) Emacsはハングしなくなったのですが、 先日の alarm() を使ったコードでは SIGALRM が無限に保留される事となり影響があるのが分かった... という流れです。 で、そもそもシングルスレッドでは ロック競合は起こりえないハズなので、 最初に記した通りスレッド数が1の場合は発動しないという条件を加えてみたらどうか？ と思った次第です。ワークアラウンドとは言え、 ひとつ前のコードと同様に「このパッチ、意図が分からん」に 拍車をかけている感は否めません😓。

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
       if (!inside_kernel (cx, true))
        {
          HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
-         cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+//       cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
          SetThreadContext (*this, cx);
          suspend_on_exception = true;
          in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..799476e1f 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
   while (++ix < (int) nthreads)
     {
       /* Only pthreads have tid set to non-0. */
+      if (nthreads!=1 && (sig==14 || threadlist[ix].thread->locked () != false))
+       continue;
       threadlist[ix].thread->lock ();
       if (!threadlist[ix].thread->tid
          || !threadlist[ix].thread->initialized)

テレワーク。気持ち早めに終了。

先日のCygwinパッチの副作用。configureでの検査の中で、以下のコードが終了しないという 感じになっていました。

     1  #include <errno.h>
     2  #include <unistd.h>
     3  #include <signal.h>
     4  static void
     5  handle_alarm (int sig)
     6  {
     7    if (sig != SIGALRM)
     8      _exit (2);
     9  }
    10
    11  int
    12  main (void)
    13  {
    14
    15      /* Failure to compile this test due to missing alarm is okay,
    16         since all such platforms (mingw, MSVC) also lack sleep.  */
    17      unsigned int pentecost = 50 * 24 * 60 * 60; /* 50 days.  */
    18      unsigned int remaining;
    19      signal (SIGALRM, handle_alarm);
    20      alarm (1);
    21      remaining = sleep (pentecost);
    22      if (remaining > pentecost)
    23        return 3;
    24      if (remaining <= pentecost - 10)
    25        return 4;
    26      return 0;
    27
    28    ;
    29    return 0;
    30  }

テレワーク。早めに終了。

何気に以前作成したdiffの -y のカラーパッチを 新しい diffutils-3.12 に対応してみたり。ところがconfigure実行で sleepのテストがいつまで経っても終わらず。 むむ、これはEmacsハングに対応する Cygwinへのパッチが 影響している気が。configure内で実行しているテストコードを切り出してコンパイル＆実行してみたところ、 確かにいつまで経っても終わらないのですが、Ctrl-Zでバックグラウンドに切り替えてbgで実行継続すると 先に進むようだったので、本題のdiffutilsのconfigureはそれで進めたり。 ひとまずパッチ(diff-y_coloring_patch-3.12.diff.xz) を置きます。御参考まで。

Cygwinパッチの副作用が見つかったので 対応を考え直す必要があるなぁ....🤔

テレワーク。気持ち早めに終了。

調べごとをして終了。

テレワーク。早めに終了。

Web巡回して終了。

テレワーク。気持ち早めに終了。

デスクトップPCのFirmwareアップデートが来ていたので適用してみたのですが、 「Intel TBT Retimer」なるもののアップデートがFailします。数週間前にもFirmwareアップデートが来ていたので、 適用してみたのですが、その時も同じようにFailしていました。 なんかアップデートできない状態にハマっている模様。 意図的に再度アップデートの有無を探して適用する方法が分からないので、 また自動チェックでアップデート通知が来るのを待つしか無いのか？むーん🤔。

BIOS(というかUEFI)メニューを見てみたところ、SystemLogにFailが記録されていたり。 前回失敗していたのは2週間くらい前でした。ただ、Failした事しか記録されていなくて、 何がFailしたかは記されていませんでした。 ところで Intel TBTってなんぞ？と思ったのですが、メニューに「Intel Turbo Boost Technology」の 項目があったのでこれなのか？と思ったものの Enable/Disableにするスイッチしか無いのでよく分からず 設定はそのまま。
特に得られる物は無さそうだったので、Windowsを起動して調べてみたのですが、 どうやら「Intel Thunderbolt Retimer」というパターンもあるようで、Retimerの文言から察するに TBTは「Turbo Boost Technology」じゃなくて「Thunderbolt」のような気がしてきたりも。 他社製のマシンでもアップデートに失敗するような例があるようですが、 USB-typeCに何か繋いでいると影響あるかも？(ただそのコメントに対するリアクションは「改善せず」でしたが) というので 一理あるかもな？と思ったりも。 液タブ用にUSB-typeCにケーブルだけ刺していたのですが、 また忘れた頃にアップデートが来るかも知れないので、ケーブルを抜いておく事にしたり。どうなるか？

AM中に起床。

掃除したり。

先週に引き続き Cygwinのパッチに更に手を加えて Emacsハングの再現確認を 継続しています。ノートPCで合計2週間(336時間) 3つのEmacsを動かし続けてハングしていないので、 パッチの効果としては問題無いだろうと思っています。 また、普段使いのデスクトップPCにも適用して1週間経ちますがこちらも問題は無さげ。

そういえば、HP-UXって x86系で動作するのだっけ？と思って調べていたら、HP-UX自体が2025年12月末を以って サポート終了らしいのを知ったり(参考Wikipedia)。 PA-RISCから Intel Itaniumへと移行した後、Itaniumは2021年に製造終了となってました。 CPUと一緒にOSも店じまいという感じみたい。因みに、TANE自身は使ったことはありません😅。
過去の日記を検索してみると、10年くらい前にデバッガのGDBの 7.10で「HP/PA running HP-UX (hppa*-*-hpux*)」と「Itanium running HP-UX (ia64-*-hpux*)」の サポートを外したという話を記していましたが、 このときは「x86_64-*-hpux*」はあるのか？というような事は調べていませんでした。 結局、x86_64への対応は無いようなので、GDBでは事実上「*-*-hpux*」のサポートを外したのと等価だったようです。

AM中に起床。

自転車の引き取り。駆動系が新品のためかペダルがめっちゃ軽い😅。 旧車購入から今回の新車の買い替えまでの17年間で自転車も進化しているのだろうか？

唐突にNAS-HDDを新規購入にお出かけ。6TBで約40000円也。 不思議なことにNASは8年前に購入したものと比べても 容量当たりの単価が変わっていない、なんならちょっと高いくらいという相場のようです。 一般的には「クラウドストレージで十分」という考え方もあるかと思いますので ニッチなのかも知れませんが、NASではないSSDやHDD単品の容量当たりの単価の 感覚だと「なぜこの価格？」と思ってしまうところはあるかもしれません。

置き場を整理してNAS-HDDを稼働。設定などを一通り行ってひとまず使える感じに。

テレワーク。気持ち早めに終了。

調べごとをして終了。

テレワーク。気持ち早めに終了。

何気にOllamaって更新頻度が高いなぁ？と思ったりも。

テレワーク。早めに終了。

調べごとをして終了。

AM中に起床。

タスクバーの右の方にウィジットなるボタンがあります。天気の表示が主な目的で表示ONにしているのですが、 マウスカーソルをかざすとニュースが表示されます。表示されている見出しをパッと見る感じ、 いつもテレビが元ネタと思われるものが多いなぁ？とは思ったりも。 記事の元ネタを書いている人の世代は分かりませんが、テレビっ子であることに違い無い気がします。勝手な憶測ですが。

10月13日で大阪・関西万博は閉幕となりますが、GoogleEarthの写真は建設途中のままだなぁと思ったり。 以前にも記した通り、大屋根リングは撤去予定なので 意図的に撮影しない限りは開催期間中の状態をGoogleEarthで見ることはできないかもなぁ？とは思ったりも。

何気にgptel(gpt-oss:20b)で「「やなせたかし」という人物について教えて」と聞いてみたら、 色々出てきたのですが、アンパンマンのアニメ化について 「1975年に日本テレビがアニメ版を制作。全国のテレビで毎日放送され、...」 と記されていて、何と間違えているんだ？🤔と思ったりも。 因みに少し前に調べた時には、 アニメ放送開始は1988年10月3日 という事でした。

何故かWikipeiaで、年に対応したテレビアニメの一覧が出せるようだったのですが、 1988年だと「Category:1988年のテレビアニメ」という感じみたいです。 テレビ神奈川(TVK)で日曜夜に再放送されている「美味しんぼ」のアニメ放送開始も1988年なんだっけ？ と改めて思ったりも。

テレワーク。早めに終了。

Web巡回して終了。

AM中に起床。

掃除したり洗濯したり。

丁度一週間前からCygwinのパッチに更に手を加えて Emacsハングの再現確認をしていました。 ノートPCで一週間(168時間)、3つのEmacsを動かし続けてハングしなかったので、予想通りの動きにはなっているようです。 ノートPCでのテストはそのまま続けるとして、デスクトップPCにも適用して普段使いでEmacs以外に影響が及ばないか？ を確認してみる事に。因みに、デスクトップPCの方でも9月9日からパッチを当てて 普段使いで様子見していたのですが、こちらではハングが発生する事はありませんでした。 gptelを使う為に再起動したので連続実行という点ではせいぜい一週間といった所ですが、それでも image-diredを使ったり数個起動したりするのに比べるとハング遭遇確率は大分低いという感じだったのかも。

という訳で以下のパッチをCygwinに当ててデスクトップPCでもハング再現テスト開始。 と言っても再現はしないハズなので影響確認ですが。

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
       if (!inside_kernel (cx, true))
        {
          HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
-         cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+//       cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
          SetThreadContext (*this, cx);
          suspend_on_exception = true;
          in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..3248813e2 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
   while (++ix < (int) nthreads)
     {
       /* Only pthreads have tid set to non-0. */
+      if (sig==14 || threadlist[ix].thread->locked () != false)
+       continue;
       threadlist[ix].thread->lock ();
       if (!threadlist[ix].thread->tid
          || !threadlist[ix].thread->initialized)

commit b57c6c013bf0899d3b39048bfb7e46197a0a9689
Author: Takashi Yano <takashi.yano@nifty.ne.jp>
Date:   Sat Jun 7 17:00:35 2025 +0900

    Cygwin: signal: Enable the signal mask earlier

    Currently, _cygtls::sigmask is set in call_signal_handler(), but this
    is too late to effectively prevent a masked signal from being armed.
    With this patch, deltamask, which is set in _cygtls::interrupt_setup()
    in advance, is also checked as well as sigmask to determine if the
    signal can be armed.

    Fixes: 0d675c5d7f24 ("* exceptions.cc (interrupt_setup): Don't set signal mask here or races occur with main thread.  Set it in sigdelayed in>
    Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
    Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
    (cherry picked from commit 364226a4caaa277d86fcc0c58ef862cb23a50603)

 winsup/cygwin/exceptions.cc |  6 +++++-
 winsup/cygwin/mm/cygheap.cc | 13 +++++++++++--
 2 files changed, 16 insertions(+), 3 deletions(-)

AM中に起床。

先日チェーンの切れてしまった自転車を近所の自転車屋さんに持ち込み。 もう修理は諦めるつもりだったので新車を購入する方向で。 最近は店頭販売ではなく注文販売になっているらしくカタログを見せてもらったり。 カラーバリエーションや変速機の有無、タイヤのサイズなどの組み合わせがある為、BTO的な感じになっているようです。 という訳で直観で選んだ1台に決定。納品予定などはまた後日連絡で、旧車は先に引き取ってもらう事に。 旧車を買ったのは約17年前で愛着もありましたが致し方なし🥲。

そういえばGoogle検索で横に「AIモード」なるボタンが追加されているのでちょっと使ってみたり。 AIチャット的な使い方をするのかと思ったのですが、一問一答で検索結果を要約して表示するという感じみたい。 なので、細かい条件を後から追加して絞り込むような使い方は面倒臭い(作文し直して再入力が必要)とは思ったりも。 むしろ「昨日のニュースを教えて」みたいな感じの方が良いようには思ったりも。 ただこれ、ニュースサイトが同じ感じにやってしまうと、そもそもニュースのネタを誰が提供するんだ？ みたいなパラドックスが生じそう。あくまでニュースのネタを整理/要約する手段として使う感じに思うので、 元ネタを自分で提供しない広告収入目的のまとめサイトみたいなのは無くなる方向になるかも？とは思ったりも。

AIモードで「半年間のキーボードに関するニュースを教えて」って出てきたまとめの中に、 「ゲーミングキーボード：ラピッドトリガーの普及と進化」という見出しがありました。 ラピッドトリガーってなんぞ？と思い gptel(gpt-oss:20b)で聞いてみたら「押したキーの連射機能だ」的な 回答が返ってきたのですが、Webで調べてみた感じはそうでは無いっぽい。 一般的なメカニカルスイッチの場合、ONやOFFと判断される押し込み位置(アクチュエーションポイント;入力位置) が決まっていますが、ラピッドトリガーでは 押した/離した距離が一定距離に達するとON/OFFが確定すると いうものみたい。浅い位置で押し離ししても、深い位置で押し離ししても良いようです。 このような挙動なので、高速に連打すると自然に押し/離しの距離は短くなるのに対しても反応すると いうことなのだろうなと想像します。 ただし、ちょっと触れただけでも反応してしまうというデメリットはあるようです。 実際に可能なのかは分かりませんが、ON/OFF判定開始となる最低押し込み距離が設定できるのであれば、 問題にはならないかもなぁ？とは思います。 ともあれ、ゲーミング用途だけでなく 普通のタイピング用途でも恩恵はあるような気はします。

テレワーク。気持ち早めに終了。

gptel。チャットで何度かやり取りしていると 「error in process sentinel: Search failed: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"」 みたいなエラーが出てそれ以上チャットが続けられなくなるのはそういうものなのだろうか？🤔

テレワーク。早めに終了。

調べごとをして終了。

テレワーク。早めに終了。

Web巡回して終了。

テレワーク。早めに終了。

ちょろり自転車でコンビニに買い物に行ったその帰りにチェーンが切れてしまった予感🥺。

そういえば Emacsに関する事を検索すると、割と高い確率で macOS上で使用する例が出てくる感じがします。 でも、普段使いでmacOS使っている人ってそんなに居るのかなぁ？と思う事はあります。

全然関係無い流れで 「交通事故発生の発生件数・死傷者数の推移」 というPDF文書の存在を知りました。 中に推移のグラフがあるのですが、下がったり上がったり不思議な推移をしているなぁ？と思いました。 例えば 昭和45年は発生件数に対して死亡する割合が高かったというのが伺えます。 昭和53年くらいから発生件数は平成16年頃まで増加の一途を辿っていますが、 平成4年頃から発生件数に対して死亡件数は減少傾向になっています。 平成12年～16年に発生件数は横這いになっているもののその後は減少傾向になってるようです。 しかしながら、発生件数よりも負傷者数は必ず多いという関係ではあるようなので、 事故ると無傷で済まないという事だけは言えそうです。 昭和45～49年くらいの勢いで減少すればあっという間にゼロに近づきそうな感じに思わなくもありませんが、 自動車普及に伴って分母が増えた結果なのだろうとは思います。 事故件数は 平成16年以降は減ってはいるものの 令和になっても一日800件以上の事故が発生しているようなので、 人間の運転能力の限界なのか？と思わなくはありません。 ところで平成12年～16年をピークに発生件数は減少に転じているのですが、ここら辺で減る要因に何があったのかしら？

AM中に起床。

gptelの gptel-default-mode を org-mode にしてチャットを使ってみています。 org-modeバッファとして見た場合、表とかはTABキーで整形できるしLaTeX式も「C-c C-x C-l」で レンダリング可能だったりするのですが、どうしても見づらい場合があるなぁ？とは思いました。 で、「org-modeなんだもの、我慢できなければHTMLにエクスポートして外部ブラウザで読めばいいじゃない？」 と思ってエクスポートしてみたのですが、プロンプトを示す文字列が「*** 」になっている為、 章立てがなんだか妙な事になります。何か良い方法は無いか？と思った苦肉の策として、 「*** 」を「* ** 」とかにすればいいんじゃない？と思って試してみたところ、個人的にはこれでいいかな って感じになりました。 「(add-to-list 'gptel-prompt-prefix-alist '(org-mode . "* ** "))」てなのを 設定に追加してみたり。まぁ、よき。

org-modeでは表示のスタイルを変えられますが、どうにも振る舞いが微妙な場合があります。 例えばAIチャットで「1. =ollama serve=（または =ollama start=）を実行」というのが返ってきたのですが、 「=～=」でコードスタイルとなるので、「=ollama serve=」と「=ollama start=」が固定幅フォントに なると期待するのですが、「=（または =」の部分を固定幅フォント領域と解釈しているようです。 もう少し調べてみたところ、開始は「 =」終了は「= 」で空白文字が必要ですが、それが無いのが問題みたい。 「1. =ollama serve=X（または =ollama start=X）を実行」の「X」の部分を空白にすれば大丈夫そう。 実際には、gptel-org.elてファイルの「gptel--convert-markdown->org」という関数でMarkdownをOrgに 変換してっぽいので 何かしら弄れば対応できそうですが読み切れず。 必ず空白文字が入らない、という訳でもないのがややこしいです。

以前、HTMLのimgタグにはbase64エンコードした文字列を埋め込むことで、 リンクではなくてHTML埋め込みのインライン画像表示が可能な事を知ったのですが、 org-modeって対応してるのだろうか？と思ったり。結果から言うと対応はしていなさげ。 ただし、「#+BEGIN_EXPORT html ～ #+END_EXPORT」の間に imgタグを直接書けば、HTMLエクスポートはできるので、 ewwなどのブラウザでは表示できるっちゃできます。

AM中に起床。

掃除したり洗濯したり。

EmacsハングというかCygwinハングの件。ノートPCでEmacsを3つ起動して(image-diredのスライドショーを動かしたりしてます) ほったらかしていたのですが、3つのうち一つが3日ほど動いてハング再現してました。 数日前と同じ感じなので、ロックがぶつかる確率は下がってはいるけどゼロではないので 時間をかけると踏んでしまうのかなと思います。 前にロックがぶつかる頻度を調べた時は意外と多いって事は 分かっているのですが、そもそもぶつかってはならないものなのであれば、 init_cygheap::find_tls()の時は、新たなシグナルに関する処理の開始を待たせた上で、仕掛中のシグナル処理が終わるまで待つ などして、ロックがかかっていない事を保証しないと無理な気がします。どうやれば良いのかよく分かりませんが🥺

そういえば、ロックがぶつかるのは SIGALRM の時だけのようでした。 init_cygheap::find_tls()の引数にシグナル番号が渡ってくるので、SIGALRMの場合は問答無用でスキップする という 動かなくなるかも知れないパッチにしてみたり。動きが変になったらやっぱダメって事にしようと 思ったのですが、Emacs起動はできたのでダメ元で様子を見てみる事にしてみます。これまでの状況から言うと ハングはしなくなるハズです。代わりに変な事が起こるかもしれませんが😓。

何気にOllamaで gpt-oss:120b モデルをpullして使ってみたり。ファイルサイズは53GBくらいで、 Webの情報を見る限りは メインメモリ64GBだと動くかどうか分からないみたいなことが書いてありましたが、 大分遅いものの一応動くようです。GPUメモリは12GBを使って、メインメモリも55GBくらいを使う感じに なるようです。文字の出てくる速度は20bに比べると大分遅いのですが、人がゆっくりしゃべってるくらい の速度なので、長い回答でも意外と全部読んでしまうかも知れません(むしろ大量の情報を一瞬で出されると 斜め読みしかしない😅)。ローカルLLMで一人で使うのであれば、メモリ消費が多くても、多少遅くても、 確度の高い回答が得られるのであれば トータルで効率が良い場合はあるかもなぁ？とは思ったりも。

gpt-oss:120bを Emacsのgptelから使ってみたり。OllamaのGUIチャットと違って少しバッファリング されているので、読む思考をちょっと妨げられるかも知れません。 ただし、回答が表示されている間も、他のバッファに切り替えてテキスト編集を行う事はできるので、 仕上がりを待つ間は他の事をやってれば良いかも知れません。が、我慢できない場合はあるかもなぁ？😅

gpt-oss:120bでもHSV2RGB変換コードの生成を試してみたのですが、必ずしも最適っぽいのが安定的に 出力される感じではないみたい。出てきたコードの一つが以下。

/* ------------------------------------------------------------
 * HSV から RGB への変換
 *  h : 色相   (0.0〜360.0)
 *  s : 彩度   (0.0〜1.0)
 *  v : 明度   (0.0〜1.0)
 *  r,g,b : 変換結果を格納するポインタ (0.0〜1.0)
 *  戻り値 : 正常終了 0 / パラメータ範囲外 -1
 * ------------------------------------------------------------ */
int HSV2RGB(double h, double s, double v, double *r, double *g, double *b)
{
  /* 入力範囲チェック */
  if (h < 0.0 || h > 360.0 || s < 0.0 || s > 1.0 || v < 0.0 || v > 1.0)
    return -1;

  /* s が 0 のときはグレイスケール */
  if (s == 0.0) {
    *r = *g = *b = v;
    return 0;
  }

  /* 色相を 6 区間に分割 */
  double hh = h / 60.0;          /* 0〜6 の範囲に正規化 */
  int i = (int)hh;               /* 区間番号 */
  double f = hh - i;             /* 区間内の小数部 */

  double p = v * (1.0 - s);
  double q = v * (1.0 - s * f);
  double t = v * (1.0 - s * (1.0 - f));

  switch (i) {
    case 0: *r = v; *g = t; *b = p; break;
    case 1: *r = q; *g = v; *b = p; break;
    case 2: *r = p; *g = v; *b = t; break;
    case 3: *r = p; *g = q; *b = v; break;
    case 4: *r = t; *g = p; *b = v; break;
    default:/* case 5 */ *r = v; *g = p; *b = q; break;
  }

  return 0;
}

AM中に起床。

gptel。先日のHSV2RGB変換を、コードのスタイルを少し変更する条件を加えてみたところ、 大分様子の違うコードが生成されました。

先日のに最後の一行を加えただけです。

/*
  色相と彩度と明度を 赤と緑と青 に変換するC言語の関数を作成してください。
  関数は「HSV2RGB(double h, double s, double v, double &r, double &g, double &b)」とし、
  入力となる色相は変数h、彩度は変数v、明度は変数vとし、変換結果はr,g,bはポインタ変数に
  赤はr、緑はg、青はbにそれぞれ値を格納してください。
  色相は0～360.0、彩度は0～1.0、明度は0～1.0 の範囲で指定します。
  赤、緑、青は 0～1.0の範囲に変換してください。
  関数の戻り値は変換できた場合は0を返し、入力となる色相、彩度、明度の値が範囲外の場合は-1を返してください。
  コード内コメントは日本語で、インデントは半角スペース2個で記してください。
*/

#include <math.h>

int HSV2RGB(double h, double s, double v, double *r, double *g, double *b)
{
  // 色相・彩度・明度の範囲チェック
  if (h < 0.0 || h > 360.0 || s < 0.0 || s > 1.0 || v < 0.0 || v > 1.0)
    return -1;

  // 彩度が0ならグレースケール
  if (s == 0.0) {
    *r = v;
    *g = v;
    *b = v;
    return 0;
  }

  double hh = h / 60.0;
  int i = (int)floor(hh);
  double f = hh - i;
  double p = v * (1.0 - s);
  double q = v * (1.0 - s * f);
  double t = v * (1.0 - s * (1.0 - f));

  switch (i % 6) {
    case 0: *r = v; *g = t; *b = p; break;
    case 1: *r = q; *g = v; *b = p; break;
    case 2: *r = p; *g = v; *b = t; break;
    case 3: *r = p; *g = q; *b = v; break;
    case 4: *r = t; *g = p; *b = v; break;
    case 5: *r = v; *g = p; *b = q; break;
  }

  return 0;
}

テレワーク。早めに終了。

gptel。gptel-send や gptel-rewrite を試してみたり。どこまで書けるものか？を試してみた感じ、 ある程度内容を示せばイケるみたい。

以下のような文言を記してみました。

/*
  色相と彩度と明度を 赤と緑と青 に変換するC言語の関数を作成してください。
  関数は「HSV2RGB(double h, double s, double v, double &r, double &g, double &b)」とし、
  入力となる色相は変数h、彩度は変数v、明度は変数vとし、変換結果はr,g,bはポインタ変数に
  赤はr、緑はg、青はbにそれぞれ値を格納してください。
  色相は0～360.0、彩度は0～1.0、明度は0～1.0 の範囲で指定します。
  赤、緑、青は 0～1.0の範囲に変換してください。
  関数の戻り値は変換できた場合は0を返し、入力となる色相、彩度、明度の値が範囲外の場合は-1を返してください。
*/

#include <math.h>

/*
 * Convert HSV to RGB.
 *
 * Parameters:
 *   h  - Hue in degrees [0, 360]
 *   s  - Saturation [0, 1]
 *   v  - Value (brightness) [0, 1]
 *   r  - Pointer to store red component [0, 1]
 *   g  - Pointer to store green component [0, 1]
 *   b  - Pointer to store blue component [0, 1]
 *
 * Returns:
 *   0  - Success
 *  -1  - One or more parameters out of range
 */
int HSV2RGB(double h, double s, double v,
            double *r, double *g, double *b)
{
    if (!r || !g || !b)
        return -1;

    if (h < 0.0 || h > 360.0 || s < 0.0 || s > 1.0 || v < 0.0 || v > 1.0)
        return -1;

    double c = v * s;                     /* chroma */
    double h_prime = h / 60.0;
    double x = c * (1.0 - fabs(fmod(h_prime, 2.0) - 1.0));
    double m = v - c;

    double r1, g1, b1;

    if (h_prime >= 0.0 && h_prime < 1.0) {
        r1 = c;  g1 = x;  b1 = 0.0;
    } else if (h_prime >= 1.0 && h_prime < 2.0) {
        r1 = x;  g1 = c;  b1 = 0.0;
    } else if (h_prime >= 2.0 && h_prime < 3.0) {
        r1 = 0.0; g1 = c; b1 = x;
    } else if (h_prime >= 3.0 && h_prime < 4.0) {
        r1 = 0.0; g1 = x; b1 = c;
    } else if (h_prime >= 4.0 && h_prime < 5.0) {
        r1 = x;  g1 = 0.0; b1 = c;
    } else { /* h_prime >= 5.0 && h_prime < 6.0 */
        r1 = c;  g1 = 0.0; b1 = x;
    }

    *r = r1 + m;
    *g = g1 + m;
    *b = b1 + m;

    return 0;
}

テレワーク。早めに終了。

記録的短時間大雨で落雷による停電がありました。体感で1分くらい停電したように思いますが、 色々リセットされてつらい。EmacsハングのテストはノートPCで行っているので継続されてました😅。

Emacsで使用できる AIチャットクライアントはいくつかあるようですが、Ollamaも使えるらしい gptelを試してみたり。 面倒臭いのは依存パッケージに Transient の 0.7.4 以降が必要なのですが、Emacs-30.2の標準パッケージのは 0.7.2.2 の為そのままでは使え無さそうです。 Transient は今や色んな所で使われつつあるので、 迂闊に新しいのを入れると色んな所がダメになりそうなのですが、仕方ないので入れてみたり。 最初に 影響を受けるであろう magit をちょろっと確認してみたのですが、「l l」でログを表示すると、 これまでのログを全て表示しようとしていたり。早速影響があるのが判明。 仕方ないのでmagitの方も更新したところ、適当な行数のログ表示で止まるようになりました。

で、本題のgptelを試したり。.emacsでの最小設定は以下くらいで良さそうです。

(require 'gptel)
(setq
 gptel-model 'gpt-oss:20b
 gptel-backend (gptel-make-ollama "Ollama"
                 :host "localhost:11434"
                 :stream t
                 :models '(gpt-oss:20b)))
(setq gptel-default-mode 'org-mode)

テレワーク。早めに終了。

ノートPCはEmacsハングのテストの為に立ち上げっぱなしにしていたのですが、 今朝 Windowsアップデートが自動的に適用されてました。Emacsハングのテストは強制終了となったものの、 それと引き換えに いつもWindowsアップデートのダウンロートが何故か全然進まない イライラがありませんでした。 次回から使ってなくてもWindowsアップデート前日に電源入れておくかと思ったりも😓。

今まであまりよく見ていなかったのですが、何故かGPUの 3Dの負荷が常時 30% くらいあるなぁ？と思ったり。 「デスクトップウインドウマネージャー」というプロセスが薄っすらGPUを使っているようなのですが、 なんぞこれ？と思ったり。そして、起動しているEmacsを最小化するとGPU負荷が 0% になるようだったり。 どういうメカニズム？🤔
Webにあるような視覚効果の無効化をいくつか適用してみたのですが、あまり変化は無いようにみえたり。 あと、ウインドウサイズを小さくすると負荷が下がり、大きくすると上がるようです。 最小化すると0になるのとも辻褄が合っていると言われればそんな気もします。 まぁ気になるなら最小化しておくかというくらいで。

Ollamaの OpenAI互換APIを CygwinのPythonから使ってみようと思い、「pip install openai」を 実行してみたのですが、jiter という依存ライブラリがインストールできないようだったり。 エラーメッセージの一部が以下。

 :
  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 1
  ╰─> [28 lines of output]
      Collecting maturin<2,>=1
        Using cached maturin-1.9.4.tar.gz (213 kB)
        Installing build dependencies: started
        Installing build dependencies: finished with status 'done'
        Getting requirements to build wheel: started
        Getting requirements to build wheel: finished with status 'done'
        Installing backend dependencies: started
        Installing backend dependencies: finished with status 'done'
        Preparing metadata (pyproject.toml): started
        Preparing metadata (pyproject.toml): finished with status 'error'
        error: subprocess-exited-with-error

        × Preparing metadata (pyproject.toml) did not run successfully.
        │ exit code: 1
        ╰─> [3 lines of output]
            Python reports SOABI: cpython-39-x86_64-cygwin
            Unsupported platform: x86_64-cygwin
            Rust not found, installing into a temporary directory
            [end of output]

        note: This error originates from a subprocess, and is likely not a problem with pip.
      error: metadata-generation-failed

      × Encountered error while generating package metadata.
      ╰─> See above for output.

      note: This is an issue with the package mentioned above, not pip.
      hint: See above for details.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.

 :

テレワーク。早めに終了。

デスクトップのWindows11もCygwinにパッチを当てて様子を見てみることに。Emacsの動作よりも、普段使いして 他のコマンドに副作用が無いかの様子を見る感じで。

タスクマネージャでGPUの使用率にCUDAが選べなかった件は、先日の参考ページの通りで 再起動したら 表示できるようになりました。Ollamaを動かしてみたところ、問に答える時にCUDA全力で動いているようです。 あとよく見ていなかったのですが、GPUメモリをバク食い(13.8GBくらい)しています。

EmacsハングのCygwinパッチ対応。一昨日から複数のEmacsを起動しっぱなしにしていたのですが、 3つあるうちの一つが止まっていたり😭。やっぱりロックが解除できない状況に陥っているようです。 確かに、パッチのロジックでは、ロックがかかっている場合は100% スキップ されますが、ロックがかかっていないと判定した後で、ロックを掛ける前にスレッドがスイッチして ロック実行を横取りされる可能性はゼロではありません。 それをアトミックに行うのが InterlockedExchange() などのような特別な関数なのでしょうけど。うーむ。 ただ、ハング発生確率はかなり低くなっているとは言えそうです。

テレワーク。早めに終了。

EmacsハングのCygwinパッチ対応。昨日から複数のEmacsを48時間ほど起動しっぱなしにしていたのですが、 どれもハングすること無く動き続けてます。ひとまず今週のWindowsアップデートが来るまでそのまま継続してみよう。

唐突ですが ローカルLLMとやらを試してみたくなったので調べてみたり。 Ollamaというツールを使えば 色々なモデルが試せるようなのでインストールしてみたり。 インストール完了と同時にプロンプト入力ウインドウが開き、適当に質問を入れたらモデル(gpt-oss:20b) がダウンロードされ始め、完了すると応答が返ってきたのでこれで使えるようです。



ollamaというコマンド名でコマンドラインからも使えるので(Cygwinのmintty+bash、screenコマンドを挟んでも 良いし、Emacsのvtermからも一応使えました)、どうにかすればEmacsとかからも使えるんじゃないかなー？ という気がします。ただ、応答がMarkdownで表示されるようなので、普通のターミナルでは なんか読みにくいです😓。
あと、デスクトップのWindows11のタスクマネージャはGPUの使用率表示にCUDAを選べません。 見かけ上 GPUを使っていないようにも見えるのですが、 GPU-Zで負荷を見てみると一応GPUを使っているようです。 Webで検索してみるとズバリな回答があったり (参考ページ)。 再起動が必要みたいですが、今は色々動かしてて再起動したくないので明日試してみよう。

AM中に起床。

掃除したり洗濯したり。

D言語で以下のような構造体のコンストラクタを書いたのですが、何故かエラーで怒られたり。

$ cat -n struct_test.d
     1  import std.stdio;
     2  import std.string;
     3
     4  struct Test{
     5    int x;
     6
     7    this(){
     8      x=3;
     9    }
    10  }

$ dmd struct_test.d
struct_test.d(7): Error: constructor `struct_test.Test.this` default constructor for structs only allowed with `@disable`, no body, and no parameters
  this(){
  ^

AM中に起床。

Emacsハングの件。というかCygwinハングの件。 straceでアタッチしたままほったらかしておいたところハングしてました。 ダメなのか？と思い Process Explorer で見てみたところ何故かメインスレッドがサスペンド状態 になっていました。Resumeで再開してみたらそのままSegfaultになったり。なんだこりゃ？🤔 straceでアタッチしていたのがダメなのか？とも思ったので、今度はただ起動しておくだけにしてみたり。 どうなるか....？

12時間ほど見てみたのですが、straceでアタッチしていた時のようにサスペンド状態にはならなかったり。 なにやら動きが変わるのかも知れませんが確認ムズい🥺。
一旦区切りとして、Cygwinのパッチは以下のような感じ。

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
       if (!inside_kernel (cx, true))
        {
          HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
-         cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+//       cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
          SetThreadContext (*this, cx);
          suspend_on_exception = true;
          in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..c34ff8c26 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
   while (++ix < (int) nthreads)
     {
       /* Only pthreads have tid set to non-0. */
+      if (threadlist[ix].thread->locked () != false)
+       continue;
       threadlist[ix].thread->lock ();
       if (!threadlist[ix].thread->tid
          || !threadlist[ix].thread->initialized)

テレワーク。気持ち早めに終了。

Emacsハングの件。というかCygwinハングの件。 先日のコンパイルのオプティマイズレベルを上げたものでもハング再現しないようだったり。 そういや既にロックしてたらスキップするみたいなコードなのですが、一度発生したらロックしっぱなしなのか、 ぶつかりさえしなければアンロックされているのか、が気になったので調べてみる事に。 と言っても、デバッガ上で動かすと動きが変わってしまいそうなので、デバッグprintを使おうと思ったのですが、 普通のはどれも大量に使用されているようだったので、special_printf()というのを使って 「strace --mask=special ...」でメッセージを絞る感じで観察しようと思ったり。 しかし、「strace --mask=special emacs-w32」で最初から strace に乗せると、メッセージが出ていなくても 異常に遅かったので、起動を済ませた後で 「strace --mask=special -p プロセスID」でアタッチする方式で網掛け。 さて、どうなるか....？

網掛けメッセージはわりとすぐに出力されたり。ただ、持続したりはしないみたい。 ついでにシグナル番号と思われるものも表示してみていたところ、どうやら SIGALRM を受けた時に 既にロックされている場面に遭遇しているようでした。killコマンドで SIGALRM を送ったらどうなる？ と何の気なしに「while true; do kill -s SIGALRM pid; done」で送りまくってみたら、 デバッグメッセージが流れるように表示されたり😅。 もしかして再現を加速できる？と思ったので Cygwin 3.6.2-1 かつ オリジナル emacs-w32 で試してみた のですが、動きが遅くなったりはするもののハングにまでは至らず。むぅ。

テレワーク。早くもなく遅くもなく終了。

Emacsハングの件。というかCygwinハングの件。 先日加えたCygwinの改造を適用してEmacsを立ち上げっぱなしにしていたのですが、 26時間以上ハング再現しないという状況です。 対処方法として正しいか否かは別にして、ひとまず避けられているみたい。 一旦止めて コンパイルのオプティマイズレベルをO0からO2に戻したものに差し替えて しばらく様子を見てみよう。

テレワーク。早めに終了。

Emacsハングの件。もう一度Cygwinのソースコードを眺めたり。 ロック制御している箇所の一つは winsup/cygwin/mm/cygheap.cc:init_cygheap::find_tls() の中なのですが、 もう一つ winsup/cygwin/local_includes/cygtls.h 内で定義されるクラス _cygtls の中の get_signal_arrived()というメソッドがありました。 なんとなく、シグナルが到着したら何かするって感じみたいです。 昨日の改造コードは既にロックがかかっていればそのままにするってロジックにしたのですが、 なんかダメかもなぁ？って感じだったかも。 そこで、find_tls()の方を ロックがかかっていたらそのスレッドは無視して次のスレッドを チェックするようなロジックにしてみたり。まぁこれも直している事になっているのか分かりませんが、 二重にロックしようとして脱出できなくなる事は無くなるハズ？という期待です。 そもそも、一つのスレッドで find_tls() と get_signal_arrived() を同時に実行する事は無い のだとすると、find_tls()を実行するスレッドAと、get_signal_arrived()を実行するスレッドBが ちゃんと切り替われば、ロックが脱出できなくなることは無いハズと考えられます。 しかし、実際にロック処理で脱出できなくなっているので、 「lock()～unlock()」の組がどの瞬間にも複数重ならないようにしたらどうなるか？ という感じです。

Emacsハングとは関係無い話。ELISPの message関数を使ってデバッグしていて、何故かELISPエラーと なって、なんで？ってなりました。最小コードで示すと「(message "100%")」でエラーとなりました。 message関数の1番目の引数はフォーマットストリングなので「%」がダメって事でした。 実際には文字列の入っている変数を 何の気なしに「(message strvar)」とかやってしまってたのですが、 習慣的に「(message "%s" strvar)」と書く癖を付ける必要があるかもなぁ？とは思ったりも。 修行が足りません🥺。

タケモトピアノのCMがリニューアルでHD化されとる。

テレワーク。早めに終了。

先日のロックコードのループにカウンタを設けて、あるカウント回数に達したら exit するようなコードにして ハングではなく終了するか？という網掛け確認してみたり。.....すぐに再現せず。

時間はかかりましたが一応 網にはかかったり。やっぱりlockを脱出できない場合があるみたい。 で、ロックを実行するコードを眺めていて思ったのですが、自分でロックをかけて用事が終わったら 自分でアンロックするという前提のコードになっているのですが、既にロックがかかっている場合は 脱出できない状況に必ず陥ると思われます。なので、ロックがかかっていない場合に限り ロックをかけるという風にしてはどうか？と思ったり。

コードを変更して実行。ひとまずハング再現待ち。と言ってもハングしない状況になるので、 どこでロックされたか分からないのに別の所でロックを外す事になるけど、それで変にならないか？という 確認になるかも知れませんが。

ん～～、なんかダメでした。何故かハングが再現する場合と、exitする網掛けに引っかかる場合があって、 なんで？な感じ。

テレワーク。早めに終了。

Emacsハングの件。 Emacsをgdbに乗せずに直実行したところでハングが再現した後、以下のような操作でどこで止まっているかを 調べてみたり。

1. Process Explorer で予めCPUをバグ食いしているスレッドIDを調べておく。
2. 「gdb -p プロセスID」でアタッチする。
3. 「info threads」のスレッド一覧と、1.のスレッドIDを付き合わせて、「thread #id」でスレッドを切り替える。
4. 「si」コマンドで命令単位のステップ実行をしばらく繰り返して、Cygwin上のコード領域に脱出する。

  void lock ()
  {
    while (InterlockedExchange (&stacklock, 1))
      {
#ifdef __x86_64__
        __asm__ ("pause");
#else
#error unimplemented for this target
#endif
        Sleep (0);
      }
  }