Earlier quoted context omitted.
The old man the boat
The horse raced past the barn fell
I still have never managed to understand that one properly
Fixing Ctrl+C in Rust terminal apps: Child process management
41–50 of 62 posts
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#42Earlier quoted context omitted.
The horse raced past the barn fell
I still have never managed to understand that one properly
I think it shall be interpreted like this: The creature who fell was the horse (that was previously raced past the barn). I.e. it was not the barn that fell.
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#43This title was close to being a garden path sentence, but ultimately avoided it.
I have never undestood why garden path sentences are interesting. They can always be rewritten to make more obvious sense. Its like saying theres a way to take any sentence and remove some words to make its intended meaning confusing. I dont personally find this interesting, just frustrating that the author didnt take more time to use punctuation or more words to convey explicit meaning.
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#44[dead]
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#45Earlier quoted context omitted.
I still have never managed to understand that one properly
I think it shall be interpreted like this: The creature who fell was the horse (that was previously raced past the barn). I.e. it was not the barn that fell.
Thankyou that makes sense!
So in reality this is just an incorrect sentence. It should be written as
"The horse that raced past the barn fell"
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#46Earlier quoted context omitted.
I think it shall be interpreted like this: The creature who fell was the horse (that was previously raced past the barn). I.e. it was not the barn that fell.
Thankyou that makes sense! So in reality this is just an incorrect sentence. It should be written as "The horse that raced past the barn fell"
It’s ambigous, but is it incorrect?
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#47Fearless concurrency with Rust unless you are worried about lifecycle management, threads/co-operation and general ergonomics. Even modern c++ might be better at this (gasp!) with std::jthread
I believe Rust's std::thread::scope is an equivalent. > Unlike non-scoped threads, scoped threads can borrow non-'static data, as the scope guarantees all threads will be joined at the end of the scope. > All threads spawned within the scope that haven’t been manually joined will be automatically joined before this function returns.
So, std::jthread is basically fixing std::thread. In C++ it's difficult to fix broken standard library features so they just make a new thing and discard the old busted one. Landfill programming.
The fact Rust actually has scoped threads is unrelated, in Rust they can do this because they have working lifetime checking and in C++ such a feature would be meaningless, you're always assumed to have manually ensured the correct lifetimes and they aren't checked.
Generously you could say they're gesturing at the fact C++ decided to bolt the stop flag mechanic to jthreads, so you can have the old broken threads or this newer non-broken threads which also has built-in stop flags. But that's less choice, it's not as though you can't have a stop flag in Rust.
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#48Handling SIGINT (ctrl-c) with child processes is tricky, but a more pervasive problem for Rust CLI programs is handling SIGPIPE. For historical reasons the compiler adds a signal handler before calling main() which ignores SIGPIPE. It means when you pipe your Rust CLI program's output to something like head, instead of being killed by the signal sent when head closes the pipe, you get a write error and usually print an error message instead of silently dying. You can match on the type of write error and skip printing a message when it's from a broken pipe, but a more subtle problem is that the shell sets the exit status of a program killed by a signal to 128 + the signal number, so 141 in the case of a broken pipe. You can emulate this behaviour by checking for a broken pipe and explicitly exiting with a 141 status code, but it's not possible to fully reproduce being killed by a signal. There's been an issue to make this configurable (the latest proposal is via a compiler flag) for years.
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#49Earlier quoted context omitted.
Thankyou that makes sense! So in reality this is just an incorrect sentence. It should be written as "The horse that raced past the barn fell"
It’s ambigous, but is it incorrect?
If language is constantly changing due to how people use it rather than sticking to a strict set of rules, then in my opinion gramatically correct sentences should always be explicit and never ambiguous.
Re: Fixing Ctrl+C in Rust terminal apps: Child process management
#50Earlier quoted context omitted.
I think it shall be interpreted like this: The creature who fell was the horse (that was previously raced past the barn). I.e. it was not the barn that fell.
Thankyou that makes sense! So in reality this is just an incorrect sentence. It should be written as "The horse that raced past the barn fell"
It should be.
But it’s not incorrect to say
The tree grown tall is the one I planted
The horse raced past had somewhere to go
It’s easier to read
The tree grown tall last year withered
You can artificially push out the point at which the sentence disambiguates between whether the word is past tense or past particle, and make it seem that it’s probably past tense until it can’t be.
You could say that the sentence is LL(k) for an unintuitively high k.