K.Sasada's Home Page

Diary - 2004 August

研究日記

葉月

_31(Tue)

朝風呂。


松江から帰宅。

というわけで、まつもとさん、shugoさん、かずひこさん、NaClの方々、大変お世話になりました。


class C
  def m= a
    p a
  end
end

a, b = C.new, C.new

a.m ,b.m = 1,2

面白いよねぇ。

_まさ(Sun Nov 13 14:00:05 JST 2005)

 うううううううううううううううううううううううううううううううううううううう

_30(Mon)

なんだかんだと残ってたのを片付ける。

飛行機、ちゃんと飛べばいいんだけど。

ちなみに、まだ例外は実装できていない。


継続の持たせ方、というのは凄く難しい。たとえば、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。長い。


というわけで、行ってきます。


というわけで、来ました松江。

大変お世話になりました。

肉美味しかったです。

_29(Sun)

やっと酔いが覚めてきた.


例外発生時,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 ぽいぞ.

こんな単純なので,本当にいいんだろうか.

あぁ,ダメポ.考え直し.


例外ハンドリング規則:

  • そのフレームで,PC について rescue_part に該当するものがないか検索
    • あったら,rescue_part を実行
      • rescue_part がきちんと実行できれば(例外を発見すれば)そのまま実行(☆)
  • なければ,ensure_part に該当するものがないか検索
    • あったら,そのパートを実行
  • フレームを一個上に上る
    • もうなければ,VM(スレッド)停止
    • あれば,最初に戻る

☆の部分が出来ない.困ったぞ.つまり,「駄目だったとき,どうやって再検索するの?」という話.

あと,ネストの話も解決しないな.困ったなあ.でも,これはどっちもテーブル操作を賢くやれば問題ない気がしてきた.

「駄目だったとき,もう一度検索やりなおしてね」命令が必要,ということだろうか.どうしようかなぁ.例外情報は,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 は嫌いだ.

今回もパーミッション関係.

_maeda(Sun Aug 29 17:02:37 JST 2004)

 Javaの文が中断(abrupt termination)するときには原因(reason)がひとつあります。例外とかbreakとかreturnとか。finally節が中断したとき、以前の原因は捨てられます。

_ささだ(Sun Aug 29 18:31:28 JST 2004)

 やっぱそういうものなのですか.

_shiro(Sun Aug 29 19:08:47 JST 2004)

 「作りかけの引数フレームは継続の一部」ということですな>SPの巻戻しの調整。

_ささだ(Sun Aug 29 21:45:59 JST 2004)

 たしかに.

_28(Sat)

数字のペア(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行ほど溜まってる.まずいよなぁ・・・.


というわけで,とりあえずイテレータまで行ったけれど,この後どうしようかな.


誰かチェックしてくれないかのぉ.


あー,眠い,眠い,眠い.


酒飲んで酔っ払い.

_ym(Thu Sep 02 11:55:12 JST 2004)

 i = 1;3.times{|i|};p i;は2じゃないですか?0,1,2で。1となるべきか2となるべきかが微妙だ、って意味ですよね

_27(Fri)

最近やっと 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 へジャンプする命令となる。

  • 本当にこれで問題ないか?
  • この方式に新規性はあるか?(なさそう)
  • メソッドのインラインキャッシュをこれ(バージョンによる管理)でやったとき、前考えたときはなんかまずいことがあったような気がしたんだけど、なんだったかなぁ
  • 定数アクセス以外の適用範囲は?
    • 定数畳み込みなんてのはできそうだ(1+2*3+4**5/6 なんてのは、滅多に評価結果は変わらないだろう)
      • ・・・って駄目か。副作用を持つ可能性がある
    • ということは、副作用を持たず、評価結果が滅多に変わらない部分にしか使えない
      • やっぱり定数にしか使えないかなあ
    • once 修飾子かなぁ
    • VMのバージョンにも2種類があって、Fixnum#+とかが書き換わったら、こいつらを全部無効にしてしまうというのはいいかもしれない。つまり、特定バージョンになったら、自分自身の命令を nop に塗りつぶす、とか

どうしたもんかなぁ。他の用途が思いつかないぞ。


現状では、各メソッドフレームなどに、$~, $_ の領域を確保している。これはあまりにも非効率的かも、とか、今後メソッドローカルフレームが増えたとき困る、という問題から、こいつら特殊メソッドローカル変数は別オブジェクトに押し込むのはどうだろうと考えている。なんとかなりそうだけど、その特殊なメソッドローカル変数へのアクセサをどうするかが、今度は悩みの種になる。もう命令は増やしたくないぞ。でも、通常のメソッドローカル変数アクセサの中で if で分岐、とかはもっと嫌だなぁ。


というわけで、あまりに特殊な命令が増えてきちゃったんで、special 命令でも作ろうか検討中。operand で動作を変更。頻発しない命令に限る。

たとえば、popcref なんて命令を今しょうがなくくっつけちゃってるけれど、こいつとか。setinlinecache も候補。getspeciallocal, setspeciallocal も、こいつでいいでしょう。


とりあえず、懸念のひとつだった定数(またはclass/moduleまわり)はかなり厳密に作ったので、次は iterator。


しかし、来週、再来週と目が回りそうだ。

  • 8/30,31 松江
  • 9/2,3 川崎
  • 9/4-6 愛知
  • 9/6,7 岐阜
  • 9/9,10 滋賀

途中でプレゼンを何個作れと。


情報科学若手の会は、どんな議論ができるのか楽しみ。ふふふ。


i = 1
Class.new{
  p i
  p self
}

で、self が定義中のクラスに置き換わるって、気持ちはわかるんだけどすげー気持ち悪い。どうやって実装するかもわからない。

どうしたもんだろうねぇ・・・。


SICPに遅れないようにと思って学校に来る.泊まる.

・・・SICP家に忘れてきちゃった orz


しかし,さすがに久々に書くと,伸びる伸びる.

_24(Tue)

また 気まぐれ工房 から素材を拝借.やはり,綺麗.

_21(Sat)

日記は書かないつもりだったんだけど,感謝をこめて.

RubyConf.2004 のホテルの予約を David A. Black氏にしていただきました.ホテル側といろいろと混乱してる感じだったので,どうなのかなー,とか,私がメールをホテルに出してもなしの礫だったのを見かねて,やってもらいました.

感謝します.

でも,チャットで(私)「まだ何時まで泊まるか決めてないんだよね〜」(D)「もう(予約の)電話中だよ」と返ってきた時は焦りました.早すぎ.

で,D.C.観光のために,まだ2日分のホテルを予約しないといけないんだけど,誰かいいところ知りませんか(おい).やっぱり D.C. 内のホテルは高いんだろうか・・・.


調べてみると,やっぱり高かった orz.

ホステルは安いのだけど,怖いのでやめとこう(臆病者).

皆さんはどうやってホテルを探すんでしょうか.日本の代理店に頼むのかなぁ.でも,それだと一泊$50は軽く超えてしまう.

_出遅れた(Tue Aug 24 09:54:24 JST 2004)

 怪盗ルビィ

_18(Wed)

しばらく日記は書きません.書きたいことはあるんですが,すぐにこっちに逃避してしまう.

_こなみ(Fri Aug 20 19:58:18 JST 2004)

 うーむ,名前選びはけっこう目移りしますねえ。

_16(Mon)

頭が痛い.

クーラーにあたりすぎかも.

_15(Sun)

涼しい。クーラーのついた部屋より涼しい。


こんなプレゼンは嫌だ。

  • IRC経由で議論、観客にはログを見せるだけ

irc ネタ。

_14(Sat)

じいちゃんち(岐阜)にパソコンを用意しろという指令がきた。プロバイダ選びとか、ADSLひくとか、どうしようかなぁ。遠隔、というか代理で手続きってどこまでできることやら。そもそも、請求書とかどうしたもんか。

メモ

じいちゃんたち向けにでかい文字を表示のできる液晶募集。誰か知りませんか。

どうも、普通に売ってる 17inch は 1280x1024 固定っぽい。

低解像度が綺麗に写る液晶はないでしょうか。

うーむ、世のお年よりは何を使ってるんだろう。CRTは重いんだよなあ。


で、私自身もノートPCを新調しようか迷ってるんですが、たまには東芝でも買ってみるかぁって感じで Dynabook の SS/SX がとても魅力的。

Let's Note R3 も、この9時間持つ電池ってのは魅力だなぁ。どうしよ。


あぁ、物欲の夏。


9時間のR3が欲しくなってきた。でも高い。


うーん,SFC行ってみたいかも.


asahi.com : Be on Saturday 「名実ともにエンジニアに復帰しました」

うーん.


昨日の図書館.

  • 月と炎の戦記

今日の図書館

  • クリプトノミコン 1-4

やっと1get.


phpstack - A TCP/IP Stack and Webserver in PHP いやー,馬鹿だねー(ほめことば)


今日は二日前のちくわ揚げを食べました.まだ腹には来ていない.

_@@@@(Sat Aug 14 11:38:20 JST 2004)

 解像度あげるんじゃなくてフォントをでっかくしてしまう解もありかと

_とおる。(Sat Aug 14 13:45:13 JST 2004)

 XPはデフォルトでアイコンとかでかいし。

_ささだ(Sat Aug 14 16:59:19 JST 2004)

 そうかー,解像度にこだわる必要は無いんですね.

_13(Fri)

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侍は一人だからよかったんだよな.ネタ系がもっと大量にあったりしたら,飽きたように思う.

というわけで,まずはオーディションをして,(略).


そうかー,みつきしなりおでまとめるのかー.うーん,そうかー.こっちのが綺麗にまとまってるってことなんじゃろうか.うーん.そうかー.

とりあえず全部がなっとくしとるってのが書きやすかったんだろうか.さすがにまなまなは無理だよなぁ.


隠れ肥満というか、普通に肥満。

あぁ・・・。


今日の古本。

  • 動物のお医者さん 1-12

今日のコミック。

  • デスノート1,2
  • AQUA 1,2
  • ARIA 1
  • 二十面相の娘 1

図書カードをもらったので、つい。

どれもそこそこ面白かった。


今日の市役所。

  • 市民カード

いろんな書類を機械で取り出せるらしい。よくやってるなぁ。

必要なのは印鑑証明だけだったんだけど、ついでに。

_12(Thu)

起きたら11時.駄目人間.

で,今日も豪華にモス.


そういえば,未踏ユースの関係で青色申告しないといけないらしいんだけど,屋号どうしよう.


若手の会,新幹線はやはり高い・・・orz.バスで行こうかなあ.それだと往復7000円らしい.

「ぷらっとこだま」だと,片道 8000円か.バス往復よりも高いが,バスだと異様に疲れるだろうからなぁ.どうしたもんだか.


rubyconf'2004 ,まだ 30人ほどだそうです.まだ pickaxe2 は間に合う!


夕飯はすぱげてぃーところっけとほるもんやきとさらだ.日本酒でかきこむ.

うひゃー.


るるりんがないと仕事に手がつかない.るるりんがあると,仕事をする時間がなくなる.

_新潟のS(Thu Aug 12 23:58:20 JST 2004)

 青色申告の承認申請、期限に気をつけてね。お早目に。

_11(Wed)

臆病ものなんで,早々に流す.


ギリギリ,というかオーバー 賞味期限 7/22 のメンチカツを見つけてしまった.どうしよう.

尊敬する青木さんに近づくためには食べないと駄目だろうか.


しかし,たったあれだけのまとめで数時間かけてる俺って・・・ orz.


口には入れてみたものの(そう変な味はしなかった),飲み込む勇気がありませんでした.チキン(メンチカツだけど).

しょうがないので,一日遅れの丸じゃが揚げを食べる.


松江行きの飛行機を探す.今のところ,一番安くてホテルつき 25000円.二人以上で行けば 20000円になるらしいのだけれど.誰か行きませんか(どういう理屈だ). (中国・四国2日間)


あー,るるりんが見れないと何も出来ないぞ!(うそ)

帰って寝よう.

・・・帰ったら暑いから帰らない.


2時間くらい散歩.帰りはバスと電車.

_hira(Wed Aug 11 00:31:34 JST 2004)

 やるぶでしょ。や・る・ぶ。またnokadaさんにポーズを決めてもらいましょう。やるぶのポーズ。

_t15u(Wed Aug 11 00:35:09 JST 2004)

 LL侍のネタで「Ruby、endがないとPythonですから、残念!」というのは見つけました。「って言うじゃない」の前も知りたいですが。

_ささだ(Wed Aug 11 01:55:01 JST 2004)

 だからぁ,どうでもいいんだってば>読み

_ささだ(Wed Aug 11 01:55:23 JST 2004)

 まつもとさんの発言を引用していたように思います>〜って言うじゃない

_ogino.(Wed Aug 11 04:08:23 JST 2004)

 さすがに油モノはやめた方が...ってもう捨ててるか。

_ささだ(Wed Aug 11 09:34:36 JST 2004)

 まだ迷ってます.

_さかい(Wed Aug 11 16:39:05 JST 2004)

 http://www014.upp.so-net.ne.jp/tetryl/llw2004/ll-samurai.txt > t15uさん

_t15u(Thu Aug 12 00:22:19 JST 2004)

 ありがとうございます。私はm4とhaskellが一番笑えました。

_青木(Thu Aug 12 03:48:27 JST 2004)

 それはさすがに捨てると思う

_10(Tue)

atdot.net、停電後自動復活せず orz


そういえば、yarv ってなんて読むかわかんない、ってよく聞かれるんですけど。

そんな読み方どうでもいいんです。yarv なんて名前自体、どうでもいいんですよ。憶えてもらう必要もないんじゃないかと思います。

もうすぐ Rite になりますから。


と、たまには強気で書いてみたけど、うう・・・。

ちなみに、駄目だったら忘れられる運命なので、やっぱり憶えなくてもいいのです。あぁ、やっぱり弱気。


図書券をもらったのでたまにはコミックでも買うかーと本屋を覗いてみるも、最近のものがよくわからないので断念。どうしたもんか。

_9(Mon)

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分でロゴってのは,実はすでにお願いしていたりしたのでした.というか,出来てた.


で,未踏ユースのプロ管の人に奢ってもらって飲み.ごちそうさまでした.いろんな話が伺えた.

_ogino.(Mon Aug 09 12:44:41 JST 2004)

 Rubyのポーズ見たいー

_ささだ(Mon Aug 09 23:13:30 JST 2004)

 さすがに酔っ払っての所業をさくっと公開はできませぬ.

_t15u(Mon Aug 09 23:46:27 JST 2004)

 LLW見に行かなかったことの最大の悔いはLL侍見られなかったことです。どなたかどんなネタだったか教えてください。

_ささだ(Tue Aug 10 23:21:30 JST 2004)

 私もあんまり覚えてません。ごめんなさい。

_とおる。(Wed Aug 11 10:44:57 JST 2004)

 あ、漢字が違います。久井です。まぁどっちでもいいけど。OpenGL のレンダリング結果をコマごとに xwd で画像ファイルに落として、あとでつなげて AVI ファイルにしようとしたんだけど、なぜか全部終わる前に X が固まってしまう。途中まではちゃんとできてるので、X の不具合かなぁ。LL Magazine に LL 侍の DVD をつけたら、馬鹿売れしそう。(一部で。)

_ささだ(Wed Aug 11 13:47:21 JST 2004)

 うあー,失礼しました>久井さん

_8(Sun)

やっとネタを思いついた。


昨日、頑張って会場に辿り付きたかったなぁ。

地図を印刷しなかったのが敗因。

・・・20号館を20号線(甲州街道)と見まちがえたのが敗因・・・。

orz


LT、それなりに受けたようで、よかった。

あくまで、それなり。まだまだ修行が足りない。

_7(Sat)

とても眠い。


皆さん大変よくやってくれました。本当に凄い。感動しました(ほっとした、というところもありますが)。

どうもありがとうございました。ちょっと涙腺が弱くなってます。


まだ明日の資料作ってないなあ。どうしよ。


久しぶりに帰宅。2週間ぶり?


会計としてあるまじき失態を犯しました。今後このようなことにならないよう、肝に銘じます。大変ご迷惑をおかけました。


と日記で言うことじゃない。


かずひこさんに、「Rubyを50倍速くしたらNaClに入れてあげるよ」と言われた。NaCl への道は遠い。

てか、一般的に、50倍速くするってのは、Cで書くよりも相当速いものを作らないといけない気がする。

例を特定させてもらえば、なんとかなるような気はする。でも、一般解ではない。

(解答:誰かを納得させる例(の集合)について、それ(ら)を速くする)

_shugo(Sun Aug 08 00:08:06 JST 2004)

 む、いつの間にかずひささんに人事権が。

_かずひこ@会場(Sun Aug 08 13:37:13 JST 2004)

 きゃ〜

_6(Fri)

生徒さんたちラストスパート。


この時間に帰ると何もしゃべれません。しょんぼり。

_5(Thu)

いろいろとしょぼーん。


LL weekend のらいとにんぐとーくの私の資料を公開していただきました。興味がある方はごらん下さいませ。

しかし、なんでわざわざあんなに速く提出させたんだろうなあ。納得いかない。


いろいろとご迷惑をおかけしております。申し訳ありません。

_tokuhirom(Fri Aug 06 00:28:14 JST 2004)

 速めに期限を設定しておかないと集まらない、ということではないでしょうか>LLW

_ささだ(Fri Aug 06 09:03:28 JST 2004)

 どうなんでしょうねぇ。

_4(Wed)

新宿のお店どこがいいんかなぁ。

しかし、MLみたいなのを立てて大げさにしたのは失敗だったかもしれない。なんか、まだ何もなかったらしいので、処理系の話ができたのかも。

_MoonWolf(Wed Aug 04 11:19:29 JST 2004)

 Yahooグルメあたりで探してみては?http://gourmet.yahoo.co.jp/gourmet/restaurant/Kanto/Tokyo/list/area/130004/

_ogino.(Thu Aug 05 01:23:06 JST 2004)

 大人数のごはんって飲みより難しいんだよね。どういうのがいいんでしょうねえ。

_3(Tue)

というわけで、いろいろと不自由な生活が続く。

いや、そんなに不自由じゃないか。部屋にネットワークさえあれば、家より快適(クーラーがあるから)


高校生若いなあ。


私は基本的に落ちこぼれなので、それを決め付けるような会話にはとても心が痛む。なんとかしてあげたい。反論ができない時点で負けっぽいけど、自分のできる範囲でなんとかしたい。

やはり、プレゼンテーション(発表に限らず)がうまい人にいい世の中ということは、どこも変わらない。私には何ができるんだろうか。

_hira(Tue Aug 03 22:21:46 JST 2004)

 やっぱり年齢順じゃなかったっすね。発表順か。

_2(Mon)

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 を初めて使ってみた(予習しておけよ!)。スゲーわ、これは。

_1(Sun)

matzにっきで私の興味がある話題が出ても、議論は私的に興味の無い話ばかり。それだけ関心がないということなのかなぁ。

・・・何も言いようが無い、ということかもしれず。


帰宅。

体中が痛い。

_まつもと(Sun Aug 01 20:51:12 JST 2004)

 わたしももっと面白い(技術的な)議論がしたいです。つまんない日本語の話(とかしたくない。

Sasada Koichi / sasada@namikilab.tuat.ac.jp
$Date: 2003/04/28 10:27:51 $