Suggestion to improve ReportingComponent

Submitted by sspr on Sat, 2009-01-31 22:25

RTT-dev

The confusion of a user on how to configure the ReportingComponent inspired me
to an improvement. Today, the property file of the ReportingComponent looks
like:

<properties>
  <simple name="AutoTrigger" type="boolean"><description>When set to 1, the 
data is taken upon each update(), otherwise, the data is only taken when the 
user invokes 'snapshot()'.\
</description><value>1</value></simple>
  <simple name="Configuration" type="string"><description>The name of the 
property file which lists what is to be 
reported.</description><value>deployment/logging/log-plant.cpf</v\
alue></simple>
  <simple name="WriteHeader" type="boolean"><description>Set to true to start 
each report with a header.</description><value>1</value></simple>
  <simple name="Decompose" type="boolean"><description>Set to true to 
decompose data ports.</description><value>1</value></simple>
  <simple name="ReportFile" type="string"><description>Location on disc to 
store the reports.</description><value>port-log.dat</value></simple>
</properties>

Note that the 'Configuration' property points to another file, which lists which
ports and/or components to report. This makes that in practice, in order to
configure the ReportingComponent, three XML files are needed: the application
deployment file, the Reporter's property file and the 'Configuration' file. We
could, using the 'LoadProperties' scheme, allow to put the contents of
Configuration in the standard property file and let the ReportingComponent scan
the loaded properties in order to know which ports to log:

<properties>
  <simple name="AutoTrigger" type="boolean"><description>When set to 1, the 
data is taken upon each update(), otherwise, the data is only taken when the 
user invokes 'snapshot()'.\
</description><value>1</value></simple>
  <simple name="WriteHeader" type="boolean"><description>Set to true to start 
each report with a header.</description><value>1</value></simple>
  <simple name="Decompose" type="boolean"><description>Set to true to 
decompose data ports.</description><value>1</value></simple>
  <simple name="ReportFile" type="string"><description>Location on disc to 
store the reports.</description><value>port-log.dat</value></simple>
  <struct name="ReportData" type="PropertyBag">
    <simple name="Component" 
type="string"><description></description><value>Plant</value></simple>
    <simple name="Port" 
type="string"><description></description><value>Automatic.output</value></simple>
  </struct>
</properties>

The struct 'ReportData' has been added and Configuration becomes obsolete (we
can keep it for backwards compatibility).

It makes more sense to me, but YMMV.

Peter

Suggestion to improve ReportingComponent

Submitted by sspr on Mon, 2009-02-09 22:15.

On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
> The confusion of a user on how to configure the ReportingComponent inspired
> me to an improvement. Today, the property file of the ReportingComponent
> looks like:
(snipped)

This is how far I got with my patch. It seems to work (read in a file, ports
got reported), but I didn't thoroughly test it yet. I had to add the
'AutoSave' property to the deployer's XML format such that settings of the
reporting could be saved within the XML file when the application closes.

I didn't test AutoSave. you probably need OCL trunk for these patches to
apply.

Peter

Suggestion to improve ReportingComponent

Submitted by sspr on Tue, 2009-02-10 08:35.

On Monday 09 February 2009 23:11:39 Peter Soetens wrote:
> On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
> > The confusion of a user on how to configure the ReportingComponent
> > inspired me to an improvement. Today, the property file of the
> > ReportingComponent looks like:
>
> (snipped)
>
> This is how far I got with my patch. It seems to work (read in a file,
> ports got reported), but I didn't thoroughly test it yet. I had to add the
> 'AutoSave' property to the deployer's XML format such that settings of the
> reporting could be saved within the XML file when the application closes.
>
> I didn't test AutoSave. you probably need OCL trunk for these patches to
> apply.

Nevermind. Patch was incomplete. Try these on orocos-rtt and orocos-ocl. This
works for me (with AutoSave).

Peter

Suggestion to improve ReportingComponent

Submitted by snrkiwi on Mon, 2009-03-02 22:20.

On Feb 10, 2009, at 02:53 , Peter Soetens wrote:

> On Monday 09 February 2009 23:11:39 Peter Soetens wrote:
>> On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
>>> The confusion of a user on how to configure the ReportingComponent
>>> inspired me to an improvement. Today, the property file of the
>>> ReportingComponent looks like:
>>
>> (snipped)
>>
>> This is how far I got with my patch. It seems to work (read in a
>> file,
>> ports got reported), but I didn't thoroughly test it yet. I had to
>> add the
>> 'AutoSave' property to the deployer's XML format such that settings
>> of the
>> reporting could be saved within the XML file when the application
>> closes.
>>
>> I didn't test AutoSave. you probably need OCL trunk for these
>> patches to
>> apply.
>
> Nevermind. Patch was incomplete. Try these on orocos-rtt and orocos-
> ocl. This
> works for me (with AutoSave).

Trunk does not work for me, on both Mac OS X and Linux, for
FileReporting components. I have to change from PropertyFile to
LoadProperties (UpdateProperties does not work), and replace the
Configuration section with a ReportData section to get it to work. I
thought the intent was to keep backwards compatibility?

Both UpdateProperties and PropertyFile for a FileReporting component
give me

0.268 [ ERROR  ][ReportingComponent] No port or component  
configuration loaded.
0.268 [ ERROR  ][ReportingComponent] Please use  
marshalling.loadProperties(), reportComponent() (scripting) or  
LoadProperties (XML) in order to fill in ReportData.
0.268 [ ERROR  ][DeploymentComponent::configureComponents] Failed to  
configure peer ReporternAxes

Have not tried AutoSave.

Working sections below

   <struct name="ReporternAxes" type="OCL::FileReporting">
     <struct name="Activity" type="PeriodicActivity">
       <simple name="Period" type="double"><value>0.1</value></simple>
       <simple name="Priority" type="short"><value>0</value></simple>
       <simple name="Scheduler" type="string"><value>ORO_SCHED_OTHER</ 
value></simple>
     </struct>
     <simple name="LoadProperties" type="string">
	  <value>data/orocos/cpf/report-naxes.cpf</value></simple>
     <simple name="AutoConf" type="boolean"><value>1</value></simple>
     <simple name="AutoStart" type="boolean"><value>1</value></simple>
     <struct name="Peers" type="PropertyBag">
       <simple type="string"><value>Robot</value></simple>
       <simple type="string"><value>ArmControllerMgr</value></simple>
       <simple type="string"><value>nAxesGeneratorPos</value></simple>
     </struct>
   </struct>

File report-naxes.cpf

<properties>
   <simple name="AutoTrigger" type="boolean">
	<description>When set to 1, the data is taken upon each update(),  
otherwise, the data is only taken when the user invokes 'snapshot()'.</ 
description>
	<value>1</value>
   </simple>
   <struct name="ReportData" type="PropertyBag">
	<simple name="Port" type="string"><value>Robot.robotState</value></ 
simple>
	<simple name="Port"  
type="string"><value>ArmControllerMgr.armControllerMgrState</value></ 
simple>
	<simple name="Port" type="string"><value>Robot.nAxesSensorPosition</ 
value></simple>
	<simple name="Port" type="string"><value>Robot.nAxesDesiredPosition</ 
value></simple>
	<simple name="Port"  
type="string"><value>Robot.CartesianSensorPosition</value></simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesSensorPosition</value></ 
simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesDesiredPosition</value></ 
simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesPercentCompleted</value></ 
simple>
   </struct>
   <simple name="WriteHeader" type="boolean">
	<description>Set to true to start each report with a header.</ 
description>
	<value>1</value>
   </simple>
   <!-- For file reporting component -->
   <simple name="ReportFile" type="string">
	<description>The name of the file to write the report data to.</ 
description>
	<value>report-naxes.dat</value>
   </simple>
   <simple name="Decompose" type="boolean">
	<description>For NetCDF</description>
	<value>1</value>
   </simple>
   <simple name="Synchronize" type="boolean">
	<description>Synchronize timestamp with logging</description>
	<value>1</value>
   </simple>
</properties>

Suggestion to improve ReportingComponent

Submitted by snrkiwi on Mon, 2009-03-02 21:35.

On Feb 10, 2009, at 02:53 , Peter Soetens wrote:

Both UpdateProperties and PropertyFile for a FileReporting component
give me

0.268 [ ERROR  ][ReportingComponent] No port or component  
configuration loaded.
0.268 [ ERROR  ][ReportingComponent] Please use  
marshalling.loadProperties(), reportComponent() (scripting) or  
LoadProperties (XML) in order to fill in ReportData.
0.268 [ ERROR  ][DeploymentComponent::configureComponents] Failed to  
configure peer ReporternAxes

Have not tried AutoSave.

Working sections below

   <struct name="ReporternAxes" type="OCL::FileReporting">
     <struct name="Activity" type="PeriodicActivity">
       <simple name="Period" type="double"><value>0.1</value></simple>
       <simple name="Priority" type="short"><value>0</value></simple>
       <simple name="Scheduler" type="string"><value>ORO_SCHED_OTHER</ 
value></simple>
     </struct>
     <simple name="LoadProperties" type="string">
	  <value>data/orocos/cpf/report-naxes.cpf</value></simple>
     <simple name="AutoConf" type="boolean"><value>1</value></simple>
     <simple name="AutoStart" type="boolean"><value>1</value></simple>
     <struct name="Peers" type="PropertyBag">
       <simple type="string"><value>Robot</value></simple>
       <simple type="string"><value>ArmControllerMgr</value></simple>
       <simple type="string"><value>nAxesGeneratorPos</value></simple>
     </struct>
   </struct>

File report-naxes.cpf

<properties>
   <simple name="AutoTrigger" type="boolean">
	<description>When set to 1, the data is taken upon each update(),  
otherwise, the data is only taken when the user invokes 'snapshot()'.</ 
description>
	<value>1</value>
   </simple>
   <struct name="ReportData" type="PropertyBag">
	<simple name="Port" type="string"><value>Robot.robotState</value></ 
simple>
	<simple name="Port"  
type="string"><value>ArmControllerMgr.armControllerMgrState</value></ 
simple>
	<simple name="Port" type="string"><value>Robot.nAxesSensorPosition</ 
value></simple>
	<simple name="Port" type="string"><value>Robot.nAxesDesiredPosition</ 
value></simple>
	<simple name="Port"  
type="string"><value>Robot.CartesianSensorPosition</value></simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesSensorPosition</value></ 
simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesDesiredPosition</value></ 
simple>
	<simple name="Port"  
type="string"><value>nAxesGeneratorPos.nAxesPercentCompleted</value></ 
simple>
   </struct>
   <simple name="WriteHeader" type="boolean">
	<description>Set to true to start each report with a header.</ 
description>
	<value>1</value>
   </simple>
   <!-- For file reporting component -->
   <simple name="ReportFile" type="string">
	<description>The name of the file to write the report data to.</ 
description>
	<value>report-naxes.dat</value>
   </simple>
   <simple name="Decompose" type="boolean">
	<description>For NetCDF</description>
	<value>1</value>
   </simple>
   <simple name="Synchronize" type="boolean">
	<description>Synchronize timestamp with logging</description>
	<value>1</value>
   </simple>
</properties>

Suggestion to improve ReportingComponent

Submitted by sspr on Mon, 2009-03-02 22:45.

On Monday 02 March 2009 22:33:50 S Roderick wrote:
> On Feb 10, 2009, at 02:53 , Peter Soetens wrote:
> > On Monday 09 February 2009 23:11:39 Peter Soetens wrote:
> >> On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
> >>> The confusion of a user on how to configure the ReportingComponent
> >>> inspired me to an improvement. Today, the property file of the
> >>> ReportingComponent looks like:
> >>

>
> Trunk does not work for me, on both Mac OS X and Linux, for
> FileReporting components. I have to change from PropertyFile to
> LoadProperties (UpdateProperties does not work), and replace the
> Configuration section with a ReportData section to get it to work. I
> thought the intent was to keep backwards compatibility?

I should have made more explicit (on the ML) that it broke the old property format.
Sorry.

http://www.orocos.org/stable/documentation/rtt/v1.8.x/doc-xml/orocos-rtt...
http://www.orocos.org/stable/documentation/ocl/v1.8.x/doc-xml/orocos-rep...

I was wondering during coding if the error message should refer to the manual as well :-/

Peter

Suggestion to improve ReportingComponent

Submitted by sspr on Wed, 2009-02-04 08:25.

Ping ! Anyone cares ?

> <properties>
>   <simple name="AutoTrigger" type="boolean"><description>When set to 1, the
> data is taken upon each update(), otherwise, the data is only taken when
> the user invokes 'snapshot()'.\
> </description><value>1</value></simple>
>   <simple name="Configuration" type="string"><description>The name of the
> property file which lists what is to be
> reported.</description><value>deployment/logging/log-plant.cpf</v\
> alue></simple>
>   <simple name="WriteHeader" type="boolean"><description>Set to true to
> start each report with a header.</description><value>1</value></simple>
>   <simple name="Decompose" type="boolean"><description>Set to true to
> decompose data ports.</description><value>1</value></simple>
>   <simple name="ReportFile" type="string"><description>Location on disc to
> store the reports.</description><value>port-log.dat</value></simple>
> </properties>
>

>
> Note that the 'Configuration' property points to another file, which lists
> which ports and/or components to report. This makes that in practice, in
> order to configure the ReportingComponent, three XML files are needed: the
> application deployment file, the Reporter's property file and the
> 'Configuration' file. We could, using the 'LoadProperties' scheme, allow to
> put the contents of Configuration in the standard property file and let the
> ReportingComponent scan the loaded properties in order to know which ports
> to log:
>
>

> <properties>
>   <simple name="AutoTrigger" type="boolean"><description>When set to 1, the
> data is taken upon each update(), otherwise, the data is only taken when
> the user invokes 'snapshot()'.\
> </description><value>1</value></simple>
>   <simple name="WriteHeader" type="boolean"><description>Set to true to
> start each report with a header.</description><value>1</value></simple>
>   <simple name="Decompose" type="boolean"><description>Set to true to
> decompose data ports.</description><value>1</value></simple>
>   <simple name="ReportFile" type="string"><description>Location on disc to
> store the reports.</description><value>port-log.dat</value></simple>
>   <struct name="ReportData" type="PropertyBag">
>     <simple name="Component"
> type="string"><description></description><value>Plant</value></simple>
>     <simple name="Port"
> type="string"><description></description><value>Automatic.output</value></s
>imple> </struct>
> </properties>
>

>
> The struct 'ReportData' has been added and Configuration becomes obsolete
> (we can keep it for backwards compatibility).
>
> It makes more sense to me, but YMMV.
>
> Peter
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>

Some bytes from me:

Submitted by vri on Wed, 2009-02-04 08:41.

Some bytes from me: time=approx 9 min

Yes, I care. I had a student struggling with this, the next one will now struggle less I guess.

So: thanks!

But: YMMV???
And yesterday you had another one: YAGNI???

I think we need a wiki page for this... ;-)

Theo.

Some bytes from me:

Submitted by bruyninc on Wed, 2009-02-04 08:55.

On Wed, 4 Feb 2009, t [dot] j [dot] a [dot] devries [..] ... wrote:

> Some bytes from me: time=approx 9 min
>
> Yes, I care. I had a student struggling with this, the next one will now struggle less I guess.
>
> So: thanks!
>
> But: YMMV???
> And yesterday you had another one: YAGNI???
>
> I think we need a wiki page for this... ;-)

Indeed:-)
<http://en.wiktionary.org/wiki/YMMV>
<http://en.wikipedia.org/wiki/YAGNI>

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Suggestion to improve ReportingComponent

Submitted by Ruben Smits on Wed, 2009-02-04 08:40.

On Wednesday 04 February 2009 08:10:08 Peter Soetens wrote:
> Ping ! Anyone cares ?
>
> On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
> > The confusion of a user on how to configure the ReportingComponent
> > inspired me to an improvement. Today, the property file of the
> > ReportingComponent looks like:
> >
> >

> > <properties>
> >   <simple name="AutoTrigger" type="boolean"><description>When set to 1,
> > the data is taken upon each update(), otherwise, the data is only taken
> > when the user invokes 'snapshot()'.\
> > </description><value>1</value></simple>
> >   <simple name="Configuration" type="string"><description>The name of the
> > property file which lists what is to be
> > reported.</description><value>deployment/logging/log-plant.cpf</v\
> > alue></simple>
> >   <simple name="WriteHeader" type="boolean"><description>Set to true to
> > start each report with a header.</description><value>1</value></simple>
> >   <simple name="Decompose" type="boolean"><description>Set to true to
> > decompose data ports.</description><value>1</value></simple>
> >   <simple name="ReportFile" type="string"><description>Location on disc
> > to store the reports.</description><value>port-log.dat</value></simple>
> > </properties>
> >

> >
> > Note that the 'Configuration' property points to another file, which
> > lists which ports and/or components to report. This makes that in
> > practice, in order to configure the ReportingComponent, three XML files
> > are needed: the application deployment file, the Reporter's property file
> > and the 'Configuration' file. We could, using the 'LoadProperties'
> > scheme, allow to put the contents of Configuration in the standard
> > property file and let the ReportingComponent scan the loaded properties
> > in order to know which ports to log:
> >
> >

> > <properties>
> >   <simple name="AutoTrigger" type="boolean"><description>When set to 1,
> > the data is taken upon each update(), otherwise, the data is only taken
> > when the user invokes 'snapshot()'.\
> > </description><value>1</value></simple>
> >   <simple name="WriteHeader" type="boolean"><description>Set to true to
> > start each report with a header.</description><value>1</value></simple>
> >   <simple name="Decompose" type="boolean"><description>Set to true to
> > decompose data ports.</description><value>1</value></simple>
> >   <simple name="ReportFile" type="string"><description>Location on disc
> > to store the reports.</description><value>port-log.dat</value></simple>
> > <struct name="ReportData" type="PropertyBag">
> >     <simple name="Component"
> > type="string"><description></description><value>Plant</value></simple>
> >     <simple name="Port"
> > type="string"><description></description><value>Automatic.output</value><
> >/s imple> </struct>
> > </properties>
> >

> >
> > The struct 'ReportData' has been added and Configuration becomes obsolete
> > (we can keep it for backwards compatibility).
> >
> > It makes more sense to me, but YMMV.

I care ;), and i think it is a good idea, needing two property-files for the
reporting has always been a little strange to me.

Suggestion to improve ReportingComponent

Submitted by snrkiwi on Wed, 2009-02-04 13:25.

On Feb 4, 2009, at 03:35 , Ruben Smits wrote:

> On Wednesday 04 February 2009 08:10:08 Peter Soetens wrote:
>> Ping ! Anyone cares ?
>>
>> On Saturday 31 January 2009 23:23:59 Peter Soetens wrote:
>>> The confusion of a user on how to configure the ReportingComponent
>>> inspired me to an improvement. Today, the property file of the
>>> ReportingComponent looks like:
>>>
>>>

>>> <properties>
>>>  <simple name="AutoTrigger" type="boolean"><description>When set  
>>> to 1,
>>> the data is taken upon each update(), otherwise, the data is only  
>>> taken
>>> when the user invokes 'snapshot()'.\
>>> </description><value>1</value></simple>
>>>  <simple name="Configuration" type="string"><description>The name  
>>> of the
>>> property file which lists what is to be
>>> reported.</description><value>deployment/logging/log-plant.cpf</v\
>>> alue></simple>
>>>  <simple name="WriteHeader" type="boolean"><description>Set to  
>>> true to
>>> start each report with a header.</description><value>1</value></ 
>>> simple>
>>>  <simple name="Decompose" type="boolean"><description>Set to true to
>>> decompose data ports.</description><value>1</value></simple>
>>>  <simple name="ReportFile" type="string"><description>Location on  
>>> disc
>>> to store the reports.</description><value>port-log.dat</value></ 
>>> simple>
>>> </properties>
>>>

>>>
>>> Note that the 'Configuration' property points to another file, which
>>> lists which ports and/or components to report. This makes that in
>>> practice, in order to configure the ReportingComponent, three XML
>>> files
>>> are needed: the application deployment file, the Reporter's
>>> property file
>>> and the 'Configuration' file. We could, using the 'LoadProperties'
>>> scheme, allow to put the contents of Configuration in the standard
>>> property file and let the ReportingComponent scan the loaded
>>> properties
>>> in order to know which ports to log:
>>>
>>>

>>> <properties>
>>>  <simple name="AutoTrigger" type="boolean"><description>When set  
>>> to 1,
>>> the data is taken upon each update(), otherwise, the data is only  
>>> taken
>>> when the user invokes 'snapshot()'.\
>>> </description><value>1</value></simple>
>>>  <simple name="WriteHeader" type="boolean"><description>Set to  
>>> true to
>>> start each report with a header.</description><value>1</value></ 
>>> simple>
>>>  <simple name="Decompose" type="boolean"><description>Set to true to
>>> decompose data ports.</description><value>1</value></simple>
>>>  <simple name="ReportFile" type="string"><description>Location on  
>>> disc
>>> to store the reports.</description><value>port-log.dat</value></ 
>>> simple>
>>> <struct name="ReportData" type="PropertyBag">
>>>    <simple name="Component"
>>> type="string"><description></description><value>Plant</value></ 
>>> simple>
>>>    <simple name="Port"
>>> type="string"><description></description><value>Automatic.output</ 
>>> value><
>>> /s imple> </struct>
>>> </properties>
>>>

>>>
>>> The struct 'ReportData' has been added and Configuration becomes
>>> obsolete
>>> (we can keep it for backwards compatibility).
>>>
>>> It makes more sense to me, but YMMV.
>
> I care ;), and i think it is a good idea, needing two property-files
> for the
> reporting has always been a little strange to me.

Ditto and ditto.
S