Comments URL: https://news.ycombinator.com/item?id=43291128

Points: 2

# Comments: 1

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

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

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

Comments URL: https://news.ycombinator.com/item?id=31494042

Points: 16

# Comments: 3

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.

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.

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.

We will provide a new backend for the Storage Foundation API when it's available.