[Rock-dev] New feature: vizkit3d debug drawings

[Sylvain Joyeux]

> Besides, creating and populating special data structures just for
debugging creates debug-only code paths as well.

I never talked about "debug-only".

Most of the time, filling (or more often exposing) an internal data
structure has very little cost. When things start to fail online,
however, it helps dramatically. Debugging is not something that is
done "at the beginning" and the benefit I get from these structures
outweights by far the cost of maintaining them. Replay is never
perfect, and when you're pressed with time, may not be an option.

My experience is that there is little "debug-only codepaths" or
"release codepaths". There's ancillary data that is not often looked
at, but would be missed when it's needed.

Was just my two cents ... It's just my experience that text (and now
visual) logging does not cut it. Now, do what suits yourselves best.

Sylvain

On Tue, Sep 19, 2017 at 5:55 AM, Arne Böckmann <arne.boeckmann at dfki.de> wrote:
> Hi,
>> Friendly piece of advice: don't add debug-only codepaths in your
>> components.
>
> I agree. Debug-only codepaths should not be part of any release worthy
> code. However the goal of this library is to help developers understand
> what is going on while debugging/developing new components. It is not
> meant to be part of release code, hence the compile time switch that
> removes all visualization code paths.
>
> In a sense this library is like a logging library. But instead of
> textual output it creates visual output.
>
>> If you need to visualize debug info, build data structures
>> that go on a port and visualize that. Which will allow you to do deep
>> debugging from log files, and will make sure that debugging codepaths
>> does not get in the way when you go headless.
>>
>
> That is what we did before. However building data structures for
> temporary stuff that you just want to take a look at while debugging is
> time consuming and cumbersome. Especially in early development phases I
> tend to use small binaries that just test the stuff I am working on. At
> that time there are neither tasks nor ports.
>
> Besides, creating and populating special data structures just for
> debugging creates debug-only code paths as well. In my experience going
> from hand-made debug visualizations to debug drawing macros has reduced
> the debug-only code paths to a bare minimum.
>
> Cheers,
>
> Arne
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev