Re: [Pharo-project] SUnit GUI

Sat, 11 Apr 2009 05:10:32 -0700 


On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote:


is it normal that when one doubleclick on an yellow item in the list
it does not open a debugger?


No, that's not normal.

Right now I can think of two possible causes:

- The test is not deterministic or has side effects that cause it to
sometimes fail and sometimes pass.


I do not think that this is the case.
I can reproduce the bhevaior run KernelsTests-classes.



- Another reason that I recently noticed is related to exceptions and
how SUnit runs the tests. When a test is run (when you click on run)
the code is wrapped into an [ ... ] on: Error do: ..., thus catching
all exceptions. When a test is debugged (when you click on an item on
the list) the code is not wrapped in such a handler assuming that this
would cause the system to open a debugger. However, depending on the
exception raised this causes a custom default action to be evaluated
and the test does not fail anymore. Many file-related exceptions have
such a default behavior. Oscar recently reported an issue on this:
<http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why
this only appeared now? Was there anything changed related to SUnit or
Exceptions?


I know that we introduce a fix of eliot in the way does not understand
lead to open the debugger.

see the mail below
The code is attached to a mail of 20 of december in pharo mailing-list
Let me know if you understand better than me. Now I do not have the time
to look at it.

Stef



Begin forwarded message:


From: "Eliot Miranda" <[email protected]>
Date: December 19, 2008 7:52:21 PM CEST
To: "The general-purpose Squeak developers list" <[email protected] > 
Subject: Re: [squeak-dev] Re: Resume Problems
Reply-To: The general-purpose Squeak developers list <[email protected] > 

Hi Zulq,
I made sure this was fixed in VisualWorks. Steve Dahl and I fixed this together. Here's an analogous fix for Squeak. The essential change is to make Object>>doesNotUnderstand: check if the MessageNotUnderstood exception was handled or not, so 

        MessageNotUnderstood new
                message: aMessage;
                receiver: self;
                signal.
        ^ aMessage sentTo: self.

is replaced with

        (exception := MessageNotUnderstood new)
                message: aMessage;
                receiver: self.
        resumeValue := exception signal.
        ^exception reachedDefaultHandler
                ifTrue: [aMessage sentTo: self]
                ifFalse: [resumeValue]

HTH

On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <[email protected]> wrote:
Hi Klaus,


Klaus D. Witzel wrote:
Nah, the result has nothing to do with #on:do: resuming with 1, you better 
try

[('abc' + 1) + 1]
  on: MessageNotUnderstood
  do: [:e | e resume: -1]
which still says 2. This because someone, behind you back, put #asNumber arithmethic into ByteString ... now this attempts (Number readFrom: 'abc') 
which gives 0 for your +1 +1 and so 2.

You may want to start DNU testing with ('abc' break; + 1) and then see
where it goes.
Hmm... I think something is not right or at the very least the semantics are subtly different than I expect. 

VisualWorks:
[Object new blah + 1]
 on: MessageNotUnderstood
 do: [:e | e resume: 1]  " = 2 "

[MessageNotUnderstood signal + 1]
 on: MessageNotUnderstood
 do: [:e | e resume: 1] " = 2 "

Squeak:
[Object new blah + 1]
 on: MessageNotUnderstood
 do: [:e | e resume: 1]  " infinite recursion!!! "

[MessageNotUnderstood signal + 1]
 on: MessageNotUnderstood
 do: [:e | e resume: 1] " = 2 "
If I look at doesNotUnderstand: in both I see that in VW the resumed value is returned. In Squeak is is not... surely this can't be right?
As for my problem, I think a simpler solution is to pass an adaptor/ proxy object to the block rather than the tag itself. This adaptor can then marshal behaviour such that it will act as a message eating null if it receives an MNU from the tag it's looking after. 

Thanks,
Zulq.

Attachment: SqueakMNUaLaVW.1.cs
Description: Binary data






_______________________________________________
Pharo-project mailing list
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to