[Pharo-project] SUnit GUI
lukas is it normal that when one doubleclick on an yellow item in the list it does not open a debugger? Stef
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. - 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? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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.
_______________________________________________ Pharo-project mailing list
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
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
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
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
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
indeed but when this is yellow we should be able to click on it?
Clicking on a yellow or red test just re-runs that test. If the test then suddenly passes, you are out of luck. The problem could be solved by capturing and storing a continuation when a test fails. Like this a debugger could be opened on the original stack that caused the error. This however would require a major rewrite of SUnit, as extra care has to be take when and how to release resources. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Wow. I naively assumed that the entire run-time context was still there as long as the red/yellow test was not garbage collected. Rerunning is obviously the smart thing to do, but snafus non-deterministic tests. So you should just click on those yellow tests over and over till the debugger pops up? ;-) - on On Apr 11, 2009, at 23:15, Lukas Renggli wrote:
indeed but when this is yellow we should be able to click on it?
Clicking on a yellow or red test just re-runs that test. If the test then suddenly passes, you are out of luck.
The problem could be solved by capturing and storing a continuation when a test fails. Like this a debugger could be opened on the original stack that caused the error. This however would require a major rewrite of SUnit, as extra care has to be take when and how to release resources.
Lukas
-- 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
participants (3)
-
Lukas Renggli -
Oscar Nierstrasz -
Stéphane Ducasse