TStcltk 発言

こんにちは、山本です。

"Keiichi Takahashi <bitwalk@...>"さんは書きました：
> >私と「ほぼ」同じ修正内容ですね。
> >違うのは、channelからISO2022-JPをdecodeするときの
> >変換する長さを約30文字から約20文字に減らしている点です。
> >(ENCODING_LINESIZEを30→20に変更している)
> >これの理由はよく解りません。要らないはずですけど...
> >現象を確認するために減らしたのかな?

> tclIO.c:FilterInputBytes. It has something to do with the value of the
> ENCODING_LINESIZE #define (currently 30). If I bump that up to 60, I can
> read Thomas' sample just fine, and if I drop it to 20, it stops the
> correct encoding translation even earlier per line. That's obviously not
> a correct fix, but it does indicate that FilterInputBytes isn't encoding
> right. I'll have to look into this more when it's not past midnight ..."
> 
> とあるように、いろいろテストしているようですね。

この文章では、
20に減らしてテストした後、元に戻し忘れただけのように読めますね。

今CVSからcore-8-3-1-branchを取り直していたのですが、ChangeLogに

    Also reduced the value of ENCODING_LINESIZE from 30 to 20 as this
    seems to improve the performance of 'gets' according to tclbench.

と、書かれていました。でも、readable channelから一度に読み込む量を
減らしたのですから、単純にループ回数が増えて性能が悪くなるはずです。
...で、tclIO.c(core-8-3-1-branch版)を見てみると、
#define ENCODING_LINESIZE   50
と、今度は増えていたり(笑)。
午前中、誤って8.4版を取ったときは
確かに20になっていたんですけど(笑)。

> ># って、よく見てみると523988.patchってMarch 1に修正!?
> ># なんとまあ、タイミングが良いというか悪いというか。
> >
> 
> そうです。まさにホットな話題だったのです（正確には2月末の話題です）。

バグそのものは昨年から知っていましたが、
先週の半ば頃から急にこのバグを修正したい気持ちになってきて、
昨夜突然狂ったようにデバッグを開始して修正方法を見つけました。
当然、この話題が持ち上がっていたことは知りません。
# これって電波? いやそんなはずは??

> Jeff氏によれば、8.4の正式リリースまでにはこの手の問題をしっかり解決した
> いということですので、この機に乗ずればこちらの改善要求もすんなり通るよう
> な気がします。 :-)

ChangeLogとencodingパッケージを確認したところ、
iso2022(-jp).encのエスケープシーケンスも修正されていました。
残るは、RFC1468の規約違反の修正、つまり田口さんのパッチを
適用して、encoding.testの結果内容を修正すれば、
現時点で判明しているISO2022-JP関連のバグは全てfixできそうです。

--
Koichi Yamamoto, 
http://www3.ocn.ne.jp/~yamako/