OCL::FileReporter enums

Hello,

In master branch, OCL::FileReporter is not reporting the values of enums
in the data structs that are exchanged over the dataports. For example,
a snippet of a line from the FileReporter output is

---

10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
(/scoop/informationElement/t_messagePriority) 7 0
(/scoop/informationElement/t_nodeType) 10 10

---

In the above (/scoop/informationElement/t_messageType) is an enum [in
this particular case, I happen to know that its value is 2 and this is
read properly by the component receiving the struct ]. Similarly, the
other () in the log above are enums.

How to get enums reported properly in the logs?

Thanks in advance,
Sagar

OCL::FileReporter enums

On Fri, Oct 12, 2012 at 9:21 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> Hello,
>
> In master branch, OCL::FileReporter is not reporting the values of enums
> in the data structs that are exchanged over the dataports. For example,
> a snippet of a line from the FileReporter output is
>
> ---
>
> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
> (/scoop/informationElement/t_messagePriority) 7 0
> (/scoop/informationElement/t_nodeType) 10 10
>
> ---
>
> In the above (/scoop/informationElement/t_messageType) is an enum [in
> this particular case, I happen to know that its value is 2 and this is
> read properly by the component receiving the struct ]. Similarly, the
> other () in the log above are enums.
>
> How to get enums reported properly in the logs?

In a hand-written typekit, you'd use EnumTypeInfo which would convert your
enum to an int when reporting looks at your type. It looks like typegen is
not using EnumTypeInfo.

Well, now it gets interesting for using the master branch. This can be added
later-on, by writing a tiny typekit which adds this functionality to the enum's
typekit. Try in some arbitrary location (like a constructor) to write this:

#include <rtt/types/EnumTypeInfo.hpp>
#include <rtt/types/Types.hpp>

RTT::types::Types()->addTypeInfo( new
RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );

You could formalize this later on in a hand written typekit or plugin.

Peter

OCL::FileReporter enums

On 10/12/2012 10:41 PM, Peter Soetens wrote:
> On Fri, Oct 12, 2012 at 9:21 PM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>> Hello,
>>
>> In master branch, OCL::FileReporter is not reporting the values of enums
>> in the data structs that are exchanged over the dataports. For example,
>> a snippet of a line from the FileReporter output is
>>
>> ---
>>
>> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
>> (/scoop/informationElement/t_messagePriority) 7 0
>> (/scoop/informationElement/t_nodeType) 10 10
>>
>> ---
>>
>> In the above (/scoop/informationElement/t_messageType) is an enum [in
>> this particular case, I happen to know that its value is 2 and this is
>> read properly by the component receiving the struct ]. Similarly, the
>> other () in the log above are enums.
>>
>> How to get enums reported properly in the logs?
>
> In a hand-written typekit, you'd use EnumTypeInfo which would convert your
> enum to an int when reporting looks at your type. It looks like typegen is
> not using EnumTypeInfo.
>
> Well, now it gets interesting for using the master branch. This can be added
> later-on, by writing a tiny typekit which adds this functionality to the enum's
> typekit. Try in some arbitrary location (like a constructor) to write this:
>
> #include<rtt/types/EnumTypeInfo.hpp>
> #include<rtt/types/Types.hpp>
>
> RTT::types::Types()->addTypeInfo( new
> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );

I assume you meant RTT::types::Types()->addType() ? The compiler
complained that classs TypeInfoRepository didn't have addTypeInfo().

So I included the headers and added the following line to one of the
TaskContext's constructors

RTT::types::Types()->addType( new
RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
);

This resulted in the FileReporter log file containing something like

---
10.7818 (t_messageType) 13 1350078190 44
(/scoop/informationElement/t_messagePriority) 7 0
(/scoop/informationElement/t_nodeType) 10 10
---

So the only thing that changed in the log is that the enum value is
(t_messageType) instead of the earlier
(/scoop/informationElement/t_messageType).

Does something more need to be done in order to get a numerical value?

/Sagar

> You could formalize this later on in a hand written typekit or plugin.
>
> Peter

OCL::FileReporter enums

On 10/12/2012 11:58 PM, Sagar Behere wrote:
> On 10/12/2012 10:41 PM, Peter Soetens wrote:
>> On Fri, Oct 12, 2012 at 9:21 PM, Sagar Behere<sagar [dot] behere [..] ...>
>> wrote:
>>> Hello,
>>>
>>> In master branch, OCL::FileReporter is not reporting the values of enums
>>> in the data structs that are exchanged over the dataports. For example,
>>> a snippet of a line from the FileReporter output is
>>>
>>> ---
>>>
>>> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
>>> (/scoop/informationElement/t_messagePriority) 7 0
>>> (/scoop/informationElement/t_nodeType) 10 10
>>>
>>> ---
>>>
>>> In the above (/scoop/informationElement/t_messageType) is an enum [in
>>> this particular case, I happen to know that its value is 2 and this is
>>> read properly by the component receiving the struct ]. Similarly, the
>>> other () in the log above are enums.
>>>
>>> How to get enums reported properly in the logs?
>>
>> In a hand-written typekit, you'd use EnumTypeInfo which would convert
>> your
>> enum to an int when reporting looks at your type. It looks like
>> typegen is
>> not using EnumTypeInfo.
>>
>> Well, now it gets interesting for using the master branch. This can be
>> added
>> later-on, by writing a tiny typekit which adds this functionality to
>> the enum's
>> typekit. Try in some arbitrary location (like a constructor) to write
>> this:
>>
>> #include<rtt/types/EnumTypeInfo.hpp>
>> #include<rtt/types/Types.hpp>
>>
>> RTT::types::Types()->addTypeInfo( new
>> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
>
> I assume you meant RTT::types::Types()->addType() ? The compiler
> complained that classs TypeInfoRepository didn't have addTypeInfo().
>
> So I included the headers and added the following line to one of the
> TaskContext's constructors
>
> RTT::types::Types()->addType( new
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
> );

I added the above line of code to the constructor of the component that
is sending the structs which contain the enums. When running the system,
it gives messages like
----
11.280 [ Warning][Logger] No enum-to-string mapping defined for enum
t_messageType. Converting to int.
----

but the log file still contains lines like

9.83815 (/scoop/informationElement/t_messageType) 131 1350508651 648
(/scoop/informationElement/t_messagePriority) 131 0
(/scoop/informationElement/t_nodeType) 131 131

which is the same as before. The enum values are still not being
reported properly. The warning message seems to originate from the
decomposeType() function in

http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...

but I'm unable to debug further :(

/Sagar

>
> Does something more need to be done in order to get a numerical value?
>
> /Sagar
>
>> You could formalize this later on in a hand written typekit or plugin.
>>
>> Peter
>

OCL::FileReporter enums

2012/10/17 Sagar Behere <sagar [dot] behere [..] ...>

> On 10/12/2012 11:58 PM, Sagar Behere wrote:
> > On 10/12/2012 10:41 PM, Peter Soetens wrote:
> >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar Behere<sagar [dot] behere [..] ...>
> >> wrote:
> >>> Hello,
> >>>
> >>> In master branch, OCL::FileReporter is not reporting the values of
> enums
> >>> in the data structs that are exchanged over the dataports. For example,
> >>> a snippet of a line from the FileReporter output is
> >>>
> >>> ---
> >>>
> >>> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
> >>> (/scoop/informationElement/t_messagePriority) 7 0
> >>> (/scoop/informationElement/t_nodeType) 10 10
> >>>
> >>> ---
> >>>
> >>> In the above (/scoop/informationElement/t_messageType) is an enum [in
> >>> this particular case, I happen to know that its value is 2 and this is
> >>> read properly by the component receiving the struct ]. Similarly, the
> >>> other () in the log above are enums.
> >>>
> >>> How to get enums reported properly in the logs?
> >>
> >> In a hand-written typekit, you'd use EnumTypeInfo which would convert
> >> your
> >> enum to an int when reporting looks at your type. It looks like
> >> typegen is
> >> not using EnumTypeInfo.
> >>
> >> Well, now it gets interesting for using the master branch. This can be
> >> added
> >> later-on, by writing a tiny typekit which adds this functionality to
> >> the enum's
> >> typekit. Try in some arbitrary location (like a constructor) to write
> >> this:
> >>
> >> #include<rtt/types/EnumTypeInfo.hpp>
> >> #include<rtt/types/Types.hpp>
> >>
> >> RTT::types::Types()->addTypeInfo( new
> >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
> >
> > I assume you meant RTT::types::Types()->addType() ? The compiler
> > complained that classs TypeInfoRepository didn't have addTypeInfo().
> >
> > So I included the headers and added the following line to one of the
> > TaskContext's constructors
> >
> > RTT::types::Types()->addType( new
> >
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
> > );
>
> I added the above line of code to the constructor of the component that
> is sending the structs which contain the enums. When running the system,
> it gives messages like
> ----
> 11.280 [ Warning][Logger] No enum-to-string mapping defined for enum
> t_messageType. Converting to int.
> ----
>

You have to define the enum/string mapping in your type info constructor:

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";
}
};

I am afraid this is not documented...

Charles.

>
> but the log file still contains lines like
>
> 9.83815 (/scoop/informationElement/t_messageType) 131 1350508651 648
> (/scoop/informationElement/t_messagePriority) 131 0
> (/scoop/informationElement/t_nodeType) 131 131
>
>
> which is the same as before. The enum values are still not being
> reported properly. The warning message seems to originate from the
> decomposeType() function in
>
>
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
>
> but I'm unable to debug further :(
>
> /Sagar
>
> >
> > Does something more need to be done in order to get a numerical value?
> >
> > /Sagar
> >
> >> You could formalize this later on in a hand written typekit or plugin.
> >>
> >> Peter
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

OCL::FileReporter enums

On 10/18/2012 08:36 AM, Charles Lesire-Cabaniols wrote:
>
>
> 2012/10/17 Sagar Behere <sagar [dot] behere [..] ...
> <mailto:sagar [dot] behere [..] ...>>
>
> On 10/12/2012 11:58 PM, Sagar Behere wrote:
> > On 10/12/2012 10:41 PM, Peter Soetens wrote:
> >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar
> Behere<sagar [dot] behere [..] ... <mailto:sagar [dot] behere [..] ...>>
> >> wrote:
> >>> Hello,
> >>>
> >>> In master branch, OCL::FileReporter is not reporting the values
> of enums
> >>> in the data structs that are exchanged over the dataports. For
> example,
> >>> a snippet of a line from the FileReporter output is
> >>>
> >>> ---
> >>>
> >>> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404 765
> >>> (/scoop/informationElement/t_messagePriority) 7 0
> >>> (/scoop/informationElement/t_nodeType) 10 10
> >>>
> >>> ---
> >>>
> >>> In the above (/scoop/informationElement/t_messageType) is an
> enum [in
> >>> this particular case, I happen to know that its value is 2 and
> this is
> >>> read properly by the component receiving the struct ].
> Similarly, the
> >>> other () in the log above are enums.
> >>>
> >>> How to get enums reported properly in the logs?
> >>
> >> In a hand-written typekit, you'd use EnumTypeInfo which would
> convert
> >> your
> >> enum to an int when reporting looks at your type. It looks like
> >> typegen is
> >> not using EnumTypeInfo.
> >>
> >> Well, now it gets interesting for using the master branch. This
> can be
> >> added
> >> later-on, by writing a tiny typekit which adds this functionality to
> >> the enum's
> >> typekit. Try in some arbitrary location (like a constructor) to
> write
> >> this:
> >>
> >> #include<rtt/types/EnumTypeInfo.hpp>
> >> #include<rtt/types/Types.hpp>
> >>
> >> RTT::types::Types()->addTypeInfo( new
> >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
> >
> > I assume you meant RTT::types::Types()->addType() ? The compiler
> > complained that classs TypeInfoRepository didn't have addTypeInfo().
> >
> > So I included the headers and added the following line to one of the
> > TaskContext's constructors
> >
> > RTT::types::Types()->addType( new
> >
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
> > );
>
> I added the above line of code to the constructor of the component that
> is sending the structs which contain the enums. When running the system,
> it gives messages like
> ----
> 11.280 [ Warning][Logger] No enum-to-string mapping defined for enum
> t_messageType. Converting to int.
> ----
>
>
> You have to define the enum/string mapping in your type info constructor:
>
> 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";
> }
> };

Doing the above removes the warning message, but does not result in the
mapped string appearing in the log file. In fact, there is no change in
the log file contents.

Specifically, the actual test code I created is

-----
namespace scoop {
namespace wireless {

struct EnumStringTypeInfo: public
RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>
{

EnumStringTypeInfo():EnumTypeInfo<scoop::informationElement::t_messageType>("nameOft_messageType")
{

to_string[scoop::informationElement::reserved_messageType] = "0
reserved_messageType";
//
to_string[scoop::informationElement::dynamicVehicleInfo] = "1
dynamicVehicleInfo";

this->to_string[scoop::informationElement::staticVehicleInfo] = "2
staticVehicleInfo";
}
};

and in the constructor of the TaskContext, I added

RTT::types::Types()->addType( new EnumStringTypeInfo );
------

So when the enum value is "scoop::informationElement::staticVehicleInfo"
I expect to see the mapped string "2 staticVehicleInfo" in the log. This
does not happen. The log file still shows the enum value as
"(/scoop/informationElement/t_messageType)"

So I commented out the to_string[] line for
"scoop::informationElement::staticVehicleInfo" in the EnumStringTypeInfo
constructor just to see if it would have any effect. Doing so causes the
warning to re-appear.

In summary, registering the EnumStringTypeInfo makes the warning
disappear. However, the contents of the log file do not show the enum value.

Regards,
Sagar

> I am afraid this is not documented...
>
> Charles.
>
>
> but the log file still contains lines like
>
> 9.83815 (/scoop/informationElement/t_messageType) 131 1350508651 648
> (/scoop/informationElement/t_messagePriority) 131 0
> (/scoop/informationElement/t_nodeType) 131 131
>
>
> which is the same as before. The enum values are still not being
> reported properly. The warning message seems to originate from the
> decomposeType() function in
>
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
>
> but I'm unable to debug further :(
>
> /Sagar
>
> >
> > Does something more need to be done in order to get a numerical
> value?
> >
> > /Sagar
> >
> >> You could formalize this later on in a hand written typekit or
> plugin.
> >>
> >> Peter
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> <mailto:Orocos-Users [..] ...>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

OCL::FileReporter enums

Hi Sagar,

I need to look into the decomposition code and the reporters code. We'll
get this fixed, the error is not on your side.

Peter

Op donderdag 18 oktober 2012 schreef Sagar Behere (sagar [dot] behere [..] ...)
het volgende:

> On 10/18/2012 08:36 AM, Charles Lesire-Cabaniols wrote:
> >
> >
> > 2012/10/17 Sagar Behere <sagar [dot] behere [..] ... <javascript:;>
> > <mailto:sagar [dot] behere [..] ... <javascript:;>>>
> >
> > On 10/12/2012 11:58 PM, Sagar Behere wrote:
> > > On 10/12/2012 10:41 PM, Peter Soetens wrote:
> > >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar
> > Behere<sagar [dot] behere [..] ... <javascript:;> <mailto:
> sagar [dot] behere [..] ... <javascript:;>>>
> > >> wrote:
> > >>> Hello,
> > >>>
> > >>> In master branch, OCL::FileReporter is not reporting the values
> > of enums
> > >>> in the data structs that are exchanged over the dataports. For
> > example,
> > >>> a snippet of a line from the FileReporter output is
> > >>>
> > >>> ---
> > >>>
> > >>> 10.9116 (/scoop/informationElement/t_messageType) 14 1350069404
> 765
> > >>> (/scoop/informationElement/t_messagePriority) 7 0
> > >>> (/scoop/informationElement/t_nodeType) 10 10
> > >>>
> > >>> ---
> > >>>
> > >>> In the above (/scoop/informationElement/t_messageType) is an
> > enum [in
> > >>> this particular case, I happen to know that its value is 2 and
> > this is
> > >>> read properly by the component receiving the struct ].
> > Similarly, the
> > >>> other () in the log above are enums.
> > >>>
> > >>> How to get enums reported properly in the logs?
> > >>
> > >> In a hand-written typekit, you'd use EnumTypeInfo which would
> > convert
> > >> your
> > >> enum to an int when reporting looks at your type. It looks like
> > >> typegen is
> > >> not using EnumTypeInfo.
> > >>
> > >> Well, now it gets interesting for using the master branch. This
> > can be
> > >> added
> > >> later-on, by writing a tiny typekit which adds this
> functionality to
> > >> the enum's
> > >> typekit. Try in some arbitrary location (like a constructor) to
> > write
> > >> this:
> > >>
> > >> #include<rtt/types/EnumTypeInfo.hpp>
> > >> #include<rtt/types/Types.hpp>
> > >>
> > >> RTT::types::Types()->addTypeInfo( new
> > >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
> > >
> > > I assume you meant RTT::types::Types()->addType() ? The compiler
> > > complained that classs TypeInfoRepository didn't have
> addTypeInfo().
> > >
> > > So I included the headers and added the following line to one of
> the
> > > TaskContext's constructors
> > >
> > > RTT::types::Types()->addType( new
> > >
> >
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
> > > );
> >
> > I added the above line of code to the constructor of the component
> that
> > is sending the structs which contain the enums. When running the
> system,
> > it gives messages like
> > ----
> > 11.280 [ Warning][Logger] No enum-to-string mapping defined for enum
> > t_messageType. Converting to int.
> > ----
> >
> >
> > You have to define the enum/string mapping in your type info constructor:
> >
> > typedef enum
> > {
> > A, B, C
> > } TheEnum;
> >
> > struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
> > {
> > EnumStringTypeInfo() :
> > EnumTypeInfo<TheEnum> ("TheEnum")
> > {
> > to_string[A] = "A";
> > to_string[B] = "B";
> > Doing the above removes the warning message, but does not result
> in the
> mapped string appearing in the log file. In fact, there is no change in
> the log file contents.
>
> Specifically, the actual test code I created is
>
> -----
> namespace scoop {
> namespace wireless {
>
> struct EnumStringTypeInfo: public
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>
> {
>
>
> EnumStringTypeInfo():EnumTypeInfo<scoop::informationElement::t_messageType>("nameOft_messageType")
> {
>
> to_string[scoop::informationElement::reserved_messageType] = "0
> reserved_messageType";
> //
> to_string[scoop::informationElement::dynamicVehicleInfo] = "1
> dynamicVehicleInfo";
>
> this->to_string[scoop::informationElement::staticVehicleInfo] = "2
> staticVehicleInfo";
> }
> };
>
> and in the constructor of the TaskContext, I added
>
> RTT::types::Types()->addType( new EnumStringTypeInfo );
> ------
>
> So when the enum value is "scoop::informationElement::staticVehicleInfo"
> I expect to see the mapped string "2 staticVehicleInfo" in the log. This
> does not happen. The log file still shows the enum value as
> "(/scoop/informationElement/t_messageType)"
>
> So I commented out the to_string[] line for
> "scoop::informationElement::staticVehicleInfo" in the EnumStringTypeInfo
> constructor just to see if it would have any effect. Doing so causes the
> warning to re-appear.
>
> In summary, registering the EnumStringTypeInfo makes the warning
> disappear. However, the contents of the log file do not show the enum
> value.
>
> Regards,
> Sagar
>
> > I am afraid this is not documented...
> >
> > Charles.
> >
> >
> > but the log file still contains lines like
> >
> > 9.83815 (/scoop/informationElement/t_messageType) 131 1350508651
> 648
> > (/scoop/informationElement/t_messagePriority) 131 0
> > (/scoop/informationElement/t_nodeType) 131 131
> >
> >
> > which is the same as before. The enum values are still not being
> > reported properly. The warning message seems to originate from the
> > decomposeType() function in
> >
> >
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
> >
> > but I'm unable to debug further :(
> >
> > /Sagar
> >
> > >
> > > Does something more need to be done in order to get a numerical
> > value?
> > >
> > > /Sagar
> > >
> > >> You could formalize this later on in a hand written typekit or
> > plugin.
> > >>
> > >> Peter
> > >
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ... <javascript:;>
> > <mailto:Orocos-Users [..] ... <javascript:;>>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ... <javascript:;>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

OCL::FileReporter enums

On 10/18/2012 12:41 PM, Peter Soetens wrote:
> Hi Sagar,
>
> I need to look into the decomposition code and the reporters code. We'll
> get this fixed, the error is not on your side.

Maybe this will help.

--------

In PropertyDecomposition.cpp, in the typeDecomposition()

if (decomposed) {
...
if (bag){...}
else {

This is where it ends up for enums.

dsb->getTypeName() is /scoop/informationElement/t_messageType
dsb->toString() is (/scoop/informationElement/t_messageType)

decomposed->getTypeName() is either an int or string
(depending on whether Charles' advice is followed)
decomposed->toString() contains exactly what we need
(when Charles' advice is followed; haven't tested without)
But nothing is done with decomposed and its content.
Instead it just returns false.

}

--------

It seems that the output of EnumTypeInfo's decomposeType() therefore
never reaches anywhere?

[ Or I could be entirely wrong. Going through the orocos internals feels
a bit like swimming in very thick liquid. Progress is slow, then you get
tired and sink ;) ]

Cheers,
Sagar

> Op donderdag 18 oktober 2012 schreef Sagar Behere
> (sagar [dot] behere [..] ... <mailto:sagar [dot] behere [..] ...>) het volgende:
>
> On 10/18/2012 08:36 AM, Charles Lesire-Cabaniols wrote:
> >
> >
> > 2012/10/17 Sagar Behere <sagar [dot] behere [..] ... <javascript:;>
> > <mailto:sagar [dot] behere [..] ... <javascript:;>>>
> >
> > On 10/12/2012 11:58 PM, Sagar Behere wrote:
> > > On 10/12/2012 10:41 PM, Peter Soetens wrote:
> > >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar
> > Behere<sagar [dot] behere [..] ... <javascript:;>
> <mailto:sagar [dot] behere [..] ... <javascript:;>>>
> > >> wrote:
> > >>> Hello,
> > >>>
> > >>> In master branch, OCL::FileReporter is not reporting the values
> > of enums
> > >>> in the data structs that are exchanged over the dataports. For
> > example,
> > >>> a snippet of a line from the FileReporter output is
> > >>>
> > >>> ---
> > >>>
> > >>> 10.9116 (/scoop/informationElement/t_messageType) 14
> 1350069404 765
> > >>> (/scoop/informationElement/t_messagePriority) 7 0
> > >>> (/scoop/informationElement/t_nodeType) 10 10
> > >>>
> > >>> ---
> > >>>
> > >>> In the above (/scoop/informationElement/t_messageType) is an
> > enum [in
> > >>> this particular case, I happen to know that its value is 2 and
> > this is
> > >>> read properly by the component receiving the struct ].
> > Similarly, the
> > >>> other () in the log above are enums.
> > >>>
> > >>> How to get enums reported properly in the logs?
> > >>
> > >> In a hand-written typekit, you'd use EnumTypeInfo which would
> > convert
> > >> your
> > >> enum to an int when reporting looks at your type. It looks like
> > >> typegen is
> > >> not using EnumTypeInfo.
> > >>
> > >> Well, now it gets interesting for using the master branch. This
> > can be
> > >> added
> > >> later-on, by writing a tiny typekit which adds this
> functionality to
> > >> the enum's
> > >> typekit. Try in some arbitrary location (like a constructor) to
> > write
> > >> this:
> > >>
> > >> #include<rtt/types/EnumTypeInfo.hpp>
> > >> #include<rtt/types/Types.hpp>
> > >>
> > >> RTT::types::Types()->addTypeInfo( new
> > >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
> > >
> > > I assume you meant RTT::types::Types()->addType() ? The compiler
> > > complained that classs TypeInfoRepository didn't have
> addTypeInfo().
> > >
> > > So I included the headers and added the following line to one
> of the
> > > TaskContext's constructors
> > >
> > > RTT::types::Types()->addType( new
> > >
> >
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
> > > );
> >
> > I added the above line of code to the constructor of the
> component that
> > is sending the structs which contain the enums. When running
> the system,
> > it gives messages like
> > ----
> > 11.280 [ Warning][Logger] No enum-to-string mapping defined
> for enum
> > t_messageType. Converting to int.
> > ----
> >
> >
> > You have to define the enum/string mapping in your type info
> constructor:
> >
> > typedef enum
> > {
> > A, B, C
> > } TheEnum;
> >
> > struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
> > {
> > EnumStringTypeInfo() :
> > EnumTypeInfo<TheEnum> ("TheEnum")
> > {
> > to_string[A] = "A";
> > to_string[B] = "B";
> > Doing the above removes the warning message, but does not
> result in the
> mapped string appearing in the log file. In fact, there is no change in
> the log file contents.
>
> Specifically, the actual test code I created is
>
> -----
> namespace scoop {
> namespace wireless {
>
> struct EnumStringTypeInfo: public
> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>
> {
>
> EnumStringTypeInfo():EnumTypeInfo<scoop::informationElement::t_messageType>("nameOft_messageType")
> {
>
> to_string[scoop::informationElement::reserved_messageType] = "0
> reserved_messageType";
> //
> to_string[scoop::informationElement::dynamicVehicleInfo] = "1
> dynamicVehicleInfo";
>
> this->to_string[scoop::informationElement::staticVehicleInfo] = "2
> staticVehicleInfo";
> }
> };
>
> and in the constructor of the TaskContext, I added
>
> RTT::types::Types()->addType( new EnumStringTypeInfo );
> ------
>
> So when the enum value is "scoop::informationElement::staticVehicleInfo"
> I expect to see the mapped string "2 staticVehicleInfo" in the log. This
> does not happen. The log file still shows the enum value as
> "(/scoop/informationElement/t_messageType)"
>
> So I commented out the to_string[] line for
> "scoop::informationElement::staticVehicleInfo" in the EnumStringTypeInfo
> constructor just to see if it would have any effect. Doing so causes the
> warning to re-appear.
>
> In summary, registering the EnumStringTypeInfo makes the warning
> disappear. However, the contents of the log file do not show the
> enum value.
>
> Regards,
> Sagar
>
> > I am afraid this is not documented...
> >
> > Charles.
> >
> >
> > but the log file still contains lines like
> >
> > 9.83815 (/scoop/informationElement/t_messageType) 131
> 1350508651 648
> > (/scoop/informationElement/t_messagePriority) 131 0
> > (/scoop/informationElement/t_nodeType) 131 131
> >
> >
> > which is the same as before. The enum values are still not being
> > reported properly. The warning message seems to originate
> from the
> > decomposeType() function in
> >
> >
> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
> >
> > but I'm unable to debug further :(
> >
> > /Sagar
> >
> > >
> > > Does something more need to be done in order to get a numerical
> > value?
> > >
> > > /Sagar
> > >
> > >> You could formalize this later on in a hand written typekit or
> > plugin.
> > >>
> > >> Peter
> > >
> >
> > --
> > Orocos-Users mailing list
> > Orocos-Users [..] ... <javascript:;>
> > <mailto:Orocos-Users [..] ... <javascript:;>>
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
> >
> >
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ... <javascript:;>
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

OCL::FileReporter enums

Hi Sagar,

Probably, the patch in attachment for RTT will fix this. I added code
which was present in the ReportingComponent, but not in the RTT,
causing decomposed structs not to be able to decompose enums.

Peter

On Sat, Oct 20, 2012 at 2:45 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> On 10/18/2012 12:41 PM, Peter Soetens wrote:
>>
>> Hi Sagar,
>>
>> I need to look into the decomposition code and the reporters code. We'll
>> get this fixed, the error is not on your side.
>
>
> Maybe this will help.
>
> --------
>
> In PropertyDecomposition.cpp, in the typeDecomposition()
>
> if (decomposed) {
> ...
> if (bag){...}
> else {
>
> This is where it ends up for enums.
>
> dsb->getTypeName() is /scoop/informationElement/t_messageType
> dsb->toString() is (/scoop/informationElement/t_messageType)
>
> decomposed->getTypeName() is either an int or string
> (depending on whether Charles' advice is followed)
> decomposed->toString() contains exactly what we need
> (when Charles' advice is followed; haven't tested without)
> But nothing is done with decomposed and its content.
> Instead it just returns false.
>
> }
>
> --------
>
> It seems that the output of EnumTypeInfo's decomposeType() therefore never
> reaches anywhere?
>
> [ Or I could be entirely wrong. Going through the orocos internals feels a
> bit like swimming in very thick liquid. Progress is slow, then you get tired
> and sink ;) ]
>
> Cheers,
> Sagar
>
>> Op donderdag 18 oktober 2012 schreef Sagar Behere
>> (sagar [dot] behere [..] ... <mailto:sagar [dot] behere [..] ...>) het volgende:
>>
>>
>> On 10/18/2012 08:36 AM, Charles Lesire-Cabaniols wrote:
>> >
>> >
>> > 2012/10/17 Sagar Behere <sagar [dot] behere [..] ... <javascript:;>
>> > <mailto:sagar [dot] behere [..] ... <javascript:;>>>
>>
>> >
>> > On 10/12/2012 11:58 PM, Sagar Behere wrote:
>> > > On 10/12/2012 10:41 PM, Peter Soetens wrote:
>> > >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar
>> > Behere<sagar [dot] behere [..] ... <javascript:;>
>> <mailto:sagar [dot] behere [..] ... <javascript:;>>>
>>
>> > >> wrote:
>> > >>> Hello,
>> > >>>
>> > >>> In master branch, OCL::FileReporter is not reporting the values
>> > of enums
>> > >>> in the data structs that are exchanged over the dataports. For
>> > example,
>> > >>> a snippet of a line from the FileReporter output is
>> > >>>
>> > >>> ---
>> > >>>
>> > >>> 10.9116 (/scoop/informationElement/t_messageType) 14
>> 1350069404 765
>> > >>> (/scoop/informationElement/t_messagePriority) 7 0
>> > >>> (/scoop/informationElement/t_nodeType) 10 10
>> > >>>
>> > >>> ---
>> > >>>
>> > >>> In the above (/scoop/informationElement/t_messageType) is an
>> > enum [in
>> > >>> this particular case, I happen to know that its value is 2 and
>> > this is
>> > >>> read properly by the component receiving the struct ].
>> > Similarly, the
>> > >>> other () in the log above are enums.
>> > >>>
>> > >>> How to get enums reported properly in the logs?
>> > >>
>> > >> In a hand-written typekit, you'd use EnumTypeInfo which would
>> > convert
>> > >> your
>> > >> enum to an int when reporting looks at your type. It looks like
>> > >> typegen is
>> > >> not using EnumTypeInfo.
>> > >>
>> > >> Well, now it gets interesting for using the master branch. This
>> > can be
>> > >> added
>> > >> later-on, by writing a tiny typekit which adds this
>> functionality to
>> > >> the enum's
>> > >> typekit. Try in some arbitrary location (like a constructor) to
>> > write
>> > >> this:
>> > >>
>> > >> #include<rtt/types/EnumTypeInfo.hpp>
>> > >> #include<rtt/types/Types.hpp>
>> > >>
>> > >> RTT::types::Types()->addTypeInfo( new
>> > >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
>> > >
>> > > I assume you meant RTT::types::Types()->addType() ? The compiler
>> > > complained that classs TypeInfoRepository didn't have
>> addTypeInfo().
>> > >
>> > > So I included the headers and added the following line to one
>> of the
>> > > TaskContext's constructors
>> > >
>> > > RTT::types::Types()->addType( new
>> > >
>> >
>>
>> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
>> > > );
>> >
>> > I added the above line of code to the constructor of the
>> component that
>> > is sending the structs which contain the enums. When running
>> the system,
>> > it gives messages like
>> > ----
>> > 11.280 [ Warning][Logger] No enum-to-string mapping defined
>> for enum
>> > t_messageType. Converting to int.
>> > ----
>> >
>> >
>> > You have to define the enum/string mapping in your type info
>> constructor:
>> >
>> > typedef enum
>> > {
>> > A, B, C
>> > } TheEnum;
>> >
>> > struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
>> > {
>> > EnumStringTypeInfo() :
>> > EnumTypeInfo<TheEnum> ("TheEnum")
>> > {
>> > to_string[A] = "A";
>> > to_string[B] = "B";
>> > Doing the above removes the warning message, but does not
>> result in the
>> mapped string appearing in the log file. In fact, there is no change
>> in
>> the log file contents.
>>
>> Specifically, the actual test code I created is
>>
>> -----
>> namespace scoop {
>> namespace wireless {
>>
>> struct EnumStringTypeInfo: public
>> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>
>> {
>>
>>
>> EnumStringTypeInfo():EnumTypeInfo<scoop::informationElement::t_messageType>("nameOft_messageType")
>> {
>>
>> to_string[scoop::informationElement::reserved_messageType] = "0
>> reserved_messageType";
>> //
>> to_string[scoop::informationElement::dynamicVehicleInfo] = "1
>> dynamicVehicleInfo";
>>
>> this->to_string[scoop::informationElement::staticVehicleInfo] = "2
>> staticVehicleInfo";
>> }
>> };
>>
>> and in the constructor of the TaskContext, I added
>>
>> RTT::types::Types()->addType( new EnumStringTypeInfo );
>> ------
>>
>> So when the enum value is
>> "scoop::informationElement::staticVehicleInfo"
>> I expect to see the mapped string "2 staticVehicleInfo" in the log.
>> This
>> does not happen. The log file still shows the enum value as
>> "(/scoop/informationElement/t_messageType)"
>>
>> So I commented out the to_string[] line for
>> "scoop::informationElement::staticVehicleInfo" in the
>> EnumStringTypeInfo
>> constructor just to see if it would have any effect. Doing so causes
>> the
>> warning to re-appear.
>>
>> In summary, registering the EnumStringTypeInfo makes the warning
>> disappear. However, the contents of the log file do not show the
>> enum value.
>>
>> Regards,
>> Sagar
>>
>> > I am afraid this is not documented...
>> >
>> > Charles.
>> >
>> >
>> > but the log file still contains lines like
>> >
>> > 9.83815 (/scoop/informationElement/t_messageType) 131
>> 1350508651 648
>> > (/scoop/informationElement/t_messagePriority) 131 0
>> > (/scoop/informationElement/t_nodeType) 131 131
>> >
>> >
>> > which is the same as before. The enum values are still not
>> being
>> > reported properly. The warning message seems to originate
>> from the
>> > decomposeType() function in
>> >
>> >
>>
>> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
>> >
>> > but I'm unable to debug further :(
>> >
>> > /Sagar
>> >
>> > >
>> > > Does something more need to be done in order to get a numerical
>> > value?
>> > >
>> > > /Sagar
>> > >
>> > >> You could formalize this later on in a hand written typekit or
>> > plugin.
>> > >>
>> > >> Peter
>> > >
>> >
>> > --
>> > Orocos-Users mailing list
>> > Orocos-Users [..] ... <javascript:;>
>> > <mailto:Orocos-Users [..] ... <javascript:;>>
>>
>> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>> >
>> >
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ... <javascript:;>
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>

OCL::FileReporter enums

On 10/25/2012 05:39 AM, Peter Soetens wrote:
> Hi Sagar,
>
> Probably, the patch in attachment for RTT will fix this. I added code
> which was present in the ReportingComponent, but not in the RTT,
> causing decomposed structs not to be able to decompose enums.

Sweet! This works :)

It is still required to add the EnumTypeInfo derived type to the RTT,
but once this is done, then the FileReporter reports the string set
using the to_string[] map, and if no such string exists, it reports the
enum as an int.

Thank you so very much, Peter!

Cheers,
Sagar

> On Sat, Oct 20, 2012 at 2:45 PM, Sagar Behere<sagar [dot] behere [..] ...> wrote:
>> On 10/18/2012 12:41 PM, Peter Soetens wrote:
>>>
>>> Hi Sagar,
>>>
>>> I need to look into the decomposition code and the reporters code. We'll
>>> get this fixed, the error is not on your side.
>>
>>
>> Maybe this will help.
>>
>> --------
>>
>> In PropertyDecomposition.cpp, in the typeDecomposition()
>>
>> if (decomposed) {
>> ...
>> if (bag){...}
>> else {
>>
>> This is where it ends up for enums.
>>
>> dsb->getTypeName() is /scoop/informationElement/t_messageType
>> dsb->toString() is (/scoop/informationElement/t_messageType)
>>
>> decomposed->getTypeName() is either an int or string
>> (depending on whether Charles' advice is followed)
>> decomposed->toString() contains exactly what we need
>> (when Charles' advice is followed; haven't tested without)
>> But nothing is done with decomposed and its content.
>> Instead it just returns false.
>>
>> }
>>
>> --------
>>
>> It seems that the output of EnumTypeInfo's decomposeType() therefore never
>> reaches anywhere?
>>
>> [ Or I could be entirely wrong. Going through the orocos internals feels a
>> bit like swimming in very thick liquid. Progress is slow, then you get tired
>> and sink ;) ]
>>
>> Cheers,
>> Sagar
>>
>>> Op donderdag 18 oktober 2012 schreef Sagar Behere
>>> (sagar [dot] behere [..] ...<mailto:sagar [dot] behere [..] ...>) het volgende:
>>>
>>>
>>> On 10/18/2012 08:36 AM, Charles Lesire-Cabaniols wrote:
>>> >
>>> >
>>> > 2012/10/17 Sagar Behere<sagar [dot] behere [..] ...<javascript:;>
>>> > <mailto:sagar [dot] behere [..] ...<javascript:;>>>
>>>
>>> >
>>> > On 10/12/2012 11:58 PM, Sagar Behere wrote:
>>> > > On 10/12/2012 10:41 PM, Peter Soetens wrote:
>>> > >> On Fri, Oct 12, 2012 at 9:21 PM, Sagar
>>> > Behere<sagar [dot] behere [..] ...<javascript:;>
>>> <mailto:sagar [dot] behere [..] ...<javascript:;>>>
>>>
>>> > >> wrote:
>>> > >>> Hello,
>>> > >>>
>>> > >>> In master branch, OCL::FileReporter is not reporting the values
>>> > of enums
>>> > >>> in the data structs that are exchanged over the dataports. For
>>> > example,
>>> > >>> a snippet of a line from the FileReporter output is
>>> > >>>
>>> > >>> ---
>>> > >>>
>>> > >>> 10.9116 (/scoop/informationElement/t_messageType) 14
>>> 1350069404 765
>>> > >>> (/scoop/informationElement/t_messagePriority) 7 0
>>> > >>> (/scoop/informationElement/t_nodeType) 10 10
>>> > >>>
>>> > >>> ---
>>> > >>>
>>> > >>> In the above (/scoop/informationElement/t_messageType) is an
>>> > enum [in
>>> > >>> this particular case, I happen to know that its value is 2 and
>>> > this is
>>> > >>> read properly by the component receiving the struct ].
>>> > Similarly, the
>>> > >>> other () in the log above are enums.
>>> > >>>
>>> > >>> How to get enums reported properly in the logs?
>>> > >>
>>> > >> In a hand-written typekit, you'd use EnumTypeInfo which would
>>> > convert
>>> > >> your
>>> > >> enum to an int when reporting looks at your type. It looks like
>>> > >> typegen is
>>> > >> not using EnumTypeInfo.
>>> > >>
>>> > >> Well, now it gets interesting for using the master branch. This
>>> > can be
>>> > >> added
>>> > >> later-on, by writing a tiny typekit which adds this
>>> functionality to
>>> > >> the enum's
>>> > >> typekit. Try in some arbitrary location (like a constructor) to
>>> > write
>>> > >> this:
>>> > >>
>>> > >> #include<rtt/types/EnumTypeInfo.hpp>
>>> > >> #include<rtt/types/Types.hpp>
>>> > >>
>>> > >> RTT::types::Types()->addTypeInfo( new
>>> > >> RTT::types::EnumTypeInfo<t_messageType>("t_messageType") );
>>> > >
>>> > > I assume you meant RTT::types::Types()->addType() ? The compiler
>>> > > complained that classs TypeInfoRepository didn't have
>>> addTypeInfo().
>>> > >
>>> > > So I included the headers and added the following line to one
>>> of the
>>> > > TaskContext's constructors
>>> > >
>>> > > RTT::types::Types()->addType( new
>>> > >
>>> >
>>>
>>> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>("t_messageType")
>>> > > );
>>> >
>>> > I added the above line of code to the constructor of the
>>> component that
>>> > is sending the structs which contain the enums. When running
>>> the system,
>>> > it gives messages like
>>> > ----
>>> > 11.280 [ Warning][Logger] No enum-to-string mapping defined
>>> for enum
>>> > t_messageType. Converting to int.
>>> > ----
>>> >
>>> >
>>> > You have to define the enum/string mapping in your type info
>>> constructor:
>>> >
>>> > typedef enum
>>> > {
>>> > A, B, C
>>> > } TheEnum;
>>> >
>>> > struct EnumStringTypeInfo: public EnumTypeInfo<TheEnum>
>>> > {
>>> > EnumStringTypeInfo() :
>>> > EnumTypeInfo<TheEnum> ("TheEnum")
>>> > {
>>> > to_string[A] = "A";
>>> > to_string[B] = "B";
>>> > Doing the above removes the warning message, but does not
>>> result in the
>>> mapped string appearing in the log file. In fact, there is no change
>>> in
>>> the log file contents.
>>>
>>> Specifically, the actual test code I created is
>>>
>>> -----
>>> namespace scoop {
>>> namespace wireless {
>>>
>>> struct EnumStringTypeInfo: public
>>> RTT::types::EnumTypeInfo<scoop::informationElement::t_messageType>
>>> {
>>>
>>>
>>> EnumStringTypeInfo():EnumTypeInfo<scoop::informationElement::t_messageType>("nameOft_messageType")
>>> {
>>>
>>> to_string[scoop::informationElement::reserved_messageType] = "0
>>> reserved_messageType";
>>> //
>>> to_string[scoop::informationElement::dynamicVehicleInfo] = "1
>>> dynamicVehicleInfo";
>>>
>>> this->to_string[scoop::informationElement::staticVehicleInfo] = "2
>>> staticVehicleInfo";
>>> }
>>> };
>>>
>>> and in the constructor of the TaskContext, I added
>>>
>>> RTT::types::Types()->addType( new EnumStringTypeInfo );
>>> ------
>>>
>>> So when the enum value is
>>> "scoop::informationElement::staticVehicleInfo"
>>> I expect to see the mapped string "2 staticVehicleInfo" in the log.
>>> This
>>> does not happen. The log file still shows the enum value as
>>> "(/scoop/informationElement/t_messageType)"
>>>
>>> So I commented out the to_string[] line for
>>> "scoop::informationElement::staticVehicleInfo" in the
>>> EnumStringTypeInfo
>>> constructor just to see if it would have any effect. Doing so causes
>>> the
>>> warning to re-appear.
>>>
>>> In summary, registering the EnumStringTypeInfo makes the warning
>>> disappear. However, the contents of the log file do not show the
>>> enum value.
>>>
>>> Regards,
>>> Sagar
>>>
>>> > I am afraid this is not documented...
>>> >
>>> > Charles.
>>> >
>>> >
>>> > but the log file still contains lines like
>>> >
>>> > 9.83815 (/scoop/informationElement/t_messageType) 131
>>> 1350508651 648
>>> > (/scoop/informationElement/t_messagePriority) 131 0
>>> > (/scoop/informationElement/t_nodeType) 131 131
>>> >
>>> >
>>> > which is the same as before. The enum values are still not
>>> being
>>> > reported properly. The warning message seems to originate
>>> from the
>>> > decomposeType() function in
>>> >
>>> >
>>>
>>> http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/EnumTypeInf...
>>> >
>>> > but I'm unable to debug further :(
>>> >
>>> > /Sagar
>>> >
>>> > >
>>> > > Does something more need to be done in order to get a numerical
>>> > value?
>>> > >
>>> > > /Sagar
>>> > >
>>> > >> You could formalize this later on in a hand written typekit or
>>> > plugin.
>>> > >>
>>> > >> Peter
>>> > >
>>> >
>>> > --
>>> > Orocos-Users mailing list
>>> > Orocos-Users [..] ...<javascript:;>
>>> > <mailto:Orocos-Users [..] ...<javascript:;>>
>>>
>>> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>> >
>>> >
>>>
>>> --
>>> Orocos-Users mailing list
>>> Orocos-Users [..] ...<javascript:;>
>>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>>
>>