Stdout and stderr currently do no buffering. They process each call to the write method independently, splitting on newlines and sending each line immediately to the log.
Unfortunately this means a call such as print("hello", "world") will produce 4 lines in the log:
hello- (space)
world- (empty line for the final newline)
This makes the log difficult to read, and it may be impossible to reconstruct the original output well enough for automated processing.
A more useful behavior would be to buffer multiple calls to write, and send a line to the log only when one of the following happens:
- A newline is written to the stream
- The
flush method is called with some data in the buffer
This has some risk of losing output if the app crashes or pauses while something's in the buffer, so we should offer the option to restore the unbuffered behaviour by calling reconfigure.
@freakboy3742: FYI
Related: #516, #654. Maybe the easiest way to solve all of these would be to actually implement our stdout-Logcat interface as a binary stream, and then put a TextIOWrapper on top of it, which would handle line-buffering automatically. When the binary stream converts its bytes into text for the Logcat, it would ideally use surrogateescape mode to allow automated recovery of the original bytes, but if that doesn't display correctly in Android Studio and Briefcase, then we should use backslashreplace instead.
Stdout and stderr currently do no buffering. They process each call to the
writemethod independently, splitting on newlines and sending each line immediately to the log.Unfortunately this means a call such as
print("hello", "world")will produce 4 lines in the log:helloworldThis makes the log difficult to read, and it may be impossible to reconstruct the original output well enough for automated processing.
A more useful behavior would be to buffer multiple calls to
write, and send a line to the log only when one of the following happens:flushmethod is called with some data in the bufferThis has some risk of losing output if the app crashes or pauses while something's in the buffer, so we should offer the option to restore the unbuffered behaviour by calling
reconfigure.@freakboy3742: FYI
Related: #516, #654. Maybe the easiest way to solve all of these would be to actually implement our stdout-Logcat interface as a binary stream, and then put a TextIOWrapper on top of it, which would handle line-buffering automatically. When the binary stream converts its bytes into text for the Logcat, it would ideally use
surrogateescapemode to allow automated recovery of the original bytes, but if that doesn't display correctly in Android Studio and Briefcase, then we should usebackslashreplaceinstead.