[#15701] Ruby 1.9.0-1 snapshot released — Yukihiro Matsumoto <matz@...>
Hi,
[#15704] Proc#curry doesn't work on func which produces func — Lin Jen-Shin <godfat@...>
Proc#curry doesn't work on function which produces function,
Hi,
>>>>> "Y" == Yusuke ENDOH <mame@tsg.ne.jp> writes:
[#15707] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>
Hi, developers,
On Sat, Mar 01, 2008 at 08:58:00PM +0900, Akinori MUSHA wrote:
Hi,
At Fri, 21 Mar 2008 23:16:54 +0900,
At Mon, 24 Mar 2008 21:39:45 +0900,
[#15709] capitalize and downcase — Trans <transfire@...>
I've always wondered why String#capitalize downcases the whole string
[#15713] Ruby String hash key overflow when converting to Fixnum. — "Chiyuan Zhang" <pluskid@...>
Hi, all! I've opened a issue at rubyforge:
[#15728] Question on build process - skipping unsupported extensions — Daniel Berger <djberg96@...>
Hi,
[#15740] Copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>
Hi.
Hi,
Yukihiro Matsumoto wrote:
Yukihiro Matsumoto wrote:
Hi.
Hongli Lai wrote:
Hi.
Hi,
I believe I managed to close the performance gap to only 6% slower than
Daniel DeLorme wrote:
[#15746] Am I misinterpreting the new keyword arguments to IO.foreach and friends? — Dave Thomas <dave@...>
I was expecting this to pass lines to the block:
[#15756] embedding Ruby 1.9.0 inside pthread — "Suraj Kurapati" <sunaku@...>
Hello,
Hi,
Hi,
Yukihiro Matsumoto wrote:
Suraj N. Kurapati wrote:
Hi,
Nobuyoshi Nakada wrote:
Suraj N. Kurapati wrote:
Hongli Lai wrote:
[#15775] next(n), succ(n) ? — Trans <transfire@...>
Can anyone see any reason against adding an optional parameter to
[#15778] Named captures and regular captures — Dave Thomas <dave@...>
It seems that once you have a named capture in a regular expression,
[#15783] Adding startup and shutdown to Test::Unit — Daniel Berger <Daniel.Berger@...>
Hi all,
Daniel Berger wrote:
On Wed, Mar 05, 2008 at 07:52:40AM +0900, Daniel Berger wrote:
[#15835] TimeoutError in core, timeouts for ConditionVariable#wait — MenTaLguY <mental@...>
I've been reworking JRuby's stdlib to improve performance and fix
On Sun, 2008-03-09 at 12:13 +0900, MenTaLguY wrote:
[#15837] Correct procedure for patch review? — Hongli Lai <hongli@...99.net>
Hi.
[#15855] Ruby 1.8.6 trace return line numbers wrong — "Rocky Bernstein" <rocky.bernstein@...>
Consider this program:
[#15860] Webrick directory traversal exploit on UNIX — Jos Backus <jos@...>
DSecRG Advisory #DSECRG-08-026 aka -018 describes a remote directory traversal
[#15871] Sparc architecture optimizations — Thomas Enebo <Thomas.Enebo@...>
Someone at Sun has been looking at Ruby on Sparc:
Thomas Enebo wrote:
Hello Ruby-core,
Hi,
Yukihiro Matsumoto wrote:
Prashant Srinivasan wrote:
[#15880] Ruby 1.8.6 binding value after "if" expression evaluation — "Rocky Bernstein" <rocky.bernstein@...>
Here's another trace hook weirdness that I've encountered.
Hello,
Thanks. The output you report matches what I get in 1.8.6 and suggests where
I think I've found why this is happening. The trace hook for NODE_IF is
[#15907] Range#member? semantics seem wrong — Dave Thomas <dave@...>
Range#member? has been changed so that it the start and end of the
[#15909] RARRAY_PTR — "Laurent Sansonetti" <laurent.sansonetti@...>
Hi,
[#15917] Ruby 1.9 (trunk) crashes when running RubyGems and Rake — Hongli Lai <hongli@...99.net>
Ruby 1.9 (trunk) seems to crash when running the supplied RubyGems and Rake:
Hi,
Nobuyoshi Nakada wrote:
On Mon, Mar 17, 2008 at 06:53:19PM +0900, Hongli Lai wrote:
[#15927] how to create a block with a block parameter in C? — Paul Brannan <pbrannan@...>
This works in Ruby (1.9):
>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:
[#15933] complex and rational — Dave Thomas <dave@...>
Before I start doing the documentation for the PickAxe, could I just
[#15936] Are Depreciated Methods "add_final" & "remove_final" supposed to ACTUALLY WORK? — Charles Thornton <ceo@...>
In Working on IRHG Docs for GC the following
>>>>> "C" == Charles Thornton <ceo@hawthorne-press.com> writes:
ts wrote:
[#15938] Questions on Enumerator#skip_first and Enumerable#first — "Artem Voroztsov" <artem.voroztsov@...>
I asked in ruby-talk, but did not get answer.
On Mar 18, 2008, at 6:20 AM, Artem Voroztsov wrote:
[#15975] Bugs in REXML — "Federico Builes" <federico.builes@...>
Hi,
On Mar 21, 2008, at 17:35, Federico Builes wrote:
[#15980] 1.8.6 memory leak? — "Stephen Sykes" <sdsykes@...>
Hi,
[#15983] Changing the algorithm of String#* — apeiros <apeiros@...>
Hi there
[#15990] Recent changes in Range#step behavior — "Vladimir Sizikov" <vsizikov@...>
Hi,
Hi Dave,
Hi Dave,
Hi,
Hi,
Hi,
On Wed, Mar 26, 2008 at 7:01 PM, Dave Thomas <dave@pragprog.com> wrote:
Dave Thomas wrote:
Dave Thomas wrote:
Dave Thomas wrote:
Dave,
This is all a semantic problem. Different people have different
[#16011] New ERb mode — Marc Haisenko <haisenko@...>
Hi folks,
On Tuesday 25 March 2008, Marc Haisenko wrote:
ERb already does this:
On Tuesday 25 March 2008, Jason Roelofs wrote:
On Tue, Mar 25, 2008 at 11:39 AM, Marc Haisenko <haisenko@comdasys.com> wro=
On Tuesday 25 March 2008, Jason Roelofs wrote:
[#16023] some Enumerable methods slower in 1.9 on OS X after revision 15124 — Chris Shea <cmshea@...>
All,
Hi,
Hi,
On Thu, Mar 27, 2008 at 02:26:51PM +0900, Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
[#16057] About the license of gserver.rb being "freeware"? — "XiaoLiang Liu" <liuxlsh@...>
Hello everyone,
[#16088] command_call in parse.y — Adrian Thurston <thurston@...>
Hi,
Re: Copy-on-write friendly garbage collector
Yukihiro Matsumoto wrote: > Hi, > > In message "Re: Copy-on-write friendly garbage collector" > on Thu, 20 Mar 2008 19:59:16 +0900, Hongli Lai <hongli@plan99.net> writes: > > |Sorry for mentioning this again, but it has been almost a week since my > |last patch. I'd really appreciate it if a core committer can comment on it. > > It works on my machine. But since it slows down Ruby a bit, we > haven't decided yet to merge it officially. Do you (or anyone else) > have something we can use for GC benchmark? > > matz. Hi. Yes, I use the following tool for benchmarking: http://pastebin.com/m26839d72 The results are as follows: - Standard Ruby: 13.600 seconds - My Ruby: 16.600 seconds So the copy-on-write friendly GC seems to be about 20% slower. (At least, on this machine. I've noticed that the percentage can vary wildly depending on the specific machine. On some machines it only seems to be about 5% slower.) However, I've recently submitted a patch which implements pluggable marking tables. By default, it uses the non-copy-on-write-friendly implementation (i.e. the same as the old one, which uses mark flags on the objects directly). So if I remove the "GC.copy_on_write_friendly = true" line, then the result is as follows: - My Ruby: 13.394 seconds So by default, performance is on par with standard Ruby. Only if the programmer has explicitly set "GC.copy_on_write_friendly = true" will there be a speed hit. The standard Ruby version I use is 1.8.6 patchlevel 114. My modified Ruby is also based on that version. Both Ruby binaries are compiled with '-g' (i.e. no optimizations). Finally, I've benchmarked some Ruby on Rails applications. Only 10% of the total application time seems to be spent on the garbage collector. So if the garbage collector is 20% slower, then it only results in a 2% speed reduction in total. I'd like to know whether my patches are acceptable, now that it's just as fast as the normal Ruby by default. And if it's not acceptable, I'd like to know how many % speed hit would be acceptable. Thanks. - Hongli Lai