昔の最近の出来事(2024.03)

2024/03/31

AM中に起床。

掃除したり洗濯したり。

「Emacsの雑記」を更新しました。 29.3でimage-diredを使うとハング状態に陥る事がある件への対応になります(emacs-w32.29.3_20240331.patch.xz)。 ただし、原因が判って対応した訳では無いので、環境に依存するなど何かしらの理由で 再発したり新しいパッチの方が具合が悪くなったりする可能性があるかも知れません。

gdbのTUIモード。 gdbの古いソースアーカイブの中の NEWSなどを見てみたところ、どうやら4.18(4系の最終版; 1999-04-11リリース)で入ったもよう。

＃gdb-4.18.tar.bz2  1999-04-07 01:16 gdb-4.18/gdb/NEWS より抜粋

* TUI

HP has donated a curses-based terminal user interface (TUI).  To get
it, build with --enable-tui.  Although this can be enabled for any
configuration, at present it only works for native HP debugging.

  :
warning: HEAP[emacs.exe]:
warning: HEAP: Free Heap block 00000000000DC680 modified at 00000000000DC6A4 after it was freed

Thread 1 "emacs" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffd460ea413 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) where
#0  0x00007ffd460ea413 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffd4601dd6a in ntdll!RtlAllocateHeap () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007ffd4601b44d in ntdll!RtlAllocateHeap () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3  0x00007ffd460e88d8 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x00007ffd4601d255 in ntdll!RtlAllocateHeap () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x00007ffd4601b44d in ntdll!RtlAllocateHeap () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x00007ffd4605b356 in ntdll!LdrUnloadAlternateResourceModuleEx ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x00007ffd4605b2a8 in ntdll!LdrUnloadAlternateResourceModuleEx ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#8  0x00007ffd4600fb31 in ntdll!RtlGetFullPathName_UstrEx ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x00007ffd460073e4 in ntdll!RtlDosPathNameToNtPathName_U ()
   from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x00007ffd46006af4 in ntdll!LdrLoadDll () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x00007ffd43c556b2 in LoadLibraryExW () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#12 0x00007ffcfc503b6d in cygwin1!.assert () from /usr/bin/cygwin1.dll
#13 0x00007ffcfc503c2c in cygwin1!.assert () from /usr/bin/cygwin1.dll
#14 0x00007ffcfc503ad2 in cygwin1!.assert () from /usr/bin/cygwin1.dll
#15 0x00007ffcfc6d6909 in ?? () from /usr/bin/cygwin1.dll
#16 0x0000000000000001 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb) where
No stack.
(gdb)

(gdb) where
#0  handle_child_signal (sig=0) at process.c:7459
#1  0x0000000100558c34 in deliver_process_signal (sig=0, handler=0x10065f72e <handle_child_signal>)
    at sysdep.c:1741
#2  0x000000010065fa69 in deliver_child_signal (sig=0) at process.c:7545
#3  0x00007ffa53f91d99 in setcontext () from /usr/bin/cygwin1.dll
#4  0x00007ffa540ba2f0 in timegm () from /usr/bin/cygwin1.dll
#5  0x00000000000280a1 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

• 「sig 0」を受け取った時に cygwinのシステムコールに到達するような関数を実行してはいけない。 例えば 元対処で入れていた open(), close()や printf()の先にあるwrite()とか。
• 「sig 0」を受け取った時も 関数handle_child_signal()の処理は行なう必要がある。 sig==0で即時returnしてしまうと終了できないプロセスを抱え続けてしまう。

昼前起床。寝すぎ。

image-diredでハングの件。 printf()とかを仕込みながら様子を見たのですが、やっぱり 以前 ワークアラウンドで入れた、 /dev/nullをただopen()してclose()するだけのコードが入っていればハング状態に陥る事がある感じです。 ただ、前後にprintf()を仕込んでいるとハング状態が再現するのと恐らく同タイミングで 仕込んだprintf()表示も変になっているようで、何かやっぱり変になっている気も。
先日のgdbを使ってループ箇所を特定するのを少し変えて様子を見てみたり。 まず、以下のような手順に変更してみました。

1. gdbでemacsを起動する。
2. ハング状態を再現させる。
3. ハング状態になったら、killコマンドでシグナルを送る。このとき「kill -s SIGSTOP プロセスID」 でサスペンド状態にする。
4. gdbのemacsが停止するのでメモリの値を調べたり色々仕込んでみる。ブレークポイントも追加できる。
5. gdbの c(continue)コマンドで動作を継続する。

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

image-diredでハングの件。これならどう？というのを試してみたところ、直接捕まえられた 訳では無いですが、なんとなく関係しそうな所を絞れたような。 まず、先日まで課題だったどこで無限ループ状態に陥っているのかを特定する方法について。

1. gdbでemacsを起動する。
2. ハング状態を再現させる。
3. ハング状態になったら、killコマンドでシグナルを送る。
4. gdbのemacsが停止するので、ここでバックトレースを表示する(btとかwhereコマンド)。

  :
Thread 1 "emacs" received signal SIGTERM, Terminated.
0x00007ffd46090e90 in ntdll!KiUserExceptionDispatcher () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) where
#0  0x00007ffd46090e90 in ntdll!KiUserExceptionDispatcher () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffcfc58d7de in getppid () from /usr/bin/cygwin1.dll
#2  0x00007ffcfc64a1cb in timegm () from /usr/bin/cygwin1.dll
#3  0x0000000100bc1f4f in ifflag_table ()
#4  0x0000000000000008 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

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

Cygwinパッケージの Emacs 29.3-1がリリースされた模様。早いな。準備が追い付いていない....

明日付けになっていますが、「Emacsの雑記」を 29.3対応に更新してみました。御参考まで。

image-diredでハングの件。ハング状態に陥る時の状況と陥った時の状況を整理。

• Emacs29からですが、サムネイルが表示され始めるまで何故か時間がかかるようになりました (参考)。サムネイルの一覧が表示され始めた時に Emacs自体の操作は一応可能なのですが、スクロールとかしているとキー操作が受け付けられなくなり、 ハング状態に陥るというのが、今の所はトリガーのパターンになっているようです。
  
• ハング状態に陥った時、サムネイル生成で起動された子プロセスは残ったままになっている。 サムネイルの生成ではファイルを直接参照して生成したサムネイル画像をセーブします。 なので何か入力を待っていると考えるよりは、親プロセスとなるEmacs本体がハングった状態に なっているので、終了が見届けられない状態になっているのではないか？と推測しました。
  

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

image-diredでハング。リモートファイルのサムネイル生成中にハング状態に陥る感じだったのですが、 ローカルファイルでもダメな時はダメな感じだったり。どこで無限ループ状態に陥っているのか 特定しようと、ハング状態になったところで「gdb -p プロセスID」でアタッチしてみたのですが、 何かしらよく判らないところで止まる感じになるみたい。

普通に動いている状態でgdbによるアタッチを試してみたところ、 アタッチしたら ntdll!DbgBreakPoint() なるところで止まる模様。何かしらシグナルを受信した時 のように決まったハンドラで止まる感じっぽい。そして ここは通るであろうと思われる場所に ブレークポイントを設定してからcontinueで再開するとブレークポイントで止まりました。 これでうまく無限ループのどこかで止められるとして、 問題は無限ループしていると思われるコードの道筋にブレークポイントをどうやって設定すれば良いか？ というところ。それが分かるのであればデバッガを使う必要は無いのですが....どうしたもんか？🤔

image-diredがハングるのは前から起こっていた現象で(ただし原因は色々)、 ファイルの数が少なければ大丈夫だったりもするのですが、キー入力もフレームの再描画もできない 感じになるので、どうにか原因を突き止めて直したいところです。

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

Emacs 29.3でリモートマシンの画像ファイルを参照した image-diredのテストを行なっていたのですが、 何故か高い頻度で途中でハング状態に陥る感じだったり。Emacsのプロセスが100% で動いているけど キー入力が受け付けられない状態になります。CPUが全力で動いているのでIO待ちでは無さそうですが。 はて....？🤔

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

確認したり直したり。

そういや本日でへっぽこページは24周年を迎えました。毎度見てくださっている方々に感謝いたします。 ふにゃふにゃしたページですがこれからもよろしくお願い致します🙂

AM中に起床。

掃除したり洗濯したり。

CygwinEmacsで ldc2/dmdをflymakeで使う件。 先日作成したスクリプトを少し整えて簡単にテストしてみたので放流してみます (dmdfm_240324a.tar.xz)。 使い方は アーカイブに含まれる dmdfm.plという perlスクリプトの最初の方に 日本語で記しています。御参考まで。

いきなり Emacs-29.3がリリースされた模様 (Emacs 29.3 released)。 ちょっ、何も前ぶれが無かったのと 29.2が出てから 約2ヵ月しか経っていないので 完全に油断していました😓。29.2のIME/その他パッチはリジェクトされずに当たり、 ちょろっと起動した感じではいきなりズッコケたりはしなさげ。 Cygwinパッケージが出るまでの間にテストしてみようと思います。

昼前起床。寝すぎ。

CygwinEmacsで ldc2/dmdをflymakeで使う件。 先日は WindowsパスとCygwinパスの違いを全て Emacs側で吸収するようにしていたのですが、 flymakeのコアに近い部分に Cygwinだったら...みたいな分岐を入れる必要があるのが 大分イマイチでした。で、結局 ldc2/dmdコマンドを perlスクリプトで包んで ファイル名やメッセージをWindowsパスからCygwinパスに変換する処理を スクリプトで吸収するという事にしてみました。とは言え、gcc互換のメッセージに 変換する事はできないので、先日知った FlyMakeDの設定を応用した合わせ技で 対応してみた所、最小の .emacs設定とスクリプトのインストールで ldc2/dmdを使って Cygwinでflymakeが使える感じになってみました。 gdcとコンパイルオプションに互換が無いので、ldc2/dmd用に Makefileの check-syntax: を設定する必要はありますが、 当面はこれでなんとかなりそうな目途が付いた気も。

そういや flymakeを使うのに コンパイラが日本語文字でメッセージを出すと上手く機能しないので、 Makefileの最初の方に「LANG=C」と記しているのですが、プログラミング言語の方も CとかDとか言っている為、環境変数LANGの事を知らないと「LANG=D」みたいな設定が あるのか？と思う人は居るかもなぁ？と思ったりも。 何を設定しているのか意味を理解してもらうしか無い所かも知れません。 ただ、LANG=Cの Cは C言語に由来しているらしくて (参考) やっぱり ややこしいとは思ったりも😓

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

今までちゃんと探せていなかったのですが、 こちらに FlymakeとD言語(このページではdmdを使う)を組み合わせる設定があるのを知りました。 ただ、こちらの設定そのままだとどうにもうまく動かなかったので調べてみたところ、 いくつか直したり追加の対応を加える事で、ひとまずmakeコマンドの中で実行した ldc2のエラーメッセージをパースしてエラー表示できるようになってみたり。 動かす為にflymakeの関数に手を入れているのでもう少し整理が必要ですが、ざっくり

• Cygwinパスのファイル名が渡るので、Makefile内で ldc2に渡す時に Windowsファイルパスに 変換する必要がある。
• エラーメッセージのファイルパスにドライブ名が含まれているとパターンにマッチしない。
• エラーメッセージ中のWindowsファイルパスをCygwinファイルパスに変換しないと バッファへの着色表示が行なわれない。
• エラーメッセージが CRLFで返って来ているので「^M」が見えてしまう。

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

調べ事をして終了。

ゴミ捨てに起きて 二度寝してたら昼過ぎ。寝すぎ。

そういや dubって make -jN のような並列コンパイルをしているように見えないのだけれど、 コンパイルコマンドを1行で済ましているからだろうか？

ちゃんと使えてはいないのですが、そもそも LSPで文法チェックするにあたって、 以下のような事は原理的に可能なのだろうか？と思ったりも。

• 標準ライブラリ意外に 複数のファイルを importしている場合。
  importするファイルも併せてサーバーに送らないと、そんなもの(クラスや関数)は 無いみたいなのはチェックできないと考えられます。

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

serve-dのビルドを試みたのですが、ディスクアクセスしっぱなしのままCPUを使っている訳もなく ハング状態に陥っている感じになったり。何故か diet-complete なるパッケージのビルドが終わらない。 タスクマネージャで見るとディスクのアクティブな時間が100% になったままで、 コンパイラが動きっぱなしになっているため原因がよく判らず。

どうもいくつかのファイルがアクセスできない状況になっているようだったり。 Cygwinで「cat $(find . -type f) > /dev/null」というコマンドラインでファイルが読める事を 検査した結果、いくつかのファイルが「cat: ./bin/ldc2.exe: Input/output error」みたいな状態になっていて、 これらのファイルを読み込もうとしたらハング状態に陥るという感じだったみたい。 ディスクの不良だとファイルを消してから上書きしてもまたダメになる可能性がある為、 I/Oエラーになるファイルをリネームしてから新しくコピーし直したところ、つっかかる事が無くなりました。 一応ドライブチェックはしてみたものの異常は検出されず。うーむ🤔

しかし、mir-algorithmってパッケージがコンパイルエラーでやっぱりビルドできず。なんでだ。
x86でビルドするとダメそうだったので x86_64でビルドしてみたら通過できたり。 release.batと release.shがあり、.batの方は x86ビルドになっているのですが。 release.shは 何向けかは判りませんが、Linuxの他に MinGW64とかでもこちらが使う想定なのだろうか？ 結局 dubコマンド一行が全てのようなので、これが通ればそれでどうにかするという感じだろうか。

しばらく待つと serve-d.exeが一応生成されました。ビルドしたserve-dを 使ってみたところ 一応動いてはいそう。バージョンは v0.8.0-beta.15 ってのになってました。 先日試したWindowsバイナリは 0.7.5ってバージョンでした。 で、ビルドした新しいバージョンでもエラーチェックできないパターンは変わらず。 ブランチの最新で直っているという事は無さげ。

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

serve-dがどのように文法をチェックしているのかソースコードを git cloneして 眺めてみているのですが、どこで何をやっているのかよく判らず。 DScannerなる物が文法をチェックしてっぽいのですが、実際に表示されている エラーメッセージに含まれる文字列がどこにも見当たらない感じで、 一体どうやってるのか謎。

AM中に起床。

掃除したり洗濯したり。

「これ描いて死ね(5)」。まさかの ルゥ・ガルゥ合流。

過去に D言語向けの LSP(Language Server Protocol)を試してみた事があったのですが、 インストールドキュメントなどの通りに設定しても、何やらエラーして 動きそうになかったので放置していました。 Cygwinとの相性問題のようなのですが、如何せん正しく動いている様を 見たことが無いのでそれ以上調べる事もしていませんでした。
で、最近 MinGWで Emacs29.2のビルド確認を行なったのですが、その環境を使えば動いている様が見られるんじゃね？ と思って試してみたところ、動くようだったので少し調べてみようと思った次第。 ただ、ほんのちょっと使ってみた感じでは、括弧の対応が足りないようなのは エラーを検出できるようですが、未定義の変数を使っている みたいなエラーが全然チェック できていないように思ったりも。

     1  import std.string;
     2  import std.stdio;
     3
     4  int main()
     5  {
     6    doubl;
     7    write(a);
     8    return;
     9  }

AM中に起床。

D言語コンパイラのアップデート確認。 毎度の事ですがポン置きできる LDC 1.37.0 (==DMD2.107.1相当)で手持ちコードを コンパイルしてみたところ、何やら Deprecation のメッセージが山ほど出るように なっていたり。LDC 1.32.2 (==DMD2.102.2相当)の間で様子が変わったみたいですが、 約1年間に加えられた変更のどこかで変わったようなので探すのが大変🥺。 DMD2.104.0で非推奨になったっぽい。

$ ldc2 -m64 -O2 -I. -d-version=Unicode -d-version=Windows10 -d-version=IE5   -c FontMan.d -of=FontMan.obj
win32\rpcnsi.d(54): Deprecation: using `in` parameters with `extern(Windows)` functions is deprecated
win32\rpcnsi.d(54):        parameter `__anonymous_param` declared as `in` here

$ cat -n win32/rpcnsi.d | sed '54p;d'
    54          RPC_STATUS RpcNsEntryObjectInqNext(in RPC_NS_HANDLE, out UUID*);

$ cat -n string_cast_test.d
     1  import std.stdio;
     2  import std.string;
     3
     4  int main()
     5  {
     6    writefln("1: %s", "TestString".ptr);
     7    writefln("2: %s", "TestString".ptr);
     8    writefln("3: %s", "Test String".ptr);
     9    return 0;
    10  }

$ ldc2 string_cast_test.d ; ./string_cast_test
1: 7FF6C84E15F6
2: 7FF6C84E15F6
3: 7FF6C84E160D

  char* str = cast(char*)("TestString".ptr);
  writefln("4: %s", str);
  str[0] = 't';
  writefln("%c",str[0]);
  writefln("5: %s", str);

4: 7FF6EC16B5F6
T
5: 7FF6EC16B5F6

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

訳あってPythonコードを読む必要があったのですが、関数がどこに定義されているか さっぱりわからなかったので Emacsのタグジャンプを使ってみたり。 因みに [ceg]tagsの D言語サポートは現在も無いようなので使う事はありませんでした。 さておき、Webで使い方を探したところ、カーソル位置の関数を探すのは「M-.」に バインドされていてジャンプできたのですが、元の場所に戻る方は「M-*」らしいのですが undefinedで割当たっているように見えなかったり。 これまでの経緯はよく判りませんが 29.2では「M-,」になっているようです。 「M-.」で潜る、「M-,」で戻るなので、キートップの刻印的には 「'.'は'>'」「','は'<'」で 覚えやすい気はしたりも。

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

調べ事をして終了。

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

スペースワン カイロス初号機 打ち上げ失敗。一発ではうまくいかないものなのかもねぇ。

あまりの眠さに急速停止。

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

ちょろりモデリング。

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

ちょろりモデリング。

AM中に起床。

掃除したり洗濯したり。

Blenderモデリング。 先週から 少しオブジェクトを追加したり変更を加えてみたりしてました。



先週バージョンでは机の奥行を65cm相当にしていたのですが、ちょっと狭いなぁ？と思ったので 少し広げて75cm相当にしてみたものの あまり広くなった気がしません😓。 今まであまり意識したことは無かったのですが、普通の机の奥行は60cm～80cmくらいのようです。 先週と同じくケーブル接続は一切考慮が無いのですが、 電源やUSB接続を考慮に入れると、角を使ったレイアウトは接続可能な距離が大分限定されてしまうのが 難しいかもなぁ？と思ったりも。 横長レイアウトで考えてみるか....。まぁ CGなので模様替えごっこですが🙂

模様替えごっこで、液晶タブレットを実際どう繋ぐ？って事を考えたとき、 Razerのキーボードのように 液晶タブレットも USBパススルーポートが付いていたらなぁ？と思ったりも。 例えばキーパットのようなUSBの補助デバイスを接続する際、PC本体から 液タブと補助デバイスをそれぞれ 接続する必要があります。もし 液タブにUSBパススルーポートが付いていれば、PC本体との接続は 液タブだけになり、補助デバイスは液タブに接続する事で配線の取り回しが少し楽かも知れないなぁ？ と思ったりも。ただ、複数のUSBポートがある場合 ホスト側と下流とが区別できる必要があるのですが、 そのためだけに ホスト側がケーブル(USB雄コネクタにする為)になっていて且つ取り外せないのは イマイチかも知れません。

AM中に起床。

TARAKO氏死去。

もそもそとモデリング。

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

鳥山明氏死去。68歳でしたか。

ちょろっとモデリング...のつもりが地味に時間がかかったりも。

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

ちょろっとレンダリングテスト。

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

調べ事をして終了。

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

ちょろっとモデリングして終了。

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

Inkscape 1.4向けのスクリーンコンテストの アナウンス が行なわれているようです。年に1回 0.1ずつ上がる感じになっているようです。

AM中に起床。

Blender。慣れない操作を行なって変な事になるとちょいちょい落ちる事があって辛い。

ここ数日、小物のモデリングで遊んでいました。ジオラマみたいなのも良いなぁと思ったのですが、 建築は大がかりすぎるので何か手軽なモチーフは無いかと思ったところ、PCデスクがこんなだったら 良いかもなぁ？というのを考えてみてました。



サイズはほぼリアルスケールになっています。Blenderでは大体が1m単位なので、 例えば キーボードのキーキャップとかは、キャラクタの頭部モデリングのモデルに比べて かなり小さい感じです。ノートPCはまだモデリング途中なので、キーが足りていません。 因みに、机の強度や機器のケーブル接続の事は全く考えていませんので、 実際に配置しようとすると地獄のように面倒臭い感じかも知れません😅。 正面のディスプレイは 43インチ相当のサイズなので、実際に配置すると「画面近っ」ってなりそうかも。 大分広い机にしたつもりだったのですが 物を置くと意外と狭い....

昼過ぎ起床。寝すぎ。

掃除したり。

Blender。もそもそとモデリング。

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

Blender。もそもそとモデリング。