Re-added compose/decompose API on master branch

I have re-added the compose/decompose API to the Typekit classes, keeping it
100% compatible with RTT 1.x. Concretely, this means that you implement
composeTypeImpl() and decomposeTypeImpl() by just copy-pasting these functions
from your RTT 1.x toolkit. The semantics have broadend slightly to also allow
non-propertybag conversions, but in that case, you need to override
composeType()/decomposeType() (rare use case). You can use this method for
TemplateTypeInfo, StructTypeInfo, SequenceTypeInfo etc.

I have updated the docs (rtt/doc/xml/orocos-typekit-plugin.xml) to explain
when you need to implement these functions and when not.

For (automated) testing purposes, you can just check that:


typeinfo->composeType( typeinfo->decomposeType( input ), output)
assert( input->get() == output->get() )


where input and output are data sources of same type as 'typeinfo'. Since the
RTT itself does not have such a type, we need some testing/feedback from real
typekits.

This change is supposed to be backwards compatible with 2.0/2.1 typekits as
well (so you're not forced to upgrade to these functions in case you found
another way by now).

I apologize for the pain every 2.x typekit writer has suffered because of the
removal of these two functions. I hope future migrations will be less painful.

Peter

Re-added compose/decompose

Thank you Peter for this patch.

I have just tested it with my typekit, and it seems to work.

I have tried the test you suggest, i have put traces in my methods, and everything seems ok.

Thank you again !

Paul.

Re-added compose/decompose API on master branch

On Tue, Nov 9, 2010 at 14:45, Peter Soetens <peter [..] ...> wrote:
> I have re-added the compose/decompose API to the Typekit classes, keeping it
> 100% compatible with RTT 1.x. Concretely, this means that you implement
> composeTypeImpl() and decomposeTypeImpl() by just copy-pasting these functions
> from your RTT 1.x toolkit. The semantics have broadend slightly to also allow
> non-propertybag conversions, but in that case, you need to override
> composeType()/decomposeType() (rare use case). You can use this method for
> TemplateTypeInfo, StructTypeInfo, SequenceTypeInfo etc.
>

Thanks.

> I have updated the docs (rtt/doc/xml/orocos-typekit-plugin.xml) to explain
> when you need to implement these functions and when not.

It seems that the online documentation (for the moment) has not
changed yet (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.1...).
Did I overlook it or am I looking at the wrong location? Can you check this?

>
> For (automated) testing purposes, you can just check that:
>
> &#10;&gt; typeinfo-&gt;composeType( typeinfo-&gt;decomposeType( input ), output)&#10;&gt; assert( input-&gt;get() == output-&gt;get() )&#10;&gt;
>
> where input and output are data sources of same type as 'typeinfo'. Since the
> RTT itself does not have such a type, we need some testing/feedback from real
> typekits.

Can I offer help to make a test for the BFL typekit?
In fact I already have a basic component testing all my types.

>
> This change is supposed to be backwards compatible with 2.0/2.1 typekits as
> well (so you're not forced to upgrade to these functions in case you found
> another way by now).

This is also good news.

>
> I apologize for the pain every 2.x typekit writer has suffered because of the
> removal of these two functions. I hope future migrations will be less painful.

Me too ;). Thanks for helping us during this (painful) process!

Tinne

Re-added compose/decompose API on master branch

On Tue, Nov 9, 2010 at 14:45, Peter Soetens <peter [..] ...> wrote:
> I have re-added the compose/decompose API to the Typekit classes, keeping it
> 100% compatible with RTT 1.x. Concretely, this means that you implement
> composeTypeImpl() and decomposeTypeImpl() by just copy-pasting these functions
> from your RTT 1.x toolkit. The semantics have broadend slightly to also allow
> non-propertybag conversions, but in that case, you need to override
> composeType()/decomposeType() (rare use case). You can use this method for
> TemplateTypeInfo, StructTypeInfo, SequenceTypeInfo etc.
>

Thanks.

> I have updated the docs (rtt/doc/xml/orocos-typekit-plugin.xml) to explain
> when you need to implement these functions and when not.

It seems that the online documentation (for the moment) has not
changed yet (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.1...).
Did I overlook it or am I looking at the wrong location? Can you check this?

>
> For (automated) testing purposes, you can just check that:
>
> &#10;&gt; typeinfo-&gt;composeType( typeinfo-&gt;decomposeType( input ), output)&#10;&gt; assert( input-&gt;get() == output-&gt;get() )&#10;&gt;
>
> where input and output are data sources of same type as 'typeinfo'. Since the
> RTT itself does not have such a type, we need some testing/feedback from real
> typekits.

Can I offer help to make a test for the BFL typekit?
In fact I already have a basic component testing all my types.

>
> This change is supposed to be backwards compatible with 2.0/2.1 typekits as
> well (so you're not forced to upgrade to these functions in case you found
> another way by now).

This is also good news.

>
> I apologize for the pain every 2.x typekit writer has suffered because of the
> removal of these two functions. I hope future migrations will be less painful.

Me too ;). Thanks for helping us during this (painful) process!

Tinne

Re-added compose/decompose API on master branch

On Tuesday 09 November 2010 15:26:51 Tinne De Laet wrote:
> On Tue, Nov 9, 2010 at 14:45, Peter Soetens <peter [..] ...>
wrote:
> > I have re-added the compose/decompose API to the Typekit classes, keeping
> > it 100% compatible with RTT 1.x. Concretely, this means that you
> > implement composeTypeImpl() and decomposeTypeImpl() by just copy-pasting
> > these functions from your RTT 1.x toolkit. The semantics have broadend
> > slightly to also allow non-propertybag conversions, but in that case,
> > you need to override composeType()/decomposeType() (rare use case). You
> > can use this method for TemplateTypeInfo, StructTypeInfo,
> > SequenceTypeInfo etc.
>
> Thanks.
>
> > I have updated the docs (rtt/doc/xml/orocos-typekit-plugin.xml) to
> > explain when you need to implement these functions and when not.
>
> It seems that the online documentation (for the moment) has not
> changed yet
> (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.1.
> x/doc-xml/orocos-typekit-plugin.html). Did I overlook it or am I looking at
> the wrong location? Can you check this?

You're now supposed to read the xml doc itself. This will only be part of
v2.2, which has no docs online yet.

>
> > For (automated) testing purposes, you can just check that:
> >
> > &#10;&gt; &gt; typeinfo-&gt;composeType( typeinfo-&gt;decomposeType( input ), output)&#10;&gt; &gt; assert( input-&gt;get() == output-&gt;get() )&#10;&gt; &gt;
> >
> > where input and output are data sources of same type as 'typeinfo'. Since
> > the RTT itself does not have such a type, we need some testing/feedback
> > from real typekits.
>
> Can I offer help to make a test for the BFL typekit?
> In fact I already have a basic component testing all my types.

Just testing if I didn't break anything anyway would already be nice :-)

Peter

Re-added compose/decompose API on master branch

On Tuesday 09 November 2010 15:26:51 Tinne De Laet wrote:
> On Tue, Nov 9, 2010 at 14:45, Peter Soetens <peter [..] ...>
wrote:
> > I have re-added the compose/decompose API to the Typekit classes, keeping
> > it 100% compatible with RTT 1.x. Concretely, this means that you
> > implement composeTypeImpl() and decomposeTypeImpl() by just copy-pasting
> > these functions from your RTT 1.x toolkit. The semantics have broadend
> > slightly to also allow non-propertybag conversions, but in that case,
> > you need to override composeType()/decomposeType() (rare use case). You
> > can use this method for TemplateTypeInfo, StructTypeInfo,
> > SequenceTypeInfo etc.
>
> Thanks.
>
> > I have updated the docs (rtt/doc/xml/orocos-typekit-plugin.xml) to
> > explain when you need to implement these functions and when not.
>
> It seems that the online documentation (for the moment) has not
> changed yet
> (http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v2.1.
> x/doc-xml/orocos-typekit-plugin.html). Did I overlook it or am I looking at
> the wrong location? Can you check this?

You're now supposed to read the xml doc itself. This will only be part of
v2.2, which has no docs online yet.

>
> > For (automated) testing purposes, you can just check that:
> >
> > &#10;&gt; &gt; typeinfo-&gt;composeType( typeinfo-&gt;decomposeType( input ), output)&#10;&gt; &gt; assert( input-&gt;get() == output-&gt;get() )&#10;&gt; &gt;
> >
> > where input and output are data sources of same type as 'typeinfo'. Since
> > the RTT itself does not have such a type, we need some testing/feedback
> > from real typekits.
>
> Can I offer help to make a test for the BFL typekit?
> In fact I already have a basic component testing all my types.

Just testing if I didn't break anything anyway would already be nice :-)

Peter