freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Logging Library-GSOC


From: David Turner
Subject: Re: Logging Library-GSOC
Date: Wed, 20 May 2020 10:07:09 +0200



Le mar. 19 mai 2020 à 09:30, Priyesh kumar <address@hidden> a écrit :
Thanks for the reply,

>Basically yes.  As an improvement, I would like that the value of the
>`FT_COMPONENT` macro can be displayed optionally, e.g.

>[afhints] foo bar
>[ttgxvar] sproink
>...

>The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to
>see all those tags, then redo it with, say,

> FT2_DEBUG=afhints:7

>to get only the 'afhints' debug messages if this is what you need for
>debugging.


Thanks, I will keep this in mind...

> >2. Most external libraries provide some log levels capabilities
>>    themselves, so, should I think in direction of utilizing
>>    those. In case yes, then how should that be utilized?

>Please elaborate and show examples.
>> In the 2nd case, FreeType's logger will completely depend on the
>> external library, and developers will also need to learn some new
>> information to use the logger.  And In the worst-case scenario, if
>> the external library drops some functionality, we will need to make
>> amendments to the logger.

>I agree.
 
In the 2nd point I wanted to ask that should I completely reimplement the logger using APIs of external library.
Since you agreed with the below point, I don't think the 2nd point makes any sense now...
Will proceed with the 1st point...

I'm sorry but that doesn't make any sense to me. There is absolutely no point in making part of FreeType depend on a specific external logger library at this point.
Also we don't even know which library, or which API. This looks like a solution looking for a problem.

Also we don't necessarily send logs to stderr, e.g. there are already several versions of ftdebug.c, i.e. the one under builds/windows/ uses OutputDebugStringA(), or the one under builds/amiga/ uses KVPrintf(), etc..
All Werner wants is structured outputs, which can easily be done in the current code base with minimal refactor of the FT_TRACE macro implementations.

I'm sorry but all I see in your posts are vague promises and little concrete ideas.

I recommend you start presenting how you plan modifying the current code base to achieve structured outputs (in very technical terms), then explain how one could hook FreeType to a specific logging library (e.g. with a runtime callback, or a configurable dependency).
And for each step, explain the benefits / drawbacks of the approach you're suggesting.

Thanks

- David
 
Thanks,
Priyesh

On Mon, May 18, 2020 at 9:03 PM Werner LEMBERG <address@hidden> wrote:



> I wanted to ask that after selecting desirable external library how
> should I proceed:

[For David T.: The idea is to statically link the library into
 FreeType using a git submodule.  In other words, it's 'external' only
 because it is developed by other people.]

> 1. Should I stick to the existing debugging facility in which
>    filtering of log messages is based on debug level comparisons of
>    various FreeType's components and only use the external library
>    to write log messages to file instead of stderr?

Basically yes.  As an improvement, I would like that the value of the
`FT_COMPONENT` macro can be displayed optionally, e.g.

  [afhints] foo bar
  [ttgxvar] sproink
  ...

The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to
see all those tags, then redo it with, say,

  FT2_DEBUG=afhints:7

to get only the 'afhints' debug messages if this is what you need for
debugging.

> 2. Most external libraries provide some log levels capabilities
>    themselves, so, should I think in direction of utilizing
>    those. In case yes, then how should that be utilized?

Please elaborate and show examples.

> In the 2nd case, FreeType's logger will completely depend on the
> external library, and developers will also need to learn some new
> information to use the logger.  And In the worst-case scenario, if
> the external library drops some functionality, we will need to make
> amendments to the logger.

I agree.

> According to me, the 1st option is better since the experience of
> using the logger will be the same for the client and developers and
> the only dependency of FreeType on external library will be of
> writing log messages to a file.

Yep.


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]