Nanthy
このページは自由に編集出来ます。
日本語変換エンジン ナンシーの紹介
Nanthyはanthyからフォークしたものです。計画倒れの可能性あり。
当面はコードのクリーンアップに力を入れ、ユーザーの利用は想定しない方向でいく予定です。
辞書の開発はこちら -> Nanthy/辞書。
開発に参加したいと考えてる方へ
Nanthyでは開発に分散型バージョン管理システムであるBazaar-NG(以下bzr)を利用しています。インストールしていない方はインストールしてください。Debian系ならルート権限でaptitude install bzrを実行すればオーケーです。それとBazaar User Guideを読むことをおすすめします。
また、launchpadにホスティングしてます。launchpadにユーザー登録してなければ登録をしてください。分からないことがあったら、Launchpad Help wikiを見るのをお勧めします。
また開発に際し、Ubuntu行動規範を守ることを推奨します。
現在メンテナは私一人ですが、そのうち自分よりも信頼できそうな人が出てきたら開発をチーム制に変更しようと考えています。頑張ってください。
お勧め補助ツール
- ドキュメント生成
- global
- コールグラフ生成
- cflow + graphviz + dmd + imagemagick + 連携の為のスクリプト(cflow2graphviz.d )
- コードの整形
Uncrustify 0.45推奨。
uncrustify -c uncrustify.cfg --replace *.c
よく使うコマンド
ダウンロードはコマンドプロンプトでbzr branch lp:nanthyとします。
ソースを改変したら、bzr diffするとファイル間差分が取れます。
bzr ciでローカルなレポジトリにチェックインできたり、bzr diff -rn..mでリビジョン間差分も取れます。
git bisectのbzr版はBazaar Bisect Pluginとしてあるようだが、パッケージが無い様子。
rebaseも別コマンドっぽい。だみだこりゃ。
Wishlist
- ユニットテストの追加
- コードのリファクタリング
よくあるFAQ
- 開発に参加したいのですが
- 歓迎します。まずはlaunchpadにユーザー登録してなければ登録をしてください。その後、ソースコードをbzr経由でダウンロードして、ドキュメントを読んで(注:まだドキュメントの整理もしてないので注意)、直したい箇所/追加したい箇所のバグを探し、なければバグを登録をして、そのバグにパッチを添付してください。そのパッチは私がレビューをし、問題なくなればチェックインを行います。
- Nanthy Development Teamとは?
- メンテナの集まりです。現在は私一人ですが。
- 名前の由来は?
- nazoの頭文字 + anthyから。R.O.Dのナンシー幕張からではありませんが、Nanthyの名は仮の名前なので今後Nancyへの改名もありえます。
- 小さいパッチなんだけど…
- 大歓迎です。特にコーディング規則やコメント周り、DDOC、テストケースの不備などのパッチは是非送ってください。
- オープンソースのプロジェクトの参加は初めてなのですが…
- ffmpegの開発ガイド(英語)やMozillaのコーディングガイド、MozillaのC++ 移植性ガイドを見ておくことをお勧めします。NanthyはC90で書かれているし、使用するライブラリも違うので当てはまらない部分も多いですが、参考になるでしょう。
コンパイルの仕方
libavutilの開発ファイルが必要です。
- autoreconf
- ./configure
- make depend&&make
コーディング/開発規則
この規則は暫定的なものであり、変更する可能性あり。また現在守られてないものも含む。
- C90を使う。
- APIの説明コメントにはDoxygen形式を使う。また、その説明はヘッダ側に書く。
- -Wallでエラーがでないようにする。
- できるだけネストを深くしない。
- 不要な括弧、== NULLなどは消す。
- タブは使わない。スペースは二つ。
- 行は120文字以下。
- キャリッジリターン(CR/\r)は使わない。
- コードのコメントアウトには#if 0を使う。
- マクロよりもインライン関数を積極的に使う。
- GCC以外でもコンパイルできるようにする(__attributeの利用時は場合分けする)。
- 新しい機能を付けるときは必ずテストも追加する。
方針
- うまくいってるモデルを参考にする。
- うまくいく可能性が高いはずだから
- C++は避ける
- 簡潔さの為
- C99は使う
- リーダビリティの確保の為。 デメリット: VCでコンパイル不可?
- なるべく開発が活性なライブラリに依存する
- リソース不足を補うため
問題
- まだeuc-jpなファイルがある。見付け方
- バージョン管理から外して.bzrignoreに追加すべきファイルがあるはず。
- ./anthyをもっと使いやすくすべき。
- quitとterm、どっちが良い? closeにすべき。C99を使ってffmpegのように。
- atorはallocにすべき
- 個人用辞書とそれ以外とが抽象化不足(C99を使ってffmpegのように)。
- libanthydicをlibjadicとしてanthyの冠を外す。
- libanthyutilを分離(for libjadic)
- 書きなおした方が早い予感。ただリグレッションがなぁ。やっぱunittestが先か。unittestのインフラの実装完了。./configure --enable-unittestでどうぞ。実装はanthy/common.hをインクルードしてunittest(ファイル毎に一意のid){}でおk。GNUCのみ対応。
- VCにやさしくする。__force_inlineとか。
- personarityはユーザー名使うべきじゃ?
- structの名前を無くす(typedefのみにする)。あと命名規則を変える(最初を大文字に)。
- コーディング規則がまちまち。
- test/prediction.cが文字化けしてる。
- 実行権限があるファイルがある。test/anthy.c
- DoxygenコメントがついてないAPIがある。
- do-whileの問題。一行の時、括弧無いままでいいか。ある方が好み。
- avuのAVClassとかLZOとか使う。
- (C) vs. (c)
- texttrieに壊れてたら作り直す処理があるが、これはどうなんだろう。
- texttrie/textdictのopenのcreateは常に、読み込み時非作成、書き込み時作成であるべきじゃ?
- textdictはopenのcreateフラグが使われてない。
- 自動学習はもっと効くべき -> カタカナ語以外の単語があまり学習されてないから@last-record1_default
- 辞書の整理
API再考
#define LIBANTHY_VERSION 1.0.0 /**< AnthyのライブラリのAPIのバージョン */
#define LIBANTHY_VERSION_INT ((1<<16)+(0<<8)+0) /**< ditto */
typedef struct{
const char *name; /**< 名前 */
int priv_data_size; /**< priv_dataのサイズ */
int (*init)(AnthyModuleContext *); /**< 初期化関数 */
int (*close)(AnthyModuleContext *); /**< 破棄関数 */
int (*print)(AnthyModuleContext *); /**< 表示関数 */
} AnthyModule;
typedef struct{
int initialized; /**< 初期化されてるか(anthy_create_module_contextでセットされる) */
void *priv_data; /**< モジュール固有のデータ(initでセットされる) */
AnthyLogger *logger; /**< ロガー(anthy_create_module_contextでセットされる) */
} AnthyModuleContext;
AnthyModuleContext *anthy_create_module_context(AnthyModule *module, AnthyLogger *logger);
int anthy_release_module_context(AnthyModuleContext *s);
typedef struct{
xchar *str; //str -> ptr?
int len; //len -> length?
} xstr; //xstr -> AnthyString?
文字コード周りを何とかするべき。
C99にstdbool.hあるけど使う?
まだEUC-JPなファイル
src-splitter/segclass.c
src-splitter/splitter.c
src-util/rkhelper.c
src-worddic/ext_ent.c
test/check.c
src-util/rkhelper.h
src-util/rkmap.h