YamaKen
yamak****@bp*****
2004年 12月 31日 (金) 08:37:12 JST
ヤマケンです。 custom APIの改訂に伴ってuim-scm APIも位置付けが変わりつつあるの で最近の変化を紹介しておきます。 現在のlibuimはSchemeインタプリタのsiodをuim向けに改変したものに べったり依存する形で書かれているんですが、これを整理してuim-scm APIによってSchemeインタプリタを抽象化し、直接siodの関数を呼ぶ代 わりにuim_scm_*()を介して呼び出すように変えつつあります。siodが 公開しているシンボルは他のライブラリ等と衝突しやすい短かい名前な のでuim_scm_プリフィクスを付けてそれを回避する目的もあります。 これはlibuim内部利用の他、IMプラグイン内でCからSchemeインタプリ タにアクセスする際にも使われる事を意図しています。以前のuim-scm APIはGCまわりのハンドリングがまずかったため実用になりませんでし たが、後述の改変によりある程度安全に利用できるようになっています。 スタック上のlispオブジェクト保護のためにはちょっと特殊な作法が必 要なのでドキュメントが必要ですが。 libuimとSchemeインタプリタ間のインタフェイスが十分細くなって抽象 化された時点でTinySchemeやGaucheに挿し替えられるようにしたいと思っ ています。siodは標準仕様に沿っていない、ライブラリが少ない等の問 題があるので。また、Gaucheのような大きめの実装は十分なリソースの 用意できない環境では利用しにくいのでそのままでは標準にはできない と思いますが、リッチなプログラミング環境を生かしてのプロトタイピ ングには有用だと思います。 uim/uim-scm.c: #if 0 /* To avoid namespace pollution, all siod functions should be static and wrapped into uim-scm.c by direct inclusion rather than linked via public symbols. After uim_scm_* abstraction, the Scheme interpreter implementation can be switched to another one such as uim-scm-tinyscheme.c or uim-scm-gauche.c. But uim/*.[hc] and scm/*.scm are still depending on siod in several ways. At least full test suite for *.scm files are required to migrate to another Scheme implementation. -- YamaKen 2004-12-21 */ #include "slib.c" #endif At Sun, 03 Oct 2004 18:35:45 +0900, yamak****@bp***** wrote: > Schemeの実装の話になったのでついでに触れておきますが、現在のsiod > では repl_c_string() → callback → repl_c_string() のようにnest > した形でrepl_c_string()を呼ぶとGCがおかしくなるため、uimでは > callback queueを使ってこれを回避していますが、repl_c_string()の > 内部で呼ばれているrepl_driver()の実装をいじって、stack_start_ptr > の初期化を最初のrepl_c_string()呼び出し時に限って行う事でこの問 > 題を回避できるんじゃないかと考えています。実際の検証はまだですが、 > repl_c_string()がnested reentrantだとAPIの設計自由度が増すので、 > uim-scm API(とcustom API)の改訂時に実験してみようと思っています。 これもr86, r88, r89で対応し、一応の正常動作を確認しました。 今まではこの制限のためSchemeからcallback関数を呼んだり、Cの呼び 出し側スタック上にlispオブジェクトを置いたりする事が自由にできな かったんですが、両方とも可能になったので今後はそれを前提にlibuim 内部を柔軟でシンプルな形に再編・拡張してゆくつもりです。 手始めにcustom APIの「あるcustom variableが更新された時に呼ばれ るC callback」を実現するために利用します。これは現在のcallback queueでは実現できないため、callback queueの廃止が前提です。廃止 のスケジュールは以下のように予定していますが、何か関連する作業を 行っていたり問題を感じている方は意見ください。 0.4.6リリースまでの間、なるべく以下のコンフィギュレーションでテ ストして頂けると助かります。もしバグがあった場合にはアプリごとク ラッシュしますのでご注意ください。もちろん問題無い事を期待してい ますが。 configure --enable-scm-nested-eval --disable-callback-queue ------------------------------------------------------------------------ r86 | yamaken | 2004-12-31 05:41:21 +0900 (Fri, 31 Dec 2004) | 30 lines * This commit adds nested Scheme evaluation feature described below. The feature will be enabled by default once tested enough. - nested Scheme evaluation from C (i.e. C -> Scheme -> C -> Scheme) - protect lisp objects on the caller stack from GC ------------------------------------------------------------------------ r89 | yamaken | 2004-12-31 07:32:55 +0900 (Fri, 31 Dec 2004) | 49 lines * This commit removes callback queue from libuim to simplify the internal implementation. Whether use the callback queue or not is still configurable at compile time: - The old code using callback queue configure --disable-scm-nested-eval --enable-callback-queue - The new simplified code without callback queue configure --enable-scm-nested-eval --disable-callback-queue - The new simplified code without callback queue, but sometime crashes the application process. Exist only for testing purpose configure --disable-scm-nested-eval --disable-callback-queue Please test the second configuration. The second will be default for uim 0.4.6 if no fatal behavior is reported. After 0.4.6, the old codes enclosed by #ifdef UIM_CALLBACK_QUEUE will be removed to prepare further libuim simplification. If the callback queue is completely gone, we can simplify other codes affected by the callback queue such as uim_eval_string() ------------------------------- ヤマケン yamak****@bp*****
