*> Oh yes, you can! Either you modify the source code of 'dlg' within>
FreeType, or – which is better IMHO – you submit a feature request or>
patch to the 'dlg' maintainers that allows control of the '{' and '}'>
characters for marking tags. I see no reason why this must be> hard-coded.*
Ok, I will talk to the dlg's maintainer about this, but in the meantime
could
you provide me the format in which you want the log messages to be printed.
Along with this, please share your thoughts on how you want to toggle the
TimeStamp
and FT_COMPONENT features...
Thanks,
Priyesh
On Mon, Jul 6, 2020 at 3:32 PM Werner LEMBERG <[email protected]> wrote:
>
> >> Of course. Please send a separate patch for these fixed so that I
> >> can apply it to master directly.
> >
> > Ok, I will provide you the patch once done...
>
> Thanks.
>
> >> Very nice! Do you have some data how large the slowdown is due to
> >> the additional code?
> >
> > No, As I haven't done software profiling before this... But I will
> > try it and provide you the required data...
>
> :-)
>
> >> I want
> >> [stream] ...
> >
> > It is indeed possible... dlg uses a feature flag (where user can
> > provide different features joined using the binary OR operator) to
> > control what needs to be printed along with actual log message (Time
> > Stamp, Tags, etc). Therefore we could check if `show_modules`
> > string is present in the `FT2_DEBUG` env and update the flag
> > accordingly.
>
> OK.
>
> > But, we cannot remove curly braces enclosing FT_COMPONENT as I am
> > using dlg_tags to print the FT_COMPONENT value and it is the default
> > way of dlg to output tags. Therefore, we could make Time Stamp and
> > FT_COMPONENT toggleable based on strings passed in `FT2_DEBUG` env
> > but cannot change the way in which they are printed.
>
> Oh yes, you can! Either you modify the source code of 'dlg' within
> FreeType, or – which is better IMHO – you submit a feature request or
> patch to the 'dlg' maintainers that allows control of the '{' and '}'
> characters for marking tags. I see no reason why this must be
> hard-coded.
>
>
> Werner
>
