Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On Linux you can use 'ltrace' to get a list of all the environment
variables that R looks up. E.g., do the following in 'script' so all the
output is stored in a file ('typescript') and later look around in it for
the getenv calls.
$ R-devel --debugger=ltrace --debugger-args="-f -e getenv"
...
[pid 25055] libR.so->getenv("R_HOME")
= "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("R_TRANSLATIONS")
= nil
[pid 25055] libR.so->getenv("R_PLATFORM")
= nil
...
> tools:::.check_packages(c("testFixup_0.1.tar.gz", "--as-cran"))[pid
25055] libR.so->getenv("_R_NS_LOAD_") =
nil
[pid 25055] libR.so->getenv("_R_CHECK_ELAPSED_TIMEOUT_")
= nil
[pid 25055] libR.so->getenv("R_CHECK_ENVIRON")
= nil
[pid 25055] libreadline.so.6->getenv("HOME")
= "/homes/bill"
[pid 25055] libR.so->getenv("_R_CHECK_TIMINGS_")
= nil
[pid 25055] libR.so->getenv("R_ENABLE_JIT")
= nil
[pid 25055] libR.so->getenv("R_HOME")
= "/home/R/R-devel/lib/R"
[pid 25055] libR.so->getenv("_R_CHECK_USE_INSTALL_LOG_")
= nil
[pid 25055] libR.so->getenv("_R_CHECK_SUBDIRS_NOCASE_")
= nil
[pid 25055] libR.so->getenv("_R_CHECK_ALL_NON_ISO_C_")
= nil
... hundreds more lines ...
> q("no")
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Jul 2, 2020 at 7:24 AM Jan Gorecki wrote:
> Thank you Gabor
>
> On Thu, Jul 2, 2020 at 10:20 AM Gábor Csárdi
> wrote:
> >
> > You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
> > use R-devel.
> >
> > Alternatively, and you don't need R-devel for this, you can run R CMD
> > --html INSTALL on your package, and then look for messages that
> > contain "treated as a topic", e.g.
> >
> > curl_fdshtml
> > Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
> > link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
> > treated as a topic
> >
> > Gabor
> >
> >
> > On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki
> wrote:
> > >
> > > Hi,
> > > What is the recommended way to test for those issues locally?
> > > If it is tested during cran submission, then seems reasonable to be
> enabled just by --as-cran switch. Is it?
> > > Thanks
> > >
> > > On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford,
> wrote:
> > >>
> > >> Thank you!
> > >>
> > >> -Original Message-
> > >> From: Gábor Csárdi
> > >> Date: Tuesday, June 16, 2020 at 4:32 PM
> > >> To: Wayne Oldford
> > >> Cc: List r-package-devel
> > >> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
> > >>
> > >> 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
>
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On 02/07/2020 10:41 a.m., Dr. Jens Oehlschlägel wrote: Thank you for the advice Duncan, But let's not get carried away here: we are talking about a *warning* that only arises if two packages are checked together that are never meant to be installed together. The new packages contain weeks of improvement-work, and I am not going to add back-and-forth-trick-work just to circumvent some warnings that arise only at the point of switching from old to new. That's a choice, but your package might face auto-rejection on CRAN. Asking CRAN to handle your update manually means extra work for them; if there's a simple way to handle it without that (and I've given you two to choose from), it seems kind of selfish not to use it. BTW, assuming you got the two packages on CRAN, it wouldn't be hard for a user to install the new bit without updating ff: just have both installed before your update, then ask to update bit. Since it doesn't depend on ff, it won't trigger an ff update. You can't expect R to know they were never meant to be installed together unless you record that fact in the dependencies in the DESCRIPTION file. Duncan Murdoch If there is a problem when checking the new packages together that's a different story and worth taking care about. I didn't find such problems. Kind regards Jens Gesendet: Donnerstag, 02. Juli 2020 um 15:23 Uhr Von: "Duncan Murdoch" An: "Dr. Jens Oehlschlägel" , r-package-devel@r-project.org Betreff: Re: Aw: Re: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s) On 02/07/2020 7:49 a.m., Dr. Jens Oehlschlägel wrote: Duncan, 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. Exactly that I have done: I submitted all three packages bit/bit64/ff in version 4.0.2 and made them dependend on Version >= 4.0.0. And yes, the maintainers have been informed about the issue. I'm not sure that's what I meant, but I can't be sure, since I haven't seen your source. What I meant is a package dependency, i.e. the existing ff on CRAN is version 2.2-14.2 and it depends on bit without saying what version of bit is needed. The existing bit is 1.1-15.2 with no dependency on ff. So you can force the new ff to use the new bit by giving the version number, e.g. Depends: bit (>= 2.0) but it's not so obvious how to make the new bit depend on the new ff. There's no way to say that the dependency is only to a help page, and circular strong dependencies are messy, so I'd suggest you use one of the other options I offered: a dynamic link in the Rd file, or no link at all. 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)
Thank you for the advice Duncan, But let's not get carried away here: we are talking about a *warning* that only arises if two packages are checked together that are never meant to be installed together. The new packages contain weeks of improvement-work, and I am not going to add back-and-forth-trick-work just to circumvent some warnings that arise only at the point of switching from old to new. If there is a problem when checking the new packages together that's a different story and worth taking care about. I didn't find such problems. Kind regards Jens > Gesendet: Donnerstag, 02. Juli 2020 um 15:23 Uhr > Von: "Duncan Murdoch" > An: "Dr. Jens Oehlschlägel" , > r-package-devel@r-project.org > Betreff: Re: Aw: Re: Re: [R-pkg-devel] check cross-references error: Non-file > package-anchored link(s) > > On 02/07/2020 7:49 a.m., Dr. Jens Oehlschlägel wrote: > > Duncan, > > > >> 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. > > > > Exactly that I have done: I submitted all three packages bit/bit64/ff in > > version 4.0.2 and made them dependend on Version >= 4.0.0. > > And yes, the maintainers have been informed about the issue. > > I'm not sure that's what I meant, but I can't be sure, since I haven't > seen your source. What I meant is a package dependency, i.e. the > existing ff on CRAN is version 2.2-14.2 and it depends on bit without > saying what version of bit is needed. The existing bit is 1.1-15.2 with > no dependency on ff. > > So you can force the new ff to use the new bit by giving the version > number, e.g. > > Depends: bit (>= 2.0) > > but it's not so obvious how to make the new bit depend on the new ff. > There's no way to say that the dependency is only to a help page, and > circular strong dependencies are messy, so I'd suggest you use one of > the other options I offered: a dynamic link in the Rd file, or no link > at all. > > 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)
Thank you Gabor
On Thu, Jul 2, 2020 at 10:20 AM Gábor Csárdi wrote:
>
> You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
> use R-devel.
>
> Alternatively, and you don't need R-devel for this, you can run R CMD
> --html INSTALL on your package, and then look for messages that
> contain "treated as a topic", e.g.
>
> curl_fdshtml
> Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
> link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
> treated as a topic
>
> Gabor
>
>
> On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki wrote:
> >
> > Hi,
> > What is the recommended way to test for those issues locally?
> > If it is tested during cran submission, then seems reasonable to be enabled
> > just by --as-cran switch. Is it?
> > Thanks
> >
> > On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, wrote:
> >>
> >> Thank you!
> >>
> >> -Original Message-
> >> From: Gábor Csárdi
> >> Date: Tuesday, June 16, 2020 at 4:32 PM
> >> To: Wayne Oldford
> >> Cc: List r-package-devel
> >> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> >> package-anchored link(s)
> >>
> >> 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
> >> 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:
> >>
> >> > 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:
> >>
> >> > 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:
> >>
> >> > 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 on
> >> behalf of Georgi Boshnakov
> >> > Date: Tuesday, June 16, 2020 at 9:27 AM
> >> > To: Gábor Csárdi , Duncan Murdoch
> >>
> >> > Cc: List r-package-devel
> >> > 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
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On 02/07/2020 7:49 a.m., Dr. Jens Oehlschlägel wrote: Duncan, 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. Exactly that I have done: I submitted all three packages bit/bit64/ff in version 4.0.2 and made them dependend on Version >= 4.0.0. And yes, the maintainers have been informed about the issue. I'm not sure that's what I meant, but I can't be sure, since I haven't seen your source. What I meant is a package dependency, i.e. the existing ff on CRAN is version 2.2-14.2 and it depends on bit without saying what version of bit is needed. The existing bit is 1.1-15.2 with no dependency on ff. So you can force the new ff to use the new bit by giving the version number, e.g. Depends: bit (>= 2.0) but it's not so obvious how to make the new bit depend on the new ff. There's no way to say that the dependency is only to a help page, and circular strong dependencies are messy, so I'd suggest you use one of the other options I offered: a dynamic link in the Rd file, or no link at all. 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)
Duncan, > 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. Exactly that I have done: I submitted all three packages bit/bit64/ff in version 4.0.2 and made them dependend on Version >= 4.0.0. And yes, the maintainers have been informed about the issue. Best Jens __ 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)
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 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:
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:
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:
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 on behalf of Georgi
Boshnakov
Date: Tuesday, June 16, 2020 at 9:27 AM
To: Gábor Csárdi , Duncan Murdoch
Cc: List r-package-devel
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
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Yes, this is one consequence of the newly enforced check. Now you can
choose which version of the ff package you want to be compatible with.
In the GH version a manual file was renamed and this is now a breaking
change, so you cannot be compatible with both.
Gabor
On Thu, Jul 2, 2020 at 11:47 AM 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
> > >> 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:
> > >>>
> > >>> 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:
> > >>>
> > >>> 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:
> > >>>
> > >>> 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 on behalf
> > >>> of Georgi Boshnakov
> > >>> Date: Tuesday, June 16, 2020 at 9:27 AM
> > >>> To: Gábor Csárdi , Duncan Murdoch
> > >>>
> > >>> Cc: List r-package-devel
> > >>> 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
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
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
> >> 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:
> >>>
> >>> 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:
> >>>
> >>> 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:
> >>>
> >>> 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 on behalf
> >>> of Georgi Boshnakov
> >>> Date: Tuesday, June 16, 2020 at 9:27 AM
> >>> To: Gábor Csárdi , Duncan Murdoch
> >>>
> >>> Cc: List r-package-devel
> >>> 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 On
> >>> Behalf Of Gábor Csárdi
> >>> Sent: 16 June 2020 13:44
> >>> To: Duncan Murdoch
> >>> Cc: List r-package-devel
> >>> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> >>> package-anchored link(s)
> >>>
> >>> On Mon, Jun 15, 2020 at
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
use R-devel.
Alternatively, and you don't need R-devel for this, you can run R CMD
--html INSTALL on your package, and then look for messages that
contain "treated as a topic", e.g.
curl_fdshtml
Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
treated as a topic
Gabor
On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki wrote:
>
> Hi,
> What is the recommended way to test for those issues locally?
> If it is tested during cran submission, then seems reasonable to be enabled
> just by --as-cran switch. Is it?
> Thanks
>
> On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, wrote:
>>
>> Thank you!
>>
>> -Original Message-
>> From: Gábor Csárdi
>> Date: Tuesday, June 16, 2020 at 4:32 PM
>> To: Wayne Oldford
>> Cc: List r-package-devel
>> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
>> package-anchored link(s)
>>
>> 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
>> 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:
>>
>> > 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:
>>
>> > 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:
>>
>> > 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 on
>> behalf of Georgi Boshnakov
>> > Date: Tuesday, June 16, 2020 at 9:27 AM
>> > To: Gábor Csárdi , Duncan Murdoch
>>
>> > Cc: List r-package-devel
>> > 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
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Hi,
What is the recommended way to test for those issues locally?
If it is tested during cran submission, then seems reasonable to be enabled
just by --as-cran switch. Is it?
Thanks
On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, wrote:
> Thank you!
>
> -Original Message-
> From: Gábor Csárdi
> Date: Tuesday, June 16, 2020 at 4:32 PM
> To: Wayne Oldford
> Cc: List r-package-devel
> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
>
> 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
> 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 on
> behalf of Georgi Boshnakov
> > Date: Tuesday, June 16, 2020 at 9:27 AM
> > To: Gábor Csárdi , Duncan Murdoch <
> murdoch.dun...@gmail.com>
> > Cc: List r-package-devel
> > 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
> On Behalf Of Gábor Csárdi
> > Sent: 16 June 2020 13:44
> > To: Duncan Murdoch
> > Cc: List r-package-devel
> > 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
