3,665 karma · joined December 28, 2019
My pet theory is something like, my brain's dials for "avoid risk" and "recognize patterns" are turned up too high. So I breezed through a software engineering degree without ever partying, but I spend a lot of my time sitting in my house unable to motivate myself to go outside, and I'm not very empathetic (other people's words) and not very outgoing.
It's not that schizophrenia makes you smart, but that "smart" and "schizophrenic" are both functions of some high-dimensional space, and the same underlying differences can easily cause both.
On the other side, I have an elder relative who has paranoid schizophrenia and below normal IQ. Us in the tech industry are definitely going to get survivor bias from the "Beautiful Mind" cases around us.
And of course sometimes you meet those people who are smart, beautiful, rich, and friendly, with no downsides, and all you can think is ... "You son of a bitch" :P
Qt opens GUI windows and sockets and such. libusb touches USB devices. OpenCV can capture video frames from a camera and sometimes use GPU acceleration. Sqlite manipulates files on disk.
So unfortunately with wasm in a sandbox, the easiest libraries to work with are only pure functions. ffmpeg would work, but HW encoding or decoding would be difficult, and I need to either enable some file system access in the wasm runtime or feed it file chunks on demand.
(I think there is a limit on microcode, they seem conservative to release new ones - I don't remember the details)
It's probably a common skill in presenting, on radio / DJing they call it "hitting the post" https://en.wikipedia.org/wiki/Glossary_of_broadcasting_terms...
(It's not the lens - That's a pet peeve of mine, it's not the lens. The z-divide in any graphics simulation is what appears to compress or expand depth. The lens merely makes a shorter or farther camera distance practical. The lens themselves don't distort anything until you're talking about fisheye effects.)
There was resentment yes, but I did trust them!
Then it's vulnerable to malicious buyers putting in fake bids. There is probably a good reason this hasn't been implemented.
The only problem I see otherwise is that it's not a progressive tax - 5% of a trailer is much more of a poor person's income than 5% of a mansion is of a rich person's. But for that you can use UBI or something to make any flat tax net-progressive.
Like when a company says they're making some change to "improve service" or whatever but it's actually making service worse for some people
It's not gonna happen this decade, but it'd be nifty.
Before you start designing, look at what you have and ask why it doesn't already work. Those answers become manual test cases. Then get it into a test environment immediately, not after more than a day of coding. Every day make the test environment more like production. Run the whole cycle every time, build, release, test, otherwise one of the phases will go astray when you aren't exercising it.
I know Kanban is something different but these are all "Don't push from the start of the pipe, pull from the end of the pipe" approaches. It also works with media encoding and decoding. If you push, the buffers fill up and you have to figure out where to stuff packets when the codecs tell you they're full. If you pull, you waste 1 cycle figuring out where to start, but then everything is smooth and just-in-time.
It's all the same crap. It's Lean, too. There must be 20 names for this concept.
And I vetoed early return with a link to the article on railroad error handling. I don't know how it looks in C, but in C++ and Rust early returns are so much better.
In all my use of Tokio in the last few years, I never heard of such a thing.
In tokio::fs::File [1] it calls spawn_mandatory_blocking to do file writes, I assume this is similar to spawn_blocking [2] which sends a task to Tokio's blocking thread pool. That thread pool is supposed to max out at 512 blocking threads [3], unrelated to CPU core count.
Tokio's TcpStream appears to be built on mio's TcpStream. I didn't dig deep into the code for this, but it doesn't just call spawn_blocking, and I'm assuming on Unix it ultimately registers the socket with epoll or equivalent, so it never blocks a thread to do socket reads or writes.
Could you share more about your application?
[1] https://docs.rs/tokio/latest/src/tokio/fs/file.rs.html#682
[2] https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...
[3] https://docs.rs/tokio/latest/tokio/runtime/struct.Builder.ht...
I never thought about it but, my only problem with C's manual destructors is that the compiler doesn't check that you remember to call them. If we accept a language like Rust that does sophisticated static analysis, it doesn't need to delete things for you, it only needs to be sure you have a plan to delete everything.
That's interesting.