cclib-devel — Developer's mailing list

Re: [cclib-devel] pyquante and cclib

[Rick M. <rm...@sa...>]

Nice! Let me know if I can help with anything.

By the way, how are you using mayavi? Did you have to write your own  
routine to input the cube file, or is that fairly easy?

Rick

On Jul 28, 2006, at 4:16 AM, Noel O'Boyle wrote:

> Hello Adam,
>
> I'm very excited by what we will be able to do with PyQuante/cclib.
>
> After adding the ability to extract the coefficients of the Gaussian
> basis functions from G03 (I've called the attribute 'gbasis' for the
> moment, any comments) [note to self: G03 also exports basis  
> functions in
> a different format depending on the Gaussian revision/version - I  
> cannot
> handle this yet], it is possible to use PyQuante to calculate the
> amplitude of any molecular orbital at any point in space.
>
> That means that we can calculate the electron density! We can do
> population analysis methods like Hirshfeld atomic charges, AIM, etc.,
> etc. (if we know how, of course :-). You should note that calculating
> the electron density will take quite a while but speed can come  
> later if
> we really want to work on this.
>
> I haven't yet added the code to cclib, but see the attached screenshot
> for proof - the volume data derives from cclib/PyQuante, not the cube
> file of a Gaussian calculation. (Visualised with mayavi, the python  
> GUI
> interface to VTK).
>
> Regards,
>   Noel
>
>
> <dvb_homo>

Rick Muller
rm...@sa...

Re: [cclib-devel] pyquante and cclib

[Adam T. <a-t...@st...>]

> I'm very excited by what we will be able to do with PyQuante/cclib.
>
> After adding the ability to extract the coefficients of the Gaussian
> basis functions from G03 (I've called the attribute 'gbasis' for the
> moment, any comments) [note to self: G03 also exports basis  
> functions in
> a different format depending on the Gaussian revision/version - I  
> cannot
> handle this yet], it is possible to use PyQuante to calculate the
> amplitude of any molecular orbital at any point in space.
>
> That means that we can calculate the electron density! We can do
> population analysis methods like Hirshfeld atomic charges, AIM, etc.,
> etc. (if we know how, of course :-). You should note that calculating
> the electron density will take quite a while but speed can come  
> later if
> we really want to work on this.

This is quite exciting! I've always wanted to have a custom, modern  
program for visualizing orbital data, especially one that will allow  
scripting so that a list of desired orbitals can be used instead of  
selecting each one individual from a menu (Molden, ADFGUI).

Out of curiosity, how long are you saying electron density takes for  
a single orbital?

Adam

[cclib-devel] [Fwd: Re: Package independent analysis of comp chem calcs]

[Noel O'B. <no...@ca...>]

-------- Forwarded Message --------
From: Rick Muller <rm...@sa...>
To: Noel O'Boyle <no...@ca...>
Subject: Re: Package independent analysis of comp chem calcs
Date: Wed, 26 Jul 2006 09:52:28 -0600
Noel,

I had hoped to clean this up before sending it to you, but it's a  
busy time of the year, and I haven't had the time to dedicate to it.

I've attached a few python modules that I use for parsing Jaguar and  
GAMESS output. To be honest, much of the time I just write  
lightweight parsers from scratch, instead of the attached modules.  
But to read in an overlap matrix or something the routines are useful.

The files have a copyright notice in them, but you may treat them as  
public domain and do what you like with them. Keep me posted on what  
you do. I'll be glad to write the module to output cube files from  
PyQuante, but you might have to nag me once or twice. Best of luck!

Rick
On Jul 13, 2006, at 9:16 AM, Noel O'Boyle wrote:

> On Thu, 2006-07-13 at 08:51 -0600, Rick Muller wrote:
>> Ah, but here's a problem, one of those things that only works when
>> you start writing code.
>>
>>   I was assuming that the basisset be a list of PyQuante basis
>> functions, which have a built-in function .amp(x,y,z) to give the
>> basis function amplitude at the point x,y,z. If you want to do this
>> in cclib you would essentially have to recreate (or steal -- you're
>> welcome to them) the PyQuante functions that define a basis set,
>> normalize it, and compute the amplitudes. This is certainly possible,
>> but it isn't as elegant as one might like.
>> However, I actually use
>> PyQuante functions to do analysis like this all the time. I'll read
>> in a Jaguar or GAMESS output file, parse it for the orbitals,
>> recreate the basis set and overlap matrix in PyQuante, and display
>> information that I want.
> But this is great! This is exactly what I want to do, and you've even
> gotten the parsing code written already. If you're happy to give me  
> this
> code for cclib, that would be fantastic.
>
>> Alternatively, I can simply include code to output a cube file from
>> PyQuante.
> That would be good too. As this is the next step, once the density is
> calculated.
>
> Regards,
>   Noel
>
>> On Jul 13, 2006, at 6:37 AM, Noel O'Boyle wrote:
>>
>>>
>>> I think a first attempt to make a useful bridge between cclib and
>>> PyQuante would be for cclib to provide a function density() as
>>> follows:
>>>
>>> def density(mocoeffs, coordinates, basis set, delta = 0.1, cube =
>>> None):
>>> 	"""Calculate the electron density using PyQuante.
>>>
>>> 	Requires:
>>>           mocoeffs - mol. orb. coefficients in terms of atom  
>>> orbitals
>>> 	  coordinates
>>>           basis set - a set of Gaussian functions per atom
>>> (expressed as
>>>                       per PyQuante user guide)
>>>         Optional:
>>>           delta - the dx/y/z value for points in the cube.  
>>> Defaults to
>>>                   0.1Ang or something sensible.
>>>           cube - the dimensions of the cube. Default is something
>>> sensible
>>>         Returns:
>>> 	  a Numeric array of the density (which can be visualised with
>>>                                           MayaVi for example)
>>>         """
>>>
>>> If this makes sense to you and seems doable, I'll start hacking  
>>> basis
>>> set info out of log files. Of course, I will make sure that the  
>>> above
>>> code will work equally well for users of PyQuante and other comp.
>>> chem.
>>> packages.
>>>
>>> In PyQuante everything is Gaussian-based right? No STOs? If so, that
>>> rules out ADF I think.

Re: [cclib-devel] API change

[Noel O'B. <no...@ca...>]

On Tue, 2006-07-25 at 08:23 -0700, Adam Tenderholt wrote:
> Hey Noel,
> 
> > I've been busy getting GAMESS-UK into shape. There haven't really  
> > been any
> > difficulties, although it seems that GAMESS UK doesn't want to  
> > print out
> > all of the mocoeffs of the virtual orbitals (it just does the first  
> > 10 or
> > so)...I'll see if I can ask the developers about this.

Latest update, I've registered to post my query on the GAMESS UK forum,
but am waiting to be OKed.

> Glad to hear you've been working on this. Jaguar also only prints a  
> handful of virtual orbitals unless you tell it to print more.  
> Speaking of which, do you want me to check in the little bit of  
> Jaguar code I have? It just parses aonames, moceoffs, and aooverlaps  
> as needed from PyMOlyze.

Absolutely, I didn't realise you had some already (I've actually just
checked in some aooverlaps code) - if you're happy, why don't don't you
take over finishing Jaguar. I think we're going to need some more
calculations though, as the uploaded ones don't seem to be comprehensive
[there's a time limit on my access to Jaguar and GAMESS-UK at this
stage, i.e. I'll be leaving here at the end of August - hence the reason
I'm trying to get as much done as possible now].

> > I've also been trying to get GaussSum to use cclib. I'm getting  
> > there, but
> > I realise I need to add a .clean() method to the superclass of the  
> > parsers,
> > which removes all of the calculated attributes. The reason is that  
> > I need
> > to allow users to reparse their log files as a calculation  
> > progresses, and
> > the easiest (and cleanest) way to do this seems to be to wipe the  
> > parser
> > clean and reparse.
> 
> I didn't realize GaussSum actually monitored the progress of a  
> calculation. Do you just open up a file, and every so often GaussSum  
> parses it? That's a neat idea. Adding a clean() method sounds  
> completely reasonable.

Well, it's not quite automatic. You have to click the button. :-) But it
does tell you whether the SCF/geometry is likely to convergence, rather
than just oscillate for ever.

Regards,
  Noel

Re: [cclib-devel] API change

[Adam T. <a-t...@st...>]

Hey Noel,

> I've been busy getting GAMESS-UK into shape. There haven't really  
> been any
> difficulties, although it seems that GAMESS UK doesn't want to  
> print out
> all of the mocoeffs of the virtual orbitals (it just does the first  
> 10 or
> so)...I'll see if I can ask the developers about this.

Glad to hear you've been working on this. Jaguar also only prints a  
handful of virtual orbitals unless you tell it to print more.  
Speaking of which, do you want me to check in the little bit of  
Jaguar code I have? It just parses aonames, moceoffs, and aooverlaps  
as needed from PyMOlyze.

> I've also been trying to get GaussSum to use cclib. I'm getting  
> there, but
> I realise I need to add a .clean() method to the superclass of the  
> parsers,
> which removes all of the calculated attributes. The reason is that  
> I need
> to allow users to reparse their log files as a calculation  
> progresses, and
> the easiest (and cleanest) way to do this seems to be to wipe the  
> parser
> clean and reparse.

I didn't realize GaussSum actually monitored the progress of a  
calculation. Do you just open up a file, and every so often GaussSum  
parses it? That's a neat idea. Adding a clean() method sounds  
completely reasonable.

Adam

[cclib-devel] API change

[Dr N. O'B. <no...@ca...>]

Hello Adam,

I've been busy getting GAMESS-UK into shape. There haven't really been any 
difficulties, although it seems that GAMESS UK doesn't want to print out 
all of the mocoeffs of the virtual orbitals (it just does the first 10 or 
so)...I'll see if I can ask the developers about this.

I've also been trying to get GaussSum to use cclib. I'm getting there, but 
I realise I need to add a .clean() method to the superclass of the parsers, 
which removes all of the calculated attributes. The reason is that I need 
to allow users to reparse their log files as a calculation progresses, and 
the easiest (and cleanest) way to do this seems to be to wipe the parser 
clean and reparse.

Regards,
  Noel 

[cclib-devel] ANNOUNCE: cclib-0.5 available

[Noel O'B. <noe...@ma...>]

cclib 0.5 is now available for download from http://cclib.sf.net.

cclib is an open source library, written in Python, for parsing and
interpreting the results of computational chemistry packages. It
currently parses output files from ADF, GAMESS (US), Gaussian, and PC
GAMESS. (Support for Jaguar and GAMESS UK is being added.)

Among other data, cclib extracts:

    * coordinates
    * atomic orbital information
    * molecular orbital information
    * information on vibrational modes
    * the results of a TD-DFT calculation 

(For a complete list see
http://cclib.sf.net/wiki/index.php/Parsed_Data).

cclib also provides some calculation methods for interpreting some
electronic properties of molecules using analyses such as:

    * Mulliken population analysis
    * Overlap population analysis
    * Calculation of Mayer's bond orders. 

For information on how to use cclib, see
      http://cclib.sf.net/wiki/index.php/Using_cclib.

If you need help, find a bug, want new features or have any questions,
please send an email to our mailing list:
	https://lists.sourceforge.net/lists/listinfo/cclib-users

Regards,

 The cclib development team

[cclib-devel] Ready for releasing 0.5 final

[Dr N. O'B. <no...@ca...>]

I have updated the licenses and references to 0.5b, and merged the changes 
to the release branch, so we are ready to roll on 0.5 final. I will make 
the release early next week if you have no objections.

Regards,
  Noel

[cclib-devel] [Fwd: [OpenBabel-Devel] Fwd: SourceForge.net SVN trouble]

[Noel O'B. <no...@ca...>]

-------- Forwarded Message --------
From: Geoffrey Hutchison <ge...@ge...>
To: openbabel-DISCUSS list <ope...@li...>,
openbabel-devel <ope...@li...>
Subject: [OpenBabel-Devel] Fwd: SourceForge.net SVN trouble
Date: Fri, 14 Jul 2006 09:58:35 -0400

Begin forwarded message:

> From: Egon Willighagen <ewi...@un...>
> Date: July 14, 2006 1:29:56 AM EDT

> Hi all,
>
> we all have all had our trouble with SVN since yesterday, and I  
> think I
> tracked down why. A Debian server was compromised proving the  
> existence of an
> exploit for a kernel security issue, and on the same day SF takes
> shell/svn/cvs access for a kernel exploit too (must be the same one):
>
> "( 2006-07-13 09:23:52 - Project CVS Service, Project Shell  
> Service, Project
> Subversion (SVN) Service, SourceForge.net Web Site  )   A recent  
> kernel
> exploit was released that allowed a non admin user to escalate  
> privileges on
> the host pr-shell1. We urge all users who frequent this host to  
> change their
> password immediately and check their project group space for any  
> tampering.
> As a precaution, we have blocked access to all project resources by  
> password
> until the user resets their password. After the password has been  
> reset,
> project resources should be accessible within 5 minutes."
>
> So, to enable write access for SVN again, you will have to change  
> your SF
> password, which you can do by logging in on the SF webpage, going  
> to "My
> Page" -> Preferences and choosing [Change Password] (how suprising ;)
>
> After I had done this I could commit to SVN again, though it did  
> require me to
> authenticate with my passward, as it was not done automatically  
> using my SSH
> key.
>
> Egon
>
> -- 
> CUBIC
> blog: http://chem-bla-ics.blogspot.com/



-------------------------------------------------------------------------
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
_______________________________________________
OpenBabel-Devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [cclib-devel] LGPL

[Noel O'B. <no...@ca...>]

> Is there anything you'd like me to focus on for the 0.5 final release?

I think it's just a case of getting it out there now. Let's declare a
feature and bug freeze.

If you have some spare time you might think about a way to make your
equations look nicer on the wiki (I think there's a way to do this on
the mediawiki help page somewhere in cyberspace). There's a TODO list
somewhere on the wiki on the Developer's page. I'm not brave enough to
look at it, but you may want to add to it, or better still, remove
things from it :-)

Noel

Re: [cclib-devel] LGPL

[Adam T. <a-t...@st...>]

> A very good answer - I think you've summed the situation up  
> exactly. The
> LGPL it is, then. I'm happy with this. And I know you are too.
>
> Today, I'll replace COPYING.txt or LICENSE.txt or whatever it's  
> called.
> I'll also look into replacing the docstring at the start of every  
> python
> file with something succinct as regards the license and copyright. I'm
> thinking something along the lines of:
> cclib, http://cclib.sf.net, (c) 2006, the cclib development team
> cclib is licensed under the LGPL (web ref)

Excellent. :o)

>
> As I mentioned before, it would be useful to have some 'help' text  
> here
> also - even something very basic. I don't think this is a priority
> before we release 0.5 final (since the web site gives quite reasonable
> help), but it's something to bear in mind.

Is there anything you'd like me to focus on for the 0.5 final release?

Adam

Re: [cclib-devel] [Pyquante-users] Package independent analysis of comp chem calcs

[Noel O'B. <no...@ca...>]

On Wed, 2006-07-12 at 14:32 -0600, Rick Muller wrote:
> Should certainly be possible to make a more robust interface.  
> Currently the HF and DFT codes have the following interface:
> 
>  >>> h2 = Molecule('H2',atomlist = [(1,(0,0,-0.7)),(1,(0,0,0.7))])
>  >>> energy, orbital_energy, orbitals = dft(h2)
> 
> If you also have the basis set, you can compute both orbital  
> amplitudes and densities at points in real space.
> 
> Let me know if I can help in any way. I've written code along these  
> lines before, and can probably dig up something close to what you need.

Sounds good. I'd like to see that code if you can find it.

I think a first attempt to make a useful bridge between cclib and
PyQuante would be for cclib to provide a function density() as follows:

def density(mocoeffs, coordinates, basis set, delta = 0.1, cube = None):
	"""Calculate the electron density using PyQuante.

	Requires:
          mocoeffs - mol. orb. coefficients in terms of atom orbitals
	  coordinates
          basis set - a set of Gaussian functions per atom (expressed as
                      per PyQuante user guide)
        Optional:
          delta - the dx/y/z value for points in the cube. Defaults to
                  0.1Ang or something sensible.
          cube - the dimensions of the cube. Default is something sensible
        Returns:
	  a Numeric array of the density (which can be visualised with
                                          MayaVi for example)
        """

If this makes sense to you and seems doable, I'll start hacking basis
set info out of log files. Of course, I will make sure that the above
code will work equally well for users of PyQuante and other comp. chem.
packages.

In PyQuante everything is Gaussian-based right? No STOs? If so, that
rules out ADF I think.

Noel

P.S. Let me know if you want to move this discussion from the pyquante
users list.

Re: [cclib-devel] LGPL

[Noel O'B. <no...@ca...>]

On Wed, 2006-07-12 at 12:50 -0700, Adam Tenderholt wrote:

> > It's just that I'm about to modify all of the license pages now, and
> > want to sort this out before I start doing this.
> 
> I still think we should make cclib LGPL. Whether we use LGPL or the  
> Python license, we still won't be allowed to use GPL code unless we  
> relicense under GPL. And I figure we would never be adding GPL code  
> since we're basically writing everything from scratch (except stuff  
> we initially wrote under GPL and have since decided to release under  
> a different license). So I don't see any advantages using a Python  
> license has.
> 
> My understanding of the requirements the LGPL would place on  
> derivative works is that it would have to be distributed as a library  
> under the LGPL and the modifications be available. At least this is  
> how it seems things are working between KHTML devs and Apple. Correct  
> me if I'm wrong...
> 
> Finally, if you have specific issues with using the LGPL let me know.  
> I think both of us are relatively flexible, and just have preferences  
> based on pre-conceived ideas. If there is any solid reason not to use  
> one of the licenses (like we did with the GPL), then I think it  
> should be stated and that it only makes sense to use the other.

A very good answer - I think you've summed the situation up exactly. The
LGPL it is, then. I'm happy with this. And I know you are too.

Today, I'll replace COPYING.txt or LICENSE.txt or whatever it's called.
I'll also look into replacing the docstring at the start of every python
file with something succinct as regards the license and copyright. I'm
thinking something along the lines of:
cclib, http://cclib.sf.net, (c) 2006, the cclib development team
cclib is licensed under the LGPL (web ref)

As I mentioned before, it would be useful to have some 'help' text here
also - even something very basic. I don't think this is a priority
before we release 0.5 final (since the web site gives quite reasonable
help), but it's something to bear in mind.

Regards,
  Noel

Re: [cclib-devel] [Pyquante-users] Package independent analysis of comp chem calcs

[Rick M. <rm...@sa...>]

cclib looks cool.



Should certainly be possible to make a more robust interface.  
Currently the HF and DFT codes have the following interface:

 >>> h2 = Molecule('H2',atomlist = [(1,(0,0,-0.7)),(1,(0,0,0.7))])
 >>> energy, orbital_energy, orbitals = dft(h2)

If you also have the basis set, you can compute both orbital  
amplitudes and densities at points in real space.

Let me know if I can help in any way. I've written code along these  
lines before, and can probably dig up something close to what you need.

Rick


On Jul 12, 2006, at 5:19 AM, Noel O'Boyle wrote:

> Dear Rick,
>
> I am one of the developers of cclib (http://cclib.sf.net) which  
> provides
> an interface to the results of comp chem calcs from various  
> proprietary
> comp chem packages. This is currently GPLed, but we may be moving to a
> more liberal license.
>
> A further goal of cclib is to provide some algorithms that allow
> analysis of the results of comp chem calcs in a platform and package
> independent way. Typical examples of some useful algorithms that  
> can be
> carried out after calculations are those that simply involve
> partitioning of the electron density, e.g. Hirshfeld charge analysis,
> AIM, NBO and so on.
>
> I have already coded a small bridge to PyQuante as part of cclib. I am
> interested in expanding this to allow 'recreation' and manipulation of
> the electron density given the basis set details extracted from log
> files. Could you give me any idea whether I will be able to use  
> PyQuante
> to accomplish some of these goals?

[cclib-devel] Package independent analysis of comp chem calcs

[Noel O'B. <no...@ca...>]

Dear Rick,

I am one of the developers of cclib (http://cclib.sf.net) which provides
an interface to the results of comp chem calcs from various proprietary
comp chem packages. This is currently GPLed, but we may be moving to a
more liberal license.

A further goal of cclib is to provide some algorithms that allow
analysis of the results of comp chem calcs in a platform and package
independent way. Typical examples of some useful algorithms that can be
carried out after calculations are those that simply involve
partitioning of the electron density, e.g. Hirshfeld charge analysis,
AIM, NBO and so on.

I have already coded a small bridge to PyQuante as part of cclib. I am
interested in expanding this to allow 'recreation' and manipulation of
the electron density given the basis set details extracted from log
files. Could you give me any idea whether I will be able to use PyQuante
to accomplish some of these goals?

Regards,
  Noel

[cclib-devel] LGPL

[Noel O'B. <no...@ca...>]

Hello Adam,

I'm back from holidays. And I've fixed that final (for now) bug with the
gaussian parser.

Regarding the licensing; if we include GPL code in cclib, then cclib
needs to become GPL (the opposite isn't true though; they can include
cclib code in their GPL code so long as our license is GPL-compatible,
which most licenses are).

This is the relevant quote from Wikipedia:
"""
Many of the most common free software licenses, such as the original
MIT/X license, the BSD license (in its current 3-clause form), and the
LGPL, are "GPL-compatible". That is, their code can be combined with a
GPLed program without conflict (the new combination would have the GPL
applied to the whole).
"""

To be honest, I'm still leaning towards the Python license, which is
what most Python software has anyway. This means we don't have to worry
about any of this stuff, so long as we don't want to include any
GPL-code in it. PyQuante uses a similar license, as does BioPython. If
you still say LGPL (to ensure pymol has no problems) then we'll do that.
It's just that I'm about to modify all of the license pages now, and
want to sort this out before I start doing this.

Regards,
  Noel

Re: [cclib-devel] Test files

[Noel O'B. <no...@ca...>]

On Tue, 2006-06-27 at 10:16 -0700, Adam Tenderholt wrote:
> >> Sounds good. Should I still do that for the first logfile, or  
> >> shall  we just archive it?
> > Not sure what you mean by the first logfile.
> 
> The first ADF logfile I emailed to the gmail account. I fixed the  
> bug. Should I reply to my email there?

I think so. Just a line to say it's fixed in whatever revision. Does
this system make sense?

SF has a bug tracker, and an alternative system would be to send the log
files to the gmail account but log a bug in the bug tracker. This has a
system for adding comments and marking bugs as closed and so on. The
original poster gets notified of any changes in the bug status, and an
email gets sent to the developers list simultaneously. Also, every bug
has a number. Our SF ranking would increase and in addition, users can
see that we have a system for dealing with bugs, which is pretty
transparent. The downside is a slight overhead.

> >> Did you mean sourceforge? I thought the idea of using the gmail   
> >> account was have a way to share large data files....
> > It is, but sourceforge also is functionning as a bug tracker in  
> > this instance. It's good to be able to download all of the test  
> > files at once, e.g. for a new developer or for someone who wants  
> > some test files for their own program (e.g. open babel might use  
> > these eventually).
> >
> > In any case, I've discovered releaseforge.sourceforge.net which  
> > makes it a doodle to release files. So I just tar up everything and  
> > make a release every so often with the SVN revision name. Check out  
> > the SF download site in another 8 hours for the first release. You  
> > just unzip it at the 'top level' of the directory structure, and it  
> > makes all of the data folders for you (or overwrites them).
> 
> Ok.
Really - it's no problem. And I meant to say doddle not doodle. :-)

> Adam
> 
> 
> 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

Re: [cclib-devel] Test files

[Adam T. <a-t...@st...>]

>> Sounds good. Should I still do that for the first logfile, or  
>> shall  we just archive it?
> Not sure what you mean by the first logfile.

The first ADF logfile I emailed to the gmail account. I fixed the  
bug. Should I reply to my email there?

>> Did you mean sourceforge? I thought the idea of using the gmail   
>> account was have a way to share large data files....
> It is, but sourceforge also is functionning as a bug tracker in  
> this instance. It's good to be able to download all of the test  
> files at once, e.g. for a new developer or for someone who wants  
> some test files for their own program (e.g. open babel might use  
> these eventually).
>
> In any case, I've discovered releaseforge.sourceforge.net which  
> makes it a doodle to release files. So I just tar up everything and  
> make a release every so often with the SVN revision name. Check out  
> the SF download site in another 8 hours for the first release. You  
> just unzip it at the 'top level' of the directory structure, and it  
> makes all of the data folders for you (or overwrites them).

Ok.

Adam

Re: [cclib-devel] Test files

[Dr N. O'B. <no...@ca...>]

>> (2) Email it to ccl...@go... with the following info:
>> (a) What's the problem? "Breaks parser" is fine, if that's all that we
>> know already.
>> (b) What revision does it have a problem with.
>> (c) Where does the file come from, and confirm that it's public domain
>> [I think we only spoke briefly about this before, but I believe  
>> that we
>> need all test log files to be public domain...are you happy with this
>> for your log files?? I have already asked Joe Townsend, and the AOMIX
>> files are, by nature, public domain]
>> (d) Where will the file be stored in the repository (not sure is this
>> necessary)
>
>I'm definitely ok making any broken log files I make be public domain.
Great.

>> (3) The log message of the revision that fixes the problem should  
>> refer
>> to the name of the problem log file (as well as the usual info).
>> (4) Login to googlemail and reply to the original problem with the  
>> name
>> of the revision that fixes it. This lets us know at a glance (on
>> googlemail) whether a particular log file is still a problem.  
>> (Although
>> we should also know this from regression.py)
>
>Sounds good. Should I still do that for the first logfile, or shall  
>we just archive it?
Not sure what you mean by the first logfile.

>> Somewhere in all of this, preferably after (2), to add a regression  
>> test
>> to regression.py for the problem. This will let the other developer  
>> know
>> that there's a problem that needs to be fixed and also that they are
>> missing a test file in their local repository. I have already added  
>> some
>> broken parser tests for the 4 files in the test repository (haven't  
>> done
>> anything about that second ADF example of yours).
>
>Ok. If it just "breaks" the parser, can the regression just test for  
>completion of the parsing function?
Exactly. Let's keep it simple for these tests or we won't add tests as 
it'll be too much of a chore. If you look at what I've added already you'll 
see that the files that break the parsers are just parsed. For more 
complicated problems, we can be a bit more imaginative depending on the 
problem.

>> I will try to set up an automated procedure to make a .zip of all  
>> of the
>> data files in my local repository (excluding the basic ones), and send
>> it up to sourceforge. I think there are ways to do this, but it will
>> take some time.
>
>Did you mean sourceforge? I thought the idea of using the gmail  
>account was have a way to share large data files....
It is, but sourceforge also is functionning as a bug tracker in this 
instance. It's good to be able to download all of the test files at once, 
e.g. for a new developer or for someone who wants some test files for their 
own program (e.g. open babel might use these eventually).

In any case, I've discovered releaseforge.sourceforge.net which makes it a 
doodle to release files. So I just tar up everything and make a release 
every so often with the SVN revision name. Check out the SF download site 
in another 8 hours for the first release. You just unzip it at the 'top 
level' of the directory structure, and it makes all of the data folders for 
you (or overwrites them).

>> I'll wikify these instructions if they sound reasonable - please  
>> let me
>> know any further ideas.
>>
>> Oh yeah, could you send to google that Gaussian example you said there
>> was a problem with?
>
>If I can find it again, yep. ;o)
Great.
>Adam
>
>
> 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

Re: [cclib-devel] Test files

[Adam T. <a-t...@st...>]

> I've just been doing some tidying up of the tests. I've removed the
> so-called wild folders, and used our new Googlemail system instead.  
> Here
> are some proposed guidelines for dealing with new problem output  
> files:

Excellent

> (0) Give it a unique name (compared to others in the repository)
> (1) gzip it

Make sense. Sorry for not doing that to the first two I uploaded to  
gmail.

> (2) Email it to ccl...@go... with the following info:
> (a) What's the problem? "Breaks parser" is fine, if that's all that we
> know already.
> (b) What revision does it have a problem with.
> (c) Where does the file come from, and confirm that it's public domain
> [I think we only spoke briefly about this before, but I believe  
> that we
> need all test log files to be public domain...are you happy with this
> for your log files?? I have already asked Joe Townsend, and the AOMIX
> files are, by nature, public domain]
> (d) Where will the file be stored in the repository (not sure is this
> necessary)

I'm definitely ok making any broken log files I make be public domain.

> (3) The log message of the revision that fixes the problem should  
> refer
> to the name of the problem log file (as well as the usual info).
> (4) Login to googlemail and reply to the original problem with the  
> name
> of the revision that fixes it. This lets us know at a glance (on
> googlemail) whether a particular log file is still a problem.  
> (Although
> we should also know this from regression.py)

Sounds good. Should I still do that for the first logfile, or shall  
we just archive it?

> Somewhere in all of this, preferably after (2), to add a regression  
> test
> to regression.py for the problem. This will let the other developer  
> know
> that there's a problem that needs to be fixed and also that they are
> missing a test file in their local repository. I have already added  
> some
> broken parser tests for the 4 files in the test repository (haven't  
> done
> anything about that second ADF example of yours).

Ok. If it just "breaks" the parser, can the regression just test for  
completion of the parsing function?

> I will try to set up an automated procedure to make a .zip of all  
> of the
> data files in my local repository (excluding the basic ones), and send
> it up to sourceforge. I think there are ways to do this, but it will
> take some time.

Did you mean sourceforge? I thought the idea of using the gmail  
account was have a way to share large data files....

> I'll wikify these instructions if they sound reasonable - please  
> let me
> know any further ideas.
>
> Oh yeah, could you send to google that Gaussian example you said there
> was a problem with?

If I can find it again, yep. ;o)

Adam

[cclib-devel] Test files

[Noel O'B. <no...@ca...>]

I've just been doing some tidying up of the tests. I've removed the
so-called wild folders, and used our new Googlemail system instead. Here
are some proposed guidelines for dealing with new problem output files:

(0) Give it a unique name (compared to others in the repository)
(1) gzip it
(2) Email it to ccl...@go... with the following info:
(a) What's the problem? "Breaks parser" is fine, if that's all that we
know already.
(b) What revision does it have a problem with.
(c) Where does the file come from, and confirm that it's public domain
[I think we only spoke briefly about this before, but I believe that we
need all test log files to be public domain...are you happy with this
for your log files?? I have already asked Joe Townsend, and the AOMIX
files are, by nature, public domain]
(d) Where will the file be stored in the repository (not sure is this
necessary)
(3) The log message of the revision that fixes the problem should refer
to the name of the problem log file (as well as the usual info).
(4) Login to googlemail and reply to the original problem with the name
of the revision that fixes it. This lets us know at a glance (on
googlemail) whether a particular log file is still a problem. (Although
we should also know this from regression.py)

Somewhere in all of this, preferably after (2), to add a regression test
to regression.py for the problem. This will let the other developer know
that there's a problem that needs to be fixed and also that they are
missing a test file in their local repository. I have already added some
broken parser tests for the 4 files in the test repository (haven't done
anything about that second ADF example of yours).

I will try to set up an automated procedure to make a .zip of all of the
data files in my local repository (excluding the basic ones), and send
it up to sourceforge. I think there are ways to do this, but it will
take some time.

I'll wikify these instructions if they sound reasonable - please let me
know any further ideas.

Oh yeah, could you send to google that Gaussian example you said there
was a problem with?

Regards,
 Noel

Re: [cclib-devel] Final release of 0.5

[Noel O'B. <no...@ca...>]

On Wed, 2006-06-21 at 16:08 -0700, Adam Tenderholt wrote:
> > Well, I want to use whatever the standard method is. I create the
> > Windows distribution using standard disutils commands:
> > python setup.py sdist    (to create the .tar.gz for Linux)
> > python setup.py bdist_wininst (to create the windows installer)
> >
> > There's no option (at least with the distutils supplied in Linux) to
> > create a Mac installer. I would expect Mac users to just do as Linux
> > users do. I wouldn't worry about anything more.
> 
> I was thinking there was something like bdist_mpkg, but I guess I was  
> wrong. Maybe that's an option for setup.py when py2app is being used.  
> Do you know if the bdist option just byte-compiles the source for  
> that specific plaform? Just curious. Source distribution makes sense  
> as well for Mac since it's pretty easy to fire up a terminal and run  
> python setup.py install. I suspect anyone using cclib on the Mac is  
> going to be savvy enough to manage this step.

  sdist            create a source distribution (tarball, zip file, etc.)
  register         register the distribution with the Python package index
  bdist            create a built (binary) distribution
  bdist_dumb       create a "dumb" built distribution
  bdist_rpm        create an RPM distribution
  bdist_wininst    create an executable installer for MS Windows

The bdist_wininst installs the source as well as compiling on Windows.
The others I don't know anything about. There's also py2exe.

> > Sounds good. The more generic stuff you can put into cclib the better.
> > You should also take a look at Viewmol.
> 
> Viewmol looks promising, esp since it's GPL. That should mean there  
> isn't a problem adapting part of that code and including it in  
> PyMOlyze, provided I leave any copyright statements intact, right?

Ah...I wouldn't be so sure about that. So check it out at Groklaw or
whereever. I think the author would have no problem sharing code with
us/you if you asked nicely - I think he's very involved in OSS, although
not so active with Viewmol anymore.

> > That would be good, but maybe there are ways to do this that aren't
> > KDE-specific. e.g. some sort of python ssh library
> 
> Interesting point, although there are other uses of KIO-slaves like  
> the zip and gz. I can imagine that being somewhat useful if people  
> compress their files after analyzing them, and decide to take another  
> look.
Aha, but don't forget to think about using a python gzip library...it's
somewhere in the standard library, I think.

> > I recommend running ccget on every output file you can find. If you're
> > brave you could try:
> > ccget `find . | grep .out` which would run ccget on every .out file in
> > your directory structure (recursively). You'll soon find out if there
> > are any problems.
> 
> So all my Gaussian files except one worked ok. The one that didn't  
> threw a logging error, so I think it's probably a broken file. I can  
> upload it if you want.
> 
> ADF, unfortunately, had a lot of problems. Several of the files  
> didn't have any attributes to print, which I find odd because I'd  
> expect *something*. A few just completely crapped out with  
> IndexErrors or TypeErrors. Is there a limit to the filesizes we  
> should be uploading? Or should I just put it on a website somewhere  
> for you to access?
Ok, we're going to have to sort this out somehow. I think you're right
that we cannot be putting everything up on SVN. Here are some ideas.

In the short term, we need to share log files easily between us, and
keep track of what log files there are for testing, and write unit tests
for them. If we're not going to use SVN we need to use email, I guess;
we could share a gmail a/c between us, with log files as attachments and
the body explains what the bug is, and which SVN revision the bug occurs
with. We could integrate this with the bug tracker on SF in the medium
term, once we get bug submissions externally; in that case, the body of
the gmail email would only need to be a reference to the bug number.

Every so often we can make a release of example log files, basically a
tar.gz of the Data directory.

I'll send you the gmail account address and password off list.

Regards,
 Noel

> Adam
> 
> 
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Final release of 0.5

[Adam T. <a-t...@st...>]

> Well, I want to use whatever the standard method is. I create the
> Windows distribution using standard disutils commands:
> python setup.py sdist    (to create the .tar.gz for Linux)
> python setup.py bdist_wininst (to create the windows installer)
>
> There's no option (at least with the distutils supplied in Linux) to
> create a Mac installer. I would expect Mac users to just do as Linux
> users do. I wouldn't worry about anything more.

I was thinking there was something like bdist_mpkg, but I guess I was  
wrong. Maybe that's an option for setup.py when py2app is being used.  
Do you know if the bdist option just byte-compiles the source for  
that specific plaform? Just curious. Source distribution makes sense  
as well for Mac since it's pretty easy to fire up a terminal and run  
python setup.py install. I suspect anyone using cclib on the Mac is  
going to be savvy enough to manage this step.

> Sounds good. The more generic stuff you can put into cclib the better.
> You should also take a look at Viewmol.

Viewmol looks promising, esp since it's GPL. That should mean there  
isn't a problem adapting part of that code and including it in  
PyMOlyze, provided I leave any copyright statements intact, right?

> That would be good, but maybe there are ways to do this that aren't
> KDE-specific. e.g. some sort of python ssh library

Interesting point, although there are other uses of KIO-slaves like  
the zip and gz. I can imagine that being somewhat useful if people  
compress their files after analyzing them, and decide to take another  
look.

> There are no known bugs at the moment...right? So nothing to fix. I  
> can
> only think of new features, and they won't be going into cclib 0.5. I
> will probably continue to do some work on the Jaguar parser in  
> prep. for
> the next version, unless we find some bugs with the current parsers.
>
> I recommend running ccget on every output file you can find. If you're
> brave you could try:
> ccget `find . | grep .out` which would run ccget on every .out file in
> your directory structure (recursively). You'll soon find out if there
> are any problems.

So all my Gaussian files except one worked ok. The one that didn't  
threw a logging error, so I think it's probably a broken file. I can  
upload it if you want.

ADF, unfortunately, had a lot of problems. Several of the files  
didn't have any attributes to print, which I find odd because I'd  
expect *something*. A few just completely crapped out with  
IndexErrors or TypeErrors. Is there a limit to the filesizes we  
should be uploading? Or should I just put it on a website somewhere  
for you to access?

Adam

Re: [cclib-devel] Final release of 0.5

[Noel O'B. <no...@ca...>]

On Tue, 2006-06-20 at 09:08 -0700, Adam Tenderholt wrote:
> > What do you think about getting a final release of 0.5 out there?  
> > I'm on
> > holidays the first week of July, so we should either do it later this
> > week, first thing next week, or after I come back.
> 
> I haven't really worked on cclib recently, so unless you're really  
> anxious to get it out this week, I say we wait until you get back.  
> This will give both of us a bit of time to work on some of the points  
> below, and will allow me time to throw some more files I have at our  
> parsers to see if I can break them.

OK, DOK.

> > This release will be announced on the CCL, GAMESS users, and ADF users
> > lists, so we should be prepared for a large number of hits if nothing
> > else. I haven't received any feedback for any downloaders of the
> > software, and there have been a few if you look at the SF and  
> > cheeseshop
> > download pages.
> 
> What about the Gaussian lists?
Aha, but there's no such thing. Gaussian relies on the volunteer efforts
of Jan and co. at ccl.net to provide user-assisted support. In fact, as
you can see from http://www.ccl.net/cgi-bin/ccl/supporting_members they
have not even contributed to this effort. They could do a bit more to
combat their image as the Microsoft of quantum chemistry.

> I'm not sure I really expect a lot of  
> users since one needs to know be familiar with programming, and  
> chemists with such skills seem to be on the decline...at least that's  
> been my experience here so far. But I'm sure we'll have a handful of  
> really excited people.
Well, I think that would be really good.

> > The ChangeLog is basically some bug fixes to the parsers to deal with
> > AOMIXes examples. Internally, we're going to have changed license  
> > to the
> > LGPL, and the code will have some nice spacing. I need to add some  
> > more
> > stuff about necessary keywords to the wiki. Also, instead of a .zip
> > files for Windows, I will create a binary source distribution for
> > Windows (this is the usual way of distributing Python modules for
> > windows - allows uninstallation using Add/Remove Programs too).
> 
> Ok, sounds good. I can make a Mac OS X package if you want that as well.
Well, I want to use whatever the standard method is. I create the
Windows distribution using standard disutils commands:
python setup.py sdist    (to create the .tar.gz for Linux)
python setup.py bdist_wininst (to create the windows installer)

There's no option (at least with the distutils supplied in Linux) to
create a Mac installer. I would expect Mac users to just do as Linux
users do. I wouldn't worry about anything more.

> > Here's some things that are on my mind to do, not for 0.5final though:
> > 1. Replace the docstring at the start of every .py file with something
> > useful for people looking for information. Currently it's some GPL
> > stuff, which isn't very informative. The idea is that people who type:
> > "help(cclib.parser)" or whatever, find out something useful, not
> > licensing information. We can create documentation for users from  
> > this,
> > using pydoc -w, which creates a html pages with info, or we could cut
> > and paste into the wiki.
> 
> Right. I think we should maintain some license info such as a  
> copyright line and a licensed under the LGPL line with a link to the  
> GNU page. After that, i think we should definitely try and put some  
> more useful help in the docstring.
OK.

> > 2. Could we push the code for progress updating into a function of the
> > progress object? Going through the Gaussian parser for example, the  
> > same
> > code is duplicated in a number of places. In the interest of
> > maintainability, I think it'd be good to just call a method of a the
> > Progress object to update this info.
> 
> I think part of the reason for all of the code is that we wanted 1)  
> to check to make sure there was a progress object, and 2) not call it  
> every single time in the interest of speed. Most of the "actual" code  
> is in the update function of the progress class. We could probably  
> move step!=oldstep into the progress class, but we definitely need  
> the step = inputfile.tell().
Hmmm...I need to think some more about this, and play around with it a
bit...I'll put it on my list of things to think about eventually. :-)

> > 3. I've run out of good ideas, so here's a possibly bad one. Create
> > parsers for 3D surface information. This is actually pretty easy, and
> > would allow pymol for example to read in cube files/TAPE41 files (or
> > whatever) from different programs. It'd also be easy to create bridges
> > to other open source molecular visualisation software (e.g. MayaVi  
> > takes
> > Numeric arrays).
> 
> I actually this this is a good idea, mainly because at some point, I  
> want to create an awesome molden replacement with the following  
> characteristics (called PyMOlyze, since I already have most of part 2):
Sounds good. The more generic stuff you can put into cclib the better.
You should also take a look at Viewmol.

> 1) Easy to use z-matrix and cartesian coordinate editor. Chem3D isn't  
> bad for this, but it's ugly and not cross-platform or open source.
> 
> 2) Population analysis and bond orders
> 
> 3) Easy-to-use command-line interface for converting surfaces (and  
> maybe frequencies) to a povray file for easy rendering and animation.  
> (I currently have a script that isn't very intuitive that calls  
> molden, but it's way slow because it opens the Gaussian log file  
> everytime I want an orbital. That's either my lack-of-understanding  
> or a molden problem.)
> 
> 4) Monitor the progress of the calculation. This would be especially  
> useful if I add optional KDE-bindings that uses KIO-slaves....just  
> browse to the calc machine through FISH or SFTP, open the file, and  
> tada! no more middle step of copying to your computer first. And once  
> KDE is ported to windows and mac, I could completely switch to it  
> (unless it's a pain to build).
That would be good, but maybe there are ways to do this that aren't
KDE-specific. e.g. some sort of python ssh library
> > Oh yes, cclib has been accepted into the Free Software session at
> > CompLife06 http://www.inf.uni-konstanz.de/complife06/freesoft.html  
> > which
> > will be in Cambridge at the end of Sept. I'm not sure how  
> > interested the
> > attendees will be in the software, but there might be a few. There's
> > only 5 minutes to present the software, but 90 minutes of face-to-face
> > discussions afterwards along with all of the other software  
> > presenters.
> 
> Cool! Hopefully there will be some very interested people there.
> 
> Let me know what I should fix to get cclib ready for the release.
There are no known bugs at the moment...right? So nothing to fix. I can
only think of new features, and they won't be going into cclib 0.5. I
will probably continue to do some work on the Jaguar parser in prep. for
the next version, unless we find some bugs with the current parsers.

I recommend running ccget on every output file you can find. If you're
brave you could try:
ccget `find . | grep .out` which would run ccget on every .out file in
your directory structure (recursively). You'll soon find out if there
are any problems.

Noel

Re: [cclib-devel] Final release of 0.5

[Adam T. <a-t...@st...>]

> What do you think about getting a final release of 0.5 out there?  
> I'm on
> holidays the first week of July, so we should either do it later this
> week, first thing next week, or after I come back.

I haven't really worked on cclib recently, so unless you're really  
anxious to get it out this week, I say we wait until you get back.  
This will give both of us a bit of time to work on some of the points  
below, and will allow me time to throw some more files I have at our  
parsers to see if I can break them.

> This release will be announced on the CCL, GAMESS users, and ADF users
> lists, so we should be prepared for a large number of hits if nothing
> else. I haven't received any feedback for any downloaders of the
> software, and there have been a few if you look at the SF and  
> cheeseshop
> download pages.

What about the Gaussian lists? I'm not sure I really expect a lot of  
users since one needs to know be familiar with programming, and  
chemists with such skills seem to be on the decline...at least that's  
been my experience here so far. But I'm sure we'll have a handful of  
really excited people.

> The ChangeLog is basically some bug fixes to the parsers to deal with
> AOMIXes examples. Internally, we're going to have changed license  
> to the
> LGPL, and the code will have some nice spacing. I need to add some  
> more
> stuff about necessary keywords to the wiki. Also, instead of a .zip
> files for Windows, I will create a binary source distribution for
> Windows (this is the usual way of distributing Python modules for
> windows - allows uninstallation using Add/Remove Programs too).

Ok, sounds good. I can make a Mac OS X package if you want that as well.

> Here's some things that are on my mind to do, not for 0.5final though:
> 1. Replace the docstring at the start of every .py file with something
> useful for people looking for information. Currently it's some GPL
> stuff, which isn't very informative. The idea is that people who type:
> "help(cclib.parser)" or whatever, find out something useful, not
> licensing information. We can create documentation for users from  
> this,
> using pydoc -w, which creates a html pages with info, or we could cut
> and paste into the wiki.

Right. I think we should maintain some license info such as a  
copyright line and a licensed under the LGPL line with a link to the  
GNU page. After that, i think we should definitely try and put some  
more useful help in the docstring.

> 2. Could we push the code for progress updating into a function of the
> progress object? Going through the Gaussian parser for example, the  
> same
> code is duplicated in a number of places. In the interest of
> maintainability, I think it'd be good to just call a method of a the
> Progress object to update this info.

I think part of the reason for all of the code is that we wanted 1)  
to check to make sure there was a progress object, and 2) not call it  
every single time in the interest of speed. Most of the "actual" code  
is in the update function of the progress class. We could probably  
move step!=oldstep into the progress class, but we definitely need  
the step = inputfile.tell().

> 3. I've run out of good ideas, so here's a possibly bad one. Create
> parsers for 3D surface information. This is actually pretty easy, and
> would allow pymol for example to read in cube files/TAPE41 files (or
> whatever) from different programs. It'd also be easy to create bridges
> to other open source molecular visualisation software (e.g. MayaVi  
> takes
> Numeric arrays).

I actually this this is a good idea, mainly because at some point, I  
want to create an awesome molden replacement with the following  
characteristics (called PyMOlyze, since I already have most of part 2):

1) Easy to use z-matrix and cartesian coordinate editor. Chem3D isn't  
bad for this, but it's ugly and not cross-platform or open source.

2) Population analysis and bond orders

3) Easy-to-use command-line interface for converting surfaces (and  
maybe frequencies) to a povray file for easy rendering and animation.  
(I currently have a script that isn't very intuitive that calls  
molden, but it's way slow because it opens the Gaussian log file  
everytime I want an orbital. That's either my lack-of-understanding  
or a molden problem.)

4) Monitor the progress of the calculation. This would be especially  
useful if I add optional KDE-bindings that uses KIO-slaves....just  
browse to the calc machine through FISH or SFTP, open the file, and  
tada! no more middle step of copying to your computer first. And once  
KDE is ported to windows and mac, I could completely switch to it  
(unless it's a pain to build).

> Oh yes, cclib has been accepted into the Free Software session at
> CompLife06 http://www.inf.uni-konstanz.de/complife06/freesoft.html  
> which
> will be in Cambridge at the end of Sept. I'm not sure how  
> interested the
> attendees will be in the software, but there might be a few. There's
> only 5 minutes to present the software, but 90 minutes of face-to-face
> discussions afterwards along with all of the other software  
> presenters.

Cool! Hopefully there will be some very interested people there.

Let me know what I should fix to get cclib ready for the release.

Adam