SUnit GUI

>
> 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" <[hidden email]>
> Date: December 19, 2008 7:52:21 PM CEST
> To: "The general-purpose Squeak developers list" <[hidden email]>
> Subject: Re: [squeak-dev] Re: Resume Problems
> Reply-To: The general-purpose Squeak developers list <[hidden email]>
>
> 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 <[hidden email]> 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.
>
>
>
>

> 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 <[hidden email]
> > 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" <[hidden email]>
>> Date: December 19, 2008 7:52:21 PM CEST
>> To: "The general-purpose Squeak developers list" <[hidden email]
>> >
>> Subject: Re: [squeak-dev] Re: Resume Problems
>> Reply-To: The general-purpose Squeak developers list <[hidden email]
>> >
>>
>> 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 <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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 <[hidden email]
>> > 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" <[hidden email]>
>>> Date: December 19, 2008 7:52:21 PM CEST
>>> To: "The general-purpose Squeak developers list" <[hidden email]
>>> >
>>> Subject: Re: [squeak-dev] Re: Resume Problems
>>> Reply-To: The general-purpose Squeak developers list <[hidden email]
>>> >
>>>
>>> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
> <[hidden email]> 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 <[hidden email]
>>> > 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" <[hidden email]>
>>>> Date: December 19, 2008 7:52:21 PM CEST
>>>> To: "The general-purpose Squeak developers list" <[hidden email]
>>>> >
>>>> Subject: Re: [squeak-dev] Re: Resume Problems
>>>> Reply-To: The general-purpose Squeak developers list <[hidden email]
>>>> >
>>>>
>>>> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> 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 <[hidden email]>  
> 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
>> <[hidden email]> 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 <[hidden email]
>>>>> 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" <[hidden email]>
>>>>> Date: December 19, 2008 7:52:21 PM CEST
>>>>> To: "The general-purpose Squeak developers list" <[hidden email]
>>>>>>
>>>>> Subject: Re: [squeak-dev] Re: Resume Problems
>>>>> Reply-To: The general-purpose Squeak developers list <[hidden email]
>>>>>>
>>>>>
>>>>> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> 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
> [hidden email]
> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project