Most of the marking process will be based on automated tests carried on a fresh build of your code. Your code will receive only a cursory inspection to ensure that you have observed the implementation limitations (if applicable), and to establish code ownership. Bad programming practice and dirty code will not impact your grade unless they impact the execution of the program, or are conspicuous enough to be easily noticed in said cursory code inspection. The documentation accompanying your submission is also part of the marking scheme;missing or incomplete documentation will set you back by as much as 20% of your marks.
As a consequence of this marking scheme your program must build exactly as specified and must accept input exactly as specified. Any deviation from the build specification or run time input requirements (command line arguments, configuration files, standard input, etc) will result in the submission not being marked at all and so receiving zero marks. I will not debug or fix during marking build errors or run time errors caused by not observing the given specification; trivial mistakes can be very costly so don’t make them.
To receive the full marks for documentation pay special attention to testing your submission. Incorrect implementations (aka bugs) identified as such may or may not subtract marks, depending on the extent of the problem. Bugs that would have been caught by a complete test suite but have not been identified by you will subtract marks no matter their extent.
In addition to all of the above be aware that identical or nearly identical submissions by two (or more) teams will receive (all of them) an automatic grade of 0 tokens. Further action according to the departmental and university regulations for academic dishonesty may be pursued.
The assignments should be handed in electronically, as one directory which in turn contains your work for the given assignment. Do not create any kind of archive; submit the directory itself, unarchived. The name of the submitted directory need not follow any particular format; it will be automatically prefixed by the name of your account at submission time.
Each submission must contain the following:
Should you use code other than yours, proper credit should be given to that code’s author. Proper
credit to my code (in the case that you are provided with an existing program to modify) means
clear identification of your changes, or grouping your changes in a new module. Failing to give
proper credit (and getting caught while at it :-)) shall be considered academic dishonesty and
will result in an automatic mark of 0 tokens for the given assignment and possibly further action
according to the relevant departmental and university regulations.
Building your code must produce an executable with a precise name (given in each assignment) in the root directory of your submission. The build process must complete successfully when using GNU make and GCC with the default target of your makefile.
The target clean that removes all the object files, executable files, and files created at run time is also compulsory.
I will build your submission using the following command issued in the root directory of your submission:
make clean && make
This file must be called “README” (capital letters, with no extension), must reside in the root directory of your submission, and must be plain text.
The first line of the file must contain all the names of the authors in full (first name and family name) separated by commas. All the names must be on a single line. The second line of the file must contain all the emails you want to be used to receive feedback and marks. You can provide as many emails as you wish; they must all be on a single line and separated by commas. Optionally (but encouraged), you can provide on the next line the student numbers of all the collaborators.
The rest of the file is free form and must document your submission. Documentation is an integral part of your submission and should include the following:
The following submission method is compulsory; assignments submitted in any other way will not be marked. If necessary, transfer your submission to linux.ubishops.ca. Then open a terminal on linux.ubishops.ca and type
submit cs464 dir
where dir is the directory you want to submit. You can specify it by either a relative or an absolute path. Also note the capitalization of “cs464” (or rather the lack thereof) which must be observed.
Resubmissions within the due date are allowed. Just re-issue the above command for this to happen. Note that only the most recent submission will be marked.
Short answer: Your late submission will be accepted (with a penalty) if and only if the submit program does not say otherwise.
Longer answer: Late submissions will incur a penalty of 20% per day. Under no circumstance will a submission be accepted after solutions have been made public. Solutions may be posted as soon as three days after the assignment due date. If the submit program says that submissions are disabled, then your work will not be accepted.
Assume that your work (code, documentation, etc.) is in the directory ~/networks/assignment1, and that the current working directory is ~/networks. You should then type one of the following commands:
submit cs464 ~/networks/assignment1
submit cs464 assignment1
submit cs464 ./assignment1
Type man submit for more details.
When you test your program, your first priority is to test the behaviour of your code when the input is correct. Ideally, you should take into consideration all the possible inputs. This is usually impossible, but at least I want to see from you a genuine effort in this direction.
In order to test the program on correct input, you should identify to the best of your ability classes of input, i.e., categories of input for which your program should behave in a different manner. Once these classes are identified, you could pick one (or more) sample inputs from each class and feed them to the program.
Of course, the reaction of your program to erroneous input should be considered as well, but that should be your secondary goal during testing. However, your program should not loose control when presented to erroneous input. In particular, buffer overflows should be avoided to the best of your abilities; any segmentation violation will be severely penalized.
I am not asking you to do a perfect testing suite, I just ask for a honest effort on the matter. I also ask for a brief explanation of why is your test suite complete, just to make sure that you knew what you were doing.
Poor test suites or poor explanations will be penalized, especially when your program exhibits an erroneous behaviour that would have been caught by a reasonable set of tests.
The reference computing environment for the assignments is linux.ubishops.ca, meaning that this is the environment under which we will build and run your solutions. This environment is a Linux machine which provides a recent version of GCC (currently 15.2) and a recent version of GNU make.
This being said, a well written solution should build and run on any reasonably current POSIX system with a standard C/C++ compiler (including but not necessarily limited to GCC and LLVM) and a non-ancient version of make (GNU or otherwise). You can easily set up such an environment using any current Linux distribution (make sure that you install the development packages) or Mac OS (with Xcode as well as the Xcode command line tools installed). The easiest way to create such an environment in Windows is to use the Windows Subsystem for Linux aka WSL. It is still a good idea to test out your solution on linux.ubishops.ca before submitting (just in case).
Later in the course you will need to test distributed applications. You can accomplish this on the CS network using the machines in Johnson 118. The IP addresses of these machines include the range 10.18.0.111 to 10.18.0.125. Other than their consoles (located physically in Johnson 118) these machines are only accessible from linux.ubishops.ca (meaning that you will have to connect to linux.ubishops.ca first and then ssh into the machines from there). The machines are imaged essentially identically with linux.ubishops.ca. The login credentials as well as your home directory are shared between all the machines involved.