[#1207] warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...>

This message was posted to ruby-talk, but I didn't get responce from

22 messages 2003/07/01
[#1208] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/01

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1209] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/02

ts wrote:

[#1210] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/02

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1211] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1212] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1213] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1214] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1215] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1237] FTP.new with block — Gavin Sinclair <gsinclair@...>

Hi,

22 messages 2003/07/19
[#1238] Re: [Patch] FTP.new with block — ts <decoux@...> 2003/07/19

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

[#1240] Re: [Patch] FTP.new with block — Mathieu Bouchard <matju@...> 2003/07/19

[#1297] Fix for Bug 1058 — Markus Walser <walser@...>

Hi,

16 messages 2003/07/25

Re: testunit, exit status and at_exit

From: "Nathaniel Talbott" <nathaniel@...>
Date: 2003-07-22 01:46:10 UTC
List: ruby-core #1270
Yukihiro Matsumoto [mailto:matz@ruby-lang.org] wrote:

> In message "Re: testunit, exit status and at_exit"
>     on 03/07/22, "Nathaniel Talbott" <nathaniel@talbott.ws> writes:
> 
> |  1. The last exit status that is set wins. So if there are multiple 
> |END procs, and they all set the exit status (by calling #exit), the 
> |last one registered wins (END procs are called in the order they are 
> |defined,
> |correct?)
> 
> They are executed reverse order they are defined.  I think 
> there's a reason for this order, which I don't remember correctly now.

Oops, I had that backwards.


> On my prototype, the first one wins.  Is this OK?

The first one defined, or the first one executed? My initial expectation is
for the last one executed to win, but either way is OK for Test::Unit - I
figure that if people start defining a bunch of END procs in their tests,
they've created their own troubles. If for some reason this strategy doesn't
work, they can always fall back on starting tests manually (via a "__FILE__
== $0" check or something like it).


> |  2. Calling #exit in an END proc does nothing, but calling #exit! 
> |immediately terminates with the given status (skipping any remaining 
> |END procs).
> 
> It works even now.  But Calling exit! bypasses other END 
> procs and finalizers.

Yup, I discovered that after my last email. I thought it would be an OK
solution, but forgot about finalizers. It's probably best to not skip them
in a case as regular as a failing test.


Nathaniel

<:((><



In This Thread