CSO Programming Assignments

Cloning your git repo

Type the following in your virtual machine:

$ cd ~ 
$ git clone https://github.com/nyu-cso-17fall/labs-<YourGithubUsername>.git
$ cd labs-<YourGithubUsername>

You will see that a directory named labs-<YourGithubUsername> has been created under your home directory. This is the git repo (short for repository) for your lab assignments throughout the semester.

Setup upstream repo

The skeleton code for this lab and future assignments are kept in the cso17-labs managed by the course staff. Therefore, the first thing you need to do is to set up your own lab repo to track the changes made in the cso17-labs repo. In the git world, cso17-labs would be your "upstream" repo from which changes flow into your own lab repo.

Type git remote add to add the upstream repo, and git remote -v to check that cso17-labs is indeed an upstream for your own lab repo.

$ git remote add upstream https://github.com/nyu-cso-17fall/cso17-labs.git
$ git remote -v
origin	git@github.com:nyu-cso-17fall/labs-xxx.git (fetch)
origin	git@github.com:nyu-cso-17fall/labs-xxx.git (push)
upstream	https://github.com/nyu-cso-17fall/cso17-labs.git (fetch)
upstream	https://github.com/nyu-cso-17fall/cso17-labs.git (push)

Immediately, you should check if the upstream cso17-labs repo has additional changes not present in your repo. You can check for and merge in those changes by typing:

$ git fetch upstream
$ git merge upstream/master

You should perform the above two steps periodically to ensure that you've got the latest lab code. We will also remind you to fetch upstream if we do changes/bug-fixes to Lab1.

Completing the lab

Go to this lab's sub-directory by typing:

$ cd lab1

This lab contains six independent exercises. The instructions for each exercise can be found in files part1.c, part2.c, ..., part6.c. Fill in your code in each of the files and test them individually. For example, suppose you have completed the exercise in part1.c. Test by typing the following:

$ make
$ build/part1
variable should be 5, actually is 3!
Aborted

From the above error message, you can see that it did not pass the test. Debug and try again. Complete and test each part individually.

Once you've passed the tests for all six labs, you can double check your test-passing status by typing:

$ ./grade-lab
basic [part1.c]: 
  set_to_five: OK
  array_sum: OK
bubble sort [part2.c]: 
  swap: OK
  bubble_sort: OK
prime sieves [part3.c]: 
  initialize_array: OK
  mark_multiples: OK
  prime_number_sieves: OK
  find_smallest_divisor: OK
point structure [part4.c]: 
  set_point: OK
  point_dist: OK
linked list [part5.c]: 
  list_insert: OK
  list_end: OK
  list_size: OK
  list_find: OK
  list_remove: OK
bitwise operators [part6.c]: 
  get_exponent_field: OK
  clear_msb: OK
  bit_at_index: OK
Score: 90/90

The above shows the example output of a successful full test.

Debugging Lab1

Below is our set of advice on how to go about debugging common problems you've seen in Lab1:

Whenever you've changed a file, always type make to re-compile before executing again.

It's a good practice to write your own test code. Don't rely solely on the lab's testing infrastructure (i.e. ./grade-lab) to test the correctness of your code. This is because we do not distribute the source code of those test code (hence you will only see clab/static/part1_harness.o and not /clab/static/part1_harness.c).

Let's say you want to test the array_sum function in file part1.c. To write your own test code, create a file (e.g. called test-part1.c) with a main function that invokes array_sum in various ways to test its correctness.

An example test-part1.c might look something like this.

Compile your test code by typing:

$ gcc -std=c99 test_part1.c part1.c

An essential debugging tool that you should use is gdb, esp. when you hit a ``segmentation fault''. Let's say you have a segfault on part1. Invoke gdb by typing:

$ gdb build/part1
(gdb) bt

bt is the gdb command to print the stack trace which tells you where the problematic execution occurs and how the program got there. Recitation has covered the use of gdb. There are also many tutorials online on gdb.

Saving changes while you are working on Lab1

As you modify the skeleton files to complete the lab, you should frequently save your work to protect against laptop failures and other unforeseen troubles. You save the changes by first "committing" them to your local lab repo and then "pushing" those changes to the repo stored on github.com

$ git commit -am "saving lab1 changes"
$ git push origin

Note that whenever you add a new file, you need to manually tell git to ``track it''. Otherwise, the file will not be committed by git commit. Make git track a new file by typing:

$ git add <my-new-file>

After you've pushed your changes with git push, they are safely stored on github.com. Even if your laptop catches on fire in the future, those pushed changes can still be retrieved. However, you must remember that git commit by itself does not save your changes on github.com (it only saves your changes locally). So, don't forget to type that git push origin.

To see if your local repo is up-to-date with your origin repo on github.com and vice versa, type

$ git status

Handin Procedure

To handin your files, simply commit and push them to github.com

$ git commit -am "saving all my changes and handing in"
$ git push origin