DockerのAlpine化に向けて / Guile対応と実装WARの管理

Cygwin64ビルドのためのパッチをBoehmGCに投げました( https://github.com/ivmai/bdwgc/commit/4e24d219d29abb2b111bb9a9ccb13c3f149a855a )。Gauche由来のパッチが溜っていくね。。(e.g. https://github.com/ivmai/bdwgc/pull/91 )
基本的にアンダースコアを付けるだけ。Gauche等のパッチと違うのはGC_wordにキャストする点だけか。

Musl libc対応

で、今やっているのはDockerのAlpine化に向けたMusl libc対応で、後動いていないのはincremental collectionだけ。Issueに書いた( https://github.com/ivmai/bdwgc/issues/73#issuecomment-179080943 )ようにMuslは__MUSL__のようなfutureマクロが無いのでglibcで無い かつ uclibcでないで判定する必要があり、uclibcはglibcを詐称するので、結局のところglibcでないならMuslに帰着することに。最新のdietlibcで壊さなければまぁ良いかな。と。
MuslはTwitterでツイートしたら作者から直接コメントされる( https://twitter.com/RichFelker/status/695113058381885440 )等衝撃的なlibcで、glibcと相互依存にあるLinuxでこれをやる点はすごい情熱を感じる。
ちなみにAlpineLinuxの作者は現在Dockerに雇用されていて、HackernewsではDockerオフィシャルイメージのAlpineへの移行について触れられている( https://news.ycombinator.com/item?id=11000827 )。なのでMuslへの対応、つまり潜在的なglibc-ismへの対処は今後重要になってくる可能性がある。(ちょうどDebian/Ubuntuのash移行でbashismがあぶりだされていったように)

Guile対応と実装workaroundsの付番管理

Guileのmasterの非互換問題は結局workaround( https://github.com/okuoku/yuni/issues/29 )した。Chicken同様に、...等の補助キーワードが標準ライブラリにbindされていない処理系扱いとすることで問題を回避している。
yuniは移植性ライブラリなのでこの手のworkaroundはかなり仕込まれているが、ちょっと数が増えてきて管理しきれなくなってきたのでSIBR(Scheme Implementation Behaviour Report)として付番して管理することにした。もうちょっと政治的に正しい名称を考えたい。

• https://github.com/okuoku/yuni/tree/master/doc/sibr

この挙動を付番して管理する手法はCMakeのPOLICY( https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html )のようなもので、将来はyuniで書かれたSchemeプログラムからホストSchemeの挙動をクエリできるようにするつもり。cond-expandでも良いじゃんという説は有るが、SRFIと違って誰も管理していないのであんまし役に立っていない気がする。
現時点でSIBRは7つ有る。興味深いものとしては:

• https://github.com/okuoku/yuni/blob/master/doc/sibr/SIBR0001-AUX-KEYWORDS.md
  • SIBR0001: 標準の補助キーワードがバインドされていない処理系。SIBR0001処理系では、補助キーワードの再エクスポートが機能しないため、アプリケーション固有ライブラリで標準ライブラリをwrapすると機能しなくなる。SIBR0001はR7RS標準から逸脱している。R6RSの状況は不明。
• https://github.com/okuoku/yuni/blob/master/doc/sibr/SIBR0002-SYNRULE-DOTTED-TAIL.md
  • SIBR0002: ellipsisをsyntax-rulesのdotted-listパタンの最終入力にできない。SIBR0002はSRFI-46/R7RSで許可された挙動なので当該パタンを使用しないこと。
• https://github.com/okuoku/yuni/blob/master/doc/sibr/SIBR0003-SYNRULE-LIT-UNDERSCORE.md
  • SIBR0003: syntax-rulesのリテラルとしてアンダースコアを指定できない。SIBR0003はR6RSで許可された挙動なので当該パタンを使用しないこと。(性能とdebuggabilityのためにyuniはこの点をR7RS互換にwrapしない)
• https://github.com/okuoku/yuni/blob/master/doc/sibr/SIBR0005-C-STYLE-INCLUDEPATH.md
  • SIBR0005: Cスタイルのinclude path挙動を持たない処理系。一部の処理系はいわゆる*.sldからの相対パスを処理しない。yuniはincludeを使用しない。
• https://github.com/okuoku/yuni/blob/master/doc/sibr/SIBR0007-LIBNAME-COMPONENT.md
  • SIBR0007: ライブラリ名コンポーネントの一部が予約されていることがある。R7RS、R6RS共にライブラリ名の予約については特に規定が無い。SIBR0007に挙げられるライブラリ名は移植性ライブラリでは使用できない。

基本的にyuniではR7RS挙動に揃える方向で各種処理系をwrapしているが、SIBR0003のように意図的にwrapしていないようなケースが存在する。シンボルでなく番号管理するのはフロントエンド都合(翻訳の都合で全エラー/警告に番号を振る必要があるため揃えている)。