[#18042] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — gdefty@...
Hi,
[#18052] Enumerators that know about a block — "David A. Black" <dblack@...>
Hi --
[#18086] Suggestion to change Time#to_s format to an official standard — Dirkjan Bussink <d.bussink@...>
Hello people,
[#18110] [Ruby 1.9 - Feature #403] (Open) Add support to Haiku — Anonymous <redmine@...>
Issue #403 has been reported by Anonymous.
[#18121] [Ruby 1.8.7 - Bug #405] (Open) ssl.rb:31: [BUG] Bus Error — Anonymous <redmine@...>
Issue #405 has been reported by Anonymous.
[#18130] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Brian Candler <B.Candler@...>
> Seriously though... Array.first is a noun.
[#18145] [PATCH] error.c (Init_Exception): Rename class "fatal" to "Fatal" — Otto Hilska <otto.hilska@...>
Hi,
Hi,
Nobuyoshi Nakada wrote:
Hi,
On Thu, Aug 7, 2008 at 1:37 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
On Thu, Aug 7, 2008 at 15:48, Jeremy Kemper <jeremy@bitsweat.net> wrote:
[#18164] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — gdefty@...
In message "Re: [ruby-core:18133] Re: New array
[#18237] Severe problem with garbage collection — Bertram Scharpf <lists@...>
Hi,
[#18247] Thread#priority(=) will be obsolete — SASADA Koichi <ko1@...>
Hi,
[#18252] Re: result for mget [last:10 MIME/multipart] (1/1) (ruby-core ML) — "Giuseppe Bilotta" <giuseppe.bilotta@...>
>> We are planning to make Thread#priority(=) method as obsolete method
Hi,
[#18257] Definition of "Support levels", 1.9.1 supported platforms and recruitment for platform maintainers — "Yugui (Yuki Sonoda)" <yugui@...>
Hi, all.
HI! This answers the question that I asked a few days ago, thank you!
Hi,
Yukihiro Matsumoto wrote:
[#18263] Am I right that this is wrong? — "David A. Black" <dblack@...>
Hi --
Hi,
Hi --
On Wed, Aug 13, 2008 at 3:04 PM, David A. Black <dblack@rubypal.com> wrote:
[#18303] Ruby 1.8.6 yields 50%-100% performance gain when compiled at full optimization — kevin nolan <kpnolan@...>
After compiling Ruby 1.8.6 with '-O3 -mtune=K8 -march=K8' on an AMD 4800
kevin nolan:
On Sat, 2008-08-16 at 03:39 +0900, Shot (Piotr Szotkowski) wrote:
[#18314] [Bug #449] File.zero? returns true when given a directory on Windows — Anonymous <redmine@...>
Bug #449: File.zero? returns true when given a directory on Windows
Hi,
I submitted that original bug (first time using redmine :)). Here's some mo=
Hi,
Not at all - it means we're now free to do the right thing :)
On Mon, Aug 18, 2008 at 6:45 PM, John Lam (IRONRUBY)
[#18319] NEW Command: absolute_path() -- — "C.E. Thornton" <admin@...>
Core,
Hi,
Are you sure you didn't mean to use "~/oracle/bin"
Trans wrote:
[#18349] [Feature:1.9] autoload with a block — Nobuyoshi Nakada <nobu@...>
Hi,
[#18354] Retrieving bytecode for method — Michael Neumann <mneumann@...>
Hi,
[#18381] [Bug #496] DRb.start_service(nil) is very slow — Hongli Lai <redmine@...>
Bug #496: DRb.start_service(nil) is very slow
[#18387] [Bug:1.9] rubygems fails to cache spec file — "Yusuke ENDOH" <mame@...>
Hi,
[#18396] problems with test_io.rb on cygwin — Martin Duerst <duerst@...>
I have run into problems with test_io.rb on cygwin.
Hello,
[#18405] [Bug #512] String#% behavior — Federico Builes <redmine@...>
Bug #512: String#% behavior
[#18409] ruby-lang.org has old download links — Nate_Wiger@...
The download links here:
[#18414] DoS vulnerability in REXML — "Shugo Maeda" <shugo@...>
Hi,
[#18424] [Bug #528] Several ruby-mode.el improvements — Nathan Weizenbaum <redmine@...>
Bug #528: Several ruby-mode.el improvements
[ruby-core:18049] Re: finalizers in 1.8 no longer run after gc_sweep()
In most garbage collectors I know of, it's unwise to have hard
expectations about when finalizers are going to be run. Not only does it
impose considerably more overhead on the underlying GC (since it can't
do finalizers as a separate step from sweeping), but it is impossible to
implement on black-boxed GC implementations that don't make the same
guarantee. Obviously it's a problem if this really isn't finalizing
until the process terminates or GC.start is called, but there should be
no expectation that finalizers will run immediately after any GC
calls...the GC should be free to call finalizers when it's appropriate
to do so.
I'm not saying this might not be a bug...just that finalization
shouldn't be expected to run immediately after an object is collected.
- Charlie
Eric Hodel wrote:
> This was brought up by Roger Pack in [ruby-talk:309757].
>
> In 1.6, a finalizer would run immediately after the garbage collector
> collected an object. Now they are no longer run until the process
> terminates or an explicit GC.start is run:
>
> $ cat final.rb
> $finalizer_proc = proc do |obj_id| puts "#{obj_id} finalized" end
>
> def a() b end
> def b() c end
> def c() d end
> def d() e end
> def e() f end
> def f() g end
> def g() h end
> def h() i end
> def i() j end
> def j() k end
> def k() make_obj end
>
> def make_obj
> o = Object.new
> ObjectSpace.define_finalizer o, $finalizer_proc
> o.__id__
> end
>
> obj_id = a
>
> puts "#{obj_id} created"
>
> a = []
> s = 'a'
>
> begin
> loop do
> ObjectSpace._id2ref obj_id
> a << s.succ!
> print "#{s}\r"
> end
> rescue RangeError
> puts
> puts "#{obj_id} collected"
> end
>
> $ ruby -v final.rb
> ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
> 81660 created
> avr
> 81660 collected
> 81660 finalized
> $ ruby16 -v final.rb
> ruby 1.6.8 (2005-09-21) [i386-darwin9.4.0]
> 1117686 created
> 1117686 finalized
> omu
> 1117686 collected
> $
>
> I would expect the finalized line to print before the collected line at
> all times. This is no longer true.
>
> Running the finalizers in gc_sweep() was removed in r7090. The
> following patch restores the 1.6 behavior, but I'm unsure if it
> re-introduce some problem from [ruby-dev:24536].
>
> Index: gc.c
> ===================================================================
> --- gc.c (revision 18230)
> +++ gc.c (working copy)
> @@ -1196,7 +1196,7 @@ gc_sweep()
>
> /* clear finalization list */
> if (final_list) {
> - deferred_final_list = final_list;
> + finalize_list(final_list);
> return;
> }
> free_unused_heaps();
>
>