AM中に起床。
午前中に散髪に。
午後から急に思い立って秋葉原へ。「REALFORCE R4」を調達。
本物お仕事では社給のノートPCを使用しているのですが、CtrlとCapsLockの入れ替えをソフト的に行えない
事情があったため、ハードウェア的にキー交換が可能な「REALFORCE R2」を使用しています。
元々は2018年6月頃に 指が痛くてその対策として30gを買ってみたのですが
(以前の日記)、あまり改善はせず、加えて
Ctrlキーとして使っているCapsLockキーに突っかかりがあり 普段使いするにはイマイチだったので
しばらく放置していました。コロナ禍でテレワークとなった訳ですが、ソフト的にキー交換ができない
という理由から 2020年3月に再び使う事にしました(以前の日記)。
スペーサーを入れて(R2には標準添付)、ACPも調整して、更にキーキャップもヤスリで面取りするなどして
使えるようにして現在に至っていました。しかし、ここ最近「N」キーの反応が極端に悪い感じになっていて
押しているけど抜けるのでTypoになり、なんかイマイチな状況になっていました。
ハード的にキー交換ができるとなるとREALFORCEくらいしか無いので、そういや最近はどうなっているんだっけ？
と検索してみたら 10月に R4が出ているというのを知ったのと、R2でキータッチ以外にも不満に思っていた点が
軒並み解消されていそうだったので 急に思い立ったという次第。
R2の時は「日本語配列、テンキーレス、キー荷重30g、黒」でしたが、
今回のR4は「日本語配列、テンキーレス、キー荷重45g、白」にしました。
30gを45gに変えたですが 30gだと軽すぎたかな？と思うところがあったので思い切って変えてみました。
色についてはタッチタイピングなので 黒に黒刻印のキーキャップでもあまり困る事は無いのですが、
たまに見たときに「読めん」って思うことがあったのと、R4ではFnキーによる操作の刻印もあることから
「夜にサングラスをする」的な機能不美(造語)は不要と思った次第です。
4mmストロークはしばらく使っていなかったので(本物お仕事はスペーサーを挟んで3mmにしたREALFORCE、
プライベートは3mmのロープロファイルメカニカルスイッチのキーボード)、
ちょっと感覚的な調節が必要なのと 30gに比べるとやっぱり重いかも？と感じましたが、使っていれば慣れるかな？
という感じです。R2とR4ではキーのサイズが微妙に変わっている所があるので、R2のスペーサーはR4では使えなさげ。
キータッチ以外では、R4ではケーブルがUSB-Cで本体から脱着可能になりました。USB-Cは向きがリバーシブルなので、
コネクタ形状が J型の向き L型の向きといった区別も無いので ケーブルの取り回しが良いです。
R2ではCtrlとCapsLockの交換しかできなかったのですが、R4ではどのキーもほぼ自由に入れ替え可能です。
加えて4つのキーレイアウトを保持/切り替えできるようなので、PCのソフト環境に合わせるのが簡単になりそうです。
TANE自身は恐らく使う場面はほぼ無いと思いますが、Bluetoothでワイヤレス対応だったり
乾電池が使える(リチウムイオンは処分が面倒)というのも場面によっては良いかも。
ダメもとで R2のスペーサーを取り外して R4にあてがってみました。すると、一番下の段(スペースキーのある段)が
ほんのりズレているだけで、上から4段分はピッタリはまるようでした。という訳で、下の段の合わない部分の
スペーサをハサミで切り離して、合うところをなるだけそのまま生かしてみたところ、それとなくつかえるんじゃないか？
という感じになりました。スペーサーを挟むとキーの押し込み感覚は無くなってしまうのですが、
R2で慣れてしまっているのもあってひとまずこれで使ってみることに。
ACPは2.2mmに設定されているのを1.5mmに変更。R2と感触的には変わらないかも。
R2でイマイチになってしまっていた「N」キーの反応も問題無し(当たり前かも知れませんが)。よき😄。
そういえば REALFORCEを買った時に レジでボタン電池の回収について聞いたら その場で引き取ってもらえたり。
ありがたや。因みにヨドバシです。
テレワーク。早めに終了。
Web巡回して終了。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。早めに終了。
Fedoraの43ってのがリリースされたようなので、VirtualBoxで動かしているのをアップグレードしてみたり。
壁紙が変わった以外の変化はよく分からず。
テレワーク。早めに終了。
プログラム言語などでの「変数」を「箱」に例えて説明する場合がありますが、これって万国共通なのかしら？
と思って 検索してみたところ AI回答によると 海外でもよく使われる一般的な比喩表現らしい。へぇ。
AM中に起床。
以前手持ちのD言語コードでdmdコンパイラがICE落ちすることがありました。
今年の4月にリリースされた 2.111.0 で起こる話ですが、今日時点で新しいのはリリースされていないので特に何かする
訳ではなかったのですが、Nightlyで直ってたり
しないだろうか？と思って試してみたり。 2.112.0-beta.1 というバージョンだったのですが、
やっぱりICE落ちするようなので修正は(発見も？)されてはいなさそうです。
$ dmd -m64 -O -I. -version=Unicode -version=Windows10 -version=IE5 -c GameFrame.d -of=GameFrame.obj tym = x14 Illegal instruction $ dmd --version DMD32 D Compiler v2.112.0-beta.1 Copyright (C) 1999-2025 by The D Language Foundation, All Rights Reserved written by Walter Bright
AM中に起床。
掃除したり。
そういえば Emacs31系はまだmasterから分岐はしていませんが いつ出す予定だろうか？
Qwen3-VLで画像の内容ではなくフォーマットについて尋ねたところ、なんだかモンヤリした推測交じりの
回答が返って来たり。恐らく画像認識にはデコード済の状態で渡されるので、デコード前のフォーマットに
ついては知りえないという事なのだろうと思われます。「仕組み的に元の画像ファイルフォーマットは判らない」と
回答してくれれば良いようにも思うのですが、何やら頑張って推測するようです。
先日アップデートした新しい gptelのチャットでは回答結果に「#+begin_reasoning ～ #+end_reasoning」というブロックが
表示されるようになっているようです。推論の過程が表示されているようで、これらを踏まえて回答結果が表示される
という感じになっているようです。gpt-oss:20bでは割とあっさりとした内容ですが、
qwen3:30bでは割と長めの(場合によっては最終的な回答よりも長い)自問自答を行っているようです。
英語で表示されていますが、HTMLにエクスポートしてChromeで表示してページ翻訳すると人間にも意味が判るように
推論していて面白いなぁと思いました。画像認識の場合は色々推論して間違えてるってパターンもあるようです😓。
さておき、reasoningブロックは HTMLにエクスポートすると非表示にはできないので、
回答結果を読むのに邪魔になる場合があります。カスタム変数 gptel-include-reasoning を nilに設定すると
reasoningブロックは出力されなくなるようです。
qwen3の推論(reasoning)の中でEmacsユーザーである可能性について触れられている事があったので
「なんで分かるんだ？🤔」と思ったのですが、gptel-directives という変数の中で
「(default . "あなたはEmacs上で動作する大規模な言語モデルで、役立つアシスタントです。詳しく教えてください。")」
って記してあるからっぽい。
言ってなければ判る訳が無いので、判っているという事はどこかで言っているって事になるのかなと思います。
これって対人の時は逆の方向で気を付ける所かも。
直接会話ではない公開チャットのようなもので言ったつもりになったところで、
それをみんなが読んでいるとも 意図通りに解釈しているとも 限らないってのはよくある事です😓。
AM中に起床。
Ollamaのv0.12.7というアップデートが来ていたのですが(ついさっき見たらv0.12.8が出てましたが😅)、
Qwen3-VLというモデルを使用可能になったらしい。
どんなモデルなのかと思って調べてみたら画像も認識できるらしいというのを知り試してみたり。
話は一瞬逸れますが モデルのファイルサイズってダウンロードしてみるまで判らないのだろうか？🤔
さておき、適当に試しながらダウンロードしてみたところ 以下のようなサイズのようです。
$ ollama list NAME ID SIZE MODIFIED qwen3-vl:8b 901cae732162 6.1 GB 7 hours ago qwen3:30b ad815644918f 18 GB 7 hours ago qwen3-vl:30b eda0be100877 19 GB 8 hours ago gpt-oss:20b 17052f91a42e 13 GB 2 weeks ago gpt-oss:120b f7f8e2f8f4e0 65 GB 6 weeks ago
テレワーク。早めに終了。
調べ事。
テレワーク。早めに終了。
GoogleのDoodleがハロウィン仕様のパックマン。ハロウィンは判るのですが何故パックマン？
と思ったところ、1980年の稼働(日本では7月、アメリカでは10月26日)から45周年という事らしい。
テレワーク。早めに終了。
先日のorg-modeで attachment: のファイルがHTMLエクスポートすると絶対パスになる件。
expand-file-nameで展開しているというのもあるのですが、他にも絶対パスになっている事をチェックしているようで、
ちょっと弄れば相対パスにできるという感じでは無さそうだったり。LaTeXの式をレンダリングした画像と
同じような扱いなのかと思いきや全然扱いが違ってて挫けました😓。
テレワーク。早めに終了。
調べごとをして終了。
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
AM中に起床。
掃除したり洗濯したり。
現在開発中の Emacs31系のWindows向けビルドでは yank-media というクリップボード画像の貼り付けがサポートされる予定です。
org-modeでは貼り付けに対応しているのですが、.orgファイルに貼り付けた後にHTMLにexportすると
画像のリンクが expand-file-name で展開された絶対パスになってしまいます。
Cygwinビルドでは ewwで見るのは大丈夫ですが、EdgeやChromeなどの外部ブラウザを使用すると
ファイルパスがCygwinパスになっている為、画像が表示されないという事が起こっています。
クリップボードから貼り付けた画像はデフォルトでは.orgファイルと同じディレクトリの dataという
ディレクトリ内に保存されます。
画像の参照は「[[attachment:clipboard-20251026T121446.png]]」のような感じで、attachment:という
特別なキーワードと clipboard-yyyymmddThhmmss.* という形式の自動生成名から成り、
途中のパスは何かしら自動生成されるハッシュ値的な物(UUIDっぽくも見える)を使用しているようです。
HTMLにexportする際に 相対パスで「src=./data/.../clipboard-...」と記してくれれば良いのですが、
色んなところで expand-file-name で展開した絶対パス名を使用しているようです。
また、設定値の書き方とかで対応できる感じにもなっていないようです。
CygwinパスとWindowsパスの違いの問題もありますが、そもそも絶対パスだと 画像ファイルの置き場所を移動すると
表示できなくなってしまうし、公開Webページとしてアップロードしてもリンク切れになってしまうなど、
デメリットしか無いように思われます。なんとかならないっすかね？とは思ったりも。
minibufferでファイルパス名に文字「?」を入れようとしたら minibuffer-completion-help 実行にバインドされているなぁ？
と思ったり。以前シェルのglobstarなるものを知り、
時々find-diredの代わりに使う事があるのですが、正規表現を少し細かく「**/*.??g」のような指定をしたい
と思ったところ、文字「?」が入れられないので気づいた次第。
.emacsに「(define-key minibuffer-local-completion-map "?" nil)」を記して無効化する方向で。
AM中に起床。通院。
Web巡回していたら、PlemolJPのv3.0.0が
今年の6月29日に出ていたというのに気づいたり。
元になっているIBM Plexの「IBM Plex Sans JP」
がv2.0.0になったのに追従したアップデートだった模様。グリフが大量に追加されているらしいですが、
異体字セレクタに対応している訳では無さげ。
因みに、IBM Plex Sans JP の方はv3.0.0が今年の9月2日に出ているようです
(Releases @ibm/plex-sans-jp@3.0.0)。
また、IBM PlexはGoogle Fontsでもダウンロードできるように
なっているっぽいですが、v1.001なのでちょっと古いのが置かれているようです。
テレワーク。早めに終了。
Emacs30.2で zlc-modeの補完がうまく動いていない件。
29.4の lisp/minibuffer.el を読み込むと解消したので、30.2との差分を調べてみたところ、
なにやら余計なテキストプロパティが追加されるようになっているようです。
以下のようなパッチでひとまず機能するようになりましたが副作用があるかも知れません。
$ diff -u lisp/minibuffer.el.orig lisp/minibuffer.el
--- lisp/minibuffer.el.orig 2025-03-15 22:19:26.000000000 +0900
+++ lisp/minibuffer.el 2025-10-24 19:31:05.140339100 +0900
@@ -703,12 +703,12 @@
;; on the first character of the completion. Make
;; sure the quoted completion has these properties
;; too.
- (add-text-properties 0 1 (text-properties-at 0 completion)
- qcompletion)
+; (add-text-properties 0 1 (text-properties-at 0 completion)
+; qcompletion)
;; Attach unquoted completion string, which is needed
;; to score the completion in `completion--flex-score'.
- (put-text-property 0 1 'completion--unquoted
- completion qcompletion)
+; (put-text-property 0 1 'completion--unquoted
+; completion qcompletion)
;; FIXME: Similarly here, Cygwin's mapping trips this
;; assertion.
;;(cl-assert
$ echo test_message > test.txt $ ls -l 合計 1 -rw-rw-r-- 1 TANE-HP なし 13 10月 24 22:23 test.txt $ /usr/bin/diff -u -N test.txt.orig test.txt --- test.txt.orig 1970-01-01 09:00:00.000000000 +0900 +++ test.txt 1970-01-01 09:00:00.000000000 +0900 ★★★★日付が変 @@ -0,0 +1 @@ +test_message $ /usr/bin/diff -v diff (GNU diffutils) 3.12 Packaged by Cygwin (3.12-1) Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower.
$ ~/develop/work/diffutils/diffutils-3.8/src/diff -u -N test.txt.orig test.txt --- test.txt.orig 1970-01-01 09:00:00.000000000 +0900 +++ test.txt 2025-10-24 22:23:11.567447100 +0900 ★★★★ファイルの日付通り @@ -0,0 +1 @@ +test_message $ ~/develop/work/diffutils/diffutils-3.8/src/diff -v diff (GNU diffutils) 3.8 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Paul Eggert, Mike Haertel, David Hayes, Richard Stallman, and Len Tower.3.12よりも新しいのは出ていないようなので、発見されていないか発見されていても 修正リリースは出ていないという感じ。3.8と3.12の間もいくつかバージョンがあるのですが、 どのタイミングで変になったのかまでは判らず。うーむ🤔。 当面 3.8にロールバックして 3.12よりも新しいのが出たらまた確認するという方向で様子見。
テレワーク。早めに終了。
Emacs30.2で zlc-modeの補完がうまく動いていないのに今頃気づきました😓。
以前、31系では上手く動かなくなっているというのに気づいて
lisp/minibuffer.el の方を対応するしかないなぁという事があったのですが、
その時の「候補文字列のテキストプロパティが無くなっていて、余計な文字列が補完される。」が
30.2でも起こっている予感。と思ったのですが、
テキストプロパティの中に変なプロパティが含まれているのが原因のようです。なんだこれ？🤔
29.4では大丈夫そうで、上手く動くようにした31系と同じテキストプロパティが返っているみたい。
30系で壊れてる感じになっていた模様。
テレワーク。早めに終了。
今更ですが、bashの入力キーバインドに「C-/」でUndo ができるのを知りました。
因みにEmacsスタイルです。今まで押し間違いで存在に気づいたことは無かったので、
コマンドライン編集でUndoを期待するようなことは無かったのだと思いますに、
個人的にはあまり使う場面は無いかも知れません。
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
AM中に起床。
掃除したり洗濯したり。
Emacsのキーボードマクロの中に isearchで W32-IMEから文字を入力するという要素を含めると
うまくマクロ実行できないのを調べたり。キーボードマクロを調べると、
なにやら「with-keyboard-coding」というのが記録されていて、
./lisp/international/isearch-x.el の中でそのキーコードを受け取ったら 関数isearch-with-keyboard-coding
を実行するような事が記されているのですが、そもそも「with-keyboard-coding」というキーが
どこに定義されているのか判らなかったり。どういう事？🤔
AM中に起床。
ちょろり買い物にお出かけ。
あまり数がある訳では無いのですが、使用済みのボタン電池を回収してもらおうと持ち込んだ所、
雑にマスキングテープで包んでいたので穴に入らず一旦断念。それにしても資源ゴミ回収では
コイン型のリチウム電池(CR2032とか)は回収OKらしいのですが、一般的にもよく使うと思われる
LR44とかは回収しないというのがよくわかりません。
ボタン型電池を資源ゴミで回収しないのなんでだっけ？と調べていたところ、
川崎市では 2025年11月からリチウムイオン電池などの二次電池も回収するようになるのを知ったり
(川崎市ページ)。
髭剃りなどは分解不要で回収してもらえるようです。ありがたや。
で、ボタン型電池は水銀を含む場合があるので回収しないという事みたい。
水銀フリーなボタン電池も存在するのですが、見た目で区別がつかないのでダメっぽい。
カラーシャープ芯。先週買った水色は薄すぎたので、
赤と青を購入してみました。色んな色入りってのもあったのですが、0.7mmのが無かったので試せず。
ついでにもう一本0.7mmのシャープペン本体も購入。今回買ったのは300円でまぁ普通。
赤も青も想像した通りの色の濃さだったので、あまり色分けすることはありませんが普段使いしてみようと思ったり。
それよりもシャープペン本体の色が 白と青で、白の本体は重いので青の本体をよく使うだろう色に
した結果、青の本体に赤芯、白の本体に青芯 を入れました。が、絶対に一回は思ったのと違う色の方を選んで
「あぁ...💦」ってなる気がします😓
Emacsの テーマのカスタマイズメニューでは、チェックボックスの描画は絵文字フォントではなくて
画像で表示されています。何気に masterブランチ(31.0.50相当)のEmacsで表示しているのを見ると
なんだかズレた位置にレンダリングされた画像になっているなぁ？と思ったり。
30.2ではそんな事になっていないので、何が違うのか調べようと思ったのですが、
どこで画像を選んでレンダリングして表示しているのかよく分からず。
どうやら lisp/wid-edit.el でwidgetとして管理されるっぽい。なのですが表示の実体は
SVG画像を create-imageやinsert-imageでレンダリングしているようです。さておき、以下のような感じに見えます。
テレワーク。気持ち早めに終了。
そういえば先日知った超連射68kの Ver1.10 って、いつ頃出ていたのかしら？
と思い調べてみたり。
超連射68kのページには
特に明記は無さそうで、クレジットは「©1995 1998」となっていたので、その頃に出ていたのかな？
と思ったわけですが、ゲーム本体が X68000用の xdf形式で置かれていたので、エミュレータでxdfの中を
見てみたところ、CRS68K/DOC/readme.txt に 散逸していたソースとデータを2021年頃からサルベージした
事が記されていました。全てのファイルの日付が「2023-01-01 00:00」になっていたので、
それくらいにビルドされたのだろうと想像します。
Wikipedia
によると、X68000 Z EARLY ACCESS KITに
同梱されていたようで、正確なリリース日は分かりませんが 2023年4月頃だったのだろうと思われます。
という訳で、Ver1.10が出たのは 2023年なので、約27年間気づかなかった訳では無い
(2年くらいは気づいてませんでしたが😅)という事でした。
背景グラフィックが変わっていたりするのですが、リプレイデータは互換があるという事で、
大昔に草の根BBSで知り合った めっちゃシューティングゲームの上手い方の ウルトラ超絶プレイの
リプレイデータを食わせてみたところ ちゃんと再生されました。
テレワーク。気持ち早めに終了。
Web巡回して終了。
テレワーク。気持ち早めに終了。
Windows Update。Emacsのハングテストを継続していたのを一旦終了させて Update後にテスト再開。
テレワーク。早くもなく遅くもなく終了。
全然関係ない流れで見つけた
「【X68000】超連射68k Ver1.10【エンディングまで】」
という動画。ん？エンディングって何？と思って最後の方を観てみたところ、ラスボス倒した後に見たこと無い映像が。
そういや背景画像も見たことない感じになっていて、TANEが知ってるのはver1.00(SZ2.Xの日付は97-12-28 19:57)
だったというのに今頃気づきました😅。
AM中に起床。
NHK総合で「大阪・関西万博閉会式」を放送していたのをBGVで観たり。
結局GoogleEarthでは完成版は見られるようにならなかったですが、GoogleMapの航空写真は完成版になっていたようです。
そういえばGoogle検索で期間指定ができますが、終了日を過去に指定して古い情報を探そうとしてみたのですが、
フィルターが効いていないような気が。
AM中に起床。
掃除したり。
ちょろり買い物にお出かけ。「これ描いて死ね(8)」捕獲。
気にはなっていた「カラーのシャープ芯」をどんなもんかと試しに購入。0.5mmのもあったのですが
0.7mmを選択。でも0.7mmのシャープペン本体は持っていないので本体も購入。
値段を見ていなかったのですが、シャープペンの方が825円だというのに後で気づいて驚いたり😅。
なんでこんなに高いんだ？と思ったのですが、振ると芯が出てくる機構が付いているものだったらしい。
でも手持ちの他のシャーペンは普通のなので振る機構は多分使わない😓。
カラーシャープ芯。水色を買ったのですが色が薄いな。下書きを消さなくても印刷に出ないという利点が
あるようですが薄くてよく見えない😅。他の色も試してみたくなりました。
AM中に起床。
そういえば gpt-ossのモデルって更新されてたりするのだろうか？と思い、
ollama pull してみたところアップデートされたり。pullできるという事は何かしら変わっているという事なのかしら？
「ollama show -v gpt-oss:20b」でモデルの情報を表示してみても、
モデルのバージョンに関する情報は含まれていないようなので、いつ時点のモデルを使用しているか？は判らない予感。
因みに ollama list で出てくる MODIFIEDは pullした時点からの経過時間を示しているので、モデルが更新された
日時が判れば pullした日付と合わせてどの時点のモデルを使用しているかを判別できるかも知れません。
テレワーク。早くもなく遅くもなく終了。
CygwinパッケージのImageMagickが更新されていたので、インストールする前に同じバージョンで
野良パッチの確認をしたり。HEICフォーマットの色化けはバージョンアップで直る予定だったので
そちらのパッチは不要になりますが、透明度付きグレースケールのTGAフォーマットは野良パッチとして
引き続き取り込む感じに。
で、ImageMagickをインストールしようと思ったところ、Cygwin本体も 3.6.5-1 が出ていたので、
インストール前に git pullでログの確認をしたり。pull前から2つの修正が追加されていたのですが
Emacsハング修正には関係していなさげ。インストールしてみて一応ハング再現するか少し様子を見る方向で。
因みに gdb上でemacs-w32を動かすと謎のSIGTRAPが発生するのは変わりないようです。
後、先週から実行していたEmacsハング回避パッチの様子見では
約1週間 Emacsハングは再現していませんでした。
いくつかEmacsを立ち上げてパッケージオリジナルの Cygwin3.6.5-1 でハング再現の様子を見てみたのですが、
数時間でハング再現しました🥺。仕方ないのでワークアラウンドパッチを当てて野良ビルドしたcygwin1.dllと
入れ替えて様子見開始。まぁ大丈夫だろうと思いますが。
テレワーク。気持ち早めに終了。
調べごとをして終了。
テレワーク。早くもなく遅くもなく終了。
GIMP 3.0.6がリリースされているのに気づいたり
(GIMP 3.0.6 Released)。
ちょろっと触った感じでは特に問題無さげ。安定してきている気も。
テレワーク。早くもなく遅くもなく終了。
全く気付いていなかったのですが、magitでの「Tracked files」表示が途中までしか出てないようだったり。
以前、gptelを試すために Transientを更新した後、
magit-20230410.857ではダメになっている箇所があったので、magit-20250912.1136に更新しました。
以前のmagitではディレクトリの中は非表示の状態になっていて、展開したり折りたたんだりできたのですが、
現在のではサブディレクトリのファイルも含めて全て表示しようとしています。
しかし、100までしか表示されていない為、トラッキングしているファイルを探す事ができなくなっています。
なんだこれ？🤔
どうやら カスタム変数magit-status-file-list-limit てのが新しく定義されているようで、
この値がデフォルトで100になっている模様。ここを20000とかに設定すれば 5000以上のファイルがある
Emacsのリポジトリでもトラッキングしている全てのファイルを表示できました。
「Tracked files (xxxx)」の行で TABキーを押せば展開したり折りたたんだりできるので、
全部表示するか 全く表示しないか の二択という感じになるようです。なぜ 操作仕様を変えたのかは不明。
パフォーマンスを理由にしているみたいですが、中途半端なリストを出されても役に立たないし、
リストが必要な人は パフォーマンスを理由にして リストの取得を諦める訳が無いと思います。
考え方が理解できません。
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
Windows11の「ペイント」ってレイヤーを使えるようになってたのか。AI補助とか何気に色々変わっているっぽい。
AM中に起床。
掃除したり洗濯したり。
ちょろり生活備品の調達。本屋に寄ったところ「アオイホノオ(32)」が置かれていたので捕獲。
31巻はなかなか捕獲できず
(1,
2,
3,
4)、死に筋判定されているのか？と思ったのですが、置かれてたので
タイミングの問題だったのか？と思ったりも。ただ、書棚には30巻はあるのに31巻は無かったので
やっぱり31巻には何かあるのかも知れない😅。
AM中に起床。
ノートPCで継続していたCygwinパッチの確認。合計で約3週間(478時間) 3つのEmacsを動かし続けて
ハングしなかったのですが、先日副作用が見つかったので 一旦確認は終了。
Emacsハング対応のCygwinパッチ再考。
前のパッチは SIGALRM の場合は処理を完全にスキップするような感じでしたが、
スレッド数が1の場合は発動しないという条件を追加してみたり。
元々、複数のスレッドでロックが競合した場合に、何故かスレッドが切り替わらない為に
ロックループがいつまでも脱出できないという動きになっていそうな感じでした。
ロックされていた場合はスキップするみたいなコードを入れてみたものの、
ロック状態確認とロック実行の間の時間を理論上0にする事ができない為、ハングしにくくはなるものの
完全対応にはなりませんでした。そこで、ダメもとで SIGALRMの場合は処理を完全スキップする
としてみたところ(以前のメモ) Emacsはハングしなくなったのですが、
先日の alarm() を使ったコードでは SIGALRM が無限に保留される事となり影響があるのが分かった...
という流れです。
で、そもそもシングルスレッドでは ロック競合は起こりえないハズなので、
最初に記した通りスレッド数が1の場合は発動しないという条件を加えてみたらどうか？
と思った次第です。ワークアラウンドとは言え、
ひとつ前のコードと同様に「このパッチ、意図が分からん」に
拍車をかけている感は否めません😓。
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
if (!inside_kernel (cx, true))
{
HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
- cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+// cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
SetThreadContext (*this, cx);
suspend_on_exception = true;
in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..799476e1f 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
while (++ix < (int) nthreads)
{
/* Only pthreads have tid set to non-0. */
+ if (nthreads!=1 && (sig==14 || threadlist[ix].thread->locked () != false))
+ continue;
threadlist[ix].thread->lock ();
if (!threadlist[ix].thread->tid
|| !threadlist[ix].thread->initialized)
テレワーク。気持ち早めに終了。
先日のCygwinパッチの副作用。configureでの検査の中で、以下のコードが終了しないという
感じになっていました。
1 #include <errno.h>
2 #include <unistd.h>
3 #include <signal.h>
4 static void
5 handle_alarm (int sig)
6 {
7 if (sig != SIGALRM)
8 _exit (2);
9 }
10
11 int
12 main (void)
13 {
14
15 /* Failure to compile this test due to missing alarm is okay,
16 since all such platforms (mingw, MSVC) also lack sleep. */
17 unsigned int pentecost = 50 * 24 * 60 * 60; /* 50 days. */
18 unsigned int remaining;
19 signal (SIGALRM, handle_alarm);
20 alarm (1);
21 remaining = sleep (pentecost);
22 if (remaining > pentecost)
23 return 3;
24 if (remaining <= pentecost - 10)
25 return 4;
26 return 0;
27
28 ;
29 return 0;
30 }
テレワーク。早めに終了。
何気に以前作成したdiffの -y のカラーパッチを
新しい diffutils-3.12 に対応してみたり。ところがconfigure実行で sleepのテストがいつまで経っても終わらず。
むむ、これはEmacsハングに対応する Cygwinへのパッチが
影響している気が。configure内で実行しているテストコードを切り出してコンパイル＆実行してみたところ、
確かにいつまで経っても終わらないのですが、Ctrl-Zでバックグラウンドに切り替えてbgで実行継続すると
先に進むようだったので、本題のdiffutilsのconfigureはそれで進めたり。
ひとまずパッチ(diff-y_coloring_patch-3.12.diff.xz)
を置きます。御参考まで。
Cygwinパッチの副作用が見つかったので 対応を考え直す必要があるなぁ....🤔
テレワーク。気持ち早めに終了。
調べごとをして終了。