CSC 200 2014 Undergraduate Problem Seminar

Course Description

In computer science curriculum, a typical course in computer systems focuses on a single layer of a system.  This course teaches cross-cutting issues in the construction of multi-component designs.  The content is eclectic and instruction problem-driven.  Students are guided to solve four problems: advanced modularization, type specification, concurrent data structures and cache performance, to learn the principles of composition in different subfields of computer science.  

As software and hardware become more powerful, they are increasingly complex and intra- and inter-connected.  This complexity is possible because of the continued advance in computer systems research.  The course selects four fundamental advances in the last two decades (much of them originated here in URCS) and teaches them under the theme of compositional problems and solutions covering the essentials from static organization to dynamic adaptation, collected as a synthesis and practiced as an exploration.

Assignments: There is no single textbook and source of reading.  Students must come to class.  Reading material includes papers and links to library and online resources and is given in lectures.  The assignments consist of individual and group programming projects, project reports and presentations.   Students are always encouraged (with extra credits) to find topics of interest and explore, individually or as a group, beyond what is covered in lectures and assignments.

Prerequisites: Data structures and basic algorithms (172 or equivalent).  Basics of C or Java programming on Linux.  Formal systems, e.g. lambda calculus, and programming language design and implementation, i.e. 254, are not required but highly encouraged.



Instructor

Instructor: Chen Ding, Prof., CSB Rm 710, x51373
Lectures: Wednesdays and Fridays, 11:50am-1:05pm, CSB 632
TA: Joe Izraelevitz, CSB Rm 624. jhi1 [at] cs [DOT] rochester [DOT] edu
Office hours: Chen - by appointment (use email).  Joe - Wednesday, Friday 1:05 pm-2:00pm



Course Repo

For this class, we will be managing all code in version control software (Mercurial).  All provided assignment code will be distributed using this software, and all projects will be turned in using it  (so please make sure you understand how to use the software!)


What is version control?

Version control software allows several people to work on and share a project, while also providing a method of recovering previous version in the case of problems.  In this class, we will be using Mercurial (also known as hg). 

On the undergrad network, we will host a shared repository, which holds all class code.  On your personal machine, you can check out a copy of this code into a local folder, modify it, and then check it in.  To save changes to the code, you commit, taking a snapshot of your progress and creating a save point you can go back to.  To copy the code to your local machine is called a pull, whereas to send in your changes is a push

In Mercurial, we can keep track of changes to the project in branches.  Branches allow different versions of a project to exist independently - for instance, two developers might try two vastly different (and incompatible) methods of implementing a new feature.  While they are stilll developing, their changes should be isolated from the main project - after all, we shouldn't add features until they work.  Eventually one might be accepted into the main project, at which point we will merge their changes with the main (default) project.

In our class, we will release assignments on the default branch in the class repo.  Each student will have their own branch.  When we release assignments, you will merge the assignment into your branch.  When you complete the assignment, you will commit your changes and push the code back to the shared repository.

Some more resources on Mercurial:

  • Mercurial's "Beginners Guides", where you can go for instructions on downloading, and tutorials.
  • Mercurial's "Quick Start Guide", for when you have it installed and are ready to "clone" the repository.

 

Setting up your local repository:

Before you start, make sure that you have an account on cycle2.csug.rochester.edu. If you need an account, please see Marty Guenther. 

First, we need to configure hg to use associate your name when tracking code changes.  To do this, create a file in your home directory ~/.hgrc and add the following:
[ui]
username = First, Last <email@somewhere.com>

Second, create a directory to keep your local repository.  For instance, on Linux:
mkdir cs200repo

Third, navigate to this directory:
cd cs200repo

Fourth, clone the shared repository onto your local machine (don't forget the dot):
hg clone ssh://my_csug_username@cycle2.csug.rochester.edu//u/cs200/cs200repo .

Next, create a new branch with your name and switch onto it:
hg branch myusername

Finally, commit your new branch, creating a checkpoint, and give it a good description:
hg commit -m "Added new branch: myusername"

Some people have had trouble getting permissions working correctly checking out the repo.  Specifically, they get an error message like: "not trusting file /home/hoover/u/myusername/cs200repo/.hg/hgrc from untrusted user 4294967294, group none".

This appears to be an NFS issue due to the way cycle1/2.csug are set up.  When you create files on cycle1/2.csug, sometimes there's a permissions hiccup and the files end up being owned by the anonymous user (4294967294).  A better workaround right now is to change to owner of your repo to you, then continue.  More to follow to get a better solution so that this doesn't happen.

To change the owner of the directory, navigate to your checked out repo (mine is at ~/cs200repo):
cd ~/cs200repo

Confirm you are not the owner of the files using:
ls -la
You'll see output like:
drwxr-sr-x 3 4294967294 none 4096 Sep  7 11:09 .
drwxr-sr-x 7 4294967294 none 4096 Sep  7 11:08 ..
drwxr-sr-x 5 4294967294 none 4096 Sep  7 11:09 cs200repo

If you see the 4294967294, you're having the ownership problem.
To change the owner of the files in the directory to you, use the command:
chown -R yourusername .


Getting assignments:

Since assignments are released on the default branch, you need to merge the assignment code into your branch (after the first assignment).  To do this, first make sure you are on your branch:
hg checkout myusername

Next, pull the changes to the repository, including the new assignment:
hg pull

Next, merge the changes from the default branch into your branch.
hg merge default

Finally, commit your merge.
hg commit -m "merge from default"

If you take a look in your repository now, you'll see the new assignment.

Some people have had problems getting messages like: "abort: uncommited changes" when merging.  This means you have made changes to your repo, but have yet to tell mercurial about them.  Use hg status to get information on which files have been changed since the last commit.  The letters on the left indicate what sort of changes have occurred. 
M this_file_was_modified_since_the_last_commit.txt
? this_file_is_untracked_by_mercurial_(you_might_need_to_add_it).txt
! this_file_is_tracked_by_mercurial_but_is_now_missing_(you_might_need_to_remove_it).txt
A this_file_was_added_since_the_last_commit.txt


Submitting assignments:

To submit an assignment, first make sure you have added all your files to the repo:
hg add somefile.txt
hg add someotherfile.txt
hg add makesureyouaddallyourfiles.txt

And saved your changes in a commit, and provide a comment to make sure you (and the TA) know what it is your are committing:
hg commit -m "A commit message, e.g. Finished assignment 1: Summarize Silver Bullet"

Next push your changes to the remote repository so the TA can grade it:
hg push

Note that the first (and only the first) time you submit, you'll need the --new-branch flag to signal a branch creation in the shared (remote) repository.
hg push --new-branch