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:
>
>
>
> 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:
>
>
>
> 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:
> >
> >
> >
> > 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:
> >
> >
> >
> > 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