Documentation can be found at http://tcllib.sourceforge.net/doc/log.html . ---- A side-by-side comparision to the very similar [logger] package in tcllib can be found here [http://sourceforge.net/docman/display_doc.php?docid=23243&group_id=12883]. Also take a look at the audit package at: [http://dqsoftware.sourceforge.net] ---- [LV] writes: What are some tips for using this package? For instance, can someone provide a skeleton for using logs to a program. One using has several types of msgs in a program: * introductory (Hi, this is program ABC, and I am here to help you learn to tie your shoes) * progress (program ABC is now loading a 256 terabyte database about types of shoes ... loading ... loading ...) * success/results (program ABC has located your language environment) * failure (program ABC is unable to identify shoes called 'sandels') * completion (Well, thanks for stopping by to talk to me - y'all come back now, ya' hear?) How would one code a skeleton for such an application (don't worry about the tcl to do the above actual coding - just the logs)? [[Good question(s), Larry.]] ---- [LV] 2007 June 27 I'd still love the above questions answered, but here's something I've learned. $ tclsh % package require log 1.2 % ::log::lvSuppress debug % ::log::lvIsSuppressed debug 1 % ::log::Puts debug "test" debug test % ::log::log debug "test" % Note the following - it appears that '''log::Puts''' is going to output something regardless of whether the output is suppressed or not. Use '''log::log''' which then observes the supression mechanism. The idea is this - log::log takes two arguments - an output ''level'' and the string to output. There are various levels available. The developer determines what kinds of output is desired for what types of things. The levels available include: Error level: * emergency * alert * critical * error Other level: * warning * notice * info * debug These levels are nearly "policy free" - that is, there isn't a requirement to use them in any particular way. Instead, the developer decides when a particular level should be observed. Thus, one might use the debug level to output text that the user won't see when normally using the application. The developer can decide when the each level might be appropriate, allowing three levels of "end of the world" type situations. I say "nearly policy free" because there is two policies relating to the relative ranking between levels. That is, debug has the lowest level of priority, emergency has the highest level, and the whole list is priority ranked in the order I list above . By default, anything in the "error level" group of log messages results in output to [stderr]. Messages of the other levels are written to [stdout]. However, there are log commands to reconfigure other levels to go to stderr as well. There are also commands for coloring text, for invoking commands to produce the output in a [GUI] [widget] or whatever else you desire (sending info to a pager, etc.) There are also commands for suppressing/unsupressing output of a particular level, or all levels less than or equal a given level, testing whether a level is suppressed, etc. ---- [PT] writes: OK Seeing as I used this in TclSOAP and tkchat...: package require log; # tcllib 1.0 namespace eval mine { variable logLevel warning; # set up the default level } # ------------------------------------------------------------------------- # Description: # Set the amount of logging you would like to see. We use the tcllib log package for this so the level # must be one of log::levels. The default is 'warning'. # Parameters: # level - one of log::levels. See the tcllib log package documentation. # proc mine::setLogLevel {level} { variable logLevel set logLevel $level log::lvSuppressLE emergency 0; # unsuppress all log::lvSuppressLE $logLevel 1; # suppress all below selected log::lvSuppress $logLevel 0; # unsupress selected. return $logLevel } # initialize the default package logging level if {[info exists mine::logLevel]} { mine::setLogLevel $mine::logLevel } Add a ''-loglevel'' configuration option that calls to ''setLogLevel'' and then liberally splinkle your code with log::log debug "message" and so forth. So: proc mine::DoStuff {args} { log::log debug "starting to do stuff" if {! [doing stuff]} { log::log notice "we are not doing anything!" } set r [do more stuff] if {$r < 1} { log::log emergency "argh!" } log::log debug "stopping doing stuff" } With this pseudo-procedure if the user has set their log level to ''debug'' then they will see all these messages printed out. Raising the log level to ''notice'' will reduce the noise but keep the more significant messages. ''emergency'' is (IIRC) the higest level. * emergency * alert * critical * error * warning * notice <--- logLevel variable * info........x * debug.......x The tkchat program uses log levels to provide debugging information for people having trouble and less information for those for whom it works. This program is probably a reasonable example of the use of this package. In this program we use ''debug'' and ''info'' for http status messages. The output appears at ''debug'' level and just the status at ''info'' level. Level ''error'' is used for reporting failures like timeouts and http protocol errors. ---- '''log''' is also an [expr] built-in function, "natural" logarithm to base ''e'': % expr log(2.71828182846) 1.0 '''log''' is also one of [TclX Commands] ---- [Category Debugging] | [Category Package], subset [Tcllib]