Mingw port status
r1948。手元の修正は基本的にtrunkに入れた(ライブラリ以外)ので、単にREADME.MINGWにあるようにconfigureすれば動くバイナリが得られる。
基本的に4.2以降のgccであればビルドできる。ただし、クロスビルド(linux上でWindowsバイナリを作る等)のための配慮は無い*1。
重要な違いとして、MinGWの配布は既にSJLJ(setjmp-longjmp)による例外処理ではなく、他のプラットフォームと同様にDwarf2によるunwindingをサポートしている*2。そのため、通常のビルドではlibgcc_s_dw2-1.dllを外部DLLとして配布する必要がある。
通常、Windows向けの実行ファイルを配布する場合はファイルが少なければ少ないほど良いので、そのうち-static-libgccが自動的に含まれるようにする。
現在の所、テストの多くは通らないしaccも機能しない。R6RS test suiteは全て通る。
Cygwin版は、あとはGCの警告を黙らせればというところ。日常的に使っているが特に不都合無い。Cygwin1.5はUnicode cleanでないので1.7を使う。
課題
- REPLの強化
最低でも括弧の強調とbash行編集くらいは欲しいところ。地味にWindows対応が面倒な分野なので、ターミナルエミュレータを自前で持つ方向で模索中。
さらにWindowsの端末は1プロセスにつき1つが基本という制限もある。
難しいのは自前のターミナルといわゆるVT100ターミナルの両立で、VT100程度の機能性に合わせるのもアリといえばアリだけど縦分割もできないような前時代的なターミナルを今更作るメリットは何処にあるのかという問題。
最終的にはlivecodingをサポートするために、GTEdit( http://www.instantcafe.org/hara/research/gtedit/gtedit.html )とかGraph Edit程度にはグラフィカルにしたいので、テキスト端末のことは後から考える。
emacsとかchez schemeはS式編集にある程度のショートカットがある。emacsの例 : Scheme: コーディングスタイル。
面倒なのでc-wrapperのようにlibffiで済ませたい。。
GObjectはgstreamerやGtkを使うのに必要。GObjectにはせっかく型システムが有るので、FFIでやるより何か特別なケアをしても良いような気もする。TinyCLOSが十分な速度で動くならそれでもいいけど。
GCでないmallocは、フレームバッファのようなメモリを呼び出し側が確保するときに必要になる。解放のタイミングが地味に面倒で、skymoshの場合はコンテキストオブジェクトを別途作っておいて、ポインタを次々push、コンテキストオブジェクトを解放したタイミングでpushされたポインタも全部解放。
あとcallbackも現状のFFIをwrapするだけでは実現は出来ない。skymoshではbinding側にstubを用意するか、0〜6個の引数をとるstub関数*3をN個*4インタプリタ側に用意して、競合しないように仲良くつかうという男らしい解決手法を採っていたが、もっと賢い方法が有るように思える。
callbackの難しいところはどのthreadから呼ばれるのか保証されていないことが多いこと。当然、BoehmGCに登録されていないスレッドでVMを動かすことは出来ないので、メッセージなり何なりで実行コンテキストを分離する必要がある。
とにかくユースケースを収集する必要がある。
