This repository contains the specifications for the three lab exercises for the Compilers module.
The three exercises are:
1 - Lexers and regular expressions (due Tue 9 Feb at 23:59).
2 - Parsers and ASTs (due Tue 23 Feb at 23:59 Thu 25 Feb at 23:59).
3 - Code Generation (due Tue 9 Mar at 23:59 Thu 11 Mar at 23:59).
(NB: the deadlines were extended by one week on 20-Jan-2021 to account for the mismatch between the lecture timetable and the lab timetable.)
The primary purpose of the lab exercises is to ensure that everyone learns the basic skills needed for the coursework. They are not designed to be too challenging, but they do require you to get to grips with several tools and concepts that you will need later.
The three exercises are equally weighted, and are together worth 20% of your Compilers mark (and hence 10% of your IAC mark).
The exercises will be marked in a largely automated fashion. I will compile your code and run it against a collection of my own inputs. Please note that it is very important to test that your code compiles and runs correctly. Failure to do so could result a mark of zero for that exercise.
Feedback will be largely in terms of what works and what doesn't work. I hope to provide formal feedback within ten working days. You are also encouraged to seek informal feedback on your code from the teaching assistant, your tutor, and your peers.
The target environment for the labs (and the coursework) is Ubuntu 16.04. It is strongly suggested that you do your final testing before each submission in this environment, otherwise you are likely to hit incompatibility problems, which may mean your program won't build. Those using Mac OS should watch out in particular, as the build environment is often subtly different.
If you want to work on your own machine (which is encouraged), you can install a version of Ubuntu quite easily. For this, you may wish to use VirtualBox together with Vagrant.
This repository contains a Vagrantfile, which is a script that sets up a blank Ubuntu 16.04 environment, and then installs all the tools that the lab exercises require. To start a virtual machine (VM) using Vagrant, follow these steps.
-
Open a shell in this directory.
-
Run
vagrant upto download, install, and configure the VM. -
Run
vagrant sshto log into the VM. -
Run
cd /vagrant: This will put you in the same directory, with your host files shared with the VM.
You can then use command line build tools in the VM, while editing the source files in your host editor.
If you want to stop the machine,
-
Run
exitto exit the session, -
Run
vagrant haltto shut down the virtual machine.
If you later run vagrant up again, it will not need to download the VM from scratch.
A private repository has been created for you, which you can clone using the following command:
git clone https://github.com/LangProc/langproc-2020-lab-${LOGIN}.git
You'll need to type in your GitHub credentials to authenticate, unless you've set up SSH authentication.
You are free to include any files you wish in your repository, such as notes or partial versions. However, try not check in compiled programs or large binary files. Repositories should contains the sources and instructions for binaries, but git does not deal well with binary files. Most repositories should contain a .gitignore file, which gives patterns for files that should not be committed. There is one included here which covers a few things, but feel free to add other temporary and binary files that your system might produce.
If there are any changes to the specification (e.g. bugs or updates), you can incorporate them into your version by pulling again from the specification repo. First you need to make sure it is included as a "remote":
git remote add spec https://github.com/LangProc/langproc-2020-lab.git
If you now list the remotes, you should see both "origin" (your private repo), and "spec" (the specification repo):
git remote -v
You can now integrate changes from the specification repo by pulling from it:
git pull spec master
If you have changed a file that also changed in the specification, then you may need to commit locally first. Look carefully at any incoming changes due to the pull, and make sure you want to accept them.
Submission of code is via your git repository. Make sure you have committed and pushed to GitHub all the files that your project needs. You are strongly encouraged to clone it into a different directory and then test again, just in case you are relying on something that wasn't committed.
Once your code is committed, note the commit hash of your current revision:
git log -1
This will produce something like:
ubuntu@ubuntu-xenial:/vagrant$ git log -1
commit 94d8419b20c78da86415bea7236d3719915977a3
Author: John Wickerson <[email protected]>
Date: Mon Jan 07 14:26:40 2018 +0000
All tests passing.
The commit hash of this revision is 94d8419b20c78da86415bea7236d3719915977a3
which is a cryptographic hash over all the files in your
repository, including the history of all the files. The hash produced
on your local machine will also match the hash calculated
by GitHub.
So take your hash (and just the hash), and submit it via Teams. Even if GitHub goes down, you can later on prove that the existence of your hash in Teams means you must have done the work associated with the hash. The hash in Teams will also be the exact revision of your repository that will get checked out of GitHub and tested. So you can carry on editing and modifying the repository, but only the commit with the hash submitted to Teams will be tested.
To summarise:
-
Test your code on your machine.
-
Commit your code to your local repo.
-
Note the commit hash (
git log -1). -
Push the code to GitHub.
-
Check that the commit hash in the GitHub website matches your local hash.
-
Strongly recommended: clone your code to a completely different directory, and test it again.
-
Submit the hash via Teams.
You can repeat this process as many times as you want, up until the deadline.
The exercises were devised by Dr David Thomas (course lecturer until 2017-18), and are nowadays maintained by Dr John Wickerson.