A local shop here only has shopping carts, no baskets. You can get smaller shopping carts, and in fact even shopping carts for toddlers to push around, but you still need a coin for those.
And yep, I've genuinely been stood in front of that shop and went back home, because I didn't have an appropriate coin. I think, even twice already.
I could have bought a small item to have them hand me out coins and then done another loop with the shopping cart, but yeah, there was just no way, I'd waste that much time.
So, they go into the menu, then press the "Exit" button.
Unfortunately, that video is already out of date again, as there's now a general "Settings" button where the "Touchscreen Layout" button was. But in those settings, you can select the "Touchscreen" category and then that button is near the top.
Then it works like in the video again, by pressing "Add button" and so on.
Yes, let's call it "good eye" and not "damn, you really had this meme burnt into your terminally-online brain cells to the point where you'd recognize this random internet cat from a different picture".
That is a much better name, yes, haha.
At first I thought, this was the same beats, just with staggered emphasis, but no, that's 30 eighths in the timespan of 14 eighths.
So, it's like the bassoons are playing sixteenth notes, except that they're decidedly not in sync with everyone else.
At first it'll sound like they're too early. Then their offbeat sixteenth will sync up with the on-beat for everyone else. Then their offbeat will sound like it's too early compared to the on-beat, until they sync up properly again. Well, and then you do that cycle a second time, because they have to fit two extra notes in there.
Yeah, that does seem quite impossible to conduct, but even if you set up two metronomes, that'll throw even good orchestras quite easily...
I artificially limit myself to Creative Commons music. Never been particularly convinced of digital ownership, so I prefer stuff that I can re-download at any time. I do also like a lot that I can share the music files freely.
Well, and a very personal reason for limiting the selection, is that I'm a hobby musician myself. It helps convince my brain that my own music is worth creating, if I'm not constantly bombarded with an infinite selection of amazing music...
Oh wow, so it's kind of suffering from success, in that you might have understood it better, if it didn't have a translation for your native language... 😅
Interesting. Presumably, enough of their customers now show up without the appropriate coins, due to electronic payment methods being available otherwise, that they decided to not require coins.
Here in Germany, where we hold onto cash a bit more dearly due to our Stasi-past, I don't know any shop where I can take a shopping cart without sticking a coin in...
Hmm, is there a way to improve that, like a different word that's normally used? I could probably contribute a fix for the translation to the project...
Hmm, not sure, if I've heard of it. I'm guessing, we're not talking about simply drawing a UML class diagram...? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?
Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using .unwrap() and .expect().
String vs. &str can mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the & at times, but that's then trivial to solve (by just adding the &).
"temporary value dropped while borrowed" can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
"missing lifetime specifier" is also largely solved by not storing references in structs.
The thing with OOP, particularly how it's used in GCed languages, is that it's all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it's modified in asynchronous code.
Rust has quite the opposite mindset. It's all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.
But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.
Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.
¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don't need them.
A local shop here only has shopping carts, no baskets. You can get smaller shopping carts, and in fact even shopping carts for toddlers to push around, but you still need a coin for those.
And yep, I've genuinely been stood in front of that shop and went back home, because I didn't have an appropriate coin. I think, even twice already.
I could have bought a small item to have them hand me out coins and then done another loop with the shopping cart, but yeah, there was just no way, I'd waste that much time.