[Rd] [R] step by step debugger in R?

[Romain Francois]

[moving this to r-devel]

Robert Gentleman wrote:
> Hi,
>
> Romain Francois wrote:
>   
>> Duncan Murdoch wrote:
>>     
>>> On 5/22/2009 10:59 AM, Michael wrote:
>>>       
>>>> Really I think if there is a Visual Studio strength debugger, our
>>>> collective time spent in developing R code will be greatly reduced.
>>>>         
>>> If someone who knows how to write a debugger plugin for Eclipse wants
>>> to help, we could have that fairly easily.  All the infrastructure is
>>> there; it's the UI part that's missing.
>>>
>>> Duncan Murdoch
>>>       
>> [I've copied Mark Bravington and Robert Gentleman to the list as they
>> are likely to have views here, and I am not sure they monitor R-help]
>>
>> Hello,
>>
>> Making a front-end to debugging was one of the proposed google summer of
>> code for this year [1], it was not retained eventually, but I am still
>> motivated.
>>
>> Pretty much all infrastructure is there, and some work has been done
>> __very recently__ in R's debugging internals (ability to step up). As I
>> see it, the ability to call some sort of hook each time the debugger
>> waits for input would make it much easier for someone to write
>>     
>
>  I have still not come to an understanding of what this is supposed to do? When
> you have the browser prompt you can call any function or code you want to. There
> is no need for something special to allow you to do that.
>   
Sure. What I have in mind is something that gets __automatically__ 
called, similar to the task callback but happening right before the user 
is given the browser prompt.

>> front-ends. A recent post of mine (patch included) [2] on R-devel
>> suggested a custom prompt for browser which would do the trick, but I
>> now think that a hook would be more appropriate. Without something
>> similar to that, there is no way that I know of for making a front-end,
>> unless maybe if you embed R ... (please let me know how I am wrong)
>>     
>
>  I think you are wrong. I can't see why it is needed. The external debugger has
> lots of options for handling debugging. It can rewrite code (see examples in
> trace for how John Chambers has done this to support tracing at a location),
> which is AFAIK a pretty standard approach to writing debuggers. It can figure
> out where the break point is (made a bit easier by allowing it to put in pieces
> of text in the call to browser).  These are things the internal debugger can't do.
>
>   
Thanks. I'll have another look into that.

>> 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.
>
>   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.
>
>   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