| 5 Nov 2024 |
|  olivia changed their display name from benjamin to olivia. | 01:45:18 |
|  robbystk joined the room. | 13:17:23 |
|  @stejcon:matrix.org joined the room. | 13:53:15 |
 samrose | In reply to @ljubitje:matrix.org
Oh okay. Where can I see a package's progress to being available on my machine? I naively thought hydra builds it and it's done. I first got into nix and nixos around 2017. I've tried many strategies over the years. But if I could go back in time to communicate with my old self, I would tell myself that if I identified right away that just being able to use what is released in nixpkgs on any branch, that it would be worth a bit of time to learn how to just package the version I need and use it in my nixos machine or packages. | 16:23:59 |
 Jez (he/him) ♾️ | @ljubitje:matrix.org also if there is a PR in nixpkgs for the package you want, this will show you its progress through the various channels: https://nixpk.gs/pr-tracker.html
| 16:34:38 |
 LEGO® Worm™ | Spent like 3 hours trying to build my system with whatever Nix I could and I was going to ask how would I tackle the deadlock bug if I already got the cursed Lix and now I remember generations are a thing | 21:18:20 |
| LEGO® Worm™ | The human mind is truly complex 🥴 | 21:18:30 |
| 6 Nov 2024 |
 Charles | this is kind of a weird question but would anyone mind if i used (a subset of) the room state of #space:lix.systems (the space) as test data for a matrix state resolution algorithm? that room (spaces are rooms) hits an interesting edge case. i figure it's probably fine since the data is public, but i thought i'd ask anyway to be sure | 08:44:32 |
| Charles | ftr, i was able to anonymize user IDs, room IDs, server names, display names, and avatars, the only things that survived the anonymization process were event IDs (too much of a hassle to change lol) and origin_server_ts values (important for this edge case) | 09:10:54 |
|  seapat joined the room. | 13:50:24 |
 oz | if you end up rebuilding flakes ground up you should call the new thing sprinkles | 16:24:30 |
| oz | unrelated: are there any administrative or infrastructure tasks that this project needs help with? I would like to help if feasible | 16:58:51 |
| Charles | In reply to @ozmodeuz:matrix.org
if you end up rebuilding flakes ground up you should call the new thing sprinkles i've been saying this too lol | 17:41:16 |
 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 |
