Rubyについて Part 37 ..
[2ch|▼Menu]
372:デフォルトの名無しさん
09/09/25 15:13:24
既出かもしれないけど、Ruby1.9で巨大なオブジェクトに対して存在しないメソッドを呼び出そうとするとハングする・・・
エラーメッセージを生成するためにinspect呼び出してるせいみたいだけど、これタイムアウトか何か設けて欲しいわ

373:デフォルトの名無しさん
09/09/25 15:22:12
巨大な、て
インスタンス変数がめっちゃやたらあるとか、
ギガバイトサイズの文字列とか?

374:デフォルトの名無しさん
09/09/25 15:32:39
巨大っつったけど、実は大したことなかったりする・・・
頂点をあらわすオブジェクトが50個、辺を表すオブジェクトが200個くらいのグラフなんだけど
(辺はそれぞれ長さ1の文字列と頂点一つ、頂点は長さ10〜20の整数と辺の配列をもってる)
普通にプログラミングしてたら作られ得る規模だよね、これ

CPUはE8500だし言うほど古くないと思うんだけど、、、

375:デフォルトの名無しさん
09/09/25 15:37:55
そんな巨大プロジェクトにRubyを採用する方が悪い(キリッ

376:デフォルトの名無しさん
09/09/25 16:00:31
PHP使え

377:デフォルトの名無しさん
09/09/25 16:04:33
再現コードうpれば直るよ

378:デフォルトの名無しさん
09/09/25 16:06:16
>>374
> 頂点をあらわすオブジェクトが50個、辺を表すオブジェクトが200個くらいのグラフなんだけど
> (辺はそれぞれ長さ1の文字列と頂点一つ、頂点は長さ10〜20の整数と辺の配列をもってる)

再帰してんのか?

379:デフォルトの名無しさん
09/09/25 16:14:45
そのオブジェクトに自前のinspectメソッドを用意すればいいのでは

large_string = '巨大文字列' * 20 # 例えば*10000なんかだと表示が大変なことに
p large_string
def large_string.inspect
"#<巨大文字列 #<object_id:0x#{self.object_id.to_s(16)}> size=#{self.size}>"
end
large_string.foobar # => undefined method `foobar' for #<巨大文字列 #<object_id:0x156ad40> size=200> (NoMethodError)


380:デフォルトの名無しさん
09/09/25 16:22:30
inspectのオーバーライドはしたけど、
こういうオブジェクト作るたびに、エラーメッセージ対策のためにinspectオーバーライドするのはなんかなぁ・・・と

ちなみに、ある程度inspectの結果が巨大になると、かってに#<[クラス名]:16進数文字列>に直してくれるみたいだけど、
それならいっそのこと、inspectに時間がかかるケースも想定して欲しかった、と

class A; def inspect;"A"*10 end end
A.new.hoge ==> NoMethodError: undefined method `hoge' for AAAAAAAAAA:A
class A; def inspect;"A"*10000 end end
A.new.hoge ==> NoMethodError: undefined method `hoge' for #<A:0xcc8594>

381:デフォルトの名無しさん
09/09/25 16:34:21
>>374
グラフにループがあるとしたら、何も考えずに頂点と辺の関係をたどってたら無限ループ突入だろ

382:デフォルトの名無しさん
09/09/25 16:41:34
>>381
ビルトインのinspectって循環参照考慮してる筈だよね
380で言った「inspectのオーバーライドはしたけど」っていうのは、ビルトインのinspectのせいで止まるから
仕方なく自前で用意した処理の軽いinspectに置換したってこと

383:デフォルトの名無しさん
09/09/25 16:53:34
Object#inspect はインスタンス変数全部表示しようとするぞ
インスタンス変数がアホみたいに莫大だった場合はボトルネックになる

384:デフォルトの名無しさん
09/09/26 00:32:45
pp だと pretty_print_instance_variablesを定義して簡単に回避できるけど、
単なるinspect向けにそういうのはないの?

385:デフォルトの名無しさん
09/09/26 11:10:14
>>384は悪くないかもな。
あるいは
module Inspector
def inspect_member(name)
...
end
end
class LargeObject
extend Inspector
inspect_member :lines
end
とか

386:デフォルトの名無しさん
09/09/26 12:51:38
タイムアウトも悪くないけど、
速いマシンと遅いマシンとでinspectの結果やら
p の出力が変わったりするとそれはそれで地雷かもなあ

387:デフォルトの名無しさん
09/09/26 20:52:14
そういや、Matzにっきってもう更新されないの?

388:デフォルトの名無しさん
09/09/26 22:45:12
>>387
Ruby会議でその話になったときはTwitter見てっていってた。

389:デフォルトの名無しさん
09/09/26 23:07:24
TLをまとめてブログにポストするrubyスクリプトでも書いて
それで更新したらいいのに

390:デフォルトの名無しさん
09/09/26 23:11:54
そんなの読みたくない

391:デフォルトの名無しさん
09/09/27 09:18:31
twilog.org のこと?

392:デフォルトの名無しさん
09/09/27 10:02:00
Rubyによる並列処理システム
「CloudCrowd 0.1.0」リリース
URLリンク(codezine.jp)

393:デフォルトの名無しさん
09/09/27 13:27:33
>>388
twitter見てみたけど、便所の落書きみたいなことしか書いてなかった・・・
blogにもどってくれよん

394:デフォルトの名無しさん
09/09/27 13:42:49
そもそもTwitterは「基本ひとこと」「ログが長期間残らない」という点で
blogとは違ったものだしな
「Matzはblogの更新をやめた」と考えた方がいい

395:デフォルトの名無しさん
09/09/27 13:48:34
ブログを書く手間と時間はTwitterに消えてるんだろうな
Twitterってかなり一般的になってきたけど気が散って生産性落ちたりしないのかな

396:デフォルトの名無しさん
09/09/27 13:53:02
リアル雑談と同じようなご利益があります
同じようなご利益しかないとも言えます
同じような弊害があるとも言えるわけですが

397:デフォルトの名無しさん
09/09/27 14:25:25
iPhone持ちだし、Twitter興味はあるけどね
手を出すと集中して本読んだりコード書けなくなる自信がある

398:デフォルトの名無しさん
09/09/27 19:26:24
twitterも読みきれなくなってきた


399:デフォルトの名無しさん
09/09/27 19:33:50
>>394
>「ログが長期間残らない」
いや、残るけど?

400:デフォルトの名無しさん
09/09/27 19:36:22
どうせならここでつぶやいてよ

401:デフォルトの名無しさん
09/09/27 19:40:00
うむ
元祖便所の落書きとしては是非invitationを

402:メカMatz
09/09/27 19:40:13
Matz江なう

403:デフォルトの名無しさん
09/09/27 20:08:43
>>399
Twitterのログは途中で消えるよ
いやサーバに残ってるのかどうかは知らんけど、少なくともWeb上から見えなくなる

404:デフォルトの名無しさん
09/09/27 20:16:36
loopっていつの日かまっとうな制御構文に格上げされる可能性はないの?

loop

end
でいいやん

405:デフォルトの名無しさん
09/09/27 20:18:46
forさんよりも利用頻度が高いloop・・・

406:デフォルトの名無しさん
09/09/27 20:24:11
for や while はオプションがめんどくさいからな
お前は黙って無限ループだけしてりゃいいんだよというのを黙々とこなす loop

407:デフォルトの名無しさん
09/09/27 20:38:19
1.9だとloop doはwhile trueより格段に遅くて気に入らない
制御構文になったら違ってくるのかもしれないけど

408:デフォルトの名無しさん
09/09/27 20:45:42
>>403
Web上からも見えるよ

一覧上からたどれなくなるだけで
個別のエントリのURLを控えておけばいつでも参照可能。

409:デフォルトの名無しさん
09/09/27 21:29:44
>>407
そうなん?
ここに書いたらまたlength/sizeのときみたいに笹田さんが直してくれそうだな

410:デフォルトの名無しさん
09/09/27 21:31:55
最適化の書き換えの優先度が低いんだろ
放っておいてもいつか速くなると思われる

411:デフォルトの名無しさん
09/09/27 21:35:53
loopが、というよりyieldが遅いんでは?
最適化が本格化すると、loopをバイトコードレベルで
無限ループに書き換えるくらいはやってくれるだろう

412:デフォルトの名無しさん
09/09/27 21:36:01
よし、おまえらささださん方面に電波最大出力だ

413:デフォルトの名無しさん
09/09/27 21:36:27
「いつか」とか「本格化すると」じゃなくて、今速くして欲しいんだよね

414:デフォルトの名無しさん
09/09/27 21:41:53
今すぐ切実に早くしたいならwhile trueに書き変えろよw

415:デフォルトの名無しさん
09/09/27 21:42:32
>>413
Rubyのソースコード書き変えて再コンパイルしれ
たぶんいちばん早い

416:デフォルトの名無しさん
09/09/27 21:48:40
length/sizeって何があったの?
本人降臨したの?

417:デフォルトの名無しさん
09/09/27 22:02:53
>>414
切実に速くしたかったらCで書くだろJK
せっかく超高級言語つかってんだし、loop do endって書くキモチを
大事にしたいんだもん

418:デフォルトの名無しさん
09/09/27 22:19:41
むしろforが要らない子になってね?

419:デフォルトの名無しさん
09/09/27 23:03:27
rubyそのものを最適化オプションガリガリ付けてコンパイルすればいいんじゃね

420:デフォルトの名無しさん
09/09/28 06:44:34
if RUBY_VERSION >= '1.9.0' then
str.force_encoding(::Encoding::ASCII_8BIT)
end

について本スレで何かコメントでもあれば

421:デフォルトの名無しさん
09/09/28 07:01:52
今時thenなんて使わないよね

422:デフォルトの名無しさん
09/09/28 08:01:53
いや全然

423:デフォルトの名無しさん
09/09/28 08:05:40
thenだけにー

424:デフォルトの名無しさん
09/09/28 08:07:52
>>421
てめえちょっと表出ろ

425:デフォルトの名無しさん
09/09/28 08:10:26
::Encoding::ASCII_8BIT より "ASCII-8BIT" のほうが短くていいな

426:デフォルトの名無しさん
09/09/28 08:22:33
やたら短さだけに拘る人間の80パーセントはちんこ短い

427:デフォルトの名無しさん
09/09/28 08:25:15
        で
        ト
        ン
        セ
       |
       パ
       0
       2
      り
     残
    た
よかっ

428:デフォルトの名無しさん
09/09/28 08:34:26
respond_to?(:force_encoding) しろとか defined?(::Encoding) 使えとか言われてたな

429:デフォルトの名無しさん
09/09/28 11:29:54
A-Zでカテゴリ選んで
A-Zで登録アプリを26^2個呼び出せる
CUIなランチャ作ったけど起動が重いな。
Lightspeed Languageの登場が望まれる。

430:デフォルトの名無しさん
09/09/28 11:50:50
>>370
SafariというかWebkitの人が直してくれないから
URLリンク(bugs.webkit.org)

431:デフォルトの名無しさん
09/09/28 11:53:41
>>420
RUBY_VERSIONじゃなくて、>>428の言うとおりforce_encodingかEncoding見てください。

なお、勝手に俺バージョンのforce_encodingやEncodingを1.8で定義しないように。
その辺を見て分岐することが推奨されているので、MRI以外で死にます。

432:デフォルトの名無しさん
09/09/28 11:55:47
>>420 >>425
文字列リテラル使うとオブジェクトが増える。

433:デフォルトの名無しさん
09/09/28 11:58:19
ruby使ってんのに、小せえこと気にすんなよ

434:デフォルトの名無しさん
09/09/28 12:34:09
>>431
> 勝手に俺バージョンのforce_encodingやEncodingを1.8で定義しないように。
Javaでも使っとれ

435:デフォルトの名無しさん
09/09/28 12:40:57
1.8.7 で警告が出ない以上、>>431の主張はカス
Ruby 1.9 の Encoding が動作してくれないと困るのであるなら、そのように記述するべき
我々は実際には Ruby のメジャーバージョンを考慮しているのである以上、
スクリプトとしての記述もバージョンで分岐させるように書か「なければならない」

436:デフォルトの名無しさん
09/09/28 12:50:23
>>432
どっちかというと文字列から Encoding の特定の定数を決定する処理の負担のほうが嫌気されるのでは
毎回いちいち探させるくらいなら定数として最初から書いておいたほうがプログラム的に親切
.encode('utf8') や encode('sjis') って動作したっけ、encode('EUC-JP-MS') って使えるのか、とか悩む必要もなし
定数だった場合は間違ってれば Ruby が uninitialized constant で教えてくれる

437:デフォルトの名無しさん
09/09/28 12:52:46
初心者スレのだが、これくらい書けば問題ないのかも

if str.respond_to?(:force_encoding) && defined?(::Encoding::ASCII_8BIT) &&
str.respond_to?(:encode) && str.respond_to?(:encoding) &&
defined?(::Encoding::UTF_8) && str.class.new.encode(::Encoding::UTF_8).encoding == ::Encoding::UTF_8 &&
(_ = str.class.new.encode(::Encoding::UTF_8).force_encoding(::Encoding::ASCII_8BIT); _.encoding == ::Encoding::ASCII_8BIT) then
str.force_encoding(::Encoding::ASCII_8BIT)
end

438:デフォルトの名無しさん
09/09/28 13:06:30
「添付ライブラリにEncodingがあるなら」とか
「標準のStringがforce_encodingを持ってるなら」とか
そういう指定の仕方ができないんだよね
それを唯一担保するのがRubyのメジャーバージョンなんだから仕方ないわ

439:デフォルトの名無しさん
09/09/28 13:10:19
>>434 >>435 RailsとかtDiaryとかと混ぜた時に死にたいなら定義してもいいけど。

440:デフォルトの名無しさん
09/09/28 13:11:34
>>438
MRI以外のこと忘れてない?

441:デフォルトの名無しさん
09/09/28 13:17:37
>>440
respond_to? を通っても別のどっかで齟齬の例外が出てそもそも動かないことが逆に期待されるから別にいいじゃん(素

バージョン併用スクリプトの書き方のガイドは特急で作ったほうがいいかも

442:デフォルトの名無しさん
09/09/28 13:20:58
>>438
だからそれが>>428だろ

443:デフォルトの名無しさん
09/09/28 13:23:31
っ class Encoding; end


444:デフォルトの名無しさん
09/09/28 13:25:17
str.force_encoding(::Encoding::ASCII_8BIT) rescue str

よし解決
皆の者我に続け

445:デフォルトの名無しさん
09/09/28 13:26:17
1.9は文字コード面では完全に失敗だな。
2.0までにPython同様内部文字コードに変換する作りにしといてね。

446:デフォルトの名無しさん
09/09/28 13:38:28
String そのものにエンコーディング機能のメソッドを新たに持たせたのがめんどくささの原因な気もする
String のエンコーディング関連は Encode のメソッドからしか操作参照できないようにしておけばあるいは

447:デフォルトの名無しさん
09/09/28 13:58:21
>>445
Pythonのucs2/ucs4絡みとかUnicodeString絡みとか見ておいで

448:デフォルトの名無しさん
09/09/28 14:13:51
>>446
いや、1.8互換ってのが茨の道なんだと思うけど。
> String のエンコーディング関連は Encode のメソッドからしか操作参照できないようにしておけばあるいは
他の言語ならそうしたかもね。

449:デフォルトの名無しさん
09/09/28 17:09:38
だれだよ UTF-8 とか中途半端なの作ったやつ

はじめから 32bit ぐらいの幅にして、世の中の全種類の文字を一意に判定、
かつ少しぐらい文字が増えてもいいようなテーブル作っておけばよかったんだ

450:デフォルトの名無しさん
09/09/28 17:10:03
つ UCS-4

451:デフォルトの名無しさん
09/09/28 17:15:27
中途半端感がひどいのはUTF-8じゃなくてUTF-16だな

452:デフォルトの名無しさん
09/09/28 17:15:34
>>449
UTF-8はUnicodeのエンコーディング方法の1つでしかない。


453:デフォルトの名無しさん
09/09/28 17:21:34
UTF-8はこれでもずいぶんマシなんだよ
UTF-8以外のUnicodeや広域文字実装を実質全く見ないのがその証拠
どんなに理想的でも、利用されないと意味がない
そういう意味で大変戦略的な「とてもマシ」な代物

454:デフォルトの名無しさん
09/09/28 17:23:16
どこの世界の話ですか

455:デフォルトの名無しさん
09/09/28 17:23:18
>>448
「1.8」なんて存在しないだろ
あるのはオブジェクトがrespondするかどうかだろ

456:デフォルトの名無しさん
09/09/28 17:31:18
>>455
まあ、これまでの理屈で言えばそうだな
1.8用や1.9用というバージョン分けの理由はないはず

457:デフォルトの名無しさん
09/09/28 17:32:48
もう1文字4byteのRubyEncodingを策定しようぜ

458:449
09/09/28 17:38:33
Unicode と UTF-8 という言葉をほとんど同義に使っていたけど、
もしかして違うの?

たしかに UTF-16 とか UTF-32 とか、UCS2 とか UCS4 という単語は聞いたことがあって、
どう違うのかはわかっていなかったけど

>>457
はげどう

でも ASCII オンリーな環境の時は、だいぶ無駄になっちゃうね

459:デフォルトの名無しさん
09/09/28 17:45:44
>>458
語弊を恐れず一言で言えば概念と実装

460:デフォルトの名無しさん
09/09/28 17:46:37
>>458
Unicodeってのは、規格群の総称のような感じで、
UTF-*は文字符号化形式及び文字符号化スキーム
UCS-*は符号化文字集合

461:デフォルトの名無しさん
09/09/28 17:55:38
世界中のあらゆる文字に文字コードという数字を割り振ったのがUnicode
そのUnicodeをバイト列表現する(エンコードする)やり方が何種類かあってそれがUTF-*

って理解をしているんだけど

462:デフォルトの名無しさん
09/09/28 18:25:10
>>449
前に書いた記事を読んでください、わからないところがあれば答えます。
URLリンク(gihyo.jp)

>>459
UnicodeはUTF-8を含むので違う。(ISO 10646はおいておいて)

>>460
おおむね正しいんだけど、UCS-2とUCS-4も文字符号化表現なんだよね。
URLリンク(d.hatena.ne.jp)

>>461
基本的に正しい。
世界中の文字を集め、Unicode scalar valueという数字を割り振り、
さらにその他文字を扱うのに必要な規格を定義しているのがUnicode。
その他の規格っていうのは、例えば「だいたいこれとこれは同じ意味の文字」
って処理をするための「Unicode正規化」とか、大文字小文字変換とか。
この辺まで定義しているのがUnicodeの凄いところ。
URLリンク(www.unicode.org)

先述の通り、UTF-*だけじゃなくて、UCS-2とUCS-4もバイト列表現するためのやり方。

463:デフォルトの名無しさん
09/09/28 18:43:33
>>456
じゃあバージョンとか本当はいらないんじゃね?

464:デフォルトの名無しさん
09/09/28 18:52:08
>>463
スクリプトの実行者はスクリプトが実行されているシステムのこともRubyのことも知っていて
スクリプトを適宜修正可能であるというモデルを暗黙に設定してるのは確か

“お客様”であるという前提はあまりしてないはず

465:445
09/09/28 18:55:19
>>447
見た上で言ってるんだが?
この点ではPythonは完璧。

466:デフォルトの名無しさん
09/09/28 18:59:56
>UnicodeはUTF-8を含むので違う
概念は実装を含むと思うけど
仕様と実装のほうがよかった?
たとえばRubyと言えばMRIを含む(指す)ように

まあ一言なんて所詮はたとえ話みたいなもんだw

467:デフォルトの名無しさん
09/09/28 19:04:05
>>464
例外出たら自分の環境に合わせて修正してもらえればいいんじゃね、というスタンスではある
rescue もいわゆるバージョン差異を埋めるために使うものじゃないわけでさ

468:デフォルトの名無しさん
09/09/28 19:04:41
>>458はMatzのコードの世界を読むべき

469:デフォルトの名無しさん
09/09/28 20:24:45
>>463
バグ報告対応で使います。

>>465
URLリンク(dsas.blog.klab.org)
この辺とか。
まぁ、言語を実装する側にとってもUCS正規化の方が楽だけどね。

>>466
なんか「抽象」は「具体」を含むと言っているように聞こえるんですが

470:デフォルトの名無しさん
09/09/28 21:38:09
今日の名言

  概 念 は 実 装 を 含 む


471:デフォルトの名無しさん
09/09/28 22:58:07
Rubyを支えるYuguiの自信 「最後にはわたしがいる」
URLリンク(jibun.atmarkit.co.jp)

Yuguiさんかっけええええええええ

472:デフォルトの名無しさん
09/09/28 23:12:18
Yugui△

473:デフォルトの名無しさん
09/09/29 22:51:18
yugui さん かっく

足りねえぞおい

474:デフォルトの名無しさん
09/09/29 22:55:22
セクシーと言ったほうが喜ぶんじゃまいかい?

475:デフォルトの名無しさん
09/09/29 22:58:04
>>473
さんかっけー
(ボケだったらスルーしてくれ)

しかしいい写真だな

476:デフォルトの名無しさん
09/09/29 23:00:55
かっけー、のはいいとして、previewとか全然出てないんだけどどうなったんすか?

477:デフォルトの名無しさん
09/09/29 23:08:00
>>476
RubyWorld conf での議論を受けて、スケジュール切り直し。
後日開発者会議で決定。
RubySpec全パスを目指すみたい。[ruby-core 25707]

上のメールで触れられている開発者会議は10月13日にダイビルで開催。
[ruby-dev:39404][ruby-core:25841]


478:デフォルトの名無しさん
09/09/30 00:57:05
裸の王様ごっこはいつ終わるのですか?


479:デフォルトの名無しさん
09/09/30 08:16:38
>>478
自分の妄想に正面から向き合う勇気を持てよ

480:デフォルトの名無しさん
09/09/30 09:23:06
>>471
関連記事で気づいたんだが、富田倫生の「パソコン創世記」
@itが連載形式で掲載してたんだな。

全文、青空文庫で読めるわけだが。

481:デフォルトの名無しさん
09/09/30 09:56:09
コレまじすか

【島根】 プログラミング言語「Ruby」開発者ら3人を松江市名誉市民に
スレリンク(newsplus板)


482:デフォルトの名無しさん
09/09/30 10:04:43
おお、クレヨンしんちゃんなんかと一緒ですな

483:デフォルトの名無しさん
09/09/30 15:59:07
島根県マジだな

484:デフォルトの名無しさん
09/09/30 16:25:20
負けるな取烏

485:デフォルトの名無しさん
09/09/30 19:37:11
そして久しぶりにMatzにっきが更新された

486:デフォルトの名無しさん
09/10/01 00:02:02
こっそりここ見てるんじゃないのか?w

487:デフォルトの名無しさん
09/10/01 00:04:42
日記の内容的にそれはないと思うけど。


488:デフォルトの名無しさん
09/10/01 00:09:23
【島根】 プログラミング言語「Ruby」開発者ら3人を松江市名誉市民に
スレリンク(newsplus板)

489:デフォルトの名無しさん
09/10/01 00:55:13
プログラミング言語で村おこしとかすげえな
過疎で悩んでる地域はIT会社の誘致とかしろよ
ほとんどオンラインで出来るから場所は関係ないしな

490:デフォルトの名無しさん
09/10/01 03:10:02
ほとんどオンラインでできるなら会社の社屋は都会にあったほうが便利
これまめちしきな

491:デフォルトの名無しさん
09/10/01 03:54:34
家賃

492:デフォルトの名無しさん
09/10/01 04:01:39
>>491
お前都会でしかネット使ったことないだろ

493:デフォルトの名無しさん
09/10/01 04:11:43
NTTの支店があるような市でならうまくいく可能性はあるな
田舎は下手すりゃISDNだったりするからある程度都会だったほうがいいのは事実
社員集まれと言ったときにJRの駅がないとか非常に困る

494:デフォルトの名無しさん
09/10/01 04:23:10
じゃあ間をとって地方都市の中心市街だな。
別に松江でいいじゃん。

495:デフォルトの名無しさん
09/10/01 04:34:56
だからJRの駅がないと駄目だって言ってんだろ

496:デフォルトの名無しさん
09/10/01 05:42:21
おまえJRってどういう意味で使ってるの?
旅行でビジネスホテル使ってもかなりブロードバンド引いてあるし
家の中にばっかいないで外に出ろよ

497:デフォルトの名無しさん
09/10/01 07:54:32
>>496の考えてる田舎は既にかなり都会である件

498:デフォルトの名無しさん
09/10/01 08:25:59
>>496
お前こそJRをどういう意味で使ってるんだ
駅だぞ? ブロードバンドが引いてあろうが何だろうが
交通手段が無いところでIT会社が成長するのは難しすぎる

499:デフォルトの名無しさん
09/10/01 08:34:10
松江ってJRの駅ないの?

500:デフォルトの名無しさん
09/10/01 08:36:45
>>499
JRの駅くらいしかない。


501:デフォルトの名無しさん
09/10/01 08:38:23
普通に山陰本線だが、どうも>>498は新幹線とでも言いたいのではないかという気がして仕方がない

502:デフォルトの名無しさん
09/10/01 08:46:17
松江厨が空気読めないレスをしております

503:デフォルトの名無しさん
09/10/01 09:11:31
松江にJRの駅があるなら
初めから会話が成り立ってないな

504:デフォルトの名無しさん
09/10/01 09:19:55
一畑も忘れんなよ

505:デフォルトの名無しさん
09/10/01 09:23:21
セリーヌの金ピカ自転車に乗ってくるので交通手段の問題はありません

506:デフォルトの名無しさん
09/10/01 11:54:31
日本にJRの駅がない県庁所在地はないだろ…
と思ったら、那覇があったか。

507:デフォルトの名無しさん
09/10/01 13:26:38
>>494
確かに>>490は「都会」とは言ってるが「首都圏」とまでは言ってないからな

508:デフォルトの名無しさん
09/10/01 15:56:30
ちょっと質問
Ruby1.8 と Ruby1.9 で併用するスクリプトで文字列のエンコーディングの変換をしたいんだけども
Ruby1.9 では String#encode を使ったほうがいい?
共通で使えるから Iconv.conv でいいやーとかはダメ?

509:デフォルトの名無しさん
09/10/01 17:57:42
隣の机でもメールで会話してるアフォPGも居るから、
距離は微妙だな。
客は大都市圏のほうが多いから、営業と打ち合わせは大都市に事務所無いとコスト掛かるな。

510:デフォルトの名無しさん
09/10/01 18:02:18
>>508
併用かつ常に同じiconv実装を使える保証があるならIconvでいいと思う。
保証が無くて、CP932やCP51932くらいしか使わないのだったらNKFの方がよい。
どちらでもないなら場合によるかなぁ。

511:デフォルトの名無しさん
09/10/01 20:21:07
1.9でYAML.loadしたらハッシュはYAMLに書いた順番通りになりますか?

512:デフォルトの名無しさん
09/10/01 20:44:52
>>510
そういえば1.8の$KCODEって
sはCP932,eはCP51932を期待していいもんなんだろうか
なんとなくWindowsは期待していい気がするけど他OSだと微妙な気がしてきた

513:デフォルトの名無しさん
09/10/02 11:34:22
Ruby1.9 で日本語文字列を inspect するとコンソールのエンコーディングによっては前時代的に表示が崩れるよね
Ruby1.8 の時より退化してるような気がしなくもないんだが、なんか超賢い irb の設定とかある?

514:デフォルトの名無しさん
09/10/02 11:43:54
>>513
$ irb1.9
irb> p "うんこ".encode('UTF-8')
"うんこ"
irb> p "うんこ".encode('Shift_JIS')
"????"
irb> p "うんこ".encode('EUC-JP')
"????"
$
$ irb1.9 -Eutf-8
irb> p "うんこ".encode('UTF-8')
"うんこ"
irb> p "うんこ".encode('Shift_JIS')
"うんこ"
irb> p "うんこ".encode('EUC-JP')
"うんこ"

$stdout の external encoding を irb 内で直接切り替えてもよさそうだが方法がよくわからんかった

515:デフォルトの名無しさん
09/10/02 12:57:37
新時代的に日本語文字列はUTF-8しか使わないというのでどうだろうか

516:デフォルトの名無しさん
09/10/02 13:09:20
defaukt_external の正しそうな使用法を見た気がする
irb で実行されたファイル保存なんかが UTF-8 に切り替わる危険性はあるが

517:デフォルトの名無しさん
09/10/02 15:51:25
$stdin.set_encoding("locale")
$stdout.set_encoding("locale", undef: :replace, invalid: :replace)
$stderr.set_encoding("locale", undef: :replace, invalid: :replace)


518:デフォルトの名無しさん
09/10/02 16:40:11
ぎゃー set_encoding なんて組み込みクラスにあるのか
メソッド名変えないと

519:デフォルトの名無しさん
09/10/02 16:54:49
例外が起こらない begen ... rescue ... end は処理遅いですか?
begin ... end で括っただけでやや重いとかそういうことってある?

520:デフォルトの名無しさん
09/10/02 17:02:35
初心者スレじゃないんだしまず自分でベンチ取ってみろよw
たぶん、その重さが気になる状況ならRuby自体やめろっていう程度だと思う

521:デフォルトの名無しさん
09/10/02 17:15:25
>>518
自作メソッドが微妙に似た機能で全く同じ名前だと困るよね

522:デフォルトの名無しさん
09/10/02 17:17:46
あんだば入れるかどうかって何か決まりがあるの?

523:デフォルトの名無しさん
09/10/02 17:19:59
RubyであえてHigh Performance RubyやEffective Rubyみたいな本を読みたい
もう出てたりする?

524:デフォルトの名無しさん
09/10/02 17:23:51
rubyのメソッド名で単語区切りに入れる
定数(マジックナンバー的な意味での)も同様
camelCaseは使わん

525:デフォルトの名無しさん
09/10/02 18:18:06
メソッドは小文字でアンダースコア区切り
クラス・モジュールはUpperCamel
それ以外の定数は大文字でアンダースコア区切り
例外はString()とかInteger()とか

526:デフォルトの名無しさん
09/10/02 19:45:08
>>523
ホットスポットをCモジュールに切り出せ、以上、で終わってしまうので、
そういう本は出ない。てかEffectiveじゃなくてEfficient?

527:デフォルトの名無しさん
09/10/02 19:48:16
るびまでパフォーマンスチューニングねたいっぱいやってたじゃん

528:デフォルトの名無しさん
09/10/02 19:57:57
>>523
アプリケーションレベルでの高速化(キャッシュとか並列化とか)はよく聞くけど
Rubyプログラムの高速化はあんまり聞かないなあ。

「Ruby 速い」でぐぐったらるびまの記事とかあったけど、求めるものとは違うかも。
URLリンク(jp.rubyist.net)

529:デフォルトの名無しさん
09/10/02 20:54:02
ライブラリ名は _ と - か混在してカオス状態

530:デフォルトの名無しさん
09/10/02 20:58:29
もうだめかもわからんね
5冊も参考書買ったのに

531:デフォルトの名無しさん
09/10/02 21:06:03
>>529
Rubyの標準添付ライブラリを見てくれていれば
- (ハイフン)が標準だということは分かっただろうに・・・

wx_sugar、お前のことだ

532:デフォルトの名無しさん
09/10/02 21:42:52
個人的は(C++ みたいに)言語の変数に使える記号のみで
ライブラリ名も命名されてる方が一貫性があって好み

というわけで、最近書くRubyライブラリ名はみなアンダースコア
区切りに統一した

533:デフォルトの名無しさん
09/10/02 21:55:20
>>532
頼むからやめてくれ
もうこれ以上、require書くときに「ハイフンだっけアンダースコアだっけ」とか悩みたくない

534:デフォルトの名無しさん
09/10/02 21:55:56
いるよね個人的趣味でデファクトスタンダード破る奴

535:デフォルトの名無しさん
09/10/02 21:57:25
>>532
まっとうな判断だと思う
どうせクラス名・メソッド名になればハイフンは使えないんだし、無意味な脳内変換が必要になるだけ

536:デフォルトの名無しさん
09/10/02 22:03:22
統一されていないのが一番厄介なんだよな
空気呼んでくれ

537:デフォルトの名無しさん
09/10/02 22:46:53
C の #include 同様 require の引数も所詮ファイル名なんだから、どちらでも気にならんな。

538:デフォルトの名無しさん
09/10/02 22:57:20
脳味噌が欠乏している人はそんなことでも気になるんだよ

539:デフォルトの名無しさん
09/10/02 23:14:43
Rails脳だとActiveSupportの自動ロード(*)に毒されているので
アンダースコアを使う。

const_missing 時に Foo::BarBaz → foo/bar_baz と変換した
名前で require する機構がある。


540:デフォルトの名無しさん
09/10/03 04:57:11
いるよね個人的趣味でデファクトスタンダード破る奴

541:デフォルトの名無しさん
09/10/03 05:07:53
・ require がハイフンとアンダースコアと空白を同一視すべきだった
・ ActiveSupport はハイフンに変換すべき
・ 必要なのはファイルではなくクラスやモジュールである以上ファイル名に依存するのが糞
・ マニュアル読まずにライブラリ使おうとすること自体が間違い

どれか選ぶよろし

542:デフォルトの名無しさん
09/10/03 05:14:43
require 'a と書いた時点でディレクトリ走査して
候補を表示するサポートがあってもいいかな、と思うことはちらっとある

543:デフォルトの名無しさん
09/10/03 05:29:39
前田さんのところのコーディング規約はハイフンだね
URLリンク(shugo.net)

544:デフォルトの名無しさん
09/10/03 05:33:53
どれでも良「かった」んだよ
その中からRubyはハイフンを選んだわけで
娘を人質にとられてるとかそういう事情があるのでない限り
利便性を捨てる理由がないのならハイフンにするのが無難

545:デフォルトの名無しさん
09/10/03 05:57:45
教祖がハイフンと逝ったから、信者の皆さんはハイフンを使わないと地獄に堕ちるだけ。

546:デフォルトの名無しさん
09/10/03 07:32:06
なんかもう目眩がしてきた
all_load_paths-c.yaml

547:デフォルトの名無しさん
09/10/03 09:22:01
>>535さんの作るライブラリのクラス名はハイフン区切りなんですねさすがです

548:デフォルトの名無しさん
09/10/03 09:40:28
アンスコの間違いでは

549:デフォルトの名無しさん
09/10/03 09:44:36
Ruby歴はけっこう長いんだけど低いレベルで安定しちゃってて
全然進歩がない。それで困ってないといえば困ってないんだけど。
開くたびに違うTIPSや小ネタ表示してくれるサイトとかってないですか?

550:デフォルトの名無しさん
09/10/03 09:59:50
困るような問題にぶつかれ
困るような問題が無いならそれでいいじゃないか

以上

551:デフォルトの名無しさん
09/10/03 11:33:13
>>549
レシピブックをひととおり読んでみるとか

552:デフォルトの名無しさん
09/10/03 12:03:33
>>551
どのレシピブック?

553:デフォルトの名無しさん
09/10/03 14:32:53
初心者スレ見てると、このぐらい簡単だろと回答してみようにも意外ときれいに書けなかったり
これ初心者に役立つのか?とは思いつつも盲点をつかれたような回答がついたりと
為になることもままある
さっぱりなときも多いけどw

それはともかく他人のコード読みまくるのが一番だと思うよ

554:デフォルトの名無しさん
09/10/03 14:37:06
そこまで労力かけたくないって話だろう

555:デフォルトの名無しさん
09/10/03 14:39:55
自分が使うライブラリのコード読むだけでずいぶん効果あるんだけどな
それもブラックボックスで困らないというなら、その程度で身の丈に合ってるんじゃね

556:デフォルトの名無しさん
09/10/03 14:51:08
アンテナ作りたいんですけどhtmlパーサっぽいのないですか
ぐちゃぐちゃのhtml渡してもパースエラー吐かずにがんばってくれるのがいいです

557:デフォルトの名無しさん
09/10/03 15:07:14
ぐぐれ
それすらできんのでは成功はない

558:デフォルトの名無しさん
09/10/03 16:27:53
最初にLINT噛ませて成形してパーサに喰わせればいいんじゃね。
方言を標準語に直して字句解析すればおk。

559:デフォルトの名無しさん
09/10/03 16:49:46
そのへんは、firefox (かIE)に渡すのが一番だという結論になってたはず

560:デフォルトの名無しさん
09/10/03 23:01:42
>>556
htmlsplit

>>557
ライブラリに関しては、探しても見つけられない
(or 良くないものを見つけて満足してしまう)
ことがよくあるので、人に聞くべきだと思う

561:デフォルトの名無しさん
09/10/03 23:25:46
Ruby 1.9.2 のリリース延期かよ・・・

まあ、分かっちゃいたけど下手したらさらに1年後くらいになりそうだな

562:デフォルトの名無しさん
09/10/04 00:39:11
リリース延期てなんかあったの?

563:デフォルトの名無しさん
09/10/04 00:46:43
>>562
延期というかリスケ。[ruby-core:25707]
決まるのは10/13の会合で。[ruby-core:25841]



564:デフォルトの名無しさん
09/10/04 14:33:48
うんこでもいいから毎年一回だしてほしいなあ

565:デフォルトの名無しさん
09/10/04 14:40:58
previewとか1.7系みたいなのならいくら出してもかまわないけど
正式版でうんこは臭うからやめてくれ

566:デフォルトの名無しさん
09/10/04 14:42:00
正式版でもどうせたいしたことないし
リリースが質を高めるモチベーションになってるからさ

567:デフォルトの名無しさん
09/10/04 14:43:35
matzにっきが再開?

568:デフォルトの名無しさん
09/10/04 16:09:14
しかし1.9系は1.9.2からが本番だから
1.9.2はなるべく早く出して欲しいなぁ

569:デフォルトの名無しさん
09/10/04 16:45:42
バージョン番号が1増えたからといってどうかどうにかなるもんでもあんめえ
「それ」はおそらく1.9.1でも充分に行えるはずだし、そうしておくべき

あと RUBY_VERSION >= '1.9.0' の問題は公式にコメントなりガイドなりあったほうがええぞ

570:デフォルトの名無しさん
09/10/04 16:49:24
>>569
ここに書いて解決する可能性は低いと思う

571:デフォルトの名無しさん
09/10/04 16:54:56
>>569
どうにかなるんだよMerbユーザにとっては

1.9.2を待ってる人は相当多いと思う

572:デフォルトの名無しさん
09/10/04 17:20:29
再利用型メソッド上書きにまつわるエトセトラと同じような問題だと思ってる > RUBY_VERSION >= '1.9.0'

alias _old_hoge hoge
def hoge
 old = _old_hoge
 ...
end

だとまずい、みたいな

573:デフォルトの名無しさん
09/10/04 17:25:55
まー、
「提供されてるそのまんまのはずの機能を使ってごく素直に記述して“きちんと動作する”のに怒られる」
という点では似ていなくもない

574:デフォルトの名無しさん
09/10/04 17:29:01
>>569
結局「バージョン番号分岐でもdefined?でもどっちでもいい」って方向で
まとまったんじゃなかったけ

575:デフォルトの名無しさん
09/10/04 17:31:04
rubyなんて1.68で充分だろ

576:デフォルトの名無しさん
09/10/04 17:32:05
>>569>>572もダメな理由がわからない\(^o^)/

577:デフォルトの名無しさん
09/10/04 17:44:28
>>574
各々で動作しない場合の理由の例示というのはあってもいいかな、と思う
動作しない場合を踏まえた上で利用するのは全く問題あんめえ
defined?(Encoding) は Module::Encoding が include されてると誤爆するから defined?(::Encoding) と書け、とか
str.respond.to?(:force_encoding) は ::Encoding の存在を保証しないから defined?(::Encoding) にしとけ、みたいな

RUBY_VERSION が駄目な理由は結局明示されなかったが

578:デフォルトの名無しさん
09/10/04 17:52:51
あー、>>420-のことか

579:デフォルトの名無しさん
09/10/04 18:14:40
つか、 Ruby 1.9.1 を名乗っておきながら特定の標準ライブラリが動作しないなんてのは
スクリプト作者が考慮することじゃない気がしてならない
そのプラットフォームで Ruby を使用する利用者側が、各々の環境における代替手段を追記すべき

580:デフォルトの名無しさん
09/10/04 19:10:24
現時点で1.9系専用の(文法ではなく)機能を要求するからといってバージョンに依存した判定をすると
例えば1.8系にコンパチの機能がついて要件を満たした時に、無駄に1.9系を要求することになるから微妙だという話じゃなかったっけ

あとはMRI以外の実装がバージョン番号と機能が一致しないんじゃないかって話とか
そのへんは事情がよくわかんないけど

581:デフォルトの名無しさん
09/10/04 19:14:40
現時点では 1.9.1 と 1.8.7 と 1.8.6 しかないのにね
「1.8.8.ではどうなるかわからないだろ」なんてのは今議論されてもそいつが困るだけのはずなのに

582:デフォルトの名無しさん
09/10/04 19:31:20
RUBY_VERSION のいいとこは、でかい if 文で括れるところだろ
機能 A は存在するが機能 B は存在しない、というような複雑な状況を無視できる
本当に respod_to? と defined? を使っていったら可読性は限界まで下がるぞ

583:デフォルトの名無しさん
09/10/04 19:34:01
Ruby.has_encoding? みたいなのがあればよかったんでないか

584:デフォルトの名無しさん
09/10/04 19:37:35
RUBY_VERSIONよりdefined?がいいという理由は
1. >>580
2. 「Encodingが必要だ」という意図が分かりやすい
の二つが今まで挙がってたはず

両方とも一長一短あるし、俺はどっちでもいいと思うよ

>>582
Encoding関連以外に、if文で分岐しないといけないような機能ってないのでは

585:デフォルトの名無しさん
09/10/04 19:45:25
Encoding は String クラスと Encoding クラスの両方に影響して
なおかつ iconv とかも必要として実装依存だから例外中の例外とも言える

でも使用前に返り値が Enumerable かどうか確かめるとかいうのはめんどいぬ

586:デフォルトの名無しさん
09/10/04 19:49:18
Object#tap 使うたびに Object.new.respond_to?(:tap) を調べるのはやだなあ

587:デフォルトの名無しさん
09/10/04 19:56:44
tap使ったスクリプト書く度にバージョンチェックするのもいやだぞw
そういうのは例外で動作止まるのを期待してノーチェックでいいだろ

588:デフォルトの名無しさん
09/10/04 20:00:40
>>586
tap程度なら、ない環境を検出したら自前の定義を提供すればいい。


589:デフォルトの名無しさん
09/10/04 20:05:28
if RUBY_VERSION >= '1.9.0'
require '1.9/main.rb'
else
require '1.8/main.rb'
end

これが許されざるよなのが辛い
実質2バージョンを並行管理しないといけないのも辛いが

590:デフォルトの名無しさん
09/10/04 20:11:40
実際問題としては「Ruby1.9ぽく書きたい」のでない限り、併用スクリプトでは問題にならないはず
文字列とIOだけは別途処理しないとどうにもならないが

591:デフォルトの名無しさん
09/10/05 08:16:44
>>583
だね。どんなフューチャーがサポートされてるか、って観点だとそれが一番きれい。
当面はそういうgemを作って凌ぐとして、
次の1.9系、1.8系リリースで入らんもんかね。


592:デフォルトの名無しさん
09/10/05 08:33:16
>>591
今入っても、もう遅いだろう
動く環境と動かない環境があるのでは……

というか、もし1.9.1の時点でhas_encoding?が入っていたとしても
そのメソッドは1.8.0や1.6.xでは動かないのだから
どちらにしても、あまり役に立たないと思う

593:デフォルトの名無しさん
09/10/05 08:34:17
フューチャーだから未来のために入れるんじゃないのか

594:デフォルトの名無しさん
09/10/05 08:52:20
フィーチャー?

595:デフォルトの名無しさん
09/10/05 08:53:06
ときどき futuring 誰それ って書いてあるのを見るとかわいそうに思う。


596:デフォルトの名無しさん
09/10/05 08:53:17
バージョンチェックはアフォっぽい所は有るな。
バージョンチェック部分の記述だけで10バージョンぐらい比較してたりしてw

597:デフォルトの名無しさん
09/10/05 08:58:18
いまさらC言語が30年前に解決している問題で揉めるなんて…

598:デフォルトの名無しさん
09/10/05 09:02:21
「どんな未来がサポートされているか」
なんだかかっこいいな。

599:デフォルトの名無しさん
09/10/05 09:03:18
autoconf系だと、小さなプログラムをコンパイルして
期待どおりの動作をするか(エラーが出ず、出力も想定どおりか)
チェックしてたりするな。

600:デフォルトの名無しさん
09/10/05 09:48:45
>>599
1.8 と 1.9 ではインストールされるファイルが違うという rubygem は前どっかで見た
面倒だからほとんど行われてないけど

まあこのスレの論理で言うとバージョンでの分岐や
ライブラリインストール時の環境固定でチェックするなんてことは
あってはならないわけだが(w

あくまで実行時にすべてがチェックされるべきであり

601:デフォルトの名無しさん
09/10/05 10:31:45
どっちかってと
「メソッドの存在は一緒だし返り値のクラスも同じなのだが返り値の具体値が 1.9 と 1.8 では違う」
というような場合に、非 RUBY_VERSION 派はどう書くのか知りたい

602:デフォルトの名無しさん
09/10/05 10:38:41
具体的には?

603:デフォルトの名無しさん
09/10/05 10:45:22
ちょっと考えてたんだが、なんだろうね
String#inspect あたりは違うかもしれん
defind?(::Encoding) の範疇かどうかがちと微妙

604:591
09/10/05 11:35:02
>>594
あばばばば

W-ZERO3から入力したから!!入力補完とバック・トゥ・ザ・フューチャーが悪いんや!!!
(顔を真っ赤にしながら)

で、gemについては
・どうにかしてある機能が実行環境下で存在するか判定
・機能の有無をFeature.has?(Synbol)とかそんな感じでチェックできるように
なんてgemを作っておいて、機能の有無で処理を切り分けたい側は
このgemに依存関係を与えておくと。

とはいえ、俺も文字コード関連のほかにはFiberぐらいしか
嬉しいところが思いつかないけどね。



605:デフォルトの名無しさん
09/10/05 11:46:49
動作チェックした環境をコメントに書いとくだけでいいよ

606:デフォルトの名無しさん
09/10/05 12:09:36
>>602
Class#name。
[1.8] Class.new.name # => ""
[1.9] Class.new.name # => nil

607:デフォルトの名無しさん
09/10/05 12:37:02
俺も>>584に同意で、>>601みたいなケースがあったなら素直にバージョン判定でいいじゃない
そこでdefine?使う理由がないし、>>603三行目はdefine?派の主張ねじまがってないか?w

ただライブラリなりアプリなりのユーザが制御する方法を用意すれば
判定方法にこだわる必要なくなるんじゃないかとずっと考えてた

# 1.9の場合
require 'hogelib'

# 1.8の場合
require 'hogelib/compat-1.8'
require 'hogelib'

1.9指定もなにかrequireさせて、単体呼び出しは自動判定というインターフェイスのほうがいいのかな?
「自動判定手段に納得いかないなら手動ないし自作コードで判定しろよ」と言えるようになる

requireするファイルの中身は依存コードをモジュール化して切り出す方が理想っぽいけど
めんどくさいしフラグ立てておけば十分だろうw
COMPAT_1.8 = true


608:デフォルトの名無しさん
09/10/05 12:45:45
ならsite_ruby/1.8とsite_ruby/1.9.1にインストールしろよ。

609:デフォルトの名無しさん
09/10/05 12:57:25
>>608
>>455

610:デフォルトの名無しさん
09/10/05 14:56:48
1.8は捨てろ。
1.8はもうダメだ。終わった。
1.9で動かないrubyプログラムは捨てろ。書き直せ。


611:デフォルトの名無しさん
09/10/05 19:54:36
走れ描け走れ走れ

612:デフォルトの名無しさん
09/10/05 19:58:20
mswin32でユニコードファイル名扱えるようにしておくれ。

613:デフォルトの名無しさん
09/10/05 20:04:48
>>610
最近始めたんだけど、そんなに違うの?


614:デフォルトの名無しさん
09/10/05 20:12:59
>>613
文字列の文字エンコードとファイルIOが、互換性保ちつつ書くのがとてもめんどくさいレベル
1.8のほうが普段遣いの範囲では直感的なので、1.8で慣れてから1.9に移行するのがベスト

615:デフォルトの名無しさん
09/10/05 20:17:41
そんなにエンコーディング関係にはまるってのは「普段遣い」の範囲が常人とはかけ離れてる説

616:デフォルトの名無しさん
09/10/05 20:19:25
>>609
> # 1.8の場合
> require 'hogelib/compat-1.8'
こんなマネをするくらいなら、ということだよ。



次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5398日前に更新/200 KB
担当:undef