I've also tried Gemini 3 for Clues by Sam and it can do really well, have not seen it make a single mistake even for Hard and Tricky ones. Haven't run it on too many puzzles though.
AFAIK Finland always had more separated sauna culture. They have so many saunas that you specifically pick when you want to go to mixed sauna.
In Germany or parts of eastern europe saunas are popular but there are not that many of them so they end up mixed gender. Also everybody is going to saunas in Finland where as in Germany its much more thing for "fans" or "experienced" sauna goers that maybe accept it as part of the whole thing.
USB HID actually works pretty much how you describe, for instance a Physical Descriptor can contain metadata about which body part a button/control is supposed to be used with.
It's extremely complicated however (like many things USB), which is probably why everything just emulates an XBox 360 controller like you said.
It's related to XInput making that easier option on Windows, from my understanding.
Especially if you supported both XBox and Windows.
So the only complex HID game controllers are for very much enthusiast setups, which are rare enough to trip things like absurd assumptions in HID drivers in some systems (the joystick+throttle I have used to break linux HID driver because someone decided to statically allocate possible amounts of joystick buttons per device...)
It'd be interesting to see a setup where a Linux-capable SoC would run the Arduino application on a isolated CPU core with no interrupts handled, so you'd still have real-time guarantee for the Arduino app
It runs the Arduino app on a separate mcu stm32l4 I think. So you have the realtime as well, but what you describe is already possible with the pi and asymmetric multiprocessing using openamp and zephyr.
For handhelds the temperature of the device's case is one factor as well when deciding the thermal limits (so you don't burn the user's hands) - less of a problem on laptops.
Ya that's what I'm hoping, because I've been blasted for a second or two here and there. I guess I could put a CD next to it and see if it crackles haha. But I'll probably just recycle it and move on.
To be clear `File::drop()` does sync, it just ignores errors (because `drop()` doesn't have a way of returning an error). It's not really Rust specific I guess, I just don't know off the top of my head what other languages behave this way.
I believe C++'s fstreams also ignore errors on destruction for similar reasons.
I've wondered for a while what it'd take to eliminate such pitfalls in the "traditional" RAII approach. Something equivalent to deleting the "normal" RAII destructor and forcing consumption via a close() could be interesting, but I don't know how easy/hard that would be to pull off.
There's no reason that throwing exceptions in finalisers must be prohibited. It's just bad design.
Modern Java provides the concept of suppressed exceptions. Basically an exception can maintain the list of suppressed exceptions.
When stack unwinds, just allow finaliser to throw an exception. If it threw an exception, either propagate it to the handler, unwinding stack as necessary, or add it to the current exception as a suppressed exception. Exception handler can inspect the suppressed exceptions, if necessary. Exception print routine will print all suppressed exceptions for log visibility.
Java does not do it properly for finally blocks, instead overwriting current exception, probably because the concept of suppressed exception was introduced in the later versions and they wanted to keep the compatibility.
IIRC C++ and Rust don't technically prohibit throwing exceptions out of destructors; it's triggering unwinding during unwinding that's the main problem.
Does make me wonder about the specifics behind that. I had assumed that there are some kind of soundness issues that force that particular approach (e.g., https://github.com/rust-lang/rust/pull/110975, "Any panics while the panic hook is executing will force an immediate abort. This is necessary to avoid potential deadlocks like rustc hangs after ICEing due to memory limit #110771 where a panic happens while holding the backtrace lock."; alternatively, some other kind of soundness issue?), but I don't have the knowledge to say whether this is a fundamental limitation or "just" an implementation quirk that basically got standardized. Rust' first public release was after Java 7, so in principle the precedent was there, for what it's worth.
It does not. BufWriter<File> flushes its userspace buffer (but doesn't fsync either). If you have a bare File then drop really just closes the file descriptor, that's it.
reply