ひ日誌

_ [scheme][c-wrapper][ruby][objective-c][macosx][cocoa] ruby.scm, speak.scm

SICP読書会の図形言語はどうすりゃいいのかななどと考えてたら、いつのまにか脱線してgauche+c-wrapperでRubyのmain.cを書いてみていた。

(use c-wrapper)
(c-load-library "libruby")
(c-include "ruby.h"
           :include-dirs "/usr/lib/ruby/1.8/universal-darwin8.0")
(define (main args)
  (ruby_init)
  (ruby_options (length args) args)
  (ruby_run))

これだけなんだけど

$ gosh ruby.scm --version
ruby 1.8.2 (2004-12-25) [universal-darwin8.0]

とか、RubyCocoaのサンプル

$ gosh ruby.scm TransparentHello.rb
$ gosh ruby.scm sndplay2.rb

などが普通に動く。当たり前なんだけどなんかおもしろい。さらに脱線して、RubyCocoaのTransparentHello.rbあたりと同じものを書いてみようかと思ったけど、NSViewのサブクラスを定義する簡単な方法がなさそうな気がするので、 かわりにNSAppleScriptでしゃべるプログラムを書いてみた。

(use objc-wrapper)
(c-load-framework "Cocoa")
(c-include "Cocoa/Cocoa.h")   ;; ここ時間かかる

(define (speak text)
  (define (escape s)
    (list->string
     (fold-right (lambda (c cs)
                   (if (eqv? c #\")
                       (cons #\\ (cons c cs))
                       (cons c cs)))
                 '()
                 (string->list s))))

  (define (text->source text)
    [NSString 'stringWithCString
              (string-append "say ?"" (escape text) "?"")])

  (let ((script [[NSAppleScript 'alloc]
                 'initWithSource (text->source text)])
        (errinfo (make-null-ptr)))
    [script 'compileAndReturnError errinfo]
    [script 'executeAndReturnError errinfo]))

(define (main args)
  (let ((pool [[NSAutoreleasePool 'alloc] 'init]))
    (with-input-from-port (standard-input-port)
      (port-for-each speak read-line))
    [pool 'release]))

文字列の中の「"」をエスケープする処理を、(正規表現を使わず)foldで書いたあたり、SICPを読んでる影響が出てる。Objectve-CのC部分がSchemeに置き換わった感じ。(CLOS風じゃない)Objective-C風のクラス定義・宣言の構文をマクロで作って、Objective-Schemeとでも名づけたいような雰囲気もある。

_ [scheme][sicp] SICP読書会 #31 図形言語

サイボウズラボさんにて(会場提供どうもです！)。図形言語はc-wrapper経由でQuartzかCocoa使ってとか考えてたけど間に合わず。小人さんがWikiに書いてくれたDrScheme情報を頼りに。どういうわけか、あちこちでlibffiという言葉がやたら飛び交ってた。

ちなみに、RubyCocoaでも、apple-unstabeブランチはすでにlibffiベースで書き直されてます(by Laurent)。もともとのRubyCocoaは、libffiを使わず(というかそもそも存在を知らなかった)、手書き＋ビルド時にヘッダーをパースしてObjective-Cのプログラムを生成(RubyCocoaのソースの中で、もっもと素人くさかったところ)してました。

(追記) 二次会でlibffiの話をしてるときに、名前が思い出せなかったのはffcallでした。GNUstepを入れたときに見つけて気になったらしい(ひ日誌:20040414.html#p01)。ついでに、libffiはPLT Schemeのソースで見つけて気になったらしい(ひ日誌:20050328.html#p03)。

_ [scheme][c-wrapper][macosx][python][rubycocoa] 初めてのQuartzプログラムをSchemeで

SICP読書会の図形言語はどうすりゃいいのかななどと考えてたら、いつのまにか脱線…というほどでもなく、山手線の逆方向に乗っちゃった程度の回り道になって、/Developer/Examples/Quartz/Python/circle.py をgauche+c-wrapperで書いてた。

circle.py では、CGPDFContextCreateWithFilename という関数でコンテキストを生成してるけど、これが見つからないので(隠れ関数？)かわりに CGPDFContextCreateWithURL を使用。また、circle.pyで使っている finish というメソッドは何をしているのか調べてみると、/Developer/Examples/Quartz/Python/API-SUMMARY に:

/* Finalize the context, emitting any pending output. Any future
 * calls to the context object produce undefined behavior. */

と書いてあるんだけど、結局何をしてるのか詳細はわからない。そうこうするうち、/usr/lib/python2.3/plat-mac というディレクトリに、CoreGraphics.py も含めてApplicationServicesフレームワーク関連のラッパーがドカーンと定義されてるのを見つけたので、そちらでチェック。やたらたくさんあるこれらのプログラムは自動生成したのかな？それとも人が書いた？(Laurentに聞いてみよう)。Rubyのも欲しいですな。つまりあれだ！c-wrapperが使ってるパーサを使ってRubyのコードを生成するプログラムをSchemeで書けばいいんじゃないの、SWIG？などと思いつつ、goshのREPLとXcodeのオンラインマニュアルなどを眺めての試行錯誤の結果、動くようになったのが:

(define-syntax dprint-with
  (syntax-rules ()
    ((_ e0 ...) (begin (debug-print e0) ...))))

(use objc-wrapper)
(c-load-framework "ApplicationServices")
(c-include "ApplicationServices/ApplicationServices.h")

(let* ((pageRect (CGRectMake 0 0 612 792))
       (fname (CFStringCreateWithCString kCFAllocatorDefault
                                         (string-append "file://"
                                                        (sys-getcwd)
                                                        "/circle.pdf")
                                         NULL))
       (url (CFURLCreateWithString kCFAllocatorDefault fname NULL))
       (c (CGPDFContextCreateWithURL url (ptr pageRect) NULL)))

  (dprint-with
   (CGContextBeginPage c NULL)
   (CGContextSetRGBFillColor c 1.0 0.0 0.0 1.0)
   (CGContextAddArc c 300 300 100 0 (* 2 (ref pi)) 1)
   (CGContextFillPath c)
   (CGContextEndPage c)
   (CGContextFlush c)
   (CGContextRelease c)))

これが初めてのQuartzプログラム。CFStringなどCoreFoundationのAPIを素で使うのも初めて。これをQuartzプログラミングと呼んでいいものかどうかはともかく…図形言語のことはすっかり忘れてた。

[蛇足] 結局のところ、ほとんどの場合、C以外のプログラミング言語からCで書かれたAPIをマニュアルに従って使うときに、Cのヘッダーファイルにしかない情報(例えば上のプログラムの kCFAllocatorDefault の値など)が必要になるので、c-wrapperのc-includeやRubyCocoaのgenerate_bridge_support.rb(あるいは以前のgen_cocoa_wrapper.rb)のような仕組みで、ヘッダだけにある情報に実行時にアクセスする手段を作ることは、実用的であるかどうかという点でとても重要だと思う。

_ [sicp][scheme][macosx][gauche][c-wrapper][cocoa][objective-c] SICP読書会 #32 図形言語

三田にて(会場提供どうもです！)。図形言語は、つまり draw-line を作ればいい。ということがわかったので、きょうになって作ってみました。いろんな実装パターンを思いついたけど、とりあえず二種類作成、いずれも Mac OS X用。

まずは、gauche + osascript + OmniGraffle.app という組合わせ:

• draw-lineが呼ばれるごとに、線分をスタックに積んでいく
• paintという関数が呼ばれると
• 溜まった線分を OmniGraffle.app に描かせる AppleScript を作り
• osascriptコマンドで実行

draw-line を OmniGraffle.app を使って実装:

(load "./picture-lang")

(define *og-commands* '())

(define (og-draw-line v0 v1 scale)
  (push! *og-commands* 
         (map floor
              (list (xcor-vect (scale-vect scale v0))
                    (ycor-vect (scale-vect scale v0))
                    (xcor-vect (scale-vect scale v1))
                    (ycor-vect (scale-vect scale v1))))))

(define (og-compose-script)
  (define (make-new-line cmd)
    (apply format #f
           (string-append
            "make new line at end of graphics with properties {"
            "point list:{{~d, ~d}, {~d, ~d}}"
            ", thickness: 2.0"
            ", stroke color: {0.0, 0.3, 0.6}"
            "}?n")
           cmd))
  (string-append "tell application ?"OmniGraffle?"?n"
                 "activate?n"
                 "tell canvas of front window?n"
                 (fold-right string-append ""
                             (map make-new-line *og-commands*))
                 "end tell?nend tell?n"))

(define (og-flush)
  (do-applescript (og-compose-script))
  (set! *og-commands* '()))

(define (do-applescript src)
  (use gauche.process)
  (with-output-to-process "osascript" (lambda () (print src))))


(define (draw-line v0 v1)
  (og-draw-line v0 v1 1))

(define (paint painter)
  (painter (make-frame (make-vect 0.0 0.0)
                       (make-vect 400.0 0.0)
                       (make-vect 0.0 400.0)))
  (og-flush))

(define (main args)
  (paint (corner-split wave 2)))

次は、gauche + c-wrapper + Cocoa という組合わせ。

drawRectを呼ぶためだけに、NSViewのサブクラス(DrawView)を作る必要があるのだけど、c-wrapperで派生クラスの定義は大変なので、そこらへんは Objective-C で書いた。Xcode の Cocoa Applicationテンプレートをベースに、libgauche をリンクして、main.m を gauche の main.c の main() を呼ぶコードに直して、Schemeのプログラムを引数に渡して実行。あらかじめ、c-wrapper の genwrapperコマンドで作っておいた、CocoaとDrawViewのwrapperを使って、draw-line を実装。DrawView#drawLineで、線分を描くNSBezierPathを生成して配列に溜めていき、DrawView#drawRectで描画。下準備がえらく大変、簡単には説明しがたいややこしさ、RubyCocoaの便利さを思い知った。以下はコードの断片:

paint-drawview.scm (scheme):

(use cocoa)
(use cocoa-myclasses)
(use objc-wrapper)

(define (view)
  [[Controller 'sharedController] 'drawView])

(define (draw-line v0 v1)
  [(view)
   'drawLine_x0 (xcor-vect v0)
   'y0 (ycor-vect v0)
   'x1 (xcor-vect v1)
   'y1 (ycor-vect v1)])

(define (paint painter)
  (painter (make-frame (make-vect 0.0 0.0)
                       (make-vect 400.0 0.0)
                       (make-vect 0.0 400.0))))
(define (clear)
  [(view) 'clear])

DrawView#drawLine (objective-c):

- (void) drawLine_x0: (float)x0
                  y0: (float)y0
                  x1: (float)x1
                  y1: (float)y1
{
  id path = [[NSBezierPath alloc] init];
  [path setLineWidth: 2.0];
  [path moveToPoint: NSMakePoint(x0, y0)];
  [path lineToPoint: NSMakePoint(x1, y1)];
  [path closePath];
  [lines addObject: path];
  [self setNeedsDisplay: YES];
}

Controller#eval (objective-c):

- (IBAction)eval:(id)sender
{
  NSString* input = [inputField stringValue];
  const char* src = [[NSString stringWithFormat: @"(%@)", input] cString];
  NSLog(@"eval: %s", src);
  ScmObj result;
  ScmObj outport;
  ScmObj str;
  result  = Scm_EvalCString(src, SCM_NIL);
  outport = Scm_MakeOutputStringPort(1);
  Scm_Write(result, outport, SCM_WRITE_WRITE);
  str = Scm_GetOutputString(SCM_PORT(outport));
  NSLog(@"  => %s", SCM_STRING_CONST_CSTRING(str));
}

iShowUというアプリのデモ版を使って、動かしてるところの動画も作ってみた。小さくてぼけぼけなので何してるかよくわからないけど…

• OmniGraffleバージョン動画
• Cocoaアプリバージョン動画

_ [scheme][gauche][c-wrapper][tips] c-wrapperであらかじめwrapperを生成しておく方法など

c-wrapper 0.4.4 のポイントは、CやObjective-Cのヘッダファイルをパースしてwrapperを生成できるところにあると思う。wrapperは、c-include という関数にヘッダーファイルのパスを渡して呼ぶとできる。

(use c-wrapper)
(c-include "stdio.h")
puts                       ; => #<closure (make-c-func make-c-func)>
(puts "hello,world")       ; => hello

Cocoa.h みたいな巨大なヘッダーファイルを c-include に渡すと、かなり時間がかかるので(MacBook13'で12秒かかった)、付属している genwrapper というコマンドを使って:

$ genwrapper cocoa -objc \
    /System/Library/Frameworks/Cocoa.framework/Cocoa \
    /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h \
    > cocoa.scm

wrapperを作っておくと (use cocoa) でロードできるようになる。巨大なSchemeプログラムのread-eval)だからか、それなりに時間はかかるけど少し改善はされる。

(use cocoa)
(use objc-wrapper)
(define *pool* [[NSAutoreleasePool 'alloc] 'init])
(define o [[NSObject 'alloc] 'init])
(cast <string> [[o 'description] 'cString])  ; => "<NSObject: 0x606410>"

同様の方法で、Carbonのラッパーを作っておくこともできる。ただし、cocoa.scmの中にはCarbon関連もかなりの部分のwrapperができてる(たぶん全部ではない)。

_ [lisp] マクロの抽象化の漏れ

最近、少しずつ読んでいるPractical Common Lispの8章で、マクロを書くときの手順:

1. マクロ展開前と展開後のコード例を書く
2. 展開前のコードを展開後のコードに変換するプログラムを書く
3. マクロによる抽象化に漏れがないか確認する

のうち、3番目の抽象化の漏れについて、Joel on Software の "The Law of Leaky Abstractions" (漏れのある抽象化の法則)を引用して説明していた。Lispの本を読んでいて、Joel on Software が出てくるのがちょっと意外性があっておもしろい。ここには、驚き最小の法則(Principle of Least Astonishment)というなんとなく聞き覚えのあるフレーズもでてきた。

8章の最後の方、マクロを作るマクロのところで with-gensyms は納得できたんだけど、囲み記事にあった once-copy の実装は僕の理解力の限界を超えてる。Joel on Software には、抽象化の漏れを防ぐには、結局、どのように抽象化されているか理解するしかないとあって、なるほど確かにそうだなぁと思ったんだけど、once-copy がパズルにしか見えねー。

この本(Practical Common Lisp)、まだ8/32しか読んでないんだけど、タイトルどおり実践的な雰囲気が漂っていてなかなかよい。次の9章では、マクロを使ってテスト用のフレームワークを作るらしい。3章で出てくるCDデータベースにしても、シンプルながらも説明のための例に終っていない、応用がききそうな実用的なものだった。よく考えられてる気がする。

_ [event][mosa][macosx][rubycocoa] 今週末はMOSA湘南ミーティング2006

今週末(金土)は、MOSA Software Meeting in 湘南 2006でRubyCocoaのセッションをやります。きょうはその事前顔合わせ会に参加。昔、Macプログラミングの雑誌連載や本なとで、よく参考にさせていただいていた小池さんや藤本さんとご一緒させて頂きました。他の講師の方々のセッションもそれぞれおもしろそうで楽しみです。

同じく今週末、デンバーのRubyConf 2006 では、RubyCocoa開発者のLaurentさんが Leveraging Mac OS X from Ruby というタイトルのセッションをやります(いけないのが残念)。

_ [rails][ruby][tips] RailsアプリAPI化メモ

MOSAでのネタづくりとして、railsアプリにシンプルなapiを追加してみたのでメモ。リクエストハンドラでsend_dataを呼べばいいらしい。まず、api用のコントローラを生成:

ruby script/generate controller api

一覧をjsonまたはyamlで返すAPIなら:

def list
  books = Book.find_all
  case params[:format]
  when 'json' then send_data(books.to_json, :type=>'text/json')
  when 'yaml' then send_data(books.to_yaml, :type=>'text/yaml')
  end
end

のような感じ。 http://localhost:3000/api/list?format=yaml のように呼ぶ。これくらいならapi用コントローラを作らずに、formatを省略したときは普通に html を返すようにしてもいいかもしれない。RubyCocoa的には、NSDataSource をこのAPIへのHTTPアクセスと YAML の展開で実装すると…

_ [scheme][sicp][javascript][canvas][ruby][rubycocoa] SICP読書会 #34 まだ図形言語

三田にて(会場提供どうもです！)。今回はやけに黙々と問題を解く日でした。

"Why JavaScript is an acceptable Scheme"というフレーズをどこかで見たことがあるような気して、図形言語をJavaScript+<canvas>で実装してみました。"Why Ruby is an acceptable LISP" というフレーズの勘違いかもしれないので、Ruby+Cocoaでも作ってみました。どちらも、SICP図形言語にあります。Ruby版は、Mac OS X 10.4でしか動かないかも(RubyCocoa入りUniversalBinary)。

_ [event][mosa][macosx][rubycocoa][ruby] MOSA湘南ミーティング2006

金土と、MOSA湘南ミーティング2006に参加してきました。RubyCocoaのセッションの発表者の立場としては、時間配分がだめでグダグダになってしまいました。今頃になってあーすればよかったといろいろ思いついてるのだけど、機会があれば何らかの形でフォローさせてもらえればなぁと考えてます。聞き手がいるとRubyのおもしろさやRubyCocoaの良さを伝えようという気が盛り上がってくるので、そんな形式でできないかなとか…

参加者の立場としては、参加できなかったセッションがあったり話す機会がなかった方もいてそこらへんがちょっと残念ですが、Monalisa-auの永野さんやOS Xハッキング!の海上さん、他にもおもしろい方々と知り合い刺激やアイディア(開発ツールなど)を得ることができて有意義でした。僕の発散しまくる話に付き合ってくれた方々、運営の方々、どうもありがとうございしました。

_ [ruby][objective-c][rubyconf2006][wwdc2006][macosx][rubycocoa] Ruby on Leopard ロードマップ

RubyConf 2006で、RubyCocoaコミッタかつAppleのLaurentが、"Leveraging Mac OS X from Ruby"というタイトルのセッションで、Leopard での Ruby に関するロードマップを発表したそうなので、RubyCocoaに関連するあたりを中心に、WWDC 2006での話とmputさんのRubyConf2006ログを参考に整理してみます。

• Cocoa環境用の開発言語として、RubyをObjective-Cと同等のレベルでサポート
• Appleによる開発者向けのドキュメントやサンプルなど
• Rubyのフレームワーク化 (Ruby.framework)
• RubyCocoa, RubyOSA, Ruby on Rails, RubyGems, Rake など標準添付
• Rubyのガベジコレクタ(GC)をObjective-C 2.0のガベジコレクタと統合
• Rubyの文字列、配列、辞書(Hash)などのトールフリーブリッジ化
• フレームワークインターフェースのメタデータ化 (BridgeSupport)
• RubyCocoaはlibffi採用 (apple-unstableブランチで既に実装)

トールフリーブリッジ(toll-free bridge)というのは、Objective-CベースのFoundationフレームワーク(Cocoa環境の一部)と、CベースのCoreFoundationフレームワークとの間で、一部の基本的なオブジェクト(String,Array,Dictionaryなど)の実体が同じものになっている、ということを言うようです。コード片で書くとつまりこういうようなこと:

#import <Foundation/Foundation.h>
#import <CoreFoundation/CoreFoundation.h>
...
NSString*   fstr  = [NSString stringWithCString: "hello,world"];
CFStringRef cfstr = (CFStringRef)[fstr string];
...

実体が同じなので無駄なコピーは不要とかそのあたりが利点かな？RubyCocoaでは、今のところ、NSStringからRubyの文字列に変換すると必ずコピーが発生するわけですが、そういうことをする必要はなくなるはず。

このトールフリーブリッジという言葉は、WWDC2006のときLaurentが使っていて、僕は知らなかったので教えてもらったのに忘れてました、すんませんorz。先日のMSM2006のとき、Cocoa勉強会発行の希少雑誌「Cocoa Life Vol.2」の平井さんの記事を見て再度理解(2回目)。もう忘れないと思う。

_ [macosx][rubycocoa] RubyCocoaリリース予定近況

近いうちに、RubyCocoa 0.5 をリリースする予定です(きむらさんの日記)。Cocoaのクラス階層がRuby上でも同等になるような実装に変更されています。ns_import が必要になるまで発生しないようになっています(lazy import)。

Leopard には RubyCocoa 1.0 が載る予定です。こちらは、apple-unstableブランチで開発が進んでいます。近いうちに devleoper preview が出る予定です。今現在、Tigerの開発環境でビルドできないのだけど、これは単なるバグなのでLaurentが近いうちに直して更新するはずです。

_ [sicp][scheme] SICP読書会 #35 記号データ

今回の会場を提供してくださった弾さんが外出で不参加、なんだか申し訳ないです。 図形言語はもういいよ感が漂っていて、前半で無理矢理終り。2.3 記号データに入る。前はきっちり本文を読んでたけど、ここも読まなくてもいいよという空気ですぐ問題をやりはじめる。問題2.25のquoteの入れ子問題でしばし論議。quoteはリーダで解決されるとか、外側から見ていくから内側のquoteは単なる記号になるというのが、自然言語の引用のルールからのアナロジーで考えるとわかりやすい(hayaさん)とか…

_ [macosx][ruby][cocoa][rubycocoa] RubyCocoa 0.5 previewテスト続く

RubyCocoa の 0.5リリースに向けて、きむらさんが ppcマックでpreviewパッケージを作っては、僕がintelマックで何かしら問題を発見するという繰り返し。なかなかややこしい。手元のPPCマックが、/usr/bin/ruby を上書きしちゃっててテストに使えないのが不便とか、他にもいろいろ試したいことがあったので、思い切ってパーティションを切り直して、まっさらからシステムをインストールし直した(まだおわらん)。このPBG4はかなり気に入っていたのだが(MacBookを使っているとPBG4のできの良さがよくわかる、ただしバッテリー爆発の危険あり)、テスト機になりさがってしまった。

以降、業務連絡。--build-universal を指定してビルドしても、拡張モジュール(rubycocoa.bundle)はビルドするシステムのarchに依存したものができるみたいなので、universal binary を作るように修正して commit しました。STAGE は preview4 です(＞きむらさん)。

他に気付いたところでは、sample/RubyTypeTutor (ヒレガス本の例題をRubyで書いたもの)で、文字をドラッグすると落ちる問題あり。0.4.3d2 では発生しない。これも直したい。

ところで、0.5のsampleにはTim Burksさんの RubyRocks (昔懐かしいゲーム)が入ってます。

_ [macosx][rubycocoa][memo] 素のTigerに RubyCocoa 0.5 preview4 を入れる

ここで、素のTigerというのは、CDでインストールして開発ツールを入れたあと、ソフトウェアアップデートした Mac OS X 10.4.8 のことです。この状態では Xcode が 2.0。これに、MacBookでdmg化した RubyCocoa 0.5 preview4 を入れてみた状態でいくつか確認:

$ ruby -r osx/cocoa -e 'p OSX::RUBYCOCOA_VERSION'
0.5.0preview4

• samples/*.rb これらはちゃんと動く
• samples内のアプリケーションは作れない (プロジェクトが Xcode 2.1以降用なので)
• Xcodeで、Cocoa-Ruby テンプレートからアプリを作ることはできる

つまり 0.5 では、サンプルアプリを作るためには「ADC online会員(無料)になってXcode 2.4をインストールしてね」ということになる。これから Xcode を 2.4 にアップデートするけど、Xcode 2.0 と Xcode 2.1以降は共存できないらしいので、この状態はもう試すことができない。というわけで今のうちにメモ。

(追記)

Xcode 2.4ではsampleのアプリも作ることができました。ということてで、preview4 は ppc と intel どちらでも基本的に問題なさそうな気がします。RubyTypeTutorのバグ(というかおそらくRubyCocoaの変更に追従してない)以外は…

_ [rubycocoa][memo] ひたすらRubyCocoaテスター

テスター向きではないなぁ(ものごとを整理できない、すぐ忘れちゃう)と思いながら、なんだかいろいろやったのでメモ。

[0.5 preview5の問題点]

0.5 preview5 のバイナリパッケージを PowerBook G5 (Tiger)で作ったものを、MacBook にインストールする。sample/*.rb をコマンドで呼ぶと動くけど、simpleapp や Xcodeからアプリが作れない。また、このエラーがでる。

Oct 28 01:26:10 mbw crashdump[24626]: crash report written to: /Users/hisa/Library/Logs/CrashReporter/SimpleApp.crash.log
dyld: Symbol not found: _rb_cObject
  Referenced from: /Library/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa
  Expected in: flat namespace

逆(intelで作ってppcで動かす)は問題なさそう。いずれにしてもRubyTypeTutorはdragすると落ちる。

[apple-unstable]

libffiベースのものをLaurentがTigerで作れるように更新してくれたので作ってみた。sample/*.rb は動くけど、simpleapp の aboutを開くと落ちる。残りはまた今度試してみる。BridgeSupportはc-wrapperを彷彿とさせる。違いは、S式じゃなくとXMLなところとか。

[アプリ配布あれこれ]

Jonathanが作ったstandaloneify.rbというスクリプトは、RubyCocoaアプリを再配布できるように依存解決して必要なライブラリ類をアプリバンドルに放り込むツールなんだけど、おそらく intelやuniversal binary のことを考えていないために、ppc mac で standaloneify.rb を使って作ったアプリがintel macで動かない。これについては、osx/objc/cocoa_macros.rb が nkf に依存してるというのも、UTF-8で行くことに決めた今となっては、いまいちだなぁという気もする(utf-8使えメソッドを発動すれば解決？)。

僕が書いてたときは、サンプルコード駆動開発(このCocoaアプリサンプルをRubyで書くとこうなるだろうというコードを書いて、それが動くようにがんばる！泥臭くてもいいさ！みたいな開発方法。こう表現すると体育会系くさいな)だったのだけど、今はサンプルは放置されぎみなのでこういうことが起きちゃうのもある程度しょうがないのだけど、やっぱりdragしただけで落ちるのはちょっとまずい。dragの単体テストを自動化する方法なんてあるのかな？ そのためのツール(MacアプリGUIテストツール)を売ってるところとかありそうな気もするけど、あったとしても実用的なものがありそうな気がしない(ツール自体がバグだらけとか)。

_ [rubycocoa] 全員1.0の方に注力すべきかも

RubyCocoa 0.5 はすぐにリリースできるかなと安直に思ってたのだけど、preview でサンプルを動かすだけでもちょくちょく問題が見つかってしまい、なかなか出せそうにないです。

今の開発体制は、自然と、開発2(Laurent,きむらさん)テスト1(自分)という感じになっていて、0.5でみつかった問題は、きむらさんが分析・デバッグするというパターンなんだけど、そのバグがapple-unstableではLaurentが修正ずみだったりしてややこしい。どうせこうなるなら、いっそのこと、0.5のリリースを保留・中止にして、apple-unstable(将来の1.0)の方をさっさとtrunkにマージ。全員、そちらの開発すべきなんじゃないかとという気がしてきた。現在のapple-unstableを安定させるという方向。libffi変更後のapple-unstableに、あとどのくらい劇的な変更が入るのかというあたりがポイントかもしれない。

0.4.3d2はとても安定してるように思えるし、もうしばらく現役続行。