-
Notifications
You must be signed in to change notification settings - Fork 100
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
Add support for merge-include in the Interface API #768
Conversation
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Codecov Report
@@ Coverage Diff @@
## sdf12 #768 +/- ##
==========================================
+ Coverage 90.71% 90.76% +0.05%
==========================================
Files 78 78
Lines 12447 12535 +88
==========================================
+ Hits 11291 11378 +87
- Misses 1156 1157 +1
Continue to review full report at Codecov.
|
Per VC, in conjunction w/ #764, having frame graph construction be based solely on Interface API may help simplify both this and that PR. |
Signed-off-by: Addisu Z. Taddese <[email protected]>
…ace elements Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
…eToGraph Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
there are still a few test failures |
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 with minor nits.
Took me a while to fully grok some of the nested include tests, but they do test the full gamut - thanks for writing those!
src/FrameSemantics.cc
Outdated
for (const auto &item : model->Joints()) | ||
{ | ||
// TODO(azeey) In theory, the child could be "__model__" in which case, | ||
// we'd have to use the proxy frame here, but not sure if "__model__" is |
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.
nit "not sure" seems like it could be confirmed; worth adding a test?
(But to be fair, an unscoped __model__
does seem like an awkward child)
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've confirmed that __model__
is not allowed in //joint/child
and added a test in 09b6421.
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.
Awesome!
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.
looking at the error messaged added to the test in 09b6421, I believe the error is raised by the checkJointParentChildNames function in parser.cc
. To be honest, I wouldn't take this as strict proof that __model__
is not allowed in //joint/child
. I think our proposal is ambiguous about this, and if we modified the checkJointParentChildNames
function to explicitly allow __model__
, I think it would work. The same logic applies to __model__
as a parent frame as well.
If we want to disallow __model__
in //joint/parent
and //joint/child
, then let's be explicit about it
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 just tested this and found out that the logic in checkJointParentChildNames
also prevents a scoped __model__
from working. Since we allow __model__
in @relative_to
and @attached_to
, I think it makes sense that it should be allowed in both //joint/parent
and //joint/child
. I think it would be best for me to create another PR making that change and update this PR afterward. Thoughts?
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.
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.
sounds like a good plan
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.
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
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.
@scpeters I've addressed the test failures, PTAL. There's a CMake warning due to an infra issue (see gazebo-tooling/release-tools#625 (comment))
src/FrameSemantics.cc
Outdated
for (const auto &item : model->Joints()) | ||
{ | ||
// TODO(azeey) In theory, the child could be "__model__" in which case, | ||
// we'd have to use the proxy frame here, but not sure if "__model__" is |
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've confirmed that __model__
is not allowed in //joint/child
and added a test in 09b6421.
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.
(But to be fair, an unscoped model does seem like an awkward child)
my github interface is weird right now; I can't reply to that other thread, but I had one more comment: the checkJointParentChildNames
logic also disallows an unscoped __model__
as a joint parent, which strikes me as less awkward than as a child. So I'd rather make an affirmative decision about this rather than inferring intent from the existing code
This reverts commit 09b6421. Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
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've reviewed all but FrameSemantics.cc and the test. I'll finish reviewing next week. It's looking good. I just noticed one minor thing
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've finished reviewing; I just have a few nits and then I'll be ready to approve
nit: I think the test/integration/model/joint_model_parent_or_child.toml
file could be renamed? I'm not sure what the parent_or_child
part of the name means
Signed-off-by: Addisu Z. Taddese <[email protected]>
I renamed it to |
This pull request has been mentioned on Gazebo Community. There might be relevant details there: https://community.gazebosim.org/t/new-ignition-releases-2022-04-13-fortress-edifice/1367/1 |
🎉 New feature
Closes #658
Summary
Builds on top of #764 to add support for merge-includes for custom parsers.
TODO
Test it
Run the
INTEGRATION_interface_api
test.Checklist
[] Added example and/or tutorialcodecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge