[R-pkg-devel] Vignette timing out on test server

2019-04-16 Thread Roy Mendelssohn - NOAA Federal via R-package-devel 
--- Begin Message ---
Hi All:

The package I am trying to get ready for submission has a Vignette that does a 
number of data downloads and some complicate maps with satellite images.  While 
it knits on my computer,  on checks it times out.  I am looking for ways to 
speed it up,  but my question is, is  there a command or a way to profile a 
vignette as it knits to  have a record to see which chunks are using up how 
much time?

I realize CRAN only runs the vignette code to check that it runs, but it must 
have a time limit because I am consistently hitting time outs on test machines. 
 So ti would help me if I can identify where all the time is.

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

2019-04-16 Thread Iñaki Ucar 
On Tue, 16 Apr 2019 at 20:54, Tan Zhou  wrote:
>
> Hi Iñaki and Ralf,
> Thank you very much for your help and suggestions.
> Yes, I followed instruction and did that. Now I have the 
> https://tankwin08.github.io/drat.
> But I test
>
> install.packages("rPeaks")
> Installing package into ‘C:/Users/tank/Documents/R/win-library/3.4’
> (as ‘lib’ is unspecified)
> Warning in install.packages :
>   unable to access index for repository 
> https://tankwin08.github.io/drat/bin/windows/contrib/3.4:
>   cannot open URL 
> 'https://tankwin08.github.io/drat/bin/windows/contrib/3.4/PACKAGES'
> Package which is only available in source form, and may need compilation of 
> C/C++/Fortran:
>   ‘rPeaks’
> Do you want to attempt to install these from sources?
>
> I can install it by typing y.
>
> For check my package, I changed it like this:
> Suggests:
> knitr,
> rPeaks
> Additional_repositories: https://tankwin08.github.io/drat
>
> But I conduct check, it still gives me a note:
> R CMD check results
> 0 errors | 0 warnings | 1 note
> checking package dependencies ... NOTE
> Package suggested but not available for checking: 'rPeaks'

You still need to install it in your computer to check it locally, as
with any other dependency.

-- 
Iñaki Úcar

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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

2019-04-16 Thread Tan Zhou 
Hi Iñaki and Ralf,
Thank you very much for your help and suggestions.
Yes, I followed instruction and did that. Now I have the
https://tankwin08.github.io/drat.
But I test

install.packages("rPeaks")
Installing package into ‘C:/Users/tank/Documents/R/win-library/3.4’
(as ‘lib’ is unspecified)
Warning in install.packages :
  unable to access index for repository
https://tankwin08.github.io/drat/bin/windows/contrib/3.4:
  cannot open URL '
https://tankwin08.github.io/drat/bin/windows/contrib/3.4/PACKAGES'
Package which is only available in source form, and may need compilation of
C/C++/Fortran:
  ‘rPeaks’
Do you want to attempt to install these from sources?

I can install it by typing y.

For check my package, I changed it like this:
Suggests:
knitr,
rPeaks
Additional_repositories: https://tankwin08.github.io/drat

But I conduct check, it still gives me a note:
R CMD check results
0 errors | 0 warnings | 1 note
checking package dependencies ... NOTE
Package suggested but not available for checking: 'rPeaks'

I guess it still may relate to the drat.
Or any suggestions? I deeply appreciated your effort and time.

Best
Tan




On Tue, Apr 16, 2019 at 4:00 AM Iñaki Ucar  wrote:

> You could convince the original author to submit rPeaks to CRAN, or
> volunteer to be the maintainer and do it yourself if he doesn't want
> to maintain it. That would be easier for you and better for everyone,
> because the package would be well-checked under the watchful eye of
> CRAN maintainers. Otherwise, see below.
>
> On Tue, 16 Apr 2019 at 03:15, Tan Zhou  wrote:
> >
> > Thank you very much for your suggestions and explanation, Ralf. They are
> > very helpful.
> > I got permission from the author and use *drat::addRepo("jrminter").*
> >
> > *When I try to test if this package can be installed with
> install.package*
> >
> > *install.packages("rPeaks", repos = "https://jrminter.github.io/drat/
> > ", type = "source")Warning in
> > install.packages :  unable to access index for repository
> > https://tankwin08.github.io/drat/src/contrib
> > :  cannot open URL
> > 'https://tankwin08.github.io/drat/src/contrib/PACKAGES
> > 'Warning in
> > install.packages :  unable to access index for repository
> > https://jrminter.github.io/drat/src/contrib
> > :  cannot open URL
> > 'https://jrminter.github.io/drat/src/contrib/PACKAGES
> > 'Installing
> package
> > into ‘C:/Users/tank/Documents/R/win-library/3.4’(as ‘lib’ is
> > unspecified)Warning in install.packages :  unable to access index for
> > repository https://jrminter.github.io/drat/src/contrib
> > :  cannot open URL
> > 'https://jrminter.github.io/drat/src/contrib/PACKAGES
> > 'Warning in
> > install.packages :  package ‘rPeaks’ is not available (for R version
> 3.4.3)*
> >
> > *Do you have any suggestion? *
>
> I see nothing in https://jrminter.github.io/drat or
> https://tankwin08.github.io/drat. First of all, someone (the author or
> you in his behalf) has to setup a drat repo, so please read and follow
> the guide for package authors:
>
>
> https://cran.r-project.org/web/packages/drat/vignettes/DratForPackageAuthors.html
>
> After you setup such a repo (if the original author didn't want to do
> it by himself and gave his permission) in your GitHub account and push
> jrminter's package, you should be able to do the following:
>
> drat::addRepo("tankwin08")
> install.packages("rPeaks")
>
> and that's it. So finally, you can add
>
> Additional_repositories: https://tankwin08.github.io/drat
>
> to your DESCRIPTION file.
>
> --
> Iñaki Úcar
>


-- 

Best regards

Tan Zhou

[[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] Submitting a package whose unit tests sometimes fail because of server connections

2019-04-16 Thread Iñaki Ucar 
On Tue, 16 Apr 2019 at 19:57, Will  wrote:
>
> Hello everyone,
>
> I'm sorry to bother you, but I would like some help getting a package (
> *suppdata*; https://github.com/ropensci/suppdata) available through CRAN.
> The package downloads supplementary materials from papers and data
> repositories on the basis of their DOI, making reproducible analyses a
> little easier to share and create.
>
> The package's unit tests involve downloading data, and when multiple
> requests for the same resource are sent from a single machine (as seems to
> be done by CRAN's testing servers) the data hosts will sometimes refuse the
> connection and so the package's tests will fail. I emphasise that the tests
> pass at Travis-CI (https://travis-ci.org/ropensci/suppdata) and OpenCPU (
> https://ropensci.ocpu.io/suppdata/info); I am confident this is a
> connection issue but I would be grateful to be shown I am wrong. I am not
> sure how to solve this problem, and was hoping you might have some advice.
> Some things I have considered include:
>
>
>1. Skipping all unit tests on CRAN (using something like
>*testtht::skip_on_cran*). This would immediately fix the problem, and as
>a mitigating factor we report automated test result and coverage on the
>package's GitHub page (https://github.com/ropensci/suppdata).

This doesn't seem a good idea.

>2. Using HTTP-mocking to avoid requiring a call to a server during tests
>at all. I would be uncomfortable relying solely on this for all tests,
>since if the data hosters changed things we wouldn't know. Thus I would
>still want the Internet-enabled tests, which would also have to be turned
>off for CRAN (see 1 above). This would also be a lot of additional work.

What about mocking on CRAN and run Internet-enabled tests otherwise?

>3. Somehow bypassing the requirement for the unit tests to all pass
>before the package is checked by the CRAN maintainers. I have no idea if
>this is something CRAN would be willing to do, or if it is even possible.
>It would be the easiest option for me, but I don't want to create extra
>work for other people!

I think it's acceptable to skip a test if something is not available,
but not the majority of them, for packages like this which basically
is about downloading stuff from APIs. Mocking on CRAN, as said before,
is the way to go here.

>4. Slowing the tests with something like *Sys.sleep*. This might work,
>but would slow the tests massively and so might that cause problems for
>CRAN?

This is not a good idea either.

-- 
Iñaki Úcar

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

Re: [R-pkg-devel] Submitting a package whose unit tests sometimes fail because of server connections

2019-04-16 Thread Dirk Eddelbuettel 


On 16 April 2019 at 11:40, Will wrote:
| Some things I have considered include:
| 
|1. Skipping all unit tests on CRAN (using something like
|*testtht::skip_on_cran*). This would immediately fix the problem, and as
|a mitigating factor we report automated test result and coverage on the
|package's GitHub page (https://github.com/ropensci/suppdata).
|2. Using HTTP-mocking to avoid requiring a call to a server during tests
|at all. I would be uncomfortable relying solely on this for all tests,
|since if the data hosters changed things we wouldn't know. Thus I would
|still want the Internet-enabled tests, which would also have to be turned
|off for CRAN (see 1 above). This would also be a lot of additional work.
|3. Somehow bypassing the requirement for the unit tests to all pass
|before the package is checked by the CRAN maintainers. I have no idea if
|this is something CRAN would be willing to do, or if it is even possible.
|It would be the easiest option for me, but I don't want to create extra
|work for other people!
|4. Slowing the tests with something like *Sys.sleep*. This might work,
|but would slow the tests massively and so might that cause problems for
|CRAN?
| 
| Does anyone have any advice as to which of the above would be the best
| option, or who I should email directly about this?

5. Run a hybrid scheme where you have multiple levels:

   5.1 Do what eg Rcpp does and only opt into 'all tests' when an overall
   variable is set; that variable can be set conveniently in .travis.yml
   and conditionally in your test runner below ~/tests/

   That way you can skip tests that would fail.

   5.2 Do a lot of work and wrap 3. above into try() / tryCatch() and pass
   if _your own aggregation of tests_ passes a threshold.

   Overkill to me.

   5.3 Turn all tests on / off based on some other toggle. I.e. I don't think
   I test all features of RcppRedis on CRAN as I can't assume a redis
   server, but I do run those tests at home, on Travis, ...

Overall, I would recommend to 'keep it simple & stupid' (KISS) as life is to
short to argue^Hdebate this with CRAN. And their time is too precious so we
should try to make their life easier.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Submitting a package whose unit tests sometimes fail because of server connections

2019-04-16 Thread Steven Scott 
I'd mock the tests you want run on Cran and keep live fire tests that you
can run manually.  Just don't include the live fire stuff in the package.

On Tue, Apr 16, 2019, 10:57 AM Will  wrote:

> Hello everyone,
>
> I'm sorry to bother you, but I would like some help getting a package (
> *suppdata*; https://github.com/ropensci/suppdata) available through CRAN.
> The package downloads supplementary materials from papers and data
> repositories on the basis of their DOI, making reproducible analyses a
> little easier to share and create.
>
> The package's unit tests involve downloading data, and when multiple
> requests for the same resource are sent from a single machine (as seems to
> be done by CRAN's testing servers) the data hosts will sometimes refuse the
> connection and so the package's tests will fail. I emphasise that the tests
> pass at Travis-CI (https://travis-ci.org/ropensci/suppdata) and OpenCPU (
> https://ropensci.ocpu.io/suppdata/info); I am confident this is a
> connection issue but I would be grateful to be shown I am wrong. I am not
> sure how to solve this problem, and was hoping you might have some advice.
> Some things I have considered include:
>
>
>1. Skipping all unit tests on CRAN (using something like
>*testtht::skip_on_cran*). This would immediately fix the problem, and as
>a mitigating factor we report automated test result and coverage on the
>package's GitHub page (https://github.com/ropensci/suppdata).
>2. Using HTTP-mocking to avoid requiring a call to a server during tests
>at all. I would be uncomfortable relying solely on this for all tests,
>since if the data hosters changed things we wouldn't know. Thus I would
>still want the Internet-enabled tests, which would also have to be
> turned
>off for CRAN (see 1 above). This would also be a lot of additional work.
>3. Somehow bypassing the requirement for the unit tests to all pass
>before the package is checked by the CRAN maintainers. I have no idea if
>this is something CRAN would be willing to do, or if it is even
> possible.
>It would be the easiest option for me, but I don't want to create extra
>work for other people!
>4. Slowing the tests with something like *Sys.sleep*. This might work,
>but would slow the tests massively and so might that cause problems for
>CRAN?
>
> Does anyone have any advice as to which of the above would be the best
> option, or who I should email directly about this?
>
> Thank you for your help, and I apologise if I've missed some aspect of the
> documentation that already explains how to solve this,
>
> Will Pearse
>
> ---
>
> Need a phylogeny? Try phyloGenerator: original
>  or new version
> 
> Measuring phylogenetic structure? Try install.packages('pez')
>
> Will Pearse 
> Assistant Professor of Biology, Utah State University
> Office: +1-435-797-0831; Room LSB-333
> Skype: will.pearse
>
> [[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: [Rd] Feature request: make file.exists interruptable

2019-04-16 Thread Prof Brian Ripley 

The place for feature requests is bugs.r-project.org .

On 15/04/2019 18:44, Christopher Hammill wrote:

Hi R developers,

On slow file systems with large lists of files, file.exists can take a long 
time to run. It would be nice if users could interrupt this function. I think 
it would be simple to add:

https://svn.r-project.org/R/trunk/src/main/platform.c,

at line 1373, add "R_CheckUserInterrupt();" perhaps every some number of 
iterations if performance is a concern here.


It is a concern, and it is (very) unusual to call file.exists() on more 
than one file (as its name implies).  Perhaps you could give us some 
idea of what you are trying to do and how many files take how many 
seconds on what OS/filesystem.


For completeness, dir.exists() can be used with more than one path and 
potentially has the same issue.


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

2019-04-16 Thread Iñaki Ucar 
You could convince the original author to submit rPeaks to CRAN, or
volunteer to be the maintainer and do it yourself if he doesn't want
to maintain it. That would be easier for you and better for everyone,
because the package would be well-checked under the watchful eye of
CRAN maintainers. Otherwise, see below.

On Tue, 16 Apr 2019 at 03:15, Tan Zhou  wrote:
>
> Thank you very much for your suggestions and explanation, Ralf. They are
> very helpful.
> I got permission from the author and use *drat::addRepo("jrminter").*
>
> *When I try to test if this package can be installed with install.package*
>
> *install.packages("rPeaks", repos = "https://jrminter.github.io/drat/
> ", type = "source")Warning in
> install.packages :  unable to access index for repository
> https://tankwin08.github.io/drat/src/contrib
> :  cannot open URL
> 'https://tankwin08.github.io/drat/src/contrib/PACKAGES
> 'Warning in
> install.packages :  unable to access index for repository
> https://jrminter.github.io/drat/src/contrib
> :  cannot open URL
> 'https://jrminter.github.io/drat/src/contrib/PACKAGES
> 'Installing package
> into ‘C:/Users/tank/Documents/R/win-library/3.4’(as ‘lib’ is
> unspecified)Warning in install.packages :  unable to access index for
> repository https://jrminter.github.io/drat/src/contrib
> :  cannot open URL
> 'https://jrminter.github.io/drat/src/contrib/PACKAGES
> 'Warning in
> install.packages :  package ‘rPeaks’ is not available (for R version 3.4.3)*
>
> *Do you have any suggestion? *

I see nothing in https://jrminter.github.io/drat or
https://tankwin08.github.io/drat. First of all, someone (the author or
you in his behalf) has to setup a drat repo, so please read and follow
the guide for package authors:

https://cran.r-project.org/web/packages/drat/vignettes/DratForPackageAuthors.html

After you setup such a repo (if the original author didn't want to do
it by himself and gave his permission) in your GitHub account and push
jrminter's package, you should be able to do the following:

drat::addRepo("tankwin08")
install.packages("rPeaks")

and that's it. So finally, you can add

Additional_repositories: https://tankwin08.github.io/drat

to your DESCRIPTION file.

-- 
Iñaki Úcar

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

Re: [R-pkg-devel] Package suggested but not available for checking: 'rPeaks'; Additional_repositories

2019-04-16 Thread Ralf Stubner 
On 16.04.19 03:15, Tan Zhou wrote:
> install.packages("rPeaks", repos = "https://jrminter.github.io/drat/;,
> type = "source")
> Warning in install.packages :
>   unable to access index for repository
> https://tankwin08.github.io/drat/src/contrib:
>   cannot open URL 'https://tankwin08.github.io/drat/src/contrib/PACKAGES'
> Warning in install.packages :
>   unable to access index for repository
> https://jrminter.github.io/drat/src/contrib:
>   cannot open URL 'https://jrminter.github.io/drat/src/contrib/PACKAGES'
> Installing package into ‘C:/Users/tank/Documents/R/win-library/3.4’
> (as ‘lib’ is unspecified)
> Warning in install.packages :
>   unable to access index for repository
> https://jrminter.github.io/drat/src/contrib:
>   cannot open URL 'https://jrminter.github.io/drat/src/contrib/PACKAGES'
> Warning in install.packages :
>   package ‘rPeaks’ is not available (for R version 3.4.3)

Either you or the rPeaks author should create a repository on GitHub
named 'drat', possibly by forking the original 'drat' repo. Please read
the corresponding vignette
https://cran.r-project.org/web/packages/drat/vignettes/DratForPackageAuthors.html
for the full details.

cheerio
ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustraße 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stub...@daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Geschäftsführer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze



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