This is more to plan the path for future stuff than anything else.
I'd need to know what is the place of TypeInfo in the
boost::serialiation system. Is it required for each type used in each
field (or each sequence ...) to be registered ? Is defining only the
boost::serialization overloads enough ?
Sylvain
What is the place of TypeInfo in the whole boost::serialization-
On Tuesday 16 November 2010 17:16:38 Sylvain Joyeux wrote:
> This is more to plan the path for future stuff than anything else.
>
> I'd need to know what is the place of TypeInfo in the
> boost::serialiation system. Is it required for each type used in each
> field (or each sequence ...) to be registered ? Is defining only the
> boost::serialization overloads enough ?
It's actually the other way around. boost::serialization is just a way to
'easily' implement a StructTypeInfo class. I know I have been unclear about
this in the past, but as long as you stay away from StructTypeInfo,
boost::serialization will not bite you.
A TypeInfo pointer of a type T is required whenever we manipulate that type
(non-opaque access) in the component's interface. So if TypeInfo's getMember()
does not expose a field of type T, RTT does not need to know about it.
We're pretty much back to the 1.x way of doing things, allowing much better
support of opaques, but the typegen/scripting user of Orocos won't be happy
with opaque structs, unless there's no other option.
Peter
What is the place of TypeInfo in the whole boost::serialization-
On 11/16/2010 05:44 PM, Peter Soetens wrote:
> On Tuesday 16 November 2010 17:16:38 Sylvain Joyeux wrote:
>> This is more to plan the path for future stuff than anything else.
>>
>> I'd need to know what is the place of TypeInfo in the
>> boost::serialiation system. Is it required for each type used in each
>> field (or each sequence ...) to be registered ? Is defining only the
>> boost::serialization overloads enough ?
>
> It's actually the other way around. boost::serialization is just a way to
> 'easily' implement a StructTypeInfo class. I know I have been unclear about
> this in the past, but as long as you stay away from StructTypeInfo,
> boost::serialization will not bite you.
>
> A TypeInfo pointer of a type T is required whenever we manipulate that type
> (non-opaque access) in the component's interface. So if TypeInfo's getMember()
> does not expose a field of type T, RTT does not need to know about it.
The background is that oroGen now separates types that are registered
(i.e. for which a TypeInfo will exist) and types that are simply part of
another type. The goal being to reduce the amount of compilation and
template instanciation code dramatically. It does not work with
scripting, obviously.
I see two options -- I am only talking about orogen-generated typekits
of course, no modifications to the existing RTT typekit code.
* either we do it the way you proposed at the workshop. It means that
we would have a 'weak' typeinfo and a 'non-weak' typeinfo. Still
quite a bit of compilation will be needed.
* write a typelib-based TypeInfo when generated from oroGen. It would
implement getMember and friends using either Typelib itself, i.e. at
runtime based on the information known at compile time.
I tend towards the second option, as the needed code generation for it
is already there (typelib marshaller), but I think I don't see all the
implications of it. In particular, can you get an element in sequences
by its index ? What about arrays ?
I definitely plan to do this for the mqueue transport however, as it
reduces the amount of caveats dramatically (since oroGen is
typelib-based, the marshalling is completely trivial).
> We're pretty much back to the 1.x way of doing things, allowing much better
> support of opaques, but the typegen/scripting user of Orocos won't be happy
> with opaque structs, unless there's no other option.
What is the place of TypeInfo in the whole boost::serialization-
On Tue, Nov 16, 2010 at 7:03 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 11/16/2010 05:44 PM, Peter Soetens wrote:
>>
>> On Tuesday 16 November 2010 17:16:38 Sylvain Joyeux wrote:
>>>
>>> This is more to plan the path for future stuff than anything else.
>>>
>>> I'd need to know what is the place of TypeInfo in the
>>> boost::serialiation system. Is it required for each type used in each
>>> field (or each sequence ...) to be registered ? Is defining only the
>>> boost::serialization overloads enough ?
>>
>> It's actually the other way around. boost::serialization is just a way to
>> 'easily' implement a StructTypeInfo class. I know I have been unclear
>> about
>> this in the past, but as long as you stay away from StructTypeInfo,
>> boost::serialization will not bite you.
>>
>> A TypeInfo pointer of a type T is required whenever we manipulate that
>> type
>> (non-opaque access) in the component's interface. So if TypeInfo's
>> getMember()
>> does not expose a field of type T, RTT does not need to know about it.
>
> The background is that oroGen now separates types that are registered (i.e.
> for which a TypeInfo will exist) and types that are simply part of another
> type. The goal being to reduce the amount of compilation and template
> instanciation code dramatically. It does not work with scripting, obviously.
Ack.
To precise how RTT works internally: if it gets a pointer to a DataSource,
it will manipulate that datasource through the TypeInfo object associated
with it. By default, every data source returns the 'unknown_'t type info object,
until the proper type info is registered.
>
> I see two options -- I am only talking about orogen-generated typekits of
> course, no modifications to the existing RTT typekit code.
> * either we do it the way you proposed at the workshop. It means that
> we would have a 'weak' typeinfo and a 'non-weak' typeinfo. Still
> quite a bit of compilation will be needed.
I can't say it's ideal, but it would work for me.
> * write a typelib-based TypeInfo when generated from oroGen. It would
> implement getMember and friends using either Typelib itself, i.e. at
> runtime based on the information known at compile time.
I never thought about this. It's inspiring... We could override the default
'unknown_t' object with a typelib implementation of TypeInfo, which
would be the central entry point to type information. There must be some
construction that can work.
>
> I tend towards the second option, as the needed code generation for it is
> already there (typelib marshaller), but I think I don't see all the
> implications of it. In particular, can you get an element in sequences by
> its index ? What about arrays ?
Do you mean if TypeInfo supports this ? The getMember function takes two
datasources as an argument. The first one is the element to inspect.
If the type is a sequence, it will expect the second
datasource to be of type <int>, in order to index into the element.
If the type is a struct, getMember expects a string data source identifying
the name of the member to read.
>
> I definitely plan to do this for the mqueue transport however, as it reduces
> the amount of caveats dramatically (since oroGen is typelib-based, the
> marshalling is completely trivial).
With my understanding of how typelib can do binary-blob marshalling,
that would indeed work too.
You'd still need to inherit from TemplateTypeInfo for the 'top level' type,
such that we can use the type in all places.
I hope it's not a pandora's box we're opening here. As you can expect, my
main concern is that 'getMember' remains available, such that introspection
can happen. I don't really need to 'create a property or port or
transport...' of a member type.
As I have said before on this list, I regret the choices I made during
the typekit
reform with regards to the 'boost serialization' dependency. But from
now on (2.2.0),
the road is clear again for solutions like in the old days.
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
What is the place of TypeInfo in the whole boost::serialization-
On 11/16/2010 10:30 PM, Peter Soetens wrote:
> To precise how RTT works internally: if it gets a pointer to a DataSource,
> it will manipulate that datasource through the TypeInfo object associated
> with it. By default, every data source returns the 'unknown_'t type info object,
> until the proper type info is registered.
So, it means we anyway need a TypeInfo for every field, if scripting is
meant to access these objects.
>> * write a typelib-based TypeInfo when generated from oroGen. It would
>> implement getMember and friends using either Typelib itself, i.e. at
>> runtime based on the information known at compile time.
>
> I never thought about this. It's inspiring... We could override the default
> 'unknown_t' object with a typelib implementation of TypeInfo, which
> would be the central entry point to type information. There must be some
> construction that can work.
Yes, would probably work. TemplateTypeInfo would then only instanciate
the templates.
>>
>> I tend towards the second option, as the needed code generation for it is
>> already there (typelib marshaller), but I think I don't see all the
>> implications of it. In particular, can you get an element in sequences by
>> its index ? What about arrays ?
>
> Do you mean if TypeInfo supports this ? The getMember function takes two
> datasources as an argument. The first one is the element to inspect.
> If the type is a sequence, it will expect the second
> datasource to be of type<int>, in order to index into the element.
> If the type is a struct, getMember expects a string data source identifying
> the name of the member to read.
That's exactly the information I was looking for.
>>
>> I definitely plan to do this for the mqueue transport however, as it reduces
>> the amount of caveats dramatically (since oroGen is typelib-based, the
>> marshalling is completely trivial).
>
> With my understanding of how typelib can do binary-blob marshalling,
> that would indeed work too.
>
> You'd still need to inherit from TemplateTypeInfo for the 'top level' type,
> such that we can use the type in all places.
Ack.
> I hope it's not a pandora's box we're opening here. As you can expect, my
> main concern is that 'getMember' remains available, such that introspection
> can happen. I don't really need to 'create a property or port or
> transport...' of a member type.
Ack. getMember() can very easily be implemented generically using
Typelib. The 'only' general API change would be the ability to get a
void* on the data held by a datasource.
> As I have said before on this list, I regret the choices I made during
> the typekit
> reform with regards to the 'boost serialization' dependency. But from
> now on (2.2.0),
> the road is clear again for solutions like in the old days.
I would not be so harsh about the boost::serialization thing. I
understand that you want to really support all types of workflow, but I
personally believe that tooling does require some tradeoffs. And yes,
that some workflows could be changed for the benefit of the rest of the
system.
The rest of the Ruby toolchain *will* require all toolkits to be
generated by oroGen. Making it otherwise is just impractical.
--
Sylvain Joyeux (Dr. Ing.)
Researcher - Space and Security Robotics
DFKI Robotics Innovation Center
Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
Phone: +49 421 218-64136
Fax: +49 421 218-64150
Email: sylvain [dot] joyeux [..] ...
Weitere Informationen: http://www.dfki.de
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
What is the place of TypeInfo in the whole boost::serialization-
On 11/17/2010 09:49 AM, Sylvain Joyeux wrote:
> On 11/16/2010 10:30 PM, Peter Soetens wrote:
>> To precise how RTT works internally: if it gets a pointer to a
>> DataSource,
>> it will manipulate that datasource through the TypeInfo object associated
>> with it. By default, every data source returns the 'unknown_'t type
>> info object,
>> until the proper type info is registered.
> So, it means we anyway need a TypeInfo for every field, if scripting is
> meant to access these objects.
Correcting myself: for these, the generic typelib-based typeinfo
fallback would work just fine.
--
Sylvain Joyeux (Dr. Ing.)
Researcher - Space and Security Robotics
DFKI Robotics Innovation Center
Bremen, Robert-Hooke-Straße 5, 28359 Bremen, Germany
Phone: +49 421 218-64136
Fax: +49 421 218-64150
Email: sylvain [dot] joyeux [..] ...
Weitere Informationen: http://www.dfki.de
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
What is the place of TypeInfo in the whole boost::serialization-
On 11/16/2010 05:44 PM, Peter Soetens wrote:
> We're pretty much back to the 1.x way of doing things, allowing much better
> support of opaques, but the typegen/scripting user of Orocos won't be happy
> with opaque structs, unless there's no other option.
There's support for opaque types in oroGen, and I think this is the way
to go. I'm writing the related documentation.