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 <renggli@gmail.com> 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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@inria.fr
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" <eliot.miranda@gmail.com> Date: December 19, 2008 7:52:21 PM CEST To: "The general-purpose Squeak developers list" <squeak-dev@lists.squeakfoundation.org
Subject: Re: [squeak-dev] Re: Resume Problems Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
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 <me@zulq.net> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project