J

2004 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 12 |
2008 | 01 | 02 | 04 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 12 |
2013 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2014 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2015 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2016 | 01 | 02 | 04 | 05 | 06 | 07 | 09 | 11 | 12 |
2017 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 |

ホーム

日記内の"morihyphen.hp.infoseek.co.jp"へのリンクは切れてます。必要な場合はお手数ですが int.main.jp へ書き換えをお願いします。

TODO: ファイル名確認を忘れないこと > 自分

twitter

 | 

2004-11-30

00:32

んんん。何をどうやってもPCの時計が狂っていくんだけど。

火曜日の昼の12時とかになってる。


あんま関係ないけど、Windowsの「日付と時刻のプロパティ」ってカレンダ代わりに使えるように見えてAdmin権限無いと見れないようになってんだよな。

14:48

あー、こうやって書くネタが無いときは本でも読んで勉強してりゃいいのにな。最近あんまり本読まなくなったなぁ…というか、最近て。過去に一度でも本を読みまくってた時代があったかのような感じだな。実際にはなかったんだけど。

眠い。眠いし、やることないんだったら寝たらいいのにッ!

トラックバック - http://d.hatena.ne.jp/w_o/20041130

2004-11-28

PSY-NO 14:48

http://shinh.skr.jp/psyno/

が、楽しすぎる。


とりあえず、1番とれたー。ノーミスだって。アホか。

ばらけさせる作戦と密集させる作戦のどちらがいいかを昨日一晩かけて試した結果、ばらけさせるほうがうまくいくような感じ。

Pattern 1〜5はあの形で3回に1回はとれる。Pattern 6〜10は運。Pattern 7,8あたりがどう出るか次第。Pattern 11〜17ぐらいは気合。アドリブ。Pattern 18〜20は弾避け次第。って感じで。

2004-11-27

今日はドラクエ発売日ではないか。と、いうようなことにいまさら気付いた。

GCCのspecs 14:48

specsについては前に調べたと思うんだけど、調べたことが中途半端だったうえになんか今見たら全然わからなくなってたのでメモ。


specsというのは、gccの補助プログラム呼び出し時のルールを書いたファイルのことだ。

gccは実はCコンパイラではなくて、拡張子に応じて、各種言語のコンパイラを呼び出してるだけっていうのは有名な話かと思う。で、そこらへんで各コンパイラを呼び出すときのオプションのルールを書いてあるのがspecsというわけだ。

で、まあ、そういう話はまあ、ふーん、って、ところなんだけど、このspecsがまた無駄なくらい高機能になってたりするので、GCC作ってる人達は変人ばっかだなぁ…と、いうか、素晴らしいと思いました。


まず、手始めに、簡単なところで、

.yes:
	yes %b 

こんな感じ。意味は、'yes'っていう拡張子だったら、次の行を実行っていうところか。%bは入力ファイルの拡張子を取り除いたもの。

(行末の処理がおかしいのか、行末にスペースが必要のような気がする)


例えば、上のを、"yes.spec"として、

$ gcc -c -specs=yes.spec no.yes

ってすると、

no
no
no
no
...

こんな感じで。(ただ、入力ファイルが存在するかどうかのチェックはしてるようなので、touch no.yesとかをしておかないといけない。)

%の文字についてはgcc.info、もしくはgcc.cのソースなんかを参照。


で、別の言語のコンパイラを呼び出したりもできる。

例えば、

.my-c:
	@c

@cにすると、C言語コンパイラを呼び出す。@Javaとか@C++とかもできる。


んで、specで重要なのはオプションに対応する場合だ。%{hogehoge:naninani}とかってすると、-hogehogeとしたときに、次のプロセスにオプションnaninaniが渡される、というものだ。例えば、

.yes:
	echo %{good:イイヨー} 

なんてして、

$ gcc -c -specs=yes.spec -good a.yes

こーやると、

イイヨー

こんな感じ。で、%{!hogehoge:naninani}ってすると、-hogehogeがなかったときに、naninaniが渡される。

.yes:
	echo %{good:イイヨー}  %{!good:ダメダヨー} 

こーすると、

$ gcc -c -specs=yes.spec -good a.yes
イイヨー
$ gcc -c -specs=yes.spec a.yes
ダメダヨー

こんな感じ。


他にも色々機能あるんだけど、このぐらいわかるようになればspecsも読めるかと。ただ、ファイルとして出力されてるのはgcc -dumpspecsされて生成されたものなんだけど、このspecsは各言語の全てについて記述されているわけではないようなので、実際のgccの挙動を理解するにはgcc.cを読まないといけないかもしれない。


ていうわけで、gccドライバはただのspecs言語インタプリタであった、という話。

[] オプション対応 14:48

で、specsを理解したところで、ILogにオプション対応。ilogcをコンパイラドライバにして、コンパイラをilog1に変更…って書いても多分僕にしかわからない。

要するに、今までできなかったファイル名渡しが可能になったということです。

$ ilogc --script-file=orz.ilog orz.orz

ってして、orz.ilogで、

print( options.input_filename );
print( "\n" );

ってすると、

orz.orz

って表示されるかと。あと、--ilog-optionも追加。

$ ilogc --ilog-option=val=hikisuu --script-file=orz.ilog orz.orz 

と、して、

print( options.val );
print( "\n" );

ってすると

hikisuu

と、表示。


これで、必須だけど足りないと思ってた分はとりあえず対応できるようになった、ということで、バージョン0.1にしよう。いや、前のが0.0.1でわかりにくいので、0.2だな。0.2っていうと、大きく出すぎた感じがあるけど。

構造体みたいな型システムも対応済み。以前のでも対応できていたはずなんだけど、僕が型システムを理解した、ということで対応済み…

気合さえあればC言語クラスの物が書けるはずだ。浮動小数点が無いけど。


ただでさえややこしいGCCのシステムの上に糞みたいな俺言語理論が乗っかってるので、もはや僕にしか理解できないものだらけになってきた。まずいなぁ…。けど、だからといってそこらへんはどう対応したらいいのかは全然わからない。

ilog-0.2


memo: ファイル名を確認すること > 自分

トラックバック - http://d.hatena.ne.jp/w_o/20041127

2004-11-24

よし。w3mのライブラリ化に多分成功。と。

w3m 14:48

おもむろに、HTMLのエンジンが欲しくなったので、「よーしここはGeckoでも使うべ」とか思ったんだけど、やっぱGeckoは大きいしなぁ…と、思って、w3mにした。HTMLのパースさえしてくれれば十分なんだよね。だったら最初にw3mの名前を思い出すべきだったんだけど、記憶から消えてた感じだった。駄目だなぁ…

#include <stdio.h>
#include "fm.h"

int
main(int argc, char **argv)
{
  Buffer *buf;
  AnchorList *al;
  int i;
  Line *l;
  Str s;

  w3m_init_rc();
  buf = loadGeneralFile( argv[1], NULL, NO_REFERER, 0, NULL );
  al = buf->href;

  for ( i=0; i<al->nanchor; i++ ) {  // リンクを表示
    puts( al->anchors[i].url );
  }

  for ( l=buf->topLine; l; l=l->next ) { // 本体を表示
    char *s = conv_to_system( l->lineBuf );
    puts( s );
  }

  return 0;
}

これで、w3m -dumpと同じようなことが出来ます。オマケでサイト内のリンクも表示。これぐらいできれば十分か。

む。思ったよりバイナリサイズ大きくなるな…。1MB近い。


パッチ

パッチ作ったらその大半がconfigureで埋まっててアレだったので、configure削除してます。パッチを当てたあとにautoconfしてください。

autoconfが2.5以上じゃないといけないことに気付かずに時間かかったのは色んな罠だ。


まず、w3m_init_rcで初期化。

で、loadGeneralFileで読み込み。必要なことは大体ここでやってくれる。で、Buffer型の物が返ってくるので、あとはそれをいじるだけ。Buffer型についてはfm.hを参照のこと。libw3m.cのCOLS、LINESを変更すれば幅、高さを変更。あとはあんまりわからない。

0.4.2 14:48

あ。0.4.2は300KBより減らせるのか。0.5は大きいのかもしれない。

修正 14:48

ファイル名違う…って何回目だよ…

トラックバック - http://d.hatena.ne.jp/w_o/20041124

2004-11-22

今日は「ボタン押して5分待って正しい動作するか見守る」っていう非常に何もしない仕事だったので、アレだった。

と、まあ、そんな感じで暇だった(それは駄目じゃないのか?)ので、今日はGCCのバックエンド見ながら、「へー」とか、感心してた次第。


で、GCCバックエンドの記述方法は、非常に柔軟性があって、色々書けるっていうのはわかるんだけど、それでも、やっぱりPentium4とかの最適化規則を表現しろっていうのには足りないように感じる。

ていうか、Pentium4最適化規則って一般人に理解できるもんなんだろうか。ましてや、それの最適化アルゴリズム書くなんて可能なのか?


なんてことを考えながら、GCC Linuxっていうのを思い付いた。GCCのためだけの1CD Linux

過去はStallman直筆の1st GCC から、最新鋭tree-ssa搭載4.0スナップショット。さらには、boundsチェック、Propoliceスタックチェックその他各種パッチ対応GCC、さらには、ネタ言語SPLからGCCの関数型の可能性Mercuryまで各種フロントエンド、cloop圧縮の670MBのディスクにありとあらゆるGCCのソース、バイナリめいいっぱい詰め込みました。って感じで。

スタイル 14:48

returnとか、sizeofとはあんまり関係ないんだけど、僕の書くコードは build_hogehoge、 create_hogehoge、 new_hogehoge、さらには、hogehoge_build とか hogehoge_create が何のルールも無く混在してたりするのでよくないと思った。これからは特に理由の無い限りcreate_hogehogeに統一するようにしておこう。いや、でもやっぱり気分によって変わるかもしれない。

[] RTL 14:48

ああああ。わからん。RTLの構造は全然わからんからRTL関連のエラーが出たらどうしようもないような気がしてたんだけど、ついに、今日、そんな感じになってしまった。

sample.seni: In function `sample_loop':
sample.seni:1: error: unrecognizable insn:
(insn 22 21 23 (parallel [
            (set (reg/f:SI 7 sp)
                (plus:SI (reg/f:SI 6 bp)
                    (??? bad code 45616
)))
            (set (reg/f:SI 6 bp)
                (mem:SI (reg/f:SI 6 bp) [0 S4096 A8]))
            (clobber (mem:BLK (scratch) [0 A8]))
        ]) -1 (nil)
    (nil))

何が言いたいいんだね?君は。spとかbpとか見る感じ、スタックフレームのサイズが怪しいんだけど、これだけでは何もわからない。

何から手を付けたらいいかわかんない感じは久し振りだったので、まあ、楽しいといえば楽しいんだけど。


とりあえず、2時間くらい色々試して、saved_treeの最適化っぽい感じじゃないかというところ。3時なので寝る。

はやまだすはやまだす 2004/11/22 23:07 先生、make_hogehoge を忘れています!

w_ow_o 2004/11/23 03:05 む、確かにそうですな。でもmake_hogehogeは僕は滅多に使わないような気がします。

あと、hogehoge_makeのパターンってのは全然見ないような気が。

トラックバック - http://d.hatena.ne.jp/w_o/20041122

2004-11-21

うう…結局何も思い付かんかった…多分SDLネタは用意できないです…

VM積むのはあたりまえなのか 14:48

吉里吉里

ふと、「そーいえば、吉里吉里のスクリプトもJavaScript似とかだったよーな。」とか思ったので、吉里吉里について調べてみた。

吉里吉里といえば、吉里吉里とTJSとKAGの関係がいまいちよくわからないことで(僕の中で)有名かと思うけど、まあ、そこらへんはSpiderMonkeyがMozillaにのっかるとMozillaJavaScriptエンジンになる感じで、TJSっていうスクリプトエンジンが吉里吉里とくっついて吉里吉里システムになる、というような感じの解釈でよさそうだ。んで、その吉里吉里システム上で書いたアドベンチャーゲーム用のプログラムをKAGと呼ぶらしい。(バージョンごとに色々あるみたいなので、正しくはバージョン表記もいるかもしれない)

と、いうことは、「吉里吉里のスクリプトエンジン」と、した場合は、TJSを指すということなのだろうか。と、いう感じで、TJSについて調べようとしたところ、なんか一番下に仮想マシンとか書いてあるじゃないかー

いや、しかし、アレだなぁ。アドベンチャーゲーム用のスクリプトっていうと、適当に作られた感じがするんだけど、こう、これは、オマケ的に作られたって感じじゃないような。仮想マシン生成するスクリプトとなると、それだけで、伝わってくる本気度が違うよなぁ…。


ああ、まあ、正確にはADVG用に作られたのはKAGのほうであって、TJS自体はADVG用のスクリプトじゃないのか…

と、すると、自分で作ったスクリプト言語でスクリプタ書くっているっていうことか。なかなか熱いなぁ…


と、いう、特に意味の無い感想文。


あと、

汚rect管理はMozillaのが参考になるらしいっていう話と、sizeof(a).b は sizeof((a).b)になるっていう話が参考になった。参考になったといっても、僕はどういう場面で使ったらいいのかはわからないけど。

14:48

はてなキーワード多いと見にくい予感

OrcaOrca 2004/11/22 10:15 sizeof演算子のソレは, +演算子とかに置き換えてみるとそんなに変でもないれすね。
1 +(a).b == 1 +(a.b) == 1 + a.b

sizeof演算子に ”()”付ける人 多いし, return に ”()”付ける人もたまに見かけるけど, σ(^^) はどちらも付けない派です。

w_ow_o 2004/11/22 22:51 確かに、少し考えれば理解できるんですけどねぇ。少し考えないとわからないというか。

あと、僕の場合はreturnには()は付けないけど、sizeofには付けるっていう一番ありきたりパターンです。

トラックバック - http://d.hatena.ne.jp/w_o/20041121

2004-11-20

[] 演算子順位構文解析 14:48

ほい、できた。

using gcc;

var opparser_table = [ 
		      [[`TOK_MULT:MULT_EXPR],[`TOK_DIV:CEIL_DIV_EXPR]],
		      [[`TOK_PLUS:PLUS_EXPR],[`TOK_MINUS:MINUS_EXPR]]
];
var parser = Parser.create_oppre_parser( opparser_table );

var lextable = [
		["[0-9]+":`TOK_DIGIT],
	        ["\\+":`TOK_PLUS],
		["-":`TOK_MINUS],
		["\\*":`TOK_MULT],
		["/":`TOK_DIV],
		["[ \t]":null],
		[ null:`EOF]
];
var lexer = Lex.generate_analyzer( lextable );
var queue = Lex.new_lex_queue( lexer, file.open_rstream("expr") );

var counter = 0;

function term_func( lqueue ) {
  var tok = lqueue.get();

  counter += 1;

  if ( tok == `TOK_DIGIT ) 
    return counter;		// ほんとはちゃんと数値を返さないと
  else
    return 2;			// 超適当
}


var ctxt = parser.new_context();

var tree = parser.parse( ctxt, queue, term_func );
debug_tree( tree );

これで、

1 * 2 + 3 * 4 - 5 * 6

これを食わせると

 <minus_expr 0x404f9840
    arg 0 <plus_expr 0x404f94f8
        arg 0 <mult_expr 0x404f9138
            arg 0 <integer_cst 0x404f803c constant 1>
            arg 1 <integer_cst 0x404f8258 constant 2>>
        arg 1 <mult_expr 0x404f94e0
            arg 0 <integer_cst 0x404f862c constant 3>
            arg 1 <integer_cst 0x404f8848 constant 4>>>
    arg 1 <mult_expr 0x404f9828
        arg 0 <integer_cst 0x404f8cbc constant 5>
        arg 1 <integer_cst 0x404f8ed8 constant 6>>>

こうなる。

演算子順位(operater precedence)をoppreと略すのは大丈夫なのか?


そろそろ、気持ち悪いバグとか、関数間でつじつまが合わないところとか出てき始めたので、これまで適当に作ってきた分のツケがまわってくるのかもしれないなぁ…

シューターのジレンマ 14:48

今日もやってくるか。と、思って、ゲーセンまで行ったんだけど、既に先客がいて、なんかクリアしてしまいそうなペースだったので、微妙な気分になって、見ないようにして帰ってきた。

こう、避けかたとか、稼ぎかたとか、見てしまったらつまらんからなぁ…。けど、だからといって、わざわざ、それを見ないようにして、あとでそれを自分ひとりで組み立てるっていうのも他人が開発したパターンの車輪の再発明っぽい感じがしてなんか無駄っぽいんだよなぁ…

こう、どうすればいいかわかんないんだよなぁ。見るべきか、見ざるべきか。2chとか。見たら、あの微妙にわからない稼ぎシステムとかがわかるようになるんだろうけど。

14:48

なんか、色々考えるんだけど、「それってCへのトランスレータでも十分実装できるんじゃないかなぁ…」とか、そういう気分になる。わざわざRTLに変換する利点は?GDBで調べられる?でも、C の #line とか使えばGDBもそれなりに努力してくれるんだよなぁ…

RTLにしないとできないことっていうと、g++のコードが投げる例外を捕まえるぐらいしか思い付かないんだけど。C++の例外なんて糞ややこしい型システムを理解できるようなコードにしないと捕まえられたところでどうしようもないような。


でも、OpenCobolの人も、生成コードサイズが20%減ったと、言ってるので、そういう面では無意味ではないかもしれないしな。

まあいか。もともとの動機はGCCを弄りまくりたい、っていうのだから、別に「何ができるか」とかはどうでもいいんだ。多分。


というか、OpenCobolのGCC対応版はどこにあるのかわからん。今のOpenCOBOLはCへのトランスレータにしか見えない。と、いうか、そう書いてあるし

トラックバック - http://d.hatena.ne.jp/w_o/20041120

2004-11-19

虫姫さま、を、やってきた。

マニアックが難しいのはわかるんだけど、だからといってオリジナルが簡単なわけではないッッ。。オリジナルのStage 5の弾速は非常にアレだ。アレ。良い。

14:48

よし、適当にネタを思い付いたのでやってみるか。と、思ったんだけど、今のILogでは式のパースが面倒だ。再帰下降で二項演算子をやるのはちょっとよくない。

と、いうわけで、演算子順位をうまくやってくれるライブラリでも作るか。演算子順位法は、調べた感じでは、そんなに難しそうではなかった。まだ二項演算子しかわからんけど。


目標は

var table = [
    [[TOK_MULT,MULT_EXPR], [TOK_DIV, TRUNC_DIV_EXPR]], //
    [[TOK_PLUS,PLUS_EXPR], [TOK_MINUS,MINUS_EXPR]],    // プラスとマイナスは同じ優先順位。乗除算よりは低い
];

var parser = Parser.gen_parser( table, callback );  // callbackは終端記号に至ったら呼ばれる

parser.parse( lextable );

こんな感じで書けるように。

演算子順位法 14:48

演算子順位法なんて使わねーよなぁ…とか、馬鹿にしてた!!これは、非常に良いではないか。プログラムが単純になるし、効率良いし。左結合、右結合もちょちょいといじるだけ。

トラックバック - http://d.hatena.ne.jp/w_o/20041119

2004-11-17

いや、しかし、寒いですな。朝は、かなり、寒い、です。

衝突判定 14:48

http://www.sci-museum.kita.osaka.jp/exhibit/text/1-502.html

ボールマシーンみたいなパズルゲームでもやってみたいな。と、いうことで、ちょっと衝突判定でも真面目に勉強するか、と思ったわけだ。まあ、今日ふと思い付いただけなので、明日にはどうでもよくなってるかもしれんが。


んで、色々検索してたら、Radium Software Developmentの過去ログがひっかかったりしたんだけど、その一番上のタイトル、「ヘタれた〜」と、いうのを見て少し、何か心躍るもの、というか、単に、文体が今と比べて軽かったので、何か嬉しかったわけだ。

これの何がどう嬉しいのか説明してくれと言われても困るのだが、まあ、それは、僕もわからんので適当にうやむやにしておこう。


で、web日記の文体の話だ。最近は、日記っぽいスタイルが主流になってきてるので、文体はもはやwebサイトを特徴付ける最大の要因のひとつになっているかと思う。昔は、色々サイトデザインやら、JavaScriptギミックなんかがあったんだけど、今はサイトデザインはサブキャラ扱いだし、ギミックは邪魔物扱いだし、そういうとろで差別化するのは難しくなってきているだろう。今後webサイトというのがどういう方向に進んでいくかは知らないけど、色々と長い時間をかけて、WWW全体で「テキスト主体のほうが繰り返し見るのに適している」という結論に達っした感じはあるので、文体がどうでもよくなる、というようなことはそうそうすぐには来ないと思う。

それで、まあ、そういう前フリはいいとして、過去ログを読む楽しみのひとつは文体の変化だよなぁ…って思った。(前フリのほうが長い)


いやしかし、僕も、一度「文体を変えよう」と思って、やったはずなんだけど、その頃の過去ログ見ても境界がどの日だったかがわからんのだよなぁ…スッパリ変えたつもりだったんだけど、今見てみると、じわじわ変わっていったようにしか見えない。

サイトデザインといえば。 14:48

しかし、企業のサイトはそこらへん悪くなっていく一方だよなっていうか、ケイブさんのアレはシューター全員が「そりゃあんた間違いだよ!!」って思ったような。その話はかなり今さらなんだけど。

トラックバック - http://d.hatena.ne.jp/w_o/20041117

2004-11-15

ゼルダを終えた。本来なら、ここからハートのかけらを集めにいくべきなんだろうけど、そこらへんする気が起きないというのは困ったもんだ。

なんか、急に書くこと無くなったなぁ…プログラム的にも日記的にも。

しばらく何も書かないというのもいいかもしれない。

[] メモ。 14:48

型チェック言語はPrologみたいなのにしたらいいような気がしてきた。

Prologみたいなのってなんだよ。実際、Prologなんて殆ど知らないしなぁ…どうなんだろうか。ちょっとオーバースペックのような気がするけど。


で、あんま関係無いんだけど、左辺値というのは結構面倒だ。いや、面倒だ。なんか、その話を書くのも面倒だ。(なんじゃそりゃ)

とりあえず、ILogでインクリメント演算が行えないのは、そこらへんが面倒だからだ。どうも綺麗にいかないんだよなぁ…左辺値。評価用のilog_evalと、左辺値の場合の評価用のilog_levalとを分けて実装すれば、それなりにきれいにいくと思うんだけど、それやると、評価関数の量が二倍になるんだよなぁ…。

ILogのソースで、直したほうがいいと思われるほど汚い部分は、その左辺値まわりの実装とto_strとか、to_iなんかの変換関数が新旧入り交じってるところ。

あと、コメントが全然無いところとか。


Soopyなんかを見てると、オブジェクト=name spaceっていう考えかたは当たり前かもしれんな…とか思った。

トラックバック - http://d.hatena.ne.jp/w_o/20041115

2004-11-12

あああ、あと一週間の我慢だ…多分。一週間耐えたら次の仕事ではコード書けるかもしれない。色々勉強できるかもしれない。


しかし、あれだな。近いうちに役立つとわかっている技術を会社の金と時間で勉強できるっていうのは、すごい幸せなような気がするんだが、どうだろうか。大人は、よく子供に「社会人になってからの勉強のほうが大変だ」とかいうけど、それって、いつ役に立つかもわからないような知識を金払って教えられてる子供に言うような言葉じゃないような。

まあいいか。そういう大人にはならないようにしよう。

[] 昨日の 14:48

結局型チェックなんて考えてもどうしようもないので、当たってくだけろ、ということで、昨日のを実装してみた。字句解析も構文解析も実行もほとんどILogのものを流用できるので、すぐできた。のは、いいんだけど、これが便利かどうかを検証するにはどうしたらいいもんか。うーむ。

僕はプログラムを文字列としてだけでなく、図としても見ているのかもしれないな。 14:48

昨日のを書いてて思ったんだけど、どうも、僕はプログラムの論理的構造と、見た目の構造が一致しているのが好きなようだ。見た目、というのは、比喩表現ではなくて、単純に、ソースコードの見た目、だ。


ただ、それだけの話なんだけど、これは、なかなか面白い話かもしれない。

例えば、僕は構文解析は、yaccで書くよりも、自分で再帰下降したほうが漠然と好きだったりするんだけど、こういうのも「綺麗な木構造になってる構文木とyaccみたいな並列的な書き方との対比に気持ち悪さを感じる」もんだとしてしまえば、自分の中でうまく説明できるような気がする。


プログラムは、自身の構造を、処理の記述だけでなく、見た目でもそれを表現していてほしいのだ。「コメントはプログラムの処理を記述するべきではない、プログラムが処理を説明しているようにしなければならない」と、いうことばに、僕は、さらに、「プログラムの構造は別の図で表現すべきではない。ソースコードの見た目が、それ自身の構造を表していなければならない」と、いうことばを付け加えたいわけだ。んんん。うまく説明できないな。

(わかるかなぁ…こんな文章で。例えば、美しい木構造になっている継承関係をプログラム内のクラスに変換してしまって、それで、プログラムの見た目で継承関係を表せないから、プログラムのオマケとして、クラス図を付け加えるとかっていうのが、まさに、その悪い例で、こういう話、「オブジェクト指向」とか、「オブジェクト設計」とかっていう言葉に嫌悪感を感じる人だったらわかってくれると思うんだけど…)



そんなわけで、ただひたすらパターンマッチを行うっていう並列処理である型チェックとそれの見た目をあわせたいから、昨日みたいな話になったんだろう、と、自分の中で納得したわけだ。

真・ビジュアルプログラミング 14:48

でも、こういう話はあたりまえかもしれないな。でも、当たり前のわりに、議論として表に出てくることは少ないような。言語で行いたいことの処理の構造と、プログラムの見た目の構造を一致させる、というような観点で言語を設計するっていうのはどうだろうか。

極端な例を出すと、簡単な2次元画像フィルタのプログラムなんかだ。ラプラシアンフィルタなんかを

3x3   // 対象を中心とする3x3の正方形とする


[ 1 ][ 1  ][ 1 ]
[ 1 ][ -8 ][ 1 ]
[ 1 ][ 1  ][ 1 ]

こういう構造で書けたらなによりもわかりやすいだろう。そんな感じ。


そう、だから、流れとしては、こうだ。

基本は、既存の言語で書けばいいと思う。既存の言語は色々研究されてるだけあって、日常生活では困らないはずだ。だが、処理によっては、恐しく(構造の)並列性が高かったり、やたら綺麗な木構造をしていたり、それとか、もっと珍妙な構造をしているかもしれない。そういった場合に、そういう構造をソースコード自身が図として表現できるような言語を設計するのだ。

それは、最初は工数がかかるかもしれないけど、長い目で見てそれらを回収できるだけの高い可読性が得られるような気がしないだろうか。他人に教えないといけないような状況になったときに、へんてこりんなライブラリの使いかたを教えるのと、どちらのほうが楽だろうか。


そう考えると、やっぱり、用途限定言語は便利だという話になって、そうなると、処理系の実装の手間を省くILogの存在も意味が出てくると、いうわけなのですよ。

と、いう話にもっていきたかったのか 14:48

いや、宣伝するのは重要だと思ってるのですよ。

Rubyの一番悪いところは、Ruby使いはみんな「まあ、Perl使いはPerl使い。Python使いはPython使いだしねぇ」っていうような態度をとっているところなんだ、とか、。もっと、こう、「Pythonは〜が糞だよ。あんなの使ってるのはダメだヨー」とか表に出してこないと。


PythonRubyの両方を見てみればわかるんだけど、PythonRubyは根本の思想はあんまり似ていない。

トラックバック - http://d.hatena.ne.jp/w_o/20041112

2004-11-11

[] 型チェックってどうすればいいかっていうメモ 14:48

と、したいところなんだけど、ちゃんとした型システムって作ったこと無いからどういうのが必要なのかわからんのだよなぁ…


とにかく、型チェックっていうのは組み合わせだ。いっこいっこのパターンは量が多くないんだけど、型の数に応じてパターンの数が組み合わせっぽく増えていくわけだ。

intとfloatがあったら、int+int=int、float+float=float、int+float=floatのみっつ。

これにポインタが混じると、int+pointer=pointer、pointer+pointer=error、int+int=int、float+pointer=error、float+float=float、float+int=floatの6個。

これにdoubleが混じると?charが混じると?構造体が混じると?構造体がオペレータのオーバライドすると?型に修飾子が付くと?継承?テンプレート?


とにかく、そういう、パターン数の爆発に対処できる何かがいるわけだ。けど、ライブラリとか、構文とかでいくら対処をしたとしても組み合わせには対処しないといけないわけで、結局どうやってもパターン数は減らないわけだ。

んんん。どうすればいいかなぁ…とりあえず考えたのが、いっこいっこのパターンを極限まで簡単に、一目瞭然でわかるようなフォーマットを作る、という感じか。

int float: // 左辺がint型、右辺がfloat型の場合、次の関数を実行
	function( expr, lhs, rhs ) { 
		expr.type = float;        // これ全体の式の型はfloat。
		lhs = convert_float(lhs); // 左辺値はfloatに変換
	} 

int int:
	function( expr, lhs, rhs ) { expr.type = int }

pointer float: // pointer は型名ではなくて、えーと、そこらへんはうまくやるようにできる予定。
	function( expr, lhs, rhs ) { error("error hoge hoge"); expr.type = error_type; }

こういう別ファイルを用意しておけば、あとはそれを読み込んで、うまくやってくれるようなライブラリがある、と、そういうのを考えてみたんだけど。



んで、もういっこ、重要なのが、型の伝播っぽいものを簡単に書く方法だ。関数型言語みたいに型推論するんだったら当然いるだろうし、Cでも、doubleとかfloatなんかの変換を考えれば、そういうのが自然に書けるようになっていると嬉しい気がする。

けど、そういうのって具体的にどうやったらいいか全然イメージがわいてこないんだよなぁ…どうすればいいのかなぁ。

やっぱ一回は関数型言語みたいな静的型の処理系も書いておくべきだったか。いや、それはちょっと気楽にはできないなぁ…


まあ、そんな感じ。とにかく、コンパイラでは、型チェックは馬鹿にしてはいけない。C言語のような簡単な型システムでも、どうやって実装するか考えると、それだけで結構な量になることがわかるかと。

実際、GCCのCフロントエンドでも一番行数が多いのがc-typeck.cというファイルだったりするのだ。

4.0が偉い。 14:48

昨日のを書いてて思ったんだけど、ひょっとしてGCCは配列まわりの解析が甘いんじゃないかなぁ…とか。

あー、でも、4.0ではなんとかなってた。んん、まあいいのかもしれない。

トラックバック - http://d.hatena.ne.jp/w_o/20041111

2004-11-10

っぐ。サンプルが200行超えてしまった。

「200行でポータブルな最適化コンパイラが書ける!!」

とかだったらインパクトあると思ったんだけど。300行ではちょっとなぁ…

無理すれば200行に収まりそうな気もするんだけど、複雑そうに見えるのも困るしなぁ。

動いたー 15:38

14:48

orz

これのコンパイラが

http://morihyphen.hp.infoseek.co.jp/prog/orz.txt

これ。

で、サンプルの「orzを出力」っていうのをコンパイルしたのが

http://morihyphen.hp.infoseek.co.jp/prog/orz.s.txt

これ。


あとはspecとかを書けばいいかなー。

今のソース ILogのソースを含めても9984行か…惜しい…


(訂正: ファイル名修正)

[] 0.0.1 リリース 14:48

軽く休憩しようかなーとか思って、ふらりと外へ出たらその足でゼルダ買ってて7時だったのが気が付いたら10時になってた。しかし、アレだな。リンクはカワイイ系のキャラとして攻めてくるつもりなのだろうか。

ILog 0.0.1

と、まあ、それはいいとして、specsをtreelangからコピーしてきたり、ビルド通るようにMakefile見直したりして、そういう見栄えを良くしたので、これを0.0.1にしようかと。

specs書いたので、

gcc hogehoge.ilog

とかでも動くはず。けど、入力ファイル名渡せないからあんまり意味無いんだよなぁ…


さっきのバージョンとの違いはspecsとMakefileだけなので、そこらへん気にしないならば、上のものと変わらなはず。


3.4.1で動作確認してます。3.3とか4.0では多分コンパイルも通らないかと。3.4.2でも動作しているとのこと。じゃあ、3.4.3も大丈夫なのかもしれない。

配布はGCCのそれ(と、いうか、GPLなんだけど)に従ってください。好きなようにしていいけど無保証です。

バージョン番号 14:48

は結局0.0.1にすることに。

Knuth先生はTeX作ったことよりも、Art of 〜書いたことよりも、あのバージョン番号を考えたのが偉い、とか適当なことを思ってる人間なんで、なんか、そういう遊びをしてみたいなぁ。と思ったんだけど、6.626はやっぱちょっと微妙だなぁ…って感じで。あー、DBL_EPSILON→FLT_EPSILON→0.0.1とかにすればよかったのか。いや、それも微妙だな…



TODO: 次は型情報あたりか。あと、それなりに文書系の資料も作っとかないと使いものにならないような。

shinichiro_hshinichiro_h 2004/11/10 19:08 とりあえず URL が違ってるみたいです。カンで ilog- を付けてみたところ落とせたのですけど、たぶん bz2 じゃなくて gz っぽいです。それと6.626E-34をぐぐってみるまでわからなかった私は学科を間違えてる気がしました。では、わくわくしながら試させてもらいますです。

w_ow_o 2004/11/11 00:05 あぁぁ。かなり適当な間違いしてますね…反省して出直してきます。

shinichiro_hshinichiro_h 2004/11/12 15:09 動かしてみましたがすばらしいです。なんか簡単な言語考えて試してみたいところではありますが…ところで gcc-3.4.3 でも大丈夫でした。

w_ow_o 2004/11/13 02:35 おっと、動作確認どうもありがとうございます。

どのへんから実装していったらいいものか結構迷ってたりするので、簡単な言語考えた際には、「〜を先に実装したらいいんじゃないか」なんかを教えていただけるとありがたいです。

トラックバック - http://d.hatena.ne.jp/w_o/20041110

2004-11-09

ここまで関数の渡す順番と引き数の受け取る順番が逆になっていることに気付かなかった僕は相当のアホなんじゃないかと思った。


あと、文章でアホって書くと、なんか気持ち悪いなぁ。



なんか潰さないといけないのがどんどん出てくるな…厳しい。

とりあえず、今日はFirefox見れたのでよしとしよう。(なんじゃそりゃ)

ff 2004/11/10 03:01 前にも同じようなことありませんでしたっけ?<関数の渡す順番と引き数。

w_ow_o 2004/11/10 11:51 前も、というか、コンパイラとかインタプリタとか書く度に間違えてるような記憶がありますが。

w_ow_o 2004/11/13 12:49 もういっこ引数の順番を間違えてるバグがあった。そればっかりだなぁ

トラックバック - http://d.hatena.ne.jp/w_o/20041109

2004-11-08

[] 14:48

よし、あれもできたし、これもできたし、いい感じに進んでますよ。

明日早起きできれば、明日の朝リリースもできるかもしれない。ただ、早起きできるかはわからないのと、まだ潰せていない課題がこれからどうなるかわからないので、微妙なところ。

とりあえず、あさっては休みということになってるのであさってにはできるだろう。多分。

ここまできたら、いっそ誕生日まで待つかとも思うんだけど、さすがにそれはアレすぎると思うのでパス。

あと、6.626E-34はわかりにくいのでやめておこうと思った。

トラックバック - http://d.hatena.ne.jp/w_o/20041108

2004-11-07

match文の

match ( expr ← これ ) {
	case 1:
		hogehoge;

	case 2:
		hogehoge;
}

の名前をなんにしたらいいかわからなくて悩む。

CONDとかでいいのかなぁ…

14:48

んん。デバッグ無しで一発で動いてしまうと逆に不安になる…

トラックバック - http://d.hatena.ne.jp/w_o/20041107

2004-11-06

今日も早く起きれた。4:35。

けど早起きしても眠いからって15:30から18:00まで寝てたら意味ないような。もはや今日までか。二日坊主。

GIMPLE 14:48

で、ちょっと息抜きにtree-ssaについて調べてみた。息抜きのつもりが、読んでたら寝てしまったわけだが。


まあ、そんな話はいいか。とにかく、最適化のことはよくわからんのだけど、フロントエンドのAPIが変わっちゃうんじゃないかなー。とそういう感じで調べてたわけだ。

で、結論としては、やっぱ、若干変わってるなぁ…と。けど、思っていたほど変わっているわけではない。多分。


http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA

これまでは、インライン展開なんかの高レベルな最適化っていうのが、tree_rest_of_compilationからのフック呼びまくりで行われてたんだけど、そいつはどうかと思うので、RTLに変換する前にRTLよりももうちょい抽象的な3番地文で構成されたGIMPLEっていうので、そこらへんの最適化をやっちゃおうか。っていうような話らしい。多分。(ただ、僕の英語力はまるであてにならないので、あんまり信用しないほうがいいかと。)

と、いうことは、tree-ssaと名乗ってはいるけど、SSAになるだけじゃなくて、もうちょい色々効果があるんじゃないだろうか、などと思ってみる。

で、フロントエンドから見たインターフェースなんだけど、これからは、RTL変換だけじゃなくて、3番地文への変換が必要になってくるので、フロントエンドが背負う仕事量が増えるんじゃないかと思うんだけど、Cフロントエンドのコード量は結構な量減ってんだよなぁ…これは、フロントエンドレベルでの最適化のうちのいくつかがGIMPLE最適化のフェーズに押し込まれた結果だと見ていいんだろうか。そんな感じはしないんだけどなぁ…謎。

[] 字句解析 14:48

よし、大体できた。と。

var line = 0;

var table = [

		// 基本は ["パターン" : 値] のペア
		// マッチしたら next_token関数は
		// [値:マッチデータ] というペアを返してくる。
		["[a-zA-Z_][0-9a-zA-Z_]+":2],
		["=":4],
		["\\[":5],
		["\\]":6],
		["\"[^\"]*\"":7],
		["[0-9]+":8],
		["[;:]":9],
		[",":10],


		// null を指定すると無視してマッチングを続ける
		["[ \t]+":null],

		// 値に関数を指定するとマッチしたときに呼ばれるようになる
		// 値を返せば、それがnext_tokenの戻り値になる。
		// nullを返せば、無視してマッチングを続ける
		["\n": function(){ line = line+1; return null; } ]
];


var lexer = Lex.generate_lexer( table );
var f = file.open_rstream("file.ilog");

for ( var i=0; i<20; i=i+1 ) {
	print( (lexer.next_token(f)).chain[0] );
	print( "\n" );
}

print( "\n\nline = " );
print( line );
print("\n");

で、これで自分自身を字句解析した結果が、

var
line
=
0
;
var
table
=
[
[
"[a-zA-Z_][0-9a-zA-Z_]+"
:
2
]
,
[
"[ \t]+"
:
null
]


line = 4

こうなる。

このくらいやっておけば、定型処理は殆ど必要なくなるはず。


次はmatch文の類いだな。これができれば、字句解析〜構文解析〜機械語生成 までの一連の流れが実装できるようになるはずだ。それができたら、バージョン6.626E-34をリリースでいいか。

ここまでのソース


訂正: コンマの位置間違えてた。

トラックバック - http://d.hatena.ne.jp/w_o/20041106

2004-11-05

睡眠時間狂ったついでに早起きしてみる。今日は4時には起きてた。

メタ文字 14:48

んあ、そうか。昨日のはメタ文字作っちゃえばいいんだよな。'\i'で識別子っぽい文字列とマッチ。'\I'でマルチ文字と識別子っぽい文字とマッチって感じで。

そうすれば、いかにもコンパイラ用途っぽい…はず。あと、""でくくった文字列は'\s'でマッチとか。バックスラッシュエスケープも勝手に考慮してくれるとか。

[] コンパイラ用途 14:48

ILogが、コンパイラとして使いやすいかどうかは、死活問題なのだ。それは、Perlが文字列処理に便利だとか、そういう便利/便利じゃない程度の話ではなくて、そう、ILog自身のアイデンティティに関わる問題なのだ、とか、そういう話。


まず、用途を限定した、小さな言語の話(DSLとかいうらしい)だ。

それなりにプログラムを書いたことのある人ならば、状況によっては、ライブラリを用意したり、開発環境を整えたりするよりも、用途にあった言語を使用するほうが、何十倍も効果があることを実感したことがあると思う。

で、それとは別に、一般人がコンピュータに触れる機会が多くなった現在、これからは一般人がプログラムを書くような場面も増えてくるかもしれない、ということを考えると、必要なことだけを最低限やれて、かつ、誰でも利用できる簡単な言語っていうのは需要が増えてくるんじゃないだろうか。

つまり、DSLは今までも十分に重要な立場にあったし、これからもそれは変わらないだろう、と、僕は思うのである。


それで、だ。DSLは今のところほとんどがインタプリタであると思う。その原因は、極めて単純な話、「機械語コンパイラを書く」、というのは、敷居が高すぎるからだ(特に、移植性を考えた場合、個人でなんとかなる問題ではなくなってくる)。けど、インタプリタ、となると、やっぱり、ちょっとした問題でも富豪的解決になってしまうことは否めない。

まあ、富豪的に解決するのは別に良いんだけど、他に選択肢が無いからそうするしかないっていうのは、やっぱりおもしろくない。やっぱり機械リソースを最低限に抑えられるDSLっていうのがあってもいいんじゃないか、と思う。

で、要するに、話としては、「DSLが必要→今後は機械語に変換できるDSLっていうのもありじゃないか→じゃあ、機械語を簡単に出せたらいいじゃないか」っていうような流れだ。それで、そうなったとしたら、機械語を出すコンパイラが簡単に書けるILogの必要性っていうのが生まれてくるだろうと思う。


しかし、この話は、DSLが重要になってくる、という話が前提になっているので、ここで、「DSLが便利であったとしても、言語を用意したり勉強したりする手間を考えれば、過去のリソースが大量に残っている既存の言語を使った方が総合的にみて良い」と、いうような話になってしまえばILogの存在意義っていうのは生まれてこなくなってしまうわけだ。

つまり、ILogが必要である、とするには、用途限定言語が重要である、ということを示せなくてはいけない、と、いうことである。



そして、ILogというのは、コンパイラという用途に限定した言語、ということになっている。もし、ここで「他のリソースを捨ててでも、コンパイラを書くにはILogが良い」っていうような話にすることができれば、それは「便利である」以上に重要な意味を持つことになると思う。逆に、「やっぱり、それでも既存のモノで書いたほうがいいよねぇ」っていうような話になれば、それは結局、「じゃあ、最初からいらないんじゃネーノ」っていうような話になってしまうのである。

14:48

いや、しかし、文体がカタい。こういう内容のを軽い文体で書けるようになったら僕としては十分なんだけど。

アレだ。アレ。文体がカタくなってしまうと、読者に「この人ひょっとして真面目に、真剣にやってんじゃないかな…」っていうような不信感、不安感を与えてしまいがちである。

トラックバック - http://d.hatena.ne.jp/w_o/20041105

2004-11-03

/memo/ 14:48

Pythonのregexprの移植を大体終了…と。あと、ささやかにマルチバイト対応。

re.match("あ+b","ああb");  // マッチする

これだけなんだけど。正規表現のマルチバイト対応のしかたはわかるんだけど、どういう表記にしたら使いやすいかがわからないんだよねぇ。

ぱっと思い付くのが、

[あ-ん]

こういうのなんだけど、これだと、ひらがなはいいとして、漢字にしたときも文字コード順を覚えとかないといけなくなるような。で、

[:printm:]   // 印字できる文字(マルチバイト含む)とマッチ

これだと、各種演算子とか、記号とかも混ざっちゃうので、厳しい。かといって、:kanji:とか作っちゃうのも問題だしなぁ…

やりたいことは、識別子文字([_a-zA-Z0-9])と漢字を混ぜれるようにしたいっていうだけなんだけど。ああ、そうか、どうせ、それにしか使わないんだから、そういう文字クラス作っちゃえばいいのか。[:multiident:]みたいな。


まあ細かいのはいいか。とりあえず、実装方法は見えた。いや、簡単じゃない。今調べたらPython正規表現は多分[:hogehoge:]をサポートしてない…むむむ…


TODO: 読み込みストリームと字句解析と正規表現の完成。

睡眠リズム 04:50

9時頃寝て、12時過ぎぐらいに起きて作業を始めると、1時〜3,4時くらいまで、作業効率をかなり高く保つことができるようだ。ただし、やりすぎると次の日の業務に影響が出る。あと、腹減った。

トラックバック - http://d.hatena.ne.jp/w_o/20041103

2004-11-02

睡眠リズムが崩れまくりだ。

明日は休出。と。

正規表現が熱い 14:48

前回は、SpiderMonkeyの正規表現実装が直観的でいいんじゃないか、という話だったんだけど、どうも、こいつがあんまり効率が良くなさそうに見える。まあ、別に効率なんてどうでもいいといえばいいんだけど、やっぱり、気持ち悪いので、他に方法が無いかとPython正規表現の実装を調べてみた。

と、これが、結構面白い。正規表現をバイトコードに変換して、ちょっとしたVMでパターンマッチを行うというふうになっているのだ。(ひょっとしたら常識かもしれんが)

(あとで見たらgnuのregexもそんな感じの実装になってたんだけど、Pythonのほうが読みやすかったので、先に理解できた。)


Pythonのソースでいうと、Modulesディレクトリ下のregexpr.cがそれ。バイトコードのオペコードは、regexp_compiled_opsにあるんだけど、(多分)重要そうなのが、

  • Cexact
  • Cjump
  • Cstar_jump
  • Cfailure_jump

といったところだろうか。

たとえば、"((aa)|(bb))c"をコンパイルすると、

0:	failure_jump	4
1:	exact		'a'
2:	exact		'a'
3:	jump		6
4:	exact		'b'
5:	exact		'b'
6:	exact		'c'
7:	exact		'c'

と、いったような感じ。

簡単に説明すると、

exact
一文字とマッチ。マッチしなかったらfailureスタックからアドレスを拾ってきてそこへジャンプして文字列位置を戻す。
jump
アドレスへジャンプ
star_jump
最適化しなかったらjumpと一緒(と、コメントに書いてあった)
failure_jump
failureスタックにアドレスと文字列位置をプッシュ

って感じ。


なるほどなぁ…うまくできてるなあ…って、思った。

(…んんん?これだとexact 'c'で失敗したときに3に戻ってしまうような。もうちょい調べないとな…)


で、'?'とか'*'が文字列の後ろにくるという正規表現の都合上、コンパイル時はひたすら後埋めになってるっていうのが、これまたちょっと面白かったんだけど、そこらへんのおもしろさはちょっと文章ではあらわせないのでパス。

トラックバック - http://d.hatena.ne.jp/w_o/20041102

2004-11-01

いまだにソーシャルネットワーキングとやらがなんなのかわかりません。

[] 圧縮はゲームには使えん!! 14:48

http://d.hatena.ne.jp/w_o/20041016#p1

圧縮ってゲームにならんかとか言ってたので、対戦(予定だった)圧縮シューティングを作ってみた。


これがこれが、大失敗。全然使えねぇ。

作る前から、「シューティングという単純なシステムに比べて"圧縮"っつーのは複雑すぎる」っていうのは予想されてた。

けど、そのへんは「まあ、プログラムコードだったらキーワードとかで似たようなパターンが頻出するはずだから、大丈夫なんじゃないかなぁ…」と、思ってたんだけど、全然駄目だった。「int」とかをちまちま拾って圧縮率がプラスになるようにするので精一杯。

と、いうわけで、僕の力では、圧縮は、ゲーム、少なくともシューティングとは混ぜられない。という結論でした。


一応敵機がいてます。うまくいったら動かして対戦する予定だったんだけど、放棄。アルゴリズムどうしたらいいかとか、ちょっと面白いかと思ったんだけど、それもまたかなり難しいよなぁ…。

まあ、敵機は適当に撃ってゲームでたまったストレス解消に使ってください、ということで。


ハフマン実装の勉強になったので、良かったっていうことにしておこう。


processingというか、BAppletとフォント使ってるだけのような気もするんだけど。あと、MSのVMでは動きません。

トラックバック - http://d.hatena.ne.jp/w_o/20041101
 |