enum are unknown_t

Submitted by Polch on Wed, 2010-12-15 16:29

Hello.

It's an open question, i would like your opinion.

In the deployer, at runtime, i have an "unknown_t" warning with my enum properties.

As an enum is an int on most implementation, would it be conceivable to use the int type for enums ? Would it be technically possible ?

Thanks.

Paul.

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 13:00.

Hi,

I made a little attempt to improve the EnumTypeInfo.
When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
'(TheEnum)'. But, rather then seeing what type it is, I guess most
users are interested in what value the TheEnum contains at that
moment. This information he already gave to the EnumTypeInfo by
implementing the to_string map.

Patch in appendix uses this information to try to get the string
equivalent of the Enum Type value and, if not found, converts it to an
int.

For this to work, I made the EnumType inherit from TemplateTypeInfo
with has_ostream = true, which however requires me now to implement
the operator>> function in order to get the code to compile.

- Does this look like a good implementation?
- Can we implement the operator>> function somewhere in RTT using the
to_string map as well?

Steven

2011/1/23 Paul Chavent <paul [dot] chavent [..] ...>:
> Hello Steven.
>
> I haven't tested this because i don't use typegen.
>
> Paul.
>
> Steven Bellens wrote:
>> Paul,
>>
>> 2010/12/15 Peter Soetens <peter [..] ...>:
>>> On Wednesday 15 December 2010 20:49:22 Ruben Smits wrote:
>>>> On Wednesday 15 December 2010 17:29:48 paul [dot] chavent [..] ... wrote:
>>>>> Hello.
>>>>>
>>>>> It's an open question, i would like your opinion.
>>>>>
>>>>> In the deployer, at runtime, i have an "unknown_t" warning with my enum
>>>>> properties.
>>>>>
>>>>> As an enum is an int on most implementation, would it be conceivable to
>>>>> use the int type for enums ? Would it be technically possible ?
>>>> I have noticed the EnumTypeInfo being available in RTT 2.x, I haven't
>>>> looked in it's details but I suppose it can transform your enums to
>>>> strings and vice versa. Maybe some of the core-devs can elaborate on this
>>>> or point us to some usefull documentation?
>>> The only 'documentation' is in the tests directory in enum_type_test.cpp
>>>
>>> The important code snippet is this:
>>>
>>>

>>> typedef enum
>>> {
>>>    A, B, C
>>> } TheEnum;
>>>
>>> struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
>>> {
>>>    EnumStringTypeInfo() :
>>>        EnumTypeInfo<TheEnum> ("TheEnum")
>>>    {
>>>        to_string[A] = "A";
>>>        to_string[B] = "B";
>>>        to_string[C] = "C";
>>>    }
>>> };
>>>

>>>
>>> Where you subclass EnumTypeInfo and write down the to_string mapping in the
>>> constructor. Then add this type with the regular Types()->addType() syntax.
>>>
>>> Compile, import, use[1]
>>
>> Did you manage to get this working?
>> I tried typegen to display an enum type, without success (it just
>> inherits from templateTypeInfo apparently)
>>
>> Steven
>>
>>> Peter
>>>
>>> [1] ,bug report
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>
>

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 13:56.

On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
> Hi,
>
> I made a little attempt to improve the EnumTypeInfo.
> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
> '(TheEnum)'. But, rather then seeing what type it is, I guess most
> users are interested in what value the TheEnum contains at that
> moment. This information he already gave to the EnumTypeInfo by
> implementing the to_string map.
>
> Patch in appendix uses this information to try to get the string
> equivalent of the Enum Type value and, if not found, converts it to an
> int.
>
> For this to work, I made the EnumType inherit from TemplateTypeInfo
> with has_ostream = true, which however requires me now to implement
> the operator>> function in order to get the code to compile.
>
> - Does this look like a good implementation?

It's a good start.

> - Can we implement the operator>> function somewhere in RTT using the
> to_string map as well?

You don't need to. You can keep the template argument to 'false' and only
implement the write() function. The 'false' only says: don't use the default
read/write implementation which uses operator<<. It doesn't mean you can't
implement your own versions of read() and write()

So remove the 'true' argument, and it will work.

On the master branch, there is a new function 'TypeInfo::isStreamable()' which
must also return true for your case, such that the TaskBrowser will try to use
your 'write' function.

Peter

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 13:52.

It's a good start.

> - Can we implement the operator>> function somewhere in RTT using the
> to_string map as well?

So remove the 'true' argument, and it will work.

On the master branch, there is a new function 'TypeInfo::isStreamable()' which
must also return true for your case, such that the TaskBrowser will try to use
your 'write' function.

Peter

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 15:32.

2011/1/31 Peter Soetens <peter [..] ...>:
> On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
>> Hi,
>>
>> I made a little attempt to improve the EnumTypeInfo.
>> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
>> '(TheEnum)'. But, rather then seeing what type it is, I guess most
>> users are interested in what value the TheEnum contains at that
>> moment. This information he already gave to the EnumTypeInfo by
>> implementing the to_string map.
>>
>> Patch in appendix uses this information to try to get the string
>> equivalent of the Enum Type value and, if not found, converts it to an
>> int.
>>
>> For this to work, I made the EnumType inherit from TemplateTypeInfo
>> with has_ostream = true, which however requires me now to implement
>> the operator>> function in order to get the code to compile.
>>
>> - Does this look like a good implementation?
>
> It's a good start.
>
>> - Can we implement the operator>> function somewhere in RTT using the
>> to_string map as well?
>
> You don't need to. You can keep the template argument to 'false' and only
> implement the write() function. The 'false' only says: don't use the default
> read/write implementation which uses operator<<. It doesn't mean you can't
> implement your own versions of read() and write()
>
> So remove the 'true' argument, and it will work.
>
> On the master branch, there is a new function 'TypeInfo::isStreamable()' which
> must also return true for your case, such that the TaskBrowser will try to use
> your 'write' function.

Yes, that works, thanks!

Next question I have: I'm using a struct which contains an enum type.
How do I make sure that the struct decomposes the enum type using the
EnumTypeInfo implementation?

@Paul: if you're interested in the implementation, let me know and
I'll send you the details. I've got the enum types working in both
ways now: with the operator<< functions and with the write() function.
So depends what you like most.

Steven

>
> Peter
>
>
>

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 15:32.

Yes, that works, thanks!

Next question I have: I'm using a struct which contains an enum type.
How do I make sure that the struct decomposes the enum type using the
EnumTypeInfo implementation?

Steven

>
> Peter
>
>
>

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 17:08.

On Monday 31 January 2011 16:30:40 Steven Bellens wrote:
> 2011/1/31 Peter Soetens <peter [..] ...>:
> > On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
> >> Hi,
> >>
> >> I made a little attempt to improve the EnumTypeInfo.
> >> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
> >> '(TheEnum)'. But, rather then seeing what type it is, I guess most
> >> users are interested in what value the TheEnum contains at that
> >> moment. This information he already gave to the EnumTypeInfo by
> >> implementing the to_string map.
> >>
> >> Patch in appendix uses this information to try to get the string
> >> equivalent of the Enum Type value and, if not found, converts it to an
> >> int.
> >>
> >> For this to work, I made the EnumType inherit from TemplateTypeInfo
> >> with has_ostream = true, which however requires me now to implement
> >> the operator>> function in order to get the code to compile.
> >>
> >> - Does this look like a good implementation?
> >
> > It's a good start.
> >
> >> - Can we implement the operator>> function somewhere in RTT using the
> >> to_string map as well?
> >
> > You don't need to. You can keep the template argument to 'false' and only
> > implement the write() function. The 'false' only says: don't use the
> > default read/write implementation which uses operator<<. It doesn't mean
> > you can't implement your own versions of read() and write()
> >
> > So remove the 'true' argument, and it will work.
> >
> > On the master branch, there is a new function 'TypeInfo::isStreamable()'
> > which must also return true for your case, such that the TaskBrowser
> > will try to use your 'write' function.
>
> Yes, that works, thanks!
>
> Next question I have: I'm using a struct which contains an enum type.
> How do I make sure that the struct decomposes the enum type using the
> EnumTypeInfo implementation?

It should happen automatically when you're using StructTypeInfo. When the
EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
of the sofware that it can handle that enum type.

>
> @Paul: if you're interested in the implementation, let me know and
> I'll send you the details. I've got the enum types working in both
> ways now: with the operator<< functions and with the write() function.
> So depends what you like most.

Isn't the write() solution more general ? How can you let the compiler choose
the right operator<< without hand-coding it ?

Peter

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 17:08.

Isn't the write() solution more general ? How can you let the compiler choose
the right operator<< without hand-coding it ?

Peter

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 18:20.

2011/1/31 Peter Soetens <peter [..] ...>:
> On Monday 31 January 2011 16:30:40 Steven Bellens wrote:
>> 2011/1/31 Peter Soetens <peter [..] ...>:
>> > On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
>> >> Hi,
>> >>
>> >> I made a little attempt to improve the EnumTypeInfo.
>> >> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
>> >> '(TheEnum)'. But, rather then seeing what type it is, I guess most
>> >> users are interested in what value the TheEnum contains at that
>> >> moment. This information he already gave to the EnumTypeInfo by
>> >> implementing the to_string map.
>> >>
>> >> Patch in appendix uses this information to try to get the string
>> >> equivalent of the Enum Type value and, if not found, converts it to an
>> >> int.
>> >>
>> >> For this to work, I made the EnumType inherit from TemplateTypeInfo
>> >> with has_ostream = true, which however requires me now to implement
>> >> the operator>> function in order to get the code to compile.
>> >>
>> >> - Does this look like a good implementation?
>> >
>> > It's a good start.
>> >
>> >> - Can we implement the operator>> function somewhere in RTT using the
>> >> to_string map as well?
>> >
>> > You don't need to. You can keep the template argument to 'false' and only
>> > implement the write() function. The 'false' only says: don't use the
>> > default read/write implementation which uses operator<<. It doesn't mean
>> > you can't implement your own versions of read() and write()
>> >
>> > So remove the 'true' argument, and it will work.
>> >
>> > On the master branch, there is a new function 'TypeInfo::isStreamable()'
>> > which must also return true for your case, such that the TaskBrowser
>> > will try to use your 'write' function.
>>
>> Yes, that works, thanks!
>>
>> Next question I have: I'm using a struct which contains an enum type.
>> How do I make sure that the struct decomposes the enum type using the
>> EnumTypeInfo implementation?
>
> It should happen automatically when you're using StructTypeInfo. When the
> EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
> of the sofware that it can handle that enum type.

Then how exactly should I implement the boost serialize function for
that struct?

>
>>
>> @Paul: if you're interested in the implementation, let me know and
>> I'll send you the details. I've got the enum types working in both
>> ways now: with the operator<< functions and with the write() function.
>> So depends what you like most.
>
> Isn't the write() solution more general ? How can you let the compiler choose
> the right operator<< without hand-coding it ?

Yes it is .. I can't.

Steven

>
> Peter
>

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 18:20.

Then how exactly should I implement the boost serialize function for
that struct?

Yes it is .. I can't.

Steven

>
> Peter
>

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 18:48.

2011/1/31 Steven Bellens <steven [dot] bellens [..] ...>:
> 2011/1/31 Peter Soetens <peter [..] ...>:
>> On Monday 31 January 2011 16:30:40 Steven Bellens wrote:
>>> 2011/1/31 Peter Soetens <peter [..] ...>:
>>> > On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
>>> >> Hi,
>>> >>
>>> >> I made a little attempt to improve the EnumTypeInfo.
>>> >> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
>>> >> '(TheEnum)'. But, rather then seeing what type it is, I guess most
>>> >> users are interested in what value the TheEnum contains at that
>>> >> moment. This information he already gave to the EnumTypeInfo by
>>> >> implementing the to_string map.
>>> >>
>>> >> Patch in appendix uses this information to try to get the string
>>> >> equivalent of the Enum Type value and, if not found, converts it to an
>>> >> int.
>>> >>
>>> >> For this to work, I made the EnumType inherit from TemplateTypeInfo
>>> >> with has_ostream = true, which however requires me now to implement
>>> >> the operator>> function in order to get the code to compile.
>>> >>
>>> >> - Does this look like a good implementation?
>>> >
>>> > It's a good start.
>>> >
>>> >> - Can we implement the operator>> function somewhere in RTT using the
>>> >> to_string map as well?
>>> >
>>> > You don't need to. You can keep the template argument to 'false' and only
>>> > implement the write() function. The 'false' only says: don't use the
>>> > default read/write implementation which uses operator<<. It doesn't mean
>>> > you can't implement your own versions of read() and write()
>>> >
>>> > So remove the 'true' argument, and it will work.
>>> >
>>> > On the master branch, there is a new function 'TypeInfo::isStreamable()'
>>> > which must also return true for your case, such that the TaskBrowser
>>> > will try to use your 'write' function.
>>>
>>> Yes, that works, thanks!
>>>
>>> Next question I have: I'm using a struct which contains an enum type.
>>> How do I make sure that the struct decomposes the enum type using the
>>> EnumTypeInfo implementation?
>>
>> It should happen automatically when you're using StructTypeInfo. When the
>> EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
>> of the sofware that it can handle that enum type.
>
> Then how exactly should I implement the boost serialize function for
> that struct?

Yes, working. Turned out to be an OCL problem on the master branch.
The serialize function has no problem dealing with the enum type.

FYI: on the OCL master branch, the included header in
ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.

Steven

>
>>
>>>
>>> @Paul: if you're interested in the implementation, let me know and
>>> I'll send you the details. I've got the enum types working in both
>>> ways now: with the operator<< functions and with the write() function.
>>> So depends what you like most.
>>
>> Isn't the write() solution more general ? How can you let the compiler choose
>> the right operator<< without hand-coding it ?
>
> Yes it is .. I can't.
>
> Steven
>
>>
>> Peter
>>
>

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 18:48.

Yes, working. Turned out to be an OCL problem on the master branch.
The serialize function has no problem dealing with the enum type.

FYI: on the OCL master branch, the included header in
ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.

Steven

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 21:44.

On Monday 31 January 2011 19:44:40 Steven Bellens wrote:
> 2011/1/31 Steven Bellens <steven [dot] bellens [..] ...>:
> > 2011/1/31 Peter Soetens <peter [..] ...>:
> >> On Monday 31 January 2011 16:30:40 Steven Bellens wrote:
> >>> 2011/1/31 Peter Soetens <peter [..] ...>:
> >>> > On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
> >>> >> Hi,
> >>> >>
> >>> >> I made a little attempt to improve the EnumTypeInfo.
> >>> >> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it
> >>> >> as '(TheEnum)'. But, rather then seeing what type it is, I guess
> >>> >> most users are interested in what value the TheEnum contains at
> >>> >> that moment. This information he already gave to the EnumTypeInfo
> >>> >> by implementing the to_string map.
> >>> >>
> >>> >> Patch in appendix uses this information to try to get the string
> >>> >> equivalent of the Enum Type value and, if not found, converts it to
> >>> >> an int.
> >>> >>
> >>> >> For this to work, I made the EnumType inherit from TemplateTypeInfo
> >>> >> with has_ostream = true, which however requires me now to implement
> >>> >> the operator>> function in order to get the code to compile.
> >>> >>
> >>> >> - Does this look like a good implementation?
> >>> >
> >>> > It's a good start.
> >>> >
> >>> >> - Can we implement the operator>> function somewhere in RTT using
> >>> >> the to_string map as well?
> >>> >
> >>> > You don't need to. You can keep the template argument to 'false' and
> >>> > only implement the write() function. The 'false' only says: don't
> >>> > use the default read/write implementation which uses operator<<. It
> >>> > doesn't mean you can't implement your own versions of read() and
> >>> > write()
> >>> >
> >>> > So remove the 'true' argument, and it will work.
> >>> >
> >>> > On the master branch, there is a new function
> >>> > 'TypeInfo::isStreamable()' which must also return true for your
> >>> > case, such that the TaskBrowser will try to use your 'write'
> >>> > function.
> >>>
> >>> Yes, that works, thanks!
> >>>
> >>> Next question I have: I'm using a struct which contains an enum type.
> >>> How do I make sure that the struct decomposes the enum type using the
> >>> EnumTypeInfo implementation?
> >>
> >> It should happen automatically when you're using StructTypeInfo. When
> >> the EnumTypeInfo is loaded, it sets a global pointer to itself to
> >> inform the rest of the sofware that it can handle that enum type.
> >
> > Then how exactly should I implement the boost serialize function for
> > that struct?
>
> Yes, working. Turned out to be an OCL problem on the master branch.
> The serialize function has no problem dealing with the enum type.
>
> FYI: on the OCL master branch, the included header in
> ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.

There are two answers to this problem: 1. update both your ocl and rtt master
branches to get the latest fixes. 2. remove (gradually) all occurences of this
statement in your cmake files: "rosbuild_find_ros_package( ocl )" and put ocl as
dependency in your manifest.xml file. The useorocos macros will do the 'find'
for you, based on the manifest file.

If fixed the macros such that such a rosbuild_ clash is no longer disruptive.
Note that master has these new UseOrocos.cmake macros, it's tested to some
extent, but it needs more of that :-).

As a side note, you can also remove ocl from your manifest if you only used
the ocl/Component.hpp header. You can now include rtt/Component.hpp instead
and drop one dependency.

Peter

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 21:44.

when building a component.

If fixed the macros such that such a rosbuild_ clash is no longer disruptive.
Note that master has these new UseOrocos.cmake macros, it's tested to some
extent, but it needs more of that :-).

As a side note, you can also remove ocl from your manifest if you only used
the ocl/Component.hpp header. You can now include rtt/Component.hpp instead
and drop one dependency.

Peter

enum are unknown_t

Submitted by snrkiwi on Mon, 2011-01-31 18:56.

On Jan 31, 2011, at 13:44 , Steven Bellens wrote:

> 2011/1/31 Steven Bellens <steven [dot] bellens [..] ...>:
>> 2011/1/31 Peter Soetens <peter [..] ...>:
>>> On Monday 31 January 2011 16:30:40 Steven Bellens wrote:
>>>> 2011/1/31 Peter Soetens <peter [..] ...>:
>>>>> On Monday 31 January 2011 13:58:26 Steven Bellens wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I made a little attempt to improve the EnumTypeInfo.
>>>>>> When I have an enum type, e.g. TheEnum, the TaskBrowser displays it as
>>>>>> '(TheEnum)'. But, rather then seeing what type it is, I guess most
>>>>>> users are interested in what value the TheEnum contains at that
>>>>>> moment. This information he already gave to the EnumTypeInfo by
>>>>>> implementing the to_string map.
>>>>>>
>>>>>> Patch in appendix uses this information to try to get the string
>>>>>> equivalent of the Enum Type value and, if not found, converts it to an
>>>>>> int.
>>>>>>
>>>>>> For this to work, I made the EnumType inherit from TemplateTypeInfo
>>>>>> with has_ostream = true, which however requires me now to implement
>>>>>> the operator>> function in order to get the code to compile.
>>>>>>
>>>>>> - Does this look like a good implementation?
>>>>>
>>>>> It's a good start.
>>>>>
>>>>>> - Can we implement the operator>> function somewhere in RTT using the
>>>>>> to_string map as well?
>>>>>
>>>>> You don't need to. You can keep the template argument to 'false' and only
>>>>> implement the write() function. The 'false' only says: don't use the
>>>>> default read/write implementation which uses operator<<. It doesn't mean
>>>>> you can't implement your own versions of read() and write()
>>>>>
>>>>> So remove the 'true' argument, and it will work.
>>>>>
>>>>> On the master branch, there is a new function 'TypeInfo::isStreamable()'
>>>>> which must also return true for your case, such that the TaskBrowser
>>>>> will try to use your 'write' function.
>>>>
>>>> Yes, that works, thanks!
>>>>
>>>> Next question I have: I'm using a struct which contains an enum type.
>>>> How do I make sure that the struct decomposes the enum type using the
>>>> EnumTypeInfo implementation?
>>>
>>> It should happen automatically when you're using StructTypeInfo. When the
>>> EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
>>> of the sofware that it can handle that enum type.
>>
>> Then how exactly should I implement the boost serialize function for
>> that struct?
>
> Yes, working. Turned out to be an OCL problem on the master branch.
> The serialize function has no problem dealing with the enum type.
>
> FYI: on the OCL master branch, the included header in
> ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.

What platform was this? Does this occur when building OCL, or when building a user component? The automated builds should catch this, either way. We might just have to setup something extra to catch an error at the user level.
S

enum are unknown_t

Submitted by snrkiwi on Mon, 2011-01-31 18:56.

On Jan 31, 2011, at 13:44 , Steven Bellens wrote:

when building a component.

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 20:12.

[...]
>>>>>
>>>>> Next question I have: I'm using a struct which contains an enum type.
>>>>> How do I make sure that the struct decomposes the enum type using the
>>>>> EnumTypeInfo implementation?
>>>>
>>>> It should happen automatically when you're using StructTypeInfo. When the
>>>> EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
>>>> of the sofware that it can handle that enum type.
>>>
>>> Then how exactly should I implement the boost serialize function for
>>> that struct?
>>
>> Yes, working. Turned out to be an OCL problem on the master branch.
>> The serialize function has no problem dealing with the enum type.
>>
>> FYI: on the OCL master branch, the included header in
>> ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.
>
> What platform was this? Does this occur when building OCL, or when building a user component? The automated builds should catch this, either way. We might just have to setup something extra to catch an error at the user level.

Ubuntu 10.10 64-bit platform. RTT - OCL master branch both compile
fine. Problem occurred when building a user component (generated with
oro-create pkg script from the toolchain 2.2 branch). I adjusted the
include header in my component from <ocl/Component.hp

to
<orocos/ocl/Component.hp

and then the error popped up:

[100%] Building CXX object
CMakeFiles/krypton_component.dir/src/krypton_component.cpp.o
In file included from
/home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/krypton_hardware/krypton_component/src/krypton_component.hpp:46,
from
/home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/krypton_hardware/krypton_component/src/krypton_component.cpp:38:
/home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/orocos_toolchain_ros/ocl/install/include/orocos/ocl/Component.hpp:42:
fatal error: ocl/OCL.hpp: No such file or directory
compilation terminated.

regards,

Steven

> S
>
>

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 20:12.

to
<orocos/ocl/Component.hp

and then the error popped up:

regards,

Steven

> S
>
>

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 20:52.

On Monday 31 January 2011 21:10:23 Steven Bellens wrote:
> [...]
>
> >>>>> Next question I have: I'm using a struct which contains an enum type.
> >>>>> How do I make sure that the struct decomposes the enum type using the
> >>>>> EnumTypeInfo implementation?
> >>>>
> >>>> It should happen automatically when you're using StructTypeInfo. When
> >>>> the EnumTypeInfo is loaded, it sets a global pointer to itself to
> >>>> inform the rest of the sofware that it can handle that enum type.
> >>>
> >>> Then how exactly should I implement the boost serialize function for
> >>> that struct?
> >>
> >> Yes, working. Turned out to be an OCL problem on the master branch.
> >> The serialize function has no problem dealing with the enum type.
> >>
> >> FYI: on the OCL master branch, the included header in
> >> ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.
> >
> > What platform was this? Does this occur when building OCL, or when
> > building a user component? The automated builds should catch this,
> > either way. We might just have to setup something extra to catch an
> > error at the user level.
>
> Ubuntu 10.10 64-bit platform. RTT - OCL master branch both compile
> fine. Problem occurred when building a user component (generated with
> oro-create pkg script from the toolchain 2.2 branch). I adjusted the
> include header in my component from <ocl/Component.hp

to
> <orocos/ocl/Component.hp

and then the error popped up:

This is not a correct fix. You/Somebody/Something needs to add
-Ioclprefix/include/orocos to the compiler flags instead of renaming all your
include directives.

I have reproduced your issue here I'll take a look at the proper fix. Probably,
ocl's .pc file (which contains this -I directive) is not taken into account for
some reason.

Peter

enum are unknown_t

Submitted by peter on Mon, 2011-01-31 20:52.

to
> <orocos/ocl/Component.hp

and then the error popped up:

This is not a correct fix. You/Somebody/Something needs to add
-Ioclprefix/include/orocos to the compiler flags instead of renaming all your
include directives.

I have reproduced your issue here I'll take a look at the proper fix. Probably,
ocl's .pc file (which contains this -I directive) is not taken into account for
some reason.

Peter

enum are unknown_t

Submitted by snrkiwi on Mon, 2011-01-31 20:16.

On Jan 31, 2011, at 15:10 , Steven Bellens wrote:

> [...]
>>>>>>
>>>>>> Next question I have: I'm using a struct which contains an enum type.
>>>>>> How do I make sure that the struct decomposes the enum type using the
>>>>>> EnumTypeInfo implementation?
>>>>>
>>>>> It should happen automatically when you're using StructTypeInfo. When the
>>>>> EnumTypeInfo is loaded, it sets a global pointer to itself to inform the rest
>>>>> of the sofware that it can handle that enum type.
>>>>
>>>> Then how exactly should I implement the boost serialize function for
>>>> that struct?
>>>
>>> Yes, working. Turned out to be an OCL problem on the master branch.
>>> The serialize function has no problem dealing with the enum type.
>>>
>>> FYI: on the OCL master branch, the included header in
>>> ocl/Component.hpp fails: <ocl/OCL.hp

when building a component.
>>
>> What platform was this? Does this occur when building OCL, or when building a user component? The automated builds should catch this, either way. We might just have to setup something extra to catch an error at the user level.
>
> Ubuntu 10.10 64-bit platform. RTT - OCL master branch both compile
> fine. Problem occurred when building a user component (generated with
> oro-create pkg script from the toolchain 2.2 branch). I adjusted the
> include header in my component from <ocl/Component.hp

to
> <orocos/ocl/Component.hp

and then the error popped up:
>
> [100%] Building CXX object
> CMakeFiles/krypton_component.dir/src/krypton_component.cpp.o
> In file included from
> /home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/krypton_hardware/krypton_component/src/krypton_component.hpp:46,
> from
> /home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/krypton_hardware/krypton_component/src/krypton_component.cpp:38:
> /home/steven/src/svn/stacks/kul-ros-pkg-git/stacks/orocos_toolchain_ros/ocl/install/include/orocos/ocl/Component.hpp:42:
> fatal error: ocl/OCL.hpp: No such file or directory
> compilation terminated.
>
> regards,
>
> Steven

Looking at the automated build system, are any of the ROS-related jobs doing userspace builds? Or are they just building/packaging Orocos itself? If those jobs are not user applications, then we would need user application type jobs to catch errors like this in the future.
S

enum are unknown_t

Submitted by snrkiwi on Mon, 2011-01-31 20:16.

On Jan 31, 2011, at 15:10 , Steven Bellens wrote:

to
> <orocos/ocl/Component.hp

enum are unknown_t

Submitted by Steven Bellens on Mon, 2011-01-31 13:00.

Hi,

Patch in appendix uses this information to try to get the string
equivalent of the Enum Type value and, if not found, converts it to an
int.

For this to work, I made the EnumType inherit from TemplateTypeInfo
with has_ostream = true, which however requires me now to implement
the operator>> function in order to get the code to compile.

- Does this look like a good implementation?
- Can we implement the operator>> function somewhere in RTT using the
to_string map as well?

Steven

>>> typedef enum
>>> {
>>>    A, B, C
>>> } TheEnum;
>>>
>>> struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
>>> {
>>>    EnumStringTypeInfo() :
>>>        EnumTypeInfo<TheEnum> ("TheEnum")
>>>    {
>>>        to_string[A] = "A";
>>>        to_string[B] = "B";
>>>        to_string[C] = "C";
>>>    }
>>> };
>>>

enum are unknown_t

Submitted by Ruben Smits on Wed, 2010-12-15 19:56.

On Wednesday 15 December 2010 17:29:48 paul [dot] chavent [..] ... wrote:
> Hello.
>
> It's an open question, i would like your opinion.
>
> In the deployer, at runtime, i have an "unknown_t" warning with my enum
> properties.
>
> As an enum is an int on most implementation, would it be conceivable to use
> the int type for enums ? Would it be technically possible ?

I have noticed the EnumTypeInfo being available in RTT 2.x, I haven't looked
in it's details but I suppose it can transform your enums to strings and vice
versa. Maybe some of the core-devs can elaborate on this or point us to some
usefull documentation?

Ruben

enum are unknown_t

Submitted by Polch on Wed, 2010-12-15 21:04.

Hello.

I didn't see this class. But i expected that the registration could be done automatically as for basic types (bool, int, double). But i'am not sure it can be done like this.

Ruben Smits wrote:
> On Wednesday 15 December 2010 17:29:48 paul [dot] chavent [..] ... wrote:
>> Hello.
>>
>> It's an open question, i would like your opinion.
>>
>> In the deployer, at runtime, i have an "unknown_t" warning with my enum
>> properties.
>>
>> As an enum is an int on most implementation, would it be conceivable to use
>> the int type for enums ? Would it be technically possible ?
>
> I have noticed the EnumTypeInfo being available in RTT 2.x, I haven't looked
> in it's details but I suppose it can transform your enums to strings and vice
> versa. Maybe some of the core-devs can elaborate on this or point us to some
> usefull documentation?
>
> Ruben
>
>

enum are unknown_t

Submitted by peter on Wed, 2010-12-15 20:48.

On Wednesday 15 December 2010 20:49:22 Ruben Smits wrote:
> On Wednesday 15 December 2010 17:29:48 paul [dot] chavent [..] ... wrote:
> > Hello.
> >
> > It's an open question, i would like your opinion.
> >
> > In the deployer, at runtime, i have an "unknown_t" warning with my enum
> > properties.
> >
> > As an enum is an int on most implementation, would it be conceivable to
> > use the int type for enums ? Would it be technically possible ?
>
> I have noticed the EnumTypeInfo being available in RTT 2.x, I haven't
> looked in it's details but I suppose it can transform your enums to
> strings and vice versa. Maybe some of the core-devs can elaborate on this
> or point us to some usefull documentation?

The only 'documentation' is in the tests directory in enum_type_test.cpp

The important code snippet is this:

typedef enum
{
    A, B, C
} TheEnum;
 
struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
{
    EnumStringTypeInfo() :
        EnumTypeInfo<TheEnum> ("TheEnum")
    {
        to_string[A] = "A";
        to_string[B] = "B";
        to_string[C] = "C";
    }
};

Where you subclass EnumTypeInfo and write down the to_string mapping in the
constructor. Then add this type with the regular Types()->addType() syntax.

Compile, import, use[1]

Peter

[1] ,bug report

enum are unknown_t

Submitted by Steven Bellens on Sun, 2011-01-23 11:00.

Paul,

2010/12/15 Peter Soetens <peter [..] ...>:
> On Wednesday 15 December 2010 20:49:22 Ruben Smits wrote:
>> On Wednesday 15 December 2010 17:29:48 paul [dot] chavent [..] ... wrote:
>> > Hello.
>> >
>> > It's an open question, i would like your opinion.
>> >
>> > In the deployer, at runtime, i have an "unknown_t" warning with my enum
>> > properties.
>> >
>> > As an enum is an int on most implementation, would it be conceivable to
>> > use the int type for enums ? Would it be technically possible ?
>>
>> I have noticed the EnumTypeInfo being available in RTT 2.x, I haven't
>> looked in it's details but I suppose it can transform your enums to
>> strings and vice versa. Maybe some of the core-devs can elaborate on this
>> or point us to some usefull documentation?
>
> The only 'documentation' is in the tests directory in enum_type_test.cpp
>
> The important code snippet is this:
>
>

> typedef enum
> {
>    A, B, C
> } TheEnum;
>
> struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
> {
>    EnumStringTypeInfo() :
>        EnumTypeInfo<TheEnum> ("TheEnum")
>    {
>        to_string[A] = "A";
>        to_string[B] = "B";
>        to_string[C] = "C";
>    }
> };
>

>
> Where you subclass EnumTypeInfo and write down the to_string mapping in the
> constructor. Then add this type with the regular Types()->addType() syntax.
>
> Compile, import, use[1]

Did you manage to get this working?
I tried typegen to display an enum type, without success (it just
inherits from templateTypeInfo apparently)

Steven

>
> Peter
>
> [1] ,bug report
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

enum are unknown_t

Submitted by peter on Thu, 2010-12-16 08:08.

On Thursday 16 December 2010 07:00:38 Paul Chavent wrote:
> Ok.
>
> But i wondered if it was possible to have a default behavior that consider
> enum as int.

But for the C++ compiler, it isn't. So there's no way to code for that, except
to generate code for that ala orogen.

>
> So the transport could work by default and the deployer could not complain
> without adding code.

We might at least think of a 'generic' enum transport for CORBA such that they
are passed as int-in-Any over the wire.

>
> So we could need to code EnumStringTypeInfo only if we want the conversion
> to string...

It also takes care of int <->enum conversions. But I believe this is limited
to xml/scripting and not used by the transports (it's only a typekit, not a
transport). Since typekits are transport-independent, it's not possible to add
a default corba transport for the enum type.

There must be some easy 'one line' solution. Did you consider using typegen ?

Peter

enum are unknown_t

Submitted by Polch on Wed, 2010-12-15 16:36.

Hello.

It's an open question, i would like your opinion.

In the deployer, at runtime, i have an "unknown_t" warning with my enum properties.

As an enum is an int on most implementation, would it be conceivable to use the int type for enums ? Would it be technically possible ?

Thanks.

Paul.