The discussions starts with explaining the improved TypeInfo infrastructure:

• Normally , everything should be generated by the tools
• If the tools don't make it, you can generate a typekit manually by:
  • Add a StructTypeInfo<T> instead of TemplateTypeInfo<T> (the latter still exists)
  • Define a boost::serialization function the decomposes your struct

ROS messages and orogen

• Can orogen parse a generated ros message class ?
  • It can't since it does not work when a class has virtual functions. Also the ANTLR parser is not 'good enough'.
  • gccxml tool can help here, it also removes ANTLR then.

Sylvain explains how orogen works

• List dependencies
• Declare used types (header files to use)
• Declare task definitions
• Declare deployments

Sylvain shows how orogen requires the #ifndef __orogen in the headers listed. gccxml is a fix for this too.

Hosting on gitorious is being discussed. It allows us to group code in 'projects' and collaborate better using git.

Autoproj is discussed as a tool to bootstrap the orocos packages. It's an alternative to manually download and build everything. It may work in parallel with rosbuild, in case application software depends on both ros and orocos. This needs to be tested.

The work is divided for the rest of the day:

• Charles + Peter : Yarp transport for 2.0
• Markus + Peter : Find collect segfault bug
• Stephen + Sylvain: Mac OS-X testing of autoproj/ruby etc.
• Sylvain + Peter + Markus : gccxml into orogen

We decided to rename orogen to typegen

The day concluded with investigating the code size/compile time issue. The culprits are the operations added to the ports in the typekit code. We investigated several solutions to tackle this, especially in the light of code/typekit generation.