Students in 6.170 are required to submit the implementation parts of their problem sets electronically. The implementation is then run against a test suite to check its correctness. Since this part of problem set grading is run automatically, it is vital that students submit their implementations in the form expected by the 6.170 autograder. We have provided these tools to make this task straightforward:
Validation ensures that a student's implementation:
validate6170 is called from the Athena command line and takes these options:
validate6170 [options] psN; psN is one of 'ps1', 'ps2', ... options: --printstack : include stack traces in test output --output filename : send test output to named file
validate6170 expects to find all the required files for psN in the directory ~/6.170/psN.
The file ~/6.170/psN/Manifest lists the files that should be included with the student's submission. In the Manifest, each file is listed on a separate line. validate6170 will complain if there are files in the manifest that are not in the psN directory or if there are files required for psN that are not in the manifest.
In addition to their code files, a student can submit files containing text and diagrams as answers to certain problem set questions. These additional files must be listed in the manifest or else they will not be included in the student's submission. Each problem set will include a default Manifest file that lists the basic files expected in the submission; students should add entries to the manifest for any additional code or text files they with to submit.
For example, let's say a problem set contains the file Foo.java and the default Mainfest file only contains an entry for that file. If the student adds a helper class called Bar.java and supplies an answer to problem 3 in problem3.txt, the final Manifest should look like this:
Foo.java Bar.java problem3.txt
Note that the order of the file names is not important.
If validate6170 succeeds in checking the implementation, the output looks like this:
validate6170: Validating ps1, please be patient... validate6170: This script compiles all of your code from scratch, and then runs validate6170: a test suite. This process may take a while for larger psets. validate6170: Success: your solution passed validation.
If for some reason validate6170 fails, it will print out an error message. If the student's implementation compiles but fails some tests, validate6170 will print out the name of the test and a description of the falure. The student can use this output, along with the provided test suites, to debug their code.
validate6170 provides options for handling test output:
validate6170 (and returnin6170) may not operate correctly if you have .java files that define multiple classes. As a matter of style, it is best to put each class (public or private) in its own class, and that will also avoid this potential problem with returnin. The jikes compiler will issue a warning if you define multiple classes in a single file.
turnin6170 packages a student's problem set files for submission. It is called from the Athena command line and takes only the problem set name as an argument:
turnin6170 psN
psN is one of ps1, ps2, etc.
The files specified in the student's ~/6.170/psN/Manifest are packaged, zipped, and stored in the file ~/6.170/psN-turnin.tar.gz. When psN is due, the TAs copy each student's turnin package and use their contents for autograding. Students should be sure to use validate6170 to check their problem set before turning it in.
Update: For Problem Sets 4 and 6, you need to use (and possibly edit) classes you wrote in previous problem sets. Please just use or edit those files in place; turnin6170 will package everything. i.e.: When you run turnin6170 ps4, all files specified in the Manifest files for problem sets 2, 3, and 4 will be packaged into ~/6.170/ps4-turnin.tar.gz. For problem set 6, all files specified in the Manifest files for problem sets 2, 3, 4, and 6 will be packaged.
The returnin command tests that your implementation is correct; it does not check your specifications or documentation, though getting those right is likely to help you produce error-free code.
To use returnin, first correct and test your code on your own. Then, run validate6170 to ensure that your code can be compiled by our system and that it minimally meets our specifications. Finally, run the returnin6170 comand to submit your work to our autograder.
validate6170 psN returnin6170 psN
The returnin6170 command is analagous to the turnin6170 command. It creates a psN-returnin.tar.gz file. A reaper program will pick up this file, build it, and test it; you will receive a response with success or failure via email, usually within half an hour. If you do not receive a success/failure report within an hour, please send mail to 6.170-autograder@mit.edu describing the problem.
Returnin is worth 25 points on each of problem sets 1-4. You have three free tries to run returnin; if any of your first three tries succeed, you get full credit. Otherwise, you lose five points for each returnin run beyond the third. (Your fourth attempt, if successful, earns you 20 points out of 25, your fifth earns you 15, and so on.)