Re: [R-pkg-devel] Forward function call

2020-06-08 Thread William Dunlap
Use Call[[1]] <- quote(survival::coxph) Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Jun 8, 2020 at 12:12 PM Göran Broström wrote: > Hello, > > the function 'coxreg' in my package 'eha' is often just a wrapper for > 'coxph' in survival, so I have code like > > if (cox.ph){ >

Re: [R-pkg-devel] Forward function call

2020-06-08 Thread Göran Broström
Thanks for the responses! I found the suggestion Call[[1]] <- quote(survival::coxph) easiest to implement. And it works. Best, Göran On 2020-06-08 21:42, Ben Bolker wrote: I think quote(survival::coxph) will work in place of as.name() ? On Mon, Jun 8, 2020 at 3:12 PM Göran Broström wrote

Re: [R-pkg-devel] Forward function call

2020-06-08 Thread Ben Bolker
I think quote(survival::coxph) will work in place of as.name() ? On Mon, Jun 8, 2020 at 3:12 PM Göran Broström wrote: > > Hello, > > the function 'coxreg' in my package 'eha' is often just a wrapper for > 'coxph' in survival, so I have code like > > if (cox.ph){ > Call <- match.cal

Re: [R-pkg-devel] Forward function call

2020-06-08 Thread Neal Fultz
You will first need to convert the function call to an expression, then you can modify the expression as appropriate. Here's a somewhat contrived minimal example: > f <- function(z, ...) match.call() > aaa = f(a=1,2,3) > str(aaa) language f(z = 2, a = 1, 3) > aaa <- as.expression(aaa) > str(aaa)

[R-pkg-devel] Forward function call

2020-06-08 Thread Göran Broström
Hello, the function 'coxreg' in my package 'eha' is often just a wrapper for 'coxph' in survival, so I have code like if (cox.ph){ Call <- match.call() Call[[1]] <- as.name("coxph") fit <- eval.parent(Call) return(fit) } which works since eha depends on

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Duncan Murdoch
The built-in way is to put those tests in a separate directory, and specify that directory when you run R CMD check. For example, rgl has directory "inst/slowTests", and I use these options to R CMD check: --test-dir=inst/slowTests Duncan Murdoch On 08/06/2020 10:52 a.m., Spencer Graves wro

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Daniel Lüdecke
Hi Spencer, the NOTE you posted in your email was related to examples, so you probably don't need to remove tests. You can wrap part of the examples in \dontrun{} to reduce check time for examples. As for tests, there are several ways of skipping (long-running) tests on CRAN. If you're using t

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Uwe Ligges
On 08.06.2020 17:02, Gábor Csárdi wrote: On Mon, Jun 8, 2020 at 3:58 PM Uwe Ligges wrote: [...] Nor do I how they can find out, as our idea is that CRAN cannot be special cased. If you want to run additional tests, you can execute them if some env var is set that you define on machines where

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Gábor Csárdi
On Mon, Jun 8, 2020 at 3:58 PM Uwe Ligges wrote: [...] > Nor do I how they can find out, as our idea is that CRAN cannot be > special cased. > If you want to run additional tests, you can execute them if some env > var is set that you define on machines where you want to run the > additional tests

Re: [R-pkg-devel] [External] Re: email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread luke-tierney
testthat::skip_on_cran function () { skip_if(on_cran(), "On CRAN") } testthat:::on_cran function () !identical(Sys.getenv("NOT_CRAN"), "true") Best, luke On Mon, 8 Jun 2020, Uwe Ligges wrote: On 08.06.2020 16:52, Spencer Graves wrote: Hi, Uwe et al.:   What's the prefe

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Uwe Ligges
On 08.06.2020 16:52, Spencer Graves wrote: Hi, Uwe et al.:   What's the preferred way to eliminate tests on CRAN that the maintainer still wants to run on other platforms?   For several years, I've been using "if(!fda::CRAN()){...}". I've been told that I should NOT do that, b

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Spencer Graves
Hi, Uwe et al.:   What's the preferred way to eliminate tests on CRAN that the maintainer still wants to run on other platforms?   For several years, I've been using "if(!fda::CRAN()){...}". I've been told that I should NOT do that, but it has worked for me, and I haven't found any

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread stefano
Hello Uwe, OK sorry for that. Best wishes. *Stefano * Stefano Mangiola | Postdoctoral fellow Papenfuss Laboratory The Walter Eliza Hall Institute of Medical Research +61 (0)466452544 Il giorno mar 9 giu 2020 alle ore 00:40 Uwe Ligges < lig...@statistik.tu-dortmund.de> ha scritto: > > >

Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread Uwe Ligges
On 08.06.2020 16:26, stefano wrote: Hello, I would like to point out that I (and others in various forums) find that the CRAN check with the note : *checking CRAN incoming feasibility ... NOTEMaintainer* Not true, it also says Flavor: r-devel-windows-ix86+x86_64 Check: running examples

[R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer

2020-06-08 Thread stefano
Hello, I would like to point out that I (and others in various forums) find that the CRAN check with the note : *checking CRAN incoming feasibility ... NOTEMaintainer* Triggers an email saying 1) *package nanny_0.1.7.tar.gz does not pass the incoming checks automatically* 2) *Please fix all