[Rock-dev] csv_logger and rock-toolchain

[Alexander Duda]

On 11/13/2013 09:46 AM, Matthias Goldhoorn wrote:
> 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.
You can always write a ruby binding to speed up the conversion.
>>
>> 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.

I am open for discussions but I will have no time to propose a solution 
nor to implement this kind of functionality. This has to be done by the 
guys which want to have the functionallity.

Greets
Alex

>>
>> 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.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3