-
Notifications
You must be signed in to change notification settings - Fork 19
Add {input,output}_visualizer_args and example visualizers #439
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
spec/2023-07-draft.md
Outdated
it is recommended to include the test case visualizer source code in the directory `test_case_visualizer/` along with invocation instructions in a file such as `test_case_visualizer/README.txt`. | ||
Tooling may make use of the `test_case_visualizer_args` key in the [test data configuration](#test-data-configuration) and [test case configuration](#test-case-configuration). |
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.
How can test_case_visualizer_args
be used if "invocation instructions" are needed?
It would be great if we could specify invocation, as we do with output visualizers.
spec/2023-07-draft.md
Outdated
|
||
## Output Visualizer | ||
|
||
An output visualizer is an optional [program](#programs) that is run after every invocation of the output validator in order to generate images illustrating the submission output. | ||
A visualizer program must be an application (executable or interpreted) capable of being invoked with a command line call. It is invoked using the same arguments as the output validator. | ||
A visualizer program must be an application (executable or interpreted) capable of being invoked with a command line call. It is invoked using the same arguments as the output validator, except that `output_validator_args` is replaced with `output_visualizer_args`. |
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.
Isn't an input visualizer also a "visualizer program"?
A visualizer program must be an application (executable or interpreted) capable of being invoked with a command line call. It is invoked using the same arguments as the output validator, except that `output_validator_args` is replaced with `output_visualizer_args`. | |
An output visualizer program must be an application (executable or interpreted) capable of being invoked with a command line call. It is invoked using the same arguments as the output validator, except that `output_validator_args` is replaced with `output_visualizer_args`. |
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.
Yep, and I found some more inconsistencies when looking at the related phrases, thanks! 😄
@mpsijm Could you rebase? |
…input visualizer Co-authored-by: Fredrik Niemelä <[email protected]>
Done! 😄 |
Closes #351 and closes #459.
I've tested the example visualizers in the "maximal" problem with https://github.com/RagnarGrootKoerkamp/BAPCtools/tree/draft, with the following side-notes:
The visualizer in BAPCtools currently only generates images under
data/
with a propergenerators/generators.yaml
, so I temporarily wrote one:Temporary
generators/generators.yaml
:BAPCtools does not support the
include/
(yet?), so it should be invoked asbt generate --no-solution --no-validators
BAPCtools still usestestdata.yaml
, I renamed this manually totest_group.yaml
after runningbt generate
test_group.yaml
as well now! 🎉Nonetheless, the "maximal" problem should be spec-compliant (and at some point in the future, BAPCtools should run it without issues as well) 😄