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