Sorry for not posting a proper reply, but I got unsubscribed for a week
or two and did not get the original emails ...
My two cents: Yes, parsing the .msg directly to inject it into typelib
for usage in the toolchain would be a very valid option. However, for
implementation reasons, we would still need to generate binary layouts
for the C++-side of things to give us scripting language bindings. But
there's already code for that in typelib, so it would be doable from the
.msg.
What we would basically need for that is an easy-to-integrate C++ parser
for ROS message structures. A less desirable but workable solution would
be to have a msg-to-XML converter, typelib then parsing the generated XML.
Reply to " ROS messages outside of ROS nodes"
To add: I support peter's point that the most important part of the
integration is not "serialization outside of ROS" support but the
ability to use the msg format.
This is so as in Rock we will never use ROS serialization outside of the
ROS transport. We use each transport's serialization (i.e. CORBA in
CORBA, DDS in DDS, ...).
Reply to " ROS messages outside of ROS nodes"
On Mon, Dec 12, 2011 at 11:35 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> To add: I support peter's point that the most important part of the
> integration is not "serialization outside of ROS" support but the
> ability to use the msg format.
>
> This is so as in Rock we will never use ROS serialization outside of the
> ROS transport. We use each transport's serialization (i.e. CORBA in
> CORBA, DDS in DDS, ...).
I should stop using the term "serialization". I mean "whatever one wants
to generate from .msg files".
The restructuring of code generation has so far involved
- removal of dependence on rospack/rosmake/ROS_PACKAGE_PATH
- create "genmsg" library containing a pure python .msg parser and a little
cmake infrastructure
- create genpy/gencpp/genpybindings that take the output of the genmsg
parser and generate code
The generators are written in python; it would be easy enough to generate
XML. In the short run this will be more straightforward than reviving a
C++ parser. In the long run I can certainly see the argument for having
parsers available in multiple languages.
If you have some examples of the typelib-xml (the subsequently generated
IDL would also be interesting to see) I can throw together a prototype.
-t
Reply to " ROS messages outside of ROS nodes"
On 12/14/2011 08:57 PM, Troy Straszheim wrote:
> The restructuring of code generation has so far involved
>
> - removal of dependence on rospack/rosmake/ROS_PACKAGE_PATH
Finally ...
> - create "genmsg" library containing a pure python .msg parser and a
> little cmake infrastructure
> - create genpy/gencpp/genpybindings that take the output of the genmsg
> parser and generate code
Sounds good. Where is this package ? The github link was only a package
using that stuff ...
> The generators are written in python; it would be easy enough to
> generate XML. In the short run this will be more straightforward than
> reviving a C++ parser.
Why "reviving" ? The C++ parser is gccxml works perfectly fine and is
maintained.
> If you have some examples of the typelib-xml (the subsequently generated
> IDL would also be interesting to see) I can throw together a prototype.
Attached one to this mail. Just generate the XML with the size and
offset attributes set to zero.