思惑は相対し
時は非常にも現実を刻む
[topic:Mac OS X、プログラミング]
先月末に届いた Power Book の設定が遅々として進まない。
まず最初に開発環境に関するマニュアルがなかったため、Web を探して初めて /アプリケーション/Installers/Developer Tools/Developer.mpkg を実行( ダブルクリック )して Xcode をインストールする必要があるということを知ったり、ターミナルが /アプリケーション/ユーティリティ ディレクトリ以下に埋もれてたり、Unix の知識を学ぶために Mac にしたので Unix の知識がなくて苦戦したり、root にならなくても sudo su 等で root にしか使えないはずのコマンドは使えるけど、/アプリケーション/ユーティリティ/NetInfo マネージャーを起動した セキュリティ から root ユーザーを有効にしなければ設定できないものもあるという Mac 特有の部分ではまったり。
またあらかじめ何でも入っているわけではないため Fink を利用しているのですが、そこで出てくる疑問もあります。gtkglext など gtk を利用しているライブラリを使用しようと思い Fink 0.7.0 で sudo apt-get install gtk+2 として gtk+2 を導入したのですが、gtk+-2.0.pc というファイルが入っていないため、pkgconfig がこれを見つけ損ねるところで ./configure や make などが止まってしまいます。 gtk+2 はあるのでこのファイルを直接書いてしまおうと思うのですが、このファイルの中身をどう記述すればよいでしょうか？
と mixi で疑問をぶつけてみたのですが、果たして解答はでてくるのかどうか心配。gltglext のバイナリ自体はあるようなのに配布対象に入ってないのは、ここに問題があるように見えるので。
そんなわけで gauche-gtk は未だに入らず fixpoint の導入が間に合わなかったため、仕方なくオープンソースと言語処理系について扱ったオープンソースカンファレンス Lightning-talk の資料は再び PDF で作成することに。しかも、プロジェクターに表示できそうにありません。残念。
[topic:プログラミング、Lisp、Mac OS X]
オープンソースカンファレンス後の懇親会で Ruby の面々に関数プログラミング (Haskell 版)の次のテキストとして書かれた the fun of programming (Amazon) を見せたところ、Origami Programming が何をしてるか気になると言われたのでざっと見て fold と unfold の話だと言ったのですが、"折り紙"という言葉からすると納得いかないと言われたのでそこまで読んでみました。結局のところ fold でデータ構造を畳み込んでいって unfold で広げる様を折り紙に比喩的に例えただけなのですが、ソートアルゴリズムの表現方法を通して fold や unfold による書き直しが出来るんだという内容にもなってますし、fold という考え方を通して stream の哲学を見せているようなところが良いと思います。fold って何って方は C++ の STL の accumulate のようなものをイメージして下さい。関数型言語を使っている人は多分問題ないと思いますが、一応念のために OCaml による定義が高階関数のところで紹介されていることをポインタとして示しておきます。
以下、懇親会後の内容。
Mac OS X で X11 や gtk を使うとなるとあんまりいい顔されないのかな？ どうやら予想通り使っている人は少ない模様。確かに X11 をインストールした上で起動させておかなければならないし、Fink や Darwin ports が要るし、あんまりいい方法ではないというのも理解できる。(それに gauche-gtk のパッケージが用意されているのが分かっていても、本家サイトに大掛かりな解説しかないような Darwin ports には簡単に手が出せそうにない。) 代りにおぎのさんからとある Wiki に Mac OS X の GUI と Gauche のバインドがあることを教えて貰ったのですが、ねるさんの Gauche:ObjectiveCBridge のことですよね。
仕事で使っている PHP の話になっていたので、Curl が Sxmlcnv のようなコンテンツ記述に特化したマクロ埋め込みマークアップ言語として良いらしいという話を振ったところ、それでは Model と View の分離ができていないのではないかという話になって、XP の Web 開発編での XSLT でコンテンツと View を分離できるというのはあまりにプログラマ的な考え方と言われたので、CSS に長く触れてきた身として擁護にまわることに。結局のところ、CSS 3 (の特にセレクタ) + Mozilla 独自拡張 がまだサポートされていないことによる CSS の表現力の貧弱さと IE の CSS のサポートレベルの低さというところに結論を持っていきました。そりゃ、もちろん今の実装でも class を使いまくって頑張ればできるものもありますし、ある程度 class を作っておく必要はありますが、それに頼りっぱなしというのはコンテンツと見た目を分離するというスタイルシートの精神に反するのでそこにまだ到達できていない現在の状況が悪いとしか言いようがないし……
オブジェクト指向とかイテレータとか値のスコープの話とか。認知をやった人間としては言語が思考を規定するというよりは、言語認識が思考を規定するという立場を取りたい。そういう意味で、高橋さんの Ruby 以前のプログラミングに対する認識と Ruby に触れた後のプログラミングに対する認識が変わった一方で、C ではオブジェクト指向の機能がないので値のスコープをどう組み立てたらよいか分からないという意見は参考になった。というのも、関数言語のプログラマーだと関数を first class object (第一級の値) として扱うのに慣れているのでスタイルがまた異なりそういう時にもうまく組み立てるやり方を見出せるが、elisp や Common Lisp プログラマーは setq を使うのに慣れすぎてスコープを考えるということに慣れていないという点があることを同時に思い起こせたからだ。これは言語だけではなく、それを取り巻く環境も思考には重要という一例であろう。その上で、思考をなるべく反映するオーバーヘッドをできるだけ少なくする言語が必要となる。Common Lisp の Object System (CLOS) のことも取り上げて、mixi でも示唆していた C++ にリストをプリミティブな要素として組み込めば本来の generic さが発揮できるという話題も振っておいたけれど、果たして言語はこっちの方向に進化するだろうか？
lightning talk の内容を補完する、先走って仕様ばかり決めていると完全サポートは難しいし、柔軟性が衰えるという話。Sun の Java もフル実装ではないらしい。また、Ruby の良さとしてできちゃった実装を仕様に入れていく柔軟性というのも。(裏を返せば暗黒面を招くことにもなりますが)
新人をペアティーチングで徹底的に指導した果てにペアプログラミングに移行するというアイデアは、受け入れられるか最初からペアプログラミングをはじめるのに比べて実効性はどうかというのは別として、面白いものだと思います。
あとどういう流れだったか全然覚えていないのですが、人が集まれば生産性は平均化されるものだという認識が世の中にはあって、名匠チームを信じていないというような話。これは私の勉強と関係のある分野なので、本来チームというものは生産性をあげることを 1+1 を 2 ではなくそれ以上にすることを目的として組まれるのに実際にはそうなっていないのをいかに改善すべきかという問題意識があってそれを扱った本があるという情報を伝えたり(それこそ XP の目指しているもののはず)、ソフトウェアはそこでしか作られない一個一個が開発であるものにもかかわらず、生産現場のように見ていることがテイラリズムに陥らせてしまっているという話とか。……コンテクストが全然思い出せないので、これ以上有用な文章になりそうにありません。
[topic:プログラミング、Lisp]
Object-Oriented Programming: The CLOS Perspectiv という CLOS から C++ や Smalltalk 等の比較までを扱った絶版の本のコピーを使ってのとても有意義セミナー。Gauche の Object System の元となっている Tiny CLOS では省かれている defgeneric や Method Combination の話が面白かったし、Class Redefine Protocol を実際に使う様子を解説していたのが「ああ、そんな風に」という感じでした。
Method Combination の :around から入って (call-next-method) で引っ張りだした :before、:around、:after と関数を辿っていって最後に返るという動作はアスペクト指向を思い起こさせるものとして、こんな時代からこんなものが入っていたんだと思わされました。
今日は急遽決まったメイド喫茶に行って、メイド服を着るオフでした。いや、メイド服着たの私だけですけど。
ケーキを紅茶といつもの通りゆっくりと味わって食べる。雑談の合間にちらちらとメイドさんの観察。メイド喫茶って、こういうものかというのはだいたい分かったかな？ 今回行った店ではは鈴を鳴らして注文を取るのはなし。
それから9号(女性 M サイズに相当)のメイド服を着ました。着るときの肩と脱ぐときのおしりがぎりぎりの感じ(そう、私はいつもズボンでおなかはぶかぶかなのにおしりのサイズが問題で着れなかったりするんです。「それなら女性用のズボンを買ったら？」という風に今日提案されました。)だったので、10か11号あたりがちょうどいい感じなのかな？ ええと、ここでは写真は公開したりはしませんよ。写真写りがそんなに良くなかったし、そういう輪の中に積極的に加わろうと思いませんので。とは言っても、内輪向けに公開されたり、今回一緒にいたメンバーのページで公開されるのはまた別の話。
それと、その存在を教えられてからずっと気になっていたヘアアイロンなどを買いました。十分に役立つといいんですけど。何人か一緒になってウィンドウ・ショッピングをするのは初めてだったので、それもなかなか楽しかった。実に有意義なオフでした。
その人が私を愛してくれるのだと思った。だから一歩ずつでも、その人に答えていかなければならないのだと真剣に考えていた。でもそれは違って。だから自分の中で育てていたその思いが、失恋の痛みに変わった。そう、気がついたら恋をしていたのだと思う。
後でメールでフォローを貰ったけど、その時のふざけだったという言葉は MtF の私を肯定してくれたことまで否定しているようでショックだった。何よりもそれが嬉しかったから、だから相手に答えていこうと考えていたのだから。逆に言えば、そういう振る舞いさえなければ、私もただのふざけだと思って真剣に受け取ることなどなかっただろうに。だから後でそんな自分を肯定して貰ったことは嬉しかったけど、同時にそれ以上にずるいとも思った。
男の人に振られるのは初めて。MtF といっても嗜好は別に男の人の方にばかり向いているわけではなく、むしろ普段は女の人の方が好きだったはずだからこれでいいのかもしれない。そう、自分に言い聞かせることにしよう。
昨日の突然参加することになった Ac+C'04 翌日ミーティングとは違って、今日はいつも通り RHG 読書会でした。
昨日のミーティングの詳細については……そのうち記事になると思うのでそれまでは書かない方針で。ただ、知っていながら今まで会っていなかった人に会えてよかったとだけ。
紆余曲折を経て付き合うことになって、今日は相手の家で過ごしました。
こんな風に二人でゆったりと過ごすのは、かけがえない時なのだろう。応援してくれている人達もいるし、こんな風に進んでいければと思う。
今日は『計算機プログラムの構造と解釈第二版』を読む会II第二十回に行って、その後相手の家にお泊りしに行きました。
院試に落ちました。あと三つ、あと三つの試みに失敗したら私はダメかもしれない。
そんなことをしていたら大間抜けですが、番号を間違って覚えていたこともあって、受験番号を書き間違えた疑惑を拭えないことが私を不安にさせる。
Franz で今月のセミナーに引き続いて CLOS MOP のセミナーが数回にわたって開かれるとのこと。そこで今度は絶版されていない方の本 The Art of the Metaobject Protocol (Amazon) をテキストとして使うのでできるかぎり用意しておいて下さいと書かれていました。いつか手に入れて読もうかなそれとも読まなくていいかなどうしようかなと考えていただけに入手するよい機会ですが、問題は代引なので手数料がかかるんですよね。そうなると、ついでに他の本も買っておきたいような気が……まだあの本読み終わってないのに。
Google AdSense 入れてみたところ、贈り物関係のサイトばかり表示されてしまう。まあ、贈り物で検索してくる人がそこそこいるようなので、これはこれで正しいのだと思うけど。
下で書きましたが、それよりも親からの圧力強かったようです。新卒を利点として売り出せということで、未踏に通ったとしても就職しろという勢い。バイトじゃダメそう。うーん、確かに一年以上の実務経験を要求する大学院もあるので、就職すれば選択肢は増えるけど……。
[topic:ソフトウェア、プログラミング]
今日締め切りなのでぎりぎりセーフ。Excel の文書は OpenOffice.org があればどうにかなったんですが、Word の文書が見事に文字化けしていたため学校に行って作成しなければいけないのが辛かった。また、せっかく Illustrator CS が入っているにも関わらずメモリを十分に積んでないせいで初期設定を 800 * 600 pixel にしたらメモリ不足で製作した図が保存できないのも痛かった。……サイズ変えても直らないし。おかげでぎりぎりになって第二希望の PM を変えることに。ああ、倍率あがるなぁ。まあ、昨日 IRC で内容を話してつっこんでもらって提案書の記述をブラッシュアップできたのは良かったかな？ つっこみは想定範囲内だったけど、全ての PM 候補で面接があるわけじゃないので書いておくにこしたことはないと思うので。
できれば採択された方が嬉しいけど、採択されるにしろ採択されないにしろぎりぎりまで提案を考えるということは自分が何をしたいのか考えるよい機会だと思う。あきらかにこれなら受けそうという考え方ではダメだ。私も最近まではは XAML や XUL に対抗するものとして Gauche への wxHaskell binding を考えていたけど、それは他の人のためにやりたいことであって自分が本当にやりたいことではないということに気がついて、もっと下のレベルの wxHaskell を使ったライブラリフレームワークを作る方に変えた。これ以上は結果待ちということで詳しくは書かないけど、こうしてもともとマルチメディアアプリケーションが作りたかったという原点に帰ることになった。まあ、昨日の IRC のように身内には内容を聞かせてもいいですけど、日記にはまだ載せない。
懸賞論文とかすんだら結果が出ないうちから作業をはじめてみようと思うけど、大学院に受からなかったことで親からの圧力は強化されるし、採択されなくても外注をするためにはお金を稼いでおかないといかないからバイトする必要がありそうだと思う今日この頃。
[topic:Mac OS X、Scheme]
Mac OS X を利用し始めたのには今のところ Windows 上ではうまく機能しない WASH や Kahua をまともに動かそうと思ったのもあったのですが、いろいろと躓いてなかなかうまくいきませんね。
まず bash のパスに /usr/local/bin が入っていないので付け足さなければ色々と gauche の周りのものが使えなくて不便なのですが、このとき /sw/bin もパスに入れておかないと fink で導入できる様々なアプリケーションがフルパスでないと利用不可になりますし、そのときつい /usr/bin も記述しようものなら色々なものがまともに動かなくなってしまいます。./configure なども動かなくなるので痛いです。ちなみにこのとき最初 make install で入れて Internal Server Error が起きてたのが怖くて、原因をついきゅうするきにもなれなれなくて、gauche-package install Desktop/WiLiKi-0.5.tgz でしか入れてません。また、utf-8 関係の設定がオフになってしまうようです。さらに gauche で slib を使いたければルートでない限りデフォルトで探しにいくところにおけないので、パスをきちんと書いてやらないといけないという点にも注意が必要です。
で、なんとか WiLiKi を導入したものの、ホームディレクトリに data ディレクトリを作って db-path を /Users/XXX/data/wikidata.dbm に設定して 755 のパーミッションを持たせているにも関わらず暗黙に dbm ファイルを作らないのか Couldn't database file to read
と言われます。kahua.cgi だと CGI Error: coudln't open output file
なんですが、これはルート権限を持たせてないためなのかどっちなんでしょうか？ ……と疑問はつきない。絶対本家に Mac OS X 用のドキュメントが必要だと思います。
2004-10-01T09:27:00+09:00追記:Mac OS X の Apache 環境では CGI が新たにファイルを生成する場合にその上位ディレクトリのパーミッションを 707 にする必要がある、というのが問題だったようです。また Finder で下のディレクトリにアクセスするためにもこれが必要です。Kahua の場合、こうすると /usr/local/var/kahua/cgilog や /usr/local/tmp/kahua にかかっていた制限がとれちゃいますし、まだ問題が残っているわけですが。
あと kahua で困るのは /usr/local/bin/ の下にわざわざ kahua を作って実行可能なファイルを置いたり、 Mac OS X では utf-8 の方が望ましいけれど Kahua-web や pdf の生成は utf-8 に対応してないため make check に fail するのを我慢しなければならなかったり、kahua-web.kahua の euc-jp を utf-8 に置き換えた上で文字コードの変換をしなくてはいけないところとか。
~/.bash_profile
export PATH=/sw/bin:/usr/local/bin:/usr/local/bin/kahua:$PATH
export LANG=ja_JP.UTF-8
export LESSCHARSET=utf-8
~/.inputrc
set convert-meta off
set output-meta on
set input-meta on
[topic:ソフトウェア、プログラミング]
HSP に関する議論でまつもとさんがささださんの言語が作りたかったのではないという意見を受けて
実際は彼が作りたかったのは「プログラマブルなツールジェネレータ」くらいじゃないかと
という風に分析しているまでは良かったのだけど、それ以後展開された議論を見て「おや？」って思いました。初めにツールありきでそれに言語を組み込むというアイデアを示しているのだけど、むしろ Ruby とかにライブラリを用意してやってその上に DSL を築いた方が遥かに様々なツールを作りやすくなるのになという判断がすぐに働いたので。下のレベルのライブラリをうまく確保しさえすれば、後は combinator を書いていくことで DSL は簡単に記述できる。静的言語でインタプリタを実装しようという場合など evaluator を作ることが必要になることもあるけれど、それも型をどう解釈していくかという方針を作る必要があるだけで、本質的な方法は変わりません。というように、関数型の考え方にどっぷり使っていれば自然にこんな風に発想してしまって、どうしてわざわざツールに言語を組み込むなんていうナンセンスなことをしなければならないのだと疑問に思ってしまいます。
ブロックをうまく使えるからでしょうか Martin Fawler が Ruby でも言語内 DSL を書けると言っているのですが、Ruby 方面でこれを研究する人はいないのかな？ Ruby 論者はマクロ不要論を唱えるので対立する考え方かもしれませんが。少なくとも、ある言語でうまくできることをそれならばこの言語でもできないだろうかという風に考えるのは、言語の使い方の幅を広げてくれるよいものだと思うのですが……。ちなみに私は Ruby をきちんと知っていないし、それを考えるくらいなら Haskell に手を出してしまうので無理です。必要にかられればやると思いますが。