[Rd] internal and external debugging [was: [R] step by step debugger in R?]

[Mark.Bravington at csiro.au]

Hello all

I'm coming late to this discussion, and my comments may now be beside the point-- but I have been intending to ask what people think of the pros & cons of internal and external (e.g. 'debug' package) debuggers. When I wrote 'debug', the internal debugger just didn't do what I wanted, but maybe things have changed-- hence this email, to find out. The particular facilities in 'debug' that I'm thinking of, are

   - Graceful error trapping. In 'debug', I can just run til it crashes, then figure out what's up and carry on if desired-- often in conjunction with...
   
   - 'skip', to move the execution point around. I use this all the time, often after a graceful error trap, to replace a dodgy bit of code with the correct version, and then skip round the bad version to carry on.
   
   - the conditional breakpoint facilities, including debugging of on-exit code.
 
Can these be done with internal debugging?
 
The main negative issues I have seen with 'debug' are:

   - very clunky tcl/tk interface, and inability to see proper source code;

   - (occasionally) speed-- although this can often be gotten round with a bit of ingenuity;

   - some more "special cases" that I should add, e.g. to trace into 'try' statements;

   - a few maggots in the code barrel due to changes in R over the years.
   
I try to catch up with the 3rd & 4th from time to time, and would be very happy if anyone can help with the 1st (Romain did already offer as part of summer-of-code, though the project didn't get up).

If anyone has other thoughts on bad things in, or good things not in, 'debug', then I would consider adding them.
   
Finally, my 2c from experience with 'debug': writing it was very hard work. Debugger-writing seems to be a case where one can one can get *something* working quite quickly-- and then get sucked in to a very long and painful process. The effort I spent has been repaid many times over, but...

Mark Bravington

CSIRO, Hobart, Australia

> >> There is also the debug package [3,4] which does __not__ work with R
> >> internals but rather works with instrumenting tricks at the R level.
> >> debug provides a tcl/tk front-end. It is my understanding that it does
> >> not work using R internals (do_browser, ...) because it was not possible
> >> at the time, and I believe this is still not possible today, but I might
> >> be wrong. I'd prefer to be wrong actually.
> >>    
> >
> >   I don't understand this statement. It has always been possible to work with
> > the internal version - but one can also take the approach of rewriting code.
> > There are some difficulties supporting all the operations that one would like by
> > rewriting code and I think a combination of external controls and the internal
> > debugger will get most of the functionality that anyone wants.
> >  
> 
> I understand now the confusion. I meant that the debug package does not
> use functions like debug and browser. I think this is because once you
> enter into "browser", only the user gets the right to type commands in,
> and there is a need for (for example) automatically updating the editor
> when a given breakpoint is reached, ...
> 
> I did not mean that R internal debugging failed to work.
> 
> >   There are somethings that are hard and once I have a more complete list I will
> > be adding this to the appropriate manual. I will also be documenting the changes
> > that I have been making, but that project is in flux and won't be done until the
> > end of August, so people who want to look at it are welcome (it is in R-devel),
> > but it is in development and could change pretty much without notice.
> >   Romain noted that we now support stepping out from one place to another
> > function.  We also have a debugonce flag that lets you get close to step in, but
> > step in is very hard in R.
> >
> >   I am mostly interested in writing tools in R that can be used by anyone that
> > wants to write an external debugger and am not that interested in any particular
> > external debugger. I would be happy to listen to feature requests or issues that
> > arise - but the discussion should probably be on R-devel mailing list.
> >  
> I am very interested in making one (or very likely several) front-ends
> using these tools.
> 
> 
> >   best wishes
> >     Robert
> >
> >
> >  
> >> Romain
> >>
> >> [1] : http://www.r-project.org/soc09/ideas.html#p5
> >> [2] : https://stat.ethz.ch/pipermail/r-devel/2009-April/053128.html
> >> [3] : http://cran.r-project.org/web/packages/debug/index.html
> >> [4] : http://cran.r-project.org/doc/Rnews/Rnews_2003-3.pdf
> >>
> >>    
> >
> >  
> 
> 
> -- 
> Romain Francois
> Independent R Consultant
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
>