Week 9

Week 9

Table of Contents

Due Dates & Links

Lecture Materials

Note: Links will require you to log in as a UCSD student

Lab Tasks

Discuss with your group:

Image

Write down your answers (and why you chose them!) in your group’s shared doc.

In this lab, you’ll be presented with a sequence of common debugging scenarios that we have noticed students encountering this quarter. For each one, there’s a brief description and a screenshot. Your job is to reproduce the error shown in the screenshot so that you see it on your own computer, and then describe the fix.

For each of the scenarios below, you should:

  1. Write down in notes: Discuss and confirm with your partner – what is the desired or expected behavior, and which part of the output is wrong or not what’s expected?
  2. Reproduce this behavior with your partner. If you have to, take the time to write out exactly the command-line in a suitable repository. To reproduce, we mean getting your terminal/editor to look as much like the one in the screenshot as possible. It might not be possible to make it exactly the same—your username will be different, for instance—but you should see the same error message for the same command.
  3. Write down in notes: Take a screenshot of your reproduction and put it in the notes, along with a description of how you reproduced it (e.g. if you first cloned a repository, opened a terminal, and changed directory, for example).
  4. Write down in notes: Describe how to change the commands or program to get the expected output. This might take some time and thinking! Did you need to gather any more information to figure out the issue? What helped you figure out the issue in the end? If you had a tutor or someone else help, what suggestions did they make to lead you to the answer?
  5. Write down in notes: Have you ever made this mistake before? What was easy or hard about noticing the error? What could you do in the future to notice or fix it more quickly?

(This is good practice and gives some understanding about what we do as course staff when we see your EdStem posts!)

One skill we’re practicing here is reproducing bugs. In general when reporting issues or asking questions, there’s a question of reproducibility: whoever is seeing the error usually doesn’t have access to your running system, so reproducing the possible error from the given information is a key step. Sometimes screenshots are more helpful than just text, because they include the Visual Studio Code file browser or other similar visual details. Sometimes text is more helpful than a screenshot, because it can be easily copy-pasted to try out some code on another computer. You can always provide both to really help the person trying to reproduce the error, which is what we do in some cases below!

Scenario 1

Here’s a screenshot of an error (right-click and “Open Image in New Tab” to see it if it’s too small). For reference, this one was using the lab 3 code repository. The programmer was trying to run the tests.

Image

Scenario 2

Imagine you are a tutor or TA and you only have access to the screenshot below, but not all the code. What would be frustrating about helping someone identify the bug in this scenario?

(The course staff does not have to imagine 😉)

Image

Imagine you are a tutor or TA and you only have access to the screenshot, but not all the code. What would be frustrating about helping someone identify the bug in that scenario?

(The course staff does not have to imagine 😉)

Scenario 3

bug.sh contains the following code:

VAR=7

if [[1 -eq $VAR ]]
then
  echo "it was 1"
fi

Image

Scenario 4

A project has the following file layout:

Image

The contents of Code.java is this:

import java.io.File;

public class Code {
   public static void main(String[] args) {
       File file = new File(args[0]);
       if (file.exists()) {
           System.out.println("File exists, yay!");
       }
       else {
           System.out.println("The file does not exist :(");
       }
   }
}

Then this surprising result happens (the programmer was expecting the file to be reported as existing):

Image

Reflection

You’ve learned a lot this quarter! (We hope)

It’s useful to reflect on what we’ve learned. (Seriously, it helps with the learning process to do reflection.)

Think about what you’ve learned in labs, lecture, and quizzes this quarter. Think about a question or a problem that you can answer now that you would not have been able to at the begining of the quarter. Write it down in the notes.

Then, the other people in your group will try to answer it or talk about how they would go about solving the problem using things they learned in class. Did they have the same answer as you? Did they highlight any different parts of their learning?

The best learning here will come from questions that aren’t one-line answers (“how do you git push from the command line” won’t be a useful reflection, for instance). A task you can imagine doing with a few lines of a bash script, a strategy for debugging or choosing good test cases, a workflow for setting up a project, a choice of Java feature for a particular program, and more could be good examples of things to discuss.

Open Discussion

Spend the remainder of the time discussing general computing/CSE department/course/research topics with your group and tutor.

Write down in notes before starting the questioning out loud (tutors, don’t answer questions until folks have a chance to think and write!) What is a question you have for your tutor/lab TA/classmates? Some potential conversation starters are below, but don’t be limited to these:

  • What classes are you taking?
  • Are you involved in any student organizations?
  • Have you done an internship recently?
  • What topics from CSE15L come up again and again in your courses?
  • Are you involved in research?
  • What has been your favorite/least favorite course at UCSD?

Once you’ve spent a few minutes thinking and writing something down, start asking! Feel free to mix groups, listen in on other conversations, move around the room, and ask these questions to the lead TA, too!

Lab Report 5

Part 1 – Debugging Scenario

Design a debugging scenario in the spirit and style of the ones above. Write your report as a conversation on EdStem. It should have:

  1. The original post from a student with a screenshot showing a symptom and a description of a guess at the bug/some sense of what the failure-inducing input is. (Don’t actually make the post; just write the content that would go in such a post)
  2. A response from a TA asking a leading question or suggesting a command to try (To be clear, you are mimicking a TA here.)
  3. Another screenshot/terminal output showing what information the student got from trying that, and a clear description of what the bug is.
  4. At the end, all the information needed about the setup including:
    • The file & directory structure needed
    • The contents of each file before fixing the bug
    • The full command line (or lines) you ran to trigger the bug
    • A description of what to edit to fix the bug

You should actually set up and run the scenario from your screenshots. It should involve at least a Java file and a bash script. Describing the bug should involve reading some output at the terminal resulting from running one or more commands. Design an error that produces more interesting output than a single message about a syntax or unbound identifier error – showcase some interesting wrong behavior! Feel free to set this up by cloning and breaking some existing code like the grading script or code from class, or by designing something of your own from scratch, etc.

Part 2 – Reflection

In a couple of sentences, describe something you learned from your lab experience in the second half of this quarter that you didn’t know before. It could be a technical topic we addressed specifically, something cool you found out on your own building on labs, something you learned from a tutor or classmate, and so on. It doesn’t have to be specifically related to a lab writeup, we just want to hear about cool things you learned!

A Note on Grading at the End of the Quarter

We will try, but there might not be a resubmission window for lab report 5, so do your best to be thorough, creative, and clear in your submission.