Thread: [cclib-devel] Refactoring

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

Nice work on the refactoring, Karol.

On Thursday 01 of February 2007 17:55, Noel O'Boyle wrote:
> Nice work on the refactoring, Karol.

Thanks... it might be worthwhile to move some more things to LogFile.pares, 
but I need your input on these.

1)  The stuff before the loop (inputfile.seek, initialize self.progress, 
etc.). For this, inputfile, nstep, and oldstep would need to be attributes of 
the class. However, since they are temporary (parsing is never aborted before 
it's finished, I think), this may not be a good idea.

2) The code that uses cupdate, fupdate, nstep, and oldstep (condition "if 
self.progress and random.random() < fupdate") is repeated multiple times, but 
the same question arises as the above.

Could you perhaps explain the full purpose of LogFile.progress? Maybe there 
would be some advantages in making the logfile file object an attribute of 
LogFile (as in self.intputfile)?

Karol

-- 
written by Karol Langner
Fri Feb  2 12:21:24 CET 2007

On 02/02/07, Karol Langner <kar...@kn...> wrote:
> Thanks... it might be worthwhile to move some more things to LogFile.pares,
> but I need your input on these.
>
> 1)  The stuff before the loop (inputfile.seek, initialize self.progress,
> etc.). For this, inputfile, nstep, and oldstep would need to be attributes of
> the class. However, since they are temporary (parsing is never aborted before
> it's finished, I think), this may not be a good idea.

Do they have to be attributes of the class? Can they be local
variables in parse() which are passed into extract() (or maybe this is
too messy)? Alternatively, they can be 'weak' attributes, with names
like self._nstep. AFAIK, this is a convention to indicate 'private'
variables of a class, although it doesn't do much else.

> 2) The code that uses cupdate, fupdate, nstep, and oldstep (condition "if
> self.progress and random.random() < fupdate") is repeated multiple times, but
> the same question arises as the above.
Well, I think that this code can be moved into a function.

> Could you perhaps explain the full purpose of LogFile.progress?
It's main purpose is for GUI applications to be able to display a
progress bar showing how near to completion the parsing is. This is
because parsing can take more than 20 seconds for large files
containing population data (which is what both myself and Adam were
interested in). You should try out PyMOlyze to see this in action.
There is some cost in seconds in including the progress code, but
blindingly fast parsing is not the main goal of cclib. For instance,
it is possible to rewrite our multiple 'if' statements in other forms
that would parse large files quicker. If you care about this, it might
be worth thinking about, bearing in mind that "premature optimization
is the root of all evil" or something.

> Maybe there
> would be some advantages in making the logfile file object an attribute of
> LogFile (as in self.intputfile)?
IMO the fewer attributes the better. Since it's a 'derived attribute'
(i.e. it can be recreated from self.filename), and is only used within
extract(), I don't see how it can be useful. If you can think of a
useful reason for doing this though, go ahead.

> Karol
>
> --
> written by Karol Langner
> Fri Feb  2 12:21:24 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
>

On Friday 02 of February 2007 12:57, Noel O'Boyle wrote:
> Do they have to be attributes of the class? Can they be local
> variables in parse() which are passed into extract() (or maybe this is
> too messy)? Alternatively, they can be 'weak' attributes, with names
> like self._nstep. AFAIK, this is a convention to indicate 'private'
> variables of a class, although it doesn't do much else.

A made nstep an attribute of LogFile.progress, hope that doesn't conflict with 
your code. After all, it does fit in as an attribute of LogFile.progress.

Karol

-- 
written by Karol Langner
Fri Feb  2 18:47:42 CET 2007

On Friday 02 of February 2007 12:57, you wrote:
> On 02/02/07, Karol Langner <kar...@kn...> wrote:
> > Thanks... it might be worthwhile to move some more things to
> > LogFile.pares, but I need your input on these.
> >
> > 1)  The stuff before the loop (inputfile.seek, initialize self.progress,
> > etc.). For this, inputfile, nstep, and oldstep would need to be
> > attributes of the class. However, since they are temporary (parsing is
> > never aborted before it's finished, I think), this may not be a good
> > idea.
>
> Do they have to be attributes of the class? Can they be local
> variables in parse() which are passed into extract() (or maybe this is
> too messy)? Alternatively, they can be 'weak' attributes, with names
> like self._nstep. AFAIK, this is a convention to indicate 'private'
> variables of a class, although it doesn't do much else.

Yes, probably better to pass them as arguments, for now at least.

> > 2) The code that uses cupdate, fupdate, nstep, and oldstep (condition "if
> > self.progress and random.random() < fupdate") is repeated multiple times,
> > but the same question arises as the above.
>
> Well, I think that this code can be moved into a function.

Is there a difference in the meaning of the numbers cupdate and fupdate, 
beyond what I can see in the code?

> > Could you perhaps explain the full purpose of LogFile.progress?
>
> It's main purpose is for GUI applications to be able to display a
> progress bar showing how near to completion the parsing is. This is
> because parsing can take more than 20 seconds for large files
> containing population data (which is what both myself and Adam were
> interested in). You should try out PyMOlyze to see this in action.
> There is some cost in seconds in including the progress code, but
> blindingly fast parsing is not the main goal of cclib. For instance,
> it is possible to rewrite our multiple 'if' statements in other forms
> that would parse large files quicker. If you care about this, it might
> be worth thinking about, bearing in mind that "premature optimization
> is the root of all evil" or something.

I don't care about optimization a bit, at least at this point. I do hope, 
though, that some extent of refactoring will make writing new parsers and 
extending the present ones a little easier.

I'm going to try out pyMOlyze and GaussSum soon, when I find a bit more free 
time.

> > Maybe there
> > would be some advantages in making the logfile file object an attribute
> > of LogFile (as in self.intputfile)?
>
> IMO the fewer attributes the better. Since it's a 'derived attribute'
> (i.e. it can be recreated from self.filename), and is only used within
> extract(), I don't see how it can be useful. If you can think of a
> useful reason for doing this though, go ahead.

No, I don't :)

Karol

-- 
written by Karol Langner
Fri Feb  2 16:29:18 CET 2007

> Is there a difference in the meaning of the numbers cupdate and  
> fupdate,
> beyond what I can see in the code?

I think I originally intended them as course and fine update values,  
although I honestly don't recall how they are actually used. I think  
that the progress while parsing mocoeffs didn't update frequently  
enough with cupdate, so I added fupdate---but I may be wrong.

Adam

On Friday 02 of February 2007 17:06, you wrote:
> > Is there a difference in the meaning of the numbers cupdate and
> > fupdate,
> > beyond what I can see in the code?
>
> I think I originally intended them as course and fine update values,
> although I honestly don't recall how they are actually used. I think
> that the progress while parsing mocoeffs didn't update frequently
> enough with cupdate, so I added fupdate---but I may be wrong.
>
> Adam

The function I added to LogFile that does this now takes an argument xupdate, 
so a parser can give any value now (I retained the cupdate/fupdate values 
that were in all parsers. I see that this was used moslty for the Gaussian 
parser up till now.

Karol

-- 
written by Karol Langner
Fri Feb  2 18:23:14 CET 2007

I have a more radical idea for refactoring the code for the parsers, which 
could structure them better and make them more 'standardized'. It still won't 
change anything in the user-side, but I really think something like this will 
give alot of long-term benifits in terms of writing new parsers and 
regulating common aspects (like LogFile.progress and attribute types).

The attached file contains my fast scetch of the new parse function (so it 
probaly won't work).

Besides parse() itself:
1) the extract methods of all parsers would be revised. This is pretty 
straightforward and I would do it with a script - the loop is cut out, and 
each conditional block  for line content needs to returns a tuple with the 
attributes that were set. If the "_" prefix were to denote private 
attributes, extract should probably be renamed to _extract at this point.
2) a few new dictionaries are needed for common information, as used in the 
attached file: _attrtypes (attribute types we want for each attribute), 
_fupdate (for the progress update), _msg (messages for progress). The last 
two should logically be attributes of the progress object itself), and could 
be set to default values by cclib if they don't exist (for compatibility).

And that would be about it! If this all looks like it might work :) and you 
think it's a good idea, I'll go straight ahead and work on the details. I 
don't think it would take alot of work, and I have some spare time this 
weekend.

Karol

-- 
written by Karol Langner
Fri Feb  2 19:00:35 CET 2007

Sounds interesting. Anything that you feel makes it easier for people
to write parsers is ok with me. :-)

Just been reading today that instead of a massive switch statement
it's better to use a dictionary of functions. It's not exactly the
same, but it makes me think of something like...

for line in file:
    for keyphrase,blockname in keyphrases:
        if line.find(keyphrase)>=0:
             extract[blockname]()

e.g. keyphrase("Number of MOs") and corresponding blockname is 'MO section'

I'm not sure why you think it should return a tuple though (this makes
things more difficult). Surely it can just set the attributes from
instead the extract function.

Sounds like this is starting to turn into a major refactoring, and I'm
a bit wary of having this on the trunk, especially as it will be
experimental for the first while. Can you put this on a branch instead
and just test with a single parser for the moment?

On 02/02/07, Karol Langner <kar...@kn...> wrote:
> I have a more radical idea for refactoring the code for the parsers, which
> could structure them better and make them more 'standardized'. It still won't
> change anything in the user-side, but I really think something like this will
> give alot of long-term benifits in terms of writing new parsers and
> regulating common aspects (like LogFile.progress and attribute types).
>
> The attached file contains my fast scetch of the new parse function (so it
> probaly won't work).
>
> Besides parse() itself:
> 1) the extract methods of all parsers would be revised. This is pretty
> straightforward and I would do it with a script - the loop is cut out, and
> each conditional block  for line content needs to returns a tuple with the
> attributes that were set. If the "_" prefix were to denote private
> attributes, extract should probably be renamed to _extract at this point.
> 2) a few new dictionaries are needed for common information, as used in the
> attached file: _attrtypes (attribute types we want for each attribute),
> _fupdate (for the progress update), _msg (messages for progress). The last
> two should logically be attributes of the progress object itself), and could
> be set to default values by cclib if they don't exist (for compatibility).
>
> And that would be about it! If this all looks like it might work :) and you
> think it's a good idea, I'll go straight ahead and work on the details. I
> don't think it would take alot of work, and I have some spare time this
> weekend.
>
> Karol
>
> --
> written by Karol Langner
> Fri Feb  2 19:00:35 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
>
>
>

On Friday 02 of February 2007 20:35, Noel O'Boyle wrote:
> Just been reading today that instead of a massive switch statement
> it's better to use a dictionary of functions. It's not exactly the
> same, but it makes me think of something like...
>
> for line in file:
>     for keyphrase,blockname in keyphrases:
>         if line.find(keyphrase)>=0:
>              extract[blockname]()
>
> e.g. keyphrase("Number of MOs") and corresponding blockname is 'MO section'

I thought about this also - extracting a new attribute is then just adding a 
new entry to that dict, very conscise - but this would take some more work 
from where we are (which I'm willign to do). One question remains, where 
would the functions be defined? As methods of the class? As locals in the 
module? Directly inside the dictionary?

There's one more problem, the "keyphrase conditions" are various, some 
conditions check more than just the current line - some have more than one 
possible keyphrase, some have additional conditions. So there would have to 
be another dict of functions that check the conditions specific to the parser 
and attribute. So I thought that that was too much change at one time.

> I'm not sure why you think it should return a tuple though (this makes
> things more difficult). Surely it can just set the attributes from
> instead the extract function.

Not necessarily a tuple, but subscriptable, because some conditional blocks 
extract more than one attribute at a time. Now that I look at it, seems 
superfluous, since the type checks can go after the extracting, and progress 
isn't ever updated twice in the same block.

Karol

-- 
written by Karol Langner
Sat Feb  3 10:08:29 CET 2007

> Sounds like this is starting to turn into a major refactoring, and I'm
> a bit wary of having this on the trunk, especially as it will be
> experimental for the first while. Can you put this on a branch instead
> and just test with a single parser for the moment?

Karol, it does sound like you are doing some interesting work, but I  
agree with Noel that this should be developed someplace other than  
where our current changes are. Especially since my most recent  
version of PyMOlyze uses trunk as that's where the CDA and  
FragmentAnalysis code is.

What are the current features we are hoping to have in cclib 0.7? If  
there aren't going to be many changes (esp to parsers), I think it  
makes sense to merge trunk (from before the refactoring) into a  
cclib-0.7 branch. If we decide we like the refactoring changes, we  
can merge those into cclib-0.7 once its stable. What do y'all think?

Adam

On Friday 02 of February 2007 20:47, Adam Tenderholt wrote:
> > Sounds like this is starting to turn into a major refactoring, and I'm
> > a bit wary of having this on the trunk, especially as it will be
> > experimental for the first while. Can you put this on a branch instead
> > and just test with a single parser for the moment?
>
> Karol, it does sound like you are doing some interesting work, but I
> agree with Noel that this should be developed someplace other than
> where our current changes are. Especially since my most recent
> version of PyMOlyze uses trunk as that's where the CDA and
> FragmentAnalysis code is.
>
> What are the current features we are hoping to have in cclib 0.7? If
> there aren't going to be many changes (esp to parsers), I think it
> makes sense to merge trunk (from before the refactoring) into a
> cclib-0.7 branch. If we decide we like the refactoring changes, we
> can merge those into cclib-0.7 once its stable. What do y'all think?

OK, so tell me which way to go - branch off with the refactoring or create a 
0.7 branch? I would opt for the first, becuase I was really hoping to get the 
refactoring over with quickly and get on to some "real" additions :)

Conceptually, the parsing function structure I proposed is not far from a dict 
of functions, so maybe that would be a good first step to take.

Karol

-- 
written by Karol Langner
Sat Feb  3 10:26:45 CET 2007

Since you are moving at a faster pace than we can make decisions it's
probably better for you to make a branch for this refactoring, so that
you can continue without losing momentum and can experiment a bit.

I think the refactoring changes up till now in trunk have been
relatively minor, but I'm happy to do as Adam suggests and and make a
cclib-0.7 release branch from before the refactoring. All future
development will be done on the trunk anyway and stable changes or
completion of agreed features will be merged to the release branch.

Noel

On 03/02/07, Karol Langner <kar...@kn...> wrote:
> On Friday 02 of February 2007 20:47, Adam Tenderholt wrote:
> > > Sounds like this is starting to turn into a major refactoring, and I'm
> > > a bit wary of having this on the trunk, especially as it will be
> > > experimental for the first while. Can you put this on a branch instead
> > > and just test with a single parser for the moment?
> >
> > Karol, it does sound like you are doing some interesting work, but I
> > agree with Noel that this should be developed someplace other than
> > where our current changes are. Especially since my most recent
> > version of PyMOlyze uses trunk as that's where the CDA and
> > FragmentAnalysis code is.
> >
> > What are the current features we are hoping to have in cclib 0.7? If
> > there aren't going to be many changes (esp to parsers), I think it
> > makes sense to merge trunk (from before the refactoring) into a
> > cclib-0.7 branch. If we decide we like the refactoring changes, we
> > can merge those into cclib-0.7 once its stable. What do y'all think?
>
> OK, so tell me which way to go - branch off with the refactoring or create a
> 0.7 branch? I would opt for the first, becuase I was really hoping to get the
> refactoring over with quickly and get on to some "real" additions :)
>
> Conceptually, the parsing function structure I proposed is not far from a dict
> of functions, so maybe that would be a good first step to take.
>
> Karol
>
> --
> written by Karol Langner
> Sat Feb  3 10:26:45 CET 2007
>

On Saturday 03 of February 2007 11:05, you wrote:
> Since you are moving at a faster pace than we can make decisions it's
> probably better for you to make a branch for this refactoring, so that
> you can continue without losing momentum and can experiment a bit.

OK, done.

> I think the refactoring changes up till now in trunk have been
> relatively minor, but I'm happy to do as Adam suggests and and make a
> cclib-0.7 release branch from before the refactoring. All future
> development will be done on the trunk anyway and stable changes or
> completion of agreed features will be merged to the release branch.

OK, So I haven't reverted the changes up till now, and started off fro mteh 
current revision.

Karol

-- 
written by Karol Langner
Sat Feb  3 11:17:11 CET 2007

cclib 0.7 release branch created based on trunk revision 479.
Development should still occur on the trunk (or the parser refactoring
branch). I'll look after merging stable changes to the release branch
every so often.

Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
final Jaguar tests.

Noel

On 02/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > Sounds like this is starting to turn into a major refactoring, and I'm
> > a bit wary of having this on the trunk, especially as it will be
> > experimental for the first while. Can you put this on a branch instead
> > and just test with a single parser for the moment?
>
> Karol, it does sound like you are doing some interesting work, but I
> agree with Noel that this should be developed someplace other than
> where our current changes are. Especially since my most recent
> version of PyMOlyze uses trunk as that's where the CDA and
> FragmentAnalysis code is.
>
> What are the current features we are hoping to have in cclib 0.7? If
> there aren't going to be many changes (esp to parsers), I think it
> makes sense to merge trunk (from before the refactoring) into a
> cclib-0.7 branch. If we decide we like the refactoring changes, we
> can merge those into cclib-0.7 once its stable. What do y'all think?
>
> Adam
>
>
>

On Friday 09 of February 2007 14:51, Noel O'Boyle wrote:
> cclib 0.7 release branch created based on trunk revision 479.
> Development should still occur on the trunk (or the parser refactoring
> branch). I'll look after merging stable changes to the release branch
> every so often.
>
> Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> final Jaguar tests.
>
> Noel

I'll take care of the MP2 energies, except for Jaguar which I don't have 
access to (unless someone uploads a test, then I can do that, too).

I'm not eager to do any more major refactoring in the parsers at the moment 
(except perhaps splitting _extract() into a dictionary of functions, but that 
needs to be discussed more thouroughly). Nor do I have any more interesting 
ideas for this. Also, I would rather go about adding functionality and 
resolving bugs. So what are your views on the current revision of the 
parser-refactoring branch - can it be merged with trunk? I ask, because 
merging later can be a pain if we add things to the parser long the way.

Karol

-- 
written by Karol Langner
Mon Feb 12 19:01:33 CET 2007

On 12/02/07, Karol Langner <kar...@kn...> wrote:
> On Friday 09 of February 2007 14:51, Noel O'Boyle wrote:
> > cclib 0.7 release branch created based on trunk revision 479.
> > Development should still occur on the trunk (or the parser refactoring
> > branch). I'll look after merging stable changes to the release branch
> > every so often.
> >
> > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > final Jaguar tests.
> >
> > Noel
>
> I'll take care of the MP2 energies, except for Jaguar which I don't have
> access to (unless someone uploads a test, then I can do that, too).
>
> I'm not eager to do any more major refactoring in the parsers at the moment
> (except perhaps splitting _extract() into a dictionary of functions, but that
> needs to be discussed more thouroughly). Nor do I have any more interesting
> ideas for this. Also, I would rather go about adding functionality and
> resolving bugs. So what are your views on the current revision of the
> parser-refactoring branch - can it be merged with trunk? I ask, because
> merging later can be a pain if we add things to the parser long the way.

The merging is going to happen after release; we now need to stabilise
the branch, get all tests to pass, and *release*.

> Karol
>
> --
> written by Karol Langner
> Mon Feb 12 19:01:33 CET 2007
>

On Tuesday 13 of February 2007 08:51, Noel O'Boyle wrote:
> > > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > > final Jaguar tests.
>
> The merging is going to happen after release; we now need to stabilise
> the branch, get all tests to pass, and *release*.

OK.... so I understand that the trunk is the priority now. I'll start to help 
out with that soon, I did a little travelling recently.

As to mpenergies, I don't have access to a new version of GAMESS-UK, so could 
someone upload an MPx test for that program, too (also Jaguar). I can take 
care of parsing.

Karol

-- 
written by Karol Langner
Tue Feb 13 11:23:25 CET 2007

On 13/02/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 13 of February 2007 08:51, Noel O'Boyle wrote:
> > > > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > > > final Jaguar tests.
> >
> > The merging is going to happen after release; we now need to stabilise
> > the branch, get all tests to pass, and *release*.
>
> OK.... so I understand that the trunk is the priority now. I'll start to help
> out with that soon, I did a little travelling recently.
>
> As to mpenergies, I don't have access to a new version of GAMESS-UK, so could
> someone upload an MPx test for that program, too (also Jaguar). I can take
> care of parsing.

I'll upload water sto3g mp2 for GAMESS-UK. It make take a while, as I
may need to get a new copy of the software...

> Karol
>
> --
> written by Karol Langner
> Tue Feb 13 11:23:25 CET 2007
>

I'm going to make a U-turn now. I'm slowly realising that even with
the magic help of svnmerge.py, it will not be possible to cleanly
merge trunk to the release branch (or at least without a lot of effort
hand fixing conflicts and so on), and leave out the refactoring
changes soon after 479.

With this in mind, could we just base the release on trunk (i.e. I'll
merge all of the change to release), and then I'll remove any items in
development (e.g. ccenergies).

Noel

On 09/02/07, Noel O'Boyle <bao...@gm...> wrote:
> cclib 0.7 release branch created based on trunk revision 479.
> Development should still occur on the trunk (or the parser refactoring
> branch). I'll look after merging stable changes to the release branch
> every so often.
>
> Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> final Jaguar tests.
>
> Noel
>
> On 02/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > Sounds like this is starting to turn into a major refactoring, and I'm
> > > a bit wary of having this on the trunk, especially as it will be
> > > experimental for the first while. Can you put this on a branch instead
> > > and just test with a single parser for the moment?
> >
> > Karol, it does sound like you are doing some interesting work, but I
> > agree with Noel that this should be developed someplace other than
> > where our current changes are. Especially since my most recent
> > version of PyMOlyze uses trunk as that's where the CDA and
> > FragmentAnalysis code is.
> >
> > What are the current features we are hoping to have in cclib 0.7? If
> > there aren't going to be many changes (esp to parsers), I think it
> > makes sense to merge trunk (from before the refactoring) into a
> > cclib-0.7 branch. If we decide we like the refactoring changes, we
> > can merge those into cclib-0.7 once its stable. What do y'all think?
> >
> > Adam
> >
> >
> >
>

> With this in mind, could we just base the release on trunk (i.e. I'll
> merge all of the change to release), and then I'll remove any items in
> development (e.g. ccenergies).

That sounds reasonable. Are all the regression tests passing with the  
trunk version?

Adam

---------- Forwarded message ----------
From: Noel O'Boyle <bao...@gm...>
Date: 27-Feb-2007 14:34
Subject: Re: [cclib-devel] Refactoring
To: Adam Tenderholt <a-t...@st...>

On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > With this in mind, could we just base the release on trunk (i.e. I'll
> > merge all of the change to release), and then I'll remove any items in
> > development (e.g. ccenergies).
>
> That sounds reasonable.
OK, done.

> Are all the regression tests passing with the
> trunk version?

The only tests left to pass are those involving coreelectrons (because
of tests I've added today basically). We need

(1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
(2) code for GAMESS-UK
(3) bug fix for ADF (I presume it's a bug)

To be practical, I think I'll have to make a release of cclib 0.7b
this weekend, or it'll be put off for too long. When I come back I'll
make the final release.

Noel

On Tuesday 27 of February 2007 15:34, Noel O'Boyle wrote:
> On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > With this in mind, could we just base the release on trunk (i.e. I'll
> > > merge all of the change to release), and then I'll remove any items in
> > > development (e.g. ccenergies).
> >
> > That sounds reasonable.
>
> OK, done.

Out of curiousity, did something happen here that caused some tests in testMP 
to fail? I noticed that a few lines of code were gone (readded them today).

> The only tests left to pass are those involving coreelectrons (because
> of tests I've added today basically). We need
>
> (1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
> (2) code for GAMESS-UK
> (3) bug fix for ADF (I presume it's a bug)

So this is all done, I think. Any other coding bits you need help with?

Karol

-- 
written by Karol Langner
Thu Mar  1 22:50:06 CET 2007

On 01/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of February 2007 15:34, Noel O'Boyle wrote:
> > On 26/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > > > With this in mind, could we just base the release on trunk (i.e. I'll
> > > > merge all of the change to release), and then I'll remove any items in
> > > > development (e.g. ccenergies).
> > >
> > > That sounds reasonable.
> >
> > OK, done.
>
> Out of curiousity, did something happen here that caused some tests in testMP
> to fail? I noticed that a few lines of code were gone (readded them today).
I saw your log message, but I didn't notice anything. You should be
able to look through the SVN diffs of that file to see what the story
is. The SVN browser on our SF website is useful for this.

> > The only tests left to pass are those involving coreelectrons (because
> > of tests I've added today basically). We need
> >
> > (1) a test file for GAMESS-US and/or PC-GAMESS, and then code for it
> > (2) code for GAMESS-UK
> > (3) bug fix for ADF (I presume it's a bug)
>
> So this is all done, I think. Any other coding bits you need help with?
I think we're ready to rock. Sometime this weekend, I'll make the beta
release. We'll sit tight for a week or two (I'll be away) and try to
find problems, and then make a final release, and announce it on CCL,
etc.

Good luck with the talk.

Noel