週刊mosh - 0.2.7リリースブランチマージ / WG1への対応方針
0.2.7のリリースブランチ(okuoku側)が開発ブランチ(higepon側)にマージされました。
moshはそれなりにテストが有って、0.2.6→0.2.7の変更でビルドの信頼性は相当向上したので今後は(pushする前にcheckさえすれば)開発ブランチとリリースブランチの別は無くなるはず。。
このマージによってディレクトリ構成が変更されたので、gen-git-build.shの前にgit cleanするかcloneしなおしてください。autoreconfがlibtoolizeを実行しないことが有るので事件が起きます。
解決したIssue
with-syntaxにbodyが無い。これは、psyntax-moshもnmoshもSRFI-93の定義で実装していたため。
psyntax-moshはパッチが提供された。nmoshはR6RSのexample通りの定義に変更。
この辺の変更はr6rs-test-suiteにフィードバックした方が良いかもなぁ。。
- http://code.google.com/p/mosh-scheme/issues/detail?id=197
- Gaucheを0.9.1にアップデートするとbootstrapできない
mergeされた。
報告されたIssue
- http://code.google.com/p/mosh-scheme/issues/detail?id=198
- CProcedureがリエントラントでない
mosh上で使えるScheme手続きはCProcedureと呼ばれる。このScheme手続きの戻り値はCProcedureオブジェクト中に保持されるのを期待しているので、本来CProcedureの呼び出しからそのCProcedureに再帰することはできない。
これが起こるのはCustom portsとhashtable、FFIだけなので、これを全部VM側のディスパッチループでチェックして特別対応する必要が有る。今のところ、put-stringとFFIだけが対応されているので、Known Issue行き。
個人的には、これはdesign flawだと考えていて、(CProcedure的な意味で)Leaf functionでないCProcedureを作らないようにする(= Custom portsはScheme側で実装する)か、そもそも現状のVM自体を再編する必要が有るような気がしている。
話題
0.2.7から、正常に動作するSRFIが必要になったという話。これに関しては対策を2つ考えていて、1) gen-git-build.shの中でLOADPATHを空に再設定 2) bootstrapに使うmoshをnmoshに変えて-nodefaultlibのようなオプションを追加。
psyntax-moshは(この界隈ではメジャーな)Derick EddingtonのR6RS SRFIコレクションを実行できないバグが有る(コンパイラのバグを踏む)。nmoshは実行できるのでそちらの方が安定すると期待される。
Socketからの送信時にSEGV。GCの問題ではないかと考えられる。
nmoshはそもそもサンプルを実行できないので、nmoshのバグの予感も。
CMakeビルドからpsyntax-moshをdrop
0.2.7から、CMakeビルドではpsyntax-moshが作れなくなります。Loadpathの挙動調整やbootstrapが難しいことによる問題。
configureによるビルドでは従来通りpsyntax-moshが標準。
組込みモード / prefix-less モード
prefix-lessモードはライブラリを$PREFIX/share/mosh/$VERSION/libから探さないモード。
組込みモードは、share/mosh/$VERSION/libの構造自体を使用しないモード。/libの代わりに/mosh-libにSchemeライブラリがインストールされるように。(後者は未実装)
これらはWin32やMac OS Xのアプリケーションとしてnmoshを使うためのモードで、システムに他のnmoshがインストールされていても干渉しないようにするのと、インストーラによってprogram files以外にmoshがインストールされた場合の対策。
psyntax-moshのnmoshによるBootstrap
psyntax-moshはnmoshでbootstrapできるようになりました。(未merge)
現在、psyntax-moshはSubversionから常にダウンロードする方針になっているのを、nmoshと同様gen-git-build時に生成するよう変更可能に。
ただ、現状のnmoshはpsyntax-moshでbootstrapしないといけないので、この点をどうにかする必要有り。高速化のためにGaucheを使ったbootstrapを以前無効化したので、それを復活させるかも。
bootstrap時に外部と通信するプログラムは、実際のアプリケーションに組込むという観点から言うとかなりヤバいので。。
テストケースから外部通信の排除
FacebookやGoogleといった外部サイトと通信を行うテストケースは一旦全部無効化しています。プライバシの懸念のため。
今回は手動でtest suiteを検閲したので、人工的にテスト環境を調整してチェックする必要が有った。将来的には自動化する必要が有るかも。
nmoshのWG1 modulesへの対応(予定)
(psyntax-moshの対応方針は不明)
nmoshはWG1 modulesに対応する予定です。これは将来のScheme標準のproposalで、includeを標準で持ち、exportやimportを好きな場所に配置できます。
nmoshとして拡張するのは :
- phase semantics。R6RS互換のPhasing機能。
- includeは文字列だけでなくDerick EddingtonのR6RS SRFIコレクションに見られるような(directory filename)形式のオブジェクトにも対応。この形式で指定した場合はライブラリと同様に検索される。
- includeされたファイルもキャッシュ依存関係として追跡する。
- 拡張子は.slsに限定。.nmosh.slsを推奨。
- SRFIライブラリはSRFI-97互換名のエイリアスを持つ。現状のmoshで提供されているSRFIはほぼ対応予定。
- いくつかのR6RSライブラリは提供される。(rnrs base)や(rnrs control)、(rnrs unicode)等。
- (rnrs base)のsyntax-rulesはchibi-scheme由来のもの。
重要な注意点としては :
- WG1モジュールライブラリを使ったプログラムではsyntax-caseとR6RS recordが提供されない。
- 平たく言えば、(rnrs)は提供されない。(rnrs base)や(rnrs control)を明示的にimportする必要有り。
- low-level macrosとしてはexplicit-renaming+とその上に実装された普通のexplicit-renamingを提供します ( http://d.hatena.ne.jp/mjt/20110302/p1 )
- マクロの結果としてシンボルを返した場合の挙動は、普通のexplicit-renamingは適当なidentifierの挿入(= 〜+におけるinject)、explicit-renaming+の場合は未定義です。(内部的にVMコンパイラ用のcore-form挿入に使用)
- 最初のバージョンでは(rnrs base)のidentifier-syntaxは提供しない予定。
- 標準的なScheme bindingは(rnrs)でなく(nmosh)で提供される。これにはSRFI-8やSRFI-26、SRFI-48、(shorten)のような基本的な構文や手続きも全て含まれる。(Chez Schemeにおける(chezscheme)ライブラリと同様の方針。)
- バージョン機構は提供予定なし。現状と同様。
- ReaderはR6RS互換。ただしcase-foldingなし。
現在、WG1はドラフトを作成中なので、それを待っているところ。
とにかくsyntax-caseが難しいところで、これさえサポートできれば現状のnmoshのexpanderは廃止できる。それまでは、WG1 expanderと現状のnmosh expanderの両方を持つことになる予定。。
一応、explicit-renaming+の仕様はsyntax-caseと同居できるように作ってあるので、それなりにコストを掛ければ対応すること自体は可能。問題は、そこまでコストを掛ける必要が有るかどうかというポイント。。
手元のプログラムにおけるsyntax-caseのユースケースは、explicit-renaming+とmatch構文の組合せでほぼカバーできるので、個人的にはWG1 expanderが安定したらnmosh expanderは使わなくなるような気がする。