Lab 5

Lab 5: Debugging

Due Dates

As we did not have Lab Sessions this week due to Reading Period, this lab is optional and will not be graded. There is autograder feedback when you submit to Gradescope!

Objectives

In this lab, we will focus on debugging. The goal of this lab is to gain experience with the following:

Understanding the different types of errors that can arise while programming
Developing some debugging strategies to identify and resolve these errors
Writing useful test cases that discriminate between a buggy and correct version of a program

Different Types of Errors

When programming, you may encounter three main types of errors:

Syntax errors. These are textual errors that are identified by Python before it attempts to run the program. For example, if you forget a colon after the function definition def foo(), or forget to indent properly, Python will complain that your syntax is incorrect. These errors, while annoying, are typically the easiest to correct.
Runtime errors. When the program begins running, there are some conditions that may unexpectedly arise that Python will complain about. For example, suppose you compute the average of a list speeds in the following definition, found in a file physics.py:
```
def mean_speed(speeds):
    return sum(speeds) / len(speeds)
```
It is possible that speeds is empty. If so, the computation attempts to illegally divide by zero:
```
Traceback (most recent call last):
    File "physics.py", line 29, in meanSpeed
    return sum(speeds)/len(speeds)
ZeroDivisionError: division by zero
```
Logic errors. Sometimes when we translate an algorithm into code we may introduce mistakes in logic. For example, we may reset a variable to zero, or append a value incorrectly within a conditional, etc. Logic errors are among the hardest bugs to isolate and debug, because even though your program runs just fine, it fails to do what you expect it to do.

Reading error messages. As we investigate our scripts this week, we will want to carefully read the hints that Python gives us. For example, when syntax error messages are printed, they include line numbers. The error is very likely at or before the indicated line number. Fortunately, all modern text editors (like VS Code) show us line numbers for the current location.

When runtime errors occur, the Python system often prints a stack trace or traceback. This is a list of lines in the program that are currently being executed. Information about the most recent line appears near the bottom of the trace. Carefully reading the stack trace can give you important clues about what your program was doing when it stopped running.

Using print statements. Logic errors often stem from bad assumptions about the state of the program. To fix them, it is often helpful to get a better view of the program’s variables. The judicious use of print statements can help to isolate sections of the code that lead to unexpected values in state.

To get started on this week’s lab, you should clone the lab05 repository in the usual manner:

git clone https://evolene.cs.williams.edu/cs134-labs/23xyz3/lab05.git

Remember to replace 23xyz3 with your CS username.

Required Tasks

We would like you to fix errors in two of the scripts we’ve included in this week’s repository.

1. Syntax Errors

The script swedishpuzzle.py is filled with syntax errors. This script is inspired by a Swedish word puzzle game called “Rövarspråket”. Given a string word and letter letter, the rules of “Rövarspråket” ask for a new word which is created as follows:

Each consonant in word is doubled and the supplied letter is inserted between (e.g. 'n' becomes 'non' when 'o' is supplied).
Pre-existing vowels in word remain untouched.

Ideally, the function convert in swedishpuzzles.py takes a letter and a word as input (both of type str) and returns a new string answer according to the rules of the game. The logic of the included script is sound, but there are many syntax errors that you must fix. As you fix errors, mark each corrected line with the comment “#FIXED,” so we know what you changed. As you get started, you should consider adding some print statements to see how the state of variables are changing on each execution of the loop.

Once you have fixed all the errors, then running the script python3 swedishpuzzle.py should print the following:

Let's call convert on u and 
    it returns 
Let's call convert on o and stubborn
    it returns sostotubobboborornon
Let's call convert on o and pp
    it returns poppop

Note that your output should match the output shown above. If necessary, you should comment out any additional print statements that you used while debugging.

2. Logic Errors

The script vowelacious.py contains two buggy versions of the function is_vowelacious. We call a word vowelacious if it contains three or more consecutive vowels. For example, the word 'vowelacious' is itself vowelacious because of the substring iou. A correct is_vowelacious function should take a word (string) as input, and return True if it is vowelacious; else it should return False.

We have given you two incorrect implementations of this function: is_vowelacious_failed_attempt1 and is_vowelacious_failed_attempt2. You must analyze each of these functions to identify the logic errors. You may add as many print statements as you try to figure out where the code might be going wrong, but please do not modify the logic of these functions and remove the extra print statements before you turn in your code.

In addition to finding the logic errors, you must also complete the following three subtasks:

At the top of the file, there are 3 variables: attempt_1_vowelacious, attempt_1_not_vowelacious, and attempt_1_buggy. Set these strings to be words satisfying the following criteria.
- attempt_1_vowelacious is a Vowelacious word and is_vowelacious_failed_attempt1(attempt_1_vowelacious) returns True.
- attempt_1_not_vowelacious is a non-Vowelacious word and is_vowelacious_failed_attempt1(attempt_1_not_vowelacious) returns False.
- attempt_1_buggy is a Vowelacious word but is_vowelacious_failed_attempt1(attempt_1_buggy) returns False.
In other words, find two inputs for which the function works properly, and then an input for which the function produces a “false negative”.
Similarly, set attempt_2_vowelacious, attempt_2_not_vowelacious, and attempt_2_buggy to strings satisfying the same criteria for the second broken version of our function, is_vowelacious_failed_attempt_2:
- attempt_2_vowelacious is a Vowelacious word and is_vowelacious_failed_attempt_2(buggy2Vowelacious) returns True.
- attempt_2_not_vowelacious is a non-Vowelacious word and is_vowelacious_failed_attempt_2(buggy2NotVowelacious) returns False.
- attempt_2_buggy is a Vowelacious word but is_vowelacious_failed_attempt_2(buggy1Bad) returns False.
Fill in the TODO comment in the docstring for both buggy functions to briefly describe the logic error.
Finally, complete the is_vowelacious function with the correct implementation.

You can put function calls to test your functions directly in the if __name__ == "__main__": block at the end of the file. This code will only run when the python file is run as a script.

Submitting Your Work and Grading Guidelines

Do not modify function names or interpret parameters differently from what is specified! Make sure your functions follow the expected behavior in terms of type of input and output: if they return lists, their default return type must always be list. A function’s documentation serves, in some way, as a contract between you and your users. Deviating from this contract makes it hard for potential users to adopt your implementation!
Functionality and programming style are important, just as both the content and the writing style are important when writing an essay. Make sure your variables are named well, and your use of comments, white space, and line breaks promote readability. We expect to see code that makes your logic as clear and easy to follow as possible.
Do not forget to add, commit, and push your work as it progresses! Test your code often to simplify debugging.
Please edit the README.md file and enter the names of any appropriate students on the Collaboration line. Add, commit, and push this change.
Near the bottom of the README.md, there is a breakdown of the grading expectations that will form the basis of your lab’s evaluation. Please keep these in mind as you work through your lab!
Download a .zip archive of your work. Download your assignment files for submission by going to your lab repository on Gitlab, selecting the Download source code icon (a down arrow), and select zip. Doing so should download all of your lab files into a single zip archive as lab05-main.zip, and place it inside your Downloads folder (or to whichever folder is set as your browser’s default download location).
Submit your work. Navigate to the CS134 course on Gradescope. On your Dashboard, select the appropriate Lab Assignment. Drag and Drop your downloaded zip archive of the Lab Assignment from the previous step, and select ‘Upload’.