-
Notifications
You must be signed in to change notification settings - Fork 16
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
Include compiled mod files. #1131
Conversation
2492b8c
to
16d82cd
Compare
The hope is that it can generate a suite of references. Then when things change we have The advantage is that we can automatically update the references; and don't need to do so manually. The cost is that we need to commit entire files. Meaning we test the whole file not just the "interesting" parts of each usecase. Which means we're sensitive to more changes. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1131 +/- ##
==========================================
+ Coverage 88.38% 88.40% +0.02%
==========================================
Files 176 175 -1
Lines 12946 12934 -12
==========================================
- Hits 11442 11434 -8
+ Misses 1504 1500 -4 ☔ View full report in Codecov by Sentry. |
This comment has been minimized.
This comment has been minimized.
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.
Those "golden" reference files could be a potential solution. However I think that this PR is missing a test that compares the "golden" reference file with the one generated using the NMODL being tested.
Let's discuss this with @pramodk and @ohm314 to see what Omar has been working on to make the diff of these "golden" reference files nicer and see how to proceed
Yes, I agree. In a first step I'd like to understand if it helps with my difficulty reviewing PRs. While I can see what changed and might understand at a high-level what's happening, I can't see the generated code. The question is: does seeing how the generated code changed help understand a PR? I suspect this might help with that. As for checking/diffing: fist time they're uploaded the references are completely new. After that the diff will only contain the lines that change due to a specific PR. Preferably one would add the file in a separate commit. Before any changes. Then make changes and have the diff already valid on the first PR. |
It definitely helps 👍
I am afraid that with so many files we are going to start forgetting to update them in case there are any changes or miss small changes to them. I believe it's necessary to have a way to automatically update them when opening a PR with some changes. Once way to enforce that is to have a test that fails if there is a difference between the generated and the "golden" file. |
100% correct, that's an important part missing: those files must be automatically generated. |
16d82cd
to
5934204
Compare
This comment has been minimized.
This comment has been minimized.
@1uc : I assume this will be updated by pushing references to https://github.com/BlueBrain/nmodl-references. So I will keep this as it is. |
Yes, exactly. |
7900c31
to
75956e3
Compare
@pramodk the generated files have been move to the submodule. there's a PR ready in the submodule: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
8859eb6
to
6c9c664
Compare
4c4fe09
to
c4c149c
Compare
This comment has been minimized.
This comment has been minimized.
c4c149c
to
4962518
Compare
I currently have a different PR which introduces changes. To help other judge if this is useful, I'll post the output of the two approaches: unit-testing and external as sketched here. |
The proposed tests fail as follows:
|
The unit-test fail as follows:
|
The diff based approach isn't stellar, but at least I can:
I would also say that one can quickly identify that like these changes (if they were correct and would compile) would likely not affect any of the computations. They're just slightly rearranging some parameters passed to certain NMODL generated functions. |
I think the unit-test approach isn't sensitive to this (precise) change (which is interesting):
|
The ugly format can easily be fixed. Yielding the following output:
|
Logfiles from GitLab pipeline #195513 (:white_check_mark:) have been uploaded here! Status and direct links: |
We can now precisely point out issues, e.g. here: at time of writing my copy of NMODL generates faulty code that I can't copy-paste, but since these references are stored I can copy/link from there. |
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
Add a script for generating the reference values of compiled mod files. These are included with the sources to enable the following: * during review the reviewer can see what was generated. * these can serve as golden tests, flagging changes in unrelated mod files.
Co-authored-by: JCGoran <[email protected]>
553857f
to
20fd2c2
Compare
Add a script for generating the reference values of compiled mod files. These are included with the sources to enable the following: * during review the reviewer can see what was generated. * these can serve as golden tests, flagging changes in unrelated mod files. --------- Co-authored-by: JCGoran <[email protected]>
Add a script for generating the reference values of compiled mod files. These are included with the sources to enable the following: