gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part