Rework zombie handling to fix #451 and #464#460
Conversation
|
Hi @mitsuhiko, could you please give this a try? It fixed it for me™. |
|
This fixes the yarnish example, the |
Hmm, at least that one is consistent for me. I'll take a look. |
I think this one is broken because as I predicted |
6666b48 to
0cd925e
Compare
0cd925e to
ebbba89
Compare
ebbba89 to
e776623
Compare
|
I think there is probably a way to fix up the original fragment, would that be good enough or do you actually need all the complexity of the current version? |
I'm all ears if you have a different approach :) but I spent a good 6 hours working on this and couldn't come up with anything simpler. |
djc
left a comment
There was a problem hiding this comment.
Looking pretty good! I agree that it can't be simplified much further...
a9b01d5 to
32a0cd7
Compare
|
@chris-laplante ping? |
pong :). I already commented on your reviews above. Was waiting to hear your thoughts. |
|
Sure thing, I will get it done today. Sorry for the delay.
|
be2b10c to
f4562b9
Compare
Fixes console-rs#464 and console-rs#451 Possibly fixes console-rs#411 (if not already fixed?)
… behavior Specifically, `clear` no longer clears lines printed by `println`. Also, changed some render tests to not manually reset the in-memory terminal since then it gets out of sync with MultiProgress.
f4562b9 to
c2f2c75
Compare
|
@djc should be ready |
This implements what I described here (except for the resetting upon
MultiProgress::clearorMultiProgress::suspend). It is ugly because it is working around a double mutable borrow that occurs when you write the code in the "obvious" way:Ideally, only
MultiState/MultiProgresswould have to know anything aboutzombie_line_count, but I fear we may have to push it deeper into the hierarchy. I will do my best to find a way so that doesn't happen, though.