I cannot reproduce, for me the tests are always green. What image are you using?
Lukas On Sat, Apr 11, 2009 at 5:37 PM, Stéphane Ducasse <[email protected]> wrote: > When running the kernelTest-Classes > testClassDescriptionallSubInstances is yellow but when run > individually green. > > > > On Apr 11, 2009, at 2:57 PM, Lukas Renggli wrote: > >> I don't think this is related to #doesNotUnderstand:, but if you tell >> me what test case this is I can have a look. >> >> Lukas >> >> On Saturday, April 11, 2009, Stéphane Ducasse <[email protected] >> > wrote: >>> >>> 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. >>> >>> >>> >>> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
