Re: tracing and logging library - GSOC Project

2020-03-22 Thread Alan Coopersmith

On 3/22/20 7:58 AM, Werner LEMBERG wrote:

Instead of 'Linux' (which is just an OS kernel) I would rather ask for
'standard Unix environments' like GNU/Linux or BSD variants.


Thanks - we're still shipping FreeType in Solaris as well, but are trying
to reduce the number of things that FOSS projects have to do to support us
vs. Linux/BSD platforms, so hopefully "standard Unix environments" will
cover us too.

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc



Re: tracing and logging library - GSOC Project

2020-03-22 Thread Werner LEMBERG


> As per the reply, my main focus for this project will be on the
> following platforms:
> 
>- Windows
>- macOS
>- Linux
>- iOS
>- ChromeOS
>- Android
>- ReactOS

Instead of 'Linux' (which is just an OS kernel) I would rather ask for
'standard Unix environments' like GNU/Linux or BSD variants.  'macOS'
and 'iOS' are more or less based on BSD, while 'ChromeOS' is a
GNU/Linux variant (to a certain extent).  'ReactOS' should essentially
use the same API as Windows.

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

We don't have CI (yet).


Werner



Re: tracing and logging library - GSOC Project

2020-03-22 Thread 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

2020-03-22 Thread Werner LEMBERG


> 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

2020-03-22 Thread 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

2020-03-03 Thread 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

2020-03-03 Thread Werner LEMBERG

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

2020-03-03 Thread 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

2020-02-26 Thread 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`.
>


Re: tracing and logging library - GSOC Project

2020-02-24 Thread Werner LEMBERG

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

2020-02-23 Thread 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.