Re: [Rd] How to (appropropriately) use require in a package?

[Joshua Wiley]

Dear Professor Ripley,

PkgB does not need to be on the search path---importing into the namespace
is fine.  I did not realize that namespace scoping ensured that if a
cluster is created from within a package, that packages entire environment
tree is available on all the workers.
I tried to apply how makeCluster works from an interactive R session, where
functions from packages that are loaded when the cluster is created are not
available on the workers, to how it works from within a package.

Thanks for your reply,

Josh



On Fri, Aug 8, 2014 at 4:47 PM, Prof Brian Ripley 
wrote:

> The safe, elegant way to do this is to use namespace scoping: it is still
> not at all clear why 'other code' needs PkgB *on the search path*.
>
> In other cases seen in CRAN submissions, 'other code' has been in PkgA's
> namespace, and hence things in PkgB's exports have been visible as it was
> imported by PkgA and hence in the environment tree for functions in PkgA.
>  Then namespace scoping will ensure that PkgB's namespace is loaded on the
> cluster workers.
>
>
>
> On 08/08/2014 00:58, Joshua Wiley wrote:
>
>> Someone kindly pointed out that it is not clear from my email why Depends
>> will not work.  A more complete example is:
>>
>> PkgA:
>> f <- function(ncores) {
>>cl <- makeCluster(ncores)
>>
>>clusterEvalQ(cl, {
>>  require(PkgB)
>>})
>>[other code]
>>
>>### this is the code I want to work and need to be able to call
>>### PkgB functions on each of the cluster slaves
>>output <- parLapply(cl, 1:n, function(i) {
>>  [code from my package and using some functions from PkgB]
>>})
>>
>> }
>>
>> As far as I know, just because I add PkgB to the Depends (or imports,
>> whatever) of PkgA, does not mean that the cluster started by PkgA will
>> automatically have PkgB loaded and functions available.
>>
>> Thanks!
>>
>>
>>
>> On Fri, Aug 8, 2014 at 9:35 AM, Joshua Wiley 
>> wrote:
>>
>>  Dear All,
>>>
>>> What is the preferred way for Package A, to initialize a cluster, and
>>> load
>>> Package B on all nodes?
>>>
>>> I am writing a package that parallelizes some functions through the use
>>> of
>>> a cluster if useRs are on a Windows machine (using parLapply and family).
>>>   I also make use of another package in some of my code, so it is
>>> necessary
>>> to load the required packages on each slave once the cluster is started.
>>>
>>> Right now, I have done this, by evaluating require(packages) on each
>>> slave; however, Rcmd check has a note that I should remove the "require"
>>> in
>>> my code.
>>>
>>> Thanks!
>>>
>>> Josh
>>>
>>> --
>>> Joshua F. Wiley
>>> Ph.D. Student, UCLA Department of Psychology
>>> http://joshuawiley.com/
>>> Senior Analyst, Elkhart Group Ltd.
>>> http://elkhartgroup.com
>>> Office: 260.673.5518
>>>
>>>
>>
>>
>>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  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
>



-- 
Joshua F. Wiley
Ph.D. Student, UCLA Department of Psychology
http://joshuawiley.com/
Senior Analyst, Elkhart Group Ltd.
http://elkhartgroup.com
Office: 260.673.5518

[[alternative HTML version deleted]]

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

[Rd] could not find function "anyNA" when building tools package in R 3.1.1

[Benjamin Tyner]

Hello,

When building R from source, during the part where the 'tools' package
is built, I get:

make[6]: Entering directory `/home/btyner/R-3.1.1/src/library/tools/src'
make[6]: Leaving directory `/home/btyner/R-3.1.1/src/library/tools/src'
make[5]: Leaving directory `/home/btyner/R-3.1.1/src/library/tools/src'
make[4]: Leaving directory `/home/btyner/R-3.1.1/src/library/tools'
Error in .deparseOpts(control) : could not find function "anyNA"
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> 
Execution halted
make[3]: *** [all] Error 1
make[3]: Leaving directory `/home/btyner/R-3.1.1/src/library/tools'
make[2]: *** [R] Error 1
make[2]: Leaving directory `/home/btyner/R-3.1.1/src/library'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/home/btyner/R-3.1.1/src'
make: *** [R] Error 1

wondering if anyone has seen this before or has any suggestions as to
what the problem could be? Here is some platform information:

uname -m = x86_64
uname -r = 2.6.32-358.18.1.el6.x86_64
uname -s = Linux

Happy to provide more info as needed.

Regards
Ben


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

Re: [Rd] RFC: diag(x, n) not preserving integer and logical x

[Duncan Murdoch]

On 07/08/2014, 4:51 AM, Martin Maechler wrote:
> This is not at all something new(*). As maintainer of the
> Matrix  package, I don't like this inconsistency of base R's diag().
> We have had the following -- forever, almost surely inherited
> from S and S+  :
> 
> diag(x) preserves the storage mode of x  for  'complex' and
> 'double' precision,  but converts integer and logicals to double :
> 
>   > storage.mode(x <- 1i + 1:7); storage.mode(diag(x))
>   [1] "complex"
>   [1] "complex"
>   > storage.mode(x <- 0 + 1:7);  storage.mode(diag(x))
>   [1] "double"
>   [1] "double"
> 
>   > storage.mode(x <- 1:7);  storage.mode(diag(x))
>   [1] "integer"
>   [1] "double"
>   > storage.mode(x <- 1:7 > 3);  storage.mode(diag(x))
>   [1] "logical"
>   [1] "double"
> 
> and so it is actually a bit cumbersome (and a memory waste in
> the case of large matrices) to create a diagonal integer or
> logical matrix.
> 
> The help page does not mention the current behavior, though you
> may say it alludes to the fact that logicals are treated as 0/1
> implicitly (**)
> 

I think the change to preserve integer makes sense, but preserving
logical does not.  A diagonal matrix has zeros off the diagonal, and
they are not logical.  Having diag() sometimes return a matrix with
FALSE off the diagonal just looks wrong.

Duncan Murdoch

> If I change this behavior such that logical and integer x are
> preserved,
> 
>   make check-all
> 
> which includes all checks, including those of all recommended
> packages (including Matrix!) successfully runs through; so at
> least  base + Recommended R never relies on the current
> behavior, nor should any "well programmed" R code ...
> 
> Hence my proposal, somewhat tentative for now,
> to change this  diag(.) behavior.
> 
> Martin Maechler
> 
> *) and possibly something we "can not" change in R, because too
>much code implicitely may be depending on it,  but now I hope
>we can still...
> 
> **) BTW, also including the somewhat amusing case of diag(c("A","B")).
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

[Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Uwe Ligges]

Dear maintainers and R-devel,

Several orphaned CRAN packages are about to be archived due to 
outstanding QC problems, but have CRAN and BioC packages depending on 
them which would be broken by the archival (and hence need archiving 
alongside).
Therefore we are looking for new maintainers taking over maintainership 
for one or more of the following packages:


R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

Package maintainers whose packages depend on one of these may be natural 
candidates to become new maintainers.
Hence this messages is addressed to all these maintainers via BCC and to 
R-devel.


See

  
  
  
  
  
  
  
  
  

for information on the QC issues and the reverse dependencies.

Best wishes,
Uwe Ligges
(for the CRAN team)

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

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Hin-Tak Leung]

At least as far as I am concerned, I'll remove dependency on hexbin, if it 
comes to that.
The dependency is only used in some vignettes, and quite non-essential, and 
perhaps,
undesirable, in fact.


On Fri, 8/8/14, Uwe Ligges  wrote:

 Subject: Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin 
lgtdl monreg muhaz operators pamr
 To: "R-Devel" 
 Cc: "CRAN" 
 Date: Friday, 8 August, 2014, 17:41

 Dear maintainers and R-devel,

 Several orphaned CRAN packages are about to be archived due
 to 
 outstanding QC problems, but have CRAN and BioC packages
 depending on 
 them which would be broken by the archival (and hence need
 archiving 
 alongside).
 Therefore we are looking for new maintainers taking over
 maintainership 
 for one or more of the following packages:

 R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators
 pamr

 Package maintainers whose packages depend on one of these
 may be natural 
 candidates to become new maintainers.
 Hence this messages is addressed to all these maintainers
 via BCC and to 
 R-devel.

 See

    
    
    
    
    
    
    
    
    

 for information on the QC issues and the reverse
 dependencies.

 Best wishes,
 Uwe Ligges
 (for the CRAN team)

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