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 > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
