Home > Archives > 2007年11月

2007年11月

tramp を Meadow で使ってみる

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

(setq tramp-default-method "sshx")

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

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

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

runas コマンドと administrator の有効化

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

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

パーミッション変更が…

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

NP_SyntaxHighlighter と NP_HatenaLike と DB保存/復元と

はてなっぽくかけるという 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 on RAMDisk その2

前の実験に使った 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にある).

pTeXTeX ソース1回目2回目3回目
RAM RAM 11.801s 11.642s 11.754s
HDD 11.947s 11.934s 11.893s
HDD RAM 12.413s 12.624s 12.383s
HDD 12.329s 12.313s 12.323s

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にある).

pTeXTeX ソース1回目2回目3回目
RAM RAM 26.255s 25.724s 26.349s
RAM HDD 27.300s 26.161s 26.379s
HDD RAM 27.924s 27.191s 27.425s
HDD HDD 27.331s 27.285s 27.315s

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

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

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

TeX on RAMDisk

RAMDisk 上に pTeX をインストールして,HDDにインストールしたものとコンパイル時間を比較してみた.

コンパイルに使ったTeXソースは9分割されており,64KBくらいでA4に14ページ(英語)ほど.ドキュメントクラスは article で,パッケージはfullpage, color, graphicx, amssymb, amsmath, cite を使用.画像は eps を6枚くらい.

コンパイル時間は,中間ファイルをすべて削除した状態から platex を3回かけた時間を time コマンドで測定(real).ls-R データベースを作った場合と作らない場合とで測定.各セットについて10回くらい走らせて平均を取った.

結果は以下のとおり.マシンはW7Bを使用(Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD).

ls-R なしls-R あり
HDD7.24s4.41s
RAMDsik5.18s4.15s

とりあえず ls-R のあるなしにかかわらず RAMDisk のほうが速い.ls-R データベースがないときはRAMDiskのほうが30%程度速くそれなりに大きな差がついた気がする.でも,ls-R データベースがあると6%程度しか差が出ない上に絶対値も小さくなっているのでほとんど無視できる程度の差しか出なかった.

ちなみに,メインマシン(Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD)だとRAMDisk と HDD で有意な差が出なかった.OSのディスクキャッシュが効いたのかHDDが速かったのかそれ以外なのかは不明.

結論:RAMDisk上にpTeXをインストールしてもあんまり特にならない.ls-Rデータベースを mktexlsr とかで作るほうが手間も要らずに速くなる.

まあ,OSのディスクキャッシュもあるのでリードアクセスだけのファイルを RAMDisk 上においておく事の意義はそれほどない気もする(RAMDiskのキャッシュをとられるとアホだ).やっぱ書込みの激しいキャッシュとかに使うのが正しいのでしょう.

PlexTools Professional LE

PlexTools Professional の Vista 対応が未だに行われないので PlexTools Professional LE をダウンロードして使うことにした.どこら辺が Limited Edition なのか全くわからないのだけど.とりあえずデータの読み書きが普通にできるらしいので今のところ LE で問題なさげ.

Qcam + Thunderbird ではまる

Thunderbird のアップデートが出たので更新実行したら何故か失敗しまくる.そして Thunderbird のアップデータはあきらめることを知らないのでキャンセルができない.おかげですぐに来るであろう大事なメールの返信を受信できない状態に…

何が悪いのかと原因を探ってみると mozMapi32.dll が消せないとのこと.で,このファイルを誰が読み込んでるのかと思ったら Qcam.exe であったと.(こういう時 ProcessExplorer はとても便利だなぁ)ということで,とりあえず Qcam をアンインストールすることに決定.ただ,Qcam のアンインストールが途中で止まって何もできなくなってしまい… 結局は Vista ごと再インストールすることになった.

さて,悪いのは誰だろう?

Vista + Ghostscript ではまる

フォント周りで Error: /rangecheck in --string-- とか言って怒られまくり… 色々試したけど原因わかんないなぁと思って検索かけてたら次の書き込みに行き着いた.

http://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/47672.html

どうやら XP あたりからフォントを持ってこないとだめらしい.んで gs/lib/cidfmap も書き換えてやると.何が直接の原因なんだかわからないけどとりあえずこれで日本語が通るようになった.

ところで texインストーラ3 なんてものがあったんだなぁ.微妙にインストールが楽になった気がする.

さてどうするか

pTeX をフルインストールしたら 500M 超えた.これをRAMDisk上にそのまま置くのは馬鹿だよなぁ.標準インストールでも 260M らしい.インストールするパッケージをちゃんと選ぶとするか…

RAMDisk を入れる

HDDがガリガリうるさい&遅いので,QSoft の RAMDisk "Enterprise (full)" Version 5.3.1.* を導入.ドライバのロード&アンロード時にイメージの読込&保存をしてくれる設定もあるので色々楽そう.

そんで,FireFox のキャッシュやら環境変数の TEMP&TMP を全部 RAMDisk に指定.とりあえずガリガリうるさかったのが大分静かになってくれた&所々速くなってくれた(気がする).

この調子で TeX 関係も突っ込んでしまえばコンパイルが早くなってうれしそう.ところで TeX ってどれくらい容量食うんだ?

いろいろとうまくいかず

Vista のエクスプローラでジャンクションをクリックしてもアクセスできないといわれる.普通にリンク先にいってくれるものもあるけどほとんどがアクセス拒否.さてどうしたものか?

とりあえず FireFox やら Thunderbird やらの設定は C:\Users\XXXX\AppData\Roaming とかにあることだけは見つけたけた.そしてNICのIP固定とかどこでできるんだ?

PowerShell を入れてみる

Windows の cmd.exe の次のシェルらしいので面白そうだからダウンロードしてみた.だいぶ前からあったらしいけどコードネームが Monad だったのは何か数学的意味が…?

それはさておきちょっと使って嫌だった部分を上げる.

第一にバックが黒くないところ.微妙に紺色なので黒くしてしまった.

第二に ls が内部コマンド(alias)で定義されてること.ls -al と書いて怒られた.

第三に man も内部コマンドで定義されてること.まあ,内部コマンドの説明見るには便利だけど.

第四に sl が内部コマンドで…  第五に cpp が…

ということで,Alias: に移って rm ls にて偽物の ls には消えていただいた.んで,このまま Alias: で ls したらどうなるかと思って試してみたら元のディレクトリの一覧が出た.まあ,当然といえば当然だけど Alias: という位置は PowerShell が適当に作った場所であって他のプログラムからみたらカレントディレクトリの移動はしていないと.

ついでに,PowerShell 起動しなおしたら元に戻った.Export-Alias, Import-Alias 使わないとダメみたい.

落とし穴: ls と rm の alias を消そうとして順番間違うと危ない.

touch ls
cd alias:
rm rm
rm ls

とかやると alias の ls は消えずに touch で作った ls が消える.まあ,最初の rm が Remove-Item の alias で二つ目が /bin/rm なだけだけど.

結局,プロバイダとして物理的なドライブ以外の物の場合カレントディレクトリの齟齬があると.で,この状態で PowerShell 外のコマンドを読んでしまうとある意味変なことが起きると.sshfs みたいなのをプロバイダにするとリモートのファイルを消したつもりが手元のを消すことに? 結構危なそう…

Home > Archives > 2007年11月

Search
Feeds

Page Top