みるくCocoa

OSAtomicFifoQueueを使った非同期スレッド間通信

Tue, 15 May 2012 20:37:32 +0900

OSAtomicFifoQueueを使って、非同期スレッド間通信を行うサンプルコードを作ってみた。

Cocoaでマルチスレッドなプログラムを作るとき、大抵の場合はNSOperationやGCDを使えば済むかもしれません。しかし、ときには手動でスレッドを作って、スレッド間通信をしたくなることもあります。

例えば、複数のスレッドで一つのデータを共有する場合、真っ先に思いつくのはNSLockなどを使ってスレッドセーフにすることです。しかしこの方法は手軽で確実な反面、パフォーマンス面に問題があります。それは、NSLockが基本的にスレッドを「一時停止」させるための機能だからです。そもそも、なぜマルチスレッドにしたのかという理由にもよりますが、せっかくマルチスレッドで動いているのに、スレッドを止めてしまうことはあまり好ましい状況ではありません。

このようなときは、共有したいデータの管理を一つのスレッドに全て任せてしまい、複数のスレッドで一つのスレッドを共有するという方法を取ります。各スレッドからLockを使わずに、その一つのスレッドに対してメッセージを送れれば、データ編集が完了するまでの間、各スレッドは一時停止せずに済みます。

そしてこのとき、Lockせずにメッセージを送るために使うのがOSAtomicFifoQueueです。
以前はCarbonライクなMPQueueというのがありましたが、MacOSX10.7になってOSAtomicFifoQueueに置き替えられました。OSAtomicFifoQueueを使うには、libkern/OSAtomic.hをインポートします。

OSAtomicFifoQueueはLinked-Listなデータ構造を持つキューで、以下のような形になります。

ヘッダーにはキュー全体を統括するOSFifoQueueHeadという構造体が定義されていますが、Itemに相当するデータ構造は定義されていません。
これは、Linked-Listな要素なので、次の要素へのリンクポインタさえ用意すれば、どんな構造体でもOKと言う事で、ユーザー側で自由に定義できるようになっているからです。

キューにItemを出し入れする、OSAtomicFifoDequeue()や OSAtomicFifoEnqueue()と言った関数には、offsetという引数があり、これでユーザー定義された構造体の中でのリンクポインタの位置を指定します。

//
// ユーザー定義のItemクラス
//
@interface Item : NSObject
{
    NSString* title;
    NSURL* url;

    void* link; // リンクポインタ
}
@property(strong) NSString* title;
@property(strong) NSURL* url;
@end

//
// キューの初期化
//
OSFifoQueueHead queue;
queue.opaque1 = NULL;
queue.opaque2 = NULL;
queue.opaque3 = 0;

//
// キューへの挿入
//
Item* item = [Item new];
item.title = @"Hello";
item.url = [NSURL URLWithString:@"http://hello.jp"];

Ivar ivar = class_getInstanceVariable([Item class], "link");
size_t offset = ivar_getOffset(ivar);

OSAtomicFifoEnqueue(&queue, item, offset);

//
// キューから取り出し
//
Item* item = OSAtomicFifoDequeue(&queue, offset);

if (item) {
    NSLog(@"%@ %@", item.title, item.url);
}

キューが空の場合、OSAtomicFifoDequeue()関数はすぐにNULLを返し、決してキューに新たなItemが挿入されるまでスレッドを停止させたりはしません。そのため、Itemの挿入を待ち受けるには、CFRunLoopのカスタムSourceを利用します。

今回のサンプルコードの内容は、「割り算スレッド」です。

MainスレッドからWorkerスレッドへ、「12 / 4」のような文字列を送信すると、「12 / 4 = 3」という文字列が返ってきます。MainスレッドもWorkerスレッドもRunLoopを使用しており、それぞれ非同期で動きます。そのため、タイミングによっては文字列を送信してもすぐに受信できないかもしれません。
ゼロ除算を行おうとすると例外が発生して、Workerスレッドが落ちるようにしています。落ちたWorkerスレッドはMainスレッドによって、すぐに再起動させられます。
Workerスレッドでエラー等が発生したとき、エラーからの回復を試みてもいいですが、一度スレッドを落としてから再起動させるのも一つの方法です。

もう少しでiDiskが終わります

Fri, 04 May 2012 22:08:34 +0900

来月でiDiskがサービス終了となります。
iDiskは、このサイトのバックアップだけでなく、画像ファイルやダウンロードファイルなどの置き場所にもなっていました。

かつては、サーバーの回線速度が1.5Mbpsと遅かったので、負荷分散のため比較的容量の大きなファイルを別サーバー（つまりiDisk）に置いていました。
でも、このたびiDiskがサービス終了ということで、iDiskに置いていたのものリンク先を修正して全て自分のサーバーに移動させました。

サーバーの負荷分散は、当初は良い考えだと思っていましたが、こんなふうにレンタルサーバーのサービスが終了したりすると結構大変なことになりますね。

MIDIWindシーケンサーの開発状況

Sun, 25 Mar 2012 13:55:51 +0900

昨年の４月から開発を続けているMIDIWindシーケンサーの開発状況はこんな感じです。

ある程度編集が可能になっていますが、のんびりと開発してるので、完成度は50%ぐらいでしょうかね。
来年ぐらいには、初期リリースしたいな。

副作用とは？

Sat, 17 Dec 2011 23:34:56 +0900

関数型言語でよく話に出てくる「副作用」。今回は、その副作用についてまとめてみる。

まず、副作用とは「別の世界に与える影響」または「別の世界から受ける影響」のことです。

int function(int a, int b);

例えば、C言語で上記のように定義された関数について、同じ値の引数なら戻り値も必ず同じになるとき、この関数には副作用がありません。おそらく、２つの引数からなんらかの演算によって戻り値を算出する内容のコードになっているのでしょう。

void action(int a, int b);

しかし、上記のように戻り値が無い関数の場合、引数として入力された値はどこへ行ってしまったのでしょうか。この関数は何もしない関数なのでしょうか。もし何か処理を行っているとすれば、その結果はどこに出力されたのでしょうか。
これが、副作用を持つ関数です。この関数の処理結果は「別の世界」へと送られたのです。

「別の世界」をもう少し具体的に言うと、「自分と平行して動作しているもの」となります。

コンピュータでは、CPU、GPU、USBコントローラ、IDEコントローラ、Audioデバイスなどが、全て同時平行的に動作しています。CPU動作中はGPUが停止してて画面が表示されない、などということはありません。
つまり、全てのI/Oデバイスへのアクセスは副作用なのです。

また、１台のコンピュータにCPUが２つあった場合、２つのCPUは平行して動作します。そして、OSのカーネルが提供するマルチプロセスやマルチスレッドなどは、仮想的なCPUを作り出すサービスです。
つまり、プロセス間通信やスレッド間通信も副作用です。

さらに、下記のようなコードを書いた場合、

int a = 3;
int b = 4;
a = a + b + 5;

変数aは、再代入によって内容を書き替えています。これは、メインメモリをデータストレージデバイスのように扱っていることになるため、これもI/Oデバイスへのアクセスと同様に副作用です。ちなみに、変数bは再代入を行っておらず、実質的に定数であると考えられるため、これは副作用にはなりません。

副作用の伴うコードは、可能な限り排除しなければなりません。なぜなら、副作用はバグの発生と大きな関係があるからです。
例えば、I/Oデバイスへの書き込みは失敗するかもしれません。また、I/Oデバイスからはどんな値が読み込まれるか完全に予測することはできません。プログラムを組む際は、これら予想外の事態に配慮しなければなりません。もし、予想外の事態に対処できなければ、これがバグという形になって表れるからです。

この予想外への対応は、副作用を含むコードと共に行われます。そして、「予想外」に対応するコードは、大抵は面倒で書くのに時間の掛かるコードです。副作用があまりにも多いコードだと、この予想外への対応が困難になります。面倒だからといってここでコードを省略すると、それがバグに繋がってしまいます。

関数型言語では副作用を特別扱いするものが多く、副作用への対処がやりやすくなっています。逆に、手続き型言語では、副作用の存在自体が見えにくく対処しづらくなっています。

破損した書類でもエラーにしない

Sun, 13 Nov 2011 02:01:04 +0900

あるアプリケーションで書類を開こうとしてファイルを読み込んだとき、もしそのファイルのデータが破損していた場合どうしたら良いでしょうか？

これまでは、「この書類は破損しています」とアラートパネルを表示し、書類を開く処理は失敗に終わらせる。というのが、ほとんど常識でした。そのファイルは、おそらくアプリケーションのバグなどによって、壊れた状態で最後に保存されてしまったのです。運良くバックアップでもないかぎり、もう諦めるしかありません。

ところが、MacOSX10.7の「バージョン管理」機能によって、この状況は変わります。
「運良く」ではなく、ごく日常的に書類のバックアップを取るような形になるからです。
しかし、Cocoaのデフォルトの実装では、書類を開かないと、その書類の過去バージョンにアクセスできません。バージョン管理は、書類の変更履歴を残すもので、破損したファイルを復旧させることは想定されていないのです。

でも、破損したファイルでもエラーにせず、とりあえず開けるようになっていれば、破損したファイルを救うことも可能になります。MacOSX10.7用のアプリケーションを開発する際は、このような配慮も必要になってくるのかもしれませんね。

iCloud Storageのサンプルコード

Sat, 29 Oct 2011 15:22:04 +0900

iCloud Storageの動作を確認するべく、サンプルコードを作って見ました。

iCloud Storageを利用するには、まずそのアプリケーションを登録しなければなりません。iCloud Storage内には、アプリケーションごとに別々に領域が確保されます。
登録するには、Mac Developer Programの会員になり、メンバーセンターで登録手続きを行う必要があります。
1. アプリケーションIDの登録
2. 開発者としての証明書の登録
3. 開発モードなら、開発機の登録
4. 規定書の作成とダウンロード
ダウンロードした規定書は、システム環境設定のプロファイルとXcodeオーガナイザーのDevicesにインストールします。

Xcodeでプロジェクトを作成したら、規定書に基づいてセットアップします。
1. Summaryで、Identifierに登録したアプリケーションIDを設定
2. Summaryで、Code Sign Applicationにチェック
3. Summaryで、Enable Entitlementsにチェック
4. Summaryで、Entitlements Fileを設定
5. Summaryで、iCloud ContainersにアプリケーションIDを設定
6. Build Settingsで、規定書に対応したCode Signing Identityを設定
これでやっと準備完了です。

iCloud Storageは、iDiskと違ってファイルシステムにマウントされません。そのため、FinderからはiCloud Storageのファイルを基本的に見る事はできません。ただし、iCloud Storage内のファイルはローカルにキャッシュされるようになっており、実際にはこのキャッシュファイルを読み書きすることで、間接的にiCloud Storageのファイルをアクセスします。このキャッシュファイルは、デーモンプロセスによりiCloud Storage内のファイルと同期が取られます。

iCloud Storageにファイルを保存するには、一度ローカルに普通にファイルを書き出したあと、NSFileManagerのsetUbiquitous:itemAtURL:destinationURL:error:メソッドで、iCloud Storage（のキャッシュエリア）にファイルを移動させます。
逆に、ファイルを開くときは、NSMetadataQueryのスコープにNSMetadataQueryUbiquitousDocumentsScopeなどの値を設定して、ファイル検索を行いURLを取得します。
iCloud Storage内には自由にフォルダ（ディレクトリ）を作ることができますが、Documentsフォルダ配下に置いたファイルだけは、システム環境設定のiCloudのストレージ管理で見る事ができます。

iCloud Storageのファイルを取り扱う上で最も大変なのが、ファイルの競合解決です。これに関連して、ファイルは必ずバージョン管理しなくてはなりません。そのために、NSFilePresenterの実装と、NSFileCoordinatorやNSFileVersionの使用は不可欠です。NSDocumentには、これらのものが既に実装されていますが、今回のサンプルコードではNSDocumentを使わずに手動で実装してみました。
なお、iCloud Storageに保存されるのは、現在のバージョンのみなので、歴代のバージョンはそれぞれのデバイスのローカルに保存されるだけで同期されません。

ちなみに、一般的に「クラウドコンピューティング」というものには、インターネット全体を１台の巨大なコンピュータにするという概念があります。インターネット経由でiCloud Storageに接続された各デバイスも、この巨大なコンピュータの一部です。
そのため、実はファイルの同期どころか、ファイルの共有すらしていないことになります。１台のコンピュータが１つのファイルをアクセスしてるだけなので。当然、ファイルの競合など起こるはずがありません。
そういった背景からか、iCloud Storageのドキュメントでは、ファイルの競合は可能な限り静かに解決することが推奨されています。ユーザーに競合の解決を求めるのは最後の手段です。NSDocumentには、この最後の手段が実装されています。

MIDIWindシーケンサの開発状況

Sun, 09 Oct 2011 15:43:59 +0900

今年の４月から開発を開始したMIDIWindシーケンサの今の状況はこんな感じです。

まだまだ未完成ですが、それっぽい形が出来上がってきたところです。
MIDIファイルの中身が表示されて、再生もできますが、編集機能はまだありません。

オーバーレイなScrollerは、少し手間

Thu, 01 Sep 2011 19:55:41 +0900

オーバーレイ・スクローラーは、MacOSX10.7で大きく変化したユーザーインターフェースの一つです。
今までNSScrollViewのdocumentViewに隣接して配置されていたNSScrollerが、documentViewの上に半透明で重ね置きされるようになりました。
このNSScrollerは、複合ビューであるNSScrollViewに含まれており、特別な苦労もなく簡単に利用することができます。しかし、特殊なスクロール環境を作るために単体でNSScrollerを使おうとすると、単純にNSScrollerをView上に配置するだけで済んでいた以前と比べて、数倍もの手間が掛かことが分かりました。

まず、スクローラーのスタイルとして「オーバーレイ」と「レガシー」が選択できるようになっています。そして、この２つのスタイルを任意のタイミングで切り替えられるようにしなければなりません。

Lionのスクローラーは必ず「オーバーレイ」スタイルになるわけではなく、入力デバイスによってスタイルが変化します。また、システム環境設定によって手動で切り替えることもできます。その際は、アプリケーションの実行中であっても、リアルタイムに設定が反映されなければなりません。例えば、MagicMouseを使っていて突然電池が切れ、普通のUSBマウスに切り替えたとき、スクローラーが隠れたままだとスクロール不能になってしまいます。

この設定変更通知を受け取るために、NSPreferredScrollerStyleDidChangeNotificationが用意されました。現在のスタイル情報は[NSScroller preferredScrollerStyle]で取得できます。

@implementation MyScrollView

@synthesize documentView, scroller;

- (id)initWithFrame:(NSRect)frame
{
  ...
  [[NSNotificationCenter defaultCenter]
    addObserver:self selector:@selector(styleChange:) 
    name:NSPreferredScrollerStyleDidChangeNotification object:nil];
  ...
}

- (void)styleChange:(NSNotification*)notify
{
  NSScrollerStyle style = [NSScroller preferredScrollerStyle];
  scroller.scrollerStyle = style;
  scroller.frame = scrollerRectForStyle(style);
  documentView.frame = documentRectForStyle(style);
  [self setNeedsDisplay:YES];
}

スタイルの変更は、スクローラーのプロパティ変更だけにとどまらず、ビューの配置変更を伴います。

このようなスタイル変更だけならまだ楽だったのですが、少し大変なのが「スクローラーを隠す」処理です。
オーバーレイなスクローラーはドキュメントの一部を覆い隠しており、そのためにドキュメントの一部は画面に表示されていても見えず、しかもマウスクリックにも反応しなくなっているのです。オーバーレイなスクローラーは、必要の無い時は隠れていなくてはならないのです。
しかし、スクローラーを隠す処理は自動的には行われません。手動で実装する必要があります。最も簡単な実装方法は-[NSView setHidden:]を使う事です。でも、もう少し本格的に実装しようとしたとき問題となるのが、スクローラーの「ノブ」と「スロット」を独立して透過処理する方法です。
オーバーレイなスクローラーは、常時隠れていて、ビューがスクロールするときのみ「ノブ」が表示され、そこでさらにマウスをスクローラーにフォーカスさせると「スロット」が表示される仕組みです。しかし、以前よりスクローラーのノブとスロットは一体もので、ノブのみを表示させるようなAPIはMacOSX10.7のリファレンスにも載っていません。

このノブとスロットの独立透過処理をプライベートな領域に片足を入れて実装すると以下のようになります。

- (void)hideSlot
{
  [NSAnimationContext beginGrouping];
  NSAnimationContext* animeContext = [NSAnimationContext currentContext];
  [animeContext setDuration:0.25];
  id animeProxy = [scroller animator];
  NSNumber* alphaValue = [NSNumber numberWithDouble:0.0];
  [animeProxy setValue:alphaValue forKey:@"overlayScrollerTrackAlpha"];
  [NSAnimationContext endGrouping];
}

これを実行すると、スクローラーのスロットのみが0.25秒かけてなめらかに透明になっていきます。"overlayScrollerTrackAlpha"の代わりに"overlayScrollerKnobAlpha"というキーを使うと、ノブとスロットを合わせた透明度をアニメーション付きで制御できます。
上記のコードは一応プライベートなAPIを一切使用していませんが、"overlayScrollerTrackAlpha"などのキーの使用を許容するかどうかで議論が分かれるかもしれません。

プライベートな領域に一切触れずに実装するなら、以下のようにNSScrollerのサブクラスを作って、drawRect:をオーバーライドしなければなりません。

@interface MyScroller : NSScroller
@property(readwrite) CGFloat knobAlphaValue;
@property(readwrite) CGFloat trackAlphaValue;
@end

@implementation MyScroller
@synthesize knobAlphaValue, trackAlphaValue;

+ (BOOL)isCompatibleWithOverlayScrollers
{
  return self == [MyScroller class];
}

- (void)drawRect:(NSRect)dirtyRect
{
  [[NSColor clearColor] set];
  NSRectFill(NSInsetRect([self bounds], -1.0, -1.0));
  CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort];
  CGContextSaveGState(context);
  CGContextSetAlpha(context, trackAlphaValue);
  NSRect knobSlotRect = [self rectForPart:NSScrollerKnobSlot];
  [self drawKnobSlotInRect:knobSlotRect highlight:NO];
  CGContextSetAlpha(context, knobAlphaValue);
  [self drawKnob];
  CGContextRestoreGState(context);
}

@end

上記のコードでは、knobAlphaValueとtrackAlphaValueの２つのプロパティによって、ノブとスロットの透明度を独立して設定できるようになっています。あとは、NSAnimationを使って透明度を制御すれば、先ほどと同じようなものが実現します。
なお、NSScrollerをオーバーレイ対応でサブクラス化する場合は、上記のような形でisCompatibleWithOverlayScrollersを実装する必要があります。ここでYESを返さないと、オーバーレイは無効です。

IPv6がやってきた！

Sat, 20 Aug 2011 22:26:12 +0900

６月から各プロバイダ一斉にIPv6のネイティブ接続サービスがスタートしました。うちのOCNもPPPoEのIPv6接続を無料のオブションサービスという形で提供を開始したので、早速申し込みしました。

それで、OCN側の工事は６月下旬には終わっていたのですが、YAMAHAのルーター(RTX1200)の対応が遅れて、やっとIPv6のPPPoE接続に対応したのが７月下旬。そこから、ルーターの設定で、いろいろ苦労があって、実際の使用開始は８月上旬となってしまいました。
まあ、別に急いでいたわけじゃないから、どんなに遅れてもいいんだけどね。

ちなみに、OCNの申込書には「別途、NTTのIPv6トンネル対応アタブタが必要です。」と書かれていましたが、YAMAHAのRTX1200があれば不要です。一応買ってしまいましたが。

それから、参考までにルーターのコンフィグはこんな感じです。

# RTX1200 Rev.10.01.32 (Wed Jul 13 17:42:17 2011)
ipv6 route default gateway pp 1
ipv6 prefix 1 2400:xxxx:xxxx:11::/64
ipv6 prefix 2 2400:xxxx:xxxx:22::/64
ipv6 vlan1 prefix 2400:xxxx:xxxx:11::/64
ipv6 vlan1 rtadv send 1 o_flag=on
ipv6 vlan2 prefix 2400:xxxx:xxxx:22::/64
ipv6 vlan2 rtadv send 2 o_flag=on
pp select 1
 pppoe use lan3
 pp auth accept pap chap
 pp auth myname xxxx xxxx
 ppp ccp type none
 ppp ipv6cp use on
 ipv6 pp secure filter in 1 2 3 4 5
 ipv6 pp dhcp service client
 pp enable 1
ipv6 filter 3 pass * * * * 546-547

設定のポイントは、

「ipv6 route default gateway pp 1」で、ppをゲートウエイにする。
「ppp ipv6cp use on」で、ipv6cpを有効にする。
「ipv6 pp dhcp service client」で、DHCPv6を有効にする。

といったところです。
今回は、プロバイダから/56のアドレスを固定で割当てもらっているので、LAN側のアドレスは手動で設定しています。アドレスの割当が/64の場合は、DHCPv6で受信したアドレスをそのままLAN側に割り当ててください。
ちなみに、NTTのIPv6トンネル対応アダブタだと、/64のアドレスしか対応していないようなので、今回は本当に使い物になりませんでした。

IPv4のPPPoE接続のときは、unnumbered接続だったので、ただ単純にppをゲートウエイにするだけでよかったのですが、IPv6のPPPoE接続の場合は、ppでDHCPv6を稼働させてアドレスを受信しないと正常に繋がらないようです。ppにフィルターを設定する場合はDHCPv6のパケットが通るようにポート546-547に穴を開けてください。
今回は、このDHCPv6の設定に気づかず苦労したというのもありますが、設定に気づいてDHCPv6のコンフィグを投入したのに、なぜかDHCPv6が正常に稼働しなかったため、泥沼にはまってしまいました。
ルーターの電源をOFF/ONしてもダメで、最終的にはcoldstartでルーターを初期化してからコンフィグを入れ直して、やっと正常に稼働するようになりました。

サーバーの方は、HTTPとDNSだけIPv6で見えるようにしているつもりですが、未確認です。なにぶん、IPv6の回線が１本しかないので、外部からの接続試験ができません。

Lionの新機能を使ったサンプルコード

Thu, 04 Aug 2011 22:51:56 +0900

非同期保存などのMacOSX10.7の新機能が気になったので、サンプルコードを作って見ました。

まず、一番簡単なのはフルスクリーンモード。単純にNSWindowのプロパティでFull ScreenをPrimary Windowに設定するだけで、ウインドウの右上にフルスクリーンボタンが付きます。

つぎに、Auto Layout。当初、XcodeではGUIでの編集がサポートされていないと思っていましたが、実はサポートされていました。しかし、分かりづらい。
.xibファイルのプロパティで、「Use Auto Layout」にチェックを入れると、レイアウトの編集が通常モードからAuto Layoutモードへと切り替わります。

Editorメニュー配下にPinメニューがが追加されて、これでNSLayoutConstraintオブジェクトが追加できるようになります。

Auto LayoutではPriorityという、そのレイアウトをどの程度強制するのかを示すプロパティの使い方がポイントのようです。例えば、自由にリサイズするビュー内部をレイアウトするとき、すべてをPriority=1000にしてしまうと、ビューのサイズが縮小し過ぎたときにレイアウトを維持できなくなる可能性があるため、実行時に警告が出たりします。

そして、自動保存とバージョン管理については、プロジェクトのテンプレートにあるように +autosavesInPlaceでYESを返すようにするだけで有効になります。

@implementation MyDocument

+ (BOOL)autosavesInPlace
{
    return YES;
}

- (IBAction)editModelObject:(id)sender
{
    [modelObject edit];
    [self updateChangeCount:NSChangeDone];
}

- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
    return [NSArchiver archivedDataWithRootObject:modelObject];
}

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName 
    error:(NSError **)outError
{
    [self willChangeValueForKey:@"modelObject"];
    modelObject = [NSUnarchiver unarchiveObjectWithData:data];
    [self didChangeValueForKey:@"modelObject"];
    return YES;
}

updateChangeCount:の呼び出しにより書類の編集が検知されると、一定時間操作が無いときにRunLoopから書類の保存が起動されます。また、「保存」メニューが「バージョンを保存」に変わります。
readFromData:ofType:error:は、通常書類を開く時に呼ばれますが、書類を古いバージョンに戻す時にも呼ばれます。古いバージョンに戻すときは、開くときと違い、NSDocumentオブジェクトが新規に生成されないので、ここでdidChangeValueForKey:などを呼んでおかないと、表示が更新されません。

で、ここからが本題の非同期保存ですが、まず非同期保存を有効にするには上記のコードに加えて、canAsynchronouslyWriteToURL:ofType:forSaveOperation:でYESを返し、保存処理の中でunblockUserInteractionを呼び出す必要があります。

@implementation MyDocument

- (BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName 
    forSaveOperation:(NSSaveOperationType)saveOperation
{
    return YES;
}

- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
    [self unblockUserInteraction];
    return [NSArchiver archivedDataWithRootObject:currentObject];
}

- (IBAction)editModelObject:(id)sender
{
    self.currentObject = [currentObject edit];
    [[self undoManager] setActionName:@"Edit"];
}

- (void)setCurrentObject:(Model*)object
{
    [[self undoManager] registerUndoWithTarget:self 
        selector:@selector(setCurrentObject:) object:currentObject];
    currentObject = object;
}

canAsynchronouslyWriteToURL:ofType:forSaveOperation:でYESを返すことによって、dataOfType:error:がメインスレッドとは別のスレッドで呼ばれるようになります。ただし、このときメインスレッドは、このスレッドにjoinするような形でブロックされているため、この時点ではまだ非同期ではありません。unblockUserInteractionを呼ぶことで、メインスレッドのブロックが解除されて、ここから非同期保存が始まります。

このように、非同期にするだけなら簡単なのですが、問題は「非同期保存中に、メインスレッドで書類が編集されたらどうするか？」です。これに対する基本戦略は、「非同期になる前に、書類のスナップショットを取る」です。unblockUserInteractionが呼ばれるまで非同期にならないのは、スナップショットを取る最後のチャンスを与えるためです。
しかし、スナップショットとは、ようするに書類全体のコピーを作る処理のことです。ここであまり処理に時間を掛けると、非同期のメリットが失われてしまいます。

今回はこれらの問題に対し、イミュータブルな戦略を試してみました。つまり、NSArrayにオブジェクトを追加する際に、-[NSMutableArray addObject:]を使わず、代わりに-[NSArray arrayByAddingObject:]を使うということです。書類を編集する全てのメソッドで、新規に生成された編集後の書類オブジェクトを返すようにしています。

@interface Model

- (Model*)addNewPerson;
- (Model*)removeAtIndex:(NSUInteger)index;
- (Model*)setNameValue:(NSString*)name atIndex:(NSUInteger)index;
- (Model*)setAgeValue:(NSInteger)age atIndex:(NSUInteger)index;
- (Model*)setCommentValue:(NSString*)comment atIndex:(NSUInteger)index;

この方法だと、実質的に常時スナップショットを取っている形になるので、保存処理でいきなり非同期にしても問題ありません。これは、平行処理に強いと言われている関数型言語で標準的に行われている方法です。

さらに、このイミュータブルな戦略を使った際の二次的な効果として、Undo処理が簡素で信頼性の高いものになるというのがあります。
CocoaのUndoは、基本的には「書類の操作履歴」です。ある操作をしたとき、それとは逆の操作をすれば元に戻るという話です。しかし、この方法には少し問題もあります。まず、Undoのために必ず対となる操作を作らなければならないこと、それから、操作を操作で打ち消す場合、書類が確実に元の状態に戻る保証がないことです。例えば、「値を３で割る」という操作を「値を３倍する」という操作で打ち消そうとしても、端数処理の関係で元の値に戻らないかもしれません。
今回のUndoは「書類の状態履歴」という形で実装しています。書類を操作したときに捨てられるはずの古いスナップショットを、Undoとして登録するだけの簡単な実装です。これだと、Undoのために対になる操作を作る必要もないし、Undoすれば確実に元の状態に戻ります。

最後に、今回スナップショットにイミュータブルな戦略を採用した結果、バインドが使いにくくなることが分かりました。そもそもCocoaではミュータブルな戦略が採用されているので、イミュータブルな戦略とはやや相性が悪いのです。しかし、「非同期」や「平行処理」をキーワードにプログラムを書くなら、イミュータブルな戦略を採用した方が有利に展開するのは、今回のサンプルコードからも明らかです。
Cocoaは最初にリリースされてからもう10年以上立ちました。そろそろ時代遅れなものになりつつあるのかもしれませんね。

MIDIWind2.1.1をリリース

Wed, 27 Jul 2011 20:23:58 +0900

MIDIWind2.1.1をリリースしました。
単純にMacOSX10.7に対応させただけで、特に追加機能はありません。また、このバージョンから動作環境が10.6以降となりました。

10.7で動作上問題となったのが内蔵のソフトシンセで、Deprecatedな古いAPIを使用するとアプリごとクラッシュしてしまいます。また、なぜかコントロールチェンジ#93（コーラスエフェクト）を送るとフリーズします。

今回のアップグレードで、Deprecatedな古いAPIを10.6の新しいAPIに書き替え、余計なコントロールチェンジを送信しないようにフィルターを施しています。

LionそしてMIDIWindがまた動かなく...

Sat, 23 Jul 2011 02:19:42 +0900

OSをMacOSX10.7(Lion)にアップグレードしました。
そして、またしてもMIDIWind2.1の一部の機能が動かなくなりました。

ソフトシンセで再生しようとすると、アプリケーションが予期せず落ちてしまいます。
幸い外部音源の再生は問題なくできるようです。

MIDIWind2.1はMacOSX10.4がターゲットで、ソフトシンセ周りでDeprecatedなAPIを使っていて、このAPIがLionで使用不能にならないことを祈っていたのですが、残念ながらその祈りはAppleには届かなかったようです。
これから、10.7対応に修正する予定です。

MacOSX10.7でも新しいAPIがいろいろ追加されていますが、ジェスチャー・フルスクリーン・自動保存＆バージョンなんかが大きなところかな。まだ詳しく見ていないが、自動保存に伴う「非同期保存」の実装が少し気になるところだ。保存中にデータを書き換えたらどうなるんだろうか？　あと、CoreDataの自動保存ってどうなるんだろ？　自動保存関連の機能追加が無いように見える。
その他にも、TableViewでCellの代わりにViewが使えるようになった。今まではMatrixを使った実装だったので同じcellを並べることしかできませんでしたが、Viewだと行ごとに違うものを使ったりとか出来るっぽい。単純にデータをリスト表示するのとは違うものが作れそうだ。
それから、新しいViewのレイアウト機能が追加された。でも、Xcodeが対応していないっぽく、コードを書いてレイアウトしなきゃならないっぽい。なんか不便だ。

Viewを如何にテストするか？

Mon, 30 May 2011 19:11:37 +0900

テストにはテスト内容に応じていろいろな種類や方法がありますが、オブジェクト単位のシンプルな機能テストと言えばxUnitなどを使うユニットテストがあります。オブジェクトに何かを入力したときの出力を検査することで、オブジェクトの機能をテストするというものです。

MVCパターンに基づいてコードを書いている場合、Modelが最もテストし易いコンポーネントになります。Modelは他のコンポーネントに依存しない形になっているので、テストプログラムに組み込むことも簡単なのです。
逆に、ViewやControllerはテストしにくいコンポーネントです。まあ、ViewやControllerに限らず、I/O処理を含むコードのテストはModelであっても困難です。ただModelであればまだ手段がありますが、特にViewに関してはグラフィックの描画という部分がOSに結び付いているため、この部分のテストを行うのは非常に困難です。

でも、だからといってViewをテストしないわけにも行きません。
まず最初に考えたのは、グラフィックの描画そのものをテストすることはできないが、描画に使用するパラメータならテストできるのではないか、という事です。例えば、NSRectFill()で塗りつぶす時に矩形の座標情報がパラメータとして必要になります。塗りつぶした結果はテストできないかもしれませんが、矩形の座標情報ならテスト可能ですし、それをテストすれば塗りつぶした結果を間接的にテストしたことになるのでしょう。
しかしこの方法はうまく行きませんでした。なぜなら、Modelの場合は「テストに合格するコードが良いコード」だったのに対し、Viewの場合は「見栄えの良いグラフィックを描画するコードが良いコード」だからです。グラフィックは実際に画面に表示させて見ないと評価できません。座標情報を前もって決めておくことは困難なのです。

このように、グラフィックの描画がViewの主要機能であるにもかかわらず、それをテストすることが現実的ではないとすると、そもそもViewの何をテストすればいいのでしょうか。いろいろ考えた結果、おそらく以下のようなものがテストの対象になるのでしょう。

・ViewがModelオブジェクトにアクセスできるか？
・ViewがModelオブジェクトからの通知を受け取れるか？
・ViewがNSEventを受け取りTarget/Actionを発行できるか？

しかし、これはこれで難しいデストです。通常ユニットデストでは、あるものを入力したときの出力をテストしますが、上記のような場合は出力されるものがありません。そこで、これをテストするために、以下のような方法を考えました。

@interface TestView : MyView {
  NSMutableArray* log;
}
@property(retain) NSMutableArray* log;

@end

@implementation TestView

@synthesize log;

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
  change:(NSDictionary *)change context:(void *)context {
  [log addObject:@"observeValueForKeyPath"];
  [super observeValueForKeyPath:keyPath ofObject:object
    change:change context:context];
}

- (void)setNeedsDisplay:(BOOL)flag {
  [log addObject:@"setNeedsDisplay"];
}

@end

@implementation MyTestCase

- (void)testKeyValueObserv {
  MyModel* model = [[MyModel alloc] init];
  TestView* view = [[TestView alloc] initWithFrame:NSZeroRect];
  [view bind:@"content" toObject:model withKeyPath:@"self" options:nil];
  view.log = [[NSMutableArray alloc] init];
  [model setValue:@"hoge" forKey:@"boke"];
  STAssertEqualObjects(
    [view.log objectAtIndex:0], @"observeValueForKeyPath", nil);
  STAssertEqualObjects(
    [view.log objectAtIndex:1], @"setNeedsDisplay", nil);
}

@end

これは、テスト対象のViewオブジェクトに、メソッド呼び出しのログを取る機能を追加して、ユニットテストを行うという方法です。このテストにより、Modelオブジェクトのプロパティが変化したときに、Viewがその通知を受け取って再描画しようとしている動きをテストできます。

メソッドの呼び出しがログという形で出力されるので、通常のユニットテストでもテスト可能になります。また、上記の例ではsetNeedsDisplay:の呼び出しでsuperを呼んでいないので、実際にグラフィックの描画というI/O処理が発生しません。

これにより、Viewのテストができる見通しがたったものの、メソッドのログを取るためにいちいちサブクラスを書くのはちょっと面倒。でも、このようなことは、アスペクト指向を使えば簡単なのですが、残念ならがObjective-Cにはアスペクト指向の実装がありません。昔は、あったらしいですけどね、なんとなく復活してくれるとうれしいです。

MIDIWindシーケンサの開発開始

Sat, 23 Apr 2011 19:57:59 +0900

予定どおり現在MIDIWindシーケンサを開発中です。MIDIWindシーケンサは、ようするにSMFファイルの編集ソフトです。ピアノロールやイベントリスト、リアルタイム入力なんかを予定。

Xcode4になってUnitTestが使いやすくなったので、今回の開発ではテストファーストを実践しています。テストファーストとは、先にテストコードを書いてから、そのテストに合格するように本体コードを書く開発スタイルのことです。今のところ、少々ぎこちないながらもなんとか形になっている状況です。噂どおり、テストを全てクリアするのを見るのは、なんだか楽しいですね。

それから、プロジェクトの管理にRedmineを使い始めました。RedmineはRubyで作られたWebアプリケーションで、うちではApache2 + mod_passenger + MySQL5の組み合わせで運用しています。Redmineでは「チケット」を使ってプロジェクトを管理します。リポジトリのリビジョンをチケットに関連付けることもできます。
そして、このMIDIWindのプロジェクトは公開することにしました。リポジトリも公開するので、コミットしたソースコードをリアルタイムに見る事ができます。

MIDIWindプレイヤーの方は、MacAppStoreに出して見ました。無料なので、開発者側に金銭的なメリットは無いですが、ユーザー側にAppStoreのソフトが充実することへのニーズがあるなら、それに答えてもいいかなと思いました。それに、AppStoreに並ぶソフトが有料ソフトばかりというのも、ちょっと寂しいですしね。

CocoaにおけるMVCパターンの実装

Tue, 05 Apr 2011 20:57:24 +0900

Cocoaの記事を書きました。今回は、MVCにおけるコントローラの実装ということで、MVCパターンの話です。
アプリケーションの規模が大きくなると、全体構成をどうするかとか、どこに何を書くのかをある程度整理しておかないと、あっという間にスパゲティーが出来上がります。CocoaはMVCパターンをベースにしたフレームワークなので、とりあえずMVCパターンに従って実装すれば、それほど悪い状態にはならないはずです。
ただ、実際にはModelの内部構成なんかについても整理しないと、十分とは言えないかもしれませんが、そこまで話を広げて整理しようとするとかなり大変な事になるので、今回はControllerに的を絞って整理しました。MVCで比較的厄介なのがControllerであると思われるので、ここを重点的に整理すれば、あとはまあ何とかなるでしょう。

Xcode4でNSLogを過去にする

Sat, 19 Mar 2011 18:19:55 +0900

Xcode4がリリースされました。久しぶりの大幅なアップグレードです。InterfaceBuilderと統合されて、ユーザーインターフェースもガラッと変わっています。強化された機能もいろいろありますが、今回はその中でブレークポイントを紹介します。

今までデバックする際に、あるメソッドは確実に呼ばれているか？　ある時点での変数の値はどうか？
ということを確認するのに、ブレークポイントを設定する方法もありましたが、それだとプログラムの実行がいちいち止まってしまい、デバックの効率が非常に悪くなることがありました。ループ処理の内部に興味がある場合は特にそうです。
そのため、ブレークポイントを設定する代わりにNSLog()をプログラムに挿入して実行し、デバッグが終わったらNSLog()を削除する。などということを行って来ました。

しかし、Xcode4からは一時的なデバックのためにNSLogを使う必要はもうありません。ブレークポイント・アクションの機能が（少しだけ）強化されたからです。

まず、ソースコードの左側をクリックして、ブレークポイントを設定します。

次に、ブレークポイントを右クリック（Control+クリック）して、メニューを開き、「Edit Breakpoint」を選択します。

すると、情報パネルらしきものが開かれるので、そこで「Click to add an action」をクリックしてアクションを追加します。

ここで、Actionに「Log Message」を選択。テキストフィールドに出力するメッセージ”MyView %B (%H) @(NSPoint)[theEvent locationInWindow]@”を入力します。そして、忘れずにOptionsの「Automatically continue after evaluating actions」にチェックを入れます。（これが追加機能です）

最後に「Done」をクリックすれば完了です。

出力するメッセージの文字列では、「%B」がブレークポイントの名前、「%H」がブレークポイントを通過した回数に置き換えられます。また「@...@」で式を書くことができますが、ここにはObjective-Cのメソッド呼び出しを書く事もできます。「(NSPoint)」などと戻り値をキャストすれば、構造体も出力可能です。

今回はNSViewのmouseDown:にブレークポイントを設定した訳ですが、これでプログラムを実行すると、Viewをクリックするたびにコンソールにログが出力されます。

メニューでProduct＞Window Behavior＞Xcode In Frontを選択しておくと、デバック時のみXcodeがコンソールのみ小さなウインドウに縮小され、常に手前に表示されるようになります。

MIDIWind version2.1をリリース

Sun, 20 Feb 2011 16:53:30 +0900

MIDIWind Player Edition v2.1をリリースしました。

今回のバージョンでMacOSX10.6に対応するようになり、これでJavaのコードが全て削除されました。また、ユーザーインターフェースも大幅に修正しました。

MIDIWindを作るのは、これで3回目です。バージョン1.0のリリースが2004年なので、7年も開発を続けたことになります。こんなに何度も作る予定ではなかったのですけどね。
思えば、Cocoa-Javaを使ったのがそもそもの始まりでした。当初、JavaはMaxOSXのコアなコンポーネントと位置づけられていたので、まさかOSから削除されるとは思ってもいませんでした。

以前にも書いたことがあると思いますが、MIDIWindはもともとMIDIプレイヤではなく、MIDIシーケンサを作るためのプロジェクトです。MIDIプレイヤは、MIDIデバイスへのアクセスをテストするために、シーケンサに先行して作成したに過ぎません。
そういう訳で、今度こそMIDIWind Player Editionの開発は、バグが出ないかぎり終了にする予定です。4月ぐらいから、シーケンサとしてのMIDIWindの開発が始まるはずです。

MIDI.mdimporterの罠

Thu, 20 Jan 2011 23:50:18 +0900

MacOSX10.6対応版のMIDIWindは、順調に開発が進んでいます。機能的な部分はほぼ全ての実装が終わり、今はビューの表示関係を修正して見栄えを良くしているところです。

で、検索機能を実装していた中でまた妙な問題に出くわしました。それが、MIDI.mdimporterです。

かつて、MIDIWind2.0の開発中にMIDIファイルから情報を収集するMDインポータがないという話になり、けっきょく自前でMDインポータを作った経緯があります。その時は、MDインポータを動かすためのUTIがMIDIファイルに定義されていなかったため、独自にUTIを定義してMDインポータを実装しました。

そして現在、MacOSXにはMIDIファイルのために、public.midi-audioというUTIが定義され、それ用のMIDI.mdimporterが/System/Library/Spotlight内に用意されました。めでたしめでたし、という感じなのだが実際にはそううまくは行かなかった。どうも、MIDIファイルの検索がうまく行かない。

調べて見ると、どうもこのMIDI.mdimporterは、MIDIファイルからほとんど情報を収集しないらしい。なんとも役立たずなMDインポータだ。それで、自前のMDインポータを使おうということになったのだが、これがなぜか機能しない。
調べて見ると、同一のUTIに対するMDインポータが複数ある場合、実際に動くのは１つだけで、優先順位は

~/Library/Spotlight
/Library/Spotlight
/System/Library/Spotlight
MyApp.app/Contents/Library/Spotlight

こんな感じだ。
MIDI.mdimporter、邪魔である。

もちろん、自前のMDインポータを~/Library/Spotlightにインストールすればいいのだが、逆にOS標準のMDインポータをあっさり殺してしまっていいのかという懸念もある。
で、最終的にはMDインポータに関しては、あまり深くサポートしないことにした。自前で作ったMDインポータも配布はするが、インストールするかどうかはユーザーにまかせることにした。もっとも良い結末は、アップルがMIDI.mdimporterをアップグレードすることだ。もし、自前でMDインポータの開発を続けても、OS標準のMDインポータが強化されたら、努力が無駄になってしまうからね。

Quartzによるグラフィックの描画

Sat, 25 Dec 2010 13:21:29 +0900

久々にCocoaの記事を書きました。過去の記録を見ると、なんだか記事の更新が１年１回ペースになってますね（汗）

で、今回の記事はQuartzによるグラフィックの描画ということで、CocoaでNSViewの中にいろいろなグラフィックを描く事について書いています。
この記事は約８年前にCocoa-Java向けに書いた記事のアップグレード見たいなもので、今回はグラフィックの描画だけにとどまらず、グラフィックの描画速度、描画パフォーマンスについて、CFAbsoluteTimeGetCurrent()を使っていろいろ測定してみました。興味深い結果が出ています。
また、最後にMacOSX10.6の新機能であるCPUのマルチコアを活かした、平行処理描画についてもやってみました。こちらは、Grand Central Dispatchの性能の良さが表れる結果が出ています。

と、まあ今回の記事は後半が描画パフォーマンスの実験レポートのようになっています。
実は私は工業高校の出身なんですが、かつては実験をしてはレポートを纏める毎日だったなぁ〜と、つい昔のことを思い出してしまいました。

MIDIWind2.1betaを公開

Mon, 22 Nov 2010 17:52:24 +0900

まったりと開発を進めていたMIDIWind2.1がある程度形になってきたので、ベータ版として公開することにしました。

今回のバージョンでMacOSX10.6に対応するようになり、これでJavaのコードが全て削除されました。また、ユーザーインターフェースも大幅に修正しました。
ただ、見ての通りまだまだ未実装な部分が多いので、完成までにはもう少しかかりそうです。