Re: [R-pkg-devel] Visible bindings and reference classes

On Tue, 11 Aug 2015, William Dunlap wrote: You can avoid the temporary file by replacing dput(def, file= (tf <- tempfile())) compiler::cmpfile(tf) with cdef <- compiler::compile(def) #Note: no visible binding for '<<-' assignment to 'ConfigString' The compiled code appears to work. eval(cde

Re: [R-pkg-devel] Visible bindings and reference classes

On Tue, 11 Aug 2015, Colin Gillespie wrote: To your question: Reference classes are used in *many* places, and the use of ' <<- ' is really "standard" there. e.g., package 'lme4', or 'pcalg' are two packages I'm involved with, which use ref.classes and ' <<- ' but are "fine" with that. So

Re: [R-pkg-devel] not resolved from current namespace error

renaming did the trick! Now I can create the library but the parallel part is not working (things are much slower in parallel). I will try to figure that out next. Is this a good list to ask R + Fortran + MPI questions or should I go to a different place? Thanks! On Tue, Aug 11, 2015 at 2:21 PM

Re: [R-pkg-devel] not resolved from current namespace error

Not sure, but your problem might be answered in the .Fortran() help page: All Fortran compilers known to be usable to compile R map symbol names to > lower case, and so does .Fortran. > I've been caught by that before, and found that using all lowercase names for Fortran routines in R is safest.

[R-pkg-devel] not resolved from current namespace error

I'm trying to create a package that uses a MPI Fortran module. I have a working version of that package that uses a Fortran module without MPI. When I run the function `FMPIpi(DARTS = 5000, ROUNDS = 100, cores=2)` I get the following errors: > FMPIpi(DARTS = 50

Re: [R-pkg-devel] CRAN submission which requires third party software?

On 11 August 2015 at 11:49, Charles Determan wrote: | I am beginning to reach the completion of a new package I would like to | submit to CRAN. However, there are a few aspects of it that I would like | some guidance prior to submitting. | | 1. It requires some third party software (i.e. an Open

[R-pkg-devel] CRAN submission which requires third party software?

I am beginning to reach the completion of a new package I would like to submit to CRAN. However, there are a few aspects of it that I would like some guidance prior to submitting. 1. It requires some third party software (i.e. an OpenCL SDK) to be installed before it will compile (it contains c++

Re: [R-pkg-devel] Visible bindings and reference classes

You can avoid the temporary file by replacing dput(def, file= (tf <- tempfile())) compiler::cmpfile(tf) with cdef <- compiler::compile(def) #Note: no visible binding for '<<-' assignment to 'ConfigString' The compiled code appears to work. eval(cdef) c1 <- Config$new() c1 #Reference

Re: [R-pkg-devel] Visible bindings and reference classes

This is a problem in the compiler package. Here is a way to reproduce it: def <- quote(Config <- setRefClass("Config", fields = list( ConfigString = "character"), methods = list( # Constructor initialize = function() { ConfigString <<- "Hello, World!"

Re: [R-pkg-devel] Visible bindings and reference classes

> > > To your question: > > Reference classes are used in *many* places, and the use of ' <<- ' > is really "standard" there. > e.g., package 'lme4', or 'pcalg' are two packages I'm involved with, > which use ref.classes and ' <<- ' but are "fine" with that. > > So there must be something peculi

Re: [R-pkg-devel] Visible bindings and reference classes

> Colin Gillespie > on Mon, 10 Aug 2015 20:33:32 + writes: > Dear All, > > I have a package that uses reference classes. When I build the package I > get numerous notes of the sort > > Note: no visible binding for '<<-' assignment to 'pars' > > I've tried using GlobalVariables,

Re: [R-pkg-devel] Working with connections - What is correct?

On Mon, Aug 10, 2015 at 10:18 PM, Glenn Schultz wrote: > Hi Dirk, > Thanks for your response, I get the point on return(). For me, it is a > security blanket - I just need to let that go rather than justify keeping > it. I will refactor the connections and just get comfortable without > return().