CSCI 102 - Intro to Computer Science LAB

Part C: Post Studio Work (9 points)
         Due Tuesday, November 30th, 11:45pm

Now that we have a git repository local to our computer, the next step is to make it available via GitHub. Fortunately GitHub Desktop makes this process pretty easy!

1. Open GitHub Desktop (if you don’t have it open already). If the repository we created in Part B is not listed at the very top left of your GitHub Desktop window, click on the area and select the name of the repo you created in Part B.
2. On this top menu bar, click on the option that says “Publish this Repository”.
3. You can use the default settings if you want. One KEY POINT: it is very important that your code is private (because you will be uploading your 101 and 102 labs to your repo). You are responsible for keeping your files safe.

Once the above steps are down (especially the PRIVATE setting), click on “Publish Repository”. You can now view your code on the GitHub website. You can do this by navigating to https://github.com/<yourusername>/csci-101-102-labs. At this point, your code on GitHub should look identical to the code you have in your local repository. If you get a “page not found error”, sign into GitHub and try again. It should look something like this:

Adding our Python Code

Since we want a large number of files to work with, we will add all our previously developed 101 and 102 labs to this local repository.

1. From your Finder / File explorer, create 1-2 new folders (two if you are in both 101 and 102): a 101 and a 102 folder.
2. Copy your 101 labs to the 101 folder, and your 102 labs to your 102 folder.
3. Open GitHub Desktop.
4. Select only your 101 labs (or half of your 102 labs, if you are not in 101) on the left hand side. (Recall: what is selected is what is staged for commit.)
5. In the commit summary area, write something like ‘added 101 labs’.
6. Verify that your GitHub Desktop looks something similar to the following (which doesn't have all of the 101 and 102 labs, i.e., your number of files / names of your files will be different).

Let's stop a minute and think about what we are doing before we hit ‘commit to master’. As discussed earlier, committing creates a snapshot of what our files look like at this current time. Thus, the content of the files that we have staged right now will be saved by git forever. Press ‘commit to master’.

Syncing with GitHub

Sign back into GitHub and go to your csci-101-102-labs repository. Are the files there what you expected? Maybe not. The files on GitHub did not change since the last time you looked at GitHub, as the commit we made only makes changes to our local repository. How do we make our new code added to GitHub Desktop available on GitHub? We do this through a process called pushing. You can push to GitHub from GitHub Desktop by pressing the “Push origin” on the top bar. Now, after you refresh github.com/<yourusername>/csci-101-102-labs, you should see something like this.

Take a few minutes and think about what this all means. Our 101 folder is here, but our 102 folder is not. (Or if you are only in 102, only half of your files are there.) This is because we only commited the 101 folder changes.

Trying it on your own

1. On your own, add all your 102 labs, commit, and push.
2. Verify that what you see at github.com/<yourusername>/csci-101-102-labs is the same as what you see on GitHub Desktop, i.e., you should have no uncommitted changes on the left.

Coding with Git

In this lab, you will use GitHub as you develop a Python program. As you know, when developing any large coding project, it is valuable to develop the program incrementally, where you design, then code, then test, then design, then code, then test, etc. This software development model is referred to as the incremental build model.

In this lab, while you are following the incremental build software development model, you are to commit your Python program in git SEVERAL times during its development. Specifically, you should develop each function incrementally; once a new function is fully developed (after you've tested it), you should push it to your repository. Then, at the end of this lab, you should have nine (or more) commits. The first commit will be when you add your Week12-utility.py file. The next eight commits will be after you have fully developed each of the eight functions below. (It is OK if you end up with more than nine commits.)

For your Week12-utility.py file, define the following utility functions (and, again, after each function is developed, push it to your repository):

1. load_file is a function that takes in a string (a filename) and then returns a list. The list is the contents of the file, where each element is a list of data from the file. Here's an example of using this function. The input file had four lines of text.
   >>> lines = load_file("test.txt")
   >>> print("OUTPUT", lines)
   OUTPUT ["Hello there", "I am a test file", "please load me in and print me out", "Thanks"]
2. update_string is a function that takes in two strings and an index integer (no return). The function should print a string that is the first string modified to replace the character at the index provided with the second string. (Remember that strings are immutable, i.e., some_string[5] = 'a' will give you an error.) Here's an example of using this function:
   >>> update_string("Hello World", 'yup', 3)
   OUTPUT Helyupo World
3. find_word_count is a function that takes in a list and a string. The function then returns the number of occurances of the string in the list. Here's an example of using this function:
   >>> my_list = load_file("test.txt")
   >>> find_word_count(my_list, "me")
   2
4. score_finder is a function that takes in two lists and a string. The first list is a list of strings (player names), the second list is a list of floats (player scores), and the string is a name (player to find). If the player to find exists in the list of player names, then print the name of that player along with their associated score (which is in the second list at the same index). If the player to find does not exist in the list of player names, print player not found. Here are two examples of using this function:
   >>> players = ["Mary", "Cody", "Joe", "Jill", "Xai", "Bodo"]
   >>> scores = [5, 8, 10, 6, 10, 4]
   >>> score_finder(players, scores, "jill") % NOTE: upper and lowercase should both work
   OUTPUT Jill got a score of 6
   >>> score_finder(players, scores, "Manuel")
   OUTPUT player not found
5. union takes in two lists and returns a single list that is the union of the two lists (i.e., return all values of the lists A and B with no duplicates). Here's an example of using this function:
   >>> players2 = ["Melvin", "Martian", "Baka", "Xai", "Cody"]
   >>> union(scores, players2)
   [5, 8, 10, 6, 4, "Melvin", "Martian", "Baka", "Xai", "Cody"]
6. intersect takes in two lists and returns a single list that is the intersection of the two lists (i.e., return all values of the lists A and B that are in both A and B). Here's an example of using this function:
   >>> intersect(players, players2)
   ["Cody", "Xai"]
7. not_in takes in two lists and returns a single list that is all values in the first list that are NOT in the second list. Here's an example of using this function:
   >>> not_in(players2, players)
   ["Melvin", "Martian", "Baka"]
8. is_prime takes in an integer and returns True if the given integer is prime and False if it is not (i.e., composite). Your solution should be O(sqrt(n)) in the worst case. An optimized solution will complete each of the following test cases in (at most) a second.
   >>> is_prime(1)
   False
   >>> is_prime(2)
   True
   >>> is_prime(49)
   False
   >>> is_prime(100123456789)
   True
   >>> is_prime(430593847530498654390593486530498563409586345098367)
   False
   >>> is_prime(666666555551)
   True
   Note: An optional is_prime AutoGrader problem has been created in the Weekly Lab Tests folder if you would like to test your function (and make sure it is optimized).

Gradescope Submission Nuances

Part A will ONLY be submitted to Gradescope (you will NOT demo this lab in class).
When you submit your Python file to Gradescope, multiple different test cases are run on your code. Passing all of the tests results in a 100% on the autograded portion of the lab.

You are allowed to submit to Gradescope four times (or less) for this lab. The maximum grade of your submissions will be your grade for the lab. Note: If your code doesn’t work (e.g., a syntax error exists, or an error is thrown in execution), then you will receive an AUTOMATIC ZERO. You should test your code before submitting to ensure it executes correctly.

Comments

---

Submission for Part C

You need to submit two items to Gradescope: (1) submit a screenshot of your history page and (2) submit your Week12-utility.py file; both files should be submitted to "lab week12: Part C". If you used the git from the command line, you can run git log > gitlog.txt and submit the resulting text file instead of a screenshot.

To receive full credit, your screenshot needs to show several commits, your Week12-utility.py code must execute in Python 3, and you must submit two files (your Python code file and the screenshot). In addition, your code must use the function names listed.

Whenever you submit something to Gradescope, we strongly recommend you always double check what you submitted actually got submitted correctly (e.g., did the file upload correctly? did you submit the correct file? etc.) If your submission is incorrect, it's on you.