PL: FAQCommon frequently asked questions.

• Your first place to ask (all) questions is piazza (see the description, and the Email and Piazza Policies page). That should cover most questions — you can even ask anonymously to the class if that helps.
• If your question involves homework code, then the first thing to do is to ask yourself if this is a real question, rather than “here’s my answer is it correct?” kind of a thing (aka “help me debug my code”). If it is, you should avoid it. Not only are these questions unfair to the other students, part of learning is dealing with your own bugs.
• If you still want to ask your question, then you should, of course, avoid a public question that shows your code — piazza allows you to ask a private question. Please use “Instructors” to include the whole course staff instead of relying on a particular person.
• But note that private questions are only for real questions — in other cases, you should just send out email.

Your first stop is always piazza, possibly in the form of a private question if there’s bits of your solution in the error. In some rare cases you can also email me and/or anyone on the course staff.

In any case, before you reach out to your screenshot tool, please consider doing so a very-last resort. Read the policy page for more details. Specifically, the error that you’re talking about is a few characters on the screen that you can always copy (even from error popups (with a right-click)) and paste, which would make it easier to send, easier to read, and easier to handle.

This is not really a question, but rather a common issue that many students have. Just like the material, it’s best if you use precise language. Specifically, avoid the following commonly misused terms:

• “Variable”. As discussed in class, almost the whole semester (and homework) will not use mutations, and therefore we’re going to have “identifiers” that are “bound” to values. These values will not vary, and therefore don’t call them “variables”.
• “Statement”. Many mainstream-ish languages have a distinction between “an expression” and “a statement”. This is best seen by the fact that there’s a distinction between “an if statement” and “a ternary conditional expression”. Like many modern functional languages, Racket does not have that distinction: instead, everything is an expression. This greatly simplifies things (languages with statements and expressions pretty much always have a BNF with a separate “expression” non-terminal), so we’re going to follow that and have no statements in our languages.
• “Method”. A “method” is an OOP term for a function that is associated with a specific object, possibly via a class. It is identified by having such an object as an implicit (usually) this or selfargument. Unless you’re talking about these things in particular, you should use the term “function” instead.

The homework are intended to mostly go along as we go over the material. A red link is for stuff that is not available yet. If you really want to some future homework now, then you can dig through the future class notes and find what’s needed. But this is not recommended, and even less so if code from these notes is needed.

If you think that this is a mistake then ask on piazza.

Please just do the best you can and when we get closer to the deadline, if you still need more time, then ask for it then. I usually try to accommodate such requests when they’re reasonable and when possible. (In some cases the next homework depends on the solution for the current one, so I need to publish the solution, which would make it impossible to continue working on the HW.)

But if it’s because of some reason that affects many people (for example, there’s some university event that I’m not aware of), please post a note on piazza so that other’s can +1 it, and I’ll move the due time for everyone.

I don’t give penalties for late submissions, and I usually close homework manually. So it’s quite possible that a submission is possible past the deadline, and submissions are fine at that time. But you should not rely on this so if the deadline is approaching, be sure to submit whatever you have, and if you need more time, then ask me.

But more generally, for best results, don’t start working on a homework the day it is due. Start much earlier, and be done with it earlier. You’ll feel better.

It’s a handin directory that accepts anything, and can be conveniently used in two common situations:

• You try to submit and it turns out that there are still problems. Switch to scratch and get a server-backed copy so you can work without ever saving local files.
• Later on it will be useful as a kind of a shared space where you can synchronize work with your partner.

Note, BTW, that I reset the scratch space from time to time, so it’s intended for working on your submissions, not as a generic storage thing. (But I do keep backups, in case you lose something…)

The Style Guide is not intended to be an exhaustive list of everything you should ever know to avoid such penalties. Attempts to make it so are inherently futile and frustrating. On one hand, they are futile since there can always be another way to write code badly, making it a never-ending chase after some notion of completeness that is never achieved. However, such a chase will make it more and more verbose, leaving students with a huge list of rules to go over, which will lead to frustration all around: students will be frustrated by its length, or by the verbosity of the precise-but-verbose language that will result from generations of fixes, or by the fact that the grading will look more like a list of mistakes on your tax return forms. Graders will also be frustrated with finding the places where some rule is mentioned, and the chore of keeping the list updated.

Finally, what if such a list did exist, was painfully comprehensive, and people could read and follow it completely? Even that supposedly ideal outcome is not good at all: taking out all human considerations from making your code readable means that you’ll stop thinking about how to make your code nice and readable for the people you work with. There’s different expression styles, both at the lowest level of indenting your code through the highest level of code design and organization. You really should learn to think about all aspects of your code and make it as readable as you can.

That’s not to say that there is no place in the world for style guides. They’re useful in getting the obvious details laid out for newbies, they can help in settling on certain decisions when there are different opinions, and they are therefore first and foremost a useful tool for humans to communicate with each other. In your case, you are expected to ask when something is unclear or debatable, and you need to learn good habit and respect how code is written. Just as a quick example: you should grow to be careful to respect the style in any project you work with. For example, in modern JS/Python/etc projects you get to decide on using single-quotes or double-quotes for strings — and in almost all cases, the people who work on a project have a specific preference; it is therefore good to read existing code and see what the convention are even when the project doesn’t have its own style guide. In time, you would hopefully grow to a point of appreciating such issues enough to write your own guide for people who want to work with you.

Look in the graded file (graded.rkt) — it has two important bits of information in the header section at the top: first, a Graded by comment should show you which grader did the grading and therefore should be your contact point (see the table). The second important bit is a Grading File comment: the graders receive anonymized filenames, so you need to identify your file in case of grading questions.

Please realize that grading resources are limited, and in some cases a grading mistake should apply to other students too, so dealing with such problems might take a while.

Did you go over the Tips page? Pay extra attention to the Keeping Up section.

A good way to significantly boost your overall knowledge is to become a tutor. It might seem that understanding the material is difficult for you to follow — but if you’re teaching someone else, it will help you organize what you know, and as you’re explaining it, things will become clearer to yourself too.

First: Don’t Panic!

Remember that you have many ways to evaluate your performance. In particular, use the grades.txt file (when it becomes available in the “Summary” row on the handin server) to see your current estimated numbers: your grade, the possible grade range from now to the end of the semester, and your percentile. Remember to also compare your numbers against the class charts.

If you’re worried about PLQ grades, then read through the About PLQ page. It has a thorough explanation of the format. In many cases students are unaware of these details resulting in being redundantly over-stressed about it. A great way to improve your performance is to suggest a question!

If you’re still worried about your performance, please do schedule a meeting to review your performance and discuss what could be done to improve things (if needed). People are often over-stressing for many reasons, and in many cases they have nothing to be worried about — going over your numbers in a meeting is a good way to avoid such stress and be more focused on the material.

Short answer: no.

Long answer: such projects, extra homework, etc are problematic in several ways. First, a problem with these end-of-semester requests is that doing anything after the semester is done is technically difficult enough to be impractical. At that point there is no course staff so it’s only me who would need to handle such things.

A more severe problem is that such things are inherently unfair to other students. It might be that you’re looking at a potential failure so you’re more stressed, but if there’s an option to improve grades via extra work then almost everyone will want to do it, even ones that have very good grades. This means that these kind of extras become regular homework, not really extras — and this means that you’re actually asking for another homework for everyone.

The karma grade is special in that it doesn’t follow the same rules as homework/exam/PLQ. For exams (and PLQs), the grading is usually “positive grading”, where you’re getting some points for doing things right; and for homework it’s usually “negative grading” where your grade starts from a 100 and you get penalized for problems. The karma grades, however, are neither of these. There is no list of things that you should do to get a 100, and there is no tracking of bad things you did with penalties.

So the bottom line is that it’s just a combination of a bunch of numbers that are factored in (for example, various piazza stats, grading bonuses, etc), combined into a single number and the whole thing is done so the final number is somewhere on a range that looks like a normal grade — and like everything else, used in the context of all grades.

• Access the PLQ page on Safari (must be Safari, since it’s the only one that is permitted to install things on your home screen).
• Tap the icon in the bottom-middle of the screen (the one that looks like a box with an arrow coming out of the top).
• Scroll down and tap “Add to Home Screen”, which will install the site as a PWA.

• Check that you’re on a network that allows high ports (e.g., if you use Nuwave-guest without a login it considers you a “guest” user, and the ports that you can use are restricted to a few well-known ones like http and ssh).

• To check for errors, you can try to use some utility to get a more precise diagnostic. For example, you can run this in DrRacket or just plain Racket:

  (require pl/client)
  (define h (handin-connect "pl.barzilay.org" 9770))
  (handin-disconnect h)

  and see what it complains about.

• The handin server uses a certificate that is signed by letsencrypt.org. This should be included in your OS root certificates, but make sure that your OS is updated if there are problems.