Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
On 01/07/2020 1:46 p.m., Dr. Jens Oehlschlägel wrote:
Good evening,
My package bit 4.0.2 (https://github.com/truecluster/bit) is being
rejected by CRAN checks with warning:
>Check: Rd cross-references, Result: WARNING
> Non-file package-anchored link(s) in documentation object 'clone.Rd':
>'[ff]{clone.ff}'
>
> See section 'Cross-references' in the 'Writing R Extensions' manual.
although clone.ff is in clone.ff.rd as confirmed by
> help("clone.ff","ff")[[1]]
[1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"
I asked the maintainers to explain what is wrong and what to do and got
no answer. Does someone here can help?
It's actually in ff/man/clone.rd, not clone.ff.rd. There is no
ff/man/clone.ff.rd file.
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 5:30 PM Duncan Murdoch
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 jus
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Linking to the manual _file_ is now enforced on CRAN. Here is how to
get the file name:
> help("clone.ff", package = "ff")[[1]]
[1] "/Users/gaborcsardi/Library/R/4.0/library/ff/help/clone"
So in this case you need to link to 'clone'.
Btw. since you already use roxygen2, you could also turn on markdown
support, and then [ff::clone.ff()] automatically creates the right
links in the latest version of roxygen2.
Gabor
On Wed, Jul 1, 2020 at 6:46 PM Dr. Jens Oehlschlägel
wrote:
>
> Good evening,
>
> My package bit 4.0.2 (https://github.com/truecluster/bit) is being
> rejected by CRAN checks with warning:
>
>
> >Check: Rd cross-references, Result: WARNING
> > Non-file package-anchored link(s) in documentation object 'clone.Rd':
> >'[ff]{clone.ff}'
> >
> > See section 'Cross-references' in the 'Writing R Extensions' manual.
>
> although clone.ff is in clone.ff.rd as confirmed by
>
> > help("clone.ff","ff")[[1]]
> [1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"
>
> I asked the maintainers to explain what is wrong and what to do and got
> no answer. Does someone here can help?
>
> 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
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Good evening,
My package bit 4.0.2 (https://github.com/truecluster/bit) is being
rejected by CRAN checks with warning:
>Check: Rd cross-references, Result: WARNING
> Non-file package-anchored link(s) in documentation object 'clone.Rd':
>'[ff]{clone.ff}'
>
> See section 'Cross-references' in the 'Writing R Extensions' manual.
although clone.ff is in clone.ff.rd as confirmed by
> help("clone.ff","ff")[[1]]
[1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"
I asked the maintainers to explain what is wrong and what to do and got
no answer. Does someone here can help?
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 5:30 PM Duncan Murdoch
>> 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
Re: [R-pkg-devel] R package does not find DLL routine
Dear Dirk, dear Ivan,
thanks for your suggestions. I agree that R packages aren't meant to be
build that way, and even though this is an academic project but since the
source code wasn't written by me it is not my decision if, where and when
to publish it openly. In any case, directly linking to a DLL seems quite
unstable and I just came across the option to do a system call to an
executable instead which appears to maybe be the most straight forward
solution for me.
Thanks a lot for your time and effort.
Best,
Lisa
On Sun, Jun 28, 2020 at 10:39 PM Ivan Krylov wrote:
> On Sun, 28 Jun 2020 12:43:53 +0200
> Lisa GM wrote:
>
> > "sum_c" not resolved from current namespace (sum)
>
> As mentioned by Dirk Eddelbuettel, this is not the way R packages are
> supposed to be built [*], but if you are absolutely positive you cannot
> build the DLL from source together with the package or link your
> package to externally installed DLL (as done by packages curl, rgdal,
> and many others), it still seems to be possible. I have been able to
> get a dummy package to work like this:
>
> .onLoad <- function(libname, pkgname)
> library.dynam('dynl', pkgname, libname, TRUE)
>
> .onUnload <- function(libpath)
> library.dynam.unload('dynl', libpath)
>
> do <- function()
> .C('do_hello', x = as.integer(1L), y = as.numeric(2), PACKAGE = 'dynl')
>
> (Note the extra PACKAGE argument required in absence of native routine
> registration or useDynLib(...) declarations in NAMESPACE)
>
> I placed the DLL itself in file.path('inst', 'libs',
> paste0('dynl', .Platform$dynlib.ext)) under the package source
> directory and made sure that it exports a C function
> void do_hello(int * x, double * y).
>
> Needless to say, this goes against CRAN and Bioconductor policies. The
> preferred approach is described in Writing R Extensions, section 1.2.
>
> --
> Best regards,
> Ivan
>
> [*] See sections
> 1.5.4 and 5.4 for preparing C functions to be called from an R package.
> The Rcpp package does wrap all this in a very convenient way, see the
> Rcpp.package.skeleton function.
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
