CSCI-UA.0480 Spring 2016 Lab 0: Set up and preliminaries

Released Monday, January 25, 2016
Due Friday, Friday, 29, 2016, 7:00 PM

Lab 0: Set up and preliminaries

It is not possible to take late days on this lab!

Introduction

This lab will walk you through the process of setting up our development environments. It will also walk you through the process of integrating with the class's "organization" on github; this is crucial, since we will be using github for lab distribution (us to you) and submission (you to us).

Most of the work you will do will be on remote machines or machines you can interact with only via the command line. As a result, you will have to use a command line based editor. Two popular editors are vim and emacs. To edit a file, you would type:

$ vi myfile.txt

# or 

$ emacs myfile.txt

Each has its benefits; ideally you should try both and figure out which editor best suits you. To get started, work through either this vim tutorial or the emacs tutorial that is built into the editor. (From within emacs, you can pull up the tutorial by typing C-h t. This is read as "press [ctrl]-h, then let go, then press t".)

If you're unfamiliar, spend at least an hour just navigating and editing sample text. You'll find that within a day or so, you'll have the required keystrokes internalized, and within a few days, you'll probably be faster at common editing tasks.

There will be two separate working platforms this semester: machines provided by CIMS (short for Courant Institute of Mathematical Sciences, which is the home of the CS department) and a virtual Ubuntu server that we have set up. We will indicate at the beginning of each lab which platform the lab will be using. Below, you will set up both of them.

Part 1: Setting up the work environments — CIMS workstations

Exercise Go here and follow the instructions for setting up your CIMS account.

Question 1. On any CIMS machine, run the command lscpu. Write down both the hostname (server name) of the cims machine on which you ran this, along with the entry for CPU family. You will have to submit this information to us in the last part of this lab.

Part 2: Setting up the work environments — Virtual devbox

Exercise Go here and follow the instructions for setting up the virtual machine.

For the next question, the hostname can be read from the command line. It follows the username of the logged in user and precedes the current directory's name.
httpd@[hostname]:~$ _

Question 2. Write down the hostname of the virtual machine we provided. You'll need to submit this information later too.

Part 3: Connecting to us on github and using git

We'll be using the Git version control system and github to distribute all of the files you'll need for this course. This requires that you be part of the cs480 organization on github, which in turn requires that all of you have a github account.

Exercise Go here and follow the instructions for setting up an account on github if you don't already have one.

Question 3. What is your github username? If we go to https://github.com/[username] we should not see the number '404' in a banner (as you do here, for example). We'll learn the significance of the number '404' soon.

Cloning the repository

Perform the following steps on the virtual machine you set up in the second part of this lab. Login as httpd.

Exercise Unless you are 100% comfortable with git, read Eddie Kohler's excellent introduction to git. Where this page mentions code.seas.harvard.edu:~kohler/cs61/cs61-psets.git, read that as github.com/nyu-cs480-16sp/lab0.git (you cloned from there, above). Where it mentions "the CS50 appliance", read that as our two development platforms (the CIMS machines and our virtual devbox).

Do not skip this exercise. Procrastinating competence in git will lead to hours and hours of misery later in the semester (or even next week). And eventually you will come to understand git the hard way. But you don't want to know what the hard way is. Trust us. Get fluent in git now.

Life with git will be far easier at first if you use a graphical browser. Gitk is a good one that is installed on the lab platforms. Just type gitk while you are in a git repo (if you haven't heard the term "repo" before, it's short for "repository"; we and many others sometimes use this abbreviation).

Below are some exercises on git.

Exercise First, go to the ~/lab0/ directory on your virtual machine and type make setup. 
$ cd ~/lab0
$ make setup
+ cp /home/httpd/resources/submit.py /home/httpd/lab0
$

Now run git status to view the current state of the repository.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   answers.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        submit.py

no changes added to commit (use "git add" and/or "git commit -a")

Add the untracked file to the repository by typing:

$ git add submit.py

This lets git know you want to track the submit.py file. Add the modified file as well:

$ git add answers.txt

This lets git know you want it to keep track of the changes you've made to the answers.txt file. Check the status again:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   answers.txt
        new file:   submit.py

You can commit this change by doing the following. The text within the quotation marks is a message that is stored along with the commit for future reference.

$ git commit -m "Added the submit.py file to the repository and updated answers.txt."

On your first commit, you may see the following message:

$ git commit -m "Added the submit.py file to the repository and updated answers.txt."

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
....

This is expected. Follow the instructions to run the two commands and re-commit.

$ git config --global user.email "<your email>"
$ git config --global user.name "<your name>"
$ git commit -m "Added the submit.py file to the repository and updated answers.txt."
[master abdd69f] Added the submit.py file to the repository and updated answers.txt.
 2 files changed, 49 insertions(+), 3 deletion(-)
 create mode 100755 submit.py

$ _

The string following "master" may be different as may the number of insertions and deletions. This is okay.


Exercise

In the ~/lab0/ directory on your virtual machine, type:

$ git checkout -b git/a origin/git/a
Branch git/a set up to track remote branch git/a from origin.
Switched to a new branch 'git/a'
$ ls
merge.c

This creates a branch named git/a from the remote branch origin/git/a which is hosted on github.com. It should contain a single file, merge.c. You can compile and run this file by typing:

$ make merge  # To compile 
$ ./merge     # To run

Now, we will create another branch called git/b with its own copy of merge.c. Type:

$ git checkout -b git/b origin/git/b

# compile and run the new version

$ make merge
$ ./merge

One of the strengths of git is that it allows multiple users to work from the same repository independently from each other. Eventually, though, all of the work must be merged together into a final product. Usually, git will do this automatically for you; however, there are times when multiple users modify the same place in a file, in which case git cannot know whose work should be used (only a human can manually resolve a "conflict" of this kind). The two branches that you have just created have been set up so that they will cause exactly such a conflict when merging. Both here and throughout the semester, you must be careful: a botched merge is a reliable source of headaches. Type the following into a console:

$ git branch        # This will list all local branches
  git/a
* git/b
  master
$ git merge git/a   # Merge the current branch with the branch called 'git/a'
Auto-merging merge.c
CONFLICT (content): Merge conflict in merge.c
Automatic merge failed; fix conflicts and then commit the result.

Exercise Find out what the parent version of merge.c does, then resolve the merge conflict so that the merged file behaves the same as the parent version. By 'parent version', we mean the original version of the merge.c file before either developer A or developer B edited it and pushed code to their respective branches. Don't forget to add the modified file and commit the merge when you are done.

Make sure your merged merge.c compiles and runs correctly.

To access the answers.txt file, you'll need to checkout the master branch again. 

$ git checkout master

You'll see a notice message that you are ahead of origin/master. Ignore it.

Question 4. What does your merged program print?

Question 5. Please provide us with a copy of your public key here. If you're on an OS X / Linux system, you can do this by: 
$ cat ~/.ssh/id_rsa.pub
ssh-rsa ABCAB3N ....
...
...

# or if you specified a specific path name

$ cat /your/path/here/<keyname>.pub
ssh-rsa ABCAB3N ....
...
...
Make sure to copy the entire contents of your call to cat.

Question 6. How long did this lab take you (including all of the setup)?

Handing in the lab

Here's a checklist before you submit: This completes the lab.

Last updated: 2016-04-15 16:24:03 -0400 [validate xhtml]