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 [..] ... >>> > <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.hp

>>> > >> #include<rtt/types/Types.hp

>>> > >>
>>> > >> 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 [..] ... >>>
>>> > 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
>>>
>>