6 ms·

> There's no standard way of doing file watching across BSDs, Mac OS and Linux. You are correct, but that's about the only divergence matters in this context.

> There's no standard way of doing file watching across BSDs, Mac OS and Linux. You are correct, but that's about the only divergence matters in this context. As I've noted elsewhere, you can't even safely use `char*` for file names in Windows; it should be `wchar_t*` in order to avoid any encoding problem. > Are you referring to the clear feature? Yes, it's fixed. It's also pretty standard in that regard. At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). > spamming colours everywhere is eye candy not a feature Agreed that "spamming" is a real problem, provided that you don't treat any amount of color as spamming. > Which is unnecessary and entirely cargo specific. Meanwhile you can achieve the same effect with entr by just chaining it with an appropriate jq invocation. entr is more flexible by not having this feature. Cargo-watch was strictly designed for Cargo users, which would obviously want to watch some Cargo workspace. Entr just happens to be not designed for this use case. And jq is much larger than entr, so you should instead consider the size of entr + jq by that logic. > Not really anywhere near as many lines as you seem to think. Yeah, my estimate is about 300 lines of code with a carefully chosen set of interface. But you have to ensure that it is indeed correct yourself, and JSON is already known for its sloppily worded standard and varying implementation [1]. That's what is actually required. [1] https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html > Yes, I think trying to golf the problem is probably not appropriate. But 4M LoC is fucking ridiculous by any metric. 1M would still be ridiculous. And that 4M LoC is fucking ridiculous because it includes all `#[cfg]`-ignored lines in various crates including most of 2.2M LoC in the `windows` crate. That figure is just fucking incorrect and not relevant! > 100k would also be ridiculous 50k is still pretty ridiculous. And for this part, you would be correct if I didn't say the "faithful" reproduction. I'm totally sure that some thousand lines of Rust code should be enough to deliver a functionally identical program, but that's short of the faithful reproduction. This faithfulness issue actually occurs in many comparisons between Rust and C/C++; even the simple "Hello, world!" program does a different thing in Rust and in C because Rust panics when it couldn't write the whole text for example. 50K is just a safety margin for such subtle differences. (I can for example imagine some Unicode stuffs around...)

Arch-TK 2y ago
> As I've noted elsewhere, you can't even safely use `char` for file names in Windows; it should be `wchar_t` in order to avoid any encoding problem. Yes, this is true. But I think the overhead of writing that kind of code would not be as enormous as 30k lines or anything in that order. > At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). Maybe. It's an explicit option you must pass. It's often useful to be able to override isatty decisions when you want to embed terminal escapes in output to something like less. But for clear it's debatable. I would say it's fine as it is. Also, if isatty is "the very least" what else do you propose? > Agreed that "spamming" is a real problem, provided that you don't treat any amount of color as spamming. I treat any amount of color as spamming when alternative options exist. Colours are useful for: syntax highlighting, additional information from ls. Not for telling you that a new line of text is available for you to read in your terminal. There are many things where colours are completely superfluous but are not over-used. I still think that colours should be the exception not the rule. > Cargo-watch was strictly designed for Cargo users, which would obviously want to watch some Cargo workspace. Entr just happens to be not designed for this use case. And jq is much larger than entr, so you should instead consider the size of entr + jq by that logic. Yes jq is larger than entr. But it's not 3.9M SLOC. It also has many features that cargo-watch doesn't. If you wanted something cargo specific you could just write something specific to that in not very much code at all. The point is that the combination of jq and entr can do more than cargo-watch with less code. > and JSON is already known for its sloppily worded standard and varying implementation [1]. That's what is actually required. I hope you can agree that no number of millions of lines of code can fix JSON being trash. What would solve JSON being trash is if people stopped using it. But that's also not going to happen. So we are just going to have to deal with JSON being trash. > And for this part, you would be correct if I didn't say the "faithful" reproduction. I'm totally sure that some thousand lines of Rust code should be enough to deliver a functionally identical program, but that's short of the faithful reproduction. This faithfulness issue actually occurs in many comparisons between Rust and C/C++; even the simple "Hello, world!" program does a different thing in Rust and in C because Rust panics when it couldn't write the whole text for example. 50K is just a safety margin for such subtle differences. (I can for example imagine some Unicode stuffs around...) Regardless of all the obstacles. I put my money on 20k max in rust with everything vendored including writing your own windows bindings. But neither of us has time for that.

Arch-TK 2y ago

> As I've noted elsewhere, you can't even safely use `char` for file names in Windows; it should be `wchar_t` in order to avoid any encoding problem. Yes, this is true. But I think the overhead of writing that kind of code would not be as enormous as 30k lines or anything in that order. > At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). Maybe. It's an explicit option you must pass. It's often useful to be able to override isatty decisions when you want to embed terminal escapes in output to something like less. But for clear it's debatable. I would say it's fine as it is. Also, if isatty is "the very least" what else do you propose? > Agreed that "spamming" is a real problem, provided that you don't treat any amount of color as spamming. I treat any amount of color as spamming when alternative options exist. Colours are useful for: syntax highlighting, additional information from ls. Not for telling you that a new line of text is available for you to read in your terminal. There are many things where colours are completely superfluous but are not over-used. I still think that colours should be the exception not the rule. > Cargo-watch was strictly designed for Cargo users, which would obviously want to watch some Cargo workspace. Entr just happens to be not designed for this use case. And jq is much larger than entr, so you should instead consider the size of entr + jq by that logic. Yes jq is larger than entr. But it's not 3.9M SLOC. It also has many features that cargo-watch doesn't. If you wanted something cargo specific you could just write something specific to that in not very much code at all. The point is that the combination of jq and entr can do more than cargo-watch with less code. > and JSON is already known for its sloppily worded standard and varying implementation [1]. That's what is actually required. I hope you can agree that no number of millions of lines of code can fix JSON being trash. What would solve JSON being trash is if people stopped using it. But that's also not going to happen. So we are just going to have to deal with JSON being trash. > And for this part, you would be correct if I didn't say the "faithful" reproduction. I'm totally sure that some thousand lines of Rust code should be enough to deliver a functionally identical program, but that's short of the faithful reproduction. This faithfulness issue actually occurs in many comparisons between Rust and C/C++; even the simple "Hello, world!" program does a different thing in Rust and in C because Rust panics when it couldn't write the whole text for example. 50K is just a safety margin for such subtle differences. (I can for example imagine some Unicode stuffs around...) Regardless of all the obstacles. I put my money on 20k max in rust with everything vendored including writing your own windows bindings. But neither of us has time for that.