Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Tim Mackinnon]

Ah that’s interesting- it’s happened to me 4 or 5 tines in the last 2 days. 
Recent enough that maybe I can figure out a test case I’ll try.

Sent from my iPhone

> On 8 Jun 2018, at 18:57, Steven Costiou  wrote:
> 
> Concerning the bug 22085, i commented on fogbuzz:
> 
>> I believe it is because when running test cases, it runs through:
>> 
>> runCaseForDebug: aTestCase
>> [...call test code...]
>> on: self class failure , self class skip, self class warning, self 
>> class error
>> do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass]
>> 
>> So when you reach a doesNotUnderstand, you have:
>> 
>> doesNotUnderstand: aMessage
>> [...stuff...]
>> 
>> resumeValue := exception signal.
>> 
>> ^exception reachedDefaultHandler
>> ifTrue: [aMessage sentTo: self]
>> ifFalse: [resumeValue]
>> 
>> In normal cases (class of the receiver is not a test case), when you step in 
>> the debugger the exception signal blocks the execution right away. In 
>> subclasses of TestCase, it does ex pass each time you get to this line, then 
>> it enters the aMessage sentTo: self, which is not understood, then you can 
>> wait a long time...
>> 
>> 
>> It is equivalent to doing this in a playground:
>> 
>> [ Object new doStuff ] on: Exception do:[:ex| ex pass]
>> 
>> Then step in the debugger and bye bye. But then it seems to be expected 
>> behavior... or maybe not ? I mean voluntarily passing on an exception in a 
>> doesNotUnderstand would lead to such problems.
>> 
>  
> 
> I have heard at least three different stories about this bug : yours, the one 
> from fogbuzz and one other a bit different from Guille.
> 
> They seem to be different but all of them end up looping ad vitam eternam 
> after a debugger step.
> 
> I am looking for ways to reproduce any of this bugs (well except 22085), but 
> so far i have no success on my own images :'( (pharo 6.1 & 7).
> 
>  
> 
> Steven.

Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Steven Costiou]

Concerning the bug 22085, i commented on fogbuzz:

> I believe it is because when running test cases, it runs through:
> 
> runCaseForDebug: aTestCase
> [...call test code...]
> on: self class failure , self class skip, self class warning, self class error
> do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass]
> 
> So when you reach a doesNotUnderstand, you have:
> 
> doesNotUnderstand: aMessage
> [...stuff...]
> 
> resumeValue := exception signal.
> 
> ^exception reachedDefaultHandler
> ifTrue: [aMessage sentTo: self]
> ifFalse: [resumeValue]
> 
> In normal cases (class of the receiver is not a test case), when you step in 
> the debugger the exception signal blocks the execution right away. In 
> subclasses of TestCase, it does ex pass each time you get to this line, then 
> it enters the aMessage sentTo: self, which is not understood, then you can 
> wait a long time...
> 
> It is equivalent to doing this in a playground:
> 
> [ Object new doStuff ] on: Exception do:[:ex| ex pass]
> 
> Then step in the debugger and bye bye. But then it seems to be expected 
> behavior... or maybe not ? I mean voluntarily passing on an exception in a 
> doesNotUnderstand would lead to such problems.

I have heard at least three different stories about this bug : yours,
the one from fogbuzz and one other a bit different from Guille. 

They seem to be different but all of them end up looping ad vitam
eternam after a debugger step. 

I am looking for ways to reproduce any of this bugs (well except 22085),
but so far i have no success on my own images :'( (pharo 6.1 & 7). 

Steven. 

Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Tim Mackinnon]

Good point by Norbert - I should have referenced a bug - but interested in 
others experience and I will annotate that bug.

For me, this isn’t a recursion thing, it’s a dnu when restarting a method (not 
sure if many people do this - but it’s a key Smalltalk feature in my mind - so 
it should work well).

Also my image recovers fine when I shut down the debuggers.

Interested in others experience and I guess I should try and use 7 more to see 
if it’s there too.

Tim

Sent from my iPhone



Sent from my iPhone
>> On 8 Jun 2018, at 13:10, Esteban A. Maringolo  wrote:
>> 
>> On 08/06/2018 08:30, Tim Mackinnon wrote:
>> Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that 
>> if I restart a method in the debugger - particularly from a breakpoint or 
>> correcting a dnu issue the environment frequently locks up. Fearing the 
>> worst (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 
>> 10 seconds more it comes back with 30 debugger Windows typically with 
>> something like Instance of Xxxx dnu: #someMethod (which is legit as I might 
>> have a now corrupt inst bar). 
>> 
>> I understand the error, but why does it lockup and require the cmd . Dance?
>> 
>> I dont recall earlier Pharos doing this (and not other smalltalks).
>> 
>> Should I report this?
> 
> 
> It was reported years ago [1], there was a bug and an issue, and it was
> supposedly fixed, apparently it wasn't.
> 
> In some cases that recursion caused a "detachment" of the image from the
> changes, it is, the image starts complaining that it can't find the
> changes file, so all methods lose the source and you better discard that
> image without saving, because if you do, you'll never be able to
> "reattach" it.
> 
> I don't know if it is still around in Pharo 7.
> 
> 
> Regards,
> 
> [1] https://twitter.com/emaringolo/status/603939752098816000
> 
> 
> -- 
> Esteban A. Maringolo
> 

Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Esteban A. Maringolo]

On 08/06/2018 08:30, Tim Mackinnon wrote:
> Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that 
> if I restart a method in the debugger - particularly from a breakpoint or 
> correcting a dnu issue the environment frequently locks up. Fearing the worst 
> (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 
> seconds more it comes back with 30 debugger Windows typically with something 
> like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now 
> corrupt inst bar). 
> 
> I understand the error, but why does it lockup and require the cmd . Dance?
> 
> I dont recall earlier Pharos doing this (and not other smalltalks).
> 
> Should I report this?


It was reported years ago [1], there was a bug and an issue, and it was
supposedly fixed, apparently it wasn't.

In some cases that recursion caused a "detachment" of the image from the
changes, it is, the image starts complaining that it can't find the
changes file, so all methods lose the source and you better discard that
image without saving, because if you do, you'll never be able to
"reattach" it.

I don't know if it is still around in Pharo 7.


Regards,

[1] https://twitter.com/emaringolo/status/603939752098816000


-- 
Esteban A. Maringolo

Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Norbert Hartl]

> Am 08.06.2018 um 13:30 schrieb Tim Mackinnon :
> 
> Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that 
> if I restart a method in the debugger - particularly from a breakpoint or 
> correcting a dnu issue the environment frequently locks up. Fearing the worst 
> (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 
> seconds more it comes back with 30 debugger Windows typically with something 
> like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now 
> corrupt inst bar). 
> 
> I understand the error, but why does it lockup and require the cmd . Dance?
> 
> I dont recall earlier Pharos doing this (and not other smalltalks).
> 
> Should I report this?
> 
As an exercise for you. If you go to http://bugs.pharo.org 
 and enter „debugger“ in the search field, please click 
on the first entry found which should be 22085. 

Norbert

Re: [Pharo-users] Pharo 6, bad debugger behaviour

[Tim Mackinnon]

I should also mention these extra debuggers don’t have the stack either, just a 
single dnu method.

Tim

Ps thank god for close windows to right. ...

Sent from my iPhone

> On 8 Jun 2018, at 12:30, Tim Mackinnon  wrote:
> 
> Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that 
> if I restart a method in the debugger - particularly from a breakpoint or 
> correcting a dnu issue the environment frequently locks up. Fearing the worst 
> (after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 
> seconds more it comes back with 30 debugger Windows typically with something 
> like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now 
> corrupt inst bar). 
> 
> I understand the error, but why does it lockup and require the cmd . Dance?
> 
> I dont recall earlier Pharos doing this (and not other smalltalks).
> 
> Should I report this?
> 
> Tim
> 
> Sent from my iPhone
> 

[Pharo-users] Pharo 6, bad debugger behaviour

[Tim Mackinnon]

Hi, I’ve noticed lately when using a reasonably recent Pharo 6.1 setup that if 
I restart a method in the debugger - particularly from a breakpoint or 
correcting a dnu issue the environment frequently locks up. Fearing the worst 
(after a few seconds), if I repeatedly press cmd . (Say 5 times) after 10 
seconds more it comes back with 30 debugger Windows typically with something 
like Instance of Xxxx dnu: #someMethod (which is legit as I might have a now 
corrupt inst bar). 

I understand the error, but why does it lockup and require the cmd . Dance?

I dont recall earlier Pharos doing this (and not other smalltalks).

Should I report this?

Tim

Sent from my iPhone

[Pharo-users] [Issue Tracker] Please check issue tracker

[Marcus Denker]

Hi,

If you
-> submitted an issue in the past
-> have been involved in some discussion about an issue

===> please check the issue tracker.

There are many cases where e.g.
- some issue has been fixed but the issue tracker entry is not closed
- where a discussion came to a conclusion but no action happened.
- you reported issue has been fixed in the meantime but the issue 
tracker entry is still open.


https://pharo.fogbugz.com/f/filters/57/All-newest-first

We have right now 471 open issues, I am sure we can get that number down!


Marcus

Re: [Pharo-users] Why do #select:thenXxx methods not return their result

[Peter Uhnák]

>
> It only uses one temp collection, where a #select: followed by a separate
> #collect: would need two.
>


Yeah, be careful with that, because it changes the semantics of the
operation. (magine what happens when `thenDo:` operates on the original
collection and there's no intermediate collection. (I ran into this issue
many times.)

Peter