09/08/06 23:39:00
どっちも駄目
まだ
きちんと一定の形に完成しないのなら意味がない
701:デフォルトの名無しさん
09/08/06 23:41:59
JRubyは完成したとして何に使うのかがよくわからない
IronRubyはWin環境でのライブラリ不足を一挙に解決してくれるからな
702:デフォルトの名無しさん
09/08/07 00:01:12
ふと一行78文字ルールと戦うIronPythonデベロッパの姿が脳裏に浮かんだ
703:デフォルトの名無しさん
09/08/07 00:26:51
JRubyだってJavaのライブラリ使えるのが強みだろうさ
あとJVMが動く場所なら動くことと、JVMが速くなりゃJRubyも速くなること
704:デフォルトの名無しさん
09/08/07 04:03:18
1.9.1の最新版のmswin32のバイナリは出ないのだろうか・・・
705:デフォルトの名無しさん
09/08/07 08:33:10
>>700
「きちんと一定の形」についてもう少しkwsk
706:デフォルトの名無しさん
09/08/07 08:47:11
>>704
fURLﾘﾝｸ(ftp.ruby-lang.org)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
なぜusaさんのページで出てないのかは謎
707:デフォルトの名無しさん
09/08/07 11:50:58
jrubyはもう駄目だろ Sunにさえ見放された
IronRubyは世界標準のWindowsだし、世界最強IT会社のMS製だし・・・
708:デフォルトの名無しさん
09/08/07 12:07:19
マイクロソフトが手を出せば成功するというのなら世の中はとっくに
709:デフォルトの名無しさん
09/08/07 12:26:30
Ruby の今後について、マーケティング用語「キャズム」を紹介する
URLﾘﾝｸ(www.mitsue.co.jp)
一般的にテクノロジーのライフサイクルはベル型の標準偏差のグラフによって示され、
その各段階でターゲットとすべき顧客として、イノベーター、アーリー・アドプ
ター、アーリー・マジョリティ、レイト・マジョリティ、ラガードといった顧客セグ
メントが行なわれます。通常、この顧客セグメントによって、異なるマーケティング
施策を行いながら、徐々に新しいテクノロジーの顧客層を広げていくことが推奨され
ます。しかし、米のマーケティング・コンサルタントであるジェフリー・ムーア氏が、
同名の著書によって、明らかにしたのは、イノベーターとアーリー・アドプター
で構成される初期市場と、アーリー・マジョリティやレイト・マジョリティによって
構成されるメジャー市場のあいだには、容易には越えがたい「キャズム（深いミ
ゾ）」あるということでした。顧客セグメントの違いによって生み出される、この
キャズムを超えなくては、新しい商品はメジャー市場でブレイクすることなく、規模
の小さな初期市場のなかでやがては消えていく運命となります。同著が、10年間にわ
たって米国ハイテク業界のバイブルとされたように、特にテクノロジーの進歩の激し
い業界においては、強く意識することが重要なマーケティング理論です。
以下は、マーケティングの視点で、Twitter の普及を分析
Twitter の快進撃がとまった!?～スローダウンの要因を分析する
URLﾘﾝｸ(japan.internet.com)
710:デフォルトの名無しさん
09/08/07 12:35:14
ふだんは Java と Ruby を両方いじっている者だが
(Java 系のエンジニアだが、さいきん Rails も覚えた)
Java のプロジェクト内ライブラリを叩く運用ツール(半使い捨て)を、
# たとえば 在庫一覧をファイルに出力するツールなど
いまは Java のプログラムでつくっているが、
これを JRuby でやるようにしたら、もっと手軽に作れないかなと思っている。
JRuby は、マルチスレッドプログラミングするなら Ruby 1.9 系よりも速いんじゃなかったっけ？
このスレだかどこかで読んだような
711:デフォルトの名無しさん
09/08/07 12:51:12
>710
そういうのは、Scalaでやった方がいいと思う。
712:デフォルトの名無しさん
09/08/07 13:12:29
>>710
Javaなら一応Groovyとかもあるかな
arton氏が似たようなシチュエーションでrake使って
自動化とか効率化とかやってたはず
713:710
09/08/07 13:17:10
>>712
Groovy は少しかじったけど、なんかいまいち。
Ruby のほうが見やすいし、Ruby / Groovy でできないところは Java で書く。
Groovy は Java しか出来ない人のスクリプト言語って感じだけど、Ruby 本物を覚えてしまった今、
いまいち中途半端だなあと感じる。
>>711
Scala でも使い捨てスクリプトをちゃちゃっと作れるのかな。
714:デフォルトの名無しさん
09/08/07 14:24:50
JRubyがもう少し起動早くなったらGUIが気持ちよくかけるかもしれない
715:デフォルトの名無しさん
09/08/07 17:19:04
>>713
そんなことない。
Groovyは最初からJavaと連携できるよう考慮されているから、Javaもよく使うならJRubyよりGroovyのほうがいい。
JRubyはあくまでRubyをJVMで使いたい人向け。
716:710
09/08/07 17:38:54
>>715
なるほど。
どうやら自分は、まだ Groovy への理解が足りないようだ。もうちょっと勉強してみるよ。
でも、るび厨になってしまったので、Ruby や JRuby いじっているほうが楽しいんだけどね。
717:デフォルトの名無しさん
09/08/07 21:53:14
あとGroovyは一時はJavaSDKに標準添付の話まであったのに
そのあと大きな動きがなくてプロジェクトが死んじゃってるんじゃねえの、って状態なのも難点かなあ
718:デフォルトの名無しさん
09/08/07 22:22:20
Groovyはコレの24p以降のイメージが強烈すぎた
URLﾘﾝｸ(kakutani.com)
719:デフォルトの名無しさん
09/08/07 23:21:26
おまえらのせいでGroovyに興味が湧いてきた
720:デフォルトの名無しさん
09/08/07 23:43:45
>718
なんだこれｗｗｗｗｗｗｗ
721:デフォルトの名無しさん
09/08/07 23:49:51
なついなあライブでみたよ
722:デフォルトの名無しさん
09/08/07 23:53:53
>>718
無駄に力作過ぎるが、全体を通してみてこれで使ってみたくなるか？という素朴な疑問
公平な紹介ってなんだろうけど
723:デフォルトの名無しさん
09/08/08 09:25:45
>>718
ネタ帳かとおもたwwwwwwww
724:デフォルトの名無しさん
09/08/08 09:28:03
弱点
● 機能セットがすべて出揃っていない
? 匿名インナークラスが未サポート（Groovy-1.1までに対応?)
? モダンなIDEでのサポートが不十分(Eclipse, IntelliJ...)
● 実行速度が遅い
? 対Java比: 20～90%
● デバッギング・ヘル!
? パーサが未成熟: わけのわからんエラーメッセージ
wwwwww
725:デフォルトの名無しさん
09/08/08 10:20:13
>>724
それ、いつのこと？現時点での話じゃないよね
726:デフォルトの名無しさん
09/08/08 11:37:41
>>725
>>718のPDFを見れば書いてあるよな
727:デフォルトの名無しさん
09/08/08 11:53:34
Ruby 初心者スレッド Part 30
ｽﾚﾘﾝｸ(tech板)
初心者スレが立ちました
アンチスレは落ちたままです
最終の遣り取りは以下の通り
> 979 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:50:29
> Ruby ってメモリ馬鹿食いするよね？
>
> 980 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:57:59
> まあ、そこそこには
> 省メモリで動作することが重要なのならRubyは使ってはいけない
728:デフォルトの名無しさん
09/08/08 12:41:08
>>726
>>>718のPDFを見れば書いてあるよな
それ、2004年の資料だよね。だから>>724は現時点での話じゃないよね。
おわかり？
729:デフォルトの名無しさん
09/08/08 12:51:02
別にいいけどおまえの言うことを
必死でくみ取ってくれる存在なんて両親くらいだぞ
730:デフォルトの名無しさん
09/08/08 13:14:14
Rubyの会のサイトって死んでるの？
解散した訳じゃないよね？
URLﾘﾝｸ(jp.rubyist.net)
731:デフォルトの名無しさん
09/08/08 13:35:53
>730
最近サーバの調子が悪いらしい
732:デフォルトの名無しさん
09/08/08 13:39:03
PJの社長みたいに金余ってる人がスポンサーにつかないものか
733:デフォルトの名無しさん
09/08/08 13:50:15
最近と言っても、ここ数日の話なので仕方ないと思われる。
734:デフォルトの名無しさん
09/08/08 17:07:25
1.8の方のDLってひょっとして可変長引数扱えないのかな。
ruby-ffiは出来るみたいだからそっちでごまかすかのう。
735:デフォルトの名無しさん
09/08/08 20:02:51
>>732
Ruby 界隈でイケメンはいないだろ
736:デフォルトの名無しさん
09/08/08 20:44:54
アンチスレも消えてすっきりしたな
737:デフォルトの名無しさん
09/08/08 23:09:44
>735
_why はイケメン。
738:デフォルトの名無しさん
09/08/08 23:50:23
これって既出ですかね？
Ruby1.9.1、Python3.1、Java1.6.0の実行速度比較
URLﾘﾝｸ(www.mwsoft.jp)
1.8は遅かったけど1.9はかなり速くなったと聞いてたので
そろそろRubyをしっかり勉強するのもありかなと思ってたんですが
この結果を見て愕然としました
何故にこれほど遅いんでしょう…
もう高速化の手段は残ってないんでしょうか…
739:デフォルトの名無しさん
09/08/08 23:59:25
WindowsでRubyって・・・
740:デフォルトの名無しさん
09/08/09 00:17:54
>>738
高速化技法はまだ全然試されていないからまだまだ伸び代はある。
Pythonも高速化計画が持ち上がってたはずだし。
741:デフォルトの名無しさん
09/08/09 00:18:17
そういえばRubyが遅い遅いとは言われてるけど
なんで（少なくともベンチマーク上では）遅いのか、その理由がよくわからない
1.9.1からYARVが入って、他の言語と同じバイトコンパイルになったはずだし
Pythonあたりと柔軟性で極端な違いがあるとも思えないし
742:デフォルトの名無しさん
09/08/09 00:19:57
>>738
きっきっと、新しいバージョンだから遅いいんだよ
最適化された・・・バージョンアナら・・・ぼぼろ負けはしないよ
>>739
LinuxにはPython入ってるから、Windowsで・・・
743:デフォルトの名無しさん
09/08/09 00:27:05
正直、じゃんごの日本語リファレンスとかもうちょっと充実してきたら
Pythonに移ってもいいかなって思ってる
744:デフォルトの名無しさん
09/08/09 00:31:09
俺は日本語リファレンスが充実しても、Pythonには行かないなー
Rubyが使いやすすぎて、ちょっとやそっとの速度差で止める気にはならない
どうしても速度が気になるなら拡張ライブラリがあるし
745:デフォルトの名無しさん
09/08/09 00:35:37
IronRubyによってMSが10倍速にしてくれるから気にするな
Linuxは知らん
746:デフォルトの名無しさん
09/08/09 00:36:34
>>745
その時には素敵な拡張文法がてんこ盛りだったりして
747:デフォルトの名無しさん
09/08/09 01:20:32
JRubyでいいじゃんはやいじゃん
748:デフォルトの名無しさん
09/08/09 01:46:45
とりあえずRubyがWindows上で遅い、特に一定の条件が揃うと妙に遅いというのは前から言われてる
あと、usa版バイナリはVC6でコンパイルしているので最適化が甘い
ので、まずはコンパイラを揃えてテストするべき
749:デフォルトの名無しさん
09/08/09 01:48:48
ということは、mingw版の方が速い可能性があるってことなのか
750:デフォルトの名無しさん
09/08/09 01:52:45
というか、Linuxサーバー上で運用されることが実際には多いんだから
Linuxでテストしないと意味がないと思うんだが・・・
Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
ASP.NET使うだろｊｋ・・・
751:デフォルトの名無しさん
09/08/09 07:46:33
> ということは、mingw版の方が速い可能性があるってことなのか
まぁ、それはあるけど、素直にVC9を使うのが楽だと思うよ
> Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
> ASP.NET使うだろｊｋ・・・
IronRubyをテストしてあげて！
752:デフォルトの名無しさん
09/08/09 09:02:21
>>751
またそんないばらの道を...
というかmingw32のほうがVC(9含めて)よりはやいというのは、以前からわかってる。
753:デフォルトの名無しさん
09/08/09 16:41:58
Windowsならgcc -O3で野良だろJK
754:デフォルトの名無しさん
09/08/09 16:46:52
Ruby/Tkさえコンパイルできるようになれば、すぐにmingw版に移るんだが
755:デフォルトの名無しさん
09/08/09 17:00:11
>>754
普通にできてるが
756:754
09/08/09 17:12:14
>>755
え、本当？
俺の環境では ruby-list:46093 と同じ問題でコンパイルできない・・・
何が問題なのかさっぱりだ
配布バイナリがあればそっちを使うんだけど、更新止まってるみたいだし
757:デフォルトの名無しさん
09/08/09 17:31:30
>>753
GCの関係で、最適化かけすぎると
不味いんじゃなかったっけ？
758:デフォルトの名無しさん
09/08/09 17:52:37
ソースコード完全解説には「-O2まで」と載ってるな
URLﾘﾝｸ(i.loveruby.net) （「最適化のヒント」の項）
759:デフォルトの名無しさん
09/08/09 18:45:58
>>758
むしろ-O3より-O2の方がコンパイルに時間がかかったって話も聞くけどな
760:デフォルトの名無しさん
09/08/09 19:01:57
The Computer Language Benchmarks Game
URLﾘﾝｸ(shootout.alioth.debian.org)
761:デフォルトの名無しさん
09/08/09 19:57:53
>>758
いつの時代の本だよ
762:デフォルトの名無しさん
09/08/09 21:22:36
いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
Rubyもevalこそ入れ替わったけど、GCは基本同じだし。
763:デフォルトの名無しさん
09/08/09 22:10:26
RHG1.9版出せよ
764:デフォルトの名無しさん
09/08/09 22:18:27
OneClickRubyInstaller の次期バージョンになる予定のRubyInstallerは、
mingw版です。ダウンロードできるけど、まだプレビュー版です。
URLﾘﾝｸ(rubyinstaller.org)
みんなでテストして、安定すれば問題解決じゃない？
1.8系はmingwにするだけで倍以上早くなるみたいだし。
URLﾘﾝｸ(antoniocangiano.com)
765:755
09/08/10 00:15:17
>>756
俺もstubはダメだったんで非stubで使ってる。
Tcl/Tk 8.5 以降できなくなったような気がする。
ちなみにActiveTcljは使ったこと無い。いつもソースからビルドしてる。
766:デフォルトの名無しさん
09/08/10 03:28:30
>>762
> いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
ソースだせソース
767:デフォルトの名無しさん
09/08/10 07:13:49
最近は-O3でも動くらしい（ソースはIRCでの中田さんの発言
768:デフォルトの名無しさん
09/08/10 08:37:56
もう1年以上-O3のRuby(MinGWとlinux)使ってるけど
特に問題になったことはないなあ
769:デフォルトの名無しさん
09/08/10 20:17:04
少なくとも写真はこっちが勝ちだな
「変わっていかなければ」。日本Rubyの会 会長の葛藤 － ＠IT自分戦略研究所
URLﾘﾝｸ(jibun.atmarkit.co.jp)
770:デフォルトの名無しさん
09/08/10 20:23:33
世界にはばたく日本のRuby（笑）から（笑）を取ってもいい頃合の状況なのに、
実際の中の人の活動は状況に比べて芳しくないんだよね
771:デフォルトの名無しさん
09/08/10 20:50:57
Javaの解説やドキュメントを書くのは楽しい
なぜなら、足りない部分を補填するという自覚がもてるからだ
Rubyの解説やドキュメントを書くのは楽しくない
なぜなら、余計なものを重複して書いてる気分になるからだ
Rubyのスクリプトコードがもうちょっと読みにくかったら
ドキュメンテーションへのインセンティブになると思う
772:デフォルトの名無しさん
09/08/10 23:57:13
> Javaの解説やドキュメントを書くのは楽しい
奇特な性癖の持ち主発見
773:デフォルトの名無しさん
09/08/11 01:02:30
内容から察するに、わざわざツッコミ入れなくてもそういう意味だと思うぞ
「Rubyに比べてJavaのコードは解りにくいから、むしろドキュメント書くのが楽しくなる」という内容のようだから
774:デフォルトの名無しさん
09/08/11 01:22:03
実際にはJavaでもろくに書いてないんだろうけどな
775:デフォルトの名無しさん
09/08/11 01:25:32
分かりきったことをあらためて書くことほどつまらないことはないので
気持ちはわからなくもない
776:デフォルトの名無しさん
09/08/11 01:29:55
成程>>769での懸念も尤もだな
よっぽどJavaの4文字に負い目があるらしい
777:デフォルトの名無しさん
09/08/11 08:39:14
メッセージ伝達手段としての例外って使わないほうがいい？
1.9ではそもそも遅いとか聞くし
778:デフォルトの名無しさん
09/08/11 09:43:54
>>777
例外は例外なんだから例外的なことが起きた時にだけ使うべきだろう。
779:デフォルトの名無しさん
09/08/11 10:00:13
>>778
正論
大域脱出だったら catch と throw でいいんじゃないの？
780:デフォルトの名無しさん
09/08/11 11:10:02
Rubyでのthrow-catchはbegin-raiseとどう使い分けるの？
ふつうに例外処理があるのになんでcatch-throwがあるの？
初心者の素朴な疑問。
781:デフォルトの名無しさん
09/08/11 11:22:56
>>780
779が書いたように、throw～catchは大域脱出機構。
例外処理機構じゃない。
782:デフォルトの名無しさん
09/08/11 11:36:29
>>777
基本的には使うべきでない
ただしメッセージの種類によっては、判定が微妙なこともある
例：net/http.rb や open-uri.rb のHTTP例外
783:デフォルトの名無しさん
09/08/11 11:41:53
elseでのreturnは例外送出と根源的には同質
キャッチするかそのままにするかの違いでしかない
784:デフォルトの名無しさん
09/08/11 12:31:49
>>779
ライブラリが「このメソッドを呼ぶ時はcatchで括ってください」とか言ってきたらイヤだぞｗ
785:デフォルトの名無しさん
09/08/11 12:38:26
PStore#transactionとか
786:デフォルトの名無しさん
09/08/11 12:50:53
>>785
コード見て理解できた、指摘thx
787:デフォルトの名無しさん
09/08/11 15:05:47
>>785
理解できないので解説おねがい
788:デフォルトの名無しさん
09/08/11 15:07:48
>>784
検索メソッドを中断したらabort投げられるなんてのもないでもない
789:デフォルトの名無しさん
09/08/11 15:08:03
PStoreというクラスのインスタンスメソッドtransactionという意味
790:デフォルトの名無しさん
09/08/11 15:32:35
python の __getattr__ (属性へのアクセスのフック)のような事を ruby で行いたいのだがどうやれば良い？
method_missing ならぬ attr_missing みたいなメソッドがあれば良いんだけど発見できなかった。
791:デフォルトの名無しさん
09/08/11 15:49:05
できません
「インスタンス変数へのアクセスは全員アクセサメソッド使え」
とマニュアルにでっかい字で書いておくというのはどう
792:デフォルトの名無しさん
09/08/11 16:31:01
>>791
ｔｈｘ。
俺が見つけられなかっただけで、rubyでも絶対出来る方法があるだろーと思っていただけに意外でした。
793:デフォルトの名無しさん
09/08/11 18:24:41
>>789
だれもそんなこときいてねー！！
例外やcatch-throwの話しているときになぜ
>PStore#transactionとか
がでてきたのか（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど。
これが空気読めない理系どものコミュニケーション能力か！
794:デフォルトの名無しさん
09/08/11 18:32:49
>>793
そういう君こそ >>789 が言外に込めた意味を汲み取るべきでは？
ちなみに件のコードは見た？
795:デフォルトの名無しさん
09/08/11 19:35:00
＞（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど
見てたらこんなこと言わないか、一年ROMれのレベル
796:デフォルトの名無しさん
09/08/11 20:26:54
そうか、コールバック（イベント）メソッドという手もあったな
797:デフォルトの名無しさん
09/08/11 23:46:42
RubyやPythonの例外の使われ方を考えると
例外を例外的な状況だけで使えというのは
Java独自の風習じゃないかと思えてくる。
798:デフォルトの名無しさん
09/08/11 23:51:55
ジャヴァの例外周りの仕様は明らかにウンコ
C++の<< >>なIO stream並にフォロワーが出てこない
799:デフォルトの名無しさん
09/08/12 00:24:07
C++の例外はうんこ以前に普通に使えないという代物だからなあ
うんこはまだ食べられるだけマシだろ
800:デフォルトの名無しさん
09/08/12 04:42:59
それは例外ではなくただのエラーだと突っ込みたくなることが何度か
801:デフォルトの名無しさん
09/08/12 07:07:10
例外という日本語に引っ張られてるっぽい人は時々見る
802:デフォルトの名無しさん
09/08/12 07:20:25
>>792
trace的なものはあった気がするがすさまじく遅いから常用不可だった記憶
803:デフォルトの名無しさん
09/08/12 09:30:11
>>801
exception だとニュアンスがちがうのか？
804:デフォルトの名無しさん
09/08/12 09:38:30
「予期しないこと」ぐらいのニュアンスかな
805:デフォルトの名無しさん
09/08/12 09:41:00
よく知らんのだが、Lispのコンディションはもうちょっと積極的に
制御に組み込まれるんだろうか
806:デフォルトの名無しさん
09/08/12 09:45:43
>>801
例外なんて相対的なものだからね
ある人の例外は別の人にとって例外でなかったりする
807:デフォルトの名無しさん
09/08/12 09:58:03
OCamlの例外は積極的に制御機構として使われているね。
ループをbreakするときも例外とか。
よく知らんけど。
808:デフォルトの名無しさん
09/08/12 10:17:12
そもそもRubyの例外クラスには
StandardErrorなんてのが普通にあるんだし
それを考えても、エラーと例外をはっきり分ける意味はないと思う
809:デフォルトの名無しさん
09/08/12 10:36:09
例外って、実行時エラーに捕捉機能が備わっただけのような気もするな。
810:デフォルトの名無しさん
09/08/12 11:03:01
丸投げ機構
811:デフォルトの名無しさん
09/08/12 11:38:01
本スレに関係ない話題の隔離機構
812:デフォルトの名無しさん
09/08/12 13:01:02
むしろ本スレが隔離機構
813:デフォルトの名無しさん
09/08/12 13:13:33
隔離機構と薄力粉って似てるよね
814:デフォルトの名無しさん
09/08/12 13:20:53
隔離機構とカクリコンって似てるよね
815:デフォルトの名無しさん
09/08/12 13:24:16
∴ 薄力粉とカクリコンって似てるよね
816:デフォルトの名無しさん
09/08/12 13:39:36
>>790
method_missing 使え
Rubyはメソッドとか属性とかプロパティとか区別しない。
817:デフォルトの名無しさん
09/08/12 13:45:07
>>816
てゆか「メソッドしかない」んだけどね、厳密には
818:デフォルトの名無しさん
09/08/12 15:16:10
なんでこういう布教スレばっかり立てるん？
魁け！ Ruby 1.9.X
ｽﾚﾘﾝｸ(tech板)
819:デフォルトの名無しさん
09/08/12 16:17:53
>>818
何で今さら？
かなり前からあるぞそのスレw
820:デフォルトの名無しさん
09/08/12 21:09:26
MLの中にたこ焼き仮面がどうやらっていうメールがあって
何事かと思ったw
821:デフォルトの名無しさん
09/08/12 21:36:06
>>820
何で今さら？
かなり前からあれだぞそのカレw
822:デフォルトの名無しさん
09/08/12 21:56:32
>>821
そうだったのかw
ほとんどタイトルしか見ないからな
823:デフォルトの名無しさん
09/08/13 09:55:38
WEBrickのパースユーティリティって特定条件のパース遣り残しとか残ってる？
信用して丸投げしていい？
824:デフォルトの名無しさん
09/08/13 11:35:32
全く同じようなメソッドが大量に再発明されて氾濫してる現状からお察しください
825:デフォルトの名無しさん
09/08/13 11:51:36
やっぱり HTML とか HTTP とかの軽量クラスは作るべきだっただろうか
require 'cgi' が重いから嫌われてるんだよね escapeHTML
826:デフォルトの名無しさん
09/08/13 11:58:06
>>823
1.9でマルチバイト通さなかったことを誰も気づかなかった時点でお葬式
827:デフォルトの名無しさん
09/08/13 12:06:59
あのへんは、コードを読み解こうとしてRFCとか参照しようとするとわかるが、そもそも頭に入らないぞ
仕様読んでる時点で脳内スタックが溢れるという体験を久しぶりにした
「…このままでいいや」と呟いた俺
828:デフォルトの名無しさん
09/08/13 12:14:41
Railsさんはどうしてるのかなあ
どっかのライブラリに仕様を加味しつつ現実的な動作のメソッドがごそっと入ってそうだが
829:デフォルトの名無しさん
09/08/13 12:23:40
>>828
h と u については有名
ERB::Util の中に入ってる
irb> require 'erb'
irb> include ERB::Util
irb> p h('<html>')
"<html>"
irb> p u('ABCDE!,.[]123')
"ABCDE%21%2C.%5B%5D123"
フォームのエスケープとか URL のコンパクションとかやってくれるとこはまだ知らない
830:デフォルトの名無しさん
09/08/13 16:07:00
あまりにカオスだからいっそStringのメソッドに入れてしまおうか、
という話がでたくらい
831:デフォルトの名無しさん
09/08/13 16:27:39
>>830
Web特化のPHPならあり得る選択だろうけど、Rubyでやると賛否の否の方が圧倒的だろうな
なによりPHPを馬鹿にできなくなるし
832:デフォルトの名無しさん
09/08/13 16:33:11
現実の問題を解決する道具としてプログラム言語があり、
現実として Ruby が Web でよく使われているのに。
833:デフォルトの名無しさん
09/08/13 16:35:47
>>825
HTMLをエスケープするだけのためにあんなでっかいライブラリ呼んでられん
834:デフォルトの名無しさん
09/08/13 16:38:55
今はrequire 'cgi/util' するのが正解かな
835:デフォルトの名無しさん
09/08/13 17:06:57
はいはいみなさい便所の落書きお疲れ様です。
ここでなされた議論なんて一切参考にしないし
むしろ採用しないような力が働くからそのつもりでお願いしますよ。
836:デフォルトの名無しさん
09/08/13 17:26:17
議論された場所なんか関係ないね
参考にしたけりゃするし、気に入らなければしない
もちろん場所によってS/N比は違うが
837:デフォルトの名無しさん
09/08/13 17:34:00
話してるのが気に入らないって書いてる人に対して特にコメントはない
838:デフォルトの名無しさん
09/08/13 18:59:47
>>835
そうならなかったことは歴史が証明してるけどなw
老害って自分たちが苦労して堪え忍んだ不条理を
若いのがこともなげにスルーすると滅茶苦茶ヒステリックにブチ切れるよねw
いい年したオッサンの風体で幼稚極まりないのって見苦しいことこの上ないというか。
839:デフォルトの名無しさん
09/08/13 21:21:24
さすが本スレという感じの流れですね
840:デフォルトの名無しさん
09/08/13 21:42:16
>>838
ま、そのへんは回り持ちだよ。君も後にそうなる。
歴史が証明してる。
841:デフォルトの名無しさん
09/08/14 00:32:24
XML のパーサーがまだ作られていない時、
完璧なパーサーを作ろうとすると、すごく大変だけど、
90% ぐらいを満たすパーサーならば、
楽チンで作れるという話を聞いた。
その 10 % のために、コード量がすごく増えて、
労力と時間を使うのは、もったいないなーと思った。
ライブラリーは、90% を満たせる軽量なものがいい。
だいたい、残りの 10% って使用頻度が少なかったりする。
842:デフォルトの名無しさん
09/08/14 00:42:55
でも、その10%に入ってる機能の1つが必須要件に入っていたりするんだよな
843:デフォルトの名無しさん
09/08/14 04:23:10
9割で良いから。
-> 9割の物をつくる
-> 事情を知らない人が来て出来ない1割に文句を言う。
-> メンテする気がなくなる
-> 放置ライブラリができる
-> 新しいライブラリを作ろう。9割で良いから。
844:デフォルトの名無しさん
09/08/14 04:47:07
っていうか今のRubyの添付ライブラリは9割まではできてる
残り1割というが、1割というのはかなり大きい
「普通に使っていれば絶対に引っかかる」のが1割
845:デフォルトの名無しさん
09/08/14 04:52:51
使用状況を100個集めて、90個くらいまで対応して「だいたい9割できました」と言ってしまうような誤りが多い
実際に起こりうるポピュラーな使用事例は300個くらい存在するにもかかわらず、
一番最初の事例採取が間違っていたがために、実際稼動すると充足率は3割未満だ
添付ライブラリは仕様先行のほうがいいと思う
846:デフォルトの名無しさん
09/08/14 05:10:11
思ったより Ruby が急速広範に使われてしまい、
さくっとライブラリ直そうにも影響範囲がでかくなりすぎて互換性に縛られてどうにもならん
というのが現状のような気がする
Net::HTTP みたいな直し方すら、1.8.6 が広まった今ではもう危なっかしくてできん
1.6 時代ならまだがりごり直せた気がするんだが
847:デフォルトの名無しさん
09/08/14 05:21:12
いっそのこと Ruby++ とか別の言語にしてしまった方がいいのかね
848:デフォルトの名無しさん
09/08/14 05:27:57
本体添付ライブラリ は難しくても、gem なら大幅に変わっても見逃してもらえる
gem で事実上の標準ライブラリを作って本体にぶち込むんだ
849:デフォルトの名無しさん
09/08/14 06:08:08
>>848
それしかないだろうな
現状でも「アレをやる場合は添付ライブラリ駆使ではなくgemの○○が定番」というのが分野によってはあるわけだし
850:デフォルトの名無しさん
09/08/14 06:42:22
ねー
たとえばクローラ作ってたとして、HTTPS 対応みたいな、
受け取った URL によってはそもそも絶対使わないようなライブラリがけっこうある場合、
require 'net/https' if uri.scheme == 'https'
というように、メソッドの途中で条件分岐で require させるのって下品？
851:デフォルトの名無しさん
09/08/14 07:01:49
下品かといえばやっぱ下品だと思うよ
「必要なときに必要なものだけrequire」と書くと、字面はとってもエレガントなんだけどね
RMagick みたいなよっぽど重いやつでない限り、用はなくても最初に全部読むのが基本
852:デフォルトの名無しさん
09/08/14 07:01:50
Rubyは標準添付ライブラリレベルではメジャーバージョンアップごとに結構変わってる。
例えばcsvとかは1.9でFasterCSVへの入れ替えが行われてるし、test/unitもmini/testになってる。
結局不満があるのに変わらない系のライブラリは、責任持って変えようって言う人がいないだけ。
互換性は、別の名前で入れて時間をかけて置き換えっていう手もあるし、どうとでもなる
853:デフォルトの名無しさん
09/08/14 07:11:20
>>850
open-uriは正にそーゆー事をやってるね (ftp|http)
あれを下品だと思うなら下品と言ってもいいのかな
854:デフォルトの名無しさん
09/08/14 07:17:41
caseで書けそうなくらい条件と場所がまとまってて、自分以外のライブラリを呼んでるなら許すと思う
あちこちで細かく自分の下のファイルをrequireするのはやめてほしい気分
855:デフォルトの名無しさん
09/08/14 11:25:07
>>850
autoload使えば、と思ったが、
Net::HTTPSとかがあるわけじゃないのか。
856:デフォルトの名無しさん
09/08/14 20:04:46
net/httpsの中身をnet/httpに移して空にし、net/http側でautoload'openssl'したらどうだろう
857:デフォルトの名無しさん
09/08/16 02:50:52
コミケ2日目の帰路で
・RubyKaigi2009のシャツ
・NetBSDの携帯ストラップ
なんて風体の髭の人を見たんだが、
名のある開発者かなんかだったんだろうか
858:デフォルトの名無しさん
09/08/16 03:16:54
@takano32 ?
859:デフォルトの名無しさん
09/08/16 11:52:53
Rubyﾀｿの萌え萌えRuby入門でも描いて布教しろ
860:デフォルトの名無しさん
09/08/17 16:04:19
githubでフォークしたものが手元にあるんだよ
んで、手当たり次第魔改…気になっていた点を節度を持って改良したんだ
変えた点を細かく記録したコミットが30個くらい入ってるブランチになったんだ
最終的な新機能はお互いに関連する2つなんだけど、
ちょっと大掛かりだったもんで全部記録したんよ
これそのまま公開したらうざいよね？
861:デフォルトの名無しさん
09/08/17 16:08:54
興味持った香具師は粛々とpullするだろうからいいんじゃね？
862:デフォルトの名無しさん
09/08/17 16:14:47
>>860
公開するブランチはcherry-pickとスカーッシュで体裁整えるのが礼儀だろ
時々typo修正とかrevertとかマージの痕跡とか入ったままのがあるけどああいうの問題外
公開してしまったものをコミットで修正するのは仕方ないけど、公開前ならローカルで整頓
863:デフォルトの名無しさん
09/08/17 16:24:17
そのへんよくわかんないよね
commitの粒度とか
Ruby関係ないけどな
864:デフォルトの名無しさん
09/08/17 16:32:47
あー、rubygemのライブラリいじるときってさ、
ファイル追加したらManifest.txtやgemspecにも記述を追加するべきだよね？
コミットごとにCHANGELOGにコミットログをコピペするんだよね？
865:デフォルトの名無しさん
09/08/17 16:43:12
公開されているコミットは
「それだけを取り出して適用して（なおかつ衝突部分だけをなんとかすれば）なんとかなるようになっている一塊」
だから、やっぱ Manifest には書いたほうがいいんでないの
変更が必要になる場所はとにかく最低限衝突させて明示するほうがよさそうだ
rubygems ライブラリにとっての「コンパイル成功」は gem パッケージ生成だろうから
それが失敗する状態で特定のコミットが公開されているというのは片手落ちだと思う
866:デフォルトの名無しさん
09/08/17 16:51:26
commit 前に rake しろとな
867:デフォルトの名無しさん
09/08/17 17:58:46
学生が開発したコードがRubyの本体に
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
何がどう変わるのか、知ってる人教えて。
集まった学生は天才プログラマーですか？
868:デフォルトの名無しさん
09/08/17 18:06:48
Rubyがどんどんカオス化してってるな・・・
やっぱPythonにしておけばよかった・・・
869:デフォルトの名無しさん
09/08/17 18:35:54
>>868
確かに伽藍型開発であるPythonでは想像だにできない愚行だよな。
学生がソースに触れるなんておこがましいにも程がある
870:デフォルトの名無しさん
09/08/17 18:39:58
>>867
サッサーをmatzかと思っちゃった。
871:デフォルトの名無しさん
09/08/17 18:40:15
>>867
これすごいなｗ
裾野が広がって優秀なやつがバンバン育ってるんだろうな
おれは彼らの作るプログラムを利用させてもらうしかないわ
872:デフォルトの名無しさん
09/08/17 18:41:27
中学生とかもうね涙でそう
873:デフォルトの名無しさん
09/08/17 19:35:07
まあ年寄りは年の功で精査検査でがっつりツッコめばいいんだよ
それで全体のバランスが取れてうまくいくようになってる
稀～に経年知識ゼロでもセンスで綱渡りして渡り切れる若い人もいるがぬ
874:デフォルトの名無しさん
09/08/17 19:49:11
>>867
これほんとにその学生が自分で見つけてデバッグしてコード修正したの？
なんかこのセキュリティなんちゃらに箔をつけるために思えるんだけど
875:デフォルトの名無しさん
09/08/17 20:00:19
> その成果が冒頭で紹介したRuby本体の改良などである。
>開発されたコードは，ベンチマークによってはRubyの性能を約5倍向上させるもの。
>すでに笹田氏の手により，8月15日付けでRuby本体に取り込まれている
すげぇ！この前の５０倍と合わせて最大250倍も高速に！
876:デフォルトの名無しさん
09/08/17 20:02:20
「ベンチマークによっては」だけど、
通常利用でも顕著に高速化の恩恵が受けられるような改良であればいいな
おじさんは隅っこの方で君たちのお世話になりますよ
877:デフォルトの名無しさん
09/08/17 21:52:15
なんか胡散臭い記事だなw
878:デフォルトの名無しさん
09/08/17 21:54:02
おまいらの嫉妬なさけなすぎ
せめて未来ある若者の足をひっぱるなよ
879:デフォルトの名無しさん
09/08/17 21:57:20
いやそりゃある程度持ち上げてはいるだろ
凄い感じの人がいますが未来は不定だから何も凄くないんですヨ、みたいな記事に価値はねえw
それっぽく希望を膨らませる前向き記事にしてこそプロ
880:デフォルトの名無しさん
09/08/17 22:00:08
はてなとかこんなことやってないで
もっとましな有料オプション付けろよ
881:デフォルトの名無しさん
09/08/17 22:04:56
誰か試してみて速くなってた？
882:デフォルトの名無しさん
09/08/17 22:44:17
厨房の頃からrubyみたいな高級言語さわれて羨ましいな。
わしが厨房の頃はZ80アセンブリしか選択肢がなかったもんじゃ。
883:デフォルトの名無しさん
09/08/17 22:46:17
消防の頃からBasicみたいな高級言語さわってた
おいらが通るよ
884:デフォルトの名無しさん
09/08/17 22:48:10
この贅沢もんが！
というおいらは消防の授業でLOGOだったお。
885:デフォルトの名無しさん
09/08/17 22:49:54
考えることが少ない方がいいかもしれない
886:デフォルトの名無しさん
09/08/17 22:53:31
考え過ぎると禿げるしね
887:デフォルトの名無しさん
09/08/17 22:56:11
ストラウストラップが禿げてるのはそのせいか
あんな言語だもんな・・
888:デフォルトの名無しさん
09/08/17 22:59:06
考えすぎると禿げる、が真だとしても、
禿げてる人はよく考えてる、は必ずしも真ではない
何が言いたいかというと、うちの会社の禿げを何とかして欲しいと
889:デフォルトの名無しさん
09/08/17 23:00:05
つまんないよ
890:デフォルトの名無しさん
09/08/17 23:23:37
5倍速くなってV8と同等くらいになるのか
891:デフォルトの名無しさん
09/08/18 02:26:08
むしろアセンブラで組めたほうが将来は有望だろう。
rubyは数十年後には消えてる鴨だし。
892:デフォルトの名無しさん
09/08/18 06:47:06
>>858
なんとも。
とりあえずサンダル履きだったのでサークル参加だったのはほぼ間違いないかと。
893:デフォルトの名無しさん
09/08/18 07:00:51
一般参加者はスプリンターシューズを履いてるからな
894:デフォルトの名無しさん
09/08/18 10:49:19
URLﾘﾝｸ(www.infoq.com)
VC6捨てようぜ
あとライブラリ作成者はmingw32をWindowsとして扱えバカ
という話らしい
895:デフォルトの名無しさん
09/08/18 13:51:08
ついに公式ビルド元としてすら期待されなくなったか
とはいえこっちのが健全な流れだよなあ
896:デフォルトの名無しさん
09/08/18 13:54:14
できる人がリプレースというのは正しい
メンテナンス上の問題でVC6だったんだから、メンテナンス上の問題が解消できるならVC6でなくてもよい
897:デフォルトの名無しさん
09/08/18 15:51:51
>>895
> ついに公式ビルド元としてすら期待されなくなったか
なにが?
公式には
・「ruby-installer」はruby本体とは独立したプロジェクト
・「公式ビルド元」というものが存在したことはない
という答えになると思う。
898:デフォルトの名無しさん
09/08/18 17:38:59
うさビルドは9xサポートのためにVC6を使っている。
9xを切れるならばVC6以外を使った方がよい。
899:デフォルトの名無しさん
09/08/18 17:47:02
jperlみたいに残すのもありかなとも思う
古いシステム用のRuby
900:デフォルトの名無しさん
09/08/18 18:20:04
そろそろbccとかtccとかの（今となっては）マイナーなコンパイラを
切り捨ててもいいかも、ってもう切り捨てたんだっけ?
901:デフォルトの名無しさん
09/08/18 20:11:00
>>898
9xのためじゃないよ
バイナリ配布されている外部ライブラリのほとんどがmsvcrt.dllとリンクしているから
902:デフォルトの名無しさん
09/08/19 02:59:01
>>901
この辺の話かな
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.artonx.org)
903:デフォルトの名無しさん
09/08/19 03:08:28
URLﾘﾝｸ(www.artonx.org)
の6ページ目あたりでもそんなことを話していたんだと予想
904:デフォルトの名無しさん
09/08/19 18:04:41
>>901
逆でバイナリ配布されている外部ライブラリのほとんどは
usaビルドにあわせて泣く泣くmsvcrt.dllとリンクするようにしているんじゃね。
>>894のがデファクトになればみんなあっさり移行するよ。
905:デフォルトの名無しさん
09/08/19 18:58:45
>>904
何もわかってない奴だなあ。
「外部ライブラリ」ってのはこの場合Rubyの拡張ライブラリじゃなくて、
例えばOpenSSLとかGDBMとかそのもののことだよ。
それからね、mingw版もmsvcrt.dllにリンクするんだよ。
拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。
906:デフォルトの名無しさん
09/08/19 19:06:57
なんでVC6なんだ
2008とか使えねーの？
907:デフォルトの名無しさん
09/08/19 19:45:55
ビルド環境変えるのが面倒だから。に30カラット。
908:デフォルトの名無しさん
09/08/19 20:31:28
唐揚げ食べたいけど食べすぎると死ぬよね
909:デフォルトの名無しさん
09/08/19 21:06:27
>>906,907
この話を最初から全部読み直せ。リンク先も辿って。
VC6以降の全てのVCはそれぞれランタイムDLLがファイル名から異なる。
Ruby本体、拡張ライブラリ、拡張ライブラリが呼び出す外部ライブラリDLL、
が全て共通のランタイムDLLにリンクされていない限り、全体としてのRubyが
正常に動作することは保証されない（たいていはクラッシュする）。
910:デフォルトの名無しさん
09/08/20 01:06:38
python2.5ってmsvcr71.dllとリンクしてんだよね。
OpenSSLとかってどうしてんだ？
自前でビルドしてんのかな。
911:デフォルトの名無しさん
09/08/20 07:45:26
>>905
>mingw版もmsvcrt.dllにリンクする
それはみんなわかってて、だからこそ
mingw版が解法だっていってるんでしょ?
・新しいVisualC++はmsvcrt.dllをリンクしてビルドしてくれない
・mingwのgccは最新でもmsvcrt.dllをリンクできる
って話で。
だからこそ、
>拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。
だし、それゆえ移行コストが低いからmingwにしようって話になるわけで。
912:デフォルトの名無しさん
09/08/20 08:40:12
そういえば>>894でreadlineをpure rubyなものに差し替えようとしてるのってなんでだろ
GNU Readlineがらみでなんか問題があるんだっけ
913:デフォルトの名無しさん
09/08/20 08:44:46
readlineといえばWindowsで端末の画面サイズをirbに
（というかreadlineに）教えるにはどうすればいいんだろ
cmd.exeの画面サイズを30x120とかにしてると
補完とか改行周りが悲しいことになってかなわん
914:デフォルトの名無しさん
09/08/20 08:57:31
テラ自己解決しました
URLﾘﾝｸ(d.hatena.ne.jp)
915:デフォルトの名無しさん
09/08/20 09:03:01
>>912
readlineはGPLだから、組み込んだ時点でRubyライセンスが不可になってGPL一択になってしまうこと
Gauche の gosh （irb 相当）が Readline をサポートしないのも同じような理由だと思った
916:デフォルトの名無しさん
09/08/20 11:54:47
>>914
考えようによっては修正がupstreamに取り込まれないまま
数年経っちゃってるともとれるなあ
だれか拡張ライブラリ直す形のコードにしてパッチ投げない?
それかmputたんのgithubにpull requestしたほうがいいのか?
917:デフォルトの名無しさん
09/08/20 12:52:23
_whyが行方不明らしいな。
918:デフォルトの名無しさん
09/08/20 13:33:47
最近、どこかのスレで同じ話題を見た気がするけど
mingw環境でtcltklib.so（stub有効）がコンパイルできない……
解決法を知ってる人がいれば教えてほしい
環境：
ruby 1.8.7-p174, ActiveTcl 8.5.7.0
stub無効ならコンパイルできる