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 debugfixpc.7.cs.gz (3K) Download Attachment |
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 <[hidden email]> 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 > > > |
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 [hidden email] 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 |
In reply to this post by Chris Muller-3
Added an explanation pane to shed some light on
mysteries like #to:by:do:. Also an addition to the code pane menu
to look at the debugger map.
https://dl.dropboxusercontent.com/u/28914094/debugfixpc.10.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 [hidden email] 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 |
Free forum by Nabble | Edit this page |