Re: [Bioc-devel] Size limits of packages when including other executables
On Thu, Jun 6, 2013 at 1:48 AM, Thomas Dybdal Pedersen thomas...@gmail.com wrote: Hi I'm developing a wrapper for the peptide-identification tool MS GF+. The algorithm is developed in Java and the .jar file has a size around 20 mb. For the ease of the user, I think it would make sense to pack the java code together with the wrapper (this has been cleared with the MS GF+ developer), and would have the added benefit of securing version compatibility. This, on the other hand, stretches the size limits imposed in the guidelines by several factors… What is the opinion on this? Is the size limits set in stone or can they be lifted for certain cases besides annotation packages? We generally do frown on this, you're right, but if you're sure all the classes in the JAR are necessary, then we'll allow it. What's more important than getting buy-in from the developer of the Java code is finding out what license the Java code is written under, making sure that is compatible with the license of the R package, and acknowledging the Java license as well as the R license in your package. See the licensing section of the Writing R Extensions manual for more information. Note that some licenses require that all source code be either in the package, or that a link be provided that points to it; this would apply to your jar file (which presumably contains only .class files and no Java source). Dan best Thomas Pedersen, PhD student at DTU, Denmark ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] biomaRt::getBM column names
Hi Steffen -- getBM now returns the 'description' rather than 'name' of biomaRt columns, e.g., mart - useMart(ensembl) datasets - listDatasets(mart) mart-useDataset(hsapiens_gene_ensembl,mart) df - getBM(attributes=c(affy_hg_u95av2, hgnc_symbol, chromosome_name , band), filters=affy_hg_u95av2,values=c(1939_at,1503_at,1454_at),, mart=mart) returns df ## devel Affy HG U95AV2 probeset HGNC symbol Chromosome Name Band 1 1939_atTP53 17 p13.1 2 1503_at BRCA2 13 q13.1 3 1454_at SMAD3 15 q22.33 rather than df ## release affy_hg_u95av2 hgnc_symbol chromosome_name band 11939_atTP53 17 p13.1 21503_at BRCA2 13 q13.1 31454_at SMAD3 15 q22.33 This makes it difficult to access columns via df$... (breaking code in at least a couple of packages) and it is a little confusing to ask for 'affy_hg_u95av2' but get 'Affy HG U95AV2 probeset'. I wonder if the original behaviour could be offered, either as an option or as a similarly named function, or (my preference) the new behavior could be provided by something like getBiomart() -- fancy function name for fancy column names? Martin -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Rd] Question about writing portable packages
Dear R-devel list, I am creating an R package that includes C++ code. I tried to install it both in Linux and Windows and it worked. I load the C code via the NAMESPACE file using useDynLib. Now I am revising once again whether everything is ready before submitting the package to CRAN and I have read in http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages that “It is not portable to call compiled code in R or other packages via .Internal, .C, .Fortran, .Call or .External, since such interfaces are subject to change without notice and will probably result in your code terminating the R process”. However, the R function of my package that calls the C++ code uses the Call function. Does it mean that I cannot submit my package to CRAN because the portability is not guaranteed?. Then, how could I to call C++ code so that my package were portable?. I hope you can clarify my doubts. I have seen the collection of prior postings to the list, but I have not found a specifical answer to my doubts . Thank you very much in advance. Best regards, Guillermo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about writing portable packages
Guillermo, That phrase is referring to using .Call in your package to call a C function that shipped with a DIFFERENT package or is part of R itself (defined in the R source code). As long as you are only calling C functions you define in the C++ code that ships with your package you are fine. ~G On Thu, Jun 6, 2013 at 6:54 AM, guillermo.vi...@uv.es wrote: Dear R-devel list, I am creating an R package that includes C++ code. I tried to install it both in Linux and Windows and it worked. I load the C code via the NAMESPACE file using useDynLib. Now I am revising once again whether everything is ready before submitting the package to CRAN and I have read in http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages that It is not portable to call compiled code in R or other packages via .Internal, .C, .Fortran, .Call or .External, since such interfaces are subject to change without notice and will probably result in your code terminating the R process. However, the R function of my package that calls the C++ code uses the Call function. Does it mean that I cannot submit my package to CRAN because the portability is not guaranteed?. Then, how could I to call C++ code so that my package were portable?. I hope you can clarify my doubts. I have seen the collection of prior postings to the list, but I have not found a specifical answer to my doubts . Thank you very much in advance. Best regards, Guillermo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about writing portable packages
Dear Kevin, Berwin and Gabriel, Thank you very much for your detailed and clear answers. According to your comments, in a few days I will submit my package to CRAN. I would also like to take this opportunity to thank all the R-devel list for being a wonderful place to discuss and clarify doubts about R. Best wishes, Guillermo Guillermo, That phrase is referring to using .Call in your package to call a C function that shipped with a DIFFERENT package or is part of R itself (defined in the R source code). As long as you are only calling C functions you define in the C++ code that ships with your package you are fine. ~G On Thu, Jun 6, 2013 at 6:54 AM, guillermo.vi...@uv.es wrote: Dear R-devel list, I am creating an R package that includes C++ code. I tried to install it both in Linux and Windows and it worked. I load the C code via the NAMESPACE file using useDynLib. Now I am revising once again whether everything is ready before submitting the package to CRAN and I have read in http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages that “It is not portable to call compiled code in R or other packages via .Internal, .C, .Fortran, .Call or .External, since such interfaces are subject to change without notice and will probably result in your code terminating the R process”. However, the R function of my package that calls the C++ code uses the Call function. Does it mean that I cannot submit my package to CRAN because the portability is not guaranteed?. Then, how could I to call C++ code so that my package were portable?. I hope you can clarify my doubts. I have seen the collection of prior postings to the list, but I have not found a specifical answer to my doubts . Thank you very much in advance. Best regards, Guillermo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Gabriel Becker Graduate Student Statistics Department University of California, Davis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about writing portable packages
I think the key word here is _other_ packages. It's entirely okay to call your package's own compiled code through the .Call interface (and the code you write may link to other packages; the obvious example being Rcpp code you write); however, it is not portable to use .Call to call compiled code from another package directly. This is because package authors are not required to maintain a consistent .Call interface to their compiled code; rather, they just have to make sure the direct user-facing R exported functions retain a stable interface over different versions (or, if changed, are done so with prior warning etc.) Ultimately, if your package passes 'R CMD check' with no errors, warnings or notes, you should be okay for CRAN submission. -Kevin On Thu, Jun 6, 2013 at 6:54 AM, guillermo.vi...@uv.es wrote: Dear R-devel list, I am creating an R package that includes C++ code. I tried to install it both in Linux and Windows and it worked. I load the C code via the NAMESPACE file using useDynLib. Now I am revising once again whether everything is ready before submitting the package to CRAN and I have read in http://cran.r-project.org/doc/manuals/R-exts.html#Writing-portable-packages that It is not portable to call compiled code in R or other packages via .Internal, .C, .Fortran, .Call or .External, since such interfaces are subject to change without notice and will probably result in your code terminating the R process. However, the R function of my package that calls the C++ code uses the Call function. Does it mean that I cannot submit my package to CRAN because the portability is not guaranteed?. Then, how could I to call C++ code so that my package were portable?. I hope you can clarify my doubts. I have seen the collection of prior postings to the list, but I have not found a specifical answer to my doubts . Thank you very much in advance. Best regards, Guillermo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- -Kevin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Rcpp-devel] Setting the R random seed from Rcpp
This would be easier if base::set.seed() accepted a value of .Random.seed instead of just a scalar integer or, new to R-3.0.0, NULL. If set.seed() returned the previous value of .Random.seed (NULL if there was no previous value) things might be even easier. People should not have to know where .Random.seed is stored. S+'s set.seed() accepts a value of .Random.seed but does not return the previous value. (If it is given an illegal value for .Random.seed it complains and sets it to a random value.) Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com -Original Message- From: rcpp-devel-boun...@lists.r-forge.r-project.org [mailto:rcpp-devel- boun...@lists.r-forge.r-project.org] On Behalf Of Romain Francois Sent: Friday, June 07, 2013 7:42 AM To: Matteo Fasiolo Cc: rcpp-de...@lists.r-forge.r-project.org Subject: Re: [Rcpp-devel] Setting the R random seed from Rcpp You can do something like this (i'm on my phone, so you might have to change it): Environment g = Environment::global_env() ; Environment::Binding RandomSeed = g[.Random.seed] ; You get the current value of the binding like this: NumericVector someVariable = RandomSeed ; And then when you want to set the variable: you just do : RandomSeed = someVariable ; The Environment::Binding class acts a a proxy class. Romain Le 7 juin 2013 à 16:22, Matteo Fasiolo matteo.fasi...@gmail.com a écrit : Dear Rcpp experts, I would like to be able to store the R random seed from a Rcpp function and then reset it. In other words I would like to replicate the following code in Rcpp: savedSeed - .Random.seed x - Rfunction(parameters1); .Random.seed - savedSeed x1 - Rfunction(parameters2); where Rfunction simulates some random numbers and uses them but with different parameter values. Is it possible to do something similar in Rcpp? Probably using GetRNGstate() and PutRNGstate()? Thanks, Matteo ___ Rcpp-devel mailing list rcpp-de...@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel ___ Rcpp-devel mailing list rcpp-de...@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] col2rgb, factors documentation
Hello Core Folk. Quite by accident I discovered today that col2rgb, when fed factors, acts on the integer representation of those factors: td - as.factor(rainbow(5)) # not how I discovered the issue! td res - col2rgb(td) res # but col2rgb(#FFFF) # this is td[1] but does not produce the same answer res[,1] # moreover as.integer(td) col2rgb(5) # the integer value of the first level # and this is res[,1] which by the way is palette()[5], aka cyan ?col2rgb says: col vector of any of the three kinds of R color specifications, i.e., either a color name (as listed by colors()), a hexadecimal string of the form #rrggbb or #rrggbbaa (see rgb), or a positive integer i meaning palette()[i]. Non-numeric values are coerced to character. So in the example the factor is being taken as its integer representation, and finding an integer as the input value, col2rgb goes to palette(). Perhaps this is a nuance that belongs in the documentation? Thanks, Bryan *** Bryan Hanson Professor of Chemistry Biochemistry DePauw University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] relist() is broken when the skeleton is a list with empty list elements
Hi, relist() is broken when the skeleton is a list with empty list elements: x - list(1:3, integer(0), 11:14) relist(unlist(x), x) [[1]] [1] 1 2 3 [[2]] [1] 11 3 [[3]] [1] 11 12 13 14 Hard to believe that such a bug has been around for 6 years (i.e. since the introduction of relist()) without ever being noticed. Cheers, H. sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
