3,935 karma · joined March 24, 2020
denying self-determination is the root of hierarchy and fascism
It might be worth testing/forking the library to test on Loom (https://github.com/tokio-rs/loom), which can model atomic orderings and check for concurrency errors to some degree (though I last used it years ago). TSAN might be able to check for ordering errors in visited execution traces (though I haven't tried using it in the past).
A few years ago, I've built attenuators out of voltage dividers (using around 2-20 ohm resistors). Unfortunately at any given attenuation factor, there's a limit to how high of an impedance you can expose to the audio source, along with how low of an impedance you can expose to the headphones. Additionally, to compensate for stray ground-line resistance causing inverted crosstalk between the stereo channels, I also add a crossfeed resistor or potentiometer of 500 ohms or so, ideally tuned based on the headphone impedance. If you use a potentiometer you can take one side of your headphones/earbuds off, send loud noise to that side alone, and turn the potentiometer knob until no sound is audible in your remaining ear. (To determine the correct fixed resistor value, you can send quiet noise to the remaining ear and adjust its volume until it cancels out crosstalk.) Also since I use TRS cables/sockets, this breaks headphone mics.
I've been meaning to make a PCB version of my attenuator with SMD resistors to reduce space, but don't know where to find a reliable PCB-mount headphone jack (or 3.5mm dongle cable). If anyone has suggestions for a PCB-mount headphone jack (available in the US), let me know!
> His claim is that structured concurrency is the only way to make Ctrl+C handling work in a way how users naively expect it to work.
> And it’s easy to see why: If the exceptions are propagated up the call tree, freely crossing the thread boundaries, the KeyboardInterrupt exception is eventually going to reach the top of the call three (main function) and exit cleanly.
> However, there’s a hidden race condition involved: Imagine two threads in a scope, one gets KeyboardInterrupt and the other one raises an unrelated exception. If the latter exception bubbles up to the parent thread faster it will cancel the thread that’s processing KeyboardInterrupt and Ctrl+C would get lost.
I wonder if progress has been made since 2019.
You should touch up the joints with external flux.
> Second, we also found that participants first exposed during middle childhood (ages 6–10) to other types of interpersonal violence, including witnessing a friend or family member being murdered or being attacked with or without a weapon, had depressive symptoms scores that were about twice as high as those first exposed during adulthood. Similar results were also detected for PTSD, but were not statistically significant after adjusting the frequency or number of occurrences of child exposure. These results are consistent with at least some prior studies suggesting that trauma during middle childhood, including severe illness 41, or natural disasters 34–36 is associated with an elevated risk for PTSD relative to exposure in other periods. Although the mechanisms driving this association are unclear, exposure to interpersonal violence events during middle childhood may be more harmful than exposure in adulthood for a number of reasons: school-age children may be in a unique developmental stages where they do not benefit as much from parental buffering 62, when demands from the social environment increase (i.e., relating to peers, participating in school activities) 63, and when adaptive coping capacities are still developing 64.
Guess I'll die...
it wasn't an obscure hardware issue related to corrupted firmware, but just the laptop (Windows 7) dies when it tries to go from sleep to hibernate after 6 hours
>DALL-E-2023-12-02-15.50.18---A-serene--contemplative-scene-inspired-by-Elder-Sophrony-of-Essex-s-quote.-The-image-depicts-a-peaceful-landscape-with-a-deep--dark-abyss-in-the-backg
What's causing the issue? Perhaps the coin cell battery is drained (and I didn't know the right way to test CR2032s at the time, so I thought it was good)? Or is the EC fried or corrupted, perhaps because I did a botched BIOS reflash which corrupted the EC, and had to reprogram the EC in flashrom over multiple passes while skipping "hung" flash blocks (the pin to hold the EC in reset didn't make flash properly writable)? Afterwards the laptop would boot, but dumping the EC flash again revealed the image was changed again. Or did the EC die due to flash corruption that occurred afterwards (either from flaky chips or because I damaged it earlier)?