Nathaniel Smith wrote:
> Can I butt in for a moment and ask why we'd even want q() not to exit?
> There is (unfortunately) no way to create and destroy multiple R
> sessions, because R doesn't have such a capability. Even if there
> were, I don't see what q() would have to do with it -- the right API
> for creating and destroying sessions would be more like
> my_r = rpy2.R()
> # ... do stuff with my_r ...
> del my_r
> or whatever. There is an rpy2.rinterface.endEmbeddedR() which tries to
> clean up the R data structures without exiting the process; the only
> problem is that you can't re-initialize R afterwards.
Technically, one can re-initialize but it leads to an unusable embedded R.
The suspected reason is that R is using global variables and various
stateful initialization procedure (that should only be run once), and
the termination code I could find does not seem to bother about that.
Options to get it to work are:
- file R API functions to handle that as a wish to R developers
- trace everything R is doing to initialize and terminate and make one's
own function
I'd be happy if anyone wants to work this out, but it is otherwise not
the highest on my priority list.
> q() is a function for exiting the process, just like sys._exit or the
> C exit() function or whatever. If you call any of them the process
> will exit. This makes sense if you think about it...
>
> If you're just worried about users accidentally calling q() and being
> surprised by the results, it'd be easier to just say
> r('q <- function(...) { "Don't press the red button!" }')
> or whatever at startup.
This is precisely what setting a cleanup function is offering, just
ensuring that your custom checkpoint on the way to the exit is reached
(''' q <- function(...) { <whatever> } ''' is only adding a function q()
in the globalenv; baseenv['q']() would still call the original function).
One of the use-cases for setting a cleanup function is for example if
you are building an application and want to offer an R console, but want
to prevent the user (or run python-level cleanup) from terminating the
application from the console.
> In conclusion, I don't get it :-)
I am not any better than Nathaniel: without you telling a little more of
what you are trying to achieve, I am left puzzled.
L.
> -- Nathaniel
>
> On Sat, Jul 4, 2009 at 2:46 PM, Daniel Yuan<dy...@jhmi.edu> wrote:
>>> I have just added something in the documentation for 2.1-dev
>>> http://rpy.sourceforge.net/rpy2/doc-dev/html/callbacks.html#clean-up
>>> That will hopefully be enough to get you started.
>> Still no joy:
>>
>> xn...@work:~> python
>> Python 2.5.2 (r252:60911, Nov 26 2008, 00:44:29)
>> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import rpy2.rinterface
>> >>> rpy2.rinterface.initr()
>> 0
>> >>> q = rpy2.rinterface.baseenv['q']
>> >>> q()
>> xn...@work:~>
>>
>> The problem is not one of cleaning up the R namespace, as with a
>> '.Last' or '.Last.sys' function in R (which I don't have), but of
>> keeping the python interpreter alive after R quits.
>>
>> - Daniel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> rpy-list mailing list
>> rpy-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rpy-list
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> rpy-list mailing list
> rpy-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rpy-list
------------------------------------------------------------------------------
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
