[Rd] Standalone C++ application for processing R parser output(SEXP)

[Rob Anderson]

Hi All,

I am trying to write a source-to-source compiler for R. I am trying to
leverage the R parser code for the purpose. I am trying to transform the
SEXP returned from the parser into an AST for our own Ruby embedded Domain
specific language.

I tried using R CMD SHBIN to compile a C function that parses arbitrary R
expressions. But I think, the generated .so file can be used from within R
and not be called from other C or Ruby programs(I get linker errors).

My Idea  is to use the SEXP processing functions/MACROS (CAR, CDR, CADR,
etc..) from within C code and transform it to our AST format. I tried
linking to libR.a and other lib*.so's when I compile the C code using gcc
but, it doesn't work.

I read that R exposes only small number of functions for library/package
writers and the compiled *.so can only from within R.

Any ideas on what is wrong, or how I can go about it?

Appreciate any help.

Thanks
RJ

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Standalone C++ application for processing R parser output(SEXP)

[Rob Anderson]

Thanks a lot guys. I'll try out what you suggested.

Thanks,
RJ

On Thu, Mar 24, 2011 at 8:46 AM, Dirk Eddelbuettel  wrote:

>
> On 24 March 2011 at 08:08, Duncan Murdoch wrote:
> | On 11-03-23 7:35 PM, Rob Anderson wrote:
> | > Hi All,
> | >
> | > I am trying to write a source-to-source compiler for R. I am trying to
> | > leverage the R parser code for the purpose. I am trying to transform
> the
> | > SEXP returned from the parser into an AST for our own Ruby embedded
> Domain
> | > specific language.
> | >
> | > I tried using R CMD SHBIN to compile a C function that parses arbitrary
> R
> | > expressions. But I think, the generated .so file can be used from
> within R
> | > and not be called from other C or Ruby programs(I get linker errors).
> | >
> | > My Idea  is to use the SEXP processing functions/MACROS (CAR, CDR,
> CADR,
> | > etc..) from within C code and transform it to our AST format. I tried
> | > linking to libR.a and other lib*.so's when I compile the C code using
> gcc
> | > but, it doesn't work.
> | >
> | > I read that R exposes only small number of functions for
> library/package
> | > writers and the compiled *.so can only from within R.
> | >
> | > Any ideas on what is wrong, or how I can go about it?
> |
> | I think you need to think of your program as a new front end for R, even
> | if you're only using a few R functions.  See Chapter 8 in the Writing R
> | Extensions manual.
>
> Maybe also have a look at the parser package by Romain at
>
> https://r-forge.r-project.org/R/?group_id=384
>
> (and scroll down sufficiently on that page) which has the description
>
> parser - Detailed R source code parser
>
> detailed source code parser, based on the standard R parser but
> organizing the information differently
>
> which strikes me as close enough to what you describe. That said, Romain
> did
> this for highlight so it may not be relevant.
>
> Dirk
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Accessing ENVSXP and CLOSXP while processing parsed R code

[Rob Anderson]

Hello Guys,

Following up my earlier mail where I am trying to write an alternative
front-end for R,  I had a question about accessing the closures and
environments in R code.

Here's the function taken  and modified a little from "*Lexical Scope and
Statistical Computing*"

=
f<-function(){
  Rmlfun<-function(x){
sumx  <-  sum(x)
n <-  length(x)
function(mu)
  n*log(mu)-mu*sumx
  }
  efun  <-Rmlfun(1:10)
  y1  <-  efun(3)
  print(y1)
  efun2  <-  Rmlfun(20:30)
  y2  <-  efun2(3)
  print(y2)
}
=

Now assignment efun  <-Rmlfun(1:10) creates a closure where
*function(mu) n*log(mu)-mu*sumx *is returned and *sumx* and *n *are added
to the existing environment.

I can parse the code using *PROTECT(e =
R_ParseVector(tmp,1,&status,R_NilValue));* where tmp is the buffer
containing the same source. I can walk the resultant parser output and
build and alternative Abstract syntax tree(AST).

I would like to include the information about closure/environments in my
AST so that I can possibly do some optimizations.

My question is, how can I get hold of this information?

One thing I noticed while 'walking' through the parser output, I never
encounter a CLOSXP (which I check using TYPEOF()) , even though in the
above code, closure is created. Is it the case that this information is
meant just for the internal "eval*" function and not exposed application
writers?

Thanks,
Rob

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Question on parsing R code from C

[Rob Anderson]

Hi,

With respect to initializing R state and parsing, you might want to look at
the "Linking GUI's and other front-ends to R" section in Writing R
Extensions .

Once the initialization is done, you can use mkString() function to get an
input SEXP from a C character buffer(your R code). Calling R_ParseVector()
with this SEXP as input will give you the parsed output. It works for me.

Thanks,
Rob

On Tue, Nov 8, 2011 at 6:53 PM, KR  wrote:

> Simon Urbanek  r-project.org> writes:
> > Except that you don't know what are macros, inlined functions and actual
> functions. If you are careful you
> > can possibly fall back to external functions but, obviously, your code
> will be
> less efficient. I would
> > still prefer including Rinternals.h - you must have a *really* good
> reason to
> not do so ;)
>
> Hmmm yes there are good motives (I am not completely unreasonable, yet :P)
> but I
> could probably cope with it if there is no other way.
>
> Regarding the rest of the e-mail, please let me be clearer on what my goal
> is. I
> would need a function to create and initialize an R state, a function to
> close
> the state, and a function (R_ParseVector?) that takes as input the R state
> and a
> string (containing R code), evaluates the code and return an "error code"
> (error, incomplete, done) plus (eventually) a string containing the output
> of
> the computation.
>
> In my application I do not have any UI elements (it's console based), but I
> would like calls to plot in R (and other functions using the graphic
> device) to
> function as they would under R.exe (on windows), i.e. have persistent
> windows
> popped up which you can resize ecc ecc. I naively thought that these
> graphic
> capabilities came automatically with the R_ParseVector via some threading
> techniques.
>
> Thanks for all your comments!
>
>
> Cheers
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accessing ENVSXP and CLOSXP while processing parsed R code

[Rob Anderson]

Thanks! that was useful

Rob

On Mon, Nov 7, 2011 at 6:49 AM, Duncan Murdoch wrote:

> On 11-11-07 5:24 AM, Rob Anderson wrote:
>
>> Hello Guys,
>>
>> Following up my earlier mail where I am trying to write an alternative
>> front-end for R,  I had a question about accessing the closures and
>> environments in R code.
>>
>> Here's the function taken  and modified a little from "*Lexical Scope and
>> Statistical Computing*"
>>
>>
>> ==**==**=
>> f<-function(){
>>   Rmlfun<-function(x){
>> sumx<-  sum(x)
>> n<-  length(x)
>> function(mu)
>>   n*log(mu)-mu*sumx
>>   }
>>   efun<-Rmlfun(1:10)
>>   y1<-  efun(3)
>>   print(y1)
>>   efun2<-  Rmlfun(20:30)
>>   y2<-  efun2(3)
>>   print(y2)
>> }
>> ==**==**=
>>
>> Now assignment efun<-Rmlfun(1:10) creates a closure where
>> *function(mu) n*log(mu)-mu*sumx *is returned and *sumx* and *n *are added
>> to the existing environment.
>>
>
> That's not correct.  When you call Rmlfun, an evaluation frame
> (environment) is created.  It contains the argument x.  Then sumx and n are
> added to it.  Then the anonymous closure is created, with body
> n*log(mu)-mu*sumx, and the closure's environment is the evaluation frame
> from the call to Rmlfun.
>
>
>
>> I can parse the code using *PROTECT(e =
>> R_ParseVector(tmp,1,&status,R_**NilValue));* where tmp is the buffer
>>
>> containing the same source. I can walk the resultant parser output and
>> build and alternative Abstract syntax tree(AST).
>>
>> I would like to include the information about closure/environments in my
>> AST so that I can possibly do some optimizations.
>>
>
> It's not there, except potentially.  When you call the function "function"
> to create the closure, that's when the closure is created. That doesn't
> happen at parse time.  Rmlfun is created when you evaluate f() and then the
> anonymous function is created when you call Rmlfun() within it.
>
>
>
>> My question is, how can I get hold of this information?
>>
>> One thing I noticed while 'walking' through the parser output, I never
>> encounter a CLOSXP (which I check using TYPEOF()) , even though in the
>> above code, closure is created. Is it the case that this information is
>> meant just for the internal "eval*" function and not exposed application
>> writers?
>>
>
> No, there's nothing hidden, it just didn't exist at the time you were
> looking for it.
>
> Duncan Murdoch
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Multithreaded code in .Call interface

[Rob Anderson]

Hi,

I was wondering if it is safe to call R functions and/or R BLAS functions
from within multithreaded C/C++ code(.Call interface)? It is not in case
with MATLAB. I was experimenting  using pthreads and OpenMP.

Thanks,
Rob

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Multithreaded code in .Call interface

[Rob Anderson]

Thanks for the reply.

Rob

On Sat, Oct 13, 2012 at 1:57 AM, Prof Brian Ripley wrote:

> On 13/10/2012 08:09, Rob Anderson wrote:
>
>> Hi,
>>
>> I was wondering if it is safe to call R functions and/or R BLAS functions
>> from within multithreaded C/C++ code(.Call interface)? It is not in case
>> with MATLAB. I was experimenting  using pthreads and OpenMP.
>>
>
> Not unless it is documented to be so.  (I believe the internal BLAS to be
> fine, but you could use an external one: although with care if that also
> uses threads.)
>
> See also §8.1.5 of 'Writing R Extensions'.
>
>  Thanks,
>> Rob
>>
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  
> http://www.stats.ox.ac.uk/~**ripley/<http://www.stats.ox.ac.uk/~ripley/>
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel