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
directory (where the string
username should be replaced with your username) and then run the
$ 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
paN directory, respectively,
N will be 1, 2, 3, etc. (i.e.,
The directory will include a
README.txt file with a description
of the files contained in the directory. Make sure to always read
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.
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
commit -m"some message" and
git push to upload your changes to
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)
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 : %load_ext autoreload In : %autoreload 2
%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
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:
Request a repository using
chisubmit. Let’s say that users
amrwant to register as a pair.
borjaruns 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
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).
amralso 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)
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.
Setup repositories: Both students should run this command on the CS Linux machines:
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.