Rubyで遊んだ日々の記録。あくまで著者視点の私的な記録なので、正確さを求めないように。
Rubyと関係ない話題にはその旨注記しているはず。なので、一見関係無いように見える話題もどこかで関係あるのかもしれません。または、注記の書き忘れかもしれません...
_ 木村さんのところから。
えーと、これはside-by-side実行の恐怖について理解していないために起きる問題です。
「ランタイムDLLを手でコピーすればいいんだよね」という、従来通用した甘い考えを捨てて、ちゃんと再頒布用ランタイムをインストーラを使ってインストールすることによって解決できます。
_ 子供が日曜に1歳半になった。
それと関係はないけど、正月にNHKの全国ニュースでやってた肩乗りペリカンを見に某所に行ってきた。
思い返すと、去年の正月にも行ったんだよなあ。当時はペリカンもいなかったし、子供も何一つ理解できていなかったわけだが。
結果としてペリカンが肩に乗るところは見られなかった、が、子供もなんか楽しそうでよかった。鳥につつかれてたけど。
_ 翌日、子供が家の中でボールを投げて遊んでいるのを見ていたら、
という事件があった。
しかし自分が見てる目の前で子供が怪我するとマジでへこむ。大したことなくて本当によかった。
_ 先日、--encodingについて思考実験したのだけど、記録として残しておく。
_ 従来は-Kというオプションがあって、スクリプトのencodingと入出力のencodingの両方に作用した。
1.9では--encoding(-E)というオプションが追加された。これも現状はスクリプトのencodingと入出力のencodingの両方に作用する。
しかし、本来はスクリプトのencodingと入出力のencodingというのは一致しなければならないものではなく、一致させたい場合が多いのは確かだが、一致しない場合もあるだろう。
ということは、これを機会に、新設の--encodingは入出力のencodingにのみ作用するべきではないか。スクリプトのencodingは同じく新設のmagic commentで指定できるんだし。
_ さて、以上の考えは筋が通っていると自分では思うのだが、実用上の観点から見直してみる。
実は、現状では、magic commentは--encoding指定より強く、magic commentがあると--encodingではスクリプトのencodingを変更できない。
従って、--encodingからスクリプトのencodingへの作用があろうがなかろうが、magic commentが勝つので、実質的には--encodingは入出力のencodingにしか作用しない。
1.9用に新規に書かれたスクリプトではmagic commentが常にあると仮定してよいし、仮にそれがないなら、別に--encodingで変わろうがなんだろうが問題ないから書かれていないのだろう、たぶん。
_ そうでもないか。
UTF-16のようにASCIIと非互換(*1)のencodingを--encodingで指定してしまうと、magic commentがないスクリプトは実行不可能になる。
なので、magic commentのないスクリプトというのは使えない代物で、1.9ではmagic commentは必須のものということになる。
ふうむ...
_ 油断してる間に、--encodingと-Kの両方がスクリプトのencodingには効かなくなっていた。
さらに、それ以前から、メインスクリプト以外には-Kが効いていなかったという話が[ruby-dev:33156]に。うへえ。
_ というわけで、--encodingがスクリプトのencodingには効かないこと、-Kはメインスクリプトのみならずライブラリにも効くこと、が仕様となることを確認した。
後者はまだ修正されてない。意外とめんどいのよ。
_ 木村さんのところから。
手元で再現していなくて「なにそれ?」と思っていたのだけれど、実はconfigureで--with-baserubyを指定していたら再現しないだけだった。
ひょっとするとnmakeのバージョンも関係あるのかもしれない。
どうもnmake中で起動するrubyのパスがダブルクォートでくくられていた場合、nmakeがrubyを変な風に起動しているらしい。
実際にどんなコマンドラインで起動しているのか、という中身は確認しなかったけど、短いパス名になるようにしてダブルクォートを外したら解決はした。
わけわからんな、nmake。
被捕捉アンテナ類
[Ant]
[Antenna-Julia]
[Rabbit's Antenna]
[Ruby hotlinks]