cclib-devel — Developer's mailing list

Re: [cclib-devel] Jaguar data files

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

On 31/10/2007, Karol Langner <kar...@kn...> wrote:
> On Wednesday 31 October 2007 07:35, Noel O'Boyle wrote:
> > > Done. The cclib package is now almost 50% slimmer, so that might be
> > > something to still include in the 0.8 final.
> > > Still to do:
> > > 1. Support reading multiple files in regressions.py, plus general
> > > cleanup. 2. Allow unittests to be run in regressions.py, for those
> > > used-to-be-unittests and maybe other files.
> > > 3. Update further to Jaguar7.0 when we get the liscence.
> >
> > Regarding 2, wouldn't it be easier just to have testall.py run those
> > tests if basicJaguar4.2 is present? This would be a lot easier to
> > implement and I don't see any downside.
>
> You mean "Jaguar4.2" now. That would work, the coverage is the same, and I
> think both solutions are easy to implement. The question is just, how
> important is keeping the most-recent unittests separate from the regressions.

I don't think it's a good idea to keep them too separate. Otherwise,
failures will only be discovered at a later point...

> I see one drawback: if you parse test these files with testall.py and then go
> on to run regression.py, you will actually parse them twice!

Regression.py parses everything twice already, because there are files
in the basic folders which are not tested by "testall.py".

> > Regarding 1, we should probably make a subfolder of tests, and put
> > everything that testall.py imports into that.
>
> I agree; also, for clarity I think the current 'testall' should be renamed
> to 'testparser' since thats what it does. In my view, a 'testall' script
> would run testparser, testmethod, whatever other testsuits there may be and
> possibly regressions, and print the results in **very** condensed form.

Sure.

Noel

Re: [cclib-devel] Jaguar data files

[Karol L. <kar...@kn...>]

On Wednesday 31 October 2007 07:35, Noel O'Boyle wrote:
> > Done. The cclib package is now almost 50% slimmer, so that might be
> > something to still include in the 0.8 final.
> > Still to do:
> > 1. Support reading multiple files in regressions.py, plus general
> > cleanup. 2. Allow unittests to be run in regressions.py, for those
> > used-to-be-unittests and maybe other files.
> > 3. Update further to Jaguar7.0 when we get the liscence.
>
> Regarding 2, wouldn't it be easier just to have testall.py run those
> tests if basicJaguar4.2 is present? This would be a lot easier to
> implement and I don't see any downside.

You mean "Jaguar4.2" now. That would work, the coverage is the same, and I 
think both solutions are easy to implement. The question is just, how 
important is keeping the most-recent unittests separate from the regressions. 
I see one drawback: if you parse test these files with testall.py and then go 
on to run regression.py, you will actually parse them twice!

> Regarding 1, we should probably make a subfolder of tests, and put
> everything that testall.py imports into that.

I agree; also, for clarity I think the current 'testall' should be renamed 
to 'testparser' since thats what it does. In my view, a 'testall' script 
would run testparser, testmethod, whatever other testsuits there may be and 
possibly regressions, and print the results in **very** condensed form.

Wonder what you think about that,
Karol

-- 
written by Karol Langner
Wed Oct 31 13:41:45 EDT 2007

Re: [cclib-devel] Jaguar data files

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

> Done. The cclib package is now almost 50% slimmer, so that might be something
> to still include in the 0.8 final.
> Still to do:
> 1. Support reading multiple files in regressions.py, plus general cleanup.
> 2. Allow unittests to be run in regressions.py, for those used-to-be-unittests
> and maybe other files.
> 3. Update further to Jaguar7.0 when we get the liscence.

Regarding 2, wouldn't it be easier just to have testall.py run those
tests if basicJaguar4.2 is present? This would be a lot easier to
implement and I don't see any downside.

Regarding 1, we should probably make a subfolder of tests, and put
everything that testall.py imports into that.

Noel

Re: [cclib-devel] ADF test files

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

> I wonder if anyone can comment on the fact that for ADF we have 4
> single-point tests ('sp', 'sp_b', 'sp_c', 'sp_d'), two sp_un tests,  
> and two
> gopt tests.

Depending on whether or not ADF detects symmetry, different headers  
for the MO energies are present. Also, I think there is an additional  
keyword to tell ADF to print all the orbitals instead of a subset  
around the HOMO-LUMO gap.

Adam

[cclib-devel] ADF test files

[Karol L. <kar...@kn...>]

Hi,

 Just to brief you on my recent ADF-related commits. I reran all ADF tests in 
versions 2006.01 and 2007.01, leaving the unittests to use only basic2007.01 
files. I put all 2004.01 test files and one (gopt) 2007.01 file in 
regressions.

 I wonder if anyone can comment on the fact that for ADF we have 4 
single-point tests ('sp', 'sp_b', 'sp_c', 'sp_d'), two sp_un tests, and two 
gopt tests.

- Karol

-- 
written by Karol Langner
Tue Oct 30 18:18:44 EDT 2007

Re: [cclib-devel] problem of parsing clusters with large spin multiplicity

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

Yes. It just took me some time to make the example test files.

On 30/10/2007, Karol Langner <kar...@kn...> wrote:
> Is this the bug you added to the tracker recently?
>
> On Wednesday 24 October 2007 11:12, Noel O'Boyle wrote:
> > Thanks for reporting this problem. I will fix this in cclib...
> >
> > In the meanwhile, just change the line:
> >  Charge =3D  0 Multiplicity =3D18
> > to...
> >  Charge =3D  0 Multiplicity =3D 18
> > by adding a space after the equals sign. It should work then.
> >
> > Noel
> >
> > On 24/10/2007, su...@yo... <su...@yo...> wrote:
> > > Dear Mr. O=B4Boyle.
> > >
> > >  I am having problem with parsing the output G03 file of rh_13 cluste=
rs
> > > by Gausssum, one of them is rh_13 with 2s+1=3D10, the other is Rh_13 =
with
> > > 2s+1=3D18, I attached the zipped output file and if you could take a =
look
> > > and give me some suggestion, I will greatly appreciate. Thank you for
> > > your help.
> > >
> > > All the best,
> > >
> > > Yan
>
> --
> written by Karol Langner
> Mon Oct 29 20:51:10 EDT 2007
>

Re: [cclib-devel] problem of parsing clusters with large spin multiplicity

[Karol L. <kar...@kn...>]

Is this the bug you added to the tracker recently?

On Wednesday 24 October 2007 11:12, Noel O'Boyle wrote:
> Thanks for reporting this problem. I will fix this in cclib...
>
> In the meanwhile, just change the line:
>  Charge =3D  0 Multiplicity =3D18
> to...
>  Charge =3D  0 Multiplicity =3D 18
> by adding a space after the equals sign. It should work then.
>
> Noel
>
> On 24/10/2007, su...@yo... <su...@yo...> wrote:
> > Dear Mr. O=B4Boyle.
> >
> >  I am having problem with parsing the output G03 file of rh_13 clusters
> > by Gausssum, one of them is rh_13 with 2s+1=3D10, the other is Rh_13 wi=
th
> > 2s+1=3D18, I attached the zipped output file and if you could take a lo=
ok
> > and give me some suggestion, I will greatly appreciate. Thank you for
> > your help.
> >
> > All the best,
> >
> > Yan

=2D-=20
written by Karol Langner
Mon Oct 29 20:51:10 EDT 2007

[cclib-devel] ANN: cclib 0.8 now available for download

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

cclib 0.8 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), GAMESS-UK,
Gaussian, Jaguar, Molpro and PC GAMESS.

Among other data, cclib extracts:

    * coordinates and energies
    * information about geometry optimization
    * 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 the
electronic properties of molecules using analyses such as:

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

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

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

Re: [cclib-devel] Jaguar data files

[Karol L. <kar...@kn...>]

On Saturday 20 October 2007 18:20, Noel O'Boyle wrote:
> On 19/10/2007, Karol Langner <kar...@kn...> wrote:
> > On Saturday 13 October 2007 08:37, Noel O'Boyle wrote:
> > > On 13/10/2007, Karol Langner <kar...@kn...> wrote:
> > > > > > Let me start things up again with a
> > > > > > simple issue - why do we have three different basicJaguar*
> > > > > > directories in trunk/data/? It seems logical to use data files
> > > > > > for unittests only from the newest Jaguar version and to change
> > > > > > the rest to regressions. That is the situation for Gaussian and
> > > > > > ADF (although here basicADF2004 is not the newest version). Why
> > > > > > should Jaguar be an exception?
> > > > >
> > > > > If a newer version of Gaussian comes out or if we have access to a
> > > > > newer version of ADF, Jaguar won't be the exception. I'm not sure
> > > > > what you mean by changing the unittests to regressions. If we
> > > > > support JaguarX, then we should have unittests to ensure this.
> > > >
> > > > There are probably more people using Gaussian98 than there are using
> > > > Jaguar4.2, so I don't see why we should only support older version of
> > > > Jaguar and not Gaussian.
> > >
> > > There's no reason. We just started supporting whatever programs we had
> > > access to.
> >
> > Of course, and access changes and versions become old. The data files
> > packaged along with cclib should reflect the current state of our access
> > to the newest program versions.
>
> That's fine by me.

Done. The cclib package is now almost 50% slimmer, so that might be something 
to still include in the 0.8 final.
Still to do:
1. Support reading multiple files in regressions.py, plus general cleanup.
2. Allow unittests to be run in regressions.py, for those used-to-be-unittests 
and maybe other files.
3. Update further to Jaguar7.0 when we get the liscence.

> > On a related note, ADF2007.01 has been released. We have all the tests in
> > ADF2004.01 and should probably think about upgrading this also. I can
> > rerun them in 2006.01 or 2007.01 - so the question is whether we want to
> > update this soon and, if so, to which version?
>
> I would run them on both just to see if they fail the current tests,
> and whether we need to change the parser to deal with them. If you
> have access to 2007.01, then I see no reason not to include those
> tests as the latest ones.

In the works.

-Karol

-- 
written by Karol Langner
Mon Oct 29 12:42:51 EDT 2007

[cclib-devel] [ cclib-Bugs-1821996 ] Gaussian: can't parse if mult > 9

[SourceForge.net <no...@so...>]

Bugs item #1821996, was opened at 2007-10-29 09:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1821996&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian: can't parse if mult > 9

Initial Comment:
It's a trivial fix, but the parser fails if the multiplicity is 10 or greater. I've attached some test files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1821996&group_id=161285

Re: [cclib-devel] problem of parsing clusters with large spin multiplicity

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

Thanks for reporting this problem. I will fix this in cclib...

In the meanwhile, just change the line:
 Charge =3D  0 Multiplicity =3D18
to...
 Charge =3D  0 Multiplicity =3D 18
by adding a space after the equals sign. It should work then.

Noel

On 24/10/2007, su...@yo... <su...@yo...> wrote:
> Dear Mr. O=B4Boyle.
>
>  I am having problem with parsing the output G03 file of rh_13 clusters b=
y
> Gausssum, one of them is rh_13 with 2s+1=3D10, the other is Rh_13 with 2s=
+1=3D18, I
> attached the zipped output file and if you could take a look and give me =
some
> suggestion, I will greatly appreciate. Thank you for your help.
>
> All the best,
>
> Yan
>

Re: [cclib-devel] Upcoming cclib 0.8 final -- BUGS!

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

On 23/10/2007, Adam Tenderholt <a-t...@st...> wrote:
> So I updated the cda script that's installed with ccget to handle the
> ccData objects in trunk, and merged the change into the cclib-0.8
> branch. That fixes the only bug I'm aware of.

Great. There's a couple of failing tests on ADF, but some of these may
not be real failures (Karol introduced new tests which don't apply in
every case)...and frankly, although we'll continue to work on all
failures, I think that with each release we can be confident our
parsers are better, so we can tolerate 99% perfection. :-)

> Adam
>
> On Oct 22, 2007, at 12:06 PM, Noel O'Boyle wrote:
>
> > Regarding (1)... I had some problems (probably my fault) with getting
> > the whole setuptools stuff to work, so on the branch, I went back to
> > distutils. However, you need to delete the egg off your computer, as
> > "import cclib" will still use the egg, even though you install from
> > the branch.
> >
> > This is the only difference really between the trunk and the branch,
> > apart from some recent edits by Karol.
> >
> > Regarding (2)...I need to check this...
> >
> > Noel
> >
> > On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
> >> So I've found a couple of problems:
> >>
> >> 1) The setup.py in the cclib-0.8 branch doesn't create an egg. If you
> >> remove all cclib references from your python installation, and re-run
> >> python setup.py install from the cclib-0.8 branch, it installs fine.
> >> However, when you run the cda script using the Gaussian test files,
> >> you get the following error:
> >>
> >> Traceback (most recent call last):
> >>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
> >> cda", line 4, in ?
> >>      import pkg_resources
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> >> line 2561, in ?
> >>      working_set.require(__requires__)
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> >> line 626, in require
> >>      needed = self.resolve(parse_requirements(requirements))
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> >> line 524, in resolve
> >>      raise DistributionNotFound(req)  # XXX put more info here
> >> pkg_resources.DistributionNotFound: cclib==0.8b
> >>
> >> Installing from trunk "fixes" this error.
> >>
> >> 2) The next problem is that CDA is broken. Doing so gives the
> >> following error:
> >>
> >> Traceback (most recent call last):
> >>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
> >> cda", line 5, in ?
> >>      pkg_resources.run_script('cclib==0.8b', 'cda')
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> >> line 448, in run_script
> >>      self.require(requires)[0].run_script(script_name, ns)
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> >> line 1166, in run_script
> >>      execfile(script_filename, namespace, namespace)
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/cclib-0.8b-py2.4.egg/EGG-INFO/scripts/cda",
> >> line 22, in ?
> >>      retval = fa.calculate([parser2, parser3])
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/cda.py",
> >> line 39, in calculate
> >>      retval = super(CDA, self).calculate(fragments, cupdate)
> >>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> >> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/
> >> fragments.py", line 40, in calculate
> >>      unrestricted = ( len(self.data.mocoeffs) == 2 )
> >> AttributeError: 'Gaussian' object has no attribute 'mocoeffs'
> >>
> >> I was looking into this problem and decided to reinstall with
> >> cclib-0.8, which gave me the first error.
> >>
> >> Adam
> >>
> >>
> >> On Oct 21, 2007, at 11:08 AM, Noel O'Boyle wrote:
> >>
> >>> Since there have been no reported problems with the beta, I'm
> >>> going to
> >>> push out a cclib 0.8 final hopefully by the end of the week. I've
> >>> updated the website as much as possible - again, it would be
> >>> useful if
> >>> you could have a look.
> >>>
> >>> Don't let this stop development on the trunk, in case you're
> >>> waiting.
> >>> I'll merge the orca branch to trunk as soon as possible too.
> >>>
> >>> Noel
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> ---
> >>> This SF.net email is sponsored by: Splunk Inc.
> >>> Still grepping through log files to find problems?  Stop.
> >>> Now Search log events and configuration files using AJAX and a
> >>> browser.
> >>> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >>> _______________________________________________
> >>> cclib-devel mailing list
> >>> ccl...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >>
> >>
>
>

Re: [cclib-devel] Upcoming cclib 0.8 final -- BUGS!

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

So I updated the cda script that's installed with ccget to handle the  
ccData objects in trunk, and merged the change into the cclib-0.8  
branch. That fixes the only bug I'm aware of.

Adam

On Oct 22, 2007, at 12:06 PM, Noel O'Boyle wrote:

> Regarding (1)... I had some problems (probably my fault) with getting
> the whole setuptools stuff to work, so on the branch, I went back to
> distutils. However, you need to delete the egg off your computer, as
> "import cclib" will still use the egg, even though you install from
> the branch.
>
> This is the only difference really between the trunk and the branch,
> apart from some recent edits by Karol.
>
> Regarding (2)...I need to check this...
>
> Noel
>
> On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
>> So I've found a couple of problems:
>>
>> 1) The setup.py in the cclib-0.8 branch doesn't create an egg. If you
>> remove all cclib references from your python installation, and re-run
>> python setup.py install from the cclib-0.8 branch, it installs fine.
>> However, when you run the cda script using the Gaussian test files,
>> you get the following error:
>>
>> Traceback (most recent call last):
>>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
>> cda", line 4, in ?
>>      import pkg_resources
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 2561, in ?
>>      working_set.require(__requires__)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 626, in require
>>      needed = self.resolve(parse_requirements(requirements))
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 524, in resolve
>>      raise DistributionNotFound(req)  # XXX put more info here
>> pkg_resources.DistributionNotFound: cclib==0.8b
>>
>> Installing from trunk "fixes" this error.
>>
>> 2) The next problem is that CDA is broken. Doing so gives the
>> following error:
>>
>> Traceback (most recent call last):
>>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
>> cda", line 5, in ?
>>      pkg_resources.run_script('cclib==0.8b', 'cda')
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 448, in run_script
>>      self.require(requires)[0].run_script(script_name, ns)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 1166, in run_script
>>      execfile(script_filename, namespace, namespace)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/EGG-INFO/scripts/cda",
>> line 22, in ?
>>      retval = fa.calculate([parser2, parser3])
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/cda.py",
>> line 39, in calculate
>>      retval = super(CDA, self).calculate(fragments, cupdate)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/
>> fragments.py", line 40, in calculate
>>      unrestricted = ( len(self.data.mocoeffs) == 2 )
>> AttributeError: 'Gaussian' object has no attribute 'mocoeffs'
>>
>> I was looking into this problem and decided to reinstall with
>> cclib-0.8, which gave me the first error.
>>
>> Adam
>>
>>
>> On Oct 21, 2007, at 11:08 AM, Noel O'Boyle wrote:
>>
>>> Since there have been no reported problems with the beta, I'm  
>>> going to
>>> push out a cclib 0.8 final hopefully by the end of the week. I've
>>> updated the website as much as possible - again, it would be  
>>> useful if
>>> you could have a look.
>>>
>>> Don't let this stop development on the trunk, in case you're  
>>> waiting.
>>> I'll merge the orca branch to trunk as soon as possible too.
>>>
>>> Noel
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> cclib-devel mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>>

Re: [cclib-devel] Merging ORCA

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

I've done the merge. Possibly buggy, as I haven't tested as I don't
want to install again from the trunk until the release is sorted
out...

On 22/10/2007, Noel O'Boyle <bao...@gm...> wrote:
> On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
> > Is there a reason it should be a copy instead of another merge?
> I started doing the merge (--bidirectional according to the
> svnmerge.py docs) but then I realised that you had already done it for
> me, and sorted out all of the conflicts.
>
> > Is
> > copy smart enough to know when two files are the same, or does it
> > overwrite duplicates anyway?
>
> I know that I'm not smart enough to know the answer. But I think that
> the end result is the same. I guess I'll go ahead with the merge if it
> doesn't seem to make sense.
>
> BTW, I've just been to see Jorge Cham of Piled Higher and Deeper. Very
> funny guy.
>
> Noel
>
> > Adam
> >
> > On Oct 22, 2007, at 1:36 AM, Noel O'Boyle wrote:
> >
> > > Hi Adam,
> > >
> > > Can you just "svn cp" the ORCA branch onto the trunk, now that you've
> > > just done that merge?
> > >
> > > Noel
> >
> >
>

Re: [cclib-devel] Upcoming cclib 0.8 final -- BUGS!

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

I had removed the egg and all instances of cclib, although it looks  
like the install script doesn't overwrite already existing files (cda  
and ccget).

I also committed a fix for CDA. Hopefully it works for you as well,

Adam

On Oct 22, 2007, at 12:06 PM, Noel O'Boyle wrote:

> Regarding (1)... I had some problems (probably my fault) with getting
> the whole setuptools stuff to work, so on the branch, I went back to
> distutils. However, you need to delete the egg off your computer, as
> "import cclib" will still use the egg, even though you install from
> the branch.
>
> This is the only difference really between the trunk and the branch,
> apart from some recent edits by Karol.
>
> Regarding (2)...I need to check this...
>
> Noel
>
> On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
>> So I've found a couple of problems:
>>
>> 1) The setup.py in the cclib-0.8 branch doesn't create an egg. If you
>> remove all cclib references from your python installation, and re-run
>> python setup.py install from the cclib-0.8 branch, it installs fine.
>> However, when you run the cda script using the Gaussian test files,
>> you get the following error:
>>
>> Traceback (most recent call last):
>>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
>> cda", line 4, in ?
>>      import pkg_resources
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 2561, in ?
>>      working_set.require(__requires__)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 626, in require
>>      needed = self.resolve(parse_requirements(requirements))
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 524, in resolve
>>      raise DistributionNotFound(req)  # XXX put more info here
>> pkg_resources.DistributionNotFound: cclib==0.8b
>>
>> Installing from trunk "fixes" this error.
>>
>> 2) The next problem is that CDA is broken. Doing so gives the
>> following error:
>>
>> Traceback (most recent call last):
>>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
>> cda", line 5, in ?
>>      pkg_resources.run_script('cclib==0.8b', 'cda')
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 448, in run_script
>>      self.require(requires)[0].run_script(script_name, ns)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
>> line 1166, in run_script
>>      execfile(script_filename, namespace, namespace)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/EGG-INFO/scripts/cda",
>> line 22, in ?
>>      retval = fa.calculate([parser2, parser3])
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/cda.py",
>> line 39, in calculate
>>      retval = super(CDA, self).calculate(fragments, cupdate)
>>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
>> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/
>> fragments.py", line 40, in calculate
>>      unrestricted = ( len(self.data.mocoeffs) == 2 )
>> AttributeError: 'Gaussian' object has no attribute 'mocoeffs'
>>
>> I was looking into this problem and decided to reinstall with
>> cclib-0.8, which gave me the first error.
>>
>> Adam
>>
>>
>> On Oct 21, 2007, at 11:08 AM, Noel O'Boyle wrote:
>>
>>> Since there have been no reported problems with the beta, I'm  
>>> going to
>>> push out a cclib 0.8 final hopefully by the end of the week. I've
>>> updated the website as much as possible - again, it would be  
>>> useful if
>>> you could have a look.
>>>
>>> Don't let this stop development on the trunk, in case you're  
>>> waiting.
>>> I'll merge the orca branch to trunk as soon as possible too.
>>>
>>> Noel
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a
>>> browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> cclib-devel mailing list
>>> ccl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>>
>>

Re: [cclib-devel] Upcoming cclib 0.8 final -- BUGS!

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

Regarding (1)... I had some problems (probably my fault) with getting
the whole setuptools stuff to work, so on the branch, I went back to
distutils. However, you need to delete the egg off your computer, as
"import cclib" will still use the egg, even though you install from
the branch.

This is the only difference really between the trunk and the branch,
apart from some recent edits by Karol.

Regarding (2)...I need to check this...

Noel

On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
> So I've found a couple of problems:
>
> 1) The setup.py in the cclib-0.8 branch doesn't create an egg. If you
> remove all cclib references from your python installation, and re-run
> python setup.py install from the cclib-0.8 branch, it installs fine.
> However, when you run the cda script using the Gaussian test files,
> you get the following error:
>
> Traceback (most recent call last):
>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
> cda", line 4, in ?
>      import pkg_resources
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> line 2561, in ?
>      working_set.require(__requires__)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> line 626, in require
>      needed = self.resolve(parse_requirements(requirements))
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> line 524, in resolve
>      raise DistributionNotFound(req)  # XXX put more info here
> pkg_resources.DistributionNotFound: cclib==0.8b
>
> Installing from trunk "fixes" this error.
>
> 2) The next problem is that CDA is broken. Doing so gives the
> following error:
>
> Traceback (most recent call last):
>    File "/Library/Frameworks/Python.framework/Versions/Current/bin/
> cda", line 5, in ?
>      pkg_resources.run_script('cclib==0.8b', 'cda')
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> line 448, in run_script
>      self.require(requires)[0].run_script(script_name, ns)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",
> line 1166, in run_script
>      execfile(script_filename, namespace, namespace)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib-0.8b-py2.4.egg/EGG-INFO/scripts/cda",
> line 22, in ?
>      retval = fa.calculate([parser2, parser3])
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/cda.py",
> line 39, in calculate
>      retval = super(CDA, self).calculate(fragments, cupdate)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/
> fragments.py", line 40, in calculate
>      unrestricted = ( len(self.data.mocoeffs) == 2 )
> AttributeError: 'Gaussian' object has no attribute 'mocoeffs'
>
> I was looking into this problem and decided to reinstall with
> cclib-0.8, which gave me the first error.
>
> Adam
>
>
> On Oct 21, 2007, at 11:08 AM, Noel O'Boyle wrote:
>
> > Since there have been no reported problems with the beta, I'm going to
> > push out a cclib 0.8 final hopefully by the end of the week. I've
> > updated the website as much as possible - again, it would be useful if
> > you could have a look.
> >
> > Don't let this stop development on the trunk, in case you're waiting.
> > I'll merge the orca branch to trunk as soon as possible too.
> >
> > Noel
> >
> > ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Re: [cclib-devel] Merging ORCA

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

On 22/10/2007, Adam Tenderholt <a-t...@st...> wrote:
> Is there a reason it should be a copy instead of another merge?
I started doing the merge (--bidirectional according to the
svnmerge.py docs) but then I realised that you had already done it for
me, and sorted out all of the conflicts.

> Is
> copy smart enough to know when two files are the same, or does it
> overwrite duplicates anyway?

I know that I'm not smart enough to know the answer. But I think that
the end result is the same. I guess I'll go ahead with the merge if it
doesn't seem to make sense.

BTW, I've just been to see Jorge Cham of Piled Higher and Deeper. Very
funny guy.

Noel

> Adam
>
> On Oct 22, 2007, at 1:36 AM, Noel O'Boyle wrote:
>
> > Hi Adam,
> >
> > Can you just "svn cp" the ORCA branch onto the trunk, now that you've
> > just done that merge?
> >
> > Noel
>
>

Re: [cclib-devel] Upcoming cclib 0.8 final -- BUGS!

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

So I've found a couple of problems:

1) The setup.py in the cclib-0.8 branch doesn't create an egg. If you  
remove all cclib references from your python installation, and re-run  
python setup.py install from the cclib-0.8 branch, it installs fine.  
However, when you run the cda script using the Gaussian test files,  
you get the following error:

Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/Current/bin/ 
cda", line 4, in ?
     import pkg_resources
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",  
line 2561, in ?
     working_set.require(__requires__)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",  
line 626, in require
     needed = self.resolve(parse_requirements(requirements))
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",  
line 524, in resolve
     raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: cclib==0.8b

Installing from trunk "fixes" this error.

2) The next problem is that CDA is broken. Doing so gives the  
following error:

Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/Current/bin/ 
cda", line 5, in ?
     pkg_resources.run_script('cclib==0.8b', 'cda')
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",  
line 448, in run_script
     self.require(requires)[0].run_script(script_name, ns)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/setuptools-0.6c6-py2.4.egg/pkg_resources.py",  
line 1166, in run_script
     execfile(script_filename, namespace, namespace)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/cclib-0.8b-py2.4.egg/EGG-INFO/scripts/cda",  
line 22, in ?
     retval = fa.calculate([parser2, parser3])
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/cda.py",  
line 39, in calculate
     retval = super(CDA, self).calculate(fragments, cupdate)
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/cclib-0.8b-py2.4.egg/cclib/method/ 
fragments.py", line 40, in calculate
     unrestricted = ( len(self.data.mocoeffs) == 2 )
AttributeError: 'Gaussian' object has no attribute 'mocoeffs'

I was looking into this problem and decided to reinstall with  
cclib-0.8, which gave me the first error.

Adam


On Oct 21, 2007, at 11:08 AM, Noel O'Boyle wrote:

> Since there have been no reported problems with the beta, I'm going to
> push out a cclib 0.8 final hopefully by the end of the week. I've
> updated the website as much as possible - again, it would be useful if
> you could have a look.
>
> Don't let this stop development on the trunk, in case you're waiting.
> I'll merge the orca branch to trunk as soon as possible too.
>
> Noel
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Merging ORCA

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

Is there a reason it should be a copy instead of another merge? Is  
copy smart enough to know when two files are the same, or does it  
overwrite duplicates anyway?

Adam

On Oct 22, 2007, at 1:36 AM, Noel O'Boyle wrote:

> Hi Adam,
>
> Can you just "svn cp" the ORCA branch onto the trunk, now that you've
> just done that merge?
>
> Noel

[cclib-devel] Merging ORCA

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

Hi Adam,

Can you just "svn cp" the ORCA branch onto the trunk, now that you've
just done that merge?

Noel

[cclib-devel] Upcoming cclib 0.8 final

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

Since there have been no reported problems with the beta, I'm going to
push out a cclib 0.8 final hopefully by the end of the week. I've
updated the website as much as possible - again, it would be useful if
you could have a look.

Don't let this stop development on the trunk, in case you're waiting.
I'll merge the orca branch to trunk as soon as possible too.

Noel

Re: [cclib-devel] Jaguar data files

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

On 19/10/2007, Karol Langner <kar...@kn...> wrote:
> On Saturday 13 October 2007 08:37, Noel O'Boyle wrote:
> > On 13/10/2007, Karol Langner <kar...@kn...> wrote:
> > > > > Let me start things up again with a
> > > > > simple issue - why do we have three different basicJaguar*
> > > > > directories in trunk/data/? It seems logical to use data files for
> > > > > unittests only from the newest Jaguar version and to change the rest
> > > > > to regressions. That is the situation for Gaussian and ADF (although
> > > > > here basicADF2004 is not the newest version). Why should Jaguar be an
> > > > > exception?
> > > >
> > > > If a newer version of Gaussian comes out or if we have access to a
> > > > newer version of ADF, Jaguar won't be the exception. I'm not sure what
> > > > you mean by changing the unittests to regressions. If we support
> > > > JaguarX, then we should have unittests to ensure this.
> > >
> > > There are probably more people using Gaussian98 than there are using
> > > Jaguar4.2, so I don't see why we should only support older version of
> > > Jaguar and not Gaussian.
> >
> > There's no reason. We just started supporting whatever programs we had
> > access to.
>
> Of course, and access changes and versions become old. The data files packaged
> along with cclib should reflect the current state of our access to the newest
> program versions.

That's fine by me.

> > > I was referring to data files rather than unittests, of course. What I
> > > mean be 'changing the unittests to regressions' is not distributing the
> > > older data files with cclib anymore and adding them to the family of
> > > regression tests.
> > >
> > > I think it is sufficient and more efficient to have a good set of test
> > > log files only for the newest available version of all the programs, and
> > > to support all older versions with appropriate regression tests (works
> > > fine for Gaussian, GAMESS, ADF).
> >
> > Right, okay - now I understand. Yes - that's fine by me. Probably the
> > easiest way to do this is simply to have the testall.py script (or
> > whatever) only run the tests if the test file exists. At the same
> > time, I can change manifest.py (or MANIFEST.in if we can make this
> > work in future) so that it only includes the latest files for each.
>
> The appropriate tests can be imported and run by regression.py to make them
> truly regressions.

Right.

> > > > The historical reason we have unittests for different versions of
> > > > Jaguar is that my colleagues in Cambridge were using Jag4.2 (or so),
> > > > Adam's colleagues were using 6.?, and finally we got the latest Jaguar
> > > > 6.5 (which is now superseded by Jag 7.0 - maybe we should ask for
> > > > this).
> > >
> > > This is redundant, since then we will have as many basicJaguar*
> > > directories as there are Jaguar versions being used. Already, the
> > > Jaguar4.2 and Jaguar6.0 tests are "behind" Jaguar6.5 since we don't have
> > > easy access to them.
> > >
> > > Notice also that the Jaguar6.0 data files take up alot more space than
> > > the Jaguar6.5 ones. I would prefer to see a complete set of log files for
> > > Jaguar6.5 and everything else put in directories that can be downloaded
> > > as regressions (so we can still check if they are parsed and pass the
> > > tests we want).
> >
> > Yes - I think we agree.
>
> Is that a green light for doing this? Probably after the release, anyway.

Yes - it is. :-) I have realised that I have become too
conservative...I will talk about this after the final release.

> As you mentioned, Jaguar7.0 is out. Now would be a good time to update the
> installation, which by the way has changed (the machine it was on is dead...
> there is a new one now) so I need to write about that later.
>
> On a related note, ADF2007.01 has been released. We have all the tests in
> ADF2004.01 and should probably think about upgrading this also. I can rerun
> them in 2006.01 or 2007.01 - so the question is whether we want to update
> this soon and, if so, to which version?

I would run them on both just to see if they fail the current tests,
and whether we need to change the parser to deal with them. If you
have access to 2007.01, then I see no reason not to include those
tests as the latest ones.

> Karol
>
> --
> written by Karol Langner
> Fri Oct 19 01:04:14 EDT 2007
>

Re: [cclib-devel] Jaguar data files

[Karol L. <kar...@kn...>]

On Saturday 13 October 2007 08:37, Noel O'Boyle wrote:
> On 13/10/2007, Karol Langner <kar...@kn...> wrote:
> > > > Let me start things up again with a
> > > > simple issue - why do we have three different basicJaguar*
> > > > directories in trunk/data/? It seems logical to use data files for
> > > > unittests only from the newest Jaguar version and to change the rest
> > > > to regressions. That is the situation for Gaussian and ADF (although
> > > > here basicADF2004 is not the newest version). Why should Jaguar be an
> > > > exception?
> > >
> > > If a newer version of Gaussian comes out or if we have access to a
> > > newer version of ADF, Jaguar won't be the exception. I'm not sure what
> > > you mean by changing the unittests to regressions. If we support
> > > JaguarX, then we should have unittests to ensure this.
> >
> > There are probably more people using Gaussian98 than there are using
> > Jaguar4.2, so I don't see why we should only support older version of
> > Jaguar and not Gaussian.
>
> There's no reason. We just started supporting whatever programs we had
> access to.

Of course, and access changes and versions become old. The data files packaged 
along with cclib should reflect the current state of our access to the newest 
program versions.

> > I was referring to data files rather than unittests, of course. What I
> > mean be 'changing the unittests to regressions' is not distributing the
> > older data files with cclib anymore and adding them to the family of
> > regression tests.
> >
> > I think it is sufficient and more efficient to have a good set of test
> > log files only for the newest available version of all the programs, and
> > to support all older versions with appropriate regression tests (works
> > fine for Gaussian, GAMESS, ADF).
>
> Right, okay - now I understand. Yes - that's fine by me. Probably the
> easiest way to do this is simply to have the testall.py script (or
> whatever) only run the tests if the test file exists. At the same
> time, I can change manifest.py (or MANIFEST.in if we can make this
> work in future) so that it only includes the latest files for each.

The appropriate tests can be imported and run by regression.py to make them 
truly regressions.

> > > The historical reason we have unittests for different versions of
> > > Jaguar is that my colleagues in Cambridge were using Jag4.2 (or so),
> > > Adam's colleagues were using 6.?, and finally we got the latest Jaguar
> > > 6.5 (which is now superseded by Jag 7.0 - maybe we should ask for
> > > this).
> >
> > This is redundant, since then we will have as many basicJaguar*
> > directories as there are Jaguar versions being used. Already, the
> > Jaguar4.2 and Jaguar6.0 tests are "behind" Jaguar6.5 since we don't have
> > easy access to them.
> >
> > Notice also that the Jaguar6.0 data files take up alot more space than
> > the Jaguar6.5 ones. I would prefer to see a complete set of log files for
> > Jaguar6.5 and everything else put in directories that can be downloaded
> > as regressions (so we can still check if they are parsed and pass the
> > tests we want).
>
> Yes - I think we agree.

Is that a green light for doing this? Probably after the release, anyway.

As you mentioned, Jaguar7.0 is out. Now would be a good time to update the 
installation, which by the way has changed (the machine it was on is dead... 
there is a new one now) so I need to write about that later.

On a related note, ADF2007.01 has been released. We have all the tests in 
ADF2004.01 and should probably think about upgrading this also. I can rerun 
them in 2006.01 or 2007.01 - so the question is whether we want to update 
this soon and, if so, to which version?

Karol

-- 
written by Karol Langner
Fri Oct 19 01:04:14 EDT 2007

Re: [cclib-devel] Jaguar data files

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

On 13/10/2007, Karol Langner <kar...@kn...> wrote:
> On Friday 12 October 2007 03:07, you wrote:
> > On 12/10/2007, Karol Langner <kar...@kn...> wrote:
> > > Hi all,
> > >
> > >  It's been fairly quiet for some time now.
> >
> > I'm going to get out a release (beta?) of cclib 0.8 this weekend.
> > Would appreciate any relevant updates to the Changelog...
> I added as much as I could find after looking through the logs yesterday.

That's great. I made some minor edits but it looks pretty comprehensive now.

> > > Let me start things up again with a
> > > simple issue - why do we have three different basicJaguar* directories in
> > > trunk/data/? It seems logical to use data files for unittests only from
> > > the newest Jaguar version and to change the rest to regressions. That is
> > > the situation for Gaussian and ADF (although here basicADF2004 is not the
> > > newest version). Why should Jaguar be an exception?
> >
> > If a newer version of Gaussian comes out or if we have access to a
> > newer version of ADF, Jaguar won't be the exception. I'm not sure what
> > you mean by changing the unittests to regressions. If we support
> > JaguarX, then we should have unittests to ensure this.
> There are probably more people using Gaussian98 than there are using
> Jaguar4.2, so I don't see why we should only support older version of Jaguar
> and not Gaussian.

There's no reason. We just started supporting whatever programs we had
access to.

> I was referring to data files rather than unittests, of course. What I mean
> be 'changing the unittests to regressions' is not distributing the older data
> files with cclib anymore and adding them to the family of regression tests.
>
> I think it is sufficient and more efficient to have a good set of test log
> files only for the newest available version of all the programs, and to
> support all older versions with appropriate regression tests (works fine for
> Gaussian, GAMESS, ADF).

Right, okay - now I understand. Yes - that's fine by me. Probably the
easiest way to do this is simply to have the testall.py script (or
whatever) only run the tests if the test file exists. At the same
time, I can change manifest.py (or MANIFEST.in if we can make this
work in future) so that it only includes the latest files for each.

> > The historical reason we have unittests for different versions of
> > Jaguar is that my colleagues in Cambridge were using Jag4.2 (or so),
> > Adam's colleagues were using 6.?, and finally we got the latest Jaguar
> > 6.5 (which is now superseded by Jag 7.0 - maybe we should ask for
> > this).
> This is redundant, since then we will have as many basicJaguar* directories as
> there are Jaguar versions being used. Already, the Jaguar4.2 and Jaguar6.0
> tests are "behind" Jaguar6.5 since we don't have easy access to them.
>
> Notice also that the Jaguar6.0 data files take up alot more space than the
> Jaguar6.5 ones. I would prefer to see a complete set of log files for
> Jaguar6.5 and everything else put in directories that can be downloaded as
> regressions (so we can still check if they are parsed and pass the tests we
> want).

Yes - I think we agree.

> Karol
>
> --
> written by Karol Langner
> Fri Oct 12 20:12:49 EDT 2007
>

[cclib-devel] A belated release

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

So, I've finally gotten the release out. It's a beta release, but it
should be a lot easier getting out the final release.

I've updated a good few wiki pages. I'd appreciate if you could look
through a few yourselves and change or add anything you think is
appropriate...

Noel