昔の最近の出来事(2024.02)

2024/02/29

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

そういえば、Blenderでは POV-Rayで言う所のベジェ曲面って無いなぁ？と思ったり。 NURBS曲面はありますが制御点が離れすぎてて思い通りにコントロールできない感じです。

2024/02/28

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

調べ事をして終了。

2024/02/27

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

Blenderでモデリング。微妙に操作を忘れている...😓

2024/02/26

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

Benderのモデリング動画を観ていてたまたま知った石粉粘土で等身大フィギュアを作るという動画 (「三揉みじゃ！【等身大】パワー【チェンソーマン】100均石粉粘土でフィギュア作ってみた[Life-sized]Power[Chainsaw Man]」)。すげぇって思ったのは勿論なのですが、実際の骨や筋肉に相当する部位を重ねているのが面白いと思いました。

2024/02/25

昼頃起床。寝すぎ。

洗濯したり掃除したり。

レバーレスコントローラーというものがあるのを知ったり。レバーがボタンになったコントローラーで、格闘ゲームとかで普及しているみたい。 2011年末頃から存在していたようです(参考記事)。 PCのFPSゲームをキーボードで操作するようになっている現在では「無くはない」感じかも知れませんが、2011年当時は(も)格闘ゲーム用ならばパッドじゃなくてジョイスティックという感じだったので、どちらでもないボタンは斬新に感じられたとは思います。

2024/02/24

昼過ぎ起床。寝すぎ。

perl版の wrapped_convertをちょろっとリファクタリング。ちょろっとと言いつついくつかハマりましたが😓。
perlでパイプオープンする場合、「oepn(FILE, "コマンドライン |")」みたいにファイル名の代わりに最後が"|"のコマンドライン文字列を指定しますが、コマンドライン自体はシェルに渡されて展開されます。このとき「magick convert foo.jpg -background #ffffff ...」みたいな文字列の場合、「#以降」がシェルではコメントになってしまうので「magick convert foo.jpg -background」のように #以降が無いものとして扱われます。なので「magick convert 'foo.jpg' '-background' '#ffffff' ...」のようにシングルクォートで囲む必要がありますが、書き換えの過程で壊してしまいました😓。シェルを介さずに渡せれば良いかも知れませんが、一長一短あるのでどういう事が起こるのか理解して対応するしかないのかもなぁ？とは思ったりも。

鬼滅の刃のアニメ。遊郭決戦編はエネルギーを込めすぎ(褒め)に思います。

2024/02/23

昼過ぎ起床。寝すぎ。

libjxl のv0.10.0がリリースされている模様。 Cygwinでビルドしてみたのですが、clangでスタティックリンクしないとダメなのは変わらないみたい (参考)。速度が遅いのも変わらないのですが、MinGWでパッケージインストールした cjxlコマンドだと遅くない(以前のメモ)感じだったので、何が違うのか少し調べてみたり。原因は判りませんが、cjxlの「-e effort (--effort=effort)」オプションで値を変更するとファイルサイズと引き換えに圧縮速度が劇的に上がるようです。
「time cjxl -q 90 -e ${N} pov_benchmark_orig.png pov_benchmark_e${N}_q90.jxl」のコマンドラインで Nを1～9で変えてみた実行結果とファイルのサイズは以下のような感じになりました。

JPEG XL encoder v0.10.0 b38469de [AVX2,SSE4,SSE2]

| -e N |       real |       user | file size | 備考     |
|------+------------+------------+-----------+----------|
| -e 1 |   0m1.588s |   0m2.812s |   5201104 |          |
| -e 2 |   0m1.643s |   0m2.406s |   5201104 |          |
| -e 3 |   0m1.626s |   0m2.312s |   4820782 |          |
| -e 4 |   0m1.692s |   0m2.343s |   4986191 |          |
| -e 5 |  4m18.657s |  4m21.750s |   5556764 |          |
| -e 6 |   6m9.826s |  6m42.421s |   5541065 |          |
| -e 7 |   9m1.124s |  9m13.531s |   5586797 |          |
| -e 8 | 26m49.844s |  27m3.593s |   5389633 |          |
| -e 9 | 27m12.087s | 27m35.250s |   5389785 |          |
|------+------------+------------+-----------+----------|
| jpeg |            |            |   6408555 | q 90     |
| png  |            |            |  36531643 | original |

因みにデフォルトは「-e 7」です。イマイチ -e オプションで何が最適化されるのか分かっていないのですが、拡大して観察してみると 1～4と 5～9ではエッジのボケ具合に差があるようです。見た目、実行時間、ファイルサイズから言うと 1～4と 5～9とではアルゴリズムが違うんじゃないか？と思ったりも。
MinGWのパッケージインストールした cjxlでは次のような感じでした。

JPEG XL encoder v0.9.1 0.9.1-1 [AVX2,SSE4,SSE2]

| -e N |      real |     user | file size | 備考 |
|------+-----------+----------+-----------+------|
| -e 1 |  0m1.404s | 0m0.015s |   5729961 |      |
| -e 2 |  0m1.406s | 0m0.015s |   5729952 |      |
| -e 3 |  0m1.262s | 0m0.015s |   5294418 |      |
| -e 4 |  0m1.330s | 0m0.000s |   5349121 |      |
| -e 5 |  0m4.594s | 0m0.000s |   5580067 |      |
| -e 6 |  0m7.613s | 0m0.000s |   5548807 |      |
| -e 7 | 0m15.019s | 0m0.000s |   5592374 |      |
| -e 8 | 0m52.651s | 0m0.015s |   5382412 |      |
| -e 9 | 1m11.560s | 0m0.000s |   5388246 |      |

Cygwinのcjxlとの jxlファイルサイズの違いはバージョンの違いによるものかと思われます。ただ、やっぱりMinGWの方が実行速度は速いです。タスクマネージャで見る限り、 Cygwinではシングルスレッドで動いてるような感じですが(エンコード時のメッセージでは 8 threadsとはなっていますが)、 MinGWの方はマルチスレッドで動いているように見えます。少なくともMinGWとCygwinとでは Cygwinの方が 35倍遅いケースがあるので、速くなる余地はあると考えます。

2024/02/22

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

SAI2のアップデートが来ている模様。おつかれさまです。

GIMPの開発版2.99.18がリリースされているみたい (アナウンス)。今後は3.0に向けてRC版が出る感じかな？

2024/02/21

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

先日 sshを子プロセス実行するD言語コードを書いたのですが、昨日動いていたハズなのに今日は何故か動かない。先日、パイプが突っかかっているのをcatを挟むと動くようになったりしたのですが、やっぱり何か怪しい気がします🤔
子プロセス実行するのに関数pipeProcess()を使用しているのですが、sshを子プロセス実行する場合は子プロセスのstdinは特に使用しないので何もしていませんでした。 stdinもリダイレクトした上でflush()とclose()するようにしてみたところ stdoutの方にデータが出てくるようになったり。全く納得はできてません。なんだこれ？🤔
納得はしていないものの perl版の wrapped_convertと同じ感じで MinGWビルドのEmacsからリモートマシンの画像をimage-diredできるようになってみたり。ただ、D言語版のwrapped_convertは Cygwinではコンパイルできないので、Cygwinパスとの相性がダメなのと、ImageMagickのサポート状況もMinGWとCygwinとでは違う事から、二本立てにならざるを得ません。とは言え、MinGW版の方は常用する気が無いので「.exeにすれば使えるのは分かった」ってのを以って終了です。

Web散策していて、「𠮷(U+20BB7)」という漢字があるのを知ったり。見た目からか「つちよし(土よし)」と呼ばれているようです。「吉」の異体字ではない模様。 Windows7以降はフォントにグリフとして含まれるようになってたようですが、 WindowsXPとかではわざわざ外字登録して表示させるなんて事が行なわれていたようです。現在の MS-IME(新しい方)では外字登録できなくなっているので古の技となっているように思われます。そういやTANE自身は過去においても外字を使う事は無かったのですが、ベクターフォントの使用が普通になっている現在においては、ビットマップで外字を登録して使うってのは大分無理している気がしなくもありません。

2024/02/20

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

先日のパイプ接続がうまく動かない件。動いたり動かなかったりする模様。訳が判らん。
「ssh user@host 'cat foo.jpg' | cat | convert - png:foo.png」のように間に catコマンドを挟めば失敗しなさそう。やっぱり訳が判らん。

2024/02/19

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

Emacs diredのソート。何故かlsをどこで実行しているのか判らず。あれぇ？🤔

msysのbashで「ssh user@host 'cat foo.jpg' | convert - png:foo.png」みたいに実行したのですが何故か終了せず。「ssh user@host 'cat foo.jpg' > foo.jpg」は大丈夫、「cat foo.jpg | convert - png:foo.png」も大丈夫で、直接パイプで繋ぐと何故かダメ。なにこれ？🤔

2024/02/18

AM中に起床。

Emacs上で画像表示する際に外部コマンド(ImageMagickのconvertとか)を使って機能を補助/補強している場合がありますが、ImageMagickでサポートされていない機能を埋め合わせる為に Cygwinの emacs-w32では拙作のperlスクリプト(wrapped_convert)を併せて使用しています。 MinGWではスクリプトをコマンドとして直接起動できないという事と、CygwinのImageMagickと対応状況が少し違うという事で、 D言語で同じようなものを作成してみています。この中で、convertで指定する入力ファイル指定に「filename.ext[0]」みたいな書き方ができるのをすっかり忘れていた為、外付け対応したJXRやBPGの image-diredサムネイル画像だけが元のファイルを見つけられなくて、うまく生成できない状態になりました。こちらの参考ページのように例えば「foo.pdf[0]」みたいに指定すると最初のページを画像として扱うみたいな使い方ができるようですが、Emacsの image-diredではファイルフォーマットによらず、ファイル名指定に「[0]」が付加されているので、wrapped_convertではその指定を受け入れた上で適当に解釈する必要があります。perl版は JXLを外付け対応した時にそういう事をしていたのですが、 MinGWでは JXLはconvertがネイティブ対応されているため何もしなくて良くなった代わりに、 JXRとBPGは convertが動かなくなってしまったので、対応が必要になっています。プラットフォームにより状況が異なるというのはなかなかに面倒臭いです。

image-diredでマルチバイト文字を含んだファイルのサムネイル生成に失敗するようだったり。どうやら utf-8文字をさらに sjisに変換して(つまり化けて) コマンドには伝わっているみたい。 msys2のbashコマンドラインで実行した時や eshellから実行すれば utf-8で伝わっているようなので、見かけ上 image-diredでサムネイルを生成する時だけ余計なコード変換が行なわれているように見えます。なんだこれ？🤔
調べてみたところ何が起こっているのかイマイチよく分かっていませんが、結論から言うと、以前設定した「(modify-coding-system-alist 'process "convert" 'binary)」がまずかった模様。「(modify-coding-system-alist 'process "convert" 'cp932)」にすればイケました。先日のimage-cropの方の表示化け対応もこれで大丈夫そうです。これってどこのコーディングを指定している事になるんだ？でもこれ、ファイル名に絵文字を含むとダメだよなぁ？と思い試してみるとやっぱりダメでした。因みに、Cygwinのemacs-w32では大丈夫でした。でしょうね...

随分前に、diredでソートのタイプ(名前、時間(-t)、サイズ(-S)、拡張子(-X)、バージョン(-v))を切り替える設定をWebで知り、現在もCygwinのemacs-w32では使用しているのですが、 MinGWビルドした emacsでは機能していないなぁ？と思ったり。 MinGWビルドの emacsでもファイルの一覧は lsコマンドを使用して取得してっぽいので、同じように動きそうな気がするのですが、何故ダメなのかはまだよく判らず。

2024/02/17

昼前起床。寝すぎ。

掃除したり。

D言語のstd.file.deleteme()。どうも名前を決めるだけじゃなくてファイルもオープンされる感じだったり。write()を使うとコンパイルエラーになるようだったのでなんで？と思ったのですが、何回かに分けてwrite()したい場合は append()で行なう必要があるもよう。

MinGWの ImageMagickで displayコマンドもあるようなので使えるのかと思ったら、サポートされてはいないようだったり。そういうものなのか？🤔

JPEG-XL(jxl)、JPEG-XR(jxr)、BPG画像フォーマットのMinGW ImageMagickの対応。 JPEG-XRとBPGは convertコマンドでは delegateという仕組みでエンコーダ/デコーダを外部コマンド実行して convertコマンドが知っている画像フォーマットを経由してから読み込むような仕組みなのですが、 MinGWの convertではエラーで動かないようだったり。なんだこれ？🤔 因みに、jxlはネイティブ対応されているようです。

jxlとjxrのエンコーダ/デコーダツールやライブラリは MinGWではpacmanでパッケージインストールできるようになってました。 BPGはビルドしても良いと思いますが、実行バイナリをインストールする方法で対応してみました。ところでJPEG-XRのライブラリ(jxrlib)のリファレンスコードを置いてあったサイトが無くなっている模様。 GitHubにはいくつかforkしたものがあるようです。 jpeg.orgの方にも JPEG-XRのリファレンス実装があるようですが、デコードしかできないみたい。

MinGWの JPEG-XLのエンコーダ(cjxlコマンド)。MinGWのはv0.9.1のようですが、 Cygwinでビルドした時のように100倍遅くなっている(参考) という事は無さそうです。Cygwinでのビルドの仕方の問題なのか？と思ったりも。

2024/02/16

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

コーディング。そういやD言語で tempfileを作った事無いな？と思い作り方を調べてみると、 std.stdioに tmpfile()っていう C言語のtmpfile()と同じ感じのがあるらしいので使ってみたのですが、File() とちょっと違うようで扱い方がよく判らなかったり。別の方法として、std.file.deleteme() ってので tmpファイルのベース名を生成できるようだったので、これを使う感じに考えてみる事にしたのですが、この関数は何度呼んでも同じ文字列が返ってくるので、複数のtmpファイルを同時に扱おうと思うと、ぶつからない文字列を適当に追加する必要があるようです。関数を呼ぶ度に絶対にぶつかっていない名前を生成してくれれば良いのになぁ？と思わなくも無かったり。

2024/02/15

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

MinGWビルドのEmacs。リモートのLinuxマシンのファイルにアクセスするのに、MinGWのEmacsでは plinkを使用して「/plink:...」みたいな感じでファイルを開きます。試してみたところ当然アクセスできるのですが、Cygwinのemacs-w32で「/ssh:...」でアクセスするのに比べるとかなり高速にファイルの書き込みができるなぁ？と思ったり。以前、Cygwinのemacs-w32が遅いのは ptyの書き込みが遅いからと結論付けたのですが、plinkをCygwinでも使えば同じくらいの速度が出るんじゃね？と思いました。単純にWindowsバイナリを使うとファイルのパスの扱いが違うなどの理由で上手く動かない事が予想できたので、 plinkをCygwinでビルドできれば良いのでは？と思い調べていました。現在、plinkのGitHubサイトを見た感じ、 1.9と2.0ってのがあるようで、2.0の方はWindows以外のプラットフォームでのビルドに対応していそうだったので、Cygwinでのビルドを試してみました。結果はビルドできず🥺。色々突っかかりどころがあって挫けました。でも、MinGWビルドのEmacsと同じような事をすれば CygwinビルドのEmacsでも同じ結果が得られるんじゃなかろうか？と考えます。

全く説明を読んでいなかったのですが、 plinkのGitHubサイトは PLINKって名前の全然関係無いソフトでした😅。節穴が過ぎると自分で愕然とします🥺。

PuTTYの公式から今日時点で最新の0.80の Unix source archiveってのをダウンロードしてビルドしてみたり。ビルドできたのでCygwinの emacs-w32から「/plink:...」で使ってみたのですが、「/ssh:...」と様子が変わらず。ファイルの書き込みは猛烈に遅く、大きなファイルは途中で転送に失敗します。むぅ。
もう少し調べてみたら、tramp-process-connection-typeを nilにする必要がある模様。以前調べた通り、デフォルトでは tになっているのですが、 MinGWビルドのEmacsではptyが使えないので nil相当で動いているという事みたい。 Cygwinでは明示的に nilにした上で「/plink:...」(/plinkx:...ではない)を使えば良いみたいです。 tramp-process-connection-typeを nilにすると scpは使えないので、 plinkと一緒にビルドできた pscpを使う必要があるようです。
結局のところ、「ptyを使っているから遅い。だからpipeを使えば良い」に対して plinkや pscpを介する事でpipeを使って高速化しているというように解釈できなくもありません。ともあれ、選択肢があるのは良い事だ....という事にしよう🙂。

2024/02/14

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

調べ事をして終了。

2024/02/13

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

調べ事をして終了。

2024/02/12

AM中に起床。

掃除したり。

先日から立ち上げっぱなしのEmacsで改行化けの再現コードを試したら何故か再現しなくなっていたり。整理すると、上手く動く設定方法があったり、罠にハマってたりしていた模様。

「(modify-coding-system-alist 'process "convert" 'binary)」を .emacsに追加して convertコマンド実行時は入出力ともbinaryになるようにしておく。 MinGWビルドでは default-process-coding-system が「(undecided-dos . undecided-unix)」になっているようです。「(setq default-process-coding-system '(binary . binary))」でも convertで標準出力を使うケースはイケるようになるのですが、「shell-command-on-region(M-|)」とかで他のコマンドを実行した時にマルチバイト文字表示が化けるようになるようです。
「(write-file "foo" nil)」では改行コードCRLFとLFが混在していると、ファイルに書き込む時にどちらか一方に揃える変換が行なわれる。ファイルに書き込むとバッファの内容が変換されてしまうので、その後に「(buffer-string)」しても化けてしまいます。これはデバッグ用に調べているつもりが、やり方がマズくて原因を見間違えてしまう要因になっていました😓

modify-coding-system-alistの対応でimage-cropの表示も化けなくなりました。ひとまず設定で回避できるのは判りましたが面倒臭いのは変わらず。

2024/02/11

AM中に起床。

D言語で「magick convert」コマンドをラップしてEmacsの外部コマンド実行で使用してみたのですが、「magick convert -resize 600x - png:-」のような標準入力から読み込んで標準出力に書き込まれるようなのがうまく動かなかったり。「magick convert -resize 600x - png:abc.png」のように実行すると abc.pngというファイルも中身も入っている事から、見かけ上、標準出力が空中散布されているように見えます。

次のようなコードでデータ化けを再現させてみました。

(insert-image
 (create-image
  (with-temp-buffer
    (set-buffer-multibyte nil)
    (set-buffer-file-coding-system 'binary)
    (apply #'call-process "convert" nil (list t nil) nil
           '("-resize" "600x" "foo.jpg" "ppm:-"))
    (write-file "abcdefg.ppm" nil)
    (buffer-string))
 'pbm :data)) ;; and press C-j

このとき、リサイズのサイズ指定(この例では600x)が小さければ画像が挿入されますが、大きくしていくと豆腐になりました。同時に「abcdefg.ppm」というファイルにセーブもしているので、コマンドラインで生成したファイルと比べてみたところ、どうやらCRLF改行コードに相当するバイナリデータがLF改行コード相当に変換されてしまっているのが表示されない場合がある原因のようです。
先日、image-cropがなんとなく動くようになった時、回転させると表示が化けると記しました。image-cropではSVGで画像を表示する為に元画像を回転やリサイズしてSVG表示しています。このとき、jpegに変換すると多少壊れていても色化けしながら表示される場合があって、それが結果として表示が化けるように見えたという事みたい。我が家では入力画像フォーマットによらず PNGに変換するように image-crop-resize-command や image-crop-crop-command などをカスタマイズしているのですが (以前のメモ)、PNGの場合はファイル先頭の「PNGファイルシグネチャ」に「0x0d 0x0a」が含まれています。これが必ず「0x0a」に化けるため、絶対に表示できないという罠にハマるというのもあります🥺。ただ、サブプロセスのSTDOUT から Emacsバッファ間のどこで化けているのかがまだ判りません🤔

前述の再現コードで「(set-buffer-file-coding-system 'binary)」を入れているのですが、これの有無で変換結果が変わる模様。

| set-buffer-file-coding-system | 0x0d 0x0a |   0x0a    |
|-------------------------------+-----------+-----------|
| binary                        |   0x0a    |   0x0a    |
| 設定無し                      | 0x0d 0x0a | 0x0d 0x0a |

binaryだと LF(0x0a)に変換されるようですが、指定無しだとCRLF(0x0d 0x0a)に変換されてしまうようです。改行コードが混在していたらどちらかに揃えるという動きにも見えますが、それをやられるとバイナリデータは壊れます。

もっと単純に以下のような再現コードで十分なようです。

  (with-temp-buffer
    (set-buffer-multibyte nil)
    (set-buffer-file-coding-system 'binary)
    (apply #'call-process "cat" nil (list t nil) nil
           '("src.png"))
    (write-file "dst.png" nil)
    )  ;; and press C-j

これで set-buffer-file-coding-systemの行の有無によらず正常なsrc.pngから dst.png は壊れたPNGファイルになるみたい。どうしたもんか？🤔

2024/02/10

昼前起床。寝すぎ。

Emacsのimage-cropについて調べていたら、たまたま sとか mといったキーバインドがあるのを知ったり。 crop領域の選択後に、sを押すと正方形領域に変形された上にマウスドラッグで原点位置を変えられるというもので、mを押すと選択領域をマウスドラッグで原点位置を変えられるというものみたい。でも、sやmを押すと元の選択領域編集に戻る方法が無くて、一旦 cropモードを抜ける必要があるようです。また、いきなり sや mでモードを切り替えると領域無選択のまま選択領域移動モードになってしまう為、ハマる感じになってしまいます。そこで、aで選択領域の頂点編集モードに戻ったり、bで最初から選択するモードに戻るバインドを追加してみたり。現在の状態が分かりやすいかと言われるとイマイチかも知れませんが。

MinGW64とMSYS2との違い。D言語を使って子プロセス実行の実験。「ls -l」は出力が得られるのに、なぜか「convert -help」は出力が得られず。どうやら、bashコマンドライン上では /mingw64/bin/convert の方にパスが通っているようですが、プログラムからは「C:\Windows\System32\convert.exe」の方が実行されている事が判明。パスが引き継がれる訳ではないのか？とも思ったのですが、もしかしてbashは「/mingw64/bin/」を解釈できるけど、Windowsアプリは「/mingw64/bin/」が解釈できず、解釈可能なパス上だと「C:\Windows\System32\convert.exe」が該当するという事か？と思ったりも。でも、「magic convert -help」はイケるので、パスが解釈できないとか通っていないとかではないような。パスの順序が問題なのか？と思い調べてみるも、magick.exeも convert.exeもパス「D:\msys64\mingw64\bin(==/mingw64/bin/)」の方に置かれていて、パス「C:\Windows\System32」よりも先に書かれていますが、convertコマンドは何故か後に書かれたパス「C:\Windows\System32」の方を実行していて、パスの解釈順番がよく判らない感じになっているように見えます。なんだこれ？🤔

2024/02/09

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

MinGWビルドのEmacs。 ImageMagickのconvertコマンドを拡張する wrapped_convertという拙作のperlスクリプトを実行しているつもりなのですが、上手く動いていない感じだったのを調べてみたり。「shell-command-on-region(M-|)」で実行すれば一応動くので、実行の仕方を調べてみたところ、以下のようにcall-processを使うような実行方法だと実行できないみたい。

スクラッチバッファで以下を実行。
(apply #'call-process "wrapped_convert" nil '(t nil) nil '("-list" "format")) ;; and press C-j

以下バックトレース。
Debugger entered--Lisp error: (permission-denied "Searching for program" "Permission denied" "wrapped_convert")
  call-process("wrapped_convert" nil (t nil) nil "-list" "format")
  apply(call-process "wrapped_convert" nil (t nil) nil ("-list" "format"))
  (progn (apply #'call-process "wrapped_convert" nil '(t nil) nil '("-list" "format")))
  eval((progn (apply #'call-process "wrapped_convert" nil '(t nil) nil '("-list" "format"))) t)
  elisp--eval-last-sexp(t)
  eval-last-sexp(t)
  eval-print-last-sexp(nil)
  funcall-interactively(eval-print-last-sexp nil)
  call-interactively(eval-print-last-sexp nil nil)
  command-execute(eval-print-last-sexp)

wrapped_convertを convertにすれば動くので、スクリプトの場合は何かしらの理由で Permission deniedらしい。そういうものなのか？🤔
よく考えてみたら、いわゆる「#!」(シェバン)が書かれたスクリプトを実行できるんだっけ？と思ったりも。.exeじゃないとダメなんじゃないかという疑惑。だとすれば、単純に面倒臭い...🥺

2024/02/08

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

MinGWビルドのEmacs。shell-command-on-region(M-|)で lsなどのコマンドが使えます。それらのコマンドは /usr/bin にあるっぽいのですが、C-x C-f では見えないディレクトリになっていて、何がどうなっているのかよく判らず。拙作 sysmonでは「/proc/stat」というファイルを参照してCPU使用率を取得しているのですが、 Emacsからは直接参照できないため動きません。「cat /proc/stat」ならば中身を表示できるようなので、書き換えたら動くようにはなりました。なんだか微妙に面倒臭い.....

sysmonで文字表示するのに、「terminal」というfont-familyを指定しているのですが、 MinGWビルドのEmacsではフォントが見つからないというPango-WARNINGメッセージが表示されます。Cygwinでは問題無いのですが、そもそもどこにあるフォントを読み込んでいるんだ？というのが判らなかったり。

2024/02/07

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

随分前にカラー絵文字対応のパッチをMinGWでビルドできるか試してそれっきりだったのですが、Emacs-29.2向けのパッチを適用してそのままMinGWビルドできるか試してみてました。前はカラー絵文字表示だけを確認したかったので画像ライブラリなどはほぼリンクせず harfbuzzだけ有効な感じでビルドしていたのですが、今回は色々もりもりでビルドしてみました。結果から言うとIMEパッチやカラー絵文字の部分は特に問題無さげ。いくつか直しどころはある感じですがまぁ問題無いだろうと思います。以下覚書。

フォントフォールバックに時間がかかる原因を調べる為の仕組みの中で clock()というCライブラリの標準関数を使用しているのですが、nt/inc/ms-w32.hというMinGWビルド時に使用されるヘッダファイルの中に「#define clock sys_clock」というdefineがあって、コンパイルで警告が出てしまう。多分置き換えられるとダメなので clock()を使用している部分で MinGWの時だけ「#undef clock」するという謎の対応を入れる必要がありそうです。
lisp/org/ob-plantuml.elでCygwinの場合はWindowsパスになるようにファイルの文字列変換を行なうパッチを加えているのですが、Windowsパスに変換する関数cygwin-convert-file-name-to-windows がCygwinだけの関数の為、バイトコンパイル時にワーニングメッセージが出る。 system-typeをチェックしてから実行しているので動きに問題は無いのですが、今のところ致し方なしか。

あと、image-cropを試してみたのですが、何やらバグってて動かず。 convertコマンドのチェックの仕方の問題のようだったので、雑に以下のようにしてみました。

$ diff -u lisp/image/image-crop.el.orig  lisp/image/image-crop.el
--- lisp/image/image-crop.el.orig       2024-02-06 22:35:46.742739900 +0900
+++ lisp/image/image-crop.el    2024-02-07 23:16:49.174862000 +0900
@@ -182,9 +182,9 @@
              ;; MS-Windows has an incompatible convert.exe, used to
              ;; convert filesystems...
              (string-equal crop-cmd "convert")
-             (= 0 (string-search "Invalid drive specification."
-                                 (shell-command-to-string
-                                  (format "%s %s" crop-cmd null-device)))))
+             (string-search "Invalid drive specification."
+                            (shell-command-to-string
+                             (format "%s %s" crop-cmd null-device))))
         (error "The program `%s' is not an image conversion program"
                found)))
   (let ((image (image--get-image)))

コマンドを実行してその結果文字列の中に「Invalid drive specification.」が最初に見つかった場合はエラー条件の一つが成立するという論理のようですが、文字列がマッチしなかった場合に関数string-searchは nilを返すため、「(= 0 nil)」がELISPエラーになってしまうというバグのようです。「Invalid drive specification.」が見つかればダメなんでしょ？だったらそれだけでいいじゃんというパッチです。パッチの良し悪しはともかく、30系のブランチでも直っていないので Windowsバイナリでは誰もimage-cropを使っていないのか？と思わなくもありません🤔

image-cropがなんとなく動いてっぽいのですが、画像を回転させたりすると表示が化けているような。 convertがちゃんと動いていないのだろうか？

2024/02/06

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

調べ事。

2024/02/05

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

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

2024/02/04

AM中に起床。

掃除したり洗濯したり。

Web散策していて、こちらの動画を知ったり。 GeForce 256 ～ RTX 3090 Ti までの変遷をまとめた動画ですが、最後に出てくる GeForce 256 と RTX 3090 Ti のスペック比較を見て、約22年で色々な比率が数百倍から千倍とかになっていて驚きます。 CPUもそうですが半導体はそろそろ物理的な微細化限界に達しつつあるので、次の20年はどうなるのかなぁ？と思う所です。

2024/02/03

昼前起床。

ノートPCのCygwinも Emacs-29.2にアップデート。そういえば Windows11に Unicode 15.1の絵文字はいつ入るのだろうか？と思ったりも。Unicode 15.0の絵文字がしれっと 2023年10月のアップデートで入っていた (以前のメモ)のを鑑みると、 15.0の絵文字は仕様が確定したのが2022年9月13日で、約1年後にWindows11で使えるようになった感じなので、 15.1の絵文字の仕様が確定したのは2023年9月12日だったところから、やっぱり1年はかかるのだろうか？🤔

そういや Emacs-30系のブランチはまだ無いのですが、30系ブランチが作られるのはいつ頃になるのかなぁ？と思ったりも。とは言え、29.2がリリースされた後も 29系は修正変更がそこそこ加えられているようなので、今年は 29.3でもう一回刻むのかなぁ？判りませんが。ところで masterブランチの etc/NEWSには現時点で 30.1に入る予定の機能や変更が記されています。その中に「Native compilation is now enabled by default.」てのがあり、30.1ではネイティブコンパイルがデフォルト有効となるようにconfigureオプションが変更されるようです。現状、Cygwinではネイティブコンパイル有効でビルドはできますが(色々ハマりどころがあるためか)、パッケージ版はデフォルト無効で配布されています。今後どうなるかは状況によるかも知れません。

と書いた後にネイティブコンパイルを有効にしたテストパッケージのアナウンス(emacs 29.2-2 (TEST)) をよく読んでみると、「.elnはASLRを有効にしてビルドされていて、以前はforkでずっこけたりしてたけど解消が期待される」という感じの事が書かれていました。そうなのか？と思って --with-native-compilation を試してみたのですが、初回起動のelnコンパイルでやっぱりズッコケる場合がある模様。一旦emacsを終了して再度立ち上げるとダメそうな .elnファイルが表示されて再度起動も失敗するので、対象となる.elnファイルを消しては再起動、またズッコケたら終了→.elnを特定して消す→再起動→....を繰り返して、elnコンパイルが行なわれなくなったらひとまず完了...って感じに対応するのは変わっていないように思えます。

Cygwin 3.5.0になったのですが、libjxlの cjxlが起動できない件 (以前のメモ)に何か変化があるだろうか？と思いビルドを試してみたり。因みにソースコード自体はアップデートしていません。一応ダイナミックリンクでビルドしても大丈夫になった模様。原因が分かって対処した結果ではないので、何かの拍子でまたダメになったりする可能性はありますが。ただ、100倍遅くなっているのはのは変わらず(以前のメモ)。スタティックリンクに起因して遅くなった訳では無かったようです。
cjxlがOKになったかと思ったら、djxlの方がSegfaultでずっこけるようになったり。よくよく確認してみたら、clangじゃなくてgccでビルドしていました。という訳でclangでビルドし直し。やっぱりダイナミックリンクでのビルドは前と同じく「Invalid relocation. 」でダメでした。結局以下のような感じかと。

| コンパイラ | ビルド  | cjxl                   | djxl                           |
|------------+---------+------------------------+--------------------------------|
| clang      | Dynamic | NG(Invalid relocation) | OK                             |
| clang      | Static  | OK                     | OK                             |
| gcc        | Dynamic | OK                     | NG(Segfault)                   |
| gcc        | Static  | OK                     | NG(出力ファイルが生成されず？) |

いずれにしてもなんかダメな状況である事には変わりなし。

そういえば、grep 3.8で egrepや fgrepを使用した時に警告メッセージが出るようになっていました (以前のメモ)。その後「grep -E」を使うようにしてたのですが、何気に egrepを使ったところいつの間にかメッセージが出なくなってるなぁ？と思ったり。以下のようにメッセージ出力がコメントアウトされてました。

$ cat /usr/bin/egrep
#!/bin/sh
#cmd=${0##*/}
#echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2
exec grep -E "$@"

$ grep --version
grep (GNU grep) 3.11
パッケージ作成者: Cygwin (3.11-1)
Copyright (C) 2023 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 Mike Haertel and others; see
<https://git.savannah.gnu.org/cgit/grep.git/tree/AUTHORS>.

grep -P uses PCRE2 10.42 2022-12-11

grep本家のgitリポジトリを見る限り、コメントアウトされた形跡や廃止予定の撤回は見られないので、Cygwinパッケージだけの対応なのかも？もう少し調べてみたところ、Cygwinの grep-srcパッケージのファイル一覧に「grep-3.11-1.src/grep-3.8-egrep.sh-no-warning.patch」というのがあるようで何かしらパッチが当たっている模様。

2024/02/02

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

Cygwinの Emacs-29.2パッケージがリリースされた模様。という訳で明日付けになっていますが「Emacsの雑記」を 29.2対応に更新してみました。御参考まで。

2024/02/01

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

Cygwin 3.5.0-1が出てるっぽい。Windows7と8のサポートが終了した模様。Windows8.1はまだ継続みたい。

Blendero弄り。カメラに写っている面だけを張りなおしてレンダリングしてみたり。

blender面張りテスト_240201a

先日のモデルを元に面張りし直したわけですが、サブディビジョンサーフェスモディファイヤーを使ってみたりしているのもあってか微妙な違いは出る感じです。若干目が大きくなっていますが、これもサブディビジョンの影響でモデルが若干痩せる(==目や口の穴は広がって若干大きくなる)ことによるものです。眼球や髪の毛の位置や大きさは全く同じなので、顔モデルの差だけが違いとして見える感じです。とは言え、微調整はやはりポリゴン数が少ない方がやりやすいです。当たり前かも知れませんが😅

TOP PREV