Hi,
> Armin, Nikhil, wasn't there a plan to set up a FreeType mirror? Could
> you do that?
Here are some possible ways we could do this:
1. Set up a server side post-receive hook so that all commits are
pushed to the mirror immediately.
2. Set up a cron job server side to push commits at a
> I think everyone might be fine with these ideas, simply because,
> they don't even require an external library.
Some of them, however, are *not* easy to do right since you need quite
an intimate knowledge of the whole library to get decent results.
> These features will surely be helpful for
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
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).
> There's a simple rule: don't try to fix something that is not broken.
I 100% agree. However, as Werner and I have pointed out earlier, there are
a few issues with the current implementation of the logger. At least, there
are things that could clearly be improved.
> Another consideration
wrote:
> >> Well, as far as I can see, it's exactly as Armin described the
> >> situation: people insert `printf' statements for debugging. And the
> >> final code usually missed important debugging calls...
> >
> > How does that justify adding new logging library or changing the current
> >
>> Well, as far as I can see, it's exactly as Armin described the
>> situation: people insert `printf' statements for debugging. And the
>> final code usually missed important debugging calls...
>
> How does that justify adding new logging library or changing the current
> logger code? That
>> > I mean that even if a GSoC student working on adding some
>> > functionality to Freetype (and who apparently was new to
>> > Freetype) never complained about the logging functionality then
>> > the logging code is not a problem at all.
>>
>> Well, as far as I can see, it's exactly as Armin
Werner LEMBERG wrote:
> >> > For instance has anyone heard anything about the logger during
> >> > last years GSoC?
> >>
> >> The idea to add a logger library is just a few months old.
> >
> > I mean that even if a GSoC student working on adding some
> > functionality to Freetype (and who
>> > If a developer believes that she/he needs to change the logger of
>> > a project she/he starts to work with - that's good sign that this
>> > developer has slightly distorted priorities.
>>
>> Well, it is a nice GSoC project IMHO. Not that I would implement it
>> by myself...
>
> Current
Werner LEMBERG wrote:
> > If a developer believes that she/he needs to change the logger of a
> > project she/he starts to work with - that's good sign that this
> > developer has slightly distorted priorities.
>
> Well, it is a nice GSoC project IMHO. Not that I would implement it
> by
>> Of course. Only if some preprocessor macros are defined at configure
>> time, this feature is available – I won't change that. In other
>> words, it will stay as a developer-only feature.
>
> Right. Which makes using en external library overkill.
Not really, you want your logger to be as
(disclaimer: personal opinions and personal preferences ahead!)
> Since I was working on adding support for Windows fonts to Freetype, and I
had
> to use the Freetype built-in logging facilities probably I could share a
bit
> my own experience of using it. First of all the Freetype logger is
Werner LEMBERG wrote:
> >> I want to work on your project titled "Replace FreeType's tracing
> >> and debugging facilities with an external logging library". You
> >> have mentioned that there are platforms where stderr is not
> >> accessible. Can you give me an example of such a platform?
>
>> Windows in GUI mode.
>
> First of all the Freetype logger is perfectly sufficient for
> productive work.
Mhmm.
> If a developer believes that she/he needs to change the logger of a
> project she/he starts to work with - that's good sign that this
> developer has slightly distorted
> Also, I recall some formatting discussions somewhen last year (I
> don't know exactly when that was); IIRC Werner proposed a new output
> formatting but ran against a wall there.
What I want is the ability to output the component and level a
debugging message belongs (a bit similar to what
> That's all I can think about it for the moment ... if I come across
something
> else I will add it to the thread.
To keep this memo board somewhat complete: a key aspect of the logger
should also be the ease of "extegration"; meaning the logger has to be
compiled out completely by default
> @Werner: I just checked https://www.freetype.org/gsoc.html and, if
> you like, I can try to briefly (!) summarise more details to make it
> easier to understand the challenges (and possible approach) when
> choosing this project?
Please do so, thanks in advance! Simply send me a diff that I
>> Of course. Only if some preprocessor macros are defined at
>> configure time, this feature is available – I won't change that.
>> In other words, it will stay as a developer-only feature.
>
> Right. Which makes using en external library overkill.
Mhmm, I don't think so – while Armin was
On Tue, Jan 22, 2019 at 11:47 AM Werner LEMBERG wrote:
>
> Of course. Only if some preprocessor macros are defined at configure
> time, this feature is available – I won't change that. In other
> words, it will stay as a developer-only feature.
Right. Which makes using en external library
Hehe I was just preparing a detailed answer myself to bridge the gap until you
have time to answer ... but you beat me ;)
Also: hi Yash, welcome to FreeType :)
>>> Anyways, a simple solution to an inaccessible stderr is to print log
>>> messages directly into a file. Our code will work
>> I want to work on your project titled "Replace FreeType's tracing
>> and debugging facilities with an external logging library". You
>> have mentioned that there are platforms where stderr is not
>> accessible. Can you give me an example of such a platform?
Windows in GUI mode.
>> Anyways,
> Please don't use an external library. Logging in FreeType is for developers
> only, and some parts maybe for font designers. Clients who just want to
> render text don't need the logging capabilities. Just keep it simple.
Obviously a logging library has to be completely compiled out by
Werner,
Please don't use an external library. Logging in FreeType is for
developers only, and some parts maybe for font designers. Clients who just
want to render text don't need the logging capabilities. Just keep it
simple.
On Mon, Jan 21, 2019 at 4:35 PM Yash Khasbage
wrote:
> Hi
> I
Hi
I want to work on your project titled "Replace FreeType's tracing and
debugging facilities with an external logging library". You have mentioned
that there are platforms where stderr is not accessible. Can you give me an
example of such a platform?
Anyways, a simple solution to an inaccessible
25 matches
Mail list logo
