Picasa の Instant Upload アルバムから他のアルバムに「移動」できなくなっていたのでなんとかした
昔はできていたのにね。
コピー→削除はだるいし、Picasa WebAlbum 上で複数の写真を削除するとやけに時間かかるしでやってられません。
なのでグリモン書きました。
Gauche から wkb (well-known binary) を読み込めるライブラリを書きました
ソースコード
Github にあります:
https://github.com/cryks/Gauche-wkb
みどころ
本題です。
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 を使ってみた
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) を作成。同上。
レッツぬるぬる!