| 26 Nov 2024 |
 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 |
| maralorn | In reply to @picnoir:alternativebit.fr
I'm not super sure about the help screen part, there's maybe a better way to do it. Yeah, that part is problematic. It has been for now my iron rule that nom will not destroy the backlog of the build. So calling clearScreen is not something I want to do. | 10:57:33 |
| Picnoir | Right | 10:57:52 |
| Picnoir | Makes sense | 10:58:07 |
