This feed contains pages with tag "git".
Before the lab
- Complete the On your own part of L02
Background
- Beautiful Racket unit test explainer
- RackUnit QuickStart
- Racket Modules
- Pro Git on Debugging with git
Questions from last time
- Time
- 10 Minutes
- Activity
- Group discussion
In this part of the lab, we will discuss some questions from the On your own part of L02.
Git
- What is a remote?
- What is merging?
- What is a conflict?
Racket
- For those familiar with other IDEs, what's similar and what's different about DrRacket?
- What's the difference between a text editor and an IDE?
- What's a REPL?
Setup
- start the fcs-vm-cs2613-dev VM
- make a directory
labs/L03inside your~/fcshome/cs2613git repository - All of your work from today should be committed in that directory (and pushed before you leave).
The first / rest pattern
- Time
- 20 min
- Activity
- Programming by example
Section 2.3.2 of the Racket Guide gives several examples of recursively traversing a list, in particular
(define (my-map f lst)
(cond
[(empty? lst) empty]
[else (cons (f (first lst))
(my-map f (rest lst)))]))
This function uses a very important pattern, processing the first
element of the list with first and recursively processing the
remaining elements with rest. In this part of the lab you use this
example as a starting point to rewrite the rainbow example from
L02 to use explicit recursion (i.e. calling first and rest),
rather calling than map.
- Make an auxilary function
color-mapperthat takes two parameterspandcolor-listand calls(colorize p color)for each elementcolorofcolor-list.
#lang slideshow
(define (rainbow p)
(map (lambda (color)
(colorize p color))
(list "red" "orange" "yellow" "green" "blue" "purple")))
(define (rainbow2 p)
(define (color-mapper p color-list)
)
(color-mapper p (list "red" "orange" "yellow" "green" "blue" "purple")))
- Your function can steal the structure of
my-map
but you shouldn't call
mapormy-map - If you have extra time, repeat the exercise with
for/listinstead offirstandrest.
Unit Tests in Racket
- Time
- 20 min
- Activity
- Individual work
Unit testing is an important part of programming, and has inspired something called test driven development.
This part is based on an example from
RackUnit QuickStart. The
Beautiful Racket unit test explainer
is a better reference, since we'll skip some of the fancier features
of rackunit and move straight to having a test submodule.
copy file.rkt, save it as
~fcshome/cs2613/labs/L03/file.rktand commit it.add a test submodule with the following tests
(check-equal? (my-+ 1 1) 2 "Simple addition") (check-equal? (my-* 1 2) 2 "Simple multiplication")
run your "file.rkt" in
DrRacket; observe that one of the two tests fails.Fix the recursive definition of my-* so that it at least works for non-negative integers. There are several different approaches which work, one simple way is based on the cases
If
a = 0thena * b = 0if
a > 0thena * b = (a - 1) * b + b
Since we assume
a >= 0, you can combine those two cases into a singleiforcondexpressionObserve there is no output from the tests now when you run the code in
DrRacket. This means success. Commit this version of your code. Remember that git commit message quality counts in this course, so work on making commit messages.
Test Coverage
- Time
- 25 min
- Activity
- Individual work
This activity continues with the same file from the previous activity.
Under
Language -> Choose Language -> Show Details -> Dynamic Propertiesenable
⊙ Syntactic test suite coveragerun your code in
DrRacketagainmost likely you will have some code highlighted with orange text and black foreground. This means that code is not covered by your test suite. Add another test to cover each piece of uncovered code.
When you have complete test coverage, commit your code.
In this course, for all
racketassignments you will lose marks if you don't have complete test coverage.Push your repo to coursegit.
If you have extra time
- Run the tests on the command line with
raco test file.rkt - Read the first assignment A1
- Update your journal.
- Read about Debugging with git, particularly "binary search".
Git Bisect
- Time
- 25 minutes
- Activity
- Individual work
This part is based on Debugging with git, particulary the part labelled "Binary Search".
Make a directory
~/fcshome/lab3-scratchChange to
~/fcshome/lab3-scratch, and clone your coursegit repoin this clone (not your main
~/fcshome/cs2613directory), make 5 nonsense commits (e.g. add comments to the file), followed by a commit that breaks one of your tests, followed by 5 nonsense commits.Follow the example of using
git bisectin Pro Git, "manually" withgit bisect goodandgit bisect badTry running the
git bisect --run "raco test file.rkt"to automatically mark commits as good and bad.If you have extra time, use git revert to undo your bad commit.
On your own
- Time
- 20 min
- Activity
- Independent research
See if you can come up with answers to the following questions for next time.
The programming languages we will study this term are all dynamically typed. This means that not only the value but also the type of variables can change at runtime. Why does this make testing even more important?
What kind of software problems is testing not well suited to find?
Why might mutable state (e.g. instance variables in Java) make writing unit tests harder?
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 with the class.
Using the CS2613 Virtual Machine
Figure out your preferred method(s) of running the VM.
Watch the video tour of the CS2613 VM This video is from 2020, so a few things will be slightly different, in particular
- we won't be using remote access by default, so there is no "first video"
- vscodium is not installed in this year's VM.
Command Line Familiarity Check
In the cs2613 VM, start 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 marks assigned for the lab we're just starting?
Frog Tutorial
- Time
- 30 minutes
- Activity
- Individual work
- Summary
- Getting started with frog
We'll be using frog frog to keep a journal of what we learn in this course.
Make a directory under
fcshomethat will keep all of your work for cs2613. For the rest of this lab we'll assume that directory is~/fcshome/cs2613viewed from fcs-vm-cs2613-dev (or~/cs2613, viewed from your normal FCS Linux account).Follow the frog quick start to create a frog project in a directory
~/fcshome/cs2613/journal(in the tutorial this is calledfrog-projectrather thanjournal. Please make things easy on the TA by using the name specified here).Start a new blog page for today's lab, and delete the fake entry created by the frog setup command. Note that you may have to refresh the browser after running
raco frog -bp.
Git background
- Time
- 10 minutes
- Activity
- Reading, Discussion
Take a quick read of - Section 1.3 from Pro Git Don't worry if you don't get every detail now; you can always go back and re-read it later.
Answer the following questions in your journal:
What are two important concepts discussed in this reading?
Relate to previous experience; answer any of the following that apply. Note that at least one applies to everyone.
If you have used a version control system other than
gitbefore, what is one important difference between that system and git?If you have used git before, what is one thing about
gityou like, and one you don't?If you have never used a version control system before, what strategies have you used to keep versions of files?
- copies of files?
- track changes in an office suite?
Setting up a git repo
- Time
- 30 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
~/fcshome/cs2613. This directory should have one subdirectory calledjournal, which has the results of your experiments above with frog.Create the git repository
$ git initGit will reply
Initialized empty Git repository in /media/sf_FCS-HomeDir/cs2613/.git/You’ve now initialized the working directory — you may notice a new directory created, named ".git". The path starting with
/mediahas to do with with way that VirtualBox shared folders work.Read the git-quickref page, and follow the initial configuration steps there.
- note that the "--wait" option for gedit is important here.
- One important technical detail is that your home directory on fcs-vm-cs2613-dev is not preserved between reboots of the VM. For this reason you should not use --global configuration.
Next, tell Git to take a snapshot of the contents of all files under the
journal, with git add:$ git add journal
- 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.
If you have extra time, start the next part
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-<username>origin is the default name for a remote, but we could have used a different name here. ⟨username⟩ is 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 master -> masterIf you have extra time, start L02
Next steps
We'll pick next time with some more practice using Git, but you should have the bare minimum to hand in your work at this point. Don't forget that your first journal entry is due tomorrow.
Emacs
2018-07-23
- NMUed cdargs
- NMUed silversearcher-ag-el
- Uploaded the partially unbundled emacs-goodies-el to Debian unstable
- packaged and uploaded graphviz-dot-mode
2018-07-24
- packaged and uploaded boxquote-el
- uploaded apache-mode-el
- Closed bugs in graphviz-dot-mode that were fixed by the new version.
- filed lintian bug about empty source package fields
2018-07-25
- packaged and uploaded emacs-session
- worked on sponsoring tabbar-el
2018-07-25
- uploaded dh-make-elpa
Notmuch
2018-07-2[23]
Wrote patch series to fix bug noticed by seanw while (seanw was) working working on a package inspired by policy workflow.
2018-07-25
- Finished reviewing a patch series from dkg about protected headers.
2018-07-26
Helped sean w find right config option for his bug report
Reviewed change proposal from aminb, suggested some issues to watch out for.
2018-07-27
- Add test for threading issue.
Nullmailer
2018-07-25
- uploaded nullmailer backport
2018-07-26
- add "envelopefilter" feature to remotes in nullmailer-ssh
Perl
2018-07-23
- Tried to figure out what documented BibTeX syntax is.
- Looked at BibTeX source.
- Ran away.
2018-07-24
- Forwarded #704527 to https://rt.cpan.org/Ticket/Display.html?id=125914
2018-07-25
- Uploaded libemail-abstract-perl to fix Vcs-* urls
- Updated debhelper compat and Standards-Version for libemail-thread-perl
- Uploaded libemail-thread-perl
2018-07-27
- fixed RC bug #904727 (blocking for perl transition)
Policy and procedures
2018-07-22
- seconded #459427
2018-07-23
- seconded #813471
- seconded #628515
2018-07-25
- read and discussed draft of salvaging policy with Tobi
2018-07-26
- Discussed policy bug about short form License and License-Grant
2018-07-27
- worked with Tobi on salvaging proposal
Documentation
First, note that you can get documentation for a command such as
git log --graph with:
$ man git log
or:
$ git help log
With the latter, you can use the manual viewer of your choice; see git-help(1) for more information.
The man pages are also available online version
A good reference for git (other than the man pages) is The Pro Git Book.
Initial configuration
It is a good idea to introduce yourself to Git with your name and email address before doing any operation. The easiest way to do so is:
$ git config user.name "Your Name Comes Here"
$ git config user.email you@yourdomain.example.com
You may also want to configure an editor to use with git. The default on fcs-cs2613-dev is nano; most other places it is vim. Both are very fast to start up, but completely keyboard driven. If that doesn't suit you, you can configure the editor via
$ git config core.editor <something>
On the options for <something> include
- nano
- vim
- emacs
- "gedit --wait"
You can optionally used git config --global, but note this probably
won't work in an FCS VM.
Common Tasks
For a more detailed introduction, see gittutorial
Committing
To save your changes in the git database,
$ git add file
$ git commit file
Pushing
First make sure the remote origin is set up according to coursegit
$ git push origin master
Overview
- Worth
- 12% of your course mark
- Due
- The day after the lab, at 4:30 PM
Students will keep a record (a "journal" or "blog") of activities in the the CS2613 labs.
This journal will be worth 12% of your course mark in total.
The journal will be maintained using frog and git. See the first lab for a tutorial.
The marking rubric available
Content
Each journal entry should be a minumum of 250 words and a (rough) maximum of 500
You can think about your journal entry as a set of notes for a friend who missed this particular lab.
Your journal entry should answer the following questions
- What new concepts (if any) did you learn about in this lab?
- What concepts are familiar from other courses or from your own knowledge?
- What new skills did you practice?
- What specific details did you find surprising, interesting, confusing, difficult, or otherwise important?
- What explicit tasks (e.g. reading) were you given during this lab?
You are encouraged to link to other pages both inside and outside UNB in your journal entries.
Presentation
Imagine a future employer reading your journal right before interviewing you. Write so that the person interviewing will think of you as a peer, rather than as an "annoying kid".
Your journal entry should use good spelling and grammar, including complete sentences and paragraphs.
A certain amount of point form is OK, but don't rely on it exclusively.
Try to keep a neutral tone. It's fine to record positive or negative opinions, but avoid ranting (or gushing).
Avoid overuse of emoticons or abbreviations typical of instant messaging and social media.
Deliverables
Create a separate post for each lab.
This journal entry must be in the standard directory, and must be named
<date>-<title>.md or<date>-<title>.scrbl where<date>is the date of the corresponding lab. Any easy way to ensure this is to create the journal entry during the lab.Journal entries are due the day following the lab in question, at 4:30 PM. See below for how to hand it in.
Make sure you preview your journal entry to avoid obvious mistakes. You will lose marks for syntax errors.
Handing it it
I recommend you commit and push some rough notes during the lab and edit them later.
You can commit and push as many times as you like. You will be marked on what is on the server at the time it is due.
By default your journal is only visible to the prof and the TA.
All coursework in CS2613, including tests, will be submitted via git repositories operated by the Faculty of Computer Science
A tutorial on git will be offered in the first two labs of the course (L01 and L02) Like all material presented in the labs, you are responsible for this material whether you attend or not. This includes people who register late for the course.
Some hints about using git are available, including pointers to more documentation.
Technical difficulties with git will not be considered a valid excuse for late or missed work unless they affect the entire class (e.g. server downtime).
In this course git commit messages are considered part of the documentation of your code and you will be marked accordingly. See the §5.2 of Pro Git for some guidelines. See this webcomic for a related joke.
Access to the FCS git repos is available from all machines in FCS Linux Labs. Be aware of scheduled use of these labs when planning to work on or hand in coursework.
Remote access to the FCS Linux labs is available via ssh.