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
