CENG 334 Homework 1 – Grader

The C grader checks that your merger program produces the correct merged CSV output, that all operator processes exit successfully, and that there are no zombie processes left behind.

For students (grader executable)

If you received a grader executable with your homework package:

1. Put your compiled merger in the same diory as the grader and the operator executables (sort, filter, unique).
2. Ensure a tests directory is present (it should be in the same package) with test specs and expected outputs.
3. Run the grader from that directory (so the merger finds the operators):
   ./grader
   Or from elsewhere: path/to/grader --merger path/to/merger --build-dir path/to/dir --tests-dir path/to/tests
   The grader will run the built-in tests and print one line per test (PASS/FAIL) and a total.

Extending with your own tests

You can add your own test cases so the grader runs them too. Create a directory (e.g. my_tests) with the same layout as tests: for each test, provide:

• tNN.spec – Merger specification:
  • Top-level merger: first line is filename num_chains. The top-level merger always rea the entire CSV file; there is no merger-level line range.
  • Each following line describes one chain as start_line end_line pipeline..., where start_line and end_line are 1-based line numbers in the top-level CSV file.
  • If a chain ends with merger, the next block in the spec describes a sub-merger.
  • Sub-merger blocks start with a line num_chains (no filename) and then num_chains chain lines. For sub-mergers, start_line/end_line are relative to the sub-merger’s own input block (line 1 is the first line that sub-merger receives on stdin).
• tNN.csv – CSV data file.
• tNN.expected – Expected merged data only (no exit status lines). The grader never uses this file to check exit status; it is used only for the CSV data comparison.

Then run:

./grader --extra-tests my_tests

Or use only your own test directory:

./grader --tests-dir my_tests

Exit status reporting and EXIT-STATUS lines

The grader verifies operator exit status using a dedicated communication channel, not by looking at the expected output file:

• The grader sets the environment variable HW1_EXIT_REPORT to point to a per-test log file before running your merger.
• Each operator executable (sort, filter, unique) is provided to you. They install an atexit handler that appends a line pid status to HW1_EXIT_REPORT when the process terminates.
• Your merger must, for every operator process it spawns (including those inside sub-mergers), write a line of the form EXIT-STATUS <pid> <status> to its standard output. These EXIT-STATUS lines may appear anywhere in the output; the grader scans the whole stream and ignores them when comparing CSV data to tNN.expected.
• The grader matches the EXIT-STATUS lines it sees in the output against the lines in the HW1_EXIT_REPORT file (same pid status pairs, and the expected number of operators). If HW1_EXIT_REPORT is unavailable, it falls back to counting operators from the spec and requiring that many EXIT-STATUS ... 0 lines.

In summary: the expected files check only data. Operator exit status is checked via EXIT-STATUS lines and the HW1_EXIT_REPORT operator→grader log.

← Materials · ← Homework 1