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() be
В Wed, 25 Sep 2024 16:57:55 -0400
Ben Bolker пишет:
> Next question, is this (in your opinion) worth escalating to
> r-devel ?
I think so, yes. Hopefully there will be a way to temporarily re-enable
the S4 dispatch for primitive operators in methods:::.requirePackage
(that lives in R/RClassUtil
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
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
cleanl
В Wed, 25 Sep 2024 12:28:25 -0400
Ben Bolker пишет:
>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 m
On 9/25/24 12:21, Ivan Krylov wrote:
Hmm, so it's *not* a machine-specific problem after all [1,2] and can
now be reproduced on a regular R-devel build on Debian Sid. I'm sorry
for jumping to conclusions.
No need to apologize, you've gotten 1000x farther than I would have
on my own.
Hmm, so it's *not* a machine-specific problem after all [1,2] and can
now be reproduced on a regular R-devel build on Debian Sid. I'm sorry
for jumping to conclusions.
Why would Rcpp::loadModule() (called from rstan's .onLoad) end up trying
to apply a non-function, but only when being called from
Thanks both.
Josiah Parry says:
> Ben, the issue is that {rstan} is not available. Since it is a
suggested package it is not expected to always be there.
The thing is that the checks for rstan-based objects *are*
conditional. This is actually failing on the tests for brms-based
object
В Tue, 24 Sep 2024 10:27:34 -0400
Ben Bolker пишет:
>Weirdly, I can't get this to fail on my local system even if I
> remove rstan -- maybe rstan needs to be present for brms at install
> time but not at runtime ... ???
I'm noticing that despite broom.mixed having Suggests: rstan and it
bein
Ben, the issue is that {rstan} is not available. Since it is a suggested
package it is not expected to always be there.
This is referred to is the "hard" check.
Here is a GitHub CI workflow I use to perform this check:
https://github.com/JosiahParry/sfdep/blob/008a59b6009d01e5e1625319f6525c1e0ba
broom.mixed is failing tests on Fedora.
With apologies for the mangled formatting, here is the test failure
(full properly formatted details at
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-gcc/broom.mixed-00check.html).
══ Failed tests
═
11 matches
Mail list logo
