Week 6

Week 6 – IR and Projects

Table of Contents

Readings & Due Dates

Read:

TODOs:

Lecture Materials

Lecture 11 (Tue 05/03) Handout

Lecture 11 (Tue 05/03) Notes

Lecture 12 (Thu 05/05) Handout

Project Milestone Tests

For your first task, you need to meet with your group (reminder – group assignments here on Piazza) and decide on what your first milestone ought to look like. There are a few main goals here:

  • Meet your group and start communication with them
  • Commit to some test cases you’ll pass by the end of week 7
  • Report back on changes you think will be needed to the AST and other shared interfaces, for cross-team communication

All of these goals apply to both the ChocoPy teams and the teams working on the big compiler!

You will submit a Pull Request to:

  • For compiler A: https://github.com/ucsd-cse231-s22/chocopy-wasm-compiler-A

  • For compiler B: https://github.com/ucsd-cse231-s22/chocopy-wasm-compiler-B

  • In the directory designs/, add a file called <projectname>-design.md, with the following contents 10 test cases that your team commits to passing by the end of week 7. They should be meaningfully different from one another. Most of these will be Python programs, like print(len("abcd")) should print 4 for the strings group.

    In particular, some of the more complex topics like closures, memory management, or optimization might not have obvious week-1 candidates. If you’re not sure what you’ll be able to get done in a week, ask. There is probably some other kind of test you can write other than a Python program.

  • A list of all changes you want to make to the AST, IR, and built-in libraries to support your test cases. This can be through a combination of actual changes you make and suggest via PR (e.g. change ast.ts, then push the commit and include it in the PR), and listed descriptions in your design.md file. For AST/IR changes, write out in detail what’s an expression, what’s a value, what’s a string, etc. For new files like memory.wat, describe which functions will go there.

  • A description of any new functions, datatypes, and/or files added to the codebase. These can be actual code diffs in the PR or written in your design.md.

  • A description of the value representation and memory layout for any new runtime values you will add. These should be described in design.md rather than implemented directly.

If you’re working on ChocoPy, think carefully about if your tests should span multiple features, or if there’s a feature you want to focus on first. You will still need to make all of ChocoPy work by the end of the quarter, but you might prefer to make simple cases work across all features, or finish e.g. all of lists before moving on.

You might not need to fill out all of these sections depending on your project (aside from having 10 useful scenarios/tests you want to make work). Just note it explicitly if you don’t think you’ll make a particular category of changes.

On Gradescope, you’ll submit a group assignment with a link to your PR to the “Project Milestone Proposal” assignment.

We might give you feedback next week nudging you to be less (or more!) ambitious, and coordinate across groups that are trying to add similar library functions, features, or AST constructs.