2013/11/30

Unity を 4.3 にしたら MonoDevelop の補完が効かなくなった

Unity を 4.3 にアップデートしたら、 Mono Develop の補完が効かなくなった話。

環境

  • Mac OSX Mountain Lion
  • Unity 4.3
  • MonoDevelop-Unity 4.0.1

経緯

Unity を 4.2.1 くらいから 4.3 にアップデート。
4.3 の dmg を落としてきて実行する形式でアップデート。
そうすると MonoDevelop の見た目が変わっていて、 Unity な Object の補完が効かない。
どうやら、新規インストールではなくアップデートすると補完が効かなくなる現象があるらしい

解決方法

参考にしたところの通り、消して入れ直したら直りました。
具体的には
$ rm -rf /Applications/Unity/MonoDevelop.localized/
して .dmg から Unity 4.3 を入れ直し。
私の環境ではこれで直りました。

Unity に Blender で作成したアニメーション付きモデルをインポートする

Blender で作成したアニメーション付きモデルファイルを Unity でインポートするとか。

環境

  • Mac OSX Mountain Lion
  • Unity 4.3
  • Blender 2.68a

方法

.blend ファイルを Unity にドラッグアンドドロップする。
インポートされたファイルを選択し、Inspector -> Rig -> Animation Type  を Legacyに変更。
それで OK でした。参考にした記事はこちら

一旦 fbx にエクスポートしてからやる、みたいなのもありましたが .blend がそのまま使えるみたいです。

アニメーションは、 Inspector -> Animations の Clips  に + やらで登録して、Unity内でのアニメーションの名前と Blender でのアニメーションの名前を対応させる。
それから Scene にそのモデルを入れた時に Animation Component を追加とする。
Animation Component の項目は Animation が default のアニメーションで、Animations が使うアニメーションの種類らしい。
なので Animations の size を指定して、 element 0 とかに設定したアニメーションの名前を追加していくと良いみたい。
そこまですると Script から使えるようになって、 animation["<animation_name>"] くらいで参照できる。
アニメーションするには Animation.Play("<animation_name>") とか。

2013/11/26

PyPy ソースコード読み会に参加してきた

PyPy ソースコード読み会に参加してきました。
通算3日くらい。
バージョンは Python は 2.7.2 で pypy は 2.2-dev くらいで commit は 67874:84a635eb05a7 なところ。
環境は Mountain Lion。

これだけ大きいソースを追っていくのは初。
割と分かってないところが多いので間違っていることを書いているかもしれません。

PyPy

Python で言語を定義するとそれを pypy なレベルに落として、最終的にバイナリにしてくれるみたいです。
それが rpython なスクリプトで、例えば pypy は Python の実装を Python Code で書いて、それを実行すると一旦 C なファイルになって、それをコンパイルしてバイナリを生成するみたいです。

pypy-c

公式のページにある
$ pypy ../../rpython/bin/rpython -Ojit targetpypystandalone 
をすると python で実装された python が C に落ちて pypy-c という Python 実行系なバイナリができます。
その時には、  rpython/path/to/*.py は rpython_path_to_*.c みたいに / が _ になった C コードが生成される様子。
--lldebug とかを付けて
$ python ../../rpython/bin/rpython --lldebug -Ojit targetpypystandalone 
にすると lldb とかで追えるようになります。
生成されたコードは変数に5ケタとかの番号が付いてたり goto しまくりで直接読むのは厳しいです。

ちなみに pypy は 生成した C コードや debug object を /private に置くので、しばらくしていると消えてしまうようです。
なので PYPY_USESSION_DIR や PYPY_USESSION_KEEP を設定すると良さそう

とりあえず一旦 C に落ちてからバイナリが作られるので、バイナリを追っても python code は読めなさそう、という結論に。

Python Code を読んでいく

Pypy には大量のモジュールがあるので、それらの知りたいところだけを追おう、ということに。
なのでテストルーチンを最小限に切り出して、それを実行していく形式にしました。
個人的にテストを直接 pdb で追おうとしていましたが、 py.test で書かれてるようで、どうも通常のコードとは勝手が違って断念。
ということで test くらいからめぼしいものを拾ってきて、method 1つを実行できるようにして pdb debug で trace していくことに。
これだと python 側のコードで読めます。
ちなみにテストコード側には space とかの環境っぽいコードは無かったりしたので、 pypy/bin/pyinterpreter.py とかの インタプリタコードな pypy/interpreter/main.py から StdObjSpace のコードを拝借したりで動かし動かし。
おそらくすぐ動く小さいコードは pypy/bin/pyinterpreter.py なので足りないパーツはその辺りにあるんじゃないかな、とか思ってます。

テストを切り出してみる

parser とか astcompiler とかのソースを追いたいので
pypy/interpreter/astcompiler/test/test_compiler.py
の compile_with_astcompiler を拾ってくる。
足りない space とかは
pypy/interpreter/main.py
から拾ったり。mainmodule とか w_globals  とかも。
そんなんで作ったコードがこんな感じ。

pyparser / astcompiler

そんな感じのコードを使って pyparser を読んだり。
tokenize で lines を split したりと割と富豪的。
おかげで高速化とかされていないわけなので素直で読みやすいといえば読みやすいかも。
astcompiler は buld_ast な parse 後のコードから ast を生成する部分をちょろっと読むなど。
token の type に応じて handle_expr やら handle_binop やらの関数で parse した node を拾ってきて AST オブジェクトを new っていく感じらしいです。
あと Python VM なやつは pyinterpreter を追っていったら出てきたような。

symbol table

token から ast にする時に expr_node.type を確認していったりするのですが、 この type が syms.stmt やら syms.simple_stmt やらとガンガン if で比較していく形式。if-elif祭り。
syms.stmt の値は定数の数値なので、 expr_node.type の数値が分かっても syms の何に相当するのかが謎。
なので dir(syms) とかで syms にある attr を拾ってきて getattr(syms, attr) とかしていって逆引きテーブルを作ったりして対応を取ることに。
この辺の対応を確認する便利コードが pypy にありそうだけれどなー、とかなりつつ。
というかこいう enum みたいなコードって 書く/読む 分にはマジックナンバーが隠れて良いけれど、実行していく分にはチェックするの大変だなー、とか思うなど。特にマジックナンバーな値しか分からない時。
そういう時はやっぱり debug helper チックなのでも書いてたら良いのかな。逆引きとか。

所感 / tips / もろもろ

読んでいくというよりは実行していく、といった感じで読んでいきました。
流れが分かりやすいし使わないところは読まなくて良いので、こんな感じで読むのかー、と。

ただ、実行の仕方分からないとだいぶ大変そうだなー、と。 python 分からない。
一番単純な example とか how to reading sources とかあれば嬉しいよなー、とか。

object の class を見て関連しそうなところとかを探していったり、関数に入ったら l っていってざっくり見てから n/s るのが自然な読み方なのかも?

一見見えないところでも lldb で stepi するとアセンブラに書かれてたりするのでそれを頼りに読むとかあってすごいなー、と。

lldb の debug symbols が /private にあったので読んでたら消えたり、なんか一部のコードを単体で実行したら pypy が動かなくなったり謎ハプニングも。
ちなみに動かなくなったら hg clone しなおしでどうにか直る。
でも hg diff には引っかからなかったのでどこが壊れたのかも謎でした。

とかとかいろいろあった読み会でした。

2013/11/13

MacBookPro のパーティションを切って使っていたらやらかした話

MacBookPro 13-inch, Early 2011 を使っているのですが、パーティション切って運用しているとエラい目にあいかけたのでそのログとか。

ことの発端

もともとは Snow Leopard が入っていて、 Mountain Lion に upgrade する時に「どうせだし Snow Leopard も残しておくか」とパーティションを切って、 Mountain Lion + Snow Leopard の2つ運用をしていました。
Mountain Lion を使い続けてパーティションの容量が一杯になったので、 Snow Leopard を消して容量を確保しようとしたのですが

悲劇

パーティション分割は起動中にできたので、結合も簡単だろうと思ってググる。
disk utility.app だとパーティションを消さないと無理そう。
diskutil の mergePartition を使えば良いっぽいことを知る。
そしてサイトのコマンドをペーストして、編集しようとしたらエンター込みでペーストされる。
^c を押すも Recovery HD が吹き飛ぶ。
別に使っていなかったし大丈夫か、くらいのつもりで、残るパーティションを結合しようと試みる。
Mountain Lion 以外を全て統合しきった後に、「unmount できないと結合できないよ」と言われる。
そして残ったのは容量が変わらない Mountain Lion のパーティションとパーティション未割り当て領域のみ。
ちなみにこんな状態でした。なんか EFI のやつとかも吹き飛ばし済という。
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk0
   1:                  Apple_HFS Mountain Lion           159.8 GB   disk0s1

格闘

unmount 状態じゃないと merge できないっぽいので、recovery mode あたりで起動しようと思ったら Recovery HD は吹き飛ばした後。
起動時に cmd + r で何も起動してくれない。
そして、Recovery HD を再作成するには OSX 再インストールしかないらしい。
ということで仕方無くアップデート待ちだった Marvericks にするか、とインストーラを起動するもインストールできませんと言われる。
Mountain Lion Installer を起動するもインストールできませんと言われる。
この辺で割と厄介なことをしてしまったと思う。
仕方無いので Mountain Lion を完全に再インストールすることにする。
が、最後に backup を取ろうとしたら Time Machine の HDD を認識しない。
dock に入れてクリック長押しからのメニューでどうにか認識。なにそれ。
とりあえず怪しいながらもバックアップを取る。

復活

Mountain Lion の Installer を USB に作ってもらって、起動時に option からの boot 。
これは認識してくれた。
そんでパーティションを1つにして一旦フォーマット。
からのOS再インストール。
んで Time Machine から restore 。
これでどうにか帰ってきた。
消しちゃった EFI とかもあるしたぶん復活でしょう。
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:                  Apple_HFS Mountain Lion           319.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

まとめ

  • パーティションは切るのは楽だけれど統合割と面倒
  • ペーストのエンターこわい
  • diskutil さん sudo いらんのこわい
  • Recovery HD は壊しちゃいけない
  • USB/DVD boot なデバイスは残しておくべき
  • Snow Leopard パーティション使った記憶が無い
  • 何気に Snow Leoprad って typo して使っていた
  • Time Machine 重要
  • @各位 ごめいわくおかけしました。

2013/11/11

アプレンティスシップ・パターン を読んだ

アプレンティスシップ・パターン を読みました。

リファクタリング・ウェットウェアを読んだ 後、ドレイファスのモデルとかを知ったのは良いけれど具体的に何をするべきなんだろうか、とか言っていたら kimihito さんからこんな本あるよー、とか勧められたので読みました。

実を言うとだいぶ時間を空けながら読んでしまったのと、訳があまり私に合わなかったので正直斜め読みというか記憶があまり無いというか。

さらっと目次を見ると思い出したのですが、憶えようと思っていたのがお茶の話。
パターンで言う「白帯」とかですね。
新しいことを教えようという時に、今までの考えのみを使って考えていたようであれば、教えようにも教えられない、みたいな話。
「すでに一杯になっているカップを持って、私のもとにやって来たのであれば、私がどうやってあなたに何か飲み物を与えられるでしょうか」
と。本文引用。
どうも私は聞きかじりの知識で対応しようとしてしまう癖があるようなので非常に耳の痛い話。
しかも目次を見直すまで今まで憶えずに忘れていたという……。

技術者にまつわるよう問題に対して、どう対応するべきか、みたいなパターン集でした。

2013/11/04

競技プログラマが知るべき97のこと を読んだ

最近 @_simanman さんと @kanpe777 さんと #ie_procon なる競技プログラミング勉強会をしているのですが、そこで紹介された薄い本。
競技プログラミングに関する TIPS 本です。
kanpe777 さんから借りて読みました。


印象に残っているのは
  • 競技プログラミングはネトゲである
  • float ではなく double を使う
  • 定数倍高速化はムダ
  • 100, 300, 600, 1000
  • コーディング規約
  • コードの綺麗さ
  • 絨毯爆撃
  • Editor な話で Vim が無い
  • 摂動
  • 自作ライブラリ、他人の自作ライブラリ
  • 煩雑なデータ構造へのアクセサ
といった感じでしょうか。



それぞれについてちょっとコメントすると

競技プログラミングはネトゲである

  • みんなが集まってクエスト(問題)を解いていくから、と。なんかそれっぽい。

float ではなく double を使う

  • 精度の関係で double 安定らしいです。

定数倍高速化はムダ

  • これはちょっと耳が痛い話。 
  • 初心者がやりがちらしい話らしくて、定数倍程度のちまちました改善は基本的にムダらしい。 
  • 計算量を見直すレベルじゃないとダメだとか。

100, 300, 600, 1000

  • 競技プログラマには解いた問題によって実力の壁があるんだとか。 
  • それが 100, 300, 600, 1000 らしくて、すごい方々は1000とか解いているらしい。
  • 私は100も解いてない。うーむ。 

 

コーディング規約

コードの綺麗さ

  • 競技プログラミングのコードは基本的に書いて終わりだから、綺麗さをどうしようかという話。 
  • 競技プログラマのコードは汚いんじゃないか、みたいなイメージもあったりなんだりらしいけれど、競技のコードとそれ以外のコードは分けよう、とか。 
  • あと、チーム戦なら競技でもちゃんと書いた方が良いし、自分のためにもちゃんと書こう、みたいな。

絨毯爆撃

  • これは知らなかった。というかその発想は無かった。
  • 撃墜フェーズで良いコーナケースを思い付いたら、それでひたすらに爆撃していくらしい。
  • 大量得点 or 大量失点 の大博打らしいです。

Editor な話で Vim が無い

  • 補完の関係では Visuatl Studio, Eclipse とか、構文チェックでは Eclipse, Visual Studio, Emacs + flymake とかが紹介されてました。 
  • Vim も Makefile 書けば quickfix に syntax error 残るし、 quickrun とか quickrun + watchdogs とか syntastics とか入れたら捗りそうなのになー、とかって私見。

摂動

  • 実数を扱う時には誤差を考慮したりするのだとか。知らない世界でした。

自作ライブラリ、他人の自作ライブラリ

  • 競技で頻繁に使うたコードはライブラリにしたりするのだとか。
  • 他人のライブラリと比較したり自分なりのアレンジを作ったりなんだりするらしい。

煩雑なデータ構造へのアクセサ

  • これは良いなと思った。
  • クラスを作るようなサイズで無い(とか時間が無い)構造体を定義する時とかに、それにアクセスするためだけのメソッドを定義する、というもの。
  • triple の変わりの pair pair だと hoge.first.first とかになって分かりづらいので accessor(my_triple hoge) { return hoge.first.first } とか      


他にもいろいろありましたがこんなところで。
細かい tips もあったりしたので、簡単に手に入るなら手元の置いておいても良いのかな、とか思いました。