| 10 Nov 2024 |
 emily | do we have conversions for when new std::filesystem::path-using code has to talk to Path-land, or should I just port any Path stuff I touch? | 03:28:12 |
|  Peter Hansson joined the room. | 10:04:43 |
|  ChrisOboe removed their profile picture. | 11:56:32 |
 Mic92 | In reply to @emilazy:matrix.org
do we have conversions for when new std::filesystem::path-using code has to talk to Path-land, or should I just port any Path stuff I touch? I noticed that many std::filesystem::path exception do not provide the most readable error messages and they also do not support these error traces, we are using, so I think we maybe should re-wrap those and throw nix's own exception class in most cases. I think for the most part we want to at least migrate away from path concatenation, this is the most annoying part that breaks things in the windows port. | 17:12:11 |
| Mic92 | In reply to @emilazy:matrix.org
do we have conversions for when new std::filesystem::path-using code has to talk to Path-land, or should I just port any Path stuff I touch? * I noticed that many std::filesystem::path exception do not provide the most readable error messages and they also do not support these error traces, we are using, so I think we should re-wrap those and throw nix's own exception class in most cases. I think for the most part we want to at least migrate away from path concatenation, this is the most annoying part that breaks things in the windows port. | 17:13:19 |
| emily | do the error messages differ from strerror? | 17:16:17 |
| emily | they provide the OS error code, so you can always just strerror yourself | 17:16:32 |
| Mic92 | emily: you can just throw a syserror and the error message is taken care off: https://github.com/NixOS/nix/blob/aa9c0bc1ee03f0fedebc4a6367fcf5bbecb4ef5c/src/libfetchers/git-utils.cc#L227 | 17:18:28 |
| emily | right | 17:19:34 |
| emily | although, where is that getting the code from? | 17:19:48 |
| Mic92 | errno | 17:20:04 |
| emily | is it guaranteed that errno corresponds to e.code() there? | 17:20:08 |
| Mic92 | Unless something has overridden the errno in the meantime, yes | 17:20:30 |
| emily | hmm, does the spec actually guarantee that or is it just a common side effect of implementations being written in terms of the C API? I didn't see it mentioned on cppreference anywhere, at least | 17:21:37 |
| Mic92 | Ah. no. Actually I don't know what e.code() is. | 17:22:30 |
| Mic92 | Ok. It seems there is a table? https://en.cppreference.com/w/cpp/error/errc | 17:23:07 |
| Mic92 | But I know that those filesystem exception have errno updated corectly | 17:23:42 |
| emily | I think std::error_code's .value() just gives you an errno | 17:24:15 |
| emily | so I believe that strerror(e.code().value()) or similar is the correct thing to do | 17:24:33 |
| emily | if e.what() is not useful | 17:24:36 |
| emily | not 100% sure though | 17:25:10 |
| Mic92 | emily: https://github.com/NixOS/nix/blob/aa9c0bc1ee03f0fedebc4a6367fcf5bbecb4ef5c/src/libutil/error.hh#L235 | 17:30:06 |
|  Daniel Fahey joined the room. | 17:48:53 |
| emily | right | 17:52:55 |
|  sbc64 left the room. | 20:01:59 |
| 11 Nov 2024 |
|  @zxfsee:matrix.org left the room. | 02:53:23 |
 Vladimír Čunát | Any idea: build input /nix/store/foo does not exist (link)
That's... some Nix bug? | 06:24:10 |
| Vladimír Čunát | I found this long-closed issue, but surely we don't have a very old Nix on Hydra builders:
https://github.com/NixOS/nix/issues/6572 | 06:29:12 |
| Mic92 | vcunat: is it reproducible? | 09:01:03 |
| Vladimír Čunát | Two different machines did this on this particular derivation. | 09:01:27 |
