Upgrade to Eigen 5.0.0

Eigen 5.0.0 was released recently. They changed versioning scheme, so the version bump is not as dramatic as it first seems.

Here's a list of the breaking changes. I suspect the requirement on C++14 may be the most problematic among these.

Sounds good to me. For what it is worth we did the same in this release cycle for Rcpp (i.e. for the version to go to CRAN this week): settle on C++11 or later, and R 3.5.0. That made it possible to remove a few old constructor crufts that were shimmied in pre-C++11.

Indeed that is my hunch. In particular, we have pretty hard C++17 requirements in the math code at this point, so I think we can confidently rule out 12-plus-year-old compilers

A floor of C++17 is no problem at all either ¹. For what it is worth upstream R 4.6.0 will warn about / even outlaw C++11 and C++14 ².

Apart from creating a headache for people on ancient systems, but it may get them to upgrade. ↩
Personally I find that overeager but I have no horse in that race. To me, 'reasonable' defaults are best and I have no qualms with C++17 being one. ↩

@bgoodri

@bgoodri @WardBrian Any news on this? Are you guys working on this by chance?

I have not had the chance. Any updates will end up in stan-dev/math#3243 if I (or others) do this upstream, but it sounded like Ben was going to do local patches (the rstan codebase wouldn't immediately receive any upstream patch anyway)

Thanks for the update. Not imminently urgent as, hey, it took me three months to respond as well, but now that I did the blocking element is you guys so I may check in every now and then. Eigen is a key part so we should probably track their progress and keep up.

My hope is that I can remove the lines involving EIGEN_EMPTY_STRUCT_CTOR from StanHeaders and require a C++ compiler that obviates the need to workaround whatever bug EIGEN_EMPTY_STRUCT_CTOR was intended to workaround 10+ years ago. At that point, I don't think we would have mass compiler errors from Eigen 5.x. I will test that soon.

Sounds good. We had good luck settling on C++11 as a minimum in the July release 1.1.0 allowing us to remove thousands of lines of code in Rcpp leading to this month's 1.1.1 release. Tarball size had peaked at 3.43 nb two years ago, it is now 1.88 mb. Quite the reduction. We are mindful of folks with old compilers but at some point one can draw a line in the sand and move on from there. I am sure you will find a good baseline.

I'm working on getting stan to use Eigen 5.0.1 but there are a few weird things I need to take care of since we use a few Eigen internals. I'm going to try to get this all working by Friday.

Sadly I found a bug in 5.0.1 that makes it a large nuisance to move Stan math up to 5.0.1. In Eigen it is a one line fix though. Should we wait for Eigen to release a patch version or do a patch for RcppEigen / Stan Math? This bug would cause most code that uses custom scalars types that require initialization to segfault.

https://gitlab.com/libeigen/eigen/-/issues/3019

Nice work! Now, we may actually be in a situation to accommodate this as RcppEigen generally ships (and thereby "controls" the Eigen used. So we could patch this locally 'for now' and switch to an upstream 5.0.2 (or whatever) once it is out.

Looking at your issue 3019 I am little confused: it made one of their tests fail and they still released? Or it is a fail in 5.0.1 and wasn't in 5.0.0? I'm lost.

As mentioned, though happy to add this to the RcppEigen repo

modified   inst/include/Eigen/src/Core/Fill.h
@@ -94,7 +94,9 @@ struct eigen_fill_impl<Xpr, /*use_fill*/ true> {
 template <typename Xpr>
 struct eigen_memset_helper {
   static constexpr bool value =
-      std::is_trivially_copyable<typename Xpr::Scalar>::value && eigen_fill_helper<Xpr>::value;
+      std::is_trivially_copyable<typename Xpr::Scalar>::value
+      && eigen_fill_helper<Xpr>::value
+      && (NumTraits<Xpr>::RequireInitialization == 0);
 };
 
 template <typename Xpr>

@bgoodri

I'm afk but thank you for catching my confusing verbage. The test in that issue is one that I wrote to show the issue and does not exist in eigen. Though that particular test does pass if you put it in the 3.4 branch of eigen

If we can patch in RcppEigen that is great. I'll continue updating Stan and will ping @bgoodri when I have a patch he can use for Stan headers

EDIT: That is the only issue I have found so far. Once all of Stan's tests are passing I can give a view of any patches needed

@bgoodri

Very good. How about if I let you work on things from your end for a bit more, and when you are at a point where you think you are done I can patch up the RcppEigen branch -- and @bgoodri can see where that takes us.

@SteveBronder

My hope is that I can remove the lines involving EIGEN_EMPTY_STRUCT_CTOR from StanHeaders and require a C++ compiler that obviates the need to workaround whatever bug EIGEN_EMPTY_STRUCT_CTOR was intended to workaround 10+ years ago. At that point, I don't think we would have mass compiler errors from Eigen 5.x. I will test that soon.

Removing EIGEN_EMPTY_STRUCT_CTOR seems to work with RcppEigen 0.3.4.0.2, at least under g++ 12 from Debian oldstable. So, next week I can make that change to StanHeaders on CRAN, in which case adding @SteveBronder 's patch to RcppEigen 0.5.x will probably allow Stan-related packages to work.

@SteveBronder

Time for my (bi-)weekly check-in. Looks like @SteveBronder remains hard at work on issue 3271 over at your end. Any expectations of timelines? There is no urgency here, asking mostly for planning purposes.

I'm hoping to get everything done this week. They accepted my first patch and I have another already. I suspect there will be at least 1 more before all the Stan tests pass

@SteveBronder

@SteveBronder How is coming along? Any road blocks or 'surprises' along the way? What timelines are we looking at?

So hopefully I have everything sorted out! Tests locally are all passing.

I have all the patches as the first few commits here

stan-dev/math#3271

I am going to make patches for Eigen and am going to ask if they are amenable to a 5.0.2 release for these.

But otherwise, with those Eigen changes we should be good to go! If we have any other hiccups that need patches I will lyk

Sounds excellent, and I really appreciate that your shepherding changes upstream.

It might be worth stressing that we do control our copy of Eigen so we could in the interim provide a 'patched 5.0.0' (or 5.0.1) while documenting the changeset applied by including it. That is really not all that different from having to modify upstream code to please CRAN's preferences, something we already do.

So as long as Eigen takes this patch we could probably just use a commit from the main repo. I think that would make all of this a little easier.

https://gitlab.com/libeigen/eigen/-/merge_requests/2129

My (possibly ill-stated) proposal was to NOT have our actions depend on whether or not they take a patch as this is beyond our control. I suggested to focus on what we own: RcppEigen on my end, stan-dev/math on yours. Does that make sense?

That works for me!

Reading the history of the conversation and I'd like to make sure I understand. Do we want to apply the Eigen patches from stan-dev/math#3271 to RcppEigen/eigen-5.0.0 and then Ben and I update StanHeaders? Not sure about the order of operations but happy with whatever is easiest for everyone.

Works for me too! As RcppEigen is a Build-Dependency for stan-dev/math, I would have to go first, create an updated package and let you test it. If all is well, we can communicate with CRAN -- such cases of 'coordination' where 'upload of X will break Y, but team Y have a version ready' have happened before.

@SteveBronder

@SteveBronder If you could assist me and more clearly delineating where the patch to Eigen is (it's a long thread with many moving pieces over in stan-dev/math#3271 too) I would appreciate it. Also, do you think I need to roll to 5.0.1 first?

I am confident I can make a small update to StanHeaders on CRAN that will make it work with both the old and new versions of Eigen, which should permit a (more) automatic update path for RcppEigen on CRAN. There may well be a few packages Stan-related R packages with unit tests that are overly sensitive to changes in compiled code but those can usually be explained to CRAN and the relevant maintainers.

@eddelbuettel

@eddelbuettel sure! Let me finalize this patch to Eigen to make sure I got everything right, then I will make a patch to send you for RcppEigen. I would update to 5.0.1, though it looks like they may make a 5.0.2 after my patch. Either way I'll make the patch for my changes and make a PR off of the 5.0.0 branch

Cleanly working off an upstream 5.0.2 would be nice. In the meantime we can probably test some more with local patches and / or initial RcppEigen updates.

fyi I have a branch here for a proposed 5.0.2 branch. I just made an issue today for talk to the Eigen team about doing an official 5.0.2 branch you can find here. Though we could just use the patch branch I have setup already.

Thanks for reporting back. I did all my work a full two months ago, so at this point you are closer to the metal, and I will to need a) find time and b) get myself back up to speed. While your discussion with the Eigen team are ongoing, could you conceivably work on a patch applied to what I have here? Or is the 5.0.0 to 5.0.2 change too large?

Sure! I'll look at what you have and see if I can do something similar to the patch apply I did for 5.0.1. I should have time tomorrow for this and will ping you when I have something up

Really appreciate it. I think the idea always is to keep it clean, keep around a patch against 'pristine upstream' (and we have that for 5.0.0), bring in 5.0.2 (or 5.0.1 as is?) and adjust as needed. It was actually pretty straightforward for 5.0.0, and tomorrow would be good for me too (today less so) so could hop on a zoom or meet or jit.si and chat as needed.

Let me take a crack at it then if I get stuck we can have a meeting to chat!

@eddelbuettel

@eddelbuettel can you take a look at this?

https://github.com/RcppCore/RcppEigen/compare/master...SteveBronder:RcppEigen:eigen-5.0.2?expand=1

fyi I used claude to make it, but did check of each the individual commits and imo everything makes sense.

I looked at them both with the following

# This assumes you are on branch SteveBronder/RcppEigen/eigen-5.0.2
git fetch https://github.com/RcppCore/RcppEigen.git feature/eigen-5.0.0:refs/remotes/rcppcore/feature/eigen-5.0.0
git fetch https://github.com/SteveBronder/RcppEigen.git eigen-5.0.2:refs/remotes/steve/eigen-5.0.2
git diff -w rcppcore/feature/eigen-5.0.0..steve/eigen-5.0.2 -- \
. \
':(exclude)inst/include/Eigen' \
':(exclude)inst/include/unsupported/Eigen'

You can see the patches/eigen-5.0.2 diff here which seems similar to patches/eigen-5.0.0

This passes calling Rscript tests/tinytest.R and R CMD check --as-cran. Is it okay if I open a pull request with this branch? Also happy to chat, it's been a while!

Will do.

Is upstream 5.0.2 'final' and out or is your branch of their development? I.e. I am trying to ensure the 'diff to 5.0.2' will be useful for the next round.

The ultimate test is of course not R CMD check --whatever on the package, but the reverse dependency checks. I assume that this passes for all stan related packages?

Why does your git diff invocation (that I am largely unfamilar with) exclude Eigen headers? "That's where the beef is."

(I guess because we don't want to see all the 5.0.0 --> 5.0.2 changes that are purely Eigen...)

I am not particularly interested in changes in workflow. So not a fan of the altered howToDiff.md, and not a fan my 5.0.0 work is missing i.e. we cannot compare your 20k change set to my 16k change set. That is what I would prefer to look at, or least be able to look at.

This suggests you patched files outside of the Eigen 5.0.2 set.

edd@paul:~/git/rcppeigen-stevebronder(eigen-5.0.2)$ grep "^---" patches/eigen-5.0.2.diff 
--- c/inst/include/Eigen/CholmodSupport
--- c/inst/include/Eigen/src/CholmodSupport/CholmodSupport.h
--- c/inst/include/Eigen/src/Core/util/DisableStupidWarnings.h
--- c/inst/include/RcppEigenForward.h
--- c/inst/include/RcppEigenWrap.h
--- c/inst/include/unsupported/Eigen/src/SparseExtra/MatrixMarketIterator.h
--- c/inst/tinytest/cpp/rcppeigen.cpp
--- c/inst/tinytest/cpp/sparse.cpp
--- c/inst/tinytest/test_sparse.R
--- c/src/fastLm.cpp
edd@paul:~/git/rcppeigen-stevebronder(eigen-5.0.2)$ grep "^---" ../rcppeigen/patches/eigen-5.0.0.diff 
--- c/inst/include/Eigen/CholmodSupport
--- c/inst/include/Eigen/src/CholmodSupport/CholmodSupport.h
--- c/inst/include/Eigen/src/Core/util/DisableStupidWarnings.h
--- c/inst/include/RcppEigenForward.h
--- c/inst/include/RcppEigenWrap.h
--- c/inst/include/unsupported/Eigen/src/SparseExtra/MatrixMarketIterator.h
edd@paul:~/git/rcppeigen-stevebronder(eigen-5.0.2)$

Some of those changes are white space only (never great, one can edit that out), some affect tests yet you did not say anything about them.

But the key is that the core Eigen changes are unchanged from 5.0.0 to 5.0.2. That is good. (And makes me wonder why 5.0.2 was needed but maybe that was all stan related and semi-orthogonal to what we do here.) And the other stuff is small stuff we can likely fold in one by one. So overall this moves the needle the right way. Good.

Is upstream 5.0.2 'final' and out or is your branch of their development? I.e. I am trying to ensure the 'diff to 5.0.2' will be useful for the next round.

It is my branch. I suggested this patch to the Eigen team here, but they may possibly do a minor version bump instead of take in my patch. I'll follow up to see if they have made a decision on this yet.

Why does your git diff invocation (that I am largely unfamilar with) exclude Eigen headers? "That's where the beef is."
(I guess because we don't want to see all the 5.0.0 --> 5.0.2 changes that are purely Eigen...)
You can omit the exclude at the end to see all the diffs including Eigen.

git diff -w rcppcore/feature/eigen-5.0.0..steve/eigen-5.0.2

But the key is that the core Eigen changes are unchanged from 5.0.0 to 5.0.2. That is good. (And makes me wonder why 5.0.2 was needed but maybe that was all stan related and semi-orthogonal to what we do here.)

I'm not sure what you mean here? You can see the proposed 5.0.2 vs 5.0.1 below. There have been quite a good number of small bug fixes since even 5.0.1!

https://gitlab.com/sbronder1/eigen/-/compare/bc3b39870ecb690a623a3f49149a358b95c5781d...proposed-release%2F5.0.2?from_project_id=15462818

And the other stuff is small stuff we can likely fold in one by one. So overall this moves the needle the right way. Good.

eod, the only things that will change in a 5.0.x version will be Eigen internals so your branch of RcppEigen on 5.0.0 should be fine.

Yes but I 'ship' Eigen to CRAN inside of RcppEigen and I would rather ship an actual release. It took up seven months to get here so I reckon a few more weeks won't kill us.

@SteveBronder

@SteveBronder Apologies this all took so long but the term was busy, then the R 4.6.0 transition plus BioC 3.23 took some time for r2u, and then various other projects came calling.

Upstream appears to be doing two things. First, 5.0.1 was tagged and released. Second, mainline continues. So I made the executive decision to have a clean baseline and ported RcppEigen to Eigen 5.0.1.

Could you possibly rebase you branch of your '5.0.2rc-for-stan' against that upstream 5.0.1 tag (in the upstream 5.0 branch) so that we get a clean diff against it for the Eigen/ and unsupported/Eigen/ directories?

@SteveBronder

@SteveBronder A diff between your proposed-release/5.0.2 and the actual 5.0.1 is large:

edd@paul:~/git/eigen-sbronder(proposed-release/5.0.2)$ diff -ru ../rcppeigen/inst/include/Eigen/ Eigen/|wc -l
9196
edd@paul:~/git/eigen-sbronder(proposed-release/5.0.2)$ diff -ru ../rcppeigen/inst/include/unsupported/Eigen/ unsupported/Eigen/|wc -l
150
edd@paul:~/git/eigen-sbronder(proposed-release/5.0.2)$

A lot of the difference in the former is adding constexpr. Is there a chance we could minimise the diff to the essentials needed to support stan and friends?

I ran two full reverse-dependency checks for

RcppEigen 0.4.9.9-2 containing Eigen 5.0.1
Steve's Eigen 5.0.2 'rc' branch

Both resulted in the same (unacceptable) failure of nearly 200 packages as stanheaders, TMB, ... need updates. So we are effectively 'check mated' here unless are coordinated action can be put together.

I will do a StanHeaders release ASAP. I don't think it will need a coordinated upload just a forward and backward compatible StanHeaders first.

…

On Sun, Jun 7, 2026 at 6:13 PM Dirk Eddelbuettel ***@***.***> wrote: *eddelbuettel* left a comment (RcppCore/RcppEigen#143) <#143 (comment)> I ran two full reverse-dependency checks for - RcppEigen 0.4.9.9-2 containing Eigen 5.0.1 - Steve's Eigen 5.0.2 'rc' branch Both resulted in the same (unacceptable) failure of nearly 200 packages as stanheaders, TMB, ... need updates. So we are effectively 'check mated' here unless are coordinated action can be put together. — Reply to this email directly, view it on GitHub <#143?email_source=notifications&email_token=AAZ2XKWZ46H662VZWYJCEMD46XSJZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGQZDKOBRG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4644258170>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKUAZGPIHMISYENBHHD46XSJZAVCNFSM6AAAAACZ4B3VB2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMNBUGI2TQMJXGA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAZ2XKTEBZGM24BTB4VKH4T46XSJZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGQZDKOBRG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAZ2XKS7IIYFLG2BOGCL5H346XSJZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRUGQZDKOBRG4YKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

@bgoodri

@bgoodri Are you or anybody from 'team stan' in contact with the TMB folks?

Happy to coordinate with you to sort this out.

@eddelbuettel

@eddelbuettel Yes I think the actual patch diff should be very small. Let me look at this tommorow

@SteveBronder

@SteveBronder You have a lot of (very well intended, but in this context noisy) additions of constexpr and alike. I would probably be best while we juggle these R change that we keep diffs to Eigen as compact as we can. You have some really good stuff in there to possibly get rid of our CholMod entry point which would be excellent to get upstream. Appreciate you revisting this, and again sorry my turnaround time was so long this round.

@eddelbuettel

@eddelbuettel I don't think I actually added those, I think they can from one of the patches I imported. I'll look at updating this today.

@SteveBronder

@SteveBronder Could well be from the upstream diff between 5.0.2 "under development" in their main and the tagged 5.0.1. It would be best for us to find the subset of changes that is minimal, and working.

@bgoodri

@bgoodri @SteveBronder How are we doing on, respectively, StanHeaders and the Eigen patch? Any news? Any blockers?

I think we are good. I will talk with Steve in a few minutes.

…

On Thu, Jun 18, 2026, 8:07 AM Dirk Eddelbuettel ***@***.***> wrote: *eddelbuettel* left a comment (RcppCore/RcppEigen#143) <#143 (comment)> @bgoodri <https://github.com/bgoodri> @SteveBronder <https://github.com/SteveBronder> How are we doing on, respectively, StanHeaders and the Eigen patch? Any news? Any blockers? — Reply to this email directly, view it on GitHub <#143?email_source=notifications&email_token=AAZ2XKVIH3WF77S7D7GKQ4L5APLORA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGE3TMNBQGU4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4741764058>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKSFEQEWK7K4ZHXD7WT5APLORAVCNFSNUABEKJSXA33TNF2G64TZHMYTIMBSGIZDCMR3JFZXG5LFHMZTKOJUGM4TANBZHCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAZ2XKRT52YH5GAVXBICAT35APLORA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGE3TMNBQGU4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAZ2XKQNLNBVJIWNMPG3XJ35APLORA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUGE3TMNBQGU4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

@SteveBronder

@SteveBronder I missed you today at the meeting. I have a StanHeaders that (deletes the macro Eigen 5.x killed off and) reduces the number of compiler errors to 24. One of the remaining compiler errors is like

g++ -std=gnu++17 -I"/home/ben/r-devel/include" -DNDEBUG -I"../inst/include" -I"/home/ben/r-devel/library/StanHeaders/include/src" -DBOOST_DISABLE_ASSERTS -DEIGEN_NO_DEBUG -DBOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error -DUSE_STANC3 -D_HAS_AUTO_PTR_ETC=0 -I'/home/ben/r-devel/library/StanHeaders/include' -I'/home/ben/r-devel/library/rstan/include' -I'/home/ben/r-devel/library/BH/include' -I'/home/ben/r-devel/library/Rcpp/include' -I'/home/ben/r-devel/library/RcppEigen/include' -I'/home/ben/r-devel/library/RcppParallel/include' -I/usr/local/include -I'/home/ben/r-devel/library/RcppParallel/include' -D_REENTRANT -DSTAN_THREADS -fpic -O3 -g0 -Wno-ignored-attributes -Wno-deprecated-declarations -Wno-unknown-pragmas -c stanExports_BebopInPeps2.cc -o stanExports_BebopInPeps2.o
In file included from /home/ben/r-devel/library/RcppEigen/include/Eigen/Core:333,
from /home/ben/r-devel/library/RcppEigen/include/Eigen/Dense:1,
from /home/ben/r-devel/library/StanHeaders/include/stan/math/prim/fun/Eigen.hpp:22,
from /home/ben/r-devel/library/rstan/include/rstan/rstaninc.hpp:3,
from stanExports_AugBin2T1A.h:23,
from stanExports_AugBin2T1A.cc:5:
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/CoreEvaluators.h: In instantiation of ‘Eigen::internal::unary_evaluator<Eigen::CwiseUnaryView<UnaryOp, ArgType, StrideType>, Eigen::internal::IndexBased>::Scalar& Eigen::internal::unary_evaluator<Eigen::CwiseUnaryView<UnaryOp, ArgType, StrideType>, Eigen::internal::IndexBased>::coeffRef(Eigen::Index) [with UnaryOp = Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op; ArgType = Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >; StrideType = Eigen::Stride<0, 0>; typename Eigen::CwiseUnaryView<UnaryOp, ArgType, StrideType>::Scalar = double; Scalar = double; Eigen::Index = long int]’:
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/CwiseUnaryView.h:86:60: required from ‘const Eigen::internal::CwiseUnaryViewImpl<ViewOp, MatrixType, StrideType, Eigen::Dense, false>::Scalar& Eigen::internal::CwiseUnaryViewImpl<ViewOp, MatrixType, StrideType, Eigen::Dense, false>::coeffRef(Eigen::Index) const [with ViewOp = Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op; MatrixType = Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >; StrideType = Eigen::Stride<0, 0>; Scalar = double; Eigen::Index = long int]’
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/CwiseUnaryView.h:67:80: required from ‘const Eigen::internal::CwiseUnaryViewImpl<ViewOp, MatrixType, StrideType, Eigen::Dense, false>::Scalar* Eigen::internal::CwiseUnaryViewImpl<ViewOp, MatrixType, StrideType, Eigen::Dense, false>::data() const [with ViewOp = Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op; MatrixType = Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >; StrideType = Eigen::Stride<0, 0>; Scalar = double]’
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/util/XprHelper.h:871:35: required from ‘bool Eigen::internal::is_same_dense(const T1&, const T2&, std::enable_if_t<possibly_same_dense<T1, T2>::value>) [with T1 = Eigen::Map<Eigen::Matrix<double, -1, 1>, 0, Eigen::Stride<0, 0> >; T2 = Eigen::CwiseUnaryView<Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op, Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >, Eigen::Stride<0, 0> >; std::enable_if_t<possibly_same_dense<T1, T2>::value> = void]’
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/ProductEvaluators.h:1192:23: required from ‘static void Eigen::internal::transposition_matrix_product<ExpressionType, Side, Transposed, ExpressionShape>::run(Dest&, const TranspositionType&, const ExpressionType&) [with Dest = Eigen::Map<Eigen::Matrix<double, -1, 1>, 0, Eigen::Stride<0, 0> >; TranspositionType = Eigen::Transpositions<-1, -1, int>; ExpressionType = Eigen::CwiseUnaryView<Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op, Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >, Eigen::Stride<0, 0> >; int Side = 1; bool Transposed = false; ExpressionShape = Eigen::DenseShape]’
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/ProductEvaluators.h:1208:74: required from ‘static void Eigen::internal::generic_product_impl<Lhs, Rhs, Eigen::TranspositionsShape, MatrixShape, ProductTag>::evalTo(Dest&, const Lhs&, const Rhs&) [with Dest = Eigen::Map<Eigen::Matrix<double, -1, 1>, 0, Eigen::Stride<0, 0> >; Lhs = Eigen::Transpositions<-1, -1, int>; Rhs = Eigen::CwiseUnaryView<Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op, Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >, Eigen::Stride<0, 0> >; int ProductTag = 7; MatrixShape = Eigen::DenseShape]’
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/ProductEvaluators.h:133:43: [ skipping 16 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/home/ben/r-devel/library/StanHeaders/include/stan/math/prim/prob/multi_normal_lpdf.hpp:98:45: required from ‘stan::return_type_t<T, L, U> stan::math::multi_normal_lpdf(const T_y&, const T_loc&, const T_covar&) [with bool propto = true; T_y = std::vector<Eigen::Matrix<double, -1, 1> >; T_loc = std::vector<Eigen::Matrix<var_value, -1, 1>, std::allocator<Eigen::Matrix<var_value, -1, 1> > >; T_covar = Eigen::Matrix<var_value, -1, -1>; stan::return_type_t<T, L, U> = var_value]’
stanExports_AugBin2T1A.h:542:63: required from ‘stan::scalar_type_t model_AugBin2T1A_namespace::model_AugBin2T1A::log_prob_impl(VecR&, VecI&, std::ostream) const [with bool propto__ = true; bool jacobian__ = true; VecR = std::vector<stan::math::var_value, std::allocator<stan::math::var_value > >; VecI = std::vector; stan::require_vector_like_t* = 0; stan::require_vector_like_vt<std::is_integral, VecI>* = 0; stan::scalar_type_t = stan::math::var_value; std::ostream = std::basic_ostream]’
stanExports_AugBin2T1A.h:1067:47: required from ‘T_ model_AugBin2T1A_namespace::model_AugBin2T1A::log_prob(std::vector<T_l>&, std::vector&, std::ostream*) const [with bool propto__ = true; bool jacobian__ = true; T_ = stan::math::var_value; std::ostream = std::basic_ostream]’
/home/ben/r-devel/library/StanHeaders/include/src/stan/model/log_prob_grad.hpp:40:79: required from ‘double stan::model::log_prob_grad(const M&, std::vector&, std::vector&, std::vector&, std::ostream*) [with bool propto = true; bool jacobian_adjust_transform = true; M = model_AugBin2T1A_namespace::model_AugBin2T1A; std::ostream = std::basic_ostream]’
/home/ben/r-devel/library/rstan/include/rstan/stan_fit.hpp:1183:49: required from ‘SEXPREC* rstan::stan_fit<Model, RNG_t>::grad_log_prob(SEXP, SEXP) [with Model = model_AugBin2T1A_namespace::model_AugBin2T1A; RNG_t = boost::random::additive_combine_engine<boost::random::linear_congruential_engine<unsigned int, 40014, 0, 2147483563>, boost::random::linear_congruential_engine<unsigned int, 40692, 0, 2147483399> >; SEXP = SEXPREC*]’
stanExports_AugBin2T1A.cc:23:80: required from here
/home/ben/r-devel/library/RcppEigen/include/Eigen/src/Core/CoreEvaluators.h:1205:50: error: binding reference of type ‘Eigen::internal::unary_evaluator<Eigen::CwiseUnaryView<Eigen::MatrixBase<Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> > >::val_Op, Eigen::Map<Eigen::Matrix<stan::math::var_value, -1, 1>, 0, Eigen::Stride<0, 0> >, Eigen::Stride<0, 0> >, Eigen::internal::IndexBased, double>::Scalar&’ {aka ‘double&’} to ‘const double’ discards qualifiers
1205 | return m_d.func()(m_d.argImpl.coeffRef(index));

If necessary, I could give you the C++ code that stanc produces for this particular (AugBin2T1A) model.

@bgoodri

@bgoodri if you can send me the model + branch you have that would be great! I have a version of RcppEigen with the fixes we need up. You will most likely need to most recent develop branch of Stan math to get stan to compile with Eigen 5.0.1

@bgoodri

Weekly check-in with @bgoodri and @SteveBronder : Where are we on this? What are realistic timelines?

@bgoodri

Weekly check-in with @bgoodri and @SteveBronder : Where are we on this? What are realistic timelines?

@bgoodri @SteveBronder This changeset to CRAN StanHeaders resolves the build issues for all rstan packages (for me) with the current github RcppEigen (while being backwards-compatible with CRAN RcppEigen): https://github.com/cran/StanHeaders/compare/master...andrjohns:StanHeaders:eigen5-compat?expand=1

I'll have a look at the TMB issues and see what they might need

@andrjohns

Thanks @andrjohns . I had been thinking that we could make a small change to StanHeaders to let RcppEigen update in a backward and forward compatible way and then worry about upgrading StanHeaders and rstan for real later this summer. @SteveBronder what was it that made you feel that StanHeaders would have to sync with develop?

@andrjohns

Weekly check-in: Given that @andrjohns merged (thank you!) how are we looking with respect to a packages that could live on CRAN with old and new RcppEigen?

@andrjohns Was there a separate TMBstan problem, other than it would not compile under Eigen 5.x without your compatibility PRs?

@andrjohns Was there a separate TMBstan problem, other than it would not
compile under Eigen 5.x without your compatibility PRs?

Nah tmbstan was ok. Many of the other TMB-based packages are broken separately, unfortunately. It appears that using a namespace-level import for Eigen was standard practice (i.e., using namespace Eigen), and Eigen 5.0 introduced an array typedef which conflicts with the TMB array type

@andrjohns

So @andrjohns @bgoodri @SteveBronder : Where are we at, and what can be done this week to move this closer to the goal line? Can you share what the current bottlenecks are, and who is trying to move them?

This continues to block RcppEigen, and it would be lovely to get it resolved.

@andrjohns

Another week, another probe: @andrjohns @bgoodri @SteveBronder any chance you can give an updated about expected next steps? And/or currenrt blockers?

@bgoodri

With these rstanstools changes we should be able to get a StanHeaders update out. @bgoodri if we get that rstantools update out, would you be happy to submit StanHeaders 2.39.0 to CRAN?

@andrjohns

Another week, another status check: @andrjohns got a new rstantools onto CRAN (congrats, and thanks!) so how are we doing on follow-up work from the other packages? @bgoodri @SteveBronder any insights you can share?

@andrjohns

At this point I think @andrjohns is taking the lead (🙏 tyty). I made the updates for math to work with 5.0.1 and I think at this point the main work is updating StanHeaders and rstan. I believe Andrew got StanHeaders updated and working on github last week. @bgoodri and @andrjohns know more about that then me but happy to help!

@andrjohns

Hi @andrjohns -- any chance you could offer an update on status, plans, timelines, ... ? Lovely to see that @kaskr updated TMB too.

Hi @andrjohns -- any chance you could offer an update on status, plans, timelines, ... ? Lovely to see that @kaskr updated TMB too.

Sorry about these delays! We've got a dev meeting tomorrow , so will hopefully get some agreements on submission timelines and share an update here

@bgoodri

We just had the meeting and @bgoodri is going to look over the rstan changes @andrjohns made and then push a version of rstan to cran which works with Eigen 5.0 and the previous version of Eigen

@andrjohns

So how are we doing on this now that CRAN is back open again? Can you share next steps and expected timelines? Paging @andrjohns @bgoodri @SteveBronder

@andrjohns

Paging @andrjohns @bgoodri @SteveBronder again:

So how are we doing on this now that CRAN is back open again? Can you share next steps and expected timelines?

@andrjohns

Sorry this has dragged on. It's my fault that I haven't had time to deal with this properly. @andrjohns is probably asleep at the moment but yesterday he was putting together a new rstantools because a couple of new packages hit CRAN since the last time he wrote up the list of grandfathered packages that still are using a bit of Stan syntax that was deprecated years ago. With that, StanHeaders can up updated to v2.39.0, which works with Eigen 5.x, and Andrew has a bunch of stuff in the overrides folder that makes it work with RcppEigen currently on CRAN and works with C++ code generated by older versions of Stan that used a different PRNG. My understanding is that RcppEigen can go after that, and then rstan 2.39.x can depend on RcppEigen >= 5.0.0.

No worries. I also had to leave this to the side for a few months, and it is a big lift.

But I think we are close. Let's keep pushing.

I tried uploading StanHeaders but a couple of packages failed to install that we were not anticipating, so we are going to have to try again.

That is the way it goes. I had RcppEigen rev.deps. fail on my machine too when I had the release candidate (rather than the CRAN version) installed.

Slow drilling of hard boards. One at a time.

@bgoodri

@bgoodri Can you summarize where we are at now with StanHeaders 2.39.1 on CRAN? And congrats for getting it there.

Yes, second-and-a-half time is the charm. v2.39.x includes stan-dev/stan#3371 so it should be ready to check the reverse dependencies of RcppEigen with that StanHeaders installed.

Great. I will attempt to get to it. Last time it was clear that we needed this first, I fear there will still be a few but again ... slow drilling of hard boards. One at a time. Thanks for all the help by all of you to get us here!

Does postlink, which just upgraded at CRAN, need an adjustment? r2u builds are failing for the same issue the M1mac machines at CRAN show:

Error in rstan::stanc(file_name, allow_undefined = TRUE, obfuscate_model_name = FALSE,  : 
  0
Syntax error in 'string', line 7, column 26 to column 27, parsing error:
   -------------------------------------------------
     5:    int<lower=1> K;               // Number of predictors
     6:    matrix[N, K] X;               // Predictor matrix
     7:    int<lower=0, upper=1> y[N];   // Binary outcome variable (0 or 1)
                                   ^
     8:    // Prior Hyperparameters (Passed from R)
     9:    // Intercept priors (applied to beta[1] only)
   -------------------------------------------------

Ill-formed declaration. ";" expected after variable declaration.
  It looks like you are trying to use the old array syntax.
  Please use the new syntax:
  array[N] int<lower=0, upper=1> y;
Calls: <Anonymous> -> sapply -> lapply -> FUN -> <Anonymous>
Execution halted
ERROR: configuration failed for package ‘postlink’

Is that a StanHeaders thing?

PS Issue 18 filed there

Sorry for the delay: "things" got in the way. First a pending RcppArmadillo releases, then several batches of Rcpp tests. I finally got to re-testing RcppEigen after the fine work on (r)stan you all did, and I have good news and bad news.

Good news: The count is down considerably from the previous run where we had '310 successes, 200 failures, 21 skipped'.

Bad news: The count is still high in this new run as we have '472 successes, 69 failures, 24 skipped'.

I will open a new issue to track this. One PR has been filed already, another one can likely be made as I got another package to compile. We will have to chip away at the pile of packages and convert them (as needed) to Eigen 5.0.*.

@bgoodri

@bgoodri Can you clarify the situation with StanHeaders / rstan ? Do we need another update at CRAN ? When I tested the current RcppEigen release candidate I still ran into a number of run-time errors that seem to suggest we need more work. (There are also a number of relatively simple compile-time issues I will try to tackle one by one.)

@SteveBronder

These segfaults are caused by the new memset fast-path which needed patching, discussed a little earlier in the thread: #143 (comment)

@SteveBronder what's the best minimal patch for this?

@SteveBronder

@SteveBronder Any news or insights? I am chipping away furiously at PRs for reverse dependencies that need small (often simple) updates for Eigen 5.0.1. It would be terrific if we could cover this. The Fill.h code does no longer look like #143 (comment) so this may take some digging. Can you help?

@eddelbuettel

@eddelbuettel sorry for my delay.

Re #143 (comment) :

Looking at your issue 3019 I am little confused: it made one of their tests fail and they still released? Or it is a fail in 5.0.1 and wasn't in 5.0.0? I'm lost.

The unit test they had was built to catch something that it did not actually catch so they just missed it. If you bring in the commit below that should fix the memset segfault. This is fixed on the main branch of Eigen.

https://gitlab.com/libeigen/eigen/-/commit/e246f9cb68d07e8f15c60a2404ac9a625c349223

I'm confused though, I thought we imported all of the changes Stan math needed to RcppEigen at one point? Am I hallucinating that? The 3 commits below are the bug patches in Eigen that Stan needed to pass its full test suite. I tried reading through this thread but it was kind of hard to follow if these changes were brought in or not.

stan-dev/math@d241d92
stan-dev/math@ac2a7a9
stan-dev/math@79b617b

These were also brought in as patches on Eigen's main branch

https://gitlab.com/libeigen/eigen/-/commit/e246f9cb68d07e8f15c60a2404ac9a625c349223
https://gitlab.com/libeigen/eigen/-/commit/43a01f06ad52a2e07e8b522eb7106bdde5d8bb5c

@SteveBronder

@SteveBronder No worries we will get this sorted and it is getting closer.

Things were a little commingled as I recall. What we have now in RcppEigen is

Eigen 5.0.1 pretty much as is plus needed R / CRAN changes
You had mentioned 'something something Eigen 5.0.2' at some point ...
... so it could be those changes are not in our 5.0.1 base

So right now rstan / StanHeaders is the odd man out. I have spent this week preparing some fourty or so PRs for everthing that failed w.r.t. Eigen 5.0.1 that was compile-time related so it sidesteps these rstan / StanHeaders issue.

It would be truly valuable if someone (you ?) could start from the Eigen 5.0.1 we have in RcppEigen 0.4.9.9-2 and creates a clean and documented set of patches so that we have something to re-apply for later Eigen releases that may / may not have that in their release. Application and motivation-wise speaking, I think that ball is over in the corner of 'team STAN' and I would greatly appreciate any assistance in getting us closer to releasing this on CRAN.

PS:

I tried reading through this thread but it was kind of hard to follow if these changes were brought in or not.

Yes. The thread is a mess. The repo for RcppEigen should be much easier to discern.

That sounds good. I will import the commits in Eigen above to patches for RcppEigen

Great. We can start one by one. The first one you mention https://gitlab.com/libeigen/eigen/-/commit/e246f9cb68d07e8f15c60a2404ac9a625c349223 lays a foundation via a trait likely missing in my repo (of "just Eigen 5.0.1", more or less) and the others build on it. So maybe an updated RcppEigen is likely the next step, and then (if needed) another StanHeaders. More next week....

@SteveBronder

@SteveBronder On a lurch, first step

RcppEigen as in the repo, plus the gitlab patch against Fill.h: ❌ as baggr still segfaults in tests

To be continued but I'll more away from keyboard than at keyboard the coming days.

@SteveBronder

@SteveBronder @bgoodri @andrjohns I may have a fix! Though you may want to refine this. Read on ...

In short, the comprises two parts:

the gitlab patch against Fill.h in (Rcpp)Eigen, along
a one-line change in stan/math/rev/core/Eigen_NumTraits.hpp setting RequireInitialization = 1, (diff below)

This was found by the same model I used during the wave of fourty-some PRs I created this week, namely DeepSeek V4 Flash-0731. You may have access to more powerful ones. But I basically told it to examine the baggr segfault, and to focus on RcppEigen and StanHeaders, not baggr itself. I validated it by running R CMD check against birdie which also segfaulted -- and now passes.

I believe you have some other (pending ?) patching related to NumTraits so maybe this can be achieved without flipping the constant as I did here.

The diff follows.

--- /tmp/Eigen_NumTraits.hpp.bak	2026-10-02 01:44:49.784997766 +0000
+++ stan/math/rev/core/Eigen_NumTraits.hpp	2026-10-02 01:44:49.786284935 +0000
@@ -59,7 +59,7 @@
     /**
      * stan::math::var does not require initialization.
      */
-    RequireInitialization = 0,
+    RequireInitialization = 1,
 
     /**
      * Twice the cost of copying a double.

@andrjohns

a one-line change in stan/math/rev/core/Eigen_NumTraits.hpp setting RequireInitialization = 1, (diff below)

That was done in Stan math for update to Eigen 5.0+ @andrjohns did you port the stan math changes I did in stan-dev/math#3271 to StanHeaders?

Also Dirk I'm traveling today, but should have time to do the patches either later in the afternoon or Monday at the latest.

If the RequireInitialization = 1 was supposed to be included in the StanHeaders 2.39.1 on CRAN, then I must have missed it. But I can do a .2 release any time.

No rush, was AFK all day too. Looks likewheels are in motion and maybe that fix is just what we need.

@SteveBronder

Hi @SteveBronder @bgoodri @andrjohns : So what worked for me is

small patch suggested by @SteveBronder and currently in (now committed / pushed) branch fix/stanheaders
the 'one character change' of setting RequireInitialization to 1 as described above

It would be terrific if you could confirm this / ship a StanHeaders with it. It feels that we are quite close.

@eddelbuettel

@eddelbuettel See the PR below which has the two patches from Eigen that Stan needed to compile correctly.

#152

@bgoodri the stan math changes for Eigen 5.0.1 are all in this commit stan-dev/math@d6833b8 . Did this get ported to StanHeaders?

@SteveBronder

@SteveBronder Great. I streamlined this a little (the PR probably wanted to be against the branch already containing one of its two commits) and brought that to the RcppEigen main branch. I will increment the micro version. With that RcppEigen should be ready.

@bgoodri I will await word from you about when StanHeaders on CRAN has RequireInitialization = 1; as needed, or which ever equivalent changes you deem best. You should be able to base all your tests on the main branch of RcppEigen, and you should have corresonding R-universe builds in an hour or two.

@bgoodri

Paging @bgoodri :

@bgoodri I will await word from you about when StanHeaders on CRAN has RequireInitialization = 1; as needed, or which ever equivalent changes you deem best. You should be able to base all your tests on the main branch of RcppEigen, and you should have corresonding R-universe builds in an hour or two.

@bgoodri

@bgoodri I've pushed an update to thev2.39.0 branch with the RequireInitialization = 1 update that I'd missed, and bumped the version number to 2.39.2. Test away and ready for you to submit!

Navigation Menu

Repository navigation

Upgrade to Eigen 5.0.0 #143

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Upgrade to Eigen 5.0.0 #143

Description

Activity

eddelbuettel commented on Jan 5, 2026

WardBrian commented on Jan 5, 2026

eddelbuettel commented on Jan 5, 2026

Footnotes

eddelbuettel commented on Jan 12, 2026

WardBrian commented on Jan 13, 2026

eddelbuettel commented on Jan 13, 2026

bgoodri commented on Jan 13, 2026

eddelbuettel commented on Jan 13, 2026

SteveBronder commented on Jan 13, 2026

SteveBronder commented on Jan 15, 2026

eddelbuettel commented on Jan 15, 2026

SteveBronder commented on Jan 15, 2026

eddelbuettel commented on Jan 15, 2026

bgoodri commented on Jan 18, 2026

eddelbuettel commented on Feb 2, 2026

SteveBronder commented on Feb 2, 2026

eddelbuettel commented on Feb 10, 2026

SteveBronder commented on Feb 10, 2026

eddelbuettel commented on Feb 10, 2026

SteveBronder commented on Feb 10, 2026

eddelbuettel commented on Feb 10, 2026

SteveBronder commented on Feb 10, 2026

eddelbuettel commented on Feb 10, 2026

eddelbuettel commented on Feb 10, 2026

bgoodri commented on Feb 11, 2026

SteveBronder commented on Feb 13, 2026

eddelbuettel commented on Feb 13, 2026

SteveBronder commented on Feb 27, 2026

eddelbuettel commented on Feb 27, 2026

SteveBronder commented on Mar 2, 2026

eddelbuettel commented on Mar 2, 2026

SteveBronder commented on Mar 3, 2026

SteveBronder commented on Mar 3, 2026

eddelbuettel commented on Mar 3, 2026

eddelbuettel commented on Mar 3, 2026

eddelbuettel commented on Mar 3, 2026

eddelbuettel commented on Mar 3, 2026

SteveBronder commented on Mar 4, 2026

eddelbuettel commented on Mar 4, 2026

eddelbuettel commented on Jun 5, 2026

eddelbuettel commented on Jun 6, 2026

eddelbuettel commented on Jun 7, 2026

bgoodri commented on Jun 7, 2026

eddelbuettel commented on Jun 7, 2026

SteveBronder commented on Jun 8, 2026

eddelbuettel commented on Jun 8, 2026

SteveBronder commented on Jun 9, 2026

eddelbuettel commented on Jun 9, 2026

eddelbuettel commented on Jun 18, 2026

bgoodri commented on Jun 18, 2026

bgoodri commented on Jun 19, 2026

SteveBronder commented on Jun 22, 2026

eddelbuettel commented on Jun 29, 2026

andrjohns commented on Jul 1, 2026

bgoodri commented on Jul 1, 2026

eddelbuettel commented on Jul 6, 2026

bgoodri commented on Jul 13, 2026

andrjohns commented on Jul 13, 2026

eddelbuettel commented on Jul 13, 2026

eddelbuettel commented on Jul 21, 2026

andrjohns commented on Jul 21, 2026

eddelbuettel commented on Jul 27, 2026

SteveBronder commented on Jul 28, 2026

eddelbuettel commented on Aug 4, 2026

andrjohns commented on Aug 6, 2026

SteveBronder commented on Aug 6, 2026

eddelbuettel commented on Aug 21, 2026

eddelbuettel commented on Aug 27, 2026

bgoodri commented on Aug 28, 2026

eddelbuettel commented on Aug 28, 2026

bgoodri commented on Aug 31, 2026

eddelbuettel commented on Sep 1, 2026

eddelbuettel commented on Sep 2, 2026

bgoodri commented on Sep 2, 2026

eddelbuettel commented on Sep 2, 2026

eddelbuettel commented on Sep 4, 2026