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

Simon Urbanek simon.urbanek at r-project.org
Mon May 25 11:19:28 CEST 2009 

On May 24, 2009, at 10:18 AM, Romain Francois wrote:

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

Yes - it would be quite useless otherwise ;)  there are many examples  
of GUIs that use it (including the built-in ones [Windows, MAc, ..] or  
external ones e.g JGR).

Cheers,
S


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

More information about the R-devel mailing list