Version 1.1.9 for CRAN #1000
Comments
|
Sigh, the stuff on M1Mac is that old platform-variable test for doing the right thing when the Hessian can't be inverted. In fact we had already commented it out in cd020c2 (I think it would be better to The other issues are pretty trivial, I may already have fixed them in some branch or other ... I, too, have a lot of stuff on branches that's not merged into devel yet (especially I'll try to submit/update PRs for the Other than running the reverse-dependency checks, though, this shouldn't (??) be too hard? Did CRAN really give you only a 4-day window, or did they contact you a while ago ... ?? PS congratulations, this is issue #1000 ... |
|
They contacted me a while ago on March 3rd when I was on vacation, so it slipped to the back of my mind. Sorry about that. I can focus on this today and over the weekend. |
|
Can we ignore that? |
|
Thanks for the HTML tidy tip. That fixed that problem and now check as CRAN is good. It passed tests with R 4.3.3 on win-builder, but has some errors with 4.2.3 and the development version. I'm still trying to understand these. There are a lot of problems with the reverse dependency checks which I'm reading through and trying to understand. I'm not going to try to merge Should we try to merge in |
I just extended the GitHub PS this is a headache/rabbit hole, because getting all the LaTeX stuff to work right on GH actions is going to take a lot of trial and error ... update, R-CMD-check-allOS seems to be OK with LaTeX now. Can replicate the windows-oldrel problem, have no idea: figuring this out seems hard (I don't see anything in the R NEWS that would suggest anything about |
|
I just put in a bit of code to skip the problematic (test-basics lines 137, 138, 149) if R version is < 4.3.3 ... re-running "allOS" check here, we'll see how it goes. Also restarted my revdep check run after the priors PR merge (thanks!) - will see how it goes. |
|
running revdepcheck locally the only thing I see failing is (in the meantime it looks like I finally got the test-skipping stuff right, see here ...) Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
[1] 0.14953175 - 0.14953169 [1]
[2] 0.23286508 - 0.23286503 [2]
[3] 0.05429365 - 0.05429360 [3]
[4] 0.48286508 - 0.48286503 [4]
[5] -0.01713492 - -0.01713497 [5]
[6] -0.37427778 - -0.37427783 [6]
[7] -0.01713492 - -0.01713497 [7]
[8] 0.14953175 - 0.14953169 [8]
[9] -0.51713492 - -0.51713497 [9]
[10] 0.08286508 - 0.08286503 [10]
... ... ... and 290 more ...Looks like this is from the Gaussian disp change and can be 'fixed' by simply loosening the tolerance on a test slightly ( |
|
That sounds better than the revdepcheck results I got from the cluster. I couldn't run it on my computer before because my computer kept freezing and complaining about using too much memory, even when I told the function to only use 2 out of 8 nodes. Are you using a laptop? This could be my laptop getting old. I sent the latest version to winbuilder and revdepcheck on the cluster again and should have results soon. |
|
I'm using a fairly powerful machine that I have at home, bought near the beginning of the pandemic - 32 cores, 60+GB of memory. It took about 1 hour to run I submitted a PR for |
|
There are still the 3 errors on R-devel according to win-builder. I don't think I can work on this much more today, but I can tomorrow. |
|
Those errors seem extremely cryptic to me. Wrote to |
|
Digging down a little bit further into the The install logs (scroll to the end) show the same issue. I'm not sure that's the problem, but it's highly suspicious since the log also shows that the failure occurs on the first non-trivial I also suspect that the tests are failing/hanging on Finally, the I'm pretty sure based on this message from Mikael Jagan that 1.7.0 already exists and that the CRAN maintainers decided it would be good to install it on win-builder ... |
|
The issue is that we Matrix maintainers checked Matrix 1.7-0 on win-builder as recently as yesterday. The checked version became the installed version for everyone else. It is a "feature", as documented at https://win-builder.r-project.org/:
So you could get things working again by uploading a TMB tarball to win-builder, with the side effect of having TMB rebuilt under the currently installed version of Matrix (whatever it is at the time). That shouldn't be needed in general. It is just bad luck that we are checking around the same time ... An alternative is to upload the original Matrix tarball (in this case 1.6-5). That should perhaps become our habit whenever checking an ABI-breaking Matrix ... |
|
(I don't want to step on your toes so I'm just going to let you do one of the above ... Going forward we'll have to remember to clean up after our own checks ... @mmaechler) |
|
Thanks @jaganmn for that insight. I just uploaded |
|
A few points:
|
|
Now it passes checks on R-devel. So uploading the right Matrix version fixed that problem. Now I can't understand why, but it doesn't pass EDIT: I may have complied this version with the development version of |
|
When I ran this with the development version of TMB I got an (expected) WARNING about "Found ‘_ZSt4cout’, possibly from ‘std::cout’ (C++);Object: ‘glmmTMB.o’", but nothing else. I think you should go ahead and submit! https://en.wiktionary.org/wiki/damn_the_torpedoes |
|
After I compiled with CRAN's I guess we should already start planning for 1.1.10 to coincide with the next |
|
according to the |
|
Thanks for asking. I'm busy right now with another project. There were 2 failed tests on the insight package, a reverse dependency. I haven't had a chance to look at them yet, but maybe it's also related to the Gaussian sigma change. |
|
Sigh. Seems likely. I'll work on this if I get a chance. |
|
I fixed this and submitted a PR (here), so it's probably OK to go back to CRAN and tell them this is resolved (you could wait until the |
|
This may also break code in performance (but I'm planning a new release the next days anyway). I think functions like
then tests shouldn't probably be changed, but rather we want to fix Maybe we could continue this discussion here: easystats/insight#861 Either way, a fix for insight can be prepared in time and should not delay glmmTMB submission. |
|
Success on CRAN! |
CRAN emailed me and requested a new version by March 17th. I was hoping to get the
dispREbranch ready for that, but think it might be time to start working towards this in parallel. I have to teach today, so I probably won't get to it until tomorrow.We have issues to fix. The email specifically said to remember to look at the 'Additional issues'.
The text was updated successfully, but these errors were encountered: