昔の最近の出来事(2025.02)

2025/02/28

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

image-diredが落ちる件。 バックトレースが見られないので、当たりを付けた関数の入口と出口にprintf()を仕込んで どの関数の中でSegfaultしているのか調べてみる事に。ひとまず src/image.c内の 関数 lookup_image() の中のどこかでSegfaultしている事が判りました。 コード量の多い関数ですが、適当にprintf()を置いてどこら辺で落ちているかを絞り込めそう。

printfデバッグで原因箇所まで辿り着けたり。vadd_to_log()という関数でダメになっているみたい。 先日調べた通り、ファイルが存在しない状態で create-image したオブジェクトは 豆腐表示に なりますが、豆腐描画をするか否かの決定はファイルがオープンできるか否かで行なっているようです。 で、ファイルが存在していなかった場合にそのことを記録するのに 関数vadd_to_log()を使用しているようです。 関数vadd_to_log()の中では更にmessage_dolog()という関数を実行するようなのですが、 如何せんメッセージを表示する為の仕組みのようなので、必ず同じタイミングで再現する訳では無い今の状況ではSegfaultが 起こる条件が揃った状態で見る事が難しい状況。
豆腐表示が大量にあるとファイルが見つからないというメッセージが大量に表示され続ける ようなのですが、image-diredでは画面更新も遅くなるので、何かしらメッセージが表示されるまでの バッファが溢れているみたいな感じなのかしら？🤔 という訳で「*Messages*」バッファのサイズを変更する 変数message-log-max を 10000から50000に増やしてみたところ 落ちなくなる模様。そういう事なのか？？🤔

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

image-diredが落ちる件。 そもそも豆腐表示になっている画像グリフの中身ってどのタイミングで埋められるのだろう？ と思って調べてみたり。 例えば画像ファイルが存在しない状態で 「(insert-image (create-image "/path-to/filename.jpg"))」てな感じで実行すると 豆腐表示になります。この状態で /path-to/filename.jpg を作ると、Emacs側の操作は特に 行なわなくても即座に中身が描画されるようです。 一度中身が描画されると画像キャッシュに乗った状態になる為、画像ファイルを削除しても中身はしばらく 描画されたままになります。この状態から「(clear-image-cache t)」でキャッシュを消すと 再び豆腐表示に戻るという感じです。
で、疑ってみたのは、生成途中の画像ファイルを中途半端な状態で参照してしまったから？という所。 そこで、一時的なファイル名で画像ファイル生成を行ない、終わった所で本来の名前にリネームするように してみたのですが状況は変わらず。違うか.....🤔。 まぁ、壊れた画像ファイルを読み込んで落ちるのであれば、それはそれでバグなので根本的な対処が 必要となる訳ですが、流石にそれは無さそうです。アテが外れたのは残念ですが。

gdbのバックトレースで見えている timegm() の周りに何かあるのだろうか....？ バックトレースがちゃんと見られないのが辛い。

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

image-diredが落ちる件。先日 Segfaultした状態だと timegm()という関数を実行してそうだったので、 関数にブレークポイントを設定してみたのですが そこでは止まらず。

まだよく判りませんが、関係しそうな所の当たりを付けてみたり。 image-diredではサムネイル画像は最初は枠だけの豆腐表示になります。 サムネイル画像ファイルが生成されて表示可能になると豆腐表示の中身が埋まって表示されるようになります。 どうもこの豆腐表示から中身が埋まる過程が表示される所で落ちるように見えます。 例えばウインドウ内に表示される分だけ表示し終わると、残りの画像生成で失敗する事は無いように見えます。 ウインドウ内に表示可能なサムネイル画像が埋まったところでスクロールして豆腐表示の分を追いかけていると 100% 途中で落ちるようです。 また、image-diredの 部品関数image-dired-display-thumbs を少し弄って、 サムネイル表示を4つだけにして残りはファイルは生成するけど表示はしないという状況を作っても、 途中でファイル生成に失敗して落ちるという事は無さそうでした。 以上から、何かしらサムネイル画像の表示のタイミングが関係しているのではないか？と思った次第です。 デバッガでバックトレースできれば原因箇所に近づけると思うのですが、CygwinビルドのEmacsでは いつも肝心な所が押さえられない🥺。

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

Emacs 30.1をテストしていて、何故か svg-analog-clockを動かしながら image-diredを実行すると、サムネイルを生成している最中に Emacs本体がサイレント落ち(Segfaultではなく終了)したり。 なんでだ？🤔 再現性があるので少し調べてみるか....

オプティマイズレベルを -O0にして gdbから実行してみたところ、若干再現しにくいようですが、 Segfaultで落ちたり。ただ、Emacsで落ちているのではなくて cygwin1.dllの中で落ちているっぽい。 バックトレースでは Emacsのフレームが現れず。うーむ。

:
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00007ffc3b461548 in ntdll!RtlVirtualUnwind () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) where
#0  0x00007ffc3b461548 in ntdll!RtlVirtualUnwind () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007ffc3b461040 in ntdll!RtlVirtualUnwind () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007ffc3b460e7b in ntdll!RtlVirtualUnwind () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#3  0x00007ffc3b4824a8 in ntdll!RtlRaiseException () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x00007ffc3b4d13ce in ntdll!KiUserExceptionDispatcher () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x00007ffc14520ae4 in setcontext () from /usr/bin/cygwin1.dll
#6  0x00007ffc146482f0 in timegm () from /usr/bin/cygwin1.dll
#7  0x00000000001903ae in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

AM中に起床。

掃除したり。

Emacs 30.1 が出てました (Emacs 30.1 released)。 毎度長いリリース作業おつかれさまでした。

早速、IMEパッチをあててビルドを試してみたり。パッチは30.1-rc1のままでリジェクトは無し。 ビルドも問題無く、ちょろっと使った感じではいきなり落ちたりはしなさげ。 Cygwinパッケージが出るまでテストする感じで。

AM中に起床。

image-cropのinfoを眺めていて、「C-u i x」でimage-cutを実行すると、最初に塗りつぶしの色を 選べるというのを知りました。read-colorという関数を使っていて、 TABキーで補完すると色見本の候補が出てきます。でも、RGBの色しか指定できないようで、 RGBA指定できれば半透明塗りつぶしもできるのになとは思ったりも。 因みに カスタム変数image-cut-color に塗りつぶし色は設定されているので、 外付けにはなりますが RGBA指定できる手段で予めこの変数に設定しておくという手はあるかも知れません。

そういえば、以前 Emacsのマスターブランチで yank-mediaというクリップボードの画像データ貼り付けコマンドが Windowsビルドでも使えるようになったと知りました。 Emacs 31.0.50で試してみたり。使う為にはいくつか条件があるようです。

• 貼り付けできるモードは限定されている。今の所 org-modeだけ？
• PrintScreenで保持したクリップボード画像は貼り付けられない。 Webブラウザで表示されている画像上で右クリック→「画像をコピー」で保持した 画像データや、「Win+Shift+S」で撮ったスクリーンショット画像は貼り付けられる。
• org-modeで開いたファイル上で 「M-x yank-media」を実行するとカーソル位置に 「[[attachment:clipboard-20250223T115605.png]]」といった感じのリンクが生成される。 データの実体はorgファイルと同じディレクトリにdataというディレクトリが生成されて その下にファイル保存される。

AM中に起床。

HTMLのimgタグに 「<img src="data:image/jpeg;base64,[base64 -w 0 foo.jpg とかでbase64エンコードした文字列]" alt="foo">」 のように書くと画像埋め込みできるというのを知りました。ewwでも表示対応されてました。ほぅ....

何気にリモートマシンのC言語のソースコードを pscpやplinkで開いて、「M-x gdb」でデバッガ起動すると リモートの実行ファイルをデバッグできるようになっていたり。いつの間に。 もしやと思い「M-x compile」で makeを実行してみたところ、こちらもリモートでmakeが実行されました。 いつの間に。てことは、現状うまくいっていないリモートファイルのflymake (最後のメモ)さえ動けば個人的にはそれで十分なのですが。

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

いわゆる筋肉痛の傷みがどういうメカニズムで生じているのかまだ解明されていないというのを 今日知りました。医学って進んでいるのか進んでいないのかよく判らない。

PouetにLovebyte 2025の 結果が出てたり。 毎度の事ですがエントリー数が多いな😅。

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

Emacs 30.1 RC1 が来てた模様 (Emacs 30.1 RC1 is available)。 問題が無ければ今度の日曜日に30.1としてリリースする模様。
IME他パッチを当ててビルド。パッチ自体は 30.0.93でCygwinビルド失敗対応をしていた分 (以前のメモ)が コンフリクトしてリジェクトされましたが、それはオリジナルの方を使うで問題無し。 configureへのパッチがFAILしたので ./autogen.sh 実行で対応。 ひとまず問題無くビルドは完了できて、ちょろっと使った感じではいきなりズッコケたりはしなさげ。 30.1がリリースされるまでテストしてみよう。

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

Web巡回して終了。

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

調べ事をして終了。

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

Web巡回して終了。

AM中に起床。

掃除したり洗濯したり。

Emacs 30.0.93の次が出る気配が無い。

AM中に起床。

素の Emacs 31.0.50で壊れている所が直っているかを見てるのですが、 基本的には直っていないところばかりです。 それよりも壊れている所が増えていて、なんだこれ？って感じです。 リリースサイクルに入ってからリリースされるまでの期間が長すぎる弊害のようにも思えます。 その間にmasterブランチが破壊されていてもほぼ誰もテストしないので、 次のリリースサイクルに入るまで気づかれないままになっているように思います。 結局のところ、masterブランチの品質が悪いのをリリースサイクルでデバッグしているが為に リリース期間が伸びているという感じに思えます。例えばEmacs29の時のtree-sitterとか。 先日記した通り、masterブランチの品質については基本的に テストが甘いままコミットしているからだろうと考えます。 まぁ、フリーソフトなので好きにやってもらって構わないのですが、 素人目に見て もうちょっとテストしてからコミットしないのはなんで？と思う所はあります。

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

GIMP-3.0の RC3が2月10日付けでリリースされてた模様 (GIMP 3.0 RC3 Released)。 インストールしてみたところ、スプラッシュ画面の画像は 3.0.0 RC2になっていますが RC3のようです。 RC2の時には「ぼかし→焦点ぼかし」が落ちていたのですが 修正されているみたい。 ちょろっと動かしてみたところでは変な事には遭遇しませんでした。 大きな問題が出なければ次にはリリースされるんじゃないか？と思ったりも。

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

Web巡回して終了。

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

ビルドした Emacs 30.0.93のバイナリが落ちる件。WindowsUpdate前まで落ちず。 WindowsUpdate後に様子見を再開。

Emacsのキーバインドで「(kbd "C-M-<up>")」や「(kbd "C-M-<down>")」に コマンド割り当てを行なってたのですが、リモートデスクトップ接続ではキーがどこかに食われている ようだったり。むぅ。

昼前起床。

掃除したり。

デスクトップPCの新しいのを見立ててみようかと思ったのですが、BTOのカスタマイズの選択肢に 想定したものが無くなってて希望する構成にできなかったり。うーむ。

ビルドした Emacs 30.0.93のバイナリが落ちる件。先日から動かしている分については落ちたりハングはせず。 明日のWindowsUpdateまで動かして、その後またしばらくテストする感じに思ったり。 ただ、雰囲気的に多分大丈夫そう。

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

唐突ですが、現在のマスターブランチである Emacs 31.0.50 をCygwinでビルドしてみたり。 因みにパッチは無しで「./configure --prefix=/usr --with-w32 --with-imagemagick --with-native-compilation=no」 でビルドしてみました。見たかったのはカラー絵文字対応されているというのがどんな感じかという所。 で、ビルドは問題なくできてemoji-list コマンドでもカラー絵文字表示されるようです。 しかし、「C-x C-+」で表示を拡大していくと描画がバグるようです。 以下はテキストプロパティでサイズを変えて表示してみた画面です。



左が 素のEmacs 31.0.50での描画。 あるサイズを超えると正しく描画されないみたい。コードは全く見ていませんが、メモリサイズとか決め打ちになってないか？ という雰囲気が漂っている気がします。因みに右は Emacs29.4で拙作のカラー絵文字パッチを適用した版です。 まだ 30.1も出ていませんので、31.1が出るまでに気づいて修正されるのに期待したい。
それにしても大分前から薄っすら思っているのですが、全体的に キワ の動作確認が甘いようには思います。 ちょろっと動かして動いたからコミットしたみたいなのが多い。最悪動かさずにコミットしていると思われる場合もあり、 追加されたと思ったらすぐに修正コミットが入ったり、 最悪revertしたりという事が多いなぁと感じます。まだ修正がすぐ入るのはマシな方で、 image-crop.elの Windowsで違うconvertコマンドが実行された時の判定コード のバグ (以前のメモ)とか、一向に気づかれない(31.0.50でも直っていない) のはなんでだ？と思ったりもするところです。

ビルドした Emacs 30.0.93がいつの間にか落ちたりハングしたりする件。 いくつか起動してみているのですが、24時間ほど経過したところでは落ちてはいません。 要因がいくつかありそうなのでいったん整理。

• Cygwinアップデート後、再ビルドせずにアップデート前にビルドしたバイナリを使用していた時には落ちていた。
• Cygwinアップデート後に再ビルドしたバイナリを gdbに乗せて実行したところ、しばらくして ウインドウ最小化→元のサイズ にもどったところで描画が更新されない状況になった。ハングはこの一回。
• その後、再ビルドしたバイナリをいくつか起動してアクセサリ類などを動かして確認してみるも 落ちたりハングは再現せず。

AM中に起床。

何故かビルドした 30.0.93の emacsバイナリが起動後しばらくほっておくと、いつの間にか 落ちたりハングしたりするようになったり。Cygwinをアップデートした後に再コンパイルしていなかったので、 それも試してみたのですがあまり状況変わらず？ Cygwinアップデート前(ver 3.5.4)は数週間起動しっぱなしで 問題無かったので、またCygwinに関係しているのではないかと推測しています。困った🤔。

AM中に起床。

久々にCygwinをアップデート。CygwinのMLで ハングが起きる問題が報告されていて、 何度か修正してはまだ直ってないといったやりとりが行なわれていたようなので様子見していました。 バージョン 3.5.7で一旦ほとぼりがさめたようなのでアップデートしてみたという次第。
Rもアップデートされていたのですが、前の版でMinGW系のdllをロードしようとして失敗する件 (以前のメモ)は直っているようです。

org-modeを git pullしてみたところ、画像のインライン表示のコードが大幅に変更されているようだったり。 ひとまずオリジナルのままで試してみたところ、JPEG2000フォーマットのファイルが表示できなくなりました😓。 画像の幅プロパティを省略したときに画像フォーマットによってインライン画像が表示できないのを ワークアラウンドしていたのが (参考)やっぱり必要で、パッチを当てるファイルが org.elから ol.elに変わったという感じでした。 因みに、これまでは「C-c C-x C-v (org-toggle-inline-images)」でインライン画像表示のON/OFFをトグルできましたが、 最新では 画像表示ON コマンド(org-link-preview) となっているようです。 表示OFFするには org-link-preview-clear(キーバインド無し) で行なう必要があるようです。 画像を表示すると本文を見渡しにくくなる場合があるので 画像表示のON/OFFトグルは頻繁に使用します。 そんな訳で個人的には最新版は操作性が下がっているという気がします。

タイピングplus。リトルドラゴンに遭遇しているのですが、最近指が痛くて長時間練習ができません😥。

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

Web巡回して終了。

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

Emacsのewwの仲間コマンドに eww-search-words というのがあります。 Googleを検索に使うような設定にしてあったのですが、いつの間にかGoogleのサイト側が JavaScriptが有効でなくては機能しなくなっているのに気づいたり。 eww-search-prefixというカスタム変数を何かしらWeb検索してGoogleに切り替えていたのですが、 デフォルトは duckduckgo.com を検索サイトとしているようです。 少なくとも今のままでは検索コマンドとしての用事にならないので 「(setq eww-search-prefix "https://duckduckgo.com/html/?kl=jp-jp&q=")」 てな感じに設定してみたり。 デフォルトのままだと日本語以外のページが先に出てくるので、日本語ページで検索する感じにしてみました。 まぁ、日本語文字を含んでいれば日本語のページが出てくるようですが、そのような検索を必ずしも できるとは限らないのでひとまずこれで。

よくよく調べてみたら eww-search-words だけの問題でも無くて、ewwで Googleのページを開いて 検索文字を入れてもやっぱりダメになってるなぁ？ w3mは大丈夫そうなので ewwの問題なのか？🤔

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

Web巡回して終了。

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

Web巡回して終了。

AM中に起床。本日休業。

掃除したり。

生成AI。仕組み的に単にチャットしているだけで情報が漏れるんだっけ？とは思ったり。 会話から新たな事実を入力したとして、それを事実として学習データに反映するような 仕組みが無いのであれば、情報は漏れないようには思ったりも。 もし、聞いたら答えが返ってくるようであれば、既にデータが漏れていて学習データに 反映されてしまっていると思うのですが、それは何を元に学習したか次第かと。 逆にどこかで漏れているのは判るので、例えば「(どこぞの)アカウント〇〇のパスワードを教えて」 とかで正解が返ってくるようであればパスワードを変更した方が良いとはなるかも？ ただ、そうなってると既に色々と手遅れな状態かも知れませんが😓。

AM中に起床。

VirtualBoxのFedoraを使うようになってから、VMwareの方は39のままほったらかしになっていたのですが、 VMwareのFedoraもアップグレードしようとしたところ、ルートファイルシステムの空きが足りなくて アップグレードできないと言われたり。なにそれ面倒臭い。50GBくらい足りないと言われているようなのですが、 アップグレードになぜそんなに必要なんだ？🤔 納得できない。
ひとまずバックアップもあるので不要なファイルを消してディスクを空けてみたところイケました。 最初は /homeの下(/dev/mapper/fedora-home)を空けていたのですが、 /の下(/dev/mapper/fedora-root)に空きが足りないというメッセージだったので、/homeの下を空けても ダメなのか？と思ったのですが大丈夫でした。文字通りの解釈に対して対応しようとすると、 lvextend や lvreduce といったコマンドを使ってボリュームを拡張したり縮小したりする必要があるっぽいのですが、 そんなのVMでしかできないし、面倒臭い＆間違えると死ぬ 恐れがあるようなので、やりたくは無いところです。

全く気づいていなかったのですが、 SAIのページの最初の方で 2025年1月27日付けで Ver.1の不具合対応(のテストリリース SAI Ver.1.2.6-Beta.3 32bit)が出ていました。 いつも Ver.2の辺りにスクロールした状態でリロードで表示している為、ページの他の部分の更新に気づいてませんでした😓。

それにしても Emacs30.0.93の次が出る気配が無いな....

AM中に起床。

何気にVirtualBoxのFedoraを40から41にアップグレードしてみたり。 もしものためのバックアップに時間がかかり過ぎてしまい、壁紙以外の変わりどころはあまりよく判らず。