freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] Logging library proposal


From: Yash Khasbage
Subject: Re: [ft-devel] Logging library proposal
Date: Thu, 24 Jan 2019 22:54:14 +0530

In my opinion, here are some improvements that the logger needs.

The logger needs to have a facility of logging directly into a file.

We can also involve macros like __func__, __LINE__, __FILE__,(or also  __FUNCTION__ and __PRETTY_FUNCTION__) 
for logging. As in gdb, printing line numbers and file names are pretty helpful, IMO.
This way we also won't need to change line numbers in log statements if we change 
the code. (if we code log statements in this way)

We can also display log timings. There are certain bug reports like #54257 and #43248
that say rendering is slow. In such a case, log timings will definitely help us
in knowing how well we have been in improving speed. This can also help us test speed optimizations
in code.

We also need a log-config file and a flexible logging pattern. The state-of-the-art loggers usually have a 
file that configures logging. This file is used in specifying where to log into and logging patterns.

The paper http://opera.ucsd.edu/paper/log_icse12.pdf says on an average, codes have one line of logging 
for every 30 lines of non-logging code. I think freetype needs little more logging statements. 
The paper also says "we find that they often do not make the log messages right in their first attempts, and 
thus need to spend a significant amount of efforts 
to modify the log messages as after-thoughts". This also suggests a need to regularly revise log statements.  

On Wed, Jan 23, 2019 at 8:22 PM Dmitry Timoshkov <address@hidden> wrote:
<address@hidden> wrote:

> > Also, obviously there is no point in inventing new dependencies for such a
> > simple thing as logging.
>
> This is probably where I disagree the most.  Logging/tracing in itself is
> far more than "a simply thing";  it is a tremendous debugging tool (when
> done right).  Instructions that are (1) dead easy to insert and (2) generate
> output that is spot-on for whatever you're looking for in any specific
> situation can make the difference between firing up `gdb' or finding an
> issue within a few seconds.  The current logger is great, but there are far
> better solutions out there.

It would be helpful to list the things that the developers would like
to see changed in the current logger, especially since it's already
great.

--
Dmitry.

reply via email to

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