Notices by naskya::dev (dev@post.naskya.net), page 2

私の今使っているバージョンには入ってなかったけど nextest の対応もそろそろ入るみたいだ
youtrack.jetbrains.com/issue/RUST-12459/Support-cargo-nextest-test-runner#focus=Comments-27-13414847.0-0

気まぐれで RustRover を入れて使ってみているけど、これいいな……
OSS ではないので使っていくかは分からないけど

pacman -Sy は危険だから使わないようにしているけど、pacman -Syu で更新に失敗したときも同じ状態になっちゃうの勘弁してほしい

また GitHub にスパムが

C 言語書くと狂いそうになるんだけど人間はよくこれで GUI ライブラリだの OS だの作ったな

C 言語の仕様について全然知らないけど、(void*)n は n が定数式で 0 な場合はヌルポインタになることが保証されて、n が実行時に与えられたりする場合には値が 0 だったとしてもヌルポインタになるとは限らないっけ？
記憶違いで適当喋ってるかも

🇬🇧 US
🇩🇪 uns ❌️
🇪🇸 a nosotros ❌️
🇫🇷 nous ❌️
🇮🇹 noi ❌️
🇯🇵 私たち ❌️
🇰🇷 미국 ✅️
🇳🇱 ons ❌️
🇨🇳 美国 ✅️
www.minisforum.com/products/minisforum-um890-pro

#i18nFails

プログラムのソースコード中の識別子で、to や
for の意味で 2 や 4 を使うのにはだいぶ抵抗がある
パッケージの名前（例: wasm2wat）とかならいいけど

C 言語を書くのはもはや縛りプレイ的な楽しさがある

また GitHub にスパムが

かなり一般的によくある問題だと思うから誰かが何か良い方法を考えていてもおかしくはないが、果たして

一つの大きなファイルを複数の小さいファイルに分割しつつ、分割された各部分のコードのメタ情報を引き継ぐ（例えば git blame で元の著者やコミットメッセージを表示する）ことって可能？
git blame --ignore-revs すればファイルを分割した人を誤って著者と認識することはなくなるけど、コードの移動を追跡することはできないよね？

git mv を hunk 単位で行いたい

GitHub の Markdown text の入力欄は信用できないから書くのは手元にして最後にコピーして投稿した方がいい（入力欄にそのまま書いていたら、気づいたら装飾が全部消えててめちゃくちゃ萎えた）

配信する宛先サーバーごとに投稿の内容を変えるやつ、あれ画像でやったら伸びるよ

:ablob_jitabata:

おいアカウント間違えたが

GNU Make に特有の機能を使っているなら GNUMakefile と命名するべきだし、そうでないなら Makefile と命名するべき

Docker でしか動かないコンテナイメージは Docker image だけどそうでないのなら container image や OCI image と呼ぶべきだし、Docker に特有の機能を使っているなら Dockerfile と命名すべきだけどそうでないのなら Containerfile にするべきだし、docker-compose.yaml は compose.yaml に改名するべき

std::cout << "Hello, world!"（キモすぎる演算）