date:20180319

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

2018-03-19 Thread Iñaki Úcar

2018-03-19 3:57 GMT+01:00 Tim Keitt :
> http://www.keittlab.org/
>
> On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel  wrote:
>
>>
>> Tim,
>>
>> On 18 March 2018 at 18:58, Tim Keitt wrote:
>> | I have an Rmd vignette that runs some benchmarks. It takes long enough
>> (20+
>> | minutes) that eg TravisCI will choke. I've not tried submitting to CRAN.
>> | What is the best practice for handling this situation? Do I generate
>> | HTML/PDF output locally and try to make them static? The vignette builder
>> | is knitr. I know about the R.rsp package but I do not know if it handles
>> | Rmd files.
>>
>> Tests are tickled from a runner script such as either one of
>>
>>   tests/doRUnit.R
>>   tests/testthat.R
>>
>> so you have an entry point to control for environment variables.
>>
>> Travis clearly documents what theirs are -- so you could just turn it off
>> --
>> and I have opted (years ago) for a more endogeneous scheme of suppressing
>> tests on CRAN based on version numbers (as I suppress tests when version
>> numbers are "release-style" form 'a.b.c', but then run the tests when the
>> version number is "dev-style" ie a.b.c.d).
>>
>
> That's a great idea, however my problem is with building a vignette, not
> running tests, unless they are linked in some way I'm not understanding.

One of my packages on CRAN contains a vignette with a benchmark. You
can check what I do here (search for "microbenchmark"):

https://raw.githubusercontent.com/r-simmer/simmer/master/vignettes/simmer-07-ctmc.Rmd

Basically, those chunks that use microbenchmark are marked as
"eval=FALSE", and the resulting figures are static images. I run those
manually and update the images from time to time if something relevant
changed. Apart from saving compilation time, this way I don't need to
include microbenchmark as a dependency.

Iñaki

>
> THK
>
>
>>
>> You can alternatively check for CRAN via an env.var; I forget what it is
>> called and cannot grep for it as my scheme does not need it. WRE may tell
>> you
>> what it is.
>>
>> Hth,  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] Avoid reprocessing Rmd vignette

2018-03-19 Thread Thierry Onkelinx

You can make things even a bit easier by setting "eval=myeval" and set
"myeval <- FALSE" at the top of the vignette. In case you want to update
the figures, you only have to set "myeval <- TRUE" and run the vignette.


ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///



2018-03-19 8:18 GMT+01:00 Iñaki Úcar :

> 2018-03-19 3:57 GMT+01:00 Tim Keitt :
> > http://www.keittlab.org/
> >
> > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel 
> wrote:
> >
> >>
> >> Tim,
> >>
> >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> >> | I have an Rmd vignette that runs some benchmarks. It takes long enough
> >> (20+
> >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> CRAN.
> >> | What is the best practice for handling this situation? Do I generate
> >> | HTML/PDF output locally and try to make them static? The vignette
> builder
> >> | is knitr. I know about the R.rsp package but I do not know if it
> handles
> >> | Rmd files.
> >>
> >> Tests are tickled from a runner script such as either one of
> >>
> >>   tests/doRUnit.R
> >>   tests/testthat.R
> >>
> >> so you have an entry point to control for environment variables.
> >>
> >> Travis clearly documents what theirs are -- so you could just turn it
> off
> >> --
> >> and I have opted (years ago) for a more endogeneous scheme of
> suppressing
> >> tests on CRAN based on version numbers (as I suppress tests when version
> >> numbers are "release-style" form 'a.b.c', but then run the tests when
> the
> >> version number is "dev-style" ie a.b.c.d).
> >>
> >
> > That's a great idea, however my problem is with building a vignette, not
> > running tests, unless they are linked in some way I'm not understanding.
>
> One of my packages on CRAN contains a vignette with a benchmark. You
> can check what I do here (search for "microbenchmark"):
>
> https://raw.githubusercontent.com/r-simmer/simmer/master/
> vignettes/simmer-07-ctmc.Rmd
>
> Basically, those chunks that use microbenchmark are marked as
> "eval=FALSE", and the resulting figures are static images. I run those
> manually and update the images from time to time if something relevant
> changed. Apart from saving compilation time, this way I don't need to
> include microbenchmark as a dependency.
>
> Iñaki
>
> >
> > THK
> >
> >
> >>
> >> You can alternatively check for CRAN via an env.var; I forget what it is
> >> called and cannot grep for it as my scheme does not need it. WRE may
> tell
> >> you
> >> what it is.
> >>
> >> Hth,  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
>

[[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] Avoid reprocessing Rmd vignette

2018-03-19 Thread Dirk Eddelbuettel


On 18 March 2018 at 21:57, Tim Keitt wrote:
| That's a great idea, however my problem is with building a vignette, not
| running tests, unless they are linked in some way I'm not understanding.

Similar idea applies: condition, just as Inaki and Thierry suggested.  An
example for a conditional vignette evaluation is 

```{r echo = FALSE, message = FALSE}`r ''`
hasData <- requireNamespace("hurricaneexposuredata", quietly = TRUE)
#1
if (!hasData) { 
#2
knitr::opts_chunk$set(eval = FALSE) 
#3
msg <- paste("Note: Examples in this vignette require that the", 
 "`hurricaneexposuredata` package be installed. The system",
 "currently running this vignette does not have that package",
 "installed, so code examples will not be evaluated.")
msg <- paste(strwrap(msg), collapse="\n")
message(msg)
#4
}
```

and the paper (https://journal.r-project.org/archive/2017/RJ-2017-026/) by
Brooke Anderson and myself discusses #1 to #4.

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

[R-pkg-devel] Very large packages in Additional_repositories

2018-03-19 Thread Hugh Parsonage

Dear list,

I'm considering submitting a package to CRAN. The package would be a
'foyer' or API to a much larger package (>1GB tarball) containing
geographical data that the 'foyer' package would use to perform tasks
like geocoding. The foyer package would be usable, though quite
limited, as a standalone package, and I can technically pass an R CMD
check by placing the 1 GB package in Suggests and using an
Additional_repository, but it takes a long time to retrieve and
install from the Additional_repository. While I believe the downside
of long install times would be acceptable for end-users (who would
only need to install the package once a year), for CRAN it could
occupy a large part of the check farm and have to occur much more
frequently.

The package once installed makes good use of lazy loading; in
particular, it would be basically unusable if the CRAN package had to
connect and download the necessary pieces from the large package each
time it was required. I thought about breaking up the package into
lots of little packages; however, even though the package is not
strictly atomic, its indivisible elements would still be too large for
CRAN.

My questions are:
  would this 'foyer' package be acceptable to CRAN? and, if so,
  what can I do so that the foyer package doesn't eat up CRAN's
computing resources (either on submission or once accepted) when
checking Suggests:


Best,

Hugh.

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

Re: [R-pkg-devel] Very large packages in Additional_repositories

2018-03-19 Thread Brian G. Peterson



Why not add an install function to foyer that would get the large data package?
Have examples and vignette use a small test data set, so only end users would 
actually install the large data set.
Regards,
Brian


--Brian G. Peterson ph: 773-459-4973im: bgpbraverockSent from my mobile, please 
excuse my brevity. 

 Original message 
From: Hugh Parsonage  
Date: 3/19/18  07:11  (GMT-06:00) 
To: R-package-devel  
Subject: [R-pkg-devel] Very large packages in Additional_repositories 

Dear list,

I'm considering submitting a package to CRAN. The package would be a
'foyer' or API to a much larger package (>1GB tarball) containing
geographical data that the 'foyer' package would use to perform tasks
like geocoding. The foyer package would be usable, though quite
limited, as a standalone package, and I can technically pass an R CMD
check by placing the 1 GB package in Suggests and using an
Additional_repository, but it takes a long time to retrieve and
install from the Additional_repository. While I believe the downside
of long install times would be acceptable for end-users (who would
only need to install the package once a year), for CRAN it could
occupy a large part of the check farm and have to occur much more
frequently.

The package once installed makes good use of lazy loading; in
particular, it would be basically unusable if the CRAN package had to
connect and download the necessary pieces from the large package each
time it was required. I thought about breaking up the package into
lots of little packages; however, even though the package is not
strictly atomic, its indivisible elements would still be too large for
CRAN.

My questions are:
  would this 'foyer' package be acceptable to CRAN? and, if so,
  what can I do so that the foyer package doesn't eat up CRAN's
computing resources (either on submission or once accepted) when
checking Suggests:


Best,

Hugh.

__
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] Avoid reprocessing Rmd vignette

2018-03-19 Thread Tim Keitt

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 2:18 AM, Iñaki Úcar  wrote:

> 2018-03-19 3:57 GMT+01:00 Tim Keitt :
> > http://www.keittlab.org/
> >
> > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel 
> wrote:
> >
> >>
> >> Tim,
> >>
> >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> >> | I have an Rmd vignette that runs some benchmarks. It takes long enough
> >> (20+
> >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> CRAN.
> >> | What is the best practice for handling this situation? Do I generate
> >> | HTML/PDF output locally and try to make them static? The vignette
> builder
> >> | is knitr. I know about the R.rsp package but I do not know if it
> handles
> >> | Rmd files.
> >>
> >> Tests are tickled from a runner script such as either one of
> >>
> >>   tests/doRUnit.R
> >>   tests/testthat.R
> >>
> >> so you have an entry point to control for environment variables.
> >>
> >> Travis clearly documents what theirs are -- so you could just turn it
> off
> >> --
> >> and I have opted (years ago) for a more endogeneous scheme of
> suppressing
> >> tests on CRAN based on version numbers (as I suppress tests when version
> >> numbers are "release-style" form 'a.b.c', but then run the tests when
> the
> >> version number is "dev-style" ie a.b.c.d).
> >>
> >
> > That's a great idea, however my problem is with building a vignette, not
> > running tests, unless they are linked in some way I'm not understanding.
>
> One of my packages on CRAN contains a vignette with a benchmark. You
> can check what I do here (search for "microbenchmark"):
>
> https://raw.githubusercontent.com/r-simmer/simmer/master/
> vignettes/simmer-07-ctmc.Rmd
>
> Basically, those chunks that use microbenchmark are marked as
> "eval=FALSE", and the resulting figures are static images. I run those
> manually and update the images from time to time if something relevant
> changed. Apart from saving compilation time, this way I don't need to
> include microbenchmark as a dependency.
>

Thanks. That is helpful.

I thought I had tried this method with a recent package and still ran into
problems with CRAN. The issue seemed to be that the R code is extracted
from the knitted output and run a second time where the chunk options no
longer apply. At least I thought that was what was happening. Glad to hear
this can work if so.

(Incidentally, I don't use microbenchmark for this one as I need to
generate random data per trial and don't want to include that in the
timing. A few lines of C++ does the trick.)

THK


>
> Iñaki
>
> >
> > THK
> >
> >
> >>
> >> You can alternatively check for CRAN via an env.var; I forget what it is
> >> called and cannot grep for it as my scheme does not need it. WRE may
> tell
> >> you
> >> what it is.
> >>
> >> Hth,  Dirk
> >>
> >> --
> >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[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] Avoid reprocessing Rmd vignette

2018-03-19 Thread Tim Keitt

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 3:29 AM, Thierry Onkelinx 
wrote:

> You can make things even a bit easier by setting "eval=myeval" and set
> "myeval <- FALSE" at the top of the vignette. In case you want to update
> the figures, you only have to set "myeval <- TRUE" and run the vignette.
>

Thanks. Yes, that is quite useful. I was thinking of making the entire
vignette "asis" but this approach is an alternative. As in my other email,
I ran into some problems with CRAN using this but perhaps I got it wrong.

THK


>
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> 
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> 
> ///
>
> 
>
> 2018-03-19 8:18 GMT+01:00 Iñaki Úcar :
>
> > 2018-03-19 3:57 GMT+01:00 Tim Keitt :
> > > http://www.keittlab.org/
> > >
> > > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel 
> > wrote:
> > >
> > >>
> > >> Tim,
> > >>
> > >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> > >> | I have an Rmd vignette that runs some benchmarks. It takes long
> enough
> > >> (20+
> > >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> > CRAN.
> > >> | What is the best practice for handling this situation? Do I generate
> > >> | HTML/PDF output locally and try to make them static? The vignette
> > builder
> > >> | is knitr. I know about the R.rsp package but I do not know if it
> > handles
> > >> | Rmd files.
> > >>
> > >> Tests are tickled from a runner script such as either one of
> > >>
> > >>   tests/doRUnit.R
> > >>   tests/testthat.R
> > >>
> > >> so you have an entry point to control for environment variables.
> > >>
> > >> Travis clearly documents what theirs are -- so you could just turn it
> > off
> > >> --
> > >> and I have opted (years ago) for a more endogeneous scheme of
> > suppressing
> > >> tests on CRAN based on version numbers (as I suppress tests when
> version
> > >> numbers are "release-style" form 'a.b.c', but then run the tests when
> > the
> > >> version number is "dev-style" ie a.b.c.d).
> > >>
> > >
> > > That's a great idea, however my problem is with building a vignette,
> not
> > > running tests, unless they are linked in some way I'm not
> understanding.
> >
> > One of my packages on CRAN contains a vignette with a benchmark. You
> > can check what I do here (search for "microbenchmark"):
> >
> > https://raw.githubusercontent.com/r-simmer/simmer/master/
> > vignettes/simmer-07-ctmc.Rmd
> >
> > Basically, those chunks that use microbenchmark are marked as
> > "eval=FALSE", and the resulting figures are static images. I run those
> > manually and update the images from time to time if something relevant
> > changed. Apart from saving compilation time, this way I don't need to
> > include microbenchmark as a dependency.
> >
> > Iñaki
> >
> > >
> > > THK
> > >
> > >
> > >>
> > >> You can alternatively check for CRAN via an env.var; I forget what it
> is
> > >> called and cannot grep for it as my scheme does not need it. WRE may
> > tell
> > >> you
> > >> what it is.
> > >>
> > >> Hth,  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
> >
>
> [[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] Avoid reprocessing Rmd vignette

2018-03-19 Thread Tim Keitt

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 6:41 AM, Dirk Eddelbuettel  wrote:

>
> On 18 March 2018 at 21:57, Tim Keitt wrote:
> | That's a great idea, however my problem is with building a vignette, not
> | running tests, unless they are linked in some way I'm not understanding.
>
> Similar idea applies: condition, just as Inaki and Thierry suggested.  An
> example for a conditional vignette evaluation is
>
> ```{r echo = FALSE, message = FALSE}`r ''`
> hasData <- requireNamespace("hurricaneexposuredata", quietly = TRUE)
>   #1
> if (!hasData) {
>  #2
> knitr::opts_chunk$set(eval = FALSE)
>  #3
> msg <- paste("Note: Examples in this vignette require that the",
>  "`hurricaneexposuredata` package be installed. The
> system",
>  "currently running this vignette does not have that
> package",
>  "installed, so code examples will not be evaluated.")
> msg <- paste(strwrap(msg), collapse="\n")
> message(msg)
>   #4
> }
> ```
>

That's a great solution. I've used something similar eg
https://raw.githubusercontent.com/thk686/strider/master/vignettes/strider.Rmd

I'm still confused however as I was sure that my code chunks were run
during CRAN check even when the eval option was set to false. But its
sounding like I made the wrong assumption. Not sure why it did not work
before.

THK


>
> and the paper (https://journal.r-project.org/archive/2017/RJ-2017-026/) by
> Brooke Anderson and myself discusses #1 to #4.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[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] Avoid reprocessing Rmd vignette

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

[R-pkg-devel] Very large packages in Additional_repositories

Re: [R-pkg-devel] Very large packages in Additional_repositories

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

8 matches

Site Navigation

Mail list logo

Footer information