Tudor Brindus

https://github.com/DMOJ/online-judge/blob/617a321d03756c46e62986dfe2f6db4c944a5d9a/judge/views/problem.py#L146-L147 This needs to change to use the problem ID (and solution ID, for the editorial views). We should also have a migration that ports comments over to the id-based...

> * [ ] this Tentatively fixed by https://github.com/DMOJ/martor/pull/8.

Thanks for reporting this. I've pinned packaging to < 22, but will keep this issue open as a reminder to switch off of `LegacyVersion`.

I suspect this is fixed for good with https://github.com/DMOJ/judge-server/commit/95a432b68fce5c512a902a8f8226a01e4abaebf8.

I'd say: * Build the runtimes-docker image locally with your changes. * Build the corresponding judge image as-is, it should base itself off your runtimes-docker build rather than pull in...

There isn't any other configuration required to get Swift to work. Something is wrong here; usually these things happen because the runtime hits the sandbox in a way that hasn't...

We'll need an accompanying site-side PR to not crash the bridge when we send it `PRETEST-{BEGIN,END}` packets. https://github.com/DMOJ/online-judge/blob/f3cd24e3ecad89c2492917df9229009c2634baed/judge/bridge/judge_handler.py#L40-L54

Overkill solution: For Java 8, use `ZipFile` to list the contents of `/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar` and filter anything ending with `Exception|Error`. Only a handful of builtin throwables don't follow this pattern (`ThreadDeath`...

If we're doing that then we should definitely do it as a cronjob, otherwise doing it on startup would take too long.

If by cronjob then we ought to do only the Java 9+ thing, since exceptions are unlikely to be removed, but may be added.