Emit content of unexpected stderr

[FabioLuporini]

Without this patch, I couldn't really understand where the error was coming from -- turned out to be something in stderr emitted by one of our dependencies which recently got an update.

Do you think this can be useful?

[vidartf]

Was this ALLCAPS print statement meant to be kept in?

[FabioLuporini]

uoops no! that's clearly a leftover. Pushing a fix+rebase shortly

[vidartf]

Beside the above comment I am not sure if this makes sense for the general case (I assume this will try to print the full base64 strings if the output is an image?). If you only want this behavior to happen for stream output, then scoping it to that might make sense.

[FabioLuporini]

I assume this will try to print the full base64 strings if the output is an image?

probably yes

If you only want this behavior to happen for stream output, then scoping it to that might make sense.

trying to paraphrase what you wrote -- are you saying to restrict this to stdout/stderr (ie testing_outs['stdout'] and testing_outs['stderr']) ? that'd be weird...I think?

we could also add a verbose mode, but I wouldn't know how to do it

[vidartf]

probably yes

Please note that printing an image as a base64 string will typically output pages upon pages of random characters, completely drowning out any important data. For other data as well, the output will be too large to keep. Maybe outputting the ~70 first characters would make sense (length chosen so line length ends up less than 79 chars, so it fits in default terminal size).

[sebp]

I came across the Unexpected output fields from running code: {'stderr'} message too. It would be very helpful if there would be a way to report what the contents of stderr actually were.