[R-pkg-devel] help with CRAN failures (broom.mixed, rstan-related)

[Stephanie Evert]

May be a completely red herring, but I've recently had what might be a similar issue with reference classes, which kept me pulling my hair for a few hours (when method calls that used to work suddenly stopped doing so, unless called manually first).

IIRC, the culprit was a method obj$basis() being called from another method that happened to have an argument also named 'basis'. Slightly shortened code:

GMA$methods(
  similarity = function (other, basis=FALSE) {
    A <- basis()
    B <- other$basis()
    gma.similarity(A, B, basis=basis)
  })

When calling basis() on the object itself (unlike other$basis() in the next line), symbol lookup would find the argument 'basis' and then complain about trying to call a non-function.  Apparently, methods are initially invisible to symbol lookup in reference classes, so it couldn't find a symbol 'basis' of type function.

Once the basis() method has been called for this specific object by some other code, it's registered and becomes visible to symbol lookup, so the call from similarity() works (with the argument 'basis' ignored because it is not a function). 

Best,
Stephanie



> On 25 Sep 2024, at 22:22, Ivan Krylov via R-package-devel <r-package-devel using r-project.org> wrote:
> 
> В Wed, 25 Sep 2024 12:28:25 -0400
> Ben Bolker <bbolker using gmail.com> пишет:
> 
>>   What is your current estimate of the probability that this is 
>> something that I've done wrong vs. exposing something wonky elsewhere 
>> (i.e. at the level of testthat, brms, rstan, Rcpp, R-devel, ...) ?
> 
> I didn't have a good answer (the most recently updated package should
> be the one to suspect, right?), but stopping the investigation now
> would be akin to closing a murder mystery in the middle of the last
> chapter. Here's what I've been able to find out:
> 
> When running library(testthat); debugonce(Rcpp::loadModule);
> source('tests/testthat/test-alltibbles.R'), by the time we reach
> Rcpp:::loadModule, the reference classes don't come out right. A simple
> new('C++OverloadedMethods') returns an object that doesn't have a $show
> or $info method. A similar problem happens for 'envRefClass', from
> which 'C++OverloadedMethods' inherits: printing it will fail due to a
> missing $show() method.
> 
> The problem is not in the class definition or object contents. I don't
> see differences between serialised class definitions. Reloading a
> serialized object from a "broken" R session into a fresh R session makes
> it work normally.
> 
> The first difference I was able to notice was in how the $ operator
> works for the reference semantics objects. In both cases,
> .Primitive('$') -> do_subset3 eventually calls DispatchOrEval(). In a
> healthy R session, the test [*] for IS_S4_OBJECT(x) &&
> R_has_methods(op) succeeds. In a "broken" R session it fails because
> R_has_methods(op) is FALSE.
> 
> That's because allowPrimitiveMethods had been set to FALSE.
> 
> Judging by the traceback, brms::variables(object) ->
> variables.brmsfit(object) -> dimnames(x$fit) needs to resolve the S4
> 'dimnames' method for class 'stanfit'. At this point
> methods:::.findInheritedMethods temporarily disables S4 methods for
> primitives. The comment says it's done "to avoid infinite recursion,
> and somewhat for speed". Unfortunately, later the 'rstan' namespace
> needs to be loaded, and 'rstan' calls Rcpp functions that use reference
> classes, which break without S4 dispatch for `$`.
> 
> As far as endings go, this one is rather like Murder on the Orient
> Express. Even understanding what happened doesn't point towards the
> "right" fix. Josiah's suggestion should have helped by loading the
> namespace at a safer time.
> 
> -- 
> Best regards,
> Ivan
> 
> [*]
> https://github.com/r-devel/r-svn/blob/776045d4601ed3ac7b8041e94c665bbfe9709191/src/main/eval.c#L4152
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel