Before the lab
Before every lab in this course, you will be given tasks to complete. These will generally be easy tasks like watching videos, but you need to complete them in order to keep up with the class.
Command Line Familiarity Check
In an FCS linux lab (remote or locally) log in, and open a terminal.
Make a directory
Create a file in that directory using one of the available text editors
Now clean up, removing the file and the directory.
If any of this was new to you, then please take the time to go through parts 1 to 5 of the Learning the Shell Tutorial.
Read the course syllabus.
The Course Syllabus is available on line. Please read it, and bring any questions you have about it to the first lab.
Background Reading
For every lab there will be some related reading. I'll point these out as we go through the lab, but I'll also collect them at the start of the lab in case you want to get a head start (or refer back to them later).
About the course
- Time
- 10 minutes
- Activity
- Q&A, discuss course syllabus.
What's similar to other CS courses you've taken?
What's different?
Key point, how are labs evaluated?
Getting started with racket
Open a terminal.
Make a directory called
cs2613that will keep all of your work (note that case and spaces matter in Linux and this is not the same asCS2613orCS 2613. For the rest of this course we will assume it is directly under your home directory. The shortcut~/cs2613will refer to this directory in the lab texts and in the shell.
Hello Racket World
- Time
- 20 Minutes
- Activity
- Group walkthrough
Open a terminal
Make a directory
~/cs2613/labs/L01(if it does not already exist) and change there withcdSave the following code to
~/cs2613/labs/L01/hello.rkt
#lang htdp/bsl
"hello world"
(* 6 7)
Command Line
run the program with
$ racket hello.rktWhat is the difference between the first and second line of output?
compile the program
$ raco make hello.rktrun the program again
$ racket hello.rktcan you tell any difference? (hint, consider the "time" command).
DrRacket: A Racket Specific IDE
Start DrRacket from the activities menu
Referring to the DrRacket documentation as needed, open and run the
hello.rktprogram from the previous part.What is the meaning of the first line of the file?
Setting up a git repo
- Time
- 20 minutes
- Activity
- Individual work
- Summary
- This is where we create the git repository used for the rest of the term to hand things in.
Change to
~/cs2613. This directory should have one subdirectory calledlabs, which has the results of our experiments with racket.Create the git repository
$ git init -b mainGit will reply with something like
Initialized empty Git repository in /home1/ugrads/$username/cs2613/.git/You’ve now initialized the working directory — you may notice a new directory created, named ".git". You should mentally replace "$username" with whatever the login name is that you use to log into the FCS linux machines.
Read the git-quickref page, and follow the initial configuration steps there.
- note that the "--wait" option for gedit is important here.
Next, tell Git to take a snapshot of the contents of all files under the
labs, with git add:$ git add labs
- Notes
- Many revision control systems provide an
addcommand that tells the system to start tracking changes to a new file. Git’saddcommand does something simpler and more powerful: git add is used both for new and newly modified files, and in both cases it takes a snapshot of the given files and stages that content in the index, ready for inclusion in the next commit.
This snapshot is now stored in a temporary staging area which Git calls the "index". You can permanently store the contents of the index in the repository with git commit:
$ git commit
This will open and editor and prompt you for a commit message. Enter one and exit the editor. You’ve now stored the first version of your project in Git. See §5.2 of Pro Git for some hints about writing good commit messages. As mentioned in the class git policy, you will be marked on your commit messages, so you may as well get started with good habits.
Pushing to a central repo
- Summary
- Learn how to upload your work to a server
- Time
- 20 minutes
- Activity
- Individual work
- Notes
- You absolutely have to understand this before continuing in the course, since all marks in the course will be based on work pushed to the coursegit repos.
Since we are using the FCS git repositories there is an existing repository for all students who registered early enough. If it turns out there is no repository for you, you may need to do the last step later.
First add the
remote. This something like a nickname for the URL where the repo will be stored.$ git remote add origin https://$username@vcs.cs.unb.ca/git/cs2613-$usernameorigin is the default name for a remote, but we could have used a different name here. Replace
$usernamewith your FCS Linux account name.Now upload your local copy of the repo.
$ git push --all originyou should see something like
Counting objects: 388, done. Delta compression using up to 8 threads. Compressing objects: 100% (350/350), done. Writing objects: 100% (388/388), 71.63 KiB | 0 bytes/s, done. Total 388 (delta 223), reused 59 (delta 33) To https://$username@vcs.cs.unb.ca/git/cs2613-$username e7e5311..f1ae959 main -> main
Git Tutorial Continued
Making Changes in git
- Time
- 15 minutes
- Activity
- Individual work
- Summary
- Get some practice commiting your changes to git.
Change to the root of your git repository (~/cs2613).
Start by finding the right files to edit with
$ git grep hello
git grep is a very useful (and fast!) tool to find occurrences of strings in your git repository. Notice in the output there are some Binary files created by racket; we will clean those up later.
Edit the non-binary (source code) file, and change the output message.
Use git add to stage your changes:
$ git add file1
(replace file1 with the actual file you modified). You are now ready to commit. You can see what is about to be committed using git diff with the --cached option:
$ git diff --cached
or $ git diff --cached --stat
To undo the effect of a git add command, run git reset.
(Without --cached, git diff will show you any changes that you’ve made but not yet added to the index.) You can also get a brief summary of the situation with git status:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: file1
# modified: file2
# modified: file3
#
The git-rubric requies to begin the commit message with a single short line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git.
If you need to make any further adjustments, do so now, and then add any newly modified content to the index. Finally, commit your changes with:
$ git commit
This will again prompt you for a message describing the change, and then record a new version of the project.
Alternatively, instead of running git add beforehand, you can use
$ git commit -a
which will automatically notice any modified (but not new) files, add
them to the index, and commit, all in one step. Keep in mind that you
will be marked on the logical structure of your git commits,
so you are better off using git add to explicitely choose what
changes to commit.
Cleaning up generated files
- Time
- 15 minutes
- Activity
- Individual work
- Summary
- Get some practice commiting your changes to git.
A common phenomenon in software development is the existence of generated files. These files are created by some tool, typically based on some source files. In general it is a bad idea to track generated files in version control because they introduce spurious changes into history. We'll look at this more later, but for now let's try to clean up. We can often find what files are generated by re-running the build process. In our case
$ cd ~/cs2613/labs/L01
$ raco make hello.rkt
To find out what changed, run
$ git diff --stat
All going well, you will two modified files. You can delete them using git rm. As with with other changes, you can preview your changes with git diff and git status.
When you are satisfied with the changes, run git commit.
Before next lab
- Make sure you can push to coursegit from an FCS linux machine. A good way to test this is to push your work for Lab 1.
- Test that your push was successful by cloning the repo, per the instructions in faq.
- Read about how to write a good commit message in §5.2 of Pro Git
- Read Section 2 of FICS
- Read the first two sections of Stepper documentation
- Read the documentation for check-expect, check-random, check-satisfied, check-within, check-error, check-member-of, check-range