最近の出来事

2025/10/05

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);
      }
  }