From lgautier at gmail.com  Mon May  4 18:46:22 2015
From: lgautier at gmail.com (Laurent Gautier)
Date: Mon, 4 May 2015 12:46:22 -0400
Subject: [Rd] C-API: check whether R has been initialized ?
In-Reply-To: <C1374C0D-7F92-4268-A8CD-69E4631823DC@r-project.org>
References: <CA+JCgN12YVXnWggr1PTfp81U6Bg3=4ARatOdfNh8wZXM_Aes8g@mail.gmail.com>
	<55469D5B.5030701@gmail.com>
	<CA+JCgN3VW3qe+dDMyfSRJEAUdv-kjjG--HHwwbZk5isH8=oVAQ@mail.gmail.com>
	<5546B3B7.4010407@gmail.com>
	<CA+JCgN131Ar-1phKdNX7yqxO4QmmEZUQdFLZ8JGg6nrev0Tp2g@mail.gmail.com>
	<C1374C0D-7F92-4268-A8CD-69E4631823DC@r-project.org>
Message-ID: <CA+JCgN1ZbteMNqMEmZP_TWRvbXDVrXxxdEMvEAE-vYJoOHWhng@mail.gmail.com>

On May 4, 2015 12:06 AM, "Simon Urbanek" <simon.urbanek at r-project.org>
wrote:
>
> Laurent,
>
> On May 3, 2015, at 8:07 PM, Laurent Gautier <lgautier at gmail.com> wrote:
>
> > rPython appears to provide an interface from R to Python by embedding
> > Python and I'd think that it can safely assume that R has been
initialized,
> > but might not be the point here.
> >
> > The issue is that a Python package embedding itself R (here rpy2)
appears
> > to have no way to know that earlier in the life of the process R was
> > initialized.
> >
>
> Duncan's point was that it has - since it would have to embed R itself
and thus record the initialization. I suppose you're asking about a case
where you want to detect that something else already started R so you can't
embed it yourself anymore and thus have to abort -- one side-effect check
is to see if R_NilValue is NULL since that would only be the case if R was
not started yet.

The nesting of embedded Rs is obviously conceptual since the R C library
will only be found once in a process address space. The testing would allow
to keep that coherence (as far as rpy2 is concerned R is embedded, although
if coming from say rPython R has already been started).

If checking R_NilValue is the way to test whether R has been initialized,
why isn't R using it rather than have its own variable (and that variable
jealously made unreadable from this thread) ?

Also, I would necessarily want to abort if R has already been initialized.
One can think about it as a stateful library, and I should be able to just
skip the initialization and go on.

> Note, however, that if you didn't initialize it you can't embed it.
>
> Cheers,
> Simon
>
> PS: there are much better interfaces to Python than rPython (which is
mostly dysfunctional) - see
> http://www.omegahat.org/RSPython
> https://github.com/s-u/rpython

I am seeing rpy2 as way to run R code from Python, and while I may have
preferences about how and what to run I am trying to make running any R
code possible.

> PPS: I wish you didn't hide the capsulling in rpy2 since that prevents us
from having common references that rpy2 can use (please contact me off the
list).

The way it is generally working is that you contact me about wishes for
rpy2.

Think of the precedent it would make and the rather entertaining replies to
posts such as "I wish feature X in R was different, please contact me at
your earliest convenience with a proposal and an aggressive timeline"
blooming on R-dev would trigger.
;-)

Joke aside, personal email is fine but unless there is a reason not to I
like to use the issue tracker on bitbucket so the discussion and reason for
a decision can be consulted by all.

PS: I have unpublished code playing with R's internals from Python were the
opacity of the capsule made me provide access to pointers. May be I should
clean that up and try to integrate it.
>
> > 2015-05-03 19:48 GMT-04:00 Duncan Murdoch <murdoch.duncan at gmail.com>:
> >
> >> On 03/05/2015 7:02 PM, Laurent Gautier wrote:
> >>> Beside the possible argumentation that with an API elegance and
> >>> convenience might sometimes be superior to necessity, the suggested
> >>> pattern ("every program, including R itself, keeping its own flag")
does
> >>> no work too well when the nested embedding of R is involved.
> >>>
> >>> A concrete example is:
> >>> ```
> >>> $ R -q
> >>>> library('rPython'); python.exec('import rpy2.robjects')
> >>> R is already initialized
> >>> ```
> >>
> >> I don't know rPython at all, but surely this is an rPython bug.  When
> >> the package is loaded by "library('rPython')", R is obviously
> >> initialized.  You don't need to query it to ask that.
> >>
> >> The standard R front-ends don't need a flag to know if it is
> >> initialized.  They initialize, then go into the read-eval-print loop.
> >> If they are in that loop, R is initialized.  If it failed to
initialize,
> >> they would never get to that loop.
> >>
> >> Other front-ends may do other things besides run R, so they do need to
> >> know if it is initialized, but surely they can keep a flag telling them
> >> whether they've succeeded in initializing it.
> >>
> >> Duncan Murdoch
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

	[[alternative HTML version deleted]]



[Rd] C-API: check whether R has been initialized ?
Laurent Gautier