indeed but when this is yellow we should be able to click on it? no? Stef
On Apr 11, 2009, at 6:54 PM, Lukas Renggli wrote: > 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
