Milestone 3‎ > ‎

Submission instructions

Test Submitting Assignment 3

The testsubmitece297s script tests wether all required files are included in your submission, the project is buildable, and the available test cases pass. You can testsubmit assignment 3 as follows.

> /cad2/ece297s/public/testsubmitece297s 3

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 testsubmitece297s script (Your code is ready for submission), follow the instructions here to submit your code.

We highly recommend that you continue to use the testsubmitece297s script throughout the assignment and not leave it until the last minute before the deadline. This script is meant to help you understand what works and what tests pass successfully, and what you may want to fix before submitting. Note that we will process additional test cases with your submission, which are not included in the test cases available to you via the submission script. This may mean that while the script tells you to go ahead with your submission, your code may still exhibit bugs and may not pass all the test cases we will be subjecting it to (for marking).

Save the output of the Testsubmit script as follows.

> /cad2/ece297s/public/testsubmitece297s 3 > testsubmitAss3.log

Please make sure that you include the output file testsubmitAss3.log in storage-asst3.tgz as your are required to submit it as part of your code.

Code submission instructions

Make sure the FINAL versions of all your changes are added and committed to the Subversion repository. Don't forget to svn add and svn commit any new files (other than binary files) you created.

You will be submitting two files: storage-asst3.tgz will contain your complete source code, and storage-asst3.diff will contain a record of the changes you've made to the code since the initial checkin.

  • Create and submit storage-asst3.tgz as follows.
> mkdir ~/ece297/submit
> svn export ~/ece297/storage ~/ece297/submit/storage-asst3
> cd ~/ece297/submit
> tar zcf storage-asst3.tgz storage-asst3
> rm -r storage-asst3
> submitece297s 3 storage-asst3.tgz

Refer to this page for a list of common submission problems and how to solve them.

  • Create and submit storage-asst3.diff as follows.
> mkdir ~/ece297/submit
> cd ~/ece297/storage
> svn diff -r 1:HEAD > ~/ece297/submit/storage-asst3.diff
> cd ~/ece297/submit
> submitece297s 3 storage-asst3.diff

Be sure to do a final check by running your tests on your submission.

> mkdir ~/ece297/tmp
> cd ~/ece297/tmp
> tar zxf ~/ece297/submit/storage-asst3.tgz
> cd ~/ece297/tmp/storage-asst3/test/query
> make run
> cd ~/ece297/tmp/storage-asst3/test/set
> make run
> cd ~/ece297/tmp/storage-asst3/test/get
> make run

If you haven't already done so, you can also run some of our tests. Some of the marking tests are available at/cad2/ece297s/public/assignment3/a3-partial.tgz. You can try running them as follows.

> cd ~/ece297/storage/test
> tar zxf /cad2/ece297s/public/assignment3/a3-partial.tgz
> cd a3-partial
> make clean run

Check Submitted Files

We only mark the most recent files submitted by any member of the teams. You can see which submitted files will be marked by entering below line at all team members' command prompt:

> checksubmit 3

In particular check the file size and latest submission date to confirm the correct file was submitted. Carefully examine the .tgz and .diff files to make sure all your changes are there, including the unit tests you added.

Common Submission Problems

Refer to the page here for some common submission problems and how to solve them.

Marking guidelines

Your assignment will be marked based on the code and 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 would try to fix the problem with reasonable effort, but would deduct some marks. Should our intervention not lead to successful build of 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.

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.

As with the M2 Design Document: Basic Storage Server, the fundamental basis of evaluation for the M3 Design Document are principles laid out in the course text book. 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.

You are expected to be able to analyze the instructions in order to determine the design decisions pertinent to the assignment and to discuss these decisions in an orderly fashion. Information must be easy to find, and language must be precise, efficient and correct.

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 very few to no errors in grammar, syntax or usage.

Tentative code marking scheme

Here is the marking scheme for the coding portion:

  • [4 marks] Build+Submission: 2 marks if the server and client library build without error, or 1 mark if they build after a reasonable effort to fix submission problems. Plus 0.5 marks if the submission is a valid SVN export, and 0.5 marks for submitting a .diff file.
  • [4 marks] Coding attempt: 0.5 marks each for a reasonable attempt to support the get/set and query functions in the server and client library.
  • [5 marks] Submitted tests: 0.5 marks for each get/set/query test submitted, and 0.5 marks for each of these tests that pass.
  • [85 marks] Automarker tests: 1 mark for each test that pass.

Bonus marks

In this assignment you may obtain the following bonus marks.

  • If your Assignment 3 submission builds successfully and passes 90% of the test cases we apply, the coding portion of your Assignment 2 mark will be increased to 40%. If your Assignment 2 coding mark was already more than 40%, your mark will not be changed.
  • If your Assignment 2 code was not submitted properly (received 0 for no submission) but you were able to submit for Assignment 3, we will re-run the Assignment 2 tests over your M2 code with a 25% penalty.
  • Bonus marks are allocated for early submissions. Your submission qualifies as early if you submit 7 full days before the advertised code submission deadline. You may not submit prior to submitting the design document. We want you to think, design, and plan before you code. Also, your submission must build successfully and at least 90% of our test cases must pass.
  • Bonus marks are allocated for the use of the tools Lex and Yacc in the development of the configuration file parser (we require the use of Flex for Lex and Bison for Yacc.) Moreover, your project has to build and pass 90% of all test cases we run. No test case relating to the parsing of the configuration file may fail. We encourage that you use Lex and Yacc for other parsing tasks as well.
  • Bonus marks are allocated for supporting persistent storage policy. Follow the specifications here. You must pass 90% of the persistence tests to qualify. You can use a3-disk.tgz (same location as a3-partial.tgz) for partial tests. Note that if you implement this bonus, your code must still support the original specifications, which means your server must run even if no storage policy is indicated (in which case, it defaults to in-memory storage).