YamaKen
yamak****@bp*****
2005年 11月 12日 (土) 02:23:18 JST
ヤマケンです。こんばんは。 At Tue, 8 Nov 2005 00:03:58 +0900, ek.ka****@gmail***** wrote: > 05/11/07 に Kazuki Ohta<mover****@hct*****> さんは書きました: > > > できれば年内にtrunkにSigSchemeをマージしたいんで、各人のやりたい > > > /得意な分野でどんどんTODOを潰していくのがいいんじゃないかと思い > > > ます。 > > んー、目指せ11月。pending作業って後何がありますかね？ > > port の抽象化以降、また LIBUIM_VERBOSE=0 で出力される > message がある場合、assert で exit するようになっています。 > ということで、verbose level 0 の場合の output_port と > error_port の対応おねがいできますか? 出力しない port を > どうするのか、意図がつかめなかったもので… あ、まずいですね。直しときます。 それでtrunkへのマージですが、11月中はちょっと難しいんじゃないか と思います。機能と品質が足りてないからですが、大きなものでは以下 になります。 ・SRFI-34とエラーハンドリング全般の修正 ・マルチバイト文字サポート(int<->char相互変換等) ・compaction その他sigscheme/TODOの"Requirements and bugs"に含まれているもの はマージ前に潰しておく必要があると思っています。 それから品質面では未整理なコードが多いのと、テストの網羅性に問題 があります。前者に対しては少なくとも"FIXME"とマークしてある個所 を全て整理し、後者は境界条件のテスト拡充とエラー発生ケースのカバー が必要です。このためにassert-errorとassert-parse-errorを用意し、 例示を兼ねてcond, stringリテラル, charリテラルのテストを私が想定 しているレベルに補完しました。いずれも重要なバグが見つかっている ので、他のprocedure等に対しても同レベルのテスト拡充が必須と思い ます。 これらはtrunkにマージしてから行うという選択肢もありますが、以下 の理由によりマージ前にやっておくべきと考えています。 ・品質向上といった地味な作業はtrunkへのマージという目標が消える とおざなりになってしまう ・uim自体の開発が同時に進むと、問題が発生した場合にuimと SigSchemeのどちらに原因があるか切り分けるのにコストが嵩む ・scm/以下のコードのSigScheme(R5RS)依存が始まり、SIODベースの安 定版にバグ/セキュリティ修正をbackportできなくなるケースが出て くる。よってtrunkにマージする時点ですぐにでもSigSchemeベースの 安定版uimを出せる品質に達しているのが望ましい ------------------------------- ヤマケン yamak****@bp*****
