Re: [cclib-devel] strange logger bug

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

 It seems that logging.getlogger() returns the same instance when called with 
the same "logname", supposedly to not have to pass loggers around in an 
application that uses them. So, all parser instances in cclib of the same 
class were duplicating their own handlers (since each instance added another 
one). So a quick check that LogFile.logger.handlers is empty fixes this.

 I wonder if there is any advantage in having at maximum one logger for each 
kind of parser class there is - that's the way it is now. If not, it might be 
good to establish a clearer logging strategy:
1) create a global logger when cclib is loaded (or rather cclib.parser), and 
use only this one throughout by all parsers
2) create a new logger for any parser instance, each one with a unique name 
(the docs say that dots determine the hierarchy for loggers - such as a.b.c).

Cheers,
- Karol

On Thursday 03 May 2007 12:26, Noel O'Boyle wrote:
> Sorry, just checked. clean() doesn't remove the logger, nor should it.
> If you parse the same file a second time (e.g. this is common with
> GaussSum users following a geometry optimisation) you still want a
> logger.
>
> The problem you found occurs if you create two instances of parsers
> with the same name. We either ignore this problem, or implement some
> complicated way of tracking file names. Perhaps if we only create the
> logger when parse() is called, then we can remove it when clean() is
> called.
>
> On 03/05/07, Noel O'Boyle <bao...@gm...> wrote:
> > This is a "feature" of the logger (yes, I agree it's annoying, but
> > it's not a bug). The problem is that now you have two loggers both
> > doing the exact same thing. Loggers are distinguished by their names;
> > so if you parse the same file twice, without using clear() (which I
> > hope deletes the logger), you get this effect.
> >
> > On 03/05/07, Karol Langner <kar...@kn...> wrote:
> > > While working interactively with cclib on many files, I noticed a bug
> > > related to the logger. For some reason, it prints as many messages for
> > > each attribute as there were instances created of the specific parser
> > > (GAMESS, Gaussian, counted separately), so you get an increasingly long
> > > output form the logger. The problems is not related to any recent
> > > changes, it goes as far back as version 0.5, as you can see here:
> > >
> > > langner@slim:~/tmp/python/cclib/trunk/data/Gaussian/basicGaussian03$
> > > python Python 2.5 (r25:51908, Apr 30 2007, 15:03:13)
> > > [GCC 3.4.6 (Debian 3.4.6-5)] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > >
> > > >>> import cclib
> > > >>> print cclib.__version__
> > >
> > > 0.5
> > >
> > > >>> print cclib.parser.logfileparser.__revision__
> > >
> > > $Revision: 240 $
> > >
> > > >>> print cclib.parser.gamessparser.__revision__
> > >
> > > $Revision: 240 $
> > >
> > > >>> cclib.parser.Gaussian("water_mp2.log").parse()
> > >
> > > [Gaussian water_mp2.log INFO] Creating attribute atomcoords[]
> > > [Gaussian water_mp2.log INFO] Creating attribute atomnos[]
> > > [Gaussian water_mp2.log INFO] Creating attribute natom: 3
> > > [Gaussian water_mp2.log INFO] Creating attribute nbasis: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute nmo: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute scftargets[]
> > > [Gaussian water_mp2.log INFO] Creating attribute scfvalues
> > > [Gaussian water_mp2.log INFO] Creating attribute scfenergies[]
> > > [Gaussian water_mp2.log INFO] Creating attribute moenergies[[]]
> > > [Gaussian water_mp2.log INFO] Creating attribute homos[]
> > >
> > > >>> cclib.parser.Gaussian("water_mp2.log").parse()
> > >
> > > [Gaussian water_mp2.log INFO] Creating attribute atomcoords[]
> > > [Gaussian water_mp2.log INFO] Creating attribute atomcoords[]
> > > [Gaussian water_mp2.log INFO] Creating attribute atomnos[]
> > > [Gaussian water_mp2.log INFO] Creating attribute atomnos[]
> > > [Gaussian water_mp2.log INFO] Creating attribute natom: 3
> > > [Gaussian water_mp2.log INFO] Creating attribute natom: 3
> > > [Gaussian water_mp2.log INFO] Creating attribute nbasis: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute nbasis: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute nmo: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute nmo: 7
> > > [Gaussian water_mp2.log INFO] Creating attribute scftargets[]
> > > [Gaussian water_mp2.log INFO] Creating attribute scftargets[]
> > > [Gaussian water_mp2.log INFO] Creating attribute scfvalues
> > > [Gaussian water_mp2.log INFO] Creating attribute scfvalues
> > > [Gaussian water_mp2.log INFO] Creating attribute scfenergies[]
> > > [Gaussian water_mp2.log INFO] Creating attribute scfenergies[]
> > > [Gaussian water_mp2.log INFO] Creating attribute moenergies[[]]
> > > [Gaussian water_mp2.log INFO] Creating attribute moenergies[[]]
> > > [Gaussian water_mp2.log INFO] Creating attribute homos[]
> > > [Gaussian water_mp2.log INFO] Creating attribute homos[]
> > >
> > > >>> cclib.parser.GAMESS("../../GAMESS/basicGAMESS-US/water_mp2.out").pa
> > > >>>rse()
> > >
> > > [GAMESS ../GAMESS/water_mp2.out INFO] Creating attribute atomcoords,
> > > atomnos [GAMESS ../water_mp2.out INFO] Creating attribute nbasis
> > > [GAMESS ../water_mp2.out INFO] Creating attribute homos
> > > [GAMESS ../water_mp2.out INFO] Creating attribute natom
> > > [GAMESS ..//water_mp2.out INFO] Creating attribute scftargets
> > > [GAMESS ../water_mp2.out INFO] Creating attribute scfvalues
> > > [GAMESS ../water_mp2.out INFO] Creating attribute scfenergies[]
> > > [GAMESS ..//water_mp2.out INFO] Creating attributes moenergies, mosyms
> > > [GAMESS ../water_mp2.out INFO] Creating attribute nmo with default
> > > value [GAMESS ../water_mp2.out INFO] Creating attribute mocoeffs
> > > [GAMESS ../water_mp2.out INFO] Creating attribute geotargets[] with
> > > default values
> > >
> > > Notice how only the same parser class contributes to the repeats. The
> > > problem is not in parsing, though, since it happens whenever
> > > logger.info is called. Consider this from the current revision in
> > > trunk, where it is called in LogFile.__setattr__ whenever an attribute
> > > from _attrlist is set that did not exist previously:
> > >
> > > langner@slim:~/tmp/python/cclib/trunk/data$ python
> > > Python 2.5 (r25:51908, Apr 30 2007, 15:03:13)
> > > [GCC 3.4.6 (Debian 3.4.6-5)] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > >
> > > >>> import cclib
> > > >>> cclib.__version__
> > >
> > > '0.7'
> > >
> > > >>> cclib.parser.logfileparser.__revision__
> > >
> > > '$Revision: 620 $'
> > >
> > > >>> a = cclib.parser.ccopen("basicGaussian03/water_mp2.log")
> > > >>> a.mult = 1
> > >
> > > [Gaussian basicGaussian03/water_mp2.log INFO] Creating attribute mult:
> > > 1
> > >
> > > >>> a = cclib.parser.ccopen("basicGaussian03/water_mp2.log")
> > > >>> a.mult = 1
> > >
> > > [Gaussian basicGaussian03/water_mp2.log INFO] Creating attribute mult:
> > > 1 [Gaussian basicGaussian03/water_mp2.log INFO] Creating attribute
> > > mult: 1
> > >
> > > >>> b = cclib.parser.ccopen("basicGAMESS-US/water_mp2.out")
> > > >>> b.mult = 1
> > >
> > > [GAMESS basicGAMESS-US/water_mp2.out INFO] Creating attribute mult: 1
> > >
> > > >>> a.mult = 1
> > > >>> a.clean()
> > > >>> a.mult = 1
> > >
> > > [Gaussian basicGaussian03/water_mp2.log INFO] Creating attribute mult:
> > > 1 [Gaussian basicGaussian03/water_mp2.log INFO] Creating attribute
> > > mult: 1
> > >
> > > This looks pretty strange.
> > >
> > > - Karol
> > >
> > > --
> > > written by Karol Langner
> > > Thu May  3 13:25:54 CEST 2007
> > >
> > > -----------------------------------------------------------------------
> > >-- This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > cclib-devel mailing list
> > > ccl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol Langner
Mon May  7 02:51:00 CEST 2007