Menu
▾
▴
cclib-devel
|
From: Karol L. <kar...@kn...> - 2007-02-03 22:51:24
|
I finished refactoring the parsers in the new branch ("parser-refactoring").
Besides moving the loop over to the base class, most of the changes were
connected with moving bits and pieces around and turning variables into class
attributes when they're used across calls of _extract().
All tests now finish like in the trunk, and the user side shouldn't be any
different than it was. Something might go wrong, though, in real-life
situations, so I would be grateful for testing the lateset revision in this
branch with some normal usage (GassSum and, PyMOlyze?). I'm not going to add
anything new here for now.
As to making _extract a dictionary of functions - from here on this is
simple, since the function is already divided into clear parts. It won't
simplify the code anymore, though, so I would leave this for the future. Also
- where would the many extracting funtions be defined? It's not a good idea,
for example, to populate the parser object with so many new attrbiutes.
Also changed/added:
1) Updategprogress is still needed... because alot of the parsing code updates
progress inside loops and such.
2) I wrote a new __setattr__ method for LogFile - it updates the logger, so no
more worrying about this in the parsers!
3) I also added a loop after parsing that deletes all attributes that are not
in self._nodelete (which is set utomatically), so that all the temporary
attributes used across calls of _extract() during parsing go away.
4) Notice that now in order for an attribute to be parsed it HAS TO be added
to LogFile._attrlist, otherwise it will get deleted, even if set by
_extract().
Looking forward to your feedback,
Karol
--
written by Karol Langner
Sat Feb 3 17:38:31 CET 2007
|
|
From: Adam T. <a-t...@st...> - 2007-02-03 23:24:27
|
Hi Karol,
I found a couple of problems:
1) Gaussian object has no attribute optfinished (line 77 in _extract)
when I run PyMOlyze (and ccget) on trunk/data/Gaussian/Gaussian03/
Mo4OSibdt2-opt.log.bz2.
2) nstep isn't defined when I try to open trunk/data/Gaussian/
basicGaussian03/dvb_gopt.out with PyMOlyze. Presumably, this isn't
seen in ccget because it doesn't use a progress class. This appears
to be a problem with a lot of the other dvb_gopt/sp files from ADF
and GAMESS calcs.
This is after completely removing cclib from python's site-packages
(remove all traces of trunk) and reinstalling cclib from revision 508
of your new branch. There's also a bunch of errors that I don't
recall seeing from trunk/test/regression.py.
Adam
On Feb 3, 2007, at 2:50 PM, Karol Langner wrote:
> I finished refactoring the parsers in the new branch ("parser-
> refactoring").
>
> Besides moving the loop over to the base class, most of the changes
> were
> connected with moving bits and pieces around and turning variables
> into class
> attributes when they're used across calls of _extract().
>
> All tests now finish like in the trunk, and the user side shouldn't
> be any
> different than it was. Something might go wrong, though, in real-life
> situations, so I would be grateful for testing the lateset revision
> in this
> branch with some normal usage (GassSum and, PyMOlyze?). I'm not
> going to add
> anything new here for now.
>
> As to making _extract a dictionary of functions - from here on
> this is
> simple, since the function is already divided into clear parts. It
> won't
> simplify the code anymore, though, so I would leave this for the
> future. Also
> - where would the many extracting funtions be defined? It's not a
> good idea,
> for example, to populate the parser object with so many new
> attrbiutes.
>
> Also changed/added:
>
> 1) Updategprogress is still needed... because alot of the parsing
> code updates
> progress inside loops and such.
> 2) I wrote a new __setattr__ method for LogFile - it updates the
> logger, so no
> more worrying about this in the parsers!
> 3) I also added a loop after parsing that deletes all attributes
> that are not
> in self._nodelete (which is set utomatically), so that all the
> temporary
> attributes used across calls of _extract() during parsing go away.
> 4) Notice that now in order for an attribute to be parsed it HAS TO
> be added
> to LogFile._attrlist, otherwise it will get deleted, even if set by
> _extract().
>
> Looking forward to your feedback,
> Karol
>
> --
> written by Karol Langner
> Sat Feb 3 17:38:31 CET 2007
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
|
|
From: Karol L. <kar...@kn...> - 2007-02-04 11:26:30
|
On Sunday 04 of February 2007 00:24, Adam Tenderholt wrote:
> Hi Karol,
>
> I found a couple of problems:
>
> 1) Gaussian object has no attribute optfinished (line 77 in _extract)
> when I run PyMOlyze (and ccget) on trunk/data/Gaussian/Gaussian03/
> Mo4OSibdt2-opt.log.bz2.
That's strange, I don't get that error:
>>> import cclib
>>> cclib.parser.gaussianparser.__revision__
'$Revision: 509 $'
>>> g = cclib.parser.ccopen("Mo4OSibdt2-opt.log.bz2")
>>> g.parse()
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute atomcoords[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute atomnos[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute natom: 62
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute gbasis[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute nbasis: 581
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute nmo: 581
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute scftargets[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute scfvalues[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute scfenergies[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute mosyms[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute homos[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute moenergies[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute aonames[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute mocoeffs[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute geovalues[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute geotargets[]
[Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute coreelectrons[]
Everything looks fine here. Are you sure you're using revision 509 of the
Gaussian parser? The attribute optfinished is set to False at the beginning.
Using ccget with the file also works for me, and all the regression tests
finish fine.
> 2) nstep isn't defined when I try to open trunk/data/Gaussian/
> basicGaussian03/dvb_gopt.out with PyMOlyze. Presumably, this isn't
> seen in ccget because it doesn't use a progress class. This appears
> to be a problem with a lot of the other dvb_gopt/sp files from ADF
> and GAMESS calcs.
> This is after completely removing cclib from python's site-packages
> (remove all traces of trunk) and reinstalling cclib from revision 508
> of your new branch. There's also a bunch of errors that I don't
> recall seeing from trunk/test/regression.py.
That's what I get for not reading mails to the end :) Could you try out
revision 509 from the branch? That's when I added minor fixes for these
attributes
Karol
--
written by Karol Langner
Sun Feb 4 12:14:55 CET 2007
|
|
From: Adam T. <a-t...@st...> - 2007-02-05 18:08:13
|
Minor problem with Rev. 509 and ADF files:
>>> from cclib.parser import ccopen
>>> from cclib.progress import TextProgress
>>> progress = TextProgress()
>>> import logging
>>> parser = ccopen("dvb_sp.adfout", progress, logging.ERROR)
>>> parser.parse()
[=========-] 97% Unsupported informationTraceback (most recent
call last):
File "<stdin>", line 1, in ?
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/site-packages/cclib/parser/logfileparser.py", line 223, in
parse
self.progress.update(nstep, "Done")
NameError: global name 'nstep' is not defined
I haven't checked if it affects other calculation files yet. Just
noticed it when I was using PyMOlyze this morning on an ADF file... ;o)
Adam
On Feb 4, 2007, at 3:25 AM, Karol Langner wrote:
> On Sunday 04 of February 2007 00:24, Adam Tenderholt wrote:
>> Hi Karol,
>>
>> I found a couple of problems:
>>
>> 1) Gaussian object has no attribute optfinished (line 77 in _extract)
>> when I run PyMOlyze (and ccget) on trunk/data/Gaussian/Gaussian03/
>> Mo4OSibdt2-opt.log.bz2.
>
> That's strange, I don't get that error:
>
>>>> import cclib
>>>> cclib.parser.gaussianparser.__revision__
> '$Revision: 509 $'
>>>> g = cclib.parser.ccopen("Mo4OSibdt2-opt.log.bz2")
>>>> g.parse()
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute atomcoords[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute atomnos[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute natom: 62
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute gbasis[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute nbasis: 581
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute nmo: 581
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute scftargets[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute scfvalues[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute
> scfenergies[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute mosyms[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute homos[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute moenergies[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute aonames[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute mocoeffs[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute geovalues[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute geotargets[]
> [Gaussian Mo4OSibdt2-opt.log.bz2 INFO] Creating attribute
> coreelectrons[]
>
> Everything looks fine here. Are you sure you're using revision 509
> of the
> Gaussian parser? The attribute optfinished is set to False at the
> beginning.
> Using ccget with the file also works for me, and all the regression
> tests
> finish fine.
>
>> 2) nstep isn't defined when I try to open trunk/data/Gaussian/
>> basicGaussian03/dvb_gopt.out with PyMOlyze. Presumably, this isn't
>> seen in ccget because it doesn't use a progress class. This appears
>> to be a problem with a lot of the other dvb_gopt/sp files from ADF
>> and GAMESS calcs.
>
>> This is after completely removing cclib from python's site-packages
>> (remove all traces of trunk) and reinstalling cclib from revision 508
>> of your new branch. There's also a bunch of errors that I don't
>> recall seeing from trunk/test/regression.py.
>
> That's what I get for not reading mails to the end :) Could you try
> out
> revision 509 from the branch? That's when I added minor fixes for
> these
> attributes
>
> Karol
>
> --
> written by Karol Langner
> Sun Feb 4 12:14:55 CET 2007
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
|
|
From: Karol L. <kar...@kn...> - 2007-02-06 14:25:38
|
That would affect any logfile - I cut out the definition of nstep without
checking if it is used (and forgot the tests don't check progress). Revision
510 is fixed for this.
Thanks for the testing,
Karol
On Monday 05 of February 2007 19:07, Adam Tenderholt wrote:
> Minor problem with Rev. 509 and ADF files:
> >>> from cclib.parser import ccopen
> >>> from cclib.progress import TextProgress
> >>> progress = TextProgress()
> >>> import logging
> >>> parser = ccopen("dvb_sp.adfout", progress, logging.ERROR)
> >>> parser.parse()
>
> [=========-] 97% Unsupported informationTraceback (most recent
> call last):
> File "<stdin>", line 1, in ?
> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib/parser/logfileparser.py", line 223, in
> parse
> self.progress.update(nstep, "Done")
> NameError: global name 'nstep' is not defined
>
> I haven't checked if it affects other calculation files yet. Just
> noticed it when I was using PyMOlyze this morning on an ADF file... ;o)
>
> Adam
--
written by Karol Langner
Tue Feb 6 15:22:22 CET 2007
|
|
From: Adam T. <a-t...@st...> - 2007-02-06 18:38:42
|
Hi Karol,
That fixed it.
However, using PyMOlyze this morning exposed another bug. ADF parsers
should have frags and fragnames attributes because ADF sometimes
alters the atom order so that there isn't a direct mapping between
fonames (ie. C1_3s) and atomcoords. Look in the svn log and ADF test
files for more details.
Adam
On Feb 6, 2007, at 6:24 AM, Karol Langner wrote:
> That would affect any logfile - I cut out the definition of nstep
> without
> checking if it is used (and forgot the tests don't check progress).
> Revision
> 510 is fixed for this.
>
> Thanks for the testing,
> Karol
>
> On Monday 05 of February 2007 19:07, Adam Tenderholt wrote:
>> Minor problem with Rev. 509 and ADF files:
>>>>> from cclib.parser import ccopen
>>>>> from cclib.progress import TextProgress
>>>>> progress = TextProgress()
>>>>> import logging
>>>>> parser = ccopen("dvb_sp.adfout", progress, logging.ERROR)
>>>>> parser.parse()
>>
>> [=========-] 97% Unsupported informationTraceback (most recent
>> call last):
>> File "<stdin>", line 1, in ?
>> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib/parser/logfileparser.py", line 223, in
>> parse
>> self.progress.update(nstep, "Done")
>> NameError: global name 'nstep' is not defined
>>
>> I haven't checked if it affects other calculation files yet. Just
>> noticed it when I was using PyMOlyze this morning on an ADF
>> file... ;o)
>>
>> Adam
>
> --
> written by Karol Langner
> Tue Feb 6 15:22:22 CET 2007
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
|
|
From: Karol L. <kar...@kn...> - 2007-02-06 20:05:26
|
On Tuesday 06 of February 2007 19:38, Adam Tenderholt wrote: > Hi Karol, > > That fixed it. > > However, using PyMOlyze this morning exposed another bug. ADF parsers > should have frags and fragnames attributes because ADF sometimes > alters the atom order so that there isn't a direct mapping between > fonames (ie. C1_3s) and atomcoords. Look in the svn log and ADF test > files for more details. > > Adam Yes... this is a side-effect of a new thing I introduced in LogFile.parse() - attributes that do not exist before parsing or are not in _attrlist are deleted after parsing - this way parsers can create temporary attributes for the object when needed across calls of _extract(). I'm not sure if this work-around is good practice in general, but it does require we keep the list of attributes (_attrlist) up-to-date, which is probably a good thing :) In any case, in revision 511 I added the ADF-specific attributes (4 of them, in fact) to _attrlist in the __init__ method of class ADF.. I would add them to the docstring, but I don't have the time to read into their meanings today. Let me now if there are any other problems, Karol -- written by Karol Langner Tue Feb 6 20:56:45 CET 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-26 14:51:55
|
Now that 0.7 is out, I wanted to return to the discussion about refactoring the parsers. The 'parser-refactoring' branch has a working version of the new Gaussian parser that I wrote up some time ago. The major change is that the parser loop is in the LogFile class, and calls the method of the child class (i called it "_extract"). This allows generic changes to be done to all the parsers in parallel. Temporary variables need to be attributes in order to survive between iterations, and I added code that deletes them after parsing (everything that's not in _attrlist and wasn't there before parsing). There are a few other additions that should make writing parsers easier. For example, the __setattr__ can take care of issuing messages to the logger when new attributes are created. Most of these smaller changes can and probalby should be discussed separately. Let me know how you feel about how to proceed. I would prefer not to work too long in a branch on something that is so fundamental to cclib (not like a new, specific parser) where the files keep changing. I think it would be more efficient and reasonable to stretch out the "refactoring" but keep it alive. That is, to take up one issue at a time on this list and to work in small steps in the trunk (following consensus). Karol -- written by Karol Langner Mon Mar 26 16:30:38 CEST 2007 |
|
From: Adam T. <a-t...@st...> - 2007-03-26 18:26:15
|
What are the plans for version 0.7.1? It obviously will contain the bug fixes we make to the ADF parser and the new functionality being added to the Jaguar parser, as well as some of the changes I'll be making to the methods. Is it appropriate to include the refactoring in this release, or should it wait until 0.8? The reason I bring up this issue is how we should handle the svn tree. If the refactoring is going into the 0.7.1 release, then I see no reason to not merge it with trunk whenever you're ready. If this is the case, then I'd like the most recent changes in trunk to be merged with the 0.7 branch first as I'm trying to get Jaguar support working better in PyMOlyze. If the refactoring goes into the 0.8 release, then you could simple rename that branch to 0.8 and we'll push patches from trunk into that branch as necessary. Adam |
|
From: Karol L. <kar...@kn...> - 2007-03-27 06:39:24
|
On Monday 26 of March 2007 20:26, Adam Tenderholt wrote: > What are the plans for version 0.7.1? It obviously will contain the > bug fixes we make to the ADF parser and the new functionality being > added to the Jaguar parser, as well as some of the changes I'll be > making to the methods. Is it appropriate to include the refactoring > in this release, or should it wait until 0.8? > > The reason I bring up this issue is how we should handle the svn > tree. If the refactoring is going into the 0.7.1 release, then I see > no reason to not merge it with trunk whenever you're ready. If this > is the case, then I'd like the most recent changes in trunk to be > merged with the 0.7 branch first as I'm trying to get Jaguar support > working better in PyMOlyze. If the refactoring goes into the 0.8 > release, then you could simple rename that branch to 0.8 and we'll > push patches from trunk into that branch as necessary. > > Adam Good point, it's more logical to wait until after 0.7.1. Still, perhaps some of the smaller changes that don't alter the parser strusture (like automated logger messages in __setitem__) could be included in the next subrelease. Karol -- written by Karol Langner Tue Mar 27 08:22:02 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-04-03 08:18:09
|
I won't force the issue either way, but I feel it might be a good idea to push ahead with the refactoring and get it over with. This will mean a 0.8 release rather than 0.7.1, but we can make this a quick release if all it contains is the refactoring plus some bugfixes (ADF) and enhancements (ccenergies, tightening up the TD-DFT, filling holes in Jaguar). I suppose what it boils down to is how long it will take to fix the ADF bugs. I haven't looked at these but, due to the nature of ADF output files, ADF bugs are typically more complex than your average one Noel On 27/03/07, Karol Langner <kar...@kn...> wrote: > On Monday 26 of March 2007 20:26, Adam Tenderholt wrote: > > What are the plans for version 0.7.1? It obviously will contain the > > bug fixes we make to the ADF parser and the new functionality being > > added to the Jaguar parser, as well as some of the changes I'll be > > making to the methods. Is it appropriate to include the refactoring > > in this release, or should it wait until 0.8? > > > > The reason I bring up this issue is how we should handle the svn > > tree. If the refactoring is going into the 0.7.1 release, then I see > > no reason to not merge it with trunk whenever you're ready. If this > > is the case, then I'd like the most recent changes in trunk to be > > merged with the 0.7 branch first as I'm trying to get Jaguar support > > working better in PyMOlyze. If the refactoring goes into the 0.8 > > release, then you could simple rename that branch to 0.8 and we'll > > push patches from trunk into that branch as necessary. > > > > Adam > > Good point, it's more logical to wait until after 0.7.1. Still, perhaps some > of the smaller changes that don't alter the parser strusture (like automated > logger messages in __setitem__) could be included in the next subrelease. > > Karol > > -- > written by Karol Langner > Tue Mar 27 08:22:02 CEST 2007 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
|
From: Karol L. <kar...@kn...> - 2007-04-25 22:14:01
|
Hi,
I've already started, but I'd like to shortly summarize the changes I'm about
to do in the trunk related to refactoring the parser, in the order they will
proceed. Ideally, these changes won't break anything, but you never know, so
be on the lookout! The goal is to get certain things working automatically
and to move as many elements of the parsing process to the generic class
LogFile, which in turn is supposed to make writing and modifying the child
parsers easier in the future.
1) Move all calls to logger.infio() for newly created attributes to the method
LogFile.__setattr__() - which is called automatically when an attibute is
set. Prints the log message only if the attribute is new and present in
LogFile.attrlist.
2) Up till now, we refrained from setting temporary attributes while parsing
in order to keep things tidy. By utilizing an additional list attribute
("__nodelete"), these can be used (alot, if neede), and will be deleted after
parsing (so the user does not see that they existed). Interestingly, this
also requires that we keep LogFile.attrlist up-to-date :-)
3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to
LogFile.parse(). This may seem like just moving one line, but there are some
extra things to change in order to keep things parsing (like using temporary
attributes), and a number of things to consider. Note a paradigm shift in the
way the parsers work: the method extract() will be now called many times
instead of once. In my opinion, this is a natural step that makes the parsers
more flexible and opens interesting possibilities for further enhacements,
4) Making fupdate and cupdate attributes of the class - this is reasonable, as
then they won't have to be passed around to extract() in each call.
5) Numeric->numpy transition. This isn't strictly related to the refactoring,
but it might as well be done at once. The related changes seem to be trivial.
6) A few other minor changes I might not remember at the moment, but will
comment on.
Any further changes to the parser structure really need to be discussed
thouroughly so as not to waste development time. For example, as mentioned by
Noel, we could choose to use a dictionary of functions that parse separate
blocks of output (best if the keys are regexps). I like the idea, and the
present changes are a step in that direction. It would be pretty, optimal,
and well-structured, which all makes writing new parses easier and more fun.
Then main question is - where would all these functions be defined? If they
are to be class methods, things can get messy, since there will be quite a
lot of them. But first things first.
Hope this clears up the up-coming commits,
Karol
--
written by Karol Langner
Thu Apr 26 01:24:12 CEST 2007
|
|
From: Noel O'B. <bao...@gm...> - 2007-04-26 06:04:51
|
On 26/04/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
> I've already started, but I'd like to shortly summarize the changes I'm about
> to do in the trunk related to refactoring the parser, in the order they will
> proceed. Ideally, these changes won't break anything, but you never know, so
> be on the lookout! The goal is to get certain things working automatically
> and to move as many elements of the parsing process to the generic class
> LogFile, which in turn is supposed to make writing and modifying the child
> parsers easier in the future.
>
> 1) Move all calls to logger.infio() for newly created attributes to the method
> LogFile.__setattr__() - which is called automatically when an attibute is
> set. Prints the log message only if the attribute is new and present in
> LogFile.attrlist.
Do any of our parsers set the attribute, but then delattr it? Might be
worth checking. Also, it would be possible to check the types of
attributes at this point, using an assert statement. I can look into
this.
> 2) Up till now, we refrained from setting temporary attributes while parsing
> in order to keep things tidy. By utilizing an additional list attribute
> ("__nodelete"), these can be used (alot, if neede), and will be deleted after
> parsing (so the user does not see that they existed). Interestingly, this
> also requires that we keep LogFile.attrlist up-to-date :-)
>
> 3) THE MAJOR CHANGE - moving the "for line in inputfile" loop to
> LogFile.parse(). This may seem like just moving one line, but there are some
> extra things to change in order to keep things parsing (like using temporary
> attributes), and a number of things to consider. Note a paradigm shift in the
> way the parsers work: the method extract() will be now called many times
> instead of once. In my opinion, this is a natural step that makes the parsers
> more flexible and opens interesting possibilities for further enhacements,
>
> 4) Making fupdate and cupdate attributes of the class - this is reasonable, as
> then they won't have to be passed around to extract() in each call.
Sure.
> 5) Numeric->numpy transition. This isn't strictly related to the refactoring,
> but it might as well be done at once. The related changes seem to be trivial.
Can we leave this until all current tests pass after the first refactoring.
> 6) A few other minor changes I might not remember at the moment, but will
> comment on.
>
> Any further changes to the parser structure really need to be discussed
> thouroughly so as not to waste development time. For example, as mentioned by
> Noel, we could choose to use a dictionary of functions that parse separate
> blocks of output (best if the keys are regexps). I like the idea, and the
> present changes are a step in that direction. It would be pretty, optimal,
> and well-structured, which all makes writing new parses easier and more fun.
> Then main question is - where would all these functions be defined? If they
> are to be class methods, things can get messy, since there will be quite a
> lot of them. But first things first.
> Hope this clears up the up-coming commits,
> Karol
>
> --
> written by Karol Langner
> Thu Apr 26 01:24:12 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
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X