[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