Skip to content

Fix problems when parsing a Command Substitution as a parameter value#137

Merged
ivanpauno merged 14 commits intomasterfrom
ivanpauno/fix-parameter-bad-interaction-frontend
Aug 4, 2020
Merged

Fix problems when parsing a Command Substitution as a parameter value#137
ivanpauno merged 14 commits intomasterfrom
ivanpauno/fix-parameter-bad-interaction-frontend

Conversation

@ivanpauno
Copy link
Copy Markdown
Member

Trying to address #136.
Related with #74.

Since #31, substitutions in parameter values are loaded like yaml. This is an issue with the Command substitution, because it is not possible to skip the yaml.load() done by the Node action when parsing the input parameters.

My proposal here is to add a Parameter class, which allows to specify the type of the parameter.
One of the options is to convert the result of the substitution like yaml.

Other things I would like to revisit after this:

  • Add a type attribute in launch frontend parameters, map them to the new API.
  • Maybe stop supporting to pass a dictionary in parameters Node argument. Or maybe, don't allow substitutions in them (How to tic-toc?).
  • Consolidate type_utils here with type_utils used in launch.frontend.
  • Drop support of union of types in launch.frontend.type_utils. Update parsing functions if necessary.
  • Revisit lists in XML frontend. Drop *-sep and support list written like in yaml?

@ivanpauno ivanpauno requested review from hidmic and wjwwood March 24, 2020 21:06
@ivanpauno ivanpauno self-assigned this Mar 24, 2020
Copy link
Copy Markdown
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me, but I just glanced over the description and the new API. Still needs a thorough review from someone else.

@wjwwood
Copy link
Copy Markdown
Member

wjwwood commented Mar 24, 2020

Maybe stop supporting to pass a dictionary in parameters Node argument. Or maybe, don't allow substitutions in them (How to tic-toc?).

My instinct is to leave them, but I don't know for sure.

Copy link
Copy Markdown

@hidmic hidmic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that conceptually this makes sense, though I don't love how nested parameters end up being specified. I left some comments.

@ivanpauno
Copy link
Copy Markdown
Member Author

Rebased with master, I'm working in addressing comments.

@ivanpauno
Copy link
Copy Markdown
Member Author

ivanpauno commented Jul 13, 2020

I've created ros2/launch#438, to consolidate all type_utils in launch repo.
I still have to polish things up, but this is ready for a review again.

@ivanpauno ivanpauno requested a review from hidmic July 13, 2020 13:41
@hidmic
Copy link
Copy Markdown

hidmic commented Jul 30, 2020

I have to review this, and we need to decide what to do with

<!-- TODO(hidmic): revisit after https://github.com/ros2/launch_ros/pull/137 gets merged -->

…r type.

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
@ivanpauno ivanpauno force-pushed the ivanpauno/fix-parameter-bad-interaction-frontend branch from ba69703 to 4fea16f Compare August 3, 2020 17:59
@ivanpauno
Copy link
Copy Markdown
Member Author

I have to review this, and we need to decide what to do with

<!-- TODO(hidmic): revisit after https://github.com/ros2/launch_ros/pull/137 gets merged -->

Those "qoute" can be avoided by explicitly passing the type.

@hidmic
Copy link
Copy Markdown

hidmic commented Aug 3, 2020

Those "qoute" can be avoided by explicitly passing the type.

Yes, that's what I thought. Though I wonder if we should keep that test case to make sure XML special characters work.

<param name="param12" value=""/>
<param name="param12" value="''"/>
<param name="param13" value="$(var my_value)" type="str"/>
<param name="param14" value="'2', '5', '8'" value-sep=", " type="list_of_str"/>
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ivanpauno should it be

Suggested change
<param name="param14" value="'2', '5', '8'" value-sep=", " type="list_of_str"/>
<param name="param14" value="2, 5, 8" value-sep=", " type="list_of_str"/>

instead, to actually make sure YAML rules won't get in the way? Same below.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the expected output is ["'2'", "'5'", "'8'"], this is checking that YAML rules aren't used in the way.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that YAML rules are not used to parse a list, but not checking that YAML rules are not used for each element.

Copy link
Copy Markdown
Member Author

@ivanpauno ivanpauno Aug 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that YAML rules are not used to parse a list, but not checking that YAML rules are not used for each element.

The first element is "'2'". If yaml rules were being used, the output would be '2'. This is checking that the output is "'2'".
If I make the change you ask for, the test won't pass.

Copy link
Copy Markdown

@hidmic hidmic Aug 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I make the change you ask for, the test won't pass.

How so? Assuming both markup snippets and test expectations are adjusted, of course.

I don't mind keeping that expectation as-is. But I'd really like to make sure that:

<param name="test" value="1, 2, 3" value-sep=", " type="list_of_str"/>

effectively yields a list of strings.

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>

Co-authored-by: Michel Hidalgo <michel@ekumenlabs.com>
@ivanpauno
Copy link
Copy Markdown
Member Author

Yes, that's what I thought. Though I wonder if we should keep that test case to make sure XML special characters work.

That's still being tested, I've only deleted the TODOs.

@ivanpauno ivanpauno requested a review from hidmic August 3, 2020 18:50
@ivanpauno
Copy link
Copy Markdown
Member Author

I've to re-release launch to make the Rpr checker happy.

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
@ivanpauno
Copy link
Copy Markdown
Member Author

@ros-pull-request-builder retest this please

1 similar comment
@ivanpauno
Copy link
Copy Markdown
Member Author

@ros-pull-request-builder retest this please

@ivanpauno
Copy link
Copy Markdown
Member Author

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants