結構長い時間の旅であったが、ほとんどを寝て過ごす。 機内の映画は『黄泉がえり』で、実は見たかったのだが、 寝ている間に始まったらしく、気がつくと話が全然わからないうちに終わってしまった。 うーむ。後でレンタルすることにしよう。
日本に着いたら夕方6時。なんだか1日損した気分。 まあ、ヨーロッパだと時差がアメリカの半分なのでまだマシと言えばそのとおりだが。
ヒルトン成田に電気かみそりを忘れていたので、取りによってから、今日のホテルへ。
なんだか時差があるんだかないんだか、よくわからない。とりあえず寝る。
前の夜は弟のアパートに泊まったので、 弟と大学生活と就職について、 伝道中の経験について、 お互いの最近の活動、 人狼BBSについてなど話し込んでから、 次の日(というか当日だな)のお話しの準備をしてたりしたら、 寝たのは3時を過ぎていた。
9時すぎに荷物をまとめて車に積み込んだら、 またPHSを忘れていた。....。
鳥取の今日の出席はまあまあ多かった。 私とステーク会長がステークの責任で訪問していたこともあるし、 よそから訪問してくださった方が何人かいらっしゃったこともあるが、 鳥取支部が全体に活気があるということなのかもしれない。
昨日、今日と続けてバプテスマ会が開かれたしね。
私の今日の話のテーマは「永遠の家族」。 だけど実際には「継続は力なり」という内容だったような気がする。
バプテスマ会が開かれている間、依頼されてコンピュータの再セットアップを。 しかし、Windows98を私にどうしろと。思わずLinuxをインストールしようかと思ってしまった。 とりあえず、サージでだめになったらしいモデムを除いては復旧できたようだ。 もっとも私はたいしたことしてないんだが。
弟のアパートに電話を取りによってから、自宅へ。
寝不足からなんどか意識不明になりそうになったので、 途中コンビニの駐車場で休憩。死ななくてよかった。
そういえば、弟に届けてほしいって言われてた米、忘れたんだよなあ。 忘れっぽいのはなかなか直らないなあ。
最近、Eric Mahurinが一年以上前に送ってくれていたパッチをベースに Array#shiftと#unshiftのパフォーマンスを改善したのだが、 彼がさらに改善できるというパッチを送ってくれた。
だが、このパッチかなり規模が大きいうえに、 ベースになった時点と現在とでarray.cが相当変化しているので 取り込むのが大変。
一通りのマージはすぐに済んだのだけど、 実行するとSEGVするのだよ。どこにバグがあるのやら。 実際にコミットされるまでにはずいぶんかかりそう。
しばらくはstgのパッチスタックに積んだままかな。
Linux開発者にえらい不人気なGPLv3の話。
しかし、Afferlo GPLもどきの条項を含むとかいう噂とか、 DRMや特許についてえらいドラスティックな条文を含んでいたドラフト1と 比較すると、現在のGPLv3ドラフトはだいぶおとなしい気がするのだが、 それでも「危険」なんだろうか。
どっちかっていうとLinusとFSFの(やや感情的な)対立に 他の開発者が同調しているだけのような気がするんだけど。
ま、私自身もGPLv3を読み込んでないんで、 偉そうなことは言えないんだけど。
この時期になるもまだ詳細が未確定で、 ショーストッパーになりかねないM17N開発を加速するべく 開発会議を開催した。
ほんとは松江でとか思ってたんだけど、 結局秋葉原ダイビルで。
参加者は、私、ささださん、akrさん、なかださん、mputさん、 Martinさん、青学の学生さん。
で、最初の議論は、最近主流っぽいUCS(Universal Character Set)モデルを 採用するか、日本の伝統的文字列処理の延長線上で(ある意味、茨の道)なんとかするか という話。結局、後者で頑張ることに。
で、伝統を尊重して
エンコーディング情報を使うメソッドは
となる
これは議論していないんだけど、JRubyなどでこれをどう実現するかと考えると
とすればいいんじゃないかな。
追記
成瀬さんからコメントをいただいた。
すでに世界がUTF-8で統一されつつある今、UCSでもCSIでもそう変わらなかったりはするかもしれませんね。
UTF-8はともかくUnicode系では統一されつつありますね。
> (optional)ASCIIの範囲内しか含まない文字列のエンコーディングはASCIIになる
これを optional にするのは危険な気がするのですが、互換性とか大丈夫ですか。
あ、ここでのoptionalというのは「現状の実装ではASCIIにしてる」が、最終的には分からないと言う意味です。1.8との互換性の問題はないでしょう。JRuby的には難しそうなので、なくした方が良いかもしれません。
> 二つのエンコーディングが等しい時→そのエンコーディングに基づき処理
> 二つの文字列内容がASCIIのみの時→ASCIIエンコーディングで処理
> それ以外→エラー「一方のみASCIIのとき→もう一方エンコーディングで処理」ですよね？
そうですね。
> primary encoding(仮称)
まずこの「primary encoding」が指す対象が何かを決めた方が決めた方がいいように思います。
上でも書きましたように「明示しない時の入力のエンコーディング」です。 それ以上でもそれ以下でもありません。
スクリプトのエンコーディングはmagic comment(pragmaという言葉は使わないことにしました)で 決まりますが、primary encodingとは関係ありません。
なお、[0x82, 0xA0].pack('C*') は BINARY でしょうか。
packの結果はBINARY(ASCII)です。前にもどこかで書きましたが、 実用上の観点からASCIIエンコーディングとbinaryは区別しません(が、8bit目が立っているASCIIエンコーディング文字列は7bitの特別扱いを受けません)。
> primary encoding(仮称)はUTF-16で固定。UCSモデル
ここでいう「primary encoding」は何に関わるのでしょう。String#encodigが常にUTF-16になるという趣旨だと解釈します。
それは違うのでは。primary encodingはあくまでもデフォルトですから、 明示的に指定すればString#encodingは変化するでしょう。 実装としては、おそらくはバイナリのままエンコーディングタグがつくのだと思います。
ので、ここ以降の考察はちょっとズレちゃってるかも。
CにPythonのインデントによるブロック指定を導入する、という話。
しかし、考えてみれば、Cってのは
と、Pythonでよく見かけるインデントによるブロックの弊害の原因がほとんどない言語 ではないだろうか。
もしかして、これって理想の組み合わせ？
せっかく東京に引っ越したということで、今年の東京ゲームショウに行ってみました。 ...
家に帰って、Xtalのコンパイラに定数伝播、定数畳み込みの機能を実装しつつ寝ました。
ゲームショウに行ったというエントリなのに、 Xtalコンパイラをいじった話が登場しちゃう。 ほんとに言語実装が好きなんだなあ。
共感しちゃう。
それはそれとして、Xtalは最近導入された言語仕様が、独自性が強すぎてちょっと不安なんだけど(first_stepとかblock_catchとか)。 言語デザイナーってのは頑張って独自性・新規性を追求しすぎちゃうと ユーザが離れちゃうし、なにも独自性がないと関心を持ってもらえないし、 難しいバランスが要求される責任だよね。