| 20 Nov 2025 |
 maralorn | I removed the one for builds again after popular demand. | 08:10:35 |
| maralorn | Because it was bad. | 08:11:17 |
| maralorn | I could add one for the total. Will consider that. | 08:12:01 |
| maralorn | Maybe I just should have used a proper uri parsing library. | 09:18:08 |
 Emma [it/its] | multicolor progress bar 👀 | 13:29:07 |
| Emma [it/its] | (completed vs running) | 13:29:52 |
| 21 Nov 2025 |
|  jasper @ 39c3 ☎️ 62749 joined the room. | 17:03:08 |
|  isabel changed their profile picture. | 18:14:39 |
| 23 Nov 2025 |
|  dave :3 set a profile picture. | 16:52:39 |
| 24 Nov 2025 |
| Emma [it/its] | i wonder if this is a reasonable way to detect finished builds as fallback? | 17:20:29 |
| Emma [it/its] | 
Download clipboard.png | 17:20:29 |
| Emma [it/its] | because i'd assume that nix builds dont start running until all of their inputs are finished? | 17:20:53 |
| maralorn | Is this on nom main? | 17:23:18 |
| Emma [it/its] | thats on my server, so no | 17:23:34 |
| maralorn | Ah, okay. Then this is probably already fixed. | 17:23:50 |
| Emma [it/its] | ah | 17:23:55 |
| maralorn | I mean it’s not perfect on main, but definitely different. | 17:24:15 |
| maralorn | But yeah, we could of course use that heuristic. However I’d prefer to have a correct logic instead of paving over the occurences where the user can tell that something is afoot. | 17:25:29 |
 vivekanandan_ks | Oh. I'm using unstable channel. Still not seeing it when I run the nh commands.
🤔Maybe not upstreamed yet in nh?
Btw where the progress bar will be shown?
| 17:52:42 |
 K900 | It's not in a stable release yet | 17:53:24 |
| maralorn | vivekanandan_ks: Currently we have one progress bar per transfer right aligned in the tree-row of a transfer. | 17:55:14 |
| maralorn | But I am currently also thinking about having one colored global progress bar in the last line which cumulates all builds and transfers. | 17:56:02 |
| vivekanandan_ks | This actually sounds great. Looking forward to it🤩 | 17:57:37 |
| maralorn | Me too. Wonder if I can find a free evening for that this year … | 18:01:36 |
| 26 Nov 2025 |
 saygo.2 | The problem with optparse applicative is that forwardOptions like all other info modifiers can only be applied to the whole parser | 04:24:30 |
| saygo.2 | this causes all unparsed arguments to be treated as positionals — which is good for the nix build etc wrappers, but terrible for normal nom | 04:25:15 |
| saygo.2 | I think it might actually be the cleanest to still parse the subcommands manually and only use optparse for nom | 04:26:02 |
| saygo.2 | I could make optparse applicative work for all but then we would have to use nix build -- <nix-args> | 04:33:12 |
| saygo.2 | since after -- all args are treated as posistionals anyway so i no longer have to use forwardOptions globally | 04:33:39 |
| saygo.2 | * I could make optparse applicative work for all but then we would have to use nix build -- <nix-args> which defeats the point of a drop in wrapper | 04:35:08 |
