ココログ応答しなすぎ
案の定というか、予定通りというか、3/28のメンテナンスからめちゃめちゃ遅くなってる。記事を投稿する自作コマンドがタイムアウトしまくるので、オプションとして XMLRPC のタイムアウトの秒数を指定できるようにしてしまった。
| 固定リンク
案の定というか、予定通りというか、3/28のメンテナンスからめちゃめちゃ遅くなってる。記事を投稿する自作コマンドがタイムアウトしまくるので、オプションとして XMLRPC のタイムアウトの秒数を指定できるようにしてしまった。
| 固定リンク
ダイナミック Objective-C の28回「ランタイムAPIでさらに動的に(2)」や29回「〜(3)」)では、C の関数を Objective-C のメソッドとして追加/置き換えすることについて言及されてる。ここでの C の関数の引数が、型エンコード(連載の20回「メソッドとは何か(3)」参照)の2番め以降で表されているわけだ。で、必ずレシーバ(self)とセレクタ(_cmd)を受け取る。なんだけど、セレクタはなくてもいいんじゃないの?と思わなくもない。
たとえば ruby では、メソッドを C で定義するときはレシーバに相当する VALUE 型の引数をとるけれども、メソッド名は受け取らない。([ruby-dev:28471] あたりを見てると、インタプリタは呼び出されたメソッド名を知っているので、取得することはできると思う。未検証)
同じ関数で、セレクタ/メソッド名によって振る舞いを変更したいってときには、まあ利用できる。だけど、そんなケースはあまり思い浮かばない。そこで RubyCocoa。RubyCocoa では、このセレクタの値をばっちり使っている。具体的に挙げると、handle_ruby_method()(OverrideMixin.m)での、Objective-C から ruby で定義されたメソッドを呼び出しているところ。
RubyCocoa では、ns_override や addRubyMethod:withType: などにより、ruby から Objective-C のメソッドを追加することができる(ns_override も内部的には追加)。ここで Objective-C のメソッドの実装(IMP)としては、いつも同じ関数(*1)が class_addMethods() される。で、実際にそのメソッドが呼び出されたときに、そのセレクタに相当する ruby のメソッドを探して呼び出している。
というわけで _cmd の活躍する現場もあるよって話。おしまい。
(*1) 正確には2つの関数のどちらか。返り値の型が id より大きいサイズのときと、そうでないとき。/usr/include/objc/objc-runtime.h の objc_msgSend_stret() あたりを参照のこと。
| 固定リンク
rentzsch.com の ADC Core Data Video Tutorial 経由で、ADC に Building a Sample Core Data Application が公開されてることを知る。rentzsch.com のほうでは細切れでないムービーがあったのでそっちを見た(15分くらい)。アプリケーションのリリースノート的なものを管理するアプリケーションがサンプル。
"モデルを Interface Builder にドラッグ" の手順がないので、ぱっと見ですげー!というのはないけれど、短時間でひととおり押さえてあるので CoreData の雰囲気をつかむには良いデモだと思う。
| 固定リンク
まだ告知でてないようだけど、秘密にすることでもないので。次の勉強会の日程が決まりました。4/15(土)です。
最近発表してなかったので、今回はやるぞお!と気合いを入れたものの、まだ全然。予定では、CoreData のデータを iTunes のブラウズスタイルで見せるという実装を提示するつもり。NSTreeController と NSBrowser の基本的な動作を説明した上で、今回の実装のデザインの解説とかをするという流れで考えている。まだリファレンスレベルでの実現可能性しか検討してないので、そろそろ動くものをつくってみないとヤバイ。
データモデルの設計時点で迷うことが多いので、なんか指針(カンペ)がほしい。(Cocoa に限らなければ)すでに実装したものがあるんじゃないの?というヨコシマな気持ちを起こして Google に聞いてみた。どうやら iTunes のブラウズのような UI を mSpace と呼ぶらしい。sourceforge.net のリリースファイルが 0 件なんですけど...
| 固定リンク
OSC のときの相談してみようリストから。実現可能性とかあんまり検討してないアイディア段階のもの。
るびまのあなたの Ruby コードを添削します 【第 3 回】 dbf.rbを見ているときに、CoreData でも DSL があったら便利かなあと考えた。以前から、CoreData と Rails の ActiveRecord って似てるんじゃないの?と思っていたところで、この記事を見てできそうな予感がしてきた。作るとしたら NSManagedObjectModel のクラスメソッドあたりに置くのがよいのかな。
Xcode でビジュアルな編集ができるのもいいけど、DSL でテキストとして扱えると diff で差異がわかりやすいというメリットも大きいと思う。
それはそれとして、いいかげん CoreData のデモプロジェクトもつくらないとね。
さらに余談だけど、通常 Xcode で CoreData のモデルをつくると、/Library/Application Support/Apple/Developer Tools/Plug-ins/XDCoreDataModel.xdplugin/Contents/Resources/momc というコマンドで plist 形式のデータにコンパイルされて、アプリケーション内に .mom という拡張子のファイルが作成される。
| 固定リンク
Cocoa のサブクラスではない Pure Ruby なオブジェクトは、RBObject にラップされて Objective-C 側では扱われる。ただ、このラッパーオブジェクトは ruby から Cocoa 側にオブジェクトを渡すたびに生成されるため、同一の ruby オブジェクトが Objective-C では別のオブジェクト(異なる id を持ったオブジェクト)となる。このため、NSOutlineView の item として pure ruby オブジェクトを利用すると正しく動作しないなどの現象が報告されてる。
前置きが長くなったけど、これを解決するための Jonathan によるパッチが[rubycocoa-devel:195]。これをテストしてみた。ちゃんと動いているもよう。
テストコードを書く際に、OCUnit を使う方向で作業をしていたのだけど、RubyCocoa からテストケースを実行する方法がいまいちキレイに書けなかったので放棄。テストケースのバンドルパッケージを作れば、otest で簡単に実行できるようには思うのだけど。
仕方がないので、Objective-C で assert のメソッドをひとつずつ書いて、ruby から Test::Unit::TestCase#assert で検証するという、やや上長な構成にしてみた。それはそれでいまいち。
| 固定リンク
[rubycocoa-devel:230] あたりからの流れで検討していた変更を、ようやくコミット。今まで RubyCocoa では、enum だけが OSX モジュールの定数と扱われていた。文字列系の Cocoa の定数 NS...Key なんかは関数として、OSX.NS...Key と書かないと値がとれない。これが今後は、定数として利用できるようになるので、直感的に OSX::NS... と書いてもちゃんと動く。include してもばっちり。
個人的な気持ちとしては、関数スタイルのほうは定数を定義したものについては obsolete でもいいかなあと思っている。けどまあ、あんまりいじると混乱するしね。
| 固定リンク
RubyCocoa では、Project Builder のプロジェクトファイルを config 時にいくつかの項目を変換している。この仕組みをとっているために、プロジェクトの構成に変更があったときにプロジェクトファイルを変更するのがちょっとめんどい。
そういや OmniFrameworks では、Configurations という別ディレクトリに .xcconfig という拡張子の設定ファイルがあったなと思い出す。ちょっと調べてみると、Xcode 2.2ユーザーガイド: 構成ファイルが見つかった。こういった形で、いくつかの設定を外部ファイルにすれば、プロジェクトファイルをそのまま編集できるようにならないかなと思うわけ。
あー、でも今は Project Builder のプロジェクトファイルだから、Xcode 2.0 以降では編集できないのか。ひさしぶりに 10.2 環境を立ち上げて、Project Builder の設定関連をみてみたけど、どうにもなさそう。がっかり。
| 固定リンク
ふじもとさんと RubyCocoa の今後とか実装上の課題とかを相談しようと思っていたのに、木村が会社に呼び出されてしまったため、なにもできなかったというオチ。
さらに終電でも帰れなかった。明日も朝から続き。
参加したセッションのレポートはまたあとで。
| 固定リンク
情報技術標準化研究センター(INSTAC)の「オープンソースソフトウェアに関する標準化調査研究」WG1の成果発表と考えておけばいいのかな。
内容の中心は、オープンソース活動の標準モデルにおける OSS ハブ機構の実例について。ここでいう標準モデルとは、INSTAC OSS の定義した参照モデルで、平成16年度の報告の「オープンソース・ソフトウェアに関する標準化調査研究」の P.18 の 図5 あたりを指している。このモデル中で開発者とユーザの間に登場するのが「OSS ハブ機構」。一般的なオープンソースプロジェクトにおけるファウンデーションやユーザ会がこれに相当する。
平成16年の活動として、これらモデル定義や一般的な分析を行ったので、17年は実際の OSS ハブ機構に相当する組織についてレポート。前述の報告書におけるファンクション・プレーヤマップ(P.30)をそれぞれの OSS ハブ機構にあてはめて、カバーする領域を示したり、活動の傾向などについて。
詳しい話は、INSTAC のほうにそのうち報告書がでるんじゃないかと期待。
以前に『Producing Open Source Software』(Karl Fogel)を読んだときに、オープンソース活動におけるマネジメントやコミュニティのコントロールという側面に関心を持ったのが、このセッションに参加したきっかけ。
オープンソース活動の参照モデルを定義し、それに基づいてコミュニティの活動領域を分析していくという手法は、やや地味だけれどおもしろい。タイトルからは内容の想像がつかなかったのだけど、先に平成16年の報告書を読んでおけばよかったとちょっと後悔。
紹介されたハブ機構のなかでは、Software Freedom Law Center が特定のソフトウェアに特化していないという意味で珍しいのかな。それぞれのソフトウェアのハブ機構と「契約する」という形で、法的なサポートを提供するというのも、考えてみれば当たり前なのだけど面白かった。また、法人格を持つということが重要という PostgreSQL ユーザ会と、ビジネスを重視する Zope Foundation のアプローチのちがいも、それぞれのソフトウェアの特性なのか、コミュニティの性格的なものなのかは考えてみると面白いかも。
セッション自体については、見せ方とか話し方にそれなりの工夫がほしいとこ。かなり集中してないと、何を言ってるのかすぐにわかんなくなってしまった。けっこう内容的にはおもしろかったと思うんだけどね。
| 固定リンク
明日のOSC2006 Tokyo/Springにふじもとさんも行くことが判明したので、RubyCocoa の現在の開発メンバーのおよそ7割が集まることになります。 (確認してないけど、たぶん Jonathan は来ないでしょう。日本に住んでないと思うし)
ここでもし、明日 RubyCocoa オフを開催するって言ったら参加する人っていますか?もしそんな人がいたら、私あてにメールするか、コメントお願いします。
| 固定リンク
だらだらと作っていたツールがあっけなく動いたので、しばらくkimurawの日記との両輪でいきます。ある程度安定したら、完全にこちらのみになります。
公開しているソフトウェアのリリース案内をこっちにもコピーしました。コメントできるはずです。
| 固定リンク
ふじもとさんからアナウンスがあったように、LGPL から Ruby ライセンス( Ruby 独自と GPL のデュアルライセンス)に変更する予定です。 RubyCocoa の contributor の方はじめ、ユーザの方も意見などあれば ML へお願いします。
| 固定リンク
3/18(土)に参加する予定。 申し込みしたのは、次の3つ。
オフラインで僕に問いつめたいことのある人は、適当につかまえておくれ。
| 固定リンク
最近のコメント