Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
Ah, brilliant. Thanks. On Sun, Jun 14, 2020 at 11:28:17AM -0400, Duncan Murdoch wrote: > On 14/06/2020 10:59 a.m., Joshua N Pritikin wrote: > > On Sun, Jun 14, 2020 at 09:17:32AM -0400, Duncan Murdoch wrote: > > > knitr::opts_chunk$set(eval = !is_CRAN) > > > > This works except for in-text `r 1+1` code fragments. Is there an option > > to make these evaluate to "[MISSING]" or similar? > > To suppress evaluation of those, you can use this: > > knitr::knit_hooks$set(evaluate.inline = function(x, envir) x) __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
On 14/06/2020 10:59 a.m., Joshua N Pritikin wrote: On Sun, Jun 14, 2020 at 09:17:32AM -0400, Duncan Murdoch wrote: Since you're using Rmarkdown, you can use a variable for the eval chunk option, e.g. put this in your setup chunk: knitr::opts_chunk$set(eval = !is_CRAN) This works except for in-text `r 1+1` code fragments. Is there an option to make these evaluate to "[MISSING]" or similar? To suppress evaluation of those, you can use this: knitr::knit_hooks$set(evaluate.inline = function(x, envir) x) This will show the code in place of evaluating it and showing its value. Replace the function value with "[MISSING]" if you don't want to see the code. Duncan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
On Sun, Jun 14, 2020 at 09:17:32AM -0400, Duncan Murdoch wrote: > Since you're using Rmarkdown, you can use a variable for the eval > chunk option, e.g. put this in your setup chunk: > > knitr::opts_chunk$set(eval = !is_CRAN) This works except for in-text `r 1+1` code fragments. Is there an option to make these evaluate to "[MISSING]" or similar? __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
Ah, thank you!
Sorry for the duplicate posts.
On Sun, Jun 14, 2020 at 09:17:32AM -0400, Duncan Murdoch wrote:
> On 13/06/2020 1:29 p.m., Joshua N Pritikin wrote:
> >
> > I'm trying to include vignettes that take much too long for CRAN check.
> >
> > At the beginning of the Rmarkdown vignette, I use
> >
> >is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
> >if (is_CRAN) q()
> >
> > And then I use
> >
> >export NOT_CRAN=true
> >
> > when I build locally. But CRAN check still complains,
>
> You shouldn't call q() from a vignette. Since you're using Rmarkdown, you
> can use a variable for the eval chunk option, e.g. put this in your setup
> chunk:
>
> knitr::opts_chunk$set(eval = !is_CRAN)
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
On 13/06/2020 1:29 p.m., Joshua N Pritikin wrote:
I'm trying to include vignettes that take much too long for CRAN check.
At the beginning of the Rmarkdown vignette, I use
is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
if (is_CRAN) q()
And then I use
export NOT_CRAN=true
when I build locally. But CRAN check still complains,
You shouldn't call q() from a vignette. Since you're using Rmarkdown,
you can use a variable for the eval chunk option, e.g. put this in your
setup chunk:
knitr::opts_chunk$set(eval = !is_CRAN)
Duncan Murdoch
On Mon, Jun 08, 2020 at 04:24:43PM +0200, lig...@statistik.tu-dortmund.de wrote:
Flavor: r-devel-linux-x86_64-debian-gcc
Check: re-building of vignette outputs, Result: WARNING
Error(s) in re-building vignettes:
...
--- re-building 'GeneEnvironmentInteraction.Rmd' using rmarkdown
--- re-building 'OneFactorModel.Rmd' using rmarkdown
--- re-building 'PostGWASprocessing.Rmd' using rmarkdown
--- re-building 'ResidualsModel.Rmd' using rmarkdown
--- re-building 'StandardGWAS.Rmd' using rmarkdown
--- re-building 'TwoFactorModel.Rmd' using rmarkdown
--- re-building 'UserSpecifiedGWASModels.Rmd' using rmarkdown
--- re-building 'growth.Rmd' using rmarkdown
Error: Vignette re-building failed.
Execution halted
What's the correct way to avoid CRAN complaints?
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problem with test data folder. R package develpoment
Use a different name than "data" such as "rawdata" within "inst" to put files that your code refers to using the system.name() function. The directory name "data" is used for a specific purpose as described in the Writing R Extensions manual [1], and if you want to put files in that directory following those special requirements then they must be in the top level "data" directory. [1] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Data-in-packages On June 14, 2020 1:55:50 AM PDT, Subhadip Datta wrote: >I attached my test data in inst/data but why this warning is showing. >"Found the following non-empty subdirectories of 'inst' also used by R: >inst/data > It is recommended not to interfere with package subdirectories used by > R." >This is not a problem from my side. It used the data from that >directory but showed an error for the folder. -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
On Sun, 14 Jun 2020 at 14:32, Joshua N Pritikin wrote:
>
>
> I'm trying to include vignettes that take much too long for CRAN check.
>
> At the beginning of the Rmarkdown vignette, I use
>
> is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
> if (is_CRAN) q()
>
> And then I use
>
> export NOT_CRAN=true
>
> when I build locally. But CRAN check still complains,
Because you're just exiting and nothing is generated. Instead, you
should mark all chunks as eval=FALSE. You could use something as
follows in the initial chunk:
if (is_CRAN) knitr::opts_chunk$set(eval = FALSE)
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
I'm trying to include vignettes that take much too long for CRAN check.
At the beginning of the Rmarkdown vignette, I use
is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
if (is_CRAN) q()
And then I use
export NOT_CRAN=true
when I build locally. But CRAN check still complains,
On Mon, Jun 08, 2020 at 04:24:43PM +0200, lig...@statistik.tu-dortmund.de wrote:
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> ...
> --- re-building 'GeneEnvironmentInteraction.Rmd' using rmarkdown
> --- re-building 'OneFactorModel.Rmd' using rmarkdown
> --- re-building 'PostGWASprocessing.Rmd' using rmarkdown
> --- re-building 'ResidualsModel.Rmd' using rmarkdown
> --- re-building 'StandardGWAS.Rmd' using rmarkdown
> --- re-building 'TwoFactorModel.Rmd' using rmarkdown
> --- re-building 'UserSpecifiedGWASModels.Rmd' using rmarkdown
> --- re-building 'growth.Rmd' using rmarkdown
> Error: Vignette re-building failed.
> Execution halted
What's the correct way to avoid CRAN complaints?
--
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://exuberant-island.surge.sh
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
I'm trying to include vignettes that take much too long for CRAN check.
At the beginning of the Rmarkdown vignette, I use
is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
if (is_CRAN) q()
And then I use
export NOT_CRAN=true
when I build locally. But CRAN check still complains,
On Mon, Jun 08, 2020 at 04:24:43PM +0200, lig...@statistik.tu-dortmund.de wrote:
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> ...
> --- re-building 'GeneEnvironmentInteraction.Rmd' using rmarkdown
> --- re-building 'OneFactorModel.Rmd' using rmarkdown
> --- re-building 'PostGWASprocessing.Rmd' using rmarkdown
> --- re-building 'ResidualsModel.Rmd' using rmarkdown
> --- re-building 'StandardGWAS.Rmd' using rmarkdown
> --- re-building 'TwoFactorModel.Rmd' using rmarkdown
> --- re-building 'UserSpecifiedGWASModels.Rmd' using rmarkdown
> --- re-building 'growth.Rmd' using rmarkdown
> Error: Vignette re-building failed.
> Execution halted
What's the correct way to avoid CRAN complaints?
--
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://exuberant-island.surge.sh
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Problem with test data folder. R package develpoment
I attached my test data in inst/data but why this warning is showing. "Found the following non-empty subdirectories of 'inst' also used by R: inst/data It is recommended not to interfere with package subdirectories used by R." This is not a problem from my side. It used the data from that directory but showed an error for the folder. -- *-* *Mr. Subhadip Datta* -- M.Sc in Remote Sensing and GIS Vidyasagar University 8348703617 subhadipda...@live.com subhadipdatta...@gmail.com [[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] [CRAN-pretest-archived] CRAN submission gwsem 2.0.3
I'm trying to include vignettes that take much too long for CRAN check.
At the beginning of the Rmarkdown vignette, I use
is_CRAN <- !identical(Sys.getenv("NOT_CRAN"), "true")
if (is_CRAN) q()
And then I use
export NOT_CRAN=true
when I build locally. But CRAN check still complains,
On Mon, Jun 08, 2020 at 04:24:43PM +0200, lig...@statistik.tu-dortmund.de wrote:
> Flavor: r-devel-linux-x86_64-debian-gcc
> Check: re-building of vignette outputs, Result: WARNING
> Error(s) in re-building vignettes:
> ...
> --- re-building 'GeneEnvironmentInteraction.Rmd' using rmarkdown
> --- re-building 'OneFactorModel.Rmd' using rmarkdown
> --- re-building 'PostGWASprocessing.Rmd' using rmarkdown
> --- re-building 'ResidualsModel.Rmd' using rmarkdown
> --- re-building 'StandardGWAS.Rmd' using rmarkdown
> --- re-building 'TwoFactorModel.Rmd' using rmarkdown
> --- re-building 'UserSpecifiedGWASModels.Rmd' using rmarkdown
> --- re-building 'growth.Rmd' using rmarkdown
> Error: Vignette re-building failed.
> Execution halted
What's the correct way to avoid CRAN complaints?
--
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://exuberant-island.surge.sh
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
I agree with almost everything you wrote, except one thing: this isn't
newly enforced, it has been enforced since the help system began. What
I think is new is that there are now tests for it. Previously those
links just wouldn't work.
Duncan Murdoch
On 14/06/2020 6:26 a.m., Gábor Csárdi wrote:
On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
wrote:
[...]
I think the argument was that static builds of the help pages would have
trouble resolving the links. With the current system, you can build a
help page that links to a page in package foo even if package foo is not
installed yet, and have the link work later after you install foo.
That is true, but it is also not a big problem, I think. The CRAN
Windows R installer does indeed build static help pages by default.
But the built-in web server that serves these works around broken
links by treating them as help topics instead of files. As you know.
:) So this would only be a problem if you wanted to serve the static
help pages with another web server. (Which is not a bad use case, but
then maybe Rd2HTML() can just resolve them as topics and avoid the
broken links.)
Btw. the problem of linking to the wrong page is even worse with
static builds of help pages, because if a link w/o a package (e.g.
\link{filter}) picks up the wrong package at install time, then the
wrong link is hard-coded in the html. If you are building binary
packages, then they will link to the wrong help pages.
WRE says that specifying the package in the link is rarely needed.
This was probably the case some time ago, especially when packages did
not have (compulsory) namespaces. But I am not sure if it still holds.
I would argue that it is better to specify the package you are linking
to. But the newly enforced requirement that we need to link to files
instead of topics makes this more error prone.
Gabor
[...]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On Sun, Jun 14, 2020 at 10:44 AM Duncan Murdoch
wrote:
[...]
>
> I think the argument was that static builds of the help pages would have
> trouble resolving the links. With the current system, you can build a
> help page that links to a page in package foo even if package foo is not
> installed yet, and have the link work later after you install foo.
That is true, but it is also not a big problem, I think. The CRAN
Windows R installer does indeed build static help pages by default.
But the built-in web server that serves these works around broken
links by treating them as help topics instead of files. As you know.
:) So this would only be a problem if you wanted to serve the static
help pages with another web server. (Which is not a bad use case, but
then maybe Rd2HTML() can just resolve them as topics and avoid the
broken links.)
Btw. the problem of linking to the wrong page is even worse with
static builds of help pages, because if a link w/o a package (e.g.
\link{filter}) picks up the wrong package at install time, then the
wrong link is hard-coded in the html. If you are building binary
packages, then they will link to the wrong help pages.
WRE says that specifying the package in the link is rarely needed.
This was probably the case some time ago, especially when packages did
not have (compulsory) namespaces. But I am not sure if it still holds.
I would argue that it is better to specify the package you are linking
to. But the newly enforced requirement that we need to link to files
instead of topics makes this more error prone.
Gabor
[...]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
