This is a time-boxed investigation prototype for adding code-execution question support to questions.carletoncomputerscience.ca. It is not production code and will not be deployed.
Three approaches are being evaluated in parallel via spike tickets. Once viable options are identified, the chosen approach is migrated into the main Astro repo and this repo is archived. Nothing here is intended to be maintained long-term.
Pyodide runs CPython compiled to WebAssembly, executing Python entirely in the browser with no server involvement. The spike evaluates whether student-submitted Python functions can be loaded, executed against a test suite, and graded without any network round-trip. Key unknowns: bundle size, startup latency, and sandbox adequacy for an exam-adjacent context.
CheerpJ compiles Java bytecode to WebAssembly/JavaScript, allowing Java programs to run in-browser. The spike evaluates whether student Java submissions can be compiled or pre-compiled and executed client-side with comparable grading semantics to the Python approach. Key unknowns: whether student code can be compiled in-browser or requires a pre-compilation step, runtime overhead, and JVM subset limitations. Other options may include TeaVM, QEMU-WASM, or something else.
Judge0 is an open-source code execution API that runs submissions in isolated containers server-side. The spike evaluates the integration complexity of setting up Judge0 (self-hosted), the latency and infrastructure overhead, the process of configuring questions on the platform, and the viability as a fallback for languages that cannot run client-side.
The goal is to have either a way to mark both Python and Java questions fully locally in the user's browser, and/or to determine the Judge0 integration process and complexity. Python and Java are the two priority languages as they are used in the intro courses.
| Path | Description |
|---|---|
| SCHEMA.md | Question format specification |
| questions/ | Example questions in the defined schema |
| submissions/ | Sample student submissions used to test grading logic |
The following are out of scope until spike options have been evaluated and a direction is chosen:
- A code editor (Monaco, CodeMirror, or otherwise)
- A UI shell or any frontend scaffolding
- A shared runner interface or abstraction layer
- Integration with the main Astro site
- Styling of any kind
Spike authors should ideally not build any of the above. The purpose of each spike is narrow: determine whether the execution approach works and what its constraints are. UI and integration work follows after a direction is picked.