Marking Scheme (Outdated)

Directories and Files for Student Submissions (not applied to MarkUs)

The submitted files for Assignment 3 are stored in ~/handin/3.

• ~/handin/3/.subfiles is a list of files to be submitted including all scheme and text files. This list should be consistent with the assignment specifications.
• ~/handin/3/.reject is a list of files that do not need to be submitted. It should be clear to the students that they should NOT submit these files. This file is rarely used in CS 135.

Controlling Submission

When an assignment is released to students, the deadline command must be run to ensure that students will be able to successfully submit their code. For example, to allow students to submit Assignment 3, you would use:

/u/isg/bin/deadline 3 o

To cut off the submissions for Assignment 3, use the following command:

/u/isg/bin/deadline 3 n

Instead of worrying about when to shut off submission, it is convenient to set “at” job for stopping the submission after the due date.

at <time><month><day> (eg. at 1735 Jan 19)

You will be prompted with at>, type the deadline command, ( /u/isg/bin/deadline 3 n), hit enter, thenctrl-d to end the at job. To list all the at-jobs, type:

at –l

To remove an at-job, type:

at –r <filename>

To account for problems that may occur near the assignment deadline, submissions are generally cut off 5 to 10 minutes after the deadlines have passed.

Creating Test Cases

Navigate to the "=in=" folder and add directories for each question (i.e. 1 2 3 ...). In each question folder add directories for each part of a question (i.e. a b c ...). Now add a test.ss file to each leaf folder. Also add anoptions.ss file to each question folder.

The test.ss file should look similar to the following example:

(desc "(matching-brackets? (string->list \"(([]){)}[{}()]\"))")
(result (matching-brackets? (string->list "(([]){)}[{}()]")))
(expected false)

Notice that the description in test.ss is on a single line. A multi-line string passed into the description function will cause errors with RST.

The options.ss file should look similar to the following example:

(language intermediate-lambda)
(loadcode "sudoku.ss")
(modules "puzzles.ss")
(value 1/2)

The options.ss file can be placed in any directory. The options specified in the options.ss file will take effect for all subdirectories unless another options.ss file is encountered. Not all of the options in the above example are necessary to be specified. For example the language level may only need to be specified for an entire assignment and so could be placed in an options.ss in the "=in=" folder.

View the structure of the marking directory from the previous academic offering as a more detailed example. The Folderize Script described in the next section may also be used to make this process more convenient.

Using The Folderize Script

Place all test cases for a specific question in a file called testlist.ss and place it in the following directory structure:

marking<assignment><test-suite>/in/<question>/testlist.ss

Within the file a semi-colon followed by a digit represents the start of a test case and a semi-colon followed by a pound sign represents the end:

;3

;a comment describing the test


;#

After all test cases have been written run the folderize script using the correct parameters:

Usage: folderize  {p|m|c} 

This will create a folder for each test case described in the testlist.ss file within the /in/<question> directory. Within each folder a test.ss file will be created containing the code for the test case.

NOTE: running folderize again will override any existing test case folders, however the script will NOT delete folders, so if you remove a test case from

testlist.ss

be sure to remove the associated test case folder if it was already created.

The format of the tests and any other options or modules is outlined in the Marking Suite Usage PDF. New Scripts:

The material in section 1.7 is still a method that can be used to run the marking scripts; however, there have been some new scripts that have made this process much easier and a bit more efficient.

The problem with the method in 1.7 was that running the rst command on all students in one terminal takes a VERY long time.

Because of the fact that the results of rst commands with the same timestamp run on different students will end up in the same folder, one method was to manually divide up the students into group and run each group on a separate CPU.

This was still difficult to do. So the following scripts were created.

To run rst on all of the students for an assignment, do the following. First, run:

genRST <assignment> {p|m|c} <suite> <regex> <timestamp>

This command will create a temporary file for each student who matches the regex category. What is contain within this file is merely a script which will be called by greedyRST that will run rst on the student listed in that file. These files are stored in a folder called tmprst

example:

genRST 3 p 0 ‘^[a-z]’ printRun

This command would create files which will run the testp.0 test suite for assignment 3 for all students whose userid’s begin with a letter a through z (which is why naming fake student files used specifically for trial run purposes only is a great idea).

After running genRST, you then can open as many terminals as you would like to use and run:

greedyRST

What this script will do is grab a file in tmprst, run it, and then immediately delete it. In this sense, no matter how long rst takes on any one student, the first available terminal will grab the first available student. There has only ever been one incident in which rst was run on one student twice, but nonetheless beware of this possibility, as rare as it is.

Enter Marks

Update the marks spreadsheet located in ~/marks/ as soon as the TAs give the assignments back. Uploading the marks does not have to be immediate.

Hand Assignments Back

Course not using MarkUs

Hand the assignments back during the first Tutorial after the TAs give the marked assignments back. This is why it’s a good idea to set the marking deadlines for the TAs to be 2 to 3 days before the first tutorial of the week.

-- AndrewGemmel - 2014-12-16