it by a pristine copy:
rm -rf pintos/src/tests
- cp -R /usr/class/cs140/pintos/pintos/src/tests pintos/src/tests
+ cp -R /usr/class/cs140/winter13/pintos/src/tests pintos/src/tests
+
+ (make sure you are using the correct version of Pintos for the current
+ offering of the course; it may be in a different location than the
+ example above)
3. Run "make clean" in the top-level directory, to get rid of
any binaries or objects mistakenly included in the
passed, but all yours failed) then you should contact the
group. Otherwise, use the grade report that you produced.
- Grade reports can vary a number of reasons: QEMU is not
+ Grade reports can vary for a number of reasons: QEMU is not
fully reproducible, Bochs sometimes has reproducibility
bugs, the compilers used on different machines may produce
code with different behavior, and so on. Finally, it's
documents and their code. Both are lumped into a single grade, taken
out of 100 points.
-A suggested form to use for grading each project is in hw<N>.txt in
-this directory. You should copy this file into each submission
-directory and delete the lines that do not apply.
-
-The subtractions for each kind of problem with a submission are
-suggestions. You are free to modify them. You can also add your own
-subtractions for problems that are not listed.
-
-When you add up the subtractions for a project, those for the OVERALL
-section are not capped at any particular maximum. Those for
-individual problems are capped at the value of the problem.
+The form to use for grading each project is in hw<N>.txt in this
+directory. You should copy this file into each submission directory
+and delete the lines that do not apply. The grading form is divided
+into sections, one for each problem, and an OVERALL section. Each
+section has its own set of deductions, with a cap on the total
+deductions for that section. To compute the overall design score,
+first compute the (capped) deductions within each section, then
+subtract the section deductions from 100. If the final score is less
+than zero, round it up to zero.
IMPORTANT: Be critical in grading designs. Most submissions will pass
most of the tests, which means that they get almost 50% of the grade
It is better to take off lots of points on projects and thereby give
students more realistic expectations about their final course grades.
+At the same time, don't be unfair. You should only deduct points in
+situations where students should have known what was expected of them.
+For example, don't invent your own standards for coding style based on
+what you think is "right": stick to what is documented, or what any
+reasonable person might assume.
+
Grading Design Documents
------------------------
- Missing: The question is not answered at all.
- Non-responsive: The response does not actually answer what
- is being asked. (If the question does not reasonably apply
- to the solution chosen by the group, then the answer should
- explain why it does not.)
+ is being asked. (If the question does not reasonably apply
+ to the solution chosen by the group, then the answer should
+ explain why it does not.)
- Too long: e.g. a "25 words or less" response takes a whole
- page. These qualifiers aim to save the group's time and
- your time, so don't waste your time in these cases.
+ page. These qualifiers aim to save the group's time and
+ your time, so don't waste your time in these cases.
- Too short: The response is evasive or excessively terse to
- the point that you don't feel confident in the answer.
+ the point that you don't feel confident in the answer.
- Grossly inaccurate: When you examine the code, you find that
- it has no resemblance to the description.
+ it has no resemblance to the description.
- Not implemented: The functionality described in the answer
- was not implemented. This often happens when a group runs
- out of time before implementing the entire project. Don't
- give credit for a design without an implementation.
+ was not implemented. This often happens when a group runs
+ out of time before implementing the entire project. Don't
+ give credit for a design without an implementation.
Take off some points (use your judgment) for:
+ - Conceptual errors: Statements, assumptions, or strong
+ implications made in the design document are incorrect,
+ e.g. assuming that unblocking a thread immediately schedules
+ it.
+
+ - Minor inaccuracies: Some aspects of the code do not match
+
+ - Partial response: Multiple questions are asked, but only
+ some of them are answered.
+
+Minor issues (take off only a few points, and only if the problem
+is severe):
+
- Capitalization, punctuation, spelling, or grammar: An
- occasional mistake is tolerable, but repeated or frequent
- errors should be penalized. Try to distinguish grammar
- errors made by non-native speakers of English, which are
- understandable, from those made by others, which are less
- so.
+ occasional mistake is tolerable, but repeated or frequent
+ errors should be penalized. Try to distinguish grammar
+ errors made by non-native speakers of English, which are
+ understandable, from those made by others, which are less
+ so.
In Emacs, it is easy to check the spelling of a word: put
the cursor on or just after it, then type M-$. You can also
make it highlight misspelled words with M-x flyspell-buffer.
- - Minor inaccuracies: Some aspects of the code do not match
- its description.
-
- - Conceptual errors: Statements, assumptions, or strong
- implications made in the design document are incorrect,
- e.g. assuming that unblocking a thread immediately schedules
- it.
-
- - Partial response: Multiple questions are asked, but only
- some of them are answered.
-
- Excessive redundancy: The answer restates much of what is
- specified in the assignment.
+ specified in the assignment.
Instructions for recurring questions:
less.
- Deduct points if the required comment on each declaration is
- missing. (The Introduction states "Add a brief comment on
- every structure, structure member, global or static
- variable, and function definition.")
+ missing. (The Introduction states "Add a brief comment on
+ every structure, structure member, global or static
+ variable, and function definition.")
- Deduct points if the response does not describe *purpose*.
- We can see the type and the name of each entity from their
- declarations. But why are they needed? If the comments
- themselves adequately explain purpose, then that is
- sufficient.
+ We can see the type and the name of each entity from their
+ declarations. But why are they needed? If the comments
+ themselves adequately explain purpose, then that is
+ sufficient. Comments should provide information that is not
+ obvious from the code. A common mistake is for a comment to
+ duplicate information in the variable or function name. For
+ example, a variable "pageFaultCount" might have the comment
+ "count of page faults"; that's not much help!
---- RATIONALE ----
important flaws:
- Inconsistent style: indentation changing randomly between 4
- spaces and 8 spaces per level, between BSD and GNU brace
- placement, and so on. (The Introduction states "In new
- source files, adopt the existing Pintos style by preference,
- but make your code self-consistent at the very least. There
- should not be a patchwork of different styles that makes it
- obvious that three different people wrote the code.")
+ spaces and 8 spaces per level, between BSD and GNU brace
+ placement, and so on. (The Introduction states "In new
+ source files, adopt the existing Pintos style by preference,
+ but make your code self-consistent at the very least. There
+ should not be a patchwork of different styles that makes it
+ obvious that three different people wrote the code.")
- Bad style: such as no indentation at all or cramming many statements
- onto a single line.
+ onto a single line.
- Many very long source code lines (over 100 columns wide).
- Lack of white space: consistent lack of spaces after commas
- or around binary operators that makes code difficult to read.
+ or around binary operators that makes code difficult to read.
- Use of static or file scope ("global") variables instead of
- automatic, block scope ("local") variables: one student
- submission actually declared 12 (!) different global
- variables "just so we don't have to make a new var in each
- function". This is unacceptable.
+ automatic, block scope ("local") variables: one student
+ submission actually declared 12 (!) different global
+ variables "just so we don't have to make a new var in each
+ function". This is unacceptable.
- Use of struct thread members instead of automatic, block
- scope ("local") variables: sometimes it's not obvious
- whether this is the case, but subtract points when it is.
+ scope ("local") variables: sometimes it's not obvious
+ whether this is the case, but subtract points when it is.
- Code copied into multiple places that should be abstracted
- into a function.
+ into a function.
- Gratuitous use of dynamic allocation: e.g. a struct that
- contains a pointer to a semaphore instead of a semaphore
- itself.
+ contains a pointer to a semaphore instead of a semaphore
+ itself.
projects / pintos-anon / blobdiff