AM中に起床。
掃除したり洗濯したり ちょろっと投票に出かけたり。
東京都コロナ感染者。新規は 22人。
大分前にWindows10でワイヤレスディスプレイなるものが使えると
いうのを知って少し使ってみましたが、その後は使う事無くそっとしてありました。
久々に使ってみようと試してみたところ、何故かデバイスを見つけられず。
どうやらWindows10の 2004からワイヤレスディスプレイ機能はデフォルトで組み込まれなくなっていて、
機能追加で有効にする必要があるというのを知りました
(参考記事)。
ディスプレイになる側のWindowsで機能追加すれば良いようです。あと、ホスト側もディスプレイになる側も
Wifiに繋いでおかないとダメってのもすっかり忘れてました😓
起きたら午後もいい時間。寝すぎ。
東京都コロナ感染者。新規は 23人。
Cygwin64移行。足りないコマンドとかを追加インストールしたり野良ビルドしたり。
という訳で、普段使いのベースをCygwin64に切り替えてみたり。使ってみると細かい所で
色々足りないとは思いますがその都度対応という感じで🙂
普段あまり使わないものを思いつくまま使ってみるとやっぱりインストールし忘れてます😓。
そういえばと思い Emacsの artist-modeを何気に立ち上げてみたり。
text-scale-adjustでフォントサイズを小さくすれば80年代のパソコンのグラフィックス面くらいの
解像度にはなるかな？と思ってバッファのフォントを小さくしてみたところ、マウスカーソルの位置がフォントサイズの
スケールに連動できていないっぽいのに気づいたり。
少し調べてみたところ posn-col-row という関数でマウスカーソルの位置から文字単位の座標を
得ているようですが、この関数では文字サイズがデフォルトと違っていると位置が合わなくなるみたい。
ただ、artist-mode内の artist-coord-win-to-buf という関数で posn-col-rowで得た値を
何かしら変換しており、ここに補正を加えれば良いんじゃね？という感じで以下のように
.emacs内で関数を上書きしてみたり。
;;text-scale-adjust 変更に対応するパッチ
(defun artist-coord-win-to-buf (coord)
"Convert a window-relative coordinate COORD to a buffer-relative coordinate."
(let ((window-x (/ (* (frame-char-width) (car coord)) (default-font-width)))
(window-y (/ (* (frame-char-height) (cdr coord)) (default-font-height)))
(window-start-x (window-hscroll))
(window-start-y (save-excursion (goto-char (window-start))
(artist-current-line))))
(cons (+ window-x window-start-x)
(+ window-y window-start-y))))
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 24人。
結局、今新規に感染するのはどういう人？ せめてワクチン接種の有無は公表して欲しいものです。
Cygwinの3.3.1が来てるようなので、先に普段使いではない Cygwin64の方に入れてみたり。
立ち上がらないとかそういうのは無さそう。
Cygwin64移行をボチボチ。Emacsで動作するvtermですが、Cygwin32のEmacsでelpaインストールした
時にビルドされたダイナミックモジュールは Cygwin64のEmacsからは使用できません。そんな訳でCygwin64向けの
vtermを別ディレクトリにコピーして .emacsでパスを切り替えて使うという感じにしてみたり。
Cygwin64ではcmakeやlibtoolが入っていなくてvterm-module.dllのビルドに失敗するのを対応しながら
ひとまずCygwin32/64の両対応にしてみたり(正確には個別に用意しただけですが😓)。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 21人。
大阪の新規感染者人数が東京の倍以上あるのはやっぱりおかしいなぁ？
Cygwin64でビルドしたEmacs-28.0.60で画像表示テスト。ちょっと大きいくらいの画像表示だと問題無かった
のですが、20000x20000以上のサイズだと組み込みのJPEG,PNG,PPMだとうまく表示できないようだったり。
オートリスケールしているので表示画像サイズはディスプレイの表示範囲内になる為、そこでメモリが
足りなくなる事は無いハズと思ってます。組み込みのImageMagick経由でJPEG,PNG,PPM表示すると
ちゃんと表示できる事から、何かしら組み込みのJPEG,PNG,PPMに共通の何かに問題があるのかしら？🤔
ちょっとsrc/image.cを眺めてみたり。emacs-w32の場合、DIBに画像を読み込んでいるようです。
以前CreateDIBSection()では2GBの制限があるっぽい事を
知ったのですが、失敗するのは多分そのためなのじゃないか？と思ったり。
先日対応してみた --with-native-image-apiで GDI+を使用すると2GBを越える画像も大丈夫そうですが、
32768x32768のサイズだとダメでした。もしかすると幅と高さ自体に制限があるのかも知れません。
ImageMagickライブラリでは、全てメモリバッファで展開とスケーリングが行われているようです。
スケーリングされた画像を表示するのは大丈夫そうですが、オリジナルサイズで表示しようとすると
メモリが足りなくなっている感じがします(何か動いてっぽいけど結局表示できないままだったので強制終了してしまいました😓)。
8Kくらいまでの節度あるサイズなら問題無いだろうって感じです。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 36人。
CygwinのMailingListに
「[HEADSUP] Phasing out old Windows versions and 32 bit support」
って投稿があり、32bitサポートは 次にリリース予定の 3.3.x までで、
2022年にリリース予定の3.4.xでは32bitサポートは無くなる計画のようです。
我が家では、結局64bitへの移行はのびのびになっているのですが、
そろそろ本腰を入れて移行する必要がありそうです😓。
64bitだとメモリを節操なく使いすぎるのを懸念してました。
例えば 少し前に
--with-native-image-apiビルドのEmacsで画像表示テストをしていて、
過渡的に数GBのメモリを消費してしまうとか。「明らかに今は使ってないだろ？」と気づく前に
ヒープメモリが縮めば良いのですが、まぁ うまく使っていくしかないのかも知れません🙂
テレワーク。早めに終了。
東京都コロナ感染者。新規は 29人。
そういえばEmacsの master(29系)ブランチに WebPサポートが入ったようなのですが、
29系だと正式にリリースされるのは1年以上先だよなぁ？とは思ったりも。
色々な組み合わせでのビルドが考えられるので、ナイトリービルド的なものを置くのも
難しいとは思うのですが、自分でビルドをしない人はバグ修正や機能追加されたバージョンを利用できるようになるまで、
かなり時間が空く事になるのだなぁ？とは思ったりも。
Emacs-28.0.60のlisp/image-mode.elを 27.2で使うようにしてみました。
画像ファイルの表示能力が急に強まった気がします🙂
テレワーク。早めに終了。
東京都コロナ感染者。新規は 17人。ちょっと弱まっているか？
EmacsでTGA画像ファイルを表示する件。image-format-suffixes でヒントを与えれば良いのは判ったのですが、
27.2では効いてなさそうでした。という訳でlisp/image-mode.elを比較してみると、
27.2では create-image実行時に:formatを指定するコードになっていないようです。
という訳で、27.2で設定が効かないのは そういうコードだからという事みたいです。
しかしながら、28.0.60の lisp/image-mode.el を 27.2でも使用すれば
image-format-suffixesが効かない件も、imagemagick-types-inhibitにフォーマットを指定しても外部converterが使用されない件も
解消されるようです。特に、ImageMagickが有効になっていないCygwinパッケージのEmacs-27.2では
データ渡しの場合に外部converterが起動されなかったので、外部converterに依存する画像フォーマットで
リモートやアーカイブ内のファイルを表示できなかったのが表示可能になるようです🙂
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 19人。
トイレットペーパーや洗剤などの生活消耗品を1～2ヵ月に1回くらいの頻度で近所のドラッグストアで
調達するのですが、掃除用品のユニ・チャームのウェーブ
のハンディワイパー取り替えシートがここ数か月入荷されていないよなぁ？と思ったりも。
そもそも超低頻度でしか見てないにもかかわらず毎度無いってのは変だよなぁ？と思う所です。
商品自体が無くなった訳ではないようなので 生産量などの問題か？
因みに今の住まいに引っ越した時にウェーブを高頻度で使うようになりました。最初は引っ越し直後の掃除で
使い始めたのですが、舞い上げずにホコリを取れるとか、テレビのリモコンのような凹凸があるものでもちょっと撫でれば綺麗になるとか、
どれだけ汚れているかが判る(水色ですが汚れがヒドイと真っ黒になる😓)のが良いです。
またホコリは積もり始めるとあっと言う間に目に付くようになります。我が家の生活様式では
きっかり1週間を越えると急にホコリが目に付き始めます。このため、今の所に引っ越してからは
週に1回 必ず掃除をするようになりました😅。引っ越し直後の掃除では直ぐに真っ黒になっていたので1～2回の使用で
交換していたのですが、ホコリの積もる桟(さん)などの出っ張り要素を一通りウェーブで撫でる掃除ルーティンにしてからは、
すぐに交換しなくても良い感じになってます🙂
Emacsでの画像表示。ImageMagickを有効にしたビルドでデータ渡しの場合に表示できないフォーマットとして
JXRとBPGがあるのは認識していたのですが、TGAもダメだったというのに今日気づきました😓。
ただ、JXRやBPGのようにImageMagick自体も外部デコーダーコマンド実行に頼っているからダメという訳ではなく、
自力デコードできるのにダメっぽい。ややこしいな。
ファイル名渡しはOKだけどデータ渡し(リモートファイルやアーカイブ内ファイルなど)がダメなフォーマット
を調べた方が良いのかも？🤔
ImageMagick有効なビルドのEmacsでデータ渡しのTGAフォーマットを表示できない件。そもそもImageMagickでは
どうなのかを見てみたら、何が起こっているのか少し判ったような気が。
ImageMagickの displayコマンドでは convertコマンドと同じく標準入力のデータを表示する事ができます。
ただ、以下のような事になるようです。
$ cat test_image.tga | display -auto-orient display: no decode delegate for this image format `' @ error/constitute.c/ReadImage/562. #表示できず $ cat test_image.tga | display -auto-orient tga:- #これは表示できる $ cat test_image.jp2 | display -auto-orient #これも表示できる
(add-to-list 'image-format-suffixes '(image/tga "tga"))
昼過ぎ起床。寝すぎ。
東京都コロナ感染者。新規は 32人。
何気にEmacsでflyspell-modeを起動してみたり。
Typoの修正をするのに M-$ (ispell-word)で修正候補が表示されて候補に対応するキーを押すみたいな感じなのですが、
こんな面倒くさい感じだったっけ？🤔
ミニバッファで C-f だか C-n だかで選んで直すような感じだったと思ったのですが、
普段使いしなさ過ぎてて全く思い出せません😓
infoを見てやっと思い出しました。C-M-i (ispell-complete-word)により ミニバッファ上で選択候補を
ローテートして修正する方法があり、記憶にあったのはこれの事でした。あ、M-はALTキー押しです。
因みに「M-<TAB>」にも同じキーバインドが設定されているらしいのですが、
Windowsでは Windows自体のウインドウ切り替えのショートカットになっている為、
そちらにキーバインドを食われてて機能しませんが 「<ESC> <TAB>」はイケるようになっています。
そういや C-M-i は並びを M-C-i に変えると、C-iは<TAB>と同じなので、整理すると C-M-i は M-<TAB> に
読み替えられる感じになっているなぁ？と思ったり。数学チックです。
何気に --without-imagemagick でImageMagickサポート無しのEmacsをテストしていて、リモート画像ファイルをimage-modeで
外部converter経由して表示しているなぁ？ と思ったり。
以前 image-modeでの表示可不可をコードで調べたとき、データ渡しは
外部converterでは表示できないと思ったのですが読み違えていたようです。
どうやって表示しているんだ？と思ってwrapped_convertにデバッグコードを仕込んで引数を調べてみたところ
「'-auto-orient' 'JXR:-' 'png:-'」てな感じで渡っていて、標準入力読み込みを行っているようです。
てか、パイプ渡しもしていないと思っていたのですがしっかり使っていたようです。色々と修行が足りません。
ただ、一部直感と異なる動作をするような気はします。(その後27.2がバグってっぽいという事で解消)
| 専用画像LIB | ImageMagickLIB | 外部converter | |
|---|---|---|---|
| ファイル名渡し | 表示可 | 表示可 | 表示可 |
| データ渡し | 表示可 | 表示可(※1) | 表示可(※2) |
テレワーク。早めに終了。
東京都コロナ感染者。新規は 26人。
大阪の減りが弱いのは なんか変な気も。今新規感染している人の原因はちゃんと調べているんだろうか。
--with-native-image-apiビルドのEmacs-28.0.60でテスト。TIFFフォーマットもGDI+によるデコード可能対象となってるのですが、
何故か .tiff はネイティブになるのに、.tif はImageMagickになってるのに気づいたり。
--with-imagemagick と併用しているので imagemagick-types-inhibit に ImageMagickを使わないフォーマットを
指定しないとネイティブにならないのですが、設定が足りなかった模様。加えて設定の順番が影響するというのも判ったり。
最初以下のようにしてたのですが、これだと .tifはImageMagick、.tiffはネイティブになってました。
因みにGIFやJPGなども追加しないとそれらもImageMagickでのデコードになりますが、ここでは説明用にTIFに
着目した分だけを記しています。
(when (image-type-available-p 'imagemagick)
(dolist (imgtype (list 'TIFF 'TIFF64))
(add-to-list 'imagemagick-types-inhibit imgtype))
(imagemagick-register-types))
(when (image-type-available-p 'imagemagick)
(dolist (imgtype (list 'TIF 'TIFF 'TIFF64))
(add-to-list 'imagemagick-types-inhibit imgtype))
(imagemagick-register-types))
(when (image-type-available-p 'imagemagick)
(dolist (imgtype (list 'TIFF 'TIFF64 'TIF))
(add-to-list 'imagemagick-types-inhibit imgtype))
(imagemagick-register-types))
テレワーク。早めに終了。
東京都コロナ感染者。新規は 36人。
そういや 北海道、沖縄、大阪はなんか新規感染者数の減りが弱い気がします。
北海道や沖縄はこれまでも何故か新規感染者数が多いという所はあったと思うのですが、
結局理由はなんなんだ？という感じです。特に沖縄は 島国in島国 なのに封じ込められないのはなんで？
と思います。
以前試してうまくいかなかった、Emacs28.0.60に入ってる native-image-apiを
有効にしてCygwinでビルドできるように書き換えてみました。
不足しているヘッダを足すと余計な物がついてくる為、コンパイルエラーになるという感じだったので、
Cygwinの場合は必要な関数やコードだけを#ifdefブロック配下に直書きで取り込むという大分強引な対応になった感じです😓。
でも、そこよりもオリジナルの src/w32term.c 内で
/* For now, disabled by default, since this is an experimental feature. */
#if 0 && HAVE_NATIVE_IMAGE_API
if (os_subtype == OS_9X)
w32_use_native_image_api = 0;
else
w32_use_native_image_api = 1;
#else
w32_use_native_image_api = 0;
#endif
テレワーク。早めに終了。
東京都コロナ感染者。新規は 41人。
飲食店への時短要請等を25日以降解除する方向。大丈夫か？
感染対策を続けているから今の状況になっている訳で、感染源が無くなったから
大丈夫になったという訳ではないというのを分かってるよね？ と問いたくなる唐突感があります。
「イギリスでやってた感じの全開放的な実証実験をやるのだ」とでも言った方が
リスクを承知で意図してやってるのが分かるだけまだマシ。
ハロウィンを跨いだ効果を見込んでいるのかも知れませんが、
急アクセルを踏む必要も無いだろうと思うのは個人的な感想です。
もそもそと実験。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 36人。
今新規で感染するのはどういう人なのだろう？
調べ事をして終了。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 29人。
emms。何故か Playlistで キーバインド「s」による停止を行うとプレイヤープロセス(子プロセス)が残ったまま
Emacs上のプロセス管理が消滅するという状況になるようです。恐らくこれがEmacsから操作不能な子プロセスに
なってしまった状況と思います。この子プロセスが残った状態のまま親プロセスであるEmacsを終了させると、
いわゆる プロセスID=1(Cygwinではinit風の実体の無い何か)が親プロセスとなります。
さておき、キーバインドでは 関数emms-stop を実行しているようですが、この関数を M-x emms-stop
で実行するとプレイヤープロセス(子プロセス)も消えます。 同じ関数を実行しているのに動きが違うという感じ。
なんで？🤔
もう少し調べてみると kill-process という関数で 子プロセスをkill しているのですが、これが
何故か 一回の関数実行で killできない場合があるっぽい。 kill-process 関数を実行した後に delete-process と
いう関数を実行しているようですが、delete-processを実行するとEmacs上の管理インスタンスが無くなって
しまうようで、Emacsからは操作できないプロセスとなってしまうっぽい。試しに、
emms-player-simple-stop という関数で実行されるkill-process をプロセスが消えるまで何度も実行するように
してみました。
(defun emms-player-simple-stop ()
"Stop the currently playing process, if indeed there is one"
(let ((process (get-process emms-player-simple-process-name)))
(when process
(while (get-process emms-player-simple-process-name)
(kill-process process)
(sleep-for 0.1))
(delete-process process))))
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 40人。
MPlayerの最新版が1.4というのを知ったので
ビルドを試みたり。とりあえず何も指定せずにconfigerを実行してmakeを開始してみたところコンパイルエラー。
マルチバイト文字変換の関数が見つからないみたいな感じだったのですが、以下のようなパッチを当てれば
大丈夫そう。
$ diff -u stream/stream.c.orig stream/stream.c --- stream/stream.c.orig 2017-04-29 20:09:32.000000000 +0900 +++ stream/stream.c 2021-10-17 13:45:47.229301900 +0900 @@ -37,6 +37,8 @@ #include <winsock2.h> #endif +#include <winnls.h> + #include "mp_msg.h" #include "help_mp.h" #include "osdep/shmem.h"
(require 'emms-setup)
(emms-all)
(setq emms-player-list
'(emms-player-mplayer-playlist
emms-player-mplayer
))
AM中に起床。散髪予約を入れて夕方頃に出動。
東京都コロナ感染者。新規は 66人。
大分前にも思ったのですが、何故減り方は漸近線なんだろう？
増えるも減るも指数関数的なのは解るのですが、感染防止のアルゴリズム的にいつまでも
新規の感染先を渡り歩けられるのはなんでだ？とは思います。
無防備もしくは微妙に防御できていない人同士が繋がる事でしかそうはならないように思えるのですが、
1.2億人を入力にすると確率的にはあり得る関数という事なのかなぁ？
Emacs-28.0.60 上で音楽プレイヤーのemmsを使ってみたところ、再生は問題無いようですが
何故か停止がうまくできなくなる場合があるようだったり。
一応27.2で確認してみたらこちらも変になる模様。あれぇ～？
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 57人。
Emacs-28.0.60。27系以前では全角スペースを可視化するのに whitespace-mode に設定を追加
する方法がありましたが、28では whitespace-mode じゃない場合でも全角スペースは色付き
アンダーラインで表示され、半角スペースと区別が付くようになっているようです。ほぅ.....
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 62人。
そろそろ、今 新規に感染しているのはどういう原因なのだろうと思い始めたりも。
調べ事。イケそうでイケてない。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 72人。
今更ですが、gdbのrunコマンドでターゲットプログラムの引数を指定できるってのを知りました....。
多分gdbを知った時から「set args ....」しか使った事が無かったので、
20年以上のあいだ気づいていなかったという事になります。
今に始まった事では無いのですが自分の節穴ぶりに驚愕します😱
org-mode。念のため「Emacs-28.0.60 + Org-9.4.5」を確認してみたところ、
「Emacs-28.0.60 + Org-9.5」と同じようにダメだという事が分かりました。んんん？？？そっち？
ていうか原因は一体どこ？？🤔
切り分けてみたり。「(add-to-list 'org-src-lang-modes '("D" . c))」だと「#+BEGIN_SRC D」とすれば
エラー無くc-modeで色が付くのに対して、
「(add-to-list 'org-src-lang-modes '("C" . d))」だと「#+BEGIN_SRC C」でエラーを検出する事から、
d-modeに何か秘密があるのかも？と当たりを付けてみたり。起動後にload-fileでd-mode.elファイルを
再読み込みしたり試したのですが反応せず。何気に .elc を消したらどうだ？と思って削除してみたら大丈夫になりました.....
えーー？そこ？🥺 .el読み込みで「Emacs-28.0.60 + Org-9.5」でも問題無くなりました。
.elcの後方互換の問題なのか？でもload-fileで.elの再読み込みとか試したのですが...？🤔。
ともかく回避策があるという事でよしとしよう。
それにしても色々なトラップに順にハマっている気がしてなりません😓。いいけど(＜いいのか？)
そういや我が家のデスクトップPCのCPUは Core i7-7700K なので、現状ではWindows11の要求するハード要件を満たしていません。
それは良いのですが、ハード要件をチェックする「PC正常性チェックアプリ」のネーミングには違和感があります。
PCは正常だよ！ぷんすこ💨 そんだけ。
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 77人。
インフルエンザとコロナの同時流行。ここでは何度か記していますが、ワクチン以外のコロナ感染対策が
継続できていればインフルエンザは流行しないと思われます。去年とかも同時流行の可能性を主張する専門家と
呼ばれる人は居ましたが、インフルエンザにしろコロナにしろ感染の原因を考えれば、
コロナ感染対策をやってるにもかかわらずインフルエンザに感染するって事にはならないように思います。
ただ、もしインフルエンザが流行する事があれば、コロナに対する感染対策も全然できていない
(デルタ株にはコロナワクチン接種してても感染するという事を忘れているという超どんくさいレベル)
という指標にはなるかも知れません。
org-modeで先日のd-mode適用設定を再度確認しようと立ち上げたら何故かエラー。んん？？
どうやら org-src-lang-modes への追加でうまくいってたのは「Emacs-27.2 + Org-9.4.5」でした😅。
とは言え、Org-9.4.5ではうまくいくのに Org-9.5ではうまくいかないというのも納得できるハズも無く。
差分とかを少し調べてみるも原因は判らず。ぐふっ。
因みに、「Emacs-27.2 + Org-9.4.5」で先日の .emacs設定を「(require 'org)」直後くらいに移動すると
「(add-to-list 'org-src-lang-modes '("D" . d))」のように大文字のDでも
大丈夫になりました。でも「Emacs-28.0.60 + Org-9.5」ではやっぱりダメ。設定が難しすぎる🥺
もう少し確認してみると、org-mode上は「#+BEGIN_SRC D」と記すと
「Org mode fontification error in #<buffer foo.org> at XXX」のようにエラーメッセージが
表示されてコードブロックの認識も怪しい感じなのですが、気にせずHTMLにエクスポートすると
意図通りにキーワードハイライトされたコードブロックがエクスポートできているようです。
編集時のコードブロックの認識動作が変なのかなぁ？🤔
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は 49人。10月いっぱいはこれまでと変えずに感染予防の手を緩めなければ、
新規0人も視野に入っているように思えます。
ところで、今日の新規感染者数が49人って県がいくつかあるのは偶然か？
Emacs 28.0.60 + Org 9.5。またEmacs-28とは関係無いですが、いつの頃からかD言語のコードブロックのキーワードハイライティングが
行われなくなっているなぁ？と思ったり。org-mode中でもハイライトされない為か、HTMLにエクスポートしても
色が付きません。「#+BEGIN_SRC D」を「#+BEGIN_SRC C」に変えた瞬間にそれっぽくキーワードに色が付く
(C言語解釈で色が付いている訳ですが)ので、色が付かないといった訳では無さそうです。
言語モードである d-modeが使えるようになっていればそれを利用して色が付くものだと思っていたのですが違うのか？🤔
もう少し調べてみたところ、org-src-lang-modes ってリスト変数に コードブロックの識別子に対応する
メジャーモードを指定できるっぽかったのと、D言語は指定が無いようだったので足してみたところ、
何やら識別子がうまく認識されなくなったり。しかし、試しに以下のように小文字にしてみたらイケました。
=====.emacs設定=====
(add-to-list 'org-src-lang-modes '("d" . d)) ;;("D" . d)だとダメ
=====org文書内ブロック識別子は新たに"d"が認識されるようになる=====
#+BEGIN_SRC d
import std.stdio;
import std.string;
void main()
{
writef("Hello D world\n") ;
}
#+END_SRC
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は 60人。
Emacs 28.0.60でテストをしていて、そういや28より前から org-mode 内でgnuplotを使って
グラフを描かせるブロックにおいて、初回のgnuplot起動でエラーするという現象があるなぁ？
と思って原因を調べてみる事に。因みに 普段使いではorg-modeからgnuplotを使う事は皆無な事もあって、
初回起動でエラーするけどもう一度やれば動くのでほったらかしにしてました😓
org-modeからは gnuplot-modeを使う仕組みになっているのですが そこで生じるエラーという感じ。
因みにバージョンは表記上 0.6.0ですが、これは Version 6.0の事みたい。
さておき、一つは以前 Anthyの27系対応でハマった
obsolete になっていた 関数 process-kill-without-query が Emacs-27で削除執行されて関数自体が無くなってエラーしている件でした。
ちょっと直してここは通過するようになったのですが、その次の関門に kill-buffer の問い合わせが行われる件があり、
これをどうにもうまく回避できませんでした。諦めて新しいのがあるか調べたら
「Gnuplot for Emacs」で
更新されているのを知り、今年になってVersion 8.0というのが出ていて
(因みに 7.0は2012年10月にリリース、6.0は2011年12月にリリース)、
大幅に変更されているようでした。という訳で8.0を入れてみたらあっさり解決。ありがたい事です😄
そういえば Emacs-28から --with-native-image-api というconfigureオプションがあって、
Windowsの場合はJPEGやPNGなどのロードを GDI+ を使って行うようになるそうな。
Cygwinで特にオプション指定しなければ 有効にならないようだったのですが、
--with-native-image-apiを付けても有効にならなかったので、そうなの？と思って少し調べてみたり。
configure.acを調べてみたら Cygwinか否かで条件が分かれているようで、Cygwinの場合は
--with-native-image-apiには反応しないようになってます。コメントに
dnl FIXME: This should probably be supported for Cygwin/w32 as
dnl well, but the Cygwin build needs to link against -lgdiplus
AM中に起床。
東京都コロナ感染者。新規は 82人。
9月末の連休の状況を踏まえても減少の傾向が続いている所を見ると、今の感染防止による抑止力
の方が感染拡大力よりも大きいのだろうと思われます。8月から9月のピークからの減少は「感染したら死ぬ」
ってのが徐々に意識されて感染防御力が全体的に上がった事によるものだろうと考えます。
以降の減少についてはワクチン接種の普及が大きいのかも知れません。9月末には日本国民の60% 近い割合で
2回目接種完了していた(10月9日時点では 63%) 所を見ると、無視できない要素だと考えます。
恐らく、やってるつもりで微妙にできていない感染キャリア候補の人がワクチン接種により感染キャリアにはなり得なくなった
という感じなんじゃなかろうかと考えます。
アルゴリズム的には 感染力よりも抑止力が上回っていれば拡大はしないので、行動制限は徐々に緩和
しても問題無いと思われます。ワクチンによる緩衝は強そうなので、密を避けたり換気を行ったりは
継続するにしても、多少動いた所で直ぐに拡大に転じる感じにはならないかも知れません。
てか、今の時点はその状況なのだろうと推測します。
デルタ株は今あるワクチンを接種していても感染するとされているので、もし拡大した場合は感染対策を怠りすぎ(行動を戻し過ぎ)
という事なのだろうと思います。イギリスとかは今だに30000人/日のオーダーで新規感染しているようなのですが、
単純に戻しすぎなんじゃなかろうか？とは思います。
ここでは以前から何度か記していますが、
ロックダウンしているのに感染拡大していたイギリスやアメリカの方が、
対策に対する結果としては理解できません。今の日本の新規感染者数の急激な減少はむしろ判りやすい結果に思えます。
Emacs 28.0.60。挙動が変わっている件。
先日の select-window-functions ていうフックは、src/window.c 内の関数 select_window()
が呼び出し元になるのですが、この select_window() が(Emacsの)ウインドウのフォーカスが
変更された時しか実行されなくなっている模様。27.2ではこの関数が定期的に実行される
感じになっていたので、run-with-timerを使ったような動きをしていました。
デバッガを使って 27.2で select_window() の元の呼び出しをバックトレースで調べてみた
のですが、キーボードイベントが元になっているようでした。しかし、28.0.60との差分が
有り過ぎて、ちょっと戻したくらいでは反応しなさそうで、戻し始めると27.2と同じになって
しまいそうな勢いだったので、「うん、28はこういうものなんだ」と思う事にして28向けに改めて
対応を考える事にしました。
直接の原因は w32-ime内の関数 w32-ime-sync-state が定期的に実行されなくなったのが
全てのようなので、ELISPのタイマー機能である run-with-timer を使って
定期実行をするという単純な方法を採用してみました。少し使ってみた範囲では良好に
動作している気がします。むしろ専用のフックを使わなくて良くなった分、
全てELISPの制御下になった感じかも。ひとまずこれでという感じ。
28.0.60で term+ を使ってみたのですが、起動して使うのは特に問題無いようですが、
終了する時にエラーが出て、バッファリストやkill-bufferコマンドを使っても削除できない
状態になりました。28.0.60では lisp/buff-menu.el 内で宣言されているカスタム変数 Buffer-menu-name-width に
関数シンボルが設定されているですが、これが数値じゃないといってエラーしていました。
27.2でも同じ変数がありますが単純に 19という値が設定されているようでした。
term+で使用しているタブ機能のELISP tab-group.el の中で変数 Buffer-menu-name-widthを
参照しているのですが、tab-group.elでは数値という前提で使用しているのがエラーの直接の原因
のようです。という訳で、ワークアラウンドとしては .emacsとかで 27.2のようにカスタム変数
Buffer-menu-name-width に数値を指定するという方法が簡単そうです。根本的には tab-group.el で
変数 Buffer-menu-name-width を参照している箇所について、28.0.60の lisp/buff-menu.el の中で
行っているように、
(setq name-width (if (functionp Buffer-menu-name-width)
(funcall Buffer-menu-name-width (mapcar #'car entries))
Buffer-menu-name-width))
<style>
#content { max-width: 60em; margin: auto; }
:
テレワーク。早めに終了。
東京都コロナ感染者。新規は 138人。
Emacs 28.0.60。なんか挙動が変わってて、W32-IMEのインジケーター表示がうまく更新されなくなっている模様😭
少し調べてみたところ、 select-window-functions ていうW32_IME専用に追加しているフックの反応が変わっているような？
27.2ではウインドウの選択中に登録したフック関数が高頻度で何度も実行される感じでしたが、
28.0ではウインドウを切り替えた時に1回だけ実行される感じになっている模様。ふむぅ🤔
テレワーク。早めに終了。
東京都コロナ感染者。新規は 143人。
夜に急に揺れてビビった。
すぎやまこういち氏死去。ドラクエXI発表会の時も、
去年の文化功労者に選ばれた時も、毎度随分なお爺ちゃん
だと記してましたが、この時はやってくるよなぁと改めて思ったりも。90歳ですか。
Emacs 28.0.60。そういや起動時のスプラッシュ画面で、ロゴ画像がフレーム(ウインドウ)の幅とは関係無い
位置でセンタリングされるようになったなぁ？と思ったり。最初何かしらフレームサイズ設定とかに
問題があるのか？と思ったのですが、gitログを調べてみると lisp/startup.el 内の 関数 fancy-splash-head
が、画像ロゴの下のテキストの幅(80って固定幅になってるっぽいですが？)に合わせてセンタリングされるように
意図的に変更された模様。う～ん、これはどうなんだろう？🤔
インプットメソッドの切り替えをテストしていて、そういや view-hello-file で追加された言語
に連動してインプットメソッドも増えていたりするのかしら？と思って調べてみたり。
以下のような感じになってっぽい。
| 文字/言語 | Hello (27.2→28.0) |
IM(27.2) | IM(28.0) |
|---|---|---|---|
| Cham | 追加 | 無し | 有り |
| Javanese | 変更 | 無し | 無し |
| Egyptian Hieroglyphs | 追加 | 無し | 無し |
| Belarusian | 追加 | 有り | 有り |
| Lakota | 追加 | 無し | 有り |
テレワーク。早めに終了。
東京都コロナ感染者。新規は 149人。
先日 SAI2の新しいのが来ていました。お疲れ様です。バグ修正がメインという感じでしょうか。
Emacs 28.0.60。define-minor-mode に由来するワーニングを修正してみたり。機械的に修正するだけなのですが、
沢山あるとやっぱり面倒臭いです😅。一回やれば終わりという事で対応してワーニングの撲滅に成功。
view-hello-file 向けにフォント設定追加。
「Cham」と「Javanese」は過去にインストールしたフォントなどでイケました。
「Egyptian Hieroglyphs」は
NewGardinerという
フォントを知ったので入れてみました。.emacsでの設定は以下のような感じ。
(set-fontset-font t 'cham (font-spec :family "Code2003")) (set-fontset-font t 'javanese (font-spec :family "Javanese Text")) (set-fontset-font t 'egyptian (font-spec :family "NewGardiner"))
テレワーク。早めに終了。
東京都コロナ感染者。新規は 144人。
emacs-28のブランチからの28.0.60 (の今日時点での最新)をgitリポジトリからcloneしてビルドしてみたり。ひとまずネイティブコンパイルは無し。
なのですが、運悪く ぶっ壊れているようでコンパイルエラーになったり😓。しかたないのでちょっと直して素のままビルド。
ひとまず実行バイナリはできたのですが、SVGがレンダリングできないせいでスタートアップのロゴが
表示できないようだったり😓。configureオプションを足しても有効にならなくて、
そういやCygwinの emacs-w32は SVGが有効になっていないのを知った
のですが、オプションを足しても有効にならないからだとは思いませんでした。
という訳でIMEパッチと一緒にSVGに関する変更も含めて適用。ひとまずビルドはできて、
スタートアップのロゴも表示され、IMEもそれとなく使えているっぽい。
色々直っているのもあればそのままのもありそう。変になっている点もありそう。
何やら「Warning: (lambda nil \.\.\.) quoted with ' rather than with #'」ってワーニングが
大量に出るようになったのがちょっとウザい。
「'(lambda () ...」て書いてたのを「#'(lambda () ...」て直す必要があるみたい。
.emacs内でキーバインドに無名関数で機能割り当てしてる所は全滅でした😓。
「Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode'」って
ワーニングも大量に出ているのですが、これはどうやって直せば良いのかよく判らず。
少し検索した感じ
こちらのような感じ
で直せばイケるらしい。
view-hello-file もいくつか言語が足されていて、
我が家の設定では「Cham」,「Egyptian Hieroglyphs」がフォント無しで表示できませんでした。
また、「Javanese」は27.2まではただのASCIIだったのがフォント無しで表示できなくなってました。
「Belarusian」,「Lakota」は追加されたのですが今の設定で表示できているようです。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 87人。月曜だけどね。今週の全国的な傾向で今後の方向は判るのかも。
光回線修理。朝10時前にNTTから連絡があり、建屋の外の様子を確認してみるとの事でした。
通話が終わって10分後くらいに、先日以来消灯していた「光回線」のインジケーターが点灯していたり。
直ぐに修理を始めた感じなのかしら？と、しばらく1Mbps回線で耐えながら(いや、耐えられませんでしたが)
インジケーターの様子を見ていたのですが切れる事も無かったので試しに繋いでみたところ回復しているようでした。
午後になって修理完了の連絡があったのですが、連絡が来るまでの間は普通に使えてた感じです。
実質直ぐに復旧してたところを見ると、コネクタが抜けかけてたレベルの障害だったのかも。
ケーブル張り直しとかにならなかったのは不幸中の幸いだったかも😓。
AM中に起床。
東京都コロナ感染者。新規は 161人。
朝から何故かネットが繋がらず、ルーターをよく見てみると「光回線」のインジケーターが消えていたり。
回線が切れているようで光電話も不通。ルーターを再起動しても復帰せず。終わった。
ひとまずNTTのいわゆる116(携帯は0120-116-000;参考)で問い合わせてみたら、
現在契約上はNTTとの契約にはなっていないと言われて、
そういや回線契約をプロバイダ管理で一括にすると安くなるとかなんとかで変えたな？というのを
思い出し。で、連絡先を契約書から探すもコロナ影響で土日は受け付けていないとか。
故障受付の連絡先じゃかったのでどうにか探す為に、建屋サービスであるケーブルTV経由の1Mbpsインターネット回線を
使ってどうにかネットアクセスを行って故障受付の連絡先を探し当てたり。
診断の結果、ルーターよりも外側での問題だろうという事で、NTTに取り次ぐという流れになる模様。
なんだ、物理的なインフラの話はNTTじゃないとダメなのか。という事で折り返し連絡待ち。
しかし連絡無く。何故か詰まってて今日中はダメかもと言われてたのですが本当にダメとは。
それにしても使う事は無いだろうと思っていたケーブルTV回線を使う事になろうとは。
本当に よもやよもやだ。ただ、久しぶりに使うせいか(160Mbps試用期間の時以来)、
最初うまく繋がらなくて本当の手詰まりになりかけました😓。あと、ルーター機能が無い？のか
PC直結でしか繋がらない感じ。
ひとまずまとめ終わり。Emacsの雑記を更新してみました。御参考まで。
そういえば、先日 Emacs-28のgitブランチが生成されたようですが、MailingListの
アナウンスの中で
「I've cut the emacs-28 branch」と記されていたのですが、これってどういう意味なんだ？と思ったりも。
確かに日本語で「ブランチを切る」って言い方をする人がいますが、大体「ブランチ(分岐)を生成する」の
意味で使っているように思っていて、「切る」って使うのは日本語だからだと思ってました。
昼頃起床。寝すぎ。
東京都コロナ感染者。新規は 196人。
これまでのEmacsやらELISPやらいじったのをまとめたり。色々ありすぎてまとめ終わらず。
テレワーク。早めに終了。
東京都コロナ感染者。新規は 200人。
Cygwin64の動作確認をしていて、以前 Cygwin32で
ハマった「Cygwinネイティブじゃない実行ファイルの並列実行で終了コードが0にならない」件は
Cygwin64でも起こるらしい。スナップショットビルドされた dllに差し替えて対応。
現在テスト版がリリースされている 3.3.0で直る予定みたいですが 流石に正式修正リリース遅くね？
とは思ったりも。
Emacsのgitログを眺めていたのですが emacs-28のリリースブランチが生成されたみたい。
次は28.0.60にしたみたいなので、28系のソースアーカイブのリリースは28.0.60からになるのかな？と思ったり。