最近の(でもないけれど)出来事/落書帳/仲間内のネタ/覚え書き/whatsnew

基本的に落書き帳/メモ帳/備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。


Wed,01 Jul,2009

今日の出来事: C/C++ での int型のデータ長が具体的に幾つなのかは決まっていません。
C/C++ では、変数の型に関しては、 signed/unsigned char型は1文字を格納できるサイズ (但し、C99 にて 8bit以上と定義されたらしい?)、 short int型は char以上のデータ長、 int型は short以上のデータ長、 long int型は int以上のデータ長、 long long int型は long int以上のデータ長(C99?)、 double型は float以上のデータ長、 ポインタ型はポインタを格納できるデータ長、 とだけ定義されているらしい。 たぶん。 もしかしたら多少間違えているかも。
なので、 char が 7bit だったり (電子メールで EUC,SJIS,UTF,UCS が使用禁止なのは、 この辺が多少関連したと思った)、 int が 14bit だったり(ATMEL とか PIC のメモリ領域の一部)、 int が 16bit だったり(10年以上前は普通16bitだった)、 int が 64bit だったり、 する事もあり得る。
一時期バグが頻発して有名になった所で、 ポインタ型が 64bit で int型が 32bit とか。
また、 char に格納する文字コードは定義されていないので、EBCDIC もありえる。

理由は忘れたが5分前後の遅れ。

Thu,02 Jul,2009

今日の出来事: プロテクト付きのデバイスドライバは、 ハードウェアライセンスキーを接続しないと、動きません。
先日の MS-Windows XP のマシン、 結局、待ちきれなくなって、 データやソフトが死んだらあきらめろ、と言う事で、 HDDフォーマットせずに上書きインストール、になったらしい。
今度は起動はする様になったけれど、 ハードウェアを認識しないらしい。
USBトークン型ライセンスキーが外れているんですけど。

理由は忘れたが5〜8分前後の遅れ。

Fri,03 Jul,2009

GNU/Linux で FFS, UFS2。
Linux-2.6.5〜2.6.6辺りで、 UFS/UFS2ドライバがマージされていたらしい。
mount -t ufs -o ufstype=44bsd /dev/hda1 /mnt
とか
mount -t ufs -o ufstype=ufs2 /dev/hda1 /mnt
とかで、 FreeBSD/NetBSD/OpenBSD UFS や FreeBSD UFS2 も マウントできるらしい。
GNU/Linux で UFS2 な / とか /usr とか言う無茶もできるのだろうか?。   でも、Linux-kernel で UFS2 使っても、 下位層ドライバの信頼性が不足 (UFS2のアルゴリズムの信頼性よりも LinuxのRAWディスクアクセスのドライバの信頼性が低い)するから、 信頼性の観点ではあまり意味無いかも。
UFS2 softupdate 対応か否か見るの忘れた。 まぁ、Linux の RAW ディスクアクセスのドライバがアレだから、 softupdate 対応する意味が無いかも。

kakasi を試してみた。
杏仁豆腐 あんずひとしとうふ
空時間 そらじかん
空容量 そらようりょう
割付額 わりつけひたい
……。 完全自動化するわけには行かない様だ。

anthy-9100h。
のすけ氏のサイトで何年か前にリストアップされていた誤字一覧が、 一部治っていない。
該当部分の抜粋:anthy_dic_konosuke_memo.txt
「ず」「づ」、「いばらき」が「いばらぎ」になっている、あたり。
「がく」「がっ」は、どちらがよいのだろう?。

Sun,20 Sep,2009 追記:
vagus氏 - 丘の道を登り - 2009年09月15日
「いばらぎ」は正しいらしい。御指摘、有り難うございます。

Sat,03 Oct,2009 追記:
以前のは誤記で、「いばらぎ」は誤りらしい。

Sat,04 Jul,2009

ロバート L フォワード、スタークエイク Starquake。
借りようとしたら、 経年変化による老朽化でページがパラパラとこぼれ落ちてきた。 返却後は修繕が必須らしい。
ふと、前半 1/3 の部分だけで1冊書こうとしたけれども、 足りなくて今の構成になったのではないかと思った。
前作の終盤で異星人が描写しきれていない様な感じがするのは、 この作者の書き方のクセかもしれない。今作でもそうなっていた。
カー時空のスペースワープって、カーは ker だっけ、と思ったら、 正しくは kerr らしい。 でも、カーが k って、そもそもどこで覚えたのだろう?。
話の結末は、哲学的に多大な問題をはらんでいる気が。 人によって、Happy End とみるか、Bad End とみるか、 大きく変わると思う。   ……。   もしかしたら、 欧米の場合は「神 = もたらすもの」「魂 = 思考パターン」、 日本の場合は「神 = 見守っているもの」「魂 = 肉体に宿っている何か」、 と、根本的な所で考え方が違うのかも。

EIZO M1700C-R ¥15,000-。サムスン TN 8ms らしい。
DVI-D (SingleLink)ケーブル ¥800-。
USBケーブル A-miniB 中古¥200-、秋月だと 新品¥150-、千石だと 新品¥230-。

Let's Fire, Second Fire 各¥250-。

攻殻機動隊1.5 紙の方 ¥350-。

娘フロ ¥980- で3枚、 娘トラ(盤面にキズ)¥980- から2割引で1枚、 娘たま¥2,180?で1枚。

千石の webカタログより引用。
Sケーブル 0.5m ¥200-、1.0m ¥250-、1.5m ¥280-、2.0m ¥340-、3.0m ¥440-、5.0m ¥530-、10.0m ¥690-、15.0m ¥850-、20.0m ¥1,010-、30.0m ¥1,340-。
S+ステレオ ケーブル 0.5m ¥260-、1.0m ¥340-、1.5m ¥450-、2.0m ¥510-、3.0m ¥610-、5.0m ¥820-、10.0m ¥1,470-、15.0m ¥1,970-、20.0m ¥2,440-、30.0m ¥3,220-。
HDMIケーブル 1.0m ¥730-、1.5m ¥870-、2.0m ¥940-、3.0m ¥1,230-。
HDMI - DVI-D(DualLink) ケーブル 1.8m ¥1,470-。
DVI-D(DualLink)ケーブル 1.0m ¥1,150-、1.8m ¥1,230-、3.0m ¥1,450-、5.0m ¥2,230-、10m ¥3,980-。
DVI-I(DualLink)ケーブル 1.8m ¥1,750-、3.0m ¥2,000-、5.0m ¥2,750-。

秋月の webカタログより引用。
Sケーブル 1.5m ¥380-。千石より質が低くて値段が高い。
D端子ケーブルはあるけれど、DVI や HDMI は無いらしい。

ドスパラの webカタログより引用。
Sケーブル 1.0m ¥280-、2.0m ¥320-、3.0m ¥340-、5.0m ¥380-。
S+ステレオ ケーブル 1.0m ¥310-。
HDMIケーブル 0.5m ¥980-、1.0m ¥1,680-、1.5m ¥1,880-、2.0m ¥2,180-。
HDMI - DVI-D(DualLink) ケーブル 1.5m ¥2,100-、3.0m ¥2,700-、5.0m ¥3,900-。
DVI-D(DualLink)ケーブル 1.8m ¥1,380-、3.0m ¥1,595-、5.0m ¥1,680(特売品)。
Sケーブルだけは何故か千石より安い。

ヨドバシの webカタログより引用。
Sケーブル 1.0m ¥588-、2.0m ¥756-、3.0m ¥882-、5.0m ¥1,134-。
S+ステレオ ケーブル 0.5m ¥1,180-。
HDMI(HighSpeed)ケーブル 0.7m ¥1,480-、1.0m ¥1,680-、1.5m ¥1,880-、2.0m ¥2,180-。
HDMI - DVI-D(DualLink) ケーブル 1.0m ¥2,980-、2.0m ¥3,480-、3.0m ¥3,980-、5.0m ¥5,780-。
DVI-D(DualLink)ケーブル 1.0m ¥2,480-、1.5m ¥3,080-、2.0m ¥3,280-、3.0m ¥3,580-、5.0m ¥4,780-。

ソフの webカタログより引用。
Sケーブル 1.5m ¥586-、2.0m ¥900-、3.0m ¥733-、5.0m ¥882-。
HDMI(HighSpeed)ケーブル 1.0m ¥1,780-、1.5m ¥1,980-、2.0m ¥2,280-。
DVI-D(DualLink)ケーブル 1.0m ¥3,085-、3.0m ¥3,580-。

Sun,05 Jul,2009

EIZO のディスプレイが無くなっていた。

Let's Fire, Second Fire 各¥500-。

Sケーブル ¥300-、千石だと 1.5m ¥280-、ドスパラだと 1.0m ¥280-。 鉄騎のコントローラのペダル部分は無くなっていた。
640MO ドライブはたぶん無くなっていた。

Let's Fire, Second Fire 各¥250- 無くなっていた。

Second Fire, GALAXY Chart.1, GALAXY Chart.2 各¥500-。

ハウルのサントラ¥250- 無くなっていた。 もののけ姫のサントラ ¥250-。

GALAXY Chart.1 ¥250- 無くなっていた。

店頭に並べてある商品にローテーションがかかっている?。 それとも、もしかして¥250-まで下がると、 転売屋が底引き網漁をかけるのだろうか?。 amazonで中古価格を見てみると、¥200-を下回っているのだが。

Diamonds、プリンセス・プリンセス、1989.4.21。

Tue,07 Jul,2009

七夕。

梅雨なのに全然梅雨があまり降っていない気がする。 その割に土砂降りの雨が降ったりするし。

どうでもいいネタ。 なお、正しいかどうかは不明。
墓石の天辺が四角錐なのが神道で、平らなのが仏教らしい。 ただ、墓石がどうのこうのこだわるのは日本の仏教だけらしい。

奈良仏教系(南都六宗系) 華厳宗: 南無という言葉が無い時代にできた宗派らしい?。
奈良仏教系(南都六宗系) 法相宗: 南無という言葉が無い時代にできた宗派らしい?。
奈良仏教系(南都六宗系) 律宗: 南無という言葉が無い時代にできた宗派らしい?。
平安仏教(平安二宗)系・密教系 真言宗: 南無は使わない。
平安仏教(平安二宗)系・密教系 天台宗: 南無阿弥陀仏。
法華系(鎌倉仏教法華系) 日蓮宗: 南無妙法蓮華経。
浄土系(鎌倉仏教浄土系) 浄土宗: 南無阿弥陀仏。
浄土系(鎌倉仏教浄土系) 浄土真宗: 南無阿弥陀仏。
浄土系(鎌倉仏教浄土系) 融通念仏宗: 不明。
浄土系(鎌倉仏教浄土系) 時宗: 不明。
禅系(鎌倉仏教禅系)・禅宗系 曹洞宗: 南無釈迦牟尼仏。
禅系(鎌倉仏教禅系)・禅宗系 臨済宗: 南無釈迦牟尼仏。
禅系(鎌倉仏教禅系)・禅宗系 黄檗宗: 不明。

Wed,08 Jul,2009

OpenBSD で CnQ/SpeedStep/EIST。
/etc/rc.conf.local にて apmd_flags="-A" もしくは "-C" らしい。
apmd の負荷計測インターバルは1秒毎なので、 負荷が上がってから速度が上がるまでにその位の遅延がある、 ので、ちょっとレスポンスが悪い。
アルゴリズムは、 -A の場合は、 負荷が上がったら即座に最大速度、 その後に余裕があれば速度を毎秒 20%ずつ下げる。 -C の場合は、 負荷が上がったならば速度を毎秒 20%ずつ上げ、 負荷が下がったならば即座に最低速度。
FreeBSD の標準の powerd の場合、 速度を上げる時も下げる時も 0.5秒毎に1段階ずつで、 ちょっとレスポンスが悪い感じがするので、 個人的には OpenBSD の apmd -A の方が好き。 まぁ、手元の FreeBSD の powerd では、 既にそう言う改造をしてあるけれど。
ただし OpenBSD でも FreeBSD でも、 AMD K10 な Phenom は未対応らしい。

Unix系汎用の文字コード表の表示ソフト。
UCS/Unicode の文字コード表の表示ソフトは見かけるけれども、 JIS や EUC の文字コード表の表示ソフトが見つからない。
……。
fontforge にて、拙作の JIS 対応プラグインを使えば、 代用になる事に今更気付いた。

anthy-9100h。
compound.t にて。 「自動調整」(じどうちょうせい) #T35 なので、 「する」が付属語にならない。 たぶん #T30。

↑。
複合語は、ひょっとしたら品詞を持つ必要は無いのでは。 構造を考えると、末端の単語の品詞をそのまま使えば良い筈だし、 末端の単語の品詞とは違う品詞を持つ様だと、 それは複合語ではなくて別の単語だと思う。

かな漢字変換の変換所要時間。

約5秒		中性子星《卵》の1日。
3秒		のび太が寝っ転がった状態から昼寝を開始するのに必要な時間(ごく初期の版)。
約2.6秒		月面との通信での遅延時間(往復)。
約1.3秒		月面との通信での遅延時間(片道)。
930msec		のび太が立った状態から昼寝を開始するのに必要な時間。
239msec		静止衛星との通信での遅延時間(往復)。
119msec		静止衛星との通信での遅延時間(片道)。
104msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。ビタビ(-g3 -O0)、PentiumD 3.2GHz。
98msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。ビタビ(-g3 -O0)、PentiumD 3.2GHz。
95msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。4文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
94msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。3文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
93msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。2文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
85msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。4文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
83msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。3文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
83msec		Anthy拙作パッチ版で、1文の内容を変換するのに要する時間。2文節最長一致(-g3 -O0)、PentiumD 3.2GHz。
64msec		Anthy原作版 + alt-depgraph-090525 で、1文の内容を変換するのに要する時間。ビタビ(-g3 -O0)、PentiumD 3.2GHz。
64msec		Anthy原作版で、1文の内容を変換するのに要する時間。ビタビ(-g3 -O0)、PentiumD 3.2GHz。
63msec		Anthy原作版で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。ビタビ(-g3 -O0)、PentiumD 3.2GHz。
50msec		蒸着。
41msec		Canna-3.5b2 + WX3の辞書(anthyの辞書全てと同じ位の量)で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g3 -O0、PentiumD 3.2GHz。
39msec		Canna-3.5b2 + WX3の辞書(anthyの辞書全てと同じ位の量)で、1文の内容を変換するのに要する時間。-g3 -O0、PentiumD 3.2GHz。
33msec		フレーム速度1/30での1フレーム。
24msec		Canna-3.5b2 + alt-cannadicのgcanna で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g3 -O0、PentiumD 3.2GHz。
21msec		Canna-3.5b2 + alt-cannadicのgcanna で、1文の内容を変換するのに要する時間。-g3 -O0、PentiumD 3.2GHz。
17msec		フレーム速度1/60での1フレーム。
16msec		Canna-3.5b2 で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g3 -O0、PentiumD 3.2GHz。
15msec		Canna-3.5b2 で、1文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz。
13msec		Canna-3.5b2 で、1文の内容を変換するのに要する時間。-g3 -O0、PentiumD 3.2GHz。
12msec		Canna-3.5b2 で、1文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz。
1msec		赤射および焼結。

備考:Anthy の場合、-O0 から -O2 に変更すると、大体2倍くらいに速くなる。

1文 = 10文節。
変換内容:「tatoebakonnnakanzinobunsyouga10bunnsetutonarunaiyouwohenkansurutokekkahadounarunodarou.(space)」
変換内容を平仮名表記:「たとえばこんなかんじのぶんしょうが10ぶんせつとなるないようをへんかんするとけっかはどうなるのだろう。」
期待する変換結果:「(3 ((UL RV) "例えば" 0 3) ((UL) "こんな感じの" 0 4) ((UL) "文章が" 0 6) ((UL) "10文節となる" 0 3) ((UL) "内容を" 0 5) ((UL) "変換すると" 0 5) ((UL) "結果は" 0 7) ((UL) "どうなるのだろう" 0 2) ((UL) "。" 0 3))」
プログラム内で同じ変換を100回行い、その処理に要する時間を計測し、1回当たりの変換時間を算出した。

ネットブックだと、この 2.5〜3倍くらいかかると思う。たぶん 160〜300ms くらい。
のび太に昼寝されずには済むが、シューティングゲームや格闘ゲームだと 10〜15フレームくらい経過してしまう。

Android携帯や iPhone携帯だと、この 12〜16倍以上はかかるのではないかと思われる。もしかしたら 750ms〜約2秒。
のび太に昼寝される可能性があります。

拙作パッチで5割も遅くなっているのは、
変換内容への学習の適用と、変換結果からの学習の抽出にて、
大幅に変更(もしかしたら木構造データベース処理部以外は全部書き変えたかも)し、
大量の文字列の取り出し/連結/分割を行う様になったのが効いているのではないかと思われる。
# anthy の設計仕様では、通常の文字列処理1回に付き malloc() が2回と free() が2回付いてくるが、これの負荷が高い。

FreeWnn とも比較してみたいのだが、やり方が判らん。
もっとも、体感では Wnn は Canna よりも遅かったが……。


Thu,09 Jul,2009 追記:
Canna35b2 の変換所要時間を計測。なんとなく体感してはいたが、やっぱり速い。但し変換結果はまるで出鱈目だった。
「タトエバコンナカンジノブンショウガ10ブンセツトナルナイヨウ を 変換すると 結果 波動 奈留のだろう。」
読点を突っ込んでようやくそれっぽくなったが。
「例えば、 こんな 漢字の、 文章が、 10 文節となる、 内容を、 変換すると、 結果は、 どう 奈留のだろう。」

結論:
体感していた通り、Anthy の変換は遅い。
ただ、Cannaは速いと言っても連文節の区切りを覚えてくれないから……。

数百ms で処理される様な有名なネタが思い付かない。 むしろそちらが本命だったり。

Fri,10 Jul,2009

独断と偏見による各種 OS の概要解説。 を外から閲覧できる場所に移転。

昨日のかな漢字変換の速度の話の続き。
canna をインストールしようとしたら、 ビルド中の pod とか言う部分の処理で SIGSEGV で死んだ。
毎度お馴染み、gdb して、step して、 それでも判らないから step して finish して info reg して、 ようやく判明。
Canna35b2/dic/ideo/pubdic/pod.c に #include <stdlib.h> が無くて、 malloc() がプロトタイプ無しの関数とみなされ、 返値が int に暗黙の強制キャストを食らって、 値が 64bit から 32bit に強制変換を食らってポインタが壊れていた。
またこのオチかよ……。

↑ Wnn4.2 の Xsi/Wnn/jutil/*.c でも、 同じオチで SIGSEGV した。

今月の Design Wave Magazine(CQ出版) じゃなくて Digital Design Technology(CQ出版)。
ありきたりの本屋で普通に平積みされている雑誌としては久しぶりに、 質が高くて新人にも勧められそうな記事だった。 と思ったら、DWM DDT でしかも CQ出版か。 じゃぁ特段と言う事も無く普段通りかな。 DWM は安定して質が良かったし、 CQ出版の質は安心していられるレベルだし。
むしろ問題は、何月号辺りまで、ありきたりの本屋で平積みされるかだ……。 近年は Interface とかトラ技とか置いていない本屋が増えているから……。
今回は HDL 特集で著者は 小林 優 氏らしい。 web で著者名で検索してみても、同姓同名が多くてよくわからん。

Interface と言えば「通りすがりの組み込みもん」(米田 裕 著)。
いつもウケていたが、冷静に考えてみると、 完全に技術屋の内輪受けだよなぁ……。 …… web でも公開しているのか……。 http://www.cqpub.co.jp/interface/kumikomimon/

GTK/GTK+/GTK--(gtkmm)。
チェックボックスやラジオボタンなどで、 ボタンの状態を固定にして操作を禁止するには gtk_widget_set_sensitive( , 0 ); (GTK/GTK+の場合) もしくは set_sensitive( false ); (GTK--(gtkmm)の場合)。
操作を受け付ける状態にするには gtk_widget_set_sensitive( , 1 ); (GTK/GTK+の場合) もしくは set_sensitive( true ); (GTK--(gtkmm)の場合)。

途中駅混雑と車内清掃の為、3〜5分の遅れ。

途中駅混雑と接続待ちの為、3〜5分の遅れ。

Sat,11 Jul,2009

alt-depgraph-090525。

その1:
「未達」(みたつ)が出ない。
読み方は「みたつ」で良いらしい (「大辞林 第二版」web版より。デイリーコンサイスには掲載無し)。 ……これは alt-cannadic に入れるべきなのだろうか?、 それとも個人用の辞書か。

その2:
「捨て駒」(すてごま)が出ない。
……これは alt-cannadic に入れるべきなのだろうか?、 それとも compound.t に入れるべきなのだろうか?。

Fri,17 Jul,2009 追記:
どちらも alt-depgraph-090712 に入っていました。 対応有り難うございます。

Kingmax SD 2GB ¥798-、4GB ¥1,480-。 BUFFALO USB microSD リーダー ¥1,480-。
DMM ¥580- くらい、JIS認証は付いていなかった。 秋月で叩き売りしていそうなタイプ。 ……秋月の叩き売りは¥800-らしい。

EIZO L557 ¥12,600-、 17inch, 1280x1024 DVI-D D-sub 25ms, サムスンPVA、らしい。
EIZO L565 ¥13,800-、 17inch, 1280x1024 DVI-D D-sub(24kHz可) 35ms, 日立 S-IPS、らしい。
EIZO L461 ¥7,350-、 16inch, 1280x1024 DVI-I 45ms, シャープTN、らしい。
EIZO L675 ¥8,400-、 18inch, 1280x1024 DVI-I 50ms, IBM IPS、らしい。
EIZO L685 ¥16,800-、 18inch, 1280x1024 DVI-I 40ms, IDTech DD-IPS、らしい。

BUFFALO microSD 2GB ¥750-、4GB ¥1,480-。

Let's Fire ¥250- ケース割れ。

置き引きにやられた。 自転車の前カゴに鞄を入れて、ひったくり防止カバー (カゴを丸ごとおおって中身が見えなくなるタイプ。 チャックを開けるとフタが上に開く)のフタを閉めて、移動。 到着先で、カゴに鞄を入れた事を忘れていた (カゴの中身が見えなくて、入れた事を忘れていた)。 30分〜1時間後に自転車に戻り帰路。 家に帰り着いた時に、 ひったくり防止カバーのチャックが開いている事に気付いた。 それで、ようやく鞄を入れっ放しだった事を思い出したのだが、 鞄は残っていたが中身が空っぽだった。 被害は鞄の中に入れてあった、 置き引きに遭った駐輪場に行く直前に寄った店で買ったばかりの 中古CD が2枚(鞄の中身はそれだけだった)。   最近の置き引きはひったくり防止カバーを開けてまでして犯るのか。
被害金額にして¥500- なのだが、 14年前の CD で、 しかもレアでもなんでも無くてプレミアがまるで無い為に かえって中古に出回らない (売る様な人はとっくに売ったし、買う様な人はとっくに買った)シロモノ、 さらにせっかく見つけた妥当な売値で、 とどめは買ったばかりで一度も聞いていない。 精神的にヘコむ。

警察に被害届か遺失物届けを出しても見つかる事は無いだろうし、 被害金額¥500- で 係長決済が必要な書類を約10枚(5枚だっけ?)書かないといけないとなると、 かなり嫌がられるし……、 いやまあ、嫌なのは判るけれど……、 検挙ノルマ未達なのにこの程度の被害金額の決済を貰いに行った日には 小言や嫌味を食らうから……。 そっちでも(にっちもさっちもいかないとか、 鬱憤を向ける先が無いとか、言う点で)精神的にヘコむ。

以下、現実逃避の落書きが続く。

店頭展示しているノート型PC。
ネットブックは Atom 1.6GHz しか無いのは当然として。
2.5kg以下で AMD だと、HP か NEC か eMachines くらい。
ACER Aspire5536 Athlon64X2 QL-64 2.1GHz 15.6inch(1366x768) 2.8kg、7〜万円。
eMachines eMD620-T1 Athlon64 1.6GHz 14.1inch(1280x800) 2.4kg。
HP 6535s AthlonX2 2GHz 14.1inch(1280x800) 2.2kg、7万円。
NEC LN500 AthlonX2 2GHz 2.0kg、10万円超。
HP tx2 AthlonX2 2GHz 2.0kg、8〜9万円。
DOS/PARA Cressida NB Turion64X2 1.6GHz 1.9kg、6〜万円。
HP dv2 AthlonNeo 1.6GHz 1.7kg、6〜万円。
eMachines と言ったらツクモを連想してしまうが、 今はツクモ限定では無いらしい。
Athlon64X2 は 64 が当たり前になったので AthlonX2 に改名したらしい。
Athlon64 2.0GHz くらいで 2.0〜2.5kg くらいが、 戦力になりつつギリギリ持ち運べなくも無い範囲だが、やっぱり重い。 AthlonNeo 1.6GHz だと Atom 1.6GHz よりは速いけれど戦力不足。
まぁ、ノートPCでコンパイルなんぞするのを諦めればいいのだろうけれど。 そうすると NEC の Lui方式がだね(以下ループ)。

コンピュータ関連の雑貨。
マウスとか、不揮発メモリとか、CD-RW/DVD-RAM とかは、 ドスパラで叩き売りしていた物よりも、 ツクモで叩き売りしていた物の方が、 値段面でも品質面でも私の好み。
でもツクモって1回潰れたのだよね。 ドスパラのも価格を承知した上で捨て駒にするならば許容範囲だし。 商売に於ける値段と品質のバランスって難しい。

ドスパラの JCB カード決済。
ドスパラは JCB との契約を切られたとかで JCB が使えなくなっていたらしいのだが、 今 web を見たら JCB が使えると書いてあった。 いつの間に復活したのだろう。

マクロスFの劇場版の広告が web で出ていた。
キャッチコピー、 「歌で銀河が救えるわけないでしょ」
……。 ファンなら受けるけれどファンじゃないと全然判らないネタの様な……。 (マクロスFの前々作「マクロス7」の キャッチコピーが「歌は銀河を救う」だった……)

マクロスのちっこい模型みたいな完成品のヤツ 1/250 マクロス ファイター コレクション。
キワモノが VF-2SS しかなくて今一おもしろみに欠ける。 VA-1SS とか VF-4 とか VF-14 とか無いし。
定番とこでも YF-19 とか YF-21 が無いし。 微妙な所で VF-17 とか VF-11 とか VF-5000 とか無いし。
ぶっ飛んだ所で VA-3 とか VB-6 とか無いし。
とか言い出すと全機種が列挙されてしまうか。 むしろキワモノの VF-2 が有る所を驚くべきか。
シークレットは……、 シークレットの響きが合いそうなのはゴーストとか VF-27 とかだが、 金型の都合を考えると……、 VF-25 ルカ機が無いけれどシークレットと言う感じではないし、 VF-25 オズマ機か VF-1S ロイ機か?、あるいは無難に特殊彩色か?。
総額で数千円台後半になりそうで駄目だ、手が出ない。

ヨドバシ。 ポイント還元率+3%らしい。7/31までらしい?。

ビック。 暫く前から、一部商品で最大ポイント還元率+5%らしい。

Sun,12 Jul,2009

鉄道債。
3年 0.63%らしい。 半年前発行の鉄道債が 3年 1.0%なので、ものすごい下がり方。

Second Fire ¥500-。

マウス ¥980-。 ホイール、左側面に追加2ボタン、ホイールの手前に謎のボタン1個。 DPI切り替えかな?。   何種類か5ボタンマウスを常用した感想から言うと、 追加2ボタンは側面(両側各1、片側2、問わず)に有るよりも、 チルトホイールの方が直感的にわかりやすい、 但しホイールの作りが悪いと誤操作しやすい。

工画堂の PD1、新品¥8,580-。

Let's Fire, GALAXY Chart.1, GALAXY Chart.2 各¥500-。

Ultra Fire キズあり¥1,050-。

娘フロ 中古¥1,550- で8枚、娘トラ 中古¥1,550- で6枚。 在庫増殖中……。ちょっと値下がりしたらしい。

ヨドバシカメラのイメージキャラクター。
秋葉じゃないヨドバシにて、いつの間にか、 山手線なマスコットが メイド?なマスコットに変わっていた。 店内のイメージソングも 「権兵衛さんの赤ちゃんが風邪ひいた」(……正しくはリパブリック讃歌) ではない、別の曲に変わっていた。
なんとなく web で検索した所、 あの山手線マスコットは全部が全部山手線ではなくて、 店舗毎に最寄り路線のマスコットにマイナーチェンジしたモデルが 使われているらしい。 全然気付いていなかった。 メイド?なマスコットの方も、 黄+緑バージョンとピンク+赤バージョンと、あるらしい。

alt-depgraph-090525。

「察」(さっ)
「悪」(あっ)
「一」(いっ)
「屈」(くっ)
「欠」(けっ)
「卒」(そっ)
「納」(なっ)
「熱」(ねっ)
「密」(みっ)
「薬」(やっ)
この辺りの単語って、需要が有るのだろうか……。

「察」+「庁」(さっちょう)とか「悪」+「化」(あっか)とか
いう使い方を想定していたのかな?。

「辛」(から)
「っ辛」(っから)
が出ない……。
でも、使わない気もする。

Mon,13 Jul,2009

カゼひいた。

人身事故で10〜30分の遅れ。 ……アナウンスでたまに死傷事故って言っている……。

そしていつも通っている交差点が、 交通事故の処理中だった。   あいにくと、私に手伝える様な事といえば、邪魔しない事くらいだった。

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

学習の再生が微妙に変。 「|(動詞)する|様に|した|。」と学習させてあるのに、 動詞の内容を変えて変換すると、 「|(動詞)する|様に|下|。」になってしまう。
候補を「|(動詞)する|様に|した|。」に選び直して学習させても、 また「|(動詞)する|様に|下|。」になってしまう。
${HOME}/.anthy/last-record2_default を確認しても、 ちゃんと学習されているし、 anthy-agent で見ても、学習のスコアは反映されている。 でも、「|様に|下|」の候補に、 学習を上回る謎のスコアが加算されていた。

ソースを探した所、怪しい所を3点発見。
src-ordering/relation.c:reorder_by_corpus() と src-ordering/relation.c:reorder_candidate() と src-ordering/relation.c:compare_context() 。

reorder_by_corpus() では、 変換内容がコーパスに一致したと判定された場合、 スコアをいきなり2倍にしている。
その為に、学習の内容よりもコーパスの内容の方が優先されている。

reorder_candidate() では、 用例辞書 mkworddic/udict に一致した場合、 スコアをいきなり10倍にしている。
その為に、学習の内容よりも用例辞書の内容の方が優先されている。

compare_context() では、 変換候補とコーパスとの一致判定において、 文を構成する各文節の出現順序問わず、 使われている「変換候補/結果の自立語の漢字表記」が 2つ以上かつコーパスの文に於ける文節数の半分以上が一致するならば、 変換候補とコーパスに記録されている文章が一致したと判定され、 reorder_by_corpus() のスコア2倍が適用されていた。


先の「するようにした」の場合:
まず、コーパスには
「|したの|せってい|ふぁいるを|みよ| |下の|設定|ファイルを|見よ|」
がある。
「せっていするようにした」を変換すると、 変換候補の1つとして「|設定する|様に|下|」と言う物も作られるが、 「設定」と「下」の自立語の漢字表記の2つがコーパスと一致するので、 一致判定の条件「2つ以上かつコーパスの文節数のうち半分以上」を 満たしているので、スコア2倍が適用され、 学習由来の候補や他のあらゆる候補を差し置いて優先されている。


対策について:
コーパスのデータベースにおいては、 文中での単語の出現順序は記録されていない(たぶん)。 従って、 語順がコーパスと一致しているか否かを判定する事はできない(たぶん)。
文節数全部一致に変えると、 多分、ほとんど一致しなくなってコーパスが効かなくなりすぎる。
なので、スコアを、2倍/10倍にはせず、 学習されていない内容以上、学習された内容未満、に変えてみた。


web で何となく検索してみて何となく見つけた話:

anthy 拙作パッチ 20090308版 → 最新版 での、変換結果に影響が出る様な変更箇所は以下の通り:
・x86_64 でコーパスを無視するバグを修正(patch13系の最初からあったバグ)。
・普通の変換中に逆変換が混じるバグを修正(patch13系の最初からあったバグ)。
・文節区切り位置の学習を再生する際に、付属語を変えたパターンも自動生成する様にした。
LATTICE_AUTOEXPAND_DEPS
「|一例を|挙げると|」(|いちれいを|あげると|)を学習してある時に、「いちれいをあげた」を変換すると、
「|一例を|挙げると|」の学習の付属語を変えたパターン「|一例を|挙げ××|」を適用して、
「|一例を|挙げた|」と文節を区切る。
・「ぁぃぅぇぉゃゅょっ」を付属語として連結した時のスコアを最低点に下げた。
DEPGRAPH_WITH_PART
・「スパーギアの」の様な「カタカナ + 平仮名」の変換をした時に、カタカナ部分を勝手に短期記憶辞書?に登録する様にした。
オプションで設定を変える事はできません。
・OCHAIRE 3文節の学習を止めた。
ENABLE_OCHAIRE3*
・文節区切り位置の手動指定をできる様にした。
LATTICE_HINTING_*
・平仮名変換/カタカナ変換をした際に短期記憶辞書?への学習の有無を指定できる様にした。
ENABLE_AUTOLEARN
・変換の際に、直前に変換確定した内容も参照する様にした。
ENABLE_KEEPALIVE_REFER_COMPOUND
ENABLE_KEEPALIVE_REFER_OCHAIRE
ENABLE_KEEPALIVE_REFER_CORPUS
ENABLE_KEEPALIVE_LEARN_OCHAIRE
・自動生成した連用形のスコアを下げた。
CANDIDATE_RENYOU_SCORE_*

同じ内容をタイプする事が多く、
かつ、学習のデータ量に対する効果の比率が大きく悪化しても良い(学習データに無駄なデータが増えても構わない)ならば、
ENABLE_OCHAIRE3_WITHOUT_DEP は true の方が変換結果は多少良くなります。
どうにもコーパスがアレなので、
ENABLE_KEEPALIVE_REFER_CORPUS は false の方が良いかもしれません(デフォルトでは true)。
それから typo が多いなら、
ENABLE_AUTOLEARN も false の方が良いかもしれません(デフォルトでは true)。

それ以外では、変換結果に目に見える変化が出る様な変更は無い筈なので、あとは、
今までよりタイプ量が格段に多くなった影響(気付いていなかった事に気付いた)とか、
締切に追われて typo が増えた影響とか……。

# どうも、タイプ量が格段に増えた上に、締切に追われて typo が増えた、と言う両方の影響の模様。

Tue,14 Jul,2009

昨日、交通事故の処理中だった交差点に、 目撃者の方は連絡して下さい、と言う看板と、 死亡事故発生現場、と言う看板が出ていた。
えええ?。

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

typo の影響が思っていたよりもずっと大きい様なので、 直前の変換確定内容を忘れる機能を追加。

この機能を使う場合には、 フロントエンドのソフトの改造が必須です。 「patch12/patch13/patch13B パターン22:」 を参照。
uim-xim と uim(GTK_IM_MODULE/QT_IM_MODULE) の場合は、 そのページに置いてある scm ファイルに入れ替えれば使える様になりますが、 scim/ibus/iiimf/im/etc... 等、uim 以外のフロントエンドは未対応 (対応予定無し)です。


uim での使い方:
変換確定した直後に、 (BackSpace) キーもしくは Ctrl+h を押すと、忘れます。
確定した後に、 カーソル移動キー/IM-off/ スルーされる入力((tab) とか (space) とか (enter) とか)、 等をしてから (BackSpace) キーもしくは Ctrl+h を押した場合は、 忘れません。
確定した後に、未確定の入力を行い、 それから未確定の入力内容を全て削除して、 さらに (BackSpace) キーもしくは Ctrl+h を押した場合は、 忘れます。

↑ 何かたまに(特に、句読点を余計に打ってしまって消した時) 「いや、それは忘れさせるつもりでは無いのですが」と言う事が 起きるものの、 今までの様に、何が何でも絶対忘れない状態よりは、 使いやすくなった感じ。

↑*2 カーソル移動をマウスで行った後に (BackSpace) キーもしくは Ctrl+h を押した場合でも、 忘れてしまう問題が。
なんか uim_displace_context() が呼び出されていませんよ。 同一ウィジェット内での移動の場合は、displace は呼ばれないのかな?。

↑ alt-depgraph-090525 (最新版に追いついていない)。
alt-depgraph にて、付属語が短くなると、 どうも学習に不利に働いている様な印象が……。 印象だけなので、単なる思い込みかもしれませんし、 個人差が相当大きいとは思いますが。
具体的には、 「|(動詞)した|」が「|(動詞)|下|」になってしまったり、 「|(動詞)いない|」が「|(動詞)|以内|」になってしまったり、 するパターンが、以前より増えた様な……。 (私の場合、 「上」「下」「右」「左」を単語変換するクセがあるので、 「下」の評価値が異様に高くなっているせいも有る)

↑ alt-depgraph の最新版に追いついていないのは、 作業が追いついていないのと、 エンジン側の改造と alt-depgraph の入れ替えの両方を同時に行うと、 どちらの変更の影響で結果が変わったのか判らなくなるから。

Wed,15 Jul,2009

一昨日、交通事故の処理中だった交差点に、 真新しい花が……。

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

読み仮名もしくは変換結果に「"」や「 」(ASCII 20h の SPC)が 混じっていた時に、忘れる事が出来ないバグを修正。

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

mojin氏
> 半角カナがちょっと変。イ〓ク〓ナ〓イ〓、ってなる。

→ 原因
EUC-JP系の 00h(NULL) を UCS-4 に変換する部分にバグがあった。

→ 対処
EUC-JP系の 00h(NULL) を UCS-4 の U+00000000 (NULL) に 変換する様に治した。

→ 備考
uim-anthy とか anthy-agent で変換テストを行うと、 この問題の部分は uim とか agent が処理していて、 anthy のエンジンのテストにならないので注意。

USER-AGENT。
FreeBSD の ftp の user-agent が NetBSD-ftp/???????? な 事に気付いた。何故?

バトルテックリプレイ2 女神たちの彷徨 ¥105-、新品同様の状態の良さ……。
バトルテック グレイ・デス 1/2/6巻 各¥105-、但し背表紙にオビの形の日焼け有り、それ以外は新品同様の状態の良さ……。 3/4/5巻は在庫が無いらしい。
一体、何処から湧いて出たのだろう。

Thu,16 Jul,2009

人身事故の為、1時間遅れ。
そして、 全面禁煙の駅でタバコを吸うヤツラや、 駅員を怒鳴りつけるヤツラや、 駅施設を蹴っているヤツラが出没。

Anthy。それなりにあちこちの OS にて、 コーパス情報が不適切だったりする事がある問題。

今までずっと、 alt-depgraph 同梱のコーパス情報(corpus_info と weak_words)と、 手元で再計算したコーパス情報(corpus_info と weak_words)が、 一致したり一致しなかったりして、疑問に思っていた。
1ヶ所は原作版 Anthy のバグ(GNU/Linux だと高確率で発症せず、 それ以外の OS だと若干の確率で発症し、 BSD系のデバッグ/セキュア用?の設定だと必ず発症する)だったが (問題が顕在化しない部分だったので修正パッチは作成していない)、 それ以外の大量の不一致の原因が不明だった。

どうやら、 システム辞書(anthy.wdic や anthy.dic)の生成の際に、 どの辞書のソース(*.ctd や *.t)を用いるかの 構成(dict.args.in)を変更したり、 あるいは辞書のソース自身(*.ctd や *.t)を変更したりすると、 コーパス情報(corpus_info と weak_words)の一部(半分くらい?)も 変わってしまうらしい。
私の場合、alt-depgraph そのままの構成で使っている事もあるけれども、 辞書の構成(dict.args.in)をちょっとだけ変更する事が多かった為、 コーパス情報(corpus_info と weak_words)が alt-depgraph 同梱版とは違ってしまっていたらしい。

具体的には、 文節区切りアルゴリズムで用いられている部分は、 品詞(anthy の内部処理用の種別。動詞とか名詞とかの方では無い)を 変えた場合は変化し、 頻度値?を変えると変化する事がある、 付属語グラフを変えると変化する事がある、 それ以外では変化しない。 候補一覧での並び順を決めるアルゴリズムで用いられている部分は、 第1候補が変わる様な変更をするとコーパス情報も変化するが、 それ以外では変化は少ない。

そして気付いた事。

幾つかの OS における Anthy のパッケージでは 辞書の構成(dict.args.in)を変更しているけれども (例えば Debian や Ubuntu だと 2ch辞書を追加していた様な気がする……、 環境設定を変更した場合のみ追加だっけ?)、 コーパス情報(corpus_info と weak_words)の 再計算を行っていないのではないか (先の Debian や Ubuntu で、再計算を行っているのか否かは未確認)。
もし再計算を行っていないとなると、 コーパス情報(corpus_info と weak_words)が 間違った状態になっている可能性があるわけで。

つまりは、 今まで使っていた anthy の、 コーパス処理の何割だかは出鱈目だったかもしれないわけで。
どうなのだろう。

↑ ……デジャブ。
もしかして vagus氏の日記で既出?

↑ ほぼ当たり。
alt-cannadic の「Anthyで使う」の項目に、 しっかり書いてあった。


FreeBSD 6.4:
標準状態では問題無し。 環境設定を変更すると 2chdic, odic, gskk が追加されるが、 update_params が実行されていない為、コーパスが出鱈目になる可能性がある。

NetBSD 5.0:
標準状態では問題無し。 環境設定を変更すると 2chdic, okinawa が追加されるが、 update_params が実行されていない為、コーパスが出鱈目になる可能性がある。

OpenBSD 4.4:
コーパス導入前の 8300 なので、関係無し。

Debian, Ubuntu:
標準の設定のままでも dict.args を書き変えているが update_params を実行していない。 ので、標準状態で既にコーパスが出鱈目になっている可能性がある、 もしかしたら。

Fedora, Red Hat:
標準の状態で辞書の元データと dict.args を書き変え、 update_params を実行している。 なので問題無し。


↑*? make update_params の件。
Anthy の ML の過去ログに全文検索をかけてみた (注:google で site:sourceforge.jp で検索しただけなので、 漏れがあるかも知れない)が、 「コーパスの例文を追加/削除/変更した場合」と、 「udict を追加/削除/変更した場合」は、 「make update_params が必須」とは書かれていたが、 辞書の構成を変更した場合に関しては言及が無かった。
anthy 同梱のドキュメント類には、その言及も無かった。

↑ make update_params。
てきとうに辞書の元データをいじって make update_params とか make update_params2 とかしてみたが、 corpus_info と weak_words が 変わったり変わらなかったりよく判らない。
使う元データを変えたのに corpus_info と weak_words が変わっていなかったり、 使う元データは同じで中身を数件変えただけで corpus_info と weak_words が変わっていたり。
ワケワカ。

make update_params の件は Wed,22 Jul,2009、 に続く。

Sat,18 Jul,2009

娘フロ ¥980- で3枚、 娘トラ(盤面にキズ)¥980- から2割引で1枚、 娘たま¥2,180?で3枚。 7月18〜20日は、5%割引+10%ポイントの日らしい。

Radio Fire ¥980-。

SSLの証明書。
拙作パッチ版petname が、 SSL証明書に微細な差異が有ると注意を出してきた。 OU が以前と違っているらしい。
旧:「IT Business Development Headquarters」
新:「Infomation Systems Planning Department」
確かに変わっている。 どうもつい最近発行されたタイムスタンプになっていたので、 期限切れで更新する際に、異動に合わせた部署名にしたのかな?。
あれ……、えっと……、Infomation?。

まぁ、この typo は私も山ほどやったけれど。

Sun,19 Jul,2009

交通事故が有ったらしい。 パトカー2台で道路を封鎖して、 それから化学消防車が2台くらい出ていた。

交通事故が有ったらしい。 コンビニ前を封鎖して、実況見分をしていた。

交通事故が有ったらしい。 パトカー、消防車?、救急車、合計3〜4台くらいが 緊急走行していった。

何か最近こんなん多いな。

白黒ツートンカラーの 85 だか 86 だかいう車を3回目撃。 ボンネットの吸気口の有無や、 ライトの違い(出たり引っ込んだりするタイプか、固定か)などから、 少なくとも3台以上は居る筈。 連休になるとこの近辺に出没している気がする。

Sケーブル ¥210-。

Power DoLLS 3 ¥980+税。

Logitec LMO-H630U2 ¥4,200-。 中の人は OLYMPUS MOS3393E11 らしい。

GALAXY Chart.1 ¥500-、今日だけ半額。 先月は GALAXY Chart.2 も有ったのに、今日は無かった。 今更買う人がいたのか……。 ネットでの流通価格は¥100〜200+送料だから、 転売すると赤字になる筈だし……。 それともオークションで構わず高値を付けて転売しているのだろうか。

ラピュタのイメージアルバム 3枚あって¥500-。

Diamonds、プリンセス・プリンセス、1989.4.21。

浅い眠り、中島みゆき、1992.7.29。 ミリオンセラーシングルらしいが知らなかった。ちょっと好みではないので。

MajiでKoiする5秒前、広末涼子、1997.4.15。 こんな感じの曲だったっけ?。

謎、小松未歩、1997.5.28。

NAVITIME。
カーナビ無しで道路ルートを自動探索すると言ったら、 これ一択だと思うけれど。
徒歩/自転車用に、 坂の少ないルート探索、とか、歩道が有るルート探索、とか、 が、あったらいいかなと思う事がたまにある。
自動車で走りやすい道が出やすい傾向が有る(たぶんわざとだろうけれど)が、 自動車で走りやすい道って、太くて真っ直ぐだけれども、 案外上り下りが多いのだよね。 ゆるやかな上りがずっと続くルートを徒歩や自転車で移動すると、 かなりウンザリする。 それから、 自動車の通りが多い道で歩道が無かったりするとかなり怖い。   あと、知らない場所だと、 地図を見ても坂の有無がわかりにくい、もしくはわからないので、 避けたくても避けられない。 川とか緑地とか道路の曲がり具合とか 道が有っても良さそうなのに無い場所とかを見れば、 多少の見当は付くけれども、ほぼヤマカンだし。 最近の幹線は、そういう事を一切無視して道路作っているから、 地図見ても坂がわからないし。
でも営業面を考えたら無理だろうな。 あーでも、最近は、 屋根の有る道探索、が、あるらしいから、あるいは……。

Mon,20 Jul,2009

コンビニにパトカーが止まっていた。

また、コンビニにパトカーが止まっていた。はて?。

市民公園の駐車場にパトカーが止まっていた。 さっきから何だろう?。

↑ ニュースによると、学校が夏休みに入ったとかで、 補導?の強化週間?日間?らしい。

Sケーブル 1.5m ¥105- で3本。
DVI-D SingleLink ケーブル ¥525- で3〜5本くらい。

Logitec LMO-F654U2(S) ¥1,575-。
富士通で 5455rpm らしい。
2003年製造終了らしいので、レーザーダイオードのヘタリが怖い。
メーカーの能書きでは、USB 2.0 で 480Mbps、と書いてあるけれども、 これは嘘大袈裟紛らわしい、で、実効データ転送速度は、 インタラプトモードでは定常的に約187Mibps(23MiB/s)(約197Mbps(25MB/s))、 バルクモードでは瞬間最大の 概算(512B/packet,10packet/micro-frame,8micro-frame/frame,1000frame/sec)で 約312Mibps(39MiB/s)(約328Mbps(41MB/s))。
USB 1.1 の実効データ転送速度は、 バルクモードでは瞬間最大の 概算(64B/packet,17packet/frame,1000frame/sec)で 約8Mibps(1MiB/s)(約9Mbps(1MB/s))。
ディスク転送速度が最大 5.87MB/s らしいので、 実データ転送速度は、USB 1.1 は USB 2.0 の 1/5 〜 1/6 の速度になる。 USB 2.0 だと、ドライブの最大速度まで出せる、たぶん。

MACROSS PLUS Original Sound Track ¥500- は無くなっていた。

DVI-D のシングルリンクとデュアルリンク。
1920x1200x60 まではシングルリンクでいけるらしい。 業務用とか絵描きとかで無ければ、シングルリンクで構わないのか……。

Sケーブル。
¥105-なら、試してみてもいいかな、と言う事で。
チューナー − TV 間を コンポジット(黄色いヤツ)からSに変えてみたのだが。
変わらなかった。見て判る様な違いは無し。
むしろ、スノーノイズが増えたり、 mpeg のブロックノイズが増えたり、 したかもしれん。 ……。 これは高周波の通りが良くなったと言う事なのか?。

BOY MEETS GIRL、trf、1994.6.22。 パラパラ版もあるらしい。 アニソンにもなったらしい。 ユーミン版もあるらしい。 小室哲哉らしい。
小室哲哉も全部が全部駄目な訳ではないだろうに。

Anthy 拙作パッチ版用 anthy.scm, anthy-utf8.scm 更新。 「patch12/patch13/patch13B パターン22:
Control modifier 付きキーをタイプした場合にも継続入力では無くなる、 および、 Control modifier 付きキーをタイプした以降は (BackSpace) キーを押しても忘れない、 様に変更。

Tue,21 Jul,2009

駅のコンコースの携帯屋にて。
1円ケータイが売っていた。 7月下旬は新機種発売に伴う旧機種処分らしい。
あと、ここは駅のコンコースかと思いきや、駅ビルらしい。

雨の為、ダイヤに乱れ。5〜10分遅れくらい。

Wed,22 Jul,2009

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

ただし、パラメータを調整し直して再更新するかも。

Tue,14 Jul,2009版にて学習を忘れる機能を追加した際に、 last-record1* が存在しない時に学習データを読み込まなくなる エンバグをやらかしていたので修正。

複合語を文節を区切って変換した時に、 スコア加算が行われなくなるエンバグを、 かなり前にやらかしていたので修正。
いつからだろう。相当前だと思う。
「|てつや|」で変換すると「|徹夜|」が第1候補になるけれど、 「|たけだ|てつや|」で変換すると「|武田|鉄矢|」が第1候補になり、 「|こむろ|てつや|」で変換すると「|小室|哲哉|」が第1候補になる、 と言う機能。
この機能自体は原作版 anthy から有った機能だけれども、 骨格部分のデータ仕様と、この機能の部分のデータ仕様がずれていて、 原作版 anthy では正しく動作しない状態だった、たぶん。 あるいは、さらに別の部分で仕様が一致していないバグが絡んで、 逆に機能している状態だったかも。
……。 この機能、左の文節の確定結果もしくは第1候補が不一致でも、 複合語に高得点付けてるし。 いじらないと駄目だ。

で。 今回のエンバグも、実の所、 原作版 anthy の仕様と、拙作パッチでの変更後の仕様とが、相反してしまい、 動作が破綻して発生したものだったりする。
破綻しない様な仕様変更にしろ、と言われそうだが、 それを言い出すと、そもそも(以下略)。 話し出すと長くなるので要約すると、 すでに仕様が確定してシステムとしての組み上げが終わった物に対して、 仕様を変更すると言うのは、すごく大変なんだよ。 まして、稼働状態を維持しながらの変更となると。

anthy において、 make update_params は、どの様な時に必要なのか。 Thu,16 Jul,2009の続き。
web で検索していたら、 Fedora/Red Hat GNU/Linux用の Anthy パッケージにて、 誤字修正が行われているのを発見。
https://bugzilla.redhat.com/show_bug.cgi?id=509534
これ、ちゃんと上流に還流されていない気がするのですが、 単に表に出ない所で行われているだけ?、 それとも表でフィードバックされているけれど私が気付いていないだけ?。

Thu,23 Jul,2009 追記:
で。 Fedora/Red Hat の場合、 上記の様に辞書の元データを書き換えると共に、 dict.args.in を書き換えていたが、 anthy.spec にて update_params0, update_params, update_params2, update_params2, update_params2 を行っていた。

Fri,24 Jul,2009 追記:
そんなこんな見ていたら、 原作版 anthy の Makefile.am にて、 make を呼び出す際に make と書いているバグ (正しくは $(MAKE)。 これは autoconf の doc の Portability だかの項目に書いてある)と、 GNU-make専用オプション -C を使っている問題 (このオプション、FreeBSD make にはインポートされていたが、 OpenBSD make には無かった) (適切な方法は「cd hoge && $(MAKE) foo」) を発見。
そうか、OpenBSD でいままでずっと、 作業ディレクトリの頭で make update_params するとエラーが出ていたのは、 こいつのせいか。

辞書の元データをいじってみたり、 構成を変えたり、 変換時のパラメータを変えたり、 してみると共に、make update_params してみたが、 どうやら、変換して最初に提示する、 文節区切り位置や変換の第1候補が変化する様な事をすると、 corpus_info や weak_words に変化が出るらしい。
変換して最初に提示する内容が変化しない様な変更だと、 辞書の元データを変えようが辞書の構成を変えようが、 corpus_info や weak_words は変化しなかった。
変換して最初に提示する内容が変化する様な変更だと、 たとえ変換のパラメータ(${HOME}/.anthy/conf に書く内容)を1つ 変えただけでも、 corpus_info や weak_words が変化した。

……。 業務用サーバ(ありきたりのリース機だけど)を借用して実行してさえ、 make update_params や update_params2 を1回実行する毎に 6〜7分消費するのですが。 vagus氏はリリース毎にこれを約4回も実行していたのか……。

Thu,23 Jul,2009

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 と言う訳で更新。

複合語のスコア加算を行う際に、 左側が一致するか否かの判定を追加。
複合語のスコア加算の値を、 CAND_HISTORY学習以上、OCHAIRE学習未満、になるように、大きくした。

途中駅で非常停止ボタンが押されたとかで、 10〜15分の遅れ。
そして、例に依って例の如く、乗換駅にて、 乗り換え先の電車が接続待ちを5分しかおこなわず、 接続待ちしていた相手の電車が到着する前に発車。 しかもこれが終電。
前回遅れた時は接続待ちを3分しかおこなわずに、 接続待ちしていた相手の電車が到着する前に発車(しかも終電)したので、 今回は2分長くなったものの、やっぱり待たずに発車って……。

Sat,25 Jul,2009

大澤誉志幸、「そして僕は途方に暮れる」、1984.09.21。
そして僕は途方に暮れる、高杉さと美、2007.12.12、と言うのも有るらしい。 こちらは……、えっと……、何でこんな事したのでしょう。

中村あゆみ、「翼の折れたエンジェル」、1985.04.21。
2008.10 に別バージョンが出たらしい。 どこが違うのか判らなかった……、ちょっとガラ声になった?。

両方共、日清 カップヌードル のCMソングだったらしい。

anthy 拙作パッチ。

どうにも、 複合語や OCHAIRE とは違う連文節を選択した時の、 連文節のスコアが気に入らない。
原作版では、そもそも入力された読み仮名が、 複合語か OCHAIRE の読み仮名に一致さえすれば、 文節区切りの位置を問わず、スコア加算を行っていたっぽい (「|竹|だ|鉄矢|」とか「|わ|たり|哲也|」とか)。
で、 実際に使っているとこれで出してくる候補が痛い事があるので、 注目文節の左側の文節区切りが一致した場合のみ、 スコア加算を行う様に改造した、が。
文節区切りが一致しても、選択した候補が別の時だった場合、 やっぱりそんな候補を出されると何か痛い (「|竹だ|鉄矢|」とか「|渡り|哲也|」とか)。
でも、変換途中に、仮選択された候補を知る機能は無い。
anthy_get_segment() された時に、 nth_seg に対する nth_cand を仮決定として保存する機能を追加して、 組み合わせに変更があったら、変更があった地点から右側に対して anthy_sort_candidate() しなおす機能を追加するか?。

と、言う訳でそうした。
結果が良い方に転ぶのか悪い方に転ぶのかは不明。
かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

omniORB。
i386系でコンパイルしてもウォーニングは出ないのに、 amd64系でコンパイルするとウォーニングが出る。
BSD系のamd64系では、 int64_t は long long int 型で PRId64 は lld になっているのに、 omniORB では 64bit長変数を long int 型にしていて、 それで食い違ってウォーニングが出ているらしい。
i386系だと、 OS側も omniORB側も、両方共 long long int なので、 ウォーニングが出ないらしい。
32bit長変数では逆に、 i386系ではウォーニングが出て、amd64系では出ない。 i386系では、int32_t は int、PRId32 は d、omniORB では long。 amd64系では、int32_t は int、PRId32 は d、omniORB では int。 こちらはもう相当前に気付いていて、PRICORBAd32 を作ってあった。
omniORB で、int??_t を使うようにすればよいのだろうけれど。
悠長にそんな事をしてはいられないので、 PRICORBAd64 の定義内容を変更して逃げた。

Sun,26 Jul,2009

0083 サントラ1 ¥180-。 amazon みたら¥150- とか付いていた。 サントラ2もあるらしい。

愚連隊シリーズは無くなっていた。 戦士たちの邂逅は、まだあった。

ハードオフのジャンクケーブルコーナーにて。
テスタでチェックしながらカゴに入れている人がいた。 しかもアナログテスタの音無しタイプ。 プローブがノーマルでは無く、 細部チェック用?の先が針金みたいになっているタイプ。

GALAXY Chart.2 ¥200-。
王立宇宙軍サントラ(1枚組の方) ¥1,950-。
もののけ姫 サントラ ¥200-。
もののけ姫 イメージアルバム ¥200-。

¥200- につられてホイホイ買って帰った訳だが……。 新品買って多少なりとも原作者に還元しろと言う話が……、 1996年製らしいので、もう13年前になるのか……。
イメージアルバムの方は、 amazon みたら中古¥54- とかなっているし、 ブックレット?は水濡れのシミがあるし、 保護層面側にカビ生えているし、 円周方向にキズがあって音飛びするし(泣。
とりあえず、 データ用CDドライブでスピンアップをたっぷりしてから読み出したら、 音飛びせず、C2エラーも出ずに、読み出せた。 スピンアップせずに読み出すと C2エラーが万の単位で出るのに、 スピンアップタイムが数十秒だと C2エラーが数百だったり、 数分くらいスピンアップしてから読み出すと 0 になったり、 わけがわからん。 waveファイルの波形エディタで見ても、 エラー訂正らしき跡は見つからなかった。 まぁ、エラー訂正の跡を見た事が無いから判らないけれど。

中島 みゆき 「空と君のあいだに」 1994.5.14。

Mon,27 Jul,2009

電車内の広告にあった地球の絵。
某塾の試験問題が書かれているヤツ。 http://www.nichinoken.co.jp/column/shikakumaru/2009/0908_ri.html
円の中に、 メルカトル図法かミラー図法か何かそっち系の世界地図の 一部を丸く切り取って貼っ付けてある図だった。
それは違うだろ。

以前、某国の某ミサイル騒動の時も、 メルカトル図法かミラー図法か何かそっち系の世界地図の上に、 円を描いて「射程距離」とか書いてある 新聞記事やテレビのニュースを、 沢山見たけどさ……。

Wed,29 Jul,2009

CVE-2009-0696
なんか久しぶりにとてつもない物が来た様な気が。

Thu,30 Jul,2009

戦闘妖精・雪風
第3巻「アンブロークンアロー」(ハヤカワ)が7月24日に出たらしい。

ところで、 エンダーのゲームの裏編の最新刊の邦訳版はまだですか > ハヤカワ。

Fri,31 Jul,2009

ようやくバグがとれた。
C/C++言語で書いたシステムが、 「自己診断の結果、内部状態遷移に矛盾を発見した」 と言うエラーを出してきた。
で、デバッグを始めたら、自己診断部分にもバグを見つけてしまって、 自己診断のバグでエラーが出たのか、本当に矛盾が発生したのか、 区別が付かなくなってしまった。
当然、まず自己診断のバグ修正。
ようやくバグがとれた所で、再診断。
やっぱりエラーが出る。 データベースをダンプして人力で診断してみても、確かに矛盾している。
そして再度、今度こそ系本体部分のデバッグ。
記憶を持つ系を、 当初はムーア型で設計製作していたのに、 後になって仕様変更および仕様追加した部分を 再実装・追加実装する際に、ミーリー型で書いてしまい、 矛盾が起きてバグになっていた。

そう言えば、 ソフトウェアを書く際にミーリー・ムーアを意識する事は無いなぁ。
ハードウェアの図面を書く際もミーリー・ムーアは意識しないけれど、 こちらは明確に意識していないだけで、 状態遷移図やブロック図を書く際に、 当然、意識せずとも考慮に入っているし。

Sat,01 Aug,2009

Kingston microSD 2GB ¥780-改め¥680-、4GB ¥980-。 Kingmax SD 2GB ¥680-。
HDMIケーブル(ELECOM 金メッキ) ¥2,380-。
各種型落ち携帯電話機 ¥2,000〜0-。

攻殻機動隊1.5 (紙の方の通常版)¥350-。

BSD magazine the DVD 2004(No.1〜No.18 の総集編)(古本)¥150-。
今見てみたら、遂に ASCII の webサイトからも消滅していた。 こうして歴史が埋もれてゆく……。

BSD magazine 2004 No.20(最終巻)(古本)¥105-。

Let's Fire ¥500-。

ssh の新しいサーバ鍵を登録していて、ふと。
RSA と DSA って何が違うんだっけ?。 この話、何か定期的に繰り返しているけれど……。
RSA は権利関連で色々あって、代替として DSA が作られたらしい。 ただ、DSA は鍵長が 1024bit 固定らしい。 RSA なら、768以上で可変、デフォルトは 1024〜2048bit くらいらしい。 現在は、RSA の権利関連は解決して、フリーに使えるらしい。
例に依って例の如く、本記事が正しい事を保証するものではありません。

↑ 鍵長の話。
http://www.rsa.com/rsalabs/node.asp?id=2004
http://www.oiwa.jp/~yutaka/tdiary/20080623.html#p01
1024bit なら 2010年廃止目処、 2048bit なら 2030年廃止目処、 それ以降は 3072bit以上を推奨、 らしい。
ええい、面倒だ、4096bit にしてしまえ。 そうすれば、 鍵長による危殆化より、 アルゴリズムの危殆化の方が先に来るだろ。
と思ったが、 GnuPG の主鍵DSA2 の上限が 3072bit だと言う事を思い出した。
……。TTSSH2 に至っては鍵長固定だし。 PuTTY なら鍵長を 3072以上にも出来るらしい。
例に依って例の如く、本記事が正しい事を保証するものではありません。

Sun,02 Aug,2009

GreenHouse USB - microSD/microSDHC アダプタ ¥480-。
BUFFALO USB - microSD/microSDHC アダプタ(限界まで小さいタイプ) ¥680-。

某安かろう悪かろうで有名なブランド microSD 2GB ¥600-。 ¥80-差なら Kingston の方が……。

GreenHouse USB - SD/SDHC アダプタ¥500-。

バッファローコクヨサプライ BSMOU02YM(WH) USB 光学式 5ボタン マウス DPI切り替え付き(有線)¥980-。 ホイールがスクロール&左右チルトするタイプ。

中型?の扇風機 ¥1,780-。

BUFFALO USB - microSD/microSDHC アダプタ(限界まで小さいタイプ) ¥780-。

MAXELL DVD-RAM 10枚¥1,980- ポイント15%。
Panasonic DVD-RAM 10枚¥1,780- ポイント15%。
パソコン用記録メディアのコーナーは、 ほぼ BD-R?,DVD-R,DVD-RW,CD-R のみで、DVD-RAM は殆ど無くなっていた。
ポイント15%は、 現金/店舗直系のクレジットカード/J-Debit 限定らしいのだが。 他社クレジットカードがポイント優遇除外なのは判るが、 Suica/Edy はポイント優遇に含まれないのだろうか?。 J-Debit はポイント優遇で電子マネーはポイント優遇無し?。

プロフェッサーキューブ と ミラーブロックス の 取り扱いが無くなっていた。

攻殻機動隊 バイリンガル版 ¥250-。

バッファローコクヨサプライ BSMOU02YM。
外れだった。 HUC_AC_PAN イベント?対応のマウスドライバが必須。 製品には MS-Windows WIN32用ドライバしか付属していない。 拙作FreeBSD版ドライバは後述。 ドライバがあれば、そこそこ良い。 ドライバが無ければ、ハズレ。
ホイール左右チルトが、MS-Windows専用ドライバを常駐させないと入力できず、 FreeBSD だと認識しなかった。 この時点で、私の基準では失格確定。
中の人は Logitech(Creative Labs) らしい。 idVendor 0x062a, idProduct 0x0252。 あと、マウスなのに Full Speed デバイスらしい。 反応速度が速いかもしれない、変わらないかもしれない。
ケーブル&USBコネクタが、マウス本体に格納できるのは、 ノートPCをよく持ち運ぶけれどもマウスも一緒に持ち運びたい、 と言う人には良いかも。 ただ、格納庫が磁石留めなので、問題有るかも (一緒に持ち運んだキャッシュカード/クレジットカードが壊れたりする。 最近は FD が壊れる問題は心配しなくていいのか……)。
光学系が中心からずれた所に付いている。 仕様状態において左手前側にずれている。 なので、マウスをかしいで持つ人の場合、 操作方向と移動方向がずれるかも。
ホイールの作りが甘く、 回すと場所によって固くなったり軟らかくなったりするし、 ホイールクリックが効かなくなったりする。 ただ、クリックの遊びが適度に大きめなので、 チルトした時に誤ってクリックしてしまう事は少なそう。
DPI切り替えは3段階(1600/1200/800 DPI)。 普通のDPI切り替えな感じ。 現在のDPI設定が、LEDの明るさで判るのは良いかも……と思ったが、 大差無かった……、 色の違いならすぐに判別できるのだが、明るさの違いは全然区別が付かない (切り替えた直後は明るさが変わったのが判るのだが、 後で見た時にどの段階の明るさなのか判らなくなる)。 3段トグルスイッチの方が、直感的に判りやすくて好き、 でもそんな製品は存在しない(部品代が高いから)。

↑ チルトが効かない件、lsusb 使ってダンプしてみたら判明。
チルト操作が Comsumer: AC Pan になっていた。 Comsumer: AC Pan に対応したマウスドライバが無い、と言う話らしい。 で、この Comsumer: AC Pan って何?。
NetBSD にて、系列機で、同じ罠にハマった人がいて、 対応パッチを作っていたらしい。 http://mail-index.netbsd.org/current-users/2009/07/15/msg010043.html HUP_CONSUMER, HUC_AC_PAN に対応すればいいらしい。 ちょうど2週間前って……。
どうも、kernel にコミットされているっぽい記事が。 でも、NetBSD の CURRENT でコミットだから、 FreeBSD の RELEASE まで来るには、かなり時間かかりそうだ。 また自分で kernel source いじるしかないか……。

チルトホイールマウス(チルトがボタン操作タイプ):
Bus /dev/usb2 Device /dev/ugen1: ID 15d9:0a41  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x15d9 
  idProduct          0x0a41 
  bcdDevice            1.00
  iManufacturer           0 
  iProduct                1 USB Mouse
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      64
          Report Descriptor: (length is 64)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x02 ] 2
                            Mouse
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Pointer
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Usage Page, data= [ 0x09 ] 9
                            Buttons
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            Button 1 (Primary)
            Item(Local ): Usage Maximum, data= [ 0x05 ] 5
                            Button 5
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x05 ] 5
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x03 ] 3
            Item(Main  ): Input, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Global): Logical Minimum, data= [ 0x00 0xf8 ] 63488
            Item(Global): Logical Maximum, data= [ 0xff 0x07 ] 2047
            Item(Global): Report Size, data= [ 0x0c ] 12
            Item(Global): Report Count, data= [ 0x02 ] 2
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Local ): Usage, data= [ 0x38 ] 56
                            Wheel
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0005  1x 5 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)


このマウス(チルトが AC_PAN):
Bus /dev/usb2 Device /dev/ugen0: ID 062a:0252 Creative Labs 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x062a Creative Labs
  idProduct          0x0252 
  bcdDevice            0.00
  iManufacturer           1 Logitech 
  iProduct                2 USB WheelMouse     
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      61
          Report Descriptor: (length is 61)
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x02 ] 2
                            Mouse
            Item(Main  ): Collection, data= [ 0x01 ] 1
                            Application
            Item(Local ): Usage, data= [ 0x01 ] 1
                            Pointer
            Item(Main  ): Collection, data= [ 0x00 ] 0
                            Physical
            Item(Global): Usage Page, data= [ 0x09 ] 9
                            Buttons
            Item(Local ): Usage Minimum, data= [ 0x01 ] 1
                            Button 1 (Primary)
            Item(Local ): Usage Maximum, data= [ 0x03 ] 3
                            Button 3 (Tertiary)
            Item(Global): Logical Minimum, data= [ 0x00 ] 0
            Item(Global): Logical Maximum, data= [ 0x01 ] 1
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Global): Report Size, data= [ 0x01 ] 1
            Item(Main  ): Input, data= [ 0x02 ] 2
                            Data Variable Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Global): Report Size, data= [ 0x05 ] 5
            Item(Main  ): Input, data= [ 0x01 ] 1
                            Constant Array Absolute No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Local ): Usage, data= [ 0x38 ] 56
                            Wheel
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Report Count, data= [ 0x03 ] 3
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Global): Usage Page, data= [ 0x0c ] 12
                            Consumer
            Item(Global): Report Count, data= [ 0x01 ] 1
            Item(Local ): Usage, data= [ 0x38 0x02 ] 568
                            AC Pan
            Item(Main  ): Input, data= [ 0x06 ] 6
                            Data Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield
            Item(Main  ): End Collection, data=none
            Item(Main  ): End Collection, data=none
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0005  1x 5 bytes
        bInterval               2
Device Status:     0x0000
  (Bus Powered)

↑ と言う訳で、FreeBSD のカーネルをハック。
Logitech(Creative Labs) もしくは OEM(BUFFLAO とかバッファローコクヨサプライとか)のマウスにて、AC_PAN(HUC_AC_PAN) なチルトホイールを FreeBSD 6.4 で使える様にするパッチ カーネルパッチなので、カーネル再構築が必要。
元記事の NetBSD のパッチは、改造の方針の理解には大いに訳に立ったが、 処理の違いが結構大きかったので、コード自体は利用できなかった。
で、今、実地試験中。
チルトボタンを「離した」イベントが来ないとか、 チルトボタンは押しっ放しにするとリピートするし、 リピートは「押した」イベントが連続で来るだけだったり、 結構面倒だった。 ドライバ側で「離した」イベントを捏造してやらないと、 tty の moused や、X のマウスドライバが、 2回目以降の「押した」イベントを認識してくれなくて。

マウスドライバのパッチの話は Wed,16 Dec,2009に続く。

現実逃避でバカネタ。 王立宇宙軍のニキシー管。 Mon,09 Jan,2006の続き。
以前から、 チマチマとオネアミス数字のコマ送り解読をしていたが、 ようやくまとまった。
たぶん、こんな感じ → Honneamise's Numeric Character on Nixie 3と5が、非常にまぎらわしい。
ニキシー管のシーンでは3本のニキシー管が表示されているが、 最上位桁は6コマに1回変化(1づつ下がる)、 中位桁は2コマに1回変化(1づつ下がる)、 最下位桁は毎コマ変化(2〜4づつ下がる)、 しているので、桁の繰り下げが合わない。 何か違うカウントダウンを3つ表示しているのだろうか?。

打ち上げカウントダウンのニキシー管のシーン。
807, 806, 894, 892, 881, *87,
776, 774, 762, 761, 757, *56,
644, 642, 631, 637, 626, *24,
522, 511, 507, 506, 594, *92,
481, 487, 476, 474, 462, *61,
357, 356, 344, 342, 331, *37,
226, 224, 212, 211, 207, *06,
194, 192, 181, 187, 176, *74,
062, 061, 057, 056, 044, *42,
931, 937, 926, 924, 912, *11,
打ち上げカウント1→0のニキシー管のシーン。
017, 016, 004, 002, 001, 007,
006, 004, 002, 001, 007, 006,

……カウント0を過ぎていませんか。
……最下位桁は、76421を繰り返しているだけだ……。

Tue,04 Aug,2009

ssh がつながらない。
Permission denied (publickey).
とか出て、拒絶される。
結論だけ言うと、 サーバ側の ~/.ssh/authorized_keys に、 今使っている公開鍵が登録されていなかっただけだった。
もうちょっとわかりやすいエラーメッセージにして欲しい……。

ターミナルのキー操作がおかしい。
shell.sourceforge.jp にて ^h や BackSpace をタイプしても、 Delete として機能してしまう。
結論だけ言うと、 Debian GNU/Linux の場合、 kterm を使っている時に TERM を xterm-color にしてしまうと、 そうなるらしい。 TERM を kterm-color にすると、想定通りに機能した。
ちなみに、Vine GNU/Linux 3系の場合、 TERM を kterm-color にすると、 「そんなターミナルは知らん」と言ってエラーになる。 TERM を xterm-color にすれば、想定通りに機能する。 これがあったので、GNU/Linux はそうなのか、と思って、 Debian でも xterm-color に設定していた。

anthy 拙作パッチのバグを踏んだ。

候補の並び順が、設計通りになっていないケースに遭遇。
しかも再現性無し。
困ったね。

それから。 ENABLE_PROVISIONAL_COMMITTED 機能追加に伴い ANTHY_RECONVERT_DISABLE をデフォルトにした筈だったが、 その様に変更したファイルを一時作業領域から公開用作業領域に コピーするのを忘れていたのを修正。
それから。 ENABLE_PROVISIONAL_COMMITTED 機能にて再評価を開始する文節が、 正しくは「注目文節の右の文節以降(注目文節は含まない)」の所を、 間違って「注目文節以降(注目文節を含む)」になっていたので修正。
それから。 ENABLE_PROVISIONAL_COMMITTED 機能追加に伴い、 将来の機能拡張用に追加しておいたパラメータ(OCHAIRE の文節の連接情報)を 利用する様になったが、 生成したこのパラメータを、 間違ってローカル変数に格納してしまっていて (正しくは splitter_context* sc側の mw に設定すべき) 情報生成した直後の return で破棄される、 と言うオバカをやっていたので修正。
それから。 candsort.c の check_dupl_candidate() にて候補を統合する際に、 学習と一致しなかった為に廃棄した「学習由来なので優先するフラグ」を、 復活させてしまっているバグがあったので修正。

……ああ、 候補の並び順が設計通りになっていないのは、 これのせいだわ。
と言う訳で、 「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

Wed,05 Aug,2009

anthy 拙作パッチ。

昨日の修正で、 OCHAIRE の適用判定を厳密にした影響で、 自立語無し OCHAIRE学習が適用できなくなっていた (自立語無し OCHAIRE学習に対応し忘れたバグ、とも言うかもしれない)。
ので、再再度、OCHAIRE の判定を調整、 自立語無し OCHAIRE学習が適用される様にした。
もっとも、標準設定では、 自立語無し OCHAIRE学習は「学習しない」設定になっているので、 適用しようがしまいが変化は無いと思うけれど。
かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 更新。

↑ 自立語無し OCHAIRE学習は、学習の誤適用が割合目につく。
なので、覚えないのと覚えすぎるのと、 どちらが良いのかと言うジレンマが。

Thu,06 Aug,2009

広島の日。

Fri,07 Aug,2009

Unix系でファイルの改行コードの変換。
一番有名であろうツールを使う方法だと、 nkf で -Lw とか -Lm とか -Lu とかする方法がある。 が、これだと、 日本語の文字コードが勝手に ISO-2022-JP(nkf 2.0.7頃までの場合) もしくは locale で設定された文字コード?(nkf 2.0.9頃以降の場合?) に変換されてしまう問題がある。 nkf のオプションで出力文字コードを明示すれば 出力文字コードを固定できるが、 改行コードだけ変えて文字コードは変えたくない、 とか言う場合に対応できない。
次に有名かもしれない方法としては、 tr とか perl とかで \r や \n を置換する方法がある。 が、これだと、 入力元の改行コードが何なのか知らないと変換できない問題がある。

で、別の方法。
vim -c "set ff=dos" -c "x" filename
ff= の dos の所は、unix,dos,mac から出力したい改行コードを選ぶ。
これだと、 文字コードは変更せずに済み、 入力元の改行コードが判らない場合でも対応できる。
他の方法に無い欠点として、 ファイルの末尾に、勝手に改行が付いてしまう。
それから、vim の文字コードの自動判定処理が失敗すると、 出力を壊される問題がある。
あと、vim なので、処理が凄く遅い。

とほほのperl入門(概要編) 改行コード の方法を使えば、 入力の改行コードの種類問わず、文字コードを変更せずに、 改行コードのみを変換できるらしい。
ただ、これだと、Unix系(LF) 上において、 Mac形式(CR) な改行コードを読み込めなかった (単独の CR を改行とみなさなかった)。

Sat,08 Aug,2009

ワンダースワン(黄色い筐体) 本体のみ、ジャンク扱い¥950-。
プレステのコントローラ ジャンク扱い¥350-。

初期シリーズの方のロードス島戦記のサントラ2と3、各¥250-。
……、あれ、 菅野よう子 & 坂本真綾 って、新シリーズの OP の「奇跡の海」だけなのか。

Anthyのどうでもいい話。 複合語辞書に、 菅野よう子は載っていたけれども坂本真綾は載っていなかった。 意外。

Sun,09 Aug,2009

ワンダースワン(クリア)箱付き、ジャンク¥315-。
プレステのコントローラ ジャンク¥315-。

patch。
MS-Windows上で作られた diff ファイルを、 GNU/Linux上でパッチ当てしようとすると、 丸ごと全部、rej された。
原因は。
パッチ対象のファイルの改行コードが CR+LF なのだが、 MS-Windows上で diff を作ると、 パッチ本文中が CR+LF な改行になるだけでなく、 diffの識別行?(^diff な行)の改行コードも CR+LF になるらしい。
で、Unix系上で動いている GNU-patch は、 diffの識別行?(^diff な行)の改行コードが CR+LF だと、 diffファイル全体の改行コードを CR+LF から LF に変換してから、 パッチ当てを実行するらしい。
その為、 パッチ対象のファイルの改行コードも LF とみなして処理しようとしてしまい、 でも実際のパッチ対象のファイルの改行コードが CR+LF なので、 マッチせずに、処理失敗してしまうらしい。

GNU-patch の man をざっと読み直してみたが、 この自動判別を無効にする方法が見つからなかった。
仕方が無いので、 パッチファイルの方の diffの識別行?(^diff な行)の改行コードだけを 変換するスクリプトを書いてしのいだ。
各種スクリプトの crlfdiff2lfdiff.pl。

Mon,10 Aug,2009

Hub が死んだ。Corega の Giga-Hub。
しかも場所が基幹から枝への分配、なので、ネットワークが壊滅。
ケーブルをつなぐとモニタ LED はちゃんと点灯するし、 データが流れるとモニタ LED はちゃんと点滅する。
でもデータが通り抜けない。
24h 365d 運用で5回目の夏だった。

今日の WBS。
ほんの数秒だけ、BGM に「Fly up in the air」が使われていた。
あれ、CDDB だと「Fly up to the air」になっている。

svn のファイルの属性。
バイナリで mime-type が違っているとか、 スクリプトの eol-style が違っているとか、 いう事に気付いた。
[auto-props] はちゃんと設定してあるのに。
……。
enable-auto-props が yes になっていなかった。 orz

Tue,11 Aug,2009

また Hub が死んだ。 マイクロリサーチ社のルータに内蔵されている Giga-Hub。
こんどは基幹の根っこ、なので、今日もまたネットワークが壊滅。
ケーブルをつなぐとモニタ LED はちゃんと点灯するし、 データが流れるとモニタ LED はちゃんと点滅する。
でもデータが通り抜けない。
こちらは 24h 365d 運用で4回目の夏。

各種スクリプトの crlfdiff2lfdiff.pl を修正。
手抜きして、 行頭の diff, ---, +++, @@ だけを見て判定していたら、 変更前のファイル中の削除された内容に「-- 」で始まる行とか、 変更後のファイル中の追加された内容に「++ 」で始まる行とか、 が有って、 みごとに「--- 」や「+++ 」で始まる状態になっていて、 誤判定してしまった。
ちゃんと diff, ---, +++, @@ の4行セットで判定する様にした。
そう言えば、unified diff だけ対応で、 context diff や、もう1つの形式(名前忘れた)に、 対応していないや。

Wed,12 Aug,2009

かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 バグ修正。

nosuke(のすけ)氏 - 日記みたいな何か - 2009年 8月11日 (火) - ぐうすうばんめ
> 9100h.patch13Bptn23.iconv.2009805.alt-depgraph-090712
> 「ぐうすうばんめ」を変換すると,最初「偶数 + 坂め」になるんですが,
> これを変換し直して「偶数 + 番目」で確定した後,
> 再度「ぐうすうばんめ」を変換するとAnthyがアプリ巻き込んで死にます.
> その後は「ばんめ」だけで変換しても死に,
> さらには「ぐうすうばんめ」を一続きで打って変換することなく確定しても死ぬという超展開.
の件。

結論だけ言うと:
単体で自立語になる事が許可されていない単語に対して学習を再生した際に、 変換候補一覧の線形リストを無限ループさせてしまう事がある、 バグがあった。

→ 分析
・「ぐうすうばんめ」では再現できなかった。
→ 「ぐうすうばんめ」は compound.t に載っている単語なので、一発で「|偶数番目|」と1単語になる筈。
→→ 以前に「|偶数|番|」(|ぐうすう|ばん|)の学習が行われ、その自動拡張で「ぐうすうばんめ」を2文節に区切った?。
→→→ 本質ではないから、どうでもいいや。
・「|数|番目|」(|すう|ばんめ|)では無限ループが起きた。
→ 落ちはしなかった。謎。
・その後、「ばんめ」だけでは再現できなかった。
→ これは、「ぐうすう」にて「偶数」と変換確定し、続けて「ばんめ」と変換した可能性が有ると思われる。
→→ ENABLE_KEEPALIVE機能により、続けて変換した場合に連結する機能が働き、「ぐうすうばんめ」の変換と同じ状態になったと思われる。
→→→ 本質ではないから、どうでもいいや。
・> 「ぐうすうばんめ」を一続きで打って変換することなく確定しても死ぬという超展開.
→ フロントエンドのソフトによっては、無変換で確定をした場合でも、内部で自動的に変換を行って、無変換と同じ内容になる候補を自動的に選択し、変換確定する場合があります。

→ 原因
(1)
「|番目|」(ばんめ)が、 単体で自立語になる事が許可されていない単語なので、 単体の変換候補としては生成されない。
(2)
学習適用時に学習を適用できる変換候補「|番目|」(ばんめ)が 見つからない為、強制的に自立語として生成、 付属語無しの候補として「|番目|」(ばんめ)、 付属語有りの候補として「|番目|」(ばんめ)、 と、2つ、候補を登録しようとする。
(3)
登録する際に手抜きとメモリをけちる為に、 「変換候補として登録する内容」のメモリ (metaword_bylearn.c の各関数から anthy_commit_meta_word() を呼び出す時の struct meta_word* mw の方の引数)を使いまわす。
(4)
anthy_commit_meta_word() の設計が、 引数に使いまわした物を渡されると 「変換候補の線形リスト」が壊れる設計になっていた。
# 原作版からずっとそういう設計。「引数として渡す内容は使い回さない」と言う前提だったのでしょう、たぶん。

→ 対処
anthy_commit_meta_word() を設計変更。 引数に使いまわした物を渡されると拒否する様にした。

→ ごめんなさい
すみません。このバグ、以前自分で踏んで、 metaword_bylearn.c の呼出側で使いまわして呼ばない様に 修正していたのですが(たぶん半年とかそれ以上前)、 2009804版→2009805版の時のバグ修正/処理調整の際に、 このバグを復活させてしまっていました。

↑ みたいに、バグが出て、 新しい版ではバグが有るけれども古い版なら大丈夫、な時に、 私以外の人でもリポジトリを見て修正できた方が良いのかな、 と思ったので、 sourceforge.jp にリポジトリでも突っ込んでみようかと、 何ヶ月か前から思い始めた所。
vagus氏の、 古い版は消されてしまうので、 発言が割と影響が有って、 先月頃ののすけ氏の、 20090308あたりが一番こなれていてよかったような、 発言が割ととどめ。
……。
1年くらい前から、リビジョン管理した方が良いのかなぁ、と思い始め、 その頃から作業領域のバックアップだけは採っておいたのだが。 サーバのバックアップを探して見たら、 パッチのバックアップが 220個と、 alt-depgraph版の作業領域のバックアップが 60個、 あった。
生ディレクトリから SVN への変換を、 人力で1日10個おこなったとして、1ヶ月かかりますよ……うへぇ。 1日20個でも2週間かかるし……。

途中でファイル名変更やディレクトリ移動をやらかしたから、 commit の自動化ができないのだよなぁ……。 私が RCS や CVS を使わない理由の大半は、 ファイル名変更やディレクトリ移動をちょくちょくやらかすから、 なのだけれども。 SVN はファイル名変更やディレクトリ移動にも対応になったそうだし。 あとは、頻繁に typo をやらかす問題が。 commit log ですら typo やらかして 再commit してさらに間違えて 再再commit、 それでも間違えて面倒になってリポジトリ生編集、とか やらかした事があるくらいだし……。
……。 ファイルの分割は svn cp で記録するとして、 ファイルの併合はどうやって記録するのだろう。 もしかして、対応していない?。

あと、CVS, SVN などのリビジョン管理ソフトは、 タイムスタンプを保存しない仕様になっている問題も無くも無い。
CVS や SVN の場合、 コンパイルした後に別のリビジョンを checkout した際に、 確実に再コンパイルが行われる様にする為、 故意にタイムスタンプを checkout した時刻に 設定しているらしいのだが。
日本のソフトウェア業界だと、相当古くから 「ファイルのタイムスタンプ = ファイルのリビジョン」 と言う管理方法が行われていた慣習が有る為、 CVS, SVN などのリビジョン管理ソフトはタイムスタンプを保存しない、 と言う仕様が受け入れられないらしい。
一部の OS だと、ファイルをコピーしただけで タイムスタンプは変わるんですけれど。
まぁ私も、 「ファイルのタイムスタンプ = ファイルのリビジョン」 の考え方にとらわれているけれど。 lha u とか zip -f とかやると、 タイムスタンプ基準で処理が行われるから、 タイムスタンプは保存しておきたくなるし。 あと、ls しただけでリビジョンが判るのって、やっぱり便利。 svn ls すればいいのだろうけれど。
↑ SVN の場合、export すれば、 ファイルのタイムスタンプに commit時刻を用いるらしい。 branches とか tags とか作った時に、 全ファイルが同一タイムスタンプになってしまうけれど。
↑ ファイルの最終編集時刻と commit時刻のずれさえも受け入れられない場合、 commit時刻を変更してしまう荒技はあるものの。 取り敢えず、 svnroot/projectname/hooks/pre-revprop-change.tmpl を参考に svnroot/projectname/hooks/pre-revprop-change を作って、 svn:date を M する時も exit 0 してやれば、
svn propset --revprop -r 1234 svn:date "1975-01-01T00:00:00.000000Z" file:///svnroot/projectname
とかやって編集できた。
↑ これ使えば、mime-type を間違えたのも修正できるかも。 と思ったが、駄目らしい。 mime-type は revprop(リビジョンの管理側)ではなく revs(ファイルの管理側)に入っているらしい。
↑ mime-type はテキストファイルにも付けられるらしい。 svn:mime-type=text/plain; charset=EUC-JP (config の auto-props で書く時は ; を ;; に変えるらしい) とかやると、文字コード指定付きのテキストファイルにできるらしい。 web連動で svn閲覧とかやっている時に、 文字コードの判定を間違えなくなるので嬉しいらしい。

vim を使っていると、 文字削除に、BackSpace 使わずに ESC して x する方が多いから、 誤学習削除が効かない事に今更気付いた。 対処法は……、……、……、無いな。

anthy alt-depgraph-090712。
「誤判定」(ごはんてい)に助動詞?(する、した)が付かない。
alt-cannadic/gcanna.ctd と mkworddic/compound.t の両方で #T35 になっていた。
たぶん #T30 。
Sun,20 Sep,2009 追記:
vagus氏 - 丘の道を登り - 2009年09月15日
対応、有り難うございます。

Thu,13 Aug,2009

そして今日もネットワークが死んだ。
あちこちの Hub で通信過多な状態になった上、 無線LAN の基地局が発狂して 有線ポート再起動の syslog を大量に垂れ流しているし。 垂れ流された大量の syslog で ログサーバの数GB が埋まって Disk full まで出ちゃうし。
無線LAN の基地局を予備機と交換しても全く変わらないので、 あちこち見て回った所。
原因発見。
ネットワークがリピーター Hub 経由で循環していた。
10BASE-5 じゃないのだからさぁ……。
もしかして、先日 Hub が発狂していたのはこれのせい?。

ネットワーク殺すにゃ刃物は要らぬ、ループの1つもあればよい。
まぁ、最近の Hub やルータは、 ループの自動検出と自動排除機能を内蔵しているけれど。
それに、 カテ5の両端にRJ-45 付けるより、刃物でケーブル切る方が楽だけど。
それよりも痛いのは、雷とかスタンガンとか静電気。 ケーブルでつながっている先が全部殺られてしまう事があるのと、 表面上は正常動作してしまう事があるから、 障害発見が大変。

Sat,15 Aug,2009

スペース バイオチャージ。
今更知った。 陳腐感漂うネーミングが……、Bio_100% を連想した。
ブレンパワードが1曲しか入っていないとか、 奇跡の海が入っていないとか……、 きりないか。

初回限定販売しかしなかった攻殻機動隊 S.A.C. O.S.T. 4- は?。

Sun,16 Aug,2009

最近、 ソフトバンクの携帯電話、毎月の支払額8円、8月18日で新規受付終了、 とか宣伝しているが、頭金と事務手数料が何処にも書かれていない……。

最初は大幅ディスカウントして、寡占の後は一挙に改変、の手口は、 孫正義もビルゲイツも相変わらず。 資本主義を基準として考えれば真っ当な商法なのだろうけれど。

松任谷由実「ANNIVERSARY」1989.6.28。 何で唐突に思い出したのだろう?

リンドバーグ「BELIEVE IN LOVE」1991.7.3。

今更 Wikipedia で確認してみたら。
「技の1号・力の2号」と書いてあった。あれ、逆?。
1971年のシリーズだと「技の1号・力の2号」で、 1976年の特番と2005年の劇場版だと「力の1号・技の2号」らしい。

Wed,19 Aug,2009

Subversion のリポジトリを web から閲覧。
sourceforge.jp だと、 svn:log とか svn:date とかの編集が、 デフォルトでは禁止になっている(申請すれば変更可能になるけれど面倒)。 あと、 サーバの daily backup から svn におこした時に、 順番を間違えたり内容を間違えたりすると、 修正できない(4日前にさっそくやらかした)。 それから、業務内容のリポジトリだったりすると 公開サーバに置くわけにはいかない。
そうなると、自前の webサーバにて Subversionのリポジトリ閲覧を できる様にした方が取り回しが良いかもしれない。
ざっと探した所では、 http://geekswithblogs.net/flanakin/articles/CompareSubversionWebTools.aspx" http://www.nminoru.jp/~nminoru/diary/2007/01.html#2007-01-09 http://blog.pear.co.jp/archives/419 あたりにまとめが書いてあった。
php は嫌(インストールとセキュリティがらみが面倒)、 diff は必須、と考えると、 Perl で書かれた SVN::Web か、Python で書かれた ViewVC の、 2つしか残らないらしい。 ViewVC は、sourceforge.jp で使っている奴らしい。

ViewVC は、指定リビジョンの指定ディレクトリ以下を tarball で取得する機能が有るけれど、 SVN::Web には無い。
ViewVC は CvsGraph 対応だけれども SVN::Web は非対応、 でも CvsGraph は svn に非対応だから、 どちらにしても駄目。

gnu patch-2.5.4
OpenBSD だけで、GNU-patch が SIGSEGV 出して動かない。
デバッガで追いかけてようやく判明。 GNU-patch が u形式?のタイムスタンプをパースする時に NUL文字を無視しているバグだった。
OpenBSD以外だとメモリ割当は連続して配置する傾向が非常に強い為、 NUL文字を無視しても前の行をパースした時の名残りのゴミ文字列とか 次の行の先読みバッファとかに行き着いて何とかなってしまう。
OpenBSDだと、この手のバグに遭遇した時に、 わざと「なんとかさせない」為 (「なんとかなってしまう」と、そのうち重大な事故につながる、 それを未然に防ぐ事もセキュアの1つ、と言う考えだから)に、 メモリ割当を故意に不連続に配置してある為 (隙間にはアクセス禁止領域も挟むんだっけ?どうだっけ?)、 NUL文字を無視すると死ぬ。

取り敢えず、partime.c の time_patterns[] から 「'u', 0,」の行を消せば、落ちなくなった。
副作用として、u形式?のタイムスタンプがパースできなくなる。

↑ って、gnu patch の最新版は 2.5.9 か。orz
上記の件は 2002-02-17 に修正したって書いてあるし。 実際、ちゃんと治っていたし。
コンパイル中に BSD系で setmode() 回りがこけるバグも治っているし。
私は一体いつから更新していなかったのだ?。

subversion 1.6.4 on OpenBSD 4.4R
make check で FAILURE が出た。 fs-pack-test [10/71], commit_tests.py [33/71], update_tests.py [34/71], prop_tests.py [36/71] の4つ。
詳細を追いかけてみた。
Too many open files
env: python: No such file or directory
……。
一般ユーザのファイルデスクリプタの上限数が 128 だったが、 それを使い切ったらしい。 limit descriptors 256 にした。
python インタプリタの実名が /usr/local/bin/python2.5 なのだが、 svnのテストスクリプト内で再帰する際に テストスクリプトが呼び出す実名を python 決め打ちしていて、 行方不明になっているらしい。 /usr/local/bin/python にリンクを張った。
これで全部通る様になった。

anthy alt-depgraph-090712。
「4か」とかで変換しても「4日」が出ない。
当たり前だけど。

Thu,20 Aug,2009

subversion 1.6.4 on OpenBSD 4.4R、昨日の続き。
で。今度はロケールがこける。

svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is ja_JP.eucJP
svn: warning: please check that your locale name is correct
?\228?\189?\191?\231?\148?\168?\230?\150?\185?\230?\179?\149?\227?\130?\146?\231?\159?\165?\227?\130?\138?\227?\129?\159?\227?\129?\132?\227?\129?\168?\227?\129?\141?\227?\129?\175 'svn help' ?\227?\129?\168?\230?\137?\147?\227?\129?\163?\227?\129?\166?\227?\129?\143?\227?\129?\160?\227?\129?\149?\227?\129?\132?\227?\128?\130

こんな感じになる。
……。
OpenBSD は locale が ISO-8859系くらいしか無いのを忘れていた。
毎回ウォーニングを表示された上に主メッセージが文字化けでは鬱陶しいので、 「びえんべにいどすあら - ぱひなでくらてぃ - あせるかで *BSD - ja locale patch for OpenBSD」 の OpenBSD 3.9用を入れてみた。OpenBSD 4.4 だけど問題無し。 表示メッセージがまともに読める様になれば良く、 ロケール対応がどうしても欲しいと言う訳では無いので、 xpg4dl は入れていない。
env LD_LIBRARY_PATH=path_to_working_dir/ svn help
とかすると、ちゃんと日本語メッセージが表示される様になった。
問題無い様なので libc.so.48.0 を更新…… しまったぁ(泣。 リモートで作業中にやっちまった。 サーバ死んだ。

Fri,21 Aug,2009

subversion 1.6.4 on OpenBSD 4.4R、昨日の続き。
何とかサーバ復旧した後に気付いた事。
vim の様に、既に多言語対応化しているソフトにて、 ロケールがこける様になった。
日本語の文字列上でカーソル移動や文字削除を行うと、 1バイトずつ処理しよる。
駄目だわ……。
いやまぁ、ロケールを無視して 「ロケール対応になったつもり」として処理させているので、 1バイトずつ処理するのは当然ではありますが > thomas仙人様

↑ vim の場合、 未知ロケールだと iconv を使って1文字のバイト数を取得するけれども、 既知ロケールだと mblen() を使って1文字のバイト数を取得するらしい。
OpenBSD の mblen() は、不正入力と NUL文字以外には 1 しか返さないから、 日本語の文字でも構わず1文字=1バイトと判定してしまうらしい。

↑*2 つまるところ、 OpenBSD でも多言語対応化している様なソフトの場合。
OS が未知のロケールだと返答してきた場合、 言語関連の処理を OS に頼まずに自前で処理するので、 正常に処理される。
ところが OS が既知のロケールだと返答してきた場合、 言語関連の処理を OS に依頼するけれども、 本当は対応していないものだから、 処理がメタメタになる。

↑*4 OpenBSD で svn の日本語処理がこける方。
さんざんデバッガやらソースコードやら追いかけ回した結果。
原因は、 ロケールが ja_JP.eucJP の時に、 svn が使っているライブラリである apr の中の apr_xlate_open() が、 topage = APR_LOCALE_CHARSET の解釈を間違えている所らしい。
APR_LOCALE_CHARSET なので OS から文字コードを取得しようとするが、 apr_os_locale_encoding() の nl_langinfo(CODESET) にて 「646」と言う回答を得て、ISO-646 だと判断しているらしい。
nl_langinfo(CODESET) が「646」を返すのは何故かと言うと、 OpenBSD にはロケールが無いからデフォルトの 646 を返してしまう。
結論:
svn とか apr とか apr-util は、 ロケール判定を OS に完全依存しているので、 ロケールが無い OS では I18N では動かない。

↑ と言う事は、 apr_os_locale_encoding() を改造して、 強引に文字コードを突っ込んでやれば、それっぽく動く、 と言う事か。

投げやり行き当たりばったりに、misc/unix/charset.c にて
APR_DECLARE(const char*) apr_os_locale_encoding (apr_pool_t *pool)
{
#if defined(HAVE_NL_LANGINFO) && defined(CODESET)
    const char *charset;

    const apr_status_t ret = apr_env_get( &charset, "APR_OS_LOCALE_ENCODING", pool );
    if (APR_SUCCESS == ret) {
        return apr_pstrdup(pool, charset);
    }

    charset = nl_langinfo(CODESET);
    if (charset && *charset) {
#ifdef _OSD_POSIX /* Bug workaround - delete as soon as fixed in OSD_POSIX */
        /* Some versions of OSD_POSIX return nl_langinfo(CODESET)="^[nN]" */
        /* Ignore the bogus information and use apr_os_default_encoding() */
        if (charset[0] != '^')
#endif
        return apr_pstrdup(pool, charset);
    }
#endif

    return apr_os_default_encoding(pool);
}
ってな感じで。
環境変数 APR_OS_LOCALE_ENCODING が存在したら、 その中身をロケールの文字コード種別とみなします。

↑ これで、svn の log に日本語を使っても、 問題無く通る様になった。 log に日本語使うな、と言う説も有るけれど……。

Sat,22 Aug,2009

FreeBSD 6 で USBマウスが死にまくっていた件、 Sat,24 Feb,2007に発端、 Thu,17 Jan,2008Sat,19 Jul,2008Mon,18 Aug,2008Wed,17 Dec,2008Fri,16 Jan,2009の続き。
今日もまた、USBマウスが死んだ。 今回も、web ブラウザを操作していて、 パワーセーブの最低クロック状態に対して 最大CPU負荷をかけた瞬間に、 死んだ。毎回このパターンだと思う。
初期の頃の様に、毎週の様にバンバン落ちる事は無くなったものの、 1〜2ヶ月に1回くらいのペースで落ちる。   やっぱり、CPUパワーが非力なマシンの方が発症しやすい気がする。 初期の頃はパワーセーブを効かせて 250MHz まで落としていたが、 途中から余りの遅さに我慢できなくなって下限速度を 500MHz まで引き上げたら、起きにくくなった。   まぁこれでも遅い (負荷上昇時のクロック引き上げが人間の反応速度に追いついていない) んだけどさ……。 OSデフォルトだと、負荷ポーリング間隔 500ms だったけれど、 100ms にしてもやっぱり反応が遅い。 ポーリング 100ms、クロック下限 750MHz にして、 ようやくまともな反応速度になる。ただそれをやると熱が……。   ネットブックの場合、 熱設計とかバッテリの持ち時間とかが、 クロック下限が 100〜150MHz 辺りで設計されているだろうから、 クロック下限の引き上げとかやると、 加熱とかバッテリ持ち時間とか、悲惨な事になるのかな。 アイドリング割合がどのくらいで考えられているのかわからないけれど、 アイドリング割合5割と考えても1.5〜2.5倍の消費電力になっちゃうから……。 昨今の電気製品の許容度設計から考えると、耐えられるとは思えん。

で、今日、ようやく、USBが死んだ後の復帰方法が判明。
まず、 uhci/ohci/ehci を含む usb ドライバを全て、 カーネル埋め込みからカーネルモジュールに変更して、 カーネル再構築&カーネルインストールする。 uhci/ohci/ehci と usb を全て埋め込みから外さないと、 カーネルコンパイルでエラーになるから注意。   それから /boot/loader.conf にて、 usb_load="YES" とか ums_load="YES" とか umass_load="YES" 等の、 使用する USB関連のドライバを起動時に読み込む様にする。
で、新カーネルで再起動。
これで仕込みは完了 (今回の場合、この仕込みを6月頃に予めやっておいてあった)。

実際に、
usb2: host controller process error
usb2: host controller halted
とか出て USBドライバが死んでしまったら、
% sudo kldunload umass
% sudo kldunload ums
とかやって USB関連のドライバを全部はずした後に、 % sudo kldunload usb
として、USBドライバを完全にはずす。 それから
% sudo kldload usb
% sudo kldload ums
% sudo kldload umass
とかすれば、無事、USB回りが再起動。
あとは、USBデバイスを一回抜き挿しすれば、再度使える様になった。
当たり前と言ってしまえば当たり前だけれど。

Sun,23 Aug,2009

anthy alt-depgraph-090712。
「|右|書き|と|」(|みぎ|かき|と|) 「|左|書き|を|」(|ひだり|かき|を|) 「書き」の名詞化?をすると助詞が付属しない。 とはいえ、仕様と言えば仕様だし、対応を考え始めるときりが無いと思う。
Sun,20 Sep,2009 追記:
誤読。 正しくは「みぎがき」「ひだりがき」だそうです。
vagus氏 - 丘の道を登り - 2009年09月15日
御指摘・対応、有り難うございます。

Mon,24 Aug,2009

svn がまたこけた。
今度は、OS とか環境とかには、ほぼ非依存でこけた。

ファイルのデータを送信しています ....svn: コミットに失敗しました (詳しい理由は以下のとおりです):
svn: 'hogehoge/configure' のコミットを準備する際に
svn: 改行文字形式が一貫していません
svn: コミットメッセージが一時ファイルに残っていました:
svn:    'foo/svn-commit.tmp'

とか出て、コミットが拒否される。
hogehoge/configure を見たら理由はすぐに判明。
hogehoge/configure には svn:eol-style=native 指定をしているのだが、 hogehoge/configure中に ^M が直で書いてあって(ac_cr の所)、 svn がこれを改行と誤判定している。
この問題は、autoconf-2.62 から増えた問題らしい。

autoconf-2.64 にて
-ac_cr='^M'
+ac_cr=`echo X | tr X '\015'`
で、対応していた。 ac263 ではまだ修正されていなかった。

↑の件、日本語のサイトが1件もかからなかった。
sourceforge.jp の svn を適当に覗いてみたら、 configure が svn に入っていないか、 2.61かそれ以前だった。

↑*2 でだ。
BSD系だと ac213 と ac262 の2本立てで、 ac264系はまだ ports に降りてきていないのだよね……。
Debian/Ubuntuだと ac213 と ac259 と ac261 の3本立てで、 experimental は ac263 だった。 Ubuntu の新しいバージョンか何かだけ ac264 が来てた。

Tue,25 Aug,2009

今月の Interface。
Realtime Ubuntu と言う物があるらしい。
記事中の説明で「ハードリアルタイム」と書いてあったが、 あの説明だと「ソフトリアルタイム」だと思うのだが。
で、Realtime Ubuntu のサイトを見たら、確かに 「This specification details the plan to improve hard real time support in Ubuntu ...」 と書いてある。
でも、実体は「soft realtime」だと思うのだが……。
私が見落とした/誤解した/気付いていない何かが有るのか、 Realtime Ubuntu の面子に ソフトリアルタイムとハードリアルタイムの違いを 理解している人がいない/全員誤解している/ そもそも違いがある事を知っている人がいないのか、 政治的/スポンサー的理由により 敢えてハードリアルタイムと書かなくてはならない事情が有るのか。

それはともかくも。

Xenomai GNU/Linux-adeos や、 RTAI GNU/Linux-adeos や、 RT-Linux や、 ART-Linux 辺りと比べて、 使い勝手とか信頼性とかって、どうなのだろう?。

Thu,27 Aug,2009

anthy 拙作パッチ更新。
かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ

「せいさくかいし」で変換したら、「|政策|開始|」になった。
そんなバカな、と言う事で PRINT_CONTEXT してみたら、 複合語の「|政策|課|」(|せいさく|か|)の 「政策」の部分を適用して高加点になっていた。
そんなのは嫌なので、 複合語や OCHAIRE学習を適用して高加点にする際には、 右側の文節区切り位置候補が一致しているかどうかも、 判定条件に加えてみた。

この辺の深読みをすると、 第1文節の変換候補として「|政策|」を選択した時には、 自動的に右側の文節区切り位置候補を変更して 「|課|」もしくは「|課 + (付属語)|」を提示する、 とかもできるかもしれないが。
面倒なのと、 anthy って変換候補の変更をした時に 文節区切り候補の変更をしても平気な構造になっていたっけ?、 と言う問題と。

今回の修正の機能を追加しようとソースを追いかけていた時の話。
原作版 anthy にて、構造体の中のとある変数に、 文節の種類によって違う意味の内容を入れている事に気付いた (struct meta_word の mw1 の内容が、 OCHAIRE学習由来の文節の場合は右側の文節の内容で、 複合語由来の文節の場合はこの文節の内容)。 右側の文節群の判定なので、mw1 を流用できるかな、とした矢先の事だった。 そう言うのはせめてコメントに書いて……。
私の場合は、 こういうのは、いちいち union か struct でラップをかけるから、 バロックとかパラノイアとか分類魔とか言われるのだけれど……。

Fri,28 Aug,2009

svn で checkout した作業領域を tar で固める時に、 .svn を除外した上でファイル名でソートしながら固める方法。
在来型の?ファイルシステムの場合、 FD(ファイラー)でソートして記録してから tar で固めると、 ソートされた状態にはできるけれども。
NFS とか sshfs とかだと、その手は使えないし、 FD が入っていないとか権限が足りないとか言う場合も、 その手は使えない。
ソートしないで固めるのは楽は楽だけれども、 似たファイル名に似た内容が偏っている様な場合、 ソートの有無で、1〜2割くらい圧縮後のサイズが違ってきたりする。 似た拡張子に似た内容が偏っている様な場合は、 拡張子でソートすれば良し。
% find . \! -type d \! -path "*/\.svn/*" | sort | tr \\n \\0 | xargs -0 tar -rvf - | lzma -8 > archivefile.tar.lzma
取り敢えず、これでできた。

svn。
ブランチにて merge する毎に、 編集していないのに M が付くファイルがあった。
svn:mergeinfo が付いていた。
CURRENT系列からbranchesに svn merge かけた時に、 -r や -c を付け忘れるか間違った指定をしてしまい、 その時に付いてきてしまって、それ以来ずっとらしい。
リビジョン 100個分以上ずっと、 余計な svn:mergeinfo が付いてしまっているので、 一旦展開して消してコミットしなおし、と言う方法は無理。
と言う事で、svnadmin dump して、 dump ファイルを直接エディタで編集して削除して、 svnadmin load。
エラー無しで一発で通った。 svnadmin verify してもエラー無し。 珍しい。

svn で diff。
複数のリビジョンの diff を同時に閲覧したいのだが、 どうすればいいのだろう。

--- foo(rev11) 2009-12-34 56:78:91.000000000 +0900
+++ foo(rev12) 2009-12-34 56:78:92.000000000 +0900
+++ foo(rev13) 2009-12-34 56:78:93.000000000 +0900
+++ foo(rev14) 2009-12-34 56:78:94.000000000 +0900
@@ -12,7 -12,7 -12,7 -12,7 @@
       line12
       line13
       line14
rev11 -line15(rev11)
rev12 +line15(rev12)
rev13 +line15(rev13)
rev14 +line15(rev14)
       line16
       line17
       line18
みたいな感じで……。

↑ Tue,01 Sep,2009 追記:
diff な表示は見つからなかったが、 指定リビジョンにおける最終状態に於いて、 どの行がどのリビジョンで書かれたものか、は、 閲覧するソフトが見つかった。
Annotation Browser とか Annotate Browser とか Blame Browser とか 言うらしい。
TkCVS-8系, SVN::Web, ViewVC が、その機能のカラー表示を持っていた。 SVN::Web や ViewVC は Webブラウザからで、 TkCVS はコマンドラインから。
それ以外の svn 操作用の GUI なソフトでも、大抵は装備しているらしい。 ただ、前述3つを除き、カラー表示機能はみつからなかった。
というか。
そもそも svn blame すれば見る事が出来た。

Sun,30 Aug,2009

English Fire ¥1,250-。

タイムセールで CD 半額。
タイムセール、娘フロ ¥775- で3枚。 タイムセール、娘トラ ¥775- で1枚。 娘たまは無かった。
タイムセールの終了時刻を1時間延長しました、とかアナウンスが。 決算の売上目標に届いていないのかな?。

というわけで。
Speed!! Miracle!! Spacy!!

svn の svn:mergeinfo の続き。
再度 merge tracking info の点検をしたら、 今度はディレクトリの svn:mergeinfo がずれていた。

Daily Backup から svn のリポジトリに落とし込む時に、 途中で何個か抜けてしまい、穴埋めしようとして。
% mv hoge hoge.old
% svnadmin dump --incremental --deltas -r 0:123 hoge.old > dump0_123
% svnadmin dump --incremental --deltas -r 124:456 hoge.old > dump124_456
% svnadmin dump --incremental --deltas -r 457:head hoge.old > dump457_head
とかやって、抜けている方のリポジトリを dump に変換。
一旦、svndamin load hoge < dump0_123 で 0〜123 までの svn リポジトリを作った状態にして、 checkout して抜けてしまった分を commit かます。 そこから続きのぶんを svnadmin load hoge < dump124_456 とかやって、 またもや checkout して抜けてしまった分を commit かます。 さらに svnadmin load hoge < dump457_head とかやって、 補填完了。
これをやると、dump457_head の読み込み時に、 svn:mergeinfo のリポジトリ番号が修正されないケースと、 修正しなくてもいいのに修正されてしまうケースが、 ある様に見える。
……。
書いてみて気付いた。
この操作方法だと、 トラッキングの番号を修正できるわけが無いんだ。
svn が 旧457(新459)〜HEAD を読み込む際に、 旧123 の後に 新124 が追加された事を知る方法が無いのだもの。
旧456 の後に、新457 と新458 が追加されたと誤解して、 svn:mergeinfo を修正するから、 こちらの期待と違う修正がされてしまうのだと思う。
対処法としては、 一連の操作で追加するのは連続した1ヶ所のみ、 とすれば、多分、期待通りに修正してくれると思う。

ファイル破損の復旧支援ツール parchive(par2)の話、 Sun,29 Mar,2009の続き。
バックアップをとる時に。 個人でテープストリーマーを使う気にはならないし、 MO や MD-DATA はメディアやデータの耐性は高くても ドライブの耐久性が低い上に値段が高くて しかも継続入手性に大きな不安がある。 となると、諦めて、 データが破損する事を前提にしている CD-R/RW, DVD-R/RW/RAM/+R/RW 辺りを使わざるを得ない。 そうすると、 ファイルが破損する事を前提に、 何らかの修復の為の情報も付与する必要がある。
rar はアーカイビングしないと復旧の為の情報を付加できないので面倒。
dvdisaster は ISOイメージにしか付加できないので、DVD-RAM で使えない。 あといちいち ISOイメージを操作するのは面倒。
par2(parchive) は、対象がファイルであれば何にでも付加できる。
と言う事で、選択肢は par2 しか見つからなかった (HDD直のバックアップツールとか市販のバックアップツールとかは 除く)。

で、日本語の使い方を探してみたが、 MS-Windows から GUI で使うソフトの説明(QuickPARなど)しか 見つからなかった。
Unix系から CUI で使うソフトの説明が見つからない。
仕方が無いので諦めて英語の説明書を読んだ。

パッケージシステムを導入している OS の場合、パッケージ名は par2 とか par2cmdline とかなっている場合が多いっぽい。

NetNews(Usenet) とか web とかに流すデータの場合、 復旧専用のデータのサイズは小さい方が良いので、 par2 には大きい物から小さい物まで色々なサイズのパリティを 生成する機能が有るけれども、 バックアップ用なので、最大サイズのパリティが1個有ればよい。
と言う事で、パリティを生成する時は
% par2 c -n1 -r25 datafile
とか、
% par2 c -n1 -r25 par2file datafile
とする。オプションのアルファベットと数字の間にはスペースを入れない。
-r の次の 25 が、何%の破損まで耐えられる様にするかの値。
これで datafile.par2 と datafile.vol000+???.par2 の2つのファイルが 作られる。
datafile.par2 が処理用の基本情報で、 datafile.vol000+???.par2 が修復用のデータ、らしい。

データファイルが破損していないかどうか検査する場合は
% par2 v datafile.par2
破損している場合、何ブロックの修復用のデータが必要か言ってくる。 その値が par2 c で生成した修復用のデータのブロック数を越えている場合は 修復不能になる。

実際に修復するには
% par2 r datafile.par2

実際に試した感じだと、小さいファイルの場合、 元ファイルよりも修復用ファイルの方が大きくなった。 元ファイルが大きくなると、 修復用ファイルのサイズは par2 c の -r で指定した割合に近づくらしい?。
また、生成時の演算に結構時間がかかる。 元データ 600MiB に対して 25%で生成すると、 Core 1.6GHz で 15〜25分くらいかかった。 メモリリソース消費量は 20MiB くらいだったが、 これはどうやら par2側で上限をかけていて、 メモリ消費量が 16MiB を超える場合は分割して処理しているらしい。

Tue,01 Sep,2009

SVN::Web。
subversion-1.6.4 の被呼仕様と、 SVN::Web-0.53 の svn の呼び出し仕様が、 合っていないらしい。

1.6.4 の場合:
svn: In file 'subversion/libsvn_ra/deprecated.c' line 289: assertion failed (*path != '/')
svn: In file 'subversion/libsvn_ra/libsvn_ra.c' line 759: assertion failed (*path != '/')
svn: In file 'subversion/libsvn_ra/libsvn_ra.c' line 783: assertion failed (*path != '/')
1.6.6 の場合:
svn: In file 'subversion/libsvn_ra/deprecated.c' line 289: assertion failed (*path != '/')
svn: In file 'subversion/libsvn_ra/ra_loader.c' line 759: assertion failed (*path != '/')
とか出て、こける。
面倒なので、subversion の該当部分をコメントアウトしたら、 動く様になった……、そんなんでいいのか?。

SVN::Web が I18N に真っ当に対応していなかった。
英語以外の言語は全て UTF-8 とみなしてしまうので、 閲覧しているファイルが EUC-JP とか ISO-2022-JP とかで書かれたものだと、 SVN::Web が html に追加したヘッダ/svnのログ/フッダが UTF-8、 ファイル本体が EUC-JP とか ISO-2022-JP とか、 というごちゃ混ぜ状態で、まともに閲覧できない。
web で検索しても、 対応パッチを作ってみようかといじりはじめた、 と言うのは見つかっても、完成したパッチは見つからなかった。
仕方が無いので自分で書いた。
SVN::Web を日本語対応にするパッチ

SVN::Web は、tarball ダウンロードに対応していなかった。
過去の特定リビジョンのファイル一式をダウンロードしたい、 とか言う時に痛い。
ViewVC は tarball ダウンロードに対応 (セキュリティ上の不安から、デフォルトでは無効)、 らしい。

↑ あと、SVN::Web にはファイル一覧表示のソート機能が無かった。
ViewVC には、各種属性毎のソート有り。

ViewVC。
こちらも日本語に対応していなかった。
En Sourdine」 この方の、 「viewvc の(日本語文字コード混在環境向)パッチ」 を 「pykf」 で使うと、日本語対応になった。
デフォルトの chardet で使うと、 EUC-JP を EUC-TW と誤認してこける場合が有った。

CvsGraph。
データの構造が全然違うから Subversion 対応にする気は毛頭無い(超意訳)。 らしい。

Wed,02 Sep,2009

SVN::Web が I18N に真っ当に対応していなかった件の昨日の続き。
こんな事も有ろうかと?、 リポジトリを生成する時に svn:mime-type に charset を書いておいたのだった。
と言う訳で、 svn:mime-type に charset の記述が有る場合はそれを用い、 無い場合のみ Jcode.pm の文字コードの自動判別を行う様に修正。
SVN::Web を日本語対応にするパッチ

SVN の編集履歴とか Branch Diagram とか Annotate/Blame とかが GUI表示できるソフト。
KDE や Qt4 や Eclipse は、tk や IDE をインストールするのがしんどいので、 実地確認は省略。

SVN の GUI I/F
名称 使用tk svn:mime Branch Diagram Annotate/Blame svn st 特記事項
esvn-0.6.12 Qt3 「martian properties string」とかエラーが出て何も表示されない。 無し 有り、但し色分け表示はしない色分けアイコンで表示 日本語が正しく表示される。
kdesvn KDE4 不明 Revision Tree が有るらしい 有り、色分け表示するらしい。モノクロ文字表示らしい FreeBSD-7以前は KDE4 非対応。
qsvn Qt4 正しく処理できる無い 無い 色分けアイコンで表示
RapidSVN-0.9.6 wxGtk 正しく処理できる無い 有り、色分け表示はしない、日本語が表示されない 色分けアイコンで表示 フォーカスが移る度に Working Copy の再読み込みを行い、ファイラーの表示位置を先頭に戻すので、重い上に操作しにくい。
subclipse Eclipse 不明 Revision Graphs が有るらしい不明 不明
subcommander-1.2.3Qt3 正しく処理できるTree Graph?が有る(横表示)、但し連動ログ表示は無い。 有り、色分け表示はしない、日本語が文字化けした。 行の色と文字で表示 何か操作する度に時々 SIGSEGV で落ちる。
Log 表示の際に「Run」をクリックするまでは何も表示しないので、こけたと誤解した。
……長大なリビジョンツリーを解析かけたら途中で表示が切れた。
subcommander2 Qt4 不明 不明 不明 不明 FreeBSD-6 は非対応
subversive Eclipse 不明 Revision Graph が有るらしい 不明 不明
TkCvs-8.1 Tcl/Tk 無い Tree Graph?が有り(縦表示)、ノードを選択するとそのリビジョンのログも表示される。 有り、色分け表示、日本語だとこけて何も表示されない アイコンで表示 OpenBSD だと日本語が ISO-8859フォントで表示されるが、FreeBSD だと日本語も通る。
……長大なリビジョンツリーを解析かけたら途中で表示が切れた。
拙作「TkCvs を日本語ロケール対応にするパッチ」あります。
SVN::WEB-0.53 perl-CGI 無い 無い 有り、モノトーン色分け表示 無し 標準状態では ASCII か UTF-8 しか通さない(eucJP が通らない)。 拙作「SVN::Web を日本語対応にするパッチ」あります。
ViewVC-1.1.1 python-CGI無い 無い 有り、色分け表示はしない 無し 指定ディレクトリを丸ごとダウンロードする機能が有る。
svn-graph.pl perl 無い 分岐のみ表示可能。merge が表示されない。 無し 無し
TkCvs-8.1〜8.2 で日本語ロケールで Annotate Browser を動かすと出るエラー。

can't read "now": no such variable
can't read "now": no such variable
    while executing
"$blameproc $w.text $now $logline $lc"
    ("foreach" body line 3)
    invoked from within
"foreach logline [lrange $log_lines 0 end-1] {
        incr lc
        $blameproc $w.text $now $logline $lc
      }"
    (in namespace eval "::annotate::0" script line 301)
    invoked from within
"namespace eval $my_idx {
      set my_idx [uplevel {concat $my_idx}]
      variable revision [uplevel {concat $revision}]
      variable file [uplevel..."
    (procedure "annotate::new" line 10)
    invoked from within
"annotate::new $revflag $file "svn""
    (procedure "svn_annotate" line 19)
    invoked from within
"svn_annotate BASE [workdir_list_files] "
    invoked from within
".workdir.bottom.buttons.cvsfuncs.bannotate invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 22)
    invoked from within
"tk::ButtonUp .workdir.bottom.buttons.cvsfuncs.bannotate"
    (command bound to event)


TkCvs は、 現在のリビジョン番号を取得する為に、 svn info を呼び出して、 応答の中から「Revision: 1234」と言う行を検索しているのだが、 日本語ロケール上で svn info すると 応答が「リビジョン: 1234」となってしまって見つからない、 と言う話だった。
TkCvs 内の svn を呼び出している部分を 「env LC_ALL=C svn」に変えてやれば、 日本語ロケールでも通る様になった。
TkCvs 自体を実行するロケールを C にしてしまうと、 ビューワーで日本語が文字化けする (ISO-8859 辺りで表示してしまう)ので駄目。

↑ パッチにしておいた。
TkCvs を日本語ロケール対応にするパッチ

↑*3 TkCvs が OpenBSD 上で日本語通さないのは……、 日本語フォントを入れ忘れたか(……入れた筈だけれど)、 例に依って例の如く OpenBSD にはロケールが無いせいか。
……。
ロケールが無いせいだった。
ロケールが無いので svn がエラーを吐いてしまい、 TkCvs が svn と通信できなくてこけていた。
ロケールを C にすると、 今度は TkCvs 内蔵のビューワーが日本語を通さなくなる。
と言う訳で、OpenBSD で使う場合、上記のパッチの様に、 一部の svn 呼び出しだけを英語ロケールにするだけでは駄目で、 全部の呼び出しを英語ロケールにする必要があるらしい。

↑ これもパッチにしておいた。
TkCvs を日本語ロケール対応にするパッチ

これで OpenBSD でも日本語が表示される様になったが……、 字が汚かったり潰れていたり。
日本語フォントはインストールしてあるけれど、 こちらが望んだフォントを使ってくれていない。
TkCvs のソースを追いかけたら、 とにかく英語フォントを使う様になっており、 フォント変更は不完全だった。

↑ 毎度、これも変更可能にするパッチを作った。
TkCvs を日本語ロケール対応にするパッチ・フォントを変更可能にするパッチ

これでようやっと、 日本語を含む内容の操作に耐えられる様になった……。
惜しむらくは、プロパティエディタが無い事か。

Fri,04 Sep,2009

subversion のプロパティを ファイル/ディレクトリ毎に1行ずつ一覧表示するスクリプト 「各種スクリプト - lssvn.pl」 追加。

こんな感じ。

<DIR>svn:mergeinfo		./
<DIR>		./m4/
<DIR>		./src-worddic/
<DIR>		./sample/
<DIR>		./depgraph/
<DIR>		./doc/
<DIR>		./src-main/
<DIR>		./src-diclib/
<DIR>		./alt-cannadic/
<DIR>		./test/
<DIR>		./mkworddic/
<DIR>		./anthy/
<DIR>		./mkanthydic/
<DIR>		./src-splitter/
<DIR>		./src-ordering/
<DIR>		./src-util/
<DIR>		./calctrans/
svn:executable,svn:mime-type="text/x-sh"		./configure
svn:mime-type="text/plain"		./anthy.spec.in
svn:mime-type="text/x-makefile"		./Makefile.in
svn:mime-type="text/plain; charset=euc-jp"		./AUTHORS.patch
svn:mime-type="text/plain"		./Doxyfile
svn:mime-type="text/plain; charset=euc-jp"		./AUTHORS
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./depcomp
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./compile
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./config.guess
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./config.sub
svn:mime-type="text/x-sh",svn:eol-style="native"		./ltmain.sh
svn:mime-type="text/plain"		./README.en
svn:mime-type="text/x-sh",svn:eol-style="native"		./configure.ac
svn:mime-type="text/plain"		./INSTALL.patch
svn:mime-type="text/plain; charset=euc-jp"		./INSTALL
svn:mime-type="text/plain; charset=euc-jp"		./DIARY
svn:mime-type="text/plain"		./COPYING
svn:mime-type="text/plain"		./anthy-conf.in
svn:mime-type="text/plain; charset=euc-jp"		./NEWS
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./mkinstalldirs
svn:mime-type="text/plain; charset=euc-jp"		./ChangeLog
svn:mime-type="text/plain"		./anthy-test-conf.in
svn:mime-type="text/plain"		./anthy.pc.in
svn:mime-type="text/plain; charset=euc-jp"		./README
svn:mime-type="text/x-chdr"		./config.h.in
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./elisp-comp
svn:mime-type="text/x-makefile"		./Makefile.am
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./missing
svn:mime-type="text/x-m4"		./aclocal.m4
svn:executable,svn:mime-type="text/x-sh",svn:eol-style="native"		./install-sh

Sat,05 Sep,2009

とりあえず。
森の路はずれ - 物分かりの良いメディア、聞き分けの悪いメディア
それ、何て銀英伝?。   銀英伝は、その実、田中芳樹の政治談義、だと思うのですよ。
以下蛇足。
日本経済新聞や日経CNBC 辺りは、かなり強力に民主党批判をしていました (スポンサーやコネなどで経団連とのつながりが強いのだろうか?)。 日経新聞の論説委員あたりは、具体的な表現字句は忘れましたが、 民主党が政権を取ったら日本は沈没する、と言わんばかりの勢いで。 選挙後の日経CNBC でも、 出演した竹中平蔵の方が公平に思える (竹中平蔵は、 民主には不安や課題や矛盾がいっぱい有るとは延々言ったけれども、 どの党が、良いとか悪いとか正しいとか間違っているとか、 そう言う事は言っていないので、論評と言う点ではある意味公平かも) ぐらいの勢いで。 しまいには、正確な字面は忘れましたが、 間違った選択をした責任は間違った選択をした人々に取ってもらう、 の様な感じの事まで言うし。

Tue,08 Sep,2009

.htaccess の Files 指定。
なんか、効いたり効かなかったりしていると思ったら。
Files 指定はファイル名だけの記述で、 ディレクトリ名/パスは含まないらしい。
正規表現で ^ とか $ とか書くと、ファイル名の先頭/最後尾になるらしい。

Thu,10 Sep,2009

かな漢字変換の速度ベンチマーク。

唐突に現実逃避で sj3-2.0.1.23 の速度ベンチマークをしてみた。
その際に、 例に依って例の如く? ソースを展開したディレクトリとビルド作業を行うディレクトリを分けた場合に ビルドが通らない問題と、 たぶん OpenBSD でのみ発症するバグを見つけたので、 修正。
sj3 の(大多数の人の環境だと絶対発症しない)潜在バグ修正パッチ
あとでメンテナ氏の所に送っておかなきゃ。窓口は何処だろう。
google の code の issues らしい。送付した。

ベンチマーク結果は Anthy 改造パッチの詳細解説と覚え書きと落書きとグチ - 継続使用の試験結果とかベンチマーク結果とか:
Canna より 10倍前後、 原作版 Anthy より 50〜150倍、 拙作パッチ版より 80〜270倍くらい、 速いのですが……。
確かに、 Anthy の変換結果は目で追える速度だし、 Canna の変換結果はスクロールしているのが ギリギリ判るくらいの速度ではあるのだが、 sj3 は…… エンターキーを押した次の瞬間に画面がなんかちらついて、 えっと〜と思った時には終わっていると言う……。

↑ sj3 をネットワークソケット接続モードを試してみたら、 IPv6 で接続していた。 意味無くおもしろい……。

Wnn4 を試してみようとした。
Wnn4 のソースが stdlib.h をインクルードしていないせいで、 関数の返値のポインタ型を int型と誤処理されて SIGSEGV しまくった。
それを全部治しても、なぜか動かなかった。   jserver を起動しようとしても、エラーも何も出さずに何もしない。
諦めた。 Wnn4 なら FreeWnn でもほぼ同等だろうと言う事で。

FreeWnn-1.1.1-a021 を試してみようとした。
例に依って例の如く? ソースを展開したディレクトリとビルド作業を行うディレクトリを分けた場合に ビルドが通らなかった。
ccache 非対応だった。
CFLAGS とか LDFLAGS とかを中途半端に無視して -g3 が効いていなかった。
インストール時に root特権を使用しようとしてゴネてきた。

どうにかこうにか、ビルドしてインストールして。
uum を実行したら SIGSEGV で死んだ。
デバッガで追いかけたら。
malloc() で確保したメモリを初期化せずに使っていた。
GNU/Linux系だと、 malloc() で確保したメモリはゼロクリアされているケースが非常に多い為に 動いてしまうのだろうけれど。 BSD系で MALLOC_OPTIONS を付けると、ゼロ以外で埋めてから渡されるから、 直撃して死亡。

そこのところを手直しして、 uum にリダイレクトで変換させたい内容を突っ込んだら。
tty 以外につなぐな、と蹴られた。
ソースのそこの所をコメントアウトして試したら。
リダイレクトで突っ込む内容が 1kiB を越えた所か、 出力のサイズが 50kBを越えたくらいの所で、 固まった。
どうも、適度に keyin0() で何も入力が無い状態になっておかないと、 固まるらしい。
そこの所をいじって、どうにか全自動で動かせる状態になった。
ベンチマークを採ってみたら、 Canna の6倍2倍くらい速かった。
Solaris2 の emacs で Wnn4 と Canna を使った時は、 体感速度では Canna の方が速かったのだけれども。 何だろう。

Canna のベンチマークに使った canfep。
出力内容を見てみたら、 tty制御の為のエスケープシーケンスの出力が、 変換内容自体の出力の2〜3倍の量があり、 カーソル移動やら表示の削除を沢山していた。
その辺の処理を全部消してみたら。
3倍速くなった。   それでも Wnn4 より倍遅い。

これでようやく、かな漢字変換の御三家とのベンチマーク比較が完了。
いらん所で散々手間取ったので、もう嫌。
OS やアーキテクチャを問わずに スタンドアローン(ネットワーク非接続)で使用できる かな漢字変換って、 御三家+SKK+Anthy+PRIME の6つ(も?しか?)なんだよな……。 SKK と PRIME は特殊なので、 他4つと単純に並べるわけにはいかないけれど。   真字 と なつめ が未確認だ……。
今回遭遇したゴタゴタや Wnn5 以降が GNU/Linux専用になった事を考えると、 Wnn系は「OSやアーキテクチャを問わず」の点で除外したい気分。

ベンチマーク結果の結論:
sj3 爆速、連文節の学習も出来るらしい。但し、辞書の単語数の上限がかなり小さい。
FreeWnn かなり速い、但し、連文節の学習が出来ないし、ビルドに関して難有り。
Canna 十分に速い、但し、連文節の学習が出来ない。それ以外は全般的に無難。
原作版 Anthy 遅い、連文節の学習が出来る、学習量が少ない、辞書やコーパスのバランスがナニ。
拙作パッチ版 Anthy とてつもなく遅い、連文節の学習が出来る、学習する量も反映する量も多すぎ、辞書やコーパスのバランスがナニなのはそのまま。

……、何と言うか、 選びたくないけれど選ばなくてはならない選択、 の様な気がしてきた。

辞書量を捨ててでも速度重視なら sj3。
連文節変換を捨てて単文節変換での完成度重視なら Canna。
速度や完成度のバランスを捨ててでも連文節回りを重視なら Anthy系にパッチとか追加辞書とか追加コーパスとか。
独特の入力方式を覚えられるなら SKK とか風とか。

かなぁ。

Fri,11 Sep,2009

sj3 のレポート。
いかん、code.google.com の使い方が判らなくて ××しながら書いたら、 かなりぶっきらぼうになってしまった。

いかん、言葉が出てこない。 四苦八苦とか右往左往とかはちょっと違うしなぁ。 何だろう。

「四苦八苦」(しくはく)が出ないと思ったら。 正しくは「しくはっく」だった。

Mon,14 Sep,2009

vim で sed な一括置換。
set hidden にしている場合、
「:bufdo %s/pattern/replaced/g」
set nohidden にしている場合(デフォルト設定)、
「:bufdo %s/pattern/replaced/g | update」
にしないと駄目。

sed だと、 入力か出力を一時ファイルに飛ばしておかないと、 置換処理前の箇所の元データまで壊してしまうので面倒だが、 vim だと一時ファイルの事を考えなくて良い。 その代わり?、vim は遅い。多機能な分、滅茶苦茶遅い。 あと、正規表現の記法が、標準や拡張とは異なる独自書式なので注意。

argdo が、引数で指定した全ファイル (ファイルを開いたり閉じたりした場合、 現在開いているファイル一覧とは異なるファイルに対して操作する。 :args にて確認可能)に対して操作。
bufdo が、全バッファ(ファイルを開いたり閉じたりした場合でも、 現在開いているファイルに対して操作する。:ls にて確認可能) に対して操作。
tabdo が、全タブ (画面に表示されている全サブウィンドウ。:tabs にて確認可能) に対して操作。
windo が、全ウィンドウ(gvim の話か?。確認方法は不明)に対して操作。

Tue,15 Sep,2009

Anthy 拙作パッチ更新。
INDEP_HISTORY学習の適用に関してパラメータ調整。
かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ

概要:
変換しようとした文節において、 文節学習した事は無いけれども、 自立語部分だけ見れば過去に学習した事が有る場合に、 提示する並び順に関して。

例:
「げんてんが」を変換しようとした際に、 OCHAIRE学習(連文節の学習)や CAND_HISTORY学習(個別の文節の選択の学習)には 該当が無いけれども、 INDEP_HISTORY学習(使用された自立語の学習)には 「げんてん O1253000000 N3 S"原点" O1252000000 N7 S"原典" O1250000000 N10 S"減点" T1253000000 F16」 と言う該当があった場合。
利用回数が多い順に「減点が」「原典が」「原点が」と提示するべきか。
直近に使用した順に「原点が」「原典が」「減点が」と提示するべきか。
利用した回数と最後に利用した時刻からスコアを計算して 「原典が」「原点が」「減点が」 (現在時刻が 1254000000 で、 スコアの計算式が {(現在時刻)−(最終利用時刻)}÷(利用回数) で 小さいスコアを優先する場合、 「原点」が 333,333点、 「原典」が 285,714点、 「減点」が 400,000点。 )と提示するべきか。
スコア計算の場合は、どの様な計算式にするかによっても並び順が変化する。

原作版 Anthy の場合:
その様な学習は行っていない。
近いものとして INDEPPAIR学習があるけれども、 あれはかなりクセが強くて挙動の推定が楽ではない処理なので。

だいぶ前の拙作パッチの場合:
スコアだったか直近だったかの順番だった様な気がする。

今の拙作パッチの場合:
利用回数順。
なんで変えたのだっけ?。 CAND_HISTORY学習に該当が有った場合の処理に似せる為だったかも。 あるいは、INDEP_HISTORY を辞書ソースの頻度値の延長としていたのかも。

今回の調整後:
スコア順。

何故、変更しようとしているのか(蛇足):
「(略)|げんてんが|ずれた|。|」(変換)
「(略)|原点が|ずれた|。|」(確定)、
「(略)|げんてんだと|(略)」(変換)
「(略)|原点だと|(略)」(確定)、
「(略)|げんてんだった|。|」(変換)、
と変換したら、 初回に「減点が」を提示されたのはともかくも、 それ以降も立て続けに「減点だと」「減点だった」と提示されて凹んだ。
ただ、この辺りは、 CAND_HISTORY学習とのバランスとか誤学習とか好みとかの事を考えると、 利用回数の方が無難かもしれないので、悩ましい所。
CAND_HISTORY学習に「減点が」「減点だと」「減点だった」がある場合、 初回に「原点が」と変換確定して学習しても、 以降の変換にて CAND_HISTORY学習が適用されて 「減点だと」「減点だった」が提示される。 ので、それに似た挙動にするならば、利用回数順のままの方が良いかも。
かといって CAND_HISTORY学習がある場合でも 最近利用した自立語をある程度優先しようとすると、 CAND_HISTORY学習よりも INDEP_HISTORY学習を優先する事になるが、 これはあからさまに出鱈目な候補を提示するケースが多いし……。

Fri,18 Sep,2009

vim の書式自動判定。
vim の書式自動判定にて、C/C++ のヘッダファイルを、 普通なら c か cpp と判定される筈なのに objc と判定されてしまい困っていたのだが、原因が判明。
doxygen のタグの @endverbatim を行頭に書いていると、 objc と判定するらしい。   行頭の「@end」が、Object-C らしい。   @ の前に何でもいいから1文字以上入れる (但し整形後のドキュメントにも入ってしまう)か、 \endverbatim と書くか、 すれば誤判定しない。
setfiletype は、 環境設定スクリプトの1実行毎に1回しか指定出来ないらしい。 システム側の filetype.vim にて setf されると、 ${HOME}/.vimrc にて setf しても無視された。

タワーキューブ(非ルービック、2×2×3)、 9月中旬発売らしい。幻冬舎で書籍流通で¥1,260- らしい。
フロッピーキューブと同様、長手方向の回転が180°単位だから、 2×2×2 ミニキューブより難易度は低いような気がする、たぶん。

スーパーフロッピーキューブ(非ルービック、1×3×3) と言う物があるらしい。
通常のフロッピーキューブ(非ルービック、1×3×3)だと 回転が180°単位だが、 スーパーだと90°単位らしい。
回転を90°で止めた所で別の回転をして、 変な形にしたりとか変な色配置にしたりとか出来るらしい。
構造を想像してみると。 通常のフロッピーキューブの、 90°回した時に隣のエッジキューブが回転しない様にするロックを、 削り落とした感じだろうか?。

フロッピーキューブは難易度はとても低いが、 揃え方が、ルービックキューブの6面の揃え方とは全く異なる為、 ルービックキューブの揃え方の参考には全くならない。
もしかしたら、 ルービックキューブの1面だけ揃えるやり方と同じかも。
ルービックキューブは、 1面だけ揃える場合と、6面全部揃える場合とで、 揃え方の基本的な考え方が全然違うから……。

で。↑の辺りの原作者氏の webサイトの閲覧が会員制になっていた。
それから、氏の作品のパクリが流通していて困った事になっているらしい。
この2点に関連が有るか否かは不明。

4^3とか5^3のルービックリベンジやルービックプロフェッサーを 全然見かけなくなったと思ったら、日本向けは製造中止らしい。
積んどけば良かった……。

工画堂の火星計画の中古も見かけなくなった……。
箱庭は好きとは言え、プレイする時間が全く無いが……。
積んどけば良かった……。

web で検索していて見つけた、誤りの指摘。
tree3yamaのブックマーク / 2009年7月28日 (2)

はい、御指摘の通りです。
原作版 Anthy が eucJP-MS なのか CP51932 なのか 確認する前に書いた内容のままになっており、 確認後に修正するのを忘れていました。
Mon,01 Jun,2009
YEN SIGN を U+00A5 にしないのは、 下手をするとプログラムのソースでトラブル続出になる場合がある為と、 大部分の iconv がそのマッピングに対応していない為、 です。
HP-UX の iconv で eucJP0201 と指定すれば、 たぶん、YEN SIGN が U+00A5 になります。

Sat,19 Sep,2009

Anthy 拙作パッチ更新。
かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ

複合語を使用する際に、 これまでは複合語全体で1文節にして使用していたが (なんでそうしたのだっけ? 原作版や拙作パッチ旧版だと、 複合語由来の高加点の条件が大甘で、 注目文節の区切り位置さえ同じならば 前後の文節の区切り位置が違っていようが 注目文節の候補が辞書上の内容とは違っていようが 構わず高加点をしていたから、 辞書上の内容と完全一致する単語1文節のみ高加点にする様に したのだったかな? 2009413, 2009626, 2009723, 2009827 辺りで その問題自体は治したと思う)、 原作版 Anthy どおり、複数文節に分割して使用するように修正。

Wed,23 Sep,2009

alt-cannadic-090921 が出ていた。

かな漢字変換 の各エンジンの登場年。

ふと気になったので調べてみた(但し、個人的に気になった物のみ)。 とは言っても、大部分は 「ABE Keisuke - 日本語入力プログラムの歴史(年表)」 こちらに書いてあったのだけれども。

不明		NEC漢字コード入力(正式名称は不明)(1982年には存在していた筈)
不明		NEC漢字コード表入力(正式名称は不明)(単漢字変換〜単文節変換あたりと同時だったかもしれない?)
不明		NEC単漢字変換(正式名称は不明)
不明		NEC部首変換(正式名称は不明)(単漢字変換か熟語変換と同時だったかもしれない?)
不明		NEC熟語変換(正式名称は不明)
不明		NEC単文節変換(正式名称は不明)(熟語変換と同時だったかもしれない?)
1984		VJE-86
1985		ATOK3
1986		松茸
1986		NEC連文節変換
1987		NEC逐次自動変換
1987		Wnn
1987		SKK
1988		WX
1988		NEC AI変換
1989		Wnn4 → のちの Wnn4.2 - FreeWnn
1990		Canna
1991?		sj3(ソース中のコメントから推定)
1993		MS-IME
1994			Wnn4系オムロン版の最終版?
1996			Canna NEC版の最終版
1997			松茸の最終版?
1998				Canna NEC版のMS-Windows移植版
1998			sj3 ソニー版の最終版?
1999	*	FreeWnn
1999	*	Daredevil SKK (Openlab版)
2000			WXG 最終版
2000			SKK 最終版
2001				Canna NEC版のMS-Windows移植版の最終版
2001		Anthy
2002	*	Canna sourceforge.jp版
2004	*		Canna sourceforge.jp版の最新版
2005	*		FreeWnn の最新版
2007			Anthy のコア部分の最終版
2007	*		Daredevil SKK の最新版
2008	*	sj3 Google Code版
2008	*		sj3 Google Code版の最新版
継続中		Wnn (有料版のみ)
継続中		ATOK (有料版のみ)

当初開発元版でも開放系?移行版でも、 Wnn → SKK → Canna → sj3 の順番だったのか。 しかも主要部分は、1990年代の前半分頃には、ほぼ出来上がっていたのか。

Sat,26 Sep,2009

anthy の拙作パッチに関して来ていた、 要望と言うか助言と言うか、の、匿名の連絡に関して。

-----------------------------------------------------------
根本の点に関しまして、拙作パッチの主目的は、
「使えるかな漢字変換ソフトが現れるまでのつなぎとして耐えられる様にする」
です。それが出現するのが1年後なのか50年後なのか100年後なのかは判りませんが。
# ATOK は非対応OS が多く且つ有料なので「(動かないので)使えない、(自由に)使えない」に分類されています。
# SKKは「(操作が覚えられないので)使えない、(高速タイプすると指がつるので)使えない」に分類されています。
# Canna,FreeWnn,Wnn4は「(連文節を学習しない/連文節学習が弱い点が)使えない」に分類されています。
# sj3は、……、ビミョー。Anthyより先に sj3 に出会っていたら、Anthy を改造する事は無かったかもしれません。
# natume, shinji は未評価です。
# PRIME は「想定する使い方が違うので(私の場合は)対象外、(とても遅いので)使えない」に分類されています。
# mecab-skkserv は「(滅茶苦茶遅いので)使えない」に分類されています。
# それ以外の物は非対応OS が多いので(多くの物は私の使っているOSでは非対応なので)「(動かないので)使えない」に分類されています。
副目的として、
「興味深い/後人の足しになるかもしれない、アイディアを試してみる」
と言うのは有りますが。
なので、それ以上の事をする気はありません。

また、私自身は、
『Anthyが「セキュア」とか「高速」とか「組み込みに向いている」とか「消費リソースが小さい」等と主張しているのは、未踏で採択されやすい様にする為の方便』
であり、事実に反すると考えております(sj3 や FreeWnn や Canna と比べてみて下さい。一目瞭然です)。
『フリー』と言う点に関しては同意・賛同しますがね。


本題に関してですが。

oprofile は GNU/Linux専用なので、私の使っているOS/作業環境では使用できません。
gcov は試していませんが、gprof なら1年前に行いました。
その結果、結局、ボトルネックは anthy の根本設計が関与している部分だったので高速化は諦めました。
# 原作版 Anthy では、
# 処理して、処理結果を格納するのに必要なメモリ量を算出して、処理結果を破棄して、
# 算出結果を用いてメモリを確保して、また同じ処理をして、処理結果を確保したメモリに格納、
# や
# malloc() して memcpy() して malloc() して memcpy() して処理して free() して free() して、
# という、全く同じ処理を2回繰り返す、と言う基本構造を多用している事もあり。
かな漢字変換御三家との速度ベンチマーク対比を行ったのは、
「私自身が感じていた体感速度がどの程度正確なのか出鱈目なのか」
を確認するためです。

「辞書サイズ」自体に関しては、別に困っていないので、どうこうする気はありません。
# 半分以上冗談となりますが、データベース構造をいじるなら SQL にした方が良いのではないかと言う気もします。

「セキュリティ」および「スタビリティ」に関して。
Coverityの様な商用レビューサービス以前に、 flawfinder や RATS の様なフリーなコードレビューツールもあります、が、 そもそも gcc -Wall -Wextra -Werror すると山ほどウォーニングが出る時点で諦めました。
# ソースコードの作りが、
# 仕様通りの入力に対しては仕様通りの処理を行い、
# 仕様の範囲外の入力が行われる事は想定しない、
# という作りだった事もあり。
一応、valgrind だけは、行っておりますが。たしか一般的な利用法では使われない機能にメモリリークが残っていたかと。
その様な状態でレビューをかけても効果が薄い・順番が逆、だと思われます。
また、Anthy を Coverity で rung 0 から rung 1 や rung 2 にした方が良いのではないか、 と言う件は、本家 ML なりメンテナ氏なりに言って頂いた方が適切かと思います。
-----------------------------------------------------------


娘フロ、娘トラ、月末セールで各¥625-。

タワーキューブ(非ルービック、2×2×3)。
書店(個別書店規模は中くらいで経営規模が零細まではいかないが小さめの所) に行ったら。 店頭在庫無し、チェーン店在庫無し、 問屋流通はせずに出版社と直接取引の為、 取り寄せはできるかどうか判らないが試してみる事は可能、 そのばあいは早くて7〜10日くらいかかる、 とのこと。 やめておいた。
2軒目の書店 (個別書店規模は中小だがチェーン構成と資本規模がちょっと大きめの所)。 パズル系のコーナーやちょっとかさばる物が積んであるコーナーを 見て回っても見つからない。 店員専用検索端末で検索してもらった所、店頭在庫が有るらしい、 でもみつからない。 探してもらっていた店員さんがベテラン店員?に聞いた所、 店員専用検索端末の斜め後ろ、レジの脇にあった……、 灯台下暗しと言うか何と言うか……私も店員さんも全然気付かなかったし……。 ボイドキューブやフロッピーキューブもいっしょに並んでいた。 ボイドキューブが一番多くて、 フロッピーキューブ、タワーキューブと段々減っているのは……。

タワーキューブ。
事前の予想通り、簡単だった。
フロッピーキューブ同様、 付属の解き方解説書を一切見ずに、 初めて触ってから2〜3分で、解ける様になった。
特定方向の回転が 180°毎で対称性が低く状態数が少ないのが とても効いていると思う。
……。
暫くいじっていると、 私の腕前では数分では解けないパターンもある事に気付いた。 どうやら、方向が違う複数回の 180°回転の途中に 90°回転が混じると、 難易度が高めのパターンになるらしい。

TOCTTOU - Time of Check to Time of Use。
Thu,19 Mar,2009に関連 (そちらは、セキュリティホールではなくファイル/ディレクトリの破壊)。
他ユーザが書き込めるディレクトリにある ファイル/ディレクトリを操作する際に、 セキュリティホールになりやすい問題。
IPA ISEC - セキュア・プログラミング講座 - [7-5.] Unixのレースコンディション
情報処理推進機構:情報セキュリティ:調査・研究報告書:情報セキュリティ技術動向調査(2008 年下期)
問題の構造を考えるに、 起因部分の現象としてはレースコンディションとかハザードとかに近い話、 と言う理解でいいのかな?。   web上のセキュリティ用語辞典の類によると、 ソフトウェア方面の場合、 TOCTTOU の様な状況をずばりレースコンディションと呼ぶらしい。

Tue,29 Sep,2009

omniORB-4.1.3。
標準のままだと OpenBSD でコンパイルが通らなかった。 -fPIC が必須らしい。
ビルドするだけで30分かかった……。

異環境間で通信が通らない。 omniORB4.0系なら通っていたのに、 omniORB4.1系にした途端に通らなくなった。
fstat を見てもちゃんとポートは開いているし、 tcpdump まで駆り出して見ても、tcp6 のパケットが……、
tcp6?
OpenBSD側が IPv6 で送受信しようとしていて、 FreeBSD側が IPv4 で送受信しようとしているだけだった。
そりゃ通らんわ。

omniORB-4.0.7およびそれ以前の4.0系全部と 4.1.1およびそれ以前の4.1系全部で発症していた、 OpenBSD にて GIOP回りの例外処理がこけて throw が catch されずに abort してしまう問題は、 今回は何故か発症しなかった。
はて?。
OpenBSD、gcc、omniORB のどれが原因だったのかは不明。

Wed,30 Sep,2009

anthy において、 複合語の最後尾以外の文節の品詞は、どうなっているのか。
vagus氏 - 丘の道を登り - 2009年09月28日 - 覚書: anthy の複合語関連」 の枝葉の部分の話関連。

Tue,06 Oct,2009 に用例辞書の解析結果あります。

Thu,08 Oct,2009 追記:
「予備知識」の部分が、間違っていたり別件とごっちゃになっていたり紛らわしかったりしたので、ほぼ丸ごと書き直し。
「補足:得点の計算方法:」を追加。

Fri,09 Oct,2009 追記:
「補足:得点の計算方法:」が間違っていたので修正。

Sat,10 Oct,2009 追記:
「補足:得点の計算方法:」がまた間違っていたのでまたもや訂正。

Mon,12 Oct,2009 追記:
「コーパスの構造:」(Sun,27 Sep,2009〜Sat,03 Oct,2009)をこちらに移転。

Fri,23 Oct,2009 追記:
trans_info と cand_info を追記。

-----------------------------------------------------------
予備知識:
辞書の元データで指定している形式の「品詞」は、そのまま直接使われる事は無い。

付属語の付加の際には、src-worddic/wtab.h と src-worddic/ptab.h を使って、形式を変換する。
この形式では、辞書の元データで指定している形式の「品詞」と、1対多で対応する(1が辞書側、多が ptab.h側)。
品詞が増えちゃうのです。

コーパスは、
・文節区切り位置を決める時の、文節の接続確率
・候補の並び順を決める時の、文節の接続確率(文節区切り位置を決める時とほぼ同じ)
・候補の並び順を決める時に、コーパスの例文と一致する候補に加点を行う(用例辞書 udict と似た使われ方)
の3ヶ所2種類の使われ方をする。このうち、確率を得る際に品詞が使われる。加点を行う際には品詞は見ない。

補足:
コーパスから得る文節の接続確率のうち、
「文節区切り位置を決める時」に使われるのは trans_info データベースで、
「候補の並び順を決める時」に使われるのは cand_info データベースです。
別のデータベースなんですね。どこが違うかまでは調べていません。


コーパスから確率を得る時は、src-splitter/segclass.c の anthy_set_seg_class() にて、品詞を seg_class, dep_class の形式に変換する。
seg_class の一覧は anthy/segclass.h の seg_class と dep_class に記述されています
(日本語での表記および anthy-agent にて PRINT_CONTEXT した時の表記は src-splitter/segclass.c の seg_class_tab と dep_class_tab)。
この形式では、辞書の元データで指定している形式の「品詞」と、多対1で対応する(多が辞書側、1が seg_class, dep_class側)。
品詞が減ります。

文節区切り位置を決める時と、区切った文節毎に候補の並び順を決める時に、コーパスデータベースから確率を得る際には、
・注目文節の seg_class(前の文節が入力の最後尾ならば SEG_TAIL)
・前の文節の seg_class(前の文節が無ければ SEG_HEAD)と注目文節の seg_class(前の文節が入力の最後尾ならば SEG_TAIL)のペア
・注目文節の dep_class
・注目文節の付属語のハッシュ値
・注目文節の mw_features(文節の特徴の有無をビット列にしたもの。頻度値?の分類とか)
・注目文節の ptab.h の各パラメータ
をセットにして求める。文節の順番と連続した文節かどうかは考慮される。
「前の文節が入力の最後尾ならば SEG_TAIL」と言うのは、
ビタビアルゴリズムでの処理時に、入力の最後尾の次に長さ 0 の文節を付加して処理しているから。
ビタビアルゴリズムでは、この付加した長さ 0 の文節を、文節の木構造の根として扱っているらしい(末端葉かも)。
# 「注目文節の seg_class」が2回出てきているが、無駄な気が……?

区切った文節毎に候補の並び順を決める時にコーパスデータベースと一致する候補に加点を行う際には、
・2つ前の文節の自立語のハッシュ値
・1つ前の文節の自立語のハッシュ値
・注目文節の自立語のハッシュ値
・1つ後の文節の自立語のハッシュ値
・2つ後の文節の自立語のハッシュ値
の最大5文節分をセットにし、
変換候補側のセットとコーパスデータベース側のセットで2文節以上一致すれば、一致と判定され、注目文節の該当自立語の総得点が2倍される。
文節の順番や連続した文節か否かは考慮しない。品詞は見ない。

例)
コーパスに「|下の|様な|設定|ファイル|」がある場合の変換候補「|設定|下|」:
確率を得る時は、
「|設定|ファイル|」の部分は「|"名詞+終端"|"名詞+終端"+付属語なし+"終端"+"POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV"|」、
「|設定|下|」の部分は      「|"名詞+終端"|"名詞+終端"+付属語なし+"終端"+"POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP"|」、
で、不一致。それ以外の部分は付属語が一致しないので不一致。
用例を見る時には一致すると判定されて得点2倍。

## 正直、あのコーパスデータベースの生成・読み出しルーチンのコードを正しく解析する自信はありません。


処理の順番は、
1) 変換内容の部分集合の全てに対して、部分集合と一致する辞書上の単語を列挙する。
   複合語は、各文節を全て連結した1単語として処理される。
2) 列挙した単語に対して、変換内容と一致する範囲で付属語を付加した全パターンを列挙する。
3) 複合語を文節毎に分解する。
4) 変換内容に一致する学習を列挙する。
5) 文節区切りを行う(これまでの処理で列挙した単語・文節の組み合わせのうち、評価が最高となる物を検索する)。
6) これまでの処理で列挙した単語・文節のうち、決定した文節区切りに一致しない物を削除する。
7) これまでの処理で列挙した単語・文節のうち、変換結果の字面が同じ物を削除する。
   品詞等の情報は、評価が高い方を残す。
8) 区切った文節毎に、候補の並び順を決める。



本題:

複合語の最後尾以外の文節の品詞は、どうなっているのか:
・付属語を連結する時は、関係無し(付属語を連結しないから)。
・文節区切りの処理時は、
  ビタビアルゴリズム:
    複合語全体の品詞から計算したコーパス上の確率と、
    同等の内容の文節となる alt-cannadic の単語の品詞から計算したコーパス上の確率とで比較して、
    どちらか確率が高い方の品詞を用いる。
  前方n文節最長一致:
    品詞は見ていない。
・各文節の候補一覧の処理時は、
  原作版の場合:
    複合語全体の品詞から計算したコーパス上の確率を単語の得点に掛けた値と、
    同等の内容の文節となる alt-cannadic の単語の品詞から同様に計算した値とで比較して、
    どちらか大きい方の品詞を用いる。
  拙作パッチ版の場合:
    複合語の先頭文節ならば複合語の品詞、
    注目文節よりも左の文節の仮確定内容が複合語と一致する場合は複合語の品詞、
    それ以外ならば同等の内容の文節となる alt-cannadic の単語の品詞、
    を用いる。

例1) 「|油を|売る|」(|あぶらを|うる|)
「油を」も「売る」も両方共、
複合語「あぶらをう #R5 #_4油を_1売」の #R5 およびそれから変換した
「SEG_DOUSHI_SHUTAN 動詞+終端」「DEP_NONE なし」になります。
PRINT_CONTEXT した時の
原作版の場合> あぶらを(油を:(,1000,Ve,6553)2500,001 ,(以下略)
拙作パッチ版> あぶらを(油を:(,1000,Ve,52064,S-,E:0,F:1,LF:0,D:0,L:0,Cl)3,202,643  ,(以下略)
の、「Ve」が SEG_DOUSHI_SHUTAN、「S-」が DEP_NONE の意味。

例2) 「|彼は|油を|売った|」(|かれは|あぶらを|うった|)
「彼は」が「名詞+格助詞」「dep_classは未確認」(原作版)もしくは「名詞+連用」「連用」(alt-depgraph)で alt-cannadic側、
「油を」と「売った」が「動詞+終端」「なし」で compound.t側。

例3) 「|彼は|油を|売っていた|」(|かれは|あぶらを|うっていた|)
「彼は」が「名詞+格助詞」「dep_classは未確認」(原作版)もしくは「名詞+連用」「連用」(alt-depgraph)で alt-cannadic側、
「油を」が、原作版の場合は「名詞+格助詞」(alt-cannadic側)で、alt-depgraph + 拙作パッチ版の場合は「動詞+終端」「なし」(compound.t側)、
「売っていた」が「動詞+終端」「なし」(compound.t側)。

「めにつ #K5 #_2目に_1つ」から「|目に|つく|」に変換したなら、
たぶん「目に」も「つく」も、両方共 #K5 だと思われます。
-----------------------------------------------------------
Thu,08 Oct,2009 追記:
Fri,09 Oct,2009 大きく訂正:
Sat,10 Oct,2009 またもや訂正:
補足:得点の計算方法:

原作版の場合:
        (バイナリ辞書に記録される単語の得点)= {(単語の頻度値を使って単語の順位を求め、最高順位〜最低順位を 99点〜1点に変換する)×100
                                                    −(辞書の元データの1行中で何番目に書かれているか。他の品詞や異なる頻度の物も含む)}÷100
        (単語の得点)=(バイナリ辞書に記録される単語の得点)×8 +(バイナリ辞書の1行中で何番目に書かれているか。先頭が7、8番目以降は0)
        (ビタビアルゴリズムで文節の区切り位置を決める時の、コーパス上の確率)= [1−(陰性の回数)÷{(陽性の回数)+(陰性の回数)}]×(ポワソン分布値)
        (文節の並び順を決める時の、コーパス上の確率)= 0.1 + [(陽性の回数)÷{(陽性の回数)+(陰性の回数)}]^2
        (文節構造の補正点)=(接頭辞と接尾辞のどちらも無ければ1、どちらかでも有れば2)×(depgraphで weak_conn 指定なら10、無指定なら1)
        (文節構造の得点)= 256×256×(コーパス上の確率)÷(文節構造の補正点)
        (文節の総得点)={(接頭辞の単語の得点)÷4+(自立語の単語の得点)+(接尾辞の単語の得点)÷4}×(文節構造の得点)÷256
        (OCHAIRE学習の文節の総得点)= 5000000
        (CAND_HISTORY学習の筆頭候補の文節の総得点)= (文節の総得点)+(仮の第1候補となった文節の総得点)
        (CAND_HISTORY学習の筆頭候補以外の文節の総得点)= (文節の総得点)+(仮の第1候補となった文節の総得点)÷(使用回数、最大8)×(履歴に残る回数、標準設定だと8)
        (複合語の文節の総得点)= (OCHAIRE学習の文節の総得点)÷2
        (用例の加点)= 通常は1、udict の用例に該当すると 10、コーパスの用例に該当すると2。
        (候補の並び順を決める時に使う得点)=(文節の総得点)×(用例の加点)

        # バランスが、用例辞書が適用された時には学習が無視される事がある様になっているが、わざとそうしたのかもしれない?
        # → ml の anthy-dev 126、http://lists.sourceforge.jp/pipermail/anthy-dev/2003-April/000125.html
        # → DIARY の(年不明)4/20 の項目。

        (バイナリ辞書に記録される単語の得点)は、正規化ではない。
        元データの頻度値が同じでも(〜単語の得点)が数点異なる場合や、
        元データの頻度値に 10倍のひらきがあっても(〜単語の得点)が 1点しか違わない場合がある。

        (OCHAIRE学習の文節の総得点)は、単語の得点の約24416(補正一切無しの単語)に相当する。
        (複合語の文節の追加点)は、単語の得点の約12208(補正一切無しの単語)に相当する。
        但し、どちらの場合も、コーパスの確率最大10倍、用例辞書の補正10倍×2倍、が一切無い場合。
        補正が増加方向に最大に効いた単語と比較した場合、122(OCHAIRE)、61(複合語)に相当する。

        (ポワソン分布値)は、20.0 を基準値にした、文節の文字数(ただし、2文字未満は2、6文字以上は6、3文字未満の連体修飾は3、に補正)による、ポワソン分布値。
        コーパスに該当が無い場合の(ビタビアルゴリズムで文節の区切り位置を決める時の、コーパス上の確率)は 4.1e-13 〜 1.8e-10。
        コーパスに該当が有る場合の(ビタビアルゴリズムで文節の区切り位置を決める時の、コーパス上の確率)は 0.0 〜 1.8e-4。
        コーパスに該当が無い場合の(文節の並び順を決める時の、コーパス上の確率)は 0.1。
        コーパスに該当が有る場合の(文節の並び順を決める時の、コーパス上の確率)は 0.1 〜 1.1。
        (文節構造の得点)は、補正無しの文節だと 6553。

拙作パッチの場合:
        (バイナリ辞書に記録される単語の得点)= (単語の頻度値)×100 ÷100
        (コーパス上の確率)と(文節構造の得点)に、confファイルで指定したパラメータを足したり引いたり掛けたり割ったりが追加。
        (追加点の基準値)= 4000000
        (複合語の文節の追加点)= (追加点の基準値)×6÷8 + (追加点の基準値)×1÷8÷5 ×(複合語の文節数)
        (CAND_HISTORY学習の筆頭候補以外の文節の追加点)= 最大で{(追加点の基準値)×3÷8}
        (文節の総得点)=(文節の追加点)+{(接頭辞の単語の得点)÷4+(自立語の単語の得点)+(接尾辞の単語の得点)÷4}×(文節構造の得点)÷256
        (OCHAIRE学習の文節の総得点)= (追加点の基準値)+ (追加点の基準値)×2÷8 ×(OCHAIRE学習を適用する文節数)÷(OCHAIRE学習で覚える最長文節数)
        (CAND_HISTORY学習の筆頭候補の文節の総得点)= (追加点の基準値)×5÷8
        (用例の加点)= 通常は0、udict の用例に該当すると9、コーパスの用例に該当すると1。
        (候補の並び順を決める時に使う得点)= (文節の総得点)+(単語の得点)×(文節構造の得点)×(用例の加点)
        あとは同じ。
        # この辺の追加点の一覧は anthy/splitter.h

        OCHAIRE学習/複合語の追加点は、注目文節より左側の仮変換結果が一致した場合のみ、該当する。

        (OCHAIRE学習の文節の総得点)は、辞書上の頻度値の約22789〜24416(補正一切無しの単語)に相当する。
        (CAND_HISTORY学習の筆頭候補の文節の追加点)は、辞書上の頻度値の約14428(補正一切無しの単語)に相当する。
        (複合語の文節の追加点)は、辞書上の頻度値の約15626〜17000(補正一切無しの単語)に相当する。
        但し、どれも、コーパスの確率最大10倍、用例辞書の補正10倍×2倍、が一切無い場合。
        補正が増加方向に最大に効いた単語と比較した場合、113(OCHAIRE)、72(CAND_HISTORY)、78(複合語)に相当する。
        拙作パッチではさらに conf に記述している各種補正がありますが、計算しきれなくなったので省略。


概算値のまとめ:
原作版    :連文節の学習          :約24416相当(補正一切無しの単語)、約122相当(補正最大の単語)、に変更。
原作版    :単文節の学習          :仮の第1候補となった文節のスコアを丸ごと加算(筆頭候補) 〜 仮の第1候補の約1割(最下位候補)、を加算。
原作版    :複合語                :約12208相当(補正一切無しの単語)、約61相当(補正最大の単語)、に変更。
拙作パッチ:連文節の学習          :約22789〜24416相当(補正一切無しの単語)、約113相当(補正最大の単語)、に変更。
拙作パッチ:単文節の学習の筆頭候補:約14428〜 8656相当(補正一切無しの単語)、約72相当(補正最大の単語)、に変更。
拙作パッチ:単文節の学習のその他  :約7324相当以下(補正一切無しの単語)、約36相当以下(補正最大の単語)、を加算。
拙作パッチ:自立語の学習          :約4882相当以下(補正一切無しの単語)、約24相当以下(補正最大の単語)、を加算。
拙作パッチ:付属語の学習          :約0.05×log(1+利用回数)相当(補正一切無しの単語)、約0.00024×log(1+利用回数)相当以下(補正最大の単語)、を加算。
拙作パッチ:接頭辞・接尾辞の学習  :対立候補の内、学習が適用されていない物の中での最高評価のスコアの最大50%を加算。
拙作パッチ:複合語                :約15626〜17000相当(補正一切無しの単語)、約78相当(補正最大の単語)、を加算。

alt-cannadic の頻度値の最大が 645 でしたので、
たとえ将来的に頻度値の最大値を 1000 まで引き上げても、
コーパス確率10倍までなら複合語や学習の方が強くなる様に設計してあります、
たしか。
-----------------------------------------------------------
コーパスの構造:
# 配布されているバイナリパッケージやソースパッケージからの自動構築の設定にて、
# make update_params が記述されているパッケージと記述されていないパッケージとに別れているが、
# make update_params は必須なのか否か、
# と言う検討結果。

コーパスのデータベースの構造は2種類ある。
・各文節間の遷移の陽性?・陰性?の各回数が記録されている corpus_info。
・例文にて指定された変換結果と
  コーパス情報を使わずに変換した時の第1候補が異なる場合に
  その(この自立語を第1候補として提示したのは誤りとマークされる)自立語が登録される weak_words。

 corpus_info は、文節の遷移確率や自立語(ハッシュ値)の並びを列挙したもので、1行が1文節の情報に相当する。
 trans_info と cand_info が
・注目文節の seg_class(前の文節が入力の最後尾ならば SEG_TAIL)
・前の文節の seg_class(前の文節が無ければ SEG_HEAD)と注目文節の seg_class(前の文節が入力の最後尾ならば SEG_TAIL)のペア
・注目文節の dep_class
・注目文節の付属語のハッシュ値
・注目文節の mw_features(文節の特徴の有無をビット列にしたもの。頻度値?の分類とか)
・注目文節の ptab.h の各パラメータ
を1行1セットで記述した確率情報で、それを1文毎にまとめて木構造(正確には trie)にした集合。
trans_info が文節区切りの時に使う確率で、
cand_info が各文節の変換候補の並び順を決める時に使う確率。
trans_info, cand_info 各々の section行から数えた行数が遷移先番号、
各行の1桁目がその行の有効項目数、
有効項目の最後が遷移先番号、
14桁目が neg(陰性?)の回数、
15番目が pos(陽性?)の回数。
(各セットの文節接続の確率) = 1.0 - neg / (pos + neg)
 corpus_array だったか corpus_bucket だったが、自立語のハッシュ値と遷移先番号の対応表。

 weak_words は、
例文にて指定された変換結果と、コーパス情報を使わずに変換した時の第1候補が異なる場合に、
「コーパス情報を使わずに変換した時の第1候補の自立語のハッシュ値」を列挙したもの。
変換時に自立語のハッシュ値が一致した単語/文節には、
mw_features に FEATURE_WEAK_SEQ が追加される。
それだけ。一致したら減点する、とか言う事は無い。



 従って、
辞書の構成を変更したり、辞書の内容を変更した場合でも
「自立語・付属語・単語の各々のハッシュ値」は変化しないから、
コーパスのデータベース化した物?が完全な出鱈目になってしまうわけでは無いらしい。

 但し、mw_features は変化する場合があり、
特に品詞を修正すると確実に変わり、頻度値を変えても変化する場合があるので、
辞書の構成を変更したり辞書の内容を変更した場合は
コーパスデータベースの質?が下がるかもしれない
(修正が行われた単語のコーパス情報が出鱈目になる可能性がある)。

 また、変換結果の第1候補が変化する様な辞書の構成・内容の変更を行った場合、
本来なら mw_features の FEATURE_WEAK_SEQ が変化するが、
データベースの更新を行わないとコーパスデータベースのバランスが崩れる事になると思う
(出鱈目になる訳では無さそう。
該当の単語で「のすけ氏 - 日記みたいな何か - 2009年 2月21日 (土) - 配流」の問題が
起きやすくなる程度だと思われる)。



 Debian GNU/Linux や Ubuntu GNU/Linux の標準のパッケージの場合や、
FreeBSD や NetBSD でパッケージの環境設定を標準状態から変更して辞書の追加を指定した場合、
辞書の構成の変更(具体的には辞書の追加)を行っているが、
コーパスのデータベースの更新を、たぶんおこなっていない。
これらの辞書の構成の変更が、コーパスデータベースの更新が必須になる様な変更なのか否かは未確認。

 あと、当然ながら、
ハッシュ値が衝突する単語同士(自立語同士および付属語同士)は同じ単語と誤認識されるので、
同じ確率値が使われる。
 確か vagus氏の以前のブログによると1割くらい衝突しているので……、
コーパスをデータベース化する際に誤った情報が1割くらい混入すると共に、
変換する際にも1割くらいは間違ったコーパス情報が使われている可能性がある、
と言う話になる訳で……。
-----------------------------------------------------------

alt-cannadic-090921。
#JS の「営業日」(えいぎょうび)が無かった。
同様に、#JS の 「営業日後」、「営業日毎」、「営業日中」、「営業日付」、 「営業日分」、「営業日程」、「営業日前」、「営業日目」、 「営業日目頃」、 「日目頃」、 も無い。
無いのだけれども……、必要か不要か、人によって大きく別れそうだ。
個人用辞書への登録で構わないかもしれない。


2009年の4に続く。


FENIX HomePage
G-HAL HomePage
Mail to, メールはこちらへ
Suggestion Box, 投書箱
BBS, 掲示板 UserName:BBS、Password:BBS
(C) 2009 G-HAL