iconv 1.9.1におけるCP932は、いわゆるWindows文字をうまく変換できません。相応のパッチも出ているのですが、Visual C++環境のない私には再ビルドが困難なので、プラグイン側で対応することにしました。libiconv-1.9.2-cp932.patch.gzやXML日本語プロファイル 解説あたりを参考に、CP932⇔UTF16LE変換をいわゆる「マイクロソフト変換」に対応させました。EUC-JPやISO-2022-JPには対応してませんが、必要であれば追々対応するという方向で。
ペイント関数やイメージバッファ比較関数では、同一（一致）と見なす際に、不透明度まで比較するかどうかなどを指定できます。これを（無駄に）拡張して、ピクセル比較時に、ユーザが指定したビットマスクを適用できるようにしました。マスク値を使うと、例えば赤成分が一致する領域のみを塗りつぶすとか、RGB各成分の上位6ビットが一致していれば同じイメージと見なす、みたいなことができるようになります。だから何だ、といえばそれまでなんですが。
一日中、SQLiteと格闘してました。いやどちらかというと、SQLitePlusのほうですかね。例外処理等の関係上、とうとうSQLitePlusにメスを入れることになりました。スマートポインタを一部使わないようにしただけですが。
がんばれ！！ゲイツ君経由。これは知りませんでした。一年半も前の記事ですが、これを読む限りでは「法務省版シグマ計画」のように思えます。2007年に全面稼働予定とのことですが、どうなんでしょうねえ。
しかしまあ、2003年度までにつぎ込まれた開発関連予算は合わせて2600億円以上
って、どうやったらこんな金額になるんでしょうかね。書面ベースの登記情報（不動産で約3億筆個）を電子化するのにかかった人件費、というのであればまだわかりますけど、開発でこの金額はおかしいでしょう。
シグマといい年間維持費３億円の原子力発電の広報用ウェブページといい、官公庁絡みのプロジェクトは不思議がいっぱいですね。
先日のメジアン取得ロジック。上位4ビットで基数（というよりはバケツ？）ソートしてましたが、これを上位3ビットにしてみたところ、5%ほど速くなりました。まあ、あまり変わってませんね。
書くのが面倒になってサボっていたら、随分間が開いたなあ。
メモ。
送信コールバック関数を、吉里吉里が持つコンティニュアスハンドラを使用して呼び出すようにしました。送信データはオクテット列の配列で、各オクテット列データ（へのポインタ）を、WSABUF構造体の配列に代入しておきます。コンティニュアスハンドラは、オーバーラップデータ構造体が保持する転送サイズを監視し、各WSABUF構造体が保持するサイズを越えるたびに、コールバックイベントをイベントキューにエンキューします *1 。イベントキューにイベントがあれば、コンティニュアスハンドラはそのイベントを実行します。つまり、分割送信をアプリケーションレベルで実現し、分割された各データの送信完了ごとにイベントが発生する、という仕組みです。
イベント発生時にコールバックされる関数は、クライアントソケットが持つメソッドonRequestSendで、要するにイベント関数です。この関数は、最終コールバックかどうかを表すフラグと、何回目のコールバックかを表すカウンタを引数として受け取ります。予め、送信するデータを一定のサイズで区切っておけば、転送の進捗を知ることもできます。また、転送済みのバッファを順次解放したり、転送待ちのバッファにデータを逐次投入することで、使用メモリを節約することも可能になるかもしれません。
SSTPを使って、分割送信とイベント呼び出し（の一歩手前）の動作を確認しました。これと同様の機構を受信でもやるわけですが、受信はちょっと大変かも。
友達と東方花映塚で通信対戦してみました。処理落ちはそれなりに起こっていましたが、シューティングゲームでも意外と動くものですね。対戦中、ADSLモデムのアクセスランプが激しく点滅していましたが、ネットゲームってどれもこんな感じなんでしょうか。
アキバ。本とHDDを購入し、出勤途中（夜勤）の旅人さんと合流しました。カレー屋で食事をしながら例のブツ（何）を引き渡して、解散しました。
PCの内蔵S-ATA HDDをRAID1構成に。
これでうまくいくはず。今日はファイルコピーを仕掛けて就寝。
仕掛けておいたファイルコピーが完了していたので、もう一つの新HDDを接続し、アレイ構成を変更してデュプリケート開始。250GBもあると、さすがに時間がかかりますね、二時間ほど放置して、複製完了。あとはOSレベルで確認して作業終了。問題なし。
…いや、問題が一点ありました。読み込みはかなり速いのですが、書き込みが妙に遅いです。シーケンシャルリードの場合、アクセス場所にもよりますが、速いところでは65[MB/s]、遅いところで41[MB/s]でした。しかし書き込みは場所によらず、19[MB/s]と低い値で安定しています。何が原因なんでしょうか。うーむ。
PostgreSQLのCREATE AGGREGATEを参考に、集約関数を作ってみました。
// 和を返す状態遷移関数
var sfunc_sum = function(internalState, value)
{
return internalState + value;
};
// 平均値を返す最終計算関数
var ffunc_avg = function(internalState)
{
return (count > 0) ? (internalState / count) : void;
};
// 差の二乗和を返す状態遷移関数
var sfunc_2diff = function(internalState, value, avg)
{
var s = value - avg;
return internalState + s * s;
};
// 平均値を返す集約関数
var average = arr.aggregate(sfunc_sum, ffunc_avg, 0);
// 分散を返す集約関数
var variance = arr.aggregate(sfunc_2diff, ffunc_avg, 0, average);
こんな感じに分散を算出したり、しなかったり。使い道が不明なのはいつものことです。
ちなみに、この機能をTJS2で実装するとこんな感じです。
Array.aggregate_TJS = function(stateFunc, finalFunc, initialCond, *)
{
var N = this.count;
var internalState = initialCond;
for (var i = 0; i < N; i++) {
internalState = stateFunc(internalState, this[i], *);
}
if ((typeof finalFunc) == 'Object') {
internalState = finalFunc(internalState, N, *);
}
return internalState;
};
メモ。単独で実現できるもののみ記述。RubyとC#はよく知らないので適当。
| 要素抽出 | 各要素処理 | ユニーク | |
|---|---|---|---|
| Perl | grep | map | - |
| Ruby | Enumerable.grep | Array.each, Enumerable.map | Array.uniq |
| PHP | array_filter | array_map | array_unique |
| C#2 | Array.Where (?) | Array.ForEach | ? |
| 俺的TJS2拡張 | Array.grep | Array.map | Array.unique |
TJS2エンジンに手を出しました。まずは練習ということで、ArrayにforEachメソッドを追加してみました。何の変哲もない、ただのforeachです。
[ 'TJS', this ].forEach(function(index, value) {println(@"${index} => ${value}");});
ほかにいくつかネタがあるので実装してみようかとは思いますが、自作プラグインでの機能と被る部分は二重管理になってしまいます。どうしたものか。