[FR-devel] Re: Brainstorming on FreeRIDE debugger

[Alun ap Rhisiart]

Hi Laurent,

> A - Push-button and/or command line
I think push buttons are fine for standard debugger operations, step 
over, step into, return, continue.

>Other ideas?
Well, since you asked....
Have you seen the VA Smalltalk debugger? You see the method you are 
stepping through in one pane (at the bottom), and the top is divided 
into three panes: one on the left gives the call stack, so you can 
quickly go up and down through the methods and find out where you are. 
The middle pane gives the local variables that are in scope for the 
selected method in the stack frame, and when you select one of the 
variables the value appears in the top right frame. This last is itself 
an edit pane, meaning that you can 'inspect' variables, and type in 
messages to call against a variable and run it.
   In the main method pane, you can select bits of the code and run them 
(either execute, execute and display the result, or execute and open an 
inspector on the result). You can also change the code in this pane, and 
re-run the method with the changed code immediately. Many people write a 
lot of the program in the debugger in this way. Now this is all hardly 
possible in many languages, but should be in another dynamically-typed 
one like ruby, although some things may need a VM, with things like 
CompiledMethod available as objects too. I think the point is that an 
edit pane in the smalltalk environment can be used to immediately 
execute selected parts of the code, browse a class if you select the 
class name, etc. This same pane is used by the debugger. The statement 
that will execute next is selected (rather than an arrow in the margin, 
since you can have several statements in a line).
  Finally, for breakpoints, they are not simply breakpoints. You click 
in the left margin to set a breakpoint, and a dot appears there, as you 
have suggested. If you double-click the dot a window opens. You can 
leave a breakpoint in place but inactive (you can also globally set all 
breakpoints in/active). You can specify the iteration, eg break the 3rd 
time the breakpoint is hit, not every time (very useful for loops). Even 
when active, a breakpoint doesn't necessarily break, it executes the 
statements associated with the breakpoint; if the last statement returns 
'true' then it breaks and you are in the debugger. The statements can be 
arbitrary, as long as the last returns a boolean. eg, you can type 
'Transcript show: "some variable is: ' aVar; false". The program will 
continue executing, but you will print out the value of aVar onto the 
console each time the breakpoint is hit.
  Sorry for the long-winded explanation, I just thought some people on 
the list may not be smalltalkers, and not have seen this.
  Now, obviously this is pretty advanced functionality, and nobody would 
expect any of it in the first few releases, but I thought it worth 
mentioning as a possible goal to work towards.

Alun