[#32171] autoload_delete — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#32185] Date#+に大きな数字を与えるとおかしな日付に — "madoka yamamoto" <yamamotomadoka@...>
こんにちは、山本と申します。
> Dateオブジェクトに+で大きな数字を与えるとおかしくなるようです。
山本です。
> アルゴリズムの意味がわからないで書いた、表層的なパッチなので
Hi,
> 1.9ではRationalとComplexを組み込みに、という話はありましたが、
原です。
ささだです.
[#32192] test-all results - ruby 1.9.0 (2007-11-09 patchlevel 0) [i686-linux] — SASADA Koichi <ko1@...>
ささだです.
[#32198] [提案] Array#tail — "Yusuke ENDOH" <mame@...>
遠藤と申します。
まつもと ゆきひろです
西山と申します
遠藤です。
[#32204] yydebug — Nobuyoshi Nakada <nobu@...>
なかだです。
[#32205] Use two pipes for duplex IO.popen — Tanaka Akira <akr@...>
改心して duplex な IO.popen で socketpair を使うのはやめよう
なかだです。
In article <20071111120021.7f0592e5.nobu@ruby-lang.org>,
[#32206] Integer#ord for 1.8 — Tanaka Akira <akr@...>
1.9 と 1.8 の両方で ?a.ord で 97 が得られるように、1.8 に
[#32219] trunkでビルド失敗 — KIMURA Koichi <kimura.koichi@...>
木村です。
[#32247] round missing (mswin32) — KIMURA Koichi <kimura.koichi@...>
木村です。
[#32263] toplevel irb method — SASADA Koichi <ko1@...>
ささだです.
まつもと ゆきひろです
[#32266] version string — SASADA Koichi <ko1@...>
ささだです.
[#32268] RFLOAT_VALUE(val), DOUBLE2NUM(dbl) — SASADA Koichi <ko1@...>
ささだです.
SASADA Koichi wrote:
[#32306] nanosecond Time and stat — Tanaka Akira <akr@...>
最近、nanosecond 単位な timestamp があるようです。
In article <874pflntd5.fsf@fsij.org>,
まつもと ゆきひろです
In article <E1Iu2GD-0004Wh-1I@x31>,
[#32308] core dump with undef/alias using dynamic symbols — Tadashi Saito <shiba@...2.accsnet.ne.jp>
斎藤と申します。
遠藤と申します。
ささだです.
遠藤です。
ささだです.
[#32329] enumerator with single array and multiple arguments. — Tanaka Akira <akr@...>
enumerator を通すとひとつの配列と複数の引数が区別できません。
[#32330] defined?($&) — Tanaka Akira <akr@...>
ふと気がついたんですが、defined?($&) が "expression" になり
まつもと ゆきひろです
まつもと ゆきひろです
ささだです.
[#32333] test/ruby/test_eval.rb — SASADA Koichi <ko1@...>
ささだです.
まつもと ゆきひろです
ささだです.
まつもと ゆきひろです
[#32348] DRb test leaves ut_eval.rb process — Tanaka Akira <akr@...>
DRb のテストをすると、(テストがいろいろと失敗する他に) プロ
[#32352] 1.9.1のリリース時期について — KIMURA Koichi <hogemuta@...>
木村です。
まつもと ゆきひろです
木村です。
まつもと ゆきひろです
[#32403] Next 1.8.6 patch release? (was Re: 1.9.1のリリース時期について) — Takahiro Kambe <taca@...>
こんばんは。
卜部です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
成瀬です。
卜部です。
遠藤と申します。
遠藤です。
ささだです.
まつもと ゆきひろです
[#32404] SEGV on child process by fork on GC.stress. — Tanaka Akira <akr@...>
GC.stress = true 下で fork すると子プロセスが SEGV します。
まつもと ゆきひろです
In article <E1Iy7HA-0006zn-37@x31>,
まつもと ゆきひろです
ささだです.
[#32409] Re: [ruby-cvs:21293] Ruby:r14056 (trunk): * signal.c (trap_signm): SIGVTALRM no longer used for green — SASADA Koichi <ko1@...>
ささだです.
さとうふみやす @ OSS テクノロジです。
ささだです.
まつもと ゆきひろです
[ruby-dev:32200] Re: rational (Re: Date#+に大きな数字を与えるとおかしな日付に)
> 1.9ではRationalとComplexを組み込みに、という話はありましたが、 > なんか立ち消えてますね。難しいのはやっぱ責任を持って議論と作 > 業を行う人物がいるかどうかでしょうか。 石塚さんの成果もあり、他の特に関数型言語あたりの議論があるおかげで、 rational の仕様はなかなかに枯れていると思います。なので一旦安定してし まえば、保守はあまり大変ではないだろうと期待してはいます。 いい機会かもしれないので、rational について思っていることを書きます。 まず、原さんの rational による速度の改善は素晴らしと思います。原さんの 貢献に感謝しています。以前、とくに、date での改善についてくわしくテス トしたのですが、くわしい結果はなくしてしまったかもしれません。でも、か なり速くなるのは間違いありません。立石さんによる、初期的な試みである Frac と比べても明かに速いようです。 僕の利用範囲では、原さんの rational はとても安定してつかえています。少 し心配なところは、複雑さです。立石さんの Frac に比べても明かにそう思わ れます。C に直しても、やるべき事は、石塚さんの rational とそう変らない と思うのですが、ものすごく複雑になっているような印象があります。 もちろん、原さんのは、単に複雑になっているわけではなく、機能も性能もずっ と高いのですが、コードを眺めると、似たような記述が繰り返されているよう な印象を受けます。見通しが悪くなっている可能性があり、実際、過去に発見 したバグからは、そういう傾向が感じられました。これは詳細に検討した末の 結論ではなく、たんなる印象なので間違っているかもしれません。 自分が保守する覚悟で取りこんでもらうか、date の自前の機能として、内部 で利用する事もちょっと考えましたが、ざっと眺めたところでは、僕には無理 そうです。はやり現実的には、原さんが、やってくれるかどうかということで しょうか。