blog: pawo

「Steve Jobs」を読んでの感想

2011-11-20T15:58:00.003+09:00

ようやく「Steve Jobs」の上下巻を読み終えました。

MacBookAir と iPhone を使っているくらいには Apple 好きなので、この本にはだいぶ期待してました。

ざっくりとした感想は、上巻は細かいジョブズの伝記という感じったのに対し、下巻はだいぶ Apple の歴史の方にシフトしていたのが残念だな、というところ。

上巻だったらジョブズはこう悩み、こう現実歪曲フィールドを展開し、こいつらと戦いという話が出ていたのが、下巻だと「悩み」の部分が少なかった印象です。

あと、下巻が時系列順ではなくて製品によって時期が転々と飛ぶのも、伝記としてはわかりづらいなーと思います。

逆にジョブズにあまり興味がない人も、下巻だけ読むと iPod とか iPhone の考え方がわかって良いと思います。

多分上巻は、ジョブズに多少なりとも興味がないと読めないと思いました。

下巻読んで、Apple だけじゃなくてジョブズにも興味持ったら上巻を読む、というのをお勧めします。

コマンドラインでの並列実行: xargs

2011-11-10T23:06:00.005+09:00

そこそこなシェルスクリプターなのですが、いまいち並列実行について知りません。
make を使えば並列実行出来るのはわかるのですが、各ファイルに対して処理をするだけとかの場合にわざわざ Makefile を書くのもナンセンスだなと思います。

そこで「シェルスクリプト　並列実行」あたりでググりました。
そうすると、xargs とか GNU Parallels を使えばイー感じにできそうということです。

■ xargs
こことかで紹介されています。

技術メモ帳: http://d.hatena.ne.jp/lurker/20070117/1169039924

xargs で順次実行する際に並列実行してくれるとのことです。

自分はよく -I を使うので、次の感じでやればいい感じです。

通常

$ find . -type f | xargs -I {} shasum -a 256 {}

並列実行

$ find . -type f | xargs -P 4 -I {} shasum -a 256 {}

ためしに、Emacs.app 内の適当なelisp ディレクトリ内で上スクリプトを実行してみます。

$ time find . -name "*.el" | xargs -I {} shasum -a 256 {}
..
real 0m8.181s
user 0m7.057s
sys 0m0.938s

$ time find . -name "*.el" | xargs -P 4 -I {} shasum -a 256 {}
..
real 0m3.642s
user 0m11.469s
sys 0m1.419s

find とかの時間もあるので単純な比較はできないですが、確かに早いです。

とりあえず、追加のインストールもなくさくっと使うにはよさそうです。

時間がなかったのでGNU Parallel はまた今度！

Emacs + hi-lock 2

2011-10-31T23:59:00.003+09:00

前回 hi-lock と isearch を統合するe-lisp をちょこっと書きましたが、これだと case-sensitive で使いづらいということに気づきました。

■例：runAsThread() という関数があり、それをハイライトしようとする

Ctrl-s Ctrl-w で現在位置の文字列を isearch すると、「runasthread」という文字列での検索になってしまいます。

これを、前回の e-lisp を使い、Ctrl-l でハイライトしようとすると、「runasthread」で登録されます。

しかし hi-lock だと case-sensitive なため、当初の目的である runAsThread がハイライトされません。

■対処案

hi-lock.el を見ていると、hi-lock-process-phrase という関数があり、これは Capitalize (先頭文字だけ大小不問) でも大丈夫にするもののようです。

単に、「runAsThread」を「[rR]unAsThread」という正規表現に書き換えるだけですが。

ただこれを参考にすれば、case-insensitive という目的は、汚いですが「[rR][uU][nN]....[dD]」と書き換えてしまえば達成できます。

ということで、以下の e-lisp でゴリ押ししました。

;; isearch-highlight
(require 'hi-lock)

(defun highlight-isearch-word ()
 (interactive)
 (let ((case-fold-search isearch-case-fold-search))
   (isearch-exit)
   (hi-lock-face-buffer-isearch isearch-string)))

(defun unhighlight-isearch-word ()
 (interactive)
 (isearch-exit)
 (hi-lock-unface-buffer (highlight-to-ignore-case isearch-string)))

(defun casemap (char)
 (replace-regexp-in-string
  "\\<[a-z]" (lambda (m) (format "[%s%s]" (upcase m) m)) char))  

(defun highlight-to-ignore-case (string)
   (mapconcat (lambda (x) (casemap x)) (split-string string "") ""))  

(defun hi-lock-face-buffer-isearch (string)
   (setq face (hi-lock-read-face-name))
   (or (facep face) (setq face 'hi-yellow))
   (unless hi-lock-mode (hi-lock-mode 1))
   (hi-lock-set-pattern (highlight-to-ignore-case string) face))  

(define-key isearch-mode-map (kbd "C-l") 'highlight-isearch-word) 
(define-key isearch-mode-map (kbd "C-u") 'unhighlight-isearch-word)

日本語、英語は確認しています。バックスラッシュが混ざるとアウトなのも確認済みです。

Emacs + hi-lock

2011-10-29T21:19:00.009+09:00

vim を使う友人を見ていて羨ましいと思ったのが、検索文字列を強調したままにしておく機能です。

調べてみると、ちゃんと Emacs にもありました。hi-lock-mode だそうです。

Meadow/Emacs memo

http://www.bookshelf.jp/soft/meadow_35.html#SEC527

このサイトにはisearch との連携を良い感じにする e-lisp も置いてあり、そのまま使えばいいかと思ったのですが、どうもうまく動きません。

Wrong number of arguments: #[(regexp face) ... と言われてしまいます。

ということで、いー感じに e-lisp を修正する必要がありました。

どうせならということで、isearch したものを highlight から消すのもちょこっと追加しました。

それが以下です。

(2011/10/31 追記)

この e-lisp だと、アルファベットの大小を区別してしまうため、あまりおいしくありません。

ゴリ押しで対応した版の e-lisp を作成したので、そちらも参照ください。

(require 'hi-lock)

(defun highlight-isearch-word ()
(interactive)
(let ((case-fold-search isearch-case-fold-search))
(isearch-exit)
(hi-lock-face-buffer-isearch isearch-string)))

(defun unhighlight-isearch-word ()
(interactive)
(isearch-exit)
(hi-lock-unface-buffer isearch-string))

(defun hi-lock-face-buffer-isearch (regexp)
(interactive)
(setq face (hi-lock-read-face-name))
(or (facep face) (setq face 'hi-yellow))
(unless hi-lock-mode (hi-lock-mode 1))
(hi-lock-set-pattern regexp face))

(define-key isearch-mode-map (kbd "C-l") 'highlight-isearch-word)
(define-key isearch-mode-map (kbd "C-u") 'unhighlight-isearch-word)

hi-lock-set-pattern のパラメータを修正しただけですね。

あと、migemo を使っていないので、migemo を削ってあります。動作確認していないからなので、必要であれば追加してください。

これで、isearch 中に Ctrl-l でその文字をハイライト、Ctrl-u でハイライトをキャンセルとなります。

■便利な使い方

・カーソル位置の文字列を、バッファ全体で強調：Ctrl-s Ctrl-w で選択後、Ctrl-l

・カーソル位置にある強調文字列の強調をキャンセル：Ctrl-s Ctrl-w で選択後、Ctrl-u

・直前に強調した文字の強調をキャンセル：Ctrl-s Ctrl-s で直前のものを選択後、Ctrl-u

Emacs + hide-ifdef-mode の自分なりの使い方メモ

2011-09-06T00:16:00.012+09:00

ifdef 多用なソースコードを多々見るので、ソースコードを見やすくしたいよねーという話をしました。Emacs で（大事）。

ということでちょっとググッてみました。

見つかったのはとりあえず２つ。

cpp-highlight-buffer
hide-ifdef-mode

どちらも、最初から Emacs に入っているもののようです。

ぐぐると cpp-highlight-buffer は設定が色々出来るようなのですが、わかりづらい！という印象。

ということで、単純な hide-ifdef-mode を使ってみました。

■自分の目指す使い方

「どこかに利用する定数のリストを用意しておき、それを使って現在表示しているソースコードの ifdef 表示を切り替えたい！」

ということで、これをもう少し具体的な要求にすると次の形です。

ソースコードそれ自体には何も追加しない
何種類かの定数の組み合わせを簡単に切り替えられるようにしたい
ifdef が無効になっていることがわかりさえすれば、表示方法は気にしない

これを目指すと、以下の形で使うのが良さそうでした。

予め hide-ifdef-mode、hide-ifdefs を有効にしておく
ザクッと切り替えられる elisp を書く
elisp をコピー(yank)する
M-: で、ミニバッファでの eval にして、コピーした elisp を eval

これで、ソースとは別に用意した elisp を使って定義する定数を切り替えられます。

例えば次の感じ。

;; .emacs に書く内容
(add-hook 'c++-mode-hook
    '(lambda ()
       (hide-ifdef-mode t)
       (hide-ifdefs)
    ))
;; 定数切り替えのスクリプト
;; define-alist で定義しているのは、一時的に付けるリストの名前(l)と、define する定数(FOO, BAR2)
((lambda () (setq hide-ifdef-define-alist '((l FOO BAR2)))(hide-ifdef-use-define-alist 'l)))

これでいい感じ。

もしソースコードをいじって良い環境であれば、上記の定数切り替えスクリプトをコメントとして貼っておいて、C-x C-e で eval するのが便利です。

# 個人的には、define する定数が Emacs 内グローバルだと便利だと思うのですが、どうなんでしょうか？

自分なりのアクターモデルの解釈

2011-08-18T23:21:00.003+09:00

７つの言語、７つの世界の Scala を読みました。

Ruby → Io → Prolog → Scala → ... なので、折り返しです。

印象は、Ruby 並の動的な書き方を静的言語に持ってきているおかげで、「楽しくプログラミングできそう」というものでした。ちょっとシンタックスは不慣れですがｗ

あと、静的言語である以上、動的にクラスを書き換えるのは出来なさそうですが。

Scala の特徴で気になったのは、アクターモデルなるものです。

これは、基本はスレッド間で共有する資源は無く、ただ必要なものだけは共有するという考え方のようです。

（アクターという考え方は Io にもあったのですが、Io は動的で遅めなのであまりクリティカルに見てませんでした・・）

最初の印象は「単にスレッドに制限入れただけじゃん」でした。それなら従来のスレッドで充分実現できるよね、って。

ただしばらくしてから、自分の恩師が「スレッドよりプロセスの方が安全でいいよね！」と言っていたのを思い出して、おっ！て。

つまりは「プロセスレベルのメモリ安全性をプログラミング言語が提供してくれてるんだ！」という気づきににやにやしてしまいました。あーなるほど、そう考えると凄い便利、って。

原則共有で、たまにロックして守るというブラックリスト方式ではなく、原則非共有で、必要なものだけホワイトリストに追加して共有するという方が、確かに安全ですね。

ということで、こうしたプロセスなどの OS が提供してきた機能を、プログラミング言語、コンパイラが提供してくれるようになるのかなという印象を、Scala を知ったことで持ちました。

次のパラダイムも OS の機能を考えたら視えるかもしれないですね。

Io-language 二日目の課題

2011-08-03T23:40:00.004+09:00

7つの言語 7つの世界を読み続けています。なかなか進まないですが。

今は Io-language の二日目です。課題やってます。

「シンタックスは15分で覚えられる」が確かに！と感動して、なかなか好きになりましたｗ

ということで、課題を真面目にやっています。でもなかなか難しい。

その自分なりの回答をメモっておきます。

■フィボナッチ数列を、再帰とループを用いて解け

-----

FibRecursive := Object clone

FibRecursive fib := method(

evaledArg := (call evalArgAt(0))

if(evaledArg == 1 or evaledArg == 2 ,

(fib(evaledArg-1)) + fib(evaledArg-2)))

FibLoop := Object clone

FibLoop fib := method(

a := 1

b := 1

c := 0

evaledArg := (call evalArgAt(0))

i := 3

while(i <= evaledArg, i = i + 1; c = a + b; a = b; b = c);

f := FibRecursive clone

f := FibLoop clone

f fib(1) println

f fib(2) println

-----

いちおう解けてるはずです。

ただ、再帰でfib(25)位を計算すると随分時間がかかってしまいます。

再帰がここまで遅いのはちょっと残念。

ちなみに、eval しないと数値にならず Message のままであるというのがわからず、数時間はまってました・・

■分母がゼロの時ゼロを返すように、/演算子を変換せよ

-----

origOp := Number getSlot("/")

Number / := method(number, if(number == 0, 0, (self origOp(number))))

-----

■二次元配列のすべての要素の総和を求めるプログラムを書け

-----

List dim2sum := method(

result := 0

foreach(i, v, result = result + (v sum));

result)

list(list(3, 3, 4), list(5, 5, 2)) dim2sum println

-----

メソッド名を数字から始めることはできないんですね。最初 2dsum としていたらはまりました。

この場合、2 に大して dsum メッセージを送ることになります。

例えば 2type と打つと、Number と返ってきます。

■リストに、そのリストのすべての数値の平均を算出するスロット myAverage を追加せよ

-----

List myAverage := method(

foreach (i, v, ((v type) != (Number type)) ifTrue(Exception raise("Only number type acceptable")))

sum / size)

-----

■二次元リストを実現するプロトタイプを書け。また、転置メソッドを用意せよ

１次元配列にして、ゲッタ・セッタで隠蔽するようにしています。

-----

Matrix := Object clone

Matrix dim := method(

self x := (call evalArgAt(0))

self y := (call evalArgAt(1))

self l := list()

for(i, 1, x * y, l append("")))

Matrix set := method(

v := (call evalArgAt(0))

w := (call evalArgAt(1))

(v < x) ifFalse(Exception raise("Index error"))

(w < y) ifFalse(Exception raise("Index error"))

l atPut((v + w*x), (call evalArgAt(2))))

Matrix get := method(

v := (call evalArgAt(0))

w := (call evalArgAt(1))

(v < x) ifFalse(Exception raise("Index error"))

(w < y) ifFalse(Exception raise("Index error"))

l at(v + w*x))

Matrix translate := method(

result := Matrix clone

result dim(self y, self x)

tmp := 0

for(i, 0, x-1, for(j, 0, y-1, tmp = get(i,j); result set(j, i, tmp)))

result)

-----

評価を行うタイミングが、セッタを使うときになっているけど、それでいいのかな？と思っています。

ホントはゲッタでアクセスしたときでしょうか？

それとも eval せずに返すほうがいいのですかね？遅延評価の中で実際の評価をどこで行うべきかが難しいです。

IO-language のビルド

2011-07-31T20:18:00.002+09:00

今、「7つの言語 7つの世界」という本を読んでいます。

この本は、7つのプログラミングパラダイム (プログラミングの考え方、って考えればあっていると思う)を紹介する本で、なかなか楽しく読んでいます。

紹介している言語は、

Ruby
Io
Prolog
Scala
Erlang
Clojure
Haskell

です。

一言語あたり30ページ程度なので、一つあたりの説明がそこまで濃くないですが、自分にとっては目新しい言語ばかりでいい感じですｗ

今 Io の章を読んでおり、せっかくなのでインストールして試しながらやろうと思っています。

で、インストールを試したのですが、なかなか苦戦しました。

そのメモです。環境は Mac OS X 10.6.8 + Xcode 3.2.6 で試しています。

■ リポジトリの取得

git-hub からリポジトリを取得します。

git clone https://github.com/stevedekorte/io.git

■ Xcode で開く (extras/osxvm/osxvm.xcodeproj)

cmake と make でビルドしようとしましたが、どうもうまくいきません。

しかし Xcode で、次の修正をした上でビルドするとすんなり通ります。

なので自分は Xcode でのビルドのみ確認しています。

■Common_inline.h の修正

そのままビルドを行うと、以下のエラーがでます。

ld: duplicate symbol _List_size in

/Users/xxx/hobby/io/extras/osxvm/build/osxvm.build/Development/osxvm.build/Objects-normal/x86_64/Stack.o

and /Users/xxx/hobby/io/extras/osxvm/build/osxvm.build/Development/osxvm.build/Objects-normal/x86_64/List.o

List_size 関数が、List.o 上ではグローバルで、Stack.o 上では inline として定義されているみたいです。

inline なので static になってくれればいいのですが、どうも static にならないので、Duplicated になっているみたい。

なので、ただの inline ではなく static inline にすれば大丈夫だろう、と考えました。

ということで、libs/basekit/source/Common_inline.h を修正してみました。

diff --git a/libs/basekit/source/Common_inline.h b/libs/basekit/source/Common_in

index 1b122c1..3759d9f 100755

--- a/libs/basekit/source/Common_inline.h

+++ b/libs/basekit/source/Common_inline.h

@@ -46,7 +46,7 @@ Kudos to Daniel A. Koepke

#else

// in .h

#define IO_DECLARE_INLINES

- #define IOINLINE inline

+ #define IOINLINE static inline

#endif

#elif defined(__MINGW32__)

#ifdef IO_IN_C_FILE

これで上のエラーは無くなります。

■ビルド

あとは、Xcode でビルドすれば、osxvm がビルド出来ます。

出来たバイナリを適当なディレクトリに突っ込めば終わり。

Autodesk 123D でさるぼぼつくって、いろんな視点で MPO にして 3DS で表示できるようにしてみました

2011-07-18T19:00:00.009+09:00

Autodesk さんが、Autodesk 123D なる無料で使える 3D CAD を出していて、大変使ってみたくなりました。

http://www.123dapp.com/

あと、3DS を持っているのですが、そのブラウザで 3D 写真を見るのが案外楽しいです。

例えばこのサイトで、3DS の 3D 写真(MPOフォーマット)をアップロード出来、見ることが出来ます。

HAGERIUM http://hage.my-sv.net/

ということで。

Autodesk 123D でモデリングして、MPO を作ってみるしかない、と思いました。

最初に今回 Autodesk 123D で作成したモデルである、さるぼぼくんを。

機械設計は結構書いたことがあったのですが、こういうモデルは書いたことなくてむっさ苦労しました・・・。

では、作り方とか解説は省略して、視点を表す図と MPO を上げておきます。

MPO の作成は、StereoPhoto Maker を使っています。

http://stereo.jpn.org/jpn/stphmkr/

1. 立体視なし

http://dl.dropbox.com/u/544268/mpo/center-front.mpo

2. 立体視あり

http://dl.dropbox.com/u/544268/mpo/center-angle1.mpo

3.さるぼぼが画面の奥にいる感じ

http://dl.dropbox.com/u/544268/mpo/backward-angle1.mpo

4. さるぼぼが画面から飛び出す

http://dl.dropbox.com/u/544268/mpo/forward-angle1.mpo

5.視点が並行

http://dl.dropbox.com/u/544268/mpo/center-flat.mpo

Emacs + auto-complete-clang

2011-05-24T23:32:00.010+09:00

ちょっと Xcode について徘徊していたら、auto-complete-clang なるものを発見。

Emacs の auto-complete の補完を、Eclipse や Visual Studio のように候補となるメソッド名で出来るようにするものみたい。

次のが手元で試した際の動作例。たしかに、Hoge::Fugaなどが補完候補にでてきててすごい！

ひとまずこのサイト( http://www.nomtats.com/2010/11/auto-completeelemacs.html )にしたがって、auto-complete-clang.el をインストール。

.emacs に上記サイトの elisp をそのまま追記して試してみた。でも動かず。

エラーをみると、auto-complete-config (ac-configだったか?) が無いとのこと。

そういえば、手元の auto-complete.el は手動でインストールしたもので古いなーと思ったので、一度削除して、auto-install-batch を使って改めてインストールし直し。

----------

auto-install-batch は、「Emacs テクニックバイブル」で紹介されている、auto-install.el の機能。Emacs Lisp プログラムを自動でインストールしてくれます。

http://d.hatena.ne.jp/rubikitch/20091221/autoinstall

M-x auto-install-batch として、auto-complete を探せば見つかるはず。

----------

そしたら無事、clang がコンパイルを実行するところまでは動いたみたい。

でも、コンパイルでエラー。stdafx.pch を用意してないからいけない模様。

先のサイトの"(setq ac-clang-prefix-header "stdafx.pch")" をコメントアウトすれば動くようになるので、ひとまずそうやって動作を確認。

ただ、補完しようとする際結構もさっとするので、やっぱプリコンパイルヘッダを用意しないと非効率みたい。

ということで、今度はプリコンパイルヘッダを使えるようにする。と言っても以下のサイトを参照するとすぐ。

http://d.hatena.ne.jp/whitypig/20110306/1299416655

自分がよく使うヘッダファイルをずらずら書き連ねて、それをプリコンパイルするだけ。

その成果物として、stdafx.pch が出来る。

あとはこれを、clang がアクセスする場所においておけばいい。

とりあえず、現在編集している*.cpp ファイルのある場所に置いておけば参照してくれる。

なので、*.cpp とか Makefile とかの、プロコン用 *.cpp のためのテンプレの中に、先ほど作成した stdafx.pch 突っ込んでおきました。

ひとまずこれで、単一ファイルの *.cpp は大変快適になったはず。

ただ、複数ファイルに分かれる場合どうなるんだろう？プリコンパイルヘッダ使ってしまうと、それ以外のヘッダ読み込んでくれなかったりしないのかな？

冷静に考えると、プロジェクトごとにプリコンパイルヘッダをつくることになりそう。

ぼそっ

2011-04-14T23:22:00.002+09:00

自分は、「自分に厳しく、人に厳しく」という感じで生きてきた。
そのほうが、最終的に良い結果になると思っていたから。
もちろん厳しいだけじゃなくって、その分助けて、助けてもらって、頑張ってきたつもり。

気に入った人は、逆に、厳しくした気がする。

でもそれじゃだめなんだ、ずっと後悔して、考えて。

エコノムーブはこの先どーする？

2011-04-13T22:43:00.002+09:00

地震とかで大変で、大会があるのかわからないけれども、二年前のエコノの知識をもってこの先どーなるのか考察してみる。
実際作る時間とかは無いはずなので、あくまで妄想でしかないけれどｗ

基礎知識。エコノムーブの三大損失。

転がり抵抗[W] 速度の1乗に比例
空気抵抗[W] 速度の3乗に比例。風の方向から見たときの面積 (前方投影面積)の1乗に比例。形状に依存
電気損[W] その他

今後記録が伸びていくことを考えると、速度の3乗が問題の空気抵抗をいかに減らすかが課題。
なので、多少重くなっても、いかに空気抵抗を減らすかの勝負になるはず。
それで考えるのが、

トレッドをせまく
外部はカメラで見る
全高はそのまま、地上高をがっとあげる

こんなところ。こうすると、きっと人を真上 or 真下から見たときの前方投影面積に近くなると思う。

問題は、コーナーが圧倒的に脆弱になること。トレッドが狭く、地上高が高かったら、すぐに横転してしまうはず。
これは、車体をかたむける機構を導入すれば万事解決でなかろうか？
地上高が高いのも、傾けるの前提になればまがりやすさにつながりもするはずだし。

# 2輪という選択肢もある

Windowsでどーやってログをとる？

2011-04-10T23:29:00.004+09:00

初期（評価）版AOVCSは、Mac で作った。
これは、その時点で dtrace を知っていて、それを使えばほしいトレースが取れるとわかっていたから。（とは言っても、実際に本当に必要な情報を取得しようとしたら相当苦労したけれども）

※ほしいトレース

ファイルの操作ログ（どのファイルをどういう処理した？）
操作を行ったプロセス名、その親のプロセス名、親の親のプロセス名、、
プロセス系のシステムコール (親のプロセス名を取得するため)

Linuxに移植しようとしたら、同等、あるいはそれ以上の機能を提供するSystemTapを使えばOK。

今回Windows に移植するとすると、このログ相当のものをどうやって取得するかが問題になる。
Windowsのシステムコール監視とか、どうやってやるのか全然詳しくない。
ということで調査しました。

1. FileSystemWatcher
http://www.atmarkit.co.jp/fdotnet/dotnettips/281filewatch/filewatch.html
指定したディレクトリ以下のファイル操作を、Notification として教えてくれる API。
ファイル操作のログを取得するということであれば、これで充分だが、今回アプリケーション名を取得しないと意味がないため、不十分。
(上記ページの、NotifyFilters 参照）

2. Directory Change Notifications
http://msdn.microsoft.com/en-us/library/aa365261(v=vs.85).aspx
ちょっと良く調べてないけれども、機能的には上記FileSystemWatcher のC言語でのAPIに視える。
要調査。

3. tracelog
http://msdn.microsoft.com/en-us/library/ff552961(v=VS.85).aspx
いろんなところにtraceを仕掛けられるらしい、Windows Driver Kit の中のツール。
dtrace 的なカンジがするので、現状これを調べているところ。

管理者権限で実行しないといけない（シェル起動を、右クリック-> 管理者権限）
プロバイダ (トレースポイント) に何があるかイマイチわからない
TraceView という、tracelog のGUI版でみる限り、あまり情報が取得できない？ (ファイル名が取れてない、Process ID が取れてない）

とかな状態。もっとこの機能は調べないとわからないですね。

とりあえず上記の画面は、Create New Log Session -> Add Provider -> Kernel Logger (Process, File I/O ) -> OK でとっている情報。system.tmfは、 WinDDK/*/tools/tracing/amd64/内にあります。

ブログ復帰？

2011-04-08T22:47:00.002+09:00

Windows版のAOVCSデーモンと、Git用のAOVCS拡張を作る計画をしています。
夜とかにこつこつと調べてやるつもりですが、出来るかなー？

■こんな感じ

ファイルのメタデータとして、ファイル作成ログはつけたい。無理なら、汎用的なメタデータをつける仕組みを用意することにする。削除ログはどちらにせよメタデータの仕組みを用意しないといけない
GitのStaging Areaはひとまずあきらめる。従来と同じ全部コミット型。もったいないけど

fsloggerの調査 (4)

2010-02-17T23:32:00.003+09:00

fsloggerの調査その4．今度はFSEventによって取得した情報の解析方法．fsloggerのコードを読むと，次のコードで解析が出来る事がわかる．

fileTrace.h：

#ifndef FILE_TRACE_H
#define FILE_TRACE_H

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/sysctl.h> // uint32_t
#include <sys/fsevents.h>

const char *DEV_FSEVENTS="/dev/fsevents"; // fsevent device
const int EVENT_QUEUE_SIZE=4096;          // limited by MAX_KFS_EVENTS
const int FSEVENT_BUFFER_SIZE=131072;     // copied from fslogger.c

// copied from fslogger.c
// an event argument
typedef struct kfs_event_arg {
 u_int16_t  type;         // argument type
 u_int16_t  len;          // size of argument data that follows this field
 union {
     struct vnode *vp;
     char         *str;
     void         *ptr;
     int32_t       int32;
     dev_t         dev;
     ino_t         ino;
     int32_t       mode;
     uid_t         uid;
     gid_t         gid;
     uint64_t      timestamp;
 } data;
} kfs_event_arg_t;

#define KFS_NUM_ARGS  FSE_MAX_ARGS

// an event
typedef struct kfs_event {
int32_t         type; // event type
pid_t           pid;  // pid of the process that performed the operation
kfs_event_arg_t argHead; // head of event arguments, other events continue after this
} kfs_event;

#endif // FILE_TRACE_H

fileTrace.c：

#include "fileTrace.h"

static int fseventFd;

// event names
static const char *kfseNames[]={
 "FSE_CREATE_FILE",
 "FSE_DELETE",
 "FSE_STAT_CHANGED",
 "FSE_RENAME",
 "FSE_CONTENT_MODIFIED",
 "FSE_EXCHANGE",
 "FSE_FINDER_INFO_CHANGED",
 "FSE_CREATE_DIR",
 "FSE_CHOWN",
 "FSE_XATTR_MODIFIED",
 "FSE_XATTR_REMOVED",
};
// argument names
static const char *kfseArgNames[] = {
 "FSE_ARG_UNKNOWN", "FSE_ARG_VNODE", "FSE_ARG_STRING", "FSE_ARGPATH",
 "FSE_ARG_INT32",   "FSE_ARG_INT64", "FSE_ARG_RAW",    "FSE_ARG_INO",
 "FSE_ARG_UID",     "FSE_ARG_DEV",   "FSE_ARG_MODE",   "FSE_ARG_GID",
 "FSE_ARG_FINFO",
};

void readFSEventLoop()
{
int ret, off, eoff;
char buffer[FSEVENT_BUFFER_SIZE];
kfs_event_arg_t *kea;
int argID;

while(1){
 if((ret=read(fseventFd, buffer, sizeof(buffer)))>0){
   printf("Received %d bytes\n", ret);
 }
 off=0;

 while(off<ret){
   struct kfs_event *kfse=(struct kfs_event *)((char *)buffer+off);
   off+=sizeof(kfse->type)+sizeof(kfse->pid); // skip type & pid

   if(kfse->type==FSE_EVENTS_DROPPED){
     printf("# Event\n");
     printf("  %-14s = %s\n", "type", "EVENTS DROPPED");
     printf("  %-14s = %d\n", "pid", kfse->pid);
     off += sizeof(kfse->argHead.type); // FSE_ARG_DONE: sizeof(type)
     continue;
   }

   int32_t aType=kfse->type & FSE_TYPE_MASK;
   uint32_t aFlags=FSE_GET_FLAGS(kfse->type);

   if((aType<FSE_MAX_EVENTS) && (aType>=-1)){
     printf("# Event\n");
     printf("  %-14s=%s", "type", kfseNames[aType]);
     if (aFlags & FSE_COMBINED_EVENTS) {
       printf("%s", ", combined events");
     }
     if (aFlags & FSE_CONTAINS_DROPPED_EVENTS) {
       printf("%s", ", contains dropped events");
     }
     printf("\n");
   } else { // should never happen
     printf("This may be a program bug (type = %d).\n", aType);
     exit(1);
   }
   printf("  %-14s = %d\n", "pid", kfse->pid);
   printf("  # Details\n    # %-14s%4s  %s\n", "type", "len", "data");

   kea=&(kfse->argHead);

   while(off<ret){
     if(kea->type==FSE_ARG_DONE){ // no more arguments
       printf("    %s (%#x)\n", "FSE_ARG_DONE", kea->type);
       off += sizeof(kea->type); // no len field
       break;
     }
     eoff=sizeof(kea->type)+sizeof(kea->len)+kea->len;
     off+=eoff;

     argID=(kea->type > FSE_MAX_ARGS) ? 0 : kea->type;
     printf("    %-16s%4hd\n", kfseArgNames[argID], kea->len);
     kea = (kfs_event_arg_t *)((char *)kea + eoff); // next
   }
 }
}
close(fseventFd);
}

とりあえずこれで各イベントを読み込んで，その種類を書きだすことが出来る．読み込む情報の構造は次の図に示すとおり．

1イベントの情報長は不定．kfs_event構造体でアクセス出来るのは，最初のkfs_event_argだけである．それ以降のkfs_event_argについては，len情報を使って順に辿る必要がある．
kfs_event_argの終端は，そのtypeがFSE_ARG_DONEかどうかで判断する．もしFSE_ARG_DONEであった場合，そこにはlen情報やdata情報は存在しない．その点を間違えると，次のkfs_event情報が不正なものになるので注意．

fsloggerの調査 (3)

2010-02-13T18:16:00.004+09:00

fsloggerの調査その3．今回は，FSEventの初期化をどうするかの部分．

fslogger.cのコードリーディングをすると，次のコードで大丈夫なことが分かった．このコードは，読み込みの部分まで実装し，正しく読み込めることを確認した上で掲載している．
fileTrace.h：

#ifndef FILE_TRACE_H
#define FILE_TRACE_H

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/sysctl.h> // uint32_t
#include <sys/fsevents.h>

const char *DEV_FSEVENTS="/dev/fsevents"; // fsevent device
const int EVENT_QUEUE_SIZE=4096;          // limited by MAX_KFS_EVENTS

#endif // FILE_TRACE_H

fileTrace.c：

#include "fileTrace.h"

static int fseventFd;

int initFileTrace()
{
int fd;
struct fsevent_clone_args fca;
int8_t eventList[]={ // Which event to be traced
FSE_REPORT, // FSE_CREATE_FILE
FSE_REPORT, // FSE_DELETE
FSE_IGNORE, // FSE_STAT_CHANGED
FSE_REPORT, // FSE_RENAME
FSE_IGNORE, // FSE_CONTENT_MODIFIED
FSE_IGNORE, // FSE_EXCHANGE
FSE_IGNORE, // FSE_FINDER_INFO_CHANGED
FSE_REPORT, // FSE_CREATE_DIR
FSE_IGNORE, // FSE_CHOWN
FSE_IGNORE, // FSE_XATTR_MODIFIED
FSE_IGNORE  // FSE_XATTR_REMOVED
};

// confirm user ID (this requires root priviledge)
if(geteuid()!=0){
perror("This requires root priviledge.");
exit(1);
}

// open fsevents device
if((fd=open(DEV_FSEVENTS, O_RDONLY))<0){
perror("Open fsevents device.");
exit(1);
}

// create fsevents_clone_args (refer to bsd/fsevents.h)
fca.event_list=(int8_t *)eventList;
fca.num_events=sizeof(eventList)/sizeof(int8_t);
fca.event_queue_depth=EVENT_QUEUE_SIZE;
fca.fd=&fseventFd;

// control fsevent device
if(ioctl(fd, FSEVENTS_CLONE, (char *)&fca)<0){
perror("ioctl");
close(fd);
exit(1);
}
close(fd);
printf("FSEvents device is cloned\n");

// set the format of fsevents output
if(ioctl(fseventFd, FSEVENTS_WANT_EXTENDED_INFO, NULL)<0){
perror("ioctl");
close(fseventFd);
exit(1);
}
printf("Ready for events\n");
return 0;
}

int main()
{
initFileTrace();
return 0;
}

やっていることを簡単にまとめると次の通り．

取得するイベントの指定 (FSE_IGNORE / FSE_REPORT)
ルート権限の確認
FSEventデバイスファイルのオープン
ioctl命令を用いて，FSEventデバイスの制御 (指定したイベントのクローン作成を指示)
ioctl命令を用いて，FSEventで取得する情報の形式をEXTENDEDに指定

以上．

情報の形式がEXTENDEDの場合は，FSEventで取得出来るファイル情報が，細かく分かれて取得出来る．つまり，デバイスIDやinode番号が別々のフィールドとして取得出来る．
一方，FSEVENTS_WANT_COMPACT_EVENTSを指定すると，デバイスIDやinodeがひとつのフィールド(FSE_ARG_FINFO)にごちゃっとまとめられる．この場合は，fse_info構造体を用いてその情報にアクセスすれば良い．その辺りの情報は，sys/fsevents.hの次の部分に書いてある．


#define FSE_ARG_FINFO    0x000c   // next arg is a packed finfo (dev, ino, mode, uid, gid)
#define FSEVENTS_WANT_COMPACT_EVENTS _IO('s', 101)
#define FSEVENTS_WANT_EXTENDED_INFO _IO('s', 102)

// misc utility functions for fsevent info and pathbuffers...
typedef struct fse_info {
 ino64_t    ino;
 dev_t      dev;
 int32_t    mode;   // note: this is not a mode_t (it's 32-bits, not 16)
 uid_t      uid;
 gid_t      gid;
 uint64_t   nlink;  // only filled in if the vnode is marked as a hardlink
} fse_info;

初期化に必要なのはこの位のはず．

fsloggerの調査 (2)

2010-02-12T15:17:00.002+09:00

fsloggerの調査つづき．とりあえず-m32をつければ正しくコンパイル出来る事を確認したので，ソースコードの中身を読むことにする．

fsloggerが読み込んでいるヘッダは次の通り．

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/sysctl.h>
#include <sys/fsevents.h>
#include <pwd.h>
#include <grp.h>

この中で重要なのはsys/fsevents.h．なのでそちらのコードを参照してみる．このヘッダファイルは，xnuのソース内のbsd/sys/fsevents.hに存在する．そこの重要な所だけ抜き出してみる．

// Event types that you can ask to listen for
#define FSE_INVALID             -1
#define FSE_CREATE_FILE          0
#define FSE_DELETE               1
#define FSE_STAT_CHANGED         2
#define FSE_RENAME               3
#define FSE_CONTENT_MODIFIED     4
#define FSE_EXCHANGE             5
#define FSE_FINDER_INFO_CHANGED  6
#define FSE_CREATE_DIR           7
#define FSE_CHOWN                8
#define FSE_XATTR_MODIFIED       9
#define FSE_XATTR_REMOVED       10

#define FSE_MAX_EVENTS          11
#define FSE_ALL_EVENTS         998

#define FSE_EVENTS_DROPPED     999

//
// These defines only apply if you've asked for extended
// type info.  In that case the type field's low 12-bits
// contain the basic types defined above and the top 4
// bits contain flags that indicate if an event had other
// events combined with it or if it represents a directory
// that has dropped events below it.
//
#define FSE_TYPE_MASK          0x0fff
#define FSE_FLAG_MASK          0xf000
#define FSE_FLAG_SHIFT         12
#define FSE_GET_FLAGS(type)    (((type) >> 12) & 0x000f)

#define FSE_COMBINED_EVENTS          0x0001
#define FSE_CONTAINS_DROPPED_EVENTS  0x0002


// Actions for each event type
#define FSE_IGNORE    0
#define FSE_REPORT    1
#define FSE_ASK       2    // Not implemented yet

// The types of each of the arguments for an event
// Each type is followed by the size and then the
// data.  FSE_ARG_VNODE is just a path string
#define FSE_ARG_VNODE    0x0001   // next arg is a vnode pointer
#define FSE_ARG_STRING   0x0002   // next arg is length followed by string ptr
#define FSE_ARG_PATH     0x0003   // next arg is a full path
#define FSE_ARG_INT32    0x0004   // next arg is a 32-bit int
#define FSE_ARG_INT64    0x0005   // next arg is a 64-bit int
#define FSE_ARG_RAW      0x0006   // next arg is a length followed by a void ptr
#define FSE_ARG_INO      0x0007   // next arg is the inode number (ino_t)
#define FSE_ARG_UID      0x0008   // next arg is the file's uid (uid_t)
#define FSE_ARG_DEV      0x0009   // next arg is the file's dev_t
#define FSE_ARG_MODE     0x000a   // next arg is the file's mode (as an int32, file type only)
#define FSE_ARG_GID      0x000b   // next arg is the file's gid (gid_t)
#define FSE_ARG_FINFO    0x000c   // next arg is a packed finfo (dev, ino, mode, uid, gid)
#define FSE_ARG_DONE     0xb33f   // no more arguments

#define FSE_MAX_ARGS     12

// ioctl's on /dev/fsevents
#if __LP64__
typedef struct fsevent_clone_args {
   int8_t  *event_list;
   int32_t  num_events;
   int32_t  event_queue_depth;
   int32_t *fd;
} fsevent_clone_args;
#else
typedef struct fsevent_clone_args {
   int8_t  *event_list;
   int32_t  pad1;
   int32_t  num_events;
   int32_t  event_queue_depth;
   int32_t *fd;
   int32_t  pad2;
} fsevent_clone_args;
#endif

#define FSEVENTS_CLONE  _IOW('s', 1, fsevent_clone_args)

// ioctl's on the cloned fd
#if __LP64__
#pragma pack(push, 4)
typedef struct fsevent_dev_filter_args {
   uint32_t  num_devices;
   dev_t    *devices;
} fsevent_dev_filter_args;
#pragma pack(pop)
#else
typedef struct fsevent_dev_filter_args {
   uint32_t  num_devices;
   dev_t    *devices;
   int32_t   pad1;
} fsevent_dev_filter_args;
#endif

ちょっと多くなったが，fsloggerのソースコードを参照する上で必要なのはきっとこれで全部のはず．しかしenum使わないんだなーdefineなんだなー．

これらの意味は，ソースコードの説明する際に必要に応じて示すことにする．

fsloggerの調査

2010-02-10T21:17:00.004+09:00

fsloggerの調査を行う．

前回，xnuのソースコードをダウンロードし，そのヘッダファイルを用いることでコンパイル出来ると述べた．これでコンパイルは正しく出来，実行も出来るのであるが，結果がおかしい事になる．

次が実行例．

# Event
type           = FSE_CREATE_FILE
pid            = 56878 (optimizer)
# Details
# type           len  data
FSE_ARG_STRING    35  string = rs/hitoshi-s/.aovcs.db-journal
FSE_ARG_DEV        4  dev    = 0x040007 (major 0, minor 262151)
FSE_ARG_INO        4  ino    = 262154
FSE_ARG_MODE       4  mode   = ?-----x---  (0x040008, vnode type VNON)
FSE_ARG_UID        4  uid    = 262155 (?)
FSE_ARG_GID        4  gid    = 524293 (?)
FSE_ARG_INT64      8  tstamp = 197083164404091
FSE_ARG_DONE (0xb33f)

stringの先頭が切れていたり，アクセス権(mode)の表示がおかしかったりしている．これはよろしくない．

そこで色々試行錯誤をした結果，64bitでコンパイルすると駄目，という事がわかった．つまり，コンパイルは次のとおりに行う必要がある．

 $ gcc -Ibsd -m32 fslogger.c
(bsdは，xnuカーネルのソースコード内のディレクトリ)

こうすることでコンパイルが正しく出来，実行結果も正しくなる．その結果が次．

# Event
 type           = FSE_CREATE_FILE
pid            = 56878 (optimizer)
# Details
 # type           len  data
 FSE_ARG_STRING    35  string = /Users/hitoshi-s/.aovcs.db-journal

 FSE_ARG_DEV        4  dev    = 0xe000002 (major 14, minor 2)
 FSE_ARG_INO        4  ino    = 18352091
 FSE_ARG_MODE       4  mode   = -rw-r--r--  (0x0081a4, vnode type VREG)
 FSE_ARG_UID        4  uid    = 502 (hitoshi-s)
 FSE_ARG_GID        4  gid    = 20 (staff)
 FSE_ARG_INT64      8  tstamp = 397689684106485
 FSE_ARG_DONE (0xb33f)

ちゃんとパスも全部表示され，modeも正しい．ユーザ名とかも表示出来た．とりあえず今回の場合は，-m32をつけてコンパイルすれば良いという事である．

しかしこれでいつでも動くとは限らない．今回確認した環境はMac OS X 10.6で，アプリケーションのデフォルトコンパイル対象は64bit環境である．しかし，カーネル(PID:0, kernel_task)は32bitで動いている．これがもし64bitになると，-m64でないとむしろ正しく動かないという事は十分考える事が出来る．fsloggerが，カーネル内のFSEventという仕組みを用いている事を考えると，これは十分あり得る話である．

これは，Mac OS Xのユニバーサルバイナリ/ファットバイナリではうまく対処出来ない．正しく対処するには，自分でkernel_taskのモード(32bit/64bit)を調べ，それに応じたバイナリを実行する等が必要であろう．

Mac用の高速デーモン作成計画

2010-02-09T21:02:00.003+09:00

お久し振りです．まだこのブログは続きます．

現在，ファイル操作を行ったアプリケーションが何かと言う情報を収集するために，dtraceを用いています．なお収集作業を行うデーモンを，ここではAOVCSデーモンと呼びます．

dtraceを用いた実装方法では，収集する情報の正確性において問題はありません．しかし，速度という面では問題が有ります．configureを実行する場合，AOVCSデーモンを有効にしたか否かで実測時間が4倍ほど差が出てきてしまいます．
現在の予想は，dtraceの出力を受け取るためのパイプ(pipe)がボトルネックになっているというものです．しかし，パイプサイズの変更は難しそうです．

(以下から丁寧語ではなくなります)

そこで，以前から調べてあった，FSEventという仕組みを用いることにする．これは，Mac OS X内のファイル操作のイベント情報を収集するための仕組みである．Spotlightがメタ情報を構築する際も，この仕組みを用いている．

この方法は，Mac OS X Internalsで説明されており，Webサイトでも説明されている．
http://osxbook.com/software/fslogger/

ソースコードもあるが，これをコンパイルするにはカーネルのヘッダファイルが必要である．これは，次のサイトからダウンロード出来る．
http://www.opensource.apple.com/
xnu内のbsdディレクトリがそれである．そうしたら，"gcc -I/bsd/dir/path fslogger.c"とすることでコンパイル出来る．

で，このFSEventという仕組みだが，上記で述べた仕組みはAppleは公開していない．Appleが公開しているのは同じFSEventという名前の，もう少し機能が制限された仕組みである．
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html

特定のディレクトリを指定すると，そこに何か変更が起こった場合に通知を行うという仕組みである．具体的なファイルやディレクトリの情報は取得出来ず，自分で調べる必要がある．

今回実現したい機能に必要なのは，各ファイルがどのプロセスによって変更されたか，という情報である．上記の，ディレクトリ内に何か変更がある，という情報だけでは足りない．つまり，Appleが公開している機能では不十分なのである．

そのため，Appleが公開していない，FSEventのより細かい機能を利用する必要がある．利用方法は，先のfsloggerのソースコードを参照すればよい．本ブログでは以後，この利用方法を詳しく調べ，まとめていく．

Mercurialのプラグイン作成方法 (2)

2009-12-13T17:35:00.002+09:00

Mercurialのプラグイン，もうちょっとだけ調べた．とりあえず，AOVCSが状態をセットしなければならないファイルの一覧の取得をば．

from mercurial import hg

def tobeset(ui, repo, **opts):
   """ just display files to be set status """
   ui.write("Disappeared files:\n")
   for filename in repo.status(unknown=True)[3]: # 3 is disappeared                               
       ui.write("  "+filename)
       ui.write("\n")

   ui.write("Unknown files:\n")
   for filename in repo.status(unknown=True)[4]: # 4 is unknown files                             
       ui.write("  "+filename)
       ui.write("\n")

cmdtable={
   "tobeset": (tobeset,
               [],
               "")
}

関数名が非常に適当だけど，これで一覧が取得出来る．実行例は次．

$ hg tobeset
Disappeared files:
 foo.o
Unknown files:
 bar
 foofoo
 foofoo.o

あとはこいつらの情報をAOVCSのDBから取得して，状態を決定して，設定すれば良い．

Mercurialのプラグイン作成方法

2009-12-11T17:14:00.002+09:00

今度はMercurialのプラグイン作成方法を簡単に調べた．

MercurialはBazaar同様Pythonで書かれており，再コンパイルなどはする必要が無い．また，プラグインの作り方は，Bazaarほど詳しくはないが，次の2つのページを参照すると良い．

http://mercurial.selenic.com/wiki/WritingExtensions (プラグインの書き方)
http://mercurial.selenic.com/wiki/UsingExtensions (プラグインの設定方法)

とりあえずGitと同様Helloを実装する．まずは，プラグインの設定．~/.hgrcに以下を記述．

 [extensions]
hello=~/.hgext/hello.py

こうすることで，hello.pyをプラグインとして読み込む様になる．そしたら今度は，hello.pyの編集．プラグインの書き方を参照しながら，helloと言わせる多分最低限のコードを作った．

from mercurial import hg

def hello(ui, node, **opts):
   """ Say hello """
   ui.write("Hello\n")

cmdtable={
   # cmd  :  func, opts, help
   "hello": (hello, [], "")
}

これを~/.hgext/hello.pyとして保存すると，何かしらのリポジトリ内であれば次の通りに動く．

$ hg hello
Hello

もし，リポジトリ内でなくても動く様にしたければ，上記のコードを次の通り修正する．

from mercurial import hg, commands

def hello(ui, **opts):
   """ Say hello """
   ui.write("Hello\n")

commands.norepo+=" hello"
cmdtable={
   # cmd  :  func, opts, help
   "hello": (hello, [], "")
}

やることは，mercurial.commandsをインポートし，commands.norepoにhelloを追加し，hello関数からnodeを取り除くということである．

これでプラグインの作り方は分かったので，あとはGit同様に，ファイル状態設定のAPIを参照する事になる．Mercurialは，次のページにAPIのドキュメントがある．

http://mercurial.selenic.com/wiki/MercurialApi

今度はここを参照すれば良い．

Gitのプラグイン？拡張コマンド？の作り方

2009-12-10T23:07:00.006+09:00

AOVCSの拡張を，Bazaar以外に移植する事を考える．まずはGitが対象．

Gitは，調べた限りプラグインを作成する方法は無い．そのため，Gitのソースコードを直接編集することになる様だ．まずは，Gitをコンパイルする環境を整える．今回は，Linux 2.6.27.38-170.2.113.fc10.x86_64にて行った．

(2009/12/16追記：コメントにもありますが，git-hogeというコマンド(バイナリ/シェルスクリプト)をパスの通ったところに作成すると，git hogeとすることで，gitが"git-hoge"を探索，実行してくれるというメカニズムがあります)

まず今回インストールしたコマンド達．

git (リポジトリのダウンロードに必要)
autoconf (コンパイルに必要)
zlib-devel (コンパイルに必要)
perl-ExtUtils-MakeMaker (コンパイルに必要)

これらをyum経由でインストールすれば，コンパイル環境は出来た事になる．

次にコンパイルの手順．

"git clone git://git.kernel.org/pub/scm/git/git.git"を実行，ソースのダウンロード (http://git-scm.com/download 参照)
make configure (リポジトリ内のINSTALL参照)
./configure (INSTALL参照)
make (INSTALL)

多分これでコンパイルが成功する．そしたら次に拡張を作成する．拡張の作成は，次のサイトにあるapi-builtin.txtが非常に参考になる．
http://repo.or.cz/w/git.git?a=tree;f=Documentation/technical;hb=HEAD

やるべき事をまとめると次の通り．今回は，hogeという，helloを出力するだけのコマンドを作成してみる．

builtin-hoge.cを作成し，int cmd_hoge(int argc, const char **argv, const char *prefix);を定義 (printfするだけ)
builtin.hに，int cmd_hoge(int argc, const char **argv, const char *prefix);のプロトタイプ宣言を追加
git.c内のcommands[]に，{"hoge", cmd_hoge, 0}を追加 (0の意味はapi-builtin.txtを参照)
Makefile内のBUILTIN_OBJSに，builtin-hoge.oを追加

これでコンパイルをすれば，無事hogeを定義出来る．案外簡単．実行例は次．

$ ./git hoge
hello

次は，cmd_hogeの中で使えるAPIが何かを調査する必要がある．

AOVCSの移植性調査 - Linux with SystemTap

2009-12-07T22:33:00.006+09:00

結構間が開いてしまいました．この間はずっと論文で評価の部分を書いてました．

で，一応その辺の記述が一通り終わったため，今度はAOVCSを他の環境へ移植する方法の調査を行うことに．まずは，LinuxでSystemTapを用いた実装の調査．

SystemTapは，Solarisのdtraceを受けてLinux側がそれと同等かそれ以上の機能を持たせようとしたツール．というのが自分の解釈．なのでMac OS Xでdtraceを用いて実装したのとだいたい同じ方法で，Linuxでもデーモンを作成出来ると期待している．

とりあえず，SystemTapのリファレンスを一通り読む．
http://sourceware.org/systemtap/documentation.html
これの，Language Referenceという所．

さて，読んで見たところ，次のあたりがdtraceと違うようだ．

スレッドローカル変数が無い(dtraceにおけるself->．一応連想配列で代用は出来る)
ネイティブコードに変換し，カーネルモジュールとして読み込み，実行する(dtraceは，仮想命令をインタプリトする)
ネイティブコード(C言語)を直接記述出来る
カーネルのトレースには，デバッグ情報が必要(debuginfo-installコマンドを利用)
関数が定義可能
制御フロー命令が利用可能

案外違うところが多い．でもまあなんとかなるかな？

ただ，リファレンスを読んでいると，dtraceにあるようなデフォルトで用意される情報群がどうも少ない．pidとかuidとかは取得できるのだが，Mac OS Xで苦しんだCWD (Current Working Directory)を取得するコマンドが，SystemTapにおいても見つからない．

これは困った．これが取得出来ないと，SystemTapを使えば実装出来るよ！と主張するのは難しい．そこで，SystemTapの勉強もかねてCWDをどうにかして取得してみよう．

まず，何かの情報からファイルのフルパスを取得出来ないものかとググってみた．すると，次のサイトを発見．

http://lwn.net/Articles/345341/
ここの文章を引用したのが次．

"The dentry tapset provides functions to map kernel VFS directory entries
to file or full path names: d_path(), d_name() and reverse_path_walk()."

どうやらdentryを与えればそのファイルのフルパスを取得出来るようだ．そこで次の戦略．

どうにかしてCWDへのdentryを取得して，reverse_path_walkを用いてフルパスを取得すれば良い
CWDの情報は，きっとプロセス情報か何かが持っているはず
プロセス情報っぽいのは，SystemTapのスクリプト内でtask_current()関数を呼べば取得出来る
task_current()で取得出来る情報は，task_struct構造体 (/usr/share/systemtap/tapset/task.stp参照)の模様

ここまで情報がわかったので，今度はLinuxカーネル第三版を参照して，task_structが何者かを見る．すると，3.2節にその大まかな構造が載っていて，その中のfsというメンバに，カレントディレクトの情報があるということがわかった．あとはその中身をたどれば良さそう．そこで，リファレンスを読みながら次のコードを作成．

probe syscall.open
{
     printf("%d\n", @cast(task_current, "task_struct", "kernel")->fs->pwd.dentry);
}

しかしこれだとエラー．エラーメッセージは次の通り．

semantic error: 'struct path' is being accessed instead of a member: identifier '@cast' at :3:17
     source:  printf("%d\n", @cast(task_current, "task_struct", "kernel")->fs->pwd.dentry);

最初はよくわからなかったが，これは，SystemTapには構造体の中身にアクセスするドット演算子が無いから起こるようだ．アロー(->)はあるのに．ぬぅ．どうやらここは，Cを直接記述するしかない．そこで今度はインライン(?)Cの書き方を参照して，次のコードにする．

function getCwdEntry:long (task:long)
%{
struct fs_struct *fs=((struct task_struct *)THIS->task)->fs;
THIS->__retvalue=(long)fs->pwd.dentry;
%}

probe syscall.open
{
printf("%s\n", reverse_path_walk(getCwdEntry(task_current())));
}

これで無事，CWDを取得することに成功した．実行例は次．-gオプションを付けないとインラインCの記述が通らない．これに結構はまった．

$ sudo stap -g cwd.stp
usr/share/systemtap/tapset/powerpc/
usr/share/systemtap/tapset/
usr/share/systemtap/tapset/s390/
usr/share/systemtap/tapset/
usr/share/systemtap/tapset/ia64/
usr/share/systemtap/tapset/
usr/share/systemtap/tapset/x86_64/
usr/share/systemtap/tapset/
usr/share/systemtap/tapset/test/
usr/share/systemtap/tapset/
usr/share/systemtap/tapset/i386/

これはtapsetディレクトリ内でfindした結果のトレース．うん，ちゃんと取れてる．

AOVCSの実用性検証 - /usr/bin内，/Developer/usr/bin/内，/opt/local/bin/内編 (2)

2009-11-24T23:39:00.002+09:00

/usr/bin内，/Developer/usr/bin/内，/opt/local/bin/内のコマンドの設定を作成する．前回示したコマンドを一応一通り作成した．それが次．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-configurations>
 <action-sets>
   <!-- configuration for primary-file-generate applications -->
   <action-set name="primary">
     <create action="auto" type="weak" />
     <remove action="auto" type="weak" />
   </action-set>
   <!-- configuration for do-fork and primary-file-generate applications such as shell script -->
   <action-set name="primary-overridable">
     <create action="auto" type="middle" />
     <remove action="auto" type="middle" />
   </action-set>
   <!-- configuration for autotools -->
   <action-set name="autotools">
     <create action="auto" type="middle" />
     <linkto action="auto" type="midlle" />
     <remove action="auto" type="middle" />
   </action-set>
   <!-- configuration for secondary-file-generate applications -->
   <action-set name="secondary">
     <create action="ignore" type="strong" />
     <remove action="ignore" type="strong" />
   </action-set>
   <!-- configuration for symlik/link applications -->
   <action-set name="symlink">
     <linkto action="auto" type="weak" />
   </action-set>
   <!-- configuration for archiver/unarchiver, we cannot define the acts -->
   <action-set name="archiver">
     <create action="prompt" type="weak" />
   </action-set>
   <!-- configuraiton for Version Control Systems, we cannot define the acts such as conflicted files -->
   <action-set name="vcs">
     <create action="prompt" type="weak" />
     <remove action="prompt" type="weak" />
   </action-set>
 </action-sets>
 <app-configurations>
   <!-- Finder -->
   <app-configuration action-set="primary">
     <name>Finder</name>
     <exceptions>
       <create action="ignore" type="strong" pattern=".DS_Store" />
       <remove action="ignore" type="strong" pattern=".DS_Store" />
       <create action="ignore" type="strong" pattern="*/.DS_Store" />
       <remove action="ignore" type="strong" pattern="*/.DS_Store" />
     </exceptions>
   </app-configuration>
   <!-- IDEs -->
   <app-configuration action-set="primary">
     <name>Xcode</name>
     <exceptions>
       <!-- Build Directory-->
       <create action="ignore" type="weak" pattern="build" />
       <create action="ignore" type="weak" pattern="*/build" />
       <!-- Not well-known -->
       <create action="ignore" type="weak" pattern="*.swp" />
       <create action="ignore" type="weak" pattern="*~.nib" />
       <!-- User configurations -->
       <create action="ignore" type="weak" pattern="*.pbxuser" />
       <create action="ignore" type="weak" pattern="*.perspective" />
       <create action="ignore" type="weak" pattern="*.perspectivev3" />
       <create action="ignore" type="weak" pattern="*.mode1v3" />
       <create action="ignore" type="weak" pattern="*.mode2v3" />
     </exceptions>
   </app-configuration>
   <app-configuration action-set="primary">
     <name>eclipse</name>
     <exceptions>
       <!-- java -->
       <create action="ignore" type="weak" pattern="bin" />
       <create action="ignore" type="weak" pattern="*/bin" />
       <create action="prompt" type="weak" pattern=".classpath" />
       <!-- C++ -->
       <create action="ignore" type="weak" pattern="Debug" />
       <create action="ignore" type="weak" pattern="*/Debug" />
       <create action="ignore" type="weak" pattern="Release" />
       <create action="ignore" type="weak" pattern="*/Release" />
       <create action="prompt" type="weak" pattern=".cdtbuild" />
       <create action="prompt" type="weak" pattern=".cdtproject" />
       <!-- General Configurations -->
       <create action="prompt" type="weak" pattern=".project" />
       <create action="prompt" type="weak" pattern=".settings" />
       <create action="prompt" type="weak" pattern="*/.settings" />
       <!-- EclipseUML Files can be version-controlled. So, no configurations here -->
     </exceptions>
   </app-configuration>
   <!-- Editors, Shell Commands, Applications -->
   <app-configuration action-set="primary">
     <name>Emacs</name>
     <name>emacs</name>
     <exceptions>
       <create action="ignore" type="weak" pattern="*.elc" />
       <remove action="ignore" type="weak" pattern="*.elc" />
     </exceptions>
   </app-configuration>
   <app-configuration action-set="primary">
     <name>vi</name>
     <name>vim</name>
     <name>view</name>
     <name>ex</name>
     <name>nano</name>
     <name>Preview</name>
     <name>touch</name>
     <name>mkdir</name>
     <name>rmdir</name>
     <name>rm</name>
     <name>Icon Composer</name>
     <name>OmniGraffle Professional</name>
     <name>Numbers</name>
     <name>Microsoft Excel</name>
   </app-configuration>
   <!-- my Shell Script -->
   <app-configuration action-set="primary-overridable">
     <name>template.sh</name>
   </app-configuration>
   <!-- Template Generators -->
   <app-configuration action-set="autotools">
     <name>autom4te</name>
     <name>automake</name>
     <name>autoheader</name>
     <name>autoconf</name>
     <name>autoupdate</name>
     <name>autoreconf</name>
     <name>aclocal</name>
     <exceptions>
       <create action="ignore" type="middle" pattern="autom4te.cache" />
       <create action="ignore" type="middle" pattern="*/autom4te.cache" />
     </exceptions>
   </app-configuration>
   <app-configuration action-set="primary-overridable">
     <name>autoscan</name>
     <exceptions>
       <create action="ignore" type="weak" pattern="*.log" />
     </exceptions>
   </app-configuration>
   <app-configuration action-set="primary">
     <name>javah</name>
     <name>mib2c</name>
   </app-configuration>
   <!-- Compilers -->
   <app-configuration action-set="secondary">
     <name>gcc</name>
     <name>gcc-4.0</name>
     <name>gcc-4.2</name>
     <name>llvm-cpp-4.2</name>
     <name>llvm-g++</name>
     <name>llvm-g++-4.2</name>
     <name>llvm-gcc</name>
     <name>llvm-gcc-4.2</name>
     <name>c++</name>
     <name>c++-4.0</name>
     <name>c++-4.2</name>
     <name>g++</name>
     <name>g++-4.0</name>
     <name>g++-4.2</name>
     <name>c2ph</name>
     <name>cc</name>
     <name>distcc</name>
     <name>cpp</name>
     <name>cpp-4.0</name>
     <name>cpp-4.2</name>
     <name>gcov</name>
     <name>gcov-4.0</name>
     <name>gcov-4.2</name>
     <name>bison</name>
     <name>flex</name>
     <name>flex++</name>
     <name>as</name>
     <name>javac</name>
     <name>clang</name>
     <name>javadoc</name>
     <name>ld</name>
     <name>libtool</name>
     <name>lipo</name>
     <name>mkdep</name>
     <name>nasm</name>
     <name>osacompile</name>
     <name>perlcc</name>
     <name>perlcc5.8.9</name>
     <name>phpize</name>
     <name>pstopdf</name>
     <name>pydoc</name>
     <name>pydoc2.5</name>
     <name>pydoc2.6</name>
     <name>strip</name>
     <name>yacc</name>
     <name>dvipdfmx</name>
     <name>ptex</name>
     <name>tex</name>
     <name>latex</name>
     <name>platex</name>
   </app-configuration>
   <!-- Files Generated by Interpreters cannot be defined the states-->
   <!-- tag jump -->
   <app-configuration action-set="secondary">
     <name>ctags</name>
     <name>etags</name>
     <name>htags</name>
     <name>gtags</name>
   </app-configuration>
   <!-- VCS -->
   <app-configuration action-set="vcs">
     <name>cvs</name>
     <name>rcs</name>
     <name>svn</name>
     <name>svnadmin</name>
   </app-configuration>
   <!-- SCM Tools -->
   <app-configuration action-set="secondary">
     <name>configure</name>
     <name>make</name>
     <name>gnumake</name>
     <name>bsdmake</name>
     <name>org.apache.tools.ant.launch.Launcher</name>
     <name>rake</name>
     <name>xcodebuild</name>
   </app-configuration>
   <!-- link command configuration -->
   <app-configuration action-set="symlink">
     <name>ln</name>
     <name>link</name>
   </app-configuration>
   <!-- archivers -->
   <app-configuration action-set="archiver">
     <name>bsdtar</name>
     <name>gnutar</name>
     <name>gzip</name>
     <name>gunzip</name>
     <name>bzip2</name>
     <name>compress</name>
     <name>uncompress</name>
     <name>zip</name>
     <name>unzip</name>
     <name>jar</name>
     <name>tar</name>
     <name>xar</name>
   </app-configuration>
 </app-configurations>
</aovcs-configurations>

長い...疲れた...

尚，この検証を行っている際に，Mac OS Xにおける濁音，半濁音を含むパスによる問題，というのに遭遇した．数時間修正を試みたが，上手く行かなかったのでとりあえず保留としておく．
問題のキーワード：nfd, nfc, iconv

AOVCSの実用性検証 - autotools

2009-11-23T21:35:00.005+09:00

前回示したツール一覧の，autotoolsの部分の調査．autotools対象のアプリケーションは次．

autoscan
aclocal
autoheader
autoconf
autom4te
automake

これらの自動化を試みる．各コマンドの関係は，Wikipediaに掲載されている図が分かりやすい．その図を引用したのが下．

この図を見ると分かるが，ユーザはconfigureから始めるべき，となっている．そして，それ以前のものは開発者が作るものである．つまり，autotoolsで作成したファイルはバージョン管理されるべき，となる．

そこで，実際にautotoolsを使ってconfigureを作成し，どういったファイルが生成されるかの調査を行う．使い方をキチンと調べ，自分でゼロから作ればそれがベストだが，あまり時間もないのでそうはしない．ググって出てきたautotoolsの利用例に従ってみる事にする．

参照したサイトは次．
http://shimaki-hp.hp.infoseek.co.jp/autoconf/book1.html
http://www.ogis-ri.co.jp/otc/hiroba/technical/CppUnit/chapter3.html

今回は後者のサイトに置いてある，dicegame-0.1を使って検証する．ただしこの記事が書かれたのが2001年であり，それ以降にautotoolsの挙動が変わっていたりする様である．そこは今回は検証しないとする．

dicegame-0.1展開し，なぜか作成されているconfigureを削除し，bootstrap(autotoolsコマンド一連)を実行したのが次．

$ ./bootstrap
+ aclocal -I config
+ autoheader
+ automake --foreign --add-missing --copy
+ autoconf
$ bzr init && bzr af --dry-run
----
No configurations for the following files/directories:
autom4te.cache                 (Application names: autom4te, aclocal, bootstrap, bash, login, Terminal, launchd, launchd)
config                         (Application names: tar, bash, login, Terminal, launchd, launchd)
dicegame                       (Application names: tar, bash, login, Terminal, launchd, launchd)
msvc                           (Application names: tar, bash, login, Terminal, launchd, launchd)
Makefile.am                    (Application names: tar, bash, login, Terminal, launchd, launchd)
Makefile.in                    (Application names: automake, bootstrap, bash, login, Terminal, launchd, launchd)
aclocal.m4                     (Application names: aclocal, bootstrap, bash, login, Terminal, launchd, launchd)
bootstrap                      (Application names: tar, bash, login, Terminal, launchd, launchd)
configure                      (Application names: autom4te, bootstrap, bash, login, Terminal, launchd, launchd)
configure.in                   (Application names: tar, bash, login, Terminal, launchd, launchd)
stamp-h.in                     (Application names: tar, bash, login, Terminal, launchd, launchd)
config.h.in                    (Application names: autoheader, bootstrap, bash, login, Terminal, launchd, launchd)

autom4te.cacheとかいうディレクトリは，オープンソースのリポジトリを見ても管理されていないので，無視していいディレクトリ．あとのファイルはバージョン管理するべきファイル．

また，autoscanコマンドが実行されていないので，そちらは自分で実行して調査する．その結果が次．

$ autoscan
$ bzr af --dry-run
configure.scan                 (Application names: autoscan, bash, login, Terminal, launchd, launchd)
autoscan.log                   (Application names: autoscan, bash, login, Terminal, launchd, launchd)
(※一部略)

configure.scanは，編集してconfigure.ac(またはconfigure.in)として扱うので，configure.scanそれ自体はバージョン管理すべきでないものの，configure.acに名前変更した場合は管理すべき．そのため，configure.scanはバージョン管理対象とする．これは，名前変更トレースを行う関係で良い方法が無かったため．詳細は省くけどちょっと悔しい．
autoscan.logは，バージョン管理不要．オープンソースのリポジトリにやはり無いので．

以上の結果から，次のaovcs.confを作成．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-configurations>
<action-sets>
 <!-- configuration for do-fork and primary-file-generate applications such as shell script -->
 <action-set name="primary-overridable">
   <create action="auto" type="middle" />
   <remove action="auto" type="middle" />
 </action-set>
 <!-- configuration for autotools -->
 <action-set name="autotools">
   <create action="auto" type="middle" />
   <linkto action="auto" type="midlle" />
   <remove action="auto" type="middle" />
 </action-set>
</action-sets>
<app-configurations>
 <!-- Template Generators -->
 <app-configuration action-set="autotools">
   <name>autom4te</name>
   <name>automake</name>
   <name>autoheader</name>
   <name>autoconf</name>
   <name>autoreconf</name>
   <name>aclocal</name>
   <exceptions>
     <create action="ignore" type="middle" pattern="autom4te.cache" />
     <create action="ignore" type="middle" pattern="*/autom4te.cache" />
   </exceptions>
 </app-configuration>
 <app-configuration action-set="primary-overridable">
   <name>autoscan</name>
   <exceptions>
     <create action="ignore" type="weak" pattern="*.log" />
   </exceptions>
 </app-configuration>
</app-configurations>
</aovcs-configurations>

automake --add-missingを実行すると，NEWSとかのシンボリックリンクを張ってくれたりするので，シンボリックリンクにも対応出来る様にaction-setを追加．また，サブプロセスに任せる場合も見られたので，type="middle"に調整．そして上で示したignore対象を追加すればOK．
autoflagsを実行すると次の通り．

$ bzr af --dry-run
The following state will be set if execute autoflags(af) without --dry-run

----
Added files/directories:
Makefile.in                    (automake)
aclocal.m4                     (aclocal)
configure                      (autom4te)
configure.scan                 (autoscan)
config.h.in                    (autoheader: renaming traced)
----
Ignored files/directories:
autoscan.log                   (autoscan - pattern: *.log)
autom4te.cache                 (aclocal - pattern: autom4te.cache)
----
No configurations for the following files/directories:
dicegame                       (Application names: tar, bash, login, Terminal, launchd, launchd)
msvc                           (Application names: tar, bash, login, Terminal, launchd, launchd)
Makefile.am                    (Application names: tar, bash, login, Terminal, launchd, launchd)
bootstrap                      (Application names: tar, bash, login, Terminal, launchd, launchd)
configure.in                   (Application names: tar, bash, login, Terminal, launchd, launchd)
stamp-h.in                     (Application names: tar, bash, login, Terminal, launchd, launchd)

この程度であれば正しく動いている．多分これ以上の規模でも動くはずだが，実証は出来ない．

尚，autotoolsの名前を取得するため，perlのパースが必要だった．とりあえず下ので対応．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-daemonConfigurations>
 <parseConfigurations>
   <parseConfiguration scriptName="perl" shortOptions="sTtuUWXe:">
   </parseConfiguration>
 </parseConfigurations>
</aovcs-daemonConfigurations>

AOVCSの実用性検証 - /usr/bin内，/Developer/usr/bin/内，/opt/local/bin/内編

2009-11-23T18:56:00.002+09:00

もう少しコマンドの検証を続ける．自分が知っているコマンドだけだと結果が偏るので，/usr/bin内のコマンド全部をざっと見て，ファイルを操作しそうなコマンドを絞った．それが次．

ant@
apt@
as*
autoconf*
automake*
automake-1.10*
autoreconf*
autoscan*
autospec*
autoupdate*
batch*
bison*
bsdmake*
bsdtar*
bspatch*
bzip2*
c++@
c++-4.0*
c++-4.2*
c++filt*
c2ph*
c2ph5.10.0*
c2ph5.8.9*
c89*
c99*
cap*
cc@
compress*
cpp*
cpp-4.0*
cpp-4.2*
csplit*
ctags*
cvs*
defaults*
diff*
diff3*
diffpp*
distcc*
erb@
etags*
ex@
find*
flex*
flex++@
ftp*
g++@
g++-4.0*
g++-4.2*
gcc@
gcc-4.0*
gcc-4.2*
gcov@
gcov-4.0*
gcov-4.2*
gdb*
gem@
gm4*
gnumake*
gnutar*
gprof*
gunzip*
gzip*
headerdoc2html*
i686-apple-darwin10-cpp-4.2.1*
i686-apple-darwin10-g++-4.0.1*
i686-apple-darwin10-g++-4.2.1*
i686-apple-darwin10-gcc-4.0.1*
i686-apple-darwin10-gcc-4.2.1*
idlj@
indent*
irb@
jar@
java@
javac@
javadoc@
javah@
javap@
javatool*
ld*
libtool*
lipo*
m4*
make@
merge*
mib2c*
mkdep*
nano*
nasm*
osacompile*
patch*
pear*
pecl*
perl*
perl5.10.0*
perl5.8.9*
perlcc*
perlcc5.8.9*
php*
phpize*
pstopdf*
pydoc*
pydoc2.5@
pydoc2.6@
python*
python-config*
python2.5@
python2.5-config@
python2.6@
python2.6-config@
pythonw*
pythonw2.5@
pythonw2.6@
rake*
rcs*
rsync*
ruby@
scp*
sftp*
sqlite3*
srm*
ssh*
strip*
svn*
svnadmin*
tab2space*
tar@
tclsh@
tclsh8.4@
tclsh8.5@
touch*
uncompress*
unzip*
vi@
view@
vim*
xar*
xcodebuild*
xcodeindex*
yacc*
zip*

うーん，多い．ちょっとげんなりしてきた．/usr/bin内のコマンド，一通りmanを見るだけで1日費やしてしまった．ペースあげないとまずそう．

AOVCSの実用性検証 - /bin/内編

2009-11-20T20:46:00.003+09:00

/bin/内のコマンドについて確認．ユーザが直接操作する場合は自動管理対象となるはずなので，そう扱えば良い．

lsで出たアルファベット順に．ちゃんとmanも確認している．

[ ：testと同じコマンド．ファイルは作成しないのでスルー
bash：シェルが扱ったものを自動管理とすると，リダイレクトなどで実行結果を吐き出させたものも管理されてしまう．なので，自動管理対象とすべきではない．スルー
cat：ファイルを作成しないのでスルー．リダイレクトは，シェルが扱う
chmod：ファイル属性を変更するだけなのでスルー
cp：ファイルコピー．ユーザが直接操作する場合は自動管理すべき．weakで自動管理と指定．シェルスクリプトで使われる場合はシェルスクリプトに依存するが，その場合はシェルスクリプトで挙動を指定すべきな
csh：シェルはスルー
date：日付を色々なフォーマットで出力．/var/log に何か吐き出す様だが，バージョン管理に関係ない場所なのでスルー
dd：全然使わないので分からないけど，ディスクのバックアップに使うコマンドとのことなので，それはバージョン管理する規模ではない．スルー
df：ディスクの空き状況を表示．ファイルを特に作成しないのでスルー
domainname：ドメインネームを表示/指定するとの事だが，使わないしファイル操作もない模様なのでスルー
echo：文字列出力．ファイル操作は無いのでスルー
ed：ファイルエディタらしいので，自動管理とするが，使った事は無い
expr：計算し，その結果を出力する．ファイルは関係ないのでスルー
hostname：ホスト名を表示/指定する．ファイル操作は無いのでスルー
kill：プロセスにシグナルを送信する．ファイル操作は無いのでスルー
ksh：シェルはスルー
launchctl：launchdを操作するコマンド．オプションが多いが，ファイルを生成するような事は無いのでスルー
link/ln：リンクコマンド．場合によって管理すべき場合と管理すべきでない場合がある．例えばシンボリックリンクの場合，別の作業ディレクトリへの簡易アクセスという事がある．これはユーザによって違うので管理すべきでない．逆に，別ディレクトリで作ったファイルのコピーとして扱う場合，バージョン管理した方が良い．よってこれはprompt
ls：ファイル一覧表示．lsがファイルを作成する事は無い(リダイレクトはあるにしても)のでスルー
mkdir：ディレクトリ作成．cpと同じ理論で自動管理すべき
mv：ファイル，ディレクトリ移動，名前変更．移動は何も指定しなくても自動管理するので，スルー
pax：アーカイブ操作コマンド．らしい．使わないので分からない．そもそもアーカイブ系のコマンドは扱いが難しい．これもpromptかな
ps：プロセス情報の表示．ファイルは扱わないので，スルー
pwd：Current Working Directoryを表示．man的には，Pathname of current Working Directoryなのかな？スルー
rcp：リモートファイルコピー．今だとscpを使う事がほとんど．ユーザが手動で行うファイル操作なので，自動管理
rm：ファイル削除．自動管理
rmdir：ディレクトリ削除．自動管理
sh：シェル．スルー
sleep：一定時間スリープ．ファイル操作は無いので，スルー
stty：ターミナルのオプション指定．ファイル操作は無いので，スルー
sync：ディスクキャッシュをディスクに書き出す．スルー
tcsh：シェル．スルー
test：[と同じで，スルー
unlink：rmと同じ．自動管理
wait4path：指定したパスのファイルが出来るまでsleep．ファイルを作成する訳ではないので，スルー
zsh：シェル．スルー

以上．長かった．

AOVCSの実用性検証 - Interface Builder編

2009-11-19T22:43:00.004+09:00

Xcodeを調査しておいて，Interface Builderの方を放置していた．なのでちょっとそれをやる．

Interface Builderは，MacのGUIを作るソフト．*.xibという，クラスのインスタンス(GUIパーツ)とその包含関係とか色々を記述したXMLファイルを扱う．

とりあえず操作をしてみてトレースを取得した．その結果が次．

sqlite> select filename1,processnames from trace where processnames like "%Interface%" group by filename1;
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.000|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.001|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.002|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.003|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.004|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.005|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/.dat3fa6.006|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/DTAssetLibraryAssetDates.plist|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Application Support/Interface Builder 3.0/Library/DTAssetLibraryGroups.plist|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Caches/com.apple.InterfaceBuilder3/Cache.db-journal|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/.GlobalPreferences.plist|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/.GlobalPreferences.plist.1gqgIii|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.0Cuq981|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.0RIoPn1|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.1ZxUuky|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.3negjI7|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.DauctxW|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.EP71K0s|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.F88PFyh|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.GpPreHT|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.JfqbVfj|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.Jwu02nl|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.LJg7La2|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.MHe0wXE|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.azzd0rq|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.bhJ2mWQ|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.i40xfr4|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.jWLiUCG|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.owuUHqA|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.t0K8XnA|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.vrjZvSi|Interface Builder launchd launchd
/Users/hitoshi-s/Library/Preferences/com.apple.InterfaceBuilder3.plist.zwzKzku|Interface Builder launchd launchd
/Users/hitoshi-s/someDir/TestSvn/TestSvn/English.lproj/MainMenu.xib|Interface Builder launchd launchd
/private/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/TemporaryItems/(A Document Being Saved By Interface Builder)|Interface Builder launchd launchd
/private/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/TemporaryItems/(A Document Being Saved By Interface Builder)/MainMenu.xib|Interface Builder launchd launchd

MainMenu.xib以外は操作してない．他のは，InterfaceBuilderそれ自体の設定だったり一次ファイルだったり．Save asを見ると，*.nibという形式も扱えるようなので，そっちも自動管理対象とすべきだな．そのくらい．

AOVCSの実用性検証 - Emacs版

2009-11-19T19:23:00.002+09:00

エディタ編その2．今度はEmacs．

今まで開発にガンガン使ってきたし，実際にautoflagsでファイルを自動管理出来てきているので，次の設定で今のところ問題は無い．

    <app-configuration action-set="primary">
   <name>Emacs</name>
   <name>emacs</name>
   <exceptions>
     <create action="ignore" type="weak" pattern="*.elc" />
     <remove action="ignore" type="weak" pattern="*.elc" />
   </exceptions>
 </app-configuration>

ちなみに自動保存(#*#)/バックアップ(*~)ファイルはBazaarが自動で無視してくれるので設定していない．他のVCSで利用する事を考えると，設定しておくべきか．

ということで，Emacsのトレースを取得してみた．利用している設定/拡張は次の通り．

バックアップファイルを，~/.bak/内に保存
flymake (オンタイムエラーチェック，g++を背後で起動)

これでC++のファイルを新しく作成，保存，終了，改めてファイルを開いて編集，保存，終了としてみた．その結果が次．

sqlite> select filename1, processnames from trace where date>1258625627 and processnames like "%Emacs%" group by filename1;
/Users/hitoshi-s/.bak/!Users!hitoshi-s!someDir!helloEmacs.cpp~|Emacs launchd launchd
/Users/hitoshi-s/.emacs.d/.#anything-c-adaptive-history|Emacs launchd launchd
/Users/hitoshi-s/.emacs.d/auto-save-list/.saves-13354-hi-air.local~|Emacs launchd launchd
/Users/hitoshi-s/.emacs.d/auto-save-list/.saves-15613-hi-air.local~|Emacs bash login Terminal launchd launchd
/Users/hitoshi-s/.emacs.d/auto-save-list/.saves-15829-hi-air.local~|Emacs launchd launchd
/Users/hitoshi-s/.emacs.d/auto-save-list/.saves-15869-hi-air.local~|Emacs launchd launchd
/Users/hitoshi-s/someDir/#helloEmacs.cpp#|Emacs launchd launchd
/Users/hitoshi-s/someDir/.#helloEmacs.cpp|Emacs launchd launchd
/Users/hitoshi-s/someDir/.#helloEmacs_flymake.cpp|Emacs launchd launchd
/Users/hitoshi-s/someDir/helloEmacs.cpp|Emacs launchd launchd
/Users/hitoshi-s/someDir/helloEmacs_flymake.cpp|Emacs launchd launchd
/Users/hitoshi-s/someDir/helloEmacs_flymake.o|as as i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//cc0TAG5u.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//cc12Tenx.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//cc35ypEo.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//cc8Lconx.s|i686-apple-darw g++ Emacs baslogin Terminal launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccCSHFGg.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccLAVPFO.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccMpOrVS.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccPsVnpf.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccRfEUqN.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccUosBDf.s|i686-apple-darw g++ Emacs baslogin Terminal launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccfph8XQ.s|i686-apple-darw g++ Emacs baslogin Terminal launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccmPagRA.s|i686-apple-darw g++ Emacs baslogin Terminal launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccrQfKNq.s|i686-apple-darw g++ Emacs launchd launchd
/var/folders/QQ/QQA+ujrJFO43tJOv83wquE+++TM/-Tmp-//ccwFTcUY.s|i686-apple-darw g++ Emacs launchd launchd

色々あるけど，後半の/var/folders/内のは全てg++の途中ファイルなのでスルー．仮にスルーしなくても，g++が無視設定を行っていれば問題は起こらない．
バックアップファイルである*~は，当然バージョン管理すべきではないので，ignore．#*#の自動保存ファイルも同様にignore．

やや困るのは，*_flymake.cpp．これは，flymakeでg++を実行する為にEmacsが自動で作成するファイル．当然管理すべきではないし，flymakeが終わったら自動で削除されるので大して影響は無いはずのだが，もしflymake中にEmacsが落ちると残り，Emacsが作ったという理由から自動管理されてしまう．
もしignoreとするのであれば，*_flymake.*をignoreに入れる事になる．が，後置型の*は危険なのであまりやりたくない．とりあえずリスクは低いので，スルーにしよう．

他に，.#から始まるファイルが存在する．試しにトレースの詳細を見てみる．

sqlite> select * from trace where filename1="/Users/hitoshi-s/someDir/.#helloEmacs.cpp";
422616|5|/Users/hitoshi-s/someDir/.#helloEmacs.cpp|/Users/hitoshi-s/someDir/hitoshi-s@hi-air.local.15613|Emacs bash login Terminal launchd launchd|1258625746
422640|1|/Users/hitoshi-s/someDir/.#helloEmacs.cpp||Emacs bash login Terminal launchd launchd|1258625766
423292|5|/Users/hitoshi-s/someDir/.#helloEmacs.cpp|/Users/hitoshi-s/hitoshi-s@hi-air.local.15829|Emacs launchd launchd|1258627255
423304|1|/Users/hitoshi-s/someDir/.#helloEmacs.cpp||Emacs launchd launchd|1258627262
423364|5|/Users/hitoshi-s/someDir/.#helloEmacs.cpp|/Users/hitoshi-s/hitoshi-s@hi-air.local.15869|Emacs launchd launchd|1258627428

5という数字は「リンク(シンボリック/ハード)」を指すので，何かのリンク(実際見るとシンボリックリンク)という事が分かる．ただ，リンク先のファイルの実体が存在しない．なんだろこれ？うーん，.#から始まるリンクファイルは，ignoreするというのでいいかな．

とりあえずこんなとこか．

AOVCSの実用性検証 - vi版

2009-11-19T17:55:00.004+09:00

Xcodeは昨日ので大体OKなので今度はviを検証する．
Emacsはよく使うのだが，viはどんな拡張があるのか分からないので，デフォルトの状態で使う．

とりあえずHelloWorldを作って，どんなファイル操作をしてるか見てみた．それが次．

sqlite> select filename1,processnames from trace where processnames like "vi%";
/Users/hitoshi-s/someDir/.hellow.c.swp|vi bash login Terminal launchd launchd
/Users/hitoshi-s/someDir/.hellow.c.swx|vi bash login Terminal launchd launchd
/Users/hitoshi-s/someDir/hellow.c|vi bash login Terminal launchd launchd
/Users/hitoshi-s/.viminfo.tmp|vi bash login Terminal launchd launchd
/Users/hitoshi-s/.viminfo|vi bash login Terminal launchd launchd

.swpファイル，.swxファイルが自動生成ファイルの模様．これらはignore対象．.viminfoは作業ディレクトリ内に出来る訳ではないので特に指定する必要も無いが，操作履歴なのでignore対象．

統合開発環境と比べて，エディタは楽．ただ，SQLiteの内容を見るのがちょっと面倒だと感じ始めた．ビューアを作りたいがどうしようか．

2009/11/19 23:30追記
vimでも同じトレースだった

AOVCSの実用性検証 - Xcode版

2009-11-18T23:21:00.004+09:00

Eclipseの設定は後で記述するとして，今度はXcodeの調査を行う．

といっても以前AOVCSのGUIを作成時に使っているし，こちらは比較的資料が多いので，実際に使うまでもなさそう．以前使った際には，buildディレクトリのみをignoreしていた．では，参考資料を示す．

資料その1：「Xcode 3 UNLEASHED」という本

P.97に，XcodeでSCM (Software Configuration Management)を使う方法として，Subversionが無視すべきファイルの設定がある．ここの記述は以下．


build
*.nib
*.so
*.pbxuser
*.mode*
*.perspective*

buildディレクトリだけでなく，nibファイルとかユーザの設定とかそういうのも無視すべきとの事．nibファイルもなのか．

資料その2：「Git ignore file for Xcode projects」という質問ページ

.DS_Store
*.swp
*~.nib

build/

*.pbxuser
*.perspective
*.perspectivev3

*.mode1v3
*.mode2v3

これらをignore設定すれば良いそう．上の参考資料よりも，こっちの方が良さげ．後置型の*を使ってないし．なので，下をデフォルト設定とすることにしよう．ただ，.DS_Storeを作成するのはFinderのはずなので，それをここで含める必要は無い．

AOVCSの実用性検証 - Eclipse版 (4) - EclipseUML

2009-11-18T18:15:00.005+09:00

AOVCSがEclipseで適用出来るかの調査第4回．これだけにそんな時間はかけられないので，これでEclipseの調査は終わり．あとはConfigurationを書き出して，どこまで上手く管理出来るかを述べる．

まず，EclipseUMLをインストールして，クラス図を作ってみた．その際に作成されたファイルは次．

.umlproject
*.uml
*.ucd

またどれを管理したらいいか難しい．Code synchronizationを使う(むしろデフォルト)と，.javaファイルと.ucdが同期する事になるし．
.javaファイルから.ucdを作る，と考えれば.javaだけ管理すれば良いとなる．しかし，UML内にメモなどを書き出すと，.ucdも管理すべき対象となる．

自分では分からなかったので，ちょっとググった．そーすると，次のページが見つかった．
http://www.forum-omondo.com/documentation_eclipseuml_2008/Team%20work/index.html

EclipseUMLを開発しているomondoのドキュメント．ここによれば，Code Synchronizationを使う場合は次のファイルをバージョン管理すると良いらしい．

java code
graphical diagram (e.g. .ucd, .usd, .uud etc..file)
model file (e.g. .uml file)

こうすると，上手くいくとある．

EclipseUMLの開発元が言うのだから正しいと思ったが，よく考えるとこれが上手く動くのは，最初にUMLを共同作業で作成する，の部分だけではあるまいか？この記事も，UMLを恊働で作る，という状況での指針となっている．そのため，実際にコーディングが始まると，どう考えても面倒なコンフリクトが起こるはず．

ただ逆に考えれば，UMLを作る段階でコーディングをしないとすれば，この管理方法で良いという事にもなる．うーん，なるほど．

だがやはり，AOVCSでどちらの挙動をすべきかは決められない．となるとやはりこれもpromptとしないといけない．ただ，どういう時に管理すべきでどういう時に管理すべきでないかは分かった．この情報を有効利用する為，AOVCSがpromptと表示する際に，どうすべきかの指針を示してあげる事が出来たらいいのではないかと考え中．

また，.javaファイルに影響しないファイルであれば管理出来るだろうと考え，同時に開発するという事をやろうとしたが，EclipseUMLの何かしらのライセンスが必要なようでストップ．学内で使えるところが無いか今度調べよう．

AOVCSの実用性検証 - Eclipse版 (3)

2009-11-17T21:18:00.004+09:00

前回，EclipseのVCSプラグインが自動管理する/しないの調査を行った．今回は，Eclipseを用いて開発しているプロジェクトが，どのファイルをバージョン管理し，どのファイルをバージョン管理しないと指定しているかを調べる．

前回調べたのがC++とJavaである以上，調査対象もC++とJavaの両方としたい．しかし，EclipseでC++を開発しているオープンソースのリポジトリに何があるか分からなかった為，今回はJavaだけとしている．

例として扱うのは，Seasar2のリポジトリ．このリポジトリはsvnで管理されている．svnが何をignoreしているかを見るには.svn内の，dir-prop-baseとかdir-propsを参照すればよい．中に，以下の様に記述されている．

$ cat diigu/org.seasar.diigu.eclipse.plugin/.svn/dir-prop-base
K 10
svn:ignore
V 8

target

END

まず，リポジトリ内のdir-prop-baseとdir-propsの中身を拾ってくる．どっかのリポジトリに入って，次のコマンドを実行すると，catで連結したpropsを取得出来る．

 $ find . -name dir-prop-base -or -name dir-props | xargs -n 1 cat

この出力をファイルに保存して，Emacsで適当に編集してまとめたのが次．いくつものプロジェクトの混合体になっているので，全プロジェクトでこれがignoreされている訳ではない事に注意．

build
target
release.properties
cobertura.ser
.classpath
.project
work
bin
classes
dist
result.txt
classlist.txt
objdbc5.jar
xadatasource_oracle.dicon
xadatasource_db2.dicon
.settings
ddl
sql
db2.dicon
temp
sqljdbc.jar
main
example

うーん．色々ignoreしている．.classpathとか.settingsとか.projectもignore対象になってたりもする．これは，.classpathと.settingsと.projectは，ユーザに入力を求めるしか無いな．

また逆に，binディレクトリがバージョン管理されているという場合もあった．ベンチマークとかチュートリアルとか．これについては，レアなケースかつbinは通常.classファイルを置く場所なので，大半の人には自動管理しないのが妥当と判断し，binは無視するとすべき．

どれがどうしてignoreされているのか，その理由も調べたいが，その余力はちょっとなさそう．

AOVCSの実用性検証 - Eclipse版 (2)

2009-11-17T17:52:00.003+09:00

前回，Eclipse上でプロジェクトを作成してみて，どんなファイルが何によって作られているかを見た．

今度は，どのファイルをバージョン管理すべきかを考える．アプローチは次の2つ．

EclipseのVCSプラグインを入れて，何が管理されるかを観察する
Eclipseを用いて開発しているプロジェクトを見つけて，何が管理されているか確認する

まずは前者を行う．対象は，C++とJava．

まずC++．Standard Make C++ Projectは，管理すべきでないファイルを生成するのはmakeであり，makeはEclipseのサブプロセスとして実行される．よって，makeの生成物を管理しない，という設定をしてさえいればOK．
問題は，Managed Make C++ Projectである．とりあえずhelloworldを作ってみて，バージョン管理をしてみた．使ったVCSは，SubversionとBazaar．管理対象ファイルは下の図の通り．.bzrディレクトリは無視してください．

で，これをバージョン管理する．まずはBazaarがデフォルトで追加しようとしたもの．

全部．拡張意味ないです．結局自分で選択しないといけません．

次．Subversion．

どうやって情報を取得しているかは知らないけど，Debugディレクトリは無視されている．.projectとか，.から始まるファイルは候補として表示されている為，管理してもいい様だ．

Debugディレクトリはどうやって無視すると決めているのか気になったので，適当にリネームしてみた．しかしそれでもDebugは自動的に無視される．逆に，ソースディレクトリをDebugとかにリネームしても，きちんと管理候補として表示する．

どうやってるかは分からないけど，Subversionの方はファイルパターンではなく，何かしらのファイル，ディレクトリの属性情報を用いているようだ．パターンでは駄目か？

さて次はJava．こっちはSubversionでもBazaarでも，両方大体おんなじ挙動をした．

binは管理対象としない
それ以外は管理対象とする
binをリネームすると，管理対象にしたりしなかったりする (case by case)

まだEclipseのVCSプラグインがどこまでお膳立てしてくれるのかよくわかってないが，案外大した事はしてくれない様である．例えば，ファイル名を変更する場合，EclipseのRefactor -> Renameを用いる．だが，それを用いたからと言って，svn mvやbzr mvを実行したとは扱ってくれない．deleteとaddとして扱う．

案外Control Integrationとか行ってないんだなーとかニヤニヤしながら，binをリネームする事は無いと信じよう．

AOVCSの実用性検証 - Eclipse版

2009-11-16T21:23:00.004+09:00

AOVCSという手法がどこまで通用するかを検証する．まずは，Eclipse．

自分はEclipseを全然使わない人間なのだが，EclipseでAOVCSが上手く動くとすれば，それはすばらしい．なぜかと言えば，専用のプラグインを使わなくても自動でバージョン管理が出来るからである．
まーでもEclipseで使う場合は，一発で自動管理する，ってボタンが欲しいとこだろうし，どのファイルが管理されているかの視覚情報も必要だろうから，プラグインが不要，とはいかない．

で，その自動管理が上手く動くかどうかを調査する為，Eclipseをインストール & 適当にファイルの作成を行った．そのトレース結果．

java開発 (sqliteからクエリで取得)：


/Users/hitoshi-s/Documents/workspace/TestBazaar||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/.classpath||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/.project||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/.settings||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/.settings/org.eclipse.jdt.core.prefs||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/bin||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/bin/root||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/bin/root/Controller.class||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/src|eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/src/root||eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestBazaar/src/root/Controller.java||eclipse launchd launchd

全てがeclipseによって作られたという悲しい結果．コンパイルくらいコンパイラをサブプロセスとして立ち上げればいいのに．まぁそもそもファイル名のパターンによる例外処理を導入したのも，この理由なんだけど．
とりあえずこんな小さい規模で，他のファイルも全然ないような状況であれば，bin内を無視とすれば良さげ．.settings内とか.classpathとか.projectをバージョン管理すべきかどうかはよくわからない．

次．C++開発．CDTをインストールして，Standard Make C++ Projectと，Managed Make C++ Projectの両方のトレースを取得した．まずはStandard Make C++ Project．自分でmakefileを作ってあげる必要がある．

Standard Make C++ Project：

/Users/hitoshi-s/Documents/workspace/TestC++/.project||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++/.cdtproject||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++/src||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++/src/controller.cpp||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++/makefile||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++/a.out||ld collect2 i686-apple-darw g++-4.2 make eclipse eclipse launchd launchd

こちらはサブプロセスとしてmakeを起動してコンパイルしている．よって，AOVCSでmakeを設定してさえいれば自動管理が出来る．他のファイルの管理云々は，javaの場合と大体共通かな？

次．Managed Make C++ Project．こちらは，Eclipseが自動でmakefileを作ってくれるというもの．どうやって？って部分は気になるが気にしないとしておく．

Managed Make C++ Project:

/Users/hitoshi-s/Documents/workspace/TestC++Version2/.project||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/.cdtproject||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/.cdtbuild||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/src||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/src/Controller.cpp||eclipseeclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/sources.mk||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/src||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/src/subdir.mk||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/makefile||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/objects.mk||eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/src/Controller.o||as as i686-apple-darw g++ sh make eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/src/Controller.d||sh make eclipse eclipse launchd launchd
/Users/hitoshi-s/Documents/workspace/TestC++Version2/Debug/TestC++Version2||ld collect2 i686-apple-darw g++-4.2 make eclipse eclipse launchd launchd

こちらは，Controllerやバイナリ(TestC++Version2)はmakeサブプロセスによって作られている事が分かる．しかし，Debug内のEclipseによって自動生成されたファイル群は，Eclipseが作ったとしか分からない．そもそもDebugをバージョン管理しない，と決めない限り，これを上手く動かすのは難しそうである．

AOVCS benchmark (2)

2009-11-11T16:48:00.004+09:00

とりあえず全部の測定結果を出したので，それを．

やはり，forkだけが際立って消費時間の増加率が高い．

次のグラフが，増加率をグラフで比較したもの．fork()は目盛りを振り切るけど無視．

大体1.5倍から4倍の範囲となっている．ただしforkを除く．

この結果から安直に，システムコールに1.5倍から4倍の時間が費やされる，と考えるのは間違っている．なぜなら，利用頻度が低いシステムコールが4倍になったところで，ユーザにとって大した問題とはならないからである．同様に，もともとわずかしかCPU時間を費やさないシステムコールの消費時間が4倍になっても，問題は無い．

そこで今度は，システムコールの頻度と，それぞれの消費時間を測定する．
まず，システムコールの頻度は，dtraceを用いて非常に簡単に測定出来る．

 $ sudo dtrace -n 'syscall:::entry{@counts[probefunc]=count();}'

これを実行して，適当なタイミングでCtrl-cで終了させると，次のような結果を取得出来る．この結果は，dtraceを20秒起動した場合の結果．

  audit                                                             1
audit_session_join                                                1
chflags                                                           1
connect_nocancel                                                  1
ftruncate                                                         1
getaudit_addr                                                     1
getlogin                                                          1
getpgid                                                           1
listen                                                            1
listxattr                                                         1
setaudit_addr                                                     1
sync                                                              1
audit_session_self                                                2
auditon                                                           2
csops                                                             2
fgetxattr                                                         2
fstat                                                             2
fsync_nocancel                                                    2
getpeername                                                       2
getsockname                                                       2
rename                                                            2
vfork                                                             2
bind                                                              3
chmod                                                             3
chown                                                             3
getpgrp                                                           3
getsockopt                                                        3
chdir                                                             4
gethostuuid                                                       4
setgid                                                            4
setlogin                                                          4
symlink                                                           4
umask                                                             4
fchdir                                                            5
flock                                                             5
fsctl                                                             5
getpriority                                                       5
recvmsg_nocancel                                                  5
wait4_nocancel                                                    5
flistxattr                                                        6
kill                                                              6
setsid                                                            6
setuid                                                            6
getdtablesize                                                     7
posix_spawn                                                       7
readlink                                                          8
getppid                                                           9
msync                                                             9
poll_nocancel                                                     9
workq_open                                                        9
getgroups                                                        10
kqueue                                                           10
recvmsg                                                          10
socketpair                                                       10
statfs64                                                         10
dup                                                              11
connect                                                          12
identitysvc                                                      12
mkdir                                                            13
sendmsg_nocancel                                                 13
fchmod                                                           14
fchown                                                           14
sendto_nocancel                                                  14
fsync                                                            17
execve                                                           18
adjtime                                                          20
fsgetpath                                                        21
initgroups                                                       21
sigsuspend                                                       21
unlink                                                           22
setsockopt                                                       23
shared_region_check_np                                           25
pipe                                                             27
ptrace                                                           28
bsdthread_create                                                 29
setegid                                                          29
shm_open                                                         30
socket                                                           31
__pthread_canceled                                               32
bsdthread_register                                               34
getrlimit                                                        34
settid                                                           34
exit                                                             36
lstat                                                            36
fork                                                             37
getgid                                                           42
setpgid                                                          42
seteuid                                                          43
__pthread_fchdir                                                 58
__pthread_sigmask                                                58
getfsstat64                                                      60
__disable_threadsignal                                           62
bsdthread_terminate                                              62
getegid                                                          62
wait4                                                            65
issetugid                                                        66
setpriority                                                      66
iopolicysys                                                      70
getpid                                                           89
recvfrom                                                         95
sendto                                                           96
getdirentriesattr                                               108
writev_nocancel                                                 112
recvfrom_nocancel                                               115
sendmsg                                                         120
accept                                                          131
stat                                                            135
pwrite                                                          136
__semwait_signal                                                147
__mac_syscall                                                   157
setitimer                                                       159
thread_selfid                                                   164
select_nocancel                                                 184
access                                                          224
write                                                           280
sigreturn                                                       307
munmap                                                          379
madvise                                                         464
select                                                          471
pread                                                           481
kdebug_trace                                                    540
mmap                                                            557
write_nocancel                                                  648
lstat64                                                         699
gettimeofday                                                    767
getattrlist                                                     772
ioctl                                                           791
fcntl_nocancel                                                  836
getrusage                                                       838
fstatfs64                                                       843
sigaction                                                       906
close_nocancel                                                 1078
open_nocancel                                                  1082
proc_info                                                      1135
access_extended                                                1161
fstat64                                                        1218
getuid                                                         1237
dup2                                                           1272
open                                                           1432
getdirentries64                                                1672
workq_kernreturn                                               2680
fcntl                                                          3234
lseek                                                          4005
read_nocancel                                                  4605
__sysctl                                                       5005
read                                                           5641
stat64                                                         6775
geteuid                                                        6910
sigaltstack                                                    7252
sigprocmask                                                    8740
close                                                         12722
kevent                                                        20917

分析はのちのち行う．

これに対し，システムコールの実行時間を測定するのは難しい．dtraceのリファレンスに，システムコールのaggregationの例がある．

syscall:::entry
{
self->ts=timestamp;
}
syscall:::return
{
@time[probefunc]=avg(timestamp - self->ts);
self->ts=0;
}

しかしこれだと，適切な値を取得出来ない場合が起こってくる．以下がその例である．

システムコール実行中に，プリエンプションが起こった: entry時とexit時のタイムスタンプで判断しているので，プリエンプションは分からない

ディスクI/O等による消費時間が含まれるのも若干の問題である (最初に示した測定は，RAMDISK上で行ったのでI/Oの占める割合が低い)が，それ以上に上記の場合だと正確性に欠けてしまう．

システムコールの平均消費時間を正確に測定するのは難しそうなので，今回はシステムコールの頻度のみで考える事にしよう．

AOVCS benchmark

2009-11-07T20:48:00.005+09:00

AOVCSの評価として，AOVCSデーモンによるオーバーヘッドを測定する．

測定は，トレース対象となるシステムコールをそれぞれ10000回実行し，デーモンの有効無効でどれだけ時間に差が出るか，で行う．対象とするシステムコールは次の画像の通り．

まだ表を埋めきっていないが，対象となるシステムコールは分かる．で，現在コードを書いて計測中．とりあえずvforkまで測定．その結果が次．

デーモンが有効だと，大体2倍 - 4倍程度の時間がかかる事が分かる．システムコールの頻度を考えれば，それほど酷い値ではない．例外はfork．無茶苦茶遅い．20倍近くかかっている．なんで？

試しに，何もトレースを行わないdtraceを起動してみる．

$ sudo dtrace -Z

この状態でforkのベンチマークを行うと，それでも7000[msec]くらいかかった．つまり，今回書いたd-scriptが悪いのではなく，dtraceのそもそもの仕様の様だ．こればかりはどうしようもない．今度，10.5でも同様の実験をしてみよう．

英数 / かなキーの問題

2009-11-04T15:12:00.002+09:00

CarbonEmacsが，どうも最近フリーズする機会が多い．先日も論文を書いている際にフリーズしてくれて，2行程文章が失われた．

しかしその際，どうやらCtrl - 英数を押しているという事に気づいた．試しに押してみると，CarbonEmacsが簡単にフリーズする．ぬ？これはバグではないか？

Emacs フリーズ英数とかでググると，2chに同じ問題の情報がある．Cocoa Emacsでは問題ないとかどうとか．
http://pc11.2ch.net/test/read.cgi/mac/1228489176/l50

でも，Snow Leopardにしてからの問題みたいだから，CarbonEmacsは悪くない気がする．Snow Leopardが悪い．そう考えて調査をすると，CarbonEmacsじゃなくても起こる事が分かった．多分発動条件は次の通り．

Mac OS X 10.6以降
Cocoaのtextfield以外(文字が入力出来ない場所)にフォーカスを当てる
英数キーを押すと「ことえり」の英字入力になるか，かなキーを押すと「ことえり」のかな入力になるかの状態にする
Ctrl-英数またはCtrl-かなを押す

そうすると，CarbonEmacsならば完全フリーズ，他のCocoaアプリケーションだとウィンドウとかは動くけどボタンとかは機能しない状態になる．そして，アクティビティモニタを見るとCPU消費が50%とかになる．
Cocoaアプリケーションだと，Dockを右クリックするとかSpotlightを開くと回復するときもある．

他のSnow Leopardユーザもなったというし，これは完全にバグ．Appleにバグレポートだしといた．ただ，バグレポートは英語で書いてくださいってのは酷い．何故そこで報告させない方に向かわせようとする？翻訳ぐらいそっちでやって欲しい．

とりあえず次の通りに報告しときました．

-----
Ctrl-EISUU / Ctrl-KANA (only in JIS keyboard) makes applications hang

Summary:
Simply push ctrl-EISUU or ctrl-KANA in some applications, and the application hangs.
I could cause the problem in the following applications:
Mail, iCal, Activity Monitor, Adium, CarbonEmacs

Steps to reproduce:
Setup input method to use Kotoeri when you push EISUU/KANA key.
Then focus one of the above applications, whose active target shouldn't be Cocoa's text-field.
Then push ctrl-EISUU or ctrl-KANA and the application will hang.

The application won't accept any input.
It MAY recover when ctrl-click Dock or open spotlight.

Expected result:
Not hang.
Simply treat it as EISUU or so.

Actual result:
Hang.

Regression:
I confirm the problem in MacBook Air and MacBook KURO with Mac OS X 10.6.1.
In 10.4.11, this problem doesn't occur.

Notes:
Attached file is a screen shot of hanged iCal.
(Sorry, using language is Japanese)
This figure shows that Kotoeri and iCal consumes a lot of CPU resources.

AOVCS-bazaarの修正 (3)

2009-11-03T17:44:00.004+09:00

type="middle"の実装．目的は，Emacsのe-shellで作成したファイルが何でもかんでもバージョン管理されてしまうのを防ぐ事．

実装した事．
Before: (bazaar-ext/autoflags/aovcs.py)

        for appName in appNames:
       if self.data.has_key(appName) and self.data[appName][0][event][0]!="undef":
           result=(self.data[appName][0][event][0],appName)
           type=self.data[appName][0][event][1]
           for exception in self.data[appName][1][event]:
               if fnmatch.fnmatch(filename, exception[0]):
                   result=(exception[1], appName+" - pattern: "+exception[0])
                   type=exception[2]
           if type=="strong": return result
   return result

After：

        for i in xrange(len(appNames)):
       appName=appNames[i]
       if self.data.has_key(appName) and self.data[appName][0][event][0]!="undef" and (i==0 or self.data[appName][0][event][1] in ("middle", "strong")):
           result=(self.data[appName][0][event][0],appName)
           type=self.data[appName][0][event][1]
           for exception in self.data[appName][1][event]:
               if fnmatch.fnmatch(filename, exception[0]):
                   result=(exception[1], appName+" - pattern: "+exception[0])
                   type=exception[2]
           if type=="strong": return result
   return result

変更点は，

イテレーションを配列に対して行うのではなく，添字で行うようにする
添字が0でなければ，weakは処理対象としない

これだけ．もうちょっとメンドクサイことになるかと思ったが，意外とここだけですんだ．実装が良かったのかな，とちょっとだけ喜ぶ．

実際にEmacs上のシェルで実行すると次の通り．

$ ls > foobar
$ bzr af --dry-run
The following state will be set if execute autoflags(af) without --dry-run

----
No configurations for the following files/directories:
testCase/foobar                (Application names: bash, bash, Emacs, bash, login, Terminal, launchd, launchd)

確かに，Emacsがプロセス一覧に含まれていても勝手に管理する，という事は無くなった．目標達成．今までの挙動が必要(例えばシェルスクリプトとか)な場合は，type="middle"を使えば良い．

さて，多分Webページの修正の方が多いな．

AOVCSの修正案

2009-11-02T19:29:00.003+09:00

現在AOVCSの評価を実行中．いずれまとまったらここに載せる予定．

で，それとは別に，前々からAOVCSに対して修正した方がいいと思っていた点がある．評価をキチンとやるに辺り，やはり直しておくべきと思うようになった．その点のまとめ．

直したい点は，設定の強さにmiddleを用意するというもの．middleの意味と，それに伴う変更は次．

type="weak"は，そのプロセスが直接ファイルを操作した場合のみ，意味をなす．例えば，Emacsが直接ファイルを操作した場合は意味を為すが，Emacsがe-shellのサブプロセスを立ち上げて，その中で処理をした場合は意味を為さない
type="middle"は従来のweakと同じ意味を為す．これは，サブプロセスに処理を投げるアプリケーションの場合に設定すべきとなる．例えばシェルスクリプトはmiddleにすべきである
type="strong"は，従来と意味が変わらない．親プロセスが何かによらず，そこで挙動を決定する．ignoreが確定するコンパイラなどの場合に用いる

これを導入する目的は，weakで例に挙げたサブプロセスでシェルを立ち上げる場合に上手く対応する為である．これが無いと次の問題が起こる．

Emacsを，create="auto" type="weak"とする
Emacsのe-shellを立ち上げる
適当な，AOVCSで未設定のシェルスクリプトを実行して，ファイル(file.txtとする)を作る
autoflags実行
file.txtはEmacsが作成した事となり，自動管理される

これは非常に不適切な挙動である．file.txtはよくわからないスクリプトが作成しているのでユーザに設定を催すのが適切である．この挙動を修正する為に，weakの強さを弱くする必要がある．

出来るだけ設定できるパラメータの種類は少ない方が良いのだが，今回は必要と判断し，導入することとした．

Snow Leopard用のTex環境

2009-10-30T23:02:00.010+09:00

Snow Leopardで日本語Texを使う方法のメモ．

Texのインストール

Texのインストールはportを使って行う．以前の記事でも書いたが，次の通りのportコマンドを打てば良い．

$ sudo port install ptex +utf8 +no_x11

Macだと大体UTF-8の文字コードなので，+utf8は付けておくと安心．あと，+no_x11を付けておくとX関係のライブラリが省略されてコンパイルが大幅に速くなる．これを付けて問題になるような事は今のところ無い．

texのプレビュー

プレビューの方法は2種類ある．1つは，dviで閲覧する事，もう1つはpdfで閲覧する事である．
自分はLeopardまではMxdviを用いてdviで閲覧していた．しかし，Snow LeopardになるとMxdviはデフォルトでは動かない．Rosettaをインストールする必要がある．Rosettaのインストール自体は簡単に行える．

しかし，わざわざAppleがRosettaをデフォルトでインストールしないようにしてきたという事は，いずれRosettaのサポートを切るぞという事なはず．そのためRosettaは用いない事にした．

もしRosettaでいーやという場合はMxdviを入れればOKとなる．しかし，Mxdviのオフィシャルページが少なくとも2ヶ月間は404となっているため，今からMxdviでやろうというのも無理となっている．そのため，次に示すpdfによる方法を推奨する．

pdfによる方法では，dvipdfmxを用いてdviをpdfに変換し，プレビュー.appで確認する，という形式が良い．WindowsだとおなじみのAdobe Readerは，後述する理由(コンパイルの簡略化にて述べる)によりプレビューに劣る．

この方法では，貼付ける画像をepsではなくpdfで用意するとよい．そうすると，dviからpdfへの変換が高速になるからである．pdfの貼付け方法は次．

mediabb.styをダウンロード (http://www.ma.ns.musashi-tech.ac.jp/Pages/TeX/mediabb.sty.html)
適当な場所にmediabb.styを置き，texファイル内に\usepackage[dvipdfm]{graphicx}と\usepackage{mediabb}を記述
\includegraphics{hoge.pdf}

これだけ．epsだと滅茶苦茶時間がかかっていたのが，かなり高速に変換出来るようになる．@wtakuoの話によれば，用意したpdfファイルに相性があるらしいが，Omni Graffleで作成した画像は今のところ問題ないそうである．

コンパイルの簡略化

あとはtexを用意してコンパイルするだけだが，毎回platexとかdvipdfmxと書くのは面倒である．簡略化はもちろんmakeで．@wtakuoによればomakeを使うとすばらしく快適になるとの事だけど，残念ながらport install omakeに失敗するので，Makefileでなんとかする．

TEX=platex
PDF_CONVERT=dvipdfmx
PDF_VIEW=open -a Preview
TARGET=paper.pdf

all: ${TARGET}

%.pdf: %.dvi
${PDF_CONVERT} $^

paper.dvi: paper.tex content/*.tex
 ${TEX} $^ && ${TEX} $^

%.dvi: %.tex
 ${TEX} $^ && ${TEX} $^


view: ${TARGET}
${PDF_VIEW} $^


clean:
rm -f *.log *.toc *.aux *.dvi

(※タブが削除されてしまっているため，利用する場合は補完をお願いします)

Texは経験によれば，2パスすれば大体ページ番号関係は解決する．そのため，dvi生成部分で2度platexを起動するようにする．本当に正確なものを生成するには，3パスが必要だったはず．でも自信が無いので自己責任で．この依存関係を正確に解決出来るのが，omakeとのこと．

paper.dviのルールは，texファイルを複数に分割している場合に便利．上記の例では，contentディレクトリ内のtexファイル全てに依存がある，としてある．特に分割がなければ，paper.dviのルールは削除して問題ない．

Makefileの使い方としては，プレビューが開いてないときはmake viewを実行，既に開いているときはmakeを実行するのが良い．プレビューは賢く，変更があったら変更後の表示に切り替えてくれる．Adobe Readerは，一応は変更後のやつに切り替えてくれるんだけど，レンダリングが怪しかったりするので微妙．

また，既にプレビューで開いているときにmake viewをやってしまうと，表示しているページが先頭に戻ってしまうので注意．レイアウトを確認しながらtexファイルを修正し，コンパイル，再確認をやる事が多いと思うので，確認していたページを見失わないためにもすでに開いているときはmakeで済ますのが良い．

MacPortsのメモ binutils

2009-10-29T21:54:00.002+09:00

Snow Leopard移行直後にインストールしようとした際は失敗した，binutils．2ヶ月ぶりにコンパイルしてみた．

 $ sudo port install binutils +universal
--->  Computing dependencies for zlib
--->  Fetching zlib
--->  Verifying checksum(s) for zlib
--->  Extracting zlib
--->  Applying patches to zlib
--->  Configuring zlib
--->  Building zlib
--->  Staging zlib into destroot
--->  Deactivating zlib @1.2.3_2+universal
--->  Computing dependencies for zlib
--->  Installing zlib @1.2.3_3+universal
--->  Activating zlib @1.2.3_3+universal
--->  Cleaning zlib
--->  Computing dependencies for binutils
--->  Fetching binutils
--->  Attempting to fetch binutils-2.20.tar.bz2 from ftp://ftp.dti.ad.jp/pub/GNU/binutils
--->  Verifying checksum(s) for binutils
--->  Extracting binutils
--->  Configuring binutils
--->  Configuring binutils for architecture x86_64
--->  Configuring binutils for architecture i386
--->  Building binutils
--->  Building binutils for architecture x86_64
--->  Building binutils for architecture i386
--->  Staging binutils into destroot
--->  Staging binutils into destroot for architecture x86_64
--->  Staging binutils into destroot for architecture i386
Note: binutils installs files outside the common directory structure.
--->  Installing binutils @2.20_0+universal
--->  Activating binutils @2.20_0+universal
--->  Cleaning binutils

この通り，キチンとコンパイル出来た．実行するとこんな．

$ gobjdump -t /bin/ls
In archive /bin/ls:
unable to read unknown load command 0x22

/bin/ls:i386:x86-64:     file format mach-o-le

SYMBOL TABLE:
0000000005614542      d  3c OPT    00 0000 radr://5614542
0000000100000000 g       03 ABS    00 0010 __mh_execute_header
0000000000000000 g       01 UND    00 0200 __DefaultRuneLocale
0000000000000000 g       01 UND    00 0201 ___assert_rtn
0000000000000000 g       01 UND    00 0201 ___error
0000000000000000 g       01 UND    00 0201 ___maskrune
0000000000000000 g       01 UND    00 0201 ___stack_chk_fail
0000000000000000 g       01 UND    00 0200 ___stack_chk_guard
0000000000000000 g       01 UND    00 0200 ___stderrp
0000000000000000 g       01 UND    00 0200 ___stdoutp
0000000000000000 g       01 UND    00 0201 ___tolower
0000000000000000 g       01 UND    00 0201 _acl_free
0000000000000000 g       01 UND    00 0201 _acl_get_entry
0000000000000000 g       01 UND    00 0201 _acl_get_flag_np
0000000000000000 g       01 UND    00 0201 _acl_get_flagset_np
0000000000000000 g       01 UND    00 0201 _acl_get_link_np
0000000000000000 g       01 UND    00 0201 _acl_get_perm_np
0000000000000000 g       01 UND    00 0201 _acl_get_permset
0000000000000000 g       01 UND    00 0201 _acl_get_qualifier
0000000000000000 g       01 UND    00 0201 _acl_get_tag_type
0000000000000000 g       01 UND    00 0201 _atoi
0000000000000000 g       01 UND    00 0201 _compat_mode
0000000000000000 g       01 UND    00 0201 _err
0000000000000000 g       01 UND    00 0201 _exit
0000000000000000 g       01 UND    00 0201 _fflagstostr
0000000000000000 g       01 UND    00 0201 _fprintf
0000000000000000 g       01 UND    00 0201 _fputs
0000000000000000 g       01 UND    00 0201 _free
0000000000000000 g       01 UND    00 0201 _fts_children$INODE64
0000000000000000 g       01 UND    00 0201 _fts_close$INODE64
0000000000000000 g       01 UND    00 0201 _fts_open$INODE64
0000000000000000 g       01 UND    00 0201 _fts_read$INODE64
0000000000000000 g       01 UND    00 0201 _fts_set$INODE64
0000000000000000 g       01 UND    00 0201 _fwrite
0000000000000000 g       01 UND    00 0201 _getbsize
0000000000000000 g       01 UND    00 0201 _getenv
0000000000000000 g       01 UND    00 0201 _getgrgid
0000000000000000 g       01 UND    00 0201 _getopt
0000000000000000 g       01 UND    00 0201 _getpid
0000000000000000 g       01 UND    00 0201 _getpwuid
0000000000000000 g       01 UND    00 0201 _getuid
0000000000000000 g       01 UND    00 0201 _getxattr
0000000000000000 g       01 UND    00 0201 _group_from_gid
0000000000000000 g       01 UND    00 0201 _ioctl
0000000000000000 g       01 UND    00 0201 _isatty
0000000000000000 g       01 UND    00 0201 _kill
0000000000000000 g       01 UND    00 0201 _listxattr
0000000000000000 g       01 UND    00 0201 _localeconv
0000000000000000 g       01 UND    00 0201 _localtime
0000000000000000 g       01 UND    00 0201 _malloc
0000000000000000 g       01 UND    00 0201 _mbr_uuid_to_id
0000000000000000 g       01 UND    00 0201 _mbr_uuid_to_string
0000000000000000 g       01 UND    00 0201 _mbrtowc
0000000000000000 g       01 UND    00 0201 _memset
0000000000000000 g       01 UND    00 0201 _nl_langinfo
0000000000000000 g       01 UND    00 0200 _optind
0000000000000000 g       01 UND    00 0201 _printf
0000000000000000 g       01 UND    00 0201 _putchar
0000000000000000 g       01 UND    00 0201 _readlink
0000000000000000 g       01 UND    00 0201 _realloc
0000000000000000 g       01 UND    00 0201 _setenv
0000000000000000 g       01 UND    00 0201 _setlocale
0000000000000000 g       01 UND    00 0201 _signal
0000000000000000 g       01 UND    00 0201 _snprintf
0000000000000000 g       01 UND    00 0201 _sscanf
0000000000000000 g       01 UND    00 0201 _strchr
0000000000000000 g       01 UND    00 0201 _strcoll
0000000000000000 g       01 UND    00 0201 _strcpy
0000000000000000 g       01 UND    00 0201 _strdup
0000000000000000 g       01 UND    00 0201 _strerror
0000000000000000 g       01 UND    00 0201 _strftime
0000000000000000 g       01 UND    00 0201 _strlen
0000000000000000 g       01 UND    00 0201 _strmode
0000000000000000 g       01 UND    00 0101 _tgetent
0000000000000000 g       01 UND    00 0101 _tgetstr
0000000000000000 g       01 UND    00 0101 _tgoto
0000000000000000 g       01 UND    00 0201 _time
0000000000000000 g       01 UND    00 0101 _tputs
0000000000000000 g       01 UND    00 0201 _user_from_uid
0000000000000000 g       01 UND    00 0201 _warn
0000000000000000 g       01 UND    00 0201 _warnx
0000000000000000 g       01 UND    00 0201 _wcwidth
0000000000000000 g       01 UND    00 0201 _write
0000000000000000 g       01 UND    00 0200 dyld_stub_binder

otoolだとシンボルテーブルの参照がどうも出来ないので，gobjdumpが役に立つ．ディスアセンブルはotoolで事足りる(otool -tv /bin/ls)のだけれども．

fslogger

2009-10-27T14:39:00.003+09:00

Webページは大体出来たが，公開サーバが決まらないので保留．論文の方を始めた．

で，そこは置いておいて，2chを見ているとこんなソフトウェアを発見．

fslogger
http://osxbook.com/software/fslogger/

Mac OS X Internals関連の記事で，その本の中にも同じ情報がある．11.8.2節のThe Fsevents Mechanismって所．

やっているのは，Spotlightがファイルシステム情報取得に使っている仕組みを用いて，ファイルシステムへの変更情報を取得する，ということ．変更情報とはファイル作成，削除，移動など．

おや？AOVCSのデーモンがdtraceを使ってやっていることと同じじゃないか？しかもシステムコールをフックしてやっているAOVCSに比べて，元々用意された仕組みを用いるので多分速い．情報のフィルタリングもd-scriptでなくCとかで記述出来るし．むぅ．

一応dtraceを用いた場合のメリットもある．プロセスがすぐに終了するような場合に，プロセス名や引数リストを取得し損ねることを防げる点である．dtraceはfork/exec時にフックして処理するのに対し，fsloggerはカーネルが情報を送ってきた時点で処理する．この時点でプロセスが存在していないとアプリケーション情報が取得出来ない訳である．

とすると，デーモン実装については，dtrace+fsloggerの仕組みのハイブリッドがベストになるかな？

今回の研究においては，「評価用」であること，「他への移植も念頭に入れてる」ことを理由として，全部dtraceで実装したと言い訳しよう．

AOVCSのwebページ作成中 (8)

2009-10-17T21:27:00.004+09:00

やっとこさ，一通りアップロード出来るようになった．まだAutoflags Commad用しか出来てないけど，仕組み自体は同じだからデザインを考えるだけで出来るはず！

アップロードした設定の参照．

こんな．情報の配置はこういう形にした．あとは，

App., Eval., Dateでソート出来るようにする
Eval. (その設定の評価)を加点出来るようにする
XMLにマウスをかざすと，XMLを表示するようにする (以前作ったやつ)
Delを押すと，削除を出来るようにする

この辺りをやる必要がある．細かいのがちょっと面倒だな〜．

ファイル選択&アップロード部分

こういう形．ファイルを選択する方法だけじゃなくって，コピペでもアップロード出来るようにする予定．

アプリケーション選択部分

ここは大体OK．XMLを同じようにホバーで表示するようにする予定だけど，正直不要な気もする．

AOVCSのwebページ作成中 (7)

2009-10-14T21:18:00.002+09:00

現在，設定をアップロードする部分製作中．

やりたい事は次．

設定ファイルから，特定のアプリケーションを指定してアップロード出来る
他人がアップロードした設定を見れる
これを，「状態設定」「スクリプト名解析設定」「無視アプリケーション設定」それぞれに対して出来る

まあそれほど複雑ではない．とりあえずアップロードの為のサーバスクリプト(API by JSON)は実装し終わったので，それを利用するJavaScriptを実装中．

アップロードの流れは次の形にする．

アップロードするファイルを選択する / XMLをペーストする
サーバに一時アップロード
サーバでXMLを解析
正しく解析出来たアプリケーション名，および出力用のデータ，XMLをJSONで返す
クライアントはJSONデータを元に，アップロードするアプリケーションの選択ページを作成
ユーザは，アップロードするアプリケーションの選択，備考および削除キーを入力
サーバに本登録

XMLのパースはクライアントでも出来るだろうけど，今回はサーバにした．

そこで現在，クライアントの，アップロードするアプリケーションを選択するページ作成中．

Webページ製作に結構時間がかかっていてやな感じ．
あと，このWebページを公開するサーバがまだ決まってないのもやな感じ．

AOVCSデーモンがkernel_taskを暴走させる？ (2)

2009-10-08T13:47:00.008+09:00

暴走原因調査つづき．条件を探るのはひとまず置いておいて，Sharkで暴走時のシステムトレースを取得することにした．

やり方．

暴走するのを待つ
暴走したら，Systemトレースを取得
暴走が終わったら，Systemトレースを改めて取得

ふたつのトレースを比べて，明らかな違いが見つかれば，そこに暴走原因が潜んでいる可能性が高い．

リザルト．

まずはSummary．左が暴走時，右が通常に戻った際．

KernelのCPU利用比率が高い以外は特に際立った差は見つからない．

kernel_taskを展開して，何の処理がCPUを消費しているかを見れないかなー，と思ったのが次．どこを処理しているか全然分かんなくて意味無し．


mach_kernel    4606    1.2 s    255.7 μs    0.0 ns    10.1 ms
0x4A393D4    160    516.0 ms    3.2 ms    4.3 μs    10.1 ms
0x54A67A8    341    509.1 ms    1.5 ms    4.3 μs    10.1 ms
0x4A817A8    802    33.9 ms    42.3 μs    4.3 μs    114.9 μs
0x6D4A7A8    730    23.2 ms    31.8 μs    4.1 μs    495.4 μs
0x7B17000    735    21.1 ms    28.6 μs    4.0 μs    467.8 μs
0x513AB7C    729    20.7 ms    28.4 μs    4.0 μs    223.8 μs
0x60423D4    719    20.3 ms    28.2 μs    4.0 μs    177.6 μs
0x4BCC7A8    8    16.2 ms    2.0 ms    6.0 μs    4.5 ms
0x4BC87A8    135    7.1 ms    52.8 μs    4.2 μs    156.6 μs
0x863AA0    5    5.4 ms    1.1 ms    5.0 μs    1.8 ms
0x4B0D000    104    2.2 ms    21.3 μs    4.1 μs    51.0 μs
0x48FF7A8    60    861.3 μs    14.4 μs    4.1 μs    37.0 μs
0x54B97A8    34    674.9 μs    19.9 μs    4.2 μs    116.4 μs
0x54A37A8    19    365.5 μs    19.2 μs    4.2 μs    42.2 μs
0x4A67B7C    11    361.4 μs    32.9 μs    5.0 μs    66.2 μs
0x48FF3D4    13    198.7 μs    15.3 μs    4.1 μs    42.1 μs
0x58AA000    1    45.3 μs    45.3 μs    45.3 μs    45.3 μs
0x4A42000    -    -    -    -    -
0x48FFB7C    -    -    -    -    -
Idled Thread - CPU #2    -    -    -    -    -
Idled Thread - CPU #1    -    -    -    -    -

見ても分からず．

Traceタブの結果は見ても対して意味が無いのでスルー．なので次は，Timeline．
やはり左が暴走時で，右が平常時．

暴走時の方，2つのkernel_task(上から5個目と6個目)がやたら同期取りながら実行している．なんだこれ？？
拡大して調べると，ほぼ等間隔，だいたい30msec毎に処理しているみたい．暴走時はGUIとかのレスポンスが悪くなるんだけど，その原因がこれか．

ちょっと拡大したのが次．

実行時間はまちまちだけど，スケジューリングが等間隔っぽいのは分かる．

さらに拡大．

ほぼ同期しているのが確認出来る．
あと，2つのスレッドでCPU割当が終了する(スケジューリング対象外となる)理由が，上側スレッドは必ずBlockedなのに対し，下側はBlockedだったりUrgent Preemptionだったりする．Urgent Preemptionってのはよくわかんないけど．

しかしこれ以外の情報はつかめず．

分かった事まとめ．

kernel_taskで2スレッドを同期して実行するヤツが居る

これ以外わからず．普通，何かを同期とって「同時に」処理するなんてやらないと思うんだけどなー．ちょっとカーネルを読んでみるか．それで分かるとは思えないけど．

しかも，しばらく時間が経つとこの暴走が終わるから尚謎．

-----------------------
小テク(？)たち

root権限のプロセスをSharkで監視するには，Sharkをroot権限で立ち上げる．sudo /Developer/Applications/.../MacOS/Shark という形
なぜか2つ以上のトレース結果ファイルを，Sharkで同時に開けない．その場合は，別プロセスのSharkを立ち上げれば良い．open -n *.msharkという形で．

AOVCSデーモンがkernel_taskを暴走させる？

2009-10-07T20:02:00.000+09:00

d-scriptの修正？調査のつづき．デーモンを動かしていると，突然Macが重たくなる，調べるとkernel_taskがやたらCPUを消費している，という問題．

そこまでは分かったのだが，それ以上が分からない．そもそも発動条件が分からないし，本当にデーモンのせいなのかも不明．

そこで，現在試した条件で暴走を確認したかどうかをメモしていく．

フルの状態：何回か確認
GUI無し，ターミナルで通常実行：確認出来ず
GUI付き，DBへの書き出し無し：確認出来ず

とりあえずこれくらい．「確認出来ず」というのは，ある程度長いスパン実行させっぱなしにしても暴走を確認出来なかった，ということ．

AOVCSのwebページ作成中 (6)

2009-10-07T13:48:00.002+09:00

とりあえず暫定として，自宅サーバに置くことにした．
VM上なので，たまに落ちてたりするかもしれません．

http://www.hi.mydns.jp/aovcs/home

尚，まだ文章修正中&ハイライト調整中です．

それらの指摘は，ここのコメントで頂けると幸いです．

AOVCSのwebページ作成中 (5)

2009-09-29T17:30:00.006+09:00

言語選択表示の件，試行錯誤の末，次の場所にした．

ページを開いた時点で視界に入り，かつ区切られているためメインコンテンツを邪魔しない．かな．まあそれなりに満足．

すでにPythonが必須となっている為，Dropboxとかで公開が出来ない．くっ．とりあえず自宅サーバで公開することにしようかな？

AOVCSのwebページ作成中 (4)

2009-09-29T13:16:00.006+09:00

英訳に飽きたらWebページのスクリプトを書く，という作業をやっている．設定uploadページは置いといて，言語選択とかも出来る所まで作った．

ただ，言語選択をどこに置くかがすごく悩ましい．とりあえず今は下に示す場所に置いている．デザイン的にも気に入っている．

でも，液晶の解像度によっては，開いた直後に目に入らないかもしれない．ちょっと良くないかな？悩ましい．

多分，多くの人はこれが普通じゃないっていうのが次．

でも個人的には，タイトルと言語選択が同類に見えてしまうところが好きじゃない．言語選択のとこだけ色を変えればまあでもいいか？

他にも色々迷走中．デザイン的にはこれも好き．ただ，リンクを張るのが難しすぎるので却下．そしてここで縦に書くのは，スペースが足りない．

本文タイトルの上に入れてみた．多分本文タイトルが見づらくなって邪魔．

メニューの脇に．でも本文を見るたびに言語選択が目に入るのは邪魔だと思うから駄目．

色々考えて思ったけど，言語選択の理想はきっと次なんだろう．

開いた際に，すぐに見つけられる
選択した後は，特に気にしなければ目につかない

斜めとか縦書きにするのは，前者と後者を同時に満たせるいい方法だと思ってる．そうすることで「変な場所」として分離出来るから．でも，それを本文のあるセクションに用意するのは，本文が見づらくなって駄目．あーむずかし．

こんなとこに時間かけすぎるのは駄目だと思いつつ，そこそこの使いやすさがないと中身が評価されないので悩みつつ．

d-scriptの修正？調査

2009-09-28T01:00:00.004+09:00

どうもデーモンを動かしっぱなしにしていると，kernel_taskが突然重くなる(CPU100%使い始める)．多分，デーモンのせいなのだと思う．ただ原因も対処法も分からない．

原因として考えられるのは，次の辺りか？

「SQLiteのファイルサイズが大きくなり，commitに時間がかかるから」
でもkernel_taskが暴走するとは考えにくい
「メモリリークが起こって，何かしらの問題を引き起こしている」
でもそれだとトレースの整合性が取れなくなり，デーモンの方にエラーが表示されるはず．現状kernel_taskがしんどくなっても，デーモンにエラーはほぼ出ない
「dtraceのガーベジコレクタが頑張ってる」
GCの頻度がホントに少なければあり得るだろうけど，普通そんなこと無いはず

どれもkernel_taskが突然重くなる原因を綺麗に説明できない．仕方ないので，対症療法として，d-scriptを軽くするとかSQLiteのコンパクションを考えるとかが必要そう．

また，GCが全然発動しないとかあり得るのか調べる為に，copyinに対してのGCが動いているっぽいかを調べてみた．
copyinは，指定したユーザ空間アドレスからデータを引っ張り，カーネル空間にコピーしてそのアドレスを返す関数．GCが働かないとか働く頻度が低いとかあれば，最初にコピーしたアドレスを再利用するまで時間がかかるということになるはず．なので，次のd-scriptを実行してみた．

#pragma D option quiet
syscall::open:entry{
      printf("%p\n", (int *)copyin(arg0, sizeof(char *)));
}

適当なシステムコールをフックして，その引数内のポインタの参照先をコピーし，そのアドレスを表示させている．んでこの実行例が次．

数秒実行させただけだけど，同じアドレスをちゃんと再利用している事が分かる．少なくともcopyinについては，GCはちゃんと動いているみたい．そうなると，他のGCもきっと大丈夫なんだろうな

AOVCSのwebページ作成中 (3) - mod_python インストール to 10.6

2009-09-26T16:25:00.003+09:00

現在アップロードをどうするか行き詰まり，Webページの英訳の方も進まないので，Webページのスクリプトを作成する方向に走ろうと思う．で，その言語としてPythonを使うこととした．正直Webページ製作であればPHPの方が慣れているのだけれど，まあ気分転換&勉強という事で．

開発はもちろんSnow Leopard上．ただ，デフォルトで入っているApacheにはmod_pythonがインストールされていない．以前MAMPで入れたApacheにも．そのため，デフォルトで入っているApacheに，mod_pythonを自分でインストールすることにした．

参照したのは次のページ．

http://d.hatena.ne.jp/namaniku206/20080601/p1
http://mod_python.darwinports.com/

この辺のページを見れば分かるが，MacPorts経由でインストールすることも出来る．でも，そうするときっとflexとかapacheとか色々依存するものをコンパイル&インストールさせられて，時間が無くなると思った．なので，MacPortsでコンパイルしない，を目標とした．

で，色々格闘した所，次の流れでコンパイル&インストールすれば成功した．

ソースコードダウンロード
パッチダウンロード
コンパイル
インストール

とってもざっくり．重要なのは，パッチを当てないとコンパイルが成功しないって所か．

ソースコード&パッチダウンロード

ソースコードはここから．mod_python-3.3.1.tgzを落とせば良い．
http://httpd.apache.org/modules/python-download.cgi

パッチはどこにあるかよくわからなかったので，MacPortsでダウンロードした．

 $ port fetch mod_python

こうすると，自分の環境では/opt/local/var/macports/sources/rsync.macports.org/release/ports/www/mod_python/files にパッチファイルがダウンロードされる．あとはこれらをソースコードに適用すれば良い．ソースコードのアーカイブ，パッチが同じディレクトリにあるとすれば，次の通り．

$ tar -zxf mod_python-3.3.1.tgz
$ cp *.diff mod_python-3.3.1
$ cd mod_python-3.3.1
$ patch -p0 < patch-dist-Makefile.in.diff
$ patch -p0 < patch-src-connobject.c.diff

コンパイル＆インストール

通常通りconfigure，make，sudo make installとすれば良い．

$ ./configure && make
$ sudo make install

そうすると，/Library/Python/2.6/site-packages/mod_python/と/usr/libexec/apache2/mod_python.soが出来る．あとは，httpd.confに次を記述してApache再起動．

LoadModule python_module libexec/apache2/mod_python.so

終わり．動作確認は，http://www.python.jp/doc/contrib/modpython/inst-testing.html
辺りを参考に．

AOVCSのwebページ作成中 (2)

2009-09-25T17:18:00.003+09:00

日本語ページの文章は大体出来た．今は，Configurationの投稿ページを作成中．

AOVCSが良いデフォルト設定を提供できれば，ユーザはほとんど設定せずにバージョン管理を出来るようになるはずである．しかし，多様なアプリケーションの設定を用意するのは，個人では非常に難しい．そのため，ユーザが独自に設定したものをアップロード出来るようにしたい．

現状では，ユーザが手動でアップロードをする形とする．のちのち，AOVCS-daemonの方からアップ出来るようになれば尚良いが．

この要求を単純に満たすだけであれば，掲示板を用意してそこにXMLの設定を貼付けられれば良い．でも出来れば，下で示す要求を満たしたい．

アップロードされているアプリケーションが何かを一覧出来る
興味を持ったアプリケーションについては，設定を表形式およびXML形式で見れる
アプリケーション名や評価(「良」への投票数とか？)によってソート出来る

この辺を満たす方法は無いかと考えて，とりあえず次のWebページに示す形にしてみた．
https://dl.getdropbox.com/u/544268/aovcs-web/floatingTest.html

一覧を表示する際には表やXMLを表示はしない．で，興味を持ったらマウスをShowに持ってく事で，フローティングウィンドウでその中身が見れる．

興味を持ったところにマウスを持ってかないといけないのは，使いづらいかなー？とか，表形式とXMLはまとめて表示してもいいかなー？とか色々思う所はまだある．そのため，こういうデザインで行く，とは決めてない．

AOVCSのwebページ作成中

2009-09-15T21:39:00.006+09:00

以前β版を公開する為に必要な事としてあげた，Webページの作成を実行中．とりあえずOmniGraffleで作成したデザインはこんな．

カラフルなのはセンスが必要で自分には難しいので，インストーラの際にも使ったティールって色のみでほとんど構成する事にした．また，メニューとコンテンツの間は，現在今どこに居るかを示すインジケータ＆トップへジャンプ＆ボトムへジャンプ領域とした．

ほいでこれを，HTMLで書き直す．未だにHTMLは手打ちで，MacのhpDrafterってアプリケーションで行ってる．で，トップページまで作った(トップ/ボトムへジャンプ機能はまだ)のが次のURI．

http://dl.getdropbox.com/u/544268/aovcs-web/index.html

まだどこのサーバに置くか決めていないので，とりあえずdropbox．スクショは次の通り

これからしばらくは，この辺の文章を書く作業&英訳する作業&Configurationをアップロードするページを作る作業になるはず．英訳とか厳しいなー．

AOVCS-bazaarの修正 (2)

2009-09-14T23:20:00.002+09:00

前回の，二段以上のディレクトリ名変更への対応，再帰で簡単に出来た．

    def grabActionFromRenamingChain(self, path, events, depth=5):
      """ define the action using renaming chain of parent directories
      such as: mkdir hoge; touch hoge/foo; mv hoge fuga
      without checking parent directories, the file 'fuga/foo' cannot be found out
      any trace from DB.
      To resolve the problem, we should check the parents.
      This situation rarely causes, so check it too honestly.
      """
      originalPath=path
      if depth==0: return None

      while(1):
          index=path.rfind("/")
          if index==-1: break
          path=path[0:index]
          curpath=path
          while(1):
              result=self.db.search(curpath, [aovcs.DB_MOVETO])
              if result==None: break;
              curpath=result[3]

              renamedPath=originalPath.replace(path, curpath)
              result=self.db.search(renamedPath, events)
              if result!=None:
                  result=list(result)
                  result[2]=originalPath
                  return result

              result=self.grabActionFromRenamingChain(renamedPath, events, depth=depth-1)
              if result!=None:
                  result=list(result)
                  result[2]=originalPath
                  return result

      return None

親ディレクトリの名前変更が見つかって，でもその名前変更を使ってもDBからトレースが見つからなかった場合，そこから改めて親ディレクトリを辿る，という事をする．それが，grabActionFromRenamingChainを再帰的に呼んでいる所．基本はこれだけ．
ただ，これが無限ループになるとまずいので，depth変数で再帰回数を制限している．無限ループになる場合は，ディレクトリ名をAからBに変更し，またAに戻すような場合．もしその中のファイルが何かしらの理由でトレースを取り損ねていたとしたら，A→B→A→ ... を繰り返してしまう．

AOVCS-bazaarの修正

2009-09-14T21:27:00.004+09:00

autoflagsの動作検証しつつ，OmniGraffleでAOVCSのWebページデザインをしていた．すると，現状のautoflagsコマンドでは，OmniGraffleで作成したファイルをうまくautoflagsできないという事が発覚．この修正を行った．

現状うまく扱えない状況というのは，次の通りにして出来る．

新規ディレクトリを作成，その中にファイルを作る (mkdir hoge; touch hoge/fuga)
作ったディレクトリを何かしらに名前変更 (mv hoge foo)
autoflagsの実行

こうすると，新規ディレクトリ内のファイルは，そのパス(foo/fuga)においてDBにトレースが存在しない．これにより，正しくautoflags出来ないという事になってしまう．

これを正しく動作させるには，次の通りにする．前提条件として，あるパス(foo/fuga)でDBからトレースを取得出来なかったとする．

その親ディレクトリに名前変更操作(mv hoge foo)が無いか調べる
あったら名前変更前のパス(hoge/fuga)でDBから検索する

きちんとフローチャートで書くと次の通り．

赤字で，上で示した例を処理させた場合の挙動を示している．

ただし，このフローチャートを書いていて気づいたが，ディレクトリの名前変更が二段以上になったら，これでも対応が出来ない．

mkdir -p hoge/fuga/piyo; touch hoge/fuga/piyo/foo; mv hoge/fuga hoge/bar; mv hoge ooo

こんな感じ．上記のアルゴリズムだと，ooo/bar/piyo/fooは，ooo/fuga/piyo/fooとhoge/bar/piyo/fooは探索するが，hoge/fuga/piyo/fooは探索しない．再帰的に上記のアルゴリズムを適用してあげれば良さげだが，果たして．(現状実装中)

尚上記アルゴリズムをpythonで実装すると次の通り．

    def grabActionFromRenamingChain(self, path, events):
      """ define the action using renaming chain of parent directories
      such as: mkdir hoge; touch hoge/foo; mv hoge fuga
      without checking parent directories, the file 'fuga/foo' cannot be found out
      any trace from DB.
      To resolve the problem, we should check the parents.
      This situation rarely causes, so check it too honestly.
      """
      originalPath=path
      while(1):
          index=path.rfind("/")
          if index==-1: break
          path=path[0:index]
          curpath=path
          while(1):
              result=self.db.search(curpath, [aovcs.DB_MOVETO])
              if result==None: break;
              curpath=result[3]

              renamedPath=originalPath.replace(path, curpath)
              result=self.db.search(renamedPath, events)
              if result!=None:
                  result=list(result)
                  result[2]=originalPath
                  return result

      return None

フローチャートよりもコードの方がなぜか簡単に見える．

AOVCSにGUIをくっつける (7)

2009-09-14T17:01:00.004+09:00

GUIのちょっとした修正．バグレポートを送ってもらう際に，Daemon Messageを添付してもらいたいのだが，そのメッセージをコピーする方法が無い．それを実装する．

とりあえずGUIにメッセージコピーボタンを追加．

次に，このボタンを押した際の動作．

- (IBAction) copyErrors:(id)sender
{
 NSPasteboard *pb=[NSPasteboard generalPasteboard];
 [pb declareTypes:[NSArray arrayWithObject:NSStringPboardType] owner:nil];
 [pb setString:errorMessages forType:NSStringPboardType];
}

まずペーストボードのインスタンスを取得する．次に，declareTypes:owner:メソッドで，コピーしようとしているデータの種類(ここではNSStringPBoardType)を設定．最後に，setString:forType:で，実際にデータをコピーする．
これだけ．これで，errorMessagesの内容をコピー出来る．あとは，Cocoa Bindingsをくっつけて終わり．

errorMessagesの更新部分は本質じゃないのでここでは触れない．

AuthorizationExecuteWithPrivilegesについて

2009-09-09T00:55:00.005+09:00

以前，このエントリでCocoaにおけるsudoのやり方を示した．しかしこの，AuthorizationExecuteWithPrivileges(AEWP)を直接使って実行するやり方は，セキュリティ的に良くないらしい．

この代わりの手段として，次の２つをAppleは挙げている．

AEWPからhelper toolを起動し，それにsetuidさせる (2003, サンプルコード)
launchdを通して起動する (2007, サンプルコード兼ライブラリ)

基本的には，前者よりも後者を推奨とのこと．これは，helper toolの実行環境(環境変数とかかな？)は改変可能だが，launchdから起動した場合は改変不可能だから．
(原文： In the BAS design, an attacker can't directly control the environment which the helper tool inherits, and that prevents a variety of potential attacks. 方法2プロジェクト内のドキュメントより．BASとは，BetterAuthorizationSample，方法2のライブラリ名)

となれば，推奨されている方法2を調べるのが筋．なのだが，これがなかなか難しい．使い方はこのドキュメントの通りなのだろうけど，「単に"sudo dtrace -C -s hoge.d"を実行して，その標準出力およびエラー出力を取得したい」というのを満たすにはオーバースペックに見えてしまう．

ざっと読んだ感じ，実行は次の通りに行われるようだ．

予め，または必要になった際に，システム内のlaunchdが管理する領域にhelper toolをコピー(/Library/LaunchDaemons/<bundleID>.plist, /Library/PrivilegedHelperTools/<bundleID>)
これにより，launchdが/var/run/<bundleID>.socket を作成
アプリケーションから上のソケットに接続すると，launchd経由で，/Library/PrivilegedHelperTools/<bundleID>が起動
起動した<bundleID>=helper toolが，元のアプリケーションから認証情報を取得し，認証を行い，成功したら指定のコマンドを起動

helper toolのインストールは，方法1で行う．これは，1度限りの実行は，方法1でもセキュリティリスクは高くないから．繰り返し実行されるものを方法1でやってしまうと，危険らしい．

うーん，まだまだ使える気がしない．helper toolで実行したdtraceのstdout, stderrはどう取得するのかとか．helper toolインストール用のhelper toolを作らないと駄目だし．もちろんサンプルはあるけど．

AOVCSにGUIをくっつける (6)

2009-09-07T22:30:00.006+09:00

とりあえず出来た．まあ実を言うとAOVCS-GUI(1)の時点で，既に動くようにはなってたんだけど．

実装してある機能は次．

optimizer, reorderer, dtraceの起動/停止 (launch/stopボタンより)
ログの出力 (optimizerのみ，dtraceのstderrは取得出来ておらず)
Mac起動時の，自動起動(Dockにアイコンが出来る事で，Dockから選択出来る)
デフォルト設定ファイルの自動作成 (ファイルが無ければコピーする)

で，せっかくMacのアプリケーションを作ったので，インストーラ (.dmgを開くと出てくる，インストールのガイドライン付きディスクイメージ)を作った．それが次．

結構頑張った！でも，Snow Leopardで作ったこのインストーラ(dmg)，Leopardで開くと何故か画像が表示されない．逆に，Leopardで作ったものをSnow Leopadで開くのは問題ない．うーん，原因が謎．

インストーラの作り方は次の通り．参照したのはここ．

ディスクユーティリティで，dmgを作成 (新規イメージを選択，作成)
dmgをマウント
必要なファイルをdmg内にコピー
インストーラ画像を作成
画像をdmg内にコピー
dmgのFinderメニューから「表示 -> 表示オプションを表示」を選択 (command-jでも可)
背景：ピクチャを選び，先ほどdmg内にコピーした画像を選択
シェルか何かを用いて，コピーした画像をドットから始まるファイル名に変換 (Finderに表示されないようにするため)
コピーしたファイルを適当にレイアウト
dmgをアンマウント
ディスクユーティリティで，今作成したdmgを選択し，変換，イメージフォーマットを読み出し専用にして，作成

以上．

で，今回作成したインストーラは一応次の場所にからダウンロード可能．
http://dl.getdropbox.com/u/544268/aovcs-installer.dmg

LeopardおよびSnow Leopardで一応動作確認している．ただしx64が実行可能でなければならない(optimizer, reordererのFATバイナリ化をまださぼっている)

ただ注意してもらいたいのは，まだα版という事．アクティビティモニタを見ると，リソースの無駄使いをしているという事も十分あり得る(実際何度もあった，修正したが)．くれぐれも試す場合は自己責任でお願いします．

β版とするには，次の事が出来たらにしたい．

数日間，複数台で動かしっぱなしでも暴走しない，Leopard，Snow Leopard両環境で
現状，状態自動設定に対応しているアプリケーションのまとめ (Emacs, Xcodeなど)
現状，スクリプト名抽出に対応しているアプリケーションのまとめ (bash, sh, python)
使い方まとめページ
Configurationをアップできるページ
バグ報告ページ (launchpadで十分か？)

Grand Central Dispatch, リファレンスまとめ

2009-09-06T07:09:00.007+09:00

時間がなくて詳しく読んではいないが，Grand Central Dispatch関係のリファレンスを色々探したので，それのメモ．

Concurrency Programming Guide

http://developer.apple.com/mac/library/documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html

Appleの，マルチコア，メニーコア，GPGPU戦略の方針と方法が大雑把に書かれている．Appleは基本的にスレッドの利用を極力減らし，その代わりにGCDを利用する事を推奨している．以下引用．
-----
The Move Away from Thread:
Although threads have been around for many years and continue to have their uses, they do not solve the general problem of executing multiple tasks in a scalable way. With threads, the burden of creating a scalable solution rests squarely on the shoulders of you, the developer. (...)

Instead of relying on threads, Mac OS X and iPhone OS take an asynchronous design approach to solving the concurrency problem. (...) Typically, this work involves acquiring a background thread, starting the desired task on that thread, and then sending a notification to the caller (usually through a callback function) when the task is done. In the past, if an asynchronous function did not not exist for what you want to do, you would have to write your own asynchronous function and create your own threads. But now, Mac OS X and iPhone OS provide technologies to allow you to perform any task asynchronously without having to manage the threads yourself.

One of the technologies for starting tasks asynchronously in Mac OS X is Grand Central Dispatch (GCD). (...)
-----

Grand Central Dispatch (GCD) Reference

http://developer.apple.com/mac/library/documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html

Grand Central Dispatchのリファレンス(そのまま)．GCDはC言語に対してBlock構文でクロージャ(と今のところ解釈)を追加し，それを利用する事で効果的な分散処理を可能にしている．その，クロージャを利用するAPIのリファレンスというのがより正確なところ．当然CにおけるAPIである．CocoaレベルのAPIは，先述のConcurrency Programming Guideにある．

Threading Programming Guide

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/Introduction/Introduction.html

どういう場合にスレッドを利用しないといけないか，という観点で参照すべきはこれ．そういう観点で見る事で，GCDの長所(記述力)と短所(記述制限)が分かるはず．その辺の話はDesign Tipsにある模様．

OpenCL Programming Guide for Mac OS X

http://developer.apple.com/mac/library/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html

GCD以外の分散，並列処理技術．GPGPUの方．Appleとしては，GCDとOpenCLで並列分散を推進したいので，一応ここに挙げておこう．

以上が，今のところ見つけたリファレンス．サンプルコードとかは，Xcodeのヘルプから各技術名で検索をかければOK．

AOVCSにGUIをくっつける (5)

2009-09-05T22:16:00.005+09:00

第五回．今回は，optimizerが出力するメッセージをパイプから読み込み，一行ずつ処理する方法．C言語でいうfgets的な手段を探す．

まず，NSFileHandleのAPIを参照する．そうすると，データ読み込みとしては次のものがある事が分かる．

- (NSData *)availableData
- (NSData *)readDataToEndOfFile
- (void)readInBackgroundAndNotify
- (void)readToEndOfFileInBackgroundAndNotify

最初の二つは同期読み込みで，読み込めるデータが無かったらすぐに返ってくる．これではfgets的な使い方は出来ない．なぜなら，データが来るまでポーリングでずっと参照し続けなければならないからである．また最後のメソッドも，End-of-Fileが返ってくるまで読み込むというものなので，パイプで少しずつ表示するようなものには適さない．
よって，三番目のreadInBackgroundAndNotifyを使う事になる．

ただ，readInBackgoundAndNotifyは，返り値はvoidである．これを実行したからといって，データが受け取れる訳ではない．ではどうやって受け取るかというと，NSNotificationCenterを使う．NSNotificationCenterは，アプリケーション内のNotificationを受信して，そのNotificationを必要としているオブジェクトに転送する，というものである．先にコードを示すと次．

// launch dtrace, reorderer, and optimizer
- (void) runDaemon
{
 (略)
 // setup to read the optimizer's stderr
 NSNotificationCenter *nc=[NSNotificationCenter defaultCenter];
 [nc removeObserver:self];
 [nc addObserver:self
        selector:@selector(readAsync:)
            name:NSFileHandleReadCompletionNotification
          object:[messagePipe fileHandleForReading]];
 [[messagePipe fileHandleForReading] readInBackgroundAndNotify];
 (略)
}

- (void) readAsync:(NSNotification *)aNotification
{
 NSData *aData=[[aNotification userInfo] valueForKey:NSFileHandleNotificationDataItem];
 if([aData length]){
     [self addMessage:aData];
 }
 if([optimizer isRunning]){
     [[messagePipe fileHandleForReading] readInBackgroundAndNotify];
 }
}
- (void) addMessage:(NSData *)aData
{
 NSString *str=[messageBuffer stringByAppendingString:[[NSString alloc] initWithData:aData
                                                                            encoding:NSUTF8StringEncoding]];
 NSArray *array=[str componentsSeparatedByString:@"\n"];
 NSString *message=nil;
 for(id elem in array){
     if(message!=nil){
         [aViewController sendDaemonMessage:message];
     }
     message=elem;
 }
 messageBuffer=message;
}

こんな感じ．まず，readInBackgroundAndNotifyを実行する前に，NSNotificationCenterに，messagePipeからNSFileHandleReadCompletionNotificationが来たら自分(self)にreadAsync:メッセージを送ってくれと伝える(8-11行)．それを行った上で，messagePipeのreadInBackgroundAndNotifyを実行する．こうすると，何かしらデータを読み込んだらreadAsync:を呼んでくれる．

readAsync:は，引数からデータを読み込み，処理すれば良い．ただし，readInBackgroundAndNotifyでNotification送るのは一度だけである．そのため，一度データを読み取ったら改めてreadInBackgroundAndNotifyを送る必要がある．

また，読み込んだデータは必ずしも改行で終わっているとは限らない．そのため，改行で終わっていなければ，その部分のデータは次のreadAsyncまで保持する必要がある．その保持を，messageBufferを使って行っている．for..in文で，最後の要素=改行を含まないデータを処理しないようにしているのはそのため．

NSTaskはすごく使いやすいと思ったけど，NSFileHandleでは行単位の読み込みがやりづらくてあまり好きにはなれなかった．NSFileHandleからファイルディスクリプタを取り出して，そこからFILE構造体を作り，fgetsを使うというのも出来るけど，それは最終手段だし．
実は何かNSFileHandleをより使いやすくする何かがあったりするのかな？

AOVCSにGUIをくっつける (4)

2009-09-05T16:27:00.005+09:00

4回目．今回は，optimizerやreordererをどうアプリケーションに添付し，どう起動するか．また，dgen.pyで生成したd-scriptをどこに保存するのが良いか．この二つ．

-----
まず前者．どうアプリケーションに添付するかは，既存のアプリケーションを覗いてみると分かる．例えばiCalで使われる画像データは，/Applications/iCal.app/Contents/Resources/内にある．
XcodeはキチンとResourcesディレクトリを用意してくれるので，そこの中に入れてあげれば良い．こんな感じ．

こうする事で，ビルド後もキチンとResourcesにoptimizer等々が保存される．入れる際には，コピーじゃなくて参照としておく．そうすると，あとでoptimizerやreordererを再コンパイルしても，このプロジェクトを再コンパイルするだけで済む．もちろん，コンパイル時には参照じゃなくてコピーになるので安心．コピーにしてしまうと，optimizerとかを編集したら，あらためてコピーし直す必要がある．

で，Resourcesに入れたファイルの利用方法．これは，NSBundleというクラスを使えばそのファイルのパスが取得出来る．例えば次．

[reorderer setLaunchPath: [[NSBundle mainBundle] pathForResource:@"reorderer" ofType:nil]];

typeは拡張子の事．今回はバイナリで拡張子が無いため，nilを指定．これでOK．

-----
次．d-scriptをどこに保存するか．今まで通りホームディレクトリというのは悪くないし，そっちの方がd-scriptの状況を把握しやすいというメリットもある．でも，本質的にd-scriptは一時ファイルにすぎないという面もある．今回は後者の特徴をふまえて一時ディレクトリに作成する事にする．で，その使い方．次の通り．

dscriptPath=[NSTemporaryDirectory() stringByAppendingPathComponent:[[NSProcessInfo processInfo] globallyUniqueString]];

一時ディレクトリのパスを取得し，その中にユニークな文字列でファイルを作成すれば良い．これだけ．

AOVCSにGUIをくっつける (3)

2009-09-05T14:53:00.009+09:00

GUIの実装3回目．今回は，Cocoaにおいてforkおよびexec, pipeをどうすればいいか．Objective-Cなので当然POSIX APIは使えるので，既存のlauncher.c同様fork/exec/pipeを使って行っても良い．しかし，どうせならCocoaのAPIを使おうと思い，そっちで実装することにした．

調べていくと，NSTask, NSPipeというのがfork, exec, pipeを実現するAPIである事が分かった．リファレンスは次．

Introduction to Interacting with the Operating System: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/OperatingSystem/Concepts/task.html

NSTaskで新規プロセスを作り，実行ファイルを起動するという事が出来る．また，NSPipeでpipeと同様の事が出来る，というものだった．これを参照しながら，POSIXでのfork/exec/pipeをCocoaで書き換えてみる．

POSIX (posix.c):

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
pid_t pid=fork();
if(pid==-1){
perror("Fork failed");
exit(1);
}
if(pid==0){
// child process (execute: ls -l | grep -e "\.c$" )
int fd[2];
if(pipe(fd)!=0){
perror("Pipe failed");
exit(1);
}
// create grandchild
pid=fork();
if(pid==-1){
perror("Fork failed");
exit(1);
}
if(pid==0){
// grandchild process (execute: grep -e "\.c$")
char *args[4];

args[0]=(char *)"grep";
args[1]=(char *)"-e";
args[2]=(char *)"\\.c$";
args[3]=NULL;

close(fd[1]);
dup2(fd[0], STDIN_FILENO);
execvp(args[0], args);
}else{
// child process (execute: ls -l)
char *args[3];

args[0]=(char *)"ls";
args[1]=(char *)"-l";
args[2]=NULL;

close(fd[0]);
dup2(fd[1], STDOUT_FILENO);
execvp(args[0], args);
}
perror("Some error caused (maybe in exec)");
exit(1);

}else{
// parent process
int st;
waitpid(pid, &st, 0);
if(!WIFEXITED(st) || WEXITSTATUS(st)!=0){
perror("Child caused some errors");
exit(1);
}
return WEXITSTATUS(st);
}
}

シェルで，$ ls -l | grep -e "\.c$" と入力した場合とほぼ同じ事を，Cで実装した．これを，Cocoaを用いた形式に書き換える．

Cocoa(cocoa.m):

#include <Foundation/Foundation.h>

int main()
{
NSTask *lsTask=[[NSTask alloc] init];
NSTask *grepTask=[[NSTask alloc] init];
NSMutableArray *lsArgs=[NSMutableArray array];
NSMutableArray *grepArgs=[NSMutableArray array];

NSPipe *pipe=[NSPipe pipe];

// configure ls
[lsArgs addObject: @"-l"];
[lsTask setLaunchPath: @"/bin/ls"];
[lsTask setArguments: lsArgs];
[lsTask setStandardOutput: pipe];

// configure grep
[grepArgs addObject: @"-e"];
[grepArgs addObject: @"\\.c$"];
[grepTask setLaunchPath: @"/usr/bin/grep"];
[grepTask setArguments: grepArgs];
[grepTask setStandardInput: pipe];

// launch applications
[lsTask launch];
[grepTask launch];

// wait applications
[lsTask waitUntilExit];
return [lsTask terminationStatus];
}

コンパイル方法は，gcc -framework Foundation -fobjc-gc-only cocoa.m．前回同様ガーベジコレクタ必須．
NSTaskインスタンスに情報を全部設定しちゃった状態で，launchメソッドを実行すればいいだけなので楽．POSIXの場合も，posix_spawn辺りのシステムコールを使えば，もう少しObjective-Cっぽくなるかもしれないけど．あと，わざわざpipeを閉じたりする必要がなく，またファイルディスクリプタではなくてNSPipeそのものを渡せばいいってのも楽．ただ，PATHの解決はNSTaskではやってくれない．そのため，実行アプリケーションはフルパスで設定してある．多分どっかにPATHを解決するAPIがあるとは思うけど．
また，Cocoaの方は実行に失敗した場合のエラー処理をサボっている．処理する場合は，@tryで例外をハンドリングすればいい．

一応述べておくと，POSIXの場合とCocoaの場合とで，プロセスの親子関係は同じになってない．POSIXの場合は子，孫だったけど，Cocoaでは二人の子供ってなっているので．実際のシェルは，後者の形で実装していると思うけど．

また，コンパイル方法を見れば分かる通り，実際にはCocoaのフレームワークを使ってない．まあでも，Cocoa上でforkとかを実行する方法と捉えてもらえば，Cocoaっていうのは間違ってないはず．

Bloggerのデザイン修正

2009-09-04T23:01:00.003+09:00

前々から思ってたけど，直してなかったBloggerのデザイン．

コンテンツの幅が固定で，いくらウィンドウが広くてもちっちゃくしか表示されない！

ソースコードとか折り返しまくりだし，とても読みづらい．なのでテンプレートをいじいじして，今表示されている通りに変更した．コンテンツの元幅が480pxに対して，現状が720px．1.5倍！
残念ながらウィンドウ幅に応じて自動的に，とまでは大変なのでしなかったが，今の環境(1280x800)で読むにはすばらしく快適．

今回の変更で，解像度が横1000pxくらい無いと見づらいということになっていますが，ご了承ください．Google Analyticsを見る限り，最低でも1024あるので大丈夫だと思いますが．

また，Firefox以外のブラウザで表示が大丈夫かを確認する，という事もやっていない為，変であればコメントください．

AOVCSにGUIをくっつける (2)

2009-09-04T21:40:00.005+09:00

GUIの作成その２．今回は，デーモンを起動する上で必須な，Cocoa上のsudoっぽいものの利用方法を調べる．インストーラを使うときに出る，「***に認証を許可するには，パスワードを入力してください」なアレ．

Cocoa root権限辺りでググると，どうやらAuthorization Serviceというのを使えばいい事が分かった． (こことか http://www.aynimac.com/p_blog/category.php?k=Cocoa)

Authorization Serviceのリファレンスは，Xcodeのドキュメントからすぐ見つかる．Webでは次．
http://developer.apple.com/mac/library/documentation/Security/Conceptual/authorization_concepts/03authtasks/authtasks.html

ここを参照しながらコーディングをすると，キチンと認証ボックスが表示され，正しくパスワードを入力する事でdtraceをroot権限で実行出来た．そのコードが次．

aovcs-daemon/launcher.m：

// launch dtrace with root privilege
- (NSFileHandle *) runDtrace:(pid_t)pid
{
 OSStatus myStatus;
 AuthorizationFlags myFlags=kAuthorizationFlagDefaults;
 AuthorizationRef myAuthorizationRef;

 myStatus=AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, myFlags, &myAuthorizationRef);
 if(myStatus!=errAuthorizationSuccess) return nil;

 do{
     {
         AuthorizationItem myItems={kAuthorizationRightExecute, 0, NULL, 0};
         AuthorizationRights myRights={1, &myItems};
         myFlags=kAuthorizationFlagDefaults | kAuthorizationFlagInteractionAllowed | kAuthorizationFlagPreAuthorize | kAuthorizationFlagExtendRights;
    myStatus=AuthorizationCopyRights(myAuthorizationRef, &myRights, NULL, myFlags, NULL);
     }
     if(myStatus!=errAuthorizationSuccess) break;
  
     {
         char *toolPath="/usr/sbin/dtrace";
         char *arguments[5];
         FILE *pipe=NULL;
      
         arguments[0]="-C";
         arguments[1]="-s";
         arguments[2]=(char *)[dscriptPath UTF8String];
         arguments[3]=(char *)[[NSString stringWithFormat:@"%d", pid] UTF8String];
         arguments[4]=NULL;
         NSLog(@"%s", [dscriptPath UTF8String]);
      
         myFlags=kAuthorizationFlagDefaults;
         myStatus=AuthorizationExecuteWithPrivileges(myAuthorizationRef, toolPath, myFlags, arguments, &pipe);
         if(myStatus==errAuthorizationSuccess){
          NSLog(@"launch success");
             AuthorizationFree(myAuthorizationRef, kAuthorizationFlagDefaults); 
             return [[NSFileHandle alloc] initWithFileDescriptor:fileno(pipe)];
         }
     }
 }while(0);

 AuthorizationFree(myAuthorizationRef, kAuthorizationFlagDefaults); 
 return nil;
}

認証に成功した場合はdtraceの標準出力ハンドラ(NSFileHandle)を返し，失敗した場合はnilを返す．ただし，正直サンプルコードをそのまま引っ張ってきただけで，詳しいとこは理解してないので，細かい部分は上で示したリファレンスを参照してください．また，ガーベジコレクタ必須(-fobjc-gc-only)でコーディングしているので，そちらも注意．dtraceが使えるのが10.5以降で，それだとガーベジコレクタが存在しているから問題は無いはず．

実行自体はこれで問題なく出来る．他の問題は，先ほど示したAuthorization Serviceを見つけたブログでも言及されていた内容．Authorization Service Programming Guide (P.33)に書いてある内容．

Important: Because of the security risk, calling the AuthorizationExecuteWithPrivileges function is recommended only for special and infrequent use such as repairing setuid bits and installing your application. In the most secure computer systems, the right this function requests times out immediately so every time you call it, the user must authenticate.
Important: You may be tempted to use the function AuthorizationExecuteWithPrivileges to perform privileged operations rather than creating and calling your own setuid tool. Although this might seem like an easy solution, using the AuthorizationExecuteWithPrivileges function without the rest of the Authorization Services functions produces a severe security hole because the function indiscriminately runs any tool as the root user. Setuid tools also have security risks, but they are far less severe than using the function AuthorizationExecuteWithPrivileges for purposes other than those described in this document. Read “Factored Applications” for instructions on creating your own helper tool.

この二つの文章．すごく大雑把に日本語にすると「セキュリティの危険があるから，setuidを行うツール(ヘルパーツール)とインストーラ以外はAuthorizationExecuteWithPrivilegesで直接実行するのは推奨しない」というもの．ヘルパーツールが何なのかもこのリファレンス内に記述されているけれども，さらっと読んだだけではキチンと理解出来なかった．

ただここで述べているのは，自分が作ったアプリケーションを直接root権限で実行すると，そこにセキュリティホールがあった場合大変．そのため，そのリスクを少しでも減らす為にヘルパーツールを使いましょう，というもの．
今回実行するのはdtraceという予め用意されているアプリケーション．そこのセキュリティホールは知らないし，関与出来るものではない．むしろ間にヘルパーツールとかを噛ませる方が，セキュリティリスクは広がるはずである．なのでここでは，直接dtraceを実行しても問題ない，と判断する．

もしこの利用法に問題がありましたら，ぜひともご指摘ください．これはあくまでも自分の解釈ですので．

(2009/9/9追記　やっぱ使うのは怪しいみたい．調査中)

AOVCSにGUIをくっつける

2009-09-04T18:19:00.005+09:00

現状AOVSCのデーモンは，./launcherと実行すれば起動する．しかし，ログインの度にこれを実行するのは面倒であるし，このためにターミナルをひとつ立ち上げておくのも抵抗がある．

そこで，Macのアプリケーションとしてまとめてしまう事を考える．こうすることで，Dockから「ログイン時に開く」を選択し，自動的に起動するようにも出来る．邪魔であれば，Cmd-Hで隠してしまえば良い．これはターミナルでも同じだけど．

色々考えれば考える程GUIをくっつけるのがいー感じに聞こえてくるので，実装することにした．アイディアとしては，現状シェル上で動かしているlauncher (dtrace, reorderer, optimizerを起動)の代わりをObjective-Cで実装するだけ．それほど大変ではない．はず．

まずはGUIのデザイン．必要な機能はそれほど多くない．

daemonの起動，終了
daemonの実行状態
daemonのログ表示

最低限はこれだけ．この他に，アプリケーション起動時に自動的にdaemonを実行する (ユーザの起動ボタンクリックを待たない)という事もオプションとしてあればいいが，それはまた後に．

ということでInterface Builderでデザインを考えた．その結果が次．当然色々悩んだ末の，最終(?)案．

左がデーモン起動前で，右がデーモン起動後．操作はLaunch/Stopボタンしか無し．

さて，これを実装していこう．

d-scriptの修正 - 例外アプリの指定，LeopardとSnow Leopard間の調整

2009-09-02T16:33:00.003+09:00

現状，トレースを取得しないアプリケーション名を指定するには，d-scriptを直接修正するしか方法が無い．しかし，ユーザに直接d-scriptを修正してもらうのは危険性が非常に高い．そのため，configurationファイルを読み込み，d-scriptを吐き出すというスクリプトを作成する事とした．

やる事は非常に少ない．

configurationファイルからトレースを取得しないアプリを取り出す
取得しないアプリを指定するd-scriptのコードを作成
もととなるd-scriptのテンプレートに上のコードをくっつけ，ちゃんとしたd-scriptを吐き出す

これだけ．また，取得しないアプリを指定するには，次の形式でd-scriptを書いてあげれば良い事になっている．

ignoreExecs["iTunes"]=ignoreExecs["Evernote"]=ignoreExecs["mds"]=ignoreExecs["Mail"]=ignoreExecs["backupd"]=1;

テンプレートからこれを書き込む場所を検出し，そこに読み込んだ例外アプリ一覧を上記の形式で書き出すだけ．特にこった事をする必要も無いと思い，書き込む場所検出は"IGNORE_CONFIGURATIONS();"という文字列マッチを使うだけにした．

configuration読み込みも大したコードではないので，テンプレートからd-scriptを生成するスクリプト(by Python)へのリンクだけ張っとこう．
http://bazaar.launchpad.net/~hitoshi-s/aovcs-bazaar/main/annotate/head%3A/dtrace/dgen.py

もうひとつ．Snow Leopardへの移行時に，引数リストを読み込んでも大丈夫そうかの判定方法を修正した．しかしこのままでは，Leopardユーザがこのアプリケーションを使えないことになる．なので，LeopardかSnow Leopardかどうかで読み込んで大丈夫かの判定方法を変える，という事を考える．

当初は，上で作ったスクリプトでSnow LeopardかLeopardかを判定させ，それに応じて出力を変えるという事を考えた．しかし，PythonからSnow LeopardかLeopardかを判定する方法がすぐには見つからず，挫折．そこで，cppを用いて判定させる事とした．その方法は次の通り．

#include <_types.h>
(略)
#if defined(__DARWIN_10_6_AND_LATER)
  // for Snow Leopard
  this->isClean=SELECT_64_86((curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint64_t)+sizeof(uint64_t))), (curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint32_t)+sizeof(uint32_t))));
#else
  // for Leopard
  this->isClean=SELECT_64_86(uregs[R_SP]==0x1f00000000LL || uregs[R_SP]==0x1f0000001fLL, (curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint32_t)+sizeof(uint32_t))));
#endif

Leopardで検証出来てないけど，多分これで大丈夫なはず．

MacPortsのメモ coreutils, binutils, ptex

2009-08-30T18:38:00.011+09:00

Snow Leopardになったので，portの入れ直しをやる．入れ直さなくても，i386のアプリは動くので問題ない気がする．しかし，portで入れた32bitのライブラリを用いる64bitのアプリケーションが動くとは思わない．なので，どうせならと全部入れ直す事に．

MacPortsはそのままでは動作しないので，次のサイトに書いてある通りにやって再インストール．
http://forums.macrumors.com/showthread.php?t=720035

   1. Open up the Terminal
   2. svn co http://svn.macports.org/repository/macports/trunk/base/
   3. Wait for it to finish checking out files
   4. cd base
   5. ./configure
   6. make
   7. sudo make install
   8. sudo /opt/local/bin/port -v selfupdate

portで入れているアプリケーションで再インスコしたいのは次のもの．結構少ない．

coreutils (lsだけはGNU lsを使いたいので)
binutils (使い慣れたobjdumpを使いたいので)
bash-completion (コマンドライン補完)
ptex (修論)

ということで，これらをインストールする．本文が長いので先に結果を示しておくと，binutils以外はインストール出来た．binutilsは敗北．コマンドは次の通り．

 $ sudo port install coreutils +universal
 $ sudo port install bash-completion +universal
 $ sudo port install ptex +utf8 +no_x11

ptexはFATバイナリには出来なかった．

で，長い本文の始まり．まずは，@wtakuo に教えて頂いたSnow LeopardでMacPortsを使う際のアドバイスを示しておく．

デフォルトは，64bitオンリーでのコンパイル
variantsで+universalを付けておく事(port install *** +universal)で，32bitと64bitのFATバイナリになる
64bitが上手くコンパイル出来ない場合は，build_arch=i386として(port install *** build_arch=i386)32bitに指定すると大丈夫な事がある
ジョブ数(make -j2とか)によってコンパイルがミスる場合は，buildmakejobs=1と指定する(port install *** buildmakejobs=1)と良い

これらを参考にして，基本的にはFATバイナリを作成するという事にした．

まず，今まで入れてたportの削除．

 $ sudo port -f uninstall installed

これで，インストールされたもの全削除になる．-fを付けないと，依存関係が解決出来なくて削除出来ない，と言われてしまうので付ける．

次．coreutilsのインストール．

 $ sudo port install coreutils +universal

特に問題なくインストール出来る．fileコマンドでFATバイナリである事を確認．

 $ file `which gls`
/opt/local/bin/gls: Mach-O universal binary with 2 architectures
/opt/local/bin/gls (for architecture x86_64): Mach-O 64-bit executable x86_64
/opt/local/bin/gls (for architecture i386): Mach-O executable i386

次．binutilsのインストール．

 $ sudo port install binutils +universal

しかし，次の通りにWarningが出てコンパイルできず．

 --->  Building binutils
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_binutils/work/binutils-2.19" && /Developer/usr/bin/make -j1 all " returned error 2
Command output: libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c corefile.c -o corefile.o
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c -o format.lo format.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c format.c -o format.o
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c -o init.lo init.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c init.c -o init.o
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c -o libbfd.lo libbfd.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././bfd -I. -I. -I.././bfd -I.././bfd/../include -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -arch i386 -c libbfd.c -o libbfd.o
cc1: warnings being treated as errors
libbfd.c: In function 'bfd_getb_signed_64':
libbfd.c:708: warning: left shift count >= width of type
libbfd.c:708: warning: left shift count >= width of type
libbfd.c: In function 'bfd_getl_signed_64':
libbfd.c:731: warning: left shift count >= width of type
libbfd.c:731: warning: left shift count >= width of type
libbfd.c: In function 'bfd_putb64':
libbfd.c:763: warning: right shift count >= width of type
libbfd.c:764: warning: right shift count >= width of type
libbfd.c:765: warning: right shift count >= width of type
libbfd.c:766: warning: right shift count >= width of type
libbfd.c: In function 'bfd_putl64':
libbfd.c:781: warning: right shift count >= width of type
libbfd.c:782: warning: right shift count >= width of type
libbfd.c:783: warning: right shift count >= width of type
libbfd.c:784: warning: right shift count >= width of type
lipo: can't figure out the architecture type of: /var/tmp//ccLOcEia.out
make[4]: *** [libbfd.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-bfd] Error 2
make: *** [all] Error 2

64bitになってsizeof演算子か何かの値が変わって，シフト演算がオーバーフローするようになったのか？まぁでもソースコードを直す訳にもいかない．なので別手段に．

 $ sudo port install binutils build_arch=i386
--->  Computing dependencies for binutils
--->  Fetching binutils
--->  Verifying checksum(s) for binutils
--->  Extracting binutils
--->  Configuring binutils
--->  Building binutils
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_binutils/work/binutils-2.19" && /Developer/usr/bin/make -j1 all " returned error 2
Command output: make[4]: Nothing to be done for `all'.
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c -o dis-buf.lo dis-buf.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c dis-buf.c -o dis-buf.o
/bin/sh ./libtool --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c  -DARCH_i386 -DARCH_powerpc -DARCH_rs6000 .././opcodes/disassemble.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c -DARCH_i386 -DARCH_powerpc -DARCH_rs6000 .././opcodes/disassemble.c -o disassemble.o
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c -o dis-init.lo dis-init.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c dis-init.c -o dis-init.o
/bin/sh ./libtool --tag=CC --mode=compile /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd  -I./../intl  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c -o i386-dis.lo i386-dis.c
libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././opcodes -I. -I. -I.././opcodes -I../bfd -I.././opcodes/../include -I.././opcodes/../bfd -I./../intl -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch i386 -c i386-dis.c -o i386-dis.o
cc1: warnings being treated as errors
i386-dis.c: In function 'print_i386_disassembler_options':
i386-dis.c:9776: warning: format not a string literal and no format arguments
i386-dis.c:9780: warning: format not a string literal and no format arguments
i386-dis.c:9781: warning: format not a string literal and no format arguments
i386-dis.c:9782: warning: format not a string literal and no format arguments
i386-dis.c:9783: warning: format not a string literal and no format arguments
i386-dis.c:9784: warning: format not a string literal and no format arguments
i386-dis.c:9785: warning: format not a string literal and no format arguments
i386-dis.c:9787: warning: format not a string literal and no format arguments
i386-dis.c:9789: warning: format not a string literal and no format arguments
i386-dis.c:9790: warning: format not a string literal and no format arguments
i386-dis.c:9791: warning: format not a string literal and no format arguments
i386-dis.c:9792: warning: format not a string literal and no format arguments
i386-dis.c:9793: warning: format not a string literal and no format arguments
i386-dis.c:9794: warning: format not a string literal and no format arguments
make[4]: *** [i386-dis.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-opcodes] Error 2
make: *** [all] Error 2

が，駄目．x64の方をターゲット(build_arch=i386を消す)にすると，今度は次のエラー．

Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_binutils/work/binutils-2.19" && /Developer/usr/bin/make -j1 all " returned error 2
Command output: libtool: link: /usr/bin/gcc-4.2 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -o objdump objdump.o dwarf.o prdbg.o rddbg.o debug.o stabs.o ieee.o rdcoff.o bucomm.o version.o filemode.o  -L/opt/local/lib ../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a ../libiberty/libiberty.a /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc -lz
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c arparse.c -Wno-error
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c arlex.c -Wno-error
arlex.c:1841: warning: no previous prototype for 'yyget_in'
arlex.c:1849: warning: no previous prototype for 'yyget_out'
arlex.c:1857: warning: no previous prototype for 'yyget_leng'
arlex.c:1866: warning: no previous prototype for 'yyget_text'
arlex.c:1877: warning: no previous prototype for 'yyset_in'
arlex.c:1882: warning: no previous prototype for 'yyset_out'
arlex.c:1887: warning: no previous prototype for 'yyget_debug'
arlex.c:1892: warning: no previous prototype for 'yyset_debug'
arlex.c:1898: warning: no previous prototype for 'yylex_destroy'
arlex.c:1349: warning: 'yyunput' defined but not used
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c ar.c
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c not-ranlib.c
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c arsup.c
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c rename.c
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c binemul.c
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c emul_vanilla.c
/bin/sh ./libtool --tag=CC --mode=link /usr/bin/gcc-4.2 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64  -L/opt/local/lib -o ar  arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a -lfl -lintl -liconv -lc  -lz
libtool: link: /usr/bin/gcc-4.2 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -o ar arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o  -L/opt/local/lib ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lfl /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc -lz
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.././binutils -I. -I. -I.././binutils -I../bfd -I.././binutils/../bfd -I.././binutils/../include -DLOCALEDIR="\"/opt/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -I/opt/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -arch x86_64 -c strings.c
cc1: warnings being treated as errors
strings.c: In function 'strings_file':
strings.c:407: warning: 'stat64' is deprecated (declared at /usr/include/sys/stat.h:465)
make[4]: *** [strings.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-binutils] Error 2
make: *** [all] Error 2

うーん，無理．binutilsはあきらめるか．objdumpじゃなくて，otoolに慣れるようにしよう．

次．bash-completion．どうせシェルスクリプトか何かだろうけど，まあ一応+universalを付けてインストールしておこう．

 $ sudo port install bash-completion +universal
To use bash_completion, add the following lines at the end of your .bash_profile:

if [ -f /opt/local/etc/bash_completion ]; then
. /opt/local/etc/bash_completion
fi

すぐ完了．bash_profileとかへの設定は，元々やってあったので不要．そして一応fileコマンドで確認すると，まあ当然シェルスクリプトファイルだった．

最後．ptexのインストール．これがインストール成功しないと卒業出来ないので超重要．まず次の通りに実行してみた．

 $ sudo port install ptex +utf8 +universal +no_x11

texを入れる為だけにX関係のライブラリを入れるとホントに時間がかかって仕方なくなるので，no_x11ってオプションを試しに付けてみた．もし何か問題があったら，このオプションを外して再コンパイル．
で，やっていくと，次のエラーが出た．

---> Configuring fontconfig for architecture x86_64
---> Configuring fontconfig for architecture i386
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_fontconfig/work/fontconfig-2.7.1-i386" && ./configure --prefix=/opt/local --disable-dependency-tracking --disable-dependency-tracking --with-docdir=/opt/local/share/doc/fontconfig-2.7.1 --disable-dependency-tracking --with-add-fonts=/usr/X11R6/lib/X11/fonts,/Library/Fonts,/Network/Library/Fonts,/System/Library/Fonts,/opt/local/share/fonts " returned error 1
Command output: checking for rand... yes
checking for random... yes
checking for lrand48... yes
checking for a usable iconv... no
checking for freetype-config... /opt/local/bin/freetype-config
checking for FT_Get_Next_Char... yes
checking for FT_Get_BDF_Property... yes
checking for FT_Get_PS_Font_Info... yes
checking for FT_Has_PS_Glyph_Names... yes
checking for FT_Get_X11_Font_Format... yes
checking for FT_Select_Size... yes
checking for FT_Bitmap_Size.y_ppem... yes
checking expat.h usability... yes
checking expat.h presence... yes
checking for expat.h... yes
checking for XML_SetDoctypeDeclHandler... no
configure: WARNING: Cannot find usable expat library. Trying to use libxml2 as fallback.
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBXML2... configure: error: Package requirements (libxml-2.0 >= 2.6) were not met:

Libs.private field occurs twice in '/opt/local/lib/pkgconfig/libxml-2.0.pc'

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBXML2_CFLAGS
and LIBXML2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

(※ただしこの前に，pkgconfigが無いって言うエラーが出ていたので，port install pkgconfigを行っている．その出力は残ってないので書けず)

libxml2のバージョンが古いとのことらしい．なのでportからlibxml2を入れる．

 $ sudo port install libxml2 +universal

これでlibxml2自体のインストールは成功する．しかしこれでもptexのコンパイル時には相変わらず上記のエラーが出る．仕方ないので妥協．さっきのログを見る限り，32bitのconfigureに失敗しているだけで，64bitの方は成功している．そのため，FATバイナリはあきらめて64bitだけにしてみた．

 $ sudo port install ptex +utf8 +no_x11

こうすると，無事，インストール出来た．

 $ file `which ptex`
/opt/local/bin/ptex: Mach-O 64-bit executable x86_64

ちゃんと出来てよかった．実際ptexを走らせると，次の感じ．

 $ platex report9.tex
This is pTeX, Version 3.141592-p3.1.10 (utf8.euc) (Web2C 7.5.4)
(./report9.tex
pLaTeX2e <2006/11/10>+0 (based on LaTeX2e <2003/12/01> patch level 0)
(/opt/local/share/texmf/ptex/platex/base/jarticle.cls
Document Class: jarticle 2006/06/27 v1.6 Standard pLaTeX class
(/opt/local/share/texmf/ptex/platex/base/jsize10.clo))
(/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty)
(/opt/local/share/texmf/tex/latex/graphics/dvipdfmx-contrib-latex/graphics.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty)
(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg)
(/opt/local/share/texmf-dist/tex/latex/dvipdfm/dvipdfm.def)))
(/opt/local/share/texmf/tex/latex/graphics/dvipdfmx-contrib-latex/color.sty
(/opt/local/share/texmf-dist/tex/latex/graphics/color.cfg)
(/opt/local/share/texmf-dist/tex/latex/graphics/dvipsnam.def))
(/opt/local/share/texmf/ptex/latex/url/url.sty) (../style/footmisc.sty

LaTeX Warning: You have requested package `../style/footmisc',
       but the package provides `footmisc'.


LaTeX Warning: Command \@footnotetext  has changed.
       Check if current package is valid.

) (../style/footStyle.sty) (../style/picins.sty
Option `picins' Version 3.0 Sep. 1992, TH Darmstadt/HRZ)
(/opt/local/share/texmf/ptex/platex/base/ascmac.sty
(/opt/local/share/texmf/ptex/platex/base/tascmac.sty))
(/opt/local/share/texmf-dist/tex/latex/tools/bm.sty)
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/opt/local/share/texmf-dist/tex/latex/amsmath/amstext.sty
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/opt/local/share/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/opt/local/share/texmf-dist/tex/latex/amsfonts/amssymb.sty
(/opt/local/share/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) (./report9.aux)
(/opt/local/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/opt/local/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
</Users/hitoshi-s/Library/BitMemo/capture/2008-06-19_16.45.40.png>

LaTeX Warning: \oval, \circle, or \line size unavailable on input line 64.

</Users/hitoshi-s/Library/BitMemo/capture/2008-06-19_16.47.08.png>

LaTeX Warning: \oval, \circle, or \line size unavailable on input line 71.

</Users/hitoshi-s/Library/BitMemo/capture/2008-06-19_16.48.08.png>

LaTeX Warning: \oval, \circle, or \line size unavailable on input line 78.

</Users/hitoshi-s/Library/BitMemo/capture/2008-06-19_16.48.52.png>

LaTeX Warning: \oval, \circle, or \line size unavailable on input line 86.

[1] [2] [3] (./report9.aux) )
Output written on report9.dvi (3 pages, 4740 bytes).
Transcript written on report9.log.

ovalenv辺りで何かWarning食らってるっぽい．けど出力は出来た．で，Mxdviで開こうとしたら，Rosettaをインストールしますか？って言われてストップ．MxdviはPower PCバイナリだったのか！しかも今作者サイトつながらないし．今度にする事に．

で，pdfの作成．

 $ dvipdfmx report9.dvi
report9.dvi -> report9.pdf
[1][2
** WARNING ** Invalid ICC profile: Inconsistent checksum.

pdf_color>> ICC Profile Info
pdf_color>> Profile Size: 4380 bytes
pdf_color>> CMM Type: appl
pdf_color>> Profile Version: 2.0.0
pdf_color>> Device Class: mntr
pdf_color>> Color Space: RGB
pdf_color>> Connection Space: XYZ
pdf_color>> Creation Date: 2008:03:10:03:06:58
pdf_color>> Primary Platform: APPL
pdf_color>> Profile Flags: 00:00:00:00
pdf_color>> Device Mnfct: (null)
pdf_color>> Device Model: (null)
pdf_color>> Device Attr: 00:00:00:00:00:00:00:00
pdf_color>> Rendering Intent: Perceptual
pdf_color>> Creator: appl
pdf_color>> Illuminant (XYZ): 0.964 1.000 0.825
pdf_color>> Checksum: 4f:00:ed:04:36:f6:95:15:52:44:e2:a2:ef:c1:af:f9
pdf_color>> Calculated: 88:de:7b:81:28:7b:77:7a:7d:12:c4:09:e8:9a:da:07

** WARNING ** Invalid ICC profile: Inconsistent checksum.

pdf_color>> ICC Profile Info
pdf_color>> Profile Size: 4380 bytes
pdf_color>> CMM Type: appl
pdf_color>> Profile Version: 2.0.0
pdf_color>> Device Class: mntr
pdf_color>> Color Space: RGB
pdf_color>> Connection Space: XYZ
pdf_color>> Creation Date: 2008:03:10:03:06:58
pdf_color>> Primary Platform: APPL
pdf_color>> Profile Flags: 00:00:00:00
pdf_color>> Device Mnfct: (null)
pdf_color>> Device Model: (null)
pdf_color>> Device Attr: 00:00:00:00:00:00:00:00
pdf_color>> Rendering Intent: Perceptual
pdf_color>> Creator: appl
pdf_color>> Illuminant (XYZ): 0.964 1.000 0.825
pdf_color>> Checksum: 4f:00:ed:04:36:f6:95:15:52:44:e2:a2:ef:c1:af:f9
pdf_color>> Calculated: b7:5e:70:78:94:28:79:8e:60:cc:6e:58:99:c8:fa:f9
][3
** WARNING ** Invalid ICC profile: Inconsistent checksum.

pdf_color>> ICC Profile Info
pdf_color>> Profile Size: 4380 bytes
pdf_color>> CMM Type: appl
pdf_color>> Profile Version: 2.0.0
pdf_color>> Device Class: mntr
pdf_color>> Color Space: RGB
pdf_color>> Connection Space: XYZ
pdf_color>> Creation Date: 2008:03:10:03:06:58
pdf_color>> Primary Platform: APPL
pdf_color>> Profile Flags: 00:00:00:00
pdf_color>> Device Mnfct: (null)
pdf_color>> Device Model: (null)
pdf_color>> Device Attr: 00:00:00:00:00:00:00:00
pdf_color>> Rendering Intent: Perceptual
pdf_color>> Creator: appl
pdf_color>> Illuminant (XYZ): 0.964 1.000 0.825
pdf_color>> Checksum: 4f:00:ed:04:36:f6:95:15:52:44:e2:a2:ef:c1:af:f9
pdf_color>> Calculated: b7:5e:70:78:94:28:79:8e:60:cc:6e:58:99:c8:fa:f9

** WARNING ** Invalid ICC profile: Inconsistent checksum.

pdf_color>> ICC Profile Info
pdf_color>> Profile Size: 4380 bytes
pdf_color>> CMM Type: appl
pdf_color>> Profile Version: 2.0.0
pdf_color>> Device Class: mntr
pdf_color>> Color Space: RGB
pdf_color>> Connection Space: XYZ
pdf_color>> Creation Date: 2008:03:10:03:06:58
pdf_color>> Primary Platform: APPL
pdf_color>> Profile Flags: 00:00:00:00
pdf_color>> Device Mnfct: (null)
pdf_color>> Device Model: (null)
pdf_color>> Device Attr: 00:00:00:00:00:00:00:00
pdf_color>> Rendering Intent: Perceptual
pdf_color>> Creator: appl
pdf_color>> Illuminant (XYZ): 0.964 1.000 0.825
pdf_color>> Checksum: 4f:00:ed:04:36:f6:95:15:52:44:e2:a2:ef:c1:af:f9
pdf_color>> Calculated: b7:5e:70:78:94:28:79:8e:60:cc:6e:58:99:c8:fa:f9
]
72300 bytes written

dviの時と同じくWarningが出た．でもpdf自体はちゃんと出来て，きちんとプレビューで見れる．しかも，前回上手くレンダリング出来てない！って言った，ovalenvが正しく表示出来るようになってるし．なぜ？

まぁということで，+no_x11オプションを付けても，今のところ問題ない．おかげで今回のでインストールされたportは次の通りで，かなり少なく済んでる．

 $ port installed
The following ports are currently installed:
autoconf @2.64_2 (active)
automake @1.11_0+universal (active)
bash-completion @1.0_1
bash-completion @1.0_1+universal (active)
cairo @1.8.8_0+macosx+no_x11 (active)
coreutils @7.5_0
coreutils @7.5_0+universal (active)
expat @2.0.1_0 (active)
fontconfig @2.7.1_0+macosx (active)
freetype @2.3.9_0+macosx+universal (active)
gd2 @2.0.35_5+no_x11 (active)
gettext @0.17_4 (active)
ghostscript @8.70_0+no_x11 (active)
ghostscript-fonts-hiragino @8.70_1+darwin_10 (active)
gmp @4.3.1_1 (active)
gperf @3.0.4_0 (active)
help2man @1.36.4_1+universal (active)
jpeg @6b_3 (active)
libiconv @1.13_0 (active)
libpixman @0.14.0_0 (active)
libpng @1.2.38_0 (active)
libtool @2.2.6a_0 (active)
libxml2 @2.7.3_0+universal (active)
lzmautils @4.32.7_1 (active)
m4 @1.4.13_0+universal (active)
ncurses @5.7_0+darwin_10 (active)
ncursesw @5.7_0+darwin_10 (active)
nkf @2.0.9-20090426_0 (active)
p5-locale-gettext @1.05_0 (active)
perl5 @5.8.9_0 (active)
perl5.8 @5.8.9_3 (active)
pkgconfig @0.23_1 (active)
pTeX @20090703_0+no_x11+utf8 (active)
t1lib @5.1.2_1 (active)
texi2html @1.82_0 (active)
texinfo @4.13_0 (active)
zlib @1.2.3_2+universal (active)

X関係が全然入って無いのは，すっきりしてていい．

Snow Leopardへの移行 - AOVCSの修正

2009-08-29T18:58:00.002+09:00

Snow Leopardへの移行したために，今まで実装してきたAOVCSの一部を修正する必要があった．それでどこを修正したかのメモ．

optimizerの修正

とりあえず再コンパイル(64bitでコンパイル)してそのまま走らせてみると，一瞬でメモリを食いつぶすことが判明．メモリリークかなーと思いながら調べていくと，無限ループに陥っている事が分かった．64bitだとなかなかメモリアロケーションに失敗しないから，無限ループでもプログラムが全然落ちない模様．にゃるほど．

で，問題のコードが次．

optimizer/bufReader.cpp：

vector<string> BufReader::explode(string& str,char delim)
{
vector<string> result;
unsigned int curpos=0;
unsigned int size;

while((size=str.find_first_of(delim,curpos))!=str.npos){
 if(size>curpos){
   result.push_back(str.substr(curpos,size-curpos));
 }
 curpos=size+1;
}
if(curpos!=str.length()){
 result.push_back(str.substr(curpos));
}
return result;
}

sizeの型がunsigned intになっているのが問題．ついでにcurposの型もsize_tであるべき．32bitではたまたまfind_first_ofの正しい返り値の型size_type(size_t)がunsigned intと一致していたから問題なかっただけ．このままコンパイルすると，"bufReader.cpp:157: warning: comparison is always true due to limited range of data type"という警告が出る．whileの条件のところが常にtrueになるようだ．そのせいで，無限ループに陥ってたという事．しかしこれが何故常にtrueになるのかが分からない．なのでちょっと調べてみる．

まず，string::nposはsize_t型で，値は-1，つまり64bitなら0xffffffffffffffffを持つ．これに対して，unsigned int型(32bit)を比較しようとすると，64bitへの変換が起こる．この際，unsignedなので符号拡張が行われず，そのため表現出来る最大値が0x00000000ffffffffとなる．これにより，常に等しくない，!=の条件式を適用すれば常にtrueとなるのである．なるほどー．
もし，unsignedが付いていないとすると，符号拡張で0xffffffffffffffffを表現出来てしまう為，上記のエラーは出ない(ただし次の行辺りでunsignedとsignedを比較しているというWarningは出る)．なるほどねー．

dtrace daemon (d-script)の修正

次が，d-scriptの修正．普通に実行する分にはエラーが出ていなくてなかなか気づかなかったのだが，引数リストを取得出来ないという問題がある事に気づいた．まず，テストケースが抜けてたってことが問題．あとで直さないと．
で，テストの方は置いといて，この問題の対処法を検証する．問題となっていたのは次の部分．

  // argv[0] may point invalid area. The way to check it is just a symptomatic treatment
this->isClean=SELECT_64_86(uregs[R_SP]==0x1f00000000LL || uregs[R_SP]==0x1f0000001fLL, (curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint32_t)+sizeof(uint32_t))));

そのスタックから引数リストを読み込んでも大丈夫「そう」かを確認していた部分．これでだいたい動いていたからいいや，と思っていたら，Snow Leopardで全然駄目になった．

調査の経緯は省いて解決法を示すと，次の通りにすればまただいたい動くようになった．

this->isClean=SELECT_64_86((curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint64_t)+sizeof(uint64_t))), (curproc->p_dtrace_argv==(uregs[R_SP]+sizeof(uint32_t)+sizeof(uint32_t))));

32bitの場合と同じ確認方法を使えるようになったって事．dtraceで取得する引数リストへのポインタと，スタックポインタの値が同じ場所を指していればOKというものである．むしろLeopardの時，何故これが使えなかったかが謎．

dtraceのバージョンアップ

http://www.opensource.apple.com/release/mac-os-x-106/
ここからdtraceのコードを参照すると，バージョン(?)が78になってた．Leopardの時は48-1だったから，結構進んだ？なので，CWDとか引数リストとかが解決されてないか期待しながらソースを参照した．

scripts/darwin.d：

pr_psargs = P->p_comm; /* XXX omits command line arguments XXX */
(略)
/* XXX Really want vn_getpath(curproc->p_fd->fd_cdir, , ) but that takes namecache_rw_lock XXX */
inline string cwd = curproc->p_fd->fd_cdir->v_name == NULL ?
 "<unknown>" : stringof(curproc->p_fd->fd_cdir->v_name);

変わってなかった．

Snow Leopardへの移行

2009-08-29T16:23:00.005+09:00

先日Snow Leopardが発売されたので，早速インストールしてみた．今まで作ってたプログラムが，Snow Leopardでも動くのかを試す為に．クリーンインストールではなくて普通にアップグレードでインストール．およそ1時間でインストール完了．

そこで起こった問題大きいのから小さいのまで．

iStat menusが動かない => 日付を表示させる為に入れていたのだが，Snow Leopardからは環境設定の日付と時刻で表示出来るようになっているので，不要，アンインストール
Growl Mailが動かない => 代替策無し，結構ショック．Growl自体は問題なく動く
64bitアプリに対してSIMBLが動かない => SafariやターミナルでMega Zoomer，TerminalColoreopardが使えなくなる．痛い
Exposeの展開レイアウトが変わる => 今までのノリで使うと，ウィンドウ選択をミスる
locateコマンドが最初は使えない => DBが削除されているため．locateコマンドを実行すると出る方法に従って，DBを再構築すればOK
64bitカーネルで起動出来ない => MacBook Air(2008初期モデル)EFI自体は64bitに対応しているんだけど，Appleの戦略かなにかのせいで，64bitでは起動出来ず
プレビューの表示がおかしい時がある => 後述

1日触って出てきた不満はこんな感じ．ディスク容量が結構増えた以外は，軽くなったとかそういう印象も薄く(立ち上げてるアプリが少ないと軽いので，メモリか，またはグラボ辺りがネックか？)，あんま変わらない感じ．ベンチマークとかじゃなくてあくまでも体感でしか無いけど．

そして下の画像が，プレビューの問題．一緒に表示しているのは，Adobe Readerの結果．プレビューが問題って事が分かるはず．
プレビュー：

Adobe Reader：

ちなみにこれは，Texのovalenvって環境．picins.styを入れると使える．

※8/29 20:00追記
32bitでプレビューを起動しても同じ現象が起こった．プレビューに入り込んだバグと考えればいいのかな．
(32bitでの起動法：Finderからプレビューを選択，情報を見る，32ビットモードで開く)

ToDo処理その5 - dry-runの実装

2009-08-27T18:36:00.003+09:00

ToDo処理その5．今回は，autoflagsコマンドがどういう動作をする予定かを表示する，dry-runの実装．以前書いたToDo一覧に書き損ねていたものだけど．

この機能は非常に重要．当然実際にautoflagsを実行する前に確認の意味を込めるというのもあるが，それ以上に，初めてautoflagsコマンドを使う人が正しく動作する事を確認するために使うという意味がある．なので，この実装は結構前から必要だと思っていた．

ただそう思っていたにも関わらずなかなか実装しなかったのは，面倒になりそうな部分があったから．嫌な事を後回しにするのは良くないけど，でも避けてた．それが次の部分．

自動設定すべきファイル・ディレクトリの取得は，BazaarのAPIを使う (WorkingTree.iter_changes)
新しいディレクトリがあったら，iter_changesはそのディレクトリだけを返し，その中のファイル名までは返してくれない
現在の実装ではまず自動設定すべきディレクトリが無くなるまで，ディレクトリの追加を行ってから，ファイルの自動設定を行う

この挙動の為，現状，あるディレクトリ以下のファイルを処理する為には，そのディレクトリが実際にリポジトリに追加されている必要がある．しかし，dry-runでは実際に追加する動作をしてはいけないので，ここでコンフリクトが起こるのである．

しかしこれは案外単純にクリア出来ることに気づいた．
新しく，状態を設定したファイル一覧と，ディレクトリの追加で新しく状態設定をすべきファイル一覧という二つの項目を用意する．そして，iter_changesの返り値に，後者の新しく状態設定すべきファイル一覧を加え，そこから前者の状態設定したファイル一覧を取り除く，とやるのである．こうすると，上で述べたiter_changesの挙動と同じになる．あとはこれを実装するだけ．

単純なやり方としては，--dry-runオプションが付いていたらif文で各メソッドの挙動を変えるというものがある．しかし，コードの見通しが悪くなる．
そこで，autoflagsクラスを継承したdry-run実行用のクラスを用意し，そこでメソッドのオーバーライドを行うという方法を取る事にした．--dry-runオプション付きで実行したら，autoflagsクラスが実行をdry-runクラスに投げ直すという形にするのである．

上記の実装を行ったのが次．まず，cmd_autoflagsクラスの変更点．

bazaar-ext/autoflags/autoflags.py：

from bzrlib.option import Option
....
class cmd_autoflags(Command):
   ....
   takes_options =[
       Option('dry-run',
              help="Show what would be done, but don't actually do anything.")]

   ....
   def run(self, dry_run=False):
       if dry_run:
           dryrunner=cmd_autoflags_dryrun()
           dryrunner.run()
           return
   ....

--dry-runオプションを有効にする為，takes_optionsの部分にdry-runを追加，またrunメソッドにdry_runという引数を追加する．これで--dry-runが指定されていたらTrueか何かになるので，その値でdry_runの方に分岐させればよい．

次．dry-runの方の実装．

class cmd_autoflags_dryrun(cmd_autoflags):
   """ autoflags command implementation for dry-run
   This command shows just what will be done, the state of files will never be changed
   """
   stateDefinedFiles=[]
   newTargetFiles=[]

   def add(self, files):
       """ if new directory is added, we should determine
       the state of files in the directory"""
       self.addFiles[0:0]=files
       self.stateDefinedFiles[0:0]=[self.wt.relpath(target[1][2]) for target in files]
       for target in files:
           if os.path.isdir(target[1][2]):
               for filename in os.listdir(target[1][2]):
                   filename=self.wt.relpath(target[1][2])+"/"+filename
                   if os.path.isdir(filename):
                       changeEntry=(None, (None, filename), True, (False, False), (None, None), (None, filename), (None, "directory"), (None, None))
                   else:
                       changeEntry=(None, (None, filename), True, (False, False), (None, None), (None, filename), (None, "file"), (None, None))
                   self.newTargetFiles.append(changeEntry)

   def delete(self, files):
       self.deleteFiles[0:0]=files
       self.stateDefinedFiles[0:0]=[target[1][2] for target in files]

   def move(self, pairs):
       self.movedFiles[0:0]=pairs
       self.stateDefinedFiles[0:0]=[target[1][2] for target in pairs]
       self.stateDefinedFiles[0:0]=[target[1][3] for target in pairs]

   def ignore(self, files):
       self.ignoredFiles[0:0]=files
       self.stateDefinedFiles[0:0]=[target[1][2] for target in files]

   def grabChanges(self, type='both'):
       """ changes format:
       (file_id, path, content_change, versioned, parent_id, name, kind, executable)
       """
       changes=self.wt.iter_changes(self.wt.basis_tree(), want_unversioned=True)
       # filter each files
       changes=[change for change in changes if self.isTreat(change)]
       changes[0:0]=self.newTargetFiles
       changes=[change for change in changes if not self.wt.is_ignored(change[1][1])]
       changes=[change for change in changes if not change[1][1] in self.stateDefinedFiles]
       if type=='file' or type=='directory':
           changes=[change for change in changes if change[6][1]==type or change[6][0]==type]

       return changes
  
   def showResult(self):
       print "The following state will be set if execute autoflags(af) without --dry-run"
       print ""
       cmd_autoflags.showResult(self)

案外これだけで実装出来てしまった．小細工が必要なのは，ディレクトリを追加する場合のnewTargetFilesへの操作，そこに追加する際のパスの形式(リポジトリルートからの相対パス)程度．
もっともっとメンドクサイ事になると身構えてたのにな．ただ，楽になる方に読みが外れても，それはそれで問題．ちゃんとどのくらいの難易度かを判断出来るようになるべきだなー．

ToDo処理その4.5 - アプリケーション名+パスで動作を指定出来るようにする - 2

2009-08-27T16:47:00.009+09:00

アプリケーション名+パス名のつづき．XMLの記述変更はやったので，それを読み込んで，例外動作処理をどうするか，の部分．

XMLの読み込み方法は特に重要でもないので割愛．minidomでちょっとずつパースして処理しているだけ．ソースコードはここにあるので，気になるならばそこで．メソッド名はinsertData．

で，XMLを読み込んだとして，その先の処理の部分．こっちもまぁ全然大した事はない．動作のフローチャートは次の通り．

赤い部分が，今回の拡張で追加された部分．まぁ普通の記述．ソースコードも次の通り．

    def getAction(self, filename, appNames, event):
    """This gives the information of 'What to do for (App.Names, event)',
    and returns one of 'auto/ignore/prompt/alert/undef'."""

    result=("undef","undef")
    if event==DB_MOVEFROM:
        result=("auto", "renamed/moved file")
    if event==DB_MOVETO:
        result=("auto", "renamed/moved file")

    for appName in appNames:
        if self.data.has_key(appName) and self.data[appName][0][event][0]!="undef":
            result=(self.data[appName][0][event][0],appName)
            type=self.data[appName][0][event][1]
            for exception in self.data[appName][1][event]:
                if fnmatch.fnmatch(filename, exception[0]):
                    result=(exception[1], appName+" - pattern: "+exception[0])
                    type=exception[2]
            if type=="strong": return result
    return result

for exceptionの節が，今回の拡張で追加された部分．それだけ．この実装では，例外パターンの優先度は，minidomで先に取得した方が優先度が低くなる．XMLの子要素には優先順位というものが無いはずなので，先に記述したものが優先されるとかはおかしいのである．
基本スタンスとして，重複する例外を書くとどっちで処理するかは分からないという事にする．優先度を数値で指定出来るようにするのもアリだけど，とりあえずはこのままにしよう．

そしてこの実装のテストコードが次．

function test20_setup {
 TEST_NAME="test20"
 TEST_DESCRIPTION="touch ignore pattern: .elc"
};

function test20_run {
 touch .aovcs.conf
 cat ${TEMPLATE_DIR}/.aovcs.conf >> .aovcs.conf
 touch hoge.c
 touch fuga.elc
 bzr init
 autoflags
 commit
 confirmFiles ".aovcs.conf .bzrignore hoge.c"
 confirmIgnores "fuga.elc"

 mkdir dir
 touch dir/poo.elc
 touch dir/poo.el
 autoflags
 commit
 confirmFiles ".aovcs.conf .bzrignore dir dir/poo.el hoge.c"
 confirmIgnores "dir/poo.elc fuga.elc"
};

function test21_setup {
 TEST_NAME="test21"
 TEST_DESCRIPTION="mkdir ignore pattern: bin"
};

function test21_run {
 touch .aovcs.conf
 cat ${TEMPLATE_DIR}/.aovcs.conf >> .aovcs.conf
 mkdir bar
 mkdir bin
 mkdir bar/bin
 mkdir bar/bin/foo
 touch bar/bin/bar
 bzr init
 autoflags
 commit
 confirmFiles ".aovcs.conf .bzrignore bar"
 confirmIgnores "bar/bin bin"
};

このテストは，次の設定ファイルを読み込んで行う．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-configurations>
<action-sets>
 <action-set name="primary">
   <create action="auto" type="weak" />
   <remove action="auto" type="weak" />
 </action-set>
 <action-set name="secondary">
   <create action="ignore" type="strong" />
   <remove action="ignore" type="strong" />
 </action-set>
</action-sets>
<app-configurations>
 <app-configuration action-set="primary">
   <name>touch</name>
   <exceptions>
     <create action="ignore" type="weak" pattern="*.elc" />
   </exceptions>
 </app-configuration>
 <app-configuration action-set="primary">
   <name>mkdir</name>
   <exceptions>
     <create action="ignore" type="weak" pattern="*/bin" />
     <create action="ignore" type="weak" pattern="bin" />
   </exceptions>
 </app-configuration>
</app-configurations>
</aovcs-configurations>

touchが作成した*.elcは無視する，mkdirが作成したbinディレクトリは無視する，という設定．これはemacsやeclipseを見据えたもの．

ToDo処理その4 - アプリケーション名+パスで動作を指定出来るようにする

2009-08-27T16:07:00.002+09:00

ToDoの処理第4回．今回は，アプリケーション名だけでは表現しきれない状況に対処する為，ファイル名のパターンで例外的に処理する部分を実装する．

もう少し具体的な目標を示す．例えばEmacsで作成したファイル．これは通常バージョン管理するが，Emacsがコンパイルしたe-lispファイル(.elc)はバージョン管理すべきではない．こういう，基本的に〜だが，このファイル名/拡張子/ディレクトリ名については例外的に別の処理をする，というのを記述出来るようにしたい．
これに頼りすぎると従来のバージョン管理と同じ感じになってしまい嬉しくないのだが，一部の例外を処理するためには必要．eclipseのバイナリとかを排除する為にもね．

そうするとまずは，この例外記述をどう行うかから考えなければならない．現状Configurationは次のフォーマットで記述している．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-configurations>
 <configuration>
   <create action="auto" type="weak"/>
   <remove action="auto" type="weak"/>
   <appnames>
      <name>Emacs</name>
      <name>Finder</name>
      <name>vi</name>
      <name>touch</name>
      <name>mkdir</name>
      <name>rmdir</name>
      <name>rm</name>
      <name>template.sh</name>
   </appnames>
 </configuration>
 <configuration>
   <create action="ignore" type="strong"/>
   <remove action="ignore" type="strong"/>
   <appnames>
     <name>gcc</name>
     <name>gcc-4.0</name>
     <name>make</name>
     <name>gnumake</name>
     <name>javac</name>
   </appnames>
 </configuration>
</aovcs-configurations>

Configurationがあって，その中に，そのConfigurationに属するアプリケーション名を記述してくというもの．しかしこれだと，例外を記述する場所が難しい．例外は，アプリケーション名と同じ場所に書きたいものなので．そこで，記述を次の形式に大きく変える事とした．

<?xml version="1.0" encoding="UTF-8"?>
<aovcs-configurations>
 <action-sets>
   <action-set name="primary">
     <create action="auto" type="weak" />
     <remove action="auto" type="weak" />
   </action-set>
   <action-set name="secondary">
     <create action="ignore" type="strong" />
     <remove action="ignore" type="strong" />
   </action-set>
 </action-sets>
 <app-configurations>
   <app-configuration action-set="primary">
     <name>Emacs</name>
     <name>emacs</name>
     <exceptions>
       <create action="ignore" type="weak" pattern="*.elc" />
       <create action="ignore" type="strong" pattern="*~" />
       <remove action="ignore" type="weak" pattern="*~" />
     </exceptions>
   </app-configuration>
   <app-configuration action-set="primary">
     <name>Finder</name>
     <name>vi</name>
     <name>touch</name>
     <name>mkdir</name>
     <name>rmdir</name>
     <name>rm</name>
     <name>template.sh</name>
   </app-configuration>
   <app-configuration action-set="secondary">
     <name>gcc</name>
     <name>gcc-4.0</name>
     <name>make</name>
     <name>gnumake</name>
     <name>javac</name>
   </app-configuration>
 </app-configurations>
</aovcs-configurations>

最初に動作ルールを名前付きで記述し，次に，各アプリケーションの設定を例外付きで書く．それほど時間をかけて考えた訳ではないのでベストではないだろうが，記述力としては十分．のちのち拡張したくなったら，patternじゃなくてregexpとか追加すればいいし．

とりあえずXMLの記述方式の変更はこんな．次の投稿で，実際のコード変更の方を述べる．

SQLiteのBUSY問題

2009-08-25T17:09:00.002+09:00

トレースは大方取れるようになった．しかし前回の日記の最後で触れた通り，SQLiteのデータベースのデータ競合でトレースがドロップする事がある，という問題が残っている．

現状行っている操作は，optimizerでのデータ書き込みとautoflagsでのデータ読み込みだけなので，本当は競合が起こらなくて済む (読み込むデータの一貫性が失われるかもしれないけど)はずである．しかし，なぜかoptimizerでのデータの書き込み=トランザクションのcommitや，autoflagsでのselectの実行時に，SQLITE_BUSYエラーが返ってくる．

とりあえずSQLiteのリファレンスを参照して，その辺の記述が無いかを探す．すると，トランザクションの項目に次の文章があった．

An attempt to execute COMMIT might also result in an SQLITE_BUSY return code if an another thread or process has a shared lock on the database that prevented the database from being updated. When COMMIT fails in this way, the transaction remains active and the COMMIT can be retried later after the reader has had a chance to clear.
http://www.sqlite.org/lang_transaction.html

shared lock (読み込み時のロック)がかかっているとcommitに失敗する事がある，とのこと．そして，そのトランザクション自体はまだ有効だから，後で改めてcommitすれば大丈夫，とのこと．
失敗するのには納得いかないが，SQLITE_BUSYが返ってきたら後で改めてcommitするということにしよう．本実装では1秒毎にcommitを実行しているけど，もしcommitに失敗したら，その次のcommitでまとめてやってしまう，という事にする．コードにすると次の通り．

optimizer/dbWriter.cpp：

bool DbWriter::syncDisk()
{
 if(commitTransaction()){
   return beginTransaction();
 }
 return false;
}

commitに失敗したら，新しいトランザクションを開始せず，そのままトランザクションを利用するというものである．これで，トレースがドロップするという問題は解決した．

しかし，まだ解決出来ていない問題もある．autoflagsがselect文を発行するとSQLITE_BUSYエラーが返ってくるというものである．これは，ロックのタイムアウトを大きな値に設定してあげれば良いらしい．

bazaar-ext/autoflags/aovcs.py：

    def createConnection(self):
        self.connection=sqlite3.connect(self.dbpath, timeout=3000)

とりあえず3秒にすると，SQLITE_BUSYエラーで動かないって事が無くなった．

ToDo処理その3 - optimizerの処理速度向上 - SQLite書き込み

2009-08-24T19:15:00.003+09:00

optimizerの処理速度を上げないと，configureなどで負荷があがった際にトレースを取りこぼすという自体になっている．そこで，optimizerの処理速度を上げる．

どこの処理が重いのかを，コメントアウトしながら探すという原始的な方法で調べてみた (Sharkで測定する事を試したが，イマイチな結果)．そこでわかったのは，データベースSQLiteへの書き込みが重いという事．まぁそうだろうなー．
その対策として前回上げていたのが，短時間での追加と削除はDBに書き出さないというものである．しかし，ググっていたら，それより簡単に処理速度を上げられそうな方法があった．

「SQLite の処理は トランザクション の中でないと著しく遅い」
http://www.randynetwork.com/blog/87

トランザクションを使わないで処理すると，実際は毎回トランザクションを発行，毎回ファイルに書き込みを行うという事になるらしい．ここがパフォーマンスのボトルネックとなる．そこで，複数の処理をまとめて1トランザクションとすると，パフォーマンスが改善するとの事．
そこで，1秒に1回の割合でトランザクションのcommitを行う事とした．別にcommit処理を正確に1秒毎に行う必要は無いので，time関数でゆるーく1秒毎に処理させた．

optimizer/controller.cpp：

  int mainloop()
 {
   time_t t=time(NULL);

   while(true){
     time_t t2=time(NULL);
     if(t!=t2){
       writer.syncDisk();
       t=t2;
     }
     (ループ内処理)
   }
 }

こうすると，configureのトレースを処理する際にもトレースのドロップが無くなった．当然より負荷の高い処理を行ったとすればドロップが起こるかもしれないが，現状では大丈夫．よし．

※しかし現在SQLiteのデータロック競合かなにかで，トレースがドロップする問題がまだ存在

ToDo処理その2 - moveしたファイルは，元々作成したアプリケーションで動作を決める

2009-08-21T20:21:00.004+09:00

ToDoの処理その２．現在，次の操作を行った際にhogeというgccで生成したバイナリが追加として扱われるという問題がある．

 $ emacs hoge.c
$ gcc hoge.c
$ mv a.out hoge
$ bzr autoflags

これは，hogeを生成した(正しくは移動した)アプリケーションがmvであり，AOVCSはmvが操作したため自動的に管理すべきと判断するからである．しかしこの挙動は当然よくない．管理すべきでないファイルを，ちょっと名前変更しただけで管理するということになってしまうからである．

よって，ファイルの移動元のファイルはどのアプリケーションが作ったか，という事を調べ，それにより動作を決めるというのが適切となる．そこでAOVCS-bazaarをそのような動作に変更する．移動元を調査するアルゴリズムが次の図．

移動元を無限に辿り続けるのも問題なので，今回は5回までとした．ファイル名を決めるのに四苦八苦して，何度もrenameされると足りないかもだけど，とりあえずこんなもんとしておく．

このアルゴリズムを実装したのが次のコード．

bazaar-ext/autoflags/autoflags.py：

    def resolveAlones(self, buffers):
      """ Search original file from DB and define the actions of moveto files
      """
      for moveto in buffers["moveto"]:
          curtarget=moveto
          for x in range(5):
              # we try 5 times for searching originally created application name
              if self.wt.is_ignored(curtarget[1][3]):
                  buffers["ignore"].append(("originally ignored file", moveto[1]))
                  break
              curtarget=self.db.search(curtarget[1][3], [aovcs.DB_CREATE,aovcs.DB_MOVETO,aovcs.DB_COPYTO,aovcs.DB_LINKTO], date=moveto[1][5])
              if curtarget==None:
                  buffers["undef"].append(moveto)
                  break
              apps=curtarget[4].split("\t")
              (action, appname)=self.conf.getAction(apps,curtarget[1])
              if action=="auto" and (curtarget[1]!=aovcs.DB_MOVETO):
                  buffers["add"].append((appname+": renaming traced", moveto[1]))
                  break
              if action=="ignore" and (curtarget[1]!=aovcs.DB_MOVETO):
                  buffers["ignore"].append((appname+": renaming traced", moveto[1]))
                  break
              if action=="prompt" and (curtarget[1]!=aovcs.DB_MOVETO):
                  buffers["prompt"].append((appname+": renaming traced", moveto[1]))
                  break
              if action=="alert" and (curtarget[1]!=aovcs.DB_MOVETO):
                  buffers["alert"].append((appname+": renaming traced", moveto[1]))
                  break
              if action=="undef" and (curtarget[1]!=aovcs.DB_MOVETO):
                  buffers["undef"].append((appname+": renaming traced", moveto[1]))
                  break
              curtarget=(appname, curtarget)
              if x==4:
                  buffers["undef"].append(moveto)
      buffers["moveto"]=[]
      return buffers

先にコードを書いて，その後で上のアルゴリズムをまとめたので，実装方法が若干違う部分がある．ただ，やっている事は上のアルゴリズムの通り．後で上の図の通りの形に実装し直そう．

ToDo処理その1 - 複数のConfigurationファイルに対応

2009-08-19T19:58:00.003+09:00

随分と間が開いてしまったけど，実装の続き．前回示したToDoを片付けていく．

まずは簡単なものから．複数のConfigurationを読み込めるようにする．
AOVCSでは，ユーザ固有のConfiguration, リポジトリ固有のConfigurationがあり，優先度はリポジトリ固有のものが高い，という形式にする．しかし現状はホームディレクトリのみしか参照していないので，リポジトリルートの方も参照するように変更する．

Configuration読み込み部分は予め，複数のConfigurationを読み込めるよう準備してある．なので，単にリポジトリルートを検出して，そこのConfigurationファイルを読み込めばいいだけ．ソースも簡単．
bazaar-ext/autoflags/autoflags.py：

    def run(self):
        # user-specific configurations
        self.conf=aovcs.Configuration(os.environ.get("HOME")+"/.aovcs.conf")
        self.db=aovcs.Database(os.environ.get("HOME")+"/.aovcs.db")
        self.wt,relpath=WorkingTree.open_containing('.')

        # repository-specific configurations
        if os.path.exists(self.wt.abspath(".aovcs.conf")):
            self.conf.insertData(self.wt.abspath(".aovcs.conf"))

ファイルの存在を確認して，存在したら読み込むというだけ．

ToDos

2009-08-05T19:38:00.003+09:00

AOVCS-bazaarの評価を行う為にまだ実装しなきゃいけない事のリストアップ．10月になる前にはこれらを終わらせたいところ．

プロセステーブルのリフレッシュ機能 (存在しないプロセス名の削除)
複数のConfigurationファイル読み込みへの対応 (ユーザホーム，リポジトリルート)
AOVCSが処理する際の，prompt, alert, undefのファイルへの対応
d-scriptの動的生成 (無視するアプリケーション名を指定出来るように)
DBから不要なデータの除去 (同じファイルのCREATEトレースは2つもいらないなど)
SQLiteの定期的な最適化 (vacuum, reindex，当然負荷が高くないときに)
シンボリックリンクを含むパスの扱い変更 (シンボリックリンクを展開したパスもDBに保存)
元々ignoreされていたものをmvした場合は，ignoreとして扱う
moveしてきて新しく作られたファイルは，元々のファイルを作成したアプリケーションによって追加か削除かを決める (move操作に対する指定は無くなる)
optimizerの処理速度を上げる (短時間で追加と削除を行ったファイルは，DBに書き出す前に検出して書き出さないようにする)
アプリケーション名+パス(拡張子，ファイル名)で，動作を指定出来るようにする

うーん，いっぱいあるなー．順に処理していかないと．

blog: pawo

「Steve Jobs」を読んでの感想

コマンドラインでの並列実行: xargs

Emacs + hi-lock 2

Emacs + hi-lock

Emacs + hide-ifdef-mode の自分なりの使い方メモ

自分なりのアクターモデルの解釈

Io-language 二日目の課題

IO-language のビルド

Autodesk 123D でさるぼぼつくって、いろんな視点で MPO にして 3DS で表示できるようにしてみました

Emacs + auto-complete-clang

ぼそっ

エコノムーブはこの先どーする？

Windowsでどーやってログをとる？

ブログ復帰？

fsloggerの調査 (4)

fsloggerの調査 (3)

fsloggerの調査 (2)

fsloggerの調査

Mac用の高速デーモン作成計画

Mercurialのプラグイン作成方法 (2)

Mercurialのプラグイン作成方法

Gitのプラグイン？拡張コマンド？の作り方

AOVCSの移植性調査 - Linux with SystemTap

AOVCSの実用性検証 - /usr/bin内，/Developer/usr/bin/内，/opt/local/bin/内編 (2)

AOVCSの実用性検証 - autotools

AOVCSの実用性検証 - /usr/bin内，/Developer/usr/bin/内，/opt/local/bin/内編

AOVCSの実用性検証 - /bin/内編

AOVCSの実用性検証 - Interface Builder編

AOVCSの実用性検証 - Emacs版

AOVCSの実用性検証 - vi版

AOVCSの実用性検証 - Xcode版

AOVCSの実用性検証 - Eclipse版 (4) - EclipseUML

AOVCSの実用性検証 - Eclipse版 (3)

AOVCSの実用性検証 - Eclipse版 (2)

AOVCSの実用性検証 - Eclipse版

AOVCS benchmark (2)

AOVCS benchmark

英数 / かな キーの問題

AOVCS-bazaarの修正 (3)

AOVCSの修正案

Snow Leopard用のTex環境

MacPortsのメモ binutils

fslogger

AOVCSのwebページ作成中 (8)

AOVCSのwebページ作成中 (7)

AOVCSデーモンがkernel_taskを暴走させる？ (2)

AOVCSデーモンがkernel_taskを暴走させる？

AOVCSのwebページ作成中 (6)

AOVCSのwebページ作成中 (5)

AOVCSのwebページ作成中 (4)

d-scriptの修正？ 調査

AOVCSのwebページ作成中 (3) - mod_python インストール to 10.6

AOVCSのwebページ作成中 (2)

AOVCSのwebページ作成中

AOVCS-bazaarの修正 (2)

AOVCS-bazaarの修正

AOVCSにGUIをくっつける (7)

AuthorizationExecuteWithPrivilegesについて

AOVCSにGUIをくっつける (6)

Grand Central Dispatch, リファレンスまとめ

Concurrency Programming Guide

Grand Central Dispatch (GCD) Reference

Threading Programming Guide

OpenCL Programming Guide for Mac OS X

AOVCSにGUIをくっつける (5)

AOVCSにGUIをくっつける (4)

AOVCSにGUIをくっつける (3)

Bloggerのデザイン修正

AOVCSにGUIをくっつける (2)

AOVCSにGUIをくっつける

d-scriptの修正 - 例外アプリの指定，LeopardとSnow Leopard間の調整

MacPortsのメモ coreutils, binutils, ptex

Snow Leopardへの移行 - AOVCSの修正

Snow Leopardへの移行

ToDo処理 その5 - dry-runの実装

ToDo処理 その4.5 - アプリケーション名+パスで動作を指定出来るようにする - 2

ToDo処理 その4 - アプリケーション名+パスで動作を指定出来るようにする

SQLiteのBUSY問題

ToDo処理 その3 - optimizerの処理速度向上 - SQLite書き込み

英数 / かなキーの問題

d-scriptの修正？調査

ToDo処理その5 - dry-runの実装

ToDo処理その4.5 - アプリケーション名+パスで動作を指定出来るようにする - 2

ToDo処理その4 - アプリケーション名+パスで動作を指定出来るようにする

ToDo処理その3 - optimizerの処理速度向上 - SQLite書き込み

ToDo処理その2 - moveしたファイルは，元々作成したアプリケーションで動作を決める

ToDo処理その1 - 複数のConfigurationファイルに対応