- {% for post in site.posts limit:2 %}
+ {% for post in site.posts limit:1 %}
{{ post.title }}
{{ post }}
diff --git a/labs/bst-lab8/assets/Backtracking_BST_AVL.pdf b/labs/bst-lab8/assets/Backtracking_BST_AVL.pdf
new file mode 100644
index 00000000..d61f8dff
Binary files /dev/null and b/labs/bst-lab8/assets/Backtracking_BST_AVL.pdf differ
diff --git a/labs/index.md b/labs/index.md
index ce111e6f..7e3013a2 100644
--- a/labs/index.md
+++ b/labs/index.md
@@ -30,24 +30,28 @@ Lab sessions are held every week and will be conducted by a team of TAs and Cour
{% for lab in site.data.content.labs %}
+ |
+ {{ lab.id }}
+ |
+ {{lab.week}} |
{% if lab.assigned %}
- {{ lab.id }}
+ {{ lab.title }}
{% else %}
- {{ lab.id }}
+ {{ lab.title }}
{% endif %}
|
- {{ lab.week }} |
- {{ lab.title }} |
{{ lab.topics }} |
{% if lab.slides %}
- {{ lab.slides }}
+ {% for slide_link in lab.slides %}
+ {{ slide_link }}
+ {% endfor %}
{% endif %}
|
diff --git a/labs/lab10/assets/hashtable_lab.pdf b/labs/lab10/assets/hashtable_lab.pdf
new file mode 100644
index 00000000..0a7111cb
Binary files /dev/null and b/labs/lab10/assets/hashtable_lab.pdf differ
diff --git a/labs/lab10/index.md b/labs/lab10/index.md
index de07175a..9c6d79d3 100644
--- a/labs/lab10/index.md
+++ b/labs/lab10/index.md
@@ -9,7 +9,6 @@ title: Hashtables
**Due at the end of your registered lab section**
-As per usual, instructions/materials can be found on Codio. Code is also available [here](assets/resources.zip).
---
diff --git a/labs/lab13/assets/number_theory_lab.pdf b/labs/lab13/assets/number_theory_lab.pdf
new file mode 100644
index 00000000..821aeb11
Binary files /dev/null and b/labs/lab13/assets/number_theory_lab.pdf differ
diff --git a/labs/lab13/index.md b/labs/lab13/index.md
index 26be80d0..2bc2973c 100644
--- a/labs/lab13/index.md
+++ b/labs/lab13/index.md
@@ -7,7 +7,7 @@ title: Number Theory
---
-**Due at the end of your registered lab section.** Material and questions are also available on Codio. The coding materials for exercise 3 can be downloaded [here](./resources/resources.zip).
+**Due at the end of your registered lab section.**
---
@@ -56,6 +56,7 @@ Here is a helpful theorem to remember:
Using the theorem above, prove the following:
* If $p$ is a prime and $p \mid ab$, then $p \mid a$ or $p \mid b$.
+
---
### Quadratic Probing
@@ -160,4 +161,4 @@ After you finish your implementation, type `make` in your terminal to run the te
---
## Checking Off
-To get checked off, complete all three exercises in this lab and show your results to a CP/TA.
\ No newline at end of file
+To get checked off, complete all three exercises in this lab and show your results to a CP/TA.
diff --git a/labs/lab14/hashtable_lab.pdf b/labs/lab14/hashtable_lab.pdf
new file mode 100644
index 00000000..0a7111cb
Binary files /dev/null and b/labs/lab14/hashtable_lab.pdf differ
diff --git a/labs/lab3/makefile_lab.pdf b/labs/lab3/makefile_lab.pdf
new file mode 100644
index 00000000..8b654baa
Binary files /dev/null and b/labs/lab3/makefile_lab.pdf differ
diff --git a/labs/lab4/assets/stl_inh_lab.pdf b/labs/lab4/assets/stl_inh_lab.pdf
new file mode 100644
index 00000000..8bf24383
Binary files /dev/null and b/labs/lab4/assets/stl_inh_lab.pdf differ
diff --git a/labs/lab4/index.md b/labs/lab4/index.md
index 7f0fe67a..53801bdc 100644
--- a/labs/lab4/index.md
+++ b/labs/lab4/index.md
@@ -5,13 +5,8 @@ tasks: true
title: Inheritance and STL
---
----
-
-**Due at the end of your registered lab section**
-[Here](assets/resources.zip) is the zip file with all required files. You can also find the lab on Codio.
----
## Inheritance and STL
diff --git a/labs/lab5/index.md b/labs/lab5/index.md
index 38a14971..fcf7adc9 100644
--- a/labs/lab5/index.md
+++ b/labs/lab5/index.md
@@ -5,10 +5,6 @@ tasks: true
title: Templates
---
----
-### Due at the end of your registered lab section
-
-[Here](assets/resources/resources.zip) is the zip file with all required files. You can also find the lab on Codio.
---
diff --git a/labs/lab6/assets/heap_lab.pdf b/labs/lab6/assets/heap_lab.pdf
index 4b0a6073..3c96f99b 100644
Binary files a/labs/lab6/assets/heap_lab.pdf and b/labs/lab6/assets/heap_lab.pdf differ
diff --git a/labs/lab6/index.md b/labs/lab6/index.md
index 506af1a2..7b4aa22d 100644
--- a/labs/lab6/index.md
+++ b/labs/lab6/index.md
@@ -10,8 +10,6 @@ title: Heaps
In today's lab, we're going to focus on priority queues, an important data structure that you'll need to understand for the next assignment and beyond.
-Code can be downloaded [here](assets/resources.zip), as well as viewed/edited on Codio.
-
### Heaps Introduction
In office hours, we use a standard FIFO queue system, where the student waiting the longest is called next. But what if we wanted to apply a more complicated calculation to found who was next? Maybe the person with the shortest question? The person who started the assignment the earliest? The person who's asked the fewest questions? We still want the popping functionality of a queue, where we just care about who's on top, and don't need to access anyone in the middle. However, we no longer want to process items in order of the arrival.
diff --git a/labs/lab7/assets/Backtracking_BST_AVL.pdf b/labs/lab7/assets/Backtracking_BST_AVL.pdf
new file mode 100644
index 00000000..d61f8dff
Binary files /dev/null and b/labs/lab7/assets/Backtracking_BST_AVL.pdf differ
diff --git a/labs/lab7/assets/Backtracking_Lab.pdf b/labs/lab7/assets/Backtracking_Lab_su22.pdf
similarity index 100%
rename from labs/lab7/assets/Backtracking_Lab.pdf
rename to labs/lab7/assets/Backtracking_Lab_su22.pdf
diff --git a/labs/lab9/assets/Backtracking_BST_AVL.pdf b/labs/lab9/assets/Backtracking_BST_AVL.pdf
new file mode 100644
index 00000000..d61f8dff
Binary files /dev/null and b/labs/lab9/assets/Backtracking_BST_AVL.pdf differ
diff --git a/labs/lab9/assets/Lab9_BST_AVL.pdf b/labs/lab9/assets/Lab9_BST_AVL_su22.pdf
similarity index 100%
rename from labs/lab9/assets/Lab9_BST_AVL.pdf
rename to labs/lab9/assets/Lab9_BST_AVL_su22.pdf
diff --git a/labs/number_theory/assets/number_theory_lab.pdf b/labs/number_theory/assets/number_theory_lab.pdf
new file mode 100644
index 00000000..e04339ee
Binary files /dev/null and b/labs/number_theory/assets/number_theory_lab.pdf differ
diff --git a/labs/number_theory/index.md b/labs/number_theory/index.md
index 27ca04f3..d5b8f739 100644
--- a/labs/number_theory/index.md
+++ b/labs/number_theory/index.md
@@ -7,7 +7,6 @@ title: Number Theory
---
-This lab would be covered by lab sections between Apr. 19, 2022 and Apr. 22, 2022.
You need to get checked off by a TA/CP during your assigned lab section.
@@ -161,4 +160,4 @@ After you finish your implementation, type `make` in your terminal to run the te
### Checking Off
-To get checked off, complete all three exercises in this lab and show your results to a CP/TA.
\ No newline at end of file
+To get checked off, complete all three exercises in this lab and show your results to a CP/TA.
diff --git a/labs/su-gtest_lab/assets/gtest_slides.pdf b/labs/su-gtest_lab/assets/gtest_slides.pdf
new file mode 100644
index 00000000..c1ecf788
Binary files /dev/null and b/labs/su-gtest_lab/assets/gtest_slides.pdf differ
diff --git a/labs/su-gtest_lab/index.md b/labs/su-gtest_lab/index.md
new file mode 100644
index 00000000..8c616c7e
--- /dev/null
+++ b/labs/su-gtest_lab/index.md
@@ -0,0 +1,236 @@
+---
+layout: default
+toc: true
+tasks: true
+title: GTest
+---
+
+## Unit Testing and GTest
+In this lab we want to dive into the topic of unit testing. The goal of this lab is to give you an overview of how to use the Google Test framework to build and run test cases for any C++ project.
+
+### 0 - Motivation
+
+Testing is absolutely essential to a typical development process. Having a complete test suite can ensure that the code that you spent hours building works, fits specification, and is bug-free.
+
+Suppose you have just finished homework and you think you have a pretty good implementation of a doubly linked list. How do you know, for sure, that this list behaves like how you intended it to be? You can manually read through the code a million times, but you might still miss something.
+
+A good test case program should:
+
+ + Use your newly created data structure
+ + Perform simple operations with your data structure's methods
+ + Make sure that each method performs the way you intended it to be
+
+There are several advantages for having a well-crafted test program:
+
+ + Help you think about edge cases - ones that you might not have thought of when implementing the data structure itself.
+ + Help you make sure each subpart of a problem works correctly. For example, when you implement a new data structure with your new LinkedList, and you encounter a problem, it's very hard to know whose fault it is - the new data structure or the underlying LinkedList. By thoroughly testing your LinkedList in its corresponding test, you will be able to nail down where to hunt for problems fast.
+ + When you make a change to your code, you can make sure that it did not break anything.
+
+The [Google Test documentation](https://code.google.com/p/googletest/wiki/Primer) has further guidelines for what constitute good test suites.
+
+### 1 - Testing a Fibonacci Program
+
+#### 1.1 - Introduction to Testing
+
+Let's first begin writing tests for a simple function that computes the nth Fibonacci number. But before you open the code for the Fibonacci program, ask yourself - what are some test cases that we'll need to test?
+
+**Nominal Cases** - You can always start with the most basic cases - that 5th fibonacci should be 5, 7th should be 13. It's a good idea to include a few basic cases so to be sure you weren't just lucky, but you shouldn't need anything more than that.
+
+**Boundary or Special Cases** - What are the boundaries for this function? For a Fibonacci calculation, it seems that there is only a "lower-bound", namely when n = 1. For some data structures that are slightly more complex, there might be multiple boundaries, like the resize limit ("`capacity`") for an array based implementation of a list.
+
+**Off-nominal Cases** - Your program should be completely fool-proof. That means your program should handle even input that does not make sense. For example, asking for the -2th Fibonacci number, or asking to insert at the 5th position for a 2 element array. Note that things that do not compile are not part of off-nominal cases. If your compiler cannot compile the code, you won't even have an executable to run.
+
+Notice that we came up with these cases **without the need of looking at code** - all we did was think about how a Fibonacci program should behave, and how a user would be using such a function. In fact, it's very common for industry software engineers to write the test cases first _before_ writing a single line of code; they call this [Test-Driven Development (TDD)](http://en.wikipedia.org/wiki/Test-driven_development).
+
+A very simple test program might include a long list of test cases made of if statements that looks like this:
+
+```
+Fibonacci fib;
+if (fib.get(5) == 5) {
+ std::cout << "OK" << std::endl;
+} else {
+ std::cerr << "FAIL | 5th Fibonacci number should be 5."
+}
+```
+
+However, a long list of these cases can get out of hand very quickly - it's annoying to read and even more so to write repetitive code. We can use a library called Google Test to help us out.
+
+#### What is enough, and how much is too much?
+
+Generally speaking, there should be at least one test case for each code execution path in a function. For example, if a function has 3 branch conditions, test at least each path once, to ensure all use cases are covered. There is no need to test a single path more than a few times - it doesn't hurt, but it's generally unnecessary as it increases testing time. This is only a rule of thumb, as some edge cases just cannot be predicted by looking at the code.
+
+When testing a class implementation, each public function should be tested. For example, an array implemntation of a list, `ArrayList`, should have test cases for functions `add()`, `set()`, `remove()`, `get()`, and so on. More on class testing in a little bit!
+
+#### 1.2 - Our First Google Test Case
+
+Navigate to the `part1` directory, and open the `test.cpp` file included for you. The meat of the test suite provided to you in this file is in these four lines:
+
+```
+TEST(FibTest, Nominal) {
+ Fibonacci f;
+ EXPECT_EQ(5, f.get(5));
+ EXPECT_EQ(13, f.get(7));
+}
+```
+
+You should notice that this is not standard C++ syntax. We're using a **C++ Macro** here that is supplied by the framework. C++, when compiling, will automatically replace this code with some appropriate C++ code defined in the framework. It is likely a much longer chunk of code that Google Test wants to hide and save the user from an unnecessary amount of copy pasting.
+
+A test case is defined by calling this `TEST` macro. Two more things are important here: `FibTest` and `Nominal`, the two "parameters" that are "passed into" the Macro. The first parameter specifies the name of the test suite. As a rule of thumb, all tests in a file should belong to the same test suite, and in this case, FibTest. The second parameter is the name of this test. We're testing the trivial cases right now, so we're just going to call it the "Nominal" case.
+
+```
+EXPECT_EQ(5, f.get(5));
+```
+
+Another macro here - `EXPECT_EQ`. The name of this macro is not too surprising - test cases are but a long list of expected results under different circumstances. In here, by calling `EXPECT_EQ`, you're saying: "When I call f.get(5), the value it returns should equal to 5."
+
+You can find the list of GTest Macros [here](https://github.com/google/googletest/blob/master/googletest/docs/Primer.md).
+
+#### 1.3 - Adding some more test cases
+
+As we've mentioned, there are more test cases worthy to be tested. Let's add them together to our `test.cpp` file.
+
+**Boundary or Special Case**
+
+In our Fibonacci calculation, we have a base case of "1" and "2" - they return special values unlike the nominal cases. We should add a test that makes sure this happens.
+
+We first start with a call to the macro, with the test suite name staying the same (`FibTest`), and the test case name something like ("Boundary").
+
+```
+TEST(FibTest, Boundary) {
+ Fibonacci f;
+ ...
+}
+```
+
+What goes inside? Expectation statements. What do you expect `f.get(1)` return? `f.get(2)`?
+
+```
+ EXPECT_EQ(??, ??)
+ EXPECT_EQ(??, ??)
+```
+
+When you're done - _don't run the tests yet_! Finish the entire test suite first, before you try to see if anything's wrong. This is to prevent us tailoring our test cases to the code - you would be able to think about edge cases much more easily from a different perspective.
+
+- [ ] Write a test for the boundary case in `test.cpp`.
+
+**Off-Nominal Case**
+
+What else can go wrong? A rule of thumb is: never trust the user. If something can go wrong, it will; so it's essential that your program handles correctly.
+
+For the sake of this testing demonstration, let's assume that any invalid input should return a value of 0. Some invalid inputs in this case could be 0, -1.
+
+- [ ] Write a test case for this and include it in `test.cpp`.
+
+**Bonus**: There is one more edge case. Can you think what it is? (Hint: What's the type of the input?)
+
+#### 1.4 - Run the tests now
+
+Now that we have a complete test suite, we can see if our program works fully to our specs by running `make tests` on the terminal **in Docker**. Because our dependencies are set up properly, this will attempt to compile the `fib` object, and then the test executable. After all the compiling is done, it will then attempt to run the test executable.
+
+You should now see a fancy test runner output, that says the output is unexpected, followed by a segfault. It's okay, we'll fix them one by one.
+
+```
+// Line 5: Change from:
+return 0;
+// to:
+return 1;
+```
+
+Run the tests again by calling `make tests` from your Docker shell. That nominal test case now passes successful, but the segfaults are still there in the Off-Nominal Case. Well, that's unexpected. As always, try to debug using gdb.
+
+```
+gdb fibTest
+```
+
+Run until the segfault happens, and then run `bt` to see how the error occurred. It seems that the program crashed because we ran out of stack space by calling too many recursions. Fix this by modifying our `fib.cpp`:
+
+```
+// Add after Line 3:
+if (n <= 0) {
+ return 0;
+}
+```
+
+Run the test again, and it should now pass with flying colors - green, that is.
+
+- [ ] Fix the segfault as instructed.
+
+### 2 - Testing a Class
+
+Now that we understand how to run tests, we're going to practice testing on a class implementation. We'll be writing tests for an `ArrayList` class.
+
+#### 2.1 - Understanding Fixtures
+
+When we test classes, we often need some initialization before we can test. For example, initializing classes with the correct constructor parameters, populating an array, etc. Because these setup are usually repeated across multiple test cases, we put them in "Fixtures"
+
+Open the `test.cpp` in the `part2` folder. You'll notice that this file is slightly longer than the one in the first part. The main difference being a definition of a class `ArrayListTest`. There are several characteristics to this class:
+
+ + It inherits from a Google Test class `testing::Test`. We have not learned what inheritance works yet, but you will understand how it works in a little bit
+ + The class is largely empty, but it includes a declaration of a member variable of type `ArrayList`. This object is available for use in any of the test cases
+ + It has four methods you can insert code in:
+ - the class constructor and `SetUp()` is largely the same; both will be called before each test case
+ - similarly, the class destructor and `TearDown()` will be called after each test
+
+In order to have access to the fixture, tests need to be declared using the `TEST_F` fixture instead of `TEST`. The test suite name should also be the same as the class name.
+
+You can see all that comes to play in the sample `get()` test. Notice that we are able to read elements from the list right away without any other code inside the test. In fact, for every test in this test suite will inherit these setup instructions as well. This helps to keep the actual test code simple.
+
+### 3 - More about Testing
+
+A common mistake students make is that they write tests for their program to pass. This is wrong. Your job, when writing test cases, is to try as hard as you can to break your code. Try to think of all possible ways that your program can misbehave. When designing test cases, ask yourself these questions:
+
+ + What promises does the program make in its documentation?
+ + If something is supposed to happen after a function call, does it happen?
+ + If nothing should happen, how can you make sure nothing happened?
+ + What edge cases might a programmer easily overlook?
+ + What input might cause the program to crash?
+
+Remember - the harsher you are when testing your own program, the less bugs will make it to the hands of your end users.
+
+### 4 - Assignment: Identify Two of the Bugs
+
+**TL;DR: Find 2 out of 3 bugs by writing tests, and describe them in a .txt file for credit..**
+
+In the `part2` folder, we have provided an implementation of ArrayList for you - there is a header file `arraylist.h`, with the specification of the expected function in the comments, and a pre-compiled `ArrayList` implementation. You do not have access to the source code. We do this because again, we do not want you to think about test cases in terms of the source, but in a wider perspective of "how things should work".
+
+There are **three** bugs in the source code, and it is your task to find the problems by writing a good suite of test. Write a good set of tests for each of `add()`, `set()`, and `remove()` according to the specification provided in the header file, and thinking about edge cases. Find two of these bugs and you're good to go.
+
+We have written a sample test case for you for the `get()` function, although it is by no means an exhaustive test case. There is also a simple Makefile included for you, simply compile and run the test with `make tests`.
+
+Some tips:
+
+ + [Google Test documentation](https://code.google.com/p/googletest/wiki/V1_7_Primer) has a lot more macros you can use: `EXPECT_NE`, `EXPECT_LT`, `EXPECT_TRUE` etc.
+ + When you call a method, how should the state of the object change?
+ + What are the "boundaries" of this class? What happens there?
+ + What are the execution paths in each function?
+ + Big Hint: look at the test names we give you
+
+ - [ ] Find two of the three bugs. Describe them in a .txt file for credit.
+
+### Appendix: A little bit more on the Makefile
+
+You might be a little more confused about the `GTEST_LL` variable and how we are able to use Google Test. There are several key parts to understand here:
+
+ + The complete compile command is: `g++ -Wall -g test.cpp arraylist.o -I /usr/include/gtest/ -l gtest -l gtest_main -o arrayTest` The important files are `test.cpp` and `arraylist.o`, the rest are just flags.
+ + `GTEST_LL` - This is variable that contains the necessary flags to compile a Google Test program. There are several flags in here:
+ + `-I /usr/include/gtest/`: `-I` means "look up includes in this directory". This is how `#include "gtest/gtest.h"` worked in the test program - when C++ tries to look up a file, it looks not only in the current directory, but in whatever directories specified by `-I` as well. Including the gtest header ensures all necessary functions are imported. This is similar to how `-Ilib` works.
+ + `-l gtest`: Use the library called "gtest". This includes all extra dependencies not included in the header file
+ + `-l gtest_main`: Use the library called "gtest_main". Notice that there are no main functions at all in our test suite program. THat's because the `gtest_main` library comes with one. When we run the test, we're running a main function included in the Google Test framework that automatically detects all tests and execute them accordingly.
+ + `-pthread`: Because Google Test runs tests in parallelize, enable threading support.
+
+You can probably safely copy this variable everywhere.
+
+**fib.o** - This is the rule to compile the Fibonacci class by itself. Notice that the `-c` flag is used - when we compile the class by itself, we can include the compiled object everywhere - in an actual program, or in the test suite.
+
+**fibTest** - The main test rule. It has two dependencies: the compiled fib object, and the test suite itself. For the command, we simply take all the dependencies and compile them, with the `GTEST_LL` variable. It's important that the libraries are loaded after the source files, or else the linker will likely throw an error.
+
+**tests** - A rule that just runs the tests. Optional. Notice that this is a phony rule, because it doesn't actually create any file.
+
+### Checking off
+To get credit please show a CP/TA the following:
+- fib.cpp and test.cpp from part1 folder
+- test.cpp from part2 folder
+- a .txt file describing at least 2 bugs you found in part2
+
+
+
diff --git a/labs/su-lab0-curricula/index.md b/labs/su-lab0-curricula/index.md
new file mode 100644
index 00000000..539ea7b5
--- /dev/null
+++ b/labs/su-lab0-curricula/index.md
@@ -0,0 +1,293 @@
+---
+layout: asides
+toc: true
+tasks: true
+title: Getting Started
+---
+
+# Getting Started
+
+Before you start out on your 104 journey you're going to have to complete a couple of setup steps.
+Make sure you read each section carefully; if you don't, you may find yourself unable to submit assignments.
+
+
+## Register with Github
+
+If you have not created a Github account yet, follow the instructions in this section.
+If you already have a Github account and you wish to use it for this course, you can skip to the next section.
+
+We will be using git extensively this semester in labs and in programming assignments.
+Github is a development ecosystem based around git.
+In CSCI 104, we will be using Github to host our git repositories and we will take advantage of other GitHub features such as the issue tracker and wiki.
+
+We start by visiting Github's
signup page.
+You are free to choose your username; it does not necessarily need to match your USC username.
+Likewise, you are welcome to any email, just **remember which email you use as you will need it later**.
+You will be sent an email to verify your email address.
+Do that before proceeding.
+
+If in doubt, use a GitHub account with your @usc.edu e-mail address.
+
+- [ ] Create or have a GitHub account
+
+
+## Register with Curricula
+
+Curricula is our home-grown classroom software suite that we'll be using to handle things like submission, grading, and office hours.
+Your next link your USC ID and GitHub account via the
registration page. If you've take the class in the past and have an account with our "Curricula" system, just login with Github. Otherwise, if this is your first time, just click **Register** and go through the process of creating an account. Though you'll enter a username and password, you should use the "Login with Github" each subsequent time you need to login. It will authenticate you automatically when you click that button.
+
+This step is particularly important because it will also kickstart the processes that create your homework repository and add you to the necessary GitHub groups.
+
+- [ ] Register with Curricula Web
+
+
+## Install Git
+
+You can skip this section if you have git installed or are using the VM, which has git installed.
+
+In order to actually install the git command line tools, go to the [git website](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git){:target="_blank"} and follow the instructions for your operating system.
+
+If you're installing on MacOS, installing the Homebrew package manager should also get you there: [brew.sh](https://brew.sh/){:target="_blank"}
+
+### Special Notes for Windows
+
+If you are using Windows, we recommend installing [git bash](https://git-scm.com/download/win), which will be provided as an option in the installer.
+Git bash is a separate shell that provides access to git as well as other command line utilities.
+If you have more experience with git or other command line tools, installing git and the other unix commands directly to your CMD is a pretty convenient option.
+
+
+## Virtual Machine
+
+We have two options for running the compiler tools that we will use for grading.
+While you are welcome to use any editor/IDE to develop your homework code, you must compile and run your code (and any of our tests) in a Linux virtual environment using a Linux VM, Docker, or some similar solution of your creation.
+
+We offer two solutions: a traditional VM and Docker.
+**We recommend Docker, as it avoids emulating an entire desktop by giving you easy and low-latency command-line access to all the tools you need**.
+Plus, you can use your own local editor to develop and write code.
+
+### Docker
+Follow the directions in this Github **[repository](https://github.com/csci104/docker){:target="_blank"}.**
+
+You might want to [configure an SSH key for your github account](#configuring-an-ssh-key) first, but it is not necessary.
+
+If you want more information on how Docker works and how to use it, you can read the
additional guide.
+
+- [ ] Read the additional guide or promise you know what you're doing.
+
+
+### VM
+
+Alternatively, you can download and install the Course VM, the instructions for which are available [in the wiki]({{ site.baseurl }}/wiki/vm/).
+This provides a full-featured virtual OS with graphical interface, etc.
+It is larger, stores your files on a separate "virtual disk" that is not directly accessible from your computer's host OS, and can sometimes get corrupted, so please push your work to Github often.
+
+- [ ] Install Docker or a virtual machine.
+
+
+## Configuring an SSH Key
+
+One of the main features of using a distributed version control system such as git is having a complete backup of your code and its history.
+Git uses the [Secure Shell](http://en.wikipedia.org/wiki/Secure_Shell) protocol (SSH) when contacting remote servers.
+To facilitate this communication, you need to generate a pair of encryption keys: one public and the other private.
+In this step, we will generate the set of keys required to use SSH.
+This will be done manually through the command line.
+
+**Important**: where you run the following instructions will depend on whether you're using Docker or the VM.
+**If you are using Docker, you must open a terminal on your normal operating system. This is because Docker reboots itself from a pre-canned image everytime, which would erase all git configurations you had**.
+If you're on Windows, installing Git should either give you Git Bash or access to unix commands in CMD.
+**If you are using the VM, you have to open Terminal inside the virtual desktop**.
+Going forward, whichever applies to you will be the terminal we refer to when we ask you to open or write commands in a terminal.
+
+- [ ] Open the correct terminal based on the instructions above.
+
+**Note**: you will be copying and pasting several commands in this lab.
+If you are using the VM, you can use `ctrl + shift + c` to copy from Terminal and `ctrl + shift + v` to paste into Terminal.
+You can also right-click in Terminal and choose Copy/Paste.
+If you're using Docker, copy and paste should work how it normally does on your operating system.
+
+Use the following command to generate an SSH key, **replacing `ttrojan@usc.edu` with the email associated with your Github account**:
+
+```shell
+ssh-keygen -t rsa -b 2048 -C "ttrojan@usc.edu"
+```
+
+- [ ] Generate an SSH key using the email associated with your GitHub account
+
+When prompted for a location to save the key, use whatever the default is.
+The path may look slightly different than the one below, but that's fine.
+
+```
+Generating public/private rsa key pair.
+Enter file in which to save the key (/home/cs104/.ssh/id_rsa):
+```
+
+After that, you will be prompted for a passphrase to secure your private key.
+**We recommend you do NOT generate a passphrase (because you'll have to enter it each time you upload your code to Github) and simply hit Enter when prompted for a passphrase**. If you do decide to enter a passphrase, please note that your password will not show up in terminal as you type it.
+When you are done typing your password (don't enter anything if you do not wish to set a passphrase), press `enter`.
+You will be prompted to verify your passphrase.
+Re-enter your passphrase (or nothing if you did not set one) and press `enter`.
+
+Upon success, you should receive confirmation that your key was generated.
+It will most likely look something like this:
+
+```
+Your identification has been saved in /home/cs104/.ssh/id_rsa.
+Your public key has been saved in /home/cs104/.ssh/id_rsa.pub.
+The key fingerprint is:
+SHA256:vC+4OG2u1PIeE0OKX9jiFFHuLnkYCBSsvIW8ybD873H ttrojan@usc.edu
+The key's randomart image is:
++---[RSA 2048]----+
+| ++o. |
+| S+.o *.* |
+| +.X. o |
+| 0. o + |
+| ..o E . |
+| .=S. . + .0 |
+| .*=* ... |
+|.+.=o*. .. *o* |
+| .++*oo. .. |
++----[SHA256]-----+
+```
+
+- [ ] Save the key to the default location
+
+
+## Git Configuration
+
+The next step is to configure your git profile in your development environment.
+This is important because your profile information is used to annotate your contributions to a repository/project.
+It may not seem like a big deal when you are the only one committing to a repository.
+However, it's a good habit to build since in a group setting, this information will help track what changes you made and how much you've contributed.
+
+You only need to do this configuration once for any machine or virtual machine you want to develop on.
+We'll be setting the following fields:
+
+- Full name
+- Email associated with GitHub
+- Editor for commit messages, e.g. `nano`, `vi`, `emacs`, `notepad`
+- Git message colors (make it prettier)
+- Newline handling ([why is this a problem?](http://en.wikipedia.org/wiki/Newline#Common_problems))
+
+To get started, have a terminal open.
+
+### Personal Information
+
+Please use your actual first and last name when configuring your git `user.name`.
+For your email, you should **use the email address you've associated with your Github account**.
+Configure your information as follows, replacing the example name and email with your own:
+
+```shell
+git config --global user.name "Tommy Trojan"
+git config --global user.email "ttrojan@usc.edu"
+```
+
+- [ ] Configure your `user.name` and `user.email`
+
+### Git CLI
+
+By default, git does not color its output.
+Pretty printing git messages makes it easy read the output and take proper actions.
+You can enable colors for interactive use with:
+
+```shell
+git config --global color.ui auto
+```
+
+### Git Editor
+
+When committing code in git, the system requires a commit message.
+If a message is not provided via the shell, git will launch the operating system's default text editor prompting you for a message.
+You can customize this action by setting what command you want to invoke to open a text editor, for example:
+
+- `nano` is a simple and easy-to-use shell text editor
+- `emacs`, `vi`, and `vim` have a steeper learning curve but offer more utility
+- `subl -n -w` will open Sublime if you have that installed (won't work on Docker)
+- `gedit` will open the default Ubuntu text editor (also doesn't work on Docker)
+
+Choose one of them (`nano` is likely the easiest) and run the following command:
+
+```shell
+git config --global core.editor "nano"
+```
+
+- [ ] Set your git editor to the text editor command of your choice
+
+### Default branch name
+
+Recently GitHub has changed to `main` as the default branch. We need our local git command to respect that:
+
+```shell
+git config --global init.defaultBranch main
+```
+
+### Miscellaneous Settings
+
+Operating systems implement new lines differently.
+Here you will configure git to automatically normalize the line feed to properly match the platform:
+
+```shell
+git config --global core.autocrlf input
+```
+
+- [ ] Set the line feed normalization to `input`
+
+Since Git 2.0, Git has updated its default push settings.
+To avoid getting a warning when you push (we will explain what push means soon), apply the following setting:
+
+```shell
+git config --global push.default simple
+```
+
+- [ ] Set the push strategy to `simple`
+
+You can double check your settings using the following command:
+
+```shell
+git config --list
+```
+
+- [ ] Check that all settings have been set properly
+
+
+## Github Profile
+
+You need to update your profile to include your name and SSH public key.
+There are also some optional settings you can change such as your profile picture and email notifications.
+
+In your [profile settings](https://github.com/settings/profile):
+
+- Put your **real name** in the name field.
+ This is to ensure the TAs & CPs know who you are regardless of your username.
+- Optionally, change your [profile image](http://gravatar.com/)
+
+In your [SSH key settings](https://github.com/settings/ssh):
+
+- Click `Add SSH Key`.
+- Provide a name for the key, such as "CS104 VM Key" or "MacBook Key".
+- Display the contents of your `id_rsa.pub` file by running `cat ~/.ssh/id_rsa.pub` in your terminal.
+- Select all the contents of your `id_rsa.pub` file all the way through the end of the last line where your email is displayed and then copy/paste them into the key field.
+ Make sure you copy the entire contents of the `id_rsa.pub` file.
+ It should start with `ssh-rsa` and end with your email address.
+- Click `Add Key`.
+
+In your [notification settings](https://github.com/settings/notifications), apply the following settings:
+
+- In your notification settings
+ - Automatically watch repositories: ON
+ - Participating: Email ON, Web ON
+ - Watching: Email OFF, Web ON
+- In your email notification settings:
+ - Comments on Issues and Pull Requests: ON
+ - Pull Request reviews: ON
+ - Pull Request pushes: ON
+ - Include your own updates: OFF
+
+Homework grade reports are released through GitHub, and using the above settings will ensure that you receive email notifications when your grade report is available.
+
+- [ ] Set your profile name to your real name
+- [ ] Upload your SSH key by adding the contents of your `id_rsa.pub`
+- [ ] Enable Github and Github email notifications
+
+
+
+
diff --git a/labs/su-lab1/assets/AppendixA_Git.pdf b/labs/su-lab1/assets/AppendixA_Git.pdf
new file mode 100644
index 00000000..3e5853d2
Binary files /dev/null and b/labs/su-lab1/assets/AppendixA_Git.pdf differ
diff --git a/labs/su-lab1/assets/git_lab.pdf b/labs/su-lab1/assets/git_lab.pdf
new file mode 100644
index 00000000..d43f85e3
Binary files /dev/null and b/labs/su-lab1/assets/git_lab.pdf differ
diff --git a/labs/su-lab1/assets/github-clone-button.png b/labs/su-lab1/assets/github-clone-button.png
new file mode 100644
index 00000000..9a3c3cd8
Binary files /dev/null and b/labs/su-lab1/assets/github-clone-button.png differ
diff --git a/labs/su-lab1/assets/github-clone-ssh.png b/labs/su-lab1/assets/github-clone-ssh.png
new file mode 100644
index 00000000..2d52cde3
Binary files /dev/null and b/labs/su-lab1/assets/github-clone-ssh.png differ
diff --git a/labs/su-lab1/assets/github-edit-pencil.png b/labs/su-lab1/assets/github-edit-pencil.png
new file mode 100644
index 00000000..2e2a9556
Binary files /dev/null and b/labs/su-lab1/assets/github-edit-pencil.png differ
diff --git a/labs/su-lab1/assets/github-edit-submit.png b/labs/su-lab1/assets/github-edit-submit.png
new file mode 100644
index 00000000..4b2e7a4a
Binary files /dev/null and b/labs/su-lab1/assets/github-edit-submit.png differ
diff --git a/labs/su-lab1/assets/github-example-first-commit.png b/labs/su-lab1/assets/github-example-first-commit.png
new file mode 100644
index 00000000..b497ab80
Binary files /dev/null and b/labs/su-lab1/assets/github-example-first-commit.png differ
diff --git a/labs/su-lab1/assets/github-link-commits.png b/labs/su-lab1/assets/github-link-commits.png
new file mode 100644
index 00000000..2e6747d1
Binary files /dev/null and b/labs/su-lab1/assets/github-link-commits.png differ
diff --git a/labs/su-lab1/assets/vm-terminal.png b/labs/su-lab1/assets/vm-terminal.png
new file mode 100644
index 00000000..d3536b07
Binary files /dev/null and b/labs/su-lab1/assets/vm-terminal.png differ
diff --git a/labs/su-lab1/index.md b/labs/su-lab1/index.md
new file mode 100644
index 00000000..01a212f7
--- /dev/null
+++ b/labs/su-lab1/index.md
@@ -0,0 +1,490 @@
+---
+layout: asides
+toc: true
+tasks: true
+title: Introduction to Git
+---
+
+# Introduction to Git
+
+[Git](http://git-scm.com/) is a distributed source code version control system.
+When you place your code under version control, you record the changes you make to your files over time and you can recall the history of each of your file changes at will.
+We will be using git extensively this semester in homework assignments.
+
+[GitHub](https://github.com/) is a development ecosystem based around git.
+In this course, we will be using GitHub to host our git repositories and we will take advantage of other GitHub features such as the issue tracker and wiki.
+
+**If you have not done [Lab 0]({{ site.baseurl }}/labs/lab0) to set up your GitHub account or install Docker or a VM, please do so now.**
+
+## Important: Using the correct terminal
+
+In order to complete this lab, make sure you are using the correct terminal to run commands:
+
+* If you are running Docker, then there are two types of terminals you are going to interact with:
+ - The **native terminal** refers to the terminal provided by your native OS, not docker. On Windows, type
+ `Win + R` and then `powershell` to start it. On Mac, open you app launcher and search for "terminal".
+ - The **docker terminal** refers to the terminal you obtain by typing the following in your **native terminal**:
+
+```shell
+ch start csci104
+ch shell csci104
+```
+
+From now on, every sequence of command we show you would be annotated with either *`[native]`* or *`[docker]`*. This denotes the
+terminal you should be running the command from if you are using Docker. (If you are using the VM, then always use the VM terminal).
+
+Examples (You do **NOT** need to run these commands):
+
+*`[native]`*
+```shell
+notepad.exe cat.txt
+```
+
+The above command shall be ran from your **native terminal**.
+
+*`[docker]`*
+```shell
+vim cat.txt
+```
+
+The above command shall be ran from your **Docker terminal**.
+
+* If you are running the course VM (through Virtual Box), then **all commands** from this lab shall be ran from
+ the terminal within the VM. To open a terminal in the VM, press `Ctrl + Alt + T` (Windows) or `Cmd + Option + T` (Mac).
+ Alternatively, you could open it by searching for "terminal" in the quick launcher:
+
+
+
+## Cloning the `resource` and `hw-username` repositories
+
+### The Concept of the *working directory*
+
+Every open terminal has a *working directory*. When you run a command inside that terminal,
+the command would interpret paths and filenames to be relative to that working directory, for example:
+
+```
+mkdir sub
+```
+
+creates the subdirectory named `sub` under the current *working directory*. If the *working directory* is `/usr/root/parent`, then this will
+create the directory `/usr/root/parent/sub`.
+
+### Step 1. Changing working directory to Docker's assigned `/work` directory
+
+First open your **native (Mac/Windows) terminal**. Then, change the working directory to the directory you [assigned to Docker during setup](https://github.com/csci104/docker#step-5-set-your-working-directory).
+
+If you are working on the course VM, you may use any directory you like on the VM (e.g. `~/csci104`).
+
+The command for changing the working directory is `cd` (which stands for "**c**hange **d**irectory"). In my case, the path to change to is:
+`C:\Users\rin\Documents\csci104\home` (yours might be different, depending on how you configured your docker), therefore I just type:
+
+*`[native]`*
+```shell
+cd C:\Users\rin\Documents\csci104\home
+```
+
+**Note: You will need double quotes around the path if your path contains space, e.g. `cd "C:\My Documents\Home"`**
+
+If you have forgotten which path you have assigned to Docker, you could check it by typing:
+
+*`[native]`*
+```shell
+ch list
+```
+
+And you will see an output that looks like:
+
+```
+Name: csci104
+ Image: usccsci104/docker:20.04
+ Volume: C:\Users\rin\Documents\csci104\home:/work
+ SecOpt: seccomp:unconfined
+ CapAdd: SYS_PTRACE
+ Port: :2222
+```
+
+The path after `Volume: ` (excluding `:/work`) is what you are looking for.
+
+### Step 2. Obtaining clones of the `hw-username` and `resources` repositories
+
+This step assumes that you have already finished the git, GitHub, and SSH key setup from Lab 0.
+
+Once you are inside the correct working directory, type the following commands (**replace the `username` in `hw-username` with your actual USC Net Id, the same goes for everything that follows. Your USC NetId is your USC email address without the "@usc.edu" part, not the 10-digit Student ID**):
+
+
+*`[native]`*
+```shell
+git clone git@github.com:{{site.data.urls.github_org}}/hw-username.git
+git clone git@github.com:{{site.data.urls.github_org}}/resources.git
+```
+
+If you see the following dialog in your command line, type `yes` and press `enter`.
+It's basically asking if you want to trust `github.com` as an SSH server.
+
+```
+The authenticity of host 'github.com (192.30.255.112)' can't be established.
+RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
+Are you sure you want to continue connecting (yes/no)?
+```
+
+After every clone command, you should see something like this (exact output might be different):
+
+```
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
+Receiving objects: 100% (4/4), done.
+Checking connectivity... done.
+```
+
+A few notes about cloning:
+ - **Never clone a Git repository** into a Dropbox or other sync'ed folder (Google Drive, etc.).
+ - **Never clone a Git repository** under another repository folder. They should be at the same level.
+
+## Running the Example Project
+
+We have provided an `example` project to test whether you have the correct environment setup to compile our homeworks. Make sure you follow the steps below and the output on your terminal matches the ones on this page.
+
+### Step 3. Copy the `example` dirctory to your `hw-username` directory
+
+For every assignment from this class, we would provide the it's skeleton code inside the `resources` repository, and you need to copy it into your
+`hw-username` directory when you start the assignment. You should then do all of your work in your `hw-username` repo instead of the
+`resources` repo.
+
+The `example` project is also provided in the `resources` repo. To copy it, first start the **docker terminal** if you are using Docker:
+
+*`[native]`*
+```
+ch start csci104
+ch shell csci104
+```
+
+Then, make sure your working directory is where you put the `hw-username` and `resources` clones. You could check this by typing:
+
+*`[docker]`*
+```
+ls
+```
+
+and you should see `hw-username` and `resources` in the output.
+
+If not, you have to use `cd` to change to the correct working directory.
+
+To copy the directory, type:
+
+*`[docker]`*
+```
+cp -r resources/example hw-username/example
+```
+
+where `cp` stands for "copy" and the `-r` standard for "recursive" which allows copying of directories.
+
+### Step 4. Building the example project
+
+Now, go into your `hw-username/example` directory by typing:
+
+*`[docker]`*
+```
+cd hw-username/example
+```
+
+Then, run the following command:
+
+*`[docker]`*
+```
+make run
+```
+
+If the build is successful, you should see something like this:
+
+```
+Running main() from /build/googletest-j5yxiC/googletest-1.10.0/googletest/src/gtest_main.cc
+[==========] Running 3 tests from 2 test suites.
+[----------] Global test environment set-up.
+[----------] 2 tests from SimpleReturnTest
+[ RUN ] SimpleReturnTest.Returns42
+[ OK ] SimpleReturnTest.Returns42 (0 ms)
+[ RUN ] SimpleReturnTest.Returns37
+test.cpp:12: Failure
+Expected equality of these values:
+ returns_37()
+ Which is: 36
+ 37
+[ FAILED ] SimpleReturnTest.Returns37 (0 ms)
+[----------] 2 tests from SimpleReturnTest (0 ms total)
+
+[----------] 1 test from SummationTest
+[ RUN ] SummationTest.SumsAreEqual
+[ OK ] SummationTest.SumsAreEqual (0 ms)
+[----------] 1 test from SummationTest (0 ms total)
+
+[----------] Global test environment tear-down
+[==========] 3 tests from 2 test suites ran. (0 ms total)
+[ PASSED ] 2 tests.
+[ FAILED ] 1 test, listed below:
+[ FAILED ] SimpleReturnTest.Returns37
+
+ 1 FAILED TEST
+make: *** [Makefile:8: run] Error 1
+```
+
+You **don't** have to worry about the red `[FAILED]` message as long as it shows up (it is intentional),
+but in case it does not show up, please ask for help from your lab instructor.
+
+### Step 5. Fixing the FAILED test case
+
+What you have just seen above is an example of an automated test. We run automated tests to grade your
+assignments, and you will learn more about them in later labs. For now, you could just think of them
+as programs that feeds some input into your assignment code and test whether they produce the correct
+output.
+
+Obviously, it is not good to have a FAILED test case! (You would lose points in an actual assignment if your
+program fail our test cases) So let's fix it!
+
+Open `library.cpp` and look at the function `int returns_37()`. As you can see it returns `36` instead of
+the suggested `37`. If you look at the FAILED test case carefully you would see:
+
+```
+Expected equality of these values:
+ returns_37()
+ Which is: 36
+ 37
+```
+
+which points to exactly the same issue.
+
+Therefore, change the return value to `37` and run `make run` again. This time every test should pass.
+
+### Step 6. Committing and pushing to your homework repository
+
+Now that you have finished the work locally, you would also want to push the changes to GitHub.
+
+To do so, open your **native** terminal (or the VM terminal is you are using the course VM) and change
+the working directory to `hw-username`. Then type
+
+*`[native]`*
+```
+git status
+```
+
+The output should look like this:
+
+```
+Your branch is up to date with 'origin/main'.
+
+Untracked files:
+ (use "git add
..." to include in what will be committed)
+ example/
+```
+
+which means that nothing from your `example` directory is tracked by git.
+
+To track those files run the following command:
+
+*`[native]`*
+```
+git add .
+```
+
+This command tells git to track all modification you have done to the repo (adding a new file, modifying a file, deleting a file, renaming a file, etc.). You could also specify individual files to track by providing their name instead of `.` (e.g. `git add library.cpp`).
+
+Now, if you check `git status`, you would see:
+
+```
+On branch main
+Your branch is up to date with 'origin/main'.
+
+Changes to be committed:
+ (use "git restore --staged ..." to unstage)
+ new file: example/.vscode/launch.json
+ new file: example/.vscode/settings.json
+ new file: example/.vscode/tasks.json
+ new file: example/Makefile
+ new file: example/README.md
+ new file: example/library.cpp
+ new file: example/library.hpp
+ new file: example/library.o
+ new file: example/test
+ new file: example/test.cpp
+```
+
+All the changes are now ready to be *committed*. You could now run the following command:
+
+*`[native]`*
+```
+git commit -m "fixed the example"
+```
+
+This tells git to create a snapshot of the repository that reflects the changes you just asked it to track.
+The snapshot is called a **commit**. Each commit must have a message, as specified by the `-m` option. It can be anything,
+but it's a good practice to keep it informative of what changes you have made.
+
+
+Now, if you type `git status`, you would see:
+
+```
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+ (use "git push" to publish your local commits)
+
+nothing to commit, working directory clean
+```
+
+This tells that your local repo has one commit that the remote does not have. To
+upload the commit, simply type:
+
+*`[native]`*
+```
+git push
+```
+
+Now, if you everything runs successfully, the changes you have made would be synced to GitHub. Go to
+the repo page on GitHub (it should be at https://github.com/usc-csci104-spring2022/hw-username, with `username`
+replaced with your actual Net ID), and navigate to `example`, you should see the following files:
+
+
+
+## Cloning the `resource` and `hw-username` repositories
+
+### The Concept of the *working directory*
+
+Every open terminal has a *working directory*. When you run a command inside that terminal,
+the command would interpret paths and filenames to be relative to that working directory, for example:
+
+```
+mkdir sub
+```
+
+creates the subdirectory named `sub` under the current *working directory*. If the *working directory* is `/usr/root/parent`, then this will
+create the directory `/usr/root/parent/sub`.
+
+### Step 1. Changing working directory to Docker's assigned `/work` directory
+
+First open your **native terminal**. Then, change the working directory to the
+directory you [assigned to Docker during setup](https://github.com/csci104/docker#step-5-set-your-working-directory).
+
+If you are working on the course VM, you may use any directory you like on the VM (e.g. `~/csci104`).
+
+The command for changing the working directory is `cd` (which stands for "**c**hange **d**irectory"). In my case, the path to change to is:
+`C:\Users\rin\Documents\csci104\home` (yours might be different, depending on how you configured your docker), therefore I just type:
+
+*`[native]`*
+```shell
+cd C:\Users\rin\Documents\csci104\home
+```
+
+**Note: You will need double quotes around the path if your path contains space, e.g. `cd "C:\My Documents\Home"`**
+
+If you have forgotten which path you have assigned to Docker, you could check it by typing:
+
+*`[native]`*
+```shell
+ch list
+```
+
+And you will see an output that looks like:
+
+```
+Name: csci104
+ Image: usccsci104/docker:20.04
+ Volume: C:\Users\rin\Documents\csci104\home:/work
+ SecOpt: seccomp:unconfined
+ CapAdd: SYS_PTRACE
+ Port: :2222
+```
+
+The path after `Volume: ` (excluding `:/work`) is what you are looking for.
+
+### Step 2. Obtaining clones of the `hw-username` and `resources` repositories
+
+This step assumes that you have already finished the git, GitHub, and SSH key setup from Lab 0.
+
+Once you are inside the correct working directory, type the following commands (**replace the `username` in `hw-username` with your actual USC Net Id, the same goes for everything that follows. Your USC NetId is your USC email address without the "@usc.edu" part, not the 10-digit Student ID**):
+
+
+*`[native]`*
+```shell
+git clone git@github.com:{{site.data.urls.github_org}}/hw-username.git
+git clone git@github.com:{{site.data.urls.github_org}}/resources.git
+```
+
+If you see the following dialog in your command line, type `yes` and press `enter`.
+It's basically asking if you want to trust `github.com` as an SSH server.
+
+```
+The authenticity of host 'github.com (192.30.255.112)' can't be established.
+RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
+Are you sure you want to continue connecting (yes/no)?
+```
+
+After every clone command, you should see something like this (exact output might be different):
+
+```
+remote: Counting objects: 4, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
+Receiving objects: 100% (4/4), done.
+Checking connectivity... done.
+```
+
+A few notes about cloning:
+ - **Never clone a Git repository** into a Dropbox or other sync'ed folder (Google Drive, etc.).
+ - **Never clone a Git repository** under another repository folder. They should be at the same level.
+
+## Running the Example Project
+
+We have provided an `example` project to test whether you have the correct environment setup to compile our homeworks. Make sure you follow the steps below and the output on your terminal matches the ones on this page.
+
+### Step 3. Copy the `example` dirctory to your `hw-username` directory
+
+For every assignment from this class, we would provide the it's skeleton code inside the `resources` repository, and you need to copy it into your
+`hw-username` directory when you start the assignment. You should then do all of your work in your `hw-username` repo instead of the
+`resources` repo.
+
+The `example` project is also provided in the `resources` repo. To copy it, first start the **docker terminal** if you are using Docker:
+
+*`[native]`*
+```
+ch start csci104
+ch shell csci104
+```
+
+Then, make sure your working directory is where you put the `hw-username` and `resources` clones. You could check this by typing:
+
+*`[docker]`*
+```
+ls
+```
+
+and you should see `hw-username` and `resources` in the output.
+
+If not, you have to use `cd` to change to the correct working directory.
+
+To copy the directory, type:
+
+*`[docker]`*
+```
+cp -r resources/example hw-username/example
+```
+
+where `cp` stands for "copy" and the `-r` standard for "recursive" which allows copying of directories.
+
+### Step 4. Building the example project
+
+Now, go into your `hw-username/example` directory by typing:
+
+*`[docker]`*
+```
+cd hw-username/example
+```
+
+Then, run the following command:
+
+*`[docker]`*
+```
+make run
+```
+
+If the build is successful, you should see something like this:
+
+```
+Running main() from /build/googletest-j5yxiC/googletest-1.10.0/googletest/src/gtest_main.cc
+[==========] Running 3 tests from 2 test suites.
+[----------] Global test environment set-up.
+[----------] 2 tests from SimpleReturnTest
+[ RUN ] SimpleReturnTest.Returns42
+[ OK ] SimpleReturnTest.Returns42 (0 ms)
+[ RUN ] SimpleReturnTest.Returns37
+test.cpp:12: Failure
+Expected equality of these values:
+ returns_37()
+ Which is: 36
+ 37
+[ FAILED ] SimpleReturnTest.Returns37 (0 ms)
+[----------] 2 tests from SimpleReturnTest (0 ms total)
+
+[----------] 1 test from SummationTest
+[ RUN ] SummationTest.SumsAreEqual
+[ OK ] SummationTest.SumsAreEqual (0 ms)
+[----------] 1 test from SummationTest (0 ms total)
+
+[----------] Global test environment tear-down
+[==========] 3 tests from 2 test suites ran. (0 ms total)
+[ PASSED ] 2 tests.
+[ FAILED ] 1 test, listed below:
+[ FAILED ] SimpleReturnTest.Returns37
+
+ 1 FAILED TEST
+make: *** [Makefile:8: run] Error 1
+```
+
+You **don't** have to worry about the red `[FAILED]` message as long as it shows up (it is intentional),
+but in case it does not show up, please ask for help from your lab instructor.
+
+### Step 5. Fixing the FAILED test case
+
+What you have just seen above is an example of an automated test. We run automated tests to grade your
+assignments, and you will learn more about them in later labs. For now, you could just think of them
+as programs that feeds some input into your assignment code and test whether they produce the correct
+output.
+
+Obviously, it is not good to have a FAILED test case! (You would lose points in an actual assignment if your
+program fail our test cases) So let's fix it!
+
+Open `library.cpp` and look at the function `int returns_37()`. As you can see it returns `36` instead of
+the suggested `37`. If you look at the FAILED test case carefully you would see:
+
+```
+Expected equality of these values:
+ returns_37()
+ Which is: 36
+ 37
+```
+
+which points to exactly the same issue.
+
+Therefore, change the return value to `37` and run `make run` again. This time every test should pass.
+
+### Step 6. Committing and pushing to your homework repository
+
+Now that you have finished the work locally, you would also want to push the changes to GitHub.
+
+To do so, open your **native** terminal (or the VM terminal is you are using the course VM) and change
+the working directory to `hw-username`. Then type
+
+*`[native]`*
+```
+git status
+```
+
+The output should look like this:
+
+```
+Your branch is up to date with 'origin/main'.
+
+Untracked files:
+ (use "git add ..." to include in what will be committed)
+ example/
+```
+
+which means that nothing from your `example` directory is tracked by git.
+
+To track those files run the following command:
+
+*`[native]`*
+```
+git add .
+```
+
+This command tells git to track all modification you have done to the repo (adding a new file, modifying a file, deleting a file, renaming a file, etc.). You could also specify individual files to track by providing their name instead of `.` (e.g. `git add library.cpp`).
+
+Now, if you check `git status`, you would see:
+
+```
+On branch main
+Your branch is up to date with 'origin/main'.
+
+Changes to be committed:
+ (use "git restore --staged ..." to unstage)
+ new file: example/.vscode/launch.json
+ new file: example/.vscode/settings.json
+ new file: example/.vscode/tasks.json
+ new file: example/Makefile
+ new file: example/README.md
+ new file: example/library.cpp
+ new file: example/library.hpp
+ new file: example/library.o
+ new file: example/test
+ new file: example/test.cpp
+```
+
+All the changes are now ready to be *committed*. You could now run the following command:
+
+*`[native]`*
+```
+git commit -m "fixed the example"
+```
+
+This tells git to create a snapshot of the repository that reflects the changes you just asked it to track.
+The snapshot is called a **commit**. Each commit must have a message, as specified by the `-m` option. It can be anything,
+but it's a good practice to keep it informative of what changes you have made.
+
+
+Now, if you type `git status`, you would see:
+
+```
+On branch main
+Your branch is ahead of 'origin/main' by 1 commit.
+ (use "git push" to publish your local commits)
+
+nothing to commit, working directory clean
+```
+
+This tells that your local repo has one commit that the remote does not have. To
+upload the commit, simply type:
+
+*`[native]`*
+```
+git push
+```
+
+Now, if you everything runs successfully, the changes you have made would be synced to GitHub. Go to
+the repo page on GitHub (it should be at https://github.com/usc-csci104-spring2022/hw-username, with `username`
+replaced with your actual Net ID), and navigate to `example`, you should see the following files:
+
+
+
+
+
+
The world the town your computer is safe once again!
+
+- [ ] Show a CP or TA `answers.txt` to get checked off!!
diff --git a/labs/su-lab3/index.md b/labs/su-lab3/index.md
new file mode 100644
index 00000000..71155f02
--- /dev/null
+++ b/labs/su-lab3/index.md
@@ -0,0 +1,533 @@
+---
+layout: asides
+toc: true
+tasks: true
+title: Makefiles
+---
+
+---
+
+**Due at the end of your registered lab section**
+
+---
+
+We are holding the hybrid labs sections this week - they will be recorded and streamed over Zoom, and you could get checked off over zoom. However you are strongly recommended to go to the physical location, unless you have COVID concerns (e.g. you tested positive or have symptoms).
+
+# Makefiles
+
+In this lab, we will review Makefiles, how they work, and how to write them.
+In order to do this, we will also be reviewing how to use GCC to effectively compile your code with the right settings and configuration.
+We will also explore some advanced techniques you can use to streamline your Makefile as your projects get larger.
+
+## Extra - Running Homework 1 Tests
+
+Before we get into Makefiles, here is something important for homework 1: running and debugging
+the tests. We have posted the instructions [here](https://bytes.usc.edu/cs104/wiki/cmake-tests/).
+
+We will also do live demo in each lab section. If you would like to see it in action ASAP, you
+could check the lab recordings for earlier sections.
+
+## GCC and Makefiles
+
+GCC (GNU Compiler Collection) is a program that we use to compile our program into executables.
+You have already used it in previous homework.
+
+Make (GNU Make) is a program that makes other programs.
+This is especially useful when your programs become large, and recompiling after an edit requires multiple steps.
+Using a `makefile`, we can configure a program to compile simply by typing the `make` command into terminal.
+This lab will teach you how to write a basic makefile to be used in assignments from here on out.
+
+### 1 - GCC
+
+You might have noticed that we have been using some magic commands when we compile files.
+Namely, you should have seen `g++`, `-g`, `-Wall`, `-o`, and `-c`.
+Here is a brief explanation of what exactly these commands do.
+
+First of all, `g++` is used to compile your programs using the GNU Compiler Collection (GCC).
+The `g++` command tells GCC that you want to compile a C++ program.
+There are other compilers out there, and when you want to use other compilers, you replace `g++` with the command that's used by the other compiler, such as `clang++`.
+In this class, we ask that you always compile your program with GCC using the `g++` command, because that's what we use when we grade you.
+
+When you see a terminal command that has a `-` followed by some text, this is usually a flag (also called options).
+A flag can be used to specify a setting or add additional information about the command.
+An option may or may not take an argument.
+If an option takes in an argument, the argument is followed immediately after the flag.
+To use a flag, simply include it with your compile command.
+
+In the `g++` command, you will often see `-g`, `-Wall`, `-o`, `-c`, and `-std=` command.
+Here's a descriptino of what they do and how to use them:
+
+ + `-g`: Provide debugging feature for your program.
+ You will need this when you want to use gdb or valgrind.
+ To use this flag, simply append the command to the end of your compile command.
+ + `-Wall`: Turn on all warnings.
+ This is helpful because, as you might have seen, not all errors cause your program to not compile.
+ There are some problematic operations that can cause undefined or unexpected behaviors in edge cases.
+ By turning on all warnings, you make sure that you eliminate these potentially dangerous operations.
+ + `-o`: This flag controls the output name of your compilation.
+ By default, the binary file name is `a.out`.
+ When you append `-o filename` to the end of your compile command, the compiled binary output will be the filename you specificed.
+ Be carefule that the filename is not an existing file because you will overwrite the file.
+ + `-c`: Compile the files but do not link them.
+ This is usually used to compile intermediate object files.
+ We will explain this more in later parts of the lab.
+ + `-std=`: This flag is used to specify the c++ version that you would like to use.
+ As you expect, c++ is an evolving language, and it keeps adding new features to the language.
+ Therefore, if you use a feature that's introduced in a newer version but try to compile the code with an older version, the compiler wouldn't know what the features are and the compilation will fail.
+ You use this flag by appending this flag to the end of your compile comand and speficy the version number after the equal sign (i.e. `-std=c++17`).
+ In this class, most of the times you can get away with using the default version and don't need to include this command at all.
+ There are times when you need to use the c++ 17 and you do it with `-std=c++17`.
+ + `-fmax-errors=N`: This tells the compiler to stop after encountering N errors in your code.
+ Usually we don't use it, because we want to see all errors in a code, and fix them together.
+ However, at times you will find that some error messages are long and there are so many of them that you can't see the top one (and if you are not fixing your compile errors starting with the first one, you should start doing that).
+ This is when it becomes handy to stop compilation after some number of errors.
+ + `-Wfatal-errors`: This is similar to the previous one, except that the compiler will treat an error as fatal and stop on first error.
+
+Lastly, you might sometimes see people compile files with `g++ something.cpp main.cpp -o main -g -Wall`, and you might wonder why they list the source files before the options.
+As it turns out, the order that you specify the options does not matter.
+If you really want to, you can even use `g++ something.cpp -g -Wall main.cpp -o main` to compile your program.
+However, by convention, we usually group the list of source files together and the list of options together.
+
+### 2 - Using Make
+
+GCC is nice to compile our programs, but it gets annoying if we have to type a 20 character command 10 times during development.
+This is when a makefile comes in handy.
+
+When you type `make` into terminal, Make will look for a file named `makefile` or `Makefile` for instructions.
+Let's start with a makefile for a single cpp file.
+
+In the part 1 folder, you will find a file called `charizard.cpp`.
+You can compile this simply with the following instruction:
+
+```
+g++ -g -Wall charizard.cpp -o charizard
+```
+
+That's too much typing if we need to do it 20 times during developing, so let's use make.
+
+#### 2.1 - Syntax and Structure
+
+A basic makefile's structure is the following:
+
+```
+target: dependencies
+ command_1
+ command_2
+ ...
+ command_N
+```
+
+Each of these is called a rule.
+A target is a file that Make tries to create, commands are used to create the target, and dependencies are the files that determine whether the commands need to be executed.
+When you type `make `, the make tool searches for the appropriate target in the directory and checks whether any of its dependencies need to be rebuilt.
+If the file is not found, or if any of its dependencies is newer than the target file, all commands in the rule will be executed.
+
+In this instance, we want to create a charizard executable using `g++ -g -Wall charizard.cpp -o charizard`, and we need to recompile the file if charizard.cpp changes.
+Therefore, our rule should look like this:
+
+```
+charizard: charizard.cpp
+ g++ -g -Wall charizard.cpp -o charizard
+```
+
+Note that the system command is and must be precedeeded by a **tab**.
+
+If you ever get an error message like this:
+
+```
+makefile:2: *** missing separator. Stop.
+```
+
+It means on line 2, make is expecting a tab but didn't find it.
+
+Editors like VSCode will convert tabs to spaces automatically. Normally that's fine but it's not okay for Makefiles.
+If you're using VSCode, you can use tabs as indentation this way:
+
+1. Open the command pallete with `Ctrl+Shift+P` (Windows) `Cmd+Shift+P` (MacOS)
+2. Search/Run the command: "Convert indentation to tabs"
+3. (Suggested for MacOS users) In the command pallete, run the command "Shell Command: Install 'code' command in PATH"
+
+
+- [ ] Compile your code by running `make charizard`
+
+#### 2.2 - Default Target
+
+What happens when you just run `make`?
+Good question!
+By default, `make` will execute the first target in a makefile.
+By convention, we add a target called `all` and list targets we wish to build on `make` command after `all`.
+
+Let's have 'all' make the charizard file, which will become the name of our target.
+Our resulting `makefile` is as below:
+
+```
+all: charizard
+
+charizard: charizard.cpp
+ g++ -g -Wall charizard.cpp -o charizard
+```
+
+- [ ] Compile your code by running `make all`
+
+Save this file as `Makefile` in the part1 directory and type make.
+Congratulations, you've just made your life 100x easier.
+
+### 3 - Compiling Multi-File Programs
+
+#### 3.1 - Object Files
+
+Compiling a multi-file program requires two main steps: compiling each `.cpp` file separately, and putting them all together to form the executable.
+The first step is know as compilation, during which the compiler checks for syntax and semantic mistakes, such as missing semicolons, calling a function that's not declared, or returning the wrong type in a function.
+The second step is known as linking, during which the linker "links" your function calls - it finds where the body of a function is so that it knows what line to execute when you call that function.
+
+When you compile a program with `g++ -g -Wall charizard.cpp -o charizard`, you are actually compiling and linking it.
+It turns out that it's possible to do them separately.
+This comes in handy when you have multiple files in your project.
+When you change one of the files, you can re-compile only files that depend on the change, and run linker, without having to re-compile the entire project.
+
+In order to do that, we introduce a new binary file type: .o files, or object files.
+These are the intermediate files we make in preparation to compile the executable.
+
+Let's look inside the part 2 folder.
+
+```
+$ cd ../part2
+$ ls *
+```
+
+You will find three classes: `AttackMove`, `Battle`, and `Pokemon`.
+We want to compile each of these into their own .o file of the same name.
+
+Since we're going to have a lot of binary files beyond this point, let's make a `bin` directory to hold them all for easy cleanup.
+
+```
+$ mkdir bin
+```
+
+To make an object file, we simply need to add the `-c` flag in the compile command, which tells g++ to not run linker.
+Let's compile `AttackMove` first.
+
+```
+g++ -g -Wall -c attackMove.cpp -o bin/attackMove.o
+```
+
+Simple as that.
+Do the same for the other two classes, and we can then compile the main.
+
+- [ ] Run compile commands for battle.cpp and pokemon.cpp
+
+[^1]: Or a library
+
+#### 3.2 - Putting It All Together
+
+To compile the main, we just have to include all the `.o` files that we've already made in the g++ command.
+
+```
+g++ -g -Wall bin/attackMove.o bin/battle.o bin/pokemon.o main.cpp -o bin/pokemon
+```
+
+**Note:** A `.o` file is compiled code that doesn't get linked to other code even if it calls functions from other classes.
+We tell the compiler this using the `-c` flag so that the compiler does not check whether the functions from other classes are implemented.
+When we want to compile the full executable, we do not want to have the `-c` flag in that statement because we want the compiler to link all the code together in the final step.
+
+And you have your own pokemon battle simulator! Run it like normal using:
+
+```
+./bin/pokemon
+```
+
+- [ ] Run the command to compile main to and then run `./bin/pokemon`
+
+#### 3.3 - Makefile Dependencies
+
+Well that's great and all, but how do we do that in a makefile?
+
+Let's go back to the basic make rule structure:
+
+```
+target: dependencies
+ command_1
+ command_2
+ ...
+ command_N
+```
+
+We skipped dependencies before, but it's something we want to use now.
+If a target has dependencies, make first checks if those dependencies exist before executing the system command associated with that rule.
+If the dependencies don't exist, make will run the rule to make those dependencies if they exist.
+
+Make will also check to see if the dependencies have been updated since the last make and will only recompile the dependencies that have changed.
+This can save you a lot of time if you make a change and don't want to recompile all the files in your project.
+
+Remember that dependencies are the files that can affect the compilation result of your target.
+This includes all the non-standard-library files that you `#include`, a class's own header file and .cpp file, and, if you are compiling into an executable, all the .o files you need.
+
+(Note: techincally speaking, `#include` files should be considered as transitive dependencies, that is: if `A` includes `B`, and `B` includes `C`, then `C` would also be a dependency of `A`. However, handling transitive inclusion is more complicated and not covered here)
+
+A multi-file program might have a Makfile like this:
+
+```
+all: bin/pokemon
+
+bin/pokemon: main.cpp bin/attackMove.o bin/battle.o bin/pokemon.o
+ g++ -g -Wall main.cpp bin/attackMove.o bin/battle.o bin/pokemon.o -o bin/pokemon
+
+bin/attackMove.o: attackMove.h attackMove.cpp
+ g++ -g -Wall -c attackMove.cpp -o bin/attackMove.o
+
+bin/:
+
+
+bin/:
+
+```
+
+If you run `make`, this will fail.
+You will be filling in all the `` at the end of the lab.
+
+- [ ] Fill in the blanks in the sample code to get your program to successfully compile
+
+### 4 - More Makefiles
+
+#### 4.1 - Variables
+
+Your professors decides they don't like the students compiling to the `bin` directory.
+They instead want the directory to be named `exe`.
+You could easily find and replace bin with exe, but that's messy and could generate errors.
+Why not take advantage of variables instead?
+
+At the top of your makefile, let's define:
+
+```
+BIN_DIR = exe
+```
+
+Now let's replace every instance of `bin` with `$(BIN_DIR)`, like so:
+
+```
+$(BIN_DIR)/attackMove.o: attackMove.h attackMove.cpp
+ g++ -g -Wall -c attackMove.cpp -o $(BIN_DIR)/attackMove.o
+```
+
+Now when the profesors change their mind again and want a different name for the directory, we can just change the variable at the top.
+By convention, we keep the binaries in a directory named `bin`.
+(For homework, don't put your final executable in a bin directory unless we tell you to do so.)
+
+Another use for this is to have a CPPFLAGS (compiler flags) variable that holds all the flags you frequently use to compile.
+We can have a CXX variable to specify which compiler to use. For example:
+
+```
+CXX = g++
+CPPFLAGS = -Wall -g
+BIN_DIR = exe
+
+$(BIN_DIR)/attackMove.o: attackMove.h attackMove.cpp
+ $(CXX) $(CPPFLAGS) -c attackMove.cpp -o $(BIN_DIR)/attackMove.o
+```
+
+- [ ] Rewrite your compile commands to use your new `BIN_DIR` variable
+
+The most useful variables you will use are **Automatic Variables**.
+Things that look like `$@`, `$<`, and `$^` are called automatic variables.
+When Make parses through the Makefile, it'll automatically substitute them with the correct string.
+
+ + `$@`: target name
+ + `$<`: first dependency
+ + `$^`: entire dependency list.
+
+Using these variables, we can rewrite our makefile rules as so:
+
+```
+CXX = g++
+CPPFLAGS = -Wall -g
+BIN_DIR = exe
+
+$(BIN_DIR)/pokemon: main.cpp $(BIN_DIR)/attackMove.o $(BIN_DIR)/battle.o $(BIN_DIR)/pokemon.o
+ $(CXX) $(CPPFLAGS) $^ -o $@
+
+$(BIN_DIR)/attackMove.o: attackMove.cpp attackMove.h
+ $(CXX) $(CPPFLAGS) -c $< -o $@
+```
+
+- [ ] Rewrite your compile commands to use automatic variables
+
+#### 4.2 - DIRSTAMP
+
+There is one problem with the above approach. If you now run
+
+```shell
+rm -r exe
+g++ -Wall -g -c attackMove.cpp -o exe/attackMove.o
+```
+
+you'll probably get an error that the `exe` directory doesn't exist.
+We could just use `mkdir exe` everytime we compile our program, but that's a pain.
+
+Let's define a rule to make sure the `exe` directory exists.
+
+```
+$(BIN_DIR)/.dirstamp:
+ mkdir -p $(BIN_DIR)
+ touch $(BIN_DIR)/.dirstamp
+```
+
+The `.dirstamp` file is a hidden file we make to make sure a directory exists.
+Notice that this rule does not have any dependency.
+When a rule has no dependency, it will be executed if the target does not exist.
+You can add this rule to the dependency list of your compile commands.
+
+```
+all: $(BIN_DIR)/.dirstamp $(BIN_DIR)/pokemon
+```
+
+It's important that you list `.dirstamp` before `pokemon`, because Make will check the dependencies in order. Since building `pokemon` requires that `$(BIN_DIR)` exists, make needs to create `.dirstamp` before `pokemon`.
+
+- [ ] Add `.dirstamp` to your Makefile where needed
+
+#### 4.3 - PHONY and Clean
+
+Now large projects will eventually generate a lot of binary files.
+We want to keep our workspace relatively clean by writing a rule to delete the generated files.
+This is also helpful when you're having mysterious problems as they sometimes go away after you delete and recompile your binaries.
+
+Here's our `clean` rule:
+
+```
+clean:
+ rm -rf $(BIN_DIR)
+```
+
+You can add this to the end of your makefile.
+Now clean your directory using the `make clean` rule.
+
+- [ ] Add `clean` as a target in your Makefile
+
+Very nice, but there's a small problem with the original rule.
+If a file named 'clean' exists in our directory, make won't run the clean rule because it sees that the file already exists!
+
+To get around this, we declare the clean rule as PHONY to tell make that `clean` is not associated with a file.
+
+```
+.PHONY: clean
+clean:
+ rm -rf $(BIN_DIR)
+```
+
+Now `clean` will always run when you use `make clean`.
+
+- [ ] Add a `.PHONY` target
+
+**Note:** there's a danger when using rm -rf as it will irreversably delete whatever `BIN_DIR` is without prompting additional confirmation.
+Be good and don't delete your entire OS (or worse, delete your grader's VM).
+
+#### 4.4 - Search Path
+
+If you look at files under `src` or `main.cpp`, you will see that we are including header files by writing out the relative path to it.
+It can be annoying if we wish to move our header files into a different directories, because we need to go to every single file that includes the header and change the path.
+We can avoid this by adding additional **Search Paths** during compilation.
+
+You should create a separate `lib` and `src` directory and move your `*.h` files into `lib` and `*.cpp` files into `src`. Here's some commands to help do that:
+
+```shell
+# run this in part2 folder
+mkdir lib src
+mv *.h lib/
+mv *.cpp src/
+```
+
+Now that every `cpp` file has been moved to the `src/` directory, you need to change
+your Makefile to reflect that. Change `main.cpp` to `src/main.cpp` and `attackMove.cpp` to
+`src/attackMove.cpp`, and `attackMove.h` to `lib/attackMove.h`.
+
+```
+$(BIN_DIR)/pokemon: src/main.cpp $(BIN_DIR)/attackMove.o $(BIN_DIR)/battle.o $(BIN_DIR)/pokemon.o
+ $(CXX) $(CPPFLAGS) $^ -o $@
+
+$(BIN_DIR)/attackMove.o: src/attackMove.cpp lib/attackMove.h
+ $(CXX) $(CPPFLAGS) -c $< -o $@
+```
+
+There is another problem, however. By default, GCC will look in the current directory of the file (i.e. `src` when compiling a file in `src`), but it will not look under nested directories.
+In addition, GCC also searches for standard libraries.
+
+In order to add a directory to its search paths, you use the -I*dir* option, where *dir* is the relative directory path from where you run the compile command.
+If you are using a Makefile, the path will be relative to where your Makefile is.
+
+In our case, we want to ask GCC to look for files under the `lib` directory.
+We can add append the option to the end of `CPPFLAGS`:
+
+```
+CPPFLAGS = -Wall -g -Ilib
+```
+
+Technically, this is not a makefile feature, but a compiler option.
+However, you don't normally group files into different directories unless your have a bigger project, in which case you should be using a Makefile (or IDE) to manage compilation.
+
+- [ ] Add `-I` to your compile commands
+
+### 5 - Assignment: Complete the Makefile
+
+Your final makefile should look something like this.
+Note: if you copy and paste the code from course website and paste it into your makefile, you will need to fix all the spaces and change them into tabs.
+
+```
+BIN_DIR = exe
+CXX = g++
+CPPFLAGS = -g -Wall -Ilib
+
+all: $(BIN_DIR)/.dirstamp $(BIN_DIR)/pokemon
+
+$(BIN_DIR)/pokemon:
+
+
+.o:
+
+
+.o:
+
+
+.o:
+
+
+.PHONY: clean
+clean:
+ rm -rf $(BIN_DIR)
+
+$(BIN_DIR)/.dirstamp:
+ mkdir -p $(BIN_DIR)
+ touch $(BIN_DIR)/.dirstamp
+```
+
+After finishing this part, you should be able to run
+
+```shell
+make
+exe/pokemon
+```
+
+to see a marvelous battle between pokemons!
+
+- [ ] Show your final Makefile to a CP or TA for checkoff. Be prepared to answer some of the review questions below!
+
+#### 5.1 - Review Questions
+
+1. What is the purpose of the `-c` flag?
+1. What is the advantage of compiling to .o files via makefile compared to compiling the executable together in one step?
+1. What files should be in a rule's dependency list?
+
+### 6 - More about Makefiles
+
+If you would like to know more about Makefile, you can visit [GNU Make Manual](https://www.gnu.org/software/make/manual/make.html).
+It covers both the basic and more advanced topics of the Makefiles.
+
+**CAUTION** Do not use these advanced make commands until you are very comfortable with Makefiles.
+
+### 7 - More about GCC
+
+We have listed some commonly used flags and options that you will see in this class.
+This is just a list of the common flags that you will use in this class.
+This is in no way comprehensive.
+If you see a flag that you do not understand, or if you are curious about other options, you can refer to this [official document from GCC](https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html).
+Feel free to play around with the flags in your free time.
+
+**IMPORTANT** We will be compiling your code with `-g -Wall -std=c++11`, so you must use the same options to check that your code compiles and produces no warnings.
diff --git a/labs/su-lab8-avl/assets/rotations.gif b/labs/su-lab8-avl/assets/rotations.gif
new file mode 100644
index 00000000..da6a7c74
Binary files /dev/null and b/labs/su-lab8-avl/assets/rotations.gif differ
diff --git a/labs/su-lab8-avl/index.md b/labs/su-lab8-avl/index.md
new file mode 100644
index 00000000..3260390d
--- /dev/null
+++ b/labs/su-lab8-avl/index.md
@@ -0,0 +1,127 @@
+---
+layout: default
+toc: true
+tasks: true
+title: AVL Trees
+---
+
+---
+
+**Due at the end of your registered lab section**
+
+---
+
+## Maintaining the BST and Height-Balancing Properties
+
+We will study these details more carefully in a few weeks. However, this is a good preview to start familiarizing yourself with these ideas. The BST property is maintained by smart insertion and deletion. In an insert, you traverse the tree based on the key to be inserted. Once you encounter a situation where you can't traverse any further, you know that the key can be placed there. Because we are traversing based on the key value, we are inherently upholding the BST property.
+
+The same thing can be said about a deletion in a BST. This is done by choosing which node to promote. Either the predecessor, if the node has two children, or the child if the node has 1 child. By doing this, the BST property is being maintained.
+
+A BST that maintains its balance throughout all insertions and deletions is called a self-balancing BST. These types of trees that auto-balance or self balance inherently with the insertion are called Self-Balancing Binary Search Trees. Examples are:
+
+1. Splay Trees
+2. AVL Trees
+3. Red Black Trees
+4. B-Trees
+5. 2-3 Trees
+
+For all of these self-balancing binary search trees, the height-balancing property is upheld by the nature of an insert or remove. The best way to do so is with rotation, or series of rotations. We're going to briefly review how those rotations work below.
+
+#### 1 - Rotations
+
+A rotation changes the local structure of a binary tree without changing its ordering. This means that in between rotations, the BST property is still maintained.
+
+Rotations can be broken up into left and right rotations which are just inversions of each other.
+
+
Staff and Hours
For special questions, you can contact your instructor.
- However, we encourage you to use the course edStem page so that other students can also benefit from these questions or answer them.
+ However, we encourage you to use the course edStem page so that other students can also benefit from these questions or answer them.
Note that we may change the listed office hours as needed, or add more before homework deadlines or examinations.
- For an up to date listing please see the Google Calendar
+ For an up to date listing please see the Google Calendar below.
diff --git a/syllabus/index-su22.md b/syllabus/index-su22.md
new file mode 100644
index 00000000..eafb6f62
--- /dev/null
+++ b/syllabus/index-su22.md
@@ -0,0 +1,212 @@
+---
+layout: asides
+toc: true
+tasks: false
+title: Syllabus
+---
+
+# CSCI 104 Syllabus
+
+The course covers the fundamentals of data structures.
+As a programmer becomes more proficient, they realize that how well and efficiently a problem can be solved often depends on how the data are stored.
+Some of the ideas are quite sophisticated and clever, and we will explore a spectrum of them in this class, ranging from fairly basic to moderately advanced structures.
+
+The other side is that once one realizes the importance of data structures, it is natural to think of programs not as sequences of instructions that pass around some data, but as data packets that come with the code needed to process them.
+This is at the heart of the object-oriented design paradigm, and often leads to more modular and extensible (and readable) programs.
+
+The class will put significant emphasis on a theoretical understanding of data structures, their implementation, and the object-oriented viewpoint. Assignments will contain significant programming projects along with programming-free questions to explore how data structures work.
+
+## Learning Objectives
+
+1. Ability to choose appropriate and efficient data structures and algorithms to solve a problem.
+2. Ability to compare data structures and algorithms for efficiency using algorithm analysis and experiments.
+3. Ability to apply algorithm analysis and knowledge of discrete mathematics to evaluate algorithms and data structures.
+4. Ability to implement and use linear data structures, including stacks, queues, lists.
+5. Ability to implement and use search structures and algorithms including binary search, search trees, and hash tables.
+6. Ability to use and implement search data structures, including search trees and hash tables.
+7. Ability to use and implement priority queues.
+8. Knowledge of and ability to implement sorting algorithms and compare their performance analytically and empirically.
+9. Understanding of graphs and their representations; ability to implement graph search using BFS, DFS, and Dijkstra's Algorithm.
+10. Ability to write recursive functions and understand when recursion is appropriate to a problem.
+11. Ability to write readable and maintainable code.
+12. Ability to explain computational solutions in person and in writing.
+13. Use probability as a tool in analyzing the efficiency of various data structures
+14. Use basic number theory to analyze basic hash functions
+
+## Catalog Entry
+
+Introduces the student to standard data structures (linear structures such as linked lists, (balanced) trees, priority queues, and hashtables), using the C++ programming language.
+
+### Prerequisites
+
+- CSCI 103: Introduction to Programming
+- CSCI 170: Discrete Methods in Computer Science
+
+## Course Websites
+
+- [All content & info]({{ site.baseurl }}/)
+- [Blackboard]({{ site.data.urls.blackboard }})
+- [CSCI 104 GitHub Organization]({{ site.data.urls.github }})
+- [Piazza]({{ site.data.urls.discussion }})
+
+## Grading Weights and Scale
+
+The following point structure will be used in determining the grade for the course.
+Your final grade will depend solely on your own performance, graded according to the scale given below.
+
+
+
+
+ | Weight |
+ Item |
+
+
+
+ | 36% |
+ Homework |
+
+
+ | 6% |
+ Lab Exercises |
+
+
+ | 28% |
+ Midterm Exams |
+
+
+ | 30% |
+ Final Exam |
+
+
+
+
+
+
+ | Grade | Letter |
|---|
+
+
+ | 85% | A |
+ | 80% | A- |
+ | 75% | B+ |
+ | 70% | B |
+ | 65% | B- |
+
+
+
+
+ | Grade | Letter |
|---|
+
+
+ | 60% | C+ |
+ | 55% | C |
+ | 50% | C- |
+ | 45% | D+ |
+ | 40% | D |
+
+
+
EdStem
GitHub organization
Office hours calendar