-
Notifications
You must be signed in to change notification settings - Fork 21
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
Imports revisited #248
Imports revisited #248
Conversation
…ons_import test model.
Starting work on a test to explore resolving of imports.
Testing that the correct number of imports is detected.
Added a few new methods to the import class to track the source model used to resolve the import. And then the test code which makes use of this to resolve the imports in the existing test model.
This seems to have exposed some issues in the parsing of encapsulation hierarchies, so parking this for now to explore that issue.
The tests are now working as expected (see cellml#171), and all passing.
Models don't all validate successfully, but outstanding issues likely due to cellml#174 and cellml#175.
… in complex_imports.xml.
Minor suggestions in documentation
The introduction of the
|
src/model.cpp
Outdated
libcellml::ModelPtr model = parser.parseModel(buffer.str()); | ||
if (model) { | ||
importSource->setModel(model); | ||
model->resolveImports(url); |
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.
Won't this cause all imports in the imported model to be resolved, regardless of whether they are needed?
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.
OK, so we always try to resolve all imports in all imported models, but the hasUnresolvedImports
method only checks the required imports are resolved. I guess this is more an efficiency thing that an actual problem with the 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.
My point was that, from the code in Parser::parseModel()
, model
will never be equal to nullptr
, so no point for the test.
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.
yep - the if (model)
can be removed.
Could you try to add the following and see whether it makes any difference with VS 2017?
|
Ok, my bad, I should have read your warning message properly. My idea was correct, except that it should have read:
So, now, everything should be fine (it is using my local copy of VS 2017). |
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.
Phew! Everything is back working with no warnings for me. I'm happy with the changes Alan has made, but would be good for someone with a bit more C++ expertise to confirm the new approach for import recursion makes sense.
Happy to look at the bindings bit for this once you're sure the interface is final! |
pretty sure the interface is final, so would be good to look at the bindings. |
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 merge this now, from a bindings point of view
src/api/libcellml/model.h
Outdated
* @brief Resolve all imports in this model. | ||
* | ||
* Resolve all @c Component and @c Units imports by loading the models | ||
* from local disk through relative urls. The @p baseFile is used to determine |
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.
Might want to replace "urls" with "URLs" to be consistent with the rest of our documentation.
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.
On that note, these methods setUrl
and getUrl
and such, should they be capitalised this way? Or getURL
etc.?
(Personally, my left shoulder likes using the shift key as little as possible)
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.
No, setUrl()
and getUrl()
should be left as-is. Indeed, we use lower camel case for class methods (see http://libcellml.readthedocs.io/en/latest/dev_coding_standard.html).
|
||
# void setReset(const ResetPtr &reset); | ||
e = Error() | ||
e.setReset(Reset()) |
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.
Definitely not a blocker, but not sure there is much point in having such a test (and similar ones) since setReset()
is effectively tested as part of test_get_reset()
.
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 think you're right, but I just wanted to be systematic in having a test for every method!
from libcellml import Model | ||
|
||
m = Model() | ||
m.resolveImports('file.txt') |
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.
No tests as such?
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.
The actual functionality is tested by the C++ tests. Here I just want to check that the method exists and doesn't raise any exceptions!
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.
Fair enough.
Apart from a few comments above, it all looks good to me. |
Moving @nickerso work from outside the library to inside. The added import functionality only works for local on disk imports.
Addresses #238.
This PR supersedes #167, should this PR be merged then #167 should be closed and not merged.