nix-output-monitor | 131 Members | |
| https://github.com/maralorn/nix-output-monitor | 46 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Jun 2026 | ||
| I'm getting something funny | 10:11:33 | |
| A lot of "runHandler: couldn't find handler" | 10:11:36 | |
| After a build ends | 10:11:39 | |
| I think those are coming from nom? | 10:11:46 | |
| So essentially the problem isn’t solved? | 10:33:45 | |
| Maybe have a screenshot? That sounds very weird. Maybe something to do with the inotify lib. | 10:34:23 | |
| looks like a bug with hinotify in fact, it has this in the source:
| 10:47:26 | |
| The 'impossible' has happened | 10:48:24 | |
| It was, and then it wasn't | 11:01:41 | |
| I am not sure what changed during | 11:02:04 | |
| Maybe a difference between fsnotify and hinotify? | 11:03:13 | |
| Oh, boy. Don’t tell me we have to bisect this. | 11:03:23 | |
| I believe what this means is simply that nom has exited the withWatch scope before all watches have been destroyed. Kinda something which something a borrow checker would prevent.^^ | 11:18:54 | |
| * I believe what this means is simply that nom has exited the withWatch scope before all watches have been destroyed. Kinda something which something like a borrow checker would prevent.^^ | 11:19:00 | |
| Oh, boy. This sucks. I even had nearly a complete and detailed lix issue written yesterday and then my computer shut down and I lost my input field. 🤦 | 11:20:02 | |
Do you mean fsnotify's withManager? The thread that runs runHandler is cancelled when the INotify/WatchManager leaves scope (https://github.com/haskell-fswatch/hinotify/blob/master/src/System/INotify.hsc), so I doubt that it's that. | 11:32:36 | |
| Okay, that was my speculation. | 11:37:06 | |
| Maybe it is not allowed to fork a thread within a withManager call? That is what I am doing. | 11:37:35 | |
Not being able to fork a thread at all would be strange, but maybe watchDir has to be called in the same thread. | 11:47:09 | |
| https://git.lix.systems/lix-project/lix/issues/1227 | 11:49:48 | |
| Also maralorn (this is Vasily), minor remark on Copilot in nom PRs: I remember you've mentioned earlier that you only plan to use it as a check to find trivial issues like typos etc in your own commits only, but I think even that might have a danger of discouraging others from reviewing already-Copilot-reviewed PRs. For example, it might give a false sense of security that things were already checked, or people might not want to read Copilot output in order to participate in the discussion of a PR without repeating things that were already mentioned. What about posting in this channel (or elsewhere) to get volunteers to review individual PRs on an ad-hoc basis instead? I don't think that it would take much for someone to provide a better review than Copilot: I doubt they'd even need to know Haskell, from looking at most of Copilot's comments so far. | 11:53:35 | |
| * Also maralorn (this is Vasily), minor remark on Copilot in nom PRs: I remember you've mentioned at Zurihac earlier that you only plan to use it as a check to find trivial issues like typos etc in your own commits only, but I think even that might have a danger of discouraging others from reviewing already-Copilot-reviewed PRs. For example, it might give a false sense of security that things were already checked, or people might not want to read Copilot output in order to participate in the discussion of a PR without repeating things that were already mentioned. What about posting in this channel (or elsewhere) to get volunteers to review individual PRs on an ad-hoc basis instead? I don't think that it would take much for someone to provide a better review than Copilot: I doubt they'd even need to know Haskell, from looking at most of Copilot's comments so far. | 11:56:14 | |
| I understand that the use of LLMs is very contentious. As I expressed to Leana I believe that using it for code review is much less problematic than for code gen. I personally regard it as completely additive and optional. However it provably finds issues which are more complex than simple typos which I overlooked myself. If this project becomes more than a single person project (which it kinda looks like right now), then this changes a lot of the parameters and is certainly up for debate. | 12:02:20 | |
| * I understand that the use of LLMs is very contentious. As I expressed to Leana I believe that using it for code review is much less problematic than for code gen. I personally regard it as completely additive and optional. However it provably finds issues which are more complex than simple typos which I overlooked myself. I see that a Copilot review might discourage others from reviewing my PRs. However as far as I remember I have never had a code review by anyone, so this argument wasn’t at the top of my mind. If this project becomes more than a single person project (which it kinda looks like right now), then this changes a lot of the parameters and is certainly up for debate. | 12:03:23 | |
| Having human feedback on my changes would of course be very luxirious. Developing nom can at times be kinda solitary and having more of a team feeling would be much nicer than anything llms can provide. If people tell me they wanna do code reviews, but only if I stop asking copilot then I’d be willing to do that. | 12:08:21 | |
| Ah, but I disagree on the Haskell knowledge part. I am quite certain that LLMs could detect some Haskell specific bugs which would be hard to find for someone without any experience with the language. | 12:18:41 | |
| With regards to getting people to do code reviews: I think just posting something along the lines of "I have this PR here that fixes A and B, is anyone available to briefly review the code?" and leaving it open for a while should work well enough. | 12:20:47 | |
| Yeah, sure. Let’s try that. | 12:23:21 | |
| still broken for me too yesterday building into nixos tests on master | 13:30:19 | |
| Maybe I am just completely misdiagnosing the problem … Maybe this has nothing to do with the store paths not appearing in time but instead some completely different problem | 13:52:28 | |