[R-pkg-devel] Warning Message on Vignettes
(Reposting..)
Hi everyone,
I am getting following two warnings when I submit my R package (perfectphyloR)
to CRAN.
Warning 1: * checking files in 'vignettes' ... WARNING
Files in the 'vignettes' directory but no files in 'inst/doc':
'perfectphyloR.html', 'perfectphyloR.html.asis'
Warning 2: * checking package vignettes in 'inst/doc' ... WARNING
dir.exists(dir) is not TRUE
Package vignette without corresponding single PDF/HTML:
'perfectphyloR.html.asis'
I want to make my vignette as a static html vignette (not the PDF). Therefore,
I followed this documentation,
https://cran.r-project.org/web/packages/R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
After including my html vignette (perfectphyloR.html) into the directory
'vignette', I created a file called "perfectphyloR.html.asis" and that file
includes following lines:
%\VignetteIndexEntry{R packages: perfectphyloR}
%\VignetteEngine{R.rsp::asis}
%\VignetteKeyword{HTML}
%\VignetteKeyword{vignette}
%\VignetteKeyword{package}
Also, I added 'R.rsp' to the DESCRIPTION file as follows:
Suggests:
knitr,
rmarkdown,
R.rsp
VignetteBuilder: R.rsp
So, I am wondering something is wrong with my .asis file or I am doing any
other mistake. Could you help me fix this issue?
Thank you in advance!
Regards,
Charith.
[[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] CRAN pre-test failed on NOTE "no visible binding for global variable"
On 02/07/2019 11:00 a.m., Georgi Boshnakov wrote:
...
if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
Using such a general pattern eventually and inevitably will prevent the check
from reporting legitimate bugs.
I believe globalVariables() takes a vector of names, not a regular
expression for names. So that's not so general, it's just the name ".".
Duncan Murdoch
One alternative is to list explicitly the variables in question and make sure
that they are not commonly used names like 'x'.
If that is not practical and you use non-standard evaluation a lot, consider
'.data' from package 'lang' , see its documentation and/or Google it
to find out how to use it.
#' @importFrom rlang .data
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Iñaki Ucar
Sent: 02 July 2019 15:19
To: Berlanga, Antonio J
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for
global variable"
raúl
On Tue, 2 Jul 2019 at 14:18, Berlanga, Antonio J
wrote:
Hi r-package-devel,
I've submitted my first package but it failed the CRAN pre-tests on
NOTES. I got:
- my email
- an extra non-standard file (which I have now added to .Rbuildignore)
- NOTEs on "no visible global function definition"
The first two I assume are harmless. The third I do not know how to fix
(possible solutions below). Can it be ignored and suggest the fail was a
false-positive?
The third NOTE is:
###
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: R code for possible problems, Result: NOTE
epi_clean_count_classes: no visible global function definition for
'%>%'
epi_clean_count_classes: no visible binding for global variable '.'
epi_plot_heatmap: no visible binding for global variable 'Var1'
epi_plot_heatmap: no visible binding for global variable 'Var2'
epi_plot_heatmap: no visible binding for global variable 'value'
epi_plot_heatmap_triangle: no visible binding for global variable
'Var1'
epi_plot_heatmap_triangle: no visible binding for global variable
'Var2'
epi_plot_heatmap_triangle: no visible binding for global variable
'value'
epi_plot_heatmap_triangle: no visible global function definition for
'element_text'
epi_plot_heatmap_triangle: no visible global function definition for
'coord_fixed'
epi_plot_heatmap_triangle: no visible global function definition for
'element_blank'
epi_plot_heatmap_triangle: no visible global function definition for
'element_rect'
epi_plot_heatmap_triangle: no visible global function definition for
'guide_colorbar'
epi_stats_summary: no visible global function definition for '%>%'
epi_stats_tidy: no visible global function definition for '%>%'
epi_stats_tidy: no visible binding for global variable '.'
epi_stats_tidy: no visible binding for global variable 'x'
epi_stats_tidy: no visible binding for global variable 'n'
epi_stats_tidy: no visible binding for global variable 'id'
Undefined global functions or variables:
%>% . Var1 Var2 coord_fixed element_blank element_rect element_text
guide_colorbar id n value x
###
Solutions seem to cause errors elsewhere and there does not appear to be
an ideal one unfortunately. It seems to me that adding a file in the
directory 'R' containing eg:
###
if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
###
is one of the preferred ways. This seems far from ideal though.
If you use NSE in your package, this is the best solution. You may
also switch to SE.
Iñaki
__
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] "Progress reports" for examples in packages.
On 2/07/19 11:13 PM, Ivan Krylov wrote:
Could R CMD check be using valgrind to run the examples? Valgrind has
to interpret CPU instructions manually to be able to warn about
results of code execution depending on memory values it considers
undefined, so it is much slower than execution on a real CPU.
One way to verify that on a GNU/Linux system would be to temporary
insert system('pstree -aps $$') into one of the examples and look at
the output produced.
Thanks for the suggestion. I put the command that you advise in the
first example that gets run and in the file
ldEst.Rcheck/ldEst-Ex.Rout
I got the output:
system('pstree -aps $$')
systemd,1 --system --deserialize 32
`-lightdm,1249
`-lightdm,1568 --session-child 13 20
`-mate-session,1595
`-mate-panel,1772
`-mate-terminal,16032
`-tcsh,18036
`-sh,18204 /usr/lib/R/bin/check ldEst_2.0-15.tar.gz
`-R,18208 --no-restore --slave --args
nextArgldEst_2.0-15.tar.gz
`-sh,18572 -c ...
`-R,18573 --vanilla
`-sh,18579 -c pstree -aps $$
`-pstree,18580 -aps 18579
Nothing untoward leaps out at me. Certainly no mention of valgrind.
Can anyone see anything in the foregoing output that I should
investigate? Ta.
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
On 02/07/2019 5:31 a.m., Rolf Turner wrote:
Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
that I can monitor progress by looking at the file
"mypkg.Rcheck/mypkg-Ex.Rout"
e.g. by using "tail -f". This strategy indeed revealed where the hangup
was happening. I wrapped a line of the examples in \dontrun{} and
checked the package again. Now the checking completes in finite time! :-)
However I remain puzzled as to *why* the line in question induces a
hangup. When I load the package and run that same line from the
command line, a result is returned within about 5 seconds of "wall time"
(or less).
Another strangeness: The line prior to that which I wrapped in
\dontrun{} took a very long time to return a result, although the
command did eventually complete (after which everything ran swiftly).
But when I run this same line from the command line it completes
*instantaneously*.
Why on earth would commands be slow, or not execute at all, when run
under the aegis of "R CMD check", but execute swiftly from the command line?
I think it would be unwise of me to ignore the fact that something
strange is going on here, but I'm damned if I can see how to go about
tracking the strangeness down so as to be able to remedy it.
My usual practice when trying to get a handle on something that I don't
understand is to insert browsers() into the code at strategic points.
See fortunes::fortune(158). That's of no help in the current context in
which the problem only arises when R CMD check is being run.
Can anyone suggest a clever means by which I might determine the
"magnitude and direction of my stupidity"?
Normally "R CMD check pkg.tar.gz" isn't easily debugged, as you've
found. You can make it a bit easier by doing from the console what it
does from the command line, using
tools:::.check_packages("pkg.tar.gz")
Sometimes this helps. I think it spawns separate R processes at a few
points; if it's one of those that is hanging, you can at least see what
the command line is, and run that part directly, possibly from the
console. Still not easy, but easier.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for global variable"
> ...
> if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
Using such a general pattern eventually and inevitably will prevent the check
from reporting legitimate bugs.
One alternative is to list explicitly the variables in question and make sure
that they are not commonly used names like 'x'.
If that is not practical and you use non-standard evaluation a lot, consider
'.data' from package 'lang' , see its documentation and/or Google it
to find out how to use it.
#' @importFrom rlang .data
Georgi Boshnakov
-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf
Of Iñaki Ucar
Sent: 02 July 2019 15:19
To: Berlanga, Antonio J
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for
global variable"
raúl
On Tue, 2 Jul 2019 at 14:18, Berlanga, Antonio J
wrote:
>
> Hi r-package-devel,
>
> I've submitted my first package but it failed the CRAN pre-tests on
> NOTES. I got:
>
> - my email
>
> - an extra non-standard file (which I have now added to .Rbuildignore)
>
> - NOTEs on "no visible global function definition"
>
> The first two I assume are harmless. The third I do not know how to fix
> (possible solutions below). Can it be ignored and suggest the fail was a
> false-positive?
>
> The third NOTE is:
>
> ###
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: R code for possible problems, Result: NOTE
> epi_clean_count_classes: no visible global function definition for
> '%>%'
> epi_clean_count_classes: no visible binding for global variable '.'
> epi_plot_heatmap: no visible binding for global variable 'Var1'
> epi_plot_heatmap: no visible binding for global variable 'Var2'
> epi_plot_heatmap: no visible binding for global variable 'value'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var1'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var2'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'value'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_text'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'coord_fixed'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_blank'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_rect'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'guide_colorbar'
> epi_stats_summary: no visible global function definition for '%>%'
> epi_stats_tidy: no visible global function definition for '%>%'
> epi_stats_tidy: no visible binding for global variable '.'
> epi_stats_tidy: no visible binding for global variable 'x'
> epi_stats_tidy: no visible binding for global variable 'n'
> epi_stats_tidy: no visible binding for global variable 'id'
> Undefined global functions or variables:
> %>% . Var1 Var2 coord_fixed element_blank element_rect element_text
> guide_colorbar id n value x
> ###
>
>
> Solutions seem to cause errors elsewhere and there does not appear to be
> an ideal one unfortunately. It seems to me that adding a file in the
> directory 'R' containing eg:
>
> ###
>
> if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
>
> ###
>
> is one of the preferred ways. This seems far from ideal though.
If you use NSE in your package, this is the best solution. You may
also switch to SE.
Iñaki
__
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] CRAN pre-test failed on NOTE "no visible binding for global variable"
raúl
On Tue, 2 Jul 2019 at 14:18, Berlanga, Antonio J
wrote:
>
> Hi r-package-devel,
>
> I've submitted my first package but it failed the CRAN pre-tests on
> NOTES. I got:
>
> - my email
>
> - an extra non-standard file (which I have now added to .Rbuildignore)
>
> - NOTEs on "no visible global function definition"
>
> The first two I assume are harmless. The third I do not know how to fix
> (possible solutions below). Can it be ignored and suggest the fail was a
> false-positive?
>
> The third NOTE is:
>
> ###
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: R code for possible problems, Result: NOTE
> epi_clean_count_classes: no visible global function definition for
> '%>%'
> epi_clean_count_classes: no visible binding for global variable '.'
> epi_plot_heatmap: no visible binding for global variable 'Var1'
> epi_plot_heatmap: no visible binding for global variable 'Var2'
> epi_plot_heatmap: no visible binding for global variable 'value'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var1'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'Var2'
> epi_plot_heatmap_triangle: no visible binding for global variable
> 'value'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_text'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'coord_fixed'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_blank'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'element_rect'
> epi_plot_heatmap_triangle: no visible global function definition for
> 'guide_colorbar'
> epi_stats_summary: no visible global function definition for '%>%'
> epi_stats_tidy: no visible global function definition for '%>%'
> epi_stats_tidy: no visible binding for global variable '.'
> epi_stats_tidy: no visible binding for global variable 'x'
> epi_stats_tidy: no visible binding for global variable 'n'
> epi_stats_tidy: no visible binding for global variable 'id'
> Undefined global functions or variables:
> %>% . Var1 Var2 coord_fixed element_blank element_rect element_text
> guide_colorbar id n value x
> ###
>
>
> Solutions seem to cause errors elsewhere and there does not appear to be
> an ideal one unfortunately. It seems to me that adding a file in the
> directory 'R' containing eg:
>
> ###
>
> if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
>
> ###
>
> is one of the preferred ways. This seems far from ideal though.
If you use NSE in your package, this is the best solution. You may
also switch to SE.
Iñaki
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN pre-test failed on NOTE "no visible binding for global variable"
Hi r-package-devel,
I've submitted my first package but it failed the CRAN pre-tests on
NOTES. I got:
- my email
- an extra non-standard file (which I have now added to .Rbuildignore)
- NOTEs on "no visible global function definition"
The first two I assume are harmless. The third I do not know how to fix
(possible solutions below). Can it be ignored and suggest the fail was a
false-positive?
The third NOTE is:
###
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: R code for possible problems, Result: NOTE
epi_clean_count_classes: no visible global function definition for
'%>%'
epi_clean_count_classes: no visible binding for global variable '.'
epi_plot_heatmap: no visible binding for global variable 'Var1'
epi_plot_heatmap: no visible binding for global variable 'Var2'
epi_plot_heatmap: no visible binding for global variable 'value'
epi_plot_heatmap_triangle: no visible binding for global variable
'Var1'
epi_plot_heatmap_triangle: no visible binding for global variable
'Var2'
epi_plot_heatmap_triangle: no visible binding for global variable
'value'
epi_plot_heatmap_triangle: no visible global function definition for
'element_text'
epi_plot_heatmap_triangle: no visible global function definition for
'coord_fixed'
epi_plot_heatmap_triangle: no visible global function definition for
'element_blank'
epi_plot_heatmap_triangle: no visible global function definition for
'element_rect'
epi_plot_heatmap_triangle: no visible global function definition for
'guide_colorbar'
epi_stats_summary: no visible global function definition for '%>%'
epi_stats_tidy: no visible global function definition for '%>%'
epi_stats_tidy: no visible binding for global variable '.'
epi_stats_tidy: no visible binding for global variable 'x'
epi_stats_tidy: no visible binding for global variable 'n'
epi_stats_tidy: no visible binding for global variable 'id'
Undefined global functions or variables:
%>% . Var1 Var2 coord_fixed element_blank element_rect element_text
guide_colorbar id n value x
###
Solutions seem to cause errors elsewhere and there does not appear to be
an ideal one unfortunately. It seems to me that adding a file in the
directory 'R' containing eg:
###
if(getRversion() >= "2.15.1") utils::globalVariables(c("."))
###
is one of the preferred ways. This seems far from ideal though.
Another option is to import the package and function in the namespace
with eg @importFrom rlang .data
This also seems to cause errors in my case however as I then get
problems with R CMD check with conflicts when including or excluding
such packages from the DESCRIPTION file (I'm sure I'm missing something
though but can't see how to fix it).
See discussions in:
https://github.com/r-lib/devtools/issues/1714
feature request: R CMD check and no visible binding for global variable
· Issue #1714 · r-lib/devtools
https://stackoverflow.com/questions/40251801/how-to-use-utilsglobalvariables
r - how to use utils::globalVariables - Stack Overflow
https://github.com/tidyverse/magrittr/issues/29
R CMD check and no visible binding for global variable '.' · Issue #29 ·
tidyverse/magrittr
https://github.com/STAT545-UBC/Discussion/issues/451
Writing R Packages: no visible binding for global variable · Issue #451
· STAT545-UBC/Discussion
My current thought is to keep the NOTEs as they are to remind me what
I've done and ignore them in the CRAN checks.
Help would be appreciated though (!).
Best wishes,
Antonio
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
Could R CMD check be using valgrind to run the examples? Valgrind has
to interpret CPU instructions manually to be able to warn about
results of code execution depending on memory values it considers
undefined, so it is much slower than execution on a real CPU.
One way to verify that on a GNU/Linux system would be to temporary
insert system('pstree -aps $$') into one of the examples and look at
the output produced.
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
On 2/07/19 9:45 PM, Iñaki Ucar wrote:
Which line of code is it?
Dunno that it's very enlightening, without having access to the package,
but the two lines involved are:
fit <- ldFit(inLogs,predictor="logDose",link="logit")
x3 <- cvCompare(fit,nrep=5)
The first line runs instantaneously from the command line, but takes a
very long time under R CMD check.
The second causes R CMD check to disappear into a black hole, but runs
in 5 seconds or less from the command line.
I'm sorry that I can't make the package public at this time. It
contains a number of data sets that my consulting client does not want
released publicly.
I guess I could create a slightly cut down version of the package with
the proprietary data sets removed If anyone is actually interested.
cheers,
Rolf
P. S. The package is about "lethal dose" estimation. The ldFit() is
for fitting models from which to estimate lethal doses. The cvCompare()
function is for using cross validation of log likelihood to assess
goodness of fit and to compare models for goodness of fit.
The "nrep=5" is an unrealistically small value (small so as to reduce
the amount of time needed for checking). The default value is nrep=100.
R.
Iñaki
On Tue, 2 Jul 2019 at 11:32, Rolf Turner wrote:
Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
that I can monitor progress by looking at the file
"mypkg.Rcheck/mypkg-Ex.Rout"
e.g. by using "tail -f". This strategy indeed revealed where the hangup
was happening. I wrapped a line of the examples in \dontrun{} and
checked the package again. Now the checking completes in finite time! :-)
However I remain puzzled as to *why* the line in question induces a
hangup. When I load the package and run that same line from the
command line, a result is returned within about 5 seconds of "wall time"
(or less).
Another strangeness: The line prior to that which I wrapped in
\dontrun{} took a very long time to return a result, although the
command did eventually complete (after which everything ran swiftly).
But when I run this same line from the command line it completes
*instantaneously*.
Why on earth would commands be slow, or not execute at all, when run
under the aegis of "R CMD check", but execute swiftly from the command line?
I think it would be unwise of me to ignore the fact that something
strange is going on here, but I'm damned if I can see how to go about
tracking the strangeness down so as to be able to remedy it.
My usual practice when trying to get a handle on something that I don't
understand is to insert browsers() into the code at strategic points.
See fortunes::fortune(158). That's of no help in the current context in
which the problem only arises when R CMD check is being run.
Can anyone suggest a clever means by which I might determine the
"magnitude and direction of my stupidity"?
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
It's a pain in the neck, but even more basic than inserting browser()
calls all over the place (but possibly useful in this situation) would
be inserting appropriate cat() statements all over the place ... (and
maybe using cat() with proc.time() to report on elapsed time as you go?)
(As for why the speed depends on the environment, I have no idea ...)
On 2019-07-02 5:31 a.m., Rolf Turner wrote:
>
> Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
> that I can monitor progress by looking at the file
>
> "mypkg.Rcheck/mypkg-Ex.Rout"
>
> e.g. by using "tail -f". This strategy indeed revealed where the hangup
> was happening. I wrapped a line of the examples in \dontrun{} and
> checked the package again. Now the checking completes in finite time! :-)
>
> However I remain puzzled as to *why* the line in question induces a
> hangup. When I load the package and run that same line from the
> command line, a result is returned within about 5 seconds of "wall time"
> (or less).
>
> Another strangeness: The line prior to that which I wrapped in
> \dontrun{} took a very long time to return a result, although the
> command did eventually complete (after which everything ran swiftly).
> But when I run this same line from the command line it completes
> *instantaneously*.
>
> Why on earth would commands be slow, or not execute at all, when run
> under the aegis of "R CMD check", but execute swiftly from the command
> line?
>
> I think it would be unwise of me to ignore the fact that something
> strange is going on here, but I'm damned if I can see how to go about
> tracking the strangeness down so as to be able to remedy it.
>
> My usual practice when trying to get a handle on something that I don't
> understand is to insert browsers() into the code at strategic points.
> See fortunes::fortune(158). That's of no help in the current context in
> which the problem only arises when R CMD check is being run.
>
> Can anyone suggest a clever means by which I might determine the
> "magnitude and direction of my stupidity"?
>
> cheers,
>
> Rolf
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
Which line of code is it?
Iñaki
On Tue, 2 Jul 2019 at 11:32, Rolf Turner wrote:
>
>
> Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
> that I can monitor progress by looking at the file
>
> "mypkg.Rcheck/mypkg-Ex.Rout"
>
> e.g. by using "tail -f". This strategy indeed revealed where the hangup
> was happening. I wrapped a line of the examples in \dontrun{} and
> checked the package again. Now the checking completes in finite time! :-)
>
> However I remain puzzled as to *why* the line in question induces a
> hangup. When I load the package and run that same line from the
> command line, a result is returned within about 5 seconds of "wall time"
> (or less).
>
> Another strangeness: The line prior to that which I wrapped in
> \dontrun{} took a very long time to return a result, although the
> command did eventually complete (after which everything ran swiftly).
> But when I run this same line from the command line it completes
> *instantaneously*.
>
> Why on earth would commands be slow, or not execute at all, when run
> under the aegis of "R CMD check", but execute swiftly from the command line?
>
> I think it would be unwise of me to ignore the fact that something
> strange is going on here, but I'm damned if I can see how to go about
> tracking the strangeness down so as to be able to remedy it.
>
> My usual practice when trying to get a handle on something that I don't
> understand is to insert browsers() into the code at strategic points.
> See fortunes::fortune(158). That's of no help in the current context in
> which the problem only arises when R CMD check is being run.
>
> Can anyone suggest a clever means by which I might determine the
> "magnitude and direction of my stupidity"?
>
> cheers,
>
> Rolf
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "Progress reports" for examples in packages.
Many thanks to Henrik Bengtsson and Martin Maechler for pointing out
that I can monitor progress by looking at the file
"mypkg.Rcheck/mypkg-Ex.Rout"
e.g. by using "tail -f". This strategy indeed revealed where the hangup
was happening. I wrapped a line of the examples in \dontrun{} and
checked the package again. Now the checking completes in finite time! :-)
However I remain puzzled as to *why* the line in question induces a
hangup. When I load the package and run that same line from the
command line, a result is returned within about 5 seconds of "wall time"
(or less).
Another strangeness: The line prior to that which I wrapped in
\dontrun{} took a very long time to return a result, although the
command did eventually complete (after which everything ran swiftly).
But when I run this same line from the command line it completes
*instantaneously*.
Why on earth would commands be slow, or not execute at all, when run
under the aegis of "R CMD check", but execute swiftly from the command line?
I think it would be unwise of me to ignore the fact that something
strange is going on here, but I'm damned if I can see how to go about
tracking the strangeness down so as to be able to remedy it.
My usual practice when trying to get a handle on something that I don't
understand is to insert browsers() into the code at strategic points.
See fortunes::fortune(158). That's of no help in the current context in
which the problem only arises when R CMD check is being run.
Can anyone suggest a clever means by which I might determine the
"magnitude and direction of my stupidity"?
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] The correct way to put additional DLLs on windows?
Sorry, it was a mistake. CC the list. 于 2019年7月2日 GMT-07:00 上午12:17:01, Jeff Newmiller 写到: >I recommend that you "reply-all" to keep the mailing list included. > > >On July 1, 2019 11:30:23 PM PDT, Jialin Ma wrote: >>Hi Jeff, >> >>Thanks for your reply. I would like to clarify a little bit: >> >>> A) You cannot assume the package code will have write access to the >>library >>> directories. The user/admin who installs the package may never load >>the >>> package. >> >>I am downloading the necessary binary dependencies at *compile time*, >>i.e. the >>script is being called inside "Makevars.win". I suppose the script >>should have >>write access to the current directory, i.e. "inst" directory, at this >>stage? >>But I am not sure about it. >> >>I am aware many packages will download static libraries on windows at >>this >>stage. For example the Cairo package (see >>https://github.com/cran/Cairo/blob/ >>master/configure.win ) mentioned in Writing R Extensions will download >>binary >>to the source directory and link against them. >>My question is about whether it is an accepted practice to put DLL >file >>in >>"inst/libs". >> >>> B) Downloading binary files for execution without the direct >>involvement of >>> the user/admin is a security risk. >>> >>> C) Open-source package license means the source code is part of the >>package. >>> Downloading binaries later fails this requirement. >> >>This however is a workaround for the windows platform due to the >>difficulties >>compiling the external libraries. The toolchains needed (specifically, >>cmake) >>was missing in Rtools and there are several dependencies. I believe >>there >>should be some accepted practice for the license issue, however I am >>not sure. >> >>Best regards, >>Jialin >> >> >>On Monday, July 1, 2019 10:49:43 PM PDT you wrote: >>> A) You cannot assume the package code will have write access to the >>library >>> directories. The user/admin who installs the package may never load >>the >>> package. >>> >>> B) Downloading binary files for execution without the direct >>involvement of >>> the user/admin is a security risk. >>> >>> C) Open-source package license means the source code is part of the >>package. >>> Downloading binaries later fails this requirement. >>> On July 1, 2019 10:03:07 PM PDT, Jialin Ma wrote: >>> >Hi everyone, >>> > >>> >Currently my package has a script downloading additional DLLs >>> >into "inst/libs" and being called in "Makevars.win". In this way >>these >>> >DLLs get copied to libs when installing the package and I am able >to >>> >load them with "library.dynam". >>> > >>> >However R CMD check gives the following warning. >>> > >>> > * checking package subdirectories ... WARNING >>> > >>> > Found the following non-empty subdirectories of 'inst' also used >by >>R: >>> >inst/libs >>> > >>> > It is recommended not to interfere with package subdirectories >used >>by >>> > >>> > R. >>> > >>> >I was wondering what would be the best practice for my case, or I >am >>> >safe >>> >to ignore this warning (suppose I am planing for a CRAN >submission). >>> > >>> >I know many packages will download static library and link them at >>> >compile >>> >time. But I haven't see any example with additional DLL files. >>> > >>> >Thanks. >>> >Jialin Ma >>> > >>> >__ >>> >R-package-devel@r-project.org mailing list >>> >https://stat.ethz.ch/mailman/listinfo/r-package-devel > >-- >Sent from my phone. Please excuse my brevity. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. [[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] "Progress reports" for examples in packages.
> Henrik Bengtsson
> on Mon, 1 Jul 2019 20:36:26 -0700 writes:
> FWIW, when running R CMD check mypkg_1.0.tar.gz
> the example output is captured to the file
> 'mypkg.Rcheck/mypkg-Ex.Rout', so you could monitor that
> one for what's going on.
> /Henrik
Yes, indeed, that's what we have been doing "all the time"; e.g.,
on a unix-alike (or in a 'bash'-like (powershell?) on Windows);
you can 'tail -f /mypkg-Ex.Rout' in another shell/terminal
Martin
> On Mon, Jul 1, 2019 at 7:00 PM Rolf Turner
> wrote:
>>
>>
>> I am currently working on a package such that when "R CMD
>> check" is run the procedure seems to disappear into a
>> black hole when it gets to the "* checking examples ..."
>> stage.
>>
>> Strangely, when I run the examples individually, although
>> they take a rather long time, they do not take an
>> "endless" amount of time, so I am puzzled. I would like
>> to be able to isolate where the hang-up is occurring so
>> that I can rectify the problem.
>>
>> I guess I could, successively, wrap all but one of the
>> examples in \dontrun{} and see what happens in each case.
>> But this is rather tedious. Is there any to get some
>> diagnostic output as to, e.g. which example is being
>> checked at the given moment? Doing R CMD check --help
>> does not reveal any useful looking options.
>>
>> Thanks for any tips.
>>
>> cheers,
>>
>> Rolf Turner
>>
>> --
>> Honorary Research Fellow Department of Statistics
>> University of Auckland Phone: +64-9-373-7599 ext. 88276
>>
>> __
>> 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
