Version 23 of log

Updated 2007-06-27 14:12:57 by LV

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 [L1 ].

Also take a look at the audit package at: [L2 ]


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