C の比較演算の結果で，true の場合は 1 で false の場合は 0 っていうのが常識的な 挙動のような気がするけど，未規定とかじゃなくてちゃんと決まっているのか， 前から気になっていたのでちゃんと調べた。 素直に検索しても出なかったけど，ちゃんと規格（に近いもの）を見に行ったら 簡単に書いてあるのが見つかって，どうやら true が 1 で false が 0 になるってのは 決まってるっぽい。 つまり，以下のコードは環境に依存せずに 2 を出力する。 #include <stdio.h> int main(void) { int num = (0 == 0) + (0 == 0); printf ("%d\n", num); return 0; } あと，結果の型は int。 参考 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

なんじゃこりゃ %:include <stdio.h> int main(void) <% char str<::> = "Hello, world!"; printf("%s\n", str); return 0; %> これが $ gcc main.c コンパイルすると $ ./a.out Hello, world 動いてしまう。 <:, :>, <%, %>, %:, %:%: の6つのトークンは， [, ], {, }, #, ## と同じように解釈されるらしい。 なんじゃそりゃ。 参照 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

いろんなワードで pacman -Ss してみて眺めていたら，termtosvg というやつを 見つけたので試してみた。 結論：すごい。ただ alternative screen buffer ができないみたい。 ソース見たら CSS で表示位置をずらしてアニメーションしているように見せているっぽい？ よくわからぬ。

でその PR が通ったので，さっき日本語に切り替えた。

という議論が ここ にあったけど（2007 年……古い……！），malloc(3) で取ってきたメモリを delete（もしくは delete[]）に渡してはいけないとか，new で取ってきた メモリを free(3) に渡してはいけないのに malloc(3) を読んだり new したり しても問題ないってのはなんか奇妙な話な気がしてきた。 （普通に C++ 書いていれば malloc には用がないけど）。 なぜかというと，どちらのメモリも malloc(3) が管理していないと， 同じ領域が別の用途で使われてしまうということになるので。 で，new で取ってきたのも malloc が管理しているんだったら， delete しても free(3) に渡されるだけだから， デストラクタとかがなければ問題にならない気がする。 と思って gdb でアタッチして試したら実際に malloc が呼ばれてるっぽい。 まあ仕様上未定義ってだけだよね。

しかも ArchLinux でやってる。エモい。 https://github.com/nikp123/ntfs-rootfs/wiki 正気か？POSIX のパーミッションをサポートしてないので無理な気がしたけど 非公式のサポートがあるらしい。誰得なんだろ。 安定しているの？ シャットダウンできないことを除けばとても安定している。 :thinking_face: パーミッション周りをゴニョゴニョやってるせいでパフォーマンスは悪いらしい。

GNOME 端末，というか GNOME 端末が使っている vte に Sixel が入ってほしいな， と思っていたけど，これ を見た感じ入る日は来なさそうだな，と思った。 この issue は重複する issue を上げるな，というところから， sixel のプロトコルがレガシーでパレットベースで，view/model を分けるのが困難 という説明までしている。 bugzilla の方もパッチはあるけどそのパッチが入る雰囲気はゼロだった。 2021/8/10 追記 そういえばこれ入ってました。

https://lists.gnu.org/archive/html/coreutils/2017-05/msg00000.html こんな変なものも割と簡単に受け入れられるんだな，と思った。 で，ここにパッチとかも入ってるメール。 https://lists.gnu.org/archive/html/coreutils/2017-08/msg00038.html

Minecraft で読み込まれるチャンクの半径は 3–16 の間で選べるのだそうだ。 ということは，5 チャンク飛ばして更新されているか確認していけば 3 チャンクだったとしても どこかのチャンクにはぶつかるということだ。 というわけで，1 チャンク見て，間の 5 チャンクは更新されているかの確認もせずに 飛ばして，更新されていたら間のチャンクがアップデートされているか確認する ということにすると，何も更新がない場合の生成がかなり速くなった。 やっぱりやることを減らすと簡単にかなり速くなる。

camel case を snake case で表示してくれるやつ。 僕は camel case より snake case や chain case の方が好きなので， ………と思ったけど表示とデータが違うって実際に書くときに使える訳ないじゃん。 そういや C# で推奨されてるメソッド名を大文字で始めるってやつ好きくない。。。。。（言葉がおかしい） (setq glasses-mode-uncapitalize-p t) ってしとくと，アンダースコア直後のアルファベットが小文字に変換されて表示される。 まあ実用性はないです。 実用性ないといえば，M-x zone とかけっこう好き。特に drip 系のエフェクトが秀逸。 という訳で，glasses-mode は好きじゃないスタイルのソースコードを眺めるときに便利だよ， という話でした。（ほんまか）