The University of Melbourne
School of Computing and Information Systems COMP90045 Programming Language Implementation
Assignment 2, 2019
Released: Friday 12 April 2019
Anonymised parser/pretty-printer submission: Tuesday 16 April at 23:00 Reviews due: Monday 29 April at 23:00
Ob jectives
To generate feedback on the parsers and pretty-printers submitted for assignment 1, and to provide an opportunity to learn from other teams’ solutions. To practice reading and understanding software. To practice the provision of constructive critique.
Background and context
This is the second stage in a larger task: to write a compiler for a procedural language, Goat. In the first stage, teams submitted parsers and pretty-printers for the language. Each student will now review two randomly allocated project submissions (none of which will be their own). Stage 3 will be to write a semantic analyser and a code generator. The remaining deadlines are
Stage 2a 16 April at 23:00. Team effort: Re-submit, anonymised, using “submit COMP90045 2”. Stage 2b 19 April. Individual: Review tasks will be available through the “Peer Reviewing”
menu item on the LMS.
Stage 2c 29 April at 23:00. Individual: Deadline for completing double-blind peer reviewing. Stage 3a 17 May at 23:00. Team effort: Submit test data.
Stage 3b 27 May at 23:00. Team effort: Submit compiler.
Code peer reviewing
Assignment 1 will be marked as usual and we will provide feedback and a mark. The peer reviewing activity is not a substitute for that and it will not have any impact on marks for Stage 1, only on marks for Stage 2.
This second stage gives you an opportunity to see other solutions and compare them to your own, while preserving some privacy through the anonymity of double-blind reviewing. Thus a central aim is to provide an additional source of learning. Other aims include:
• It should add to (and diversify) the feedback you receive in this subject.
• It should help develop important skills in the reading and understanding of other people’s
code, as well as in providing and receiving critique in a polite and constructive way.
You can access the review tool from the COMP90045 LMS site. For the review part, you are not asked to assign any marks to the work you are peer reviewing. There is an online review form that will guide you as to how to structure your review and which aspects you may want to assess.
Procedure
Re-submission. Since the reviews are intended to be anonymous both ways, you will need to submit your code again. Only one person per group should submit. The steps required are:
1. Log in to nutmeg2 (see instructions on the LMS).
2. Anonymise all of your code, that is, remove all names, login names, enrolment numbers and
team names from each of your files—anything that might identify the group. 3. Submit the anonymised files, including the Makefile, using (note the ’2’):
submit COMP90045 2 Makefile …
Re-submission should be done by Tuesday 16 April at 23:00.
Reviewing. Two submissions will be allocated for you to personally review. You can access the tasks through the “Peer Reviewing” menu item on the LMS, from 19 April. You will receive each review task in the form of a compressed file with a name like parser.tar.gz. To retrieve the contents, use ‘gunzip parser.tar.gz; tar xvf parser.tar’.
The tasks will be split into two separate pools, and we will let you know which pool you should access. When you access your pool, you should find two submitted tar files with code waiting for you to download and review. Submit your two online reviews by Monday 29 April. Reviews that you receive should be shared with your team.
Assessment
This peer-review part of the project counts for 4 of the 30 marks allocated to project work. Marks are awarded for the quality of your reviews. For each review task we allocate 0, 1 or 2 marks, according to this scheme: 0 for no review submitted, 1 for a poor review, and 2 for a decent review that is of value to the reviewees.
How to write a good review
An important aim of Stage 2 is to get all teams to be as well prepared for Stage 3 as possible. Since we all work on the same challenge, you should be in a very good position to provide useful feedback to your peers. For example, you will have your own set of test data to use when you assess their code.
Remember to praise positive aspects, and be clear and specific when you highlight weaknesses. A good review is careful and constructive, and if needed it is detailed. But note that a careful review is not necessarily a long review—the amount of feedback will often depend on the quality of the work being reviewed. A good review not only pinpoints flaws; it also suggests how to repair them. The online review form will guide you through aspects that should be considered when you evaluate code.
Harald Søndergaard 11 April 2019
2