基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
昨晩から朝までずっと、電車が終夜運転していたらしい。
BB TwinPack のブルーフロウパート。 事前に、 「普通に考えたらバットエンドに思えるエンディングがベストエンド」 と聞いていたので、心構えはできていたので問題は無かったが。 これ、心構えができていなかったら、かなりへこむ様な……。
工画堂スタジオの lpg画像を PNG画像に変換するツール。
↑ 工画乃郷によると、 エンディングのとあるシーンが２パターンある、 との事だが、 画像データを見る限りでは確かに２パターンあった。 ただ、 例の集合写真イベントを回想するシーンの アップのシーンで、どこを中心にするかが違う （隊長＋カナを中心か、隊長＋マキを中心か） だけで、 次のシーンで、２パターンの両方を含んでいる全体シーン （例の集合写真の全体シーン） になるので、 ２周してまで見る程の物では無し。
↑*3 レベル「凄い難しい」にて、 無損失クリアを正月三が日だけでやるのは、ちょっときつかった。
↑ 「ナイアガラドロップ・セカンド」は普通に敵全滅クリアしたので、 全クリ後に工画乃郷を見るまで、「テルテル イベント」の事を知らなかった。 その「ナイアガラドロップ・セカンド」は、 支援砲撃は、地雷６、空爆３、砲撃１、しか使わなかったし、 しかも空爆１と砲撃１は空振りに近かった （初めて使った支援砲撃なので、タイミングが判らなかった）ので、 「凄い難しい」でも支援無しでクリアできると思う。 ……、よくよく考えたら、今回のプレイで支援砲撃使ったのって、 全ミッション通してここだけだな。
↑ 工画乃郷によると、 この部隊を直轄指揮しているテルル参謀は、中将らしい。 ブルーブラスター辺りで、ようやく階級がはっきりするらしい。
Anthy 拙作パッチのバグ修正、その１。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2008年12月27日 (土) - 干し芋」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 1月1日 (木) - G-HAL氏パッチ」
拙作パッチのバグ指摘。
MBRビタビモードにて、後方一致する学習結果の優先度計算が抜けていた。
Anthy 拙作パッチのバグ修正、その２。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「vagus氏 - 丘の道を登り - 2008年12月31日 - 【お試し版】自作 depgraph」
拙作パッチのバグ指摘。
ソート関数の引数の閾値検査が無い事により、libc の実装によっては落ちる。
qsort() と mergesort() と heapsort()。
↑ GNU/Linux だと qsort() のみ実装されていて mergesort() と heapsort() は実装されていない （そもそも mergesort() と heapsort() は BSD依存で ANSI にも POSIX にも入っていないし、 BSD嫌いがメンテナンスしている GNU glibc に BSD由来の関数が入る事を期待できるわけも無く）。
↑ FreeBSD だと、qsort(), mergesort(), heapsort() どれも、 引数の検査が行われていて、要素数 0 とか突っ込んでも、 きちんと除外処理がされる。
↑ ところが OpenBSD と NetBSD だと、 qsort() と heapsort() は引数の検査が行われているのに、 mergesort() は引数の検査が行われていないので、 要素数 0 とか突っ込むと、 qsort() と heapsort() は除外処理されるのに、 mergesort() だけ SIGSEGV で落ちる。 これはまいった。
↑ OpenBSD と NetBSD のレポジトリを見た感じでは、 その辺は共通のソースから NetBSD と OpenBSD に流布していったらしい。
↑*2 だからと言って、 単純に mergesort() だけ FreeBSD 由来に差し替えてしまえば良いじゃん、 とかやると、 NetBSD とか OpenBSD とか使っている人がまずい事になる （実行時に libc の mergesort() が使われてしまうかもしれない） ので、 それはまずい。
エポック秒を年月日時分秒形式に変換する方法。
BSD系の場合 % date -jr 1234567890 GNU系の場合 % date -d '1970-01-01 UTC 1234567890 seconds' perlの場合 % perl -le 'print scalar localtime 1234567890;' にて、可読形式に変換できる。この場合は 2009年 2月14日 土曜日 08時31分30秒 JST になる。
宅急便。 配送記録を調べてみたら、どうやら、 発送場所 → 集荷所 の間辺りで年を越したっぽい感じ。
電車の中吊り広告の写真の場所を見つけた。 無駄に嬉しい。
鉄道債。 ３年 1.0％らしい。 抽選で商品が当たるらしいが、 抽選なんぞあてにならないからなぁ、と思っていたのだが。 ふと、数えてみた。 ……買付 15口につき１件、当選する勘定になる……、 商品総額から勘定すると、還元率 0.06％くらいだった。
uim のメモリリーク。
uim-xim uim-candwin-gtk uim-toolbar-gtk-systray
確保 消費 確保 消費 確保 消費
起動時 41.6MiB 22.7MiB x x 13.3MiB 8.8MiB
開始時 41.8MiB 22.9MiB 23.5MiB 13.8MiB 見るの忘れた
１回変換時 41.9MiB 24.3MiB 23.7MiB 14.1MiB 見るの忘れた
暫く使った後 42.3MiB 28.6MiB 23.7MiB 14.3MiB 13.5MiB 9.4MiB
さらに暫く使った後 42.5MiB 29.5MiB 23.7MiB 14.3MiB 14.5MiB 9.4MiB
さて、
これは uim の普通のメモリ消費だろうか？、
それとも Anthy の普通のメモリ消費だろうか？、
それとも uim のメモリリークだろうか？、
それとも Anthy のメモリリークだろうか？。
uim-xim は、
uim か Anthy かどちらかでリークしているくさい感じがするのだが。
CoreDuo 1.6GHz とか Core2Duo 1.0GHz クラスの ノートＰＣが９万円弱〜８万円弱。
娘フロ 新品￥3,045- ポイント20％ で２枚、 娘トラ 新品￥3,045- ポイント20％ で３枚、 娘たま 新品￥3,799- ポイント20％ で３枚。 今日だけポイント２倍。
とある量販店。 その系列店専用の商品券での支払にはポイントが付く。 Ｗポイントデーの倍ポイントも割引無く２倍付く。
独立愚連隊シリーズ、全部無くなっていた。 売れたのだろうか？、売れないから奥にしまったのだろうか？。
娘フロ ￥1,824-。 娘トラ ￥1,984-。
Sandisk の SDメモリ、2GB ￥980-。
娘フロ 新品￥3,045- ポイント10％ で１枚、 娘トラ 新品￥3,045- ポイント10％ で４〜５枚くらい、 娘たま 新品￥3,799- ポイント10％ で１〜３枚くらい。
PD1 無し、PD2CV 無し、APD2 無し、 PD3 無し、PD4 無し、 PD5 無し、PD5X 無し、 PD5plusX 無し、 PD6 無し、 PD2CB 無し。 ブルーフロウ 無し、ブルフロ ファンディスク 無し、 ブルーブラスター 無し、ブルブラ ファンディスク 無し、 BB TwinPack 中古￥5,980-。
零金利解除頃から、郵貯の定期性預金残高がずっと減りつづけていたが、 最近はまた増え始めたらしい。
vim。 vim の日本語処理を強化するスクリプト（monday.vim）。 ２年半近く、バグを治さずに使っていたが、ようやく治した。
マクロスＦ ライオン 中古￥580-。
攻殻機動隊１ ￥300-、天・小口・地が日焼け。
FreeBSD 6 で USBマウスが死にまくっていた件、
Sat,24 Feb,2007に発端、
Thu,17 Jan,2008、
Sat,19 Jul,2008、
Mon,18 Aug,2008、
Wed,17 Dec,2008の続き。
Sat,22 Aug,2009に続く。
debug.mpsafenet="0"の件に、もろに該当する事に気付いた。 思い出してみると、 USBマウスや uhub や X がフリーズする時って、 ウェブブラウザで通信に高負荷がかかるか通信がストールするか、 した時だった。 今更……。
Anthy 拙作パッチのバグ修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 1月13日 (火) - 干し芋みたいな何か」
拙作パッチのバグ指摘。
ビタビが１パス処理している為、
「比較対象が違うと評価が変わる文節」が処理できない事の見落とし。
攻殻機動隊２ ￥800- で５冊……。 攻殻機動隊1.5（全部紙の方の通常版） ￥900-。
ソフトバンクの携帯、「緊急値下げ 一括１円」とか出ていた気がする。 先週は無かった。
メモ。 Seagate の件は、2007年頃から発売されたモデルらしい。
uimの拙作改造パッチ。 なんか、ごくまれに、 ステータスウィンドウがどこか出鱈目な場所に吹っ飛んでいる。 再現方法が判らない上に、滅多に発症しないので、原因追究がつらい。
そろそろ確定申告の季節。 還付・損失繰越／控除繰越の申告なら、 １月１日以降の開庁日から手続き出来るけれど。 現実問題として源泉徴収票とかが届くのが１月中旬から下旬になる訳で。
FreePascal の型検査。 オプション -Cr を付けてコンパイルすると、 演算オーバーフロー／アンダーフローで例外を出せるのだが、 この例外のフック方法が判らん。 一般配布するプログラムの場合、 オーバーフロー／アンダーフローの時は、 上限値／下限値を返しながらログか何かに記録しつつ処理は続行、 の方が良い場合も無い訳ではないと思うけれど……、 でもやっぱり設計としては、 オーバーフロー／アンダーフローは落とす方が綺麗なのは確かだと思う。
FreePascal の型検査。 -Cr と -Co の、違いが判らない。 -Ci が何をチェックするのか判らない。
MSの RFC無視なクサレはなんとかならんのか。
娘フロ ￥2,480-、娘トラ ￥2,280-。 大量に高値買取して身動きとれなくなったか？、 それともまだ売れると考えているのか？。
GUNDAM SingleHistory 3 ￥1,550-。
娘フロ ￥1,580- ポイント２％ で店頭在庫５枚くらい。 娘トラ ￥1,980- ポイント２％ で店頭在庫５枚くらい。 娘たま ￥2,980- ポイント２％ で店頭在庫５枚くらい。 １月は木曜日に５％値引き＆ポイント10％セールを行うらしい。 ポイントは、いつも期限切らすから嫌なんだよなぁ。
攻殻１ ￥105-、カバーにキズ等は無いが、中の日焼けと汚れが。
攻殻１ ￥550- で２冊 状態そこそこ良ろし、 攻殻２ ￥800- で３冊 状態そこそこ良ろし、 攻殻２ ￥105- で１冊 カバーの色落ちアリ それ以外は状態そこそこ良ろし、 攻殻1.5 紙 通常版 ￥900- で１冊 状態そこそこ良ろし。
Anthy 拙作パッチのバグ修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 1月25日 (日) - 数字大好き」
拙作パッチのパラメータが不適切な点の指摘。
接頭辞／接尾辞の学習による加点が大き過ぎた。
娘フロ ￥2,250- で４枚くらい。 娘トラ ￥2,250- で４枚くらい。
PD2CB ￥5,480-。 APD2 ￥4,480-で２本。 アマネカ 中古￥3,480-で３本。 PD2CB は800円下げだが、APD2 が700円上げの、アマネカが500円上げ。
PD2CB ￥7,980- で２本。 PD3 ￥1,980？。 PD5 ￥3,980？。 PD5+X は忘れた。 PD6 ￥4,480-。 火星計画ＤＶＤ ￥4,980-。
娘トラ ￥1,750-。
Willcom nico とか言う奴が、 一括払い￥4,800-で２年間基本料無料らしい。
JR と私鉄の両方が入っている駅の場合、 JR の券売機で、その駅から乗車の私鉄の切符を買う事は出来ないらしい。 と言う事で、オレンジカードで私鉄の切符を買うのは、 JRに乗車する時に連絡切符を買うしか手が無いらしい。
途中駅混雑で６分遅れ。
BB TwinPack の BB本編。 Symantec Client Security (Corporate Edition) を有効にしたまま インストールしたら、インストールするだけで 60分かかった。 ディスクを 2.3GB くらい消費した。 BFといいBBといい……。 どうやら、大量の wav ファイルのコピーで時間食っているらしい。 DVD のディレクトリエントリだけでもキャッシュできれば、 結構高速化出来そうな気がするのだが。
娘フロ ￥2,250- で３枚くらい。 娘トラ ￥2,250- で３枚くらい。
娘フロ ￥1,580- ポイント２％ で店頭在庫５枚くらい。 娘トラ ￥1,780- ポイント２％ で店頭在庫５枚くらい。 娘たま ￥2,780- ポイント２％ で店頭在庫５枚くらい。 ２月も木曜日に５％値引き＆ポイント10％セールを行うらしい。
戦士たちの邂逅、 出撃 独立愚連隊、 脱出 独立愚連隊、 激闘 独立愚連隊、 決戦 独立愚連隊、 各１冊づつあって各￥105-、状態良し。 ……あちこちの古本屋に足を運んで、 半年かかってようやく５冊揃えた翌月に、 そう遠くない所でいきなり５冊揃ってしかも美品できますか。
スケベニンゲン。 「スヘフェニンゲン(Scheveningen, 最も近い発音は スヘーファニンゲン)」 (ja.wikipedia.orgより引用)らしい。
ゴールデンハーベストクリームワッフル。 ブルース・リーとかジャッキー・チェンとかが所属していた、 「映画会社を中心としたコングロマリット」 (ja.wikipedia.orgより引用)らしい。
はてなアンテナ。 テキスト化後で、32KiB までしか対応していないらしい。
EUC-JP。 C言語で文字列を処理する際に、文字列を char型配列に入れて、 0x8E, 0x8F, 0xA1〜0xFE で EUC-JP 判定していたら、判定を間違える。 char型だと、普通、有符号なので、EUC-JP は負になってしまうのね。 unsigned char型配列でないと駄目。
↑ ちなみに Pascal の String だと、 そのままで、0x8E, 0x8F, 0xA1〜0xFE で EUC-JP 判定しても問題無し。
工画堂の PD1 のリニューアル？版。 ソフ：￥7,980- ポイント798。 ビック：￥8,580- ポイント858。 ヨド：￥8,580- ポイント858。
BB TwinPack の ブルーブラスター パートの マンジ。 バグに当たった。 味方増援部隊が出現せず、ミチル単機のまま、敵全滅を遂行する羽目に。 結局、 「難易度とても難しい」＋「リセット技あり」 ＋「FtF 使わず」＋「支援無し」＋「修理施設は使う」＋「弾薬庫は使う」 にて、 ミチル単機で 86機撃破でクリア。 修理・補給は４回。 ただ、このマップ構成と敵アルゴリズム、もしかしたら、 わざと単機クリアが可能に作ってあるのかも。 もう一度やれと言われれば、面倒だけれども、リセット技ありなら、 難易度とても難しいでも FtF 使わずにできると思う。 修理無しはさすがに無理だが。
RATS (Rough Auditing Tool for Security) とか、
Flawfinder とか言う、
コードレビューツールがあるらしい。
lint。
GUNDAM SingleHistory 1,2,3, Ending Collection 各￥1,950〜2,250-。
バトルテックリプレイ１魔女たちの饗宴 は無くなっていた。
攻殻機動隊 1.5 紙の通常版￥250-。 攻殻機動隊 1 ￥105-。
結局、BB TwinPack の ブルーブラスター パートは、 難易度 とても難しい にて、支援と FtF を一切使わずにクリア。 ブルーフロウ パートよりも、明らかに難易度低いと思う。 時間制限のある面の場合でも、 倉庫２つ奪った上で（但し、全ての面で HMT を最低１機出した）、 制限時間の 1/3 くらい残してクリアできたし。 ただ、半リアルタイム制である事と操作性を考えると、 快適にプレイできるバランスかも。
唐突な思い付きで、RSS 1.0 を書いてみた。
RSS を書いた途端、 "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)" とか言うのが、３時間毎に回って来る様になった。 多すぎ。 Thu,26 Feb,2009に続く。
Linux（GNU/Linux ではない方）。 TOMOYO が Linux にマージらしい。 と言う事は、セキュアがらみの Linux カーネル派閥抗争は、 SELinux原理主義派が折れたと言う事か？。
あれ、hackaholic が消えた？。
バトルテックリプレイ１魔女たちの饗宴 ￥105-、 裏表紙にわずかな汚れ、カラーページに汚れ少々。
BB TwinPack の ブルーブラスター パートの エルザスパスィート。 バグに当たった。 出現機体は合っているのだが、 マップとイベントと出現位置が最初のチュートリアルマップになっている。
PD1 無し、PD2CV 無し、APD2 無し、 PD3 無し、PD4 無し、 PD5 無し、PD5X 無し、 PD5plusX 無し、 PD6 無し、 PD2CB 無し。 ブルーフロウ 無し、ブルフロ ファンディスク 無し、 ブルーブラスター 無し、ブルブラ ファンディスク 無し、 BB TwinPack 中古￥5,980-。 アマネカ 中古￥2,980-で２〜３本。
出撃 独立愚連隊、 脱出 独立愚連隊、 各１冊づつあって各￥105-。
戦士たちの邂逅、 出撃 独立愚連隊、 脱出 独立愚連隊、 激闘 独立愚連隊、 決戦 独立愚連隊、 各１冊づつあって各￥105-、状態良し。 バトルテックリプレイ１魔女たちの饗宴 ￥105-、 バトルテックリプレイ２女神たちの彷徨 ￥105-、 共にカバー若干痛みとカスレとわずかに色褪せ、ページ折れ。
BB TwinPack の ブルーブラスター パート。 バグでは無くて仕様です。 今までずっと、オートプレイと既読早送りが使えなかったのだが。 ようやく原因に気付いた。 管理者権限で NTFS なディスクにインストールして一般ユーザで実行すると、 メッセージの既読フラグが保存できずに、既読早送りが使えなくなる。 ScData/*.em を一般ユーザにも書き込み可能にしてやれば、 既読早送りが使える様になった。 ところで、MS-Windows XP の場合、再起動してセーフモードにしないと、 一般ユーザへの書き込み許可を設定できないクサレ仕様を何とかして下さい。
BB TwinPack の ブルーブラスター パート。 工画乃郷によると、 「マキ編」クリア後は、 各キャラのエンディング後に声優のコメントが付くらしいが、 付いていなかった。 全キャラクリア後の間違いか？。 同じく、工画乃郷によると、 「マキ編」のイ何とかミッション後の選択で……、 と言う記事があるが、選択その物が無かった。
OpenBSD 4.4。 以前に mergesort() の実装が甘かった件に当たったが、 今度は user_from_uid(), user_from_gid() の 実装が甘い気がするのを見つけた。 該当名称無しで数字の文字列で返す際に、 返り値が static char nbuf[15]; で返されているが、 その事が man に書いていない。 なので、
const char* user1 = user_from_uid( uid1, 0 );
const char* user2 = user_from_uid( uid2, 0 );
とかやると、user1 が壊れる。
FreeBSD 6.x-RELEASE は、
uid別に static char [] だったので、
問題無かった。
thomas仙人、FEZ師匠によると、
OpenBSD の SMPの lock回りも、
なんかちょっと、な感じらしい。
OpenBSD は、こだわっている部分は良いけれども、
そうでない部分は、なんか抜けているのだよなぁ……。
OpenBSD 4.4 の getpwent()。 バグらしき所を見つけた。どうしたらいいのだろう。
lib/libc/gen/getpwent.c:641行目と665行目、__yppwlookup() 関数内の
r = yp_match(__ypdomain, map,
user, strlen(user),
&ypcurrent, &ypcurrentlen);
は
r = yp_match(__ypdomain, (PASSWD_BYNAME),
user, strlen(user),
&ypcurrent, &ypcurrentlen);
の間違いだと思う。
OpenBSD 4.2 では (PASSWD_BYNAME) になっていた。
cvs を見た感じだと、
OpenBSD 4.3 の後の、
getpwent.c Revision 1.35 にて、
重複したコードをまとめた際に、間違えたのだと思う。
某 THM氏への伝言、と言っても、ここ見ていないだろうけれど。
ネタ元は今月号の SoftwareDesign。
LEGO Mindstorms RCX Programmable Brick (Programmable Bricks) の話。
タートルグラフィックス(Logo) の考え（教育用らしい）を受け継いでいる物に、
Squeak eToys（マスコットキャラクターは鼠）とか、
Squeak eToys の途中バージョンからブランチって分派を作った
Scratch（マスコットキャラクターは猫）とか言う物があるらしい。
↑ ……、Squeak Etoys のスクリーンショットは、何かデジャブが……。 もしかして、以前にも同じ話を振った？。
ここ数年、 ArtDink の地球防衛軍シリーズとか HR2 とか 鴨葱 CarnageHeart シリーズとか、 そっち系の話をぜんぜん聞かない気がする。
Anthy 拙作パッチの修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「vagus氏 - 丘の道を登り - 2009年02月04日 - 【お試し版】 自作 depgraph 更新 - alt-depgraph-090203.tar.bz2」
カタカナ語の評価順位に関する見解を参考にしました。
Anthy の yomi hash の collisions の話、
実際に作業したのは Fri,30 Jan,2009〜Sat,31 Jan,2009頃なのだけれども。
ネタ元は
「vagus氏 - 丘の道を登り - 2009年01月31日 - anthy-9100g - yomi hash の collision」。
9100e: Total 409234 indexes, 583089 words, (6395 pages). generated yomi hash bitmap (37509 collisions/409234 entries) 9100h ＋ １件修正: Total 436453 indexes, 607319 words, (6820 pages). generated yomi hash bitmap (42389 collisions/436453 entries)ちなみに、hash を、 md2(128bit) とか md4(128bit) とか md5(128bit) とか ripemd(160bit) とか sha1(160bit) とか sha256(256bit) とかにして 下位 32bit だけ取り出して使ってみたら、 遅くなった上にコリジョンが増えた。
原作版通り: generated yomi hash bitmap (42388 collisions/436451 entries) SHA256: generated yomi hash bitmap (42423 collisions/436451 entries) SHA1: generated yomi hash bitmap (42448 collisions/436451 entries) SHA0: generated yomi hash bitmap (42606 collisions/436451 entries) RIPEMD160: generated yomi hash bitmap (42621 collisions/436451 entries) MD5: generated yomi hash bitmap (42486 collisions/436451 entries) MD4: generated yomi hash bitmap (42486 collisions/436451 entries) MD2: generated yomi hash bitmap (42535 collisions/436451 entries) CRC32(OpenSSH): generated yomi hash bitmap (42713 collisions/436451 entries) UCS-2化してCRC32(OpenSSH): generated yomi hash bitmap (42201 collisions/436451 entries) elfhash?: generated yomi hash bitmap (316061 collisions/436451 entries) UCS-2化してelfhash?: generated yomi hash bitmap (17???? collisions/436451 entries) Tue,20 Oct,2009 追記： 原作版通り: generated yomi hash bitmap (45005 collisions/449923 entries) 37倍な生成多項式: generated yomi hash bitmap (49113 collisions/449923 entries) 131071倍な生成多項式: generated yomi hash bitmap (235021 collisions/449923 entries) 24919倍な生成多項式: generated yomi hash bitmap (44984 collisions/449923 entries) CRC32-IEEE802.3 generated yomi hash bitmap (44691 collisions/449923 entries) CRC32C generated yomi hash bitmap (44628 collisions/449923 entries) CRC32K generated yomi hash bitmap (44838 collisions/449923 entries)むぅ。
↑ 実際には、求めた hash のさらに下位21bit しか使っていなかった。
それでも 2097152 になるから……。
えーと、
ハッシュテーブルの８割は空きなのに、エントリの１割がコリジョン？。
ハッシュテーブルのダンプを目視で見ても、確かに空きが多い……。
誕生日のパラドックス恐るべし。
↑*2 エントリ数が２件ずれてる……何で？。
↑*3 Sat,21 Feb,2009 追記：
CRC32(OpenSSH), elfhash? 追加。
コリジョン率に関して、
「2^n 個のキーに関して，衝突の可能性を 1/(2^m) 程度に抑えたいならば，2(n+m) ビットのハッシュ値を用いる必要があります。」、
Radium Software Development、
と言う記事を見つけた（真偽は不明）。
エントリ数は 19bit、ハッシュは 21bit なので、
……、
あれ？。
↑*4 Sun,22 Feb,2009 追記：
web でざっと検索した所によると、
ハッシュテーブルの使用率は、５割〜７〜８割くらいが丁度良いらしい（真偽は不明）。
となると、ハッシュテーブルの大きさを更に半分にできる勘定になるが……。
原作版通りのハッシュアルゴリズムにて: ハッシュテーブルサイズ ハッシュ衝突率 ハッシュテーブル使用効率 23bit: generated yomi hash bitmap (11161 collisions/436451 entries) 2.6％ 5％ 22bit: generated yomi hash bitmap (21837 collisions/436451 entries) 5.0％ 10％ 21bit: generated yomi hash bitmap (42388 collisions/436451 entries) 9.7％ 19％ 20bit: generated yomi hash bitmap (79659 collisions/436451 entries) 18.3％ 34％ 19bit: generated yomi hash bitmap (140177 collisions/436451 entries) 32.1％ 56％ 18bit: generated yomi hash bitmap (223685 collisions/436451 entries) 51.3％ 81％……、結局どの辺が良いのかは判らん。
C/C++ の sizeof()。
詳細は
「noocyte のプログラミング研究室 〜プログラムは楽しげに走らねばならない♪〜」
の
「データ型のアラインメントとは何か，なぜ必要なのか？」
を参照。
もちろん、sizeof(int) が 4 固定である事を前提にするなど問題外。
sizeof(int) が 2 な処理系や、
2 なのに 14bit とかいう処理系（厳密には C/C++ の規格に違反らしい）、
まで存在する。
……、なのだけれども、
例えば最近いじったソースだと、
Anthy は 4 固定（あるいは 4 か 8 どちらか固定？）を
前提にコーディングされていた。
概して。
MS-Windows2000 以降の MS-Windows系の人が書いたソースは
ほぼ確実に 4 固定前提になっているし、
GNU/Linux 系の人が書いたソースは 4 固定前提が特に多い。
Solaris系とか NetBSD の人が大丈夫なのは、
アーキテクチャがらみの問題なのか、
不人気だから（流行じゃないから）コアな人しか残っていないからなのか。
本題はそれじゃなくて。
"1 <= sizeof(uint8_t)" である事は保証されるが、
"1 == sizeof(uint8_t)" は保証されていない。
"2 <= sizeof(uint16_t)" である事は保証されるが、
"2 == sizeof(uint16_t)" は保証されていない。
例えば、
struct HOGE {
uint8_t foo;
uint32_t bar;
};
にて sizeof(HOGE) が 5 とは限らない事を考えれば、
行き着くかもしれない結論だけれど。↑ Anthy パッチのテストコード、
よくよく考えたら、エンディアンも変換しないとまずいわ……。
テストコードだからいいや……。
ハッシュ。 CRC16 とか CRC32 のオープンソースなライブラリが見つからない。 昔、MS-DOS で自作した奴も見つからない…… あれは 80186 のアセンブリだから駄目か。 ……。 OpenSSH の crc32.c が手っ取り早そうだ。 elfhash とか言う物もあるらしい。
バトルテックリプレイ２女神たちの彷徨 ￥105-、 メックウォーリアーＲＰＧリプレイ１ ￥105。 ともに小口に若干シミ有り。
バトルテックリプレイ１魔女たちの饗宴 ￥105-、 メックウォーリアーＲＰＧリプレイ２ ￥350-、 メックウォーリアーＲＰＧリプレイ３ ￥350-、 メックウォーリアーＲＰＧリプレイ４ ￥350-、 バトルテックがよくわかる本 ￥350-。 バトテリプレイはカバーとカラーページに汚れ少々。 メックリプレイはカバーあちこちにキズ。
↑*2,*1 で。 今まで全然見かけなかったのに、 最近になって唐突にあちこちでちらほら見かける様になったのは 何故なのだろう？。
COLEZO! マクロス ソングセレクション ￥1,550-。 でも新品￥2,000-らしい。 で、他の COLEZO シリーズが中古で￥2,180- で売っていたのだが……、 中古なのに新品定価より高いんですか。
娘フロ 中古通販で￥1,160〜1,300- らしい。 娘トラ 中古通販で￥1,570〜1,880- らしい。 娘たま 中古通販で￥3,100〜3,380- らしい。
BB TwinPack の ブルーブラスター パート。
チェックバック → 原語だと、動詞の「再確認」くらいの意味らしいが。 →→ Check back. で「再確認しろ」、Please check back later. で「後ほど御確認下さい」 →→ くらいの意味らしい。 ジーンマップ → Gene Map ほしのひかりにせいほうへんいをみつけちゃったらう ちうがちじまってきてたいへんなことになるずらよ？ → 漢字で書けば、意味はすぐに判る……そっち系好きな人なら。 → 「星の光に青方偏移を見つけちゃったら宇宙が縮まってきて大変な事になるずらよ？」 → 「ちじまって」は、正しくは「ちぢまって」だと思うが。 てんぷら、氷水で衣 → レシピ関連で web で検索してみると。賛否両論あるらしい。 重畳 → 技術系の書類によく出てくる単語で意味は知っているがだが読めなかったり。 → 「ちょうじょう」……、どの場面で出てきたか忘れた。 ギリアム → VF-X2 ネタなわけは無いと思うが、思わず「ギリアムー（泣」シーンを連想してしまう。 牛刀皮肉（リンリン語シンシン語）、羊頭狗肉（ようとうくにく） シャーリー・マクラクラン → 工画乃郷だと「シャーリー・マクマクラン」になっているが。 工画乃郷だと「マキクリア後に声優トーク」とあるが「全パターンクリア後」の間違い。 共通エンドを含むか否かは不明。 攻略ルートにのっていると聞けない会話： ２−５町に出る前：非エルザルートにてエルザに質問 ３−２看病：非アッシュルートにてアッシュ ３−８ディカイオシュネ前の戦う理由：非アッシュルートにてアッシュ ３−８ディカイオシュネ前の戦う理由：非マキルートにてマキ 全クリア後の共通エンド（広報部隊、惑星連合、共に）：ミチル役声優トーク 真ん中突っ込んで全部壊して戻ってくる。 → ……、大部分は、普通にそれでクリアできます。
SSD の寿命。 http://akiba-pc.watch.impress.co.jp/blog/archives/2009/02/ssd_3mtron_msds.html 「SSD耐久テスト経過報告 その3」 によると、最近の奴は結構丈夫らしい。 ７〜８年？くらい前から職場で使っていた奴なんぞ、 atime 付きの ext2（デフォルト設定で atime 有効）で使っていると 半年〜１年で壊れていたものだが。 noatime,ro 指定で使った方が良い、と言っているのに、 無視して rw（デフォルトで atime が付いている）で使って、 壊す度に（以下略）。 先月頃にも、また壊したとかで買い直していたが……。 平均すると２年で３台のペースで壊して買い直ししていると思う。
USB A-miniB ￥105- で３本。
COLEZO! マクロス ソングセレクション ￥1,550-。
銀河英雄伝説のサントラ１〜４？ 各￥1,250-。 ……、どうも、第２期サントラ音楽集１〜４、らしい。 第１期〜第４期のうち、第２期分しか収録していないっぽい。
脱出 独立愚連隊 ￥105-、 決戦 独立愚連隊 ￥105-。 メックウォーリアーＲＰＧリプレイ２ ￥105-、 メックウォーリアーＲＰＧリプレイ４ ￥105-。 どれもかなり良好な状態。これは私に買えと？。
そして電車に乗り間違えて電車賃を￥300-余計に払う羽目に。 寄道して安く入手した意味無し。
Anthy 拙作パッチのトラブル修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 2月21日 (土) - 配流」
・たまに変な候補が出る件。
Anthy は、システム辞書(anthy.wdic)上の単語得点（頻度値？）が
ソースコード上で定義されている HF_THRESH より大きいか否かで、
単語？付属語？のコーパス検索のハッシュ値を変えている。
が、しかし、
拙作パッチ patch12ptn12 にて単語の得点（頻度値？）の計算方法を変えた
（原作：頻度値の序列、
但し頻度値が同じ場合はランダム(qsort)に順位を決定。
拙作：頻度値をそのまま。）為、
HF_THRESH の値がシステム辞書の値と釣り合わなくなっていたらしい。
原作の HF_THRESH値 784（上位から 63％くらい）だと、
だいたい頻度値 300 くらいだった。
→ 参考
頻度値をそう言う風に変換されると、
システム辞書の頻度値の調節がしにくくなる。
「vagus氏 - 丘の道を登り - 2007年11月21日 - 【実験】hogedic - その１(追記)」
「vagus氏 - 丘の道を登り - 2007年11月22日 - 【実験】hogedic - 寄り道」
→ 備考
マジックナンバー 784 の由来は不明。
Anthy のコーパス検索は、
ハッシュ値のみで一致／不一致の判定を行っている。
従って、違う文字列でもハッシュ値が同じならば、
同じ文字列として処理される。
→ 既知の問題
システム辞書の頻度値の割り当て方を大きく変えると、
また同じ問題が出る。
メジャーな単語とマイナーな単語の頻度値の境界を、
300（300以下はマイナーな単語、301以上はメジャーな単語）にすれば、
たぶん大丈夫ではないかと。
取り敢えずコーパスを無効にすれば、問題は出ないものの……。
・数字が強めに出る件
→ 原因
「せん」→「千」、「ぜん」→「千」と自立語学習したけれども、
「ぜんたい」「ぜんぶ」「せんしゅう」「せんけい」などは
文節学習していない場合、
取り敢えず自立語学習してある
「せん」→「千」、「ぜん」→「千」を含む
「千体」「千部」「千周」「千京」を優先してしまう。
→ 対策
接頭辞か接尾辞が付いていたら、
自立語学習を反映しない様にしてみた。
cf. CANDIDATE_DISABLE_INDEPSCORE_WITH_PREFIX_OR_POSTFIX
Anthy 拙作パッチのトラブル修正、その１。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 2月22日 (日) - ほぼぜんぶ」
・「ほぼぜんぶ」が「ほぼ|全部」にならずに「ほぼ千部」になる。
類似）
「しゅうろくたんご」が
「収録|単語」にならずに
「週六単語」になる。（Sun,23 Nov,2008 に受信したメール）
結論だけ言うと仕様。
現行の Anthy（原作版、ビタビ、ｎ文節最長一致、全て）の
文節区切りのアルゴリズムでは、
文節数が少ない物を優先する様になっている。
「ほぼ|全部」や「収録|単語」は２文節だが、
「（接頭辞）ほぼ + （数詞）千 + （接尾辞）部」や
「（接頭辞）週 + （数詞）六 + （接尾辞）単語」は１文節なので、
「ほぼ千部」や「週六単語」が優先される。
対処法は、
・学習する。
・コーパスに追加する（効くかどうかは未確認）。
・オプション MAXLEN_MODE_PHRASE_WITH_PRE_POST_AS_2 を使う（ｎ文節最長一致のみ）。
いずれか。
Anthy 拙作パッチのバグ修正、その２。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 2月24日 (火) - ほぼぜんぶ」
・「干し芋のが」問題再燃
単純に、
anthy-9100.patch13.2009105 および
anthy-9100.patch13ptn13.2009113 での
「干し芋のが」問題修正時の修正漏れ。
＃ 今まで発症条件が揃った事が無かった為、気付かなかった。
＃ ビタビは枝刈り絡みの都合で、
入力した内容に依って動作状況が激しく変わるので、
追跡や動作確認がつらい。
Makefile。
BSD make と GNU make で、条件分岐の書き方が違うのだが、
何とか共通の Makefile にできないものか。
取り敢えず、条件分岐を Bourne shell script で書いてしまえば解決か。
Google の rss のクローラー、 Tue,10 Feb,2009の続き。 今まで３時間に１回、回って来ていたのが、 20時間に１回になっていた。 sy:updatePeriod, sy:updateFrequency の項目が反映され始めたのかな？。
↑ と思ったら、また３時間に１回来ていた。 単なるメンテか何かか。 Mon,02 Mar,2009に続く。
スウェーデンのサーブ。 以前は巨大企業だったサーブは部門毎に分割売却していて、 今回破綻処理？したのは以前のサーブの自動車部門であって、 航空機部門では無いらしい。
mplayer の GTKフロントエンド gmplayer on FreeBSD/i386|amd64 6.4-RELEASE。 暫く前から、 UI無しの素の mplayer なら動くのに、 GUI の gmplayer が動かなくなっていた。 web で検索したらあっさり見つかって、 gui/wm/ws.c パッチ当ててサクっと解決。 XSync() が１発抜けていただけという……。
Anthy 拙作パッチの修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「vagus氏の発言 - nosuke(のすけ)氏のサイト - 日記みたいな何か - 2009年 2月24日 (火) - ほぼぜんぶ」
・「ほぼぜんぶ」が「ほぼ|全部」にならずに「ほぼ千部」になる。
現状の Anthy の、辞書、adjust.t、コーパスではお手上げだそうなので、
無理矢理ゴリ押しでプログラムに実装してみた。
VITERBI_MODE_DECREASE_PROBABILITY_PHRASE_WITH_PRE_POST
VITERBI_MODE_DECREASE_PROBABILITY_PHRASE_WITH_PRE_AND_POST
VITERBI_MODE_DECREASE_PROBABILITY_PHRASE_WITH_PRE
VITERBI_MODE_DECREASE_PROBABILITY_PHRASE_WITH_POST
の辺り。
１文節分の確率は、
4.1e-7（１〜２文字）
2.7e-6（３文字）
1.4e-5（４文字）
5.5e-5（５文字）
1.8e-4（６文字以上）
で、２文節だとこの２乗、３文節だと３乗。
ｎ文節最長一致と異なり、ビタビは確率処理を行う都合で、
挙動の予想が付かないので、
本オプションの使用で、何が何処へ飛んでいくかは不明。
２月再販版 1/144 VF-19改 ￥710くらい。25％引きらしい。 ２月再販版 1/100 VF-1J ￥1100くらい。
娘フロ ￥1,580- で３枚、 娘フロ（盤面にキズ）￥1,580- から２割引で１枚、 娘トラ ￥1,580- で４枚、 娘たま ￥2,780-。
娘フロ ￥2,250- で３枚くらい。 娘トラ ￥2,250- で３枚くらい。
出撃 独立愚連隊 ￥105-、 脱出 独立愚連隊 ￥105- で２冊。
戦士たちの邂逅、 出撃 独立愚連隊、 脱出 独立愚連隊、 激闘 独立愚連隊、 決戦 独立愚連隊、 各１冊づつあって各￥105-、状態良し。 バトルテックリプレイ１魔女たちの饗宴 ￥105-、 バトルテックリプレイ２女神たちの彷徨 ￥105-、 共にカバー若干痛みとカスレとわずかに色褪せ、ページ折れ。 メックウォーリアーＲＰＧリプレイ２ ￥105-、 メックウォーリアーＲＰＧリプレイ３ ￥105-、 共にカバー裏表紙が若干痛み。 ……増えてる……。
１週間くらい前に書き忘れた話。 distributed.net OGR-26 終了していたらしい。 ２月分よりも前の演算結果が全部消滅しているのは何故だろう？。
OpenBSD。 shutdown -p -h now しても、 コールドリブートになってしまう……、 何で？、困った。
OpenBSD。 OpenBSD版 m4 と GNU automake/autoconf は、仲が悪いらしい。 なので、 OpenBSD だと GNU automake がまともに走らない。 しかも、 GNU側は「OpenBSD が悪い」の一点張りだし、 OpenBSD側は放置だし（コア部分ではなく ports だからなのだろうか？）。 困った……。
OpenBSD、何だかんだ言って、 開発のコア部分（有名な所で OpenSSH）は最強なのに、 周辺は弱すぎ……。
GearHead。 駄目だ、先週からぼちぼちやっていた方式の処置だと、うまくない。 やり直しか？。
そして本題を忘れた。
distributed.net OGR-27 正式開始していたらしい。 でも FreeBSD の ports には、まだ来ていない。 ……それどころか、distributed.net の本家にすら存在していないのか。 未だ prerelease で、テスターによる試験中らしい。
Thundierbird 2.0.0.19。 2.0.0.18 からの ports 更新に、 ディスクを 510MB くらい消費した。 そしてまたディスクフルを出した。
Google の rss のクローラー、 Thu,26 Feb,2009の続き。 10時間弱くらい来ていなかったのに、また３時間毎に来ていた。 もしかして、 sy:updatePeriod, sy:updateFrequency 指定で 更新が想定される日にち帯は３時間毎、 そうでない場合は来ない、 とかだろうか。
そして本題を忘れたまま思い出せない。
本題１。 ３月になった途端、 銀行の定期預金金利が１〜３割くらい下がった気がする。 気がするだけ。 確認してみたら、そんなでもなかった。
本題２。 １年だったか半年だったかくらい前から、 サーバの DNS に、大量と言う程でも無いけれど、 多くの query を投げ付けて来るアタック？が来ている。 NS . のクエリを延々と。 数日〜数週間毎にアタック元が変わっていて、 最近は 62.109.4.89 （ロシア）から来ている。 頻度は毎分 40回くらいで、それが 24時間ずっと続く。 正常な query でも、 数秒程度の間ではその位の頻度になる事は有るので、 頻度ベースのフィルタは、かけにくい。 DoS にしては頻度が少ないし、狙う理由が判らないし。 目的が判らん。ポイゾニング狙い？。
↑ ぼけていた。 送出元の 62.109.4.89 が偽造な DDoS かも。 しまった、REFUSED なレスポンス返しちゃってる、まずい。 （さすがに root のヒントを返すのは、私が担当を押し付けられた時にとめた）
↑ snort2pf みたいに、 ログを監視して pf の table に突っ込むしか、方法が無さそう。
↑*2 http://www.bsddiary.net/d/200901.html#28 「パケットドロップするのはデメリットの割りには大したメリットもないんで、 refuse 返した方がいいんでね?」 らしい。
↑*3 DNS の bind(named) で REFUSED を返信しない様にする改造パッチ。
↑*4 Sat,07 Mar,2009 の 03:15頃に、とまっていた。
↑*4 Wed,11 Mar,2009 の 06:45頃に、 正引き専用 DNS サーバに、 64.34.179.92 から逆引きの query が来ていた。 こちらの DNS の構成上、 この IP で DNS が動いているのを知らないと、 逆引きは来ない筈なのだけれど。 関係が有るのか無いのかは不明。
本題３。 １〜２ヶ月くらい前の話。 回りで 「クレジットカードが年会費取る様になったから、乗り換える」 とか 「引っ越して、鉄道系の電子マネー付きクレジットカードがあると 便利な状況になった」 とかで、 新たに鉄道系のクレジットカードを作る人が数人いるので、 なんとなく調べてみた（１ヶ月くらい前の過去形）。 50Hz圏だと、 ビックカメラ Suica（JR東で定期を買う、 もしくは定期を買う私鉄が他社クレジットＯＫの場合）、 ToMeCARD UC（営団で定期を買う場合）、 あたりが、 万人向けに手軽で無難でそこそこお得、らしい。 年会費とかポイントの有効期限／活用方法とかを考えなくて良い、 と言う意味で。
50Hz圏 Suica/PASMO クレジットカード まとめ
種別 年会費／維持費 実質換金した時の ポイント制度 ポイント有効期限 ポイントの実質換金 旅行保険
還元率
ビックカメラSuica JCB Suica一体(本体) 年１利用で無料 海外：自動（他社より保険範囲が狭い）、国内：利用
1.0％ クレジット 100円毎に１ビック 最終利用から２年 Suicaにチャージ（1000ポイント毎に1000円チャージ）
0.0〜1.5％ チャージ 1000円毎に６VIEWサンクス 獲得の翌年度末 Suicaにチャージ（400ポイント毎に1000円チャージ）
Yahoo JAPAN Suica VISA/Master Suica一体Type2 年10万以上で無料 0.0〜1.0% 100円毎１ポイント 最終獲得から１年 Suicaにチャージ（1000ポイント毎に1000円） 海外：自動（他社より保険範囲が狭い）、国内：利用付帯
ビックカメラSuica JCB Suica一体(本体) 年１利用で無料 海外：自動（他社より保険範囲が狭い）、国内：利用付帯
0.33％(0.455%) クレジット 200円毎に１ビック 最終利用から２年 Suicaにチャージ（1500ポイント毎に1000円チャージ）（ビックにて1ポイント1円の買物）
0.0〜0.5％ クレジット 1000円毎で２VIEWサンクス 獲得の翌年度末 Suicaにチャージ（400ポイント毎に1000円チャージ）
0.0〜1.5％ チャージ 1000円毎で６VIEWサンクス
ToMeCARD UC VISA/Master PASMO一体/分離 永年無料 0.5％ 1000円毎１ポイント 無期限（他UC合算可？） PASMOにチャージ（200ポイント毎に1000円） なし
みずほ《セゾン》Suica VISA Suica一体Type2 永年無料 0.5％ 1000円毎１〜２ポイント 無期限（他セゾン合算不可） Suicaにチャージ（200ポイント毎に1000円） なし
西武プリンス(セゾン) VISA/Master/JCB PASMO分離 永年無料 ×(0.5%) 1000円毎１ポイント 無期限（他セゾン合算可） ×（1000ポイント毎に5000円相当の各種金券） なし
ToMeCARD NICOS VISA/Master PASMO一体/分離 永年無料 0.0〜0.5％ 1000円毎１ポイント 獲得の翌年度末（他NICOS合算可） PASMOにチャージ（200ポイント毎に1000円） なし
ToMeCARD JCB JCB PASMO一体/分離 永年無料 0.0〜0.5％ 1000円毎１ポイント 獲得から２年？（他JCB合算可？） PASMOにチャージ（200ポイント毎に1000円） なし
三菱東京UFJ Suica VISA Suica一体Type2 永年無料 0.0〜0.5％ 1000円毎１ポイント 獲得年度末（合算不可） 現金還元（200ポイント毎に1000円） 海外：利用付帯
Pastown SMBC VISA/Master PASMO分離 永年無料 0.0〜0.3(〜0.5%) 1000円毎１ポイント 獲得から２年（他smbc合算可） 支払金額に充当（200ポイント毎に600円充当） 海外：利用付帯
Pastown JCB 親子型 JCB PASMO分離 永年無料 ×(0.0〜0.5%) 1000円毎１ポイント 獲得から２年（他JCB合算可） ×（200ポイント毎に1000円相当のポイント交換） なし
Pastown UFJ VISA/Master PASMO分離 永年無料 ×(0.0〜0.5%) 1000円毎１ポイント 獲得の１年後以降の10月末日 ×（200ポイント毎に1000円相当のポイント交換） なし
イオンSuica VISA/Master/JCB Suica一体Type2 永年無料 0.0〜0.50％ クレジット 200円毎１ポイント 獲得の翌年度末（他VIEW合算不可）Suicaにチャージ（1000ポイント毎に1000円） 海外：自動、国内：利用付帯
0.0〜0.25％ チャージ 400円毎１ポイント（クレジットと合算）
東急 TOP CARD 一般 VISA/Master PASMO分離 永年無料 0.0〜0.2％ 500円毎１ポイント 獲得の２年後の年度末 PASMOにチャージ（1000ポイント毎に1000円） 海外：自動
三菱東京UFJ TOP PASMO VISA PASMO一体 永年無料 0.0〜0.2％ 500円毎１ポイント 獲得の２年後の年度末 PASMOにチャージ（1000ポイント毎に1000円） 海外：利用付帯
京急 UC VISA/Master PASMO一体 永年無料 ×(0.0〜0.5%) 200円毎１ポイント 獲得から１年（他UC合算不可） ×（京急系列店のみ使用可、500ポイント毎に500円相当？） なし
京成 VISA/Master PASMO分離 永年無料 ×(0.0〜0.5%) 1000円毎５〜３ポイント 獲得から２年 ×（京成系列店のみ使用可、1000ポイント毎に1000円相当） 海外：利用付帯
相鉄(smbc) VISA/Master PASMO分離 永年無料 ×(0.0〜0.5%) 1000円毎５ポイント 獲得から２年 ×（相鉄系列店のみ使用可、1000ポイント毎に1000円相当） なし
東武JCB JCB PASMO分離 永年無料 ×(0.0〜0.5%) 1000円以上で0.5％ 獲得年内 ×（東武系列店のみ使用可、1000ポイント毎に1000円相当） なし
東武UC VISA/Master PASMO分離 永年無料 ×(0.0〜0.5%) 1000円以上で0.5％ 獲得年内 ×（東武系列店のみ使用可、1000ポイント毎に1000円相当） なし
東武DC VISA/Master PASMO分離 永年無料 ×(0.0〜0.5%) 1000円以上で0.5％ 獲得年内 ×（東武系列店のみ使用可、1000ポイント毎に1000円相当） なし
横浜バンクカードSuica VISA Suica一体Type2 永年無料 ？ ？ 獲得から２年 ？ ？
小田急OP VISA/Master/JCB PASMO分離 年１利用で無料 ×(0.0〜0.5%) 200円毎１ポイント 獲得後の７月末〆で10月末期限切 ×（小田急系列店のみ使用可、1ポイント毎に1円相当） なし
京王パスポートDC Master？ PASMO分離 年250円 （以下略）
京王パスポートVISA smbc VISA？ PASMO分離 年250円 （以下略）
京王パスポートJCB JCB PASMO分離 年250円 （以下略）
その他の VIEW Suica VISA/Master/JCB Suica一体(本体) 年500円 0.0〜0.5％ クレジット 1000円毎で２VIEWサンクス 獲得の翌年度末 Suicaにチャージ（400ポイント毎に1000円チャージ） 海外：自動（他社より保険範囲が狭い）、国内：利用付帯
0.0〜1.5％ チャージ 1000円毎で６VIEWサンクス
SMBC CARD Suica VISA Suica一体Type2 年1312円 （以下略）
TOYOTA TS CUBIC VIEW VISA/Master/JCB Suica分離 年1837円 （以下略） ×（トヨタ系列店でのみ使用可）
ANA VISA Suica VISA Suica一体Type2 年2100円 （以下略）
鉄道会社直系の物は、各社の定期購入のポイント還元率が上昇する。
ビックカメラSuicaは、JCBクレジットの利用でビックとViewサンクスの両方が付く。ビックのポイントとViewサンクスのポイントは合算不可。
それ以外のカードでは、クレジットカード利用のポイントと、PASMOチャージのポイントが、合算される。
ToMeCARD の一体型は、デポジット500円は取られない。ToMeCARD の分離型は、デポジット500円を取られる。
ToMeCARD は、カード更新時に PASMO対応事業者の窓口（メトロでなくても可）で PASMO残高の移し替え手続きが必要。
Fri,01 May,2009 追記：ビックカメラSuica のポイント制度改変。
クレジットカードの旅行保険の話はFri,27 Jul,2007に詳細。
60Hz圏だと、 どうも、万人向けに、これ、と言える物が無い。 たいてい、 「年１回以上、定期券区間外を電子マネーで乗車しない場合、 年会費有料」 と言う条件が付いてくる。 電子マネーの対応圏外まで行く場合は 券売機で切符を買わなくてはならないが、 それがカウントに入らなかったりする場合、 かなりきつい条件の様な気がする。
本題４。 電車の中吊り広告。 株主優待の定期券式優待乗車券に必要な株数が、 ５年くらい前の1.5倍くらいになっていた。
別題。 アートディンクが、また、昔のシリーズの再販を始めていたらしい。 アートディンクといい、工画堂といい……、ゲーム業界の衰退期？。 第１弾は定番のＡ１〜Ａ３だったらしい。 …… HR2 は出るのだろうか？……、出しても売れないだろうな。 あと、アートディンクが作ったソフトはどれも、 大画面対応のリメイクをすれば、格段に見栄えが良くなると思うのだが。 Ａ４からしか大画面対応リメイクが無いけれど、 Ａ１〜Ａ２とかＡ以外のシリーズとかどうだろう。 あと、ダウンロード販売は苦手なのだが。
Ａ４ WIN の理不尽さは、壮絶なものがあった……。 鉄道箱庭を作りたいのにも関わらず、 不動産ころがしや株ころがしをやらないと経営が成り立たないし。 Ａ４ DOS(9801) の場合は、 駅は 8 だか 12 だか 16 個までしか作れないし、 １編成の１日の売上が 255 だったか 65535 だったかを越えると 0 に戻るバグがあるし。
Ａ２は「初の復刻」と書いてあるが、 以前に１度、 Ａ２（追加５マップ同梱で全10マップ）が再発売されているのだが……。 もしかして、前回出たのは「廉価版」もしくは「セット版」であって、 「復刻版」では無い、と言う理屈か？。
と、言う訳で、ＡシリーズはＡ１とＡ２が最高だったと思う。 Ａ３以降だったら FreeTrain の方が良いと思う…… でも総合的な完成度が……。
あと、 ロボクラッシュとかカルネージハートとか……、 箱庭じゃないか。
箱庭の件は、 Sun,08 Mar,2009に続く。
その工画堂の再販の PD1 の画面写真のプレスリリースが出ていた。 壮絶。 いっそ再販は無かった事に、と言うぐらい。黒歴史に埋没させて。 PD6 は新規の舞台へのチャレンジ失敗だからまだ救いがあるとして、 PD1 は新しい事へのチャレンジ無しで失敗だから、 もう救いようが……。
新聞の誤字？：「偽造防止を防ぐ為に」。 時々、数文字分とか一文分程度の空白が有るのは、 こう言うのを直した痕跡なんだろうなぁ。
Wine-1.1.16 on FreeBSD/i386 6.4-RELEASE。
Mon,09 Nov,2009に続く。
作業中に裏で箱庭を BackGroundVisual にでもしようかと、
Wine で T98Next を動かしてみた。
wine: Unhandled page fault on write access to 0x00000000 at address 0x******** (thread 0009), starting debugger...でこけた。 どうも wined3d.dll を読み込もうとして失敗した直後に出ている。 でも wined3d.dll.so は、ちゃんとインストールされている。 挫折。
↑ wine + 東方 も駄目だった。全く同じエラーが出て動かない。 http://d.hatena.ne.jp/kakurasan/20080331 に書いてある様にすればネイティブの DirectX がインストールできたが、 ネイティブの DirectX 9.0c Nov.2008版をインストールしても 状況は変わらず。 http://wiki.freebsd.org/Wine に書いてある様にパッチを当てても駄目。 dxdiag.exe でも、 DirectDraw と Direct3D のテストで全く同じエラーが出てこける。 Pixel Shader とか Vertex Shader とかの設定を変えても駄目。
↑*2 DirectDraw を使わないアプリケーションなら、 相当前から問題無く動くのだが。 FreePascal とか GearHead for MS-Windows GUI/SDL とか 市販のCAD とか。 テキストエディタとかバイナリエディタとかも動く。
と言う訳で？、誰か、 鉄道箱庭とか HR2 とかその辺りを Unix系で作ってくれませんか。 HR2 なんか、ゲームとしては退屈でつまらないだろうけれども、 BGV としては、淡々と積み上がっていく辺り良いのではないかと。 但し、 マクシスやエレクトロニックアーツあたりのアメコミ風味は苦手なので、 アートディンクあたりの和風で。 あと、GNU/Linux 専用は勘弁な。 どうしても GNU/Linux 専用にする場合でも、 せめて BSD/Linux/amd64 でも動く様にして下さい。
BGV の件と箱庭の件は、 Sun,08 Mar,2009に続く。
２月再販版 1/8000 マクロス強攻型 ￥588-。 定価が￥735-なので２割引。 他は、VF-11 ミレーヌ、VF-1J 変形、VF-1S ファイター（固定）、 ヌージャデルガー、クァドランロー、グラージ、 しかなかった。
BB TwinPack のブルーブラスターファンディスク パート、 未来編 クロウディア奪還作戦。 web でみかける攻略記事だと 「脱落者無しのクリアは無理」と言う物しか見かけないが、 難易度 とても難しい にて、脱落者無しでクリアした。 でも、その後のシナリオ展開は変わらなかった。
メモ：
確認が必要そうなもののメモ（以前の Anthy では変換できなかった物）。 おそろし #KYT 恐ろし → OK かい #KXI 書い → OK かい #KXI 描い → OK しん #T05 死ん → OK 「単語だとか」は出るが、「単語だとかの」が出ない。→ OK 古語の「恐ろし」が出ないが、これは仕方が無いだろう。
BackGroundVisual の話。 Fri,06 Mar,2009の続き。 Unix系ネイティブで動作する PC-9801 エミュレータが無いかと探していたら、 Neko Project II for X 略して xnp2 と言う、 X-Window System 方面用の、PC-286/PC-9801 エミュレータを見つけた。 FreeBSD/i386 6.4-RELEASE にて、IA-32 有効にしたら刺さったが、 IA-32 無効なら、すんなり動いた。ただ、音が出ない。 sdl_sound がらみがよくわからん。
Couldn't set audio blocking mode → SDL の音源として OSS が指定されているのに、OSS が動いていない。 （SDL の音源として ESD と NAS を指定して SDL を再インストール） Couldn't open /etc/goemon.cfg → esd(daemon) もしくは nasd(daemon) が止まっているので、timidity に振り替えに行って失敗。 （esd もしくは nasd を起動） Couldn't create audio thread → SDL で thread生成が禁止に設定されている。 SDL の thread生成を許可に設定してインストールしていると、 FreeBSD/i386用や GNU/Linux/i386用にコンパイルした GearHead を FreeBSD/amd64上で動かした時や、 GNU/Linux/i386用にコンパイルした GearHead を FreeBSD/i386上で動かした時に、 SDL がクラッシュする、SDL のバグだか仕様だかがあるので、 SDL の thread 生成を強制禁止にしていて、そのままだった。 （SDL の thread 生成を許可に変更して SDL, SDL_mixer, SDL_image を再インストール） → 無事、SDL_sound で音が出る様になった。 でも xnp2 では音が出ないまま。 → ~/.np2/np2rc の sounddrv が nosound のままだった。 SDL に書き換えたら、無事、音が出た。 ＃ sounddrv を GUI から設定できるメニューが見つからない。今まで使っていた仮想 HDD で起動してみたら、 メモリマネージャで刺さった。 xnp2 は 80286ベースだから、 VEM486 とか VMM386 とか EMM386 は駄目らしい。 こんな事もあろうかと あらかじめ仕込んでおいた CINIT の EMM無印な設定を使うと、 あっさり起動。
↑ Ａ列車で行こう２ を動かしてみたら、 文字表示回りで画面が乱れた。 GRCG では駄目で、xnp2 で EGC 指定にしないと駄目らしい。 当時より１〜２桁速い CPU を負荷 100％で回しているのに、 当時の２倍の速さにもなっていない（← 無茶言うな）。 別のマウス対応のソフトで、マウスの移動速度が変。 No Wait モードだと、 負荷が軽い時は速く動き、負荷が重い時は遅く動いてしまうので、 そうなってしまうらしい。 面表示の同期を取るモードに設定すれば、 まともに動かせる様になった。 但し、エミュレーション速度が等倍速固定になってしまう。 ポーズ（一時停止）が無い。 xnp2 を終了させたくないけれども、一旦止めたい時など、ポーズ欲しいかも。 あとやっぱり、今時の画面の広さに慣れてしまうと、 640x400 で箱庭を表示するのは狭すぎる。
と言う訳で、誰かその辺りの箱庭を再実装して下さい。 ルートスクリーンとかスクリーンセーバーとかで、 ぼんやり動かしても負担にならない様に、 せいぜい CPU 負荷 10％くらいで画面一杯に表示しつつ軽快に動く様に。
↑ 鉄道系に関しては、もうあるらしい。 http://japanese.simutrans.com/ しかも鉄道に限定されず、車両、船舶、飛行機も扱えるらしい。 ……ダイヤグラムは作れないらしい。 高架線とか立体交差とか地下鉄とか直線以外のトンネルとかも 駄目（小細工してなんとかそれっぽい雰囲気止まり）らしい。 複線とか３複線とか複々線とかも駄目（それっぽい雰囲気止まり）らしい。 急行の接続待ちも駄目らしい。 うーん、なんかいまひとつ、鉄道箱庭とはずれているなぁ。 町だと LinCity あたりかな。 民族？だと Freeciv あたりがあるし。 塔は聞いた事が無いな。 バトル物で鴨葱なみの物も無いし。 CoreWars はバトル物でも毛色が全然違うし。 RealTimeBattle はソフト面は鴨葱の系統だけれども。
alt-depgraph-090308 が出ていた。
で、気付いた事。
「|専用にする|」（１文節）が出ない。 「|専用に|する|」（２文節）と「|専用する|」（１文節）は出る。 同じ「××にする」でも、「|反故にする|」は１文節で出た。 「反故」は T35 だった。 「専用」は T30 単体になっているけれども、T30 と T35？の重複なのかも。 ＃ 「専用する」は、「占有する」「占用する」と同じ感じの意味らしい。 「|縮退させる|」（１文節）出ない。 「|縮退|させる|」（２文節）出る。 同じ「××させる」でも、「|破壊させる|」は１文節で出た。 「縮退」は T35、「破壊」は T30。 「する」、「させる」を付けて１文節になる物と、２文節に分かれる物の、 仕分けがよくわからない。１文節と２文節と、どちらが良いのだろう。
↑昨日の続き。
とか書きかけていたら、詳細な解説が来ていました。
vagus氏 - 丘の道を登り - 2009年03月10日 - 「専用にする」。
有り難うございます。
< patch13 2009303 の mkdepgraph.c を使うように(でいいんですよね?)修正します。 はいそうです。 あと、mkdepgraph にて、 indepword.txt か master.depword が無い場合は make が止まる様にしましたが、 include しようとしたファイルが無い場合や、構文エラーがあった場合などで、 anthy.dep が作れなかった（壊した）場合などは、make は続行してしまいます。 その辺りは、ちょっと根が深いっぽかったので、手抜き。 「助詞を挟んで補助動詞」のパターンは、 １文節でも２文節でも構わないので、統一した方が、 「単語が辞書に無い」と誤解されなくて済むかと思われます。 でもここまで大規模化してしまっているので、作業が簡単確実な方が良いかと……。 「恐ろし」は古語なので、これを出そうと考え始めると、 「良ろし」、「悪ろし」、「悪し」、きりがないかと……。 ＃ でも「良し」は出た。 ただ、ク活用とシク活用は、頭が痛い問題ですね。どうしようもないですが……。
学習の上限を引き上げて学習させ始めた頃から、
補助動詞を付けて１文節で学習させるべきか、２文節で学習させるべきか、
ずっと迷っていました。
あと「して」とか「しました」とかが付いたり付かなかったり……。
DDoS の話、 Tue,03 Mar,2009の続き？。 Wed,11 Mar,2009 の 06:45頃に、 正引き専用 DNS サーバに、 64.34.179.92 から逆引きの query が来ていた。 こちらの DNS の構成上、 この IP で DNS が動いているのを知らないと、 逆引きは来ない筈なのだけれど。 DDoS の踏み台にする前には、 踏み台にできる相手を探さなくてはいけない筈で、 踏み台を探す際の何らかの兆候が有る筈だと思うのだけれども、 もしかしたらこれがそうかもしれないし、違うかもしれない。 DDoS に関係が有るのか無いのかは不明。
かな漢字変換の変換候補の並び順のアルゴリズム。
Anthy で、
変換候補の第１候補が望んだ物で無かった場合の、
第２候補以降の並び順に、
ずっと（Anthy を使い始めてからずっと）違和感を感じていたのだが、
ようやくその原因に気付いた。と思う。
直接には、
第１候補が望んでいない物だった場合に、
第２候補以降の並び順が「何か違う」ので、
望んだ候補がなかなか見つからなくて、
ものすごく違和感を感じるのだが。
今まで使っていたかな漢字変換だと、未学習の物は、
JIS の文字コード順かそれに近い順に並んでいた。
たぶん。
Anthy 原作版だと、システム辞書の頻度値でおおまかな順番を決め、
システム辞書のインストール時に詳細な順番をランダム(qsort)で確定し、
変換時にランダム(qsort)とコーパス情報から再調整を行い、
順番が決まっている。
Anthy 拙作パッチだと、
システム辞書の頻度値で順番を確定し（同値の場合は出現順）、
変換時にコーパス情報から再調整を行い、
順番が決まっている。
はず。
Canna の場合： 全、前、善、膳、千、喘、蝉、漸、然、禅、 繕、ゼン、ぜん 愛、相、会い、合、藍、哀、アイ、娃、挨、姶、 逢、合い、あい、逢い、遭い、アイ、あい、 原作版 Anthy の場合： Disk Full になってしまったので消してしまいました。 Anthy + 拙作パッチ + alt-cannadic-090308 + alt-depgraph-090308 の場合： 全、前、善、膳、禅、ぜん、千、漸、仟、是ん、 染、然、蝉、繕、亶、冉、喘、擅、涎、禪、 譱、苒、蠕、髯、ゼン 愛、相、藍、あい、アイ、合い、会い、間、阿井、遭い、 逢い、亜依、亜衣、遇い、安居、歩惟、亜唯、歩衣、哀、娃、 挨、姶、逢、I、i、Ｉ、ｉ、哇、噫、埃、 曖、欸、瞹、穢、胥、藹、阨、隘、靄、靉、 鞋うーん、違うと言う程違うわけでもないなぁ。 単漢字や二水も一緒に並んでいるせいかなぁ。
原典： vagus氏 - 丘の道を登り 【実験】hogedic - 寄り道 http://vagus.seesaa.net/article/68188762.html 【実験】hogedic - その１(追記) http://vagus.seesaa.net/article/67869203.html 【実験】hogedic - その2 http://vagus.seesaa.net/article/69112610.html ほげ ほげKS-300、ほげKS-250、ほげKS-200、ほげ、ホゲ ほげる ほげるCN-300、ほげるJN-300、ほげるKK-300、ほげるCJ-300、ほげるT35-300、 ほげるT05-300、ほげるT15-300、ほげるT30-300、ほげるF14-300、ホゲルT35-300、 ほげるCN-250、ほげるJN-250、ほげるKK-250、ほげるCJ-250、ほげるT35-250、 ほげるT05-250、ほげるT15-250、ほげるT30-250、ほげるF14-250、ホゲルT35-250、 ほげるCN-200、ほげるJN-200、ほげるKK-200、ほげるCJ-200、ほげるT35-200、 ほげるT05-200、ほげるT15-200、ほげるT30-200、ほげるF14-200、ホゲルT35-200、 ほげR5-300る、ほげKS-300る、ほげR5-250る、ほげKS-250る、ほげR5-200る、 ほげKS-200る、ダミー26、ダミー25、ほげるKJ-300、ダミー24、 ほげるKJ-250、ダミー23、ダミー22、ホゲる、ダミー21、 ほげる、ダミー20、ほげるKJ-200、ダミー19、ダミー18、 ダミー17、ダミー16、ダミー15、ダミー14、ダミー13、 ダミー12、ダミー11、ダミー10、ダミー9、ダミー7、 ダミー8、ダミー6、ダミー5、ダミー4、ダミー3、 ダミー2、ダミー1、ホゲル ほげるです ほげるT05-300です、ほげるT15-300です、ほげるT05-250です、ほげるT15-250です、ほげるJN-300です、 ほげるCN-300です、ほげるKK-300です、ほげるCJ-300です、ほげるT30-300です、ほげるT35-300です、 ほげるF14-300です、ホゲルT35-300です、ほげるT05-200です、ほげるT15-200です、ほげるJN-250です、 ほげるCN-250です、ほげるKK-250です、ほげるCJ-250です、ほげるT30-250です、ほげるT35-250です、 ほげるF14-250です、ホゲルT35-250です、ほげるJN-200です、ほげるCN-200です、ほげるKK-200です、 ほげるCJ-200です、ほげるT30-200です、ほげるT35-200です、ほげるF14-200です、ホゲルT35-200です、 ダミー9です、ダミー8です、ダミー7です、ダミー6です、ダミー5です、 ダミー4です、ダミー3です、ダミー2です、ダミー1です、ダミー26です、 ダミー25です、ダミー24です、ダミー23です、ダミー22です、ダミー21です、 ダミー20です、ダミー19です、ダミー18です、ダミー17です、ダミー16です、 ダミー15です、ダミー14です、ダミー13です、ダミー12です、ダミー11です、 ダミー10です、ほげるです、ホゲルデス ・「ほげR5-*る」が低いのは、環境設定で付属語付きのスコアを下げてあるから。 ・「ほげるKJ-*」が低いのは、depgraph で #KJ（単漢字）の付属語無しは weak 指定になっているから （ついでに言うと、単漢字の付属語は存在しない様に指定されている）。 ・「ほげるJN-300です」が「ほげるT15-250です」より低いのは、 「ほげるJN-300です」は付属語２つに対して、 「ほげるT15-250です」は付属語１つであり、 環境設定で付属語の数が多いほど減点を大きくしてあるから。 ・「ほげるです」の、「ダミー9です」と「ダミー26です」の並び順が逆なのは、 「ダミー9です」以降全部が最低点の 11 に張り付いてしまって、 内容の文字数でソートされているから。 ……試験的に文字数ソート入れたまま忘れてた。 スコア → 付属語の数 → 付属語の文字数 → 全体の文字数 → 辞書での出現順一応設計通りにはなっているのか……。
結論：
やっぱり違和感の原因は、わからなかった。
いっそ単漢字の付属語を「t」とかにして、
普段の一覧では出ない様にしてみるか……。
……数字とか記号とかの候補順序を固定する為に
単漢字で登録して頻度値で調整しているから駄目なのか。
鴨葱みたいなプログラミング。 TiColla とか言う物で、ブロックを組み合わせてプログラムを作り、 ロボット（実機）を動かせるらしい。 2002年10月に開発スタートで 2004年６月には販売していたらしい。 ふと、 将来、こう言う簡単にプログラムを作れるシステムでしか プログラムを作れない人ばかりになったら、 そのシステム自体のプログラムは誰が作るのだろう、 とか思った。 直近でも、統合開発環境が無いとプログラム作れません、 と言う人が結構いるみたいな感じだし。 こういうブロック方式とか図形描画方式は、入門用には良いのだろうけれどね。 英語アレルギーや文法アレルギーも起きにくいだろうし。 でも、鴨葱は、 ブロック使わずに普通にソースコード書かせろ、と思った事もある。 ブロックだと、処理を追加する時のブロックの位置合わせのやりなおしが 面倒なんだよ……。
FreeBSD で TrueCrypt。 Sun,15 Oct,2006、 Sun,09 Sep,2007、 Sun,02 Mar,2008、 Tue,25 Mar,2008に関連。 Tue,17 Mar,2009に続き。 バックアップの時期に利用しようとする毎に、 メジャーアップデートがかかっている気がする。 FreeBSD の ports 方面だと、 正統派の主張「geli 使えばいいじゃん」によるものなのか、 安定動作しないからなのか、 あるいはライセンスの問題なのかは不明だが、 TrueCrypt は未だに ports に入っていない。 （追記： TrueCrypt の標準設定のままだと安定動作しないから、らしい） 確かに geli 使うのが王道で正当なのだけれども。 運用が FreeBSD で閉じている場合はともかくも、 運用に MS-Windows や GNU/Linux が絡む場合や、 バックアップのリカバリに使えるマシンが FreeBSD ではない可能性があったりすると、 geli だと困るわけで。 もっとも、TrueCrypt にした所で、 OpenBSD で使えない（fusefs が無い）けれども。 NetBSD は不明。 結局、横断して使えるのが TrueCrypt しかない、と言う消極的理由で、 FreeBSD 6.4-RELEASE にも TrueCrypt 5.1a とか 6.1a とかをインストールしてみた。 修正点は、
5.1a の場合： Makefile は GNU-make 専用なので、gmake（パッケージ）を使う。 Makefile内からの GNU-make の呼び出しに make を直打ちしているので、$(MAKE) に書き直す。 （FAQ： make を実行するコマンド名が make であるとは限りません。 Makefile 中で make を呼ぶ場合は $(MAKE) と書きましょう） マウントオプションで sync 指定する。これ重要。 sync 指定を忘れると、大きなファイルを書き込んだ時にカーネルフリーズする。 TrueCrypt の標準設定だと async 指定になっている。 6.1a の場合： Makefile は GNU-make 専用なので、gmake（パッケージ）を使う。 pkcs11-helper（パッケージ）が必要。 pkcs11 のライブラリによっては？、Common/SecurityToken.cpp の 654行目(CKR_NEW_PIN_MODE)と 655行目(CKR_NEXT_OTP)の機能が 無い場合がある？ので、修正（コメントアウト）する。 マウントオプションで sync 指定する。これ重要。 sync 指定を忘れると、大きなファイルを書き込んだ時にカーネルフリーズする。 TrueCrypt の標準設定だと async 指定になっている。ビルドは、 TrueCrypt の Readme.txt の GNU/Linux用の説明通りにするだけ。
% setenv PKCS11_INC /usr/local/include/pkcs11-helper-1.0/ % setenv WX_ROOT /hoge/wxWidgets-2.8.9 % gmake WX_ROOT=/hoge/wxWidgets-2.8.9 wxbuild % gmake WX_ROOT=/hoge/wxWidgets-2.8.9 WXSTATIC=1FreeBSD/i386 Core 1.6GHz で１時間、 FreeBSD/amd64 Athlon64 2.2GHz で30分くらいかかったが、 ビルドできた。 wxWidgets 入れるのが面倒なので、 バイナリパッケージの wxgtk-unicode を使ってみたが、 それは駄目だった。 参考： freebsd-ports/2008-February/046801 （sys/ucontext.h の修正は不要だった） あとは
% sudo /usr/local/etc/rc.d/fusefs forcestart % ./Main/truecryptで、普通に fusefs として使えた。fusefs の可搬性、凄いね。 truecrypt側で root権限が必要な部分は、 sudo用のパスワードを聞いてきて sudo かけていた。 あとはどれだけ安定していて信頼性があるかどうかの問題か……。 ベンチマーク結果は、 Sun,02 Mar,2008の TrueCrypt の項目を参照。 gpg --compress-level 9 --symmetric --cipher-algo AES256 よりは速かったけれども、 gpg --compress-level 0 --symmetric --cipher-algo AES256 や FreeBSD で使用できる他の全てのファイル暗号化システム （fusefs 有無問わず）より遅かった。 保存先のメディア買うの忘れた。
↑ TrueCrypt。 流出しても問題無いデータのバックアップ用コンテナとして使う為に、 暗号化無し／パスワード無しで高速なコンテナも選択できると便利かな、 と、ちょっとだけ思った。 アーカイバ使え、と言う話になるかもしれないけれど。
↑ あと、 途中のブロックにエラーが出た場合に、 エラーブロックに当たらないファイルの救出が出来るか否かの確認を忘れた。 lha は、そのブロック以外のファイルの救出ができるから、 愛用しているのだけれど。 tar.gz や tar.bz2 や gpg + gz や gpg + bzip2 は救出できず、 丸ごと全滅する。 zip も救出できるっぽい。
↑*3
TrueCrypt on FreeBSD/i386 がフリーズした、
5.1a でも 6.1a でも変わらずフリーズする。
vfs.bufspace？か vfs.hirunningspace
どちらか小さい方の値を超えるサイズのファイルを書き込もうとすると、
書き込み（暗号化する前の側の書き込み）のシステムコール？から
帰ってこなくなる。
vfs.bufspace もしくは vfs.hirunningspace の小さい方の値は
TrueCrypt を起動した初期状態で 1MB なので、
1MB より大きいファイルを書き込もうとすると、さようなら。
sysctl vfs.hirunningspace=1000000000 とかやっても、
vfs.bufspace は 100MB くらいより大きくはならなかった。
なので、どうがんばっても 100MB より大きいファイルを書き込むと、
色々と終わる。
fusefs-EncFS だと 200MB のファイルを書き込んでも問題無かったので、
fusefs の問題では無く、TrueCrypt の問題だと思う。
……、本家 FreeBSD の ports ML でも、同じ話題が既に出ていた。
TrueCrypt を標準設定のままで使うと、
大きなファイルを書き込んだ時にフリーズする。
マウントオプションを変更して -o sync すると、
フリーズせずに書き込める様になった。
詳細はTue,17 Mar,2009。
ベンチマークの詳細は
Sun,02 Mar,2008。
書き込みのベンチマーク結果は、Core 1.0GHz にて、
AES-128 で 3〜4MB/s くらいだった。
CFS の blowfish-128 の半分〜７割程度の速度、
fusefs-EncFS の blowfish-128 の２〜３割くらい、
GnuPG の AES256 の 1/3〜半分くらい、
geli の blowfish-128 の 1/3〜半分くらい、
geli の AES-128 の３割くらい、
の速度。
速度だけ見たら、
TrueCrypt はファイル暗号化方面の最遅をマークしました。
まぁ fusefs のせいという面もあるかもしれず……、
でも fusefs-EncFS は速度出ているのだよな……。
読み出しは特に問題は見つからなかった。ただ、やたら負荷が高い。
msdosfs のマウントオプションが GNU/Linux 向けになっているらしく？、
「md→マウント先ディレクトリ」側のマウントが
日本語ファイル名が扱えない設定でマウントされる。
no mount 指定にして暗号処理部分だけマウントした後、
手動で
% sudo mount_msdosfs -o sync -l -L ja_JP.eucJP /dev/md1 /media/truecrypt1するか、普通にマウントした後に
% sudo mount -u -o -l,-L=ja_JP.eucJP,sync /media/truecrypt1しないと、日本語ファイル名が蹴られる。 TrueCrypt のマウントオプション指定の欄で -t msdosfs -o -l,-L=ja_JP.eucJP,sync 指定しても駄目（挙動からすると、「コンテナ→truecrypt→fusefs」側か、 「fusefs→md」側どちらかのマウントオプションらしい）。 gam_server が変な所でディレクトリかファイルの ソケットか何かを握って離さなくなって、 Device Busy で TrueCrypt の unmount ができなくなる事が多い。
% sudo umount -f /media/truecrypt1 % sudo mdconfig -d -u 1 % sudo umount -f /tmp/.truecrypt_aux_mnt1すれば、無理矢理 unmount できるけれど。 Mon,06 Apr,2009 追記： /var/log/hdk.log - 2008年5月中旬 - 12 (月) - %3 gamin すれば、掴まないらしい。
と言う訳で、FreeBSD で TrueCrypt は、
読み出しは無理して何とかならなくはないが、
あとは駄目そう。
使える事は使えるが、常用にはちょっときつい感じ。
可搬性とコンテナ方式で管理が楽、なのは良いのになぁ。
TrueCrypt の話は Sat,14 Mar,2009、 Tue,17 Mar,2009に続く。
Anthy に alt-depgraph と alt-cannadic を
入れたのはいいけれど、
ちゃんと使えるか否かは、どうやって確認すればいいのだろう、と言う話。
検査するには、「よみがな」と「変換後の内容」が必要だが、
どうやって手に入れたものか、と思ったのだが。
よくよく考えたら、
これまで学習させたデータがそのまま教師データになる事に気付いた。
しかも、全てのデータに於いて、
望ましい変換であるかのチェックを済ませてあるし。
あとは、「よみがな」から「変換後の内容」の内容に
変換させる事が出来るか否かの判定が必要だが。
test/ を探してみたが駄目だった。
test/test_anthy は、
第１候補が「変換後の内容」になるか否かの判定しかしない上に、
「変換後の内容」の一致判定の際には文節区切り位置指定を無視していて、
指定した文節数にならなくても OK 判定出された。
次に vagus氏がコーパスをいじっていた時の記事に
何かそれっぽい事があった事を思い出して calctrans/ を探してみる。
calctrans/proccorpus に突っ込んでやれば、
変換できる場合は変換後の文字列の
自立語部分と付属語部分のハッシュ値が出力され、
変換できなければ unknown と記録されハッシュ値が出力されない。
これで変換可否の検査は出来る。
あとは、学習データを calctrans/proccorpus に入力できる形式に
変換するだけだが。
#!/usr/bin/perl --
#
# Anthy: A Converter of some CAND_HISTORY to a corpus.txt file.
# Sat,14 Mar,2009
# Copyright(C)2009 G-HAL (fenix.ne.jp)
#
use strict;
my $argc = @ARGV;
my $debug = 0;
{
while () {
chomp( $_ );
my $input = $_;
if ($input =~ /^\+([^ ]+) (.+)$/i) {
my $index = $1;
my $contents = $2;
while ($contents =~ /^O[0-9]+ [0-9]+ "([^"]+)" (.+)$/i) {
my $key = $1;
$contents = $2;
print "|". $index ."|" . " " . "|". $key ."|" . "\n";
}
}
}
exit 0;
}
__END__
# [ EOF ]
変換する perl スクリプト書いて終わり。面倒なので、拙作patch4以降専用。↑ 注意：
calctrans/proccorpus は、
実体は （ビルドしたディレクトリ）/calctrans/.libs/proccorpus、
設定ファイルは ../anthy-conf のみ、
辞書は ../mkanthydic/anthy.dic のみ、
なので注意。
↑ そして調べた結果。
入力 約28000件に対し、１文節に変換できなかった物が約1000件。
……、1000件もあったら全部に目を通せないし。
private_words_* にのみ登録してある単語を使っているせいで
変換できない物も混じっているし。
どうしよう。
↑ alt-depgraph の話の続き？と言うか一旦の結末？と言うかは、 「vagus氏のサイト - 丘の道を登り - 2009年03月14日」。
tclock が、またメモリリークしていた、 Sun,16 Oct,2005の続き。 valgrind で検出できないので、たぶんまた libX11 内の XEvent 回り。 こいつは ccmalloc 使えば検出できる筈……。 ……検出できた。 Sun,25 Feb,2007 の patch5 で、 Window Manager側での Stickey Above機能に対応させた時に、 昔のメモリリークバグを復活させてしまっていて、 それからずっとメモリリークしっぱなしだったらしい。 何のひねりも工夫も無く、以前のメモリーリークと全く同じだった。 何やってんだか……。 tclock-1.0.1 機能追加パッチ、 メモリーリークの修正完了版(patch6)。
バックアップメディア。
最近は Blu-rayDisk もあるのか。
しかもメディア容量単価は BD の方が DVD より安いご時世なのか。
MO は信頼性は高いが容量単価と入手性とメディア１枚当り容量がなぁ。
Hi-MD は MO よりメディア容量単価は多分安いが
入手性とメディア１枚当り容量と
さらには継続的にデバイスが供給されるかどうかと言う問題がなぁ。
DVD 外付けドライブ ￥6,000〜15,000- BD 内蔵ドライブ ￥16,000〜40,000- BD 外付けドライブ ￥30,000〜35,000- 640MO 外付けドライブ ￥15,000〜20,000- 1.3MO 外付けドライブ ￥20,000〜25,000- 2.3MO 外付けドライブ ￥40,000弱 MZ-RH1 ￥30,000〜40,000- 容量単価でソート 量販店価格 容量単価 15GBの保存にかかる費用（ドライブ込） MO 230MB メディア ５枚￥1,500〜2,000- @1.3〜1.7/MB ￥36,000〜49,000- 72枚 MO 2.3GB メディア １枚￥2,000前後 @0.87/MB ￥55,000- ８枚 MO 640MB メディア ５枚￥2,500〜3,000- @0.78〜0.94/MB ￥27,000〜36,000- 26枚 MO 1.3GB メディア １枚￥1,000前後 @0.77/MB ￥32,000〜38,000- 13枚 Hi-MD 1.0GB(964MB?) メディア １枚￥710- @0.74/MB ￥42,000〜53,000- 18枚 Hi-MD 1.0GB(964MB?) メディア ３枚￥1,970- @0.68/MB ￥41,000〜52,000- 18枚 Hi-MD 80min 305MB メディア ５枚￥700- @0.46/MB ￥37,000〜48,000- 55枚 Hi-MD 74min 291MB メディア ５枚￥600- @0.41/MB ￥36,000〜47,000- 57枚 Hi-MD 80min 305MB メディア 10枚￥1,000弱 @0.33/MB ￥35,000〜46,000- 55枚 Hi-MD 74min 291MB メディア 10枚￥900弱 @0.31/MB ￥35,000〜46,000- 57枚 CD-RW メディア（650MB） ５枚￥500〜1,000- @0.16〜31/MB ￥8,000〜21,000- 26枚 CD-RW メディア（650MB） 10枚￥1,000〜1,500- @0.15〜23/MB ￥8,000〜19,000- 26枚 DVD-RAM 4.7GB ２倍速 メディア ５枚￥1,280- @0.054/MB ￥6,000〜16,000- ４枚 DVD-RAM 4.7GB ２倍速 メディア 10枚￥2,180- @0.046/MB ￥6,000〜16,000- ４枚 BD-RE メディア（25GB） １枚￥1,000前後 @0.040/MB ￥31,000〜36,000- １枚 BD-RE メディア（25GB） ３枚￥2,500前後 @0.033/MB ￥31,000〜36,000- １枚 BD-RE メディア（25GB） ５枚￥3,500前後 @0.028/MB ￥31,000〜36,000- １枚 ドライブ込み総費用でソート 量販店価格 容量単価 15GBの保存にかかる費用（ドライブ込） MO 2.3GB メディア １枚￥2,000前後 @0.87/MB ￥55,000- ８枚 Hi-MD 1.0GB(964MB?) メディア １枚￥710- @0.74/MB ￥42,000〜53,000- 18枚 Hi-MD 1.0GB(964MB?) メディア ３枚￥1,970- @0.68/MB ￥41,000〜52,000- 18枚 MO 230MB メディア ５枚￥1,500〜2,000- @1.3〜1.7/MB ￥36,000〜49,000- 72枚 Hi-MD 80min 305MB メディア ５枚￥700- @0.46/MB ￥37,000〜48,000- 55枚 Hi-MD 74min 291MB メディア ５枚￥600- @0.41/MB ￥36,000〜47,000- 57枚 Hi-MD 80min 305MB メディア 10枚￥1,000弱 @0.33/MB ￥35,000〜46,000- 55枚 Hi-MD 74min 291MB メディア 10枚￥900弱 @0.31/MB ￥35,000〜46,000- 57枚 MO 1.3GB メディア １枚￥1,000前後 @0.77/MB ￥32,000〜38,000- 13枚 BD-RE メディア（25GB） １枚￥1,000前後 @0.040/MB ￥31,000〜36,000- １枚 BD-RE メディア（25GB） ３枚￥2,500前後 @0.033/MB ￥31,000〜36,000- １枚 BD-RE メディア（25GB） ５枚￥3,500前後 @0.028/MB ￥31,000〜36,000- １枚 MO 640MB メディア ５枚￥2,500〜3,000- @0.78〜0.94/MB ￥27,000〜36,000- 26枚 CD-RW メディア（650MB） ５枚￥500〜1,000- @0.16〜31/MB ￥8,000〜21,000- 26枚 CD-RW メディア（650MB） 10枚￥1,000〜1,500- @0.15〜23/MB ￥8,000〜19,000- 26枚 DVD-RAM 4.7GB ２倍速 メディア ５枚￥1,280- @0.054/MB ￥6,000〜16,000- ４枚 DVD-RAM 4.7GB ２倍速 メディア 10枚￥2,180- @0.046/MB ￥6,000〜16,000- ４枚……、BD は、まだ早いか。あと、信頼性がなぁ。 DVD-RAM に dvdisaster でエラー訂正符号付けて 実効データ保存効率？を 50％位にしても、まだ最安なのか。 Sat,28 Mar,2009、 Sun,29 Mar,2009に続く。 価格の話は Wed,19 Jan,2011に続く。
TrueCrypt 5系 & 6系を FreeBSD 6系 で使うと、 カーネル内のディスクアクセスバッファのサイズより 大きいファイルを書き込もうとした時にカーネル空間近辺で固まる件、 Fri,13 Mar,2009の続き。 Tue,17 Mar,2009に続く。 web で検索していたら。 TrueCrypt のソースの FuseFS の書き込み要求受付部分のコメントに、 ずばり 「FreeBSD は書き込みでエラー出すと永遠にリトライを繰り返して、 system crash を引き起こす」（意訳、原文は英語） と書いてあった。 でもよくみたら、 実ディスクが ReadOnly mount されていた場合と、 実ディスクが書き込み保護されていた場合に、 書き込みを拒否する部分のコードだった。 なので今回の件とは関係無し。 でもまぁ、この近辺なんだろうなぁ、と言う事で追いかけてみたら。 コンテナにデータを書き込む時は 2KiB 単位に分割して書き込んでいたが、 大きいファイルを書き込もうとすると、 コンテナに 2KiB 毎に pwrite() するループ中の スレッドキャンセルポイント辺りで自動で sync が行われて、 その sync でフリーズしていた。 fusefs への書き込み中に sync が発生したせいで、 vfs-lock がデッドロックでも起こしたのだろうか？。 でもそうすると、fusefs-EncFS でフリーズが起きないのが不思議になるわけで。 ufs/ufs2 と msdosfs の違いか？、 ファイル単位とボリューム単位の違いか？。 Tue,17 Mar,2009追記： ファイル単位とボリューム単位の違いだった。 あと、いくら UFS2 は復旧性能が高くて、 この程度のクラッシュでは損害が出た事が無いとは言え、 失敗したらクラッシュするのを承知で作業するのは精神衛生上は良くないわけで。 qemu 上にテスト環境を作るのも面倒で、それ以前にディスク容量が足りないし。
唐突な思い付きで、RSS 1.0 をやめて RSS 2.0 に変えた。
TrueCrypt on FreeBSD、 大きなファイルを書き込むとカーネルフリーズを起こす件、 Fri,13 Mar,2009、 Sat,14 Mar,2009の続き。 TrueCrypt の話は、 Sun,15 Oct,2006、 Sun,09 Sep,2007、 Sun,02 Mar,2008、 Tue,25 Mar,2008に関連。 大きなファイルを書き込む時でも安定して動かす方法が判った。
ファイルシステムの事を判っている人ならば、 「多段重ねにしているファイルシステムでは、sync と async を混ぜるな」で 全てが完了する話。 管理者級の人には 「ふ、しろうとが（いせっいたまぬ氏風に）」 と言われてしまって終わる話、 いや、鼻で「フン」とされて終わりかも。 結論だけ言うと、 TrueCrypt をマウントする時は -o sync が必須。 でも TrueCrypt の標準設定だと -o sync が付いていない。
問題無く動作する時はこんな感じ。
% sudo /usr/local/etc/rc.d/fusefs forcestart （TrueCrypt のマウント操作） % sudo mount -u -o -l,-L=ja_JP.eucJP,sync /media/truecrypt1 ← sync オプションを付けて同期モードにする。 % mount （一部省略） /dev/ad0s2f on /home (ufs, local, noatime, soft-updates) ← truecrypt のコンテナが置いてあるファイルシステムは soft-update な非同期モードのままでもいけた。 /dev/fuse0 on /tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous) ← fusefs は同期モード専用らしい？ /dev/md1 on /media/truecrypt1 (msdosfs, local, synchronous) ← fusefs に合わせて truecrypt も同期モードに設定する。 % dd if=/dev/zero of=/media/truecrypt1/zero bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 2.832344 secs (3702149 bytes/sec) % dd if=/dev/zero of=/media/truecrypt1/zero bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 2.755431 secs (3805488 bytes/sec) % dd if=/dev/zero of=/media/truecrypt1/zero bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 2.717497 secs (3858609 bytes/sec)
カーネルフリーズする時はこんな感じ。
% sudo /usr/local/etc/rc.d/fusefs forcestart
（TrueCrypt のマウント操作）
% sudo mount -u -o -l,-L=ja_JP.eucJP /media/truecrypt1
% mount
（一部省略）
/dev/ad0s2f on /home (ufs, local, noatime, soft-updates) ← truecrypt のコンテナが置いてあるファイルシステムは soft-update な非同期モード。
/dev/fuse0 on /tmp/.truecrypt_aux_mnt1 (fusefs, local, synchronous) ← fusefs は同期モードになっているのに。
/dev/md1 on /media/truecrypt1 (msdosfs, local) ← truecrypt が非同期モードのまま。
% dd if=/dev/zero of=/media/truecrypt1/zero bs=1m count=10
（1MiB くらい書き込んだ頃に、カーネル空間でデッドロック起こして帰ってこない）
その時の様子を printf() なデバッガで追跡した時の様子。
＃ 1MiB超を 2KiB毎に書き込む様子を kdb で追っかけるのはつらいので。
TrueCrypt 側の処理の流れ：
原作の TrueCrypt を改造して、pwrite() 直後に明示的に fsync() する様に変更してある。
（省略）
fuse_service_write() CheckAccessRights()...
fuse_service_write() CheckAccessRights()
fuse_service_write() WriteVolumeSectors(0x85ad040,512,2914304)...
WriteVolumeSectors()
WriteVolumeSectors() WriteSectors()...
WriteSectors()
WriteSectors() if 512,3045376
WriteSectors() encBuf...
WriteSectors() encBuf.CopyFrom()...
WriteSectors() encBuf.CopyFrom()
WriteSectors() EncryptSectors()...
WriteSectors() EncryptSectors()
WriteSectors() WriteAt()...
WriteAt(4,512,3045376)
WriteAt() pwrite() done.
WriteAt() done.
WriteSectors() WriteAt()
WriteSectors() done.
WriteVolumeSectors() WriteSectors()
fuse_service_write() WriteVolumeSectors(0x85ad040,512,2914816)...
WriteVolumeSectors()
WriteVolumeSectors() WriteSectors()...
WriteSectors()
WriteSectors() if 512,3045888
WriteSectors() encBuf...
WriteSectors() encBuf.CopyFrom()...
WriteSectors() encBuf.CopyFrom()
WriteSectors() EncryptSectors()...
WriteSectors() EncryptSectors()
WriteSectors() WriteAt()...
WriteAt(4,512,3045888)
WriteAt() pwrite() done.
WriteAt() done.
WriteSectors() WriteAt()
WriteSectors() done.
WriteVolumeSectors() WriteSectors()
fuse_service_write() WriteVolumeSectors()
fuse_service_write() CheckAccessRights()...
fuse_service_write() CheckAccessRights()
fuse_service_write() WriteVolumeSectors(0x85ad040,512,2915328)...
WriteVolumeSectors() WriteSectors()...
WriteSectors()
WriteSectors() if 512,3046400
WriteSectors() encBuf...
WriteSectors() encBuf.CopyFrom()...
WriteSectors() encBuf.CopyFrom()
WriteSectors() EncryptSectors()...
WriteSectors() EncryptSectors()
WriteSectors() WriteAt()...
WriteAt(4,512,3046400)
WriteAt() pwrite() done.
← ここで fsync() しているのだが、カーネル空間内でデッドロックを起こして帰ってこない。
カーネル内の処理の流れ：
bufwrite(0xd8fc1098,0xc59b3dd0) CTR3()... ← dd による仮想ファイルシステムへの書き込み
bufwrite() CTR3(), if...
bufwrite() if 2...
bufwrite() if 3...
bufwrite() bundirty()...
bufwrite() bundirty(), bufobj_wref()...
bufwrite() bufobj_wref(), vfs_busy_pages()...
bufwrite() vfs_busy_pages(), atomic_add_int()...
bufwrite() atomic_add_int(), if...
bufwrite() atomic_add_int(), if 2...
bufwrite() if 2, dbtob()...
bufwrite() dbtob(), bstrategy()...
bufwrite() bstrategy(), if...
bufwrite() if, 2...
bufwrite() if, 2, waitrunningbufspace()...
bufwrite() done
bufwrite(0xd8fc11e0,0xc59b3dd0) CTR3()... ← dd による仮想ファイルシステムへの書き込み
bufwrite() CTR3(), if...
bufwrite() if 2...
bufwrite() if 3...
bufwrite() bundirty()...
bufwrite() bundirty(), bufobj_wref()...
bufwrite() bufobj_wref(), vfs_busy_pages()...
bufwrite() vfs_busy_pages(), atomic_add_int()...
bufwrite() atomic_add_int(), if...
bufwrite() atomic_add_int(), if 2...
bufwrite() if 2, dbtob()...
bufwrite() dbtob(), bstrategy()...
bufwrite() bstrategy(), if...
bufwrite() if, 2...
bufwrite() if, 2, waitrunningbufspace()... ← vfs.bufspace を全て消費したので、空きが出来るのを待つ。
fsync() AUDIT_ARG()... ← vfs.bufspace の空きが尽きたので、空きを作る為に fsync() の実体が実行される。
fsync() AUDIT_ARG(), getvnode()...
fsync() getvnode(), VFS_LOCK_GIANT()...
fsync() VFS_LOCK_GIANT(), vn_start_write()...
fsync() vn_start_write(), vn_lock()...
fsync() vn_lock(), AUDIT_ARG()...
fsync() AUDIT_ARG(),
fsync() AUDIT_ARG(), VM_OBJECT_LOCK()...
fsync() VM_OBJECT_LOCK(), vm_object_page_clean()...
fsync() vm_object_page_clean(), VM_OBJECT_UNLOCK()...
fsync() VM_OBJECT_UNLOCK(),
fsync() ,VOP_FSYNC():0xc595caa0,0xc59ad180...
ffs_fsync() ffs_syncvnode()...
ffs_syncvnode() ...
ffs_syncvnode() lblkno(), ...
ffs_syncvnode() 1, splbio()...
ffs_syncvnode() splbio(), VI_LOCK(...
ffs_syncvnode() VI_LOCK(), ...
ffs_syncvnode() loop, TAILQ_FOREACH()...
ffs_syncvnode() TAILQ_FOREACH(), TAILQ_FOREACH_SAFE()...
ffs_syncvnode() TAILQ_FOREACH_SAFE(), 1...
ffs_syncvnode() TAILQ_FOREACH_SAFE(), 2...
ffs_syncvnode() TAILQ_FOREACH_SAFE(), 3...
ffs_syncvnode() TAILQ_FOREACH_SAFE(), VI_UNLOCK()...
ffs_syncvnode() VI_UNLOCK(), if...
ffs_syncvnode() if, if 1...
ffs_syncvnode() if, if 2:0xd8fefe20...
ffs_syncvnode() if 2, bremfree()...
ffs_syncvnode() if 2, bremfree(), splx()...
ffs_syncvnode() if2, splx(), bawrite:0xc0723cf0(0xd8fefe20)...
bufwrite(0xd8fefe20,0xc595caa0) CTR3()... ← 仮想ファイルシステムに書き込まれた内容を実ディスクに書き出す処理を行う。
bufwrite() CTR3(), if...
bufwrite() if 2...
bufwrite() if 3...
bufwrite() bundirty()...
bufwrite() bundirty(), bufobj_wref()...
bufwrite() bufobj_wref(), vfs_busy_pages()...
bufwrite() vfs_busy_pages(), atomic_add_int()...
bufwrite() atomic_add_int(), if...
bufwrite() atomic_add_int(), if 2...
bufwrite() if 2, dbtob()...
bufwrite() dbtob(), bstrategy()...
bufwrite() bstrategy(), if...
bufwrite() if, 2...
bufwrite() if, 2, waitrunningbufspace()... ← vfs.bufspace の空きが無いので、空きが出来るのを待つ……。
バッファの空きを食いつぶした物が、この sync を発生させた２段上位側にいる TrueCrypt の仮想ファイルシステムなので、この sync から戻らないと、空きが出来ない。
この sync の１段上位側にいる fusefs は同期モードに設定されているので、下位側と上位側の処理の順序の入れ替えが禁止される。
この sync では、空きが出来るまで戻る事ができない。
つまり、デッドロック。
と、言う訳で、 ファイルシステムを多段重ねにする時は、 同期モードと非同期モードを混ぜない様に注意しましょう。
…… GNU/Linux や MacOS X だと、この問題は起きないのかな？。 GNU/Linux の場合、デフォルトは非同期モードだった筈。 カーネルの実装が違うから、各々のカーネルソースを読まないと、 問題無いのか問題有るのかは判らないけれど。 もしかして fusefs も非同期モードになっているのだろうか？。
追記： TrueCrypt にも、 slashdot.jp - 2009年03月14日 6時18分 (#1530766) の問題が有る。 TrueCrypt は仮想ファイルシステムを提供するだけなので、 （提供した仮想ファイルシステムへの書き込みタイミングに関しては、 どうする事もできない） 仮想ファイルシステムへアクセスするアプリケーションによっては、 #1530766 の問題が起きる。 また、 コンテナへの書き込みはデータ I/O のみであり、 何もしなければ書き込みタイミングは OS に完全依存となる （TrueCrypt のコンテナ書き込み部分のソースコードには fsync() も sync() も入っておらず、何もしていなかった） ので、#1530766 の件に該当する。 実際、仮想ファイルシステムのディレクトリエントリの、 コンテナへの書き込みは、 もろに FreeBSD syncer の30秒毎のタイミングで行われていた。 ので、 重要なデータの記録に TrueCrypt を使うならば、 上位から下位まで全て同期モードでマウントした方が良いと思う。 コンテナファイルを置く側のファイルシステムは、 GNU/Linux で言う所の dirsync 指定では代替にならない （仮想ファイルシステム側のメタデータも、コンテナ側では通常データになる為）。
備考： FreeBSD のデフォルトでは、 「メタデータは同期 ＆ データは非同期」になる。 GNU/Linux で言う所の dirsync に近い。 GNU/Linux のデフォルトでは、 「メタデータもデータも非同期」になる。 FreeBSD で言う所の async になる。
改正貸金業法。 既発行のクレジットカードの限度額も、実質的に改変されるらしい。
I18N(Internationalization) GearHead。 Sun,24 Feb,2008〜 Sat,01 Mar,2008（初版）、 Sun,02 Mar,2008〜 Sun,09 Mar,2008（FreePascal上での、iconv, SDL, バッファオーバー／アンダーランの各問題）、 Tue,11 Mar,2008（FreePascal で多バイト文字？を処理する問題）、 Fri,21 Mar,2008（UNIX系対応安定版になると思っていたリリース）、 Sun,27 Apr,2008（国際化版の最初のリリース）、 Sun,11 May,2008（一時は安定版になると思っていたリリース）、 の続き。 ようやく、安定版に到達したかもしれない。 １年と１ヶ月かかってしまったのか……。
GNU libc 発祥の getopt_long()。 以前は getopt_long() は GNU libc 専用関数で、 BSD系で使用したい場合はパッケージの libgnugetopt を入れる必要があった。 でも、 NetBSD 1.5（2000年12月）, FreeBSD 5.0 （2003年１月）, OpenBSD 3.3（2003年５月）, から BSD系にも輸入され パッケージ無しで普通に使える様になり、 パッケージで提供される getopt_long() と重複している移行期間だった。 最近半年位で、 パッケージの libgnugetopt がインストールされていないのが普通になり始め、 ネイティブ？の getopt_long() に切り替えた方が良くなってきていた。 で、うっかり従来通り libgnugetopt が有るつもりで作業してしまう。 しかも、あらかじめ configure.in に仕込んでおいた、 getopt_long() がネイティブの libc で提供されているのか オプションの libgnugetopt で提供されているのか、 の判定処理にバグがあり、判定にしくじっていた。 そして今は亡き libgnugetopt の getopt_long() を使おうとしてしまい リンクエラー。
ところで BSD 発祥の strlcpy(), strlcat(), mergesort() 辺りが posix とか GNU/Linux とかに輸入されるのはいつですか。 いちいち configure.in で識別処理書いて 代替関数を同梱しておくのは面倒なんですが。 まぁ、GNU libc のコアメンバーが、 「strlcpy/strlcat は設計思想が間違っているので導入しない」 （意訳。原文では、もっと酷い罵倒になっている） みたいな感じの事を言っている限り、GNU libc には入らないだろうけれど。 Linux カーネル単体では、もう輸入済みだった筈。 glib（GTK GLib）でも、輸入済み。 各ディストリビューションでは、どうなのだろう。 snprintf() で同等の処理をした方がエラー検査が厳密にできる、 のは、その通りなのだけれども。 上層部のくだらん政治争いで割を食うのはいつも末端。
ゆうちょのキャッシュカード。 Suica 付きができるらしい。 ゆうちょICキャッシュカード/ゆうちょICキャッシュカードEdy が発行済の場合、切り替えになって、手数料￥1,000-取られるらしい。
↑ ja.wikipedia.org のゆうちょのキャッシュカードの項目を見てみたら、 キャッシュカードのデザインの説明が間違っているのを見つけてしまった。 正しくは、 「旧郵政公社時代のキャッシュカードのデザインは、 通常郵便貯金は緑と白と薄緑で描かれたデザイン（たぶん）で、 通常貯蓄貯金は灰色（銀色？）地に黒文字のデザインだった。」 通常貯蓄貯金の通帳も、 灰色（銀色？）地に黒文字と、キャッシュカードと同じデザインだった。 総務省管轄になった頃か民営化後かその辺りで（たぶん）、 キャッシュカードは通常郵便貯金も通常貯蓄貯金も同じデザインになった。 通帳のみ、背の帯の色が違う。
↑ wikipedia.org のシステムに関して気になったので、調べてみた。 完全オープンで誰でも編集出来る、 イメージで言うと cvs や svn と同様の感じで データを保持しているシステムらしい。 嘘だろうが本当だろうが、扇動だろうが握り潰された真実だろうが、 何でも書けると言う事らしい。 件は、 「2007年10月24日 (水) 12:51 220.219.61.216 (会話) (62,139 バイト) (→キャッシュカード) 」 の人が、間違いを書いてしまった後、誰も訂正を入れていない事になるらしい。
もっとも、 wikipedia.org は、 正しい記事と間違った記事、嘘と本当が、ごちゃまぜだ、 とは、以前から聞いていたけれど。
OS 問わず、
非同期書き込み／遅延書き込み／遅延アロケーション 系を
実装しているファイルシステムに於いて、
データがぶっ壊れる場合がある問題、
「ubuntu-9.04-beta Bug #317781: Ext4 data loss（原著：英語。
この URL は http://tinyurl.com/cqmcvb と表記される事もあるらしい）」、
「slashdot.jp - BonTf (8325) : 2009年03月14日 6時18分 (#1530766)（日本語での解説）」、
要約すると、
「それはファイルシステム／カーネル／OSなどの仕様／バグでは無くて、
アプリケーションのバグだろ」（おもいっきり意訳）。
http://ja.wikipedia.org/wiki/XFS の 2009年３月23日(月) 版によると、
この件は、GNU/Linux における XFS の実装に際して、
2004年７月と 2006年３月に既に問題提起されていたらしい。
Sat,26 Sep,2009に関連。
Anthy のバグでは無くて仕様です。
Anthy の学習データ last-record* に関しては、↑の件の (2) が直撃。
Anthy の個人辞書 private_dict_*.tt に関してはあやふやだが、
↑の件の (1) と同レベルの状態だと思った、たぶん。
↑の件では OS のクラッシュにより発症するが、
Anthy が行っている実装の仕方の場合には、
Anthy や IM-module やアプリケーションのクラッシュや強制終了でも発症する。
実際にこれに類似するトラブルで last-record* を壊した事が有るけれども、
「重要ならバックアップを取ってあるよね」とか、
「重要ならファイルシステムを同期モードにしているよね」とか、
「クラッシュが起きなければ問題無いよね」とか思ったので、
私が遭遇した程度のデータ破損なら、
SIGSEGV/SUGBUS を起こさずに続行できるかもしれない
程度のパッチを書いて送って、
あとは放置していた。
でも、こんなにおおごととは思っていなかった。
でも、やっぱり、
「重要ならバックアップを取ってある」とか、
「重要なら -o sync している」とか、
「クラッシュが起きなければ問題無い」は、
前提にして良いのだよね？。
となると、かな漢字変換ごときでは、
この件に関してどうこうする程の重要性は無いよね？。
↑ ついでに。
Anthy はシングルタスクでのみ運用されると言う前提で
設計および製作されている為、
env GTK_IM_MODULE=xim QT_IM_MODULE=xim 以外にした時（たぶん）に
複数のウィンドウでかな漢字変換を使うと、
↓の対策を行ったとしても、
レーシングを起こして学習データをぶっ壊す場合が有る
設計上のバグ……ではなくて仕様です……がある。
この問題を治すには、
env GTK_IM_MODULE=xim QT_IM_MODULE=xim 限定で使用するか
（たぶん xim側でタスクの調停をしてくれるので、
シングルタスクと同等になる筈）、
複数のウィンドウでかな漢字変換を使わない様に注意するか、
さもなければ、
マルチタスク動作する事を前提に抜本的に設計からやり直さなければならない。
マルチタスク対応の為に設計変更するなら、
データ破損に対するフェイルセーフ／フォールトトレラントの設計も、
ちゃんと行うべきで。
そうなると、データ構造や実装などで、
GNU/Linux/i386専用に作った後に無理に汎用的に使っている部分も、
最初から OS やアーキテクチャに依存しない様に設計し直した方が良いよね。
……それって、Anthy 捨てて全再設計、だよね。
あと、
「Anthy がセキュア」とか
「Anthy は組込系へも移植できる」と言う主張は、
未踏の予算を取るための方便だよね。
注意：
Anthy が悪いと言っている訳ではありません。
↑*2 取り敢えず、忘れても思い出せる様に結論部分だけ引用。
3.a) open and read file ~/.kde/foo/bar/baz
3.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
3.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
3.d) fsync(fd) --- and check the error return from the fsync
3.e) close(fd)
3.f) link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
3.g) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
仕様上は、これで万事解決らしい。
↑ だがしかし、GNU/Linux では、 slashdot.jp - okky (2487) : 2009年03月14日 19時15分 (#1531001) と言う問題が有るので「これでも駄目」（意訳）で、 「ファイルシステムを同期書き込みにする以外、現時点では解決策は無い」（意訳） らしい。 「らすと２号」は UNIX Magazine 2006年３月号〜４月号の事だった。
↑ GNU/Linux では、sync; sync; sync; すら信用できないらしい。 slashdot.jp - saitoh (10803) : 2009年03月14日 22時08分 (#1531049) 勘弁して……。
そう言えば、この問題は TrueCrypt にも該当するな。 仮想ファイルシステム側と、コンテナファイル側と、両方で。 「安全」にしたければ、 上位から下位まで全て同期モードに設定し直す以外、手は無い。 しかもコンテナ側は dirsync では駄目で sync にする必要があるし。
マウス、その１。 某99 で買った 代理店がアクロスの ￥980- の安物 ５ボタン DPI 切り替え付き 光学マウスの ホイールが、半年位前から不調。 回転がやたら固い。 無理に回そうとすると、思わずクリックしてしまう。 意地になって暫く使っていると、軟らかくなる。 でもまた翌日には固くなっている。 こちらのマウスは、DPI 切り替えした時の感度が、そこそこ適切で、 追加２ボタンがホイールチルトでも操作できるので （ちょっと誤操作しやすいけれど）、 わりと好みなのだが。
マウス、その２。 某99 で買った 代理店がアクロスの ￥1,280- の安物 ５ボタン DPI 切り替え付き 光学マウスの ホイールが不調になった。 特定の箇所だけ（多分、全周で１ヶ所だけ）、 １ノッチ回しただけで、パルスが３発出ている。 で、一旦バラして組み立てなおすと、一旦は治る。 でも、数日後にまた再発する。 操作したのと違う挙動をされるのが、 こんなにストレスが溜まるとは思わなかった。 こちらのマウスは、 DPI 切り替えした時の感度は滅茶苦茶で使い物にならないが、 追加２ボタンは、 横に付いていて押しやすく且つ誤操作しにくいので、 ボタンの配置は好きなのだが。
銀河英雄伝説 サントラ BOX、 自由惑星同盟サイド 中古￥12,000-（新品定価￥15,000-）、 銀河帝国サイド 中古￥14,000-（新品定価￥18,000-）。 中古なのに、新品買った方が良い様な値段だ……。 限定生産らしい……。 StarChild の曲目一覧を見ると、 「銀河帝国軍軍楽曲」と「自由惑星同盟国歌」が入っていない。 でも、販売店の曲目一覧を見ると、入っている……。 と思ったら、「帝国のテーマ」と「同盟のテーマ」が、それらしい。 外伝も含めて全部入っているっぽい。
alt-depgraph。
「ぜんていにして」 |前提に|して| 毎度お馴染みの（助詞）＋（補助動詞）は１文節にするべきか２文節にするべきか、の問題。 「へんこうにより」 |変更に|より| 毎度お馴染みの（助詞）＋（補助動詞）は１文節にするべきか２文節にするべきか、の問題か？。に関して、 何処から手を付けたら良いのか、考えあぐねて積んだままになっていたら、 もう、詳細な解説が出ていました。 「vagus氏 - 丘の道を登り - 2009年03月21日 - 色々」。 有り難うございます。
↑ alt-depgraph、昨日の続き。
現状のやり方が無難で妥当かと思います。
考え方や好みが多様なのはその通りですが、
現状は適切かつ万人向けに無難だと思います。
１文節で出すぎのきらいがあるのは同感ですが
（なので、１文節にすべきか２文節にすべきかで迷っていた）。
それらの事が負荷になってしまっても悪いですし。
ボツネタ：
補助動詞／補助形容詞／形式名詞は全て区切ってしまう事にして。
last-record0_default.bin みたいなデータベースを作って、
『「*してくれて*」の場合、「くれて」の部分で１文節作り、表記は「くれて」』
『「*してきた*」の場合、「きた」の部分で１文節作り、表記は「きた」』
『「*したとき*」の場合、「とき」の部分で１文節作り、表記は「時」』
の様なデータを予め仕込んでおく（但し、通常の学習の方を優先する）。
●メリット
・「くる/来る」や「いく/行く」や「なる／鳴る」などで、区切り直す必要が無い（元々区切ってある）。
・補助動詞／補助形容詞／形式名詞の漢字表記も登録できる。
・文節が短くなる。ので、学習データ量が小さくなる。
→ 文節が短くなると、学習のパターンが減るので。
・単純に depgraph を区切った場合よりは、誤変換が減るかもしれない（自信無し）。
・それに近い機能は、patch13 の途中から実装されている。
→ 例えば、「|近い|時|」（|ちかい|とき|）と学習させると「い|時|」（い|とき|）も学習され、
「とおいとき」を変換した場合にその学習が適用される、筈。
……、誤適用が怖かったので、標準では無効にしてあった。
ENABLE_OCHAIRE2_WITHOUT_INDEP
ENABLE_OCHAIRE2_WITHOUT_INDEP_WITHOUT_DEP
・変換する時に、区切って変換するべきか区切らずに変換するべきか、迷わずに済む。
●デメリット
・原作版の Anthy で使用する事ができない alt-depgraph およびデータベースになる。
・「*してる」や「*したる」は、やっぱり分割できない。
・誰がそのデータベース構築の労力を払うのだ？
・登録できるのは、読み１パターンに付き変換結果１パターンのみ。
・depgraph の様に、遷移が書けないので、全パターンを列挙しなければならなくなる。
・現状の実装では品詞を見る事ができないので、誤適用が増える。
・文節が短くなるので、誤適用が増える。
→ 文節が短くなると、適用できるか否かの判定に使える部分が狭くなるので。
・そもそもコーパスの機能や量や内容を改善した方が（略）
・１文節にならないのは辞書が悪いからだ、と誤解する人が増えるかも。
……。区切った場合の問題点が、全然解決できないどころか増えた。駄目だ。
品詞（単語）の漏れ？、 anthy-9100h + alt-cannadic-090308 + alt-depgraph-090308。
自立語「ある程度」に、付属語が付いたり付かなかったりする。 付く場合： 「あるていどで」 |ある程度で| 「あるていどなら」 |ある程度なら| 「あるていどだと」 |ある程度だと| 付かない場合： 「あるていどは」 |ある程度|は| 「あるていどの」 |ある程度|の| 「あるていどからは」 |ある程度|からは| 「あるていどにて」 |ある程度|にて| 類似の自立語の状況： gcanna.ctd:3284:あのていど #T35*200 あの程度 gcanna.ctd:4535:あるていど #F14*400 ある程度 gcanna.ctd:44080:このていど #T35*250 この程度 gcanna.ctd:69645:そのていど #T35*250 その程度 gcanna.ctd:80510:ていど #T15*300 程度 #T15*200 ていど gcanna.ctd:86675:どうていど #T15*200 同程度 gcanna.ctd:87356:どのていど #T35*250 どの程度 gcannaf.ctd:868:ていど #JSSUC*20 程度 「ある程度」だけ副詞で、あとは名詞。 備考： 「ある程度」 ＝ 「或る程度」 結論： 「あるていど #F14*400 ある程度」 は、 「あるていど #F14*400 ある程度 #T35*400 ある程度」 にするべきかも？ ただ、T35 にすると、一部の格助詞の接続にて変な言葉になるかもしれない。
↑ Sun,19 Apr,2009 追記：
「vagus氏 - 丘の道を登り - 2009年04月13日 - 「未完成らしい」他 【追記】4/13」
に解説が来ていました。
「ある程度」は alt-cannadic で F14 に修正した物で、
「[こそあど]の程度」が T35 なのは cannadic にあった物がそのまま残っているそうです。
2GB の SD系統のメモリが￥600前後で買えるご時世か……。
バトルテックリプレイ１ 魔女たちの饗宴 ￥105-。 状態良好。 カバーの汚れが酷かった バトルテックがよくわかる本 ￥105- は無くなっていた。
シリーズ全部揃っていた愚連隊、飛び飛びであったリプレイ、は、 全て無くなっていた。
娘フロ 中古￥2,250- で６枚、娘トラ 中古￥1,950- で３枚。 それはもはや不良在庫の様な気が……。
堀内 孝雄、君のひとみは10000ボルト、1978.8.5 らしい。 はぐれ刑事純情派 や さすらい刑事旅情編 の主題歌もかんでいたらしい。
矢野 顕子、春咲小紅、1981.2.1 らしい。 春先小町、春先小紅、春咲小町、春色小紅、春色小町、は、間違い。
DNS。 38.229.0.10 から「query: recursion-test.cymru.com IN A +」 とか言うのが来ていた。 38.229.0.10 は bahamut.iad01.cymru.com らしい。 recursion-test.cymru.com は 38.229.0.10 で、
recursion-test.cymru.com. 10800 IN TXT "Contact team-cymru <at> cymru.com"らしい。「 <at> 」のところは原文だと「@」。 Open Recursive DNS 探して、見つけたら警告しているのだろうか？。
また DNS。 59.140.20.3 から「query: www.example.com IN A +」 とか言うのが、 10秒あけて、１分あけて、10秒あけて、１分あけて、 の繰り返しで、のべ８回来ていた。 59.140.20.3 は KHP059140020003.ppp-bb.dion.ne.jp ……、 国内プロバイダかい。 ボットか？。
現実逃避で、かなり古いネタ。 Sat,05 Jan,2008に関連。
BSD Magazine 2001年４月１日号 より引用
＃ タイトル
新世紀覇王獲素伝説（しんせいきはおうえすでんせつ）
美獲素手の拳（びぃえすでぃのけん）
作：無論損
画：弥生すみれ
＃ 登場人物、元ネタ
テオシロウ : ケンシロウ、*BSD三兄弟の末っ子 OpenBSD、その創始者 Theo（テオ） de Raadt
ネットキ : トキ、*BSD三兄弟の次兄 NetBSD の前半の発音
フリオウ : ラオウ、*BSD三兄弟の長兄 FreeBSD の前半の発音
レッド : レイ？、Red Hat Linux の前半の発音
聖帝カレル : サウザー？、Corel（コーレル）社？
1999〜2000年頃、Linux方面の企業 Corel が株価が急上昇、
Inprise を買収して Corel の CEO が Inprise の CEO に就いたらしい。
その後、Corel の株価は急降下、GNU/Linux から手を引いて業績回復を図ったらしいがうまくいかず、
2000年に MS に買収されたらしい。
覇王獲素 : 覇王 と OS の掛け言葉。
海軍用OS : MS-WindowsNT。
米海軍のイージス艦だか何だかで使っていたヤツがコケて
まともに航行できなくなった？漂流した？らしい。
美獲素手 : BSD
ペンギン : Linux 2 のマスコット
理汝駆素 : Linux
理汝駆素 六聖拳 : どのディストリビューションを指しているのかは不明
理汝駆素 赤帽拳 : Red Hat GNU/Linux
フリオウが乗っている亀 : FreeBSD KAME Project（IPv6, IPsec の開発プロジェクト）
理汝駆素加酷拳奥義 死射雄追放翔 : GNU/Linux業界で起きた過酷な人事異動、CEO 追放
美獲素手神拳秘奥義 阿厨意図 : BSD License の究極表現である As Is
美獲素手 有情猛撃打 : 北斗有情猛翔破？
マック : Macintosh と McDonalds
Ｘ（テン） : Mac OS X
今なら平日１２０円 : 当時の McDonalds の Hamburger の値段
＃ 語り
某国の某海軍が採用した某ＯＳの暴走によって引き起こされた核戦争により、
地球上のあらゆる生命は絶滅したかにみえた……
しかし、人類は生きていた！
＃ レッドがペンギン背負って登場
＃ 通りすがりの？爺さん曰く
まるで水中を行くペンギンのような……
理汝駆素聖拳（りなくすせいけん）
＃ 通りすがりの？爺さん曰く
この世に２つの覇王獲素（はおうえす）あり、
美獲素手（びぃえすでぃ）と理汝駆素（りなくす）。
経絡秘孔を突き、ソースを
送り込んで内部よりの破壊
を引き起こす美獲素手神
拳を陰とするならば、外部
からソースを用いて破壊す
る理汝駆素聖拳は陽！
＃ レッド曰く
理汝駆素は陽拳ゆえ、
さまざまに分派し、
今では理汝駆素六聖
拳を頂点に１０８のデ
ィストリビューション
が存在している。
uim-anthy の悪相性修正。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
.uim をカスタマイズして、
アルファベットや記号類を直接（変換無しで）入力できる様にし、
直接入力して変換した場合、
Anthy が勝手に逆変換かけてしまうらしい。
「さいようしたぼうＯＳが」を入力すると、
「ＯＳ」の部分を拡大解釈して逆変換を始めてしまい、
「したぼう」が「_」になり、
「さいよう_ＯＳが」のよみでしか変換できなくなった。
これは困るので、
環境設定
#ANTHY_RECONVERT_AUTO true #ANTHY_RECONVERT_DISABLE true #ANTHY_RECONVERT_ALWAYS trueで変更できる様にした。
メモリが足らないかもしれない事態。 しかも DDR1-PC3200-1GiB * 2。 できれば DDR1-PC3200-2GiB * 2 が良いのだが、そんな製品は無いらしい。 今時 DDR1 を 2GiB ぶん買おうとすると、 正規ブランド品を購入すると２万円するし。 バルクでも１万円するし。
調べてみると、４〜５万円出せば、 Athlon64 X2 5000〜5500+ (2.5〜3.0GHz) クラス ／ Core2Duo 2.5〜3.0GHz クラス、 メモリ 4GiB、 くらいの計算機が買えるご時世らしい。 そう考えると、案外１万円は許容範囲かも知れない。 が、２万円はちょっと、というくらいかも。
最近は DDR3 まであるとかで、浦島状態なので調べてみた。 Intel系だと、普通に DDR2 とか DDR3 とかに対応しているらしい。 でも、 DDR2 の中速クラスのデュアルチャンネルを使うと、 バスの帯域を全て使い切ってしまい、 それ以上速いメモリを使っても意味が無いらしい。 DDR3 に至っては、 DDR2 の中速クラスのデュアルチャンネルと同等の速度しか出ないらしい。 DDR3 のトリプルチャンネルだと、Core i7 でないと全く無意味らしい。 AMD系だと、 DDR2 なら最高速モデルのデュアルチャンネルでも速度を出し切れるし、 DDR3 でも中速クラスのデュアルチャンネルまでは速度を出し切れるらしい。 でも、一般モデルの SocketAM2 だと DDR2 しか使えない。 最新モデルの SocketAM3 で、 ようやく DDR3 が使えるモデルも有るには有る、と言う状態らしい。 性能を出し切れない方が DDR3 に対応していて、 性能を出し切れる方が DDR3 に対応していない……。
途中駅混雑と駅でのトラブルにより、10分遅れ。 しかも、途中接続駅にて、相手方路線にて接続待ち無し。 しかもそれが終電。 どうしろと……。
Hackaholic が復活していた。 DoS で強制停止させられていたらしい。
sshfs on FreeBSD、 sshfs のホストは OpenBSD でクライアントは FreeBSD。
% sshfs -p ***** -o uid=***** -o gid=***** -o allow_other hoge@example.jp:/home/hoge % sudo mount_fusefs /dev/fuse0 /mntとかやると、マウントまでは通るのだが、 一般ユーザでアクセスすると Permission denied になる、 でも特権ユーザでアクセスすると普通に見える。 今回は、vfs.usermount=1 は、事前にちゃんとやった。 結局、/usr/local/sbin/sshfs を 04555 にしてから、
% sshfs -p ***** -o uid=***** -o gid=***** -o allow_other hoge@example.jp:/home/hoge /mntしたら、一般ユーザでもアクセスできた。 mount を行ったユーザしかアクセスできないので、 sudo で mount すると root しかアクセスできなくなるらしい。 ホストを GNU/Linux系にしてクライアントを FreeBSD系にする場合、 文字コードを変換しないとまずいらしい。
$ sshfs user@host:/dir /mountpoint -o modules=iconv,from_code=UTF-8,to_code=EUC-JP引用元： 「屑俺日記 - 2008-07-24(Thu) はれ? - ☆ sshfsでコード変換」 通信とプロセスを見た感じだと、 実体は ssh の sftp らしい。 いくら普通のファイルシステムに見えると言っても、 実体は ssh なので、diff -r とかやると、やっぱり遅い。 あと、なんかたまに回線切れて、 切れているのに応答待ちにはまって固まっている事がある。 取り敢えず、それなりに新しめの OpenSSH ならば、 サーバ側で
ClientAliveInterval 180するか、クライアント側で
ServerAliveInterval 180すれば、回線は持続されるらしい……、 ……既に指定してあるのに、それでも切れた……。
OpenBSD のシグナルハンドラにおける非シグナルセーフ。 OpenBSD 上で、 シグナル処理内で非シグナルセーフな関数を呼び出したら、 abort() された。 まぁ、承知して非シグナルセーフな関数を呼び出していたのだから、 構わないのだけれど。 タコな作りのソフトウェアで引っかかりそうな気がした。
工画堂の PD1。 店頭に並んでいない。
バックアップメディアの話、 Sat,14 Mar,2009の続き。 DVD-RAM 国産 ２倍速／２〜３倍速 の価格。 長期データ保存用なので、国産限定 ＆ ３倍速未満限定。 2008年現在では、国産は Panasonic のみらしい？（未確認）。
祖父 ビック 淀 片面 4.7GB LM-AF120LJ １枚 CPRM ￥480-48P ￥480-48P LM-AB120LJ １枚 殻付 CPRM ￥580-58P ￥580-58P LM-HC47L １枚 ￥490-49P ￥490-49P ￥490-49P LM-HB47LA １枚 殻付 ￥580-58P ￥580-58P LM-HB47LS3A ３枚 殻付 ３色 ￥1,680-168P ￥1,680-168P LM-AF120LW5 ５枚 CPRM ￥1,270-127P ￥1,279-127P ￥1,280-128P LM-AF120LJ5 ５枚 CPRM ￥1,279-127P ￥1,280-128P LM-AF120LC5 ５枚 ５色 CPRM ￥1,270-127P ￥1,279-127P ￥1,280-128P LM-HC47LW5 ５枚 ￥1,380-138P ￥1,380-138P ツクモ￥1,380-14P LM-HL47LW5 ５枚 ￥1,380-138P LM-HC47LS5 ５枚 ５色 ￥1,380-138P ￥1,380-138P LM-AF120L10Y 10枚 CPRM ハードコート 淀専用 ￥1,780-178P LM-AF120LW10 10枚 CPRM ￥1,780-???P ￥1,880-188P ￥2,280-228P LM-AF120LJ10 10枚 CPRM ￥1,580-???P ￥1,880-188P ￥2,280-228P LM-AF120L20W 20枚 CPRM ハード￥2,480-75P ￥2,480-74P ￥3,580-358P LM-AS120L20Y 20枚 CPRM ハードコート 淀専用 ￥2,980-298P（個別ケース無） LM-AF120LJ20 20枚 CPRM ￥4,080-408P ￥3,680-368P ￥4,080-408P 両面 9.4GB LM-AD240LJ １枚 殻付 CPRM ￥880-88P ￥880-88P ￥880-88P LM-HB94L １枚 殻付 ￥1,129-113P ￥880-88P LM-AD240LJ3 ３枚 殻付 CPRM ￥2,180-218P ￥2,180-218P LM-HB94LP3 ３枚 殻付 ￥2,590-259P ￥2,180-218P ￥2,180-218P ドスパラ￥1,780- ツクモ￥2,180-22P LM-AD240LJ5 ５枚 殻付 CPRM ￥3,280-328P ￥2,980-447P ￥3,280-328P LW がプリンタ対応、LJ がマジック書き対応、LC がカラー各色、らしい。あとは dvdisaster の使い方……、dvdisaster だと UDF は駄目か。 ファイルにエラー訂正符号を付加できるソフトが欲しい。
DVD のハードコートって何だろう。 検索してみたら、特許の開示が引っかかった。 通常の基材だと機械的強度が弱いらしい。 かといってハードコート膜を形成すると基盤が反りやすくなってしまうらしい。 じゃぁと言って反らない様にハードコート膜を薄くすると ハードコートの意味が無いくらい薄くなってしまうらしい。 その辺りのハードコート材の成分や形成に関して特許が有るらしい。 ……出願人がずばり松下電器産業だ……。 2000年出願、2002年開示、らしい。
バックアップメディアの話は Sun,29 Mar,2009に続く。
一撃殺虫！！ホイホイさん、古本在庫整理で￥84-、但しキズ有り。 ……ホイホイさん LEGACY とかいう新連載が始まっているらしい。 しかも連載始めてすぐに落としそうになったらしい。
ちょっと変な付属語、 anthy-9100h + alt-cannadic-090308 + alt-depgraph-090308 の話。
「|店頭にならんでいなかった|」（てんとうにならんでいなかった）が１文節になる。 たぶん「#T35 + に + な + らん + で + いな + か + った」らしい。 音便無しにすると「|店頭にならなくていなかった|」で１文節になる。 「|店頭にならんでいない|」、「|店頭にならなくていない|」とかも１文節になる。
Sun,05 Apr,2009 追記：
alt-depgraph-090402版で、対応されていました。有り難うございます
娘フロ ￥1,380- で４枚、 娘トラ ￥1,580- で１枚、 娘トラ（盤面にキズ）￥1,580- から２割引で１枚、 娘たま は忘れた……確か店頭在庫１枚。
LINDBERG、今すぐ Kiss Me、1990.2.7、らしい。 曲調は 1980年代後半な気がする。
バックアップメディアの話、 Sat,14 Mar,2009、 Sat,28 Mar,2009の続き。 エラー訂正符号（ECC : Error-Correcting Codes）。 広義では冗長符号（Redundancy Codes）とも言う。 訂正能力としては、 「 ターボ符号（Turbo codes） ＞ ビタビ符号（Viterbi codes） ＞ リードソロモン符号（RS : Reed-Solomon codes） 」 らしい。 リードソロモンは DVD-RAM（ROM、±R、±RW は含まれない）や QR-Code に使われているらしい。
ファイルに エラー訂正符号／リカバリブロック／リカバリレコード／冗長符号 などを付加できるソフト。 OS、アーキテクチャに依存する （特定の OS用しか公開されていない）物は除外。
parchive (par2, par2cmdline) http://parchive.sourceforge.net/ さっき見つけた。詳細不明。 パッケージメンテナーの能書きをまともに信じると、 「どんなファイルにでも、 エラー訂正用データを（別ファイルで）添付する事ができて、 エラーが出た時に簡単に復旧作業を行う事ができる、 NetNews（英語表記だと Usenet らしい）では一番有名なソフト」 （意訳、原文は英語） らしい。 Sun,30 Aug,2009 追記： どんなファイルにでも、 エラー訂正用データを（別ファイルで）添付する事ができて、 エラーが出た時に簡単に復旧作業を行う事ができた。 破損時の修復と言う点にかけては、rar や dvdisaster より遥かに強力。 Sun,30 Aug,2009に続く。 dvdisaster http://www.dvdisaster.com/ かなり強力なエラー訂正符号を付加できる。 Error-Correcting Codes 割合は 3〜64％で設定可能。 iso9660 イメージにしか対応していない。 rar リカバリレコードみたいな物を付加できるソフトの中では、日本国内限定では一番有名か？。 Error-Correcting Codes 割合は 1〜10％で設定可能。 アーカイビングしないと付加できない。 reed-solomon http://www.ka9q.net/code/fec/ リードソロモン符号の計算を行うライブラリらしい。 SIMD-Viterbi http://www.ka9q.net/code/fec/ ビタビ符号の計算を行うライブラリらしい。 Schifra http://www.schifra.com/ リードソロモン符号の計算を行うライブラリらしい。 C++版と VHDL版（IPコア版）があるらしい。
先週頃から今週にかけて、電車の遅れが多い気がする。
anthy-9100h + alt-cannadic-090308 + alt-depgraph-090308 の話の蛇足。
「|公開されることはないだろうけれど|」（こうかいされることはないだろうけれど）で１文節になった。 「|訂正すべきものでもないけれど|」（ていせいすべきものでもないけれど）で１文節になった。
間違いではないし、訂正すべき物でも無いけれど。
何か良い方法はないかなぁ。
↑ Sun,05 Apr,2009 追記：
「vagus氏 - 丘の道を登り - 2009年04月03日 - 自作 depgraph 更新(4/2)」
にて、解説がありました。有り難うございます。
結局、最終的に行き着く所は、
コーパスを10倍100倍に増やすとか、
新しいエンジンを開発するとか、
になってしまうかなぁ。
すみません、良いあるいは良さそうなアイディアが浮かびません。
日経CNBC で放送事故。 録画リピート放送にも関わらず、 番組本編中にいきなり切れて CM に突入する事、２〜３度、 そして遂に「しばらくお待ち下さい」になった。 かなり久しぶりに「しばらくお待ち下さい」のテロップを見た。 何年ぶりだろう。
↑ システムの年度越えがらみトラブルだろうか？。 新担当者への引き継ぎ失敗だろうか？。 単純ミスだろうか？。 理由が公開される事は無いだろうけれど。 「失敗学」と言う意味で気になる。