[R] step by step debugger in R?

[John Lindsey]

As a newbie I'm trying to figure out how much more than RKWard does is 
wanted. The code turns colors as syntax is checked and errors are noted. 
It seems like a reasonable IDE. Maybe someone is looking for the same in 
windows?

John F Lindsey
803-790-5006 Home , 803-790-5008 Cell
919-439-9088 Home Office
3850 Northshore Rd., Columbia,SC 29206-3350
John.F.Lindsey at Gmail.com , John-Lindsey at SC.RR.COM 
http://www.linkedin.com/in/johnlindseysc




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