The following works for me:
module RCall
module R
import ..RCall
export foo
function foo()
RCall.bar()
end
end # R
export R
function bar()
println("hello, handsome!")
end
end
Now, I can do
using RCall
R.foo()
"hello, handsome!"
I didn’t manage to get it working with using instead of import in the inner
module, though, but that only affects your own usage of your own code, so I
think that’s a minor issue.
// T
On Monday, January 5, 2015 10:50:04 PM UTC+1, Douglas Bates wrote:
The (unregistered) [RCall](https://github.com/JuliaStats/RCall.jl) package
> is an initial cut at the interface. I am not happy with all the names that
> I chose and welcome suggestions of improvements. For some reason I was
> unable to create an R module within the RCall module, as Stefan suggested.
> Again, I welcome suggestions of how to accomplish this. My particular
> difficulty is that if I create an R module within the RCall module I don't
> see the names from RCall.
>
>
> On Saturday, January 3, 2015 12:56:48 PM UTC-6, lgautier wrote:
>>
>> I agree.
>> RCall does provide consistency, although at the possible slight cost of
>> boring conformity, and seems a better choice than RStats.
>>
>> On Saturday, January 3, 2015 8:31:42 AM UTC-5, Viral Shah wrote:
>>>
>>> I prefer Rcall.jl, for consistency with ccall, PyCall, JavaCall, etc.
>>> Also, once in JuliaStats, it will probably also be well advertised and
>>> documented - so finding it should not be a challenge, IMO.
>>>
>>> -viral
>>>
>>> On Saturday, January 3, 2015 10:16:51 AM UTC+5:30, Ismael VC wrote:
>>>>
>>>> +1 for RStats.jl, I also think it's more search-friendly but not only
>>>> for people coming from R.
>>>>
>>>> On Fri, Jan 2, 2015 at 9:50 PM, Gray Calhoun <[email protected]>
>>>> wrote:
>>>>
>>>>> That sounds great! Rcall.jl or RCall.jl are fine names; RStats.jl may
>>>>> be slightly more search-friendly for people coming from R, since they may
>>>>> not know about PyCall.
>>>>>
>>>>>
>>>>> On Friday, January 2, 2015 1:59:04 PM UTC-6, 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?
>>>>>>
>>>>>>
>>>>
