Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
I have written the Final Report for my project @here

Please take a look at it and provide feedback...

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> So, I have updated the code in `GSoC-2020-priyesh' branch such that
> there are no separate project files for building dlg,

Thanks.

> in this branch I have used the `dlgwrap.c' method, [...]

OK.

> I have also pushed all the changes in this new branch, Please take a
> look at that and let me know if there are any concerns.

It works, great, AFAICS!  Two minor things.

* Under GNU/Linux the `dlg` library needs pthread.  Please fix
  building the demo tools in `make devel` mode by adding the attached
  patch to a branch.

  It would be great if you could also update FreeType's
  `builds/unix/configure.raw` file to check for working pthread
  support.

* Right now I get, for example,

[objs]FT_Open_Face: Requesting number of faces and named instances
[io]FT_Stream_Open: opened `zapf.cff' (329 bytes) successfully
[ttobjs]TTF driver
[ttobjs]  SFNT driver
[sfobjs]  not a font using the SFNT container format
[t1objs]Type 1 driver

  However, I would like to have

[objs]  FT_Open_Face: Requesting number of faces and named instances
[io]FT_Stream_Open: opened `zapf.cff' (329 bytes) successfully
[ttobjs]TTF driver
[ttobjs]  SFNT driver
[sfobjs]  not a font using the SFNT container format
[t1objs]Type 1 driver

  In other words, I want that all tags a constant width for better
  vertical alignment.


Werner
diff --git a/Makefile b/Makefile
index 851c4f7..e63880e 100644
--- a/Makefile
+++ b/Makefile
@@ -172,7 +172,7 @@ else
   else
 LINK_CMD = $(CC) $(subst /,$(COMPILER_SEP),$(LDFLAGS))
 ifeq ($(PLATFORM),unixdev)
-  LINK_LIBS := $(subst /,$(COMPILER_SEP),$(FTLIB) $(EFENCE)) -lm -lrt -lz -lbz2
+  LINK_LIBS := $(subst /,$(COMPILER_SEP),$(FTLIB) $(EFENCE)) -lm -lrt -lz -lbz2 -lpthread
   LINK_LIBS += $(shell pkg-config --libs libpng)
   LINK_LIBS += $(shell pkg-config --libs harfbuzz)
   LINK_LIBS += $(shell pkg-config --libs libbrotlidec)

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,




*> * I wonder whether it is necessary to have a separate `dlg.vcxproj`>
file (and friends).  What about folding its contents into>
`freetype.vcxproj`?  The `dlg` stuff gets completely integrated into>
FreeType and will be always linked statically...*

So, I have updated the code in `GSoC-2020-priyesh' branch such that
there are no separate project files for building dlg, in this branch
I have used the `dlgwrap.c' method, now dlg is compiled along with FreeType
only for `Debug' and `Debug Release' configurations on Windows if
`FT_LOGGING' macro is defined.

I have also pushed all the changes in this new branch,
Please take a look at that and let me know if there are any concerns.


Thanks,
Priyesh

On Tue, Aug 25, 2020 at 11:45 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > I have updated the FreeType's code in accordance with the recent
> > changes in the dlg library and again tested the code on
> > Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).
>
> thanks!
>
> > I wanted to ask that is there something else which I have to take
> > care of?  or should I proceed towards writing the final report?
>
> In addition to the final report you should do two things.
>
> (1) Rebase your code to current 'master'.
>
> (2) Create a new branch that presents your code in an ordered fashion,
> this is, using not-too-large, concise, well documented commits
> that makes it easy to understand how your project works.  Have a
> look how Anuj is doing this to get an idea.
>
> While doing so, please check the code and documentation
> formatting.
>
> - Two spaces after a full stop.
> - Source code files should always have a newline character at the
>   very end (again an editor setting).
> - Avoid trailing whitespace (this should be an editor setting)
> - Don't precede tab characters with spaces (again an editor
>   setting).
>
> If you do, for example,
>
>   git diff master
>
> on the command line then trailing whitespace is marked in red, and
> right now you will see *a lot* of red boxes :-)
>
>
> Some comments regarding the code.
>
> * I wonder whether it is necessary to have a separate `dlg.vcxproj`
>   file (and friends).  What about folding its contents into
>   `freetype.vcxproj`?  The `dlg` stuff gets completely integrated into
>   FreeType and will be always linked statically...
>
>   Am I missing something?
>
> * I expect that
>
> FT_LOGGING_FILE=/dev/stderr
>
>   works to emit data to stderr.  It should probably be documented.
>
> * Please keep `devel/ftoption.h` in sync with
>   `include/freetype/config/ftoption.h`.  Right now, the former lacks
>   `FT_LOGGING`.  Note that the devel version should have FT_LOGGING
>   activated by default, while the standard one should not.
>
> * Have you checked that `make refdoc` builds ok, and that your
>   `debugging_apis` stuff is properly displayed as HTML in the API
>   documentation?
>
> * For function definitions (and especially API functions), always use
>   one argument per line.  This is, don't write
>
> int foo( char  bar, void  *baz )
>
>   but
>
> int
> foo( char   bar,
>  void  *baz )
>
> * Have you ensured that the `dlg` files are compiled into the library
>   only if `FT_LOGGING` is defined?  As far as I can see, this is not
>   the case yet.
>
>   Two possible solutions
>
>   - Adjust the copying process from the 'dlg' sub-repository to
> `src/dlg`, for example do
>
>   echo "#ifdef FT_LOGGING" > dlg.c
>   echo>> dlg.c
>   cat submodules/dlg/src/dlg/dlg.c>> dlg.c
>   echo>> dlg.c
>   echo "#else /* !FT_LOGGING */"  >> dlg.c
>   echo "/* ANSI C doesn't like empty source files */" >> dlg.c
>   echo "  typedef int  _dlg_dummy;"   >> dlg.c
>   echo>> dlg.c
>   echo "#endif /* !FT_LOGGING */" >> dlg.c
>
> You might use the `sed` program instead of `echo` and `cat`.
>
>   - Create a wrapper file (say, `dlgwrap.c`) that contains
>
>   #ifdef FT_LOGGING
>   #  include "dlg.c"
>   #else
> /* ANSI C doesn't like empty source files */
> typedef int  _dlg_dummy;
>   #endif
>
> and compile this instead.
>
> * In `toplevel.mk`, change
>
> # For builds that don't use `./configure' script ...
>
>   to
>
> # For builds directly from the git repository ...
>
>
>Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

>>Create a new branch that presents your code in an ordered
>>fashion, this is, using not-too-large, concise, well documented
>>commits that makes it easy to understand how your project works.
>>Have a look how Anuj is doing this to get an idea.  While doing
>>so, please check the code and documentation formatting.
>>- Two spaces after a full stop.
>>- Source code files should always have a newline character at
>>  the very end (again an editor setting).
>>- Avoid trailing whitespace (this should be an editor setting)
>>- Don't precede tab characters with spaces (again an editor
>>  setting).
> 
> Is there a git way to do it or do I have to manually order changes
> and do commits?

This is a manual job.  You take the final code, split it into smaller,
logical chunks that get committed separately (taking care that each
commit is compilable).  In other words, you replace your 40+ commits
with, say, less than 10.

>> I wonder whether it is necessary to have a separate `dlg.vcxproj`
>> file (and friends).  What about folding its contents into
>> `freetype.vcxproj`?  The `dlg` stuff gets completely integrated
>> into FreeType and will be always linked statically...
>
> I have made a separate project for dlg, as for the release
> builds(Release Static and Release) it would be easy to not compile
> the dlg's code just by simply skipping the dlg project and building
> only the FreeType project.

My knowledge is too limited to have a qualified opinion.  Alexei?

> Ok, I will use the dlgwrap.c method, for this we also have to
> include file `freetype.h' right?

Please include whatever is necessary :-)


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,











*> Create a new branch that presents your code in an ordered fashion,>
this is, using not-too-large, concise, well documented commits>that
makes it easy to understand how your project works.  Have a>look how
Anuj is doing this to get an idea.>While doing so, please check the
code and documentation>formatting.>- Two spaces after a full
stop.>- Source code files should always have a newline character at
the>  very end (again an editor setting).>- Avoid trailing
whitespace (this should be an editor setting)>- Don't precede tab
characters with spaces (again an editor>  setting).*

Is there a git way to do it or do I have to manually order changes and do
commits?






*> I wonder whether it is necessary to have a separate `dlg.vcxproj`>  file
(and friends).  What about folding its contents into>  `freetype.vcxproj`?
The `dlg` stuff gets completely integrated into>  FreeType and will be
always linked statically...>  Am I missing something?*
I have made a separate project for dlg, as for the release builds(Release
Static and Release)
it would be easy to not compile the dlg's code just by simply skipping the
dlg project and
building only the FreeType project.




*> * I expect that>FT_LOGGING_FILE=/dev/stderr>  works to emit data to
stderr.  It should probably be documented.*
Yes, it works, will update this in documentation...




*> Please keep `devel/ftoption.h` in sync with>
 `include/freetype/config/ftoption.h`.  Right now, the former lacks>
 `FT_LOGGING`.  Note that the devel version should have FT_LOGGING>
 activated by default, while the standard one should not*
Ok.



*> Have you checked that `make refdoc` builds ok, and that your>
`debugging_apis` stuff is properly displayed as HTML in the API>
documentation?*
Yes, it is working properly.








*> For function definitions (and especially API functions), always use>
 one argument per line.  This is, don't write>int foo( char  bar, void
*baz )>   but>int>foo( char   bar,> void  *baz )*
Ok.



*> Have you ensured that the `dlg` files are compiled into the library>
only if `FT_LOGGING` is defined?  As far as I can see, this is not>  the
case yet[...]*
Ok, I will use the dlgwrap.c method, for this we also have to include
file `freetype.h' right?




*> In `toplevel.mk `, change># For builds that
don't use `./configure' script ...>  to># For builds directly from the
git repository .*
Updated, thanks.

On Tue, Aug 25, 2020 at 11:45 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > I have updated the FreeType's code in accordance with the recent
> > changes in the dlg library and again tested the code on
> > Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).
>
> thanks!
>
> > I wanted to ask that is there something else which I have to take
> > care of?  or should I proceed towards writing the final report?
>
> In addition to the final report you should do two things.
>
> (1) Rebase your code to current 'master'.
>
> (2) Create a new branch that presents your code in an ordered fashion,
> this is, using not-too-large, concise, well documented commits
> that makes it easy to understand how your project works.  Have a
> look how Anuj is doing this to get an idea.
>
> While doing so, please check the code and documentation
> formatting.
>
> - Two spaces after a full stop.
> - Source code files should always have a newline character at the
>   very end (again an editor setting).
> - Avoid trailing whitespace (this should be an editor setting)
> - Don't precede tab characters with spaces (again an editor
>   setting).
>
> If you do, for example,
>
>   git diff master
>
> on the command line then trailing whitespace is marked in red, and
> right now you will see *a lot* of red boxes :-)
>
>
> Some comments regarding the code.
>
> * I wonder whether it is necessary to have a separate `dlg.vcxproj`
>   file (and friends).  What about folding its contents into
>   `freetype.vcxproj`?  The `dlg` stuff gets completely integrated into
>   FreeType and will be always linked statically...
>
>   Am I missing something?
>
> * I expect that
>
> FT_LOGGING_FILE=/dev/stderr
>
>   works to emit data to stderr.  It should probably be documented.
>
> * Please keep `devel/ftoption.h` in sync with
>   `include/freetype/config/ftoption.h`.  Right now, the former lacks
>   `FT_LOGGING`.  Note that the devel version should have FT_LOGGING
>   activated by default, while the standard one should not.
>
> * Have you checked that `make refdoc` builds ok, and that your
>   `debugging_apis` stuff is properly displayed as HTML in the API
>   documentation?
>
> * For function definitions (and especially API functions), always use
>   one argument per line.  This is, don't write
>
> int foo( char  bar, void  *baz )
>
>   but
>
> int
> foo( char   bar,
>  void  *baz )
>
> * Have you 

Re: Logging Library-GSOC

[Werner LEMBERG]

Hello Priyesh,


> I have updated the FreeType's code in accordance with the recent
> changes in the dlg library and again tested the code on
> Linux(Autotools), Windows(Visual Studios), and on OS X(Autotools).

thanks!

> I wanted to ask that is there something else which I have to take
> care of?  or should I proceed towards writing the final report?

In addition to the final report you should do two things.

(1) Rebase your code to current 'master'.

(2) Create a new branch that presents your code in an ordered fashion,
this is, using not-too-large, concise, well documented commits
that makes it easy to understand how your project works.  Have a
look how Anuj is doing this to get an idea.

While doing so, please check the code and documentation
formatting.

- Two spaces after a full stop.
- Source code files should always have a newline character at the
  very end (again an editor setting).
- Avoid trailing whitespace (this should be an editor setting)
- Don't precede tab characters with spaces (again an editor
  setting).

If you do, for example,

  git diff master

on the command line then trailing whitespace is marked in red, and
right now you will see *a lot* of red boxes :-)


Some comments regarding the code.

* I wonder whether it is necessary to have a separate `dlg.vcxproj`
  file (and friends).  What about folding its contents into
  `freetype.vcxproj`?  The `dlg` stuff gets completely integrated into
  FreeType and will be always linked statically...

  Am I missing something?

* I expect that

FT_LOGGING_FILE=/dev/stderr

  works to emit data to stderr.  It should probably be documented.

* Please keep `devel/ftoption.h` in sync with
  `include/freetype/config/ftoption.h`.  Right now, the former lacks
  `FT_LOGGING`.  Note that the devel version should have FT_LOGGING
  activated by default, while the standard one should not.

* Have you checked that `make refdoc` builds ok, and that your
  `debugging_apis` stuff is properly displayed as HTML in the API
  documentation?

* For function definitions (and especially API functions), always use
  one argument per line.  This is, don't write

int foo( char  bar, void  *baz )

  but

int
foo( char   bar,
 void  *baz )

* Have you ensured that the `dlg` files are compiled into the library
  only if `FT_LOGGING` is defined?  As far as I can see, this is not
  the case yet.

  Two possible solutions

  - Adjust the copying process from the 'dlg' sub-repository to
`src/dlg`, for example do

  echo "#ifdef FT_LOGGING" > dlg.c
  echo>> dlg.c
  cat submodules/dlg/src/dlg/dlg.c>> dlg.c
  echo>> dlg.c
  echo "#else /* !FT_LOGGING */"  >> dlg.c
  echo "/* ANSI C doesn't like empty source files */" >> dlg.c
  echo "  typedef int  _dlg_dummy;"   >> dlg.c
  echo>> dlg.c
  echo "#endif /* !FT_LOGGING */" >> dlg.c

You might use the `sed` program instead of `echo` and `cat`.

  - Create a wrapper file (say, `dlgwrap.c`) that contains

  #ifdef FT_LOGGING
  #  include "dlg.c"
  #else
/* ANSI C doesn't like empty source files */
typedef int  _dlg_dummy;
  #endif

and compile this instead.

* In `toplevel.mk`, change

# For builds that don't use `./configure' script ...

  to

# For builds directly from the git repository ...


   Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have tested the changes on OS X using Autotools i.e by using:
>
>   sh autogen.sh
>   ./configure
>   make
>
> I know FreeType mainly uses Autotools for building purposes and here
> I wanted to ask that other than Autotools are there some other tools
> with which I need to build FreeType and test the changes on OS X?

There is no special support for OS X; we only have autotools and cmake
(the latter only supported by user contributions).  Hopefully we will
have meson support in the near future.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Vincent,

*> If you want I can tell you how I compile freetype on Windows using>
MSYS2 and mingw-w64 (or even on linux with cross compilation)*
Thanks for your help.
I have already tested the changes using MSYS2 on Windows.
But I do have a question.
When I use Autotools to build FreeType on Linux, the build process produces
both static library(*libfreetype.a) *and shared library(*libfreetype.so).*
But when I am building FreeType using MSYS2 and mingw32-make on Windows
I am getting only a static library(freetype.a). Is this a default behavior
or I am doing something wrong?

Thanks,
Priyesh

On Wed, Aug 19, 2020 at 12:39 AM Vincent Torri 
wrote:

> Hello,
>
> On Tue, Aug 18, 2020 at 1:03 PM Priyesh kumar 
> wrote:
> >
> > Hi Werner,
> > I was trying to compile FreeType on Windows using Cygwin and I was
> > getting the following error while executing `sh autogen.sh' command even
> > though I have installed the required packages from the Cygwin package
> installer:
> > --
> >
> > Can't locate Automake/Config.pm in @INC (you may need to install the
> Automake::Config module) (@INC contains: /usr/share/automake-1.16
> /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_p
> >
> > erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl
> /usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.
> >
> > --
> > The commands like `make devel;make' which do not use `sh autogen.sh'
> script are executing fine...
> > I have searched about this error online but didn't get any helpful
> answers.
> > Could you please take a look at it as it the only remaining platform to
> test the changes.
>
> If you want I can tell you how I compile freetype on Windows using
> MSYS2 and mingw-w64 (or even on linux with cross compilation)
>
> regards
>
> Vincent Torri
>

Re: Logging Library-GSOC

[Priyesh kumar]

*> IMHO it's not worth that you examine this in more detail**.*
Ok...

*> No idea.  What exactly are you interested in?*
I have tested the changes on OS X using Autotools i.e by using:
*sh autogen.sh*
*./configure*
*make*
I know FreeType mainly uses Autotools for building purposes and
here I wanted to ask that other than Autotools are there some other tools
with which I need to build FreeType and test the changes on OS X?

Thanks,
Priyesh

On Tue, Aug 18, 2020 at 11:25 PM Werner LEMBERG  wrote:

>
> > I was trying to compile FreeType on Windows using Cygwin and I was
> > getting the following error while executing `sh autogen.sh' command
> > even though I have installed the required packages from the Cygwin
> > package installer:
> > --
> >
> >
> > *Can't locate Automake/Config.pm in @INC (you may need to install the
> > Automake::Config module) (@INC contains: /usr/share/automake-1.16
> > /usr/lib/perl5/site_perl /usr/share/perl5/site_perl
> > /usr/lib/perl5/vendor_p*
> >
> > *erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl
> > /usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.*
> >
> > --
>
> Obviously there is a problem with Perl.  No idea how to solve it,
> sorry.  In case you can't generate the `configure` script simply copy
> it to your Cygwin environment from, say, your GNU/Linux box.
>
> We don't guarantee that a build directly from the git repository works
> on all platforms.  However, the tarball created by `make dist` should
> work.
>
> > I have searched about this error online but didn't get any helpful
> > answers.  Could you please take a look at it as it the only
> > remaining platform to test the changes.
>
> IMHO it's not worth that you examine this in more detail.
>
> > I also wanted to ask that other than using `make' and `cmake' is
> > there some other way to compile FreeType on Mac platforms?
>
> No idea.  What exactly are you interested in?
>
> > After this, I will proceed towards updating the `docs/DEBUG' file
> > and wrap up the project.
>
> Thanks!
>
>
> Werner
>

Re: Logging Library-GSOC

[Vincent Torri]

Hello,

On Tue, Aug 18, 2020 at 1:03 PM Priyesh kumar  wrote:
>
> Hi Werner,
> I was trying to compile FreeType on Windows using Cygwin and I was
> getting the following error while executing `sh autogen.sh' command even
> though I have installed the required packages from the Cygwin package 
> installer:
> --
>
> Can't locate Automake/Config.pm in @INC (you may need to install the 
> Automake::Config module) (@INC contains: /usr/share/automake-1.16 
> /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_p
>
> erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl 
> /usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.
>
> --
> The commands like `make devel;make' which do not use `sh autogen.sh' script 
> are executing fine...
> I have searched about this error online but didn't get any helpful answers.
> Could you please take a look at it as it the only remaining platform to test 
> the changes.

If you want I can tell you how I compile freetype on Windows using
MSYS2 and mingw-w64 (or even on linux with cross compilation)

regards

Vincent Torri

Re: Logging Library-GSOC

[Werner LEMBERG]

> I was trying to compile FreeType on Windows using Cygwin and I was
> getting the following error while executing `sh autogen.sh' command
> even though I have installed the required packages from the Cygwin
> package installer:
> --
> 
> 
> *Can't locate Automake/Config.pm in @INC (you may need to install the
> Automake::Config module) (@INC contains: /usr/share/automake-1.16
> /usr/lib/perl5/site_perl /usr/share/perl5/site_perl
> /usr/lib/perl5/vendor_p*
> 
> *erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl
> /usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.*
> 
> --

Obviously there is a problem with Perl.  No idea how to solve it,
sorry.  In case you can't generate the `configure` script simply copy
it to your Cygwin environment from, say, your GNU/Linux box.

We don't guarantee that a build directly from the git repository works
on all platforms.  However, the tarball created by `make dist` should
work.

> I have searched about this error online but didn't get any helpful
> answers.  Could you please take a look at it as it the only
> remaining platform to test the changes.

IMHO it's not worth that you examine this in more detail.

> I also wanted to ask that other than using `make' and `cmake' is
> there some other way to compile FreeType on Mac platforms?

No idea.  What exactly are you interested in?

> After this, I will proceed towards updating the `docs/DEBUG' file
> and wrap up the project.

Thanks!


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
I was trying to compile FreeType on Windows using Cygwin and I was
getting the following error while executing `sh autogen.sh' command even
though I have installed the required packages from the Cygwin package
installer:
--


*Can't locate Automake/Config.pm in @INC (you may need to install the
Automake::Config module) (@INC contains: /usr/share/automake-1.16
/usr/lib/perl5/site_perl /usr/share/perl5/site_perl
/usr/lib/perl5/vendor_p*

*erl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl
/usr/share/perl5/core_perl) at /c/cygwin/bin/aclocal-1.16 line 36.*

--
The commands like `make devel;make' which do not use `sh autogen.sh' script
are executing fine...
I have searched about this error online but didn't get any helpful answers.
Could you please take a look at it as it the only remaining platform to
test the changes.

I also wanted to ask that other than using `make' and `cmake' is there some
other way to compile FreeType on Mac platforms?
After this, I will proceed towards updating the `docs/DEBUG' file and wrap
up the project.

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> With my last commit dlg's Visual Studios project is only built for
> `Debug' and `Debug Static' configurations on both `x64' and `Win32'
> platforms.  For `Release' and `Release Static' builds, dlg's build
> is skipped.

This sounds completely correct.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Alexei,

*> I am sorry I was not following your logging project closely enough. So>
I asked the most general question.*
Ok, no problem at all :-)

*> What is the difference between submodules and modules?*
As part of this project, I have to integrate an Open Source logging library
in FreeType to print
tracing and other log messages to a file instead of stderr, for debugging
purposes.
Since dlg is a third party library and it uses a Meson build system for
building purposes, Werner suggested
me to first checkout dlg in a separate directory: `submodules/dlg'
(`submodules' as for git submodule), and afterward,
copy the necessary files to `src/dlg'.
The directory `src/dlg' would contain a `rules.mk' file to build dlg along
with FreeType,
whenever FreeType is configured with a macro `FT_LOGGING' present in
`include/freetype/config/ftoption.h'.

> *Is this the mechanism to turn it on/off?*
Therefore, the printing of tracing and other logs is totally controlled by
`FT_LOGGING' macro in
`include/freetype/config/ftoption.h' on both Windows and UNIX platforms.

Please, let me know if there are any other concerns regarding my project.


*> It is probably ok to have it enabled only in Debug builds (or make>
devel). But there must be a way to disable it altogether.*
With my last commit dlg's Visual Studios project is only built for `Debug'
and `Debug Static' configurations on both `x64' and `Win32' platforms.
For `Release' and `Release Static' builds, dlg's build is skipped.
I wanted to check if I have set up the dlg's Visual Studios Project on
Windows correctly?
Especially, for Release builds of FreeType, is simply skipping dlg project
the right way to not build dlg, or is there some other way around?
Please guide me...

Thanks,
Priyesh


On Tue, Aug 4, 2020 at 5:17 PM Alexei Podtelezhnikov 
wrote:

> Hi Pryiesh,
>
> I am sorry I was not following your logging project closely enough. So
> I asked the most general question.
>
> On Tue, Aug 4, 2020 at 7:32 AM Priyesh kumar 
> wrote:
> >
> > Hi Alexei,
> > Thanks for replying.
> >
> > > It looks ok as far as clean separation. I don't quite understand why
> > > you need to copy files
> > In one of the previous mail about building dlg on Linux, Werner
> > suggested me to first copy necessary files from `submodules/dlg' to
> > `src/dlg' and then use a rules.mk file to build dlg.
> > Therefore, I thought to set up the same directory hierarchy on windows
> also.
>
> Is this the mechanism to turn it on/off? What is the difference
> between submodules and modules?
>
> > > and how to disable dlg.
> > I didn't understand your concern here...
> > Are you asking about skipping dlg build in `Release' and `Release
> Static' builds?
>
> It is probably ok to have it enabled only in Debug builds (or make
> devel). But there must be a way to disable it altogether.
>
> Alexei
>

Re: Logging Library-GSOC

[Alexei Podtelezhnikov]

Hi Pryiesh,

I am sorry I was not following your logging project closely enough. So
I asked the most general question.

On Tue, Aug 4, 2020 at 7:32 AM Priyesh kumar  wrote:
>
> Hi Alexei,
> Thanks for replying.
>
> > It looks ok as far as clean separation. I don't quite understand why
> > you need to copy files
> In one of the previous mail about building dlg on Linux, Werner
> suggested me to first copy necessary files from `submodules/dlg' to
> `src/dlg' and then use a rules.mk file to build dlg.
> Therefore, I thought to set up the same directory hierarchy on windows also.

Is this the mechanism to turn it on/off? What is the difference
between submodules and modules?

> > and how to disable dlg.
> I didn't understand your concern here...
> Are you asking about skipping dlg build in `Release' and `Release Static' 
> builds?

It is probably ok to have it enabled only in Debug builds (or make
devel). But there must be a way to disable it altogether.

Alexei

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Alexei,
Thanks for replying.

> It looks ok as far as clean separation. I don't quite understand why
> you need to copy files
In one of the previous mail about building dlg on Linux, Werner
suggested me to first copy necessary files from `submodules/dlg' to
`src/dlg' and then use a rules.mk file to build dlg.
Therefore, I thought to set up the same directory hierarchy on windows also.

> and how to disable dlg.
I didn't understand your concern here...
Are you asking about skipping dlg build in `Release' and `Release Static'
builds?

Thanks,
Priyesh


On Mon, Aug 3, 2020 at 10:43 PM Alexei Podtelezhnikov 
wrote:

> Hi Priyesh
>
> On Mon, Aug 3, 2020 at 10:33 AM Priyesh kumar 
> wrote:
> >
> > Hi Alexei,
> > Is there any update for me regarding Werner's previous mail?
> >> > The dlg project contains two configurations: `Debug' and `Debug
> >> > Static' on both `x64' and `Win32' platforms and will be built with
> >> > FreeType, whenever FreeType is built in these configurations.  I
> >> > have also added a windows batch file which is called as a pre-built
> >> > event whenever dlg is built, and it takes care of copying files from
> >> > `submodules/dlg' to `src/dlg'...  For `Release' and `Release Static'
> >> > builds of FreeType the dlg project build will simply be skipped.
> >>
> >> OK.  Alexei, can you please have a look?  I have no clue about
> >> Visual C, and I guess Priyesh wants to have comments.
>
> It looks ok as far as clean separation. I don't quite understand why
> you need to copy files and how to disable dlg.
>
> Thanks,
> Alexei
>

Re: Logging Library-GSOC

[Alexei Podtelezhnikov]

Hi Priyesh

On Mon, Aug 3, 2020 at 10:33 AM Priyesh kumar  wrote:
>
> Hi Alexei,
> Is there any update for me regarding Werner's previous mail?
>> > The dlg project contains two configurations: `Debug' and `Debug
>> > Static' on both `x64' and `Win32' platforms and will be built with
>> > FreeType, whenever FreeType is built in these configurations.  I
>> > have also added a windows batch file which is called as a pre-built
>> > event whenever dlg is built, and it takes care of copying files from
>> > `submodules/dlg' to `src/dlg'...  For `Release' and `Release Static'
>> > builds of FreeType the dlg project build will simply be skipped.
>>
>> OK.  Alexei, can you please have a look?  I have no clue about
>> Visual C, and I guess Priyesh wants to have comments.

It looks ok as far as clean separation. I don't quite understand why
you need to copy files and how to disable dlg.

Thanks,
Alexei

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Alexei,
Is there any update for me regarding Werner's previous mail?

Thanks,
Priyesh

On Fri, Jul 31, 2020 at 11:42 PM Werner LEMBERG  wrote:

>
> > I have added a project under `builds/windows/vc2010/freetype.sln'
> > file to build dlg along with FreeType on Windows.
>
> Thanks.
>
> > The dlg project contains two configurations: `Debug' and `Debug
> > Static' on both `x64' and `Win32' platforms and will be built with
> > FreeType, whenever FreeType is built in these configurations.  I
> > have also added a windows batch file which is called as a pre-built
> > event whenever dlg is built, and it takes care of copying files from
> > `submodules/dlg' to `src/dlg'...  For `Release' and `Release Static'
> > builds of FreeType the dlg project build will simply be skipped.
>
> OK.  Alexei, can you please have a look?  I have no clue about
> Visual C, and I guess Priyesh wants to have comments.
>
> > And for proceeding further, I wanted to ask that do I have to add
> > the dlg project on other compilers(builds/windows/visualc,
> > builds/windows/visualce) also?
>
> No, not necessary IMHO.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have added a project under `builds/windows/vc2010/freetype.sln'
> file to build dlg along with FreeType on Windows.

Thanks.

> The dlg project contains two configurations: `Debug' and `Debug
> Static' on both `x64' and `Win32' platforms and will be built with
> FreeType, whenever FreeType is built in these configurations.  I
> have also added a windows batch file which is called as a pre-built
> event whenever dlg is built, and it takes care of copying files from
> `submodules/dlg' to `src/dlg'...  For `Release' and `Release Static'
> builds of FreeType the dlg project build will simply be skipped.

OK.  Alexei, can you please have a look?  I have no clue about
Visual C, and I guess Priyesh wants to have comments.

> And for proceeding further, I wanted to ask that do I have to add
> the dlg project on other compilers(builds/windows/visualc,
> builds/windows/visualce) also?

No, not necessary IMHO.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
I have added a project under `builds/windows/vc2010/freetype.sln' file to
build
dlg along with FreeType on Windows.
The dlg project contains two configurations:
`Debug' and `Debug Static' on both `x64' and `Win32' platforms and will be
built
with FreeType, whenever FreeType is built in these configurations.
I have also added a windows batch file which is called as a pre-built event
whenever dlg is built, and
it takes care of copying files from `submodules/dlg' to `src/dlg'...
For `Release' and `Release Static' builds of FreeType the dlg project build
will simply be skipped.
And for proceeding further,
I wanted to ask that do I have to add the dlg project on other
compilers(builds/windows/visualc, builds/windows/visualce) also?

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> I was working on removing the warnings which get triggered after
> enabling macro `FT_LOGGING' in ftoption.h file to use dlg library
> for logging on a file.  If `FT_LOGGING' macro is enabled FT_TRACE
> messages are handled by dlg's API which internally uses a function
> of `printf' like format, therefore, I was getting many [-Wformat=]
> warnings.  I have updated the code locally to handle most of these
> warnings.  But there are several other warnings like which I don't
> know how to fix: [...]

These are now fixed in master.  Thanks for the report!


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I was working on removing the warnings which get triggered after enabling
macro `FT_LOGGING' in
ftoption.h file to use dlg library for logging on a file.
If `FT_LOGGING' macro is enabled FT_TRACE messages are handled by dlg's API
which internally uses
a function of `printf' like format, therefore, I was getting many
[-Wformat=] warnings.
I have updated the code locally to handle most of these warnings.
But there are several other warnings like which I don't know how to fix:

freetype2/src/cache/ftcbasic.c:112:19: warning: too many arguments for
format [-Wformat-extra-args]
  112 |   FT_TRACE1(( "ftc_basic_family_get_count:"
  |   ^
*--*
freetype2/src/smooth/ftgrays.c:499:3: warning: ‘gray_dump_cells’ defined
but not used [-Wunused-function]
  499 |   gray_dump_cells( RAS_ARG )
--
freetype2/src/sfnt/sfwoff2.c:1924:19: warning: too many arguments for
format [-Wformat-extra-args]
 1924 |   FT_TRACE2(( "  %c%c%c%c  %08d  %08d%08ld  %08ld\n",
--
freetype2/src/bdf/bdfdrivr.c:913:23: warning: format ‘%lx’ expects a
matching ‘long unsigned int’ argument [-Wformat]
  913 |   FT_TRACE1(( "bdf_get_bdf_property:"
--
freetype2/src/bdf/bdfdrivr.c:903:23: warning: format ‘%x’ expects a
matching ‘unsigned int’ argument [-Wformat=]
  903 |   FT_TRACE1(( "bdf_get_bdf_property:"
--
freetype2/src/bdf/bdfdrivr.c:186:19: warning: format ‘%x’ expects a
matching ‘unsigned int’ argument [-Wformat=]
  186 |   FT_TRACE1(( "bdf_cmap_char_next: charcode 0x%x > 32bit API"
));
--
freetype2/src/pcf/pcfdrivr.c:610:23: warning: format ‘%x’ expects a
matching ‘unsigned int’ argument [-Wformat=]
  610 |   FT_TRACE1(( " too large integer 0x%x is truncated\n" ));
--
freetype2/src/truetype/ttgxvar.c:1732:21: warning: too many arguments for
format [-Wformat-extra-args]
 1732 | FT_TRACE6(( "  tuple coordinate is zero, ignore\n", i
));
--
freetype2/src/base/ftoutln.c:277:17: warning: too many arguments for format
[-Wformat-extra-args]
  277 | FT_TRACE5(( "FT_Outline_Decompose: Done\n", n ));

Please take a look at this.

Thanks,
Priyesh

On Thu, Jul 23, 2020 at 1:27 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > I have used FT2_DEBUG=any:7 with:
> >
> >   ./test arial.ttf *qwertyuiopasdfghjklzxcvbnm*
> >
> > and I have got following results:
> >
> >   FT_LOGGING:   387ms  (here dlg writes logs to stderr)
> >   FT_DEBUG_LEVEL_TRACE: 305 ms (FreeType writes logs to stderr,
> > no redirection to text file)
>
> Finally some realistic, expected results :-)
>
> > I have also updated `builds/freetype.mk` so that in Linux, dlg is
> > built like rest of the modules in FreeType.
>
> Thanks!
>
> > And I wanted to ask that should I also go ahead add a visual studios
> > project in `src/dlg` to build dlg on windows?  For this, we have to
> > add a Windows command script to copy the files from
> > `submodules/dlg/` to `src/dlg`...
>
> I think this is the right approach.  Alexei?
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

Hello Priyesh,


> I have used FT2_DEBUG=any:7 with:
>
>   ./test arial.ttf *qwertyuiopasdfghjklzxcvbnm*
>
> and I have got following results:
>
>   FT_LOGGING:   387ms  (here dlg writes logs to stderr)
>   FT_DEBUG_LEVEL_TRACE: 305 ms (FreeType writes logs to stderr,
> no redirection to text file)

Finally some realistic, expected results :-)

> I have also updated `builds/freetype.mk` so that in Linux, dlg is
> built like rest of the modules in FreeType.

Thanks!

> And I wanted to ask that should I also go ahead add a visual studios
> project in `src/dlg` to build dlg on windows?  For this, we have to
> add a Windows command script to copy the files from
> `submodules/dlg/` to `src/dlg`...

I think this is the right approach.  Alexei?


Werner

Re: Logging Library-GSOC

[Vincent Torri]

On Tue, Jul 21, 2020 at 6:27 AM Werner LEMBERG  wrote:
>
> > I have also updated the GitHub repo containing this example @ here
> > 
>
> Alas, I don't use Windows so I can't check this.

install on your linux distro mingw-w64 toolchain to compile. Install
wine to test it

Vincent Torri

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,

*> What do your GNU/Linux tests show?*

So, I was analyzing time taken by the example program @ here

and this time for comparison purpose I have made dlg write logs
to stderr.
I have used FT2_DEBUG=any:7 with:
./test arial.ttf *qwertyuiopasdfghjklzxcvbnm*
and I have got following results:
FT_LOGGING: 387ms ( here dlg writes logs to stderr )
FT_DEBUG_LEVEL_TRACE: 305 ms ( FreeType writes logs to stderr, no
redirection to text file)
Please provide feedback...

I have also updated `builds/freetype.mk` so that in Linux, dlg is built
like rest of the
modules in FreeType.
And I wanted to ask that should I also go ahead add a visual studios
project in `src/dlg`
to build dlg on windows?
For this, we have to add a Windows command script to copy the files from
`submodules/dlg/` to `src/dlg`...

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> As suggested by you I have used `setvbuf()` function in
> `FT_Message()` function for printing logs on stderr in Full
> buffering mode when FT_DEBUG_LEVEL_TRACE macro is enabled.  For
> FT2_DEBUG=any:7 and command:
>
>   main.exe arial.ttf *qwertyuiopasdfghjklzxcvbnm *
>
> I have got the following results:
>
>   FT_LOGGING:   8 sec
>   FT_DEBUG_LEVEL_TRACE: 9 sec (stderr logs redirected to a file)

This looks reasonable now, thanks.  I still think, however, that the
difference is mainly due to the redirection.  Theoretically,
`FT_LOGGING` should be a tiny bit slower than `FT_DEBUG_LEVEL_TRACE`
since the former has a larger overhead.

What do your GNU/Linux tests show?

> I have also updated the GitHub repo containing this example @ here
> 

Alas, I don't use Windows so I can't check this.


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have followed the [above] steps to change the `autogen.sh` file,
> so that it copies the files from directory `submodules/dlg` to
> `src/dlg`.

Great, thanks!

> I have also added a `rules.mk` file to `src/dlg` and, for proceeding
> further I wanted to ask that do I have to add a separate target like
> `make submodule` to build the dlg library in some separate directory
> or do I have to hook `src/dlg/rules.mk` file to FreeType so that it
> is built like the rest of the base and modules objects?

The latter, please.  Please remember that a FreeType tarball
essentially captures the state after running `autogen.sh`.  This means
that a normal `make` call should build everything (after people have
fiddled with the macros in `ftconfig.h`).

> And In the (1) point you specified that the directory
> `submodules/dlg` won't be distributed with FreeType tarball, do I
> have to add some code regarding this?

You might have a look at the `dist` target in file
`builds/toplevel.mk`; it probably needs some adjustments to skip
inclusion of the `submodules` directory.  However, this isn't
something urgent.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,

*> I suggest the following.*















*> (1) Use a different directory (for example>
`/submodules/dlg`) for checking out the `dlg`>submodule.
This subdirectory won't get distributed with the>FreeType tarball.> (2)
Create subdirectory `src/dlg`, which only holds a `rules.mk
` file.> (3) Change the `autogen.sh` script to copy the
necessary files from`/submodules/dlg` to `src/dlg`.> (4)
Modify the `setup` target in `builds/toplevel.mk ` to
do the sameas (3).  This is necessary for builds that don't use the
`configure` script (for example `make devel; make`).  Be carefulto use
the right variables like `OBJ_DIR` so that it possible toallow builds
that use a read-only source directory.*

I have followed the above steps to change the `autogen.sh` file,
so that it copies the files from directory `submodules/dlg` to `src/dlg`.
The copying is done if the submodule is already checked out and  if the
submodule is
not checked out the first `git submodule init` and `git submodule update`
commands
are executed and then the files are copied.

I have also added a `rules.mk` file to `src/dlg` and, for proceeding
further I wanted
to ask that do I have to add a separate target like `make submodule` to
build the
dlg library in some separate directory or do I have to hook `src/dlg/
rules.mk` file to
FreeType so that it is built like the rest of the base and modules objects?

And In the (1) point you specified that the directory `submodules/dlg`
won't be distributed
with FreeType tarball, do I have to add some code regarding this?


Thanks,
Priyesh

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
As suggested by you I have used `setvbuf()` function in `FT_Message()`
function
for printing logs on stderr in Full buffering mode when
FT_DEBUG_LEVEL_TRACE macro
is enabled.
For FT2_DEBUG=any:7 and command:
main.exe arial.ttf *qwertyuiopasdfghjklzxcvbnm *
I have got the following results:
FT_LOGGING: 8 sec
FT_DEBUG_LEVEL_TRACE: 9 sec (stderr logs redirected to a file)

I have also updated the GitHub repo containing this example @ here


Please provide feedback...

Thanks,
Priyesh

Re: Logging Library-GSOC

[Priyesh kumar]

*> This still looks fishy.*

Ok, I will try `setvbuf()` function :D


*> Probably yes.  At least the difference between the two approaches>
shouldn't be *that* large, I believe.*


*> Well, for comparison purposes the buffering mode should be the same> for
`FT_LOGGING` and `FT_DEBUG_LEVEL_TRACE*

I will let you know the results after trying the `setvbuf()` function...

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> When I am redirecting stderr logs to a text file using: `main
> arial.ttf qwertyuiopasdfghjklzxcvbnm 2>sdterr_logs.txt` I am getting
> the following results:
>
> `FT_LOGGING`: 8 sec
> `FT_DEBUG_LEVEL_TRACE`: 11 sec

This still looks fishy.

>> Otherwise I guess the big difference between `FT_LOGGING` and
>> `FT_DEBUG_LEVEL_TRACE` is due to file buffering.  In other words,
>> data sent to `stderr` gets output line by line to the screen, which
>> is slow, while data sent to the log file gets buffered completely,
>> and it is written to the disk in asynchronously to avoid write
>> delays.
> 
> I guess this is only the reason for the difference between the time
> values of `FT_LOGGING` and `FT_DEBUG_LEVEL_TRACE`...

Probably yes.  At least the difference between the two approaches
shouldn't be *that* large, I believe.

>> Maybe it makes sense to use C function `setvbuf` to exactly control
>> the buffering mode of the output file descriptor.
> 
> Ok, I will try this one out, but I guess using the `setvbuf()` in no
> buffering mode for writing logs to a file will give the same time
> value as time value produced when logs are written to stderr line by
> line...

Well, for comparison purposes the buffering mode should be the same
for `FT_LOGGING` and `FT_DEBUG_LEVEL_TRACE`.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,


*> This looks very unrealistic.  Do you redirect data sent to stderr to> an
output file?*

No, I haven't redirected the data sent to stderr to an output file, for
measuring time : (
I thought I have to use the time value which I got when data from stderr is
not sent to a .txt file
therefore I have analyzed the time value which I got when data from stderr
was not sent to a .txt file.
When I am redirecting stderr logs to a text file using:
`main arial.ttf *qwertyuiopasdfghjklzxcvbnm* 2>sdterr_logs.txt`
I am getting the following results:
`FT_LOGGING`: 8 sec
`FT_DEBUG_LEVEL_TRACE`: 11 sec





*> Otherwise I guess the big difference between `FT_LOGGING` and>
`FT_DEBUG_LEVEL_TRACE` is due to file buffering.  In other words, data>
sent to `stderr` gets output line by line to the screen, which is> slow,
while data sent to the log file gets buffered completely, and it> is
written to the disk in asynchronously to avoid write delays.*

I guess this is only the reason for the difference between the time values
of `FT_LOGGING`
and `FT_DEBUG_LEVEL_TRACE`...


*> Maybe it makes sense to use C function `setvbuf` to exactly control> the
buffering mode of the output file descriptor.*

Ok, I will try this one out, but I guess using the `setvbuf()` in no
buffering mode for writing logs
to a file will give the same time value as time value produced when logs
are written to stderr line by line...


*> Could you test your program under a Unix-like OS (i.e., GNU/Linux,>
MacOS, other BSD variants), too?*

Ok, I will let you know once done.

Thanks,
Priyesh

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have tried the query performance counter/frequency method for
> example program:
> (https://www.freetype.org/freetype2/docs/tutorial/example1.c) on
> Windows with arial.ttf and FT2_DEBUG=any:7 on
> string:"qwertyuiopasdfghjklzxcvbnm" which produced 24260 logs.
>
> I have executed the test program multiple times and below are the
> average time for each case in seconds:
>
> FT_LOGGING:8 sec ( writes logs to file freetype.log)
> FT_DEBUG_LEVEL_TRACE: 40 sec (writes logs to stderr)
> NO_DEBUGGING:7  sec

This looks very unrealistic.  Do you redirect data sent to stderr to
an output file?

Otherwise I guess the big difference between `FT_LOGGING` and
`FT_DEBUG_LEVEL_TRACE` is due to file buffering.  In other words, data
sent to `stderr` gets output line by line to the screen, which is
slow, while data sent to the log file gets buffered completely, and it
is written to the disk in asynchronously to avoid write delays.

Maybe it makes sense to use C function `setvbuf` to exactly control
the buffering mode of the output file descriptor.

> I have also prepared a test program for this @ here
> 
> , so that if anyone wants to test they can also try and test the
> results...

Could you test your program under a Unix-like OS (i.e., GNU/Linux,
MacOS, other BSD variants), too?


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hello,
I have tried the query performance counter/frequency method for example
program:
(https://www.freetype.org/freetype2/docs/tutorial/example1.c)
on Windows with arial.ttf and FT2_DEBUG=any:7 on
string:"qwertyuiopasdfghjklzxcvbnm"
which produced 24260 logs.
I have executed the test program multiple times and below are the average
time for each case in seconds:
FT_LOGGING:8 sec ( writes logs to file freetype.log)
FT_DEBUG_LEVEL_TRACE: 40 sec (writes logs to stderr)
NO_DEBUGGING:7  sec
I have also prepared a test program for this @ here
 ,
so that if anyone wants to test they can also try and test the results...
The Visual Studios solution contains three different configurations for the
x64 platform:
FT_LOGGING: linked with FreeType library built with FT_LOGGING macro
enabled.
FT_DEBUG_LEVEL_TRACE: linked with FreeType library built with
FT_DEBUG_LEVEL_TRACE macro enabled.
NO_DEBUGGING: linked with release built of FreeType library

Please look into this and provide feedback...

Thanks,
Priyesh




On Thu, Jul 16, 2020 at 11:24 AM Priyesh kumar 
wrote:

> Hi Vincent,
> Thanks for the suggestion it seems very helpful, I will try it and let you
> know in case of any query.
>
> Thanks,
> Priyesh
>
> On Thu, Jul 16, 2020 at 4:14 PM Vincent Torri 
> wrote:
>
>> On Thu, Jul 16, 2020 at 9:51 AM Werner LEMBERG  wrote:
>> >
>> >
>> > >> *Have you set `FT2_DEBUG=any:7` in the environment?*
>> > >
>> > > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
>> > > OpenSans-Bold.ttf font.
>> >
>> > OK.
>> >
>> > > Also, I wanted to ask is this the right approach for profiling?
>> >
>> > I'm not an expert, sorry.  However, you might also try `valgrind
>> > --tool=cachegrind` (on GNU/Linux), which gives you detailed
>> > information on used CPU cycles including instruction and data caches.
>>
>> also
>> valgrind --tool=callgrind + kcachegrind
>> and
>> oprofile could be useful
>>
>> Vincen Torri
>>
>

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Vincent,
Thanks for the suggestion it seems very helpful, I will try it and let you
know in case of any query.

Thanks,
Priyesh

On Thu, Jul 16, 2020 at 4:14 PM Vincent Torri 
wrote:

> On Thu, Jul 16, 2020 at 9:51 AM Werner LEMBERG  wrote:
> >
> >
> > >> *Have you set `FT2_DEBUG=any:7` in the environment?*
> > >
> > > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
> > > OpenSans-Bold.ttf font.
> >
> > OK.
> >
> > > Also, I wanted to ask is this the right approach for profiling?
> >
> > I'm not an expert, sorry.  However, you might also try `valgrind
> > --tool=cachegrind` (on GNU/Linux), which gives you detailed
> > information on used CPU cycles including instruction and data caches.
>
> also
> valgrind --tool=callgrind + kcachegrind
> and
> oprofile could be useful
>
> Vincen Torri
>

Re: Logging Library-GSOC

[Vincent Torri]

On Thu, Jul 16, 2020 at 9:51 AM Werner LEMBERG  wrote:
>
>
> >> *Have you set `FT2_DEBUG=any:7` in the environment?*
> >
> > Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
> > OpenSans-Bold.ttf font.
>
> OK.
>
> > Also, I wanted to ask is this the right approach for profiling?
>
> I'm not an expert, sorry.  However, you might also try `valgrind
> --tool=cachegrind` (on GNU/Linux), which gives you detailed
> information on used CPU cycles including instruction and data caches.

also
valgrind --tool=callgrind + kcachegrind
and
oprofile could be useful

Vincen Torri

Re: Logging Library-GSOC

[Vincent Torri]

On Thu, Jul 16, 2020 at 8:30 AM Priyesh kumar  wrote:
>
> Hi,
> I was trying profiling on the example program given @ here.
> I have used the profiling tool inbuilt in Visual Studios but was unable to
> extract useful information from it, therefore I have tried a solution provided
> on Stack Overflow @ here . It basically uses `clock()` function to calculate 
> the
> running time of the program.

you can use query performance counter/frequency on Windows. I find
them a bit more accurate than anything else :

static LARGE_INTEGER freq;
static LARGE_INTEGER count1;
static LARGE_INTEGER count2;

you call once, at the beginning :
QueryPerformanceFrequency();

before the code you want to profile :

QueryPerformanceCounter();

at the end :

QueryPerformanceCounter();

number of seconds (as a double ):
double t = (double)((count2.QuadPart - count1.QuadPart) / freq.QuadPart);

regards

Vincent Torri




> So, basically I have used two variables of type time_t one at the start and 
> one
> at the end of the program marking the clock time at those steps and in the end
> the program prints the time taken by the program in seconds.
> For averaging out the result I have used a  for loop running the example code 
> 10
> times every time the code is is executed and at the end of each iteration it 
> writes the difference
> between the start time and end time to a file in seconds.
> I have attached the file in which it writes the results.
> I have tested the above solution on Ubuntu 20.04 LTS and got the following 
> results:
> No Debugging mode (avg time: 0.0164531 sec)
> Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec)
> Debugging using FT_LOGGING mode (avg time: 0.0512144)
>
> Please look into this and provide feedback...
>
> Thanks,
> Priyesh
>
>
>
> On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar  wrote:
>>
>> Hi again,
>> I accidentally sent the previous mail
>> Continuing to the previous mail...
>> Also in the requirements, you told me to provide an option in MakeFile `make 
>> dist` to build the
>> external library. But dlg uses meson build system and I don't have any idea 
>> how to combine
>> meson build system with MakeFile, therefore could you provide me some 
>> references from where
>> I can read about doing this...
>>
>> Thanks,
>> Priyesh
>>
>> On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar  
>> wrote:
>>>
>>> Hi,
>>> I have added an option in `FT2_DEBUG` environment variable to 
>>> enable/disable the
>>> printing of FT_COMPONENT and Timestamp with a log message.
>>> The discussion related to dlg's features is still going, therefore in the 
>>> meantime I was
>>> thinking of extending the support on Windows.
>>> After looking: builds/windows/vc2010 , builds/windows/visualc and 
>>> builds/windows/visulace
>>> I can see that they all depend on builds/windows/ftdebug.c, therefore I 
>>> wanted to ask that
>>> Do I have to change only this file or there are some other files that I 
>>> have to take care of?
>>>
>>> Also in the requirements, you told me to provide an option in MakeFile 
>>> `make dist
>>>
>>> On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar  
>>> wrote:

 Hi armin,

 > This would print wrong-ish timestamps that couldn't really be used for 
 > profiling (I mean, it could; you just have to know which timestamp 
 > belongs to which message).  I would suggest to
 > rather store a flag after reading `\n` and attach the timestamp to the 
 > following message.

 I am also following this approach for printing timestamp and FT_COMPONENT.
 Actually dlg uses a flag `dlg_features` in which different features like  
 `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for 
 FT_COMPONENTS) are summed up using binary OR operator.
 For the first log message, these flags are kept ON so that timestamp and 
 FT_COMPONENT values are printed, and for the next coming log messages the 
 following logic is used:
 If the current log message contains a `\n` in it then the flags will be 
 toggled ON for the next coming log message assuming that it is end of a 
 log message,
 and if the current log message doesn't contain `\n` then these flags are 
 toggled OFF for the next coming log message assuming that it is in 
 continuation of current log message.

 > Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather 
 > fast, esp. given that this is followed by an IO operation.  To be tested 
 > though :)
 OK

 > Writing this lead me to look for multi-linebreak traces (e.g. 
 > src/pcf/pfcread.c:504) -- should that have one timestamp for the entire 
 > statement or one timestamp per line?

 With the above logic for these types of logs, there will be one timestamp 
 per line...

 Thanks,
 Priyesh

 On Sun, Jul 12, 2020 at 2:02 PM  wrote:
>
> > Since debugging isn't time critical it might be necessary to add an 
> > additional

Re: Logging Library-GSOC

[Werner LEMBERG]

>> *Have you set `FT2_DEBUG=any:7` in the environment?*
> 
> Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
> OpenSans-Bold.ttf font.

OK.

> Also, I wanted to ask is this the right approach for profiling?

I'm not an expert, sorry.  However, you might also try `valgrind
--tool=cachegrind` (on GNU/Linux), which gives you detailed
information on used CPU cycles including instruction and data caches.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

> *Have you set `FT2_DEBUG=any:7` in the environment?*

Sorry, I forgot to mention this, I have used FT2_DEBUG=any:7 with
OpenSans-Bold.ttf font.



*> You should also use a> well-hinted TrueType font like 'Arial' to get a
large bunch of> instruction debugging.*

Thanks, I will use this font.
Also, I wanted to ask is this the right approach for profiling?

Thanks,
Priyesh

On Thu, Jul 16, 2020 at 12:18 PM Werner LEMBERG  wrote:

>
> > I was trying profiling on the example program given @ here
> > .  I
> > have used the profiling tool inbuilt in Visual Studios but was
> > unable to extract useful information from it, therefore I have tried
> > a solution provided on Stack Overflow @ here
> >  >
> > .  It basically uses `clock()` function to calculate the running
> > time of the program.
>
> OK.
>
> > So, basically I have used two variables of type *time_t *one at the
> > start and one at the end of the program marking the clock time at
> > those steps and in the end the program prints the time taken by the
> > program in seconds.  For averaging out the result I have used a *for
> > *loop running the example code 10 times every time the code is is
> > executed and at the end of each iteration it writes the difference
> > between the start time and end time to a file in seconds.
> >
> > I have attached the file in which it writes the results.
>
> Well, those numbers vary far too much to have any significance.  I can
> only see that an execution without debugging is faster.  Have you set
> `FT2_DEBUG=any:7` in the environment?  This will make FreeType very
> chatty and thus should give better numbers.  You should also use a
> well-hinted TrueType font like 'Arial' to get a large bunch of
> instruction debugging.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> I was trying profiling on the example program given @ here
> .  I
> have used the profiling tool inbuilt in Visual Studios but was
> unable to extract useful information from it, therefore I have tried
> a solution provided on Stack Overflow @ here
> 
> .  It basically uses `clock()` function to calculate the running
> time of the program.

OK.

> So, basically I have used two variables of type *time_t *one at the
> start and one at the end of the program marking the clock time at
> those steps and in the end the program prints the time taken by the
> program in seconds.  For averaging out the result I have used a *for
> *loop running the example code 10 times every time the code is is
> executed and at the end of each iteration it writes the difference
> between the start time and end time to a file in seconds.
>
> I have attached the file in which it writes the results.

Well, those numbers vary far too much to have any significance.  I can
only see that an execution without debugging is faster.  Have you set
`FT2_DEBUG=any:7` in the environment?  This will make FreeType very
chatty and thus should give better numbers.  You should also use a
well-hinted TrueType font like 'Arial' to get a large bunch of
instruction debugging.


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have added an option in `FT2_DEBUG` environment variable to
> enable/disable the printing of FT_COMPONENT and Timestamp with a log
> message.

Looks good, thanks.

> After looking at builds/windows/vc2010, builds/windows/visualc and
> builds/windows/visualce I can see that they all depend on
> builds/windows/ftdebug.c, therefore I wanted to ask that Do I have
> to change only this file or there are some other files that I have
> to take care of?

AFAIK, it's only this file.  Alexei?

> Also in the requirements, you told me to provide an option in
> MakeFile `make dist` to build the external library.  But dlg uses
> meson build system and I don't have any idea how to combine meson
> build system with MakeFile, therefore could you provide me some
> references from where I can read about doing this...

I suggest the following.

(1) Use a different directory (for example
`/submodules/dlg`) for checking out the `dlg`
submodule.  This subdirectory won't get distributed with the
FreeType tarball.

(2) Create subdirectory `src/dlg`, which only holds a `rules.mk` file.

(3) Change the `autogen.sh` script to copy the necessary files from
`/submodules/dlg` to `src/dlg`.

(4) Modify the `setup` target in `builds/toplevel.mk` to do the same
as (3).  This is necessary for builds that don't use the
`configure` script (for example `make devel; make`).  Be careful
to use the right variables like `OBJ_DIR` so that it possible to
allow builds that use a read-only source directory.


Werne

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I was trying profiling on the example program given @ here
.
I have used the profiling tool inbuilt in Visual Studios but was unable to
extract useful information from it, therefore I have tried a solution
provided
on Stack Overflow @ here
 .
It basically uses `clock()` function to calculate the
running time of the program.
So, basically I have used two variables of type *time_t *one at the start
and one
at the end of the program marking the clock time at those steps and in the
end
the program prints the time taken by the program in seconds.
For averaging out the result I have used a  *for *loop running the example
code 10
times every time the code is is executed and at the end of each iteration
it writes the difference
between the start time and end time to a file in seconds.
I have attached the file in which it writes the results.
I have tested the above solution on Ubuntu 20.04 LTS and got the following
results:
No Debugging mode (avg time: 0.0164531 sec)
Debugging using FT_DEBUG_LEVEL_TRACE mode (avg time: 0.0988122 sec)
Debugging using FT_LOGGING mode (avg time: 0.0512144)

Please look into this and provide feedback...

Thanks,
Priyesh



On Tue, Jul 14, 2020 at 4:43 PM Priyesh kumar 
wrote:

> Hi again,
> I accidentally sent the previous mail
> Continuing to the previous mail...
> Also in the requirements, you told me to provide an option in MakeFile
> `make dist` to build the
> external library. But dlg uses meson build system and I don't have any
> idea how to combine
> meson build system with MakeFile, therefore could you provide me some
> references from where
> I can read about doing this...
>
> Thanks,
> Priyesh
>
> On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar 
> wrote:
>
>> Hi,
>> I have added an option in `FT2_DEBUG` environment variable to
>> enable/disable the
>> printing of FT_COMPONENT and Timestamp with a log message.
>> The discussion related to dlg's features is still going, therefore in the
>> meantime I was
>> thinking of extending the support on Windows.
>> After looking: builds/windows/vc2010 , builds/windows/visualc
>> and builds/windows/visulace
>> I can see that they all depend on builds/windows/ftdebug.c, therefore I
>> wanted to ask that
>> Do I have to change only this file or there are some other files that I
>> have to take care of?
>>
>> Also in the requirements, you told me to provide an option in MakeFile
>> `make dist
>>
>> On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar 
>> wrote:
>>
>>> Hi armin,
>>>
>>> *> This would print wrong-ish timestamps that couldn't really be used
>>> for profiling (I mean, it could; you just have to know which timestamp
>>> belongs to which message).  I would suggest to *
>>> *> rather store a flag after reading `\n` and attach the timestamp to
>>> the following message.*
>>>
>>> I am also following this approach for printing timestamp and
>>> FT_COMPONENT.
>>> Actually dlg uses a flag `dlg_features` in which different features
>>> like  `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for
>>> FT_COMPONENTS) are summed up using binary *OR *operator.
>>> For the first log message, these flags are kept ON so that timestamp and
>>> FT_COMPONENT values are printed, and for the next coming log messages the
>>> following logic is used:
>>> If the current log message contains a `\n` in it then the flags will be
>>> toggled ON for the next coming log message assuming that it is end of a log
>>> message,
>>> and if the current log message doesn't contain `\n` then these flags are
>>> toggled OFF for the next coming log message assuming that it is in
>>> continuation of current log message.
>>>
>>> *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather
>>> fast, esp. given that this is followed by an IO operation.  To be tested
>>> though :)*
>>> OK
>>>
>>> *> Writing this lead me to look for multi-linebreak traces (e.g.
>>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
>>> statement or one timestamp per line?*
>>>
>>> With the above logic for these types of logs, there will be one
>>> timestamp per line...
>>>
>>> Thanks,
>>> Priyesh
>>>
>>> On Sun, Jul 12, 2020 at 2:02 PM  wrote:
>>>
 > Since debugging isn't time critical it might be necessary to add an
 additional
 > step that scans tracing messages for newline characters, then
 massaging the
 > output by inserting the time stamp.  In other words, all occurrences
 of
 >
 >   `\n`
 >
 > should be replaced with
 >
 >   `\n[time stamp] `
 >
 > or something similar.

 This would print wrong-ish timestamps that couldn't really be used for
 profiling (I mean, it could; you just have to know which timestamp belongs
 to which message).  I would suggest to rather store a flag after reading
 `\n` and attach the timestamp to the following 

Re: Logging Library-GSOC

[Priyesh kumar]

Hi again,
I accidentally sent the previous mail
Continuing to the previous mail...
Also in the requirements, you told me to provide an option in MakeFile
`make dist` to build the
external library. But dlg uses meson build system and I don't have any idea
how to combine
meson build system with MakeFile, therefore could you provide me some
references from where
I can read about doing this...

Thanks,
Priyesh

On Tue, Jul 14, 2020 at 4:37 PM Priyesh kumar 
wrote:

> Hi,
> I have added an option in `FT2_DEBUG` environment variable to
> enable/disable the
> printing of FT_COMPONENT and Timestamp with a log message.
> The discussion related to dlg's features is still going, therefore in the
> meantime I was
> thinking of extending the support on Windows.
> After looking: builds/windows/vc2010 , builds/windows/visualc
> and builds/windows/visulace
> I can see that they all depend on builds/windows/ftdebug.c, therefore I
> wanted to ask that
> Do I have to change only this file or there are some other files that I
> have to take care of?
>
> Also in the requirements, you told me to provide an option in MakeFile
> `make dist
>
> On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar 
> wrote:
>
>> Hi armin,
>>
>> *> This would print wrong-ish timestamps that couldn't really be used for
>> profiling (I mean, it could; you just have to know which timestamp belongs
>> to which message).  I would suggest to *
>> *> rather store a flag after reading `\n` and attach the timestamp to the
>> following message.*
>>
>> I am also following this approach for printing timestamp and FT_COMPONENT.
>> Actually dlg uses a flag `dlg_features` in which different features like
>> `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for
>> FT_COMPONENTS) are summed up using binary *OR *operator.
>> For the first log message, these flags are kept ON so that timestamp and
>> FT_COMPONENT values are printed, and for the next coming log messages the
>> following logic is used:
>> If the current log message contains a `\n` in it then the flags will be
>> toggled ON for the next coming log message assuming that it is end of a log
>> message,
>> and if the current log message doesn't contain `\n` then these flags are
>> toggled OFF for the next coming log message assuming that it is in
>> continuation of current log message.
>>
>> *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather
>> fast, esp. given that this is followed by an IO operation.  To be tested
>> though :)*
>> OK
>>
>> *> Writing this lead me to look for multi-linebreak traces (e.g.
>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
>> statement or one timestamp per line?*
>>
>> With the above logic for these types of logs, there will be one timestamp
>> per line...
>>
>> Thanks,
>> Priyesh
>>
>> On Sun, Jul 12, 2020 at 2:02 PM  wrote:
>>
>>> > Since debugging isn't time critical it might be necessary to add an
>>> additional
>>> > step that scans tracing messages for newline characters, then
>>> massaging the
>>> > output by inserting the time stamp.  In other words, all occurrences of
>>> >
>>> >   `\n`
>>> >
>>> > should be replaced with
>>> >
>>> >   `\n[time stamp] `
>>> >
>>> > or something similar.
>>>
>>> This would print wrong-ish timestamps that couldn't really be used for
>>> profiling (I mean, it could; you just have to know which timestamp belongs
>>> to which message).  I would suggest to rather store a flag after reading
>>> `\n` and attach the timestamp to the following message.  Also, I would
>>> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that
>>> this is followed by an IO operation.  To be tested though :)
>>>
>>> Writing this lead me to look for multi-linebreak traces (e.g.
>>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
>>> statement or one timestamp per line?
>>>
>>> Armin
>>>
>>>

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I have added an option in `FT2_DEBUG` environment variable to
enable/disable the
printing of FT_COMPONENT and Timestamp with a log message.
The discussion related to dlg's features is still going, therefore in the
meantime I was
thinking of extending the support on Windows.
After looking: builds/windows/vc2010 , builds/windows/visualc
and builds/windows/visulace
I can see that they all depend on builds/windows/ftdebug.c, therefore I
wanted to ask that
Do I have to change only this file or there are some other files that I
have to take care of?

Also in the requirements, you told me to provide an option in MakeFile
`make dist

On Sun, Jul 12, 2020 at 2:50 PM Priyesh kumar 
wrote:

> Hi armin,
>
> *> This would print wrong-ish timestamps that couldn't really be used for
> profiling (I mean, it could; you just have to know which timestamp belongs
> to which message).  I would suggest to *
> *> rather store a flag after reading `\n` and attach the timestamp to the
> following message.*
>
> I am also following this approach for printing timestamp and FT_COMPONENT.
> Actually dlg uses a flag `dlg_features` in which different features like
> `dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for
> FT_COMPONENTS) are summed up using binary *OR *operator.
> For the first log message, these flags are kept ON so that timestamp and
> FT_COMPONENT values are printed, and for the next coming log messages the
> following logic is used:
> If the current log message contains a `\n` in it then the flags will be
> toggled ON for the next coming log message assuming that it is end of a log
> message,
> and if the current log message doesn't contain `\n` then these flags are
> toggled OFF for the next coming log message assuming that it is in
> continuation of current log message.
>
> *> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather
> fast, esp. given that this is followed by an IO operation.  To be tested
> though :)*
> OK
>
> *> Writing this lead me to look for multi-linebreak traces (e.g.
> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
> statement or one timestamp per line?*
>
> With the above logic for these types of logs, there will be one timestamp
> per line...
>
> Thanks,
> Priyesh
>
> On Sun, Jul 12, 2020 at 2:02 PM  wrote:
>
>> > Since debugging isn't time critical it might be necessary to add an
>> additional
>> > step that scans tracing messages for newline characters, then massaging
>> the
>> > output by inserting the time stamp.  In other words, all occurrences of
>> >
>> >   `\n`
>> >
>> > should be replaced with
>> >
>> >   `\n[time stamp] `
>> >
>> > or something similar.
>>
>> This would print wrong-ish timestamps that couldn't really be used for
>> profiling (I mean, it could; you just have to know which timestamp belongs
>> to which message).  I would suggest to rather store a flag after reading
>> `\n` and attach the timestamp to the following message.  Also, I would
>> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that
>> this is followed by an IO operation.  To be tested though :)
>>
>> Writing this lead me to look for multi-linebreak traces (e.g.
>> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
>> statement or one timestamp per line?
>>
>> Armin
>>
>>

Re: Logging Library-GSOC

[Priyesh kumar]

Hi armin,

*> This would print wrong-ish timestamps that couldn't really be used for
profiling (I mean, it could; you just have to know which timestamp belongs
to which message).  I would suggest to *
*> rather store a flag after reading `\n` and attach the timestamp to the
following message.*

I am also following this approach for printing timestamp and FT_COMPONENT.
Actually dlg uses a flag `dlg_features` in which different features like
`dlg_output_timestamp`(for timestamps) and `dlg_output_tags`(for
FT_COMPONENTS) are summed up using binary *OR *operator.
For the first log message, these flags are kept ON so that timestamp and
FT_COMPONENT values are printed, and for the next coming log messages the
following logic is used:
If the current log message contains a `\n` in it then the flags will be
toggled ON for the next coming log message assuming that it is end of a log
message,
and if the current log message doesn't contain `\n` then these flags are
toggled OFF for the next coming log message assuming that it is in
continuation of current log message.

*> Also, I would believe that `fmt[strlen(fmt) - 1] == '\n'` is rather
fast, esp. given that this is followed by an IO operation.  To be tested
though :)*
OK

*> Writing this lead me to look for multi-linebreak traces (e.g.
src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
statement or one timestamp per line?*

With the above logic for these types of logs, there will be one timestamp
per line...

Thanks,
Priyesh

On Sun, Jul 12, 2020 at 2:02 PM  wrote:

> > Since debugging isn't time critical it might be necessary to add an
> additional
> > step that scans tracing messages for newline characters, then massaging
> the
> > output by inserting the time stamp.  In other words, all occurrences of
> >
> >   `\n`
> >
> > should be replaced with
> >
> >   `\n[time stamp] `
> >
> > or something similar.
>
> This would print wrong-ish timestamps that couldn't really be used for
> profiling (I mean, it could; you just have to know which timestamp belongs
> to which message).  I would suggest to rather store a flag after reading
> `\n` and attach the timestamp to the following message.  Also, I would
> believe that `fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that
> this is followed by an IO operation.  To be tested though :)
>
> Writing this lead me to look for multi-linebreak traces (e.g.
> src/pcf/pfcread.c:504) -- should that have one timestamp for the entire
> statement or one timestamp per line?
>
> Armin
>
>

RE: Logging Library-GSOC

[armin]

> Since debugging isn't time critical it might be necessary to add an additional
> step that scans tracing messages for newline characters, then massaging the
> output by inserting the time stamp.  In other words, all occurrences of
>
>   `\n`
>
> should be replaced with
>
>   `\n[time stamp] `
>
> or something similar.

This would print wrong-ish timestamps that couldn't really be used for 
profiling (I mean, it could; you just have to know which timestamp belongs to 
which message).  I would suggest to rather store a flag after reading `\n` and 
attach the timestamp to the following message.  Also, I would believe that 
`fmt[strlen(fmt) - 1] == '\n'` is rather fast, esp. given that this is followed 
by an IO operation.  To be tested though :)

Writing this lead me to look for multi-linebreak traces (e.g. 
src/pcf/pfcread.c:504) -- should that have one timestamp for the entire 
statement or one timestamp per line?

Armin

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have made the required changes in the dlg library according to the
> requirements and submitted a pull request (
> https://github.com/nyorain/dlg/pull/5 ) one day ago and I am waiting
> for the dlg's maintainer to respond to it.

Thanks a lot; the discussion looks interesting.

> I have tried the new changes with FreeType and I am attaching a log
> file produced by it.  Please take a look at it...

Very nice!


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

>> What do you mean with 'toggle'?
> 
> In one of the previous mail, you mentioned that you wanted to print
> FT_COMPONENTS along with actual log message only when there is some
> string present in the FT2_DEBUG env variable.  Therefore, I wanted
> to ask about what exactly do you have in your mind about controlling
> this behaviour, so that I could try to implement it...

Thanks.  For simplicity, let's assume that the addition of an argument
`-v` to `FT2_DEBUG` activates the output of the `FT_COMPONENTS`
strings in square brackets.  Example:

  FT2_DEBUG="any:7 -v"


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

*> I thought of>  [] ...> where  is the value given
in the `FT_COMPONENT` macro,> padded with spaces to ensure a uniform
width.  Example:>  [cffdriver] ...>  [psconv   ] ...>  [sfobjs   ] ...>
However, this should be freely adjustable – thus my request to make> `{`
and `}` configurable in the 'dlg' library.*

Ok


*> What do you mean with 'toggle'?*

In one of the previous mail, you mentioned that you wanted to print
FT_COMPONENTS along with
actual log message only when there is some string present in the FT2_DEBUG
env variable.
Therefore, I wanted to ask about what exactly do you have in your mind
about controlling this behaviour, so that I
could try to implement it...


On Mon, Jul 6, 2020 at 6:31 PM Werner LEMBERG  wrote:

>
> >> 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,
>
> Thanks.
>
> > but in the meantime could you provide me the format in which you
> > want the log messages to be printed.
>
> I thought of
>
>   [] ...
>
> where  is the value given in the `FT_COMPONENT` macro,
> padded with spaces to ensure a uniform width.  Example:
>
>   [cffdriver] ...
>   [psconv   ] ...
>   [sfobjs   ] ...
>
> However, this should be freely adjustable – thus my request to make
> `{` and `}` configurable in the 'dlg' library.
>
> > Along with this, please share your thoughts on how you want to
> > toggle the TimeStamp and FT_COMPONENT features...
>
> What do you mean with 'toggle'?
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

>> 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,

Thanks.

> but in the meantime could you provide me the format in which you
> want the log messages to be printed.

I thought of

  [] ...

where  is the value given in the `FT_COMPONENT` macro,
padded with spaces to ensure a uniform width.  Example:

  [cffdriver] ...
  [psconv   ] ...
  [sfobjs   ] ...

However, this should be freely adjustable – thus my request to make
`{` and `}` configurable in the 'dlg' library.

> Along with this, please share your thoughts on how you want to
> toggle the TimeStamp and FT_COMPONENT features...

What do you mean with 'toggle'?


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

*> 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  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
>

Re: Logging Library-GSOC

[Werner LEMBERG]

>> 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

Re: Logging Library-GSOC

[Priyesh kumar]

*> 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...


*> 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...








*> Now let's pretend I'm Joe User, and I want a different logging format.>
Instead of having> [12:03:56 {stream}] ...> I want>  [stream] ...> What
must be done?  [Actually, this is the default format I want to> have if the
`FT2_DEBUG` environment variable contains the string> `show_modules` (or
`-v`, or whatever; this isn't implemented yet).]*

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.
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.


Thanks,
Priyesh




On Mon, Jul 6, 2020 at 1:01 PM Werner LEMBERG  wrote:

>
> > I have added some changes to produce the desired output using the
> > previous approach specified by you.  With this approach, I have to
> > make very little changes in some FT_TRACE calls for better
> > indentation.  Would that be OK with you?
>
> Of course.  Please send a separate patch for these fixed so that I can
> apply it to master directly.
>
> > I am attaching a log file generated by the ftview.c demo program
> > representing the new changes...
>
> Very nice!  Do you have some data how large the slowdown is due to the
> additional code?
>
> Now let's pretend I'm Joe User, and I want a different logging format.
> Instead of having
>
>   [12:03:56 {stream}] ...
>
> I want
>
>   [stream] ...
>
> What must be done?  [Actually, this is the default format I want to
> have if the `FT2_DEBUG` environment variable contains the string
> `show_modules` (or `-v`, or whatever; this isn't implemented yet).]
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have added some changes to produce the desired output using the
> previous approach specified by you.  With this approach, I have to
> make very little changes in some FT_TRACE calls for better
> indentation.  Would that be OK with you?

Of course.  Please send a separate patch for these fixed so that I can
apply it to master directly.

> I am attaching a log file generated by the ftview.c demo program
> representing the new changes...

Very nice!  Do you have some data how large the slowdown is due to the
additional code?

Now let's pretend I'm Joe User, and I want a different logging format.
Instead of having

  [12:03:56 {stream}] ...

I want

  [stream] ...

What must be done?  [Actually, this is the default format I want to
have if the `FT2_DEBUG` environment variable contains the string
`show_modules` (or `-v`, or whatever; this isn't implemented yet).]


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> > Since debugging isn't time critical it might be necessary to add
> > an additional step that scans tracing messages for newline
> > characters, then massaging the output by inserting the time stamp.
> > In other words, all occurrences of `\n` should be replaced with
> > `\n[time stamp] ` or something similar.
> 
> I also came up with the same idea but thought that string comparison
> will take plenty amount of time, therefore, I dropped this idea...
> But, as you said so I will try to implement it...

Do you have a better idea?  I could only come up with another set of
tracing macros like `FT_TRACEC[0-7]` ('C' for continuing) that don't
emit a final newline.  This would imply *a lot* of (mostly mechanical)
changes in the source code.  It wouldn't really uglify the source
code, though, but I think a solution that doesn't necessitate this
distinction is preferable since easier to use.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

>






*Since debugging isn't time critical it might be necessary to add an>
additional step that scans tracing messages for newline characters,> then
massaging the output by inserting the time stamp.  In other> words, all
occurrences of>  `\n`> should be replaced with>  `\n[time stamp] `> or
something similar.*

I also came up with the same idea but thought that string comparison will
take
plenty amount of time, therefore, I dropped this idea...
But, as you said so I will try to implement it...
Thanks,
Priyesh


On Sun, Jul 5, 2020 at 1:17 AM Werner LEMBERG  wrote:

>
> > Throughout this week I have integrated dlg with FreeType and I was
> > able to achieve the following goals: [...]
>
> Thanks!
>
> > [...] I am facing a problem with printing FT_COMPONENT and
> > Time-Stamp along with log messages part...  The problem is that this
> > extra information is printed every time there is a call to dlg's API
> > to handle trace/error logs.
>
> Indeed, this is a problem.  The time stamp should only be printed if
> the last character of the last message was a newline character.
>
> Or rather, the printing of a newline character should trigger the
> printing of the time stamp.
>
> > I have attached a log file related to this problem.  I am working on
> > this but in the meantime, if I could get some suggestions it would
> > be very helpful...
>
> Since debugging isn't time critical it might be necessary to add an
> additional step that scans tracing messages for newline characters,
> then massaging the output by inserting the time stamp.  In other
> words, all occurrences of
>
>   `\n`
>
> should be replaced with
>
>   `\n[time stamp] `
>
> or something similar.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> Throughout this week I have integrated dlg with FreeType and I was
> able to achieve the following goals: [...]

Thanks!

> [...] I am facing a problem with printing FT_COMPONENT and
> Time-Stamp along with log messages part...  The problem is that this
> extra information is printed every time there is a call to dlg's API
> to handle trace/error logs.

Indeed, this is a problem.  The time stamp should only be printed if
the last character of the last message was a newline character.

Or rather, the printing of a newline character should trigger the
printing of the time stamp.

> I have attached a log file related to this problem.  I am working on
> this but in the meantime, if I could get some suggestions it would
> be very helpful...

Since debugging isn't time critical it might be necessary to add an
additional step that scans tracing messages for newline characters,
then massaging the output by inserting the time stamp.  In other
words, all occurrences of

  `\n`

should be replaced with

  `\n[time stamp] `

or something similar.


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I have updated the progress report for this week @ here
> 
> It contains a brief description of all the useful APIs provided by
> dlg

Thanks, looks promising.  If you are going to import the 'dlg' files I
suggest that you put the necessary files into

  src/dlg

(in your personal branch of FreeType's git repository).


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,
I have updated the progress report for this week @ here

It contains a brief description of all the useful APIs provided by dlg
Please look at the report...
Thanks,
Priyesh

On Thu, Jun 25, 2020 at 1:26 PM Werner LEMBERG  wrote:

>
> > [...] Therefore, according to me if you are concerned about the
> > additional code that we need to add along with using dlg, it would
> > be much less than the code if we develop a logger inside FreeType
> > with all of the above the requirements and support on different
> > platforms.
>
> OK.
>
> > I would try to document all the dlg's features that I am going to
> > use along with how I am going to use them in week 4 and week 5
> > progress reports.
>
> Looks good, thanks!
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> [...] Therefore, according to me if you are concerned about the
> additional code that we need to add along with using dlg, it would
> be much less than the code if we develop a logger inside FreeType
> with all of the above the requirements and support on different
> platforms.

OK.

> I would try to document all the dlg's features that I am going to
> use along with how I am going to use them in week 4 and week 5
> progress reports.

Looks good, thanks!


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,




*> Well, you say 'most'.  Is this, say, 70% or 90% suitability in your>
opinion?  If it's the former, how much additional code must be added> to
fit the needs?  There might be a point that you have to add so much> code
that it might be easier to avoid the library altogether.*

According to me the requirements from the external library were:
1. Write logs to file (with support on different platforms including
Windows).
2. Formatting of log messages according to user needs (toggle-able:
timestamps and FT_COMPONENT values)
These requirements are completely satisfied by dlg, and we only have to
call the respective APIs given by dlg with some tweaks in FreeType to avail
these features...

Other than the above requirements there was a requirement to dynamically
change log levels and change the output mode through the use of callback
functions.
For this requirement, we have to add code irrespective of whether we use an
external library or we develop a logger inside FreeType.

Therefore, according to me if you are concerned about the additional code
that we need to add along with using dlg, it would be much less than the
code if we develop a logger inside FreeType with all of the above the
requirements and support on different platforms.

I would try to document all the dlg's features that I am going to use along
with how I am going to use them in week 4 and week 5 progress reports
And that would be my plan on how I am going to integrate dlg with FreeType
(obviously changeable according to the suggestions)  :-)
Please guide me...

Thanks,
Priyesh


On Thu, Jun 25, 2020 at 8:24 AM Werner LEMBERG  wrote:

>
> > > The recent discussion with Behdad reminded me to ask you whether you
> > > have also investigated the case where you modify the existing
> > > debugging and tracing code of FreeType without using an external
> > > library.  For example, such new code might be based on the code from
> > > 'dlg' but stripped down to the bare features we would like to see.
> >
> > I haven't tried this case as I thought that we need to look at this
> > option only when none of the external libraries satisfies the
> > specified requirements.  And while exploring we have found a library
> > *dlg* which is satisfying most of the requirements...
>
> Well, you say 'most'.  Is this, say, 70% or 90% suitability in your
> opinion?  If it's the former, how much additional code must be added
> to fit the needs?  There might be a point that you have to add so much
> code that it might be easier to avoid the library altogether.
>
> Please note that I'm only looking at the problem from different points
> of view.  If you say 'dlg' is the right choice to proceed, then by all
> means let's do it :-)
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> > The recent discussion with Behdad reminded me to ask you whether you
> > have also investigated the case where you modify the existing
> > debugging and tracing code of FreeType without using an external
> > library.  For example, such new code might be based on the code from
> > 'dlg' but stripped down to the bare features we would like to see.
> 
> I haven't tried this case as I thought that we need to look at this
> option only when none of the external libraries satisfies the
> specified requirements.  And while exploring we have found a library
> *dlg* which is satisfying most of the requirements...

Well, you say 'most'.  Is this, say, 70% or 90% suitability in your
opinion?  If it's the former, how much additional code must be added
to fit the needs?  There might be a point that you have to add so much
code that it might be easier to avoid the library altogether.

Please note that I'm only looking at the problem from different points
of view.  If you say 'dlg' is the right choice to proceed, then by all
means let's do it :-)


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,

>





*Thanks!  The recent discussion with Behdad reminded me to ask you> whether
you have also investigated the case where you modify the> existing
debugging and tracing code of FreeType without using an> external library.
For example, such new code might be based on the> code from 'dlg' but
stripped down to the bare features we would like> to see.*

I haven't tried this case as I thought that we need to look at this option
only when none of the external libraries satisfies the
specified requirements.
And while exploring we have found a library *dlg *which is satisfying most
of the requirements...
Please guide me accordingly...
Thanks,
Priyesh

On Wed, Jun 24, 2020 at 11:23 AM Werner LEMBERG  wrote:

>
> > Also I have updated the progress report for 3rd week @ here
> > <
> https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing
> >
>
> Thanks!  The recent discussion with Behdad reminded me to ask you
> whether you have also investigated the case where you modify the
> existing debugging and tracing code of FreeType without using an
> external library.  For example, such new code might be based on the
> code from 'dlg' but stripped down to the bare features we would like
> to see.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> Also I have updated the progress report for 3rd week @ here
> 

Thanks!  The recent discussion with Behdad reminded me to ask you
whether you have also investigated the case where you modify the
existing debugging and tracing code of FreeType without using an
external library.  For example, such new code might be based on the
code from 'dlg' but stripped down to the bare features we would like
to see.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Guys,

> *I do like that notation style ;)  Apart from that I for sure have not
used it on Windows;  don't worry about that either and thanks for
double-checking! :)*
Thanks for responding to my concerns...

>* As you are now moving into the implementation phase of your project I
would quickly like to recall my message from about a month ago: *
*> https://lists.nongnu.org/archive/html/freetype -
devel/2020-05/msg00165.html
.
Don't worry about exact naming and we might need more functions and/or more
arguments but outlining the  > general idea:  I would very much appreciate
it if we could find a way to wrap FT logging into a public interface that
works something along these lines.  So basically there's a default log  *
*> callback implemented internally that listens to environment variables
(and/or other, more dynamic inputs) and then there's a way to overwrite
this callback from the outside by providing (a)  > custom function(s).  All
details are obviously up for discussion :)*
Will work on it and respond...

Also I have updated the progress report for 3rd week @ here

Sorry, for replying this late...

Thanks,
Priyesh


On Sat, Jun 20, 2020 at 5:03 PM  wrote:

> Hi Priesh,
>
> >> In previous mails, Armin suggested to move some of the FreeType's
> >> logging functionality to the external logger but according to my
> >> analysis, none of the external logging libraries that I have
> >> explored exactly matches the logging architecture of FreeType
> >> (i.e. logging based on debug level of components and debug levels of
> >> trace calls).  According to me, this is not possible with dlg
> >> library [...]
> >
> > This is not a problem at all.
>
> Don't worry about that -- I was just thinking out loud about things we
> could do :)
>
> > (For Armin){
> > I have looked into log4c, [...] but I am not sure about it on windows
> [...]
> > }
>
> I do like that notation style ;)  Apart from that I for sure have not used
> it on Windows;  don't worry about that either and thanks for
> double-checking! :)
>
> As you are now moving into the implementation phase of your project I
> would quickly like to recall my message from about a month ago:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00165.html.
> Don't worry about exact naming and we might need more functions and/or more
> arguments but outlining the general idea:  I would very much appreciate it
> if we could find a way to wrap FT logging into a public interface that
> works something along these lines.  So basically there's a default log
> callback implemented internally that listens to environment variables
> (and/or other, more dynamic inputs) and then there's a way to overwrite
> this callback from the outside by providing (a) custom function(s).  All
> details are obviously up for discussion :)
>
>

Re: Logging Library-GSOC

[Behdad Esfahbod]

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG  wrote:

>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file.  Specially bad if that can be controlled by an
> > env-var.
>
> Interesting.  Please explain.  Do you fear security issues?
>

Sorry, forgot to reply to this.  Yes, security.  I give you a couple of
examples:

  - On a security-sensitive system, even an extra open file handle is an
extra tool an attacker can use to mount their attack.  Read this epic story:

https://threatpost.com/pinkiepie-strikes-again-compromises-google-chrome-pwnium-contest-hack-box-101012/77098/
https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html
https://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html

  - A few years ago there was an attempted attack on ChromeOS.  Some
ChromeOS UI components were using GTK+, which uses Pango.  Pango used to
have a config file.  The default search path for the config file looked in
certain directories on the user's home-directory, which is writable to the
user.  It could also be controlled via an environment variable.  The config
file could reconfigure where Pango module map was loaded from.  The Pango
module map pointed to binary modules to load for shaping certain scripts.
Pango would dlopen() such modules and look for a specifically named symbols
and call those.  That's already problematic, because it means that an
attacker who finds a way to write files to user's home directory would be
able to make the system UI load custom code.  On top of that, note that
that on Linux / ELF as well as most other systems, binary modules can
execute code at runtime linking stage.  That means, such attack could run
arbitrary code on processes that just linked to GTK+ and initialized it but
not even display any text.

So when I hear about a system, no matter what it is, that will write to
file, controlled via env-vars, and configured through a config file, my
immediate response is:

  - That sounds like hell of a lot of security vectors, for...
  - A feature that is not even justified to begin with!  FreeType clients
what to read text.  None of this contributes to any of that.

While you may be tempted to argue why it won't be a problem for FreeType
(for example because it will be disabled by default), I accept that.  But
that is in conflict with what Armin's stance is on this.  I'll expand in
the other thread.  I'm still hopeful to be able to write that today.

Re: Logging Library-GSOC

[Behdad Esfahbod]

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG  wrote:

>
> > I find it a *very* bad idea to have code in FreeType that would
> > write to a file.  Specially bad if that can be controlled by an
> > env-var.
>
> Interesting.  Please explain.  Do you fear security issues?
>
> > I still think what's desired can be done best by just revamping and
> > writing custom code in FreeType itself.
>
> Yes, this is another possibility.  We haven't yet decided how to
> proceed; Priyesh is still in the investigation phase.


Those words are not consistent with your actions.  I'll reply in other
thread I specifically started about this topic earlier.

-- 
behdad
http://behdad.org/

RE: Logging Library-GSOC

[armin]

Hi Priesh,

>> In previous mails, Armin suggested to move some of the FreeType's
>> logging functionality to the external logger but according to my
>> analysis, none of the external logging libraries that I have
>> explored exactly matches the logging architecture of FreeType
>> (i.e. logging based on debug level of components and debug levels of
>> trace calls).  According to me, this is not possible with dlg
>> library [...]
>
> This is not a problem at all.

Don't worry about that -- I was just thinking out loud about things we could do 
:)

> (For Armin){
> I have looked into log4c, [...] but I am not sure about it on windows [...]
> }

I do like that notation style ;)  Apart from that I for sure have not used it 
on Windows;  don't worry about that either and thanks for double-checking! :)

As you are now moving into the implementation phase of your project I would 
quickly like to recall my message from about a month ago:  
https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00165.html.  
Don't worry about exact naming and we might need more functions and/or more 
arguments but outlining the general idea:  I would very much appreciate it if 
we could find a way to wrap FT logging into a public interface that works 
something along these lines.  So basically there's a default log callback 
implemented internally that listens to environment variables (and/or other, 
more dynamic inputs) and then there's a way to overwrite this callback from the 
outside by providing (a) custom function(s).  All details are obviously up for 
discussion :)

Re: Logging Library-GSOC

[Priyesh kumar]

Hi,

> *OK, then let's try this library!*
Thanks for the reply, will work in this direction...

Thanks,
Priyesh


On Fri, Jun 19, 2020 at 9:44 AM Werner LEMBERG  wrote:

>
> > During the exploration phase, I have seen several libraries and
> > according to me *dlg* is best suited for the requirements:
>
> OK, then let's try this library!
>
> > In previous mails, Armin suggested to move some of the FreeType's
> > logging functionality to the external logger but according to my
> > analysis, none of the external logging libraries that I have
> > explored exactly matches the logging architecture of FreeType
> > (i.e. logging based on debug level of components and debug levels of
> > trace calls).  According to me, this is not possible with dlg
> > library [...]
>
> This is not a problem at all.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> During the exploration phase, I have seen several libraries and
> according to me *dlg* is best suited for the requirements:

OK, then let's try this library!

> In previous mails, Armin suggested to move some of the FreeType's
> logging functionality to the external logger but according to my
> analysis, none of the external logging libraries that I have
> explored exactly matches the logging architecture of FreeType
> (i.e. logging based on debug level of components and debug levels of
> trace calls).  According to me, this is not possible with dlg
> library [...]

This is not a problem at all.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi guys,

During the exploration phase, I have seen several libraries and according
to me *dlg* is best suited for the requirements:
1. Printing logs to file
2. Dynamically change log levels and redirect logs to the desired output
through the use of callback functions
3. Windows support
Other than dlg, I think zlog and log4c are also powerful logging libraries
but they are not properly supported on windows...

Also, I have some concerns regarding Armin's previous mails:-
In previous mails, Armin suggested to move some of the FreeType's logging
functionality to the external logger but according to my analysis, none of
the external logging libraries that I have explored exactly matches the
logging architecture of FreeType (i.e. logging based on debug level of
components and debug levels of trace calls). According to me, this is not
possible with dlg library but we could leverage the zlog or log4c for this
requirement and we might have to make some changes in FreeType's current
logging architecture. I am not sure if this will suit to Freetype clients.
Requesting guidance from your side.
Please correct me if I am not understanding this requirement correctly :-)

Thanks,
Priyesh

On Wed, Jun 17, 2020 at 2:18 PM Priyesh kumar 
wrote:

> Hi Werner,
> > *I think you did a great job with your exploration.*
>
> Thanks...
>
> > *Do you think that** you already can suggest a library that fits best?*
>
> I think I need some time to analyze the already explored logging libraries
> (mainly dlg and log4c) w.r.t to FreeType, and how to leverage these within
> FreeType...
> I will update you on this by this weekend...
>
> Thanks,
> Priyesh
>
>
> On Wed, Jun 17, 2020 at 12:54 PM Werner LEMBERG  wrote:
>
>>
>> > After going through log4c, I don't think I have any more options to
>> > look onto...  If you guys know any more logging libraries, please
>> > let me know...
>>
>> I think you did a great job with your exploration.  Do you think that
>> you already can suggest a library that fits best?
>>
>>
>> Werner
>>
>

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
> *I think you did a great job with your exploration.*

Thanks...

> *Do you think that** you already can suggest a library that fits best?*

I think I need some time to analyze the already explored logging libraries
(mainly dlg and log4c) w.r.t to FreeType, and how to leverage these within
FreeType...
I will update you on this by this weekend...

Thanks,
Priyesh


On Wed, Jun 17, 2020 at 12:54 PM Werner LEMBERG  wrote:

>
> > After going through log4c, I don't think I have any more options to
> > look onto...  If you guys know any more logging libraries, please
> > let me know...
>
> I think you did a great job with your exploration.  Do you think that
> you already can suggest a library that fits best?
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> After going through log4c, I don't think I have any more options to
> look onto...  If you guys know any more logging libraries, please
> let me know...

I think you did a great job with your exploration.  Do you think that
you already can suggest a library that fits best?


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi guys,
(For Armin){
I have looked into log4c, no doubt it is a powerful logging library and we
could use some of it's features to share some logging functionality from
FreeType,
but I am not sure about it on windows as I am having a hard time compiling
it on windows and also I think the pre-built .lib file provided in log4c
release @ here
 is
also broken/not working,
I have to make a .lib file from .dll using dumpbin and lib commands to link
log4c with an example and to make it work (-_-)zZ
Please help me with this as you have worked with log4c before...
Thanks
}

After going through log4c, I don't think I have any more options to look
onto...
If you guys know any more logging libraries, please let me know...

Thanks,
Priyesh

On Mon, Jun 15, 2020 at 10:47 AM Priyesh kumar 
wrote:

> Hi Armin,
>
>
> *>However, I could see how e.g. the usage of `FT_COMPONENT` could be
> slightly altered (or an additional macro introduced) if that helps with
> moving more functionality into the logger.*
> Please, could you provide more information on this...
>
> Thanks,
> Priyesh
>
> On Sun, Jun 14, 2020 at 3:24 PM  wrote:
>
>> > No, I haven't thought in that direction as according to the
>> requirements least
>> > coupling is favorable...
>>
>> I think (but happy for everyone with other opinions to chime in +
>> discuss) at this point the only real hard constraint in that regard is that
>> we want to wrap the logger into FreeType specific macros and not expose it
>> directly in the core codebase.  In addition, `FT_TRACE*` and `FT_ERROR`
>> should not be replaced or changed (unless there is a really good reason
>> that pretty much everyone agrees on).  However, I could see how e.g. the
>> usage of `FT_COMPONENT` could be slightly altered (or an additional macro
>> introduced) if that helps with moving more functionality into the logger.
>>
>> As I understand it, parts of this project is to generally enhance tracing
>> + logging within FreeType.  Apart from platform independent write-out,
>> timestamps, custom callbacks, etc ...  this _could_, in my opinion, also
>> include moving the handling of logging + tracing out of the core codebase
>> (if / as much as this is reasonable) as this could open up a lot more
>> flexibility down the road (depending on the logging library in question +
>> should be discussed separately).  I believe that, once we are able to hook
>> a specific logger into FreeType with just a few macros, replacing that
>> logger might become a reasonably easy task, should requirements change.
>> Thus, unless Werner disagrees, I believe it would be interesting to explore
>> that option and understand if / how easily this can be done (and to what
>> extent).
>>
>> Best
>> Armin
>>
>>

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Armin,


*>However, I could see how e.g. the usage of `FT_COMPONENT` could be
slightly altered (or an additional macro introduced) if that helps with
moving more functionality into the logger.*
Please, could you provide more information on this...

Thanks,
Priyesh

On Sun, Jun 14, 2020 at 3:24 PM  wrote:

> > No, I haven't thought in that direction as according to the requirements
> least
> > coupling is favorable...
>
> I think (but happy for everyone with other opinions to chime in + discuss)
> at this point the only real hard constraint in that regard is that we want
> to wrap the logger into FreeType specific macros and not expose it directly
> in the core codebase.  In addition, `FT_TRACE*` and `FT_ERROR` should not
> be replaced or changed (unless there is a really good reason that pretty
> much everyone agrees on).  However, I could see how e.g. the usage of
> `FT_COMPONENT` could be slightly altered (or an additional macro
> introduced) if that helps with moving more functionality into the logger.
>
> As I understand it, parts of this project is to generally enhance tracing
> + logging within FreeType.  Apart from platform independent write-out,
> timestamps, custom callbacks, etc ...  this _could_, in my opinion, also
> include moving the handling of logging + tracing out of the core codebase
> (if / as much as this is reasonable) as this could open up a lot more
> flexibility down the road (depending on the logging library in question +
> should be discussed separately).  I believe that, once we are able to hook
> a specific logger into FreeType with just a few macros, replacing that
> logger might become a reasonably easy task, should requirements change.
> Thus, unless Werner disagrees, I believe it would be interesting to explore
> that option and understand if / how easily this can be done (and to what
> extent).
>
> Best
> Armin
>
>

RE: Logging Library-GSOC

[armin]

> No, I haven't thought in that direction as according to the requirements least
> coupling is favorable...

I think (but happy for everyone with other opinions to chime in + discuss) at 
this point the only real hard constraint in that regard is that we want to wrap 
the logger into FreeType specific macros and not expose it directly in the core 
codebase.  In addition, `FT_TRACE*` and `FT_ERROR` should not be replaced or 
changed (unless there is a really good reason that pretty much everyone agrees 
on).  However, I could see how e.g. the usage of `FT_COMPONENT` could be 
slightly altered (or an additional macro introduced) if that helps with moving 
more functionality into the logger.

As I understand it, parts of this project is to generally enhance tracing + 
logging within FreeType.  Apart from platform independent write-out, 
timestamps, custom callbacks, etc ...  this _could_, in my opinion, also 
include moving the handling of logging + tracing out of the core codebase (if / 
as much as this is reasonable) as this could open up a lot more flexibility 
down the road (depending on the logging library in question + should be 
discussed separately).  I believe that, once we are able to hook a specific 
logger into FreeType with just a few macros, replacing that logger might become 
a reasonably easy task, should requirements change.  Thus, unless Werner 
disagrees, I believe it would be interesting to explore that option and 
understand if / how easily this can be done (and to what extent).

Best
Armin

Re: Logging Library-GSOC

[Priyesh kumar]

Hi armin,

>*Thanks for your update & write-up, looks promising :)  I agree with your
approach of trying to find the most lightweight C logger that does the job*

Thanks for reviewing the report...

Regarding Qus 1)
*>do you plan to mainly using the logger to write to files and an
equivalent of `stderr` consistently across multiple platforms *

Yes, this was my plan (plus the feature of dynamic change of log levels and
dynamic log redirection).

*>do you also plan to use it to replace some of the handling that's
currently done within FreeType (like checking + parsing log levels +
components, etc) with calls to that library?  I believe it >would be
especially interesting if we managed to move some of the components
handling out of FT and into that external piece.  Not sure however, if any
of these libraries have a somehow >direct mapping of how components
(modules) are used for tracing within FT currently (essentially, all
components/modules can be configured with their own trace level). *

No, I haven't thought in that direction as according to the requirements
least coupling is favorable...
But, I think it is a nice idea to completely use the external logger if
some user wants the feature of printing log messages to file (otherwise
they can use the normal debugging facility provided by FreeType),
However, for that, we will require a logging library that provides a
feature to create our own log levels (so that we could map 8 trace and
other log levels which FreeType uses).
But as far as I have seen only zlog provides the feature of defining our
own log levels...

Regarding Qus 2)

*>have you looked into log4c at any point?  Not saying it is what FreeType
needs but something that worked reasonably well for me a while ago;  might
be a lot bigger than what we need or >have other downsides, just asking b/c
I couldn't see it in your list.  *

I haven't looked into log4c till now...
I will have a look at log4c and update it's pros and cons (according to me
and the requirements) in next week's progress report...

Thanks,
Priyesh


On Sat, Jun 13, 2020 at 8:39 PM  wrote:

> Hi Priyesh,
>
> > I have updated the progress report for this week @
> >
> https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing
>
> Thanks for your update & write-up, looks promising :)  I agree with your
> approach of trying to find the most lightweight C logger that does the job,
> just two quick questions about your work:
>
> (1) do you plan to mainly using the logger to write to files and an
> equivalent of `stderr` consistently across multiple platforms or do you
> also plan to use it to replace some of the handling that's currently done
> within FreeType (like checking + parsing log levels + components, etc) with
> calls to that library?  I believe it would be especially interesting if we
> managed to move some of the components handling out of FT and into that
> external piece.  Not sure however, if any of these libraries have a somehow
> direct mapping of how components (modules) are used for tracing within FT
> currently (essentially, all components/modules can be configured with their
> own trace level).
>
> (2) have you looked into log4c at any point?  Not saying it is what
> FreeType needs but something that worked reasonably well for me a while
> ago;  might be a lot bigger than what we need or have other downsides, just
> asking b/c I couldn't see it in your list.
>
> Best
> Armin
>
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> I find it a *very* bad idea to have code in FreeType that would
> write to a file.  Specially bad if that can be controlled by an
> env-var.

Interesting.  Please explain.  Do you fear security issues?

> I still think what's desired can be done best by just revamping and
> writing custom code in FreeType itself.

Yes, this is another possibility.  We haven't yet decided how to
proceed; Priyesh is still in the investigation phase.


Werner

Re: Logging Library-GSOC

[Behdad Esfahbod]

I find it a *very* bad idea to have code in FreeType that would write to a
file.  Specially bad if that can be controlled by an env-var.

I still think what's desired can be done best by just revamping and writing
custom code in FreeType itself.

This is my last word on this particular topic, but I'll reply to
genuine technical curiosity.

behdad

On Fri, Jun 12, 2020 at 8:47 AM Priyesh kumar 
wrote:

> Hi Werner,
> I have updated the progress report for this week @ here
> 
>
> Thanks,
> Priyesh
>
> On Sat, Jun 6, 2020 at 8:34 PM Werner LEMBERG  wrote:
>
>>
>> > The gnulib repository provides a module 'unistd' for creating a
>> > 'unistd.h' header file; this works on Windows too.
>> >
>> >   https://www.gnu.org/software/gnulib/
>>
>> By the way, the gnulib repository also provides an interface to
>> threads – including Windows.  If you install the corresponding modules
>> you automatically get a configure option
>>
>>   --enable-threads={posix,windows,isoc}
>>
>> (with MSVC and mingw support for 'windows').  The very recent commit
>> 10cf67b5e333 in the gnulib repository describes the available modules
>> and options for multithreading.
>>
>> Note that my knowledge of thread programming is zero, so please handle
>> my observations with some care.
>>
>> Of course, it is problematic for FreeType license-wise to rely on
>> gnulib since the latter uses the LGPLv2+ license.  On the other hand,
>> linking with a logging library would be mainly used for debugging
>> purposes and not for end products, so a dependency on LGPLv2+ might be
>> OK if the corresponding code is properly guarded with preprecessor
>> conditionals (which is a good idea anyway).
>>
>>
>> Werner
>>
>

-- 
behdad
http://behdad.org/

RE: Logging Library-GSOC

[armin]

Hi Priyesh,

> I have updated the progress report for this week @ 
> https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing

Thanks for your update & write-up, looks promising :)  I agree with your 
approach of trying to find the most lightweight C logger that does the job, 
just two quick questions about your work:

(1) do you plan to mainly using the logger to write to files and an equivalent 
of `stderr` consistently across multiple platforms or do you also plan to use 
it to replace some of the handling that's currently done within FreeType (like 
checking + parsing log levels + components, etc) with calls to that library?  I 
believe it would be especially interesting if we managed to move some of the 
components handling out of FT and into that external piece.  Not sure however, 
if any of these libraries have a somehow direct mapping of how components 
(modules) are used for tracing within FT currently (essentially, all 
components/modules can be configured with their own trace level).

(2) have you looked into log4c at any point?  Not saying it is what FreeType 
needs but something that worked reasonably well for me a while ago;  might be a 
lot bigger than what we need or have other downsides, just asking b/c I 
couldn't see it in your list.

Best
Armin

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,
I have updated the progress report for this week @ here


Thanks,
Priyesh

On Sat, Jun 6, 2020 at 8:34 PM Werner LEMBERG  wrote:

>
> > The gnulib repository provides a module 'unistd' for creating a
> > 'unistd.h' header file; this works on Windows too.
> >
> >   https://www.gnu.org/software/gnulib/
>
> By the way, the gnulib repository also provides an interface to
> threads – including Windows.  If you install the corresponding modules
> you automatically get a configure option
>
>   --enable-threads={posix,windows,isoc}
>
> (with MSVC and mingw support for 'windows').  The very recent commit
> 10cf67b5e333 in the gnulib repository describes the available modules
> and options for multithreading.
>
> Note that my knowledge of thread programming is zero, so please handle
> my observations with some care.
>
> Of course, it is problematic for FreeType license-wise to rely on
> gnulib since the latter uses the LGPLv2+ license.  On the other hand,
> linking with a logging library would be mainly used for debugging
> purposes and not for end products, so a dependency on LGPLv2+ might be
> OK if the corresponding code is properly guarded with preprecessor
> conditionals (which is a good idea anyway).
>
>
> Werner
>

Re: Logging Library-GSOC (Re: Freetype-devel Digest, Vol 185, Issue 12)

[Hin-Tak Leung via FreeType development]

 > Date: Fri, 5 Jun 2020 23:04:59 +0530
> From: Priyesh kumar 
> To: Werner LEMBERG , freetype-devel@nongnu.org
> Subject: Re: Logging Library-GSOC
> So, I was thinking to use something like this in ftdebug.h to print the
> tracing component:

> #define FT_COMPONENT( x ) FT_COMPONENT_TAG_( x )
> #define FT_COMPONENT_TAG_ #x
> #define FT_TRACE( level, varformat )
>            do
>    \
>            {
>   \
>              if ( ft_trace_levels[FT_TRACE_COMP( FT_COMPONENT )] >= level )
> { \
>              set_tag( FT_COMPONENT_TAG( FT_COMPONENT ) );
>    \
>              FT_Log varformat;
>   \
>            } while( 0 )
>   \
On Sun, May 24, 2020 at 3:22 PM  wrote:

> ```c
>  FT_Trace_Set_Level( FT_Trace_Level  level );
>
>  typedef void
>  (*FT_Trace_Callback)( FT_Trace_Level  level,
>                        const char*    fmt,
>                        va_list        args );
>
>  FT_Trace_Set_Callback( FT_Trace_Callback  callback );
>
>  FT_Trace_Set_Default_Callback( void );
> ```
>
> Note this is just a quick sketch and the actual callback function might
> have a forth parameter for the module ...  or this can be part of `fmt` and
> `args` ...  tbd :)

This is basically the first version of the FontVal patch: a macro to expand 
DIAGNOSTICS() with more local details, a function callback prototype for 
emitting messages elsewhere, and two new routines to set and unset the callback.
That first patch was posted to the list and should be in the list archive - 
July 2016. I don't think either of you were subscribed in 2016? Anyway, the 
FontVal patch is an enhancement to get diagnostic information out of freetype's 
TrueType hinting instruction interpreter, in a form to make it imitate the 
older Microsoft diagnostic backend, which was not open-sourced.
I am not going to get drawn into another flame war about it... Anyway, the two 
major changes since then was to move the global variable which stores the set 
function pointer, into FT_Face, so it becomes a face-instance variable (and the 
set/unset function gain an additional first FT_Face argument). The 2nd major 
change was to the callback itself, which adds a last "arbitrary payload" 
argument, because it is easier to do that on the C side than on the Perl side 
of trying to recurse inside a C struct in perl, I think.
I imagine for your FT_TRACE, you want to store the callback info in a library 
instance variable - ie you need FT_Library as an argument to set/unset.
Anyway, as I said, the patch is in the list archive in July 2016. The client 
side code are all under my github account ("HinTak") - C# in 
FontVal/Compat/Compat.cs (named because it was a compatibility layer to make 
freetype works like Microsoft's renderer...), python bindings under my 
Freetype-py fork on the font-diag branch, and similar for perl on 
p5-Font-Freetype . All 3 language bindings are maintained, though the main one 
getting attention is the C# one.
The prebuilt freetype binaries are all under FontVal/bin for various arches - 
linux, windows , Mac os x, the latest is Raspbian 32-bit arm.
You are welcomed to play with the 3 language bindings to hook them into a 
different /logging library instead of the FontVal GUI html browser front end 
(or stderr as the python/perl examples do). This might give you some idea how 
your external tracing interface should work.
The 64-bit windows binary is not compatible with 64-bit windows python. Use 
32-bit python if you want to play with it on windows.
Flames > /dev/null
  

Re: Logging Library-GSOC

[Werner LEMBERG]

> The gnulib repository provides a module 'unistd' for creating a
> 'unistd.h' header file; this works on Windows too.
> 
>   https://www.gnu.org/software/gnulib/

By the way, the gnulib repository also provides an interface to
threads – including Windows.  If you install the corresponding modules
you automatically get a configure option

  --enable-threads={posix,windows,isoc}

(with MSVC and mingw support for 'windows').  The very recent commit
10cf67b5e333 in the gnulib repository describes the available modules
and options for multithreading.

Note that my knowledge of thread programming is zero, so please handle
my observations with some care.

Of course, it is problematic for FreeType license-wise to rely on
gnulib since the latter uses the LGPLv2+ license.  On the other hand,
linking with a logging library would be mainly used for debugging
purposes and not for end products, so a dependency on LGPLv2+ might be
OK if the corresponding code is properly guarded with preprecessor
conditionals (which is a good idea anyway).


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> I am currently looking at a library called EasyLogger ( Github Link:
> https://github.com/armink/EasyLogger ).  I would say it could be my
> favourite logging library as it satisfies most of the
> requirements. But the problem is that the plugin which this library
> uses for outputting logs to file uses  *:-P*, therefore is
> not working on windows.

The gnulib repository provides a module 'unistd' for creating a
'unistd.h' header file; this works on Windows too.

  https://www.gnu.org/software/gnulib/

But I agree that a better solution is to avoid it on Windows.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hi Werner,

>*What is your favourite logging library right now?*

I am currently looking at a library called EasyLogger ( Github Link:
https://github.com/armink/EasyLogger ).
I would say it could be my favourite logging library as it satisfies most
of the requirements. But the problem is that
the plugin which this library uses for outputting logs to file uses
  *:-P*, therefore is not working on windows.
I will contact the authors asking for their guidance for this case, and if
things work out I will consider this library for integration.
Other than that I think zf_log is my favourite one till now...



*>Hmm.  Maybe it makes sense to contact the authors or maintainers of>these
libraries, asking for advice how Windows support is intended to>work.
Maybe this link also helps *
Thanks, I will do so...

Thanks,
Priyesh

On Sat, Jun 6, 2020 at 9:33 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > This week I have explored several libraries and I have prepared a
> > report mentioning their pros and cons @here
> > <
> https://docs.google.com/document/d/1X5ApmVxz0pXcGUCF9Um5VhVZV403LWDIYFbKYg1aLoQ/edit?usp=sharing
> >
>
> thanks for that.  Very informative.  A quick comment: I think we can
> move on, requiring C99 for building FreeType.  This standard is more
> than 20 years old...
>
> What is your favourite logging library right now?
>
> > I am using Visual Studios 2019 to build libraries on windows, and
> > while exploring the external libraries I have seen that most of the
> > libraries use  and  which are not supported on
> > windows (even though it is mentioned in the documentation that the
> > library supports Windows).
>
> Hmm.  Maybe it makes sense to contact the authors or maintainers of
> these libraries, asking for advice how Windows support is intended to
> work.  Maybe this link also helps
>
>
> https://stackoverflow.com/questions/2150938/can-i-get-unixs-pthread-h-to-compile-in-windows
>
> > I have also tried Cygwin to compile these libraries on windows but
> > got no success...  Is there a way to compile these libraries on
> > windows other than using Visual Studios and Cygwin?  More
> > importantly, should I consider such libraries?
>
> These are good questions.  Were I the author of such a library, I
> would use preprocessor conditionals to surround code that is
> platform-dependent, either to disable the functionality, or to provide
> a replacement.
>
>
> Werner
>

Re: Logging Library-GSOC

[Werner LEMBERG]

Hello Priyesh,


> This week I have explored several libraries and I have prepared a
> report mentioning their pros and cons @here
> 

thanks for that.  Very informative.  A quick comment: I think we can
move on, requiring C99 for building FreeType.  This standard is more
than 20 years old...

What is your favourite logging library right now?

> I am using Visual Studios 2019 to build libraries on windows, and
> while exploring the external libraries I have seen that most of the
> libraries use  and  which are not supported on
> windows (even though it is mentioned in the documentation that the
> library supports Windows).

Hmm.  Maybe it makes sense to contact the authors or maintainers of
these libraries, asking for advice how Windows support is intended to
work.  Maybe this link also helps

  
https://stackoverflow.com/questions/2150938/can-i-get-unixs-pthread-h-to-compile-in-windows

> I have also tried Cygwin to compile these libraries on windows but
> got no success...  Is there a way to compile these libraries on
> windows other than using Visual Studios and Cygwin?  More
> importantly, should I consider such libraries?

These are good questions.  Were I the author of such a library, I
would use preprocessor conditionals to surround code that is
platform-dependent, either to disable the functionality, or to provide
a replacement.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hey,
This week I have explored several libraries and I have prepared a report
mentioning their pros and cons @here

I am using Visual Studios 2019 to build libraries on windows, and while
exploring the external libraries I have seen that most of the
libraries use  and  which are not supported on windows
(even though it is mentioned in the documentation that
the library supports Windows).
I have also tried Cygwin to compile these libraries on windows but got no
success...
Is there a way to compile these libraries on windows other than using
Visual Studios and Cygwin? More importantly, should I consider
such libraries?

One more thing that I have noticed is that most of the libraries provide *tags
*that could be printed with log messages.
So, I was thinking to use something like this in ftdebug.h to print the
tracing component:

#define FT_COMPONENT( x ) FT_COMPONENT_TAG_( x )
#define FT_COMPONENT_TAG_ #x
#define FT_TRACE( level, varformat )
   do
   \
   {
  \
 if ( ft_trace_levels[FT_TRACE_COMP( FT_COMPONENT )] >= level )
{ \
 set_tag( FT_COMPONENT_TAG( FT_COMPONENT ) );
   \
 FT_Log varformat;
  \
   } while( 0 )
   \


Please, look into the report and let me know if there are any concerns...
Thanks,
Priyesh

On Sun, May 24, 2020 at 3:22 PM  wrote:

> Hi Priyesh,
>
> > 2. Modifying the output stream at runtime.
> >
> >a. Dynamic change of desired output log levels.
> >b. Dynamic log redirection.
> >
> > [...]
> >
> > All of this should be configurable either with a config file or with
> > environment variables.  I'm not sure how item 2 can be handled best; if
> this
> > feature is active it maybe makes sense to force re-reading of environment
> > variables and config files as sonn as a FreeType API function is called.
>
> I believe a good way to handle point 2 (and blend in well with the rest of
> the project) is to allow overrides of the these values (from the config
> file or env variables) with dedicated functions at runtime; something like
>
> ```c
>   FT_Trace_Set_Level( FT_Trace_Level  level );
>
>   typedef void
>   (*FT_Trace_Callback)( FT_Trace_Level  level,
> const char* fmt,
> va_list args );
>
>   FT_Trace_Set_Callback( FT_Trace_Callback  callback );
>
>   FT_Trace_Set_Default_Callback( void );
> ```
>
> Note this is just a quick sketch and the actual callback function might
> have a forth parameter for the module ...  or this can be part of `fmt` and
> `args` ...  tbd :)
>
> One thought also on the timestamps:  let's plan them flexible please (at
> least on/off toggle-able per env variable) as there's a good chance that
> you want to use your own TS format when retrieving the logs through the
> callback.
>
> I totally agree with the rest :)
>
> Have a lovely Sunday,
> Armin
>
>

RE: Logging Library-GSOC

[armin]

Hi Priyesh,

> 2. Modifying the output stream at runtime.
>
>a. Dynamic change of desired output log levels.
>b. Dynamic log redirection.
>
> [...]
>
> All of this should be configurable either with a config file or with
> environment variables.  I'm not sure how item 2 can be handled best; if this
> feature is active it maybe makes sense to force re-reading of environment
> variables and config files as sonn as a FreeType API function is called.

I believe a good way to handle point 2 (and blend in well with the rest of the 
project) is to allow overrides of the these values (from the config file or env 
variables) with dedicated functions at runtime; something like

```c
  FT_Trace_Set_Level( FT_Trace_Level  level );

  typedef void
  (*FT_Trace_Callback)( FT_Trace_Level  level,
const char* fmt,
va_list args );

  FT_Trace_Set_Callback( FT_Trace_Callback  callback );

  FT_Trace_Set_Default_Callback( void );
```

Note this is just a quick sketch and the actual callback function might have a 
forth parameter for the module ...  or this can be part of `fmt` and `args` ... 
 tbd :)

One thought also on the timestamps:  let's plan them flexible please (at least 
on/off toggle-able per env variable) as there's a good chance that you want to 
use your own TS format when retrieving the logs through the callback.

I totally agree with the rest :)

Have a lovely Sunday,
Armin

Re: Logging Library-GSOC

[Werner LEMBERG]

Hello Priyesh,


> Clearly there is some problem with the current logger, but I think
> the requirements which are mentioned on the FreeType's GSoC page and
> the requirements which are discussed being here are different...

I don't think so.  It's only that David T. is back, and he wasn't part
of the earlier discussions that we had some time ago :-)

> Please could you guys guide me with the actual requirements as there
> is very little time left for coding to begin...

Don't worry about the timing; investigating what to use and how is
*part* of GSoC.

Irrespective of that, Armin has added some quite useful things that I
haven't thought before, and which are definitely worth to be
considered and implemented.

To summarize: I want an improved logging facility that ideally doesn't
change how errors are marked within the FreeType source code (i.e.,
continued use of `FT_TRACEx`).  However, it should provide
possibilities to adapt the debugging output data to various needs.

1. Flexible formatting of the messages, for example

   a. Displaying the tracing component (i.e., the value of the
  `FT_COMPONENT` macro), and
   b. Showing a time stamp.

2. Modifying the output stream at runtime.

   a. Dynamic change of desired output log levels.
   b. Dynamic log redirection.

3. Hide platform-specific logging details from FreeType.

All of this should be configurable either with a config file or with
environment variables.  I'm not sure how item 2 can be handled best;
if this feature is active it maybe makes sense to force re-reading of
environment variables and config files as sonn as a FreeType API
function is called.

To avoid library dependencies, the following seems appropriate.

1. The logging library should be statically linked with FreeType.
2. Its source should be distributed with the FreeType source code
   bundle: It gets imported into the FreeType git repository as a git
   submodule, and `make dist` should add it to the distribution
   tarball.

In case there isn't a library that fits our needs, or that cannot be
easily adapted to the desired purposes, it's necessary to investigate
how to implement at least a part of the above ideas directly in
FreeType.


Werner

Re: Logging Library-GSOC

[Priyesh kumar]

Hey guys,
After going through the discussion, I think I am confused about the actual
requirements from the project.
Clearly there is some problem with the current logger, but I think the
requirements which are mentioned on the FreeType's GSoC page and the
requirements which are discussed being here
are different...
Please could you guys guide me with the actual requirements as there is
very little time left for coding to begin...
Thanks
Priyesh

On Thu, May 21, 2020 at 2:07 PM  wrote:

> > Armin, could you chime in and add your opinion?
>
> Gladly, sorry for the delay guys!
>
> >> 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.
> >
> > Mhmm, yes and no.  For example, if you want to have time stamps in the
> logging
> > output, too, you have to take care of the OS since you are entering
> > platform-specific behaviour.  It would be nice if this is completely
> hidden.
>
> Agreed;  also in addition, the two biggest things to be improved from my
> perspective:
>
>   1. Dynamic change of desired output log levels
>   2. Dynamic log redirection
>
> I've recently been working on long-running (for days/weeks straight) video
> transcoders, depending on several libraries like FFmpeg, FreeType, ...  One
> thing that is 100% needed is to change log levels on the fly (enable more
> logging as things go south) and be able to redirect logs to wherever I want
> them to go, separate for each library, maybe prefixed differently on the
> fly
> (files, memory, ...  best case, again, changeable at runtime).  I consider
> both things reasonably standard and something I'd love to see in FreeType
> as
> well :)
>
> About external dependencies:  everything you don't build yourself leaves
> more time for the things you actually want to build.  I do get the concern
> (it's a trade-off) but the question IMO is how easy it is to replace
> dependencies.  In terms of an external logging library I imagine it to be
> very easily replaceable should that become interesting at some point.
>
> A few more thoughts about recent messages (didn't chime in since, by the
> point I read it, it was already answered in a way that I agreed with):
>
>   - 100% submodule + static linking
>
>   - Let's keep using various FreeType macros within the code base and use
> the
> external library mainly for writing out + the filtering / forwarding /
> flexibility part
>
> The biggest upside of an external logging lib IMO is not to care about its
> implementation and cross platform compatibility, just use something that's
> been tried + tested and spend all the more time on the core business of
> font
> rendering.  Also provide users of FreeType a way to extract logs in an
> extremely flexible way that does not require users to dig deep into the
> implementation of the codebase in order to write a personalised log
> callback
> function that filters and converts relevant logs and requires users to do
> all sorts of nasty downcasts that really only library implementers are
> comfortable doing.
>
> Just a few thoughts, happy to discuss further :)
>
>

RE: Logging Library-GSOC

[armin]

> Armin, could you chime in and add your opinion?

Gladly, sorry for the delay guys!

>> 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.
>
> Mhmm, yes and no.  For example, if you want to have time stamps in the
logging
> output, too, you have to take care of the OS since you are entering
> platform-specific behaviour.  It would be nice if this is completely
hidden.

Agreed;  also in addition, the two biggest things to be improved from my
perspective:

  1. Dynamic change of desired output log levels
  2. Dynamic log redirection

I've recently been working on long-running (for days/weeks straight) video
transcoders, depending on several libraries like FFmpeg, FreeType, ...  One
thing that is 100% needed is to change log levels on the fly (enable more
logging as things go south) and be able to redirect logs to wherever I want
them to go, separate for each library, maybe prefixed differently on the fly
(files, memory, ...  best case, again, changeable at runtime).  I consider
both things reasonably standard and something I'd love to see in FreeType as
well :)

About external dependencies:  everything you don't build yourself leaves
more time for the things you actually want to build.  I do get the concern
(it's a trade-off) but the question IMO is how easy it is to replace
dependencies.  In terms of an external logging library I imagine it to be
very easily replaceable should that become interesting at some point.

A few more thoughts about recent messages (didn't chime in since, by the
point I read it, it was already answered in a way that I agreed with):

  - 100% submodule + static linking

  - Let's keep using various FreeType macros within the code base and use
the
external library mainly for writing out + the filtering / forwarding /
flexibility part

The biggest upside of an external logging lib IMO is not to care about its
implementation and cross platform compatibility, just use something that's
been tried + tested and spend all the more time on the core business of font
rendering.  Also provide users of FreeType a way to extract logs in an
extremely flexible way that does not require users to dig deep into the
implementation of the codebase in order to write a personalised log callback
function that filters and converts relevant logs and requires users to do
all sorts of nasty downcasts that really only library implementers are
comfortable doing.

Just a few thoughts, happy to discuss further :)

Re: Logging Library-GSOC

[Werner LEMBERG]

David wrote:

> 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.

Mhmm, yes and no.  For example, if you want to have time stamps in the
logging output, too, you have to take care of the OS since you are
entering platform-specific behaviour.  It would be nice if this is
completely hidden.

> 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.

Armin, could you chime in and add your opinion?


Werner

Re: Logging Library-GSOC

[David Turner]

Le mar. 19 mai 2020 à 09:30, Priyesh kumar  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  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
>>
>

Re: Logging Library-GSOC

[Priyesh kumar]

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...

Thanks,
Priyesh

On Mon, May 18, 2020 at 9:03 PM Werner LEMBERG  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
>

Re: Logging Library-GSOC

[Werner LEMBERG]

> Also in the last message you said you would explore logging
> libraries, and I would be curious about the results, i.e.:
> 
> - Can you give one *concrete example* of an actual logging library
>   that would be useful for FreeType developers for development
>   purposes.  Because I failed to find one.

Investigating this is part of the GSoC project :-)

> - What would be the actual benefits to using an external logging
>   library really?

(a) We don't have to fiddle with OS-specific details.
(b) Better control of log formatting.
(c) Possibly a config file for (a) and/or (b) in addition to
environment variables.

> Note that the quality of the logging library(ies) has nothing to do
> with this.  I would rather not introduced a surperfluous dependency
> to the build.

As mentioned in another e-mail, it wouldn't be a dependency since it
should be always statically linked.


Werner

Re: Logging Library-GSOC

[Werner LEMBERG]

> 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

Re: Logging Library-GSOC

[Priyesh kumar]

Hello David,

Thanks for the response.

*>What would be the actual benefits to using an external logging library
really? The only thing I can think of is using structured debug messages
(i.e. sending a (component, level, message) >tuple instead of a string to
whatever receives the log messages, to allow better filtering). But we can
easily refactor ftdebug.c to do that, with a default implementation that
prints to stderr / , >and a debug-only API to inject a custom sink callback
at runtime. Only then can we decide to optionally provide a sink that
depends on a specific third-party library, as an option.*

As far as I have understood the problem statement under this project @
https://www.freetype.org/gsoc.html is that the current logging capabilities
of FreeType only print the logs on stderr and to scale the FreeType for
multiple platforms where something similar to stderr don't exist, there is
need to write the logs on files present on the file system. My queries were
with respect to this use case.

I am sorry I am unable to fully understand your concern in this regard. Can
you please provide more insight on this?

*>Can you give one concrete example of an actual logging library that would
be useful for FreeType developers for development purposes. Because I
failed to find one.*

Regarding the library's exploration, it is still in progress and will keep
you posted on the same. Some time back I explored zlog library and it was
meeting some of our requirements but it was never finalized. Would like to
hear from you on this?

Also, if possible, can you please let me know which all libraries have
already been explored and any documentation around this will help?

Initially, we did discussed to change the ftdebug.c to write the logs on
file system rather than using an external library but later we concluded
that the external library will be more beneficial since they have matured
and well tested APIs.


*>Do you plan to improve the debugging macros used by FreeType. If so, how
exactly?*
I am still in the exploration phase and will plan the changes according to
the external library...

Thanks,
Priyesh

On Mon, May 18, 2020 at 3:46 PM David Turner  wrote:

>
>
> Le lun. 18 mai 2020 à 10:49, Priyesh kumar  a
> écrit :
>
>> Thanks for the reply...
>>
>> *>I recommend not baking details of the logging library into the rest of
>> FreeType whenever possible. One thing that can be done is to send
>> structured logs from FreeType, i.e. instead of >FT_Message() sending a
>> string to whatever log, the function could instead send a (component,
>> level, message) tuple, which would allow filtering externally (in the log
>> library, through >whatever means are necessary). Also something useful when
>> tracing is scoping traces with start/stop events, but that would require
>> new FT_TRACE_XXX() macros, so should probably be >considered a stretch
>> goal. Just keep this in mind if you intend to modify that part of the code.*
>> Got that...will keep this in mind while exploring external logging
>> libraries.
>>
>> *>I still don't know what the benefits of these external logging
>> libraries will be. Can you clarify what are we supposed to gain from this
>> in practical terms? Every dependency we add to the >library becomes a
>> maintenance burden, so I would be in favor of the least coupling possible.*
>> Yes, I agree that any new library adds to maintenance burden but we
>> already had a discussion around this sometime back. The summary of the
>> discussion was that a well maintained external library comes with mature
>> API's and gets a lot of testing and hence that would be ideal to integrate.
>> Please refer to this mail thread for details(
>> https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html )
>> and let me know in case of any concern.
>>
>> I'm afraid, this thread doesn't seem to answer any of my concerns. Also
> in the last message you said you would explore logging libraries, and I
> would be curious about the results, i.e.:
>
> - Can you give one *concrete example* of an actual logging library that
> would be useful for FreeType developers for development purposes. Because I
> failed to find one.
>
> - What would be the actual benefits to using an external logging library
> really? The only thing I can think of is using structured debug messages
> (i.e. sending a (component, level, message) tuple instead of a string to
> whatever receives the log messages, to allow better filtering). But we can
> easily refactor ftdebug.c to do that, with a default implementation that
> prints to stderr / , and a debug-only API to inject a custom sink callback
> at runtime. Only then can we decide to optionally provide a sink that
> depends on a specific third-party library, as an option.
>
> - Do you plan to improve the debugging macros used by FreeType. If so, how
> exactly?
>
> Note that the quality of the logging library(ies) has nothing to do with
> this. I would rather not introduced a surperfluous 

Re: Logging Library-GSOC

[David Turner]

Le lun. 18 mai 2020 à 10:49, Priyesh kumar  a
écrit :

> Thanks for the reply...
>
> *>I recommend not baking details of the logging library into the rest of
> FreeType whenever possible. One thing that can be done is to send
> structured logs from FreeType, i.e. instead of >FT_Message() sending a
> string to whatever log, the function could instead send a (component,
> level, message) tuple, which would allow filtering externally (in the log
> library, through >whatever means are necessary). Also something useful when
> tracing is scoping traces with start/stop events, but that would require
> new FT_TRACE_XXX() macros, so should probably be >considered a stretch
> goal. Just keep this in mind if you intend to modify that part of the code.*
> Got that...will keep this in mind while exploring external logging
> libraries.
>
> *>I still don't know what the benefits of these external logging libraries
> will be. Can you clarify what are we supposed to gain from this in
> practical terms? Every dependency we add to the >library becomes a
> maintenance burden, so I would be in favor of the least coupling possible.*
> Yes, I agree that any new library adds to maintenance burden but we
> already had a discussion around this sometime back. The summary of the
> discussion was that a well maintained external library comes with mature
> API's and gets a lot of testing and hence that would be ideal to integrate.
> Please refer to this mail thread for details(
> https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html )
> and let me know in case of any concern.
>
> I'm afraid, this thread doesn't seem to answer any of my concerns. Also in
the last message you said you would explore logging libraries, and I would
be curious about the results, i.e.:

- Can you give one *concrete example* of an actual logging library that
would be useful for FreeType developers for development purposes. Because I
failed to find one.

- What would be the actual benefits to using an external logging library
really? The only thing I can think of is using structured debug messages
(i.e. sending a (component, level, message) tuple instead of a string to
whatever receives the log messages, to allow better filtering). But we can
easily refactor ftdebug.c to do that, with a default implementation that
prints to stderr / , and a debug-only API to inject a custom sink callback
at runtime. Only then can we decide to optionally provide a sink that
depends on a specific third-party library, as an option.

- Do you plan to improve the debugging macros used by FreeType. If so, how
exactly?

Note that the quality of the logging library(ies) has nothing to do with
this. I would rather not introduced a surperfluous dependency to the build.

- David


> Thanks,
> Priyesh
>

Re: Logging Library-GSOC

[Priyesh kumar]

Thanks for the reply...

*>I recommend not baking details of the logging library into the rest of
FreeType whenever possible. One thing that can be done is to send
structured logs from FreeType, i.e. instead of >FT_Message() sending a
string to whatever log, the function could instead send a (component,
level, message) tuple, which would allow filtering externally (in the log
library, through >whatever means are necessary). Also something useful when
tracing is scoping traces with start/stop events, but that would require
new FT_TRACE_XXX() macros, so should probably be >considered a stretch
goal. Just keep this in mind if you intend to modify that part of the code.*
Got that...will keep this in mind while exploring external logging
libraries.

*>I still don't know what the benefits of these external logging libraries
will be. Can you clarify what are we supposed to gain from this in
practical terms? Every dependency we add to the >library becomes a
maintenance burden, so I would be in favor of the least coupling possible.*
Yes, I agree that any new library adds to maintenance burden but we already
had a discussion around this sometime back. The summary of the discussion
was that a well maintained external library comes with mature API's and
gets a lot of testing and hence that would be ideal to integrate. Please
refer to this mail thread for details(
https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html )
and let me know in case of any concern.

Thanks,
Priyesh

Re: Logging Library-GSOC

[Vincent Torri]

On Mon, May 18, 2020 at 9:28 AM David Turner  wrote:
>
>
>
> Le lun. 18 mai 2020 à 09:03, Priyesh kumar  a écrit :
>>
>> Hey,
>> I wanted to ask that after selecting desirable external library how should I 
>> proceed:
>> 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?
>> OR
>> 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?
>>
> I recommend not baking details of the logging library into the rest of 
> FreeType whenever possible. One thing that can be done is to send structured 
> logs from FreeType, i.e. instead of FT_Message() sending a string to whatever 
> log, the function could instead send a (component, level, message) tuple, 
> which would allow filtering externally (in the log library, through whatever 
> means are necessary). Also something useful when tracing is scoping traces 
> with start/stop events, but that would require new FT_TRACE_XXX() macros, so 
> should probably be considered a stretch goal. Just keep this in mind if you 
> intend to modify that part of the code.
>
>>
>> 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 still don't know what the benefits of these external logging libraries will 
> be. Can you clarify what are we supposed to gain from this in practical 
> terms? Every dependency we add to the library becomes a maintenance burden, 
> so I would be in favor of the least coupling possible.
>

what about dlopen this external log lib ?

Vincent Torri