Assignment Tasks
For each module, there are two kinds of assignments:
- Programming Assignments. These assignments should be done in one of the approved programming languages: OCaml, Scala, Haskell, Rust, Java, or C/C++. We recommend using either OCaml or Scala, which supports a functional programming style, although it is allowed to submit solutions in any of these languages. The programming assignments are released on the first Monday of each module.
- Theoretical Individual Assignments. Each student will have an individual set of exercises. The individual assignments will be available in your course Git-repo.
See below for the Assignment Workflow and instructions on developing and submitting the assignments.
If you do not meet the deadline (do not submit on time), you can still submit a solution for a module (e.g., module 1) before the deadline for a coming module (e.g., module 2). You will then be given the opportunity to do the peer reviewing and to have a seminar for module 1 as soon as possible, but the exact date may vary depending on the availability of time slots. Hence, it is allowed to submit later during the course, but you will miss the deadline bonus.
| Module | Assignment | Supplementary Material |
| 0 | assignments-module0.pdf Download assignments-module0.pdf | |
| 1 | examples.zip Download examples.zip | |
| 2 | assignments-module2.pdf Download assignments-module2.pdf | |
| 3 | assignments-module3.pdf Download assignments-module3.pdf |
Assignment Workflow
All assignments you do in this course will be stored, worked on, and handed in through KTH's hosted version of GitHub. Some of the assignments also have automatic online grading. This page describes the intended workflow.
Getting Started
Your repository is available at https://gits-15.sys.kth.se/ID2202-2024/id2202-<your-kth-username> (when the course starts). Initially, it contains a README, a directory of templates in various programming languages ("template-projects"), and a solutions folder in which you will place your code ("solutions"). Clone the repository so you can work on it locally. You should only edit files in the "solutions" folder and treat other files as read-only. We will push individual assignments and code for peer-reviewing to your repository, which may overwrite what you did or result in conflicts.
Let's try out the automatic grading. Your repository contains templates for the programming languages we support. Copy the template of your choice to solutions/hello and move into this directory. For example, if your language of choice is OCaml, the process is as follows:
$ cp -r template-projects/ocaml/ solutions/hello
$ tree
.
├── README.md
├── solutions
│ └── hello
│ ├── hello.ml
│ ├── Makefile
│ └── README.md
└── template-projects
# <...>
$ cd solutions/hello
The templates contain a small hello world example, which can be built (using make) and executed (using ./hello). Each template has its own README file with language-specific instructions. Make sure to read these as well to understand how to reuse the template for later assignments.
We submit the code to the automatic grader by pushing a commit whose message contains the grading tag "#hello":
$ git add .
$ git commit -m "First commit #hello"
$ git push
The grader clones your repository, builds it using make, and executes it. You get feedback from the grader as a comment on the commit itself (in your repository on gits-15):
Success! If we were to edit the program to print something else (by modifying "hello.ml") and commit and push the changes as before, the tests fail:
In case a test fails, you get detailed information on the purpose of the particular test. For later assignments, the grader may also include the provided input and expected output values for up to three test cases.
Actual Assignments
The assignments will specify which subdirectory of the "solutions" directory your code should be placed in and which grading tags should be used (when applicable). Each assignment will also state what the executable should be named; the README in your chosen template specifies how to change this.
You should test your code yourselves before submitting it to the grader. This is particularly important close to deadlines, when the grader may otherwise become overloaded. A big part of software engineering is figuring out how to properly test your code. The automatic grader should be seen as a sanity check and an extra help for us to verify that your implementation is (most likely) correct.