mingw版Groongaのビルド

Groongaをmingwでビルドしてみた。非公式ビルドが32bitだったので、64bit版にチャレンジ。※ Groongaは32bit OSをサポートしていません。
以下手順

MSys/MinGWインストール

1. MinGWのインストーラをダウンロード
   http://sourceforge.net/projects/mingw/files/ から mingw-get-inst-yyyymmdd.exe を取得する。
2. インストーラを実行。オプションでMSysを追加しておく。
3. http://sourceforge.net/projects/mingw-w64/files/ から Toolchains targetting Win64 / Personal Builds / sezero_20101003 を選択
4. zipアーカイブをダウンロードして展開する。
   ホストOSが32bitなら mingw-w64-bin_i686-mingw_20101003_sezero.zip
   ホストOSが64bitなら mingw-w64-bin_x86_64-mingw_20101003_sezero.zip
   ※ 64bit版はネイティブコンパイラ(クロスコンパイラではない)なので、アーカイブ中のmingw64ディレクトリ以下をMinGWのルートディレクトリ(例えばC:\MinGW)に展開してもよい。
5. MinGWのルートディレクトリに展開しなかった場合、mingw-w64-binを展開したフォルダをMSysのPATHに追加する。(下記参照)

MSysのPATHの追加方法

MSysのホームディレクトリに .profile というファイルを作成し、以下を記述。
※ アーカイブのmingw64ディレクトリを、MinGWのルートディレクトリに展開した場合

export PATH=/mingw/mingw64/bin:$PATH

Groongaビルド手順

1. Groonga 1.1.0のpthread依存除去版 http://pub.cozmixng.org/~kou/archives/groonga-1.1.0.tar.gz を取得する。
   ※ 本来は http://groonga.org/download/ からダウンロードできます。次の肉の日(2011/3/29)以降。
2. 64bitの場合、ltmain.shにパッチを当てる。(下記参照)
3. MSysのコマンドプロンプトを開く。
4. tar xf groonga-1.*.*.tar.gz によりGroongaを展開する。
5. cd groonga-1.*.* で展開したディレクトリに移動する。
6. 64bit OSの場合、引数なしで ./configure
7. 32bit OSの場合、./configure --host=x86_64-w64-mingw32
8. make
9. make install

ltmain.shのパッチ

libtool 2.2に含まれるltmain.shはx86_64に未対応のため、2.4のものをバックポートする。

--- ltmain.sh.orig	2011-01-29 21:21:29 +0900
+++ ltmain.sh	2011-03-01 22:47:52 +0900
@@ -2560,7 +2560,7 @@
     ;;
   *ar\ archive*) # could be an import, or static
     if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null |
-       $EGREP 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
+       $EGREP 'file format (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)' >/dev/null; then
       win32_nmres=`eval $NM -f posix -A $1 |
 	$SED -n -e '
 	    1,100{

動作確認

残念ながら、64bit版は正常動作していないようです。まだ調べられていません。

参考情報

• ongaeshiさんとktouさんのtwitterのやりとり(http://togetter.com/li/102678)
• http://www44.atwiki.jp/ongaeshi/pages/14.html

キーを入れ替える7つの方法

ちょっと前になりますがWindows Internals勉強会というので発表してきました。

これ → http://www.slideshare.net/firewood/lr-5346579

以前「Vista/Windows 7におけるキーボードカスタマイズ問題」というのを読んで、これにフィルタドライバのネタを加えてみました。
で、発表時にid:NyaRuRuさんがMSKLCの紹介＆デモをしてくれたので、その部分を加筆しました。（こういうのがすぐ出てくるのがさすがだなあと思いました）

MinGW-ffmpeg

FFmpegのコンパイル (2010/4/2)を読んでffmpegをビルドした。
大変すばらしい情報なのだが手作業が多いのでスクリプトを書いてみた（github）。
以下手順。

1. http://sourceforge.net/projects/mingw/files/ から MinGW-5.1.6.exe、MSYS-1.0.11.exe、msysDTK-1.0.1.exe をダウンロードしてインストールする。
2. GCCを更新する。私は TDM's GCC/mingw32 Buildsにある4.3.3-tdm-1にした。（4.4以上は安定してるか不明だったので）
   この際、別のバージョンのg++を入れていると間違ったlibstdc++がリンクされたりするので、/mingw/lib/libstdc++.* と /mingw/lib/libsupc++.* をどこかに退避しておく。
   ffmpegだけビルドするなら3.4.5のままでも大丈夫かも。
3. GCCを更新するとpthreadのライブラリとヘッダが更新されるので、退避しておく。
   ファイルは /mingw/include/ の pthread.h、sched.h、semaphore.h と、/mingw/lib/ の libpthread*.a
4. coreutils-extを追加する。http://sourceforge.net/projects/mingw/files/MSYS%20coreutils/ にある coreutils-5.97-2-msys-1.0.11-ext.tar.lzma を、MSysの / に展開。
   # cd / && tar xf coreutils-5.97-2-msys-1.0.11-ext.tar.lzma --lzma
5. wgetを追加する。http://sourceforge.net/projects/mingw/files/mingwPORT/Current%20Releases/ にある wget-1.9.1-mingwPORT.tar.bz2 を展開し、その中の wget.exeを /mingw/bin/ にコピーする。
6. http://github.com/firewood/mingw-ffmpeg のスクリプトをどこか（/usr/src/ffmpeg/ とか）に置く。
7. build.sh でダウンロードとビルドを行う。
   # ./build.sh 2>&1 | tee build.log

なおffmpeg.exeを生成するだけでインストールはしないようになっているので、必要であればffmpeg.iniを編集する。（インストール先はPREBUILD1で指定し、インストールするかどうかをPOSTBUILD1で指定する）
また、faacを使用する場合は、faac.iniのENABLEDをyesにする。（これで生成したバイナリは配布できないので注意）

http://blog.k-tai-douga.com/article/36847657.html とはx264とffmpegのバージョンが若干異なっている。パッチが当たらないところはbuild.shの中で追加してある。

そもそも何でビルドしたかというと、

• 手持ちのデジカメがMotionJPEG対応なため変換することに
• 携帯動画変換君を使ってみようと思ったらffmpegが古かった
• ffmpegを更新したらオプションが色々変わっていた
• xvidを使おうとしたら Invalid pixel aspect ratio 0/1 というエラーが発生

という感じ。アスペクト比については無指定だとで0が入っていて、たぶん0は各CODECでよきに計らえという意味だと思うのだが、libxvidff.cは処理しないので困ったものだ。640×480の動画で明示的に-aspect 4:3としたときにsample_aspect_ratioに1:1が設定されたので同じにした。（PARなのだろう）

ビルド環境について

• http://ffmpeg.arrozcru.org/wiki/index.php?title=Installing_MSys

x264のオプションについて

• http://blog.k-tai-douga.com/article/34604396.html
• http://mobilehackerz.jp/archive/wiki/index.php?%BB%A8%C3%CC%C8%C46#z722b241

ソフトウェアの社会的責任

夜フクロウと「社会的責任」を読んだ感想。

• ソフトウェアは基本的には何らかの条件に従って使用するものなので、例え無料であっても提供者と使用者が明示的に契約を結ぶことが望ましい。
• 有償無償に関わらずまずは契約を結ぶという考え方が共有されれば、堅苦しくはあるが、トラブルは減りそう。
• 責任という言葉は、何が義務なのかわかりづらい。社会的責任と、特定の機能を維持することとの間には、直接の因果関係はないのではないか。
• 契約書に何が義務なのか明示しておくべき。
• 責任という言葉は、セキュリティホールなど欠陥に対する義務という文脈で使われることが多い気がする。
• 開発者視点だと、対価を取った場合でも、対価にふさわしくない労力を提供する義務を課してほしくない。
• 製造者責任という言葉はある。何か問題が生じたときに、使用者だけでなく、製造者にも相応の責任があるという意味か。
• 社会的責任は社会に対する影響の大きさに比例しそう。提供者にはリスクがある。

MessagePackとProtocol Buffersを試してみた

Visual C++ 2005でMessagePackとProtocol Buffersを試してみた。

MessagePack

インストール

http://msgpack.sourceforge.jp/ から最新版（3/10の時点ではmsgpack-0.4.2.tar.gz）をダウンロードし、適当な場所に展開する。
プロジェクトファイルは付属してないので作成した。
http://github.com/firewood/test/blob/master/msgpack_vc8.sln
http://github.com/firewood/test/blob/master/msgpack_vc8.vcproj
c/msgpack/zone.hに以下の部分がある場合は削る。（msgpack/sysdep.hで吸収しているので不要）
#include
#include
プロジェクトファイルを開き、バッチビルドでDebugとRelease両方をビルドしておく。これでフォルダlib以下にmsgpack.lib（リリース版ライブラリ）とmsgpackd.lib（デバッグ版ライブラリ）ができる。

以下インストールしたフォルダをC:\msgpackとする。
VC++の開発環境の「ツール→オプション」のダイアログを開く。「プロジェクトおよびソリューション」の「VC++ディレクトリ」の「インクルードファイル」の欄に
C:\msgpack\cpp
C:\msgpack\c
C:\msgpack
を追加する。
「ライブラリファイル」の欄に
C:\msgpack\lib
を追加する。

使い方

以下のようにしてヘッダとライブラリを追加する。（msgpack.vcprojを自分のプロジェクトに追加する必要はない）
#include
#pragma comment(lib, "ws2_32.lib")
#ifdef _DEBUG
#pragma comment(lib, "msgpackd.lib")
#else
#pragma comment(lib, "msgpack.lib")
#endif

オブジェクト生成→ファイルへ保存→ファイルから読み込み→オブジェクトへ戻すというお手軽な例を書いてみた。
http://github.com/firewood/test/blob/master/MsgPackTest.cpp
http://github.com/firewood/test/blob/master/MsgPackTest.sln
http://github.com/firewood/test/blob/master/MsgPackTest.vcproj
なお公式APIドキュメントはこれ。

Protocol Buffers

インストール

Google CodeのDownloadのとこから最新版（3/10の時点ではprotobuf-2.3.0.zip）をダウンロードし、適当な場所に展開する。
付属のプロジェクトファイルvsprojects/protobuf.slnにより、protoc.exeやlibprotobuf.libがビルドできる。

もしプロジェクトファイル（libprotobuf.vcproj）を自分のプロジェクトに含めないで利用する場合には、ライブラリの名前がデバッグとリリースで重複するので、プロジェクトlibprotobufのプロパティを開き、ライブラリアンの出力ファイルを$(OutDir)\$(ProjectName)d.libのように変更しておく。

以下インストールしたフォルダをC:\protobufとする。
VC++の開発環境の「ツール→オプション」のダイアログを開く。「プロジェクトおよびソリューション」の「VC++ディレクトリ」の「インクルードファイル」の欄に
C:\protobuf\src
を追加する。
「ライブラリファイル」の欄に
C:\protobuf\vsprojects\Debug
C:\protobuf\vsprojects\Release
を追加する。
「実行ファイル」の欄に
C:\protobuf\vsprojects\Release
を追加する。（protoc.exeを使用する）

Protocol Buffersでは.protoという定義ファイルをprotocという独自のコンパイラでコンパイルするようになっているので、これのカスタムビルドルールを追加しておく。
カスタムビルドルールが存在しない場合、.protoファイルを追加するとダイアログで聞いてくるので、その場で作ることもできるが、参考までに以下に置いておく。
http://github.com/firewood/test/blob/master/ProtocolBuffers.rules
このファイルをVCのインストールディレクトリ（C:\Program Files\VisualStudio2005\VC\VCProjectDefaultsみたいなところ、masm.rulesとかがあるはず）に置いてから、プロジェクトを右クリックして「カスタムビルド規則」を選び、「既存ファイルの追加」で追加しておく。VCProjectDefaultsに置いておくとプロジェクト毎に指定しなくてよい。

使い方

定義ファイルHoge.protoを利用する場合、以下のような感じ。
#include "Hoge.pb.h"
#ifdef _DEBUG
#pragma comment(lib, "libprotobufd.lib")
#else
#pragma comment(lib, "libprotobuf.lib")
#endif

こちらもオブジェクト生成→ファイルへ保存→ファイルから読み込み→オブジェクトへ戻すという例。
http://github.com/firewood/test/blob/master/Hoge.proto
http://github.com/firewood/test/blob/master/ProtoBufTest.cpp
http://github.com/firewood/test/blob/master/ProtoBufTest.sln
http://github.com/firewood/test/blob/master/ProtoBufTest.vcproj
チュートリアルで十分な気はする。

感想

MessagePackは低レベル関数が最初から見えているので小回りがきくのかなと。メンバの格納順序を気にしたくない（こんな感じ http://github.com/firewood/test/blob/master/Deserial.cpp）みたいなときにカスタムデシリアライザを書くこともできる。
Protocol Buffersは、デシリアライズしたオブジェクトがそのまま使えるので便利。しかしいろんな型のものを突っ込むのはどうやったらいいのかわからない。

PC環境検討会

よくわからない会合に行ってきた。Windows3台、OSX4台で、OSX率高し。Macは10年くらい使ってないので参考になった。

スタイル

どこでもgenericな環境 or カスタマイズばりばり、という軸だと私は自前の常駐アプリが何本か走ってたりして後者なのだが、OSや場所にしばられないようにしようとすると必然的に前者になる。まかーの人たちは便利なUNIXコンソールとしてOSXを使ってた感じ。Windowsをコンソールにするときに困るのはマルチスクリーン（仮想デスクトップ）が悲惨とか、cmd.exeよりCygwinとか。

メモとファイル

私はよく1つのファイルにどんどん追記していくのだけど、日付毎に1ファイルにしたほうが検索しやすそうだった。作業日報とか作るときに便利。

ツリーメモ、TODO管理

4人くらいFreeMindを使ってたようだ。いわゆるアウトラインプロセッサは書き方を強制されるというイメージがあったのだけど、使いたいように使えばいいのかなと。議事録を取っている様子を見て、これは是非使いたいと思ったが、キーカスタマイズは必須そうである。
横に長くなったらどうすんだろと思ったら長文モードとかもあった。

sync

sa-yさんの環境（複数OS＋Dropbox共有＋自動分配スクリプト）は素晴らしい。近い環境になった暁には真似したい。
ごにいさんのevernoteに名刺とか何でもつっこむというのも良さそうだった。ただWindowsと日本語への対応はまだ発展途上ぽい。

エディタ

isshikiさんと共鳴しすぎた。エディタとかよりもこの辺の方がシンクロ率高い気がするが。ちなみにWE LOVE WIZARDRYとALL OVER XANADUは家宝ですよ（脱線
エクスプローラの右クリックからGREPできる環境に慣れすぎていてWZが捨てられないのだがあまりにも非標準すぎて困る。もう少しviを使えるようになろう。

キーremap

tekezoさんのこだわりはすごい。カスタマイズが日常化していて実に楽しそうだ。OSXの素晴らしいところは見た目ではなくドライバ周り（フックとかPnPとか）だと思う自分。
XKeymacsがctrlキーがロックするとかいう話があったが、ユーザーモードだけでやろうとするとどうしてもバグるのかも。Windowsだとキーのカスタマイズ方法は何種類もあるようだ（参考）。
Linuxの日本語環境にはみんなご不満の様子。

開発環境

isshikiさんのエディタとか開発の流れの話。ペアプロとかしない限り、他人がどうやって作ってるのかってなかなかわからないものである。Unityとか見てるとテキストエディタでちまちま作るってのは趣味ですら絶滅しつつあるのかなあとか。Unreal Development Kitとかも似てる印象。

ファイルの日付

そういえばファイルの更新日付って気にしない人の方が多いのかなあと思う。私はエクスプローラは常に詳細表示で、更新日付で検索をかけることが多いのだが、cvsやgitでアップデートをかけるとデフォルトで（commitされた日付ではなく）取得した日付になる。他の人は新しいかどうかってどうやって判断してるんだろ。

いやほんと環境といっても色々ありますね。Zinniaさん良い会ありがとうございました。

LRUSet

キャッシュのデータ構造について。「キャッシュのデータ構造 with Boost.MultiIndex」と「slist LRUMap」でできるっぽいので、それぞれでLRUSetを実装してみた。GetかAddするとキューの末尾に並び替えられるというもの。

まずBoost.MultiIndexのほう。http://github.com/firewood/test/blob/master/MultiIndexTest.cpp
modify()でlast_accessメンバを更新すると自動的にソートしなおされる。この手軽さと強力さはすばらしい。ただVC++だとエラーメッセージからエラーの原因をつかむのが難しかったりする（「'boost::multi_index::detail::bidir_node_iterator' から 'boost::multi_index::detail::bidir_node_iterator' に変換できません」とか）。

でstd::setとslistの組み合わせのほう。http://github.com/firewood/test/blob/master/LRUSet.cpp
set+slistを実現するためにsetにはノード構造体のポインタを入れることにした。ノード構造体はnextとvalueを保持していて、setは次のノードの値（next->value）でソートするという変則仕様。リンクチェーンの更新はnextとvalue、自分と前後で計6箇所書き換えている。kinabaさんの元のソースではポインタの差し替えをしているのだが、ポインタのsetにおけるポインタは要素の値であり直接書き換えられない（ポインタのポインタのsetにすれば差し替え可能になるが、余計なメモリを消費するくらいなら双方向リストにしたほうがよい）。そのためわざわざ前のノードのポインタも取得している。実用性はないがパズルとしては楽しめた。