| 19 Sep 2021 |
 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.org
i.e. you have no guarantees about the behavior if you pass in something wrong. well 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.
00000000: 6378 696e 0000 0000 0a01 0000 0000 0000 cxin............
00000010: 0000 0000 0000 0000 0100 0000 0000 0000 ................
00000020: 3500 0000 0000 0000 2f6e 692f 7374 6f72 5......./ni/stor
00000030: 652f 7a79 3962 636e 7932 3270 7931 3776 e/zy9bcny22py17v
00000040: 3037 3130 6339 7276 3269 6239 6a78 6136 0710c9rv2ib9jxa6
00000050: 7076 2d73 6f75 7263 652e 6472 7600 0000 pv-source.drv...
00000000: 6f69 7864 0000 0000 2001 0000 0000 0000 oixd.... .......
00000010: 7374 6c61 0000 0000 7074 7863 0000 0000 stla....ptxc....
00000020: 7100 0000 0000 0000 1b5b 3331 3b31 6d65 q........[31;1me
00000030: 7272 6f72 3a1b 5b30 6d20 7061 7468 2027 rror:.[0m path '
00000040: 1b5b 3335 3b31 6d2f 6e69 2f73 746f 7265 .[35;1m/ni/store
00000050: 2f7a 7939 6263 6e79 3232 7079 3137 7630 /zy9bcny22py17v0
00000060: 3731 3063 3972 7632 6962 396a 7861 3670 710c9rv2ib9jxa6p
00000070: 762d 736f 7572 6365 2e64 7276 1b5b 306d v-source.drv.[0m
00000080: 2720 6973 206e 6f74 2069 6e20 7468 6520 ' is not in the
00000090: 4e69 7820 7374 6f72 6500 0000 0000 0000 Nix store.......
000000a0: 0100 0000 0000 0000 7074 7863 0000 0000 ........ptxc....
000000b0: 7100 0000 0000 0000 1b5b 3331 3b31 6d65 q........[31;1me
000000c0: 7272 6f72 3a1b 5b30 6d20 7061 7468 2027 rror:.[0m path '
000000d0: 1b5b 3335 3b31 6d2f 6e69 2f73 746f 7265 .[35;1m/ni/store
000000e0: 2f7a 7939 6263 6e79 3232 7079 3137 7630 /zy9bcny22py17v0
000000f0: 3731 3063 3972 7632 6962 396a 7861 3670 710c9rv2ib9jxa6p
00000100: 762d 736f 7572 6365 2e64 7276 1b5b 306d v-source.drv.[0m
00000110: 2720 6973 206e 6f74 2069 6e20 7468 6520 ' is not in the
00000120: 4e69 7820 7374 6f72 6500 0000 0000 0000 Nix store.......
00000130: 0100 0000 0000 0000 ........
| 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
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 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 Promise type or one that takes an explicit allocator
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 |
| Robert Hensing (roberth) | and if it does, it doesn't seem like this could call into arbitrary code, which does seem to be something we need to make the whole sink/source translation business work | 12:23:38 |
| Robert Hensing (roberth) | more specifically, that arbitrary code would not be capable of knowing how to yield | 12:24:48 |
| Robert Hensing (roberth) | (I mean any C++ code we wrote, not the security almost-term "arbitrary code") | 12:26:39 |
| Kha | Does Nix even use more than that single coroutine in serialise.cc, which does not have a nested yield? In any case, afaiui you cannot have directly yield from inside a nested call with these coroutines, but you can yield to the surrounding coroutine, which then yields to the caller/next coroutine, etc. | 12:34:20 |
| Kha | It's like Python before yield from | 12:34:31 |
| Kha | * Does Nix even use more than that single coroutine in serialise.cc, which does not have a nested yield? In any case, afaiui you cannot directly yield from inside a nested call with these coroutines, but you can yield to the surrounding coroutine, which then yields to the caller/next coroutine, etc. | 12:35:06 |
| Kha | There is absolutely no stack pointer manipulation with this approach | 12:35:38 |
| Rev. CornWallace III (novus ordo seclorum) changed their display name from Rev. CornWallace III to Rev. CornWallace III (tzu/tzi). | 15:22:23 |
| Rev. CornWallace III (novus ordo seclorum) changed their display name from Rev. CornWallace III (tzu/tzi) to Rev. CornWallace III (sun/tzu). | 15:24:44 |
| Robert Hensing (roberth) | Kha: I'm going to trust you on that | 15:29:53 |
| Robert Hensing (roberth) | A possible issue is that these coroutines are "viral" in the sense that any stack frame between coroutine start and yield must become part of the coroutine. Some of these are virtual method invocations and some might be calls into libraries we don't control (not sure) | 15:31:42 |
| Robert Hensing (roberth) | So those are possible challenges. I would really like for this to work and I suspect that C++20 may be a nicer requirement than boost_context, although I'm blissfully unaware of C++20 maturity | 15:33:08 |
