CS314: Tutorials

  • Marks will be given for
    • Successful completion of tutorial requirements, but also
    • Structured and neat repos; e.g., delete old/duplicate files/directories; use a .gitignore file to make sure that compilation and execution output files are not added to the repo (unless explicitly needed for an analysis section of a report, for example). Basically, any temporary files that are created every time you build and run the program.
    • A proper Makefile for each tutorial.
      • For more information on Makefiles, see the GNU make tutorial.
      • If your Makefile stores object files in an obj directory, add a command that will create the directory if it does not exist.
      • Use a DEBUG flag and define it in your Makefile -DDEBUG to turn on the printing out of DEBUG info.
    • A sensible and useful Readme in each tutorial or project directory.
    • Sensible comments in your code.
    • A run.sh script that runs your program with the correct command-line parameters
    • Following good programming principles: descriptive names for files/functions/etc., proper memory management, logical structure, using command-line parameters as input rather than hardcoded values, proper usage messages when the wrong command-line parameters are given, etc.
  • A hardcopy of the Plagiarism Declaration must be signed for each tutorial and each project.
  • Please familiarise yourself with the University's Code of Conduct for Computer User Areas so that you can adhere to it at all times.


  1. Implement small pieces of functionality at a time and test it thoroughly before implementing the next piece.
  2. Before each submission, check that your repository is up to date (remember that marks are subtracted for late submissions). You can check the status of you repo with: git status .
  1. Navigate to the CS git repo.
  2. Log in using the US Single Sign-on button.
  3. Add your SSH key to gitlab (if not yet addded)
    • Click on your Avatar in the top right-hand corner and choose Settings
    • In the "User Settings" pane on the left-side, click on SSH Keys
    • Follow the instructions to add a key:
      • If you do not have a public key ('~/.ssh/id_rsa.pub'), because it was deleted or you have not created one before, then first click on the generate link that will take you through the steps to generate a new key.
      • Copy and paste your public key in the provided box.
  4. Goto the project that was created for you: <su-number>-rw314
  5. Follow the steps to:
    • Set up your name and email address.
    • Clone your project.
    • Touch, commit, and push your readme. Please note the arguments to use the first time you push to a new repo.

Trouble Shooting

If you cannot clone your repository

e.g., Error: sign_and_send_pubkey: signing failed: agent refused operation

  1. First run ssh-add
  2. If it still does not work you might have copied the wrong public key, entered the wrong password, or have the wrong file permissions. During key generation, make sure that you press enter to use the default directory (.ssh) -- if you entered a directory name (using your student number, for example) to store the new ssh key and then copied your old ssh key from the .ssh directory, your new password will not work.
  3. If it still does not work. Set the environment variable as below:
    Literally, issue the above in the terminal; it will effectively bypass the Gnome keyring daemon which caches the keys so the user doesn't have to put the password in each time they access the key. This will need to be done on each terminal session (or can probalby be added to your .profile file). The Narga administrator is planning to fix this.
TroubleShooting FAQs
See The troubleshooting section of the git-beginners pages on gitlab.
If you struggle with Git, you can learn more at the following links
  1. Before:
    • git pull
    • this is important if your previous working session was at a different location (e.g., at home and you are now in the lab)
  2. During:
    • If you are starting with a new tutorial or project, first create a directory for that tutorial, called tut1, proj1, tut2, tut3, ..., and proj2; otherwise continue where you stopped during your previous working session.
    • During each working session: it is useful to use git when deleting or moving files that are in version control, for example
      • instead of mv old_name.txt new_name.txt, use git mv old_name.txt new_name.txt
      • instead of rm no_longer_needed.txt, use git rm no_longer_needed.txt.
  3. After:
    • git add . (or git add "all new file/dir names")
    • git commit -m "Appropriate message"
    • git push (unless it is your first commit for this repo, then use git push -u origin)


Always use descriptive commit messages and when you have a full working version, create a tag, so that when you break something you can easily find and checkout a previous working version.