- 1 名前：デフォルトの名無しさん [2009/06/28(日) 16:29:28 ]
- オブジェクト指向スクリプト言語Rubyについて扱うスレッドです。
前スレに変なのが沸いて流れてしまいましたが、まったりと行きましょう。
Ruby Home Page
www.ruby-lang.org/ja/
= 前スレ
Rubyについて Part 35
pc12.2ch.net/test/read.cgi/tech/1238194350/
過去スレ・関連スレは >>2-
- 283 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 12:38:14 ]
- >>281
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
この手の問題は、数が少ないからといって無視できるものではない。
というより、データ変換については間違いがあってはならないのが前提であり、
すこしでも間違いがあれば大きな問題。
１文字でもうまくいかないのがあれば、移行しない人が大勢いても不思議ではない。
- 284 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:13:38 ]
- cp932はもれなくユニコードで表現できるでしょ？
じゃなきゃW系APIとかどうすんのかと
- 285 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:16:48 ]
- マクはいろいろ問題が。
- 286 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:31:41 ]
- UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
そういう人に限って、コンピューターが高速になってるからインタープリタ言語でも問題ないとか言うんだよね。
- 287 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:34:12 ]
- Perlがまだjcode.pl全盛期でUnicodeなんか誰も使ってなかった頃、
Rubyは既に日本語(EUC-JP, SJIS)に対応していた。
というだけで今となっては別に日本語処理がとりわけ得意なわけではない。
1.9はノウハウがたまってくれば良いかも。
- 288 名前：262 mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 14:13:03 ]
- 文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
Javaの文字コード周りの大変さとか、
Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
文字コード変換テーブルのせいだった、とか考えると
Rubyでやるべきかどうか、ってのは悩ましいな。
特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。
- 290 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 14:23:46 ]
- >>284
もういちど>>279を読もうぜ
>>279
>ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの） で表現できるなら
>そりゃ移行はもうあっさり済むと思うんだが
>実際はそうではないわけで
- 291 名前：デフォルトの名無しさん mailto:sage [2009/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 は
ttp://www.gnu.org/software/libiconv/
> 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 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 15:08:47 ]
- >>291
事前にコードが仮定できればそれでOKというかベストですね。
ちなみに当初ハマっていたシナリオだと
とあるページをパースすると途中で内容が途切れたようなパース結果が帰ってくる
->元データを確認したらWindows-31J相当の内容のページに設定されたmetaタグの内容がShift_JIS
->encodingにWindows-31J指定->内部的には未知のエンコーディングでエラー。なかったことに。
->再パースされるもmetaタグのエンコーディングでパース
->外観的には何度encodingを再設定してもencodingがShift_JISのまま
->大☆混☆乱
とかまあそんな感じでしたw
- 293 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 15:44:28 ]
- >>290
具体的にどの文字がUTF-8で表現できないんだ?
- 294 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 16:09:56 ]
- CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
逆は不可だが
- 295 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 16:14:24 ]
- >>293
その辺の話はCP932については
ttp://ja.wikipedia.org/wiki/Microsoftコードページ932
がまとまってるんじゃないかな
- 296 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:19:41 ]
- UNICODEってあほなの？
文字コード統一するどころか
種類増やしてさらに面倒にしただけじゃないの？
- 297 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:25:18 ]
- iso-8859-*は統一されたんだろ
- 298 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:56:04 ]
- 日本国内の文字コードも統一できない民族よりはマシ
- 299 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:01:14 ]
- >>296
JIS EUC-JP Shift_JISを使い分け続けるよりは遙かに分別があるよ
- 300 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:09:45 ]
- 100年後も使い分けしつづけてるんじゃないかなぁ？w
- 301 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:13:33 ]
- 毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ
- 302 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:24:07 ]
- >>291
ubuntuのiconvはglibcのiconv
- 303 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:25:18 ]
- >>301
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかｗ
って、もとから超人工的で場当たり的なものなんだからそれはねーよ
、とマジレスｽﾏｿ
- 304 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:59:21 ]
- 文化で人工的でなくて場当たり的でないものはあるのか
それこそ非文化だろ
- 305 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:23:45 ]
- Perl、インターネット、日本語漢字コードあたりは、「とりあえず作ってみた」が
実用に供されていろいろ問題が尾を引いている事物の代表だな。
- 306 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:25:39 ]
- Cもしかり
Javaもしかり
GAEもしかり
- 307 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:27:02 ]
- Rails もしかり www
- 308 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:28:10 ]
- >>305
>「とりあえず作ってみた」
Rubyもその代表なんだが
- 309 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:34:18 ]
- 長く大勢に使われる人工物で統一取れているものなんていくつあるんだか。
- 310 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:40:12 ]
- 車のエンジンレーキハンドルを変えようかって話は出たり出なかったり
- 311 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:51:08 ]
- > ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの） で表現できるなら
> そりゃ移行はもうあっさり済むと思うんだが
> 実際はそうではないわけで
>>281 一応理論上はもれなく表現可能だよ、最近はテーブルも統一されてきたし。
ただ、とりあえずWindowsがロケールをUTF-8に移行しないうちは無理でしょうね。
> 漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
> 大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
> 対応できるんじゃねーのとか。
>>283 1文字でもあれば普通は移行不可能だと考えるべきでしょう。
まぁ、一応一度片道切符で移行するだけなら、先述の通り大丈夫。
> ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
> Macと違って
Joelが言ってたけど、plain textはplainじゃないんだよね、外部からエンコーディングを指定しないと。
まぁ、外部からのエンコーディング指定がまたそれはそれで腐ってたりするんだけど。
- 314 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:04:24 ]
- >>312
CSIは仕様？それとも実装依存？
- 316 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:26:15 ]
- >>314
DQNというより問題点が理解されてないんでは?
- 317 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/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というより問題点が理解されてないんでは?
www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=416
とかをはじめとして、なんどもコンタクトは取っているようなので、
たぶんあまりのカオスっぷりにびびってデジュールの気持ちよい世界に逃げたんだと思っています。
Safari/Webkitとかもそう言う傾向があるので、海外だと一定存在するかな。
まぁ、勘違い・偏見である可能性を否定はしませんけど。
- 319 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:02:58 ]
- 本家に取り込んでください
www.moongift.jp/2009/07/ruby-php/#more-16888
- 320 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:30:24 ]
- >>319
勘弁してくれ。
- 321 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:34:01 ]
- LTネタだって知らないと本気の拡張に見えそうだな。
- 322 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 08:43:00 ]
- >>317
>> 現状、Mechanize経由で使ったりする分には、
>> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
>それよりはCP932に差し替えた方がいいのでは
コンテンツのcharsetが予測できない場合だとどれかに決め打つことになるわけですが、
その場合だと文字集合的に一番広いUnicodeにせざるをえないかと。
この場合でもNKFで対応できないコードが入ってくればアウトなのでまあ、
実用上そうそう困らなくてそれなりに楽、って程度の話ではありますが。
>>318
>まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
>バイト列として扱う時の事を考えてよく設計されてるよ。
ですね。
ASCIIがそのまま通って、かつファイルシステムクリーンというのは素晴らしい。
- 323 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 08:53:01 ]
- ISO-2022-JP-* みたいなイビツなシロモノがスタンダードにならなくて本当に良かったわ
「Unicodeでは全ての文字を含められない」ってのが理由だったがぶっちゃけどうでもいいし
- 324 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:09:25 ]
- 新しい文字は放っておいても生まれる。絵文字とか。
というわけで、 UTF-8 系列をとりあえずの基盤として受け入れたのはたぶん結果的にはマシ。
- 325 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:11:43 ]
- 余裕をもってUCS4にしようぜ
- 326 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:28:58 ]
- >>324
その割にはサロゲート対応だの、4バイトまでだの、
なかなか中途半端な現状だけどな
UTF-16ってのが諸悪の根元か？
- 327 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:39:34 ]
- UTF-8 は尖兵
ユニコードとやらも意外と悪くないではないかとか思わせるために敢えて本筋を剥いだ草
- 328 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:48:30 ]
- I'm perfect soldier.
- 329 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:49:35 ]
- 草とか言うな(w
気がついたら UTF-8 ファイルと UTF-8 アプリケーションばっかで
他のエンコーディング系列に移行できなとかそんなのか
- 330 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:59:43 ]
- 最強の尖兵乙
- 331 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 11:03:52 ]
- >>321
最初からRejectKaigiを狙ってたんじゃないのか?
- 332 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 11:45:19 ]
- あああ、LTじゃなくてRejectKaigiか。
- 333 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:02:24 ]
- rubyってjisちゃんと扱えないのか。苦労するはずだわ。
ruby捨ててjavaでがんばる。
- 334 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:06:25 ]
- > rubyってjisちゃんと扱えないのか。苦労するはずだわ。
何の話をしてるの？
- 335 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:11:42 ]
- 一文字64bitの新文字コード作ろうぜ
- 337 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:24:59 ]
- >>335
そこが今ひとつわからんのだが、31bitあったのを21bit？にしたのは、
なにか技術的な要請があったの？
それとも、先行したUCS2に引きずられただけ？
256*256*17面（だっけ）にしたのは、どういうことなんだろう。
- 338 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 03:13:11 ]
- >>337
まず、31bitだったのはsigned int32ね。
0x10FFFFまでなのは、UTF-16の収録限界が由来で、
BMPの0xFFFF+サロゲートペアの(0xDC00-0xD800)*(0xE000-0xDC00)だから
- 339 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 06:35:23 ]
- そもそもUnicode自体がクソだろ
文字鏡をつかっていればあるいわ
- 340 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 07:24:13 ]
- 現実的にUnicodeより良い物があるの？
- 341 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 09:45:27 ]
- Unicode一本化されたとこから漸次さらに優れたものに移行すればいいじゃん
カオス状態がUnicodeのおかげでずいぶんましになってる所なのに
- 342 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:29:26 ]
- Rubyスレなのに気付いたらUnicodeの話になってた!
- 343 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:30:10 ]
- 文字コードの話はなぜか妙に食いつきがいい
- 344 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:35:23 ]
- 開発コアメンバが語るRubyの今とこれから（前編）
www.atmarkit.co.jp/news/200907/24/ruby.html
そろそろ1.8系から1.9に移るころなのかな？
- 345 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:35:10 ]
- >>341
Unicodeがある意味全てを終わらせてしまったので、
優れたものが出てくる余地はない。
Unicodeが優れたものなんじゃなくて、悪貨は良貨を駆逐するという意味で。
- 346 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:46:51 ]
- 日本の3つの文字コードへの対応ライブラリパッチのファイルサイズ見れば、色々間違いだと思えるようになるよ
>>344
なんでこう、ちょっとカッコいいポーズしてください写真なん？
や、写真使うのは取材側の人だから要望聞いたほうがいいんだけどさ
Ruby1.9 に移行するのは絶対に間違いない
問題は、そのためのライブラリサポートの手間をいつ誰が取るかだと思う
外国の人はいろんな意味で慎重な移行をやりたがらないと思うんで、
それこそマルチバイトユーザーで最大Rubyコミュニティである日本人の出番なのではないかと
英語のライブラリ作者向けガイド書いた人がどっかにいたが、ああいうの頑張るべきかもしれない
- 347 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:50:53 ]
- 弾子飼かと思った
- 348 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:55:37 ]
- とりあえず rubyrb1.9 test/ で Ruby1.9 対応完了とかほざく外人作者さんの調教から
古い rubygem でしか動かないライブラリが捨てられていくのと同じように、
Ruby 1.9 で実際上動作しないライブラリが捨てられていくようになればいいんだけど
- 349 名前：デフォルトの名無しさん [2009/07/25(土) 13:11:14 ]
- Railsが1.9でまともに動けば移行が進むんじゃね。
- 350 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 14:20:13 ]
- つまり asakusa.rb 期待 age?
- 351 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:38:39 ]
- >>344
記事内容とはまったく関係ないし、たぶん写真写りのせいだと思うんだが
2枚目の写真のYugui氏が怖い
- 352 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:39:58 ]
- UTFが、8859と互換なのが大きいからなあ。日本人が使えないって騒いだって、欧米圏は、もう他に移行はしないだろう。
- 353 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:48:08 ]
- >>344
率直に言って恥ずかしいな
写真が気になって記事が頭に入らない
- 354 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:49:35 ]
- >>352
使えるのに使いたくないって騒いでるだけじゃないかと
- 355 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:54:58 ]
- >>351
全てがマイナスに働いている、ある意味レア写真
著者近影に使ったら書籍自体が山積みでお祓いに出されるレベル
もうちょっちいいのなかったんかね
- 356 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 20:00:03 ]
- >>352
互換じゃないお
互換なのは ISO-8859-1 の部分だけだお
それ以外の 2 から 16 くらいまでの文字は、文字は入ってるけど互換性ないお
- 357 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 20:10:41 ]
- キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ
- 358 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 20:46:12 ]
- >>339
文字鏡はライセンスが問題になって以来、もうないと思うけどな
- 359 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 20:47:32 ]
- >>351
目が白目むいてるように見えるのが大きいんだろうな
- 360 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:26:04 ]
- ホントにキモイな。
Ruby関係って、他にもキモイやついなかったか?
- 361 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:32:55 ]
- 1.9っていうと開発版だから〜って思って2.0をずっと待ってた。
そんなに自信もって進められるなら2.0リリースしてくれよ。
- 362 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:42:04 ]
- インタビュー経由で疑問に思ったんだが、Rubiniusって結局何がどう嬉しくなるんだ？
・コードをそのままRubyオブジェクトにできる
・BSDライセンスになる
ことぐらい？
そもそも、CRubyの上で動くRubiniusが、CRubyより速くなるというのがよく理解できない
詳しい人がいればぜひ教えてほしい
- 363 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:45:51 ]
- まだ>>361みたなこと言ってるやつがいるのか
- 364 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:46:13 ]
- 1.9使ってたけどRailsを使う必要があったんで1.8に戻した。
1.8でも十分速いし、対応ライブラリも豊富だからこれでいいよ
- 365 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:49:18 ]
- みんな！民主党が大変な事になってるよ。
www.nicovideo.jp/watch/sm7737318
- 366 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:49:24 ]
- >>360
> 他にもキモイやついなかったか?
好きで使ってる奴でキモくない人間を一人も見たこと無いよ。
- 367 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:49:36 ]
- 一方おれは1.9でRailsを使っている。
特に大きな問題はなく今のところすべて回避できている。
回避できない問題もあるんだろうが。
- 368 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 22:52:45 ]
- >>362
対象の言語でVMを実装できるというところが「きれい」
- 369 名前：デフォルトの名無しさん [2009/07/25(土) 23:50:54 ]
- pythonってVMだったか？
Ruby VM より早いPythonってどうなんだろうね
- 370 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 23:51:03 ]
- 心の底から>>361と同意見
MatzはなぜRite=2.0にこだわるんだ
今の1.9.1を2.0にして、Riteを3.0にしたらいいのに
- 371 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 23:51:35 ]
- 【科学】道路に軍手が落ちているワケ、名城大研究チームが突き止める[09/07/24]
namidame.2ch.net/test/read.cgi/hidari/1225537555/
- 372 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 23:57:09 ]
- >>362
アルゴリズムによってはCで書かれたHaskellがCよりも速いのと一緒
- 373 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 04:16:25 ]
- 2.0 への思い入れ云々を除いても、バージョン1をバージョン2に上げるほどの何某があるとは思えん
1.9.1 の次くらいを 2.0 にするならまあアリかなと思う
1.9.1p0 の存在が鬱陶しいと思ってる人は少なくないはずだよ
- 374 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 04:27:31 ]
- 1.9.1 は本体オンリーはともかく第三者ライブラリ全体を含んだ便利度はまだまだだなー、と感じるわけだが、
これが 2.0 だった場合は「バージョン 2.0 とか言ってる割には全然…」だの
「2.0 はアレなので 2.0.4 以降インストールしてください」だのいうことになったと思う
今現在我々が 1.9.1 の使い勝手に抱いている感想は、
それのバージョンが 2.0 だったからといっていい方向に作用したと思われるものではない、はず
- 375 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 11:15:43 ]
- ttp://d.hatena.ne.jp/mrkn/20090717/rubykaigi2009_trap
ヒドスwww
- 376 名前：デフォルトの名無しさん [2009/07/26(日) 16:42:35 ]
- ささぴーひっどーぉい。（か☆わ★い☆い★女☆子★高☆生 より
- 377 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 17:06:50 ]
- うわぁ
- 378 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 19:52:21 ]
- おいtrunkのrakeやrdocやrubygemsは最新版にアップデートしないのか
- 379 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 20:11:05 ]
- ruby-coreでいえ
- 380 名前：デフォルトの名無しさん mailto:sage [2009/07/26(日) 21:03:56 ]
- アップデートしてくれる度にtest-allのエラー数が激増するんで困ってる
- 381 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 11:34:32 ]
- > Google App EngineではJRails on Rubyも動いてます。
> もうJVMでいいじゃんっていうことになる危機感は？
ここはまつもとさんじゃなく、
ささださんの回答が見たかった。
- 382 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 13:42:39 ]
- bigtableは独特だからなぁ
- 383 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 14:31:58 ]
- ここに書けばささださんの回答は得られる
|
 |
