2004/12/17(金)perlの処置

2004/12/17 14:00 PC（Linux）
per.5.8を入れた理由を思い出した。どうやらmysql関係のlibが5.8じゃないと動かなかったらしい。
さて、
・5.8系と5.6系はバイナリ非互換とかなんかそんな話。
・debianのstableはほとんどが5.6系依存で固められている。
・が、5.8でないと動かないソフトもある。(mysql関係等)
・個別コンパイルすれば、5.8系でまとめることは可能。

という線らしい。しかしなんかやだなあ。PHPじゃあるまいし……

とりあえず、よくよく考えてみたらmod_perlを入れる意味というかmod_perlちゃんと動く気がしないので止めて、見なかったことにした。今のうちのサイトで動いてるCGIはグローバル変数の初期化・お掃除をちゃんとやってる気がしない。dirtyなCGIをぽこぽこ実験するサイトなのだから、mod_perlで動かないのが出てくると切り分けがややこしいしストレスチックになる。かといって、拡張子変えたりLocation切り分けで棲み分けるのもなんだかばかばかしい。

とりあえず、このままほっておいてパッケージで入るものだけで頑張ろう。どうしてもmakeしなきゃいけないものはやるにしてもね。
コメント（0件）

2004/12/16(木)apache死亡事件顛末 in perl5.8 ＜-＞ perl5.6.1

2004/12/16 17:00 PC（Linux）
apacheを殺してしまった問題。

一番最悪の殺人方法で、apacheのパッケージを削除してしまった。

原因。なぜ入れたのかは覚えていないが、現在インストールされているのがperl-5.8(unstable)。で、perl-5.6系でないと動かないパッケージを入れようとしたところ、dselectの依存解決に任せていたら、↓こんなことになった。

The following packages will be REMOVED:
aalib1 abiword abiword-common abiword-gtk abiword-plugins apache
apache-common apache-dev apache-utils apel ark asiya24-vfont autoconf
automake css-mode defoma docbook docbook-xml dpkg-dev emacs21 fontconfig
gconf gdk-imlib1 gdm gnome-s gnome-bin gnome-common gnome-core
gnome-libs-data gnome-panel gnome-panel-data gnome-session gnome-terminal
gnome-users-guide gs gs-common gsfonts gsfonts-x11 html-helper-mode
imagemagick imlib-base imlib1 jdk1.1 jvim-canna kab kaffe-pthreads karm kate
kcalc kcharselect kchart kcoloredit kcron kde kdebase kdebase-audiolibs
kdebase-libs kdelibs3 kdelibs3-bin kdepasswd kdepim-libs kdf kdict kdm kedit
kfind kformula kfract kghostview khexedit kiconedit kinput2-canna-wnn kit
kivio kjots kmail knewsticker knode knotes koffice koffice-libs konqueror
konsole kontour korganizer korn koshell kpackage kpaint kpm kpresenter
kruler kscreensaver ksirc ksnapshot kspread ksysv kterm ktimer kugar kuser
kview kword lbxproxy libapache-mod-ruby libarts libdbd-mysql-perl
libdbi-perl libfontconfig1 libgconf11 libgdk-pixbuf-gnome2 libgdk-pixbuf2
libgimp1.2 libglade-gnome0 libglade0 libgnome-vfs-common libgnome-vfs0
libgnome32 libgnomeprint-bin libgnomeprint-data libgnomeprint15
libgnomesupport0 libgnomeui32 libgnorba27 libgtk1.2 libgtkxmhtml1
libimage-size-perl libkdenetwork1 libkmid libkonq3 libmagick5
libnet-daemon-perl libplrpc-perl libqt2 libungif4g libwmf0.2-2 libxaw7
libxft1 libxft2 mc-common mew mozilla mozilla-browser mozilla-mailnews
mozilla-psm mysql-client mysql-server nessus openssl perl perl-modules php4
php4-dev php4-mysql proftpd proftpd-common proxymngr psfontmgr rep-gtk rpm
sawfish scrollkeeper secpolicy sgml-base sgml-data skk skkinput
ttf-xtt-wadalab-gothic ttf-xtt-watanabe-mincho twm vflib2 watanabe-vfont
x-ttcidfont-conf x-window-system x-window-system-core xaw3dg xbase-clients
xdm xemacs21 xemacs21-basesupport xemacs21-bin xemacs21-mule
xemacs21-support xfonts-abi xfwp xlib6g xlibs xnest xterm yc-el

どうもperl(perl-5.8)を削除しようとしたらしい。慌てて止めたが、後の祭り。消えた可能性があるのを全て確認し、入れ直した。もしかすると、動いてないdaemonがあるかもしれない他、apache上でのperl-CGIの実行速度が落ちた気がする。

実行速度が落ちたことに関して考え得る原因：
１．apacheのパッケージが狂った
２．perlのパッケージが狂った
３．apacheでmod_perl,speedycgiかなんかが動いていた

1. 2.は分からないのでとりあえずおいておくとして、3に関してはmod_perl.soやspeedyCGIが入っていた形跡がないので、可能性としてはmod_pelのapacheへの静的コンパイル。記憶あやふや。

とりあえず、トップページのカウンターを入れ替えてごまかす。
e-counterだとcgiを５回呼び出すことになるので、夢カウンターに。……これで前の実行速度の感覚に近づくってことはやっぱりmod_perlがくさいのだがどうだろう。

perl 5.6への巻き戻し方法はよくわからない。日本語ソースもないが、英語ソースもどうも？
コメント（0件）

2004/12/15(水)Virtual PC 2004 SP1 v.s. vmware workstation 4.5.2

2004/12/15 15:00 情報工学
昨日の続き。さらにvmwareとVirtual PC 2004 SP1を試してみたので書いてみる。
どうもverによって大分挙動が変わる気配なので、verを書くことにする。
なお以降めんどくさいのでMS Virtual PC 2004をVPC,vmware 4.5.2をvmwareと書く。

昨日のはSP1が当たってない奴だったらしくもう１回別のところから落としてみた。おどろいたことに、SP1なしとありでは別物のソフト。大分処理が変わったようだ。

ただ、結論から言ってしまえばどれもゲームにはならない。こんなことでストレスをためるくらいなら、実機でOSを動かす方法を考えた方がよい。

ただ、このテストは全てAthlonXP1GHz,Mem512MB,Radeon9200SE(メモリ遅い方),YMF744というリーズナブル環境で行っていることを追記しておく。

さて特にネックになるのはサウンド周りなのでその状況から書いていこう。

１．音声
　ハードをソフトでエミュレーションする際に一番問題になりそうなのがソフトとハードの割り込みをどうやって制御するかという点になるだろう。タイマ割り込みの管理が悪いのか、処理能力の限界か音声がブツ切れる。双方で挙動が違うが、

VPC- 全ブツ切れ。使い物にならず
VPC SP1 - 無印より大分良い。負荷が低いとき（mp3再生時等）には切れない。MIDIの再生が重いらしく、MIDIはブツ切れまくる。SXGY100はブツブツだった。
vmware - 全般的に何を再生してもちょっとずつ切れる。しかし余程忍耐力がないと我慢できないだろう。

２．処理の重さ
　マウスの挙動やゲストPC上の操作の重さ。
(1)マウス
　マウスは双方ホストカーソルをソフト側でキャプチャしてゲストOSに渡す方法に変更したようだ。
VPC - ワンテンポ遅れる。クリックゲーや高速なレスポンスを要するゲームには向かないだろう。
VPC SP1 - マウスの移動はホスト側に依存。クリックなどがスルーされることもあり、ちょっと不安はあるがVPCよりずっと良。
vmware - additionalでVPC SP1と同様にマウス移動はホスト側となる。若干軽めなせいかマウス感覚はもっとも良好。

(2)全般
VPC - 重い。重さについては昨日の記事を参考。
VPC SP1 - VPCよりはるかに軽くなっている気がする。OSインストールこそ試していないが、バックグラウンドでも動くようになったのではないか。負荷時に重くなるのは同じ。
vmware - ３つの中ではもっとも軽いが、やはり負荷時に重くなる。インストールなどは非常に早く実機～実機1/2位の速度が出ているようだ。ただし、ゲスト<->ホスト間ファイル転送などは非常に重くUSB1.1！？とか思う。

３．その他
VPC SP1 - ネットワークのインストールに失敗することがある。めんどくさいのでその後未調整。additionalで入る共有を使っていると、どうも普通のディレクトリと同様に扱われておらずそこからのインストール作業等に失敗することがある。まあローカルにいったん持ってくればそれですむ話ではあるが。なお、共有で仮想マシンのファイルがあるフォルダを指定すると、ゲストOSが死ぬ。

vmware - CD-ROMドライブの接続を変えたときに、認識してくれないことがある。こうなるとゲストOSの再起動が必要。ネットワークは最初から簡単に動くが、Win98だとSoundはデフォルトで認識してくれない。Creativeのサイトから、ENSONIQ Audio PCIのDriverを落とす必要があり。
コメント（0件）

2004/12/14(火)Virtual PC 2004 Trialを使ってみた

2004/12/14 05:00 PC（全般）
仮想マシンエミュレートソフトMicrosoft Virtual PC 2004 Trialを使ってみての感想。

ちなみに、目的はというと昔やってたゲームのデータを確認したくなったがWinXPじゃ動かんー　という話。

さて感想。

1.実機より遅い
　ホスト側に普通にOSをインストールする方が早い。当たり前だという声もあるかもしれないが、エミュレートすることによって低速デバイスが加速する部分もあるはずで一概に確実に遅くなるとは言えない（はず）。だがまあこいつはだいたい遅い。マウスポインタ、ディスクアクセス、その他もろもろホストの能力の1/3～1/4位の感覚になる。

2.サウンド滅茶苦茶
　音に関しては相当酷い。ブツ切れるし、このMIDIの酷さは久方ぶり。PC-98 + ソフトウェアMIDIより多分悪い。

3.バックグラウンドにすると遅くなる
　Virtual PC固有だと思われる。バックグラウンドにすると途端にフォーマットなどが進まなくなる。今ひとつ使い勝手が悪い。

結論、使えるか使えないかというと”将来性に期待”というところか。マルチOSは決して勧められる物ではないが、ガチャポンあたりで余りHDD１つ使えるのなら実機にインストールした方が万倍良い。下手すると、Annex86+Win95あたりに負けるかも。Grandaleだかなんだか、ハードからのバーチャル化の方が早いかもしれない。

ただしこのソフトがやたら遅いのは、相当低レベルまでいちいちエミュレートしてるからだという話なので、動くOSの多さという点では強いのだろう。Unix系もおそらく動く。有り余るCPUパワーの下で、OSの互換性を保って作業というシチュエーションでは強力か。
コメント（0件）

2004/12/14(火)華式（Kshiki）Updateのやり方

2004/12/14 01:00 PC（全般）
前にも書いたのだが、記事として不足が多く今回苦労したので再確認。

KShikiの場合は、スタイルシートで全部色を変えたり出来ないので一苦労である。

1.全バックアップ
　とりもなおさず、現在動いてる奴を全ファイルバックアップ。

2.転送
　最新版を/data,/GraphixAをのぞいて全て転送。転送は普通に行えばいいが、sjisの所為かsamba経由だと上手くいかないことが多い。WinSCPで。パーミッションは継承されるので、多分問題ない。

3.書き換え
　具体的に書き換える必要があるファイルを以下に挙げる。ここでの「書き換える必要がある」とは、私が自分のサイトで使うために色変えなどで書き換えているファイルを含んでいる。

KshikiconfigD.cgi - デザインファイル。記事のボーダーカラーなど。将来的にはこれとスタイルシートで全部いじれる？
KshikiconfigP.cgi - パスワード関係ファイル。タイトル等。
KshikiFormMain.html - 外形生成ファイル。タイトルのバックカラー、ログインフォームの場所など。
KshikiFormParts.html - 検索フォーム、カレンダー等のバックカラー。

上記４ファイル。どうも散逸してるのが気になる。今回は差分を残しているので、どこを書き換えているか次回ExamDiffで直ぐ分かるはず。

以上３ステップで終了。

なお、画像のアップロードに失敗する問題はa50にしたところ直った。が、なんか記事追加時に消去ボタンしかでなかったりする。どうにもKshikiはバグが多い。おまけに遅い。
コメント（0件）

2004/12/06(月)数式-&gt;画像

2004/12/06 02:00 PC（全般）
数式が１個画像で突然欲しくなった場合どうするか。

Texで１から書くのはいかにもめんどくさい……
ということで、Microsoft数式エディターをPowerPointで使い、「図として保存」コマンドでjpg or gif or pngで書き出すのが楽だろう。

なお、この「図として保存」コマンドは背景色が設定されていないと黒ベタ画像を吐く。

つまり、


  1. 挿入->オブジェクト->Microsoft 数式3.0
  2. 開いた数式エディタWindowで編集->終了
  3. オブジェクトの書式設定->色と線->塗りつぶし->色：白
  4. オブジェクト選択->右クリック->図として保存


という手順になる。保存時のサイズ調整・パレット選択等は出来ないが、PowerPoint上での拡縮は比較的まともに動くのでサイズが合わなかったら目分量でサイズ変えて再出力。

JustSystemやOpenOfficeの数式エディタもさわってみたけれど、手早くということならMSのをWord or PowerPointで使うのが一番使い易かった。

花子あたりでMSの数式エディタが扱えれば良かったのだが、Word,PowerPoint以外だと数式エディタの挙動が変わり、この状態になるとどうも怪しい。BackSpaceが効かなくなることもあるし、編集終了すると画像に固定されるようで、拡縮がうまくできなくなる。

まあそんな感じで。数式が複数出現する文書とかなら、まあやっぱりTexなんだろうな。余程のよれが無い限りTexはあと１年ちょっとで永久卒業。数式コマンドを全部覚えてーなんて考えは持たないようにしたい。WinShell,EasyTexは使えるのかいな……　次回チェックだな。
<追記>
知り合いからMimeTex.cgi（Texの数式を画像にしてくれるcgi）を使ってはどうかと勧められた。自サーバにおいて、数式を張りたいところに数式コマンドとリンクを書く。

うーん、それがいいやり方の１つだというのは納得できるがイマイチしっくり来ないのはなぜだろう？　外部画像がいやなのか。amazonだったらOKなのに？　著作権問題があるから納得できる？

それと１つ書きたいときというのがたいてい自分であれこれ考えながら数式を書いているときだというのがある。wysiwygじゃないと使えないのだ。あとはCってのはどうなんだろうな。このサーバ潰れたら外部リンクだよな。
コメント（0件）

2004/11/23(火)なにかがおかしい（作業マシンのIE）

2004/11/23 05:00 PC（プログラミング）
＊＊＊＊＊＊　　スパイウェアが原因でした　　＊＊＊＊＊＊

spy bot1.3でpossible hijacker検出。修復したら直りやんの。

orz
        • Old-------------------------------------------------------------------
以下の記事は、なんと作業用マシンのIEでしか発生していない。ノートパソコンでの表示（同じXP SP1、同update状態、低スペック、ビデオカードRade系統、同DHCPにぶら下げている）は"admin mode"でも３秒弱と問題ないスピード。

また、知り合い３人に同ページを読んでもらったところ、IEを使っている３人ともが３秒程度で表示されるという状況。

正直原因・打開策全く思いつきません。まだブラウザ環境変える気にはならないし、このマシンから速くないと意味がないんだが……

.NET frameworkが悪さしてる可能性を考えて、アンインストールしたが変わらず。
IEの再インストールも試みたが変わらず。
        • Old----
さて、ユーザモードは２～３秒で開くようになったので満足としても、管理者モードだと未だ７秒超かかる。アウトプットは0.2秒で出来ているため、ブラウザの描画での問題。なんかいい資料が見つからなかったので自分でざっと実験。きっとあると思うんだが。

結論から言うと、描画するボタンの総数とhiddenフィールドが描画時間の足を引っ張っているようだ。
<<調査内容（超手計測）>>
・
の数 -> 影響なし
・の数 -> ほぼ影響なし
・の数 -> 影響あり
・の数 -> 影響あり
・cssの使用、および記述内容 -> ほぼ影響なし

ボタン１００個、hiddenフィールド２００個につき１秒超くらいかかっている気配。このCGIが吐くページでないと再現性がない？　でもValidatorは一応通ってるからなあ……　トップの検索から、ノードデータの編集に飛べないのは不便、なんとかしたい。

ラジオボタンが１つ逃げの打開策。hiddenフィールド、ボタンを減らす方向で１ボタンであとで分岐させるのが折衷案。

うーんもうちょい考えますか。

P.S.
Firefoxだとhiddenがいくらあろうが２秒で表示してくれます。IE固有？　ションボリ。
コメント（0件）

2004/11/23(火)xml －＞ csv

2004/11/23 05:00 PC（プログラミング）
REXMLを断念した。

REXMLを使用した場合、１００件程度のデータの表示において私の腕では、
$ time ruby value.cgi > test.out
による計測で4.2sec～4.6secと4秒を切れない。「表示まで5秒」ルールを達成するのはどうやら無理。

奇っ怪な記法で多少の速度アップは出来ないことはないが、スクリプト言語の最大の利点は読みやすさにあるべきだと考える。そもなぜXMLを使おうとしたかというと、データの可読性と保守性が欲しかったから。まあ実際は、腕の問題か。

そんなわけで、csvで実装し直した。それなりに冗長に書いたのにもかかわらず同計測で、0.2sec。同じデータを使用していないので、公平なテストではないが１００件程度で揃えてはある。ruby + xmlを使うのは時期尚早だったようだ……

さて、rubyの場合なにせHashクラスがあるためcsvの管理は相当楽。csvは１行目にkey、２行目以降を実際のデータとして、１行目と各行をzipで閉じてHashにつっこむ。csv自体の可読性・保守性もアップと実にありがたい話。疑似ツリーも簡単に作れるし、REXMLのAPIとにらめっこしたのはなんだったんだろうか。

ちなみに、計測に使用したCPUはC3 800A MHzナリ。単体で買えるCPUで現役最低消費電力。
コメント（0件）