On Sat, 29 Oct 2016 01:50:21 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> On Sat, Oct 29, 2016 at 12:07 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 28 Oct 2016 14:15:39 +0200 thomasg <tho...@gstaedtner.net> said: > > > >> On Fri, Oct 28, 2016 at 4:08 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > >> > On Thu, 27 Oct 2016 09:16:02 -0200 Gustavo Sverzut Barbieri > >> > <barbi...@gmail.com> said: > >> > > >> > > Hi all, > >> > > > >> > > eina_log has a feature to print the thread that generated the log as > >> > > in "[T:XXXXXX]" prefix, which is handy during development or debug. > >> > > > >> > > But that is off by default and the only way to enable is using > >> > > eina_log_threads_enable() call. > >> > > > >> > > So: > >> > > > >> > > 1) could we make that an envvar to enable/disable it? > >> > > >> > i see no reason why not > >> > > >> > > 2) could we default to TRUE if no envvar was used? > >> > > >> > hmmm we already putr pid, process, file, line number, function... a > >> > T:0x3f wouldnt really hurt. of an 80 wide terminal 100 chars is just > >> > this header already. may as well start making this multi-line anyway. :) > >> > > >> > >> While any extra debugging info is nice, and I like that it can be > >> controlled at runtime, I think it should be off by default. > > > > have you seen the log lines? its 100 chars of stuff long before the log > > itself... does an extra integer or hex value like th:0x123 really make a > > difference? > > > >> Log output that contains only really necessary information is much more > >> readable, and most of the time, thread information will not be at all > >> relevant nor useful. > >> > >> Logging isn't necessarily used for program debugging, it mainly is used for > >> error reporting, which may be any number of errors, be it user or input > >> errors. > >> Threading information is exclusively useful for debugging, and I do think > >> debugging should always be off by default and only activated when actually > >> needed. > > > > actually it might be useful for user reporting. like thread 0x12 says A and > > thread 0x54 says b. knowing this is useful for a report. the PID there > > always and is in the same ballpark of usefulness. > > agreed, that's why it's nice to know if it was done in a thread or not. > > as for long lines, we already have separate vars that disable a big > part of it... maybe offer an EINA_LOG_SHORTLINE=1 that disables them > all? that makes sense. making thread info optional but the rest all there by default makes no sense to me. having a "short line" that maybe just reports filename +line number would be useful (that's enough to track it down in most cases). remove the full path from the file too- just the last file after the last / if there are /'s. :) and maybe a minimal which is just "ERR: xxx" where xxx is the log string content and no file/line/process etc. but thread info imho belongs together with pid and other such info anyway.:) > >> To be honest, I think eina_log default output is already a little bit too > >> cluttered and it may indeed already be useful to make it a seperate line > >> header. > >> > >> That said, I love eina_log and it is certainly one of my favorite EFL > >> features! > > :-) > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
