[#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:43978] Re: ThreadGroup#make_local_space!

From: Hidetoshi NAGAI <nagai@...>
Date: 2011-06-28 06:15:07 UTC
List: ruby-dev #43978
永井@知能.九工大です.

From: Urabe Shyouhei <shyouhei@ruby-lang.org>
Subject: [ruby-dev:43920] Re: ThreadGroup#make_local_space! (Re: ThreadGroup の強化案)
Date: Sun, 26 Jun 2011 17:23:06 +0900
Message-ID: <4E06EC5F.1040908@ruby-lang.org>
> ひっじょうに根本的な質問をするのですけれども、ThreadGroupって何に使うん
> ですか。
> 
> 過去に若干の調査を行った結果、Threadを束にして操作したいという用途には
> real world examplesが少なすぎて、いまいちです。

基本的には束ねるものでしょうね.
これまでは機能が少なすぎて,sub thread が自動的に含まれることを除き,
thread を array に入れて管理するのとたいして変わらなかった,
それゆえ,わざわざ使う気にもならなかったというように思います.
ThreadGroup の機能強化により,ThreadGroup というものの活用の幅を広げ,
ひいては thread 活用プログラミングの幅も広げられないかというのが趣旨です.
「そうは見えない」というのであれば,それは私の力不足ということです.

例えば thread pool として使うにしても,
処理を queue で渡して pool のいずれかの thread を起こすというのでは
ThreadGroup のありがたみなどはありません.
監視する能力が弱いため,thread の状態変化に高い即応性を持たさせるためには
polling したり,対象 thread ごとに1個の専用監視 thread を用意したり
する必要があります.

ThreadGroup オブジェクトに持たせようとする thread_queue は,
thread 群の監視能力の強化を図るという意味合いがあります.
thread pool コントロールの主導権を監視側に移すことが可能となります.
例えば thread 群が処理能力差のある別マシンに処理依頼をする場合でも
各 thread が処理完了に要した時間を監視し易くなりますから,
スケジューリングもより緻密にできるかもしれません.

自分で thread_queue を作って似たことを実現することもできますが,
thread_queue への投入を ruby 本体の thread 管理に組み入れることで,
予期せぬ trouble で落ちた thread でも早くに低コストで拾えると思います.

>                                  元のメールにはsandboxと書
> いてありますけれども、少なくとも現状ではsandboxingは$SAFEが担っている分
> 野ですよね? 私も$SAFEの機能が完璧であるとは口が割けても言えませんが、だ
> からといって$SAFEでは実現できないようなsandboxing機構が必要なのだとした
> ら、まずそれは$SAFEを拡張することで実現するのが筋というものではないで
> しょうか? そうではなくThreadGroupを使うことで何がどう便利になるのか、が
> 残念ながら見えてきません。

関数的メソッドも使っているような普通の Ruby スクリプトを
環境汚染することなくそのまま動かせる環境が欲しいと考えています.
スクリプトを無名モジュールで wrap して実行する場合,
関数的メソッドの定義はうまく機能しません.
関数的メソッドは Object クラスに定義されてグローバルに環境を汚染するため
禁止されても仕方がない存在ですが,使えた方が嬉しいのは確かです.

# 先のサンプルスクリプトには含んでいませんが,
# ThreadGroup#make_local_space! は関数的メソッドについても
# 有効空間を限定できますので,良かったらお試しください.

既存のクラスに対するメソッド追加もしばしば行われますが,
これもグローバルな変更になりますから禁止されるべきものとなります.
safe level の問題以外のケースでも,定義が干渉し合うライブラリ等を
同時に使いたいという場合も同様の問題を含んでいます.

これらの問題のすべてを safe level の拡張で対処できるとは思えません.
仮に safe level からのアプローチで解決を図るとしても,
ThreadGroup が管理単位となって make_local_space! のようなものが
必要になるだろうと予想します.
ならば,safe level と無関係に有効に使いうる make_local_space! を実装し,
それと組み合わせて safe level の機能強化を考えるのも不自然とは思えません.
-- 
永井 秀利  (nagai@ai.kyutech.ac.jp)
九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教

In This Thread