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

Thu May 28 09:32:00 CEST 2009

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