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