Using the Autograder
CS377 uses a system for automatically grading your projects. This isn't because we are lazy, the autograder is designed to help you do the projects correctly, and to give us more time to help you work on them.
CREDIT: Many parts of the autograder were developed at the University of Michigan by Pete Chen, Brian Noble, Atul Prakash and others. Thanks!
To help you validate your programs, your submissions will be graded automatically, and the result will be mailed back to you. You may then continue to work on the project and re-submit. The results from the auto-grader will not be very illuminating; they won't tell you where your problem is or give you the test programs. The main purpose of the auto-grader is it helps you know to keep working on your project (rather than thinking it's perfect and ending up with a 0). The best way to debug your program is to generate your own test cases, figure out the correct answers, and compare your program's output to the correct answers. This is also one of the best ways to learn the concepts in the project.
You may submit your program as many times as you like. However, only the first submission of each day will be graded and mailed back to you. Later submissions on that day will be graded and cataloged, but the results will not be mailed back to you.
In addition to this one-per-day policy, you will be given 3 bonus submissions that also provide feedback. These will be used automatically--any submission you make after the first one of that day will use one of your bonus submissions. After your 3 bonus submissions are used up, the system will continue to provide 1 feedback per day.
Because your programs will be auto-graded, you must be careful to follow the exact rules in the project description.
In addition to the auto-grader's evaluation of your programs' correctness, a human grader will evaluate your programs on issues such as the clarity and completeness of your documentation, coding style, the efficiency, brevity, and understandability of your code, etc.. Your final score will be the product of the hand-graded score (between 1-1.12) and the auto-grader score.
Use the submit377 program to submit your files. The full name is /courses/cs300/cs377/cs377/bin/submit377, but you should add /courses/cs300/cs377/cs377/bin/ to your path (see the FAQ) so you don't have to keep typing in the full name. submit377 submits the set of files associated with the project part and is called as follows: submit377 ... C++ programs should end in ".cc".
For instance, for project 1(inverter) you will execute:
submit377 1 inverter.cc
The system will package up your project and send it to the grader. The tiny hampsters will spin in their cages, and within a few hours you should receive an email telling you how you did. If you do not receive a response within 4 hours of submission, please mail the instructor.
The official time of submission for your project will be the time the project is received at the grader. If you send in anything after the due date, your project will be considered late (and will use up your late days or will receive a zero). Each group member will evaluate the contributions made by each person in the group. The course home page will have a link to a web form where you can enter your evaluation.
The key to using the autograding system is to:
1) As they say in Chicago: "vote early---and often". Your submissions are limited to one per day (plus bonus submissions). This means the earlier you start on the projects, the more chances you have to get it right. I have never seen someone start on the last day and get the project right.
2) Recognize that the autograder is not a debugger. The autograder will not tell you what you did wrong or even any inkling of what you did wrong. The autograder (and the instructor) is not going to tell you what the autograder is using for testcases. When you go out into the world the autograder is not going to be there to help you.
3) Testing is the only way to figure out what is wrong with your program. Wriing effective test cases is central to writing good software.
4) Do not be afaid to "throw one away". Starting over is hard to do, but sometimes it is the best option.