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.