[#8136] Confused exception handling in Continuation Context — "Robert Dober" <robert.dober@...>

Hi all

13 messages 2006/07/06

[#8248] One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...>

I just posted this to ruby-talk. But I would also like to discuss this

33 messages 2006/07/18
[#8264] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

From my experience using both tool chains on Windows (for the ruby-prof

[#8266] Re: One-Click Installer: MinGW? or VC2005? — "Curt Hibbs" <ml.chibbs@...> 2006/07/19

Tim, I'm going to top reply since your post was so long. I'm interested in

[#8267] Re: One-Click Installer: MinGW? or VC2005? — Charlie Savage <cfis@...> 2006/07/19

> Tim, I'm going to top reply since your post was so long. I'm interested in

[#8271] my sandboxing extension!! — why the lucky stiff <ruby-core@...>

I have (what feels like) very exciting news. I finally sat down to code up my

17 messages 2006/07/19

[#8430] Re: doc patch: weakref. — "Berger, Daniel" <Daniel.Berger@...>

> -----Original Message-----

19 messages 2006/07/28
[#8434] Re: doc patch: weakref. — Yukihiro Matsumoto <matz@...> 2006/07/29

Hi,

[#8436] Re: doc patch: weakref. — Daniel Berger <djberg96@...> 2006/07/29

Yukihiro Matsumoto wrote:

[#8437] Re: doc patch: weakref. — Mauricio Fernandez <mfp@...> 2006/07/29

On Sat, Jul 29, 2006 at 07:37:24PM +0900, Daniel Berger wrote:

[#8441] Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...>

I have the following code:

18 messages 2006/07/30
[#8442] Re: Inconsistency in scoping during module_eval? — nobu@... 2006/07/30

Hi,

[#8443] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/30

Why does this:

[#8445] Re: Inconsistency in scoping during module_eval? — Yukihiro Matsumoto <matz@...> 2006/07/30

Hi,

[#8454] Re: Inconsistency in scoping during module_eval? — "Charles O Nutter" <headius@...> 2006/07/31

So to clarify...

Re: [PATCH] --fqname option to test/unit/autorunner.rb

From: jonathan gold <dev@...>
Date: 2006-07-13 17:34:34 UTC
List: ruby-core #8206
Thanks again for getting back to me. Perhaps my original focus on the 
fact that I had multiple test cases in the same file was something of a 
red herring -- I think it's only incidental to the real issue.

As I understand the current intent of AutoRunner, and of the testing 
libraries as a whole, the intent is to have a collector 
(Collector::ObjectSpace, Collector::Dir, or otherwise) gather up 
multiple test cases from somewhere. As it is today, the '--testcase' and 
the '--name' options are in place to allow the user to filter the 
collection, regardless of how they were collected, in some meaningful 
way. I believe that these two options leave a gap for what I'm proposing 
with '--fqname', and so it seems that the patch would be in line with 
the current spirit of the libraries.

Again, perhaps my assumptions are incorrect about the intent of the 
Collector classes and of how the test suites are expected to function. 
If that is the case, perhaps the authors most familiar with the testing 
architecture could help me better understand?

jon

Berger, Daniel wrote:
>>-----Original Message-----
>>From: jonathan gold [mailto:dev@samizdatdigital.org] 
>>Sent: Wednesday, July 12, 2006 3:22 PM
>>To: ruby-core@ruby-lang.org
>>Subject: Re: [PATCH] --fqname option to test/unit/autorunner.rb
>>
>>
>>Daniel --
>>
>>One of my colleagues pointed out that maybe I mistook your initial 
>>response. To clarify, will this patch be applied to the ruby 
>>codebase at 
>>some point?
> 
> 
> Not unless Matz or Nathaniel Talbott approve it.
> 
> There's no reason you couldn't create your own little library, install
> it, and require it separately, is there?  Otherwise you'll be waiting
> until mid August at the earliest.  Given the lack of feedback on your
> patch I suspect the general consensus is that you shouldn't put multiple
> test case classes in the same file, so there's just no demand for this
> patch.
> 
> Regards,
> 
> Dan
> 
> 
> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly 
> prohibited and may be unlawful.  If you have received this communication 
> in error, please immediately notify the sender by reply e-mail and destroy 
> all copies of the communication and any attachments.
> 

In This Thread