• Linuxザウルス開発メモ/ハードウェア - http://digit.que.ne.jp/visit/index.cgi?Linux%A5%B6%A5%A6%A5%EB%A5%B9%B3%AB%C8%AF%A5%E1%A5%E2%2F%A5%CF%A1%BC%A5%C9%A5%A6%A5%A7%A5%A2
  • SL-C700はなぜ遅いか(ハードウェア編) - http://digit.que.ne.jp/visit/?Linux%A5%B6%A5%A6%A5%EB%A5%B9%B3%AB%C8%AF%A5%E1%A5%E2%2F%A5%CF%A1%BC%A5%C9%A5%A6%A5%A7%A5%A2#i20

現行のXScale PXA250には、キャッシュ周りにハードウエア的なバグがあり、そのため公式発表通りのパフォーマンスが出ていない（実際に市場に流れている製品では、キャッシュ周りの機能を一部殺している）。Windows CEとかで、旧StrongARMマシンと比べてXScale化された新マシンが速くない理由として、「OSがXScaleに最適化されていないため」だと言われていたが、それは嘘（正確な事実の公表ではない）で、実際にはXScaleのハードウエアバグが主な原因なのでは。という話。

具体的にいうと、PXA210とPXA250にはWrite Backキャッシュにバグがあるんで、現行の機種（少なくともLinux Zaurusでは。Windows CE系はOSソースが公開されていないので不明。CPU設定を覗く系のツールで確認できるのかな？）ではWrite Throughで動かしている状態になっている。Write Back有効と無効でどのくらいパフォーマンスに差が出るのかは不明。もしもその影響が大きいのだとしたら確かに問題だ。

理屈で言うと、非常に局所性が高く、かつ、データの書き込みも発生するような処理においては、Write Backキャッシュ有効/無効でのパフォーマンスの差は大きくなるはず。OSレベルでそういう処理はどのくらい多いものなんだろう？　何にしろ次期Linux Zaurusにおいては、メモリの増強以外にもCPUバグフィックス済みのものに置き換えを希望しよう。

---

スラドにもスレが立っていた。

• http://slashdot.jp/article.pl?sid=02/12/21/1139251&mode=nested

でそれを読んで、この問題を「問題がある」というためには前提条件が必要であることに思い当たった。それは、XScaleの売り文句がWrite Backキャッシュ有効時のパフォーマンスを前提にしたものであったのかどうか、ということ。Write Backキャッシュ無効時のパフォーマンスを前提に宣伝して売っていたのならば、それは全然問題がない。いわゆる「それは仕様です」だからだ。しかし、Write Back有効時のパフォーマンスを前提に（ベンチマークなどでその場合の値を公表し）売っていたにも関わらず、実際にはそのスペックを満たしていなかったとしたら、それは問題になる。さてこの場合はどっちだったんだろう。

ここ最近仕事でずっと.NETばかりやっていて、あんまりそればっかりやっていると深みにはまりすぎて後戻りが出来なくなりそうな気がしてきた。.NETはマイクロソフトプロダクツにしてはものすごくできがいいと思うんだけど、やっぱり将来性に不安があるし。せめてApacheあたりと連携して手軽にUnix系サーバー上で動作すればいいんだけど。

というわけで、個人的なリハビリのために家サーバーにTomcatをインストール。Tomcatはバージョン3の頃にちょっと触ったけど、インストールでやたらと苦労した覚えがある（主に関連コンポーネントのバージョン合わせ）。最新バージョンの4.1.18では、最新のJDKとJRE（J2SE v1.4.1）をインストールして、Tomcat 4.1.18をインストールしたらあっさり動いた。しかもなんか管理ツールみたいなものまでインストールされている気配。ずいぶん使いやすくなったみたいだなー。

さてこの環境で何を作ってみようか。.NETとJavaとをWebサービスを使って連携させたりするとちょっと面白そうかな。とかいう色物ネタよりも、普通に単独で動くWebアプリを作った方がリハビリにはいいかな。そういやJavaで作られたWikiって存在するんだろうか？

---

あら、インストールは簡単じゃなかった。Tomcat自体は簡単に動いたんだけど、Apacheとの連携部分がうまくいかない。昔インストールしたときにはmod_jkとかいうモジュールで接続した覚えがあるけど、今はmod_webappなんてものになっているんだね。で、環境変数JAVA_HOME（/usr/java/j2sdk）とCATALINA_HOME（/usr/local/jakarta-tomcat）を設定して、httpd.confに

LoadModule webapp_module libexec/mod_webapp.so
AddModule mod_webapp.c
WebAppConnection WarpConnection warp localhost:8008
WebAppDeploy examples WarpConnection /examples

を記述するところでしばらくはまる（apachectl configtestが通らない）。が、これは結局httpd.confに上記設定を記述する場所の問題だった。上記設定は、ServerName行とPort行よりも後に記述しなければならない。

というわけで、ひとまず設定自体は通るようになったんだけど、Apache（80ポート）からexamplesを呼び出そうとしてもうまくTomcatのexamplesが呼び出されない。mod_webappまではちゃんと接続しているみたいだけど、mod_webappが「Web-application not yet deployed」と返してくる。ヘッダにJSESSIONIDなんて項目がくっついているから、一応Tomcatエンジン自体は起動しているけれども、アプリケーションが見つかっていない感じなのかな。

---

うげげ。server.xmlのwebapp関連の設定がデフォルトでコメントアウトされていたというオチだった。つまんねー話だ。

Eclipse（http://www.eclipse.org/）いじり中。JBuilderよりもこっちのほうがいいのかなー。Borlandは好きだから、JavaだけだったらJBuilderにしようと思っていたんだけど、EclipseはJava以外の言語（PHPとかJavaScriptとか）も統合環境で扱えるってのが魅力だ。CVSサーバーと直接やりとりできるみたいだし。ところでEUC-JPはどうやったら扱えるのかな？　まあこれを機会にコードはすべてUTF-8に統一するってのもありかもしれない。いや、それだとLinuxのshell環境で扱いが面倒だし、UTF-8が読めないブラウザもまだありそうだよな。

とか言っているうちに勢い余って、PCG-SRX7にApacheとPHPとMySQLまで入れてしまった。ついでに設定が腐りつつあったcygwin環境もいったん捨てて再構築。おお、Windowsローカル環境でTomcatもPHPもちゃんと動くよ。WikiLikeは何も書き換える必要なく動作するみたいだな。ローカルWikiLikeをメモ帳代わりに使うのもそれなりに楽しそうだ。ただこのマシンはときどきIIS系の開発のサブマシンとして使うこともあるんだよなー。80ポートはどっちで使おう。排他利用にするかそれともどちらかを別ポートに移動するか。できればIISの方を別ポートに動かしたいけれど、あっちは関連アプリ（VisualStudioとか）がちゃんと連携してくれるかどうか不安だなー。ひとまず排他利用にしておくか。

---

なんだ、EclipseでEUC-JPを使うのは簡単だ。設定-ワークプレース-エディター-テキスト・ファイル・エンコードの「その他」に「EUC-JP」が見つからないから、てっきりそれ関係のプラグインでも探してきて追加しなければならないのかと思っていたら、単にドロップダウンリストに自分で「EUC-JP」と入れるだけで良かった。Windowsのドロップダウンリストってフリーワード入力OKなのかどうかが一見判別つかないよね。

EclipseにWebStudio for Php（http://www.xored.com/products.php）とphp Plugin（http://sourceforge.net/projects/phpeclipse）の二つのプラグインをつっこんで、php開発環境を構築。基本的に前者の方ができがいいけれども、-[後者の方はphpのヘルプが同梱されていて、マニュアルを参照しやすい。前者に後者のマニュアル機能だけをつっこむことは出来ないものか]-+[マニュアルがついているのも前者の方だった。あと、マニュアル単体でもダウンロード＆インストールできるはず]+。いずれプラグイン開発関連の資料をあたってみるか。ひとまず前者を使うことに決定。ただし、

<script Langage="php">...</script>

という表現で書かれたコードをうまくparseできないらしい。

<?php ... ?>

に書き直したらちゃんとparseしてくれるようになった。EUC-JPを認識させる方法はEclipseいじりに書いてあるとおり。なかなか良さそうな開発環境を構築できたんで、しばらくこれを使ってphpフレームワークを作っていこう。その前にphpフレームワークの名前を決めないとなー。

• ホームページ - http://www.eclipse.org/
• プラグインホームページ - http://eclipse-plugins.2y.net/eclipse/

オープンソースの統合開発環境。標準でJava開発環境として設定されているが、プラグインを追加することによって他の言語の開発環境としても使用できる。CVSサーバーとの連係機能も用意されているので、Windows環境ではWinCVSなんかを使うよりも手軽。

やっぱりすごくいい。これからはほとんどの開発環境はこれに移行しよう。Java関連はもちろん充実しているし（携帯Java関連もできるかな？）、PHPもWebStudio for Phpをベースに環境構築すればちゃんとデバッグまで出来る。ついでにC#も結構まともに開発環境が構築できた（けど、これはまあVisualStudioの方が今のところは使いやすいかな）。あとPerlとHTML/CSS関連の環境があれば完璧なんだけどなー。なぜPerlのPlug-inは見あたらないんだろう。まあ単にコーディング＋実行だけだったら現状の環境でも出来そうだけど。HTML/CSS関連も純粋にそれ用というのではなく、JSP作成の補助的な意味合いのものしか見あたらないし。

そういやWiki（英語のみ）の環境なんかもあったりするみたいだから、がんばればemacsみたいにエディタ機能をコアにがんがんいろんなアプリケーション的機能を取り込んでいくアプローチで、統合開発環境機能をコアにいろんなアプリケーション的機能も取り込んでいけるのかな。コアの機能がemacsなんかよりも強力な分、よりすごいものが出来てきそうだ。

たぶんこれでJBuilderとはさよならすることになりそうだな。ついでにDelphiともさよならしようかな。旧VBとDelphi（Object Pascal）を比較して、言語仕様的な優劣でDelphiを選んで好んで使ってきたわけだけど、現在のVB.NETはDelphiよりもできがいい。これならばWindows系アプリはDelphiよりもVB.NETを使った方が作りやすそうだ。本当ならばC#に行きたいところだけど、あれはJavaに似すぎていて気色悪いし、仕事の都合上VB.NETの方が使い回しが効く。それにVB.NET単体は1万円くらいで売っているから個人で買うのもそれほどつらくないし。Delphi 5 Professionalは5万円くらいしたんじゃなかったっけ。

もうちょっといろいろいじって自分なりの納得いく環境を構築できたら、そのうち情報のまとめを書いておこう。現在の懸案事項は、ApacheとかPerlとかの環境をCygwin環境をベースに構築するのと、Win32用のインストールパッケージ（ActivePerlとか）をベースに構築するのとどちらがEclipseとの相性がいいのか、という問題。最初Win32用パッケージをインストールして構築していったんだけど、あまりWin32パッケージが提供されないツール関連を使いたいとなるとCygwin環境をベースに全部構築した方が良さそうなんだよなー。

PHPのオブジェクトとリファレンス周りの仕様は大嫌いなんだけど、それを何とか使いこなすために試行錯誤中。問題なのは、

• インスタンスの変数への代入＝インスタンスのコピーの作成であること
• インスタンスを返す関数に直接続けてインスタンスの機能を呼び出すコードが書けないこと

たとえば、

class ClassA{
var $value;
function Set($newvalue){
$this->value=$newvalue;
}
function Get(){
return $this->value;
}
}

なんて値を保持する簡単なクラスがある。で、そのクラスのインスタンスをグローバルに一つ生成しておいて、あちこちで手軽にそれを使い回したいと思う。

global $a;
$a=new ClassA();

なんてすることで、グローバル変数$aにClassAのインスタンスが生成される。あとはカレントスコープがグローバルな場所ならば、

$a->Set("newvalue");

なんて感じで$aにアクセスできる。でも、スコープがローカルな場所ならば、

function func(){
global $a;
$a->Set("newvalue");
}

なんて感じで、いちいち$aがglobalであることを宣言しないといけない。それがいやなんで、どこからでも同じ表現でアクセスできるようなインターフェースを用意してみようかと思った。たとえば、

function &IA(){
global $a;
return $a;
}

なんて関数を用意すれば、カレントのスコープがグローバルだろうがローカルだろうが、IA()でグローバルな$aへの参照が返される。しかし、PHPでは関数が返したインスタンス変数への参照を使って、直接そのインスタンス変数の機能を呼び出すことは許されていないらしい。たとえば、

IA()->Set("newvalue");

なんて書くとタイムアウトまで固まってしまう。

$b=&IA();
$b->Set("newvalue");

というように、いったんローカル変数にインスタンスの参照を受け取ってからSetすると、きちんとグローバルな$aに値がセットされるのだが、これならばいちいちglobal $a;を記述するのと大差ないだろう。

ちなみに余談だが、

$b=IA();
$b->Set("newvalue");

は間違い。これはグローバルな$aのコピーである$bに対して値をセットしているだけなので、グローバルな$aには値はセットされない。

このあたりはとてもわかりにくい仕様だ。出来れば代入処理は、stringやintegerみたいな型に対して行った場合はコピーになり、その他オブジェクト型に対して行った場合は参照の代入になるといいんだけど。

ちなみにグローバルなインスタンス変数に対して、どのスコープからでも一意な表現でアクセスする手段としては、

$GLOBALS["a"];

を使うという方法もある。でも$GLOBALSを使った表現は見た目が美しくないので使いたくない。あと、

define("a",new ClassA());

なんてやったらどこでも、

a->Set("newvalue");

なんて出来るようになるんじゃないかと思ったら、あいにく定数にはオブジェクト型は入れられないそうな。

というわけで、現在手詰まり状態（動くことは動くけどね）。グローバルなインスタンス変数に対して、どのスコープからも手軽にアクセスできるような手段はないものかのー。

Eclipseを中心にしたWindows上での開発環境を充実させようと苦闘中。Java（＋Tomcat）、PHP、C#（まあおまけで）、JavaScript、C/C++、Ruby（これは新しくお勉強用）、Python（これも新しくお勉強用）、HTML/CSS（いいプラグインがいまだに見つからない）、XML、おまけでPerl（これはひとまずエディタとしてのみ使えればいいや）あたりを、きちんとWindows上で編集、デバッグもしくは単なる動作テストできるようにしようという方向で。

で、Eclipseとそのプラグインについては、まあ普通にインストールすればそれでOK。あまり揺らぎがない。けれどもその他環境については、Win32専用のインストールパッケージを利用するパターンと、Cygwinを使った疑似UNIX環境を利用するパターンの二つがあって、どれを利用するか迷う。

最初はApache、Tomcat、ActivePerl、PHPをWin32用パッケージでインストールして環境を構築してEclipseと連携させたところ、結構ちゃんと安定して動くようになった。PHPなんかはデバッグ用モジュールとかをつっこんだらトレース実行とかもちゃんと出来るようになったし。

ただ、Win32用パッケージが用意されているツールはさほど多くないし、PerlモジュールなんかをCPAN経由でインストールしようとするときには、Cygwinの疑似UNIX環境が合った方が役に立つ。あと、Win32用パッケージは最新版に追随しないから、最新版を追いかけたいようなツール類をWindows上でも使いたいとなると、Cygwin環境の方がいいかも。

と思って、一日かかって環境を再構築していたんだけど、Cygwin環境ってそんなに万能じゃないみたいだなー。UNIX環境みたいに普通にソースからインストールできるツールはそんなに多くないようだ。設定を何とかしろっていうレベルならばいいんだけど、コンパイルにVisual C++が必須と言われるとつらい。特にVisual Studio .NETのC++は古いバージョンとはいろいろ互換性がなくなっているみたいだし（windows.hはどこに消えた？）。

というわけで結局、ApacheとPerlとRubyはWin32用のパッケージからCygwin環境のものに移行したんだけど、その他は普通のWin32パッケージを使うことにした。Cygwin環境のApacheからもWin32用パッケージでインストールしたバイナリに「/cygdrive/ドライブレター/****」でアクセスできるみたいだし、逆方向の連携は普通に実行すればCygwin用バイナリは勝手に内部でCygwin経由で起動してくれるようだ。

ただ単にEclipseを使ってWindows上での開発環境を構築したいという場合は、基本的にCygwinとの連携ははじめから考えずに、Win32ベースで出来る範囲でベストの環境を構築する方針にした方が良さそうだな。Windows環境ではWin32用パッケージでインストールしたものの方が使いやすいことが多いし、Cygwin環境を使ったところで開発環境の可能性の幅はさほど広がらないようだ。というのは、Cygwin環境で（Visual C++なしで）普通にソースからインストールできる開発ツールは少ないようだから。

まあRubyみたいにCygwin環境でも普通にコンパイルできるものもあるし、ApacheからPerlのパスを指定するときに「c:\perl\bin\perl」なんて書くよりは「/usr/bin/perl」と書けたほうがいいから、俺は一応Cygwin環境と半々で使っていこうと思うけれども、たいていの場合はWin32用パッケージだけで環境構築した方がよさそう。しばらく使ってみてCygwin環境を使うメリットが感じられなくなったら、俺もWin32用インストールパッケージオンリーな環境に戻すかも。

ああ、ちなみにメインの実行環境はUNIX系OS上であることが前提ね。実運用までWindows上でやろうというパターンは想定していない。