Re: [R-pkg-devel] Windows binary package not at mirrors
Duncan Murdoch wrote on 2024-06-23 13:04: […] One exception is the one run by Posit: because it is cloud based, I think they spend quite a lot of money on it. […] it means that it is very reliable, and it's the one I use almost all the time. I agree. It is also helpful for developers of packages because they can use badges based on METACRAN’s data (which itself evaluates the Posit mirror) to get an idea about the number of downloads (total and of the current version per month). Example: https://github.com/Detlew/PowerTOST/blob/master/README.md Helmut Schütz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE about missing package ‘emmeans’ on macos-x86_64
Hi Simon, THX for the clarification and additional work I have caused. Helmut Simon Urbanek wrote on 2023-06-24 06:51: On Jun 24, 2023, at 12:19 AM, Uwe Ligges wrote: On 23.06.2023 11:27, Helmut Schütz wrote: Dear all, since a while (January?) we face NOTEs in package checks (https://cran.r-project.org/web/checks/check_results_PowerTOST.html): Version: 1.5-4 Check: package dependencies Result: NOTE Package suggested but not available for checking: ‘emmeans’ Flavor: r-release-macos-x86_64 Version: 1.5-4 Check: Rd cross-references Result: NOTE Package unavailable to check Rd xrefs: ‘emmeans’ Flavor: r-release-macos-x86_64 First I thought that ‘emmeans’ is not available for macos-x86_64 on CRAN. However, ‘emmeans’ itself passed all checks (https://cran.r-project.org/web/checks/check_results_emmeans.html). Since we want to submit v1.5-5 of PowerTOST soon, any ideas? Please go ahead. Simon rarely updates the check results, so I guess this was a coincidence at the time and never got updated. I'd ignore this one. Correct, packages are only re-checked if they failed the check before. Once a package passes the checks the results are not re-run, because it would take way too long given how many packages we have (re-running all takes 2-3 days). If you don't intend to update your package and want such NOTEs to disappear, send me an email and I can run it by hand (I did now for PowerTOST and the NOTE is gone). Cheers, Simon -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at <mailto:helmut.schu...@bebac.at> helmut.schu...@meduniwien.ac.at <mailto:helmut.schu...@meduniwien.ac.at> W https://bebac.at <https://bebac.at/> __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] NOTE about missing package ‘emmeans’ on macos-x86_64
Dear all, since a while (January?) we face NOTEs in package checks (https://cran.r-project.org/web/checks/check_results_PowerTOST.html): Version: 1.5-4 Check: package dependencies Result: NOTE Package suggested but not available for checking: ‘emmeans’ Flavor: r-release-macos-x86_64 Version: 1.5-4 Check: Rd cross-references Result: NOTE Package unavailable to check Rd xrefs: ‘emmeans’ Flavor: r-release-macos-x86_64 First I thought that ‘emmeans’ is not available for macos-x86_64 on CRAN. However, ‘emmeans’ itself passed all checks (https://cran.r-project.org/web/checks/check_results_emmeans.html). Since we want to submit v1.5-5 of PowerTOST soon, any ideas? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at <mailto:helmut.schu...@bebac.at> helmut.schu...@meduniwien.ac.at <mailto:helmut.schu...@meduniwien.ac.at> W https://bebac.at <https://bebac.at/> __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Transient (?) error on r-devel-windows-ix86+x86_64
Dear Duncan, Duncan Murdoch wrote on 2021-05-17 13:17: On 17/05/2021 5:35 a.m., Helmut Schütz wrote: Dear all, I'm facing an error: https://cran.r-project.org/web/checks/check_results_replicateBE.html As usual the link on the bottom of https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/replicateBE-00check.html is not helpful because it leads to an empty page. No errors/warnings were thrown in the pre-check on winbuilder. If I try it again, I get - as expected - a warning "Insufficient package version (submitted: 1.0.17, existing: 1.0.17)" but again no error. Are these different machines / installations? Is this error transient or - if not - what can I do? I don't see an empty page, I see an explanation for the problem: Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]) : there is no package called 'lme4' Calls: ... loadNamespace -> withRestarts -> withOneRestart -> doWithOneRestart Execution halted ERROR: lazy loading failed for package 'replicateBE' If you look at the lme4 page, you'll see it succeeded, so this was probably a transient error while it was being rebuilt. I see. I'm not importing lme4 _directly_ - it is a dependency of lmerTest. If you see nothing "as usual", there may be a problem at your end stopping you from downloading the info. Oh dear, Chrome was over-cautious... Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Transient (?) error on r-devel-windows-ix86+x86_64
Dear all, I'm facing an error: https://cran.r-project.org/web/checks/check_results_replicateBE.html As usual the link on the bottom of https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/replicateBE-00check.html is not helpful because it leads to an empty page. No errors/warnings were thrown in the pre-check on winbuilder. If I try it again, I get - as expected - a warning "Insufficient package version (submitted: 1.0.17, existing: 1.0.17)" but again no error. Are these different machines / installations? Is this error transient or - if not - what can I do? Best regards, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Sudden error on r-devel-windows-ix86+x86_64
Dear all, our package (https://cran.r-project.org/package=replicateBE) shows an error on the windows development version (r79815); no errors on Linux (r79812, r79815, r79818). See https://www.r-project.org/nosvn/R.check/r-devel-windows-ix86+x86_64/replicateBE-00check.html The link at the bottom of the page leads to an empty page and hence, is not helpful... Any ideas what might be the reason? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Run-times of examples in vignettes
Hi Dirk, Dirk Eddelbuettel wrote on 2020-10-27 13:32: | is there somewhere an official statement about the maximum run-times of | examples in vignettes? Seven minutes is excessive. Sure. The one vignette contains simulation code which needs 1E5 to 1E6 sims to get a stable result. Fewer sims are simply not meaningful. Since we use a pre-complied vignette now the execution time is essentially zero. The others take 45 seconds in total. If we would pre-compile the second slowest as well, we would be down for the remaining four at 12 seconds. I have (long) gone by the rule of "about one minute" each for tests and examples. OK. Do you know of any reference for this "rule"? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Run-times of examples in vignettes
Dear all, is there somewhere an official statement about the maximum run-times of examples in vignettes? Currently I got for our seven vignettes on my six-years old machine 7.9 minutes. One of them (containing a lot of simulation code) take 7.1 minutes. Hence, in the submission we asked for --no-vignettes (on Windows only). Interestingly on some flavours and operating systems this was also observed, whereas on others not. What I don't understand: Some zip-files (e.g. Windows r-oldrel) which state in the result-Flag --no-vignettes contain not only the *.Rmd (what I would expect) but also the *.R and *.html. Since a while we submit the time-critical vignette pre-compiled, which should bring the total execution time below one minute. Is that fine for all flavours & OSs? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning on r-oldrel-macos-x86_64
Hi Michael, Michael Dewey wrote on 2020-10-25 12:54: Dear Helmut I think the protocol is to always bump the version number for a re-submission even when the first one did not get onto CRAN. Agree. But in this case it’s already on CRAN (https://cran.r-project.org/package=PowerTOST). Only this _one_ warning. Shall I wait 28 days for a new submission with a new version number or try to re-submit with an explanation? For my taste a new version with only one line of code changed is a bit over the top. You are right; maybe a lot of users are still behind R4.0.0. Though stringsAsFactors = FALSE is new default, I will add it for simplicity. Some call stating all defaults "good coding practice". ;-) Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning on r-oldrel-macos-x86_64
Hi Hugh, Hugh Parsonage wrote on 2020-10-25 11:45: If you click on WARN in the table on your check results page (i.e. if you go to <https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/PowerTOST-00check.html> ) you will see in the first line: * using R version 3.6.2 (2019-12-12) Oh, dear! Hope that helps. I does. THX. An opinions of the list-members about a re-submission? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Warning on r-oldrel-macos-x86_64
Dear all,
we faced a warning on r-oldrel-macos-x86_64:
https://cran.r-project.org/web/checks/check_results_PowerTOST.html
I'm not concerned about "Pandoc (>= 1.12.3) and/or pandoc-citeproc not
available" in the first 5 vignettes since there were no problem in the
previous releases.
However I found this on stackoverflow:
https://stackoverflow.com/questions/50789125/how-to-get-an-rmarkdown-vignette-for-r-package-to-escape-cran-warnings-on-solari
RolandAsc commented:
"In my understanding you can only see this warning if there is an error
(either because warnings are being converted to errors or because there
is another subsequent error), else it just doesn't come through. This is
not an answer but maybe an explanation."
Seems to be correct. In my code a data.frame is assigned with a column
"foo" and _without_ stringsAsFactors = FALSE. Later a function is called
which requires "foo" as character.
The default stringsAsFactors was changed to FALSE in R4.0.0. Hence, my
question: How "old" is the old releaseon CRAN's test machines/ macos?
oldrel on windows is OK.
What shall we do?
Re-submit with the same release-number(either add stringsAsFactors =
FALSE or call the function with as.character("foo")with an explanation?
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] rJava (broken installation?)
Dear all,
in one of my packages I import from package xlsx, which itself imports
rJava.
I have the current Java (jre1.8.0_261) installed:
JAVA_VERSION="1.8.0_261"
OS_NAME="Windows"
OS_VERSION="5.2"
OS_ARCH="amd64"
However:
devtools::session_info("rJava")
- Session info
---
setting value
version R version 4.0.3 (2020-10-10)
os Windows 7 x64 SP 1
system x86_64, mingw32
ui Rgui
language EN
collate German_Germany.1252
ctype German_Germany.1252
tz Europe/Vienna
date 2020-10-13
- Packages
---
! package * version date lib source
D rJava 0.9-13 2020-07-06 [1] CRAN (R 4.0.2)
[1] D:/Program Files/R/R-4.0.3/library
D -- DLL MD5 mismatch, broken installation.
I found only this:
https://community.rstudio.com/t/error-dll-md5-mismatch-broken-installation/64141
with no answer.
Deleted rJava from my library and made a new install, no avail.
The functions I need from xlsx work as intended but I'm worried a bit.
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN badges in README
Dear Zhian, Zhian N. Kamvar wrote on 2020-10-01 16:43: You might be having browser cache issues because I just looked and things are fine on this end. You can double check in another browser or clear the cache (usually via Preferences > Settings > Security). FWIW, cran checks is an rhub/rOpenSci project: https://blog.r-hub.io/2019/06/10/cran-checks-api/, and not controlled by the CRAN team. Sorry, seems that rhub suffered from hiccups. All fine now without clearing the cache. Case closed. All the best, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN badges in README
Dear all,
we are using badges in README files of our packages on GitHub and CRAN.
Recently wrong results are reported:
https://github.com/Helmut01/replicateBE#readme shows CRAN Error
https://cran.r-project.org/web/packages/replicateBE/readme/README.html
shows CRAN Not OK
though OK at
https://cran.r-project.org/web/checks/check_results_replicateBE.html
https://github.com/Detlew/Power2Stage#readme shows CRAN Not OK
though OK at
https://cran.r-project.org/web/checks/check_results_Power2Stage.html
https://github.com/Detlew/PowerTOST#readme shows CRAN Error
https://cran.r-project.org/web/packages/PowerTOST/readme/README.html
shows CRAN Not OK
though one NOTE at
https://cran.r-project.org/web/checks/check_results_PowerTOST.html
All badges are linked with https://cranchecks.info/badges/worst/{package
name}
I checked about 1 month ago and the first 2 showed CRAN OK and the last
CRAN Note – which was correct.
Any ideas?
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Hi Duncan, Duncan Murdoch wrote on 2020-08-07 21:55: On 07/08/2020 3:22 p.m., Helmut Schütz wrote: I see. However, the HTML-source states This manual is for R, version 4.1.0 Under development (2020-08-06). I was relying on the PDF-version (4.0.2 of 2020-06-22) which does *not* contain this sentence. Hence, I fell into the trap. Should be stated in the PDF as well, IMHO. Oh, c'mon. It will be a new requirement in R 4.1.0 It's not a requirement in 4.0.2, and you didn't get a NOTE about it there, you only got the note in one of the r-devel platforms. Yep, but why are the others not configured in the same way (with setenv _R_CHECK_SUGGESTS_ONLY_ false)? Doesn't sound consistent to me. The general way things work in R is that changes get announced well in advance of release *by putting them in R-devel*. That's why you're asked to check your package against R-devel before submitting: so that it meets upcoming announced changes to requirements as well as ones that are in the current release. Of course, we checked the package on winbuilder... Are you suggesting to set up a multi-boot system for all those OSs? Even if one -- not us -- would aim at that: Where to get Solaris v10? Buy a Mac to run checks on maxOS? At least I understand now the differences between r-devel-linux-x86_64-debian-gcc and r-devel-linux-x86_64-debian-gcc (given in the last line there: https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-gcc). Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Hi Duncan, Duncan Murdoch wrote on 2020-08-07 18:39: You're reading the wrong version of the manual. This is in the R-devel manual: "Packages referred to by these ‘other forms’ should be declared in the DESCRIPTION file, in the ‘Depends’, ‘Imports’, ‘Suggests’ or ‘Enhances’ fields. " This is at the end of section 2.5 in https://cran.r-project.org/doc/manuals/r-devel/R-exts.html. I see. However, the HTML-source states This manual is for R, version 4.1.0 Under development (2020-08-06). I was relying on the PDF-version (4.0.2 of 2020-06-22) which does *not* contain this sentence. Hence, I fell into the trap. Should be stated in the PDF as well, IMHO. Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Hi Gábor, THX again. Case closed. Helmut Gábor Csárdi wrote on 2020-08-07 17:02: On Fri, Aug 7, 2020 at 3:51 PM Helmut Schütz wrote: Hi Gábor, Gábor Csárdi wrote on 2020-08-07 16:46: If you want to link to a package in the documentation, you'll have to add it to Suggests. THX, will do. Is this documented somewhere? The check is documented in https://cran.r-project.org/doc/manuals/r-devel/R-ints.html You can turn it on with the _R_CHECK_XREFS_PKGS_ARE_DECLARED_ environment variable. Any why don't the *other* installations of CRAN complain as well? I don't know if they run a different set of checks on purpose or by accident. G. -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Hi Brian, you take the words out of my mouth. However, we were slapped in the face... Helmut Brian G. Peterson wrote on 2020-08-07 17:02: On Fri, 2020-08-07 at 15:46 +0100, Gábor Csárdi wrote: If you want to link to a package in the documentation, you'll have to add it to Suggests. This doesn't make any sense. If you don't use the code from that package anywhere, then a cross-reference to that package should not require the extra dependency in Suggests. Cross references should be able to point to other functionality that might be useful to the user, or might add extra depth of understanding to a concept. If the user doesn't have the package installed, no worries, it is just a cross reference. The requirement you are suggesting is also not discussed in Writing R Extensions: https://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Cross_002dreferences In fact, it explicitly allows links to potentially uninstalled packages. Regards, Brian -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Hi Gábor, Gábor Csárdi wrote on 2020-08-07 16:46: If you want to link to a package in the documentation, you'll have to add it to Suggests. THX, will do. Is this documented somewhere? Any why don't the *other* installations of CRAN complain as well? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria T +43 1 2311746 M +43 699 10792458 E helmut.schu...@bebac.at W https://bebac.at/ C https://bebac.at/Contact.htm F https://forum.bebac.at/ GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209 GDPR https://bebac.at/Data-Protection.htm __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] NOTE in r-devel-linux-x86_64-fedora-clang
Dear all,
I'm struggling to understand this NOTE in
r-devel-linux-x86_64-fedora-clang (only)
https://cran.r-project.org/web/checks/check_results_PowerTOST.html
emmeans is a great package (THX Russell!) but we don't use it anywhere
in ours.
Only in two man pages we have
... obtained via \code{\link[emmeans]{emmeans}} of package \code{emmeans}.
Previously we had plain text and were asked by users for details.
AFAIK, this is the correct syntax acc. to the REM linking to the man
page of another package. In the library links work as intended.
Our package is used in a regulated environment where even a NOTE raises
eyebrows.
In all other R-versions and operating systems there is no problem. What
surprises me is that on Fedora the results depends on the C-compiler.
Strange.
Of course, we could use in NAMESPACE
importFrom(emmeans, emmeans)
but that would force users to install a package they might not need at all.
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Duncan Murdoch wrote on 2020-07-24 01:05:
On 23/07/2020 5:11 p.m., Helmut Schütz wrote:
I'm not a native speaker of English but for me "should not write" !=
"must not write".
And "may be allowed" is not "will be allowed".
Which leaves the question open _who_ may -- or may not -- allow it. ;-)
I removed the automatic switch to "~/" if no path is given. As before I
recommend in the man-pages to give the full path. However, I _still_
state that "~/" _can_ be used for convenience.
[...] It's fine if your documentation recommends the user choose
that. That's a variation on what I recommended to you (that you
generate an error message that suggests how to avoid the error).
Yes, I've done that.
Off topic: I don't like it that on Windows tempdir is located at
"C:/Users/{Username}/AppData/Local/Temp/Rtmp..." I strictly separate my
OSes (on C), software (on D), data (on E), backups (on F). Writing to
the system disk is not what I prefer. However, in my installation "~/"
resolves to "E:/Users/{Username}/Documents/"...
It can resolve anywhere you like (as long as its writable), by
specifying the TMPDIR environment variable.
Agree. Though I can change it permanently in _my_ Rcmd_environ file, in
a package I _must not_ change the users environment.
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Hi Dirk,
Dirk Eddelbuettel wrote on 2020-07-23 15:16:
Helmut,
For previous uploads you affirmed that you read the CRAN Repository Policy
which states
[...]
Your package appears to violate that requirement.
As I wrote previously the statement continues with
"Limited exceptions may be allowed in interactive sessions if the
package obtains confirmation from the user."
I'm not a native speaker of English but for me "should not write" !=
"must not write".
I would fix the package.
I removed the automatic switch to "~/" if no path is given. As before I
recommend in the man-pages to give the full path. However, I _still_
state that "~/" _can_ be used for convenience.
The package is used in a regulated environment. The output file contains
an entire audit-trail (name of the user and system, version and date of
the OS, R, all packages, functions used, time of execution, blablah). If
the package would write to tempdir() I would have to add a warning in
bold font of every man-page like "Execute the command tempdir() to find
out where your result files reside. Copy the files to a safe location
before you quit the R-session. If you fail to do so, your results will
be lost."
Off topic: I don't like it that on Windows tempdir is located at
"C:/Users/{Username}/AppData/Local/Temp/Rtmp..." I strictly separate my
OSes (on C), software (on D), data (on E), backups (on F). Writing to
the system disk is not what I prefer. However, in my installation "~/"
resolves to "E:/Users/{Username}/Documents/"...
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
T +43 1 2311746
M +43 699 10792458
E helmut.schu...@bebac.at
W https://bebac.at/
C https://bebac.at/Contact.htm
F https://forum.bebac.at/
GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209
GDPR https://bebac.at/Data-Protection.htm
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Hi Sebastian,
Sebastian Meyer wrote on 2020-07-23 16:52:
Back to the original topic:
THX!
Calling graphics.off() in example code will also disturb standard R CMD
check. Before running the examples, R CMD check opens a pdf device to
store any graphics output [1]. You will find the resulting pdf file in
{PACKAGE}.Rcheck/{PACKAGE}-Ex.pdf after R CMD check.
Ah! For years I was wondering where the PDF comes from.
R CMD check will eventually fail from trying to close this pdf device
after running the examples [2], if you have already closed all graphics
devices (including this pdf device) through code in your examples. This
is where the
Error in grDevices::dev.off() :
cannot shut down device 1 (the null device)
Execution halted
actually came from.
OK, now I have:
if (file.exists("myfile") & !is.null(dev.list()["png"]) {
invisible(dev.off(dev.list()["png"]))
}
You made my day. No error in check() any more.
Finally, […] the png device may not even be available.
Ouch!
So it is reasonable to condition on
capabilities("png")
Done.
or to put such examples in \donttest.
It was already in \donttest{} but check() ignored that.
HTH!
It did. Additionally I've learned a new abbreviation...
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Hi David, David Cortes wrote on 2020-07-23 13:16: It is explained here: https://cran.r-project.org/web/packages/policies.html Section about source packages: "Packages should not write in the user’s home filespace (including clipboards), nor anywhere else on the file system apart from the R session’s temporary directory (or during installation in the location pointed to by TMPDIR: and such usage should be cleaned up)." THX; I missed that! However, the policy continues: "Limited exceptions may be allowed in interactive sessions if the package obtains confirmation from the user." IMHO, this is applicable here (i.e., the user _should_ specify a directory (as recommended in the man-pages), and only if none is provided, a warning is issued and confirmation obtained). If I would use tempdir() and the user forgets to copy the result files to another location and closes the console, everything would be lost and the user would have to start again from scratch. I think that this is not very user-friendly. Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Dear Duncan, Duncan Murdoch wrote on 2020-07-22 23:48: On 22/07/2020 5:40 p.m., Helmut Schütz wrote: Duncan Murdoch wrote on 2020-07-22 21:42: During a check, it probably wouldn't, because you aren't allowed to write to "~/". Your package should be writing to tempdir(), or a location entered by the user. The user is asked to provide a certain path indeed. Only if none is provided, the fallback is "~/" (which is always writable). That disqualifies your package from inclusion on CRAN. Can you please point to such a policy in the R-Extension Manual? Eight versions of the package were accepted by CRAN and three times checked by members of the team. BTW, the package passed on winbuilder: Your package replicateBE_1.0.14.9000.tar.gz has been built (if working) and checked for Windows. Please check the log files and (if working) the binary package at: https://win-builder.r-project.org/k2tGfNoY7y88 The files will be removed after roughly 72 hours. Installation time in seconds: 41 Check time in seconds: 251 Status: 1 NOTE R version 4.0.2 (2020-06-22) Hence, I suspect that there is a problem with CHECK which I run locally on my machine. If no destination is provided and tempdir() isn't acceptable, you shouldn't write anything. The user may be keeping an irreplaceable piece of information in "~/test.png", and your package would destroy it. It's not your decision to make to trespass on the user's file space. The package is used in a regulated environment (e.g., for the FDA). The name of the file is always unique, i.e., depends on the input. The code checks whether a file with the same name already exist and -- if yes -- asks the user to confirm overwriting it. The man-pages make clear that a path should be provided. If none is provided, a message is issued informing the user that results are saved in the home directory. By using tempdir() the user would have to move all files to another location before the session is closed. Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Duncan Murdoch wrote on 2020-07-22 21:42:
> On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
>> [...]
>> The problem is that I cannot reproduce it as well. Only CHECK laments
>> about dev.off() which I changed to graphics.off() in the meantime.
>>
>> library(grDevices)
>> foo <- TRUE # shall we plot?
>> png.path <- "~/" # user's home folder
>> png.path <- normalizePath(png.path)
>> if (foo) {
>> png(paste0(png.path, "test.png"), width = 480, height = 480,
>> pointsize = 12)
>> }
>> plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
>> if (foo) {
>> graphics.off()
>> }
>
> You don't test whether the call to png() succeeded.
Correct. However,
if (file.exists(paste0(png.path, "test.png"))) graphics.off()
worked in the example but not in the package...
> During a check, it probably wouldn't, because you aren't allowed to
> write to "~/". Your package should be writing to tempdir(), or a
> location entered by the user.
The user is asked to provide a certain path indeed. Only if none is
provided, the fallback is "~/" (which is always writable). The package
is intended for "common" users and not "R-geeks". If I would write to
tempdir(), I guess chances are pretty low that a user will be able to
locate the file.
What I still fail to understand: CHECK laments about
grDevices::dev.off() in a certain man page, where I removed the argument
foo completely in one example (which is within \donttest{}). Hence, the
entire plotting routine is not executed at all. Furthermore, dev.off()
is nowhere used, only graphics.off() - now after file.exists().
Regards,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
[[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] Error in CHECK caused by dev.off()
Hi Serguei,
Serguei Sokol wrote on 2020-07-22 15:51:
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
I _can_ built the package and it runs as intended. Only the CHECK throws
the error.
- or the error comes from some other place of the code.
Closing the device is required only _once_ in the entire package.
In my NAMESPACE I have (and had in all previous versions):
importFrom(grDevices, png, graphics.off, dev.list, dev.off)
Sorry but without a minimal reproducible example I cannot help more.
The problem is that I cannot reproduce it as well. Only CHECK laments
about dev.off() which I changed to graphics.off() in the meantime.
library(grDevices)
foo <- TRUE # shall we plot?
png.path <- "~/" # user's home folder
png.path <- normalizePath(png.path)
if (foo) {
png(paste0(png.path, "test.png"), width = 480, height = 480,
pointsize = 12)
}
plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
if (foo) {
graphics.off()
}
Best,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
T +43 1 2311746
M +43 699 10792458
E helmut.schu...@bebac.at
W https://bebac.at/
C https://bebac.at/Contact.htm
F https://forum.bebac.at/
GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209
GDPR https://bebac.at/Data-Protection.htm
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Error in CHECK caused by dev.off()
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up to
v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> grDevices::dev.off()
Error in grDevices::dev.off() :
cannot shut down device 1 (the null device)
Execution halted
I tried:
if (foo | (foo & bar)) {
dev <- dev.list()
if (!is.null(dev)) {
if (dev == 2) invisible(dev.off())
}
}
without success (same error).
Even the more general
if (foo | (foo & bar)) {
graphics.off()
}
did not work.
The plot is called only in an example of one man-page -- though embedded
in \donttest{}.
Even if I set both foo and bar to FALSE (i.e., the respective part of
the code should not be executed at all), I get the same error.
Any ideas/suggestions?
Regards,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] MathJax for Rd files
Hi Wolfgang, Viechtbauer, Wolfgang (SP) wrote on 2020-05-13 16:53: Seems like you are using roxygen2. I have little experience with that, as all my Rd files are 'handcrafted' (plus 100% organic and biodegradable). As are mine. ;-) In the HTML-preview of RStudio the LaTeX is indeed not parsed. I get it only (in the HTML man-page and the PDF) if I build the package. Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Errors in r-devel (Linux) and r-patched (Solaris)
Dear Sebastian, Sebastian Meyer wrote on 2020-04-08 14:15: Do both of your R installations use the same version of lme4 ? THX, good point! On R3.6.2 I have lme4 1.1-21 (2019-03-05) and on R3.6.3 indeed yesterday's lme4 1.1-23. A new lme4 version has been published on CRAN yesterday and some changes regarding default numerical tolerances in optimizations could explain the difference in your results. See the NEWS here: https://cran.r-project.org/web/packages/lme4/news.html I see. Since the other 93 (!) tests passed, I will submit a fix only for _this_ data set. A little bit nasty since we recently published a paper about software validation: https://dx.doi.org/10.1208/s12248-020-0427-6 The supplementary material contains code for IQ (installation qualification). If a user on r-devel (Linux) or r-patched (Solaris) runs it – with the current lme4 - he/she will be slapped in the face and the suppl. material will tell him/her: "If a test fails […] the package did not pass IQ in the user’s computational environment (hardware, operating system, R-release) and _must not_ be used." Splendid. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria T +43 1 2311746 E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Errors in r-devel (Linux) and r-patched (Solaris)
Dear all, I was notified about errors: https://cran.r-project.org/web/checks/check_results_replicateBE.html Since I don't have access to those operating systems, I'm a little bit lost. Here is what I get with 64bit R on Windows: library(replicateBE) x <- method.B(details = TRUE, print = FALSE, data = rds30, option = 1)[c(10, 19)] y <- c(17.86418, 92.73371) d <- as.numeric(signif(abs(x - y), 7)) With R 3.6.2 print(d) [1] 4.431372e-06 1.182994e-07 With R 3.6.3 print(d) [1] 1.078696e-05 1.182989e-07 x[10] are Satterthwaite's degrees of freedom obtained by package pbkrtest. In both R-versions I use its current version (0.4-8.6 of 2020-02-20). Any ideas / suggestions? As a workaround I could reduce the tolerance of testthat's expect_quivalent() from to currently 5e-7 to a higher (_which one?_) value. But I still want to know what might be going on the CRAN's linux/solaris devel/patched installations since the other R-versions on all operating systems passed the tests. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria T +43 1 2311746 E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN repo mirror down? http://cran.us.r-project.org
Hi Daniel, I use install.packages(..., repos = "https://cloud.r-project.org/";) which hopefully find the closest working mirror. BTW, it’s "repos" not "repo". ;-) Daniel Sjoberg wrote on 2020-02-23 14:45: To install packages I've used `install.packages(..., repo = "http://cran.us.r-project.org";). All the CI checks began failing last week because the site http://cran.us.r-project.org is no longer available. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria E helmut.schu...@bebac.at W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] new package processing time
Hi Marcelo, Marcelo Araya Salas wrote on 2020-02-04 00:56: I submitted a new package to CRAN a couple of weeks ago. Does anyone know how long does it take for the package to be processed? New package versions are usually processed in a few hours so that's why I am wondering if everything is fine. Possibly it went unnoticed. My first new package took two days from submission to acceptance including answering questions in July last year. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] License of pre-built vignettes
Dear Duncan,
Duncan Murdoch wrote on 2019-10-24 21:51:
So it seems clear what to do: remove the BuildVignettes: false
statement, and explain why CRAN should avoid building them in your
submission message. This will likely make it take longer for the
package to be handled; if that's a problem for you, you probably need
to simplify the examples (or remove them).
THX, I got the idea. However, if we remove BuildVignettes: false, in the
tarball the HTML5 vignettes in inst/doc are overwritten with pandoc's
XHTML1.0 (with a warning, of course). That's the opposite of what we want.
The vignettes contain code for simulations which causes the long
runtime. In examples of the man-pages we have -- much simpler ones -- in
\donttest{}. I think that one of the purposes of vignettes is to give
the user a more exhaustive description what can be done with certain
functions. The only way out would to have instead of the R-code plain
text. Runtimes close to zero but all -- rather useful -- formats lost.
We will try to keep them and start a discussion with the team.
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] License of pre-built vignettes
Dear all, since we have many examples in our vignettes (rendering takes about 7 minutes) we provide them in /inst/doc Another reason is to have HTML5 instead of XHTML1.0 produced by pandoc (which contains deprecated attributes). To prevent building we have BuildVignettes: no in the DESCRIPTION Building the source, and installation from the local zip works as intended (vignettes are listed by browseVignettes(package="ourpackage"), linked in the main man-page, and all internal links are fine. However, CHECK throws a WARNING FOSS licence with BuildVignettes: false If I understand that correctly, it means that license(s) could not retrieved. In the DESCRIPTION we have License: GPL (>=2) Furthermore, all vignettes have a license section We tried adding License_is_FOSS: yes and License_restricts_use: no to the DESCRIPTION without success. Any ideas? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Resubmitting after a few days
Hi Roy, Roy Mendelssohn - NOAA Federal via R-package-devel wrote on 2019-09-24 20:43: > Hi All: > > A few days ago I had to resubmit because an external URL I was using in my > vignette changed and the nightly builds were issuing warnings. This morning > a user reported a bug. I have the fix and a new version, but the test > machines, and I suppose it will also be true of CRAN, are unhappy about the > interval since last submit. They will. ;-) > Should I just submit the new version anyway with a note in cram-comments that > this is a bug fix. Absolutely. The one-month interval for new versions is a *recommendation*. If a bug has to be fixed, go for it -- together with an explanation. Happened to me once as well (new version correcting a bug after two days). IIRC, Hadley had to submit a new version of one of his packages after three days. Murphy's law. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ [[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] Add reference in Description
Hi Juhee, Juhee Lee wrote on 2019-09-09 12:53: […] please add these in the Description field So I added it in the Description field of my DESCRIPTION file like this: Description: […] Berrington de Gonzalez A, et al.(2012) , National Research Council(2006, ISBN:978-0-309-09156-5). I would use instead of Interesting that CRAN started requesting references a while ago. Note that /nothing/ about it is stated in the 'R-Extensions Manual'. But, I've gotten the reply like below. Possibly mis-spelled words in DESCRIPTION: Berrington (32:5) Happens all the time, esp. with names. Sometimes words are common in your particular field but unknown to the spell-checker. It seems that the spell-checker learns or is less strict in later submissions. Nothing to worry about. Found the following (possibly) invalid DOIs: DOI: 10.1088/0952-4746/32/3/205 From: DESCRIPTION Status: Forbidden Message: 403 Strange. Generally you get that only if the document is behind a pay-wall and not even the abstract can be accessed. I could access it. Sometimes an entire site is down for maintenance (as Springer was ~ two weeks ago). Then one gets an HTTP 404. How do I modify it? You can't. Be patient. As stated in the note, wait for a member of CRAN to check that. Wetware outperforms silicon-based lifeforms. Cheers, Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria W https://bebac.at/ F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Misspelled words in DESCRIPTION
Hi John, we had the same issue with abbreviations BA (bioavailability), BE (bioequivalence), and NTID (narrow therapeutic index drug) in our packages (PowerTOST, replicateBE). Don’t worry.This note will appear only if you submit the package for the first time to CRAN. Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies W https://bebac.at/ C https://bebac.at/Contact.htm F https://forum.bebac.at/ __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package manual built by CRAN (Xposted from R-help)
Hi Duncan, Duncan Murdoch wrote on 2019-07-25 21:33: This sounds like a LaTeX bug in whatever system CRAN is using to produce the PDF. Like you, I don't see footnotes, I see the link inline with a complete URL. I think you'd get the footnotes if the LaTeX hyperref.sty file is not found, […] Perfect guess! When I removed hyperref.sty from my installation I got also the footnotes (without any errors or warnings). So what is the best way to proceed? Ask Uwe Ligges? Helmut -- Ing. Helmut Schütz BEBAC – Consultancy Services for Bioequivalence and Bioavailability Studies Neubaugasse 36/11 1070 Vienna, Austria T +43 1 2311746 M +43 699 10792458 E helmut.schu...@bebac.at W https://bebac.at/ C https://bebac.at/Contact.htm F https://forum.bebac.at/ GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209 GDPR https://bebac.at/Data-Protection.htm This e-mail is confidential and may also be legally privileged. If you are not the intended recipient please reply to sender, do not disclose its contents to any person and delete the e-mail. Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Package manual built by CRAN (Xposted from R-help)
Dear all,
recently I noticed an unexpected effect. The PDF-manual built from the
package’s .Rd-files looked different to what I was used to beforeand to
the one rendered locally. Specifically: If the reference-section looks
like this
\references{
foo \href{bar}{baz}
...
}
previously "foo" was intended (like a normal paragraph), "bar" formatted
in red and "baz" the URL.
Example of what I got instead:
https://cran.r-project.org/web/packages/replicateBE/replicateBE.pdf
(first occurrence at page 5).
In the references there are no direct links but a numbered footnotes in
a mono-spaced font running beyond the right margin of the page. The two
links of page 5:
In ABE.Rd
https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-investigation-bioequivalence-rev1_en.pdf
https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-pharmacokinetic-clinical-evaluation-modified-release-dosage-forms_en.pdf
ABE.Rd is correctly rendered into ABE.html
In the two footnotes of the PDF links are truncated
https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-investigation-bioequivalence-rev1_
https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-pharmacokinetic-clinical-evaluation-modified-release-dosage-forms_
Of course, both are punished with a HTTP 404.
Cheers,
Helmut
PS: I’m aware that
\references{
\enumerate{
\item foo \href{bar}{baz}
}
}
produces *exactly* this effect. Didn't use it.
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
T +43 1 2311746
M +43 699 10792458
E helmut.schu...@bebac.at
W https://bebac.at/
C https://bebac.at/Contact.htm
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
