-
-
Notifications
You must be signed in to change notification settings - Fork 643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optionally render the --dynamic-ui
with Prodash
#14221
Conversation
Thanks a lot! Yea, feel free to run with this: I can close the original in favor of this one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks great! If you need help getting it green, let me know, but looks like you're on the right track.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stuhood I'm going to open issues for the TODOs so they can be discussed
So the only difference (other than the obvious "style" of swimlane) this provides is the fact that the I consider the (Although that might change if we try and fix #14093 with prodash, I don't understand the underlying behavior of these very well) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks good!
Let me know when it's otherwise ready to land, and I can push a change for the stderr
race.
src/rust/engine/ui/src/console_ui.rs
Outdated
indicatif | ||
.multi_progress_task | ||
.map_err(|e| format!("Failed to render UI: {}", e)) | ||
.boxed(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indicatif | |
.multi_progress_task | |
.map_err(|e| format!("Failed to render UI: {}", e)) | |
.boxed(); | |
indicatif | |
.multi_progress_task | |
.map_err(|e| format!("Failed to render UI: {}", e)) | |
.await |
I think that this needs to await
the multi_progress_task
, but I'm surprised that you're not getting an error for an unused/unawaited future here, so I might be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding the await
leads to compiler warnings/errors which I don't quite understand.
I'm going to attempt a refactor to have both cases here share some code, so this might get unified with prodash
. We'll see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK yeah await
ing causes some kind of deadlock or equivalent "nothing is happening" scenario 😒
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This blocks landing, because otherwise the UI will not necessarily be torn down properly before we move on to doing other things, which could trigger race conditions. If this were prodash, then that might be ok... but can't land that for the default.
I'll take a look.
Moving out of draft state @stuhood |
let classify_tasks = |mut current_ids: HashSet<SpanId>, | ||
handler: &mut dyn FnMut(SpanId, TaskState)| { | ||
for span_id in heavy_hitters.keys() { | ||
let update = current_ids.remove(span_id); | ||
handler( | ||
*span_id, | ||
if update { | ||
TaskState::Update | ||
} else { | ||
TaskState::New | ||
}, | ||
) | ||
} | ||
for span_id in current_ids { | ||
handler(span_id, TaskState::Remove); | ||
} | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's way out of scope for this PR, but honestly heavy_hitters()
could be refactored to be more like this lambda, where it simply calls into a function param with the relevant info.
Likely to be a performance bump from not constructing and moving the HashMap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, there is absolutely optimization that can happen here. But I expect that it will be easier to do once we've reduced back to one implementation: prodash
's datastructure might mean that we don't even need to keep the "running" graph... or can directly keep prodash
nodes in the "running" graph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, that would truly be ideal. 🙌
--dynamic-ui
with Prodash
[ci skip-build-wheels]
Pull Request is not mergeable
What's the path forward to stabilizing Prodash? It looks awesome, I'm excited to try it out. If several of us maintainers / early adopters try it this week without issue, how about we switch the default to Prodash in 2.10 before stable release? Still keep the feature so users have an escape hatch. Then in 2.11 we drop the old UI? |
I haven't spent enough time using it to get a good sense for when it will be ready to become the default. I do think that it could potentially become the default within I agree that we should have a path toward stabilizing/making-default though: I'd tentatively suggest that it should either become the default or be removed within two or three stable releases, even if we don't start the push today. |
At a minimum we'll want to fix pants/src/rust/engine/ui/src/console_ui.rs Line 190 in 4335962
It's probably also not a bad idea to try and get Stu's changes to Afterwards, I think the path forward would be much clearer. |
FWIW, I've been using this mostly successfully, but Byron/prodash#10 is an issue, and breaks rendering for longer messages. We'd need to fix it, or truncate ourselves... not the end of the world. But in general, I don't think that it's currently in a place where it is better than indicatif. We'd need to invest time in actually using the nesting to improve rendering... but I'm not going to be in that place in the next few weeks. I'm going to switch back to the default until we have time to improve it. But if it is hampering our ability to ship any improvements elsewhere before we have time to fix the issues, I think that we should bias toward removing it. |
Ah, I've been using this for the past month too and indeed encountered Byron/prodash#10 but kept punting on opening an issue, glad to see that's accounted for! |
I've taken @stuhood 's PR #13481 and adapted it to hide behind an experimental flag.
I can't say I understand some/most/any of Stu's changes 😉 but if needed I'm happy to learn ❤️
Also, I've done my best to make commits incremental, so it's likely worth reviewing commits.