-
Notifications
You must be signed in to change notification settings - Fork 271
Extra python examples, more uniform code layout with tags, #2006
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d7c2ef9
to
463788b
Compare
example_problems/hello/submissions/accepted/extra-file-awk/test-hello.awk
Show resolved
Hide resolved
@@ -1,2 +1,5 @@ | |||
cat("Hello World!\n") | |||
# This should give CORRECT on the default problem 'hello'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering whether we should remove these comments overall for correct submissions. They made sense when everything was in a single directory, but now not we are using the standard format.
I am also not sure that we should add the @EXPECTED_RESULTS@
if there exactly one. It is a relict from the pre-problem package format times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should put some in a non-standard folder just to make sure that this also does work with 1 result, and I changed this mostly to be consistent so I'm fine with removing it everywhere for the standard folders (but will than move some solutions to mixed-verdicts
for the check)
Removing the comment is fine by me, I might have a slight preference for the comment as it gives more information than having to look in the file explorer if this is a failing submission without comment or that this is a correct submission so it does not have a comment. I don't care much for it though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that these @EXPECTED_RESULTS@
tags are useful, both when viewing the file as @vmcj already mentioned, but also because it means that this meta-data is now included in the source, so you can separately submit/import the file as jury and it will still pick up this information.
@@ -1,2 +1,5 @@ | |||
cat("Hello World!\n") | |||
# This should give CORRECT on the default problem 'hello'. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that these @EXPECTED_RESULTS@
tags are useful, both when viewing the file as @vmcj already mentioned, but also because it means that this meta-data is now included in the source, so you can separately submit/import the file as jury and it will still pick up this information.
example_problems/hello/submissions/run_time_error/test-exitcode-2.py
Outdated
Show resolved
Hide resolved
This does not matter as the tag is ignored because the directory name is specified in the spec (so has priority).
The outcome of the submission is either the correct or a wrong answer. The verifier should accept this if either of those two verdicts is given.
We ignore this in the .gitignore but the submission needs this to test if we can submit compiled code and have a working submission.
These do almost never run as we don't default enable POSIX, which is needed to actually run these tests.
These should all fail as they need root access. These things are easier from a shell but the sh language is default not enabled.
Check that having only one expected result in the @EXPECTED_RESULTS@: also works. According to spec these should be in the original folders, so those are copied and waste (negligible) some judging time for a very small problem.
463788b
to
748abe1
Compare
I've moved some solutions around when they had multiple tags and I've added one fail back which might not have been added in the rewrite. @meisterT touched those files last so knows best if this is actually an improvement.