目が覚めたら11時だった。なんか気の抜けきった生活をしている。 その割には「仕事する」とか言って娘に嫌われたり。
息子の凧揚げに付き合う。 しかし、息子が保育園でもらってきたビニール製の凧は安定して飛ばないのだった。
新聞紙で尻尾を付けてみる。少しだけ安定したが、風向きが変わると墜落する。 義父と一緒に、ああでもない、こうでもないとやっていると木に引っかかったりして。 走り回って息が切れる大人二人。もう駄目だ。
結局息子は、糸を短くして走り回り、自分の後ろで凧を低空飛行させるという遊びを開発する。 うむ、そうか。そういう手があったか。我々には「凧はこうやって飛ばすもの」という先入観があったな。 あれなら電線や木に引っかかる心配もないしな。本人が満足しているならそれでよかろう、 などと話しながらうちに帰る。
子供たちは従兄弟と遊ばせておいて、今日も妻と買い物に出る。 なかなか一緒に行動できないものな。しかし、正月から店が開いていると正月らしくない気もする。 便利だから助かるけど。
正月のご馳走を食べ過ぎて体重が増加する。うーむ。
1024x768以上でお願いします(つまらないジョークはやめなさい)。
今年の目標とか設定するのは苦手なのだが、せっかく日記を付けているのだから、 記録のためにも考えることにしよう。今回は、比較的楽な仕事編。
Rubyについて
原稿について
海外講演について
死んで幽霊になる夢を見た。映画『ゴースト』の設定だな。
死ぬってことは、Rubyのメンテは誰に頼めばよいかな
などと冷静に考えている自分が滑稽だった。
1.8は中田さんやわたなべさんがいるから心配ないと思うけど、 Ruby2はどうしたもんかなあ。
甥っ子が具合が悪く正月から入院という事態なので、姪を預かることにする。
天真爛漫、元気溌剌な姪と、甘やかされ放題の末っ子は相性が悪く、泣かされてばかりいる。 年齢は倍違うのにな。
姪を連れて、安来の叔母の家により、それから米子の実家に。それぞれ正月の挨拶。
夕方には帰る。渋滞を避けようとして、道を間違え伯太町の方に向かってしまう。 が、予期せず白鳥を眺められたりして。
姪はそのまま泊まる。
PC関係のメモに、
Matzにっき で使われてるのはカスタマイズされてるみたい。
と指摘される。そうそう、カスタマイズした時点で満足してしまって、公開してなかったな。
あおきさんのところの最新らしい1.41とマージして、 ここに置く。
主な変更点は
くらいかな。
あと、tdiary.rbのapply_pluginメソッドの正規表現を
r.gsub!(/<.*?>/, '') if remove_tag
から
r.gsub!(/<.*?>/m, '') if remove_tag
に変更(mフラグを追加)しないとfnプラグインがうまく展開できない。
昨日、米子で食べ損ねた小豆雑煮を食べる。
ご存じない方のために:
小豆雑煮とは、潰した小豆を砂糖とともに煮たものに餅を入れたものである。 全国的には「ぜんざい」と呼ばれるものに似ているが、違いは
鳥取県東部地方(鳥取市とか)では、さらに地位が上がるほど砂糖をてんこ盛りにするのだそうだ。 昔、砂糖が貴重だった頃の名残であろう。
急に寒くなったせいか、昨日あたりから体調が悪く、寒気がしたり、鼻炎が悪化したりしたので自宅作業。
とはいえ、今は子供たちも冬休みなので、作業がはかどらない。 家族全員で引きこもり状態。 結局仕事もたいして進まないし。
これではいくらなんでもいかんだろうと、夜は温泉にでかける。 結構寒いのね。
で、仕事が進まないなりにRuby M17Nについて考えていたのだが、CHISEあたりをヒントに
という方針でなんとかなるのではないかと考える。 これだと、たとえば「文字＝コードポイント」という仮定もないのでより広い範囲で対応できるだろう。 ステートフルなエンコーディングにはいずれにせよ対応できないけど(効率上の問題であきらめた方が良さそう)。
もっとも、これだと以前作ったもの(ruby_m17nブランチ)の実装はほとんど流用できないなあ。
課題は
だな。特に前者。 エンジンの自作はできれば避けたいけど、鬼車をフォークするってのもなあ。
以前、リニューアル直後の『日経バイト』に書いたものがWebで掲載された。
一般的な言語論についてまとめて書く機会はなかなかないので面白かった。〆切はきつかったけど。 で、結果としては、歴史的正確さはいまいちだが、読み物としての出来はまあまあではないかと自画自賛。
Citrus Projectの人たちにも聞いてみてはという提案をいただいた。
とりあえず、私の理解ではCitrus Project当面の目標は「正しい」localeシステムの実装にあると思っていたので、 RubyのM17Nはより上位層であって参考にはならないのでは、と考えていた。 それはそれとして、とりあえずもう一度調べてみようと思ったのだが、 このCitrus Projectの現状は私にはさっぱりわからないのだった。
Googleで検索して得られるページは、 かなり古そうだし、メーリングリストアーカイブを見てもSpamばっかりだし。
一応、目標の中に「マルチスクリプトフレームワークの設計/実装」とかあるんで期待したんだけど。
狩野さんのコメントに続き、 曽田さんから丁寧なフォローをいただいた。ありがたいことだ。
いただいた情報に従い調べると、現時点でのCitrusの主眼はiconvの実装と、 wchar_tを用いた処理のようだ。どちらもCSI(Code Set Independent)を目指していて、 興味深い。
今回RubyのM17Nと銘打って実装したい部分は、 「各種エンコーディングを変換することなく行う文字列操作」 なので、直接はオーバーラップしないことも分かった。
ただ、今後文字列のエンコーディング変換についての考察は必須なので、 その際にはCitrus Projectのiconvの実装を｛参考にする、取り込ませてもらう｝ことにしよう。
予約しておいたドラマをようやく見る。第一回目。 なんのことはない『め組の大悟』のドラマ化なのだが、面白かった。 なんかドラマを見ようという気になったのは久しぶり。 前回は『サイコドクター』と『アルジャーノンに花束を』だっけか。
要するに原作付きに弱いらしい。
『FIRE BOYS』については、原作から変えてある点がかなりたくさんあったのだが、 それがどれも自然で気にならない。 落合先生が音楽の先生ってことはスマトラ島のエピソードはありえないのねとか、 「めだかヶ丘」ってことは千石国際空港のネタもなさそうとかは思ったけど。
現場の描写については実際を知らないのでなんともいえないが、嫌な感じは受けなかった。
しかし、毎回火事の撮影ってのはいろんな意味で辛そうだなあ。
追記:
しかし、大悟役の人はもう少し体が大きく見える人のほうがよかったかもしれないなあ。
「今日のリンク元」を見る限り、最近の私のエントリでもっともヒットしたのはMatz版tdiarygrepらしい。お役に立ててなによりです。
「文字オブジェクトは導入するんでしょうか」とのことだが、 いろいろ考えたあげく、素のRuby M17Nは文字オブジェクトは導入しない。
ともさんが欲しがっている「文字」に対する機能は将来的にもRuby/CHISE(のようなadd-on)が提供するものと考えている。文字に対するrequirementは本当にさまざまなので。それに「文字」そのものが必要なことは意外と少ないものだ。
ただ、Ruby M17Nが提供する「属性」を使った正規表現マッチはできればやりたいと考えているのだが、 ただ、現時点では正規表現の実装をどうするかさえ決めてないので、断言はできない。
あ、そうそう。ともさんのコメントには「文字列を code point の列とする」とありました。 ruby_m17nブランチでは確かにその通りで、コードポイントで文字を近似していました。 今度のM17N化では文字列の内部表現も文字の内部表現もバイト列で、 こうすることで複数のコードポイントから構成される「文字」もちゃんと文字として扱えるようになるはずです。
新生ITmediaの記事。そういう愛もあるのね...っていうか、そう来るか。爆笑。
hamadaさんから
ところで、Plankalkuel についてですが、Konrad Zuse が作った Z3 というコンピュータ上で動いていたわけではないのでしょうか？
というツッコミがあった。
確かに、 Plankalkülの設計者でもあるKonrad ZuseはZ3というコンピュータも作っている。 というか、PlankalkülはZ3用に設計されたのだ。
しかし、彼がPlankalkülにかかわっていた1949年までに、 処理系が動いたという事実は確認できていない。 この時点では記法として設計されていたのではないかと考えている。 この時代の技術レベルでPlankalkül処理系が実装されたとはいくらなんでも考えにくい。
Wikipediaには、
It was first published in 1972 and the first compiler for it was implemented in 2000 by the University of Berlin.
と1972年までは存在さえ(広くは？)知られていなかったこと、 最初のコンパイラは2000年(!)に実装されたことが記されている。
参考資料
p.s. しかし、ウムラウトは打ちにくいぞ。
うちの社長と島大の縄手先生と学生さんとで新年会。今年は焼肉。ちょうど今朝、焼肉食べたいな、と思っていたので、ちょうど良かったのだが、食べ過ぎた。おなかいっぱい。研究のこととか、就職活動のこととかいろいろ話したような気がするなあ。
遅い朝食を食べてから、宍道湖自然館ゴビウスへ、 「まみずのカメ」展を見に行く。 もっとも「まみずのカメ」って銘打っているわりには、パンケーキリクガメやアカウミガメなんかがいるんですけど。
ええ、カメをたくさん眺めて、ケヅメリクガメに餌やって、幸せでしたとも。 カミツキガメとかワニガメとかかわいいんだけど、ちょっと自宅では飼えないなあ。 まあ、ライオンやトラもかわいいけど飼えないんだから似たようなものか。
帰りには「ガリバー」でピザ。 子供たちはパスタ。味も量も満足だ。でも、昨日に続き、今日もちょっと食べ過ぎ。
月に一度の会議。今月は行き帰りとも運転してもらったのでラクチン、が、夕べの夜更かしがたたって眠たい。
どうも〆切とかのプレッシャーに弱くて、しかも、弱いんなら弱いでちゃんと仕事すればよいのに、 つい逃避してしまって、ますます事態を悪化させているという。これまでなんどか「事故」なく こなしてきたのが奇跡のようだ。
それはともかく、 毎月のように感じるのだが、人間が集まる組織での問題の本質は、企業だろうが、 宗教組織だろうがたいして変わらない。もちろん表面的には取り扱う問題が違うので全然違って見えるけど。
で、いつもいつも同じような問題に取り組んでいるのに、 いつもいつも適切な答えが出せなくて悩むのは情けないといえば情けない。 ま、個人的には今月はいつもよりはマシな対応が出来たような気がして自己満足。
でもまだまだだ。
帰ったら、姪が遊びに来ていた。今回は娘たちがちゃんと面倒を見たようだ。よしよし。
最近、Matz版tdiarygrepにhistory対応を追加したのですが、 これにCross Site Scripting問題があることが指摘されました。 検索履歴データの表示でサニタイジングを忘れていました。 これはMatz版のみの問題で、あおきさんのオリジナルにはこの問題はありません。
あわてて修正しましたので、 history機能を持つMatz版tdiarygrepをお使いの方は、
<URL:http://www.rubyist.net/~matz/a/grep.txt>
から再取得してください。問題があるのはバージョン番号だと1.33以前(今回は1.33.1)です。
夕べから姪がまた遊びに来ている。「おばちゃんのところに遊びに行きたい」と押し切られたらしい。
で、午前中はキックボードや三輪車などを出してきて遊ぶ。 ただ、ひとり宿題が終わらなくてとりこのされた次女が機嫌が悪い。 涙を浮かべながら割り算を計算していた。
もうちょっと気を使ってやるべきだったか。
あとはビデオを見たり、散歩したり。
夕方は全員でお好み焼きを食べに行く。今回、私はもんじゃ焼き初体験。思ったよりもおいしい食べ物であった。 単価が安い店だったので頼みすぎた。余った。
で、最後、泣きわめく姪を妹に返して一日は終わり。
2.6.1もリリースされたのだが、こちらはようやく2.6.0にアップグレード。
2.4のときにはinitrdがよくわからず移行にずいぶん手間取ったのだが、 今回は割とスムーズに。
気がついた点:
引っかかった点:
解決しなかった問題:
visorとのsyncができない。syslogには
Jan 13 13:05:21 ev usbmgr[592]: invalid buffer line
というメッセージ。
Audio CDがアクセスできない。gripでアクセスすると、
のいずれかになる。
いずれもささいではあるが、無視はできない。
午前中は晴れていたのに、午後から急に雲が出てきて、雷も鳴る。雪が降りはじめる。 少し冷えるなと思っていたら、本格的な雪になり、あっという間に積もってしまう。
夜、息子と風呂に入っていたら、停電になる。停電初体験でパニックになりかける息子。 久しぶりの停電でちょっとわくわくする父。懐中電灯を出してきて、 「大丈夫？」と風呂場に確認に来る次女。停電は数分で復旧した。
うむ、次女は緊急事態に強いらしい。こういう時に性格が出るな。
停電で狂った時計を再設定する。 うちだと給湯器と電子レンジの時計以外は停電でもリセットされないから楽だ。
Amazonから荷物が届く。中身は 『4592132793』。
注文もしていないものが届いたので驚いたが、どうやらウィッシュリストを見た人が プレゼントしてくれたらしい。こんなことは初めてだったのでえらいびっくりしたが、 ありがたい。
千代田区の磯辺さん、どうもありがとうございます。この場を借りてお礼いたします。
さっそく読んだが、面白かった。たぶん、以前雑誌で読んだような気もするが、 改めて読んでも十分楽しい。 「4051062228」を読んで以来、 ロケット関係に少々興味がある長女も喜んで読んでいた。
しかし、宇宙開発がある意味停滞している昨今、こんな本や、 『プラネテス』、『ふたつのスピカ』のようなアニメによって 宇宙に対する情熱を持つ子供がふたたび増えてほしいものだ。 最近、熱く宇宙を語る子供になんてなかなか出会わないものなあ。 私のまわりだけかもしれないけど。
人類が月に行ったのが「ぼくらの生まれるずっとずっと前」だという歌の文句に衝撃を受けたものとしては、 今週発表されるというブッシュ大統領の宇宙開発宣言に(たとえそれが選挙向けのポーズだとしても) 期待したい気持ちが強いのだった。
小泉さんもいかがでしょう。そんな宣言出したら、大いに見直すんだけどなあ。
夜は家族が集まる「家庭の夕べ」。本来は月曜日なのだが、昨日は休日だったし、 姪も来ていたので今日に延期されていた。
レッスンは「御霊の導きに従う」。妻による「小さな細い声に耳を傾けましょう」という話。
活動は長女の提案により「かくれんぼ」。狭い家では大人の隠れるところはなかなかないのだが、 精一杯がんばった。が、当然のようにすぐ見つかる。頑張ったのに。子供たちは喜んでいた。 親も結構楽しんだ(子供っぽい？)。 今回は「家の中限定」というしばりがあったので難しかった。 以前はベランダに隠れるというワザを使ったものもいたのだが。
なんかこのところ生活臭のただよう話題ばかりなんで、たまにはRubyの話を。
Rubyの新実装であるRiteであるが、解決したい課題は以下のものだ。
「組み込み対応」はアプリケーションの一部として Rubyインタプリタを組み込んだとしてもじゃまにならないためのもの。 具体的には「インタプリタオブジェクトを持つ」あるいは「インタプリタオブジェクトの再初期化ができる」ことが必要だろう。GCについての考える必要があるかもしれない。
「スレッドセーフ」では、少なくともpthreadを使うライブラリとリンクしても、 止まったり落ちたりしないような実装にしたい。たぶん、インタプリタオブジェクトはここでも役立つだろう。 また、必要に応じてはgiant interpreter lockで対応せざるをえない部分もあるかも。 yaccを使ったparserはreentrantにできないのも問題だ。 bisonのpure-parserはlexer用にデータを渡せないので、役に立たない。 これをreentrantにするには自分で再帰下降構文解析を行うか、lemonのようなparser generatorを使うか。 GCについての考える必要があるかもしれないのはこの件も同じ。
「高速化」はある意味当然だろう。実行が速くて文句を言う人はいないし、 また現在のRubyの実装が決して効率の良いものではないと分かっているのだから、 ぜひ実現したい。 この件については、いくらRubyが最適化が難しいと言っても、(今が良くないのだから) メソッド呼び出しの効率化とバイトコードディスパッチの改善でかなり高速化できそうな気がしていた。 しかし、私自身の作ったプロトタイプや笹田さんのyarvなどの結果はさほど思わしくない。 実はボトルネックは別のところにあるのだろうか。
去年の5月にこの「Matzにっき」をスタートして以来、アクセス数なんて気にしたことなかったが、 あちこちで話題になっているのでちょっと調べてみた。
2004年1月1日から14日までの計は以下の通り。 これは「Matzにっき」のトップページにGETアクセスしたものの数。
1日 2320 2日 2330 3日 2486 4日 2538 5日 4740 6日 3378 7日 4310 8日 5078 9日 4190 10日 2520 11日 2914 12日 2938 13日 3156 14日 4320
休日にはアクセスが少ないということがはっきり分かる。が、休日でも休まずアクセスする2000人の廃人が。 この14日間の平均を出すと3372.17。多い日は5000アクセスがあるのか。驚異的だな。
もうちょっと心して文章を書くべきかもしれない....うーむ、無理だな。
ひさびさに東京に来たので、秋葉原を歩く。
Thinkpad X40もVaio X505もちょっと物足りない。 いい値段の割に、ディスク容量もCPUクロックもバッテリー寿命も今ひとつ。 これなら少々重いのを我慢してThinkpad X31にした方が良いか。
などと考えるものの、結局、今のマシンを買い替えるほど困ってないなあ、と思い直すのであった。 就職してから、学生時代ほど貧乏ではなくなったのだが、貧乏性は直らないなあ。
あと、Zaurusu C860を眺め、ぷらっとホーム3FでOKIのMini Keyboard Proを確認して終わり。
残りはオフィスで原稿を書く。
この日記を書きはじめてすぐに話題にしたハッカー甲子園こと 「セキュリティー甲子園」だが、結局いろいろ誤解を招くということで 延期になったのは記憶に新しい。
しかし、経済産業省はあきらめていなかったのだ。 今年こそはきちんと企画して、なんらかの方法で「ハッカー甲子園」を開くことを狙っていたのだった。
なんて、言い方はおおげさだが、ちゃんと各方面から意見を吸い上げて実施するべく、 「高度IT人材早期発掘のあり方検討会」なるものを開くことなったそうな。
で、委員としてはJIPDECのプロコン関係者、セキュリティ専門家、それと(いわゆる)ハッカーで、 ハッカーの代表としてミラクル・リナックスの吉岡さんと私が呼ばれたのだった。
いやあ、一年前に冗談のネタにしたものに自分がかかわることになるとは思いもしなかった。 まあ、ワケのわからないものにならないように努力しよう。
検討会ではいろいろな意見が出たが、まだ第1回目で結論は出ていないし、 途中経過をどのくらい公開してよいのかわからないので、ここでは触れないが、 少なくとも有意義な話し合いであったことと、出席者に不勉強な人はいなかったことだけは報告しておく。
FreeBSD上で
ruby -r socket -e 'p Socket.gethostbyname("210.251.121.214")'
が落ちる。理由はこの処理の内部でホスト情報を得るのに、 getaddrinfo(3)をserviceをNULLにして呼んでいるのだが、 FreeBSDでは、この呼び出しがエラーなく終了した後、結果のstruct addrinfoのai_canonnameがNULLだからだ。 flagsにはAI_CANONNAMEを指定している。
たぶん、呼び出し方が悪いのだと思うのだが、man getaddrinfoには
node パラメータと service パラメータのどちらかは NULL にしてよい (両方同時には不可)。
とあるので、許されると思うんだけどなあ。 昨日会った、ゆうぞうさんは「それは駄目だろう」っていうんだけど、 私にはいまいち理解できてない。
mallocにバグなし
という有名なことわざがあるので、間違っているのは自分である可能性はかなり高いのだが、 どう対応したらよいのかは不明だ。
「末松千尋・オープンソース戦略を探る」の13回目。 もう13回にもなるのか。
今回は経済産業省(METI)の久米 孝商務情報政策局 情報処理振興課 課長補佐。先日の「高度IT人材早期発掘のあり方検討会」の立役者でもある。
今回は出雲へ。少々出発が遅れた上に、 出かけてすぐに免許を忘れたことに気がついたりしてあせったが、 道が思ったよりも空いていて、遅れることなく到着。
今月のテーマは「モルモン書を研究する」。 まあ、モルモン書に限らず聖典というのは何千年もの歴史を経て 私たちの手元に届いているのだが、今や簡単に入手できるので、 つい価値や大切さを忘れがち、なんてな感じ。
集会終了後、会計監査。特に問題もなく終了。
「以前当たられたU101はどうされたんでしょうか?」とのツッコミが。
いえ、U101さまはちゃんと自宅でブラウザマシンとして活躍しておられます。 子供たちは最近飽きたのか、あんまり使わなくなってしまいましたが。
ただ問題は、私が求めているものが「開発マシン」にもなるものだということなのです、 U101ではその点ちょっと力不足。贅沢かしら。
追記
VAIO TRは(ポインティングデバイスを除けば)魅力なのですが、Linuxの動作に不安があります。 私にとってUNIX系でないOSでの開発は論外だし。あと、 変則的なスクリーンサイズがプレゼンテーション(けっこうあるのです)の問題にならないかどうかが心配です。
でも、TRがトラックポイントだったらきっと真剣に悩んだと思います。
フリーソフトウェアイニシアティブ 副理事長 鈴木裕信氏こと、ひろのぶさんのインタビュー。
あいからわず難しい言い回しで。超乱暴に要約すると
どれももっともだ。
ただし、評論家としては十分な論だが、当事者としては物足りない。 いや、ひろのぶさんにどうこう言うつもりはない。 当事者の事情を話してもITproのほとんどの読者は理解できないだろうし、 あるいはひろのぶさんは話したのに記者が文章にできなかったのかもしれないし。
が、「Matzにっき」なら多少生の話が出ても大丈夫だろう。
「オープンソースがバブルかどうか」は私には関心がないのでパス。
開発者の環境だが、実際のところどうなんだろう。オープンソースがもてはやされているとはいえ、 企業の視点から本当に役に立つ(あるいは投資したい)ソフトウェアはさほど多くはない。 PostgreSQLなどのDBMSは関心をもってもらえるソフトだろうから、 Bruce Momjianなんかはわりと安泰だ(実際はその彼でも大変なんだけど)。
本当に企業が必要とするようなソフトウェアであれば、そのソフトウェアそのものを「人質」にできるので、 まだ希望があると思う。ひろのぶさんが語っていたのは、このレベルだ。 このレベルについては個人的にはわりと希望があると思う。 もちろん、絶えざる啓蒙が必要だとは思うけど。
問題は、そうでないソフトウェアを開発している人だ。 企業の利益には直結しないけれども、必要なもの、 たとえば開発ツールや、フォント、下層のライブラリなどの開発者にまで 企業の関心が届くのはまだまだ時間がかかりそうだ。
これは啓蒙では間に合わない。こういうツールの開発者は、当面副業モデルを選ばざるをえない。 ていうか、いっそ、オープンソース開発者を一手に集めるような企業が出てきて、 優秀な人材を武器に注目を集めるような真似をしないと社会に対するインパクトがないように思う。
だいたい、
オープンソース・ソフトウエアは，大企業の官公庁向けセクションといった，日本で最もコンサバティブな人たちまでがそれを使ってシステムを構築するようになりました。しかし，開発したり，普及活動をしたりしている側からはどうか。社会的に認知されるようになり，責任だけは増えましたが，待遇は良くなっていない。かえってよりプレッシャが増している。
また多くの場合，オープンソース・ソフトウエアの開発や改良は会社から業務として認められていない。会社から帰って1人で夜中まで開発しているという状況があるわけです。それを「好きだからやっている」の一言で終わらせていいのか。このままでは，日本からの優れたオープンソース・ソフトウエアが増えることは望めません。
なんてことは大きな問題だが、こんな事態になるのは、開発者にも責任がある。
状況が悪ければ声をあげるべきだ。 あるいは転職すべきだ。それを現状に甘んじているから搾取されるんだ。
我々は奴隷ではないっ
万国のオープンソース技術者よ、流動化せよっ。
あと、IPAのアレだが、 スタートアップだけを支援するという意図があるようですな。 まあ、最初が一番大変なので、それはそれで助かるわけだが。 いつまでもお上に甘えられんしなあ。
「数値的なホスト名を getaddrinfo に渡した場合には ai_canonname はセットされないのが仕様であるように見える」んですか。実はそれを確認するのが恐くてFreeBSDのソースに当たれないでいるのです。
とすると、RubyのSocket#gethostbynameのような、通常のホスト名からも数値的なホスト名からも、 区別なくホスト情報を得たい場合にはどうするのが正統なんでしょうねえ、FreeBSDにおいて。
素直にgethostbyname(3)を使うのはsocket.cにあるitojunさんがIPv6対応した時の
/* * NOTE: using gethostbyname() against AF_INET6 is a bad idea, as it * does not initialize sin_flowinfo nor sin_scope_id properly. */
というコメントを見る限り避けた方が良さそうな気がするし。
NokiaがケータイにPerlを載せてしまおうと計画しているという話。
組み込みにはPythonかLuaくらいがせいぜいと考えていたのだが、Perlが載るならなんだって載るぞ。 それこそRubyでも。
「getnaminfo(3)を使えば良いのでは?」というツッコミをもらったが、 私がやりたいのは別に逆引きがやりたいわけではないのだが。 繰り返しになるが、私がしたいのは、 「通常のホスト名からも数値的なホスト名からも、区別なくホスト情報(hostent)を得たい」ことである。 これくらいgetaddrinfo(3)がやってくれてもバチは当たらないと思うんだけどなあ。
これをgetnameinfo(3)を使って実現するためにはどうすればよいのは私にはいまいちわからない。 どういう手順を想定しているのかな。
「それを現状に甘んじているから搾取されるんだ。」とありますが、このあたりについて声を上げられるかどうかは当人の資質もあるんでなんとも言えない気も…。 今いる会社を離れて果たして食っていけるか？ということを気にする人も（たぶん）多いでしょうし、自分の資質や市場価値を過小評価している人も多い気がするんですが（汗）。 クチをあけてまってるだけの人は放置してOKだと思うんですが、自分の存在証明（そして価値証明）を何らかの形で実施している人のところには、そういう向きの会社が積極的にアプローチしてもよいと思います。
まあ気持ちはわかるんですが、
ことを考えると、最初の一歩を踏み出すのは本人以外にはあり得ないように思います。 結果的に「現状に甘んじている」人を第三者が助けることはできないでしょう。
はっきり言えば、 オープンソース技術者は、ヘッドハンティングしなければならないほどには売手市場ではない現実を考えると、 「そういう向きの会社からの積極的にアプローチ」を期待するのは、 現時点では「クチをあけてまってるだけ」とほぼ同じだと思います。
「通常のホスト名からも数値的なホスト名からも、区別なくホスト情報(hostent)を得たい」というのはちょっと変ですか。 もともとIPv6 safeで通常のホスト名からも数値的なホスト名も区別しないgethostbyname(3)が欲しいだけなんですが、 それってそんなに変な要求なのでしょうか。
念のためですが、欲しいのはhostentであって、かならずしも逆引きして欲しいわけではないです。 よって、ゆうぞうさんのパッチは やりすぎのような気がします。
問題にしているのはman getaddrinfo(3)に
The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non-NULL pointer.
とあり、
If the AI_CANONNAME bit is set in the ai_flags member of the hints struc- ture, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null-terminated string containing the canonical name of the specified nodename.
としか書いてないのにai_canonnameがNULLというのはどういうことか、使いにくいじゃないか、という点だけです。 しかもservnameを指定するとちゃんと逆引きしてai_canonnameを与えてくれるのに。 RFCを読めばちゃんと書いてあるのかしら。
「servnameを指定するとちゃんと逆引きして」というのは勘違いでした。 RubyのSocket#getaddrinfoメソッドは確かにそうなんですけど、 内部でgetnameinfoを呼んで明示的に逆引きしてました。
で、結論としては
if the canonical name is not available, then ai_canonname shall refer to the nodename argument or a string with the same contents.
ということであれば、τ森さんや曽田さんのおっしゃる通り 「getaddrinfo(3) が成功して、かつ ai_canonname がNULLなら元の文字列(のコピー)を使う」 という線で行こうと思います。
情報提供してくださった皆さん、どうもありがとうございました。
[ruby-talk:90309]でLotY(Language of the Year)*1として推薦された言語。
関数型とオブジェクト指向とを組み合わせたような言語。面白い。 演算子に優先順位がなさそうな点とか、defの意外な使い方とか、 日常的な使用にはちょっと使いにくいかもしれないが。 人によってはJavaのclassファイルを作る点に注目するかもしれない。 いろんな点でGroovyを思い出させるが、もっとずっと革新的かも。
ちょっと研究してみよう。
*1 LotYとは"Pragmatic Programmers"にあった1年にひとつ新言語を学ぶというチャレンジに応える企画のこと
こんどは国産の言語。
という言語。LENSなんかの影響も見える。
要するにプロトタイプベースのオブジェクト指向言語なのだが、 これも興味深い。これまた日常的に使うには使いやすいかどうか若干の疑問が残るが。
どこでこの言語への参照を見つけたんだっけか？ どこかのWikiだったように思うのだが。
追記: ここだった。
「オープンソースバブル」について書いたら、 ひろのぶさんからツッコミをもらう。 狭い社会になったものだ。
それはそれで望むところなのだが、続きのツッコミが。
あ、そうそう何でこのページを読んだかというと、「オープンソースソフトウェア協会」のことがあったから。昨日、関係者から「Matzにっきになんか怪しい団体みたいなことを書かれているんですよ」と嘆かれて、(後略)
別に変なことは書いてないでしょ。怪しい団体だなんてとんでもない。 私はもう大人ですから、知りもしないことを非難したりしません。
私の知っていることは
だけ。
できたばかりでなかなか揃わないのだろうけど、今後 もうちょっと明確な活動計画が見えれば、賛同できるのではないかと思う。
もし、私がなにか書くことで、関係者にご迷惑をかけたのならば謝罪したい。
追記:
「内閣府認証」が怪しさバツグンというのはあるかもしれない。 オープンソース開発者はあんまりお役所が好きじゃない人が多いような気がするから。
でもね、さっき書き忘れてたんだけど、 オープンソースソフトウェア協会関係者は 嘆くんじゃなくて喜ぶべきじゃないのかなあ。 ここで取り上げられたことはチャンスになると思うんだ。 たぶん、「Matzにっき」経由でオープンソースソフトウェア協会のページを 訪問した人はかなり多いと思う。 で、うちの読者はまさに協会の対象者に重なると思うんだ。 ここできちんと説明して、この人たちを引きつけることは協会の目的にかなうと思うんだけどなあ。
外は雪。市街地でホワイトアウト(もどき)を経験するとは。
来ないなあと思っていた、OOPSLAのproceedingsがやっときた。 船便なのでずいぶん遅れるのだ。
今年は面白そうな論文が一杯ある。やっぱ行くべきだったのかなあ。 OOPSLAは当たり外れが多いからなあ。
読もうと思っている論文
「Traits」はRubyのmoduleに近いものらしい。 ただし、Mix-inよりも優れていると主張しているので、確認しないと。
2003年はGCのセッションが充実していたようだ。
朝、目が覚めたら一面の銀世界であった。夕べのうちにまた降ったらしい。 昨日は割と天気が良かったので油断していたらこれだ。一晩で15cmくらい降ることは、 最近では珍しい。
今日は松江でよかった。これで遠くに訪問しろとかだったら大変だものなあ。 教会への途中、移動の足に不自由しそうな人を二人乗せていく。
集会終了後はお弁当食べてから、教会の雪かき。 まるで雪国のようだ。
sodaさんから情報提供。
実は、私、NetBSD の ARC マシンの移植 (の元となった OpenBSD の移植) の作業に関して、OSSAJ の設立団体の 一つの open technology さんには、大変お世話になって ます。その結果は、現在、NetBSD の sys/arch/arc の 下に統合されています。というわけで、フリーライダーっ てわけじゃないと思いますよ。
そういう情報はどんどん公開すべきだと思います。 やっぱり、貢献しているということは表に出てナンボだと思うんです。 いや、聖書にあるような
という態度もアリだとは思いますけどね。
ただ、知っておいていただきたいことがあります。 私はOSSAJがフリーライダーであるとするつもりも、フリーライダーを非難するつもりもありません。 OSSAJそのものが貢献でありえると考えていますし。
ただ、彼らの現時点での意図が読み取れないという事に対して、不満は持ってます。
「日々の流転」経由。 MITの講義資料。
こんな講義が受けられる人は幸せだ。ちゅーか、もっと勉強しなくちゃな。
Applying Traits to the Smalltalk Collection Classes,
Andrew P. Black, Nathanael Schärli, Stéphane Ducasse
SIGPLAN Notices Vol.38 No.11, Nov. 2003
読んでみた。suminさんのおっしゃる通り、さほど目新しい印象はなかった。 どうも論文中で触れている"Mix-in"がなにか非常に欠陥のある設計のものをわざわざ取り上げているような 気がする。実際に論文で紹介しているようなクラス階層の再構成はRubyのmoduleを使っても、 ほとんど問題なく行えるような気がする。Rubyにはundefもaliasもあるし。
あと、Rubyだとインスタンス変数の宣言が要らないので、Smalltalkのtraitと違って、 メソッドに対して「they cannot directly reference any instance variable」という制限が必要なくなるということが興味深い。
新しいと感じられた点はtrait同士の演算(sum, overriding, inheritance, excluding)である。 もっとも「overriding」はmoduleに対するinclude、「inheritance」はclassに対するincludeであるから、 Rubyにないのは「sum」と「excluding」だ。これはmoduleに追加するメソッドとして検討の余地はあるかも。 「このモジュールからこれこれのメソッドを除いたもの」とか、 「このモジュールとこのモジュールを足したもの*1」とか、 「このモジュールをこのメソッドの名前だけ変えたもの」とかの指定で、 名前のないtraitが作れるのは非常に面白い。
ただ、traitは「a first-class collection of named methods」であり、 そのinclude(論文中ではuses:)は、そのtraitが(現時点で)持つメソッド集合を使うイメージのようだ。 Rubyのincludeはinheritと同様、 シンボリックな関係*2を維持している。 いっそmoduleもtraitのようにしてしまうとラクなんだが、多分許されないだろうなあ。
moduleとは別にtraitを用意する？ それは混乱の元だろう。
あまりにも髪が伸びていたので、ずるずると引き伸ばしてきた散髪に。 ばっさり切って、さっぱりした。でも、ちょっと寒い。
昨日、話題にしたtraitsだが、 論文としてのインパクトはともかく、Smalltalk言語に対するインパクトは非常に大きいことに 改めて気がついた。Smalltalkでは単純継承のために実装の共有が難しい側面がある。 もちろん、委譲を使えば良いのだろうが、やや面倒な側面がある。
Smalltalkに多重継承を取り込んだ試みも報告されているが、成功したとはとても言えないだろう。 実際に多重継承を持つ(広く使われている)Smalltalk処理系は存在しない。
しかし、このtraitsは
Both the Squeak Foundation and Cincom have expressed interest in incorporating traits into the main development stream of their Smalltalk systems.
ということで、もしかしたら本流のSmalltalkに取り込まれるかも。 これがSmalltalkにとって画期的なことではないだろうか。
同じように実装の共有に苦しんでいる(ように見受けられる)言語にJavaがある。 これも単純継承しか持たず、実装の共有に委譲を使っている。 「継承よりも委譲が良いんだ」というのはJavaプログラマがよく言う言葉だが、 Mix-inを知るものにとっては負け惜しみに聞こえる。
さて、Javaにtraitsを加えたら、どのような世界が広がるか。 その時、Javaプログラマはどう感じるか。
仕様の継承としてのinterfaceと実装の継承としてのtraitの両方を持つ言語は、 大変有望な言語になると思うのだが*1。
*1 それがMixJuiceだという気もする
えー、Mix-in評論家のまつもとです。今日はshudoさんからコメントをいただきました。
mix-inの由来はともかく、次の2点がひっかかりました:
- C++にmix-inクラスがある。
- そういったmix-inクラスは、C#のinterfaceと同様の役割を果たす。
1.については、ここでは、多重継承を使って実装を差し込むことをmix-inと呼んでいるのかな？と想像してます。そういう流儀があるんでしょうか。 2.が言わんとすることは、なかなかわかりませんでした。ようやく気づいたことは「ここでは、実装(メソッド)の付加ではなくて、役割(interfaceも可)の付加をmix-inと呼んでいる」ということです。これをmix-inと呼ぶのは、どうなんでしょう？
まず、(1)ですが、元々Mix-inという用語が生まれたのはLispのオブジェクトシステムである Flavorsで、そのココロは「アイスクリーム(のフレーバー)にキャンディやチョコを混ぜ込む(Mix-in)」から なのだそうです。ちなみにそのアイス屋はSteve'sだそうです。だからFlavorsなんですね。
で、そのFlavorsシステムには多重継承はあってもMix-inという機能はありませんでした。 つまり、当時Mix-inとは多重継承の使い方だったわけです。ですから、そこから考えると(1)は必然です。 そういう流儀がある、というよりは、歴史的に見ると「Mix-inだけを目的としたエンティティ(moduleやtrait)」という考え方そのものが亜流なんでしょうね。 私はこの「Mix-inだけを目的としたエンティティ」をRuby以前に見たことはないので、 「実はオリジナルかも」とひとり悦に入っているのですが、実際に調べてみると先行者はいそうですね。
次に(2)についてですが、先程も述べた通り、元々Mix-inは単なる多重継承の使い方に過ぎず、 仕様の継承や実装の継承に限定されていませんでした。というか、Flavorsにはそんな区別はありませんでしたし。 ですから、仕様の継承を行うinterfaceのことをMix-inと呼ぶのは決して間違っていないわけです。 ただし、
These mix-in or capability classes serve much the same role as interfaces do in C#.
とまで断言すると、「実装の継承はどうした」と突っ込みたくなりますが。
ひさしぶり。灌油をしようと思ったら油が切れていた。10人の乙女のうち、駄目な方の5人のようだ。 結局、油を借りてしのいだのだが、「備えよ常に」という言葉を思い出してしまった。
Mix-inについてコメントをいただきました。まず、shudoさんから。
「"Mix-in"は、当初は多重継承の使い方を指す言葉だった」
僕はRubyでMix-inを知ったもので、大変ためになりました。
正確には「当初は」ではなく、現在でも、です。 多分、海外ではほとんどの人はMix-inを多重継承の使い方として理解していると思います。 私はMix-inの啓蒙の意図を込めてRubyのmoduleを設計したのですが、 首藤さんのような人までが「Mix-inといえばアレ」と認識するようになるとは、クスリが効き過ぎたかな。
次にtmaedaさんから。
Metrowerks の CodeWarrior に PowerPlant という C++ のフレームワークが ついていて、PowerPlant では Mix-in が非常に効果的に使われています。
Ruby と比べてどっちが先か、というのはちょっとわかりませんけれども、 PowerPlant も結構昔から存在していたので、もしかしたら PowerPlant の方 が先かもしれません。
Googleで調べると、PowerPlantは1994年からだそうですから、Ruby(1993年)の方が若干古いですね。 いや、1994年は発売された年だから、開発開始はもっと古いのかな。 いずれにせよ、PowerPlantのMix-inは(C++ですから当然)多重継承の使い方としてのMix-inでしょう。 このようなMix-inの起源は上にも書いたようにMITのFlavorsで1979年のことだそうです。 「Rubyがオリジナルかも」と思っているのは「Mix-inだけを目的としたエンティティ」ですから、 直接は関係ないですね。
それから、suminさんから。
エンティティとしての Mix-in に関しては、Strongtalk ('93) の Mix-in ('94-)は Ruby と同じくエンティティみたいです。もっとも Java がらみで Strongtalk の公開は 2002 年までずれ込みましたから、Matz さんの自負を何ら揺るがすものではないでしょう。Strongtalk は Self の人たちとの共同研究成果なので、Ruby と Mix-in 発想の経緯は似たものだったように推察しますが、(Ruby の Mix-in に関しては Self ゆずりということで)当たっていますか？
StrongTalkは2001年にOOPSLAで発表していたのを聞きました。 その時は型についての話ばかりでしたので、Mix-inがあるとは気付きませんでした。 93年ということはこれもRubyとほぼ同時期ですね。
プロトタイプベースのSelfにはクラスがありませんから、Mix-inもないんじゃないかと思います(StrongTalkにはクラスがあります)。ですから、RubyのMix-inがSelfゆずりということもありえません。
私のMix-inについての知識は以下から来ています。
『CommonLispオブジェクトシステム - CLOSとその周辺 -』, Bit1989年1月号別冊、共立出版
5章「共通例題による他の言語との比較」p.84にExplorerのFlavorsの紹介があり、 その中でMix-inについて説明しています。 ほんのわずかの記述ですが、私のSteve'sについてなどの知識はここからです。 書いたのは日本ユニシスの川辺さん。
SuperASCII 1992年6月号
Browsing OOPLという連載の2回目。 「OOPLの最新モデルとしてのLisp」というタイトルでCLOSを紹介していますが、 この中でMix-inの紹介をしています(p.121)。これを読んで初めてMix-inについて理解できました。 書いたのは日本電気の佐治さん。
で、これらの知識をベースにMix-inを啓蒙(強制)するために考えた仕組みが、 「Mix-inだけを目的としたエンティティ」であるRubyのmoduleです。 ですから、発想としては独自ですね。1993年のことです。
sumimさんから衝撃の事実が。
余談ですが、たしかに Self にはクラスこそありませんが、フレームワークとして traits (くだんの Traits とまぎらわしいですが…)と呼ばれるクラスと同種の機能を持つオブジェクトがかなり早い時期(すくなくとも '91)から用意されていて、この延長で Mix-in (mixin と呼称) もあります(と言っても、traits との違いは継承ツリーに含まれるか否かだけですが)。Self の mixin の明確な実装時期は分かりませんが、早ければ traits と一緒、遅くとも '94 には Self システムに組み込まれていたようです。
がーん、SelfにはRubyよりずっと前から「Mix-inだけを目的としたエンティティ」が存在していたのですね。 探せば見つかるだろうなとは覚悟していましたが、目の前につきつけられるとやはりショックですね。
しかし、改めて自分がSelfについて無知なことを露呈してしまいました。Selfについては、
くらいしか知識がありませんでした。Smalltalk系は構文的に面白くないので、 あまり興味を持てなかったのですが、やはり、調べておくべきでしたかねえ。
今日だけで二つも仕事の依頼があった。
ひとつはオープンソース技術者としてのインタビュー。翔泳社から。 『SEの現場』2004年版のためだそうだ。
もうひとつは某企業の関西研究所で。やはりオープンソースの啓蒙ということでの依頼。
なんかRubyそのものよりも、オープンソースがらみの依頼の方が多くなったな。
深夜、なにげなくNHK-BSをつけたらやっていた映画。フランス語で字幕。
なんだか、みょーな映画で、 登場人物がト書きを読むし、脈絡もなく歌うし、展開はだるいし。 でも、そのみょーなパワーに引きつけられて夜更かしして見てしまう。
しかし、映画が始まって1時間半以上たってから、
ことが明らかになるのであった。いや、もっと早く気づくべきであった。 だって名乗らないんだもの。アーサー王たちがフランス語を話すというのも盲点だったし。 ずっとMonty Python系の不条理劇だと思ってた。鈍すぎ？
道理でロンギヌスの槍やら聖杯らしきものが登場するはずだ。 とはいえ、この時点まで映画のタイトルを確認していないのもいかがなものか。
その後、物語はもう一人の円卓の騎士ガウェインを主人公としてしばらく展開した後、 唐突にキリスト受難のシーンになり、 ガウェインの話も、パーシバルの話もなにもかも投げ出して、 エンドクレジットが始まってしまう。決闘はどうした。パーシーはどうなった。続きを見せろーっ。
謎な映画であった。