Re: [R] step by step debugger in R?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Robert Gentleman
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?

 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.

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

--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Romain Francois
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Simon Urbanek

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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Romain Francois
Simon Urbanek wrote:

>
> [snip]
>>
>> 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
>
Hi Simon,

Do you mean the rReadConsole callback ? I managed to make some minor
modifications to the rtest.java example that comes with JRI to somewhat
emulate automatically call some code (ls.str()) in this example at the
browser prompt, before giving the prompt to the user.

    static boolean browse_first = true ;  
      public String rReadConsole(Rengine re, String prompt, int
addToHistory) {
        System.out.print(prompt);
                if( prompt.startsWith( "Browse[") ){
                        if( browse_first ){
                            System.out.println( "\n>>>> re.eval( \"
print( ls.str() )\" ); " ) ;
                            re.eval( "print( ls.str() )" ) ;
                            browse_first = false ;
                            System.out.println( "\n>>>> return
\"ls.str()\"" ) ;
                            return "ls.str()\n" ;
                        } else{
                            browse_first = true ;
                        }
                       
                }
...
}

It seems to work and could get me somewhere, although it has a "it
works, but it does not feel right" taste. Basically the code pretends
the user typed "ls.str\n" at the browse prompt, so that the R evaluator
evaluates it, and then comes back to the browse prompt.

There is also the re.eval( "print( ls.str() )" ) part which was my first
attempt, but apparently this gets evaluated in the global environment,
which is no good. I can get around that by returning some sort of
"record the sys.frames and sys.calls somewhere and do something with
them" function, but I was wondering if you meant something else.

Romain

Here is the transcript of a simple session of ./run rtest (with the
small adjustement above)

 > f <- function( x= 5) browser()
rBusy(1)
rBusy(0)
 > f()
rBusy(1)
Called from: f()
rBusy(0)
Browse[1]>
 >>>> re.eval( " print( ls.str() )" );
a :  chr "hello"
b : 'data.frame':    3 obs. of  2 variables:
 $ a: num  1.2 2.3 4.5
 $ b: num  1.4 2.6 4.2
bool :  logi [1:3] TRUE FALSE FALSE
f : function (x = 5)
iris : 'data.frame':    150 obs. of  5 variables:
 $ Sepal.Length: num  5.1 4.9 4.7 4.6 5 5.4 4.6 5 4.4 4.9 ...
 $ Sepal.Width : num  3.5 3 3.2 3.1 3.6 3.9 3.4 3.4 2.9 3.1 ...
 $ Petal.Length: num  1.4 1.4 1.3 1.5 1.4 1.7 1.4 1.5 1.4 1.5 ...
 $ Petal.Width : num  0.2 0.2 0.2 0.2 0.2 0.4 0.3 0.2 0.2 0.1 ...
 $ Species     : Factor w/ 3 levels "setosa","versicolor",..: 1 1 1 1 1
1 1 1 1 1 ...

 >>>> return "ls.str()"
rBusy(1)
x :  num 5
rBusy(0)
Browse[1]>
rBusy(0)
 >



--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Simon Urbanek

On May 25, 2009, at 4:54 PM, Romain Francois wrote:

> Simon Urbanek wrote:
>>
>> [snip]
>>>
>>> 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
>>
> Hi Simon,
>
> Do you mean the rReadConsole callback ? I managed to make some minor  
> modifications to the rtest.java example that comes with JRI to  
> somewhat emulate automatically call some code (ls.str()) in this  
> example at the browser prompt, before giving the prompt to the user.
>
>   static boolean browse_first = true ;       public String  
> rReadConsole(Rengine re, String prompt, int addToHistory) {
>       System.out.print(prompt);
>               if( prompt.startsWith( "Browse[") ){
>                       if( browse_first ){
>                           System.out.println( "\n>>>> re.eval( \"  
> print( ls.str() )\" ); " ) ;
>                           re.eval( "print( ls.str() )" ) ;
>                           browse_first = false ;
>                           System.out.println( "\n>>>> return  
> \"ls.str()\"" ) ;
>                           return "ls.str()\n" ;
>                       } else{
>                           browse_first = true ;
>                       }
>                                     }
> ...
> }
>
> It seems to work and could get me somewhere, although it has a "it  
> works, but it does not feel right" taste. Basically the code  
> pretends the user typed "ls.str\n" at the browse prompt, so that the  
> R evaluator evaluates it, and then comes back to the browse prompt.
>
> There is also the re.eval( "print( ls.str() )" ) part which was my  
> first attempt, but apparently this gets evaluated in the global  
> environment, which is no good. I can get around that by returning  
> some sort of "record the sys.frames and sys.calls somewhere and do  
> something with them" function, but I was wondering if you meant  
> something else.
>

Well, it's entirely up to you - the REPL is working. I wasn't  
suggesting you have to use JRI for the debugger, I was just pointing  
out that browsing is treated as a regular prompt on the REPL, so any  
embedding has access to it.
The JRI eval() command has nothing to do with this directly - you can  
evaluate in any environment, just not specifying anything will throw  
you in the global environment - it's really up to you (it just  
abstracts out the direct access to parse and eval part of R - you can  
(ab)use it any way you see fit).

Cheers,
Simon


> Romain
>
> Here is the transcript of a simple session of ./run rtest (with the  
> small adjustement above)
>
> > f <- function( x= 5) browser()
> rBusy(1)
> rBusy(0)
> > f()
> rBusy(1)
> Called from: f()
> rBusy(0)
> Browse[1]>
> >>>> re.eval( " print( ls.str() )" );
> a :  chr "hello"
> b : 'data.frame':    3 obs. of  2 variables:
> $ a: num  1.2 2.3 4.5
> $ b: num  1.4 2.6 4.2
> bool :  logi [1:3] TRUE FALSE FALSE
> f : function (x = 5) iris : 'data.frame':    150 obs. of  5 variables:
> $ Sepal.Length: num  5.1 4.9 4.7 4.6 5 5.4 4.6 5 4.4 4.9 ...
> $ Sepal.Width : num  3.5 3 3.2 3.1 3.6 3.9 3.4 3.4 2.9 3.1 ...
> $ Petal.Length: num  1.4 1.4 1.3 1.5 1.4 1.7 1.4 1.5 1.4 1.5 ...
> $ Petal.Width : num  0.2 0.2 0.2 0.2 0.2 0.4 0.3 0.2 0.2 0.1 ...
> $ Species     : Factor w/ 3 levels "setosa","versicolor",..: 1 1 1 1  
> 1 1 1 1 1 1 ...
>
> >>>> return "ls.str()"
> rBusy(1)
> x :  num 5
> rBusy(0)
> Browse[1]>
> rBusy(0)
> >
>
>
>
> --
> Romain Francois
> Independent R Consultant
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [R] step by step debugger in R?

Romain Francois
Simon Urbanek wrote:

>
>
> On May 25, 2009, at 4:54 PM, Romain Francois wrote:
>
>> Simon Urbanek wrote:
>>>
>>> [snip]
>>>>
>>>> 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
>>>
>> Hi Simon,
>>
>> Do you mean the rReadConsole callback ? I managed to make some minor
>> modifications to the rtest.java example that comes with JRI to
>> somewhat emulate automatically call some code (ls.str()) in this
>> example at the browser prompt, before giving the prompt to the user.
>>
>>   static boolean browse_first = true ;       public String
>> rReadConsole(Rengine re, String prompt, int addToHistory) {
>>       System.out.print(prompt);
>>               if( prompt.startsWith( "Browse[") ){
>>                       if( browse_first ){
>>                           System.out.println( "\n>>>> re.eval( \"
>> print( ls.str() )\" ); " ) ;
>>                           re.eval( "print( ls.str() )" ) ;
>>                           browse_first = false ;
>>                           System.out.println( "\n>>>> return
>> \"ls.str()\"" ) ;
>>                           return "ls.str()\n" ;
>>                       } else{
>>                           browse_first = true ;
>>                       }
>>                                     }
>> ...
>> }
>>
>> It seems to work and could get me somewhere, although it has a "it
>> works, but it does not feel right" taste. Basically the code pretends
>> the user typed "ls.str\n" at the browse prompt, so that the R
>> evaluator evaluates it, and then comes back to the browse prompt.
>>
>> There is also the re.eval( "print( ls.str() )" ) part which was my
>> first attempt, but apparently this gets evaluated in the global
>> environment, which is no good. I can get around that by returning
>> some sort of "record the sys.frames and sys.calls somewhere and do
>> something with them" function, but I was wondering if you meant
>> something else.

Thank you for these comments. It confirms what I was thinking.

>
> Well, it's entirely up to you - the REPL is working. I wasn't
> suggesting you have to use JRI for the debugger, I was just pointing
> out that browsing is treated as a regular prompt on the REPL, so any
> embedding has access to it.

I understand that. It was the quickest way for me to get an example
going. java/JRI is one option, but there are others (Qt, ...)

> The JRI eval() command has nothing to do with this directly - you can
> evaluate in any environment, just not specifying anything will throw
> you in the global environment - it's really up to you (it just
> abstracts out the direct access to parse and eval part of R - you can
> (ab)use it any way you see fit).

... and I surely will.

Romain

>
> Cheers,
> Simon
>
>
>> Romain
>>
>> Here is the transcript of a simple session of ./run rtest (with the
>> small adjustement above)
>>
>> > f <- function( x= 5) browser()
>> rBusy(1)
>> rBusy(0)
>> > f()
>> rBusy(1)
>> Called from: f()
>> rBusy(0)
>> Browse[1]>
>> >>>> re.eval( " print( ls.str() )" );
>> a :  chr "hello"
>> b : 'data.frame':    3 obs. of  2 variables:
>> $ a: num  1.2 2.3 4.5
>> $ b: num  1.4 2.6 4.2
>> bool :  logi [1:3] TRUE FALSE FALSE
>> f : function (x = 5) iris : 'data.frame':    150 obs. of  5 variables:
>> $ Sepal.Length: num  5.1 4.9 4.7 4.6 5 5.4 4.6 5 4.4 4.9 ...
>> $ Sepal.Width : num  3.5 3 3.2 3.1 3.6 3.9 3.4 3.4 2.9 3.1 ...
>> $ Petal.Length: num  1.4 1.4 1.3 1.5 1.4 1.7 1.4 1.5 1.4 1.5 ...
>> $ Petal.Width : num  0.2 0.2 0.2 0.2 0.2 0.4 0.3 0.2 0.2 0.1 ...
>> $ Species     : Factor w/ 3 levels "setosa","versicolor",..: 1 1 1 1
>> 1 1 1 1 1 1 ...
>>
>> >>>> return "ls.str()"
>> rBusy(1)
>> x :  num 5
>> rBusy(0)
>> Browse[1]>
>> rBusy(0)
>> >
>>
>>
>>
>> --
>> Romain Francois
>> Independent R Consultant
>> +33(0) 6 28 91 30 30
>> http://romainfrancois.blog.free.fr
>>
>>
>>
>
>
>


--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel