FireFox

http://ja.doukaku.org/174/nested/を見ているときにFireFoxのbugを発見してしまった。なんだか一部のdivが描画されずに黒い四角になってしまう。幅がコンテンツ側で決定されるようなdivが画面からはみ出ているときに起こるように見える。切り分けていないのでなんともいえないが。

ところで、TraceMonkeyはどういう仕組みなんでしょうね？adobeからもらったコードに基づいているとのことですが。参照

* Making bytecode cases in the threaded interpreter even fatter, so the fast cases can stay in the interpreter function.
* Adding a polymorphic property cache, for addressing properties found in prototype and scope objects quickly, without having to look in each object along the chain.

。。。。

Thus tracing is all about speculating that what the interpreter sees is what will happen next time -- that the virtual machine can stop being neurotic.

アイディアとしてはハードの分岐予測とあまりかわらんなぁ。何するかを予測して、それに関連したobjectのpropertyを拾う速度が速くなれば実行速度が向上するでしょうということだね。ハードでは命令やLoadするデータだが。

markdown

wikiの記法を複数サポートするつもりでいろいろ調べている。

先日はreStructuredTextを調べた。こいつはdocutilでサポートされているらしく、使うにはあまり深く考えずにexample.pyの中身をコピーして変えればよいようだ。
実装としてはDocument Treeを作るタイプ。ちょっと複雑なことをやろうとしたら普通。

今日はmarkdownなのだが、pythonでこれを扱うライブラリはすくなくとも二つあって、

• markdown


• markdown2

どちらもシングルファイルmoduleで2000行くらい。後者の著者は処理速度が速くて実装していない仕様も少ないぜといっているが、実装を見る限り前者のほうが好ましい。

まず、後者はインデントが深くてキモイ。つぎにtextの置換処理を重ねている実装なので変更が効かない。これでは独自拡張が入れにくい。一方で前者は仕様の違い(mid wordとか)を気にしているし、なにせコードがきれい。Documnet Treeを生成するタイプで、拡張手段を与えている。

Docutilsの中をのた打ち回る

def new_reporter(source_path, settings):
    """
    Return a new Reporter object.

    :Parameters:
        `source` : string
            The path to or description of the source text of the document.
        `settings` : optparse.Values object
            Runtime settings.

settingsってなんぞや？と思ったが、
Readerのクラスメンバのsettings_specをoptparseに渡して作ったparserで生成したvalueのようだ。

ん～～wikiでrstを使いたいので、StringIOとかに乗せた文字列を食わせてStringIO上に答えを返してほしいのだがどうしたものか。

生産性

pythonとCでだいたい同じことをするコードを書いた。行数レベルで2.5倍、作成時間で4倍くらい差があった。内容はbinary treeの実装 参考 wikipedia

• cのコード


• pythonのコード

rootの扱いが美しくないのだが・・・。

ここでいうところの機能生産性ですな。ここでも同じようなことがかかれている。

真の問題は価値生産性で、これは何を作るか決めた時点（企画）決まってしまい（まれにユーザがほかの使い方を発見して後から価値が生まれることもある）。

まあ、スティーブジョブスと日系メーカとの比較をすれば(intel power book v.s. vaioなど)明らかなのですが、なかなか魑魅魍魎というかロジカルに話を通すのが難しいといおうか、「正しいエゴ」発見のようなものですな。エゴのだけど、それが生み出す商品は正しい、というやつです。


一方で・・・。
大規模なソースコード、何万行までいじれますか? という記事へのコメントの中で、

DF [nifty.com]程度のプログラムでもソースは21,229行もありますが
把握できないという訳ではありません。全体の行数はあまり関係が
無くて、分割統治ができているかどうかが肝で、十万行の塊ひとつ
だと厳しくても、一万行の塊が十個になっていればたいしたことは
ないように思えます。

他人の書いた一万行よりも自分で書いた十万行の方がわかりやすいと
いうのもあるので解らないものを苦労して読解するよりも「自分で書
いてしまう」というのも選択肢としてはありですよね。

「読みやすさ係数」みたいなものがあるとしたら、100倍（自分が満足できるレベルでデザインしたものv.s. 普通にひどいコード）はざらだし、1000倍（同v.s. マジで悲惨なコード）以上違っても驚かないからなぁ。