You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
world
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:flush
method 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
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 usebackslashreplace
instead.The text was updated successfully, but these errors were encountered: