Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate
Hello Greg, I'm already using a reduced dataset. I can reduce it a little bit further but it doesn't really change things much. John On Tue, Sep 13, 2022 at 8:35 PM Greg Hunt wrote: > John, > Can you cut the test data size back? Do you have some processing costs > that are non-linear with data size? 27 seconds of user CPU is an awful lot > of processing these days. > > Greg > > On Wed, 14 Sept 2022 at 13:21, John Harrold > wrote: > >> Hello, >> >> I'm working on submitting a new package. I've created examples for each of >> the functions. Most of these functions depend on an R object that uses >> architecture-specific compiled code. To create that object can take >> between >> 10-20 seconds. The function that creates it will cache it in the >> tempdir(). >> So the first example that uses that object will take more than the 5 >> seconds allowed by CRAN. If I wrap that example in donttest, then the next >> function that uses it will exceed the 5 second limit, and on. I submitted >> the package with all of these examples wrapped in donttest, but that got >> me >> dinged :). So I'm trying to come up with a solution and I'd appreciate any >> help here. >> >> Is there some way to build an object before tests are run? >> >> Thank you, >> John >> >> If it would help this is an example where I'm testing it in win-builder: >> >> https://win-builder.r-project.org/6641irOr4mI6/ >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- John :wq [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Examples taking too long depend on object that takes a while to generate
Hello, I'm working on submitting a new package. I've created examples for each of the functions. Most of these functions depend on an R object that uses architecture-specific compiled code. To create that object can take between 10-20 seconds. The function that creates it will cache it in the tempdir(). So the first example that uses that object will take more than the 5 seconds allowed by CRAN. If I wrap that example in donttest, then the next function that uses it will exceed the 5 second limit, and on. I submitted the package with all of these examples wrapped in donttest, but that got me dinged :). So I'm trying to come up with a solution and I'd appreciate any help here. Is there some way to build an object before tests are run? Thank you, John If it would help this is an example where I'm testing it in win-builder: https://win-builder.r-project.org/6641irOr4mI6/ [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] Should package version requirements assume installation from sources?
[Arguably also appropriate for R-package-devel, but posted to R-devel
as the discussion is aimed primarily at "experts" ... ]
We, the authors of Matrix, have encountered a somewhat subtle issue
induced by caching of S4 classes and methods in package namespaces.
The namespaces of three reverse dependent packages (SeuratObject, conText,
mcmcsae) cache the formal definition of our virtual class Matrix (and some
subclasses). For example:
> ns <- asNamespace("SeuratObject")
> grep("^[.]__C__.*Matrix$", names(ns), value = TRUE)
[1] ".__C__dMatrix" ".__C__compMatrix"".__C__AnyMatrix"
[4] ".__C__generalMatrix" ".__C__CsparseMatrix" ".__C__sparseMatrix"
[7] ".__C__dsparseMatrix" ".__C__Matrix"
The cached definition (which includes a _validity method_) is obtained from
the version of Matrix available when the reverse dependent package was built
from sources. For example, if SeuratObject was built under Matrix 1.4-1,
then we get:
> getValidity(ns$.__C__Matrix)
function (object)
{
if (!isTRUE(r <- .Call(Dim_validate, object, "Matrix")))
r
else .Call(dimNames_validate, object)
}
whereas if SeuratObject was built under Matrix >= 1.5-0, then we get:
> getValidity(ns$.__C__Matrix)
function (object)
.Call(Matrix_validate, object)
There are two "questions" here:
1. The symbol 'Matrix_validate' is not defined until Matrix 1.5-0.
Is it necessary, for this reason alone, for SeuratObject to have
'Imports: Matrix (>= 1.5-0)'? Or can SeuratObject continue using
'Imports: Matrix (>= 1.3-3)', at the risk of errors like
> Error: object 'Matrix_validate' not found
(as already seen here: https://stackoverflow.com/questions/73700130)?
Note that this error would not occur for anyone installing SeuratObject
from sources, unless they decide to _downgrade_ Matrix after doing so.
Hence this primarily concerns Windows and macOS where R users would
typically install a binary built by CRAN (i.e., not on their system).
We are aware that package TMB tests in .onLoad() that the current Matrix
version is equal to or greater than the version available at build time,
thus avoiding a "strict" version requirement, but do not want this practice
to spread ...
2. For how long should Matrix retain the superceded 'Dim_validate' and
'dimNames_validate', in order to ensure that "stale" cached validity
methods continue to work?
We hope that this discussion will highlight the potential ramifications
of importing classes and methods from other packages, and having one's
classes and methods imported _by_ other packages, especially for version
requirements.
Mikael, Martin, and Doug
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
