[Rock-dev] csv_logger and rock-toolchain

[Matthias Goldhoorn]

On 13.11.2013 09:17, Alexander Duda wrote:
> On 11/13/2013 08:27 AM, Matthias Goldhoorn wrote:
>> On 12.11.2013 20:45, Sylvain Joyeux wrote:
>>> Hey. "Somebody" ;-) sneaked a csv_logger package in the rock-toolchain
>>> package set.
>> *here*
>>> In my opinion, rock-toolchain is a "toolCHAIN", not a "toolSHED" or a
>>> "toolSET". Meaning: it is designed to have tools that work together to
>>> form a whole, this whole allowing to solve the greater problem (in our
>>> case: building robots).
>>>
>>> This csv_logger really does not have its place. We already have a very
>>> well-integrated logger, and if a better csv export is required, it
>>> should IMO be in the form of an improvement of the CSV export of 
>>> pocolog.
>> The problem there is that my "user" requests to have a logger for _A_
>> component (including input connections). Since this is not known in the
>> log's anymore i need to do this during runtime.  The csv_ logger is not
>> mentioned to replace the current one, as written in the desc. it's only
>> for debugging components with tools like matlab.
> The problem is that we are starting to have different workflows to do 
> the same task. In your case I would really go for the normal logger 
> and extend pocolog or rock-export to convert the log data to csv. This 
> has the benefit that you can use all the infrastructore we have to 
> inspect log files (rock-replaly, rock-convert etc.). CSV is just a 
> very specific view on the logged data. And if you do not like the 
> tooling everyone is open for improving our workflow (guis, etc.)
The problem here was that a first version (besides the missing 
functionality regarding automatic handling of input_ports was REALLY 
slow. (replay through ruby scripts). So i went for a alternative logger 
implementation, that of course could be used offline too.
>
> I agree, that we lose the information about the connections if syskit 
> is not used and I am open for any discussions to solve this issue in a 
> generic way and not just for the CSV logging.
Then maybe we should start a discussion about logging the connections at 
this point. I don't want to have influence on too much core components 
for this logging functionality. As usual it needs to be done, and i 
tried the most generic way without too much overhead.
>
> Greets
> Alex
>
>>> In general, please PLEASE refrain from adding packages to the "core"
>>> rock (rock-toolchain, rock-base) without discussing it on the ML.
>> *ack, but added orogen_metadata also already, as discussed in personal*
>> Nerveless where should the logger go?, rock.base, rock?,
>> project-internal (*against since it's still from my point of view
>> general useable).
>>
>>> Sylvain
>> P.S. @Sylvain your coffee is on my desk ;)
>>
>> Matthias
>>
>
>


-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4193
  Zentrale: +49 421 178 45-6550
  Fax:      +49 421 178 45-4150
  E-Mail:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik