MOSA Developer News［MOSADeN＝モサ伝］第206号
2006-05-30
目次
- 「「Wonderful Server Life」 第4回 田畑 英和
- 小池邦人の「Carbon API 徒然草」
- SqueakではじめるSmalltalk入門 第62回 鷲見 正人
- ニュース・解説 木下 誠
「Wonderful Server Life」 第4回 田畑 英和
前回に引き続きMac OS X Serverのインストールについて解説いたします。今回はMac OS X Serverをリモートでインストールする方法について解説いたします。
まずはどのようなときにリモートでのインストールが有効かですが、もっとも典型的な例はビデオカードを搭載していない（オプションで追加することは可能）Xserveをインストールするときです。ビデオカードがなければモニタを接続することができず、モニタを接続できなければ画面上でインストーラの操作をおこなうことができません。
また、インストール対象のマシンが、マシンには優しくても人間には優しくない、とても寒くて騒音爆裂のサーバルームに設置してある場合もあるでしょう。こういったときにリモートでのインストールができれば、マシンにモニタを接続することなく、かつマシンのそばにいなくても作業ができてしまいます。
□インストールディスクからの起動
インストール作業をリモートから実行するには、まずインストール対象のマシンをインストールディスクから起動する必要があります。Xserveのクラスタノードモデルのように光学式ドライブが搭載されていないマシンがあったり、やり方によってはインストールディスクからマシンを起動せずに、インストールすることもできるのですが、こちらについてはまたの機会にご紹介することにしましょう。
インストールディスクからマシンを起動する方法ですが、スロットローディング方式のドライブを搭載したマシンの場合は、キーボードのCキーを押しながらマシンを起動し、起動時にディスクをドライブに挿入することで、インストールディスクから起動できます。ですのでこの方法ですと、キーボードの接続は必要になりますがモニタを接続する必要はありません。
トレイ式のドライブの場合ですけれども、すでになんらかのシステムがインストール済みでかつモニタが接続されていれば、既存のシステムから起動してインストールディスクを挿入し、そこからあらためてインストールディスクから起動すればよいでしょう。モニタを接続していない場合でも、マウスが接続されていれば、マシンの起動時にマウスを押しっぱなしにすることにより、自動的にトレイが開きます。これでインストールディスクを挿入して、インストールディスクから起動することができます。
以上の方法でほとんどのマシンに対応できますが、Xserve(*1)の場合にはマウスやキーボードを接続する必要もありません。詳しい操作方法はXserve G5の「ユーザガイド(p.63)」に説明がありますが、Xserve G5の前面パネルにあるシステムIDボタンを操作することで、モニタ、マウス、キーボードを接続することなく、Xserve G5をインストールディスクから起動することができます。
前面パネルでの操作では、インストールディスクからの起動以外にも、ターゲットディスクモードでの起動や、NetBootによる起動や、NVRAMのリセットを実行することができます。
・Xserve G5ユーザガイド
http://images.apple.com/jp/server/documentation/pdfs/Xserve_G5_User_Guide.pdf
□サーバ管理ツール
インストールディスクからの起動ができれば、それ以上インストール対象のマシンを直接操作する必要はありません。この後の作業はネットワーク上の他のMacからリモートで実行できます。
ただし、リモートでのインストールを実行するにはMac OS X Server用のサーバ管理ツールが必要になります。サーバ管理ツールは前回の記事でご紹介したとおり下記のURLからダウンロードできます。
・管理ツールダウンロードURL
http://www.apple.com/jp/ftp-info/reference/serveradmintools104.html
このサーバ管理ツールをMac OS Xにインストールし、「アプリケーション/サーバ/サーバアシスタント」を使ってリモートでインストールを実行することができます。ちなみにこのv10.4用のサーバ管理ツールはこれまでに2回のアップデートが行われています。
1回目は10.4.4がリリースされたときにアップデートが行われており、このアップデートについてはすでにサーバ管理ツールをインストールしてある環境ではソフトウェア・アップデートでアップデートすることができます。
2回目は10.4.6でのアップデートが行われています。ただし、こちらはソフトウェア・アップデートではアップデートできないようです。Mac OS X Serverであれば、OSを10.4.6にアップデートするとそのときサーバ管理ツールもアップデートされますが、Mac OS X上のサーバ管理ツールを最新にアップデートするにはMac OS X Server 10.4.6のアップデートに含まれるパッケージを引っこ抜くなどの対応が必要になります。
さて、これでリモートインストールの環境が整いましたので、次回は実際のインストール方法について解説したいと思います。
つづく
*1 初期型のXserveではこの方法を使用できません。
小池邦人のCarbon API 徒然草（2006/05/26）
〜 アプリケーションのUniversal Binary化（その9） 〜
今回は、もう少し詳しく画像データフォーマットに関連した例題を調べてみます。また、DICOM画像など、内部の数値フォーマットがエンディアンに依存しているファイルについても解説します。
前回の復習となりますが、1ピクセルがunsigned longにマッピングされたMacintosh用画像フォーマットの色成分の並びはαRGB（αは透明度）であり、OpenGL用テクスチャ画像フォーマットの方はRGBαです。よって、両者の変換を行うには（α値は0xff固定とする）、オリジナルデータを8bit左へシフトさせ、透明度として0xffを追加します。実際の変換ソースコードをもう一度見てみます。ビッグエンディアンに最適化した場合には…
*tex=((*buf++)<<8)+0xff;
となり、リトルエンディアンに最適化した場合には...
*tex=((*buf++)>>8)+0xff000000;
となります。リトルエンディアンの場合はちょっと奇異に見えます。これは、数値に対する加減乗除、シフト演算、理論演算などが、反転したデータに対して正しく行われるよう処理されるためです。例えば、8bit右へシフトすることは256で割るのと同じですから、0x11223344（long値）は0x00112233となります。この数値はメモリ内では44332211と並んでいますので、演算結果は33221100となります。数値演算的には8bit右へシフトさせましたが、画像フォーマット的に見ると左へ8bitシフトしていることが理解できます。
つまり、リトルエンディアンでは色成分がBGRαと列んでいると考えて各種演算を実行すれば結果オーライとなります（考えるだけ...実際は違う）。以下のzeroLevelImage()ルーチンは、RGBの各色の値がすべて指定範囲外である場合に、画像バッファのピクセルをゼロでクリアしています。画像データからRGBの各色成分を抜き出す処理のソースコード部分が、リトルエンディアンとビッグエンディアンでは異なります。
void zeroLevelImage( CGrafPtr gptr,unsigned long st,unsigned long ed )
{
unsigned long *add,*pp,i,j,row,cc,rr,gg,bb;
Rect drt;
PixMapHandle phd;
GetPortBounds( gptr,&drt ); // オフスクリーン（CGrafPort）の矩形枠を得る
phd=GetGWorldPixMap( gptr ); // PixMapHandleを得る
row=GetPixRowBytes( phd )>>2; // RowBytesを得てlong Bytes数に変換
add=(unsigned long *)GetPixBaseAddr( phd ); // 先頭アドレスを得る
for( i=0;i
次の例は、医療現場などで使われるDICOM画像ファイルの解析です。readDicomImage()は、FSSpecで指定されたDICOMファイルを読み込み、その画像データをオフスクリーンバッファ（CGrafPPort）に描画するためのルーチンです。TIFFやExif画像ファイルにはリトルエンディアンとビッグエンディアンの両フォーマットがあり、ヘッダ部分でどちらなのか判断可能です。しかし、DICOMファイルの場合はリトルエンディアンフォーマット固定であり、ファイル内に書き込まれているタグやshort,long整数は、ビッグエンディアン環境では反転させてから読み込む必要があります。
short readDicomImage( CGrafPtr gptr,FSSpec *fsc )
{
short type,fref,chk,ret=1;
short *pp,*last;
long size,len,i;
Ptr buf=NULL;
unsigned long *aa,d1,kk;
#if __LITTLE_ENDIAN__ // タグ比較用の定数を変数に代入する（リトル用）
kk=0x00107fE0;
#else
kk=0xE07F1000; // （ビッグ用）
#endif
if( ! FSpOpenDF( fsc,fsRdPerm,&fref ) ) // DICOMファイルをオープンする
{
GetEOF( fref,&size ); // ファイルのサイズを得る
if( buf=NewPtr( size ) ) // メモリ領域を確保する
ret=FSRead( fref,&size,buf ); // ファイルをメモリに読み込む
FSClose( fref ); // ファイルをクローズする
}
if( ret==noErr )
{
chk=0;
ret=1;
len=size>>1;
pp=(short *)buf;
last=pp+len;
for( i=0;i
逆にリトルエンディアン環境であれば、ファイルから得られた数値データはそのまま変数に代入して利用しても良いことになります。以下の2つのルーチンは、DICOMファイルから得られた数値やタグ情報を適切に処理するために用意したものです。
short getDicomShort( short val ) // DICOMの整数値（short）を反転させる
{
#if __BIG_ENDIAN__
return( Endian16_Swap( val ) ); // ビッグエンディアンのみ反転
#else
return( val );
#endif
}
long getDicomLong( long val ) // DICOMの整数値（long）を反転させる
{
#if __BIG_ENDIAN__
return( Endian32_Swap( val ) ); // ビッグエンディアンのみ反転
#else
return( val );
#endif
}
次回は、Universal Binary化における最大の難関（笑）PowerPCのAltiVecコードをIntel CPUのSSE/SSE2コードに変換する話に突入します。まずは、アプリケーションでAltiVecやSSE/SSE2を利用しなければいけないケースについて色々と考察してみます。
つづく
SqueakではじめるSmalltalk入門 第62回 鷲見 正人
本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回は、ワークスペースというアプリケーション（ウインドウ）がどんなモーフの組み合わせでできているのかを“破壊”して調べてみました。今度は逆に、モーフを組み合わせるスクリプトを記述し、ウインドウを組み立ててみましょう。
まずは、ワークスペースがどのように組み立てられているのか、その“出生”をたどってみることにします。
ワークスペースは、デスクトップメニューの「開く…」サブメニューの「ワークスペース (k)」を選んで起動します。ちなみに「(k)」とあるのは、デスクトップメニューをポップアップしたり、それを閉じた直後などに「cmd+ K」でワークスペースを呼び出すことが可能であることを示しています。
さて、復習を兼ねて、この「開く…」サブメニューの「ワークスペース(k)」項目をインスペクトして、ワークスペースを開くために、どんなメソッドが起動されているのかを調べてみましょう。具体的には「開く…」サブメニューの「ワークスペース (k)」項目を、shift + cmd + クリック（あるいは、複数回 cmd + クリック）してモーフとして選択し、右側の灰色ハロー（デバッグハロー）を shift クリックしてインスペクタを呼び出します。
[fig.A]モーフとして選択された「ワークスペース (k)」項目
[fig.B]「ワークスペース (k)」項目のインスペクタ
インスペクタの左側のリストペインにある、target、selector、argumentsの内容から、このメニュー項目が選択されたときに誰にどんなメッセージが送られるのかが分かります。簡単のため、ここでは#doMenuItem:with:についての詳しい解説は省きますが、その名前とメソッドの定義から、どうやらargumentsの配列内配列の第一要素に対して、第二要素のセレクタを持つメッセージを送信していることが分かります。そこで引き続き、第二要素の#openWorkspaceというメソッドの定義を調べてみることにします。念のため補足しておくと、メソッドの定義を閲覧するには、メソッド名の文字列「openWorkspace」を選択してbrowse it（cmd + B）を使うのでしたね。
#openWorkspaceには、レガシーなScreenCoontroller >> #openWorkspaceもあり、これがブラウザの起動時に選択されていますが、今は二番目のTheWorldMenu >> #openWorkspaceのほうをクリックして選択しましょう。ここから、implementorsボタンを用いてStringHolder >>#openAsMorphLabel:inWorld:の定義を見ると、具体的にどんな手続きを踏んでワークスペースを表示してるのかが分かります。ちなみに、StringHolderはWorkspaceのスーパークラスです。
[fig.C]「StringHolder >> #openAsMorphLabel:inWorld:」の定義
では、この定義に倣って、ワークスペースっぽいウインドウを“作る”スクリプトを書き起こしてみましょう。
| window textMorph |
window := SystemWindow labelled: 'My Text Window'.
textMorph := PluggableTextMorph on: nil text: nil accept: nil.
window addMorph: textMorph frame: (0@0 corner: 1@1).
window openInWorld: World
このウインドウは、見た目こそワークスペースに似ていますが、それは同じ種類のパーツを組み合わせた結果にすぎず、ワークスペースとしては機能しません。ちょうどInterface Builderで組み立てただけのUIと同じく、“魂”である「モデル」を欠いている状態です。テキストを入力したり、その編集（cmd + Z/X/C/V）や、do it（cmd + D）、print it（cmd + P）などのキーショートカットは機能しますが、黄ボタンメニューを呼び出すことはできません。ちなみに、オリジナルのStringHolder >> #openAsMorphLabel:inWorld:では、#model:や#on:text:accept:readSelection:menu:が、このUIと“魂”とを接続する作業をしています。とりあえず今は、次の#addMorph:frame:のほうに注目してください。
SystemWindow >> #addMorph:frame:は、Morph >> #addMorph:同様、サブモーフ（GUIウィジェット）をオーナー（システムウインドウ）に組み込むためのメソッドです。ただ、新しく設けられた第二パラメータとして添えるa Rectangle情報により、常にオーナーのどの範囲に位置するのかを指定することができます。#addMoprh:ではどうして駄目なのかは、実際に試してみればわかります。
| window textMorph |
window := SystemWindow labelled: 'My Text Window'.
textMorph := PluggableTextMorph on: nil text: nil accept: nil.
window addMorph: textMorph.
window openInWorld: World
[fig.D]#addMorph:では正常なウインドウを作ることができない…
たしかに#addMorph:でもa PluggableTextMorph はサブモーフとして登録されますが、オーナーモーフであるウインドウの左上に固定されていて、ウインドウサイズ変更にも追従してくれません。これではウインドウとして使いものになりませんね。
他方で、次のようにa PluggableTextMorphを二つ用意し、それぞれを#addMoprh:frame:するときに、適切なa Rectangle情報を与えることで、2ペイン（2つのテキスト編集欄）を持つウインドウを組み立てることが可能です。
| window textMorph1 textMorph2 |
window := SystemWindow labelled: 'Two Pane Text Window'.
textMorph1 := PluggableTextMorph on: nil text: nil accept: nil.
textMorph2 := PluggableTextMorph on: nil text: nil accept: nil.
window addMorph: textMorph1 frame: (0@0 corner: 1@0.5).
window addMorph: textMorph2 frame: (0@0.5 corner: 1@1).
window openInWorld: World
[fig.E]2ペインのウインドウ
現在、残念ながらSqueakシステムには、OS XのInterface Builderのような優れたUIデザインユーティリティは組み込まれていません。したがって、ウインドウのデザインは、いちいちこうして、Smalltalkコードとして記述する必要があります。ちょっと面倒ですね。
バックナンバー：
ニュース・解説
今週の解説担当:木下 誠
----------------------------------------------------------------------
WWDC 2006情報
----------------------------------------------------------------------
開催まであと二ヶ月と少しとなったWWDC 2006。チケットやフライトの手配はお済みでしょうか？
ADCのサイトでは、WWDCのページが更新されて、Community Focusというページが登場しています。ここでは、アプリケーション開発者だけではない、Macプラットフォームに興味を持つプログラミングコミュニティに向けた情報が提供されています。
登場しているのは、「Digital Media」「System Administration」「Games Development」「Scientific Computing」といった分野に向けたものです。いずれも、「GUI + Unix + Intel」といったMacの特徴を活かしやすいところと言えるでしょう。ま、そのためにはデベロッパが相当力を入れる必要があるでしょうが。
また、WWDCを控えて、Appleのデベロッパリレーションズ担当副社長ロン・オカモト氏へのインタビュー記事がいくつか公開されています。WWDCの見所などを語っています。
WWDC 2006
http://developer.apple.com/wwdc/
Digital Media
http://developer.apple.com/wwdc/digitalmedia.html
System Administration
http://developer.apple.com/wwdc/sysadmin.html
Games Development
http://developer.apple.com/wwdc/games.html
Scientific Computing
http://developer.apple.com/wwdc/science.html
「Boot Campはアプリ開発者にチャンスを生み出す」、米Appleデベロッパ担当副社長が語る
http://itpro.nikkeibp.co.jp/article/NEWS/20060516/238122/
【インタビュー】次期Mac OS X Leopard - Appleデベロッパリレーションズ担当副社長語る
http://journal.mycom.co.jp/articles/2006/05/23/leopard/
----------------------------------------------------------------------
Xcode 2.3
----------------------------------------------------------------------
Xcode 2.3がリリースされました。新しいトピックとして、リリースノートによると、まずデバッグのフォーマットとしてDWARFを採用した事が挙げられています。DWARFを使う事で、デバッグイメージのサイズが小さくなり、パフォーマンスの低い環境でのデバッグが改善されるようです。
また、Dedicated Network Builds (DNB)が利用できるようになった事も挙げられています。これは、分散ビルドの一種でしょうか。
----------------------------------------------------------------------
ADC Referenceが再編
----------------------------------------------------------------------
Xcode 2.3のリリースと併せて、ADC Referenceの構造も大きく変わっています。
まず、ドキュメントリソースのタイプが、従来「Documentation」となっていたものが、「Guides」と「Reference」に分かれました。さらに、いままでは散在していたAPIリファレンスが、フレームワークごとに管理されるようになったようです。
これからもドキュメントは増え続けるでしょうから、きちんとした管理を続けて欲しいものです。
Newest Features of the ADC Reference Library
http://developer.apple.com/macosx/newinreflibrary.html
----------------------------------------------------------------------
オープンソースとUniversal Binary
----------------------------------------------------------------------
オープンソースプロジェクトをUniversal Binaryに対応させるステップを紹介したドキュメント、「Building a Universal Binary Framework from Open Source」が公開されています。
オープンソースの場合、Universal Binary移行の最大のポイントは、Xcode対応になります。多くの場合、オープンソースプロジェクトではMakefileを使っています。ですが、Universal Binaryパッケージを作るには、Appleが推奨する方法では、Xcodeを使う以外ありません。
このドキュメントでは、MakefileをXcodeに移行させる手順を紹介しています。ただし、自動的に行なう方法はなく、プロジェクトの作成やファイルの登録を、一つ一つ手作業で行なっています。オープンソースプロジェクトでは、できるだけ多くのプラットフォームに対応する事が前提になっている事が多いので、この解説がどれだけ助けになるかは、少し疑問に感じますね。
Building a Universal Binary Framework from Open Source
http://developer.apple.com/opensource/opensourceuniversalframework.html
◇MOSAからのお知らせと編集後記は割愛します◇
記事投稿受付 http://www.mosa.gr.jp/topics/mdn-toukou.html
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA http://www.mosa.gr.jp/
Copyright (C)2006 MOSA. All rights reserved.