No Such Blog or Diary

Ethereal の続き．http://www.wireshark.org/ より入手可能．一年半くらい前に名前が変わったそうだけど今まで気づいてなかったのでメモ．アイコンが派手になった以外見た目も何も変わらない．

うまく使えずにごちゃごちゃやってたけど最終的に落ち着いた方法：

(setq tramp-default-method "sshx")

を .emacs に追加して ssh 経由をデフォルトにしつつ， cygwin の ssh-agent でキー認証をかけておいて meadow をそのコマンドラインから起動．

落ちとしては，HOME の設定が meadow 用と cygwin 用で別々になっているため .emacs がうまく読まれなかったり，同じく HOME のせいで known_hosts へのキーの追加に失敗したり，キー追加確認用の YES/NO 選択で応答不能になったりと．

とりあえず HOME の設定を整理しようかなと思う．

管理者権限での実行は runas コマンドで実行アカウントを切り換えればできるらしい．でも，Administrator アカウント自体が有効にされていなかったために何度試しても失敗しまくった．

ということで，Administrator アカウントの有効化：スタートメニューとかのコンピュータの右クリックメニューの管理（コンパネからコンピュータの管理でも可）→ システムツールの下のローカルユーザとグループ → ユーザ → Administrator を選択してプロパティ開いて無効化のチェックをはずして閉じる → Administrator を選択してパスワード設定．これでやりたい放題．

Vista でうまくできない．どういう管理になってるんだ？　管理者権限のアカウントだけど管理者権限でプログラムを動かすにはどうすればいいんだろう？　いろいろと書込み禁止で作業できん…

はてなっぽくかけるという NP_HatenaLike というプラグインを入れてみたのだけど， <pre> タグ内に空行（空白のみを含む）があるとその行で <pre> タグの効果を切られてしまう．でも &nbsp; を書き込んでおけば切られることはない．ということで，ソースを <pre> で囲むときに空行があるときは &nbsp; を書くようにした．

もうひとつ．Nucleus のDBバックアップを行うと，行頭に # がある行はバックアップ用スクリプト中のコメントとして扱われてしまい，データが吹き飛ぶことになる．Cのソースとかの場合 #include とかで先頭に # が来るため結構きつい．そこで，# を &#35; という風に文字参照に置き換えて書くようにした．

これらの条件の下，NP_SyntaxHighlighter を有効にしてみた．その結果，&#35; が # にならずに &#35; のままハイライティングされるようになってしまった．当然 &nbsp; もそのまま残って & だけに色がつくとかいう状況になった．原因は NP_SyntaxHighlighter がこれらの参照をうまく扱えないことにある．

ということで，NP_SyntaxHighlighter を少々書き換え． highlight_code の先頭付近で参照の置換をしている部分に必要な置換を追加．さらに， <pre> タグ直後に入ってしまう改行を回避．

$string = str_replace ( array ( '&quot;', '&apos;' , '&lt;' , '&gt;', '&apos;', '&#35;', '&nbsp;', '&amp;' ), array ( '"', "'", '<', '>', '?', '#', ' ', '&' ), $string );
$string = preg_replace('/^[ ]*[\n\r]/','', $string);

んで，重要なのが NP_SyntaxHighlighter の前に NP_HatenaLike を置くこと．NP_SyntaxHighlighter が &nbsp; を空白にしてしまうので逆向きだと <pre> が切れる．

とりあえずこれで大きく変な部分が解消された．あとはバックスラッシュが消えてしまう部分をどうにかすれば…

前の実験に使った TeX ソースでは，ソースが HDD にある場合と RAMDisk にある場合とで特に実行時間の差は見られなかった．そのため，前回の実験はソースを HDD において実行時間を計っていた．でも，ひょっとしたらソースが小さかったから差がなかったのかもしれない．ということで，もう少し大きなソースを持ってきて，pTeX のインストール先とソースの保存先とを変えつつ再実験してみた．

使った pTeX は角藤版の 2007/11/12 時点での最新バイナリ．余計なパッケージはインストールせず，ほぼ標準インストールの構成．

コンパイル対象のソースにはとある博士論文を使用．ソースは15分割くらいで，eps系の画像を55個くらいとリファレンスを250個くらい含む．コンパイル時間の計測は，metapost 9回，platex，jbibtex，platex，platex というコマンド列を全部実行した時間を計測．参考までに，TeX ソースの合計サイズが 700KB くらいで，metapost ソースの合計サイズが 160KB くらい．コンパイル時に生成されるファイル総数は75個で，内 68個が metapostの生成するファイルである．

まず，メインマシンでの結果は次のとおり（Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD，Vista Business 32bit．pTeX と TeX ソースは別々のHDDにある）．

pTeX を RAMディスク上においた場合，ソースも RAMDsik に置いたほうが 0.1 ～ 0.2 秒程度速いかもしれない．逆に，pTeX を HDD に置いたときには RAMDisk にソース置いたほうがほんの僅かに遅くなるのかもしれない．でも，いずれの場合も意識するほど意味のある差とはいえないでしょう．

続いてW7Bでの実験結果は次のとおり（Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD，Vista Business 32bit．pTeX と TeX ソースは同じHDDにある）．

こちらも傾向としては同じ．意識するほど意味のある差は見られない．残念．

結論：TeXソースをどこに置くかはどうでもいいんじゃないかと．

環境が変わるとどうなるかわからないけど，少なくとも自分の環境では RAMDisk においても HDD においてもコンパイル時間は変わらない．ただ，RAMDisk のほうが情報をロストする可能性が高いので，安全を考えると HDD に置いといたほうが良さげではある．