Re: [R-pkg-devel] [External] Guidelines on use of snow-style clusters in R packages?
On Wed, 3 Jun 2020 08:54:56 -0500 (CDT) luke-tier...@uiowa.edu wrote: > If you use [a cluster] passed to you it would be best to leave > it in the state you found it at least as far as the search path and > global environment are concerned. Thanks for this advice! I guess that clusterExport() is also out of question in package code, then. > So use foo::bar instead of library(). I have found out that R Internals documents serialize() to use a very efficient representation for package environments (a pseudo-SEXPTYPE followed by the name). Does it mean that it is a good idea to pass unexported private worker functions to parLapply(cl, X, fun), since the package environment is not sent over network? -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Hello,
I noticed a strange error pop up for R-devel (2020-06-12 r78687) check on
travis:
https://travis-ci.org/github/grunwaldlab/poppr/jobs/697831376#L4653-L4654
* checking Rd cross-references ... WARNING
Non-file package-anchored link(s) in documentation object 'aboot.Rd':
‘[ape:phylo]{ape::phylo()}’
I looked at the Cross-reference section of WRE, but I couldn't find any mention
of non-file package-anchored links being a problem:
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Cross_002dreferences
Is this a new policy?
All the best,
Zhian
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On 13/06/2020 1:17 p.m., Zhian Kamvar wrote:
Hello,
I noticed a strange error pop up for R-devel (2020-06-12 r78687) check on
travis:
https://travis-ci.org/github/grunwaldlab/poppr/jobs/697831376#L4653-L4654
* checking Rd cross-references ... WARNING
Non-file package-anchored link(s) in documentation object 'aboot.Rd':
‘[ape:phylo]{ape::phylo()}’
I looked at the Cross-reference section of WRE, but I couldn't find any mention
of non-file package-anchored links being a problem:
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Cross_002dreferences
Is this a new policy?
This is probably a new test of the long-time requirement that links
should be to filenames, not aliases, when they go to other packages.
WRE says
"There are two other forms of optional argument specified as
\link[pkg]{foo} and \link[pkg:bar]{foo} to link to the package pkg, to
files foo.html and bar.html respectively."
The problem is that `phylo` is documented in the read.tree.Rd file in
ape, so your link needs to be
\link[ape:read.tree]{ape::phylo()}
I wish I had fixed this inconsistency years ago when I rewrote the Rd
code, but I didn't. It would have been painful at the time (there were
already thousands of CRAN packages, and lots would have needed fixing),
but would be much worse now.
Another design flaw that I didn't fix is that you can have an Rd with
\name{foo} and no \alias{foo}, and searching ?foo won't find it. In
that case I failed to convince other R core members that it would have
been a good change.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On Sat, Jun 13, 2020 at 8:10 PM Duncan Murdoch wrote:
>
> On 13/06/2020 1:17 p.m., Zhian Kamvar wrote:
[...]
> > Is this a new policy?
Zhian, it seems that some of the problematic links are created by
roxygen2. You can fix these using this PR:
https://github.com/r-lib/roxygen2/pull/1109
You can install this branch with
remotes::install_github("r-lib/roxygen2@fix/link-to-file")
To fix the remaining ones, you need to modify your \link[]{} macros or
switch them to roxygen [pkg::fun()] links.
[...]
> This is probably a new test of the long-time requirement that links
> should be to filenames, not aliases, when they go to other packages.
I really like how the help system resolves links based on _topics_,
even for cross-package links. So I admit that I did not follow this
requirement too closely. It is better to link to topics instead of
files, because then links are independent of how the manual is
organized into files. E.g. it is not uncommon to split up a help file
that used to document multiple functions, into several files, because
the functions gain more functionality, or need more examples, etc. and
the manual page is getting less focused and harder to follow. It is
perfectly natural that the manual of a package is evolving together
with the code.
With enforcing this requirement, such documentation changes are
considered as breaking changes. If we need to link to files, then what
we get is more broken links, and more forced package updates, just to
fix the broken links. In particular, if a package moves a help topic
to another help file in a new release, then other packages linking to
this topic have to update their links, and if these happened to be
installed together with the old version of the linked package, they'll
have a broken link. This is a pity, because finding the right help
files is easy to automate, and in fact the help system already
supports it perfectly well.
As far as I can tell the only alternative of linking to the file is
using an unqualified link, i.e. not specifying the target package at
all. The help system can do the lookup at render time, and this is
usually OK, but for a non-trivial number of cases it is not, because
the resolution of the link depends on what packages are currently
loaded. If the right package is not loaded, then the link will
potentially go to the wrong help file, which is absurd. Or, if
multiple packages have the required topic, the user is presented with
a menu, which is also confusing. OTOH the manual authors know
perfectly well which package they want to link to, they just can't
specify it any more...
I am probably missing something, but what do we gain from linking to
files, instead of topics? Especially that linking to topics already
works perfectly well?
Gabor
[...]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
