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

[Paul Buerkner]

Please let me know if I can be of any help. I kind of "caused" this issue
by submitting the new version of brms to CRAN.
Of course, the issue is not really in brms but somehow deeper as your
investigations shows. Would it help if brms
extracted variables names from rstan objects somehow differently than via
dimnames(stanfit)?

Paul

Am Mi., 25. Sept. 2024 um 22:58 Uhr schrieb Ben Bolker <bbolker using gmail.com>:

>    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.
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]