| 22 Nov 2024 |
 Picnoir | * Hehe, got it working without having to move things too much around in the end. The diff is pretty small. | 18:28:13 |
 maralorn | awesome! | 19:26:32 |
| maralorn | Maybe we want to strip the /nix/store prefix? | 19:27:00 |
| maralorn | I will definitely review this on the weekend. | 19:27:33 |
| Picnoir | In reply to @maralorn:maralorn.de
Maybe we want to strip the /nix/store prefix? I'd like to keep it, my use case is to copy/paste this string to a nix build call set with a remote builder :/ | 20:29:48 |
| Picnoir | Meh, nevermind, I can append that in my wrapper. Let's change that. | 20:30:19 |
| Picnoir | I fixed the update part. It's no longer waiting for a new nix line to come to display the derivation. | 20:31:03 |
| Picnoir | I have to confess I don't know how to fix the memoization issue rn. I have to figure out how this memoization thing is working. The documentation is terse and is pointing to dead links, rough start :D | 20:31:58 |
| Picnoir | * I have to confess I don't know how to fix the memoization issue rn. I have to figure out how this memoization thing is working. The documentation of the library is terse and is pointing to dead links, rough start :D | 20:32:06 |
| maralorn | In reply to @picnoir:alternativebit.fr
Meh, nevermind, I can append that in my wrapper. Let's change that. I guess I can live with both solutions. | 20:33:26 |
| maralorn | In reply to @picnoir:alternativebit.fr
I have to confess I don't know how to fix the memoization issue rn. I have to figure out how this memoization thing is working. The documentation of the library is terse and is pointing to dead links, rough start :D Yeah, it is a bit gnarly. | 20:33:55 |
| maralorn | I see about two solutions: 1. Only apply print state when the state itself changes. 2. memoize the Printstate. Both should be doable. | 20:34:44 |
| maralorn | * I see about two solutions: 1. Only apply new print state when the state itself changes. 2. memoize the Printstate. Both should be doable. | 20:34:58 |
| maralorn | i.e. its fine when a print state change invalidates memoisation, we just don’t want it reapplied everytime. | 20:35:50 |
| 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 |
