| 25 Nov 2024 |
|  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 |
| 4 Dec 2024 |
| Picnoir | Yeah, builds are usually printing quite often anyways. | 09:31:40 |
| Picnoir | This PR start to scope creep on my end, started a refactoring to clear a bit writeStateToScreen and have a single tmvar blocking the printer until something new to print appears. | 09:32:23 |
| Picnoir | Let's remove this refactoring from this PR and get this merged first. | 09:32:36 |
| Picnoir | I'll make a quick hyperfine bench run to make sure I'm not breaking perf too much. | 09:34:38 |
| Picnoir | In reply to @picnoir:alternativebit.fr
Let's remove this refactoring from this PR and get this merged first. (I'll keep a few variables remame in the end, I don't think it'll add too much review burden) | 09:35:10 |
| maralorn | Picnoir: I appreciate all refactorings, but small PRs are definitely better.
The printing code is the part of the code base which I am least proud off. It became an ugly chimera because it is not very sensitive but changed probably the most.
| 10:05:37 |
| Picnoir | Yeah, definitely, I'm splitting to keep it small. | 10:12:02 |
| Picnoir | (implementing help and freeze atm, I'm almost done) | 10:12:16 |
| Picnoir | The freeze feature without a visual feedback is probably a footgun 😅 | 10:35:15 |
| Picnoir | Redacted or Malformed Event | 10:35:31 |
| maralorn | Bug report: "nix-output-monitor hangs when pressing f" 😄 | 10:42:08 |
| Picnoir | "maralorn assigned this issue to @picnoir" | 10:44:02 |
| Picnoir | :D | 10:44:03 |
| Picnoir | Alright, I think this is ready for review. | 10:49:28 |
| Picnoir | I keep the refactoring in my git stash for now. I'll push it once we're done with https://github.com/maralorn/nix-output-monitor/pull/162 | 10:49:50 |
| Picnoir | It do not seem like I did something very very stupid perf wise. | 10:50:15 |
| Picnoir | I'm not super sure about the help screen part, there's maybe a better way to do it. | 10:55:45 |
