Rubyについて Part 36 - 暇つぶし2ch

Rubyについて Part 36 ..

202:デフォルトの名無しさん
09/07/09 18:58:07
引数にstrをとるメソッドが文字列処理のヘルパークラスみたいに
strの内容が文字列でさえあれば問題なくなにがしか処理できるのなら
引数名はstrで必要にして充分だよな。

逆に引数の内容が何らかの意味のある文字列であって、
想定外の内容だったときにはエラーを返さなきゃいけないような処理なんであれば、
その「想定している何か」の情報を引数名に込めてやりたいところ。

203:デフォルトの名無しさん
09/07/09 18:59:23
まああと Smalltalk の場合はクラス名の部分を選択してクラスの説明読んだり
クラスブラウザ立ち上げてブラウズしたりって意味もあるけどねって話はいいとして、
名前をつけるので迷いがちなら、ケント・ベック読んでおけばとりあえず指針は得られる。

URLﾘﾝｸ(www.amazon.co.jp)

204:デフォルトの名無しさん
09/07/09 19:10:01
ケントベック本というと、読んだ後に引数名を
aTarget
とかにしまくってしまうような偏見がある

205:デフォルトの名無しさん
09/07/09 21:12:14
Smalltalk の場合は、引数の名前の他にキーワードセレクタも引数の使い方を表す情報として使用できる。
この使い方は、Rubyのメソッドが引数をハッシュでとる場合に近い。
ハッシュのキーに意味を持たせれば、値の名前は要らない。

206:デフォルトの名無しさん
09/07/10 01:10:26
「その、まあ」なやつは前RAIDスレにいなかったか？今もいるかもしれんが

207:デフォルトの名無しさん
09/07/10 08:48:47
URLﾘﾝｸ(github.com)
うへえ、90KBのソースファイル全部から一番外側のモジュール定義を物理的に引っこ抜いて、
一番最後に空のモジュール作って再代入しよった
っていうかこんなんgithubでやるな、追随や衝突解決がめんどくさいから
どうせ「スペースがもったいない」「インデントが深いから」とかいうアホな理由だろこれ

module WWW
　class Mechanize
　　def …
　　class Page
　　　def …
　　end
　end
end

　　　　　　　↓

class Mechanize
　def …
　class Page
　　def …
　end
end
module WWW; end
WWW::Mechanize = ::Mechanize

208:デフォルトの名無しさん
09/07/10 09:00:33
「いっちゃん外側の纏め用モジュールの扱い」ってのは難儀なとこではある
ここにはメソッドも定数も定義されず、クラスをまとめるモジュール空間の提供としてのみ存在するもの

インデント深くなるから外に出しちゃえってのはそれはそれでいいんじゃないの
WWW::Mechanize と Mechanize の2つが存在することになるから WWW モジュール作った意味なさそうだけどさ

てんだらーが nokogiri 疲れでトチ狂ったのかと思ったら別の人の直接コミットなのね

209:デフォルトの名無しさん
09/07/10 09:11:47
この場合は ::Mechanize でアクセスできなくすればいいんだろ
…方法思いつかんが
なんかある？

210:デフォルトの名無しさん
09/07/10 10:19:37
これずううううううっと思ってたんだけどさ、オフィシャルページの HTML のタイトルさ、
「ダウンロード」とか「ニュース」とか単語になってるのなんとかなんね？
「Ruby ダウンロード」とか「ニュース - オブジェクト指向スクリプト言語Ruby」とか
他のサイトと区別できるタイトルつけようぜ

211:デフォルトの名無しさん
09/07/10 10:22:55
Object.send(:remove_const, 'Mechanize') とか

212:デフォルトの名無しさん
09/07/10 10:51:30
それは WWW::Mechanize ごとアクセスできなくなるんでは…

class Mechanize; end
module WWW; end
WWW::Mechanize = ::Mechanize
Object.__send__(:remove_const, 'Mechanize')
p Mechanize.new rescue "Mechanize.new.failed"
p WWW::Mechanize.new rescue "WWW::Mechanize.new.failed"

"Mechanize.new.failed"
#<Mechanize:0xb7cfaec4>

んぬう

213:デフォルトの名無しさん
09/07/10 11:08:50
クラス名は単なる定数で、参照先がたまたまクラスオブジェクトだってことさ。

214:デフォルトの名無しさん
09/07/10 11:14:11
>>210
チラシの裏に提案を書いてもどうにもならないことは自覚してる？

215:デフォルトの名無しさん
09/07/10 11:14:32
class Hoge
end

と書いたとして、これがいつ class クラスのオブジェクトとして存在し始めるかというのは意識しにくいかもね

216:デフォルトの名無しさん
09/07/10 11:25:48
__send__でprivate呼べなくなったんじゃなかったっけ

>>215
class ～ endがself返せばirbとかでわかりやすいんだろうけど

ってこれも他のブロックのように最後の返値を返すのか
class Foo; end #=> nil
class Bar; self; end #=> Bar

217:デフォルトの名無しさん
09/07/10 11:59:30
WWW::Mechanize = ::Mechanize

これさ、あたりまえだけど
WWW::Mechanize.name
の返値は
"Mechanize" のままなんだな。

素直に
module WWW; class Mechanize; end; end
した場合は
"WWW::Mechanize"

218:デフォルトの名無しさん
09/07/10 12:23:37
Structといい、一応ファーストクラスオブジェクトなのに
そのへんの仕様で足引っ張ってる感じだｗ

219:デフォルトの名無しさん
09/07/10 12:45:52
とりあえず、この変更にはユーザーデメリットしかないと思う
俺としてはMechanizeが下手打ってくれて有難いが

220:デフォルトの名無しさん
09/07/10 12:50:29
うっさいよhttpclient

221:デフォルトの名無しさん
09/07/10 12:55:00
今は Anemone かも
あれはASCII 文字使い以外には機能が不足しまくりで、基本機能揃えて実際の現実フォローを行うと
単に Mechanize になるだけなんじゃねともっぱらの評判

222:デフォルトの名無しさん
09/07/10 16:23:46
>>214
それを「気にして」いるのは君だけだよ

223:デフォルトの名無しさん
09/07/10 16:36:05
エスパー参上

224:デフォルトの名無しさん
09/07/10 18:22:16
>>209
module WWW; end
class WWW::Mechanize
end

225:デフォルトの名無しさん
09/07/10 19:40:18
>>220
HTTPのクライアントなんだけどさ、
①HTTP/HTTPSが使えて
②GET/POSTその他メソッドのレスポンスを
　サーバからクライアントへの全文の受信を待たずに
　ある程度の大きさの塊で順次受け取れて
③Windows（mswin32）で動く
ライブラリってなんかあるかな?

①、②までならlibcurlのRubyバインディングのcurbがあるんだけど、
curbはドキュメントでLinux以外想定してないと明記されてるわ
mingwでgem installしてみたら案の定拡張ライブラリのコンパイルで
引っかかるわで、
今泣きながらDL経由でlibcurl叩こうとしてるんだけど。

226:デフォルトの名無しさん
09/07/10 19:50:15
>>225
つまり net/http を使わないってことね

227:デフォルトの名無しさん
09/07/10 20:04:26
>>226
うん。net/httpだと②が出来ないと思う。

意図としては、サーバ側から取得してくるリソースが
典型的なHTMLみたいに数KB～数100KB程度のサイズの場合は
内容を全部取得してからまとめて処理してもいいんだけど、
動画みたいな数MB～数100MB程度のサイズの場合は
頭から数10KBとか数100KB程度の大きさでいいから順次取得して
逐次処理したいんだ。

228:デフォルトの名無しさん
09/07/10 22:04:04
>>227
>動画みたいな数MB～数100MB程度のサイズの場合は
>頭から数10KBとか数100KB程度の大きさでいいから順次取得して
>逐次処理したいんだ。

動画じゃないけど、おなじようなことをしたいです。
これってRubyでやるときは、どんな設計にするのがいいの？

229:デフォルトの名無しさん
09/07/10 22:06:37
不用意にnet/httpを使わない
サーバが対応してるなら、こっから100キロバイトぶんだけくれというHTTPヘッダを送りつけ続ける

230:デフォルトの名無しさん
09/07/10 22:13:31
net/http は逐次処理させるの自体はできた気がする
ただ、どう小細工しても「取得完了時にメモリを数百MB占有」というのは回避できない

231:デフォルトの名無しさん
09/07/10 22:18:25
そういえばopen-uriなんかでもコールバック設定できたよね
ダウンロード状況の進捗とか示すのに使うやつ
逐次処理だけできればいいのならそれで足りそうな気が

232:デフォルトの名無しさん
09/07/10 22:21:33
>>227
230も言ってるけど、逐次処理できるよ
HTTP#getにブロックを渡せばいい
（HTTP.getではできないので注意）

233:225,227
09/07/10 22:24:01
>>229
ご存じの通り、Rangeヘッダでの取得だとサーバ側がパーシャルで返してくれなかったときに寒いことに。
で、net/httpを一部いじったりしてレスポンスのボディをある程度逐次に取れるようにしても、
単純な実装だとkeepaliveとかpipelineとかが絡んできたときにcontent-lengthやらchunkやらの取り扱いで面倒なことに。

>>228
Linuxで動けばいいのならcurbのon_bodyがそのまんま。
あらかじめコールバックハンドラ用のprocを登録しておくと、
目的のURLにアクセスしてレスポンスのbodyをある程度受け取ったタイミングで
受け取ったデータを引数にしてprocを呼んでくれる。

eventmachine使うとクライアント的な動作についてもイベントドリブンな感じで
実装できるっぽいけど、一から作るのもな、という。
実際目的が同じかはともかくほぼ一から作ろうとしてる人もいるみたいだけど。
URLﾘﾝｸ(blog.masuidrive.jp)

234:225,227
09/07/10 22:30:51
>>232
おお。もっかい確認してみます。

結局作りたいモノって大した物じゃなくて、
手元にあるmouseHoleもどきのHTTPプロキシに
URLﾘﾝｸ(www.artonx.org)
みたいな仕掛けを仕込みたいってだけなんですが。

235:デフォルトの名無しさん
09/07/11 21:11:56
いよいよAndroidの国内端末（HT-03A）出たね
これでRuby動かしてみた人居る？

236:デフォルトの名無しさん
09/07/13 10:45:37
ruby/tkのビルドで自動でライブラリさがしてくれるようになったね＞nagaiさん乙でした
でも、makeにすっごく時間がかかるようにもなってしまった。

237:デフォルトの名無しさん
09/07/16 04:57:23
p Time.at(100).strftime("%H:%M:%S") => "01:01:40"

これで "00:01:40"を返して欲しいんですが
時間は常に +1 されて帰ってくるんでしょうか？

238:デフォルトの名無しさん
09/07/16 05:33:56
TZ=UTC0 ruby -e'p Time.at(100).strftime("%H:%M:%S")'
"00:01:40"

時差+1ってことはフランスかどっかにお住まいですか。Merci

239:デフォルトの名無しさん
09/07/16 05:43:31
>>238
ああっ標準時刻とのずれか！
9時間なら気づけたのに！

場所はドイツからです。 Danke schön!!

240:デフォルトの名無しさん
09/07/17 20:43:15
Ruby 会議、初日行ってきたお
通訳しているレオさん(?) かっこよすぎる

声もイカす

・自分はずーっと大講堂だったが、高井さんのエンタープライズRailsがおもしろかった
　ヨドバシに並ぶようになったらポイントで買おう
・外人さんがけっこう見かけた

241:デフォルトの名無しさん
09/07/17 22:04:15
>>240
オレはずっと１Ｆだったが、ささだ研がブラック研究室ということが分かったよかったｗ

242:デフォルトの名無しさん
09/07/17 23:09:01
懇親会でアーロンがおよげたいやきくん歌ってた。

243:デフォルトの名無しさん
09/07/17 23:38:33
わざわざ日本に着てまで喋るだけあるな……

244:240
09/07/18 01:32:36
終わったあと、新宿でエヴァ破をひとりで見てから帰ってきた。

>>241
笹田さんって Ruby 1.9 の YARV を作っている方だよね？
そのセッションも聞きたかったのだが、Rails 3 のほうを聞いていたので聞けなかった。
ブラックだったのか.....

明日も早起きしないと。

245:デフォルトの名無しさん
09/07/18 09:24:17
>>242
ひげの山男さんマジぱねえっす（日本に馴染んでる的な意味で）

246:デフォルトの名無しさん
09/07/18 14:04:03
>>244
昨日午前中見てきた

247:デフォルトの名無しさん
09/07/18 14:04:50
> ブラックだったのか.....
あれはまぁ自虐ネタだから

248:デフォルトの名無しさん
09/07/19 00:36:45
レオさんは俺の嫁

今日の1Fの最後のコマ(GC)にいたんだけど、
Ruby 本体のメンテナ(コミッタ)は、ほぼ日本人ばかりなの？
外人さんもいるの？

あるいは Linux Kernel みたいにパッチは世界中から受け付けるけど、
コミッタは日本人だけなのかな？

249:デフォルトの名無しさん
09/07/19 01:38:29
>>248
URLﾘﾝｸ(yugui.jp)

日本人が多いけど、外人さんもいる様子
有名な人だと、Dave ThomasとかDavid Flanaganとか

250:デフォルトの名無しさん
09/07/19 16:35:21
実際に誰が動いているかとかはコミットログやChangeLogみるとか、
「Ruby のコミット数ランキング」を見るとか。
URLﾘﾝｸ(dame.dyndns.org)

まぁ、Rubyってあんまりパッチ来ないかなぁ、受け付けてはいるんだけどね。
Ruby内部のコードを読んで、いろいろつっこみをしてくる外人さんって、
Ruby本を書いているから細かいところまで見ているってイメージがある。
あと、パッチが外から来づらい理由として、継続して送ってくる人には
コミット権をあげちゃうからってのもあるかな。

251:デフォルトの名無しさん
09/07/19 23:01:55
ブラック研究室に入ったんだがどうやら俺は限界らしい
URLﾘﾝｸ(www.ci.i.u-tokyo.ac.jp)

映画化決定

252:デフォルトの名無しさん
09/07/19 23:04:02
日本Rubyの会公式Wiki - 日本Ruby会議2009 アンケート
URLﾘﾝｸ(jp.rubyist.net)

アンケートを書くまでがRuby会議です。

253:デフォルトの名無しさん
09/07/20 17:09:14
プレゼンはustreamのrecordedでもうほとんど見れるんだな、すげー時代だ
kwatchのいうテンプレートとAOPってのがamritaとどこが違うのかわからんかった
スレでtenjinのアピールしてたのっていつごろだったっけ

254:デフォルトの名無しさん
09/07/20 18:45:13
AOPはJavaでは比較的知られているけど、たしかにHTMLテンプレートと絡ませると面白いかも。

255:デフォルトの名無しさん
09/07/20 18:50:16
AOPってなに？
アスペクト指向とかいう現状バズワードまがいの代物ですか？

256:デフォルトの名無しさん
09/07/20 18:56:43
バズワードだってｗ
使ってみたかったんだねｗ

257:デフォルトの名無しさん
09/07/20 19:58:59
そういえば、matzが言ってたnloopパッチって
結局何で適用されないんだろう

高速化は正直どうでもいいけど、
多重ループが圧縮できるのは嬉しいと思うんだけどなあ
ネストが浅くなるし、行数も減るし

258:デフォルトの名無しさん
09/07/20 23:22:08
名前とか？
nloopでは分かりづらくね

259:デフォルトの名無しさん
09/07/22 00:57:45
今時は、なんでもeco。
名前にecoを付ければ、政府援助が付いて、双方ウマウマ。
なわけで、
ecoloop
おいらは、実態を知らんが、高速になるならecoに違いない。

260:デフォルトの名無しさん
09/07/22 06:58:47
>>255
>アスペクト指向とかいう現状バズワードまがいの代物ですか？

アスペクト指向は、Javaではけっこう使われているちゃんとした技術だよ。
DIコンテナでは標準的な技術。

261:デフォルトの名無しさん
09/07/23 02:44:03
実現方法は別としてLISPとかでも普通にやってることだしね。 > AOP
昔ながらのやり方に新しい名前が付いただけで「バズワード(笑)」になっちゃうわけもなく。

262:デフォルトの名無しさん
09/07/23 02:57:50
NokogiriがWindows-31Jエンコーディングをサポートしていない気がする。
正確にはNokogiriが使っているlibxml2が呼んでいるiconvかもしれないけど。

>irb -Ks -rrubygems -rnokogiri
#Shift_JISの範囲外の文字を含んだWindows-31J(=CP932)エンコーディングの文字列
irb(main):001:0> s="<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
=> "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"

#エンコーディング指定なしでHTMLパース。当然失敗。
irb(main):002:0> Nokogiri::HTML.parse(s)
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>

#Windows-31JエンコーディングでHTMLパース。失敗。
irb(main):003:0> Nokogiri::HTML.parse(s,nil,'Windows-31J')
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>

263:デフォルトの名無しさん
09/07/23 03:00:30
#CP932エンコーディングでHTMLパース。成功。
irb(main):004:0> Nokogiri::HTML.parse(s,nil,'CP932')
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "URLﾘﾝｸ(www.w3.)<)
org/TR/REC-html40/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>1１</title>
</head></html>

ちなみに環境はこんな感じ。現在入手できる最新のActiveScriptRubyとNokogiri。
>ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-mswin32]
>gem list nokogiri
I:\home\a_i\script>gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.3.2)

264:デフォルトの名無しさん
09/07/23 03:18:51
さくっとパッチ書いて配布しないの？
wktk

265:デフォルトの名無しさん
09/07/23 03:36:14
Nokogiri::HTML.parse(s,nil,'Windows-31J')
のときに実際には
Nokogiri::HTML.parse(s,nil,'CP932')
とやるようなのはすぐに出来るだろうけど、
変換結果とかエンコーディング情報はCP932になっちゃうから、

パース時に明示的に指定したエンコーディングと、
パース後に取得できるエンコーディングの内容が同一と仮定してるような
プログラム、具体的にはMechanizeとかが困ったことになる悪寒。

266:デフォルトの名無しさん
09/07/23 06:46:26
個々人の環境でインストールされている iconv が実際にどんだけの範囲をサポートしているかは
iconv 利用ライブラリ側ではもうどうしようもない
「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
そんなこと言ったらそもそも x-sjis なんかも読めないわけだし

ちなみに手元の Ubuntu では普通に動作する
irb> s = Iconv.conv('WINDOWS-31J', 'UTF-8', "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html)"
irb> Nokogiri::HTML.parse(s,nil,'Windows-31J')
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "URLﾘﾝｸ(www.w3.org)">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-31J">
<title>1?P?@1?P?@</title>
</head>
<body></body>
</html>

267:デフォルトの名無しさん
09/07/23 07:39:51
1.8もiconvも捨てて、1.9/transcode使おうぜ！

268:デフォルトの名無しさん
09/07/23 07:41:36
Ruby って不幸なんですね
日本語得意っていうのが嘘に聞こえる

269:デフォルトの名無しさん
09/07/23 07:50:24
iconv と小文字で書いてるのが読めんようだが、
まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで

270:デフォルトの名無しさん
09/07/23 07:51:48
Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う

271:デフォルトの名無しさん
09/07/23 07:57:22
比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る
つまりRubyを使ってない人にはそう見えるんだろう

272:デフォルトの名無しさん
09/07/23 08:26:58
つまりRubyを使ってない人が
比較スレとかで「日本語処理が得意」とか書いてるのか

273:デフォルトの名無しさん
09/07/23 08:35:47
・文字列処理は得意
・日本語の取り扱いもできる
　→日本語処理も得意なはず！

こういう図式が成立してそうなイメージが
嘘じゃあないが、他のスクリプト系言語と比べて
とりたてて得意かと言われると微妙な所

274:デフォルトの名無しさん
09/07/23 08:46:08
日本語版Windowsの標準エンコーディングがUTF-8になれば
UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。

275:デフォルトの名無しさん
09/07/23 09:05:08
そもそも「日本語処理が得意」って言い方からして曖昧すぎる
どうすれば得意だと言えるんだ？

たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？
ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？
それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？

やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる

276:デフォルトの名無しさん
09/07/23 09:05:44
朝から活発だな

277:デフォルトの名無しさん
09/07/23 09:16:21
>日本語版Windowsの標準エンコーディングがUTF-8になれば

I agree, but there are many SJIS records on HDD.

278:デフォルトの名無しさん
09/07/23 09:18:13
>>275
各文字列のエンコーディングを厳密に扱えるのが良い

279:デフォルトの名無しさん
09/07/23 11:11:31
ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
そりゃ移行はもうあっさり済むと思うんだが
実際はそうではないわけで

280:デフォルトの名無しさん
09/07/23 11:14:23
Summer holidays has come.

281:デフォルトの名無しさん
09/07/23 11:47:25
>>279
漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
対応できるんじゃねーのとか。

282:デフォルトの名無しさん
09/07/23 12:04:12
ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
Macと違って

283:デフォルトの名無しさん
09/07/23 12:38:14
>>281
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。

この手の問題は、数が少ないからといって無視できるものではない。
というより、データ変換については間違いがあってはならないのが前提であり、
すこしでも間違いがあれば大きな問題。
１文字でもうまくいかないのがあれば、移行しない人が大勢いても不思議ではない。

284:デフォルトの名無しさん
09/07/23 13:13:38
cp932はもれなくユニコードで表現できるでしょ？
じゃなきゃW系APIとかどうすんのかと

285:デフォルトの名無しさん
09/07/23 13:16:48
マクはいろいろ問題が。

286:デフォルトの名無しさん
09/07/23 13:31:41
UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
そういう人に限って、コンピューターが高速になってるからインタープリタ言語でも問題ないとか言うんだよね。

287:デフォルトの名無しさん
09/07/23 13:34:12
Perlがまだjcode.pl全盛期でUnicodeなんか誰も使ってなかった頃、
Rubyは既に日本語(EUC-JP, SJIS)に対応していた。

というだけで今となっては別に日本語処理がとりわけ得意なわけではない。
1.9はノウハウがたまってくれば良いかも。

288:262
09/07/23 13:53:35
>>266
>「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
>ちなみに手元の Ubuntu では普通に動作する
ああ、やっぱりそんなところですよね。

で、今回問題となってるiconvですが、
Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。

一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。
さすがにIANAに登録されてる分ぐらいはエイリアスが効かないとHTML/XMLの処理という
趣旨から困るはずなので。

現状、Mechanize経由で使ったりする分には、
コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
レスポンスのコンテントタイプのキャラクターセットもUTF-8に差し替えてしまえば
実用上はほとんど問題なさそうです。

もちろんWindows-31J->UTF8->Windows-31Jと変換したときに
変換前と後とでバイナリが一致しなくて困るケースとか、
サーバから取得した時点でのエンコーディングを意識しておく必要があるケースとかは
マズいんですが、まあそう多くはないだろう、という。

289:デフォルトの名無しさん
09/07/23 14:13:03
文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
Javaの文字コード周りの大変さとか、
Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
文字コード変換テーブルのせいだった、とか考えると
Rubyでやるべきかどうか、ってのは悩ましいな。
特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。

290:デフォルトの名無しさん
09/07/23 14:23:46
>>284
もういちど>>279を読もうぜ

>>279
>ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
>そりゃ移行はもうあっさり済むと思うんだが
>実際はそうではないわけで

291:デフォルトの名無しさん
09/07/23 14:25:39
>>288
Mechanize::Page#encoding= 使え
引数を Nokogiri::HTML.parse の第3引数に渡して page の HTML を再パースしてくれる

　agent.get(windows_31j_uri)
　agent.page.encoding = 'CP932'

今の iconv の CP932 は WINDOWS-31J と全く同じだから
（つまり、WINDOWS-31J 以前の CP932 には非対応）、
WINDOWS-31J の代わりに CP932 を渡しても構わない

あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ
オフィシャルな iconv は
URLﾘﾝｸ(www.gnu.org)
> Japanese
> EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
> EUC-JISX0213, Shift_JISX0213, ISO-2022-JP-3 (--enable-extra-encodings 有効時)
これ以外をサポートしないし、サポートする義理もない

292:デフォルトの名無しさん
09/07/23 15:08:47
>>291
事前にコードが仮定できればそれでOKというかベストですね。

ちなみに当初ハマっていたシナリオだと

とあるページをパースすると途中で内容が途切れたようなパース結果が帰ってくる
->元データを確認したらWindows-31J相当の内容のページに設定されたmetaタグの内容がShift_JIS
->encodingにWindows-31J指定->内部的には未知のエンコーディングでエラー。なかったことに。
->再パースされるもmetaタグのエンコーディングでパース
->外観的には何度encodingを再設定してもencodingがShift_JISのまま
->大☆混☆乱

とかまあそんな感じでしたw

293:デフォルトの名無しさん
09/07/23 15:44:28
>>290
具体的にどの文字がUTF-8で表現できないんだ?

294:デフォルトの名無しさん
09/07/23 16:09:56
CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
逆は不可だが

295:デフォルトの名無しさん
09/07/23 16:14:24
>>293
その辺の話はCP932については
Wikipedia項目ﾘﾝｸコードページ932
がまとまってるんじゃないかな

296:デフォルトの名無しさん
09/07/23 18:19:41
UNICODEってあほなの？
文字コード統一するどころか
種類増やしてさらに面倒にしただけじゃないの？

297:デフォルトの名無しさん
09/07/23 18:25:18
iso-8859-*は統一されたんだろ

298:デフォルトの名無しさん
09/07/23 18:56:04
日本国内の文字コードも統一できない民族よりはマシ

299:デフォルトの名無しさん
09/07/23 19:01:14
>>296
JIS EUC-JP Shift_JISを使い分け続けるよりは遙かに分別があるよ

300:デフォルトの名無しさん
09/07/23 19:09:45
100年後も使い分けしつづけてるんじゃないかなぁ？w

301:デフォルトの名無しさん
09/07/23 19:13:33
毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ

302:デフォルトの名無しさん
09/07/23 19:24:07
>>291
ubuntuのiconvはglibcのiconv

303:デフォルトの名無しさん
09/07/23 19:25:18
>>301
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかｗ

って、もとから超人工的で場当たり的なものなんだからそれはねーよ
、とマジレスｽﾏｿ

304:デフォルトの名無しさん
09/07/23 19:59:21
文化で人工的でなくて場当たり的でないものはあるのか
それこそ非文化だろ

305:デフォルトの名無しさん
09/07/23 20:23:45
Perl、インターネット、日本語漢字コードあたりは、「とりあえず作ってみた」が
実用に供されていろいろ問題が尾を引いている事物の代表だな。

306:デフォルトの名無しさん
09/07/23 20:25:39
Cもしかり
Javaもしかり
GAEもしかり

307:デフォルトの名無しさん
09/07/23 20:27:02
Rails もしかり www

308:デフォルトの名無しさん
09/07/23 20:28:10
>>305
>「とりあえず作ってみた」

Rubyもその代表なんだが

309:デフォルトの名無しさん
09/07/23 20:34:18
長く大勢に使われる人工物で統一取れているものなんていくつあるんだか。

310:デフォルトの名無しさん
09/07/23 20:40:12
車のエンジンレーキハンドルを変えようかって話は出たり出なかったり

311:デフォルトの名無しさん
09/07/23 20:49:00
> Ruby って不幸なんですね
> 日本語得意っていうのが嘘に聞こえる
> Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う
> 比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る

基本的に自然言語は難しい、「得意」というよりは、「比較的マシ」と言い換えた方が実情に近い。

> こういう図式が成立してそうなイメージが
> 嘘じゃあないが、他のスクリプト系言語と比べて
> とりたてて得意かと言われると微妙な所

確かにPerl5.8以前においては、Rubyは-Kがあるだけかなりマシだった。

> まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで

Ruby 1.9のEncoding/transcodeはソレですよ。
まぁ、再発明すれば解決ってほど文字コードの世界は甘くない。
Rubyより下のレイヤーに依存しないだけマシって話ですな。

> 日本語版Windowsの標準エンコーディングがUTF-8になれば

Windowsは互換性にかなり気を使うからどうだろうねぇ。
デフォルトがUTF-8になるまでまだまだかかると思うよ。

> UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
> これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。

で、その時にはデータ移行しないといけないんだ。
また、すでにあるWebデータは多分そのままだよ

312:デフォルトの名無しさん
09/07/23 20:49:53
> そもそも「日本語処理が得意」って言い方からして曖昧すぎる
> どうすれば得意だと言えるんだ？

とりあえず8bitの文字列が通れば「得意」って言っていいんじゃないの。

> たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？

Ruby 1.8はエンコーディングは扱っていない、扱っているのはバイト列です。
エンコーディングを扱っているのは、Rubyでなくもっと上のレイヤーだね、jcode.rbとかはのぞいて。

> ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？

Ruby 1.9みたいなCSIプログラミング環境ってのは他に例がきわめて少ないので、是非お試しください。

> それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？

これは結構あるよね、Rubyも将来的にはUnicodeに統一する方向になっていくのかもしれん。
まぁ、少なくとも1.9ではCSIのまま突っ走るはずなのでご安心ください。

> やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる

Rubyを使ったことがないか、Rubyよりはるかに悲惨な環境での経験が長いかの二択だろうね。

313:デフォルトの名無しさん
09/07/23 20:51:08
> ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
> そりゃ移行はもうあっさり済むと思うんだが
> 実際はそうではないわけで

>>281 一応理論上はもれなく表現可能だよ、最近はテーブルも統一されてきたし。
ただ、とりあえずWindowsがロケールをUTF-8に移行しないうちは無理でしょうね。

> 漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
> 大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
> 対応できるんじゃねーのとか。

>>283 1文字でもあれば普通は移行不可能だと考えるべきでしょう。
まぁ、一応一度片道切符で移行するだけなら、先述の通り大丈夫。

> ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
> Macと違って

Joelが言ってたけど、plain textはplainじゃないんだよね、外部からエンコーディングを指定しないと。
まぁ、外部からのエンコーディング指定がまたそれはそれで腐ってたりするんだけど。

314:デフォルトの名無しさん
09/07/23 20:54:41
> マクはいろいろ問題が。
Macは「ごかんせい？なにそれ？おいしいの？」だからなぁ、MacJapanese仕様変わりすぎ。

> UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、

もうそんな時代錯誤な人いないよね？オレオレUTFとかやめてよ、ほんとに。

> で、今回問題となってるiconvですが、
> Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
> つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。
> > 一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。

>>288 ライブラリとしてマルチプラットフォームで使えるiconvは今のところGNU libiconvしかないと思う。
しかし、GNU libiconvはメンテナがDQNなせいで、MS系エンコーディングを整理するパッチが取り込まれていない。
ので、パッケージやバイナリの配布者が別にパッチをあてる必要がある。
例えばFreeBSDのportsはlibiconvが入っているのだが、これには森山さんのパッチが当てられてる。
ので、同様なことをしてもらえばいいんだけど……。

315:デフォルトの名無しさん
09/07/23 21:04:24
>>312
CSIは仕様？それとも実装依存？

316:デフォルトの名無しさん
09/07/23 21:26:15
>>314
DQNというより問題点が理解されてないんでは?

317:デフォルトの名無しさん
09/07/23 21:50:32
> 現状、Mechanize経由で使ったりする分には、
> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて

それよりはCP932に差し替えた方がいいのでは

> >>289
> 文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
> Javaの文字コード周りの大変さとか、
> Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
> 文字コード変換テーブルのせいだった、とか考えると
> Rubyでやるべきかどうか、ってのは悩ましいな。

彼らは大変だったのでしょうねぇ、先人の苦労には頭が下がります。。
まぁ、彼らが残したShift_JIS変換テーブルみたいなゴミに苦労もしてたりするんですけど。

> 特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。

まぁ、CSIだと変換表を用意しないって技もあったりするんですよ。

> 今の iconv の CP932 は WINDOWS-31J と全く同じだから

実装依存です。

> あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ

Ubuntu は glibc iconvで、libiconvとは別物ですね。
glibc iconvには森山さんのパッチが取り込まれています。

> CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
> 逆は不可だが

意味的にも大丈夫ですよ、問題が出るのはShift_JISと混ぜた時の話。

318:デフォルトの名無しさん
09/07/23 21:54:49
> UNICODEってあほなの？
> 文字コード統一するどころか
> 種類増やしてさらに面倒にしただけじゃないの？

UnicodeがなかったらJIS X 0213対応とかで確実に大惨事になってた。
UnicodeのおかげでShift_JISX0213とかを無視することが出来た、すばらしい。

> 日本国内の文字コードも統一できない民族よりはマシ
別にSJIS<->EUC<->JISは計算の問題だからたいしたことはないのさ。

> 毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ

まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
バイト列として扱う時の事を考えてよく設計されてるよ。

> >>301
> 必要に応じてうだうだ追加してきただけの既存規格が
> もうそんなに文化的なものになってるのかｗ
>>304 と同意見で、場当たり的拡張の積み重ねこそが、取り決めを文化にするんだと思いますよ。

> >> 315 CSIは仕様？それとも実装依存？

Ruby 1.9はCSIが仕様なので、MacRubyとかはCSIなはずです、Rubyレイヤでは。

> >>316
> >314
> DQNというより問題点が理解されてないんでは?
URLﾘﾝｸ(www2d.biglobe.ne.jp)
とかをはじめとして、なんどもコンタクトは取っているようなので、
たぶんあまりのカオスっぷりにびびってデジュールの気持ちよい世界に逃げたんだと思っています。
Safari/Webkitとかもそう言う傾向があるので、海外だと一定存在するかな。
まぁ、勘違い・偏見である可能性を否定はしませんけど。

319:デフォルトの名無しさん
09/07/24 01:02:58
本家に取り込んでください
URLﾘﾝｸ(www.moongift.jp)

320:デフォルトの名無しさん
09/07/24 01:30:24
>>319
勘弁してくれ。

321:デフォルトの名無しさん
09/07/24 01:34:01
LTネタだって知らないと本気の拡張に見えそうだな。

322:デフォルトの名無しさん
09/07/24 08:43:00
>>317
>> 現状、Mechanize経由で使ったりする分には、
>> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
>それよりはCP932に差し替えた方がいいのでは
コンテンツのcharsetが予測できない場合だとどれかに決め打つことになるわけですが、
その場合だと文字集合的に一番広いUnicodeにせざるをえないかと。
この場合でもNKFで対応できないコードが入ってくればアウトなのでまあ、
実用上そうそう困らなくてそれなりに楽、って程度の話ではありますが。

>>318
>まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
>バイト列として扱う時の事を考えてよく設計されてるよ。
ですね。
ASCIIがそのまま通って、かつファイルシステムクリーンというのは素晴らしい。

323:デフォルトの名無しさん
09/07/24 08:53:01
ISO-2022-JP-* みたいなイビツなシロモノがスタンダードにならなくて本当に良かったわ
「Unicodeでは全ての文字を含められない」ってのが理由だったがぶっちゃけどうでもいいし

324:デフォルトの名無しさん
09/07/24 09:09:25
新しい文字は放っておいても生まれる。絵文字とか。
というわけで、 UTF-8 系列をとりあえずの基盤として受け入れたのはたぶん結果的にはマシ。

325:デフォルトの名無しさん
09/07/24 09:11:43
余裕をもってUCS4にしようぜ

326:デフォルトの名無しさん
09/07/24 09:28:58
>>324
その割にはサロゲート対応だの、4バイトまでだの、
なかなか中途半端な現状だけどな
UTF-16ってのが諸悪の根元か？

327:デフォルトの名無しさん
09/07/24 09:39:34
UTF-8 は尖兵
ユニコードとやらも意外と悪くないではないかとか思わせるために敢えて本筋を剥いだ草

328:デフォルトの名無しさん
09/07/24 09:48:30
I'm perfect soldier.

329:デフォルトの名無しさん
09/07/24 09:49:35
草とか言うな(w

気がついたら UTF-8 ファイルと UTF-8 アプリケーションばっかで
他のエンコーディング系列に移行できなとかそんなのか

330:デフォルトの名無しさん
09/07/24 09:59:43
最強の尖兵乙

331:デフォルトの名無しさん
09/07/24 11:03:52
>>321
最初からRejectKaigiを狙ってたんじゃないのか?

332:デフォルトの名無しさん
09/07/24 11:45:19
あああ、LTじゃなくてRejectKaigiか。

333:デフォルトの名無しさん
09/07/25 01:02:24
rubyってjisちゃんと扱えないのか。苦労するはずだわ。
ruby捨ててjavaでがんばる。

334:デフォルトの名無しさん
09/07/25 01:06:25
> rubyってjisちゃんと扱えないのか。苦労するはずだわ。
何の話をしてるの？

335:デフォルトの名無しさん
09/07/25 01:10:08
> 余裕をもってUCS4にしようぜ
UCS-4も最新のISOでは0x10FFFFまでしか文字を定義しないことになったよ。

> その割にはサロゲート対応だの、4バイトまでだの、なかなか中途半端な現状だけどな
サロゲートペアはUTF-16の話で、UTF-8にはあまり。4バイトまでなのは困らないでしょ。

> UTF-16ってのが諸悪の根元か？
本質的にはUCS-2が根源かな。

> UTF-8 は尖兵
UTF-8が最終形じゃないかな、UCS-2やUTF-16の方がむしろpreview。

336:デフォルトの名無しさん
09/07/25 01:11:42
一文字64bitの新文字コード作ろうぜ

337:デフォルトの名無しさん
09/07/25 01:24:59
>>335
そこが今ひとつわからんのだが、31bitあったのを21bit？にしたのは、
なにか技術的な要請があったの？
それとも、先行したUCS2に引きずられただけ？

256*256*17面（だっけ）にしたのは、どういうことなんだろう。

338:デフォルトの名無しさん
09/07/25 03:13:11
>>337
まず、31bitだったのはsigned int32ね。
0x10FFFFまでなのは、UTF-16の収録限界が由来で、
BMPの0xFFFF+サロゲートペアの(0xDC00-0xD800)*(0xE000-0xDC00)だから

339:デフォルトの名無しさん
09/07/25 06:35:23
そもそもUnicode自体がクソだろ
文字鏡をつかっていればあるいわ

340:デフォルトの名無しさん
09/07/25 07:24:13
現実的にUnicodeより良い物があるの？

341:デフォルトの名無しさん
09/07/25 09:45:27
Unicode一本化されたとこから漸次さらに優れたものに移行すればいいじゃん
カオス状態がUnicodeのおかげでずいぶんましになってる所なのに

342:デフォルトの名無しさん
09/07/25 11:29:26
Rubyスレなのに気付いたらUnicodeの話になってた!

343:デフォルトの名無しさん
09/07/25 11:30:10
文字コードの話はなぜか妙に食いつきがいい

344:デフォルトの名無しさん
09/07/25 11:35:23
開発コアメンバが語るRubyの今とこれから（前編）
URLﾘﾝｸ(www.atmarkit.co.jp)

そろそろ1.8系から1.9に移るころなのかな？

345:デフォルトの名無しさん
09/07/25 12:35:10
>>341
Unicodeがある意味全てを終わらせてしまったので、
優れたものが出てくる余地はない。
Unicodeが優れたものなんじゃなくて、悪貨は良貨を駆逐するという意味で。

346:デフォルトの名無しさん
09/07/25 12:46:51
日本の3つの文字コードへの対応ライブラリパッチのファイルサイズ見れば、色々間違いだと思えるようになるよ

>>344
なんでこう、ちょっとカッコいいポーズしてください写真なん？
や、写真使うのは取材側の人だから要望聞いたほうがいいんだけどさ

Ruby1.9 に移行するのは絶対に間違いない
問題は、そのためのライブラリサポートの手間をいつ誰が取るかだと思う

外国の人はいろんな意味で慎重な移行をやりたがらないと思うんで、
それこそマルチバイトユーザーで最大Rubyコミュニティである日本人の出番なのではないかと

英語のライブラリ作者向けガイド書いた人がどっかにいたが、ああいうの頑張るべきかもしれない

347:デフォルトの名無しさん
09/07/25 12:50:53
弾子飼かと思った

348:デフォルトの名無しさん
09/07/25 12:55:37
とりあえず rubyrb1.9 test/ で Ruby1.9 対応完了とかほざく外人作者さんの調教から

古い rubygem でしか動かないライブラリが捨てられていくのと同じように、
Ruby 1.9 で実際上動作しないライブラリが捨てられていくようになればいいんだけど

349:デフォルトの名無しさん
09/07/25 13:11:14
Railsが1.9でまともに動けば移行が進むんじゃね。

350:デフォルトの名無しさん
09/07/25 14:20:13
つまり asakusa.rb 期待 age?

351:デフォルトの名無しさん
09/07/25 19:38:39
>>344
記事内容とはまったく関係ないし、たぶん写真写りのせいだと思うんだが
2枚目の写真のYugui氏が怖い

352:デフォルトの名無しさん
09/07/25 19:39:58
UTFが、8859と互換なのが大きいからなあ。日本人が使えないって騒いだって、欧米圏は、もう他に移行はしないだろう。

353:デフォルトの名無しさん
09/07/25 19:48:08
>>344
率直に言って恥ずかしいな
写真が気になって記事が頭に入らない

354:デフォルトの名無しさん
09/07/25 19:49:35
>>352
使えるのに使いたくないって騒いでるだけじゃないかと

355:デフォルトの名無しさん
09/07/25 19:54:58
>>351
全てがマイナスに働いている、ある意味レア写真
著者近影に使ったら書籍自体が山積みでお祓いに出されるレベル

もうちょっちいいのなかったんかね

356:デフォルトの名無しさん
09/07/25 20:00:03
>>352
互換じゃないお
互換なのは ISO-8859-1 の部分だけだお
それ以外の 2 から 16 くらいまでの文字は、文字は入ってるけど互換性ないお

357:デフォルトの名無しさん
09/07/25 20:10:41
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ

358:デフォルトの名無しさん
09/07/25 20:46:12
>>339
文字鏡はライセンスが問題になって以来、もうないと思うけどな

359:デフォルトの名無しさん
09/07/25 20:47:32
>>351
目が白目むいてるように見えるのが大きいんだろうな

360:デフォルトの名無しさん
09/07/25 22:26:04
ホントにキモイな。

Ruby関係って、他にもキモイやついなかったか?

361:デフォルトの名無しさん
09/07/25 22:32:55
1.9っていうと開発版だから～って思って2.0をずっと待ってた。
そんなに自信もって進められるなら2.0リリースしてくれよ。

362:デフォルトの名無しさん
09/07/25 22:42:04
インタビュー経由で疑問に思ったんだが、Rubiniusって結局何がどう嬉しくなるんだ？
・コードをそのままRubyオブジェクトにできる
・BSDライセンスになる
ことぐらい？

そもそも、CRubyの上で動くRubiniusが、CRubyより速くなるというのがよく理解できない
詳しい人がいればぜひ教えてほしい

363:デフォルトの名無しさん
09/07/25 22:45:51
まだ>>361みたなこと言ってるやつがいるのか

364:デフォルトの名無しさん
09/07/25 22:46:13
1.9使ってたけどRailsを使う必要があったんで1.8に戻した。
1.8でも十分速いし、対応ライブラリも豊富だからこれでいいよ

365:デフォルトの名無しさん
09/07/25 22:49:18
みんな！民主党が大変な事になってるよ。
URLﾘﾝｸ(www.nicovideo.jp)

366:デフォルトの名無しさん
09/07/25 22:49:24
>>360
> 他にもキモイやついなかったか?
好きで使ってる奴でキモくない人間を一人も見たこと無いよ。

367:デフォルトの名無しさん
09/07/25 22:49:36
一方おれは1.9でRailsを使っている。
特に大きな問題はなく今のところすべて回避できている。
回避できない問題もあるんだろうが。

368:デフォルトの名無しさん
09/07/25 22:52:45
>>362
対象の言語でVMを実装できるというところが「きれい」

369:デフォルトの名無しさん
09/07/25 23:50:54
pythonってVMだったか？
Ruby VM より早いPythonってどうなんだろうね

370:デフォルトの名無しさん
09/07/25 23:51:03
心の底から>>361と同意見

MatzはなぜRite=2.0にこだわるんだ
今の1.9.1を2.0にして、Riteを3.0にしたらいいのに

371:デフォルトの名無しさん
09/07/25 23:51:35
【科学】道路に軍手が落ちているワケ、名城大研究チームが突き止める[09/07/24]

ｽﾚﾘﾝｸ(hidari板)

372:デフォルトの名無しさん
09/07/25 23:57:09
>>362
アルゴリズムによってはCで書かれたHaskellがCよりも速いのと一緒

373:デフォルトの名無しさん
09/07/26 04:16:25
2.0 への思い入れ云々を除いても、バージョン1をバージョン2に上げるほどの何某があるとは思えん
1.9.1 の次くらいを 2.0 にするならまあアリかなと思う

1.9.1p0 の存在が鬱陶しいと思ってる人は少なくないはずだよ

374:デフォルトの名無しさん
09/07/26 04:27:31
1.9.1 は本体オンリーはともかく第三者ライブラリ全体を含んだ便利度はまだまだだなー、と感じるわけだが、
これが 2.0 だった場合は「バージョン 2.0 とか言ってる割には全然…」だの
「2.0 はアレなので 2.0.4 以降インストールしてください」だのいうことになったと思う

今現在我々が 1.9.1 の使い勝手に抱いている感想は、
それのバージョンが 2.0 だったからといっていい方向に作用したと思われるものではない、はず

次ページ