If you want the source to repeat indefinitely, you can try calling repeat_infinite on it. Combine that with pausable/stoppable, and use periodic_access to occasionally check whether the audio source should be paused/stopped probably by using an Arc[AtomicBool] (using square brackets because Lemmy hates angle ones).
It could look something like this:
rs
let src = ...;
let stop = Arc::new(AtomicBool::default());
let stop2 = stop.clone();
let src = src
.repeat_infinite()
.stoppable()
.periodic_access(Duration::from_millis(50), move |src| {
if stop2.load(Ordering::Relaxed) {
src.stop();
}
});
// later on...
stop.store(true, Ordering::Relaxed);
periodic_access is also how Sink controls the source when you want to pause/stop/etc it. You could probably use Sink directly if you want more control over the source.
I believe they're already allowed in Germany actually, although their autonomous driving feature is very limited in where it can be activated. Hopefully other vehicle manufacturers follow suit and take liability when doing autonomous driving (as opposed to "assisted driving", which many vehicles currently have).
Turn them off, or repurpose them into Minecraft servers for friends. I'm using more resources running a modded server I don't play on than I am for actual productive work these days though.
I remember something about Mercedes taking liability when self driving is active, although I don't know if that still holds. Still, this seems like something that can be approached with proper legislation, assuming we can get past the lobbying BS in the US (though the EU will probably make the right call much sooner).
The day I can get in a car and not be simultaneously afraid of my own shortcomings and the fact that there are strangers driving massive projectiles around me is a day I will truly celebrate. The fact is that automobiles are weapons, and I don't want to be the one wielding it when a single mistake can cost an entire family their lives, although I would like to be there to slam on the brakes and prevent it if needed.
As someone fortunate enough to have a well paying job, I can't imagine ever having a child. The amount of stress on top of my job in addition to the extremely high cost of raising a child would just push me over the edge, and that's ignoring the fact that my current home can't really accommodate another (our second bedroom is my office, no clue how we'd make that work since I do my job from there).
I think it's honestly a combination of two things: a cost of living that continues to increase faster than our wages, and an ever increasing expectation from workplaces on employees. At one point, it was possible (and common) to have a single working member of the family support the other members on their own. These days, you'd have to be pretty much a 1%er to afford that, at least in more urban areas.
For me it's pretty much any competitive multiplayer game. I don't dislike the games, I usually dislike the communities. That was one of the big things that turned me away from Overwatch (the first one) for example, the gameplay was fun but I just wish I could choose who I was playing with.
Needless to say, I stick with singleplayer games these days, or at least less competitive multiplayer games. Games with good local multiplayer, like SSBU, are also pretty fun when I can get a group together.
I guess the flaw is that it's (almost) never used only for planning and is often used as a metric of productivity, from my experience. It becomes a competition to see who can check off the most story points, and velocity is often used to compare developers against each other.
Story points and velocity always felt to me like a flawed metric. It encourages volume of work, and discourages quality of work. The worse your code is, the more stories and tasks you can create to fix it, and the higher your velocity. It's a bit of a shame that it's used so widely as a measurement of work completed, and I wish a better means of measuring productivity would become more popular instead.
I trust my team. I don't trust my or their ability to write and merge perfect code each time. I'm not sure how we'd fix that problem aside from becoming programming gods.
Odd, it wouldn't even let me enable it for old.beehaw.org until I turned it on for beehaw.org. Strange issue, but thanks for sharing! I managed to get it enabled.
I really wish Python had multi-line lambdas. Sadly Python is very opinionated in ways I don't quite understand, but I can at least respect while using it.
For interfaces, honestly all I can suggest is using an ABC with only @abstractmethods. It's not perfect, but it's basically what you'd do in C++ anyway. If you're looking for an interface that models data, you could look at dataclasses or TypedDict (depending on what kind of data it is), but it's just not going to match what's possible in TS sadly (mapped types, conditional types, complex union types, custom type guards, etc).
You also have to be careful with what other USB devices you plug into your computer (both internal and external). The spec is 40 Gb/s for the controller, but ports often share the same controller and the bandwidth will be split between connected devices. For some computers, this could mean that 3 or more ports should be completely blocked off when plugging your gaming USB drive in, at least while playing the game. If your PC only has a single USB controller, I guess you'll also need bluetooth peripherals.
Compared to a HDD, yeah USB 3.0 speeds aren't too bad, but most laptops being released these days use an NVMe for storage (or possibly even a soldered drive). My comparison was around what you'd expect in a laptop purchased in the past year or so.
For your partner's laptop, getting better read performance from an external drive doesn't surprise me, but there are also limits to this. Games are starting to support DirectStorage, which allows the GPU to directly read and decompress assets from the hard drive. This won't work with an external drive (at least from my understanding), so those games will likely fallback to much slower methods of loading assets if they support the laptop at all. This is also not taking into account the other hardware on the laptop, which might have been excellent for the time, but with how much CPUs and GPUs have advanced over the past 4 years, I wouldn't be surprised if they're starting to reach their limits with today's major releases.
USB 3.2 gen 2x2's theoretical speeds cap out at 20Gb/s (or 2.5GB/sec). It's certainly a performance improvement compared to USB 3.0, but still doesn't quite meet the performance of an internal NVMe. If your PC supports Thunderbolt, you get double the bandwidth (so 5GB/sec) which does match what some slower PCIe 4.0 NVMe drives can handle. This is of course assuming you're comparing to a NVMe, a SATA drive won't come close to these speeds but I believe most laptops these days use NVMe drives.
Regardless, if you're loading games off a USB 3.2 gen 2x2 interface, and assuming you're using a single drive to a single controller (keep in mind that performance is split between connected devices per controller, and PCs often only have a couple controllers at most to manage all the ports), your read performance is probably more than enough.
If you want the source to repeat indefinitely, you can try calling
repeat_infiniteon it. Combine that withpausable/stoppable, and useperiodic_accessto occasionally check whether the audio source should be paused/stopped probably by using anArc[AtomicBool](using square brackets because Lemmy hates angle ones).It could look something like this:
let src = ...; let stop = Arc::new(AtomicBool::default()); let stop2 = stop.clone(); let src = src .repeat_infinite() .stoppable() .periodic_access(Duration::from_millis(50), move |src| { if stop2.load(Ordering::Relaxed) { src.stop(); } }); // later on... stop.store(true, Ordering::Relaxed);periodic_accessis also howSinkcontrols the source when you want to pause/stop/etc it. You could probably useSinkdirectly if you want more control over the source.