[PATCH weston v4 2/9] libweston: add weston_debug API and implementation

[Daniel Stone]

Hey,
One last comment from IRC discussion.

On 23 October 2017 at 13:10, Daniel Stone <daniel at fooishbar.org> wrote:
> On 23 October 2017 at 12:54, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> On Mon, 23 Oct 2017 12:34:47 +0200
>> Daniel Stone <daniel at fooishbar.org> wrote:
>>> I would very much not like to see formatted time in the debug scopes.
>>> Can we please just use a raw microsecond value? Ultimately I would
>>> like to see tools parse these files, but trying to parse formatted
>>> times is a nightmare.
>>
>> Hm, that is very much contrary to my original intentions. I hate
>> reading raw timestamps, they are difficult to make sense of. I also
>> didn't intend the output to be machine-parsed, at least not the streams
>> that use this function for timestamps. (Emitting timestamps is
>> completely optional.)
>>
>> The usual use case for these is that I am reading through the log
>> myself and that is what I optimized for: human readability.
>>
>> I suppose we would need a dual-mode framework to support both
>> human-readable and machine-readable output, because I cannot see myself
>> updating a post-processing parser every time I add some new debug prints.
>>
>> This is literally supposed to be a dynamic printf equivalent.
>
> I totally get your point, but on the other hand, we need a specialist
> client to capture the messages anyway. So why not enforce that every
> line begins with usec followed by a space (or, if a continuation,
> newline directly followed by a space)? It's trivial for a
> printf-stream tool to convert, but also makes it more usable for tools
> which want to interpret the output a bit better.

Following up to myself, one usecase I think is important is where
tools do _not_ interpret the messages. For example, IDEs like GNOME
Builder and Qt Creator already provide profiling UI, where they match
up overall system profiling information with information from the
toolkit itself - what it was painting, how long the layout/paint
cycles took, what was painted, etc. If we make two pieces of
information parseable by tools - scope lists and timestamps - then we
can allow those tools to integrate freeform log information (to be
interpreted by humans) into their existing profiling tools.

Sorry for the very late review on this one.

Cheers,
Daniel