Re: [R-pkg-devel] tryCatch defensive programming guidance

[Martin Maechler]

> Berry Boessenkool 
> on Wed, 1 Mar 2017 14:52:10 + writes:

> Hi Glenn,


> Better late than never:
> couldn't you simply use try?

> result <- try( log("a") )

> The printing is horrible: people will think an error
> occured (but the function didn't stop!)

> I tend to use it like this (which may be totally
> unintended):


> res <- try(log("a"), silent=TRUE)
> if(inherits(res, "try-error"))
> {
>   message("log failed: ",res,". Now continuing with res=0.")
>  res <- 0
> }

but if you ever looked:  try() is just a wrapper to tryCatch()
and using try(*, silent=TRUE)  is even closer to a pretty simple tryCatch(.)

Historically,  tryCatch() did not exist, but try() did.
So much of "old code" still has try() calls in it.

I consider try() as convenience function for interactive use but
would always use tryCatch() for new code in my packages.


> See here for my version that captures errors/warnings/messages with call 
tracing:

> https://www.rdocumentation.org/packages/berryFunctions/topics/tryStack

I'd recommend you switch to tryCatch(): It is more flexible and
more directly "configurable" than try() -- which also got some historical
flexibility by the "hack" (not functional programming)
of depending on  getOption("show.error.messages")  in the
default case  silent = FALSE  {needed to suppress other
packages' using  try(.) 's printing of error messages as if
*error*s inspite of the fact that they were caught.

 and back to the OP:

I think that's your only small problem that you chose
  error = function(e) print(e)

because that prints "as if" you had an error.

Martin


> Regards,

> Berry


> 
> From: R-package-devel  on behalf 
of Glenn Schultz 
> Sent: Saturday, February 25, 2017 15:50
> To: R Package Development
> Subject: [R-pkg-devel] tryCatch defensive programming guidance

> All,

> I have the following to create a class PriceTypes.  I use try catch on 
the function and it gives me the error

> price <- tryCatch(PriceTypes(price = "100")
> ,error = function(e) print(e)
> ,warning = function(w) print(w))

> 
>> 

> I read the section on tryCatch and withCallingHandlers as well the manual 
but I am still not clear as to how to use tryCatch in the function below I tried
> PriceTypes <- TryCatch(
> function(){}
> ), function(e) print(error)

> but this is obviously wrong as it did not work.  My question can I use 
tryCatch in the function itself or only when I invoke the function.

> Best Regards,
> Glenn

> #' An S4 class representating bond price
> #'
> #' This class is used to create and pass the price types reported to
> #' investors and used in analytics. For example price is often reported as
> #' decimal or fractions 32nds to investors but price basis (price/100) is
> #' used to calculate proceeds and compute metrics like yield, duration, 
and
> #' partial durations.
> #' @slot PriceDecimal A numeric value the price using decimal notation
> #' @slot Price32nds A character the price using 32nds notation
> #' @slot PriceBasis A numeric value price decimal notation in units of 100
> #' @slot PriceDecimalString A character the price using decimal notation
> #' @exportClass PriceTypes
> setClass("PriceTypes",
> representation(
> PriceDecimal = "numeric",
> Price32nds = "character",
> PriceBasis = "numeric",
> PriceDecimalString = "character")
> )

> setGeneric("PriceTypes", function(price = numeric())
> {standardGeneric("PriceTypes")})

> #' A standard generic function get the slot PriceDecimal
> #'
> #' @param object an S4 object
> #' @export PriceDecimal
> setGeneric("PriceDecimal", function(object)
> {standardGeneric("PriceDecimal")})

> #' A standard generic function to set the slot PriceDecimal
> #'
> #' @param object an S4 object
> #' @param value the replacement value of the slot
> #' @export PriceDecimal<-
> setGeneric("PriceDecimal<-", function(object, value)
> {standardGeneric("PriceDecimal<-")})

> #' A standard generic function to get the slot Price32nds
> #'
> #' @param object an S4 object
> #' @export Price32nds
> setGeneric("Price32nds", function(object)
> {standardGeneric("Price32nds")})

> #' A standard generic function to set the slot Price32nds
> #'
> #' @param object an S4 object
> #' @param value the replacement value of the slot
> #' @export Price32nds<-
> setGeneric("Price32nds<-", function(object, value)
> {setGeneric("Price32nds")})

> #' A standard generic to get the slot PriceBasis
> #'
> #' @param object an S4 object
> #' @export PriceBasis
> setGeneric("PriceBasis", 

Re: [Rd] stats::median

[Martin Maechler]

> Martin Maechler 
> on Mon, 27 Feb 2017 10:42:19 +0100 writes:

> Rob J Hyndman 
> on Wed, 15 Feb 2017 21:48:56 +1100 writes:

>> The generic stats::median method is defined as median <-
>> function (x, na.rm = FALSE) {UseMethod("median")}

>> I suggest that this should become median <- function (x,
>> na.rm = FALSE, ...)  {UseMethod("median")}

>> This would allow additional S3 methods to be developed
>> with additional arguments.

> and S4 methods, too.

>> Currently I have to over-ride this generic definition in
>> the demography package because median.demogdata has
>> several other arguments.

>> This shouldn't break any code, and will make it easier
>> for new S3 methods to be developed. It is also consistent
>> with almost all other S3 methods which do include an
>> ellipsis.

> "shouldn't break any code" is almost always quite
> optimistic nowadays,

For CRAN, the change leads   13 packages (out of > 1) to
"regress" to  status: WARN.

I've checked 10 of them, and all these define  median() S3
methods, and currently of course have not had the '...' in their
formal argument list(s).

They (and all other useRs who define median() S3 methods and
want their code to work both in R <= 3.3.x _and_ R >= 3.4.0
could use code such as
(for package 'sets' in R/summary.R )

 
median.set <-
function(x, na.rm = FALSE, ...)
{
median(as.numeric(x), na.rm = na.rm, ...)
}

## drop '...' in R versions <= 3.4.0 :
if((!any("..." == names(formals(median {
formals(median.set) <- formals(median.set)[names(formals(median.set)) != 
"..."]
body(median.set)[[2]] <- body(median.set)[[2]][-4]
}

or simply
 
median.cset <-
if("..." %in% names(formals(median))) {
function(x, na.rm = FALSE, ...) median.gset(x, na.rm = na.rm, ...)
} else
function(x, na.rm = FALSE)  median.gset(x, na.rm = na.rm)


which is R code that will work fine in both current (and older)
R and in R-devel and future R versions.

For packages however, this will leave a 'R CMD check '
warning (for now) because code and documentation mismatch
either in R-devel (and future)  R  or in current and previous R versions.

It is less clear what to do for these man i.e. *.Rd  pages [if you
have them for your median method(s): Note that they *are* optional for
registered S3 methods; package 'sets', e.g., documents 2 out of
4 median methods]. 

It may (or may not) make sense to tweak R-devel's own 'R CMD check'
to _not_ warn for the missing '...' in median methods for a
while and consequently you'd get away with continued use of no
'...' in the help page \usage{ ... } section.

One solution of course, would be to wait a bit and then release
such package only with

Depends: R (>= 3.4.0)

where you'd  use  '...' and keep the previous CRAN version of
the package for all earlier versions of R.
That is a maintenance pain however, if you want to change your
package features, because then you'd have to start releasing to
versions of the package: an "old" one with

Depends: R (< 3.4.0)

and a "new" one with   R (>= 3.4.0).

Probably easiest would be to comment the \usage{.} / \arguments \item{...}
parts for the time being {as long as you don't want R (>= 3.4.0)
in your package DESCRIPTION "unconditionally"}.

--

Tweaking  R-devel's  tools::codoc()  for this special case may
be a solution liked more by package maintainers for this case.
OTOH, we can only change R-devel's version of codoc(), so it
would be that platform which would show slightly inaccurate
"Usage:" for these (by not showing "...")  which also seems a
kludgy solution.



> Actually it probably will break things when people start
> using the new R version which implements the above *AND*
> use packages installed with a previous version of R.  I
> agree that this does not count as "breaking any code".

> In spite of all that *and* the perennial drawback that a
> '...' will allow argument name typos to go unnoticed

> I agree you have a good argument nowadays, that median()
> should be the same as many similar "basic statistics" R
> functions and so I'll commit such a change to R-devel (to
> become R 3.4.0 in April).

> Thank you for the suggestion!  Martin Maechler, ETH Zurich

>> -
>> Rob J Hyndman Professor of Statistics, Monash University
>> www.robjhyndman.com

>> __
>> 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

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

[Bioc-devel] User has issue with importing a BigWig file with rtracklayer despite having a recent openssl and latest R packages

[Leonardo Collado Torres]

Hi,

I'm trying to figure out what is going wrong in
https://support.bioconductor.org/p/93182/. Mustafa is using recount to
load a bigwig file from the web. The code in recount relies on some
code in derfinder, and the actual importing is done by
rtracklayer::import().

>From looking at the R session information reported by Mustafa I can't
tell what's wrong. He has the correct versions of rtracklayer,
derfinder and recount installed. He also has openssl and pkg-config
installed. At first I thought that he might be missing openssl since
it's not listed as a SystemRequirement in the description file of
rtracklayer/derfinder/recount. I looked back at
https://support.bioconductor.org/p/81267/ and installed the latest
openssl, made it available on my PATH and installed rtracklayer from
SVN source on both R 3.4.0 and 3.3.2. In both situations, the R code
worked for me despite the message "checking for OPENSSL... no" when
installing rtracklayer. It used to be that it would say "yes" instead
of no as you can see at
https://support.bioconductor.org/p/81267/#82142.

So, it doesn't look like it's a version issue with R packages. It's
not a problem with either the latest openssl via homebrew or other
versions https://support.bioconductor.org/p/93182/#93223. I doubt that
it's an issue specific due to his openssl version (in between the
older and newer versions I tested) or his pkg-util version. It's not
an RStudio problem either (version 1.0.136 with both R 3.3.2 and
3.4.0). Could it be an RCurl issue? Could it be that his IP is blocked
by the server hosting the BigWig file?

Anyhow, I don't know what is the source of the problem and have not
been able to reproduce it. Hopefully someone here has an idea of what
is the problem.

Best,
Leo





$ brew install --force openssl

## Edited by .bashrc with the following line:
export PATH="/usr/local/opt/openssl/bin:$PATH"

$ which openssl
/usr/local/opt/openssl/bin/openssl
$ openssl version
OpenSSL 1.0.2k  26 Jan 2017

$ svn co https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/rtracklayer
 $ R CMD INSTALL rtracklayer
Loading required package: colorout
* installing to library
‘/Library/Frameworks/R.framework/Versions/3.4/Resources/library’
* installing *source* package ‘rtracklayer’ ...
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for OPENSSL... no
...

Then I was able to run without problems

> library(rtracklayer)
> x <- import.bw('http://duffel.rail.bio/recount/DRP000366/bw/DRR000897.bw',as 
> = 'RleList')
> x
RleList of length 94
$chr1
numeric-Rle of length 248956422 with 1249470 runs
  Lengths: 1337837   366372537   4433773 1
...241324 237   53537  102837 13595
  Values : 0 1 0 1 0 1 0 1 0 1
... 1 2 1 0 1 0 1 0 1 0

$chr10
numeric-Rle of length 133797422 with 412887 runs
  Lengths: 47132371237   333 1 3 3 1 1
...37   47937   37937   21137  208237 11003
  Values : 0 1 0 1 0 1 2 3 4 5
... 1 0 1 0 1 0 1 0 1 0

$chr11
numeric-Rle of length 135086622 with 700940 runs
  Lengths:  74243 37  22178 37  22907 37699 37
1236 ... 37  66776 37  36834 37   4395 37  17340
  Values :  0  1  0  1  0  1  0  1
 0 ...  1  0  1  0  1  0  1  0

$chr11_KI270721v1_random
numeric-Rle of length 100316 with 363 runs
  Lengths:  25933717 7 129 7 1  236437
...33  804837   17237   87637   49237 47993
  Values : 0 1 0 1 2 3 2 1 0 1
... 1 0 1 0 1 0 1 0 1 0

$chr12
numeric-Rle of length 133275309 with 628862 runs
  Lengths: 1005537  410137   31610 1 1 421
...371337   26337   62337  486037 64715
  Values : 0 1 0 1 0 1 2 3 4 5
... 1 0 1 0 1 0 1 0 1 0

...
<89 more elements>
> options(width = 120)
> devtools::session_info()
Session info 
---
 setting  value
 version  R Under development (unstable) (2016-10-26 r71594)
 system   x86_64, darwin13.4.0
 ui   AQUA
 language (EN)
 collate  en_US.UTF-8
 tz   America/New_York
 date 2017-03-01

Packages 
---
 package  * version  date   source
 Biobase2.35.1   2017-02-23 Bioconductor
 BiocGenerics * 0.21.3   2017-01-12 Bioconductor
 BiocParallel   1.9.52017-01-24 Bioconductor
 Biostrings 

Re: [Rd] Test suite failures in R-devel_2017-02-25_r72256

[Peter Simons]

Hi Martin,

 > Is it necessary to also run the 'make check' part in that restricted
 > environment? Or could that ('checking") not get more priviledges?

in NixOS, there is no way to run any kind of build process in an
environment that has network access. On one hand, that is a security
consideration, but the even more compelling reason for that choice is
that NixOS goes to great lengths to guarantee deterministic builds, and
a build process that connects to servers on the Internet and uses data
they provides is as non-deterministic as it can be, unfortunately.

What we can do for the 3.4.0 release is to extend our build environment
for R to ensure that all required resources are downloaded and made
available locally before the build starts.

 > Note that you can only run  "make check" if you don't install
 > recommended packages, whereas more thorough testing would
 > include
 >  make check-devel
 > or even
 >  make check-all
 >
 > but these do have quite a bit more requirements including recommended
 > packages being present.

Thank you for pointing that out. We do offer our users the choice of
whether they want the recommended packages included or not (the default
choice being to not include them), so we should in fact parameterize our
build to run the extended test suite if the recommended packages are
built.

Another option would be to always build the recommended packages, but to
not install them if the user doesn't want them included. I'm not sure,
though, whether the R build system supports such a type of build easily?

Best regards,
Peter

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

Re: [Rd] Test suite failures in R-rc_2017-02-28_r72286.tar.gz

[Peter Simons]

Hi Brian,

 > R-devel (your subject line) is not a pre-release of R 3.3.3: it is 'R
 > Under development' for what is planned as R 3.4.0. Pre-release
 > tarballs for 3.3.3 are things like R-rc_2017-02-26_r72260.tar.gz (and
 > were previously labelled R-beta).

I did not realize this distinction exists. I am sorry about the
misleading report. I followed the link for "3.3.3 release candidates"
and didn't expect that directory to contain tarballs for 3.4.0, too. In
hindsight, that should have been obvious from the different file names,
I suppose. Thank you for the clarification.

I re-ran the build and test suite with the correct tarball,
R-rc_2017-02-28_r72286.tar.gz, and the result looks different indeed.
With that version, I get a test suite error in reg-tests-1c from
"tests". I'm citing the relevant bit from "reg-tests-1c.Rout.fail":

 | > [...]
 | > ## format.POSIXlt() of Jan.1 if  1941 or '42 is involved:
 | > tJan1 <- function(n1, n2)
 | + strptime(paste0(n1:n2,"/01/01"), "%Y/%m/%d", tz="CET")
 | > wDSTJan1 <- function(n1, n2)
 | + which("CEST" == sub(".* ", '', format(tJan1(n1,n2), usetz=TRUE)))
 | > (w8 <- wDSTJan1(1801, 2300))
 | integer(0)
 | > (w9 <- wDSTJan1(1901, 2300))
 | integer(0)
 | > stopifnot(identical(w8, 141:142),# exactly 1941:1942 had CEST on Jan.1
 | +   identical(w9,  41: 42))
 | Error: identical(w8, 141:142) is not TRUE
 | Execution halted

This happens in the --without-recommended-packages style build. Not sure
whether this is relevant.

The sessionInfo() output looks as follows:

 | R version 3.3.3 RC (2017-02-28 r72286)
 | Platform: x86_64-pc-linux-gnu (64-bit)
 | 
 | locale:
 | [1] C
 | 
 | attached base packages:
 | [1] stats graphics  grDevices utils datasets  base 

Best regards,
Peter

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

Re: [R-pkg-devel] .bib file in vignette not found during R CMD check

[Duncan Murdoch]

On 01/03/2017 2:17 AM, Henrik Bengtsson wrote:

On Tue, Feb 28, 2017 at 2:47 PM, Duncan Murdoch
 wrote:

On 28/02/2017 5:17 PM, Patrick Schratz wrote:


Thanks Duncan, that was the problem! Although the Rbuildignore entry
pointed to the main dir



No, it contains patterns, not paths, and is matched "case-insensitively
against the file and directory names relative to the top-level package
source directory".  Put ^ at the beginning if you want to refer to the main
dir.

Hadley, reporting what gets omitted might be a good suggestion, but it might
report too much in a package with compiled code (the .o files will generally
be omitted; rgl has 51 of those in src...).


I like this idea.  It could be done such that R CMD build lists the
files omitted based solely on the content of .Rbuildignore, which I
assume is also what Hadley meant.  This way *.o files wouldn't be
listed since they're omitted by the built-in rules of R CMD build
itself.


That makes sense.  Want to submit a patch?

Duncan Murdoch

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