Lab 1: Discord Chatbot

Starter Code

Get the starter code on GitHub Classroom! This lab is due September 14, 2021.

Docker

[This should look familiar from Lab 1] See the course Docker instructions for details about how to work on your own machine.

If you would prefer to use knuth, you can open up a tool that supports SSH (e.g. Terminal on a Mac, PuTTy on Windows) and run

ssh username@knuth.cs.hmc.edu

and then enter your password for the server. If you used the lab machines at Harvey Mudd in the past, this is the same account.

If you still can't get Docker or knuth working this week, not to worry! I'm currently reaching out to Tim Buchheim (our department's system administrator) to make sure everyone in the class who couldn't access knuth will be able to do so next week. In the meantime, if you have Python3 installed on your computer, all you should need to do is install one more package to get the chatbot to work:

pip3 install discord.py

Chatbot

We’ll use Discord for communicating with each other this semester. There will be channels set up on our Discord server for each of the assignments; additionally, you should feel free to create your own channels for communicating with your teammates.

Stop now and make sure that you have access to the CS159 Discord Server.

Once you have those steps working, you’re ready to improve upon your bot.

The only requirement is that you must modify the make_reply function in discordbot.py to respond to messages from Discord users. Your function must make use of regular expressions using the Python re library, though it's your choice which of re.search, re.match, etc. you'd like to use. In particular, you should use each of the following at least once (10 points):

• Regular expression groups ((...)). (2 pts) Note: these should be used to capture content that your chatbot processes later; don't just put parentheses around a regular expression and then ignore the group.

• Character classes ([...], \d, \D, \w, \W, \s, \S, etc.) (2 pts)

• Regular expression quantifiers (+, *, and/or {...}) (1 pt)

• Disjunctions (|) (1 pt)

• At least one of the following (4 pts): a lookahead ((?=...) or (?!...)), an anchor (^ or $), or a substitution (e.g. \1).

You can choose the domain and personality of your both. It can be a Rogerian psychologist like ELIZA, or you can choose a different domain. If you choose a different domain, make sure it’s one where you can reasonably expect repetition, so regular expressions will be effective.

Your inclination may be to keep working on this bot until it behaves perfectly; this is not the goal of the assignment. Instead, you should aim to build something interesting enough to observe and comment on in action, as the majority of your writeup will be based on your observations of your bot. Note that if a bot satisfies the requirements above and allows you to answer the questions below, it is sufficiently complicated (even if it seems "too simple").

On Debugging in Python

For some assignments this semester, code may take a long time to run (minutes or even hours). This can make debugging with print statements painful: since it might be several minutes before your code runs into an error, if it takes a few tries to find which print statements will find the information you need, you could spend lots of time waiting in between each try. That's frustrating and no fun, so we're going to try to make things a bit easier using the ipdb (Interactive Python DeBugger) module. This is a slightly nicer version of the built-in pdb package, though if you're having trouble getting ipdb running, you can do almost the same things with pdb instead. This will allow you to do inline debugging in your code: that is, to run code such that, when it reaches a point you're interested in inspect or hits an error, it will pause right there and give you an IPython console you can use to interact with your variables in context using Python. (It's a bit like gdb for C code if you've used it, but with a Python interpreter!) You are not required to use this to debug, but I strongly recommend trying it out and exploring what it can do, as it can save you a lot of time!

If you want to use ipdb, you should first import it (it's installed on both the Docker image for the class and knuth):

import ipdb

Next, you'll want to set where it interrupts the code to let you interact with it. If you have a specific point in the code where you want to stop and interact with it, you can just put the following line of code just before where you want to look:

ipdb.set_trace()

If you're not quite sure where an error might arrive but would like the chance to inspect the code if an exception is raised, you can use a special "context manager," which wraps the code you want to execute with an instruction to use the debugger if an exception occurs:

from ipdb import launch_ipdb_on_exception

# other things you might have set up before the code you run

with launch_ipdb_on_exception():

[...code that might have issues...]

When you run your code the normal way (e.g. python3 discordbot.py), if there is an exception raised, the above code would start the ipdb console. Once the debugging console starts up, you can use it like you'd use a Python interpreter: you can print variables from the current step of code execution to see their values, define new variables, and even write short functions. (I've been known to write gross Python list comprehensions to systematically check for broken things.)

In addition to Python syntax, the debugging console has special commands you can use to navigate the code from which the debugger was invoked. Here are a few special commands it supports:

• ? [function]: Prints the docstring for the named function.

• next: runs the current line of code and proceeds to the next line of that function or the function that called it. Can also be invoked with just n.

• step: like next, but runs the current line of code until either a new function is called (at which point it'll place you in that function's context) or the next line of the function is reached. Also invoked with s.

• continue: keep running until the next breakpoint or the code completes. Also invoked with c.

• p [variable] (or pp [variable]): Prints (or pretty-prints) the variable or code snippet provided.

For slightly more information on special debugger commands, you can check out this handy cheatsheet or the longer pdb documentation.

Turn In

On Gradescope, you should submit your completed discordbot.py file with your implementation. (1 point for a file with any changes)

You should also submit an analysis.pdf report that describes your Bot. That report should have the following sections:

• Overview: An introduction to your DiscordBot. What domain does it work in? What is its personality? (6 points for completeness and clarity)

• Regex Description: Clearly describe how you make use of each of the required regular expression features in your make_message function. (8 points for completeness and clarity)

• Analysis: Describe at least one interaction with your bot that worked well, and at least one interaction with your bot that works poorly (or not as one might expect). You should include a screenshot or transcript of your Discord conversations in your writeup. This should include explanation not just of what happened, but why it happened, and why that was good or bad. (14 points for completeness and clarity)

• Future Directions: Thoughtfully describe how you would address the existing shortcomings of your bot if you had more time. For example, what would you do to make your bot better if you had another week to work on it? If you were going to use this code as the starting point for a final class project? (10 points for completeness and clarity)

The starter code has a Markdown file that you can use to write your analysis. (For help doing things like putting a screenshot of your chat into your writeup, feel free to consult this guide.) To turn your markdown into a .pdf file, you should use pandoc:

pandoc analysis.md -o analysis.pdf

If you're having trouble getting pandoc installed and running on your own machine, you can refer to the Docker instructions for a way to use Docker to do this. Please add your analysis.pdf file to your GitHub repository so that we can view it for grading. (1 point for having a nonempty analysis file).

Last note: the default version of the analysis.md file uses horizontal lines to separate sections. Unfortunately, the Docker-compatible version of LaTeX is bad at parsing these, so you may get the error:

! Missing number, treated as zero.

<to be read again>

\protect

l.72 ...enter}\rule{0.5\linewidth}{\linethickness}

Don't worry if this happens; just delete the horizontal lines (---) in between sections and it should work fine.