-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support display of higher-level ns #876
Conversation
Unit Tests Summary 1 files 25 suites 1m 37s ⏱️ Results for commit 8ba5023. ♻️ This comment has been updated with latest results. |
Unit Test Performance Difference
Additional test case details
Results for commit be0cb8c ♻️ This comment has been updated with latest results. |
Code Coverage Summary
Diff against main
Results for commit: 8ba5023 Minimum allowed coverage is ♻️ This comment has been updated with latest results |
…rtables into 135_higher_level_ns
I hate you spellchecker |
Signed-off-by: Davide Garolini <[email protected]>
So the issue here is with what that should do. I think the most reasonable thing for that to do would be to reset all colcount formats throughout the column tree. The issue with that is that then Its probably still the right thing, but what are your thoughts? @Melkiades |
To my mind, |
There are a few things that I think make that a non-starter, though I agree it would be nice in principle. First, we cannot do that for values, because assigning a vector of values onto the nodes of a tree structure isn't trivial or something the user is going to be able to easily understand. In other words, if we have
And we say
where are each of those values going to be assigned? Secondly, for backwards compatability we need For visibility and format, the issue is different desired behavior. I am not convinced turning on visibility of all column counts for tables with non-trivial column structure would ever/even remotely often be what the user wants to do, they're likely to want to turn on and off specific (sets of) column counts. For format, though, the opposite is true, if they are ever in a position to want to modify the colcount format for an already built table, they very likely do want it to be changed across the board, and are quite unlikely to only want to change the format of specific column counts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gmbecker {scda.test} fails after this. It is because before, adding col_counts
to build_table()
was forcing to print the col counts, now it is no more true. How do you want to proceed? shall we reinstate that?
…isplay for leaf cols
Signed-off-by: Gabe Becker <[email protected]>
fixed @Melkiades, with documentation (behavior wasn't documented before) and a regression test, though that argument is marked as "soft deprecated" in the documentation (and not just by me, since it uses lifecycle which I dont), so official templates arguably "shouldn't" be relying on that feature |
wordlist update Signed-off-by: Joe Zhu <[email protected]>
I have read the CLA Document and I hereby sign the CLA |
@gmbecker There are still changes in snapshots downstream for aet04_pi |
For example: ── Failed tests ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Failure (test-table_aet04_pi.R:66:3): AET04_PI full table is produced correctly
Snapshot of code has changed:
old[6:31] vs new[6:31]
(N=86) (N=86) (N=86) (N=72) (N=72) (N=72) (N=96) (N=96) (N=96)
——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
SKIN AND SUBCUTANEOUS TISSUE DISORDERS
- Total number of patients with at least one adverse event 19 (22.1%) 4 (4.7%) 0 34 (47.2%) 6 (8.3%) 0 35 (36.5%) 6 (6.2%) 2 (2.1%)
+ Total number of patients with at least one adverse event 19 (35.2%) 4 (44.4%) 0 34 (27.6%) 6 (40.0%) 0 35 (30.7%) 6 (40.0%) 2 (100%)
- PRURITUS 9 3 0 36 8 0 24 1 1
+ PRURITUS 15 33 0 21 40 0 20 7 50
- ERYTHEMA 10 0 0 19 0 0 16 2 0
+ ERYTHEMA 17 0 0 11 0 0 13 13 0
- RASH 6 1 0 15 1 0 14 2 0
+ RASH 9 11 0 9 7 0 11 13 0
- SKIN IRRITATION 3 0 0 7 0 0 6 1 1
+ SKIN IRRITATION 6 0 0 4 0 0 5 7 50
GENERAL DISORDERS AND ADMINISTRATION SITE CONDITIONS
- Total number of patients with at least one adverse event 10 (11.6%) 2 (2.3%) 0 29 (40.3%) 5 (6.9%) 0 31 (32.3%) 8 (8.3%) 0
+ Total number of patients with at least one adverse event 10 (18.5%) 2 (22.2%) 0 29 (23.6%) 5 (33.3%) 0 31 (27.2%) 8 (53.3%) 0
and 16 more ...
* Run `testthat::snapshot_accept('table_aet04_pi')` to accept the change.
* Run `testthat::snapshot_review('table_aet04_pi')` to interactively review the change.
Failure (test-table_aet04_pi.R:88:3): AET04_PI variant 1 is produced correctly |
this doesnt look right |
downstream was broken in https://github.com/insightsengineering/scda.test/actions/runs/9502364605/job/26190158465?pr=141 |
Now the non-cran works so it these are coming out. I had the issue on my local. No issues from main, |
Should be fixed, I think, with regression test @Melkiades @shajoezhu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! Thanks @gmbecker
ready to move forward, downstream breaking change fixed, will revist remaining items as seperate issues
closes #135 and #752