Masanari Yamamoto
h0131****@ice*****
2005年 8月 18日 (木) 13:43:12 JST
山本です。 徳永さん、おもてさんありがとうございます。 On Thu, Aug 18, 2005 at 09:45:48AM +0900, Masahito Omote wrote: > おもてです。 > > On Thu, 18 Aug 2005 04:51:02 +0900 > TOKUNAGA Hiroyuki <tkng****@xem*****> wrote: > > > > その部分のコードは以下のようになっています。 > > > lenやbufを使っていないのでRkGetKanjiを呼ぶ意味がないような気がするので > > > すが、ここでRkGetKanjiを呼ばないといけない理由があるのでしょうか。 > > > > > > for (i = 0; i <= tmp_segment_num; i++) { > > > int len; > > > RkGoTo(cc->rk_context_id, i); > > > len = RkGetKanji(cc->rk_context_id, (unsigned char *)buf, BUFSIZE); > > > #ifdef UIM_CANNA_DEBUG > > > printf("segment: %d, buf: %s\n", i, buf); > > > #endif > > > } > > > > たしかにRkGetKanjiを呼ぶ必要は無さそう…というか、単にdebug目的で呼んでい > > るように見えますね。しばらく使ってみた感じでは問題なさげなので、そんな感 > > じでtrunkにコミットしちゃっていいんじゃないかと思います。 > > > > # なにか問題があったらrevertして下さい > 表さん > >コードを見直してみましたが、debug目的で各文節ごとに漢字をprintfで出力している >だけみたいなのでforのところ全体を#ifdefで囲ってしまってOKです。 >それと_update_statusをcallしているのは_update_segmentだけなのでこの2つの >関数を統合してしまってもいいかな。 _update_statusと_update_segmentを統合して、_update_statusの中で全セグ メントの候補数を取得するようにし、_update_statusをbegin_conversionと resize_segmentでしか呼ばないようにしたところ、変換が倍ぐらいの速さにな りました。 > ただ、Cannaでは変換が遅くなる現象は実装した当初から確認していないので、これで > 症状が改善しないのであればimeproxyの実装にも問題があるのではないかと考えてい > ます。 サーバにcygwinのcannaserverを使ったところimeproxyと同じくらい時間がか かりました。imeproxyが原因ではなく、ネットワークで時間がかかるようです。 > uim-cannaの実装をマトモにするのであればRk系APIを使うのではなくてjrKanjiControl > とjrKanjiStringを使って実装しなおすべきです。ただし、その場合preedit層がuimから > Canna側に移るのでcanna.scm, canna.cの大幅な書き換えが必要になりますが。 jrKanjiStringとjrKanjiControlを使えば、他のcannaクライアントと同じよう になり、Rk系APIを使えば、uimの他のIMと同じようになりますね。僕は今のま までいいと思います。 -- 山本将也
