このBlogは移転しました。今後は aish.dev を御覧ください。

Ubuntu 13.10 にVMWare Tools をインストールした時のメモ

Ubuntu 13.10 で普通にVMWare Fusion 6 の VMWare Tools をインストールしようとすると、

/vmhgfs-only/inode.c:1893:29: error: ‘struct dentry’ has no member named ‘d_count’
          int dcount = dentry->d_count;

こんな感じでエラーになってしまう。

こちらの記事 を参考に、VMWare Tools側のソースにパッチをあてるとうまく動くようだ

$ cd vmware-tools-distrib/lib/modules/source
$ tar xf vmhgfs.tar
$ curl -O https://raw.github.com/rasa/vmware-tools-patches/master/patches/vmhgfs/vmhgfs-d_count-kernel-3.11-tools-9.6.0.patch
$ patch -p0 < vmhgfs-d_count-kernel-3.11-tools-9.6.0.patch
$ mv vmhgfs.tar vmhgfs.orig.tar
$ tar cf vmhgfs.tar vmhgfs-only
$ cd ../../..
$ sudo ./vmware-install.pl

めんどくさいmock.patch()

unittest.mock モジュールを正しく使って関数を置き換えるというのは以外と難しいもので、Pythonの名前空間について、しっかり把握できてないとうまくいかないことがある。

単純なケースでは、テスト対象のコードが参照している名前で置き換えてやればいい。 例えば

import spam

def ham():
    spam.egg()

というモジュール M の ham() をテストするために spam.egg を置き換えるなら

def test():
    import M
    with patch("spam.egg"):
        M.ham()

となる。また、

from spam import egg

def ham():
    egg()

のように egg を参照している場合、ham() の内部での egg は M.egg への参照なので

def test():
    import M
    with patch("M.egg"):
        M. ham()

となる。

ここで注意しなければならないのが、関数を置き換える対象となるモジュールは、関数を呼び出すときに指定するモジュールではなく、関数が定義されたモジュールだということだ。

例えばもう一つのモジュール、M2 があって、

import M
ham2 = M.ham

となっている場合がある。こんな場合でも、M2.ham2() で呼び出される egg() を置き換えるには

def test():
    import M2
    with patch("M.egg"):
        M2.ham2()

のように、ham を定義したモジュール M の egg を置き換えなければならない。

このように、機械的に mock.patch() を使って置き換えることはできず、置き換える対象の関数がどのように呼び出されているか、ちゃんと調べてなくてはならない。普通はあまり気にしなくても良いのだが、たまに変な import などでどのモジュールを使っているのか調べにくいパッケージなどもある。そういう時は、

@contextlib.contextmanager
def patch_globalref(func, target):
   m = MagicMock()
      with patch.dict(sys.modules[func.__module__].__dict__, **{target:m}):
             yield m

のような関数を用意しておいて、

def test():
    import M2
    with patch_globalref(M2.ham2, 'egg'):
       M2.ham2()

とように、テスト対象の関数オブジェクトのグローバルスコープを直接修正してしまうほうが手っ取り早い場合もある。

ジェネレータの循環参照

以前、ジェネレータが循環参照の一部になっている場合、メモリが開放されなくなるケースがあるという エントリ を書いた。

最近、この仕様が 問題となっていた ようで対策が検討されていたが、ついにトランクにコミットされたようだ。

http://bugs.python.org/issue17807

従来のジェネレータでは、ジェネレータオブジェクトへの参照が全て破棄されて不要となった時に GeneratorExit 例外を送出してコードの実行を再開し、ジェネレータ内の finally 節が実行されるようになっていた。Pythonのコードで書くと、こんな感じになる

class Generator:
   def __del__(self):
      if self.generator:
         self.generator.send(GeneratorExit)

ここで、ジェネレータオブジェクトは __del__ メソッドを持っているため、このオブジェクトが循環参照の一部となっていた場合、ガベージコレクションでは開放できない、というのが上のエントリの話だった。

Python3.4では、上のコードの __del__() メソッドに相当する部分が削除され、代わりに ジェネレータ を実行中のフレームオブジェクトを開放するときに終了処理が起動されるようになった。このため、ジェネレータオブジェクトが循環参照に巻き込まれても、オブジェクトは保存されずに開放されるようになった。

終了処理をジェネレータからフレームに移すとなんで循環参照の問題が解決するのか不思議だったが、パッチを見ると、終了処理が必要なジェネレータでも、リファレンスカウントがゼロになったら無慈悲に削除してしまうようだ。フレームオブジェクトの開放処理を見ると、実行中のコードオブジェクトとそのフレームオブジェクトだけ使って、フレーム開放時にジェネレータの finally 節を実行できてしまうのだ。ジェネレータの後始末をするのにジェネレータ自体は不要だったというのは実に面白い。

ということで、このまま問題がなければ、Pytho 3.4からは安心してジェネレータをあっちこっちから参照できるようになったわけだ。もちろん、フレームオブジェクトを下手に使うとやはり循環参照になってしまうが、これはジェネレータだけの話ではないし、うかつに sys._getframe() を使ってフレームをどっかに保存するようなヤカラは、ひどい目にあえばいい気味というものである。

日本語でreStructuredText

実のところ、私はあんまり reStructuredText /Shinx が好きではない。Markdown と比べるとシンプルさで劣り、TeXと比べると印字品質で劣る。この辺の中途半端さが、restを愛せない大きな理由だが、もう一点、日本語の文章を書くのに適切なマークアップ言語ではない、というのも大きい。英語などの、単語と単語の間にスペースがある言語向けに設定されており、日本語で書こうとするとイライラが溜まってどうしょうもないのだ。

とはいえ、SphinxはPythonの公式ドキュメントで使われているツールでもあり、ちょっと複雑なドキュメントを書くには Pandoc を使うよりは便利なことも多いので、ある程度は使えるようにしてみたい。ということで、私が使っていて一番イライラする、インラインマークアップの改善に取り組んでみた。

通常のrestでは、インラインマークアップの前後に空白や区切り文字が必要なため、

restは*うざい*！

とは書けない。

restは\ *うざい*\ ！

などと書かなければならない。実にうざいので、スペース無しでもマークアップとして認識できるようにしてみた。

https://sourceforge.net/p/docutils/patches/103/

このパッチでは、前後のスペースや区切り文字などのチェックをいっさいチェックせず、`*` などの記号は全てマークアップとなる --no-inline-delimiters オプションを追加している。

$ rst2html.py --no-inline-delimiters sample.rst

ディレクティブでも指定できる。

.. no-inline-delimiters yes

ここでは*普通に*マークアップを書ける

.. no-inline-delimiters no

ここでは\ *書けない*\ !

この方式で日本語環境でも使いやすくなったのではないかと思うが、どうだろうか？現在わかっている問題点として、アンダーラインを含んだ英単語がマークアップとして認識されてしまう、という点がある。

mod_wsgi

とすると、これは mod へのリンクと解釈されてしまうので

mod\_wsgi

と書かなければならない。許容範囲といえば許容範囲な気もするが、できれば治したい気もする。他にもなにか落とし穴があるかもしれない。気がついた点があれば、こちら で議論に参加していただきたい。

知らなかったが、Docutilsの開発者 David Goodger さんの奥様は日本人だそうで、Davidさんも日本語の知識がおありだそうだ。このパッチについても前向きに検討して頂いてる雰囲気なので、興味や意見があれば、ぜひともご協力いただきたい。

PowerPointは僕らのIllustratorだ

普段、図を書いたりすることはそれほどないが、書くときは適当にPowerPointを使って書いてしまうことが多い。このページの図 なんかもPowerPoint製で、けっこう綺麗な図を手軽にかけるので重宝している。

書くのが簡単なのはいいんだけど、書いたあと、画像として出力するのが微妙にめんどくさい。数が多いとうんざりする。ということで、Sphinxの文書を書くときのために、PowerPointのプレゼンテーションから画像を抽出し、png ファイルとして保存するDirectiveを作成してみた。

この拡張は標準の image ディレクティブのパラメータに加え、pptfilename と shapename を指定できる。

.. ppt-shape:: abc.png
   :pptfilename: testppt.pptx
   :shapename: shape-title

pptfilename には、PowerPointプレゼンテーションのファイル名を指定し、shapename には、図形の名前(図形の書式設定|代替テキスト|タイトル で指定した、図形のタイトル) を指定する。Sphinxで文書をビルドする時、プレゼンテーションが更新されている場合は画像を抽出してファイルに保存する。PowerPointがインストールされていない環境では、作成済みの画像をそのまま使用する。

動作環境

インストール

$ git clone git://github.com/atsuoishimoto/pptshape.git
$ cd pptshape
$ python3 setup.py install

使い方

  1. Sphinx の設定ファイル conf.py の、extentions を次のように修正する。
extensions = ['pptshape.directive']
  1. プレゼンテーションの画像は、複数の図形から構成される画像の場合はグループ化して一つの図形に変換し、図形の書式設定で 代替テキスト|タイトル に、画像の名前を指定する。
  2. rst ファイルに、次のディレクティブを記述する。
.. ppt-shape:: abc.png
   :pptfilename: testppt.pptx
   :shapename: shape-title

ppt-shapeディレクティブは、Imageディレクティブと同じ機能をサポートしており、PowerPointがインストールされていない環境（Unix,Macなどを含む)では、Imageディレクティブとまったく同じ動作となる。

ppt-shapeは pptfilename で指定したプレゼンテーションから、shapename というタイトルの画像を検索し、引数として指定した画像ファイルとして出力する。文書のコンパイル時、プレゼンテーションファイルと画像ファイルの更新日付をチェックし、更新された画像ファイルだけを生成する。