Format for Dodona debugger

[niknetniko]

Pythia

As far as I can tell, Pythia currently generates the following information for the Python Tutor:

"data": {
  "statemtents": "", // A string containing the "test code"
  "stdin": "", // A string containing stdin
  "files": {} // Map of names to their contents and other metadata, ignored for now.
}

This object is then added the contexts in the output by Pythia.

TESTed

We could relatively easily do something similar in TESTed, by adding an optional object to start-context or close-context, containing debugger information, with perhaps some name changes (e.g. testcode instead of statements etc.).

For now, we would not support files, nor command line arguments as input (as those need special handling in both TESTed and the tutor). In the long term, for other languages, we would have to define somewhere what the generated testcode should do. For example, can it assume the submission is available? Do we want namespaces? However, for Python, it is probably easiest to follow the Python tutor for now.

[niknetniko]

(not really relevant right now, but perhaps interesting in the future)

---

One thought I had was that we could attempt to make the existing output format more semantic, meaning Dodona could create the input/testcode for the Python tutor from the existing output format. The advantage is that the information is then also available for other uses.

• For most exercises with function calls, all the information is already available. The testcode can be inferred by concatenating the context description and all testcase descriptions which have a format python.
• Stdin is currently not explicitly marked, but we could introduce a new description format called "stdin", which renders as "code", but is then known to be stdin.
• Files could similarly be added to the output format (which would also enable e.g. https://github.com/orgs/dodona-edu/discussions/4417).

However, since we would probably still need the ability to override this, e.g. provide a custom testcode from the judge, the added complexity might not be worth it. Command line arguments are also a difficult case here, and would probably require using the override.