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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> >>>
