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