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

Sun May 24 10:18:17 CEST 2009

Robert Gentleman wrote:
> Hi,
>   I stripped the cc's as I believe that all read this list.
>
> Romain Francois wrote:
>   
>> [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.
>>     
>
>  I am trying to understand the scenario you have in mind. Is it that the user is
> running R directly and your debugger is essentially a helper function that gets
> updated etc as R runs?
>   
yes. there are now several ui toolkits that could be use to give some 
sort of graphical representation of what is being debugged.

I agree with you that and IDE should command R and not the other way 
around, but I am not (yet) here talking about a fully featured IDE, but 
simply a debugger.

I need to read more about embedding R (as in section 8 of WRE). I know 
you can supply your own implementation of the REPL, but I am not sure 
this includes the one that goes on once trapped into the browser. For 
example littler ships its own REPL, but this does not seem to fool/deal 
with browser:

$ r -e "print(1:10); browser(); print(1:5) "
 [1]  1  2  3  4  5  6  7  8  9 10
Called from: NULL
c
 [1]  1  2  3  4  5

Not sure this is an omission of Jeffrey and Dirk or something else.

>  If so, then I don't think that works very well and given the constraints we
> have with R I don't think it will be able to solve many of the problems that an
> IDE should.  The hook you want will give you some functionality, but no where
> near enough.
>   

In the long run, I do agree. In the short run, I'd prefer taking the bus 
to the airport rather than walk.

>  Let me suggest instead that the IDE should be running the show. It should
> initialize an instance of R, but it controls all communication and hence
> controls what is rendered on the client side.  If that is what you mean by
> embedding R, then yes that is what is needed. There is no way that I can see to
> support most of the things that IDE type debuggers support without the IDE
> controlling the communication with R.
>
>  And if I am wrong about what your debugger will look like please let me know.
>
>  best wishes
>    Robert
>
>
>   
>>>> 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