No Such Blog or Diary

本棚の整理をして邪魔になった本を一週間ほど前に宅本便で売りに出していたのだけどその結果が今日来てた．ラノベと漫画が半々くらいで結果は以下のとおり．

種類                                        計算金額      商品数
__________________________________________________________________
本                                            4420円      106冊
お値段がつかなかった本                                      0冊
ソフト                                           0円        0点
お値段がつかなかったソフト                                  0点
__________________________________________________________________
商品数合計                                                106点
お値段がつかなかった商品数合計                              0点
お支払金額合計                    5304円(うち割増分       884円)

２割り増しのキャンペーンも入って一冊あたり50円なり．ゴミよりは高いが安いよなぁ．全巻セットとか限定版とかならオークションで売ったほうが手間はかかるけど還元率は高そう．

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

何ヘルツの音まで聞こえるかを tone generator のソフトで試してみた．テレビの音 15kHz は普通に聞こえる．しばらく上げて 17kHz は聞こえる．18kHz くらいから怪しくなる．19kHzになるとある特定の角度に頭を傾けたときに感じるていど（聞くというレベルでなく）．20kHz も19kHzと同じ方向のみ頭を振れば変化が感じられる程度．まあ，スピーカの音を最大に引き上げれば聞こえなくもないけど体に悪そう．

「レッツノート プレミアム ファンブック」だそうで．モバイルNo.1予約宣言のキャンペーンの先着2000人に入ってたらしく送られてきた．今年がLet'snoteの10周年とのことで，そのための記念ファンブックらしい．とりあえず一通り読んでみたけど技術的なことはあまり詳しく載ってないので面白みにかけるような…．もう少し分解図とか載せてほしかった．あと軽量化のために苦労した点とかもっと詳しく．まあ，普通の人向けにはどうでもよいことだろうけど．

はてなっぽくかけるという 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 に置いといたほうが良さげではある．