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

2008/05/10(Sat)

[NetBSD] ThinkPad s30 + piixpcib(4)

うーむpiixpcib(4)で凍るようになっちまってますやね。
r1.15でdevice_t化される前はvesafb(4)でvga_is_console()で落ちるのを
回避すれば動いてたんだけど。

dmesg見る限りspeedstep_configure()まで進んでないのね。
多分vga_is_console()と同件で、どっかでメモリ破壊起きてて
device_private()から壊れたsoftcが返されてしまい
pcibattach()内で落ちてるととりあえず予想してみる。

違った、speedstep_configure()まで動いてて最後、"SpeedStep SMI enabled"を
aprint_verbose_dev()で出力する時、何故かsc->sc_devがNULLになっとるせいで
刺さってる模様、うーむ。

[NetBSD] 続 ThinkPad s30 + piixpcib(4)

piixpcib(4)はattach()時にgenericなpicb(4)のattach()を呼ぶのだけども
piixpcib_softcと src/sys/arch/x86/pci/pcib.cの方のpcib_softcの
構造体って互換性無くなっちまってるな、これが原因臭。

[NetBSD] ThinkPad s30 + piixpcib(4) その3

あんまりキレイなやりかたじゃないけど、いちおpatch。

Index: sys/arch/x86/pci/pcib.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/pci/pcib.c,v
retrieving revision 1.4
diff -u -r1.4 pcib.c
--- sys/arch/x86/pci/pcib.c	28 Apr 2008 20:23:40 -0000	1.4
+++ sys/arch/x86/pci/pcib.c	10 May 2008 11:49:53 -0000
@@ -49,6 +49,8 @@
 #include "isa.h"
 
 struct pcib_softc {
+	device_t		sc_dev;
+
 	pci_chipset_tag_t	sc_pc;
 	pcitag_t		sc_tag;
 };
@@ -202,6 +204,7 @@
 	aprint_normal_dev(self, "%s (rev. 0x%02x)\n", devinfo,
 	    PCI_REVISION(pa->pa_class));
 
+	sc->sc_dev = self;
 	sc->sc_pc = pa->pa_pc;
 	sc->sc_tag = pa->pa_tag;
 

本当はpiixpcib.cの方を直すべきなんだろけど。
vga_is_console()で落ちる件も調べた後にでもsend-prすっか。

[NetBSD] ThinkPad s30 + piixpcib(4) その4

vga_is_console問題は再現しなかったのでsend-prしてきた。
でもpiixpcib_softcからpcib_softcへの変換がcastってダサくね?
今回のバグってJavaで書くなら

class A {
   ...
}
class B extend A {
   ...
}

A a;
B b;
a = (A)b;

のように、class A(=pcib)とその派生class B(=piixpcib)という
関係をCで実装するのに

struct A {
    ...
} *a;
struct B {
    ...
} *b;

a = (struct A *)b;

と書いた挙句、仕様変更時にAに追加したメンバを
Bに追加し忘れますた、ちゅーことなのだよね。

やっぱCならこうHAS-Aで書いた方が安全だよな。

struct A {
   ...
} *a;
struct B {
    struct A super;
    ...
} *b;

a = &b->super;
a = (struct A *)b; /* 全くお勧めしないけどこれでも動く */

softc構造体は各bus間ではdevice_tというopaque objectで
実装を隠蔽してるんだけども、piixpcibとpcibは隠蔽するような関係じゃないとオモ。

[NetBSD] multi-locale その5

newlocale(3)のcategory_maskの実装について。

これまでのsetlocale(3)だと

setlocale(LC_ALL, "");
setlocale(LC_CTYPE, "");

のように、全てのカテゴリあるいはどれか1つを指定するのだけど
newlocale(3)では

newlocale(LC_ALL_MASK, "", base);
newlocale(LC_COLLATE_MASK|LC_CTYPE_MASK, "", base);

のようにOR使って細かく指定できるようになったのよな。

んでsetlocale(3)のidentifierって実装依存なのだがNetBSDの場合

$ cat >test.c
#include <locale.h>
#include <stdio.h>
main()
{
    setlocale(LC_ALL, "C/ja_JP.eucJP/C/C/C/C");
    printf("%s\n", setlocale(LC_ALL,  NULL));
}
^D
$ make test
$ ./test
C/ja_JP.eucJP/C/C/C/C

のよに、LC_ALLの場合はスラッシュ区切りで各カテゴリを
設定/表示する仕様なのだけども、multil-localeではORが使えるので

printf("%s\n", querylocale(LC_COLLATE_MASK|LC_CTYPE_MASK, locale));

とかした場合、どういう結果が返るのがいいのかね。

C/ja_JP.eucJP

のよに、指定されたcategoryだけを設定 or 表示すると判りづらいよな。

glibc2の場合はsetlocale(3)のコードを実行すると

LC_CTYPE=ja_JP.eucJP;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C

となるけど、querylocale(3)はglibc2にはにゃいので結果が判らん。

TODO: MacOS Xのquerylocale(3)がどういう結果を返すか、調べに電器屋へいくこと。
うちのDuo230にTiger入んねぇかな。

2008/05/11(Sun)

[i18n] message catalog

悪意のある言語パック

前もちらっと書いたけど、悪意のある翻訳者対策って厄介だよな。
ワシがなんとか理解できる日本語と英語だって、ねこだいすき縦読みにアナグラムに
slangスラングを駆使して一件まともな訳文に見えて、その実まったく別の意味だったりすると
チェック洩れる可能性があるからねぇ。
one-shot translationなんてのはrelengの問題で片付くけど、査読は
信頼できる人間が各言語毎に最低2人はいて、クロスチェックしてもらわんと
ずぇーったい無理だ罠。

週末

雨降ると寒いねぇ。
いつもなら暖をとりに膝に飛び乗ってくる奴がいないのがさみしい。
ネコいないのでベランダに鳩が居座ってグルッポ鳴いてる。

ネコ最後の日の写真が現像上がり。
歩くのもやっとなのに猫草をなんとか口にしようと病に立ち向かう姿。

先日入手したばかりのAF28-75mm/F2.8(D)の後玉に傷つけちまったんで
ソニーのコニミノ修理窓口に送付。

お散歩用カメラにハーフが欲しかったのでOLYMPUS-PEN EEDをげと。
外観わりと綺麗でレンズにファインダーもカビのない個体で
570円は安いよな、まあこの機種はPENの中でも特に人気なさそうだけど。
cdsがちと劣化気味のようでシャッター速度遅い奇ガス、調整必要かもね。

[i18n] message catalog (追記)

悪意のある言語パックというより、汚染された言語パックとゆー話らしい。
まとめ参照。

あと2chの某スレのよーに「翻訳は有害」なんてアレな主張をしてるわけじゃないことに注意。
ソースならC言語に精通してるdeveloperは山ほどいてクロスチェック盛んだけど
翻訳の場合、複数の言語に精通してる人間はこの界隈には数少なく貴重だとゆー話。

CSI xterm

LANG=ja_JP.UTF-8で起動しようとするとBadFontでコケるのか。
/usr/X11R6/lib/X11/locale/ja_JP.eucJP/XLC_LOCALEでのXLC_FONTSETで
指定されてる文字集合は全部XTerm*FontSetに指定してあるのだけど。

RELNOTE-I18N読むとXlib-I18N入れろとあるのだけど、cvs repositoryが消えとる。
昔checkoutして固めといた奴も見当たらん、げげげ。

続 CSI xterm + Xlib-I18N

確かKondara LinuxがXlib-I18Nをmergeしとったっけなと突然思い出すものの
kondara.org見事に消えとるしミラーサイトも消滅しとるな。

rpm searchでXFree86-4.0.2-0.2li18nux.nosrc.rpm ちゅうものをハッケソ。
nosrcかよ!でぐんにょり。

specみるとXlib-I18N-cvs-20010129.tar.bz2ちゅうのがどっかあるはず。
ちかごろはarchie gateway消滅してて世の中退化しちょる。

要はXFree86-4.2.0でXlib-I18Nは完全に統合されたのかどーかをチェックしたいんだが
XFree86のxc/lib/X11/xlibi18nのlog読んでもいまいち要領を得ない。

しゃぁねぇ、真面目にCSI xtermのソース読むか...

2008/05/12(Mon)

[NetBSD] multi-locale その6

glibc2のLC_ALL_MASKって将来的にlocale categoryを追加する場合
ばっちり後方互換が失われる悪寒。

# define LC_ALL_MASK	(LC_CTYPE_MASK \
			 | LC_NUMERIC_MASK \
			 | LC_TIME_MASK \
			 | LC_COLLATE_MASK \
			 | LC_MONETARY_MASK \
			 | LC_MESSAGES_MASK \
			 | LC_PAPER_MASK \
			 | LC_NAME_MASK \
			 | LC_ADDRESS_MASK \
			 | LC_TELEPHONE_MASK \
			 | LC_MEASUREMENT_MASK \
			 | LC_IDENTIFICATION_MASK \
			 )

新しいカテゴリ追加すると、定数値であるLC_ALL_MASKの値が変わってしまうやね。
# まあこれ以上追加する必要ががあるかどーかわ知らん。
あっちはELF symbol versioningあるし気楽なのだろう。

つーわけでこっちの実装は

#define LC_ALL_MASK	((int)~0)

とでもしとくけ。

昨日

OLYMPUS-PEN EEDの試写を兼ねて、そこいらブラブラ。

国立病院の駐車場横の林、リスが突然目の前横切って驚いた。
こんなちょっぴりのスペースで生活していけるのだろうか。

某パチョコン量販店でMacOS X、漢字Talkwwwwを触ったことがある程度なので使い方ワカンネ。
つか普通XCodeなんて店頭にあるマシンにゃ入ってない希ガス。

急に吐き気と眩暈で立ってられなくなる、先々週と同一のバグっぽいので運用で対処。

ねこに仏花買おと思ったらJ( 'ー`)しカーチャンの日トラップで売ってねぇ。
しょうがないのでヤツの生まれ故郷の諏訪の酒買ってお供え。

2008/05/13(Tue)

TODOs

近日中に済ましとけーな作業

昨日

某楽器店、HOHNER Pianet-Tが値下げしてたけど10万円って。
つかオク相場だと5万がいいとこだから当分売れ残りそうだな。

花屋、クリスマス翌日のケーキ屋的様相を呈してた。

人民解放軍が迷彩服を着てるとガッカリする香具師は
Solid State Survivor / YMO 聴いてたオサーン。

ロシア的倒置法、中華人民共和国では 錻力の太鼓 が Japan を叩く!
そうかだから反n(以下略

ギュンター・グラスの小説の方はジャガイモ畑で早々に挫折した俺。

This ain't rock`n'roll, This is DOMESTIC PROBLEM!
    - ``Diamond Dogs'' by David Bowie

出火吐暴威って 珍マシーンTin Machine以降、過去曲封印したままだと思ってたんだが
最近はふつーに演奏ってんのな、ちゅうか VitteleのCM 感動した。

へーVistaの起動音ってRobert Frippなんだ、いーのー。
昔「太陽とシスコはロックシティ & 戦慄」というバンド名を考えたのだがボツ食らった。

2008/05/14(Wed)

昨日

フジ110フィルム終了
Pocket Instamaticってやつだけども、後はコダがいつまで作り続けるかだな。
まぁ Ferraniaもあるけど。

むしろこれの先祖の126フィルム、Instamaticの方が
正方形フォーマットちゅーことで魅力なのだけど
こっちはFerraniaと ADOXが生産してるのみで、日本だと入手困難ですな。

今週末からからドキュメンタリー映画「 JOY DIVISION」っすな、渋谷の初日とか行くと
学生時代のサークルのメンツと遭遇しまくりんぐな予感、回避すっか。
いい年こいてコピバン再結成とかエロ過ぎる。

うちのギターは最近他所でジザメリ直系シューゲイザーバンドをはじめたらすい。
ベンチャーズ直系テケテケバンドをやるのと同じ老化現象ですね、わかります。

中古CDフェア@川崎。
David BowieのRykodisc盤探したのだけど収穫harvestなし。

蜘蛛の名前ならミック・ロンソンだろJK、だがしかし ニール・ヤング
次のバンドは「ニール・ぺ・ヤング & グレイシー柔術」と「黒過ぎーステルス(以下略

カレー臭漂ってまいりますた。

[NetBSD] multi-locale その7

newlocale/duplocale/freelocale/querylocaleの実装中。
やっぱDistributed I18N Frameworkの方が設計まとも。
glibc2はがんばりましょうの判子押してやりてぇ。

2008/05/15(Thu)

[NetBSD] multi-locale その8

querylocale(3)の戻り値は、結局"/"区切りのままにしといた。
uselocale(3)はThread Local Storage必須なのでいまんとこ常時ヌルポ返却。

FreeBSDのlink loaderから

をパチってくるだけの簡単なお仕事です。
素人歓迎、委細面談

MacOS Xの man querylocaleを読むとmaskのbit操作順は
カテゴリ名でalphabetical orderとあるのだが、NetBSD的には
歴史的な事情(LC_MESSAGESが 後から追加された)があるので
あくまで

LC_COLLATE -> LC_CTYPE -> LC_MONETARY -> LC_NUMERIC -> LC_TIME -> LC_MESSAGES

とゆー順序のままにしといた。

これFreeBSDでも 事情は一緒なはずなんだがな、MacOS Xで変更したのだろか。

ちなみに

setlocale(LC_ALL, "");
setlocale(LC_ALL, NULL);

以外、つまり

setlocale(LC_ALL, "ja_JP.eucJP");
setlocale(LC_ALL, "Japanese_Japan.932");

とか環境変数LC_ALLを使わずに、直接idを指定した場合
そのソースコードは移植性無いのだけども、multi-localeを使う場合ってのは
当然環境変数とは異なるidを指定したい訳で、OSごとにifdefするなり
設定ファイルに追い出すなりの仕掛けが必要になっちまうのよな。
これは非常にめんどい。

いちお LI18NUX Locale Name Guidelineとして実装依存ではなく共通化する動きはあったけど
非Linux方面にはサクっと無視された記憶。
ところでNetBSDでlocale名のloose matchingを実装して欲しい人いるんかな。

あと これ、 idの先頭が/だった場合はpathnameとするなんて仕様もあったのか。
とりあえず放置。

根本的にPOSIX localeの設計自体が筋悪なのだよな。
カテゴリごとに別々のlocaleをセット可能とか。

なんて場合は

LC_CTYPE=ja_JP.eucJP
LC_TIME=C
export LC_CTYPE LC_TIME

とするのだけど、本来これはmulti-localeで処理すべきことなのよな。

なもんで、今の仕様だと

LC_CTYPE=ru_SU.KOI8-R
LC_COLLATE=ja_JP.eucJP
export LC_CTYPE LC_COLLATE

ソヴィエトロシアでは日本語がロシア語のソート順を規定する!
LC_CTYPEがru_SU.KOI8-Rなので、wchar_tの内部表現はKOI8-Rなのに
wchar_tの内部表現がeucJPであることを仮定したcollation order logicが動くという
アレなことになってしまう。

Javaなんかは後発なだけあって当初からmulti-locale設計なのだが
java.util.Localeにはカテゴリなんて概念はなくて 物知りモノリシックなわけだし。

Java(TM)ではjava.text.*FormatしてからSystem.out.printlnする!
理由のひとつはmulti-localeなのだが、Java5では
java.io.PrintStream.printf()なんてぐんにょりするの入ったくらいだし
仕様決めてる人たちももういろいろ忘れてるんだろう、糖衣構文マンセー。

Cの場合、文字列は自身の文字コード情報を持ってないので(JavaはUTF-16 hardwired char)
文字列とlocale_tの組み合わせはユーザ管理になるから非常にややこしいのが難点。
その一点だけはCERT Managed String(=string_m)のembedded locale info羨ましい。

話戻して、POSIX localeのの筋の悪さを考慮しないままmulti-locale化しようとしてるのは
TOG(=Distributed I18N Framework)もglibc2(=Thead Aware Locale Extension)も
一緒なんだが、LC_*_MASKとか導入して更なるgdgdを呼び込む後者の方が度し難い。

昨日

AIWA終了、逆に考えるんだAIWAがSONYを(以下略
現SONY元コニミノのαボディ設計者は予算が増えて喜んでるらしいけど。
つうかコニミノ時代の製品はどんだけ腹ぺコの中で(以下略

某スレ、やっぱThinkPad s30のauich(4)って-currentだと音出ないのだな。
2chの*BSD/ThinkPadスレ見ると少なくとも2002年までは 音出てたみたいだぬ。

2008/05/16(Fri)

[i18n] setlocale(3) で指定するロケール名の移植性

kbkさんとこ。
setlocale(3)でどうやって

を文字列にして指定するかは、 仕様では決まってないのですよ。

The locale argument is a pointer to a character string containing the required
setting of category. The contents of this string are implementation-defined.

とある通り、"C", "POSIX", "", NULL以外は実装依存です。

まあUnix方面だと

言語 + "_" + 地域 + "." 文字符号化手法 ( + "@" おまけ)

というフォーマットで

となってる実装が多いのですが
これHTTPのAccept-Languageのように、 RFC4646 Tags for Identifying Languages
の仕様で縛られてる訳ではないです(そもそも言語タグだと"_"じゃなくて"-"ですな)。
混同されてる方は要注意。

さらに文字符号化手法については

と、まあ表記の揺れが激しいわけです、glibc2ではloose matchingとか導入したくらいで。

HTTPのAccept-CharsetはいちおIANA charset registry縛りがあるのだったっけ?
あれはPOSIX localeには何の強制もないですし、そもそも

setlocale(LC_ALL, "ja_JP.Extended_UNIX_Code_Packed_Format_for_Japanese");

なんて嫌すぐる *1

それと、複数のカテゴリをいっぺんにsetlocale(3)に指定する場合も
やりかたは実装によってバラバラです、いくつか確認してみましょ。

Solarisの場合

$ cat >hoge.c
#include <locale.h>
#include <stdio.h>
#if defined(_WIN32)
#define JPLOCALE "Japanese_Japan.932"
#elif defined(__linux__)
#define JPLOCALE "ja_JP.EUC-JP"
#else
#define JPLOCALE "ja_JP.eucJP"
#endif
main(void)
{
	setlocale(LC_ALL, "C");
	setlocale(LC_CTYPE, JPLOCALE);
	printf("%s\n", setlocale(LC_ALL, NULL));	
}
^D
$ make hoge
cc -o hoge hoge.c
$ ./hoge
/ja_JP.eucJP/C/C/C/C/C

各カテゴリをスラッシュ区切りで表示します(順序はLC_*の定数値の小さい方から)。
なのですが、"/"ではじまる場合はpathnameと解釈するちゅう仕様に反してる気が。
つかそもそもスラッシュ区切りだと、LC_ALLの場合pathnameが使えなくなりますな。

/usr/local/share/locale/ww_WW.wwwWW/LC_COLLATE;/usr/local/share/locale/ww_WW.wwwWW/LC_CTYPE;...

とか、せめて;とか:なんかにしとけばよかったのに。

glibc2の場合は

$ ./hoge
LC_CTYPE=ja_JP.EUC-JP;LC_NUMERIC=C;...

となります、これはこれでウザい(注:単に個人差です)。

われらがNetBSDは↓になってます、FreeBSDが4.4BSD runeを拡張したコードが元ネタ。

$ ./hoge
C/ja_JP.eucJP/C/C/C/C

Solarisと似てますが、先頭が"/"ではじまる場合はpathnameと解釈するPOSIX仕様とはいちお整合性あります。
まあLC_ALLの場合pathname使えないのはSolarisと一緒です(汗)。

んで最後、MSVCはglibc2と一緒っすね。

C:\> hoge.exe
LC_COLLATE=C;LC_CTYPE=Japanese_Japan.932;...

んで気づいてしまったのだけど これ、将来的にカテゴリを追加する( ISO/IEC TR 14652にはある)
場合を考えると、カテゴリが足りない場合エラーになる今のNetBSD setlocale(3)の
実装では glibc2のLC_*_MASK問題と同様に、やっぱりバイナリの後方互換性失われるのよなぁ。
仕様にopaqueとは書かれてないので、移植性を諦めさえすれば
ハードコードすることは別に禁じられてないし…うーむ頭痛い。
どーせ互換性無くなるならglibc2/MSVC風の方がキモイけどリーズナブル。

この問題の別解として

setlocale(LC_ALL, "ja_JP.eucJP");

として、LC_ALLを指定した場合は全部同じロケールをセットすること以外は
禁止してしまえばいいようにも思えるのだけど

char *tmp, *s;

setlocale(LC_ALL, "C");
setlocale(LC_CTYPE, "ja_JP.eucJP");
...
tmp = setlocale(LC_ALL, NULL);
s = strdup(tmp); /* save current locale */
...
setlocale(LC_ALL, s); /* restore previous locale */
free(s);

というcurrent localeのsave/restoreを行うコードが動作しなくなっちまうよな。

まあアプリ側はそもそも この通り

そもそも、/ で区切る指定ができるということを POSIX その他は
全く規定していないですし、そういうことをやりたい人は LC_xxx で
明示的に指定するべきでしょう。

なのよな。

つーわけでパラノイアなアプリ実装者は、とことん安全側に倒して

char *tmp, *collate, *ctype, ...;

setlocale(LC_ALL, "C");
setlocale(LC_CTYPE, "ja_JP.eucJP");
...
tmp = setlocale(LC_COLLATE, NULL);
collate = strdup(tmp); /* save current LC_COLLATE */
tmp = setlocale(LC_CTYPE, NULL);
ctype = strdup(tmp); /* save current LC_CTYPE */
...

setlocale(LC_COLLATE, collate); /* restore previous LC_COLLATE */
setlocale(LC_CTYPE, ctype); /* restore previous LC_CTYPE */
free(collate);
free(ctype);
...

とした方がいいかもしれない、save/restore目的にはLC_ALLは使うなと。
ああ、やっぱりPOSIX localeは設計が腐(以下略

あと XFree86/xorg のlocale.aliasにある

POSIX-UTF2                                      C

なんじゃこれ(UTF2ってのはUTF-8の古い名前ね)。

いちお ではC/POSIX localeのnl_langinfo(CODESET)がUTF-8でも構わない *2のだけど
XFree86/xorgがこのaliasをつけちゃうのは、あんまりよろしくない。

*1:NetBSDの場合、実装の都合上ロケール名は32byteまでだったり。
*2:これ、えんがちょの理由はUTF-8だからではなく、わざわざUCS2までの限定サポートにしてること。

[NetBSD] multi-locale その9

uselocale(3)、Thread Local Storage無しでもerrnoみたいにlibpthread側で実装すりゃいいのだが
そもそもC++(=libstdc++)のmulti-localeを使いもんになるようにしよーぜ
ちゅー消極的な目的の為だけににlibpthreadなんぞ弄りたくないんだよな。
でもsrc/gnu/dist/gcc4/libstdc++-v3/config/locale/gnu以下をgrepするとワラワラと。
よく読んでない(読みたくない)けど、__gnu_cxx::__uselocale使えば逃げられるのかな。

それにしてもC++0xはもはやなにがなんだかワカンネ。
0xは200x年の意味じゃなくて、 エクストリームな気がしてきた。

2008/05/17(Sat)

[NetBSD] nvi-1.81.6

src/dist/nvi なんて入ったな、Berkley DB 3だかのライセンス問題は
dist行きにすることで回避ちゅうことか。

まだimportされただけなので、相変わらず/usr/bin/viは1.79。
なのでpkgsrc/editors/nviの方を入れてみる。
したらpkgsrc/editors/nvi-m17nが上書きされてもた、CONFLICT指定要るな。

1.81.6はwcurses使うって事はCSIなのね。
UTF-8のテキスト編集するにはLANG=ja_JP.UTF-8で
xtermとnvi起動すりゃいいんだけど
うちのCSI xtermはUTF-8ロケールでBadFontでコケる件解決してないんだな。

とりあえずja_JP.eucJPロケールで動かしてみる。
なんかカーソル位置が変だなこりゃ。
wcursesが悪いのかnviが悪いのか、端末側の問題ではないっぽ。

debian openssl problem

ディルバートwwwワロタ。

以前NetBSDでも Covertyで指摘されたcvs(1)のメモリリーク問題を 修正した時
エンバグして壊したなそういや、まあ大したバグじゃないけど。
bin/34030参照。

こういうツールでないと発見できないようなリークはイコール
人がパッと読んで指摘できないリークなわけで、要は パスタ(笑)スパゲッティなのですよ。
下手に直してエンバグするよりは放置した方がマシだったってケースは
私のよに最下流SIで生きてると何度もあって骨身に染みるという。

とかいいながらbin/34030で俺もエンバグさせてるんだけど、どんだけwww

ツールは便利だし積極的に使うべきなんだけど *1
これは古墳の壁のここにカビ生えてますよ、って教えてくれるだけ。
カビが今後どのように成長するかとか、補修の可否までは教えてくれないってこと。
下手うてば当然高松塚(以下略

*1:フィクションですが、株価低迷で自社株買い走ってもなお下がるなら
Covertyでも買ってすこしは品質を上げて、ユーザから怒られる回数を
減らした方がなんぼかマシだとおも。

[NetBSD] 続 nvi-1.81.6

LANG=ja_JP.ISO2022-JPで動かねぇ *1

common/conv.cあたりをチラ読みすると、iconv_open(3)に"WCHAR_T"とか
アレな指定してるみたいなんだが、いつものGNU libiconvが正義パターン?
まいった、こんなんならTraditional viの方がまだマシだ…

*1:XFree86だとlocale not supported by Xlibになるので、ja_JP.ISO-2022-JPを
/usr/share/locale/locale.aliasに追加すべし。

[NetBSD] pkgsrc/x11/gtk2

gtk-query-immodules-2.0、非UTF-8なmultibyte localeでmemory fault。
「UTF-8!出た!UTF-8出た!得意技!UTF-8出た!UTF-8!これ!UTF-8出たよ~~!」
俺は限界だと思った。

2008/05/18(Sun)

週末

元横浜ドリームランド跡地の 俣野公園ぶらぶら。

うまいこと遊園地時代のケヤキやクスノキを残したもんだ。
おかげでずーと古くからある公園のようでとても落ち着く。
横浜市環境創造局GJ、いや単に野球場に取られて予算がないのかもしれんが。

敷地の半分は墓地、当初は根強い反対があったみたいだけど
完成してみると広い芝生に小さな墓銘碑がならぶ洋風の墓園で、明るく違和感がない。
寺が狭い敷地に日本式のあの威圧感ばりばりのおどろおどろしい墓石を
所狭しと並べる時代はもう終わりでいいとオモタ。

春日神社の鹿と遊ぶ、公園が整備されたんだし奈良みたいに放し飼いもいいな
...と思ったが、鹿せんべいは飲物ですが何か? ちゅー旺盛な食欲に恐怖。
樹木が全部やられてしまうので無理ですな。

横浜薬科大の裏を抜けて山を下る、このへんはゴミが非常に多い。
元々遊園地とゲーセンちゅーアドレナリン系施設だったしな。
樹木豊かな公園のよなチルアウト系施設に変わったことで落差が目立つ。

俣野神社、建物はボロボロでコレナンテ物置状態なのだけど
境内の横浜市指定名木古木の大もみじがイイ、涼しい。

やっぱり体調が悪いので寝込む、台風来たら起き上がれない悪寒。

[NetBSD] src/lib/libc/locale/localeio.c

あーもウンザリ、雄山AA貼る気力もない。
file magicすらないPlain Textでdb作って将来的に仕様変更あった場合
libcの後方互換で困るとかそういうこと少しは考えようぜ。
/usr/lib/localeなら別にいつでもフォーマット変更できるけど
/usr/share/localeは将来見据えて設計するだろ、JK。
libcのmajor crunkしようが永遠に逃げられないんだからさ。

まあ最悪libcのmajor crunkした上で

ちゅーkludgeかまして逃げる道もあるけどさ、それしないのがNetBSDじゃねの?

まじでlocaledef(1)のcopy directiveの実装どうする気だろう。

気なのだろか。

あ、あとgettext(3)とLC_MESSAGESの競合問題もあったな。
LinuxだとLC_MESSAGES/SYS_LC_MESSAGESですやな。

[NetBSD] share/locale

ISCII-DEVとかiconvがサポートしてねぇcodeset突っ込むなよ。
FreeBSDから持ってくるだけでいいなら
NetBSDのlibcの上にFreeBSDのlibc上書きしてcommitすりゃいいよ、もう。

[C言語] 複数のlocaleをスッドレ毎に切り替える

kbkさんとこ。
ここ最近私がちまちま実装してるmulti-localeの話がまさにそれで
Ulrich Drepper氏は門前払いどころか Thread-Aware Locale Extensionちゅうドラフト書いてて
こいつは Linux Standard Baseにすでに取り込まれてます、なのでglibc2では

#define __USE_GNU
#include <locale.h>
#include <xlocale.h>
#include <wchar.h>

main(void)
{
    locale_t eucjploc, utf8loc;
    char eucjp[3] = "\xa4\a2";
    char utf8[4] = "\xe3\x81\x81";
    wchar_t eucjpwc, utf8wc;
    mbstate_t eucjpst, utf8st;
    size_t neucjp, nutf8;

    eucjploc = newlocale(LC_ALL_MASK, "ja_JP.eucJP", NULL);
    utf8loc = newlocale(LC_ALL_MASK, "ja_JP.UTF-8", NULL);

    mbrtowc_l(NULL, NULL, 0, &eucjpst, eucjploc);
    mbrtowc_l(NULL, NULL, 0, &utf8st, utf8loc);

    neucjp = mbrtowc_l(&eucjpwc, (const char *)&eucjp[0], sizeof(eucjp), &eucjpst, eucjploc);
    nutf8 = mbrtowc_l(&utf8wc, (const char *)&utf8[0], sizeof(utf8), &utf8st, utf8loc);
}

ちゅーコードが書けます、他にもMacOS X、MSVC8にはもう実装されてるようです。
...しかし同時にmbstate_tとlocale_tを管理しないとならないのは非常にウザい、センスに欠け(ry

当然これらはC標準ではないし、POSIXですらありませんので移植性は×です。
一度POSIXのAustin Groupでproposedされたのですがなぜかwithdrawnされてますね。
ISO/IECでも、C1Xに入れようという話はまだ出てないと思います。

というわけで言語標準でmulti-localeしたいならC++使いましょう、って
libstdc++はこのThread-Aware Locale Extension依存なのですけども ;-<

2008/05/19(Mon)

src/lib/libc/locale/localeio.c その2

CHAR_BIT != 8 のarchでshare/locale以下が互換性無いから
全部backoutしろとtech-userlevel投げたら流石に荒れるだろうなwww
どうみても数字な職業の方のいいがかりレベルです。