| 6 Nov 2024 |
 lexi | are there any plans to make builtins.addErrorContext a bit better? this one has been messing around with it a bit to at least make errors a bit more readable, and has had moderate success but only with ugly ugly hacks that should rather be a language feature. especially the fact that it isn't recursive (or at least not an option to make it recursive) is pretty annoying. for example, (builtins.addErrorContext "context" { abc.def = throw "oops"; }).abc.def just does not print any context. this can more or less be worked around inside the language, but it's quite annoying, and it also has the huge downside that while making it more readable with the context, it makes it less readable by adding unnecessary noise into the stack trace, especially when using a wrapper around addErrorContext (to make it recursive for example). it would be very useful in some cases to remove the next/previous N stack frames from the trace sometimes, and doing that without actual language support is extremely hacky. this could probably be implemented completely backwards-compatible with just string prefixes like builtins.trace "-2,+2,rec (actual context here)" as "remove two stack frames in each direction and make it recursive". would someone more experienced in C++ be interested in potentially implementing something like that? | 22:43:33 |
| lexi | * are there any plans to make builtins.addErrorContext a bit better? this one has been messing around with it a bit to at least make errors a bit more readable, and has had moderate success but only with ugly ugly hacks that should rather be a language feature. especially the fact that it isn't recursive (or at least not an option to make it recursive) is pretty annoying. for example, (builtins.addErrorContext "context" { abc.def = throw "oops"; }).abc.def just does not print any context. this can more or less be worked around inside the language, but it's quite annoying, and it also has the huge downside that while making it more readable with the context, it makes it less readable by adding unnecessary noise into the stack trace, especially when using a wrapper around addErrorContext (to make it recursive for example). it would be very useful in some cases to remove the next/previous N stack frames from the trace sometimes, and doing that without actual language support is extremely hacky. this could probably be implemented completely backwards-compatible with just string prefixes like builtins.addErrorContext "-2,+2,rec (actual context here)" as "remove two stack frames in each direction and make it recursive". would someone more experienced in C++ be interested in potentially implementing something like that? | 22:45:47 |
| 7 Nov 2024 |
 piegames | In reply to @lexi:kescher.at
are there any plans to make builtins.addErrorContext a bit better? this one has been messing around with it a bit to at least make errors a bit more readable, and has had moderate success but only with ugly ugly hacks that should rather be a language feature. especially the fact that it isn't recursive (or at least not an option to make it recursive) is pretty annoying. for example, (builtins.addErrorContext "context" { abc.def = throw "oops"; }).abc.def just does not print any context. this can more or less be worked around inside the language, but it's quite annoying, and it also has the huge downside that while making it more readable with the context, it makes it less readable by adding unnecessary noise into the stack trace, especially when using a wrapper around addErrorContext (to make it recursive for example). it would be very useful in some cases to remove the next/previous N stack frames from the trace sometimes, and doing that without actual language support is extremely hacky. this could probably be implemented completely backwards-compatible with just string prefixes like builtins.addErrorContext "-2,+2,rec (actual context here)" as "remove two stack frames in each direction and make it recursive". would someone more experienced in C++ be interested in potentially implementing something like that? Possibly, but this probably needs some more design work first | 00:01:04 |
 hexa | can we have https://github.com/NixOS/nix/pull/9280 in lix? | 00:28:43 |
| hexa | asking for om-nom-nom | 00:28:55 |
 ma27 | ohhh does this fix the reporting in nom when doing remote builds? :o | 09:38:26 |
 V. 🏳️⚧️ | Now that the static build works, can we get binary releases? | 09:56:53 |
 KFears (annoying) | Vaguely related q: how long have static builds been broken for? | 10:02:24 |
| KFears (annoying) | Maybe there's space for improving installer since we have static builds now | 10:02:45 |
 K900 | I do wonder if we can/should just do non-NixOS installs by just dropping a static binary somewhere yeah | 10:04:05 |
| KFears (annoying) | Btw, assuming we want to install static binary into the Nix store, there are no runtime dependencies right? Just the CA certs? | 10:06:38 |
| KFears (annoying) | (I do think dropping a static binary somewhere is a much better approach than using Nix store for this btw) | 10:07:15 |
| KFears (annoying) | That would also make upgrading extremely smooth | 10:07:54 |
| KFears (annoying) | Like, the whole upgrade procedure would just come down to replacing the binary with a newer version | 10:08:27 |
 Atemu | Lix is more than a single binary | 10:09:39 |
| Atemu | You need integrations with the system such as users, groups and shell hooks | 10:10:00 |
| Atemu | And the nix-daemon if course | 10:10:14 |
| Atemu | And even mounting the Nix store on some systems | 10:11:12 |
| V. 🏳️⚧️ | Yeah but point is, it is dramatically simpler | 10:11:28 |
| KFears (annoying) | Yeah, I might have given off the wrong impression, I don't try to say that we'll be able to drop installer and just distribute ready-to-go binaries, nuh-uh | 10:12:03 |
| KFears (annoying) | We'll still need the installer | 10:12:09 |
| KFears (annoying) | But the part that handles installing the package will be so much simpler, it's very nice | 10:12:58 |
| K900 | In reply to @atemu12:matrix.org
Lix is more than a single binary Yes, but upgrading a single binary is a lot easier | 10:14:37 |
| KFears (annoying) | Currently, Lix installation part of the installer is straight up miserable, we bundle a tarball with like manually copied Nix store paths with Lix, glibc, aws-sdk-cpp, curl and so much more | 10:15:17 |
| KFears (annoying) | And we like do a whole backflip to set up Lix to manage itself with those store paths, which means we hard depend on nix upgrade-nix or doing even more crimes to upgrade Lix using the installer | 10:16:08 |
| KFears (annoying) | And the alternative (which has a submitted CL) is basically re-implementing parts of the substitution process in Rust by hand ("parts" because doing the whole thing is miserable) | 10:17:20 |
| KFears (annoying) | And it's like a +800 LoC diff | 10:17:32 |
