 Okay, well, hi everyone. I know most everyone's interested in assignment too. In the future, if you have any questions about anything to dealing with course content, or also midterm questions, of course, we'll cover these in these recitation sessions. I'm assuming like this one, most of these will focus on the assignments. Just real quick, we have, of course, if everyone's seen the announcement on Piazza, we have undergrad hosted TA assignments help sessions, some today, Friday, starting at 6, 6, 7 p.m. And of course, the TAs have office hours. So again, there's plenty of help available both today and Friday, and on Monday. If you have any other specific questions, please feel free to contact us. Preferably by Piazza, either a private question if you have something specific to ask about your particular assignment, or again, public questions when possible. I checked earlier today, and roughly 242 students have yet to submit anything to Gradescope. Roughly about 100 students are done with the assignment, and about 30 or 40 are still failing some test cases. So if you, again, haven't started, I'd recommend at least getting started on this assignment as soon as possible. It's very easy to get stuck on some of these test cases, and you don't want to have to rush the last minute. This is the third time we have a presentation on this assignment. I'm not going to really cover the specifications today. I'm more or less just going to discuss a couple hints. One quick comment about Bandit version two. Again, most common problem people have is still just make sure they put the readme file along caps, and make sure you upload a plain text file, no unicorn characters, no unusual characters, so we can extract your name out of the readme file and give you credit. If you're not getting credit, again, just try cutting and pasting into notepad, check the formatting of your document, or of course, then there's a question about it. 204 secures this house. The one thing I found valuable was one of the comments a student made. He said, basically all the test cases, I recommend thinking about it like it's real life. And this does solve most of your problems. For example, like when you're turning the key, what should people be allowed to do? What should people not be allowed to do? As mentioned many times, command line input sets the owner of the house and all the initial keys, and then you should use something like get line or in Python input command to take standard input to receive commands and send responses out. Most people are not having too much trouble with make files. This is the purpose of the first assignment. C C plus plus make file support is very easy. Python, your make file should be pretty much identical to what you did in assignment one. Java, make sure you see the piazza posts that references. If you use the Java file names, again, make sure you always submit run.sh with your assignment. If you include the commands, again, changing the word commands to secure house, you generally shouldn't have any trouble. Informally, about two thirds of the class is doing this in C C plus plus. Most everyone else is using a mix of either Python or Java. Also another common problem is make sure you have an exit condition. Again, there's a blank line at the end of all the test cases. They should finish the program or should close it down. Again, if you're just doing this in C plus plus, just make a if case where if input is empty, program quits or program exits. Looking at the test debug script is very useful. By looking at this code, you can really see how the auto grader is going to work. You can also put your sample input into a text file and use redirection like secure house piping in test case to test your code. Another good recommendation I have is to have look at the actual specifications seen here. Take these specifications, copy them into a document, make sure you implement every single statement here. Some of those common problems students are having is some minor aspect or some requirement of the specifications that have not been fully implemented. There are a couple things beyond what the specification states, and these problems can be solved again by thinking about the problem or implementing what you think makes sense. Or again, obviously checking piazza. Most of these type of problems have been discussed already. Most people will get the test scripts working. But again, as I mentioned earlier, 38 students or so are still running into subtle problems with some of the complicated scripts. Also, double check spelling, spelling mistakes, check for syntax errors. Slightly different spelling mistakes or even debug code, printing the bug errors obviously will cause your cases to fail. The core of most problems is on the insert key, turn lock, enter house steps. Does the lock actually test a person? Does it test a key? Again, keep in mind that the house is simulating a smart lock. If you have someone inserting a key and then you have another person come by and they're inserting a key, obviously the first person took the key out. There's only one lock. Forget about keeping track of multiple individuals inserting keys. You also need to make sure you can account for other situations occurring between these steps. It is entirely possible for a person to come and insert a key, and then someone else to check and see who's inside the house, and then that same person to turn the lock. Again, keep in mind this is a smart lock. If person A turns key A, person B comes up and tries to turn the lock. The smart lock says, hey, you're not person A. You're not the person who inserted this key. He's going to be denied access. Again, make sure when someone else tests the lock, if that person didn't insert a key, they don't get access. One user can't insert a key, have another user turn the key, and yet a third user entered the house. Only the same person can do each of these steps. And what happens when that does happen? If someone does insert a key and someone else tries to turn the key, whatever, what key are they turning? Are they turning the key that's currently in the lock or the key that's in their possession? Buggling state is also important. If you're running some sort of command, an earlier case shouldn't mess up a later case. This example, let's say if you run who's inside. If you run a couple steps after that and try who's inside again, make sure your earlier code does not set any variables, change anything that messes up later cases when you run it. I don't believe Gradescope has any tests that really test bad syntax or completely invalid syntax. Most of the checks in Gradescope are checking for situation errors, logic issues. So again, focus on spelling mistakes, focus on logical issues, try creating test cases that you think should fail, should succeed, and see what happens to your code. As always, Piazza is very valuable. Make sure you keyword search Piazza. Feel free to ask questions of any of us if you have any situations. If you're completely stuck, again, please just shoot us a private message. We should be able to give you a hint or something. And again, just think about the situation logically. Again, you can't put multiple keys in a door. Earlier keys are removed before new keys inserted. If you change locks, make sure you invalidate prior locks, and so forth. It's pretty much all the hints I have for this assignment. Does anyone have any questions? Again, please use the group chat or post any questions here.