朝風呂。
松江から帰宅。
というわけで、まつもとさん、shugoさん、かずひこさん、NaClの方々、大変お世話になりました。
class C def m= a p a end end a, b = C.new, C.new a.m ,b.m = 1,2
面白いよねぇ。
なんだかんだと残ってたのを片付ける。
飛行機、ちゃんと飛べばいいんだけど。
ちなみに、まだ例外は実装できていない。
継続の持たせ方、というのは凄く難しい。たとえば、eval を再帰的に呼び出す場合、その「再起的に呼び出している」ということが、継続の管理手法となっている。rubyのインタプリタはそうやってる。
vm loop を用いる場合は、それを自分で管理する必要がある。それがどの程度難しいかは、対象とするプログラミング言語による。ruby はとても難しい(と思う)。
インタビューってのは、したことがないんで、どうなることやら。話下手なので、うまく聞き役ができればいいのだけれど。
例外の仕様改訂版:
begin A rescue B else C ensure D end E #=> start_A: A end_A: C end_else: D E exception_part: type: rescue range: start_A - end_A code: B end type: ensure range: start_A - end_else C end
どうやって戻っていくのかが微妙。end でシステムに戻るのだとは思うのだけど。ensure はそれでいいんだけど、rescue はそうじゃない場合がある。
もう一個命令追加しちゃおうかな。continueexceptionhandling。長い。
というわけで、行ってきます。
というわけで、来ました松江。
大変お世話になりました。
肉美味しかったです。
やっと酔いが覚めてきた.
例外発生時,ensure を実行した後の処理が思いつかない.どうしよう.
しかし,構文木を触っていると幸せな気分になれる.構文木を作るのは苦手だけど.
begin rescue else # 例外が発生してなかったら実行 end
なんて知らなかった・・・(忘れていた).使ったことない.rescue で取れなかったときに実行,のほうが嬉しかったな.
begin A rescue B ensure C end D
のとき,
A C D end rescue part: B C goto D end ensure part: C end
にするか,
A continue_C: C D end rescue part: B goto continue_C ensure part: C end
でいいのか.これで行こう.
あ,rescue 関係なかった.
begin A ensure B end C #=> start_A: A end_A: B C end ensure_part: * start_A - end_A B end
begin A rescue e1 B resuce e2 C else D end E #=> start_A: A end_A: D after_else: E end rescue_part: * start_A - end_A if classof(err) == e1 B goto after_else if classof(err) == e2 C goto after_else end(insn)
なんか python ぽいぞ.
こんな単純なので,本当にいいんだろうか.
あぁ,ダメポ.考え直し.
例外ハンドリング規則:
☆の部分が出来ない.困ったぞ.つまり,「駄目だったとき,どうやって再検索するの?」という話.
あと,ネストの話も解決しないな.困ったなあ.でも,これはどっちもテーブル操作を賢くやれば問題ない気がしてきた.
「駄目だったとき,もう一度検索やりなおしてね」命令が必要,ということだろうか.どうしようかなぁ.例外情報は,Exception オブジェクトに突っ込んでおけばいいような気がするけど,本当に大丈夫だろうか.例外処理中に例外が起こった場合とか,うまくいくかな?
例外テーブル操作.
sD--eD sB--------eB sC---eC sA------------------------eA #=> sA-sB A sB-sD B sD-eD D eB-sC A sC-eC C eC-eA A
というテーブルを作ればよい.多分.検索方法は,とりあえずスタート位置はソートされているから,簡単.
sA-eA A sB-eB B sD-eD C sC-eC D
という表にしておけば,実装は凄く楽なんだけど,検索が遅い(最内側を探さなければならない).でも,結局線形探索なので,あんまり変わらないかもしれない.オーダーとしては変わらないかも.いや,変わるか.微々たる物だけれど.いや,オーダーは凄く変わるな.でも,現実的には変わらない.
とりあえず後者のままでいっかー.
ensure の表は難しい.内側から順にやっていかなきゃいけないから.
sD--eD sB--------eB sC---eC sA------------------------eA
のときに,えーと・・・.
ensure中に例外が出たらどうなるんだろう.
ensure 終了時,もう一段 ensure 出すようなコードを書けばいいのかなぁ.それとも,コンパイル時にくっつけてしまうか.
begin begin ensure A end ensure B end #=> ensure_part: A: A goto B_ensure_part B: B end(ensure)
これが楽そうだ.
class EA < Exception end class EB < Exception end begin begin raise EA ensure raise EB end rescue EB end
このとき,EA 例外が起こったことを無視しちゃうんだね.こういう話って,有名?
複雑なことをやろうとすると,はまりそう.
ネストの話は全然解決してなかった.どうしよう.困ったなあ.
しかも,rescue と ensure,分けて考えるとどうやら駄目っぽい.困ったなぁ.
そうか,別に分けなくていいのか.で,ツリーを葉っぱから辿るような何かにすればいいんだなぁ.そこまでやるかわからないけれども.rescue はフックできたら何事もなく続ける,ensure は必ず戻ってくる,ってことにすればいいか.できた.
return がとても重くなりそうな予感.
今度は $! のための保存,復帰をどのタイミングでやるか悩む.
というか,無理.
スタックでも用意するか? そうでもしないと無理だもんなぁ.$! 禁止,じゃぁ駄目なんだろうなぁ・・・.うぅ・・・.
スタックにしても,撒き戻しのタイミングがえらい難しい.どうしたもんか・・・.
フレーム撒き戻しのときに,頑張って $! 用のスタックを撒き戻しするか慎重に見ていくしかないっぽい.
$! なんて無い方がいいと思うんだがな.例外オブジェクトがほしいんだったら,=>e
みたいに,しっかりとるスタイルのほうがすきだし.
1.times{ begin raise ensure break end } #=> 何も起きず
こうなるのね.これは正しいのかなあ?
正しくないとするなら,どうするって感じだけど.
class E1 < Exception; end 1.times{ begin raise E1 ensure break end } p $! #=> #<E1: E1>
これは明らかに間違えな気がする.
Java で試そうとしたら,
class Exception2 extends Exception{ } class E{ static void main(String args){ try{ while(true){ try{ throw new Exception(); } catch(Exception2 e){ } finally{ break; } } } catch(Exception e){ System.out.println("hoge"); } } } #=> e.java:18: 警告: finally 節が正常に完了できません。 } ^ 警告 1 個
と出たけど,コンパイルはできた.で,実行したら,
・・・何も起こらなかった(finally の break をはずしたら,きちんと catch してくれた).
現状の Ruby の仕様と,同じってことになるな,これは.
これが正しいのでしょうか.
うーむ.
class Exception2 extends Exception{ } class E{ public static void main(String args[]){ while(true){ try{ throw new Exception(); } catch(Exception2 e){ } finally{ break; } } } }
これも例外出ないんだなぁ.
つまり,ジャンプが入ると,例外を無効化してしまう,ということかしらん.
class E1 < Exception; end begin raise E1 rescue E1 $!=nil raise end #=> t.rb:9: unhandled exception
class E1 < Exception; end begin begin raise E1 ensure $! = nil end rescue E1 end
はちゃんとフックしてくれるんだなぁ.
class E1 < Exception; end class E2 < Exception; end begin raise E1 rescue E1 => e begin raise E2 rescue E2 => e end p e #=> E2 end
当然のことながら.こういう例を考えると,$! のありがたみが出てくる・・・のか? こんなコード書くほうが悪い気がする.
そういえば,天才テレビ君がいつのまにか天才ビット君になったんですね.知らなかった.
仮説:$! は rescue 節でしか使わない.しかも,複雑なことはしない.
ということで,$! の定義を「最後に起こした例外オブジェクトが入ってる」ということにするのはどうだろう.
例外が発生したとき,スタックの巻き戻しの長さを微妙に調整しないといけないことに気づいた.全然簡単じゃない・・・.
p 1 + begin 2 raise rescue 3 end
このとき,スタックトップにおかれた「2」だけを pop しなきゃいけない.つまり,begin/rescue/ensure 節では,スタックトップからSPを何個,っていうふうに巻き戻さないといけないわけだ.うーんー.スタックの位置をコンパイル時,常に意識しないといけないのかー.うわー.
Java とかだと,強制的にフレームの最初に戻せばいいような気がする.
m(1,2,3, begin 4; raise; rescue; 5; end)
なんて例でもいいのか.この場合,「1,2,3」をポップしちゃいけない.でも,4 は pop しないといけない.
じゃぁ,ってことで,begin/rescue の body 部をブロックとして実装してしまうってのは・・・.あり,なのか?
begin{ } rescue{|e| } ensure{ }
こんなイメージ.なんか Smalltalk みたいになってきたな.
Scheme も一緒か.
そうすると,ブロックの起動,という命令がまた一個増えるのか.なんてこった.
ブロックごとにそんなことやるよりは,SPの設定値を弄るほうが軽量なんだけど(フレーム積まなくていいから).begin/rescue ブロックを式として使うなんて,殆どないだろうから,そのためにコストかけるのも嫌だしなぁ.
というわけで,将来的には設定SP数を数えて,現状では必ず0ってことにしよう.決めた.どこのフェーズで計算するかってのにもよるよなぁ.
def iter p :enter 1.times{ yield } p :leave end def m p :enter_m iter(&Proc.new) p :leave_m end m{ break }
なんども同じことやってんだけど,Premature end of script headers
は嫌いだ.
今回もパーミッション関係.
Javaの文が中断(abrupt termination)するときには原因(reason)がひとつあります。例外とかbreakとかreturnとか。finally節が中断したとき、以前の原因は捨てられます。
やっぱそういうものなのですか.
「作りかけの引数フレームは継続の一部」ということですな>SPの巻戻しの調整。
たしかに.
数字のペア(A B) が,数字のペア(C D) のとき,A == C, B == D
となることを計算するためには,やっぱりもうこれ以上計算量は減らないかなぁ,と考える.前処理はいくらやってもいいこととする((C,D) は不明な状態で).
今更ながら,
i = 1 3.times{|i|} p i #=> 3
は微妙だ.難しい.
って,
Block parameters will be block local even if variables with same names exist
っていうことは,何も考えなくてもブロックローカル変数として扱ってしまえばいいか.
でも,どうしようかな.現状に合わせるか,2.0仕様にしてしまうか.
1.9 のパーサがこの仕様になったときに考えればいいか.とりあえず,現状ではサンプルプログラム・テストプログラムなどでこの問題が起こらないようにして逃げておこう.
あるブロックについて,ブロックパラメータ一覧を得る方法がわからないぃ・・・.これ,そもそも無理ですか(現状だと).そうですか.
どうしたもんかなー.うーんー・・・.ブロックパラメータしかブロックローカル変数はない,ということにすれば,一覧取得は可能か.うへぇ.めんどくさい.
1.times{ p local_variables j = 2 }
で,きちんと ["j"]
と出るのが謎だ.まだ dasgn してないじゃん.なんでー? なんでー?
わからん.どこで rb_dvar_push を呼んでるんだろう.-> rb_dvar_push は呼んでいない
eval.c を読んでもさっぱりわからない.どこで ruby_dyna_vars に"j" とかセットしてるんだろう.どこにその情報が入ってるんだろう.どうやら,パーサから伝わってるらしいんだけど.
思い出した orz.すべての dvar は,最初に nil で初期化するんだっけ・・・.eval.c 見てもわかんないはずだよ・・・.
つまり,最初の NODE_DASGN_CURR(var = nil) を全部見れば,リストが作れるわけだね.
やっとブロックがコンパイルできるようになった・・・.何時間かけてるんだ俺.
def m yield end m{ 123 }
が動いた.絶対嘘だ.こんなに簡単にいくはずがない.
NODE_YIELD の引数(nd_head)に渡す NODE_ARRAY の nd_alen も,いい加減らしい.どうしたもんかな.
def m yield(123) end m{|i| j = 1234 p j } m{|i| p i i }
がやっと動いた.あー,頭いたい.
def m a yield a end m(3){|i| m(4){|j| i*j } }
が動いた.
class Array def each_ len = self.length i = 0 while i<len yield self[i] i+=1 end end end [1,2,3].each_{|e| p e }
が動いた.なかなか感動的(しょぼ).
どうも,commit しようとすると diff が 1000行ほど溜まってる.まずいよなぁ・・・.
というわけで,とりあえずイテレータまで行ったけれど,この後どうしようかな.
誰かチェックしてくれないかのぉ.
あー,眠い,眠い,眠い.
酒飲んで酔っ払い.
i = 1;3.times{|i|};p i;は2じゃないですか?0,1,2で。1となるべきか2となるべきかが微妙だ、って意味ですよね
最近やっと yarv 脳になったので(遅すぎる)、日記を再開してみる。
class C::D < class C;self; end; self.name ; end
なんてのは、やっぱり動いたほうがいいと思うので、super を先に評価することにする。
なんか、マニアックなコードが動くのに、イテレータは動かないという謎さ。
ちなみに、定数アクセスが劇遅。定数なのに、定数時間でアクセスできないというのもアレだ。なんとかならんもんかなぁ。
定数なんだから、最初に見つけたやつを以後そのまま使う、ってことにしてもらえんものか。
class C Const = 1 class D def m p Const end end end C::D.new.m class C::D Const = 2 end C::D.new.m
現状では、1,2 と表示されるけど、1,1 でもいいような気がする。こんなケースみてられっか。
劇遅なのは理由があって、C という式が2命令に分割されるから。::C だと、ちょびっとだけマシ。
ちなみに
load(file, true) #loaded C = 1 ::C
で、Cが見つからないのは、Ruby的にOKなんだろうか。そうなりそうな気がするけど、なっちゃいけないような気がする。
case NODE_COLON3: result = rb_const_get_from(rb_cObject, node->nd_mid); break;
じゃぁ、しょうがないなぁ。
どうも定数アクセスが遅いのでなんとかならんか、と思って一生懸命考えた。
2つ命令を追加しよう。
getinlinecache(cached, version, jumpto) もし、vm の状態バージョンが version だったら、cached を stack へ 置き、jumpto で示されるところへ飛ぶ もし vm の状態バージョンが違っていれば、何もせず、次に行く setinlinecache(setaddr) setaddr で示される getinlinecache 命令の cache に stacktop の 値を格納する
VMの状態バージョンってのは、定数など、普段あんまり更新されないはずのものが更新されたときに 1 increment する。
これを利用すると、たとえば定数アクセス A::B::Const
なんてのは、
start: getinlinecache(0, 0, end) putliteral nil getconstant :A getconstant :B getconstant :C setinlinecache(start) end:
となる。VMの状態バージョンが変わらない限り、getinlinecache は label へジャンプする命令となる。
どうしたもんかなぁ。他の用途が思いつかないぞ。
現状では、各メソッドフレームなどに、$~, $_ の領域を確保している。これはあまりにも非効率的かも、とか、今後メソッドローカルフレームが増えたとき困る、という問題から、こいつら特殊メソッドローカル変数は別オブジェクトに押し込むのはどうだろうと考えている。なんとかなりそうだけど、その特殊なメソッドローカル変数へのアクセサをどうするかが、今度は悩みの種になる。もう命令は増やしたくないぞ。でも、通常のメソッドローカル変数アクセサの中で if で分岐、とかはもっと嫌だなぁ。
というわけで、あまりに特殊な命令が増えてきちゃったんで、special 命令でも作ろうか検討中。operand で動作を変更。頻発しない命令に限る。
たとえば、popcref なんて命令を今しょうがなくくっつけちゃってるけれど、こいつとか。setinlinecache も候補。getspeciallocal, setspeciallocal も、こいつでいいでしょう。
とりあえず、懸念のひとつだった定数(またはclass/moduleまわり)はかなり厳密に作ったので、次は iterator。
しかし、来週、再来週と目が回りそうだ。
途中でプレゼンを何個作れと。
情報科学若手の会は、どんな議論ができるのか楽しみ。ふふふ。
i = 1 Class.new{ p i p self }
で、self が定義中のクラスに置き換わるって、気持ちはわかるんだけどすげー気持ち悪い。どうやって実装するかもわからない。
どうしたもんだろうねぇ・・・。
SICPに遅れないようにと思って学校に来る.泊まる.
・・・SICP家に忘れてきちゃった orz
しかし,さすがに久々に書くと,伸びる伸びる.
日記は書かないつもりだったんだけど,感謝をこめて.
RubyConf.2004 のホテルの予約を David A. Black氏にしていただきました.ホテル側といろいろと混乱してる感じだったので,どうなのかなー,とか,私がメールをホテルに出してもなしの礫だったのを見かねて,やってもらいました.
感謝します.
でも,チャットで(私)「まだ何時まで泊まるか決めてないんだよね〜」(D)「もう(予約の)電話中だよ」と返ってきた時は焦りました.早すぎ.
で,D.C.観光のために,まだ2日分のホテルを予約しないといけないんだけど,誰かいいところ知りませんか(おい).やっぱり D.C. 内のホテルは高いんだろうか・・・.
調べてみると,やっぱり高かった orz.
ホステルは安いのだけど,怖いのでやめとこう(臆病者).
皆さんはどうやってホテルを探すんでしょうか.日本の代理店に頼むのかなぁ.でも,それだと一泊$50は軽く超えてしまう.
怪盗ルビィ
しばらく日記は書きません.書きたいことはあるんですが,すぐにこっちに逃避してしまう.
うーむ,名前選びはけっこう目移りしますねえ。
じいちゃんち(岐阜)にパソコンを用意しろという指令がきた。プロバイダ選びとか、ADSLひくとか、どうしようかなぁ。遠隔、というか代理で手続きってどこまでできることやら。そもそも、請求書とかどうしたもんか。
じいちゃんたち向けにでかい文字を表示のできる液晶募集。誰か知りませんか。
どうも、普通に売ってる 17inch は 1280x1024 固定っぽい。
低解像度が綺麗に写る液晶はないでしょうか。
うーむ、世のお年よりは何を使ってるんだろう。CRTは重いんだよなあ。
で、私自身もノートPCを新調しようか迷ってるんですが、たまには東芝でも買ってみるかぁって感じで Dynabook の SS/SX がとても魅力的。
Let's Note R3 も、この9時間持つ電池ってのは魅力だなぁ。どうしよ。
あぁ、物欲の夏。
9時間のR3が欲しくなってきた。でも高い。
うーん,SFC行ってみたいかも.
asahi.com : Be on Saturday 「名実ともにエンジニアに復帰しました」
うーん.
昨日の図書館.
今日の図書館
やっと1get.
phpstack - A TCP/IP Stack and Webserver in PHP いやー,馬鹿だねー(ほめことば)
今日は二日前のちくわ揚げを食べました.まだ腹には来ていない.
IRCで聞いたんですが,こんなことができるんですねぇ.
class C def initialize init class << self self end.class_eval( <<-EOS def #{init} p '#{init}' end EOS ) end end C.new('hoge').hoge C.new('huga').huga
うーむ.
最近,メールのサブジェクトをつけるのを忘れてしまう.駄目だ・・・.いろいろ.
ふと思ったんだけど,LL侍は一人だからよかったんだよな.ネタ系がもっと大量にあったりしたら,飽きたように思う.
というわけで,まずはオーディションをして,(略).
そうかー,みつきしなりおでまとめるのかー.うーん,そうかー.こっちのが綺麗にまとまってるってことなんじゃろうか.うーん.そうかー.
とりあえず全部がなっとくしとるってのが書きやすかったんだろうか.さすがにまなまなは無理だよなぁ.
隠れ肥満というか、普通に肥満。
あぁ・・・。
今日の古本。
今日のコミック。
図書カードをもらったので、つい。
どれもそこそこ面白かった。
今日の市役所。
いろんな書類を機械で取り出せるらしい。よくやってるなぁ。
必要なのは印鑑証明だけだったんだけど、ついでに。
起きたら11時.駄目人間.
で,今日も豪華にモス.
そういえば,未踏ユースの関係で青色申告しないといけないらしいんだけど,屋号どうしよう.
若手の会,新幹線はやはり高い・・・orz.バスで行こうかなあ.それだと往復7000円らしい.
「ぷらっとこだま」だと,片道 8000円か.バス往復よりも高いが,バスだと異様に疲れるだろうからなぁ.どうしたもんだか.
rubyconf'2004 ,まだ 30人ほどだそうです.まだ pickaxe2 は間に合う!
夕飯はすぱげてぃーところっけとほるもんやきとさらだ.日本酒でかきこむ.
うひゃー.
るるりんがないと仕事に手がつかない.るるりんがあると,仕事をする時間がなくなる.
青色申告の承認申請、期限に気をつけてね。お早目に。
臆病ものなんで,早々に流す.
賞味期限 7/22 のメンチカツを見つけてしまった.どうしよう.
尊敬する青木さんに近づくためには食べないと駄目だろうか.
しかし,たったあれだけのまとめで数時間かけてる俺って・・・ orz.
口には入れてみたものの(そう変な味はしなかった),飲み込む勇気がありませんでした.チキン(メンチカツだけど).
しょうがないので,一日遅れの丸じゃが揚げを食べる.
松江行きの飛行機を探す.今のところ,一番安くてホテルつき 25000円.二人以上で行けば 20000円になるらしいのだけれど.誰か行きませんか(どういう理屈だ). (中国・四国2日間)
あー,るるりんが見れないと何も出来ないぞ!(うそ)
帰って寝よう.
・・・帰ったら暑いから帰らない.
2時間くらい散歩.帰りはバスと電車.
やるぶでしょ。や・る・ぶ。またnokadaさんにポーズを決めてもらいましょう。やるぶのポーズ。
LL侍のネタで「Ruby、endがないとPythonですから、残念!」というのは見つけました。「って言うじゃない」の前も知りたいですが。
だからぁ,どうでもいいんだってば>読み
まつもとさんの発言を引用していたように思います>〜って言うじゃない
さすがに油モノはやめた方が...ってもう捨ててるか。
まだ迷ってます.
http://www014.upp.so-net.ne.jp/tetryl/llw2004/ll-samurai.txt > t15uさん
ありがとうございます。私はm4とhaskellが一番笑えました。
それはさすがに捨てると思う
atdot.net、停電後自動復活せず orz
そういえば、yarv ってなんて読むかわかんない、ってよく聞かれるんですけど。
そんな読み方どうでもいいんです。yarv なんて名前自体、どうでもいいんですよ。憶えてもらう必要もないんじゃないかと思います。
もうすぐ Rite になりますから。
と、たまには強気で書いてみたけど、うう・・・。
ちなみに、駄目だったら忘れられる運命なので、やっぱり憶えなくてもいいのです。あぁ、やっぱり弱気。
図書券をもらったのでたまにはコミックでも買うかーと本屋を覗いてみるも、最近のものがよくわからないので断念。どうしたもんか。
LLW の感想を、と思ったけど、私は殆ど聞いていない。
LL侍も面白かったんですが、一番面白かったのはnokadaさんのRubyのポーズでした。写真も撮ったので、今度何かに利用できないかと思います。
久居久井さんのGauche-gl デモがとてもよくできていた。モノを見せる、というのはやはり重要だと思う。
ウェブアプリケーションと継続。
継続、って callcc じゃなくて、「次に何をやりますか」って話。
<a href="lambda{ show_next_page() }"> 次のページ </a>
みたいに書いておくと、この Proc オブジェクトがリンクをクリックされるときに実行される(call される)ようなイメージで、難しいことではありません。Haskell もまさにこんな感じ。多分。
しかし、こういうフレームワークを作ってみるとわかるんだけど、Ruby でこういうプログラミングは壊滅的に向かないということがわかる。
やっぱり、バインディングするのはオブジェクトとメッセージであるべきなんだろうなぁとは思う。
と、ここに書いても、誰の役にも立たないような予感。
高橋さんは、発表原稿をとても精細に用意されていたのが、やはりさすがというか。あの素晴らしいプレゼンには、やはりそれだけの準備が必要なのだなあと思いました。
私は、いくつか、しゃべろうと思っていたネタを忘れていたし。
一応、LLWのプログラムを全て5分に突っ込んだつもりだったんだけど、どれくらいの人が理解してくれただろうか。
いろいろな方にご挨拶させていただきました。znzさんには、いろいろご紹介していただきました。ありがとうございます。
PGP ってなんですか、って感じですみません。
tagparts を使えばカレンダーは10分で出来ますた。tagparts 便利なんだけどなぁ。
nokadaさんに Date クラスを教えてもらう。これはとても便利かもしれない。
家族がどっかに行ってしまった。一週間ほど一人暮らし。なんというか、これで3週目?
トラックバックという仕組みを未だに理解していない駄目さ。
道具のよしあしとは、どれだけ感性にあうか、とかそういうことなのかなぁ。
学校が停電するんで,8/10の08:30〜18:30(予定)はこのサーバ,および atdot.net には繋がらなくなります.よろしくお願いします.
10分でロゴってのは,実はすでにお願いしていたりしたのでした.というか,出来てた.
で,未踏ユースのプロ管の人に奢ってもらって飲み.ごちそうさまでした.いろんな話が伺えた.
Rubyのポーズ見たいー
さすがに酔っ払っての所業をさくっと公開はできませぬ.
LLW見に行かなかったことの最大の悔いはLL侍見られなかったことです。どなたかどんなネタだったか教えてください。
私もあんまり覚えてません。ごめんなさい。
あ、漢字が違います。久井です。まぁどっちでもいいけど。OpenGL のレンダリング結果をコマごとに xwd で画像ファイルに落として、あとでつなげて AVI ファイルにしようとしたんだけど、なぜか全部終わる前に X が固まってしまう。途中まではちゃんとできてるので、X の不具合かなぁ。LL Magazine に LL 侍の DVD をつけたら、馬鹿売れしそう。(一部で。)
うあー,失礼しました>久井さん
やっとネタを思いついた。
昨日、頑張って会場に辿り付きたかったなぁ。
地図を印刷しなかったのが敗因。
・・・20号館を20号線(甲州街道)と見まちがえたのが敗因・・・。
orz
LT、それなりに受けたようで、よかった。
あくまで、それなり。まだまだ修行が足りない。
とても眠い。
皆さん大変よくやってくれました。本当に凄い。感動しました(ほっとした、というところもありますが)。
どうもありがとうございました。ちょっと涙腺が弱くなってます。
まだ明日の資料作ってないなあ。どうしよ。
久しぶりに帰宅。2週間ぶり?
会計としてあるまじき失態を犯しました。今後このようなことにならないよう、肝に銘じます。大変ご迷惑をおかけました。
と日記で言うことじゃない。
かずひこさんに、「Rubyを50倍速くしたらNaClに入れてあげるよ」と言われた。NaCl への道は遠い。
てか、一般的に、50倍速くするってのは、Cで書くよりも相当速いものを作らないといけない気がする。
例を特定させてもらえば、なんとかなるような気はする。でも、一般解ではない。
(解答:誰かを納得させる例(の集合)について、それ(ら)を速くする)
いろいろとしょぼーん。
LL weekend のらいとにんぐとーくの私の資料を公開していただきました。興味がある方はごらん下さいませ。
しかし、なんでわざわざあんなに速く提出させたんだろうなあ。納得いかない。
いろいろとご迷惑をおかけしております。申し訳ありません。
新宿のお店どこがいいんかなぁ。
しかし、MLみたいなのを立てて大げさにしたのは失敗だったかもしれない。なんか、まだ何もなかったらしいので、処理系の話ができたのかも。
というわけで、いろいろと不自由な生活が続く。
いや、そんなに不自由じゃないか。部屋にネットワークさえあれば、家より快適(クーラーがあるから)
高校生若いなあ。
私は基本的に落ちこぼれなので、それを決め付けるような会話にはとても心が痛む。なんとかしてあげたい。反論ができない時点で負けっぽいけど、自分のできる範囲でなんとかしたい。
やはり、プレゼンテーション(発表に限らず)がうまい人にいい世の中ということは、どこも変わらない。私には何ができるんだろうか。
やっぱり年齢順じゃなかったっすね。発表順か。
The hotel is offereing a special room rate of $89/night to conference attendees. Please contact the hotel directly for details.
タケーよ!
ということで、また今週とまりにいかないといけないらしい。布団で寝たいよう。
旅行記はまた今度。たくさん写真撮ったんだけど。
しかし、考えてみると、OSの研究室なのに、俺はOS研究会にはじめて行ったということになる。D1でやっとというのは、やっぱり不良学生なんだろう。
Squeak を初めて使ってみた(予習しておけよ!)。スゲーわ、これは。
うううううううううううううううううううううううううううううううううううううう