| 8 Nov 2024 |
|  moved to @amadaluzia:tchncs.de changed their display name from @amadaluzia:tchncs.de to moved to @amadaluzia:tchncs.de. | 14:30:12 |
 Find me at aleksana:qaq.li | Redacted or Malformed Event | 16:11:44 |
 hexa | off-topic here | 16:12:29 |
| Find me at aleksana:qaq.li | Oh wrong thread | 16:12:46 |
| hexa | #dev:nixos.org | 16:13:58 |
 Mic92 | Yingchi Long: ^ maybe also post your ideas here. | 17:51:21 |
 Yingchi Long | Oh, I see, recently I was taking a brainstorm on "what did nixd need in NixOS/nix".
The first thing I want to do is a type-annotation / type checking features for nix-lang, and I'd like to do this in nixd as a PoC, that's a long term plan w/ a large diff. | 17:56:38 |
| Yingchi Long | The second is to improve the error handling of the parser to some extend, maybe switch it from a yacc-generated GLR, to hand-written recursive descent, also unifies the parser used for tooling, and the official one. | 17:57:53 |
| Yingchi Long | And the last one is to improve the evaluation performance by Ahead-Of-Time analysis, namely some tricks used in Chez Scheme, and related work. | 17:59:13 |
| Yingchi Long | (Just some thoughts, sorted by implementation state). | 17:59:57 |
| 9 Nov 2024 |
| Mic92 | Yingchi Long: Could type annotations combined with doc comments? A bit how jsdoc does type checking? | 07:51:59 |
| Mic92 | https://github.com/NixOS/rfcs/pull/145 | 07:52:28 |
|  voxel 🏳️⚧️ joined the room. | 11:44:40 |
 fricklerhandwerk | In reply to @inclyc:matrix.org
Oh, I see, recently I was taking a brainstorm on "what did nixd need in NixOS/nix".
The first thing I want to do is a type-annotation / type checking features for nix-lang, and I'd like to do this in nixd as a PoC, that's a long term plan w/ a large diff. For reference, in the improbable case you aren't aware: https://github.com/thufschmitt/ptyx
Theophane did his master's thesis on building gradual typing into the Nix language.
| 14:19:46 |
| voxel 🏳️⚧️ left the room. | 14:20:11 |
| 10 Nov 2024 |
 emily | Path is deprecated for new code, right? | 03:27:46 |
| 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 |
