[R-pkg-devel] Latex issue on CRAN: Package pdftex.def Error
Dear list Trying to push a fix to CRAN, I’m now running into a Latex issue. I can neither relate the issue I’m trying to resolve, nor my fix, to this new problem, so I’m a bit lost (and slightly frustrated). I cannot reproduce this specific issue anywhere, neither locally (macOS), nor on win devel, r-hub and Github (there are some other issues on Gh and r-hub, but I don’t believe them to be relevant here). All I have to go on is: - A WARNING in “checking PDF version of manual”: LaTeX errors found: ! Package pdftex.def Error: File `...' not found: using draft setting. - An ERROR in “checking PDF version of manual without index” - A NOTE in “checking for non-standard things in the check directory”: Found the following files/directories: ‘...-manual.tex’ It seems like when building the PDF manual, an image that should be included is not found and then things fall apart, causing both the error and note. For all I know, the image should be there unter `man/figures/`. The problem is showing up in the same way for both “Windows” and “Debian” (with slightly different notes due to intermediate files not being cleaned up properly). Have there been and Latex-related changes to CRAN recently? Are others seeing similar problems? Any ideas what could be causing this? For completeness: https://win-builder.r-project.org/incoming_pretest/ricu_0.5.4_20221030_131320/ Best, Nicolas [[alternative HTML version deleted]] ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Using ggplot2 within another package
Hi,
I'm trying to help clean up an R package for someone else to submit to
CRAN. He has used ggplot2 to implement a plotting function for the kinds
of things that his packages generates. His plotting routine basically
looks like (after changing names to protect the innocent):
myPlot <- fucntion(myData, ...) {
# get ready
ggplot(myData, aes(x = myX, y = myY)) +
# add my decorations
theme_bw()
}
Of course, "R CMD check --as-cran" complains that there is no global
binding for "myX" or "myY" since they are columns defined in the
data.frame "myData".
What is the best way to work around this issue?
Of course, dinosaurs like myself might be tempted to suggest just using
plain old "plot", so I don't need to see those suggestions.
Do I just ignore the usual ggplot conventions and write "myData$myX"
inside "aes" in order to appease the CRAN checker? Or is there some
tidy-er way to solve this problem?
Thanks,
Kevin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Using ggplot2 within another package
Thanks.
Obviously, long. long ago, (in a galaxy not far enough away), Paul's
suggestion of using "aes_string" was the correct one, since "aes" uses
non-standard evaluation. (And to quote somebody from an R fortune
cookie, "The problem with non-standard evaluation is that it is
non-standard.") But teh documentation at the end oft he link provided by
Robert explivityl tells you not to do that, since "aes_string is
deprecated". And reading more carefully into the manual page for
aes_string, one does indeed find the statement that the function is
"soft deprecated". I'm not sure what that means, other than someone on
the development team doesn't like it.
Instead, the vignette says you should
importFrom("rlang", ".data")
in your NAMESPACE, and write
ggplot(myData, aes(x = .data$myX, y = .data$myY))
And now my dinosaur question: That looks like using one non-standard
hack to cover up the problems with another non-standard hack. Why the
heck is that any better for the developer than writing
ggplot(myData, aes(x = myData$myX, y = myData$myY))
or using Dirk Eddelbuettel's suggestion of calling utils::globalVariables ??
It's time to tell those kids to get off of my lawn.
Kevin
On 4/22/2021 4:45 PM, Robert M. Flight wrote:
> Kevin,
>
> This vignette from ggplot2 itself gives the "officially recommended"
> ways to avoid the warnings from R CMD check
>
> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
> <https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>
>
> Cheers,
>
> -Robert
>
> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
> mailto:paul.sav...@univ-fcomte.fr>> wrote:
>
> Hi Kevin,
>
> I was faced to the same problem and I used 'aes_string()' instead
> of 'aes()'. You can then just write the name of the columns
> containing the data to plot as character strings.
>
> Example:
>
> myPlot <- function(myData, ...) {
> # get ready
> ggplot(myData, aes_string(x = "myX", y = "myY")) +
> # add my decorations
> theme_bw()
> }
>
> It is probably already the case for your function but you need to
> include #' @import ggplot2 in your function preamble (if I am not
> wrong).
>
> Kind regards
> Paul
>
> - Mail original -
> De: "Kevin R. Coombes" <mailto:kevin.r.coom...@gmail.com>>
> À: "r-package-devel" <mailto:r-package-devel@r-project.org>>
> Envoyé: Jeudi 22 Avril 2021 22:28:55
> Objet: [R-pkg-devel] Using ggplot2 within another package
>
> Hi,
>
> I'm trying to help clean up an R package for someone else to
> submit to
> CRAN. He has used ggplot2 to implement a plotting function for the
> kinds
> of things that his packages generates. His plotting routine basically
> looks like (after changing names to protect the innocent):
>
> myPlot <- fucntion(myData, ...) {
> # get ready
> ggplot(myData, aes(x = myX, y = myY)) +
> # add my decorations
> theme_bw()
> }
>
> Of course, "R CMD check --as-cran" complains that there is no global
> binding for "myX" or "myY" since they are columns defined in the
> data.frame "myData".
>
> What is the best way to work around this issue?
>
> Of course, dinosaurs like myself might be tempted to suggest just
> using
> plain old "plot", so I don't need to see those suggestions.
>
> Do I just ignore the usual ggplot conventions and write "myData$myX"
> inside "aes" in order to appease the CRAN checker? Or is there some
> tidy-er way to solve this problem?
>
> Thanks,
> Kevin
>
> __
> R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>
> __
> R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> <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
[R-pkg-devel] Spelling and manual CRAN inspection
Hi, I have been updating a couple of R packages this morning. One of them triggered a manual inspection for "possibly mis-spelled words in DESCRIPTION" for my last name (Coombes) --- even though none of the other 20 packages that I maintain has ever triggered that particular NOTE. A second package also triggered a manual inspection for mis-spelled words including "Proteomics". (These flags only arose on the debian CRAN machine, not the Windows CRAN machine, and not on my home machines. And let's ignore how many spelling corrections I had to make while typing this email) *My question, however, is: why should this NOTE ever trigger a manual inspection?* That makes more work for the CRAN maintainers, who I am sure have better things to do than evaluate spelling. Anything that would actually stop the package from working (mis-spelling a keyword, or mis-spelling the name of package that is imported) is going to cause an automatic ERROR and a rejection of the submission without making more work for the CRAN maintainers. The other mis-spellings may reflect poorly on the package author, but since they are NOTEs, it is easy enough to get them fixed for the next round without making human eyeballs look at them. Best, Kevin __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Spelling and manual CRAN inspection
Hi Jeff, I think you are inferring an attitude in my initial message that wasn't actually present. I greatly appreciate the hard work that CRAN maintainers put in on behalf of the community. And I really did (and do) want to understand why some of their valuable volunteer time should be occupied deciding if "possible mis-spellings" are (a) real and (b) important enough to do something about. I also admit to being possibly the world's worst typist. I often mis-spell multiple words in a sentence, and I rely on numerous spell checkers to point out the problems so I can fix them right away. (But right now, I am unhappy that the spell-checker in my email client insists that "mis-spell" and it variants doesn't have a hyphen in it.) So, I agree that correct spelling is worth someone spending their time on. But that someone (in my opinion) should be the package author and maintainer, not the CRAN maintainers. Part of the issue is that the mis-spellings are reported from R CMD check as a NOTE, not a WARNING nor an ERROR. They don't affect the code in any way (unlike the consequences of trying to import the "grpahics" package -- boy, was that hard to type.). Further, most of the "possible mis-spellings" that I have seen flagged in my own packages are false positives. (As noted above; I use spell-checkers at several points along the way so I can correct them before I submit.) Moreover, the results from different spell-checkers (such as those on different CRAN machines) are inconsistent. That increases the probability that any package is going to get flagged with false positives and require manual intervention. I don't know; maybe the CRAN maintainers like checking other people's spelling manually. But having to do that on a regular basis would soon make me run screaming from the room. Best, Kevin On 7/16/2021 1:07 PM, Jeff Newmiller wrote: Spelling has different importance to different people. You are expressing a value judgement that differs from the values of R Core, but are presenting your opinion as if they are facts. My point is that your challenging attitude IMO makes having a conversation about those concerns difficult. (I am not associated with R Core in any way, and do in fact empathize with your frustration with the process.) I think it is worth pointing out that spelling errors in the DESCRIPTION file are of greater significance than other areas of a package as they can affect assignment of responsibility and permissions, as well as reflecting poorly on the CRAN summary web pages. I suspect that problems with DESCRIPTION files in the past lead to this requirement. I would encourage you to pause for a day or two before sending off messages like this in the future... a lesson I have learned the hard way myself. On July 16, 2021 9:08:27 AM PDT, "Kevin R. Coombes" wrote: Hi, I have been updating a couple of R packages this morning. One of them triggered a manual inspection for "possibly mis-spelled words in DESCRIPTION" for my last name (Coombes) --- even though none of the other 20 packages that I maintain has ever triggered that particular NOTE. A second package also triggered a manual inspection for mis-spelled words including "Proteomics". (These flags only arose on the debian CRAN machine, not the Windows CRAN machine, and not on my home machines. And let's ignore how many spelling corrections I had to make while typing this email) *My question, however, is: why should this NOTE ever trigger a manual inspection?* That makes more work for the CRAN maintainers, who I am sure have better things to do than evaluate spelling. Anything that would actually stop the package from working (mis-spelling a keyword, or mis-spelling the name of package that is imported) is going to cause an automatic ERROR and a rejection of the submission without making more work for the CRAN maintainers. The other mis-spellings may reflect poorly on the package author, but since they are NOTEs, it is easy enough to get them fixed for the next round without making human eyeballs look at them. Best, Kevin ______ 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] Spelling and manual CRAN inspection
That's an excellent idea. I can't resist pointing out that everything that was flagged this morning has been in those packages for years (and for multiple submissions), and has never been flagged before. So I would still have to update my master last this time around. And a human at CRAN would still have to spend time to check the submission comment against the NOTE. (Hmm. Maybe the real underlying issue is that I'd like computers to make less work for humans, not more.) On 7/16/2021 4:43 PM, John Harrold wrote: > I have a list of words, acronyms and initialisms that commonly get > flagged as misspelled words when I submit updates. I generally just > put an explanation for each one in the "optional comment" section of > the submission form. It's pretty simple and seems to work out well. > > On Fri, Jul 16, 2021 at 9:08 AM Kevin R. Coombes > mailto:kevin.r.coom...@gmail.com>> wrote: > > Hi, > > I have been updating a couple of R packages this morning. One > of them > triggered a manual inspection for "possibly mis-spelled words in > DESCRIPTION" for my last name (Coombes) --- even though none of the > other 20 packages that I maintain has ever triggered that particular > NOTE. A second package also triggered a manual inspection for > mis-spelled words including "Proteomics". (These flags only arose > on the > debian CRAN machine, not the Windows CRAN machine, and not on my home > machines. And let's ignore how many spelling corrections I had to make > while typing this email) > > *My question, however, is: why should this NOTE ever trigger a manual > inspection?* That makes more work for the CRAN maintainers, who I am > sure have better things to do than evaluate spelling. Anything that > would actually stop the package from working (mis-spelling a > keyword, or > mis-spelling the name of package that is imported) is going to > cause an > automatic ERROR and a rejection of the submission without making more > work for the CRAN maintainers. The other mis-spellings may reflect > poorly on the package author, but since they are NOTEs, it is easy > enough to get them fixed for the next round without making human > eyeballs look at them. > > Best, > Kevin > > ______ > R-package-devel@r-project.org > <mailto:R-package-devel@r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > <https://stat.ethz.ch/mailman/listinfo/r-package-devel> > > > > -- > John > :wq [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] function name conflict
Hi, I am writing a package that Imports several other packages. One of my imported packages eventually imports (through a chain of dependencies) "lifecycle", and another eventually imports "rlang". Both "rlang" and "lifecycle" define and export functions called "last_warnings". As a result, when I first execute "library(MYPACKAGE)" in a script, I get a warning of the form " replacing previous import 'lifecycle::last_warnings' by 'rlang::last_warnings' when loading 'tibble' " I don't want the users of MYPACKAGE to have to see this warning (since I know it will spook novices). Is there anything I can do with Imports, Depends, or something else to prevent this warning from occurring? (I know that I can suppress warnings in each script, but I also don't want to explain to my users that they have to do that. Note that I have tried reversing the order of the two functions that I import in the Imports declaration in the DESCRIPTION file, to no effect. I also only use one function from each of the two imported pakages, and they are explicitly listed in importFrom directives in the NAMESPACE file. Thank in advance, Kevin ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Rd cross-references ... NOTE, Undeclared packages ... in Rd xrefs
On 14/06/2022 01:01, Spencer Graves wrote: > > > On 6/13/22 5:05 PM, Duncan Murdoch wrote: >> On 13/06/2022 5:11 p.m., Spencer Graves wrote: >>> >>> >>> On 6/13/22 1:26 PM, Duncan Murdoch wrote: >>>> On 13/06/2022 12:12 p.m., Spencer Graves wrote: >>>>> Hello, All: >>>>> >>>>> >>>>>How do I fix "Rd cross-references ... NOTE >>>>> Undeclared packages ‘EnvStats’, ‘drc’, ‘zoo’, ‘prodlim’, ‘plyr’, >>>>> ‘TRAMPR’, ‘raster’ in Rd xrefs"? >>>>> >>>>> >>>>>This occurs with >>>>> "https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/Ecfun-00check.html"; >>>>> >>>>> and with >>>>> "https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/Ecdat-00check.html";. >>>>> >>>>> However, this error is not raised on other platforms. My search for >>>>> this note produced essentially the same message for other packages but >>>>> no advice on how to fix it. >>>>> >>>>> >>>>>These are references to other packages that I do not use in my >>>>> packages but that some users may wish to consider. If needed, I will >>>>> add them to "Suggests" for the packages. However, that seems overkill, >>>>> because I do not use them myself. ??? >>>> >>>> Section 2.5 of Writing R Extensions says "Packages referred to by these >>>> ‘other forms’ should be declared in the DESCRIPTION file, in the >>>> ‘Depends’, ‘Imports’, ‘Suggests’ or ‘Enhances’ fields." Of those >>>> fields, Suggests looks like the best fit. You'd use Enhances if your >>>> package provides "methods for classes from these packages, or ways to >>>> handle objects from these packages". >>> >>> >>> GitHub Actions failed after I added those packages to Suggests: >>> >>> >>> https://github.com/sbgraves237/Ecfun/runs/6869516417?check_suite_focus=true >> >> That log doesn't really give much info about what went wrong. Maybe some of the packages in the Suggests list weren't available? > > >Is there a way in GitHub Action to NOT fail when a package is not available -- or at least to give a more useful diagnostic? Hi Spencer and all, Yes, you can set the environment variable _R_CHECK_FORCE_SUGGESTS_. R CMD check will still run even if some suggested packages are missing. Provided no error is raised by your package when one of these Suggests is missing, you should be fine. Best wishes, Hugo > > >There probably is, but I don't know how to find the right manual to read nor any better place to ask for help with that than here. > > >Thanks, sg > >> >> Duncan Murdoch > > __ > 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] Logical Inconsistency of check regarding URL?
Dear Michael, I second Ivan's suggestion to use a custom domain on your GitHub Pages website and I also want to add that this solves your certificate issue as a nice side-effect. GitHub will automatically create a certificate for you, for free, via Let's Encrypt: https://github.blog/2018-05-01-github-pages-custom-domains-https/ Best, Hugo On 29/11/2022 08:55, Ivan Krylov wrote: Dear Michael, On Tue, 29 Nov 2022 08:19:40 +0100 "Dr. habil. Michael Thrun" wrote: URL: https://www.deepbionics.org (moved to https://mthrun.github.io/index) From: DESCRIPTION Status: 301 Message: Moved Permanently Please change http --> https, add trailing slashes, or follow moved content as appropriate. " The "HTTPS and trailing slashes" part is a red herring. The idea is to only have URLs in your package that return HTTP code 200. The website https://www.deepbionics.org redirects to https://mthrun.github.io/index, which is, strictly speaking, against the letter of the rules [1]. Websites that redirect from http://... to https://... and from .../website/path to .../website/path/ (and the other way around) are a common cause of such redirects, which is why Uwe mentioned it (I think), but this isn't the reason for the redirection at https://www.deepbionics.org. I think you could make the argument that https://www.deepbionics.org is the canonical URL for the website and the way it _currently_ works (by returning a 301 redirect to https://mthrun.github.io/index) is an implementation detail that should be ignored, but I don't know whether CRAN reviewers would agree. I think it should be possible to set up your domain and GitHub Pages to serve mthrun.github.io at the address www.deepbionics.org without a redirection [2], but I've never tried it myself. First, do we not communicate with CRAN anymore through the submission procedure of the package? If not, which is the correct line of communication in such a case? There was a case once when the reviewer was mistaken (they were in the process of heroically clearing out the "newbies" queue that almost reached 80 packages, aged 10 days and more, all by themselves, so a certain amount of fatigue was to be expected) and I was able to argue my way out of a rejection by replying to the reviewer. I think that the way to go is to either submit a package with requested changes and an incremented version or to reply-to-all and argue the case for the package as it is now. Third, why can I have a CRAN package "DataVisualizations" with this URL online, another one named "GeneralizedUmatrix" uploaded the same day with the same URL, which both are OK, but the URL in "DatabionicSwarm" is not? Has anything changed recently regarding the way your domain is set up? It really is strange that the check passed for one of the packages but not the other. Fifth, why do we need https/TLS/SSL? I think you're right (see also: depriving an existing website of its certificate as a means of censorship), but the browser makers may end up destroying TLS-less workflow for us in a few years. Thankfully, it's not a requirement of CRAN to have only HTTPS links. I probably shouldn't continue this topic because the question of "how the Web should function" tends to result in pointlessly heated debates. ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Mysterious "invalid z limit"
Hi, I am in the middle of developing a new package, which contains a markdown-knitr-html vignette. When I try to run R CMD build [mypackagedirectory] I get an error message Quitting from lines 330-336 Error: processing vignette failed with diagnostics: invalid z limits If I run the same markdown script interactively inside R Studio, there is no error. If I knit the markdown script inside R Studio, it produces the correct HTML output, with no error. The offending lines of code (the chunk at 330-336) invoke an "image" method on an object of a class defined in the package, which in turn computes a matrix from items inside the object and calls image.default, which is presumably where the error is coming from. Two questions: (1) How is it possible that the same code works error free in the RStudio contexts, but fails in the attempt to build the package? (2) Any suggestions on how to debug something that only throws an error from "R CMD build" would be most welcome. Thanks in advance, Kevin __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
A terrific answer; thanks. (I am kicking myself for not realizing the answer you gave to question 1. Of course that's the explanation. Too many consecutive hours debugging other items to get to that point, I suppose.) Kevin On 1/8/2023 6:58 AM, Ivan Krylov wrote: On Sat, 7 Jan 2023 20:43:10 -0500 "Kevin R. Coombes" wrote: (1) How is it possible that the same code works error free in the RStudio contexts, but fails in the attempt to build the package? When knitting the vignette from RStudio, it uses the package you already have installed. When knitting the vignette from R CMD build, it uses the code it's about to package. Could it be that your source code is different from the copy installed in your library? (2) Any suggestions on how to debug something that only throws an error from "R CMD build" would be most welcome. R CMD build --no-build-vignettes should let you proceed and get a tarball that could be installed. Hopefully you'll be able to reproduce the error then. ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
A very helpful answer. For some reason (probably because I have an
ancient perl script that automates the steps i take when building and
checking packages), I keep forgetting that the "tools" package let's me
do these things from within R.
I had already isolated the offending line ("plot(obj)") inside the chunk
where the error occurred, and removed any additional arguments. I
wrapped that line in a "try" command followed by a conditional
"traceback()" to find the problem. This allowed the package build to
knit the vignette and provide some feedback about what was going on. It
turned out that I had copied and pasted an assignment line of the form
main <- [compute the title]
from earlier in the code and pasted it directly as an argument to the
call to image.default. And R did exactly what I told it to (not
surprisingly), and interpreted the value of that assignment as the
unnamed "zlim" option that would have been the corresponding positional
argument that should have been there.
And yes, I still use "left arrow" <- instead of equals = as assignments.
(Heck, I even use emacs and ESS with a leftover keybinding that uses the
underscore key to insert the left arrow. Apparently, I'm ancient myself.)
Kevin
On 1/8/2023 5:04 AM, Duncan Murdoch wrote:
On 07/01/2023 8:43 p.m., Kevin R. Coombes wrote:
Hi,
I am in the middle of developing a new package, which contains a
markdown-knitr-html vignette. When I try to run
R CMD build [mypackagedirectory]
I get an error message
Quitting from lines 330-336
Error: processing vignette failed with diagnostics:
invalid z limits
If I run the same markdown script interactively inside R Studio, there
is no error.
If I knit the markdown script inside R Studio, it produces the correct
HTML output, with no error.
The offending lines of code (the chunk at 330-336) invoke an "image"
method on an object of a class defined in the package, which in turn
computes a matrix from items inside the object and calls image.default,
which is presumably where the error is coming from.
Two questions: (1) How is it possible that the same code works error
free in the RStudio contexts, but fails in the attempt to build the
package?
(2) Any suggestions on how to debug something that only throws an error
from "R CMD build" would be most welcome.
Debugging that sort of thing is hard. Here's what I would try:
From inside an R session, run
tools:::.build_packages("[mypackagedirectory]")
That runs the code that R CMD build runs, so it might trigger the same
error. If so, debug in the usual way, with traceback(), etc.
If that doesn't trigger the error, try it using a different front-end,
e.g. running R at the command line instead of running it in RStudio.
If you still can't trigger it, then start modifying the vignette to
find the exact line that causes the error (e.g. by commenting out the
second half of the code in that chunk; did the error go away? etc.).
Then modify it again to save all the inputs to the bad line in a file
before running it, and see if running that line in a different context
still triggers the error. Etc.
Duncan Murdoch
______
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
Did you have to split the packages to get the CI/CD tools to work?
Because,to me, it looks as though I can install multiple different R
packages from the same git project, using something like
library(devtools)
install_gitlab("krcoombes/[PROJECT]", "pkg/[PACKAGE]")
Best,
Kevin
On 1/8/2023 1:38 PM, Spencer Graves wrote:
R-Forge was wonderful for me when I started using it. Then
several years ago, I started having problems like you described. A few
years ago I migrated from R-Forge to GitHub.
One problem I encountered in the transition: On R-Forge, I had
multiple packages in the same R-Forge project. I had to split them
apart for GitHub.
__________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] correcting errors in an existing package
1. Yes, remove the "lazyData" line from the DESCRIPTION file.
2. Do you have "stats" in the "Imports" line in the DESCRIPTION file? If
not, put it in along with the "importFrom" line in the NAMESPACE file.
On 3/31/2023 4:51 PM, Dennis Boos wrote:
Recently I got a message from CRAN that my package Monte.Carlo.se (on CRAN
for the last few years) does not pass current testing. There seemed to be
2 problems:
***
1. * checking LazyData ... NOTE
'LazyData' is specified without a 'data' directory
I have this line in my DESCRIPTION file:
LazyData: true
Should I remove that?
*
2. * checking examples with --run-donttest ... [42s/42s] ERROR
Running examples in ‘Monte.Carlo.se-Ex.R’ failed
The error most likely occurred in:
pairwise.se(hold,xcol=10:12,summary.f=cv)
Error: object 'hold' not found
Execution halted
***
So, I put in the R code to generate the data matrix *hold. *But that
brought a host of other errors when checking in Rstudio with
devtools::check("S:/Documents/srcis/a.projects/Monte.Carlo.isr.and.package/Monte.Carlo.se.March.2023")
I started seeing the following list about standard functions like sd.
N checking R code for possible problems (3.4s)
boot.se: no visible global function definition for 'sd'
boot.var: no visible global function definition for 'var'
corr: no visible global function definition for 'cor'
cv: no visible global function definition for 'sd'
ratio.mean.sdhat.sd: no visible global function definition for 'sd'
ratio.mean.vhat.var: no visible global function definition for 'var'
ratio.sd: no visible global function definition for 'sd'
ratio.var: no visible global function definition for 'var'
varn: no visible global function definition for 'var'
Undefined global functions or variables:
cor sd var
Consider adding
importFrom("stats", "cor", "sd", "var")
to your NAMESPACE file.
But you can't add those functions to NAMESPACE. Well I did but
devtools::build()
gets rid of it. Also, I keep getting the message in the Rstudio check
WARNING
'qpdf' is needed for checks on size reduction of PDFs
but I got the latest versions of R and Rstudio and was able to get
qpdf to install and loaded with library(qpdf), but Rstudio still gives
that message.
So, if anybody has any suggestions, I would appreciate it.
Thanks.
Dennis
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission
Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
package.
Specifically, include this line in your DESCRIPTION file:
VignetteBuilder: R.rsp
Let's say the pdf file is called "myfile.pdf". Create a file called
"myfile.pdf.asis" that contains the vignette instructions. Put it in the
vignette directory along with the PDF file. Mine looks like:
%\VignetteIndexEntry{PUT VIGNETTE TITLE HERE}
%\VignetteKeywords{PUT KEYWORDS HERE}
%\VignetteDepends{PACKAGE_NAME}
%\VignettePackage{PACKAGE_NAME}
%\VignetteEngine{R.rsp::asis}
I am not certain if this works for an HTML vignette, but I see no reason
why it shouldn't.
Best,
Kevin
On 10/16/2023 10:14 AM, John Fox wrote:
Dear list members,
I believe that this issue has been discussed previously, but I'm not
sure that I have the solution right.
Georges Monette and I have developed a package that we intend to
submit soon to CRAN which has a vignette including code that takes a
long time to run. The sources for the package are available at
<https://github.com/gmonette/cv>.
We figure that we have to suppress running the code the vignette when
CRAN checks the package or the check time will be excessive.
The vignette is written as a .Rmd file to be compiled by knitr,
producing an HTML vignette. The top of the .Rmd file looks like this:
--- snip ---
---
title: "Cross-validation of regression models"
author: "John Fox and Georges Monette"
date: "`r Sys.Date()`"
package: cv
output:
rmarkdown::html_vignette:
fig_caption: yes
bibliography: ["cv.bib"]
csl: apa.csl
vignette: >
%\VignetteIndexEntry{Cross-validation of regression models}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
---
```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
message = TRUE,
warning = TRUE,
fig.align = "center",
fig.height = 6,
fig.width = 7,
fig.path = "fig/",
dev = "png",
comment = "#>",
eval = nzchar(Sys.getenv("REBUILD_CV_VIGNETTES"))
)
### other irrelevant setup code not shown ###
```
--- snip ---
So (near the bottom), if the environment variable REBUILD_CV_VIGNETTES
isn't empty, the code blocks in the vignette are evaluated, otherwise
not. To build the tarball for the package to be submitted to CRAN, we
will set REBUILD_CV_VIGNETTES to "true". That works as intended.
If we submit the tarball to CRAN, I believe that the package as
distributed by CRAN will include the HTML vignette from our tarball,
showing the evaluated code blocks, but when CRAN checks the package,
these long-running code blocks will not be executed (because
REBUILD_CV_VIGNETTES will not exist on the CRAN check machines).
My questions:
Is that correct?
If not, how can we ensure that the complete vignette is distributed by
CRAN without causing an overly long CRAN check time?
In particular, we don't want CRAN to rebuild and distribute the
vignette, because the resulting HTML file won't show the evaluated code.
Any assistance would be appreciated.
Thank you,
John
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] re-exporting plot method?
Hi,
I am working on a new package that primarily makes use of "igraph"
representations of certain mathematical graphs, in order to apply lots
of the comp sci algorithms already implemented in that package. For
display purposes, my "igraph" objects already include information that
defines node shapes and colors and edge styles and colors. But, I
believe that the "graph" - "Rgraphviz" - "graphNEL" set of tools will
produce better plots of the graphs.
So, I wrote my own "as.graphNEL" function that converts the "igraph"
objects I want to use into graphNEL (or maybe into "Ragraph") format in
order to be able to use their graph layout and rendering routines. This
function is smart enough to translate the node and edge attributes from
igraph into something that works correctly when plotted using the tools
in Rgraphviz. (My DESCRIPTION and NAMESPACE files already import the set
of functions from Rgraphviz necessary to make this happen.)
In principle, I'd like the eventual user to simply do something like
library("KevinsNewPackage")
IG <- makeIgraphFromFile(sourcefile)
GN <- as.graphNEL(IG)
plot(GN)
The first three lines work fine, but the "plot" function only works if
the user also explicitly includes the line
library("Rgraphviz")
I suspect that there is a way with imports and exports in the NAMESPACE
to make this work without having to remind the user to load the other
package. But (in part because the plot function in Rgraphviz is actually
an S4 method, which I don't need to alter in any way), I'm not sure
exactly what needs to be imported or exported.
Helpful suggestion would be greatly appreciated.
Best,
Kevin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] re-exporting plot method?
Hi Simon,
Thanks for the detailed answer. I had considered all those
possibilities, and was hoping that I had just missed something obvious.
I have been using S4 classes in my own packages for quite a while. But
here, I didn't see any need to create my own class. Now, I may make my
own, which presents a more abstract "graph" that can have realizations
both as 'igraph' or "graphNEL' - 'Rargaph'. I'll have to think about,
but that seems like the only reliable way to prevent putting al of
Rgraphviz into the user's namespace.
Oh, and CRAN doesn't complain about importing Rgraphviz, since
BioConductor is one of the "standard mainstream" repositories.
Best,
Kevin
On 4/30/2024 11:46 PM, Simon Urbanek wrote:
Kevin,
welcome to the S4 world! ;) There is really no good solution since S4 only
works at all if you attach the package since it relies on replacing the base S3
generic with its own - so the question remains what are your options to do it.
The most obvious is to simply add Depends: Rgraphviz which makes sure that any
generics required are attached so your package doesn't need to worry. This is
the most reliable in a way as you are not limiting the functionality to methods
you know about. The side-effect, though, (beside exposing functions the user
may not care about) is that such package cannot be on CRAN since Rgraphics is
not on CRAN (that said, you mentioned you are already importing then you seem
not to worry about that).
The next option is to simply ignore Rgraphviz and instead add setGeneric("plot") to your
package and add methods to Depends and importFrom(methods, setGeneric) + exportMethods(plot) to the
namespace. This allows you to forget about any dependencies - you are just creating the S4 generic
from base::plot to make the dispatch work. This is the most light-weight solution as you only
cherry-pick methods you need and there are no dependencies other than "methods". However,
it is limited to just the functions you care about.
Finally, you could re-export the S4 plot generic from Rgraphviz, but I'd say
that is the least sensible option, since it doesn't have any benefit over doing
it yourself and only adds a hard dependency for no good reason. Also copying
functions from another package opens up a can of worms with versions etc. -
even if the risk is likely minimal.
Just for completeness - a really sneaky way would be to export an S3 plot method from
your package - it would be only called in the case where the plot generic has not been
replaced yet, so you could "fix" things on the fly by calling the generic from
Rgraphviz, but that sounds a little hacky even for my taste ;).
Cheers,
Simon
On 1/05/2024, at 6:03 AM, Kevin R. Coombes wrote:
Hi,
I am working on a new package that primarily makes use of "igraph" representations of certain mathematical graphs, in
order to apply lots of the comp sci algorithms already implemented in that package. For display purposes, my "igraph"
objects already include information that defines node shapes and colors and edge styles and colors. But, I believe that the
"graph" - "Rgraphviz" - "graphNEL" set of tools will produce better plots of the graphs.
So, I wrote my own "as.graphNEL" function that converts the "igraph" objects I want to
use into graphNEL (or maybe into "Ragraph") format in order to be able to use their graph layout
and rendering routines. This function is smart enough to translate the node and edge attributes from igraph
into something that works correctly when plotted using the tools in Rgraphviz. (My DESCRIPTION and NAMESPACE
files already import the set of functions from Rgraphviz necessary to make this happen.)
In principle, I'd like the eventual user to simply do something like
library("KevinsNewPackage")
IG <- makeIgraphFromFile(sourcefile)
GN <- as.graphNEL(IG)
plot(GN)
The first three lines work fine, but the "plot" function only works if the user
also explicitly includes the line
library("Rgraphviz")
I suspect that there is a way with imports and exports in the NAMESPACE to make
this work without having to remind the user to load the other package. But (in
part because the plot function in Rgraphviz is actually an S4 method, which I
don't need to alter in any way), I'm not sure exactly what needs to be imported
or exported.
Helpful suggestion would be greatly appreciated.
Best,
Kevin
__
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-pkg-devel] Is R-Forge dead?
Hi, I have been maintaining packages in R-Forge for many tears. Last week I sent an email to r-fo...@r-project.org to report problems with the build process. It appears that any changes I have pushed to R-Forge over approximately the last two months have resulted in the package remaining in the "Building" state, even though the logs suggest that the package built successfully on both LINUX and Windows. (Also, four of the six affected packages only included changes to the man pages to clean up NOTEs from the R cmd checks on old versions at CRAN, where the new versions now happily reside.) I have received no response nor acknowledgement to my email to R-Forge. Assuming that R-Forge has finally succumbed to the ravages of entropy, does anyone have advice on creating a git project that contains multiple R packages? (I really don't want to have to create 20+ new git projects, one per package). Best, Kevin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Inherited methods
Hi,
I seem to have gotten myself confused about inheritance of S4 classes
and the dispatch of inherited methods.
The core situation is that
* The graphics package already defines the function "hist"
* My package A creates an S4 generic "hist", using the existing
function as the default method.
* Package A also defines a class B with its own implementation of the
method "hist". It exports both the generic method and the class B
specific method.
* Now I create a new package C. In that package, I define a new class
D that inherits from class B. The implementation of "hist" for class
B should do everything I want for class D, so I don't want to have
to re-implement it.
My question: what do I have to do to enable users of package D to call
"hist(B)" and have it work without complaint? After many go-rounds of
changing the code, changing the NAMESPACE, and running "R CMD check"
approximately an infinite number of times, I now have
NAMESPACE:
importMethodFrom("A", "hist")
exportMethod("hist")
R SCRIPT:
setClass("D", slots = c(some_extra_stuff), contains = "B")
setMethod("hist", "D", function(x, ...) {
callNextMethod(x, ...)
invisible(x)
})
Do I really need all that? Why do I even need *any* of it? Shouldn't I
be able to leave out the implementation that just says "callNextMethod"
and have the standard dispatch figure out what to call? Why does it want
to call the default function if it knows there is a B-method? (And it
must know it, since callNextMethod knows it.)
Confused,
Kevin
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD check options
Hi, I maintain a bunch of packages on CRAN. When updating packages, I often find two sort of NOTES on some of the platforms that CRAN checks that don't show up on my stupid Windows (I know that's redundant; you don't have to tell me) machine at home. The two most common issues are * spelling (especially in the DESCRIPTION file), and * links in the documentation with missing package anchors. How do I enable these checks so that when I run "R CMD check --as-cran" it actually does behave like those CRAN machines do, so I can find and fix the issues before submitting the package? Thanks, Kevin [[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] R CMD check options
Thank you! On 8/17/2024 9:24 AM, Ivan Krylov wrote: В Sat, 17 Aug 2024 09:17:40 -0400 Ben Bolker пишет: does there exist/has someone compiled a list of the environment variables that determine R CMD check's behaviour? https://cran.r-project.org/doc/manuals/R-ints.html#Tools But the _R_CHECK_CRAN_INCOMING_USE_ASPELL_ variable that Kevin would need to set to "TRUE" in order to enable the spell checks is not documented there. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Spell Check with Hunspell on Windows
Hi, This is a follow-up to an earlier question where I asked about R CMD check on Windows to be able to check R packages in a manner closer to the checks on CRAN machines before i submit (new or updated) packages. From the answers to the previous question, I learned the (magic) environment variable to set in order to trigger spell checks. So, I then managed to install "hunspell" n my Windows machine. I have confirmed that hunspell works * from the command line * inside emacs * inside R when running the "aspell" (or "hunspell") command to check files. (Note that I do not need to set the "program" argument to aspell in order for this to work.) However, when I run R CMD check from the command line, I get the message: ''No suitable spell-checker program found." Is there some other environment variable or command line option that I have to set in order to get R CMD check to use "hunspell" instead of "aspell" or "ispell"? Thanks, Kevin [[alternative HTML version deleted]] ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Getting error: Installation failed: Unknown username with my package
I had a few week development hiatus with github.com/rmsharp/nprcmanager and
when I tried to get a Travis build to work it failed. All of my local builds
are working without errors or warnings, but the
devtools::install_github(“rmsharp/nprcmanager”) fails with this error message
> library(devtools)
> install_github("rmsharp/nprcmanager")
Downloading GitHub repo rmsharp/nprcmanager@master
from URL https://api.github.com/repos/rmsharp/nprcmanager/zipball/master
Installing nprcmanager
Installation failed: Unknown username.
Two other packages of mine, one private rmsharp/renameSurgerySheets, and one
public rmsharp/rmsutilityr both install fine.
Does anyone know what I may have broken or how?
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
______
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Getting error: Installation failed: Unknown username with my package
Gabor,
You were exactly right. I do not think I would have caught that at all.
I had been going down the wrong path of thinking “Unknown username” was
referring to the way I was referring to my own package.
I am very grateful, but I must add that I got more enjoyment out of Duncan’s
quip.
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On Jul 13, 2018, at 7:17 PM, Gábor Csárdi wrote:
>
> Hi Mark,
>
> seems like you have "Remotes: covr" in the DESCRIPTION file, which is
> not a valid remote specification:
> https://github.com/rmsharp/nprcmanager/blob/f93e4e8056a8602654a94fc8685d9ed722c74db1/DESCRIPTION#L31-L32
>
> If you need the CRAN version of covr, remove the Remotes entry. If you
> need the GH version, use r-lib/covr
>
> Gabor
> On Fri, Jul 13, 2018 at 9:41 PM R. Mark Sharp wrote:
>>
>> I had a few week development hiatus with github.com/rmsharp/nprcmanager and
>> when I tried to get a Travis build to work it failed. All of my local builds
>> are working without errors or warnings, but the
>> devtools::install_github(“rmsharp/nprcmanager”) fails with this error message
>>
>>
>>> library(devtools)
>>> install_github("rmsharp/nprcmanager")
>> Downloading GitHub repo rmsharp/nprcmanager@master
>> from URL https://api.github.com/repos/rmsharp/nprcmanager/zipball/master
>> Installing nprcmanager
>> Installation failed: Unknown username.
>>
>> Two other packages of mine, one private rmsharp/renameSurgerySheets, and one
>> public rmsharp/rmsutilityr both install fine.
>>
>> Does anyone know what I may have broken or how?
>>
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>> __
>> 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] submitting to github
Hi Troels,
This probably doesn't score points for best practice, but if you only need to
post the files to GitHub, you could always set up a new repository on
github.com<http://github.com> and simply drag and drop the relevant files from
your computer into the browser window.
- Martin
--
Martin R. Smith
Assistant Professor in Palaeontology
Department of Earth Sciences
Durham University
Mountjoy Site, South Road
Durham DH1 3LE
T: +44 191 334 2320
M: +44 774 353 7510
E: martin.sm...@durham.ac.uk<mailto:martin.sm...@durham.ac.uk>
Skype: martin--smith
durham.ac.uk/earth.sciences/staff/academic/?id=14260<http://durham.ac.uk/earth.sciences/staff/academic/?id=14260>
twitter.com/PalaeoSmith<http://twitter.com/PalaeoSmith>
The information in this e-mail and any attachments is confidential. It is
intended solely for the addressee or addressees. If you are not the intended
recipient please delete the message and any attachments and notify the sender
of mis-delivery. Any use or disclosure of the contents of either is
unauthorised and may be unlawful.
Although steps have been taken to ensure that this e-mail and any attachments
are free from any virus, we advise the recipient to ensure they are indeed
virus free. All liability for viruses is excluded to the fullest extent
permitted by law.
On Fri, 25 Jan 2019 at 10:17, Joris Meys
mailto:joris.m...@ugent.be>> wrote:
Hi Troels,
origin: none means that git created a local repository but didn't link it
to a github account yet. If you're not that familiar with git, I suggest
you take a look at Github Desktop. We use that with our students, and even
I still use it sometimes. Github Desktop allows you to publish a local
repository to github with one click. You just have to set your credentials
after installing.
More info on adding a remote through shell :
https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/
More info on Github Desktop : https://desktop.github.com/
Hope this helps
Cheers
Joris
On Fri, Jan 25, 2019 at 10:22 AM Troels Ring
mailto:tr...@gvdnet.dk>> wrote:
> Hi Stefan – thanks for the question: I have a newly developed package
> which I need to have on github for a publication. So, while there still a
> minor problems in the package as it is, I started to trying to interact
> with github so really I am trying to put a working package onto github.
>
> All best
>
> Troels
>
>
>
> Fra: Stefan McKinnon Høj-Edwards mailto:s...@iysik.com>>
> Sendt: 25. januar 2019 09:59
> Til: Troels Ring mailto:tr...@gvdnet.dk>>; package-develop <
> r-package-devel@r-project.org<mailto:r-package-devel@r-project.org>>
> Emne: Re: [R-pkg-devel] submitting to github
>
>
>
> Hej Troels,
>
>
>
> What exactly are you trying to acheive here? I.e., are you trying to 1)
> put a new project onto github, or 2) copy a repository on github to your
> local computer, or 3) do as 2) and then update it your current
> modifications?
>
>
>
>
> Stefan McKinnon Høj-Edwards
>
> Mobile: (+45) 2888 6598
>
>
>
>
>
> Den fre. 25. jan. 2019 kl. 09.51 skrev Troels Ring
> mailto:tr...@gvdnet.dk>
> <mailto:tr...@gvdnet.dk<mailto:tr...@gvdnet.dk>> >:
>
> Dear friends - I'm sorry to bother but seem to be unable to interact
> constructively with github.
>
>
>
> I try to follow the instructions from Hadley (thanks) - i.e. I have a
> small trial-project which functions well. Since I have tried many times I
> start from shell with
>
> rm -rf .git
>
> and then select version control using git (tools, project options,git/svn)
> -
> and origin is still marked as "none" after restarting RStudio.
>
> Then from shell again: git init
>
> Yielding
>
> Initialized empty Git repository in
> C:/Users/Troels/Dropbox/Rown/ABCharge/.git/
>
> Rstudio restarted, package reopened: origin still "none"
>
> Git panel appears OK.
>
>
>
> Now from github: add new repository (non present after prior deletions!)
>
> Named as package name - repeated in description - repository created
>
>
>
> Shell opened from RStudio
>
> git remote add origin https://github.com/troelsring/ABCharge.git - works
> without problems - an origin seems correctly accepted in RStudio - but
> then:
>
> git push -u origin master - results in:
>
>
>
> error: src refspec master does not match any.
>
> error: failed to push some refs to
> 'https://github.com/troelsring/ABCharge.git' below in red
>
>
>
> I seem (also!) to have problems with the SSH keys - Rstudio marks that I
> have a key in c:/Users/Troels/.ssh/id_rsa -
>
> but when I run file.exists("~/.ssh/id_rsa.pub")
&
Re: [R-pkg-devel] Change in normal random numbers between R 3.5.3 and R 3.6.0
I was dealing with a similar issue but in the context of getting the same unit
test code to work on multiple versions of R in a Travis-CI build. It seems
RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so I
resorted to using version dependent construction of the argument list to
set.seed() in do.call().
I better solution will be greatly appreciated.
#' Work around for unit tests using sample()
#'
#' @param seed argument to \code{set.seed}
set_seed <- function(seed = 1) {
version <- as.integer(R.Version()$major) + (as.numeric(R.Version()$minor) /
10.0)
if (version >= 3.6) {
args <- list(seed, sample.kind = "Rounding")
} else {
args <- list(seed)
}
suppressWarnings(do.call(set.seed, args))
}
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On May 9, 2019, at 12:45 PM, Duncan Murdoch wrote:
>
> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
>> Hmmmh, but does that also apply if the sample.kind has been set to the
>> old version? I.e., would
>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>> val <- 10
>> set.seed(val)
>> discard <- sample(1000, 100)
>> rnorm(36)
>> produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
>> expected it to, but it seems to produce the same normal random numbers
>> as R version 3.6.0 in the previous version of the test code without the
>> RNGkind call.
>
> I'm not seeing that, but I'm not using the exact versions you tested. If I
> run your code in "R version 3.5.2 (2018-12-20)" and "R Under development
> (unstable) (2019-05-02 r76454)" I get this output from both:
>
> > if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
> > val <- 10
> > set.seed(val)
> > discard <- sample(1000, 100)
> > rnorm(36)
> [1] -0.4006375 -0.3345566 1.3679540 2.1377671 0.5058193 0.7863424
> -0.9022119 0.5328970 -0.6458943 0.2909875 -1.2375945
> [12] -0.4561763 -0.8303227 0.3401156 1.0663764 1.2161258 0.7356907
> -0.4812086 0.5627448 -1.2463197 0.3809222 -1.4304273
> [23] -1.0484455 -0.2185036 -1.4899362 1.1727063 -1.4798270 -0.4303878
> -1.0516386 1.5225863 0.5928281 -0.2226615 0.7128943
> [34] 0.7166008 0.4402419 0.1588306
>
> Okay, I just installed 3.6.0, and I get the same values there. I don't see a
> Mac binary for 3.5.3, so I can't test that one.
>
> Duncan Murdoch
>
> __
> 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] Change in normal random numbers between R 3.5.3 and R 3.6.0
Ulrike,
RNGkind() worked on 3.4.1 and 3.6.0 but generated a warning on R 3.5.3. The
message follows:
checking whether package ‘nprcmanager’ can be installed ... WARNING
Found the following significant warnings:
Note: possible error in 'RNGkind(sample.kind = "Rounding")': unused argument
(sample.kind = "Rounding")
See ‘/tmp/RtmpA4S3Ki/file32b81c218ac8/nprcmanager.Rcheck/00install.out’ for
details.
Information on the location(s) of code generating the ‘Note’s can be
obtained by re-running with environment variable R_KEEP_PKG_SOURCE set
to ‘yes’.
Mark
R. Mark Sharp
rmsh...@me.com
> On May 9, 2019, at 11:39 PM, Ulrike Grömping
> wrote:
>
> Mark,
>
> I used
>
> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>
> And that works. Actually, using rnorm afterwards also yields the same random
> numbers.
> My question arose from the fact that I confused myself about the noLD output
> I was supposed to reproduce. Therefore, my problem should be entirely
> explained by Duncan Murdoch's initial explanation: the sample() change does
> not only lead to different results in discrete sampling but also to different
> results from random number calls for other functions (like rnorm).
>
> Best, Ulrike
>
> Am 10.05.2019 um 04:58 schrieb R. Mark Sharp:
>> I was dealing with a similar issue but in the context of getting the same
>> unit test code to work on multiple versions of R in a Travis-CI build. It
>> seems RNGkind(sample.kind="Rounding”) does not work prior to version 3.6 so
>> I resorted to using version dependent construction of the argument list to
>> set.seed() in do.call().
>>
>> I better solution will be greatly appreciated.
>>
>> #' Work around for unit tests using sample()
>> #'
>> #' @param seed argument to \code{set.seed}
>> set_seed <- function(seed = 1) {
>> version <- as.integer(R.Version()$major) + (as.numeric(R.Version()$minor)
>> / 10.0)
>> if (version >= 3.6) {
>> args <- list(seed, sample.kind = "Rounding")
>> } else {
>> args <- list(seed)
>> }
>> suppressWarnings(do.call(set.seed, args))
>> }
>>
>> Mark
>>
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On May 9, 2019, at 12:45 PM, Duncan Murdoch
>>> wrote:
>>>
>>> On 09/05/2019 12:43 p.m., Ulrike Grömping wrote:
>>>> Hmmmh, but does that also apply if the sample.kind has been set to the
>>>> old version? I.e., would
>>>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>>>> val <- 10
>>>> set.seed(val)
>>>> discard <- sample(1000, 100)
>>>> rnorm(36)
>>>> produce the same normal random numbers in 3.5.3 and 3.6.0? I would have
>>>> expected it to, but it seems to produce the same normal random numbers
>>>> as R version 3.6.0 in the previous version of the test code without the
>>>> RNGkind call.
>>> I'm not seeing that, but I'm not using the exact versions you tested. If I
>>> run your code in "R version 3.5.2 (2018-12-20)" and "R Under development
>>> (unstable) (2019-05-02 r76454)" I get this output from both:
>>>
>>>> if (getRversion()>="3.6.0") RNGkind(sample.kind="Rounding")
>>>> val <- 10
>>>> set.seed(val)
>>>> discard <- sample(1000, 100)
>>>> rnorm(36)
>>> [1] -0.4006375 -0.3345566 1.3679540 2.1377671 0.5058193 0.7863424
>>> -0.9022119 0.5328970 -0.6458943 0.2909875 -1.2375945
>>> [12] -0.4561763 -0.8303227 0.3401156 1.0663764 1.2161258 0.7356907
>>> -0.4812086 0.5627448 -1.2463197 0.3809222 -1.4304273
>>> [23] -1.0484455 -0.2185036 -1.4899362 1.1727063 -1.4798270 -0.4303878
>>> -1.0516386 1.5225863 0.5928281 -0.2226615 0.7128943
>>> [34] 0.7166008 0.4402419 0.1588306
>>>
>>> Okay, I just installed 3.6.0, and I get the same values there. I don't see
>>> a Mac binary for 3.5.3, so I can't test that one.
>>>
>>> Duncan Murdoch
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> --
> ##
> ## Prof. Ulrike Groemping
> ## FB II
> ## Beuth University of Applied Sciences Berlin
> ##
> ## prof.beuth-hochschule.de/groemping
> ## Phone: +49(0)30 4504 5127
> ## Fax: +49(0)30 4504 66 5127
> ## Home office: +49(0)30 394 04 863
> ##
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] checking CRAN incoming feasibility NOTE
I getting ready to submit a package to CRAN for the first time. I have run cran_prep <- check_for_cran() using the rhub package. I understand that as a new package it will generate a NOTE. As a novice, I do not know what is to be expected within that NOTE and want to make sure the NOTEs I have received are satisfactory. I have not found an example of a minimal first submission NOTE. Below is what I am getting from the above test on rhub. I have three test environments but only two NOTEs. Do these results indicate a problem to be addressed? > cran_prep$cran_summary() For a CRAN submission we recommend that you fix all NOTEs, WARNINGs and ERRORs. ## Test environments - R-hub windows-x86_64-devel (r-devel) - R-hub ubuntu-gcc-release (r-release) - R-hub fedora-clang-devel (r-devel) ## R CMD check results ❯ On windows-x86_64-devel (r-devel), ubuntu-gcc-release (r-release) checking CRAN incoming feasibility ... NOTE Maintainer: 'R. Mark Sharp ' New submission License components with restrictions and base license permitting such: MIT + file LICENSE File 'LICENSE': Copyright 2017-2019 R. Mark Sharp Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ❯ On fedora-clang-devel (r-devel) checking CRAN incoming feasibility ...NB: need Internet access to use CRAN incoming checks NOTE Maintainer: ‘R. Mark Sharp ’ License components with restrictions and base license permitting such: MIT + file LICENSE File 'LICENSE': Copyright 2017-2019 R. Mark Sharp Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 0 errors ✔ | 0 warnings ✔ | 2 notes ✖ > R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] checking CRAN incoming feasibility NOTE
Roy, Thank you for your guidance and advice. I ran usethis::use_cran_comments() shown below. > usethis::use_cran_comments() ✔ Setting active project to '/Users/msharp/Documents/Development/R/r_workspace/library/nprcmanager' ✔ Writing 'cran-comments.md' ✔ Adding '^cran-comments\\.md$' to '.Rbuildignore' ● Modify 'cran-comments.md’ The text of “cran-comments.md” follows and also makes me think it was a clean inspection: ## Test environments * local OS X install, R 3.6.1 * ubuntu 14.04 (on travis-ci), R 3.6.1 * win-builder (devel and release) ## R CMD check results 0 errors | 0 warnings | 1 note * This is a new release. R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Oct 5, 2019, at 5:10 PM, Roy Mendelssohn - NOAA Federal > wrote: > > use this::use_cran_comments() > > There is a place to put that it is a new submission > > I would recommend also testing using: > > devtools::check_win_release() > devtools::check_win_devel() > > You should only have the one note that it is a new submission. When you > submit, you may or may not get a note that it was rejected by the automatic > checker. Sit tight, someone from CRAN will see that it is a new submission. > A new submission is given a much more thorough review, so it can take a > coupe days or more for CRAN to get back to you. You can check the status of > CRAN submissions at: > > https://cransays.itsalocke.com/articles/dashboard.html > > HTH, > > -Roy > > >> On Oct 5, 2019, at 2:52 PM, R. Mark Sharp wrote: >> >> I getting ready to submit a package to CRAN for the first time. I have run >> cran_prep <- check_for_cran() using the rhub package. I understand that as a >> new package it will generate a NOTE. As a novice, I do not know what is to >> be expected within that NOTE and want to make sure the NOTEs I have received >> are satisfactory. I have not found an example of a minimal first submission >> NOTE. Below is what I am getting from the above test on rhub. I have three >> test environments but only two NOTEs. Do these results indicate a problem to >> be addressed? >> >>> cran_prep$cran_summary() >> For a CRAN submission we recommend that you fix all NOTEs, WARNINGs and >> ERRORs. >> ## Test environments >> - R-hub windows-x86_64-devel (r-devel) >> - R-hub ubuntu-gcc-release (r-release) >> - R-hub fedora-clang-devel (r-devel) >> >> ## R CMD check results >> ❯ On windows-x86_64-devel (r-devel), ubuntu-gcc-release (r-release) >> checking CRAN incoming feasibility ... NOTE >> Maintainer: 'R. Mark Sharp ' >> >> New submission >> >> License components with restrictions and base license permitting such: >> MIT + file LICENSE >> File 'LICENSE': >> Copyright 2017-2019 R. Mark Sharp >> >> Permission is hereby granted, free of charge, to any person obtaining a >> copy of this software and associated documentation files (the "Software"), >> to deal in the Software without restriction, including without limitation >> the rights to use, copy, modify, merge, publish, distribute, sublicense, >> and/or sell copies of the Software, and to permit persons to whom the >> Software is furnished to do so, subject to the following conditions: >> >> The above copyright notice and this permission notice shall be included in >> all copies or substantial portions of the Software. >> >> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR >> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE >> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS >> IN THE SOFTWARE. >> >> ❯ On fedora-clang-devel (r-devel) >> checking CRAN incoming feasibility ...NB: need Internet access to use CRAN >> incoming checks >> NOTE >> Maintainer: ‘R. Mark Sharp ’ >> >> License components with restrictions and base license permitting such: >> MIT + file LICENSE >> File 'LICENSE': >> Copyright 2017-2019 R. Mark Sharp >> >> Permission is hereby granted, free of charge, to any person obtaining a >> copy of this software and associated documentation files (the "Software"), &g
[R-pkg-devel] R-hub PREPERROR on Ubuntu Linux 16.04 LTS, R-release, GCC not on other platforms
Should I ignore this problem with regard to going forward with a submission to CRAN? It looks like some CRAN packages that I am dependent on are not available on the Ubuntu Linux 16.04 LTS platform. #> Failed with error: ‘there is no package called ‘shiny’’ #> ERROR: dependency ‘openssl’ is not available for package ‘httr’ #> ERROR: dependency ‘httr’ is not available for package ‘covr’ #> ERROR: dependency ‘httr’ is not available for package ‘Rlabkey’ #> ERROR: dependencies ‘httr’, ‘openssl’ are not available for package ‘pkgdown’ #> ERROR: dependency ‘Rlabkey’ is not available for package ‘nprcmanager’ The following platforms have no errors or warnings and have only the “New submission” note. Windows Server 2008 R2 SP1, R-devel, 32/64 bit Fedora Linux, R-devel, clang, gfortran Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] compression of vignettes
I have been unsuccessful with all of the following attempts to have compression
of dynamically generated vignettes during the build on travis-ci and within
RStudio. Help is appreciated.
I have tried the following travis-ci YAML to have vignettes compressed.
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual'), build_args =
c('--compact-vignettes=both'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes=gs+qpdf'); devtools::test(); quit(save = "no", status = if
(length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
script:
- R -e 'r <- rcmdcheck::rcmdcheck(".", args = c('--no-manual',
'--compact-vignettes="gs+qpdf"'); devtools::test(); quit(save = "no", status =
if (length(c(r$errors, r$warnings)) > 0) { 1 } else { 0 }, runLast = FALSE)'
I have tried the following build arguments in RStudio
--as-cran --compact-vignettes=gs+qpdf
--as-cran --compact-vignettes=both
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Manual inspection of a new CRAN submission
Mauricio, I appreciate the manual inspection. I am waiting for the second time on a manual inspection. The first inspection found a fairly severe error of mine where I was writting out an error file to the user’s home directory space. It was code I had written over two years ago and long before I considered submission to CRAN. The code is only exercised with an specific data error when manually exercising the API of the Shiny application included in the package. I was certainly embarrashed by my error but I am more grateful for the work of Kurt Hornik and Uwe Ligges who found the mistake. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Dec 18, 2019, at 7:26 PM, Mauricio Zambrano-Bigiarini > wrote: > > Thank you very much Duncan for the information. > > BTW, it is incredible to me how the quality control of packages > submitted to CRAN has improved in the last decade. Now the automatic > procedures are able to identify even "little" things (e.g., broken > links, misspelled words, size of vignettes, etc). > > Thank you very much for all the effort and dedication of the CRAN > Repository Maintainers. > > Kind regards, > > Mauricio > > = > "Success is not final, failure is not fatal. > It is the courage to continue that counts. > (Winston Churchill) > = > Linux user #454569 -- Linux Mint user > > On Wed, 18 Dec 2019 at 19:50, Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote: >> >> On 18/12/2019 5:01 p.m., Mauricio Zambrano-Bigiarini wrote: >>> Dear List, >>> >>> Today I submitted a package to CRAN, and after correcting some NOTEs, >>> I got the following automatic message: >>> >>> "package mypackage_0.1-2.tar.gz has been auto-processed and is pending >>> a manual inspection of this new CRAN submission. A CRAN team member >>> will typically respond to you within the next 10 working days. For >>> technical reasons you may receive a second copy of this message when a >>> team member triggers a new check." >>> >>> >>> Could somebody give a short explanation about what type of checkings >>> are made in this "manual inspection" ? >>> >> >> Basically they're checking whether you are following the guidelines at >> https://cran.r-project.org/web/packages/policies.html. Not all of those >> things can be checked automatically, and many people claim to be >> following them when they actually are not. >> >> Duncan Murdoch > > -- > La información contenida en este correo electrónico y cualquier anexo o > respuesta relacionada, puede contener datos e información confidencial y no > puede ser usada o difundida por personas distintas a su(s) destinatario(s). > Si usted no es el destinatario de esta comunicación, le informamos que > cualquier divulgación, distribución o copia de esta información constituye > un delito conforme a la ley chilena. Si lo ha recibido por error, por favor > borre el mensaje y todos sus anexos y notifique al remitente. > > __ > R-package-devel@r-project.org <mailto:R-package-devel@r-project.org> mailing > list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > <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
[R-pkg-devel] Examples for functions called by Shiny server
I have been asked to provide examples within the Rd files of my package (github.com/rmsharp/nprcgenekeepr <http://github.com/rmsharp/nprcgenekeepr>) by the CRAN package reviewer. I have to export those functions called by the server.R script (or use ::: notation), which in turn generates an Rd file that is to have the example. I cannot think of a meaningful example for a function that creates the content of a new Shiny tabpanel when an error is detected. Suggestions are eagerly sought. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Fwd: [R] a question of etiquette
Adelchi,
I have a similar situation where I had made all of the typical academic
references within the code and documentation for a small but important function
my package uses. I was asked by the CRAN reviewers to add the author of that
function to the DESCRIPTION Authors@R section. I added the following:
person("Terry", "Therneau", role = c("aut”))
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> Begin forwarded message:
>
> From: Adelchi Azzalini
> Subject: [R] a question of etiquette
> Date: June 1, 2020 at 11:34:00 AM CDT
> To: r-h...@r-project.org
>
> The new version of a package which I maintain will include a new function
> which I have ported to R from Matlab.
> The documentation of this R function indicates the authors of the original
> Matlab code, reference to their paper, URL of the source code.
>
> Question: is this adequate, or should I include them as co-authors of the
> package, or as contributors, or what else?
> Is there a general policy about this matter?
>
> Adelchi Azzalini
> http://azzalini.stat.unipd.it/
>
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
[[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] [R] a question of etiquette
Adelchi,
Actually, the person recognized wrote the original code for the algorithm and
he has had other contributors over time that have made several improvements.
The code I have is not verbatim from his package as it has been adapted for our
purposes, but he is still the originator of the approach and I am certain he
and others would recognize the code as being clearly deriviative. I have
retained some of the same function names or near derivatives of those names. My
coding style is different but that has not changed the basic logic.
With regard to licensing, we both use MIT, which I strongly prefer. The GPL-2
and GPL-3 licenses are apparently sufficiently ambiguous in the legal community
that some companies avoid them.
Mark
R. Mark Sharp, Ph.D.
Data Scientist and Biomedical Statistical Consultant
7526 Meadow Green St.
San Antonio, TX 78251
mobile: 210-218-2868
rmsh...@me.com
> On Jun 2, 2020, at 1:32 AM, Adelchi Azzalini wrote:
>
> Thanks for this information, Mark.
>
> Given the phrase "small but important function my package uses", it seems
> that you included in your package some code, reproducing it verbatim.
> Do I understand correctly?
> In my case, the code which I am actually using is the R porting of code
> originally written in another language, namely Matlab.
>
> Best wishes,
>
> Adelchi
>
>
>> On 1 Jun 2020, at 23:37, R. Mark Sharp wrote:
>>
>> Adelchi,
>>
>> I have a similar situation where I had made all of the typical academic
>> references within the code and documentation for a small but important
>> function my package uses. I was asked by the CRAN reviewers to add the
>> author of that function to the DESCRIPTION Authors@R section. I added the
>> following:
>> person("Terry", "Therneau", role = c("aut”))
>>
>> Mark
>> R. Mark Sharp, Ph.D.
>> Data Scientist and Biomedical Statistical Consultant
>> 7526 Meadow Green St.
>> San Antonio, TX 78251
>> mobile: 210-218-2868
>> rmsh...@me.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> From: Adelchi Azzalini
>>> Subject: [R] a question of etiquette
>>> Date: June 1, 2020 at 11:34:00 AM CDT
>>> To: r-h...@r-project.org
>>>
>>> The new version of a package which I maintain will include a new function
>>> which I have ported to R from Matlab.
>>> The documentation of this R function indicates the authors of the original
>>> Matlab code, reference to their paper, URL of the source code.
>>>
>>> Question: is this adequate, or should I include them as co-authors of the
>>> package, or as contributors, or what else?
>>> Is there a general policy about this matter?
>>>
>>> Adelchi Azzalini
>>> http://azzalini.stat.unipd.it/
>>>
>>> __
>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [R] a question of etiquette
For academics, aren't those citations the currency in which they are supposed to be paid (at least for R packages)? Kevin On 6/2/2020 3:24 PM, Avraham Adler wrote: On Tue, Jun 2, 2020 at 5:04 PM Spencer Graves < spencer.gra...@effectivedefense.org> wrote: QUESTION: How much money have people on this list received for what they've written? I've received not one penny for any technical article I've written or for software contributed to CRAN. Spencer Ditto. What's even more annoying is when people clearly use one's package in their published work and do not cite it, but that is for a different thread. Avi [[alternative HTML version deleted]] __________ 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] [R] a question of etiquette
Spencer, I apologize for my obvious (in hindsight) error in bringing up the topic. I will bring up one example, because of your request. Google has listed GPL-1, 2, and 3 as one of several licenses that are restricted and cannot be used by a Google product delivered to outside customers. This include downloadable client software and software such as insdie the Google Search Appliance. This includes having scripts that load packages dynamically as with “library()” and “require()”. Please see https://opensource.google/docs/thirdparty/licenses/#restricted for their wording. I am not defending their position and disagree with it. However, it is their position based on what I think is a conservative or overly cautious legal interpretation. I am not a lawyer, however, so my opinions are of no import. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Jun 2, 2020, at 10:22 AM, Spencer Graves > wrote: > > Can Dr. Sharp kindly provide a credible reference, discussing the > alleged ambiguities in GPL-2 and GPL-3 that convince some companies to avoid > them? > > > I like Wikimedia Foundation projects like Wikipedia, where almost > anyone can change almost anything, and what stays tends to be written from a > neutral point of view, citing credible sources. I get several emails a day > notifying me of changes in articles I'm "watching". FUD, vandalism, etc., > are generally reverted fairly quickly or moved to the "Talk" page associated > with each article, where the world is invited to provide credible source(s). > > > Spencer Graves > > > On 2020-06-02 10:12, Dirk Eddelbuettel wrote: >> On 2 June 2020 at 10:06, R. Mark Sharp wrote: >> | The GPL-2 and GPL-3 licenses are apparently sufficiently ambiguous in the >> legal community that some companies avoid them. >> >> Wittgenstein: 'That whereof we cannot speak, thereof we must remain silent' >> >> This is a mailing list of the R project. R is a GNU Project. R is licensed >> under the GPL, version two or later. That has not stopped large corporations >> from using R, adopting R, or starting or acquiring R related businesses. >> >> If you have a strong urge to spread FUD about the GPL and R, could you have >> the >> modicum of etiquette to not do it on a mailing list of the R Project? >> >> Dirk >> > > ______ > R-package-devel@r-project.org <mailto:R-package-devel@r-project.org> mailing > list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > <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] [External] Re: Two packages with the same generic function
Wait; I have options on how to configure conflict resolution? Can you tell me where to read more about this feature? Thanks, Kevin On 6/22/2020 10:51 PM, luke-tier...@uiowa.edu wrote: On Tue, 23 Jun 2020, Bert Gunter wrote: "Users don't get warned about overriding names in packages they've loaded, because that would just be irritating." All Duncan is saying is that you don't get a notification if you do mean <- log in the interpreter. If you attach a package that does this you would get a notification (or an error if you configure your conflict resolution options appropriately). Best, luke __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Debugging Clang ASAN errors
A package I recently had accepted to CRAN is throwing up a "memory not
mapped" segfault on CRAN's post-acceptance fedora-clang ASAN test. This
error does not occur with debian-clang or gcc.
(Check results:
https://cran.r-project.org/web/checks/check_results_TBRDist.html)
I found a similar issue in the r-packages archives (
https://stat.ethz.ch/pipermail/r-package-devel/2018q3/002907.html). The
suggestion in that case was that the issue may have been a false positive,
a possibility that is consistent with a "HINT" in the output log.
I optimistically suspect that this is the case here too: my package is an R
wrapper to a mature C library, and the segmentation fault arises during a
routine operation with simple input, not in some obscure corner case. So
question one is: how might I confirm that this is indeed a false positive?
If it's not a false positive, then this raises the question of how I might
reproduce it, as a Windows user without access to a machine running Fedora.
rhub::check_with_sanitizers() uses debian, and returns 'success':
https://builder.r-hub.io/status/TBRDist_1.0.0.9000.tar.gz-b965d74e18dd4bdc8e51e4254ee3699a
Rocker (https://github.com/rocker-org/rocker) only offers a debian (not
fedora) environment, so looks like it will not reproduce the error.
Any thoughts would be gratefully received!
Thanks,
Martin
--
*Dr. Martin R. Smith*
Assistant Professor in Palaeontology
Durham University
Department of Earth Sciences
Mountjoy Site, South Road, Durham, DH1 3LE United Kingdom
*T*: +44 (0)191 334 2320
*M*: +44 (0)774 353 7510
*E*: martin.sm...@durham.ac.uk
community.dur.ac.uk/martin.smith
twitter.com/PalaeoSmith
The information in this e-mail and any attachments is co...{{dropped:13}}
__________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] DOI for archived package?
Hi, I am in the process of submitting a "workflow" article about an R package (which is onCRAN) to F1000Research. The associate editor that I am dealing with wants a "DOI" for the source code of the package being described in the manuscript. I have already explained that CRAN archives all versions of packages, and I sent him the URL to the archive page for the package, However, he still seems to believe that a DOI needs to be assigned by some site like Zenodo. I haven't yet responded by pointing out that CRAN has been archiving all versions of packages since at least the year 2000, it has mirrors all over the world, and the URL/URI used here is likely to be far more permanent than the DOI from Zenodo. Nor have I pointed out that there are more than 15,000 packages at CRAN, nor that not a single R user would ever think to go look on Zenodo for an R package. Does anyone have other suggestions for how to respond? (I know; I could just put the [expletive] thing into Zenodo and move on, but creating a permanent identifier for something that will *never *be accessed just seems stupid.) Thanks, Kevin [[alternative HTML version deleted]] __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Licenses
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Strange error from CRAN on package submission
Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report > Check: whether package can be installed. > Result: WARN > Found the following significant warnings: > Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters > Result: WARN > Warning: namespace 'flexmix' is not available and has been replaced > by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[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] Strange error from CRAN on package submission
Hi Uwe, Thanks for the suggestion. I thought of that idea last night, and tried it with the latest submission of version 0.11.4 of Mercator. That version is still in the submission queue waiting for manual inspection, but it gave the same error message. (See https://win-builder.r-project.org/incoming_pretest/Mercator_0.11.4_2020_014655/Debian/00check.log) I think I may try to "Import" or "Depend" on flexmix to force it to be available. Is there some reason why my program should even need to know that flexmix is suggested several layers down the dependency hierarchy? For building and installing the package (or running R CMD check ---as-cran), I tried on my machine when flexmix is not even installed, and got no errors or warnings. There is clearly something I don't understand about namespaces, and I'd like to learn it to avoid this kind of situation in the future. Best, Kevin On 11/11/2020 11:14 AM, Uwe Ligges wrote: You have to suggest flexmix. Best, Uwe Ligges On 11.11.2020 14:44, Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[alternative HTML version deleted]] __ 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] Strange error from CRAN on package submission
Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[alternative HTML version deleted]] __ 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] Strange error from CRAN on package submission
HI Uwe,
That might be the key observation. The change to Mercator in this
package was to add a "show" method to an S4 class. In its NAMESPACE, the
flexmix package also exports a "show" method.
Both "flexmix" and "Mercator" have an
import("methods")
directive in their NAMESPACE files, which is where the base method for
"show" comes from. Also, if you just type show at the command prompt to
see the definition, you get the parenthetical note that
"(This generic function excludes non-simple inheritance' see ?setIs.)"
I don't completely understand what this parenthetical remark means, but
I have a suspicion that it is highly relevant to my problem.
If I run
library("Mercator")
showMethods("show")
on a system where flexmix is installed, then the "show" method for
flexmix (and related objects) is listed, because the flexmix NAMESPACE
has been attached. If I run the same code on an R system where flexmix
is not installed, then, of course, neither the NAMESPACE nor the method
is available.
I suspect (but am by no means certain) that the combination of that
parenthetical remark above and the existence of the "show" method in the
suggested package is why I am getting errors on some systems.
But I don't really understand why. My package doesn't need the flexmix
version of show. And (as Uwe said in an earlier comment), I thought that
"Suggests" isn't supposed to be inherited. I don't want the flexmix
NAMESPACE attached, since nothing in my package nor in the packages I
directly want (Thresher by "Depends" and then moVMF by "Imports")
actually requires it.
Why does the flexmix NAMESPACE get attached if some other package down
the line merely suggests it? Is that supposed to happen? To me, it feels
like a bug in the sense that it surprises the user (i.e., the package
developer). And I guess is potentially a bug for the ultimate user of
the package, since it adds a NAMESPACE that was not specifically
requested by the top level package being loaded.
In any event, what's the best advice now on how to proceed?
Thanks again,
Kevin
On 11/11/2020 11:34 AM, Uwe Ligges wrote:
Next guess is that you need more, because you may have an object that
needs the flexmix, so likely something S4 related? I can take a closer
look.
Best,
Uwe Ligges
On 11.11.2020 17:30, Duncan Murdoch wrote:
Uwe suggested you suggest flexmix, but I see below you already tried
that.
I'd like to take a look, but I can't find your package. The existing
version on CRAN gives the URL as http://oompa.r-forge.r-project.org/,
but I can't see it mentioned there.
Duncan Murdoch
On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote:
Hi,
I am trying to figure out how to fix warnings from two of the CRAN
machines on the submission of an update to a package. The only
change to
my package was to add a "show" method to one of the S4 classes, which
was requested by a reviewer of the paper we submitted. The inability to
get this updated package into CRAN is the only thing holding up the
revision (and probable acceptance) of the manuscript.
The same "warnings"s were found in the previous version. The package is
called Mercator, and the CRAN check results from the last version
are here:
https://cran.r-project.org/web/checks/check_results_Mercator.html
I get warnings from the two fedora machine instances (clang and gcc).
They both report
Check: whether package can be installed.
Result: WARN
Found the following significant warnings:
Warning: namespace ‘flexmix’ is not available and has been
replaced
>
> Check: data for non-ASCII characters
Result: WARN
Warning: namespace 'flexmix' is not available and has been
replaced
by .GlobalEnv when processing object ''
The relationships in the DESCRIPTION files are:
1. Mercator depends on Thresher
2. Thresher imports moVMF
3. moMVF suggests flexmix
On my Windows machine, the package builds and installs with no
errors or
warnings even if flexmix is not available (which I believe to be the
correct behavior). On R-Forge, both the Windows and LINUX versions
build
and install with no errors or warnings. On R-Hub, tested on multiple
LINUX versions, the package builds and installs with no errors or
warnings.
And flexmix is still clearly available from CRAN:
https://cran.r-project.org/web/packages/flexmix/index.html
In the latest attempt to get things to work, I added
Suggests: flexmix
into the DESCRIPTION file for Mercator, but this didn't help fix the
problem on CRAN.
Is there anything I can do to fix this problem (other than moan here on
this list and hope that CRAN can just install flexmix on those
machines)?
Thanks in advance for your help,
Kevin
[[alternative HTML v
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[alternative HTML version deleted]] __ 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] Strange error from CRAN on package submission
Oh, I forgot to mention explicitly that checking (with --as-cran) on the development version of R on Windows also produces no errors or warnings. On 11/11/2020 1:39 PM, Kevin R. Coombes wrote: Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[alternative HTML version deleted]] __ 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] Strange error from CRAN on package submission
Hi Duncan, Thanks for the help. For now (since I want my package to get into CRAN so I can resubmit my paper), I'll add the "Import" clause, and write myself a note to try removing it later. Best, Kevin On 11/11/2020 4:44 PM, Duncan Murdoch wrote: Here's what I think is happening. In the movMF:::.onLoad function there's a test whether flexmix is installed. If found, then it is loaded and some methods are set. (I'm not sure what caused flexmix to be installed: I didn't intentionally install it, but it ended up in there when I installed enough stuff to check Mercator.) In the R-devel --as-cran checks, some checks are run with only strong dependencies of your package visible. Somehow I think that .onLoad function sees flexmix and loads it, but then some other part of the check can't see it. A workaround is to add flexmix to your Imports clause. This is a strong enough dependency to make it visible, and the error goes away. HOWEVER, to me this is pretty clearly an R-devel bug: you have no control over methods set by packages that you don't even use, so you shouldn't have to change your dependency lists if one of them sets a method that you're using. Duncan Murdoch On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote: Oh, I forgot to mention explicitly that checking (with --as-cran) on the development version of R on Windows also produces no errors or warnings. On 11/11/2020 1:39 PM, Kevin R. Coombes wrote: Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Martin,
I think you may be right that it is something odd about the
configuration on the test machine, since I haven't been able to
reproduce it anywhere else. But Duncan did say he could reproduce it in
R-devel but not R-4.0.3, so there's that.
The error message is buried deep in this thread, but it was:
Check: whether package can be installed.
Result: WARN
Found the following significant warnings:
Warning: namespace ‘flexmix’ is not available and has been replaced
Check: data for non-ASCII characters
Result: WARN
Warning: namespace 'flexmix' is not available and has been replaced
by .GlobalEnv when processing object ''
Best,
Kevin
On 11/12/2020 10:13 AM, Martin Morgan wrote:
This seems more like a problem with the CRAN test machine, with the movMF
package installed with flexmix available but loaded with flexmix not available,
maybe interacting with a caching mechanism used by the methods package to avoid
re-computing methods tables? Otherwise how would movMF ever know to create the
flexmix class / method?
It seems like this could cause problems for the user if they installed movMV
with flexmix available, but removed flexmix. This seems like a subtler
variation of 'I installed package A but then removed dependency B and now A
doesn't work', which could be a bug in R's remove.packages() but
I tried to emulate the scenario of installing movMF and then removing flexmix
in an interactive session, and then looking for the warning reported below. I
was not successful, but the build report with the error is no longer available
so I don't know what I'm looking for...
Martin Morgan
On 11/11/20, 4:44 PM, "R-package-devel on behalf of Duncan Murdoch"
wrote:
Here's what I think is happening.
In the movMF:::.onLoad function there's a test whether flexmix is
installed. If found, then it is loaded and some methods are set. (I'm
not sure what caused flexmix to be installed: I didn't intentionally
install it, but it ended up in there when I installed enough stuff to
check Mercator.)
In the R-devel --as-cran checks, some checks are run with only strong
dependencies of your package visible. Somehow I think that .onLoad
function sees flexmix and loads it, but then some other part of the
check can't see it.
A workaround is to add flexmix to your Imports clause. This is a strong
enough dependency to make it visible, and the error goes away.
HOWEVER, to me this is pretty clearly an R-devel bug: you have no
control over methods set by packages that you don't even use, so you
shouldn't have to change your dependency lists if one of them sets a
method that you're using.
Duncan Murdoch
On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote:
> Oh, I forgot to mention explicitly that checking (with --as-cran) on the
> development version of R on Windows also produces no errors or warnings.
>
> On 11/11/2020 1:39 PM, Kevin R. Coombes wrote:
>> Hi Duncan,
>>
>> I just sent a longer version of this message, but it looks to me like
>> the underlying issue is the fact that flexmix and Mercator both define
>> and export "show" methods for their S4 classes. What confuses me is
>> why the NAMESPACE of a package that is merely Suggest'ed by something
>> several layers down the hierarchy should get attached and cause an
>> issue like this one. (The attached NAMESPACE happens in current
>> versions of R.)
>>
>> Thanks,
>>Kevin
>>
>> On 11/11/2020 1:07 PM, Duncan Murdoch wrote:
>>> Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the
>>> new one, 4.0.3 for the CRAN version.
>>>
>>> I'm not seeing any check error with the CRAN version. I get an error
>>> trying to check 0.11.4 from R-forge because I don't have flexmix
>>> installed. If I take flexmix out of the Suggests list, it checks
>>> with no error on 4.0.3, but I get the error you saw on R-devel when
>>> checked with --as-cran.
>>>
>>> I tried debugging this, and narrowed it down a bit. It happens when
>>> your package is installed, in particular in the do_install_source()
>>> function in src/library/tools/R/install.R. But that function runs a
>>> new R instance, and I didn't get to debugging that. I'll try again
>>> later today if nobody else figures it out.
>>>
>>> Duncan Murdoch
>>>
>>>
>>>
>>>
>&
[R-pkg-devel] Confusion about what should be in Imports for a package with a shiny app
I have a package (nprcgenekeepr) in which some packages listed in the DESCRIPTION file are used only within the shiny app scripts. For my prior CRAN submission (successful), I placed such packages in the Suggests section of the DESCRIPTION file. This time testing sites seemed to have directed me to place them in the Imports section and I now have multiple test environments (3 R-hub builder, 3 winbuilder, and 3 Travis-ci) that are showing no errors, warnings, or notes with that placement. However, the package check page https://cran.rstudio.com//web/checks/check_results_nprcgenekeepr.html site is showing the wrong package version (1.0.3 instead of 1.0.5) and some environments with a note of "Namespace in Imports field not imported from: ‘shinyBS’ All declared Imports should be used.” I changed the function call from `popify` to `shinyBS::popify` and get the same results I moved shinyBS to Suggests and I get the same note. I also have shinyWidgets used within the same UI script and listed in the Imports section and it does not generate a note. It appears that I have a basic misunderstanding of the message in the note and of where the `shinyBS` package should be listed within the DESCRIPTION file. Help will be appreciated. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Confusion about what should be in Imports for a package with a shiny app
Duncan, As always, your answer is helpful. What you wrote agrees with my original understanding. I was somehow mislead by my interpretation of earlier tesing output and got on the wrong track. You are correct that the intent of the package is to enable more skilled users to use the package interactively or in their own scripts and applications. I will modify the DESCRIPTION file accordingly. Mark R. Mark Sharp, Ph.D. Data Scientist and Biomedical Statistical Consultant 7526 Meadow Green St. San Antonio, TX 78251 mobile: 210-218-2868 rmsh...@me.com > On Mar 24, 2021, at 2:31 AM, Duncan Murdoch wrote: > > On 24/03/2021 12:16 a.m., R. Mark Sharp wrote: >> I have a package (nprcgenekeepr) in which some packages listed in the >> DESCRIPTION file are used only within the shiny app scripts. For my prior >> CRAN submission (successful), I placed such packages in the Suggests section >> of the DESCRIPTION file. This time testing sites seemed to have directed me >> to place them in the Imports section and I now have multiple test >> environments (3 R-hub builder, 3 winbuilder, and 3 Travis-ci) that are >> showing no errors, warnings, or notes with that placement. However, the >> package check page >> https://cran.rstudio.com//web/checks/check_results_nprcgenekeepr.html site >> is showing the wrong package version (1.0.3 instead of 1.0.5) and some >> environments with a note of "Namespace in Imports field not imported from: >> ‘shinyBS’ All declared Imports should be used.” >> I changed the function call from `popify` to `shinyBS::popify` and get the >> same results >> I moved shinyBS to Suggests and I get the same note. >> I also have shinyWidgets used within the same UI script and listed in the >> Imports section and it does not generate a note. >> It appears that I have a basic misunderstanding of the message in the note >> and of where the `shinyBS` package should be listed within the DESCRIPTION >> file. >> Help will be appreciated. > > The check code won't examine R code in your inst/application directory where > the Shiny app code is kept, so that's why you get the "All declared Imports > should be used" message. > > Your README says > > "The goal of nprcgenekeepr is to implement Genetic Tools for Colony > Management. It was initially conceived and developed as a Shiny web > application at the Oregon National Primate Research Center (ONPRC) to > facilitate some of the analyses they perform regularly. It has been enhanced > to have more capability as a Shiny application and to expose the functions so > they can be used either interactively or in R scripts." > > This indicates that you expect some users aren't going to use the Shiny > script, so they won't need shinyBS. That means it should be in Suggests, not > Imports, and your Shiny app should check whether it is available before > trying to run it. > > If you think *most* users will want the Shiny app, then you could force it to > be installed and loaded by putting it in Imports. Then you'll have to make > use of it somewhere in your main code to silence the message. But it's > probably better to leave it in Suggests. > > As to the "wrong package version" issue: CRAN isn't showing 1.0.5 anywhere. > You may have submitted it, but it hasn't been accepted. It's not in the CRAN > queues, so you'll need to submit again if you want it on CRAN. > > Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Case of package name
Hi, I currently have a package on CRAN called "plasma" (which is an acronym for an algorithm). Reviewers of the paper submitted to describe this package/algorithm have requested that the name be changed to PLASMA to make sure that users don't somehow think we are talking about the similarly named component of the blood instead. Is there any simple way (that won't burden or confuse the CRAN maintainers excessively) to make this change? Thanks, Kevin __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] test script output
Hi,h I have a package that has been in CRAN for years and is now failing checks because some of the output of a test script is differing on some machines in the fifth or sixth decimal place. I have managed to fix most of these issues (by using the "digits" argument in calls to "summary" to hide the differences). the only one that remains yields this R CMD check report: Comparing ‘testDiff.Rout’ to ‘testDiff.Rout.save’ ...52c52 < 2.600e-06 1.328e-01 4.666e-01 1.060e+00 1.369e+00 1.091e+01 --- > 0.03 0.132800 0.466600 1.06 1.369000 10.91 Here the digit-limited output is the same (to a human mathematician, though not to a string-matching computer), but one machine has decided to report the output in scientific notation. Both versions were produced by a command equivalent to print(summary(x, digits = 4)) What is the best cross-platform way to ensure that the output gets printed in the same format? Set "options(scipen=999)"? Pass some argument to "print" as well as to "summary"? (The other alternative I am considering is to just delete the script from the "tests" directory.) Thanks, Kevin [[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] test script output
Thanks for the quick (detailed) response.
On 1/31/2025 12:23 PM, Martin Maechler wrote:
Kevin R Coombes
on Fri, 31 Jan 2025 11:48:33 -0500 writes:
> Hi,
> I have a package that has been in CRAN for years and is now failing
> checks because some of the output of a test script is differing on some
> machines in the fifth or sixth decimal place. I have managed to fix most
> of these issues (by using the "digits" argument in calls to "summary" to
> hide the differences). the only one that remains yields this R CMD check
> report:
> Comparing ‘testDiff.Rout’ to ‘testDiff.Rout.save’ ...52c52
> < 2.600e-06 1.328e-01 4.666e-01 1.060e+00 1.369e+00 1.091e+01
> ---
> > 0.03 0.132800 0.466600 1.06 1.369000 10.91
> Here the digit-limited output is the same (to a human mathematician,
though not to a string-matching computer), but one machine has decided to report
the output in scientific notation.
I'm guessing you are slightly off here:
Almost surely it's *not* a difference in machine/platform but only in versions
of R-devel.
The original issues *were* platform dependent, where the fifth digit was
off-by-one on some platforms. You are correct that what is left is
because of your change in R-devel.
My guess comes from the fact that I've been the R core member
who committed this change to R-devel :
r87625 | maechler | 2025-01-24 16:58:25 +0100 (Fri, 24 Jan 2025)
parametrize & improve accuracy in print(summary())
a week ago.
... and BTW, if you look carefully, for the first entry, the new
output *is* slightly more accurate also in your example.
Certainly, it is more accurate. But less accurate (in the form of fewer
digits) was what I needed to solve the cross-platform issues in the
current release.
I agree that the switch from fixed point to
exponential/scientific format is "unlucky" in this case
[and even unnecessary: in this case, keeping fixed format and
showing one digit more (using the same amount of characters),
one could also have shown the 0.026 ...]
A workaround for you may be to set something like
options(scipen = 2) # default is 0
in your testDiff.R script before printing
All this is only in R-devel, the development version of R...
and I have contemplated to add more tweaks to
print.summaryDefault() for that upcoming version of R.
The fear stopping me to do more tweaking was that the
consequence could be even *more* (still small) changes in such
summary() printing output.
> Both versions were produced by a command equivalent to
> print(summary(x, digits = 4))
As you may (or may not ..;-) guess from the above commit message ("parametrize")
is that print(summary()) got a new argument zdigits.
Yes. But I can't use the new devel-version argument to fix the problem
in the current release...
So, instead of print(summary(x, digits = 4))
you can, from R version 4.5 (currently only in the development
version of R) on use
print(summary(x, digits = 4), digits = .., zdigits = ..)
but you could also --- already in current versions of R ---
tweak the output using
print(summary(x, digits = 4), digits = )
where you can play to see if n=3 , n=4, or n=5
help you getting better results ..
... actually *not* 'digits = 4' for summary() at all,
but only the digits argument to print(.) {where you'll get a
the new 'zdigits' argument *additionally* in R-devel and future
R version's}.
> What is the best cross-platform way to ensure that the output gets printed in the
same format? Set "options(scipen=999)"?
That's clearly too extreme to generally,
(I mentioned `scipen = 2` earlier).
Alternatively, pass some argument to "print" as well as to "summary"?
yes, see above.
(The other alternative I am considering is to just delete the script from the
"tests" directory.)
(I don't think that would be a good idea, .. but rather a very b.. one)
Ah, but it may have helped someone who knew what they were talking about
to answer more rapidly to avoid the bad solution. Thanks again.
I will try the options(scipen) fix for now, and keep the new zdigts
argument in mind going forward.
> Thanks,
> Kevin
Best,
Martin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] URLs in DESCRIPTION file
Hi, I am systematically going through the packages that I maintain on CRAN to clean up some administrative details. Specifically, I am (1) changing all DESCRIPTION files to use Authirs@R, (2) updating the links in man files to include package anchors, and (3) making sure that the output of calls to summary in test scripts don't break (i.e., mismatch the saved test output) in the 4.5.0 release candidate. Not surprisingly, this process also finds other issues. Right now,I am looking at the package BimodalIndex. The version currently on CRAN (v. 1.1.9) includes the following URL: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2730180/ On first checking the package, I get informed that this URL has "permanently moved" to: https://pmc.ncbi.nlm.nih.gov/articles/PMC2730180/ The fix seems simple, so I edited the DESCRIPTION file to use the new URL instead of the old one. Then I submitted the newly built version (1.1.11) to both the current release and the development release at winbuilder before submitting the update to CRAN. R version 4.4.3 comes back with a 00check.log that is absolutely "OK". No errors, warnings, or notes. But version R 4.5.0 RC comes back with; (possibly) invalid URL. Status: 403 Message: Forbidden I copied the URL as reported in the error message, pasted it into my browser, and it worked just fine. Can I assume that this is just something weird about the corresponding winbuilder server at the moment, and go ahead and submit the package? Or is there some mysterious change in R 4.5 lurking somewhere that I need to deal with? Thanks, Kevin __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] URLs in DESCRIPTION file
Thanks. That's what I thought (though I was somewhat confused by the
different behaviors of winbuilder on the current and development
versions). I think the original DESCRIPTION file (from 2017?) just had
the URL. Some time after that, CRAN asked for the inclusion of the DOI,
but they didn't say to get rid of the URL. The code itself hasn't been
touched since at least 2019 (since it still works exactly the way it is
supposed to.)
And, becauseI have been both finding and losing things on the Internet
for several decades, I am not particularly confident that the DOI is
going to have a significantly longer stable lifetime than the NCBI URL.
So, for now at least, I think I will leave them both.
Best,
Kevin
On 4/7/2025 11:35 AM, Ivan Krylov wrote:
В Mon, 7 Apr 2025 11:10:21 -0400
"Kevin R. Coombes" пишет:
But version R 4.5.0 RC comes back with;
(possibly) invalid URL. Status: 403 Message: Forbidden
I copied the URL as reported in the error message, pasted it into my
browser, and it worked just fine.
Can I assume that this is just something weird about the
corresponding winbuilder server at the moment, and go ahead and
submit the package?
This is a false positive. R CMD check sends automated requests to all
URLs it finds in the package. PubMed "protects" itself from automated
requests and returns an error code:
$ curl -I https://pmc.ncbi.nlm.nih.gov/articles/PMC2730180/
HTTP/2 403
content-length: 134
content-type: text/html; charset=UTF-8
date: Mon, 07 Apr 2025 15:14:59 GMT
alt-svc: clear
Using a browser instead results in subtly different behaviour visible
to the server, so the page loads successfully when clicking a link.
I see you're already linking to the article's DOI, 10.4137/cin.s2846,
and the article is not paywalled. Is it an option to remove the PubMed
link? There is code that is intended to recommend to only use the DOI,
but currently doesn't include a pattern for the new PubMed URLs:
if(length(y) &&
any(ind <-
(grepl(re_or(c("^https://pubmed.ncbi.nlm.nih.gov/[0-9]+";,
"^https://www.ncbi.nlm.nih.gov/pmc/articles/PMC[0-9]+/$";,
"^https://academic.oup.com/.*(/[0-9]*){4}$",
"^https://www.sciencedirect.com/science/article";)),
y$URL {
##
## Ideally we would complain about such URLs in general
## and not only when the URL checks were not OK.
paste(c("Please use DOIs for the following publisher URLs:",
paste0(" ", y$URL[ind])),
collapse = "\n")
##
}
If you don't want to remove the PubMed link, you can explain the
"possibly invalid URL" as a false positive in the submission comment.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How and where do I document sysdata.rda
If it is *only *in sysdata.Rda, then it is accessible to your package code but is not available to users. (They can't, for example, use the "data" function to load it themselves.) So, there is no reason to document it. Just like there is no reason to document functions in your R scripts that were not exported into user space. Of course, you can document those functions by using the keyword "internal" in an Rd file. I suspect that this would work to document your internal data set as well. On 3/20/2025 12:47 PM, Lists wrote: > Dear Jeff > > I am afraid that does not work if the data file is in sysdata.rda. I > had to remove my existing Rd file to get the package to pass checks. > > Michael > > On 20/03/2025 15:15, Jeff Newmiller wrote: >> Did you seriously look for instructions and not find [1]? And why do >> you think the answer should not involve Rd files? Documentation in R >> packages is what Rd files are for. >> >> If you don't want to mess with Rd files then you have no choice but >> to use something like the Roxygen package to mess with them for >> you... but that just kicks the can down the road .. Rd files are >> always involved. >> >> [1] >> https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Documenting-data-sets >> >> On March 20, 2025 7:39:39 AM PDT, Lists wrote: >>> I want to put a look-up table into sysdata.rda to avoid having to >>> compute it everytime. At the moment I create it and save the >>> resulting file and then manually copy it to sysdata.rda. This works >>> but the package now contains no documentation about the look-up table. >>> >>> Most of the information which I turned up online involves doing it >>> all indirectly using various packages. I do not want to do that, I >>> am quite happy editing files by hand and moving them to where I want >>> them by hand. So what I need is to know where I should put the >>> documentation and what format it should be assuming it is not an Rd >>> file. >>> >>> Of course what I want may be impossible and I just need to document >>> it in the script which creates it but that seems messy. >>> >>> Michael Dewey >>> >>> __ >>> 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 [[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] DESCRIPTION file question
Hi Dirk, Yes, that helps very much. Thank you. Right, my package calls out to inline::cxxfunction() to interface with one particular c++ library. inline is a much more ambitious project obviously, and I get how it can't require everything as a dependency. Regarding your first paragraph, okay I'm on board now. I think we're both looking at the same passage in Writing R Extensions, too. I had some grammatical confusion. When I read "Specifying a package in ‘LinkingTo’ suffices if these are C/C++ headers containing source code or static linking is done at installation" it sounds like it's referring to c/c++ headers being included at potentially other times besides installation. In other words, it sounds like "at installation" only applies to the second of those two conditions. However, if I continue on reading that same paragraph, I now think that "at installation" applies to both conditions. It even gives explicit instructions regarding what to do about vignettes requiring packages, which is my exact situation. I just removed everything from both LinkingTo and Imports, stuck them in Suggests, and now all the notes are silenced after checking on a variety of OSes. Thanks again. Best, Taylor On Sat, Jul 22, 2023 at 6:27 PM Dirk Eddelbuettel wrote: > > On 22 July 2023 at 16:07, Dirk Eddelbuettel wrote: > | > | Taylor, > | > | I believe we have been over this at StackOverflow but you may by now have > | deleted the question/ > | > | On 21 July 2023 at 20:51, taylor brown via R-package-devel wrote: > | | I have a question about the DESCRIPTION file of an R package that has > some c++ dependencies. > | | > | | This package of mine builds c++ code during an interactive R session, > but > | | does not contain any source c++ in itself. The c++ files make > reference to > | | some dependencies that are made available by other third party R > packages. > | | > | | LinkingTo is the appropriate field for the DESCRIPTION file (usually) > here, not Imports, but if If I remove the dependencies (BH and RcppEigen) > from the Imports field, the code examples in the vignette will fail to > build on a fresh machine. > | | > | | The NOTES in my build mention that, because I have no src/ directory, > LinkingTo is ignored. Simultaneously, there is another note that mentions > Imports is also excessive. > | > | As your package has no src/ directory and does no compilation itself, > you do > | not need / have no use for LinkingTo to provide the include/ directory > of one > | or more listed packages. > | > | (If you have offer that compilation ability in a helper function you > need to > | tell the deal with it in the function. You can use `requireNamespace()` > to > | check if a package is present, warn or error if not, and compute the > include/ > | directory location using R helper functions such as system.file().) > | > | | It’s kind of a catch 22. It feels like my options are either add the > Imports lines and ignore the NOTE, or add a superfluous src/ directory to > silence the NOTE. Which option is the preferred one? Or is there a third? > | > | I think all you need is in Writing R Extensions. For us to help you more > a > | concrete example, maybe even from a mock package, would help. > > PS An existing example is provided by the 'inline' package, originally by > Oleg Sklyar, extented by many, and maintained by me for some time. It lets > you work on code in C, C++, Fortran, ... and it compiles, links and loads > it > for you from an R session just you seem to desire. > > And 'inline' has no LinkingTo and only one Imports for 'methods' as it uses > some S4. > > Hth, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Taylor R. Brown, Ph.D. Assistant Professor of Statistics, General Faculty Department of Statistics University of Virginia [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Problems runing a example (shiny App) within a package
Problems running a example (shiny App) within a package
#main code
runclt = function(){
shiny::runApp(system.file("shinyCLT", package="CLT"))
}
#example
\examples{
runclt()
}
#Problem
R CMD check breaks in "checking examples ..." and don't complete the tests.
How to solve it
Link to source code https://1drv.ms/u/s!AqhYme4BRWAog3VVjYb7oJ4jopDN
[https://r1.res.office365.com/owa/prem/images/dc-generic_40.png]<https://1drv.ms/u/s!AqhYme4BRWAog3VVjYb7oJ4jopDN>
CLT_2.1.1.tar.gz<https://1drv.ms/u/s!AqhYme4BRWAog3VVjYb7oJ4jopDN>
Compartilhado via OneDrive
thanks in advance,
Kevin Allan S. R.
[[alternative HTML version deleted]]
______
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Coordination Needed: Update in ast2ast affecting paropt
Dear all, I have two packages on CRAN (ast2ast and paropt). Notably, paropt depends on ast2ast. Currently, I'm working on a major update of ast2ast which changes the API at specific points that are used by paropt. Thus, the update will break paropt. I am reaching out to seek your suggestions on how Ican smoothly navigate this transition with minimal disruption. Thanks a lot in advance. Best Konrad [[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] Update timing of machines on CRAN?
I do think that its a reasonable ask that the test machines be running operating systems within their vendor support periods. -Andrew Robbins From: R-package-devel on behalf of Josiah Parry Sent: Monday, December 4, 2023 11:34 AM To: Tomas Kalibera Cc: R Package Development Subject: Re: [R-pkg-devel] Update timing of machines on CRAN? Unfortunately, it is often important for us to pay attention to what machines our code is being tested on. I think the point is more or less that we often find ourselves trying to make super small adjustments for machines and builds that are used by a number of users in the single digits. The vast majority of R programmers are not on these arcane machines. We should strive to support the vast majority of users who use *fairly* standard distributions such as Mac, Windows, Ubuntu, Debian, and maybe even Centos. Getting a note for a release which has reach EOL can be confusing and tough to know how to handle. On Mon, Dec 4, 2023 at 10:17 AM Tomas Kalibera wrote: > > On 12/4/23 15:44, SHIMA Tatsuya wrote: > > Thanks for your answer. > > > > Unlike Windows Server, which has a long support period, Fedora's > > support period is usually about one year, so it is surprising that the > > old Fedora continues to be used. > > And, unlike Windows, Linux uses the distribution standard packages for > > builds, which causes problems like the current Fedora machine that > > continues to use the old Rust. > > The configuration currently at different CRAN machines is just a sample > of what your users might have, just an example of a setting packages > should be able to deal with. Some users might also still have FC36, some > might have another Linux distribution (possibly still supported), which > has older software than that. > > I wouldn't recommend spending time tracking which version of which > software CRAN systems currently happen to have, but rather making sure > packages can deal with different versions (possibly with some in a > restricted way, possibly making some hard requirements when necessary). > > Best > Tomas > > > > Hope to see an update soon. Thanks to the staff for maintaining the > > infrastructure. > > > > Best, > > Tatsuya > > > > On 2023/12/01 23:43, Uwe Ligges wrote: > >> > >> > >> On 01.12.2023 13:28, SHIMA Tatsuya wrote: > >>> Hi, > >>> > >>> I maintain the prqlr package that uses rustc for compiling, so I > >>> regularly check the version of Rust on CRAN. > >>> And I have noticed that the Rust version of Fedora has been stagnant > >>> for the past few months and was wondering why, but upon > >>> investigation I realized that this is because Fedora on CRAN is > >>> currently Fedora 36 (out of support in May). > >>> <https://cran.r-project.org/web/checks/check_flavors.html> > >>> > >>> It was quite a surprise to me that out of support Fedora is being > >>> used, but what is the normal cycle for machines on CRAN to be > >>> updated? And do we have any way of knowing that schedule? > >> > >> It depends on the maintainer who cares about these machine, the > >> institution where it is hosted, the availability of technical staff, > >> and the technical pressure. > >> > >> I could not even say when the machines I maintain will be updated. > >> On one version of the retired winbuilder severs we kept the same OS > >> version for almost 10 years. > >> > >> Best, > >> Uwe Ligges > >> > >> > >> > >> > >> > >>> > >>> Best, > >>> Tatsuya > >>> > >>> ______ > >>> 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 > [[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
[R-pkg-devel] Flex missing in win-builder
Is it possible to get flex in the win-builder windows environment? It's present in the debian environment. My package depends on cmake, bison, and flex. Each of these are listed in the `SystemRequirments` field of my DESCRIPTION file but flex is the only one that cmake can't find. The win-builder home page (https://win-builder.r-project.org/) doesn't say much about foreign dependencies other than we have what's available in Rtools plus a small list of others. But neither cmake or bison are available by default in Rtools, they both have to be explicitly installed with `pacman`. Flex can also be installed via `pacman`, so why are the other two available? I can't find much on how the `SystemRequirments` is used in "Writing R Extensions" either, is this used to tell CRAN what is needed to build the package? Or is it just a hint to end users? If the former how are they supposed to be named? Different package managers have different names for the same packages. Does it need to be named `libfl-dev`? (This Rstudio repo: https://github.com/rstudio/r-system-requirements, makes it look like it's just a hint for humans.) If not able to access flex, I think I can generate the files locally and commit those but I'm pretty sure that will require doing what `rigraph` had to do and get `Make` compile all the external code that is currently handled by various `CMakeLists.txt` which is probably doable but looks like a lot work and requires manually regenerating and commiting flex files whenever updating external dependencies. Any better alternatives? [[alternative HTML version deleted]] __________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Properly referencing copied code
I'm trying to submit a package to CRAN that uses external C libs but properly
crediting copyright holders and authors is the main issue holding up the
submission and I've repeatedly failed to satisfy the requirements. I am having
a lot of trouble understanding what/who I need to be listing in my DESCRIPTION
file and how they should be listed.
1. How does linking to external libs differ from providing the source of a
library and linking against that? Do I need to provide references to lapack and
blas if they aren't shipped with the package? What about math (lm)?
2. What roles to supply to authors of external software? After my last
submission, I got the note:
> Has copyright holders of included software in a [ctb] role only
>From the CRAN Repository Policy file:
>Where code is copied (or derived) from the work of others (including from R
>itself), care must be taken that any copyright/license statements are
>preserved and authorship is not misrepresented.
>Preferably, an ‘Authors@R’ field would be used with ‘ctb’ roles for the
>authors of such code. Alternatively, the ‘Author’ field should list these
>authors as contributors.
>
>Where copyrights are held by an entity other than the package authors, this
>should preferably be indicated via ‘cph’ roles in the ‘Authors@R’ field, or
>using a ‘Copyright’ field (if necessary referring to an inst/COPYRIGHTS file).
My interpretation of the CRAN policy is that the role 'cph' should be used only
for "entities other than the package authors" and therefore authors should only
get 'ctb'. Do I need to differentiate between authors with explicit copyrights
`c('ctb', 'cph')` vs those who are authors but are not listed as copyright
holders `c('ctb')` in the third party source? Or just give everyone both?
3. One of my dependencies has a lot of copyright holders throughout the source.
Most of these are for individual functions and cmake files that are not
directly used by my package. What is the best way to handle this? Add as much
of the unused parts of the third party package to the .Rbuildignore file as
possible to filter out the unused parts? (Many copyrights are from parts of the
package that are independent on the parts I used so for example ignore an
unused vendor package seems reasonable but what about hand picking the main
source files that are actually compiled to avoid copyrights?) Or list all of
the authors/copyrights in the my DESCRIPTION file?
4. Is there a better place to put all these authors? The author list has
already gotten large and I still have many more to add. I've seen use of an
`AUTHOR-list.md` in packages but I don't see this mentioned in official
documentation. In the previous quotation from CRAN's policy document, it
mentions the possible use of a `inst/COPYRIGHTS` file that is referenced in the
DESCRIPTION. Is there an equivalent for authors? Is it preferred to just put
everything in DESCRIPTION instead?
- DRC
[[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] Properly referencing copied code
Thanks that helps. Are there any thoughts on the feedback I was given? I'm
still a bit confused on the note:
> Has copyright holders of included software in a [ctb] role only
I think I'm being asked to add the cph role to essentially every author in
addition to ctp but that doesn't seem to be what the CRAN policy wants and I
still don't know how to decide who gets both. Right now there are several
people who have explicit copyright over certain code so I would think just add
cph to all those authors? Or just give everyone cph who isn't a minor
contributor?
- DRC
On Friday, July 12th, 2024 at 3:07 AM, Ivan Krylov 'ikrylov at disroot.org'
wrote:
>
> В Thu, 11 Jul 2024 20:58:53 +0000
> DRC via R-package-devel r-package-devel@r-project.org пишет:
>
> > 1. How does linking to external libs differ from providing the source
> > of a library and linking against that?
>
>
> I think that the author information in the DESCRIPTION is about what
> your package provides by itself, not everything that may end up in the
> address space once the package is loaded. Since CRAN prefers
> self-contained packages, we end up including them in our packages
> (unless the third-party library is already very common and present in
> RTools & macOS recipes & common GNU/Linux distros), which requires us
> to specify their authors.
>
> > Do I need to provide references to lapack and blas if they aren't
> > shipped with the package? What about math (lm)?
>
>
> No.
>
> > 2. What roles to supply to authors of external software?
>
> > Do I need to differentiate between authors with explicit copyrights
> > `c('ctb', 'cph')` vs those who are authors but are not listed as
> > copyright holders `c('ctb')` in the third party source? Or just give
> > everyone both?
>
>
> I would expect most authors and contributors to be copyright holders
> too, but it must be possible to contribute without providing patches
> and becoming one. E.g. a project might recognise a tester and bug
> reporter as a full author, but there is no code that they own any
> copyright on.
>
> > 3. One of my dependencies has a lot of copyright holders throughout
> > the source. Most of these are for individual functions and cmake
> > files that are not directly used by my package. What is the best way
> > to handle this? Add as much of the unused parts of the third party
> > package to the .Rbuildignore file as possible to filter out the
> > unused parts?
>
>
> If it's feasible to implement, omitting unused files from the tarball
> is a good idea.
>
> > 4. Is there a better place to put all these authors? The author list
> > has already gotten large and I still have many more to add.
>
>
> CRAN recognises inst/AUTHORS. Here's a recently released package with
> no obvious problems that makes use of it:
> https://CRAN.R-project.org/package=xlcharts
>
> We should probably document it somewhere.
>
> --
> Best regards,
> Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Properly referencing copied code
Thank you everyone, I think this gives me everything I need to know and I have no problem spreading the copyright around. I'm not sure adding my dependencies to MXE is going to make sense here but open to being convinced otherwise. The package I am working on is wrapping functions from my own simple external C library. I wrote the C lib outside of the R package specifically so it would be possible to integrate the algorithm into multiple high level interfaces (i.e. python, matlab, in addition to R) otherwise the C would have been directly written into the R package. I don't see my lib as something anybody else is likely going to need to link against. This C lib does depend on igraph though, which is more likely to be useful. However, I don't think it's actually going to be straight forward to add to MXE given how much effort I have had to put into getting it to compile with R and I honestly would rather not be the one who needs to figure out how to do it right. I hope that is understandable given it's pretty clear I am out of my skill set as a biologist and that I am in the last few months of my PhD program and have already exceeded the time I can afford on this side project. There's a few problems that I think will make igraph difficult to package with MXE based on the challenges I have had with compiling on CRAN's build servers, assuming the environments are similar. 1. It was not possible for me to get igraph to compile correctly using cmake on CRAN builders due to other missing dependencies (including flex which I was previously told I have to pre-generate the resulting C files rather than depend on flex being available which prevents me from using cmake that calls flex itself). This means having to write new build logic instead of depending on the upstream cmake recipe, which is fragile and could break with an update. 2. There are some configuration options which are beneficial to choose based on the current project. Of particularly interest is that the igraph C lib has had to add a `USING_R` macro to modify the behavior in the lib based on whether it is used inside of `R` or not. Since MXE is not specific to R this requires a different build depending on where it's being used. 3. igraph is currently in the process of releasing 1.0.0 and the maintainers have noted there will be breaking changes. Given that it is not yet as mature as other commonly used dependencies, it is safer to use the pinned version shipped with my C lib than depending on a system wide installation. Even if there is a range of versions I can check for, I would think there would still be a need to ship an appropriate version of igraph with the R package (and therefore still have all the logic needed to build it) in cases where the system's available igraph version is not appropriate, igraph is not compiled in a thread safe manner, or igraph is not compiled for R (which it definitely wouldn't be anywhere not using MXE, i.e. on a Linux computer where `install.packages` will compile the package locally). As such I don't think it makes much sense to try to add it to MXE, especially before determining if there is demand for the lib in CRAN packages. - DRC On Monday, July 15th, 2024 at 4:11 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: > В Fri, 12 Jul 2024 20:17:22 + > DRC via R-package-devel r-package-devel@r-project.org пишет: > > > > Has copyright holders of included software in a [ctb] role only > > > > I think I'm being asked to add the cph role to essentially every > > author in addition to [ctb] > > > That's how I'm reading it too. > > > but that doesn't seem to be what the CRAN policy wants > > > I agree that there does seem to be a conflict, with the policy only > asking to use 'cph' for non-'aut' or 'ctb' copyright holders. > > > and I still don't know how to decide who gets both. > > > Technically, the conflict can be resolved by noting that the CRAN > policy doesn't prohibit using 'cph' for 'aut' or 'ctb' co-authors. > Since both your reviewer and help(person) ask for 'cph' for all > copyright holders, it sounds like all co-authors who wrote any code > should get an additional 'cph'. > > It would help if CRAN Policy also said that 'cph' should be used for > all copyright holders. > > > Right now there are several people who have explicit copyright over > > certain code so I would think just add cph to all those authors? Or > > just give everyone cph who isn't a minor contributor? > > > It shouldn't be too wrong to say that if someone wrote a nontrivial line > of code you're including in your package, they are a copyright holder. > >
[R-pkg-devel] Build process generated non-portable files
I'm working on a package that uses some fortran copied from elsewhere. It compiles and build fine everywhere but exclusively in the intel environment (provided by rhub), the intel fortran compiler generates intermediary files from *.f -> *__genmod.f90. The R check then complains that the genmod files are not portable. I include removal of the files in my cleanup file so the files do not exist in the original package source or in the final source tarball but it seems the portable files check is done after compilation but before cleanup. - Is there a way to get around this complaint? - Should this complaint be here in the first place? I'm not familar with fortran but the warning message is: "Found the following files with non-portbale usage of KIND:." In "Writing R Extensions/Writing portable packages/Portable Fortran code" it mentions the use of REAL(KIND=8) types are not portable since compilers can map values to different types (and these declarations are in the f90 files), but the compiler called the preprocessing of the files so it should be correct for this specific compiler. The docs also mention the intel compiler will perform this preprocessing so this seems to be expected behavior. Shouldn't the portable files check only be performed on the shipped source code? In general, isn't it reasonable that build processes generate files specific to the environment? - David R. Connell [[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] Build process generated non-portable files
This seems like it should work. Unfortunately my rhub github actions is failing to get past the setup deps step which has been occuring inconsistently in the past but right now it's consistently failing to build deps so I can't confirm it work. I was also unable to successfully build R using intel compilers, even when using Rhubs container as template. > Include the first 'all' target in your Makevars I was really trying to avoid explicitly creating a target in makevars but this is simple enough. In case anyone else comes across this, the genmod files end up in `src` even if the original source files are under a subdirectory so the recipe ends up being: > -rm -f *genmod.f90 > If you manage to find an option for the ifx compiler that disables creation > of these files I installed intel compilers and checked the `ifx` man page. Could not find an option for turning off generation of the genmod files. > a brief Web search says they are for only the user to read, but most results > are from early 2010's Yeah I checked one of the files again and it does say that it's generated only for reference. - David R. Connell On Tuesday, August 13th, 2024 at 3:08 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: > В Mon, 12 Aug 2024 18:24:30 + > David via R-package-devel r-package-devel@r-project.org пишет: > > > in the intel environment (provided by rhub), the intel fortran > > compiler generates intermediary files from *.f -> *__genmod.f90. The > > R check then complains that the genmod files are not portable. I > > include removal of the files in my cleanup file so the files do not > > exist in the original package source or in the final source tarball > > but it seems the portable files check is done after compilation but > > before cleanup. > > > > - Is there a way to get around this complaint? > > > Include the first 'all' target in your Makevars, make it depend on the > package shared library, and make it remove genmod files in the recipe: > > all: $(SHLIB) > -rm -f arpack/*genmod.f90 > > A similar trick is mentioned in > https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Using-Makevars. > > > - Should this complaint be here in the first place? > > > Perhaps not. If you manage to find an option for the ifx compiler that > disables creation of these files (a brief Web search says they are for > only the user to read, but most results are from early 2010's), post it > here. This may be a good argument to make this option recommended for R. > > > Shouldn't the portable files check only be performed on the shipped > > source code? > > > False negatives are possible too, in case the installation stage > (configure and/or make) performs a lot of preprocessing, or unpacks > extra sources. You could be right; I don't have statistics to back > either option as less wasteful of effort. > > -- > Best regards, > Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Build process generated non-portable files
I locally ran the rhub intel docker and that was much easier to set up. So I can now confirm the change to Makevars does work. > I experimented with the "ghcr.io/r-hub/containers/intel:latest" container and > was able to find out that the option -[no]gen-interfaces controls the > generation of __genmod files: You are right. I temporarily removed the changes to Makevar and added the `-nogen-interfaces` flag to FFLAGS and that also prevented the warning. I can open an issue at rhub and suggest adding that as a default for the intel compilers. > This may be worth reporting to the rhub developers. The error is really > strange. It looks like the package at > https://github.com/cran/igraph/releases/download/2.0.3/igraph_2.0.3_b1_R4.5_x86_64-pc-linux-gnu-fedora-38.tar.gz The strange thing is the intel container on github actions has succeeded in the past but now is consistently failing to build `targets`: > ✖ Failed to build targets 1.7.1 (2.1s) > Error: > ! error in pak subprocess > Caused by error in `stop_task_build(state, worker)`: > ! Failed to build source package targets. > Full installation output: > * installing *source* package ‘targets’ ... > ** package ‘targets’ successfully unpacked and MD5 sums checked > staged installation is only possible with locking > ** using non-staged installation > ** R > ** inst > ** byte-compile and prepare package for lazy loading > Error in dyn.load(file, DLLpath = DLLpath, ...) : > unable to load shared object > '/github/home/R/x86_64-pc-linux-gnu-library/4.5/igraph/libs/igraph.so': > libopenblasp.so.0: cannot open shared object file: No such file or directory > Calls: ... asNamespace -> loadNamespace -> library.dynam -> > dyn.load > Execution halted > ERROR: lazy loading failed for package ‘targets’ > * removing ‘/tmp/RtmpLpWRX0/pkg-lib3c3299c227c/targets’ Which is related to the igraph issue you mentioned. Checking the packages installed in a previous successful intel action, targets was not listed. I don't know why it's being installed now but not previously, I haven't changed dependencies. In the past other packages have failed to build and not only on the intel container see "https://github.com/SpeakEasy-2/speakeasyR/actions/runs/10202337528/job/28226219457"; where several containers failed at the setup-deps step. There is overlap in which package fails (i.e. protGenerics and sparseArray fail in multiple containers but succeed in others while in one container ExperimentHub fails). It seems the only packages failing are from Bioconductor. Assume this is a bioconductor or pak issue. The issue with igraph is interesting though since I do use the igraph package for some examples and inside the intel container, R CMD build has no problem running igraph. Inspecting the resulting tarball shows the html version of my vignette contains results that depends on running igraph code and my test using igraph succeeds with R CMD check. Yet when I run R inside the container and try to load the igraph library or run code via `igraph::` I get an error > > igraph::sample_pref(10) > Error in dyn.load(file, DLLpath = DLLpath, ...) : > unable to load shared object > '/root/R/x86_64-pc-linux-gnu-library/4.5/igraph/libs/igraph.so': > libopenblasp.so.0: cannot open shared object file: No such file or directory I.e. the same error with building targets. I can raise an issue on rigraph as well. - David R. Connell On Friday, August 16th, 2024 at 7:58 AM, Ivan Krylov 'ikrylov at disroot.org' wrote: > В Thu, 15 Aug 2024 18:58:41 + > anj5x...@nilly.addy.io пишет: > > > This seems like it should work. Unfortunately my rhub github actions > > is failing to get past the setup deps step which has been occuring > > inconsistently in the past but right now it's consistently failing to > > build deps so I can't confirm it work. > > > This may be worth reporting to the rhub developers. The error is really > strange. It looks like the package at > https://github.com/cran/igraph/releases/download/2.0.3/igraph_2.0.3_b1_R4.5_x86_64-pc-linux-gnu-fedora-38.tar.gz > (referenced from https://github.com/r-hub/repos) has a binary > dependency on OpenBLAS: > > $ readelf -d igraph/libs/igraph.so | grep openblas > 0x0001 (NEEDED) Shared library: [libopenblasp.so.0] > > ...but that's either not noted or not installed correctly. > > > I was also unable to successfully build R using intel compilers, even > > when using Rhubs container as template. > > > If you'd like to dig deeper, feel free to ask here with details. > > > In case anyone else comes across this, the genmod files end up in > > `src` even if the original source files are under
Re: [R-pkg-devel] gcc-asan replication for armadillo
If this were the case I don't think that I'd be having problems replicating it. From: Serguei Sokol Sent: Wednesday, May 21, 2025 9:21 AM To: and...@robbinsa.me ; R Package Development Subject: Re: [R-pkg-devel] gcc-asan replication for armadillo Le 21/05/2025 à 14:48, andrew--- via R-package-devel a écrit : > Hi all, > > I'm currently having difficulty replicating an ODR violation that is being > raised by the gcc-asan check here: > https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-ASAN/RcppPlanc/00install.out. > Perhaps weirder, it seems to be triggered by an inclusion of > armadillo_bits/constants.hpp in both my shared object and the Rcpp binding > library-which seems like something that shouldn't be raising any issues. Seemingly, yes. ODR stands for _One_ Definition Rule so if you define the same thing in two different libs then raising issue sounds legitimate. I suppose one possible solution could be incorporating the content of libnmflib.so (and all other libs your build) directly in RcppPlanc.so and cleaning them afterward. Hoping it helps, Serguei. > > Dirk, you wouldn't happen to have seen this before? > > -Andrew Robbins > ______ > 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-pkg-devel] gcc-asan replication for armadillo
Hi all, I'm currently having difficulty replicating an ODR violation that is being raised by the gcc-asan check here: https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-ASAN/RcppPlanc/00install.out. Perhaps weirder, it seems to be triggered by an inclusion of armadillo_bits/constants.hpp in both my shared object and the Rcpp binding library-which seems like something that shouldn't be raising any issues. Dirk, you wouldn't happen to have seen this before? -Andrew Robbins __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] A package that traces base functions
--- Begin Message --- Apologies, this is a cross post from 'R-devel', where I sent this message a few months ago when I did not realize there was an 'r-package-devel' list. So here it is again in the correct list: I'm working on a package that implements a REPL. A typical interaction with the package might look like: > launch_REPL()REPL> 1 + 1[1] 2REPL> QDo you wish to save results? [y/n]REPL> > ygoodbye ...> This is very similar to what happens when in `browser()`: the REPL evaluates arbitrary R user expressions and offers some additional commands. In order to implement functionality required for the REPL I must trace some functions in the base package. The trace is removed `on.exit()` from the REPL, so the functions are only modified while the `launch_REPL` function is evaluating. Unfortunately this is against the letter of the law (as per CRAN policy): > A package must not tamper with the code already loaded into R: anyattempt to > change code in the standard and recommended packages whichship with R is > prohibited. Is there any chance that this very limited (only during my function evaluation) modification of base functions with `trace` could be considered to meet the spirit of the law, if not the letter? Package users would be duly notified this is happening. Alternatively, if this is not allowed, would it be acceptable to ship the functionality turned off by default with a user option to enable it (documented with warnings about how this is non-standard behavior, etc.)? Regards, Brodie Gaslam. PS: More details for those who care: the REPL among other things implements an environment that has for parent `as.environment(2)` so that objects in the global environment are not visible while in the REPL, but otherwise the full search path is. Anytime the search path changes I need to update the REPL environment to re-point to `as.environment(2)`, which means I need to know when the search path changes. I do this by tracing `library`/`attach`/`detach` and triggering a side effect that updates the REPL environment parent any time those are called. The search path itself is untouched. I cannot just parse user expressions searching for those functions as the user can use any arbitrary expressions, including sourcing files that contain the `library`, etc. calls. [[alternative HTML version deleted]] --- End Message --- ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN check FAIL due to pragmas in headers and code
--- Begin Message --- I too am seeing the same failure in my package. It does not contain any #pragma directives, and it doesn't have any dependencies to other compiled packages. Poking around through the CRAN checks I've found other packages with C compiled code displaying the same error on the clang and gcc 64 bit debian checks: * diffobj: (my package) https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/diffobj-00check.html* xts: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/xts-00check.html* backports: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/backports-00check.html I'm pretty sure (but not certain) that my package did not throw these errors as of quite recently (I uploaded to CRAN over the weekend). This leads me to think that it is (maybe) possible that this is an issue with the latest version of the check tool? Best, Brodie. [[alternative HTML version deleted]] --- End Message --- __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problems with too much testing
An all.equal method? This might not work with 3rd edition though (untested), and I'm not sure what method registration requirements would exist for the user. Best, B. On Friday, April 16, 2021, 6:09:24 AM EDT, Duncan Murdoch wrote: I'm updating the rgl package, and have come across the following problem. Some packages that depend on rgl and do careful testing are detecting inconsequential changes. A typical case is the nat package, which has extensive testing, some of which comes down to checking results from rgl functions using testthat::is_equal(). I rewrote some parts of the rgl code, and so some rgl objects differ in irrelevant ways. For example, obj <- list(x = NULL) differs from obj <- list() obj[["x"]] <- NULL (the first is length 1, the second ends up with no entries). All tests in rgl would be like if (is.null(obj[["x"]])) ... so the tests evaluate the same, but testthat::is_equal() doesn't return TRUE, because the objects are different. Another example would be obj <- list() obj$a <- 1 obj$b <- 2 which differs from obj <- list() obj$b <- 2 obj$a <- 1 in the order of the components, but since rgl always accessed them by name, that makes no difference. So what I'm looking for is a strategy to hide internal implementation details. (I'm using a compare_proxy() method now which standardizes the objects, but that seems very specific to testthat version 3. I'd like ideas for something more robust.) Duncan Murdoch __ 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] Unable to get past CRAN submission checks for package cubature
At the risk of only being mildly (if at all) helpful, I was able
to reproduce your warnings on Rhub, which has the same compiler,
with:
rhub::check('cubature_2.0.4.1.tar.gz', platform='windows-x86_64-release')
Absent feedback from CRAN you could try tweaking your code so that
it does not produce those warnings while no changing behavior.
Obviously, iterating with rhub is not the easiest way to do this,
but might be easier than trying to get GCC 8.3.
For reference, you might be hitting:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
Maybe you knew that already but it might be useful for others to be
aware there is an actual bug that at least is in the general area
that affects GCC 8.2-8.3.
Best,
B.
On Monday, May 10, 2021, 4:01:36 PM EDT, Balasubramanian Narasimhan
wrote:
I submitted a minor update of cubature (suggesting rmarkdown for
vignettes) and received a message that the package generated warnings.
However, the warnings were noted to be untrustworthy (see email below).
I noted this in the submission comments as well as the reply to the
auto-check email.
It appears that I am unable to get beyond the auto-check service. Any
suggestions?
-Naras
Forwarded Message
Subject: Re: [CRAN-pretest-archived] CRAN submission cubature 2.0.4.2
Date: Thu, 6 May 2021 12:51:37 -0700
From: Balasubramanian Narasimhan
To: cran-submissi...@r-project.org, na...@stat.stanford.edu
Dear CRAN,
As explained in my submission comment, the warning is noted to be flaky
in the message below.
Thank you.
-Naras
On 18/03/2021 13:05, Kurt Hornik wrote:
>>>>>> Uwe Ligges writes:
>
>> Dear Naras,
>> your package cubature shows compiler warnings under Windows:
>> <https://cran.r-project.org/web/checks/check_results_cubature.html>
>
>> Any chance getting rid of these? Please try and resubmit.
>
> Interestingly, r-release-macos shows this too ...
I think -Warray-bounds is known to be flaky in earlier compilers. I do
not see this on macOS with Apple Clang 11.5 (latest for High Sierra) or
12.4 (current) and nor does Tomas for GCC 10 on Windows.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
On 5/6/21 12:27 PM, lig...@statistik.tu-dortmund.de wrote:
> Dear maintainer,
>
> package cubature_2.0.4.2.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> Windows:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Windows/00check.log>
> Status: 1 WARNING
> Debian:<https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/Debian/00check.log>
> Status: OK
>
> Last released version's CRAN status: WARN: 3, NOTE: 10
> See:<https://CRAN.R-project.org/web/checks/check_results_cubature.html>
>
> CRAN Web:<https://cran.r-project.org/package=cubature>
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the
> R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please reply-all
> to this message and explain.
>
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/cubature_2.0.4.2_20210506_211603/>
> The files will be removed after roughly 7 days.
>
> *** Strong rev. depends ***: ALTopt apTreeshape bivquant BNSP calibrator
> clusteredinterference coga cold dbmss DRAYL dvmisc ei equivalenceTest
> fMultivar GAS GB2 GPCMlasso GRCdata highfrequency hyper2 ICAOD inctools
> MCMCglmm MIRES MMDCopula MWright NonNorMvtDist np OBASpatial ODS optimStrat
> PCMRS planar pooling Power2Stage PowerTOST ProFit QGglmm robustlmm skedastic
> SphericalCubature spNetwork statsr SurvDisc symmoments TCIU tseriesEntropy
> UPCM vines WLinfer yuima
>
> Best regards,
> CRAN teams' auto-check service
>
> Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
> Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers
> Maintainer: 'Balasubramanian Narasimhan'
>
> Flavor: r-devel-windows-ix86+x86_64
> Check: whether package can be installed, Result: WARNING
> Found the following significant warnings:
> ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between
>offset 0 and size [4294967292, 2147483647] [-Warray-bounds]
> ./src/common/Random.c:105:5: warning: 'memcpy' pointer overflow between
>offset 0 and size [-4, 9223372036854775807] [-Warray-bounds]
> See 'd:/RCompile/CRANincoming/R-devel/cubature.Rcheck/00install.out' for
[R-pkg-devel] OpenMP on MacOS
Dear all, I have a problem regarding OpenMP on Mac OS. Recently I submitted my package to CRAN (https://cran.r-project.org/web/packages/paropt/index.html). However, there seems to be a problem with 'fopenmp' on Mac OS using clang++. I have read many forums regarding the topic. Thus, I know that there is no support for OpenMp on Mac OS (at least using the default clang compiler). The error was: clang: error: unsupported option '-fopenmp' Is it possible to detect the operating system and set according to this the compile flags and use also a sequentiell version of the code? Or is there a better way to cope with this problem? Many thanks in advance for your help. Regards, Konrad [[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] package test returns error when R version 4.1.0
> On Tuesday, July 6, 2021, 8:09:18 AM EDT, dbosa...@gmail.com > wrote: > > Martin: > > What I suggested was he remove the LazyData entry from the description file > if he was NOT lazy loading data. If someone is lazy loading data, then that > is a different situation, and they obviously need to set the entry. > > But clearly Gm has a different problem. He has now tried "LazyData: true", > "LazyData: false", and removing the LazyData entry entirely. And he is > still getting this error: > > * installing *source* package 'movecost' ... > ** using staged installation > ** R > ** data > ** byte-compile and prepare package for lazy loading > ERROR: lazy loading failed for package 'movecost' > * removing 'd:/RCompile/CRANguest/R-release/lib/movecost' FWIW I think this is lazy loading of the code, which I think is different to what LazyData controls. This is described in R-Internals: https://cran.r-project.org/doc/manuals/R-ints.html#Lazy-loading I know nothing about it so I will not comment further. Best, B. ______ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Scrapping R CRAN website from package
Could pkgsearch http://r-hub.github.io/pkgsearch/ help with what you're doing, as it can queries all versions of CRAN packages? See http://r-hub.github.io/pkgsearch/reference/cran_package_history.html for the docs of the function cran_package_history(). It does not scrape CRAN pages, it uses an R-hub API (that gets the data from CRAN so similar to your idea of building a separate DB :-) ). Maëlle. Den lördag 17 juli 2021 02:21:55 CEST, skrev: Maciej: There are other packages that query the CRAN site (cranlogs, etc.). So it seems the queries/fetches are generally allowed. I can only find a couple relevant mentions in the CRAN policies: "Packages which use Internet resources should fail gracefully with an informative message if the resource is not available or has changed (and not give a check warning nor error)." "Downloads of additional software or data as part of package installation or startup should only use secure download mechanisms (e.g., 'https' or 'ftps'). For downloads of more than a few MB, ensure that a sufficiently large timeout is set." So it seems like what you are trying to do would be OK with the appropriate cautions in place. Obviously any test cases are going to have to run fast, or it will get rejected for being too slow to check. Just my reading of the policies. Have never tried it. David -Original Message- From: R-package-devel On Behalf Of Maciej Nasinski Sent: Friday, July 16, 2021 6:14 AM To: r-package-devel@r-project.org Subject: [R-pkg-devel] Scrapping R CRAN website from package Dear Sir or Madam, I am creating a new package `pacs` https://github.com/Polkas/pacs, which I want to send to R CRAN shortly. However I am not sure about R CRAN policy regarding scraping CRAN per package page with its archive. More precisely I am fetching the data from https://CRAN.R-project.org/package=%s and https://cran.r-project.org/src/contrib/Archive/%s/ (downloading an old tar.gz too). Why I need this: I could read any DESCRIPTION files for any time point and get a true dependency tree. Moreover I could get a life duration of any released package version, where shorter than 7 days are marked as risky. I could compare a package min required dependencies difference before we update it. And much more. I made a few notices like "Please as a courtesy to the R CRAN, don't overload their server by constantly using this function." inside the package. Optionally If scrapping R CRAN from my package is a problem I will try to build a separate DB with such data (updated everyday). Still any old tar.gz has to be downloaded. Maciej Nasinski, University of Warsaw [[alternative HTML version deleted]] ______ 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
[R-pkg-devel] FW: [EXTERNAL] [CRAN-pretest-archived] CRAN submission surfaltr 1.0.0.9000
Hi all,
PFA the pre-check results for my package surfaltr from CRAN. I am having
troubles with a package dependency on Debian that I am not able to fix. 2
functions in my package require a Bioconductor package msa
(https://bioconductor.org/packages/release/bioc/html/msa.html). To deal with
this error, I tried the following solution of adding a call to BiocManager and
also including a code for msa installation but it did not help:
#' @importFrom BiocManager install
#' @import msa
.
.
.
Foo() {
if (!requireNamespace("msa", quietly = TRUE)){
BiocManager::install("msa")}
}
How do I solve the problem so that I don't generate this error with Debian?
Thank you,
Pooja
Pooja Gangras, Ph.D.
Postdoctoral Research Scientist - RNA Therapeutics
Eli Lilly and Company
Lilly Corporate Center, Indianapolis IN 46285 U.S.A.
Office phone number: (317) 651-0589
Cellphone number: (614) 906-0940
gangras_po...@lilly.com | www.lilly.com
CONFIDENTIALITY NOTICE: This email message (including all attachments) is for
the sole use of the intended recipient(s) and may contain confidential
information. Any unauthorized review, use, disclosure, copying or distribution
is strictly prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original message.
-Original Message-
From: lig...@statistik.tu-dortmund.de
Sent: Monday, August 16, 2021 10:32 AM
To: Pooja Gangras
Cc: cran-submissi...@r-project.org
Subject: [EXTERNAL] [CRAN-pretest-archived] CRAN submission surfaltr 1.0.0.9000
EXTERNAL EMAIL: Use caution before replying, clicking links, and opening
attachments.
Dear maintainer,
package surfaltr_1.0.0.9000.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows:
<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/Windows/00check.log>
Status: 1 NOTE
Debian:
<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/Debian/00check.log>
Status: 1 ERROR, 1 NOTE
Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the
R-package-devel mailing list:
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
If you are fairly certain the rejection is a false positive, please reply-all
to this message and explain.
More details are given in the directory:
<https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.9000_20210816_162209/>
The files will be removed after roughly 7 days.
No strong reverse dependencies to be checked.
Best regards,
CRAN teams' auto-check service
Flavor: r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
Maintainer: 'Pooja Gangras '
New submission
Version contains large components (1.0.0.9000)
Possibly misspelled words in DESCRIPTION:
APPRIS (25:78)
Isoform (3:44)
Phobius (22:29, 26:81)
SurfaltR (24:68)
TMHMM (22:19, 26:72)
Topologies (3:61)
bioinformatic (22:71)
customizable (27:19)
druggable (17:65)
isoform (28:42)
isoforms (19:41, 23:48, 25:12)
oligonucleotide (18:51)
proteome (17:75)
subcellular (19:85)
surfaltR (4:17, 27:59)
surfaltrbib (29:143)
topologies (24:3, 26:55)
transmembrane (20:29)
Flavor: r-devel-linux-x86_64-debian-gcc
Check: CRAN incoming feasibility, Result: NOTE
Maintainer: 'Pooja Gangras '
New submission
Version contains large components (1.0.0.9000)
Possibly misspelled words in DESCRIPTION:
APPRIS (25:78)
Isoform (3:44)
Phobius (22:29, 26:81)
SurfaltR (24:68)
TMHMM (22:19, 26:72)
Topologies (3:61)
bioinformatic (22:71)
customizable (27:19)
druggable (17:65)
isoform (28:42)
isoforms (19:41, 23:48, 25:12)
proteome (17:75)
subcellular (19:85)
surfaltR (4:17, 27:59)
surfaltrbib (29:143)
topologies (24:3, 26:55)
transmembrane (20:29)
Flavor: r-devel-linux-x86_64-debian-gcc
Check: package dependencies, Result: ERROR
Package required but not available: 'msa'
See section 'The DESCRIPTION file' in the 'Writing R Extensions'
manual.
______
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [EXTERNAL] Re: FW: [CRAN-pretest-archived] CRAN submission surfaltr 1.0.0.9000
Thank you so much Sebastian!
Pooja
Pooja Gangras, Ph.D.
Postdoctoral Research Scientist - RNA Therapeutics
Eli Lilly and Company
Lilly Corporate Center, Indianapolis IN 46285 U.S.A.
Office phone number: (317) 651-0589
Cellphone number: (614) 906-0940
gangras_po...@lilly.com | www.lilly.com
CONFIDENTIALITY NOTICE: This email message (including all attachments) is for
the sole use of the intended recipient(s) and may contain confidential
information. Any unauthorized review, use, disclosure, copying or distribution
is strictly prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original message.
-Original Message-
From: Sebastian Meyer
Sent: Monday, August 16, 2021 2:49 PM
To: Pooja Gangras ; r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN
submission surfaltr 1.0.0.9000
EXTERNAL EMAIL: Use caution before replying, clicking links, and opening
attachments.
Packages on CRAN can depend on released packages from both CRAN and
Bioconductor.
I don't know why "msa" is missing on the Debian check machine. The check
results of another CRAN package that suggests "msa" indicate that this package
is currently unavailable on all Linux, Solaris and macOS machines of the CRAN
check farm:
https://cran.r-project.org/web/checks/check_results_bio3d.html
Maybe this is a temporary problem? You could try resubmitting in a few days.
I think you should remove the automatic package installation from your
functions; they should not write to the user's home filespace without consent.
You should probably also avoid this NOTE when submitting to CRAN:
> Version contains large components (1.0.0.9000)
Best regards,
Sebastian Meyer
Am 16.08.21 um 17:37 schrieb Pooja Gangras via R-package-devel:
> Hi all,
>
> PFA the pre-check results for my package surfaltr from CRAN. I am having
> troubles with a package dependency on Debian that I am not able to fix. 2
> functions in my package require a Bioconductor package msa
> (https://bioconductor.org/packages/release/bioc/html/msa.html). To deal with
> this error, I tried the following solution of adding a call to BiocManager
> and also including a code for msa installation but it did not help:
>
> #' @importFrom BiocManager install
> #' @import msa
> .
> .
> .
> Foo() {
> if (!requireNamespace("msa", quietly = TRUE)){
> BiocManager::install("msa")}
> }
>
> How do I solve the problem so that I don't generate this error with Debian?
>
> Thank you,
> Pooja
>
>
> Pooja Gangras, Ph.D.
> Postdoctoral Research Scientist - RNA Therapeutics Eli Lilly and
> Company Lilly Corporate Center, Indianapolis IN 46285 U.S.A.
> Office phone number: (317) 651-0589
> Cellphone number: (614) 906-0940
> gangras_po...@lilly.com | www.lilly.com
>
>
> CONFIDENTIALITY NOTICE: This email message (including all attachments) is for
> the sole use of the intended recipient(s) and may contain confidential
> information. Any unauthorized review, use, disclosure, copying or
> distribution is strictly prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the
> original message.
>
> -Original Message-
> From: lig...@statistik.tu-dortmund.de
>
> Sent: Monday, August 16, 2021 10:32 AM
> To: Pooja Gangras
> Cc: cran-submissi...@r-project.org
> Subject: [EXTERNAL] [CRAN-pretest-archived] CRAN submission surfaltr
> 1.0.0.9000
>
> EXTERNAL EMAIL: Use caution before replying, clicking links, and opening
> attachments.
>
> Dear maintainer,
>
> package surfaltr_1.0.0.9000.tar.gz does not pass the incoming checks
> automatically, please see the following pre-tests:
> Windows:
> <https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.900
> 0_20210816_162209/Windows/00check.log>
> Status: 1 NOTE
> Debian:
> <https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.900
> 0_20210816_162209/Debian/00check.log>
> Status: 1 ERROR, 1 NOTE
>
>
>
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the
> R-package-devel mailing list:
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> If you are fairly certain the rejection is a false positive, please reply-all
> to this message and explain.
>
> More details are given in the directory:
> <https://win-builder.r-project.org/incoming_pretest/surfaltr_1.0.0.900
> 0_20210816_162209/> The files will be removed after roughly 7 days.
>
> No strong reverse dependenc
Re: [R-pkg-devel] (R-devel unknown warning: 'memory.limit()' is no longer supported)
There was a recent changed made to R to remove that option. There is documentation visible in the patch that explains it: https://github.com/r-devel/r-svn/commit/795fb3fe60d35734750afbc34cc7d36b19290b9c Presumably you would have to remove any uses of the now unsupported functions. After the patch, the only thing those functions do is issue the warning. Best, B. On Friday, September 3, 2021, 11:39:03 AM EDT, Cristhian Paredes Cardona wrote: Dear All, I'm trying to submit an R package to CRAN and there is a new warning that did not use to appear a few days ago when checking with winbuilder (R under development version): Found the following significant warnings: Warning: 'memory.limit()' is no longer supported See 'd:/RCompile/CRANincoming/R-devel/masscor.Rcheck/00install.out' for details. Package build is attached and Check results when the warning did not appear are at: https://win-builder.r-project.org/2zQe5ZnEci31/ I would appreciate if someone could please provide me with some guide on how to solve this issue. Thanks in advance. Sincerely, Cristhian Paredes -- *Aviso legal:* El contenido de este mensaje y los archivos adjuntos son confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. Se encuentran dirigidos sólo para el uso del destinatario al cual van enviados. La reproducción, lectura y/o copia se encuentran prohibidas a cualquier persona diferente a este y puede ser ilegal. Si usted lo ha recibido por error, infórmenos y elimínelo de su correo. Los Datos Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra Política de Datos Personales que podrá consultar en la página web www.unal.edu.co <http://www.unal.edu.co/>.* *Las opiniones, informaciones, conclusiones y cualquier otro tipo de dato contenido en este correo electrónico, no relacionados con la actividad de la Universidad Nacional de Colombia, se entenderá como personales y de ninguna manera son avaladas por la Universidad. ______ 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] (R-devel unknown warning: 'memory.limit()' is no longer supported)
Or you might need to make their use conditional on the R version. It is possible that the call is still needed if your package is run on older versions of R. I am not familiar with the general use of this though. I only noticed the change in R-devel and linked it to your question. Best, B. On Friday, September 3, 2021, 12:18:35 PM EDT, brodie gaslam wrote: There was a recent changed made to R to remove that option. There is documentation visible in the patch that explains it: https://github.com/r-devel/r-svn/commit/795fb3fe60d35734750afbc34cc7d36b19290b9c Presumably you would have to remove any uses of the now unsupported functions. After the patch, the only thing those functions do is issue the warning. Best, B. On Friday, September 3, 2021, 11:39:03 AM EDT, Cristhian Paredes Cardona wrote: Dear All, I'm trying to submit an R package to CRAN and there is a new warning that did not use to appear a few days ago when checking with winbuilder (R under development version): Found the following significant warnings: Warning: 'memory.limit()' is no longer supported See 'd:/RCompile/CRANincoming/R-devel/masscor.Rcheck/00install.out' for details. Package build is attached and Check results when the warning did not appear are at: https://win-builder.r-project.org/2zQe5ZnEci31/ I would appreciate if someone could please provide me with some guide on how to solve this issue. Thanks in advance. Sincerely, Cristhian Paredes -- *Aviso legal:* El contenido de este mensaje y los archivos adjuntos son confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. Se encuentran dirigidos sólo para el uso del destinatario al cual van enviados. La reproducción, lectura y/o copia se encuentran prohibidas a cualquier persona diferente a este y puede ser ilegal. Si usted lo ha recibido por error, infórmenos y elimínelo de su correo. Los Datos Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra Política de Datos Personales que podrá consultar en la página web www.unal.edu.co <http://www.unal.edu.co/>.* *Las opiniones, informaciones, conclusiones y cualquier otro tipo de dato contenido en este correo electrónico, no relacionados con la actividad de la Universidad Nacional de Colombia, se entenderá como personales y de ninguna manera son avaladas por la Universidad. ______ 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] system.file duplicates the path
Fabio, Judging from prior versions of your package, the function `tile_read` makes many assumptions as to what paths will look like, and also modifies paths. In this case, it appears to be thrown off by either the lower case drive name, or the forward slashes in the path. Presumably winbuilder is now running in a configuration that does different things with paths. Under those new paths, your code will double up the path by pre-pending the current working directory. This is not a `system.file` issue. I just took the second part of (grabbed from the error message): 'd:/RCompile/CRANincoming/R-devel/uFTIR.Rcheck/d:/RCompile/CRANincoming/R-devel/lib/uFTIR/extdata/tile.bsp' and fed it to your function from the prior version of your package and was able to produce a doubled up path as above. Best, B. PS: with this type of thing it is always helpful if you can provide a link to an online repository with the version of the code that you are trying to submit. On Friday, September 3, 2021, 12:29:02 PM EDT, Fabio Corradini S. wrote: Dear All: I submitted a package to CRAN. I developed it in DEBIAN and tested it in R-HUB windows devel, windows release, and macOS. None of the systems throw an error to me, and I mainly get notes about the package archived condition. However, the package failed at win-builder devel, as in one of the tests I call base::system.file to read a file and the function --only there-- returns the file path twice. Does system.file work differently on windows? You can check out CRAN win-builder check.log at: < https://win-builder.r-project.org/incoming_pretest/uFTIR_0.1.3_20210903_174243/Windows/00check.log > Kind regards, Fabio -- [[alternative HTML version deleted]] ______ 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-pkg-devel] Packages required but not available
Hello, I received the following output from my package, oncoPredict. However, I don't understand how to correct this error. I've tested the advice here: https://stackoverflow.com/questions/14358814/error-in-r-cmd-check-packages-required-but-not-available without success. Any thoughts as to how this error can be fixed? Danielle Maeser *Version: 0.1Check: package dependenciesResult: ERRORPackages required but not available: 'org.Hs.eg.db', 'TxDb.Hsapiens.UCSC.hg19.knownGene', 'maftools', 'TCGAbiolinks'* * See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’* *manual.Flavor: r-release-macos-x86_64 <https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/oncoPredict-00check.html>* -- Ph.D. Student Bioinformatics and Computational Biology University of Minnesota [[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] Packages required but not available
Hi David, Yes. I did recently upgrade R. On Sat, Sep 11, 2021 at 4:28 PM wrote: > Danielle: > > Did you recently upgrade to R 4.1.1? > > David > > > -Original Message- > From: R-package-devel On Behalf > Of Danielle Maeser via R-package-devel > Sent: Saturday, September 11, 2021 5:10 PM > To: R Package Devel > Subject: [R-pkg-devel] Packages required but not available > > Hello, > > I received the following output from my package, oncoPredict. > > However, I don't understand how to correct this error. I've tested the > advice here: > > https://stackoverflow.com/questions/14358814/error-in-r-cmd-check-packages-required-but-not-available > without success. > > Any thoughts as to how this error can be fixed? > > Danielle Maeser > > > > > > > *Version: 0.1Check: package dependenciesResult: ERRORPackages required > but not available: 'org.Hs.eg.db', 'TxDb.Hsapiens.UCSC.hg19.knownGene', > 'maftools', 'TCGAbiolinks'* > * See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’* > > *manual.Flavor: r-release-macos-x86_64 > < > https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/oncoPredict-00check.html > >* > -- > Ph.D. Student > Bioinformatics and Computational Biology University of Minnesota > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- Ph.D. Student Bioinformatics and Computational Biology University of Minnesota [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Good practice for database with utf-8 string in package
I have posted this question first to r-h...@r-project.org and Bert Gunter informs me that it was better for this discussion list that I didn't know. Hello everyone, I am a little bit stucked on the problem to include a database with utf-8 string in a package. When I submit it to CRAN, it reports NOTES for several Unix system and I try to find a solution (if it exists) to not have these NOTES. The database has references and some names have non ASCII characters. * First I don't agree at all with the solution proposed here: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues "First, consider carefully if you really need non-ASCIItext." If a language has non ASCII characters, it is not just to make the writting nicer of more complex, it is because it changes the prononciation. * Then I try to find solution to not have these NOTES. For example, here is a reference with utf-8 characters > DatabaseTSD$Reference[211] [1] Hernández-Montoya, V., Páez, V.P. & Ceballos, C.P. (2017) Effects of temperature on sex determination and embryonic development in the red-footed tortoise, Chelonoidis carbonarius. Chelonian Conservation and Biology 16, 164-171. When I convert the characters into unicode, I get indeed only ASCII characters. Perfect. > iconv(DatabaseTSD$Reference[211], "UTF-8", "ASCII", "Unicode") [1] "Hernndez-Montoya, V., Pez, V.P. & Ceballos, C.P. (2017) Effects of temperature on sex determination and embryonic development in the red-footed tortoise, Chelonoidis carbonarius. Chelonian Conservation and Biology 16, 164-171." Then I have no NOTES when I checked the package with database in UNIX... but how can I print the reference back with original characters ? Thanks a lot to point me to best practices to include databases with non-ASCII characters and not have NOTES while submitted package to CRAN. Marc [[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] Good practice for database with utf-8 string in package
You could also try to submit the package to CRAN with a comment about the NOTE.
There is interesting information in
https://discuss.ropensci.org/t/note-on-utf-8-strings-by-goodpractice-gp/2165/
Good luck!
Ma\\u00eblle
Den fredag 17 september 2021 13:01:25 CEST, Enrico Schumann
skrev:
On Fri, 17 Sep 2021, Marc Girondot via R-package-devel writes:
> I have posted this question first to r-h...@r-project.org and Bert Gunter
> informs me that it was better for this discussion list that I didn't know.
>
> Hello everyone,
>
> I am a little bit stucked on the problem to include a database with
> utf-8 string in a package. When I submit it to CRAN, it reports NOTES
> for several Unix system and I try to find a solution (if it exists) to
> not have these NOTES.
>
> The database has references and some names have non ASCII characters.
>
> * First I don't agree at all with the solution proposed here:
>
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Encoding-issues
>
> "First, consider carefully if you really need non-ASCIItext."
>
> If a language has non ASCII characters, it is not just to make the
> writting nicer of more complex, it is because it changes the prononciation.
>
> * Then I try to find solution to not have these NOTES.
>
> For example, here is a reference with utf-8 characters
>
>> DatabaseTSD$Reference[211]
>
> [1] Hernández-Montoya, V., Páez, V.P. & Ceballos, C.P. (2017) Effects of
> temperature on sex determination and embryonic development in the
> red-footed tortoise, Chelonoidis carbonarius. Chelonian Conservation and
> Biology 16, 164-171.
>
> When I convert the characters into unicode, I get indeed only ASCII
> characters. Perfect.
>
>> iconv(DatabaseTSD$Reference[211], "UTF-8", "ASCII", "Unicode")
>
> [1] "Hernndez-Montoya, V., Pez, V.P. & Ceballos, C.P.
> (2017) Effects of temperature on sex determination and embryonic
> development in the red-footed tortoise, Chelonoidis carbonarius.
> Chelonian Conservation and Biology 16, 164-171."
>
> Then I have no NOTES when I checked the package with database in UNIX...
> but how can I print the reference back with original characters ?
>
> Thanks a lot to point me to best practices to include databases with
> non-ASCII characters and not have NOTES while submitted package to CRAN.
>
> Marc
>
WRE in section 1.1.5 says:
"Any byte will be allowed in a quoted character string but ‘\u’
escapes should be used for non-ASCII characters. However, non-ASCII
character strings may not be usable in some locales and may display
incorrectly in others."
So you could try to use such escapes, e.g.
stringi::stri_escape_unicode("Hernández-Montoya")
## [1] "Hern\\u00e1ndez-Montoya"
--
Enrico Schumann
Lucerne, Switzerland
http://enricoschumann.net
______
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] [External] Re: What is a "retired"package?
Philosophy aside, albeit not uninteresting, I am wondering about the etiquette of developing a package and then years later dealing with how to have it replaced carefully. Do creators and maintainers have any obligation and especially when there is a large remaining embedded base of users. We may have quite a few Y2K type problems in the sense that some people cannot easily change what is being used. Other languages, like Python, have been dealing with how the newer language features (version 3) have serious incompatibilities with earlier versions and yet some stay with what they have. Hadley Wickham for example, has been involved in multiple packages including cases like ggplot where it was replaced by another package with enough incompatibilities that it might merit another name. I am not sure what exactly was in plyr when it stopped being changed but in some ways the dplyr package seems to focus on data.frames and plyr was more general. And, I suspect, dplyr also tried to do things consistent with new design approaches such as standardizing where arguments to a function go. It may well be faster when used as planned. But as a possibility, I suspect you could theoretically take the source code for a package that has largely been replaced by others and sometimes make a sort of compatibility version that consists largely of pointers to other packages. Specifically, the documentation could contain a section that suggests alternatives to use. I suspect quite a few of the included functions may be available in base R or another commonly used package (such as the tidyverse collection) and just using the new one, perhaps with some alteration in how it is called, might help guide existing users away to something more likely to be maintained. And sometimes, it might be weirdly possible to have a volunteer do something a tad odd and set up a way to replace the functions in the package. A function call like f(z, data) might simply be mapped into a call to other::g(data, z, flag=FALSE) if that made sense. Other fairly small wrappers might do more such re-direction. Obviously, this would be of limited use if other packages would need to be loaded. I can imagine leaving a package intact and adding a new function with a name like supercede() that would make such a re-arrangement when asked to. The user would normally call: library(plyr) plyr::supercede() Without that additional line, nothing changes. But after calling it, you may now be in a partial compatibility mode. I now retire without being superseded. -Original Message- From: R-package-devel On Behalf Of Martin Maechler Sent: Wednesday, September 22, 2021 3:39 AM To: Lenth, Russell V Cc: r-package-devel@r-project.org Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package? >>>>> Lenth, Russell V >>>>> on Tue, 21 Sep 2021 18:43:07 + writes: > As I suspected, and a good point. But please note that the term "retired" causes angst, and it may be good to change that to "superceded" or something else. well, some of us will become "retired" somewhere in the future rather than "superseded" .. ;-) __ 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] ERROR (re)building vignettes
Dear Christine, Looking at the chunk that causes the error https://github.com/cran/SleepCycles/blob/141186934418af387f0af257e3079af588e72844/vignettes/introduction.Rmd#L50-L56 (via the CRAN mirror maintained by R-hub): * You should not install packages from a vignette. You can add "eval=FALSE" as a chunk option. * Regarding the other lines in that chunk, they do not provoke an error but are not recommended by all. See e.g. https://www.tidyverse.org/blog/2017/12/workflow-vs-script/ Good luck with re-submission! Maëlle. Den onsdag 22 september 2021 22:20:36 CEST, Blume Christine skrev: Dear community, When building my package 'SleepCycles' using devtools::check, devtools::check_win_devel, and devtools::check_rhub, I do not get warnings, errors, or notes. Nevertheless, there seems to be an error when building the vignettes eventually (https://cran-archive.r-project.org/web/checks/2021/2021-09-06_check_results_SleepCycles.html), which I did not notice and which led to the removal of the package. Does anyone know how to solve this? I read something about changing the vignette engine, but when I tried this, I ran into other issues. I cannot replicate the error, but simply resubmitting will most likely result in the same issue again. Best, Christine [[alternative HTML version deleted]] __________ 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] Namespace is imported from in YAML header, but attracts Note that is is not imported from
Hello, It's better to get rid of this NOTE, by listing bookdown in VignetteBuilder and Suggests, not Imports see https://blog.r-hub.io/2020/06/03/vignettes/#infrastructure--dependencies-for-vignettes That's actually what you did in another package https://github.com/cran/gamclass/blob/master/DESCRIPTION (it's a coincidence I found a package of yours via code search in CRAN GitHub mirror :-) ). Maëlle. Den fredag 24 september 2021 03:00:57 CEST, John H Maindonald skrev: On the Atlas and Linux builds of my package `qra` that has just been posted on CRAN, I am getting the message: > Namespace in Imports field not imported from: ‘bookdown’ > All declared Imports should be used. This, in spite of the fct that the YAML header in two of the Rmd files for the vignettes has: > output: > bookdown::html_document2: > theme: cayman Do I need to worry about this? John Maindonald ______ 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-pkg-devel] Re :Re: Internet resources and Errors
We've summarized some advice around graceful packages in this chapter of the HTTP testing in R book: https://books.ropensci.org/http-testing/graceful.html I hope this can help too! Le ven., sept. 24, 2021 à 17:03, Ben Bolker a écrit: I think you're not supposed to stop(). You should just proceed with the other tests (skipping any tests/examples that depend on access to the inaccessible internet resources, or values derived from the failing call, to work) Does that help? On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA Federal via R-package-devel wrote: > Hi All: > > I am getting dinged again on CRAN (just Solaris for some reason), and the > problem is how to exit if there is a failure of accessing the resource, I > know it has been discussed here before, but I just am not understanding what > is desired to end properly. As I have been reminded: > > 'Packages which use Internet resources should fail gracefully with an > informative message > if the resource is not available or has changed (and not give a check warning > nor error).' > > All internet calls are wrapped in 'try()'. If that shows an error, I write > a message to the screen about the error, and call stop(), perhaps with a > further message in that call. Somehow this does not appear to meet the > standard. Can someone then please tell me what I should do instead. The > point is I have checked that the access to the internet resources has worked, > i have seen that it hasn't, now what should be the steps to take to exit > gracefully. > > I also want to add to what others have said about the frustrations of dealing > with Solaris. I have spent a fair amount of time getting things to work > with Solaris which no one uses. In this instance the package test is only > failing on Solaris. Not a good use of limited time IMO. > > Thanks for any advice. > > -Roy > > > > ** > "The contents of this message do not reflect any position of the U.S. > Government or NOAA." > ** > Roy Mendelssohn > Supervisory Operations Research Analyst > NOAA/NMFS > Environmental Research Division > Southwest Fisheries Science Center > ***Note new street address*** > 110 McAllister Way > Santa Cruz, CA 95060 > Phone: (831)-420-3666 > Fax: (831) 420-3980 > e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/ > > "Old age and treachery will overcome youth and skill." > "From those who have been given much, much will be expected" > "the arc of the moral universe is long, but it bends toward justice" -MLK Jr. > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Dr. Benjamin Bolker Professor, Mathematics & Statistics and Biology, McMaster University Director, School of Computational Science and Engineering Graduate chair, Mathematics & Statistics __ 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] Package submission to CRAN
I would just increment the version. This is the from the CRAN re-submission policy[1]: > Updates to previously-published packages must have an increased version. > Increasing the version number at each submission reduces confusion so is > preferred even when a previous submission was not accepted. You could always add NEWS entry explaining what the new version is, then the package will not be exactly the same anymore ;). Best, B. [1]: https://cran.r-project.org/web/packages/policies.html#Re_002dsubmission On Tuesday, October 19, 2021, 08:38:01 AM EDT, Simon Bonner wrote: Hi all, I have a question re package submission that I'm hoping someone might be able to help with. A package I maintain (dalmatian) was archived last year because one of the packages it depends on (dglm) was removed from CRAN. The dglm package has been fixed and is back on CRAN, and I have resubmitted my package. There have been no changes to my package and I resubmitted the same version with the same version number. I noted this in my submission. All checks passed, but I received the following from log CRAN-pretest: Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility, Result: WARNING Maintainer: 'Simon Bonner simon.bon...@uwo.ca<mailto:simon.bon...@uwo.ca>' New submission Package was archived on CRAN Insufficient package version (submitted: 0.6.1, existing: 0.6.1) CRAN repository db overrides: X-CRAN-Comment: Archived on 2020-10-18 as requires archived package 'dglm'. This build time stamp is over a month old. It seems that I am not allowed to submit the package with the same version, but it also seems odd to increment the version to get around this when nothing at all has changed in the package. Is there another solution? Thanks, Simon - Simon Bonner (he/him) Associate Professor of Environmetrics Vice-Director, Western Data Science Solutions Department of Statistical and Actuarial Sciences University of Western Ontario Office: Western Science Centre rm 276 Email: sbonn...@uwo.ca<mailto:sbonn...@uwo.ca> | Telephone: 519-661-2111 x88205 | Fax: 519-661-3813 Twitter: @bonnerstatslab | Website: http://simon.bonners.ca/bonner-lab/wpblog/ [[alternative HTML version deleted]] ______ 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] R feature suggestion: Duplicated function arguments check
Duncan,
This may not be the place to discuss this so I will be brief.
The question is whether it should be some kind of error to call a function
with two named arguments that are the same.
I can think of a perhaps valid use when a function expects to take the first
few arguments for personal use and then uses ... to pass the rest along to
other functions it calls.
so in your case, slightly extended:
f(a=1, b=2, a=3, c=-5)
The function might pass along to another function:
other(arg, ...)
which would be seen as:
other(arg, a=3, c=-5)
There can of course be other ways to get this result but probably not as
simple. And note this can go several layers deep as various functions call
each other and each has a different need and even meaning for a=something.
Avi
-Original Message-
From: R-package-devel On Behalf Of
Duncan Murdoch
Sent: Monday, November 8, 2021 11:04 AM
To: Vincent van Hees ;
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R feature suggestion: Duplicated function
arguments check
On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
> Not sure if this is the best place to post this message, as it is more
> of a suggestion than a question.
>
> When an R function accepts more than a handful of arguments there is
> the risk that users accidentally provide arguments twice, e.g
> myfun(A=1, B=2, C=4, D=5, A=7), and if those two values are not the
> same it can have frustrating side-effects. To catch this I am planning
> to add a check for duplicated arguments, as shown below, in one of my
> own functions. I am now wondering whether this would be a useful
> feature for R itself to operate in the background when running any R
> function that has more than a certain number of input arguments.
>
> Cheers, Vincent
>
> myfun = function(...) {
>#check input arguments for duplicate assignments
>input = list(...)
>if (length(input) > 0) {
> argNames = names(input)
> dupArgNames = duplicated(argNames)
> if (any(dupArgNames)) {
>for (dupi in unique(argNames[dupArgNames])) {
> dupArgValues = input[which(argNames %in% dupi)]
> if (all(dupArgValues == dupArgValues[[1]])) { # double
> arguments, but no confusion about what value should be
>warning(paste0("\nArgument ", dupi, " has been provided
> more than once in the same call, which is ambiguous. Please fix."))
> } else { # double arguments, and confusion about what value
> should be,
>stop(paste0("\nArgument ", dupi, " has been provided more
> than once in the same call, which is ambiguous. Please fix."))
> }
>}
> }
>}
># rest of code...
> }
>
Could you give an example where this is needed? If a named argument is
duplicated, R will catch that and give an error message:
> f(a=1, b=2, a=3)
Error in f(a = 1, b = 2, a = 3) :
formal argument "a" matched by multiple actual arguments
So this can only happen when it is an argument in the ... list that is
duplicated. But usually those are passed to some other function, so
something like
g <- function(...) f(...)
would also catch the duplication in g(a=1, b=2, a=3):
> g(a=1, b=2, a=3)
Error in f(...) :
formal argument "a" matched by multiple actual arguments
The only case where I can see this getting by is where you are never using
those arguments to match any formal argument, e.g.
list(a=1, b=2, a=3)
Maybe this should have been made illegal when R was created, but I think
it's too late to outlaw now: I'm sure there are lots of people making use
of this.
Or am I missing something?
Duncan Murdoch
__
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] R feature suggestion: Duplicated function arguments check
Vincent,
But is the second being ignored the right result?
In many programming situations, subsequent assignments replace earlier ones.
And consider the way R allows something like this:
func(a=2, b=3, a=4, c=a*b)
Is it clear how to initialize the default for c as it depends on one value
of "a" or the other?
Of course, you could just make multiple settings an error rather than
choosing an arbitrary fix.
R lists are more like a BAG data structure than a SET.
-Original Message-----
From: R-package-devel On Behalf Of
Vincent van Hees
Sent: Monday, November 8, 2021 11:25 AM
To: Duncan Murdoch
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R feature suggestion: Duplicated function
arguments check
Thanks Duncan, I have tried to make a minimalistic example:
myfun = function(...) {
input = list(...)
mysum = function(A = c(), B= c()) {
return(A+B)
}
if ("A" %in% names(input) & "B" %in% names(input)) {
print(mysum(A = input$A, B = input$B))
}
}
# test:
> myfun(A = 1, B = 2, B = 4)
[1] 3
# So, the second B is ignored.
On Mon, 8 Nov 2021 at 17:03, Duncan Murdoch
wrote:
> On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
> > Not sure if this is the best place to post this message, as it is
> > more
> of a
> > suggestion than a question.
> >
> > When an R function accepts more than a handful of arguments there is
> > the risk that users accidentally provide arguments twice, e.g
> > myfun(A=1, B=2, C=4, D=5, A=7), and if those two values are not the
> > same it can have frustrating side-effects. To catch this I am
> > planning to add a check for duplicated arguments, as shown below, in
> > one of my own functions. I am
> now
> > wondering whether this would be a useful feature for R itself to
> > operate
> in
> > the background when running any R function that has more than a
> > certain number of input arguments.
> >
> > Cheers, Vincent
> >
> > myfun = function(...) {
> >#check input arguments for duplicate assignments
> >input = list(...)
> >if (length(input) > 0) {
> > argNames = names(input)
> > dupArgNames = duplicated(argNames)
> > if (any(dupArgNames)) {
> >for (dupi in unique(argNames[dupArgNames])) {
> > dupArgValues = input[which(argNames %in% dupi)]
> > if (all(dupArgValues == dupArgValues[[1]])) { # double
> arguments,
> > but no confusion about what value should be
> >warning(paste0("\nArgument ", dupi, " has been provided
> > more
> than
> > once in the same call, which is ambiguous. Please fix."))
> > } else { # double arguments, and confusion about what value
> should
> > be,
> >stop(paste0("\nArgument ", dupi, " has been provided more
> > than once in the same call, which is ambiguous. Please fix."))
> > }
> >}
> > }
> >}
> ># rest of code...
> > }
> >
>
> Could you give an example where this is needed? If a named argument
> is duplicated, R will catch that and give an error message:
>
>> f(a=1, b=2, a=3)
>Error in f(a = 1, b = 2, a = 3) :
> formal argument "a" matched by multiple actual arguments
>
> So this can only happen when it is an argument in the ... list that is
> duplicated. But usually those are passed to some other function, so
> something like
>
>g <- function(...) f(...)
>
> would also catch the duplication in g(a=1, b=2, a=3):
>
>> g(a=1, b=2, a=3)
>Error in f(...) :
> formal argument "a" matched by multiple actual arguments
>
> The only case where I can see this getting by is where you are never
> using those arguments to match any formal argument, e.g.
>
>list(a=1, b=2, a=3)
>
> Maybe this should have been made illegal when R was created, but I
> think it's too late to outlaw now: I'm sure there are lots of people
> making use of this.
>
> Or am I missing something?
>
> Duncan Murdoch
>
[[alternative HTML version deleted]]
__
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-pkg-devel] CRAN submission error when running tests in testthat
Hi,
I've getting an ERROR when submitting a new release of our package BCEA to CRAN
which I'm having problems understanding and reproducing. Its passing CHECK
locally and GitHub Actions standard check
(https://github.com/n8thangreen/BCEA/actions/runs/1494595896).
The message is something to do with testthat. Any help would be gratefully
received.
Thanks!
Nathan
From https://cran.r-project.org/web/checks/check_results_BCEA.html
Here's the error message:
Check: tests, Result: ERROR
Running ‘testthat.R’ [5s/5s]
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
33: tryCatch(withCallingHandlers({eval(code, test_env)if (!handled
&& !is.null(test)) {skip_empty()}}, expectation =
handle_expectation, skip = handle_skip, warning = handle_warning, message =
handle_message, error = handle_error), error = handle_fatal, skip =
function(e) {})
34: test_code(NULL, exprs, env)
35: source_file(path, child_env(env), wrap = wrap)
36: FUN(X[[i]], ...)
37: lapply(test_paths, test_one_file, env = env, wrap = wrap)
38: doTryCatch(return(expr), name, parentenv, handler)
39: tryCatchOne(expr, names, parentenv, handlers[[1L]])
40: tryCatchList(expr, classes, parentenv, handlers)
41: tryCatch(code, testthat_abort_reporter = function(cnd) {
cat(conditionMessage(cnd), "\n")NULL})
42: with_reporter(reporters$multi, lapply(test_paths, test_one_file,
env = env, wrap = wrap))
43: test_files(test_dir = test_dir, test_package = test_package,
test_paths = test_paths, load_helpers = load_helpers, reporter = reporter,
env = env, stop_on_failure = stop_on_failure, stop_on_warning =
stop_on_warning, wrap = wrap, load_package = load_package)
44: test_files(test_dir = path, test_paths = test_paths, test_package =
package, reporter = reporter, load_helpers = load_helpers, env = env,
stop_on_failure = stop_on_failure, stop_on_warning = stop_on_warning, wrap
= wrap, load_package = load_package, parallel = parallel)
45: test_dir("testthat", package = package, reporter = reporter, ...,
load_package = "installed")
46: test_check("BCEA")
An irrecoverable exception occurred. R is aborting now ...
See:
<https://www.r-project.org/nosvn/R.check/r-release-macos-x86_64/BCEA-00check.html>,
<https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/BCEA-00check.html>
Dr
Nathan Green
@: n8thangr...@yahoo.co.ukTel: 07821 318353
[[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] rstan issue [Was: CRAN submission error when running tests in testthat]
Thanks everyone for your help with this.TBH the technical nature is more than a
little above my head.What are you advising as the current solution to enable me
to resubmit the package to CRAN?BCEA doesn't have a strong dependency on rstan
so I could remove it as a simple solution?Thanks again for all the help!
Nathan
Dr
Nathan Green
@: n8thangr...@yahoo.co.ukTel: 07821 318353
On Thursday, 25 November 2021, 22:56:45 GMT, Simon Urbanek
wrote:
Kevin,
thanks, that's very helpful! So this is a serious bug in rstan - apparently
they only do that on macOS which explains why other platforms don't see it:
.onLoad <- function(libname, pkgname) {
[...]
## the tbbmalloc_proxy is not loaded by RcppParallel which is linked
## in by default on macOS; unloading only works under R >= 4.0 so that
## this is only done for R >= 4.0
if(R.version$major >= 4 && Sys.info()["sysname"] == "Darwin") {
tbbmalloc_proxy <- system.file("lib/libtbbmalloc_proxy.dylib",
package="RcppParallel", mustWork=FALSE)
tbbmalloc_proxyDllInfo <<- dyn.load(tbbmalloc_proxy, local = FALSE, now =
TRUE)
}
I can confirm that commenting out that part solves the segfault and BCEA passes
the tests.
@Ben, please fix and submit a new version of rstan (see discussion below).
Thanks,
Simon
> On Nov 26, 2021, at 11:19 AM, Kevin Ushey wrote:
>
> That shouldn't be happening, at least not by default. However, RcppParallel
> does ship with tbbmalloc_proxy, which is a library that, when loaded, will
> overload the default allocators to use TBB's allocators instead. The
> intention is normally that these libraries would be loaded via e.g.
> LD_PRELOAD or something similar, since changing the allocator at runtime
> would cause these sorts of issues.
>
> If I test with the following:
>
> trace(dyn.load, quote({
> if (grepl("tbbmalloc_proxy", x))
> print(rlang::trace_back())
> }), print = FALSE)
>
> devtools::test()
>
> then I see:
>
> 1. ├─base::load(test_path("data", "stanfit.RData")) at test-bcea.R:179:2
> 2. └─base::..getNamespace(``, "stanfit")
> 3. ├─base::tryCatch(...)
> 4. │ └─base tryCatchList(expr, classes, parentenv, handlers)
> 5. │ └─base tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 6. │ └─base doTryCatch(return(expr), name, parentenv, handler)
> 7. └─base::loadNamespace(name)
> 8. └─base runHook(".onLoad", env, package.lib, package)
> 9. ├─base::tryCatch(fun(libname, pkgname), error = identity)
> 10. │ └─base tryCatchList(expr, classes, parentenv, handlers)
> 11. │ └─base tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 12. │ └─base doTryCatch(return(expr), name, parentenv, handler)
> 13. └─rstan fun(libname, pkgname)
> 14. └─base::dyn.load(tbbmalloc_proxy, local = FALSE, now = TRUE)
>
> My guess is that the 'rstan' package is trying to forcefully load
> libtbbmalloc_proxy.dylib at runtime, and that's causing the issue. IMHO
> 'rstan' shouldn't be doing that, at least definitely not by default.
>
> Best,
> Kevin
>
> On Thu, Nov 25, 2021 at 12:54 PM Simon Urbanek
> wrote:
> Nathan,
>
> testthat is notorious for obfuscation and unhelpful output as can be clearly
> seen in the head of testthat.Rout.fail:
>
> > library(testthat)
> > library(BCEA)
>
> Attaching package: 'BCEA'
>
> The following object is masked from 'package:graphics':
>
> contour
>
> >
> > test_check("BCEA")
>
> *** caught segfault ***
> address 0x10d492ffc, cause 'memory not mapped'
>
> However this appears to be hard to debug, because it is a fall out from some
> memory corruption and/or allocator mistmatch: the crash happens in free()
> while doing GC (see below). Since it happens in the GC, many bad things
> happen afterwards.
> With some lldb magic I could trace that the crash happens during
> ..getNamespace(c("Matrix", "1.3-3"), "stanfit")
> load(test_path("data", "stanfit.RData"))
> but as I said that's likely too late - the memory corruption/issue likely
> happened before. Since BCEA itself doesn't have native code, this is likely a
> bug in some of the packages it depends on, but quite a serious one since it
> affects subsequent code in R.
>
> The list of packages loaded at the time of the crash - so one of them is the
> culprit:
>
> [1] "rstan" "tidyselect" "purrr" &quo
[R-pkg-devel] Cannot submit package due to false-positive rejection
Hello all, Our package did not pass the automagical checks when submitted to CRAN. We think the rejection is a false positive, so we �reply-all to that message and explain� as following the official instruction. We provided explanation for all notes in that email (replied to cran-submissi...@r-project.org<mailto:cran-submissi...@r-project.org>) but did not receive any message after 9 days. I am looking for suggestions on what to do in this case: should we continue waiting for CRAN team�s reply? Or is it necessary to eliminate those notes and then submit the package again? Below are the notes from CRAN teams' auto-check service and our explanation send to CRAN team: >Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64 >Check: CRAN incoming feasibility, Result: NOTE > Maintainer: 'Arindam RoyChoudhury > mailto:arr2...@med.cornell.edu>>' > New submission > Possibly misspelled words in DESCRIPTION: >Peng (17:5) >Phylogenetics (17:32) > al (17:13) >et (17:10) > Size of tarball: 14208488 bytes Explain: This is a new submission. These words are not misspelled. >Flavor: r-devel-windows-x86_64 >Check: examples, Result: NOTE > Examples with CPU (user + system) or elapsed time > 10s > user system elapsed > RDM 40.05 0.89 40.94 Explain: This is because a large dataset is used in the example. An example with large dataset is necessary, as this package is meant for analyzing large datasets. >Flavor: r-devel-linux-x86_64-debian-gcc >Check: examples, Result: NOTE > Examples with CPU (user + system) or elapsed time > 5s > user system elapsed > RDM 24.399 0.888 25.289 Explain: This is because a large dataset is used in the example. An example with large dataset is necessary, as this package is meant for analyzing large datasets. Any suggestions or comments would be appreciated. Thank you in advance! Best, Ying [[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] Package submission error due to vignette
On 22 November 2022 at 14:15, Jaihee Choi wrote:
| I was trying to resubmit a package but was notified that it did not pass
| the initial checks due to the following error message regarding compiling
| my vignette:
|
| Error: .onLoad failed in loadNamespace() for 'rje', details:
| call: getEngine(name, package)
| error: Vignette engine 'knitr' is not registered by any of the
| packages 'knitr'
| Execution halted
|
| I have knitr, rmarkdown, and rje under "Suggests:" in my description
| file, and I have VignetteBuilder: knitr. In the Vignette.Rmd I have
| %\VignetteEngine{knitr::rmarkdown}.
|
| Any guidance to resolve this issue would be much appreciated. Thank
| you very much.
It is an error in the current version of package 'rje' which I recently
pointed out to Robin, its maintainer. You may be able to wait for an update
(and may want to contact Robin about his timeline) or (at least for a while)
skip 'rje' in your vignette.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
______
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Inconsistent R CMD Check results
Dear all, Hope you are well! Recently, in the check before a re-submission, I got an unexpected note when doing R CMD Check using rhub::check_for_cran(), saying that "Examples with CPU (user + system) or elapsed time > 5s". I didn't expect this note to appear because the same examples didn't cause this note in the previous submission last December. Compared with the previous submission, we only edited documentation, there was no change in the R code for functions of our package. To double-check, I downloaded our previous submission from CRAN and checked it again. It's strange that this current CRAN version also has this note now. However, when submitting it last December, there were no such notes. Do you have any idea why the R CMD Check results are inconsistent? Since the examples caused no note in the last submission and were successfully submitted to CRAN, I'm not sure whether I should change the examples in this re-submission to eliminate this sudden note. Any suggestions will be appreciated! Thank you! Ying [[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] Inconsistent R CMD Check results
That makes sense, thanks very much for your explanation and advice, Tomas and Uwe! Best, Ying From: Uwe Ligges Sent: Wednesday, January 25, 2023 9:52 To: Tomas Kalibera ; Ying Li ; r-package-devel@r-project.org Cc: Arindam RoyChoudhury Subject: [EXTERNAL] Re: [R-pkg-devel] Inconsistent R CMD Check results On 24.01.2023 22:03, Tomas Kalibera wrote: > On 1/23/23 17:51, Ying Li via R-package-devel wrote: >> Dear all, >> >> Hope you are well! Recently, in the check before a re-submission, I >> got an unexpected note when doing R CMD Check using >> rhub::check_for_cran(), saying that "Examples with CPU (user + system) >> or elapsed time > 5s". >> >> I didn't expect this note to appear because the same examples didn't >> cause this note in the previous submission last December. Compared >> with the previous submission, we only edited documentation, there was >> no change in the R code for functions of our package. >> >> To double-check, I downloaded our previous submission from CRAN and >> checked it again. It's strange that this current CRAN version also has >> this note now. However, when submitting it last December, there were >> no such notes. Do you have any idea why the R CMD Check results are >> inconsistent? > > You could check on Winbuilder as that is a concrete setup used for > incoming checks. But in principle, the computation may take longer > because of changes in dependencies, external software and R. Which can > be due to a performance regression, a bugfix, etc. Only > debugging/profiling could reveal the true cause. Yes, it may even be some OS update, or just coincidence that the system was idling the last time your package got checked. Note that CRAN systems are expected to be slower than, e.g., your laptop, as the servers use multi core CPUs with rather low frequencies. Best, Uwe Ligges >> Since the examples caused no note in the last submission and were >> successfully submitted to CRAN, I'm not sure whether I should change >> the examples in this re-submission to eliminate this sudden note. Any >> suggestions will be appreciated! > If you were close to the limit last time, it may be a coincidence and > you might simply reduce the examples to be on the safe side. > > Tomas > >> >> Thank you! >> Ying >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dpackage-2Ddevel&d=DwIDaQ&c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=bP8EQnZ_JVp-Bf-Rt9gvjFVaFYbqdYei_Hbkmzh0LNc&m=eLlMF2DixVEB3UPnbyg6ZeQMZ1z2DEeFgsJnjG7ZOkd8aWS2QLCazYACWGs5Jb-_&s=J5wxZE1CYC6I4jZ-omVH9Fq0hOJuvUarBD9ckVePRe4&e= > > __ > R-package-devel@r-project.org mailing list > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dpackage-2Ddevel&d=DwIDaQ&c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=bP8EQnZ_JVp-Bf-Rt9gvjFVaFYbqdYei_Hbkmzh0LNc&m=eLlMF2DixVEB3UPnbyg6ZeQMZ1z2DEeFgsJnjG7ZOkd8aWS2QLCazYACWGs5Jb-_&s=J5wxZE1CYC6I4jZ-omVH9Fq0hOJuvUarBD9ckVePRe4&e= [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] DESCRIPTION file question
Hi everyone, I have a question about the DESCRIPTION file of an R package that has some c++ dependencies. This package of mine builds c++ code during an interactive R session, but does not contain any source c++ in itself. The c++ files make reference to some dependencies that are made available by other third party R packages. LinkingTo is the appropriate field for the DESCRIPTION file (usually) here, not Imports, but if If I remove the dependencies (BH and RcppEigen) from the Imports field, the code examples in the vignette will fail to build on a fresh machine. The NOTES in my build mention that, because I have no src/ directory, LinkingTo is ignored. Simultaneously, there is another note that mentions Imports is also excessive. It’s kind of a catch 22. It feels like my options are either add the Imports lines and ignore the NOTE, or add a superfluous src/ directory to silence the NOTE. Which option is the preferred one? Or is there a third? Best, Taylor R. Brown, Ph.D. Assistant Professor of Statistics, General Faculty Department of Statistics University of Virginia [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
