[MacOSX] 劇薬 `purge`

最近は2GBしかメモリがないとあっぷあっぷですね…。いい加減4GB以上にしたいんですけど、この前のバッテリー&電源アダプタ購入が痛くてしばらくは無理そうです。とほほ…。

メモリ不足をなんとか誤魔化せないかとメモリ管理(解放)ツールをいくつか試してみたんですけど、どれもあんまりしっくり来なくて…。ターミナルはいつも起動しているんで、どうせならコマンドラインから管理できたらいいなあと思って調べてみたら、`purge`なるものを発見。CHUD Tools(The Computer Hardware Understanding Developer Tools)に含まれているコマンドです。試してみたらビックリするほど解放してくれました。アクティビティモニタで確認してみたら、「現在非使用中」が20MB前後まで激減。ちょっと怖いくらい…（笑）ちなみにpurgeを実行している4、5秒の間は若干動作がカクツキます。

解放するコマンドさえ見つかれば、シェルスクリプトを書くのは簡単。まず、purgeする目安となる空きメモリ量を変数に設定。メモリのチェックでは、topなどを使えば簡単に情報を取得できます(他にも手段はあります)。OSXのtopを使う場合なら、`top -l 1 -n 0 -s 0 | grep '^PhysMem'`みたいな感じでやればメモリの情報を抜き出せます。あとはパイプなりを通してsedとかを利用して"free"の部分を読み取って変数に代入して、最初に設定したメモリ量と比較して、空きが少なかったらpurgeを走らせればいいです。チェックする時間も設定してwhileとsleepで回せば簡易管理スクリプトになります。

ただ、ちょっと調べてみたところ、この`purge`コマンドはメモリ管理に使うべきでないと書いてあるサイトもあったり。2、3日使用してみた限り僕の環境では特に問題はなかったのですが、どの環境・使用法でも安全だと確認できたわけではないのでスクリプトの公開は控えます。まあ…劇薬扱いということで…（笑）purgeを利用してメモリ管理してみたい人は、上に書いたことを参考に自分でスクリプトを書いてみてください。ちなみにAppleスクリプトならGrowlを簡単に利用できるので組み合わせてみると面白いかもしれないですね。僕はAppleスクリプト書かない人間なのでパス。

そんなこんなでしばらくはメモリ2GBで粘ってみるつもりです。

[GPAC] こんなことやってるから…

無駄にリビジョンナンバーが嵩むんですよ…。GPAC陣はコミットする前にテストビルドしないんですかね…？（笑）

http://sourceforge.net/apps/trac/gpac/changeset/3183/trunk/gpac

http://sourceforge.net/apps/trac/gpac/changeset/3184/trunk/gpac

僕は一応複数環境でテストビルドしてからpushするように心掛けています。SSHサーバを立ち上げてビルド環境を提供してくれている某B氏に感謝。

もしビルドできない場合などは連絡ください。時間があるときに地道に更新していますので（笑）

最近利用をやめた（やめる）サービス

• Dropbox
  Mac OS X ServerでFinderとどうも相性が悪い…。


• Skype
  重い。OSX版バグ直らない。そして未来もなくなった…。


• Twitter
  公式の方針が自分の目的・用途からどんどん離れているので…。

簡単にまとめちゃうとこんな感じですが、もちろん他にも色々考えるところがあってです。仕方ない。なくても、まあ、なんとかなるさ（笑） そのうち戻ってもよさそうになったら戻るかもしれませんが、今のところ方針変更などはなさそうですし…。

さて、代用サービスを考える日々が始まるお（＾ω＾）

[MacOSX] ffmpeg binary v0.7b2-31-g033a4a9 [Snow Leopard]

libav-git-v0.7b2-31-g033a4a9.zip

ffmpeg version git-v0.7b2-31-g033a4a9, Copyright (c) 2000-2011 the Libav developers

built on May 16 2011 21:56:45 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)

configuration: --enable-gpl --enable-version3 --disable-doc --disable-ffplay --disable-ffprobe --disable-ffserver --enable-runtime-cpudetect --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --arch=x86_64 --cpu=x86_64 --disable-debug

libavutil 51. 1. 0 / 51. 1. 0
libavcodec 53. 3. 0 / 53. 3. 0
libavformat 53. 0. 3 / 53. 0. 3
libavdevice 53. 0. 0 / 53. 0. 0
libavfilter 2. 4. 0 / 2. 4. 0
libswscale 1. 1. 0 / 1. 1. 0
libpostproc 52. 0. 0 / 52. 0. 0

※ ffmpegはlibx264の検証目的などのために時々ビルドしています。どうせなのでたまーに公開します。ビルドが面倒なときは他のところから持ってきたりもしていたんですけど、Automated FFmpeg Buildsが更新停止になってしまってからは、OS X用のffmpegを定期的に配布している所がなかなか見つからないですね。一応配布する用にいろんなライブラリをstaticリンクしていますが、主目的はやっぱりlibx264検証なので、libx264が更新されないとffmpegの更新もしないと思います。

[MacOSX] x264_L-SMASH binary revision 1995+536 [Snow Leopard]

x264_MacOSX_r1995+536

x264 0.115.1995+536 0d73fda
(libswscale 1.1.0)
(libavformat 53.0.3)
(ffmpegsource 2.15.0.1)
built on Apr 26 2011, gcc: 4.2.1 (Apple Inc. build 5666) (dot 3)
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

[MacOSX] x264 binary revision 1995 [Snow Leopard]

x264_MacOSX_r1995

x264 0.115.1995 c1e60b9
(libswscale 1.1.0)
(libavformat 53.0.3)
(ffmpegsource 2.15.0.1)
built on Apr 26 2011, gcc: 4.2.1 (Apple Inc. build 5666) (dot 3)
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

 

[MacOSX] Search with DEFAULT Browser [Automator]

非常にシンプルなServiceを作りました。ホームフォルダの「ライブラリ」→「Services」に入れれば使えるようになります。システム環境設定からショートカットキーを割り当てると結構便利に使えると思います。

Search with DEFAULT Browser.workflow.zip

※（5/10 13:30追記）wordの末尾に余計な"+"が入る問題を修正しました

作った経緯、解説、使い方などは折り畳み↓

雑談とか3

実は昨日、MacBookのバッテリーと電源アダプターがお釈迦になりました…。バッテリーが14,800円で電源アダプターが7,800円…。痛い出費…orz　それでも部品換えるだけで済んだのでまだマシだと前向きに考えた方がいいかもしれません。修理に出すと、もっと恐ろしい値段に…。

以下、ブラウザ関係の雑談をちょっと。

雑談とか2

まだ#x264devで議論の途中(?)みたいですが、おそらく次回の更新でconfigureとmakeに変更が来ます。簡単に要約してしまうと、

1. configureのオプションとして以下のものが追加される
   --disable-cli、--system-libx264、--enable-static


2. makeのオプションとして以下のものが追加される
   install-cli、install-lib-dev、install-lib-static、install-lib-shared


3. ビルド時にstripしなくなるかもしれない(意見対立中?僕はしない方に一票)

3の変更と関連してmake install-stripが実装されるかされないかはわかりません。そこらへんの議論はまだされていない様子。この記事の内容から更に変更になる場合もあると思うので、ビルダーの方々は更新が来たらdiffに目を通すことをお勧めします。シェルスクリプトとMakefileに注意すればいいだけなので、ちょっと調べながら眺めてみれば変更内容は理解できると思います。

また別件ですが、GPAC Repositoryは管理上の点からどうしてもrebaseをせざるを得ません。svnの更新を取り込み、git svn rebaseをしますが、このときにconflictが発生した場合はそれを修正してgit rebase --continue、を繰り返して、すべてのパッチのconflictが解消したらビルドの確認をしてpush -fしています。このときに歴史が書き換えられ、他の環境からpullする時にconflictが発生します。そういうときはパッチ適用前のリビジョン(つまりgit logで見たときにAuthorがgolgol氏や僕でないコミット)をgit logから探し、そこにgit reset --hardしてから再度pullするとうまくいきます。GitHubに公開されているD_S氏のx264-devel repositoryを利用している人は既に手慣れた作業かもしれません。まあよくわからないときはgit cloneし直すのが一番簡単です…（笑）

更にもう一つだけ注意点を。このようにして更新をしていくと、conflictする度に過去のコードを書き変えることになります。つまり、ある時点で作ったバイナリのソースコードを、過去に遡って取得できなくなります。ライセンスを考え、バイナリ配布をする場合には、バイナリを作った時点で適用されているパッチをバックアップしておくか、またはソースコードを丸々残しておくことをおすすめします。

パッチはgit format-patchで取得できます。その時点でのソースコードを丸々取得する場合はgit archiveを利用すればいいと思います。僕はgit archiveが手軽だと思います（圧縮ファイルを伸張すればパッチを当てなくてもすぐにビルドにできますし）。使い方はこんな感じ。

[gist id=950385]

zipならもうちょっとシンプルにこんな感じ。

[gist id=950360]

コマンドが面倒な人はGitHubのページからDownloadをクリックしてGit Snapshotを取得してください。