 | Nix Hackers | 983 Members |
| For people hacking on the Nix package manager itself | 208 Servers |
| Nix Hackers | 983 Members |
| For people hacking on the Nix package manager itself | 208 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Sep 2021 | ||
 mkg20001 joined the room. | 00:10:47 | |
| 19 Sep 2021 | ||
 Las | Does anyone know if any of the builtins.unsafe* functions are actually unsafe? | 16:00:39 |
| Las | Can you misuse them such that some property of Nix is broken? | 16:00:51 |
 Alyssa Ross | I believe so | 16:02:06 |
| Alyssa Ross | for example, with unsafeDiscardStringContext you can break the dependency calculation | 16:02:30 |
| Las | But does that result in anything other than a borked package? | 16:05:01 |
| Las | * But does that result in anything other than a borked output/derivation? | 16:05:06 |
| Las | * But can that result in anything other than a borked output/derivation? | 16:05:12 |
| Las | Could it e.g. be unsafe from a security perspective? | 16:05:39 |
| Alyssa Ross | I don't think so, but nobody said unsafe meant insecure | 16:25:06 |
| Las | Generally in Haskell and Rust, unsafe means that it can break the system. | 16:51:41 |
| Las | i.e. you have no guarantees about the behavior if you pass in something wrong | 16:51:57 |
| Las | * i.e. you have no guarantees about the behavior if you pass in something wrong. | 16:51:59 |
 tomberek | Is the latest rendered docs (on master after 49a932fb18add471feefc469fb45fc44313bd5c6) hard to read for anyone else? Lowdown seems to try to highlight things, but most terminals I've tried this in make it more difficult to read. | 17:25:20 |
| tomberek | It is rendering the markdown with these codes:printf "\u001b[1;47;92m Testing \u001b[0m" | 17:44:20 |
 sterni | In reply to @Las:matrix.orgwell it is a guarantee nix gives you usually that every referenced store path in a derivation output also has to exist for example | 18:55:01 |
| Las | Is that really guaranteed? | 18:55:58 |
| sterni | as long as the referenced paths come from derivations | 18:58:30 |
 Robert Hensing (roberth) | or from sources (path values, filtersource, that kind of thing) | 18:59:05 |
 Kha | Boost coroutines have led to some GC issues (all fixed now though?) and are an issue on Cygwin. Has anyone thought about replacing them with C++20 coroutines? It might be too early to mandate C++20 support, but perhaps it would be worth supporting both impls for some time... | 21:16:06 |
| Robert Hensing (roberth) | Kha: getting boehmgc and any kind of coroutines to play nice together is non-trivial. At least the boost coroutines expose some implementation details that allow us to inform boehmgc properly (although the way we do it isn't optimal yet). Any coroutine implementation will confuse boehmgc because it doesn't handle on its own the case where the stack pointer isn't in any known thread stacks. C++20 coroutines do not seem to have an allocator parameter or anything similar that would allow us to pass this info to the gc. I haven't delved deeply into this, but from the information I could find, no such interface exists | 21:52:00 |
| Robert Hensing (roberth) | any coroutine integration will have to solve two problems: 1. making boehmgc accept the 'weird' stack pointers; 2. making sure the coroutine stack gets scanned by the gc. The current integration uses independent solutions for both, which is not optimal. A C++20 implementation has to solve both problems too | 21:54:33 |
| Robert Hensing (roberth) | there might be a way in which Nix could be refactored so that we only need to scan the evaluator's stack, so that we can configure boehm to scan only that stack. This would require a significant amount of communication between threads and an entirely new interface for working with this isolated evaluator. Such an interface would actually be useful for tracking Value provenance in a few locations where this is currently lacking, which improves error messages, but that's another topic I guess. Point is, with this much thread synchronization, it's easier and probably faster to just use threads instead of coroutines in the first place | 22:07:02 |
| Robert Hensing (roberth) | coroutines are only used for working with streams in a synchronous style. In some cases this can be replaced by code that written in an async style. I'm not sure if we even have interactions with synchronous style libraries. | 22:09:41 |
| 20 Sep 2021 | ||
 Rev. CornWallace III (novus ordo seclorum) changed their display name from CornWallace to Rev. CornWallace III. | 06:45:07 | |
| tomberek | While interacting directly with the nix-daemon I noticed that the response to exceptions/errors are sent to the client twice. Is this expected? This is a wopIsValidPath. daemon.cc looks like it sends STDERR_ERROR for the operation, and then sends another in the try-catch for the connection. | 06:54:33 |
 NinjaTrappeur joined the room. | 09:25:17 | |
 Eelco 😴 changed their display name from Eelco Dolstra to Eelco 😴. | 11:26:41 | |
| Kha | In reply to @roberthensing:matrix.org Ah, but that's the thing: C++20 coroutines are specified to be stackless: "they suspend execution by returning to the caller and the data that is required to resume execution is stored separately from the stack" Custom allocation can be done via a custom https://en.cppreference.com/w/cpp/language/coroutines | 12:19:39 |
| Robert Hensing (roberth) | does that guarantee that the stack pointer remains in the thread stack region? | 12:22:32 |