昔の最近の出来事(2023.12)

2023/12/31

AM中に起床。

Blenderを もそもそ弄っていたら時間が溶ける😓。

そんな訳で今年を振り返り。


他、SAI2は今年も定期アッップデートが行われています。新しいPCとタブレットを買ったので もっと使えれば良いのですが全然使えていません😓。

コロナはまだ微妙ですが静まってくれてれば まぁいいかという気もします。 そんな感じで今年の更新はここまで。それではみなさん良いお年を。

2023/12/30

AM中に起床。

掃除したり。普段行き届いていない所をちょっとだけ綺麗にした気も。

Blender。ちょこちょこ弄ったり。メニューや操作の体系が少し分かってきた気がするような そうでもないような。

2023/12/29

AM中に起床。

何気にBlenderフォーマットのフリーの3Dモデルを開こうとしたら Blender2.8では開かなかったので、 最新の4.0.2を入れてみて開いたのですが、Blender本体も色々できる事が増えてそうなのでちょっと 弄ってみる事にしてみたり。巨大ポリゴン数モデルを開けるかどうかを確認するのにインストールしてあったのですが、 ほぼ使い方は知りません😅。 因みに、23年程前にBlenderをインストール した時に起動できなかった為、以降使ってみようと思う事が無かったというのもあります。

どうやらView操作のバインドを変更できるようで、Wings3Dの 2ボタンマウスのBlender互換と 同じ感じに ALTキーとの組み合わせる操作にしてみたところ、良い感じにWings3Dと似た感じになったので これで少し弄ってみたり。ちょこっとモデリングを試してみたのですが、変形については手順が ややこしい感じだったので一旦保留。Wings3Dの方でモデリングしてWavefrontOBJ形式でインポート したもので レンダリングを試してみました。

レンダリングエンジンは標準でEEVEE(中間くらいの品質)、Workbench(影無しだけど高速)、 Cycles(高品質)を選べるようで、特にCyclesではGPUを使ってレンダリングできるようです。

blenderテスト_231229b

参考Webページはたくさんあるようですが、古いバージョンと4.0ではGUIの見た目が変わっている場合があるようで、 同じボタンがどれだかすぐに判らない場合がありました、もう少し色々操作を試してみる必要が あるかも知れません。

Blender内での変形の仕方が判ったのでモデリングし直してみたり。

blenderテスト_231229c

プロポーショナル編集なるもので変形を行なってみたのですが、変形にはやり方が色々あるようなのと、 一つのメニューに統合されている訳ではなさそうなので探し当てるのが難しいです。

2023/12/28

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

POV-Ray 3.8。先日、概ね明るくレンダリングされると記したのですが、シーンによっては逆に なる場合もあるっぽい。

POV-Ray 3.7 chess scene POV-Ray 3.8 chess scene

左の明るい方が3.7、右の暗い方が3.8。こんなに差が出る?とは思ったりも。原因はよく判らず。

2023/12/27

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

Linuxでは子プロセスを生成するのに fork()じゃなくてclone()を使っているのを今日知りました😅。

2023/12/26

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

調べ事をして終了。

2023/12/25

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

先日ビルドした コマンドラインの povray 3.8.0-bata2。 手持ちの POVファイルをいくつかレンダリングしてみたり。3.7.0と全くレンダリング結果が変わらない ものもあれば 変わるものもあるようです。概ね photonを使用した場合に明るくレンダリングされるみたい。

POV-Ray 3.7 bench scene POV-Ray 3.8 bench scene

上記画像は8KサイズでレンダリングしたものをGIMPで960x540に縮小したものなので、 ぱっと見ではあまり違いが判らない感じですが、真ん中のオレンジの台(?)の下に 置いてある金属のリングの周りが、3.8では明るくなっています。3.7では光源が反射して 影になっている部分を照らしている感じでは無いのですが、3.8では反射光が影を照らしている ので明るくなっていると思われます。

2023/12/24

AM中に起床。

掃除したり洗濯したり。

libjxlの cjxlが「Invalid relocation.」で動かない件。 スタティックリンクをすればイケないか?と思い、

cmake -DBUILD_SHARED_LIBS=0 -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF ..
cmake --build . -- -j$(nproc)

のように「-DBUILD_SHARED_LIBS=0」を足してからビルドしてみたり。 ビルドはできて cjxlも「Invalid relocation.」でロードに失敗するという事は無くなりました。 ただ、cjxlの圧縮にかかる時間が滅茶苦茶長くなっています。 8KサイズでレンダリングしたPOV-Rayのベンチマークシーン画像を圧縮リファレンスにしているのですが、 2023年2月頃のv0.9.0(以前のメモ)のcjxl実行ファイルでは 12秒くらいで圧縮できていたのが 今回ビルドできた v0.10.0では 22分くらいかかるようになってます。 てか100倍遅くなってるんですけど...😓。 しかも前よりちょっとファイルサイズも大きいです。何かバグってるのか?というレベル。

そういえば、POV-Rayがマルチスレッド対応された3.7から WindowsGUI版しか使っていませんでした。 GUI版ではレンダリング途中の画像が表示されるのですが、あまり大きな画像を表示しようとすると GDIの2GB制限に引っかかるためレンダリングサイズの上限が限られています。で、Unix(系)向けのソースコード をCygwinでビルドできないか試してみたり。現状Cygwinは未サポートプラットフォームなので 「#error ディレクティブ」を踏んでエラーになるのですが、コメントアウトしてコンパイルを 進める必要がありました。で、SIMD関連で関数や定義が見つからないというコンパイルエラーになったものの、 gccで用意されているヘッダファイルをincludeする事で実行ファイルの生成に成功しました。 インストールしてscenes/advanced/benchmark/benchmark.pov をレンダリングしてみたところ、 レンダリングもイケました。「Work_Threads=n」というコマンドラインオプションが 使えるようになっていて、スレッド数を指定する事もできます(デフォルトは「論理プロセッサ数」 が指定されたのと同じ)。あと、POV-Ray 3.8.0-beta2 なのでWindowsGUI版よりちょっと新しかったりしますが、 何が変わっているのかはよく判っていません😅。 なにより、(シーンファイルによるかも知れませんが)実行時のプロセスサイズが 数十MiBと物凄く小さいです。色々試してみよう。

2023/12/23

AM中に起床。

そういえば、Windows11でタスクバーのボタンをWindows10のようにバラす事ができるようになっているらしい。 23H2で来る機能かと思っていたのですが、22H2でもできるようになっていました。 Windows10のタスクバー設定でいうところの「タスクバー ボタンを結合する」の項目を 「結合しない」にした時相当の動作になるようです。 Windows11では項目の意味が分かりにくくて「個人設定」→「タスクバー」の中にある 「タスクバーの動作」の項目の「タスク バーのボタンをまとめラベルを非表示にする」 を「なし」にすれば ボタンをバラす事になるようです。 勝手な推測ですが、個々のウインドウは個別にボタンがあるのが前提で、それらのボタンをまとめて 一つのウインドウ切り替え(?)ボタンにしたものを「ウインドウ毎のボタンをまとめたボタン(ラベル非表示)」 という事にして、その機能を「なし」に設定すると ウインドウ毎のボタンにバラされるという感じなのかと。 まぁいずれにしても なんのこっちゃ?って項目の説明文なのですが、できるのでヨシとしよう。
Windows10では 7+ Taskbar Tweakerを Windows7の頃からずっと使っているのですが(以前のメモ)、 7+TTの作者ブログで Windows11はサポートできない感じの事が記されていました。 もしWindows10の機能を復活したような感じなのだとすれば 7+TT のWindows11対応も可能になるのかなぁ? (グループをバラすのはWindows10でも 7+TTを使わないとできないので)と期待したりも。

libjxlのv0.9.0ってのがリリースされている模様。 gitからpullするビルド方法を使うと v0.10.0になりますが。さておき、ビルドしてみたものの、 djxlは 手持ちのjxlファイルのデコードはできるものの、cjxlの方が

$ cjxl --help
Cygwin runtime failure: /usr/local/bin/cjxl.exe: Invalid relocation.  Offset 0x320f82197 at address 0x100403645 doesn't fit into 32 bits

で動かなかったり。Cygwin側の問題のような気もしますが原因はまだ不明。 rebaseなども行なってみたのですが解決できず。あと、gccだとcjxl以前に highwayってライブラリの シンボルが衝突しててリンクに失敗する模様。しばらく様子見。 それにしても今回に限らず cjxlの方はビルドや生成された実行ファイルのトラブルに見舞われがちです。

libjxlがgccのビルドでリンクに失敗する件。../lib/libjxl_cms.dll.a よりも ../third_party/highway/libhwy.a を手前に持ってきてリンクすればイケる模様。ただ、cjxlもdjxlも Segfaultして動かない実行ファイルが ビルドされました。うまくいかないもんです。

2023/12/22

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

調べ事をして終了。

2023/12/21

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

そういやノートPCのWindows11のWindowsUpdateをしていなかったので実施。 なにやら色々な更新があったのですが 23H2は来ていない模様。 手動でアップグレードする方法はあるらしいですが まぁいいか。

2023/12/20

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

調べ事をして終了。

2023/12/19

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

Web巡回して終了。

2023/12/18

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

調べ事をして終了。

2023/12/17

AM中に起床。

掃除したり洗濯したり散髪に出かけたり。

D言語のdo~whileステートメント。
tree-sitterでは編集途中の壊れた文法の状態ではインデントするか否かが確定できない場合が 多々あります。例えば for文で「for(なんとか;かんとか;どうした){」のように「{」まで 入れた状態では、まだブロックが形成されていないと解釈されるためインデントが機能しません。 この為、electric-pair-modeを併用して空のブロックを強制的に形成させる事で対応しています (以前のメモ)。
で、doステートメントがややこしいのは「do{}」の状態ではまだdoステートメントとみなされなくて、 「do{}while();」のようにwhileまで入れないとダメなようです。この為、一番最後にwhile()を 書くまでの「do{}」のブロックはインデントが正しく機能しません。 ひとまず「do{};」と書いておけば、expression_statementと一時的に解釈されてブロック内の インデントは機能するようです。 先にブロック内を決めないとwhile()が決められないという場合は、前述の方法で 機械に合わせて人が対応するしかないようです。
前にも思った通り、機械の都合というのは分からなくはありませんが、 文法的に不完全な場合に確率的に可能性の高い文としてtree-sitter側で解釈できないものかなぁ? とは思います。難しいとは思いますけど😓

MFゴーストのアニメ。めっちゃ途中で最終回?って思ったけど二期は2024年に放送されるらしい。

2023/12/16

昼前起床。寝すぎ。

そういえば、D言語で doステートメントのぶら下がりってイケるんだっけ?と思ったり。 もちろんイケるようなのですが、そもそもdoステートメントでぶら下がりを使う場面は稀かもしれないなぁ? とは思ったりも。 で、自作の d-ts-mode で doステートメントやwhileステートメントのぶら下がり のインデントってできるようになってたっけ?と思って確認してみたら出来るようになってないな...😓。 tree-sitter対応の構文を すっかり忘れ去ってる感じだったのですが、 ifステートメントのぶら下がりインデントですったもんだして導き出したコード (以前のメモ)を元に for、while、foreachとforeach_reverse、do~while() のぶら下がりインデントに対応してみたり。 ひとまずイケたような気がする。

個人的には、ぶら下がりはほぼ使わないのですが、 Emacsのソースコードでは結構ぶら下がりが多用されていて、

  for (なんとか)
    if (かんとか)
      どうする;

みたいなのが割と普通に書かれているように思います。この為、デバッグprintを 仕込もうとすると、

  for (なんとか)
    {
      printf("debug ...");
      if (かんとか)
        {
          printf("debug ...");
          どうする;
        }
     }

のように無駄にインデントの深さが変わってしまうのもあって、面倒臭いなぁ...と 思う事はありました。特にGNUインデントスタイルは「{」自身もインデント対象で 「{」の中のブロックも、もう一段インデントが行われる感じなので 元のコードに戻すのも面倒です。
K&Rインデントスタイルで且つぶら下がりも使わないとすると、

  for(なんとか){
    if(かんとか){
      どうする;
    }
  }

に対して、
  for(なんとか){
    printf("debug ...");
    if(かんとか){
      printf("debug ...");
      どうする;
    }
  }

という感じで、インデントを壊さずにデバッグprint行を足せます。また、元のコードに戻すのも デバッグprint行を削除すれば元に戻るので、ちょろっと弄ってまた元に戻すという事が 簡単だと思います。

2023/12/15

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

Web巡回して終了。

2023/12/14

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

そういやEmacsの29.1.91もしくは29.2は、年内に出ることはないのだろうか? 年をまたぐとCopyrightの西暦をインクリメントするコミットが入るので、 差分を見るのに邪魔になるのだよなぁ?とは思ったりも。

2023/12/13

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

WindowsUpdateついでに Cygwinパッケージをアップデート。

Web巡回して終了。

2023/12/12

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

Google 25周年のゲーム。なんとか全部見つけられましたが、こんなのあったんだと思うものもありました。 もっとも検索された絵文字は❤️なのか(VS16を入れてますがChromeやEdgeだとモノクロ表示ですけど)とは思ったりも。 探す対象のトリビアにはなっていないものもイラストに含まれているようです。

2023/12/11

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

Web散策をしていて、Unicodeの改行コードの仲間に 「
」(U+2028; Line separator)と 「
」(U+2029; Paragraph separator)というのがあるのを知ったり。 EdgeとChromeではいずれも空白っぽい文字が表示され、Firefoxだと文字自体が無視されているように 表示されるようです。Emacs上では MeiryoKe_Consoleやメイリオでは特別な文字が表示されるみたいですが、 MSゴシックでは半角スペースのように表示されるみたい。 結局、改行コードの仲間のようですが、どういうふうに振舞う文字なのかはイマイチよく判らず。 Emacsではフォントによってはシンボル文字のように可視化されるので改行に影響する感じには見えません。 しかし、文字処理ライブラリによっては事故が起こる場合があるようなので、 単に邪魔な文字という感じがしなくもありません。謎すぎる🤔。

2023/12/10

昼前起床。

掃除したり洗濯したり。

MS-IMEで長い文を入力して変換するとき、途中で打ち間違えているのに気づかず 変換した時に気づく場合があります。これまで打ち間違いを直すのはあきらめて、一回確定してから 間違えている部分を再度入力していたのですが、一応直す方法があるのを知ったり。 例えば「うちまつがい」と入れて気づかず変換すると「内まつがい」みたいになるのですが、 「内」は「打ち」に直すとして、C-dで次の文節に移動した後、「まつがい」までが1文節となるように C-lで伸ばして変換すると「枳貝」に一旦変換されます。ここでC-zを入れると「まつがい」 の部分が未変換状態に戻るので、C-h(BS相当)などで「まつがい」を「まちがい」に入力し直せば「間違い」 に再変換できるという感じです。 訂正し終えるまで一度も確定はしていないので、辞書的には誤変換を覚えないという感じにはなるみたい。 ただ、何かあるとすぐにRET(==Enter)で確定してしまう癖が付いてしまっていてダメです😓。

2023/12/09

昼前起床。寝すぎ。

そういえば、いつの頃からかChromeのタブにマウスカーソルをかざすとそのタブで使用している メモリ量が表示されるようになっています。 数十MBから100MB以上までいろいろあるようですが、そんなに使っているのか?とは思ったりも。 確かに 4K解像度だとフルスクリーンまで広げれば画面表示だけで32MB程度は必要になるかとは思いますが、 2000年頃のPCだとメインメモリ自体が64MBくらいしか無かった訳で。 Web閲覧とかやってることはそんなに変わっていない気がするのですが 何にメモリを食ってるんだ? とは思ったりも。

2023/12/08

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

Edgeで新しいタブページを開いたところ、いつもは画面の下の方に検索窓やら 最近アクセスしたサイトのアイコンだとかが並んだレイアウトなのですが、 今日開いた画面は何故か検索窓やアイコンが上の方に表示されていたり。 アップデートした訳じゃないのになんでだ?と思ったのですが、 どうやら壁紙写真の構図に配慮したレイアウト変更になっているんじゃないか? と思ったりも。もしそうだとすると、ちゃんと写真を見てレイアウトをチェックしている人(?)が居る って事と、それに応じて検索窓の表示レイアウトを変える仕組みが組み込まれている って事になるかと思ったり。ほぅ.....(真相は判りませんけど)

2023/12/07

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

TRAMPで カスタム変数 tramp-process-connection-type を変更して ptyにするかpipeにするか。 nilにすると メソッドによらずpipeを使用するようになりますが、「/ssh:」はうまく動かなくなります。 メソッド毎にpipeにするかptyにするかを切り替えるような仕組みが欲しいような気も。

2023/12/06

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

調べ事。

2023/12/05

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

そういえば dockerコンテナを操作するのに sudoコマンドを使用する必要がありますが、 TRAMPで dockerコンテナの中のファイルにアクセスする際は sudoコマンドを 「/ssh:user1@host1|ssh:user2@host2|sudo:host2|docker:コンテナID:/pathto/」 のように挟めば良いらしい。この例ではhost1はリアルマシン、host1上で VMのhost2は動いていて、 dockerコンテナはVMのhost2の中で動いているという想定です。

2023/12/04

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

TRAMPでのローカルからリモートへのファイルのコピーが遅い件。
結論としては ptyを使っているから遅い。だからpipeを使えば良い。という感じのようです。 lisp/net/tramp.elの中に tramp-process-connection-type というカスタム変数があり デフォルトは t となっています。tの場合は ptyの使用が優先されるみたいです。 この変数を nilにすると ptyを使わずにpipeを使うようになるみたい。 ただし、「/ssh:...」は使えなくなるので、SSHの公開鍵認証設定を行なった上で「/sshx:...」を 使うと tramp-process-connection-type が nilに設定されていても接続できるようになります。 そして、ptyの時に比べると圧倒的に高速にファイルのコピーが行なわれるようになりました。 なんてこった😓。
ファイルサイズは1MiB以下くらいまでならあまり待たされる感じは無さそうですが、 3MiBを超えると待たされる感じになります。ただ、ptyを使った通信では C-gが受け付けられなかったのですが(write()システムコール実行で割り込みできない感じだった?)、 pipeではC-gが受け付けられるのでうっかり実行してしまっても大丈夫かも知れません。
あと、「/scp:...」を使うと多段接続ができない為、VMの中のコンテナにリモートアクセスする事が できなかったのですが、「/sshx:user@host|podman:コンテナID:/pathto/」でコンテナ内の ディレクトリにファイルをコピーするのも大丈夫そうです。

2023/12/03

AM中に起床。

掃除したり洗濯したり。

TRAMPでのファイルのコピー。 write()での書き込み時に指定するファイルディスクリプタを isatty()で調べてみたところ 1が返ってきたので、pipeではなく端末で開いているみたい。また、ttyname()で調べてみたところ 「/dev/ptmx」てのを開いているらしい事が判りました。ptmxって何?🤔

2023/12/02

起きたら午後もいい時間。寝すぎ。

Inkscapeの1.3.2が出ていたり。 データが消失するような重大バグがあったようで修正版としてリリースされたもよう。

調べ事。まだよく判らず。

2023/12/01

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

TRAMPでのファイルのコピー。 lisp/net/tramp-sh.elの関数 tramp-do-copy-or-rename-file-via-buffer で行なっていて、 最小限の実行コードとしては

    (with-temp-file "/ssh:user@host:/tmp/remote_file.jpg"
      (set-buffer-multibyte nil)
      (insert-file-contents-literally "local_file.jpg")
      )

で、ローカルからリモートへの遅いファイルコピーの様子が見られるようです。 ファイル書き込みには関数 tramp-call-process-region てのを使ってそうですが まだよく判らず。


TOP PREV