Closed davidhyman closed 4 years ago
Good find! And thanks for providing details! I'll have to dig into this, but I may not get a chance for a few days.
The problem turned out to be I wasn't preserving the maximum scroll offset. by design, Enlighten does not shrink the portion of the screen used for progress bars, but when the number of bars was reduced it wasn't preserving that size. The main reason not to reduce the area is for aesthetics. It's much easier on the eye than having things move too much.
Fix is in master. Should have a new release soon.
Took it for a spin and it looks great :sparkles:, thank you for your efforts :+1:
Description In some circumstances, enlighten mangles the output from loggers (output disappears, becomes garbled, interspersed with progress bars).
This can be reproduced in the 'datacenters' demo by iterating another progress bar before closing the datacenter, or by using the repro code below.
expect:
actual:
Investigation This took me a while to figure out because I thought it was something to do with the counter indices and their (lack of?) reassignment when removing counters. It sort of is, but only because when tracking the terminal cursor position it shows a difference between the two scenarios in the repro code below. This then seems to affect the scroll size.
To be specific; it appears that the issue is: https://github.com/Rockhopper-Technologies/enlighten/blob/master/enlighten/_manager.py#L336
the offsets check - this only changes the scroll size if the offset grew; however, the "broken" scenario in the repro code below causes the offset to shrink, but with no scroll resize occurring, it starts overwriting the log output stream. The following modification to that line fixes the issue:
It's possible this might not be the correct way to fix the issue - the choice of
>
might be handling some other case that I can't intuit; if so, the 'shrinking scroll area' may need some other explicit handling. Any thoughts most welcome!To Reproduce This example demonstrates the problem. We expect to see all the log messages, but with 'broken' set True, we start getting corruption. In this simplest case, it appears as though the only difference is 'nesting' of progress bars - or their close order. From here I started to look at the counter position reassignments.
Environment