A little further experimentation.

- dropped some of the invisible nodes related to #to:by:do: to avoid 
some odd text selections (Debugger test002)
- dropped the abstract pc concept since it doesn't seem to be doing 
anything useful at the moment

https://dl.dropboxusercontent.com/u/28914094/debugfixpc.9.cs.gz

Cheers,
Bob
On 9/9/13 9:09 PM, Chris Muller wrote:
> The difference between the two is, on this line:
>
>      1 = 2 ifFalse: [self class].
>
> you have to press Step twice on the class message, which is actually
> disconcerting for debugging Smalltalk.  bobsWay is definitely how it
> should be.
>
> It'd also be really nice if we could fix the "Code Simulation Error"
> when stepping Through..
>
>
> On Mon, Sep 9, 2013 at 6:21 PM, Bob Arning <arning315 at comcast.net> wrote:
>> A small filein to look at a debugger issue. From the preamble:
>>
>> I'm trying to understand some of the anomalies in what the debugger shows
>> for each step. New versions of two methods in DebuggerMethodMap are added
>> (they can be toggled in and out). Try evaluating
>>
>> Debugger bobsWay: true; test001
>> and
>> Debugger bobsWay: false; test001
>>
>> and step [Over] until the end of the method. I think the bobsWay: true gives
>> better debugging, but I'm not sure if that holds true everywhere else.
>>
>> The problem seems to be a slight mismatch in pc's between what the encoder
>> thinks is useful and what the debugger actually stops on, with the
>> additional wrinkle of translating concrete pc's to abstract thrown in.
>>
>>
>> Cheers,
>> Bob
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130910/41be941b/attachment.htm