drzaiusx11
drzaiusx11 on Hacker News
Reread the post and it sounds more like a one-shot export/transform instead of recurring crawler. Bummer.
Any chance you'll make a cron (at reasonable for hn rates) of this?
A organic 3m respirator and lab grade gloves really should be required with these things. The cheap overseas options I expect them to downplay the hazzards, hopefully formlabs manuals etc are better w.r.t. safety (I don't own one.) I love my resin prints for their near flawless finishes compared to filament, but it comes at a pretty steep cost.
My anycube costs a fraction of this and I don't need to shell out for any proprietary nonsense like cartridges. I use all open source tooling as well. For $700 I got a resin printer, several diverse resin types, a fume extraction hood/enclosure, a infrared curing box and automatic washer tank.
Anecdotally, I've observed several families (including my own) where one child did not exhibit any ADHD behaviors through adulthood and another that did, separated by only one year and raised together. It's certainly possible there could have been some category of unnoticed traumatic events, but I think a genetic predisposition is more likely, no?
That said, I was likely jumping to conclusions on causality when the science is still out. CPTSD and ADHD may turn out to be the same thing, or may not. They just happen to "look the same" in brain scans.
CPTSD literally rewires your brain and "appears" in diagnostic tests as ADHD: lower arousal in prefrontal cortex, overactive amygdala causing fast emotional response, impacted hippocampus, dopamine disregulation, etc.
Stress changes the layout of your brain along with your body's chemical responses. With ADHD, genetics seem to play a larger role where you can lack the stressors and still end up with the same end result. I wouldn't be surprised that treatments would work across both CPTSD and ADHD.
It's also worth noting that LLM are fairly well suited to finding and documenting "load bearing" legacy bugs (when set out to do exactly that.)
I know because I've spent the better part of a year having them do exactly this as a precursor to rewrites in more perfomant tech stacks. Once this research is done, it's a fairly safe and mechanical translation job.
If wasm worked is a pretty big caveat still. DOM APIs are still significantly slower in rust using wasm than pure js last I checked.
We had some "ghosting" on the displays on a few now that you mentioned it, but they were still 100% usable. I guess my expectations were lower since I never had to foot the bill for the lot of em (which at 20k/unit I guess I'd be upset about when one was faulty)
I'm blanking on the exact models I used; I'm fairly certain they were tds700s or tds71xx, but a lab I ran had about a dozen units and we had nothing "fry" in the 4 years I worked there. What applications would result in these catastrophic failures?
Are you implying a direct bug for bug port is more expensive than converting to an intermediate representation and then converting via generators? Depending on the "fidelity" of the representation I'd figure the costs are about the same.
Many fond memories of using these. Glad someone is keeping them going after 20+ years of service.
I recently performed this exact exercise of converting a complex library set from one language into an intermediate state machine representation and then translated into N other languages. It worked well but there's a lot of caveats. I'd highly recommend a direct "port" in most cases tbh, as many bugs are "load bearing" and may not survive the intermediate translation. I speak from experience.
As an avid dog owner I ensure my pets have a rich home life. However, at this point in my life I've seen countless pet owners callously fall short of providing even basic pet needs: walks, enrichment activities, etc. (I've fostered and adopted multiple rescue dogs)
I welcome a humane substitute for those without the time or understanding to properly care for another living creature. Mostly people should not be allowed to have a living pet.
I maintain(ed) node bindings[1] for the old Roomba din OI serial protocol. Although it's targeting the old "create" educational series, it actually works on all Roombas predating the 900 series!
[1] https://github.com/drzaiusx11/create-oi
JRuby is another option for Java interop, although inline types are sorely missed still. TRuby is an interesting project in that regard though
Very hard on queens in particular
I've been keeping bees for well over a decade now, and Varroa mite management and prevention of downstream disease vectors like deformed wing virus are consuming ever greater amounts of our time and concern in the community.
Personally, I've tried a number of mitigations with varying levels of success--most all resulting in requeening due to toxicity of treatment. At this point unless a truly successful new therapy is found it seems like a losing battle tbh. I meet monthly with beekeepers and scientists monthly for a few years now, an 99% of the time discussions involve Varroa destructor. It has that name for a reason...
Analog to digital converters (components generally built-in to uCs and SoCs but you can make them using simple resistor ladders) have common resolution ranging usually from 8bit to 24bit in most consumer hardware.
Resolution of +/- 500g just means there's not enough "steps" values in your ADCs provided bit depth: for example the 10bits on an attiny85 gives you 1024 discreet values you can map to weight values etc.
not claiming kotlin invented anything, just that after kotlin adopts something and it turns out to be useful, java will come along in a few years and implement it (or avoid it, depending on how it goes)
I still recall when java first came out, its all relative--but sure, a decade can seem like eons in software.
I'm honestly happy with java lang's stewardship over the past decade, this particular JEP notwithstanding (it's fine, but the good parts come later.) They're conservative in adopting new features whereas I see every other language bolting on everything under the sun with reckless abandon. I prefer the "let's see what shakes out" and adopt "the good parts" which seems to be Java's approach. Sugar like "var" from kotlin, project loom event loop like nodes, etc.
They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that.
That said, we've been gnawing on this limb for a while...
Am I understanding this correctly: a value type really only works when it fits on a 64 bit "cache line", and when larger, it falls back to normal heap allocated objects as before? Seems extremely limiting, no? Great for a boxing optimization, but not much else unless you're deal with very small data types regularly...
Reminds me of my teenage years when I'd echo spooky messages to other folks /dev/pttys to freak them out (messages i sent just magically appeared in their open terminals)
Why they didn't lock those down by using different creds per client in the computer lab I still don't know. Maybe it was a VAX limitation (at the time)?
I don't hate it. Covers all the bases: 1.1, 2, 3/quic and solves real problems: get query limitations vs body content & post-without-mutation. Yes there are preexisting workarounds, but they're non-obvious.
I switched to a nxtpaper pro phone which has a hardware switch for bw vs color modes and an e-ink like display (not as good but close enough)
I love it, mostly because it forces me to use phone less..
Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.
Without -x though it works as originally described.
Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL
I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...
Tmux is n clients to 1 server.
Screen is 1 server to 1 client.
In screen each client session is a fork of the screen server. In tmux there's one server and many client forks iirc.