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