Skip to content
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

Merged
merged 8 commits into from
Jan 28, 2022

Conversation

thejcannon
Copy link
Member

@thejcannon thejcannon commented Jan 20, 2022

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.

@stuhood
Copy link
Member

stuhood commented Jan 20, 2022

Thanks a lot! Yea, feel free to run with this: I can close the original in favor of this one.

Copy link
Member

@stuhood stuhood left a 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.

src/python/pants/option/global_options.py Outdated Show resolved Hide resolved
Copy link
Member Author

@thejcannon thejcannon left a 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

src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
@thejcannon thejcannon changed the title WIP: Stu's Dyanmic UI with Prodash PR, but under a flag WIP: Dynamic UI with Prodash Jan 20, 2022
@thejcannon
Copy link
Member Author

thejcannon commented Jan 21, 2022

So the only difference (other than the obvious "style" of swimlane) this provides is the fact that the prodash implementation seemingly leaves the terminal at the lowest row, whereas when the indicatif implementation finishes, there's usually some N rows left empty below the current terminal.

I consider the prodash behavior ideal.

(Although that might change if we try and fix #14093 with prodash, I don't understand the underlying behavior of these very well)

Copy link
Member

@stuhood stuhood left a 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/Cargo.toml Outdated Show resolved Hide resolved
src/python/pants/engine/internals/native_engine.pyi Outdated Show resolved Hide resolved
src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
src/rust/engine/ui/src/console_ui.rs Outdated Show resolved Hide resolved
Comment on lines 360 to 375
indicatif
.multi_progress_task
.map_err(|e| format!("Failed to render UI: {}", e))
.boxed();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK yeah awaiting causes some kind of deadlock or equivalent "nothing is happening" scenario 😒

Copy link
Member

@stuhood stuhood Jan 27, 2022

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.

@thejcannon
Copy link
Member Author

Moving out of draft state @stuhood

@thejcannon thejcannon marked this pull request as ready for review January 26, 2022 19:39
Comment on lines +296 to +312
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);
}
};
Copy link
Member Author

@thejcannon thejcannon Jan 27, 2022

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.

Copy link
Member

@stuhood stuhood Jan 28, 2022

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.

Copy link
Member Author

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. 🙌

@stuhood stuhood changed the title WIP: Dynamic UI with Prodash Optionally render the --dynamic-ui with Prodash Jan 27, 2022
[ci skip-build-wheels]
@stuhood stuhood enabled auto-merge (squash) January 28, 2022 00:33
auto-merge was automatically disabled January 28, 2022 01:06

Pull Request is not mergeable

@Eric-Arellano
Copy link
Contributor

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?

@stuhood
Copy link
Member

stuhood commented Jan 28, 2022

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 pantsbuild/pants sooner (next few days), but I'm also not sure that now is necessarily the ideal time to be making that push (unless @thejcannon feels like he can dedicate some time to it?).

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.

@stuhood stuhood merged commit 4335962 into pantsbuild:main Jan 28, 2022
@thejcannon
Copy link
Member Author

At a minimum we'll want to fix

// TODO: Apply a fix similar to #14093 before landing.
before turning it on in this repo.

It's probably also not a bad idea to try and get Stu's changes to prodash in prodash itself. We can probably help that along.

Afterwards, I think the path forward would be much clearer.

@stuhood
Copy link
Member

stuhood commented Mar 3, 2022

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.

@thejcannon thejcannon deleted the prodash branch March 3, 2022 00:59
@Eric-Arellano
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants