Re: [Rd] Am I missing something about debugging?

From: Ross Boylan <>
Date: Wed 03 Jan 2007 - 00:29:43 GMT

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                     
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062

______________________________________________ mailing list
Received on Wed Jan 03 11:34:02 2007

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Wed 03 Jan 2007 - 01:31:07 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.