[Bioc-devel] Confusing namespace issue with IRanges 1.99.17

2014-07-07 Thread Leonardo Collado Torres
Hello BioC-devel list,

I am currently confused on a namespace issue which I haven't been able
to solve. To reproduce this, I made the simplest example I thought of.


Step 1: make some toy data and save it on your desktop

library(IRanges)
DF - DataFrame(x = Rle(0, 10), y = Rle(1, 10))
save(DF, file=~/Desktop/DF.Rdata)

Step 2: install the toy package on R 3.1.x

library(devtools)
install_github(lcolladotor/fooPkg)
# Note that it passes R CMD check

Step 3: on a new R session run

example(foo, fooPkg)
# Change the location of DF.Rdata if necessary


You will see that when running the example, the session information is
printed listing:

other attached packages:
[1] fooPkg_0.0.1

loaded via a namespace (and not attached):
[1] BiocGenerics_0.11.3 IRanges_1.99.17 parallel_3.1.0
S4Vectors_0.1.0 stats4_3.1.0tools_3.1.0


Then the message for loading IRanges is showed, which is something I
was not expecting and thus the following session info shows:

other attached packages:
[1] IRanges_1.99.17 S4Vectors_0.1.0 BiocGenerics_0.11.3
fooPkg_0.0.1

loaded via a namespace (and not attached):
[1] stats4_3.1.0 tools_3.1.0

Meaning that IRanges, S4Vectors and BiocGenerics all went from loaded
via a namespace to other attached packages.



All the fooPkg::foo() is doing is using a mapply() to go through a
DataFrame and a list of indices to subset the data as shown at
https://github.com/lcolladotor/fooPkg/blob/master/R/foo.R#L26 That is:

res - mapply(function(x, y) { x[y] }, DF, index)

I thus thought that the only thing I would need to specify on the
namespace is to import the '[' IRanges method.

Checking with BiocCheck and codetoolsBioC suggests importing the
method for mapply() from BiocGenerics. Doing so doesn't affect things
and R still loads IRanges on that mapply() call. Importing the '['
method from S4Vectors doesn't help either. Most intriging, importing
the whole S4Vectors, BiocGenerics and IRanges still doesn't change the
fact that IRanges is loaded when evaluating the same line of code
shown above.

Any clues on what I am missing or doing wrong?



In my use case, I'm trying to keep the namespace as small as possible
(to minimize loading time) because it's for a tiny package that has a
single function. This tiny package is then loaded on a
BiocParallel::blapply() call using BiocParallel::SnowParam() which
performs much better than BiocParallel::MulticoreParam() in terms of
keeping the memory under control.




Thank you for your help!
Leo

Leonardo Collado Torres, PhD student
Department of Biostatistics
Johns Hopkins University
Bloomberg School of Public Health
Website: http://www.biostat.jhsph.edu/~lcollado/
Blog: http://lcolladotor.github.io/











Full output from running the example:




 example(foo, fooPkg)

foo ## Initial info
foo sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] fooPkg_0.0.1

loaded via a namespace (and not attached):
[1] BiocGenerics_0.11.3 IRanges_1.99.17 parallel_3.1.0
S4Vectors_0.1.0 stats4_3.1.0tools_3.1.0

foo ## Load data
foo load(~/Desktop/DF.Rdata)

foo ## Run function
foo result - foo(DF)
R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] fooPkg_0.0.1

loaded via a namespace (and not attached):
[1] BiocGenerics_0.11.3 IRanges_1.99.17 parallel_3.1.0
S4Vectors_0.1.0 stats4_3.1.0tools_3.1.0
Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following objects are masked from ‘package:parallel’:

clusterApply, clusterApplyLB, clusterCall, clusterEvalQ,
clusterExport, clusterMap, parApply, parCapply, parLapply,
parLapplyLB, parRapply, parSapply, parSapplyLB

The following object is masked from ‘package:stats’:

xtabs

The following objects are masked from ‘package:base’:

anyDuplicated, append, as.data.frame, as.vector, cbind, colnames,
do.call, duplicated, eval, evalq, Filter, Find, get,
intersect, is.unsorted, lapply, Map, mapply, match, mget, order,
paste, pmax, pmax.int, pmin, pmin.int, Position, rank,
rbind, Reduce, rep.int, rownames, sapply, setdiff, sort, table,
tapply, union, unique, unlist

R version 3.1.0 (2014-04-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] parallel  stats graphics  grDevices utils datasets
methods   base

other attached packages:
[1] IRanges_1.99.17 S4Vectors_0.1.0 BiocGenerics_0.11.3
fooPkg_0.0.1

loaded via a namespace (and not attached):
[1] stats4_3.1.0 tools_3.1.0




Re: [Rd] a question about optim.R and optim.c in R

2014-07-07 Thread Sarah Goslee
Hi,

On Mon, Jul 7, 2014 at 4:34 PM, Zhiyuan Dong zhiyuan.d...@gmail.com wrote:
 Hi, I am learning R by reading R source code.

That's very brave of you.

You might also try reading some of the documentation and contributed
documentation, like:
http://adv-r.had.co.nz/C-interface.html
and
http://cran.r-project.org/doc/manuals/r-devel/R-exts.html

Sarah


Here is one question I have
 about the optim function in R.

 The context : In the optim.R, after all the prep steps, the main function
 call call is made via :

 .External2(C_optim, par, fn1, gr1, method, con, lower, upper).

 So, it seems to me, to follow what is going on from here, that I should
 read the optim function in \src\library\stats\src\optim.c

 where it has this signature :

 SEXP optim(SEXP call, SEXP op, SEXP args, SEXP rho)

 I am not sure I follow here : In the .External2 call, we have 7 parameters
 :  par, fn1, gr1, method, con, lower, upper; This does not seem to match
 the signature of

 SEXP optim(SEXP call, SEXP op, SEXP args, SEXP rho)

 However, it seems (from the source code) that the 7 parameters are somehow
 embedded in the 'args' parameter. I am not sure what is going on...Am I
 missing something?

 Thanks much!!!

 Best,

 Zhiyuan


-- 
Sarah Goslee
http://www.functionaldiversity.org

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


Re: [Rd] a question about optim.R and optim.c in R

2014-07-07 Thread Michael Weylandt


 On Jul 7, 2014, at 4:34 PM, Zhiyuan Dong zhiyuan.d...@gmail.com wrote:
 
 Hi, I am learning R by reading R source code. Here is one question I have
 about the optim function in R.
 
 The context : In the optim.R, after all the prep steps, the main function
 call call is made via :
 
 .External2(C_optim, par, fn1, gr1, method, con, lower, upper).
 
 So, it seems to me, to follow what is going on from here, that I should
 read the optim function in \src\library\stats\src\optim.c
 
 where it has this signature :
 
 SEXP optim(SEXP call, SEXP op, SEXP args, SEXP rho)
 
 I am not sure I follow here : In the .External2 call, we have 7 parameters
 :  par, fn1, gr1, method, con, lower, upper; This does not seem to match
 the signature of
 
 SEXP optim(SEXP call, SEXP op, SEXP args, SEXP rho)
 
 However, it seems (from the source code) that the 7 parameters are somehow
 embedded in the 'args' parameter. I am not sure what is going on...Am I
 missing something?
 

IIRC, args is a pairlist object. If the analogy helps, it's something like the 
OO pattern of sticking all your function parameters in an argument and passing 
that instead of passing them all as formals. One advantage of this is sane(er) 
handling of variadic functions at the C level. 

Michael


 Thanks much!!!
 
 Best,
 
 Zhiyuan
 
[[alternative HTML version deleted]]
 
 __
 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