Rubyについて Part 38 ..
[2ch|▼Menu]
39:デフォルトの名無しさん
09/11/03 20:27:01
>>37
rubyコミュニティってこんなに閉鎖的なのか?

40:デフォルトの名無しさん
09/11/03 20:44:26
当たり前だろ。素人は口出すな

41:デフォルトの名無しさん
09/11/03 21:31:18
>>39
よくわからんが、何言っても受け入れろってことか?
それを開放的というなら閉鎖的かもな

42:デフォルトの名無しさん
09/11/03 21:32:02
教祖さんが死んだらだれが跡を継ぐんだろう

43:デフォルトの名無しさん
09/11/03 21:35:58
>>42
普通に考えたら
1. メンテナのうちの誰か
2. 派生版の作者
のどちらかだろうな
そのままバージョンアップが停止するということも考えられる

44:デフォルトの名無しさん
09/11/03 22:12:36
>>41
MLでも身内の提案以外は無視されることが多いし
Matz日記にコメント付けたこともあるがすぐに削除された

45:デフォルトの名無しさん
09/11/03 22:17:01
> Matz日記にコメント付けたこともあるがすぐに削除された
モwwwルwwwwモwwwwンwwwwwwwwwww とかそういうのは削除されるぞ

46:デフォルトの名無しさん
09/11/03 22:32:07
>>43
yuguiもshyouheiも教祖様の判断がないと何も出来ない人だったんですね
知らなかったなぁ

47:デフォルトの名無しさん
09/11/03 22:35:41
yuguiさんはともかくshouheiって?

48:デフォルトの名無しさん
09/11/03 22:36:38
コメント削除されちゃうようなやつがここに集まるのか


納得

49:デフォルトの名無しさん
09/11/03 22:39:09
納得できて良かったですね

50:デフォルトの名無しさん
09/11/03 23:08:47
もっと若手を養成しないと先は無いぜ

51:デフォルトの名無しさん
09/11/04 00:57:30
>>48
と、いうことにしたいのですね? (AA略

52:デフォルトの名無しさん
09/11/04 01:54:41
  ヘ_ヘ
 ミ ・ ・ ミ
  (  ° )〜

53:デフォルトの名無しさん
09/11/04 02:23:40
ずれてますよ

54:デフォルトの名無しさん
09/11/04 03:03:57
>>46
yuguiさんとかmput氏がメンテナでないという妄想がどこから沸いてきたか詳しく

55:デフォルトの名無しさん
09/11/04 03:11:14
そもそも>>43が「バージョンアップが停止する可能性」だのと懸念してるのは
yuguiさんを認めていない証拠

56:デフォルトの名無しさん
09/11/04 03:56:15
Matz氏が開発止めるレベルの「もしも」を仮定するなら
なんらかの事情でyugui氏なりmput氏なりが継続に助力できないケースも
仮定されるんじゃねえの

57:デフォルトの名無しさん
09/11/04 06:51:10
>>55の釣り針が粗悪で困る

58:43
09/11/04 07:02:15
俺の書き方が悪かった
バージョンアップが停止する可能性っていうのは、正確に言うと
「言語仕様レベルでの」バージョンアップが停止される可能性ってこと

メンテナンスレベルのバージョンアップが停止されることは、あまり考えてない

59:デフォルトの名無しさん
09/11/04 09:59:04
>>58
それはそれで「安定」ってことでいいんじゃね?
という気もする

CとかC++とかJavaみたいに委員会方式でやるのも手だけどね

60:デフォルトの名無しさん
09/11/04 11:59:22
>>29
>891 名前:デフォルトの名無しさん[sage] 投稿日:2006/09/03(日) 10:29:35
その時期だったらブーイングされて当然な気がする。
実際その辺の不満が表出した結果がRubyConf2006での「デンバー合意」なわけで
URLリンク(jp.rubyist.net)
のあたりではささださんの愚痴が漏れてたり。

あとその辺の時期だとリリースエンジニアリングが全然駄目だった時期でも
あるのでは(つまりmputさんが動いて機能追加とセキュリティパッチが別立てになる前)

あと時期は随分あとになるけど1.8.6のメンテをRails系企業に渡したあたりで
海外からの不満はおおむね収まったのかと。

まあ、どれも今振り返るとやって大正解だったよね。

61:デフォルトの名無しさん
09/11/04 14:06:29
亜米利加じゃrbよりpyのほうが流行ってるから、railsがpyに書き直されて、rb終了のほうが可能性高いだろう。

62:デフォルトの名無しさん
09/11/04 15:35:04
>>61
> railsがpyに書き直されて

あのリフレクション使いまくりのRailsを、Pythonに書き直せると思えるならやってみやがれw

63:デフォルトの名無しさん
09/11/04 15:42:29
他言語だとgrailsとかあるけどあれはrubyもどきのgroovyだから出来ることだしなあ

64:デフォルトの名無しさん
09/11/04 15:57:50
すでにDjangoとかPylonとかあるのに、別にRailsを移植する必要なんかない。
ようはRailsに負けず劣らず開発効率がよくて、さらに実行効率までいいフレームワークがあればいいだけの話。


65:61
09/11/04 17:07:46
>>64も挙げてるとおりDjangoの方が全てにおいて上。
はい、Ruby終了。

66:デフォルトの名無しさん
09/11/04 18:14:42
>61の中では終わったようですね.今度このスレに来る時は建設的な議論があると嬉しいです.

67:デフォルトの名無しさん
09/11/04 21:37:35
昨日から大ハマリ中です。

=begin
〜グチここから〜
作りながら学ぶRubyという入門本を買ったのですが
1.9環境でsqlite3-rubyがエンコードASCII-8BITで返すことが
書いてなかったり、gem1.3.5をgemでインストールしたら
gem本体がインストールされてなくて原因わからず
糞詰まり状態で1日終了。Rubyの勉強全く進まず。
〜グチここまで〜
=end

ruby-debug-ide 0.4.7以降は1.9.1に対応してないんでしょうか?
ダウンロードはされてるんですが、インストールされません。

68:デフォルトの名無しさん
09/11/04 21:50:50
残念ながらされてません
Ruby 初心者スレッドの>>1-6をお読みください

そういやProc#to_sourceの議論って進んでないよね

69:デフォルトの名無しさん
09/11/04 21:59:40
>>67
Rubyの知識のない人間が1.9.1なんか使うな
素直に1.8.7使え

70:デフォルトの名無しさん
09/11/04 22:00:01
ありがとうございます。
1.9がリリースされて結構時間が経つので依存関係も対応済みだと思ってました。
入門本で1.9は地雷っぽいですね。

71:デフォルトの名無しさん
09/11/04 22:01:35
>>69
参考書が1.9なんですよ。
1.8.7を使ってたんですがわざわざ1.9.1環境を構築するのに
四苦八苦してるんです。

72:デフォルトの名無しさん
09/11/04 22:23:11
変な本も多いからな、Ruby

73:デフォルトの名無しさん
09/11/04 22:32:35
入門でWebアプリ作らせるやつとか大勘弁だな

74:デフォルトの名無しさん
09/11/04 22:50:37
いくらなんでもインターネット上に公開させたりはしないだろう


……しないよね?

75:デフォルトの名無しさん
09/11/04 23:04:08
>>71
1.9オンリーの参考書ってことですか?
なんという先走り…
タイトル教えてください

76:67=70=71
09/11/04 23:07:28
参考書の内容は変だとは思いません。
わかりやすくて面白いです。

が、サンプルが1.9.1でsqlite3を使っているにも関わらず
sqlite3-rubyが返す値をforce_encodingしていないので
サンプルは動かなかったんです。
コードを修正すると動くようになりますが、その一点だけが不思議です。
他の言語経験が無い人だと、たぶんお手上げだろうなと。

77:デフォルトの名無しさん
09/11/05 00:17:53
最近またちょこちょこ本が出てるが、1.8の説明なんておまけ程度
リファレンス系はさすがにカバーしてるが
1.9がトリガーになって出版してるんだから当たり前だけどな
次はRails3.0がトリガーになるんだろうな

78:デフォルトの名無しさん
09/11/05 11:01:01
1.9はsp2までまったほうが。

79:デフォルトの名無しさん
09/11/05 11:25:23
1.9.1自体は別に従来と比べて特段の不足があるわけじゃないんだけどな
外部ライブラリ周りと初心者向け解説群がまだ追っついてない

80:デフォルトの名無しさん
09/11/05 11:30:13
>>2の上二つは事実上見られない状態なので、代わりに
Ruby reference manual (beta)
URLリンク(doc.okkez.net)
を参照してほしい

81:デフォルトの名無しさん
09/11/08 15:08:24
Rubyのソースコードを読んでいるのですが、if, while等でインデントが崩れて読みにくいです。
タブ幅は空白4文字としています。
エディタはgvimなのですが、どう設定すると読みやすくなるのでしょうか?

82:81
09/11/08 15:15:42
C言語で書かれているRubyのソースコードを読んでいます。
タブ幅は空白文字4文字分としています。

83:デフォルトの名無しさん
09/11/08 15:20:20
自分でタブ幅いじって試そうとか考えないのか?

84:デフォルトの名無しさん
09/11/08 15:25:07
1TAB=8スペースみたいだよ。(set ts=8かね)
かなりスペースインデントとTABインデントが混在してるが、
揃える気ないんだろうなこりゃ。


85:81
09/11/08 19:40:12
URLリンク(i.loveruby.net)
が死んでるんだけど
もうRubyを愛してる人はいないの?

86:デフォルトの名無しさん
09/11/08 19:42:23
個人の自宅鯖だと思うから、しばらく落ちてたりしてもおかしくないと思う。

87:デフォルトの名無しさん
09/11/08 20:45:58
初心者スレでレスがないのでこちらでお願いします

NetBeans6.5.1、6.7、6.7.1の各バージョンでRuby1.8.7+SQLite3を使ってる方
いませんか?当方、複数のパソコンで

1.8.7-p72 → sqlite3-ruby → dbi → dbd-sqlite3

という順番でインストールしNetBeansとSQLite3とドライバの各バージョンを
試してみましたが、DBI経由で呼び出すと必ず

ERROR DBI::InterfaceError: Unable to load driver 'SQLite3' (underlying error: uninitialized constant DBI::DBD::SQLite3)


というエラーになります。
Rubyのバージョンが1.9.1だとエラーになりません。また、コンソールから実行すると
エラーになりません。ネットで検索しても有効な情報が得られないので困っています。
ちゃんと使えてる方いましたら教えてください。

88:デフォルトの名無しさん
09/11/08 20:47:36
python使うと楽だよ

89:デフォルトの名無しさん
09/11/09 01:46:15
>>87
dbd-sqlite3がどこにインストールされてるか調べてみるといいと思う

90:デフォルトの名無しさん
09/11/12 16:24:00
Rubyの実装はいつCからGoに切り替わりますか?

91:デフォルトの名無しさん
09/11/12 17:29:44
そういうニュースが出るとすぐ言いたくなっちゃうんだろうな

92:デフォルトの名無しさん
09/11/12 19:53:23
>>90
すでに GoRuby があります。

93:デフォルトの名無しさん
09/11/12 20:04:19
ペレストロイカ!!

94:デフォルトの名無しさん
09/11/12 21:47:18
文字コードネタで暴れてるのお前らだろw

95:デフォルトの名無しさん
09/11/12 22:30:53
goの話? むしろRuby使いなら、
「とりあえずバイト列」にも理解がありそうだが


96:デフォルトの名無しさん
09/11/17 21:10:26
以下のページに動的型付言語の問題が記載されているんだけど、
本当にこんな問題ってあるんですかね。いまいち理解できない。

URLリンク(www.infoq.com)

97:デフォルトの名無しさん
09/11/17 21:13:30
北米でPython使う人が増えてて、Rubyは増えてないとの記事がある。
URLリンク(sourceforge.jp)

いまではGoogleAppEngineでJRubyもつかえるみたいだけど、それでも
GoogleAppEngineではPythonの方がメリットあるの?

98:デフォルトの名無しさん
09/11/17 21:22:45
北米で500人か

99:デフォルトの名無しさん
09/11/19 17:45:02
動的にクラスへメソッドを追加することって出来ますか?
流石に無理かな・・・

100:デフォルトの名無しさん
09/11/19 17:54:07
え、それができるからいいんじゃないのか?

101:99
09/11/19 18:56:05
>>100
ありゃ、出来るんですか
Kernal、Objectあたりを見てもそれっぽいのは見つからないような・・・
良かったらどうすれば出来るのか教えてもらえますか?
よろしくお願いします

102:デフォルトの名無しさん
09/11/19 19:23:42
>>99
class Hoge
def a
...
end
end

class Hoge
def b
...
end
end

難しく考えなくていいですよ。
既存のメソッドの上書きまでできる(うっかり書き換えちゃう可能性もありますが)。

103:デフォルトの名無しさん
09/11/19 21:31:26
>>102
それインスタンスメソッド。


104:デフォルトの名無しさん
09/11/19 21:32:50
あう。
クラスメソッドを追加じゃなくて、
クラスへメソッドを追加、だったのね。
>>103は忘れてください。
カタカナの並びに埋没して「へ」が見えなかった。


105:デフォルトの名無しさん
09/11/19 22:32:31
別にインスタンスでもクラスでも関係ないと思うけど質問の意味が違うのかな?
class String
 def self.hoge ; 'hoge' ; end
end
hoge = String.hoge

メソッドを使って定義したいならModule#define_method

106:99
09/11/20 00:10:41
>>105
>Module#define_method
おぉ!まさしくそれです。Moduleでしたか・・・
ありがとうございました

107:デフォルトの名無しさん
09/11/20 12:39:28
やっぱり1.9ってVista的にスルー対象なの?

108:デフォルトの名無しさん
09/11/20 13:21:13
なにが「やっぱり」なの?

109:デフォルトの名無しさん
09/11/20 20:28:04
Win32APIの引数、戻り値の定義のintとlongの違いって何ですか?
どっちも4Byte(Windows for x86の場合)だと思うのですが

110:デフォルトの名無しさん
09/11/20 20:31:27
将来longが8bitになった時に、longのほうは8ビットになる...かもしれない。

111:デフォルトの名無しさん
09/11/20 20:32:46
8ビットワロタ

112:デフォルトの名無しさん
09/11/20 20:54:44
うわボケてたw

バイトねバイト。

113:デフォルトの名無しさん
09/11/20 21:18:38
何で6byteとかにはならないんですか?

114:デフォルトの名無しさん
09/11/20 21:20:48
多分誰も幸せになれないから

115:デフォルトの名無しさん
09/11/20 22:05:45
コンピューターは細かいところまで見ると結局すべて2進数で動いている
だから2の累乗のデータを扱うほうがきれいだし楽
と大した知識もないのにマジレスしてみた

116:デフォルトの名無しさん
09/11/20 22:40:18
winのapiを使ってプロンプトを開かずにCUIアプリを実行させて標準出力を得よう
とやってみたけど上手く動かねぇorz
URLリンク(www.h4.dion.ne.jp)
を参考に組んでいるんだけどパイプ関係が上手く動いていない気がする
PeekNamedPipe、ReadFileとも失敗する

どっかに似たようなことをしている事例とかないですかね?

117:デフォルトの名無しさん
09/11/20 23:53:38
これは誤爆だよな

118:116
09/11/21 00:04:33
ぁ…何処にもRuby/win32apiでって書いていなかった…釣ってくる…

119:デフォルトの名無しさん
09/11/21 07:37:48
>>109
winはLLP64だから32bit/64bit環境で違いが出ることはない
密かに開発中らしい128bitはどうなるか知らん

120:デフォルトの名無しさん
09/11/21 07:41:29
Win64APIのintは64bitなんですか?

121:デフォルトの名無しさん
09/11/21 08:05:02
>>116
この場合はCで試してみて順次Rubyに変換していくのが切り分けの常道ではあるまいか
しかし面倒なのでWIN32OLEでWshShellのRun使ってファイルに吐き出してしまえば楽
質問の内容と今さらWin32APIってところを考えるとまさかツクールか?だったらご愁傷様

次に質問するときは具体的にどんな感じで試してどう動いたかとRubyのバージョンは書いてくれ
あと、質問は初心者スレのが食いつきいいし、WindowsのRubyは専用スレがあることも付け加えておく

122:デフォルトの名無しさん
09/11/23 05:19:06
URLリンク(doc.okkez.net)
これより
URLリンク(www.ruby-lang.org)
の方がツリー上になっていてクラスの継承の関係が見やすいと思うのは俺だけだろうか・・・

123:デフォルトの名無しさん
09/11/23 10:07:58
俺もそう思うが、変えたからには意図があるんだろうと思って黙って見てた

124:デフォルトの名無しさん
09/11/23 16:04:24
Javaみたいに深い階層になってるわけじゃないからツリー上にするまでもない、ってことだろう。
ただ、クラスとモジュールをごっちゃにしてアルファベット順にする意義は全く無いと思うが。

125:デフォルトの名無しさん
09/11/23 16:54:47
ひどすぎ

126:デフォルトの名無しさん
09/11/23 20:45:11
Ruby1.8.5+rmagick/1.14.1なんですがαチャンネルを利用してcompositeしたあとにbmpで書き出すと
32bitで書き出されてしまいます。24bitで書き出したいのですがどうしたらいいですか?

127:デフォルトの名無しさん
09/11/23 22:52:33
>>122-124
単に見せ方についてまで手が回ってないだけ。
参加して見やすいように直してくれ。

128:デフォルトの名無しさん
09/11/23 23:04:41
>>126
img.alpha を弄って不透明にしてみるとか(思っただけ)


129:126
09/11/24 00:28:18
>>128
thx。が、1.x.xに.alphaは無いんだ・・・
.channel(AllChannels)で自己解決した

RMagickに限らずImageMagick系って該当スレがないんですよね・・・

130:デフォルトの名無しさん
09/11/24 13:07:31
>>120
調べりゃすぐわかると思うが、Win64ではintもlongも32bitのまま。

131:デフォルトの名無しさん
09/11/26 00:31:28
あの天下一品もrubyを使ってるんだな
URLリンク(tenkaippin.co.jp)

132:デフォルトの名無しさん
09/11/26 00:34:40
とみせかけて中身はPHPだったりして!

133:デフォルトの名無しさん
09/11/26 00:37:14
わざわざ.rbつける奴ってスタバでマックやバイオ広げるくらい自意識過剰な奴が多いよな

134:デフォルトの名無しさん
09/11/26 00:40:00
スタバなんだからマックのじゃなくてスタバの軽食食べればいいのにな

135:デフォルトの名無しさん
09/11/26 00:56:06
コーヒー飲みながらプログラミングがしたいだけなのに
まわりの目を気にするなんて意味不明だな
スタバとかMacにどれだけステータスつけてるんだと。
単にコーヒーがそこそこ美味しくて店内禁煙でどこにでもあるから
スタバにいるだけ。フォントがそこそこ美しくてUNIX環境がすぐ使えて
何かと便利だからMac使ってるだけなのに。嫉妬もたいがいにしてほしい。

136:デフォルトの名無しさん
09/11/26 01:02:29
レス長い
馬脚

137:デフォルトの名無しさん
09/11/26 01:08:29
>>134が少し考えないとわからなかった俺は関西人

138:デフォルトの名無しさん
09/11/26 01:13:08
MagLevのアルファ版が出たと聞いて

139:デフォルトの名無しさん
09/11/26 01:17:00
>>136
まーな
実際にそれが嫉妬だったとしても、コンプレックス持ちは>>135自身

140:デフォルトの名無しさん
09/11/26 04:54:19
Ruby 2.0.xの仕様ってどうなるのかなぁ・・・
また1.6.x→1.8.xの時のような状態になるのは勘弁してもらいたいわけだが

141:デフォルトの名無しさん
09/11/26 07:45:59
>>140
ずっと1.8.6使ってればいいじゃん

142:デフォルトの名無しさん
09/11/26 11:05:15
Ruby 1.9 And Rails 3.0
URLリンク(www.slideshare.net)

143:デフォルトの名無しさん
09/11/26 14:22:05
>>140
Rubyは進化したがってるのに、お前みたいな馬鹿ユーザーが足を引っ張ってるなw

144:デフォルトの名無しさん
09/11/26 15:17:03
バージョン上げる前にぐっちゃぐちゃの実装を何とかしろ

145:デフォルトの名無しさん
09/11/26 15:19:14
>>144
だから何年もかけてなんとかしてるだろ

146:デフォルトの名無しさん
09/11/26 16:33:14
>>144
例えばどこ?具体例plz
話題が大きくなれば開発側の耳にも入るかもよ

147:デフォルトの名無しさん
09/11/26 17:56:32
>>143
誰も進化するなとは言っていない
変更点があるなら事前に示して欲しいだけ
インタプリタのメジャーバージョンを上げたら
動かないコードがボロボロ出るような状態は困る

148:デフォルトの名無しさん
09/11/26 18:00:30
馬鹿な開発者が、十分なアナウンスもドキュメントも、それどころかまともな熟考もなく、
気分で形を変えて気持ち良くなってるのが、これまでのRubyの「進化」だからねぇ。
>>143みたいなシンパが、これでもかというほどスポイルした結果だろうけど。

149:デフォルトの名無しさん
09/11/26 18:02:44
具体的な指摘は結局なにひとつできないのな

150:デフォルトの名無しさん
09/11/26 18:40:32
>>149
日本語が読めないのか?
「メジャーバージョンアップ前に変更点一覧を公表せよ」
と言っているんだが

151:デフォルトの名無しさん
09/11/26 18:43:24
URLリンク(svn.ruby-lang.org)
英語が読めないのか?

152:デフォルトの名無しさん
09/11/26 18:54:10
>>151
英語は読めない。日本語は読めるが

153:デフォルトの名無しさん
09/11/26 19:12:12
まー基本的には、Matzが自分の作りたいものを作る言語だからな
ドキュメントが欲しいなら、他の人が書かないとどうにもならん

>>151
まず「日本語はないから英語読め」という姿勢自体が間違ってる

仮に英語を読むことにしたとする
その変更履歴だけを読んで、いったい何が分かるんだ?
具体的な情報は無いも同然だろ

154:デフォルトの名無しさん
09/11/26 19:31:10
ソースのdiffでも取って読めばいいんでない?

155:デフォルトの名無しさん
09/11/26 19:31:14
愛国Ruby
憂国Gauche
なんかうかんd


156:デフォルトの名無しさん
09/11/26 20:04:33
おまいらがゴタゴタしている間にPerlは6に進化していくというのに

157:デフォルトの名無しさん
09/11/26 20:12:15
釣れそうですか?

158:デフォルトの名無しさん
09/11/26 21:21:26
>>156
えらく巨視的なたしなめ方もあるもんだ
悠久の時の流れしか感じねえ

159:デフォルトの名無しさん
09/11/26 21:52:03
アキレスと亀のようだ
あっちはミクロだが

160:デフォルトの名無しさん
09/11/26 23:27:53
未踏いらない

161:デフォルトの名無しさん
09/11/27 00:07:50
メジャーバージョンあげるんなら、以前のコードが動かなくても当然くらいの勢いでいってほしい。
下手に互換性にとらわれても、どうせそのままじゃ動かないんだし。


162:デフォルトの名無しさん
09/11/27 00:27:58
えらく巨根をなめなめした

に見えた

163:デフォルトの名無しさん
09/11/27 19:04:46
日立ソフト、Ruby システム開発に対応する専門組織「Ruby センタ」を設立 - japan.internet.com Webビジネス

日立ソフトは2009年11月27日、オブジェクト指向スクリプト言語「Ruby(ルビー)」を活用したシステム開発案件に対応する専門組織として、
「Ruby センタ」を12月1日に設立することを発表した。

同センタは、Ruby 開発案件を集中対応するために設置された組織で、全社を横断する組織として窓口を一本化し、
おもに中小規模のシステム開発案件を中心にビジネス展開を進め、関連団体との連携を強化し Ruby の普及を促進する。

また、今回の Ruby センタ設立に併せて松江事務所(2008年10月設立)内に Ruby ラボを設置、
地元 IT 企業および関連団体との連携を強化していくという。
URLリンク(japan.internet.com)

164:デフォルトの名無しさん
09/11/27 20:30:47
日立って Be はどうしたんだっけ?

165:デフォルトの名無しさん
09/11/28 01:01:34
>>151
こんだけの情報で十分と思っているなら、利用者が何に困っているかをRuby開発陣はさっぱり理解できていない。

166:デフォルトの名無しさん
09/11/28 01:23:11
>>165
具体的に困っている箇所を教えてあげればいいんじゃない?


167:デフォルトの名無しさん
09/11/28 01:25:43
困ってることを具体的に開発陣に言えばいいじゃん
馬鹿に合わせドキュメント作ってたらキリ無いだろ

168:デフォルトの名無しさん
09/11/28 01:26:25
もろ被った

169:デフォルトの名無しさん
09/11/28 01:32:42
「利用者の欲求」の意見を全く無視したという話は聞かない
ほとんどはpendingあたりになってはいるはず
実際に解消されるかどうかは余剰リソースと優先度次第だが

170:デフォルトの名無しさん
09/11/28 01:42:43
Rubyが世界規模なのに開発が日本中心だからガス欠になるんだろうな

171:デフォルトの名無しさん
09/11/28 01:49:38
ガス欠なのか、エンジン性能特に馬力不足なのか、その辺も考慮に入れた例えかな?

172:デフォルトの名無しさん
09/11/28 01:49:51
JRubyがガンガン開発進んでるという話も聞かんが

173:デフォルトの名無しさん
09/11/28 01:53:00
JRuby結構進んでるけど、進めたところで本家の仕様がふわふわしてるからな

174:デフォルトの名無しさん
09/11/28 01:57:47
本家の動作がいいと思ってるなら本家のとおりに動作させればいいだけじゃん

175:デフォルトの名無しさん
09/11/28 02:16:58
>>166
NEWSを読んだうえでその発言?あれ読んで一般の利用者が理解できると思ってるの?

176:デフォルトの名無しさん
09/11/28 03:45:11
文句言うだけのお客さんが多くて手を動かす人がいないからこうなってるんだよ。

177:デフォルトの名無しさん
09/11/28 03:51:26
書き方の問題だから、そういう話じゃないよ

178:デフォルトの名無しさん
09/11/28 07:30:23
書き方の問題に文句言うだけのお客さんが多くて手を動かす人がいないからこうなってるんだよ。

179:デフォルトの名無しさん
09/11/28 09:01:02
違うだろ。開発陣とその近辺にはあれで十分と考えている人間しかいないことが原因。>>151はその典型。

180:デフォルトの名無しさん
09/11/28 09:08:30
と、ここで騒ぐだけだから、改善されるわけがないよな。

181:デフォルトの名無しさん
09/11/28 09:15:36
開発陣とその近辺にはあれで十分と考えている人間しかいないって
文句言うだけのお客さんが多くて手を動かす人がいないからこうなってるんだよ。

182:デフォルトの名無しさん
09/11/28 09:33:06
>>175
一般ってなに?

というか君の言う「一般」向けにプレスリリースなりなんなりしている言語があったら知りたい
ソース読める言語のオフィシャルはどこもこんな程度だと思うが
詳説はなんか言語の名前の入ったよくわからん関係のサイトが記事にしたりする印象

183:デフォルトの名無しさん
09/11/28 10:13:59
どうせ無学歴のJava出身とかそこら辺の奴が文句付けてるんだろ。
例えばJava5の新機能なんてネット上にいくらでも易しい解説があるし、変更点を噛み砕いて説明してくれるからそういうのに慣れちゃってるんだろう。

184:デフォルトの名無しさん
09/11/28 10:44:15
無学歴かどうかはともかく、「あってもいい」が、「無いからといってオフィシャルが非難される謂れもない」ねえ
コミットログが公開されない、みたいなのなら公然と非難してもいいが、辿ることは可能だしな

ボクに懇切丁寧に無料で教えてくれるシンセツナヒトが現れないというのなら、
そりゃオフィシャルの仕事じゃないんでコミュニティで吠えてくれ

185:デフォルトの名無しさん
09/11/28 10:55:43
> そりゃオフィシャルの仕事じゃないんでコミュニティで吠えてくれ

やめてくれ。
このスレが無情報なレスで埋まってしまう。

186:デフォルトの名無しさん
09/11/28 10:58:44
PerlerなんだけどRubyはどこらへんがPerlと比べて楽でどこら辺が大変か教えてくれ

187:デフォルトの名無しさん
09/11/28 10:58:49
このスレそういう連中の隔離スレだと思ってた

188:デフォルトの名無しさん
09/11/28 11:12:03
>>186
利点: Perlより書きやすく、Perlのように気軽に日常用途で使える
欠点: Perlじゃない

総評としてはPerlじゃないので習得する価値は薄い

189:デフォルトの名無しさん
09/11/28 11:32:22
>>187
と、いうことに(void

190:デフォルトの名無しさん
09/11/28 12:00:18
>>186
利点:Perlのように後付けOOPでないので、オブジェクト指向コードが書きやすい
欠点:CPANほどライブラリーがそろっていない

191:デフォルトの名無しさん
09/11/28 12:54:16
Rubyは、便利なライブラリがなければ自分で作ればいい
っていう発想というかパワーがある人向けかな。
CPANのようなライブラリがないと嫌だって人には向かないかもしれん。
個人的にはそう思ってる。

192:デフォルトの名無しさん
09/11/28 14:16:08
といっても、最近ではgemが充実してるから
あながち「ライブラリが弱い」とは言い切れないのでは

193:デフォルトの名無しさん
09/11/28 14:25:58
仕事だとruby単体で使う機会が無いんだよなぁ
Railsの案件ならいくらでもありそうだけど。

194:デフォルトの名無しさん
09/11/28 15:57:30
URLリンク(satoshi.blogs.com)

中島氏がまた煽ってるぞ。誰か反論してやれよ

195:デフォルトの名無しさん
09/11/28 16:19:57
ほんにんおちゅ

196:デフォルトの名無しさん
09/11/28 16:31:59
>>194
何か反論するような箇所があるか?


197:デフォルトの名無しさん
09/11/28 16:51:51
Rails排除しろとは誰も言っていないわけだが?

198:デフォルトの名無しさん
09/11/28 17:28:05
RubyのGCの停止時間ってどれくらいですか。
ゲーム作ったら数秒に一回わずかに停止するのですが....
これがGC?


199:デフォルトの名無しさん
09/11/28 17:30:42
GC止めてみたら?

200:デフォルトの名無しさん
09/11/28 17:36:31
>>198
世になんでRubyアプリが少ないか考えてみるといいよ

201:デフォルトの名無しさん
09/11/28 17:42:04
>>194
O/Rマッピングってキャッシュできないのかな

202:198
09/11/28 17:54:52
>>199
ビンゴ。GC止めたら変な引っかかりは消えました。
ありがとうございました。

完全に止めるわけにはいかないので毎フレームGC.startを呼んだら
それでも大丈夫だったのでこれで。


203:デフォルトの名無しさん
09/11/28 17:57:54
ドキュメントは比較的まともだがちっとも普及しないRuby
組み込みでよく使われるがリファレンスマニュアルが糞過ぎて使えないPython
マッタク困った物だ

204:デフォルトの名無しさん
09/11/28 18:01:00
釣りじゃないなら具体的によろ

205:デフォルトの名無しさん
09/11/28 18:14:20
>完全に止めるわけにはいかないので毎フレームGC.startを呼んだら

ゲーム作りの常識

206:デフォルトの名無しさん
09/11/28 18:16:24
ドキュメントが糞過ぎてちっとも普及しないRuby


207:203
09/11/28 18:16:44
>>204
俺のこと?

208:デフォルトの名無しさん
09/11/28 18:30:36
>>205
おい、俺今までGC止めずにゲーム作って、しかも公開してたんだぞ……
そういうことはもっと早くに指摘して欲しかったよ!

209:デフォルトの名無しさん
09/11/28 18:32:23
アマチュアPCゲーム製作はスタッフにPentiumIII使用者の人を混ぜる
これまめちしきな
高スペックだと絶対気づかんことも、彼なら気づく

210:デフォルトの名無しさん
09/11/28 18:51:05
愛国Ruby

211:デフォルトの名無しさん
09/11/28 21:12:34
>>201
スキーマが変わったことがわかる低コストな方法があればARでサポートできるだろうけど。
そうじゃなければユーザ責任でちゃんとキャッシュを更新しないと
悲惨なことになるからサポートしないんじゃないかな。
メソッド再定義して、スキーマ情報を変数にキャッシュしておくことは簡単にできると思う。

212:デフォルトの名無しさん
09/11/29 01:59:31
Rubyのマニュアルは良い方だと思うけどなぁ
誤記満載のMSDNとか、メソッドの定義クラスすら書いていないPythonなんかよりRubyの方がはるかにまとも
Rubyにも至らないところがあるのは事実だから今のままで良しとはしないで欲しいけど

213:デフォルトの名無しさん
09/11/29 08:03:50
Pythonは各クラスがコンパクトだから問題にならないような
MSDNの誤記が多い?のはお仕事言語だから細かい仕様まで記述してるせい

214:デフォルトの名無しさん
09/11/29 10:14:40
>>213
まあそれ言っちゃうと、何にでも免責可能な部分はあるわな。
むしろ、受益者負担の原則でいくなら、メリットの大きい者(商売に使っている者)から順に改善すべきなんだけどな。
メーカーもそれが分かっているから、逆に防衛のためにMSDNなんかは契約書に「内容の正確性は保証しない」旨を明記している。

215:デフォルトの名無しさん
09/11/29 10:22:29
MSDNは末尾に指摘欄があるのは好感。
誤字は何度か直った経験はある。

216:デフォルトの名無しさん
09/11/29 10:45:48
>>212
下を見ればきりがない

217:デフォルトの名無しさん
09/11/29 11:52:44
PHPのマニュアルは充実している。
「User Contributed Notes」好きだ。

218:デフォルトの名無しさん
09/11/29 12:27:10
Perlを越えろ

219:デフォルトの名無しさん
09/11/29 13:39:52
>>212
漏れはPythonのマニュアルでそんなに困ったことは無いんだが
おまいさんと見ているものが違うのかもしれない
具体的にどの変がおまいさんに理解出来なかったのか示してください

220:デフォルトの名無しさん
09/11/29 13:55:23
そもそもRubyのマニュアルで自分も困ったことがない
マニュアルが充実してないっていう人は、何が問題なの?

221:デフォルトの名無しさん
09/11/29 14:06:45
>>219
>>212ではないけれど例えばこれ
URLリンク(docs.python.org)

属性がモジュールメソッドなのかクラスメソッドなのか
インスタンスメソッドなのか一目で区別できないのが難点
以前のバージョンは属性名だけポンと書かれていたのでもっと判別しにくかった
クラスの説明が数ページに収まるPythonの場合はたいしたことじゃないと個人的には思うけど

>>220
ManpagesやMSDNなら書いてあるようなことが書いてないから
お仕事言語として使う人は現状だと困るのかも

よく覚えてないけどO_APPENDみたいにアトミックな追記Rubyでどうやるのって質問があって
回答者が歯がゆそうだった

222:デフォルトの名無しさん
09/11/29 15:40:12
CやJavaで組むときは確かに、言語仕様書が必須だな。
RubyとかPythonの時はマニュアルが無いからといって困った記憶がないが、理由はどうやら組み方にあるようだ。
Rubyなどではコード補完を使ってどんどん書いて、一緒にテストコードも作るから、挙動について勘違いがあってもすぐ判る。
むしろパフォーマンスや再利用性アップのために、ロジックを組み替える事の方が多い。
Cとかでは一回組んだものを再構築するのは、もう少し手間がかかるから、事前にしっかり言語仕様を確認しておきたい、という違いじゃなかろうか?

223:デフォルトの名無しさん
09/11/29 16:10:32
というか、コンパイル言語かどうかで姿勢は全く違う
下手したらバイナリしか配らないような言語では、設計フェーズの重要性がうんと高い
コンパイルに2時間とかそういうプロジェクトも。設計ありきで使う

そういう場合はちょっと試して駄目なら変える、ができないから、事前情報は正確に膨大に欲しい

224:デフォルトの名無しさん
09/11/29 18:18:27
結論としては、ドキュメント欲しがるやつはクソ

225:デフォルトの名無しさん
09/11/29 18:40:28
ドキュメントに突っ込むとレッテル貼って否定する香具師を
あちこちのスレで見かけるんだけど何なの?
Win32APIスレにもPythonスレにも居いるな

226:デフォルトの名無しさん
09/11/29 18:40:52
>>222
ちょっとした曖昧な部分はインタプリタに対話モードで尋ねるという選択肢があるのもでかい

227:デフォルトの名無しさん
09/11/29 18:45:35
Pythonはモジュールもクラスもインスタンスも全部オブジェクトだからなぁ。
静的型付け言語やモジュール、クラス、インスタンスの境界が明確な言語と
違って、違いを明記しなくてもわかり難いなんてことないや。

228:デフォルトの名無しさん
09/11/29 18:48:09
RubyやPythonは、基本的にモジュールと一緒にソースが公開されるのも大きいよな。
正確な情報は全部ソースに書いてあるから、ドキュメントは精密さよりも素早く概観
できるほうが大事。

229:デフォルトの名無しさん
09/11/29 18:57:27
>>224
どの言語でも、ドキュメントが有るに越した事はない。
ただ、特にボランティアの場合、ドキュメントにかける労力をその他を改善に向ける方がいい場合もある。
「ドキュメントが無い事」を、出来ない言い訳にしてるヤシは論外な。

230:デフォルトの名無しさん
09/11/29 19:20:06
というか、ドキュメント作成の類こそ「あなたにもできる大貢献」だと思うのだが

Javaドキュメントは金かけた売りもんだから比較はできん

231:デフォルトの名無しさん
09/11/29 19:56:39
>>219
Python2.6のリファレンスマニュアルで演算子の優先順位って何処に書いてあるのかなぁ・・・
って何でPythonドキュメントの話になっているんだw

>>230
平気でそういう事を言う人がいるけど、書きたい項目の動作に熟知していないとマニュアルなんて書けないよ
外野には目の前の動作が仕様通りの動作なのか仕様外の動作なのか判らないからな
実質的にマニュアルの記述が出来るのは開発者及び開発者と緊密に連絡が取れる人に限られる

232:デフォルトの名無しさん
09/11/29 20:03:37
>>231
そりゃマニュアルは外部の人間には書けん
しかしマニュアルだけがドキュメントではない

233:デフォルトの名無しさん
09/11/29 20:05:19
愛国!!!

234:デフォルトの名無しさん
09/11/29 20:05:43
外部の人間がドキュメント書いてるなんてあまり聞かない気もするけどなんかある?

235:デフォルトの名無しさん
09/11/29 20:08:01
>>234
ちょっと詳しい解説記事とか導入記事とかブログに載せるだけで価値があると思うけどね

236:デフォルトの名無しさん
09/11/29 20:26:16
不正確なBLOG記事で時間を無駄にした経験がないようだな

237:デフォルトの名無しさん
09/11/29 20:27:23
>>232
言語に限らずマニュアルの重要性は最上位だと思うが?

238:デフォルトの名無しさん
09/11/29 20:31:35
>>235
ブログ記事でいいのならるびまがあるじゃん
だいたいブログより正確だし、解説記事や導入記事が揃ってるぞ

239:デフォルトの名無しさん
09/11/29 20:41:19
>>236
そうだね
漏れはpythonの内部コード表現=UNICODE=UTF-8っていうサイトを見て信じてひどい目にあった

240:デフォルトの名無しさん
09/11/29 21:40:33
>>237
論点ずれてるぞ。
「マニュアルだけがドキュメントではない 」に対して反論があるなら
「マニュアルだけがドキュメントだ」にしなきゃ。

241:デフォルトの名無しさん
09/11/29 21:50:02
日本語しゃべれるならIRCにくるだけで主要開発者と緊密に連絡取れます
お待ちしております

242:デフォルトの名無しさん
09/11/29 21:50:45
主要開発者って暇なの?

243:デフォルトの名無しさん
09/11/29 22:08:52
なんで、外部・内部って分けたがる人がいるんだろ。
「ドキュメントで協力」っていうのだって開発者への感謝もあって、自分に出来る事をする、じゃ駄目なん?
俺なんかは、フリーソフトだから気軽に試してみてRubyの世界を知った口だから、企業品質を求めるより
もっと実験的になってもいいと思ってるくらいだ。
まあ、人によってバザール/伽藍のどちらよりか、程度の事かもしれんが。

244:デフォルトの名無しさん
09/11/29 22:09:19
Perlでは決してありえない話だよな
超多忙であられる開発者様と直接お話申し上げるなど…

245:デフォルトの名無しさん
09/11/30 00:48:08
と言うか1.8.xって2.0.xが出るまで保守されるのか?

246:デフォルトの名無しさん
09/11/30 01:06:11
1.8前提のアプリケーションが現在進行形で作られてるわけだし、
サポートしないわけには行かないと思うけど。
1.9でgemのほとんどのライブラリが動くようになるまでは、
1.8ユーザが1.9に移行するメリットはないしね。



247:デフォルトの名無しさん
09/11/30 04:41:24
1.8が2.0を待たずにサポート終了になる
 →今から手元のコードを積極的に1.9に対応させる必要がある
1.8が2.0までサポートされる
 →2.0が出るまで待って手元のコードを2.0に対応させればいい
はっきりしないのが一番困るw

オフィシャルに1.9.1は安定版って書いてあるんだよなぁ・・・

248:デフォルトの名無しさん
09/11/30 07:12:50
2.0が未来永劫でないのであれば何も問題ない

249:デフォルトの名無しさん
09/11/30 09:49:30
>>246
1.8 が保守されなくなれば 1.9 に移行しないことにデメリットがあるな。

250:デフォルトの名無しさん
09/11/30 09:51:02
>>231
お前にドキュメントが書けない言い訳は>>241で論破されたと思うが、
次なる言い訳は?

251:デフォルトの名無しさん
09/11/30 09:57:10
>>247
オフィシャルがサポートしなくなっても頼るところはいろいろあるじゃん
PhusionとかEngine YardとかJRubyとか
てか、1.8.6は今EYがメンテナじゃなかったっけ?終了はありえないだろ

252:デフォルトの名無しさん
09/11/30 09:57:15
> Python2.6のリファレンスマニュアルで演算子の優先順位って何処に書いてあるのかなぁ・・・

まとめて書いてはない。構文規則中に組み込まれてる。

253:デフォルトの名無しさん
09/12/01 01:30:17
>>252
>> Python2.6のリファレンスマニュアルで演算子の優先順位って何処に書いてあるのかなぁ・・・
>
>まとめて書いてはない。構文規則中に組み込まれてる。

そういうデマを書くなよ。またRubyが叩かれるだろ。

Pythonにおける演算子の優先順位
URLリンク(www.python.jp)

254:デフォルトの名無しさん
09/12/01 01:37:16
>>250
>>>231
>お前にドキュメントが書けない言い訳は>>241で論破されたと思うが、
>次なる言い訳は?

おまえ、あれで論破したつもりになっているのかよ。
書きたい項目の動作を熟知しない人に対し、わかるまで開発陣が懇切丁寧に教えてくれるの?
ほんとにそんなサービス精神あったら、はなからもっとましなドキュメントを用意してくれるだろうよ。

まあだいたいオチは読める。

【パターン1】
素人:ここがわかりません
開発陣:勉強してから出直してこい

【パターン2】
素人:ここがわかりません
開発陣:そこはこうこうでこうだから・・・
素人:???説明がよくわかりません。もっとわかりやすく教えていただけますか
開発陣:勉強してから出直してこい

255:デフォルトの名無しさん
09/12/01 01:45:35
>>254
> 書きたい項目の動作を熟知しない人に対し、わかるまで開発陣が懇切丁寧に教えてくれるの?
ドキュメント書きたいというのなら教えてくれると思うよ
試してみたら


256:デフォルトの名無しさん
09/12/01 02:07:31
>>253
俺はPythonを使ったことがないが、その文書のタイトルが酷いなw
総当たりをするか、知っている奴じゃないと辿り着けないだろ

つか、何故Pythonの話に・・・ネタ切れか・・・

257:デフォルトの名無しさん
09/12/01 04:51:53
まあ演算子の優先順位どっちだっけって迷ったらカッコ使えばいいし
自分が迷うようなところは他の人が読んでも大抵迷うんだからカッコ使っとけという話だね

よし、これで話が本筋からうまく外れたな

258:デフォルトの名無しさん
09/12/01 12:38:38
>>254
勉強する

詳しくなる

ドキュメント要らなくなる←いまここ

259:デフォルトの名無しさん
09/12/01 12:41:42
サービス精神どうこう言うなら、自力で勉強してその知識を
ドキュメント化する(自力で勉強するのを自分で最後にする)
というサービス精神はお前にはないの?

260:デフォルトの名無しさん
09/12/01 15:00:09
勉強するためにドキュメントが必要なんじゃん!


261:デフォルトの名無しさん
09/12/01 19:36:45
URLリンク(ruby-std.netlab.jp)

262:デフォルトの名無しさん
09/12/01 20:27:35
>>260
勉強する=ソース読む+開発者とコミュニケーションとって仕様を明らかにする

263:デフォルトの名無しさん
09/12/01 20:36:59
仕様は基礎の基礎にあたる部分は今まさにドキュメントとして公開されたわけだが

264:デフォルトの名無しさん
09/12/01 20:44:02
万人に分かるように全ての仕様を網羅して噛み砕いて文書化しろ

265:デフォルトの名無しさん
09/12/01 21:14:05
おお。骨格になる重要クラスのメソッドは
挙動を確定させるのね(当たり前か)

266:デフォルトの名無しさん
09/12/01 21:37:50
開発する人からすれば文書書きなんて退屈この上ないだろうしな。
ドキュメントが無いんじゃ衰退も止む無しだろう

267:デフォルトの名無しさん
09/12/02 01:15:39
>231とか>258-259とか見て思ったこと。
あんなドキュメントで十分だと開発陣や上級者は思っているし、
今のドキュメントがわかりにくい・不親切であることを認めようとはしないんだから、
これからもRubyのマニュアルやドキュメントがましになることはないな。
そりゃ初心者はみんなPHPに走るわけだ。

268:デフォルトの名無しさん
09/12/02 01:30:55
>>267
つまらん言い方をすれば、いまはこんなもんということ。

とはいえ、一部に問題意識を持っている人もいないでもないから、
>>267に限らず、ここに具体的に何が欲しいか書き散らしていると
いつの間にかドキュメントが増えてたりするかもしれない。

269:デフォルトの名無しさん
09/12/02 01:59:28
オフィシャルのドキュメントが不十分だと吠える奴はいるが
どう不十分なのか、どのようにすればいいのかを書いている人は少ないな・・・

今のところ出ているのは更新履歴をしっかり出せくらい?

270:デフォルトの名無しさん
09/12/02 05:47:37
Perl4の水準にも劣る

271:デフォルトの名無しさん
09/12/02 08:02:17
「お客さん」は開発者にとってはうざいだけだからな。


272:デフォルトの名無しさん
09/12/02 08:07:10
というか他の言語では「お客さん」を食い物にするエコシステムがすでに成立してるんだよね
ある意味では未成熟ともいえるし、ある意味では健全とも言える

273:デフォルトの名無しさん
09/12/02 08:09:06
俺は今のドキュメント事情を見て、そんなに不満はないかなー

ただ二つ気になるのは、Ruby1.8と1.9の違いが
公式サイト上で分かりやすくアナウンスされてないことと
るりまへの参入障壁が高いこと
(以前のWikiリファレンスのように、誰でも書き換えられる形のほうが良かった)

274:デフォルトの名無しさん
09/12/02 08:19:57
「特異」の訳は Singleton じゃなくて Eigen になったのか。


275:デフォルトの名無しさん
09/12/02 08:38:13
>>269
>>122-124

276:デフォルトの名無しさん
09/12/02 08:54:43
>>274
Eigenclass っていう用語は前から使ってなかったっけ、と思ったが記憶が曖昧だ。
特異クラス = Eigenclass
特異メソッド = Singleton method
で統一されるのかな

277:デフォルトの名無しさん
09/12/02 09:38:37
EigenclassにするならEigenmethodにしろという意見も出てるみたいだね

278:デフォルトの名無しさん
09/12/02 13:44:34
前にサイン会でMatzに訊いたらEigenclassよりSingleton classの方が
好きと言ってましたけど,好き嫌いだけで用語を決めるのは
無理だろうから,どうなるかな

279:デフォルトの名無しさん
09/12/02 13:49:02
どうも永源遙が浮かんで困る

280:デフォルトの名無しさん
09/12/02 14:03:32
あいげん?


281:デフォルトの名無しさん
09/12/02 14:04:36
BookShelf 3.0に載ってない単語を使うなと

282:デフォルトの名無しさん
09/12/02 14:09:17
例文が某隣国に侵略を受けていると評判の英辞郎発進

eigen-      固有の
eigenfrequency 固有振動数
eigenfunction  固有関数
eigen fuzzy set 固有ファジー集合
eigenvalue    固有値
eigenvector   固有ベクトル



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

5380日前に更新/80 KB
担当:undef