昔の最近の出来事(2021.09)

2021/09/30

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

東京都コロナ感染者。新規は 218人。

しばらく Cygwin64 のパッケージをアップデートしていなかったのでアップデートしてみたり。 ここ数か月間にCygwin32の方で新たに入れたり野良ビルドしたものなどを揃えてみてるのですが、 BPGのエンコーダーが何故かビルドできない😓。リンクに失敗します。 コンパイルオプション -fno-asynchronous-unwind-tables が付いていたのを外せばリンクに失敗せずにビルド成功。 一応エンコードはできていそう。なんだ?🤔

2021/09/29

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

東京都コロナ感染者。新規は 267人。

さいとう・たかを氏が亡くなられたらしい。84歳。ゴルゴ13の連載は継続されるらしい。 プロダクション制の強味を感じます。 以前 「漫勉」で出てた時は78歳でしたが、 過去の日記をgrepしてみると 2006年2月5日の日記で記したものがありました。 この時で69歳だった訳で。 ところでWikipedia で知ったのですが「リイド社」って さいとうプロダクションの出版部門が分社化されたものなのだそうな。ほぅ....

Emacsのgitログを眺めていたら、Cygwin向けのELISPのネイティブコンパイル対応が入っているようだったり。 これだけで対応できるの?という変更だったのでコンパイラ対応次第なのか?と思ったり。 で、CygwinのMailingListアーカイブを見てみると、emacs-28.0.50のテスト版の アナウンスが出てました。 32bitではforkのエラーが発生するので今の所 64bit版だけのテストみたい。むぅ🤔。 でも 32bitでの問題対応も含めてのテストみたいなのでそこはひとまず様子見。 さておき、手順だけを見る限り autorebaseはテスト版を使う必要があるみたいですが、 コンパイラは gcc-core のパッケージで大丈夫っぽい。...もしかしてlibgccjitって要らないの?🤔。 テスト版のautorebaseは .elnがリベース対象になっているような事が記されている所を見ると、 ダイナミックモジュールのような仕組みで切り替わるという事なのかしら? 因みに、emacs-28のブランチは まだできていないみたい。

2021/09/28

本日臨時休業。接種から22時間では回復しませんでした😓。結局 今日は1日ぐったり。 本物のインフルエンザ(コロナはインフルじゃないけどインフルしかかかった経験が無いので)などと違うのは咳やくしゃみは出ない所だけで、 本当にインフルエンザにかかったかのような体の反応(悪寒がする、暑いのに汗が出ない、など)になりました。 生ワクチンと違って 模擬なのによくできたワクチンだと感心しました。

東京都コロナ感染者。新規は 248人。
解除されたことでどう行動して良いかわからない。わからないなら今まで通り変えなければ良いと思います。 わからないのに何も考えずにデタラメに変えるからおかしなことになるのは既に実績があると思います。 やっぱ8月の「感染したら死ぬかもしれない」という状況が減少作用としては強かったのではないかと考えます。 医療体制の拡充は予防医療ではありません。いくら拡充したところでそれを上回れば結局足りなくなるのは目に見えているので 「感染したら死ぬかもしれない」(==予防に務める) という状況は変えなくて良いと思います。 ここでは何度も記していますが、感染予防の手を緩めて良いのは 新規感染者が出なくなった時だけ。 即ち緩めて良いタイミングは今まで一度も無い。
抗原検査キットの薬局販売。結局精度は低いようで、陽性だった時以外の結果は信用できないと言っているように聞こえます。 ほぼほぼ意味は無いように思えますが、「陰性だからOK」みたいな事を言う人は居るのだろうなと思います。 デタラメな使い方をすると 科学的に全く根拠の無いサプリメントや健康器具と同じ感じになってしまいそう。 素人に使わせるもんじゃないように思えます。3000円ぽっちで得られる安全など無い。 むしろここまで意味があるとは思えない物を承認するとか、利権が関係しているんじゃないかと勘ぐってしまいます。

Inkscapeの1.1.1が出ている模様(アナウンスページ)。 先日、バグ修正リリースを刻んで欲しいなぁと書いた所だったので偶然にしてはタイムリー過ぎる😃。

2021/09/27

本日休業。AM中にワクチン接種2回目を実施。

東京都コロナ感染者。新規は 154人。月曜だしな。
全面解除するつもりのようですが大丈夫か? 解除した途端に全力で動こうとする気満々の 酒類を提供する飲食店の感染対策意識は大丈夫か?と思わなくもありません。 「完璧な感染対策を行って迎える」って前置きは無しで、商売の話だけをしているように見えるのですが、 結局ダメなのはそういう所だったでしょ?というのが個人的な感想。 感染対策についての前置きはしているにもかかわらず マスコミが切り張りしているのであれば、 そこをちゃんと言わないと、また槍玉にあげられる事になると想像します。

夜になったら熱っぽくなってきた。

2021/09/26

AM中に起床。

掃除したり。

東京都コロナ感染者。新規は 299人。

そういや「豆しば」のCMを見る事があるのですが、今頃になって あれって何のCMなのだろう?と思ったり。 豆しばのWikipediaによると 「豆しば」というキャラクターのブランディングCMらしい。 「公益財団法人 日本豆類協会」との接点は無いっぽい。

Inkscapeの1.0が出て以降、スナップショットビルドやナイトリービルドといったものが置かれなくなったように思ったり。 1.1で直して欲しい描画のバグとかあるのですが、 Windows用のInkscapeをソースから野良ビルドするのは敷居がかなり高そうなのでやろうという気になれません😓。 1.0から1.1の期間は1年あったのですが、もう少しマイナーなバグ修正リリースを刻んで欲しいなぁという気はします。
もう少しInkscapeの公式ページをよく見てみたら、 こちらのページに開発版のバイナリが置いてあるようです (現時点では1.2の開発版)。 7zアーカイブなので任意のディレクトリに展開して bin/inkscape.exe を実行すれば良いっぽい。 定規で長さや角度を計る事ができるのですがフォントのサイズが小さい且つサイズ指定をしても変わらないバグは 修正されていました。1.2の開発版なので1.1とUIが少し違っていますが、グラデーションフィルの編集がかなり分かりやすく なっているように思いました。当面1.2の開発版を使ってみる事にしよう。

2021/09/25

AM中に起床。

東京都コロナ感染者。新規は 382人。減速しているな。

Google Chromeをコマンドライン実行する事で指定したファイルやURLを PDF保存する方法があるのを知ったり。 検索するといくつか方法が記されたページが出てくるのですが、微妙に情報が古いようで こちら のChromeのコマンドラインオプション定義などからCygwinのbash上からは次のようにするのが良いっぽい感じでした。

$ /cygdrive/c/Program\ Files\ \(x86\)/Google/Chrome/Application/chrome.exe --headless --print-to-pdf="D:\フルパス\foo.pdf" --print-to-pdf-no-header  "file:///D:\フルパス\foo.txt"

で、Emacsから実行できるようにしてみました (to-pdf_20210925a.tar.xz)。 ファイルの上の方に使い方をちょろっと記していますが、やっている事は前述コマンドラインを実行すると いうものです🙂。テキストファイルはそれっぽく、HTMLやSVGはレンダリングされた結果で、画像も一応イケると いう感じでPDF変換できるみたいです。PDFのファイル名は簡単化の為に元のファイル名に.pdfを付加するだけにしています。 例えば foo.txt は foo.txt.pdf になります。 倍率とかも指定できれば良いのになぁ?と思うのですが、PDF変換用途で使われる事は想定していないと思われるので こういうものかもなとは思ったりも。
Cygwinの emacs-w32 でしか確認していないので、他のOSやビルドでの実行では カスタム変数 to-pdf-chrome-path とかを変更する必要がありますがよしなに。

2021/09/24

本日休業。しかし朝から検査で病院に。1.5時間程度で終了。

東京都コロナ感染者。新規は 235人。祝日の翌日だしな。

録画消化してぐうたら過ごしたり。

2021/09/23

AM中に起床。ゴミ捨て。

東京都コロナ感染者。新規は 531人。

SVGをPDFに変換するツールって意外と無いっぽい というのを知ったり。

2021/09/22

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

東京都コロナ感染者。新規は 537人。やっぱ減速している気が。

そういや今まで全く結びついていなかったのですが、SVGのテキスト描画でカラー絵文字ってレンダリング できるんだっけ?と思ったり。 Emacsで絵文字を含む文字列を描画するSVGを作成して「C-c C-c」で描画してみると イケました🙂。ほぅ....
因みにInkscape(Ver1.0, 1.1とも)では絵文字はモノクロになります。 且つ絵文字だけだと少し見切れてレンダリングされるのでイマイチ使えない感じになってます。 絵文字と一緒に空白文字を含む文字列にすれば見切れなくなります(ただし表示拡大率が大きいとやっぱりダメ)が、 そういうものなんだっけ?感はあります。

2021/09/21

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

東京都コロナ感染者。新規は 253人。ハッピーマンデー明けの火曜だからなぁ。
今週の連休から数えて2週間後の状況によるとは思いますが完全解除は無いだろ。 人出に強い相関無しに新規感染者数が減っている要因は、慎重に動いている人達が多いからだと考えられそうです。 しかし、観光地は慎重さを欠いた理由で出ているケースが見受けられるようで、このタイプは予防対応が弱くなる ように思えます(数値的な根拠は無い。しかしそう仮定しないとこれまでの拡大/減少の変化と合わない)。 リバウンド傾向が見られた場合は恐らく弱い予防対応で動いた人達が要因になっているものと想像できると考えます。

ちょろり調べ事。

2021/09/20

AM中に起床。

掃除したり洗濯したり。

東京都コロナ感染者。新規は 302人。月曜で祝日なのでノイズでしょう。

手持ちのTGAローダーを555RGB対応してみたり。確認するのに そもそもどうやって元データを作れば良いんだ? という感じだったのですが、ImageMagickのconvertコマンドで以下のような感じでJPEGなどから変換できるっぽい。

$ convert foo.jpg -depth 5 -compress none rgb555col.tga       #RLE圧縮無し
$ convert foo.jpg -depth 5 -compress rle  rgb555col_rle.tga   #RLE圧縮有り

ひとまず対応出来た気が。そういや、ちゃんとした(?)マッハバンドを久しぶりに見た気がします😅。
ところで、マッハバンドのWikipedia を見ると、デジタル画像処理でのマッハバンドという呼び方は間違いだと記されてました。 リンクの中にColour bandingのWikipediaが 示されていましたが、英語圏での言い方はカラーバンディングなのかしら?🤔

2021/09/19

AM中に起床。

東京都コロナ感染者。新規は 565人。

PS5に来る予定の「Horizon Forbidden West」がプレオーダーになってるみたい。 来年の2月18日発売になってたのでもうすぐかも。と思ったらPS4にも来る事になってるな?

gimp-2.10.28が来ていたり。3.0.0は年末辺りに来るのかなぁ?と勝手に予想。

2021/09/18

昼前起床。

東京都コロナ感染者。新規は 862人。減速気味か。まだ多いんだけど。

そういや、screenコマンドの最新バージョンは4.8.0 (2020年2月5日のリリース)ですが、 このバージョンではtruecolorは使えません。その後、どうなってるのかなぁと思って少し調べてみるも、 あまり変化は無い感じ。次のリリースがいつになるかは判りませんが、 以前 gitリポジトリのソースをCygwinでビルドできなかったので 4.8.0より後のバージョンでtruecolorがサポートされてパッケージ対応されるのを期待したい所です。

2021/09/17

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

東京都コロナ感染者。新規は 782人。

image-modeの件。lockを入れてみたり試してみたのですが、結局、ウインドウ状態が変化した時の run-with-idle-timer を使った遅延リサイズ表示をやめるだけで大丈夫そうでした😓。 以下のように 変更を加えた 関数image--window-state-change を .emacsで再定義してみました。

(require 'image-mode)

(defun image--window-state-change (window)
  (image-fit-to-window window)
;  (when (numberp image-auto-resize-on-window-resize)
;    (run-with-idle-timer image-auto-resize-on-window-resize nil
;                         #'image-fit-to-window window))
  )

LinuxのEmacsでも大丈夫そう。 副作用として、即時追従となりますので 変数image-auto-resize-on-window-resize の値を増やしても 遅延追従とはなりません。あと、即時追従するので状況によっては操作にもっさり感が出ます。 以前考えた 「リモート画像ファイルの場合はオートスケール表示をOFFにするワークアラウンド」は、 もっさり感は無いですが run-with-idle-timer は使うので もしかするとハマりパターンが残っているかも知れません。 という訳で、遭遇した不具合は一通り回避したかな?という感じです。
image-modeやimage-diredでの一連のハマりの通り、非同期実行とかタイマーを使った処理は TRAMPとの相性が良くなさそうです。もし突っかかる場面に遭遇した時にはチェックすべきポイントになるかも知れません。

二つのリモート画像ファイルをウインドウを2分割してそれぞれのウインドウに同時表示しようとすると、 二つ目のファイルの読み込みに失敗する模様😓。やっぱりTRAMPの競合が起こるケースがあるようです。 どうやら、「/ssh:....」だとダメですが「/scp:....」ならば問題無いようです。 リモート画像ファイルを表示する時は「/scp:....」を使った方が良さそうです。なんか難しすぎる🥺

2021/09/16

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

東京都コロナ感染者。新規は 831人。

image-modeの件。実験コードを入れながら調べている所ですが多分こうなんじゃないか?という推測。 window-state-change-functionsというウインドウの状態が変わったら反応するフックがあって、 このフックで 関数 image--window-state-change が実行されるようになってます。 この 関数 image--window-state-change を前方に辿ってみると 関数 image-toggle-display-image が実行される ようになってました。 という点を踏まえて考えると、初回のimage-toggle-display-image実行でリモートファイルの読み込みが完了していないのに ウインドウサイズの変更により image--window-state-change からのimage-toggle-display-image実行 が行われて、結果 image-toggle-display-imageが実行される事により生じる TRAMP読み込みが輻輳しているんじゃないか?と推測しています。 まだもう少し調べてみるとして、多重実行にならないようにmutex lockっぽい仕組みを入れる必要があるのかも。 具体的にどうやるのが良いのかは判りませんけど。

2021/09/15

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

東京都コロナ感染者。新規は 1052人。

リモート画像ファイルを自動スケーリング有効にしてimage-modeで開いた時にsshがつっかかる件。少し仕組みを調べてみたり。 変数 image-auto-resize-on-window-resize にリサイズ結果を反映するまでの時間を指定できるようになっていて、 これを増やせば秒単位でリサイズ表示を遅らせられるようです。でも、10秒とか遅らせてもやっぱりつっかかるようで、 どうもリサイズ動作そのものが突っかかりの契機になっていないのでは?と思ったりも。 表示できた状態で image-transform-fit-to-widthやimage-transform-fit-to-heightを実行してもうまく リサイズできる所を見ると、画像の操作以前のバッファ読み込み部分で事故が起こっているのかなぁ?🤔

2021/09/14

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

東京都コロナ感染者。新規は 1004人。

image-dired。先日の実験的な書き換えを本番向けに書き換えて、scratchバッファで実験したらうまくいったので、 .emacsに記して関数を上書きするようにしてみたのですが、何故か特定の関数だけが上手く書き換えられなかったり。 ミニバッファに出力されたエラーメッセージから察するに、process sentinelがうまく定義できていない?模様。 .emacsで記した関数をそのままscratchバッファにコピペしてC-jで定義した後実行してみると、 意図通りに再定義できてエラー無く実行できます。なんで?🤔

しかたないので lisp/image-dired.el を適当なディレクトリにコピーして書き換えた後、.emacsでは書き換えた image-dired.elをloadで直指定読み込みで対応。うーむ、イマイチ😖。 先日の「オリジナルサイズ表示(C-u RET)ができないファイルフォーマットに対応」も含めた全部入りは こちら(image-dired.el.210914a.xz)。.emacs設定は以下のような感じにしてみています。

(load "~/.emacs.d/workaround/image-dired.el")

(setq image-dired-cmd-create-thumbnail-program
      "/usr/local/bin/wrapped_convert")
(setq image-dired-cmd-create-thumbnail-options
      '("-auto-orient" "%f[0]" "-size" "%wx%h" "-resize" "%wx%h>" "-background" "white" "-gravity" "center" "-extent" "%wx%h" "-strip" "jpeg:%t"))
(setq image-dired-cmd-create-temp-image-program
      "/usr/local/bin/wrapped_convert")
(setq image-dired-cmd-create-temp-image-options
      '("-auto-orient" "%f[0]" "-size" "%wx%h" "-resize" "%wx%h>" "-strip" "jpeg:%t"))

(setq image-dired-queue-active-limit 6)

ファイルをロードするのと.emacsに直に記すのと違いがあるのだろうか?🤔 わからん。

因みに対応方法としては、process sentinelから辿った先でファイルの時刻取得を行う為のアクセスを行わないようにしてみました。 代わりにファイルの時刻は実行キューに投入する前に予め取得してキューの投入と共に覚えておいて、実行時に覚えておいた 時刻を使用する感じにしました。

以前のEmacs本体へのパッチ対応と、 リモートファイルに対応した拙作wrapped_convert_210912a.tar.xzが必要です。 並列数を設定する変数 image-dired-queue-active-limit の値を増やしても、 リモート画像ファイルのサムネイルを生成しながら、リモートのテキストファイルや画像ファイルを読み込んでもつっかかる事は無くなった予感🙂。

TGAフォーマットの表示が変だ って話から随分逸れてしまいました。 でもまだ「リモート画像ファイルを自動スケーリング有効にしてimage-modeで開いた時にsshがつっかかる件」が残っているけど😑。

2021/09/13

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

東京都コロナ感染者。新規は 611人。月曜だけど他の県も少なすぎる気が。ノイズか。

image-dired。リモートファイルのサムネイルを生成する際に、何かしらTRAMPのバッファが更新されているのですが、 どうやら 関数 file-attributes と file-attribute-modification-time を使って元ファイルの更新時刻を取得するコードがあって、 その時にリモートファイルだとTRAMPバッファが更新されるみたい。 一見、ELISPコードなので途中で割り込まれたりする事は無いんじゃないの?と思ったのですが、 よくよく辿ると process sentinel と呼ばれるプロセスの状態変化を検出するハンドラ(シグナルハンドラっぽいイメージと解釈しています) から実行される事があって、それって通常の実行ルートと衝突する事は無いのか?という疑問が湧いてきたり。

試しに 関数file-attributesを実行しないようなコードに変更してみたところ、 並列実行してもつっかからなくなりました。ふむ......🤔

2021/09/12

昼前起床

掃除したり洗濯したり。

東京都コロナ感染者。新規は 1067人。

Emacsでリモート画像ファイル表示。 そういやと思い、sshとscpを別セッションと見なせば、scpで開いた方でimage-diredしている間に sshでテキストファイル読み込みなどを行う事で、ぶつからずにイケるんじゃね?と思ったり。 wrapped_convertを「/scp:...」形式も解釈するようにして試したところ、一瞬イケるような 気がしたのですがダメな場合があり完全とはいかないようです。むぅ🤔

image-diredでリモートファイルのBPGとJXRファイルが読み込めないなぁ?というのが判明。 そういやBPGとJXRは素のconvertコマンドが標準入力を受け付けないからwrapped_convertで対応した流れが あったのをすっかり忘れてました😅。 例えば「wrapped_convert '/ssh:user@host:/pathes/file.jxr' png:-」は 「ssh user@host 'cat pathes/file.jxr' | convert jxr:- png:-」となってしまうので素のconvertコマンド的にダメです。 という訳で、再帰的に 「ssh user@host 'cat pathes/file.jxr' | wrapped_convert jxr:- png:-」となるようにする事で、 更に展開されると 「ssh user@host 'cat pathes/file.jxr' | cat > tmpfile.jxr ; convert tmpfile.jxr png:-」 となる感じに考えてみました。イケたようです🙂。という訳で放流してみます (wrapped_convert_210912a.tar.xz)。

image-diredのサムネイル選択から画像表示する場合と、image-modeで表示する場合とはそれぞれ 全く違うモードで表示されるのですが、image-modeの方は組み込みImageMagickを使うか否かや リモートファイルか否かで画像表示できるか否かを切り替えているっぽいのです。ただ、条件が複雑でよく判りません🥺

image-modeでデータを表示できる/できない条件を少し見てみたり。 すごくざっくり言うと、「ファイル名渡し」と「バッファに読み込まれたデータ渡し」の二つの方法があり、 それぞれの方法に対してデコード手段があるか無いかで決まるようです。 ファイル名渡しはローカルファイルの場合だけで、それ以外(リモートファイル、アーカイブ内ファイル、....)はデータ渡しっぽい。 デコード手段は「組み込み専用画像ライブラリ(JPEG,PNG,GIF,TIFFなど)」か「組み込みImageMagickライブラリ」か 「外部コンバーター」かの 3択で、ファイル渡しでは優先順にいずれかでデコードされ、データ渡しでは 「組み込み専用画像ライブラリ」か「組み込みImageMagickライブラリ」の2択で表示されるようです。 この為、ローカルファイルならば「外部コンバーター」で表示できていたものが、 リモートファイルだと(外部コンバーターが使えないので)表示できないという感じになるようです。 また「組み込みImageMagickライブラリ」無しでビルドした場合はデコード手段の選択肢が1つ減るという事になります。

専用画像LIB ImageMagickLIB 外部converter
ファイル名渡し 表示可 表示可 表示可
データ渡し 表示可 表示可
(ただしJXR,BPGは不可)
表示不可

「外部コンバーター」でもパイプを使ったデータ渡し(と画像タイプの指定など)を受け付けられれば 理屈の上では如何なる場合も表示可能になると思うのですが、そういう仕組みは今の所無いようです。
因みに JXRとBPGは「組み込みImageMagickライブラリ」の中でファイル渡ししか受け付けられない対応になっている為、 「ImageMagickライブラリを使ってJP2やHEICはリモートファイルでも表示できるのに 何故かJXRとBPGは表示できない」 という結果になるという訳です。

2021/09/11

AM中に起床。

東京都コロナ感染者。新規は 1273人。ちょっと減速してる?

CygwinのEmacsからリモート画像ファイルを表示する件。話が二つになってしまってて、どっちがどっちの話か こんがらがってきたので整理。


TRAMPまでかかってくると直せる気がしない🥺。Emacs-28のTRAMPでは非同期やロックに関する変更が 入っていたりするっぽいのでそれ待ちかな?

リモート接続した時にうっかり画像を表示して突っかかるのもイマイチなので、事故を回避する為の簡単な ワークアラウンドを考えてみました。

やっぱり、TRAMP接続が1つのホストに対してセッションが1つしか無いっぽいのがリモートファイルを並列で 扱う際のネックになっている予感がします。

2021/09/10

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

東京都コロナ感染者。新規は 1242人。

リモートマシンの画像ファイルの表示を行うとハング状態に陥る件。 そういやと思い、VMware上のFedoraのEmacsでどうなるかを試してみたり。 ちょっと様子は違うのですが、ssh経由で読み込み&画像表示した状態でウインドウのサイズを変えて 画像のリスケールが行われようとするとハング状態に陥るようです。 sshがハングしている感じではなくてEmacsが暴走している状態になるようなので、 ちょっと様子は違うのですがリモートの画像ファイル表示と自動リサイズとの組み合わせに何かしら問題があるという感じみたい。 (後日更新:やっぱりsshが突っかかってました。結果的にCygwinと同じ状況と思われます) CygwinのEmacsと同じく image-auto-resize を nilにすれば問題無いようです。

もう少しパターンを絞れないかと観察してみたり。


ウインドウサイズが変更されたことはフックで検出しているようなのですが、 ssh経由の場合ファイル読み込み中にぴょこぴょこミニバッファの行数が変わります。 このとき、バッファ読み込み完了していないにもかかわらず、ウインドウサイズが変更された事がトリガになって 読み込みが不完全なデータからリサイズ画像を生成しようとしているとか?🤔

2021/09/09

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

東京都コロナ感染者。新規は 1675人。行動制限緩和なんてまだ当面先の話だろという気も。

突如発覚した リモートマシンの画像ファイルの表示を行うとハング状態に陥る件。 どうやら子プロセス実行したsshが(?)突っかかっていたようです。 sshをkillするとどうにか復帰する所を見ると、パイプに関連した問題なのかも知れません。

sshのバージョンをいくつか前のに戻したり、cygwin1.dllをちょっと前(スナップショットを使っていた のでバージョンを戻すほどの大きなものではありませんが)のに戻したりしてみたのですが 変化無し。見た目の動きなどからこうなってんじゃないか?を想像してみたり。


という所を踏まえると、画像生成をする所で何か事故が起こっている?と思ったりも。 どうやって調べたもんかは判りませんが、先日の非同期プロセスの何かに似た事が 同期プロセスの場合でも起こっているのかなぁ?

image-modeの設定に image-auto-resize というのがあって、デフォルトはtでウインドウの中に画像が 収まるように自動で表示サイズが変更されます。これを nil にすると 100% 表示になるのですが、 nilにすれば少し試した範囲ではハング状態には陥らないようです。なんだろう......🤔

2021/09/08

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

東京都コロナ感染者。新規は 1834人。

image-diredでハングの件。ひとまず何故これで回避できるのか判らないけどうまくいくという方法で何度かテスト。 一度もハングする事が無かったので普段使いするのには耐えられそう。因みに、以下のような感じに。

$ diff -u src/process.c.orig src/process.c
--- src/process.c.orig  2021-03-25 23:59:35.645843500 +0900
+++ src/process.c       2021-09-08 22:40:49.753608100 +0900
@@ -7262,6 +7262,17 @@
 {
   Lisp_Object tail, proc;

+#if defined CYGWIN
+  /* This code block is a workaround for asynchronous processes hangs and Segfault in Cygwin.
+     It happened when I generated a lot of thumbnail images with image dired.
+     You can work around it by making some system calls, but I don't know why. */
+  {
+    int fd = open("/dev/null", O_APPEND);
+    if (fd != -1)
+      close(fd);
+  }
+#endif
+
   /* Find the process that signaled us, and record its status.  */

   /* The process can have been deleted by Fdelete_process, or have

えー? って思いますよね。自分もそう思います😓

ちょっと気になっている点。子プロセス終了はシグナルで通知され、通知を受けたらシグナルハンドラを実行して ELISP内のプロセス制御に関する状態の更新などを行うという仕組みになっていそうなのですが、 ハンドラの中を通過中にもう一度シグナルが送られてきたらどうなるんだ?とは思ったりも。 block_child_signal()とunblock_child_signal()といった関数があって、この二つの関数で 挟まれた部分は二重にシグナルが発生しない事を保証するという事をやっている部分もあり、 ガードが足りてる?ってのが気になってたりします。デバッガを通すと動きが変わるのでどうやって 調べたもんか?🤔

そういやTRAMPを経由してリモートマシンのディレクトリにある画像ファイルをimage-diredで見るとどうなるか?と思ったり。 少なくともconvertコマンドへの入力はパイプじゃなくてファイル名を渡しているので、 動かないだろうとは思ったものの、実際に試すとハング状態に陥ってしまいました😅。 C-gが効かないのはちょっと困ったかも。
どうやらハング状態に陥るのは別の話かも。というのはimage-diredに関係無くリモートマシンの画像ファイルを 表示しようとすると、2~3枚目を表示するとハング状態に陥ります。 そういや最近 Cygwinパッケージのsshコマンドがアップデートされていたような...? 関係あるのか判りませんけど。

2021/09/07

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

東京都コロナ感染者。新規は 1629人。

image-diredでハングの件。非同期の子プロセスの終了は シグナルを使ってハンドリングしているようです。 様子を見る為に src/process.c の中にある 関数 handle_child_signal() にデバッグプリントを仕込んでみた 所、ハング状態が再現しなくなってしまったような?🤔。 理由はともかく、もしかするとワークアラウンドの手段にはなるかも?もう少し色々試してみよう。

そういえば、縦長だったり横長だったりの画像のサムネイルを並べると、幅が揃わなくて見た目が良くない なぁ?と思い、サムネイル生成のconvertコマンドオプションを以下のようにしてみたり。

(setq image-dired-cmd-create-thumbnail-options
      '("-auto-orient" "%f[0]" "-size" "%wx%h" "-resize" "%wx%h>" "-background" "white" "-gravity" "center" "-extent" "%wx%h" "-strip" "jpeg:%t"))

-resize でサムネイルサイズに縮小した後、背景が白でサムネイルの最大サイズに縮小した画像が中心になるように 配置するという感じになるようです(参考にしたページ)。 我が家は背景色が白なので前述で問題無いのですが、余白の背景色を各自で設定したテーマ背景色に自動的に合わせられれば もっと良い感じになるかもなぁ?とは思ったりも。

2021/09/06

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

東京都コロナ感染者。新規は 968人。月曜だしな。てか全国的に下がり過ぎてないか?なんだろう?

image-diredでハングの件。ELISPの実行自体はシングルスレッドで動いているので暴走すればCPUを 使いっぱなしになったりメモリが激しくリークしたりという動きになるだろうと推測します。 今のところハング状態に陥るとプロセスCPU使用率は0になる所から鑑みますに、 プロセスの終了を監視するような場面でシステムコール的なもので問い合わせた際にあるハズのものが 無くてハング状態に陥るとかそういう感じなのかな?と想像してみました。

デバッガでブレークポイントを設定するとイマイチ再現しない感じに。むぅ🤔

2021/09/05

昼前起床。

掃除したり洗濯したり。

東京都コロナ感染者。新規は 1853人。人出が増えているというのが今後どう見えるか。

パラリンピック閉会。大きな案件が片付いたという感じでしょうか。
これまでの感じで見るとコロナ感染拡大は夏休み進行の影響が一番大きく、オリパラによる影響は (ゼロに近いくらいに)極めて小さかったのではないかと思われます。 結局オリパラは原則無観客開催だった事を鑑みると、人流が多くなっていたり県外での感染が拡大する理由を オリパラに関連付けるのはかなり無理があると考えられます。沿道観戦で密になっている話とかはありましたが、 一貫して観戦自粛は伝えられていました。結局「自分が出歩く理由として都合の良いようにオリパラを利用している」 のがインタビューで理由を答えていた人達の考え方だったように思えます。 この人達はオリパラじゃなくても 何かしら自分に都合の良いような理由を付けるだろうと考えられます。 これをもってオリパラの影響と言うのも無理しかないと考えられます。
今日見たニュース番組で最終日のマラソンを沿道観戦している理由の中に「別に犯罪ではない」というような 答えをしている人が居たのですが、直ぐ横で自粛は呼びかけているしオリンピック前からお願いされ続けているにも 関わらず、そういう答えをするというのは、わざとやっているのだろうし それこそが「自分に都合の良い解釈」 なのだと思います。

image-dired。子プロセス起動前後にsleepを入れてみたり、子プロセスで起動するスクリプト内で sleepさせてみたり、関数 run-with-idle-timer で操作負荷が低い場合に子プロセス起動されるようにしてみたりと、 色々試してみたのですがやっぱりハング状態に陥る現象が再現します。ワークアラウンド的な方法でどうにか回避できないか? と思ったのですが無理かも🥺。

2021/09/04

AM中に起床。

東京都コロナ感染者。新規は 2362人。

Emacsのimage-dired。非同期にサムネイル画像を生成するプロセスをキューで数を制限しながら 実行する仕組みってのはふんわり判ったような気も。ELISPのコードの範囲では突っかかりどころは 無いように思えるのですが、先日のように並列数を1にしてもダメな場合がある所を見ると Cygwin側で何か事故が起こっているような気がしなくもありません。 因みに、emacs-X11でもダメそうなので、ますますCygwin側で何か起こっている疑惑が増しています。

少しだけgitでimage-diredの歴史探索を行ってみたり。14年ほど前(2007年4月22日)に thumbnailsというELISPから image-diredに名前が変わって以降、今に至るようです。非同期サムネイル生成の機構が入ったのは 今から5年ほど前(2016年12月19日)で、キューで並列数を制限しながらサムネイル生成を非同期プロセス実行 する仕組みはこの時から変わっていないようです。最近大きな変更を加えたような事も無さそうなので、 どれだけの人が使っているかという話はあるものの、ある程度の実績はあるのかなぁ?とは思ったりもします。

image-dired実行時のSegfaultを調べるのにターミナルでgdbを起動してみたのですが、 いつの間にかソースコードのキーワードなどがカラーでハイライト表示されるようになってたり。ほぅ....

そういやと思い、cygwin1.dllのスナップショットを試してみたり。今日時点で最新は20210819版ですが、 入れ替えてみるもやっぱりハング状態に陥る現象は再現しました。むぅ🤔

2021/09/03

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

東京都コロナ感染者。新規は 2539人。

Emacsのimage-diredでJPEGファイルが千切れてるようだったりハング状態に陥る件。 サムネイルを非同期で生成する際にデフォルトでは並列数2で実行されているのを1にして試してみてもやっぱりダメ。 ただ、なんかデッドロックしてるんじゃないか?という漠然とした予感。 子プロセスの生成方法がイマイチよく判らない感じなので仕組みを理解しないと原因は判らないのかも。

2021/09/02

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

東京都コロナ感染者。新規は 3099人。

Emacsのimage-dired。「Premature end of JPEG file」というメッセージが出たり、ハング状態に陥るのを少し 調べてみたり。でも原因は判らず。 ハング状態に陥ったまましばらくすると 「42980475 [sig] emacs-w32 14932 get_proc_lock: Couldn't acquire sync_proc_subproc for(4,0), last 5, Win32 error 0」 といったCygwinのメッセージが出る事があるようで、原因はEmacsの方じゃない可能性があるかも。 因みにこのメッセージでWeb検索すると 過去の日記が出てくるあたり、マイナーな事象だろうと思ったりも😓。

lessコマンドの -S オプションを使うと横長のテキスト行を折り返されずに見る事ができます。 カーソルキーの左右で水平スクロールできるハズなのが何故かできなくなっているのに気づいたり。 あれぇ?いつからだ?🤔。screenコマンド上だったので、一旦デタッチしてターミナル直のコマンドラインで 試すとOKだったり。もう一度 screenをアタッチしたら横スクロールできるようになりました😅。 ターミナルが変になってたのかも知れません。それにしてもこんなピンポイントで変になるか?とは思ったりも。

2021/09/01

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

東京都コロナ感染者。新規は 3168人。隣接県も含めてまだ多いな。

Emacsのimage-dired。普段は全く使わないのですが、ふと TGAファイルの表示って大丈夫だろうか?と思って 実行してみました。結果、ものの見事に上下反転された表示になりました😓。 どうやらimage-diredは画像ファイルのデコードを全て外部コマンドに委ねているようで、 ImageMagickのconvertコマンドを使用していました。という訳でこれまでの知見を総動員して 以下のような設定を.emacsに追加してみました。

;;-----------------------------------------------------------------
;; image-dired 設定
;;-----------------------------------------------------------------
(setq image-dired-cmd-create-thumbnail-program
      "/usr/local/bin/wrapped_convert")
(setq image-dired-cmd-create-thumbnail-options
      '("-auto-orient" "%f[0]" "-size" "%wx%h" "-resize" "%wx%h>" "-strip" "jpeg:%t"))
(setq image-dired-cmd-create-temp-image-program
      "/usr/local/bin/wrapped_convert")
(setq image-dired-cmd-create-temp-image-options
      '("-auto-orient" "%f[0]" "-size" "%wx%h" "-resize" "%wx%h>" "-strip" "jpeg:%t"))

wrapped_convertを使用していますが、JPEG変換された画像データをパイプで受けている訳では無い (固定名の一時ファイルに保存されている)ようなので素のconvertでも大丈夫かも知れません。
一つハマりどころになったのが、JPEG2000ファイル(.jp2)。何故か.jp2だけスケーリングされず、 画像の左上角部分がサムネイル表示されたり、実際の表示もうまくできない感じになってました。 「"-size" "%wx%h"」のARG位置を入力ファイルの後に移動すると 大丈夫そうだったので設定にもそれを反映しています。bashコマンドラインでconvertコマンドを実行しても .jp2のスケーリングがうまくできなかった所から、ImageMagickのバグだと思われますが 深くは追及していません。それにしても、 ImageMagickの gslibリンクの問題(参考)の件といい、 CygwinのImageMagickとJPEG2000の組み合わせは鬼門です😓。

気になる点として、画像ファイル数が多いと時々「Premature end of JPEG file」という多分libjpegのメッセージが出力 される事があるようです。どのタイミングで誰(Emacsの組み込みlibjpegかconvertコマンド?)が出しているのかは 判りませんが、このメッセージが出るとEmacs自体がハング状態に陥る事があるようです。 サムネイルの生成はデフォルトでは2つのプロセスを使って非同期で行われるようですが、 その辺が関係あるのかなぁ?と漠然と思ったりもしています。
あと、サムネイル画像が特定のディレクトリ(デフォルト(?)は「~/.emacs.d/image-dired」の下) に保存されるのですが消えるタイミングは無さそうです。lisp/image-dired.elの最後の方にコメントアウト された古いファイルを消す実験コードがあるようですが、使えるものかは判りません。


TOP PREV