On Wed, 2010-08-04 at 09:56 -0700, Bryce Harrington wrote: > On Wed, Aug 04, 2010 at 05:53:34PM +0200, Lionel Dricot wrote: > > The reason is simple : I don't use debug.log because I generally want only > > informations about a very precise point. > > Yeah, I do the same a lot. Perhaps a good guideline is that when the > code gets merged to trunk, evaluate all the prints - anything that looks > like it could be useful in general should be changed to Log.debug(); if > it's not important enough, it should go. > > It's nice that the Log.debug() output includes function name and line > number. It also includes a tag of some sort, so you could grep on > 'browser:' or 'tree:' depending on your interest, that's nice.
In my dbus-server branch, the server-side of GTG is started by the DBus daemon and never gets attached to any console, so all the debug messages would normally be lost. I added a filehandler: http://bazaar.launchpad.net/~gtg-contributors/gtg/dbus-server/annotate/head:/GTG/tools/logger.py I run "watch tail ~/.local/share/gtg/daemon.log" in a Byobu window and just leave it running. I switch to that window whenever I want to see the latest debug output. Another though: since it is possible to set different levels for different handlers, maybe it would be beneficial to always (e.g. even in releases) keep a file like this with log messages all the way down to logging.DEBUG. This file could be an apport attachment when users report bugs, removing the need for them to run "gtg -d" manually. -- Paul Kishimoto SM candidate (2012), Technology & Policy Program Massachusetts Institute of Technology http://paul.kishimoto.name — +19053029315
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
