Multipass feedbackdir/multipass ?

[mzuenni]

in DOMjudge/domjudge#2307 @meisterT suggested that only the content of feedbackdir/multipass/ should be preserved between passes (and nothing else). The implications would be:

• it must be guaranteed that the directory feedbackdir/multipass/ exists (for multipass problems)
• the validator can neither accidentally nor intentionally overwrite judgemessage.txt
• the judging system must preserve files like judgemessage.txt to be able to display them for all passes

Are there any opinions on this?

[niemela]

I don't think I like this at all?

I say "think", because I'm not sure I fully understand it (and if I understood it maybe I would realize that if makes perfect sense).

• There is currently no multipass subdirectory specified, right?
• Since multipass preservation is only relevant for multipass problems, isn't this equivalent to letting the validator specify which files to keep (by copying them to the multipass direcrtory)? Or does this do anything other than that?
• Doesn't "judging system must preserve files like judgemessage.txt" directly contradict "only the content of <feedback_dir>/multipass/ should be preserved between passes (and nothing else)"?
• I think a common (and good) pattern is to append to judgemessage.txt every pass. To do this now the validator needs to save a copy in multipass/ and copy that into judgemessage.txt every pass. Seems annoying?
• What actually gets easier by doing it this way?

[mzuenni]

This is mostly a suggestion from domjudge / @meisterT so maybe they can say more about this, but I will still try to answer your questions

• There is currently no multipass subdirectory specified, right?

Yes the idea is to specific the existence of <feedback_dir>/multipass/ for multipass problems and then to only preserve the content of this directory between passes.

• Since multipass preservation is only relevant for multipass problems, isn't this equivalent to letting the validator specify which files to keep (by copying them to the multipass direcrtory)? Or does this do anything other than that?

The intention is that the judging system only preserves files in that subdirectory and nothing else

• Doesn't "judging system must preserve files like judgemessage.txt" directly contradict "only the content of <feedback_dir>/multipass/ should be preserved between passes (and nothing else)"?
• I think a common (and good) pattern is to append to judgemessage.txt every pass. To do this now the validator needs to save a copy in multipass/ and copy that into judgemessage.txt every pass. Seems annoying?

The idea is to remove the first statement and to provide a simpler / less error-prone write to judgemessage.txt.
From the validators POV the judgemessage.txt is not preserved, which implies that you don't need to ensure that you are appending to it, you can just write to it. The judging system is responsible to collect the judgemessage.txt of all the passes and present them in some way.

• What actually gets easier by doing it this way?

• as mentioned, the validator does not need to append, which the author might forget and then would unintentionally overwrite it.
• Domjudge requested this because it makes stuff easier at their end, but I don't know what exactly.

[niemela]

The idea is to remove the first statement and to provide a simpler / less error-prone write to judgemessage.txt.
From the validators POV the judgemessage.txt is not preserved, which implies that you don't need to ensure that you are appending to it, you can just write to it. The judging system is responsible to collect the judgemessage.txt of all the passes and present them in some way.

Ah, I see. So judgemessage.txt kinda gets retained as well, but in a locked down write-once sense...

• as mentioned, the validator does not need to append, which the author might forget and then would unintentionally overwrite it.

Right, so then actually only appending does get ever so slightly easier (and accidental overwrites becomes impossible). Bur also, overwriting on purpose (when that makes more sense) also becomes impossible.

I don't see that this would be better. It feels slightly more complicated and slightly less powerful (although, admittedly, the difference is not large).

[niemela]

I'm leaning towards closing this as wontfix. Please comment if you strongly disagree.

[meisterT]

Fredrik, let's talk in person in a few days?

[mpsijm]

Here's an attempt to summarize one take-away from a discussion with @eldering, @kunyavskiy, @vmcj, and @mzuenni (and there were others and more was said but I think this is a question that @meisterT could probably answer better 😛)

So, to allow a multi-pass problem to make multiple passes using state from any number of previous passes, it is essential that (some part of) the feedback directory (which is passed as a command-line parameter to the output validator) is preserved, so that the output validator can read this.

• One solution is that the entire feedback directory is just copied over from the previous pass to the next pass. This was implemented in DOMjudge/domjudge@d7cc716 and used in NWERC 2024 and GCPC 2025. But, DOMjudge also writes to the feedback directory (from the top of our heads, we do not know what exactly, but it's mostly to preserve some state to allow debugging later), which could potentially break the output validator of the next pass.
• From this followed the idea of making a multipass subdirectory inside the feedback directory and only copy this directory between passes (the start of this issue).
• My thought was: if DOMjudge wants to write some files to the feedback directory, why doesn't DOMjudge write these files to the parent directory of the feedback directory? So, in DOMjudge/domjudge@d7cc716#diff-495a2bf2ac4904f9b10777c3d8643cf0de9ee5499d64a15fc1a806e350180bb6R1410, that would be $passdir rather than $passdir . '/feedback'. Then we can ensure that only the output validator/visualizer "own" the contents of this feedback directory. Where the feedback directory lives exactly (it could even be a sub-sub-directory of $passdir), does not matter, as long as the output validator receives the path as command-line parameter.

And this last point is a question that we hope that @meisterT can answer. 😄

[niemela]

I agree with @mpsijm

[Matistjati]

So basically, close as wontfix? I slightly prefer that, as it's more homogeneous in the sense that we are going to use the persistence of feedback for both output visualizers and multipass.

[meisterT]

I still would prefer having separate directories, it is cleaner overall.

if DOMjudge wants to write some files to the feedback directory, why doesn't DOMjudge write these files to the parent directory of the feedback directory?

My comment was not about what DOMjudge might write, the spec allows validators to write judgemessage.txt and teammessage.txt among other files. I think it is cleaner and also easier for the jury to write these files per pass (not per overall judgement) - the CCSs can then display information to the judges related to a specific pass. Obviously, this would mean changing/removing In particular, the validator should only append text to the judgemessage.txt to provide combined feedback for all passes. in the multipass problem spec.

It seems you already decided that you don't want this, just wanted to state my opinion for posterity.