語られなかった言葉は消える
例えどんな思いがあろうとも
大学時代(というほど離れてないか)の友人とレオナルド・ダ・ビンチ展に行って、その後長々と話をする。Rails とか Scheme、Haskell といったプログラミング関係の話から研究開発、政治の話まで幅広く。今度会うときまでにはただ興味があるんではなく、知っているという言語が増えてくれればいいんだけど……。
[topic:Haskell、P2P]
Winny の技術 (Amazon) 読了。最近セマンティック・ウェブのための RDF/OWL 入門 (Amazon) とか恋するプログラム - Ruby でつくる人工無能 (Amazon) (の一部)とか Hacks シリーズとか、これを発売したタイミングで先に読んどけばなー、と思ったことが多かったので当日のうちにいっきに読み終えてみる。
考えていたのはこうだったけど実際にやってみたらこうだったというような試行錯誤や失敗談といった開発の生の姿も語ってくれているところが良いなあ。開発を続けられていればこうだったのにという悔しさがにじみ出ているようなところも含めて、開発話に興味があるだけでも読む価値はあると思う。Winny を使ったことがないけどネットワークを学んだことがある人のみならず、Winny とかを使ったことがある人の基礎知識がどの程度あるか知らないけど、まあ、新ネットワーク思考 (Amazon) などのネットワーク科学の読み物を読んだことある人なら、ネットワークの初歩をきちんと学んでなくても読めると思うので、P2P の技術的な側面について語るときに基盤になる良い本となるだろう。プロトコルの書き方さえ分かっていればクローンが作れるぐらいの詳細が載っているわけだし。
この本で対比されている Freenet については fhc という Haskell での実装がある。バージョンは古いし、一部 procmail とか Perl とかに頼ってて Haskell でフル実装されているわけではないけど。また、MetaInfo を扱うところまでで開発が止まっているものの darcs get http://www.scannedinavian.org/~shae/combinatorrent/ で取ってこれるあたりに Bittorrent の Haskell での実装の作りかけもある (stringToOctets やバイナリから Octets を直接データとして読み出すための Utility 関数がライブラリに用意されていないためか、The Haskell Cryptographic Library の Data.Digest.SHA1 を使うんじゃなくて自前で持たせているけど)。というわけで、Haskell で P2P に興味のある人はプロトコルのフォーマットを書いて実際に Winny を実装してみる他に、これらを弄ってみるのも良いかもしれない。そういえば darcs に DHT を実装しよう、っていう話はどうなったんだろう？
今日は圏論勉強会に行ってきました。
CodeFest 京都に参加するために前日の 13 日から出かける。Mac を持って外に出ているため丁度良いと、バージョンアップして RELAX NG 対応になった(結局やりたいのは他のアプリでも使用できるよう情報をダンプすることなので、Haskell2RelaxNG や RelaxNG2Haskell、もしくはそれらの代わりになるものが出てくれないと主流派の HaXml より良いとは言い切れないのだけど……) Haskell XML Toolbox を入れ直してついでに動くかどうかテストしていたところ、先日のコード変更の結果 Mac の GUI で実行すると落ちるようになってしまっていたので修正、という具合に予定のハックに入ってない気がかりになりそうな問題は前日のうちにつぶしておく。いや、Haskell XML Toolbox 自体に Windows では関数によっては local にある file をうまく扱えないバグがあるのが未だに残っているところとか気になる部分はまだ残ってるけど、Windows は持って行ってないし……。
当日は wxFruit に GLCanvas をくっつけるところまでは単なる作業なので淡々とやっていけば良いので順調に進められていたけど、GLCanvas がきちんと Reactive に動いているかどうかテストするための OpenGL プログラムを書く段階で Arrow notation 内での型や Yampa に対する理解の浅さから躓いてそれから半日ほど試行錯誤することに。……やっぱりこれも慣れなんだろうなぁ、Monad がきちんと分かるようになるまで苦戦していたように。GLUT のサンプルから取ってきたため OpenGL.flush していなかったので最初全然 Reactive でなかったけどどこに問題があるのか気づかなかったとか、そういうあたりのミスに気づくにも時間がかかってしまって、結局 Pan 自体を実装するには至りませんでした。割り切ってとりあえず Pan の画像を表示できるという状態にしてしまえば良かったかな？ そうすれば今回行く動機の共同作業はできなかったという事態は回避できたかもしれない。まあ、いずれにせよ Yampa を使いこなすのは避けては通れない問題なので、この書き方で書けるということが分かっただけでも収穫があったと信じても良いのかな？
さて、関西オープンソースまでには大っぴらに見せれる段階まで作れるだろうか？
実はまだ関西オープンソースに参加するかどうか迷っていたのだけど、結局 CodeFest まで Pan のハックにほとんど手をつけてなかったように締め切りを近くに設定しておかないとやる気が出せないなと思い、プレッシャーをかける目的で発表者側として参加することにする。ただ「去年の経験上、少ない時間で Reactive Programming の背景を語るのは無理がある (LL Weekend プレゼンテーション資料 (PDF)) ことは分かっているし、IORef とかをできるだけ排除して最小限にできるとかソース見せて比較するのが一番良いんだろうな」と、そういうことを考えると、Reactive Programming によるアニメーションをできるようにしただけに止めておいて現在の IORef の駆使に忠実に従って Pan(ic) をベタ移植するというのではなく、しっかりと特徴の見えるようにコードを書き直す必要があるけど。
まあ、それも勉強のうちということで頑張ろう。Yampa は入っている関数一覧を見てもらえれば分かるけどこれ1つで本が書けるんじゃないかというライブラリで(その本がないために)難しいところがあるけど、Reactive Programming になっている方が手を入れやすいってことは少なくとも実感できたし。
[topic:著作権]
のまネコ問題の時はうっかり気づかずにいたのですが、構図の(トレス？による)パクリが問題が回収騒ぎになってしまった件について疑問を呈している意見およびそういったことに義憤を感じて祭りとしてしまうことへの疑問を読んで、ようやく、ああ、これは Lawrence Lessig が コモンズ (Amazon) や Free Culture (Amazon) 等で散々話題にしてきた著作権権利意識による弊害がついに大衆のレベルにまで蔓延してきたということだと気づきました。権利者達の日頃の啓蒙の賜物ですね。
これで著作権の有効期限が発行から10〜20年であれば、今ががちがちに厳しくてなんでもブラックにしてしまったとしても期限切れは眼に見えているのでそのうちどうにかなるのですが、死後50年なのでそうもいきませんし。
ついでに、2ch に関して。あれだけ大きくなってしまったものは、もはやマスメディアやマスコミの一種として認識した方がいいですよ。実際、(祭りに代表されるような)それに似た性質も持ってしまっていますし、それだけの力もありますし。
今日は RHG 読書会。
今日は他にも勉強会などが色々ありましたが、『計算機プログラムの構造と解釈第二版』を読む会II第三一回の方へ行きました。compiler を書いたりしたことはないので、compiler の気持ちになって考えるやり方がなるほどという感じでした。contiuation の関係で見てきたことのある話題だけど、実際にやっている段階にならないと頭に入ってきてなかったんだなー。
当日中にメモらなかったせいで、昨日と今日どっちの飲み会で話したか分からなくなっている話があるなぁ。こういう話はバラバラに書くよりも Wiki にまとめておいた方が良いと思うんだけど……さて、どうしようかな？ とりあえず Wiki の方に「あの話どうなったの？」と書いてあれば書きます、以上。
今日の GUN×SWORD はどんなネタ回を持っていようが叶わない本物がいなくなったおかげで、自主規制そのものをネタ化を視聴者に印象付けることに成功していますね。それといくら人が集っていくという予感が語られていたとはいえ、エルドラ V がここで合流して一気に大所帯になってしまうのは意外でした。
[topic:Haskell、Reactive Programming]
どうなってるか気になっている人もいると思いますので、現在の状況を書いておきます。
まず、CodeFest で使えるようにした OpenGL による描画を使い、pixel に直接画像を作成して(無駄に) OpenGL で pixel をただ表示するという Panic 方式での描画はすぐに実現しました。あとは Yampa の使い方が分かってさえいればいいので、これで wxFruit に実装されている範囲内のイベントに限り、Pan による Animation を Reactive Programming で記述したいという目標自体は実現できました。マウスのクリックに反応したりしないのが不満ですが、wxHaskell はイベントハンドラにイベントを設定するようになっていて現在の生の状態を知らせてくるようにはしていないため、知らせてくれる関数が見えるように wxHaskell をハックするか、イベントハンドラに登録できるように工夫をする必要がありそう、ということで後回し。すっかり薄れてしまった Arrow 及び Yampa の復習をする必要性を感じていたのと、Pan で 250 * 150 以外の画像を描画できなかったり Windows で Anti-Alias なしの画像を描画しようとすると落ちるというのは明らかに問題があるので、そっちに先に取り組むことにしました。
バグはそれぞれ、GLCanvas をくっつけるためのコードに配慮が足りなかったのと、mallocBytes の所在を決め兼ねていて暫定的に毎 Action mallocBytes させていた部分で、Panic の resize で指摘されていたように二度目以降 mallocBytes する場合に Height * Width * bytesPerColour ではなく Height * (Width + 1) * bytesPerColour させなければいけないという微妙な問題がある部分で、とりあえず直したので今は問題なく描画できます。
で、読書会の2日間の行き帰りで論文を読み直して復習したりしたため、色々と試すのに使った余計なコードを整理しさえすれば Panic と Reactive Programming による現在の実装を比べつつ優位性を語ることはできます。あと、Recurrying を Recursive と勘違いしていたのを見つけたり。さて、発表に重きをおくか開発に重きをおくか……？ 開発のモチベーションを上げるための締め切り設定なのでぎりぎりまで Pan に近づけるように取り組んでいった方が開発にとっては良いんだろうけど、今の状態でも十分に説明は可能なことを考えると BOF の成功のためには公演のやり方を考えて、コードを書くにしてもそっちを焦点に当てたサンプル中心な形でやっていった方が良さそう。どこでバランスをとるかな？
GHC-6.4.1 の Windows 版のバイナリが更新されていました。以前指摘した問題点がそこそこ直っています。Pan 関係でのバグや c のソースのあるディレクトリをうまく使えないというのは残っていますが。
[topic:Haskell、Reactive Programming]
さて、結局関西オープンソースではなく、Haskell 同好会にのみ出席するという形になってしまいました。
Yampa には embedSynch という、与えられた値の分内側での処理の実行頻度を下げることで外側での実行から処理のタイミングから独立させるという役割を持った関数があるのですが、使い方が載っていないため外側で更新される値を取ってくる方法に頭を悩ませてぎりぎりまで格闘した挙句結局目的は達成できず、行きの新幹線でプレゼン資料を作る始末。完全に準備不足でした。Reactive Programming を語るにはコードとデモを一対一対応させてこう使えると語るのが一番なんですが、サンプルを用意するだけの時間が確保できてなくて今やっているプロジェクトの背景を説明するだけのものに留まり、Reactive Programming とは何なのか説明するのを完全に忘れてしまう始末。(Haskell 同好会 BOF でのプレゼン資料 (Keynote) (PDF 版))
まあ Haskell 方面で、現実の問題解決するのに IO Monad をベタで使う以外のやり方を試みている人がいるよと言うのが伝わっていれば幸いです。
あとは 5分とか10分とかだとどうしても説明が荒くなるので、じっくり準備するだけの余裕があるときに本格的なプレゼンをやってみたいですね。Haskell 同好会の今後の活動として、Arrow の勉強会をやりたいという意見がありましたし。
色々とちょうどよい時期だったので、今日から始まる Real-Time Rendering (Amazon) の読書会に参加しました。私の本がまだ届いてなかったし、読書会は初めての方が主催者の初回だったので、ペースをみるぐらいの結構軽めの感じの会でした。今のところ会にかける時間は短くて、家で事前準備をみっちりやっておくタイプの会を指向しているようです。
[topic:C++]
積読状態の More Exceptional C++ の内容の一部に触れているらしいので、翻訳された C++ Coding Standards - 101のルール、ガイドライン、ベストプラクティス (Amazon) をさっさと読んでみる。
Effective シリーズ及び Exceptional シリーズを全く読んだことのない人が始めに読む本としては最良の一冊だと思う、次に勉強すべきものを見つける手がかりとして Reference が充実しているし。上級者にとってはもっぱら Reference としての使い方が中心になりそう。より深く勉強するための資料への Reference という意味でも、手元に置いといてさっと引くための Reference という意味でも。もちろんコーディング標準やそれを破るべき時を決める際の基準としても役に立つ。特に、0項目目の"些細なことにこだわるな(何を標準化しないか知ろう)"は示唆的だと思う。あと、Boost とか TR1 とか言ってくれるのも嬉しい。
ただ、Reference に挙げられている資料の大半に日本語訳がないのがどうにかならないかな？ 日本語訳があるのとないのとでは読むスピードが格段に違うし。訳者はこの二人のコンビでこの出版社なんだから、せめて Exceptional シリーズだけでも訳して欲しいんだけど。