[#38121] regex performace tuning and ABI compatibility — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
13 messages
2009/03/03
[#38125] Request for plans to break compatibility; Was: Re: regex performace tuning and ABI compatibility
— "Yugui (Yuki Sonoda)" <yugui@...>
2009/03/03
Yuguiです。
[#38129] Re: Request for plans to break compatibility; Was: Re: regex performace tuning and ABI compatibility
— Nobuyoshi Nakada <nobu@...>
2009/03/04
なかだです。
[#38128] Re: regex performace tuning and ABI compatibility
— Nobuyoshi Nakada <nobu@...>
2009/03/04
なかだです。
[#38131] Bug when daemonizing — rubikitch@...
るびきちです。
6 messages
2009/03/04
[#38145] MSの方との相談に先立って — masayoshi takahashi <maki@...>
高橋征義です。どこに投げるのがベストか判断つかなかったので、
7 messages
2009/03/11
[#38153] [feature:trunk] warning when Kernel#p is used — Yusuke ENDOH <mame@...>
遠藤です。
7 messages
2009/03/11
[#38191] big time — Tanaka Akira <akr@...>
思い立って、time_t を越える範囲を Time で扱うことに挑戦して
31 messages
2009/03/27
[#38198] Re: big time
— Yukihiro Matsumoto <matz@...>
2009/03/28
まつもと ゆきひろです
[#38194] Re: big time
— Tadayoshi Funaba <tadf@...>
2009/03/28
> 思い立って、time_t を越える範囲を Time で扱うことに挑戦して
[#38196] Re: big time
— Tanaka Akira <akr@...>
2009/03/28
In article <20090328.134401.209982445.tadf@dotrb.org>,
[#38202] Re: big time
— Urabe Shyouhei <shyouhei@...>
2009/03/29
卜部です。
[#38205] Re: big time
— Tanaka Akira <akr@...>
2009/03/29
In article <49CF6641.7010204@ruby-lang.org>,
[#38214] Re: big time
— Urabe Shyouhei <shyouhei@...>
2009/03/30
Tanaka Akira さんは書きました:
[#38215] Re: big time
— Tanaka Akira <akr@...>
2009/03/30
In article <49D07B1B.7000602@ruby-lang.org>,
[#38216] Re: big time
— Urabe Shyouhei <shyouhei@...>
2009/03/30
卜部です。
[#38227] Re: big time
— Tanaka Akira <akr@...>
2009/03/31
In article <49D0E3D1.5020206@ruby-lang.org>,
[#38234] Re: big time
— Urabe Shyouhei <shyouhei@...>
2009/04/01
Tanaka Akira さんは書きました:
[#38242] Re: big time
— Tanaka Akira <akr@...>
2009/04/01
In article <49D33295.3000600@ruby-lang.org>,
[#38245] Re: big time
— Urabe Shyouhei <shyouhei@...>
2009/04/01
卜部です。
[#38267] Re: big time
— Tanaka Akira <akr@...>
2009/04/03
In article <49D39822.6070505@ruby-lang.org>,
[#38218] rinda/eval.rb — Masatoshi SEKI <m_seki@...>
咳といいます。
20 messages
2009/03/30
[#38219] Re: rinda/eval.rb
— Tanaka Akira <akr@...>
2009/03/31
In article <F01982B3-FBB5-497F-BA36-38FA250E7D69@mva.biglobe.ne.jp>,
[#38223] Re: rinda/eval.rb
— Masatoshi SEKI <m_seki@...>
2009/03/31
咳といいます。
[#38229] Re: rinda/eval.rb
— "U.Nakamura" <usa@...>
2009/04/01
こんにちは、なかむら(う)です。
[#38233] Re: rinda/eval.rb
— Tanaka Akira <akr@...>
2009/04/01
In article <20090401095853.B00A.C613B076@garbagecollect.jp>,
[#38259] Re: rinda/eval.rb
— Yukihiro Matsumoto <matz@...>
2009/04/03
まつもと ゆきひろです
[#38263] Re: rinda/eval.rb
— "U.Nakamura" <usa@...>
2009/04/03
こんにちは、なかむら(う)です。
[#38222] *BSD で fork できない理由 — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
きしもとです
12 messages
2009/03/31
[#38230] Re: *BSD で fork できない理由
— "Akinori MUSHA" <knu@...>
2009/04/01
At Tue, 31 Mar 2009 18:48:46 +0900,
[#38232] Re: *BSD で fork できない理由
— Urabe Shyouhei <shyouhei@...>
2009/04/01
卜部です。
[#38235] Re: *BSD で fork できない理由
— Tanaka Akira <akr@...>
2009/04/01
In article <49D308AD.4040303@ruby-lang.org>,
[#38236] Re: *BSD で fork できない理由
— Urabe Shyouhei <shyouhei@...>
2009/04/01
Tanaka Akira さんは書きました:
[#38238] Re: *BSD で fork できない理由
— "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
2009/04/01
きしもとです
[ruby-dev:38215] Re: big time
From:
Tanaka Akira <akr@...>
Date:
2009-03-30 14:22:48 UTC
List:
ruby-dev #38215
In article <49D07B1B.7000602@ruby-lang.org>, Urabe Shyouhei <shyouhei@ruby-lang.org> writes: > コアの中だけで見るとなさそうですね。拡張ライブラリまで見ると > Zlib::GzipWriter#mtime=とか、まあなんかありそうです。あと他のプロセスと通信する > 場合にtime_tを吐く必要がある例は思い浮かびますが、さすがにそれはちょっと別の話 > かな。 ふむ。これは違うんじゃないですか? Zlib::GzipWriter#mtime= は gzip フォーマットの mtime を指定 するもので、RFC 1952 によると MTIME フィールドは 4byte です から、これは OS の time_t のサイズによらず、32bit なんじゃな いですか? つまり、32bit time_t な OS では一致しますが、64bit time_t な OS では一致しないんじゃないでしょうか。 > 個別の状況を具体的に検討しなきゃいけない場合ってのはえてして何かの仕組みが足り > てないときな気がしますが... 私の見方としては、この問題は用法に依存します。 time_t として使う用法が全てなのか、大半なのか、稀なのか、と いうことです。 そういう用法は外部で決まるので、Time クラス自体をいくら眺め てもわからず、具体的に検討しなければならないのは自然だと思い ます。 ただ、用法に依存するような仕様はそもそもよろしくない、という ことならそれはそれで傾聴に値する意見だと思います。 もしそうだとすると、time_t という用法に依存した仕様はよくな くて、Time は時刻というものの性質自体に自然に対応するように すべきで、少なくとも 2038年で途切れるというのはなんとも不自 然、ということになる気がしますが。 > 風呂敷を広げると、例外ってロジックの誤りを処理するのには向いているけども、不正 > な値を追跡するのには向いてないと思います。他の言語でそういうのをどう処理してる > かというと、型で頑張っているんじゃないかなあ。HaskellだとData.Time.UTCTimeの他 > にSystem.Posix.Types.EpochTimeとかいう型があって、相互の変換は明示的に行わない > といけなそうな感じになってます(試してないけど)。 そうですね。型で値を制約すれば、制約に反したところで発見でき ます。 > 今回の場合で言うと、time_tはTimeが表現できる時刻たちの真部分集合になっているわ > けで、OOP的にはTimeのサブクラスとしてtime_tなクラスを表現するのが一番自然だとは > 思います。File.utimeはtime_tのほうしか受け付けないことにして、ダウンキャストは > 明示的にやらせることにすれば、ダウンキャストのタイミングで警告を出したり例外に > したりするのは、変数を追跡するよりは大分簡単だと想像します。 まずは引数に型宣言をつけないといけませんね。 あるいは型推論に挑戦するか。 それを実現した後なら、ダウンキャストを忘れたら File.utime に たどり着く前に検出できるでしょう。 ところで gzip の mtime の値を表現するクラスも、time_t 用のク ラスとは別に作るんでしょうか。 > それがRubyっぽいかは、ちょっとなんとも分かりかねますが。 かなりあきらかに Ruby っぽくないというレベルに達していると思 います。 -- [田中 哲][たなか あきら][Tanaka Akira]