There are a few ways to deal with this, but waiting for ff to be updated
is probably easiest.
However, maybe ff can't be updated until bit is updated. Here are some
possibilities:
One way is to make bit depend on a particular version of ff. That may
cause a deadlock if both are being updated at once, but I think CRAN
should be able to deal with it if they are informed of the issue.
Another way is to use R code in the Rd file to select which link to use.
For example, instead of \link[ff]{clone.ff}, you could use
\Sexpr[results=rd,stage=render]{clonelink()}
where clonelink() is a function that generates either
"\link[ff]{clone.ff}" or "\link[ff:clone]{clone.ff}" depending on the
detected installed version of ff.
Another choice that is nearly as easy as doing nothing is to include no
link at all in this update, and make it a link again in the next update
when the new ff is available.
Duncan Murdoch
On 02/07/2020 6:47 a.m., Dr. Jens Oehlschlägel wrote:
Thanks Gabor and Duncan,
It's actually in ff/man/clone.rd, not clone.ff.rd. There is no
ff/man/clone.ff.rd file.
but there *is* clone.ff.rd in the >= 4.0.0 versions of the packages
bit/bit64/ff.
Hence the check warning is a false alarm resulting from checking bit 4.0.2
(GitHub.com/truecluster) against ff 2.2-14.2 (CRAN) instead of checking it
against the also submitted ff 4.0.2 (GitHub.com/truecluster).
So all I can and will do is waiting that CRAN maintainers install and check
again.
Best
Jens
Duncan Murdoch
Best regards
Jens
On 16.06.20 22:31, Gábor Csárdi wrote:
This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.
help("sp", "sp")[[1]]
[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
So you need to link to the "00sp.Rd" file: \link[sp:00sp]{sp}
Gabor
On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldf...@uwaterloo.ca> wrote:
Hi
I got caught by this new test this week in trying to push an updated release of
the loon package to CRAN.
By following this thread, I corrected my cross-references to external packages
but I got stymied by
the one I hoped to give to the "sp" package for Spatial data
_________
Here is the history:
I tried
\link[sp:sp]{sp}
which failed here:
Debian:
<https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING
That was meant to correct an earlier attempt (it did for other links to
"scales" for example) where I had tried
\link[sp]{sp}
and failed here:
Debian:
<https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING
So to complete the possibilities as I understand them, I just now tried
\link{sp}
which, as might be expected, failed here:
Debian:
<https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different: "Missing link" as opposed to "Non-file
package-anchored link"
_________
I am not sure whether I have missed a subtlety in WRE or that the peculiar
circumstance
where the package, the topic, and the file name are all identical (sp) is some
weird boundary case.
Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".
Thanks in advance for your thoughts.
Wayne
-----Original Message-----
From: R-package-devel <r-package-devel-boun...@r-project.org> on behalf of Georgi
Boshnakov <georgi.boshna...@manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: Gábor Csárdi <csardi.ga...@gmail.com>, Duncan Murdoch
<murdoch.dun...@gmail.com>
Cc: List r-package-devel <r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file
package-anchored link(s)
I think that the current behaviour is documented in WRE:
"...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.
These are rarely needed, perhaps to refer to not-yet-installed packages
(but there the HTML
help system will resolve the link at run time) or in the normally
undesirable event that more
than one package offers help on a topic7 (in which case the present
package has precedence so
this is only needed to refer to other packages). They are currently only
used in HTML help
(and ignored for hyperlinks in LATEX conversions of help pages), and
link to the file rather
than the topic (since there is no way to know which topics are in which
files in an uninstalled
package) ... Because they have been frequently misused, the HTML help
system looks for topic foo in package pkg
if it does not find file foo.html."
Unless I am missing something, it seems that it would be relatively
painless to reverse the logic of the current behaviour of the help system,
i.e. to start looking first for the topic and then for a file.
Georgi Boshnakov
-----Original Message-----
From: R-package-devel <r-package-devel-boun...@r-project.org> On Behalf
Of Gábor Csárdi
Sent: 16 June 2020 13:44
To: Duncan Murdoch <murdoch.dun...@gmail.com>
Cc: List r-package-devel <r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file
package-anchored link(s)
On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch
<murdoch.dun...@gmail.com> wrote:
>
> On 15/06/2020 12:05 p.m., Martin Maechler wrote:
> >>>>>> Duncan Murdoch on Sun, 14 Jun 2020 07:28:03 -0400 writes:
> >
> > > I agree with almost everything you wrote, except one thing:
this isn't
> > > newly enforced, it has been enforced since the help system
began. What
> > > I think is new is that there are now tests for it.
Previously those
> > > links just wouldn't work.
> >
> > > Duncan Murdoch
> >
> > Yes, to all... including Duncan's agreement with Gábor.
> >
> > Also, Duncan M earlier did mention that he had wanted to
> > *change* the link-to-file behavior for these cases (when he wrote
> > most of the Rd2html source code) but somehow did not get it.
>
> Actually, I don't think I pushed for this change at the time (or at
> least I didn't push much). I just wish now that I had, because I
> think it will be harder to do it now than it would have been then.
>
> Duncan
I am not entirely sure, but maybe just documenting the current behaviour
and undoing 78674 could work. With some tweaks? E.g.
* updating R-exts to say that \link[pkg:topic]{text} will link to
`topic.html` in `pkg` first (for historical reasons), and falls back to
searching for `topic` in `pkg` at render time.
* updating Rd2HTML to look for the topic and use it in the link, instead
of throwing a warning, in it cannot find `topic.html`
* removing the `R CMD check` warning for non-file links, that was added
in 78674 :)
Is there anything else?
Gabor
[...]
______________________________________________
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
______________________________________________
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
