Re: [Rd] R-2.15.1 CMD CHECK output: "Call Sequence"
Dear Brian,
thanks for the reply.
Indeed, metaGSEA was the package being CHECK'ed & it turns out that the R CMD
CHECK metaGSEA errors were due to a missing 'Depends: methods' from the
DESCRIPTION of a dependent package.
I went back and CHECK'ed under R 2.14.2 and R 2.13.1, and indeed you're right
re the call sequence's having been there for a while, however I did notice that
R 2.15.1's output was somewhat less useful than R 2.14.2's in these 2 sections:
* checking S3 generic/method consistency ... WARNING
* checking Rd \usage sections ... NOTE
which under R 2.14.2 printed the offending functions (see full R CMD CHECK
output for R 2.15, 2.14, 2.13 here: git://gist.github.com/3926486.git)
fixing the DESCRIPTION of the depedent package removed the package/namespace
errors in this package, and all of the Call Sequence dumps. Importantly, fixing
the dependent package also reinstated the usual verbose output under the 2
sections above.
In hindsight, what this specific scenario boiled down to was this section of
the CHECK output:
Error : objects ¡.__T__sort:mjcbase¢, ¡sort¢ are not exported by
¡namespace:mjcbase¢
Error: package/namespace load failed for ¡metaGSEA¢
Execution halted
It looks like this package (or one of its dependent packages) has an
unstated dependence on a standard package. All dependencies must be
declared in DESCRIPTION.
which was not actually that I didn't export the S4 method sort, but that I was
missing the 'Depends: methods' from mjcbase's DESCRIPTION.
It would be *really* helpful if the error produced when checking 'metaGSEA'
looked like this:
Error : objects ¡.__T__sort:mjcbase¢, ¡sort¢ are not exported by
¡namespace:mjcbase¢
Error: package/namespace load failed for ¡mjcbase¢
Error: package/namespace load failed for ¡metaGSEA¢
Execution halted
It looks like this package (or one of its dependent packages) has an
unstated dependence on a standard package. All dependencies must be
declared in DESCRIPTION.
as when developing, I think we can all be guilty of not looking beyond the
spotlight of the current package.
kind regards,
Mark
On 21/10/2012, at 1:50 AM, Prof Brian Ripley wrote:
> On Sat, 20 Oct 2012, Mark Cowley wrote:
>
>> Hi guRus,
>
>> i'm running R-2.15.1 and the R CMD CHECK output appears to have changed
>> substantially, in that instead of pointing me to the
>
> Changed since when? This has been the behaviour for years with the error
> quoted.
>
>> offending functions or files, I get lots of 'call sequence' traces as below.
>
> It is an offending _package_, and it tells you which one in
>
>> Error: package/namespace load failed for ¡metaGSEA¢
>
> Package 'metaGSEA' seems not to be installed properly. It also tells you
> that 'library' is involved, so it looks like it is a package load and not a
> namespace load.
>
> You have not told us if ¡metaGSEA¢ is the package under test or a dependent.
> Given that in earlier 'check' output which you excised the loading of the
> package under test was checked, the latter looks more plausible.
>
>> I've been using R CMD CHECK for years & never seen anything like this
>> before. This is on a pretty fresh OSX 10.8 Mountain Lion installation, where
>> I installed R from CRAN via pkg. Is this a problem unique to me?
>
> Maybe not, but unusual. It is a lot harder to get a package installed
> non-functionally these days, but it can happen if it were installed with a
> different version or architecture, or if binary packages are involved.
>
>>
>> cheers,
>> Mark
>>
>> heres' a snippet from testing one of my packages under development:
>>
>> * checking for unstated dependencies in R code ... WARNING
>> Error: package/namespace load failed for ¡metaGSEA¢
>> Call sequence:
>> 2: stop(gettextf("package/namespace load failed for %s", sQuote(package)),
>> call. = FALSE, domain = NA)
>> 1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose =
>> FALSE)
>> Execution halted
>> See the information on DESCRIPTION files in the chapter ¡Creating R
>> packages¢ of the ¡Writing R Extensions¢ manual.
>> * checking S3 generic/method consistency ... WARNING
>> Error: package/namespace load failed for ¡metaGSEA¢
>> Call sequence:
>> 2: stop(gettextf("package/namespace load failed for %s", sQuote(package)),
>> call. = FALSE, domain = NA)
>> 1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose =
>> FALSE)
>> Execution halted
>> See section ¡Generic functions and methods¢ of the ¡Writing R
>> Extensions¢ manual.
>> * checking replacement functions ... WARNING
>> Error: package/namespace load failed for ¡metaGSEA¢
>> Call sequence:
>> 2: stop(gettextf("package/namespace load failed for %s", sQuote(package)),
>> call. = FALSE, domain = NA)
>> 1: library(package, lib.loc = lib.loc, character.only = TRUE, verbose =
>> FALSE)
>> Execution halted
>> The argument of a replacement function which corresponds to the right
>> hand side must be named ¡value¢.
>> * checking fore
[Rd] suppress *specific* warnings?
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 <- function(expr,regex=NULL) {
opts <- options(warn = -1)
on.exit(options(opts))
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[["message"]],regex)) {
invokeRestart("muffleWarning")
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows "browser",
##"muffleWarning", and "abort" ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),"abc")
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 <- function(expr,regex=NULL) {
opts <- options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its for
efficiency to avoid generating a warning message (as distinct from signalling a
warning). I think you're after something like
suppressWarnings2 <-
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
invokeRestart("muffleWarning")
}
})
}
If the restart isn't invoked, then the next handler is called and the warning
is handled as normal. So with
f <- function() {
warning("oops")
2
}
there is
> suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
> suppressWarnings2(f(), "oops")
[1] 2
For your own code I think a better strategy is to create a sub-class of warnings
that can be handled differently
mywarn <-
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg <- .makeMessage(..., domain=domain, appendLF=FALSE)
call <- NULL
if (call.)
call <- sys.call(1L)
class <- c("silencable", "simpleWarning", "warning", "condition")
cond <- structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 <-
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
invokeRestart("muffleWarning")
})
}
then with
g <- function() {
mywarn("oops")
3
}
> suppressWarnings3(f())
[1] 2
Warning message:
In f() : oops
> g()
[1] 3
Warning message:
In g() : oops
> suppressWarnings3(g())
[1] 3
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[["message"]],regex)) {
invokeRestart("muffleWarning")
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows "browser",
##"muffleWarning", and "abort" ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),"abc")
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 12-10-21 09:08 PM, Martin Morgan wrote:
> On 10/21/2012 12:28 PM, Ben Bolker wrote:
>>
>>Not desperately important, but nice to have and possibly of use to
>> others, is the ability to suppress specific warnings rather than
>> suppressing warnings indiscriminately. I often know of a specific
>> warning that I want to ignore (because I know that's it's a false
>> positive/ignorable), but the current design of suppressWarnings() forces
>> me to ignore *any* warnings coming from the expression.
>>
>>I started to write a new version that would check and, if supplied
>> with a regular expression, would only block matching warnings and
>> otherwise would produce the warnings as usual, but I don't quite know
>> enough about what I'm doing: see ??? in expression below.
>>
>>Can anyone help, or suggest pointers to relevant
>> examples/documentation (I've looked at demo(error.catching), which isn't
>> helping me ... ?)
>>
>> suppressWarnings2 <- function(expr,regex=NULL) {
>> opts <- options(warn = -1)
>> on.exit(options(opts))
>
> I'm not really sure what the options(warn=-1) is doing there, maybe its
> for efficiency to avoid generating a warning message (as distinct from
> signalling a warning).
As may have been obvious, I was copying suppressWarnings() verbatim --
so I guess you'd have to ask R-core for the reasoning there ...
> I think you're after something like
>
> suppressWarnings2 <-
> function(expr, regex=character())
> {
> withCallingHandlers(expr, warning=function(w) {
> if (length(regex) == 1 && length(grep(regex,
> conditionMessage(w {
> invokeRestart("muffleWarning")
> }
> })
> }
>
> If the restart isn't invoked, then the next handler is called and the
> warning is handled as normal. So with
>
> f <- function() {
> warning("oops")
> 2
> }
>
> there is
>
>> suppressWarnings2(f())
> [1] 2
> Warning message:
> In f() : oops
>> suppressWarnings2(f(), "oops")
> [1] 2
Great, thank you!
>
> For your own code I think a better strategy is to create a sub-class of
> warnings that can be handled differently
>
> mywarn <-
> function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
> {
> msg <- .makeMessage(..., domain=domain, appendLF=FALSE)
> call <- NULL
> if (call.)
> call <- sys.call(1L)
> class <- c("silencable", "simpleWarning", "warning", "condition")
> cond <- structure(list(message=msg, call=call), class=class)
> warning(cond)
> }
>
> suppressWarnings3 <-
> function(expr)
> {
> withCallingHandlers(expr, silencable=function(w) {
> invokeRestart("muffleWarning")
> })
> }
>
> then with
>
> g <- function() {
> mywarn("oops")
> 3
> }
>
>> suppressWarnings3(f())
> [1] 2
> Warning message:
> In f() : oops
>> g()
> [1] 3
> Warning message:
> In g() : oops
>> suppressWarnings3(g())
> [1] 3
>
>> withCallingHandlers(expr, warning = function(w) {
>> ## browser()
>> if (is.null(regex) || grepl(w[["message"]],regex)) {
>> invokeRestart("muffleWarning")
>> } else {
>> ## ? what do I here to get the warning issued?
>> ## browser()
>> ## computeRestarts() shows "browser",
>> ##"muffleWarning", and "abort" ...
>> options(opts)
>> warning(w$message)
>> ## how can I get back from here to the calling point
>> ## *without* muffling warnings ... ?
>> }
>> })
>> }
>>
>> suppressWarnings2(sqrt(-1))
>> suppressWarnings2(sqrt(-1),"abc")
>>
>>It seems to me I'd like to have a restart option that just returns to
>> the point where the warning was caught, *without* muffling warnings ...
>> ? But I don't quite understand how to set one up ...
>>
>>Ben Bolker
>>
>> __
>> 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
Re: [Rd] Change in the RNG implementation?
Hi Duncan, Martin,
Thanks for your answers.
For my real case I was generating millions of random positions
on a genome.
I compared sample.int() performance between R-2.15.1 and R-devel,
and, for me, it performs better in R-2.15.1 (almost 3x faster and
also uses slightly less memory):
With R-2.15.1:
> set.seed(33)
> system.time(random_chrom_pos <- sample(199000666L, 95000777L))
user system elapsed
4.964 0.268 5.242
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 137285 7.4 35 18.735 18.7
Vcells 47633785 363.5 154735917 1180.6 147135703 1122.6
> sessionInfo()
R version 2.15.1 (2012-06-22)
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
With R-devel:
> set.seed(33)
> system.time(random_chrom_pos <- sample(199000666L, 95000777L))
user system elapsed
14.532 0.296 14.854
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 145525 7.8 35 18.735 18.7
Vcells 47644082 363.5 152959996 1167.0 182023372 1388.8
> sessionInfo()
R Under development (unstable) (2012-10-02 r60861)
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
FWIW my R-2.15.1 and R-devel were configured with
--disable-byte-compiled-packages, otherwise, I use all the
defaults. Also my system is a standard Ubuntu 12.04 installation
with no fancy settings/tweakings/customizations.
Thanks,
H.
On 10/20/2012 12:50 PM, Martin Maechler wrote:
Duncan Murdoch
on Fri, 19 Oct 2012 19:26:39 -0400 writes:
> On 12-10-19 7:04 PM, Hervé Pagès wrote:
>> Hi,
>>
>> Looks like the implementation of random number generation changed in
>> R-devel with respect to R-2.15.1.
>>
>> With R-2.15.1:
>>
>> > set.seed(33)
>> > sample(49821115, 10)
>> [1] 22217252 19661919 24099911 45779422 42043111 25774933 21778053
>> 17098516
>> [9] 773073 5878451
>>
>> With recent R-devel:
>>
>> > set.seed(33)
>> > sample(49821115, 10)
>> [1] 22217252 19661919 24099912 45779425 42043115 25774935 21778056
>> 17098518
>> [9] 773073 5878452
>>
>> This is on a 64-bit Ubuntu system.
>>
>> Is this change intended? I didn't see anything in the NEWS file.
>>
>> A potential problem with this is that it will break unit tests
>> for algorithms that make use of RNG.
>>
>> Another more practical problem (at least for me) is the following:
>> Bioconductor package maintainers are sometimes working hard on the
>> development version of their package to improve the performance of
>> some key functions. Comparing performance between BioC release
>> (based on R-2.15) and devel (based on R-devel) often requires big
>> input data that is randomly generated, because it's easiest than
>> working with real data. Typically a small script is written that
>> takes care of loading the required packages, generating the input
>> data, and running a simple analysis. The same script is sourced in
>> R-2.15 and R-devel, and performance and results are compared.
>>
>> Not being able to generate exactly the same input in the script is
>> a problem. It can be worked around by generating the input once,
>> serializing it, and use load() in the script, but that makes things
>> more complicated and the script is not a standalone script anymore
>> (cannot be passed around without also passing around the big .rda
>> file).
>>
>> Thanks,
>> H.
>>
> I think it was mentioned in the NEWS:
> \code{sample.int()} has some support for \eqn{n \ge
> 2^{31}}{n >= 2^31}: see its help for the limitations.
> A different algorithm is used for \code{(n, size, replace = FALSE,
> prob = NULL)} for \code{n > 1e7} and \code{size <= n/2}. This
> is much faster and uses less memory, but does give different results.
So, to iterate : The RNG has not been changed at all,
but sample() has, for extreme cases (large n) like yours.
> I don't think the old algorithm is available, but pe
