| 12 Aug 2025 |
 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 | Sorry, you're absolutely right | 20:17:58 |
| raitobezarius | That sounds like a good plan, patch for releases and drop for HEAD | 20:18:13 |
| raitobezarius | 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 | (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 |
| emily | IOW, the nlohmann_json semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float" | 14:54:35 |
| emily | if we were to implement "we try to find an integer type we can fit a literal into, and otherwise we produce a float" in Nix, we should produce a float for builtins.fromJSON "9223372036854775808" | 14:54:52 |
| emily | otherwise, if we want "we reject integer-looking literals that don't fit into an integer type, and produce a float only for explicitly float-y values", we should error out on builtins.fromJSON "-9223372036854775809" | 14:55:16 |
| emily | the current combination of behaviour seems like an unjustifiable accident caused by the impedance mismatch between nlohmann_json's API oriented around C++ numeric types, and Nix's signed-only integers | 14:55:45 |
| emily | P.S. I want to cry | 14:56:12 |
 WeetHet | @raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862 | 15:29:28 |
 piegames | In reply to @emilazy:matrix.org
IOW, the nlohmann_json semantics are "we try to find an integer type we can fit a literal into, and otherwise we produce a float" Thanks, I hate it | 15:34:14 |
| emily | well, blame JavaScript :) | 15:34:30 |
