最近の出来事

2024/03/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パッケージが出るまでの間にテストしてみようと思います。

2024/03/23

昼前起床。寝すぎ。

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言語に由来しているらしくて (参考) やっぱり ややこしいとは思ったりも😓

2024/03/22

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

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


を、Cygwinネイティブなコンパイラ(例えば gccや Cygwinでビルドしたクロスコンパイラ)を 使うような場合にも壊れないように対応する必要がありそうです。

2024/03/21

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

調べ事をして終了。

2024/03/20

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

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

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


現状の使い方では serve-dを自ホストで動かしている為、普通に flymakeを使うのと 変わりません。むしろチェック出来ないエラーがある以上は 使い物にならないと考えます。

flymakeで良いんじゃないの?とも思ったのですが、 DMDやldc2のエラーメッセージに対応していないのと、Cygwinではファイルパスの違いがある都合から CygwinでflymakeをD言語対応で使うには MinGWクロスビルドしたgdcを使用しています。 しかし、gcc-12の gdcからは Cygwinでブートストラップできる目途が今のところ無いので (過去の日記)、いずれ最新の文法に追従できなくなる という状況にあります。それもあって LSPを移行先にと思った訳ですが...。 何か良い手は無いものかと思ったり🤔

2024/03/19

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

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ってバージョンでした。 で、ビルドした新しいバージョンでもエラーチェックできないパターンは変わらず。 ブランチの最新で直っているという事は無さげ。

2024/03/18

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

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

2024/03/17

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  }

上のようなのがエラーになりません。辛い🥺。

D言語の LSPサーバ(serve-d)との間で 何をやってるのか調べる所から。Cygwin Emacsでは serve-dが Segfaultして落ちているようだったのですが、 MinGW Emacsでは動いているので イベントログを見てみたところ、ファイルのパス指定が Cygwin Emacs では「file:///cygdrive/d/.....」となっているのが MinGW Emacsでは 「file:///d%3A/.....」となっていました。serve-d自体は Windows用のバイナリを使用しているので、 Cygwinのファイルパスはまず食えないだろうという事で、lisp/progmodes/eglot.el 内にある 関数eglot--path-to-uriを仮改造して CygwinファイルパスをMinGWっぽいファイルパスに文字列 変換するようにしてみたところ、 Cygwin Emacsでも serve-dが落ちなくなりました。 でも、文法的にエラーがある場合でもエラーが表示されず。ただ、例えば「writefln」のように 関数名を書いてその上にカーソルを置くとミニバッファに関数のドキュメントが表示されたので、 何かしらserve-dと通信をしているっぽい予感がしたりも。
Cygwin Emacsで EGLOTのイベントログを見たところ 「(:diagnostics ...」という文字列を 受けていて、ここにエラーがある箇所の情報が含まれているっぽい。ここまで情報を受けているなら 表示自体は可能なハズ。 もしかして、ファイルのURIを MinGWっぽいパスに変えたのに対応するように、エラー情報に含まれる URIを Cygwinパスに戻してやらなくてはダメかも?と思い調べてみたら、 仮改造した 関数eglot--path-to-uri のすぐ下に 関数eglot--uri-to-path という逆の変換を行なう 関数があったので、この中でMinGWパスからCygwinパスに逆変換してみるようにしたところ、 うまくエラー箇所がハイライトされるようになりました。まぁそういう事かという顛末😓。
さておき、本来どこで対応するものなんだ?と思ったのですが、 今回仮改造した 関数eglot--path-to-uri や 関数eglot--uri-to-path の中では 「(eq system-type 'windows-nt)」という条件で、Windowsの時はパス文字列を加工するような 特殊コードが入っています。結局 Cygwinもその仲間という考え方もできそうなのですが、 そうなんだっけ?とは思ったりも。他の言語のLSPサーバも同じ対応で良いのならばそうかも知れませんが、 もしCygwinネイティブで動くLSPサーバだとそうはならないのでは?とは思ったりも。
それよりも、明らかにコンパイルエラーになる文法エラーが検出されないのをどうにかしないと 用事にならないと思うのですが、どうしたもんか....🤔

模様替えごっこ。角を使うのをやめて長机にしてみました。

blender仮想デスク_240317a

奥行70cm/幅200cmにしたので、机としては大分大きなサイズだとは思いますが、 ディスプレイサイズが43インチ相当だとやっぱり近すぎるので30インチ相当にしてみました。 結局 画面が視野にどれだけ入るかを踏まえた上で、視点からディスプレイまでの距離が机の奥行やレイアウトで 決まっているのであれば、適切なディスプレイサイズは自動的に決まるという事かも知れません。 あと、PC本体を机の上に置くのはやっぱり邪魔な感じだったので机の下に置く感じに。 なんかやっぱりデスクトップPCがあればノートPCを併用する事は無いな....

2024/03/16

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*);

毎度の事ですが、ダメなのは分かったけどどう直ば良いのかはメッセージだけでは分かりません。 Change Log:2.104.0 によれば inを constに書き換えれば良いっぽい。全部で2箇所だけだったのでまぁいいか。

Dコンパイラのアップデート確認をしていて、ふと、これってどうなるの?と思って確認して みたところ、そうなんだ と思ったので覚書。
以下のようなコードをコンパイル&実行した結果。

$ 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

ソースコードの6行目と7行目でそれぞれ「TestString」という文字列を直に記していますが、 実行した結果のポインタ値はどちらも同じになっています。 即ち、文字列的に同じ内容だったら一つにまとめているという事かと。 8行目は6,7行目とは違う文字列なのでポインタ値は違っています。 言語仕様的に 文字列リテラルはimmutableなので書き換え不能だから こういう最適化が可能なのかと思ったりも。

因みに、

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

みたいな書き方でコンパイルエラーにはなりませんが、最適化無しだと (多分「str[0] = 't';」辺りで) Segfaultします。 -Oだと動いてしまうようですが、

4: 7FF6EC16B5F6
T
5: 7FF6EC16B5F6

みたいな結果になっていて、「str[0] = 't';」が動いていない感じに見えます。 いずれにしても、文字列の書き換えを行ないたければ、変な事は考えずに文字列操作で 行なえば問題にはならないかと思います。

2024/03/15

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

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

2024/03/14

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

調べ事をして終了。

2024/03/13

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

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

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

2024/03/12

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

ちょろりモデリング。

2024/03/11

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

ちょろりモデリング。

2024/03/10

AM中に起床。

掃除したり洗濯したり。

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

blender仮想デスク_240310a

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

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

2024/03/09

AM中に起床。

TARAKO氏死去。

もそもそとモデリング。

2024/03/08

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

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

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

2024/03/07

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

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

2024/03/06

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

調べ事をして終了。

2024/03/05

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

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

2024/03/04

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

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

2024/03/03

AM中に起床。

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

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

blender仮想デスク_240303a

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

2024/03/02

昼過ぎ起床。寝すぎ。

掃除したり。

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

2024/03/01

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

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

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の対応で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パッチやカラー絵文字の部分は特に問題無さげ。いくつか直しどころはある感じですが まぁ問題無いだろうと思います。以下覚書。


あと、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

古いの
2024.01
2023.12 2023.11 2023.10 2023.09 2023.08 2023.07 2023.06 2023.05 2023.04 2023.03 2023.02 2023.01
2022.12 2022.11 2022.10 2022.09 2022.08 2022.07 2022.06 2022.05 2022.04 2022.03 2022.02 2022.01
2021.12 2021.11 2021.10 2021.09 2021.08 2021.07 2021.06 2021.05 2021.04 2021.03 2021.02 2021.01
2020.12 2020.11 2020.10 2020.09 2020.08 2020.07 2020.06 2020.05 2020.04 2020.03 2020.02 2020.01
2019.12 2019.11 2019.10 2019.09 2019.08 2019.07 2019.06 2019.05 2019.04 2019.03 2019.02 2019.01
2018.12 2018.11 2018.10 2018.09 2018.08 2018.07 2018.06 2018.05 2018.04 2018.03 2018.02 2018.01
2017.12 2017.11 2017.10 2017.09 2017.08 2017.07 2017.06 2017.05 2017.04 2017.03 2017.02 2017.01
2016.12 2016.11 2016.10 2016.09 2016.08 2016.07 2016.06 2016.05 2016.04 2016.03 2016.02 2016.01
2015.12 2015.11 2015.10 2015.09 2015.08 2015.07 2015.06 2015.05 2015.04 2015.03 2015.02 2015.01
2014.12 2014.11 2014.10 2014.09 2014.08 2014.07 2014.06 2014.05 2014.04 2014.03 2014.02 2014.01
2013.12 2013.11 2013.10 2013.09 2013.08 2013.07 2013.06 2013.05 2013.04 2013.03 2013.02 2013.01
2012.12 2012.11 2012.10 2012.09 2012.08 2012.07 2012.06 2012.05 2012.04 2012.03 2012.02 2012.01
2011.12 2011.11 2011.10 2011.09 2011.08 2011.07 2011.06 2011.05 2011.04 2011.03 2011.02 2011.01
2010.12 2010.11 2010.10 2010.09 2010.08 2010.07 2010.06 2010.05 2010.04 2010.03 2010.02 2010.01
2009.12 2009.11 2009.10 2009.09 2009.08 2009.07 2009.06 2009.05 2009.04 2009.03 2009.02 2009.01
2008.12 2008.11 2008.10 2008.09 2008.08 2008.07 2008.06 2008.05 2008.04 2008.03 2008.02 2008.01
2007.12 2007.11 2007.10 2007.09 2007.08 2007.07 2007.06 2007.05 2007.04 2007.03 2007.02 2007.01
2006.12 2006.11 2006.10 2006.09 2006.08 2006.07 2006.06 2006.05 2006.04 2006.03 2006.02 2006.01
2005.12 2005.11 2005.10 2005.09 2005.08 2005.07 2005.06 2005.05 2005.04 2005.03 2005.02 2005.01
2004.12 2004.11 2004.10 2004.09 2004.08 2004.07 2004.06 2004.05 2004.04 2004.03 2004.02 2004.01
2003.12 2003.11 2003.10 2003.09 2003.08 2003.07 2003.06 2003.05 2003.04 2003.03 2003.02 2003.01
2002.12 2002.11 2002.10 2002.09 2002.08 2002.07 2002.06 2002.05 2002.04 2002.03 2002.02 2002.01
2001.12 2001.11 2001.10 2001.09 2001.08 2001.07 2001.06 2001.05 2001.04 2001.03 2001.02 2001.01
2000.12 2000.11 2000.10 2000.09 2000.08 2000.07 2000.06 2000.05 2000.04 2000.03