Re: [R-pkg-devel] Forward function call
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){
> Call <- match.call()
> Call[[1]] <- as.name("coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> which works since eha depends on survival. Now I am thinking of changing
> Depends to Imports, and I would like to change the code to
>
> if (cox.ph){
> Call <- match.call()
> Call[[1]] <- as.name("survival::coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> but this doesn't work, because the function name is turned into
> `survival::coxph` (with the backticks) and the evaluation fails.
>
> How can I solve this?
>
> Thanks, G,
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Forward function call
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:
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 survival. Now I am thinking of changing
Depends to Imports, and I would like to change the code to
if (cox.ph){
Call <- match.call()
Call[[1]] <- as.name("survival::coxph")
fit <- eval.parent(Call)
return(fit)
}
but this doesn't work, because the function name is turned into
`survival::coxph` (with the backticks) and the evaluation fails.
How can I solve this?
Thanks, G,
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Forward function call
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.call()
> Call[[1]] <- as.name("coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> which works since eha depends on survival. Now I am thinking of changing
> Depends to Imports, and I would like to change the code to
>
> if (cox.ph){
> Call <- match.call()
> Call[[1]] <- as.name("survival::coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> but this doesn't work, because the function name is turned into
> `survival::coxph` (with the backticks) and the evaluation fails.
>
> How can I solve this?
>
> Thanks, G,
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Forward function call
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)
expression(f(z = 2, a = 1, 3))
> aaa[[1]][[1]] <- expression(base::c)[[1]]
> str(aaa)
expression(base::c(z = 2, a = 1, 3))
> eval(aaa)
z a
2 1 3
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){
> Call <- match.call()
> Call[[1]] <- as.name("coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> which works since eha depends on survival. Now I am thinking of changing
> Depends to Imports, and I would like to change the code to
>
> if (cox.ph){
> Call <- match.call()
> Call[[1]] <- as.name("survival::coxph")
> fit <- eval.parent(Call)
> return(fit)
> }
>
> but this doesn't work, because the function name is turned into
> `survival::coxph` (with the backticks) and the evaluation fails.
>
> How can I solve this?
>
> Thanks, G,
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Forward function call
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 survival. Now I am thinking of changing
Depends to Imports, and I would like to change the code to
if (cox.ph){
Call <- match.call()
Call[[1]] <- as.name("survival::coxph")
fit <- eval.parent(Call)
return(fit)
}
but this doesn't work, because the function name is turned into
`survival::coxph` (with the backticks) and the evaluation fails.
How can I solve this?
Thanks, G,
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 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, but it has worked for me, and I
haven't found anything better. I've recently seen
"testthat::skip_on_cran(...)", but I have yet to understand enough of
how it works to actually use it.
Thanks,
Spencer Graves
On 2020-06-08 09:43, stefano wrote:
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:
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 for arch 'x64', Result: NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
lower_triangular-methods 11.48 011.5
Please reduce each example to less than 5 sec.
Best,
Uwe Ligges
Triggers an email saying
1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
automatically*
2) *Please fix all problems and resubmit a fixed version via the webform*
While apparently nothing should be done, at least according to some forum
post
https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
It would be nice to avoid this from the test side or the email side. It
is
pretty confusing for developers who think that they have to act.
Best wishes.
*Stefano *
Stefano Mangiola | Postdoctoral fellow
Papenfuss Laboratory
The Walter Eliza Hall Institute of Medical Research
+61 (0)466452544
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 testthat, you typically have code chunks like this in your
test-files:
test_that("my_function", {
expect_false(...)
expect_equal(...)
})
Just insert a "testthat::skip_on_cran()" as first line in that code-chunk:
test_that("my_function", {
skip_on_cran()
expect_false(...)
expect_equal(...)
})
This will skip this particular test.
Another way if you want to run a complete test-file only locally depends on
versioning. I always use 4 decimals as version numbers for my packages in
development, e.g. package_0.1.2.3, and on CRAN, only three decimals:
package_0.1.3 (this related to the package version you define in the
DESCRIPTION file). If you follow this rules, you can set a global environment
variable in the main test file, when you use "testthat", you should insert
following code (change package name accordingly) in "testthat.R":
if (length(strsplit(packageDescription("my_package")$Version, "\\.")[[1]]) > 3)
{
Sys.setenv("RunAllPkgTests" = "yes")
} else {
Sys.setenv("RunAllPkgTests" = "no")
}
For versions on CRAN (i.e. version number like 0.1.0), the environment variable
"RunAllPkgTests" is "no", for your local package with version number like
0.1.0.1 this would be "yes". Then you wrap your complete test file into an
if-statement:
.runThisTest <- Sys.getenv("RunAllinsightTests") == "yes"
if (.runThisTest) {
# ... all my tests here
}
Here's a practical example:
https://github.com/easystats/insight/blob/master/tests/testthat.R
https://github.com/easystats/insight/blob/master/tests/testthat/test-bigglm.R
And for skip_on_cran() / skip_on_travis:
https://github.com/easystats/insight/blob/cddc6df6783aae859f2b707dd5a938493bff3aaa/tests/testthat/test-spatial.R#L141
Hope this helps!
Best
Daniel
-Ursprüngliche Nachricht-
Von: R-package-devel Im Auftrag von
Spencer Graves
Gesendet: Montag, 8. Juni 2020 16:53
An: r-package-devel@r-project.org
Betreff: Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility
... NOTE Maintainer
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 anything better. I've recently seen
"testthat::skip_on_cran(...)", but I have yet to understand enough of
how it works to actually use it.
Thanks,
Spencer Graves
On 2020-06-08 09:43, stefano wrote:
> 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:
>
>>
>> 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 for arch 'x64', Result: NOTE
>> Examples with CPU (user + system) or elapsed time > 10s
>> user system elapsed
>> lower_triangular-methods 11.48 011.5
>>
>> Please reduce each example to less than 5 sec.
>>
>> Best,
>> Uwe Ligges
>>> Triggers an email saying
>>>
>>>
>>> 1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
>>> automatically*
>>>
>>> 2) *Please fix all problems and resubmit a fixed version via the webform*
>>>
>>>
>>> While apparently nothing should be done, at least according to some forum
>>> post
>>>
>> https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
>>> It would be nice to avoid this from the test side or the email side. It
>> is
>>> pretty confusing for developers who think that they have to act.
>>>
>>>
>>> Best wishes.
>>>
>>> *Stefano *
>>>
>>>
>>>
>>> Stefano Mangiola | Postdoctoral fellow
>>>
>>> Papenfuss Laboratory
>>>
>>> The Walter Eliza Hall Institute of Medical Research
>>>
>>> +61 (0)466452544
>>>
>>>[[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 you want to run the additional tests. [...] That is exactly how testthat::skip_on_cran() works. If you set `NOT_CRAN="true"` then the test runs. And to make it more helpful, Travis, GitHub Actions, etc. automatically set it. Gabor Thanks to Luke and Gabor for enlighting me. Uwe __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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. [...] That is exactly how testthat::skip_on_cran() works. If you set `NOT_CRAN="true"` then the test runs. And to make it more helpful, Travis, GitHub Actions, etc. automatically set it. Gabor __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] Re: email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 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 anything better. I've recently seen
"testthat::skip_on_cran(...)", but I have yet to understand enough of how
it works to actually use it.
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.
Best,
Uwe Ligges
Thanks,
Spencer Graves
On 2020-06-08 09:43, stefano wrote:
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:
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 for arch 'x64', Result: NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
lower_triangular-methods 11.48 0 11.5
Please reduce each example to less than 5 sec.
Best,
Uwe Ligges
Triggers an email saying
1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
automatically*
2) *Please fix all problems and resubmit a fixed version via the
webform*
While apparently nothing should be done, at least according to some
forum
post
https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
It would be nice to avoid this from the test side or the email side. It
is
pretty confusing for developers who think that they have to act.
Best wishes.
*Stefano *
Stefano Mangiola | Postdoctoral fellow
Papenfuss Laboratory
The Walter Eliza Hall Institute of Medical Research
+61 (0)466452544
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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, but it has worked for me, and I
haven't found anything better. I've recently seen
"testthat::skip_on_cran(...)", but I have yet to understand enough of
how it works to actually use it.
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.
Best,
Uwe Ligges
Thanks,
Spencer Graves
On 2020-06-08 09:43, stefano wrote:
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:
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 for arch 'x64', Result: NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
lower_triangular-methods 11.48 0 11.5
Please reduce each example to less than 5 sec.
Best,
Uwe Ligges
Triggers an email saying
1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
automatically*
2) *Please fix all problems and resubmit a fixed version via the
webform*
While apparently nothing should be done, at least according to some
forum
post
https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
It would be nice to avoid this from the test side or the email side. It
is
pretty confusing for developers who think that they have to act.
Best wishes.
*Stefano *
Stefano Mangiola | Postdoctoral fellow
Papenfuss Laboratory
The Walter Eliza Hall Institute of Medical Research
+61 (0)466452544
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 anything better. I've recently seen
"testthat::skip_on_cran(...)", but I have yet to understand enough of
how it works to actually use it.
Thanks,
Spencer Graves
On 2020-06-08 09:43, stefano wrote:
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:
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 for arch 'x64', Result: NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
lower_triangular-methods 11.48 011.5
Please reduce each example to less than 5 sec.
Best,
Uwe Ligges
Triggers an email saying
1) *package nanny_0.1.7.tar.gz does not pass the incoming checks
automatically*
2) *Please fix all problems and resubmit a fixed version via the webform*
While apparently nothing should be done, at least according to some forum
post
https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer
It would be nice to avoid this from the test side or the email side. It
is
pretty confusing for developers who think that they have to act.
Best wishes.
*Stefano *
Stefano Mangiola | Postdoctoral fellow
Papenfuss Laboratory
The Walter Eliza Hall Institute of Medical Research
+61 (0)466452544
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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: > > > 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 for arch 'x64', Result: NOTE >Examples with CPU (user + system) or elapsed time > 10s > user system elapsed >lower_triangular-methods 11.48 011.5 > > Please reduce each example to less than 5 sec. > > Best, > Uwe Ligges > > > > Triggers an email saying > > > > > > 1) *package nanny_0.1.7.tar.gz does not pass the incoming checks > > automatically* > > > > 2) *Please fix all problems and resubmit a fixed version via the webform* > > > > > > While apparently nothing should be done, at least according to some forum > > post > > > https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer > > > > It would be nice to avoid this from the test side or the email side. It > is > > pretty confusing for developers who think that they have to act. > > > > > > Best wishes. > > > > *Stefano * > > > > > > > > Stefano Mangiola | Postdoctoral fellow > > > > Papenfuss Laboratory > > > > The Walter Eliza Hall Institute of Medical Research > > > > +61 (0)466452544 > > > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 for arch 'x64', Result: NOTE Examples with CPU (user + system) or elapsed time > 10s user system elapsed lower_triangular-methods 11.48 011.5 Please reduce each example to less than 5 sec. Best, Uwe Ligges Triggers an email saying 1) *package nanny_0.1.7.tar.gz does not pass the incoming checks automatically* 2) *Please fix all problems and resubmit a fixed version via the webform* While apparently nothing should be done, at least according to some forum post https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer It would be nice to avoid this from the test side or the email side. It is pretty confusing for developers who think that they have to act. Best wishes. *Stefano * Stefano Mangiola | Postdoctoral fellow Papenfuss Laboratory The Walter Eliza Hall Institute of Medical Research +61 (0)466452544 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] email misleading: checking CRAN incoming feasibility ... NOTE Maintainer
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 problems and resubmit a fixed version via the webform* While apparently nothing should be done, at least according to some forum post https://stackoverflow.com/questions/23829978/checking-cran-incoming-feasibility-note-maintainer It would be nice to avoid this from the test side or the email side. It is pretty confusing for developers who think that they have to act. Best wishes. *Stefano * Stefano Mangiola | Postdoctoral fellow Papenfuss Laboratory The Walter Eliza Hall Institute of Medical Research +61 (0)466452544 [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
