2014年09月16日

Xcode 5.1.1のMountain Lionへのインストール

東京も曇ってすっきりしない日々が続いてましたが、先週末の連休からやっと晴れて良い天気になりました。例年ならこの時期は残暑が厳しく蒸し暑いのですが、今年はそれほど暑さが辛くありません。湿度が低いようで、晴れても爽やかさを感じられます。本当に夏らしい気候だったのは、東京では7月中旬〜8月中旬の一ヶ月だけでした。9月も残り2週間ですが、秋の兆しは早く訪れそうです。

さて、前記事に書いたとおり、新型のMacBook Air 11-inchを手に入れたので、いまこれにiOS開発環境を構築中です。ADC(Apple Develper Connection)で配布されているXcodeは、そのリリース時点の最新バージョンと一つ前のバージョンのOS Xに対応しています。MBA11のOSはMountain Lionにダウングレードしたのは、Yosemiteの評判が良くなく開発環境として使うことに不安があったからですが、最新版のXcodeがMountain Lionに対応していたことも判断基準になりました。現時点のXcodeの最新バージョンはXcode 5.1.1ですが、これはOS X YosemiteとMountain Lionで使うことができます。Xcode 5.1.1をMBA11へインストールしたので、自分の備忘録を兼ねて、その作業記録を書いておきます。

MBA11にiOS開発環境を構築するにあたって、Xcode 5.1.1より先にXcode 4.6.3をインストールしました。この2つのバージョンを共存させて併用したかったからです。Xcode 5.1.1はiOS 7.0, 7.1、Xcode 4.6.3はiOS 5.0〜6.1開発用として使い分けていくつもりです。去年Mac mini(Mountain Lion搭載)へXcode 4.6.3を入れましたが、このときと完全に同じ手順でインストールを行いました。Xcodeアプリを「アプリケーション」フォルダへコピーした後、追加コンポーネントとドキュメントのインストールを行い、最後に他のバージョンのXcodeからiOS 5.0, 5.1, 6.0 SDKとMac OS X 10.6 SDKをコピーしました(2014/07/08の記事を参照)。下のスクリーンショットが、Xcode 4.6.3をインストールしてiOS/Mac OS X SDKを追加した後のDeveloper Information([ユーティリティ]>[システム情報]の「Developer」カテゴリ)表示です。
SCShot_140915_0001-Installing_Xcode_4.6.3_on_MountainLion-751x520
上の作業が済んだ後、Xcode 4.6.3のアプリファイルXcode.appXcode_463.appへリネームした上で、Xcode 5.1.1のインストールを始めました。

まずはXcode 5.1.1のアプリファイルを「アプリケーション」フォルダへコピーしました。
SCShot_140915_0007-Installing_Xcode_5.1.1_on_MountainLion-612x421.png
コピーが終わった後Xcode 5.1.1を初めて起動すると、ライセンス同意要求のウィンドウに続いて、下のようなウィンドウが表示されました。
SCShot_140915_0011-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
このウィンドウの「Install」ボタンを押すと、追加コンポーネントのインストールが始まりました。
SCShot_140915_0013-Installing_Xcode_5.1.1_on_MountainLion-479x162.png
この処理が終了すると、XcodeのWelcomeウィンドウが表示されました。
SCShot_140915_0014-Installing_Xcode_5.1.1_on_MountainLion-801x472
Xcode 5.1.1が起動することを確認したら、すぐに[Xcode]>[Preferences]メニューの[Downloads]タブ画面を開き、コンポーネントとドキュメントの追加インストールを行いました。
SCShot_140915_0017-Installing_Xcode_5.1.1_on_MountainLion-750x498
SCShot_140915_0028-Installing_Xcode_5.1.1_on_MountainLion-750x498
すべてのコンポーネントを追加した後のXcode 5.1.1のDeveloper Informationは下のような表示になりました。
SCShot_140915_0020-Installing_Xcode_5.1.1_on_MountainLion-751x573
これでXcode 5.1.1のインストールは一応完了ですが、上のスクリーンショットから本バージョンにはiOS 7.1 SDKしか同梱されていないことが判ります。iOS 7.0用アプリの開発も行いたいので、Xcode 5.1.1にiOS 7.0 SDKを追加しました。具体的には、Xcode 5.0.2のdmgファイルをマウントして、ターミナルから次のコマンドを実行すれば、iOS 7.0 SDKを追加できます。
$ sudo cp -Rp /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs

下のスクリーンショットが、iOS 7.0 SDKを追加した後のXcode 5.1.1のDeveloper Information表示です。
SCShot_140915_0022-Installing_Xcode_5.1.1_on_MountainLion-751x573
さらに、iOS 5.0〜6.1とMac OS X 10.6, 10.7のSDKをXcode 5.1.1へ追加する作業も行いました(以下は、2013/12/03の記事に書いたMac miniのMountain LionへXcode 5.0.2をインストールしたときと同じ手順ですが、再掲載しておきます)。
  1. ターミナルを開き、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のiOS SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk ./

    これによって、iOS 5.0, 5.1, 6.0, 6,1のSDK が追加されます。

  2. 続いて、次のコマンドを実行して、Xcode 5.1.1内にXcode 4.6.3側のMac OS X SDKが格納されているディレクトリのリンクを作成しました。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk ./

    これによって、Mac OS X 10.6, 10.7のSDKが追加されます。

上のすべての操作を行った後、Xcode 5.1.1のDeveloper Information表示を確認すると、下のようになっていました。
SCShot_140915_0024-Installing_Xcode_5.1.1_on_MountainLion-751x612
上記のとおり、MBA11へXcode 4.6.3とXcode 5.1.1を共存インストールしてiOS開発環境を構築しましたが、その前に基本的なソフトを入れる作業もやりました。Windowsと比較すると、Macはこの作業がすごく楽です。基本的なソフトを一通り入れて使える状態にするのに、Windowsだと2〜3日かかったりしますが、Macだと半日〜1日で終わります。Windowsではソフト毎にインストーラを起動して入れていきますが、インストーラが起動するまで数分待たされたりしますし、インストール手順も統一性がなくまちまちです。インストーラによって表示されるガイド画面を確認しながら慎重に作業を進めていかないと、不要なものまでインストールされたりします。これに対して、Macではアプリのアイコンを「アプリケーション」フォルダへコピーするだけでインストールできます。すべてのアプリがこの手順に統一されているので、dmgファイルを開いたりzip/bz2ファイルを解凍した後にこの操作を行うだけです。ドライバやカーネルモジュールを内包しているソフトではインストーラが用意されていますが(インストーラはpkg/mpkgファイル内に収納されているので、同ファイルを開くと自動的に起動します)、インストーラのガイド画面もほぼ統一されているので、インストール操作を誤ったり迷ったりすることはまずありません。Windowsでは新しいソフトを入れるだけでシステムが不安定になったりすることがあり、こういう現象を解決するのに時間を取られたりしますが、Macではこんなことは皆無です。私は数台のMacを4年間ほぼ毎日を使い続けていますが、いままでこういう経験をしたことが一度もありません。マルウェアの数と種類もWindowsの方が断然多く、アンチウィルスやファイアーウォールを入れていないWindows PCはすぐにマルウェアに感染してしまいます。OSの安定性と安全性では、WindowsよりMacの方が圧倒的に優れています。本業の仕事でWindowsに使っていると、画面のあまりの見難さ(Macと比較すると、Windowsは特にフォントがすごく醜いです)とあまりの使い難さに嫌気が差してきます。毎日Macだけ使って仕事ができたら、どんなに幸せだろうと思ってしまいます。
タグ:Xcode
posted by とみやん at 10:58| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2014年01月04日

GitHubにdofilesリポジトリを作成した

前記事にGitHubのアカウントを登録したことを書きましたが、さっそくGitHubにリポジトリを作成してみました。予告どおり、最初のリポジトリはdotfilesです。.bashrc.vimrcなどの「.」で始まるファイルをこのリポジトリ格納しています。他のユーザーに利用してもらうことを前提に凝った内容のドットファイルを公開している人もいますが(「GitHub dotfiles」でググるとたんさんのページがヒットします。「こういうテクニックがあるのかぁ!」というようなTipsがいくつも見つかるはずです)、私の場合は、あくまで自分専用のプライベートなリポジトリです(と言っても、公開リポジトリなので誰でも参照できてしまいますが)。MacやLinux環境のドットファイルを一元的に管理するのがこのリポジトリの目的です。具体的には、「git clone」コマンドでdotfilesリポジトリのファイルを取得して、それらファイルのシンボリックリンクをホームディレクトリ直下に作成するというやり方で利用します。

■GitHubへのSSH公開鍵登録


GitHubにリポジトリを作成する前に、最初にやっておかなけはれならないことがあります。それは、GitHubへのSSH公開鍵の登録です。gitコマンドを使ってGitHubのリポジトリへのアクセスする際にSSH経由で接続するからです。まずは、ssh-keygenコマンドを使ってSSH鍵ペア(秘密鍵と公開鍵)を作成します。
% mkdir ~/.ssh/github
% ssh-keygen -t rsa -C "yourname@xyzzyxxyz.jp" -f ~/.ssh/github/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/LOGINHOME/.ssh/github/id_rsa.
Your public key has been saved in /Users/LOGINHOME/.ssh/github/id_rsa.pub.
The key fingerprint is:
93:31:48:88:de:cb:37:ea:9c:9d:5f:01:79:93:c7:cf yourname@xyzzyxxyz.jp
The key's randomart image is:
+--[ RSA 2048]----+
| . .. |
| . .. . . o |
| . . . = + o |
| . . * o o |
| . . S . E |
| o o . . |
| o . . |
| ..o . . |
| .+ o.. |
+-----------------+

上の操作によって、以下の2つのSSH鍵(いずれもRSA 2048ビット形式)が作成されます。

 ~/.ssh/github/id_rsa     SSH秘密鍵
 ~/.ssh/github/id_rsa.pub SSH公開鍵

デフォルトのSSH鍵の格納先は~/.sshですが、~/.ssh/githubというディレクトリを作成してそちらに格納することにします。私の場合、さくらのVPSのクラウドPCへアクセスするためのSSH鍵も作成済みなので、これらと区別するためです。

SSH秘密鍵と公開鍵を作成したら、自分以外のユーザーがそれらの内容を参照できないようにするため、ファイルのパーミションを変更しておきます。
% chmod 600 ~/.ssh/github/*

ssh-keygenコマンドによって作成されたSSH公開鍵の内容を確認します。
% cat ~/.ssh/github/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0voXZsGtiGasZR/AEZa/ATRMrHjog3hfqZsIHhPflikKnsmyX+6
8eV+Kgs37/yFzUbexn2CP+JloXiQNBxlza/+bWhkg2q8KdeH29N+7IUj/W+NORQ/WEGRoQEj0YIAEqmarQ2cG0N/Ow
KcHO7dID9Aofjrg5QFDmq84qNRtNMq/GK0ymo5GI7nlrEN4L99uX/3ieE6U3E8HE30pKlUMZdZSso2ic1vnYzS5LKu
VXtzwdeuWPbYPl4+pwJaoL9Pb6pEwLhdbCFJbgFfjWvWthuCmvfhYlxnhKsd77oXJSZIZrl9AInT4OyZJ3mKYlphdi
zN7LbqCCjVUbKNY6hHdx yourname@xyzzyxxyz.jp

続いて、上で作成したSSH公開鍵をGitHubへ登録していきます。
  1. Webブラウザで自分のGitHubアカウントのDashboardページを開き、[Account settings]ボタンを押します。
    ASShot140104_0001-GitHub-Registering_SSH_Key-1020x828

  2. すると、下のようなページに変わります。
    ASShot140104_0002-GitHub-Registering_SSH_Key-1020x926
    左側の[SSH Keys]メニューを選択すると、下のようなページに変わります。
    ASShot140104_0003-GitHub-Registering_SSH_Key-1020x714

  3. 右側に存在する[Add SSH Key]をボタンを押すと、さらに下のようなページに変わります。
    ASShot140104_0004-GitHub-Registering_SSH_Key-1020x806
    作成済みのSSH公開鍵~/.ssh/github/id_rsa.pubの内容を[Key]エディットボックス内へコピべした上で([Title]エディットボックスの入力はオプション)、[Add key]ボタンを押します。

  4. パスワードの入力を求められので、GitHubアカウントの登録時に決めたパスワードを入力した上で、[Confirm password]ボタンを押します。
    ASShot140104_0007-GitHub-Registering_SSH_Key-1020x654
    下のようなページが表示されれば、SSH公開鍵の登録は完了です。
    ASShot140104_0008-GitHub-Registering_SSH_Key-1020x714

  5. MacからSSH経由で接続ができるか確認するため、下のコマンドを実行します。
    % ssh -T -i ~/.ssh/github/id_rsa git@github.com
    The authenticity of host 'github.com (192.30.252.130)' can't be established.
    RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of known hosts.
    Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.

    このコマンドの実行中に、下のようなウィンドウが表示されて、SSH秘密鍵id_rsaのパスワードを入力するように要求されます。
    SCShot140102_0021-GitHub-Registering_SSH_Key-444x251.png
    ここで入力すべきなのは、SSH鍵ペアを作成する際に設定したパスフレーズ(passphrase)です。このウィンドウの[パスワードをキーチェーンに保存]チェックボックスをONにしておきます。すると、この情報がキーチェーンに保存され、次回からGitHubへアクセスする際にSSH鍵パスフレーズの入力を省略できるようになります。

  6. sshコマンドは、デフォルトでは~/.ssh/id_rsaに存在するSSH秘密鍵を使います。上のとおり、「-i」オプションによってSSH秘密鍵ファイルのパスを指定することができますが、毎回このオプションを入力するのは面倒です。そこで、SSHのコンフィグレーションファイル~/.ssh/configに以下のような設定を追加します。
    % vi ~/.ssh/config
    Host github
    HostName github.com
    IdentityFile ~/.ssh/github/id_rsa

    これによって、GitHubに接続する際に、sshコマンドの「-i」オプションを省略できるようになります。下のコマンドを実行して、GitHubに接続できることを再度確認します。
    % ssh -T git@github.com
    Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.



■GitHubへのリポジトリ追加


これで準備が整って、やっとリポジトリが作成できるようになりました。GitHubに新しいリポジトリを追加していきます。
  1. GitHubアカウントのDashboardページを開き、[Create a new repo]ボタンを押します。
    ASShot140104_9001-GitHub-Registering_SSH_Key-1020x8284

  2. すると、下のようなページが開きます。このページの[Repository name]エディットボックスに新しく作成するリポジトリの名前を、[Description (optional)]にリポジトリの簡単な説明文を入力します([Description (optional)]はオプションですが、必ず入力しておいた方が良いでしょう)。
    ASShot140104_0018-GitHub-Creating_New_Repository-1020x654

  3. [Create repository]ボタンを押すと、新しいリポジトリが作成されて、下のようなページが開ます。
    ASShot140104_0014-GitHub-Creating_New_Repository-1020x776これで、GitHub上にdotfilesリポジトリが作成できました。

  4. これ以降、dotfilesのローカルリポジトリを作成していきます。最初に次の2つのコマンドを実行します。
    % git config --global user.name "YOUR NAME"
    % git config --global user.email "yourname@xyzzyxxyz.jp"

    これらのコマンドは、全ローカルリポジトリに適用するユーザー名とメールアドレスを設定しています。

  5. 続いて、dotfilesのローカルリポジトリ・ディレクトリに相当するディレクトリを作成し、その中に管理したいファイルをコピーします。
    % cd
    % mkdir -p github/dotfiles
    % mv .bash_profile github/dotfiles
    % mv .bashrc github/dotfiles
    % mv .zshrc github/dotfiles
    % mv .vimrc github/dotfiles
    % mv .gvimrc github/dotfiles
    % mv .vimrc.bundle github/dotfiles

    ~/github/dotfilesへ移動したファイルのシンボリックリンクをホームディレクトリ直下に作成しておきます。
    % ln -s github/dotfiles/.bash_profile ./
    % ln -s github/dotfiles/.bashrc ./
    % ln -s github/dotfiles/.zshrc ./
    % ln -s github/dotfiles/.vimrc ./
    % ln -s github/dotfiles/.gvimrc ./
    % ln -s github/dotfiles/.vimrc.bundle ./

  6. ローカルリポジトリを初期化して、~/github/dotfilesディレクトリ下の全ファイルを追加した後、コミットします。
    % cd github/dotfiles
    % git init
    Initialized empty Git repository in /Users/LOGINHOME/github/dotfiles/.git/
    % git add .
    % git commit -m "first commit"
    [master (root-commit) 53b8ced] first commit
    6 files changed, 325 insertions(+)
    create mode 100644 .bash_profile
    create mode 100644 .bashrc
    create mode 100644 .gvimrc
    create mode 100644 .vimrc
    create mode 100644 .vimrc.bundle
    create mode 100644 .zshrc

  7. 上のコマンドを実行しただけでは、ローカルリポジトリにしかコミット内容は保存されていません。コミット内容をリモートリポジトリへ反映させるには、下のコマンドを実行します。
    % git remote add origin git@github.com:GIT_USERNAME/dotfiles.git
    % git push -u origin master
    Counting objects: 8, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (7/7), done.
    Writing objects: 100% (8/8), 4.34 KiB | 0 bytes/s, done.
    Total 8 (delta 1), reused 0 (delta 0)
    To git@github.com:GIT_USERNAME/dotfiles.git
    * [new branch] master -> master
    Branch master set up to track remote branch master from origin.

    これで、ローカルリポジトリの全ファイルがリモートリポジトリへpushされました。

  8. WebブラウザでGitHubのdotfilesリポジトリを開くと、pushしたファイルが登録されていることが確認できます。
    ASShot140104_0015-GitHub-Creating_New_Repository-1020x832

上の操作を行った後GitHubのDashboardぺージを確認すると、アクティビティ情報が更新されていました。
ASShot140104_0016-GitHub-Creating_New_Repository-1020x821
「0」が3つ並んでいたのが恥ずかしかったので、やっとこれで一安心です。左側のソーシャル情報(followers, starred, following)にはまだ「0」が3つ並んでいます。こちらも早く数字を増やしていきたいです。

【参考ページ】

 GitHubの活用(アカウントの作成と設定) | UQ Times 開発の記録
 ナウなヤングのためのgithub入門講座 -基本機能からdotfiles管理まで- - 馬鹿と天才は紙一重

タグ:Github git dotfiles
posted by とみやん at 11:59| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2014年01月02日

GitHub始めました

皆様どのような正月をお過ごしでしょうか。一部の地域(北海道や東北の日本海側)は荒れた天気のようですが、穏やに晴れているところ所が多いようですね。信州も天候が安定しており、ここ数日晴天が続いています。年末年始の信州は天気が崩れて降雪が続くことが多いのですが、こんなに天候が安定しているのは珍しいです。冷え込みは厳しいですが、こう天気が良いとちゃんと防寒して出かけてみようかという気になりますね。まだ初詣を済ませていないので、今日か明日にでも近くの神社へ行こうかと思っています。

さて、今年二番目の記事を書きます。じつは、この年末年始の休暇中にぜひやろうと決めていたことがあります。それは、GitHubのアカウント登録です。

いまどきGitHubを知らないITエンジニアはまずいないでしょう。もしいたとしたら、そんな人はいますぐにプログラマを辞めるべきです。アマチュアならともかく、GitHubを知らないでプログラマという職業を名乗る資格はないからです。日本のITベンチャー企業でも、人材採用の応募者にGitHubアカウントの提示を求めるところが出てきているみたいですね。GitHub上のソースコードを観れば、応募者のプログラミングスキルは一目瞭然だからです。アメリカのITベンチャー企業ではこれはもはや常識になっていて、GitHubアカウントを持たない応募者は採用選考から外されてしまうくらいです。GitHubで公開しているソースコードがプログラマのスキル証明になる時代がすでに到来しているのです。

本ブログの記事にも頻繁にGitHubのリポジトリが登場しています。当然私もGitHubの存在は知っていました。メジャーなオープンソースプロジェクトは大抵GitHub上にリポジトリを作成していますが、大多数のユーザーは自作プログラムの保管場所としてGitHubを利用していることも知っていました。ただし、自分もアカウントを登録して、自作プログラムのソースを公開しようという気にはなかなかなれませんでした。公開できるような実用的なプログラムはまだ開発していないからです。しかし、エンジニアtypeに載っていた下の対談記事を読んで、そんな考え方は大きな誤りだということを知りました。

 小飼弾×増井雄一郎が大激論! 開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる? - エンジニアtype

この記事に登場した次の一言が、私にものすごいインパクトを与えました。

 「これからの時代、プログラマーをやりたい人にとって、GitHubアカウントを持たなくて済むのは小学生までとなるでしょう。」

これって下のように意訳できますよね。

 「いまどき、中・高校生のアマチュアプログラマでもGitHubアカウントを持っている」

JavaScript, Python, Rubyなどのスクリプト言語が普及したおかげで、ここ数年アマチュアプログラマの数が一気に増えました。ほとんどの中・高校生はPCを持っていますし、電子工作ブームも続いています。休日などの空き時間を利用してプログラム開発に取り組むアマチュアプログラマは増える一方です。ニコニコ動画には「ニコニコ技術部」「ニコニコ工作部」というタグがあって、アマチュアプログラマや電子工作愛好家などの作品の発表の場になっています。悪ふざけ的な作品も多いですが、その中には思わず「これはスゲー」と唸ってしまうような作品もあります。いまやニコニコ動画の一大ジャンルなってしまったMikuMikuDance(MMDはアニメ制作会社でも使われているらしいです)の開発者である樋口優氏も自称アマチュアプログラマです。そして、そんなアマチュアプログラマが開発したソフトウェアがNASAに採用されるなんて事例も起きています。

 アマチュアプログラマ柏井勇魚氏の作品がNASAの管制に採用された! - Togetterまとめ

もはやアマチュアとプロの間に大きな差などなくなってきているのではないかと思わせるくらい、プログラミングの裾野は大きく拡がっています(志の低いプロが作ったものより、特定の分野を極めたオタクなアマチュアが作ったブログラムの方が出来が良かったりします)。

「学生のアマチュアプログラマが公開できるようなプログラムをバリバリ書いているんだろうか」という疑問を持つ人もいるでしょう。その疑問はもっともです。じつは、学生のアマチュアプログラマがGitHubに置いているのは学校のカリキュラムやクラブ活動などで作った小さなプログラムが多いようです。GitHubはそんなレベルの使い方で十分であって、別にかしこまる必要なんか無いんだと思います。「どんなものでも良いので自分が書いたコードを誰かに観てもらう」それがコミニュケーションの出発点になるんですね。SourceForge.netのような単なるリポジトリサービスではなく、「GitHubはプログラマのためのソーシャルサービス」と考えるべきなんだということがやっと解ってきました。

一昨年の3月のニュースになってしまいますが、GitHubに絡んで下のようなニュースが話題になりました。

 踊るPerfumeのモーションキャプチャデータ公開 GitHubに「perfume-dev」ページ - ITmedia ニュース

GitHubがソーシャルサービスとして各方面から大きな注目を集めていることは、このような動きからも判ります。また、面白い話題としては下のようなニュースもあります(このニュースに掲載されているGitHubのページは現時点でまだ存在しています。条件のハードルが結構高い気がしますが、彼女が欲しい方、応募してみてはいかがでしょう)。

 githubで彼氏を募集されてる方がいらっしゃいます : ギズモード・ジャパン

GitHubは2008年にサービスが開始されたGitリポジトリを中心とした開発支援環境です。Facebookの公開は2004年、Twitterの公開は2006年なので比較的新しいサービスだと言えるでしょう。これらのソーシャルメディアの影響を受けて、現在のGitHubには、ユーザーがアバター(Gravatar)を設定できたり、他のユーザーやリポジトリをフォロー(Follow)できる機能などが追加されています。Subversionに換わるバージョン管理システムとしてGitへの注目が高まるのと相まって、ここ1〜2年ほどの間にGitHubは急激に注目されてきています。


今回私が作成したGitHubのアカウントは無料のFreeプランです。Freeプランは非公開リポジトリを作成することはできず、ユーザーが作成したリポジトリはすべて公開扱いになります。下が私のGitHubアドレスです。

 https://github.com/tomyyann

ASShot140102_9014-GitHub_My_Dashboard-tomyyann-1204x828
まだGravatarの登録も行っていおらず、寂しいプロフィール/アクティビティ画像ですね。「0」が3つ並んでいるのが何とも言えない気分です。このままでは寂しすぎるので、これからアバターを登録したり、誰かをフォローしたり、リポジトリを作成したりしていきます。GitHubアカウントを持っている方。もし良かったらフォローしてください。

いまのところリポジトリはまだ一つも作成していません。取りあえず、一番最初に作るリポジトリはdotfilesにするつもりです。.bashrc.vimrcなどのホームディレクトリに存在する「.」で始まるファイル群をGitHubで管理するのが流行りらしく、dotfilesというのはそれらのファイルを格納しておくリポジトリです。私もMacとLinuxの両方の環境を使いますし、さくらのVPSを利用したクラウドPCはUbuntu Linuxで作成しています。これらの環境のドットファイル群をGitHubで一元的に管理するのは良いアイデアだと思います。

いま勉強中のiOSアプリのサンプルプログラムやこれから開発するつもりのNode.jsベースの試作WebサービスのソースなどもすべてGitHubに置いてしまおうと思っています。GitHubで公開するプログラムは別に実用的である必要はないんです。プライベートなプログラムコードの置き場がたまたま公開の場所だったと思って利用していきます。こういう軽いノリでGitHubを利用しているユーザーは結構多いみたいです。TwitterやFacebookみたいなソーシャルサービスはこういう軽いノリで利用すべきものでしょう。GitHubもソーシャルサービスなんですから。

私はいままでTwitterやFacebookのようなソーシャルサービスはまったく利用していませんでしたが、GitHubでソーシャル・デビューしたのを機会に、こういうサービスに対する興味が湧いてきました。上で引用した対談記事の中に登場した次の一言もインパクトがあったからです。

 これからは「人が見えるところで遊ぶ」ことが一流になる近道に

いままでブログ記事に自分の活動記録を書いてきましたが、最近「ブログって人が見える場所なのか」という疑問を持っていました。毎日アクセス解析情報をチェックしていますが、本サイトの一日の訪問者は平均500人程度です。これってやっぱり「人が見える場所」ではないよなぁと思ってしまいます。観てくれている人数が最低でも千できたら万の単位に届かないと、とても「人が見える場所」とは言えないですよね。この単位の観客が常にいて気軽に参加できる場所がどこにあるのかと言えば、やはりいまはソーシャルメディア上にしか存在しないと思います。

ちなみに、私がいままでTwitterとFacebookに興味が持てなかったのは、どちらのメディアも私に合っていないような気がしていたからです。Twitterは主に10代後半〜20代前半の若者がコミュケーションツールとして利用しており、Facebookはいままさに「若者離れ」が進行中で、30〜40代(特に高所得層)のリア充生活自慢が目立つメディアへと変わりつつあると思っていました。これらのイメージは多分それ程大きく外れていないでしょう。これらの年代やユーザー層のどちらにも私は属していません。私のような50代でITリテラシーはそこそこ高いが裕福な生活はしていないエンジニアが、たくさん集まっているソーシャルメディアはいまのところ存在していないように思えます。こういうユーザー層はマイナーな存在なので仕方がないことだとは思いますが・・・。このような理由により、TwitterとFacebookに対してはいまいち積極的に使ってみたいという意欲が湧いてきません。TwitterとFacebookを始めるかどうかについてはもう少し考えてから決めようと思っています。私の趣味や志向と合いそうなソーシャルメディアが見つかれば、積極的に参加したいという気持ちは持っているんですが・・・。

【参考ページ】

 ユーザ数400万に達したGitHubが「コラボレーションサービスの百貨店」になることで未来の成長を目指す | TechCrunch Japan
 ユカイ、ツーカイ、カイハツ環境!(29):GitHubはリアルRPG? そして、ソーシャルコーディングへ (1/3) - @IT
 そもそもGitHubとは一体何か? | TechCrunch Japan

タグ:Github git
posted by とみやん at 16:27| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年12月14日

NeoBundleによるVimへのプラグイン導入

プログラミングエディタをMacVimに換えてしばらく経つが、.vimrc内に基本的なVimの動作モードやカラースキームなどの設定項目を追加しただけで、いままではほとんど素の状態でVimを使っていた。MacVimを使い始めたときからVimには多くのプラグインが存在していることは知っていた。これらのプラグインを導入すると、Vimが格段に使い易くなることも。毎日Vimを使っているので、大分その操作感に慣れてきた。MacVimを入れる前からLinux環境でずっとVimを使っていたし、私がITの仕事を始めたマイコン創世期時代にはVimのようなモード切替とコマンド入力で操作するエディタが主流だったので馴染みもある。いまやVimは毎日使うツールの一つになっているので、そろそろVimへプラグインを導入して環境整備を始めることにした。

Vimへプラグインを導入するには、プラグインのファイル一式を~/.vimディレクトリに置くだけだ。プラグインを一つずつ入れていっても良いが、世の中には膨大な数のVimプラグインが存在するので、これを手動でやっていくは結構大変な作業になる。そのため、最初にVimプラグインを管理してくれるプラグインをインストールしておいて、他のプラグインはそれを使って導入していくのが最近の主流のやり方のようだ。Vimのプラグイン管理モジュールにはいくつかの種類が存在するが、現在もっとも広く使われているのはNeoBundleというものらしい。

■ NeoBundleのインストール


Vimへのプラグインを導入するにあたって、まずはNeoBundleのインストールから始めた。以下のコマンドを実行すれば、VimへNeoBundleをインストールすることができる。
% mkdir -p ~/.vim/bundle
% git clone git://github.com/Shougo/neobundle.vim ~/.vim/bundle/neobundle.vim


■ NeoBundleによるプクラグインの導入


NeoBundleを使ってプラグインを導入する方法は簡単で、インストールしたいプラグインを~/.vimrc内に記述すれば良いだけだ。しかし、.vimrcにNeoBundleの設定記述を書くと、どんどん長くなって読み難くなってしまうんじゃないかという気がした。これからVimへたくさんのプラグインを追加していくことになりそうだからだ。そこで、~/.vimrc.bundleという別のファイルを作成してNeoBundleの設定内容はすべてこちらへ書くことにした。この方針に従って、まずは.vimrcの先頭に次のような記述を追加した。
" NeoBundleで管理してるプラグインを読み込む
source ~/.vimrc.bundle

そして、以下の内容で.vimrc.bundleを作成した。
" NeoBundle の設定

set nocompatible " Be iMproved

filetype off

if has('vim_starting')
set runtimepath+=~/.vim/bundle/neobundle.vim/
endif

call neobundle#rc(expand('~/.vim/bundle/'))

" Let NeoBundle manage NeoBundle
NeoBundleFetch 'Shougo/neobundle.vim'

" Recommended to install
NeoBundle 'Shougo/vimproc'

" My Bundles here:
"
" Original repos on github
NeoBundle 'Shougo/neocomplcache'
NeoBundle 'Shougo/neosnippet'
NeoBundle 'Shougo/vimshell'
NeoBundle 'Shougo/unite.vim'
NeoBundle 'tpope/vim-surround'
NeoBundle 'scrooloose/syntastic'
NeoBundle 'scrooloose/nerdtree'
NeoBundle 'altercation/vim-colors-solarized'
" vim-scripts repos
" Non github repos
" Non git repos

filetype plugin indent on " Required!

" Installation check.
NeoBundleCheck

これでNeoBundle環境の設定は作成できた。さっそくVimを起動してみた。すると、下のようなメッセージが表示された。
% vim
Not installed bundles: ['vimproc', 'neocomplcache', 'syntastic', 'neosnippet', 'vim-surround', 'vimshell', 'unite.vim', 'vim-colors-solarized', 'nerdtree']
Install bundles now?
(y)es, [N]o: n

このメッセージに対して「y」を入力すれば、この時点ですべてのプラグインのインストールが行われるのだろう。しかし、ここでは「n」を入力しておいた。

そして、起動したVimの中から次のコマンドを実行した。
:NeoBundleInstall

これで、すべてのプラグインがインストールされるはずだ。実際に、Vimのコマンドライン上にプラグインのインストール処理の進行状況が表示されていた。

プラグインのインストールが完了したので、一旦Vimを終了させた。その後、以下の操作を行った。
% cd ~/.vim/bundle/vimproc
% make
make -f make_mac.mak
clang -O2 -W -Wall -Wno-unused -Wno-unused-parameter -bundle -fPIC -arch i386 -arch x86_64 -o autoload/vimproc_mac.so autoload/proc.c

vimprocはVimの中で非同期処理を実行するプラグインだが、このプラグインはOS環境に依存するので、C言語のソースで配布されている。上のとおり、NeoBundleで導入した後にビルドしてやないと、vimprocは動いてくれない。

ちなみに、今回私がVimへ導入したプラグインは以下のとおり。
 Shougo/vimproc                   Vimから非同期処理を実行する
 Shougo/neocomplcache  自動入力補完機能を提供する
 Shougo/neosnippet  スニペット入力補完機能を提供する
 Shougo/vimshell  Vimの中からシェルを起動する(vimprocを使用)
 Shougo/unite.vim  統合ユーザインターフェースを提供する
 tpope/vim-surround  ()や "" で囲まれたテキストの編集補助
 scrooloose/syntastic  言語ソースコードの構文チェックをする
 scrooloose/nerdtree  NERDTree(エクスプローラ風ファイラー)
 altercation/vim-colors-solarized Solarizedカラースキーム

Vimのプラグインについてググってみると判るが、これらはいずれも有名で広く使われているものばかり。他にも多種多様なVimプラグインが存在するので、どんな機能のものがあるかのか探し始めると切りがない。これから少しずつ追加することにして、取りあえず、最初に入れておくのはこんなところだろうか。

なお、NeoBundleではVimのカラースキーム(カラースキームはプラグインの一種)も導入することも可能だ。~/.vim/colorsにカラースキームのファイルを置くことで、すでにSolarizedは手動で導入済みだったが、このディレクトリは削除した。今後VimのカラースキームはNeoBundleで管理していくことにしたからだ。

■ unite.vmプラグインの設定


以上でNeoBundleによるVimプラグインの導入作業は終了だが、大抵のVimプラグインは固有の設定項目を持っており、それらの設定値を変更することで、プラグインの動作をカスタマイズすることが可能だ。

今回導入したVimプラグインの中から、unite.vmのgrep機能をThe Silver Searcherに置き換える設定を行った。unite.vimというのはVim用の統合ユーザインターフェースで、様々なデータを共通のインタフェースを用いて操作できようにするプラグイン。そして、The Silver Searcherはgrepやackに換わる超高速なコード検索ツールだ。開発者によると、The Silver Searcherはackより3〜5倍速く検索処理を実行できるそうだ。

The Silver SearcherはHomebrewのフォーミュラとして登録されたので、以下のコマンドでサクッとインストールした(依存フォーミュラのautoconfとautomakeも一緒にインストールされた)。
% brew install the_silver_searcher
==> Installing dependencies for the_silver_searcher: autoconf, automake
==> Installing the_silver_searcher dependency: autoconf
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/autoconf-2.69.lion.bottle.tar.gz
######################################################################## 100.0%
==> Pouring autoconf-2.69.lion.bottle.tar.gz
/usr/local/Cellar/autoconf/2.69: 69 files, 2.0M
==> Installing the_silver_searcher dependency: automake
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/automake-1.14.lion.bottle.tar.gz
######################################################################## 100.0%
Press ENTER or type command to continue
==> Pouring automake-1.14.lion.bottle.tar.gz
/usr/local/Cellar/automake/1.14: 127 files, 2.5M
==> Installing the_silver_searcher
==> Downloading https://github.com/ggreer/the_silver_searcher/archive/0.18.1.tar.gz
######################################################################## 100.0%
==> aclocal -I /usr/local/share/aclocal
==> autoconf
==> autoheader
==> automake --add-missing
==> ./configure --prefix=/usr/local/Cellar/the_silver_searcher/0.18.1
==> make
==> make install
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Summary
/usr/local/Cellar/the_silver_searcher/0.18.1: 8 files, 108K, built in 11 seconds

The Silver Searcherの実体はagという名前のコマンドで、下のような豊富なオプションを持っている。ackと同様に、agはソースコードの検索に適したオプションを備えている。
% ag

Usage: ag [OPTIONS] PATTERN [PATH]

Recursively search for PATTERN in PATH.
Like grep or ack, but faster.

Example:
ag -i foo /bar/

Output Options:
--ackmate Print results in AckMate-parseable format
-A --after [LINES] Print lines before match (Default: 2)
-B --before [LINES] Print lines after match (Default: 2)
--[no]break Print newlines between matches in different files
(Enabled by default)
--[no]color Print color codes in results (Enabled by default)
--color-line-number Color codes for line numbers (Default: 1;33)
--color-match Color codes for result match numbers (Default: 30;43)
--color-path Color codes for path names (Default: 1;32)
--column Print column numbers in results
--[no]heading
--line-numbers Print line numbers even for streams
-C --context [LINES] Print lines before and after matches (Default: 2)
--[no]group Same as --[no]break --[no]heading
-g PATTERN Print filenames matching PATTERN
-l --files-with-matches Only print filenames that contain matches
(don't print the matching lines)
-L --files-without-matches
Only print filenames that don't contain matches
--no-numbers Don't print line numbers
--print-long-lines Print matches on very long lines (Default: >2k characters)
--stats Print stats (files scanned, time taken, etc.)

Search Options:
-a --all-types Search all files (doesn't include hidden files
or patterns from ignore files)
-D --debug Ridiculous debugging (probably not useful)
--depth NUM Search up to NUM directories deep (Default: 25)
-f --follow Follow symlinks
-G --file-search-regex PATTERN Limit search to filenames matching PATTERN
--hidden Search hidden files (obeys .*ignore files)
-i --ignore-case Match case insensitively
--ignore PATTERN Ignore files/directories matching PATTERN
(literal file/directory names also allowed)
--ignore-dir NAME Alias for --ignore for compatibility with ack.
-m --max-count NUM Skip the rest of a file after NUM matches (Default: 10,000)
-p --path-to-agignore STRING
Use .agignore file at STRING
-Q --literal Don't parse PATTERN as a regular expression
-s --case-sensitive Match case sensitively (Enabled by default)
-S --smart-case Match case insensitively unless PATTERN contains
uppercase characters
--search-binary Search binary files for matches
-t --all-text Search all text files (doesn't include hidden files)
-u --unrestricted Search all files (ignore .agignore, .gitignore, etc.;
searches binary and hidden files as well)
-U --skip-vcs-ignores Ignore VCS ignore files
(.gitignore, .hgignore, .svnignore; still obey .agignore)
-v --invert-match
-w --word-regexp Only match whole words
-z --search-zip Search contents of compressed (e.g., gzip) files


The Silver Searcher(ag)がインストールできので、unite.vmのgrep検索にagを使う設定を.vimrcへ追加した(これは参考ページCに載っていた設定で、そのまま使わせてもらった)。
" unite.vmの設定
" insert modeで開始
let g:unite_enable_start_insert = 1
" 大文字小文字を区別しない
let g:unite_enable_ignore_case = 1
let g:unite_enable_smart_case = 1
" grep検索
nnoremap <silent> ,g :<C-u>Unite grep:. -buffer-name=search-buffer<CR>
" カーソル位置の単語をgrep検索
nnoremap <silent> ,cg :<C-u>Unite grep:. -buffer-name=search-buffer<CR><C-R><C-W>
" grep検索結果の再呼出
nnoremap <silent> ,r :<C-u>UniteResume search-buffer<CR>
" unite grep に ag (The Silver Searcher) を使う
if executable('ag')
let g:unite_source_grep_command = 'ag'
let g:unite_source_grep_default_opts = '--nogroup --nocolor --column'
let g:unite_source_grep_recursive_opt = ''
endif

上のunite.vm設定でのUnite grep検索の使い方は参考ページCに詳しく載っているので、本記事では省略する。

■ NERDTreeプラグインの設定


今回導入したプラグインの中でNERDTreeも豊富な機能を持つものだ。NERDTreeはVimにエクスプローラ風のファイラ機能を追加するプラグインで、一度使い始めるとこれなしではVimを使う気に慣れないほど便利な奴らしい。Vimのコマンドラインに「:NERDTree」と入力すれば、NERDTreeが起動する。
Vim-Plugin-NERDTree-SCShot13121616-745x676
NERDTreeを起動すると上のような分割画面になり、NERDTree画面内でカーソルによってVimで開くファイルを選択することができる。
Vim-Plugin-NERDTree-SCShot13121618-745x676
また、NERDTree画面がアクティブな状態(カーソルが画面内に存在する状態)で「?」キーをタイプすると、NERDTreeのヘルプ画面が表示される。
Vim-Plugin-NERDTree-SCShot13121617-745x676
NERDTreeの操作方法を忘れてしまっても、このヘルプ画面を見れば思い出すことができるだろう。

上記のようなコマンドを毎回入力するのは面倒なので、NERDTree画面の開閉を行うキーマッピング設定を~/.vimrcに追加した(これは参考ページDに載っていた設定を若干変更したもの)。
" <C-e>でNERDTreeをオンオフ いつでもどこでも
nmap <silent> <C-e> :NERDTreeToggle<CR>
vmap <silent> <C-e> <Esc>:NERDTreeToggle<CR>
omap <silent> <C-e> :NERDTreeToggle<CR>
imap <silent> <C-e> <Esc>:NERDTreeToggle<CR>
cmap <silent> <C-e> <C-u>:NERDTreeToggle<CR>
" 引数なしでvimを開いたらNERDTreeを起動、
" 引数ありならNERDTreeは起動しない、引数で渡されたファイルを開く
autocmd vimenter * if !argc() | NERDTree | endif
" 他のバッファをすべて閉じた時にNERDTreeが開いていたらNERDTreeも一緒に閉じる
autocmd bufenter * if (winnr("$") == 1 && exists("b:NERDTreeType") && b:NERDTreeType == "primary") | q | endif
" 無視するファイルを設定する
let g:NERDTreeIgnore=['\.clean$', '\.swp$', '\.bak$', '\~$']
" 隠しファイルを表示するか
let g:NERDTreeShowHidden=0
" ブックマークやヘルプのショートカットをメニューに表示する
let g:NERDTreeMinimalUI=1
" +|`などを使ってツリー表示をするか
" 0 : 綺麗に見せる
" 1 : +|`などを使わない
let g:NERDTreeDirArrows=1
" マウス操作方法
" 1 : ファイル、ディレクトリ両方共ダブルクリックで開く
" 2 : ディレクトリのみシングルクリックで開く
" 3 : ファイル、ディレクトリ両方共シングルクリックで開く
let g:NERDTreeMouseMode=2

上の設定によって、「Ctrl-e」によってNERDTree画面の開閉ができるようになる。

さらに、NERDTreeにgrep検索機能を追加した。NERDTreeもプラグインを追加できるようになっていて、~/.vim/bundle/nerdtree/nerdtree_pluginへプラグインのファイルを置くことで、新しい機能を追加できる。下のベージに載っていたNERDTree用のgrep検索プラグインを利用させてもらった。

 NerdTreePluginのgrep_menuitem.vimって便利だけど実行後にこっそりカレントディレクトリが変更されてしまってる。。 スペースなどが入った場合もそのまま検索できるようにしたかった。 なので少し付け加え。 Forked from https://gist.github.com/masaakif/414375

具体的には、以下の操作を行って、上のプラグインをNERDTreeへ追加した。
% wget https://gist.github.com/inagaa/5141204/download
% mv download gist-5141204.tar.gz
% tar zxf gist-5141204.tar.gz
% cp -p gist5141204-d427f0f2699bc4713e75ca0e34963c617a668188/grep_menuitem.vim ~/.vim/bundle/nerdtree/nerdtree_plugin

NERDTree画面がアクティブな状態で「m」キーをタイプすると、VimのコマンドラインにNERDTreeのメニュー一覧が表示されるが、上のプラグインを追加すると、下のような「(g)rep directory」という項目がメニューに追加される。
Vim-Plugin-NERDTree-SCShot13121620-745x676
このメニュー項目を選択すると、NERDTree画面のカーソルで指定したディレクトリに対してgrep検索を実行することができる。

【参考ページ】

  1. ○○○○に怖いものなんてない!!: VimをNeobundleでプラグイン管理
  2. agとUnite.vimで快適高速grep環境を手に入れる - Thinking-megane
  3. ackを捨てて、より高速なag(The Silver Searcher)に切り替えた - Glide Note - グライドノート
  4. 英語&英会話学習SNS開発記録 : vimプラグインのNERDTreeを自分好みにカスタマイズ。
  5. にゃほ〜 - NERDTreeでgrep検索


タグ:vim NeoBundle
posted by とみやん at 12:20| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年12月09日

[Homebrew] NumPy 1.8.0へOpenBLASを組込む方法

前記事を書くにあたって、GitHubのsamueljohn/pythonリポジトリのIssuesリストを眺めていたら、下のようなエントリが登録されているのを見つけた。

 numpy with openblas ・ Issue #64 ・ samueljohn/homebrew-python ・ GitHub

このページに情報によると、「--with-openblas」オプションを指定しても、NumPy 1.8.0ではOpenBLASが組み込まれないそうだ。本当にそのとおりなのか検証してみた。

まずは、「--with-openblas」オプションつきでnumpyフォーミュラをインストールして、numpyライブラリの「show_config()」関数を実行したみた。
% python
Python 2.7.5 (default, Aug 17 2013, 09:42:02)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.show_config()
atlas_threads_info:
NOT AVAILABLE
blas_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
define_macros = [('NO_ATLAS_INFO', 3)]
atlas_blas_threads_info:
NOT AVAILABLE
openblas_info:
NOT AVAILABLE
lapack_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3']
define_macros = [('NO_ATLAS_INFO', 3)]
atlas_info:
NOT AVAILABLE
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
atlas_blas_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
>>>

やはりOpenBLASは組み込まれてないようだ。

続いて、上のIssuesページに書かれている内容に従って、NumPyのフォーミュラ定義ファイル(/usr/local/Library/Taps/samueljohn-python/numpy.rb)に下のような変更を加えた(フォーミュラ定義ファイルの内容は随時更新されているので、修正後のnumpy.rbも掲載しておく)。
--- numpy.rb.orig	2013-12-06 13:14:00.000000000 +0900
+++ numpy.rb 2013-12-07 15:42:26.000000000 +0900
@@ -52,13 +52,10 @@
ENV['ATLAS'] = "None"
ENV['BLAS'] = ENV['LAPACK'] = "#{openblas_dir}/lib/libopenblas.dylib"

+ #! Renames the [blas_opt] section of the site.cfg to [openblas] and removes the [lapack_opt] section
+ #! See https://github.com/samueljohn/homebrew-python/issues/64
config << <<-EOS.undent
- [blas_opt]
- libraries = openblas
- library_dirs = #{openblas_dir}/lib
- include_dirs = #{openblas_dir}/include
-
- [lapack_opt]
+ [openblas]
libraries = openblas
library_dirs = #{openblas_dir}/lib
include_dirs = #{openblas_dir}/include

require 'formula'

class NoUserConfig < Requirement
def satisfied?
not File.exist? "#{ENV['HOME']}/.numpy-site.cfg"
end

def message; <<-EOS.undent
A ~/.numpy-site.cfg has been detected, which may interfere with our business.
EOS
end
end

class Numpy < Formula
homepage 'http://www.numpy.org'
url 'http://downloads.sourceforge.net/project/numpy/NumPy/1.8.0/numpy-1.8.0.tar.gz'
sha1 'a2c02c5fb2ab8cf630982cddc6821e74f5769974'
head 'https://github.com/numpy/numpy.git'

depends_on :python => :recommended
depends_on :python3 => :optional
depends_on :python => 'nose'
depends_on :python3 => 'nose' if build.with? 'python3'
depends_on :fortran
depends_on NoUserConfig
depends_on 'homebrew/science/suite-sparse' # for libamd and libumfpack

option 'with-openblas', "Use openBLAS (slower for LAPACK functions) instead of Apple's Accelerate Framework"
depends_on "homebrew/science/openblas" => :optional

def install
# Numpy is configured via a site.cfg and we want to use some libs
# For maintainers:
# Check which BLAS/LAPACK numpy actually uses via:
# xcrun otool -L /usr/local/Cellar/numpy/1.6.2/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so
config = <<-EOS.undent
[DEFAULT]
library_dirs = #{HOMEBREW_PREFIX}/lib
include_dirs = #{HOMEBREW_PREFIX}/include

[amd]
amd_libs = amd, cholmod, colamd, ccolamd, camd, suitesparseconfig
[umfpack]
umfpack_libs = umfpack

EOS

if build.with? 'openblas'
openblas_dir = Formula.factory('openblas').opt_prefix
# Setting ATLAS to None is important to prevent numpy from always
# linking against Accelerate.framework.
ENV['ATLAS'] = "None"
ENV['BLAS'] = ENV['LAPACK'] = "#{openblas_dir}/lib/libopenblas.dylib"

#! Renames the [blas_opt] section of the site.cfg to [openblas] and removes the [lapack_opt] section
#! See https://github.com/samueljohn/homebrew-python/issues/64
config << <<-EOS.undent
[openblas]
libraries = openblas
library_dirs = #{openblas_dir}/lib
include_dirs = #{openblas_dir}/include
EOS
end

rm_f 'site.cfg' if build.devel?
Pathname('site.cfg').write config

python do
# Numpy ignores FC and FCFLAGS, but we declare fortran so Homebrew knows
# gfortran is gnu95
system python, "setup.py", "build", "--fcompiler=gnu95", "install", "--prefix=#{prefix}"
end
end

def test
python do
system python, "-c", "import numpy; numpy.test()"
end
end

def caveats
s = "Numpy ignores the `FC` env var and looks for gfortran during build.\n"
s += python.standard_caveats if python
end
end

その上で、一旦numpyフォーミュラをアンイストールして、再度「--with-openblas」オプションつきでインストールし直した。

その結果、numpyライブラリの「show_config()」関数の表示は下のように変わった。
% python
Python 2.7.5 (default, Aug 17 2013, 09:42:02)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.show_config()
blas_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
lapack_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
atlas_threads_info:
NOT AVAILABLE
blas_opt_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_blas_threads_info:
NOT AVAILABLE
lapack_opt_info:
libraries = ['openblas', 'openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_info:
NOT AVAILABLE
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
atlas_blas_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
>>>

今度はちゃんとOpenBLASが組み込まれている。

どうやら、NumPy 1.8.0においてsite.cfg内のライブラリセクションの参照方法が変更されたことが、この問題の原因らしい。NumPyのGitHubサイトのIssuesリストにも下のようなエントリが登録されている。

ちなみに、Mac OS X環境では、OpenBLASよりApple Accelerate Framework(デフォルトでリンクされる演算ライブラリ)を使った方がNumPyの計算処理はずっと高速だ(08/10の記事を参照)。したがって、私はOpenBLASを無効にしてNumPyをインストールしている。
タグ:Homebrew NumPy
posted by とみやん at 10:46| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年12月08日

[Homebrew] Pillow 2.1.0のインストール時にコンパイルエラー

08/11の記事にHomebrewによるOpenCV + Python開発環境の構築方法について書いたが、あれから4ヶ月経って、Pythonのバーションは2.7.6になり前回インストールしたライブラリもすべてバージョンアップされている。しばらくPythonに触れていなかったんだけど、最近またPythonへの興味がフツフツと蘇ってきた。モチベーションが上がっているうちに、もう一度本格的にPythonプログラミングに取り組もうと思って、Python開発環境の更新作業を始めた。

HomebrewによってインストールしたPython本体とsamueljohn/pythonリポジトリ経由で追加したNumPy, ScipPy, matplotlibライブラリのバージョンアップは問題なくできんだけど、Pillowの更新をやろうとしたら、以下のようなコンパイルエラーに遭遇してしまった。
% brew upgrade pillow
==> Upgrading pillow
==> Downloading https://github.com/python-imaging/Pillow/archive/2.1.0.tar.gz
######################################################################## 100.0%
==> /usr/local/opt/python/bin/python2 setup.py install --prefix=/usr/local/Cellar/pillow/2.1.0 --record=installed.txt --single-version-externally-managed
_imagingft.c:62:10: fatal error: 'freetype/fterrors.h' file not found
#include <freetype/fterrors.h>
^
1 error generated.
error: command 'clang' failed with exit status 1

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
If reporting this issue please do so at (not mxcl/homebrew):
https://github.com/samueljohn/homebrew-python/issues


上の現象についてググると、Pillowとsamueljohn/pythonのGitHubサイトにこの問題がIssues情報として登録されているのを見つけた。

FreeTypeのバージョンアップも同時にやったんだけど、どうやらFreeType 2.5.1でヘッダファイルのディレクトリ構成が変更されたことがこの問題の原因らしい。この問題を解決するためのパッチコードもPillowのサイトに掲載されていた。

 fix compiling with FreeType 2.5.1 ・ c6040f6 ・ python-imaging/Pillow ・ GitHub

このパッチを適用すれば、Pillow 2.1.0とFreeType 2.5.1の組み合わせでもビルドは通るはずなので、Pillowのフォーミュラ定義ファイル(/usr/local/Library/Taps/samueljohn-python/pillow.rb)に以下のような変更を加えた(フォーミュラ定義ファイルの内容は随時更新されているので、修正後の pillow.rb も掲載しておく)。
--- pillow.rb.orig	2013-12-06 13:14:00.000000000 +0900
+++ pillow.rb 2013-12-07 16:49:16.000000000 +0900
@@ -14,6 +14,12 @@
depends_on 'jpeg'
depends_on 'libtiff'

+ def patches
+ #! Fixes compiling failure with FreeType 2.5.1
+ #! See https://github.com/samueljohn/homebrew-python/issues/63
+ DATA
+ end
+
def install
# Help pillow find zlib and little-cms (Note freetype2 is detected correctly)
inreplace "setup.py" do |s|
@@ -47,3 +53,19 @@
end
end
end
+
+__END__
+--- Pillow-2.1.0.orig/_imagingft.c 2013-07-02 21:52:49.000000000 +0900
++++ Pillow-2.1.0/_imagingft.c 2013-12-07 14:41:54.000000000 +0900
+@@ -59,7 +59,11 @@
+ const char* message;
+ } ft_errors[] =
+
++#if defined(USE_FREETYPE_2_1)
++#include FT_ERRORS_H
++#else
+ #include <freetype/fterrors.h>
++#endif
+
+ /* -------------------------------------------------------------------- */
+ /* font objects */

require 'formula'

class Pillow < Formula
homepage 'https://github.com/python-imaging/Pillow'
url 'https://github.com/python-imaging/Pillow/archive/2.1.0.tar.gz'
sha1 'e948dbfd4902de3dbf8bbc9556033f76ce906a7f'
head 'https://github.com/python-imaging/Pillow.git'

depends_on :python => :recommended
depends_on :python3 => :optional
depends_on 'little-cms'
depends_on 'graphicsmagick'
depends_on 'freetype'
depends_on 'jpeg'
depends_on 'libtiff'

def patches
#! Fixes compiling failure with FreeType 2.5.1
#! See https://github.com/samueljohn/homebrew-python/issues/63
DATA
end

def install
# Help pillow find zlib and little-cms (Note freetype2 is detected correctly)
inreplace "setup.py" do |s|
s.gsub! "ZLIB_ROOT = None", "ZLIB_ROOT = ('#{MacOS.sdk_path}/usr/lib', '#{MacOS.sdk_path}/usr/include')" unless MacOS::CLT.installed?
s.gsub! "LCMS_ROOT = None", "LCMS_ROOT = ('#{Formula.factory('littlecms').opt_prefix}/lib', '#{Formula.factory('littlecms').opt_prefix}/include')"
s.gsub! "JPEG_ROOT = None", "JPEG_ROOT = ('#{Formula.factory('jpeg').opt_prefix}/lib', '#{Formula.factory('jpeg').opt_prefix}/include')"
s.gsub! "TIFF_ROOT = None", "TIFF_ROOT = ('#{Formula.factory('libtiff').opt_prefix}/lib', '#{Formula.factory('libtiff').opt_prefix}/include')"
s.gsub! "FREETYPE_ROOT = None", "FREETYPE_ROOT = ('#{Formula.factory('freetype').opt_prefix}/lib', '#{Formula.factory('freetype').opt_prefix}/include')"
end

python do
system python, "setup.py", "install", "--prefix=#{prefix}", "--record=installed.txt", "--single-version-externally-managed"
# For python3 we append -py3 to the executable scripts:
if python3
[ "pilconvert", "pildriver", "pilfile", "pilfont", "pilprint" ].each do |f|
bin.install "build/scripts-#{python.version.major}.#{python.version.minor}/#{f}.py" => "#{f}-py3.py"
end
end
end

end

def caveats
python.standard_caveats if python
end

def test
python do
# Only a small test until https://github.com/python-imaging/Pillow/issues/17
system "python", "-c", "import PIL.Image"
end
end
end

__END__
--- Pillow-2.1.0.orig/_imagingft.c 2013-07-02 21:52:49.000000000 +0900
+++ Pillow-2.1.0/_imagingft.c 2013-12-07 14:41:54.000000000 +0900
@@ -59,7 +59,11 @@
const char* message;
} ft_errors[] =

+#if defined(USE_FREETYPE_2_1)
+#include FT_ERRORS_H
+#else
#include <freetype/fterrors.h>
+#endif

/* -------------------------------------------------------------------- */
/* font objects */

その上で再度「brew upgrade pillow」を実行したら、今度はpillowフォーミュラのビルドが通ってバージョンアップが成功した。

すでにPillowとsamueljohn/pythonの両方サイトでIssues情報として上がっているので、本問題への対応は近日中実施されるのではないかと思われる。上記のpillow.rbに対する修正はそれまでの暫定的な対策となるだろう。
タグ:Homebrew Pillow
posted by とみやん at 16:29| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年12月03日

Xcode 5.0.2のMountain Lionへの共存インストール

去年の9月にiOS 7がリリースされ、同OSを搭載したiPhone 5sとiPhone 5cが発売された。翌月10月にはOS X 10.9 Mavericksがリリースされ、同OSを搭載した新型MacBook Proも発売されている。本ブログではこれらのイベントについて記事として取り上げなかったが、Apple製品を取り巻く一大ムーブメントなので私も注目はしていた。PCとモバイル製品の両方のOSがいずれもメジャーバージョンアップされたことでApple関連の開発環境は新時代を迎えたと言っても良いだろう。iOSとOS Xのバージョンアップに合わせて、Xcodeのメジャーバージョンアップも行われている。最新版はXcode 5.0.2になっており、これにはiOS 7.0とOS X 10.9用のSDKが含まれている。Xcode 5には新しい機能も搭載されて、大きく様変わりしているらしい。Xcode 3からXcode 4へのメジャーバージョンアップが行われたときもそうだったが、しばらくXcode 4とXcode 5を併用していくのが良さそうだ。

残念ながら、私はiOSアプリ開発に本格的に取り組んでいると自信を持って言える状況ではないので、しばらくはこれらの動きを静観しようと思っていた。しかし、モバイル分野はものすごい速さで進化しているので、そのメインストリームであるiOSの最新動向をまったくフォローしないとはさすがにマズイかなぁと、最近になってだんだん不安を感じるようになってきた。そこで、取りあえず、Xcode 5の導入だけでもやっておいて、少しずつ使っていく方が良いかもしれないと考えを変えた。Mac mini(OS X Mountain Lion搭載)へXcode 5.0.2をインストールしたので、以下に作業ログを備忘録として書いていく。

Xcode 5はOS X Mountain Lion以降にしか対応していない。Mac miniには以下の2つのバージョンのXcodeをインストール済みだった。
 Xcode 4.4.1 : 
  iOS SDK → 5.0*, 5,1, 6.0*
  Mac OS X SDK → 10.6*, 10.7, 10.8
 Xcode 4.6.3 : 
  iOS SDK → 5.0*, 5,1*, 6.0*, 6.1
  Mac OS X SDK → 10.6*, 10.7, 10.8

 ※ * 印のSDKは、他のバージョンのXcodeからファイルをコピーして追加したもの

上のとおり、2つのXcodeでiOS SDKとMac OS X SDKのバージョンが重複していたので、まずはXcode 4.4.1の方を削除した。その上で、Xcode 4.6.3を残した状態でXcode 5.0.2のインストール作業を始めた。

Xcode 5.0.2のインストール方法はXcode 4.3以降と変わっていない。DMGイメージファイルに格納されているXcode.appを「アプリケーション」フォルダへコピーすればインストールは完了する(Xcode 5.0.2のXcode.appをコピーする前に、Xcode 4.6.3のアプリファイルXcode.appはリネームしておいた)。
Xcode_5.0.2-Installing_MountainLion-SCShot13112813-611x388.png
Xcode.appのコピーが済んだ後Xcodeアプリを起動すると、最初にライセンスへの同意を求める画面が表示された。
Xcode_5.0.2-Installing_MountainLion-SCShot13112820-490x342.png
この画面の[Agree]ボタンを押すと、いきなり下のような画面に変わった。
Xcode_5.0.2-Installing_MountainLion-SCShot13112821-480x163.png
何かのコンポーネントをインストールしているものと思われるが、この画面には詳細情報が表示されていないので何をインストールしているのかは不明。Xcode 4.4.1やXcode 4.6.3では「Device Support」という名前の既存コンポーネントの更新処理が実行されていたので、多分同じ処理が行われているではないかと思われる。この処理が終了すると、XcodeのWelcomeウィンドウが表示された。
Xcode_5.0.2-Welcome_Window-SCShot13112823-802x471
WelcomeウィンドウのデザインはXcode 4とは変わっている。Xcodeが起動することを確認した後、すぐに[Preferences]メニューの[Downloads]ウィンドウを開いて、追加コンポーネントのインストールを行った。
Xcode_5.0.2-Preferences_Downloads-SCShot13112824-750x498
Xcode_5.0.2-Preferences_Downloads-SCShot13112827-750x498
こちらのウィンドウのデザインもXcode 4から変わっている。もしかしたらXcode 5ではすべてのウィンドウのデザインが一新されているのかもしれない。「Command Line Tools」をインストールしなかったのは、Xcode 4.6.3の同コンポーネントがすでにインストール済みだからだ。複数のバージョンの「Command Line Tools」を共存させることはできないので、どれか一つのバージョンだけをインストールしなければならない。

上の追加コンポーネント(「Command Line Tools」以外)をすべてインストールすると、Xcode 5.0.2に含まれるSDKは下のようになる。
System_Profiler-Developer_Xcode_5.0.2-SCShot13112907-751x540
これは、[ユーティリティ]>[システム情報]の「Developer」というカテゴリを選択すると表示される情報だ(なぜXcode 5.0.2のエントリが2つ存在するのかは不明。もしかすると削除したXcode 4.4.1が影響しているのか?)。

これでXcode 5.0.2のインストールは完了だが、Xcode 4.4.1やXcode 4.6.3をインストールしたときと同様に、同梱されていないバージョンのiOS SDKとMac OS X SDKを追加する作業を行った。
  1. 最初にターミナルを開き、次のコマンドを実行して、Xcode 5.0.2内にXcode 4.6.3側のiOS SDKが格納されているディレクトリのリンクを作成した。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk ./

    これによって、iOS 5.0, 5.1, 6.0, 6,1のSDK が追加される。

  2. 続いて、次のコマンドを実行して、Xcode 5.0.2内にXcode 4.6.3側のMac OS X SDKが格納されているディレクトリのリンクを作成した。
    % cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk ./
    % ln -s /Applications/Xcode_463.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk ./

    これによって、Mac OS X 10.6, 10.7のSDKが追加される。

Xcode 4.6.3には以下のSDKしか含まれていないが、これらのバージョン以外のSDKは他のXcodeからファイルをコピーすることで追加しておいたものだ(07/08の記事を参照)。
 iOS SDK      → 6.1
 Mac OS X SDK → 10.7, 10.8

上の操作を行った後、Xcode 5.0.2のDeveloper Information([ユーティリティ]>[システム情報]>[Developer]の表示情報)を確認すると、下のようになっていた。
System_Profiler-Developer_Xcode_5.0.2-SCShot13112924-751x611
これでiOS 7用の最低限の開発環境が整った。サードバーティー製の開発ツールもiOS 7への対応が進んでいるが、ほとんどのツールはXcodeに含まれるiOS SDKに依存しているので、Xcodeがインストール済みであることは必須条件となる。私が本格的にiOS 7用アプリの開発に取り組むのはしばらく先になると思うが、取りあえず、Xcode 5の環境は構築はできたので、今回はここまでで良しとしよう。

Appleの製品開発サイクルはすごく速くて、一年経つと製品もOSも完全に一世代前のものになってしまう。この日進月歩の動きを追いかけていくのはかなり大変だ。モバイル開発のメインストリームはiOSなので、それでも覚悟を決めて追いかけていくしかないんだが・・・。

【2014/01/15 追記】

追加したSDKがXcode側で認識されているか確認するのを忘れていた。上記の操作を行った後、Xcode 5.0.2を起動して既存のプロジェクトを開くと、[Build Settings]ページの[Architectures]−[Base SDK]設定項目のメニューに新しいSDKが追加されていた。
SCShot140115_0004-Xcode_5.0.2-Adding_MacOSX_iOS_SDKs-881x542.png

【参考ページ】

 ios6 - Is it possible to install iOS 6 SDK on Xcode 5? - Stack Overflow

タグ:Xcode
posted by とみやん at 10:54| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年11月25日

[Homebrew] ClamXav導入後"brew update"がエラーになる

前記事に書いたとおり、MBA13のアンチウィルスソフトの入れ換え作業でClamXavをインストールした。この作業自体は特に問題なくできたんだけど、今日日課のHomebrewのアップデートを実行したら、下のようなエラーが出力された。
% brew update
error: unable to unlink old 'SUPPORTERS.md' (Permission denied)
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

こんな警告はいままで一度も見たことがない。最初はこの問題の原因が判らなかっただけど、色々調べていくうちに、どうやら昨日インストールしたClamXavが悪さをしていることが判った。
  • ClamXavは、/usr/localのパーミッションとオーナー情報を書き換えてしまう。

ClamXavの導入に伴ってClam AntiVirus(ClamAV)エンジンをインストールしたが、ClamAVエンジン関連のファイルは/usr/local/clamXavというディレクトリに格納される。このディレクリトはClamAVエンジンのインストーラが作成しているようだが、この際に上の操作が実行されているようだ。

ClamXavのインストール後に「brew doctor」コマンドを実行すると、下のような警告メッセージが表示された。
% brew doctor
Warning: The /usr/local directory is not writable.
Even if this directory was writable when you installed Homebrew, other
software may change permissions on this directory. Some versions of the
"InstantOn" component of Airfoil are known to do this.

You should probably change the ownership and permissions of /usr/local
back to your user account.

ClamXavのインストール後に/usr/localのパーミッションとオーナー情報を確認すると、下のように変更されていた。
% ls -l /usr
total 8
drwxr-xr-x 8 root wheel 272 1 15 2011 X11
lrwxr-xr-x 1 root wheel 3 1 15 2011 X11R6 -> X11
drwxr-xr-x 1081 root wheel 36754 11 11 15:26 bin
drwxr-xr-x 4 root wheel 136 7 14 2011 etc
drwxr-xr-x 270 root wheel 9180 6 5 22:07 include
drwxr-xr-x 381 root wheel 12954 11 16 14:46 lib
drwxr-xr-x 109 root wheel 3706 11 11 15:26 libexec
drwxrwxr-x 7 root admin 238 7 28 2011 llvm-gcc-4.2
drwxr-xr-x 20 yuhri wheel 680 11 24 12:24 local
drwxr-xr-x 237 root wheel 8058 11 11 15:26 sbin
drwxr-xr-x 77 root wheel 2618 11 11 15:26 share
drwxr-xr-x 4 root wheel 136 1 15 2011 standalone

別のMacにインストール済みのHomebrewを確認したら、/usr/localのパーミッションは「drwxrwxr-x」、オーナー情報は「root:admin」になっていた。そこで、以下のコマンドを実行して元の状態に戻した。
% sudo chown root:admin /usr/local
% sudo chmod g+rwx /usr/local
% ls -l /usr
total 8
drwxr-xr-x 8 root wheel 272 1 15 2011 X11
lrwxr-xr-x 1 root wheel 3 1 15 2011 X11R6 -> X11
drwxr-xr-x 1081 root wheel 36754 11 11 15:26 bin
drwxr-xr-x 4 root wheel 136 7 14 2011 etc
drwxr-xr-x 270 root wheel 9180 6 5 22:07 include
drwxr-xr-x 381 root wheel 12954 11 16 14:46 lib
drwxr-xr-x 109 root wheel 3706 11 11 15:26 libexec
drwxrwxr-x 7 root admin 238 7 28 2011 llvm-gcc-4.2
drwxrwxr-x 20 root admin 680 11 24 12:24 local
drwxr-xr-x 237 root wheel 8058 11 11 15:26 sbin
drwxr-xr-x 77 root wheel 2618 11 11 15:26 share
drwxr-xr-x 4 root wheel 136 1 15 2011 standalone

この状態で「brew doctor」を実行したら、警告メッセージは表示されなくなった。

じつは、上記の原因に辿り着いたのは色々と試行錯誤した後だった。この問題が起きたときに「brew update」の警告メッセージをキーワードにしてググったら、最初は参考ページAがヒットした。そこで、このページに載っていたコマンドをそのまま実行してみた。
% sudo chown -R `whoami` /usr/local
% cd /usr/local
% git stash
Saved working directory and index state WIP on master: 8c95d23 mariadb: fix build with clang when boost is present
HEAD is now at 8c95d23 mariadb: fix build with clang when boost is present
% git reset --hard
HEAD is now at 8c95d23 mariadb: fix build with clang when boost is present

これで解決するだろうと期待して再度「brew update」を実行してみたが、残念ながら、同コマンドの警告メッセージが下のように変わっただけだった。
% brew update
error: The following untracked working tree files would be overwritten by merge:
Library/Aliases/git-tig
Library/Contributions/cmd/brew-bundle.rb
Library/ENV/4.3/ant
Library/ENV/4.3/g++-4.3
Library/ENV/4.3/g++-4.4
Library/ENV/4.3/g++-4.5
Library/ENV/4.3/g++-4.6
Library/ENV/4.3/g++-4.7
Library/ENV/4.3/g++-4.8
Library/ENV/4.3/g++-4.9
Library/ENV/4.3/gcc-4.3
Library/ENV/4.3/gcc-4.4
Library/ENV/4.3/gcc-4.5
Library/ENV/4.3/gcc-4.6
Library/ENV/4.3/gcc-4.7
Library/ENV/4.3/gcc-4.8
Library/ENV/4.3/gcc-4.9
Library/Formula/afio.rb
Library/Formula/amtterm.rb
Library/Formula/apib.rb
Library/Formula/batik.rb
Library/Formula/cattle.rb
Library/Formula/clens.rb
Library/Formula/cliclick.rb
Library/Formula/clipsafe.rb
Library/Formula/cookiecutter.rb
Library/Formula/cppi.rb
Library/Formula/curaengine.rb
Library/Formula/cvs.rb
Library/Formula/dnsperf.rb
Library/Formula/dynamodb-local.rb
Library/Formula/echoprint-codegen.rb
Library/Formula/ekhtml.rb
Library/Formula/evas.rb
Library/Formula/flac123.rb
Library/Formula/flawfinder.rb
Library/Formula/fsv.rb
Library/Formula/fuseki.rb
Library/Formula/geoipupdate.rb
Library/Formula/gnu-apl.rb
Library/Formula/gtksourceview3.rb
Library/Formula/gtksourceviewmm.rb
Library/Formula/gtksourceviewmm3.rb
Library/Formula/h2.rb
Library/Formula/hexchat.rb
Library/Formula/hidapi.rb
Library/Formula/influxdb.rb
Library/Formula/jena.rb
Library/Formula/jvmtop.rb
Library/Formula/lensfun.rb
Library/Formula/libbson.rb
Library/Formula/libestr.rb
Library/Formula/libfaketime.rb
Library/Formula/liblwgeom.rb
Library/Formula/libmaxminddb.rb
Library/Formula/libmongoclient.rb
Library/Formula/lsyncd.rb
Library/Formula/mahout.rb
Library/Formula/masscan.rb
Library/Formula/pssh.rb
Library/Formula/py3cairo.rb
Library/Formula/pygobject3.rb
Library/Formula/rats.rb
Library/Formula/rcs.rb
Library/Formula/saltstack.rb
Library/Formula/screenresolution.rb
Library/Formula/smartsim.rb
Library/Formula/snapraid.rb
Library/Formula/submarine.rb
Library/Formula/tag.rb
Library/Formula/tcc.rb
Library/Formula/tcptunnel.rb
Library/Formula/tegh.rb
Library/Formula/tracebox.rb
Library/Formula/transmission-remote-gtk.rb
Library/Formula/virtualpg.rb
Library/Formula/vncsnapshot.rb
Library/Formula/vramsteg.rb
Library/Formula/x11vnc.rb
Library/Formula/xsane.rb
Library/Formula/zbackup.rb
Library/Formula/zsh-history-substring-search.rb
Library/Homebrew/cmd/leaves.rb
Please move or remove them before you can merge.
Aborting
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

上の「error: Your local changes to the following files would be overwritten by merge:」というメッセージは、「git checkout」でいずれかのフォーミュラの旧バージョンの定義ファイルを取得している状態にときに表示されるものだが、Homebrewのインストール後に、上のファイルはいずれもいじっていない。なぜこんな警告が出力されるのか理由が判らなかった。

そこで、改めてこの問題についてググって調べたら、今度は参考ページBを見つけた。このページの内容を読んで、ClamXavをインストールした際に/usr/localのパーミションとオーナー情報を書き換えられてしまっていることに気がついた。上の一連の操作をやらないで、最初に/usr/localのパーミションとオーナー情報を元に戻しておき、その上で「brew update」は実行すれば、この問題はすんなりと解決できたんじゃないかということに思い至った。

brew update」で上のような警告メッセージが表示された理由は、一連のgitコマンドによって、フォーミュラ管理情報とフォーミュラ定義ファイルとの間に矛盾が生じているからじゃないかと推測される。この矛盾状態を復旧しないと「brew update」コマンドは通らないと思われるが、それでは一体どうやって復旧すれば良いんだろうとしばし悩んでしまった。悩んでいても仕方ないので、まずは、/usr/localのパーティションとオーナー情報をClamXavをインストールする前の状態に戻した。
% sudo chown root:admin /usr/local
% sudo chmod g+rwx /usr/local

そして、しばらくやっていないことを思い出しながら「brew docotor」を実行してみた。すると、下のような警告メッセージが表示された。
% brew docotor
Warning: You have uncommitted modifications to Homebrew
If this a surprise to you, then you should stash these modifications.
Stashing returns Homebrew to a pristine state but can be undone
should you later need to do so for some reason.
cd /usr/local/Library && git stash && git clean -d -f

うーん、このメッセージの意味は良く解らん。まぁ悩むよりやってみるのが吉かなぁ。取りあえず、上のコマンドを実行してみた。
% cd /usr/local/Library && git stash && git clean -d -f
No local changes to save
Removing Aliases/git-tig
Removing Contributions/cmd/brew-bundle.rb
Removing ENV/4.3/ant
Removing ENV/4.3/g++-4.3
Removing ENV/4.3/g++-4.4
Removing ENV/4.3/g++-4.5
Removing ENV/4.3/g++-4.6
Removing ENV/4.3/g++-4.7
Removing ENV/4.3/g++-4.8
Removing ENV/4.3/g++-4.9
Removing ENV/4.3/gcc-4.3
Removing ENV/4.3/gcc-4.4
Removing ENV/4.3/gcc-4.5
Removing ENV/4.3/gcc-4.6
Removing ENV/4.3/gcc-4.7
Removing ENV/4.3/gcc-4.8
Removing ENV/4.3/gcc-4.9
Removing Formula/afio.rb
Removing Formula/amtterm.rb
Removing Formula/apib.rb
Removing Formula/batik.rb
Removing Formula/cattle.rb
Removing Formula/clens.rb
Removing Formula/cliclick.rb
Removing Formula/clipsafe.rb
Removing Formula/cookiecutter.rb
Removing Formula/cppi.rb
Removing Formula/curaengine.rb
Removing Formula/cvs.rb
Removing Formula/dnsperf.rb
Removing Formula/dynamodb-local.rb
Removing Formula/echoprint-codegen.rb
Removing Formula/ekhtml.rb
Removing Formula/evas.rb
Removing Formula/flac123.rb
Removing Formula/flawfinder.rb
Removing Formula/fsv.rb
Removing Formula/fuseki.rb
Removing Formula/geoipupdate.rb
Removing Formula/gnu-apl.rb
Removing Formula/gtksourceview3.rb
Removing Formula/gtksourceviewmm.rb
Removing Formula/gtksourceviewmm3.rb
Removing Formula/h2.rb
Removing Formula/hexchat.rb
Removing Formula/hidapi.rb
Removing Formula/influxdb.rb
Removing Formula/jena.rb
Removing Formula/jvmtop.rb
Removing Formula/lensfun.rb
Removing Formula/libbson.rb
Removing Formula/libestr.rb
Removing Formula/libfaketime.rb
Removing Formula/liblwgeom.rb
Removing Formula/libmaxminddb.rb
Removing Formula/libmongoclient.rb
Removing Formula/lsyncd.rb
Removing Formula/mahout.rb
Removing Formula/masscan.rb
Removing Formula/pssh.rb
Removing Formula/py3cairo.rb
Removing Formula/pygobject3.rb
Removing Formula/rats.rb
Removing Formula/rcs.rb
Removing Formula/saltstack.rb
Removing Formula/screenresolution.rb
Removing Formula/smartsim.rb
Removing Formula/snapraid.rb
Removing Formula/submarine.rb
Removing Formula/tag.rb
Removing Formula/tcc.rb
Removing Formula/tcptunnel.rb
Removing Formula/tegh.rb
Removing Formula/tracebox.rb
Removing Formula/transmission-remote-gtk.rb
Removing Formula/virtualpg.rb
Removing Formula/vncsnapshot.rb
Removing Formula/vramsteg.rb
Removing Formula/x11vnc.rb
Removing Formula/xsane.rb
Removing Formula/zbackup.rb
Removing Formula/zsh-history-substring-search.rb
Removing Homebrew/cmd/leaves.rb

おお、先の「brew update」の警告メッセージで示されたファイルを消してくれているみたいだ。これで復旧できたかもと思いながら、ここで再度「brew update」コマンドを実行した。そうしたら、期待したとおり、今度は上手くいった。

Homebrewで問題が起きたら、一番最初に「brew doctor」コマンドを実行すべきなんだ。そうすれば、大抵の場合問題の解決につながるヒントが得られる。いやー、Homebrewの復旧ができて本当に良かった。一時はHomebrew環境の再構築をやらないとダメなのかと焦ってしまった。今回得た教訓。いままでやったことのない事を実行するときは、その前に丹念な下調べを必ずやるべし。

【参考ページ】

  1. homebrew - brew update したら「error: unable to unlink old 'XXXXXXX' (Permission denied)」 - Qiita [キータ]
  2. Homebrew and ClamXav – I am Yihang
タグ:Homebrew ClamXav
posted by とみやん at 13:31| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年10月10日

CoffeeScriptをインストールして試してみた

前記事に書いたとおり、前々から興味を持っていたNode.jsをMac OS Xへインストールした。Node.jsを使って本格的なWebサービスを開発してやろうと一念発起したからだが、じつは、Node.jsと一緒に同時に試しに使ってみたいと思っていたプログラミング環境がある。それはCoffeeScript
CoffeeScript はプログラミング言語のひとつである。コードはJavaScript のコードに変換される。
Ruby や Python、Haskell [1] から影響を受けたシンタックスシュガーの導入により、JavaScript に比べ簡潔さと可読性を向上させたほか、配列内包 (Array comprehensions) やパターンマッチといった機能を追加している。
CoffeeScript により、パフォーマンスを下げることなく、より短いコードでプログラムを記述することができる (JavaScript に比べ 1/3 程度の行数が削減できる)[2]。 2011年3月16日から一時、CoffeeScript は GitHub でもっともウォッチされているプロジェクトであった[3]。

Wikipedia − CoffeeScript

CoffeeScriptを一言で説明するなら、JavaScriptプログラムをより簡単な文法で書ける言語とでも表現すれば良いだろうか。JavaScript文法の冗長な部分を簡略表記で書けるようになっていて、そのおかげで、軽量コードで軽快なプログラミングができるらしい。CoffeeScriptで書いたプログラムは最終的にJavaScriptに変換されて実行されるので、別に実行スピードが速くなる訳ではないが、上の引用のとおり、プログラム全体のコード量をかなり削減できるようだ。大規模なプログラムになると当然コード量も相当多くなるので、このメリットは意外に大きい。ただし、CoffeeScriptで書かれたソースコードは可読性が低下するという批判があり、個人で開発するプログラムには向いているが、チームで開発するプログラムには向いていないという否定的な意見もあるようだ。

CoffeeScriptはNode.jsのパッケージモジュールの一つとしてnpmjs.orgに登録されているので、npmコマンドを使ってインストールすることが可能だ。具体的には、次のコマンドによってCoffeeScriptをインストールできる。
% npm install -g coffee-script
npm http GET https://registry.npmjs.org/coffee-script
npm http 200 https://registry.npmjs.org/coffee-script
npm http GET https://registry.npmjs.org/coffee-script/-/coffee-script-1.6.3.tgz
npm http 200 https://registry.npmjs.org/coffee-script/-/coffee-script-1.6.3.tgz
/usr/local/bin/coffee -> /usr/local/lib/node_modules/coffee-script/bin/coffee
/usr/local/bin/cake -> /usr/local/lib/node_modules/coffee-script/bin/cake
coffee-script@1.6.3 /usr/local/lib/node_modules/coffee-script

上では「npm install」コマンドに「-g」オプションをつけているが、この場合、インストールしたNode.jsモジュールは/usr/local/lib/node_modulesというディレクトに格納され、すべてのユーザーが利用可能なグローバルモジュールとなる。もし「-g」オプションをつけなかった場合は、インストールしたモジュールは~/node_modulesに格納され、現ユーザーだけが利用可能なローカルモジュールとなる。

CoffeeScriptインタプリタ(正確には、CoffeeScript to JavaScriptトランスレータと呼ぶべきだが)は「coffee」というコマンドのようだが、これが利用可能な状態か確認するために次のコマンドを実行してみた。
% coffee -v
CoffeeScript version 1.6.3

これでCoffeeScriptのインストールが済んだので、さっそく簡単な動作確認をやってみた。エディタで以下のコードを作成して、example1.coffeeというファイル名で保存した。
http = require 'http'
http.createServer (req, res) ->
res.writeHead 200, 'Content-Type': 'text/plain'
res.end 'Hello, World\n'
.listen 1337, '127.0.0.1'
console.log 'Server running at http://127.0.0.1:1337/'

このコードは、前記事に掲載したNode.jsのサンプルプログラム 「EXAMPLE 1: Simple Web Server」をCoffeeScriptで書き直したものなので、それとまったく同じ動作をするはずだ。一見すると前記事のJavaScriptコードと大きな差はないように見えるが、次のようなCoffeeScript固有の記法が使われれている。
  • 変数宣言にvarは不要
  • 関数宣言はfunctionの代わりに -> を使う
  • 式の終わりや行末に必ずしもセミコロンを書く必要はない
  • 処理ブロックは {} ではなくインデントで表現する
  • 引数を持つ関数の場合、呼び出しは () を省略して書くことができる
  • 関数にオブジェクトを渡すときは、オブジェクトの {} を省略できる

上のサンプルプログラムをCoffeeScriptインタプリタで実行してみた。
% coffee example1.coffee
Server running at http://127.0.0.1:1337/

この状態で、ブラウザを起動して「http://127.0.0.1:1337/」にアクセスすると、前記事と同じように「Hello World」とだけ表示されたページが開いた。

上のCoffeeScriptのサンプルプログラムがどういうJavaScriptコードに変換されるのか確認するには、下のコマンドを実行すれば良い。
% coffee --print example1.coffee

変換後のJavaScriptコードが標準出力に表示される。また、次のコマンドを実行すると、example1.jsという名前のCoffeeScriptコードから変換されたJavaScriptソースファイルを生成してくれる。
% coffee --compile example1.coffee

上のコマンドによって生成されたコードは当然JavaScriptインタプリタで実行可能なので、既存のJavaScriptソースコードにペーストして利用することができる。ちなみに、上のサンプルプログラムは以下のようなJavaScriptコードに変換されていた。
// Generated by CoffeeScript 1.6.3
(function() {
var http;

http = require('http');

http.createServer(function(req, res) {
res.writeHead(200, {
'Content-Type': 'text/plain'
});
return res.end('Hello, World\n');
}).listen(1337, '127.0.0.1');

console.log('Server running at http://127.0.0.1:1337/');

}).call(this);

上のCoffeeScriptとJavaScriptのコードを比較すると、確かにCoffeeScriptの方が簡潔でコード量は少ない。JavaScriptの方はvarfunctionは宣言文として必要だし、{} () ;を繰り返し書かないといけないのが煩わしいと感じられるかもしれない。しかし、ソースコードの可読性ではどちらが優れているかいう視点で観ると、私だったらJavaScriptの方に軍配を上げるだろう(プログラマによって意見が分かれそうだが・・・)。CoffeeScriptをしばらく使ってみようと思っているが、そのまま継続して使っていかくと聞かれたら、「うーん、どうだろう」というのが答えになりそうだ。どうもCoffeeScriptは私の好みから外れている感じするだよなぁ。

CoffeeScriptはPythonやRubyの良いとこどりをしたようなプログラミング言語で、特にRubyプログラマに好まれているらしい。私はRubyは使ったことはないし、これからも使うつもりもまったくないが、コード記法がRubyに似ているCoffeeScriptはあまり好きになれそうな気がしない。

posted by とみやん at 14:16| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年10月05日

人気上昇中のNode.jsをMacへインストールした

今年に入ってすごい勢いで人気が上昇している、話題のNode.jsをMac OS Xへインストールした。

Node.jsというのはUNIX互換OS上で動作するサーバーサイドJavaScript実行環境の一種で、JavaScriptエンジンとしてGoogle Chromeに組み込まれているV8を使用している。Node.jsのネットワーク通信はイベントループをベースとした非同期処理で実装されているため、リアルタイム型Webサービスを構築するのに適しており、数多くのクライアントが同時に接続して大量のリクエストが流れてもWebサービスのパフォーマンスが低下しにくいという特徴を持っている。サーバーサイドJavaScriptの実装はいくつか存在するが、スマートデバイスの普及により、上記のようなWebサービスへの需要が高まっているいまNode.jsには大きな注目が集まっており、サーバーサイドJavaScriptのデファクト・スタンダードになりつつある。Windows AzureAmazon Web Services(AWS)からもこれらのサイトのクラウドコンビューティングサービスを利用するためのNode.js用SDKが配布されたり、Node.jsで構築されたWebサイトやクラウドサービスも次々に登場しており、Webプログラミングの世界で、Node.jsはRuby on Railsと同程度かあるいはそれ以上のホットな開発トレンドの一つになっていると言って良いだろう。

Node.jsの公式サイトに各OS用のインストーラパッケージも用意されているので、それらを使うこともできるが、Homebrew経由で導入することもできるので、今回はこの方法でMac OS XへNode.jsをインストールした。インストールを始める前に、いつものようにNode.jsのフォーミュラ情報を確認した。
% brew info node
node: stable 0.10.20, devel 0.11.7, HEAD
http://nodejs.org/
Not installed
From: https://github.com/mxcl/homebrew/commits/master/Library/Formula/node.rb
==> Options
--enable-debug
Build with debugger hooks
--without-npm
npm will not be installed

上のとおり、本記事を書いている時点のNode.jsの安定版は0.10.20だが、10/02 18時頃に確認したときは0.10.18、その1時間後に確認したときは0.10.19になっていた。Node.jsのバージョンアッブはものすごいハイペースで行われているらしい。試しに「brew versions」コマンドを使ってHomebrewで利用可能なNode.jsのバージョンを確認してみたら、以下のように、驚くほどの数のリストが表示された。
% brew versions node
0.10.20 git checkout 653960e /usr/local/Library/Formula/node.rb
0.10.19 git checkout 7973d20 /usr/local/Library/Formula/node.rb
0.10.18 git checkout b74c1c9 /usr/local/Library/Formula/node.rb
0.10.17 git checkout f7bbdcc /usr/local/Library/Formula/node.rb
0.10.16 git checkout 1782834 /usr/local/Library/Formula/node.rb
0.10.15 git checkout 89e0a43 /usr/local/Library/Formula/node.rb
0.10.14 git checkout dbc76e5 /usr/local/Library/Formula/node.rb
0.10.13 git checkout f88d5b8 /usr/local/Library/Formula/node.rb
0.10.9 git checkout ec5f331 /usr/local/Library/Formula/node.rb
0.10.8 git checkout ee99542 /usr/local/Library/Formula/node.rb
0.10.7 git checkout e44f345 /usr/local/Library/Formula/node.rb
0.10.6 git checkout 8583540 /usr/local/Library/Formula/node.rb
0.10.5 git checkout 3b589c5 /usr/local/Library/Formula/node.rb
0.10.4 git checkout 10e219d /usr/local/Library/Formula/node.rb
0.10.3 git checkout 71fd5b1 /usr/local/Library/Formula/node.rb
0.10.2 git checkout 91636ea /usr/local/Library/Formula/node.rb
0.10.1 git checkout bfb5239 /usr/local/Library/Formula/node.rb
0.10.0 git checkout 687062f /usr/local/Library/Formula/node.rb
0.8.22 git checkout 3c4a714 /usr/local/Library/Formula/node.rb
0.8.21 git checkout a3ef032 /usr/local/Library/Formula/node.rb
0.8.20 git checkout 9f95fff /usr/local/Library/Formula/node.rb
0.8.19 git checkout 4824d7c /usr/local/Library/Formula/node.rb
0.8.18 git checkout 07783c3 /usr/local/Library/Formula/node.rb
0.8.17 git checkout 59c35b9 /usr/local/Library/Formula/node.rb
0.8.16 git checkout 8aeaf15 /usr/local/Library/Formula/node.rb
0.8.15 git checkout fc6441e /usr/local/Library/Formula/node.rb
0.8.14 git checkout 11b5459 /usr/local/Library/Formula/node.rb
0.8.12 git checkout 3ae0e38 /usr/local/Library/Formula/node.rb
0.8.11 git checkout f24a5f5 /usr/local/Library/Formula/node.rb
0.8.10 git checkout 4c0b143 /usr/local/Library/Formula/node.rb
0.8.9 git checkout fb8447d /usr/local/Library/Formula/node.rb
0.8.8 git checkout 52bdfa1 /usr/local/Library/Formula/node.rb
0.8.7 git checkout ae6acb4 /usr/local/Library/Formula/node.rb
0.8.6 git checkout bfc71f7 /usr/local/Library/Formula/node.rb
0.8.5 git checkout 7b00c66 /usr/local/Library/Formula/node.rb
0.8.4 git checkout 7b2f682 /usr/local/Library/Formula/node.rb
0.8.3 git checkout 31f8d9f /usr/local/Library/Formula/node.rb
0.8.2 git checkout 50ae8e4 /usr/local/Library/Formula/node.rb
0.8.1 git checkout 9ff0a1d /usr/local/Library/Formula/node.rb
0.8.0 git checkout 01f8006 /usr/local/Library/Formula/node.rb
0.6.19 git checkout 83988e4 /usr/local/Library/Formula/node.rb
0.6.18 git checkout 653fb77 /usr/local/Library/Formula/node.rb
0.6.17 git checkout a3ecde3 /usr/local/Library/Formula/node.rb
0.6.16 git checkout ed17582 /usr/local/Library/Formula/node.rb
0.6.15 git checkout e18b02f /usr/local/Library/Formula/node.rb
0.6.14 git checkout 30813c8 /usr/local/Library/Formula/node.rb
0.6.13 git checkout 3b771d0 /usr/local/Library/Formula/node.rb
0.6.12 git checkout 0e8ea8a /usr/local/Library/Formula/node.rb
0.6.11 git checkout 3eec1f4 /usr/local/Library/Formula/node.rb
0.6.10 git checkout 7e202eb /usr/local/Library/Formula/node.rb
0.6.9 git checkout f752570 /usr/local/Library/Formula/node.rb
0.6.8 git checkout 74bff39 /usr/local/Library/Formula/node.rb
0.6.7 git checkout 9a52dcf /usr/local/Library/Formula/node.rb
0.6.6 git checkout 97fce9a /usr/local/Library/Formula/node.rb
0.6.5 git checkout 911726f /usr/local/Library/Formula/node.rb
0.6.4 git checkout 67a2615 /usr/local/Library/Formula/node.rb
0.6.2 git checkout 05b94b9 /usr/local/Library/Formula/node.rb
0.6.1 git checkout b6eb4fc /usr/local/Library/Formula/node.rb
0.6.0 git checkout 6bec7fc /usr/local/Library/Formula/node.rb
0.4.12 git checkout 3eea412 /usr/local/Library/Formula/node.rb
0.4.11 git checkout b6aa338 /usr/local/Library/Formula/node.rb
0.4.10 git checkout 523d360 /usr/local/Library/Formula/node.rb
0.4.9 git checkout 10b3ded /usr/local/Library/Formula/node.rb
0.4.8 git checkout 8d45d93 /usr/local/Library/Formula/node.rb
0.4.7 git checkout cb6a4b4 /usr/local/Library/Formula/node.rb
0.4.6 git checkout 7c0f0d9 /usr/local/Library/Formula/node.rb
0.4.5 git checkout 8241b81 /usr/local/Library/Formula/node.rb
0.4.4 git checkout 83753a9 /usr/local/Library/Formula/node.rb
0.4.3 git checkout f4a925d /usr/local/Library/Formula/node.rb
0.4.2 git checkout 0476235 /usr/local/Library/Formula/node.rb
0.4.1 git checkout 8a60de4 /usr/local/Library/Formula/node.rb
0.4.0 git checkout b4497ec /usr/local/Library/Formula/node.rb
0.2.6 git checkout 8602eee /usr/local/Library/Formula/node.rb
0.3.2 git checkout 168cb3d /usr/local/Library/Formula/node.rb
0.2.5 git checkout f55f417 /usr/local/Library/Formula/node.rb
0.2.4 git checkout 89438ae /usr/local/Library/Formula/node.rb
0.2.3 git checkout 730f311 /usr/local/Library/Formula/node.rb
0.2.2 git checkout 981bb41 /usr/local/Library/Formula/node.rb
0.2.1 git checkout c963a35 /usr/local/Library/Formula/node.rb
0.2.0 git checkout fbb93d9 /usr/local/Library/Formula/node.rb
0.1.104 git checkout ed51a5b /usr/local/Library/Formula/node.rb
0.1.103 git checkout f3e7c1b /usr/local/Library/Formula/node.rb
0.1.20 git checkout 2baa60c /usr/local/Library/Formula/node.rb
0.1.17 git checkout ab7697f /usr/local/Library/Formula/node.rb
0.1.14 git checkout a82e823 /usr/local/Library/Formula/node.rb

HomebrewによるNode.jsのインストールは、下のとおり、とても簡単にできる。
% brew install node
Warning: Your Xcode (4.3.3) is outdated
Please install Xcode 4.6.3.
==> Downloading http://nodejs.org/dist/v0.10.20/node-v0.10.20.tar.gz
######################################################################## 100.0%
==> Patching
patching file tools/gyp/pylib/gyp/xcode_emulation.py
==> ./configure --prefix=/usr/local/Cellar/node/0.10.20
==> make install
マグカップ /usr/local/Cellar/node/0.10.20: 1087 files, 15M, built in 3.5 minutes

Node.jsと一緒にnpmもインストールされる。npmというのはNode.jsのパッケージマネージャで、Pythonのpipに相当するツールと考えれば良いみたいだ。Node.jsのパッケージ(「モジュール」とも呼ぶらしい)はnpmjs.orgというサイトで一括管理されていて、こちらのサイトに登録されているパッケージはすべてnpmコマンドを使ってインストールできるようになっている(PythonやRubyにも同じようなパッケージマネージャとパッケージ管理サイトが存在する。これは最新のスクリプト・プログラミング言語のトレンドのようだ)。

nodeフォーミュラのインストール後に、Node.jsインタプリタとnpmのバージョンを確認した。
% node -v
v0.10.20
% npm -v
1.3.11

Node.jsのインストールだけで終わってしまうとちっとも面白くないので、Node.jsの公式サイトに掲載されているサンプルプログラムを動かしてみた。まずは、「Hellow World」と表示されたページを返すだけの超簡単なWebサーバーを試した。
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

上のソースコードを適当なファイル名(例えば、example1.jsとか)で保存して、Node.jsインタプリタで実行した。
% node example1.js
Server running at http://127.0.0.1:1337/

その上で、Webブラウザを起動し、アドレスバーに「http://127.0.0.1:1337/」(あるいは「「http://localhost:1337/」」)というURLを入力すると、下のような画面が表示された。
Node.js-Example1_SimpleWebServer-Safari-SCShot0602-574x280.png
Node.jsのスクリプト実行を停止するには、Ctrl-Cをタイプすれば良い。

続いて、もう一つのTCP Echoサーバーのサンプルプログラムも試してみた。
var net = require('net');

var server = net.createServer(function (socket) {
socket.write('Echo server\r\n');
socket.pipe(socket);
});

server.listen(1337, '127.0.0.1');

最初のサンプルプログラムと同様に、上のソースコードを適当なファイル名で保存し、「node」コマンドで起動した。その上で、別のターミナルを開き、下のコマンドを実行した。
% curl http://127.0.0.1:1337
Echo server
GET / HTTP/1.1
User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8x zlib/1.2.5
Host: 127.0.0.1:1337
Accept: */*


curlコマンドが送信しているHTTPリクエストがTCP Echoサーバーによってそのまま返信されている。こちらのサンプルプログラムもちゃんと動作しているようだ。

C/C++でSocketインターフェースを使ったWebサーバーやTCP Echoサーバーを作成するには、多分数百行のコードを書く必要があるはずだ。Javaでも最低100行程度のコードを書かないと実装できなじゃないかと思う。クライアント側と比較してサーバー側のブログラムは複雑な処理になるため、どうしてもコード量が大きくなるからだ。JavaScript + Node.jsだと、上のように数十行程度のコードでサーバー側の基本処理が実装できてしまう。本格的なWebサービスやサーバープログラムだともっと色々な処理を追加する必要は当然あるだろうが、Node.jsではHTTPリクエストやSocketインターフェースなどはクラスとして実装されており、ネットワーク通信処理の核心部分は非常にシンプルなコードで実現できるみたいだ。

話は少しそれるが、私がNode.jsの存在を知ったのは確か去年(2012年)の春頃だった。2011年6月から約1年間東京の大手家電メーカーでインターネット機能を搭載した次世代テレビの開発に係わっていたが、この仕事の中でJavaScriptを使ってプログラムを開発する機会に恵まれた。私が担当したのはテレビ内部のアナログフロントエンド部ハードウェアの機能を試験する動作検証用プログラムの開発で、残念ながら、この仕事でJavaScriptのネットワーク機能を使う機会は一度もなかった。しかし、いくつもJavaScriptプログラムを書いていくうちに、JavaScriptという言語の自由度の高さがすごく気に入ってしまった。この頃はスマートデバイスへの興味が大きく膨らんでいた時期で、Titanium MobileやPhoneGapのようなモバイル開発向けJavaScriptフレームワークの存在を知って、さらにJavaScriptプログラミング習得への意欲が高まっていた。そんな時期にたまたま「JavaScript サーバーサイド」というキーワードでググっていたら、Node.jsについて紹介しているページがいくつかヒットした。Node.jsを利用すればサーバー側で動作するWebサービスもJavaScriptを使って開発できることを知り、私のアンテナがビンビン反応して「これはスゲー!」と思わず叫んでしまった。紹介記事の一つに書かれたいたNode.jsの動作の仕組みを読んだ瞬間こいつに惚れ込んでしまい、「いつかNode.jsで本格的なWebサービスを開発したい」という願望が浮かんだのを覚えている。

あれからJavaScriptを使う機会に恵まれないまま一年半も時が流れてしまったが、最近になってむくむくとJavaScriptへの意欲が蘇ってきたので、モチベーションが上がっているこの機会にJavaScriptプログラミングを一気に習得したいという気持ちが沸き上がっている。せっかくやるなら何か明確な目標を持ちたいので、その目標をやはり「Node.jsで本格的なWebサービスを開発する」にしたい。さくらのVPSに2台分の仮想サーバーを持っているので、将来自分が開発したWebサービスを公開したい場合はこれを利用すれば良い。最近さくらのVPSをあまり利用していなかったので、もったいないと思っていた。JavaScript + Node.jsの習得、Webサービスの開発、さくらのVPSの利用の一石三鳥を狙ってこの目標を決めた。JavaScriptプログラミングに自信が持てるようになれば、モバイル開発へも展開していけるので一石四鳥かもしれない。

じつは、数日前にJavaScriptとNode.jsについてググっているときに、この2つを要素技術として使った新しい組込みソフトウェアのアイデアを思いついた。まだぼんやりとした構想(空想)レベルの段階だが、もし実現化できれば、組込み分野に新たなトレンドとムーブメントを起こせるほどの革新的なアイデアになるじゃないかという想いを抱いている。大部分はオープンな技術の組み合わせで構成されているので、アイデアの内容についてはおいおい本ブログで公開していこうと思っているが、まずは私自身のJavaScriptのブログラミング能力を最低でもシニアレベルまで上げないと話にならない。このアイデアを実現するための計画を練り上げるために具体的な行動を始めたいと思ったことが、JavaScriptプログラミングを本格的に再開してNode.jsを習得しようという気持ちになった大きな理由だ。

【2013/10/13 追記】

ここのところNode.jsについて調べるのが日課になっているが、今日もググっていたら、MeteorというNode.jsベースのフルスタックWebアプリフレームワークを発見した。まだ、開発中のフレームワークだが、その先進性に大きな注目が集まっているらしい。MeteorはMITライセンスに基づくオープンソースプロジェクトとして,すでにGithub上で公開されているそうだ。

TechCrunch Japanの下の記事がたまたまヒットして、このベージの載っていたリンクを辿ったら、Meteorのサイトに行き着いた。

 もうJavaもRubyも要らない?–JavaScriptオンリーの未来派WebアプリフレームワークMeteorがデビュー | TechCrunch Japan

改めてMeteorについてググってみると、次のような連載記事も見つけた。こちらの記事に詳しい解説が掲載されている。

 体感!JavaScriptで超速アプリケーション開発 −Meteor完全解説:連載|gihyo.jp … 技術評論社

MeteorはNode.jsをベースとしており,サーバとクライアントの両方のプログラムをJavaScriptで記述することができる。また、Meteorの開発チームは,Webアプリ開発を素早く,低コストで行えるようにすることにもっとも注力してそうで、実際にMeteorを使ったブログラマからもこの点は高く評価されているそうだ。

RubyがWebアプリ開発で一気にシェアを伸ばしたのはRuby on RailsというフルスタックWebフレームワークが登場したからだ。Node.jsにも軽量なWebフレームワークはいつくか存在していたが、Ruby on Railsのようなデファクトスタンダートと呼べるフルスックWebフレームワークはまだなかった。Meteorの登場によって、この状況は大きく変わるかもしれない。JavaScript + Node.js + MeteorがこれからのWebアプリ開発の大きなトレンドになっていきそうだ。2009年の登場して以来Node.jsは密かにブログラマの人気を集めていたが、いままさにNode.jsはブレークしそうな勢いになっている。一気にNode.jsを習得してしまわないと、このトレンドに乗り遅れてしまうかもしれない。

posted by とみやん at 10:06| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年08月12日

IPythonをインストールして使い始めた

Homebrewを使って初めてMacへPythonをインストールしてから2ヶ月経ったので、だいぶんPython開発環境が整ってきた。ググって調べた情報を基に一通り整備作業は終わったが、Python開発環境の構築を始めて以来必ずやろうと決めていた課題が一つ残っている。それはIPythonの導入だ。

IPythonというのはPythonコードを対話的に実行するためのシェルで、オリジナルの Python言語仕様に型推定の強化や対話的実行のための文法を追加してある超強力なツールだ。Pythonはインタプリタ言語なので、ターミナル上のCLI環境やIDLE(Tcl/Tkを利用したGUIシェル)を使って対話的にコードを実行することができるが、IDLEと比較すると、IPythonは補完、コードハイライティング、シェルコマンド実行など色々と便利な機能を持っている。評判も高くてPythonプログラマの間では有名なツールなので、多くの人が使っている。

■IPythonのインストール


ざっと下調べをした後、さっそくIPythonの導入作業を始めた。

IPythonはPythonライブラリとしてPyPiサイトに登録されているので、「pip」コマンドを使って簡単にインストールできる。ただし、IPythonは以下のライブラリに依存している(私の環境では「*」印のフォーミュラはすでにインストール済み)。
 *pyqt           Qt用Pythonバインディグ
  zmq (zeromq)  軽量な非同期メッセージングキュー・ライブラリ
  pyzmq  zmqに対するPythonバインディグ
  tornado  Pythonで書かれたWebフレームワーク
 *Pygments  Pythonで書かれたシンタックスハイライティング・パッケージ

いずれもPython経由で呼び出されているので、IPythonのインストール後に入れても良いが、先にすべてインストールしまうことにした。
% brew install zmq
% pip install pyzmq
% pip install tornado


依存ライブラリがすべて入ったので、IPythonをインストールした。
% pip install ipython

何も問題なく、IPythonのインストールはあっさりと終わってしまった。

■IPythonの動作確認


さっそくIPythonの動作確認をやってみた。まずはターミナル(iTerm2)からIPythonのCLIシェルを起動した。
IPython_CLIShell-iTerm2_StartupWindow-SCShot1204-505x351.png
次に、QtConsoleを使っているGUIシェルを起動してみた。
% ipython qtconsole

IPython_QtConsole-GUI_StartupWindow-SCShot1206-679x459
最後に、Webブラウザ・ベースの対話環境を起動してみた。
% ipython notebook

IPython_Notebook-Safari_StartupWindow-SCShot1214-1089x687
起動することを確認しただけでは面白くないので、参考ページBに載っていたサンプルコードをIPythonの各シェル環境で実行してみた。
import numpy
from matplotlib import pyplot
x = numpy.arange(0, 10, 0.1)
y = numpy.cos(x)
pyplot.plot(x,y)

このコードは、matplotlibを呼び出してグラフ描画を行なっている。

IPythonでmatplotlibのグラフを表示させるには、「--pylab」オプションを指定してIPythonの各シェル環境を起動する必要がある。
ipython --pylab

IPython_CLIShell-iTerm2_Running_matplotlib-SCShot1209-1366x768
ipython qtconsole --pylab=inline

IPython_QtConsole-GUI_Running_matplotlib-SCShot1211-679x687
ipython notebook --pylab=inline

IPython_Notebook-Safari_Running_matplotlib-SCShot1213-1089x687
いやー、すばらしい。こんなに簡単にグラフ描画プログラムが出来てしまうなんて。IPytyonのインタラクティブな環境を使えば、どんどんプログラムを書いていけそうだ。

膨大な数と豊富な種類のライブラリが揃っているので、Pythonにできないことはないと言っても過言ではないかもしれない。この点ではRubyよりPythonの方が圧倒的に優れている。QtやOpenCVのようなメジャーなフレームワークには大抵Pythonバインディングが存在するし、マイナーなライブラリもPythonに対応しているものが多い。こういうフレームワークやライブラリの機能をちょっと試してみたいと思ったときに、C/C++でプログラムを書くと、どんなに小さな物でも丸一日かかったりする。ブログラムコードを書くこと以外に、コンパイルとビルドに時間を取られるからだ。インタプリタ言語であるPythonを使えば、こういうケースに短時間で目的が達成できるだろう。Pythonでフレームワークやライブラリの機能が使い物になるか確認してから、C/C++による本格的なプログラム開発を始めれば良い。Pythonでデモ用のプロトタイプ・プログラムを作成してしまうという手もある。C/C++やJavaで書くよりずっと楽なはずだ。このように、JavaScriptやPythonのような汎用的な言語によるプログラミングを習得していると、色々なシーンでそれが役に立つ。組込み分野で働くプログラマも絶対にこういう言語を習得しておくべきだ。Pythonを選択したのは大正解だったと実感している今日この頃。

【参考ページ】

  1. Install Scientific Python on Mac OS X | Pen and Pants
  2. Pythonのための高機能IDE、iPython notebookとqtconsole ( on OSX ) | のあのあにっき
  3. IPython notebookでブラウザ内にグラフを描画する - memorandum
  4. Installing scientific Python on Mac OS X | Lowin Data Company
posted by とみやん at 12:47| Comment(2) | TrackBack(0) | 開発・プログラミング > Mac

2013年08月11日

[Homebrew] Python + OpenCV開発環境の再構築

05/2806/01の記事に、virtualenvwrapperを使ってPython + OpenCV環境の構築した際の作業記録を書いたが、その後、Pythonライブラリやvirtualenvwrapperについて調べていくうちに色々と有益な情報が得られた。前記事で紹介したNumPyやSciPyをインストールするのに便利なリポジトリを見つけこともその一つだ。こういう情報を活かすために、Python + OpenCV環境の全面的な再構築を行った。前回とは環境の構成が少し違っているので、新しい環境を構築した際の作業内容について備忘録を兼ねて記録を残す。なお、本記事は自分ための備忘録だが、同時にHomebrewを使ってPython + OpenCV環境を構築する人のためのガイド情報になるように書いていく。そのため、過去の記事と重複する部分も多い。ただし、Homebrew環境はすでにインストール済みで、Python 2.7.x, virtualenv, virtualenvwrapperによるPython環境も構築済みだと仮定して説明していく(前者については05/09の記事、後者については05/22の記事を参照)。

前回の作業で構築したPython + OpenCV環境では、すべてのライブラリをvirtualenvwrapperで作成した仮想環境へ入れたが、今回はこれらをすべて共通環境側へインストールした。共通環境側の全ライブラリを継承した仮想環境を作成できる機能がvirtualenvwrapperに存在するのを発見したことが作業方針を変えた大きな理由だ。汎用性の高いライブラリを入れた共通環境を用意しておいて、この環境に含まれるライブラリを継承した仮想環境を作成する方が、仮想環境側で個別にライブラリを入れていくより合理的だと考えた。

今回構築したPython + OpenCV環境には以下のライブラリを入れた。
 nose       単体テストフレームワーク
 SciPy  科学計算ライブラリ
 NumPy  数値計算ライブラリ
 Pillow  画像処理ライブラリ
 matplotlib グラフ描画ライブラリ
 Sphinx  ドキュメンテーションビルダー

noseを加えたのは、すべての仮想環境で単体テストができるようにしたかったからだ。また、画像処理ライブラリをPILからPillowに置き換えた。PillowはPILをsetuptools互換にするためにPILから分岐したライブラリで、PILとの完全互換を目指して開発が進められているので実装の違いはない。PILの開発は停滞しておりPython 2.7.xまでしか対応していないのに対して、PillowはPython 3.3.xにも対応している。

■Python共通環境の構築


上のように作業方針を変更したのは、前記事で紹介したsamueljohn/pythonリポジトリを見つけたことも影響している。このリポジトリを利用すると、SciPy, NumPy, Pillow, matplotlibはHomebrewを使ってインストールできる。しかも、これらのインストール時にオプションを指定してライブラリの機能を拡張することも可能で、その中には「--with-python3」というオプションもある。このオプションを指定すると、一つのコマンドでPython 2とPython 3の両方の環境にライブラリをインストールすることができる。HomebewでPython環境を構築する場合は、このリポジトリを利用することを強く勧める。

下のコマンドを実行すれば、Homebewでsamueljohn/pythonリポジトリのフォーミュラを利用できるようになる。
% brew tap samueljohn/python

ただし、samueljohn/pythonリポジトリを利用する場合一つ注意しなければならないことがある。それは、あらかじめ次のコマンドを実行してhomebrew/scienceリポジトリをHomebrewに追加しておかないと、samueljohn/pythonリポジトリに含まれるNumPyやSciPyのフォーミュラをインストールできないという点だ。
% brew tap homebrew/science

NumPyの依存フォーミラであるsuite-sparseや、「--with-openblas」オプションを指定した際にNumPyやSciPyへ組み込まれるopenblasはいずれもhomebrew/scienceリポジトリに所属するフォーミュラだからだ。

前記事にNumPyとSciPyのフォーミュラ情報を載せたので、Pillowとmatplotlibのフォーミュラ情報を下に示す。
% brew info pillow
pillow: stable 2.0.0, HEAD
https://github.com/python-imaging/Pillow
Conflicts with: pil
/usr/local/Cellar/pillow/2.0.0 (182 files, 1.9M) *
Built from source
From: https://github.com/samueljohn/homebrew-python/commits/master/pillow.rb
==> Dependencies
Required: little-cms, graphicsmagick, freetype, jpeg, libtiff
==> Options
--with-python3
Build with python3 support
--without-python
Build without python support
% brew info matplotlib
matplotlib: stable 1.2.1, HEAD
http://matplotlib.org
Not installed
From: https://github.com/samueljohn/homebrew-python/commits/master/matplotlib.rb
==> Dependencies
Required: numpy
Optional: cairo, ghostscript, pyside, pyqt, pygtk, homebrew/dupes/tk
==> Options
--with-cairo
Build with cairo support
--with-ghostscript
Build with ghostscript support
--with-pygtk
Build with pygtk support
--with-pyqt
Build with pyqt support
--with-pyside
Build with pyside support
--with-tk
Build with tk support
==> Caveats
If you want to use the `wxagg` backend, do `brew install wxwidgets`.
This can be done even after the matplotlib install.

これ以降Pythonライブラリを順番に入れていくが、その前に、フォーミュラやライブラリのビルド処理で必要となる2つのフォーミュラをインストールしておくことを勧める。pkg-configとcmakeがそれだ。
% brew install pkg-config
% brew install cmake

pkg-configは環境変数PKG_CONFIG_PATHによってpcファイルの参照先を決めるので、下の設定記述を.zshrc(bashの場合は、.bash_profile.bashrc)へ追加する必要がある。
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/X11/lib/pkgconfig

それから、gfortran(Gnu Fortran Compiler)もインストールしておこう。
% brew install gfortran

NumPyやSciPyの高速な計算処理は部分的にFortranで実装されているからだ。Fortranが存在しなくてもどちらもビルドできるが、計算速度がかなり遅くなるので、gfortranをインストールすることは必須と考えるべきだ。

上の操作が済んだら、ターミナルを再起動して、最初に、「pip」コマンドを使ってPython環境へnoseライブラリをインストールしよう。
% pip install nose

次にインストールするnumpyやscipyがnoseに依存しているので、samueljohn/pythonリポジトリに所属するフォーミュラをインストールする場合は、一番最初にnoseをインストールしなければならない。

noseを入れたら、Homebrewを使ってnumpyとscipyフォーミュラをインストールしよう(「pip」コマンドは使わない)。
% brew install numpy
% brew install scipy --with-openblas

scipyの方だけに「--with-openblas」オプションをつける理由は前記事に書いた。numpyとscipyフォーミュラをインストールすると、依存関係によって、suite-sparse, tbb, swig, pcre, openblas(「--with-openblas」オプションを指定した場合のみ)も一緒にインストールされる。

私の環境ではここまでの作業は終わっていた。今回行ったのはこれ以降からだ。まずは、Pillowをインストールした。
% brew install pillow

Pillowをインストールすると、依存関係でlittle-cms, graphicsmagick, freetype, jpeg, libtiffの4つのフォーミュラも一緒に追加される。

次にmatplotlibをインストールすることになるが、まだqtフォーミュラが入っていないなら、先にこれをインストールしておいた方が良い。
% brew install qt

matplotlibフォーミュラを入れる際にオプションを指定することでQtも一緒にインストールできるが、Qtのインストールは結構時間がかかるので、あらかじめて入れておくことを勧める。

matplotlibのインストールを行う前に、そのフォーミュラ定義ファイルに以下のような変更を加えた。
% brew edit matplotlib
require 'formula'

.... ....
.... ....
.... ....

class Matplotlib < Formula
.... ....
#! To link with Homebrew's freetype instead of MacOS's one
#depends_on :freetype
depends_on 'freetype'
#! To link with Homebrew's libpng instead of MacOS's one
#depends_on :libpng
depends_on 'libpng'
.... ....
.... ....
.... ....

def install
# Tell matplotlib, where brew is installed
inreplace "setupext.py",
"'darwin' : ['/usr/local/', '/usr', '/usr/X11', '/opt/local'],",
#"'darwin' : ['#{HOMEBREW_PREFIX}', '/usr', '/usr/X11', '/opt/local'],"
"'darwin' : ['#{HOMEBREW_PREFIX}', '#{HOMEBREW_PREFIX}/opt/freetype', '#{HOMEBREW_PREFIX}/opt/libpng', '/usr', '/usr/X11', '/opt/local'],"
.... ....
.... ....
.... ....
.... ....
.... ....
.... ....
end

変更前のフォーミュラ定義ファイルではMac OS X側のfreetypeとlibpngがmatplotlibにリンクされるが、変更後はHomebrew側のライブラリがリンクされる。前者でも特に問題はないが、いずれもHomebrewのフォーミュラとして存在しているので、そちらを使いたかった。

上の操作を行った上で、matplotlibのインストールを実行した。
% brew install matplotlib --with-cairo --with-pyqt --with-pyside

PyQtPySide(どちらもQtを利用するためのPythonバインディング)を一緒に入れたのは、Qtに大きな興味を持っている私にとって、この2つが利用価値の高いソフトウェアだと思えたからだ。matplotlibをインストールすると、依存関係によって、以下のフォーミュラも一緒に追加される。
 libpng                                   ← フォーミュラ定義ファイルに加えた変更により
 cairo, xz, pixman, glib, gettext, libffi ←「--with-cairo」オプションにより
 pyqt, qt, sip ←「--with-pyqt」オプションにより
 pyside, qt, shiboken ←「--with-pyside」オプションにより

pysideとpyqtのサイズが大きいようで、この2つのビルドにかなり時間がかかった。qtフォーミュラが未インストールだったら、さらに時間がかかっていただろう。

最後に、「pip」コマンドを使ってSphinxをインストールした。
% pip install Sphinx

SphinxはPygments, Jinja2, docutils, MarkupSafeの4つに依存しているので、これらのライブラリも一緒にインストールされる。

Pythonライブラリのインストールがすべて終わったら、最後に、「pip」コマンドを使ってライブラリ一覧を確認してみると良いだろう。
% pip list
distribute (0.6.40)
docutils (0.11)
Jinja2 (2.7.1)
MarkupSafe (0.18)
matplotlib (1.2.1)
nose (1.3.0)
numpy (1.7.1)
Pillow (2.0.0)
Pygments (1.6)
scipy (0.12.0)
Sphinx (1.2b1)
stevedore (0.10)
virtualenv (1.9.1)
virtualenv-clone (0.2.4)
virtualenvwrapper (4.1.1)
wsgiref (0.1.2)


■OpenCVのインストール


06/01の記事に書いたように、OpenCVはNumPyに依存している。また、Sphinxが存在していると、OpenCVのインストール時にドキュメントが自動生成される。いずれのライブラリもPython共通環境に入れたので、OpenCVをインストールするためPython側の条件はすでに整っている。

もしffmpegが存在していないなら、OpenCVをインストールする前に、ffmpegとその依存フォーミュラを入れておくことを勧める。
% brew install ffmpeg --with-libvorbis --with-libvpx --with-schroedinger

ffmpegはOpenCVの依存フォーミュラではないが、あらかじめffmpegを入れておくと、ビルド時にその存在を認識して、OpenCVにビデオキャプチャ機能が組み込まれるようになっている。

これでOpenCVをインストールするための条件は整った。OpenCVのフォーミュラはHomebrewのメインリポジトリではなくhomebrew/scienceリポジトリに所属しているが、このリポジトリすでにHomebrewに追加済みだ。後はopencvフォーミュラのインストールを実行するだけだが、その前に、OpenCVのフォーミュラ定義ファイルに以下の変更を加えた。

% brew edit opencv
require 'formula'

class Opencv < Formula
.... ....
.... ....
#! To link with Homebrew's libpng instead of MacOS's one
#depends_on :libpng
depends_on 'libpng'

.... ....
.... ....
.... ....
.... ....
.... ....
.... ....
.... ....
.... ....
end

.... ....
.... ....

コメントが示しているとおり、この変更の目的はHomebrew側のlibpngをopencvとリンクするためだ。上の変更を行った後、opencvフォーミュラのインストールを実行した。
% brew install opencv --with-eigen --with-jasper --with-libtiff --with-qt --with-tbb

opencvフーミュラのオプションは好みで決めれば良いだろう。上の各オプションを指定するとオプション名に対応したフォーミュラが一緒にインストールされるが、ここまでの操作によってlibtiff, qt, tbbはすでに存在しているはずなので、実際に追加されるのはeigenとjasperだけだ。

■OpenCV開発用Python仮想環境の作成


OpenCVと連携使用する基本的なライブラリはすべてPython共通環境に入っているし、opencvフォーミュラをインストールしたので、OpenCVのPythonバインディングも同環境で利用できる状態になっている。この状態で、virtualenvwrapperを使って共通環境の全ライブラリを継承した仮想環境を作成すれば、その仮想環境からOpenCVを利用することも同様に可能だ。次のコマンドを実行すれば、共通環境の全イブラリを継承した仮想環境を作成できる。
% mkvirtualenv --system-site-packages opencv_work

上で使っている「--system-site-packages」というオプションは、共通環境側のライブラリをコピーする訳ではなく、ファイルのリンクを作成することで仮想環境からライブラリを参照できるようにしているようだ。

上のコマンドで作成した仮想環境からOpenCVが利用できるか動作確認をやってみると良いだろう。OpenCVのソースパッケージにPythonで書かれたサンプルプログラムが格納されているので、それを利用するのが一番手っ取り早い。その具体的な方法は06/01の記事に書いたので、そちらを参照してほしい。

【参考ページ】



posted by とみやん at 09:29| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年08月10日

[Homebrew] SciPyにOpenBLASを組込んで高速化する

05/28の記事で、OpenCV + Python環境を構築する過程でPython仮想環境にNumPyとSciPyを組み込んだ。どちらもPythonでプログラム開発をやるには必須のライブラリだが、この2つについて調べるうちに、OpenBLASというオープンソースの線形計算ライブラリが存在し、このライブラリを組み込んでビルドするとNumPyとSciPyを高速化できるらしいことを知った。これにトライしてみたら成功したので、その作業記録を書いておく。

■OpenBLASを組み込んだNumPyとSciPyのビルド


すでにNumPyとSciPyをインストール済みだったので、まずは、「pip」コマンドを使ってこの2つのライブラリをアンイストールした。
% pip uninstall numpy
% pip uninstall scipy
% pip list
distribute (0.6.40)
stevedore (0.10)
virtualenv (1.9.1)
virtualenv-clone (0.2.4)
virtualenvwrapper (4.1.1)
wsgiref (0.1.2)

続いて、Homebrewに新しいGitHubリポジトリを追加した。
% brew tap samueljohn/python

OpenBLASについてググっているうちに、OpenBLASを組み込んでNumPyとSciPyをビルドできるフォーミュラ定義ファイルがこのsamueljohn/pythonリポジトリに存在しているのを見つけた。「pip install --no-install | --no-download PACKAGE」コマンドを使って、手動でコンフィグレーション定義に変更を加えながらOpenBLASを組み込んでビルドする方法もある。実際にこの方法も試してみたが、かなり面倒な手順だったので、Pythonライブラリのビルドに慣れていない人には勧められない。上のリポジトリを利用すれば、簡単にOpenBLASを組み込むことができる。このリポジトリを追加すると、Homebrewを使ってNumPyとSciPyをPython環境へインストールできるようになる(この2つ以外に、PillowやmatplotlibなどのいくつかのPythonライブラリのフォーミュラも追加される)。
% brew info numpy
numpy: stable 1.7.1, HEAD
http://numpy.scipy.org
Not installed
From: https://github.com/samueljohn/homebrew-python/commits/master/numpy.rb
==> Dependencies
Required: homebrew/science/suite-sparse
Optional: homebrew/science/openblas
==> Options
--with-openblas
Use openBLAS (slower for LAPACK functions) instead of Apple's Accelerate Framework
--with-python3
Build with python3 support
--without-python
Build without python support
==> Caveats
Numpy ignores the `FC` env var and looks for gfortran during build.
% brew info scipy
scipy: stable 0.12.0, HEAD
http://www.scipy.org
Not installed
From: https://github.com/samueljohn/homebrew-python/commits/master/scipy.rb
==> Dependencies
Build: swig
Required: numpy
Optional: homebrew/science/openblas
==> Options
--with-openblas
Use openBLAS (slower for LAPACK functions) instead of Apple's Accelerate Framework
--with-python3
Build with python3 support
--without-python
Build without python support

上のNumPyのフォーミュラ情報から、このNumPyはsuite-sparseというフォーミュラに依存していることが判る。SuiteSparseというのはCやFortran、MATLAB 用の疎行列演算ライブラリの詰め合わせパッケージ。suite-sparseとopenblasはいずれもhomebrew/scienceリポジトリに所属しているフォーミュラだ。したがって、NumPyやSciPyにこれらを組み込むには、あらかじめ下のコマンドによってhomebrew/scienceリポジトリをHomebrewに登録しておかなければならない。
% brew tap homebrew/science

OpenBLASを有効にしてNumPyとSciPyをインストールするには、次のコマンドを実行すれば良い。
% brew install numpy --with-openblas
% brew install scipy --with-openblas

ただし、先にnose(Python用単体テストフレームワーク)ライブラリをインストールしておく必要がある。
% pip install nose

numpyフォーミュラがnoseライブラリを要求してくるからだ。Python環境にnoseが入っていない状態でnumpyをインストールしようとすると、下のようなエラーメッセージが表示される。
% brew install numpy --with-openblas
numpy: Unsatisfied dependency: nose
Brewed Python cannot `import nose`. Install with:
pip-2.7 install nose
Error: An unsatisfied requirement failed this build.

numpyとscipyフォーミュラをインストールすると、依存関係によって、suite-sparse, tbb, swig, pcre, openblas(「--with-openblas」オプションを指定した場合のみ)も一緒にインストールされる。

上の操作を行った後で、numpyとscipyライブラリがPython環境にちゃんと入っているか確認してみた。
% pip list
distribute (0.6.40)
nose (1.3.0)
numpy (1.7.1)
scipy (0.12.0)
stevedore (0.10)
virtualenv (1.9.1)
virtualenv-clone (0.2.4)
virtualenvwrapper (4.1.1)
wsgiref (0.1.2)


■NumPyとSciPyの動作速度計測


OpenBLASを組み込んだNumPyとSciPyがどれ位高速になっているか確認してみた。動作速度の計測には、下のGitHub Gistページに掲載されている2つのPythonプログラムを利用させてもらった。

 Testing numpy and scipy setups

OpenBLASを組み込む前のNumPy/SciPyの動作速度

$ python test_numpy.py
FAST BLAS
version: 1.7.1
maxint: 9223372036854775807

dot: 0.130087995529 sec
% python test_scipy.py
cholesky: 0.0464385986328 sec
svd: 1.35554437637 sec

OpenBLASを組み込んだ後のNumPy/SciPyの動作速度

% python test_numpy.py
slow blas
version: 1.7.1
maxint: 9223372036854775807

dot: 1.26860480309 sec
% python test_scipy.py
cholesky: 0.0384438037872 sec
svd: 1.16273679733 sec

上の動作速度計測を行った環境は次のとおり。

 PC:MacBook Air 11-inch(Mid 2011)
 ハード仕様:Intel Core i7 1.8GHz(Sandy Bridge) HyperThreading 4コア メモリ 4GB
 コンパイラ:Clang 3.1 build 318(Xcode 4.3.3 + Command Line Tools )
 実行環境:Python 2.7.4
 計測対象:NumPy 1.7.1, SciPy 0.12.0

上の2つのケースの計測値を比較すると、次のような非常に興味深い結果になった。
 NumPy OpenBLASを組み込む前の方が約10倍速い
 SciPy OpenBLASを組み込んだ後の方が若干速い

ググっていたときに、OpenBLASを組み込んだらNumPy/SciPyが2〜3倍速くなったいう情報をいくつか見かけたが、期待していたほど速くなっていない。これらの情報は多分Linux環境での話なんだろう。しかも、NumPyではOpenBLASを組み込む前の方がずっと高速だ。OpenBLASを組み込む前のNumPy/SciPyには、Apple Accelerate Frameworkに含まれる線形計算ライブラリが使われている。これはXcodeのコンパイラに付属しているApple製のライブラリで、CPUに内蔵されている計算支援拡張命令(Intel x86ならSSE)を利用して動作するようになっている。上のような結果になる理由は、このApple製のライブラリが相当優秀だからではないかと推測できる。この結果を受けて、OpenBLASの採用について次のようにすることに決めた。
 NumPy → OpenBLASを組み込まない
 SciPy → OpenBLASを組み込む

という訳で、NumPyとSciPyのインストールを再度やり直した。
% brew uninstall scipy
% brew uninstall numpy
% brew install numpy
% brew install scipy --with-openblas

SciPyも一旦アンイストールしたのは、このフォーミュラがNumPyに依存しているからだ。

■NumPyとSciPyの動作テスト


以上でOpenBLASを組み込んだNumPyとSciPyのインストールは終了だが、せっかくnoseを入れたので、noseを使ったNumPy/SciPyの動作テストもやってみた。Pythonライブラリの動作テストを簡単に行うことができるので、noseはとても有益なライブラリだ。

先に、OpenBLASを組み込む前、つまり「pip」コマンドを使ってオプション指定なしでNumPy/SciPyをインストールした場合の動作テストの結果を載せておく。
OpenBLASを組み込む前のNumPyの動作テスト

% python
Python 2.7.4 (default, Jul 22 2013, 15:21:29)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.show_config()
lapack_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3']
define_macros = [('NO_ATLAS_INFO', 3)]
blas_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
define_macros = [('NO_ATLAS_INFO', 3)]
>>> numpy.test()
Running unit tests for numpy
NumPy version 1.7.1
NumPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy
Python version 2.7.4 (default, Jul 22 2013, 15:21:29) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)]
nose version 1.3.0
.........................S.....................................................................................................
...............................................................................................................................
...............................................................................................................................

.... ....
.... ....

..........................................................................K....................................................
----------------------------------------------------------------------
Ran 4790 tests in 22.075s

OK (KNOWNFAIL=5, SKIP=6)
<nose.result.TextTestResult run=4790 errors=0 failures=0>
>>> quit()

OpenBLASを組み込む前のSciPyの動作テスト

% python
Python 2.7.4 (default, Jul 22 2013, 15:21:29)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.show_config()
umfpack_info:
NOT AVAILABLE
lapack_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3']
define_macros = [('NO_ATLAS_INFO', 3)]
blas_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3', '-I/System/Library/Frameworks/vecLib.framework/Headers']
define_macros = [('NO_ATLAS_INFO', 3)]
>>> scipy.test()
Running unit tests for scipy
NumPy version 1.7.1
NumPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy
SciPy version 0.12.0
SciPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy
Python version 2.7.4 (default, Jul 22 2013, 15:21:29) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)]
nose version 1.3.0
/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas` instead!
warnings.warn(depdoc, DeprecationWarning)
/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack` instead!
warnings.warn(depdoc, DeprecationWarning)
...............................................................................................................................
...............................................................................................K...............................
...............................................................................K...............................................

.... ....
.... ....
.... ....
.... ....

======================================================================
FAIL: test_arpack.test_symmetric_modes(True, <gen-symmetric>, 'd', 2, 'SA', None, 0.5, <function asarray at 0x1031d5c08>, None, 'cayley')
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 259, in eval_evec
assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err)
File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose
verbose=verbose, header=header)
File "/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare
raise AssertionError(msg)
AssertionError:
Not equal to tolerance rtol=4.44089e-13, atol=4.44089e-13
error for eigsh:general, typ=d, which=SA, sigma=0.5, mattype=asarray, OPpart=None, mode=cayley
(mismatch 100.0%)
x: array([[-0.36892684, -0.01935691],
[-0.26850996, -0.11053158],
[-0.40976156, -0.13223572],...
y: array([[-0.43633077, -0.01935691],
[-0.25161386, -0.11053158],
[-0.36756684, -0.13223572],...

----------------------------------------------------------------------
Ran 6134 tests in 76.404s

FAILED (KNOWNFAIL=15, SKIP=47, errors=1, failures=74)
<nose.result.TextTestResult run=6134 errors=1 failures=74>
>>> quit()

NumPyの結果は「OK」だが、SciPyの方は「FAILED」になっていた。

続いて、OpenBLASを組み込んだ後のNumPy/SciPyの動作テスト結果を示す。
OpenBLASを組み込んだ後のNumPyの動作テスト

% python
Python 2.7.4 (default, Jul 22 2013, 15:21:29)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.show_config()
blas_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
lapack_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
atlas_threads_info:
NOT AVAILABLE
blas_opt_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_blas_threads_info:
NOT AVAILABLE
lapack_opt_info:
libraries = ['openblas', 'openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_info:
NOT AVAILABLE
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
atlas_blas_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
>>> numpy.test()
Running unit tests for numpy
NumPy version 1.7.1
NumPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy
Python version 2.7.4 (default, Jul 22 2013, 15:21:29) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)]
nose version 1.3.0
.......S.........S..............................................................................................................
...............................................................................................................................
...............................................................................................................................

.... ....
.... ....

..........................................................................K....................................................
----------------------------------------------------------------------
Ran 4771 tests in 22.730s

OK (KNOWNFAIL=5, SKIP=7)
<nose.result.TextTestResult run=4771 errors=0 failures=0>
>>> quti()

OpenBLASを組み込んだ後のSciPyの動作テスト

% python
Python 2.7.4 (default, Jul 22 2013, 15:21:29)
[GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.show_config()
blas_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
amd_info:
libraries = ['amd']
library_dirs = ['/usr/local/lib']
define_macros = [('SCIPY_AMD_H', None)]
swig_opts = ['-I/usr/local/include']
include_dirs = ['/usr/local/include']
lapack_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
atlas_threads_info:
NOT AVAILABLE
blas_opt_info:
libraries = ['openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_blas_threads_info:
NOT AVAILABLE
umfpack_info:
libraries = ['umfpack', 'amd']
library_dirs = ['/usr/local/lib']
define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]
swig_opts = ['-I/usr/local/include', '-I/usr/local/include']
include_dirs = ['/usr/local/include']
lapack_opt_info:
libraries = ['openblas', 'openblas']
library_dirs = ['/usr/local/opt/openblas/lib']
language = f77
define_macros = [('NO_ATLAS_INFO', 1)]
atlas_info:
NOT AVAILABLE
lapack_mkl_info:
NOT AVAILABLE
blas_mkl_info:
NOT AVAILABLE
atlas_blas_info:
NOT AVAILABLE
mkl_info:
NOT AVAILABLE
>>> scipy.test()
Running unit tests for scipy
NumPy version 1.7.1
NumPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy
SciPy version 0.12.0
SciPy is installed in /usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy
Python version 2.7.4 (default, Jul 22 2013, 15:21:29) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.61)]
nose version 1.3.0
/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.blas` is deprecated, use `scipy.linalg.blas` instead!
warnings.warn(depdoc, DeprecationWarning)
/usr/local/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/utils.py:139: DeprecationWarning: `scipy.lib.lapack` is deprecated, use `scipy.linalg.lapack` instead!
warnings.warn(depdoc, DeprecationWarning)
...............................................K...............................................K..K............................
...............................................................................................................................
...............................................................................................................................

.... ....
.... ....

...............................................................................................................................
----------------------------------------------------------------------
Ran 4829 tests in 59.444s

OK (KNOWNFAIL=11, SKIP=32)
<nose.result.TextTestResult run=4829 errors=0 failures=0>
>>> quit()

両方の結果が「OK」になっている。じつは、上のOpenBLASを組み込む前のSciPyの動作テスト結果が「FAILED」だったことが気になって、この問題の解決方法がないかと探しているうちに、OpenBLASの存在に行き着いた。なお、今回利用したsamueljohn/pythonリポジトリのNumPyとSciPyのフォーミュラ定義ファイルにはtestメソッドが定義されており、そのメソッドに上と同じnoseの「test()」関数を呼び出す処理が実装されている。numpyフォーミュラのインストール時にnoseライブラリを要求してくるのはこれが理由だ。フォーミュラをインストールした後で「brew test FORMULA」というコマンドをタイプすれば、指定したフォーミュラのtestメソッドを実行することができる。

また、上では「show_config()」という関数も使っているが、この関数を呼び出すと、NumPy/SciPyのコンフィグレーション情報を確認することができる。この情報を比較すると判るが、OpenBLASを組み込んだSciPyにはumfpackとamdという2つの外部ライブラリも一緒に追加されている。この2つのライブラリはSuiteSparseというフォーミュラの中に含まれているもので、numpyフォーミュラをインストールしたときにリンクされる。「show_config()」関数で表示されるコンフィグレーション情報の中に現れる用語の意味を下に示しておく。

 BLAS:Basic Linear Algebra Subprograms
  ベクトルと行列の基本演算を行うサブブログラム
 ATLAS:Automatically Tuned Linear Algebra Software
  コンパイル時に自動的にCPUを識別して、そのCPUに最適なBLASを構築するソフトウェア
 LAPACK:Linear Algebra Package
  連立一次方程式やベクトルと行列などの線形計算ルーチンを集めたパッケージ
 UMFPACK:Unsymmetric Multifrontal Sparse LU Factorization Package
  非対称疎線形系を非対称マルチフロンタル法を使って解くためのルーチンを集めたパッケージ
 AMD:Approximate Minimum Degree Ordering
  近似最小次数順序法(大規模行列並べ替えアルゴリズムの一種)
 MKL:Math Kernel Library
  特定のCPUに最適化された数値演算ライブラリ(Intel社のMKLやAMD社のACMLが有名)

OpenBLASを組み込んでもNumPy/SciPyの動作速度が大きく改善しなかったのは残念だったが、SciPyの動作テス結果が「FAILED」から「OK」に変わった瞬間は「よし。やったぜ」と叫んでしまった。

【参考ページ】

 Install Scientific Python on Mac OS X | Pen and Pants
 Errors in tests of Scipy ・ Issue #12 ・ samueljohn/homebrew-python ・ GitHub

posted by とみやん at 10:27| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年08月07日

pythonz + virtualenvwrapperによるPython開発環境の構築

05/22の記事で、Homebrewを使ったPython開発環境の構築方法を紹介した。Homebrewは優れたパッケージ管理システムでとても利用価値が高いので、Macでオープンソース系のプログラム開発をやるならぜひ使用することを勧めるが、Pythonプログラミングができる環境だけあればそれで十分だという人もいるかもしれない。そういうプログラマのために、pythonzというものを紹介しよう。これはPythonだけに特化したパッケージ管理システムだ。Homebrewとはまったく別のものなので、先にHomebrewをインストールしておく必要はない。このpythonzを使うと、任意のバージョンのPythonをインストールすることができる。Homebrewより操作が容易なので、もしPython環境だけしか必要ないならpythonzを使った方が楽じゃないかと思う。pythonzにvirtualenvとvirtualenvwrapperを組み合わせることで仮想環境を構築することもできるので、Homebrewで構築したPython環境と同じように複数のバージョンのPythonを切り換えて使うことも可能だ。それでは、pythonzのインストール方法から説明していく。

■pythonzのインストール


まずは、pythonzをインストールしないと何も始まらない。次のコマンドを実行すれば、pythonzをインストールできる。
% curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash

上のコマンドを実行すると、ホームディレクトリの中に.pythonzというディレクトリが作成され、その中にpythonz環境の全ファイルが格納される。

pythonzのインストールが終わったら、.zshrc(bashの場合は、.bash_profile.bashrc)に次のような記述を追加してやる。
# pythonz settings
[[ -s $HOME/.pythonz/etc/bashrc ]] && source $HOME/.pythonz/etc/bashrc

これで、「source .zshrc」を実行するかターミナルを再起動すれば、pythonzが利用できるようになる。試しに、次のコマンドを実行してみると良い。このコマンドによって、pythonzで利用可能なパッケージの全バージョンが表示される。
% pythonz list -a
# Available Python versions
# cpython:
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
2.5.6
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.6.6
2.6.7
2.6.8
2.7
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
3.0
3.0.1
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3.0
3.3.1
3.3.2
# stackless:
2.6.5
2.7.2
3.1.3
3.2.2
# pypy:
1.8
1.9
2.0
2.0.1
2.0.2
2.1
# jython:
2.5.0
2.5.1
2.5.2
2.5.3

cpython」というのがPython(C++で記述されたPython)のことだ。Python以外にPyPy(Pythonで記述されたPython処理系)やJython(Javaで記述されたPython処理系)もpythonzでインストールすることが可能だ。

■pythonzによるPythonのインストール


pythonzによって特定のバージョンのPythonをインストールするには、「pythonz install VERSION」というコマンドを使えば良い。
% pythonz install 2.7.5
Downloading Python-2.7.5.tgz as /Users/yuhri/.pythonz/dists/Python-2.7.5.tgz
########################################################################## 100%
Extracting Python-2.7.5.tgz into /Users/yuhri/.pythonz/build/CPython-2.7.5

This could take a while. You can run the following command on another shell to track the status:
tail -f /Users/yuhri/.pythonz/log/build.log

Installing CPython-2.7.5 into /Users/yuhri/.pythonz/pythons/CPython-2.7.5

Installed CPython-2.7.5 successfully.

上のメッセージの中に示されているとおり、pythonzによってインストールしたPythonパッケージのファイル一式は$HOME/.pythonz/pythons/CPython-<VERSION>というディレクトリの中に格納される。

もしHomebrew側のPython環境にすでにvirtualenvとvirtualenvwrapperがインストール済みなら、そちらとpythonz側のPythonインタプリタを組み合わせて仮想環境を作成することもできる。ただし、05/22の記事で説明したvirtualenvwrappeの設定がすべて済んでいることが条件となる。Homebrew側のvirtualenvwrapperを使って仮想環境を作成するには、次のようなコマンドを実行すれば良い。
% mkvirtualenv -p ~/.pythonz/pythons/CPython-2.7.5/bin/python work

pythonzでインストールしたPythonインタプリタを利用可能な状態にするには、.zshrcを編集して、環境変数PATHの値を下のように設定しなければならない。
export PATH=$HOME/.pythonz/pythons/CPython-2.7.5/bin:$PATH

$PATHの設定値を変更したら、ターミナルを再起動して、pythonz側のPythonインタプリタが有効になっているか確認しておこう。
% which python
/Users/yuhri/.pythonz/pythons/CPython-2.7.5/bin/python
% python --version
Python 2.7.5


■virtualenvとvirtualenvwrapperのインストール


この記事の最終目標はpythonzだけでPython環境を構築することなので、続いて、上でインストールしたPython環境へvirtualenvとvirtualenvwrapperを追加する手順について説明していく。

virtualenvとvirtualenvwrapperライブラリをインストールするには「easy_install」というコマンドが必要になるが、このコマンドはsetuptoolsというライブラリの中に含まれている。そこで、まず最初にPython環境へsetuptoolsをインストールしてやる。setuptoolsのインストールは次のコマンドで行える(最後の「rehash」はzshを使っている場合のみ必要なコマンド)。
% curl -kL https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | python
% rehash

上のez_setup.pyというファイルはsetuptoolsをインストールするためのPythonスクリプトで、このスクリプトをPythonインタプリタで実行してやることでsetuptoolsをインストールできる。ただし、pythonz側のPythonインタプリタが最優先で実行されるように$PATHを変更しておかないと、Mac OS XやHomebrew側のPython環境へsetuptoolsがインストールされてしまうので注意が必要だ。

setuptoolsのインストールが終わったら、「easy_install」コマンドが利用可能になっているはずだ。続いて、このコマンドを使って、pipライブラリをインストールする(最後の「rehash」はzshを使っている場合のみ必要)。
% easy_install pip
% rehash

最後に、「pip」コマンドを使って、virtualenvとvirtualenvwrapperライブラリをインストールする。
% pip install virtualenv
% pip install virtualenvwrapper

これでvirtualenvとvirtualenvwrapperがインストールできたが、virtualenvwrapperはインストールしただけでは有効にならない。virtualenvwrapperを有効にするには、下のような設定記述を.zshrcへ追加する必要がある。
# virtualenvwrapper settings
if [ -f $HOME/.pythonz/pythons/CPython-2.7.5/bin/virtualenvwrapper.sh ]; then
export WORKON_HOME=$HOME/.virtualenvs
source $HOME/.pythonz/pythons/CPython-2.7.5/bin/virtualenvwrapper.sh
fi

virtualenvwrapperによって作成される仮想環境の全ファイルは環境変数WORKON_HOMEで指定したディレクトリの中に格納されるので、あらかじめこのディレクトリを作成しておかなければならない。
% mkdir .virtualenvs

上の操作がすべて終わったら、ターミナルを再起動してやれば、virtualenvwrapperのコマンドが使えるようになっているはずだ。試しに「mkvirtualenv」コマンドを使って、仮想環境を作成してみると良いだろう。
% mkvirtualenv work
New python executable in work/bin/python
Installing Setuptools....................................................................
.........................................................................................
.................................................................done.
Installing Pip...........................................................................
.........................................................................................
.........................................................................................
........................................................................done.
(work)% which python
/Users/yuhri/.virtualenvs/work/bin/python
(work)% python --version
Python 2.7.5

以上でpythonzとvirtualenv, virtualenvwrapperを組み合わせたPython開発環境の構築は終わりだが、pythonzで別のバージョンのPythonを追加して、そのPythonインタプリタを使って仮想環境を作成する方法も説明しておく。例として、Python 3.3.2の仮想環境を作成してみる。まずは、pythonzでPython 3.3.2をインストールしてやる。
% pythonz install 3.3.2
Downloading Python-3.3.2.tgz as /Users/yuhri/.pythonz/dists/Python-3.3.2.tgz
########################################################################## 100%
Extracting Python-3.3.2.tgz into /Users/yuhri/.pythonz/build/CPython-3.3.2

This could take a while. You can run the following command on another shell to track the status:
tail -f /Users/yuhri/.pythonz/log/build.log

Installing CPython-3.3.2 into /Users/yuhri/.pythonz/pythons/CPython-3.3.2

Installed CPython-3.3.2 successfully.

上のメッセージの中で示されているとおり、Python 3.3.2のファイル一式は$HOME/.pythonz/pythons/CPython-3.3.2というディレクトリの中に格納される。したがって、Python 3.3.2の仮想環境を作成するには次のコマンドを実行しれば良い。
% mkvirtualenv -p ~/.pythonz/pythons/CPython-3.3.2/bin/python work3
Running virtualenv with interpreter /Users/yuhri/.pythonz/pythons/CPython-3.3.2/bin/python
Using base prefix '/Users/yuhri/.pythonz/pythons/CPython-3.3.2'
New python executable in work3/bin/python
Installing Setuptools....................................................................
.........................................................................................
.................................................................done.
Installing Pip...........................................................................
.........................................................................................
.........................................................................................
........................................................................done.
(work3)% which python
/Users/yuhri/.virtualenvs/work3/bin/python
(work3)% python --version
Python 3.3.2

一度pythonzとvirtualenvwrapper環境を構築してしまえば、任意のバージョンのPyhtonをインストールし、そのPythonインタプリタを使って仮想環境を作成できる。virtualenvwrapperで作成した仮想環境はpythonz側の共通環境とは独立しているので、ライブラリをどんどん追加して好きなように変更していけば良い。

タグ:python pythonz
posted by とみやん at 17:47| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月30日

MacVim KaoriYaをSnow Leopard + Homebrewでビルドした

06/27の記事にMacVimの導入記を書いたが、一昨日MacVim KaoriYaのサイトを覗いてみたら、最新バージョン(20130713版テストリリース)のリリース情報が掲載されていた。Vimの最新の機能であるif_lua(プログラミング言語Luaを使ってVimスクリプトプログラムを書ける機能)に対応したものらしい。これをSnow Leopard用にビルドできるか挑戦してみたら、試行錯誤を繰り返して二日がかりで何とかビルドに成功した。同じ事をやってみたい人は結構いるんじゃないだろうか。有益な情報だと思うので、この作業の記録を残しておく。ビルドを試みたのは以下の環境。

 Mac OS X 10.6.8 Snow Leopard
 Xcode 4.2 + Command Line Tools(デフォルトコンパイラ:LLVM-GCC 4.2.1 build 2336.1.00)
 Homebrew 0.9.4

MacVim KaoriYaの最新版のバイナリパッケージはLion/Mountain Lion用は配布されているが、Snow Leopard用は配布されていない。Snow LeopardでMacVim KaoriYaを使いたい場合は、古いバージョンのバイナリパッケージ(本記事投稿時、20120509リリースが最後のSnow Leopard対応版)を利用するか、ソースからビルドする必要がある。

Homebrew環境でMacVim KaoriYa(20130713版テストリリース)をソースからビルドするには、以下のフォーミュラをあらかじめインストールしておく必要がある。

 python 2.7.x     Python 2.7以降ならどのバージョンでも良い
 mercurial        pythonフォーミュラを先にインストールしておくこと
 python 3.3.2     --use-clang」オプションをつけないとビルドできない(前記事を参照)
 ruby 2.0.0-p247 「--with-suffix」オプションをつけてインストールすること
 lua 5.1.5
 lua52 5.2.1     「brew tap homebrew/versions」でリポジトリ追加後にインストール可
 luajit 2.0.2

MacVim KaoriYaをビルドするために、私が実際に行った作業手順を以下に記す。
  1. 最初に、MacVim KaoriYa本体と依存パッケージのフォーミュラ定義ファイルをダウンロードした。
    $ wget -P /Library/Caches/Homebrew/Formula https://raw.github.com/splhack/homebrew-splhack/master/cmigemo-mk.rb
    $ wget -P /Library/Caches/Homebrew/Formula https://raw.github.com/splhack/homebrew-splhack/master/ctags-objc-ja.rb
    $ wget -P /Library/Caches/Homebrew/Formula https://raw.github.com/splhack/homebrew-splhack/master/gettext-mk.rb
    $ wget -P /Library/Caches/Homebrew/Formula https://raw.github.com/splhack/homebrew-splhack/master/macvim-kaoriya.rb

    /Library/Caches/Homebrew/Formulaというディレクトリへフォーミュラ定義ファイルを置くと、Homebrewはそれらをリポジトリに属さないローカルなフォーミュラとして認識してくれるようだ。

  2. brew edit FORMULA」コマンドを使ってcmigemo-mk, ctags-objc-ja, gettext-mkの各フォーミュラ定義ファイルを開き、いずれも以下のとおりに編集した。
    -    ENV.macosxsdk '10.7'
    - ENV.append 'LDFLAGS', '-mmacosx-version-min=10.7 -headerpad_max_install_names'
    + ENV.macosxsdk '10.6'
    + ENV.append 'LDFLAGS', '-mmacosx-version-min=10.6 -headerpad_max_install_names'

  3. すべての依存フォーミュラをインストールした(依存関係により、nkfとautoconfもインストールされる)。
    $ brew install --HEAD cmigemo-mk
    $ brew install --HEAD ctags-objc-ja
    $ brew install gettext-mk

    私の環境では、ctags-objc-jaのインストール時に次のような警告メッセージが表示された。
    $ brew install --HEAD ctags-objc-ja
    .... ....
    .... ....
    .... ....
    .... ....
    ==> make install
    Warning: Could not link ctags-objc-ja. Unlinking...
    Error: The `brew link` step did not complete successfully
    The formula built, but is not symlinked into /usr/local
    You can try again using `brew link ctags-objc-ja'

    Possible conflicting files are:
    /usr/local/bin/ctags -> /usr/local/Cellar/ctags/5.8/bin/ctags
    /usr/local/include/readtags.h -> /usr/local/Cellar/ctags/5.8/include/readtags.h
    /usr/local/share/man/man1/ctags.1 -> /usr/local/Cellar/ctags/5.8/share/man/man1/ctags.1
    /usr/local/lib/readtags.o -> /usr/local/Cellar/ctags/5.8/lib/readtags.o
    ==> Summary
    /usr/local/Cellar/ctags-objc-ja/HEAD: 8 files, 396K, built in 22 seconds

    ctagsというフォーミュラがすでに存在していると、上の警告メッセージが表示されるようだ。この警告に対応するために、以下のコマンドを実行した。
    $ brew unlink ctags
    $ brew link ctags-objc-ja

  4. brew edit macvim-kaoriya」でMacVim KaoriYaのフォーミュラ定義ファイルを開き、以下のとおりに編集した。
    +    ENV.store 'CC', '/usr/bin/clang'
    ENV.remove_macosxsdk
    - ENV.macosxsdk '10.7'
    - ENV.append 'MACOSX_DEPLOYMENT_TARGET', '10.7'
    - ENV.append 'CFLAGS', '-mmacosx-version-min=10.7'
    - ENV.append 'LDFLAGS', '-mmacosx-version-min=10.7 -headerpad_max_install_names'
    - ENV.append 'VERSIONER_PERL_VERSION', '5.12'
    - ENV.append 'VERSIONER_PYTHON_VERSION', '2.7'
    + ENV.macosxsdk '10.6'
    + ENV.append 'MACOSX_DEPLOYMENT_TARGET', '10.6'
    + ENV.append 'CFLAGS', '-mmacosx-version-min=10.6'
    + ENV.append 'LDFLAGS', '-mmacosx-version-min=10.6 -headerpad_max_install_names'
    + ENV.append 'VERSIONER_PERL_VERSION', '5.10.0'
    + ENV.append 'VERSIONER_PYTHON_VERSION', '2.6'

  5. MacVim KaoriYaの本体フォーミュラのインストールを実行した(ビルド処理はインストールの過程で実行される)。
    $ brew install --HEAD macvim-kaoriya
    ==> Cloning https://github.com/splhack/macvim.git
    Cloning into '/Library/Caches/Homebrew/macvim-kaoriya--git'...
    remote: Counting objects: 3217, done.
    remote: Compressing objects: 100% (2848/2848), done.
    remote: Total 3217 (delta 479), reused 2242 (delta 295)
    Receiving objects: 100% (3217/3217), 14.38 MiB | 151.00 KiB/s, done.
    Resolving deltas: 100% (479/479), done.
    Checking connectivity... done
    Checking out files: 100% (3002/3002), done.
    ==> ./configure --prefix=/usr/local/Cellar/macvim-kaoriya/HEAD --with-features=huge --enable-multibyte --enable-netbeans --with-tlib=ncurses --enable-cscope --enable-perlinterp=dynamic --enable-pythoninterp=dynamic --enable-python3interp=dynamic --enable-rubyinterp=dynamic --enable-ruby19interp=dynamic --enable-luainterp=dynamic --with-lua-prefix=/usr/local --enable-lua52interp=dynamic --with-lua52-prefix=/usr/local/Cellar/lua52/5.2.1
    Warning: inreplace: replacement of '-L/usr/local/Cellar/readline/6.2.2/lib' with '' failed
    ==> make
    ==> make
    ==> install_name_tool -change /usr/local/opt/gettext-mk/lib/libintl.8.dylib @executable_path/../Frameworks/libintl.8.dylib /usr/local/Cellar/macvim-kaoriya/HEAD/MacVim.app/Contents/MacOS/Vim
    ==> install_name_tool -change /usr/local/lib/libmigemo.1.1.0.dylib @executable_path/../Frameworks/libmigemo.1.1.0.dylib /usr/local/Cellar/macvim-kaoriya/HEAD/MacVim.app/Contents/MacOS/Vim
    /usr/local/Cellar/macvim-kaoriya/HEAD: 2060 files, 42M, built in 3.3 minutes

  6. ビルドとインストールが終了した後の後片付け的な作業として、次のコマンドを実行した(最後のコマンドは、ctagsが存在している場合のみ実行すれば良い)。
    $ brew uninstall cmigemo-mk
    $ brew uninstall ctags-objc-ja
    $ brew uninstall gettext-mk
    $ brew link ctags

    MacVim KaoriYaの依存フォーミュラに含まれる実行ファイルやライブラリはインストール時にすべてMacVimアプリ(MacVim.app)の中に組み込まれる。ビルドが完了したらこれらのファーミュラは不要となるので、アンイストールしても構わない。

ビルド処理が正常に終わると、/usr/local/Cellar/macvim-kaoriya/HEADというディレクトリが作成されて、この中にMacVim.appがインストールされる。次のコマンドを実行すると、Finderでこのディレクトリのウィンドウが開く。
$ open /usr/local/Cellar/macvim-kaoriya/HEAD

このウィンドウからMacVim.appを起動して、GUI版MacVimの動作確認を行った。
MacVim-Homebrew_Celler_macvim-kaoriya-FinderWindow-SCShot3077-756x438
MacVim_7.4a.9_BETA-KaoriYa_20130713-GUI_StarupWindow-SCShot3080-578x400.png
ひと通り使ってみて特に問題はないようなので、MacVim.appのリンクを「アプリケーション」ファルダの中に作成した。
$ ln -s /usr/local/Cellar/macvim-kaoriya/HEAD/MacVim.app /Applications

最後に、MacVimをCLI環境から使うための設定を.zshrc(bashを使っている場合は、.bash_profile.bashrc)へ追加した上で(06/27の記事を参照)、ターミナルからMacVimを起動できるか確認した。
MacVim_7.4a.9_BETA-KaoriYa_20130713-CLI_StarupWindow-SCShot3081-505x342.png
こちらも特に問題なく使えるようだった。

LionとMountain Lionでは最新版のMacVimを使っていたが、Snow Leopardだけはいままで古いバージョンを利用していた。これで、やっとSnow Leopard環境でも最新版のMacVimが使えるようになった。やれやれ。

【2013/07/31 追記】

本記事の内容の中で、手順4で示したmacvim-kaoriya.rbに対する以下の追加設定が最大のTips情報じゃないかと思う。
+    ENV.store 'CC', '/usr/bin/clang'

このTipsを発見するまで、macvim-kaoriyaフォーミュラのビルドを20回位繰り返してしまった。作業後記的な内容になるが、最終的にこのTipsにたどり着くまでの過程も書いておく。フォーミュラのインストール時に問題が発生したときの原因究明の方法として参考情報になるんじゃないだろうか。

上の設定を加えていないmacvim-kaoriya.rbで同フォーミュラのインストールを行うと、ビルド処理で下のようなエラー発生していた。
$ brew install --HEAD macvim-kaoriya
.... ....
.... ....
.... ....
.... ....
==> make
==> make
The following build commands failed:
ProcessPCH /var/folders/0g/0gJQyP+3Fp8VP2o8x1ZV+U+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/AppKit-aecgaphphqschsdfwnfucbvwbygl/AppKit.h.gch /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h normal x86_64 objective-c com.apple.compilers.llvmgcc42
(1 failure)
make[1]: *** [macvim] Error 65
make: *** [first] Error 2

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting


参考ページEに載っていた情報から、MacVimはLLVM-GCCではなくClangでコンパイルする必要があることはすぐに判った。Xcode 4.2のデフォルトコンパイラはLLVM-GCCだ。それで「--use-clang」や「HOMEBREW_CC="clang"」を使って「brew instal」を実行してみたが、上のエラーは解決せずメッセージの内容もまったく変化しなかった。

Homebrewには「brew install --interactive FORMULA」というコマンド(いわゆる対話モード)が存在していて、これを使うと、ソース展開とパッチ適用後に処理が停止してシェルが起動する。このモードを使って、シェルの起動後にXcodeからsrc/MacVim/MacVim.xcodeprojを開いて、同プロジェクト内のすべてのコンパイラ設定を「LLVM GCC」から「Apple LLVM compiler」(Clang)に変更した上でフォーミュラのインストールを再実行してみたが、それでもエラーメッセージが下のように変わっただけだった。
The following build commands failed:
ProcessPCH /var/folders/0g/0gJQyP+3Fp8VP2o8x1ZV+U+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/AppKit-cavbwwzljiowuebyijkvejsxfmbx/AppKit.h.pth /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)
make[1]: *** [macvim] Error 65
make: *** [first] Error 2

そして、さらに調べていくと、「brew install --interactive FORMULA」の実行時に「CC=cc」という環境変数が存在していることを発見した。「--use-clang」や「HOMEBREW_CC="clang"」を指定しても、この環境変数の値は変化していなかった($HOMEBREW_CCの値はちゃんと変化していた)。この事実から、MacVimのconfigureスクリプトは$CCの値だけでコンパイラコマンドのパスを認識しているのではないかという推論が浮かんだ。対話モードの中で、「export CC=clang」と環境変数の設定を変更した上で「./configure」と「make」を実行すると、エラーメッセージの最後の部分が「com.apple.compilers.llvmgcc42」から「com.apple.compilers.llvm.clang.1_0.compiler」へ変化したことで、この推論が正しいという確信を持った。それで、対話モードのシェルの中で「export CC=/usr/bin/clang」とコンパイラコマンドをフルパスで指定してやったら、ようやくMacVimをビルドすることに成功した(この問題を解決するのに二日間悩んでいたので、ビルドが通った瞬間に「やったー」と叫んでしまった)。

という訳で、Snow Leopard + Xcode 4.2 + Homebrew環境でのMacVim KaoriYaビルド時の障害の原因を究明するために「brew install --interactive FORMULA」というコマンドがとても役に立った。また、フォーミュラのインストール時に~/Library/Logs/Homebrew/FORMULAディレクトリの中にログファイルが作成されるが、これらのファイルからもいくつかの収益な情報が得られた。もしHomebrewでフォーミュラをインストールするときに問題に遭遇したら、この2つを上手く利用すると良いだろう。そうすれば、ほとんどのケースで問題の原因が判明するんじゃないかと思う(問題の原因が判明しても、その原因の解決策をどうやって実現するかで悩む場合はあるだろうが・・・)。

【参考ページ】

  1. splhack/homebrew-splhack ・ GitHub
  2. homebrew-splhack/macvim-kaoriya.rb at master ・ splhack/homebrew-splhack ・ GitHub
  3. Building - macvim-kaoriya - MacVim-KaoriYaのビルド方法 - MacVim KaoriYa - Google Project Hosting
  4. Readme - macvim-kaoriya - はじめにお読みください - MacVim KaoriYa - Google Project Hosting
  5. Building ・ b4winckler/macvim Wiki ・ GitHub


タグ:Homebrew MacVim
posted by とみやん at 18:21| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月29日

[Homebrew] Python 3.3.2をXcode 4.2でビルド時にエラーに遭遇した

MBA13上にPython開発環境を構築するために、HomebrewでPython 3.3.2をインストールしようとしたら、ビルド処理でエラーが発生してまたしてもハマッてしまった。本現象に遭遇したのは以下の環境。

 Mac OS X 10.6.8 Snow Leopard
 Xcode 4.2 + Command Line Tools(デフォルトコンパイラ:LLVM-GCC 4.2.1 build 2336.1.00)
 Homebrew 0.9.4

brew install python3」実行時のログを下に示す。
$ brew install python3
==> Downloading http://python.org/ftp/python/3.3.2/Python-3.3.2.tar.bz2
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/python3/3.3.2 --enable-ipv6 --datarootdir=/usr/local/Cellar/python3/3.3.2/share --datadir=/usr/local/Cellar/python3/3.3.2/share --enable-framework=/usr/local/Cellar/python3/3.3.2/Frameworks CFLAGS=-I/usr/local/include -I/usr/local/opt/sqlite/include LDFLAGS=-L/usr/local/lib -L/usr/local/opt/sqlite/lib MACOSX_DEPLOYMENT_TARGET=10.6
==> make
File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
File "<frozen importlib._bootstrap>", line 855, in _load_module
File "<frozen importlib._bootstrap>", line 989, in get_code
ValueError: unmarshallable object
make: *** [pybuilddir.txt] Segmentation fault

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting

These open issues may also help:
https://github.com/mxcl/homebrew/issues/20327
https://github.com/mxcl/homebrew/issues/20591
https://github.com/mxcl/homebrew/pull/21008
https://github.com/mxcl/homebrew/issues/21288
https://github.com/mxcl/homebrew/pull/17547
https://github.com/mxcl/homebrew/issues/21489


エラーメッセージの最後にヘルプ情報になりそうなURLが示されているが、これらのページを参照してもこの現象の解決方法は載っていなかった。そこで、またGoogle先生に聞いてみたら、下の2つのページを見つけた。

 python3 failed to build on 10.6 ・ Issue #19592 ・ mxcl/homebrew ・ GitHub
 Version 3.3.2 build failed (ValueError: unmarshallable object) ・ Issue #29 ・ yyuu/pyenv ・ GitHub

2番目のページにコンパイラをClangに変えたら解決できた書かれていたので、試しに「--use-clang」オプションをつけてみたら、Python 3.3.2のフォーミュラをインストールすることに成功した。
$ brew install --use-clang python3
==> Downloading http://python.org/ftp/python/3.3.2/Python-3.3.2.tar.bz2
Already downloaded: /Library/Caches/Homebrew/python3-3.3.2.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/python3/3.3.2 --enable-ipv6 --datarootdir=/usr/local/Cellar/python3/3.3.2/share --datadir=/usr/local/Cellar/python3/3.3.2/share --enable-framework=/usr/local/Cellar/python3/3.3.2/Frameworks CFLAGS=-I/usr/local/include -I/usr/local/opt/sqlite/include LDFLAGS=-L/usr/local/lib -L/usr/local/opt/sqlite/lib MACOSX_DEPLOYMENT_TARGET=10.6
==> make
==> make install PYTHONAPPSDIR=/usr/local/Cellar/python3/3.3.2
==> make frameworkinstallextras PYTHONAPPSDIR=/usr/local/Cellar/python3/3.3.2/share/python3
==> Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.7.tar.gz
######################################################################## 100.0%
==> /usr/local/Cellar/python3/3.3.2/bin/python3.3 -s setup.py install --force --verbose --install-scripts=/usr/local/Cellar/python3/3.3.2/bin --install-lib=/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages --install-scripts=/usr/local/Cellar/python3/3.3.2/bin
==> Downloading https://pypi.python.org/packages/source/p/pip/pip-1.4.tar.gz
######################################################################## 100.0%
==> /usr/local/Cellar/python3/3.3.2/bin/python3.3 -s setup.py install --force --verbose --install-scripts=/usr/local/Cellar/python3/3.3.2/bin --install-lib=/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages --install-scripts=/usr/local/Cellar/python3/3.3.2/bin
==> Caveats
Setuptools and Pip have been installed. To update them
pip3 install --upgrade setuptools
pip3 install --upgrade pip

To symlink "Idle 3" and the "Python Launcher 3" to ~/Applications
`brew linkapps`

You can install Python packages with
`pip3 install <your_favorite_package>`

They will install into the site-package directory
/usr/local/lib/python3.3/site-packages

See: https://github.com/mxcl/homebrew/wiki/Homebrew-and-Python

Apple's Tcl/Tk is not recommended for use with Python on Mac OS X 10.6.
For more information see: http://www.python.org/download/mac/tcltk/
==> Summary
/usr/local/Cellar/python3/3.3.2: 4700 files, 92M, built in 3.0 minutes

どうやら、Xcode 4.2のデフォルトコンパイラであるLLVM-GCCを使ってビルドしたときに起きる現象のようだ。ちなみに、Python 3.3.0とPython 3.3.1でも同じ現象が起きることを確認した。これらも同じ対応策でフォーミュラをインストールできた。

Homebrewの最新のフォーミュラ定義ファイルは、Xcode 4.2.1以前の古いバージョンでは積極的なテストは行われていないのかもしれない。また、旧バーションのフォーミュラ定義ファイルは基本的にメンテナンスが行われていないようなので、フォーミュラの旧バーションをインストールする際に色々な問題に遭遇する可能性が高くなる。こういう問題に対処する自信がないユーザは常に最新バージョンのフォーミュラを利用するようにした方が良いだろう。

タグ:python Homebrew
posted by とみやん at 01:40| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月28日

[Homebrew] brew update時の"error: Your local changes to the following files would be overwritten by merge:"の解決方法

Macを起動すると必ずHomebrewのフォーミュラ管理情報の更新を行なっているが、今日「brew update」を実行したら、下のようなエラーが表示された。
$ brew update
error: Your local changes to the following files would be overwritten by merge:
Library/Formula/python.rb
Library/Formula/python3.rb
Please, commit your changes or stash them before you can merge.
Aborting
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

Homebrewを使い始めて以来このエラーは何度も見ている。「git checkout」でいずれかのフォーミュラのバージョンを変更した状態だと、このエラーが表示されることがある。「brew update」がフォーミュラ定義ファイルの書き換えを行おうとしていることがその原因だ。つまり、ローカルなフォーミュラ定義ファイルが最新版ではないために更新できないと言っている。

上のエラーを解決するには、エラーメッセージの中で指摘されたフォーミュラを一旦最新バージョンに戻す必要がある。つまり、次のようなコマンドを実行しなければならない。
$ cd /usr/local
$ git reset HEAD Library/Formula/python.rb
Unstaged changes after reset:
M Library/Formula/python.rb
$ git checkout -- Library/Formula/python.rb
$git reset HEAD Library/Formula/python3.rb
Unstaged changes after reset:
M Library/Formula/python3.rb
$ git checkout -- Library/Formula/python3.rb

ちなみに、「git status」というコマンドを使うとGitリポジトリの状態を調べることができるので、上の各操作を行う度にこれを実行すると良い。すると、次に実行すべきコマンドについてガイド情報を表示してくれる。
$ cd /usr/local
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: Library/Formula/python.rb
# modified: Library/Formula/python3.rb
#
$ git reset HEAD Library/Formula/python.rb
Unstaged changes after reset:
M Library/Formula/python.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: Library/Formula/python3.rb
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Library/Formula/python.rb
#
$ git reset HEAD Library/Formula/python3.rb
Unstaged changes after reset:
M Library/Formula/python.rb
M Library/Formula/python3.rb
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Library/Formula/python.rb
# modified: Library/Formula/python3.rb
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -- Library/Formula/python.rb
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Library/Formula/python3.rb
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -- Library/Formula/python3.rb
$ git status
# On branch master
nothing to commit, working directory clean

上の操作がすべて終わった後に再度「brew update」を実行すれば、今度は上手くいくはずだ。
$ brew update
Updated Homebrew from e454140e to 04e04869.
==> Updated Formulae
bison haproxy libupnp mysql pyenv python3 serf tbb varnish
groonga jenkins moreutils node python ranger subversion ushare vcsh

上の実行結果から、エラーメッセージの中で指摘されていたpythonとpython3のフォーミュラ情報が更新されたことが判る。

なお、この状態で「brew upgrade」を実行すると、pythonとpython3フォーミュラはいずれも最新バージョンが追加インストールされてしまう。最新バージョンをインストールしたくなければ、これらのフォーミュラを既存のバージョンに再度変更しておくことを勧める(07/21の記事を参照)。
タグ:Homebrew
posted by とみやん at 13:28| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月26日

[Homebrew] フォーミュラのバージョンを切り替えて使う方法

07/2107/23の記事にバージョンを指定してフォーミュラをインストールする方法を書いたが、複数のバージョンを共存させて切り替えて使う方法についても紹介しておこう。Scala(Javaに代わってここ数年採用例が増えている、オブジェクト指向言語と関数型言語の特徴を統合したマルチパラダイムのプログラミング言語)を例として、具体的なやり方を以下に書いていく。

すでにHomebrewでScala 2.10.2がインストール済みだと仮定して話を進めていく。まずは、現在インストール済みのscalaフォーミュラのバージョンを確認しておく。
$ brew info scala
scala: stable 2.10.2, devel 3
http://www.scala-lang.org/
/usr/local/Cellar/scala/2.10.2 (97 files, 33M) *
Built from source
From: https://github.com/mxcl/homebrew/commits/master/Library/Formula/scala.rb
==> Options
--with-docs
Also install library documentation
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d

続いて、scalaフォーミュラの利用可能なバージョンを確認しよう。
$ cd /usr/local
$ brew versions scala
2.10.2 git checkout 8a43e86 Library/Formula/scala.rb
2.10.1 git checkout 39f9385 Library/Formula/scala.rb
2.10.0 git checkout 8ca07aa Library/Formula/scala.rb
2.9.2 git checkout 8896425 Library/Formula/scala.rb
2.9.1-1 git checkout 2e7cbfe Library/Formula/scala.rb
2.9.1 git checkout b78cfbd Library/Formula/scala.rb
2.9.0.1 git checkout cb1ab23 Library/Formula/scala.rb
2.9.0 git checkout 4002978 Library/Formula/scala.rb
2.8.1 git checkout 0e16b9d Library/Formula/scala.rb
2.8.0 git checkout fdb41a3 Library/Formula/scala.rb

ここでは、Scala 2.9.2をインストールしてみる。「git checkout」によって、これからインストールするscalaフォーミュラのバージョンを変更する。
$ git checkout 8896425 Library/Formula/scala.rb

すると、scalaフォーミュラの情報は下のような表示に変わる。
$ brew info scala
scala: stable 2.9.2, devel 2.10.0-RC5
http://www.scala-lang.org/
/usr/local/Cellar/scala/2.10.2 (97 files, 33M) *
Built from source
From: https://github.com/mxcl/homebrew/commits/master/Library/Formula/scala.rb
==> Options
--with-docs
Also install library documentation
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d

この状態で「brew upgrade FORMAULA」を実行すれば、上で指定したScala 2.9.2が追加インストールされる。
$ brew upgrade scala
==> Upgrading 1 outdated package, with result:
scala 2.9.2
==> Upgrading scala
==> Downloading http://www.scala-lang.org/downloads/distrib/files/scala-2.9.2.tgz
######################################################################## 100.0%
==> Downloading https://raw.github.com/scala/scala-dist/27bc0c25145a83691e3678c7dda602e765e13413/completion.d/2.9.1/scala
Already downloaded: /Library/Caches/Homebrew/scala
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Summary
マグカップ /usr/local/Cellar/scala/2.9.2: 38 files, 26M, built in 5.3 minutes

ここで再度scalaフォーミュラの情報を取得すると、下のような表示に変わる。
$ brew info scala
scala: stable 2.9.2, devel 2.10.0-RC5
http://www.scala-lang.org/
/usr/local/Cellar/scala/2.9.2 (38 files, 26M) *
Built from source
/usr/local/Cellar/scala/2.10.2 (97 files, 33M)
Built from source
From: https://github.com/mxcl/homebrew/commits/master/Library/Formula/scala.rb
==> Options
--with-docs
Also install library documentation
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d

上のフォーミュラ情報から、2つのバージョンのScalaがインストール済みであることが判る。そして、Scala 2.9.2の方に「*」印がついているが、これは現在有効状態になっているバージョンを示している。

Scala 2.9.2ではなくScala 2.10.2を利用したければ、「brew switch FORMULA VERSION」というコマンドを使う。
$ brew switch scala 2.10.2
Cleaning /usr/local/Cellar/scala/2.10.2
Cleaning /usr/local/Cellar/scala/2.9.2
12 links created for /usr/local/Cellar/scala/2.10.2
$ scala -version
Scala code runner version 2.10.2 -- Copyright 2002-2013, LAMP/EPFL

上と同様に次のコマンドを実行すれば、Scala 2.10.2からScala 2.9.2へ切り替えることができる。
$ brew switch scala 2.9.2
Cleaning /usr/local/Cellar/scala/2.10.2
Cleaning /usr/local/Cellar/scala/2.9.2
12 links created for /usr/local/Cellar/scala/2.9.2
$ scala -version
Scala code runner version 2.9.2 -- Copyright 2002-2011, LAMP/EPFL

この「brew switch FORMULA VERSION」というコマンドは、/usr/local下の各ディレクトリ内のライブラリ、ヘッダファイル、pcファイルのシンボリックリンクの削除や作成を行なっているだけで、フォーミュラ本体に含まれるファイルの移動などは行なっていない。ライブラリ、ヘッダファイル、pcファイルの実体をすべてリンクとして管理するHomebrewのやり方はとてもスマートだ。

Scala 2.9.2が不要になって削除したい場合は、次のコマンドを実行すれば良い。
$ brew switch scala 2.10.2
Cleaning /usr/local/Cellar/scala/2.10.2
Cleaning /usr/local/Cellar/scala/2.9.2
12 links created for /usr/local/Cellar/scala/2.10.2
$ cd /usr/local
Hestia-YuhriForest% brew versions scala
2.10.2 git checkout 8a43e86 Library/Formula/scala.rb
2.10.1 git checkout 39f9385 Library/Formula/scala.rb
2.10.0 git checkout 8ca07aa Library/Formula/scala.rb
2.9.2 git checkout 8896425 Library/Formula/scala.rb
2.9.1-1 git checkout 2e7cbfe Library/Formula/scala.rb
2.9.1 git checkout b78cfbd Library/Formula/scala.rb
2.9.0.1 git checkout cb1ab23 Library/Formula/scala.rb
2.9.0 git checkout 4002978 Library/Formula/scala.rb
2.8.1 git checkout 0e16b9d Library/Formula/scala.rb
2.8.0 git checkout fdb41a3 Library/Formula/scala.rb
$ git checkout 8a43e86 Library/Formula/scala.rb
$ brew cleanup scala
Removing: /usr/local/Cellar/scala/2.9.2...

上で使っている「brew cleanup FORMULA」というコマンドは、現在「git checkout」されているバージョン以外をすべて削除してくれる。上では、残したいScala 2.10.2のフォーミュラ定義ファイルを「git checkout」した後このコマンドを実行しているので、Scala 2.9.2が削除されている。Scala 2.9.2のフォーミュラ定義ファイルを「git checkout」した状態で「brew cleanup scala」を実行すると、Scala 2.10.2の方が削除されてしまうので注意した方が良い。また、「FORMULA」をつけ忘れて「brew cleanup」を実行すると、インストール済みの全フォーミュラが対象になってしまうので注意が必要だ。

上記のフォーミュラのバージョンを切り替える機能は、利用シーンによってはすごく便利じゃないかと思う。複数のバージョン仕様の言語でブログラムの動作確認を行いたかったり、プログラム本体と複数のバージョンのライブラリを組み合わたテストを行いたい場合に、これらが楽にできるようになるからだ。仕事としてプログラム開発をやっていると、こういうシーンは頻繁にあるはずだ。Homebrewをプログラム開発のプラットフォーム環境として使っていくと、この機能が役に立つシーンにきっと遭遇するだろう。
タグ:Homebrew
posted by とみやん at 14:02| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月24日

[Homebrew] OpenCV 2.4.5をLion/Mountain Lionへインストール時にビルドエラー

MBA11上でOpneCV + Python環境の再構築作業を行なっている際に、HomebrewでOpenCV 2.4.5をインストールしようとしたら、なぜかビルド処理でエラーが発生してハマッてしまった。このエラーの所為で、最初はopencvフォーミュラをインストールできずに困ってしまった。本現象に遭遇したのは以下の環境。

 Mac OS X 10.7.5 Lion
 Xcode 4.3.3 + Command Line Tools(デフォルトコンパイラ:Clang 3.1 build 318)
 Homebrew 0.9.4

ちなみに、以下の環境のMac miniでもまったく同じ現象が起きる。

 OS X 10.8.3 Mountain Lion
 Xcode 4.6.3 + Command Line Tools(デフォルトコンパイラ:Clang 4.2 build 425)
 Homebrew 0.9.4

brew install opencv」実行時のログを、下に示す(「--with-eigen --with-jasper --with-libtiff --with-qt --with-tbb」というオプションをつけてopencvフォーミュラをインストールしているが、これらはエラーとは関係ない。これらのオプションをつけなくても、ビルド処理でエラーが発生することを確認済み)。
$ brew install opencv --with-eigen --with-jasper --with-libtiff --with-qt --with-tbb
==> Downloading http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/2.4.5/opencv-2.4.5.tar.gz
######################################################################## 100.0%
==> Downloading patches
######################################################################## 100.0%
==> Patching
patching file modules/ocl/include/opencv2/ocl/private/util.hpp
Hunk #1 succeeded at 49 with fuzz 1 (offset 2 lines).
patching file modules/ocl/src/safe_call.hpp
==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencv/2.4.5 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST
-Wno-dev -DCMAKE_OSX_DEPLOYMENT_TARGET= -DWITH_CUDA=OFF -DBUILD_ZLIB=OFF -DBUILD_TIFF=OFF
-DBUILD_PNG=OFF -DBUILD_JPEG=OFF -DBUILD_JASPER=OFF -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF
-DPYTHON_INCLUDE_DIR='/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/Headers'
-DPYTHON_LIBRARY='/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib'
-DPYTHON_EXECUTABLE='/usr/local/opt/python/bin/python2' -DWITH_QT=ON -DWITH_TBB=ON ..
==> make
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libopencv_highgui.2.4.5.dylib] Error 1
make[1]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/all] Error 2
make: *** [all] Error 2

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting


困ったときのGoogle先生頼みで、この問題の解決方法を聞いてみたら、本家本元のhomebrew-scienceのGitHubサイトに下のようなページが存在するのを発見した。

 OpenCV failed to build on 10.8.3 ・ Issue #221 ・ Homebrew/homebrew-science ・ GitHub

このページの情報によると、暫定的な解決方法として、次のどちらかの対策によって上の現象を回避できるらしい。
  1. ffmpegフォーミュラをアンインストールする。
  2. --env=std」オプションをつけて、インストールを実行する。

対策Aは試さなかった。ffmpegをアンインストールするということはOpenCVのビデオキャプチャ機能を使えなくなるということなので、これは避けたかったからだ。対策Bの方は簡単なので試してみると、確かに「brew install --env=std opencv」を実行すると、OpenCV 2.4.5のフォーミュラをインストールできた。

取りあえずインストールできたのでこれで良いかとも思ったが、上のページの中に、OpenCV 2.4.5のフォーミュラ定義ファイルopencv.rbに対するPull Request承認待ちパッチのリンクが存在するのを見つけた。さらに、このパッチを適用済みのopencv.rbのコードも下のページで見ることができる。

 homebrew-science/opencv.rb at 418c94fd5a2ff757ea1e11b8ea1d89ab4e230ba3 ・ idanw/homebrew-science ・ GitHub

近日中に、OpenCV 2.4.5のフォーミュラ定義ファイルはこのページの内容に置き換わるのではないかと予想される。それなら、先んじて既存のopencv.rbをこのページのコードに置き換えてやれば、OpenCV 2.4.5をインストールできるんじゃないかと考えた。実際にこのアイデアを試したら上手くいったので、以下にその手順を書いておく。
  1. まずは、homebrew/scienceリポジトリのフォーミュラ定義ファイルが格納されているディレクトリへ移動した。
    $ cd /usr/local/Library/Taps/homebrew-science

  2. 既存のopencv.rbのバックアップを作成した。
    $ cp -p opencv.rb opencv.rb.orig-245

    特定のバージョンのフォーミュラ定義ファイルは「git checkout」で取得できるので(前記事を参照のこと)、バックアップの必要性はないかもしれないが、念のためだ。

  3. エディタでopencv.rbを開き、既存のコードをすべて削除した上で、こちらのページのコードをコピベして保存した。

  4. opencvフォーミュラのインストールを実行した。
    $ brew install opencv --with-eigen --with-jasper --with-libtiff --with-qt --with-tbb
    ==> Downloading http://sourceforge.net/projects/opencvlibrary/files/opencv-unix/2.4.5/opencv-2.4.5.tar.gz
    Already downloaded: /Library/Caches/Homebrew/opencv-2.4.5.tar.gz
    ==> Patching
    patching file modules/highgui/CMakeLists.txt
    ==> cmake -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/opencv/2.4.5 -DCMAKE_BUILD_TYPE=None -DCMAKE_FIND_FRAMEWORK=LAST
    -Wno-dev -DCMAKE_OSX_DEPLOYMENT_TARGET= -DWITH_CUDA=OFF -DBUILD_ZLIB=OFF -DBUILD_TIFF=OFF
    -DBUILD_PNG=OFF -DBUILD_JPEG=OFF -DBUILD_JASPER=OFF -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF
    -DPYTHON_INCLUDE_DIR='/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/Headers'
    -DPYTHON_LIBRARY='/usr/local/opt/python/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib'
    -DOPENCV_EXTRA_CXX_FLAGS='-Wunsequenced' -DWITH_QT=ON -DWITH_TBB=ON ..
    ==> make
    ==> make install
    マグカップ /usr/local/Cellar/opencv/2.4.5: 224 files, 43M, built in 6.7 minutes

上の方法でOpenCV 2.4.5をインストールした後、opencv-2.4.5.tar.gzに格納されているPythonサンプル(samples/python2に格納されているプログラム)をいくつか動作させてみたが、特に問題はなかった。

ちなみに、Mountain Lion + Xcode 4.6.3 CLTの環境でも、上と同じ手順でOpenCV 2.4.5のフォーミュラをインストールすることに成功した。

それから、これは有益な情報だと思うが、最新版のOpenCV 2.4.6.1のフォーミュラ定義ファイルのPull Request承認待ちコードも、下のページで見ることができる。

 homebrew-science/opencv.rb at af6d35e85853c3298cb6af8eb2cc9b2c605addc6 ・ adzenith/homebrew-science ・ GitHub

既存のopencv.rbをこのページのコードに置き換えてやれば、HomebrewでOpenCV 2.4.6.1をインストールできるはずだ。

【参考ページ】

OpenCV 2.4 on Mac OS 10.8 導入メモ - $ cat /var/log/shin

タグ:OpenCV Homebrew
posted by とみやん at 14:59| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac

2013年07月23日

[Homebrew] バージョンを指定してフォーミュラをインストールする方法 (2)

07/21の記事にHomebrewでバージョンを指定してフォーミュラをインストールする方法を書いたが、OpenCVをインストールする場合この方法では上手くいかないことが判った。補足的な記事になるが、opencvフォーミュラのバージョンを指定してインストールする方法について書いておく。

OpenCVのフォーミュラはHomebrewのメインリポジトリではなく、homebrew/scienceというサブリポジトリの方に存在している。したがって、まずは、このリポジトリをHomebrewの管理対象として追加してやる必要がある。
$ brew tap homebrew/science

これで、Homebrewでopencvフォーミュラが利用できるようになる。インストールを実行する前に、「brew info FORMULA」でフォーミュラ情報が取得できるか確認してみると良い。
$ brew info opencv
opencv: stable 2.4.5
http://opencv.org/
Not installed
From: https://github.com/homebrew/homebrew-science/commits/master/opencv.rb
==> Dependencies
Build: cmake, pkg-config
Optional: eigen, libtiff, jasper, tbb, qt
==> Options
--32-bit
Build 32-bit only
--with-eigen
Build with eigen support
--with-jasper
Build with jasper support
--with-libtiff
Build with libtiff support
--with-qt
Build the Qt4 backend to HighGUI
--with-tbb
Enable parallel code in OpenCV using Intel TBB
--without-opencl
Disable gpu code in OpenCV using OpenCL

上の操作を行った後、opencvフォーミュラの利用可能なバージョンを調べてみた。
$ brew versions opencv
2.4.5 git checkout ae74fe9 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.4.4a git checkout 3efa797 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.4.3 git checkout 8cb3f45 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.4.2 git checkout b64b319 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.4.1 git checkout 3d32cf1 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.4.0 git checkout 2a8c46b /usr/local/Library/Taps/homebrew-science/opencv.rb
2.3.1a git checkout cdaf83d /usr/local/Library/Taps/homebrew-science/opencv.rb
2.2 git checkout 032047f /usr/local/Library/Taps/homebrew-science/opencv.rb
2.1.1-pre git checkout 2438f42 /usr/local/Library/Taps/homebrew-science/opencv.rb
HEAD git checkout c658897 /usr/local/Library/Taps/homebrew-science/opencv.rb
2.1.0 git checkout ecb6a3e /usr/local/Library/Taps/homebrew-science/opencv.rb

07/03にバージョンアップが実施されてOpenCVの最新版は2.4.6になっているはずだが、Homebrewでは最新版のフォーミュラはまだ作成されていないようだ(フォーミュラの更新はほぼ毎日行われているので、多分近日中にOpenCV 2.4.6のフォーミュラがアップされるじゃないかと思う)。現状Homebrewで利用可能な最新版はOpenCV 2.4.5だが、一つ前のバージョンのOpenCV 2.4.4aをインストールできるか試してみた。

最初に、opencvフォーミュラのバージョンを変更するために、07/21の記事と同じコマンドを実行してみた。
$ cd /usr/local
$ git checkout 3efa797 Library/Taps/homebrew-science/opencv.rb
error: pathspec '3efa797' did not match any file(s) known to git.
error: pathspec 'Library/Taps/homebrew-science/opencv.rb' did not match any file(s) known to git.

すると、上のようなエラーが表示されてしまった。このエラーは、どうも「git」コマンドで指定したファイルがリポジトリの管理対象外だと言っているようだ。「brew tap」で追加したリポジトリの管理情報は、/usr/localではなくどこか別のディレクトリに存在するんじゃないだろうか。それがこのエラーの原因ではないかと推測した。この推測に基づいて、次のコマンドを実行してみた。
$ find /usr/local -name ".git" -print
/usr/local/.git
/usr/local/Library/Taps/homebrew-science/.git

やはり推測どおり、/usr/local以外にもう一つ.gitディレクトリが存在していた。多分homebrew/scienceリポジトリの管理情報はこのディレクトリに格納されているのだろう。だとすれば、opencvフォーミュラのバージョンを変更するには、次のコマンドを実行すれば良いはずだ。
$ cd /usr/local/Library/Taps/homebrew-science
$ git checkout 3efa797 opencv.rb

正解だったようで、今度はエラーは表示されなかった。上のコマンドを実行した後フォーミュラ情報を確認したら、ちゃんと指定したバージョンに変更されていた。
$ brew info opencv
opencv: stable 2.4.4a
http://opencv.org/
Not installed
From: https://github.com/homebrew/homebrew-science/commits/master/opencv.rb
==> Dependencies
Build: cmake, pkg-config
Optional: eigen, libtiff, jasper, tbb, qt
==> Options
--32-bit
Build 32-bit only
--with-eigen
Build with eigen support
--with-jasper
Build with jasper support
--with-libtiff
Build with libtiff support
--with-opencl
Enable gpu code in OpenCV using OpenCL
--with-qt
Build the Qt4 backend to HighGUI
--with-tbb
Enable parallel code in OpenCV using Intel TBB
==> Caveats
The OpenCV Python module will not work until you edit your PYTHONPATH like so:
export PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH"

To make this permanent, put it in your shell's profile (e.g. ~/.profile).

この状態で「brew install opencv」を実行すれば、上で指定したバージョンのopencvフォーミュラをインストールできるはずだ。実際にやってみて、OpenCV 2.4.4aがインストールできることを確認できた。

なお、次のコマンドを実行すれば、opencvフォーミュラのバージョンを最新版に戻すことができる。
$ cd /usr/local/Library/Taps/homebrew-science
$ git reset HEAD opencv.rb
$ git checkout -- opencv.rb
タグ:Homebrew
posted by とみやん at 14:55| Comment(0) | TrackBack(0) | 開発・プログラミング > Mac