Course Software
1 Pyret
We are using the programming language Pyret for the programming assignments in this course. The documentation for Pyret is at http://pyret.org/docs/latest; some assignments will link to specific parts of it to highlight particular features. You don’t need to install Pyret; it runs from any Web browser (though Chrome tends to work the best), at https://code.pyret.org. The first few labs will acquaint you with programming in Pyret.
2 Captain Teach
For some assignments, we will use a service called Captain Teach that manages submissions and peer code review. Instructions for submitting to Captain Teach (sometimes abbreviated CT) are included with each assignment.
3 Reporting Bugs
While using the tools and support code for the course, you might encounter behavior that you don’t expect and seems wrong. Sometimes, this will be a misunderstanding on your part, and other times, it will be a genuine flaw in the system you’re interacting with.
If you want to report an assignment-specific problem (like the description in the assignment is inconsistent or the support code has a bug), email me at jpolitz@cs.swarthmore.edu and let me know right away.
If you want to report a bug in Pyret, emailing me is also fine. However, if you have an account on Github (https://github.com), I’d also appreciate it if you file an issue at https://github.com/brownplt/pyret-lang/issues/new, where both myself and the Pyret team can have a look.
Wherever you report the issue, remember that reporting problems is a skill that you should be developing as a programmer. Sometimes, working through the problem report will even help you find that the issue was in your own code rather than in the system. Before you submit a report:
Reduce the problematic program or input to be as small and isolated as possible. This may involve starting a new (tiny) program or function that demonstrates the issue.
Provide as much other information as possible: screenshots, output, etc.
Describe what you expected to see that was different than what actually happened. This is important, because sometimes the response to a bug report is simply to explain why surprising behavior is the way it is, and provide better documentation. If you don’t explain what you expected, it’s not clear what the bug is.
Following this process makes responding to and fixing problems go much more smoothly.