added a buffer for unfinished lines during progress bar printing. the lines will be completed by the next print, or way at the end when all progress bars are done. #1951
Conversation
… lines will be completed by the next print, or way at the end when all progress bars are done. Also removed some unused imports
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1951 +/- ##
=======================================
- Coverage 49% 49% -1%
- Complexity 6247 6248 +1
=======================================
Files 664 664
Lines 59464 59512 +48
Branches 8621 8629 +8
=======================================
- Hits 29326 29324 -2
- Misses 27943 27990 +47
- Partials 2195 2198 +3 ☔ View full report in Codecov by Sentry. |
|
This definitely needs testing on Windows; due to additional |
jurgenvinju
changed the title
|
Efficiency could be improved by making the buffer circular; however I noticed no performance hit with in the horseRaceTest demo, so this could be goldplating. |
|
I've tested it in 2 windows terminals:
So it's partially works, but we're not there yet? |
| // first ensure capacity of the array | ||
| if (curEnd + len >= curCapacity) { | ||
| var oldCapacity = curCapacity; | ||
| curCapacity *= 2; // this should not happen to often. we're talking a few lines of text. |
There was a problem hiding this comment.
maybe we should grow by 50%?
There was a problem hiding this comment.
the chance of having to grow again is large if we only grow by 50%. This way we quickly grow and we don't grow again on short notice.
| // otherwise we wait until the next input comes to be able to complete a line. | ||
| } | ||
|
|
||
| public void writeLeftOvers(OutputStream out) throws IOException { |
There was a problem hiding this comment.
It's not the same as a flush because it also adds newlines. So I have renamed it.
I think we might be looking at a different problem there that is not related to the current solution. Perhaps it is missing |
…pying of byte arrays that will be printed immediately anyway. The code now only buffers unfinished lines.
Fixes #1948 and #1946 by considering all different situations that can arise when output is printed during progress bar visualizations:
The new implementation satisfies the invariant that the cursor position will always be on column 0 when a new version of a progress bar is printed. This is necesary for the progress bar to fit one exactly one line and fill it; and also to prevent flickering (a bar that moves would flicker).
Furthermore this implementation is thread-safe, because it maintains unfinished sentences for every different thread, and completes them incrementally as new output is printed from each thread. In this manner another invariant is satisfied: never is output printed one the same line from different threads. The lines of different threads may interleave; but not the columns.
The printing is now incremental per line such that output still appears as the program is running, but it is synchronized on newline characters, in order to be able to satisfy the "column=0" invariant at all times.