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

[Ben Bolker]

   Yikes.  Next question, is this (in your opinion) worth escalating to 
r-devel ?

   I can definitely implement something where I require() rstan up 
front, (which should be harmless if it's really not available but will 
fix issues that brms is having?) ... that might resolve the symptoms 
cleanly in the absence of a definitive diagnosis ...

https://github.com/bbolker/broom.mixed/commit/4096d00cf8cb6dd6798079859dfce56ea870b636

   ... now all I have to do is get a testing framework up and running so 
I can see if it helps ...

On 2024-09-25 4:22 p.m., Ivan Krylov 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.
> 

-- 
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
 > E-mail is sent at my convenience; I don't expect replies outside of 
working hours.