Please, please, PLEASE read and follow the instructions below.
Make sure that all of the code that you submit can be compiled with a single
gradle build in the root project directory — this means that the directory structure and the build scripts settings.gradle and build.gradle must be configured properly (see the explanations below and an example file here).
Please put your whole submission into a single directory that
has your candidate ID (i.e. a 6-digit string) as its name. This single directory (called the root project in Gradle) has sub-directories task1, task2,
and task3 (called subprojects in Gradle).
settings.gradle (where task1, task2,
and task3 are specified as subprojects), and possibly
other files shared among tasks, into the root project directory.
E.g., if you use ANTLR, you may also put its pre-compiled .jar file here.
build.gradle (where you may specify dependencies) into the corresponding subproject directory.
If you use a lexer generator to produce a lexer, or a parser generator to produce a parser, then please submit the inputs (e.g., grammar files) to the generator(s) too. There is no need to integrate generators into your Gradle build, however.
We will only run your code with Gradle. For example, to run your Task 2 we will use the command gradle :task2:run in the root project directory (run is defined in build.gradle in task2).
To ensure that the tests run properly, please do the following:
System.in.
System.out.
In particular, when we run your code, it should only output information required
by the task specification to System.out, with no redundant
messages such as those used for debugging.
Please try run-tests.sh in the example file
to get an idea on how your code will be tested.
Please do the following when submitting your code for evaluation.
rar for submission:rar cannot be reliably un-rar-ed on OSX and Linux.
After you submit, please download your submitted file and check that the archive can be extracted.
234725.zip
or 439231.tar.gz. Also, to ensure anonymity, do not put your names anywhere in your
submissions.
The work submitted must be your own. You may discuss the designs of your programs with each other in broad outline, but discussions at the level of program statements — or other forms of collaboration on actual code — are unacceptable.
If you have not done so already, you would be well advised to consult the University of Sussex Handbook guidelines on the subjects of collusion and plagiarism: see here.