GTK-mac-bundler HOWTO (ビルド編)

gtk-mac-bundler の本体もとってきて、適当なディレクトリに展開して make install します。
[code:plain]
$ tar xf gtk-mac-bundler-0.7.3.tar.xz
$ cd gtk-mac-bundler-0.7.3
$ make install
[/code]
これで gtk-mac-bundler がインストールされる先は ~/.local/ 以下で、jhbuild で gtk をインストールした先と同じです。また、展開したフォルダ以下の examples/ には gtk-mac-bundler を実行するときの設定ファイルのサンプルがいろいろあります。
pkg-config が参照する GTK のインストールディレクトリを適切に選択するためには、PKG_CONFIG_PATH とかを設定する必要があるのですが、そういうのはまとめて jhbuild に委ねます。
[code:plain]
$ jhbuild shell
[/code]
これで起動するシェルは環境設定がちゃんとできているだけで普通の bash なので、このなかで普通に自分のプログラムを build して実行ファイルを作ります。
アプリケーションバンドルを作るには以下のファイルが必要です。
– .bundle ファイル (gtk-mac-bundle の設定)
– Info.plist (OS X 用)
– 起動用シェルスクリプト
– アイコンファイル
[.bundle ファイル]
gtk-demo をアプリケーションバンドルにするためのサンプルが examples/gtk-demo.bundle として用意されており、中味は XML ファイルです。最低限変更が必要なのは、
– launcher-script (起動用シェルスクリプト)
– plist (Info.plist として使うファイル)
– main-binary (実行ファイル本体)
の3つです。アイコンのファイルがある場合には、これも変更しておきましょう。
また、pango に関連するバイナリが不足しており、このままだとポータビリティのない (他のMacで動かない) バンドルができてしまうので、pango-querymodules や pango のモジュールを含める設定をします。
[code:xml]

${prefix}/bin/pango-querymodules
${prefix}/lib/pango/1.8.0/modules/*.so

[/code]
[Info.plist]
アプリケーションのバージョンや Copyright の情報などが記述されています。examples/Info.plist をたたき台にしてテキストエディタで書きます。
[起動用シェルスクリプト]
サンプルとして examples/launcher.sh が用意されており、基本的にはこれで変更の必要はない、はずなのですが、やはり pango に関連する部分を修正しておかないと、他の Mac に持って行ったときにフォントが全部□になってしまいます。
修正が必要なのはスクリプトのわりと最初のほうと、一番最後の2カ所です。これで、起動のたびに pango のモジュールパスを正しく生成するようにします。
[code:plain]
export PANGO_RC_FILE=”$bundle_etc/pango/pangorc”
+export PANGO_LIBDIR=”$bundle_lib”
+export PANGO_SYSCONFDIR=”$bundle_etc”
[/code]
[code:plain]
+mkdir -p “$bundle/pango/1.8.0”
+ln -sf ../../ “$bundle/pango/1.8.0/modules”
+
+”$bundle_bin/pango-querymodules” > “$bundle_etc/pango/pango.modules”
+
+export PANGO_LIBDIR=””
+
$EXEC “$bundle_contents/MacOS/$name-bin” “$@” $EXTRA_ARGS
[/code]
これで準備は終わりです。
[code:plain]
$ gtk-mac-bundler hogehoge.bundle
[/code]
とすれば、~/Desktop にアプリケーションバンドルが作られるはずです。

GTK-mac-bundler HOWTO (環境構築編)

ひさびさに GMV を Mac 版バイナリ配布用にビルドすることにしました。で、以前は GTK+ のパッケージを別にインストールしてもらう構成にしていたのだけれど、これ、インストール先の環境を汚してしまう感じがして大変申し訳ないので、ちゃんと Application bundle にしたいなー、と思いまして。
GMV を intensive に開発していた頃は、まだ GTK+-Quartz はあちこち怪しいところもあった (Gimp の配布も X11 版でした) んですが、いまはかなり安定して動くようになりましたし、しかも gtk-mac-bundler なんていうツールまで提供されているので、これは使うしかない。
まず、MacOS X 10.8 + Xcode をセットアップ。最近は MacOS X も仮想マシンとして使えるようになって本当に便利。職場では VMware Fusion ですが、自宅では VirtualBox でやってます。どっちもちゃんと動きます。VirtualBox だと、MacOS 用の Guest Additions がないので GUI で使うには若干不便 (host からの copy & paste とかができない) ですが、Xcode のセットアップまでやっちゃえばあとは ssh でログインして作業できることが大半ですし、あんまり問題ない感じ。
GNOME.org の GTK+-OSX のページから、gtk-osx-build-setup.sh というのをとってきてスタートです。なお、一連のツールは jhbuild という仕掛けを利用しており、gtk-osx-build-setp はこれを ~/.local/bin にインストールします。
[code:plain]
$ sh ./gtk-osx-build-setup.sh
$ export PATH=~/.local/bin:$PATH
$ jhbuild bootstrap
[/code]
これでとっかかりの部分があっけなく完了です。

ここから先は bootstrap でインストールされたツール群を利用するために、~/gtk/inst/bin にも PATH を通す必要がありますが、いろいろの環境変数の設定が面倒なので、
[code:plain]
$ jhbuild shell
[/code]
として、構築環境を起動します。しかしここでは MACOSX_DEPLOYMENT_TARGET という環境変数がなぜか 10.7 に設定されており、あとで GTK の build がエラーになるので、
[code:plain]
$ export MACOSX_DEPLOYMENT_TARGET=10.8
[/code]
としておいて、一通りのツールを作ります。Python は build しておかないと、システム標準のでは meta-gtk-osx-core の build でエラーがでる気がします。
[code:plain]
% jhbuild build python
% jhbuild build meta-gtk-osx-bootstrap
% jhbuild build meta-gtk-osx-core
[/code]
(続く)

/dev/ttyUSB on Linux

Linux 全然わからないんですが、FPGA に書き込みするのに使ってるマシンから FPGA 上の UART を叩きたかったので。
で、USB-UART が /dev/ttyUSB0 とかに生えてくるのだけれど、これの permission がふつうのユーザからは読み書きできないようになってたので、udev のルールを書き足してみたら、うまくいきました。
[code:plain]
# cat /etc/udev/rules.d/51-ttyUSB.rules
KERNEL==”ttyUSB*[0-9]*”, GROUP=”dialout”, MODE=”0666″
# /sbin/udevadm control –reload
[/code]
あと、GNU screen でシリアルポート使えるの全然知らなかったのですが、最近の Linux には cu とかないし、minicom はなんか慣れないし、これはいいですね。
[code:plain]
% screen /dev/ttyUSB0 9600
[/code]
とかすれば9600bpsでつながるし、終了はふつうにscreen のkill window でいけるぽい。

Yosemite Beta と iOS 8

古い MacBook Air (Late 2010) を引っ張り出してきて Yosemite Beta をクリーンインストールしてみました。Yosemite Beta のインストーラのフォルダの中に createinstallmedia みたいなツールがあり、それで USB メモリを起動ディスクにできます。
[ iCloud ]
Yosemite では iCloud Drive にアップグレードしないと iWork で作って iCloud に置いてあるデータにアクセスできないっぽい。
iOS 8 では iCloud (Drive でない) のデータにアクセスできています。
[ iOS – Mac 連携 ]
iPhone に電話かかってくると Mac の画面に通知が出る。出たからどうにかなるかっていうと、iPhone で普通に電話とるしかないみたいですが。
発信もできそうだけど、やってみても何もおきませんでした。
FaceTime の設定の画面には iPhone と同じ WiFi ネットワークにつながっていれば連携ができる、という説明があります。
[ 動いたもの ]
– ATOK
– Dropbox (ただしファイルやフォルダのアイコンに同期状況のマークがつかない)
– Evernote

台風予報

台風が発生するとあっという間にやってくる沖縄では、わりとみんな真剣に台風の進路予想をみるわけで。
でも実はいろいろなところが予報出してます。
米海軍: http://www.usno.navy.mil/JTWC/
気象庁: http://www.jma.go.jp/jp/typh/
Weathernews: http://weathernews.jp/typhoon/
ちょっと前に 台風の上陸地点について気象庁と Weathernews が異なった見解を出して問題になる という事件がありましたが、進路予報もよく見るとちょっとずつ違っていたりします。
今回は米海軍の予報だと沖縄本島地方にはあんまり近付かない感じ。そうなってほしいなあ。

ANA136

羽田からの飛行機はいつも、素敵な誰かを乗せてやってくる。
いつも一人で乗っていた羽田線に、
奥さんを東京から迎えて、夫婦で乗るようになり、
それから、両親が沖縄に遊びにきたりして。
そんなわけで、生まれてくる娘を迎えに東京へ行ってきました。
帰宅してから那覇に向かうバスに乗るまで20分、バスの中で飛行機を予約する、というとんでもないハードスケジュールで飛んだけど、出産に間に合って本当によかった。
一人のフライトが二人になり、今年の夏には三人で。

ownCloud いれてみた

いままで過去の発表スライドはぜんぶ subversion で管理して同期してたのだけれど、Keynote のファイルがフォルダ形式に戻っちゃったので、ちょっと編集すると .svn が消えたりして困ったことになる問題が頻発。
Dropbox でもいいのだけれど、ちょっと容量的に心配なのでどうしよっかなー、と思って、ownCloud いれてみた。
感想とか制約とか:
– セットアップ超簡単。FreeBSD ports でインストールするだけでほとんど終わる (SQLite つかえるし)
– 速度が遅い?と思ったけどそうでもなかった
– Mac 版のクライアントは普通にイケてる
– ただし Dropbox みたいに、Finder のアイコンに同期状態がついたりはしない
– 昔の (zipな) Keynote のファイルを “アップグレード” してフォルダ形式にすると、同期時に conflict と判断されて取り残される
– ファイル名に “?” とかが含まれていると同期されない。Web から copy & paste した画像とかが Keynote のスライドにあると取り残される
– シンボリックリンクが扱えない
写真をいっぱい置く、みたいな、regular file しかないよ、という使い方ならかなりよいのでは、と思ったけど、僕はちょっとつらいな。
Dropbox ってすごいんですね…

ANA127

高校の時にいわゆる鉄道写真を撮るのをすっぱりやめてからは、乗り物を撮るだけのために出かける、ということはもう15年以上もなかったわけだけど、最後の 747-400D 定期便が那覇にやってくる、となればそれはある程度違ってくるわけで。
那覇空港の滑走路は南北にまっすぐで、空港付近で個人的にお気に入りなのは空港の立体駐車場の屋上とかから見る RWY36 の離陸と、豊崎方面から見る RWY36 の着陸便。あとは、北風時は着陸便がうちの上空通るのもいいですね。つまり、南風運用になっちゃうと残念ですが、季節はそろそろ春。
それで、数日前からすっかり暖かくなって南風だったので諦めていたのですが、前日から天気が悪くなって、北風。もうこれは行くしかないですね。カメラは家にも何台かおいてあるんだけど、望遠レンズは研究室に置きっ放しになっちゃってたので、コンパクトデジカメしかないんだけども。
それで、豊崎海浜公園は北風運用時の進入経路の真下。カメラ持ってる人いっぱいいるんじゃないかと思ったら、誰もいませんでした。頻繁に着陸便が通り過ぎるので何度か練習で撮ってみたりとか。でも、ATCも何もきいてないので、いつくるか全然わからないわけです。
DSCN6522.JPG
遠くから見分けるのは胴体下のメインギアくらいかな。4発機かどうかは、小さいと意外とわからないものですね。
DSCN6523.JPG
DSCN6524.JPG
DSCN6525.JPG
というわけで那覇空港に着陸するのを見届けておしまい。
長い間お疲れさまでした。ありがとう。

ANA136

IMG_6941.JPG
便名のついているエントリを書くのもひさしぶり。
1月27日午後7時半、那覇空港。
全日空136便で、おそらく最後の747の2階席で羽田へ。
何ごともないように、RWY18 から沖縄の夜空に舞い上がる。
いきなり沖縄に住むことになってからの3年間、数え切れないほど乗ってきた機体。
最初はひとりで、そのうち結婚してふたりで乗るようになって、
本当にお世話になりました。ありがとう。

Mac mini で謎トラブル

うちの研究室の学生用端末はみんな Mac mini なんですが、先日とある学生が「なんか調子悪いっす」というので、top で変なプロセスがいないかとか、いろいろみてたんですが、結局わからなくてふと log をのぞいたらこんなのがいっぱい。
[code:plain]
Sep 3 16:43:48 macmini3 kernel[0]: stampWait: Overflowed checking for stamp 0x0 on MAIN ring: called from
Sep 3 16:43:48 macmini3 kernel[0]: timestamp = 0x8024f028
Sep 3 16:43:48 macmini3 kernel[0]: **** Debug info for *possible* hang in MAIN graphics engine ****
Sep 3 16:43:48 macmini3 kernel[0]: ring head = 0x5c804250, wrap count = 740
Sep 3 16:43:48 macmini3 kernel[0]: ring tail = 0x00004250
Sep 3 16:43:48 macmini3 kernel[0]: ring control = 0x0000f001 enabled, auto report disabled, not waiting, semaphore not waiting, length = 0x010 4KB pages
Sep 3 16:43:48 macmini3 kernel[0]: timestamps = 0x8024f028
Sep 3 16:43:48 macmini3 kernel[0]: Semaphore register values:
Sep 3 16:43:48 macmini3 kernel[0]: VRSYNC: (0x12044) = 0x8024f028
Sep 3 16:43:48 macmini3 kernel[0]: BRSYNC: (0x22040) = 0x0
Sep 3 16:43:48 macmini3 kernel[0]: RVSYNC: (0x 2040) = 0x0
Sep 3 16:43:48 macmini3 kernel[0]: BVSYNC: (0x22044) = 0x0
Sep 3 16:43:48 macmini3 kernel[0]: RBSYNC: (0x 2044) = 0x0
Sep 3 16:43:48 macmini3 kernel[0]: VBSYNC: (0x12040) = 0x0
[/code]
Userland のトラブルじゃないし、やむなく reboot しました。Intel HD3000 Graphics なモデルなのですけれど、なんでかねー。