The way I would use it is to write everything with VERBOSE mode and then start doing greps until I reach the interesting level, also for hopping between same tags. It will avoid me reading lines and lines of non-relevant material because I don't know where the important part is.

On 7/5/12 8:34 AM, Barak Raveh wrote:
Daniel, 
What exactly is the context? I guess this is what I really had in mind personally, but I'm not 100% sure what you mean by it, or how to use it (couldn't find any ref to it in the man page on logging). Is it someway of getting to know in which context a log message from a certain class was called? Is it possible to mute certain contexts in runtime (e.g., now I don't want to see logging from this class but only from that class, etc.).
Barak

On Thu, Jul 5, 2012 at 7:10 AM, Daniel Russel <drussel@gmail.com> wrote:
I'm not sure I see the problem this is supposed to solve.  And it would make often already long log lines even longer and harder to scan visually since the prefix is no longer meaningful. What is a scenario when you want to use this?

And why add the log level part? The context lines can't be readily tagged with the log level since there can be messages with several different levels within a different context (and they aren't all known when the line is produced). And I think it is too much information to stick all into one line. So I see that we can set it up so that you can get something that looks like WARN level output when running in TERSE. In addition, running things with VERBOSE slows runtimes down rather noticeably, so I'm not sure you would want to do that routinely while only looking at terse messages, for example.

On the implementation side, log messages are already scanned for newlines and indentation prefixes inserted, so adding other prefixes is easy.

On Jul 3, 2012, at 3:51 PM, Javier Velazquez wrote:

>
> I have a simple proposal. write the granularity ad the beginning of each log message. Something like
>
> LOG:TERSE blah blah
>
> Then a couple of "greps" would make going through all the output less painful, wouldn't it?
>
> _______________________________________________
> IMP-dev mailing list
> IMP-dev@salilab.org
> https://salilab.org/mailman/listinfo/imp-dev


_______________________________________________
IMP-dev mailing list
IMP-dev@salilab.org
https://salilab.org/mailman/listinfo/imp-dev



--
Barak
_______________________________________________ IMP-dev mailing list IMP-dev@salilab.org https://salilab.org/mailman/listinfo/imp-dev