昔の最近の出来事(2004.09)

2004/09/30

出張。

出張。

出張。

具合が悪くて一回休み。一日中寝てたり。

正規表現についてもう少し調べたり。すると先日欲しいと思ったperlでいう所の 括弧で括る話について、「前方参照」という名で実装されている模様。 所が、取りだしの手順がすぐに判らず悩んでみたり。マニュアルを行ったり来たり した所、java.util.regex.* にPatternクラスとMatcherクラスというのがあり、 これらを使用して、perlのそれと同じ感じにできるという事みたい。 例えば、

#    posx posy	image         "label"
item 100  100	"./test1.jpg" "テスト１"
item 100  120	"./test2.jpg" "テスト２"

Pattern p = Pattern.compile("[\\s\\t]*item[\\s\\t]+(\\d+)[\\s\\t]+(\\d+)[\\s\\t]+\\\"(\\S*)\\\"[\\s\\t]+\\\"([^\\\"]*)\\\"") ;
Matcher m=p.matcher(str) ;
if( m.matches()==true ){
   System.out.println("pos=" + m.group(1) + "," + m.group(2) + " : " + m.group(3) + " : " + m.group(4) );
}

昼頃起床。

ソースをコンパイルしてみました。gcjではコンパイルできないので、 javacで全ソースをコンパイルしてみた所、いくつかのソースが エラーしたりするのですが、とりあえず一通りのクラスファイルが できてみたり。問題はこれをjarファイルにする所なのですが、 ファイル数が多過ぎて、コマンドラインの指定に入りきらないと いう罠にハマってみたり。仕方なしにリストを採取して、 アップデートモードでファイルを追加してどうにかjarファイルを 作成できたのですが、それを使ってgcjでコンパイルすると、 メモリを思いっきり消費して、最後は赤○白×のsegfaultで死亡。 むぅ。
因みに、/usr/include/以下のヘッダファイルは参照していないようで、 ここにclassファイルよりgcjhで生成したCのライブラリヘッダを入れても コンパイラには見えていないようでした。という事は、基本的に コンパイラの解釈できる形式で且つ人が見ても判るテキスト形式の ファイルというのは存在しない為、コンパイラがサーチするライブラリ やヘッダパスに乗ったファイルを、ただテキストビュアで見るだけでは 情報を知る事はできないという事になりそうです。ですから、 「1.別途ドキュメントは用意する」もしくは「2.ソースを提供」 以外の方法で、クラスの中身を知るには「3. javapコマンドで逆アセンブルする」 くらいしか無い予感。
また、C言語のようなプロトタイプ宣言が存在しない 為、gcjではクラスファイルの生成順序を間違えると、「そんなクラス 知らん」とすぐに言われてしまいます。これは、ビルドに対して、 必要以上に明確な依存関係を要求されるという気がします。 javacの場合はクラスファイルが存在しなければ一対一に対応付く ソースファイルがあれば勝手にコンパイルして使ってしまう ようです。でも、そこまでやられてしまうと、ある場所で動かしていた 時は動いたのに、ファイルを移動すると何故か動かなくなったり しそうで、またそうなってしまった時の理由がよく判らなくなるような気 がしなくもありません。コンパイルし忘れが問題になると いうのに過剰に反応した結果の様にも思える仕様ですが、 なにもコンパイラでどうにかしなくても.....とは思いました。

SDKの日本語ドキュメントを眺めていると、VMの実行時オプションに ガベージコレクタのプロファイル情報を出力するオプションがあり、 それを眺めてみました。 ガベージコレクタが動作に要した時間が出るというものですが、 リスト構造を切ったり張ったりすると、一回のCGに要した時間よりも、 発生する頻度が増える様子が見て取れます。ガベージコレクトを行なう メモリの捻出量(?)は毎回ほぼ同じにしても、それにかかる時間は微妙に 異なる様です。 リストもサイズを限定して、非アクティブなリストを繋ぐチェーン に繋ぎとめておくような構造にすれば、ガベージコレクタの動作を 最低限に抑える事ができそうですが、そのようなチューニングが 必要か否かはプログラムによるといった所でしょうか。

文字列操作の練習をしたり。C言語でやる場合、トークンをスペースか タブに限定して、できるだけパースが面倒でないフォーマットにするか、 限度を越える場合はyacc/lexというパターンにする所なのですが、 JavaのそれだとStringクラスのメソッドにawkレベルの文字列操作が 含まれている様なので、それを使うという感じ。でも、perlの正規表現 マッチの中に、括弧でくくった部分をパラメータとして$[1-n]の変数に 取得できる構文に慣れると、awkレベルのそれでも面倒という感じです(^^;
それよりも、gcc-3.3.3に含まれるlibjavaでは、String.matchesメソッドが 無いようで、gcjではダメらしいという事の方が問題かも。 gcc-3.4.2には入っていたので、3.4.2になるまではgcjには面倒な環境の様です。 そういや、Javaって標準で使用できるクラスについての仕様というのは 決まっているのかしら？と思ったり。gcc-3.3.3のStringクラスのソースは 2002/06で、gcc-3.4.2のそれは2003/07という感じなので、割と最近 の差という感じがします。でも、Stringクラスなんて最初の頃から存在 してたのにも関わらず、拡張を続けているという事は、意外と枯れて いないのかしら？とも思ったりします。

攻殻2ndGIG鑑賞。パズとサイトーという普段は脇役的キャラクタを ターゲットとして、それぞれに一話という今回。サイトーの話に グッときました。

昼頃起床。

J2SDKに含まれるJavaコンパイラjavacと、gcjの違いを調べたり。 と言っても、挙動の違いを実験で比べただけですが。
AWTやSwingを使用したものでは、gcjでネイティブバイナリを生成 する事はできない事が判ったり、ImageIOはまだgcjのライブラリに 入っていない事が判ったりそんな感じ。 gcjの--help指定で表示されるヘルプは、gccのヘルプそのまま になってて役に立たないので、オプションの事を調べるには man gcjでなくてはならないとか、割と変な発見ばかり(^^;

Antを入れていたのですが、テストするのに丁度良いbuild.xmlが無かった ので、XMLパーサーである xerces をソースからビルドしてみる 事にしてみたり。ビルド用のツールを別途ダウンロードしなくては ならない事に気づかずに、なにやらエラーするのに唸ってみたり。 xercesのREADMEに、 「xerces本体とtoolsを同じディレクトリで展開せよ」というような 事が書いてあったので、ツールをダウンロードして、本当に 同じディレクトリに展開したらうまくいかなかったり (正しくはxercesを展開してそのディレクトリにもぐった所でtoolsを展開する) で、ハマりながらビルドしてみた所、一応 ライブラリの生成はできてみたり。でも、ドキュメントディレクトリの XMLは表示できず、使い方がよく判らないので、結局バイナリ アーカイブもダウンロードしてしまうへっぽこぶりを発揮(^^;。 READMEの通りに実行すると、jarしか生成しない模様で、./build.sh だけを実行してもそれと同じ。結局、./build.sh allとか指定すれば 良いみたいというのを、build.xmlを読んだりして判ってみたり。 んー、なんて言うか、こう、微妙に不親切というかそんな感じ？ 一応、AntによるビルドはOKと言えそう。それにしても、xercesの ビルドスクリプトも、Antのコマンドも、何気にシェルスクリプト でラッピングしてあって、確かにVM上で動作するバイナリは共通 にできているのですが、それを本当に使う様にするまでのやり方 に、微妙な感じがしました。
結局の所、最後はCPUの命令セットに変換されなければ実行できない 訳なのですが、VM自体はOS上で動く一アプリにしか過ぎないので、 OS上で動作するプロセスの一つとして起動する所までに、 シェルスクリプトや統合環境によるラッピングで一枚 皮をかぶせざるを得ないのが、仕方ないのですがダサいと思います。 どうせやるならば、JavaVM上で動作するUNIX風のシェル環境なり、 コンソール環境なりを作って、その上で普通にJavaのクラスを 実行ファイルの様に扱える様にすれば、もうちっとマシな感じが しなくはありません。そうなると、全てのツール(コンパイラも含む)を Java化する必要があるかも知れませんが。

そういや、gcjでは各クラスのヘッダファイルに相当するファイルが /usr/include/java|javax 下に置かれており、ファイルを見れば どのようなクラスやメソッドがあるのかはなんとなく判るのですが、 J2SDKには細かな事が判るファイルが一切無くて、普通どうやって クラスやメソッドの検索をするのだろうと思ってみたり。 何気にJ2SDKのディレクトリを探っていたら、src.zipという ファイルがあり、その中にソースが一式入ってました。 ファイル名とクラス名が一対一の言語文化なので、ここから 探って中身を見れば、どういうメソッドが存在するのか判ると いう感じ。
という事はImageIOがgcjで使えなかったのを、がんばれば使える様に なったりできるのかしら？

日付け越え前に帰着。ふぅ。

先日の話で、ふとこういうケースはどうか？と試してみたり。
先日の実験ではリストを保持するインスタンス自体へ参照を失わせる 事を行なったのですが、リストを保持するインスタンスはそのままに、 その中で保持しているリスト自体への参照を失わせる事を試して みました。でも、それでも問題無く、ガベージコレクタは動作しました。
リスト構造のように、実際に参照をトレースしなければ、その存在 可否が判らないようなパターンだと思われますが、うまく機能して いるようです。ふーむ。それにしても、何かしらの細工が必要か、 パフォーマンスに影響が出ると考えられそうですが、そこまでは 調べられず。

眠くて死亡。

昼頃起床。

リストの続き。なんとなくそれっぽくなった予感。 リストを増やしたり減らしたりしても消費メモリが変わらない所をみると、 ガベージコレクタが動いているようなそうでも無いような。それにしても、 newでオブジェクトを割り当てる事は意識するのに、オブジェクトが使われなく なるのは意識しなくて良いというのが、なんか気持ち悪い感じがしなくも ありません。

続いてC言語でいう所の関数ポインタのリストみたいなのをどうやって 作れば良いか考えてみたり。しばらく唸った結果、 メソッドのオーバーライドと、オブジェクトのキャストを使用すれば 良さそうな感じでそうしてみました。

MoveFunc.java:
class MoveFunc {
    int move( CharObject obj ){
     :

MoveFunc1.java:
class MoveFunc1 extends MoveFunc {
    int move( CharObject obj ){
     :

    MoveFunc mflist[]= new MoveFunc[10] ;
    mflist[0]=new MoveFunc() ;
    mflist[1]=new MoveFunc1() ;
       :

 TOP─┐
      │  ┌────┐    ┌────┐
      └→│List1   ├─→│List2   ├→null
    null←┤        │←─┤        │
          └────┘    └────┘

       CUR──────────┐
+-- -- -- -- -- -- -- -- -- --│- -- -- -- --  +
| TOP─┐                     ↓               |
|      │  ┌────┐    ┌────┐        |
|      └→│List1   ├─→│List2   ├→null  |
|    null←┤        │←─┤        │        |
|          └────┘    └────┘        |
+-- -- -- -- -- -- -- -- -- -- -- -- -- -- --  +

出張。日付け越え前に帰着。ふぅ。

Javaでリストを書く練習をしてみたり。でも途中でこんがらがって死亡(汗;

出張。

昼過ぎ起床。でも、ぐうたら過ごして終了。

ガベージコレクタとポインタ。Javaの文法で、参照型という用語が 出てくるのですが、これって動作的にはC言語の ポインタに似たイメージである事が判ってみたり。 これを踏まえてガベージコレクタの機構がなんとなく想像できる 予感がしたのでメモ。

ガベージコレクタはインタープリタ言語などで実装されている、 未使用となったメモリ領域の回収→再利用機構の事を指すのですが、 恥ずかしながらどういう時にその動作が発生し、それは具体的にどの様に実現 しているものなのか良く判ってませんでした(^^;
C言語ではポインタというメモリ領域の位置(アドレス)を指す 仕様(概念)があります。ポインタは意図した任意のメモリ領域を 指す事ができ、しかも領域を指すのに何の手続きも必要と しません(借金するのに借用書を書かずに借りられるような感じ？)。 従って、malloc()関数などで取得したメモリ領域をとあるポインタ変数に 覚えた後、何も考えずにそのポインタ変数に全く別のメモリ領域を 指し直すような事も、問題無く行えます。 ここで問題になるのは、ポインタを新しいメモリ領域に指し直した時、 元々指されていたメモリ領域からは、その領域がいかなるポインタ変数 からも指されていない、いわゆる未使用状態になっている事を、 知る術が無い点でしょう。唯一未使用状態になった事を知る方法は free()関数で未使用メモリ領域になる事を、明示的に知らせる しかありません(真の意味ではプログラムを作成した本人にしかfree() して良いかどうかは判らない と言えるかも知れませんが)。 何せ、借用書無しにお金(メモリ)を貸している のですから、債務者の自己申告以外に貸したお金を回収する方法が 無いという感じでしょうか。このような状況が意図せずに生まれてしまい、 メモリを確保するばかりで不要になったメモリを一向に返さないという状態が 続く事をメモリリークと呼び、稼動時間の長いプログラムでは思わぬ 動作不具合を起こしてしまう事があります。 他にも、OSがメモリ保護機能を有している場合は、ポインタでいくら自由に メモリ領域を指す事ができても、その領域が保護されていると、 読み書きした途端にSegfaultで死んでしまいます。実際に自分の持ち物で無いものを、 そこにあるからと言って、勝手に使うと捕まるのと同じイメージ でしょうか。
一方、Javaやインタープリタ系の言語にはポインタという概念を 明示的に持ったものはありません(私の知る限りは、ですが(^^;)。 しかしながら、コンピュータという機構の 下で動く以上、メモリをデータの記憶領域として使用する必要が ある為、どの変数をどこに記憶しているかを指す手段はどうしても 必要になります。ここで、メモリから必要な領域を割り当てる時と、 その領域を指さなくなった時を監視する機構があれば、メモリ領域 が指されなくなった時点で、その領域は未使用領域である事が 判定できると思います。あるメモリ領域を指さなくなる契機は 何でしょう？と考えると、メモリ領域を指す変数の代入が挙げられる と思います。ポインタの概念が無い言語仕様で、ポインタに代わる 物は 動的にメモリ領域を確保する事が宣言されたインスタンスや文字変数が 挙げられると思います。これらの変数に代入が行なわれる際、 元々指していたメモリ領域を未使用領域に指定してから、新しい領域を 指し直せば良い事になると思います。
例えば文字列変数を使用して、次の様な操作を仮定してみます。 「$str1="new",$str2=" message",$str3="old message"」とした時、 $str3を「$str3=$str1 + $str2」として、"new message"という文字列 に置きかえてみる事を考えてみます。

1. $str1が指している領域と$str2が指している領域のサイズを足した新たな領域を確保する。
2. (1)で確保した新たな領域に連結式に従って"new message"という文字列データを作成する。
3. $str3が元々指していたメモリ領域を無効化する。
4. $str3を(2)の領域を指す様に変更する。

1. 任意のメモリ領域を指す手段を設けない。(C言語でいう所の str='&'foo とか、char *str=0xnnnnnnnnとか)
2. 異なる参照型(クラス)からのキャストを許さない。

1. $A="c4d4e4f4" で４拍子のドレミファを演奏する演奏データを格納する。
2. play $A+$A+$A+$A で４拍子のドレミファを×４回続けるとした時、
3. 一時領域(仮に$TMPとする)として $TMP=$A+$A+$A+$A　という領域を生成し、
4. 実際の演奏には play $TMP を実行する。
5. play文を通過すると、$TMPは参照しなくなるので、未使用領域にする。

昼過ぎ起床。

ppcsim 0.96bをリリースしてみました。御参考まで。

彩コアモジュール三版で、描画ツール類のパラメータをいじり過ぎて 元の値が判らなくなってしまったので、レジストリエディタを使って レジストリキーを削除し、設定を初期値に戻してみたり。 アレ？水性ペンと筆ツールって同じパラメータでしたっけ？

姉チャン。ひたすらゾンビ切り。フラグを立てる条件が、あるブロックの ゾンビ殲滅というのが多いので結構面倒なのですが、バイオハザードみたく 恐くない のが、TANE的には丁度良いです(あのタイトルで恐いのを期待する奴ぁいない でしょうが)。難点はと言えば、ストーリーモードの セーブポイントは面クリア毎なのですが、一面当たりのクリア時間が 結構かかったりするものですから、セーブ機能は付いているのに 本体電源入れっぱなしという何だか訳わからない状況になってます。

切って切って最終面入り口で(自分の肩が)力尽きて死亡。

ケロロ軍曹をやってる時間に起床。健康的(そうか？)

久しぶりに神保町をウロウロ。でも、特にめぼしいものは見つからず。

binutils-2.15対応という事で、ELFファイルのロードルーチンを見直して みたり。セクション名を見ずに、.text領域は固定にしてあったのですが、 単純にセクション名の引き方がよく判っていなかっただけだったりします。 そんな感じで真面目に見直した所、なんとなくセクション名を引く方法が 判ったので、.textという名のセクションで始まる領域のメモリ配置アドレス の先頭を実行開始アドレスとする様に変更してみました。 そんな感じで、配置が変わっても追従するようにできました(^^)v。

ppcsimの使用方法のページも少し古くなってて、微妙に使い方が変わっていたり する点もあったので、「ppcsimの使い方」と「ppcsimインターナル」を 更新してみました。更新時に実際にppcsimで動かしながら、表示が変わった所 などを切り貼りしていたのですが、その途中でppcsim-0.95で表示がバグって いるところを発見したり色々(^^; まだ直しきれていない部分がありますが、 取りあえずの参考まで。

binutils-2.15 + gcc-3.4.2の組合わせで再度povrayのppcクロスコンパイル を行ない、ppcsimでの実行確認を行なってみたのですが、前回3.4.1に対して 0.3%程度実行命令数が増えてしまうという結果だったのですが、 今回はそんなにムチャクチャになりませんでした。システムコールの 実行回数が何故か26463回も実行されているという謎の結果だったのですが、 今回は3582回と増えてはいるものの、変というほど増えていませんでした。 むー、何故だ？
そんな訳で、以前の実行結果と今回の実行結果を見比べてみる事に。 すると、システムコールllseek()の戻り値が以前実行したものと異なっている のを発見。今回のはllseek()のエミュレート(Cygwinネイティブでlseek()に 置き換え)の戻り値がエラーしている模様。何故？試しに、

   ret = lseek( get_phyfd(mres,(int)mres->GPR[3].rl),
		(off_t)mres->GPR[5].rl,
		(int)mres->GPR[7].rl ) ;

   ret = lseek( get_phyfd(mres,(int)mres->GPR[3].rl),
		(off_t)((int)mres->GPR[5].rl),
		(int)mres->GPR[7].rl ) ;

出張。帰着。ふぅ。

Cygwinパッケージをダウンロードしたり、Webをちょろっと巡回したら眠くて死亡。

出張。

出張。

出張。

出張。

明け方までSAIを使ってて、寝て起きたら午後もいい時間(汗;

寝る前にgcc-3.4.2の再ビルドを仕掛けていたのですが、エラーで終了してたり。 一応libstdc++のconfigureは通っているみたいですが、前のゴミが残ってて うまくいかなかったのかと思い、libstdc++ディレクトリ下を手でファイル削除 して再度ビルドしたり。今度はOK。ふう。それにしても、前に3.4.1がどうやって ビルドできたのかが判らないままなのですが、binutilsのバージョンに依存する 場合もあるという事みたい。それにしてもやっぱり謎。

そんな訳で、povray-3.5bをPCCクロスビルドしppcsimで実行確認。何故か UnknownInstructionでシミュ実行失敗。スタートアドレスを見ると、 Linuxバイナリは0x10000100を固定でスタートアドレスとしていたのですが、 それがずれている模様。スタートアドレスを変更して実行しようとした所、 LinuxSysCallのエミュレーションモードではppcsimオプションによる 変更ができないというバグを発見したり(^^; ちょろっといじって実行したら、 やはりその先でUnknownInstruction。どうやらDLLによるライブラリ読み込み がONになっているらしく、先日の--as-neededオプションが関係しているのかと ldのmanページを見てみると、やはりDLLに関連するオプションらしい事が 判りました。で、gccのconfigure実行を確認した所、どうやら--disable-shared 指定が抜けいたようで、この為、sharedライブラリの使用可能という事で それ用のバイナリが生成されるようなビルド(なので、ldの--as-needed が必要だった)になっていたというのが原因の様です。という訳で、 謎は完全解明。てゆーか、ヲレのせい？てへっ
逆に、sharedライブラリを有効にする場合はbinutilsの2.15 を使用しなくてはならないと言う事になりそうです。
で、また、gccを--disable-shared指定ありでビルドしなおすこと数時間、 それでpovrayをビルドしたのですが、やはりスタートアドレスが変わっている 模様。これはbinutils-2.15によるものだろうという事でbinutils-2.14に 戻して、再度povrayをビルドし直して、どうやらスタートアドレスが 今まで通りになりました。しかしながら、binutils-2.15を使用すると、 ppcsim実行がうまくいかないというのは問題です。スタートアドレスの 取得方法を見直す必要がありそうです。
そんな訳で、povray実行で確認したのですが、何故かシステムコール実行が 3.4.1に比べて異常に多くなってたり(3.4.1まで3334回だったのが 3.4.2では26463回実行されている)、命令数で0.3%ばかり増えていたり (3.4.0→3.4.1の時は0.00004%程度の悪化でした)で、 マイナーバージョンアップの割には思いっきりレベルダウンしている予感が します。なんとなくlibstdc++の影響が大きい予感がしますが、本当の 所はよく判らず。

因みに、cygwinの方は、gccビルドを何度も行なってましたが、ハングる事も 不穏な動きも無く安定動作してたので、当面はこれで使ってみるという事で。

そんな訳でSAIコアモジュールテスト３版レポート。 全ツールについて、筆圧感度が調節できる様になってます。 150%程度で使用したのですが、スタイラスを握る手が疲れる事が無く、 非常に快適でした(^^)。他、筆ツールが追加となってます。 パラメータが多く、色の出具合を確認するのに少し手間がかかりましたが、 TANE的には結構好きな味が出ていると思います。色々変えてなんとなく は判った気にはなってますが、パラメータがそれぞれ、どこにどのように 効くのかが判れば、もう少し出る色のイメージを掴みやすいかもと思いました。
一点気になったのが引きずりの挙動について。引きずり自体のイメージは 掴めるのですが、実際に使用してみると、コントロールが難しい様に感じました。 その理由を考えてみたのですが、引きずりの元になる色に透明度の値が 入っていない為、例えば、赤(RGB:FF0000)を筆圧を弱めて塗り、 薄い赤になった下地を作り、それを引きずると、薄い赤(RGB:FF8080とか)と現在色が 混ざるように直感的には思うのですが、実際には透明度成分の無い元の赤(RGB:FF0000) と混ざった結果になるため、それが、見た色から引きずりを想像した結果と 直感的に結び付かないという点が、コントロールの難しさに感じる のではないかと推測します。



そういや、筆ツールの「筆圧→描画濃度」のチェックを外しても、描画濃度が 筆圧に反応している様に思いました。怪しげに思ったのはその辺だけでした。

そんな訳でラクガキ。何も考えずに描いたら、途中でどうしたいのか よくわかんなくなったというヒドい感じに。今回は筆をメインで使って みたのですが、結果的に引きずりとかをうまく使った感じにはなってないです(^^;



午後の良い時間に、セロというマジシャンの出ている京都めぐりの番組を やってました。 以前たまたまTVで見た事があった のですが、かなり凄くて驚いたのを覚えていたので、思わず見てしまったり。 見ていて何がスゴイのかと考えたのですが、ストリートで次から次へと 物を出すマジックを行なったり、相当な至近距離で起こっているけど全然判らないと いうのが、その凄さなのかなぁと思いました。いやー、ビックリ。

何気にハマりこんでいる週間少年ジャンプで連載中の「DEATH NOTE」。 単行本でしか読んでないのですが、なんていうか、こう、変なドキドキ感 に病みつきです。それが３巻目に来て「むきーっ！こう来たかーーっ！」 という感じになり、更に、条件が加わりそうな続きがすごく気になってます。 因みに、L視点で見るか、キラ視点で見るかで、その人の性格が判るような 気がしなくもありませんが、今の所TANEはキラ視点です。もう、いつ バレるかヒヤヒヤしながら読んでる感じです。L視点方はまだ名前がバレて いない分、ヒヤヒヤ感はありませんが、４巻目以降で出てくるミサという 死神の目を持った女が出てくると、L視点もヒヤヒヤ感が上がりそうな 予感がしています。

朝普通に起きたと思ったら、二度寝して昼過ぎ起床(汗;

先日ビルドしたスナップショットをインストールし、更に 自分ビルドをしてみたり。取りあえず fork()でIDLE状態に 陥り、ハング状態になるという感じにはなりませんでした。 何も変わって無いので、今回はたまたまOKだったという 話があるのかも知れませんが、取りあえずこれで様子をみてみよう と思う所。

gcc-3.4.2が出ていたので、ダウンロードしてみたり。 差分の一覧を見る限りでは、PPC32に対する変更は加えられていない ので、3.4.1のバイナリと同じ結果が得られそうですが、 cygwinのテストも兼ねて(libstdc++ライブラリは何故かfork()の テストに効くのです)、ビルドしてみる事に。でもlibstdc++のconfigure実行に 失敗。ただ、今回はcygwinの不具合起因ではなく、純粋にconfigure実行での 不具合起因による模様。

checking for stdint.h... (cached) yes
checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] Error 1

configure:2353:  /cygdrive/c/tane/develop/tooltest/gcc-3.4.2/build/gcc/xgcc -B\
/cygdrive/c/tane/develop/tooltest/gcc-3.4.2/build/gcc/ -B/usr/local/ppc/powerp\
c-linux/bin/ -B/usr/local/ppc/powerpc-linux/lib/ -isystem /usr/local/ppc/powerpc\
-linux/include -isystem /usr/local/ppc/powerpc-linux/sys-include -o conftest -O2\
 -g -O2 -O2 -g -O2  conftest.c  >&5
/usr/local/ppc/powerpc-linux/bin/ld: unrecognized option '--as-needed'
/usr/local/ppc/powerpc-linux/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status

print "                                      \n" ;

--------perl -e "print \"        \
--------        .\n\";"

tmp> make -v
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
tmp> cat Makefile 
SHELL=/bin/sh

aaa : a.v
--------perl -e "print \"       A\
--------      a    .\n\";"

tmp> touch a.v
tmp> make aaa
perl -e "print \"       A\
   a    .\n\";"
       A a    .

出張。帰着。ふぅ。

Cygwinアップデート。cygwin1.dllのバージョンが上がっていたり、色々 ありますが、win32apiが3.1になっていたので入れてみました。 これの一つ前のバージョンでは、OpenGL関連の#define定義が、更に 一つ前のバージョンよりも削られてしまってて、Nurbs関連の基本的 なプログラムがコンパイルできないという罠がありました (参考)。 今回入れた3.1では取りあえず、HairMakerのコンパイルはOKそう。 もっと突っ込んだ使い方をするとどうなのかは判りませんが、 TANEが現状使っている範囲内ではOKそうな予感がします。

SAIの新版が出てたり。 筆ツールの実装など、かなり多くの機能が追加実装されていますよ。 パラメータの調節項目が多くなっているので、パラメータの感触を 掴んでいるところです。

で、cygwin DLLを1.5.11-1にしてみたのですが、fork()性能問題 が残ったままなので、一旦古いのに戻したり。 先日スナップショットをコンパイルした 時は、自分コンパイルができなかったのですが、取りあえず 先日のものより新しいのが出ていた(fork.ccに変更は無いのですが) ので、fork()性能問題回避パッチだけをあてて、ビルドを仕掛けてみたり。

とかやっているうちに眠くて死亡。

出張。

出張。

出張。

出張。

昼過ぎ起床。

そんな感じで表示だけはこんな感じになってみました。 読み込みにちょっと時間がかかる(ISDNで10秒くらい)かも知れません(^^;

テスト

何気に、先日消えていると言ったα値もちゃんと残っているようで、 結局、何が問題だったのかよく判らなくなってしまってますが、 取りあえず結果オーライという事にしてしまおう。

そういや、Javaアップレットのソースを複数のファイルに分けて、makeで ビルドする事を考えた時、javaソースファイルの中に複数のクラスを 記述すると、コンパイル後はクラス名毎に.classファイルが生成されます。 JAVAではクラス名とファイル名との関係が非常に強い(というか無視できない) ので、makeを使う上では一見 makeのルールに厳格に沿っていそうですが、 例えば一つのfoo.javaというソースから、foo.classとfoosub.classが生成 される場合、foosub.classを消してしまっても、foo.javaを再コンパイル する必要があるという指示ができません。そんな感じでなんか微妙。 まぁ、ファイル名とクラス名が一対一になっていれば、クラス検索などが ファイル内をシークする必要が無い分、高速にできそうなのは容易に 想像できるので、それはそれでメリットはある所なのでしょうが。
また、アップレットに限って言えば、生成されるのは.classファイルなので、 例えば複数の.classファイルが必要な場合でも、アップレットとして 直接実行するクラスファイルを生成物の頂点にしてしまうと、そのクラス を含むソースをコンパイルすればOKな様に見えてしまいます。 なもんですから、必要な全てのクラスをコンパイルする事で得られる 実行ファイルに代わるものをフラグファイルとして用意し、 そのフラグファイルよりも新しいソースはコンパイルするというような 細工を行なう必要がありました。

後、#defineのようなプリプロセッサ処理を使ったり enumを使うといった、 定数に名前を付ける手段(というか習慣)が無さげなのですが、これぁ クラスの中に変数を定数型であると自分で決めて使うから必要が無いと いう感じなのでしょうか。どうにも定数をそのままソース中に書く サンプルが多くて(言語仕様に無いのではそうもなるでしょうが)、 ちょっと変えたいだけなのに、そこら中を良く見て変えなきゃいかんというのに、 これ本当か？と思う所があります。

昨日、今日と、地震で揺れる揺れる。震源地は関西方面のようなのですが。

昼過ぎ起床。

先日の続き。stubをコピーできるか試してみました。でも、コンパイルは 通るものの、実行するとアクセス違反になるみたい。

     1  import java.applet.Applet;
     2  import java.applet.AppletStub;
     3  import java.awt.*;
     4  import java.awt.image.*;
     5  
     6  class ChipChar extends Applet {
     7      int    x ;
     8      int    y ;
     9      Image  img ;
    10      private transient AppletStub stub;
    11  
    12      int ReadImage(String fname){
    13          this.img = getImage(getCodeBase() , fname);
    14          return(0) ;
    15      }
    16  
    17      ChipChar(int x, int y, AppletStub stub){
    18          this.stub=stub ;
    19          this.x   =x ;
    20          this.y   =y ;
    21      }
    22  }
    23  
    24  public class test extends Applet implements Runnable {
    25      ChipChar   pcg ;
    26      
    27      public void init() {
    28          pcg = new ChipChar(0,0,stub) ;
＜以下略＞    

java_test> /c/j2sdk1.4.2_05/bin/appletviewer.exe test.html
java.lang.IllegalAccessError: tried to access field java.applet.Applet.stub from class test
        at test.init(test.java:28)
        at sun.applet.AppletPanel.run(AppletPanel.java:353)
        at java.lang.Thread.run(Thread.java:534)

出張。帰着。ふぅ。

先日のJavaコードについて、 しんさんより助言をいただきました。 しかし、まるで呪文を唱えられているような感じで、個々の単語の意味が 全く判らないというダメっぷりの為、用語の習得から始めてみました(^^;
という訳で、実験コードを書きながら動きを確かめてみた所で、 おおよそ次の様に理解してみました。

まず、getImage()やgetCodeBase()といったメソッドはAppletクラスの中で 定義されており、Appletクラスの中で定義されているメソッドのそれと同じ ものを指すつもりであれば、Appletクラスを継承する必要がある (継承しないとローカルスコープ内にgetCodeBase()というメソッドなど 無いという感じのコンパイルエラーになる)。所が、先日のような書き方を すると、何故かgetCodeBase()を実行するとNullポインタ例外となりました。
そこで、gccのソースの中に含まれるAppletクラスのソース (gcc-3.4.1/libjava/java/applet/Applet.java)を眺めてみると、次のような 感じになってました。

public class Applet extends Panel
{
  ＜中略＞
  /** The applet stub for this applet. */
  private transient AppletStub stub;
  
  ＜中略＞
  public URL getCodeBase()
  {
    return stub.getCodeBase();
  }
  
  ＜以下略＞

出張。

もう一日だけ休業。