Re: [R-pkg-devel] error in windows R-devel builder, but not anywhere else
Looks like this recent change to R-devel has caught you:
\code{is.atomic(NULL)} now returns \code{FALSE}, as \code{NULL}
is not an atomic vector. Strict back-compatibility would
replace \code{is.atomic(foo)} by \code{(is.null(foo) ||
is.atomic(foo))}
but should happen only sparingly.
I don't know why you didn't see this on the other platforms; maybe they
just haven't been rebuilt recently.
Duncan Murdoch
On 13/04/2024 5:35 a.m., Tony Wilkes wrote:
Hi everyone,
I am updating my R package (tinycodet), and I have checked my R-package in all
operating systems (Linux, Mac, Windows). All examples and tests run correctly
for Linux, Mac, and Windows. Rcmd checks also finds no issues on GitHub (I use
rather strict Rcmdcheck workflows on GitHub, so any issues should be found
quickly on GitHub; see https://github.com/tony-aw/tinycodet). But on the Win
R-devel builder, I get an error. I use a Windows computer myself, and I can see
where the error takes place on the win R-devel-builder, but I cannot reproduce
the error. The error should not even be there.
The error takes place in the function `strfind(x, p, ..., i, rt)<-`. When the user specifies an
incorrect string for the optional argument `rt`, the error message "improper `rt`given" is
called. This is also the error message that occurs in Win R-devel Builder, but it shouldn't be there,
since no incorrect string is specified for "rt" there - otherwise, all operating systems
would give an error there.
Link to win R-devel builder results:
https://win-builder.r-project.org/2mG2vk48tri3/
My package has no Operating System specific functionality.
The fact that this error ONLY happens on win R-devel builder, and not when I
run it on my windows laptop, nor on any other OS, nor on the many checks on
GitHub, implies the issue might be on the Windows R-devel builder. But I don't
want to jump to conclusions. Hence my question is:
Is there currently an issue in win R-devel-builder? If not, why is the error
only on win R-devel-builder, and not anywhere else?
Thanks in advance for your help.
Kind regards,
Tony
[[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] Need help with "Lost braces" in R under development checks
On 06/04/2024 11:58 p.m., adi...@pdx.edu wrote:
Hello,
I would appreciate help with two build NOTEs:
First, On the Winbuilder check, the check for R version 4.4.0 alpha
(2024-04-05 r86346 ucrt) and also under the Debian R Under development
(unstable) (2024-04-05 r86348) I got a NOTE about a bunch of 'Lost
braces' in my .Rd files. I am confused because my braces appear to match
when I count them, and I don't *think* I am runing into an item/itemize
situation. Here's an example (all the reported issues in this NOTE are
within \references sections ):
checkRd: (-1) LoopAnalyst-package.Rd:14: Lost braces
14 | Dambacher, J. M. and Li, H. W. and Rossignol, P. A. (2002)
\doi{10.2307/3071950}{Relevance of community structure in assessing
indeterminacy of ecological predictions}. \emph{Ecology},
\bold{83(5)},1372--1385.
It appears you are trying to pass two arguments to \doi, but it only
takes one. I would have thought that would be fine, but apparently not.
So add a space after "\doi{10.2307/3071950}" and/or remove the braces
around "{Relevance of community structure in assessing indeterminacy of
ecological predictions}".
Duncan Murdoch
Here's the Winbuilder log:
https://win-builder.r-project.org/incoming_pretest/LoopAnalyst_1.2-7_20240406_215835/Windows/00check.log
And here's the Debian log:
https://win-builder.r-project.org/incoming_pretest/LoopAnalyst_1.2-7_20240406_215835/Debian/00check.log
The second NOTE is about "(possibly) invalid URLs:"
URL: https://www.journals.uchicago.edu/doi/10.1086/367590
Status: 403
Message: Forbidden
However, when I follow this URL in my browser it appears to link
appropriately to the intended page. If I use a \doi{10.1086/367590}
instead of an \href I get the same behavior: check says "(possibly)
invalid URLs" but https://doi.org/10.1086/367590 appears to work just
fine in the browser. Not sure what I am doing wrong here.
Thank you!
Alexis Dinno
Associate Professor
OHSU-PSU School of Public Health
Pronouns: she/her/hers
610-R Vanport Building
1810 SW 5th Avenue, Suite 610
Portland, OR 97201-5202
p: (503) 725-3076
f: (503) 725-5100
e: alexis.di...@pdx.edu
Note: I do not use a networked calendar, so meeting dates should be
communicated directly via email.
__
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] Removing import(methods) stops exporting S4 "meta name"
To save others a bit of time, the package in question is "do", and
Michael has already posted an issue on their Github page asking why they
made this import: https://github.com/yikeshu0611/do/issues/1 .
And if you remove that import and run R CMD check on "do", it fails with
this error:
* checking examples ... ERROR
Running examples in ‘do-Ex.R’ failed
The error most likely occurred in:
> ### Name: join
> ### Title: Join two dataframes together
> ### Aliases: join join_inner join_full join_left join_right join_out
>
> ### ** Examples
>
> df1=data.frame(x=rep(c('b','a','c'),each=3),
+ y=c(1,3,6),
+ v=1:9)
>
> df2=data.frame(x=c('c','b','e'),
+v=8:6,
+foo=c(4,2,1))
> join_inner(df1,df2,'x')
Error in xj[i] : invalid subscript type 'list'
Calls: join_inner -> data.frame -> [ -> [.data.table -> [.data.frame
Execution halted
I'm pretty sure that import should not be made, but I don't know the
intention of this example, or what the correct fix would be.
Duncan Murdoch
On 14/03/2024 2:34 p.m., Michael Chirico wrote:
In an effort to streamline our NAMESPACE, we moved from blanket
'import(methods)' to specific importFrom(methods, ) for the
objects we specifically needed.
Doing so broke a downstream package, however, which has this directive:
importFrom(data.table,`.__T__[:base`)
That package stopped installing after the above change. I can get it
to install again by adding:
importClassesFrom(methods, "[")
to our package, but I'm not sure why this would be necessary. I'm
still left with two questions:
1. How did we end up with ".__T__[:base" in our exports when we don't
do any S4 around '[' in the package (we do export S3 methods on it)?
2. Is there any legitimate reason for a package to try and import
such an object? In other words, is breaking this downstream package by
not adding the 'importClassesFrom' workaround the right thing to do? I
don't see any other CRAN packages with a similar directive in its
NAMESPACE.
Michael Chirico
__
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] Submission after archived version
On 11/03/2024 6:45 p.m., Nils Mechtel wrote: Hi, Our package was archived at the end of last year, and after some major rework we submitted a newer version yesterday. Despite R CMD check not giving any errors or warnings, the package doesn’t pass the pre-tests: package MetAlyzer_1.0.0.tar.gz does not pass the incoming checks automatically, please see the following pre-tests: Windows: <https://win-builder.r-project.org/incoming_pretest/MetAlyzer_1.0.0_20240310_215320/Windows/00check.log> Status: 2 NOTEs Debian: <https://win-builder.r-project.org/incoming_pretest/MetAlyzer_1.0.0_20240310_215320/Debian/00check.log> Status: 3 NOTEs Last released version's CRAN status: OK: 5, ERROR: 8 See: <https://cran-archive.r-project.org/web/checks/2023/2023-11-07_check_results_MetAlyzer.html> Do we miss something here? The first note is mostly informational, though you might want to mention that metabolomics is spelled correctly in your submission message. The second note should be fixed. Apparently your package has both Authors and Authors@R fields. Delete Authors and that should go away. The third note only happened on one system, so it may be a false positive, but what it says is that your checks created a file called metabolomics_data.csv some place where it shouldn't have created it. You should only be writing in the temp directory, and you should clean up afterwards. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [EXTERN] Re: [EXTERN] Re: [EXTERN] Re: @doctype is deprecated. need help for r package documentation
On 12/03/2024 6:58 a.m., Ivan Krylov via R-package-devel wrote: В Mon, 11 Mar 2024 14:57:58 + "Ruff, Sergej" пишет: I uploaded the old version of the package to my repo: https://github.com/SergejRuff/boot After installing this tarball, running RStudio and typing: library(bootGSEA) ?bootGSEA ...I see the help page in RStudio's help tab, not in the browser. I think this is the expected behaviour for RStudio. You can tell R to use an external browser in RStudio by setting the "browser" option. For example, options(browser="open") causes help to open in the default browser on MacOS. See ?browseURL for details of how to specify other browsers. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CHECK warning about new S3 generic/method consistency
On 11/03/2024 2:13 p.m., CRAN.r wrote: On Monday, March 11th, 2024 at 12:43 PM, Diego Hernangómez Herrero wrote: Shouldn’t you include the y argument also inmyscale.default ? Your generic is defining that argument as well. I assume (hopefully correctly) that methods don't need to include all the arguments of the generic. I get the same warning if I use "..." instead of y, too. No, your assumption is backwards. The methods do need to include all arguments of the generic. As Writing R Extensions says near the start of section 7, "A method must have all the arguments of the generic, including … if the generic does." Think about your user. They'll ask about help for `inmyscale`, and see that it has two arguments, x and y. If x is a type that goes to `inmyscale.default`, the user would receive an error when they followed the docs and included the y value. The usual way to handle this is to include both x and y in all methods, but document some of them to say that y is ignored. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz
On 07/03/2024 4:16 a.m., Ivan Krylov wrote:
On Wed, 6 Mar 2024 13:46:55 -0500
Duncan Murdoch wrote:
is this just a more or less harmless error, thinking that
the dot needs escaping
I think it's this one. You are absolutely right that the dot doesn't
need escaping in either TRE (which is what's used inside exportPattern)
or PCRE. In PRCE, this regular expression would have worked as intended:
# We do match backslashes by mistake.
grepl('[\\.]', '\\')
# [1] TRUE
# In PCRE, this wouldn't have been a mistake.
grepl('[\\.]', c('\\', '.'), perl = TRUE)
# [1] FALSE TRUE
Thanks, I didn't realize that escaping in PCRE was optional.
So the default exportPattern line could be
exportPattern("^[^.]")
and it would work even if things were changed so that PCRE was used
instead of TRE.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [External] [External] RcmdrPlugin.HH_1.1-48.tar.gz
On 06/03/2024 1:00 p.m., Martin Maechler wrote:
Richard M Heiberger
on Wed, 6 Mar 2024 17:10:50 + writes:
> Thank you, I will do that reversion in a few days.
(good; I'm sorry I did not see this, before I replied to Joshua's)
> Before I do, I want to ask if the default export generated by R CMD
build should be changed.
> the default is exportPattern("."), which seems to be the cause of the
problem.
> Might the default be changed to exportPattern("^[^\\.]") ?
That's a good suggestion in my view.
One thing I don't understand about that suggestion (which is taken from
WRE, I'm not blaming Rich for it): why include the backslash in the
negated character class? Does R ever create variables starting with a
backslash, or is this just a more or less harmless error, thinking that
the dot needs escaping?
Duncan Murdoch
That default *was* sensible when namespaces were
introduced (~ 2004?): It did indeed ensure that the package worked
entirely as before there were namespaces -- always everything
was "exported", i.e. publicly visible and part of the implicit
package API.
And such 100%-backcompatibility was of course sensible to ease
transition. But we are ca. 20 years later now, and I guess that
most active R users (incl package developers) either don't know
or then hardly remember that R had no namespaces originally.
I see it only in the tools pkg hidden writeDefaultNamespace()
which is used only once in tools:::.build_packages()
## add NAMESPACE if the author didn't write one
if(!file.exists(namespace <- file.path(pkgname, "NAMESPACE")) ) {
messageLog(Log, "creating default NAMESPACE file")
writeDefaultNamespace(namespace)
}
Note that the "Bible" on R packages has always been
'Writing R Extensions' - in the R sources, doc/manual/R-exts.texi
It has -- *since* svn rev 23392, 003-02-27 19:02:45 +0100
by Luke Tierney and commit message
"Added name space support for packages that do not use methods."
the text, e.g., at
https://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
For packages with many variables to export it may be more convenient
to specify the names to export with a regular expression using
‘exportPattern’. The directive
exportPattern("^[^\\.]")
exports all variables that do not start with a period. However, such
broad patterns are not recommended for production code: it is better to
list all exports or use narrowly-defined groups. .
so I agree we should change the default.
The R code above shows that the user does get a message about
automatic NAMESPACE creation.
If there are cases, where people need to export even .,
they should have to consciously choose so.
Martin
>> On Mar 6, 2024, at 11:57, Joshua Ulrich wrote:
>>
>> On Wed, Mar 6, 2024 at 1:03 AM Richard M. Heiberger
wrote:
>>>
>>> Thank you Duncan, Jeff, Ivan.
>>>
>>> I did all that Duncan and Jeff suggested, plus a bit more that
appeared to be necessary.
>>> All of what I did is documented in the RcmdrPlugin.HH/NEWS file.
>>>
>>> Ivan's comments were received after I sent 1.1-50 to CRAN and it was
accepted.
>>>
>> I recommend you revert all the changes you made that are documented in
>> the package NEWS, and at minimum follow Ivan's advice to use
>> exportPattern("^[^\\.]") instead of exportPattern("."). It would be
>> even better to follow the advice in Writing R Extensions and list each
>> exported object individually.
>>
>>> I suggest that my notes in the NEWS file, perhaps augmented with
Ivan's comments,
>>> might be added to utils/man/globalVariables.Rd and to the
>>> "
>>> section ‘Package
>>> structure’ in the ‘Writing R Extensions’ manual.
>>> "
>>>
>> That section of Writing R Extensions specifically says not to do what
you did.
>>
>> Beware of patterns which include names starting with a period: some
>> of these are internal-only variables and should never be exported,
>> e.g. ‘.__S3MethodsTable__.’ (and loading excludes known cases).
>>
>> Duncan pointed out that '.__global__' is an internal-only variable
>> created by globalVariables(), which means it should never be exported
>> by a package. Imagine the number of conflicts there would be if every
>> package that used globalVariables() exported the '.__global__'
>> object... there would probably be thousands, yikes!
>>
>
Re: [R-pkg-devel] RcmdrPlugin.HH_1.1-48.tar.gz
On 05/03/2024 5:41 p.m., Richard M. Heiberger wrote: My package is being rejected by auto-check Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64 Check: for missing documentation entries, Result: WARNING Undocumented code objects: '.__global__' All user-level objects in a package should have documentation entries. See chapter 'Writing R documentation files' in the 'Writing R Extensions' manual. The problem is that the string'.__global__' is not in the package. I can't find it and John Fox, the maintainer of Rcmdr, can'f find it. Can someone help me understand why a non-existent string is being detected? That's the variable modified by the `globalVariables()` function. So it may well exist in your package. I'd guess the problem is that your package exports functions by giving a pattern for the names instead of listing each one separately, and it matches that variable. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
On 05/03/2024 2:26 p.m., Dirk Eddelbuettel wrote:
On 5 March 2024 at 13:28, Duncan Murdoch wrote:
| What I'm seeing is that the tags are ignored, and it is distributing the
| HEAD of the main branch. I don't think most users should be using that
| version: in my packages it won't have had full reverse dependency
| checks, I only do that before CRAN releases. And occasionally it hasn't
| even passed R CMD check, though that's not my normal workflow. On the
| other hand, I like that it's available and easy to install, it just
| shouldn't be the default install.
The default behaviour is to build after every commit to the main branch. But
there are options. On the repo I mentioned we use
"branch": "*release",
Where do you put that? I don't see r2u on R-universe, so I guess you're
talking about a different repo; which one?
and now builds occur on tagged releases only. The above is AFAIUI a meta
declaration understood by `remotes`, it was an option suggested by a
colleague. Naming actual branches also works.
| I suppose I could do all development on a "devel" branch, and only merge
| it into the main branch after I wanted to make a release, but then the
| R-universe instructions would be no good for getting the devel code.
It is under your control. You could document how to install via `remotes`
from that branch. As so often, it's about trading one thing off for another.
I do that, but my documentation falls off the bottom of the screen, and
the automatic docs generated by R-universe are at the top.
Duncan
| I don't know anything about dpkg, but having some options available to
| package authors would be a good thing.
Yes but you know {install,available}.packages and have some understanding of
how R identifies and installs packages. I merely illustrated a different use
pattern of giving "weights" to repos. If "we all" want different behaviour,
someone has to site down and write it. Discussing some possible specs and
desired behavior may help.
Dirk
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
On 05/03/2024 1:04 p.m., Dirk Eddelbuettel wrote: On 5 March 2024 at 11:56, Duncan Murdoch wrote: | I have mixed feelings about r-universe. On the one hand, it is really | nicely put together, and it offers the service described above. On the | other, it's probably a bad idea to follow its advice and use | install.packages() with `repos` as shown: that will install development | versions of packages, not releases. Yup. It's a point I raised right at the start as I really do believe in curated releases but clearly a lot of people prefer the simplicity of 'tagging a release' at GitHub and then getting a build. What I'm seeing is that the tags are ignored, and it is distributing the HEAD of the main branch. I don't think most users should be using that version: in my packages it won't have had full reverse dependency checks, I only do that before CRAN releases. And occasionally it hasn't even passed R CMD check, though that's not my normal workflow. On the other hand, I like that it's available and easy to install, it just shouldn't be the default install. I suppose I could do all development on a "devel" branch, and only merge it into the main branch after I wanted to make a release, but then the R-universe instructions would be no good for getting the devel code. r-universe is indeed good at what it does and reliable. There are limited choices in 'driving' what you can do with it. We rely quite heavily on it in a large project for work. As each 'repo' can appear only once in a universe, we resorted to having the 'offical' build follow GitHub 'releases', as well as (optional, additional) builds against a the main branch from another universe. This example is for a non-CRAN package. With CRAN packages, r-universe can be useful too. For some of my packages, I now show multiple 'badges' at the README: for the released CRAN version as well as for the current 'rc' in the main branch sporting a differentiating final digit. RcppArmadillo had a pre-releases available to test that way for a few weeks til the new release this week. So in effect, this gives you what `drat` allows yet also automagically adds builds. It's quite useful when you are careful about it. | Do you know if it's possible for a package to suggest the CRAN version | first, with an option like the above only offered as a pre-release option? In the language of Debian and its dpkg and tools, one solution to that would be 'repository pinning' to declare a 'value' on a repository. There, the default is 500, and e.g. for r2u I set this to 700 as you usually want its versions. We do not have this for R, but it could be added (eventually) as a new value in PACKAGES, or as a new supplementary attribute. I don't know anything about dpkg, but having some options available to package authors would be a good thing. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
On 05/03/2024 12:08 p.m., Josiah Parry wrote:
My understanding is that the order of CRAN repos available in
`options("repos")` are tried sequentially. So if cran.r-rproject.org
<http://cran.r-rproject.org> is first, that will be tried. If the
package is not available there, the next repository will be tried.
I think that's correct, but as in the example below, the R-universe
repos is usually listed first.
I do appreciate the ease of release to R-universe quite a bit
particularly because you don’t need to vendor rust deps.
Is it really a release if the author doesn't know it happened? I found
out about "my" site dmurdoch.r-universe.dev today, but it seems to have
existed for quite a while.
Duncan Murdoch
On Tue, Mar 5, 2024 at 11:56 AM Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
On 05/03/2024 8:02 a.m., Dirk Eddelbuettel wrote:
>
> On 5 March 2024 at 06:25, Duncan Murdoch wrote:
> | You could make a compatible version of `survivalmodels`
available on a
> | non-CRAN website, and refer to that website in the
> | Additional_repositories field of DESCRIPTION.
>
> Every r-universe sub-site fits that requirement. For this package
Google's
> first hit was https://raphaels1.r-universe.dev/survivalmodels
<https://raphaels1.r-universe.dev/survivalmodels> and it carries
> the same line on install.packages() that Jeroen adds to every page:
>
> install.packages('survivalmodels', repos =
c('https://raphaels1.r-universe.dev <https://raphaels1.r-universe.dev>',
>
'https://cloud.r-project.org <https://cloud.r-project.org>'))
I have mixed feelings about r-universe. On the one hand, it is really
nicely put together, and it offers the service described above. On the
other, it's probably a bad idea to follow its advice and use
install.packages() with `repos` as shown: that will install
development
versions of packages, not releases.
Do you know if it's possible for a package to suggest the CRAN version
first, with an option like the above only offered as a pre-release
option?
Duncan Murdoch
>
> So doing all three of
> - adding a line 'Additional_repositories:
https://raphaels1.r-universe.dev <https://raphaels1.r-universe.dev>'
> - adding a 'Suggests: survivalmodels;
> - ensuring conditional use only as Suggests != Depends
> should do.
>
> | It would be best if you fixed whatever issue caused
survivalmodels to be
> | archived when you do this.
> |
> | Looking here:
> |
https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
<https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html>
> | that appears very easy to do. The source is here:
> | https://github.com/RaphaelS1/survivalmodels/
<https://github.com/RaphaelS1/survivalmodels/> .
>
> The other may even take a PR fixing this going forward.
>
> 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>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
On 05/03/2024 8:02 a.m., Dirk Eddelbuettel wrote:
On 5 March 2024 at 06:25, Duncan Murdoch wrote:
| You could make a compatible version of `survivalmodels` available on a
| non-CRAN website, and refer to that website in the
| Additional_repositories field of DESCRIPTION.
Every r-universe sub-site fits that requirement. For this package Google's
first hit was https://raphaels1.r-universe.dev/survivalmodels and it carries
the same line on install.packages() that Jeroen adds to every page:
install.packages('survivalmodels', repos =
c('https://raphaels1.r-universe.dev',
'https://cloud.r-project.org'))
I have mixed feelings about r-universe. On the one hand, it is really
nicely put together, and it offers the service described above. On the
other, it's probably a bad idea to follow its advice and use
install.packages() with `repos` as shown: that will install development
versions of packages, not releases.
Do you know if it's possible for a package to suggest the CRAN version
first, with an option like the above only offered as a pre-release option?
Duncan Murdoch
So doing all three of
- adding a line 'Additional_repositories: https://raphaels1.r-universe.dev'
- adding a 'Suggests: survivalmodels;
- ensuring conditional use only as Suggests != Depends
should do.
| It would be best if you fixed whatever issue caused survivalmodels to be
| archived when you do this.
|
| Looking here:
|
https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html
| that appears very easy to do. The source is here:
| https://github.com/RaphaelS1/survivalmodels/ .
The other may even take a PR fixing this going forward.
Dirk
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggesting an archived package in the DESCRIPTION file
On 05/03/2024 5:58 a.m., Yohann Foucher wrote: Dear R-Members, I just have submitted an update of the ‘survivalSL' package because the last version depends on the ‘survivalmodels’ package, which has been recently archived. In the DESCRIPTION file of the new version 0.93 of the ‘survivalSL' package, I've moved ‘survivalmodels' from "Depends" to the ‘Suggests'. I thought this would solve the problem. Indeed, the 'survivalSL’ package can function without the ‘survivalmodels’ package if the user does not include the related learner (survival neural network) in the learning ensemble. Nevertheless, the new version 0.93 was archived again. I’m working on the estimation of a survival neural network without the ‘survivalmodels’ package but this developments will take a long time. During this period, do you have any idea to avoid the archiving of my package? You could make a compatible version of `survivalmodels` available on a non-CRAN website, and refer to that website in the Additional_repositories field of DESCRIPTION. It would be best if you fixed whatever issue caused survivalmodels to be archived when you do this. Looking here: https://cran-archive.r-project.org/web/checks/2024/2024-03-02_check_results_survivalmodels.html that appears very easy to do. The source is here: https://github.com/RaphaelS1/survivalmodels/ . Alternatively, you could just drop the functions that depend on survivalmodels completely, and drop it as a Suggested package. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN checks for release of a package with new vignette engine
Could you show us the install and check logs for the problematic platform? I don't think you'd get to the message you quote unless the install succeeded, so I think your diagnosis of the problem isn't right. But maybe I'm wrong about that, and the install failed, perhaps because the Quarto tools were not available. Duncan Murdoch On 26/02/2024 10:34 a.m., Christophe Dervieux wrote: Hi, I am trying to release a new version of the quarto R package. This new version is adding support for a new vignette engine that will use quarto CLI (https://quarto.org) when available. The vignettes inside the package itself are '.qmd' files built with quarto. While developing the feature, I noticed that R CMD check will query for vignette engines information, and it will find engine in already installed package (with `tools:::vignetteEngine`). So a package adding a new engine, and using this engine for its vignette only works when the package is installed before check. Automated checks works ok on `r-devel-windows-x86_64`, but fails on `r-devel-linux-x86_64-debian-gcc` because of this note Check: package vignettes, Result: NOTE Package has 'vignettes' subdirectory but apparently no vignettes. Perhaps the 'VignetteBuilder' information is missing from the DESCRIPTION file? I believe this happens because the package is not installed, so when R CMD Check is doing the vignette checking, it won't find the quarto vignette engine. I am trying to understand what I could do for this package release, considering checks are ok on windows r-devel, and only having the NOTE on debian environment. Should I consider this a false positive for this specific case ? Is there any consideration to take for adding a new engine ? Thank you Christophe Dervieux [[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] CRAN Package Check Note: Warning: trimming empty
On 23/02/2024 12:04 p.m., Sunmee Kim wrote: Hello everyone, I encountered a note in the CRAN package check results for the package I submitted and need some guidance on how to address it. The note appears under two flavors: r-devel-linux-x86_64-debian-clang, r-devel-linux-x86_64-debian-gcc. The specific issue details are: Check Details Version: 1.0.4 Check: HTML version of manual Result: NOTE Found the following problems: gesca.run.Rd:127:1: Warning: trimming empty gesca.run.Rd:153:1: Warning: trimming empty gesca.run.Rd:163:1: Warning: trimming empty Could anyone provide insights or suggestions on how to resolve this warning? What is in that file at those locations? Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package required but not available: ‘arrow’
If you look on the CRAN check results for arrow, you'll see it has errors on the Linux platforms that use clang, and can't be installed there. For you to deal with this, you should make arrow into a suggested package, and if it is missing, work around that without generating an error. Another choice would be to work with the arrow developers to get it to install on the systems where it fails now, but it's a big package, so that would likely be a lot harder. Duncan Murdoch On 21/02/2024 5:15 p.m., Park, Sung Jae wrote: Hi, I’m writing to seek assistance regarding an issue we’re encountering during the submission process of our new package to CRAN. The package in question is currently working smoothly on R CMD check on Windows; however, we are facing a specific error when running R CMD check on Debian. The error message we’ve got from CRAN is as follows: ``` ❯ checking package dependencies ... ERROR Package required but not available: ‘arrow’ See section ‘The DESCRIPTION file’ in the ‘Writing R Extensions’ manual. ``` We have ensured that the ‘arrow’ package is properly listed in DESCRIPTION file under the ‘Imports:’. Could you please provide guidance on how to resolve this? Any help will be valuable. Thank you in advance. Best, --Sungjae [[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] Conversion failure in 'mbcsToSbcs'
Removing (or moving to inst) the unrecognized file should be sufficient.
Duncan Murdoch
On 19/02/2024 7:27 a.m., Package Maintainer wrote:
Hello all:
Thank you both for your advice.
I attempted to upload the latest version to CRAN, and again received
the notification that the package did not pass.
It seems there are no warnings or errors (only 2 notes) on windows
(https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240219_122904/Windows/00check.log)
and debian
(https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240219_122904/Debian/00check.log).
One of the notes is simply stating that the package has been archived
(which occurred even when I contacted folks before the deadline). The
other note I can fix easily (an unrecognized file type in the main
directory).
The only error delineated to me appears to be from a submission back
in November 2023
(https://cran-archive.r-project.org/web/checks/2023/2023-11-14_check_results_ggenealogy.html).
Is there anything particular I should do? >
Thank you.
Kind regards,
LAR
On Sat, Feb 17, 2024 at 1:18 PM Duncan Murdoch wrote:
At line 66 of your document, you have this chunk:
<>=
rm(list=ls())
@
That removed the device. You need to put its definition after that.
(It might also need to come earlier if you're doing plotting before
this, and again even later if you remove it again.)
By the way, I'd recommend using knitr for Rnw documents instead of
Sweave. It will require a few changes, but in general it's more
flexible and works a bit better.
Duncan Murdoch
On 17/02/2024 7:51 a.m., Package Maintainer wrote:
Dear Ivan:
Thank you for your help again.
Thanks for your suggestion to use cairo_pdf() instead of pdf() to
allow for the multi-lingual plots.
I incorporated your advice and added the the code you suggested:
<>=
my.Swd <- function(name, width, height, ...)
grDevices::cairo_pdf(
filename = paste(name, "pdf", sep = "."),
width = width, height = height
)
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}
as shown in lines 49-56 in my new vignette file here
(https://github.com/lindsayrutter/ggenealogy/blob/master/vignettes/ggenealogy.Rnw).
Upon attempting to build (R CMD build ggenealogy), I received the ERROR:
Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
object 'my.Swd' not found
--- failed re-building ‘ggenealogy.Rnw’
I tried replacing the code you suggested to various locations and
separating the \SweaveOpts line to be located at separate locations.
However, I received the same ERROR each time.
Do you have any suggestions or ideas on how to resolve this error?
I again thank you for your help with this issue.
Kind regards,
LAR
On Thu, Feb 15, 2024 at 3:17 PM Ivan Krylov wrote:
В Mon, 12 Feb 2024 16:01:27 +
Package Maintainer пишет:
Unfortunately, I received a reply from the CRAN submission team
stating that my vignette file is still obtaining the "mbcsToSbcs"
ERROR as is shown here
(https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240212_152455/Debian/00check.log).
I am sorry for leading you down the wrong way with my advice. It turns
out that no 8-bit Type-1 encoding known to pdf() can represent both
'Lubomír Kubáček' and 'Anders Ågren':
lapply(
setNames(nm = c(
'latin1', 'cp1252', 'latin2', 'latin7',
'latin-9', 'CP1250', 'CP1257'
)), function(enc)
iconv(enc2utf8(c(
'Lubomír Kubáček', 'Anders Ågren'
)), 'UTF-8', enc, toRaw = TRUE)
) |> sapply(lengths)
# one of the two strings cannot be represented, returning a NULL:
# latin1 cp1252 latin2 latin7 latin-9 CP1250 CP1257
# [1,] 0 0 15 0 0 15 0
# [2,] 12 12 0 12 12 0 12
While it may still be possible to give extra parameters to pdf() to use
a font encoding that covers all the relevant characters, it seems
easier to switch to cairo_pdf() for your multi-lingual plots. Place the
following somewhere in the beginning of the vignette:
<>=
my.Swd <- function(name, width, height, ...)
grDevices::cairo_pdf(
filename = paste(name, "pdf", sep = "."),
width = width, height = height
)
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}
This should define a new plot device function for Sweave, one that
handles more Unicode characters correctly.
PS: Thanks for the advice about plain text mode. Hopefully, I have
correctly abide by that advice in this current email.
This e-mail arrived in plain text, thank you!
--
Best regards,
Ivan
__
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] Conversion failure in 'mbcsToSbcs'
At line 66 of your document, you have this chunk:
<>=
rm(list=ls())
@
That removed the device. You need to put its definition after that.
(It might also need to come earlier if you're doing plotting before
this, and again even later if you remove it again.)
By the way, I'd recommend using knitr for Rnw documents instead of
Sweave. It will require a few changes, but in general it's more
flexible and works a bit better.
Duncan Murdoch
On 17/02/2024 7:51 a.m., Package Maintainer wrote:
Dear Ivan:
Thank you for your help again.
Thanks for your suggestion to use cairo_pdf() instead of pdf() to
allow for the multi-lingual plots.
I incorporated your advice and added the the code you suggested:
<>=
my.Swd <- function(name, width, height, ...)
grDevices::cairo_pdf(
filename = paste(name, "pdf", sep = "."),
width = width, height = height
)
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}
as shown in lines 49-56 in my new vignette file here
(https://github.com/lindsayrutter/ggenealogy/blob/master/vignettes/ggenealogy.Rnw).
Upon attempting to build (R CMD build ggenealogy), I received the ERROR:
Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
object 'my.Swd' not found
--- failed re-building ‘ggenealogy.Rnw’
I tried replacing the code you suggested to various locations and
separating the \SweaveOpts line to be located at separate locations.
However, I received the same ERROR each time.
Do you have any suggestions or ideas on how to resolve this error?
I again thank you for your help with this issue.
Kind regards,
LAR
On Thu, Feb 15, 2024 at 3:17 PM Ivan Krylov wrote:
В Mon, 12 Feb 2024 16:01:27 +
Package Maintainer пишет:
Unfortunately, I received a reply from the CRAN submission team
stating that my vignette file is still obtaining the "mbcsToSbcs"
ERROR as is shown here
(https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240212_152455/Debian/00check.log).
I am sorry for leading you down the wrong way with my advice. It turns
out that no 8-bit Type-1 encoding known to pdf() can represent both
'Lubomír Kubáček' and 'Anders Ågren':
lapply(
setNames(nm = c(
'latin1', 'cp1252', 'latin2', 'latin7',
'latin-9', 'CP1250', 'CP1257'
)), function(enc)
iconv(enc2utf8(c(
'Lubomír Kubáček', 'Anders Ågren'
)), 'UTF-8', enc, toRaw = TRUE)
) |> sapply(lengths)
# one of the two strings cannot be represented, returning a NULL:
# latin1 cp1252 latin2 latin7 latin-9 CP1250 CP1257
# [1,] 0 0 15 0 0 15 0
# [2,] 12 12 0 12 12 0 12
While it may still be possible to give extra parameters to pdf() to use
a font encoding that covers all the relevant characters, it seems
easier to switch to cairo_pdf() for your multi-lingual plots. Place the
following somewhere in the beginning of the vignette:
<>=
my.Swd <- function(name, width, height, ...)
grDevices::cairo_pdf(
filename = paste(name, "pdf", sep = "."),
width = width, height = height
)
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}
This should define a new plot device function for Sweave, one that
handles more Unicode characters correctly.
PS: Thanks for the advice about plain text mode. Hopefully, I have
correctly abide by that advice in this current email.
This e-mail arrived in plain text, thank you!
--
Best regards,
Ivan
__
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] Package failing reverse dependency checks
On 08/02/2024 4:24 a.m., David Hugh-Jones wrote:
Hi all,
I'm trying to upload a new version of my "huxtable" package. It is
currently failing reverse dependency checks for two packages (homnormal and
RSStest). The relevant failures are below.
I got this failure one time, and fixed the problem, which relates to
mistakenly relying on the Suggested: knitr package (see here for the
commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
commit, reverse dependency checks for homnormal and RSStest pass on my
machine, when testing either with revdepcheck::revdep_check or
tools::check_packages_in_dir, and even when knitr is not installed. But,
after I uploaded the new package to CRAN, the same failure recurred.
My new release candidate had the same version number as the previous one
(which had failed the revdep check, and therefore not been published on
CRAN). Is it possible that CRAN just tested the old version again?
The CRAN policy on re-submission says "Increasing the version number at
each submission reduces confusion so is preferred even when a previous
submission was not accepted."
So yes, I think confusion with the previous submission could have happened.
Duncan Murdoch
If not, then can anyone suggest the best way to debug a revdep check on as
close a setup to the CRAN machines as possible?
Cheers,
David
Git tag for the last CRAN submission:
https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
Info from the CRAN email:
--
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
RSStest, homnormal
Log dir: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
The files will be removed after roughly 7 days.
Pretests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
--
Changes to worse in reverse depends:
Package: homnormal
Check: examples
New result: ERROR
Running examples in ‘homnormal-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: Brown_Forsythe
> ### Title: Brown-Forsythe Test for Homogeniety
> ### Aliases: Brown_Forsythe
>
> ### ** Examples
>
> data(FH_data)
>x1=FH_data$SurvivalTime
>x2=FH_data$HospitalNo
>Brown_Forsythe(x1,x2)
Error in loadNamespace(x) : there is no package called ‘knitr’
Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
Execution halted
Package: RSStest
Check: examples
New result: ERROR
Running examples in ‘RSStest-Ex.R’ failed
The error most likely occurred in:
> base::assign(".ptime", proc.time(), pos = "CheckExEnv")
> ### Name: teststat_MRSS
> ### Title: Median Ranked Set Sampling Test
> ### Aliases: teststat_MRSS
>
> ### ** Examples
>
> x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
> x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
> teststat_MRSS(x1,x2,tn=1000)
Error in loadNamespace(x) : there is no package called ‘knitr’
Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
Execution halted
[[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] Native pipe in package examples
On 25/01/2024 12:38 p.m., Henrik Bengtsson wrote:
On Thu, Jan 25, 2024 at 8:27 AM Duncan Murdoch wrote:
On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch wrote:
On 25/01/2024 10:27 a.m., Josiah Parry wrote:
Hey all,
I've encountered use of the native pipe operator in the examples for
'httr2' e.g.
request("http://example.com;) |> req_dry_run()
Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?
I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.
I think that the package should state it requires R (>= 4.1.0), since
that code won't work in earlier versions.
I believe it's a syntax error before 4.1.0, but don't have a copy handy
to test.
Yes, support for the |> syntax was introduced in R 4.1.0;
$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.0.5’
Error: unexpected '>' in "1:10 |>"
Execution halted
$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.1.0’
[1] 55
That means the package won't pass R CMD check in those old
versions. If it wasn't a syntax error, just a case of using a new
feature, then I think it would be fine to put in a run-time test of the
R version to skip code that won't run properly.
There's also the distinction of package code versus code in
documentation. If it's only example code in help pages that use the
native pipe, but the code in R/*.R does not, then the package will
still install and work with R (< 4.1.0). The only thing that won't
work is when the user tries to run the code in the documented
examples. I'd argue that it's okay to specify, say, R (>= 3.6.0) in
such an example. It allows users with older versions to still use the
package, while already now migrating the documentation to use newer
syntax.
Is there a way to do that so that R will pay attention, or do you mean
just saying it in a comment?
As a "comment".
I think you're right that syntax errors in help page examples will be
installable, but I don't think there's a way to make them pass "R CMD
check" other than wrapping them in \dontrun{}, and I don't know a way to
do that conditional on the R version.
I think
$ R CMD check --no-examples --no-vignettes ...
would check everything else but examples and vignettes.
I would say that a package that doesn't pass "R CMD check" without
errors shouldn't be trusted.
Somewhat agree, but we still get some "trust" from the fact that the
package passes R CMD check --as-cran on R (>= 4.1.0). Also, if the
maintainer documents something like "On R (> 4.1.0), the package
passes 'R CMD check --no-examples ...'; we use R (>= 4.1.0)-specific
syntax in some of the help-age examples", then there's additional
"trust" in it's working there. But, yes, there's less "trust" here,
but I think it's okay for maintainers to declare "R (>= 3.6.0)" to be
backward compatible. Another way to put it, it would be extreme to
require "R (>= 4.1.0)" just because of a single "1:3 |> sum()" in some
example code.
/Henrik
PS. Personally, I'd skip the use of |> in examples to avoid these concerns.
I think we agree. If I was determined to support 3.6.0 users, I'd
recode that example as
req_dry_run(request("http://example.com;))
# It is convenient to use the native pipe |> in R 4.1.0 or greater:
# request("http://example.com;) |> req_dry_run()
# ... or the magrittr pipe if available:
# request("http://example.com;) %>% req_dry_run()
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Native pipe in package examples
On 25/01/2024 11:44 a.m., Josiah Parry wrote:
The package of course passes R CMD check otherwise it wouldn’t be on
CRAN! (:
CRAN doesn't run checks using R 3.6.0. The package claims it works
there, and maybe it will, but it won't pass R CMD check.
Duncan Murdoch
Thank you Henrik! Good to know my intuition was correct. I’m glad we can
start to use the new features of R in package documentation :)
On Thu, Jan 25, 2024 at 11:27 Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
> On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
>>
>> On 25/01/2024 10:27 a.m., Josiah Parry wrote:
>>> Hey all,
>>>
>>> I've encountered use of the native pipe operator in the
examples for
>>> 'httr2' e.g.
>>>
>>> request("http://example.com <http://example.com>") |> req_dry_run()
>>>
>>>
>>> Since r-oldrel (according to rversions::r_oldrel()) is now
4.2.3, can the
>>> native pipe be used in example code?
>>>
>>> I do notice that the package httr2 requires R >= 3.6.0 which
implies that
>>> the code itself does not use the native pipe, but the examples do.
>>
>> I think that the package should state it requires R (>= 4.1.0),
since
>> that code won't work in earlier versions.
>>
>> I believe it's a syntax error before 4.1.0, but don't have a
copy handy
>> to test.
>
> Yes, support for the |> syntax was introduced in R 4.1.0;
>
> $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> [1] ‘4.0.5’
> Error: unexpected '>' in "1:10 |>"
> Execution halted
>
> $ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
> [1] ‘4.1.0’
> [1] 55
>
>> That means the package won't pass R CMD check in those old
>> versions. If it wasn't a syntax error, just a case of using a new
>> feature, then I think it would be fine to put in a run-time test
of the
>> R version to skip code that won't run properly.
>
> There's also the distinction of package code versus code in
> documentation. If it's only example code in help pages that use the
> native pipe, but the code in R/*.R does not, then the package will
> still install and work with R (< 4.1.0). The only thing that won't
> work is when the user tries to run the code in the documented
> examples. I'd argue that it's okay to specify, say, R (>= 3.6.0) in
> such an example. It allows users with older versions to still
use the
> package, while already now migrating the documentation to use newer
> syntax.
Is there a way to do that so that R will pay attention, or do you mean
just saying it in a comment?
I think you're right that syntax errors in help page examples will be
installable, but I don't think there's a way to make them pass "R CMD
check" other than wrapping them in \dontrun{}, and I don't know a
way to
do that conditional on the R version.
I would say that a package that doesn't pass "R CMD check" without
errors shouldn't be trusted.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Native pipe in package examples
On 25/01/2024 11:18 a.m., Henrik Bengtsson wrote:
On Thu, Jan 25, 2024 at 7:48 AM Duncan Murdoch wrote:
On 25/01/2024 10:27 a.m., Josiah Parry wrote:
Hey all,
I've encountered use of the native pipe operator in the examples for
'httr2' e.g.
request("http://example.com;) |> req_dry_run()
Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?
I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.
I think that the package should state it requires R (>= 4.1.0), since
that code won't work in earlier versions.
I believe it's a syntax error before 4.1.0, but don't have a copy handy
to test.
Yes, support for the |> syntax was introduced in R 4.1.0;
$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.0.5’
Error: unexpected '>' in "1:10 |>"
Execution halted
$ Rscript --vanilla -e "getRversion()" -e "1:10 |> sum()"
[1] ‘4.1.0’
[1] 55
That means the package won't pass R CMD check in those old
versions. If it wasn't a syntax error, just a case of using a new
feature, then I think it would be fine to put in a run-time test of the
R version to skip code that won't run properly.
There's also the distinction of package code versus code in
documentation. If it's only example code in help pages that use the
native pipe, but the code in R/*.R does not, then the package will
still install and work with R (< 4.1.0). The only thing that won't
work is when the user tries to run the code in the documented
examples. I'd argue that it's okay to specify, say, R (>= 3.6.0) in
such an example. It allows users with older versions to still use the
package, while already now migrating the documentation to use newer
syntax.
Is there a way to do that so that R will pay attention, or do you mean
just saying it in a comment?
I think you're right that syntax errors in help page examples will be
installable, but I don't think there's a way to make them pass "R CMD
check" other than wrapping them in \dontrun{}, and I don't know a way to
do that conditional on the R version.
I would say that a package that doesn't pass "R CMD check" without
errors shouldn't be trusted.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Native pipe in package examples
On 25/01/2024 10:27 a.m., Josiah Parry wrote:
Hey all,
I've encountered use of the native pipe operator in the examples for
'httr2' e.g.
request("http://example.com;) |> req_dry_run()
Since r-oldrel (according to rversions::r_oldrel()) is now 4.2.3, can the
native pipe be used in example code?
I do notice that the package httr2 requires R >= 3.6.0 which implies that
the code itself does not use the native pipe, but the examples do.
I think that the package should state it requires R (>= 4.1.0), since
that code won't work in earlier versions.
I believe it's a syntax error before 4.1.0, but don't have a copy handy
to test. That means the package won't pass R CMD check in those old
versions. If it wasn't a syntax error, just a case of using a new
feature, then I think it would be fine to put in a run-time test of the
R version to skip code that won't run properly.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Does dependencies up to date on the pretest CRAN infrastructure
I don't know if you can find out which rtkore version was installed, but your package should work with any rtkore version if you haven't declared a dependency on a particular version. So the simplest thing is just to declare that you depend on "rtkore (>= x.y.z)" where x.y.z has the recent fix. Duncan Murdoch On 12/01/2024 1:09 p.m., Serge wrote: I'm the mainteneur of the package MixAll. This package has a dependency to the package rtkore (whom I'm the mainteneur too). I updated the package rtkore one month ago, fixing a compilation problem on windows devel platform. MixAll has a dependency to rtkore. Thus, I suspect that the error reported below is due to the presence of the old version of rtkore on the pretest infrastructure of the CRAN. My question: is-it possible to know what is the version of rtkore installed on this pretest platform ? (and the https://win-builder.r-project.org/ site too, as I get the same error on this site). Il would certainly save me many tries, my suspicion should be true. Thanks, Serge Dear maintainer, package MixAll_1.5.4.tar.gz does not pass the incoming checks automatically, please see the following pre-tests: Windows: <https://win-builder.r-project.org/incoming_pretest/MixAll_1.5.4_20240108_094228/Windows/00check.log> Status: 1 ERROR Debian: <https://win-builder.r-project.org/incoming_pretest/MixAll_1.5.4_20240108_094228/Debian/00check.log> Status: 1 NOTE Last released version's CRAN status: OK: 1, NOTE: 8, WARNING: 2, ERROR: 1 See: <https://CRAN.R-project.org/web/checks/check_results_MixAll.html> CRAN Web: <https://cran.r-project.org/package=MixAll> 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/MixAll_1.5.4_20240108_094228/> The files will be removed after roughly 7 days. __ 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] Suggests with non-CRAN packages
On 10/01/2024 10:53 a.m., Dirk Eddelbuettel wrote: On 10 January 2024 at 16:25, Uwe Ligges wrote: | | | On 10.01.2024 15:35, Josiah Parry wrote: | > Thanks, all. As it goes, the package submission failed. The package that | > is suggested is available at https://r.esri.com/bin/ | > <https://r.esri.com/bin/> and as such provided `https://r.esri.com | > <https://r.esri.com>` as the url in `Additional_repositories`. | | There is no | | https://r.esri.com/src | | hence it is obviously not a standard repository. And how to set one up is described very patiently over ten pages in Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data at https://journal.r-project.org/archive/2017/RJ-2017-026/index.html And for the impatient, see the drat "Quick Start" instructions at https://github.com/eddelbuettel/drat They work really well! Thanks Dirk! Duncan Murdoch which does Abstract Data-only packages offer a way to provide extended functionality for other R users. However, such packages can be large enough to exceed the package size limit (5 megabytes) for the Comprehen sive R Archive Network (CRAN). As an alternative, large data packages can be posted to additional repostiories beyond CRAN itself in a way that allows smaller code packages on CRAN to access and use the data. The drat package facilitates creation and use of such alternative repositories and makes it particularly simple to host them via GitHub. CRAN packages can draw on packages posted to drat repositories through the use of the ‘Additonal_repositories’ field in the DESCRIPTION file. This paper describes how R users can create a suite of coordinated packages, in which larger data packages are hosted in an alternative repository created with drat, while a smaller code package that interacts with this data is created that can be submitted to CRAN. for the use case of a 'too large for CRAN' suggested data package | > The request was to remove the additional repositories and provide | > instructions for package installation in the Description field. This | > package, arcgisbinding, is used in one line of the entire package | > https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123 <https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123> to extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation instructions for which arelengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html <https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>) and /only /available as a windows binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use. | | So you can either remove the need for that package or say something like | " and if an authorization token is to be extracted on Windows, the | 'arcgisbinding' package is needed that can be installed as explained at | <https://r.esri.com>." Additional_repositories is great, and you have 134 examples at CRAN: D <- data.table(tools::CRAN_package_db()) D[is.na(Additional_repositories)==FALSE, .(Package, Additional_repositories)] Package Additional_repositories 1:archiDART https://archidart.github.io/drat/ 2: aroma.core https://henrikbengtsson.r-universe.dev,\nhttps://r-forge.r-project.org 3: asteRisk https://rafael-ayala.github.io/drat/ 4:BayesfMRI https://inla.r-inla-download.org/R/testing 5:bigDM https://inla.r-inla-download.org/R/stable --- 130:TreatmentPatterns https://ohdsi.github.io/drat 131: TreeDist https://ms609.github.io/packages/ 132: triplesmatch https://errickson.net/rrelaxiv/ 133: USA.state.boundaries https://iembry.gitlab.io/drat/ 134: voi https://inla.r-inla-download.org/R/stable/ Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggests with non-CRAN packages
On 10/01/2024 9:35 a.m., Josiah Parry wrote: Thanks, all. As it goes, the package submission failed. The package that is suggested is available at https://r.esri.com/bin/ <https://r.esri.com/bin/> and as such provided `https://r.esri.com <https://r.esri.com>` as the url in `Additional_repositories`. I don't see a source package there, only .zip files. Those are only going to work on Windows, and only on the R versions you've prepared it for. If the suggested package is only on that platform, I'd suggest removing it from "Suggests", and just describe what it does and how to use it in a vignette or help page. If you really want to keep it in Suggests, but don't want to describe installation in the way that was recommended to you, then take the other route, and put it in an "Additional_repositories" repository as I suggested last week -- but this time make sure to use a properly formatted repository, not just a web site with some binary builds. The "drat" package makes building one of those really easy. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Assigning an object to the global environment (shiny package)
On 04/01/2024 3:51 p.m., Tiago Olivoto wrote:
Hi everyone!
I which a happy new year!
I'm coding a shiny app and I would like to include an option so that the
users can assign the results to the global environment for further analysis.
I have written the following code, which checks if 'globalvarname' (the
name of object to be created in the global environment) already exists,
returning an error if so, and asking to the user change the name.
code
---
observeEvent(input$savetoglobalenv, {
### more code here
if (exists(input$globalvarname, envir = globalenv())) {
sendSweetAlert(
session = session,
title = "Error",
text = paste0("The object'", input$globalvarname, "' already exists
in the global environment. Please, change the name."),
type = "success"
)
} else {
assign(input$globalvarname, report, envir = globalenv())
ask_confirmation(
inputId = "myconfirmation",
type = "warning",
title = "Close the App?",
text = paste0("The object'", input$globalvarname, "' has been created
in the Global environment. To access the created object, you need first to
stop the App. Do you really want to close the app now?"),
btn_labels = c("Nope", "Yep"),
btn_colors = c("#FE642E", "#04B404")
)
}
})
-
Thus, the object is only created when the user decides to assign such an
object to the global environment. As the object's name is checked, there is
no way of replacing some object already available in the global environment.
Of course, when running devtools::check(), a NOTE is returned
Found the following assignments to the global environment:
Arquivo 'plimanshiny/R/mod_analyze.R':
Can I ignore this safely?
Is there any suggestion to handly this without using 'assign()'
A simple alternative would be to assign it into a private environment
managed by your app, and supply a function to the user to retrieve it
from there. The user can choose where to assign the result of that
function.
So instead of:
user says to save to "myvar"
you save to myvar
user uses myvar
you would have
user says to save value
you save it privately
user runs myvar <- savedvalue()
If your app requires users to be able to save several different values,
the user could enter a name on the first line and enter it again on the
third line.
Duncan Murdoch
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] [Rd] static html vignette
On 04/01/2024 11:43 a.m., Adrian Dușa wrote:
> (Moved here following Ivan's suggestion)
>
> On Thu, Jan 4, 2024 at 12:55 PM Ivan Krylov
wrote:
>
>> On Thu, 4 Jan 2024 11:57:15 +0200
>> Adrian Dușa wrote:
>>
>>> I wonder if it would be possible to include an html static vignette.
>>
>> I would say that static vignettes are against the spirit of vignettes:
>> the idea is to provide another layer of unit testing to the package by
>> providing a deeper executable example than is possible with just Rd
>> examples. I think that Bioconductor will even refuse a package with a
>> vignette with no executable code in it.
>>
>
> I understand that perfectly, but for instance my package declared already
> has over 800 tests and 100% code coverage. More unit testing in the
> vignettes really strikes as unnecessary.
>
> One other reason to use a static vignette, in my case, is that package
> Sweave is not available for my version of R (on MacOS, M2 version)
As far as I know, there is no package called Sweave, there's just the
Sweave() function in the utils package.>
>
>
>> Still, you can ue the R.rsp package to provide static vignettes in
>> both PDF and HTML formats:
>>
>>
https://cran.r-project.org/package=R.rsp/vignettes/R_packages-Static_PDF_and_HTML_vignettes.pdf
>>
>> This will add 6 packages to your total Suggests budget:
>>
>> setdiff(
>> unlist(package_dependencies('R.rsp', recursive=TRUE)),
>> unlist(standard_package_names())
>> )
>> # [1] "R.methodsS3" "R.oo""R.utils" "R.cache" "digest"
>
>
> Yes indeed, I know about R.rsp.
> To me at least, zero dependency means that users install that package and
> that package alone, the reason for which I am now looking for static
> (preferably html) vignettes.
>
> I guess another question is why should the "Suggests" packages need to be
> installed by end users. I understand CRAN checks need to make sure the
> Vignettes can be processed and the code inside runs fine (just like the
> examples in the Rd files) but it is very unlikely that end-users will
want
> to compile the vignettes themselves.
>
> From my own experience of almost 20 years of using R, I never-ever build
> the vignettes of a certain package because it is much simpler to read
them
> on CRAN. I wonder, then, why are end users forced to install
> Vignette-building "Suggests" packages (with long dependency chains) when
> they practically never do that.
>
> Life would be much simpler if the Suggests packages would not be
> (automatically) installed, or if CRAN provided a way to include static
> Vignettes to avoid the heavy dependencies of building them.
>
Users aren't forced to install "Suggests" packages. That's a choice
they make. The default for `install.packages()` is `dependencies = NA`,
which says to install hard dependencies (Imports, Depends, LinkingTo).
Users have to choose a non-default setting to include Suggests.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Suggests with non-CRAN packages
On 03/01/2024 11:33 a.m., Josiah Parry wrote:
I have a scenario where I have an exported function that requires the
installation a package that *is not* available on CRAN. The body of the
function is generally:
fx <- function() {
rlang::check_installed("noncranpkg")
noncranpkg::gx()
}
As required, this package is in the Suggests field. But this results in a
note:
checking package dependencies ... NOTE
Package suggested but not available for checking: ‘noncranpkg’
Can this be safely ignored?
Uwe said yes, and he's an authority. But for your users, it might be
nice to include an Additional_repositories field so they can find the
package. This needs to be organized as an actual repository; the drat
package is a very convenient way to set one up.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?
I don't know what the warning looks like, but the ?tar help page discusses the issues. Duncan Murdoch On 12/12/2023 3:10 p.m., Ben Bolker wrote: FWIW the R-windows FAQ says: Yet another complication is a 260 character limit on the length of the entire path name imposed by Windows. The limit applies only to some system functions, and hence it is possible to create a long path using one application yet inaccessible to another. It is sometimes possible to reduce the path length by creating a drive mapping using subst and accessing files via that drive. As of Windows 10 version 1607 and R 4.3, one can remove this limit via Windows registry by setting Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1. Long paths still may not always work reliably: some applications or packages may not be able to work with them and Windows cannot execute an application with long path as the current directory. I'm having trouble finding the specific check for path lengths > 100 in the R source tree. It would be helpful to have the exact wording of the NOTE/WARNING (?) that is thrown ... (I know I could make my own mini-package with a long path length in it somewhere but ...) cheers Ben Bolker On 2023-12-12 2:57 p.m., Simon Urbanek wrote: Justin, now that you clarified what you are actually talking about, this is a question about the CRAN policies, so you should really direct it to the CRAN team as it is their decision (R-devel would be appropriate if this was a limitation in R itself, and R-package-devel would be appropriate if you wanted help with refactoring to adhere to the policy). There are still path limits on various platforms (even if they are becoming more rare), so I'd personally question the source rather than the policy, but then your email was remarkably devoid of any details. Cheers, Simon On Dec 13, 2023, at 6:03 AM, McGrath, Justin M wrote: When submitting a package to CRAN, it is required that path names be shorter than 100 bytes, with the reason that paths longer than that cannot be made into portable tar files. This error is reported by `R CMD check --as-cran`. Since this pertains only to developing packages, this seemed like the appropriate list, but if you don't think so, I can instead ask on R-devel. Best wishes, Justin From: Martin Maechler Sent: Tuesday, December 12, 2023 10:13 AM To: McGrath, Justin M Cc: r-package-devel@r-project.org Subject: Wrong mailing list: [R-pkg-devel] Could the 100 byte path length limit be lifted? McGrath, Justin M on Tue, 12 Dec 2023 15:03:28 + writes: We include other software in our source code. It has some long paths so a few of the files end up with paths longer than 100 bytes, and we need to manually rename them whenever we pull in updates. The 100 byte path limit is from tar v7, and since POSIX1.1988, there has not been a path length limit. That standard is 35 years old now, so given that there is probably no one using an old version of tar that also wants to use the latest version of R, could the 100 byte limit be lifted? Incidentally, I am a big proponent of wide, long-term support, but it's hard to see that this change would negatively impact anyone. Best wishes, Justin Wrong mailing list: This is a topic for R-devel, not at all R-package-devel, but be more accurate in what you are talking about, only between the line I could read that it is about some variants of using 'tar'. Best regards, Martin --- Martin Maechler ETH Zurich and R Core team __ 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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] vignette with "Run Examples"
On 12/12/2023 2:24 a.m., Sigbert Klinke wrote: Hi, is it possible to get a button or link to run an example in a vignette like we see for the examples in the R help? Others have explained why this is hard. An alternative might be to run the examples when you produce your vignette, but hide the results until a button is pressed to display them. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Virtual C++ functions
On 15/11/2023 4:37 a.m., Michael Meyer via R-package-devel wrote: Greetings, Suppose I wanted to develop a package with C++ code that contains virtual functions which the package user should define.It's assumed that evaluation is expensive so we do not want to define these in R and then call these R-functions from C++. Is this a reasonable idea with a standard solution?Are there packages that do this? Thanks in advance for all answers, I think you would be better off having your package evaluate R functions. If that's too slow, the user could use Rcpp or hand programming to put most of the computation into C++ or C code. It seems unlikely the overhead of passing the results from the user's C++ code through R would be significant if the computations themselves were slow. On the other hand, the user has the opportunity of prototyping in R, which may turn out to be fast enough. To get the prototyping possibility with your approach, you'd need to write and maintain two interfaces: C++ to C++ and C++ to R. One situation where this might be worth the trouble would be if you expect the user's function to be fast, but your code needs to call it a huge number of times, so the overhead adds up. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package submission issue - OMP reduction (flang-new)
On 14/11/2023 9:38 a.m., Tomas Kalibera wrote: I would definitely look for a work-around. In the end we want to give users software that works, rather than something that doesn't, but telling them, possibly with good evidence, that it is not our fault. Fortune nomination! __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package submission fail
On 10/11/2023 1:35 p.m., Christiaan Pieterse wrote:
Good day development team, I trust this email finds you well.
I am trying to upload a package onto CRAN. Note that this is a second
version of an existing package on CRAN, called iopspackage. I have built
the package using the R CMD build function and checked the function using R
CMD check --as cran--. The check yields 3 notes. 2 of them are regarding
run time and big file sizes, which is expected and I can't fix since it is
external functions used in my package that take that much time and a big
example file required.
You will have to fix the run time. Try running the example on a smaller
dataset, or don't run it at all (by putting it in \donttest{}). The file
size may be acceptable to CRAN; you will need to make an argument to
them in your upload.
The note about the "\_" entries comes from "country\_codes\_V202201"
(and similar). That's not legal Rd syntax. You could use
"\code{country_codes_V202201}" or some other verbatim wrapper.
I see a 4th note, about files Combined_Results.csv and
Combined_Results.xlsx. If those files are produced by an example or
test, they should be in tempdir().
Duncan Murdoch
The 3rd note I do not know how to solve. I submitted
this file but it did not pass the automatic checks. Please see the part
from the CRAN-submission email below, as well as my attached .tar.gz file.
Any assistance to get this package open-source uploaded to CRAN would be
appreciated, thank you!
Kind regards
Christiaan
*CRAN-submission email:*
Dear maintainer,
package iopspackage_2.1.0.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/iopspackage_2.1.0_20231109_155428/Windows/00check.log
Status: 3 NOTEs
Debian: <
https://win-builder.r-project.org/incoming_pretest/iopspackage_2.1.0_20231109_155428/Debian/00check.log
Status: 4 NOTEs
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/iopspackage_2.1.0_20231109_155428/
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-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: NOTE
Maintainer: 'C.J Pieterse '
New submission
Size of tarball: 10537094 bytes
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: Rd files, Result: NOTE
checkRd: (-1) IOPS.Rd:17: Escaped LaTeX specials: \_ \_
checkRd: (-1) IOPS.Rd:36: Escaped LaTeX specials: \_
checkRd: (-1) IOPS.Rd:42: Escaped LaTeX specials: \_
checkRd: (-1) IOPS.Rd:44: Escaped LaTeX specials: \_
checkRd: (-1) IOPS.Rd:46: Escaped LaTeX specials: \_
checkRd: (-1) IOPS.Rd:48: Escaped LaTeX specials: \_ \_
checkRd: (-1) IOPS.Rd:50: Escaped LaTeX specials: \_
Flavor: r-devel-windows-x86_64
Check: examples, Result: NOTE
Examples with CPU (user + system) or elapsed time > 10s
user system elapsed
IOPS 127.61 5.58 133.2
Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: NOTE
Examples with CPU (user + system) or elapsed time > 5s
user system elapsed
IOPS 170.57 2.971 173.549
Flavor: r-devel-linux-x86_64-debian-gcc
Check: for non-standard things in the check directory, Result: NOTE
Found the following files/directories:
'Combined_Results.csv' 'Combined_Results.xlsx'
__
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] The problem with resubmitting the package to the Cran
On 11/11/2023 3:54 a.m., Karolina Marek wrote: Hello, I am writing again about submitting the package to the CRA - per ARMA, which was archived on 2022-05-25, as it required the archived package 'matlab'. The new version of the 'matlab' was resubmitted to the Cran on 2022-06-01. When I try to submit the package, I receive the following NOTES: Checking CRAN incoming feasibility ... NOTE * checking for non-standard things in the check directory ... NOTE Found the following files/directories: ‘PARMA21del1_ident' This time I put also the link to the repository on github: https://github.com/Klona9/r-perARMA.git gh repo clone Klona9/r-perARMA I will be very glad for any help. Your examples for `parma_ident` appear to create a directory named "PARMA21del1_ident" below the current directory. You can't create files there, you need to create them in tempdir(). Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning from orphaned package on check page
I have volunteered to take over maintenance of plotrix. I should be
submitting a version without the "orphaned" designation soon.
(If anyone else would rather be maintainer, please get in touch with me
offline.)
Duncan Murdoch
On 09/11/2023 9:47 a.m., Liam J. Revell wrote:
Thank you Georgi & Ivan for your comments.
Because of the way 'plotrix' is written, it turns out to be very easy to
copy the imported functions into a new source file in my package (let's
say, plotrix_fn.R) and remove the dependency.
What I've actually done is move 'plotrix' to Suggests, and then have R
check to see if plotrix is installed to determine which version of each
function to use. E.g.:
arctext<-if(.check.pkg("plotrix")) plotrix::arctext else Arctext
in which 'arctext' is the function name exported by plotrix and Arctext
is the copy in my package.
I believe this is permitted under GPL-3. Can someone with more
experience in this recommend how the original authors of plotrix should
be properly credited?
Thanks again for this constructive feedback.
All the best, Liam
Liam J. Revell
Professor of Biology, University of Massachusetts Boston
Web: http://faculty.umb.edu/liam.revell/
Book: Phylogenetic Comparative Methods in R (Princeton University Press,
2022)
On 11/9/2023 6:42 AM, Georgi Boshnakov wrote:
You don't often get email from georgi.boshna...@manchester.ac.uk.
Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>
CAUTION: EXTERNAL SENDER
Orphaned packages can't be listed in DEPENDS and IMPORTS fields in
file DESCRIPTION. They can be in SUGGESTS but calls of functions from
them should be guarded, eg with a message to install the offending
package. In examples and tests the usage should be conditional on the
package beinginstalled.
Another option is to take over maintenance of that package. In your
case, with so many dependencies someone may be working on bringing it
back.
Georgi Boshnakov
Sent from Outlook for Android
<https://aka.ms/AAb9ysg>
*From:* R-package-devel on
behalf of Liam J. Revell
*Sent:* Thursday, November 9, 2023 11:30:05 AM
*To:* Alexandre Courtiol
*Cc:* r-package-devel@r-project.org
*Subject:* Re: [R-pkg-devel] Warning from orphaned package on check page
My apologies for the lack of clarity.
plotrix has been orphaned so my package results page now says
checking package dependencies ... WARNING
Requires orphaned package: ‘plotrix’
CRAN incoming requires maintainers to certify: 'I have fixed all
problems shown on the package check page.' Since I can't unorphan
plotrix, I can't certify this statement & thus can't get a new version
of my package on CRAN. Advice on how to proceed is welcomed.
Liam J. Revell
Professor of Biology, University of Massachusetts Boston
Web:
https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$
<https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$>
[faculty[.]umb[.]edu]
Book: Phylogenetic Comparative Methods in R (Princeton University Press,
2022)
On 11/9/2023 4:10 AM, Alexandre Courtiol wrote:
You don't often get email from alexandre.court...@gmail.com. Learn why
this is important
<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXKg7CKCI$
[aka[.]ms]>
CAUTION: EXTERNAL SENDER
Dear Liam,
I don't understand your question: if your package has plotrix listed
as a dependency, it won't affect plotrix.
Only the opposite would be true. Could you please clarify and indicate
which package you are referring to?
Thanks,
Alex
On Thu, 9 Nov 2023 at 09:57, Liam J. Revell wrote:
Dear colleagues.
I'm trying to update a package on CRAN containing a dependency
(specifically, on the popular graphing package 'plotrix') that has
been
orphaned because the maintainer is deceased.
'plotrix' is imported by well over 100 other CRAN packages, so I
hope it
is not removed from CRAN. On the other hand, I don't want to certify
that 'I have fixed all problems shown on the package check page'
if this
is not, in fact, the case.
Can anyone comment on how one might proceed in this situation?
Thank you. -- Liam
--
Liam J. Revell
Professor of Biology, University of Massachusetts Boston
Web:
https://urldefense.com/v3/__http://faculty.umb.edu/liam.revell/__;!!PDiH4ENfjr2_Jw!EUF27KhzseEpywIN0EnjFB_d4JQ9VgFwYWOCrNH1U9F6Bqh9SOqbi57oq38wPjZFM-40ALcQXaITFEjCuIgQOW0aznrXaHjdobg$
<https://urldefense.com/v
Re: [R-pkg-devel] circular suggested packages
On 07/11/2023 2:55 p.m., Thierry Onkelinx wrote: Dear all, The qrcode package converts text into a qrcode image. The opencv package is able to convert images with a qrcode into the text. opencv has a unit test that uses qrcode to generate a test image. Hence it lists qrcode as a suggested package. Would it be OK to implement the same unit test in qrcode? And thus requiring qrcode to list opencv as a suggested package. I know this is not allowed when depending or importing packages. Yes, that is allowed. There was a thread about a related issue just a few days ago: "PkgA imports PkgB, and PkgB suggests PkgA?". Duncan Murdoch Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkel...@inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be /// To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey /// <https://www.inbo.be> [[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-package-devel] Win.Metafile and package check - "Found the platform-specific device:"
On 04/11/2023 5:35 a.m., wayne.w.jo...@shell.com wrote: Update: I noticed in the ggplot2 codebase they also have a call to win.metafile - see https://github.com/tidyverse/ggplot2/blob/main/R/save.R#L280-L281 When I use grDevices::win.metafile instead of win.metafile it passes the local checks fine. That sounds like two bugs in the check code: 1. It complains about win.metafile even though you made its use conditional on being on Windows. 2. It doesn't complain about grDevices::win.metafile. I don't think you said, but this looks like a NOTE rather than a WARNING or ERROR. I'd use the grDevices::win.metafile for now, but wouldn't be surprised if the NOTE turns up again later when #2 gets fixed. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Unclear NOTE for r-devel-linux-x86_64-debian-clang
On 02/11/2023 3:58 a.m., Tony Wilkes wrote: Hi everyone, I updated my package, but found a NOTE for r-devel-linux-x86_64-debian-clang. See https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/tinycodet-00check.html. The NOTE is: checking HTML version of manual ... [3s/5s] NOTE Found the following HTML validation problems: pkgs.html:66:9 (pkgs.Rd:24): Warning: anchor "pkgs" already defined As is often the case, these NOTES do not inform me at all. What does this NOTE entail exactly, and why is the issue only present for Debian? That sounds like a bug in the check code which has been fixed. Do you have a function named pkgs() with an argument also named pkgs? Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons
On 01/11/2023 2:54 p.m., Markus Jochim wrote: Dear Alberto, I have had a small number of CRAN-related email exchanges with Brian Ripley that made it clear that his idea of politeness and my idea of politeness are incompatible. The email you are quoting reminds me very much of these exchanges. My idea of politeness, and I think also Prof. Ripley's, is that you don't discuss private discussions in public without agreement from all parties. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] CRAN archival: Does CRAN un-archive some packages automatically?
On 01/11/2023 12:30 p.m., Henrik Bengtsson wrote: I'm asking here to spare the CRAN Team a direct message, but also because the answer is of interest to others: Consider a package PkgA that was archived on CRAN, because it fails checks and errors that were not corrected in time. At the moment when package PkgA is archived, it will trigger automatic archiving of other CRAN packages that has a hard dependency on it. Say, packages PkgB and PkgC were archived automatically, because of their dependency on PkgA. Question: If PkgA is at a later point revived on CRAN, will CRAN unarchive PkgB and PkgC automatically? Or, should the maintainers of PkgB and PkgC resubmit? If they have to resubmit, should they submit identical versions and tarballs as before, or do they have to bump the version? I don't know the answer to your first question, but I'd guess "no". The maintainers of PkgB and PkgC should have already resubmitted, demoting PkgA to a "Suggests:" dependency or dropping it completely. If they chose not to do that, then at the hypothetical time when PkgA is revived, each of PkgB and PkgC would need full testing to see if they were passing the current versions of the CRAN checks with the new version of PkgA. That's something for their maintainers to do, not CRAN. Regarding your last question: if it turns out the original version still passes with the new PkgA, then I think it's still better to bump the version number. It would need an exception to the usual "new submissions need new version numbers" rule. Exceptions waste CRAN's time. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package bioOED has been removed from CRAN just for personal reasons
On 01/11/2023 8:35 a.m., Tomas Kalibera wrote: On 11/1/23 12:15, Alberto Garre wrote: Dear community, I feel dismay for having to write this email, but the issue must be brought up. On the 20th of October, I received an email from CRAN warning me of an issue with one of the packages I maintain (bioOED). The package depended on MEIGOR, a package that was no longer available in Bioconductor. I was given until 2023-11-03 to fix the issue. I contacted the MEIGOR maintainers and they told me they were migrating to CRAN. Yesterday, they contacted me again, telling me they needed more time for the migration. Hence, I responded to the email I received from CRAN, asking for an extension of the previous deadline (2023-11-03). To my surprise, it is not just that the extension was not granted, but the package has been removed from CRAN today (2023-11-01). Two days before the deadline (2023-11-03): https://cran.r-project.org/package=bioOED Then, I checked my inbox and I saw an email from one of the CRAN maintainers, showing that the package was removed because he had felt offended by my email. I copy-paste the email below. I don't think this is true. The reason is that your package depends on an unavailable package, so cannot be installed. See https://cran.r-project.org/web/packages/bioOED/index.html where the reason is publicly stated. If I were you I'd simply wait once MEIGOR is on CRAN and then publish the archived package again. I agree with that interpretation. A possibly faster alternative would be to remove the dependence on MEIGOR, and resubmit once that is done and the package is working again. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "crossprod" is not a BUILTIN function
There are two kinds of builds: source builds (producing the .tar.gz
file) and binary builds (producing the .zip file on Windows). Binary
builds are specific to R minor versions: if you build on R version
x.y.z, you can't expect the package to work if either x or y changes.
Source builds should work on other R versions, though sometimes moving
to earlier versions will cause problems (because the format of files in
the .tar.gz file may have changed), or your package relies on features
that weren't present earlier. Generally .tar.gz files will work on
later versions (though changes in R might break it).
So if you did a binary build on R 4.4.x and tested it on R 4.3.1, it's
not at all surprising that it failed. If you did a source build on R
4.4.x and it failed on R 4.3.1, that's more surprising.
Duncan Murdoch
On 26/10/2023 9:43 a.m., Plamen Mirazchiyski wrote:
Thank you very much for your responses Duncan and Ivan.
I do not call .Internal(crossprod( ... )) directly. I use crossprod()
just once in the entire package, the actual line of code is
unname(obj = crossprod(x = sweep(x = as.matrix(replicated.averages),
MARGIN = 2, mean.replicate.averages, FUN = "-"))*des.scale.fac)
I followed Ivan's advice, built a binary package from source in R 4.3.1
on Windows 10, then tested it on another Windows 10 machine with R
4.3.1. The problem did not occur et all.
If I understand Ivan's email, my package should work on R 4.3.1, but
what about newer versions? I checked some packages that were released
today, e.g. abn, these were built by CRAN "using R Under development
(unstable) (2023-10-24 r85407 ucrt)". Does this mean mine will fail on
the current released version (4.3.1) if built by CRAN. As far as I see
from the R Developer Page (https://developer.r-project.org), there is a
new version (4.3.2) scheduled for October 31, 2023. Should I better wait
until then?
Best,
Plamen
On 10/25/23 21:26, Ivan Krylov wrote:
В Wed, 25 Oct 2023 21:02:00 +0200
Plamen Mirazchiyski пишет:
Today I was preparing a new version for the RALSA package. I have
built a Windows package using "devtools::check_win_devel()".
The machine has R 4.3.1, the latest official release. After I load the
test RALSA package, R displays a message saying "Package RALSA built
under R version 4.4.0"
Can you use R CMD build to make a .tar.gz source package and then
install that on the Windows 10 machine running R 4.3.1? There is
convenience and a lot of added value in both Win-Builder and devtools,
but it shouldn't be necessary to rely on 96 CRAN packages and an online
service just to build a package.
crossprod(x,y) has indeed been recently changed from
.Internal(crossprod(x, y)) to .Primitive("crossprod"). This makes it
possible for a binary package prepared using R-devel (with a call to
.Primitive('crossprod')) to misbehave on a released version of R (which
does have .Internal(crossprod(...)) but not .Primitive('crossprod')).
Installing from source will avoid this problem. So will building the
binary package using R-4.3.1 to run it on a different machine with
R-4.3.1.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] "crossprod" is not a BUILTIN function
The sources show that crossprod has become a primitive function. I don't think this should affect any R code that calls crossprod(); are you trying to call .Internal(crossprod( ... )) directly? This was in the news a few weeks ago: "The matrix multiplication functions ‘crossprod()’ and ‘tcrossprod()’ are now also primitive and S3 generic, as ‘%*%’ had become in R 4.3.0." Duncan Murdoch On 25/10/2023 3:02 p.m., Plamen Mirazchiyski wrote: Dear All, Today I was preparing a new version for the RALSA package. I have built a Windows package using "devtools::check_win_devel()". I took the built Windows package and tested it on a Windows 10 machine to see if everything works as intended before submitting the source to CRAN. The machine has R 4.3.1, the latest official release. After I load the test RALSA package, R displays a message saying "Package RALSA built under R version 4.4.0", I guess this is what the win-builder uses when the source is sent via "devtools::check_win_devel()". When testing one of the functions of the newly built RALSA package (lsa.corsstabs"), it crashes with the following message: Error in crossprod(x = sweep(x = as.matrix(replicated.averages), MARGIN = 2, : "crossprod" is not a BUILTIN function I checked if it is a builtin by: grep(pattern = "cross", x = builtins(), value = TRUE) This returned: [1] "tcrossprod" "crossprod" I am not sure I understand, the "crossprod" function is in the base package and is builtin in 4.3.1, is it dropped in 4.4.0? If yes, how to overcome this? Please advise. Best, Plamen __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Switch between \dontrun{ } and \donttest{ }.
On 19/10/2023 8:17 p.m., Rolf Turner wrote:
In a package that I maintain, there are examples, in the *.Rd files,
that take an excruciatingly long time to run. This makes package
checking extremely tedious. There is no question of errors being
thrown from these examples, they are simply time consuming. (The check
is being run to look for possible errors elsewhere.)
I therefore would like to wrap these examples in \dontrun{ }.
However when the package is submitted to CRAN, it is expedient to wrap
the examples in \donttest{ } rather than \dontrun{ }.
I would therefore like to find a means of effecting the following
logical structure:
if(package is being checked by CRAN) {
Use \donttest{ }
} else {
Use \dontrun{ }
}
Is there a reasonably straightforward means of detecting whether
the package is being checked by CRAN, and thereby setting up such a
logical structure? Perhaps based on environment variables?
Can anyone give me any guidance? Thanks.
I think the method used by the testthat package is best: assume it is
being run by CRAN, unless an environment variable named NOT_CRAN is set
to "true" (or some string like that). Then set the environment variable
at home, where you know you are not on CRAN.
Duncan
__
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
And if the vignette claims to help the users, but contains errors? Then it's not very helpful at all. That's what the testing is there to detect. Duncan Murdoch On 17/10/2023 6:30 p.m., John Harrold wrote: I ask myself the question: Who is the vignette for? It does server two purposes. One is testing but primarily it's for the users to learn how to use a package. I think the testing is secondary, and if it slows down installation or general usability I'd sacrifice the testing. If it's that important, then the tests can be added explicitly in tests/. On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel wrote: On 18 October 2023 at 08:51, Simon Urbanek wrote: | John, | | the short answer is it won't work (it defeats the purpose of vignettes). Not exactly. Everything is under our (i.e. package author) control, and when we want to replace 'computed' values with cached values we can. All this is somewhat of a charade. "Of course" we want vignettes to run tests. But then we don't want to fall over random missing .sty files or fonts (macOS machines have been less forgiving than others), not to mention compile time. So for simplicity I often pre-make pdf vignettes that get included in other latex code as source. Works great, never fails, CRAN never complained -- which is somewhat contrary to your statement. It is effectively the same with tests. We all want maximum test surfaces. But when tests fail, or when they run too long, or [insert many other reasons here] so many packages run tests conditionally. Such is life. Dirk | However, this sounds like a purely hypothetical question - CRAN policies allow long-running vignettes if they declared. | | Cheers, | Simon | | | > On 18/10/2023, at 3:02 AM, John Fox wrote: | > | > Hello Dirk, | > | > Thank you (and Kevin and John) for addressing my questions. | > | > No one directly answered my first question, however, which was whether the approach that I suggested would work. I guess that the implication is that it won't, but it would be nice to confirm that before I try something else, specifically using R.rsp. | > | > Best, | > John | > | > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote: | >> Caution: External email. | >> On 16 October 2023 at 10:42, Kevin R Coombes wrote: | >> | Produce a PDF file yourself, then use the "as.is" feature of the R.rsp | >> | package. | >> For completeness, that approach also works directly with Sweave. Described in | >> a blog post by Mark van der Loo in 2019, and used in a number of packages | >> including a few of mine. | >> That said, I also used the approach described by John Harrold and cached | >> results myself. | >> 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-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 -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ 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-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
On 17/10/2023 4:21 p.m., John Fox wrote: Hello Simon, On 2023-10-17 3:51 p.m., Simon Urbanek wrote: Caution: External email. John, the short answer is it won't work (it defeats the purpose of vignettes). Thank you for confirming that. However, this sounds like a purely hypothetical question - CRAN policies allow long-running vignettes if they declared. I assume that we'd declare the long-running vignette in our submission note to CRAN. Maybe that's better than pre-building the HTML vignettes in the package. There's also the "BuildVignettes: false" field in DESCRIPTION, but its use is discouraged, and I don't think it allows you to ask CRAN to build some vignettes but not all. Duncan Murdoch Best, John Cheers, Simon On 18/10/2023, at 3:02 AM, John Fox wrote: Hello Dirk, Thank you (and Kevin and John) for addressing my questions. No one directly answered my first question, however, which was whether the approach that I suggested would work. I guess that the implication is that it won't, but it would be nice to confirm that before I try something else, specifically using R.rsp. Best, John On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote: Caution: External email. On 16 October 2023 at 10:42, Kevin R Coombes wrote: | Produce a PDF file yourself, then use the "as.is" feature of the R.rsp | package. For completeness, that approach also works directly with Sweave. Described in a blog post by Mark van der Loo in 2019, and used in a number of packages including a few of mine. That said, I also used the approach described by John Harrold and cached results myself. 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-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problem with "additional repository".
Whoops, I just read the next line. Sorry!
On 15/10/2023 9:34 p.m., Rolf Turner wrote:
I have submitted a new package to CRAN, and this package has been
knocked back on the basis of a NOTE:
* checking package dependencies ... NOTE
Package suggested but not available for checking: 'ionChannelData'
This suggested package consists of data sets, the size of which is too
large to satisfy CRAN's constraints. I put this package in a repository
on github, from which it can be accessed by users.
My DESCRIPTION file contains the line:
Additional_repositories: https://rolfturner.r-universe.dev
The given URL seems to work, in that users can indeed load the
ionChannelData package via the command
install.packages("ionChannelData",repos="https://rolfturner.r-universe.dev;)
I was under the impression that this was all that I needed to do. The
CRAN checking process acknowledges the existence of the repository in
question:
Suggests or Enhances not in mainstream repositories:
ionChannelData
Availability using Additional_repositories specification:
ionChannelData yes https://rolfturner.r-universe.dev
So CRAN knows about this repository. Why can it not make use of it?
What can/should I do to resolve this problem?
I guess I could simply *not* Suggest ionChannelData. But what then, is
the point of the option of including an Additional_repositories field in
the DESCRIPTION file?
cheers,
Rolf Turner
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problem with "additional repository".
On 15/10/2023 9:34 p.m., Rolf Turner wrote:
I have submitted a new package to CRAN, and this package has been
knocked back on the basis of a NOTE:
* checking package dependencies ... NOTE
Package suggested but not available for checking: 'ionChannelData'
This suggested package consists of data sets, the size of which is too
large to satisfy CRAN's constraints. I put this package in a repository
on github, from which it can be accessed by users.
My DESCRIPTION file contains the line:
Additional_repositories: https://rolfturner.r-universe.dev
Is that web site set up as a repository? My impression was that it
needed to be, so people could do
install.packages("ionChannelData", repos =
"https://rolfturner.r-universe.dev;)
You can use the "drat" package to set up a tiny repository quickly.
Duncan
The given URL seems to work, in that users can indeed load the
ionChannelData package via the command
install.packages("ionChannelData",repos="https://rolfturner.r-universe.dev;)
I was under the impression that this was all that I needed to do. The
CRAN checking process acknowledges the existence of the repository in
question:
Suggests or Enhances not in mainstream repositories:
ionChannelData
Availability using Additional_repositories specification:
ionChannelData yes https://rolfturner.r-universe.dev
So CRAN knows about this repository. Why can it not make use of it?
What can/should I do to resolve this problem?
I guess I could simply *not* Suggest ionChannelData. But what then, is
the point of the option of including an Additional_repositories field in
the DESCRIPTION file?
cheers,
Rolf Turner
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Question regarding listing base and recommended packages programmatically and efficiently
It would be much faster (but slightly less reliable) to use list.files(.libPaths()) to get the names of all installed packages, and then filter them to the known list of base and recommended packages, which changes very rarely. Duncan Murdoch On 12/10/2023 8:34 a.m., Tony Wilkes wrote: Dear all, In my R package that I'm developing, I use `installed.packages(priority = "base")` to programmatically get all core/base R packages (i.e. base, stats, etc.). And similarly, I use installed.packages(priority = "recommended")` to programmatically get the recommended R packages (i.e. mgcv, lattice, etc.). However, CRAN has requested to not use `installed.packages()`, as it is slow. I fully get and agree with that assesment. I used installed.packages()` anyway because I could not find a better, fool-proof alternative. Nonetheless, I was asked to change this code for optimalisation. So I would like to ask: how do I programmatically get all base/core R packages safely and efficiently, but without using `installed.packages()`? And the same question for recommended R packages. I have of course Googled it, and looked at R's documentation (though R's documentation is large, so it's easy to miss something); no solution found. So if any of you has a smart idea: I'm all ears. Thank you in advance. Kind regards, Tony. [[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] Question regarding CRAN submission with notes
The note says it contains "an installed version" of the package, presumably referring to your test package. I think you shouldn't do that. For a trivial package it might be true that the installed version is the same on all systems, but it won't continue to be as the installation code evolves. What you could try is to include files that would let you install the test package into a library under tempdir(). Your tests would start by installing the test package there, then run the tests, then clean up afterwards. It's possible the tests will still complain about that, in which case I'd go one step further back, and write a function to create the source package, rather than including it. For example, have a file DESCRIPTION.txt which your test renames to DESCRIPTION, etc. Duncan Murdoch On 11/10/2023 3:06 a.m., Tony Wilkes wrote: Dear all, I'm trying to publish an R package to CRAN. Their checks come back with 2 NOTES. The first one is saying that the package is a new submission, and the second one is that there is a subdirectory with a package inside my package. Both notes are correct. I have explained in my submission comments that this is indeed a new submission. I also gave the following explanation for the second note in my submission comments: "There is 1 NOTE given by the R CMD check results. This is due to the fact that I have placed fake libraries with fake packages inside the "inst/tinytest/" folder. This was necessary to test the various import-system related functions in my package. As stated, these are fake packages, and only contain trivial functions of no consequence. These fake libraries with fake packages ONLY exist because it is necessary for proper and extensive unit testing, that is all." They asked me to fix these notes a few days ago. I replied (politely) repeating my comments a few days ago. I have not heard back from CRAN since. I am assuming that I am missing something, but CRAN won't explain what exactly I am missing. Here are the NOTES: Windows: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2FWindows%2F00check.log=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Xh6fZd6iQjW6AOFtCAwwzhNO%2B5vyCh%2Fy5%2FEi25z7D%2Fg%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/Windows/00check.log>> Status: 1 NOTE Debian: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2FDebian%2F00check.log=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0jOFqYf9Ar%2FBp1YVSZjfRHRdChzGPi5lSSuyLT2HAoM%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/Debian/00check.log>> Status: 2 NOTEs More details are given in the directory: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Ftinycodet_0.1.0.4_20231009_210227%2F=05%7C01%7C%7Ce3fe951ba4c54110abbb08dbc8fb77c2%7C84df9e7fe9f640afb435%7C1%7C0%7C638324754614049791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=73zTGLwQVRlTMnk20rbgTBOn5dCdu16y%2BmhlLS8GIpg%3D=0<https://win-builder.r-project.org/incoming_pretest/tinycodet_0.1.0.4_20231009_210227/>> Could anyone tell me what exactly I'm doing wrong? Thank you in advance. Kind regards, Tony [[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] Error: [writeRaster] cannot write file
On 09/10/2023 6:56 p.m., Keshav, Krishna wrote:
Outdir is either a directory like getwd(), tempdir() etc or empty/null.
If it is empty/null, then I set it to tempdir().
That doesn't answer the question, and the link you provided doesn't
answer it either, as far as I can see. In the test and the vignette
that generated the errors, something specific was passed as outdir. But
what? If it was getwd(), that's bound to fail -- you don't have
permission to write there. tempdir() should have worked, but Berry
pointed out some other things that might be problems.
Duncan Murdoch
/if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()/
/}///
I am not sure how to debug when running it in Rbuilder. But you can look
at results here -
https://builder.r-hub.io/status/geohabnet_1.0.0.tar.gz-a2eaa40ccf1d026bbebf5077bfb482d5 <https://builder.r-hub.io/status/geohabnet_1.0.0.tar.gz-a2eaa40ccf1d026bbebf5077bfb482d5>
Best Regards,
Krishna Keshav
*From: *Duncan Murdoch
*Date: *Monday, October 9, 2023 at 4:08 PM
*To: *Keshav, Krishna , r-package-devel@r-project.org
*Subject: *Re: [R-pkg-devel] Error: [writeRaster] cannot write file
[External Email]
What were you using as "outdir"?
On 09/10/2023 2:59 p.m., Keshav, Krishna wrote:
Hi,
I am developing an R package where I need to save Raster file with .tif
extension to the tempdir(). I am using terra::writeRaster for the same. While
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {
if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
}
# Save the plot as a raster file
fp <- file.path(outdir, paste("plots", "/",
typ, "_",
stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]",
""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
if (!dir.exists(fp)) {
dir.create(fp, recursive = TRUE)
}
terra::writeRaster(rast, overwrite = TRUE,
filename = fp,
gdal = c("COMPRESS=NONE"))
message(paste("raster created", fp, sep = ": "), "\n")
}
Error �V
Error: [writeRaster] cannot write file
12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
13. �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal =
c("COMPRESS=NONE"))
14. �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal =
c("COMPRESS=NONE"))
15. �|�wterra (local) .local(x, filename, ...)
16. �|�wterra:::messages(x, "writeRaster")
17. �|�wterra:::error(f, x@pnt$getError())
Best Regards,
Krishna Keshav
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel=05%7C01%7Ckkeshav%40ufl.edu%7Cddd83781762040d664dc08dbc9038ec7%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638324789348072931%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=mBzV%2BSJoOTTnSpRzu0EvLT8sZ2NJ1OlhSGXqNCvGWB4%3D=0
<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: [writeRaster] cannot write file
What were you using as "outdir"?
On 09/10/2023 2:59 p.m., Keshav, Krishna wrote:
Hi,
I am developing an R package where I need to save Raster file with .tif
extension to the tempdir(). I am using terra::writeRaster for the same. While
it works through R CMD check in mac, it is failing in R hub builder.
Snippet �V
.saverast <- function(typ, rast, outdir) {
if (is.null(outdir) || length(outdir) == 0) {
outdir <- tempdir()
}
# Save the plot as a raster file
fp <- file.path(outdir, paste("plots", "/",
typ, "_",
stringr::str_replace_all(Sys.time(), "[^a-zA-Z0-9]",
""),
".tif", sep = ""))
# Create the "plots" directory if it doesn't exist
if (!dir.exists(fp)) {
dir.create(fp, recursive = TRUE)
}
terra::writeRaster(rast, overwrite = TRUE,
filename = fp,
gdal = c("COMPRESS=NONE"))
message(paste("raster created", fp, sep = ": "), "\n")
}
Error �V
Error: [writeRaster] cannot write file
12. �|�wgeohabnet:::.saverast(typ, rast, outdir)
13. �u�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal =
c("COMPRESS=NONE"))
14. �|�wterra::writeRaster(rast, overwrite = TRUE, filename = fp, gdal =
c("COMPRESS=NONE"))
15. �|�wterra (local) .local(x, filename, ...)
16. �|�wterra:::messages(x, "writeRaster")
17. �|�wterra:::error(f, x@pnt$getError())
Best Regards,
Krishna Keshav
[[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] User defined RNG and code registration.
On 23/09/2023 4:42 a.m., Ralf Stubner wrote: Hi everybody, Section 5.4 of WRE suggests to use `R_useDynamicSymbols(dll, FALSE);` when registering C/C++ routines in R packages, and Rcpp does so automatically. ?Random.user describes a way to hook a user- defined RNG into R. However, it looks like these two things are not compatible, i.e. `user_unif_rand` et al. are not found, if dynamic symbols are not allowed. Or can one register these routines somehow even though they are not following one of the standard calling conventions? I don't know the answer here, but section 6.16 of WRE suggests that you could explicitly make your functions visible even if they default to invisible. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] .OnLoad v .OnAttach
On 22/09/2023 8:35 p.m., Jonathan Godfrey wrote: Hello all, An issue has been raised for my BrailleR package. https://github.com/ajrgodfrey/BrailleR/issues/97#issuecomment-1732136521 I do make use of an .OnLoad() function for various tasks, including creation of a folder to put stuff in. The user gets to choose if this is temporary or fixed if the session is interactive. (all in zzz.R What risks do I face if any of this .OnLoad() are moved to .OnAttach()? If you move code from .onLoad() to .onAttach(), it won't be executed if the user never calls library(BrailleR) or require(BrailleR). (This is a little simplified; there are other ways to attach a package, but they are rarely used. More details on loading vs attaching below.) If some setup is required by functions in your package even if they are called from other packages, it belongs in .onLoad(). A less convenient approach is for those functions to check whether the setup has happened every time you call them, and execute it if not. Here are the details of the differences: Loading makes the exported functions in the package available to other packages that import them, or call them using BrailleR::fn syntax. The latter is also possible for users, and also triggers loading. Once a package is loaded it normally stays loaded for the whole session, so .onLoad() will only be called once. Attaching puts your package on the search list so that exported functions are available to the user without the prefix. It will always be preceded by loading. A user triggers attaching by making calls to library() or require(). If another package "Depends" on BrailleR, then loading that package will cause BrailleR to be attached. The guidelines recommend against this, so most packages will use "Imports" instead. That triggers loading but not attaching. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] roxygen style documentation for data sets
I just found a couple of packages with add-ins that do something like this: sinew (on CRAN) and docthis on Github at https://github.com/mdlincoln/docthis I think neither of them is quite as smooth as the `Code | Insert Roxygen Skeleton` menu item in RStudio, but both do handle dataframes, and it doesn't. Duncan Murdoch On 21/09/2023 4:30 p.m., Michael L Friendly wrote: I am an RStudio user, and I could see this as a plugin somewhere, but I don't want to create a package just for this. I'd rather that my code could be adopted somewhere in the framework of devtools/usethis/ ... It's so obvious that this tool should be there somewhere, particularly since RStudio makes it hard to work with .Rd files, except those generated by devtools (which shouldn't be edited). E.g., I have many legacy .Rd files for data. I can't select example code and click Run, as one can do with roxygen documentation in .R files. -Michael -Original Message- From: Duncan Murdoch Sent: Thursday, September 21, 2023 3:58 PM To: Michael L Friendly ; r-package-devel@r-project.org Subject: Re: [R-pkg-devel] roxygen style documentation for data sets Hi Michael. I don't know if you're an RStudio user, but this seems ideal as the basis for an RStudio plug-in. Just install it, then when you want to generate docs for some dataset defined in R code, move to the start of the definition and hit some hot key to insert the documentation skeleton ahead of the data definition. Duncan Murdoch On 21/09/2023 12:33 p.m., Michael L Friendly wrote: I have many datasets in a some of my packages, and always used `utils::promptData()` to generate the skeleton of a man/data.Rd file. Now that I've switched to roxygen style, I have found no simple equivalent. In fact, with RStudio tools for generating documentation for functions, it is surprising that documenting data has been overlooked. I solved this problem by simply editing `utils::promptData()` to replace .Rd style with equivalent roxygen tags. The result in now in a gist, https://gist.github.com/friendly/14f3ee1464213bb0b9fbcb489468383b I called this function `use_data_doc()`, because I thought it would be a welcome addition to the usethis package. I hope that someone on this list can advise how to make such a function available to all R package developers. -Michael --- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. York University Voice: 416 736-2100 x66249 4700 Keele StreetWeb: http://www.datavis.ca<http://www.datavis.ca/> | @datavisFriendly Toronto, ONT M3J 1P3 CANADA [[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] roxygen style documentation for data sets
Hi Michael. I don't know if you're an RStudio user, but this seems ideal as the basis for an RStudio plug-in. Just install it, then when you want to generate docs for some dataset defined in R code, move to the start of the definition and hit some hot key to insert the documentation skeleton ahead of the data definition. Duncan Murdoch On 21/09/2023 12:33 p.m., Michael L Friendly wrote: I have many datasets in a some of my packages, and always used `utils::promptData()` to generate the skeleton of a man/data.Rd file. Now that I've switched to roxygen style, I have found no simple equivalent. In fact, with RStudio tools for generating documentation for functions, it is surprising that documenting data has been overlooked. I solved this problem by simply editing `utils::promptData()` to replace .Rd style with equivalent roxygen tags. The result in now in a gist, https://gist.github.com/friendly/14f3ee1464213bb0b9fbcb489468383b I called this function `use_data_doc()`, because I thought it would be a welcome addition to the usethis package. I hope that someone on this list can advise how to make such a function available to all R package developers. -Michael --- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. York University Voice: 416 736-2100 x66249 4700 Keele StreetWeb: http://www.datavis.ca<http://www.datavis.ca/> | @datavisFriendly Toronto, ONT M3J 1P3 CANADA [[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] A simple question regarding examples
On 20/09/2023 8:03 p.m., Hanyu Song wrote:
Hello,
I have a simple question about including examples. My code depends on a rarely
used Python module, so I am using the @examplesIf tag per Hadley Wickham's
advice as follows:
#' @examplesIf reticulate::py_module_available('ctef')
#' res <- my_func(input1, input2)
Unfortunately, my_func runs overtime during the CRAN check. To resolve this, do
I simply use the less elegant approach as follows?
#' \dontrun{
#' if (reticulate::py_module_available('ctef')) {
#' res <- my_func(input1, input2)
#' }
The @examplesIf comments are directed at Roxygen; R checks will never
look at them. R will run tests based on what is in the my_func.Rd
examples section. I'd guess that's pretty similar to your second
version (except for the \dontrun part, which you shouldn't use, as Ivan
said).
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
Sorry, I missed the --as-cran option: you run R CMD check --as-cran Duncan Murdoch On 19/09/2023 5:59 a.m., Duncan Murdoch wrote: On 18/09/2023 10:10 a.m., Shu Fai Cheung wrote: Hi All, I know we should not use more than 2 cores in tests, vignettes, etc. I encountered and solved this issue before. However, I still committed this mistake in a new package and would like find out where the cause is. I have a package that already has parallel processing disabled by default and I did not enable parallel processing in the examples and tests (except for one test, which is always skipped by skip()). However, I was told that somewhere in the package more than 2 cores are used. I checked several times and even added a temporary 'stop()` to "trap" parallel processing but still could not find where the source of the problem is. I checked the timing in the log in R CMD check results from winbuilder but everything seems OK. The user time and elapsed time are similar for all the examples. Is there any quick way to check where things go wrong regarding the number of cores? It is not easy to find the source of the problems when there are many examples and tests. If you run R CMD check at the command line, it will produce a directory *.Rcheck containing a number of files. One of those files will be *-Ex.timings, which will give the individual timings of each of the examples in your package. Maybe you can recognize from those which of the examples are problematic ones, and add `proc.time()` calls to the example to figure out which line(s) cause the issue. I don't remember whether winbuilder keeps the timings file when it runs a check. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Checking the number of cores used
On 18/09/2023 10:10 a.m., Shu Fai Cheung wrote: Hi All, I know we should not use more than 2 cores in tests, vignettes, etc. I encountered and solved this issue before. However, I still committed this mistake in a new package and would like find out where the cause is. I have a package that already has parallel processing disabled by default and I did not enable parallel processing in the examples and tests (except for one test, which is always skipped by skip()). However, I was told that somewhere in the package more than 2 cores are used. I checked several times and even added a temporary 'stop()` to "trap" parallel processing but still could not find where the source of the problem is. I checked the timing in the log in R CMD check results from winbuilder but everything seems OK. The user time and elapsed time are similar for all the examples. Is there any quick way to check where things go wrong regarding the number of cores? It is not easy to find the source of the problems when there are many examples and tests. If you run R CMD check at the command line, it will produce a directory *.Rcheck containing a number of files. One of those files will be *-Ex.timings, which will give the individual timings of each of the examples in your package. Maybe you can recognize from those which of the examples are problematic ones, and add `proc.time()` calls to the example to figure out which line(s) cause the issue. I don't remember whether winbuilder keeps the timings file when it runs a check. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R Package Development -- PDF Manual without Index
On 02/09/2023 2:50 p.m., John Carter Hall wrote: Hello R-Package-Devel Mailing List, I am new to R package development, and am having to limp a project across the line after my organization has gone through significant changes in recent weeks. As such, I am emailing to understand what I can do to solve an error I am having: The Error Flavor: r-devel-linux-x86_64-debian-gcc Check: PDF version of manual without index, Result: ERROR The Issue For whatever reason, the R CMD check desires different fields in the DESCRIPTION file than does the devtools::check() function (particularly w.r.t. the 'Author' field), and so I have to use devtools to build/check the package. The devtools::build_manual function, however, does not work, and so I am forced to utilize Rd2pdf to create my PDF manual. CRAN will use R CMD check, so if things aren't working there, they won't accept your package. I have to make the manual via Windows due to issues with an Ubuntu installation of my package. However, the package is intended for Linux/Debian audiences. What I Need Help With I believe I have the manual created. I do not know if this manual needs to be created when CRAN does their checks, but I have the document (I am comparing its appearance to the manual of ggplot2, and the structure is similar). I do not know where it needs to be located. I have tried the root directory of the package, the doc folder, etc... but nothing works. You don't need to make a manual at all. CRAN will do that for you. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] DESCRITION error
If you are on Ubuntu, my guess is likely not relevant (unless maybe the server holding your files is running Windows). Duncan Murdoch On 30/08/2023 12:32 p.m., Emanuele Cordano wrote: Thanks . I’m working on Linux Ubuntu 20.04. I’m seeing the url you sent. Il giorno mer 30 ago 2023 alle 18:23 Duncan Murdoch mailto:murdoch.dun...@gmail.com>> ha scritto: On 30/08/2023 12:03 p.m., Emanuele Cordano wrote: > Dear list, > > I'm creating a package. At a first build, I found out the following error. > I parsed DESCRIPTION file and I did not find any possible causes for this > error. I searched on the web , but I found no clear explanation of this > error. Have you ever experienced with this? What does this error mean ? > I'm using an Rstudio server, but it's the first time it happens after > building several other developed packages. > > > Error reading package DESCRIPTION: system error 71 (Protocol error) That error says that R couldn't read the DESCRIPTION file. It sounds as though you are on Windows, your file is on a network share, and the server won't let you connect. If that's the case, this link discusses the issue: https://answers.microsoft.com/en-us/windows/forum/all/operating-system-error-71-this-remote-computer-has/74270db8-4522-4e24-a494-5bf75becc9da <https://answers.microsoft.com/en-us/windows/forum/all/operating-system-error-71-this-remote-computer-has/74270db8-4522-4e24-a494-5bf75becc9da> -- Emanuele Cordano, PhD Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr. 3587 (Albo A - Provincia di Trento) cell: +39 3282818564 email: emanuele.cord...@gmail.com <mailto:emanuele.cord...@gmail.com>,emanuele.cord...@rendena100.eu <mailto:emanuele.cord...@rendena100.eu>, emanuele.cord...@eurac.edu <mailto:emanuele.cord...@eurac.edu> PEC: emanuele.cord...@ingpec.eu <mailto:emanuele.cord...@ingpec.eu> URL: www.rendena100.eu <http://www.rendena100.eu/> LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333 <https://www.linkedin.com/in/emanuele-cordano-31995333> GitHub: https://github.com/ecor <https://github.com/ecor> __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] DESCRITION error
On 30/08/2023 12:03 p.m., Emanuele Cordano wrote: Dear list, I'm creating a package. At a first build, I found out the following error. I parsed DESCRIPTION file and I did not find any possible causes for this error. I searched on the web , but I found no clear explanation of this error. Have you ever experienced with this? What does this error mean ? I'm using an Rstudio server, but it's the first time it happens after building several other developed packages. Error reading package DESCRIPTION: system error 71 (Protocol error) That error says that R couldn't read the DESCRIPTION file. It sounds as though you are on Windows, your file is on a network share, and the server won't let you connect. If that's the case, this link discusses the issue: https://answers.microsoft.com/en-us/windows/forum/all/operating-system-error-71-this-remote-computer-has/74270db8-4522-4e24-a494-5bf75becc9da __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Re-building vignettes had CPU time 9.2 times elapsed time
On 25/08/2023 6:13 p.m., Toby Hocking wrote: Thanks Dirk. I agree. data.table is not in a situation to update very soon, so the easiest solution for the R community would be for CRAN to set OMP_THREAD_LIMIT to 2 on the Windows and Debian machines doing this test. Otherwise the 1400+ packages with hard dependencies on data.table will each have to implement custom logic to limit threads to 2. That doesn't follow. data.table could update soon even if that wasn't their intention: just include bug fixes and set the default OMP_THREAD_LIMIT to 2 in data.table. The real problem is that there are two stubborn groups opposing each other: the data.table developers and the CRAN maintainers. The former think users should by default dedicate their whole machine to data.table. The latter think users should opt in to do that. Duncan Murdoch Toby On Fri, Aug 25, 2023 at 6:46 AM Dirk Eddelbuettel wrote: On 24 August 2023 at 07:42, Fred Viole wrote: | Hi, I am receiving a NOTE upon submission regarding the re-building of | vignettes for CPU time for the Debian check. | | I am unable to find any documented instances or solutions to this issue. | The vignettes currently build in 1m 54.3s locally and in 56s on the Win | check. | | https://win-builder.r-project.org/incoming_pretest/NNS_10.1_20230824_132459/Debian/00check.log Please see, inter alia, the long running thread "Trouble with long-running tests on CRAN debian server" started earlier this week (!!) on this list covering exactly this issue. We can only hope CRAN comes to understand our point that _it_ should set a clearly-identifable variable (the OpenMP thread count would do) so that package data.table can this for its several hundred users. As things currently stand, CRAN expects several hundred packages (such as your, guessing there this comes from data.table which I do not know for sure but you do import it) to make the change which is pretty close to the text book definition of madness. Also see https://github.com/Rdatatable/data.table/issues/5658 with by now 24 comments. It is on the same issue. Uwe, Kurt: Please please please set OMP_THREAD_LIMIT to 2 on the Windows and Debian machines doing this test. 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-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] Setting valgrind options when running R CMD check --use-valgrind
On 23/08/2023 2:54 p.m., Dirk Eddelbuettel wrote:
When I invoke valgrind via
R -d valgrind -e '...'
the options in the file ~/.valgrindrc are being picked up. Good.
When I invok valgrind via
R CMD check --use-valgrind ...
the options in the file ~/.valgrindrc are NOT being picked up. Bad.
And valgrind complains. How can I add the needed options? Adding
--debugger-args=""
does not work. Is there another trick?
I don't know the answer to your question, but here's something to try.
There's a way to run an "R CMD check" equivalent from a regular session,
so presumably it could be done from "R -d valgrind -e":
tools:::.check_packages(c("pkg", "--option1", "--option2"))
A likely problem is that many of the check tests are run in separate
processes; I don't know if the valgrind setting would be inherited or not.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] possible solution to package-documentation-alias problem
When you get a note from CRAN, remember that it ignores Roxygen comments
completely. It's just looking at the files that Roxygen produces. So
you should look at the .Rd files when you get a complaint about them.
Your previous code would have produced a file named plan.Rd, and that
file didn't include the "plan-package" alias that was requested. The
new version does, so things are now fine. I think that up until a few
years ago, the old version would have worked, but this news item from
2019 hints at the change:
"Using @docType package no longer automatically adds -name. Instead
document _PACKAGE to get all the defaults for package documentation, or
use @name to override the default file name."
Duncan Murdoch
On 19/08/2023 8:54 a.m., Daniel Kelley wrote:
# Preamble
This email is to tell other developers what I did to address an issue with
documenting a package. I'm not sure that I am correct in my approach --
comments would definitely be appreciated -- but at least this email is fairly
concrete about the changes I made. To be honest, I don't know how to test
whether my changes are suitable, since no problem is reported in local builds or
in remote windows checks, and no problem is listed on the CRAN tests page.
# The problem
Today I received multiple emails from K. Hornik, telling me about problems with
the package-level documentation for several CRAN packages that I maintain. Here
is a key part of that email:
You have file 'oce/man/oce.Rd' with \docType{package}, likely intended as a
package overview help file, but without the appropriate PKGNAME-package
\alias as per "Documenting packages" in R-exts.
# Possible solution
As a test (using the 'plan' package, which is much smaller and thus ought to
give faster test results), I changed my Roxygen2 block
#' @name plan
#' @docType package
#' @author Dan Kelley
NULL
to read
#' @name plan
#' @docType package
#' @author Dan Kelley
#' @keywords internal
"_PACKAGE"
## usethis namespace: start
## usethis namespace: end
NULL
Note that the two ## comments are likely not required, but I included them
because I saw them at
https://github.com/jonesor/mpmsim/commit/e8d0f0d657ffa24c25ddd3165c7ddcad16322e3d
which I found to be quite a helpful resource.
# Local testing
After rebuilding locally, I can now do
package?plan
and get the expected documentation for the package as a whole.
# CRAN submission
I submitted the update to CRAN, and it has appeared as a tarball. It has not
yet appeared in built-up packages sources, but perhaps the fact that I didn't
get any warnings from CRAN suggests that the flaw has been addressed.
# Conclusions
If I am right, a simple fix is all that will be required for many packages.
However, I don't know of any way to know if this fix follows recommended
procedures. There appear to be multiple ways of addressing the issue.
Perhaps other developers will have better solutions than the one I've outlined
above. Or, if I happen to have done something right, then perhaps this email
will be of some use to other developers.
Dan Kelley / Department of Oceanography / Dalhousie University / Canada
__
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] Changes to checks on NEWS?
On 26/07/2023 10:18 a.m., J C Nash wrote:
Thanks for the info, though it seems odd that CRAN wants to
parse a plain text file that is purely for information, since it
should have no impact on the current package or any other. I suppose
there might be character set issues to check. The motive for parsing
it eludes me.
Does anyone know if there are plans to use NEWS for some purpose in
the future i.e., to actually track changes beyond package maintainer's
comments?
NEWS has been used for a long time by the utils::news() function, which
in turn is used by the HTML help system.
Duncan Murdoch
Cheers, and thanks again.
JN
On 2023-07-26 10:03, Ivan Krylov wrote:
В Wed, 26 Jul 2023 09:37:38 -0400
J C Nash пишет:
I'd like to avoid NOTEs if possible, and since I'm using a plain-text
NEWS, don't believe this should trigger one.
Plain-text NEWS files are parsed according to the rules specified in
help(news), which is admittedly laconic in its description. If you run
tools:::.news_reader_default('https://cran.r-project.org/web/packages/optimx/NEWS')
(or news(package = 'optimx')), you can see that R's news() already
misunderstands some of the contents of your NEWS file.
A relatively recent change (r82543, July 2022) set
_R_CHECK_NEWS_IN_PLAIN_TEXT_=TRUE for R CMD check --as-cran and started
verifying that R's plain text "news reader" function could actually
parse plain-text NEWS files without warnings or errors.
I think that if you rename NEWS to ChangeLog, R will leave the file
alone, but CRAN will offer it to users as plain text.
__
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] Package PowerSDI NOTES
On 18/07/2023 12:37 p.m., Gabriel Constantino Blain wrote: Dears, I submitted my R package to CRAN. However, it didn't pass the CRAN checks because of 2 notes: Note 1: Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64 Check: CRAN incoming feasibility, Result: NOTE Maintainer: 'Gabriel Constantino Blain ' New submission Possibly misspelled words in DESCRIPTION: EP (14:45) NASAPOWER (11:18) OperatSDI (12:9) PowerSDI (7:18, 13:9) SPEI (3:31, 7:50, 10:20) SPI (3:23, 7:42, 10:12) ScientSDI (9:19) evapotranspitation (13:44) subperiods (15:76) Note 2: Flavor: r-devel-windows-x86_64 Check: examples, Result: NOTE Examples with CPU (user + system) or elapsed time > 10s user system elapsed ScientSDI 82.71 0.75 88.00 Reference 29.75 0.05 29.80 Accuracy 10.02 1.11 11.12 Flavor: r-devel-linux-x86_64-debian-gcc Check: examples, Result: NOTE Examples with CPU (user + system) or elapsed time > 5s user system elapsed ScientSDI 52.674 0.176 57.765 Reference 20.749 0.148 20.898 Accuracy 6.001 0.024 6.024 Regarding note 1, not all the words are misspelled, EP, SPI and SPEI are acronyms OperatSDI and ScientSDI are functions of my package PowerSDI is the name of my package's name NASAPOWER is the project's name. Writing R Extensions section 1.1.1 describes some rules for quoting non-English words. I think they imply OperatSDI, ScientSDI and PowerSDI should be in single quotes. I am not sure whether that also applies to your other non-English words. Duncan Murdoch Regarding note 2, I don't know what's wrong. Is it related to the time to run the examples (>5s)? If is it so, it is not an error. There are so many calculations that it does take some time to do it. The package is available at https://github.com/gabrielblain/PowerSDI I really appreciate any help you can provide. Best regards Gabriel [[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] Feedback on "Using Rust in CRAN packages"
On 13/07/2023 7:19 p.m., Hadley Wickham wrote: If CRAN cannot trust even the official one of Rust, why does CRAN have Rust at all? I don't see the connection - if you downloaded something in the past it doesn't mean you will be able to do so in the future. And CRAN has Rust because it sounded like a good idea to allow packages to use it, but I can see that it opened a can of worms that we trying to tame here. Can you give a bit more detail about your concerns here? Obviously crates.io isn't some random site on the internet, it's the official repository of the Rust language, supported by the corresponding foundation for the language. To me that makes it feel very much like CRAN, where we can assume if you downloaded something in the past, you can download something in the future. That last statement is true, but also sort of false: you should be able to download the same version of the package that you downloaded last time, but you might not be able to download a version of the package that works with the current version of R. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help with a github/Rstudio mess
I think this isn't the right place to ask for this sort of help. Maybe
stackoverflow instead?
What I'd do in this case is to rename the local dir holding the
repository, then clone a new copy from Github. Assuming that works,
compare all the files to make sure that you have all recent changes,
commit any that were missed, then throw away the damaged one.
Duncan Murdoch
On 05/07/2023 4:44 a.m., Chris Evans wrote:
I hope this is a legitimate question here. I have a package of very
simple functions: https://github.com/cpsyctc/CECPfuns. For the forseeable
future it's really only to stop me constantly having to rewrite
functions I use and it is only also used by probably two or three
colleagues who
also use R and are even less IT/programming/R competent than I am and
are very happy to use my functions.
I hadn't done any work on it for two years but came back to it yesterday
and added a function (getCIforQuantiles). There were warnings about
things that are deprecated now in some of the older functions but
otherwise things seemed OK. However, I got a pkgdown error and warning
after
pushing the updated package to github:
Annotations
1 error and 1 warning
pkgdown
Failed to get R 4.3.1: Failed to get R 4.3.1: Failed to download version
4.3.1: Error: Unexpected HTTP response: 404
r-lib/actions/setup-r@v1 is deprecated.
r-lib/actions/setup-r@v1 is deprecated. Please update your workflow to
use the 'v2' version. Also look at the examples at
https://github.com/r-lib/actions/tree/v2/examples because '@v2'
workflows are much simpler than 'v1' workflows.
So I tweaked
https://github.com/cpsyctc/CECPfuns/blob/main/.github/workflows/pkgdown.yaml
to change
- uses: r-lib/actions/setup-r@v1
to
- uses: r-lib/actions/setup-r@v2
rather optimistically hoping that might make the warning go away.
Today I did some work on the new function (trivial, correcting one
"!is.na(" to the correct "is.na(" !!!). More importantly, I created the
test-getCIforQuantiles.R file for testthat to test the sanity checks and
add three simple output checks.
I built the source package locally, committed the changes and tried to
push the update to github (inside Rstudio) but I get:
>>> /usr/bin/git push origin HEAD:refs/heads/main
To https://github.com/cpsyctc/CECPfuns.git
! [rejected] HEAD -> main (fetch first)
error: failed to push some refs to 'https://github.com/cpsyctc/CECPfuns.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
OK. So I try to pull thinking that made sense and that the change to
pkgdown.yaml on github that I made yesterday is the offending change.
However, when I pull (in Rstudio again) I get this:
>>> /usr/bin/git pull
fatal: pack has 6 unresolved deltas
fatal: fetch-pack: invalid index-pack output
I have never felt on top of the complexities of git and github but I'm
clearly way out of my depth. I am hoping someone here can see what
I need to do to get things back in synch and be able to get back to
developing the package.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Public URLs for help for versions of base packages
I agree, really nice. One suggestion would be to check for the existence of the corresponding topic link. For example, <https://hughjonesd.github.io/r-help/2.9.0/graphics/plot.html> links to <https://stat.ethz.ch/R-manual/R-patched/library/graphics/html/plot.html>, which doesn't exist. The generic is now in the base package, at <https://stat.ethz.ch/R-manual/R-patched/library/base/html/plot.html>. Duncan Murdoch On 30/06/2023 11:37 a.m., Ben Bolker wrote: Nice! (I like "A longer description will go here eventually.") It would be cute/handy to have navigation links available for "go to this help page in the next (previous) version of R" (if it's not a huge pain) On 2023-06-30 11:10 a.m., David Hugh-Jones wrote: OK, so I took Jeff's hint and did this myself! https://github.com/hughjonesd/r-help Sample page for ?plot from the first version of R (at least, the first version that is on svn): https://hughjonesd.github.io/r-help/0.60/base/plot.html Not everything is guaranteed to work, so please report bugs if you find any. Cheers, David On Fri, 30 Jun 2023 at 13:23, David Hugh-Jones wrote: There are plenty of places to find current docs. I think it’s fine to have versioned ones also. I agree it would be a good idea to clearly signal “hey, this is an old version” - indeed I’ve been bitten by that in python before. I’m working on this now… will see what I can do. Does anyone happen to know if it’s possible to create 00index files without installing the relevant package? (Loading R 0.60 is challenging…) D On Fri, 30 Jun 2023 at 13:02, Duncan Murdoch wrote: On 30/06/2023 7:57 a.m., David Hugh-Jones wrote: Static web pages get indexed by google. Isn't that an argument against having static pages? If I do a Google search for "R lm" I think it's better to find the current docs rather than dozens of obsolete versions. It's rare that someone wants to see changes across versions, so doing that should take extra work. Duncan Murdoch David On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch mailto:murdoch.dun...@gmail.com>> wrote: Why store them? Download the source on demand, and convert it. Seems pretty simple. Duncan Murdoch On 30/06/2023 1:19 a.m., David Hugh-Jones wrote: > This is for the rcheology package. I run a Shiny web app which lets you > examine changes to functions across R versions: > > https://hughjonesd.shinyapps.io/rcheology/ <https://hughjonesd.shinyapps.io/rcheology/> > > Manually storing and converting the Rd might be possible, but it would be > burdensome in terms of data (and my time). And if the Rd spec has changed > across versions, that’s another problem. > > More generally, shouldn’t there be publicly available versioned > documentation? Python has had this for a long time. > > David > > > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller mailto:jdnew...@dcn.davis.ca.us>> > wrote: > >> Sure. On your computer. Install the old version of R and let it serve the >> relevant docs. >> >> Dunno of anyone doing this historical dive online for you though. Why >> would you want preformatted docs if you didn't have those old versions >> installed? >> >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones < >> davidhughjo...@gmail.com <mailto:davidhughjo...@gmail.com>> wrote: >>> That’s useful to know. But is there anywhere with preformatted HTML pages? >>> >>> Cheers, D >>> >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov mailto:krylov.r...@gmail.com>> wrote: >>> >>>> On Thu, 29 Jun 2023 20:22:47 +0100 >>>> David Hugh-Jones mailto:davidhughjo...@gmail.com>> wrote: >>>> >>>>> I'm looking for a source of online help for R base >>>>> packages, which covers all versions (for some reasonable value of >>>>> "all"). So e.g. the equivalent of `?lm` for R 4.1.0. >>>> >>>> These live in the R source tree, under src/library: >>>> https://svn.r-project.org/R/trunk/src/library/ <https://svn.r-project.org/R/trunk/src/library/> >>>> >>>> For the actual releases of R, you may have to go looking at the >>>> branches inside that repository, e.g., the following command: >>>> >>>> svn log \ >>>>
Re: [R-pkg-devel] Public URLs for help for versions of base packages
On 30/06/2023 7:57 a.m., David Hugh-Jones wrote: Static web pages get indexed by google. Isn't that an argument against having static pages? If I do a Google search for "R lm" I think it's better to find the current docs rather than dozens of obsolete versions. It's rare that someone wants to see changes across versions, so doing that should take extra work. Duncan Murdoch David On Fri, 30 Jun 2023 at 09:55, Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote: Why store them? Download the source on demand, and convert it. Seems pretty simple. Duncan Murdoch On 30/06/2023 1:19 a.m., David Hugh-Jones wrote: > This is for the rcheology package. I run a Shiny web app which lets you > examine changes to functions across R versions: > > https://hughjonesd.shinyapps.io/rcheology/ <https://hughjonesd.shinyapps.io/rcheology/> > > Manually storing and converting the Rd might be possible, but it would be > burdensome in terms of data (and my time). And if the Rd spec has changed > across versions, that’s another problem. > > More generally, shouldn’t there be publicly available versioned > documentation? Python has had this for a long time. > > David > > > On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller mailto:jdnew...@dcn.davis.ca.us>> > wrote: > >> Sure. On your computer. Install the old version of R and let it serve the >> relevant docs. >> >> Dunno of anyone doing this historical dive online for you though. Why >> would you want preformatted docs if you didn't have those old versions >> installed? >> >> On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones < >> davidhughjo...@gmail.com <mailto:davidhughjo...@gmail.com>> wrote: >>> That’s useful to know. But is there anywhere with preformatted HTML pages? >>> >>> Cheers, D >>> >>> On Thu, 29 Jun 2023 at 21:46, Ivan Krylov mailto:krylov.r...@gmail.com>> wrote: >>> >>>> On Thu, 29 Jun 2023 20:22:47 +0100 >>>> David Hugh-Jones mailto:davidhughjo...@gmail.com>> wrote: >>>> >>>>> I'm looking for a source of online help for R base >>>>> packages, which covers all versions (for some reasonable value of >>>>> "all"). So e.g. the equivalent of `?lm` for R 4.1.0. >>>> >>>> These live in the R source tree, under src/library: >>>> https://svn.r-project.org/R/trunk/src/library/ <https://svn.r-project.org/R/trunk/src/library/> >>>> >>>> For the actual releases of R, you may have to go looking at the >>>> branches inside that repository, e.g., the following command: >>>> >>>> svn log \ >>>> >>>> >> https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd <https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd> >>>> >>>> ...should tell you the history of ?lm until the latest R-4.1-patched. >>>> >>>> Do the Git mirrors track these release branches? The branching model of >>>> Subversion [*] is different from the Git model, so perhaps not. >>>> >>>> -- >>>> Best regards, >>>> Ivan >>>> >>>> [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html <https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html> >>>> >> >> -- >> Sent from my phone. Please excuse my brevity. >> >> __ >> 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 mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] length() conflict with C++17
rgl has a lot of C++ code which is now getting errors in the clang17 tests on CRAN: https://www.stats.ox.ac.uk/pub/bdr/clang17/rgl.log I haven't looked at the whole list yet, but many of the errors arise because R's include/Rinternals.h defines a length() macro, and that conflicts with a definition in clang's library. For example, /lib64/glib-2.0/include -I/usr/include/sysprof-4 -pthread -Iext -Iext/glad/include -isystem /usr/local/clang-trunk/include -I/usr/local/clang/include-fpic -O3 -Wall -pedantic -frtti -Wp,-D_FORTIFY_SOURCE=3 -c PlaneSet.cpp -o PlaneSet.o In file included from NULLgui.cpp:9: In file included from ./NULLgui.h:4: In file included from ./gui.h:9: In file included from ./glgui.h:8: In file included from /usr/local/clang-trunk/bin/../include/c++/v1/vector:322: In file included from /usr/local/clang-trunk/bin/../include/c++/v1/__format/formatter_bool.h:21: In file included from /usr/local/clang-trunk/bin/../include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/local/clang-trunk/bin/../include/c++/v1/locale:203: /usr/local/clang-trunk/bin/../include/c++/v1/__locale:961:34: error: too many arguments provided to function-like macro invocation 961 | int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const | ^ /data/gannet/ripley/R/R-flang/include/Rinternals.h:968:9: note: macro 'length' defined here 968 | #define length(x) Rf_length(x) For those R users who know C++ better than me, is there a standard way to avoid this? I can think of a couple that should work (e.g. defining R_NO_REMAP globally, or rearranging the order of includes). I'd like to use the standard one if there is such a thing. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Public URLs for help for versions of base packages
On 29/06/2023 4:46 p.m., Ivan Krylov wrote: On Thu, 29 Jun 2023 20:22:47 +0100 David Hugh-Jones wrote: I'm looking for a source of online help for R base packages, which covers all versions (for some reasonable value of "all"). So e.g. the equivalent of `?lm` for R 4.1.0. These live in the R source tree, under src/library: https://svn.r-project.org/R/trunk/src/library/ For the actual releases of R, you may have to go looking at the branches inside that repository, e.g., the following command: svn log \ https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd ...should tell you the history of ?lm until the latest R-4.1-patched. Do the Git mirrors track these release branches? The branching model of Subversion [*] is different from the Git model, so perhaps not. The wch/r-source mirror tracks the releases. It takes svn tags and branches and converts them all to git branches. For example, here's the help for Rd2HTML from R 2.9.0: https://github.com/wch/r-source/blob/tags/R-2-9-0/src/library/tools/man/Rd2HTML.Rd Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Public URLs for help for versions of base packages
Why store them? Download the source on demand, and convert it. Seems pretty simple. Duncan Murdoch On 30/06/2023 1:19 a.m., David Hugh-Jones wrote: This is for the rcheology package. I run a Shiny web app which lets you examine changes to functions across R versions: https://hughjonesd.shinyapps.io/rcheology/ Manually storing and converting the Rd might be possible, but it would be burdensome in terms of data (and my time). And if the Rd spec has changed across versions, that’s another problem. More generally, shouldn’t there be publicly available versioned documentation? Python has had this for a long time. David On Fri, 30 Jun 2023 at 01:01, Jeff Newmiller wrote: Sure. On your computer. Install the old version of R and let it serve the relevant docs. Dunno of anyone doing this historical dive online for you though. Why would you want preformatted docs if you didn't have those old versions installed? On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones < davidhughjo...@gmail.com> wrote: That’s useful to know. But is there anywhere with preformatted HTML pages? Cheers, D On Thu, 29 Jun 2023 at 21:46, Ivan Krylov wrote: On Thu, 29 Jun 2023 20:22:47 +0100 David Hugh-Jones wrote: I'm looking for a source of online help for R base packages, which covers all versions (for some reasonable value of "all"). So e.g. the equivalent of `?lm` for R 4.1.0. These live in the R source tree, under src/library: https://svn.r-project.org/R/trunk/src/library/ For the actual releases of R, you may have to go looking at the branches inside that repository, e.g., the following command: svn log \ https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd ...should tell you the history of ?lm until the latest R-4.1-patched. Do the Git mirrors track these release branches? The branching model of Subversion [*] is different from the Git model, so perhaps not. -- Best regards, Ivan [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html -- Sent from my phone. Please excuse my brevity. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Public URLs for help for versions of base packages
R includes the tools::Rd2HTML function to convert Rd source files to HTML for display. RStudio offers previews of Rd pages; presumably they use those functions. I imagine ESS does the same. If you want to do it yourself, start with ?tools::Rd2HTML. There have been changes to the specs over time, but I'd guess current R could render old Rd pages reasonably well, back to when Prof Ripley and I wrote Rd2HTML in R 2.9.0. Before that, it was done by a Perl script, and the Rd syntax had more differences; I think the parser would likely die on those very old files. Duncan Murdoch On 29/06/2023 8:01 p.m., Jeff Newmiller wrote: Sure. On your computer. Install the old version of R and let it serve the relevant docs. Dunno of anyone doing this historical dive online for you though. Why would you want preformatted docs if you didn't have those old versions installed? On June 29, 2023 4:23:55 PM PDT, David Hugh-Jones wrote: That’s useful to know. But is there anywhere with preformatted HTML pages? Cheers, D On Thu, 29 Jun 2023 at 21:46, Ivan Krylov wrote: On Thu, 29 Jun 2023 20:22:47 +0100 David Hugh-Jones wrote: I'm looking for a source of online help for R base packages, which covers all versions (for some reasonable value of "all"). So e.g. the equivalent of `?lm` for R 4.1.0. These live in the R source tree, under src/library: https://svn.r-project.org/R/trunk/src/library/ For the actual releases of R, you may have to go looking at the branches inside that repository, e.g., the following command: svn log \ https://svn.r-project.org/R/branches/R-4-1-branch/src/library/stats/man/lm.Rd ...should tell you the history of ?lm until the latest R-4.1-patched. Do the Git mirrors track these release branches? The branching model of Subversion [*] is different from the Git model, so perhaps not. -- Best regards, Ivan [*] https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to request for an Non Maintainer update - NMU
You should try to contact the maintainer, and find out if they are planning an update, but missed CRAN's schedule. If not, then you should volunteer to take over as maintainer. Being a maintainer doesn't require much work for the minimum necessary work: you just need to fix issues as they arise in CRAN checks. It usually doesn't require much expertise: if an issue arises that you don't understand, then people on this mailing list are likely to be helpful in fixing it. Of course, if you are maintainer you can do much more than that, but it's your choice. Duncan Murdoch On 06/06/2023 2:04 a.m., Bernd.Gruber wrote: Hi everyone, I am the maintainer of a package (dartR) that depends on ggtern (a package that seems not to be maintained anymore). Currently the package was removed from CRAN (about 4 weeks ago) due to a simple error, which can be easily fixed. This was kindly achieved by Roger Bivand (simply the remove of a backslash does the trick). In an github exchange he also suggested to have an non maintainer update (NMU) for the package in the short term (and find a replacement of orphan the package and find a new maintainer in the long term). Here is my first question as I did not find an answer googling it. How can I ask, request for an NMU? Would I simply write to CRAN and describe the situation and send the files that need to be replaced? The second question is, how I would request to orphan the package and what is the procedure to find a new maintainer (as it relies on ggplot code and this is not really my strength, hence I would try to find someone else to take over). Thanks a lot, Bernd == Dr Bernd Gruber )/_ _.--..---"-,--c_ Professor Ecological Modelling \|..' ._O__)_ Tel: (02) 6206 3804 ,=._.+ _ \..--( / Fax: (02) 6201 2328 \\.-''_.-' \ ( \_ Institute for Applied Ecology `''' `\__ /\ Faculty of Science and Technology ') University of Canberra ACT 2601 AUSTRALIA Email: bernd.gru...@canberra.edu.au<mailto:bernd.gru...@canberra.edu.au> WWW: bernd-gruber<https://researchprofiles.canberra.edu.au/en/persons/bernd-gruber> Australian Government Higher Education Provider Number CRICOS #00212K NOTICE & DISCLAIMER: This email and any files transmitted with it may contain confidential or copyright material and are for the attention of the addressee only. If you have received this email in error please notify us by email reply and delete it from your system. The University of Canberra accepts no liability for any damage caused by any virus transmitted by this email. == [UC Logo]<http://www.canberra.edu.au> [Research Festival,5-8 June 2023]<https://www.canberra.edu.au/about-uc/events/research-festival/research-festival-2023> The Ngunnawal people are the Traditional Custodians of the ACT where UC's Bruce Campus is situated and are an integral and celebrated part of UC's culture. We also acknowledge other First Nations Peoples. Australian Government Higher Education Registered Provider (CRICOS) #00212K. TEQSA Provider ID: PRV12003 (Australian University) Email Disclaimer<https://www.canberra.edu.au/about-uc/disclaimer-copyright-privacy-accessibility> [UC Facebook]<https://www.facebook.com/UniversityOfCanberra>[UC Twitter] <https://twitter.com/UniCanberra> [UC Instagram] <https://www.instagram.com/unicanberra/> [UC Linkedin] <https://au.linkedin.com/school/university-of-canberra/> [UC Youtube] <https://www.youtube.com/user/uniofcanberra> [University of Canberra] <http://www.canberra.edu.au> [[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] help fixing CRAN package sos-now fails on GitHub
On 23/05/2023 6:53 a.m., Martin Maechler wrote:
Duncan Murdoch
on Mon, 22 May 2023 15:38:10 -0400 writes:
> On 22/05/2023 3:07 p.m., Ivan Krylov wrote:
>> I fed your vignette to R CMD Sweave, and here's the
>> relevant fragment from the resulting *.tex file:
>>
>>> This returned a {\tt "findFn"} object identifying 405
>>> help pages. When this was run while preparing this
>>> manuscript, the sixth row was {\tt pspline_checker} in
>>> the \pkg{JOPS} package, which has a {\tt Score} of
>>> 47. (On another day, the results could be different,
>>> because CRAN changes over time.) This was the sixth row
>>> in this table, because it is in the \pkg{JOPS} package,
>>> which had a total of 54 help pages matching the search
>>> term, but this was the only one whose name matched the
>>> {\tt pattern} passed to {\tt grepFn}.
>>
>> This corresponds to the following part of the vignette:
>>
>>> This returned a {\tt "findFn"} object identifying
>>> \Sexpr{nrow(g)} help pages. When this was run while
>>> preparing this manuscript, the sixth row was {\tt
>>> \Sexpr{gFunc6}} in the \pkg{\Sexpr{gPac6}} package,
>>> which has a {\tt Score} of \Sexpr{gScore6}.
>>
>> So, you need to escape the underscores in
>> gFunc6. Probably not gPac6 because underscores are not
>> allowed in package names.
>>
> Nice find. Just in case Spencer has trouble with escaping
> the escapes, I think he should change
>"{\tt \Sexpr{gFunc6}}"
> to
>"{\tt \Sexpr{sub("_", "_", gFunc6)}}
> Even better would be to write a little function
> "sanitizeForLatex" that did this and any other necessary
> changes, and call that.
Yes, indeed (2 x).
If I grep the base R package sources, I find three occurrences
of something like the above:
grep --color -nH --null -e 'sub *(.*_' */R/*.R
tools/R/Rd2latex.R:295:x <- fsub("\\_", "_", x)
tools/R/Rd2latex.R:303:x <- fsub("\\_", ".Rul.", x)
tools/R/Rd.R:681:txt <- gsub("\\_", "_", txt, fixed=TRUE)
all of which do the transformation in the other direction
(because *.Rd in those cases already *is* LaTeX-alike, and needs
to convert for non-LaTeX use).
Note that the last one gives a hint to be more general --- gsub()
also working a.g. for 'parse_me_not' ---
*and* possibly faster (fixed=TRUE) leading to
"{\tt \Sexpr{gsub("_", "_", gFunc6, fixed=TRUE)}}
Martin
Yes, a good idea to use gsub and fixed = TRUE.
There are some changes in the other direction as well in that file (Rd
format is very complicated). I think the characters it handles are \,
&, $, %, _, #, {, }, ^, ~, occurring near line 145. Only _ is allowed
in a "syntactic" name, but others might turn up when trying to display
other code.
Duncan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] help fixing CRAN package sos-now fails on GitHub
On 22/05/2023 3:07 p.m., Ivan Krylov wrote:
I fed your vignette to R CMD Sweave, and here's the relevant fragment
from the resulting *.tex file:
This returned a {\tt "findFn"} object identifying 405 help pages.
When this was run while preparing this manuscript, the sixth row was
{\tt pspline_checker} in the \pkg{JOPS} package, which has a {\tt
Score} of 47. (On another day, the results could be different,
because CRAN changes over time.) This was the sixth row in this
table, because it is in the \pkg{JOPS} package, which had a total of
54 help pages matching the search term, but this was the only one
whose name matched the {\tt pattern} passed to {\tt grepFn}.
This corresponds to the following part of the vignette:
This returned a {\tt "findFn"} object identifying \Sexpr{nrow(g)}
help pages.
When this was
run while preparing this manuscript, the sixth row was
{\tt \Sexpr{gFunc6}} in the
\pkg{\Sexpr{gPac6}} package, which has a {\tt Score} of
\Sexpr{gScore6}.
So, you need to escape the underscores in gFunc6. Probably not gPac6
because underscores are not allowed in package names.
Nice find. Just in case Spencer has trouble with escaping the escapes,
I think he should change
"{\tt \Sexpr{gFunc6}}"
to
"{\tt \Sexpr{sub("_", "_", gFunc6)}}
Even better would be to write a little function "sanitizeForLatex" that
did this and any other necessary changes, and call that.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problems with devtools::build() in R
I'm using R 4.3.0, newer than you, so that might affect things.
Duncan
On 16/05/2023 2:48 p.m., Jarrett Phillips wrote:
Strange... the GitHub repo is up to date and that's what I'm trying to
bundle up for a CRAN update. So, I'm thinking it's some kind of a system
issue (I recently purchased a new MacBook Pro)..
I'll investigate.
Thanks!
On Tue, May 16, 2023 at 2:09 PM Duncan Murdoch <mailto:murdoch.dun...@gmail.com>> wrote:
I don't know what the issue would be. I just tried
remotes::install_github("jphill01/HACSim.R")
and it worked fine, but I think that's not the same version that you
are
working with.
Duncan Murdoch
On 16/05/2023 2:01 p.m., Jarrett Phillips wrote:
>
>
> On Tue, May 16, 2023 at 2:00 PM Jarrett Phillips
> mailto:phillipsjarre...@gmail.com>
<mailto:phillipsjarre...@gmail.com
<mailto:phillipsjarre...@gmail.com>>> wrote:
>
> Yes, in addition to doing what @DirkEddelbuettel suggests. I keep
> getting the same error...
>
> On Tue, May 16, 2023 at 1:47 PM Duncan Murdoch
> mailto:murdoch.dun...@gmail.com>
<mailto:murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>>>
wrote:
>
> On 16/05/2023 1:14 p.m., Jarrett Phillips wrote:
> > Installing from the URL you provide, as well as doing
R CMD
> build HACSim
> > as suggested by @JeffNewmiller fails.
> >
> > When trying the latter solution, I get the same error
as the one
> > provided in my original post.
> >
> > Any thoughts?
>
> Did you try Serguei's suggestion?
>
> On 16/05/2023 12:32 p.m., Serguei Sokol wrote:
> > Try to add in /src/Makevars:
> >
> > PKG_LIBS=$(FLIBS)
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problems with devtools::build() in R
I don't know what the issue would be. I just tried
remotes::install_github("jphill01/HACSim.R")
and it worked fine, but I think that's not the same version that you are
working with.
Duncan Murdoch
On 16/05/2023 2:01 p.m., Jarrett Phillips wrote:
On Tue, May 16, 2023 at 2:00 PM Jarrett Phillips
mailto:phillipsjarre...@gmail.com>> wrote:
Yes, in addition to doing what @DirkEddelbuettel suggests. I keep
getting the same error...
On Tue, May 16, 2023 at 1:47 PM Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
On 16/05/2023 1:14 p.m., Jarrett Phillips wrote:
> Installing from the URL you provide, as well as doing R CMD
build HACSim
> as suggested by @JeffNewmiller fails.
>
> When trying the latter solution, I get the same error as the one
> provided in my original post.
>
> Any thoughts?
Did you try Serguei's suggestion?
On 16/05/2023 12:32 p.m., Serguei Sokol wrote:
> Try to add in /src/Makevars:
>
> PKG_LIBS=$(FLIBS)
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problems with devtools::build() in R
On 16/05/2023 1:14 p.m., Jarrett Phillips wrote: Installing from the URL you provide, as well as doing R CMD build HACSim as suggested by @JeffNewmiller fails. When trying the latter solution, I get the same error as the one provided in my original post. Any thoughts? Did you try Serguei's suggestion? On 16/05/2023 12:32 p.m., Serguei Sokol wrote: > Try to add in /src/Makevars: > > PKG_LIBS=$(FLIBS) __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Problems with devtools::build() in R
On 16/05/2023 12:07 p.m., Jarrett Phillips wrote:
Hi All,
I'm trying to generate a `tar.gz` file on a Mac for R package submission to
CRAN but am having issues.
I'm using `devtools`, specifically `build()` and `install()`.
My package relies on compiled code via `Rcpp/RcppArmadillo`.
build("HACSim_OO")
── R CMD build
─
✔ checking for file ‘/Users/jarrettphillips/Desktop/HAC
simulation/HACSim_OO/DESCRIPTION’ ...
─ preparing ‘HACSim’:
✔ checking DESCRIPTION meta-information ...
─ cleaning src
─ installing the package to process help pages
---
─ installing *source* package ‘HACSim’ ...
** using staged installation
** libs
clang++ -arch arm64 -std=gnu++11 -
I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC -falign-functions=64 -Wall -g -O2 -Wall
-pedantic -fdiagnostics-color=always -c RcppExports.cpp -o RcppExports.o
clang++ -arch arm64 -std=gnu++11
-I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/Rcpp/include'
-I'/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library/RcppArmadillo/include'
-I/opt/R/arm64/include-fPIC -falign-functions=64 -Wall -g -O2 -Wall
-pedantic -fdiagnostics-color=always -c accumulate.cpp -o accumulate.o
clang++ -arch arm64 -std=gnu++11 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
-multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib
-L/opt/R/arm64/lib -o HACSim.so RcppExports.o accumulate.o
-L/Library/Frameworks/R.framework/Resources/lib -lRlapack
-L/Library/Frameworks/R.framework/Resources/lib -lRblas
-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1
-L/opt/R/arm64/gfortran/lib -lgfortran -lemutls_w -lquadmath
-F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
-Wl,CoreFoundation
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib/gcc/aarch64-apple-darwin20.6.0/12.0.1'
ld: warning: directory not found for option
'-L/opt/R/arm64/gfortran/lib'
ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [HACSim.so] Error 1
ERROR: compilation failed for package ‘HACSim’
─ removing
‘/private/var/folders/r4/xm5blbcd2tn06tjv00lm1c78gn/T/RtmpN4uaYR/Rinstdf4219594de/HACSim’
---
ERROR: package installation failed
Error in `(function (command = NULL, args = character(),
error_on_status = TRUE, …`:
! System command 'R' failed
---
Exit status: 1
stdout & stderr:
---
Type .Last.error to see the more details.
`clang` is installed (since I am able to run the code within my package)
and I've verified by typing `gcc` in the Mac Terminal. I've also installed
`Homebrew` and `gfortran`, verifying via typing in the Terminal.
Any idea on what's going on how to fix the issue(s)?
You don't say how you installed gfortran, but it sounds as though you
installed Homebrew's build of it. You should install the tools as
available from https://mac.r-project.org/tools/.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Unneeded S3 method registration
The problem is that there's no way to declare that an internal function
should or shouldn't be treated as an S3 method, other than by declaring
it as one in NAMESPACE and exporting it. If you read the thread
"Unfortunate function name generic.something" that started last week,
you'll see the opposing problem to yours: a local function named
levels.no that isn't intended to be an S3 method, but will be treated as
one in some circumstances.
You do export emm_basis and recover_data, so those generics are
available to users. And you do declare some of the methods, e.g. in
emmeans 1.8.5, users can see methods for some classes:
> methods("emm_basis")
[1] emm_basis.aovlist* emm_basis.lm* emm_basis.lme*
emm_basis.merMod* emm_basis.mlm*
As the message below says, you don't declare emm_basis.Gam to be a
method, which means that a user with a Gam object who calls emm_basis
will get the default method instead, whereas when code in your package
calls it, they'll get the Gam method.
You say users should never call emm_basis directly, but package
developers should provide methods for it. At a minimum that's going to
make debugging those packages much more confusing. And if they have a
class which inherits from Gam and want to call the inherited method,
they won't get it.
So I think in this case the NOTE is something you should fix.
Duncan Murdoch
On 10/05/2023 10:49 p.m., Lenth, Russell V wrote:
Dear R package developers
My emmeans package failed preliminary checks when I submitted an update today,
apparently due to a recent change in requirements on method registration. The
message I got was:
* checking S3 generic/method consistency ... NOTE
Apparent methods for exported generics not registered:
emm_basis.Gam emm_basis.MCMCglmm emm_basis.averaging
emm_basis.betareg emm_basis.brmsfit emm_basis.carbayes emm_basis.clm
emm_basis.clmm emm_basis.coxme emm_basis.coxph emm_basis.default
emm_basis.gam emm_basis.gamlss emm_basis.gamm emm_basis.gee
emm_basis.geeglm emm_basis.geese emm_basis.gls emm_basis.gnls
emm_basis.hurdle emm_basis.lqm emm_basis.lqmm emm_basis.mblogit
emm_basis.mcmc emm_basis.mcmc.list emm_basis.mira emm_basis.mmer
emm_basis.multinom emm_basis.nlme emm_basis.nls emm_basis.polr
emm_basis.qdrg emm_basis.rms emm_basis.rq emm_basis.rqs
emm_basis.stanreg emm_basis.survreg emm_basis.svyolr
emm_basis.zeroinfl recover_data.MCMCglmm recover_data.averaging
recover_data.betareg recover_data.brmsfit recover_data.carbayes
recover_data.clm recover_data.clmm recover_data.coxme
recover_data.coxph recover_data.default recover_data.gam
recover_data.gamlss recover_data.gamm recover_data.gee
recover_data.geeglm recover_data.geese recover_data.gls
recover_data.gnls recover_data.hurdle recover_data.lqm
recover_data.lqmm recover_data.manova recover_data.mblogit
recover_data.mcmc recover_data.mcmc.list recover_data.mira
recover_data.mmer recover_data.multinom recover_data.nlme
recover_data.nls recover_data.polr recover_data.qdrg recover_data.rms
recover_data.rq recover_data.rqs recover_data.stanreg
recover_data.survreg recover_data.svyglm recover_data.svyolr
recover_data.zeroinfl
See section 'Registering S3 methods' in the 'Writing R Extensions'
manual.
I guess my question is "why does this matter?" There are many, many functions
mentioned here, but they are all methods for emm_basis and recover_data. Both generics
are in the emmeans namespace, as are all these functions.
The section on registering S3 methods explains:
The standard method for S3-style UseMethod dispatching might fail to locate
methods defined in a package that is imported but not attached to the search
path. To ensure that these methods are available the packages defining the
methods should ensure that the generics are imported and register the methods
using S3method directives...
But clearly all those methods flagged in the messages will be found in the same
namespace as the generics -- emm_basis and recover_data -- so not being able to
find them is not an issue. Moreover, emm_basis() and recover_data() are not
meant to be called directly by a user, or even by code in another package. They
are only meant to be called within the function emmeans::ref_grid(), and the
existence of those generics and methods is simply a mechanism for being able to
support a lot of different model classes.
Obviously, I could add a whole lot of S3method() directives to the NAMESPACE
file, but it just seems wasteful to export all those methods when they are
never needed outside the emmeans namespace.
Am I missing something?
Thanks
Russ Lenth
[[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
Re: [R-pkg-devel] Unfortunate function name generic.something
On 09/05/2023 5:05 p.m., Simon Urbanek wrote:
Duncan,
you're right that any functions in the call environment are always treated as
methods (even before consulting method registrations). That is a special case -
I presume for compatibility with the world before namespaces so that, e.g., you
don't have to register methods in the global environment when working
interactively. I wonder if that is something that packages could choose to opt
out of for safety since they are already relying on method registration (and
that would also in theory improve performance).
One interesting related issue is that in the current implementation of the method registration
there is no concept of "private" methods (which is what the above rule effectively
provides) since methods get registered with the generic, so they are either visible to everyone or
not at all. If one would really want to support this, it would require a kind of "local"
registration and then replacing the name-based search up the call chain with local registration
search - but probably again at the cost of performance.
One possible implementation of this would be to register methods with an
imported copy of the generic.
Duncan
Cheers,
Simon
On May 9, 2023, at 11:23 AM, Duncan Murdoch wrote:
On 08/05/2023 6:58 p.m., Simon Urbanek wrote:
On 8/05/2023, at 11:58 PM, Duncan Murdoch wrote:
There really isn't such a thing as "a function that looks like an S3 method, but
isn't". If it looks like an S3 method, then in the proper circumstances, it will be
called as one.
I disagree - that was the case in old versions, but not anymore. The whole
point of introducing namespaces and method registration was to make it clear
when a function is a method and when it is a function. If you export a function
it won't be treated as a method:
In a package NAMESPACE:
export(foo.cls)
package R code: foo.cls <- function(x) "foo.cls"
in R:
cls=structure(1,class="cls")
foo=function(x) UseMethod("foo")
foo(cls)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "cls"
foo.cls(cls)
[1] "foo.cls"
So R knows very well what is a method and what is a function. If you wanted it
to be a method, you have to use S3method(foo, cls) and that **is** different
from export(foo.cls) - quite deliberately so.
That is true for package users, but it's not true within the package. I just
tested this code in a package:
levels.no <- function(xx, ...) {
stop("not a method")
}
f <- function() {
x <- structure(1, class = "no")
levels(x)
}
Both levels.no and f were exported. If I attach the package and call f(), I
get the error
> library(testpkg)
> f()
Error in levels.no(x) : not a method
because levels.no is being treated as a method when levels() is called in the
package.
If I create an x like that outside of the package and call levels(x) there, I
get NULL, because levels.no is not being treated as a method in that context.
As far as I know, there is no possible way to have a function in a package that is called
"levels.no" and not being treated as a method within the package. I don't think there's
any way to declare "this is not a method", other than naming it differently.
Duncan
Cheers,
Simon
In your case the function name is levels.no, and it isn't exported. So if you happen to
have an object with a class inheriting from "no", and you call levels() on it,
levels.no might be called.
This will only affect users of your package indirectly. If they have objects inheriting
from "no" and call levels() on them, levels.no will not be called. But if they
pass such an object to one of your package functions, and that function calls levels() on
it, they could end up calling levels.no(). It all depends on what other classes that
object inherits from.
You can test this yourself. Set debugging on any one of your functions, then
call it in the normal way. Then while still in the debugger set debugging on
levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named gen.cl will be
invoked by the generic gen for class cl, so do not name functions in this style unless
they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename levels.no to
something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword internal
does not solve the problem, the note is still there. Any other proposals
for properly documenting a function that looks like an S3 method, but isn't?
Best, Ulrike
Am 05.05.2023 u
Re: [R-pkg-devel] Unfortunate function name generic.something
If anyone wants to try my demo, they can install the test package using
remotes::install_github("dmurdoch/testpkg")
and see the demonstration by running
library(testpkg)
example(f)
Duncan Murdoch
On 08/05/2023 7:23 p.m., Duncan Murdoch wrote:
On 08/05/2023 6:58 p.m., Simon Urbanek wrote:
On 8/05/2023, at 11:58 PM, Duncan Murdoch wrote:
There really isn't such a thing as "a function that looks like an S3 method, but
isn't". If it looks like an S3 method, then in the proper circumstances, it will be
called as one.
I disagree - that was the case in old versions, but not anymore. The whole
point of introducing namespaces and method registration was to make it clear
when a function is a method and when it is a function. If you export a function
it won't be treated as a method:
In a package NAMESPACE:
export(foo.cls)
package R code: foo.cls <- function(x) "foo.cls"
in R:
cls=structure(1,class="cls")
foo=function(x) UseMethod("foo")
foo(cls)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "cls"
foo.cls(cls)
[1] "foo.cls"
So R knows very well what is a method and what is a function. If you wanted it
to be a method, you have to use S3method(foo, cls) and that **is** different
from export(foo.cls) - quite deliberately so.
That is true for package users, but it's not true within the package. I
just tested this code in a package:
levels.no <- function(xx, ...) {
stop("not a method")
}
f <- function() {
x <- structure(1, class = "no")
levels(x)
}
Both levels.no and f were exported. If I attach the package and call
f(), I get the error
> library(testpkg)
> f()
Error in levels.no(x) : not a method
because levels.no is being treated as a method when levels() is called
in the package.
If I create an x like that outside of the package and call levels(x)
there, I get NULL, because levels.no is not being treated as a method in
that context.
As far as I know, there is no possible way to have a function in a
package that is called "levels.no" and not being treated as a method
within the package. I don't think there's any way to declare "this is
not a method", other than naming it differently.
Duncan
Cheers,
Simon
In your case the function name is levels.no, and it isn't exported. So if you happen to
have an object with a class inheriting from "no", and you call levels() on it,
levels.no might be called.
This will only affect users of your package indirectly. If they have objects inheriting
from "no" and call levels() on them, levels.no will not be called. But if they
pass such an object to one of your package functions, and that function calls levels() on
it, they could end up calling levels.no(). It all depends on what other classes that
object inherits from.
You can test this yourself. Set debugging on any one of your functions, then
call it in the normal way. Then while still in the debugger set debugging on
levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named gen.cl will be
invoked by the generic gen for class cl, so do not name functions in this style unless
they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename levels.no to
something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword internal
does not solve the problem, the note is still there. Any other proposals
for properly documenting a function that looks like an S3 method, but isn't?
Best, Ulrike
Am 05.05.2023 um 12:56 schrieb Iris Simmons:
You can add
\keyword{internal}
to the Rd file. Your documentation won't show up the in the pdf
manual, it won't show up in the package index, but you'll still be
able to access the doc page with ?levels.no <http://levels.no> or
help("levels.no <http://levels.no>").
This is usually used in a package's deprecated and defunct doc pages,
but you can use it anywhere.
On Fri, May 5, 2023, 06:49 Ulrike Groemping
wrote:
Dear package developeRs,
I am working on fixing some notes regarding package DoE.base.
One note refers to the function levels.no <http://levels.no> and
complains that the
function is not documented as a method for the generic function
levels.
Actually, it is not a method for the generic levels, but a standalone
internal function that I like to have documented.
Is there a way to document the function without renaming it and
without
triggering a
Re: [R-pkg-devel] Unfortunate function name generic.something
On 08/05/2023 6:58 p.m., Simon Urbanek wrote:
On 8/05/2023, at 11:58 PM, Duncan Murdoch wrote:
There really isn't such a thing as "a function that looks like an S3 method, but
isn't". If it looks like an S3 method, then in the proper circumstances, it will be
called as one.
I disagree - that was the case in old versions, but not anymore. The whole
point of introducing namespaces and method registration was to make it clear
when a function is a method and when it is a function. If you export a function
it won't be treated as a method:
In a package NAMESPACE:
export(foo.cls)
package R code: foo.cls <- function(x) "foo.cls"
in R:
cls=structure(1,class="cls")
foo=function(x) UseMethod("foo")
foo(cls)
Error in UseMethod("foo") :
no applicable method for 'foo' applied to an object of class "cls"
foo.cls(cls)
[1] "foo.cls"
So R knows very well what is a method and what is a function. If you wanted it
to be a method, you have to use S3method(foo, cls) and that **is** different
from export(foo.cls) - quite deliberately so.
That is true for package users, but it's not true within the package. I
just tested this code in a package:
levels.no <- function(xx, ...) {
stop("not a method")
}
f <- function() {
x <- structure(1, class = "no")
levels(x)
}
Both levels.no and f were exported. If I attach the package and call
f(), I get the error
> library(testpkg)
> f()
Error in levels.no(x) : not a method
because levels.no is being treated as a method when levels() is called
in the package.
If I create an x like that outside of the package and call levels(x)
there, I get NULL, because levels.no is not being treated as a method in
that context.
As far as I know, there is no possible way to have a function in a
package that is called "levels.no" and not being treated as a method
within the package. I don't think there's any way to declare "this is
not a method", other than naming it differently.
Duncan
Cheers,
Simon
In your case the function name is levels.no, and it isn't exported. So if you happen to
have an object with a class inheriting from "no", and you call levels() on it,
levels.no might be called.
This will only affect users of your package indirectly. If they have objects inheriting
from "no" and call levels() on them, levels.no will not be called. But if they
pass such an object to one of your package functions, and that function calls levels() on
it, they could end up calling levels.no(). It all depends on what other classes that
object inherits from.
You can test this yourself. Set debugging on any one of your functions, then
call it in the normal way. Then while still in the debugger set debugging on
levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named gen.cl will be
invoked by the generic gen for class cl, so do not name functions in this style unless
they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename levels.no to
something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword internal
does not solve the problem, the note is still there. Any other proposals
for properly documenting a function that looks like an S3 method, but isn't?
Best, Ulrike
Am 05.05.2023 um 12:56 schrieb Iris Simmons:
You can add
\keyword{internal}
to the Rd file. Your documentation won't show up the in the pdf
manual, it won't show up in the package index, but you'll still be
able to access the doc page with ?levels.no <http://levels.no> or
help("levels.no <http://levels.no>").
This is usually used in a package's deprecated and defunct doc pages,
but you can use it anywhere.
On Fri, May 5, 2023, 06:49 Ulrike Groemping
wrote:
Dear package developeRs,
I am working on fixing some notes regarding package DoE.base.
One note refers to the function levels.no <http://levels.no> and
complains that the
function is not documented as a method for the generic function
levels.
Actually, it is not a method for the generic levels, but a standalone
internal function that I like to have documented.
Is there a way to document the function without renaming it and
without
triggering a note about method documentation?
Best, Ulrike
--
##
## Prof. Ulrike Groemping
## FB II
## Berliner Hochschule für Technik (BHT)
##
Re: [R-pkg-devel] Unfortunate function name generic.something
On 08/05/2023 12:10 p.m., Ulrike Groemping wrote:
Am 08.05.2023 um 15:48 schrieb Duncan Murdoch:
On 08/05/2023 8:28 a.m., Ulrike Groemping wrote:
Thanks, Duncan. I appreciate the view that levels.no acts as an S3
method for the generic levels, if an object of class "no" is handed to
it. However, as the function is not intended as an S3 method, it does
not make sense to document it as such. As the function is internal only,
which makes the scenario that it causes trouble extremely unlikely, I
will simply comment out the usage line for the function in order to get
rid of the note but keep the usage visible. I hope that this is OK.
I think that should solve the warning issue, and it's better than
documenting it as an S3 method when it's not intended to be one.
I don't know how likely it is to cause trouble. You do call levels(),
but I don't know if you ever call it on objects that weren't created
internally. If so, then there's the possibility that one of them will
have that "no" class for a completely unrelated reason, and then there
will be trouble.
Duncan Murdoch
It solved the documentation warning issue, but another issue followed
suit (found in the submission pretests only):
"Mismatches for apparent methods not registered:
levels:
function(x)
levels.no:
function(xx)"
I now changed the argument of levels.no to x, registered the method (as
I was under the impression that not registering it would trigger the
next complaint; of course, registering it might make it more likely to
be mis-used). For preventing unnoticed problems, I made the function
throw a meaningful error message ("DoE.base:::levels.no is not a method
for the generic base::levels") in the (hopefully unlikely) case that it
is handed an object of class "no" by someone who wants to use a levels
method on that object. This version now passed the pretest checks.
I think that registering it as an S3 method makes the potential problem
worse, because it makes it much more visible. That's assuming you now
have something like
S3method(levels, no)
in your NAMESPACE file, so every use of levels() by the user or in any
package could potentially call levels.no if your package is loaded.
Duncan Murdoch
Ulrike Groemping
Best, Ulrike
Am 08.05.2023 um 13:58 schrieb Duncan Murdoch:
There really isn't such a thing as "a function that looks like an S3
method, but isn't". If it looks like an S3 method, then in the proper
circumstances, it will be called as one.
In your case the function name is levels.no, and it isn't exported.
So if you happen to have an object with a class inheriting from "no",
and you call levels() on it, levels.no might be called.
This will only affect users of your package indirectly. If they have
objects inheriting from "no" and call levels() on them, levels.no will
not be called. But if they pass such an object to one of your package
functions, and that function calls levels() on it, they could end up
calling levels.no(). It all depends on what other classes that object
inherits from.
You can test this yourself. Set debugging on any one of your
functions, then call it in the normal way. Then while still in the
debugger set debugging on levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named
gen.cl will be invoked by the generic gen for class cl, so do not name
functions in this style unless they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename
levels.no to something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword
internal
does not solve the problem, the note is still there. Any other
proposals
for properly documenting a function that looks like an S3 method, but
isn't?
Best, Ulrike
Am 05.05.2023 um 12:56 schrieb Iris Simmons:
You can add
\keyword{internal}
to the Rd file. Your documentation won't show up the in the pdf
manual, it won't show up in the package index, but you'll still be
able to access the doc page with ?levels.no <http://levels.no> or
help("levels.no <http://levels.no>").
This is usually used in a package's deprecated and defunct doc pages,
but you can use it anywhere.
On Fri, May 5, 2023, 06:49 Ulrike Groemping
wrote:
Dear package developeRs,
I am working on fixing some notes regarding package DoE.base.
One note refers to the function levels.no <http://levels.no>
and
complains that the
function is not documented as a method for the generic function
levels.
Actually, it is not a method for the generic levels, but a
standalone
internal function that I like to hav
Re: [R-pkg-devel] Unfortunate function name generic.something
On 08/05/2023 8:28 a.m., Ulrike Groemping wrote:
Thanks, Duncan. I appreciate the view that levels.no acts as an S3
method for the generic levels, if an object of class "no" is handed to
it. However, as the function is not intended as an S3 method, it does
not make sense to document it as such. As the function is internal only,
which makes the scenario that it causes trouble extremely unlikely, I
will simply comment out the usage line for the function in order to get
rid of the note but keep the usage visible. I hope that this is OK.
I think that should solve the warning issue, and it's better than
documenting it as an S3 method when it's not intended to be one.
I don't know how likely it is to cause trouble. You do call levels(),
but I don't know if you ever call it on objects that weren't created
internally. If so, then there's the possibility that one of them will
have that "no" class for a completely unrelated reason, and then there
will be trouble.
Duncan Murdoch
Best, Ulrike
Am 08.05.2023 um 13:58 schrieb Duncan Murdoch:
There really isn't such a thing as "a function that looks like an S3
method, but isn't". If it looks like an S3 method, then in the proper
circumstances, it will be called as one.
In your case the function name is levels.no, and it isn't exported.
So if you happen to have an object with a class inheriting from "no",
and you call levels() on it, levels.no might be called.
This will only affect users of your package indirectly. If they have
objects inheriting from "no" and call levels() on them, levels.no will
not be called. But if they pass such an object to one of your package
functions, and that function calls levels() on it, they could end up
calling levels.no(). It all depends on what other classes that object
inherits from.
You can test this yourself. Set debugging on any one of your
functions, then call it in the normal way. Then while still in the
debugger set debugging on levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named
gen.cl will be invoked by the generic gen for class cl, so do not name
functions in this style unless they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename
levels.no to something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword internal
does not solve the problem, the note is still there. Any other proposals
for properly documenting a function that looks like an S3 method, but
isn't?
Best, Ulrike
Am 05.05.2023 um 12:56 schrieb Iris Simmons:
You can add
\keyword{internal}
to the Rd file. Your documentation won't show up the in the pdf
manual, it won't show up in the package index, but you'll still be
able to access the doc page with ?levels.no <http://levels.no> or
help("levels.no <http://levels.no>").
This is usually used in a package's deprecated and defunct doc pages,
but you can use it anywhere.
On Fri, May 5, 2023, 06:49 Ulrike Groemping
wrote:
Dear package developeRs,
I am working on fixing some notes regarding package DoE.base.
One note refers to the function levels.no <http://levels.no> and
complains that the
function is not documented as a method for the generic function
levels.
Actually, it is not a method for the generic levels, but a
standalone
internal function that I like to have documented.
Is there a way to document the function without renaming it and
without
triggering a note about method documentation?
Best, Ulrike
--
##
## Prof. Ulrike Groemping
## FB II
## Berliner Hochschule für Technik (BHT)
##
## prof.bht-berlin.de/groemping
<http://prof.bht-berlin.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-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] Unfortunate function name generic.something
There really isn't such a thing as "a function that looks like an S3
method, but isn't". If it looks like an S3 method, then in the proper
circumstances, it will be called as one.
In your case the function name is levels.no, and it isn't exported. So
if you happen to have an object with a class inheriting from "no", and
you call levels() on it, levels.no might be called.
This will only affect users of your package indirectly. If they have
objects inheriting from "no" and call levels() on them, levels.no will
not be called. But if they pass such an object to one of your package
functions, and that function calls levels() on it, they could end up
calling levels.no(). It all depends on what other classes that object
inherits from.
You can test this yourself. Set debugging on any one of your functions,
then call it in the normal way. Then while still in the debugger set
debugging on levels.no, and create an object using
x <- structure(1, class = "no")
and call levels(x). You should break to the code of levels.no.
That is why the WRE manual says "First, a caveat: a function named
gen.cl will be invoked by the generic gen for class cl, so do not name
functions in this style unless they are intended to be methods."
So probably the best solution (even if inconvenient) is to rename
levels.no to something that doesn't look like an S3 method.
Duncan Murdoch
On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
Thank your for the solution attempt. However, using the keyword internal
does not solve the problem, the note is still there. Any other proposals
for properly documenting a function that looks like an S3 method, but isn't?
Best, Ulrike
Am 05.05.2023 um 12:56 schrieb Iris Simmons:
You can add
\keyword{internal}
to the Rd file. Your documentation won't show up the in the pdf
manual, it won't show up in the package index, but you'll still be
able to access the doc page with ?levels.no <http://levels.no> or
help("levels.no <http://levels.no>").
This is usually used in a package's deprecated and defunct doc pages,
but you can use it anywhere.
On Fri, May 5, 2023, 06:49 Ulrike Groemping
wrote:
Dear package developeRs,
I am working on fixing some notes regarding package DoE.base.
One note refers to the function levels.no <http://levels.no> and
complains that the
function is not documented as a method for the generic function
levels.
Actually, it is not a method for the generic levels, but a standalone
internal function that I like to have documented.
Is there a way to document the function without renaming it and
without
triggering a note about method documentation?
Best, Ulrike
--
##
## Prof. Ulrike Groemping
## FB II
## Berliner Hochschule für Technik (BHT)
##
## prof.bht-berlin.de/groemping <http://prof.bht-berlin.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-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] Acknowledging small functions from another package
On 04/05/2023 4:53 a.m., Ivan Krylov wrote:
On Thu, 4 May 2023 09:21:17 +0100
David Hugh-Jones wrote:
One of my packages copy-pasted some small functions (stuff like
`%||%` for is.null) from ggplot2. (Both packages are MIT-licensed.)
What is an appropriate way to acknowledge this in the DESCRIPTION
Author: or Authors@R section?
One way would be to mention Hadley Wickham:
https://github.com/tidyverse/ggplot2/commit/ef2f944863a0db8841bf628e9eb4a9faef5049e6#diff-8f53135445ab98749043fa52e438346bb9acae8e0185aa95f186d0aa021bb7e0
(`git blame` will also tell you that he later moved this function to a
different file).
I think that person('ggplot2 authors', role = 'cph', comment = 'The
%||% operator') is also fine, just like e.g. unitizer package mentions
the code taken from R itself.
You can also find this operator in multiple base R packages, currently
unexported (maybe some day...). They mention in the comments that the
operator is adapted from ggplot2.
I'd probably use role = "ctb" instead for "ggplot2 authors", and include
Posit PBC as a copyright holder (as ggplot2 does). Presumably you or
others are also copyright holders for your package and should also have
role = "cph" added so it doesn't give the impression that Posit owns
everything.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
On 03/05/2023 9:50 a.m., Ruff, Sergej wrote: I took the Seurat package as an example, because it both lists the Bioconductor Dependencies under Imports in the DESCRIPTION-File Which packages are you talking about? I don't see any BioConductor dependencies in the Imports list for the current Seurat version. Duncan Murdoch and it uses conditional functions to check if those dependencies are pre-installed. "No, it is a requirement if the package is used but is not listed in Depends or Imports. If the package is in Depends or Imports it is a waste of time to make the check: it will always succeed." that's what I also thought but I am confused why a package like Seurat then lists the dependencies in the DESCRIPTION-File and on top of that uses conditional functions to check if the package is pre-installed or not. Wouldn't that make the packagecheck function used by Seurat redundant? Sergej Ruff ---- *Von:* Duncan Murdoch *Gesendet:* Mittwoch, 3. Mai 2023 15:29:34 *An:* Ruff, Sergej; Ivan Krylov *Cc:* r-package-devel@r-project.org *Betreff:* Re: AW: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package On 03/05/2023 9:17 a.m., Ruff, Sergej wrote: Thanks, So is it just necessary for suggested packages. Those and "Enhances" packages, but hardly anyone uses "Enhances". So, is it just good practice to make a conditional check? No, it is a requirement if the package is used but is not listed in Depends or Imports. If the package is in Depends or Imports it is a waste of time to make the check: it will always succeed. I saw some packages still include it. For example the Seurat package. I don't understand your question here. Duncan Murdoch Under Utils.R (line 349-379) of the SeuratObject-Package (https://cran.r-project.org/src/contrib/Archive/SeuratObject/ <https://cran.r-project.org/src/contrib/Archive/SeuratObject/ <https://cran.r-project.org/src/contrib/Archive/SeuratObject/>>) you will find the PackageCheck-function which used by the Seurat-Package (https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/>>) to check if packages are alredy installed. You can find examples for DEseq2 under differential_expression.R (starting line 1314 or you cntr+f for packagecheck) in the Seurat.package (https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/>>) or for limma (starting line 2292). -------- *Von:* Duncan Murdoch *Gesendet:* Mittwoch, 3. Mai 2023 14:25:56 *An:* Ruff, Sergej; Ivan Krylov *Cc:* r-package-devel@r-project.org *Betreff:* Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package On 03/05/2023 8:00 a.m., Ruff, Sergej wrote: ... [ lines about current solution deleted ] Also for the future - how Do i provide Bioconductor dependencies as "Imports" for a package that I want to submit to CRAN? Just list it as you would a CRAN package. The CRAN docs talk about "mainstream repositories"; I forget what the definition is of that (maybe repositories listed in `file.path(R.home(), "etc/repositories")`?), but definitely BioConductor is included. Do I need to make that also conditional? I know I should provide Installation description in a readme fiel but how do I make sure No, you don't need to check. If any imported package is not available, your package will not load, so errors will happen before you ever get to running examples. that the Bioconductor dependencies dont cause a rejection from CRAN? Just make sure they exist on BioC and your code works with them. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
On 03/05/2023 9:17 a.m., Ruff, Sergej wrote: Thanks, So is it just necessary for suggested packages. Those and "Enhances" packages, but hardly anyone uses "Enhances". So, is it just good practice to make a conditional check? No, it is a requirement if the package is used but is not listed in Depends or Imports. If the package is in Depends or Imports it is a waste of time to make the check: it will always succeed. I saw some packages still include it. For example the Seurat package. I don't understand your question here. Duncan Murdoch Under Utils.R (line 349-379) of the SeuratObject-Package (https://cran.r-project.org/src/contrib/Archive/SeuratObject/ <https://cran.r-project.org/src/contrib/Archive/SeuratObject/>) you will find the PackageCheck-function which used by the Seurat-Package (https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/>) to check if packages are alredy installed. You can find examples for DEseq2 under differential_expression.R (starting line 1314 or you cntr+f for packagecheck) in the Seurat.package (https://cran.r-project.org/src/contrib/Archive/Seurat/ <https://cran.r-project.org/src/contrib/Archive/Seurat/>) or for limma (starting line 2292). -------- *Von:* Duncan Murdoch *Gesendet:* Mittwoch, 3. Mai 2023 14:25:56 *An:* Ruff, Sergej; Ivan Krylov *Cc:* r-package-devel@r-project.org *Betreff:* Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package On 03/05/2023 8:00 a.m., Ruff, Sergej wrote: ... [ lines about current solution deleted ] Also for the future - how Do i provide Bioconductor dependencies as "Imports" for a package that I want to submit to CRAN? Just list it as you would a CRAN package. The CRAN docs talk about "mainstream repositories"; I forget what the definition is of that (maybe repositories listed in `file.path(R.home(), "etc/repositories")`?), but definitely BioConductor is included. Do I need to make that also conditional? I know I should provide Installation description in a readme fiel but how do I make sure No, you don't need to check. If any imported package is not available, your package will not load, so errors will happen before you ever get to running examples. that the Bioconductor dependencies dont cause a rejection from CRAN? Just make sure they exist on BioC and your code works with them. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to declare Bioconductor Dependencies in the Description File of my R Package
On 03/05/2023 8:00 a.m., Ruff, Sergej wrote: ... [ lines about current solution deleted ] Also for the future - how Do i provide Bioconductor dependencies as "Imports" for a package that I want to submit to CRAN? Just list it as you would a CRAN package. The CRAN docs talk about "mainstream repositories"; I forget what the definition is of that (maybe repositories listed in `file.path(R.home(), "etc/repositories")`?), but definitely BioConductor is included. Do I need to make that also conditional? I know I should provide Installation description in a readme fiel but how do I make sure No, you don't need to check. If any imported package is not available, your package will not load, so errors will happen before you ever get to running examples. that the Bioconductor dependencies dont cause a rejection from CRAN? Just make sure they exist on BioC and your code works with them. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to format the NEWS.md file for CRAN submissions?
On 24/04/2023 4:39 p.m., Konrad Rudolph wrote: My package is creating a CRAN check NOTE because CRAN does not like the way my NEWS.md file [1] is formatted. I am largely adhering to existing conventions with regards to my NEWS.md, in particular the (rather minimal) GNU conventions [2] mentioned in R-exts as well as the conventions used by ‘pkgdown’ to compile the file into a web page. The one peculiarity of my NEWS.md file (and where it diverges from the documented ‘pkgdown’ convention) is caused by the fact that my package has undergone a name change in the past. As a consequence, not all headings in the NEWS.md file follow the format `# ‹pkgname› ‹version›`. Consequently, the CRAN check complains Cannot extract version info from the following section titles: modules 0.x I have two questions: 1. Am I overlooking where the CRAN requirements for NEWS files are documented? As far as I can see I am not violating a documented rule. The documentation is in the ?util::news help topic. It says: "File ‘NEWS.md’ should contain the news in Markdown (following the CommonMark (https://commonmark.org/) specification), with the primary heading level giving the version number after a prefix followed by a space, and optionally followed by a space and a parenthesized ISO 8601 format date." 2. What is the best way of avoiding this NOTE _without_ dropping the changelog pre package name change? In particular, since ‘pkgdown’ does not support this I would like keep these changes in a single NEWS.md file rather than moving them into a separate file. Likewise, I think it would be misleading (and hence undesirable) to change the section headings to use the current package name for the old revisions. I don't think it cares what the prefix is, so you could use something other than the current package name there. Duncan Murdoch [1] https://github.com/klmr/box/blob/9f35bd28b26306fe94ade874c2b93a89ae3f3a61/NEWS.md [2] https://www.gnu.org/prep/standards/standards.html#NEWS-File Cheers, Konrad __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package not passing automatic checks: no clue as to what is causing 2 notes
The tidy.exe program is used in some checks of help files. The error messages you have say that it failed to run. I think that was an issue on the CRAN machine, not an issue with your package, so I'd follow the instructions in the email you received from CRAN to let them know the rejection appears to be a false positive. Duncan Murdoch On 12/04/2023 4:05 a.m., Gianmarco Alberti wrote: Dear All, I trust this email finds you doing well. I had planned to release a new version of my package, and everything was checking perfectly on my machine and using the ‘devtools’ functions check_win_oldrelease(), check_win_release(), and check_win_devel(). However, after submitting the package to CRAN, I have been notified that the package does not pass the automatic incoming checks. I had a look at the log file (https://win-builder.r-project.org/incoming_pretest/movecost_2.0_20230412_090758/Windows/00check.log) and I see two notes which I do not understand: * checking HTML version of manual ... [6s] NOTE Encountered the following conversion/validation errors: 'CreateProcess' failed to run 'd:\rtools43\x86_64-w64-mingw32.static.posix\bin\tidy.exe -language en -qe --drop-empty-elements no D:\temp\Rtmp29JsRe\file2426857b24734' 'CreateProcess' failed to run 'd:\rtools43\x86_64-w64-mingw32.static.posix\bin\tidy.exe -language en -qe --drop-empty-elements no D:\temp\Rtmp29JsRe\file2426857b24734' * checking for detritus in the temp directory ... NOTE Found the following files/directories: 'lastMiKTeXException' Do you have any suggestion as to what can possibly cause those issues, and how to fix them? Thanks -- Dr Gianmarco Alberti | Lecturer in Spatial Forensics BA, MA, PhD (Udine) - Coordinator of the BA dissertations Department of Criminology - Faculty for Social Wellbeing Room 332, Humanities B (FEMA) University of Malta Msida - MSD 2080 (Malta) +356 2340 3718 Google Scholar: https://scholar.google.com/citations?user=tFrJKQ0J=en ResearchGate: https://www.researchgate.net/profile/Gianmarco_Alberti4 Academia: https://malta.academia.edu/GianmarcoAlberti movecost: https://CRAN.R-project.org/package=movecost chisquare: https://CRAN.R-project.org/package=chisquare CAinterprTools: https://CRAN.R-project.org/package=CAinterprTools [[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] Problems on R-devel because of changes in stats family function
On 11/04/2023 3:37 a.m., Rossum, Bart-Jan van wrote: Hi, When submitting a new version of my LMMsolver package to CRAN, it fails on the automated tests, see: Windows: https://win-builder.r-project.org/incoming_pretest/LMMsolver_1.0.5_20230407_120945/Windows/00check.log I managed to track this down to a change in the output of the family function in the stats package: https://search.r-project.org/R/refmans/stats/html/family.html More specifically, it is about a new output in the call to family(): dispersion (optional since R version 4.3.0) numeric: value of the dispersion parameter, if fixed, or NA_real_ if free. Even though the documentation seems to suggest this output is optional, I don't see a way to suppress it. In all my calls to family I get an extra output dispersion with value NA. I need to store the family information in my own outputs for further processing. Also my output are quite complex by themselves so I tend to check my full output objects with outputs previously stored. Exactly this is giving me problems now. In R 4.3 all of my outputs will have an extra item as well, causing the tests to fail. I am not sure how to solve this. I could suppress the affected tests when an installation of stats with version >= 4.3 is detected, but that doesn't feel good. Do you have any other suggestions on how to solve this. One way to solve it would be to set the dispersion parameter to NULL before doing your comparison. That should work across R versions. For example, f <- gaussian() f$dispersion <- NULL expect_equal_to_reference(f, "family") Another possibility would be to save two reference values, e.g. f <- gaussian() expect_equal_to_reference(f, if (getRversion() < 4.3.0) "oldfamily" else "newfamily") You should do some sort of manual comparison when those two reference values are first created to make sure there are no other changes. Duncan Murdoch __ 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
Your message is posted using HTML, which mangles a lot of it. For
example, the NAMESPACE file you posted has URLs mixed in with the text.
But if I can guess correctly what was in those files, it looks as though
the package being checked doesn't have those files in it. I don't know
exactly what devtools::check does, but it's probably your problem.
I'd suggest this: build the tarball, and check the tarball.
Duncan Murdoch
On 04/04/2023 9:41 a.m., Dennis Boos wrote:
Thanks so much to all of you. If you have time, I'm getting really
contradictory results.
1. It first seemed to have passed the check in Rstudio (I used
device::build() in the R window and then clicked on check in the drop
down menu under build).
==> devtools::check(document = FALSE, args = c('--as-cran'))
── R CMD check results Monte.Carlo.se <http://Monte.Carlo.se> 0.1.1
Duration: 56.6s 0 errors ✔| 0 warnings ✔| 0 notes ✔R CMD check succeeded
However, I then couldn't find the tar.gz where it was supposed to be. It
was just gone.
Here is my namespace. It says not to edit, but I had been told to add
the importFrom. So I didn't use
devtools::document() for fear roxygen2 would get rid of it.
# Generated by roxygen2: do not edit by hand
importFrom("stats", "cor", "sd", "var")
export(boot.se <http://boot.se>)
export(jack.se <http://jack.se>)
export(mc.se.matrix)
export(mc.se.vector)
export(pairwise.se <http://pairwise.se>)
export(sim.samp)
4.Here is my DESCRIPTION file
Package:Monte.Carlo.se <http://Monte.Carlo.se>
Type: Package
Title: Monte Carlo Standard Errors
Version: 0.1.1
Author: Dennis Boos, Kevin Matthew, Jason Osborne
Maintainer: Dennis Boos mailto:b...@ncsu.edu>>
Description: Computes Monte Carlo standard errors for summaries of Monte Carlo
output. Summaries and their standard errors are based on columns of Monte Carlo
simulation output. Dennis D. Boos and Jason A. Osborne (2015)
.
License: GPL-3
Encoding: UTF-8
RoxygenNote: 7.2.3
Suggests: knitr, rmarkdown
Imports: stats
VignetteBuilder: knitr
5.And because of your advice: " It sounds as though you're using Roxygen2 to
generate your NAMESPACE file.
ff so, you need @imports directives in the comments
(conventionally before the function that uses the import, but I think it
doesn't really matter where)."
So I put "@imports" in the function that had trouble
#' @examples
#' \donttest{
#' # Using the output data matrix hold generated in vignette Example3,
#' # calculate jackknife and bootstrap standard errors
#' # for the differences and ratios of the CV estimates.
#' # First get the components of hold needed.
#'
#' @imports
#'
#' trim20 <- function(x){mean(x,.2)} # 20% trimmed mean function
Was that the correct thing to do?
6.And here are the failed check results. I'm clueless at this point.
==> devtools::check(document = FALSE, args = c('--as-cran'))
══BuildingSetting env vars:• CFLAGS : -Wall -pedantic -fdiagnostics-color=always• CXXFLAGS : -Wall -pedantic -fdiagnostics-color=always• CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always• CXX14FLAGS: -Wall -pedantic -fdiagnostics-color=always• CXX17FLAGS: -Wall -pedantic -fdiagnostics-color=always• CXX20FLAGS: -Wall -pedantic -fdiagnostics-color=always──R CMD build─✔checking for file 'C:\Users\boos\Dropbox\My PC (boos-home)\Desktop\dennis\R.packages\Monte.Carlo.se.March.2023/DESCRIPTION'... ─preparing 'Monte.Carlo.se <http://Monte.Carlo.se>':✔checking DESCRIPTION meta-information... ─installing the package to build vignettes✔creating vignettes(3.6s)─checking for LF line-endings in source and make files and shell scripts─checking for empty or unneeded directories─building 'Monte.Carlo.se_0.1.1.tar.gz'══CheckingSetting env vars:• _R_CHECK_CRAN_INCOMING_REMOTE_ : FALSE• _R_CHECK_CRAN_INCOMING_ : FALSE• _R_CHECK_FORCE_SUGGESTS_ : FALSE• _R_CHECK_PACKAGES_USED_IGNORE_UNUSED_IMPORTS_: FALSE• NOT_CRAN : true── R CMD check ──using log directory 'C:/Users/boos/Dropbox/My PC (boos-home)/Desktop/dennis/R.packages/Monte.Carlo.se.Rcheck'(793ms)─using R version 4.2.3 (2023-03-15 ucrt)─ using platform: x86_64-w64-mingw32 (64-bit)─ using session charset: UTF-8─using options '--no-manual --as-cran'(653ms)✔checking for file 'Monte.Carlo.se/DESCRIPTION <http://Monte.Carlo.se/DESCRIPTION>'─ checking extension type ... Package─ this is package 'Monte.Carlo.se <http://Monte.Carlo.se>' version '0.1.1'─ package encoding: UTF
Re: [R-pkg-devel] Vignette rebuilding failed
The error message seems pretty clear: "The function xfun::isFALSE() will be deprecated in the future. Please consider using base::isFALSE(x) or identical(x, FALSE) instead". So don't use xfun::isFALSE(). Duncan Murdoch On 31/03/2023 5:01 p.m., Deepankar Basu wrote: Hello All, I am in the process of developing an R package ( https://github.com/dbasu-umass/clptheory) and have encountered problems with the vignette. I had initially been able to build the vignette but *after *I added a new function to my package, I have been getting the error message that "Vignette rebuilding failed" when I use devtools:check(). If I use devtools:check(vignette=FALSE), there are no error messages. I can also compile the vignette with knitr. Below is the output from devtools:check(vignette=FALSE) devtools::check(vignettes = FALSE) ══ Documenting ═ ℹ Updating clptheory documentation ℹ Loading clptheory ══ Building Setting env vars: • CFLAGS: -Wall -pedantic -fdiagnostics-color=always • CXXFLAGS : -Wall -pedantic -fdiagnostics-color=always • CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always • CXX14FLAGS: -Wall -pedantic -fdiagnostics-color=always • CXX17FLAGS: -Wall -pedantic -fdiagnostics-color=always • CXX20FLAGS: -Wall -pedantic -fdiagnostics-color=always ── R CMD build ─ ✔ checking for file ‘/home/basu15/MyRProjects/clptheory/DESCRIPTION’ ... ─ preparing ‘clptheory’: ✔ checking DESCRIPTION meta-information ... ─ checking for LF line-endings in source and make files and shell scripts ─ checking for empty or unneeded directories ─ building ‘clptheory_0.0.0.9000.tar.gz’ ══ Checking Setting env vars: • _R_CHECK_CRAN_INCOMING_USE_ASPELL_ : TRUE • _R_CHECK_CRAN_INCOMING_REMOTE_ : FALSE • _R_CHECK_CRAN_INCOMING_ : FALSE • _R_CHECK_FORCE_SUGGESTS_ : FALSE • _R_CHECK_PACKAGES_USED_IGNORE_UNUSED_IMPORTS_: FALSE • NOT_CRAN : true ── R CMD check ─ ─ using log directory ‘/tmp/RtmpCSbZbZ/file3f721a56f9d0/clptheory.Rcheck’ ─ using R version 4.2.3 (2023-03-15) ─ using platform: x86_64-pc-linux-gnu (64-bit) ─ using session charset: UTF-8 ─ using options ‘--no-manual --ignore-vignettes --as-cran’ ✔ checking for file ‘clptheory/DESCRIPTION’ ─ this is package ‘clptheory’ version ‘0.0.0.9000’ ─ package encoding: UTF-8 ✔ checking package namespace information ✔ checking package dependencies (2.5s) ✔ checking if this is a source package ... ✔ checking if there is a namespace ✔ checking for executable files ... ✔ checking for hidden files and directories ... ✔ checking for portable file names ✔ checking for sufficient/correct file permissions ✔ checking serialization versions ... ✔ checking whether package ‘clptheory’ can be installed (7.1s) ✔ checking installed package size ✔ checking package directory ... ✔ checking for future file timestamps ... ✔ checking DESCRIPTION meta-information ... ✔ checking top-level files ... ✔ checking for left-over files ✔ checking index information ✔ checking package subdirectories ... ✔ checking R files for non-ASCII characters ... ✔ checking R files for syntax errors ... ✔ checking whether the package can be loaded (1.8s) ✔ checking whether the package can be loaded with stated dependencies (1.6s) ✔ checking whether the package can be unloaded cleanly (1.6s) ✔ checking whether the namespace can be loaded with stated dependencies (1.6s) ✔ checking whether the namespace can be unloaded cleanly (1.8s) ✔ checking loading without being on the library search path (1.8s) ✔ checking dependencies in R code (1.7s) ✔ checking S3 generic/method consistency (2.4s) ✔ checking replacement functions (1.7s) ✔ checking foreign function calls (1.7s) ✔ checking R code for possible problems (9.5s) ✔ checking Rd files ... ✔ checking Rd metadata ... ✔ checking Rd line widths ... ✔ checking Rd cross-references ... ✔ checking for missing documentation entries (1.7s) ✔ checking for code/documentation mismatches (5.1s) ✔ checking Rd \usage sections (2.5s) ✔ checking Rd contents ... ✔ checking for unstated dependencies in examples ... ✔ checking contents of ‘data’ directory ... ✔ checking data for non-ASCII characters (413ms) ✔ checking LazyData ✔ checking data for ASCII and uncompressed saves ... ─ checking files in ‘vignettes’ ... SKIPPED ✔ checking examples (4.9s) ✔ checking for non-standard things in the check directory ✔ checking for detritus in the temp direct
