Closed traversaro closed 2 years ago
This was detected in https://github.com/robotology/robotology-superbuild/pull/971 .
On which branch should I commit the fix? is master ok?
On which branch should I commit the fix? is master ok?
I guess we need to ask to @pattacini .
On which branch should I commit the fix? is master ok?
Hi @randaz81, first of all, thanks šš»
The fix should land as a PR against master
.
However, it's not clear to me how the fix would look like. Will it allow us to keep the function names equal to blink
, blink_fast
, and blink_naturalistic
? If so, that would be great.
Otherwise, I would do that rather myself as changing the function names would entail verifying the interactions with the possible callers.
No, unfortunately, the function names cannot be maintened.
I was going to fix it by renaming blink
to blink_single
.
Another possibility (equally ok, or even better) is to rename blink_fast
to blinkFast
avoiding the use of the underscore that has a special meaning. In general, I'd recommend always avoiding the use of the underscores.
Please note that the YARP_COMPILER_ERROR
was added intentionally to show a compiler error instead of getting a runtime bug (which unfortunately cannot be fixed)
Ok, nope then. I'll do the job. Thanks anyway.
Another possibility (equally ok, or even better) is to rename blink_fast to blinkFast avoiding the use of the underscore that has a special meaning. In general, I'd recommend always avoiding the use of the underscores.
Gotcha!
Question.
I was going to fix it by renaming blink to blink_single.
Is this sufficient?
According to (from https://github.com/robotology/yarp/pull/2780):
WARNING: This makes it impossible to have a service function that starts with the same name as a different function.
So we should interpret that:
blink
+ blink_fast
is āblink_single
+ blink_fast
is āļøcorrect?
yes, correct.
The file to edit is iCubBlinker.thrift
I'd suggest in this case to go for a minimal change (blink_single
).
In the future, I recommend going for camel case and avoiding the separator _ which generates a completely different* (bugged) parser. It is not just aesthetics!
*: based on yarp::os::vocabs instead of std::string
In the future, I recommend going for camel case and avoiding the separator _ which generates a completely different* (bugged) parser. It is not just aesthetics!
*: based on yarp::os::vocabs instead of std::string
If not already mentioned somewhere in the documentation, it'd be great doing so.
Since https://github.com/robotology/yarp/pull/2780 has been merged,
funny-things
is failing with this error:fyi @randaz81 @S-Dafarra @pattacini @Nicogene @drdanz