[#3249] ruby for mswin32 — KIMURA Koichi <kkimura@...>
[#3257] mini-reference (syntax) — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
[#3305] Observable#notify_observers — shugo@... (maeda shugo)
前田です。
[#3312] multi-line comment — shugo@... (maeda shugo)
前田です。
[#3329] meta programming features — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろ%最終出社日です
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
[#3350] [Q] eql? and == — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
[#3375] Exception — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
[#3378] ML分割 — takagi@... (TAKAGI Hiromitsu)
ところで、話は変わって、ひとつ提案です。
[#3403] sorry for ruby-list trouble — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
[#3411] no cbreak in curses module — Shoichi OZAWA <ozawa@...>
こんにちは 小澤@日立 です。
[#3417] [Bug] String#sub — shugo@... (maeda shugo)
前田です。
[#3429] [Req] println — shugo@... (maeda shugo)
前田です。
まつもと ゆきひろです
[#3434] [Q] Thread — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
けいじゅ@今はフリー(^^;;;です.
まつもと ゆきひろです
前田です。
前田です。
前田です。
けいじゅ@今はフリー(^^;;;です.
<199707301029.TAA25172@hoyogw.netlab.co.jp> の、
けいじゅ@今はフリー(^^;;;です.
<199707311103.UAA08460@hoyogw.netlab.co.jp> の、
[#3470] [Problem] for local class — keiju@... (Keiju ISHITSUKA)
けいじゅ@今はフリー(^^;;です.
[#3502] Re: .to_f result — 渡辺博文 <VYV01212@...>
わたなべです.
[ruby-list:3455] Re: [Q] Thread
けいじゅ@今はフリー(^^;;;です. In [ruby-list :03444 ] the message: "[ruby-list:3444] Re: [Q] Thread ", on Jul/25 00:18(JST) matz@netlab.co.jp (Yukihiro Matsumoto) writes: >|1. 組み込みの関数/メソッドはatomicか? > >その保証はありません. そうなんですくぁ? そうすると, 同じ資源にアクセスする可能性のある操作は排他制御する必要が あるってことになるんですか? でも, 同じ資源といってもそのメソッドが何に アクセスするかあまり明確ではないんですが... 例えば, eval "class Foo; def foo..." と eval "class Foo; def bar..." は排他制御する必要があるない? さらに, eval "class Foo; def foo..." と f = Foo.new f.bar はどう? # きっと内部的には, 同じハッシュ表(メソッドテーブル)をアクセスしている # と思いますが... それと, atomicでないとしても, 落ちない保証ぐらいは期待して良いんでしょ うか? 例えば, * 同じHashに同時に書き込んでも問題ないとか... * stdoutに同時に書き込んでも問題ないとか... どうなんでしょう... >|2. ユーザレベルライブラリ(**.rb)のスレッド対応 >|a. 一切対応は行わなくてよい. それを使う側がMutexなどを使って対応する. >|b. メソッドレベルのatomic性は保証するようにする. >|c. さらに高レベルな保証を行う. >| >|やはり, bぐらいは対応した方が良いのでは? とは思うのですが... >thread awareが必要なライブラリもありますが(たとえばtk),基本 >的にはaだと思っています. なるほど, そんなもんですかねえ... ところで, なぜ tkはthead awareなんで しょう? __ .........................................石塚 圭樹@今はフリー(^^;;... ------->>また, アドレス変わりました!! e-mail: keiju@bc.mbn.or.jp <<---