Gauche から wkb (well-known binary) を読み込めるライブラリを書きました

wkb とは

GIS 分野において、点や線分、多角形を扱うフォーマットです。
binary の名の示すとおり、バイナリフォーマットです。

wkb と wkbhex

wkbhex は wkb を hex 表記したもので、0x00 0x80 0xff 0x00 というバイト列ならば、"0080FF00" といった文字列表記になります。

みどころ

本題です。
wkb パーサは実のどころどうでもよくて、wkbhex をバイナリポートに変換するルーチンです。

(define (read-hex-string :optional (iport (current-input-port)))
  (glet* ([higher (read-char iport)]
          [lower (read-char iport)])
    (string->number (string higher lower) 16)))

(define (open-input-hex-string str)
  (make <virtual-input-port> :getb (cute read-hex-string (open-input-string str))))

read-hex-string はポートを引数に取ります。
glet* は and-let* のジェネレータ版です (要 gauche.generator)。
and-let* は #f が評価された時点で停止し、#f が返りますが、glet* は (eof-object) が評価された時点で停止し、(eof-object) が返ります。
read-hex-string は2バイト(正確には2文字)をポートから読み込み、読み込まれた文字列を数値に変換して返します。
つまり、ポートに "FFFE" という文字列が残っている場合、255, 254 という数値を順番に返します。
ポートの終端までたどり着いた場合は glet* により (eof-object) が返ります。
つまり、read-hex-string はジェネレータです。

open-input-hex-string は、文字列を受け取り、バイナリとして読み込めるポートを返します。
wkbhex to wkbトランスレータです。
read-hex-string は 0-255 の数値、もしくは (eof-object) を返すので、virtual-input-port の :getb に突っ込むだけでバイナリデータを読み込むことができるポートを作成できます。

ちなみにエラーチェックがないのでつけるべきですね ;-)

そのうち

Gauche のジェネレータは面白いのでなんか書きたい

課題

  • 2次元座標にしか対応していないので、多次元座標に対応させたい
  • wkb/wkbhex の出力もしたい

Galaxy Nexus で apt-X を使えるようにしたい (手詰まり中)

apt-X 対応の Bluetooth ヘッドフォンを購入したものの、スマホ側 (Galaxy Nexus) が対応していないので SBC にフォールバックされて 64kbps MP3 を聞いているような感覚に陥りながら、外で聞く用だからそんな音質こだわらねーしwwwと粋がりながらも、ふぇえやっぱり音質しょっぱすぎるよう;;; となっているアカウントがこちらになります。

なんか最近のシャープのナントカってやつとか、HTC J とかは apt-X に対応してるっていうじゃん?Galaxy S3 も対応してるっていうじゃん?じゃあ移植してみればいいじゃん?
ということで、HTC One S の ROM から物故抜いて移植を試みてみました。

  • /system/lib/libbt-aptx-4.0.3.so
  • /system/lib/bluez-plugin/audio.so
  • /system/lib/hw/audio.a2dp.default.so
  • /system/etc/bluetooth/audio.conf (APTXSources=1 を記述)

が関係ありそげ。こいつら全部 Galaxy Nexus に放り込んでみたら、見事にブートアニメーションから先に進みませんでした。残念無念。
AOKP のソースを眺めてみたところ、やはりというか、hw/audio.a2dp.default.so はハード依存っぽく、そら単純に移植しても動かんわなー。
apt-X 自体はソフトウェアレイヤなはずなので、どうにかすればいけそうな気はします。
が、ライセンスなどの関係でこいつらのソースコードが出てくることはなさそうなので、手詰まり。

gappend-map を gconcatenate で / Re: 特定のビット列が現れる場所を探す (Gauche)

Gauche の最新 HEAD で gconcatenate 手続きが追加されました。

というわけで、gappend-map と byte-generator->bit-generator は以下のように書き直せます。
ただし、gappend-map は proc 内で返す物がリストではなくジェネレータになります。

(define (gappend-map proc . gens)
  (gconcatenate (apply gmap proc gens)))

(define (byte-generator->bit-generator gen)
  (gappend-map (^x (list->generator (integer->list x 8))) gen))

特定のビット列が現れる場所を探す (Gauche)

ジェネレータ、遅延シーケンス、パターンマッチングを使ってみました。
書いた後に気づいた、Shiro さんによる gappend-map (& byte-generator->bit-generator) の別解 (http://blog.practical-scheme.net/shiro/20120217-nash-cipherer, bytes->bools)。継続が使用されない分、こっちのほうが速そう。

最後のテストで "hogefuga" という文字列の (Gauche 内部エンコーディングな) ビット列から、010110 というパターンを探しています。
その結果、3 バイト目の 1 (= 7 - 6) ビット目に見つかったことが分かります。
遅延シーケンスを用いているので、その先のビット列は読み込まれないため、巨大なファイルでも安心。
ちなみに Gauche リファレンスの遅延シーケンスの項目に書かれている内容そのままです。てへぺろ

IronScheme を使ってみた

C# から手軽に Scheme のコードを呼び出したくて。


IronScheme をインストールした後、.NET なプロジェクトに IronScheme.dll と IronScheme.Closures.dll を参照設定に追加すれば一通り使えました。

using System;
using IronScheme;
using IronScheme.Runtime;

static void Main(string[] args) {
    Console.WriteLine("(+ 1 2)".Eval()); // => 3
    Console.ReadKey();
}

あっけなく。


次に Scheme 側の手続きを C# で呼び出してみます。

"(define (add-one-func i) (+ i 1))".Eval();
var addOneFunc = "add-one-func".Eval<Callable>();
Console.WriteLine(addOneFunc.Call(0)); // => 1
Console.WriteLine(addOneFunc.Call(5)); // => 6
Console.WriteLine(addOneFunc.Call(10)); // => 11

あっけなく。


最後に C# 側の関数 (Func) を Scheme で呼び出してみます。

int i = 0;
Func<int> incrementFunc = () => i++;

"(define increment-func {0})".Eval(incrementFunc.ToSchemeProcedure());

が、no expression in body と怒られてしまいます。
IronScheme の Eval() が悪さをしているっぽいのですが (引数で渡したオブジェクトがいったんシンボルになってる)、Scheme レベル 0 なのであんまり深く追っていません。

"(define increment-func '())".Eval();
"(set! increment-func {0})".Eval(incrementFunc.ToSchemeProcedure());
Console.WriteLine("(increment-func)".Eval()); // => 0
Console.WriteLine("(increment-func)".Eval()); // => 1
Console.WriteLine("(increment-func)".Eval()); // => 2
Console.WriteLine("(increment-func)".Eval()); // => 3

とすると、とりあえず動きました。


他にも、

foreach (var val in "'(1 2 3 4 5)".Eval<Cons>()) {
    Console.WriteLine(val);
}

のように、Cons が IEnumerable だったりして面白いです。


IronScheme 自体の初期化が重いのが難点ですが、常駐系のアプリであれば結構使えそうです。

Vista, 7 以降の環境で LR2 をリフレッシュレート 120Hz で動かす方法 (GeForce, RADEON 共通)

LR2 に限らず、リフレッシュレート 60Hz で固定されてしまうのをなんとかする方法です。
XP 時代はグラフィックカードのドライバからリフレッシュレートの固定ができたのですが、Vista 以降のドライバからは軒並み削除されているようです (DX10以降のアプリケーションが、外部からのリフレッシュレート強制変更にそもそも対応しないようです。MS方針?)。
そのような事情もあり、DirectX9 世代のアプリケーションにしか効果はありません。


昔は dxdiag でリフレッシュレートの固定ができていましたが、今はありません。
というわけで、レジストリを弄ってしまいましょう。


32bit の場合 (と、64bit の場合のネイティブ 64bit アプリ向け)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw に ForceRefreshRate (DWORD) を作成。値は固定したいリフレッシュレート。


64bit の場合の 32bit アプリ向け (LR2 の場合はこちら)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectDraw に ForceRefreshRate (DWORD) を作成。同上。


レッツぬるぬる!