How to upload your programming projects and milestones

We will use the upload site for two purposes: to upload project milestones, and to grade projects with the robot. The upload website is at https://csi-info.baylor.edu/upload/.

Logging in to the upload site

You access the upload site with your Bear ID and a your Bear ID's password (the one you use for accessing your Baylor email). There is NOT have a separate password for the upload site, as in the past.

Uploading your code (for milestones and grading)

On the upload site, find the project you want to upload, which has a submission field for each file. Use the "Browse" button to locate each file, and select "Upload" for each file to send that file to the server. If you are uploading a milestone, this is all that is required. To also have your project graded, follow the instructions in the next section.

Remember, if you change your code on your computer, you will need to upload the code again to the server for the server to notice the change.

Two steps for passing each project

To pass each project, you must accomplish two high-level steps, in this order:

  1. First, you must pass the robot. Select "Test Program" on the project page to have the robot grade your project.
  2. Second, the version that passed the robot must pass the professor's check for style and other correctness issues.

Each time you ask the robot to grade your program, it will send you an email with its decision. If you get a YES (a pass) from the robot, then your professor will look at your code and send you another email indicating whether your project passes the style and implementation check. If you pass both, you are done. Both emails will be sent to your bear_id@baylor.edu email address -- please check that your spam filter is not catching the emails.

The grade you get will be based on the time you uploaded your project to the upload site for the version that passes both steps. You may upload your code and ask the robot to grade it as many times as you like without penalty.

If your code doesn't pass the robot's evaluation, it will tell you "NO" and give you a reason why. Some common reasons are:

  1. You have not submitted all the necessary files.
  2. Your code does not compile.
  3. Your output does not match my output on the same input.
  4. Your program crashed on an assert during execution (you will be given the assert message -- valuable information!).
  5. Your program crashed during execution (divide by zero, memory access error, etc.).
  6. Your program leaked too much memory during execution.
  7. Your program wrote to or read from memory it did not own.
  8. Your program required too much time to execute.
For reasons 1-2, you can immediately ask the robot to re-grade your project. For other problems, the robot has a built-in delay built that will prevent you from grading your program too frequently. This delay is present so you will spend time thinking carefully about the problem and testing on your own computer.

The robot will run your project on hidden test cases. Your project must produce identical (character for character) output compared with the correct output, and it must not crash, leak memory, use too much memory, run too long, etc. To detect memory leaks, the robot will run your project using valgrind under Linux (which you could also download and use yourself).

After pressing "Test Program," there will be a column in the browser named "SOLUTION OUTPUT:", but it will always be empty. Ignore this column.

If your project passes the robot but NOT the style check, then when you want your project to be re-graded, you MUST have the robot re-judge your project. That is, you should select "Test Program" again.

Testing and debugging your program

The robot is not a testing/debugging/development platform; it is for GRADING your program. Therefore, you should test your program on YOUR OWN COMPUTER.

You will be provided a sample executable for each project. This executable is is the professor's correct solution which you can use to run on your own computer for testing purposes. The sample executable must be run from the command-line (i.e. DOS or bash or Terminal.app). You can't just download them and double-click them to run. Also, for the linux and OSX binaries, after you've downloaded them you need to make sure that they are executable. To do this, from the command line type chmod +x file, where file is the name of the program you downloaded.

Comparing output -- Diff utilities

To check that your output is exactly the same as output from the sample executable, use a diff utility. Two files may appear the same to the naked eye, but may be different due to spaces, newlines, or some other hidden characters. Diff utilities will catch these differences you can't see.

Under OSX or Linux/UNIX, diff should be available from the command line. Under Windows, WinMerge works well. When you run WinMerge for the first time, make sure you do the following: (1) Open the Options control panel (Edit -> Options), then (2) set the options to be "Compare whitespace" and set "Sensitive to EOL" to be true. These options ensure that WinMerge catches every difference.

Metrowerks CodeWarrior also allows you to compare two files (see menu Search, option "Compare Files"). However, CodeWarrior will (by default) ignore differences in newlines, so that is a problem.

Comparing output -- other tips

Here are some important tips to make sure you are comparing files correctly:

Using the command-line interface

For this class, it's good to get familiar with using the command-line (DOS under Windows, or bash under Mac/Linux/Unix) for testing your program. If you're not familiar with it, the command line may seem cryptic, but it's fairly simple, and it can make you much more efficient than using GUI tools.

The main things to know about using the command line are: how to get to your executable program (usually under the some subdirectory of your project that your compiler automatically created) by using the "cd" and "dir" (or "ls") commands, how to run the program (type in the name, perhaps with a "./" in front for bash), and how to redirect input/output (see section above on comparing output). It's also useful to use the up/down arrow keys to get to recent commands, and to use the TAB key to do auto-completion of a partially-typed command. We may talk about using the command-line in class, but if you want help feel free to come talk to your professor about it.

General tips for testing and debugging

The robot's test cases are hidden, but you can and should develop test cases that will test your program as thoroughly as possible. Think about each project carefully, and what the "boundary conditions" might be. That is, think about large test cases, small ones, complicated ones, simple ones, etc. If the project specifies that some value will be in a range from 1 to 1000 (for example), then test 1 and 1000, as well as values in between (the 1 and 1000 are the boundary conditions). I even recommend developing test cases before you write a single line of code.

Use your debugging skills to find problems in your programs. This means using print statements to check the flow of your program, the values of variables at certain points, and your IDE's debugger (as a last resort). The assert() function can be a good debugging tool.

Don't use exceptions

Don't use exception handling in this course. Exception handling is for abnormal program condition handling, not for normal program function. We won't use it in this class, since it doesn't work the same on all computers and all compilers.

Use assert()

The C/C++ function assert() allows you to tell the program "make sure this is true, and if it isn't, crash the program and tell me about it." To access this function in C++, #include <cassert>.

Assert can give you very useful feedback about where your program is going wrong. You pass to assert a condition that should evaluate to true or false. If it is true, then nothing happens. If it's false, then assert crashes your program and prints an informative error about where the program crashed.

Here is an example:

int *song_length = new int;
assert(song_length != NULL);
If the memory allocation fails, then song_length will be NULL, and the program will crash when it gets into the assert. It will print something like this:
example.cpp:7: failed assertion `song_length != NULL'

If your program stops on an assert() during the robot's grading, the robot will give you the information about that assert, including the assert message, file name and line number. Asserts can be very useful for debugging.

Having problems?

If the robot is not working properly, it should report a very generic error message. Your professor will also get an automated email that there was a problem, so you shouldn't need to do anything but wait for the problem to be fixed.

Thanks

Many thanks to Bill Booth for providing and maintaining the upload system.

Need some advice?

If you are having problems with your project, you can save your professor time by asking for .

Press the button!


Copyright © 2007 Greg Hamerly.
Computer Science Department
Baylor University

valid html and css