Contents:
Students in CSE331 are required to submit the implementation parts of their problem sets electronically. Many problem sets have two submission phases: the first is the original problem set submission (due by the date listed at the top of the problem set), and the the second is a "returnin" submission, which gives you a second chance to improve your graded original submission.
We collect your assignments from your SVN repository. Thus, you must commit your files to SVN. For the original submission, this is sufficient. However, the validate step is highly recommended.
For problem sets 1-4, you are required to resbumit your implementation after getting feedback from your TA. To resubmit your implementation for returnin, run the returnin331 script after committing your files to SVN. The returnin331 script tells the CSE331 autograder to check out your problem set, run the test suite, and email the results to you.
Validating your code checks it for common errors, such as your code not compiling correctly on CSE331. Such errors could prevent you from recieving credit for your code, so you should always validate your problem set before you complete it (and before you run returnin331). However, validation is not guaranteed to catch all errors in your code.
You should validate your problem set by running ant validate. This checks out a fresh copy of your code (to a temporary directory) and ensures that your implementation:
If the validate output indicates errors, you should fix them before the deadline, or you will lose points on your problem set. If validate failed because the public test suite failed, you can view a summary of the JUnit failures in your YourWorkspaceDir/scratch/cse331/src/psN/test/reports directory.
Important: be aware that the validation script tests your code against your own test suite. Although by default we populate psN.test.SpecificationTests with the public test suite, it is your responsibility to retain those tests in psN.test.SpecificationTests if you want the validatation script to check your code against the public tests.
ant validate only works on attu (All other ant targets that the staff supplied should work both in the Allen Center software labs and on your home computer). For example, if you use the command line, you would type
cd ~/cse331/src/psN/ ant validate
though similar commands should also work from Eclipse.
The returnin331 program allows students to resubmit code for a problem set; it automatically grades your resubmission and gives you feedback. 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, commit your code to your SVN repository and run both ant clean total.build and ant validate to ensure that your code can be compiled by our system and meets some minimal requirements (you don't want to use up one of your returnin tries due to a silly error!). Note: in order to pass returnin, all of your psets must build, even the ones that are newer than the one you are returning in! While we do only run tests on the given pset, all of your psets must compile; the total.build command above will ensure that. Finally, from your workspace directory, run
/cse/courses/cse331/11wi/bin/returnin331 psN
to submit your work to our autograder. You will receive an email message indicating success or failure, usually within half an hour. If you do not receive a success/failure report within an hour, please send mail to cs331-staff@cs.washington.edu describing the problem.
If a student's implementation fails the staff test suite, the student can fix the code and resubmit a certain number of times without penalty. The student receives an email with the result of the resubmission. See the General Information handout for details about the requirements for, and rewards from, using returnin.
Returnin is worth 25% of the problem sets to which it applies. You have three free tries to run returnin and seven tries total. If any of your first three tries succeeds, you get full credit. Otherwise, you lose 5% 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.) (Not all problem set grades add up to 100; for example, if returnin is worth 45 points, then you lose 9 each time.) If you do not pass on your seventh try, you will get no credit.
If you fail any test, you will receive only very limited feedback from returnin331 — typically the name of the staff test that failed, and one line indicating an expected and actual result, or the message from an exception. You will not receive a full stack trace, nor the actual test case.
Oftentimes, the information you receive is plenty to help you reproduce, understand, and correct the defect in your program. If the information you receive is not sufficient, then you should use reasoning, defensive programming, and testing to prevent errors or make them more debuggable. The purpose of returnin is to reward students who are doing their work systematically and carefully, and to help the other students to learn to work in that way.
Back to tools.
Back to the CSE331 home page.
For problems or questions regarding this page, contact: cse331-staff@cs.washington.edu.