R devel - May 2009 - internal and external debugging [was: [R] step by step debugger in R?]

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
>

Hi,

Thank you for these comments. I think it does indeed add to the 
discussion and provides a good reference. I have added a few comments below.

Mark.Bravington at csiro.au wrote:
> 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...
>   
options( error = recover ) lets you examine what did cause the crash. 
AFAIK, it does not let you carry on.
>    
>    - '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.
>   
I am not sure I understand completely here, but I think the new 
facilities implemented by Robert Gentleman are going in this direction. 
once in a browser, you can use browserSetDebug to jump up one or more 
frames in the stack.
>    
>    - the conditional breakpoint facilities, including debugging of on-exit
code.
>   
browser now (in R-devel) has a "expr" argument that I think controls 
whether to actually enter the browser or not.

Also, with the work Duncan Murdoch has been doing recently on keeping 
the srcref records as part of the stack, we are not too far from the 
ability to create breakpoints without actually typing in "browser()"
in
the code, i.e. something similar to trace(...,at=) where at would not be 
a step in the list of expressions of the function but a srcref record. 
This would great from a visual debugger point of view.

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

-- 
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr