cclib-devel

[cclib-devel] Test files

[Noel O'B. <no...@ca...>]

I've just been doing some tidying up of the tests. I've removed the
so-called wild folders, and used our new Googlemail system instead. Here
are some proposed guidelines for dealing with new problem output files:

(0) Give it a unique name (compared to others in the repository)
(1) gzip it
(2) Email it to ccl...@go... with the following info:
(a) What's the problem? "Breaks parser" is fine, if that's all that we
know already.
(b) What revision does it have a problem with.
(c) Where does the file come from, and confirm that it's public domain
[I think we only spoke briefly about this before, but I believe that we
need all test log files to be public domain...are you happy with this
for your log files?? I have already asked Joe Townsend, and the AOMIX
files are, by nature, public domain]
(d) Where will the file be stored in the repository (not sure is this
necessary)
(3) The log message of the revision that fixes the problem should refer
to the name of the problem log file (as well as the usual info).
(4) Login to googlemail and reply to the original problem with the name
of the revision that fixes it. This lets us know at a glance (on
googlemail) whether a particular log file is still a problem. (Although
we should also know this from regression.py)

Somewhere in all of this, preferably after (2), to add a regression test
to regression.py for the problem. This will let the other developer know
that there's a problem that needs to be fixed and also that they are
missing a test file in their local repository. I have already added some
broken parser tests for the 4 files in the test repository (haven't done
anything about that second ADF example of yours).

I will try to set up an automated procedure to make a .zip of all of the
data files in my local repository (excluding the basic ones), and send
it up to sourceforge. I think there are ways to do this, but it will
take some time.

I'll wikify these instructions if they sound reasonable - please let me
know any further ideas.

Oh yeah, could you send to google that Gaussian example you said there
was a problem with?

Regards,
 Noel

[cclib-devel] Test files

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

Just some housekeeping - some files were recently added to the
regression suite. Could you confirm that these files are public
domain?

Noel

Re: [cclib-devel] Test files

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

The WH6 files are public domain.

Adam

On May 21, 2008, at 11:58 PM, Noel O'Boyle wrote:

> Just some housekeeping - some files were recently added to the
> regression suite. Could you confirm that these files are public
> domain?
>
> Noel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Test files

[Karol M. L. <kar...@gm...>]

On Thursday 22 May 2008, Noel O'Boyle wrote:
> Just some housekeeping - some files were recently added to the
> regression suite. Could you confirm that these files are public
> domain?
>
> Noel

 I added ptnh3_2_H2O_2_2plus from Jaguar7.0 recently. I didn't notice 
it then, but the file was sent only to me by Jean-Didier, and he 
didn't specify whether it is public.

 So I'm CC-ing him this email - hopefully he will make it clear to us 
if we can consider the file public domain and use it as a test file.

Cheers,
Karol

-- 
written by Karol Langner
Fri May 23 00:09:37 CEST 2008

Re: [cclib-devel] Test files

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

> I've just been doing some tidying up of the tests. I've removed the
> so-called wild folders, and used our new Googlemail system instead.  
> Here
> are some proposed guidelines for dealing with new problem output  
> files:

Excellent

> (0) Give it a unique name (compared to others in the repository)
> (1) gzip it

Make sense. Sorry for not doing that to the first two I uploaded to  
gmail.

> (2) Email it to ccl...@go... with the following info:
> (a) What's the problem? "Breaks parser" is fine, if that's all that we
> know already.
> (b) What revision does it have a problem with.
> (c) Where does the file come from, and confirm that it's public domain
> [I think we only spoke briefly about this before, but I believe  
> that we
> need all test log files to be public domain...are you happy with this
> for your log files?? I have already asked Joe Townsend, and the AOMIX
> files are, by nature, public domain]
> (d) Where will the file be stored in the repository (not sure is this
> necessary)

I'm definitely ok making any broken log files I make be public domain.

> (3) The log message of the revision that fixes the problem should  
> refer
> to the name of the problem log file (as well as the usual info).
> (4) Login to googlemail and reply to the original problem with the  
> name
> of the revision that fixes it. This lets us know at a glance (on
> googlemail) whether a particular log file is still a problem.  
> (Although
> we should also know this from regression.py)

Sounds good. Should I still do that for the first logfile, or shall  
we just archive it?

> Somewhere in all of this, preferably after (2), to add a regression  
> test
> to regression.py for the problem. This will let the other developer  
> know
> that there's a problem that needs to be fixed and also that they are
> missing a test file in their local repository. I have already added  
> some
> broken parser tests for the 4 files in the test repository (haven't  
> done
> anything about that second ADF example of yours).

Ok. If it just "breaks" the parser, can the regression just test for  
completion of the parsing function?

> I will try to set up an automated procedure to make a .zip of all  
> of the
> data files in my local repository (excluding the basic ones), and send
> it up to sourceforge. I think there are ways to do this, but it will
> take some time.

Did you mean sourceforge? I thought the idea of using the gmail  
account was have a way to share large data files....

> I'll wikify these instructions if they sound reasonable - please  
> let me
> know any further ideas.
>
> Oh yeah, could you send to google that Gaussian example you said there
> was a problem with?

If I can find it again, yep. ;o)

Adam

Re: [cclib-devel] Test files

[Dr N. O'B. <no...@ca...>]

>> (2) Email it to ccl...@go... with the following info:
>> (a) What's the problem? "Breaks parser" is fine, if that's all that we
>> know already.
>> (b) What revision does it have a problem with.
>> (c) Where does the file come from, and confirm that it's public domain
>> [I think we only spoke briefly about this before, but I believe  
>> that we
>> need all test log files to be public domain...are you happy with this
>> for your log files?? I have already asked Joe Townsend, and the AOMIX
>> files are, by nature, public domain]
>> (d) Where will the file be stored in the repository (not sure is this
>> necessary)
>
>I'm definitely ok making any broken log files I make be public domain.
Great.

>> (3) The log message of the revision that fixes the problem should  
>> refer
>> to the name of the problem log file (as well as the usual info).
>> (4) Login to googlemail and reply to the original problem with the  
>> name
>> of the revision that fixes it. This lets us know at a glance (on
>> googlemail) whether a particular log file is still a problem.  
>> (Although
>> we should also know this from regression.py)
>
>Sounds good. Should I still do that for the first logfile, or shall  
>we just archive it?
Not sure what you mean by the first logfile.

>> Somewhere in all of this, preferably after (2), to add a regression  
>> test
>> to regression.py for the problem. This will let the other developer  
>> know
>> that there's a problem that needs to be fixed and also that they are
>> missing a test file in their local repository. I have already added  
>> some
>> broken parser tests for the 4 files in the test repository (haven't  
>> done
>> anything about that second ADF example of yours).
>
>Ok. If it just "breaks" the parser, can the regression just test for  
>completion of the parsing function?
Exactly. Let's keep it simple for these tests or we won't add tests as 
it'll be too much of a chore. If you look at what I've added already you'll 
see that the files that break the parsers are just parsed. For more 
complicated problems, we can be a bit more imaginative depending on the 
problem.

>> I will try to set up an automated procedure to make a .zip of all  
>> of the
>> data files in my local repository (excluding the basic ones), and send
>> it up to sourceforge. I think there are ways to do this, but it will
>> take some time.
>
>Did you mean sourceforge? I thought the idea of using the gmail  
>account was have a way to share large data files....
It is, but sourceforge also is functionning as a bug tracker in this 
instance. It's good to be able to download all of the test files at once, 
e.g. for a new developer or for someone who wants some test files for their 
own program (e.g. open babel might use these eventually).

In any case, I've discovered releaseforge.sourceforge.net which makes it a 
doodle to release files. So I just tar up everything and make a release 
every so often with the SVN revision name. Check out the SF download site 
in another 8 hours for the first release. You just unzip it at the 'top 
level' of the directory structure, and it makes all of the data folders for 
you (or overwrites them).

>> I'll wikify these instructions if they sound reasonable - please  
>> let me
>> know any further ideas.
>>
>> Oh yeah, could you send to google that Gaussian example you said there
>> was a problem with?
>
>If I can find it again, yep. ;o)
Great.
>Adam
>
>
> Using Tomcat but need to do more? Need to support web services, security? 
> Get stuff done quickly with pre-integrated technology to make your job 
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 
> _______________________________________________ cclib-devel mailing list 
> ccl...@li... 
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Re: [cclib-devel] Test files

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

>> Sounds good. Should I still do that for the first logfile, or  
>> shall  we just archive it?
> Not sure what you mean by the first logfile.

The first ADF logfile I emailed to the gmail account. I fixed the  
bug. Should I reply to my email there?

>> Did you mean sourceforge? I thought the idea of using the gmail   
>> account was have a way to share large data files....
> It is, but sourceforge also is functionning as a bug tracker in  
> this instance. It's good to be able to download all of the test  
> files at once, e.g. for a new developer or for someone who wants  
> some test files for their own program (e.g. open babel might use  
> these eventually).
>
> In any case, I've discovered releaseforge.sourceforge.net which  
> makes it a doodle to release files. So I just tar up everything and  
> make a release every so often with the SVN revision name. Check out  
> the SF download site in another 8 hours for the first release. You  
> just unzip it at the 'top level' of the directory structure, and it  
> makes all of the data folders for you (or overwrites them).

Ok.

Adam

Re: [cclib-devel] Test files

[Noel O'B. <no...@ca...>]

On Tue, 2006-06-27 at 10:16 -0700, Adam Tenderholt wrote:
> >> Sounds good. Should I still do that for the first logfile, or  
> >> shall  we just archive it?
> > Not sure what you mean by the first logfile.
> 
> The first ADF logfile I emailed to the gmail account. I fixed the  
> bug. Should I reply to my email there?

I think so. Just a line to say it's fixed in whatever revision. Does
this system make sense?

SF has a bug tracker, and an alternative system would be to send the log
files to the gmail account but log a bug in the bug tracker. This has a
system for adding comments and marking bugs as closed and so on. The
original poster gets notified of any changes in the bug status, and an
email gets sent to the developers list simultaneously. Also, every bug
has a number. Our SF ranking would increase and in addition, users can
see that we have a system for dealing with bugs, which is pretty
transparent. The downside is a slight overhead.

> >> Did you mean sourceforge? I thought the idea of using the gmail   
> >> account was have a way to share large data files....
> > It is, but sourceforge also is functionning as a bug tracker in  
> > this instance. It's good to be able to download all of the test  
> > files at once, e.g. for a new developer or for someone who wants  
> > some test files for their own program (e.g. open babel might use  
> > these eventually).
> >
> > In any case, I've discovered releaseforge.sourceforge.net which  
> > makes it a doodle to release files. So I just tar up everything and  
> > make a release every so often with the SVN revision name. Check out  
> > the SF download site in another 8 hours for the first release. You  
> > just unzip it at the 'top level' of the directory structure, and it  
> > makes all of the data folders for you (or overwrites them).
> 
> Ok.
Really - it's no problem. And I meant to say doddle not doodle. :-)

> Adam
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel