On this page, you can find instructions to submit your code, check your submitted files and how to solve common submission problems. Follow these instructions to submit your code and Doxygen code documentation.
Remember that only the last submission made by any member of each team is considered for marking.
> /cad2/ece297s/public/testsubmitece297s 2
This script does not submit your code. You may use it as a check before you are ready to submit your code. Once you get the positive confirmation from the
We highly recommend that you continue to use the
Save the output of the Testsubmit script as follows.
> /cad2/ece297s/public/testsubmitece297s 2 > testsubmitAss2.log
Please make sure that you include the output file
Make sure the FINAL versions of all your changes are added and committed to the Subversion repository. Don't forget to
You will be submitting three files: storage-asst2.tgz will contain your complete source code, storage-asst2.diff will contain a record of the changes you've made to the code since the initial checkin, and doxygen-asst2.tgz will contain your Doxygen source code documentation. (To generate the .diff file, you will use the
> mkdir ~/ece297/submit > svn export ~/ece297/storage ~/ece297/submit/storage-asst2 > cd ~/ece297/submit > tar zcf storage-asst2.tgz storage-asst2 > rm -r storage-asst2 > submitece297s 2 storage-asst2.tgz
> mkdir ~/ece297/submit > cd ~/ece297/storage > svn diff -r 1:HEAD > ~/ece297/submit/storage-asst2.diff > cd ~/ece297/submit > submitece297s 2 storage-asst2.diff
> mkdir ~/ece297/submit > cd ~/ece297/storage/doc > make > tar zcf ~/ece297/submit/doxygen-asst2.tgz doxygen/ > cd ~/ece297/submit > submitece297s 2 doxygen-asst2.tgz
> cd ~/ece297/submit > submitece297s 2 performance-asst2.pdf
Please ensure your census data is available at storage/data/census/ and storage/data/census.conf exists and is part of the submitted tar archive.
You can see what files you have submitted by entering:
> submitece297s -l 2
In particular check the file size and date to confirm the correct file was submitted.
Some of the marking tests are available at
> cd ~/ece297/storage/test > tar zxf /cad2/ece297s/public/assignment2/a2-partial.tgz > cd a2-partial > make clean run
We highly recommend you make sure your submitted code passes the test suites given to you as part of the skeleton distribution and that it passed the testsubmitece297s test before submission.
These test suites were also mentioned here as part of instructions to set up the development environment. Follow the instructions below to unpack the code in a temporary directory and test it. (You can delete the temporary directory when you're done.)
> mkdir ~/ece297/tmp > cd ~/ece297/tmp > tar zxf ~/ece297/submit/storage-asst2.tgz > cd ~/ece297/tmp/storage-asst2/test > make run
We will mark your submissions partially based on the test cases given to you, so if these test cases fail, our processing of your submission is likely going to fail as well. Note that we will add additional test cases to evaluate your submission above and beyond the ones we are making available to you.
We only mark the files submitted by member of the teams. You can check these files by entering:
> checksubmit 2
In particular check the files' size, date, and the user who submitted the files.
Try to avoid SVN-related submission problems as follows:
> tar -zcf storage-asstX.tgz storage-asstX/
You can then submit the tar file by following instructions in the assignments' submission pages. Remember that by following the above approach, you will lose the marks allocated for successful SVN export.
Some other common submission problems happen when you include wrong files in your submission tar file.
> tar -tf <submission-file>.tgz storage-asst2/src/ storage-asst2/src/default.conf storage-asst2/src/client.c storage-asst2/src/utils.c storage-asst2/src/storage.c storage-asst2/src/utils.h storage-asst2/src/server.c ...
> tar -zxf storage-asst2.tgz
Your assignment will be marked based on the code you submit and based on the design document you submit.
The code you submit for this assignment will be evaluated as follows. We will build your system and test it for correctness based on a set of test cases. For example, we will issue get/set calls and check for the return values and error conditions.
It is therefore critically important that you adhere to the Makefile template and code template we provide for you, as our build scripts will be based on these files. At the very least make sure the test suites given to you pass.
Marks will be allocated to a flawless build of your system. Should your build fail, we will try to fix the problem with application of reasonable effort, but would deduct some marks. Should our intervention not lead to successfully building your system, we will inspect your submission and allocate marks based on an assessment of the development effort, the documentation, the clarity and cleanliness of your code. However, marks will be deducted to differentiate from submissions that correctly build and pass test cases.
It is extremely important that you run the
Marks will also be allocated to the number of test cases your system correctly passes.
A perfect score for your code submission can be achieved if your system builds correctly and passes all test cases.
The design document you submit for this assignment will be evaluated on the basis of the engineering communication principles laid out in the course text book and explained in lectures. That is, we will not be grading on the basis of qualitative judgments of what makes good or bad writing, but rather how well you are able to implement awareness of: purpose and audience, overall organization, rhetorical tools, paragraph and sentence level clarity, as well as visual elements. The grading rubric is available here. The rubric defines qualities that exceed requirements, meet requirements or require revision to meet requirements.
In addition, Communication Instructors/Project Managers will offer individual comments that guide students toward revision and editing of the M2 Design Document, which will form the basis of the second design document. That document, and subsequent documents, will thus retain previous iterations, which have been revised and improved, as well as adding new sections to these.
A perfect score is possible if your document is thoughtful, technically accurate, economically and clearly written, supports every statement meaningfully with either logic or data (your own or from research sources), has absolutely no padding of any sort, and contains minimal to no errors in grammar, syntax or usage.
Here is a rough guideline for the marking scheme of the coding portion of this assignment:
The assignment is worth 62 marks in total.
In this assignment you may obtain the following bonus marks.
Milestone 2 >