そういえば 「HyperSpec」もpkgにあったので。
sudo pkg install clisp-hyperspec-7.0
で、インストール。
インストール先は
pkg list clisp-hyperspec-7.0
で、確認してemacsのinit.elに定義した。
(setq common-lisp-hyperspec-root "file:/usr/local/share/doc/clisp-hyperspec/HyperSpec/")
ふむ。だじょうぶそうだ。
RaspberryPi B+にはFreeBSD12をいれるつもりだった。
しかし、動かない。
bootすらしない(後日、全然、動くことが判明した1)。
あかんわー。Ubuntuもあったけど、ちょっとかったるそうだ。というわけで、先代と同じくRaspbianをインストールした。しまった。区別がつかない。せめてケースのカラーリングぐらい別にすべきだった。
あたりまえのように動く。あたりまえだけど。
それにしてもこの軽いOS、RaspberryPi以外でもけっこういいかもしれない。
と、思ったらちゃんと「Raspberry Pi Desktop」というのがあった。
インストール後、パッケージをコツコツといれていく。
Debianのパッケージシステム。apt。
Emacs、postgres——SBCLもあった。1.3.7-1。EmacsのライブラリはRaspbianのパッケージからではなく、Emacs自身のパッケージシステムから。
SBCLの環境はFreeBSDと同様、quicklispからいれる。
ちょっととした気の迷いでaptからASDFをいれたのだけど、何かうまく動かせず——というか、SBCLには1.5.1のときのようにASDFが同梱されてなかった——、削除してまず、quicklispをいれたらいっしょについてきた。あ、そうなんだ。
「~/.sbclrc」に(require :asdf)を追加した以外はほぼ、FreeBSDのときと同じ。
ところが、このSBCL、threadをサポートしてなくて「make-thread」で落ちる。
くそおっ。
SBCLのgithubからソースをもってきてビルドする。
手順はほぼ、INSTALLというファイルに書いていた通り。ソースからビルドする場合はあらかじめ、CommonLispが必要だという。おもしろい。ところがINSTALLを読んでいたら不吉な一文が。
Native threads. Enabled by default on x86[-64] Linux only, also
available on x86[-64] Max OS X, x86[-64] FreeBSD, x86 Solaris,
and PPC Linux.
あかんかも。
何度か試してみたけれど、結局、Threadをサポートした状態にできず。
自前のプログラムはthread前提じゃなかったっけ。マルチに動かすために。
しまった、だめじゃないか2。
不思議なのだけど、Ubuntuだと、バックグランドで動いているpostgresはひとつのプロセスにひとつのCPUが割り当てられているようだった。実際、threadひとつのときは、システムモニタで見ると、ひとつのCPUだけががっつり使われていた——なのに、FreeBSDだとそれが、分散されているように見える。全体的にCPUが使用されている。
topコマンドで見ても時々、使うCPUが他のものに切り替わっていた。
これはLinuxとFreeBSDのちがいなのか、それとも用意されているバイナリのposrgresのコンパイルオプションのちがいなのか——。
Threadごとにconnectionを管理できるようにしたからだいじょうだと思っていた。たしかにThread二つまでは何ともなかった。それを四つにしたらおかしくなった。
いきなりPREPAREがすでに使われている、とエラーになる。
——？
どうして二つで動いていたものが、四つだと動かなくなる？
しかもすぐに起きることもあれば、しばらくたってから起きることもある。同じ処理をくりかえしているにもかかわらず。
三日、考えこんだ。
使っているライブラリも疑った。
どうデバックすれば、いいかも思いつかない。タイミングで発生しているのはあきらかで——それを補足するのはどうすれば、いいのだろう。ソース百遍。
三日目にしてようやく気づいた。
threadごとに管理しているconnectionはハッシュテーブルを使っている。
同時にこのハッシュテーブルにアクセスされたらどうなるんだろう？
あっ、まずいかもしれない。
ハッシュテーブルがthreadセーフなら別だが——。
どうやれば、それがわかるのか、わからなかったのでとりあえず対処した。
「with-lock-held」で処理を排他1。
それでエラーはいちおう起きなくなったように見えた。が、それは頻度が極端に減っただけで起きるときには起きる。あれ？
これがわからない。謎だ。
同じPREPAREがすでに使われているというエラーなのだが——たぶんthreadセーフじゃないところがまだ、どこかに残っているのだろう。あるいは使っているライブラリかもしれない。むずかしい。
これを避ける方法にはsqlを発行しているところをハッシュテーブルのときのように排他処理をかければ、いいのだが……それだと並列処理の意味がなくなってしまう。
threadひとつだけの場合とかわらないからだ。
まったくthreadで動くようにしたらthreadにした意味自体がなくなってしまう、という……。
なんて厄介な2。
また、RaspberryPiを買ってしまった。
別に現役のRaspberryPiがお亡くなりになったわけじゃないのだけど。
Beelink S1が熱くなっているのでRaspberryPiの方がましかもしれない、と思ったのだ。CISCよりRISCチップの方が発熱しないという話をどこかで読んだことがある。なので。
ところがAmazonで同じ値段だったので「Raspberry Pi 3 Model B」ではなく、「Raspberry Pi 3 Model B+」を注文してしまった。そのあと、調べてみると、「Raspberry Pi 3 Model B+」の方が消費電力は大きく——もちろんそれで発熱も大きくなるだろうし——、そもそも電源はちゃんと対応しているものが必要……。
えっ？
iPhoneのは使えないの？
頭を抱えていたらもともと「B」でもiPhone用のではアンペア不足らしい。使えるのは使えるらしいが。ということは「B」のときにいっしょに買った電源はどうなんだ？ 調べてみたら3Aあって「B+」に使えることが判明した。
使ってなかったのでこれ幸い。
ほっとした。
それにしてもmicroSDカード、安くなったなぁ。
へたなハードディスクよりお得かもしれない。
よくよく考えたらBeelink S1をMaicroSDカードから使えば、よかったんじゃね……RaspberryPiなんて必要なかったんじゃね……。
SBCLは使えるようになったのだけど、立ち上げるときにWarningがでているのが気になってしかったなかった。しかもどうもASDFがらみ。
英語なのでわかりませ〜ん。
とばかりいってもいられないのでGoogle翻訳の片言日本語で読んでみた。
なんか、ASDFがインストールされているけど、そっちは使わないよ、古かったりするからね、管理者権限があるなら削除した方がいいよ、ちなみに「~/.config/common-lisp/source-registry.conf 」は使えないよ……。
って書いているような気がする。
なんか、状況は一致するな。
でもそもそもASDFを入れた覚えはないんだけど？
ところが、調べてみたらインストールされていた。どうやらSBCLをインストールしたとき、いっしょに入ったらしい。その証拠に「pkg-delete」しようとしたら「SBCL」までいっしょに削除しようとする。
おいおい。
まぁ、実害はなさそうだ。
いちおうpkgで入ったASDFをいじって見えなくしたらWarningはでなくなったし。解釈はまちがいなさそうだ。Warningは無視する方向にしよう。
もしかしたらSBCLは独自のPATH構成にしているのかもしれない。それでSBCL対応のパッケージがいちいち、pkgに用意されているのかも。
果たしてroswellにたよらずにやっていけるだろうか。
なにはともあれ今まで何度も読み返していた「require, ASDF, quicklispを正しく使う」をふたたび、読み返す。いまいち、理解していないんだよなぁ、このあたりの話。roswellにたよってしまっていたのでなおのこと。
とりあえず、FreeBSD環境にSBCLをインストールした。
sudo pkg install sbcl
pkgにはほかにも「alexandria」とか、「asdf」とか、もろもろの他、SBCLのパッチがあたっているとおぼしき、バージョンもある。これを使うべきか？
迷いつつ、SBCLをslimeで使えるように設定して。
(setq inferior-lisp-program "/usr/local/bin/sbcl --noinform")
立ち上げてみたら「asdf」なんたらの文字が見えた。
そうか。SBCLの中にasdfが内蔵されているのか。そういえば、ABCLもそうだった。それならpkgでASDFをインストールすることもないか。
ところがいくらやってみても「~/.config/common-lisp/source-registry.conf 」に定義した内容がcommonlispに反映されない。試行錯誤すること数時間。
あかんわー。
自分のミスとは思えない。もしかしたらSBCL内蔵のASDFは「~/.config/common-lisp/source-registry.conf 」は無効になっているのかもしれない。じゃ、どうやって設定すれば、いいんだ？
「quicklisp1」でもってきたライブラリの場所を認識させたいんだけど2？
つらつら考えて「~/.sbclrc」に設定した。
(asdf::initialize-source-registry
'(:source-registry
(:tree "~/quicklisp/dists/") :INHERIT-CONFIGURATION))
「asdf:find-system」で設定が有効になっていることを確認。
よし。
でもREPLで「ql:quickload」が使えないのは不便なので「~/.sbclrc」にさらに設定を追加した。
(load #P"~/quicklisp/setup.lisp")
あれ、これでroswellからのREPLとほぼ、同じになったんじゃね？
すくなくともぼくが使うかぎりにおいて。
「quicklisp」はpkgになかったのでhttps://www.quicklisp.org/beta/からもってきて自前でインストール。
「~/common-lisp」の下は認識されているから自前のLispはここへ置けば、いいんだけど。
CPUをぶんぶん回していると、当たり前だけど、熱くなる。
簡単に水冷化したけれど、これは効果がなかったようで。
もしかしたらUbuntuがおかしくなったのはそのせいかもしれない。
昔はそんな経験はあまりしなかったような？
そういえば、SSD換装をするようになってからのような気がする。
ありうることだ。
昔はハードディスクのアクセスがボトルネックになってCPUの発熱が自然と抑えられていた。そういうことかもしれない。今は抑えがなくなってCPUがまじで熱くなっているもかもしれない。
それならやばいんじゃないか。
普通のノートパソコンやミニパソコンでぶんぶんCPUを回すというのは。
Beelink S1はハードディスクにすべきだろうか。
さて。
XQuartzにアプリケーションを登録すると、MacBook AirからBeelink S1の「emacs -damon」を起動できる。
これはよかった。「emacs -daemon」はXQuartzを終了させてもBeelink S1で立ち上がりつづけるからだ。Emacsが一種のサーバになる。これに接続するには「emacsclient」を使うのだけれど、「ssh -Y ほげほげ emacsclient -c」でこれはＯＫ。XQuartzにEmacsが表示される。
実体は「emacs -daemon」なのでそれまで編集していたバッファとかがそのまま、残されている——なのだけれど、どうやらＸサーバに接続する「-c」オプションはemacsclientを終わらせてもＸサーバに接続されたままらしい。Ｘサーバ(XQuartz)を終了させると、「emacs -daemon」がcoreを吐いて落ちてしまう1。
これがターミナル上に表示される「-nw」オプションだと、emacsclientを終了させてもdaemonは動きつづけているし(ここまでは「-c」オプションのときと同じ)、ターミナルを終了させてもだいじょうだ(ここがちがう)。もちろんMacBook Airを終了させてもＯＫだ。
ふむ。
しかたないのでワンクッションいれることにした。
「ssh -Y ほげほげ」でBeelink S1からターミナル2を立ち上げ、その中で「emacsclient -nw」を立ち上げる。これでEmacs自体はＸに接続していないのでdaemonごとお亡くなりにならないだろう。Beelink S1のターミナルならcommandキーをmetaキーと認識できる。ただしクリップボードの共有はできないけれど。
まぁ、これはしかたないか。
アプリケーションには次のように登録した。
ssh -Y ほげほげ lxterminal -e emacsclient -nw
これでemacsclientまで一気に起動される。当たり前だが、起動はやたら速い。
FreeBSDのpkgにroswellが登録されてなかった。
portにも見当たらず、しかたなく、githubから直接、もってきてコンパイルする。
sudo make install
そこまではよかったのだけれど。
ros install
roswellからのSBCLのインストールに失敗。
これはGNU Makeが入ってなかったからだけど、そのとき、もってきていたのはSBCLの1.2.7だった。FreeBSDのpkgにはSBCLの1.5.1があるというのに1。
それで考えてしまった。
roswellスクリプトを使わないのならroswellなしの環境を構築するのもありかもしれない、と。
でもできるだろうか。
可能なことはわかっているけれど。
Beelink S1やRaspberry PiへはMacのターミナルからsshで接続している。
フォントも好みのものにしているし、基本的には満足なのだけど、二点ほど気に入らないところがある。commandキーをmetaキーに割り当てられないのだ1。AquaEmacsではcommandキーをmetaキーにしているし、キーの配置的にやはりmetaキーはcommandキーのところであって欲しい。
なのでひんぱんに使うmeta + pを押すたび、印刷のダイヤログが立ち上がってしまう。何をやっておるのか。
もうひとつはクリップボードの共有ができないということ。
そこで「ssh -Y」
Beelink S1で動かしたEmacsをMacBook AirのXQuartz2に表示して使おうというのだ。
Ubuntuのときはこの手が使えなかった。なぜか、「ssh -Y」が効かなかった。しかし、FreeBSDではできたはず——なのに、どうしてか、「ssh -Y ほげほげ emacs」でエラーになる。xauthがなんとかかんとか。
うーむ。
manをあさったり、ググったり。
不思議なことにFreeBSDならいろいろいじる気になる。なぜだろう。Ubuntuではそこまでやる気になれなかった。調べた結果——わからない。ちゃんと設定しているように見える。
ふと、/etc/sshd.confのmanを見ていてXauthの設定があることに気づいた。
そういえば、エラーメッセージにもxauthなんとか、とでていたな。
そもそもxauthはインストールされているのか？
されてなかった。
そういうオチかい！
sudo pkg install xauth
そういうオチだった。
いれたら動くようになった。
これでクリップボードも共有できるし、commandキーをmetaキーとしても使える。なんだ、xauthをいれてやれば、よかったのか。Ubuntuもそうだったのかな？ Ubuntuは今や動かないけれど、RaspberryPiを調べてみると——あれ？ xauthは入っている。
しかも昔、RaspberryPiは「ssh -Y」が使えていた。
それなのに今は使えない。
xauthのエラーメッセージがでる。
うーむ、謎だ。
| -No- | 時刻 | 時間 | 帆走距離 | 最高速 | 平均時速 | Ｐ％ |
|---|---|---|---|---|---|---|
| 1 | 14:24-14:30 | 5分 | 0.9km | 34.54km/h | 9.80km/h | 35.07 |
| 2 | 14:37-14:58 | 20分 | 3.7km | 35.42km/h | 10.81km/h | 39.03 |
| 3 | 15:29-15:50 | 20分 | 1.5km | 35.82km/h | 4.29km/h | 22.62 |
total 46分 6.1km 7.8km/h
リハビリにはやはり本栖湖だな。
そう思って山梨へ向かう土曜日。道志みちから山中湖へ下るところで正面にあらわれた富士山を見てビビった。びっしりと雪が残っているのだ。ゴールデンウィークまであと一週間というのに、こんなに残っているのははじめて見た。
雪解け水が流れこむ本栖湖の水の冷たさを思うと顔がひきつってくる。
ＦＵＮビーチに到着したのは午後二時すこし前だった。
本栖湖入口ではまだ吹き出していないように見えたけれど、吹いていた。白波も見える。
いつものセットで出艇。
ブームの高さとか、ハーネスの位置とか、水の冷たさとか——いろいろあったけれど、とりあえずプレーニングした。何年ぶりのことか(大げさな)。
ブローがきつく、ダウンをむちゃ引きしたら逆に乗りづらくなってしまった。
リハビリにはあまりのハードコンディションに涙目になる。ひさしぶりの5.7のセイルでハエ叩きにあうほどだった。しかも寒い。
ビーチにあがると、歯が鳴って胴震いが止まらない。
真冬の菊川かよ。防寒対策にライフジャケットを身につけてすこしましになった。けれど、四時前には根性が尽きた。
全然、楽しくない——楽しむにはやはり体力がいる。
ボーナスタイムも吹き吹きだったけれど、大部分の人は撤収。
ぼくもそれにならう。二、三艇だけがやたら走り回っている。これが二十代のころならクタクタになるまでやっているところだけど。クタクタになるのにも体力がいる。
アップデートしたらUbuntuが動かなくなってしまった。
一行だけメッセージを表示したまま、ディスプレイのオンオフをくりかえす。なんじゃ？ こりゃ？ 電源ボタンには反応するので裏では動いていると思うのだが。
もしかしたら時間がかかっているだけか、と思って半日そのままにしていたけれど、状況は変わらず。レスキューモードでfsckをかけようとしたりしたけれど、できなかった。状況は改善しない。
——これだからUbuntuは……。
もちろんこれは筋違いな腹立たしさだ。今にして思えば、おそらくSSDがお亡くなりになったのだろう1。readonlyでしか、mountできなくなってしまった。そういうことだろう。でもこの半日のあいだに考えた。くそっ、FreeBSDをいれちゃる。もうひとつ持っているSSDに。
もともとFreeBSDをいれることに乗り気でなかったのは内蔵のWifiを認識しないだろうな、と思っていたからだった。ところがよくよく考えたらThinkPadで使っていたBUFFALO WLI-UC-GN2使えるじゃないか。あれはFreeBSDで使っていたのだから。そう思ったのだが、どういうわけか、それが見当たらない。
もしかしたらThinkPadを処分したときにいっしょに処分してしまったのかもしれない——ない。
しかたないな。とりあえず、インストールしてみよう。
メモリスティックにbootイメージをコピーしながら、ふと気づいた。あれ？ 以前はどうしてそうしなかったんだろう？
あのときは直接、SSDにインストールしたのだけれど。今やっているような手順だったらインストールできたんじゃないか？
しかも今、FreeBSD11.2をいれるつもりだったのにうっかりFreeBSD12のインストールメディアをつくっている。
何をやっているんだ、おれは……。
どうせだめだろうけど、面倒なのでそのまま、FreeBSD12のインストールイメージを使うことにした。BIOSの設定を変更して起動。ブートメニューがあらわれた。しかもインストールの設定画面を進んでいっていくと、オンボードのWifiを認識している！ おおっ、BUFFALO WLI-UC-GN2不要じゃないか。それなら真面目に11.2を入れなおそうと、インストールメディアをつくりなおした。
ところが11.2ではWifiを認識してくれなかった。
何をやっているんだ、おれは……。
いやいや。
12をインストールしようとしなければ、オンボードのWifiが使えることに気づかなかった——そう考えると、不幸中の幸いだったのかもしれない。
いずれにしてもBeelink S1でFreeBSDが動く！2
ひさしぶりのFreeBSDだ！
まだ、sshでLANから入るくらいしか、できないけれど。
Threadごとにconnectionが張れるようになったのだからマルチプロセスでキューイングしたやつをマルチスレッド化してみよう。mailboxというライブラリを使おうとしたのだけど、キューが空だったとき、readで待ってくれない。nilが返ってくる。
自分でsleepするの1？
ABCLのmailboxは待ってくれるのだが。
ほかのライブラリはないか、と探してみると、lparallelのqueueなら待ってくれることがわかった。ちょこちょこと組んでみたらあっさりできあがって驚いた。
これで立ち上げたworker-jobの数分だけ並列でキューが処理される——はず。
mutexを使えば、sleepは必要ないだろうけど。
| -No- | 時刻 | 時間 | 帆走距離 | 最高速 | 平均時速 | Ｐ％ |
|---|---|---|---|---|---|---|
| 1 | 15:37.33-15:55.21 | 17分 | 1.0km | 13.56km/h | 3.27km/h | 0.00 |
total 17分 1.0km 3.3km/h
日本海側に低気圧が入り、日曜はどん吹きの予想だった。
乗れるだろうか。その心配ばかりしていたら前日には肩透かしの予報になっていた。昼の1時から2時間ぐらいしか、吹かなそう。
今の自分には2時間ぐらいでのきついくらいだ。
とりあえず、昼前に検見川の駐車場入り。
まだ、吹いていないので運転席でケータイをチェックしていたらいきなりゴンと大きな音がした。どうやらすぐそばでセイルをセッティングしていたセイラーがセイルを運ぶときにぶつけたらしい。
あれだけ大きな音がしたのに完全に無視してそのセイラーはいなくなってしまった。どう反応したらいいか、わからず、呆然としていたので苦情をいう時機を逸っしてしまった。
車をチェックしてみると、見事に傷がついていた。
嫌な気分になり、そのまま、帰ってしまおうか、と思った。
1時になっても風は吹き上がらない。
2時すぎにすこし風は上がってきたけれど、乗れるほどではなかった。しばらく海を見つめていたけれど、風は上がらない。セッティングしてビーチへだしていたボードを回収して車に納める。
そのあと、トイレに行ってもどってくると、ハーバーの旗がさっきよりも激しくはためいていた。
見なかったことにして帰ろうか。
ビーチで確認すると、白波が沖のほうから入ってきていた。ああ、これはでるしかないなぁ。ボードをふたたび、セッティングしてビーチへ運ぶと——あれ？ 白波はどこに？
しばし呆然としてしまった。
海ほたるをチェックすると、風速14m。それなら吹くんじゃね？
そのうち、風が入ってくることを期待してセイルもセッティングし、セミドライに着替えて海へ。海を眺めること、10分以上。だめか。
あきらめて海に入って半往復してあがった。
それなのにセミドライを脱ぐとき、足が攣った。
when-letは生のCommonnLispにはないけれど、当たり前のようにalexandria1の中にある。swankの中にもあってほかのCommonLispでも見たことがあったような。
ぼくが思いつくくらいなのだからだれでも思いつくのだろう。
でもunless-letってないよな。
どうしてだろう、と考えてすぐに気づいた——そりゃそうだ。
(unless-let (x date)
body)
のxってnil一択じゃん。
CommonLispの定番ライブラリ
マルチプロセスで並列化したのは、実はThreadごとにDBとのconnectionを張る方法がわからなかったからだ。単純にThreadの中で最初にmake-connectionしていたら落っこちた1。
そうか、*connection*は別空間にならないのか。
でもどうやれば、いいんだろう。たぶんパッケージもThreadごとになるわけじゃないだろうし。そもそもThreadごとに変数をもてるのか？
Emacsのバッファローカル変数のように。
うーん、*connection*をクロージャー化すれば、いけるような気もするけれど、方向性を誤っているような予感がする。で、結局、そのあたりのあれやこれやが解決しないと、マルチスレッドでの並列化は無理だった。
別にマルチプロセスで問題はないのだけど。
いや問題はあるのか。ループでプロセスを四個ずつ立ち上げるようにしているので、途中で終了することができない。Ctrl-Cで中断するしかなく、なんか、これが気持ち悪い。
ググってもわからず、悩んでいるとき、cl-dbiのソースをのぞいたらまさにそういうコードがあった。別に明確にサポートしているわけではなく、それ関係がエクスポートされているわけでもないのだけど、考え方は了解した。
なるほど、ハッシュテーブルを用意してThread自身をキーにしてconnectionを管理すれば、いいのか。じゃ、こうか。
*connection*を(conn)に変更すれば、ＯＫ——そのはず2。
やはりUnitテストは書いておくべきだなぁ。
そう痛感した今日この頃。ある程度の規模になると、ふとした修正が原因で動かなくなったことに気づかないことがある。なのでUnitテストは書いておいた方がいいんだけど、重いUnitテストだと、それを毎回、動かすのがかったるくなって動かさなくなってしまう。
本末転倒だ。
で、重いテストを一時的にコメントアウトしたりするのだけど——。
——もっといい方法はありませんかね？
何か手があるような気がするのだけど。
C言語の「#ifdef」のようなやり方。たしかCommonLispにもシステムごとにコードを切り替える方法があったことは覚えているんだけど、どうすれば、いいか、見つけ切れなかった。たしかリーダーマクロを使ったやり方なんだけど——どうやるんだっけ？
とりあえず「when」で囲ってその場しのぎをしていたのだけれど。
SWANKのソースをたまたま、のぞいたときにそれを発見した。
——#+nil
#+nil (defimplementation disassemble-frame (index) (disassemble (debugger:frame-function (nth-frame index))))
おおっ、これだよ、求めていたのは。
しかもソースコードも色もちゃんとコメントアウトされたようにかわるじゃないか。
ループで処理をぶんぶん回す、というのはマルチコアのご時世ではあまり意味がないらしい。
たとえば、Beelink S1はクアッドコアなのだけれど、システムモニターで見ていると、ぶんぶん、動いてくれていない。どうもひとつのCPUだけが酷使されているだけで全体としてはのんびりとしたものになるらしい。閉店ガラガラ。まぁ、当たり前かもしらんけど。
しかし、ぼくはぶんぶんふり回したい。
うーむ。それには処理を並列化するしかないかぁ。
面倒だ。
とりあえず、マルチプロセスで対応することにした。つまりプログラムを複数、動かして処理を並列化しよう、というわけ。そうすれば、CPUが閉店ガラガラなんてことにはならないだろう。たぶん。
というわけではじめてrosスクリプトに取り組む。
シェルスクリプトの感覚で途中までいじってふと、ああ、これはCommonLispなんだ、と気づく。
なるほど。
当たり前だけど、一気に10個とか、20個とか、プログラムを起動したらマシンがパンクする。
ぶんぶんふり回すには同時に動かす数を制御する必要がある
すると、処理のキューイングと起動したプログラムの死活監視がいる。うーん。そもそもどうやってプログラムが終わったことを検知すれば、いい？ 昔、シェルプログラムで似たことをやったときには終了したときにファイルをつくるように仕込んだけど。
それはそれで面倒なのでプログラムの起動部分をマルチスレッド化することにした。
プログラムを同期起動してやれば、「プログラムの終了＝スレッドの終了」になるはずなので、スレッドの状態を調べれば、なんとかなるのでは？
——なんとか、なった。
軒並、90％ごえ。でも熱暴走しそうなのでとりあえず、Beelink S1を水冷化することにした。
