Re: Logging Library-GSOC

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

> So, I have updated the code in `GSoC-2020-priyesh' branch such that > there are no separate project files for building dlg, Thanks. > in this branch I have used the `dlgwrap.c' method, [...] OK. > I have also pushed all the changes in this new branch, Please take a > look at that and let me

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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 >

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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,

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> I have followed the [above] steps to change the `autogen.sh` file, > so that it copies the files from directory `submodules/dlg` to > `src/dlg`. Great, thanks! > I have also added a `rules.mk` file to `src/dlg` and, for proceeding > further I wanted to ask that do I have to add a separate

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> When I am redirecting stderr logs to a text file using: `main > arial.ttf qwertyuiopasdfghjklzxcvbnm 2>sdterr_logs.txt` I am getting > the following results: > > `FT_LOGGING`: 8 sec > `FT_DEBUG_LEVEL_TRACE`: 11 sec This still looks fishy. >> Otherwise I guess the big difference between

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

On Thu, Jul 16, 2020 at 8:30 AM Priyesh kumar wrote: > > Hi, > I was trying profiling on the example program given @ here. > I have used the profiling tool inbuilt in Visual Studios but was unable to > extract useful information from it, therefore I have tried a solution provided > on Stack

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> I have added an option in `FT2_DEBUG` environment variable to > enable/disable the printing of FT_COMPONENT and Timestamp with a log > message. Looks good, thanks. > After looking at builds/windows/vc2010, builds/windows/visualc and > builds/windows/visualce I can see that they all depend on

Re: Logging Library-GSOC

Hi, I was trying profiling on the example program given @ here . I have used the profiling tool inbuilt in Visual Studios but was unable to extract useful information from it, therefore I have tried a solution provided on Stack Overflow

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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:

Re: Logging Library-GSOC

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

RE: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> I have updated the progress report for this week @ here > > It contains a brief description of all the useful APIs provided by > dlg Thanks, looks promising. If you are going to import the

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> Also I have updated the progress report for 3rd week @ here > Thanks! The recent discussion with Behdad reminded me to ask you whether you have also investigated the case where you modify the

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG wrote: > > > I find it a *very* bad idea to have code in FreeType that would > > write to a file. Specially bad if that can be controlled by an > > env-var. > > Interesting. Please explain. Do you fear security issues? > Sorry, forgot to reply

Re: Logging Library-GSOC

On Sat, Jun 13, 2020 at 10:59 PM Werner LEMBERG wrote: > > > I find it a *very* bad idea to have code in FreeType that would > > write to a file. Specially bad if that can be controlled by an > > env-var. > > Interesting. Please explain. Do you fear security issues? > > > I still think what's

RE: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

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

Re: Logging Library-GSOC

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

RE: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> I find it a *very* bad idea to have code in FreeType that would > write to a file. Specially bad if that can be controlled by an > env-var. Interesting. Please explain. Do you fear security issues? > I still think what's desired can be done best by just revamping and > writing custom code

Re: Logging Library-GSOC

I find it a *very* bad idea to have code in FreeType that would write to a file. Specially bad if that can be controlled by an env-var. I still think what's desired can be done best by just revamping and writing custom code in FreeType itself. This is my last word on this particular topic, but

RE: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

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

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

Hello Priyesh, > This week I have explored several libraries and I have prepared a > report mentioning their pros and cons @here > thanks for that. Very informative. A quick comment: I think

Re: Logging Library-GSOC

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

RE: Logging Library-GSOC

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

Re: Logging Library-GSOC

Hello Priyesh, > Clearly there is some problem with the current logger, but I think > the requirements which are mentioned on the FreeType's GSoC page and > the requirements which are discussed being here are different... I don't think so. It's only that David T. is back, and he wasn't part

Re: Logging Library-GSOC

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

RE: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

David wrote: > I'm sorry but that doesn't make any sense to me. There is > absolutely no point in making part of FreeType depend on a specific > external logger library at this point. Also we don't even know > which library, or which API. This looks like a solution looking for > a problem. >

Re: Logging Library-GSOC

Le mar. 19 mai 2020 à 09:30, Priyesh kumar a écrit : > Thanks for the reply, > > > > > > > > > > > > > > > *>Basically yes. As an improvement, I would like that the value of > the>`FT_COMPONENT` macro can be displayed optionally, e.g.>[afhints] foo > bar>[ttgxvar] sproink>...>The idea is that

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

> 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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

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

Re: Logging Library-GSOC

On Mon, May 18, 2020 at 9:28 AM David Turner wrote: > > > > Le lun. 18 mai 2020 à 09:03, Priyesh kumar a écrit : >> >> Hey, >> I wanted to ask that after selecting desirable external library how should I >> proceed: >> 1. Should I stick to the existing debugging facility in which filtering of

  1   2   >