最近の出来事

2025/08/24

AM中に起床。

掃除したり洗濯したり。

そういえばと思い今更ですが検索した「REALFORCE TYPING CHAMPIONSHIP 2025」。おかしな速度(褒め)なのは以前にも思った事ですが、史上最年少って小学生らしい。すげぇ....。で、最近は上位ランカーが多くて全然見ていなかったのですが、「タイピングplus」のランキング上位に大会に出場していた選手と思われる人たちが居るなぁと思ったり。 TANE自身は一応毎日1回以上は練習しているものの、サービス全体平均スコアくらいを維持するので精一杯です😅。ところで、8月21日くらいから練習記録の練習時間が妙な時間を表示するようになってますがバグか？

Emacsハングの件。結局程度の差はあるけど、どのようなビルドでもハングはするという感じに見えます。そこでスレッドのバックトレースを取れるのを知ったので、それで何か分からないかと少し調べてみました。何度か再現させて観察してみたところ、ハングが再現した後にいくつかのスレッドが終了しているように思いました。

  Id   Target Id                             Frame
* 1    Thread 27424.0x369c "emacs-30.2.1"    0x00007fff14b12352 in _cygtls::lock (this=<optimized out>) at /home/TANE-HP/develop/work/cygwin/newlib-cygwin/winsup/cygwin/local_includes/cygtls.h:245
  2    Thread 27424.0x5514                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 27424.0x2c14                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 27424.0x2ce4                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 27424.0x2fa8 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 27424.0x2b2c                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 27424.0x6350                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 27424.0x4b20 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 27424.0x4dec "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 27424.0x6698 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 27424.0x315c "itimer"          0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  12   Thread 27424.0x5178                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 27424.0x4dd4                   0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 27424.0x672c                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 27424.0x2b54                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 27424.0x3594 "waitproc"        0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 27424.0x173c                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 27424.0x2350 "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 27424.0x39c4 "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  22   Thread 27424.0x2f8c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  23   Thread 27424.0x1e1c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  24   Thread 27424.0x4124                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
[Thread 27424.0x2c14 exited with code 0]
[Thread 27424.0x5514 exited with code 0]
[Thread 27424.0x2ce4 exited with code 0]
[New Thread 27424.0x634c]

一覧の番号で言うと Id=2,3,4 のスレッドが code 0 で終了しているようです。で、この Id=2,3,4 って何？というのをスタックダンプで見たのが以下。

  :
Thread 4 (Thread 27424.0x2ce4):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 27424.0x2c14):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 27424.0x5514):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()
  :

これらのスレッド以外のスレッドは何かしらCygwinを経由しているようなトレースが取れていますが、これらはCygwinとは無関係な何かに見えます。ここからは想像ですが、何かしらの理由で Id=2,3,4 のスレッドが終了してしまうけど、それが検知されずハング状態に陥ってしまうという事か？因みに、今回の出所不明のスレッドについては、 Idは違いますがこちらのML記事と同じように存在しているものと思われます。ただ、何者なのかは分からないみたい。スレッド生成のAPIにブレークポイントを仕掛けて誰がスレッドを作っているかを調べるしか無いのか？

とりあえずWin32APIの CreateThread() にブレークポイントを設定してみたのですが、以下のような感じになりました。

(gdb) b CreateThread
Breakpoint 1 at 0x1007173f0
(gdb) run
Starting program: /home/TANE-HP/develop/work/emacs-30.2/emacs-30.2-ime/hangtest-emacs-30.2/src/emacs-30.2.1.exe
[New Thread 19000.0x43c4]
[New Thread 19000.0x5490]
[New Thread 19000.0x5a4c]

Thread 1 hit Breakpoint 1.2, 0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(gdb) info threads
  Id   Target Id           Frame
* 1    Thread 19000.0x27e8 0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
  2    Thread 19000.0x43c4 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 19000.0x5490 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 19000.0x5a4c 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) thread apply all bt

Thread 4 (Thread 19000.0x5a4c):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 19000.0x5490):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 19000.0x43c4):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 19000.0x27e8):
#0  0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1  0x00007fff14af50e3 in cygthread::create (this=this@entry=0x7fff14cf54e0 <threads>) at ../../../../newlib-cygwin/winsup/cygwin/cygthread.cc:299
#2  0x00007fff14af515d in cygthread::async_create (arg=140733542520032) at ../../../../newlib-cygwin/winsup/cygwin/cygthread.cc:273
#3  0x00007fffc7cb1b93 in ntdll!RtlDeleteElementGenericTableAvlEx () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x00007fffc7da67be in ntdll!KiUserApcDispatcher () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x00007fffc7da6304 in ntdll!ZwTestAlert () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x00007fffc7ca37e6 in ntdll!EtwEventWriteNoRegistration () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x00007fffc7ca367e in ntdll!EtwEventWriteNoRegistration () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#8  0x00007fffc7c75fce in ntdll!LdrInitializeThunk () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in ?? ()
(gdb)

一応止まるのですが、止まった時点では既に Id=2,3,4 が生成されているように見えます。CreateThread()じゃない何かでスレッドが生成されているという事？🤔
gdbは「[New Thread 39784.0x5310]」のような感じで新しいスレッドが生成されたことを認識できているように思えるのですが、何かしらgdb側でスレッドが生成された時に止めるとか情報表示する方法は無いのかしら？🤔

2025/08/23

AM中に起床。

午前中に通院。

Emacsハングの件。

| imagemagick | native-image-api |  rsvg   | IMEpatch | ハング再現 |       その他       |
|-------------+------------------+---------+----------+------------+--------------------|
|   without   |     without      | without |   with   |    する    |     パッチ有り     |
|   without   |     without      | without | without  |    する    |     パッチ有り     |
|   without   |        -         |    -    |    -     |    する    |     パッチ無し     |
|      -      |        -         |    -    |    -     |    する    | オリジナルバイナリ |

※Cygwin 3.6.5相当(commit a5f96c196 (HEAD -> cygwin-3_6-branch, origin/cygwin-3_6-branch))にSIGTRAP回避パッチを当てたもの
※ベースのconfigureオプションは「--prefix=/usr --with-w32 --with-native-compilation=no」
※観察の為にgdb上で動かし SIGTRAPをトリガに info threads を表示する(参考)
※IMEpatchは src/config.h を手で変える方式
※「-」は選択不能でwithoutと同等

これまで大丈夫と思っていたオリジナルのemacs-w32バイナリでも、時間をかければハング再現してしまう感じになっています🥺。ただ、gdb上で動かしているとか、シグナルを送っているとか、普段使いでは行わない事をやっているので、加速する感じになっている気がしなくはありません。
必ず再現する手番(時間をかけるようなのではなくて再現する一意の操作手順)が見つかっていないのと、ハングしている状況では何も調べられないのとで、原因究明が困難になっています。

Web検索していると過去にCygwinのMLで「Threads」という投稿からの一連の流れがあった事を知ったり。現在もCygwinのEmacsパッケージをメンテナンスしている Ken Brown氏が Emacsを起動すると大量の threadが生成されるけど誰が生成しているんだ？的な話から、シグナルの話などなんか既視感のある話題だなぁ？と思ったりも。今から10年くらい前の話なので直接関係は無いと思いますが。全部読めてません(英語よく解らんもある😓)が、最終的に解決した話題のようなので当時は何が問題でどういう原因をどう直したかが読めると、今回の話のヒントが何かないかなぁ？と思ったりも。何も分からないかも知れませんが😓。

gdbコマンドの「info threads」でスレッドの一覧を表示できることを知ったのですが、「thread apply all bt」で全スレッドのスタックトレースを表示できることを知ったり。
こちらのML記事の中にスレッドの負荷テストのコードが記されているのですが、試しにコンパイル＆実行してみたところ謎の動きになったり。

$ cat signal-stress.c
#include <assert.h>
#include <sys/time.h>
#include <signal.h>
#include <stdio.h>

long SmartScheduleInterval = 1; /* ms */
long SmartScheduleTime = 0;

static void
SmartScheduleTimer(int sig)
{
    if (sig != 0)
       SmartScheduleTime += SmartScheduleInterval;
}

void
SmartScheduleStartTimer(void)
{
    struct itimerval timer;
    timer.it_interval.tv_sec = 0;
    timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
    timer.it_value.tv_sec = 0;
    timer.it_value.tv_usec = SmartScheduleInterval * 1000;
    setitimer(ITIMER_REAL, &timer, 0);
}

int main()
{
    /* Set up the timer signal function */
    struct sigaction act;
    act.sa_handler = SmartScheduleTimer;
    sigemptyset(&act.sa_mask);
    sigaddset(&act.sa_mask, SIGALRM);
    if (sigaction(SIGALRM, &act, 0) < 0) {
        perror("sigaction failed");
        return -1;
    }

   /* start timer */
   SmartScheduleStartTimer();

   /* Loop forever, doing tests which should always succeed, with lots of signals */
   int x = 0;
   int i = 0;
   while (1) {
     x = i;
     int j = x;
     if (j != i)
       {
          printf("failed: %d isn't equal to %d, apparently\n", i, j);
          break;
       }
     i++;
  }
  return 0;
}

$ gcc signal-stress.c  -Wall -O0 -g

$ ./a
Alarm clock

$ ※エラーしないと終了しないプログラムなのに、コードに無い文字列を表示して終了してしまう。

なんで？🤔 gdbから実行すると期待通りに動いているようです。少なくとも「Alarm clock」なんて文字列が出力される理由が分からない。謎。
その後、一通りMLの記事を翻訳で読んでみたつもりですが、どこをどのように修正したかが分かりませんでした🥺。

2025/08/22

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

Emacsハングの件。 Cygwinパッケージのオリジナルemacs-w32(組み込みImageMagick無し、組み込みRSVG描画無し) だと3.6.5相当の野良ビルドしたCygwinでもハングせず。 IME/他パッチをあてて、ImageMagick無し、組み込みRSVG無しにしてみたのですがハングします。むむ。--with-native-image-api を付けていたり IMEパッチも有効なので、もっとオリジナルの emacs-w32に寄せてみるとどうなるのだろう？と思って試してみる事に。

2025/08/21

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

先日のEmacsで起動されるスレッドの観察。ハングは再現していたのですが何か掴む事はできず。ただ、killコマンドが「bash: kill: (1775) - Permission denied」てな感じでエラーしていて、何やらシグナルを送れない状況になっているのか？と思ったりも。正確に権限の問題なのか、理由はともかくシグナルを送れない状況を権限の問題と丸めてしまっているのかは判らず。

ハング前に表示されていた最後のスレッド一覧は以下のようになっていました。

Thread 1 "emacs-30.2.1" hit Catchpoint 1 (signal SIGSTOP), 0x00007fffbf618019 in WindowsCodecs!WICSetEncoderFormat_Proxy () from /cygdrive/c/WINDOWS/SYSTEM32/WindowsCodecs.dll
  Id   Target Id                            Frame
* 1    Thread 8512.0x10ac "emacs-30.2.1"    0x00007fffbf618019 in WindowsCodecs!WICSetEncoderFormat_Proxy () from /cygdrive/c/WINDOWS/SYSTEM32/WindowsCodecs.dll
  2    Thread 8512.0x6c64                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 8512.0x31a4                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 8512.0x3960                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 8512.0x6298 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 8512.0x56dc                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 8512.0x2a6c                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 8512.0x6f68 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 8512.0x1e08 "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 8512.0x6e54 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 8512.0x3284 "itimer"          0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 8512.0x651c                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 8512.0x26f8                   0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 8512.0x4130                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 8512.0x5cd8                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 8512.0x1c8 "waitproc"         0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 8512.0x54e8                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 8512.0x3458 "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 8512.0x62bc "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  22   Thread 8512.0xe78 "emacs-30.2.1"     0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  23   Thread 8512.0x6f9c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  30   Thread 8512.0x5258 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  31   Thread 8512.0x6ed0 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  32   Thread 8512.0x3308 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
[New Thread 8512.0x1da8]

スレッドIDが32に達しているなぁ？とは思ったりも。ただ、番号は抜けているので総数は24のようですが。 IDは再利用されていないのだろうか？🤔 IDが32に達したところで、新しくスレッドを作っているようですが、まさかオーバーフロー的に溢れてダメになっているとかじゃないよね？

今のところハングの再現しない Cygwin 3.6.2-1で、同じく Emacsを gdb上で動かして定期的にSIGSTOPを送ってスレッドを表示するとどうなるか？を試してみたところ、4時間ほどするとハングしてしまいました🥺。以下はハング直前の最後のスレッド表示です。ノートPCではなくデスクトップPCで試したのですが、何故かスレッドの数がちょっと多いです。

Thread 1 "emacs-30.2.1" hit Catchpoint 1 (signal SIGSTOP), 0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx ()
   from /cygdrive/c/windows/System32/win32u.dll
  Id   Target Id                             Frame
* 1    Thread 37036.0x622c "emacs-30.2.1"    0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  2    Thread 37036.0x4ad8                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  3    Thread 37036.0x2200                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  4    Thread 37036.0x8dbc                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  5    Thread 37036.0x8600 "sig"             0x00007ffb8faf7f7a in RaiseException () from /cygdrive/c/windows/System32/KERNELBASE.dll
  6    Thread 37036.0x73dc                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  7    Thread 37036.0xdd0                    0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  8    Thread 37036.0x1f80 "timerfd"         0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  9    Thread 37036.0x70ec "gmain"           0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  10   Thread 37036.0x6c68 "itimer"          0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  11   Thread 37036.0x15c8 "pipesel"         0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  12   Thread 37036.0x8ee4                   0x00007ffb8ff81324 in win32u!NtUserGetMessage () from /cygdrive/c/windows/System32/win32u.dll
  14   Thread 37036.0x9538 "waitproc"        0x00007ffb92382974 in ntdll!ZwReadFile () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  15   Thread 37036.0x7c50                   0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  16   Thread 37036.0x5d30 "pipesel"         0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  17   Thread 37036.0x85fc "[pango] fontcon" 0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  18   Thread 37036.0x5d0c "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  19   Thread 37036.0x782c "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  20   Thread 37036.0x6a00 "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  21   Thread 37036.0x5a14 "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  22   Thread 37036.0x4288 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  23   Thread 37036.0x89c4 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  24   Thread 37036.0x5a0c "itimer"          0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  25   Thread 37036.0x7388 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  26   Thread 37036.0x7b28 "pipesel"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  27   Thread 37036.0x7c18 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  28   Thread 37036.0x8a64 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  29   Thread 37036.0x904 "waitproc"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  30   Thread 37036.0x3b1c "itimer"          0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  31   Thread 37036.0x8634 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  32   Thread 37036.0x5b40 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  33   Thread 37036.0x95a8 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  34   Thread 37036.0x7d9c "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  35   Thread 37036.0x2288 "pipesel"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  36   Thread 37036.0x5b30 "emacs-30.2.1"    0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  37   Thread 37036.0x8f20 "emacs-30.2.1"    0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  38   Thread 37036.0x6b58                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
[Thread 37036.0x2200 exited with code 0]
[Thread 37036.0x8dbc exited with code 0]
[Thread 37036.0x4ad8 exited with code 0]
[New Thread 37036.0x7cdc]

シグナルを送る為のkillコマンドも「bash: kill: (638) - Permission denied」てな感じになっていました。という訳で、Cygwin 3.6.2-1でもハングしない訳では無いという感じのようです。

それじゃぁと思い、Cygwinオリジナルの emacs-w32(組み込みImageMagick無し、組み込みRSVG描画無し) だとどうなんだ？と思ったり。ひとまず仕掛けてみたのですが、なんかスレッド数が半分しか無いぞ？もしかしてスレッド数とハングには因果関係がある？🤔

マクドナルドのハッピーセットで転売目的の大量購入や食品廃棄などの問題の話。え？マクドナルド側の方が何か言われるの？

2025/08/20

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

先日、gdbで handleコマンドによりシグナル受信時の振る舞いを変えられるのを知りましたが、シグナルを受信した時に任意のgdbコマンドを実行できないのか？と思ったり。 Web検索で見つけられなかったので Copilotで聞いてみたら、catch signal と commands の組み合わせで実現できるという答えが返ってきました。

(gdb) catch signal SIGSTOP
Catchpoint 1 (signal SIGSTOP)
(gdb) commands 1
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>info threads
>continue
>end
(gdb) run

これで実行した状態で、プロセスに「kill -s SIGSTOP プロセスID」でシグナルを送ると、スレッドの情報を表示したのち continueで実行を継続する感じになるようです。なる。
なぜこのような事がしたかったかと言うと、C-zでちょこちょこ止めて「info threads」で見てみるとスレッドの数が増えているようだったので、増え続けたりするのだろうか？と思った次第。別bashから「while true; do kill -s SIGSTOP プロセスID; sleep 1; done」でシグナルを送り続けて Emacsハング再現した時の最後の瞬間が見られないだろうか？という訳で試してみたり。....直ぐには再現しないようなのでそのまま放置。

2025/08/19

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

Cygwin 3.6.3-1以降で Emacsがハングする件。
如何せんハング状態に陥っていると、 strace -p でアタッチしてもそのまま何もできない状況になるし、 gdb -p でアタッチしても同様に C-z で SIGSTOPを送ることもできません。でも、なにやら大量にスレッドが生成されているようなので、どこで生成されているのだろうか？と思ったり。 src/systhread.c:sys_thread_create() が呼ばれているのだろうかと思い、ブレークポイントを設定しても止まる気配が無し。どこでスレッドが生成されているのかよくわからず🤔。
gdb上で動かして、適当なところで C-z で止めてから info threadコマンドを実行してみたところ、以下のようなスレッドが生成されているようでした。

(gdb) info threads
  Id   Target Id                             Frame
* 1    Thread 28184.0x5f0c "emacs"           0x00007fffc52d1344 in win32u!NtUserMessageCall () from /cygdrive/c/WINDOWS/System32/win32u.dll
  2    Thread 28184.0x4828                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 28184.0x69b0                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 28184.0x6390                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 28184.0x5fc0 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 28184.0x3050                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 28184.0xf60                    0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 28184.0x6f38 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 28184.0x2184 "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 28184.0x2d68 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 28184.0x6b34 "itimer"          0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 28184.0x5684                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 28184.0xef8                    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 28184.0x6db0                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 28184.0x704                    0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 28184.0x4268 "waitproc"        0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 28184.0x3450                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 28184.0x5b1c "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 28184.0x64c8 "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb)

「Id 1」は emacsのメインスレッドと思われますが、それ以外は何のスレッドなのかよくわかりません。ただ、「[pango] fontcon」は数日前に何かあるのか？と思った所でした。「sig」もスレッドのようなのですが、どちらも emacs本体のスレッドでは無いようにも思えたり。特に何かを得られた感じはせず🥺。

2025/08/18

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

Cygwin 3.6.3-1以降で Emacsがハングする件。
先日の続きで謎のSIGTRAP対応をしたリリースされていない野良ビルド Cygwin 3.6.5相当でハング再現の様子見していたのですが、やっぱり3.6.3以前よりも再現性が高いです。あと、一度だけで契機は判りませんが「Fontconfig warning: using without calling FcInit()」というメッセージが起動したターミナルに表示された事がありました。少し前にpangoや fontconfigが何か関係している可能性を考えたのですが、何かあるのか？と思ったり。原因では無く影響を受けた結果かも知れないのでなんとも言えませんが....🤔

特に何も掴めず🥺。

2025/08/17

AM中に起床。

Cygwin 3.6.3-1以降で Emacsがハングする件。
昨日のCygwin 3.6.2-1に相当する野良ビルドしたcygwin1.dllでハング再現しない事を確認していたのですが、ハング再現してました🥺。むむ。ただし、2つのEmacsのうち一つだけハング再現で、もう一つは朝まで耐えていた感じではありますか。

ちょっと話は逸れて gdbで実行すると謎のSIGTRAPが発生する件。3.6.3-1では試していなかったというのに気づいたのでパッケージでCygwin 3.6.3-1を再インストールして確認。総合結果で言うと以下のような感じ。

  | Version   | 謎のSIGTRAP | 備考       | 備考(Emacsハング)            |
  |-----------+-------------+------------+------------------------------|
  | 3.6.1-1   | ？          | パッケージ | ハングしない                 |
  | 3.6.2-1   | 発生しない  | パッケージ | (パッケージ版は)ハングしない |
  | 3.6.3-1   | 発生しない  | パッケージ | ハングする                   |
  | 3.6.4-1   | 発生する    | パッケージ | ハングする                   |
  | 3.6.5相当 | 発生する    | 野良ビルド | ハングする                   |

3.6.4-1は、よりによってこのタイミングで感🥺。逆に謎のSIGTRAP と Emacsハングとの因果関係は無いかも。

話は Cygwin 3.6.3-1以降で Emacsがハングする件に戻る。
デッドロック的なものが発生しているとして、どうやって止めれば良いのだろう？🤔。
Cygwin 3.6.2-1相当でオプティマイズレベルを -O0にして野良ビルド。ハング再現待ち。

ハング再現待ちの間に掃除でもするかと思って掃除機の電源を入れたところ、モーターの回転が急に遅くなり部屋の照明が点滅したり。これはショートか？と思い即停止。なんてこった😭。午前中だったので即座にヨドバシヘ調達に。普段行かない家電フロアでいくつか試して、型落ちだけど持ち帰り可能なコードレスのスティックタイプに決定。約25000円でしたが全額ポイントで支払い。
因みに、壊れた掃除機は2001年1月に引っ越した時に買ったものだったので約24.5年使用したことになります。掃除機って壊れないのかと思っていたのですが突然壊れるのか....

掃除したり。説明書にはフル充電に4時間かかると書かれていたのですが小一時間ほどで充電完了。バッテリー保管時は満充電にしておけとも記されていたので、出荷時に充電されていたのかも。さておき、軽くて快適😄。そしてめっちゃ吸う😆。よき。

掃除機調達やら掃除の間、5時間ほどハング再現待ちはほったらかしにしていたのですが、この時間では再現せず。3.6.2は実はギリギリ大丈夫で、コンパイル条件とかによって再現性が変わるのか？🤔 いずれにしても、これまでたまたま大丈夫だっただけという疑惑も湧いてきた気がしたりも。困った。
その後もハング再現せずトータル7時間ほど耐えたので一旦別条件に。

Cygwin 3.6.3相当を野良ビルドしてみたり。ただし、オプティマイズレベルを -O0にしてみます。 Cygwin 3.6.3-1のパッケージからハングが再現するのですが、一旦オプティマイズレベルを下げるとどうなるか？を見てみる事に。ただ、3.6.2と 3.6.3は差分内容的にはほぼ変更無しにも見えるので (数日前のメモ)、オプティマイズレベルを下げると再現性に影響あるのかを見る感じで。 ....1.5時間くらいでハング再現。マジか🥺。ダメになったのは強制終了して、追加でEmacsを起動して様子見継続した感じ6時間は耐えられてそう。イケるときはイケるし、ダメなときはダメという感じだな......

gdb上でemacsを実行すると謎のSIGTRAPが発生する件。 git log を眺めていると、スレッドに関連する不具合に対処する為に、意図的にトラップを起こすような変更を加えているようでした。複数のコミットで色々な部分を直しているので全部を外す事は難しそうだったのですが、 x86の EFlagsレジスタのTF(トラップフラグ)を設定するようなコードがあり、これが何かしら悪さをするケースがあるのではないか？と推測してみたり。フラグの設定コードをコメントアウトして、リリースされていない Cygwin 3.6.5相当で野良ビルドしたところ、 gdb上で emacsを実行しても謎のSIGTRAP は発生しなくなりました。 Emacsは結構な数のスレッドが起動されるようなので、強めの負荷テストになっているのかも知れません。で、Emacsのハングに影響するのか？を見てみたところ早めにハング再現😓。という訳で、gdb実行での謎のSIGTRAP は別件確定という感じかも。

2025/08/16

AM中に起床。

直ぐには出ないだろうと思っていたら、Cygwinパッケージに emacs 30.2-1 がもう来ていたり。マジか😓。
ひとまず「Emacsの雑記」を Emacs-30.2ベースに更新してみました。御参考まで。まだ Cygwinのバージョンとの組み合わせでハングする件は解決できていないので、先日のワークアラウンド方法を但し書きとして記してます。

話は Cygwin 3.6.3-1以降で Emacsがハングする件に戻る🥺。
調査しているノートPCは Cygwin 3.6.3-1の一つ前が Cygwin 3.6.1-1だったのですが、3.6.1-1まで戻してもハングは再現しませんでした(なので「Emacsの雑記」には 3.6.1-1まで戻すのもワークアラウンドとしています)。で、3.6.1-1でも gdb上で実行すれば SIGTRAPは発生しません。3.6.3-1以降だと謎のSIGTRAPが発生するのとハングは関係があるのじゃないか？と思い始めたりも。
SIGTRAPを受け取ると一応 gdbの操作は可能でバックトレースも表示できるのですが、シグナルの発生源は判らんなぁ？と思ったりも。何かしらデバッガ上で発生源を調べられるかと思いきや方法が見当たらず。むぅ🤔

ハング調査のノートPCのEmacsを30.2-1にアップデートしてみたり。Cygwin本体のバージョンを上げたり下げたりしていると、関係無いパケージも更新するかしないかを指示しなくてはならないのが面倒臭いから。それだけ😓。でもやっぱりハングは再現します。やっぱり原因は Cygwin側にあると考えるのが打倒だろうか....

Cygwinを野良ビルドしてみる事に。ひとまず先日調べた cygwin-3_6-branch の HEAD(まだリリースされていない3.6.5に相当)で試してみたり。一度もCygwinをビルドしたことの無いノートPCだったので、ツールのインストールが足りなかったのを追加したり、以前ハマった「shilka」ってコマンドが無くてビルドに失敗するのを回避手順で対応したり。ひとまず new-cygwin1.dll のビルドは成功。 3.6.4-1と入れ替えて(rebaseは無し)様子を見てみることに。
gdbで実行すると謎のSIGTRAPが発生する件はビルドしたcygwin1.dllにしても再現するようです🤔。
Emacsを起動して様子見中に Cygwin の git logを眺めていたところ、何やらデッドロック案件が修正されているみたい。もしこれが関係しているのだとすると、様子見中のEmacsはハングしない事が期待できるかも？...... と期待したのですが、やっぱりハングが再現しました🥺。

Cygwin 3.6.2-1に相当するコミットをcheckoutしてビルド。野良ビルドしてもこのバージョンならハング再現しないのか？を確認してみる事に。何故かビルドに失敗したのですが、Cygwin 3.6.2-1の後にw32apiが13.0.0-1になった為ヘッダの二重定義が発生している模様。手でちょっと直して対応。
gdbで実行するとパッケージのCygwin 3.6.2-1と同じく謎のSIGTRAPが発生する事は無いようです。少なくとも謎のSIGTRAPについては面倒ですがどのコミットで発生するようになるかを特定する事は可能かも。 Emacsの方は見ている範囲ではハング再現はせず。再現しないのが期待ですが、一応一晩放置で様子見する事に。

2025/08/15

AM中に起床。

Emacs 30.2のリリースアナウンス (Emacs 30.2 released)。メンテナンスリリースという位置づけのようです。結局昨日は深夜までアクセス可能になりませんでした🥺。

Cygwinパッケージの libglibのバージョンを libglib2.0_0-2.85.x-1(今年の5月末～のリリース) よりも前の libglib2.0_0-2.84.1-1(今年の4月頃リリース) まで戻したいと思ったのですがインストーラーで選択できず。ローカルにはダウンロードしたアーカイブファイルがあるので再インストール可能なハズですが。しかたないので選択可能な範囲で一番古い libglib2.0_0-2.85.1-1 まで戻して様子見。

うーむ、やっぱりハングが再現します。libglibじゃない可能性もあるのですが、やっぱりもっと古いのに戻したい。という訳でlibglib2.0_0-2.84.1-1のアーカイブ(runtimeとdevel)を展開して手動インストールした後、適当にCygwin本体を再インストールしてrebaseを実行。一応ファイルの日付は4月になっている事と、野良ビルドしたemacs-w32は再ビルドしなくても起動できたので様子見。

glibを4月のまで戻してもやっぱりハングが再現しました🥺。先日も記したのですが、glibは最新のままでCygwin本体を 3.6.2-1まで戻せば動くので、 glibが原因では無いかも知れません。困った。
現時点のワークアラウンドは以下のいずれかになるかと思います。

Cygwin本体のバージョンを 3.6.2-1まで戻す。
IME/他パッチを当てて Emacsを野良ビルドする際のconfigureオプションに --without-imagemagick と --without-rsvg を指定して組み込みImageMagickと RSVG対応を無効化する。

ただし、前者は時期を逃すと Cygwinのインストーラで選択できるバージョンのスコープを外れる可能性があり、一度新しいのを入れてしまうと戻れなくなる可能性はあります。また、後者は ImageMagickの処理を全て外部コマンドで行うように設定変更を伴ったり、そもそも SVG描画が使えなくなります(SVGを直接描画使用するアプリは使用できなくなります)。どちらにしてもダメージが大きすぎる🥺

gdbからプログラムを実行すると謎の SIGTRAPを受信して停止しまくる件。 handleコマンドで「handle SIGTRAP nostop」のようにして停止しないようにして実行してみたり。停止はしないけどSIGTRAPを受信した事は表示されるのでひとまずこれでハング再現するか？を様子見してみたり。
SIGTRAPで停止しないようにしたEmacsでハングが再現したのですが、C-zを押してもSIGSTPが受信されていないのか止められず。当然のように C-cもダメ。むーん🤔。タスクマネージャでプロセスを終了すると、SIGHUPを受けて終了するようです。コンパイルのオプティマイズレベルでも下げてみるか....
もしかするとハングがSegfaultとかに変わる事を期待したのですが、オプティマイズレベルを下げても様子は変わらず。
clangでコンパイルしてみるかと思い試してみたり。warningメッセージは出るもののビルドに成功。実行してみるもやっぱりハングは再現します。
straceを使ってハング直前に何をやってたか判るか？と思って試してみるも、イマイチ何やってたんだか判らず。何度か straceを使用した状態でハングが再現したのですが、

   :
   80 381962734 [sig] emacs-30.1.1 1052 sigpacket::process: signal 14, signal handler 0x1005F9BB0
   41 381962775 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: suspending thread, tls 0x7FFFFCE00, _main_tls 0x7FFFFCE00
  107 381962882 [[pango] fontcon] emacs-30.1.1 1052 set_signal_mask: setmask C082006, newmask 0, mask_bits C082006
   64 381962946 [sig] emacs-30.1.1 1052 _cygtls::inside_kernel: pc 0x7FFFC52D1364, h 0x7FFFC52D0000, inside_kernel 1
   61 381963007 [[pango] fontcon] emacs-30.1.1 1052 sig_send: sendsig 0x13C, pid 1052, signal -71, its_me 1
   48 381963055 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: couldn't interrupt.  trying again.
  101 381963156 [[pango] fontcon] emacs-30.1.1 1052 sig_send: wakeup 0x125C
   42 381963198 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: suspending thread, tls 0x7FFFFCE00, _main_tls 0x7FFFFCE00

「[[pango] fontcon] ....」というのが毎度ハングでメッセージが出なくなる前に現れていて、どちらもImageMagickの /usr/bin/cygMagickCore-7.Q16HDRI-9.dll や RSVGの /usr/bin/cygrsvg-2-2.dll から辿れると言えば辿れるような気も。ただ、Emacs本体からpangoの関数を呼んでいる訳ではない(というかpangoの何を指しているかもよくわからない)ので、スタックトレース的な物がないと調べられないなぁという感じ。うーむ🤔

2025/08/14

AM中に起床。

Cygwin 3.6.3-1以降で Emacsがハングする件。
まずCygwinパッケージのemacs-w32の .pdmp ですが、例えば 30.1 であれば「/usr/libexec/emacs/30.1/x86_64-pc-cygwin/emacs-*.pdmp」に配置されていた模様。なので、pdump対応を外している訳では無かったみたい。なのですが、、、configureオプションに「--with-dumping=none」を追加してダンプを抑止した実行バイナリだとハングがすぐには再現しなくなりました。むぅ🤔

その後、色々試してみたり。見かけ上、

Cygwin 3.6.2-1を、3.6.3-1以降に入れ替えると、野良ビルドしたemacs-w32実行ファイル(pdump有効) でハングするようになる。
オリジナルのemacs-w32(pdump有効のハズ)ではハングしない。
Cygwin 3.6.4-1でも configureオプションに --with-dumping=noneを付けて野良ビルドした実行ファイルはハングが再現しない........ と思いきやしばらくするとハング再現🥺。
ただし、pdump有効よりは大分長持ち。
configureオプションに --with-dumping=unexecを付けて野良ビルドした実行ファイルもハングは再現しない....... と思ったけどしばらくするとハング再現🥺。
ただし、pdump有効よりは大分長持ち。

という感じになっています。
あと、様子見してみる限り恐らくEmacsがハングするのとは別件のようですが、

Cygwinを 3.6.4-1で gdbからemacsを実行すると、オリジナルのemacs-w32、pdumpした野良ビルドemacs、 dump無し野良ビルドemacs、unexec-dumpした野良ビルドemacsのいずれも、起動途中や起動後に SIGTRAPシグナルを受信して止まる。continueで続けても、少し動いてまたSIGTRAP受信で止まる。
Emacsハングの件を調べるのにgdbを使用できないという謎の縛りが発生しています🥺。

というのもあります。

以前、Cygwin 3.6.2と 3.6.3の変更点でそんな事になるのか？と思ったのですが、当時はリリースノートを見ただけの感想でした。実際にどんな変更が入っていたのだろうか？と思い、gitリポジトリをcloneして 3.6.2と 3.6.3のタグを比較(==3.6.3の変更差分の抽出)してみた結果が以下です。

$ git branch
* cygwin-3_6-branch
  main

$ git diff cygwin-3.6.2 cygwin-3.6.3
diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h
index 622aaa95a..961a98c78 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -11,7 +11,7 @@ details. */
    changes to the DLL and is mainly informative in nature. */

 #define CYGWIN_VERSION_DLL_MAJOR 3006
-#define CYGWIN_VERSION_DLL_MINOR 2
+#define CYGWIN_VERSION_DLL_MINOR 3

 /* CYGWIN_VERSION_DLL_COMBINED gives us a single number representing the
    combined DLL major and minor numbers. */
diff --git a/winsup/cygwin/release/3.6.3 b/winsup/cygwin/release/3.6.3
new file mode 100644
index 000000000..60031e5b0
--- /dev/null
+++ b/winsup/cygwin/release/3.6.3
@@ -0,0 +1,5 @@
+Fixes:
+------
+
+- Fix "There are no available terminals" error with AzureAD accounts.
+  Addresses: https://cygwin.com/pipermail/cygwin/2025-May/258214.html
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 83883f9f6..ffe71ee07 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -1996,10 +1996,6 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap)
       if (sid_id_auth (sid) == 5 /* SECURITY_NT_AUTHORITY */
          && sid_sub_auth (sid, 0) == SECURITY_APPPOOL_ID_BASE_RID)
        break;
-      /* AzureAD SIDs */
-      if (sid_id_auth (sid) == 12 /* AzureAD ID */
-         && sid_sub_auth (sid, 0) == 1 /* Azure ID base RID */)
-       break;
       /* Samba user/group SIDs */
       if (sid_id_auth (sid) == 22)
        break;

うーむ、やっぱりこれで変になるとは思えない....🤔

だんだん rebase関連の事案じゃないかと思い始めたり。オリジナルのemacs-w32は imagemagick無し(デフォルト)、rsvg無し(Cygwin向けは未対応)ですが、 IME他パッチ版の野良ビルドではこれらを含んでいます。これを順に外してみる事に。

--with-imagemagick, --with-rsvg, --with-native-image-api はハング再現する。
--without-imagemagick, --with-rsvg, --with-native-image-api はハング再現する。
--without-imagemagick, --without-rsvg, --with-native-image-api はハング再現せず。
--with-imagemagick, --without-rsvg, --with-native-image-api はハング再現する。

imagemagickもrsvgも両方外せばハング再現せず。ある意味オリジナルのemacs-w32(ハングせず)に近いのかも。で、imagemagickとrsvgに共通する点で心当たりがあると言えば glibが思い浮かんだり。丁度 Cygwin 3.6.3-1のアップデートと同じくらいの時期に glib2.0_0-2.85.x-1 ってのがパッケージリリースされています。 Cygwin本体だけを 3.6.2-1に戻せば大丈夫というのと辻褄が合わないですが、時期的な所に連動しているので何か手がかりはないか？と思ったり。それにしても、毎年 Cygwin本体が更新されるとなにやら Emacsが不調になって、その原因を調べているような気がします🥺。

とかやっているうちに、Emacs30系のブランチに emacs-30.2 のタグが打たれたっぽい。 git pullして気づいたのでリリースアナウンスを確認したいのですが、 MLアーカイブページがタイムアウトで反応しなくて確認できず。そういやここ1ヵ月くらいMLアーカイブページのタイムアウトにかなり高い確率で遭遇するなぁ？とは思ったり。メインのftpサイトにはアーカイブが置かれている模様。ftpサイトも激烈に遅くてダウンロードに小一時間を要したり。
で、IME/他パッチを当ててビルド。configureのパッチがリジェクトされたのは 30.1.90の時と同じでした。 Cygwin 3.6.2-1での確認ですが、ちょろっと動かした感じではいきなりずっこけたりはしなさげ。 Cygwinパッケージのリリースまでテストする感じで。少し前に、30.2に向けてそろそろ動きがあるだろうと予想していたのですが、ハングの件が拗れてしまっているので油断していました。

2025/08/13

AM中に起床。

そういえば Unicode 16.0 で追加される絵文字に東日本で言うところの「スコップ」、西日本で言うところの「シャベル」が追加されますが、絵文字の説明的にはどっちになるんだ？と思い、Emacs 31.0.50 の admin/unidata/emoji-sequences.txt を調べてみたところ、0x1FA8Fに対応する絵文字は「shovel」と記されていました。シャベルのWikipedia によると、「日本のJISでは足をかける部分があるものをシャベル、無い物をスコップとしている」ようなので、東日本の方が逆なのかも。スコップはオランダ語らしいので英語圏の人には分からない。また、「園芸用こて」は英語で trowel らしいので、やっぱりスコップは通じないのかも。

シャベルの事を調べていて、JIS(Japanese Industrial Standards)の日本語呼びが「日本工業規格」から「日本産業規格」になっていたらしい (日本産業規格のWikipedia)のを知ったり。 industrialは工業/産業どちらの意味もあるのでJISはそのままの模様。 JISマークも変わったりしているようですが、Unicodeに旧JISマーク「〄」が刻まれているのはそのままみたい。 JISマークのUnicode文字が割り当てられている経緯に MacJapanese(Wikipedia)なるAppleの独自ShiftJIS拡張が関係しているらしい。そういえば以前、「㌀」や「㍇」なんて誰得なんだ？と思った事がありましたが MacJapaneseが起源となっているようです。今回、旧JISマークのようなロゴマークをUnicode文字に入れてるのは迂闊だよなぁ？と思ったのですが、「㌀」や「㍇」の時にも思った「なんで？」の犯人はMacJapaneseだったのか。

Windows Update。ノートPCのアップデートだけ何故か異常に遅いのは変わらず。

Cygwin 3.6.3-1以降で Emacsがハングする件。普段使いのデスクトップPCで調べるのは色々と作業の邪魔になるのでノートPCで確認してみる事に。 Cygwin 3.6.3-1まで入れてあったのですが、3.6.4-1にアップデートして Emacsをいくつか起動して再現するかを試してみたり。やっぱり契機は判りませんが再現はする模様。で、とりあえず gdbを挟んでみるかと試してみたところ、 run実行したら何故か起動途中くらいで SIGTRAPが発生して止まったり。なんだこれ？🤔 continueで続けると、ちょっとするとまた SIGTRAPが発生するという感じで全然普通に動く様子がなかったり。止まる場所は決まっていなさげ。むむ。これを受けて、ハングの発生しない Cygwin 3.6.2-1 のデスクトップPCで同じく gdb上で動かしてみたところ、 SIGTRAPが発生するような事はありませんでした。もしかしてハングと関係ある？🤔

様子を見始めたら少し模様が付いている感じに見えたり。

Cygwinパッケージオリジナルのemacs-w32バイナリおよび emacs-gtkバイナリでは、試している範囲内ではハングが再現しない。
自分でビルドしたIME/他パッチの当たっている emacs-w32バイナリだと再現する。ビルドし直したり、IMEパッチだけを無しにしても再現する。

という事から、オリジナルのバイナリのconfigureオプションを「M-x describe-variable」で変数 system-configuration-options から調べて適用したり、pdumpをやめたりするとどうなるか？を調べてみる方向で。

pdumpをやめるにはconfigureオプションが必要っぽいのですが、オリジナルのバイナリのconfigureオプションにはダンプに関するオプションが指定されていません。オリジナルのバイナリはどうやってビルドしたんだ？🤔

2025/08/12

AM中に起床。

Emacsのキー割り当てとして「\C-z」には「scroll-down」コマンドを割り当てています (Emacs24以降から(?)scroll-down-commandになっていたらしい。さっき知りました😅)。元々 X68kの μEmacs で previous-page という scroll-downに相当するページ単位のスクロールに割当たっていたのが由来で設定しています。 Emacsでは「\C-v」が「scroll-up-command」が割当たっていて、これは X68kの μEmacsでも「\C-v」に同じ動作の「next-page」が割当たっていたのですが、 Emacsでの「scroll-down-command」が「\M-v」に割当たっているのは (Metaキーは ESCキーを使った2ストローク入力だったのもあり) "無いわー"と思ったのと、サスペンドなんて頻繁に行わないだろ？という理由から、X68kの設定を逆輸入する形で「\C-z」への「scroll-down」割り当てを30年以上前から行っています。で、この「\C-z」への割り当てって何由来だろう？と思って調べたのですが出所は分からず。 X68kの μEmacs では ED.Xのキーバインドが少し混ざっているので、ED.X由来か？とも思ったのですがそういう訳でも無いっぽい。
さておき、一般的に scroll-down-commandに相当する操作は「\M-v」のまま使っているのだろうか？🤔 先に記した通り ESC押しの2ストローク操作は論外にしても、CtrlとALTを押し分けるのも結構難しいように思います。

今になってX68kのμEmacsのキーバインドを調べたのですが、罫線描画のモード(バインド)があったのか...とか、 grepモードがあったのか...とか、「M-x describe-bindings」って使えたのか...など、全然使いこなせていなかったかも知れんなぁと思ったりも😓。

そういえば何か違和感があったのですが、Edgeで使用しているデフォルトフォントが「Noto Sans/Serif JP」になっているなぁ？と思ったり。Webで調べると4月には変わっていたようですが、Windows10には適用されていなさげだった事と、新PC(Windows11)への乗り換えを行った 5月時点では既に変化点が無い状態だったので気づいていませんでした😅。きっかけは「\(ASCII 0x5c)」が「¥(円マーク)」じゃなくて「\(バックスラッシュ)」で表示されていたので気づきました。Microsoftが表示互換を損なうようなデフォルト変更を入れてくるとは思いませんでした。固定幅フォントは去年変更された BIZ UDGothic のままなのでpreタグ内は

\(ASCII 0x5c)

「¥」で表示されるようです。もしフォントもロケールに依存しない (例えば日本語フォントの「¥(円マーク)」やEUC-KRの「₩(ウォン)」で表示される事が無い)方向に進んでいるのだとすると、以前「Windows標準の日本語文字フォントでは表示互換を維持する為にバックスラッシュ表示になる事は絶対に無い」と思っていたのがそうではなくなる可能性はあるのかも？

以前、「游ゴシック Regular」には「猶」の文字が旧字体で表示される不具合があると言うのを知り確かにと思ったのですが、現在の Windows11では修正されているようです。

Windows10 游ゴシック猶

修正されたという情報を全然見つけられないのですが、少なくともTANEが知った2024年5月時点には修正済っぽかったらしい。そしてWikipedia にも修正された事が記されていないままとなっているようです。 Windows11で修正されていてもWindows10はそのままなので、「Windows10では修正されていない」と言われればそんな気もしますが。

2025/08/11

AM中に起床。

先日、いくつか知らないフォントがあって挙げてみたのですが、fontタグで指定してもうまく反映できないフォントがありました。例えば「Bodoni MT Poster Compressed」というフォントで、フォントファイルは「BOD_PSTC.TTF」が対応していると思われるのですが、 Windowsのフォント設定で探すと完全名「Bodoni MT」のフォントファミリに属していて face違いという扱いのようです。しかし、メタデータのフォントフェイスを選択することができて、「Poster Compressed」を選択すると完全名は「Bodoni MT Poster Compressed」となります。なんだこりゃ？🤔 Emacs上ではファミリ名「Bodoni MT Poster Compressed」を指定すれば表示できる、つまり「Bodoni MT」とは別ファミリという扱いになっています。仮に同ファミリの別faceの扱いだとして、WeightでもSlant(italic,oblique)でも無いパラメータで指定するのか？🤔

そういえば、UNIXのラインエディタに「ed」がありますが、 X68kに標準で付属していたフルスクリーンのテキストエディタも「ED(ED.X)」だったなと思ったり。これまでX68kの話の文脈から UNIXのedを連想した事は無いなと思ったりも。 X68kのEDのキーバインドってどんなだったっけ？と思って検索してみたら、 AI回答に X68kでラインエディタの edを操作するような例が出てきて、「X68000のテキストエディタ「ed」のキーバインドについてですね。edはUNIX系OSで使われる基本的なテキストエディタで、X68000にも搭載されていました。具体的なキーバインドは、標準的なUNIX版edとほぼ同じです。」と記されていたので、うーん？🤔 ってなりました。X68kの話の文脈でも UNIXのedを連想するのは AIはどういう学習をしたんだ？とは思ったりも。

2025/08/10

AM中に起床。

掃除したり。

何気にフォントの一覧を眺めていて、こんなフォントありましたっけ？と思ったり。 Windows10とWindows11とで「c:\Windows\Fonts」を比べてみて、気になったものをザックリ挙げてみました。以下の表はfontタグのface指定を使っていますが、 Windows11じゃないとフォントが存在しなくてうまく表示できないかも知れません。

ファミリ名(完全名) 表示例

Berlin Sans FB Berlin Sans FB: This is a pen. 012345

Bernard MT Condensed Bernard MT Condensed: This is a pen. 012345

Broadway Broadway: This is a pen. 012345

Brush Script MT Brush Script MT: This is a pen. 012345

Chiller Chiller: This is a pen. 012345

Colonna MT Colonna MT: This is a pen. 012345

Cooper Black Cooper Black: This is a pen. 012345

Curlz MT Curlz MT: This is a pen. 012345

Felix Titling Felix Titling: This is a pen. 012345

Forte Forte: This is a pen. 012345

Gigi Gigi: This is a pen. 012345

Goudy Stout Goudy Stout: This is a pen. 012345

Harlow Solid Harlow Solid: This is a pen. 012345

Jokerman Jokerman: This is a pen. 012345

Juice ITC Juice ITC: This is a pen. 012345

Magneto Magneto: This is a pen. 012345

Matura MT Script Capitals Matura MT Script Capitals: This is a pen. 012345

Onyx Onyx: This is a pen. 012345

Ravie Ravie: This is a pen. 012345

Rage Rage Italic: This is a pen. 012345

Rockwell Rockewll: This is a pen. 012345

Script MT Script MT: This is a pen. 012345

Showcard Gothic Showcard Gothic: This is a pen. 012345

Stencil Stencil: This is a pen. 012345

Viner Hand ITC Viner Hand ITC: This is a pen. 012345

Vivaldi Vivaldi: This is a pen. 012345

Vladimir Script Vladimir Script: This is a pen. 012345

普段使いできる感じのものは少ない気もしますが😅。

ファミリ名(完全名)	表示例
Berlin Sans FB	Berlin Sans FB: This is a pen. 012345
Bernard MT Condensed	Bernard MT Condensed: This is a pen. 012345
Broadway	Broadway: This is a pen. 012345
Brush Script MT	Brush Script MT: This is a pen. 012345
Chiller	Chiller: This is a pen. 012345
Colonna MT	Colonna MT: This is a pen. 012345
Cooper Black	Cooper Black: This is a pen. 012345
Curlz MT	Curlz MT: This is a pen. 012345
Felix Titling	Felix Titling: This is a pen. 012345
Forte	Forte: This is a pen. 012345
Gigi	Gigi: This is a pen. 012345
Goudy Stout	Goudy Stout: This is a pen. 012345
Harlow Solid	Harlow Solid: This is a pen. 012345
Jokerman	Jokerman: This is a pen. 012345
Juice ITC	Juice ITC: This is a pen. 012345
Magneto	Magneto: This is a pen. 012345
Matura MT Script Capitals	Matura MT Script Capitals: This is a pen. 012345
Onyx	Onyx: This is a pen. 012345
Ravie	Ravie: This is a pen. 012345
Rage	Rage Italic: This is a pen. 012345
Rockwell	Rockewll: This is a pen. 012345
Script MT	Script MT: This is a pen. 012345
Showcard Gothic	Showcard Gothic: This is a pen. 012345
Stencil	Stencil: This is a pen. 012345
Viner Hand ITC	Viner Hand ITC: This is a pen. 012345
Vivaldi	Vivaldi: This is a pen. 012345
Vladimir Script	Vladimir Script: This is a pen. 012345

2025/08/09

AM中に起床。

「新美の巨人たち」。伊藤若冲と円山応挙が割とご近所さん(距離にして200mくらい)だったらしい。交流の記録は無いみたいですが若冲の方が17歳年上だったようなので、まぁそれなら直接の交流は無いかも知れないなぁとは思ったりも。

2025/08/08

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

先日、ビデオゲームは残すのが大変と記したのですが、そういやオンラインサービスのみのゲームはサービス終了とともに遊ぶこと自体ができなくなる物もあるよなぁ？と思ったり。かろうじてブログや動画配信で記録として残る場合はあるかも知れませんが、ゲーム進行の無いようなコミュニケーションゲームだとほとんどは思い出にしか残らない(そしていつか忘れられる)と思います。もしかすると、今から30年後は 1980～1990年代のゲームは遊べるのに 2010～2020年代のゲーム(特にスマホゲーム)はほとんど遊べないという状況になっているかも知れません。

2025/08/07

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

「グラディウスオリジンコレクション」てのが発売されているらしい (公式ページ)。グラディウス、II、III、沙羅曼蛇、LIFE FORCE、2、他と、新作として沙羅曼蛇IIIが収録されているらしい。グラディウスIVは？ 90年代前半までのタイトルなのか？と思ったのですが、完全な再現が難しかったので未収録とした模様 (参考記事)。そういやグラディウスVはナンバリングタイトルだけど PS2専用で移植もされていません。あと、言われてみれば今年はシリーズ40周年なのか。大分前、30年とか50年とかに渡って出たらそれはそれでスゴいと書いた事がありましたが、既にビデオゲームは本や音楽や映画と変わらないなとは思ったりも。ただ、メディア的に残すのが大変という問題はあるかも知れませんが。

2025/08/06

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

調べごとをして終了。

2025/08/05

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

Web巡回して終了。

2025/08/04

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

そういえば、Copilotと言われると Microsoft Copilot と GitHub Copilot がありますが、単にCopilotというとどちらを指すかは文脈によるかも。用途は全く違うので混ざることは無いかも知れませんが。

現在では、恐竜は鳥類の祖先という事になってますが、海に棲んでいた首長竜は爬虫類に分類されていて恐竜では無いらしい。「ドラえもんのび太の恐竜」に出てくるピー助はフタバスズキリュウという設定でしたが、現在の分類に従うとピー助は恐竜では無いという事になります。そこ変わるのか....とは思ったりも。

2025/08/03

AM中に起床。

掃除したり洗濯したり。

そういえば、ラッコって日本では鳥羽水族館のメス2頭だけになっているらしい。海外から輸入する事もできなくなっているようなので、このままだと日本で見られなくなるのは時間の問題のようです。
ところで、Windows11の Fluent Emoji ではカワウソに相当する OTTER の絵文字のデザインはラッコのように描かれています(🦦)。ラッコは英語で Sea otter なのだそうな。カワウソと兼用でも良いのかも知れませんが、背泳ぎで手に何か持っているとラッコにしか見えない不思議。 Google検索でAIの回答に「ラッコの絵文字は、一般的に「🦭」で表されます。」って記されていたのですが、それはアザラシだろ？とは思ったりも。AIは絵文字を絵として認識していないのだろうか？🤔
MSのCopilotに「🦦は何の絵文字ですか？」って聞いたら「ラッコの絵文字です」って答えが返ってきました。ラッコと認識しているのもあるかも知れませんが「この絵文字を元に絵を描けますか？」って聞いたら、

絵文字🦦を元にMS-Copilot画伯の描いたラッコ

って絵が描かれました。器用なもんです。結局絵文字の絵を見てラッコと判断しているのか、文字コードにラッコが紐づけられているのかは判断できません...

そうだ、それも聞いてみればいいじゃん？と思い「Microsoft Copilotは絵文字のテキストを絵として認識しているのですか？それとも文字コードに対応した意味として認識しているのですか？」と聞いてみたら「Copilotは🦦のような絵文字を、画像そのものではなく「Unicodeで定義された文字コード」として処理します。その上でコンテキストや学習データに基づき、ある種の“意味”や“概念”として理解しています。」という回答でした。文字コードにラッコが紐づけられているということらしい。どうも OTTER の絵文字はラッコっぽく描かれた絵の方が多いようなので、人類もラッコとカワウソの区別が付いていないようには思ったりも。

2025/08/02

AM中に起床。

何気に調べごとをしていて、node.jsは CygwinでビルドできるというAI回答が出てきたので、マジで？と思って試してみたらダメでした🥺。大分古いバージョンでビルドできていた事があったようですが今はできそうに無いです。検索してみてもWindowsのバイナリを使用する....みたいな方向に向いているのですが、 Cygwinからだとファイルパスの問題が解決できない場合があるので、結局用事にならない事の方が多い気がします。

2025/08/01

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

そういえば「ASSEMBLY SUMMER'25」が始まっているもよう。メインのCOMPOは日本時間の深夜から早朝という感じだと思うので、 Pouetで結果を見る感じになるかも知れませんが。

2025/07/31

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

そういえば、Emacsの pretest 30.1.90が5月18日頃に出たのですが (以前のメモ)、約2.5ヵ月ほど経過しました。次(30.1.91？)は出るのだろうか？ 30.1は今年の2月23日頃のリリースだったので、 8月で約6ヵ月になる所を鑑みると、時期的にはそろそろ 30.2に向けて動きがあるか？と勝手に予想したりも。
masterブランチの状況はあまりよく分からず。ただ、盛大に変更が加わっているようなので 30系から31系の移行では色々面倒な対応が必要になりそうな予感はします。特に使用する側の観点で、lexical-binding のワーニングメッセージが出るのは目ざわり (そして対応も面倒; 以前のメモ; やりよう無い場合あり)なので (既に存在しているのかも知れませんが)30系以前の動きに戻す設定を用意してくれないだろうか？とは思う所です。

2025/07/30

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

津波。いつから津波警報が出ていたのかは判りませんが、夕方時点で都心では電車が運休になってて、そんなに？と思ったりも。

東京MXのTVCMで「銀河特急ミルキー☆サブウェイ銀河の果てまでいってきました！展」てのが流れていますが、そもそもこれって何？と思って調べてみたり。亀山陽平氏の個人製作のショートアニメーション作品「ミルキー☆ハイウェイ」の続編にあたるのが「銀河特急ミルキー☆サブウェイ」という事らしい。公式ページはこちらのようですが、それよりも東京MXで本編放送中というのを知りました😅。PARCOでのイベントのCMは目にするのですが、番組のCMは見たこと無いのと、6分の枠なので地デジの番組表では文字が表示できる高さになっておらず、番組の存在が見た目では判りませんでした😓。YouTubeでも観られるようだったので見逃した分を観てみたのですが、ほとんど一人で制作！？ってマジっすか....そんな感じ。

2025/07/29

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

NHK総合で放送されているドラマ「舟を編む〜私、辞書つくります〜」を何気に観ています。劇中で「セレンディピティ」 (参考Wikipedia) という言葉が出てきたのですが、こういう状況を表す言葉があるのかというのを知りました。そういえば、2016年にノイタミナ枠でアニメ放送もされていましたが (以前のメモ;情報無し😓)、内容をすっかり忘れてしまっていました。アニメ版で紙の話をこんなにしてたっけ？と思っていたのですが、こちらのアニメ版のあらすじから、ドラマは13年経った時点の話を膨らませているようです。ドラマは新たな感じで観ています。

kotlinというかSwing。マウスのホイールイベントの中に修飾キー(Ctrl,Shift,ALT)の状態を示すメンバー変数があるという事で、試しにprintln()で表示するようにしてみたのですが、以下のようなワーニングメッセージが出ました。

$ make imgview_test.jar
kotlinc -Wextra -include-runtime imgview_test.kt -d imgview_test.jar
imgview_test.kt:131:54: warning: 'val modifiers: Int' is deprecated. Deprecated in Java.
                    println("Wheel ${e.x} ${e.y} ${e.modifiers}")
                                                     ^^^^^^^^^

deprecatedなのは分かるのですが、どうしろと言っているのかが判りませんでした。結局「println("Wheel ${e.x} ${e.y} ${e.getModifiersEx()}")」のように getModifiersEx()を使えば良いっぽいのですが値に互換は無いようです。というか、ワーニングメッセージが出なくなっただけで対処として合っているのかは判りません。
それにしてももう少し気の利いたメッセージは出せないものなのだろうか？🤔 以前、C言語でも deprecatedの属性を与える仕組みがあるのを知ったのですが、gccだと非推奨って事しか判りませんでした。 kotlincでも似たようなものという事か？

2025/07/28

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

宇宙兄弟(45)。ストーリー的に成功する事は予想できるのですが、実際にこういう事故が起こったら今の人類はうまく対応できるだろうか？とは思ったりも。宇宙兄弟の物語上は2029年7月30日の出来事ですが、現実世界の4年後だとしても、月面への探査機投入も思い通りにいかない現実の現状を鑑みますに、月軌道上で人を回収するなんて事は大分難しいミッションには違い無いと想像します。次巻で完結ですが発売は約1年先になるみたい。

2025/07/27

AM中に起床。

掃除したり洗濯したり。

kotlinというかSwing。ある JPanelコンポーネントにスクロールバーを付けたいとき、 JScrollPane に JPanelコンポーネントをはめ込むイメージで使うようですが、 JPanelコンポーネント内の処理の結果に従って、スクロール位置を補正したいと思ったとき、どうやってやるんだ？というのがイマイチよく解らなかったり。 Win32APIだとスクロールバーのついたウインドウという考え方なので、スクロールバーの付いたJPanelコンポーネントのスクロール位置を再設定するみたいにできないのか？と考えてしまいます。
仕方ないので、「val scpane = JScrollPane(mypanel)」のように自前パネルをJScrollPane にはめ込んだ後に、「mypanel.parentscpane = scpane」のように相互参照できるようにした上で、 mypanel内から parentscpane を介して JViewportを取得したり設定したりすればイケるっちゃイケそうなのですが、Swing的に一般的な方法なのだろうか？🤔

2025/07/26

AM中に起床。

お出かけ。風が熱風🥵。

Emacs起動時の引数にファイルやディレクトリを指定すればそれを開いて起動できますが、 Tramp経由のリモートファイルを指定して開くこともできるというのを知りました。よく考えればそりゃできるよねという感じですが😅。

2025/07/25

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

調べごとをして終了。

2025/07/24

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

Emacsハングの件。先日 Cygwin 3.6.4に戻して様子見していたのですが、やっぱりEmacsのハングが発生します。困るのは明確な操作トリガーがはっきりしていない事と操作不能な状態に陥る事。デバッガを使って調べる事もできません。というか、Cygwin本体の問題だとほとんどの場合デバッガがうまく機能しません🥺。と言うわけで、当面は Cygwin 3.6.2に戻して使うしかありません。Emacsでなくても良いので誰かに同じ事象が発見されて修正されるのを期待するか.....

2025/07/23

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

Emacsを起動してほったらかしておくとハング状態に陥る件。3.6.3から最新のCygwin 3.6.4-1にすると症状が悪化している感じだったので、バージョンを3.6.2まで下げて様子見してましたが、ここ数日でハングする事はありませんでした。見かけ上は 3.6.2を 3.6.3にするとハング現象が発現する感じですが、 cygwin 3.6.3-1の変更点でそんな事になるのか？はよくわかりません。

Cygwinを3.6.4に戻して、Emacsをビルドし直した実行ファイルでどうなるか？を様子見してみることに。

2025/07/22

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

田宮俊作氏死去。90歳だったそうな。

調べごと。掴めず。

2025/07/21

AM中に起床。

山手線内でのバッテリー発火。スマホ本体のバッテリーなのかモバイルバッテリーなのか、 TVの報道はどっちにも取れる場合があってよくわからす。スマホ本体のバッテリーだと問題視される箇所が変わってくるかも？ところで、そもそもモバイルバッテリーって必要か？🤔 スマホデビューして半年くらいで言うのもなんですが、1日もたない状況なんてあるわけないと思えるのですが。

flymakeのkotlin対応。少し使ってみた範囲では大丈夫そうな感じなので放流してみます (kotlincfm_250721a.tar.xz)。使い方は kotlincfm.pl というperlスクリプトの最初の方にutf-8の日本語で記してあります。 Cygwinで使用する為のスクリプトなので、他のプラットフォームでは用事にならないと思います。ご参考まで。

2025/07/20

AM中に起床。

掃除したり洗濯したり。

先日椅子の下に敷いていたラグマットを交換したのですが、ラグマットだけではなくフローリングワックスがダメージを受けて剥がれていたためワックスがけを実施。掃除したり乾かしたり時間がかかりましたがひとまず完了。他にもワックスが剥がれている所はあるのですが、水場との動線がややこしい部屋構造でルートを間違えると動けなくなってしまうのもあり腰がなかなか上がりません😓。

投票へ。部屋を出て戻るまでピッタリ14分。時間とタイミングが良かったのか待ち行列無しでラッキー。

目を離すとEmacsがハングしている件。昨日Cygwinを最新の3.6.4-1にアップデートしてWindows11も再起動してみたのですが、何やら少し起こりやすくなっているような？ Cygwinを3.6.2まで下げてみる事に。また様子見。

そういえば、以前、Web散策しているとディスプレイがブラックアウトするという現象があったのですが、その後にディスプレイが故障してしまいました。新しいディスプレイになったりゴタゴタしていてすっかり忘れていたのですが、そういやブラックアウトしなくなったような？と思ったりも。NVIDIAドライバのアップデートは行っていませんが、ディスプレイ交換とWindowsUpdateがあったので何が原因だったのか判りませんが、今思うにディスプレイ故障の予兆だったのだろうか？と思い返したりも。

今頃なのですが、gcc-15.1には gcobolという COBOLのフロントエンドが実装されているらしい (GCC 15 Release Series Changes, New Features, and Fixes)。どういう経緯で実装されることになったのかはよく分からず。そういえば Rustは gcc-14.1で gcc-rustが実験的に入っていましたが(以前のメモ) 15.1では正式に入っているっぽい。Cygwinネイティブターゲットへの移植はまだ行われていないようですが、イケそうな感じになりつつあるようです (Experimental cygwin host support #137819)。

kotlin。ワーニングの直し方がよく分からない場合があります。 Swingでファイル名のドラッグ＆ドロップ処理を調べると、AI回答のコードが動きそうだったので使用してみる事にしたのですが、以下のようなコードでワーニングが出ました。

    val files = transferable.getTransferData(DataFlavor.javaFileListFlavor) as List<File>

「warning: unchecked cast of 'kotlin.Any!' to 'kotlin.collections.List<java.io.File>'.」というワーニングなのですが、結局書き方でどうにかなる訳では無さそうだったので、

    @Suppress("UNCHECKED_CAST")
    val files = transferable.getTransferData(DataFlavor.javaFileListFlavor) as List<File>

で明示的に抑止するという感じの対処方法しか分かりませんでした。Javaのライブラリを使っている都合上どうしようも無い場合はあるのかも知れませんが、抑止じゃない方法で対処する書き方があるのだろうか？🤔

2025/07/19

AM中に起床。

kotlinのflymake対応。Makefile内でコンパイルに使用する一時ファイル名を元に、出力するjarファイル名の生成と削除を行う事でゴミを手動で消さなくても良いように考えてみたり。 flymakeに連携の取れたMakefileを書かなくてはならないのは面倒かもなぁとは思ったりも。まぁ、一度書けば終わりではありますが。

libGDXのプロジェクトでflymakeを使う。まだ使えてませんが🥺。ひとまず単一 .ktファイルをチェックできるのですが、libGDX由来のクラスなどの場所が不明なのでコンパイルエラーになります。何かしら kotlincにライブラリパスを指定すれば良いのだろうと思った訳ですが、gradle でのビルドでkotlincにどういう引数を与えているのかがよく判りません。 --infoなどで実行しているコマンドラインなどが調べられるかと思ったのですが、コンパイラへの引数はおろか kotlincを実行しているか否かすら判りません。なにこれ？🤔

結局 gradleから情報を引き出す事はできませんでしたが、 kotlinc のコマンドラインに -classpath で.jarファイルを指定すれば良いらしいのが判ったり。ただし、何も無い状態からはチェックできないので、gradleで一度ビルドした後に「find . -iname '*.jar'」とかでファイルの位置を調べて例えば gdx-1.13.1.jar を -classpathに指定するように Makefileを書き換えるという感じで、 libGDXのサンプルコードをflymakeでチェックする事ができるようにはなりました。 1テンポ待たされる感じはありますが、ちょろっと変えては「./gradlew run」で確認するよりは遥かにマシになったように思います。

少しテストをしていたのですが、エラーメッセージに改行が含まれる場合にうまく動きませんでした。 Emacsのflymakeの表示でもエラーメッセージの最初の改行までしか表示されなくて、エラーはしているが肝心の原因を指す部分が表示されていない事があったため、結局フィルタースクリプト側で改行を空白文字に変換して対応したり。面倒臭すぎる。

kotlinc のオプションに -Wextra という細かいチェックを行うオプションがあるようだったので試しに指定してみたところなにやら色々指摘されたり。その中に直し方がよくわからないのがありました。

        exitmenuitem.addActionListener {
            kotlin.system.exitProcess(0)
        }

というコードに対して「warning: parameter 'it: ActionEvent!' is never used, could be renamed to '_'.」というメッセージが出ました。どうやら addActionListener() に渡ってくる引数を使用していない事に警告を発しているようなのですが、具体的にどうやって直せば良いのかよくわかりませんでした。未使用の引数は「_」を指定する事で使用しない事を明示するという方法があるとのことで、「exitmenuitem.addActionListener { _ -> 」のように書いたのですがダメでした。結局「exitmenuitem.addActionListener { it」って書くという方法で警告は出なくなりました。因みに「exitmenuitem.addActionListener { _」はエラーになります。なんだこれ？🤔

なにやらEmacsを起動して、しばらく使わないままにした後に再び使用する為にウインドウをフォーカスするとハング状態に陥っている事がちょいちょい起こるようになっています。Cygwinの更新はしていないのですが、 WindowsUpdateを適用した後から起こるようになったような？ハング状態に陥るとウインドウイベントが掴まれっぱなしになるようで、他の関係無いウインドウまで操作不能な状態になってしまう場合があって、タスクマネージャのウインドウを前面に出す事ができなくなったりしました。幸いにしてどうにか操作できる状態だったのでハングしているEmacsプロセスを殺せば復旧するのですが、はっきりとした契機が分からないためしばらく様子見するしかないかも。そういや Cygwinの3.6.4-1が出ていたのでアップデートしてみたり。様子見するしかないのには変わりありませんが🥺。

2025/07/18

本日休業。

通院。めっちゃ待つ事になると言われてたけどめっちゃ待たされた😅。

kotlin。先日のFloatのようなのはflymakeで編集しながら確認できないのだっけ？と思ったのですが、 LSPを使う面倒臭い方法しか出てこないなぁ？と思ったり。また、kotlincには gccで言うところの -fsyntax-only みたいなオプションも付いていなさげ。それ以前に kotlincもgradleも実行速度が遅すぎるように思います。

Google検索のAI回答によると、「./gradlew classes」でコンパイルだけ実行する代用になるらしい。でも 9秒かかる。遅い。「./gradlew compile」もイケるっぽい。こちらは 6秒。やっぱり遅い。そしてターゲットとなるソースコードだけをコンパイルする方法が判らず。
更にGoogle検索のAI回答に --include-buildオプションを使って「gradle classes --include-build=path/to/your/file.java」みたいにするという、「そうだよそういうので良いんだよ」と思えるのが出てきたのですが、実際に実行してみると「path/to/your/file.javaはディレクトリじゃない」と怒られました。ガッカリ🥺。ターゲットとなるソースファイルのコンパイル結果を機械的に取得したいだけなのに、なんでこんなに面倒臭いんだ？🤔 理解に苦しむ。

単一の .ktコードに限り flymakeを使えるようにしてみたり。 Cygwinの Emacsで使う都合もあって、DMDの時の様にエラーメッセージのファイルパスをCygwinパスに変換する外付けのフィルタースクリプトは必要です(以前のメモ)。加えて、kotlincはファイルをフルパスで指定しても、エラーメッセージでは勝手にディレクトリパスの表示が無くなる為、 Emacs上で開いているファイルバッファと紐づけができなくなってました。エラーメッセージのファイルパスはフルパスになるように加工する必要もありました。ただ、コンパイルだけを行う事ができない為、 Foo_XXXXXXXXXXXXXXX_flymakeKt.class といった感じファイルなどをチェックの度に生成されます。ソースファイルの中身をパースしないと関連付けられないファイルを生成する為、自動で消す事ができなくて手動で消すしかない感じになってます....
それにしても、こんな面倒臭いコンパイラの挙動に世の中のIDEは頑張って対応しているのだろうか？🤔 コンパイラのメッセージ書式や文法チェックだけを行う場合の挙動を標準化すれば良いのにと思わなくはありません。

2025/07/17

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

kotlin。libGDXのサンプルをちょろっと弄ったり。SpriteBatch.draw(img,x,y)の xとyはFloat型で指定する必要があったので、「var x: Float = 0」のように変数xの初期値を設定して使おうとしたところコンパイルエラー。「var x: Float = 0f」のように書く必要があるらしく、暗黙に型変換されないみたい。「var x: Float = 0.0」とすると、0.0は Doubleと解釈されるようで、 Floatの場合は何をやるにも fを付けないとダメっぽい。面倒くせぇ....🥺。 Float型の変数との演算「x + 1」みたいなのは fを付けなくても大丈夫そうなので、型推論が行われる場面はあるようですが。
kotlinには三項演算子が無いみたい。代わりに if式で「x = if(条件) a else b」のように記すらしい。

2025/07/16

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

随分前に買ったラグマットですが、椅子のキャスターで轢き続けた結果、椅子の足で描く円形に布地に穴が空き始めたのでチェアマットをネット購入していました。それが届いたので敷き替え。前のラグマットはタタミ一畳分だったのですが、それよりは少し小さいものの丁度収まるサイズで良い感じ。

kotlin向けにlibGDXのプロジェクト生成。ADD-ONSの LANGUAGESに Kotlinを追加し、 TEMPLATEに Kotlin Logoか Kotlinを選べば良いみたい。ビルドは「./gradlew run」で良さそう。 libGDXの作法なのか、ApplicationAdapterってクラスを継承した Mainってクラスの中に書いていくのは Javaの場合と同じようです。

2025/07/15

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

kotlinというかjava？ libGDXというゲームフレームワークがあるのを知ったので試しに使ってみたり。何かしらインストーラーでインストールするのかと思いきや、プロジェクトのセットアッププログラムを実行して指定したディレクトリ下にひな形となるファイル群を生成し、生成されたプロジェクトのディレクトリ下でビルドするというものらしい。何やらIDEにいちいちインポートしないとビルドできないのか？とも思ったのですが、コマンドラインでのビルドも可能みたいなのでひとまずそれで試してみたり。公式ドキュメントを見ずに別のページに「./gradlew desktop:run」と実行すればPC用にビルドして実行できるっぽかったので試してみたら何やらエラー。desktopが無いという事だったのですが、そういうことではなくて、公式ドキュメントにあるようにプロジェクトの構成に合わせて指定しなくてはならないという事みたい。あと単純に「./gradlew run」でもよしなにビルド＆実行されるようですが、良しなになるようになっているから (勝手に)期待した風に実行されるという事みたい。「A Simple Game」のページを見たところ、奥まった所に置かれている Main.java が本体コードのようで、同ページの最後の「Full Example Code」に差し替えて(packageを自分のに合わせる事と、画像ファイルやmp3ファイルを所定のアセット置き場に置く必要がありました) みたところビルド＆実行に成功したので、ひとまず Main.javaを弄れば良さげという事が判りました。

kotlin向けやAndroid向けを選んでプロジェクト生成を行えば、それらをターゲットとしたプロジェクトになるようですがまだそこまでは試せず。

2025/07/14

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

調べごとをして終了。

2025/07/13

AM中に起床。

掃除したり洗濯したり。

kotlin。特に進展なし。kotlinよりも Swingの方がよく分かっていないのを調べる時間が長い気も。

2025/07/12

AM中に起床。

生活備品を調達にお出かけ。洗剤を調達しようとしたのですが、一番近い店ではなぜかほとんどが液体洗剤に置き換わってて、いつもの粉洗剤が見当たらず。少し遠くの店で調達できたのですが、今ってそういう感じになっているのだろうか？🤔 帰ってから我が家の洗濯機って液体洗剤イケるんだっけ？と思い取扱説明書を見てみたら、粉洗剤と同じ投入口に入れれば良い模様。知らんかった。粉洗剤に特化してるのかと勝手に思ってました😓。

kotlin。まだ要領つかめず。クラスをインスタンス化するのに new を使わないようなのですが、 (人間が)関数と区別がつかないような？と思ったりも。あとUnicodeの扱いがイマイチよくわからず。ボタンのテキストに絵文字を使ったら表示されなかったり、ソースコードはutf8で書いてても println()での表示はSJISになってるようだったりと、D言語でもDMDやldc2を使った時と同じくよくわからない所で文字コードの変換が行われているようにも思えたり。ボタンのテキストもprintln()も、chcpコマンドで 65001を指定すれば大丈夫そうだったりするものの、それってアプリでは制御できないじゃん？と思ったりも。謎。

getComponents()で得たコンポーネントから .getClass().getName() で元のクラス名を取得しようとしたら何故か getClass()など無いと怒られました。インスタンスの構造(?)が kotlinか javaかで違うようで kotlinの場合は .javaClass.getName()に読み替える必要があるみたい。 kotlinで Swingを使うからハマるのか？🤔

2025/07/11

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

今日のGoogle検索のトップページのDoodleはラーメンを称えてって事らしいのですが、なんで今日？と思ったら7月11日はラーメンの日らしい (参考ページ)。 2017年に正式制定されたようです。ほぅ....

唐突に「Android Studio」をインストールしてみたり。ひとまずこちらを見ながら動かしてみているのですが、イマイチ要領が得られない感じです🥺。
そもそも kotlinがよく分かっていないので、 kotlincを使ってコード単体で実験してみたり。どうやらJavaのコードを置き換え可能な感じで書けるらしいという事でJavaコードと見比べながら試してみているのですが、なんか見た目が大分違うので対応が付けられない感じです。今のところkotlinではその文法になっているのに合理性をあまり感じられません。 D言語のときは合理性しか感じなかったような気がするのですが。

2025/07/10

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

調べごとをして終了。

2025/07/09

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

少し前にタスクバーのボタンにマウスカーソルをかざすとファイルエクスプローラのアイコンが何故か表示される現象があったのですが、 WindowsUpdate後に再起動したら再現しなくなっていたり。何か変な状態に陥っていたのだろうか？🤔

2025/07/08

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

Web巡回して終了。

2025/07/07

本日休業。AM中に起床。

色々用事を済ませて一日終了。

2025/07/06

AM中に起床。

掃除したり洗濯したり。

スマホに ICカードの読み取り機能があるのを知ったり。何故かスマホの説明書には書かれていないようですが。

調べごとをして終了。

2025/07/05

AM中に起床。

買い物にお出かけ。先週くらいからサイドテーブルを探していたのですが、丁度良さげなサイズのを見つけたので購入。ギリギリ持ち帰り可能と判断したのですが、流石に腕が死ぬかと思った😓。新PCで液晶タブレットを使えるようにケーブルを延長しましたが (以前のメモ)、ローテーブルでは配置や姿勢に無理がありました。今回買ったサイドテーブルは椅子に座って丁度良い高さのテーブルなので、長時間作業だったり作業机としても使えそう。よき。

Windows11のタスクバーのどれかのタスクボタンにマウスカーソルをかざすと、それまで表示されていなかったファイルエクスプローラのアイコンが表示されます。「タスクバーのボタンをまとめラベルを非表示にする」の設定を「なし」にしてタスクボタンをバラしているのですが、アイコン表示が割り込んでくるのでボタンの幅が変わってしまうため、場合によっては一つ右隣のボタンの上にカーソルが乗ってしまう場合があります。なんか邪魔に感じるのですが、挙動を変えるスイッチは見当たらず。

そういや新しいディスプレイは HDMIポートの方はHDRに対応しているらしいという事で、 1年以上ぶりくらいにPS4の電源を入れて確かめてみたり。因みにPS4はスタンバイにしてると夜中に静電スイッチが雄叫びを上げるようになったため電源を抜いたままにしていました。システムウェアのアップデートが必要だったり、PSplusもウォレットの残高不足で自動更新されず期限切れになってました。ところで、システムウェアのアップデート内容がQRコードで示されるようになっていて、その場では詳細の確認ができないようになっていました。単純になんで？🤔とは思ったりも。で、GTsportを起動してみたのですが、アップデートを先に行う必要があったり。しばらく待って終わったので起動してみたところ、オンラインサービスは終わってました😅。一旦そこは良しとして HDRの方ですが、光の輝度がまぶしい感じに表示されていてHDRになっているようでした。壊れたひとつ前のディスプレイもHDR対応だったのですが、まぶしいと感じた記憶は無かったので、 7～8年ほど前とは様子が違うのか？と思ったりも。ただ、HDRがONになっているとPS4のファンが高速回転になりました。 GTsportを終了すれば通常回転に戻る感じです。また、前のディスプレイでは HDMI2.0で接続すると数分後に映像が出なくなるという現象がありました (以前のメモ)。今回はちょろっと確認しただけなので、また後で確かめてみようかと。

2025/07/04

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

調べ事をして終了。

2025/07/03

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

ディスプレイ。昼過ぎに届きました。サイズもデザインも前のに似た感じの「Dell 27 Plus 4Kモニター - S2725QS」というのにしてみました。約35000円也。色味の第一印象は「ちょっと黄色寄り」だなぁと思いました。因みに壊れたのはDell製のUP2718Qという製品でしたが、これはどの色にも寄っていなかったのでハイエンドディスプレイってこういう事なのか？と思った所でした。これまでの感じだと、EIZOのは緑寄り、テレビですがREGZAは青寄りといった感じだったので、製品やメーカーによって何かしら特性はあるのかな？と思ったりも。

今回購入したディスプレイは 120Hz対応なので、違いを見比べられないか？と思ったのですが、 YouTubeって120fps対応はしていないのか。手持ちのアプリでは一応120fpsになってるなぁ？くらいの確認はできるのですが、倍速で描画されてるのでスムーズかどうかを見比べる感じでは無い気も。

120fps表示テスト

そういえば、ディスプレイにHDMIケーブルが付属していたのですが「ULTRA HIGH SPEED」というタグが付いていました。「ウルトラハイスピード」ってなんぞ？と思って調べてみたところ、 HDMI2.1の 8K60Hzや 4K120Hzに対応する 48Gbps伝送可能なケーブルみたいです。因みに、「プレミアムハイスピード」は4K60HzやHDRに対応する 18Gbps伝送可能なケーブルで、我が家では色々と4K対応するのに HDMIケーブルのほとんどを交換しました😓。フルHD(1920x1080)解像度ならば120Hzだとしても、プレミアムハイスピードで十分だと思います。新PCはDisplayPort接続なのですが幸い 8K60Hz/4K120Hz対応のケーブルになっています。古いデスクトップPCのときに NVIDIAドライバをアップデートしたらDP出力が映らなくなってしまったのですが (以前のメモ)、その後もアップデートで直る気配が無さそうだったので、ケーブルを変えてどうにかなるとも思えないけどオーバースペック気味のケーブルでダメだったらドライバが直るのを待つしかないと、ダメ元で交換したら映るようになってしまって、ケーブルって関係あるの？！と思った事がありました。よもやそのケーブルを4K120Hz対応で使う事になるとは想像もしていませんでしたけれども。

2025/07/02

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

先日発注したディスプレイは出荷済みになってるようですが、今日届く予定になってて本当か？と思ったりも。少なくともまだ配送業者ではトラッキングが始まっていないと思われ(18:30時点)。その後、結局21:30頃に営業所に集荷されたようなのでやっぱり届くのは明日。昼までには届くんじゃなかろうかと思ったりも。

2025/07/01

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

普段使いしているディスプレイが突然死。普通に使っていたところ突然画面の下半分がインターレースのように偶数(奇数かも)ラインだけが映らない感じに。むぅ。
ひとまず液タブで対応してみてるのですが流石に無理があるので、新しいのをWebで調達してみる事に。壊れたディスプレイは27インチ/4Kで入力ポートが DP×2, HDMI×2 あるのですが、同じ感じのは無さそうだったので、27インチ/4Kで DP×1, HDMI×2 のを選んでみました。最近のはベゼルが細くなっているので32インチもギリギリイケるか？と思ったのですが、入力ポート要件が合うものが無かったので見送り。故障したディスプレイを買った2017年頃は、 4k/60Hzに対応しているかどうかを見分けるのが難しくて、安いと思ったら30Hzまでしか対応していないとか、スペック表からHDMI2.0対応かどうかが判らないとか色々罠があったように思います。それにしても液晶ディスプレイが壊れるとは想定外だったなぁ....🥺

TOP

古いの
2025.06 2025.05 2025.04 2025.03 2025.02 2025.01
2024.12 2024.11 2024.10 2024.09 2024.08 2024.07 2024.06 2024.05 2024.04 2024.03 2024.02 2024.01
2023.12 2023.11 2023.10 2023.09 2023.08 2023.07 2023.06 2023.05 2023.04 2023.03 2023.02 2023.01
2022.12 2022.11 2022.10 2022.09 2022.08 2022.07 2022.06 2022.05 2022.04 2022.03 2022.02 2022.01
2021.12 2021.11 2021.10 2021.09 2021.08 2021.07 2021.06 2021.05 2021.04 2021.03 2021.02 2021.01
2020.12 2020.11 2020.10 2020.09 2020.08 2020.07 2020.06 2020.05 2020.04 2020.03 2020.02 2020.01
2019.12 2019.11 2019.10 2019.09 2019.08 2019.07 2019.06 2019.05 2019.04 2019.03 2019.02 2019.01
2018.12 2018.11 2018.10 2018.09 2018.08 2018.07 2018.06 2018.05 2018.04 2018.03 2018.02 2018.01
2017.12 2017.11 2017.10 2017.09 2017.08 2017.07 2017.06 2017.05 2017.04 2017.03 2017.02 2017.01
2016.12 2016.11 2016.10 2016.09 2016.08 2016.07 2016.06 2016.05 2016.04 2016.03 2016.02 2016.01
2015.12 2015.11 2015.10 2015.09 2015.08 2015.07 2015.06 2015.05 2015.04 2015.03 2015.02 2015.01
2014.12 2014.11 2014.10 2014.09 2014.08 2014.07 2014.06 2014.05 2014.04 2014.03 2014.02 2014.01
2013.12 2013.11 2013.10 2013.09 2013.08 2013.07 2013.06 2013.05 2013.04 2013.03 2013.02 2013.01
2012.12 2012.11 2012.10 2012.09 2012.08 2012.07 2012.06 2012.05 2012.04 2012.03 2012.02 2012.01
2011.12 2011.11 2011.10 2011.09 2011.08 2011.07 2011.06 2011.05 2011.04 2011.03 2011.02 2011.01
2010.12 2010.11 2010.10 2010.09 2010.08 2010.07 2010.06 2010.05 2010.04 2010.03 2010.02 2010.01
2009.12 2009.11 2009.10 2009.09 2009.08 2009.07 2009.06 2009.05 2009.04 2009.03 2009.02 2009.01
2008.12 2008.11 2008.10 2008.09 2008.08 2008.07 2008.06 2008.05 2008.04 2008.03 2008.02 2008.01
2007.12 2007.11 2007.10 2007.09 2007.08 2007.07 2007.06 2007.05 2007.04 2007.03 2007.02 2007.01
2006.12 2006.11 2006.10 2006.09 2006.08 2006.07 2006.06 2006.05 2006.04 2006.03 2006.02 2006.01
2005.12 2005.11 2005.10 2005.09 2005.08 2005.07 2005.06 2005.05 2005.04 2005.03 2005.02 2005.01
2004.12 2004.11 2004.10 2004.09 2004.08 2004.07 2004.06 2004.05 2004.04 2004.03 2004.02 2004.01
2003.12 2003.11 2003.10 2003.09 2003.08 2003.07 2003.06 2003.05 2003.04 2003.03 2003.02 2003.01
2002.12 2002.11 2002.10 2002.09 2002.08 2002.07 2002.06 2002.05 2002.04 2002.03 2002.02 2002.01
2001.12 2001.11 2001.10 2001.09 2001.08 2001.07 2001.06 2001.05 2001.04 2001.03 2001.02 2001.01
2000.12 2000.11 2000.10 2000.09 2000.08 2000.07 2000.06 2000.05 2000.04 2000.03