[#38121] regex performace tuning and ABI compatibility — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
Yuguiです。
なかだです。
なかだです。
[#38131] Bug when daemonizing — rubikitch@...
るびきちです。
[#38145] MSの方との相談に先立って — masayoshi takahashi <maki@...>
高橋征義です。どこに投げるのがベストか判断つかなかったので、
[#38153] [feature:trunk] warning when Kernel#p is used — Yusuke ENDOH <mame@...>
遠藤です。
[#38191] big time — Tanaka Akira <akr@...>
思い立って、time_t を越える範囲を Time で扱うことに挑戦して
まつもと ゆきひろです
> 思い立って、time_t を越える範囲を Time で扱うことに挑戦して
In article <20090328.134401.209982445.tadf@dotrb.org>,
卜部です。
In article <49CF6641.7010204@ruby-lang.org>,
Tanaka Akira さんは書きました:
In article <49D07B1B.7000602@ruby-lang.org>,
卜部です。
In article <49D0E3D1.5020206@ruby-lang.org>,
Tanaka Akira さんは書きました:
In article <49D33295.3000600@ruby-lang.org>,
卜部です。
In article <49D39822.6070505@ruby-lang.org>,
[#38218] rinda/eval.rb — Masatoshi SEKI <m_seki@...>
咳といいます。
In article <F01982B3-FBB5-497F-BA36-38FA250E7D69@mva.biglobe.ne.jp>,
咳といいます。
こんにちは、なかむら(う)です。
In article <20090401095853.B00A.C613B076@garbagecollect.jp>,
まつもと ゆきひろです
こんにちは、なかむら(う)です。
[#38222] *BSD で fork できない理由 — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
きしもとです
At Tue, 31 Mar 2009 18:48:46 +0900,
卜部です。
In article <49D308AD.4040303@ruby-lang.org>,
Tanaka Akira さんは書きました:
きしもとです
[ruby-dev:38205] Re: big time
In article <49CF6641.7010204@ruby-lang.org>, Urabe Shyouhei <shyouhei@ruby-lang.org> writes: > このパッチが具体的にどうという話ではなく、もうちょっと一般的な方針として、どう > かなあという気がしています。不正な値が見つかるのは早ければ早い程よいと思うから > です。 それだけであれば、よい話だと思います。 > たとえば、touch(1)のクローンを作っていたとしましょう。んで、コマンドライン引数 > の解釈にバグがあって、紀元前3億世紀とか、なんでもいいですけど、ともかくファイル > 更新時刻として不正なTimeオブジェクトを作ってしまったとしますね。そうすると、 > > 1) 見つけたいバグがあるところ: > コマンドライン引数解釈器 > 2) 実際に例外が上がるところ: > File.utimeとか > > という不一致が生じてしまうわけです。ここで、2)のほうもあなた自身が書いたコード > ならまだ追いかけられるかもしれませんが、えてして2)はライブラリの中だったりとか > するわけですよ。具体的にはFileUtilsとか。そうすると > > * スクリプト作者はどこが悪いのか追いかけられない > * ライブラリ作者は自分のせいじゃないバグ報告でモチベーションが削がれる > (だってユーザーが見るのは2のほうのバックトレースだし) > > という問題がある。これはよくないと思います。 Time が File.utime のために存在する、あるいはそこまでいかな くても大半の場合 File.utime で使われる、というなら、 File.utime の都合に Time をあわせることにはあり得る話だと思 います。そうすれば、たしかにその問題を早期に発見することがで きます。 しかし、実状としてはそうは思いません。Time オブジェクトの主 要な用途が File.utime かというと、そうではないように思います。 表示したり、比較したりといった time_t の制約が問題にならない 用途がむしろ主要な用途であるように思います。 そして、File.utime 以外に time_t な制限があるものがあるかと いうと、実はないのではないかと思います。探したんですが、見つ かりませんでした。あったら教えてください。 というわけで、File.utime に使うときに問題を早期に発見できる という利点と、メールの Date: フィールドとかから読み込んだ時 刻を Time 経由で比較できるなどといった利点とを比べて、どちら を選ぶか、という話になります。 ここで後者を選ぶのはどうでしょうか、というのがこの提案という ことになります。 卜部さんの指摘は一般的な話ということなので、これを一般化する と、利点も欠点もあるけれど、個々の用途に応じて全体としてどち らが便利なのかを考えて選ぶのが良いんじゃないでしょうか。 > こういう話はべつにTimeに限った話じゃなくて、最近見かけた例としては1.9でERBに与 > えるテンプレートと埋め込む文字列のencodingがcompatibleでない場合などは、同様に > ERBの中から例外が上がってくるんだけど、一体どのオブジェクトがいけなかったのかが > さっぱり分からん。とか、まあ、いろいろありそうな話じゃないですか。一般的に。 はい。いろいろあるでしょう。個々の状況を具体的に検討して考え ていくしかないと思います。 > これまではTimeは「生成できれば、とりあえずOSとのやりとりには使える」という、逆 > に言えばまずい時には生成する瞬間に例外になってくれていたわけで、これはよいイン > ターフェースだったと思うわけです。今回そのような特徴を排することになると、より > デバッグが難しい方向に倒れてしまう気がします。どんなもんでしょう。 Time に関しては、File.utime は主要な用途ではなく、その問題よ りも利点が大きいであろう、というのが私の判断です。 ただ、一般に、複数の利点をすべて得る方法を考えるのは重要だと 思います。たとえ無理という結論になるとしても、すくなくとも考 えるべきです。 この件についてあまりうまい方法を思いつくわけじゃないんですが、 とりあえず time_t の範囲内かどうか検査するメソッドをつけると いうのはあるかもしれません。あとは生成時に time_t の範囲外を 受け付けないメソッドとか? 本質的には、Time オブジェクト生成の時点で File.utime にたど り着くかどうかを自動的に判断できればいいのでしょうが、これが 現実的にできるかというと、ちょっとわかりません。 -- [田中 哲][たなか あきら][Tanaka Akira]