[Rd] Am I missing something about debugging?

[Ross Boylan]

On Tue, 2007-01-02 at 18:44 -0500, Duncan Murdoch wrote:
> On 1/2/2007 5:46 PM, Ross Boylan wrote:
.... 
> > The smalltalk debugger is the standard by which I judge all others; it's
> > just amazing.  You can go up and down the stack, graphically examine
> > variables (and follow links), and change code in the middle of debugging
> > and then continue.
> 
> Everything except the "change code" part is pretty standard in a modern 
> debugger; I'd hope an R debugger could do them.  An interpreter like R 
> could allow changes, but I'm not sure what the user interface would look 
> like...
> 
> Duncan Murdoch
At least in MS Visual C++ a few years ago and gdb today, data tend not
to be presented in immediately digestible form.  For a list or vector,
one gets the pointers and counts in the header, rather than the list
itself (and then if the objects are themselves complex (e.g.,
std::string!), you have the problem of seeing bits rather than semantics
recursively).  And I think neither put you inside an environment in
which you can do general operations in the language, such as invoking
methods on objects.  The R browser already has that last feature.  And I
see I left it out of my original list, which was focused more on stuff
not in the R debugger.  Interactive function invocation immediately
allows friendlier presentation, since one can print or show any object
in the browser (print or show being among the methods one can invoke).

I think ddd lets you graphically navigate your data.

Visual C++ and maybe gdb/gcc are also moving to providing "edit and
continue" functionality in which you can change code and
recompile/relink on the fly.  It's kind of brittle; for example if you
change the object layout or really anything in the ABI, you can edit
but you can't continue.

In contrast, smalltalk is pretty good about even such tough cases as
redefining the slots (in R's lingo) of a class.  For methods, if you are
in c, called from b, called from a, and you redefine b, the debugger
won't let you continue in b or c, but it will allow you to restart b and
continue from there.  And if you stopped in b, you're free to redefine c
and then continue the execution, which will go into the new c code
(oops, a function named "c" written in smalltalk).
-- 
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               ross at biostat.ucsf.edu
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062