Re: [cclib-devel] Miscellaneous

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

> On some miscellaneous notes,
> (1) I've put information on the symmetry labels used by ADF and GAMESS
> on the mosyms page. Have you considered that we should extract all of
> the symmetry labels if we extract all of the evalues? The info on the
> wiki needs to be updated if we agree to go down this route.

I agree that we should extract all the symmetry labels if we extract all
the evalues. I'll update the wiki later.

> (2) It'd be good if you could run testall.py before uploading svn
> changes as this guarantees that code doesn't break, and that we move in
> the direction of passing increasing numbers of tests (a bug in the
> latest revision means that all tests failed for adfparser). And I think
> it's a pretty neat way of comparing the results from different programs
> for some sort of parser validation.

In the case of my most recent commit, I think you're right. It was a
silly bug for the gopt case that I hadn't considered. However, I feel
this isn't practical sometimes. What if I start work on a file, take a
few days off before getting it to pass the tests, and then you begin
working on something I had already started? We'd be duplicating our
efforts. This may be a good thing because you might have the better
solution, but may also be a waste of time. Also, what if we start work
on one computer (work) and then finish it on another computer (home)?
It's easy to hunt down the changed files and copy them as needed, but
it's not as trivial as just updating your working copy.

I know these two scenarios are rather unlikely and/or the "hard" fix
outside of svn is actually quite easy, but I think they should at least
be mentioned. If you think we should just ignore them, that's fine.
Otherwise, I have two suggestions:

1) Create unstable branches for those few times when we're going to
start working on a file, but we can't get it to pass the unit tests
before we take a few day break. This would be as simple as svn copy to
create new branch, switch to that branch, and then make changes. After
work is finished, it can be merged (hopefully automatically) back into
the main branch.

2) Run the tests before a commit, and if anything breaks, say which part
 in the commit log so it's not a complete surprise to other devs. We'll
be able to review the changes that caused the break, and revert or fix
them as necessary.

What do you think?

> (3) With regard to aonames (or anything else), upload any relevant test
> files although try to aim for as small a file as possible. If you could
> add a description to the metadata, it'll make it easier for me to do the
> same (if necessary) for some of the other codes. As you are taking the
> lead on aonames, it'd also be good if you put up some specs/examples on
> the wiki, and I'll make sure other parsers meet the specs.

Ok. It's basically because I'm not sure how frozen core basis functions
with ADF translate into an aoname yet. I figure single atoms will be
sufficient.

Happy Easter!

Adam