try_lock
already exists; it’s called lock
. I just want a more convenient name and I want the name of the new method to be lock
, but that ship has sailed.
try_lock
already exists; it’s called lock
. I just want a more convenient name and I want the name of the new method to be lock
, but that ship has sailed.
Looks like the author missed my main complaint about Rust mutexes, which is that the lock
method returns a Result
. There should be a try_unlock
method for when someone actually wants to handle the rather obscure failure case, and the name lock
should be used for a method that panics on failure but returns a value that doesn’t need to be unwrapped first. I see the current arrangement as being about as sensible as having array subscripting return a Result
to handle the case of a failed bounds check.
The newer version is: https://w3c.github.io/openscreenprotocol/
I used to be on that team at Google and when I left they were working on an open source implementation of it.
Miracast is a separate, older protocol from what Chromecast uses.
Jesus Christ, calm down. They’re not “fucking with” your phone by they’re asking you to use an app to perform your job duties. And I’d expect any employer to provide you with a suitable phone if you don’t want to use your own. Using your own personal phone is just a convenience for you, and having requirements that phone has to meet us perfectly reasonable.
I think you’re underestimating how resistant to charge old people can be.
Just because they haven’t told you about the requirements doesn’t mean they don’t exist. They probably don’t support custom ROMs and they didn’t tell you because they just assumed you’re running the OS that came with the phone.
Sounds like you’re using a phone that doesn’t meet the requirements specified by your employer. Might I suggest asking them for a company phone?
I know people in tech who use iPhones. But they’re definitely the exception.
🤡
Everything in the video is considered acceptable in open source code today. If it wasn’t, it wouldn’t have been right there in the code for the person making the video to find it.
Oh please. This comment has the same energy as Dave Chappelle doing a whole Netflix special about how he’s been cancelled.
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.
From is run by Vogons!
Nah, I did everything wrong in my 20s and I experienced nothing like OP’s symptoms.
Earth’s atmospheric pressure just doesn’t change as much as you seem to think it does.
Lenses for full size-cameras are made airtight. It’s not a problem.
You asked for a yes or no answer on Google being a monopoly, and it said yes. What more do you want? Your issue is that Google confessed but not thoroughly enough?
I think a better solution would be to add a method called something like ulock that does a combined lock and unwrap.
My concern with lock+unwrap is only partly because of convenience; I also didn’t like it because I think it’s a bad idea to get people used to casually calling unwrap, because it tends to hide inadequate error handing.
Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”. In one or two of those cases you want to leave it in my production code, and in the last you want to audit all instances and replace them with proper error handing. Using the same function for all three cases makes that difficult.