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

Rubyについて Part 34 at TECH

1:デフォルトの名無しさん
09/02/04 03:34:28
オブジェクト指向スクリプト言語Rubyについて扱うスレッドです。

Ruby Home Page
URLﾘﾝｸ(www.ruby-lang.org)

= 前スレ
Rubyについて Part 33
ｽﾚﾘﾝｸ(tech板)

過去スレ・関連スレは >>2-

2:デフォルトの名無しさん
09/02/04 03:35:16

Ruby 初心者スレッド Part 25
ｽﾚﾘﾝｸ(tech板)

【ActiveScript】RubyをWindowsで使うスレ【GUI】
ｽﾚﾘﾝｸ(tech板)

Rubyの宿題教えてください。2限目
ｽﾚﾘﾝｸ(tech板)

Ruby＞＞＞＞＞Java
ｽﾚﾘﾝｸ(tech板)

愛国Ruby
ｽﾚﾘﾝｸ(tech板)

【↓アンチ系】

Rubyについて（アンチ専用） Part003
ｽﾚﾘﾝｸ(tech板)

Rubyは難しすぎ
ｽﾚﾘﾝｸ(tech板)

【カルト】Ruby開発者Matz【モルモン】
ｽﾚﾘﾝｸ(prog板)

3:デフォルトの名無しさん
09/02/04 03:35:53
Rubyリファレンスマニュアル刷新計画
URLﾘﾝｸ(doc.loveruby.net)
ライブラリ一覧
URLﾘﾝｸ(doc.loveruby.net)
RubyExtensionProgrammingGuide
URLﾘﾝｸ(i.loveruby.net)
Ruby Hacking Guide
URLﾘﾝｸ(i.loveruby.net)
Symbol < Stringも止める。
URLﾘﾝｸ(www.rubyist.net)
クラスローカルインスタンス変数
URLﾘﾝｸ(www.rubyist.net)
クラス変数
URLﾘﾝｸ(www.rubyist.net)
ローカル変数
URLﾘﾝｸ(www.rubyist.net)
可視性メモ
URLﾘﾝｸ(www.rubyist.net)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
YARV without 1.9
URLﾘﾝｸ(www.rubyist.net)
URLﾘﾝｸ(www.atdot.net)
URLﾘﾝｸ(i.loveruby.net)
JSON
URLﾘﾝｸ(json.rubyforge.org)
URLﾘﾝｸ(webos-goodies.jp)
URLﾘﾝｸ(webos-goodies.jp)
YAML
URLﾘﾝｸ(www.ruby-lang.org)
URLﾘﾝｸ(jp.rubyist.net)
URLﾘﾝｸ(www.namikilab.tuat.ac.jp)

4:デフォルトの名無しさん
09/02/04 03:36:51
Ruby/Gtk+
URLﾘﾝｸ(www.unixuser.org)
URLﾘﾝｸ(takeposo.sakura.ne.jp)
URLﾘﾝｸ(ruby-gnome.sourceforge.net)
URLﾘﾝｸ(ruby-gnome.sourceforge.net)
URLﾘﾝｸ(ruby-gnome2.sourceforge.jp)
URLﾘﾝｸ(psux1.kek.jp)
URLﾘﾝｸ(www.rubycgi.org)
URLﾘﾝｸ(ruby.gfd-dennou.org)
URLﾘﾝｸ(www.magicianmaster.jp)

5:デフォルトの名無しさん
09/02/04 03:37:42
Ruby on Rails
ｽﾚﾘﾝｸ(tech板)
URLﾘﾝｸ(jp.rubyist.net)
URLﾘﾝｸ(www.onlamp.com)
URLﾘﾝｸ(kyotosanga.com)
URLﾘﾝｸ(blog.hacklife.net)
URLﾘﾝｸ(www.metadata.co.jp)
URLﾘﾝｸ(japan.cnet.com)
URLﾘﾝｸ(japan.cnet.com)
URLﾘﾝｸ(journal.mycom.co.jp)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(www-06.ibm.com)
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

6:デフォルトの名無しさん
09/02/04 03:39:46
>>1乙☆

7:デフォルトの名無しさん
09/02/04 03:45:52
1.9系っていわゆる地雷？

8:デフォルトの名無しさん
09/02/04 03:46:56
>>7
いまのところ地雷です

9:デフォルトの名無しさん
09/02/04 04:22:32
>>7
世の中のライブラリの対応が追いついてないのが多い。
あと1.9での変更点や新機能を扱う解説サイトや解説本は不足気味。
これらが問題だと思うなら地雷。

10:デフォルトの名無しさん
09/02/04 05:40:12
C APIレベルでの変更を解説して欲しい

11:デフォルトの名無しさん
09/02/04 06:14:54
VCからRubyを呼び出すにはどうしたらいいんでしょうか？
一通りググってみたんですが、分かりませんでした。

参考になりそうなサイトなども知っていたら教えてください

12:デフォルトの名無しさん
09/02/04 06:20:48
「VCからRubyを呼び出す」の意味を詳しく

13:デフォルトの名無しさん
09/02/04 06:27:37
XXX.cppの中で、
Rubyで作ったMechanizeをラップした自作クラスを呼び出したいんですが

14:デフォルトの名無しさん
09/02/04 06:28:08
>>13は>>12宛てです

15:デフォルトの名無しさん
09/02/04 06:41:59
CからRubyは呼べないっしょ。
だってRubyスクリプトって
単なるテキストファイルだもの。

16:デフォルトの名無しさん
09/02/04 06:54:56
>>11 >>15
つ URLﾘﾝｸ(d.hatena.ne.jp)

17:デフォルトの名無しさん
09/02/04 09:19:38
勃ってたのか
>>1 乙

18:デフォルトの名無しさん
09/02/04 09:21:25
>>11-15
Exerbがそれに近いことをやってると思う

19:デフォルトの名無しさん
09/02/04 09:24:25
Python で self がうざいって言ってる人がいるみたいだが、
@classmethod や @staticmethod を使ったことが無いんだろうね。
結局ちょっと遊んでみて終わりっていうレベルの単なる食わず嫌いだってこと。
まともに使ってれば面倒とも何とも思わなくなるよ。

20:デフォルトの名無しさん
09/02/04 09:30:07
>>19
インスタンスメソッドの場合のselfがうざいんだろう
Pythonの場合クラスメソッドはクラスの外に書いちゃえばそれで用が足りるし

21:デフォルトの名無しさん
09/02/04 11:09:06
Mingw版Ruby 1.9.1-p0 で作った拡張ライブラリが mswin版Ruby 1.9.1で動かせません

原因はMingw版ruby 1.9.1-p0 がmsvcrt-ruby191.dll のDllMain@12をエクスポートしちゃってるので
msvcrt-ruby191.dllをリンクしたプログラムがMingwスタートアップのDllMainではなく
rubyのdllが公開している方をリンクしてしまうからです
rc2からp0になってmsvcrt-ruby191.defの生成法が変わった影響のようです
従来は win32/mkexports.rb によって生成されていたのが
cygwinと共通の生成方式が新設されているようです

C言語環境の知識はあまりありませんが
(特にWindowsのdllシステムやらMingwのdllの扱い方やらはよくわからない)
DllMainなんて公開しちゃだめなんじゃないですか？
ランタイムのエントリルーチンから呼び出される関数ですよね
そもそもが自分で定義するか、そうでなければ
デフォルトのDllMain関数がリンクされるもののはずなので
よそのdllの初期化関数を呼び出すのはまずいでしょう

22:デフォルトの名無しさん
09/02/04 13:03:17
１おつなんたらかんたら
長いテンプレはイラネ。公式と初心者スレだけでいいよ。

23:デフォルトの名無しさん
09/02/04 13:06:20
>>21
goto redmine

24:デフォルトの名無しさん
09/02/04 14:24:31
いまからRubyはじめるなら
ピッケル本とFlanaganのプログラミング言語Ruby、どっちが良いですか？
もしくはそれ以外で良いのあります？

25:デフォルトの名無しさん
09/02/04 14:42:14
Rubyライブラリ編

26:デフォルトの名無しさん
09/02/04 14:54:12
>>24
まずは立ち読みして自分にあった本を探した方が良いよ

27:デフォルトの名無しさん
09/02/04 14:56:04
ジュンク堂なんか、がっつり座って読めるしな
単価が高いから無駄本買ったときのがっかり感も大きいし

28:デフォルトの名無しさん
09/02/04 15:10:53
>>24
リファレンス嫁

29:デフォルトの名無しさん
09/02/04 15:14:09
この時期にピッケル本は控えたほうがいいんでは
すくじゃないだろうけど、1.9対応の第三版が控えてる
まあ翻訳に半年かそこらはかかるって担当の人は言ってたけど

30:デフォルトの名無しさん
09/02/04 16:08:18
>>29
危なかった、ピッケルやめときます
半年は長いのでとりあえずジュンク堂でオライリーとかあさってみます

31:デフォルトの名無しさん
09/02/04 16:08:28
>>29
翻訳に半年かかるって事だと
英語の本が春頃出たとしたら翻訳した本は年末か年明けになるの？

32:デフォルトの名無しさん
09/02/04 16:11:58
>>30
リファレンス嫁

33:デフォルトの名無しさん
09/02/04 16:24:38
>>32
オフラインで読みたい...小説感覚で
ライブラリ周りはwebにたよるけど

34:デフォルトの名無しさん
09/02/04 16:57:48
>>30
1.9は出たばっかりでまだまだ初心者にはお勧めできない。
どうせしばらくは1.8の開発も続くし、ピッケル本でも問題ないよ。
何事も「今始める」のがやっぱ大事だよ

35:デフォルトの名無しさん
09/02/04 18:09:21
RubyのWindows用のバイナリが色んな種類出ているのはMatzんの陰謀だと思う

36:デフォルトの名無しさん
09/02/04 18:11:49
>>24
この本よかったよ
URLﾘﾝｸ(www.amazon.co.jp)
古いけど

37:デフォルトの名無しさん
09/02/04 18:35:22
勘違いしてました
Mingw版でもmsvcrt-ruby191.def は mkexports.rbで生成されてました

>>23
redmineって誰でも問題登録できるの？
使い方がよくわからんのですけど
極端な小心者なのでMLに報告なんてのはとてもできません
そもそも普段からメールをほとんど使ってないし

Maikefile の書式もちゃんとわかってない程度だし
DllMainのことも検索しまくってなんとかちょっとわかったくらい
などとスキルも低く、しかも英語もわからんときてるorz

38:デフォルトの名無しさん
09/02/04 18:46:33
>>37
誠意をもってちゃんと書けば誰でも余裕で登録できる。
スキルがなかったら単にrejectされるだけ。

高校の先生が全角でRUBYと書いて「動かない！バグだ！」って
登録した例もある。そこまでひどくなくても要望ぐらいなお気軽に。
オープンソースってそんなもん。

39:デフォルトの名無しさん
09/02/04 18:48:32
>>35
Perlとどっこいどっこい

40:デフォルトの名無しさん
09/02/04 18:50:01
だからWindowsなんて誰も使ってないマイナーOSの話はいいって。

41:デフォルトの名無しさん
09/02/04 19:17:37
>>37
Webインターフェースから日本語で報告するだけ。事前登録は必要だけど。
それさえしてあれば、>>21をこのスレに書くのもredmineに書くのも同じ。
もっとも、もう>>21は直されたみたいだけどね。

42:デフォルトの名無しさん
09/02/04 21:03:54
Win32用のGem ファイルを作成しているのですが、
exec.bat みたいなファイルを c:/ruby/bin とかのパスが通ったところに置きたいのだけど、
どう書けばいいのか分かりません。c:/ruby/lib///xxx/gems/appname/bin/exec.rb とかにインストールされるようにはできたので、
最低限の基本は分かっているつもりです。
RubyGem の rubyforge のページには書いてないような気がするのですが、rake とかでは実現されているので
できるはずなのです。
後ついでに、PlatFormによってコピーするファイルを切り替えられるというのもできたらうれしいです。

43:デフォルトの名無しさん
09/02/04 21:21:31
>>16
サンクスです
>>18
ちょっと自分が知りたい情報じゃないですが、レスありがとうございます。

44:デフォルトの名無しさん
09/02/04 21:30:10
>>39
Rubyはすっとこどっこい

45:デフォルトの名無しさん
09/02/04 21:36:39
>>43
VC とは直接関係ないけど、参考までに
URLﾘﾝｸ(shugo.net)
URLﾘﾝｸ(shugo.net)

46:デフォルトの名無しさん
09/02/04 22:18:06
3927

47:デフォルトの名無しさん
09/02/04 23:18:51
デビアンしか動作保証してないのもどうかと思うがｗｗｗ

48:デフォルトの名無しさん
09/02/05 01:02:31
>>36
見てみたいですけど絶版...
HTML版って内容同じですか？

49:デフォルトの名無しさん
09/02/05 01:18:06
それはCでRubyの処理系を書く本だからスルーしておk
（素晴らしい本であることは間違いないけど）

というかここよりも初心者スレで聞いた方が早いよ

50:デフォルトの名無しさん
09/02/05 16:56:25
>>48
基本的に同じ。
執筆後のアフターフォローとかも少し入ってる。
（最新版のRubyに追従とかはしてないけどね）

51:デフォルトの名無しさん
09/02/05 17:31:45
CでRubyの処理系を書く本なんだけどRubyの中身が分かる
モジュールとかクラスとかスコープの解釈がどうなってるのかとか
他の言語の経験があってこれから初めてRubyを学ぶなら
コーディングするときにも役に立つと思うよ

52:デフォルトの名無しさん
09/02/05 22:58:09
>>51
おなじ様な内容を「実践rails」でも扱ってた

あの本、読み物としては面白かったよ

53:デフォルトの名無しさん
09/02/05 23:10:09
>>45
おお、それで自作クラスが呼び出せるんですね
サンクスです。
もう少しで、自作クラスを呼び出す段階までいけそうです。

今rubygemsをインストールして
mechanizeをインストールしようとしてるんですけど、
zlibがないって怒られてます。
これはどうしたらいいんでしょうか？
とりあえずwindows用のzlibをインストールしたんですがmechanizeのコンパイルでは
依然怒られっぱなしです。

54:デフォルトの名無しさん
09/02/05 23:15:54
module M
def initialize
super
puts "よこどりー1"
end
def hoge
super
puts "よこどりー2"
end
end

class C
include M
def initialize
puts "もともと1"
end
def hoge
puts "もともと2"
end
end

C.new.hoge

これで
もともと1
よこどりー1
もともと2
よこどりー2
って表示したいんだけど、どうすればいいかな

55:デフォルトの名無しさん
09/02/05 23:16:38
URLﾘﾝｸ(d.hatena.ne.jp)

56:デフォルトの名無しさん
09/02/05 23:20:28
>>53
> zlibがないって怒られてます。
> 怒られっぱなしです。
状況説明できない初心者は初心者スレ行け

57:デフォルトの名無しさん
09/02/05 23:27:41
gem install mysql で入れたmysql.soが文字化けするんですが
どうすれば正常に入るんでしょう？

バージョンは↓です

ruby v1.8.7
rails v2.2.2
mysql v5.0.67

58:デフォルトの名無しさん
09/02/05 23:28:50
> mysql.soが文字化け

59:デフォルトの名無しさん
09/02/05 23:36:51
>>54
class C でインクルードしないで

class K < C ; include M ; end
K.new.hoge

で期待する出力は出せるけど、これじゃダメですねそうですね

60:デフォルトの名無しさん
09/02/05 23:41:24
>>54
なんかソースを素直に見る限りでは

> もともと1
> よこどりー1
> もともと2
> よこどりー2

と表示されそうなんだけどな
モジュールのメソッドがガン無視されるのはなんでだろう

61:デフォルトの名無しさん
09/02/05 23:46:10
>>56
分かりました。そうします

62:デフォルトの名無しさん
09/02/05 23:56:14
> モジュールのメソッドがガン無視されるのはなんでだろう

C.ancestors

63:デフォルトの名無しさん
09/02/05 23:59:48
>>60
> モジュールのメソッドがガン無視されるのはなんでだろう

p C.ancestors #=> [C, M, Object, Kernel]

ということで、メソッド探索順がMよりCが先だから、が正解
そもそも include が

[C, Object, Kernel]

のCの1個上に割り込んで

[C, M, Object, Kernel]

とすることでメソッド追加を実現してる機能だから、
「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない

>>59だと

[K, C, Object, Kernel]

にMが

[K, M, C, Object, Kernel]

という順番で割り込むから、実質、MでCが上書きできてる

64:デフォルトの名無しさん
09/02/06 00:08:32
>>63
> 「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない
これって「メソッドをクラスに追加します」とかいうへにょげた説明の割に微妙に不便な実際だよね
「include M はメソッド探索の上位に M を追加します」とかきちんと書いて欲しいなあ

ちなみに extend ならできるが、initialize の上書きができね

c = C.new
c.extend M
c.hoge

もともと1
もともと2
よこどりー2

65:デフォルトの名無しさん
09/02/06 00:14:34
>「include M はメソッド探索の上位に M を追加します」
うおー自作で include 使わないから知らんかった
C にないメソッドのときだけ M が探索されるのね、成程

66:デフォルトの名無しさん
09/02/06 00:38:55
>>57
「mysql.soが文字化け」？？

67:デフォルトの名無しさん
09/02/06 00:39:41
>>63
なるほど
その説明で今更いろいろな事が納得できた…

68:デフォルトの名無しさん
09/02/06 01:43:50
MySQL開発チームメンバーらと起業
MySQLの「生みの親」、サンを離れる
URLﾘﾝｸ(www.atmarkit.co.jp)

69:デフォルトの名無しさん
09/02/06 02:02:57
>>54,63
> 「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない

無理矢理だがこんなんでどうだろう

class C
# この段階では M を include しない
def initialize
...
def hoge
...
end

module X
define_method :initialize, C.instance_method(:initialize)
define_method :hoge, C.instance_method(:hoge)
end

class C
remove_method :initialize
remove_method :hoge
include X
include M
end

C.new.hoge

70:デフォルトの名無しさん
09/02/06 06:15:56
>>54
それclass Cの方で、メソッドの最後にsuper呼んだらうまくいくんじゃね？

71:デフォルトの名無しさん
09/02/06 11:13:41
それはメソッドのオーバーライド（再定義）とsuperがどういうしくみになってるかってことだな

72:デフォルトの名無しさん
09/02/06 11:26:05
実際上は>>59が妥当だな
Ruby におけるメソッドの上書きは「その場」で「実際」に def を実行しないと動作しないから
既存のモジュールオブジェクトを include でがっちょんと接続しただけでは期待通りにはならないと

…そもそもの include っていう名前がまずい気がしてきた
add_parent とか family とかなんかそんなクラス・モジュール関係が変化するという印があったほうがよかったのかもしれない

73:デフォルトの名無しさん
09/02/06 11:30:59
>>72
module M; end
class C; end
p C.ancestors
class C; include M; end
p C.ancestors

[C, Object, Kernel]
[C, M, Object, Kernel]
　　↑このへんがinclude

74:デフォルトの名無しさん
09/02/06 11:38:10
なるほどクラスの内包関係に含むからincludeか！Ruby氏ね！

Mix-inとかの実装上の都合だったのか「モジュールの内包関係にあとから割り込む機能」が欲しくてこうしたのかがちょっと興味ある

75:デフォルトの名無しさん
09/02/06 12:01:02
>74
お前が氏ね

76:デフォルトの名無しさん
09/02/06 13:00:03
つーか普通 module を include するのって抽象クラスを継承するようなイメージじゃないのか?
どう考えても class で書いたメソッドの方を優先して欲しいんだが。

77:デフォルトの名無しさん
09/02/06 15:04:11
いや思いっきり優先されてるだろ
p C.ancestors #=> [C, M, Object, Kernel]
は C にメソッドがない場合にのみ M の中を探す

module M
def msg; "Rubyはうんこ"; end
end
class C
def msg; "Ruby最高"; end
end
class C; include M; end

puts C.new.msg

Ruby最高

78:デフォルトの名無しさん
09/02/06 15:06:07

　・既存のメソッドと同じ名前のメソッドをincludeしたとき super がどうなるか
　・クラスを含んだモジュールをincludeしたときそもそもどうなるか

というのがわかりにくいわぼけーという話だな

79:76
09/02/06 15:59:11
>>77
いやいや、実際そうなってないということではなくて、>>72とかの「期待通り」って、
いったい何を期待しとるんだという話。
Ruby の include のイメージで
>>78の「既存のメソッドと同じ名前のメソッドをincludeしたとき」
みたいな言い方は、普通出てこないんじゃないの? と思うんだが…

80:デフォルトの名無しさん
09/02/06 16:32:17
>>79
つヒント：普通じゃない

81:デフォルトの名無しさん
09/02/06 21:31:50
1.9.1文字コードがどーたらこーたらで既存のコードがうごかねー。
そういうのは2.0でやってくれよ。

82:デフォルトの名無しさん
09/02/06 21:35:47
文字コードなんて1.4でやっとけよ

83:デフォルトの名無しさん
09/02/06 21:56:02
>>81
1.9.0では動作してたものが1.9.1では動かないというのなら姉さん事件ですのでぜひ報告を

84:デフォルトの名無しさん
09/02/06 23:02:12
2.0でやってたらやってたで「3.0でやってくれよ」と言ってるんだろうな

85:デフォルトの名無しさん
09/02/06 23:02:59
なにいってるかわからない

86:デフォルトの名無しさん
09/02/06 23:52:48
なるほど
ありがとうございました

87:デフォルトの名無しさん
09/02/07 00:30:26
どれだー
どれに対する礼なんだー

88:デフォルトの名無しさん
09/02/07 00:38:44
きっと神にだよ。

89:デフォルトの名無しさん
09/02/07 01:33:07
なるほど
ありがとうございました

90:デフォルトの名無しさん
09/02/07 06:13:20
>>84
少なくとも1.9.1でやるよりは10倍マシ

91:デフォルトの名無しさん
09/02/07 07:27:49
複雑だと思うならつかわなきゃいいんじゃねーの？
なんでアホはあるもの全部使わなきゃ気がすまねーの？

92:デフォルトの名無しさん
09/02/07 08:02:17
誰と会話してんの

93:デフォルトの名無しさん
09/02/07 14:07:18
# -*- coding: utf-8 -*-
を行頭に挿入すりゃいいだけだろ？何を恐れることがある

94:デフォルトの名無しさん
09/02/07 14:33:29
>>92
彼は今チャンピオンベルト目指して脳内キャラとスパー中です。

95:デフォルトの名無しさん
09/02/07 14:55:55
>>94
それってつおいの？

96:デフォルトの名無しさん
09/02/07 14:58:32
昔、机の上で左手と右手を戦わせてたときのことを思い出した

97:デフォルトの名無しさん
09/02/07 14:59:40
それなんて色川武大

98:デフォルトの名無しさん
09/02/07 15:08:03
きっと神とだよ。

99:デフォルトの名無しさん
09/02/07 15:08:55
ありがとうございました

100:デフォルトの名無しさん
09/02/07 15:26:06
なるほど

101:デフォルトの名無しさん
09/02/07 15:36:53
がんばれよ

102:デフォルトの名無しさん
09/02/07 15:57:37
>>90
1.9って2.0のβじゃないの？
Rubyのバージョン付けはそういうルールじゃないんだっけ。

103:デフォルトの名無しさん
09/02/07 15:58:21
1.9は1.10のβです

104:デフォルトの名無しさん
09/02/07 16:01:49
>>102
元々はそういうルールでしたが、1.9.1からいきなり変わりました

今は1.9.0が開発版、1.9.1が安定版
それ以降はもうよく分からない

105:デフォルトの名無しさん
09/02/07 16:04:26
>>104
なるほど、知りませんでした。

>>103
確かに。
2.0のβなら1.99でしょうね。

106:デフォルトの名無しさん
09/02/07 16:06:25
>>102
2.0が当分先になりそうだから、
つなぎとして固まった仕様だけ出したのが1.9だったよーな

破壊的な変更のコストはどんどん増える一方ということを考えると、
ブロック内変数とかも含めて、
今のうちに変更しておくという決定は一理あるとは思う

107:デフォルトの名無しさん
09/02/07 16:10:00
1.8と2.0の掛け橋が1.9で、1.8と1.9の橋渡しが1.8.7
ライブラリ作ってるのでなければ、しばらくは1.8.7を常用するのがよい
半年もすれば1.9.1対応ライブラリもぐんと増えよう
ライブラリ公開してる人はとっとと1.9.1入れて対応作業始めてくりゃれ

108:デフォルトの名無しさん
09/02/07 16:13:29
>>107
今年中に1.8.8出るよ？

109:デフォルトの名無しさん
09/02/07 16:14:02
>>108
またそんな夢みたいなことを簡単に信じるんだから

110:デフォルトの名無しさん
09/02/07 16:15:25
>>108
うん、で、そのあとに続く言葉は何？
「だから1.8.6使い続けたほうがいい」？
1.8.8が出るなら今から1.8.7勉強して慣れたほうがよくないか？

111:デフォルトの名無しさん
09/02/07 16:35:19
hpricot(why-hpricot)とmysql(elia-mysql)は
githubで公開しているgemなら1.9.1に入った。
githubのgemはオーナー名が入るのが好かんのだが。

112:デフォルトの名無しさん
09/02/07 16:44:48
Hpricotの復権はあるのだろうか…

113:デフォルトの名無しさん
09/02/07 16:46:56
>>112
Nokogiri はつまるとこ lib-libxml2 なんで、そのへんの不便を突けば並列使用は可能だと思う

114:デフォルトの名無しさん
09/02/07 17:41:37
>>112
なんか、why の人の blog で
「nokogiri の方が速いとか言われてマジブルー。むかついたからパーサー書き直したYO!」
とかいうエントリがあがってた。試してないから速くなったのか知らんけど。

115:デフォルトの名無しさん
09/02/07 17:44:32
速さ云々じゃなくてあの変態APIが（ｒｙ

116:デフォルトの名無しさん
09/02/07 17:56:02
hpricotがなくっても _why の多芸っぷりは憧れる

117:デフォルトの名無しさん
09/02/07 18:39:21
最近似たようなこと書き込みまくってる気がするんだが

module M
class C1; end
class C2; end
end

この場合、C1 と C2 に関係性を持たせることはそもそもできない？
たまたま含まれるモジュールが同じだけで、「知り合い」ではない？

M を改造して

module M_II
class C1; end
class C2; end
end

というものを作りたいんだけど

118:デフォルトの名無しさん
09/02/07 19:17:21
>>110
1.8.7と1.8.8って何か変更あるの？
その時の1.9.1ってどうなるの？

119:デフォルトの名無しさん
09/02/07 19:22:25
1.9という奇数バージョンは開発バージョンだから
2.0まで待った方がいいよ。

120:デフォルトの名無しさん
09/02/07 19:32:46
間違った知識で何を言うか

121:デフォルトの名無しさん
09/02/07 19:43:53
何年も継承されてるルールを変えられると困る

122:デフォルトの名無しさん
09/02/07 19:52:42
文字列処理入ると1.8より遅いのか...

123:デフォルトの名無しさん
09/02/07 19:54:20
不安定版を一応脱した1.9.1が出た時点で、実質「1.9は開発版」という看板は終了だ
従来動作の1.8系列と、新動作の1.9系列という2つの括りになる
むしろ、次の開発版が無いのが気になる

124:デフォルトの名無しさん
09/02/07 19:56:08
>>117
定数とか調べてコピーを作るメソッドを自分で作れ
Application.create とか

あと↓見てよく考えろ。クラスも定数である事を忘れるな
class A
　CONST = :A
　def pconst ; p CONST ; end
　def pselfconst ; p self.class::CONST ; end
end
class B < A
　CONST = :B
end
B.new.pconst #=> :A
B.new.pselfconst #=> :B

125:デフォルトの名無しさん
09/02/07 19:57:42
話をループさせるの好きなんですね、わかります。

126:デフォルトの名無しさん
09/02/07 21:13:30
>>117
> 「知り合い」ではない？
まあ、基本的には。
ネストでも継承でもない場合、基本的に他人。
データ作成クラスとデータ構造クラスとかを知り合い関係のまま再利用させたい場合は適当にネストさせとく。

class DataMaker; end
class Data; end
class SubData; end

という並列構造はそもそもあんましよくない。

127:デフォルトの名無しさん
09/02/07 21:21:54
moduleインクルードすると嬉しいことって
クラスの多重継承の代わりになるってことだけですか？
なんならmoduleなんて排除してクラスの多重継承許しちゃえばよかったのに

128:デフォルトの名無しさん
09/02/07 21:29:31
ClassクラスとModuleクラスを機能的に分けたときのついでなんじゃないかと最近思う

129:デフォルトの名無しさん
09/02/07 21:34:06
>>126
ネストの意味のあるクラス名考えるのがとってもめんどくさいです

130:デフォルトの名無しさん
09/02/07 21:34:10
moduleをファイル指定にするというのはどうだろう

module HogeHoge
class FooBar; end
end
と書いたファイルは名前がHogeHoge.rbでなくてはならない、と
して
require ForBar from "HogeHoge"
とかすんの。

131:デフォルトの名無しさん
09/02/07 21:52:54
1.9系は全部開発版じゃないの? というのは私も思ったけれども、よく見るとRHG巻末に「1.9.0は開発版、1.9.1は安定版」書いてあるからかなり前から公表されていたと言える。
Matzがなにか2.0 featureをあれこれやりはじめたら、そのとき開発版と1.9系安定的開発版を分けますです。

132:デフォルトの名無しさん
09/02/07 21:56:11
てか、単に脳内情報が更新されてない人がいるだけだ
わりと前に「末尾 0 のみ開発版」というのは発表されてたはず
あと、一般的命名法とかけ離れている、直感に反するポリシーだというのが(w

133:デフォルトの名無しさん
09/02/07 22:00:13
>>119
1.9.1も開発バージョンで2.0.0も開発バージョンなんですよね
わかります

134:デフォルトの名無しさん
09/02/07 22:00:14
Rubyの作者ってちゃんと働いてるの？
IBMとかに入って一度リリースエンジニアリングを学んできた方がいいと思うんだが。

135:デフォルトの名無しさん
09/02/07 22:02:38
1.9の開発版はこの先ずっと1.9.0なんか...
それとも1.9.1.0とか

136:デフォルトの名無しさん
09/02/07 22:10:56
あの浅田真央でさえ不調になるとこんなもんだ

137:デフォルトの名無しさん
09/02/07 22:33:00
どんだけ話をループさせるのが好きなんだよ、おまいらはw

138:デフォルトの名無しさん
09/02/07 22:37:21
Rubyの安定版が1.9.1になった理由について
Matz自身が言及してる文章ってどこかにないかな？　あったら教えて欲しい

139:デフォルトの名無しさん
09/02/07 22:38:20
何で英語の方がドキュメント豊富なんだよ
日本で生まれたって理由だけでruby選んだのに
納得できん

140:デフォルトの名無しさん
09/02/07 22:41:35
>>139
日本語ドキュメントが豊富だっていう理由で言語選ばなかったからだろ

141:デフォルトの名無しさん
09/02/07 22:45:55
>>139
日本人があまりドキュメント作る気が無いから

142:デフォルトの名無しさん
09/02/07 22:47:17
用途によってまた違うんだろうけど、日本語ドキュメントの質と量の総合で言うと、
Perl > PHP > Ruby >= JavaScript > Python くらいな気がする今日この頃。

143:デフォルトの名無しさん
09/02/07 23:04:33
公式じゃなくても優良な書籍や解説サイトがあるPerl
公式以外が間違いだらけで公式しか頼れないPHP
公式があれば必要十分なPython

144:デフォルトの名無しさん
09/02/07 23:12:28
Pythonの公式は情報量は多いのに、使いやすさが全く考慮されていないのが痛い。
PHPは公式の出来はとても良い。ただしGoogle検索で出てくる更新されていない公式のコピーサイトがうざすぎる。

145:デフォルトの名無しさん
09/02/07 23:32:49
るびま25号出たー！
まさに今求められている記事のラインナップだ、素晴らしい

146:デフォルトの名無しさん
09/02/07 23:40:12
python信者ってやたらruby嫌うよね？
職場のpython教の先輩方々がみんなrubyアンチだ
何なんだろね

147:デフォルトの名無しさん
09/02/07 23:41:30
>>139
なにもかも、おまえがドキュメントを書かないせい。

148:デフォルトの名無しさん
09/02/07 23:41:39
>>146
犬好きと猫好きみたいなもんだって誰かが言ったと最近どこかで見たが、このスレじゃなかったのかな

149:デフォルトの名無しさん
09/02/07 23:42:48
URLﾘﾝｸ(isitruby19.com) (Is it Ruby 1.9?) というサイトがあった。

150:デフォルトの名無しさん
09/02/07 23:55:41
>>145
1.9スレではリンク張られてたな

151:デフォルトの名無しさん
09/02/08 00:08:25
るびまからリンクされてたFiberの解説を見て
Fiberに対する興味が出てきたんだけど、有効な使い方がよく分からない

確かにThreadよりもシンプルだけど、使い方を探すのに悩む…

152:デフォルトの名無しさん
09/02/08 05:31:54
Rubyの開発ってさ、いつ終了すんの？
早く開発完了してバグ取りと仕様固定化に
力入れてくんないと、怖くて業務に使えないんだけど。

153:デフォルトの名無しさん
09/02/08 06:45:38
>>152
Python、PHP、Java
これらの言語の開発は終了しましたか？　また終了する見込みはありますか？
それが答えです

154:デフォルトの名無しさん
09/02/08 10:30:32
CもC++もC#も終わってないな
終わったのはVBとCOBOLくらいか

155:デフォルトの名無しさん
09/02/08 10:53:42
COBOLも終わってないらしいぞ。
JIS規格の会議とか、最近でもあるし。

156:デフォルトの名無しさん
09/02/08 12:12:19
>>153
Javaは終わってないけど、互換性はそれなりにキープされてるから
ちょっと違う。テスト不要とまでは言わないが、コード修正は不要なことが多い。

>>154
VBも終わってないぞ。文法が違うだけで、中身がほとんどC#と同じという
意味では「終わっている」のかもしれないが。

157:デフォルトの名無しさん
09/02/08 12:18:07
Javaは「仕様が無い言語とか業務使用にありえないから」という理由だけで作られた政治的言語だろ
他の言語と比較するのはそれだけで場違いだ

158:デフォルトの名無しさん
09/02/08 13:39:54
1.9.1でバイナリファイル(画像)を File.read で読み込んだら
data.encoding #=> #<Encoding:UTF-8>
みたいになるんだな。これが Encoding.default_external か。

data.force_encoding('BINARY') するのと、
Encoding.default_external = 'BINARY' するのと、
どっちが行儀がよいのだろう。

とここまで書いて IO.binread の存在を知った。

159:デフォルトの名無しさん
09/02/08 13:59:17
ｇｄｇｄ

160:デフォルトの名無しさん
09/02/08 14:00:19
Pathname#binreadないんだな。

161:デフォルトの名無しさん
09/02/08 14:16:19
1.9.1(って書きづらいな。なんかコードネームでもつけてくれ)はUTF8でソースもテキストも書いとけばドツボにはまることもなくなるのかね。

162:デフォルトの名無しさん
09/02/08 14:20:57
>>161
万事解決かどうかは知らないが、そうしない理由もないだろ。
今日日EUC-JPとか正直なんのメリットもないしな。

163:デフォルトの名無しさん
09/02/08 14:45:23

　・システムがEUC-JPベースだ（オールドなLinuxとか）
　・ Emacs のUTF-8 対応に許せない
　・ターミナルと UTF-8 の関係でイラつく

の 3つの場合が考えられまする

164:デフォルトの名無しさん
09/02/08 15:17:31
そんなマイナー人種は、頑張って苦労するか日本語文字を使わないか
すればいいんじゃないかと。

165:デフォルトの名無しさん
09/02/08 15:19:16
UTF-8 は日本語大体３バイトだしな・・・

166:デフォルトの名無しさん
09/02/08 15:23:44
曖昧な幅のCJK文字とか死滅すればいいのに

>>165
UTF-8というかUnicodeにまつわる問題の多くは文字のバイト数に起因していない
的外れ

167:デフォルトの名無しさん
09/02/08 15:27:49
def val(params = nil)
@val ||= ...
end

とか

def val(params = nil)
@val if @val
...
return @val = ...
end

とかいう、最近わりと市民権得つつある遅延評価風の処理についてなにか一言あれば

168:デフォルトの名無しさん
09/02/08 15:35:00
>>167
irb とひじょーに相性が悪い
普通に書いてると、new した返り値が inspect で表示される瞬間に @val が確定してしまったりしてとてもめんどくさい

169:デフォルトの名無しさん
09/02/08 16:00:25
>>166
単に容量増えるって問題だよ

170:デフォルトの名無しさん
09/02/08 16:59:29
容量気にすんならMIME撲滅するべきだろ

171:デフォルトの名無しさん
09/02/08 17:00:41
XML もですねわかります

172:デフォルトの名無しさん
09/02/08 17:07:37
Rubyでそんなにシビアなもの作ってる人いるんだ。

173:デフォルトの名無しさん
09/02/08 17:09:58
>>167
普通にキャッシュとか言ったほうがいいよ

>>168
評価されるタイミングで結果が変わるメソッドでは使うべきではない

174:デフォルトの名無しさん
09/02/08 17:12:41
cache or memoize

175:デフォルトの名無しさん
09/02/08 17:44:46
>>167
rubyって遅延評価できるんだwww
見る限り遅延評価してるようには見えないが

176:デフォルトの名無しさん
09/02/08 17:49:34
rubyistな後輩がrails使った自社サービス開発してるんだけど
ログイン周りの拡張をする時に、汎用的に使えるようにしようってことで
railsのプラグインを３日ぐらいで作ってた。
javaしか知らなかった俺は素直にすげーって思った。
このフットワークの軽さは惚れるね。rubyじゃなくてrailsがすごいのかもしれないけど。

177:デフォルトの名無しさん
09/02/08 17:55:16
遅延評価と遅延評価風ってJavaとJavaScriptくらいの差があるよね

178:デフォルトの名無しさん
09/02/08 18:13:45
知ったか乙

179:デフォルトの名無しさん
09/02/09 02:08:35
>>176
それはrubyやrailsが凄いのではなくて、後輩が凄いんだろう。
というか、作ったものの規模にもよるんだけど、たぶん君が極端に情けない。

180:デフォルトの名無しさん
09/02/09 06:19:23
>>176
３日で作るのが難しいようなプラグインだったのか？

181:デフォルトの名無しさん
09/02/09 17:09:16
javaしか知らないやつの言うことだぞ、分かるだろ

182:デフォルトの名無しさん
09/02/09 17:14:16
何年か前の15分でブログを作るってデモを思い出すなぁ
知らない人間にとっては確かに衝撃的だった

183:デフォルトの名無しさん
09/02/09 20:27:22
オレは、rails がいまだに何なのか知らない。ｗ

184:デフォルトの名無しさん
09/02/09 20:30:53
>>183
WEB用途を主なターゲットにし、DBとの連携も手厚くサポートしているフルスタックのフレームワーク、でいいのかな
使ってみればいいよ。・・・うかつにインストールしようとするとサーバ固まるけどな。

185:デフォルトの名無しさん
09/02/09 20:35:21
rails1.0以前に研究室の先生に言われていじってたけど
最初の一歩はかるーく大きく踏み出せるんだけど、込み入ったことを
やりだすと自分でCGIを一から書いた方が早かったという・・

今は情報もふえてそうでもないんだろうけど。

186:デフォルトの名無しさん
09/02/09 21:10:26
>>185
込み入っていない大多数の場合を対象にしているのがrails

187:デフォルトの名無しさん
09/02/09 21:31:02
>>185
いまでもそうだよ

188:デフォルトの名無しさん
09/02/09 21:32:14
「Railを外れる」といいます

189:デフォルトの名無しさん
09/02/09 21:38:36
てか「フレームワーク」だということを意識しないて使って投げちゃう人いるよね
"CGI" を1個か2個作る程度ならむしろRailsの学習は損で、個別に作ったほうがお得だ

設計上似通った感じのものをいくつも作るような人が、
その似通った途中経過をざっくり省略するために使うのがフレームワークであり、
Ruby理解者に向けたWeb上での小箸ｷ中規模アプリサポートプログラムがRails

190:デフォルトの名無しさん
09/02/09 22:36:30
Redmineてどーよ？

191:デフォルトの名無しさん
09/02/09 22:38:05
それが問題追跡システムの出来の事をいってるなら、結構いいよ
Rubyの開発・サポート体制の事を言ってるなら、知らね

192:デフォルトの名無しさん
09/02/10 03:44:45
　ちょっと他のスレッドで発見したのですが
　　　　　↓
ラーメンタイマーでも作ってみれ。
カップヌードル用(3分)とどんべい用(5分)に分ける。
できればタスクバーに駐在する奴。

こういうのってRubyでもサクっと作れますか？
できればexe化したもの

193:デフォルトの名無しさん
09/02/10 04:07:31
>>192
Rubyの仕事ではないと考える
っていうか、作ったとしても中身の95パーセントくらいはRubyではないな

194:デフォルトの名無しさん
09/02/10 04:16:16
VB2005スレの話題じゃん
「Rubyでは作れない」でいいと思う

195:デフォルトの名無しさん
09/02/10 07:29:11
vrubyで簡単に作れる

196:デフォルトの名無しさん
09/02/10 08:02:22
>>192
WxRuby使えばサクっとできる。たぶん他のGUIツールキットでもすぐできるだろう
タスクバー駐在のところは出来るかどうか解らないが

197:デフォルトの名無しさん
09/02/10 08:03:26
>>192
Shoesを使うという手もある。
URLﾘﾝｸ(the-shoebox.org)
URLﾘﾝｸ(whytheluckystiff.net)
URLﾘﾝｸ(shoooes.net)
URLﾘﾝｸ(sourceforge.jp)

198:デフォルトの名無しさん
09/02/10 09:12:52
おまいらそんなレスでお茶を濁していていいのか
Pythonスレでも見て来い

199:デフォルトの名無しさん
09/02/10 09:50:44
>>198
標準でできないことはRubyで無理してやれって言わないのがRubyのジャスティスって今決めた

ていうかPythonはGUIサポートがまともだから比較すらできんぞ
RubyのこのへんはどっちかってとPerlとかに近い

200:デフォルトの名無しさん
09/02/10 10:28:46
RUbyはexe化でも結構悩む死ね

201:デフォルトの名無しさん
09/02/10 10:37:26
>>191
手厳しいな

だがそれがいい!

202:デフォルトの名無しさん
09/02/10 20:08:34
Shoesいいな

203:デフォルトの名無しさん
09/02/10 20:55:10
ソース散らばるのがいやならコンパイラ言語使えばいいじゃん。あとHSPとか。
インタプリタ言語でexe化とか矛盾してるでしょ。

204:デフォルトの名無しさん
09/02/10 20:58:03
んなこたない

205:デフォルトの名無しさん
09/02/10 21:02:35
矛盾はしてない。
ただRubyでやるには整備不足というだけで。

206:デフォルトの名無しさん
09/02/10 21:27:02
スクリプト言語に何でもやらせすぎだよ。
本質はテキスト整形言語だぜ？
ちゃんとしたアプリは横着せずCやVBで作ろうぜ。

207:デフォルトの名無しさん
09/02/10 21:36:44
超簡易ラーメンタイマがちゃんとしたアプリってのもｗ
exe化する一番大きいメリットは多分、、Rubyが入ってないマシン（普通は入ってない）に
持っていっても使えるツールになることだと思う

208:デフォルトの名無しさん
09/02/10 21:39:15
>>206
C言語やVBにこだわりすぎだよ。
ちゃんとしたアプリだからといって思考停止せずスクリプト言語で作ろうぜ。

209:デフォルトの名無しさん
09/02/10 21:42:33
Cで細かい文字列処理をするのがめんどくさい

210:デフォルトの名無しさん
09/02/10 21:43:08
ここら辺はC#やDelphiでやるのが手っ取り早いよ。
タイマーといえども作りこむと結構な大作になるしな。

211:デフォルトの名無しさん
09/02/10 21:46:29
.NET Frameworkが必要です。＞C#
Rubyで作れば作り方次第ではLinuxにも持って行けるよ！いけるよ！タスクトレイってなに？！

誰もJavaって言い出さないのが素敵だ。

212:デフォルトの名無しさん
09/02/10 21:51:48
Javaのクライアントアプリなんて総じて糞だからな。
それしかないって時以外は絶対に使わない。

213:デフォルトの名無しさん
09/02/10 21:52:59
.NET Framework上でもRuby動くよ。
C#で作っても作り方次第ではLinuxにも持っていけるよ。Gnomeのタスクトレイ(相当)もOK。

214:デフォルトの名無しさん
09/02/10 21:53:05
メイン環境がLinux, GNOMEなのでRuby/Gtk2でいい感じに

215:デフォルトの名無しさん
09/02/10 22:29:35
ウィンドウとか作るのはRubyの仕事ではないとみなしていいと思う
タスクトレイ云々はあれはたまたまウィンドウ出てないだけで内部的にはウィンドウだし

216:デフォルトの名無しさん
09/02/10 22:56:50
しかし敢えてHaskellを使う

217:デフォルトの名無しさん
09/02/10 23:47:33
ところで、普通は「駐在」じゃなくて「常駐」って言わないか？

218:デフォルトの名無しさん
09/02/10 23:56:33
ひょっとするとSwingスレにいた奴かもな。ヒマなやつだ

219:デフォルトの名無しさん
09/02/11 05:18:04
SWTも思い出してあげてください

220:デフォルトの名無しさん
09/02/11 05:47:30
SWTってeclipseの？

221:デフォルトの名無しさん
09/02/11 06:42:03
ここのところずっとsocketがいじられてるねえ

222:デフォルトの名無しさん
09/02/11 09:09:29
>>219
>SWTも思い出してあげてください
AWT(Abstract Window Toolkit) の間違いじゃなくて？

次ページ