2006-07-20

■

私信。こんなとこ読んでる暇があったら仕事しなさい。

S2.NETがmonoで動かねー

XmlReader.Create()がNotImplementedExceptionを投げる、という情報をakirameiさんから聞いたので、ソースを眺めてみましたが、多分コレはvalidation typeがDTDで、かつValidationFlagsでProcessIdentityConstraintsまたはReportValidationWarningsがオフになっているか、ProcessInlineSchemaまたはProcessSchemaLocationがオンになっていると起こるようです。ProcessIdentityConstraintsだけ対応して、あとは無視する方向で直してみました（DTD的には無視できるはず）。

ぶっちゃけ僕のDTDObjectModelにはCreateXsdSchema()というメソッドがあって、XmlSchemaをDTDから生成できるので、content modelのvalidator実装を分ける意味はあまり無いのですけどね（content model以外のvalidationについては分けなければならない）。

というわけでまだ動かなかったら教えてください。＞meiさん

インターネットの法と慣習がスラドのネタになっている

が、所詮スラドクオリティのようだ。実際現時点で具体性に欠ける寸評しか無い。

この連載くらい法制史の細かい部分を解説している法学入門の授業なんてまず考えられないし、法制史なんて大抵は必須科目でも何でもない¹。本当にこれが「法学生なら誰でも知っている」と思っているのなら、その辺の大学院生にこの文章の内容をもとに質問してみるといい。たぶん、「英米は慣習法で大陸はパンデクテンだ」とか、その程度の知識でコメントしているだけなんじゃないか、というのが僕の印象だ。

mono —profileとmono —trace

今さらな話かもしれないけど。

昨日の雑談meetingで、.NET開発にCLR Profilerを使ってみたら呼び出し回数とかいろいろ分かって便利だった、という話が出てきた。その時も少し話したのだけど、これはmonoでも簡単だ。monoを実行するときに —profile オプションを付けて実行すると、終わった後で膨大なプロファイルレポートを標準出力に出してくれる。処理時間のプロファイルとメモリ使用のプロファイルが両方出てくる。

プロファイル結果の読み方というのは、それなりに慣れるまではハマるかもしれない。典型的な例は再帰呼び出しを含むメソッドの実行時間。呼び出される側も呼び出す側も同じメソッドとして計測されてしまうので、プロファイルには向いていない。

たぶん（デバッグ用途で）もっと便利なのはmono —traceで、これはオプションで指定したnamespace, type, method, property等について、呼び出しがあるたびにその情報を標準出力に出してくれる。引数値や戻り値がそれなりに見えるようになるので、error-proneな箇所をこれで特定することができる。使い方はmono —help-traceを参照。

メモリ消費のチェックには、heap-buddyのレポートの方が分かりやすいかもしれない。ただしこちらはLinux用。