| 12 Aug 2025 |
 emily | I think that the semantics that fromTOML exposes stably should be relatively safe; it's just that experimentally extending it to timestamps turns out to be more complicated than expected | 20:13:17 |
| emily | that fromTOML cannot handle all of TOML… is suboptimal, but oh well | 20:13:32 |
| emily | easier to expand than shrink :) | 20:13:47 |
| emily | I do think that the patch should be applied to stable releases, because breaking eval semantics even for experimental features in stable releases seems bad, and the Nixpkgs bump is blocked right now | 20:14:27 |
| emily | but +2 for dropping for next release | 20:14:40 |
 raitobezarius (DECT: 7248) | Somehow obvious amirite | 20:15:06 |
| raitobezarius (DECT: 7248) | Alright | 20:15:39 |
| raitobezarius (DECT: 7248) | Taking away exp features from stable releases is a bit meh tho | 20:15:57 |
| emily | Sergei Zimmerman (xokdvium)'s patch doesn't take anything away | 20:16:16 |
| emily | (it computes the previous behaviour back on top of the new toml11) | 20:16:27 |
| emily | it's just an unfortunate amount of complexity for a broken feature that's clearly an eval stability liability, so I'd prefer to see a drop on HEAD | 20:17:01 |
| emily | doing it only for stable releases bounds the lifetime of the complexity | 20:17:21 |
| raitobezarius (DECT: 7248) | Sorry, you're absolutely right | 20:17:58 |
| raitobezarius (DECT: 7248) | That sounds like a good plan, patch for releases and drop for HEAD | 20:18:13 |
| raitobezarius (DECT: 7248) | Thank you xokdvium for this! | 20:18:46 |
 Sergei Zimmerman (xokdvium) | Sure. I'll bring this issue up at the nix team meeting as well. I'd be in favor of dropping this feature on master. Digging through toml11 def wasn't a great experience. | 20:20:09 |
| raitobezarius (DECT: 7248) | (expectations for the work above: I can probably review some CLs around that but I'm on holidays for the next 5 days, so I won't take care of it immediately) | 21:13:26 |
| 13 Aug 2025 |
 niko ⚡️ | oh no I was wondering why nix build on lix main wouldn't reproduce them and turns out the other failing install checks only error on new nixpkgs unstable that's not a good sign | 09:53:56 |
|  Picnoir changed their display name from Picnoir DECT 7426 to Picnoir. | 13:24:51 |
| emily | has anyone run into this on macOS error: failed to extract archive (Cannot extract through symlink /tmp/nix-50z48nbfhpxw5h6rvfcpq4ibip/nix-darwin-e04a388232d9a6ba56967ce5b53a8a6f713cdfcf)
it might be related to me trying to recover my busted system right now but I usually have /nix/tmp as my temp-dir and I'm wondering if there is actually some broken behaviour around /tmp -> /private/tmp when using --store local with the default config
| 15:35:17 |
| emily | --temp-dir /private/tmp fixes it | 15:35:35 |
| 14 Aug 2025 |
| emily | overlay may need adjusting for https://github.com/NixOS/nixpkgs/pull/433617, though should probably be harmless as the users are on nixComponents.* or a specific version now I guess | 14:09:10 |
| emily | is there a reason we reject builtins.fromJSON "9223372036854775808" but allow builtins.fromJSON "-9223372036854775809" and produce a float | 14:49:01 |
| emily | it seems intentional (error: unsigned json number 9223372036854775808 outside of Nix integer range, "unsigned" specifically) but it also seems bizarre | 14:49:14 |
| emily | @note There are three enumeration entries (number_integer, number_unsigned, and
number_float), because the library distinguishes these three types for numbers:
@ref basic_json::number_unsigned_t is used for unsigned integers,
@ref basic_json::number_integer_t is used for signed integers, and
@ref basic_json::number_float_t is used for floating-point numbers or to
approximate integers which do not fit in the limits of their respective type.
| 14:51:57 |
| emily | so it's handled like that in nlohmann_json to allow lossless parsing of bigger-than-signed integers if you have an unsigned type as C++ does | 14:52:27 |
| emily | but Nix only has a signed integer type | 14:52:35 |
| emily | if we're doing "values outside the range get approximated as floats" a la JavaScript (though note that we losslessly represent more values than JS does already since we have a separate integer type…), then we should do that for too-large signed integers too | 14:53:11 |
| emily | otherwise, we should reject out-of-range integers regardless of sign | 14:53:31 |
| emily | (this probably means our JSON serialization is nonportable too by RFC rules?) | 14:53:41 |
