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).

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.

Milestone grading

For each project milestone, you're expected to turn in that milestone prior to class on the day it's due. For milestone 1 (on any project), you may submit this any point before that time. For any subsequent milestone (e.g. milestone 2), it must be turned in after the due time of its predecessor (e.g. milestone 1).

Milestones will be graded electronically. I will look at the code you submitted, check for completeness, and give you a simple full/half/no credit grade. I may also add comments on your code. I check to see that you have given real thought to implementing AND testing the functions for the milestone. You must include a test driver (e.g. main() that tests the code you wrote for the milestone) for every milestone, except those for which the project driver is the milestone.

You will receive your grade and commented code in an attached PDF to an email that I will send to your Baylor email address. Usually this should be returned to you in 1-2 days. If you don't get your milestone grade within 4 days, you can start asking me about it. These emails are sent using scripts (so they may look to a filter like spam), so please make sure you check your junk mail folder for these emails if you are expecting one.

Two steps for passing each project

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

You must pass the robot. Select "Test Program" on the project page to have the robot grade your project.
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 with that project. 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 clicked test for the version that passes both steps. You may upload your code as often as you would like. However, the number of times you may test your program will depend on the number of tokens you have (see below).

How often can I test?

For each project, you will receive a number of "tokens" on the upload site. Each token allows you to test your program once. The tokens may (or may not!) regenerate after you use them, after a certain amount of time. The number of tokens and how often they regenerate will depend on the project. This token-based system is so you will spend time thinking carefully about the problem and testing on your own computer.

How the robot tests your project

The robot will compile your project using the g++ compiler, and run your project on hidden test cases. You do not have access to these test cases, but you are encouraged to make your own test cases!

For each test case, your project must produce output that is identical (character for character) to the correct output. Further, 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).

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:

You have not submitted all the necessary files.
Your code does not compile.
Your output does not match my output on the same input.
Your program crashed on an assert during execution (you will be given the assert message -- valuable information!).
Your program crashed during execution (divide by zero, memory access error, etc.).
Your program leaked too much memory during execution.
Your program wrote to, or read from, memory it did not own.
Your program required too much time to execute.

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.

Make your own test cases (and use them!)

The first thing you should do before you begin writing code for any project is to make test cases -- inputs and expected outputs -- for your program. Put each test case in its own file, and save it for later testing. You can make as many as you want. The more that you make, the more chances that you have of catching a program error, if you follow the tips provided below. Think about covering all the tricky cases, but keep your tests simple at the same time.

The way to use your test cases is to run both your program, and the provided correct executable, on a test input, and compare their outputs.

You should NOT expect that your program is correct if it gives the correct outputs on the sample inputs provided for you on the project web pages. These samples will not cover the breadth of tests that the robot will throw at your program.

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.

Your professor also encourages you to look into the diff modes of the VIM and EMACS editors, if you use one of those.

Comparing output -- other tips

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

Do not use copy and paste. Copy and paste can introduce extra newlines, and perhaps other characters, that aren't part of the original file you are copying from.
Download files. Instead of copy/paste, download all files directly from the course web pages to your computer. That is, right-click on the link and use "Save target as..." (for Internet Explorer) or "Save link as..." (for Mozilla). This will make sure the file that is on the website is exactly the file that is on your hard drive.
Use file redirection to provide input to your program. To get input to your program directly from the file, use file input redirection from the command line. In DOS and UNIX (Linux/OSX), you can "redirect" a file to be the input to your program (instead of the keyboard). The DOS syntax (UNIX is basically the same) is
```
c:\my_folder> my_program.exe < input_file
```
This will take the data in input_file and redirect it so that the program will read it in on standard input. The key here is the "<" and the file name.
Use file redirection to capture the output of your program. Use output redirection to save your program's output to a file, exactly as it comes out of your program. Here we use ">" and a file name:
```
c:\my_folder> my_program.exe > my_output
```
This will send all the standard output from your program to the file named my_output (and not to the screen).
Putting it all together, use input and output redirection at the same time:
```
c:\my_folder> my_program.exe < input_file > my_output
```
After this, we can use a diff utility to compare my_output with the output sample you expect (e.g. from the sample executable). Remember, don't use copy and paste -- use input redirection. Don't compare visually -- use output redirection and a diff utility.

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!

valid html and css