[就職活動ですか?酒井さんのように優秀な若者は、ドクターに行かれたほうがよいと個人的には思えます。[貴兄と一緒に学んでみたいものです。歳をとり頭が錆び付いていますが。[ありがとうございます。今の学ぶことへの感動を忘れずいて頂きたいと願います。[個人的には就職は楽しいと思う。arinoさんの日記を読んでいて「水を得た魚」というかそんな印象を持っていました。Ruby-GNOME2のコールバック周りを少し整理Rubyと関係ないネイティブスレッドからコールバックが呼ばれた場合にはRubyのスレッドに転送してから実行すべきなのだが、その部分がGRClosureにべったりだったので、分離してRuby-GNOME2の他のコールバックの処理でも使えるようにしてみた。これまでのコードではコールバックの転送を待っているスレッドで受け取ったコールバックをそのまま実行すると、その内部で更にコールバックが発生したときにデッドロックしてしまうという問題があった。これを回避するために、受け取ったコールバックの実行は新たに生成したスレッドで行うようにした。スレッドの生成が相対的に重い1.9では特に重いはず。スレッドプールを作ってスレッドを使いまわすべきか。[ruby-dev:31166])ので、コールバックの側で現在のスレッドがRubyのネイティブスレッドなのか判別できず、たとえ現在のスレッドがRubyのスレッドだとしても転送しなくてはならなくなっている。なんとかならないのかなぁ。Lock)を保持しているのなら、そのまま呼び出したい。現在のスレッドがRubyのネイティブスレッドで、もしGVLを手放しているのなら、GVLを再び確保した上で、そのまま呼び出したい。......と書いたが、[ruby-dev:31162]で落ちるので、1.9ではまだ試せていないのだった。MutexとかめんどいRuby-GNOME2のコールバック周りをいじったときに、久しぶりにMutexやConditionVariableを使ったコードを書いたのだけど、面倒くさいな。MVarくらいあれば良いのにと思ってしまう。サンタクロース問題お約束ということで、サンタクロース問題に挑戦してみた*1。].タイムアウト節を持つreceiveを使うことで、指定した時間だけ待ったり、優先順位付きの受信をしたりといったことが出来るのが少し面白かった。それから、プロセスのリンクやモニタのような機能は、他の言語の並行処理でも結構欲しくなることがあるので、これが組み込みであるのはいいなぁ。出てきたので読んでみた。関数はカリー化されているとはいえ、実際に実行時に一引数渡して関数を返してまた一引数渡して......なんてやっていたら遅くて仕方がないので、実際には引数を出来るだけまとめて渡している。一方で、複数の値を返すときにはタプルで返すように書くけれど、実際にタプルをヒープ上に確保してなんてやっていたら遅くて仕方がないので、これも出来る限り複数の値を直接返すようにしている*1。それに出来るだけ非ボックス化して渡したり、他にも色々あるのだけど、こうした呼び出し規約の最適化をGHCは非常にアドホックな形で行っている。導入し、そうした最適化を安全かつシステマティックに出来るようにしようという話。名前が示すように正格な言語で、また関数が多引数・多出力になっている。いった感じの型になる。Bool}のような型になる*2。以下では表記をわかりやすくするため、引数・返り値が一つの場合には山括弧は省略することにする。すると、例えば以下のように呼び出し規約を型で書き分けることが出来る。丸括弧で囲まれているのはヒープ上に確保されたタプルを表す単一の値の型。変換して、その上で各種の最適化を行うのだけど、型として違いがわかると確かにわかりやすい。現在のGHCでは行っていない。関数引数のarityの変換するようなwrapperへと変換するもの。これは従来の動的なarityの検査*3の代替になりうる。arity不明な関数を呼び出す際に、関数呼び出し側で動的に関数のarity情報を取り出して、引数が足りていたらarityに基づいた呼び出しを行い、足りてなかったらPAPクロージャを作成する。(はてな版)日記は現代の病です。読み過ぎ書き過ぎはあなたの健康を害する恐れがあります。2.2.10-p489。