.tmux.confをいじってtmuxのエスケープキー(prefix)を変える

~/.tmux.confというのがtmuxの設定ファイル、screenにおける~/.screenrcのようです。
制御キー（screenでいうescapeに相当）を設定するには、

set-option -g prefix C-t
unbind-key C-b
bind-key C-t send-prefix

こんな感じで書きます。C-を付ければControlキーが修飾キーになるようです。
.screenrcのときは

escape ^Tt

みたいに書けばOK。

参考にしたページはこちら：
http://ktjx.blogspot.com/2009/08/tmux.html


■トラブルシューティング
間違ってこんな設定を.tmux.confに書き込んでしまうと、

set-option -g prefix t

Tキーがprefixになってしまうためターミナルからexitやquitを入力させることが出来なくなりtmuxを終了させられなくなります。Control-Cも試してみましたが無視されてしまいました・・・仕方ないので強制的にMacのTerminal.appを落として解決したのですが、問題がその後。tmuxにはセッションを保持する機能があるので、強制的にTerminalを殺してもtmuxのプロセスはまだ生き残っています。再度Terminalからtmuxを起動すると、tmuxがこの生き残っているセッションを復活させてしまうため、設定ファイルを正しく書き換えても反映されなくなってしまい泥沼に突入します。

ということで、tmuxプロセスを先にkillしてから再度tmuxを起動すれば無事に設定が反映されます。こんな恥ずかしいミスをしでかすのは私ぐらいかと思いますが、何かの拍子にお役に立てば幸いです。

Python 2.5系列では__repr__()でunicodeを返すといろいろトラブルが起きる

Django（正確にはapp engine patch）のmanage.py shellで遊んでいるとき、とあるクラスを生成すると必ずUnicodeEncodeErrorが発生していることに気づきました。具体的には以下のような感じ。

>>> from game.models import *
>>> hts = HeroTemplate.all()
>>> ht = hts.fetch(1)[0]
>>> ht.template_name #問題なし
>>> ht.name          #問題なし
>>> hero = Hero(
... name=ht.name,
... symbol=ht.symbol,
... max_life=ht.max_life,
... life=ht.max_life,
... max_move=ht.max_move,
... move=ht.max_move,
... weapon=None,
... item=None,
... )
>>> hero             #ここでUnicodeEncodeError
>>> ht.createHero()  #上記と同じ処理をやるメソッド、これもUnicodeEncodeError

原因を調べていてわかったのですが、Python 2.5系列では__repr__()がunicodeを返すようにしてしまうとトラブルの元になってしまうようです。
参考にしたサイト：
http://d.hatena.ne.jp/alisue/20090402/1238690818

たとえば、

>>> class Abesi:
...   def __repr__(self):
...     return u'¥u3059¥u305a¥u304d¥u3044¥u3061¥u308d¥u30fc'
... 
>>> abesi = Abesi()
>>> abesi #UnicodeEncodeError

これを実行するとabesiを表示しようとしたタイミングでエラーになります。環境はWindowsXP上のCygwin 1.7 + Python 2.5.4で、ターミナル上ではshift_jisを使っています。始めっからターミナルがutf-8を扱えるような環境なら__repr__()でunicodeを返しても上手くいくかもしれません。
しかしながらどこの環境でも動くとはいいがたい状態なので、

• __str__()と__repr__()はstrを返す
• __unicode__()はunicodeを返す

Python 2.5系列ではこのルールを守っておいたほうが無難のようです。Python 3.0からはunicodeがデフォルトになるらしいのでこんな面倒ごとをいちいち考えなくてもよいのでしょうか？いまだにPython 3.0試していませんが、ちょっと興味が湧いてきました。


■っていうかそもそも
Djangoのdjango.db.models.Modelクラスは特にオーバーライドしなくても綺麗な__repr__()を出力してくれるので、デフォルトの__repr__()を使えばよかった＞＜

多少マシになったかな

相変わらずこんなしょぼっちい物を作っていたりします。


■前回からちょっとだけ改善
敵が出るようになりました（キャラの向き滅茶苦茶ですが）。
弾が出るようになりました（タダの自機狙い３Wayですが）。
ちょっとずつデザエモン程度には近づいてきたかなぁと。
あとは自機が動いて弾が出れば一応STGっぽくはなります。

今回作ったところまでの経過をgithubにうｐしてみました。
http://github.com/akisute/MyShooting/tree/338e164b4716ec27a6a9b8d384f7714243f53d2e

最新のソースはこちら。
http://github.com/akisute/MyShooting/tree/master


■今回の気づき
弾の発射とか敵の出現タイミングをフレーム単位で計測して実行しているのですが、cocos2dのフレーム時間はかなりばらつくようです。弾が200発程度出ただけでフレーム時間が2倍になったりします。要するに弾の発射間隔が2倍になります。ちょっとこれはいただけない感じ。毎フレームごとに前フレームから何秒経過したかが取得できるので、それを元に時間単位で発射タイミングを測った方がいいかもしれません。

あとはActionがやたら重いです。何が重いってActionの動き自体よりもActionオブジェクトの作成と解放に時間がかかっている感じです。頻繁に起動が変わったり単純直線移動しかしない動きを再現するとき（たとえば高速弾や自機コントロール）は、昔ながらのvx, vyを使った方法のほうが軽くて良さそうです。