This page provides answers to some commonly asked questions. Feel free to use the mailing list if you cannot find an answer here.

Logging to GNU/Linux machines in Rotunda lab

You will need a Secure Shell (SSH) client. On GNU/Linux machines, the SSH client is typically part of a base installation, so you should be able to simply run the ssh command. On Windows machines, you need to install an external client. We recommend using PuTTY, but feel free to use any other client.

Connect to u-plN.ms.mff.cuni.cz (where N is a number between 1 and 23) using your SIS credentials (i.e. the same username and password).

Note that machines in Rotunda use AFS and Kerberos and thus it is not possible to setup a login via a public SSH key.

Logging to the lab machine

Connect to port 22004 (standard SSH port + course code) of the machine lab.d3s.mff.cuni.cz using your SIS credentials.

Consider adding the following fragment to your ~/.ssh/config to simplify the login to bare ssh nswi004.

Host nswi004
    HostName lab.d3s.mff.cuni.cz
    User YOUR_SIS_LOGIN
    Port 22004

Note that this machine contains all that is needed to compile and run the assignments.

Keeping your fork up-to-date

Most of the (later) assignments and the self-study material will be published in form of changes committed to the respective upstream repository. You are expected to merge these updates into your private repositories. When you view your private repository in GitLab, the corresponding upstream repository will be shown as the repository you Forked from.

For example, when we add a new before-lecture quiz, we will commit the changes to the upstream/grading repository and announce the update in the mailing list.

To merge these changes into your grading-LOGIN repository for the first time, you need to perform the following steps (for subsequent updates, you will only need to perform the last 3 steps):

  1. Clone your private repository and/or change to the directory with the clone.

    git clone git@gitlab.mff.cuni.cz:teaching/nswi004/2020/grading-LOGIN.git

    cd grading-LOGIN

    You need to be inside the clone directory for the subsequent steps.

  2. Add a remote pointing to the upstream repository.

    git remote add upstream git@gitlab.mff.cuni.cz:teaching/nswi004/2020/upstream/grading.git

    This only needs to be done once per clone.

  3. Fetch changes from the upstream repository.

    git fetch upstream

  4. Merge the changes.

    git merge -m "Merge upstream changes" upstream/master

    Git will respond with an "Already up to date." message and do nothing if there is nothing to merge.

  5. Push the merged changes from your (local) clone back to your private repository on faculty GitLab.

    git push

Introductory materials

Following materials from NSWI170 (Computer Systems) might be useful for refreshing your knowledge of the C language and basic principles of program execution.

How are activity points counted?

Activity points are computed for the whole semester from the team assignment repository (i.e. those 20 points are not required for each assignment but for all assignments together).

To compute the actual values, we look at each commit in the master branch or in a branch that was already merged into master (and pushed to GitLab, obviously).

We look at commit author (usually your e-mail address) to assign commits to individual team members. You should see list of your e-mail addresses in GRADING.md (and contact us via teachers-nswi004 e-mail if you need to add another alias there).

Using commit date and author we group the commits by date and committer to compute commit count points.

We look at number of added lines in C source files, C header files and assembler files to compute points for lines of code. We do not check whether the code was later changed by another team member. That is - refactoring code of your team mates will not subtract their points but only add new ones for you. Note that Git has no concept of a changed line: changing a line means one line was removed and one was added.

We decided to count only files matching *.[chS] to simplify filtering situations when some teams managed to commit log files or the whole target subdirectory, thus gaining hundreds of points with every commit.

Looking at source code statistics from previous years we believe the limit of 20 points to be a reasonable value that should catch extreme situations only and otherwise shall be trivial to reach after several assignments.

However, we will not be very happy if a team member gathers enough points by porting his printf implementation for A02 and then doing nothing for the rest of the semester.