The Man Who Fell From The Wrong Side Of The Sky:2009年1月分

[最新版] [一覧] [前月] [今月] [翌月]

2009/1/1(Thu)

今日

喪中につき以下略

風邪ひいて寝正月。

relengの手間を減らすためにHEADとnetbsd-5それぞれ patch作った。
i386,amd64,hpcmips,hpcarm,hpcsh,sparc64,vaxでbuild checkしてあるので
たぶん大丈夫だと思うけど何分big commitになるので調整必要なんだが
まったくもってやる気が出ない…

[NetBSD] new locale db for 5.0

結局いい文面思いつかなかったのでmulti-localeの件には一切触れずw
以前某所に送ったメールを切り貼りしてtech-userlevel@に投げた。
なのでlibcの変更点でmulti-localeの為のstubが入ってる(current_locale.cとか)
件を突っ込まれるとちょっとめんどくさいかもしれない。
ホントはこれ無しでも動く実装できるんだけど、後々この方が楽なのでね。

tnozaki-multi_locale枝を切りてぇって話はまたいずれ日を改めて。
ちゅうかその前にlibc major bumpのドサクサに、_ctype_ table 32bit化の
話をしないといけんのか、うへへ。

ホントはwctype_tとwctrans_t、iconv_tがtypedef void *になってるのも何とかしたい。
仕様ではscalar typeなので別にpointerでもいいのだけど、コンパイラが型チェックできんからね。

wchar_tをunsigned intにするのはどーすっかなー。
'x' == L'x'の比較が int と unsigned int の比較になると
警告を出すコンパイラってMSVCだけだっけ? 頭痛いなー。

[NetBSD] wchar_t as 31bit problems

最悪libGBK2K.soをいじってlocale-dbは32bitなrune tableを
init時にon the flyで31bitに書き換える手もあるけどな。

んでもlibISO2022.soでUnicodeサポートする場合に困るか。
あれ32bit目使ってUCS4格納する予定だったわけだし。

あーしかもISO/IEC 2022の完全実装目指す場合、今のwchar_t mappingだと
DRCS(dynamically redefinable character sets)をつっこむ場所がなかった気がする。

ちゅーことでwchar_tを63bit(マテ

ISO/IEC 2022ラヴな人はDRCSにケータイ絵文字をつっこむとかやらんのかw


2009/1/2(Fri)

[NetBSD] new locale db for 5.0

agc氏がokゆうとるのでcommitしてまった、ついでにnviも。
ああっ、もうダメッ!
ぁあ…commitするっ、commitしますうっ!!
いやぁぁっ!あたし、こんなにいっぱいcommitしてるゥゥッ!

しかしcommit logふいた、これやっぱ枝切るべきだったろ。

mklocale(1)作り直しになるので多分src/UPDATINGも追加しないとならんはずだけど
とりあえず放置(ぉ

wizd(8)やっぱすげー、つうかいつもありがとう、ナンマンダブ。

ちなみに今回commitしたpatchだとlocale-dbはインスコされます。
ですのでmultibyte regex問題とかdate(1)の出力がひどい件については
あきらめましょう(ぉ

今日

風邪なおらんね、おかげで駅伝の往路からサザエさん症候群発症しそうだわ。

WAPBLが刺さらんようになったのでs/softdep/log/に戻してみた。
とりあえずbuild.shくらいじゃ刺さらないくらいには安定してるっぽい。

うーん、tech-userlevelなんかキター。
reed氏にLC_{MONETARY,NUMERIC,TIME,MESSAGES}実装して何がうれしいかとか
citrus_db使う事で開発者「以外」がなんかメリットあるかを
説明できる自信が全くないぞ。
なんせ実装した俺自身がひとっつも嬉しくないからな(ぉい

基本的にはバイナリ互換で将来的にgdgdになるのを回避できるのと
localeのキャッシュメカニズム突っ込んだのでちったー早くなるかってのと
(計測してないからびみょーですが)、このキャッシュを導入したことで
multi-localeの実装が楽になって、libstdc++ウマーってくらいしかないのよな。
つまりはあくまで開発者ネタでしかないとゆー。

chrtbl(1)についてはありゃSysV由来のゾンビなので放置でおk。
本来はmklocale(1)だって4.4BSD由来(つかFreeBSD?)のゾンビなので
ばっちいからポイしないとアレなんですが、localedef(1)でstateful encoding support
を考えるとかなり頭の痛い話になるので、とりあえずmklocale(1)に実装しちまえ
というグータラな発想でやってるからな。

とりあえず身も蓋もない返事書いて投げた。

[NetBSD] 続 new locale db for 5.0

デレツンなメールきた。
要約すると「おめでとう、でもまだそっちが正しいとは思ってないんだからね!」
あーぁ、別にあのまま表面上plain-text dbでもよかったんだよな。
んで結局/var/cache/locale/*/LC_*ちゅーMDデータ生成した挙句
二度とlibcはMIなplain-text dbは読まねぇwとかいう
返し技もあるんだけど…まぁ/varの容量がアレですな。

しかしなんでそんなにFreeBSDの実装にこだわるんだろか。
こうなったらFreeBSDも *1(滅多な事言わない

つか「でももうlex/yaccで書いてたlocaledef(1)、止めます」って
lex/yacc使うより手書きparserじゃないと逆に手間かかりすぎると思うんだけど。
なんせcharmap/localedefはcomment char/escape charを自由に変更可能だから。
それに ISO/IEC TR14652のinclude directiveとか実装しようとすると氏ねるからなぁ、yyparse()じゃなぁ。
前段にcpp(1)噛ますのと訳違うし…。

NetBSDならfparseln(3)使ったほうが逆に簡単に書けるってば *2

ということを繰り返しsodaさんと私で説明してるはずなんだがな。

Citrusにはドキュメント皆無なことに文句言われたけど、まぁそれはゴメン。
wiz氏にもmkcsmapper/mkesdbのman書けやゴルァいわれてたな…
まるでそびえ立つようなtemplateもどきマクロとヘッダの嵐だから
慣れないと読みづらいかもね、それこそ今回のコードはOpenBSDに
永遠にmergeされない自信がある。

さっさとsrc/external/bsd/citrusにでもごっそり移動して整備すべきなんだな。
しかしそれやるにはもっとCitrusとlibcの分離を進めないと厳しいのよな。
結局それはmulti-localeでやる予定だったのでしばらくはむりぽ。
Solaris並みのアレな分離をすればなんとか、なぁ…

ちゅかsrc/external/bsd/citrus/docだけ掘るかの。

こうしてTODOで埋もれていくんだなー。

i'm sinking in the quicksand of my thought
and i ain't got the power anymore

*1:4.2くらいまではpatch書いてたなー、それこそlocaleio.cに匹敵する
ldpart.cがcommitされてすっかりやる気失せたんだが。

*2:実際にはcitrus_fparseln()的なものを用意する必要があるけど。

[NetBSD] localedef(1)

そもそもあっちで実装してるlocaledef(1)がplain-text db formatを出力するなら
今回おれが魔改造したmklocale(1)にpipe(8)すりゃいいだけなんだけよな、よく考えると。
止める必要もなかろうとでも返事書くかー。
というか書きかけでいいから実装見せて欲しいよな、こっちも書きはじめたばっかの
プークスクスなのを以前tech-userlevelに投げたりしてるのに、ショボーン。

[NetBSD] 続々 new locale db for 5.0

lib/40317 ぶ、よりによってnetbsd-4のfparseln(3)にあるバグ踏んだ。
つかmklocale(1)はtoolchainなのでfparseln(3)のよなportableではない
関数使う場合は自前でlinkしないと駄目ですな。
build.sh便利だけど結構大変ですお、移植性ヘル。

例のメールへの返事もかかなあかんので明日だな、でんでんでんぐり返って(以下略


2009/1/3(Sat)

今日

風邪が治らない。

fparseln(3)のバグ踏んだ件の修正と、MacOS Xでcross buildする場合に
FreeBSD由来のRuneの呪いが発動する報告がcurrent-userにあったのでそっちも修正。
cross環境もつくっときゃ直ぐ気づいたんだろが。

残るはLC_COLLATE → multibyte regex(3) → localedef(1)か、なんという男坂。
昔yamtさんが書いたcollationの実装ってどんなんだっけか読んでみるか。

あとTR14652の完全実装をすべきか、LC_ADDRESSとかLC_PAPERってどれくらい使われてるんだ…
そもそもこのデータを利用するAPIがドキュメントにないのがアレ過ぎる…

[NetBSD] multi-locale vs per thread-locale

joerg氏がなんか per thread-locale vs multi-locale ちゅう比較をして
前者はらめぇとかtech-userlevelに投げてきたのだが
そもそもThread Aware Locale Modelって

なのでどっちがいいという話じゃなくて、両方実装するのだよな。
ポイントずれとれ。

ctype.hのマクロとか重々承知してますわ。
つかせっかくftpに置いてるんだから実装みてちょ。

あとでまとめてメール書く。

[NetBSD] cross build on FreeBSD

FreeBSDの/usr/include/ctype.hのたぶん rev1.27でNetBSDの定義とconflictするのが復活しとる。
よって今朝のcommitだけじゃcross-tools作れんわ。
ctype.hでis*/to*をinlineやmacroにして性能稼ごうとかもう止めようよ…
これ直すのかったるいなー。

MacOS Xだとどうんなんだろ、やっぱ買わないと駄目か。
ちなみに私を *BSDに引っ張り込んだツレの正体は狂信的マカで
Pipin@買えば幸せになるとかこれからはCopelandの時代とか
YellowBox for Windowsで救われる、などと意味不明な供述を繰り返しており
まったく欲しいと思ったことがこれまでなかったんだが。

一番簡単な方法はMacOS XやFreeBSDがrunetype.hをpublicにしとるので
こっちのprivateなrunetype.hをrunetype_local.hとかにリネームしちまうかだな。

netbsd-4でfparseln(3)のバグ踏んじまう件も駄目だわwww
そもそもnon-portableだから既にlibnbcompat.aがこれ持ってるんだな。
でもlibcにすでにfparseln(3)が存在する場合そっちを優先して
libnbcompat.aの中のfparseln.loは空っぽになってるわけだ。
つまりこれconfigureによるチェックでlibc側のfparseln(3)がバグ持ちか否かを
チェックせんとあかんちゅーことだ…これは萎える…


2009/1/4(Sun)

[NetBSD] fparseln(3)

結局バグ持ちか否かは

#include <stdio.h>
#include <stdlib.h>

#define CONFTEST        "conftest.fparseln"
#define COMMENT         '#'
int
main(void)
{
        static const char delim[3] = { '\0', '\0', COMMENT };
        FILE *fp;
        char   *ptr;

        fp = fopen(CONFTEST, "w+");
        if (fp != NULL) {
                unlink(CONFTEST);
                ungetc(COMMENT, fp);
                ptr = fparseln(fp, NULL, NULL, delim,
                    FPARSELN_UNESCALL);
                fclose(fp);
                if (ptr == NULL)
                        exit(0);
        }
        exit(1);
}

んなコードを実行すりゃいいのだが、src/tools/compat/configure.acに
どう書きゃいんだべさ、GNU autotoolワカンネ。

続fparseln(3)

こんな感じでいいのだろけ。

AC_CHECK_FUNCS(fparseln, [
    AC_MSG_CHECKING(if fparseln seems to work)
    AC_RUN_IFELSE(
        [AC_LANG_SOURCE([[
#define _NETBSD_SOURCE
#include <stdio.h>
#include <stdlib.h>

#define CONFTEST        "conftest.fparseln"
#define COMMENT         '#'
int
main(void)
{
        static const char delim[3] = { '\0', '\0', COMMENT };
        FILE *fp;
        char   *ptr;

        fp = fopen(CONFTEST, "w+");
        if (fp != NULL) {
                unlink(CONFTEST);
                ungetc(COMMENT, fp);
                ptr = fparseln(fp, NULL, NULL, delim,
                    FPARSELN_UNESCALL);
                fclose(fp);
                if (ptr == NULL)
                        exit(0);
        }
        exit(1);
}
        ]])],
        [AC_MSG_RESULT(yes)],
        [AC_MSG_RESULT(no)
         AC_DEFINE(BROKEN_FPARSELN, 1,
            [Define if your `fparseln' function is broken.])],
        [AC_MSG_WARN([cross compiling: not checking farseln])],
    )
])

そかしsrc/tools/compat/configureはautoconf-2.52なのだがpkgsrcは既に2.63だ。
2.52を拾ってこないと駄目なのかしら。

結局localにautoconf-2.52入れた。

今日

相変わらず風邪っぴき、体温が38度超えとるわー。

今回のlocale-db問題の口火となった、長年放置プレイの lib/10877
突然commitしてくれよった人から、何を今更( ゜д゜)ポカーンな質問メールきとる。
な…… もしや…tech-userlevel……購読してない……だと…? *1

いやbugathonとか参加してsend-prを積極的にcloseすんのは偉いと思うけど
PRと一緒に送られてくるFIXが常に正しいとは限らんのですよ。
言葉は悪いけど、無能な働き者by ゼークトにはならん様に注意しようぜ。

まぁ誰かがこのFIXに対してイローンハンローンobjection投げときゃよかったんだろうけど
あまりに古いサブマリンPR過ぎて俺も存在を知らなかったという。

Citrusのドキュメントを作文するだけの簡単なお仕事です。


*1:とかいいながらおいらはtech-kernは購読していないw

[NetBSD] cross build

とりあえずFreeBSDとLinux、NetBSD-4.0で動作確認した patch
まだいろんなメールの返事書いてないのでそれが終わったらcommitすんべ。

と思ったらcurrent-userで騒ぎになってるのでpatchだけ晒してみた。


2009/1/5(Mon)

今日

風邪がさらに悪化、年始よりお休みになってしもた。

うへへcurrent-userにpatchなげとるのに誰も見てねぇのな。
もうやだ。

某所でchristos_time_t mergeするよーゆうとるけど
libc no bumpとか書いてあるのはまだこれチャンスあるって事っすかね。

あぁまだ__RENAMEつかってcompat提供したってことね。
major bumpは後でってことかー。

ということでsrc/lib/libc/shlib_versionに列挙してあるmajor bump時にすべきこと
の一覧にこっそり_ctype_ tableネタを追加しておいた。

まだMacOS X上でのcrossbuildコケるか、やっぱ買わねーと駄目そうだ。
この不況で7月以降仕事があるかすらアヤシイのにそんな大金もなー。

まぁそんときゃお世話になるかもしれない年越し派遣村だが
社民って前回選挙で議席減った後自分とこの職員切りまくってなかったっけ?

current-usersのlibc major bumpネタ、やっとpkgsrc方面への影響をみんな認識しだした風味?
さすがOpenBSDみたいに始終libcがcrunkして賽の河原状態でports作り直してる
ヒャッハーな乱世とは違って、長年__RENAME()でトラブルを避けてきたネットキ慈愛の拳。

結局3rd Partyな共有ライブラリがインタフェースにtime_tを使っちまう可能性もありなので
今回の64bit time_t化でpkgsrcなんかの再コンパイルは必須になっちゃうのは仕方ないやね。
libcだけ__RENAME()とかsymbol versioningすりゃいいってもんじゃないのが
public typeのtypedefを変更する場合の恐ろしいとこですな。

そいやLC_*を実装してnon-developerが嬉しい点をひとつ思い出した。
perlが余計な文句垂れない、だ。

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LC_ALL = (unset)
        LANG = "ja_JP.ISO-2022-JP"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

しかしまだLC_COLLATE実装されてないからまだ解決されてねーしw
まだまだPERL_BADLANG=0かー、くっくやしいビクンビクン。


2009/1/6(Tue)

今日

ふーん、 DX-7(ミク)、EOS B200(リン)/ B500(レン)の次は VL1(ルカ)ときたか。
とすると WX11を咥(以下略

当時ROMpler化まっしぐらだったPCM音源ベースのシンセに対する
最後の抵抗だったなよな>>VA音源、 VL/VPシリーズって結局商売なったんだろうかあれ。

おいらはもう当時は「彼氏がピコピコ音鳴らしてた、別れたい」ちゅーかんじで
電子→電気への回帰でHAMMOND XB-2 + VOCE electric pianoがホスイと思ってた頃。
ちょうどAcid Jazz全盛期だったし、Free Soulのコンピ盤あたりを震源に'60〜70サウンドが流行りだした時期だし。
その空気を的確に読んでたのが正にROMplerであるE-mu VINTAGE KEYSだったような希ガス。

まぁアレだ、思い返せばレゾナンスすらないKORG M1みたいなのがバカ売れちゃった時点で
一般人に本当の意味でのシンセは不要だったんだと思う。
プリセット音しか使わないならROMplerが商売として一番おいしい訳だ。

ってもその辺はYAMAHA自身があのFM音源で「音作り=難解」ちゅー印象を
ユーザーの脳に刻んじまったからなので自業自得だとは思うけど。

要するに何がいいたいかというとアナログとのハイブリッドLA音源マンセーということです(ぉ

でも当時RolandもLA音源を正常進化させること無くウンコ化させよったからなぁ…
D-70とかありえんかった…PWM(Pulse Width Modulation)とRM(Ring Modulator)捨てて
DLM(Differencial Loop Modulation)とか頭ウジわいてんのかと。
おかげで木管系やキレイ系なベルの音を出すのに死ぬほど苦労した。
あれ76鍵じゃなきゃ即売り飛ばしてたな…U-20の76鍵モデルと思うようにして我慢したけど。

DLMって要はPCM音素片を高速でloopさせる時に発生する折り返しノイズでしかないので
マジキチな音しか作れません、まぁノイズ好きには(^q^)おいしい機能なんだけど。
エッビマヨマヨメタルマシーンミュージック。

(追記)
元YAMAHA系音楽教室バイトの分際ですっかり忘れとったけど
あの会社はシンセで商売してるのじゃなくて、そこからの技術を惜しみなく注ぎ込んだ
エレクトーンなんかで稼いでるんだよな、最も売れたVA音源機はおそらく EL-900あたりなんだろね。

なんせ最初のアナログシンセである GX-1はエレクトーンの形だし
同様に最初のFM音源搭載機だった GS1もデジピの形だしね。
シンセなんて遊びでやっててもおかしくない。

縁談チャラにするための自爆テロにウィニーでフリーソフト収集が今後流行りそうだ。

OLYMPUS-PEN D3げっと、わりと安く手に入ってホクホク。
今年の雛祭りはお内裏様がD3でお雛様がEEDのF Zuiko 32mm F1.7飾りでいくか。


2009/1/7(Wed)

[NetBSD] libnbcompat

jmmv氏のお返事がないのでMacOS X持ってないアテクシconfigure.acどう直していいかわからん。
やっぱ自分で環境用意しなきゃだめかー。
多分#include <util.h>を追加すりゃFPARSELN_*マクロ使えると思うんだが。
あれ多分古いNetBSDからパチってるはずだし(昔NetBSDではfparselnはlibutilにあった)。

でもconfigure.ac中で

#if defined(__NetBSD__)
#define _NETBSD_SOURCE
#elif defined(__Darwin__)
#include <util.h>
#endif

とかするくらいならふつーに

case "$host" in
*-*-netbsd-4*)
	AC_DEFINE(BROKEN_FPARSELN, 1, "[Define to 1 if ``fparseln'' function is broken.");
	;;
*-*-darwin*)
	...

の方がいいような気もするけどね。
pmakeスキー的にはこっちだよなぁ。

つかfparseln(3)がutil.hで定義されるかstdio.hで定義されるかどっちかを
チェックするスクリプトにすりゃいいのかな、そいと-lutilのリンク要否も。


2009/1/8(Thu)

今日

mutt-devより multibyte handling patch

fprintf(3)だと明らかにfwrite(3)と比較してがformat stringのparse分のコストが
かかって無駄な希ガス、そろそろprintf("%s\n", hoge)がputs(hoge)に置き換えられる
ように、コンパイラがfwite(3)に書き換えちまってもいいような気がしてきたぞ。

それとwcrtombにmbstate_tをNULLで渡してるのでstateful encodingで困るのだが
FILEからmbstate_tをぶっこ抜く方法は提供されてないのでしょうがないやな。
つかどっちみち!HAVE_WC_FUNCSの場合は自前のwcrtomb実装はUTF-8(=stateless)なんだっけ?

こんな感じかな。

wint_t fputwc(wchar_t wc, FILE *stream)
{
	char buf[MB_LEN_MAX];
	size_t l, m;

	l = wcrtomb(buf, wc, NULL/* XXX FIXME */);
	if (l != (size_t)-1) {
		m = fwrite(&buf[0], sizeof(buf[0]), l, fp);
		if (l == m)
			return wc;
	}
	return WEOF;
}

あとfgetwc(3)をそのままfgetc(3)のdefineにしちまうとまずいような。
なぜmbrtowc(3)を使わないのだろうね。

(追記)
muttのmbyte.cざっと眺めたらUTF-8の場合はutf8rtowc、それ以外の場合は
iconvで一度UTF-8に変換してからちゅう感じだだ。
しかしこれならiconvで直接UCS4に変換した方が早いと思うんだが
まぁでもそうすっといつiconv_tの扱い(いつcloseするか)が結構メンドイのだよな。

TODO、去年の2月から放置してるpcc(1)の今日までの差分を読む。


2009/1/9(Fri)

今日

某氏はtech-userlevel読んでないだけでなくsource-changesも読んでなかったか。
ok'ed by貰わずにcommitしたりほんと困った人だな、いつ気づいて赤面するか
このまま放置して観察してみよう。

それはそれとして、snj氏がcross build breakageの件でもっとpull-up必要?とかいっとるので
その準備とpatchを作り直さんとな、jmmv氏の返事がないのでconfigure.acはもう放置すんべ。
ただやっぱりlibcのmergeだけでshare/locale/*はインスコしたくないんだよな。
release版であのdate(1)の出力とか、電気消してといいたくなるほどはずかしいよう。
tech-userlevelで何の反応も無いので決めかねてたんだが、もう好きなようにやらせてもらおう。

結局今週末chiristos-time_tのmergeあるのかな。
pkgsrcの@blddepあたりを改善して混ぜるな危険防止を実装しようとか動きもなさそうだね。

もはやELF SONAMEとかmajor/minorによるヴァージョン管理なんて儚い夢だったな。
ここはexecve(2)でELF HEADERのEI_ABIVERSIONをもっと有効活用すべきな気がしてきた。
つまりbinary互換崩れた時点でcompat_hogeのようにchroot(2)実行しちゃうみたいな。
まぁFreeBSDのbrandelf(1)みたいに後から手で付け直すのはとスマートさに欠けるような気もするけど。

SONY VAIO P1、C1難民からすると何をいまさらちゅう感じで困る。
しかしあれがApple製品だったらポケットに無理矢理入れるのがファッションとして流行するだろうな。

黒点を白く塗るだけのソフトを作る簡単なお仕事、完了したらしい。


2009/1/10(Sat)

昨日

花屋、不況の影響か知らんが切花の鮮度保持剤をくれなくなった、ぶー。
そもそもこの花屋、営業終了後には冷蔵庫で温度管理してないので
ちゃんとやってる店より痛みが早いのよな(そのかわり若干安い)。
次からは別の店にしよう。

SONY VAIO type Pがデモ機置いてあったので触ってきた、パンフ持って帰る人結構いた。
俺は現場にPC持込禁止になってからモバイラ足洗ったので買わんけど。
つかThinkPad X61のローンまだ残ってるしなー。

ジャンク箱から後玉汚れなMinolta MD 50mm/F1.7拾ってきた。
中性洗剤で汚れ落としたら全く問題ないレベル。
一緒にあったMinola X-500も気になったんだけど、汚れがヒドいのと
高速シャッターが速度変わってない気がしたのでヤメ、どうせX-700持ってるし。

風邪が相変わらず治ってないので連休は寝てる予定、これは欝だ…

OpenBSD + Citrusな環境でxenocara作ろうとしたらlibXpmがgettext-toolがねぇって
怒られた、X11がgettext呼ぶってーのもおっさんからすると感慨深いものあるが
まぁ中途半端にlibintlだけつっこんだおいらが悪いということで。
Makefile.bsd-wrapperのお作法知らんのとGNU gettextとか読むと胃に穴が開きそうなので
放置してたんだけど、NetBSDでもpgettextネタでpkgsrc方面で困ってるという話もあるし
そろそろ首突っ込まんといけんのかも。


2009/1/11(Sun)

今日

christos-time_tハジマタな。

ctype.hの_ctype_ tableの8bit → 32bit化作業をしなきゃならないんだよな。
ちゅうかあれ32bitだと大き過ぎてホントは16bitで充分なんだよな。

#define _CTYPE_A        UINT16_C(0x0001)        /* Alpha        */
#define _CTYPE_C        UINT16_C(0x0002)        /* Control      */
#define _CTYPE_D        UINT16_C(0x0004)        /* Digit        */
#define _CTYPE_G        UINT16_C(0x0008)        /* Graph        */
#define _CTYPE_L        UINT16_C(0x0010)        /* Lower        */
#define _CTYPE_P        UINT16_C(0x0020)        /* Punct        */
#define _CTYPE_S        UINT16_C(0x0040)        /* Space        */
#define _CTYPE_U        UINT16_C(0x0080)        /* Upper        */
#define _CTYPE_X        UINT16_C(0x0100)        /* Xdigit       */
#define _CTYPE_B        UINT16_C(0x0200)        /* Blank        */
#define _CTYPE_R        UINT16_C(0x0400)        /* Print        */
#define _CTYPE_I        UINT16_C(0x0800)        /* Ideogram     */
#define _CTYPE_T        UINT16_C(0x1000)        /* Special      */
#define _CTYPE_Q        UINT16_C(0x2000)        /* Phonogram    */

extern const uint16_t *_ctype_ __RENAME(___ctype_r50);

なぜ今の_RuneTypeが32bitなのかっちゅーと、wcwidth(3)用の情報まで
抱え込んでるからで、そもそもありゃ 先日修正したバグで判明したとおり
実装としてはマチガイなのよな。

どーせbinary compatibility気にしなくていいタイミングなので
_RuneTypeを16bit化して_ctype_とunifyするのと、wcwidth(3)用の情報は
別途8bitでフィールド追加するって感じか、めんどくさいだけで面白くもなんとも無い作業だ…

でもLC_CTYPE locale-dbは互換性の問題で16bitに変更できないので
_FileRune*から_Rune*作るときにon the flyで32bit(_RuneType)から
16bit(_NewRuneType)にしなきゃならんのか、それはそれで無駄なコストで
ケチケチな俺としては了承しかねるな、どうすんべや。

いっそ全部/usr/lib/localeに移してMDなデータにしてlocale-db formatも
Runeよりもっとマシなもんに再構成して一から出直したい気分だ…
せめてアレがcitrus_dbなkey/value形式だったらもっと柔軟に変更できるのだが。

やぱし/var/cache/localeかなー、on the flyでの変換コストはここで吸収しちまうと。
でも断(以下略

やはりRuneつーだけあって呪いの効果は絶大だ…

Please Kill Me読了、Lou Reed先生(the Velvet Underground)のアレっぷりには
いつも心が洗われる。 この顔

「俺の口にク○させてやる、どうだい、そういうの?」

と初対面の男をナンパし、断られると

「じゃあ俺が顔に皿載せるから、そこへ○ソしてもいい、それならどうだ?」

と斜め上な妥協点を提案するとか、HENTAI過ぎて神々しくもある。

斜め上な妥協点を提案するといえば、 どっかの党首はもうワンパターン過ぎで秋田。

Lou Reedですら売れない頃、タブロイド誌で殺人犯や性犯罪者の
写真モデルのアルバイトやってたんだから、仕事を選り好みしてちゃダメだよね。
ってどんな仕事だwwwそれwww


2009/1/12(Mon)

今日

某100円ショップのアイヨーなSR44酸化銀電池詰めて冬空に撮影に出たら
性能低下でシャッター切れねぇでやんの、ちっくしょー(アナゴさんAA略)
資本主義だろーが社会主義共産主義無政府主義だろーが結局は粗悪品ばかりの世の中よ。
世界地図でソ連を探したが見つからない、それは地図がソ連製で不良品だからだってジョークかよ。
アッカはリョーカをクチクする、おおなんかおそロシア風だ。

格差社会?社会主義国家日本が、やっとこさソ連に続いて崩壊しようとしてるだけですよ。
it's the end of the world as we know it, and i feel fine.

猫探してますのチラシ、見つかるといいですね、俺もまだ探してます。
もう10回目の満月がとてもキレイ。

満月の晩、モビィ・グレイプのように解散総選挙を祈願してCall Mr. Leeを
カラオケで熱唱する小沢民のジェスチャークイズ。

そういやTelevision(アナログ)、再結成Television(デジタル)って
いつの間にやらRichard Lloydは脱退して、Jimmy Rippが加入してんのね。
この人のギターは Wandering Spirits by Mick Jaggerの頃からファンなんだけど、この組合せはちょっと微妙な悪寒。
Tom Verlaineのソロに参加した奴はまだちゃんと聴いてないんでそのうちチェック。

「服を買いに行く服がない」からthe Velvet Undergroundの"All Tomorrow's Parties"の
歌詞を連想し、更にParties → Pantiesに誤変換されるこの幸せな脳味噌をどうにかしたい。


2009/1/14(Wed)

[NetBSD] nvi-1.81.6

uebayasiさんとこ読んで気になったのでnvi-1.81.6 + uim-fep でしばらく生活することにした。

いきなりLANG=ja_JP.eucJPの場合、NEC特殊文字0xADA1〜0xADFC(丸囲み数字など)が
uim-fep側から入力可能(つまりCP51932相当)なのに対して
当然のことながらlibc側のLC_CTYPEはそんな文字は機種依存文字(笑)で知らねぇもんで
libcursesの動作が不安定になって落ちたりするバグを発見してしもうた、orz

#0  0xbbacc920 in ?? () from /usr/lib/i18n/libEUC.so.4.4
#1  0xbbacd326 in _citrus_EUC_ctype_getops () from /usr/lib/i18n/libEUC.so.4.4
#2  0xbbb5ba96 in mbrtowc () from /usr/lib/libc.so.12
#3  0xbbbd5f3b in __waddbytes () from /usr/lib/libcurses.so.6
#4  0xbbbd600b in waddbytes () from /usr/lib/libcurses.so.6
#5  0xbbbcf972 in waddnstr () from /usr/lib/libcurses.so.6
#6  0x0804c785 in addstr4 ()
#7  0x080811b5 in vs_line ()
#8  0x08083281 in vs_paint ()

誰だ、cannaの辞書にCanna36p4/dic/ideo/words/necgaiji.tを入れたのは(海原雄山AA略
ってこれ最初っからだろな、そもそもcannaはNEC製だし。
でもkinput2 -cannaだと候補に出てこないんだよなー、丸付き数字。

nvi側でのillegal byte sequenceの場合の処理がダサいのだろうけどなぁ。
emacsならInvalid code point for charsetエラーで落ちたりはしないわけで。
さてどうやって直すか…

最近のHEADではkinput2が動いてない、なんぞこれ。

Program received signal SIGSEGV, Segmentation fault.
0xbb95a032 in _malloc_prefork () from /usr/lib/libc.so.12
(gdb) bt
#0  0xbb95a032 in _malloc_prefork () from /usr/lib/libc.so.12
#1  0xbb95a2e3 in free () from /usr/lib/libc.so.12
#2  0x08089096 in js_open_lang ()
#3  0x0808e865 in jl_connect_lang ()
#4  0x0808e9ce in jl_open_lang ()
#5  0x08060840 in jcOpen2 ()
#6  0x0805c158 in jcInitialize ()
#7  0x0805c6cd in Initialize ()
#8  0xbbafaf22 in CallInitialize () from /usr/pkg/lib/libXt.so.6
#9  0xbbafb850 in xtCreate () from /usr/pkg/lib/libXt.so.6
#10 0xbbafbf9a in _XtCreateWidget () from /usr/pkg/lib/libXt.so.6
#11 0xbbafc28f in XtCreateWidget () from /usr/pkg/lib/libXt.so.6
#12 0x0804bbce in main ()
(gdb)

つかこれWnn見に行ってるのか。

inputmethodといやー、SCIMももういちど調べんとなー、 前書いたpatchだとGTKで動作が変で
gtk-query-immodules-2.0が刺さったりしやがるからなぁ。

IIIMFの状況見ようとwww.openi18n.orgいったらサイトごと消えとる、なーむー。
svnリポジトリはまだ見えてるのでIIIMF SDKとかは大丈夫みたいだけど。


2009/1/15(Thu)

[NetBSD] netbsd-5

うはーcross build breakageの件、snj氏がcommit mailから判断してpull-upしてくれたわ。
ありがたや〜なんまんだぶ、releng teamカッコヨス。
ちゅうか内部では17 Jan 2009にはRC1出したいゆうとったから痺れ切らしたんだろ、ごめんよ…
俺も本業が4月リリースに向けて盛り上がってまいってるので
時間なくていろんな人からのメールの返事とか書いてないのだった。

[NetBSD] pkgsrc/wip/scim 他

scim_iconv.cppのお行儀があんま宜しくない、MB_LEN_MAXとか使っとるし。
iconv(3)を使うアプリが正しい使い方をするはずがない!

gtkimmodule周りのコードをちら見したところ、preedit_stringが
WideStringで定義されてるんだが、これ非__ISO_STDC_10646__環境では
wchar_tでなくucs4_tになるので、gtk2がこいつを何も考慮せずに
wcrtomb(3)なんかに渡したりするとアウトになりそうな悪寒、この辺から追ってみるかー。

utf8_wcstombs()でUCS4 -> UTF-8変換してからgtk2だかpangoだかに渡しとる。
glib2のgcharってUTF-8 hardwiredなんだっけ?

しかしFreeBSDでも-D__STDC_ISO10646__とか 勝手に定義しとるんで
同じような問題が出てもおかしくないんだが、そういう話も聞かんよな。
みんなja_JP.UTF-8 locale使ってるんだろけ…

つかscimはなんでわざわざ内部UCS4で書く必要があるのか理解に苦しむ。
普通にCSIで書けばいいのに、Unicodeなんぞ銀の弾丸どころか悪魔そのものだろ(ぉ

そいやnvi-1.81.6でもgtk frontendでucs2utf8()とかアレな部分を放置しとったな。
あと32bit clean patchをpkgsrc/editors/nviにmergeしてもらわんと。
いやほんとは以前ちょっとメールやりとりしたメンテナの方にpatch投げんとならんのだが。

それとvi.recoverが/usr/bin/viがbdb1で/usr/pkg/bin/nviがbdb3なもんで
同じ/var/tmp/vi.recoverを使われると混ぜるな危険になる件もどうしたもんやら。


2009/1/17(Sat)

[NetBSD] PR/40411

ひゃー。_DefaultRuneLocaleのwctrans tableでlazy initializeしとったか。
なのでconstにしちゃまずかったってこった、おいらのミステイク。

にしてもchristos氏がつっこんだ修正だと盛大にmemory leakするんですが(笑)
もうね(以下略
つかpull-upめんどくせぇなぁ…

これconstはずすよりも_DefaultRuneLocaleのlazy initialize止めるだよな。
そうすりゃ_DefaultRuneLocaleが_wctrans_initされることもないっちゅう。
でもextなfieldで困るんだっけ?そもそもなぜlazyしとるか良く判らん。

週明けくらいに直すか、いちお patch。
つかchristos-time_tこわい!

つかsend-prした人、直ってないってstatically linked なtcshをリコンパイルしてないっぽ。

あと昔locale -aでlocale.aliasも読む対応したときに off by oneやとったかヒドイw
locale -aの出力がところどころくっついとるわ。
やっぱり必ずstrndup(3)使おうぜってことですな(当時まだlibcに無かった)。


2009/1/18(Sun)

[NetBSD] 続PR/40411

patch作り直し、_wctrans_init()自体をnukeしてしまえちゅう感じ。
ただいまテスト中。

余談だけどlint(1)にC99の指示付初期化子を喰わせると、高確率で内部エラーになるのが困る。
今回runetable.cをC99スタイルで書き直そうとしたら↑にひっかかってしまった。

今日

手元にあるHDDがすべてSeagate製でした…さあ逝こうか…
つかまだ夏に買った500GB×2まだ封も切ってないのだが。

strndup(3)はGNU拡張ですが ISO/IEC TR24731-2にあるので、C1Xには入りそうな予感。

ちなみにGNU拡張にはstrdup(3)のワイド文字版wcsdup(3)はあれど
なぜかwcsndup(3)はないとゆー中途半端な状態、ふしぎ!

strdup(3)のalloca(3)版、strdupa(3)とかになるともう勘弁してちゅーかんじ。

ホワーイnvi 32bit clean patchのreleng-5 pullup requestはstallにされとるのだろ。
まぁ困るのはzh_CN.GB18030で4byte code入力する必要のある人だけなので
個人的にはどーでもいい、ちゅうかISO-2022-JP localeでまともに動かない件の調査を
そのうちやらんとならん方が先。

シゲッといえばthe Doorsですが(最近のリマスタだとシゲッハ〜イか)
うちのSeagateはとりあえず全部問題無しだった模様、ちゅうことで放置。
そういや大昔、某スタジオでAKAI DR4dにMicroPolice製のSCSI HDD新品をつけて
慣らし運転はじめたら、半日持たずにぶっ壊れて激しくふいたな。
あれテストせずに本番のレコーディングに使ってたら死ねたわ。
もう一台の方につけたQuantumは未だに壊れることなく動いてる。


2009/1/19(Mon)

[NetBSD] 続々PR/40411

朝起きたら('A`) constはずされてた、_Default*は書込み禁止が筋だろJK。
おちけつって、なんかもうほんと勘弁してくださいよ…。手元でconflictしまくリング。
5枝に対するpull-upとかもうマンドクセ。

ちゅうか前の修正で落ちなくなるはずなんだが(memory leakすっけど)
このsend-pr主、standalone(=static linked)なtcshを作り直してないだろ…
そりゃ永遠にダメだわ。

ちゅうわけであと半月は見(けん)を決め込もうと思ってたHEADをpost 64bit time_tに
入れ替える羽目になてしもた、こわいよー。

つかkernelとkmodだけ入れ替えた状態だとかなり怪しい動きするの。
この状態でscim-helper-managerを起動するとcore吐く死によるのだが
gdbで追ってみるとgettext(3) → open(2)で死んでたりしよる。
libcも入れ替えたら落ちなくなったけど、COMPAT_50が変なのかもしれず。

[NetBSD] pkgsrc/wip/scim

さっきのやつ、5.99.4に戻してみるとこう。

#0  0xbb05c126 in open () from /usr/lib/libpthread.so.0
#1  0xbbb0d46f in dcngettext () from /usr/lib/libintl.so.0
#2  0xbbb0e2e0 in dgettext () from /usr/lib/libintl.so.0
#3  0xbb90d01e in anthy_imengine_helper_LTX_scim_module_init ()
   from /usr/pkg/lib/scim-1.0/1.4.0/Helper/anthy-imengine-helper.so
#4  0xbbb73ec5 in scim::Module::load () from /usr/pkg/lib/libscim-1.0.so.8
#5  0xbbb66410 in scim::HelperModule::load ()
   from /usr/pkg/lib/libscim-1.0.so.8

うーんCOMPAT_50でなしに、libpthread絡みっぽ。
いいや5.99.7にしちまったし忘れんべ。

今日

※ただしイケメンに限る
※ただし美少女に限る
※ただしMMUのあるarchに限る

忘れないうちにTODO

  1. _ctype_ table as 32(or 16)bit
  2. LC_COLLATE
  3. multibyte regex(3)
  4. correct src/share/locale/* data
  5. more locale(1) work (escape when locale -k currency_symbol is 0x5C)
  6. more LC_TIME work (strftime %+ spec, ERA etc...)
  7. scanf(3) positional order
  8. iconv(3) M:N conversion
  9. multi-locale
  10. hide sys/localedef.h
  11. upgrade GNU gettext-0.17, or BSDL gettext-tools :-)
  12. wcurses audit
  13. nvi-1.81 audit
  14. locale specific wctype/wctrans supports
  15. iconv GNU emulation?(//TRANSLIT, //IGNORE, iconv_hook etc...)
  16. localedef(1)
  17. pcc(1) wchar_t supports
  18. documentation

あたりか、全部終わるのはいつになるやら…


2009/1/20(Tue)

[NetBSD] 続^3 PR40411

snj氏からpull-up requestしろよ風呂入れよ歯磨けよババンババンバンバンなメールキタ
ので、2〜3日まってちょの返事書いて出した。

[NetBSD] 続^? pkgsrc/wip/scim

obacheさんとこ、NetBSDではzh_CN.GB2312って、zh_CN.eucCNのaliasでしかないんで
動かないとするとどっかにハードコードがあるっぽいですね。

ちゅうか最近のxorgのlocale.aliasが腐ってるっぽいな。
いつの間にかzh_CN.gb2312 != zh_CN.eucCNちゅうことになって
(gb2312とeucCNの関係って要するにujisとeucJPの関係と一緒ね)
なおかつzh_CNはzh_CN.gb2312のaliasになっててzh_CN.eucCNには
実体が無いので たぶんこれXtSetLanguageProc(3)とかコケるんじゃないかな
X_LOCALEじゃあるまいしコケないわw、ただしfontset周りがダメになるかも。

FreeBSDでもgb2312 != eucCN(んで中身結局同じ)ちゅーわけわからん
状態なんだけど、あちらではeucCNが何ものか知らない人たちが多いのだろけ。

XFree86 4.5.0も腐ってた、もうね(以下略


2009/1/21(Wed)

昨日

月命日、酒買って帰った。

ひろいもの、光速で壁紙にしてニヤニヤしてた。

jfbterm for FreeBSDってwsconsでもおkらしいんだけど、mixiのNetBSDコミュじゃ不安定とかいっとったっけか。
自分じゃ入れた事無いのでそのうち試してみる。

某スレのマダーリストにあるuwsconsだけど、kernel layerでi18nどうこうしようとすると
kernel iconvとかwide-character syscallのようなもんが必要になりそうなので
konとかjfbtermのようにuserlandでいいじゃんと思っちゃったりしないでもない。

以前はどうせkernelでもsmbfsとかNTFSなんかでコード変換はどーしても必要だし
kernel iconvは実装しないとダメかなと思ってたんだけど、最近はpuffs/FUSEがあるわけで
こっちもuserlandでいいじゃんとか思ってしまったり、まぁpuffs重いけどね。

FreeBSDのkiconvはportsのlibiconvから変換テーブルをcopyin(9)してくるんだっけ、その発想は無かったわ。

[NetBSD] 続^4? pkgsrc/wip/scim

おばたさんからメール頂きまして、-lpthread付でないscim本体が-lpthread付のmoduleをdlopen(3)すると
いろいろマズイという話をちょうど pkg-usersでしてるとこちゅー情報を頂きました。
ありがとうございます。

これscimを-lpthreadありにする以外ないんじゃないかな。

[NetBSD] tech-userlevel

PRI*ネタ、size_tは%zだろちゅーツッコミが早速入ってるけど、time_tもstruct tmに変換してstrftime(3)だ罠。
その他のやつも移植性考えるなら新しく追加するのはビミョーなので、intmax_tにでもキャストするとか
その他dev_tなんかはこれもtoString()的な文字列へ変換する関数を用意した方がスマートだと思う。
ただ性能的に若干不利ではあるのは確かなんで#ifdef _KERNELでくくってuserlandでは一切許可しないのなら
新しいPRI*追加しようがどうでもいいかんじ、ただし新しいspec追加はお断りだw

[NetBSD] nvi + netbsd-5

nviはいろいろ手が入ったのでもうnetbsd-5とHEADと完全にsyncするので俺のpull-up requestはstallしてたみたい。
ちゅうことでsyncされた模様、cvs logから全部辿ってreleng teamも大変でんな。


2009/1/22(Thu)

昨日

nviのバグもういっちょバグ発見。
やっぱりillegal byte sequenceの問題で、mbrtowc(3)でEILSEQが発生した場合
運が悪いと落ちたりハングするのは前も書いたけど、そこで落ちなかったとしても
不正なバイト列より後ろをwregexpで検索できない問題がある。
こないだwregex触ったのでデグったかと思って冷や汗かいた。

scimネタ、あーわかったfirefox-bin(linux emu)はzh_CN.GB2312でしか動かなくて
firefox(native)はzh_CN.eucCNでも動くよといってるわけだ、openoffice-binのくだりで把握。
そらそうだ、だってglibc2ではzh_CN.eucCNじゃなくてzh_CN.GB2312だから。

税金キャッシュバックキャンペーンを勘定に入れてもMacMiniすら買える気がしない。

今日

みのうらさんとこ、恥ずかしながら NFSv4が国際化(UTF-8)されてるのは知りませんでした:) *1
kernel iconvを実装するなら、塩崎さんの仰る通りFreeBSDのように変換テーブルを
kernel空間にcopyin(9)するよりは、変換処理をuserlandに委譲して変換結果だけ
貰ってくるくらいにしておかないとNetBSDでは厳しそうですね。
#でもiconvd(8)のようなアレなものが必要なのか…

そういえばTODO忘れてた、iconv(3)でUnicode正規化実装(まぁM:N変換なんだけど)。
ファイルシステムで使う場合、NFSv4だけでなくHFS+でも必要になる。
でも//NFD //NFCとかスイッチは嫌だな、ふつーにUTF-8-MACとかそういう感じで。

christos氏がpull-up request出してくれた模様、なんまんだぶ。
いちおnetbsd-5でpatch作っとこうと思ってたんだが、まぁ念のため用意しとこう。
あとlocale(1)のoff by oneだけpullup requestしとかんとな。


*1:最後に使ったのはもう何年前なんでしょう…


2009/1/23(Fri)

今日

年明けてから本業の方が多忙だったもんで、ついに午前中ダウンしてもうた。
今日提出のものさえなければ休んだんだが無理矢理出社。

ハンディカムを買いに行く娘がいない、ので感動できない人生ですが
SONYがネコの思い出ビデオとかやりよったら号泣するので、それだけは勘弁してつかぁさい。

あ、メカ的に裏面照射CMOSがもう投入かーってのと、これまでCarl Zeiss T*銘だったのが
α資産としてMinoltaから引き継いだGレンズ銘を持ってきたところにホロリとしましたよ? (ぉい
やらないかパナライカ対抗でCONTAXを京セラから買うなんて噂もあったっけか、Nマウントなぁ。

松下 → パナソニックになってパナソニック「電工」の発音が
マイケル・ジャクソンの「マイコー」と同じように巻き舌になった気がする。

民主副代表、麻生総理に「グラドルテスト」を実施 … 小向美奈子を小西真奈美と間違える一幕も。

ByeBUY Fujitsu、社長自らSPARC Enterprise(PRIME POWER)をまるであたかも
HP ML115のように何台も買っちゃったりする光景を想像した。
Interstage Charaset ManagerのJEFコード plugin for Solaris iconvだけ売ってください。

なんぞこれ。

# modload /stand/i386/5.99.7/modules/compat_linux/compat_linux.kmod
WARNING: linker error: symbol 'compat_43_sys_truncate' not found
(中略)
WARNING: module error unable to affix module '/stand/i386/5.99.7/modules/compat_linux/compat_linux.kmod'
modload Exec format error

すでにcompat.kmodはmodload済なんだけどな。

# nm /stand/i386/5.99.7/modules/compat/compat.kmod | grep compat_43_sys_truncate
00003c84 T compat_43_sys_truncate

# modstat | grep compat
compat          misc	builtin	0	-	-

[OpenBSD] wcstod(3) audit

OpenBSDにwcstod(3)他がmergeされたんだが(NetBSDの実装ベース)、code audit結果がおもろかった。

内部処理で、wcsr?tombs(3)にNULLを渡して必要なバッファサイズを測ってmalloc(3)し
もう一度wcsr?tombs(3)に渡すちゅー部分があるんだが、ここに差異がある。

元になったFreeBSDの実装が1回目と2回目のwcsrtombs(3)が常に同じlocaleで
実行されることを仮定して、一切ノーチェックなのよね。

	if ((len = wcsrtombs(NULL, &wcp, 0, &mbs)) == (size_t)-1) {
		if (endptr != NULL)
			*endptr = (wchar_t *)nptr;
		return (0.0);
	}
	if ((buf = malloc(len + 1)) == NULL)
		return (0.0);
	mbs = initial;
	wcsrtombs(buf, &wcp, len + 1, &mbs);

	/* Let strtod() do most of the work for us. */
	val = strtod(buf, &end);

これ私がNetBSDに持ってきた時、念のため_DIAGASSERTだけはいれてある。

	len = wcstombs(buf, src, bufsiz + 1);

	_DIAGASSERT(len == bufsiz);
	_DIAGASSERT(buf[len] == '\0');

	/* Let strto{f,d,ld}() do most of the work for us. */
	val = _STRTOD_FUNC(buf, &end);

しかしOpenBSDはここにわざわざエラー処理をぶちこんだ模様。

		size_converted = wcsrtombs(buf, &s, size, &st);
		if (size != size_converted) {
			/* XXX should not happen */
			free(buf);
			errno = EILSEQ;
			return 0;
		}

まー確かにこれ1回目と2回目のwcsrtombsが異なるlocaleで呼ばれると
彼らのコメントにあるshould not happen「でない」可能性はあるのよね。

じゃぁFreeBSDが間違いかってーとそうでもなくて、そもそもsetlocale(3)ちゅーものは
限定的なMT-safeであって、locale awareな関数が実行されてる最中に別スレッドで
setlocale(3)を呼んではならないのよね、もし呼んだとしたらそれは未定義動作。
なもんでわざわざチェックして性能落とすよか、そのまま放置でもいいんじゃねかと。

まぁやらかしてるアプリが変な動きした時に、-DDEBUGつけたlibcなら
abort()して原因を判りやすくする為に一応assertionだけは入れとけや
ちゅーのがおいらの判断だったのだけど。

まぁ遅くなろうがコードサイズ増えようが、可能な限り安全側に倒すのがOpenBSDなのだろうけど
余計なコストを払うを吉とするのならいっそmutex lockしちまうのが筋だよなと思う。

まぁ根本的にwcsr?tombs(3)を使ってmultibyteに戻してstrtod(3)を呼ぶなんちゅー
コード自体がkludgeなのよね、wcstol(3)の実装と同じようにワイド文字で閉じて処理すべき。
ただしそうすっとワイド文字版の gdtoaが必要になるというのと同義なので、手を出すのがしんどいのよな。

あともう一箇所、FreeBSDでwcsrtombs(3)を使ってる部分をおいらがwcstombs(3)に書き換えたのを
再度wcsrtombs(3)に戻してるんだが、これ意味わからんよな。
これがあるので、nul-terminateされてることが確実であればwcsrtombs(3)を使う理由は無い。
もしかしてwctomb(3)と同じようにthread-unsafeだと勘違いしてるのだろけ。
wcstombs(3)は常にinitial stateから変換を開始するので、wctomb(3)のような
global mbstate_tは持たないんだけど。

Linux/glibc2のwcstombs(3)のマニュアルがアレですな。

The function wcsrtombs(3) provides a thread safe interface to the same functionality.

wcsrtombs() 関数は同じ機能のためのスレッド・セーフなインターフェースを提供する。

どっちもMT-safeだよ。


2009/1/24(Sat)

[VMware] xvmware

@ 追記

最近のxorgだと自動でseamless機能が有効になってますのでxvmware側のautograb機能はoffにしてください、 詳細はこちら

@

うはは、そのうちサポートページ作りますかね。以下は暫定で。

@ こっ…これ何ですか?

ああ、コxvmware *1

以上2つの機能をサポートしてます。

元々 vmware-nisetoolに含まれるvmware-xsupportsがCut Bufferしか対応してないので
Selectionを使って日本語なんかも、という開発(ってほどのもんじゃなし)動機ですので
同vmware-synctimedのようなguest <-> hostとの時刻同期は当然ながらサポートしてません。
todrのsysctl化ちゅう話もありますな。

ドラッグエーンドドロップは未サポート、vmware backdoorのclipboardは
UTF-8なplain textしか通さないので、別途guest <-> hostでRPCしないとならんのですが
仕様を調べる気力がありません、XDnDサポートするアプリ(GnomeとかKDEとか)と無縁だし。

@ スクリーンショット

スクショ

@ ダウンロード

ダウソ

リポジトリ

@ 使い方

使い方は簡単で.xinitrcなどからbackground実行するだけ。

LANG=ja_JP.eucJP
XMODIFIERS="@im=kinput2"
export LANG XMODIFIERS
xvmware &
kinput2 &
kterm -g 80x24+0+0 &
exec twm

貧相な.xinitrcとかオッサンとかオールドタイプとか旧*BSD會ゆーな。
old schoolと呼びなさい。

オプションは↓な感じ。

-noautogrub			シームレス移動をoffにする 
-interval <ミリ秒>		マウスカーソルの監視インターバル

これらの設定は.Xdefaultsにも書けます、${X11BASE}/lib/X11/app-defaults/Xvmware参照。
Window managerによっては画面の端にくると自動でVitrual Desktopを移動する機能が
あったりしますが、そいつとguest -> hostへのシームレス移動の相性が悪いと思われるので
そういう場合はどっちかをoffにしてください。

@ 動作環境

[guest]
現状i386のみのサポートです、amd64用のコードもvmbackdoor.cにありますが
動くかどうかテストすらしてません。WindowsXPのx64 editionが手元にあるので
インスコして試しゃいいのですが、時間が無いのでので放置中。

(追記) amd64も対応済です

OSはNetBSDとOpenBSDで動作確認しました、まぁ戦闘力3くらいのカスなので
X11R6以降が動いてりゃ、他のOSでも大丈夫でしょう。

[VMware]
VMware-Server-1.0.xと同2.0でのみ動作確認しました。
古いWorkstationだとクリップボード中のテキスト長周りの仕様が違うようで
上手く動かない可能性がありますが、知 っ た こ と か ー 。

@ インストール

NetBSDなら

$ sudo make -f Makefile.netbsd depend all install

それ以外なら

$ xmkmf -a
$ make all install

でおk、xorgつこうとる人は適宜imakeを入手すべし。

OpenBSDのようにlibcにiconv(3)が無い場合は、GNU libiconvをportsなりでインスコして
ImakefileのUseGnuLibiconvをYESに書き換え、GnuLibiconv.tmplにあるGnuLibiconvDirなんかを
適宜編集しちゃってください、GNU Autotool化? お待ちしております。

そもそもpkgsrc/sysutils/open-vmware-toolsとゆう本家筋の実装があるのですが
GTK2のようなゴーマー・パイル依存でなしに、X Toolkit + iconvのみで書かれてるので
導入の敷居が低いのが唯一のメリットかも。
# まぁconfigureじゃなしにimake使うので、昨今ではそこが敷居に(以下略

pkgsrcな人は wip/xvmwareからも入れられます。

@ バグかと思う前に

ちなみに私の趣味でCodeSet Independentな実装です。
xvmwareは自身のlocale(LANG, LC_*環境変数)の文字コードを経由してコピペされよります。
コード変換はiconv(3)を使いますので変換不能な文字があった場合には〓とか?に置換されます。
ただしGNU libiconvを使うと POSIXに準拠しない動作により変換そのものがストップする可能性があります。
これはGNU libiconvの「バグ」ですので文句はそちらへ。

それとxvmwareをeucJP localeで起動してる場合

Windows日本語版(CP932) -> VMware(UTF-8) -> xvmware(eucJP)

という変換になりますので、お決まりのWAVE DASH/FULLWIDTH TILDE問題が発生しますが
仕様通りですので、こっちもThe Unicode Consortiumへ文句をどうぞ。


*1:これ商標権の侵害にあたるのかね?
create -> creat(3) にならってxvmwarとかにしといた方がいいのかな。


[NetBSD] scim

結局GTK_IM_MODULE=scimでfirefoxが死による件もlibpthead絡みでんな。

Program received signal SIGTRAP, Trace/breakpoint trap.
0xbba4a0b4 in PR_Lock () from /usr/pkg/lib/firefox/libnspr4.so
(gdb) bt
#0  0xbba4a0b4 in PR_Lock () from /usr/pkg/lib/firefox/libnspr4.so
#1  0xbba4edee in PR_JoinThread () from /usr/pkg/lib/firefox/libnspr4.so
#2  0xbbbe6b03 in pthread_create () from /usr/lib/libpthread.so.1.0
#3  0xbb0dc5b0 in swapcontext () from /usr/lib/libc.so.12

おっちゃんてっきり文字コード絡みだとオモテタヨ、もういやこのinputmethod。


2009/1/25(Sun)

昨日

塩崎さんとこ、ホスト時刻をクエリした結果でdate(1)するならば
VMware Command Line Toolsのvmwでいけますね。
まぁclock_settime(2)相当がdate(1)からは設定できないので、vmw time -u/U使う方がいいかも。
ってvmware-synctimedはそこまでやってなかったのか。
(追記)
clock_settime(CLOCK_REALTIME)とsettimeofday(2)はNetBSDの場合同じだそうです。

ピュアUNIX、ピュアオーディオを極めると発電所に気を使うように
anonymous cvsのcheckout元も選ぶのは当然ですね。
mirror間隔によってはレイテンシが問題になりますし、またCVSROOT/configの設定次第で
$NetBSD$の解釈が異なるので、source中の__RCSIDが変わってしまいますから。
結果的にbinaryのサイズやident(1)の出力結果に悪影響があります。
ネタでpureunix.orgドメイン取得してみたものの、これSCOに訴えられそうだな。

modload compat_linuxできない件は最新のkernelだと直ってるっぽい。
しかし何が原因だったのかcommit logみてもよーわからん。
ちゅうかCOMPAT_[0-9]+はkmodにしないほうがいいような事をchristos氏がゆうとるね。

[pcc] pcc wide-character supports

commitされよったな。

あれ 前も書いたよにCSI wchar_tでなく__STDC_ISO_10646__なwchar_tのことしか考えとらんので
glibc2とかMirBSDとかいうアレな実装でしか正しく動きませんです。
OpenBSDも今やsingle byte localeのみだけどCitrus mergeしてるので
ISO-8859-1 locale以外はアウトな訳で、theo様とかespie氏あたりブチキレて欲しいんだが
逆にああそうだねとかwchar_t as UCS4に直しそうだよな。
それが世界の選択か…ラ・ヨダソウ・スティアーナ。

まぁ文句の一言でもいやいいんだろうけど、説明するのめんどくさいし(xfree86-i18nの悪夢)
いったらいったでコード書かにゃならんのはlocale-dbと同じなので、放置しとく。
どうせgccのwchar_t回りもたいしてかわらんウンコだしな。

んで誰commitと思ったらgmcgarry氏か、NetBSD-developerじゃないの…

今日

某スレ書き込めないのでこっち。

269 :名無しさん@お腹いっぱい。:2009/01/24(土) 14:40:25
    -current の date の出力に吹いたww

>>269 すいません、date(1)のソースにフォーマットがハードコードなんですよ。
# でもFreeBSDってもう何年もこの状態じゃなかったっけ。
早々に直したいんですが、LC_TIMEの仕様だとd_t_fmtには
曜日とタイムゾーンを含まないもんで、どうしようか悩んでるとこです。
# Solarisのようにd_t_fmtに含めちまって逃げる、かなぁ…

274 :名無しさん@お腹いっぱい。:2009/01/24(土) 21:26:33
    「寄付金でi18nのえらい人にMac買ってあげて!」っていうのはあり? 

>>274 お気遣いなく、お気持ちだけで結構です。桜が咲く頃には IYHしてしまう予定ですので。
寄付ならTNFへして頂いた方が良いかと。
# あと別にえらくないですってば。

今日2

ピュアUNIX、NetBSD 0.8をリマスタ + 紙ジャケ + SHM-CD化で世界初install CD化決定というのはどうだろう。

なんというBloody Monday、このワームはきっとPython製に違いない。

最近のHuman Leagueのライブなんちゅー映像をみたら、すっかりオッサンオバサンになって
肥満リーグなメンバーが、当時のままの服と化粧で歌ってて、ズゴックTシャツの人より切なくなった。

結局glibc2にならってLC_TIMEに拡張フィールドを追加する方針で固まった。
さすがにSolarisのようなkludgeをするくらいなら、非標準だろうが追加しちまったほうがまだマシ。

…なのだが、早速CITRUS=noの場合の為に残したlocaleio周りで困った。
libcはplain textなLC_TIME dbにこの新しいフィールドがあるかないかは
結局、行数を数えるという原始的な手段をとる他にゃいので
localeio.cの__loadlocale()のIFを再設計しないとあかん、互換性を軽視し杉。

あとはERAか、 西暦2147483647年問題はまぁ別にいいか。
21億年後だし、時期が来れば誰かがera-struct_tm枝を切るでしょ。

(追記)
とりあえずstrftime(3)で"%+"をサポートしたのと、mklocale srcに定義追加した patch
まだUI-OSF日本語環境実装規約他とつきあわせてないのと
plain textなlocale-dbを使った場合の後方互換性確保の部分を実装してないので
experimentalちゅーことで。

これでLC_TIMEのversionが++するので、どうせならERAも突っ込みたいので
releng-5にpullupする時間的余裕はないです;-<


2009/1/26(Mon)

[NetBSD] pkgsrc/wip/scim

SCIM、-pthreadつきでbuildされるようになったので、ximとして使う限りはまともに動いてる模様。
ただしgtk2のimmoduleとして使おうとすると相変わらず即死。
んでこれはpthreadとは無関係ですわ、pthread_create()近辺ではあるけど、落ちる場所が毎回違うってのは以下略。
ということで-D__STDC_ISO_10646__を定義してucs4_tでなくwchar_tを使うようにすると落ちない、なんぞそれ。
ちゅうことでscim_chartraits.cppがどっかまずくてgtk2相手だとクラッシュしてる模様。


2009/1/27(Tue)

昨日

時間制限食い放題お好み焼き@川崎。あんまりジャンクフード好きじゃないのと
大人気ない振る舞いする客をみて、心が貧しくなりそうだったので金置いて先に帰った。

[NetBSD] strange output date(1)

こないだのpatchではstrftime(3)の%+を実装しただけで、date(1)用のformat stringはnl_langinfo(3)経由では
あえて取れないようにしてのだが、他の実装を調べたらSolarisもglibc2もどっちもlanginfo.hのnl_itemに
_DATE_FMTという拡張が追加してあって、date(1)はこいつをnl_langinfo(_DATE_FMT)で取得してるのな。
むしろstrftime + "%+"は実装しないがトレンドみたい。
寄らばタイキのイン(←なぜか変換できない)ちゅーことそっちに合わせるか。

patch

nl_langinfo(3)用のデータは_locale_cache_tでキャッシュを持ってて、追加になるとarray sizeが変わる。
それにつられて_locale_impl_tのoffsetが変わってしまうのだが、これはあんまりいい作りじゃないな。
_locale_impl_tはconstructorがあるし、libc外からlocale_impl_tのフィールドを直接参照することは無いので
binary互換には影響はないんだけど(というかそれを見越して後でどーせ変えられるいいやと思って
今みたいに書いた、いまは 反芻反省している)。multi-localeでもうちょい整理したいとこだあそこは。
_locale_cache_tは将来的に性能の為にinlineに展開しちまう可能性もあるしな。

glibc2のlanginfo.hをみる限り、やぱしLC_TIMEなどもwide-character版の情報を持ってるのよな。
例えばnl_itemに_NL_WABDAY_1とかある、locale dbに持ってるのかon the fly生成なのかは知らんが。

まぁNetBSDではlocaledef(1)の時点でLC_CTYPE=Runeはmbrtowc相当の機能が必須なので
wide-character版をlocale dbに持っておくことは可能、性能の落ちるon the fly生成は不要だな。

ただしNetBSDの場合LC_*がMDなglibc2(/usr/lib)と異なりMIなわけでして(/usr/share)
そこにwchar_tちゅうMDを突っ込むのがなんとも微妙、ILP64とかSILP64なんかだと
どうしてもfixupが必要になってしまうのよな、NetBSDがCrayとか移植された時に困る(ぉ

[NetBSD] pkgsrc/wip/scim

簡単なgtk2アプリで動かすとこんな落ち方をする模様。

Program received signal SIGSEGV, Segmentation fault.
0xbb39fb51 in _malloc_prefork () from /usr/lib/libc.so.12
(gdb) bt
#0  0xbb39fb51 in _malloc_prefork () from /usr/lib/libc.so.12
#1  0xbb39fdd7 in free () from /usr/lib/libc.so.12
#2  0xbacb31a3 in operator delete () from /usr/lib/libstdc++.so.7
#3  0xbab60927 in std::basic_string<unsigned int, std::char_traits<unsigned int>
, std::allocator<unsigned int> >::_Rep::_M_destroy ()
   from /usr/pkg/lib/libscim-1.0.so.8
#4  0xbab87bab in std::basic_string<unsigned int, std::char_traits<unsigned int>
, std::allocator<unsigned int> >::assign () from /usr/pkg/lib/libscim-1.0.so.8
#5  0xbaba8d31 in scim::TransactionReader::get_data ()
   from /usr/pkg/lib/libscim-1.0.so.8
(以下略)

これscim_transaction.cppのTransactionReader::get_data(WideString)の

str = utf8_mbstowcs (mbs);

で死んでるのか、jemallocかなぁ…

ちゅうか、 kinput2 + wnnで落ちるのと同件のような気がしないでもない。

_malloc_prefork()の中見るとmutex_lockかけまくっとる、やっぱりpthreadなのかなー。
NetBSD以外の環境で動かしてみるか、otto@ mallocなOpenBSDあたりで。


2009/1/29(Thu)

昨日

近所の造園業者の庭にある枝垂れ梅が咲いてる、ってもう来週あたりから各地で梅まつりなのか。
昼寝してるネコの表情もだいぶ弛んできとる。

この業者って近所一帯の街路樹の剪定もやってるのだが、ありえないくらいに丸坊主にしてくので以下略。
なんつーかガリガリ君一口あげるゆーたら棒だけ返ってくる感じ、景観がみすぼらしくなって困る。
電柱と道路さえよけりゃいいってか。

花屋。


2009/1/30(Fri)

[NetBSD] libnbcompat

pwd_mkdb(8)、time_tでなくnbtime_tのようにしてホストのtime_tとは切り離さないとダメな気が。
んで芋蔓でtime.hあたりの関数も以下略、でもそれはさすがにキツイか。
time_tくらいならホストのを使って最終的にserializeする時にターゲットに変換ですかね。
このへん今のlibnbcompatは全くあてにならない、先日mklocale(1) + CHAR_MAXでも
ホストのCHAR_MAXが使われてしまうことに悩み、結局NBCHAR_MAXに書き換えて逃げたと
本人は供述しており動機は不明。

[C言語] iconv(3)が扱うのは文字列ちゅーかバイト列でんがな

ホントは重箱の隅タグが適切だな。

iconv(3)で時々みかけるのが

void
convert(const char *s)
{
	iconv_t cd;
	char *input;
	size_t input_bytes, ret;

	...
	input = s;
	input_bytes = strlen(s);
	ret = iconv(cd, &input, &input_bytes, ...);
	...

ちゅう使い方、 これなんかそうやね(from kbkさんとこ)。
変換元の文字列の長さ判定にstrlen(3)使ってしまっとるのだが
これ変換元のencodingがUTF-16/32とか'\0' != L'\0'である可能性を忘れとるので
誤作動する可能性もある行儀の悪いコードと云わざるを得ない。

変換元の文字コードがnl_langinfo(CODESET)、つまり現在のlocaleの文字コードであることが
100%確実であればstrlen(3)は必ず正しく動くと保障できるので、この限りではありませんが。
(nul-terminateされてないとか初歩的なアレは別ですが)

それと同様に

	...
	output_left = output_size;
	ret = iconv(cd, NULL, NULL, &output, &output_left); /* stateを初期状態に戻す */
	...
	output[output_size - output_left] = '\0';
	...

のように変換後の文字列バッファに対してnul-terminateを付与するコードもありがちですが
これも変換後のencodingがUTF-16/32だったりする可能性を忘れとるわけでして決していいコードではないのよね。

まぁこっちのケースは誤作動することはないし、このoutputをlength checkをせず'\0'で末端を知る関数
例えばstrcpy(3)などに渡したとしてもbuffer overrunを防ぐことはできるという(まぁそんな関数に渡すこと自体
激しく間違ってるわけですが)利点?はあるから許容範囲かもしれない。

これ変換後文字列がnul-terminateされてることを保障したければ変換前文字列をnul-terminateしろ
(そうすればiconvをNULL引数で呼んでstateを初期状態に戻す必要すらない)ちゅうのが大原則なんだけど
部分文字列だったりするとコピーが必要になってしまうし、そもそも変換前の文字コードのnul文字が0x0なのか
{ 0x0, 0x0}なのか { 0x0, 0x0, 0x0, 0x0 }なのか判らん状態だと、手の下しようがないという問題もあるのが困るやね。
だからこれも変換後の文字コードを現在のlocaleの文字コードであることを保障してやって'\0'を使うあたりが落とし所かも。

まぁstr*とmem*の使い分けもままならないレベルのC初心者にiconv(3)は難しいってことで。
コードを読む時に、スラスラと脳内でs/char/byte/の置換ができるようになった上で、用心して使えと。

そもそも文字コード変換なぞ必要のないよう、CSIでアプリを書くことを覚えろといいたいところなんだけど
最近はUTF-8決め撃ちのプロトコルとかも多いのでそうもいかないのが泣き所。
昔はCSIで書けば文字コード変換なんて必要なかったんだけど、今ではそういうDQNの為に
逆に文字コード変換が必須になっちまってるからなぁ、トホホ *1

まぁこの手のサンプルでまず省略されてる(というか誰も理解し切れてないと思われる)エラー時の処理を含めた
iconv(3)のサンプルは この記事の最後にあるやつとか *2xvmwareに同梱のiconv_wrapper.cでも読んでちょ。


*1:まぁその為のiconv(3)なんですが。
*2:これも重箱の隅つつけば、バッファをニバイ、ニバーイする部分でsize_t overflow対策してないとかあるけど
ふつー溢れる前にmalloc(3)とかrealloc(3)の上限値に引っかかるからね…


今日

カッコイイは正義、おいらはコフキコガネとかハナムグリのマットな質感が好き。

マットな質感といえば、ネオブラック仕上げが美しいMinolta XD。
ここんとこASA設定/露出補正ダイヤルの動きがシブいなと思ってたら摺動抵抗体が壊れてたよおい。
具体的にはブラシの下にある白い半円形の板が接着剤剥がれしとる orz

修理見積取ってみた、軍艦部の分解だけで直るけど基本料金17〜18kから。
…うーん中古良品買えてしまう、しゃあねぇ自分で直すか…

ちょうど手元にジャンクの外装ボロボロなXDがあったのでこいつで予行演習してみる。
巻き上げレバー、シャッター速度ダイアル、巻き戻しクランクあたりの解体は簡単なんだけど
アイピースシャッター開閉レバーが外れず悩む、これ隠しネジでもないし引っ張っても抜けないし…

2〜3時間悩んでやっとわかった、これ外側からでなくて内側からネジ止めされてるのか(気づくの遅杉。
同XEは目隠し剥がしてネジを外さないと軍艦部を下ろせなかったので
XDもそうだろうと思いこんでしまったのが失敗だった、触らずそのままでOKということだ。

このジャンク、露出計死んでるヤツをスクリーン部品目当てで確保したやつなんだが
今回バラして各部接点のお掃除したら息を吹き返してしまったぜ。


2009/1/31(Sat)

今日

ググル曰く、このサイトはコンピュータに損害を与える可能性があります。

30万のスーツがダメなら、麻生総理には ヌクンダ将軍みたいなB系を目指してもらうしかないな。
一方民主はイオンのスーツコーナーに並ぶのか。

げー、 DNP CENTURIA生産終了のお知らせ…だと。サクラカラーの末裔ついにオワタyo
コダフジではもうISO200なネガ消滅してるので、DNPは重宝したんだが。

一方^1復活AFGAの中の人、 フェラニアのSolaris(not SunOS)が日本再上陸とかいい話もあるんだけど。

一方^2ポラロイドは 復活した8万4千円です…かと思いきやイルフォのサポートがあるのか。

そいやKodak Ektar100店頭に並んでるね、通常のC-41現像では売りの超微粒子とやらには
ならないので、別途Ektar仕上げを頼む必要があるそうだ、T-MAXもそんな感じだっけ?

露出計が復活したかに見えたジャンクXDだけど、露出計が作動するより先に
シャッター切れてしまう問題があるわこれ、困った。

一箇所フレキ切れてたりすんだけど、これが原因ならシャッター自体が切れない希ガス。
ググルと経年劣化でこの症状が、ちゅー記述がヒットするので、コンデンサを疑ってみるべか。
とりま電池ボックス周りを交換してみるか、部品探そう。


[ホームへ] [ページトップへ]