You are viewing archived messages.
Go here to search the history.

Tom Larkworthy 🕰️ 2025-03-29 21:46:29

I am back to bug hunting. Reactive live coding is great when it works but the bugs can be devilishly difficult. The best methodology I have is plotting all the transitions on a timeseries and zooming RIGHT IN. Its a technique I keep coming back to and it has fixed quite a few subtle issues. I used to think the dependancy graph would be useful but actually a lot of the reactivity bugs occur via hidden event coupling occurring outside the programming model, for example, mouse events, url events, local storage events. They can cause different cells to trigger each other but not through the normal notification mechanisms.

🎥 debugging reactive.mp4

Tom Larkworthy 2025-04-01 17:27:10

Yeah I do think often "what are the rules of reactivity to avoid these situations?". I think one risky problem class is joining async streams via different paths, it often ends up double triggering the common one, in a non-deterministic way because of the async tasks in the middle, whereas in normal programming you would join with await Promise.all([task1, task2]) . In Rx this is a zip. Observable went for limited stream combine operators, but even in Rx world, if you zip and then accidentally go out of sync, you get a different type of reactivity bug, so zip is not really the correct answer either, coz there is nothing enforcing the streams are publishing at the same rate.

I look at Rust borrow checker and that it does some kind of resource counting in the type system, so that seems kinda like it might be the right path, but its not "easy", either to develop or for people to use. So I dunno. Its an outstanding problem with reactive systems: joining streams in a non-fragile way. When you visualize it at least the problem sometimes becomes apparent, and visualization also catches the unintended coupling that occurs as well in impure systems. So thats my best workable solution for now.

            Parent

           /     \

 async task1     async task2

            \   /

           common
Kartik Agaram 2025-04-05 06:28:02

I spent some time rethinking how color is represented in my browser. I want to prioritize accessibility over expression, so I switched to ~500 colors over a perceptually uniform color space. The idea is that you specify background colors completely, but if you leave wiggle room in the foreground colors the browser will search the wiggle room and try to maintain some minimum contrast level. Here's a test run where I randomize the background on every "page load", but the foreground colors are specified the same way: text is on a greyscale, and links are blue.

I used to think the CSS hotness of the Oklab space is rocket science. I still don't understand the why of it, but it turns out to only take 200 lines of code to implement.

🎥 luaML2-contrast.webm

Roma Komarov 2025-04-05 14:43:17

Colors are fun! With modern color functions there, you can also do a lot of that just in native CSS, like with relative color syntax here: lea.verou.me/blog/2024/contrast-color

📝 On compliance vs readability: Generating text colors with CSS • Lea Verou

Kartik Agaram 2025-04-05 15:43:14

Oh that's fascinating about the limitations of WCAG. I was noticing as well while playing with my program, wondering if I have a bug somewhere.

Elliot 2025-04-05 18:37:44

Thanks for sharing your Oklab code! Excited to come back to it later when doing color stuff