きりかノート

先週の話になるけれど merge.rb というツールのアナウンスが MacPorts-dev ML に流れていたのでチェック。複数のアーキテクチャのバイナリを lipo やらなにやらでユニバーサルバイナリ化することができるというもの。（タイトルに "SoC" とあるけど、Summer of Code と関係あるのかよくわからん）

試しに実行できるように、ページで紹介されている build_libpng.sh を実行すると、ppc ppc64 i386 x86_64 の 4つのアーキテクチャの libpng が /tmp/libpng 以下に作成される。これで merge.rb を実行する準備ができる。たとえば、

 % merge.rb -i /tmp/libpng ppc ppc64 i386 x86_64
 % lipo -info ./out/usr/local/lib/libpng.dylib
 Architectures in the fat file: out/usr/local/lib/libpng.dylib are: ppc ppc64 
 i386 x86_64

と、それぞれ作成したバイナリと他のヘッダファイル・man などが ./out 以下にマージして作成される（らしい）。単純に lipo するだけでなく、バイナリでないファイルも扱える（マージしない）のが特長なのかな。

たいていのプログラムでは CFLAGS/CPPFLAGS や LDFLAGS をいじるだけでユニバーサルバイナリを生成することができるけれど、そうでないケースもある。たとえば、ruby(1.8.6) では LDSHARED がひっかかって、--enable-shared なユニバーサルバイナリは一発では作ることができなかったりする。多くのソフトウェアを相手にするパッケージシステムでは、こういうアプローチが有効かもしれんね。Xcode もビルド時のログ出力を見ていると、アーキテクチャごとにビルドしてから lipo で fat 化しているみたいだし。

先月公開されたサンプルの Bound Button をちょっと見てみる。名前からだとわかりにくいけれど、Cocoa Bindings でアクションまわりのバインディングについてのサンプル。

このサンプルアプリケーションは

1. ピザかカルゾーネのどちらにするかを選ぶ
2. トッピングを選ぶ（複数選択可）
3. Place your order ボタンを押すと、選択内容と金額が表示される

という動作をする。

ここでの特徴はボタンのバインディング Action Invocation を使っていること。その設定内容を見てみると、次のようになっている。

• target: OrderController.self
• argument: Entrees.selection
• argument2: Toppings.selectedObjects
• Selector Name: "orderEntree:withToppings:"

一般的なボタンのアクションでは -(IBAction)doAction:(id)sender という形式のアクションメソッドを呼び出すけれど、ここでは

 25 @interface OrderController : NSObject
 26 +--  6 lines: {-------------------------------------------------------------
 32 
 33 - (void)orderEntree:(id)selectedEntree withToppings:(NSArray *)selectedToppings;

と、2つの引数を受け取るメソッドがボタンの動作になっている。バインディングで直接データを引数として設定できるわけ。これはちょっとスゴイかも、、、と思ったけれど、意外と使い道ないな。

アクションのターゲットと操作に利用するオブジェクトを独立させたいときってあまりないんだよな。どうせアウトレットやなんやで参照できるし。

そういう理由もあってか、この機能を利用できるクラスはあまり多くない。

 % pwd
 /Developer/ADC Reference Library/documentation/Cocoa/Reference
 % grep -l 'Action Invocation' CocoaBindingsRef/BindingsText/*.html
 CocoaBindingsRef/BindingsText/NSButton.html
 CocoaBindingsRef/BindingsText/NSButtonCell.html
 CocoaBindingsRef/BindingsText/NSOutlineView.html
 CocoaBindingsRef/BindingsText/NSTableView.html

こんだけ。

あんまし興味ないので Safari 3 はインストールしていないのだけれど、耳にした情報ではシステムの Webkit.framework を置き換えてしまうようだ（インストーラだけダウンロードして lsbom で確認）。rubycocoa-talk でも、Safari3 をインストールした状況でビルドがうまくいかないという報告がきていた。

新しい WebKit て、現在の Tiger のものと互換だっていうモノだったのだっけ？そうでなければ、こういった問題を回避する方法はあるよね。

その1、アプリケーションにフレームワークを入れる

MacOS X では、システム共通のフレームワーク（/System/Library/Frameworks, /Library/Frameworks）として以外にも、アプリケーションバンドル内にフレームワークを置くこともできる。そうすれば、他のアプリケーションに影響を与えることなく、Safari3 では新しい WebKit を利用することができるようになる。

 Safari.app/
   Contents/
     MacOS/Safari
     Frameworks/WebKit.framework/...

その2、フレームワーク内に複数バージョンを入れる

もしくは、フレームワークバンドルには複数バージョンを入れることができるから、それを利用すればよい。ただ、フレームワークのバージョンをちゃんと利用しているのって見た記憶がほとんどない。ちょっと扱い難いのだよね、これ。

 /System/Library/Frameworks/WebKit.framework/
   Headers    # Versions/Current/Headers へのシンボリックリンク
   Resources  # Versions/Current/Resources へのシンボリックリンク
   WebKit     # Versions/Current/WebKit へのシンボリックリンク
   Versions/
     A/       # 今のWebKit
     B/       # Safari3用のWebKit
     Current/ # -> A へのシンボリックリンクのまま

iSight でバーコードを読み取るコマンドラインツール bcscan バージョン 0.1 をリリースしました。2007.02.18版からほとんど変わっていません。README がついたくらい？うっかり作ってしまった経緯は「iSight でバーコードを読む」を参照してください。

現状の出来にはいろいろ不満で

• 操作しにくい
  • 位置合わせは対象物を動かすのではなく、ウインドウ上のスキャン位置を動かせばいいじゃん
  • バーコードの位置を自動認識できないか（OpenCV とか使えるのかなあ）
• 認識力の不足
  • 入力画像のハイライトが不足しているとバーコードを認識できない。入力を補正した上でスキャンすれば読み込みの成功率が向上するんじゃないかと。
• iSight以外の入力も受け付けるようにしたい
  • 画像ファイルも読み込みできるようにすれば、検証が楽になりそう

時間とれたらアタックの予定。

みんなが難しそうなことに取り組んでいる間に、あんまり深刻でもないとこの修正。

• rdoc で生成される _rb.html の生成先階層を浅く（r1887）

0.11.1p1 の .dmg を作ったときに、lsbom で 0.11.1 と内容物を比較していて気づいた。なんか信じられないほど深い階層にファイルが作成されるので、てきとうに修正。つーか、作成者の作業ディレクトリがまんま反映されるのはマズイような気がする。

RubyCocoa の bool がなんたらの件で考えてみた。Xcode や gcc いっぱつでユニバーサルバイナリをつくることができるのは便利なんだけど、動作検証するには結局 ppc と intel の両方の環境が必要だよね。でも、とりあえず intel 上で Rosetta でテスト実行したいよな。

アプリケーション（.app）では Finder の操作で強制的に Rosetta で動作させることができるのだから、コマンドラインツールでできない理由もないはず。どうせ環境変数になんか設定するだけでしょ？と軽いノリで調べてみた。

ADC の "Forcing an Application to Run Translated"(日本語)に書いてあるくらいしかないなあ。

• Finder から「Rosetta を使って開く」
• LSPrefersPPC を Info.plist で指定

の2つはアプリケーションバンドルである必要があるのでダメ（Launch Serivce 経由で開始させりゃいいのかも？）。すると残りの選択肢は、

• ppc のみのファイルを(dittoなどで)生成し、それを実行する
• sysctlbyname() を利用して sysctl.proc_exec_affinity を指定し、子プロセスとして実行する

のどちらかになる。

簡単さから言えば前者なんだけど、sysctlbyname() を経由させて引数に与えられたコマンドを実行するツールがひとつあればそれで済む。とーぜん誰か作ってるでしょ！と探してみるものの見つからず。むー、作るの？

（2007/07/09 追記）中川さんがツールを作ってくれた！。だけど intel Mac には /usr/libexec/oah/translate が用意されてたのだった。ちなみに translate に intel のみのバイナリを渡すと、ちゃんとエラーになった。

コミットメールをながめていたら、ずいぶんと前に Jonathan が作ってくれた Ruby スレッドに RubyCocoa を対応させるパッチが trunk にマージされたもよう。([r1881])

これは Ruby 本体にも、スレッドをフックするコードを追加する必要がある。Apple が出荷する MacOS X にインストールされる Ruby にはパッチが適用されているものになる(たぶん 10.5 から)って、以前に Laurent が言っていたのだけど見つけられず。パッチは src/misc にあるので、自分で Ruby をビルドするときにはこれを適用しておくと、RubyCocoa が安定するはず。

7/21(土)に行われる、cocoa勉強会のお知らせ。見学の申し込みは勉強会のメールフォームからどうぞ。ちなみに関西のほうは、1週前の7/14(土)に大阪は北浜で開催の予定です。

概要

• 日時：2007年7月21日（土）13:00〜（終了は17:30くらい）
• 会場：東京 初台 オペラシティ アップルトレーニングルーム
• 予定されている発表（随時更新：2007.07.17 現在）
  • 多言語対応のReadMeファイルの実装
  • 黒パネルの作り方
  • HDCrashReporter
  • 動画関連の発表
  • 活動報告、他