Allow setting separate time limit for interpreted languages #1247
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows setting a different (presumably higher) per-task time limit for some languages. This is mainly intended to make competing in Python viable without giving C++ users an advantage.
If a task doesn't have the interpreted language time limit set, the default time limit will be used instead. The set of interpreted languages is currently hardcoded as Python (2/3) and PHP.
I made this as a pull request directly because it's what we already use for Estonian olympiads, but admittedly it's not as configurable as it could be (mainly the list of which languages count as "interpreted"). The set of interpreted languages needs to be carefully chosen to make sure all such languages have roughly the same performance, otherwise competing in one language might be impossible, or in another language asymptotically bad solutions might get through the tests. Realistically it should be all of the slow languages that the jury has written example solutions for, with the time limit set accordingly to make all of them pass.
This makes me think that perhaps the set of languages should be a contest-specific setting, or at the very least something in cms.conf. But feedback is of course welcome.