AWS: Implement diffing of solutions - #1462
Conversation
veluca93
left a comment
There was a problem hiding this comment.
Seems reasonable enough to me. Main question is whether comparing two large outputonly outputs risks being very slow...
veluca93
left a comment
There was a problem hiding this comment.
Seems reasonable enough to me. Main question is whether comparing two large outputonly outputs risks being very slow...
That's indeed a risk, given that it stops the whole AWS. I would recommend not diffing files larger than some constant. |
|
Added a limit of 1MB and 5000 lines. I think this should be enough for all reasonable uses, and I can't find any 5000-line files that take more than 0.07 seconds to diff. (though it doesn't help that nobody seems to document which inputs difflib hits its worst-case quadratic behavior on, but I found some 10k-line inputs that took around 0.3 seconds so I think I found the right pattern.) |
Closes #1408.
Screenshots:

The "diff submissions" details element is closed by default. When it's closed, the radio buttons on each row are hidden:

(I used an html
<details>element instead of our custom "toggling" class, because i needed an event listener for when it gets opened/closed and this was the easiest way to implement that. It doesn't have an open/close animation though.)Using the radio buttons just fills in the submission ID inputs, you can also enter submission IDs manually. The diff appears in the same popup as submission code, after clicking "Diff".
It's possible to compare almost any two solutions: if they have different languages, there is simply no syntax highlighting. If they are for different tasks, it's possible to compare them if both tasks expect a single source file. I'm not sure how useful this latter part is, but we have seen people submit code for the wrong task occasionally.
The implementation uses python's builtin
difflib.unified_diffto compare files (and uses prism.js to syntax-highlight the diff). difflib also contains an HTML diff, but I don't like its output styling, it isn't easy to syntax-highlight, and it always outputs a two-column diff (i prefer unified). It is better at showing changes within lines though, and it shows line numbers nicely.Overall I think this is the best approach (for rendering the diff itself) without spending ages implementing a custom solution.
I'm not sure the submission selection UI is the best possible though, I'm open to suggestions for improvements.