Coursework Basics

This page contains information that is common to all the exercises and programming assignments, and which you may find useful as you work through them.

Getting the assignment’s files

Every assignment has a series of files you will need to complete the assignment, including some skeleton code as well as the automated tests for the assignment.

So, before you can start working on an assignment, you will need to get those files into your git repository (please note that it is important that you complete Lab #0: Linux and Lab #0.5: Git and chisubmit to learn the basics of Linux and Git before you start working on your first exercises).

To get the files for a programming assignment, change to your cmsc12100-aut-20-username directory (where the string username should be replaced with your username) and then run the following commands:

$ git pull
$ git pull upstream master

The first command just ensures that your local copy of your repository is in sync with the server. The second command is the one that actually fetches the instructor-provided files. Instead of pulling from your own repository, it pulls from a special “upstream” repository set up by the instructors.

If, after running git pull upstream master you are taken to a screen saying “Merge branch…”, see this entry in our Git FAQ.

Files for the exercises and programming assignments will appear in a seN or paN directory, respectively, where N will be 1, 2, 3, etc. (i.e., se1, pa1, se2, pa2, …). The directory will include a README.txt file with a description of the files contained in the directory. Make sure to always read this README.txt file.

Please note that it is always good practice to run git pull upstream master before you start working, as this will fetch any updates to the instructor-provided files. For example, we may occasionally update files if we notice bugs in our code, add helpful new test cases, etc.

Using git

Once you’ve fetched the assignment’s files, you can proceed as described in Lab #0.5: Git and chisubmit: work on your code and then run git add <filename> for each file you change, followed by git commit -m"some message" and git push to upload your changes to the server.

We suggest you add/commit/push every time you complete a specific piece of work, or once you’re done working for the day, so there will be a backup of your code in the Git server. Your commits should describe the work that you did as part of that commit, and should look something like this:

  • Finished Task 1

  • Made progress on Task 3, but not yet done

  • Fixed bug in Task 2. All tests pass now!

You should also make sure to run git pull and git pull upstream master before you resume work to retrieve the latest files. This discipline will guarantee that you always have the latest version of your code, no matter which machine you are using. Also, it will be easier for us to help you recover from git and chisubmit problems if you consistently push updates to the server.

That said, you should avoid using Git as a mechanism to synchronize your code across multiple computers. More specifically, let’s say you’re working on your own computer, and need to upload your files to a CS server to run the tests. You should not do this by pushing your code to the Git server from your computer, and then pulling it from the CS server.

In other words, if you find yourself frequently committing code with messages like “Uploading to CS server”, “Changing file to try on CS machine”, etc. and doing this multiple times while you’re working on your code, this is not how version control systems are meant to be used. A commit should represent a meaningful change in your code, and should not be used as a mechanism for copying files to another machine.

At the start of the quarter, we recommend that you simply work directly on a CS environment (e.g., by using the Virtual Desktop system). Once you’ve developed more comfort with using Linux, you can switch to working on your own computer, and using SSH to copy files from your computer to a CS server. You can find instructions on how to do this on the CS Techstaff’s website (see “File Transfer” in their Remote Access page). You can also set up you code editor to this automatically for you (we will be providing instructions on how to do this with Visual Studio Code soon)

Using IPython

It is important to experiment with library functions and try out your own functions by hand in ipython3. When starting IPython, you should make sure to always enable “autoreload”:

$ ipython3

In [1]: %load_ext autoreload

In [2]: %autoreload 2

The commands %load_ext autoreload and %autoreload 2 tell ipython3 to reload your code automatically whenever it changes. We encourage you to use this package whenever you are developing and testing code.

Style

Following a consistent style is important because it makes it easier for others to read your code; imagine if you were collaborating on a large software project with 30 other developers, and everyone used their own style of writing code!

In this class, we will be adhering to the CS Style Guide. We expect you to use good style (that is, style that matches this guide), and will take this expectation into account when grading

Working in a pair

Working with a partner can be a great experience, and one that more closely resembles the way in which software is developed in real projects, but working with another person can also be challenging. We encourage you take a look at the Working in Teams page of the CS Developer Guide, but please note that you should skip the “Using Git Effectively” section, as that section covers advanced techniques that are not relevant in this class.

If you are working in a pair on an assignment, you will need to request a repository for your pair. Here are the steps you will need to take:

  1. Request a repository using chisubmit. Let’s say that users borja and amr want to register as a pair. borja runs this command on a CS Linux machine:

    $ chisubmit student assignment register pa2 --partner amr

    Please note that you must run this command inside your existing cmsc12100-aut-20-username directory.

    And should see the following:

    Your registration for pa2 (Programming Assignment 2) is complete.

Your team name is 'amr-borja'.

The team is composed of the following students:

- Rogers, Anne (amr) UNCONFIRMED
- Sotomayor, Borja (borja)

Note: Some students have not yet confirmed that they are part of
      this team. To confirm they are part of this team, they just
      need to register as a team themselves (using this same
      command, and listing the same team members).

    amr also needs to register, to confirm that she wants to be on the team:

    $ chisubmit student assignment register pa2 --partner borja

    And she would see the following:

    Your registration for pa2 (Programming Assignment 2) is complete.

Your team name is 'amr-borja'.

The team is composed of the following students:

 - Rogers, Anne (amr)
 - Sotomayor, Borja (borja)

  2. Wait for email from GitLab to your UChicago email address saying that the group repository is ready. Take into account that your repository won’t be created until both of you have completed the registration instructions. Please note that the repository won’t be created immediately; however, if you both register and do not get an e-mail from GitLab (or don’t see the pair repository on GitLab) after an hour, please ask for help on Piazza.

  3. Setup repositories: Both students should run this command on the CS Linux machines:

    $ cs-setup-script cmsc12100-aut-20

    Similar to when you set up your individual repository, the script will present you with a list of repositories you have access to. This list should now include your pair repository. Just choose that repository from the list.

Please let us know if you have any problems.

When you work in a pair, it is very important to be disciplined about synchronizing your local copy of the repository with the server before you start working and again when you are done. It is very easy to find yourself with a nasty merge conflict, if you do not communicate effectively with your partner and if you let the code in your personal copies of your shared repository diverge significantly. See the FAQ for advise on how to deal with merge conflicts.