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

Add new style value to options, include in args #24

Merged
merged 7 commits into from
Jan 28, 2018

Conversation

stevepentland
Copy link
Contributor

This is a preliminary pull request for consultation on the current direction of the changes. The new option is present in both the args and HyperfineOptions but is not yet used.

Copy link
Owner

@sharkdp sharkdp left a comment

Choose a reason for hiding this comment

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

Looks good so far!

You can just keep pushing to this branch.

.gitignore Outdated
@@ -1,3 +1,3 @@

.vscode/
Copy link
Owner

Choose a reason for hiding this comment

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

It feels like this would be something for a global .gitignore file. https://help.github.com/articles/ignoring-files/#create-a-global-gitignore

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, no problem

src/main.rs Outdated
.long("style")
.short("s")
.takes_value(true)
.value_name("OPT")
Copy link
Owner

Choose a reason for hiding this comment

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

What does OPT stand for? Maybe change this to TYPE?

Copy link
Contributor Author

@stevepentland stevepentland Jan 23, 2018

Choose a reason for hiding this comment

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

It was chosen to represent "Option" while staying in line with your existing 3 letter notation for placeholders in the help output (NUM, CMD, etc.) as I didn't want to stray from a current convention.

Copy link
Owner

Choose a reason for hiding this comment

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

That's okay. 3 letters was just a coincidence

src/main.rs Outdated
.value_name("OPT")
.possible_values(&["auto", "basic", "full"])
.help(
"Set output style type. If set to 'basic', all colors and special \
Copy link
Owner

Choose a reason for hiding this comment

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

We could maybe add ( default: auto).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It affected the output when hyperfine was called with no arguments. When I get home from work today I'll update this comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I misunderstood what you meant by default. I was talking about when I added it as a call on Arg (default_value("auto")). But yes, I can add (default: auto) to the help output.

@sharkdp
Copy link
Owner

sharkdp commented Jan 24, 2018

Just a heads up: I switched from ansi_term to the colored crate.

@stevepentland
Copy link
Contributor Author

Thanks for the heads up, I've incorporated the changes from your upstream. I'm still working on devising a method to satisfy the new output options without having conditional checks everywhere output is done so I wasn't too affected.

However, the 'basic' output is rather noisy, and a better output style needs to be
determined.
@stevepentland
Copy link
Contributor Author

@sharkdp I used an indirect approach to the output, so no individual consumer would have to worry about the style of output. I have only used it in one location and still need to do cleanup, but wanted to get your thoughts. This method only leaves the couple of lone println statements to have to worry about colors in this case.

@sharkdp
Copy link
Owner

sharkdp commented Jan 25, 2018

@stevepentland I haven't completely reviewed the code (yet) but that looks like a cool idea.

Another option we could explore would be to:

Actually, it looks like the indicatif progress bars do not show up in log files if you redirect stdout:

hyperfine 'sleep 0.1' > test.log
# or:
hyperfine 'sleep 0.1' | tee test.log

@stevepentland
Copy link
Contributor Author

@sharkdp Thanks for the ideas. I played around with them a bit and found that the results are a mixed bag. I'll address them in order of your suggestion:

  1. This option does work, but due to the progress bar still controlling the final output, the options for showing what is going on is lacking as everything is swallowed up. So reporting progress such as % complete on a line-by-line basis is no longer available.

  2. Even without spinner we still have the situation where all TUI features are not disabled, such as overwriting the last line, so we're still at the mercy of what indicatif wants to do.

It seems, after some quick experimentation, that the most reliable way to ensure that all special formatting is eliminated during basic runs is to completely omit the bar as an output target.

Additional changes to make sure that all text is plain white when using basic mode.
@stevepentland
Copy link
Contributor Author

stevepentland commented Jan 27, 2018

@sharkdp I've changed back to checking output style both at progress bar and during println statements. While there is no progress indication in basic mode, the results are still presented in a legible way. I played around with it a bit and it seems pretty good.

cmd
);
let (benchark_text, current_num) = match options.output_style {
OutputStyleOption::Basic => ("Benchmark #".white(), (num + 1).to_string().white()),
Copy link
Owner

Choose a reason for hiding this comment

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

Unfortunately, white() will also output ANSI sequences (�[37mBenchmark #�[0m�[37m1�[0m: sleep 0.1). Could we simply keep the colored version here and disable coloring globally via colored::control::set_override

Copy link
Contributor Author

Choose a reason for hiding this comment

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

dang, I'm embarrassed I hadn't seen that option when I was looking at the docs for the crate. Thanks for pointing it out. I'll make the change back to the original for println statements and set the global output

@@ -244,23 +252,49 @@ pub fn run_benchmark(
let (user_str, user_unit) = format_duration_unit(user_mean, None);
let system_str = format_duration(system_mean, Some(user_unit));

let (mean_start, delta, mean_val, stddev_val, user_val, sys_val) = match options.output_style {
Copy link
Owner

Choose a reason for hiding this comment

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

The same here. I think we could just keep the old version and disable coloring globally.

Original attempt tried to directly set what would be output,
this was more complex and did not actually solve the problem.
Now the global setting of the colored crate is used to disable
all colorization of output as soon as basic is noted.
@stevepentland
Copy link
Contributor Author

@sharkdp I have made the changes you pointed out. Thanks again for directing me to that setting in the docs, I had completely missed it.

@sharkdp
Copy link
Owner

sharkdp commented Jan 28, 2018

Thank you very much!

@sharkdp sharkdp merged commit 2e24ff0 into sharkdp:master Jan 28, 2018
@sharkdp
Copy link
Owner

sharkdp commented Jan 28, 2018

Released as v0.4.0

@stevepentland stevepentland deleted the styleopt branch February 2, 2018 12:24
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.

2 participants