Adding the programming language tag to TESTed #583
Conversation
tested/__main__.py
Outdated
| @@ -36,7 +36,6 @@ | |||
| "--translate", | |||
| type=str, | |||
| help="Specifies the language to translate translate the dsl to.", | |||
| default="-", | |||
There was a problem hiding this comment.
This is actualy a change that already should be in the other branch. This default will cause the translator to run when the option -t isn't even provided.
tested/dsl/dsl_errors.py
Outdated
| messages.append( | ||
| ExtendedMessage( | ||
| f"WARNING: You are using YAML syntax to specify statements or expressions in multiple programming languages without the `!programming_language` tag. This usage is deprecated!", | ||
| permission=Permission.STAFF, |
There was a problem hiding this comment.
@bmesuere, this gave me the idea that we might need to add a Permission.CREATOR or something like that in the future. Some messages just aren't very actionable for teachers using exercises that are not their own.
We might also want to mark exercises with unresolved warnings/errors in dodona and create a page to review these for content creators
tested/dsl/dsl_errors.py
Outdated
| @@ -102,3 +102,24 @@ def build_preprocessor_messages( | |||
| ) | |||
| for key in translations_missing_key | |||
| ] | |||
|
|
|||
|
|
|||
| def build_translate_parser_messages( | |||
There was a problem hiding this comment.
I wouldn't take a boolean argument here, nor would I return a list, as it is a single message
And rename it to build_deprecated_language_message or something like that
There was a problem hiding this comment.
I wrote it like this such that this function can easily be expanded when extra deprecation warnings pop-up about using file instead output_files.
tested/judge/core.py
Outdated
| # TODO: In the PR of adding file usage to the DSL, other deprecation warnings were added during parsing. | ||
| # So I think it's a nice split to have messages from parser and from the preprocessor. | ||
| collector.add_messages( | ||
| build_translate_parser_messages(bundle.suite.using_deprecated_prog_languages) |
There was a problem hiding this comment.
Same as in the natural_languages pr, this method won't be needed here if we had bundle.parser_messages
There was a problem hiding this comment.
I've resolved all the other notes because it boils down to this. I changed the usage of booleans to an actual list of ExtendedMessages
|
|
||
|
|
||
| def parse_dsl(dsl_string: str) -> Suite: | ||
| def parse_dsl(dsl_string: str) -> DataWithMessage[Suite]: |
There was a problem hiding this comment.
This returns DataWithMessage, but in practice all messages are just ignored. Do we need this here?
There was a problem hiding this comment.
These messages are used in main.py.
There was a problem hiding this comment.
These messages are not passed through
This method returns suite_to_json(suite_with_message.data)
suite_with_message.messages is completely ignored and never used
There was a problem hiding this comment.
main.py uses parse_dsl and not translate_to_test_suite.
This builds of the PR #574. The goal is to add the tag
!programming_languagesuch that it is more consistent with the usage of the tag!natural_language.