Conversation
| lines[separator_indices[1] + 1:] + implicit_output) | ||
| feedback_msg = parse_message_string( | ||
| pkg_name, action_name + ACTION_FEEDBACK_MESSAGE_SUFFIX, message_string) | ||
| #---------------------------------------------------------------------------------------------- |
There was a problem hiding this comment.
@sservulo Hmm, implicit fields may clash with explicitly given ones. Action generation in ROS1 would nest message definition as a field of a completely implicit message, see genaction.py sources. Alternatively, we could check for the presence of duplicate entries. @sloretz @jacobperron thoughts?
There was a problem hiding this comment.
That's a good point. +1 to nesting the user defined message
|
Addressed review comments. |
| action_name + ACTION_GOAL_MESSAGE_SUFFIX + SERVICE_REQUEST_MESSAGE_SUFFIX, | ||
| request_message_string) | ||
|
|
||
| implicit_output = ["bool accepted", "builtin_interfaces/Time stamp"] |
There was a problem hiding this comment.
@jacobperron @hidmic Will rcl_actions associate the service response by mapping goal ID to the request sequence number, or by having the higher level client library get the goal ID out of the message? If the former then these fields should be OK, if the latter then the stamp field should be action_msgs/GoalInfo so it includes a goal id too.
There was a problem hiding this comment.
I think that'd be currently the case (using goal IDs I mean).
| action_name + ACTION_RESULT_MESSAGE_SUFFIX + SERVICE_REQUEST_MESSAGE_SUFFIX, | ||
| request_message_string) | ||
|
|
||
| implicit_output = ["int8 status"] |
There was a problem hiding this comment.
What's the status field for?
There was a problem hiding this comment.
It's the goal status as defined in the proposal.
There was a problem hiding this comment.
Whoops, I completely forgot about that
There was a problem hiding this comment.
@jacobperron same question about rcl_actions using the sequence number vs goal id. If the latter then using action_msgs/GoalStatus here would get that.
|
Besides a couple questions about the implicit fields, I think with a couple unit tests for parsing actions I think this could be merged, and then #310 could be re-targeted at master. |
|
Added tests to Action parser and included some fixes in implicit field collision logic. Note that the Action messages suffixes were changed in |
|
@sloretz @jacobperron I'd say we get this one in to unblock the rest. If the current set of implicit fields is later unfit (which I'm inclined to think but we may find out that it's not), we can change them. |
jacobperron
left a comment
There was a problem hiding this comment.
Sorry for the late review.
I think the current set of implicit fields are okay, although we might consider using types defined in action_msgs so then any changes there are automatically reflected in the generated services/topics. I'm okay with merging this as is pending the one comment regarding the check for implicit field collisions.
| # check for field name collision with action implicit parameters | ||
| # (e.g. 2 or more occurrences of a field_name contained in ACTION_IMPLICIT_FIELDS, | ||
| # including the implicit one) | ||
| if field_name in ACTION_IMPLICIT_FIELDS and action_fields[field_name] >= 1: |
There was a problem hiding this comment.
Does this mean that .msg or .srv specs containing an implicit action field will also raise a collision exception?
If so, maybe it would be better to pass in a list of invalid fields to the function instead of using ACTION_IMPLICIT_FIELDS directly.
There was a problem hiding this comment.
@jacobperron It will trigger only if a field named with the same name as one implicit field is in the spec and there are at least two of them (replacing a ValueType error in this case), to make sure it triggers only when there's duplication, so if you have a field named uuid used in your msg definition it will not trigger. Should I go with the invalid fields route, then?
There was a problem hiding this comment.
Thanks for the clarification. I think it is fine to leave it as-is.
|
|
||
| import pytest | ||
|
|
||
| # from rosidl_parser import InvalidServiceSpecification |
|
@jacobperron @sservulo looks like this one's ready to go! |
|
|
||
|
|
||
| def parse_action_string(pkg_name, action_name, action_string): | ||
| action_blocks = action_string.split(ACTION_REQUEST_RESPONSE_SEPARATOR) |
There was a problem hiding this comment.
This logic is incorrect. It e.g. even matches a --- in a comment. Please use the same logic as for splitting the request and response in a service.
There was a problem hiding this comment.
You're right. I had not considered the possibility of a separator in comments. So it's either above's logic using slices or re.split('^---$', action_string, flags=re.MULTILINE).
There was a problem hiding this comment.
Fixed using re w/ multiline. @dirk-thomas Is this approach OK for you or do you have a strong preference for the slice logic?
This PR closes #305. Added
.actionfile parsing to rosidl_parser.CMake preprocessing of .action files into services and messages is coming to this branch from
sloretz/speficication-to-str.