| 8 Nov 2024 |
 p14 | Observation: If I do nix build .#{foo,bar,baz,qux} in a dev checkout of nixpkgs, I appear to see all of nixpkgs get copied to the store repeatedly. At least, it takes a while and the 'copying' message is shown. Is there a cheaper way to eval a large number of packages during development? | 11:27:13 |
 Mic92 | p14: nix build -f . .#{foo,bar,baz,qux} | 13:24:38 |
| Mic92 | for nixpkgs | 13:24:45 |
| Mic92 | maybe also: nix build -f . .#{foo,bar,baz,qux} -L | 13:24:59 |
| Mic92 | p14: actually you need to do this: nix build -f . foo bar baz qux -L | 13:26:23 |
| p14 | In reply to @joerg:thalheim.io
p14: actually you need to do this: nix build -f . foo bar baz qux -L That is fine for nixpkgs but what about flake-only projects? | 13:34:16 |
|  moved to @amadaluzia:tchncs.de changed their display name from (artur 'manuel) to @amadaluzia:tchncs.de. | 14:28:52 |
| 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:one.ems.host 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 |
