Conversation
wjwwood
left a comment
There was a problem hiding this comment.
Seems reasonable to me, but I just glanced over the description and the new API. Still needs a thorough review from someone else.
My instinct is to leave them, but I don't know for sure. |
hidmic
left a comment
There was a problem hiding this comment.
I think that conceptually this makes sense, though I don't love how nested parameters end up being specified. I left some comments.
test_launch_ros/test/test_launch_ros/utilities/test_type_utils.py
Outdated
Show resolved
Hide resolved
a4e1e54 to
b2fd4d8
Compare
|
Rebased with master, I'm working in addressing comments. |
|
I've created ros2/launch#438, to consolidate all |
|
I have to review this, and we need to decide what to do with |
…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>
ba69703 to
4fea16f
Compare
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"/> |
There was a problem hiding this comment.
@ivanpauno should it be
| <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.
There was a problem hiding this comment.
the expected output is ["'2'", "'5'", "'8'"], this is checking that YAML rules aren't used in the way.
There was a problem hiding this comment.
Checking that YAML rules are not used to parse a list, but not checking that YAML rules are not used for each element.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>
That's still being tested, I've only deleted the TODOs. |
|
I've to re-release launch to make the Rpr checker happy. |
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
|
@ros-pull-request-builder retest this please |
1 similar comment
|
@ros-pull-request-builder retest this please |
…alue (#137) Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
…alue (#137) Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Trying to address #136.
Related with #74.
Since #31, substitutions in parameter values are loaded like
yaml. This is an issue with theCommandsubstitution, because it is not possible to skip theyaml.load()done by theNodeaction when parsing the input parameters.My proposal here is to add a
Parameterclass, 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:
parametersNode argument. Or maybe, don't allow substitutions in them (How to tic-toc?).type_utilshere withtype_utilsused inlaunch.frontend.launch.frontend.type_utils. Update parsing functions if necessary.*-sepand support list written like inyaml?