[R-pkg-devel] Weird error on CRAN linux check
I see that you realized it was Inaki who gave you he patch, not me :-)
I've been looking into this further, and the toy example David put up is
actually not the right one to look at. In that example the generic is
created in the namespace. But in the original huxtable that was not the
case. Try the following :
foo.barrista <- function(x, ...){
cat("In barrista\n")
}
make_a_method <- function (x){
assign("foo", function(x, ...){
UseMethod("foo")
} ,envir = getNamespace('testMethod'))
assign("foo.bar", function (x, ...) cat("In foo.bar"),
envir = getNamespace('testMethod'))
}
make_a_method()
With a namespace:
S3method(foo,bar)
S3method(foo,barrista)
export(foo)
And test code :
thebar <- structure(1, class = c("bar", "data.frame"))
thebarrista <- structure(1, class = "barrista")
foo(thebarrista)
foo(thebar)
In both cases the correct method cannot be found. When the methods are both
exported and registered (i.e. add export(foo.bar) and export(foo.barrista)
to NAMESPACE), everything goes fine again on Windows.I went back to the
original version you sent to CRAN, and that doesn't cause any problems on
Windows either. So when the methods are exported and registered, the
problem apparently only exists on Linux.
The other thing I've noticed, is that align() is called from within the
function huxtable() without problem. So the method is found when the
generic is called by a function in the namespace, but not when the generic
is called from the global env. The patch of Inaki makes sure that the
_generic_ is assigned in the namespace itself instead of a child
environment.
To the previous minimal example, add:
baz <- function(x) foo(x)
and to the NAMESPACE:
export(baz)
If you try now:
baz(thebar)
baz(thebarrista)
the correct methods are found. But foo(thebar) etc still doesn't find the
correct ones.
On a sidenote: roxygen is really not helping here. @export literally
exports all these methods as they're not recognized as S3methods. So here
you actually need the deprecated tag @S3method. I wish Hadley would revert
the deprecation, as @export fails to recognize S3 methods correctly in
other cases as well.
On Thu, Jul 5, 2018 at 1:19 PM, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:
On 05/07/2018 5:22 AM, David Hugh-Jones wrote:
Wow, this is extremely helpful. I've applied Joris' patch. By the way, the github master has the change that I stopped exporting methods, as per Hadley's suggestion; this caused *all* functions created via make_getter_setters to fail. Version 4.0.1 on CRAN has the methods exported, which was masking the error in most cases. I don't know why bold() was failing in certain cases only... in any case, the patch seems to fix things.
That's a roxygen2 bug or misuse. If you use the code below without the roxygen2 processing, and manually build the NAMESPACE file as export(foo) S3method(foo, bar) then things are fine. I don't know roxygen2 well enough to know what else you should have done to get your NAMESPACE file to look like that. Duncan Murdoch Here is a brief test case that shows the original problem. I don't know
whether this reveals any problem in base R:
# in package mypackage:
#' @export
foo <- function (x, ...) UseMethod('foo')
make_a_method <- function () assign("foo.bar", function (x, ...) cat("In
foo.bar"), pos = getNamespace('mypackage'))
make_a_method()
# in the console:
library(mypackage)
mypackage:::foo.bar
## function (x, ...) cat("In foo.bar")
## <bytecode: 0x109a0ab80>
## <environment: 0x109a0ba28>
x <- structure(1, class='bar')
foo(x)
## Error in UseMethod("foo") :
## no applicable method for 'foo' applied to an object of class "bar"
Also, I know I shouldn't be using @s3method ... it's on the TODO list... !
Cheers,
David
On Thu, 5 Jul 2018 at 09:07, I?aki ?car <i.ucar86 at gmail.com <mailto:
i.ucar86 at gmail.com>> wrote:
El mi?., 4 jul. 2018 a las 22:47, Duncan Murdoch
(<murdoch.duncan at gmail.com <mailto:murdoch.duncan at gmail.com>>)
escribi?:
>
> On 04/07/2018 4:04 PM, Joris Meys wrote:
> >
> >
> > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch
<murdoch.duncan at gmail.com <mailto:murdoch.duncan at gmail.com>
> > <mailto:murdoch.duncan at gmail.com
<mailto:murdoch.duncan at gmail.com>>> wrote:
> >
> >
> > That shouldn't matter. That function was created in a local
> > environment whose parent is <environment: namespace:huxtable>
> > (probably by the huxtable:::make_setter_getters function,
but I
> > didn't check).
> >
> > Duncan Murdoch
> >
> > I would think it does matter. Methods are found on the search
path, but
> > the environment where the methods are defined is not on the
search path.
> > It's a child environment of the namespace, and hence cannot be
reached
> > from either the global environment or the namespace if I
understood it
> > correctly.
> >
>
> The environment of a function is where it looks for objects, not
where
> it is stored. That method is stored in the huxtable namespace, and
> exported from it. That's why
> getFromNamespace("align.huxtable","huxtable") (or even
> huxtable::align.huxtable) finds it.
>
> I don't know the source of the original error.
I don't know either. But obviously it has something to do with the
function environment and how UseMethod looks for methods when they are
exported from a namespace (I tested a similar "layout" in the global
environment and the method is correctly found). So maybe this thread
belongs to r-devel instead.
I?aki
>
> Duncan Murdoch
>
______________________________________________
R-package-devel at r-project.org <mailto:R-package-devel at r-project.org>
mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Joris Meys Statistical consultant Department of Data Analysis and Mathematical Modelling Ghent University Coupure Links 653, B-9000 Gent (Belgium) <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g> ----------- Biowiskundedagen 2017-2018 http://www.biowiskundedagen.ugent.be/ ------------------------------- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]]