Print this chapterPrint this chapter

CodeRunner Documentation (V3.0.0)

4.3 Some more-specialised question types

The following question types used to exist as built-ins but have now been dropped from the main install as they are intended primarily for University of Canterbury (UOC) use only. They can be imported, if desired, from the file uoc_prototypes.xml, located in the CodeRunner/coderunner/db folder.

The UOC question types include:

  1. python3_cosc121. This is a complex Python3 question type that's used at the University of Canterbury for nearly all questions in the COSC121 course. The student submission is first passed through the pylint source code analyser and the submission is rejected if pylint gives any errors. Otherwise testing proceeds as normal. Obviously, pylint needs to be installed on the sandbox server. This question type takes the following template parameters (see the section entitled Template parameters for an explanation of what these are) to allow it to be used for a wide range of different problems:

    • isfunction: unless this is explicitly set to false, a dummy module docstring will be inserted at the start of the program unless there is one there already. Thus, if your question is of the "write a program" variety, you should set this to false. Otherwise omit it. This purpose is to stop pylint issuing a spurious missing module docstring message.

    • pylintoptions: this should be a JSON list of strings. For example, the Template parameters string in the question authoring form might be set to {"isfunction": false, "pylintoptions":["--max-statements=20","--max-args=3"]} to suppress the insertion of a dummy module docstring at the start and to set the maximum number of statements and arguments for each function to 20 and 3 respectively. See the pylint documentation for a list of its options.

    • proscribedconstructs: this is a list of Python constructs (if, while, def, etc) that must not appear in the student's program.

    • requiredconstructs: this is a list of Python constructs (if, while, def, etc) that must appear in the student's program.

    • allowglobals: set this to true to allow global variables (i.e. to allow lowercase globals, not just ALL_CAPS "constants")

    • maxnumconstants: the maximum number of constants (i.e. uppercase globals) allowed. An integer, defaulting to 4. Some such constraint is required when teaching pylint at early stages to stop students achieving pylint compliance with a global script simply by typing all identifiers in upper case.

    • norun: if set to true, the normal execution of the student's code will not take place. Any test code provided will however still be run. This is intended for dummy questions that allow students to check if their code is pylint-compliant.

    • stripmain: if set to True, the program is expected to contain a global invocation of the main function, which is a line starting "main()". All such calls to main are replaced by 'pass'. If no such line is not present a "Missing call to main" exception is raised. Stripping the main gives the question author the ability to test individual functions in the student submission as well as, or instead of, testing the program as a whole by explicitly calling main().

    • runextra: if set (to any value) the Extra Template Data is added to the program as test code before the usual testcode. This allows the question author to load extra test code through the Extra Template Data which the student does not get to see (usually because it would confuse them).

  2. matlab_function. Used for Matlab function questions. Student code must be a function declaration, which is tested with each testcase. The name is actually a lie, as this question type now uses Octave instead, which is much more efficient and easier for the question author to program within the CodeRunner context. However, Octave has many subtle differences from Matlab and some problems are inevitable. Caveat emptor.

  3. matlab_script. Like matlab_function, this is a lie as it actually uses Octave. It runs the test code first (which usually sets up a context) and then runs the student's code, which may or may not generate output dependent on the context. Finally the code in Extra Template Data is run (if any). Octave's disp function is replaced with one that emulates Matlab's more closely, but, as above: caveat emptor.

  4. nodejs. A question type in which the student's JavaScript submission is followed by the test code and the whole program is executed using nodejs.