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, Haskell, Rust, Java, or C/C++. We recommend to use OCaml that supports a functional style of programming, although it is allowed to submit solutions in any of these languages. The programming assignments are released 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 how to develop and submit 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 at a later time during the course, but you will miss the deadline bonus.
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
You can find your repository at https://gits-15.sys.kth.se/ID2202-2022/id2202-<your-kth-username>. We have already initialized it with some templates and other structure we'll be using later. Make sure to look through it and read the README, then clone the repository, so you can work on it locally. Note that you should only edit things in the "solutions" folder, treat everything else as though it were read-only. We will push additional individual assignments later on, and potentially other updates, which will overwrite whatever you have done or create conflicts.
Next we test the automatic grading. In your repository, under "template-projects", you can find templates for each of the programming languages we support. Select your language of choice and copy its template to "solutions/hello", then "cd" into the directory. For example, for OCaml, the process would be the following:
$ cp -r template-projects/ocaml/ solutions/hello
$ tree
.
├── README.md
├── solutions
│ └── hello
│ ├── hello.ml
│ ├── Makefile
│ └── README.md
└── template-projects
# <...>
$ cd solutions/hello
Each template is populated with a small hello world example, which you can build using "make" and then run using "./hello". Note also that each template has its own README with language specific information, make sure to read this as well.
To submit this to the automatic grader we make a push where the commit message contains the grading tag "#hello":
$ git add .
$ git commit -m "First commit #hello"
$ git push
The grader will then clone the repository for itself, build your project, and then test it. You get feedback in the form of comments on the commit itself:
If we edit the program to print something different (in this case changing "hello.ml") and then commit and push the changes with "#hello" again the tests fail:
In this case you get a bit more explanation of what the test is about.
Actual Assignments
Each actual assignment will describe how you should work on it; which subdirectory of "solutions" it should live in, and which grading tags (if any) are relevant. Each assignment will also state what the executable should be called, see the README for each language template to see how to change it.
Note also that you should test things yourselves before submitting to the grader, a big part of software engineering is figuring out how to test things properly, the automatic grader is just there as a sanity check and an extra help for us to see that your implementation is correct.
FAQ
The grader missed a commit with a grading tag
The grader only ever looks at the latest commit on the master branch. If you push multiple commits at the same time it will thus not look at older commits. The same is true if you push from another branch than "master", such commits will also be ignored.
The grading tags aren't actually tags in the Git sense, why?
Since you need to be able to turn in the same assignment multiple times, in case you missed something the first time around, it was easier to just look for particular words in the commit message than use git tags. In particular, git tags have the following limitations:
- Git tags can only point at one commit at a time.
- Pushing them requires an extra flag to "git push".
- Changing which commit a tag points at requires a force push, which seems unwise to recommend as a default workflow.