Menu
▾
▴
#291 Suppression level Enhancement
I've worked as a scripter the last couple of years doing network testing with TCL. And 1 thing that has come up in at least the last 2 places that I've had work, is the use of the tcllib's log package.
The enhancement I'd like to see would be levels of suppression for any of the current levels defined.
What we've all really wanted is levels of debug logging, but after thinking about it some why not just make the change for all of the different levels.
We can still maintain the use of the idea of suppression but extend it some so that we can have additional levels of suppression for each logLevel (which for sake of discussion would be more appropriately defined as a category).
Currently we have suppression defined as 0|1, on or off for any particular "category" info,debug,alert....
What I would like to see is say have a maximum suppression level of say 5.
Which I would leave to your capable hands of determining if we change the definition of suppression or just learn what a suppresion level means.
So we'd have suppression levels of say 0-5 with 0 meaning no suppression and everything less than the level number passed would be suppressed, or the other way around that everything less than the suppression level is suppressed and everything greater is logged.
The major change to the package would be that the log::log command would require this additional parameter to be passed in. So now we'd have "log::log logLevel suppLevel msg"
Currently you can just use the different logLevels but the name that gets tagged on the message tends to be misleading. I still only want certain info messages to be displayed at say production run time, but when I'm debugging or developing I'd want addtional "info" messages and not have to use another level like "alert". I'd like the logLevel to still be indicative of the severity of what I am logging.
So like I said I think a lot of testers would really like levels of debug logging, but if were going to enhance then just lets just have levels of logging for all the current logLevels.
Logged In: YES
user_id=75003
Originator: NO
Quick note that the different log-levels were/are intended to be this type suppression-levels.
You seem to interpret them more as categories of messages, and wish to have an additional argument denoting what I would call the 'priority' of the message inside of its category.
Do I understand that right ?
If yes, then me asking you to look at the 'logger' package (same module of Tcllib) is superfluous, as it has the same type of categorization, and no priorities. What it does have is the ability to create multiple independent loggers (actually a tree), which allows us to give each package its own logger, with independent suppression of categories.
Interestingly enough, when I worked on the cvs2fossil application (*) I did not use 'log', nor 'logger', but wrote a new system with exactly that kind of priority based system you seem to look for. It had no multiple loggers however, and no categories either. But it also made sure that code in leog messages was executed only if the message was actually to be printed.
It might be interesting to take this RFE and merge it into logger, to get a system having all of multiple loggers, categories, and priorities.
I am reassigning to Michael Schlenk, as he is the maintainer of 'logger', as I wish to get his opinion on this as well.
Logged In: YES
user_id=302287
Originator: NO
Logger could do such additional suppression levels in a hackish way, by defining subloggers with numerical names, it would just need some syntax sugar to make it nicer.
Simply changing the signature of the logging function to ${log}::<level> suppLevel msg would have the bad side effect that disabled suppression levels would still eat runtime when disabled.
Its basically a decision how to setup your logging subsystem, the more simple log package doesn't allow you to create fancy output/suppression schemes, while loggger allows it with some tinkering.
So yes, i think this RFE is a good idea and could be done with the current logger code with just small compatible changes.
Michael
Logged In: YES
user_id=75003
Originator: NO
I should note that IMHO this type of enhancement may warrant a change of the major version number, and this would allow us to complete redesign the API as we see fit. no hacks would be needed as we would be able to redesign everything from the ground up.
Of course, if compatible changes allow us to support this we could go that route.
OTOH, IIRC we have some other RFE for logger currently done hackish, maybe it is time for a redo. I do not remember what this change was/is/might be.
Logged In: YES
user_id=302287
Originator: NO
Yes. There are more things in logger that could improve (e.g. the logger proc signature and some others) and a lot of the internals could be done nicer.
I think it would also be good to unify to just one logging package and not two or even more.
Logged In: YES
user_id=931198
Originator: YES
Yes Andries, for sake of discussion I called them categories, simply because I wanted to refer to the suppression as a "level", but "priority" is just as accurate.
I did look at logger and just as you referenced it didn't provide a "priority"/"level" as well.
Excellent to see that it wasn't just me thinking that we needed some enhancements.