| 24 Nov 2025 |
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 |
saygo.2 | I'll try writing it so that we use the old way of parsing subcommands, but then ill still create the subcommands using optparse for the help pages to work well (and maybe autocompletion though i havent looked into that at all yet) | 04:36:13 |
saygo.2 | * I'll try writing it so that we use the current way of parsing subcommands, but then ill still create the subcommands using optparse for the help pages to work well (and maybe autocompletion though i havent looked into that at all yet) | 04:36:34 |
maralorn | The new build finished detection is apparently also fucked for ifd. | 16:59:45 |
maralorn | So I guess this is not good enough. | 16:59:53 |
| 1 Dec 2025 |
| Brisingr changed their display name from Brisingr05 to Brisingr. | 18:40:12 |
| 2 Dec 2025 |
saygo.2 |  Download image.png | 12:09:41 |
saygo.2 | is there a reason why nom-shell has a chmod command for it but nom-build doesnt? | 12:10:05 |
maralorn | Looks like a mistake to me. I am pretty sure that I wanted to give multiple files to the chmod call. | 12:19:07 |
saygo.2 |  Download image.png | 12:29:48 |
saygo.2 | i got most of the nom functionality working using optparse now | 12:30:02 |
saygo.2 | The only part that is left is now adding passthru completions for nom-build nom-shell and the nom subcommands | 12:31:38 |
saygo.2 | there is an issue for optparse that almost wants to achieve what we want to at https://github.com/pcapriotti/optparse-applicative/issues/372 | 12:32:27 |
saygo.2 | sadly as i understand the last 2 options are not applicable to us | 12:32:39 |
saygo.2 | so i'll just be changing the scripts | 12:32:55 |