[#43610] Re: [ruby-list:48149] Re: requireが配列を取れたら便利だと思うんだけど.. — Hiroshi Nakamura <nakahiro@...>
cnVieS1saXN0GyRCJCskaTt9JEMkRk1oJF4kNyQ/ISMkRyRiQjMkKyRKJD0kJiEjGyhCCgoyMDEx
松田です。
卜部です
[#43620] Module#mix — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#43634] [Ruby 1.9 - Bug #4835][Open] Compilation failure of ext/tk with recent ActiveTcl — Yuki Sonoda <yugui@...>
[#43643] DateTime.new! and DateTime.jd — Aaron Patterson <aaron.patterson@...>
こんにちは、アーロンです。
blocker はお前だろ。
まつもと ゆきひろです
> うーん、ただでさえ日英のコミュニケーション障壁があるのに、よ
2011/6/7 Tadayoshi Funaba <tadf@dotrb.org>:
皆さんってのに俺は入ってないみたいだな。
まつもと ゆきひろです
> Aaronが言ってる「リリース」は1.9.3のことだと思いますよ。
まつもと ゆきひろです
> Railsのリリースについては私は知りません。が、1.9.3のリリース
[#43645] Re: [ruby-core:36778] Re: 1.8.7 release next month — Urabe Shyouhei <shyouhei@...>
Moving to ruby-dev to understand strategies of backporting the Tk
永井@知能.九工大です.
卜部です。
永井@知能.九工大です.
[#43655] [Ruby 1.9 - Bug #4853][Assigned] ext/tk/extconf.rb fails on Mac OS X — Nobuyoshi Nakada <nobu@...>
[#43686] test.rb for make run — SASADA Koichi <ko1@...>
ささだです.
[#43700] [Ruby 1.9 - Bug #4866][Assigned] Macでmake checkするとIO.copy_streamでSEGV — Motohiro KOSAKI <kosaki.motohiro@...>
[#43710] Re: [ruby-changes:19939] kosaki:r31986 (trunk): * ext/tk/tcltklib.c (lib_eventloop_core): replace CHECK_INTS with — KOSAKI Motohiro <kosaki.motohiro@...>
永井さん
永井@知能.九工大です.
2011年6月12日0:00 Hidetoshi NAGAI <nagai@ai.kyutech.ac.jp>:
[#43716] [Ruby 1.9 - Bug #3137] complex.rb changes exceptions of Math — Koichi Sasada <redmine@...>
[#43717] [Ruby 1.9 - Bug #3456] bisarre comma — Koichi Sasada <redmine@...>
まつもと ゆきひろです
メールにじかに反応したまつもとさんは読んでないと思うのでコメント#5を再掲
まつもと ゆきひろです
卜部です。
[#43743] [Ruby 1.9 - Feature #4871][Open] envのコンパクト化 — Kazuki Tsujimoto <kazuki@...>
[#43779] Re: [ruby-cvs:38869] nobu:r31690 (trunk): * gc.c (vm_xcalloc): use calloc provided by platforms. — Yutaka Kanemoto <kinpoco@...>
こんにちは。
金本と申します。
>> AIXでは0 size mallocでNULLが返るのでこまったことになっています。
ささだです.
[#43787] [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Kenta Murata <muraken@...>
まつもと ゆきひろです
もう結論が出てしまったようですが、これは、元々 lib/complex.rb にあった
=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82
> complex.rb をロードすると Math が CMath 相当に置き換わりますから、
=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82
まつもと ゆきひろです
=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82
> これに相当する事をやっているのが complex.rb なので、
遠藤です。
> 定義域を増やすだけにしよう、ということですよね。賛成です。
2011年6月14日22:17 Tadayoshi Funaba <tadf@dotrb.org>:
> 互換性がないという点では同じ話だと思うのですが……。
2011年6月14日23:02 Tadayoshi Funaba <tadf@dotrb.org>:
> いやあ、5 月末の feature freeze 時点では -2 を返していたはずなんですが、
遠藤です。
[#43791] [Ruby 1.9 - Bug #4879][Open] test_new(OpenSSL::TestPKeyRSA) fails on Win32 — Akio Tajima <artonx@...>
[#43820] mysterious hang at busy loop after system() — Tanaka Akira <akr@...>
以下のようなプログラムが手元の環境のひとつでハングします。
[#43829] [Ruby 1.9 - Bug #4891][Open] Vector#normalize — Kenta Murata <muraken@...>
[#43852] [Ruby 1.9 - Bug #4909][Open] trapハンドラは再入されてはいけないのではないか? — Motohiro KOSAKI <kosaki.motohiro@...>
同意します。
[#43859] [Ruby 1.9 - Bug #4911][Open] timer_thread_function() が thead unsafe — Motohiro KOSAKI <kosaki.motohiro@...>
[#43861] Date/DateTimeの仕様について — "NARUSE, Yui" <naruse@...>
ふなばさん
[#43869] [Ruby 1.9 - Bug #4919][Open] OpenSSL::SSL::Sesssion#time= に Bignum を渡すと ArgumentError が発生する — Tomoyuki Chikanaga <nagachika00@...>
報告ありがとうございます。32bit環境で落ちるとか考えてませんでした。。。
[#43875] [Ruby 1.9 - Feature #4921][Assigned] Remove intern.h — Yui NARUSE <redmine@...>
[#43890] [Ruby 1.9 - Bug #4072] dRubyで作成したサーバプログラムがsleepしていてもexitしてしまう — Tomoyuki Chikanaga <nagachika00@...>
[#43902] [Ruby 1.9 - Bug #4926][Open] --gc-stress付きtest/ruby/enc/test_emoji.rbが失敗する — Kazuki Tsujimoto <kazuki@...>
[#44001] socket related errors on chkbuild — SASADA Koichi <ko1@...>
ささだです.
[ruby-dev:43998] Re: ThreadGroup#make_local_space!
永井@知能.九工大です. From: Urabe Shyouhei <shyouhei@ruby-lang.org> Subject: [ruby-dev:43995] Re: ThreadGroup#make_local_space! Date: Thu, 30 Jun 2011 09:43:16 +0900 Message-ID: <4E0BC69B.6080507@ruby-lang.org> > 提案なのですが、たしかに永井さんの提案のほとんどの部分には共感できません > が、いくつかの機能は別にあってもいいと思うものもあるので、機能毎に分けて > 再提案されてはどうでしょうか。All or nothingだとどうかんがえてもnothing > のほうにならざるをえません。 All or Nothing だとは考えていませんので,確かに明確に分けた方が望まし いですね.分け方としては, ・thread queue ・make_local_space! ・その他 というところでしょうか. > > あくまでも Ruby の上での話です. > > さすがにパラダイムとしてのスレッドプログラミングを > > どうこうしようなどとという大それたことは考えておりません. > > これまではできなかった,あるいは余計な手間やコストがかかっていた処理を > > 楽に書けるようになれば,利用の機会も増えるのではないかとは考えています. > > この趣旨には頷けるものがありますが、 > > > 強化案のメソッド群は,過去に thread を使っていろいろとやっているときに > > 「こういうのがあればもっと積極的に ThreadGroup を使うのに」 > > と考えたものが中心となっています (「ついでに」というものが複数含まれて > > いるのも事実ですが). > > そうした実例,具体例が不足しているという批判は, > > 少なくとも現時点で確かにそのとおりで,否定できせん. > > だいたい分かってきたのですけれども、「スレッドプログラミングを便利にす > る」から「ThreadGroupを便利にする」の間に理論の飛躍があるというふうに思 > います。べつにThreadGroupじゃなくてもスレッドプログラミングが便利になれ > ばいいでしょう? 「べつにThreadGroupじゃなくても」はその通りですね. 現在の Ruby において,thread 群の取りまとめ役として存在しているのは ThreadGroup ですから,ThreadGroup を土台に便利にすることを考えるのは 素直な流れと考えていましたが,それが飛躍でありもっと別の解を検討すべ きだとおっしゃるなら,確かに私の検討不足ということなのでしょう. それはそれとして,出来てほしいと思う (確かに「私が」ですが) が現状で はうまく書けないことを可能にする一案としての提示はしたつもりです. Module での実装や $SAFE の拡張でということであれば,具体的にどのよう な仕様でそれを達成するのかの案を示していただけると比較検討がやり易く て助かります. > > まぁ,Ruby の thread そのものが使われなくなるだろうということであれば, > > ThreadGroup の強化など無意味なこととなります. > > スレッドを積極的に使わなくしていこうとはあまり思っていませんが、 > Mutex#lockがmutexをロックしないまま起きてくるかもしれないというもっと根 > 本的な仕様上の問題がありますので、ThreadGroupに多少メソッドが増えよう > が、Rubyのスレッドが使い辛いことにはたいして影響を及ぼさないと思います。 これは Ruby の thread そのものの性質の話 (改善するしないも別次元の話) で,今,議論している内容との関係は薄いように思うのですが... > >> Moduleはそのためのものですからね。しかるに、Module#mixではなく、 > >> ThreadGroupに機能を追加する、なぜですか。なぜModuleではないのですか。 > > > > 実行単位である thread を固有環境の単位として考えているからです. > > 良い説明が出てこなくて悩んでいるのですが, > > Module への装備が言語環境のレベルで箱庭を用意するのに対し, > > ThreadGroup への装備は実行環境のレベルで箱庭を用意するとでも > > 言えばいいのでしょうか. > > うーん、良い説明が出てこないものはやはり良くないからではないかという疑問 > を提示せざるを得ませんね。 良い説明ではなくても,先の記述では伝わりませんか? まぁ,伝わらないからそのようにおっしゃっているのでしょうけど.(^_^; > ちょっとやりたいことが見えてきません。make_local_space!のサンプルコード > は機能の解説にはなっていましたが、何がどう便利なのかが分かりませんでし > た。実際にこの機能を使うアプリケーションコードをどう想定しておられるのか > を提示していただいたほうがいいように思います。 おっしゃる通りですね.考えます. > > 固有環境を持った thread が sub thread を生成して処理を行うとき, > > sub thread は親 thread と共通の環境を引き継ぐことを求める場合が多い > > のではないかと思います. > > sub thread を生成するたびに固有環境のコピーを作るのは無駄ですので, > > デフォルトで引き継がれる ThreadGroup が固有環境情報を持っているのが > > 効果的だろうという考えです. > > ?? 作ったスレッドが親の環境を見ることができるのは「当然」だと思うのです > が。なぜわざわざThreadGroupが出てくるのですか? あ,ごめんなさい.わかりづらかったですね. この部分は,「実行単位である thread を固有環境の単位として考えているか らです.」を受けて書いている部分です. thread を固有環境 (ローカル空間) の単位と考えるのであれば,単純には固 有環境の情報を個々の thread に持たさせるということになるでしょう.しか し現実には,親子で共通の固有環境を用いることがほとんどでしょうから別々 に持たさせるのは無駄が多い.ThreadGroup に情報を持っておいてもらえばい いのではないかという,固有環境 (ローカル空間) の情報の保持場所について の話です. -- 永井 秀利 (nagai@ai.kyutech.ac.jp) 九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教