The new architecture memorizes settings (which we mostly did after reading the config so far) and also exposes the resulting file path as well as further settings.
This change is a prerequisite to define a dependency with Sprockets.
The PyLint output is marking the erroneous location visually by using ^ in the next line. This indicator is always prefixed by multiple spaces and the line does not contain any further text. Now, it might happen that the indicator is between two source lines that use the same quote type. Since we detect quotes through our regex, this occurrence would qualify, effectively enquoting the linter indicator ^. As a consequence of our quote handling, we normally prevented quoted text from being split. However, in the described scenario, this is not desired, since we are not dealing with a regular quote (but an accidental mismatch).
Therefore, with this commit, we disable our quote handling for those multi-line quotes where one line fully represents a typical PyLint indicator line. This should restore the desired line-matching behavior.
Fixes CODEOCEAN-12N
Within a source code comment (beginning with # or \\), a user could write arbitrary text, including unmatched quotes " or '. This is not an error and should be supported. However, with the current implementation, we would also treat such a quote the same way as an original one. With this commit, we fix that erroneous behavior.
Fixes CODEOCEAN-XF
With the turtle graphics, some very long lines might be returned by Poseidon just after the CR (\r). In this case, our new normalization will fix the mistake, but the next message received (just a LF `\n`) will be forwarded to the clients unchanged. This is not desired, so that we filter this case separately.
Since we prevent \r\r\n line breaks in the buffer (and rather return \r\n), we can also change the recognition of line breaks for the ASSERTION_ERROR_REGEXP.
This test still checked for a \r\n, which is why we modified the RegEx. Further, during testing of this change, I noticed that the line number 50 was outdated and only valid for JUnit 4.11. Since we updated to 4.13 recently, we need to find another mechanism to check for the correct line.
After splitting the messages received into lines, we could still have a line break within quotes. Since we just want to modify terminating line breaks, we change the recognition accordingly.
In Python, a so-called doc string consists of a string encoded in three quote (starting and ending with """ or '''). These strings were not yet recognized correctly, so that line breaks there would cause further trouble with recognizing individual lines (which is important for the linter translation).
Previously, a message received with CRLF line endings was (incorrectly) converted to CRCRLF line endings (i.e., from \r\n to \r\r\n). Then, the splitting in individual lines could generate an "empty" line, just containing the newly-added CR line ending \r.
If a non-JSON message received contains quotes and is cut off weirdly, the following message might "quote" the line breaks. Then, we have an issue and cause \r\n\n for the further processing within the CodeOcean backend.
This change is required for Turtle output generated by the Python environment. Otherwise, drawing some images could add empty new lines (in the browser), since the original JSON message got split between the ending \r\n characters.
This commit mainly changes the color definitions. Mostly, those changes are semantically equally, but there are a few changes that occurred to align the color scheme within the app.
When starting Poseidon with an empty Nomad cluster, the list of existing environments is empty. In this case, however, our error handler threw an error, which was not correct.
Fixes CODEOCEAN-M7
Special handling is needed to ensure we have the transaction ID and Rack ENV. Otherwise the error cannot be matched to a transaction in Sentry. This special behavior is needed because of the underlying EventMachine, which executes code in a different thread/context.
