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

 | 

2005-03-21

[]

なんか真アキいってる人がいた(一回コンテニューしてたけど)ので見てた。

弾数がどうかしてるなー。あと、ボム運んでいく虫が良い。

けど、なんかごちゃっとしてて汚い?ような。そう考えると、美しさと恐怖を兼ね備えた洗濯機はすごいよなぁ。どっちも実際にやったことはないけど。

[]

まあ、そんなこんなで、最近つまらないこと書きすぎなので、少し自粛します。

なんか面白いことがあったら再開するかと。でも、面白いことなくても再開するかも。そこらへんは、まあ、適当に。

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

2005-03-20

引越し終わったー。家のまわり何もねぇー。いや、ほんと、一歩出れば山。

[]

昨日の続き。

オープンソースに憧れる若人は実際に需要があるということだそうで。

あー、そうなのか…それは意外。僕の中では、「そんな楽しそうなおいしい話限られた場所にしか無い」ぐらいの気持ちで昨日の話は書いたんだけど、これは考えを改めないといけないかもしれない。


で、まあ、考えを改めるかどうかはいいとして、昨日のPiroさんのコメントで、露出の問題について触れられていたのを見て、僕のような一般人がオープンソースに寄り気味な会社について知らない、というのも問題のひとつなんじゃないかなー。と、思った、という話。

オープンソースの世界では、「よくできたプロダクトは放っといても成長する」とか、「優秀な開発者は勝手に目立ってくる」とか、そういった雰囲気があって、まあ、そういうのはオープンな世界っぽくて非常に良いと思うんだけど、それだと、並の能力のプロダクトを伸ばしたり、並の開発者(といってもオープンソースの世界だからそれなりにレベル高いと思うが)を集めることがなかなかできないんじゃないか。とか。


あー、なんか、非常に適当なこと書いてるな…いや、でも、おととし就職活動したときに、一応そういう方向で働けないか、と考えてみたけど、どっから情報を得たらいいかわからなくて、結局諦めた身としては、やっぱり、並の人間の熱意でも色々と、そういう情報を探せるところが欲しいな。と、思うわけですよ。簡単に諦めた僕が悪いと言えば悪いんですが。もし、本当に、オープンソースの世界で働きたい人を受け入れる会社がたくさんある、というのであれば、それは、人間が足りないんじゃなくて、お互いの情報交換がうまくいってないだけではないのかな。と。

もういいや、適当ついでに、ものすごく適当のこと書くけど、あれだ。あれ。オープンソースに寄り気味な会社の人事担当は、Blogとかで募集したらいいんだ。オープンソースの類いはNDA発生しないのをいいことに、本日の作業とか晒しまくり。「今日は〜モジュールの書き換え!しかし、人員が足りない。○○について詳しい人求む。興味ある人はTrackBackもしくはコメント、メール等で」。とか、そんな感じで。いや、そんなのでいいかは知らんけど。

いや、よくわからんな。そこらへんの話は僕個人ではどうしようもないので、触れないほうがいいかもしれない。

あと、コード書きもしないのにこんなふうにグダグダ言うようになったら色々終わりだな…気を付けよう。

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

2005-03-19

準備大体終わり。片付けた影響で昔のベイグラントのセーブデータをやっと発見。遅いよ。

[]

どーでもいいけど、

http://enbug.tdiary.net/20050311.html#p02

http://www.rubyist.net/~matz/20050316.html#p01

http://japan.linux.com/~sado/diary/20050312.html#p01

これだけを見てると、「オープンソース開発に憧れる若人」は需要があるように見えなくもない。しかし、それはサンプルが偏り過ぎているという説が。

[] 打倒 Io Language

Ioが「reasonably fast (comparable to Python, Perl, Ruby)」と言ってる秘密を探るために、ぼちぼちソースを読んでみるが、よくわからない。名前検索で、なんか不思議なことやってたので、そこらへんに秘密があるかと思ったが、それは、parentとprotoのチェインの実装がややこしかっただけで効率とは全然関係無かった。

全体的に見ても、やってることは普通に見える。

完全ハッシュ使ってる、というのは、どのくらい効果があるかは知らんが、そのぐらいの違いだったら、ローカル変数で名前検索を行わない、とか、外側の名前を参照しない関数ではクロージャを作らない、とか、そういう部分で対応すれば、十分に勝てるような気がする。


と、いうわけで、パフォーマンスの目標をとりあえず、「Ioに勝てるくらいまで」、にしとこうかと。やっぱり、基準があったほうがやりやすいし。


で、謎だった構文木を普通の構文木に変更。これで実験で作るインタプリタくらいの速度は出るんではないかと。

フィボナッチ数で、

function fib(n)
{
	if ( n>2 ) {
		return fib(n-1) + fib(n-2);
	}

	return n;
}

for ( var i=0; i<22; i=i+1 ) {
	puts( fib(i) );
}

これで1.8secぐらい。Ioだと、

fib := method ( n,
	if ( n > 2, return fib(n-1) + fib(n-2) )
	return n
)

for ( i, 0, 22,
	fib(i) print
)

これで…1.9sec…?ん、なんか間違ってるんじゃないか…?

でも、まあ、Ioは数値演算全部doubleでやってるので、そこらへんの影響かもしれない(ちなみにILogScriptは64bit整数)。もっと名前検索のほうに偏ったベンチマークのほうがいいかも。


あー、あと、ILogScriptの浮動小数点はどうするか迷う。ILogScriptの立場上、適当にはできないしなぁ…。

[] GGCは相変わらずややこしい

んんん。GGCはスタック上のオブジェクトをマークできないという問題が今頃露呈。上のプログラムで、ループ回数が22になってるのは、GC動く/動かないの境界がそこらへんだったから、とか。

GCのあたりは問題が出たら困るのでなるべく危なそうなテストは避けるようにしてきたんだけど、ついに発見してしまう。いや、うん、どうしようか。

GCのプロテクト用オブジェクトをいちいちヒープから拾ってきてたら勿体無くてしかたがないのでスタックにのせてたんだけど。

仕方ないので、専用のアロケータ書くか…



あああーあ。色々。色々。もう普通に保守GC使ってくれりゃいいのになぁ…でも、多分、ここは僕の使い方のほうが間違ってんだけど。

いや、嘘だ。嘘。このぐらいいくらでも対応できる。この程度の逆境に負けててはいけない…って、もう何言ってんだかわかんないな。


ここから下は本当にメモ。

上のフィボナッチ数でSpiderMonkey、RubyPythonは0.1秒かからずに終わってるので、どこらへんが違うか見てたら、多分、整数の扱いが違うとかのような気がして、整数値はオブジェクトじゃなくて、生でそのままレジスタに乗っかる値になってて、でも、GGCはそこらへん無茶できないような気がして、どうしようかと思ったんだけど、

struct ilog_slot GTY(())
{
  struct tree_common common;

  tree key;
  union slot_value {
    long GTY((tag ("1"))) fixlong_value;
    tree GTY((tag ("0"))) tree_value;
  } GTY((desc ("((long)&%1) & 1"))) value;


  location_t *last_define;
};

こんな感じにすればいい、と、いうのがわかって、それもまた別にいいんだけど、さすがに、いちいちこれを全部に埋めるのは辛いのと、あと、これやると、整数と、GCC内の整数が違うので

build(PLUS_EXPR,int,3,4)

これができなくなって、どうしようか、と考えるも、別に整数演算なんかそんなに出てくるわけでもないだろうし、もう今のままでいいと思った。

要するに面倒だから今のままにしとく、という結論。整数がボトルネックになるようだったら考えなおそう。


まあいいか。Rubyは整数も本物のオブジェクトにしてると思ってたんだけど、そこらへん適当にごまかしてたんだなぁ…と、いうのがわかったので、収穫ゼロってこともないだろう。そんなの知ってて何の役に立つかは知らんが。

PiroPiro 2005/03/20 16:24 需要なんて作り出すものです。露出を増やすのはその一つの方法で。
「ゲームクリエイター」に憧れる人が増えたことの背景には、ドラクエやダビスタ、FFなどの開発者の成功者っぷり(当時の)がメディアに取り上げられたことが大きいのではないでしょうか。

元々の「何故オープンソース開発に参加しないのか?」と疑問を投げかけられている方は、そのあたりの「そもそもの問題」に気が付いておられないか、敢えて無視されているような気がします。

w_ow_o 2005/03/21 03:39 あー、そうですねぇ。
幼稚園児やら、小学生やらにもその存在が知られるくらいになれば、その何年かあとにはもっと人が潤うようになるかもしれないですな。

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

2005-03-17

[] 没

前からパーサ書き直すとか言ってて、最近やっと作業を始めたんだけど、

  tree a_list_rests = seqp(build_list(1, optp(seqp(build_list(2,comma,call_toplev_expr),
						   ret2,ilog_null),ilog_null)),
			   ilog_null,ilog_null);
  
  list_expr = seqp( build_list(4,l_bracket,call_toplev_expr,a_list_rests,r_bracket),
		    build_ilog_native_function((ilog_native_func_t)list_expr_action,4,"list_expr_action"),
		    ilog_null );

  cons_expr = seqp( build_list(5,l_bracket,call_toplev_expr,colon,call_toplev_expr,r_bracket),
		    build_ilog_native_function( (ilog_native_func_t)cons_action, 5, "cons_action" ),
		    ilog_null );

  paren_expr = seqp( build_list(3,l_paren,call_toplev_expr,r_paren), ret2, ilog_null );
  term = selp( build_list(5,
			  digit,str_const,paren_expr,cons_expr,list_expr), ilog_null,
	       build_ilog_native_function( (ilog_native_func_t)term_error, 1, "term_error" ) );

なんかこんなコードになってしまって、ちょっと色々厳しいような気がしてきたのでやっぱり、このネタはお墓行きに決定。これだけ書くのに昨日、今日の二日分のエネルギー使ってます。

lang.lexerとか、lang.parserとかがあるんだけど、それは名前だけで、どこにも使われてないという微妙な状態に。


問題があるのは構文木の構造のほうなので、別にパーサを書き換える必要はなかったんだが。何を目的として実行しようとしてたんだろうか。忘れたな。まあいいか。


んで、構文木書き換えたら、バイトコード出してみたいんだけど、バイトコードに変換して得られる効率ってどのくらいになるんだろうか。と、いうのが最近の疑問。実はそんなに変わらないんじゃないか、って気がしてきた。なんも工夫しないで、単純に計算する木をスタックマシンの計算に置き換えるだけだったら、命令のキャッシュ当たりが良くなるのと、ポインタ巡るのが減るとか、そのぐらいのような。まあ、キャッシュ当たりの違いはかなり大きいかもしれんが。

面倒になってきたから、ちょっとした細工で画期的に速くなるとかじゃないんならやめとこうかなぁ…と。


そういえば、IoのVMもバイトコードとかの類いじゃないんだよなぁ。もし、本当にあれで速度が出るというのならば、VMの実行方法じゃなくて、ハッシュテーブルの構造やら、オブジェクトの構造やら、プロトタイプチェインの巡り方とかをなんとかしたほうがいいのかもしれない。というか、それ以前にプロファイルとってから始めるべきかもしれない。

それ以前に、実は今の速度でも問題無いのかもしれない。


どうしようか。

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

2005-03-16

最近、ここで、何書こうとしてたか忘れる。どうせ、大したことではないと思うんだけど。


あ、思い出した。珍しい。

引越し先の家にテレビが無いようで、どうしようか、という話だ。テレビが無いと、NHKの人が来たときに堂々と断れるからいいんだけど、ゲームできなくなる、とか、そういう感じで、やっぱり大したことなかった。

テレビ見ないから、別にいいんだが。あ、でも4/14「恋に落ちたら」が見れないな。でも、それだけのために用意する、というのもどうだろう。いや、でも、やっぱり縦置きできるテレビが欲しい。家電屋はもっと世間における縦置きテレビの需要を考えるべきである。


ほんとどうでもいいな。

[]

久し振りに家でコード書いたら、全然駄目になってて死ぬ。やっぱ会社のコードばっか読んだり書いたりしてたらなまる一方だなー。色々。

けど、だからと言って、家でばっかりコード書いてるとトリッキーなコードに走る癖が付くのでよくない。と、いうか、そう言われました。実際そうかもしれない。

[] オープンソース開発プロジェクトのストーリー化

http://piro.sakura.ne.jp/latest/2005/03.html#d16の下のほう。


討論するシーンも、閃くシーンも、凹むシーンも、作業するシーンも、ひたすらキーボード叩いてるだけ!!なんとなくリリースでなんとなくエンディング!!とか、そういったイメージが。「それが僕には楽しかったから」も実際そんな感じだしなぁ…

いや、でもプロジェクトXのTRONの話なんかはキーボードのシーンなんか無かったな。演出次第ではあんな風にできるだろうか。FirefoxなんかはNetscapeとか絡めるとできそうだけど。


むしろ、ここはオープンソース開発プロジェクトをゲーム化したらどうだろうか。

コードを書くためにいかに普段の生活から、無理矢理時間を捻り出すか。どうやって会社でバレないように作業するか。どうやって宣伝するか。だれもが嫌がるドキュメントをどうするのか。高い英語の壁。そういった数々の障害を乗り超えて、ゆっくりと育っていくプロダクト。と、いう感じにオープンソース開発の醍醐味を味わうゲーム。に見せかけといて、実は、「何の前触れもなくいきなり、"なんかどうでもよくなった"感じになってゲームオーバー、対処法無し。」というシステム登載の超高難易度ゲーム。

開発者曰く、「オープンソース開発固有の"あの感じ"を出したかった」。とか。


いや、まあ、だからなんだ。

あー、そういえば、組み込みTCLは既にあるようで。

http://tinytcl.sourceforge.net/

PiroPiro 2005/03/17 04:33 反応どもです。
ゲーム化するなら、ロマサガ2ベースが良いかも知れません(ぉ

w_ow_o 2005/03/18 02:02 なんか微妙なネタなのにわざわざすいません…

> ロマサガ2
あー、そうか、なるほど。やる気が無くなったらメンテナの引き継ぎ。っていうシステムがある感じですかね。
しかし、それはそれでまた高難易度な気がしますが。

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

2005-03-14

ゲームしかしてねー。何も書くことない。

どうでもいいが、引越し一週間前にして蛍光灯の寿命が来るとかいう面倒なことに。取り換えとか買ってくるのとかはすぐだったんだけど、蛍光灯は捨てたり保管したりするのがめんどい。

[]

ベイグラントをちょびちょび。なんか楽しくなってきた。

しかし、合成の方向性とか、武器育成の方向性とか、もっとヒントあってもいいような…

属性と攻撃タイプが重要なのであって、攻撃力と種族パラメータはおまけみたいなもんだ、と、いうのがやっと理解できた。それが理解できれば雑魚とも対等に戦えるんだけど、普通にやってるとそこらへん気付かないで、攻撃力を重視してしまうために、雑魚と毎回全力の力押しで戦うハメに。レイジングエイク、ファントムゲインのチェイン10くらい当たり前でしょ?みたいな感じ。


あと、3Dゲームなのにドット絵職人の魂とか。言われれば気付くんだけど、当時の僕は気付かなかったようだ。


まあいいか。

どうでもいいんだけど、昔、これをプレイしてたときは、そろそろゲーム卒業しようというころだったので、そこらへんの影響で印象に残ってないのだと思う。あーあと、同じくらいにやってたのがヴァルキリープロファイルとか。

で、実際、そこらへんを最後に、2年くらい全くゲームしなくなってしまってた覚えがあるんだけど、何故か、今はこうして立派なダメオタに復帰。それもこれも学校の帰り道にあったエスプレイド30円のおかげです。

そんな思い出話はどうでもいい!!そんなことより、いいかげん引越しの準備しないと。

しかし、何から手を付けたらいいかわからなくて、何も進まない。

ZinniaZinnia 2005/03/15 09:52 お引越しはどちらへ..?
(誰も聞かないのが不気味だ(^-^;

w_ow_o 2005/03/16 12:01 引越しと言っても、同じ市内なんで、実はそんなに大した変更では無いです。
自転車でも30分かからないぐらいの距離です。

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

2005-03-11

来週までに引越し準備終わらせないといけないようで。

[] 結局

ベイグラントストーリを。


イベントシーンとか、全然覚えてないなぁ…どれも始めて見るような気がする。そんなことはないんだけど。

あー、あと、何も考えずにやっていると、予想ダメージが常にゼロ。ランダムの分で実際には5くらいはダメージがあるんだけど、とか、そういえばそんなゲームだった。

[]

ウルトラstage4行けた。多分まぐれだけど。しかし、2ボスも3ボスも未だに全然避けれる気がしない。

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

2005-03-09

ストリームの部分わかんないよ。読めたもんじゃない。書き直したほうがいいのかなー。

[]ブレースがだめならインデントを使えばいいじゃない

id:ytqwertyさんのところに昨日のをAdaとPascalの場合で書いた場合のが。

で、それを見てたら、AdaとかPascalとかそれ以前に、僕が書いた処理がちょっとヘボいことに気付いて(特にread_2int)、恥ずかしさのあまり穴に入りたくなった次第。しかし、近くに入れそうな穴がなかったので問題無かった。

えーと、あれは、ちょっと複雑に書いたほうが、テーマに沿うかなーとか、そういうことにしといてください。


まあ、そういう下らない話は置いといて、確かに、MLとかLispほどではないけど、AdaとPascalは空行無しで書いてもそれほど見にくいとは感じない。これは、どこが違うんだ…、と思って見てたら、「ひょっとしたら、ブレースが悪いんじゃないか…」と感じてきた。

    hogehoge;
}
nanika;

こーいう形だけで見た場合、ブレースはどっちかっていうと、nanikaのほうにくっついてるように見える。それが気持ち悪いから、無意識のうちに改行入れてしまうんじゃないか、と。いや、断言はできないけど。なんとなく、そんな気がした。


で、「あー、じゃあブレース使わんほうがいいんかなー…ブロックの終わりはどうしたらいいかなー…begin〜endってあんま好きじゃないんだよな…」と、思ってたら、「インデントを使えばいいんだよ」とか、そんな考えが、ふと浮かんで、インデントを使うとしたら、こんな感じ↓

def read_int( fp, last, max ):
	mutable num = 0
in:
	while true:
		c = stdio.getc( fp )
	in:
		if ctype.isdigit(c):
			num = num*10 + (c-'0')
		elseif c == last:
			if num <= max
				return num
			else
				parse_error()
				return 0
		else
			parse_error()

になるかなーって妄想してたら、なんか、僕の求めてる物に非常に近いような気がしてきた。僕はずっとCスタイルが好きだと思ってたのに、全然そんなこと無かったようだ。

もうちょっと詰めて考える必要がありそうだけど、これに、前に考えた色々とか、最近考えた色々とか、そういうのを詰めたら、僕の理想の言語ができるかもしれん。と、思ってちょっと楽しくなってきたけど、言語なんて、妄想してる時が一番楽しいのであって、多分、今がピーク。


まあいいか、気が向いたら実装してみよう。いつになるか知らんが。


あと、Cだとか言う以前に、僕のコードは空行が多過ぎるような気がした。あれはどうなんだろうか。僕は精一杯見易くするつもりでやってるんだが、他にやってる人がいない。

思兼思兼 2005/03/10 21:45 で、Pythonに行くの?

思兼思兼 2005/03/10 21:49 空行の入れ方は一応ポリシー持ってる。
日本語かいてて字下げするくらいの区切りは1行
2,3行空けて段落にするのに相当する区切りは2行かブレース
章に当たるのが関数で、関数と関数の間は3行空ける

業務ではあんまり守ってないけどね。他人も編集するし。

w_ow_o 2005/03/12 05:15 いや、Pythonには行かんよ。
というか、そもそも、僕にはああいうLLとかいう類いのスクリプト言語の需要が無い。ちょっとした処理とか手動でやるし。

w_ow_o 2005/03/12 05:20 あと、僕の改行はルールも無く気分で適当にやってるだけなんで、ポリシーとは言えないかもしれない。

思兼思兼 2005/03/12 13:02 俺は会社のPCにTCL、Perl、Rubyが入っていて、次にPython入れる予定の組み込みプログラマ。
TCLとか使わんが。

w_ow_o 2005/03/15 03:04 むしろ組み込みTCLとか。

2005-03-08

どうでもいいんだけど、会社から出ると電灯の類いが一切無くて困る。月明りがありがたい。ちなみに、最近は月が無い。

[] Cスタイルでも短いコードが書きたいってのはどうだろうか

ちょっと奥さん。MLでMLコンパイラ(サブセットだけど)を書くと2000行で書けるらしいですよ。


と、いうわけで、なんか面白そう、と思って見てみたんだけど、これは、ちょっと卑怯じゃないか。何が卑怯かというと、ソースコードに空行がほとんど無い。たまーに関数の間に一行空いてるくらいで、ほとんどぎっちり詰めてある。

そんなので「関数型言語はC++よりも生産性が高い」とか言うの?それは反則なんじゃないのかっ!?


と、まあ、そんなことは別にどうでもいいとして、おもしろいのは、このソースコード、空行がほとんどないのに、可読性に問題が無い、という点である。C/C++でそんなことしたら、ちょっと痛々しいソースコードになってしまうだろう。また、逆に、OCamlのソースコードで変に空行を入れたりなんかすると、スカスカ感がして、読みにくいかもしれない。Ocamlだけでなくて、Schemeもその感じがあるかもしれない。Haskellはよくわからんけど、多分、似たようなもんだろう。

これは、どこが違うというのだろうか。と、考えるのは面白いかもしれない。

そこで、Cスタイルのコード好きとして、ここは、そこらへんについて考えて、無理矢理Cスタイルに、そういうのを混ぜてみよう、という話。


まあ、そういうネタなんだけど、空行を入れなくてもソースコードが読みやすい、となれば、一個のエディタに含められるソースコードの量が増えて作業効率が上がるだろうし、しかも、可読性がよくなる、とも考えられるので、実益もあるかもしれない。


まず、どこらへんから違いがくるか、を考えるために、ちょっとしたコードをOcamlとCで書いてみる。ネタは「ファイルの中身に書いてある時刻と、ファイルの変更時刻を比較する」と、いうもの。

n,12:30

こんなファイルがあって、このファイルの変更時刻が12:30よりあとだったらOKと表示。で、最初の一文字が'o'だったらその反対、12:30より前だったらOKと表示。と、そんな感じ。

Ocamlで書いたのが、ml.ml。Cで書いたのがc.c


Cは、多分、読みやすさと短かさを考えると、このぐらいが妥当だろう。MLのほうは、よくわからん、もっと短くなるかもしれないし、もっと読みやすくなるかもしれない。MLのほうが、58行。Cのほうが133行。やってることは大差無い。ungetcを使ってないぶん、Ocamlのほうが汚い。んで、参考までに、Cのほうは行間詰めると、100行。


で、これについて考えてみることにする。

  • 塊のあとの空行

Cでいうと、ブロック。Ocamlのほうでいうと、長めのlet ... inの間。

僕の場合、Cだと、

nanika;

while ( ... ) {

}

nanika;

まずまちがいなく、こういうスタイルになる。んで、詰めると明らかに読みにくい、でCamlのほうが

let nanika = xx in 
let hoge = match xx with 
    | _ -> ...
    ....
in
nanika...

こんなふうになる。ここで、下から二行目のinの前や後に一行入れたりはしない。そして、これでも読みにくいわけではない。


空行の入れかたの違いに関しては、これが一番大きいだろう。

これは、Cの場合はインデントが左に行っても処理が続いてしまうので、どこが区切れかわかるようにしてほしい、と思うのに対して、OCamlの場合は、インデントが左にいったときに、そこで一区切りつくから、空行無くても大丈夫。といった感じだろうか。よくわからんな。思考とか認識の問題だと思う。


とりあえず、ブロックの終わりは区切れてくれるような構文にしてほしい。ってとこか。

  • if式

if が式として使える。

int x;

if ( value == OK ) {
	x = 8;
} else {
	x = -8;
}

return x;
if value == OK then 8 else -8

空行ではないけど、これは、影響が大きいかと。MLのほうが横に長いのも多分そこらへんの影響。

Cでも三項演算子で書けるけど、可読性でいうと、あれはあんまり使わないほうがいいだろう。


ifは式として使いたい、と、いったところか。


ん。なんか書くの面倒になってきたな…他にも若干あるんだけど、まあ、なんだかんだあって、そこらへんを考慮しつつ、Cスタイルを保つ、となると、僕が考えるのは、

  • ブロックとかifとかが値を持つ。
  • 型推論
  • 構造体をつくるのが楽。

こんな感じ。

ひょっとしたら、そこにあるのは僕の理想のカタチかもしれない!!


と、思って、それで、書いてみたら、全然駄目だった。

なんていう適当なオチ!!

read_2int( FILE *fp )
{
	let n1 = {
		let c = getc( fp )
		{
			if ( isdigit(c) == 0 ) { parse_error(); 0; } else c-'0';
		}
	}

	return {
		let c = getc(c)
		{
			if ( isdigit(c) ) n1*10 + (c-'0');
			else { ungetc(c,fp); n1; }
		}
	}
}

残骸。if文とif式を別物として扱えないと無理。それ以前になんか色々無理。文法とか以前に気持ち悪くて書けない。結局無意識のうちに空行入れてるし。何が違うんだ。


Cでも副作用をほぼ無しで書くことは不可能ではないから、そういうのが問題ってわけでもないだろう。まさか、ブレースだから駄目ってこともないだろうし。

LispとかOCamlなんかで書くと、自然と行間無しで書いてるわけだから、どっかで思考を切り換えてるはずなんだけど。それがどこかわからん。自分のことなのに。

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

2005-03-07

昼間ぬくい。

とりあえず、冬は乗り切ったようだ。長野っていっても、ここらへんくらいの寒さだったら耐えられるらしい。もうちょっとくらい平気かもしれん。

[] 雑作業

ハッシュテーブルまわりを若干。

なんか昔、ハッシュテーブルが使い物にならないとか書いたんだけど、使いかたがわかったので、そっちに変更。

今気付いたんだけど、あれ書いたのが一年前の話か…ふーん…

ハッシュテーブルの部分だけは、asdfの頃のをそのまま使ってて、asdf_hashtab_insertとかって名前になってたんだけど、これでasdfの頃から使ってる部分は無くなったかと。評価の部分とかはnl_をilog_に変更しただけとかもあるけど。

そう考えると、感慨深いものなんだけど、ソースコード書き換えないと使えないってことは、腐ったコード書いてる証拠以外の何者でもないのであって、むしろ反省しないといけない部分のような気もする。

しかも、またインタプリタ部分変更するつもりだしなぁ…何が間違ってるんだ。


まあいいか。あと、大分前から言ってるパーサにようやく手を付け始めたんだけど、また、これが、思ってたより面倒だ。匿名関数のリストを作って引数に渡す、とかCで書いてるとやってられない。いや、やってると、楽しいんだけど、多分、できあがるソースコードは僕以外読めない。

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

2005-03-06

おぉぅ。面白いと言っていただけると、非常に励みになります。緊張しますが。

[]

先週日曜早起きするとか言ってたけど、あんなの口からでまかせもいいところだ。結局2時まで寝てた。

いや、一応金曜に夜11時に寝たりとかして、努力はしてみたんだが、その次の日に、昼の12時に起きたので、もう早寝は二度としない、と誓った次第。


あと、全然関係無いんだけど、ベイグラントストーリーの吉田絵再現率は高過ぎる、とか書こうとして、調べてたら、ベイグラントのスレを発見してしまって、なんとなく見てしまう。

PS2のアンチエイリアスはベイグラントストーリーのためにあるようなもんらしい、とか知ったら、なんか、やりたくなってきたな。チェイン繋げて大ダメージかと思いきや、リスクの上がる量が尋常じゃなくなってくるので、チェイン全然使えねーよ。みたいな感じしか覚えてないんだけど。

あと、リムごとのダメージが何の意味があるかわからない。とか。というか、パーツごとのダメージってどのゲームでも微妙なシステムになってるような。


まあいいか。セーブデータ残ってたかな…

Fastブロック 続き

http://d.hatena.ne.jp/w_o/20050303#p1 コメントのとこの続き。ちょっと長くなりそうなので、こっちに書きます。


えーと、僕の理解違いだったらすいませんが、ひょっとしたら、特異メソッドあんまり知らないくせに「Rubyの特異メソッドがどうの」とか書いたのが悪かったかもしれないです…メソッドの再定義を無効にするのは、あの話ではメインではないです。

僕が主に考えてたのは、暗黙のアクセサメソッドの関係、C#でいうプロパティが定義してある場合の話です。


Pythonでいうと、

class Point:
    def __init__(self,x,y):
        self.x = x
        self.y = x

    def __str__(self):
        return (self.x,self.y).__str__()

class Nanika:
    def __init__( self ):
        self.point = Point( 100, 100 )


n = Nanika()
print ( n.point.x, n.point.y ) # (100,100)

まず、こんなコードがあったとして、これの、最後の部分、

print ( n.point.x, n.point.y ) # (100,100)

この部分は、いちいちハッシュテーブル参照されるのも気分が悪いので、

tmpp = n.point
print ( tmpp.x, tmpp.y ) # (100,100)

こんな風にしてほしいところです。

が、Pythonの場合だと、クラスNanikaの定義が

class Nanika:
    def __init__( self ):
        self.__p__ = Point(100,100)

    def __getattr__( self, name ):
        if name == 'point':
            retp = self.__dict__['__p__']
            self.__dict__['__p__'] = Point( 150, 150 )
            return retp

        raise NameError( name )

こーなってると、n.pointを参照したときにn.pointが書きかわるので、

print (n.point.x,n.point.y)  # (100,150)

の場合と、

tmpp = n.point
print ( tmpp.x, tmpp.y ) # (100,100)

の場合で実行結果が変わってしまうので、勝手にコンパイラが最適化を入れるわけにいかない、と。それはどうなのか、っていう話です。

「__getattr__が定義してあって、かつ、__getattr__には副作用がある」なんて状況はそんなによくある状況でもないのに。


で、そういう気分をなんとかするためにアクセサメソッドの実行を一時的に制限する、Fastブロックみたいなのがあったらいいんじゃないかな。と。

「メソッドのインラインがされる」とかは確かにやりすぎの感じはありますが、アクセサが実行されないぐらいだったら効率と柔軟性のトレードオフとしては妥当なところじゃないかと思うのですが。

ささだささだ 2005/03/07 05:42 もっと頑張って最適化できるようになんかしよう、って話ですね。わたしは python は知りませんが、グローバルな解析(局所的じゃないやつ)が出来る、という前提だったらできるのかもしれません。

ruby でも、いろんな制約(eval 使うな、とか、定義を条件文に入れるなとか)をすれば、できるのかもしれません。

w_ow_o 2005/03/08 02:14 あー、でも僕の場合、考えてるのが自分しか使わないようなスクリプト言語なんで、同じ制約を付けるのでもRubyに制約付けるのとは、重みが違うかなぁ…と、思います。

shinichiro_hshinichiro_h 2005/03/09 03:02 面白いと言ったからには少しコメント…スクリプト言語なんて作ったことないのに昔似たようなことを妄想した時には、例えば「RubyとRubyに制約かけたもの」と考えるより、「RubyとRubyに文法が似てRubyと親和性の高い小規模別言語」の2つのインタープリタが動く、ってイメージの方がなにかとストイックな最適化かませるかな…とか思いました。妄想100%です。

w_ow_o 2005/03/10 02:33 うーん、どうですかねぇ…親和性を高めるとなると、元言語のメソッド呼べるようにしないといけないと思うのですが、そこらへんで色々最適化が厳しくなるような気がします。スクリプト言語の場合、メソッド呼ぶだけで色々と前提が崩れてしまうと思うので。
僕はVMやら最適化はよくわからないのでなんとも言えないですが。

w_ow_o 2005/03/10 02:46 むしろ、小規模別言語やるなら、親和性なんか全然無くて、整数と配列の演算しかできないけど、JITコンパイラに通しますよ、と、いうインラインアセンブラみたいなのはどうですかね。
さすがにそんなのを必要としてる人はいないような気もしますが。

ささだささだ 2005/03/10 22:23 そういうのも十分ありだと思いますよ。

shinichiro_hshinichiro_h 2005/03/11 02:03 あーなるほど… GNU lightening の VM 版みたいな感じですかね…

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

2005-03-05

[] 超雑談

再開発でもすすんでるのか、家の前で色々工事してるんだが。騒音とかは無いので別に問題無いんだけど。

それ関連で、ちょっと前からプレハブが建ってたので、何を始める気かと思ったら、プレハブ屋が始まってた。だからどうした。


あと近くのセブンイレブンのレジあたりに手書きのオタ絵があるんだが、ああいうのは店員さんとかバイトの人とかが書いてるんだろうか。謎。ああいうのは公私混同と呼べるだろうか。いや、別に僕は構わないんだが。というか、むしろ、もっとやってください。

姉も仕事場ではそういうのやってるのかなぁ。おじーちゃんおばーちゃんを和ませるオタ絵。いや、やってないと思うけど。実際やってたらかなりシュールな映像だと思うので、何かの機会があったらやってみてください > 姉。

[]

なんかできた。これ。ボールが飛んで、パーティクル出しまくって、しっぽ引くようなものを作ってたはずが、なんだかよくわからないものに。

動かすのにpythonpygameとpyOpenGLがいるけど、わざわざ用意してまで見るほどのものではない。あと、うちでギリギリ動くくらいなので、処理が重い、多分。

これで、パーティクルいくつくらい出したらテクスチャ無しで煙っぽくなるかやろうとしたら、パーティクル300個くらいで明らかに処理落ちしてたので、おとといの愚痴を書いた次第。1000個くらいは出してみたかったんだけど。

まあいいか。ビルボードというのをどういう風に使うかわかったので良しとしよう。3D空間に2D画像貼り付けるっていうのは、結構重要なんだな…


あと、Z座標を何も考えてないので、真ん中の箱は狂ってる。描画前にカメラから見たZ座標でソートすればいいのか。面倒だなぁ…。僕は3Dなプログラマにはなれないな。



全然関係無い話なんだが、グラフィック系のエフェクトのデモなんかで、かっこいいデモなんかの場合、エフェクトなんかなくても既に3Dモデル自体が素晴しい、っていうのは、珍しいことではないと思うんだけど、あれって個人でやってる場合はプログラマが自分で作ってんのかなぁ…。やっぱり、偉い3Dプログラマは空間把握力とかが違うんだろうか。

姉 2005/03/07 17:57 今月の職場のカレンダー絵はわしの絵です(=゜ω゜)
夜勤で暇あれば人知れずヲタ絵描いて捨ててます。誰にも見せねー

w_ow_o 2005/03/08 01:30 こっそり捨てたヲタ絵を拾ってるファンがいるかも…とか、言ってみるテすと

飴 2005/03/11 02:24 いねーよ

2005-03-03

これがNDA(秘密保守なんとか)の力かッ。うっかり喋ってしまいそうになるので危険だな。

Fastブロック

ちょっとPython風味でも浴びようかと思って、ちょろっと書いてみる。

しかし、テキスト処理をCで書いて、30FPSで数百個のオブジェクトが動くような処理をPythonで書いてる僕はどうかしてるな。


ううむ。しかし、あの程度の速度しか出ないのか。もう少しなんとかなると期待してたんだけど。

多分、普段からインタプリタとかGCの悪口ばっかり書いてるからだろうな。無意識のうちに、遅くなるようにコードを書いてしまう。無理矢理メソッドにしたりとか、オブジェクトにしたりとか。

愛があれば、無意識のうちにメソッドの手動インライン展開ぐらいするんだろう。


で、まあ、それはいいか。スクリプト言語に、「機能を限定して、高速化するブロック」とかがあったらどうだろうか、と、ふと思ったのである。Fastブロックとでも呼ぶべきか。


まず、多分、スクリプト言語のボトルネックのうちでもそれなりに大きいのは名前検索だと思う。変数を拾ってくるたびにハッシュテーブルからひいてこないといけない。

たとえば、

x = object()
y = x.nanika.foo()
z = x.nanika.foo()

こんなスクリプトがあると、実際の処理は、

# get がハッシュテーブルから拾ってくる処理

tmp = get( global, "object" )
get( global, "x") = tmp()
tmp = get( global, "x" )
tmp = get( tmp, "nanika" )
tmp = get( tmp, "foo" )
get( global, "y" ) = tmp()
tmp = get( global, "x" )
tmp = get( tmp, "nanika" )
tmp = get( tmp, "foo" )
get( global, "z" ) = tmp()

こんな感じになる。多分。

で、スクリプト言語の柔軟性を考えると、オブジェクトがハッシュテーブルになってるのは仕方無いとしても、上のプログラムは見るからにget呼び過ぎである。パース時に適当に最適化して、

tmp = get( global, "object" )
tmpx = get( global, "x")  # x の値はキャッシュ
tmpx = tmp()
tmp = tmpx
tmpfoo = get( tmp, "foo" )   # fooの値はキャッシュ
get( global, "y" ) = tmpfoo()
get( global, "z" ) = tmpfoo()

このくらいにはしてほしい。


しかし、これが、不可能なのである。スクリプト言語の類いは、オブジェクトの性質が代入するるだけで変わってしまうこともあるし、関数呼び出すだけで、同じ名前でも全然違うオブジェクトになってることもある。Pythonでいうと、getattr、setattrをオーバーライドしてるとか、Rubyでいうと、特異メソッドがどうとか、JavaScriptでいうと、getter、setterだとか。

それをなんとかするには、毎回変数に会うたびにハッシュテーブルから値を拾ってくるしかない。省略してしまうと動作が変わってしまう恐れがある。

だが、そういったちょっと変わった機能というのは、滅多に使われることはない。全く使わなくても良い状況というのは珍しくないだろう。

そこで、Fastブロックなのである。Fastブロックの中では、そういう最適化の邪魔になる機能は使えないが、そのかわり、コンパイラが適当に最適化してくれるかもしれない、としておくのである。適当に値をキャッシュしてくれてるかもしれない。共通部分式が括り出されてるかもしれない。そういう感じ。あと、インライン展開してくれるとか。

まあ、そんな感じ。


あーそうか、関数にFast属性みたいなのを付けれるようにしたらいいのか。Fast属性の関数は再定義できない。Fast属性の関数からは、Fast属性の関数しか呼べない。Fast属性の関数の中では、アクセサは展開されない。そんな感じ。これでいこう。

ささだささだ 2005/03/05 19:53 それの行き着く先は C++ ですね。

w_ow_o 2005/03/06 01:23 あー、こういうのはC++っぽいですかね。

個人的に気になるんですが、スクリプト好きからしたら、こういう仕様はどう感じるもんなんでしょうか。
僕は、いちいちハッシュテーブル参照してる、と、考えると気持ちよくループとかが書けないんで、あったほうが良いと考えるのですが。

ささだささだ 2005/03/07 00:37 デフォルトを「コンパイル時に決定」に倒しているのが C++(virtual 付けなきゃ検索しない)。その他(スクリプト言語や Java、Lisp など)はそうじゃないよね。

その辺は、メソッドディスパッチの高速化手法が提案されているので、興味があれば調べてみるといいのでは。

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

2005-03-02

[]

libibertyのソース見てたらなんかちょっと便利なのを見つけた。

#if DEBUG

# include <stdio.h>
# include <stdlib.h>

int
main ()
{
  printf ("%12.f %12.f\n", physmem_total (), physmem_available ());
  exit (0);
}

#endif /* DEBUG */

/*
Local Variables:
compile-command: "gcc -DDEBUG -DHAVE_CONFIG_H -I.. -g -O -Wall -W physmem.c"
End:
*/

こーやっておくと、このバッファでcompileしたときに、これでコンパイルできるようになるっぽい。

末端ソースコードのテストしたいときとか、数行の確認プログラム等に。

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

2005-03-01

しかし、毎日何もしてないことを書き続ける日記もどうかしてるよな。

あと、最近日曜の夜から月曜朝起きるまでの憂鬱さが尋常じゃないので、日曜は昼までには起きて少しは運動とかしたほうがいいかもしれん。

yarv

あー、「yarv楽しそうだなー」と、思って、たまに見てました。Rubyよく知らないので、あんまり詳しくわからないんですが。

[] 前の続き

無駄な練習をしないためにも重要なことは最初に教えておいてほしいと、いうような反論が。

うう…確かにそうかも。あとから、ボロボロと変な仕様を見せられていく、というのは、問題あるかもしれない。


でも、ガレッガの場合はともかくとして、C++のテンプレートやら、ややこしい暗黙の変換なんかの複雑な部分は、別に必須ではないので、少し状況は違うかも、とも思う。

でも、ライブラリとかが混ざってくると、必須になってくるか。あと、チームにC++オタがいたりとかしたら、話がややこしくなるような。


あー、よくわからんな…まあ、そのへんは保留…というか、思考停止か。


あと、僕は、「C++の複雑さは強調されすぎてる」とは、思ってますが、「C++がわかりやすい」とは、あんまり思ってません。と、一応フォローを。

それは正解か、それとも逃げなのか

と、まあ、コードも書かないのにあんまりうんちくばっかり書いてるのもどうかと思うので、コード書こう。

でも、特にネタも思い付かないので、結局ILogに手を入れるしかやることがない。


とりあえず、前の計画を実現するために、4.0に移植。あと、前、CFGをCall Flow Graphとか書いたんだけど、あれは、Control Flow Graphの間違いなので注意。というか、ちゃんと調べてから書きましょう > 自分。


4.0の話。

これまで、何回か、「RTLを生成するのには、expand_hogehoge関数を使う」と、書いてるんだけど、4.0以降では、それは使わないようだ。

4.0では、GIMPLE→SSA→RTLってなってるので、フロントエンドは、RTLではなく、GIMPLEというのを生成する必要がある、と。

GIMPLEというのは、gcc/tree.defの中で定義されたtreeだけで作られた中間形式のことだ。多分。

よーするに、これまでは、自分で定義したtreeを直接RTLに変換しても大丈夫だったけど、4.0からはいったん決められたtreeに変換しろよ、というわけだ。

まあ、これまでの動作でもRTLを生成する部分で単純な表現に変換する必要があったので、そこらへんをちょろちょろ弄ればいいだけだから、大きく構造が変わることはないだろうけど。


そんな感じ。コンパイルは通るようになった。構造としては、綺麗になるんじゃないかなー。

で、まあ、そこらへんは個人の問題なので、いいとして、ネタが無いからって言語処理系に手を出す、というのは正解か、それとも逃げか、という話。


言語処理系というのは、プログラマにとって、一番基本的なツールと言っていいだろう。メーラは無くても仕事できるけど、コンパイラが無くては仕事ができない。(エディタは微妙なところではあるが)

だからこそ、暇さえあれば、その基本的なツールについての理解を深め、そして、手を入れる、というのは、職人として当たり前である、というような考えかたができる。だから、他にネタが無いから処理系を弄る、というのは、正解である、といえる。


しかし、処理系というのは、作ったとしても何も問題を解決しない、という問題がある。

プログラムというのは、本来問題があって、それを解決するために作られるべきものである。

プログラムを書くためには問題がいる、というわけだ。で、プログラマにとってはその「解決しないといけない問題を探す」、というのは、また、難しいもので、プログラマにとってはそれがある意味一番の問題であると、いえないこともない。

しかし、処理系を弄る、というのは、「解決しないといけない問題」が大して無くてもそれなりのものを作るのが可能なのである。というか、そこらへんを、利用者に丸投げしてしまっているのである。

つまり、一番難しい問題を先送りにしている、という意味で処理系を弄る、というのは逃げである、ともいえる。


えーと、何が言いたいんだ。

いや、僕はもちろん正解だと思ってますよ。

言語をどう設計するか、というのはライブラリをどう設計するか、とかと同じぐらいのレベルで検討されるべきだ、と思ってるので。

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