渋日記@shibu.jp

圧縮テクスチャ。現代的なグラフィックス処理の大半はメモリ間転送ですよね。圧縮テクスチャはGPU内のメモリ使用量と転送量を削減してパフォーマンスもアップさせる魅惑のテクニックです。きっとスマートフォンのバッテリーの持ちも良くなることでしょう。

iOSはPowerVRを一貫して使っているので、PVRフォーマットが標準です。Androidの方はいちおうETC1という共通フォーマットはあるのですが、アルファチャンネルが持てなかったりするのでデバイスごとの最適なフォーマットを使うのが普通みたいです。

• ATiTC: 元ATi(現AMD)のフォーマット。ATCとも呼ばれています。ATiのモバイル向けのプロセッサは現在Qualcommがリリースしています。よく使われていrます。アルファチャンネルの有無、アルファチャンネルの特性で3種類の内部フォーマットがあります。
• DXTC: Direct X用共通フォーマットみたいです。nVidiaのTegra系が利用しています。これも、データの種類ごとに3〜4種類の内部フォーマットがあるらしい。
• PVR: iOS系と同じPowerVRを載せているデバイスで使います。圧縮率、アルファチャンネルの有無で2x2の4種類あります。
• ETC1: エリクソン社が作った標準フォーマットですが、ARM社自身が作っているMaliというGPUがこれのみをサポートしています。

そのうち、ETC2というアルファチャンネルをサポートしたフォーマットが共通で使えるようになるらしいです。このあたりは、こちらのブログを上から下まで拝むように読みまくる方が正しい情報を得られると思います。

開発ツールのみであれば、WindowsかMacだけでもいいとは思うのですが、ビルドサーバとか考えるとLinuxサポートも欲しくなるかもしれないので、その観点でマルチプラットフォームで入手可能か？で調べています。全部の検証をしたわけではないです。あくまでもメモです。

PVRフォーマット

PowerVRをリリースしている、Imagination社のサイトにツールなりなんなりが色々あります。要ユーザ登録。PVRTexToolが変換ツールです。GUIツールですが、コマンドラインからも使えるらしい。パッケージに、Windows 32/64, Linux 32/64, Mac 32の5バージョンが含まれています。Windows版だけはDXTCサポートみたい。ずるい。Apple限定でよければ、iOS用のSDKに変換ツールが付いてきます。

ライブラリとしても提供されていますので、ツールチェーンに組み込んだりもしやすいかな、と思います。ただし、ビルド手順を見ると、SDKに含まれるライブラリとかヘッダも必要とか色々書かれていて、家の遅いネットでダウンロードするのが時間がかかりそうなので詳しくおいかけてません。SDKはOpen GL ES1.1と、ES 2.0用と分かれていリリースされています。

DXTCフォーマット

今回は僕の作業では特に必要はないので詳しくは調べていませんが、nVidia社が変換ツールのソースをMIT License！で公開しています。コメントを見ると、Linuxでも動くよ、と書かれています。Macは時々落ちるかも・・・と書かれています・・・。

ATiTC/ETCフォーマット

なかなか調べにくかったのがこいつです。DXTCファイルから無理やり変換も見つけましたが、1ビット情報を無理やり落としてしまっていたりとちょっとデザイナーさんから怒られそうな感じ。AMDはWindows向けのツールしか提供していませんし、QualcommのAdrenoSDKもzipファイルを展開すると.exeファイルががががが。

でも、あきらめずに.exeファイルでインストールすると、変換用のライブラリが手に入ります。Windows32/64用とMac用。それにWindowsMobile、webOS、Androidもサポートしているので実機上の変換もできそうです。Linuxは残念ながら対象外。

また、Windows専用ですが、QCompressというGUI/CUIのツールも付いてきます。@nakamura001の啓示に従い、wineで動かしてみようと思います。

$ sudo port install wine
: (待つ)
$ wine ~/Downloads/AdrenoSDK/AdrenoSDK.2.3.00.exe

ふつーにWindowsっぽいダイアログが出て、インストールが行われます。初回のwine起動時は環境作ったりで時間がかかるかも。ホームの.wine以下にWindowsっぽいディレクトリ構造ができます。/users/Public/Documents/にテスト用の画像を置いてみました。

$ cd ~/.wine/drive_c/AdrenoSDK/Tools/QCompress
$ wine QCompressCmd.exe c:\\users\\Public\\Documents\\test.png c:\\users\\Public\\Documents\\test.atc "ATC RGBA Explicit"
QCompessCmd v0.01.00 (c)2011 QUALCOMM Incorporated

フォルダを見てみると、test.atcが出来ています。やったね。

上記の例で使ったQCompressがETC1にも対応しています。以上終了。

まとめ

やっぱり、Windowsの方が細かいツール類は充実していますねー。一部無理やりなところもありましたが、ひと通り欲しいデータは得られそうです。

レビューにちょびっと参加した、Pythonプロフェッショナルプログラミングが無事発売されたようです。おめでとうございます！わざわざ、アメリカにまで献本を送って頂きました。ありがとうございます。ホントにアメリカなんだぜ、というのを証明するために、USのトイザらス限定のクラシック・ソニック10インチフィギュアと、日本未発売のアニメーターズ・コレクションのポカホンタス、サン・フランシスコのローカルなアイスのThree Twinsと一緒に写真撮ってみました。

Amazonでも入荷待ちになっていますね。Amazonで買えないときは、弊社の親会社(DeNA)が運営するビッダーズで検索すると、見つかるかもしれませんよ。ポイントも付くかも？

本のタイトル的にはエキスパートPythonプログラミング とかぶっていますし、いくつか同じテーマを扱った章もあります。ですが、こちらはより実践的な、仕事で使えるような内容がより多くなっています。テーマが同じでも、より深堀してあったり(Sphinxのドキュメント)、より新しい内容を元に書かれていたり(パッケージ管理)、最近ではより広く使われているもの(Jenkins)を対象としていたり、エキスパートPythonプログラミングを持っている人でも、「おおっ」っと思える内容が多いです。まぁ、エキスパートPythonプログラミングの方は、Pythonという言語を深く深く取り扱っている本なので、当然両方そろえるべきですね【ステマ】

とくに実践的だな、と思えるのが想定環境です。最近のシステム開発だとウェブ上のシステムがかなりの割合を占めていると思いますが、仮想PCを使って、それの上で開発をすると説明されています。もしかしたら他のRailsとかの本もそうなっているのかもしれませんが(最近全然そちらは追いかけていない)、個人的には「なるほどー」と思いました。以前、大規模にPythonで開発していたときは、Windows XP上でコードを書き、Djangoで動作確認をしながら、本番環境(Windows Server 2003)にデプロイして・・・とかやっていました。細かい差であっても、結構デプロイ作業で手間暇がかかったりするんですよね。また、開発環境をシステム上に入れてしまうと、Pythonのバージョンなどで引きずられてしまったり・・・と。当時のPCは非力すぎて仮想PCは難しかったという事情もあったのですが、いろんな仕事を受託で引き受けて、ばっちり開発しているようなBeProudでは、そのあたりはしっかりとしているんだなぁ、と思いました。

かなりスキルの高い開発者を固めている印象のあるBeProudの、実践でつちかってきたノウハウがばっちり書かれた本に仕上がっています。Pythonと書かれていますが、半分ぐらいの章はPythonでなくても役に立つ話が書かれています。とても良い本です。ぜひ、みなさんお手にとって、レジまで運んでお金を払い、東京で毎月定期的に開催されているBPStudyという勉強会にも参加して、できるエンジニアの人たちのありがたいお話を聴きながら、本にサインをもらうと良いと思います。

by www.frontendeveloper.com under CC BY-SA

あ、近況報告ですが、DeNAから子会社のngmocoに転籍となり、サン・フランシスコに引越しました。また暇見つけて詳しく書きます。

MacのOSS関連のツールのインストールは昔からいろいろ歴史があります。最近の事件としては、MacPortsがほぼデファクトだったときに、Homebrewが出てきて一躍人気になり、MacPortsからの引越しネタが一時期の技術ブログでさかんに書かれたことですかね。

で、僕もいろいろ使っていました。最近は、環境を作りなおす際に時間節約と思ってHomebrewを使っていたのですが、どうしてもBoostの最新版がインストールできず(手元のフォーミュラがupdateでも更新されず、手元のフォーミュラの参照しているアーカイブはすでにsourceforge上から削除)、困ってMacPortsに戻しました。そしたらびっくり！ビルド済みのバイナリパッケージを落としてくるようになってました。

依存関係がやたら多い(X11とかも含む)py27-pilをインストールしても、7分半(fontconfigのactivateに時間かかってた)。今までのように、ビルドをしかけてから、オヤスミなさいまた明日する必要はないです。あ、僕のマシンはHDDのCore 2世代のMacBook Proです。ディスク暗号化とかいろいろかかっていてかなり重いです。Windows 95を思い出すぐらい・・・

インストールの過程を見ても、必要なパッケージはだいたい自分のサイトのところに置いていて、サードパーティのサイトのリンク切れとかに悩まされられない安心感もいいですね。ビルドしないからSSDみたいな環境の人にいいと思います。スペースが余計に使われないので。また、ビルドしないので、HDDみたいな環境の人にいいと思います。ビルドの時間がかかりませんし。なにより、CPUパワーと時間が食われて熱となって消えていくわけですから、バイナリを使ったほうがエコですよね。gentoo好きみたいなビルド好き以外の人はMacPortsを選んでおけば間違いないと思います。作業のインフラとしては。

まぁ、比較してみると、ちょっとパッケージに収録されているバージョンが古かったり(node.jsは0.6.10。Homebrewは0.6.14)、というのはありますが、gitとか、安定している仕事のツールを揃えるにはいいんじゃないでしょうか？

今、Boostを+universalでインストールしていますが、基本バイナリで、見つからないやつだけソースコードからビルドしている模様。icuのuniversalバイナリはなかったか・・・でも、icuのソースはmacports.orgから取ってきていました。Boostのソースはsourceforgeでしたけど。

Homebrewさん、お世話になりました。

僕はSphinx-Users.jpの創設者です。そんでもって、Sphinx-Users.jpの会長をやっていました。先月、次の代表に譲ったので今は違います。現在の会長は@tk0miyaさんです。通称、世界の小宮。副会長は前期からの引き続いて@shimizukawaさんと、新規の@shkumagaiさんです。できる人ほど忙しい、という法則の通り、みんな暇ではないのですが、きちんとビジョンを持った、良いメンバーだと思います。

僕が代表を辞した理由は、転勤によるものです。今はベイスターズで有名な東京のDeNAで働いています。実は野球以外にソーシャルゲームをやっている会社でして、僕もそちらの仕事をしています。来月から、アメリカの子会社のngmoco:)に転勤になります。サンフランシスコです。日本でのコミュニティのマネジメントはできなくなってしまいます。ただ、大きな成長のチャンスを与えてくれたDeNAにはとても感謝しています。

Sphinx-Users.jpは変わったソフトウェアのコミュニティで、Sphinxと、一般的なドキュメンテーションを対象にしています。コミュニティのミッションは、Sphinxやドキュメンテーションに関する情報を集約し、発信していくことです。僕がSphinxに出会ったのは2009年。僕は大学のころから、SWIGやらC++のリファレンスやら、アジャイルソフトウェア開発スクラムやら、実践eXtremeプログラミングやらの翻訳をしたりしていました。Erlang Efficiency Guideというドキュメントを翻訳しているときに、@Voluntasというとんでもない男にSphinxを教えてもらいました。どうとんでもないかというと、自分が読みたい英語の文章があったら、他の人に興味を持たせて、そいつに翻訳させてしまうという・・・ある意味人使いのうまい奴です。日本のPython界とErlang界を影で操っているのはこの男です。某トイプー使いのトイプーさばきとどちらが上か気になります。そんなこんなでSphinxに興味を持ち、リファレンスのドキュメントを日本語に翻訳したりしました。その後Sphinxのコミュニティを作りました。コミュニティの最初のイベントは単なる飲み会だったのですが、偶然その日にSphinx 1.0がリリースされて、偶然リリースパーティー(世界で唯一)になってしまったのは良い思い出です。その後、Sphinxは僕の右腕として大活躍しました。本を5冊ほどSphinxで書きましたし(別の2冊が進行中)、仕事のドキュメントも書きました。僕の持つスキルの中でもかなりの重要度です。

コミュニティイベントには、かなり熱心な人が多く集まりました。PHPのコミュニティのメンバーもいました。@tk0miyaさんもそのようなアクティブなメンバーの一人です。Pythonの勉強がてら、Blockdiagシリーズを次々と作っては公開しました。去年の11月にはsphinxjp.shibukawaという名前で誕生日プレゼントのモジュールを作ってプレゼントしてくれました。おかげで今週、DeNAの同僚から不具合の報告を受けることになったのですが・・・他のメンバーも同様です。@shimizukawaさんはSE向けのドキュメントテンプレートを作成したり、HTMLのテーマを簡単にインストールする拡張を公開したり、Windowsのインストーラも作成しています。@shkumagaiさんは、なかなか刺激的なプレゼンテーションのテーマを作っていたりします。他のメンバーもいろいろな貢献がありました。全部おぼえきらないほどです。日本からの貢献をまとめて紹介するページをコミュニティページに足さなかったのは失敗でした。

Sphinx-Users.jpはすでにコラボレーションの仕組みを持っています。ウェブサイトのリポジトリに誰かがpushすると(もちろんソースはSphinx)、裏でサーバがpullして自動でビルドします。さくらの廉価な月500円プランなので、Jenkinsとかを使うことはできませんでしたので、cronを使って実装しています。オフラインの勉強会に参加できなくても、外からコミットはできます。新しいリーダーは多くのイベントを開催してくれそうです。ソフトウェア開発の速度がドキュメンテーションやコミュニケーションの速度を超えるまでは、ドキュメンテーションは重要なもので在り続けるでしょう。PythonやErlangなどのようなすばらしいシステムはすばらしいドキュメントを持っています。そういう意味で、Sphinxのスキルは、プログラマにとっての良い習慣になっていくでしょう。Sphinx-Users.jpの今後の発展を期待しています。

そうそう、Sphinx-Users.jpにはひとつ迷信があります。僕も@shimzukawaさんも、Sphinx-Users.jpの三役をしている時に、相手を見つけて結婚しました。@tk0miyaさんは、会長に就任して1ヶ月もたたずに、彼女ゲッツ宣言を出していました。Sphinxに関わる人は幸せになっちゃいますね！

I am a founder of Sphinx-Users.jp. And I was a leader of Sphinx-Users.jp. Generational change was done last month. Now the leader of community is @tk0miya (his byname is "World Komiya"). Sub leaders are @shimizukawa (he continued) and @shkumagai. Basically they are all busy but they have clear vision and great members.

The reason of I have to resign the leader is job transfer to a affiliated company. I am working at DeNA Co.,Ltd, Tokyo, Japan. It is a social game company. And I will move to ngmoco:) LLC it is in San Francisco, USA. I won't be able to manage community in Japan. I would like to say thank you to DeNA for giving me chance to grow up. I am exciting.

Sphinx-Users.jp is a unique community. It deals not only Sphinx but also generic documentation topic. Its mission is gather and spread information about Sphinx and documentation. I met Sphinx in 2009. From my courage days, I translated many documents. SWIG, C++ reference, Agile Software Development with Scrum, Practical Guide to eXtreme Programming and so on. During translating Erlang Efficiency Guide, blamed guy @Voluntas taught Sphinx to me. If he found any interesting topic in English, he made other guys translate in Japanese. He is the rule of Python and Erlang in Japan. I was interested in Sphinx and I translated the reference document into Japanese. After that, I made a community about Sphinx. First event of that community was just drinking party. But Sphinx 1.0 was released at the same day, so it became release party by chance. It was a good memory. After that, I wrote many document on Sphinx. It includes 5 published books (and 2 are under writing) and business work. Now Sphinx is an one of most important my skill.

Many good members came to the community event. It includes PHP community members. @tk0miya is one of them. He start creating Sphinx extension, Blockdiag series with learning Python. L ast November, he gave me special birthday present. It was sphinxjp.shibukawa, it has my name in it. So I reported the bug of that extension this week from my coworker... Other guys too. @shimizukawa uses Sphinx in his work and opened his document template for software consulting. And he created HTML template extension and Sphinx installer for Windows. @shkumagai created super impressive presentation theme. I can't remember all community member's commitment. I should have created show case page in Sphinx-Users.jp website.

Sphinx-Users.jp already made collaboration system. If I commit to the website's repository(of course it uses Sphinx too!), hosting server pulls and build automatically. My cheap host server ($5/month, no transfer fee) doesn't use cool daemon system like Jenkins, so it is based on cron... super simple. So I can't attend offline event anymore, but I can commit from USA. And new leaders will hold many offline events. Documentation have been important until programming speed will overtake documentation(communication) speed. Good software have good document. Like Python and Erlang.The skill of Sphinx is good habit for all programmers. I am crossing my finger for continue growth of Sphinx-Users.jp.

Oh, I forget one more thing. I have to tell the rumor of Sphinx-Users.jp. When I and @shimizukawa were leader of Sphinx-Users.jp, we found partners and god married. And @tk0miya got girl friend within a month from becoming the leader. Sphinx gives us happy :)

by chooyutshing under CC BY-NC-SA

さて、クリスマス・イブになりました。みなさまいかがお過ごしでしょうか？昨日のソニック・ジェネレーションズのイベントで、ハードロックアレンジのクリスマスソングを聞くまではクリスマスイブのことなどすっかり忘れていました。

今日はまさかの三週目のPyPy アドベントカレンダーのエントリーを書いています。

RPythonでスレッドを使ってみる

Pythonとほぼ互換のPyPyでは当然のスレッドをサポートしています。PyPyはRPythonで書かれていてtranslate.pyでビルドされています。つまり、RPythonで作る実行ファイル用のスレッドサポートがpypyのコードのどこかにあるはずです。ためしにgrep -r "thread" *としてみると・・・いろいろわんさか引っかかりますね。その中でも、pypy/module/thread/以下のモジュールがあやしそうです。

pypy/module以下のフォルダは、RPythonで処理されたり初期化されたりして、最終的にPyPyの組み込みライブラリとして使われるモジュール群になります。thread以外にも、bz2やzipなどのファイルアーカイブ関連とか、_multiprocessing、pyexpatなどもこの中にあります。

オブジェクトスペース

さて、この中のモジュールをそのままコピーすればいいのかというとそうではありません。@jbkingさんのアドベントカレンダーのエントリーで説明されている通り、RPythonにはオブジェクトスペースという概念があります。言語の基本的な論理構造をインタフェースとして切り出したものです。こちらにオブジェクトスペースで提供しているインタフェースの数々があります。

たとえば、is_trueを書き換えると、Rubyみたいに0を真として扱うような言語が作れますし、演算子を書き換えると、PerlやAWKのように、適当に文字列表現の数値を変換してから計算するような言語が作れるといった寸法です。callを書き換えて遅延評価やmemoizeを実装することも可能かもしれません。

pypy/module/以下のライブラリは、このオブジェクトスペースが整備された、言語処理系のためのライブラリとして実装されています。pypy/module/thread/__init__.pyを見ると、pypy/module/thread/os_thread.pyからstart_new_thread関数をインポートしていますが、こちらのコードを見ると、最初の引数にspaceとあります。

我々にはオブジェクトスペースなど不要！

ですが、RPythonを言語を作るためではなく、マゾっ子志向プログラミング言語(MOPL)として、あくまでも、ふつうのプログラムを作るための処理系として使う場合には、オブジェクトスペースを1から作るのは大げさです。そのため、このPyPy向けのモジュールを参考にしながら、実装していく必要があります。

逆に言語を作りたい人は、このあたりから勉強していくといいのかもしれません。基本的には、パーサを作って、オブジェクトスペースを操作するための命令列を作る、というのがRPython Toolchainを使った言語作りです(僕の理解では)。

さて、os_thread.pyを見ると、ll_thread.pyの関数を呼び出しています。ざっとこの2つのモジュールをコードリーディングしてみると、つぎのようなことが分かりました。

• ll_thread.start_new_thread()を使えばスレッドが作れる。
• ll_thread.start_new_thread()にはパラメータを渡せない・・・
• os_threadでは、グローバル変数？を使ってパラメータ渡しをエミュレートしている。
• os_threadではパラメータ渡しでトラブルが置きないように、スレッド起動時にロックをかけている。
• スレッドの最初ではll_thread.gc_thread_prepare()を呼ぶ必要がある

このように、コードリーディングした結果を手で実装してみて、確認していきます。

スレッドをためしてみた

できあがったのが上記のコードです。グローバル変数の読み書きのタイミングよりは、list.pop()の方がちょっとは安全かな？(要出展)ということで、スレッド分パラメータをあらかじめ作っておいてpop()していますが、まぁこれは実験コードですので、本番コードを作る場合にはPyPyの実装と同じく、ロックを使う実装にすべきです。スレッドごとに指定された時間分スリープしながら(重い仕事をしているイメージ)、終わったら、自分のIDをコンソールに出力しています。translateで実行ファイルを作ってみて、実行するとつぎのように表示されます。

$ ./testthread-c 
finish task:1
finish task:2
finish task:1
finish task:3
finish task:1
finish task:4
finish task:2
finish task:1
finish task:5
finish task:1
finish task:3
finish task:2
finish task:1
finish task:1
finish task:4
finish task:2
finish task:1
finish task:3
finish task:1
finish task:5

どうやらきちんと実行できているようですね。ちなみに、translate.pyには--threadオプションがあるのですが、付けても付けなくても、普通に動きました。

まとめ

スレッドを題材に使いましたが、説明したかったのはつぎのようなことです。

• RPythonでできることを調べるなら、PyPyのコードが参考になる
• 言語を作らないなら、オブジェクトスペースに依存した部分を取り払って使う必要がある

それでは最後になりました。つぎは@drillbitさん？

taken by brewbooks under CC BY-SA

PyPy Advent Calenderの第二回目のバトンが回って来ました。こんかいは時間がないので、さらっと。

RPython用のライブラリ、rlibを探る冒険その2

rlibを探検してみるエントリーの第二弾です。アドベントカレンダーの中では、shomah4aさんがclibffiというモジュールを使って、Cで書かれたライブラリの関数を呼び出していました。

初めての方もいるかもしれないので、軽く関連情報をおさらいしてみましょう

• PyPyは、Pythonで書かれたPythonインタプリタである。
• Pythonで書かれたといっても、CPythonの上で実行されるわけではなく、RPython Toolchainというツールを使ってCやllvm、Java、.netに翻訳されてバイナリが作られる。
• このバイナリを作る用に機能を制限したPythonがRPythonである。
• RPythonで書かれたプログラムはtranslate.pyで変換するか、Python上で実行できる
• RPythonでCに変換すると、40倍ぐらい早くなっちゃったりする。
• RPythonの制約はかなり厳しく、マゾっ子指向プログラミング言語(MOPL)である。

詳しくは、アドベントカレンダーの他のエントリーも見ると良いと思います。

rlibには何が含まれるの？

rlibについては、PyPyのドキュメントが参考になります。名前から何をやっているのか分かるものもあれば、わかりにくものもあります。僕もまだすべて試したわけではないので・・・ちなみに、pypy/pypy/rlib以下にあるモジュールを不用意にimportすると、ビルドできないモジュールもありますので要注意。何がどうなっているのかよく分からないのですが・・・

• listsort
• nonconst
• objectmodel
• rarithmetic
• rbigint
• rrandom
• rsocket
• streamio
• unroll
• parsing

$ telnet localhost 5000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
server : connection start 

hello world
hello world

$ ./server_rsocket-c 
waiting for connection...
connection start
'cv: 'hello world