[Pharo-users] Pharo 6, bad debugger behaviour
tim at testit.works
Fri Jun 8 09:33:41 EDT 2018
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.
Sent from my iPhone
Sent from my iPhone
>> On 8 Jun 2018, at 13:10, Esteban A. Maringolo <emaringolo at gmail.com> 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 , 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.
>  https://twitter.com/emaringolo/status/603939752098816000
> Esteban A. Maringolo
More information about the Pharo-users