コグノスケ

Docker のお掃除コマンド

Docker を使っていると要らなくなったイメージ、コンテナ、ビルドキャッシュがたまってきて、/var ディレクトリ以下が肥大化していることがあります。いつも忘れてしまうお掃除用のコマンドをメモしておきます。

### 終了している container の削除

$ docker container prune

### 確認

$ docker container ls -a


### タグもなく使われていない image の削除

$ docker image prune

### 確認

$ docker image ls -a


### build cache の削除

$ docker builder prune

### 確認

$ docker builder ls

Docker がディスク容量をどの程度使用しているのかについては system df が便利（docker system df のマニュアル）です。

$ docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          1         1         14.26GB   0B (0%)
Containers      2         1         0B        0B
Local Volumes   0         0         0B        0B
Build Cache     17        0         0B        0B

昔はコマンドの名前に一貫性がなかった記憶がありますが、今は xxx ls とすれば大抵の場合は一覧が出るため統一感があります。私のようなライトユーザーがやりたいと思う程度の機能は、大抵既に存在しており良くできていてありがたいです。

誕生日

ついに 40歳の大台（？）に乗りました。

いわゆる老害というやつにならないように気をつけようと思っていますが、そもそも身近に若い人がいません。これは良いことなのか悪いことなのか？？

今年のコロナはどうなるやら

COVID-19 の感染者が増えたとき「第○波」と名付けられていたのは記憶に新しいと思います。大体のピーク時期は下記のようになっていました。（詳細は厚生労働省や NHK のデータをご覧ください）。ざっと 4〜6ヶ月に 1度に（= 年 2〜3回）流行しており、今後も収束しなさそうですね。

• 第 1波: 2020年 5月ごろ
• 第 2波: 2020年 9月ごろ
• 第 3波: 2021年 2月ごろ
• 第 4波: 2021年 6月ごろ
• 第 5波: 2021年 9月ごろ
• 第 6波: 2022年 3月ごろ
• 第 7波: 2022年 9月ごろ
• 第 8波: 2023年 1月ごろ

全数把握は 2022年の 9月くらいで終わり、今後はインフルエンザと同じ扱いになっていくのでしょうか？COVID-19 が今後どうなるか素人の私にはわかりませんが、災禍ないことを祈るばかりです。

ニューノーマル、ウィズコロナ

仕事のスタイルも大きく変わりました。勤務先では 2020年の春くらいからリモートワークに切り替わり、現在も続いています。当初は、リモートワークなんて余裕余裕〜オフィスに出社しなくて良いなんてラッキー！満員の通勤電車滅びろ、くらいに思っていました。リモートワーク 2年やってみて、考えは変わらないもののいくつか気づきもありました。

すぐに気づいたのは「通勤のため家の外に出かける」が意外と自分にとって大事だったことです。頭のモード？気持ち？の切り替えの役目を果たしていたらしく、リモートワークのときは気乗りしない日が増えました。

この話をすると、朝でも昼でも散歩に行けば？と言われますけど、そうじゃないんですね。「自主的」に外に行けるなら、やる気も自主的に出してます。家の外に出る「強制力」と「家の外に出かけることによるスイッチ効果」のコンビが大事だったみたいです。なので、今はたまに用事を作って会社に行く日を作っています。もちろん満員の通勤電車は要らないので滅びて OK なくなってどうぞ。

もうひとつ気づいたのは「社員がオフィスに集まっている状態」で暗黙のうちに得られる情報量の多さです。オフィスにみんなが居ると遠くの雑談が聞こえてきたり、話しかけなくても姿を見れば「忙しそうだ」とか「悩んでいる？」とか情報を得ることができました。リモートワークはそのような暗黙の視覚、聴覚情報が一切ありません。積極的に話しかけない限り、誰が何をしているのかわかりません。

この問題の解決方法はいくつかトライしてみましたが、あまりうまくいっていないように感じています。

定期的な雑談会議

雑談のために会議参加という行為が大げさ？面倒？あまり参加者がおらず過疎化しました。

繋ぎっぱなし＆出入り自由の会議部屋

能動的に入ってくれる特定の人しか来ませんでした。音がして気が散るという意見もありました。深堀していませんがヘッドフォンだから？でしょうか……？

カメラ ON を心がける

（自分の試みではないですが）今もあまりカメラ ON にする人はいません。カメラ ON は背景に自分の家の部屋が映るのが気になるという意見もあり、心理的に抵抗が大きい（？）ようです。

バーチャルオフィスサービス

出入り自由の会議部屋と似た状態になりつつあります。

社員がオフィスに集まっていたときは、何もアクションしない人にも受動的に情報が入ってきましたが、リモートワークだとなかなかそうはいきません。アクションする人としない人のコミュニケーション機会の差が開いてしまいます。

いやいや、オフィスを無理に再現しようとするから破綻が生じるのだ、潔く諦めチャットなどの文字ベースコミュニケーションをメインにせよ、という割り切りもあります。しかしそれも万能ではなく、文字ベースのコミュニケーションが明らかに苦手な人は放置なのか？どうケアするか？といった新たな問題が生じます。

今は各人、各企業の試行錯誤が続いているのだろうと思います、私は今の所これ！という解がありません。そのうち見つかるんですかねえ。

RISC-V と libstdc++ と int128

目次: RISC-V - まとめリンク

完全に自分用メモです。自分で libc を改造しない限りこのエラーに引っかかることはないでしょう。

前置き

世の中に C ライブラリの実装はいくつかありますが、musl libc というライブラリがあります。MIT ライセンスで商用利用等の自由度が高く、最近ですと AWS のコンテナイメージで有名になった Alpine Linux の標準 C ライブラリです。Rust のスタティックリンクにも使われていた気がします。

そんな musl libc ですが、1.1.23 から RISC-V 64bit に対応しました。しかし RISC-V 32bit は Open Future Goals という位置に置かれ（musl libc の公式 Wiki の Roadmap）、しばらく実装される見込みがありません。

GNU libc ならば RISC-V 32bit に対応していますが、ライセンスの特徴（GPL/LGPL を嫌がる界隈にはお勧めしづらい）とメモリ使用量が多い傾向があります。組み込み向けも狙っているので、GNU libc 一本だとちょっと厳しい印象です。印象だけじゃなくてちゃんと評価した方が良い？……おっしゃる通りですね。

このような事情で musl libc の RISC-V 32bit ポーティングにトライしています。

やったこと

基本的に musl libc は 32bit/64bit で完全に実装を分ける（例: arch/arm, arch/aarch64）設計思想のようです。設計思想に従えば既に存在する arch/riscv64 の横に arch/riscv32 を新規に追加するのが素直でしょう。

しかし RISC-V のツールチェーンは multilib という 64/32bit をひとまとめにしたツールチェーンを使えるので、musl の設計思想と合いません。64bit 専用と 32bit 専用のツールチェーンに分けても良いですが、すると GNU libc と合わなくなってしまい困りました。

おそらく musl libc 的には邪道ですが、RISC-V 64bit の実装に「32bit だったらこうして」という条件を追記することにします。

ハマったこと

やっと本題です、前置きが長い！RISC-V 32bit 用の移植をミスると、GCC のビルド（正確に言うと libstdc++ のビルド）で下記のようなエラーが出ます。

In file included from gcc/libstdc++-v3/src/c++17/floating_from_chars.cc:78:
gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h: In function ‘{anonymous}::fast_float::value128 {anonymous}::fast_float::full_multiplication(uint64_t, uint64_t)’:
gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h:281:3: error: ‘__uint128_t’ was not declared in this scope; did you mean ‘__int128__’?
  281 |   __uint128_t r = ((__uint128_t)a) * b;
      |   ^~~~~~~~~~~
      |   __int128__

直接の原因は GCC の挙動の差です。RISC-V 64bit だと __uint128_t を定義しますが、RISC-V 32bit だと __uint128_t を定義しません（使用すると未定義型エラーになります）。しかしなぜ __uint128_t を使うコードが有効になるのか、一見しても原因がわかりません。

調べてみるとエラーがドミノのように連鎖して起きていました。ビルドエラーを起こしているソースコードから眺めていきましょう。

// gcc/libstdc++-v3/src/c++17/floating_from_chars.cc

#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64 \
    && __SIZE_WIDTH__ >= 32
# define USE_LIB_FAST_FLOAT 1
# if __LDBL_MANT_DIG__ == __DBL_MANT_DIG__
// No need to use strtold.
#  undef USE_STRTOD_FOR_FROM_CHARS
# endif
#endif

#if USE_LIB_FAST_FLOAT    //★★RISC-V 64/32bit どちらでも有効になる★★
# define FASTFLOAT_DEBUG_ASSERT __glibcxx_assert
namespace
{
# include "fast_float/fast_float.h"    //★★エラーを起こすコードを含んだヘッダ★★
} // anon namespace
#endif

ビルドエラーを起こす fast_float.h の include が原因？と思いましたが、64bit/32bit いずれの場合も include する条件が成立し、おかしなことは起きていないようです。原因はヘッダの内部でしょう。

// gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h

...

  // Need to check incrementally, since SIZE_MAX is a size_t, avoid overflow.
  // We can never tell the register width, but the SIZE_MAX is a good approximation.
  // UINTPTR_MAX and INTPTR_MAX are optional, so avoid them for max portability.
  #if SIZE_MAX == 0xffff
    #error Unknown platform (16-bit, unsupported)
  #elif SIZE_MAX == 0xffffffff
    #define FASTFLOAT_32BIT    //★★こちらになるはずでは？？★★
  #elif SIZE_MAX == 0xffffffffffffffff
    #define FASTFLOAT_64BIT    //★★こちらが選択されるのはなぜ？★★
  #else
    #error Unknown platform (not 32-bit, not 64-bit?)
  #endif
#endif

...

// compute 64-bit a*b
fastfloat_really_inline value128 full_multiplication(uint64_t a,
                                                     uint64_t b) {
  value128 answer;
#ifdef _M_ARM64
  // ARM64 has native support for 64-bit multiplications, no need to emulate
  answer.high = __umulh(a, b);
  answer.low = a * b;
#elif defined(FASTFLOAT_32BIT) || (defined(_WIN64) && !defined(__clang__))
  answer.low = _umul128(a, b, &answer.high); // _umul128 not available on ARM64
#elif defined(FASTFLOAT_64BIT)
  __uint128_t r = ((__uint128_t)a) * b;    //★★ビルドエラー発生個所★★
  answer.low = uint64_t(r);
  answer.high = uint64_t(r >> 64);
#else
  #error Not implemented
#endif
  return answer;
}

RISC-V 32bit 向けなのに FASTFLOAT_64BIT が定義されたとき、__uint128_t 型が使われるコードがビルドされてエラーになります。ヘッダの上の方を見ると SIZE_MAX に依存しているようで、SIZE_MAX が怪しいです。

// musl/arch/riscv64/bits/stdint.h

typedef int32_t int_fast16_t;
typedef int32_t int_fast32_t;
typedef uint32_t uint_fast16_t;
typedef uint32_t uint_fast32_t;

#define INT_FAST16_MIN  INT32_MIN
#define INT_FAST32_MIN  INT32_MIN

#define INT_FAST16_MAX  INT32_MAX
#define INT_FAST32_MAX  INT32_MAX

#define UINT_FAST16_MAX UINT32_MAX
#define UINT_FAST32_MAX UINT32_MAX

#define INTPTR_MIN      INT64_MIN
#define INTPTR_MAX      INT64_MAX
#define UINTPTR_MAX     UINT64_MAX
#define PTRDIFF_MIN     INT64_MIN
#define PTRDIFF_MAX     INT64_MAX
#define SIZE_MAX        UINT64_MAX    //★★原因★★

私の移植が適当過ぎて SIZE_MAX の値が 64bit 向けのままになっていたことが原因でした。先述したように musl libc 的には邪道ではありますが、32bit 向けの分岐を追加します。

#if __riscv_xlen == 64
#define INTPTR_MIN      INT64_MIN
#define INTPTR_MAX      INT64_MAX
#define UINTPTR_MAX     UINT64_MAX
#define PTRDIFF_MIN     INT64_MIN
#define PTRDIFF_MAX     INT64_MAX
#define SIZE_MAX        UINT64_MAX
#elif __riscv_xlen == 32
#define INTPTR_MIN      INT32_MIN
#define INTPTR_MAX      INT32_MAX
#define UINTPTR_MAX     UINT32_MAX
#define PTRDIFF_MIN     INT32_MIN
#define PTRDIFF_MAX     INT32_MAX
#define SIZE_MAX        UINT32_MAX
#endif

分かってしまえば簡単な話ですが、エラーメッセージからこの原因を推測するのはちょっと難しいですね……。

JTSA Unlimited 練習記録 2023

目次: 射的 - まとめリンク

スピードシューティングを始めてから 10か月です。今日は、第一回目の公式記録会に参加したのと、5月には公式大会（アンリミティッド - 一般社団法人日本トイガン射撃協会 JTSA）があります。今までの練習会のタイムをまとめておこうかと思います。

以前と変わらず、基本的に練習は週 1回のみです。たまに練習以外のシューティング系イベントにも行きますが、記録を見る限りタイム上達とは関係なさそうです。

今回の Unlimited の個人目標は合計 80秒を切ること、です。特にこの数字に意味はありませんが、自分の実力の壁がこの辺りにあるのと、1ラウンド 4秒 → 1ステージ 16秒 → 合計タイムが 80秒ちょうどになるので、暗算でもわかりやすいのです。

JTSA Unlimited 練習会の記録

記録を見ると当初は順調に早くなり 80秒を切るかと思ったら、ここ最近 1〜2か月は全然ダメです。ベストタイムは 2/19 の 80.7秒でした。

日付の * は別のエアガン（グロック 17 Gen.4）を使った記録ですが、特に早くも遅くもなりませんでした。道具のせいにするな、腕が悪いんだろって？はい、その通りですね……。

タイムが上下してしまう原因は明らかでして、各ステージのベストスコアとワーストスコアのブレが激しすぎるためです。ベストスコアが偶然重なれば合計 80秒台前半、ワーストスコアが重れば合計 90秒台です。的を外さないよう、ステージにあったリズムで撃つ、というシューティングの基本ができていない証でしょう。精進あるのみです。

いつか週 1という練習頻度の限界が来る気はしますが、まだ遠そうな気配です。あと 1か月、怪我しない程度にボチボチやっていこうかなと思います。

免許の更新

今年は免許の更新の年です。もう 5年も経ったんですね。早いね〜。

大阪に住んでいた時は最寄りの警察署で更新していましたが、今の住居からは鮫洲の免許センターが割と近いので、今回は初めて免許センターで更新することにしました。水曜日ということもあり空いていました。

センターの職員の方々はそれはもう慣れたもんで、スイスイと更新処理が進み 3時間くらいで新たな免許をゲットできました。ハプニングがなくて良いのですが、特に書くこともないですね……。

講習では「自転車のヘルメットが努力義務（規則だが罰則はない）になった」と言っていました。安全第一で良いことですね。罰則があっても良かったのでは？と思いますが、急激に変えると色々問題があったんでしょうか。

私個人的には、最近全く自転車に乗らないので関係ないっちゃ関係ないんですが、乗る機会がいつあるかわかりませんし、自転車買ったらヘルメット買おうっと。