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を水冷化することにした。
