Guide to

Bender and Turnin

Turnin

Electronic turnin of programs is accomplished through a program called "turnin" which is available in my grader directory ~grade_cstaley/bin, so to run it, use the command ~grade_cstaley/bin/turnin, followed by commandline arguments as described below.

The turnin command requires a turnin directory as the first argument after the command itself. This will be supplied per-assignment in class or in the assignment specs. So, if the turnin directory is ~grade_cstaley/someclass/someassign, you'd have:

~grade_cstaley/bin/turnin ~grade_cstaley/someclass/someassign

AND, after the turnin directory, you also list all the files you wish to turn in, which list will be supplied per assignment in the assignment specs. Well use as an example the files Project.h and Project.cpp. The full command is thus:

~grade_cstaley/bin/turnin ~grade_cstaley/someclass/someassign Project.h Project.cpp

Turnin will confirm successful submission by listing each file as it turns them in. Check for the listing.

A note for those who may be using turnin at another school than Poly – my account name may be different. Make the appropriate substitution for “~grade_cstaley”. All else should work as described above.

If you've already turned in a file, and you then turn in a new version under the same name, turnin erases the old version. Don't worry about turning in files with the same name as other students; turnin creates a separate subdirectory for each student based on login name. But never turn in your files if you're logged in as someone else -- you will destroy their turned-in assignments.

When you turn in a file, turnin records the time you did so. If you resubmit a file that has already been turned in, the most recent turnin date is the one that is recorded for that file.

Bender

The grading robot, dubbed "Bender" by a Poly CPE 109 class in 2001, automatically grades your turnin-submitted files for accuracy. It does this by compiling and running your code (for programming projects) and testing it against a set of test cases that may or may not be published. Bender will tell you if your program fails to compile, if it fails one or more test cases, or if it "times out" by running too long. That last error may result from too-slow design, or from an endless loop. If your submission passes, Bender transfers it to the (human) style grader. Pass or fail, Bender will send email to your Poly Email account. If you get no Email, something's wrong.

For programming submissions, Bender requires that the output from your program match that from my model almost exactly. Bender uses "diff bw" to make the comparison of your output with mine. You must do the same when testing your code. No one ever passes Bender just by "eyeballing" their output to see if it matches mine.

If you want to get Bender Email at another address, arrange a forward of your Poly Email though my.calpoly.edu. Check your forward by mailing to <yourlogin>@calpoly.edu and seeing that it gets to your forward address.

Style Grading

After you pass Bender, a human style grader reviews your code (assuming the assignment is style-graded) and sends you another Email indicating whether you passed style. For an assignment to be accepted, you must get a passing Email from Bender and from the grader. Most people fail style on their first submission, and nearly all fail style 3-5 times before getting it right. You can save us time and save yourself late penalties by paying close attention to the style sheet.

Success and Failure

Once accepted, an assignment gets 100%, less any late penalties. It's official submission time is the time you ran turnin, not the time Bender or the grader checked it. Late penalties are almost always 5%/day, including weekends.

Submissions that are failed either by Bender or the style grader are erased from our records; we don't hold a copy. You must resubmit a fixed version to Bender, including *all* files.

Schedules and Deadlines

Bender runs at 1a, 7a, 1p, and 7p, every day including weekends. (This schedule no doubt contributes to his cranky attitude.) A submission before any of those times should result in a response Email to you within an hour or so after Bender's run.

The human grader actually needs sleep, so s/he grades once daily, typically between the 7p and 1a Bender runs. Expect Email from the grader by early AM the evening after your successful Bender pass.

Out of mercy, we assume that any submission made up to 7a in the morning is from the day before. In other words, "Midnight lasts all night long" or “If you haven't slept, it's still yesterday.” If the program is due on, say, May 1, it's "on time" up to 7a May 2.

Common Debugging Questions

What if I don't get a response from Bender?

There are several things you should check if you don't get a response from Bender:

1. Did you sign and submit the noncollaboration agreement? Bender only recognizes logins from those agreements.

2. Did you check Email on the machine on which Bender is running, or arrange for email to be forwarded from that machine? Mail to yourself at that machine (at Poly, yourlogin@vogon.csc.calpoly.edu) and be sure you receive the mail.

3. Did you submit to the correct turnin directory? It's easy to mess this up given the number of assignments you may turn in.

4. Did your turnin command show successful turnin for all files?

If the answer to all these is "yes", then check with Clint for more help.

What if I don't get a response from the style checker?

1. Be sure that you are Email-able at Vogon, and that you have a Vogon .forward set up, per the instructions.  Test this by mailing to yourself at <yourlogin>@vogon.csc.calpoly.edu.

2. If step 1 works properly, then Email the style grader and CC me (you can get the grader's Email from me).  We'll help you figure out what's wrong.

I get bounced for bad indentation, but my indentation is flawless.

1. Did you run the "detab" program as instructed in the style sheet?  Tabs have a nasty way of sneaking into your code.  Try running the command

cat -T <your file>

and see if any ^I markers appear -- these are tabs.  You can convert them to three-spaces via:

~cstaley/bin/detab <your file>

The turnin command says that turnin isn't allowed in the turnin directory

1. Check the turnin directory you typed in the command, letter-for-letter, respecting upper/lower case.

2. Due to a subtle security issue at Poly, you cannot run "turnin" successfully from the Terminal command on the lab machines without first starting an ssh session directly to Vogon from the Terminal command.  This is done by:

a. Typing command:  ssh vogon
b. Responding "yes" if you get challenged about a certificate.
c. supplying your password again

Once this is done, you'll still see a Unix prompt, but it should say <yourlogin>@vogon.  The commands you run henceforth will be run directly by Vogon. Turnin will then work correctly.

 When I do a turnin it complains about a "Command not found"

Read the instructions above carefully.  You are either giving the turnin directory as the command, instead of "~grade_cstaley/bin/turnin", or you're mistyping the command (capitals matter).

Bender says my program didn't compile, but it compiled fine for me

1. Be sure you are submitting exactly the file name or names requested, right down to the capitals.

2. If your code depends on a header or other file that you're not asked to submit, Bender will ignore that file, even if you submit it.  Be sure your program compiles even if only the files you must submit are present in the directory.   Don't make up other files than the ones requested, nor attempt to submit those.

3. You must resubmit all required files, every time, even if you're only trying to fix or test a few of the files.  Bender doesn't keep any of your old files when he bounces a submission.

Bender says I failed one or more tests, but I'm sure the program's working fine

1. If it's a Java program, be sure it's in the default package, or in a package specified by the assignment.

2. Review your test input files carefully, all dozen or so of them, to consider any unusual input case you might have omitted in your testing.  If you do not have test input files that's the problem!  Read my web page on Testing On Unix and follow the instructions there.

3. Did you run your script, which uses diff, on all test cases just before submitting?  Sometimes a last-minute bug or style fix introduces a bug.  If you don't have a script, or if it doesn't use diff, then see the scolding in point 2 above, and get your testing system built properly.

4. Did you run all this on Vogon?  Running tests on a different machine, especially in C, does not guarantee they'll work on Vogon.