Re: [cclib-devel] Release of cclib 0.6b

[Noel O'B. <bao...@gm...>]

I've had a quick look at this...

1) as you say, there's nothing to do here really...a warning message is
fine.
2) I would tend to go for the more 'right' solution, which you say is B.
This seems also to be the simpler solution (in terms of logic, not
necessarily implementation). However, since you are likely to be doing the
implementation you may want to reconsider. In either case, since as you say
the fix is a bit convoluted, it's probably best to create a function where
you pass in a label, and it returns something or other. This will also make
it easier to doctest (see normalisesym()). To run the doctests, you just
need to run "python adfparser.py".

P.S. The gmail/SF issue appears to be resolved.

Noel

On 06/10/06, Adam Tenderholt <a-t...@st...> wrote:
>
> > I've just made a release of cclib 0.6b. I was going to call it
> > cclib 0.6,
> > but several regression tests fail. This is a very good way of
> > marking a bug,
> > as there's no way to forget about it once there's a failing test.
> > Once all
> > tests on the released parsers pass, another release will follow.
>
> The two parser errors are in ADF files. The problems are as follows:
>
> 1) dvb_sp_c.adfout: moenergies isn't created because it is missing
> information for MOs 1-25. I'm not sure why this is the case because
> the only difference between its input file and that of dvb_sp.adfout
> is the additional "symmetry NOSYM" keyword.
>
> 2) mo_sp.adfout: during my symmetry > c1 changes, this apparently
> broke due to the "symlist" dictionary needed for sorting
> mocoefficents based on energy instead of symmetry. Just as E and T
> symmetry labels are looped through a few times, P, D, and F labels
> should also be looped through. This won't be a trivial fix because
> instead of setting up the symlist dictionary with E:1, E:2, etc.
> based on the number of times through the loop, smarter things will
> have to be added like P:x, P:y, D:z2, etc.
>
> I don't think we should worry too much about problem #1 as there
> isn't enough info for us to parse in this case. However, we should
> probably identify an ADF keyword that fixes the problem and add it to
> the wiki. Problem #2 should be fixed, although I'm not sure of the
> best way. I can think of two ways...
>
> A) Add P, D, and F to the multiple dictionary when MO info is being
> parsed. Also create a function that correctly translates P:x, P:y,
> D:xy, D:z2, etc. to something that matches the P:1, P:2, etc. which
> will be in the symlist dictionary when mocoeffs are parsed.
>
> B) When MO info is being parsed, check for cases of P, D, and F and
> correctly create symlist dictionary keys P:x, P:y, D:z2, etc. No
> changes necessary for the part when mocoeffs are parsed.
>
> While B is more "right" based on the actual names, I think
> implementing it will require more convoluted code than option A
> because of the checked needed to change P into P:x, P:y, P:z
> dictionary keys.
>
> What do you think?
>
> Adam
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>