[#8599] period.rb — akira yamada / やまだあきら <akira@...>
[#8606] can't build 1.1b9_28 on digital-unix — Go Nakagawa <nakagawa@...>
中川といいます。みなさんはじめまして。
まつもと ゆきひろです
中川です。
まつもと ゆきひろです
中川です。
まつもと ゆきひろです
中川です。
まつもと ゆきひろです
中川です。
まつもと ゆきひろです
中川です。
[#8609] Re: [ruby-dev:3184] Re: once function — "MAEDA Shugo" <shugo@...>
前田です。
[#8623] method iterator — Kazuhiro HIWADA <hiwada@...>
ひわだです。最近いろんな話が出て来て面白いです。
[#8648] sin(complex) — toyofuku@...
豊福@パパイヤです。
[#8649] [BUG] Segmentation fault — IWAOKA Masahiro <iwaoka@...>
最近はすっかり ruby にお世話になっております。岩岡です。
まつもと ゆきひろです
わたなべです.
岩岡です。
岩岡です。
自己フォロウを続けてしまいまして申し訳ございません。
まつもと ゆきひろです
わたなべです.
まつもと ゆきひろです
立石@JAISTです。
まつもと ゆきひろです
まつもと ゆきひろです
立石@JAISTです。
まつもと ゆきひろです
立石です。
まつもと ゆきひろです
[#8665] Re: Equivalence.rb — toyofuku@...
豊福@パパイヤです。
[#8739] [BUG?] mathn.rb — Yoshiyuki Kusano <kusano@...>
草野です.
[#8747] Bitwise operators for String — Inaba Hiroto <inaba@...>
1.1cのリリースも近いのに、今頃こんなことを言いだしても仕方ないのかも知
まつもと ゆきひろです
[#8749] 新人にお勧めのバージョン — Sinichiro Dezawa <dezawa@...>
出沢@フジフイルム です
[#8766] Compiling ruby-1.0-971225 — Shin-ichro Hara <sinara@...>
原です。
[#8770] ruby 1.1c0 released — matz@... (Yukihiro Matsumoto)
まつもと ゆきひろです
東芝の田中です。
In message <199807170546.OAA25091@picachu.netlab.co.jp>
出沢です
まつもと ゆきひろです
こんにちは、鄭です。
まつもと ゆきひろです
出沢@フジフイルム です
[#8778] tcltklib on 1.2 — "Kikutani, Makoto" <kikutani@...>
きくたにです。
[#8845] mapping a tagged file onto a class — Takao KAWAMURA <kawamura@...>
各行にフィルード名と値が含まれ、レコードの区切りは空行という、
まつもと ゆきひろです
In message "[ruby-list:8847] Re: mapping a tagged file onto a class"
原です。
> インスタンス変数にしたい気持ちはとてもわかるんですが、
原です。
[#8861] unary - in Complex — aito@...
あ伊藤です.
[#8862] domain name for ruby in US — gotoken@... (GOTO Kentaro)
ごとけんです
[#8872] do while — Kazumi Okamoto <kazusan@...>
はじめまして、岡本と申します。
こんにちは 小澤@日立 です。
岡本です。
[#8875] english manual 1.1c - rand — "Kikutani, Makoto" <kikutani@...>
rand(max)
[#8892] nil + 1, or Integer.to_i — Sinichiro Dezawa <dezawa@...>
出沢です
まつもと ゆきひろです
まつもと ゆきひろです
matz> 良く見るとto_i,to_fともにNumeric.htmlに記述があります.これ
けいじゅ@日本ラショナルソフトウェアです.
出沢です
けいじゅ@日本ラショナルソフトウェアです.
まつもと ゆきひろです
matz> Numeric#to_iとか,Integer#to_iとかの実装があれば良い問題なん
かんだです。
まつもと ゆきひろです
前田です。
[#8897] ruby-mode.el & font-lock-mode — Takao KAWAMURA <kawamura@...>
ruby-mode.el($Revision: 1.1.1.2.2.19 $)を便利に使わせて頂い
[#8907] Perl Conference Japan in Nov. — "Kikutani, Makoto" <kikutani@...>
python-ml-jpに入ってる人じゃないとわからないネタかもしれないですが、
[ruby-list:8734] Re: [BUG] Segmentation fault
上田@富士通研と申します。 ま> とはいえ,現状でもGCのための時間はわずかなものですから,メモ ま> リとの兼ね合いを考えるとGCをケチるよりも,少々多めにGCした方 ま> が結局は効率が良いようにも思えてきました. そうでしょうね。 仮想メモリがこれだけ普及した現在でも、GCは結局のところ、どうにかして 「実メモリ」を効率的に利用するために行なうわけですよね。 例えば、ディスクのアクセスが起きると、メモリアクセスとは比べ物にならな いほどの時間がかかるので、SWAP または ページアウトするほどのサイズのメ モリをとらないようにGCすることに意味があります。 また、ruby が GCの時にcompaction をかけているかどうか知らないのですが、 compaction をかけると page-fault や cache ミスが減って、極端にスピード が速くなることがあると聞いたことがあります。 ま> |matz@netlab.co.jpさん(07月14日14時): ま> |matz>>あの件については悩んでまして,個人的にはこーゆーことはユーザ ま> |matz>>が指定するのではなく,GCがアタマ良くなって対応すべきではない ま> |matz>>かというのが私の考えです. ま> | ま> |理想的なGCですね。 というわけで、OS依存になってしまう危険が高いのですが、実メモリをいくつ 積んでいるかとか、どのくらいページフォールトが起きているか(別のプロセ スが多かったりメモリを消費している場合に対応)を参考にしてGCをすると 「速い」GCになるような気がします。 # その程度のことなら誰かが論文を書いているかな? --HAL