[#20453] thread in loop — Yoshiki Wada <wada@...>
和田と申します。
[#20473] Comparison with Other Languages — Hideto ISHIBASHI <s34204@...>
石橋秀仁です。
まつもと ゆきひろです
石橋秀仁です。
From: Hideto ISHIBASHI <s34204@vip.cis.kurume-nct.ac.jp>
[#20475] Wrapping Regexp in C++/Windows — OZAWA Sakuro <crouton@...>
さくです。
まつもと ゆきひろです
In article <E12GWVc-0004Rq-00@ev.netlab.co.jp>,
なかだです。
まつもと ゆきひろです
[#20505] Array のサブクラス — ogino@...
荻野です。Array や Hash のサブクラスの挙動がどうもよくわかりませんので
[#20523] regexp ML — Tomoyuki Kosimizu <greentea@...2.so-net.ne.jp>
越水です。
[#20525] lib/subdirectory — gotoken@... (GOTO Kentaro)
ごとけんです
[#20526] site_ruby — gotoken@... (GOTO Kentaro)
ごとけんです
[#20534] ftpmirror-1.2.2 で @homepage へ up 不可 — Hirokazu Kiuchi <kiuchi@...>
はじめまして、きうちです。
黒田です。
素早い回答ありがとうござます、きうちです
黒田です。
きうちです
[#20554] エスケープされていないものだけを置換 — Ayanosuke <aya@...>
館林と申します。
たけうちです。
ごとけんです
なひです.
館林です。
[#20598] — "okaukio+mls" <jtz4046@...6.mnx.ne.jp>
ruby-list@netlab.co.jp のみなさん こんにちは。
片岡と申します。
おかゆきおです。
助田です.最初からこのツリーちゃんと読んでなかったんですが...
おかゆきおです。
助田です.ちょっと長いです.
おかゆきおです。
わたなべです.
おかゆきおです。
In article <38A6419D15E.469A.BXQ04723@nifty.ne.jp>,
In <200002130938.SAA17120@rose.duelists.org>,
In article <200002131054.TAA09555@mail.fb3.so-net.ne.jp>,
なかだです。
有馬です。
たかた@久しぶりの投稿です。
たかたです
たかたです
たかたです
From: "Hideaki Takata" <hideakit@d3.dion.ne.jp>
なひです.
なひです.
なひです.
From: "NAKAMURA, Hiroshi" <nakahiro@sarion.co.jp>
有馬です。
なかだです。
わたなべです.
[#20608] media watch 2000.02.08 — Noritsugu Nakamura <nnakamur@...>
[#20625] druby で 3 つのプロセス間でオブジェクトをやり取りする — 堀川 久 <vzw00011@...>
こんにちは。
こんにちは。
Masatoshi SEKI <m_seki@mva.biglobe.ne.jp> wrote:
[#20675] 括弧省略の問題? — NISHIKAWA <nyasu@...3web.ne.jp>
こんばんは。にゃす@3webです。
[#20701] call Process::waitpid with -1 — Tomoyuki Kosimizu <greentea@...2.so-net.ne.jp>
越水です。
まつもと ゆきひろです
[#20720] ruby 本の mtalkd マルチスレッド版について — Nobutaka Terauchi <europa@...>
はじめまして、寺内 信尊といいます。
[#20722] opttest.rb of optparse-0.6 — Toshiro Kuwabara <toshirok@...3.so-net.ne.jp>
Toshです。
なかだです。
Toshです。
なかだです。
Toshです。
なかだです。
Toshです。
なかだです。
[#20723] 正規表現について — Takayuki Tanaka <tanaka@...>
始めてメールさせていただきます。
[#20733] ANN: ActiveScriptRuby — "arton" <arton@...>
はじめまして。
[#20737] Ruby/Gtk の CList にパッチ — YASUI Kentarow <kenyasui@...>
安井です。
いがらしです。返答が遅くなりすみません。
まつもと ゆきひろです
やしです。
まつもと ゆきひろです
原です。
[#20766] cvsmailer — Daiji KANEMATSU <kanematu@...>
兼松と申します。
[#20771] CGI の改行 (Ruby + Apache on Windows) — ogino@...
たびたびすみません、荻野です。またひとつ分からない点が。
[#20774] 'scripting' / 'SUKURIPUTO' — TAKAHASHI Masayoshi <maki@...>
高橋征義です。
[#20821] method object — thitoshi@... (TAKAHASHI Hitoshi)
こんにちは。鈴木@仕事中です。
まつもと ゆきひろです
たかたです
新井です。
武井です。
まつもと ゆきひろです
ごとけんです
まつもと ゆきひろです
[#20848] media watch 2000.02.18 — Noritsugu Nakamura <nnakamur@...>
[#20865] ANN: ActiveScriptRuby Update — arton <arton@...>
artonです。
[#20887] 変数ウォッチ画面ありませんか? — Itou-T15@...
ひとつ相談ですが(伊藤です)
[#20918] Ruby 本入手法 — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#20923] CUI library available in Ruby — Hideto ISHIBASHI <s34204@...>
石橋秀仁です。
石橋秀仁です。
石橋秀仁です。
[#20932] [Q] array.each{|i,j|... — junji999@...
高橋と申します.
[#20944] Hash#update について — Fuyuhiko Maruyama (丸山冬彦) <fuyuhik8@...>
丸山@東工大と申します。
なかだです。
From: 中村暁史 Nakamura Akifumi <BXQ04723@nifty.ne.jp>
丸山です。
まつもと ゆきひろです
丸山です。
まつもと ゆきひろです
丸山です。
まつもと ゆきひろです
[#20959] Ruby/GTK tの動かし方 — 中村暁史 Nakamura Akifumi <BXQ04723@...>
こんにちわ、阿部です。
いがらしです。
わたなべです.
[#20965] cgi.rb BUG? — rubikitch <rubikitch@...>
るびきちです。
なかだです。
nobu.nakada@nifty.ne.jp wrote:
なかだです。
nobu.nakada@nifty.ne.jp wrote:
まつもと ゆきひろです
matz@netlab.co.jp (Yukihiro Matsumoto) wrote:
青山です。
まつもと ゆきひろです
なかだです。
[#20992] GPIB driver その後 — Makoto Tagusari <mtag@...2.so-net.ne.jp>
皆さん今晩は、田鎖です。
石橋秀仁です。
皆さん今晩は、田鎖です。
In message "[ruby-list:21083] Re: Critical Block (Re: GPIB driver その後)"
皆さん今晩は、田鎖です。
まつもと ゆきひろです
[#21024] patch - ext/socket/socket.c — GOTOU YUUZOU <gotoyuzo@...>
ごとうゆうぞうです。
[#21028] CGI.rb のドキュメント探してます — Takumi Nakamura <chapuni@...>
はじめまして。福岡在住の中村と申します。
こんにちは。
江田です。
こんにちは。
[#21042] REQ: String#to_a — Tomoyuki Kosimizu <greentea@...2.so-net.ne.jp>
越水です。
[#21073] Regexp question — Kengo Nakajima <ringo@...>
京都の中嶋です。
まつもと ゆきひろです
[#21093] RD with URL — rubikitch <rubikitch@...>
るびきちです。
なかだです。
From: nobu.nakada@nifty.ne.jp
なかだです。
From: nobu.nakada@nifty.ne.jp
Toshです。
From: Toshiro Kuwabara <toshirok@yb3.so-net.ne.jp>
Toshです。
新井です。
Toshです。
新井です。
Toshです。
新井です。
Toshです。
[ruby-list:20805] Re: opttest.rb of optparse-0.6
Toshです。
最初にちょっと余談(?)
OptionParserは引数のクラスを自動的に変換してくれるのがなかなか便利ですね。
特にacceptで変換の方法をユーザーが後から追加できるのに感動しました。(^^
In message "[ruby-list:20782] Re: opttest.rb of optparse-0.6"
on 00/02/17, nobu.nakada@nifty.ne.jp <nobu.nakada@nifty.ne.jp> writes:
>> > 変更点についてもっときちんと書いておくべきでした。0.6 と一緒に
>> >0.5.2 も出してますが、これは instance_eval 以外は同じです。
>> >0.5.2 メインの方が良かったでしょうか。
>> ># もし二本立にするなら 0.6 と 0.7 とかの方が良かった?
>>
>> 今後ともふたつのバージョンが両立するってことでしょうか?
>
> 異論があった以上、ひとまず 0.5.2 の流れは残しときます。というか
>予想して両方出したわけですが、そのうち統一したいです。
ファイル名が衝突してしまう以上2つのバージョンが同時に存在するのは
難しいんではないかと思いました。僕は0.6の仕様に納得しましたので、0.6
一本でも構いません。
>> 0.6.0a と0.6.0bってのはどうでしょう?
>
> うーん、それはでも RCS が許してくれない(笑)。今のところ3つ目は
>リリースのたびに、2つ目はインターフェースが変わったりとき(とかそ
>の場の気分とか)で上げるって方針でおおむね来てるんで、0.6.0.x と
>0.6.1.x にするよりは 0.6 と 0.7 になるかなって感じで。世間的(?)に
>も(Ruby とかと同じく)偶数/奇数バージョンでって説明しやすいですし。
僕はバージョン番号とか、いつも迷います。(^^;;
>> でも、ふたつバージョンがあると混乱するかも。
> そう、まず私が。(^^;
(^^;;
>> あ、0.6のOptionParser.newはブロック引数がつくのですね。
>> うう〜む。そうなるとカプセル化やローカル変数のスコープの点で
>> instance_evalよりはyieldの方がよいかもしれません。納得しました。
>
> ちょっとこういう用途には instance_eval は強力すぎて、ってとこで
>しょうか。なにより self が変わってしまうのが困ったちゃん。
>
> も一つ非互換性として OctalInteger のような定数が
>OptionParser:: を付けないといけなくなるってのがあるんですが。
>Integer::Octal とかも考えたものの、一ライブラリの分際であまり無関
>係なクラス、とくに組み込みクラスなどにいらん干渉をするのも憚られ
>るので(って ARGV 変えちゃってるじゃん。^^;)。
>
># その辺の定数の module を作って include してもらうって手もあるか。
ARGV 変えてるのは、正直ちょっと戸惑いました。「まぁ、ARGVの処理をする
のはフロントエンドの部分だけだろうからそれほど問題無いか」と言う感じに
今は納得してますけど。
>> ブロックを使う必然性。
>> ブロックを使うと初期化の作業を一箇所にまとめられるのがOO的に
>> (あるいはRuby的に)きれいかと思いました。
>
> たしかに当初そういう考えで new で指定できるようにしたんですが、
>後からもオプションを追加できるということに気づいて公式仕様とした
>時点で、形骸化したようです。
>
>> カスケーディングはそれほど必要を感じてないですが、
>
> そう思ってたんですが、こういうのこそカスケーディングが一番ハマ
>るように思えて来てます。
ううむ。個人的には「初期化の処理はすべて*new*にまとまってる」のが
つぼなので、
obj = OptionParser.new(str)
obj. { ... }
は意図とちょっと違うんですね。
obj = OptionParser.new(str).{ ... }
って続けて書けばいいのか。でも、これだとこの記法、ブロックと間違えやす
いかも。
obj = OptionParser.new(str) do! ... end
もやっぱちょっと紛らわしいですね。
>> obj. { ... }
>> よりか
>> obj do! ... end
>> とかのほうが個人的には好みかも。
>> # あまり記号二つつなげたくないらしい。
>
> bang method ならぬ bang keyword ですか? どうすればいいのかなぁ。
ただの思い付きですので。(^^;;
---
Tosh
Toshiro Kuwabara