Zenn
🔨

FreeBSDのlang/moshをメンテナンスしたメモ

2020/09/17に公開
FreeBSD
scheme
idea

EDIT: BugzillaのURLが間違ってたので修正(今年の: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248874 2018年の: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229540 )

個人的に lang/mosh (net/mosh ではない) のメンテナをやっていて、FreeBSD 13-CURRENTでビルドが壊れたってメールが来たので治した。

mosh とは

R6RS Scheme処理系。残念ながら開発はドーマント状態でメンテナンスモードにある。思い出は後述。

※ 同名のネットワークシェル(MObile SHell)とは無関係。

やったこと

  1. メール来た
  2. パッチ書いた
  3. バグジラ起票した
  4. 取り込まれた

何が壊れたのか

FreeBSDでは標準のツールチェーンとして clang を採用しているが、 clang がLLVM-11のものにアップデートされて GCCと同様に -fno-common がデフォルトとなった 。

この挙動変更によって、コード内に同名のシンボル(関数や変数)を持っているプログラムが正常にビルドできなくなった。

moshは有名なC言語向けのガベジコレクタ(GC)である BohemGC を使用していて、これが重複シンボルを持っていてビルドに失敗していた。

↓ (ビルドが壊れたタイミングで来たメール)

先行してgccで同様の挙動変更が行われていた関係で既に Boehm GCでは問題が修正されていた ため、この差分をmoshのソースツリー内のBoehm GCに取り込むことで修正した。

修正手順

  1. UPDATINGを読んで更新内容を確認した
  2. とりあえず手元のFreeBSD環境をmakeworldして更新した。
  3. GitHubから portsのミラー をチェックアウトした
  4. 一旦portを普通に make して失敗させた
  5. ビルドが通るように修正
  6. make makepatch でパッチを作成
  7. Bugzillaのエントリ を起票

mosh の思い出

mosh( https://github.com/higepon/mosh/ )はhigepon先生が未踏で作られたSchemeシェルのコアとなるインタプリタだが、個人的にはこれのSchemeフロントエンドを別のものに差し替えてより堅牢にした nmosh を作成して2010年代初頭にかけて本当に色々な事に使用した。殆どは表に出ない裏方としての採用だけど、メディアインスタレーションの制作やSoCの即席デバッガの実装など、直ぐ手を入れられてそれなりのパフォーマンスで動作する言語処理系として非常に便利に使っていた。

特に、FFIバインディングをすぐ用意できる環境を作っていたので、C/C++ライブラリ同士を接続してプロダクトを用意するglueとしての利用が多かった。

... ある意味 技術的活動の青春を支えた処理系 と言っても過言ではないと思う。

後継

(n)moshの精神的後継としてはyuni( https://github.com/okuoku/yuni )というSchemeライブラリを制作していて、nmoshでできていたようなFFI glueとしてのScheme処理系の利用を 任意の Scheme処理系で行えるような環境整備を目指している。(意外と環境間の違いが多くて苦戦しているけど。。)

yuniは現状10を越えるScheme処理系で非常に小さなSchemeサブセットとそのライブラリシステムを提供しているに過ぎないので実用性ゼロだが、それでも単一のライブラリを複数の独立した処理系に対応した物としては相当に多くの処理系をサポートしていると思う -- 例えばJavaScriptとかC言語の処理系を10挙げてそれら全てで動作するライブラリを用意できるだろうか。

(... もしかしたら完全なC言語処理系よりもRISC-VとかWebAssembly実装の方が多かったりして、アセンブラの方がC言語よりも処理系のポータビリティがあったりしないだろうか。。)

現状、個人的にはScheme処理系としてはCISCOの ChezScheme かGaucheを使うことが多い。一応R7RS Schemeのリファレンス実装である chibi-scheme のコミッタ/Windows移植(自称)メンテナでもあるが、moshのような方向性で組込みに使えるScheme処理系は現状選択肢がなく、研究の余地がある。

(nmoshはSchemeコードをバイトコードにコンパイルして、そのバイトコードごと実行バイナリに組込むことができた。いわゆる組込み言語としてはよくある性質だと思うけど、なぜかScheme処理系は外部ファイルが必要なものが多い。)

まぁ今でこそPython/JavaScript/Rustにあらずんばプログラミングにあらずというような状況ではあるけれど、我々は往々にしてエコシステムではなくコンピュータを活用しなければならないので、ポータビリティが求められる状況というのは永久に終わらないのではないかと思っている。

Discussion