[#43610] Re: [ruby-list:48149] Re: requireが配列を取れたら便利だと思うんだけど.. — Hiroshi Nakamura <nakahiro@...>

cnVieS1saXN0GyRCJCskaTt9JEMkRk1oJF4kNyQ/ISMkRyRiQjMkKyRKJD0kJiEjGyhCCgoyMDEx

12 messages 2011/06/02

[#43643] DateTime.new! and DateTime.jd — Aaron Patterson <aaron.patterson@...>

こんにちは、アーロンです。

25 messages 2011/06/07
[#43647] Re: DateTime.new! and DateTime.jd — Tadayoshi Funaba <tadf@...> 2011/06/07

blocker はお前だろ。

[#43648] Re: DateTime.new! and DateTime.jd — Yukihiro Matsumoto <matz@...> 2011/06/07

まつもと ゆきひろです

[#43651] Re: DateTime.new! and DateTime.jd — Tadayoshi Funaba <tadf@...> 2011/06/07

> うーん、ただでさえ日英のコミュニケーション障壁があるのに、よ

[#43653] Re: DateTime.new! and DateTime.jd — Aaron Patterson <aaron.patterson@...> 2011/06/07

2011/6/7 Tadayoshi Funaba <tadf@dotrb.org>:

[#43657] Re: DateTime.new! and DateTime.jd — Tadayoshi Funaba <tadf@...> 2011/06/07

皆さんってのに俺は入ってないみたいだな。

[#43661] Re: DateTime.new! and DateTime.jd — Yukihiro Matsumoto <matz@...> 2011/06/07

まつもと ゆきひろです

[#43662] Re: DateTime.new! and DateTime.jd — Tadayoshi Funaba <tadf@...> 2011/06/07

> Aaronが言ってる「リリース」は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

13 messages 2011/06/07

[#43787] [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Kenta Murata <muraken@...>

24 messages 2011/06/13
[#43788] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Yukihiro Matsumoto <matz@...> 2011/06/13

まつもと ゆきひろです

[#43789] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/13

もう結論が出てしまったようですが、これは、元々 lib/complex.rb にあった

[#43794] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Kenta Murata <muraken@...> 2011/06/13

=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82

[#43795] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/13

> complex.rb をロードすると Math が CMath 相当に置き換わりますから、

[#43797] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Kenta Murata <muraken@...> 2011/06/14

=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82

[#43799] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Yukihiro Matsumoto <matz@...> 2011/06/14

まつもと ゆきひろです

[#43800] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Kenta Murata <muraken@...> 2011/06/14

=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82

[#43803] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/14

> これに相当する事をやっているのが complex.rb なので、

[#43806] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Yusuke ENDOH <mame@...> 2011/06/14

遠藤です。

[#43807] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/14

> 定義域を増やすだけにしよう、ということですよね。賛成です。

[#43809] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Yusuke ENDOH <mame@...> 2011/06/14

2011年6月14日22:17 Tadayoshi Funaba <tadf@dotrb.org>:

[#43810] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/14

> 互換性がないという点では同じ話だと思うのですが……。

[#43811] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Yusuke ENDOH <mame@...> 2011/06/14

2011年6月14日23:02 Tadayoshi Funaba <tadf@dotrb.org>:

[#43812] Re: [Ruby 1.9 - Feature #4878][Open] CMath に frexp, ldexp, hypot の3関数は不要ではないか — Tadayoshi Funaba <tadf@...> 2011/06/14

> いやあ、5 月末の feature freeze 時点では -2 を返していたはずなんですが、

[#43852] [Ruby 1.9 - Bug #4909][Open] trapハンドラは再入されてはいけないのではないか? — Motohiro KOSAKI <kosaki.motohiro@...>

11 messages 2011/06/20

[ruby-dev:43998] Re: ThreadGroup#make_local_space!

From: Hidetoshi NAGAI <nagai@...>
Date: 2011-06-30 05:45:04 UTC
List: ruby-dev #43998
永井@知能.九工大です.

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)
九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教

In This Thread