I wish it hadn't taken me so long to realize that (for me personally) cardio is the most effective ADHD medication available

I can feel my brain starting to take damage from the number of times I have started to read something (code or prose) under the assumption it was written by a human and only realized partway through that it was slop

any model-based reinforcement learning algorithm with tunable hyperparameters is secretly just the inner loop of a model-free meta-reinforcement learning algorithm (using any black-box optimization algorithm, e.g. evolution strategies), and the bitter lesson says that you should treat it as such

@utopia-defer.red

If Sublime Text has million users writing Rust, then I'm one of them.
If Sublime Text has zero users writing Rust, that means I'm dead.

guys, you're still trying to replace meat. I told you, we can't do it. now, what we might be able to do is recreate it in the aggregate

why do you eat it?
*brad pitt points to jonah hill*
because it fits my macros

sup big dog how many pilates you got on that barre

not literally porting to C, see bsky.app/profile/tomf...

fun thing to do after gaining some muscle is to perform every movement in your daily life (opening and closing cupboards and doors, etc.) a little bit more explosively

the Y combinator could also be a metaphor for things that replicate without bound and consume all available resources

all the FUD about phytoestrogens in soy milk and tofu is a psyop to keep you from getting big

In fact, Mutex<T> actually has a get_mut method (doc.rust-lang.org/stable/std/s...) which takes &mut self and gives you a &mut T without any locking, since the &mut Mutex<T> is proof that you already have exclusive access

The purpose of Mutex<T> is basically to allow you to take a shared &Mutex<T> reference and safely produce a unique &mut T reference from it ("interior mutability"). If Mutex::lock required a &mut Mutex<T>, it wouldn't allow you to do anything you couldn't already do with a &mut T in the first place

That is not true at all! Mutex::lock takes &self, not &mut self (doc.rust-lang.org/stable/std/s...), which means it's completely possible to call it twice from a single thread, resulting in a deadlock: play.rust-lang.org?version=stab...

I'm not sure what you mean by "essential." Given that Mutex returns a mutable reference to its contents, it very much *is* essential for it not to be re-entrant, or else (as you just said) a program could violate Rust's typing rules by forming two simultaneous mutable references to its contents.

but Mutex<T> is only able to guard the state properly in Rust *because* it isn’t re-entrant. in other words, Mutex<T> isn’t re-entrant in Rust for exactly the reason Rob is expressing in that post

😂

yeah, it’s hard to imagine them doing this for another reason

the VST 3 SDK was recently changed from a dual GPLv3–proprietary license to the MIT license, which made it possible for me to simplify the build process for vst3-rs (the set of Rust bindings that I maintain). I wrote a blog post with some more details: micahrj.github.io/posts/vst3/

97-year-old web designer still prevents margin collapse the old-fashioned way

Screenshot of Wikipedia article: George Boolos From Wikipedia, the free encyclopedia Not to be confused with George Boole.

imagine being a logician named George Boolos en.wikipedia.org/wiki/George_...

laughing at the idea of a builder-pattern interface in C++ that uses move semantics to pass the builder between method calls

Safe area (television) - Wikipedia

I think historically console games basically had to keep everything important inside a “safe area”, much like macOS/iOS software has to do now on devices with a notch en.wikipedia.org/wiki/Safe_ar...

100% helpful 0% obnoxious. actually would you mind if I keep bugging you with occasional max questions going forward?

really glad I made this thread now haha, all of your responses have been very helpful

oh right! ok awesome

also the interpolation functionality of the preset object looks extremely cool and useful, I feel like I will use this a lot

ah okay cool! so just hooking up a preset object to my flonums will more or less do what I want (with one extra step to save/load the preset)

but both of those require manually copying the value from one node to another at some point, which I find frustrating because I want to be able to open a patch, tweak a value with click-and-drag, then save and close it without extra steps

there are some workarounds, like putting a message node after the flonum node so that its value does get saved when you close the patch, or putting a loadmess node before the flonum node so that its value gets initialized to something when you open the patch