テレワーク。早くもなく遅くもなく終了。
調べ事。判らん。
テレワーク。早くもなく遅くもなく終了。
そういえば10月19日に Emacs 29.1.90 がリリース
されていたのですが、次はいつ頃になるのかしら？
テレワーク。早くもなく遅くもなく終了。
Emacsの「/ssh:」書き込み転送でwrite()が遅い件。
EmacsのTRAMPでやっている事を C言語で書いて遅いのか確認してみたり。
sshでリモート接続して「/bin/sh -i」でインタラクティブシェル起動している子プロセスを
pipe()で繋いだ状態で、親プロセスから TRAMPでやっているように
(以前のメモ)base64デコードしてファイルに書き込むコマンド列を
送り込んでみたところ、一応リモートで展開してデータも問題無い感じになりました。
で、プログラム自体はCygwinでコンパイル＆実行したのですが、260KiB程度のデータを
1回のwrite()で書き終えていて、しかも一瞬で送り込めているようです。
パイプじゃないのか？🤔
でも、コマンドラインから「base64 foo.jpg | ssh user@host 'base64 -d > /tmp/foo.jpg'」
でリモートにファイルを送り込むのが一瞬なのだから 不思議な結果ではありません。
それから言うと Emacsの方は何をやればこんなに遅くなるのか謎が深まるばかり。
テレワーク。早くもなく遅くもなく終了。
調べ事。
AM中に起床。
掃除したり洗濯したり。
Emacsの「/ssh:」書き込み転送でデータ化けする件。というかwrite()が遅い件。
Cygwinの straceコマンドでシステムコールをトレースしてみたのですが、write()が本当に遅いだけ
のように見えたり。なんかやりようが無いなぁ？🤔
VMware上のFedoraのEmacsで、自分自身に「/ssh:」で開いたディレクトリにローカルファイルの
コピーを行なってみたところ やっぱり遅かったり。topで見てみると TRAMPか起動したと思われる sh が
何やら全力で動いている感じに。遅いって事が判ったので、
Fedoraの方でもEmacs-29.1.90を野良ビルドしてみて、emacs-w32でデバッグに使っていた書き込み速度を
測れるコードを使って観察してみたり。ただ、少し様子が違う感じも。
write()での書き込み速度は emacs-w32のように3200[byte/sec]みたいな事は無くて、Fedoraの方では
950000000[byte/sec] は出ているようです(ファイルの書き込みに比べると1/10くらいの速度みたいですが)。
ただし、1回のwrite()のmax書き込み量を98304byte(32768byte*3)にしているのですが、
実際には 13824byteずつしか書かれていないようです。
それよりも、実際に全てのデータを書き込んだ後に時間がかかっているようです。
データ書き込み後に shが全力でしばらく動いて、それが終わると完了という流れみたい。
いずれにしても emacs-w32よりはマシではあるものの やっぱり遅いと思います。なんだこれ？🤔
AM中に起床。
Emacsの「/ssh:」書き込み転送でデータ化けする件。
どうやら次のような感じになっているみたい。
そもそも write()が遅いようで、例えば 64KiB のデータをwrite()するのに 3200[byte/sec]
くらいしか出ていません。そして分割してwrite()する場合、初回のwrite()が返ってきた
すぐ後に次のwrite()を実行すると書き込みが受け付けられた量が極端に減る場合があるようです。
見掛け上、先行するwrite()は受け付けたデータ量で一旦リターンするものの、実際には
非同期でゆっくり書き込んでいて、続けてwrite()すると 先行するゆっくり書き込みが終わった分
の量しか受け付けられなくて、後続の書き込みデータ量が減っているように見える...という事っぽい。
結局スループットが合っていなくて、write()の先にあるバッファが溢れ気味状態という
事なのだと想像します。
で、先日「もりもりのデバッグprintを削ると何故かうまく動かなくなる」と記したのですが、
デバッグprintにより意図せず 先行write()と後続write()の間に waitが入った状態になっていたようです。
そこで、デバッグprintの代わりに nanosleep()を使って 意図的に30ms程度の waitを入れてみた
ところ、バッファ溢れ(write()の戻り値が書き込み希望量より少ない)は起こらなくなりました。
これでデータ化けも解消するか？と思ったのですが、失敗確率は大分下がるもののやっぱりまだ化けるようです。
いずれにしても Cygwinの問題という気がします。
ところで、「/ssh:」の書き込みの何が遅いのだっけ？ というのを調べるのがきっかけだったのですが、
write()が遅いのは判ったものの、3200[byte/sec]はいくらなんでも遅すぎないか？とは思ったりも。
例えば、
$ cat testfile.txt | ssh user@host 'cat > /tmp/testfile.txt'
テレワーク。気持ち早めに終了。
Emacsの「/ssh:」書き込み転送でデータ化けする件。送り側となる
src/sysdep.c:emacs_full_write() で送信側のデータを横取りして見た感じ
こちらは大丈夫そう(当たり前かも知れませんが)。
どんな感じのデータを送っているのかを見てみたところ、次のようなのを
送り込んでいるようでした。
(base64 -d -i | cat > /tmp/filename.jfif) << '128bitの16進hash値' 2>/dev/null; echo tramp_exit_status $? /9j/4AAQSkZJRgABAQAASABIAAD/2wBDAAQEB base64エンコードされた文字列 xxxxxxxxx <<中略>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 128bitの16進hash値
昼前起床。寝すぎ。
先日コンテナに多段接続でファイルアクセスできる事を知ったのですが、
初段は「/ssh:」でなくてはダメなようで、うっかり大きなファイルの書き込みを行なうと
死ぬほど時間がかかります。「/ssh:」だとそもそも何が遅いのだっけ？と思い調べてみる事にしました。
データの書き込みは src/process.c:send_process() で行なっているようで、中を辿ると
src/sysdep.c:emacs_full_write() の中で実行している write()システムコールに行きつきました。
デバッグprintを仕込んで調べてみた感じ、「ssize_t n = write (fd, buf, min (nbyte, MAX_RW_COUNT));」
で書き込みたい量が指定されているのですが、実際に書かれたデータ量(戻り値のn)は 257バイト程度に
留まっているようです。この為、diredでローカルファイル感覚で 10MiBくらいのファイルをコピーしようものなら
さっぱり終わる気配が無い感じになりました(デバッグメッセージの目測で 1500Byte/秒くらいしか出ていない)。
書き込みに必要なデータは用意されている訳ですが、それが勝手に分割書き込みされてしまっているので
どうしようもない状況です。うーむ🤔。
それにしても、Windows上で動作しているVMとの通信なので、物理的なネットワークを伝っている
訳ではない事を鑑みるに、いくらなんでも遅すぎないか？という気はします。
書き込みが終わるのをほっぽらかしていたのですが、数時間を要した後に190KBくらいしか
書けていなくて正しくコピーできませんでした。ますますうーむ🤔。
リモートのPNG画像ファイルを表示しようとしたら何故かSVG画像と判定されるものがありました。
切り分けてみると次のような感じになっているようでした。
リモートのファイルはEmacs上はデータとして扱われる為、ファイル拡張子によるフォーマット判定ではなく
データのヘッダ部分に置かれるマジックナンバーを見てフォーマット判定しているのですが、
我が家の環境の都合で lisp/image.el内の image-type-header-regexps をちょっと弄っていました。
この時、pngよりも先に svgのヘッダのマッチを見る事になってしまっていて、たまたま pngデータ内に
svgのヘッダ判定にマッチするデータ列があった場合に svgと誤判定される感じになっていました。
判定の順番を変更して対応してみたり。なかなかレアな状況だったかも知れません。
ちょっと解ってきたようなそうでも無いような。TRAMPの「/ssh:」でデータ転送する際に
lisp/net/tramp-sh.elの中の tramp-inline-compress-commands ってカスタム変数で指定された
圧縮/展開 コマンドを使って転送経路上はデータを圧縮して送るようになっているようです。
どうやら転送に失敗している場合は送り先で展開した時に失敗している節が見られました。
そこで「("cat" "cat")」のように圧縮しないで転送するとどうなるか？
と思って試してみたところ、データバイト数的には送れているようなのですが、所々データが
化けているようです。ここから推測しますに圧縮しながら送っているデータが途中で化ける為に
展開に失敗していて、結果として途中でファイルが千切れているような感じになっているみたい。
送信側はデータの受信に失敗している事は判らないので全部送り終えるまで続けるものの、
受信側ではデータの壊れを検出して以降はデータを捨てているものと思われます。
という訳で、データ化けの原因をなんとかしないとどうにもならないような気がしたりも。
テレワーク。早くもなく遅くもなく終了。
何気に VMware上のFedora上で podmanを使ってコンテナを起動して、そのコンテナに
ホストのCygwin emacs-w32 から「C-x C-f /ssh:user@hostname|podman:コンテナID/path」で
多段接続でコンテナの中のファイルを編集できるらしいというのを知ったり。
でも、試してみたところ何故かEmacsがCPUを食ったまま無反応に。
C-gで一応止まるのですがうまくつながらず。そういやと思い、もう一つ Emacsを起動して
同じ事を試すと今度はうまくコンテナ内のファイルを編集できました。
以前、
「mux_master_process_new_session: failed to receive fd 0 from client」なるメッセージが
trampの一時バッファに表示されるという話があったのですが、
今回コンテナに接続するときも初段のssh接続で同じようなメッセージが出ていて、
今回は接続ができない状態のままになっているのが直接の原因のようでした。
これ、前も結局原因が判らずじまいのままフェードアウトしていました
(メッセージは出るがリトライされていて実害は無かった)。
以前にも 2つめに立ち上げたEmacsだと何故か遭遇する(例えば普通に使う分を1つめとしたとき、
テスト起動した2つめがダメ)という事がなんとなく傾向としてあって、3つめ以降であれば
大丈夫だった事から、テストはそれで避けていたというのもありました。
ひとまずな回避方法にしても大分イマイチな感じです....🤔。
テレワーク。気持ち遅めに終了。
Web巡回して終了。
テレワーク。早くもなく遅くもなく終了。
SAI2の新しいのが来ていたり。おつかれさまです。バグ修正がメインのようです。
調べ事。
昼頃起床。寝すぎ。
掃除したり洗濯したり。
エルフの寿命。葬送のフリーレンでは結構長めの設定(人間の寿命の10倍以上)のように思ったりも。
ファンタジー世界の1000年だとあまり大きく世界観が変わったりしないのかも知れませんが、
現実世界での1000年は文化や生活様式が大きく変わっています。現実世界での1000年は流石に長い
と感じるかもなぁ？とは思ったりも。逆に目まぐるしく変わるので退屈はしない？
Inkscapeの1.3.1が出ていたり。
1.3をインストールしたまま1.3.1を上書きしたら libsigc-2.0-0.dll が見つからないというダイアログが開いて
起動できなかったり。一度 アンインストールしてから再度インストールし直したところ
大丈夫そうです。御参考まで。
VMwareのFedoraを38から39にアップグレードしてみたり。Emacsは29.1が入る模様。
いつも通り anthyが先祖返りするのを手動で対応してひとまず起動は大丈夫そう。
そういやFedoraのEmacsのフォントは「Droid Sans Japanese」てので表示されているのですが、
「鯖」の文字はJIS90の字形になってるみたい。
あと、3DモデラのWings3Dが互換が無いという事でアップグレード時に消滅していたのですが、
パッケージが無くなった訳ではなくて再度インストールすれば良いようでした。
そこで知ったのが Version 2.3が出ていたという事実。2023年10月上旬に出ていたらしい。
と言う訳でしばらくアップデートしていなかったWindows版の方も Ver2.3を入れてみたり。
昼頃起床。寝すぎ。
Emacsでフォントを切り替えて表示してみていたときに、
以前知った JIS90字形のフォントの方が多いなと思ったりも。
多くはJIS90の字形となっているようです。
「清風明月」ってフォントは 鯖はJIS2004の字形ですが 辻と禰はJIS90の字形(辻󠄀,禰󠄀)になってる
ようです。
因みに「PlemolJP Console HS」や「おつとめフォント」はJIS2004の字形になっていますが、
「VARIATION SELECTOR-17」を付加してもJIS90の字形に切り替わらないようです。
意味が通じれば良いのであれば字形は気にしなくても良いかも知れませんが、
字形が問題になるような場合は Windows標準搭載フォントのようにVS17で切り替えられるフォントを
使った方が良いのかも知れません。
テレワーク。早くもなく遅くもなく終了。
次回のチコちゃんに叱られる(12月1日放送予定)は生放送らしい。
.....CG合成がリアルタイムレンダリングに対応するって事なのか？と思ったりも。
テレワーク。遅めに終了。
テキスト編集をしていて 稀に ある行を削除した後に別の文字列行をヤンクしたい場合があるのですが、
C-k(kill-line)すると kill-ringに保持しているヤンクしたい文字列行が消えてしまうので、
先にヤンクしてから削除したい行を C-kで消すという順番で行ないます。
しかし、最後のC-kでkill-ringが壊れてしまうので、別の所で同じ操作を繰り返したいと思っても
うまくいきません。 kill-ringを壊さない delete-line みたいなのがあれば良いのですが、
無いなぁ？と思ったりも。
kill-ringに入れない方法として delete-region があるので応用の範囲内かと思い直したりも。
雑に以下のような関数とキーバインドを.emacsに置いてみたり。
(defun delete-line ()
"delete-line"
(interactive)
(let ((beg)
(end))
(setq beg (point))
(goto-char beg)
(move-end-of-line 1)
(setq end (point))
(if (= beg end)
(delete-char 1)
(delete-region beg end))
))
(global-set-key "\e\ek" 'delete-line)
テレワーク。早くもなく遅くもなく終了。
調べ事。
テレワーク。遅めに終了。
そういえば、昨日 TVの番組表を表示するとテレビ東京のロゴ画像が表示されないなぁ？と
思ってました。今日たまたまテレビ東京の番組を観ていたら「新テレ東」なる文言が流れていて、
そういやと思い番組表を見てみると新しいロゴ画像になってました。そういう事だったのか？
テレワーク。遅めに終了。
Web巡回して終了。
AM中に起床。
掃除したり洗濯したり。
そういえば CygwinのMLを見ていて、CygwinパッケージのVimって8.xなのかと思ったり。
CygwinのVimは8.2.4372というバージョンで2022年2月21日にリリースされたようです。
Vim 9.0のリリースは2022年6月のようなので、普段使いしている人は 新しいのは
来ないのかしら？とは思うかも知れず。
昼前起床。
Emacsで「ZERO WIDTH JOINER」や「VARIATION SELECTOR」を入力するのに
「C-x 8 RET」(insert-char)で16進数指定でコードポイントを指定するという方法がありますが
コードが覚えられません🥺。そこで以下のような ELISP関数を作ってみました。
(defun my-insert-special-unicode-char ()
"特殊なユニコード文字を挿入する"
(interactive)
(let ((special-unicode-chars
'(
("ZWJ" . (name "ZERO WIDTH JOINER" code #x200D))
("ZWSP" . (name "ZERO WIDTH SPACE" code #x200B))
("VS15" . (name "VARIATION SELECTOR-15" code #xFE0E))
("VS16" . (name "VARIATION SELECTOR-16" code #xFE0F))
("VS17" . (name "VARIATION SELECTOR-17" code #xE0100))
("VS18" . (name "VARIATION SELECTOR-18" code #xE0101))
("VS19" . (name "VARIATION SELECTOR-19" code #xE0102))
("VS20" . (name "VARIATION SELECTOR-20" code #xE0103))
))
(charlist '())
(selected nil)
)
(dolist (elm special-unicode-chars)
(push (car elm) charlist)
)
(insert-char
(plist-get (cdr (assoc
(completing-read "char: " charlist)
special-unicode-chars)) 'code))
))
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
テレワーク。遅めに終了。
調べ事をして終了。
テレワーク。気持ち遅めに終了。
GIMPの 2.10.36がリリースされてたり
(アナウンス)。
年内は 3.0は来ないかもとは思ったりも。
テレワーク。遅めに終了。
東京の気温100年ぶりに記録更新。
100年前にも同時期に同じくらいの気温だった事があったって事だろうか？
テレワーク。早くもなく遅くもなく終了。
Web巡回して終了。
昼前起床。
掃除したり洗濯したり。
Windows11の23H2が流れ始めているようですが、我が家のノートPCにはまだ来ていない模様。
ところで、全く気づいていなかったのですが、いつの間にか Windows11の Emacs29.1で Unicode 15.0 の
絵文字が Segoe UI Emojiで表示できるようになっていました。これっていつイケるようになったんだっけ？🤔
因みに前に調べたのは7月29日頃でした。
Webで調べても、夏頃の時点でpreview版では表示できるって情報しか見つけられなくて、
いつ正式サポートされたのかよく判らず。
フォントのバージョンやフォントファイルの日付を調べてみると、バージョンは1.45で
ファイルの日付が 先月の10月14日になっていたので、10月のアップデートで入ったのではないかと推測しています。
「ONEPIECE(107)」。色々山盛り。
AM中に起床。
ちょろり買い物にお出かけ。なんかちっとも寒くならない。
アニメの「葬送のフリーレン」。先日放送された回を観た時に
「あれ？ こんなにリップシンクしてましたっけ？」と思ったり。
素人なのでよく判りませんが、派手なアクション以外にも細かい所作がいつもと違う印象を受けました。
個人的にシュタルクが上着を羽織るシーンがなんかスゴって思いました。
昼過ぎ起床。寝すぎ。
先日の「﷽」は「باسم الله الرحمٰن الرَّحِيم」と書けるらしい件。
GoogleChromeでの表示をよく見てみると並びが左右逆だな？と思ったり。
Emacsでの表示は以下のような感じになっています。
文字列は「[﷽][باسم الله الرحمٰن الرَّحِيم]」を表示しています。
因みに、上記画像はテキストプロパティを変更して一つのバッファに複数のフォントファミリを混在表示
するような自作ELISPを使用した結果なのですが、「Noto Sans Arabic」は何故か
テキストプロパティでファミリ名指定しても上手く認識できないようです。
.emacsに「(set-fontset-font t 'arabic "Noto Sans Arabic")」
のように記せば表示されますが、この方法だとテキストプロパティの変更が効かなくなるので
二つに分けてスナップショットを取る必要がありました。あと、「Noto Sans Arabic」には「[」や「]」の
字形が含まれていないようなので豆腐になっています。
もう少し様子を見ていると、どうやらアラビア文字の禁則処理が行なわれているのを、
並びが逆になっていると勘違いしただけだったみたい😓。
GoogleChromeで見た時、以下のように たまたま改行が文中に来るように表示されていたからでした。
因みにEdgeでも同じです。
文字列は「[باسم الله الرحمٰن الرَّحِيم][باسم الله الرحمٰن الرَّحِيم]」と記されています。
右から左に書かれるので、「باسم الله الرحمٰن الرَّحِيم」のうち「الرَّحِيم」の部分は文末なので、「باسم الله الرحمٰن」
の部分で改行されるという事のようです。
ややこしいのは、ブラウザ自体はシステムロケールの都合で左から右に書く言語のつもりがある為か、
見た目で左側の「[باسم الله الرحمٰن الرَّحِيم]」で改行されている訳
ではなく、右側の「[باسم الله الرحمٰن الرَّحِيم]」で改行されているようです。そして アラビア語の文中で
改行する事になった場合に右から左に書く事を考慮した改行になっているという感じみたい。
話は逸れますが右から左方向に書く言語の場合、「括弧」の扱いはややこしいのかも。
例えば「(」を開き括弧「)」を閉じ括弧とするのは左から右に記す言語での話で、
右から左に記す言語の場合は「)」の方が開き括弧で「(」の方が閉じ括弧になるかと考えます。
実際どうなのかと思ったところ
こちらのブログ記事
のように括弧は見た目に合うように表示を入れ替える必要があるみたい。
てか、言語の混在表示処理って激ムズ過ぎると改めて思い直しました。
前述Edgeで表示したhtmlファイルをEmacsのewwで表示したら以下のようになりました。
ewwでは右から左に書く言語のWebページだと解釈しているようで、右寄せ表示になっています。
この為、Edgeでの表示と違い 見た目左側の「[باسم الله الرحمٰن الرَّحِيم]」で改行されています。
あと、「[」と表示されている所で「M-x describe-char」を実行してみました。
ASCIIコードとしては 0x5b ですが、describe-charした結果の コードポイントは[#x5d」となっています。
先に知った文字の入れ替えを行なった結果のようですが、アラビア語圏ではASCIIコードと見た目のグリフ
との対応が変わる感じになるので混乱するかも😓。
テレワーク。早くもなく遅くもなく終了。
「﷽」の表示。
一つのUnicodeのコードポイントに対して複数のグリフが返るようなものは、
ちょっと弄ってどうにかなる感じでは無さそうなので、
Emacs上で「﷽」をTahomaやArialで表示するのは断念🥺。
そういや、「﷽」を普通にアラビア語で書けないものなのだろうか？
と思って調べていると、
「Why is "﷽" a single character in Unicode?」
というredditの書き込みがあるのを知ったり。
Google翻訳に頼ったところ
「パキスタンでは、政府のすべての公式文書はビスミラ合字で始めることが法律で義務付けられています」
という話があって、一つの文字とすることで簡単に入力できるというのが目的の一つとしてあるみたい。
アラビア語で同じように記せば、同じような表示になるのか？と思ったところ、
前述の書き込みのスレッドによるとアラビア語で記せば
「باسم الله الرحمٰن الرَّحِيم」となるらしい。Tahomaで記された「﷽」とは
ちょっと雰囲気が違うようにも思ったのですが これで同じなのかしら？
「ﷺ」(U+fdfa)も同じ感じの目的の文字らしいのですが、「﷽」(U+fdfd)
と違ってTahomaでも一つのグリフで表示されるようです。
「﷽」の用途に比べると使用頻度的にどうなのだろうと思う 「㋿」も同じような扱いかも？
とは思ったりも。「㋿」の方はどうしても必要なのか？と問われるとそこまででも無い気はしますが。
テレワーク。気持ち早めに終了。
「﷽」の表示。
Emacsで今どのようになっているのか再度調べてみたり。
harfbuzzの方はよく判らなかったので、uniscribeの方を見てみたところ、
ScriptItemize()とScriptShape()でグリフを得ているというのが判りました。
でも、今の構造ではどうしようも無い状況っぽいかも。
まず src/w32uniscribe.c:uniscribe_encode_char() という関数でUnicodeのコードポイントをグリフコードに
変換しているのですが、そもそも一つのUnicodeコードポイントに対してグリフコードは一つという前提
になっているようで、複数のグリフコードを得たとしても関数の戻り値として返せる仕組みになっていません。
あと、ScriptShape()がグリフコードのリストを返すバッファサイズが 2固定になっていて、
5個のグリフで構成されている「﷽」は E_OUTOFMEMORY で実行に失敗しているようです。
失敗した場合やグリフが2個以上の場合は ScriptGetCMap()で (不完全な)1個のグリフを取り直していて、
結果的にScriptGetCMap()で取得した1つのグリフが「﷽」の表示に使用されている(==見切れた表示になる)
という感じになっているみたい。という訳でなんか手詰まり気味🥺。