Not only is the Internet dead, it's starting to smell really bad.:2004年07月中旬

2004/07/11(Sun)

(ry

@私事ですが

本業もMilestone越えて消火、普通の生活に戻れそうです。
ぼちぼち*BSDいぢりも再開かと。

@嘘を嘘と(ry

メール送っても450 Temporary failureで帰ってきてしまうので、2chで延々マジレス。
http://pc5.2ch.net/test/read.cgi/unix/985675477/196-

196 :itojun :04/07/09 13:50
    citrusをOpenBSD-currentに入れる作業が進行中ですが、__RENAME()がないとかその他いいろな理由で進んでいません。もしcitrus patch(ちゃんとうごくやつ)を隠し持っているひとがいたら是非お送りください。

197 :名無しさん@お腹いっぱい。 :04/07/10 13:32
    神光臨?

198 :190 (1/1) :04/07/11 21:26
    >>196
    どのへんが merge の障害なのか、議論のポインタを知らないので
    役に立つかどうかは判りませんが、↓こちらに置きました。

    http://sigsegv.s25.xrea.com/distfiles/citrus/OpenBSD/HEAD-citrus-20040710.tar.bz2

    最新(2004/07/10) の OpenBSD / NetBSD 両 HEAD branchに同期済です。i386で
    full buildが通ることと、昔のCitrus CVS repositoryにあったtest1, test2で
    NetBSD-currentと結果の相違が無いことを確認してあります。

    NetBSD から mergeしきれていないのは
    1. usr.bin/locale
    stringlist.h が無い、sys/queue.hなり使って書き直す必要あり。
    2. wcsto(u)imax(3)
    (u)intmax_tが無い、inttypes.h とか、c99 回りが整ってからでいいような。
    くらいですかね。

199 :190 (2/3) :04/07/11 21:27
    この tar.bz2 には patch が2つ含まれます。 citrus.patch の方がメインで
    kevlo AT openbsd DOT org 氏 (ttp://www.kevlo.org/citrus/index.html)
    や
    kurati 氏 (ttp://www.nurs.or.jp/~kurari/bsd/index.html)
    が作成されてるモノと(__RENAME()とか__SETLOCALE_SOURCE__の扱い以外)
    あんまり変わらないはず。

    ただ↑だけでは binary compatibility 上
    1. MB_LEN_MAX 1 -> 32
    2. sys_{nerr,errlist} (EILSEQが追加になるので)
    という問題が残りますので、対策として rename.patch を用意してあります。

    rename.patch は NetBSD から __RENAME() を lint(1) への hack 含め、
    一式貰ってくるという乱暴な方法なので、
    OpenBSD 的にはそれはOKなのかちょっと疑問です(だから役に立ちそうもない)。

    そもそもOpenBSD って結構頻繁に libc の major version が上がるのですけど、
    citrus を import したタイミングで bump up できないのでしょうか?
    それなら __RENAME() を持ってきたりする必要はないので、
    citrus.patch を merge するだけで終りという認識なのですが。

200 :190 (3/3) :04/07/11 21:29
    それから、dlopen(3) はあんまり OpenBSD 的に好まれない気がするので、
    locale module を dynamic loading するのでなく、libc に抱え込む
    compile option (CITRUS_BUILD_LOADABLE_MODULE={yes,no}) が
    citrus.patchには含まれています。
    src/libc/citrus/citrus_module_data.h 辺りのファイルが追加になってます。

    もし他に私が見落としている merge への blocker 等ありましたら
    ご指摘下さい。

つか、本物のitojunさんなんでしょうかね(苦藁

2004/07/12(Mon)

@Citrus/OpenBSD

http://pc5.2ch.net/test/read.cgi/unix/985675477/201-
いやはや、ちゃんとテストしないと駄目ですね。
regress/libc/localeをもっと充実させますかぁ。

@multibyte regex?

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/regex/regcomp.c
えっと、UTF-8以外は動かないのかな?

2004/07/13(Tue)

(ry

@FreeBSD rune

FreeBSDではtowctransの内部がliner searchからbinary searchに変更されてた↓ので
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/locale/runetype.c
追従↓してみたんだけど、そもそもusr.bin/mklocaleってorderedでLC_CTYPEを作ってたっけかな。
/distfiles/citrus/NetBSD/05_ctype-cleanup.patch
tjr大丈夫だよね?

UTF-8くらいになると確実にbsearchの方が早いんだけど、
ja_JP.eucJPとか検索量が少ないlocaleは逆に性能落ち気味なので
VARIABLEで切替え可能にする方がいいのかねぇ。

2004/07/17(Sat)

(ry

@en_US.UTF-8.src

FreeBSDと同期。
/distfiles/citrus/NetBSD/06_utf8-fix.patch
サイズは89k。

2004/07/18(Sun)

(ry

@CNS11643-1

http://www.unicode.org/charts/PDF/U2F00.pdf
http://www.cns11643.gov.tw/web/show_seek8.jsp?start=10017&end=10553&stroke=&page=1
を比較するとU+2F23が抜けているのは何故?
そもそも部首についてCNSはUCSへの変換テーブル掲載してないし。

@wctype linear search -> binary search

偏ったデータでなしに、青空文庫からひろってきたテキストを使って測定してみると、
EUC-JPやSJISでも僅かながら性能は向上してますな。
UTF-8だと差は歴然。
singlebyte localeでは_NBRuneLocale->rl_{runetype, maplower, mapupper}が使われるので、
この変更の影響は受けない訳だし、OKかな。

@vfwscanf(3)

vfscanfの%lc(%C)とか%ls(%S)対応をやっててふと
http://www.haun.org/ml/b-l-j/a/100/111.html
「バイト系関数とワイド系関数の混在利用を制限」を思い出したんだけど

char c;
wchar_t wc;

setlocale(LC_CTYPE, "ja_JP.SJIS");
wscanf("%c %C", &c, &wc);

みたいなケースでは、

  %c  →  fgetc(stdin)
  %C  →  fgetwc(stdin)

(あるいは同等の処理)が内部で動くので、formatの書き方ひとつで
「バイト系関数とワイド系関数の混在利用」が発生しそうなんだけど。

上のコードでstdinに { 0x82, 0xA0, 0x82, 0xA2 }というbyte sequenceを喰わすと

  1. c = 0x82, wc = EILSEQ(0xA082)
  2. c = 0x82, wc = 0x82A2

のどっちが正しいんでしょうか。

ちなみにFreeBSDのvfwscanf()は%cであってもfgetwc()が使われるので後者。
漏れは前者が正しいような気がするんだけど。。。

@ungetwc(3)

/diary/?20040118#18-1-1
/diary/?20040123#23-1-1
↑の問題については「混在利用する香具師が悪い」でいいのか。

でもさ、やっぱり戻せないと

FILE *fp;
wchar_t wc;
size_t n;
...
ungetwc(L'あ', fp);
fwscanf(fp, "%C %n", &wc, &n);


というコードで、nはいくつになるか判らんという事態になるのよね。