CS 418 – Common components of MPs

1 Extensions

Deadlines have two purposes: to help you manage your time and to give us have enough time to grade your work.

Before a deadline comes due, you can extend it by going to the submission page and entering an extension request. These are routinely granted without further review, but too many extensions (especially near the end of the semester) can create a grading burden we can’t handle and may result in some being rejected. For that reason, please provide your rationale in the request.

The only notification of a successful extension request is a changed deadline on the submission page. Rejected requests are communicated via campuswire DMs.

2 Regrades

There are four types of regrade requests:

Grading errors
If we mis-graded your submission, let us know in a to-instructors post on campuswire and we’ll address it.
Server errors
If your code works for you but not for us, let us know in a to-instructors post on campuswire. We’ll investigate and may fix our server, ask you to fix your code, or explain why your code doesn’t really work (the latter changing this to a different type of regrade).
Incorrect required parts

The required parts of each assignment are selected because they represent content we want every student to master. If you lost required points during grading, you should

  1. Understand why they were lost (either by inspection or by visiting office hours)
  2. Fix your code
  3. Request (in a to-instructors post on campuswire) a chance to re-submit the assignment with the fixed required part
Fewer optional points than you wished
Our advice here is focus on the upcoming assignment instead. Optional points are one big pool, so if you missed 20 on MP1 but do an extra 20 on MP2 and it will come out at 100% in the end. There may be some special cases where we re-open an assignment to have optional points fixed, but we expect that to be rare.

3 implemented.txt

We want to grade everything you implemented, but trying to grade things you didn’t implement tends to make graders grumpy. To avoid confusion about what you believe you implemented, each MP includes a file implemented.txt where you list the parts of the assignment you completed and want us to grade.

There are different guidelines for implemented.txt for different kinds of MPs

Any-language MPs (Warmup 1, MP 1, 4cr MP)

The first step in grading is running your code to make images. Thus, your implemented.txt must be formatted as one example file we provided for the MP (and which you implemented and want to have graded) per line. The order you put them in does not matter.

In MP 1 if I did the required parts, depth, sRGB, and hyperbolic interpolation I’d use the following as my implemented.txt

mp1indexing.txt
mp1req1.txt
mp1req2.txt
mp1nodepth.txt
mp1depth.txt
mp1srgb.txt
mp1hyp.txt

In this particular instance mp1nodepth.txt is not graded, but I’d still include it because that fact is not obvious on assignment writeup.

Your code should not refer to or depend on implemented.txt, nor should it refer to any specific input file directly. Putting mp1indexing.txt in implemented.txt tells the grading tool that you believe that input file should work, but we may test with different input files exercising the same code functionality instead.

WebGL2 MPs (Warmup 2, MP 2–5)

The grader is presented with your code and a rubric of assignment parts. They always grade the required parts, so no need to list them in your implemented.txt. The optional parts are listed in the rubric in the same order they are on the assignment description, so using that order in your implemented.txt will be helpful to the grader. We recommend using the title of the optional part’s header, but the file is read by humans not machines so no need to match exactly.

In MP 2 if I did the required parts, CPU vertex movement, and mouse movement I’d use the following as my implemented.txt

CPU-based vertex movement
Mouse response

I’d not include the required parts because those are always graded for WebGL2 assignments.

If you code does something odd that you think the grader ought to know about (which will hopefully be rare), include that in the implemented.txt too.

4 Makefile

Some MPs allow you to code in any language you want. We support that by using GNU Make as a build tool. There are many newer build tools out there, but make remains the most widely deployed.

For these MPs, we execute your code as follows:

  1. Enter the directory containing your code
  2. Run make build
  3. For each input file we want to test (for example mp9xyzw.txt),
    1. Copy the input file (mp9xyzw.txt) into the directory
    2. Run make run file=mp9xyzw.txt or the like
    3. Move the output file elsewhere, diff it against our expectations with ImageMagick, etc

The first warmup gives example Makefiles for many languages. If you know about Makefiles you are welcome to make your own, but for most students our example files can be used as-is.

If you don’t have make on your computer, you can either install it or test without it.

4.1 Installing make

Almost every OS

Either comes with make installed or allows installing it through the package manager under the name make

This is true of at least Arch, Gentoo, Fedora, SUSE, CentOS, Nix, Guix, Debian, FreeBSD, OpenBSD, NetBSD, and Haiku; as well as their various re-skinned wrappers like Manjaro, Mint, Ubuntu, etc.

MacOS

Students have had success with any one of the following:

Windows

Students have had success with any one of the following:

4.2 Testing without make

The Makefiles provided in the first warmup have to lines they run.

The basic structure of a Makefile is

rulename: optional dependencies
    code to execute

When we run make rulename it first looks for any rules named after dependencies and runs them; then it runs the code. While doing this it expands any names between $( and ) with their definition; notably, it expands $(file) with an input filename like mp1req1.txt.

Suppose a makefile contains

run: program
    ./program $(file)

program: main.cpp
    clang++ -O3 -I. main.cpp -o program

Then running make run file=demo.txt will first make program; because main.cpp is not a rule in the Makefile the dependency chain stops there; it will jump to the command under program:, and then do the command under run:, for a final operation of

clang++ -O3 -I. main.cpp -o program
./program demo.txt

Thus running those two commands directly will test your code without needing make.

Several example Makefiles have

build:
     

There’s no dependencies and no commands, so running make build does nothing. This is common for interpreted languages like Python.