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 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
