-
Notifications
You must be signed in to change notification settings - Fork 245
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
wide_msg can't be used with wide_bar #328
Comments
Yes, that is intended behavior. PR for doc improvements welcome! |
What do you think about: pub const fn check_template(s: &str) {
let s = s.as_bytes();
let mut i = 0;
let mut n_wide = 0;
while i + 9 < s.len() {
match [
&s[i],
&s[i + 1],
&s[i + 2],
&s[i + 3],
&s[i + 4],
&s[i + 5],
&s[i + 6],
&s[i + 7],
&s[i + 8],
&s[i + 9],
] {
[&b'{', &b'w', &b'i', &b'd', &b'e', &b'_', &b'm', &b's', &b'g', &b'}']
| [&b'{', &b'w', &b'i', &b'd', &b'e', &b'_', &b'b', &b'a', &b'r', &b'}'] => {
n_wide += 1;
if n_wide == 2 {
panic!(
"{}",
"Only one wide element can be used in the progress bar."
);
}
}
_ => (),
}
i += 1;
}
}
pub struct Template(&'static str);
impl Template {
const fn new(msg: &'static str) -> Self {
check_template(msg);
Self(msg)
}
} To test: Maybe its a bit overboard, but I thought it was cool 'that it is possible' if you force the user to provide the Template struct it can do some checks at compile time. |
It can be even more powerful: const fn check_template(string: &str) {
let string = string.as_bytes();
let mut string_index = 0;
let mut n_wide = 0;
let mut tag_start = false;
let mut tag_buffer = [0; 30];
let mut tag_index = 0;
while string_index < string.len() {
match &string[string_index] {
&b'{' => tag_start = true,
&b'}' => {
match tag_buffer {
[b'w', b'i', b'd', b'e', b'_', b'b', b'a', b'r', ..]
| [b'w', b'i', b'd', b'e', b'_', b'm', b's', b'g', ..] => {
n_wide += 1;
if n_wide > 1 {
panic!("Only one wide element is allowed per template");
}
}
[b'b', b'a', b'r', ..]
| [b's', b'p', b'i', b'n', b'n', b'e', b'r', ..]
| [b'p', b'r', b'e', b'f', b'i', b'x', ..]
| [b'm', b's', b'g', ..]
| [b'p', b'o', b's', ..]
| [b'l', b'e', b'n', ..]
| [b'b', b'y', b't', b'e', b's', ..]
| [b'p', b'e', b'r', b'c', b'e', b'n', b't', ..]
| [b't', b'o', b't', b'a', b'l', b'_', b'b', b'y', b't', b'e', b's', ..]
| [b'e', b'l', b'a', b'p', b's', b'e', b'd', b'_', b'p', b'r', b'e', b'c', b'i', b's', b'e', ..]
| [b'e', b'l', b'a', b'p', b's', b'e', b'd', ..]
| [b'p', b'e', b'r', b'_', b's', b'e', b'c', ..]
| [b'b', b'y', b't', b'e', b's', b'_', b'p', b'e', b'r', b'_', b's', b'e', b'c', ..]
| [b'b', b'i', b'n', b'a', b'r', b'y', b'_', b'b', b'y', b't', b'e', b's', b'_', b'p', b'e', b'r', b'_', b's', b'e', b'c', ..]
| [b'e', b't', b'a', b'_', b'p', b'r', b'e', b'c', b'i', b's', b'e', ..]
| [b'e', b't', b'a', ..]
| [b'd', b'u', b'r', b'a', b't', b'i', b'o', b'n', b'_', b'p', b'r', b'e', b'c', b'i', b's', b'e', ..]
| [b'd', b'u', b'r', b'a', b't', b'i', b'o', b'n', ..] => (),
_ => panic!("Unrecognized tag"),
}
tag_buffer = [0; 30];
tag_index = 0;
tag_start = false;
}
c => {
if tag_start {
tag_buffer[tag_index] = *c;
tag_index += 1
}
}
}
string_index += 1;
}
} |
Well, I think I should merge #319 first, then it becomes pretty natural... |
I just found this as an opportunity to try how far can const in rust go, here is one more version: const fn check_template(string: &str) {
let string = string.as_bytes();
let mut string_index = 0;
let mut n_wide = 0;
let mut tag_start = false;
let mut tag_buffer = [0; 30];
let mut tag_index = 0;
while string_index < string.len() {
match &string[string_index] {
&b'{' => tag_start = true,
&b'}' => {
if !matches!(tag_buffer.first(), Some(0)) {
let mut actual_tag = tag_buffer.as_slice();
// Remove trailing zeroes
loop {
match actual_tag.split_last() {
Some((a, b)) => {
if *a == 0 {
actual_tag = b;
continue;
}
}
_ => (),
};
break;
}
match actual_tag {
b"wide_bar" | b"wide_msg" => {
n_wide += 1;
if n_wide > 1 {
panic!("Only one wide element is allowed per template");
}
}
b"bar"
| b"spinner"
| b"prefix"
| b"msg"
| b"pos"
| b"len"
| b"bytes"
| b"percent"
| b"total_bytes"
| b"elapsed_precise"
| b"elapsed"
| b"per_sec"
| b"bytes_per_sec"
| b"binary_bytes_per_sec"
| b"eta_precise"
| b"eta"
| b"duration_precise"
| b"duration" => (),
_ => panic!("Unrecognized tag"),
}
}
tag_buffer = [0; 30];
tag_index = 0;
tag_start = false;
}
c => {
if tag_start {
tag_buffer[tag_index] = *c;
tag_index += 1
}
}
}
string_index += 1;
}
} |
That stuff only works on nightly, right? |
Its on stable! (panic on compile time was just stabilized) |
Well, want to see if you can make my parser in #319 const? |
Ill check it out, I doubt its possible though I think its only possible with the Actually I feel like this is interesting I will see if I can add it with konst under an optional compile time flag |
I don't think I want to add the konst crate as a dependency. |
Here is a try (stable rust no dep): https://github.com/sigmaSd/konster/blob/master/src/main.rs Running const Q: Template = Template::from_str(r#"{ "foo": "{foo}", "bar": {bar} }"#);
const R: Template = Template::from_str("{foo:^54.red.on_blue/green.on_cyan}");
#[test]
fn a() {
dbg!(Q);
dbg!(R);
}
|
updated link: https://github.com/sigmaSd/konster/blob/master/src/lib.rs (updated the above test results as well) |
Update link: https://github.com/sigmaSd/konster/blob/master/examples/indicatif.rs (also updated the test results above) |
This is very impressive work, thanks for demonstrating this! I don't think it makes sense to merge this now, as I think being const adds a whole bunch of complexity and substantially bumps the MSRV while the benefit ends up being minor. If you want to submit a PR that changes the |
Thanks! This is more of a demo of what might be possible in futures releases hopefully. I don't this this is really worth breaking the api, if you think its a good idea I can add it of-course. |
Well, the next release is an API-breaking release anyway, but might still not be worth breaking this particular API. I'm probably inclined to agree that it isn't worth it on its own. |
Here is an example of the issue ouch-org/ouch#214
I think this line https://github.com/mitsuhiko/indicatif/blob/c43d7b3d8789027835771888310f2a1416665de1/src/style.rs#L293 only expects one wide element
If this is an intended behavior, I can open a pr to document this
The text was updated successfully, but these errors were encountered: