I wouldn't recommend either. I bought into the ecosystem around 10 years ago because I had just gotten my first real job and wanted to treat myself to some nice stuff. I got the Play:5 and then the sound bar and subwoofer soon after.
Then, like two years later, everything I bought became 2nd class citizens. I have use Legacy apps that are just barely working. It sucks.
It was super cool when it all worked but if it took them this long to get rid of that CEO, then I don't seem them turning around at any point soon.
Same. It was my first CS class after transferring to NCSU in 2000. I was pretty lost at times but he was super kind and patient whenever I went to office hours. He was an older professor at that time and it was always cool to see was still teaching well beyond when I graduated.
Ditto, I took his discrete math course at NCSU in 1998. It was mainly taught by Tiffany Barnes day to day (who was also nice and a great explainer), but Bitzer was often present and always smiling and jovial.
I really regret having spent so little time interacting with my professors though. I was one of those kids that spent the least amount of time in class possible, almost never going to office hours, aiming to get the course work out of the way asap so I could "have a life". So much wisdom and life/industry experience was concentrated on that campus and at my fingertips, but I totally took it for granted. Seeing his obit amplifies this feeling; I wish I had cared enough at the time to meet and know the guy.
If I'm remembering correctly, I was using iTerm before Warp. I listened to some of the devs on the Changelog podcast and it seemed worth checking out.
At the time, iTerm was getting really heavy and slow for me and I was losing a day every few months tracking down the cause. Warp was immediately faster and prettier so I stuck with it. They're also super fast with updates and responsive on Github with issues.
I honestly don't use many of their features besides being able to ask the LLM for how to do something random in git and getting the answer without leaving the terminal. The way they organize each command+response into blocks is also cool for readability and copy/pasting.
I didn't know that about how IQ tests are formed.
Would that mean that there could be some sliver of the population that could score in the top %'s on the 1000 question test but due to the selection of questions, scored average on the final IQ exam?
If so, that'll be my excuse next time I have to take an IQ exam. I just got the wrong distribution.
What tool do you use for the source separation? Everything I've used so far is great for learning or transcribing to MIDI but the separated tracks always have a strange phasing sound to them. Are you doing something to clean that up before mixing back in or are the results already good enough?
I just dealt with a lot of sqlite concurrency stuff recently. When I first got started, a lot of recommendations were that apps should create a connection and hold that connection its the duration. This works great but I feel like it's worth noting that this can get dangerous when you're working in a multi-threaded context.
You can have one thread in the middle of stepping through the results of a SELECT prepared statement and if another thread resets the statement and runs it again, that original thread will start stepping through the results from the other thread's call. Or if both threads begin a transaction, you'll get nested transaction errors.
Things get really confusing, especially because you might not notice the problems until the app is running on a slower machine.
In my case, it's using default serialized mode. I would assume I was safe judging by "In serialized mode, API calls to affect or use any SQLite database connection or any object derived from such a database connection can be made safely from multiple threads"
But in the unit tests I have setup, it hasn't been the case, at least with prepared statements being shared between threads.
Yes that's exactly how it works in serialized build/mode.
Are you sure not ultimately compiling with -DSQLITE_THREADSAFE=0 or 2?
Also the serialized setting is distinct from the isolation level.
sqlite has a famously extensive test suite and is effectively one of the most heavily tested libraries ever, and there are multithread tests in the suite. If your tests are triggering some other kind of race/undefined behavior there is also that to consider.
Just for clarification, did you have one connection per thread or one global connection?
If it's the latter your error would make sense since you created a race condition, databases connections aren't magic, they are still just file descriptors without synchronisation, most ORMs/frameworks put the magic in there for you.
SQLite database connection objects are not "just file descriptors" and with the default serialization build they are appropriately locked to allow multi-threaded use. In that sense, they are magic.
I think we are talking past each other and see what you’re saying.
Also rereading the initial comment it is now obvious what is going on.
For some reason I thought they were claiming weird interactions between statement objects (which would occur if serialization was not used). It appears they are just sharing a single statement object between threads and expecting that to work.
I read past that because it never occurred someone working with the API would think that would work. It would imply some kind of thread local storage, and as you are aware that is definitely not something commonly done on APIs of this type.
> And there is no confusion about who owns what?
What you are describing is a higher level of race condition of course, but not one where the internal state of SQLite is inconsistent or breaking invariants. Specifically there is no confusion about ownership: there is one tx (stack) per connection and it is owned by the connection, to which access is serialized by the library.
In SQLite you implicitly open a transaction with any statement so it’s not necessarily a problem to be “starting a transaction” since the implicit start will be idempotent. And you can certainly use this behavior to run concurrent reads and writers across multiple threads on a single connection without issue.
Yes if you try to run multiple BEGIN statements that will error out. You’re right some ORMs do some fancy magic over a connection to serialize those. Sorry that was not the initial problem I was addressing (though obviously the GP had confusion in this area too)
I 100% would believe what you described in this comment is expected behaviour, it makes sense to me.
And yeah I was thinking about this a decent amount today and thought the only way you could even begin doing this is with thread local storage but could not think why they would do that concidering how widely supported (platform wise) sqlite is.
I think what you're describing is what I was confused about: sharing prepared statement objects across multiple threads.
It makes sense why it would not work but, at least in my case, it was an easy place to find myself when combining the "best practices" of prepared statements and a single shared connection.
Thanks for the clear interpretation of what's going on. Until now, it just seemed like a "gotcha." But I always knew it was user error and that sqlite was too battle tested for it to be a bug.
Beware that backend has plenty of those declarative frameworks also... Kubernetes, terraform, most CI environments, CMake. (I'd add SQL but since it's the only one that doesn't drive me crazy, I don't like to think of it as declarative)
I don't know FE development enough to speak on it but I agree with your sentiment in general. When I see "declarative," I think "learn by memorization and trial and error rather than reason and intuition."
It was super cool when it all worked but if it took them this long to get rid of that CEO, then I don't seem them turning around at any point soon.
reply