In answer to Viral's question the purpose of RCall.jl is to link to the R API directly from Julia instead of writing "glue" code in C. I decided to do a clean room implementation rather than build on Rif.jl because I was (mistakenly) concerned about the license on Rif.jl
Some of the goals are: - use dep/build.jl to determine the location of libR.so and suitable values for various environment variables expected by R - reflect the internal structure of R objects in a templated Julia type. - provide easy access to data sets from R packages. There is code to do this in DataFrames/src/RDA.jl but that depends upon reproducing the entire decoding mechanism for saved R objects in Julia. I think the easier way to do this is to use R to decode its own save format and just pick up the values from R. This will also provide an alternative to using the RDatasets package. - provide a reference implementation for the formula/data representation to produce ModelFrame and ModelMatrix objects. - allow access to R packages. Ultimately I would like RCall to be as complete as PyCall but that would probably require participation by other more skilled than me. On Tuesday, January 6, 2015 12:28:51 AM UTC-6, Randy Lai wrote: > > Hi all, > > > Sorry for joining the game late, I have been very busy in the past few > days. > > > > First of all, I am very excited to learn that RCall.jl is now alive at > JuliaStats. To resolve the confusion between the package names of my > original package and the one hosted on JuliaStats, I renamed my original > package and now it is called “RCalling.jl”. > > > https://github.com/randy3k/RCalling.jl > > > > I have a brief look of what Douglas have been doing in the new repo of > RCall.jl. > > His direction in porting all R API functions from C to Julia may allow > further development of the R/Julia interface easier. > > In contrest, in RCalling.jl, I have been using the Julia API (in C) and R > API (of course, also in C) intensively, which actually make coding > difficult and hard to be maintained. > > > It is good to have more people playing the game. > > Please let me know how I could be helping in the development of the > package. > > > Best > > > Randy > > On Friday, January 2, 2015 11:59:04 AM UTC-8, Douglas Bates wrote: >> >> For many statistics-oriented Julia users there is a great advantage in >> being able to piggy-back on R development and to use at least the data sets >> from R packages. Hence the RDatasets package and the read_rda function in >> the DataFrames package for reading saved R data. >> >> Over the last couple of days I have been experimenting with running an >> embedded R within Julia and calling R functions from Julia. This is similar >> in scope to the Rif package except that this code is written in Julia and >> not as a set of wrapper functions written in C. The R API is a C API and, >> in some ways, very simple. Everything in R is represented as a "symbolic >> expression" or SEXPREC and passed around as pointers to such expressions >> (called an SEXP type). Most functions take one or more SEXP values as >> arguments and return an SEXP. >> >> I have avoided reading the code for Rif for two reasons: >> 1. It is GPL3 licensed >> 2. I already know a fair bit of the R API and where to find API function >> signatures. >> >> Here's a simple example >> julia> initR() >> 1 >> >> julia> globalEnv = unsafe_load(cglobal((:R_GlobalEnv,libR),SEXP),1) >> Ptr{Void} @0x0000000008c1c388 >> >> julia> formaldehyde = tryEval(install(:Formaldehyde)) >> Ptr{Void} @0x0000000008fd1d18 >> >> julia> inherits(formaldehyde,"data.frame") >> true >> >> julia> printValue(formaldehyde) >> carb optden >> 1 0.1 0.086 >> 2 0.3 0.269 >> 3 0.5 0.446 >> 4 0.6 0.538 >> 5 0.7 0.626 >> 6 0.9 0.782 >> >> julia> length(formaldehyde) >> 2 >> >> julia> names(formaldehyde) >> 2-element Array{ASCIIString,1}: >> "carb" >> "optden" >> >> julia> form1 = ccall((:VECTOR_ELT,libR),SEXP,(SEXP,Cint),formaldehyde,0) >> Ptr{Void} @0x000000000a5baf58 >> >> julia> ccall((:TYPEOF,libR),Cint,(SEXP,),form1) >> 14 >> >> julia> carb = >> copy(pointer_to_array(ccall((:REAL,libR),Ptr{Cdouble},(SEXP,),form1),length(form1))) >> 6-element Array{Float64,1}: >> 0.1 >> 0.3 >> 0.5 >> 0.6 >> 0.7 >> 0.9 >> >> julia> form2 = ccall((:VECTOR_ELT,libR),SEXP,(SEXP,Cint),formaldehyde,1) >> Ptr{Void} @0x000000000a5baef0 >> >> julia> ccall((:TYPEOF,libR),Cint,(SEXP,),form2) >> 14 >> >> julia> optden = >> copy(pointer_to_array(ccall((:REAL,libR),Ptr{Cdouble},(SEXP,),form2),length(form2))) >> 6-element Array{Float64,1}: >> 0.086 >> 0.269 >> 0.446 >> 0.538 >> 0.626 >> 0.782 >> >> >> A call to printValue uses the R printing mechanism. >> >> Questions: >> - What would be a good name for such a package? In the spirit of PyCall >> it could be RCall or Rcall perhaps. >> >> - Right now I am defining several functions that emulate the names of >> functions in R itself ir in the R API. What is a good balance? Obviously >> it would not be a good idea to bring in all the names in the R base >> namespace. On the other hand, those who know names like "inherits" and >> what it means in R will find it convenient to have such names in such a >> package. >> >> - Should I move the discussion the the julia-stats list? >> >>
