On Wed, Nov 2, 2011 at 10:38 AM, Thibault Kruse <kruset@in.tum.de> wrote:
> On 11/02/2011 05:28 PM, Ken Conley wrote:
>>
>> I'm definitely for such a feature, though, like Felix, I'm not sure
>> they belong with rosmsg/rossrv as there is a bit of a abstraction loss
>> there; either that, or rosmsg/srv need a first-class notion of the
>> YAML form of messages.  Right now the YAML form is implicit and the
>> code APIs are generally marked for internal use only.
>
> I am dispassionate about where the code goes. It is 2 python functions
> we talk about, with dependencies to roslib, and only trivial dependencies to
> small rosmsg functions.

So, looking at the code, it looks like get_yaml_for_msg is a better
version of roslib.message.strify_message (though not sure how to
handle the None representer issue, either), though the
get_msgspec_prototype() method (AFAIK) isn't necessary -- if you just
instantiate an example message, you can use that instead with this
minor patch in object_representer():

            if not k.startswith('_') and k in obj.__slots__:

I haven't run it through the unit tests yet, but my quick experiments
worked. There is a question I have, which is whether or not arrays of
messages should be populated with a default instance to make them
easier to use (those are the hardest case, IMHO, to type).  This may
or may not be related to your comment re: Quaternions and Headers.
For Quaternion and Headers, I'll note that we learned the hard way
that making the core libraries have specific knowledge of messages
creates annoying future problems, no matter how well intentioned, so
perhaps a plugin system is in order, as well as possible changes to
the generated messages themselves.

The intent with Fuerte is to make roslib go away, so there's an
opportunity to create a simple Python library to incorporate these
message manipulation routines.  This has already been done with the
genmsg code, so the next level would be roslib.message-related stuff.
Some union of roslib.messages, rosmsgproto, and rosh bagys seems like
a good strawman.


> I put the patch to rosmsg only because of the seeming similarity to rosmsg
> show, thinking if there were such a function, that's where I'd look for it,
> and
> initially hoping there'd be enough support for it there.
>
> I split the functions out into a separate python file, and attached it to
> the ticket.
>>
>> Also, personally I use the multi-line input for command-line args,
>> which greatly simplifies the YAML, and perhaps the 'prototype' feature
>> could educate users about that as well.
>
> I had some problems with the YAML multiline initially. But using your trick
> I
> found that the cause was me adding \ symbols at then end of lines
> unnecessarily.
> So my patch is quickly transformed to offer both multiline and flow syntax.
>
> example:
> $ python rosmsgproto.py msg tf/tfMessage
> "transforms:
> - child_frame_id: ''
>  header:
>    frame_id: ''
>    seq: 0
>    stamp:
>      nsecs: 0
>      secs: 0
>  transform:
>    rotation:
>      w: 0.0
>      x: 0.0
>      y: 0.0
>      z: 0.0
>    translation:
>      x: 0.0
>      y: 0.0
>      z: 0.0"
>
>>   Basically, you can use the
>> 'rostopic echo' output form as a prototype of a 'rostopic pub'
>
> Sounds like hen and egg.

Don't worry, I wasn't suggesting it as equivalent to rosmsg proto,
just indicating it as a way for those who aren't familiar with
multiline as to what it looks like, as the wiki seems to be lacking in
examples.

 - Ken



>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>