| 22 Nov 2024 |
 Picnoir | Right | 20:40:43 |
 maralorn | In my mind memo basically converts "a -> b" into something like "Map a b" where the b part is lazy and all possible keys a are in the map, so that lookup again has the signature a -> b. | 20:41:19 |
| Picnoir | Worst case scenario, if I don't manage to understand how this thing works, I can rewrite this part memoization part in a more dumb-dumb explicit way. | 20:41:30 |
| Picnoir | Or let you write this part :P | 20:42:09 |
| maralorn | Yeah, I am sure we can do it together. | 20:42:30 |
| maralorn | In reply to @maralorn:maralorn.de
In my mind memo basically converts "a -> b" into something like "Map a b" where the b part is lazy and all possible keys a are in the map, so that lookup again has the signature a -> b. This would be relatively easy to write down if it weren’t for the fact that Map a b is spine strict so all a actually exist in memory. That’s why that lib has another Map a b like datastructure which tries to force as little keys as possible on lookup. | 20:44:46 |
| maralorn | At least that’s my understanding. | 20:45:07 |
| Picnoir | Alright, doesn't seem so hard in the end. | 21:03:05 |
| Picnoir | Do you have a way to test that? | 21:03:09 |
| Picnoir | Reworked the stdin buffering set/release. | 21:03:29 |
| Picnoir | I might not have as much computer time as I originally planned this weekend in the end. But that's no a big deal, I'll have pleinty spare time next week :) 👋 | 21:04:12 |
| maralorn | In reply to @picnoir:alternativebit.fr
Do you have a way to test that? I have one benchmark and we can see if it got worse, but it is not super automated. | 21:05:52 |
| 24 Nov 2024 |
|  WeetHet joined the room. | 11:46:15 |
| 25 Nov 2024 |
|  @nullcube:matrix.org joined the room. | 10:04:53 |
|  luxus joined the room. | 18:06:43 |
| 26 Nov 2024 |
| Picnoir | Ok, I spent a little bit more time digging into this memoization issue yesterday. I sadly still don't understand how we're bursting it. The print state TMVar is not updated unless we had a user interaction, in which case it'd mean we do have to compute writeStateToScreen again. | 08:48:30 |
| Picnoir | I'm maybe missing the point. | 08:48:44 |
| Picnoir | We already have the whole STM machinery, I think we could rewrite this memoization mechanism explicitely using STM values. We could be racing two async threads waiting for some nix/user interaction and recomputing writeStateToScreen only after we got something new to compute. | 08:50:43 |
| Picnoir | It'd probably make things easier to grasp for people like me. | 08:50:58 |
| Picnoir | * We already have the whole STM machinery, I think we could rewrite this memoization mechanism explicitely using STM values. We could be racing two async threads waiting for some nix/user interaction and recomputing writeStateToScreen only after we got something new to compute. It'd probablly make it harder to screw up the memoization by accident. | 08:52:45 |
| 27 Nov 2024 |
|  @thedragon44:matrix.org left the room. | 23:33:11 |
| 1 Dec 2024 |
|  shawn8901 joined the room. | 00:10:56 |
| maralorn | Picnoir: Sorry for not coming back to you earlier on this. | 21:26:48 |
| maralorn | My idea was this: writeStateToScreen does get called at least once per second with a new time stamp. | 21:28:19 |
| maralorn | And I want minimal recomputation when that happens. | 21:29:29 |
| maralorn | That being said: If we cache the application of stateToText to the printState we should be fine. | 21:33:17 |
| maralorn | Although this could also just be a premature optmisation because it basically only kicks in once per second, which is probably not at all the hot loop … | 21:45:00 |
