From ellis at stat.harvard.edu  Wed Jan  3 02:06:06 2007
From: ellis at stat.harvard.edu (Byron Ellis)
Date: Tue, 2 Jan 2007 17:06:06 -0800
Subject: [Rd] Am I missing something about debugging?
In-Reply-To: <1167784183.21960.99.camel@iron.psg.net>
References: <1167775737.21960.49.camel@iron.psg.net>
	<459ADBA3.6050800@stats.uwo.ca>
	<1167777966.21960.58.camel@iron.psg.net>
	<459AEE56.9000503@stats.uwo.ca>
	<1167784183.21960.99.camel@iron.psg.net>
Message-ID: <7098abec0701021706re570830v577ce66c8234730c@mail.gmail.com>

While a Smalltalk-style debugger would be pretty awesome, I suspect
R's semantics would make restartable exceptions pretty difficult and
R's current implementation would make getting the continuation-like
object you'd need pretty difficult, at least across the range of
platforms supported by R.

A solution, of course, would be to implement R's interpreter in
Smalltalk as a domain-specific language. Vista Smalltalk apparently
hosts a Lisp/Scheme interpreter and I know of at least one Lisp
implementation for Squeak, which serve as pretty good starting points
for an S-like language. :-)

On 1/2/07, Ross Boylan <ross at biostat.ucsf.edu> wrote:
> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Byron Ellis (byron.ellis at gmail.com)
"Oook" -- The Librarian



[Rd] Am I missing something about debugging?
Byron Ellis