similar to: Parallel R CMD check?

A package uses VignetteEngine: knitr; the package itself does not Suggests: knitr, but it Suggests: BiocStyle which in turn Suggests: knitr. Nonetheless, R CMD check fails indicating that a package required for checking is not declared. Is it really the intention that the original package duplicate Suggests: knitr? This is only with a recent R. In detail, with $ Rdev --version|head -3 R Under

On 04/29/2015 05:38 PM, William Dunlap wrote: >> And in general a developer would avoid masking a function >> in a base package, so as not to require the user to distinguish >> between stats::density() and igraph::density(). Maybe the >> example is not meant literally. > > The 'filter' function in the popular 'dplyr' package masks the one > that has

In pvec(list(1, 2), FUN, mc.cores=2) FUN sees integer() arguments whereas pvec(list(1, 2, 3), FUN, mc.cores=2) FUN sees list() arguments; the latter seems consistent with pvec's description. This came up in a complicated Bioconductor thread about generics and parallel evaluation https://stat.ethz.ch/pipermail/bioc-devel/2012-October/003745.html One relevant point is that a

Hi Gabor, I just used your R code below and the code worked properly without any error messages. Attached is the output graph, which may be the one you expected. library("Rgraphviz") set.seed(123) V <- letters[1:10] M <- 1:4 g1 <- randomGraph(V, M, 0.2) g1 plot(g1) Thanks. Howard On Wed Mar 31 11:18:25 EDT 2010, Gabor Grothendieck <ggrothendieck at

> And in general a developer would avoid masking a function > in a base package, so as not to require the user to distinguish > between stats::density() and igraph::density(). Maybe the > example is not meant literally. The 'filter' function in the popular 'dplyr' package masks the one that has been in the stats package forever, and they have nothing in common, so that

On 08/25/2015 01:30 PM, Kevin Ushey wrote: > Hi Martin, > > Indeed it does (and I should have confirmed myself with R-patched and R-devel > before posting...) actually I don't know that it does -- it addresses the symptom but I think there should be an error from libcurl on the 403 / 404 rather than from read.dcf on error page... Martin > > Thanks, and sorry for the

Maybe someone can help shed some light on an odd and repeatedly irritating error I noticed when running the check Perl script on my R 1.3 project. In following it line by line, I traced my problem down to the code/documentation matching within check, the most recent version of which seems to verify proper .Rd formatting by means of R's codoc and undoc functions. Under R --vanilla, those two

In > R.version.string [1] "R Under development (unstable) (2011-12-15 r57901)" PkgA promotes 'unique' to a generic and exports that DESCRIPTION: Imports: methods R/f.R: setGeneric("unique") NAMESPACE: export(unique) and PkgB creates and exports a method on unique DESCRIPTION Imports: methods, PkgA R/f.R: setClass("B",

Full_Name: Laurent Version: R-2.0.0-beta-from-a-week-ago OS: linux Submission from: (NULL) (202.156.6.77) When running 'R CMD check' for a package that contains the symbol '%' in the signature of a function (say the default parameter for a string argument is like "10% - 20%"), the 'codoc' part of the check throws a warning about mismatching doc and codoc. While

Hi Martin, It is really a 'PATH' problem. After adding C:\Program Files\Graphviz2.20\bin to the 'PATH' environment variable, the Rgraphviz package can be loaded without any error messages. Sorry that I ONLY set my 'PATH' environment variable correctly for R but not for Graphviz. Thank you and Duncan so much for your great help. Howard On Tue Mar 30 18:12:54

On 04/28/2015 01:04 PM, G?bor Cs?rdi wrote: > When a symbol in a package is resolved, R looks into the package's > environment, and then into the package's imports environment. Then, if the > symbol is still not resolved, it looks into the base package. So far so > good. > > If still not found, it follows the 'search()' path, starting with the > global

PkgA has a single R/binding.R file containing .A <- setRefClass("A", methods=list(initialize=function(...) {})) .onLoad <- function(...) .A() A NAMESPACE with import(methods) exportClasses("A") and DESCRIPTION Package: PkgA Type: Package Title: Documenting reference classes Version: 0.0.1 Date: 2012-08-05 Author: Martin

If I try to build a package with a vignette R CMD build Biobase I see * checking for file 'Biobase/DESCRIPTION' ... OK * preparing 'Biobase': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * creating vignettes ... OK * cleaning src Error in setwd(pkgname) : cannot change working directory Execution halted This is

In fact, this does reproduce on R-devel: > options(download.file.method = "libcurl") > options(repos = c(CRAN = "https://cran.rstudio.com/", CRANextra = + "http://www.stats.ox.ac.uk/pub/RWin")) > install.packages("lattice") ## could be any package Installing package into ?/Users/kevinushey/Library/R/3.3/library? (as ?lib? is

Hello, Since people have whisperred about Rcpp, I'd like to play too. > On 11/15/2010 07:45 AM, Patrick Leyshock wrote: >> Very helpful, thank you. >> >> A couple other questions, please: >> >> 1. I've got a function written in C, named "my_c_function". In my R >> code I call this function, passing to it an INTSXP and a STRSXP, >>

A post on the Bioconductor mailing list https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html suggests that install.packages now references .Rprofile (?), whereas in R-2-8 it did not. Is this intentional? The example is, in .Rprofile library(utils) install.packages("Biobase", repos="http://bioconductor.org/packages/2.4/bioc") then

It would be convenient if, under R-devel r56422, packages that require re-installation because they do not have a NAMESPACE were marked as old.packages, so their lack of functionality can be discovered more easily. > "snow" %in% row.names(old.packages()) [1] FALSE > library(snow) Error in library(snow) : package 'snow' does not have a NAMESPACE and should be

The attached diff address the following issues in mclapply mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be an efficient representation and is not required if the object implements length, [, and [[ methods (lapply must also work on the object, either through coercion to a list at the 'inner.do' level or through other means, e.g., promoting lapply to a

--- On Sun, 13/2/11, Shing Hing Man <matmsh at yahoo.com> wrote: > From: Shing Hing Man <matmsh at yahoo.com> > Subject: Re: [R] Linked List in R > To: "Martin Morgan" <mtmorgan at fhcrc.org> > Date: Sunday, 13 February, 2011, 4:49 > Hi Martin, > ? Thanks for the pointer ! It seems quite involved to > create a > a linked list in the oo way. I

as.factor / as.ordered is not written as a generic. This differs from as.numeric, as.matrix, and other as.*. The following seems to address this and does not break make check-all. FWIW, the patch is against r55563, because with r55564 I see /home/mtmorgan/src/R-devel/src/main/dounzip.c:75:15: error: storage size of ?dt? isn?t known /home/mtmorgan/src/R-devel/src/main/dounzip.c:88:5: warning: