Mhh no. In some rare cases it is yellow. There is definitely something non-deterministic or something with side-effects in those tests.
Lukas On Sat, Apr 11, 2009 at 6:52 PM, Lukas Renggli <[email protected]> wrote: > 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 > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
