-
-
Notifications
You must be signed in to change notification settings - Fork 23
JavaScript: account for the fact that our JavaScript bindings use a 32-bit address space #1367
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
Closed
Closed
Changes from 3 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
08dafcd
Added a test for a very big CellML file.
agarny 00c308d
Generator: use the analyser model's areEquivalentVariables() method.
agarny ae845f5
AnalyserModel: improved and fixed areEquivalentVariables().
agarny 4fd6a06
Merge branch 'issue1375' into issue1366.
agarny 3dbe3ba
Removed some TODOs and inline comments from our very bid model.
agarny 818c1af
Analyser model: replaced a logical and with a bitwise and.
agarny e5576c8
Merge branch 'main' into fixes
agarny cbec4f1
Merge branch 'main' into fixes
agarny File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
is this a new thing that we haven't done before? or doing something we've done before in a different way?
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.
CODE_COVERAGE_ENABLEDis indeed a new thing. It is needed for our code coverage test (in case the name didn't give it away! :)). We have a line that normally reads:return first == other.first && second == other.second;second == other.secondis some kind of guard, but if I recall correctly code coverage tells us that it is is neverfalseand that's because iffirst == other.firstisfalsethensecond == other.seconddoesn't get evaluated. So, I useCODE_COVERAGE_ENABLEDfor the case the code is use during code coverage and, in this case, rather than executing:return first == other.first && second == other.second;we execute:
which is the same (albeit less efficient) and has 100% coverage.
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.
I am super unkeen to see this type of switching happening. We have avoided this as it simply makes a mockery of claiming that we have 100% line coverage. Have you had a look at the generated machine code to actually see if the second is less efficient (has more machine code), quite often the compiler generates the same code when optimisation is turned on.
Uh oh!
There was an error while loading. Please reload this page.
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.
As far as my analysis goes we can replace && with &:
// Bitwise test on booleans.
(first == other.first) & (second == other.second)
This will not create a branch in the debug build.
The optimised builds of either way will produce very similar machine code.
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.
I have just checked with https://godbolt.org/ and the generated machine code is different for
&and&&in debug mode BUT the same in release mode. So, thanks for that, will implement your suggestion.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.
It seems like a significant change that we shouldn’t bury under other changes.
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.
for sure! We should have a single clear PR that makes a change like that isolated from any other code changes.
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.
And do we want that done before this goes through? So that this PR can take advantage of C++20?
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.
I wouldn't think so. You'd want to update all similar comparisons, right? This particular issue has already been resolved, right? so its not blocking this PR being merged.
Uh oh!
There was an error while loading. Please reload this page.
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.
Happy to leave this PR as-is and have C++20 added in another PR that will also remove those
operator==()methods.