Re: logging support ready for integration into master

[Priyesh kumar]

Hello Werner,

*> Fixed, thanks, and force-pushed!  Please test.*
I have tested the changes with the demo programs and
it is working fine now.. : D

Thanks,
Priyesh

On Fri, Dec 4, 2020 at 8:52 PM Werner LEMBERG  wrote:

> > > Which commit (from your GSoC branch) are you referring to?
> >
> > The changes in `include/freetype/internal/ftdebug.h' in commit
> > 802176853 are missing in `logging' branch.
>
> Fixed, thanks, and force-pushed!  Please test.
>
>
> Werner
>

Re: logging support ready for integration into master

[Priyesh kumar]

Hi Werner,


*> I've incorporated your patch into the corresponding commit, then doing>
a `git push -f`.*
Ok, Great !!

*> Which commit (from your GSoC branch)*
*> are you referring to?*
The changes in `include/freetype/internal/ftdebug.h' in commit:
802176853b5418d34704f1705617333145410625 (link
)
are missing in `logging' branch.

We only have to do the following additions to make it work:
--
diff --git a/include/freetype/internal/ftdebug.h
b/include/freetype/internal/ftdebug.h
index e19f9e176..370f0f632 100644
--- a/include/freetype/internal/ftdebug.h
+++ b/include/freetype/internal/ftdebug.h
@@ -123,7 +123,12 @@ FT_BEGIN_HEADER

 \
 ft_add_tag( dlg_tag );
  \
 if ( ft_trace_levels[FT_TRACE_COMP( FT_COMPONENT )] >= level )
\
-  dlg_trace varformat;
  \
+{
\
+  if( custom_output_handler != NULL )
 \
+FT_Logging_Callback varformat;
   \
+  else
   \
+dlg_trace varformat;
  \
+}
 \
 ft_remove_tag( dlg_tag );
   \
   } while( 0 )
--

Thanks,
Priyesh

On Fri, Dec 4, 2020 at 12:03 AM Werner LEMBERG  wrote:

>
> > The updated code is working fine when we are using the `FT2_DEBUG'
> > environment variable with tags(-v / -t / -vt), but without these
> > tags I am getting corrupted memory issue with the `features_buf'
> > char array in `src/base/ftdebug.c(ft_log_handler)' on both Ubuntu
> > and Windows.
>
> D'oh.  I was *sure* that I've tested that...  Thanks for catching.
> I've incorporated your patch into the corresponding commit, then doing
> a `git push -f`.
>
> > Also, the logic to handle the custom log handler is not present in
> > `FT_LOG' macro in `include/freetype/internal/ftdebug.h', have you
> > removed that feature, or did you missed to update it?
>
> I seem to have missed it, sorry.  Which commit (from your GSoC branch)
> are you referring to?
>
>
> Werner
>

Re: logging support ready for integration into master

[Priyesh kumar]

Hi Werner,
Thanks for doing the additions. The code is looking much cleaner now : D

The updated code is working fine when we are using the `FT2_DEBUG'
environment
variable with tags(-v / -t / -vt), but without these tags I am getting
corrupted memory
issue with the `features_buf' char array in
`src/base/ftdebug.c(ft_log_handler)' on both
Ubuntu and Windows.

In `src/base/ftdebug.c:492' we are updating the `bufp' pointer to point to
(features_length-1) th
position but that would point to a wrong memory address if there are no
additions in `features_length'
variable.
I am attaching a patch file with a fix : )

Also, the logic to handle the custom log handler is not present in `FT_LOG'
macro in
`include/freetype/internal/ftdebug.h', have you removed that feature, or
did you missed
to update it?

Thanks,
Priyesh

On Wed, Dec 2, 2020 at 6:58 PM Werner LEMBERG  wrote:

>
> I've just pushed the branch 'logging' to the git repository that
> contains the Priyesh's GSoC project, with all commits beautified, and
> with many necessary additions.
>
> Please have a look!
>
>
> Werner
>
diff --git a/builds/windows/ftdebug.c b/builds/windows/ftdebug.c
index f2a1ce2f4..389b9d8a9 100644
--- a/builds/windows/ftdebug.c
+++ b/builds/windows/ftdebug.c
@@ -500,9 +500,10 @@
   }
 
   if ( ft_component_flag || ft_timestamp_flag )
+  {
 ft_strncpy( features_buf, features, features_length );
-
-  bufp += features_length - 1;
+bufp += features_length - 1;
+  }
 
   if ( ft_component_flag )
   {
diff --git a/src/base/ftdebug.c b/src/base/ftdebug.c
index 48bd52a92..c8340bbd2 100644
--- a/src/base/ftdebug.c
+++ b/src/base/ftdebug.c
@@ -487,9 +487,10 @@
   }
 
   if ( ft_component_flag || ft_timestamp_flag )
+  {
 ft_strncpy( features_buf, features, features_length );
-
-  bufp += features_length - 1;
+bufp += features_length - 1;
+  }
 
   if ( ft_component_flag )
   {

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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
<https://github.com/Priyeshkkumar/FreeTypeExamples/tree/master/Windows/main> ,
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

[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

[Priyesh kumar]

Hi,
I was trying profiling on the example program given @ here
<https://www.freetype.org/freetype2/docs/tutorial/example1.c>.
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
<https://stackoverflow.com/questions/5248915/execution-time-of-c-program> .
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
>>>> 

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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
<https://sourceforge.net/projects/log4c/files/log4c/1.2.4/mingw-bin/> 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

[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

[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

[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

[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

[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

[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

[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

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

[Priyesh kumar]

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?

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.

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.

Please guide me...
Thanks
Priyesh

Logging Library-GSOC

[Priyesh kumar]

Hey,
I was exploring the logging libraries as per the requirements, and I was
thinking of adding functionality to automatically check whether the logging
library is installed or not as FreeType does for other libraries like
Harfbuzz and libpng.
But most of the logging libraries which I have seen till now do not produce
.pc file.
So, Is there some other way to automatically detect the metadata about the
library or do I have to use environment variables (like HARFBUZZ_CFLAGS and
HARFBUZZ_LIBS) to get metadata from the user?

Thanks,
Priyesh

Requirements from external logging library

[Priyesh kumar]

Hello everyone,
As according to my GSOC project which is integrating an external logging
library with FreeType. I need some help gathering the requirements that the
external library should satisfy.
>From earlier discussion, below are basic some requirements:
1. It should be written in C language (features not more than C99).
2. Should support various platforms such as Windows, UNIX based platforms
like GNU/Linux, and BSD.

Please help me gather enough requirements so that I should proceed to
explore the external logging libraries.
Thanks,
Priyesh

GSOC

[Priyesh kumar]

Hey,
I am glad to know that I got selected for the GSOC. I would like to thank
my mentor @Werner LEMBERG   and all other community members for
their continuous support and guidance.

I am very excited to work in FreeType and will need further guidance and
support from this group.

Thanks again!!
Priyesh

Re: tracing and logging library - GSOC Project

[Priyesh kumar]

Thanks for the reply,
As per the reply, my main focus for this project will be on the
following platforms:

   - Windows
   - macOS
   - Linux
   - iOS
   - ChromeOS
   - Android
   - ReactOS

Further, I have query related to the testing part of the project. I know
the basic testing will be surely part of this project. But just wanted to
check the scope of testing that is required as part of this project on
these platforms.
Is there any support for different test environments already available?
Thank you...


On Sun, Mar 22, 2020 at 12:46 PM Werner LEMBERG  wrote:

>
> > It seems according to the FreeType official website support the
> > following platforms: [...]
> >
> >- Ghostscript
>
> This is not a platform per se.
>
> > Further going through the codebase I also found out that following
> > platforms are also supported by FreeType:
> >
> >- Amiga
> >- Atari
> >- BeOS
> >- Mac
> >- Symbian
>
> The above are more or less dead.  ('Mac' here means the old, non-Unix
> OS.)
>
> >- OS2
> >- OpenVMS
>
> These two platforms are a bit less dead :-)  However, you don't have
> to take special care for them.
>
> >- Windows
>
> Windows is important and one of main reasons for contemplating on the
> use of a logging library, since on that platform GUI programs can't
> send stderr output to the console.
>
> Note that I would like to have a fallback to stderr in case a logging
> library is not available.
>
>
> Werner
>

Re: tracing and logging library - GSOC Project

[Priyesh kumar]

Hi,

I was trying to make the list of platforms on which logger needs to be
enhanced so that I could find the logging library as per the requirement
for my proposal. It seems according to the FreeType official website
support the following platforms:

   - GNU/Linux
   - iOS
   - Android
   - ChromeOS
   - ReactOS
   - Ghostscript

Further going through the codebase I also found out that following
platforms are also supported by FreeType:

   - Amiga
   - Atari
   - BeOS
   - Mac
   - OS2
   - Symbian
   - OpenVMS
   - Windows

This seems to be a long list and hence I wanted to confirm the platforms
that are actively supported and are under the scope of this project.

Thank You...

On Wed, Mar 4, 2020 at 3:02 AM Priyesh kumar 
wrote:

> *>Hold your horses – what you do currently is already part of the GSoC*
>
> *>project! Right now you should do some preliminary investigations only*
>
> *>so that you are able to write a useful proposal.*
>
> Got it! :)
>
> *>That said, `zlog` looks indeed promising. Not sure about the Windows*
>
> *>port, however; maybe this needs some extra work.*
>
> I will definitely look into the windows library...
>
> Thanks...
>
> On Wed, Mar 4, 2020 at 1:30 AM Werner LEMBERG  wrote:
>
>>
>> Hello Priyesh,
>>
>>
>> > Working forward in an external library hunt i came across two
>> > C based logging libraries: [...]
>> >
>> > I am also working on a prototype that will print log messages
>> > generated by FT_ERROR into a log file.
>>
>> Hold your horses – what you do currently is already part of the GSoC
>> project!  Right now you should do some preliminary investigations only
>> so that you are able to write a useful proposal.
>>
>> [If you want to work on that project without being part of GSoC this
>>  would be nice too and very welcomed, of course.]
>>
>> That said, `zlog` looks indeed promising.  Not sure about the Windows
>> port, however; maybe this needs some extra work.
>>
>> > Please guide me if I am working in right direction..
>>
>> You are :-)
>>
>>
>> Werner
>>
>

Re: tracing and logging library - GSOC Project

[Priyesh kumar]

*>Hold your horses – what you do currently is already part of the GSoC*

*>project! Right now you should do some preliminary investigations only*

*>so that you are able to write a useful proposal.*

Got it! :)

*>That said, `zlog` looks indeed promising. Not sure about the Windows*

*>port, however; maybe this needs some extra work.*

I will definitely look into the windows library...

Thanks...

On Wed, Mar 4, 2020 at 1:30 AM Werner LEMBERG  wrote:

>
> Hello Priyesh,
>
>
> > Working forward in an external library hunt i came across two
> > C based logging libraries: [...]
> >
> > I am also working on a prototype that will print log messages
> > generated by FT_ERROR into a log file.
>
> Hold your horses – what you do currently is already part of the GSoC
> project!  Right now you should do some preliminary investigations only
> so that you are able to write a useful proposal.
>
> [If you want to work on that project without being part of GSoC this
>  would be nice too and very welcomed, of course.]
>
> That said, `zlog` looks indeed promising.  Not sure about the Windows
> port, however; maybe this needs some extra work.
>
> > Please guide me if I am working in right direction..
>
> You are :-)
>
>
> Werner
>

Re: tracing and logging library - GSOC Project

[Priyesh kumar]

Hey,
Working forward in an external library hunt i came across two C based
logging libraries:
1.log4c
2.zlog
In the above mentioned libraries zlog claims to be faster, more safer and
powerful.
It is also well tested and mature, it also has a windows version.
Some of zlog's features which i think could be useful for this project are:

   - log messages could be formatted according to our needs.
   - It has six default log levels and we can also define our own log
   levels ( could be used to define 8 levels of debugging in FT_TRACE )
   - Highly Accurate and 1000 times faster than syslog ( claimed in
   documentation )
   - It is also self debuggable i.e. it can output it's own debug and error
   logs
   - Thread safe for multi process situations

I am also working on a prototype that will print log messages generated by
FT_ERROR into a log file.
Please guide me if I am working in right direction..


On Thu, Feb 27, 2020 at 10:14 AM Priyesh kumar 
wrote:

>
>
>
> *>In other words, my gut feeling says no to the idea of using
> any>different code language. The logging facility should be written in>the
> C language, too, not using more recent features than C99 so that>older
> compilers support it.*
>
> Got it!! Thanks for your suggestion... I will keep this in mind.
>
>
>
>
> *>It's not a *requirement* to use an external logging library (in spite>of
> the project's name), but there are good arguments to not re-invent>the
> wheel. In particular, it can be expected that a well-maintained>external
> library gets a lot of testing and comes with a mature API.*
>
> Thanks, I agree with your point that an external library would be well
> tested and mature. I thought in that direction as well but thought if
> somehow I could get rid of integrating an external library.
> Since quality is an important aspect, I will focus on the external library
> part going forward.
>
> As per my understanding FreeType's Logger consists of following basic
> Macros for printing log messages:
> 1.FT_ERROR: for serious error messages.
> 2.FT_ASSERT: for checking assertions at runtime.
> 3.FT_TRACE: for general-purpose debugging messages with 8 levels of
> debugging( 0 - 7 ). Different components in FreeType could have different
> debug level. These levels are specified using FT2_DEBUG environment
> variable.
> Other logger features can be easily taken care( like they are today) if we
> find a replacement for above basic Macro functions.
>
> Going forward, I will explore logging libraries and will check if one or
> more of them will meet the above requirements either by directly
> integrating them or by adding a little bit of logic on top of them.
> Please guide me if I am on the right track.
>
> Thank You
>
> On Tue, Feb 25, 2020 at 12:00 PM Werner LEMBERG  wrote:
>
>>
>> Hello Priyesh!
>>
>>
>> Thanks for your interest in FreeType.
>>
>> >[...] Therefore, I propose to implement separate code files for
>> >logging, which could be based on C++ and can be easily plugged
>> >into the existing C code base.  In addition to this, improving a
>> >bit on documentation can contribute to better understating of
>> >existing logger codebase.
>>
>> I'm not sure I like this.
>>
>> Debugging is at the very heart of FreeType.  Assume that you have to
>> identify a bug, and you work in an environment for an exotic platform
>> that only provides an (old) C compiler.  Your suggestion implies that
>> you no longer can activate debugging output at all on such a platform!
>>
>> In other words, my gut feeling says no to the idea of using any
>> different code language.  The logging facility should be written in
>> the C language, too, not using more recent features than C99 so that
>> older compilers support it.
>>
>> > Based on above points, all these changes could be done without
>> > embedding an external library.  Having said that, if it is really a
>> > requirement to replace the current logging facility with an external
>> > one, there is an external C based logging library named "Zlog"
>> > already been discussed on mailing list here
>> > <
>> https://lists.nongnu.org/archive/html/freetype-devel/2019-01/msg00023.html
>> >.
>> > I can work on it and explore other available external library
>> > option.
>>
>> It's not a *requirement* to use an external logging library (inspite
>> of the project's name), but there are good arguments to not re-invent
>> the wheel.  In particular, it can be expected that a well-maintained
>> external library gets a lot of testing and comes with a mature API.
>>
>>
>> Werner
>>
>>
>> PS: The current use of the debugging macros are documented in
>> `doc/DEBUG`.
>>
>

Re: tracing and logging library - GSOC Project

[Priyesh kumar]

*>In other words, my gut feeling says no to the idea of using any>different
code language. The logging facility should be written in>the C language,
too, not using more recent features than C99 so that>older compilers
support it.*

Got it!! Thanks for your suggestion... I will keep this in mind.




*>It's not a *requirement* to use an external logging library (in spite>of
the project's name), but there are good arguments to not re-invent>the
wheel. In particular, it can be expected that a well-maintained>external
library gets a lot of testing and comes with a mature API.*

Thanks, I agree with your point that an external library would be well
tested and mature. I thought in that direction as well but thought if
somehow I could get rid of integrating an external library.
Since quality is an important aspect, I will focus on the external library
part going forward.

As per my understanding FreeType's Logger consists of following basic
Macros for printing log messages:
1.FT_ERROR: for serious error messages.
2.FT_ASSERT: for checking assertions at runtime.
3.FT_TRACE: for general-purpose debugging messages with 8 levels of
debugging( 0 - 7 ). Different components in FreeType could have different
debug level. These levels are specified using FT2_DEBUG environment
variable.
Other logger features can be easily taken care( like they are today) if we
find a replacement for above basic Macro functions.

Going forward, I will explore logging libraries and will check if one or
more of them will meet the above requirements either by directly
integrating them or by adding a little bit of logic on top of them.
Please guide me if I am on the right track.

Thank You

On Tue, Feb 25, 2020 at 12:00 PM Werner LEMBERG  wrote:

>
> Hello Priyesh!
>
>
> Thanks for your interest in FreeType.
>
> >[...] Therefore, I propose to implement separate code files for
> >logging, which could be based on C++ and can be easily plugged
> >into the existing C code base.  In addition to this, improving a
> >bit on documentation can contribute to better understating of
> >existing logger codebase.
>
> I'm not sure I like this.
>
> Debugging is at the very heart of FreeType.  Assume that you have to
> identify a bug, and you work in an environment for an exotic platform
> that only provides an (old) C compiler.  Your suggestion implies that
> you no longer can activate debugging output at all on such a platform!
>
> In other words, my gut feeling says no to the idea of using any
> different code language.  The logging facility should be written in
> the C language, too, not using more recent features than C99 so that
> older compilers support it.
>
> > Based on above points, all these changes could be done without
> > embedding an external library.  Having said that, if it is really a
> > requirement to replace the current logging facility with an external
> > one, there is an external C based logging library named "Zlog"
> > already been discussed on mailing list here
> > <
> https://lists.nongnu.org/archive/html/freetype-devel/2019-01/msg00023.html
> >.
> > I can work on it and explore other available external library
> > option.
>
> It's not a *requirement* to use an external logging library (inspite
> of the project's name), but there are good arguments to not re-invent
> the wheel.  In particular, it can be expected that a well-maintained
> external library gets a lot of testing and comes with a mature API.
>
>
> Werner
>
>
> PS: The current use of the debugging macros are documented in
> `doc/DEBUG`.
>

tracing and logging library - GSOC Project

[Priyesh kumar]

Hi ,
I am Priyesh , currently pursuing B.Tech in Computer Science at Indian
Institute of Information Technology Una , India . Currenlty, I am a third
year student and interested in working on Freetype's GSOC Project -* "**Replace
FreeType's tracing and debugging facilities with an external logging
library"*.  Following are my observations with the project mentioned above:

Per me, the current logger is doing a great job and has been implemented
based on well thought design. However, I see a few enhancements that can be
made on top of it:

   - Firstly,  since FreeType being a C library, most of its logger
   codebase is based on Macros. This adds complexity in debugging and reduces
   code readability to some extent. Sometimes, it is hard to understand the
   code and underlying design. Today we have more powerful C++ features
   available which can be used to enhance the code and add to the
   readability and easy debugging. Therefore, I propose to  implement
   separate code files for logging, which could be based on C++ and can be
   easily plugged into the existing C code base. In addition to this,
   improving a bit on documentation can contribute to better understating of
   existing logger codebase.
   - Another issue as already mention in the project problem statement is
   its limitation to writing logs only on standard error. This need to be
   generalised and to be extended for multiple platforms. I propose to extend
   the existing code and write a C++ based code which could enable it for
   multiple platforms and could be easily plugged into the current C code
   base. To be precise, it would be *"FT_Message" *API which would be
   invoking new code for logging messages to a file.

Based on above points, all these changes could be done without embedding an
external library. Having said that, if it is really a requirement  to
replace the current logging facility with an external one, there is an
external C based logging library named "Zlog" already been discussed on
mailing list here
.
I can work on it and explore other available external library option.

Please guide me if my approach is in the right direction. Any suggestions
are welcome.