Conversation
|
Thanks for working on this! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1165 +/- ##
==========================================
+ Coverage 90.85% 90.87% +0.02%
==========================================
Files 14 15 +1
Lines 5924 5938 +14
==========================================
+ Hits 5382 5396 +14
Misses 542 542 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@jgabry do you know why macos devel would be failing in the R dep setup? Doesn't seem to happen in main--could this be a cache/GHA error? https://github.com/stan-dev/cmdstanr/actions/runs/23573417706/job/68640740296 |
|
Looks like something is broken in R Core or pak which is causing macos devel to fail. |
Took a quick glance at the logs, I agree this seems likely. I’ll try to take a look at the actual PR tomorrow. |
|
Thanks! Looks like this (new) function in tools is broken, planning on submit a patch. Got fixed, so should be gtg soon |
jgabry
left a comment
There was a problem hiding this comment.
Mostly looks great, just a few comments/questions.
Still seems broken (hitting the same error in other repos too) |
|
I see builds failing, but I think the specific error that I ran into should be fixed. I think the C API changed so some packages aren't building (abind in posterior, lazyeval in bayesplot). I don't think there are any other deps which are problematic on devel for cmdstanr, so hopefully this run will go through |
It's still failing in other recent cmdstanr PRs. This one is from today: https://github.com/stan-dev/cmdstanr/actions/runs/23760099930/job/69225022781?pr=1166 Not a big deal, we can just wait for it to sort itself out I guess? |
|
Missed that. Not sure why its still failing since the code is fixed in source--maybe the R install is cached? Waiting it out seems good to me. |
|
There are still some snapshots since expect_known_output() was deprecated and the suggestion is to use a snapshot. |
| expect_not_true <- function(...) expect_false(isTRUE(...)) | ||
|
|
||
| transform_print_snapshot <- function(x) { | ||
| vapply(x, function(line) { |
There was a problem hiding this comment.
These aren't needed for this PR, but left them in for the snapshot PR as they're helpful in normalizing results.
There was a problem hiding this comment.
Is there a reason to put them in this PR as opposed to the snapshot PR where they'll actually be used? I guess I can look at them as part of this PR, but I would kind of prefer to review them as part of the PR where they are used, so I can see them in use when reviewing them.
|
I swapped a number of things to use withr functions instead of base R so that tests don't have to manually clean up after themselves with a bunch of on.exit() calls. withr is already a suggested import so I see no reason not to swap. |
jgabry
left a comment
There was a problem hiding this comment.
Looking good. Just a couple of comments/questions/suggestions. Might have more, but maybe not.
|
|
||
| # would error if fitting failed | ||
| expect_silent(fit$draws()) | ||
| expect_no_error(fit$draws()) |
There was a problem hiding this comment.
I think testthat 3e still supports expect_silent() right? Any reason to weaken this test to expect_no_error()?
| fail(sprint("Model executable '%s' does not exist after compilation.", mod$exe_file())) | ||
| } | ||
| if(!is.null(before_mtime)) { | ||
| if(!is.null(before_mtime) && mtime_check_enabled) { |
There was a problem hiding this comment.
What's the motivation for adding the new mtime_check_enabled?
| local({ | ||
| stan_files <- dir(test_path("resources", "stan"), pattern = "\\.stan$", full.names = TRUE) | ||
| exe_files <- cmdstanr:::cmdstan_ext(cmdstanr:::strip_ext(stan_files)) | ||
| existing_exe_files <- exe_files[file.exists(exe_files)] | ||
| if (length(existing_exe_files) > 0) { | ||
| unlink(existing_exe_files, force = TRUE) | ||
| } | ||
| }) | ||
|
|
There was a problem hiding this comment.
Seems useful, but was this added because we weren't starting from a clean slate before or just as an extra precaution?
There was a problem hiding this comment.
Actually, we already have teardown-remove-files.R, which does something similar that runs after the tests.
I think maybe the best approach is to replace both the new code here and the teardown file with a single setup file that does both jobs in one place? I think both instead of one or the other because the pre-run cleanup is sufficient but the post-run teardown is nice especially if running tests locally.
What do you think?
There was a problem hiding this comment.
So we could have a function defined in setup.R that cleans up the files and then call it twice in setup, deferring the second one? Something like this maybe:
cleanup_stan_exes()
withr::defer(cleanup_stan_exes(), testthat::teardown_env())
| json_output_df <- readLines(temp_file_mat) | ||
| expect_identical(json_output_df, json_output_mat) | ||
| expect_identical(readLines(temp_file_df), readLines(temp_file_mat)) | ||
| announce_snapshot_file(name = "json-df-matrix.json") |
| expect_not_true <- function(...) expect_false(isTRUE(...)) | ||
|
|
||
| transform_print_snapshot <- function(x) { | ||
| vapply(x, function(line) { |
There was a problem hiding this comment.
Is there a reason to put them in this PR as opposed to the snapshot PR where they'll actually be used? I guess I can look at them as part of this PR, but I would kind of prefer to review them as part of the PR where they are used, so I can see them in use when reviewing them.
Migrated to latest testthat edition.
Closes #1155.