The problem is "for each pixel inside the area". I could have done that, and then clipped the output by that shape. The problem is this doesn't answer why the shape is this way at all because you are using the shape itself to clip the output. It felt fake.
Yeah that article is better. I'm the author and I wrote this only for me as I studied it, it's not great as a way to describe it to others
I wanted to start from the very beginning and as far as I know Lab and OKLab didn't come later. Studying the 1931 studies and such was a start, and I wanted to later bring up all the other things we've learned since then, but haven't had time to write more about it
but you're right, the intensity needed of each R, G, and B light sources to produce the correct color is directly related to how our eyes perceive each of those sources, so yes you are correct
Hey! I'm James, the original creator. Yeah, I tried to stay involved but over time I had to accept that my life right now just doesn't allow time to be very involved. We've had some incredible maintainers step up and their doing an amazing job stewarding the project along.
I'm long-overdue to check in with the maintainers and write some content about the transition. I was also intending to shutdown the hosted version late summer and hand over actualbdget.com to the open-source community. My goal is to do this by end of year.
Overall, I wish my life weren't so busy in some ways, but it's busy with really good and fulfilling things. The transition was a little rough for me (hard to give control away of something I worked so hard on) but it's turned out surprisingly good
Native apps were open-sourced yes in the repo, but the community moved them out into their own repos and archived them. Hard to build native apps open-source with all the tooling, and the community has been working on replacing them with a webapp
What's shutting down is the public syncing server. That server is literally just a message store: it takes CRDT changes and puts them in a big table. And it servers them back out.
Now that the server is public, it's incredibly easy for you to run your own. It's such a simple server (no postgres etc requirement) that this model is actually way better.
I launched around 3 years ago, and it was brutally slow. I think it took a year to hit 100 subscribers.
Another year to hit 300.
This past fall, YNAB increased their prices which gave me decent jump from around 500 to 800 subscribers which is where I'm at today.
I did everything wrong when it comes to marketing and getting subscribers. I focused on the tech and never invested in content, building hype, etc. Well, I take that back -- sometimes I did, but only 10% instead of 70% like I should have been doing.
Yes I totally regret it. There are ethical VCs that would be willing to invest a small amount and I should have done that. Bootstrapping isn't all it's cracked up to be; there are a lot better and smarter ways to kickstart a project.
If the community want to wait, I'm happy to push back the date.
I actually thought it felt less greedy to not wait too long, because doing it in the far future just means people are paying for unsupported software. Happy to keep it running though for as long as people want.
> Does this mean the main (UI) thread is blocked during queries? Or are there more threads, like UI <- async messages -> SQLite main <- Atomics blocking -> SQLite FS backend?
The latter! Your app running queries must be on a worker, and then the IDB backend will spawn another worker. `Atomics.wait` is not even available on the main thread.
Ideally in the future, there will be a better storage API that we don't even need all the Atomics silly-ness (hopefully it provides Sync methods)
That's really cool re: Notion! That's exactly the kind of thing I want too: a way to just build apps the same way everywhere, on mobile/desktop/web.
You are right about various issues, and I personally don't have to worry much about it on my app because I have native mobile apps and I don't support the web version on mobile. I intentionally do that -- the mobile web is just too broken in too many ways. My impression is the IDB is more stable on desktop, but because mobile is more memory sensitive there are more issues there.
However, you should try it out! I definitely discovered a lot of weird things; I definitely was able to get Safari into a weird state the required a complete app restart. Here's the thing though: I found ways around them. If you do a lot of read requests in a certain way, Safari will lock up permanently. However, if you make sure to wait until the `readonly` transaction is finished before starting a new one, the problem goes away. I was able to reliably reproduce that problem and it went away with that fix.
I think absurd-sql is so promising because it normalizes the patterns of how IDB is accessed, and it already includes fixes for a bunch of edge cases. There are probably more, but try it out! If you run into an edge case, we can tweak the IDB backend until it works. We can paper over these issues in the underlying backend and you don't have to worry about it because you aren't directly managing IDB read/writes.
I was profiling on an older computer. On my newer one, summing 100 items takes ~8ms (use the raw idb mode). When I said "simple operations" I meant simple queries that you'd expect apps to write, not just 1 single read/write. It is a little faster for each read/write, but there seems to be a bottom floor. Even if reading an item itself is fast, opening a transaction is slow. So any query, even if it only reads one item, is going to suffer the perf hit of opening a transaction.
It's only twice as fast as Firefox, so overall IDB is still super slow when compared to running the same queries with native SQLite. We're talking summing 100 items taking ~.01ms or less. I have no idea why it's so slow.
Did you read the post? This project does exactly that. (but focuses in IndexedDB for now because it's the only cross-browser thing that works. I actually tried a webkitFileSystem backend and it was slower)
The problem is "for each pixel inside the area". I could have done that, and then clipped the output by that shape. The problem is this doesn't answer why the shape is this way at all because you are using the shape itself to clip the output. It felt fake.
I do think this is what is most common though. I was trying to understand a more rigorous approach, and the one where you generate spectra and try to fill it is described here: https://clarkvision.com/articles/color-cie-chromaticity-and-...
That feels like a more rigorous approach, but clipping is probably "good enough" too