| 13 Aug 2025 |
 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 |
| emily | (and JSON for not specifying any goddamn semantics at all at first) | 15:34:35 |
| piegames | Tbh if a library does untyped bullshit like that, I preferably want it out of my sight | 15:34:47 |
| emily | no, this is just JSON | 15:34:58 |
| emily | JSON has only one numeric type, because JavaScript does | 15:35:05 |
| emily | its type is even vaguer than JavaScript's however | 15:35:09 |
| emily | I don't have a strong opinion on "reject integer-looking things that are out of Nix integer range" vs. "always produce floats for things outside of Nix integer range"; both have their merits. the current state seems unjustifiable though | 15:35:36 |
 Charles | i thought that JSON just didn't define any constraints on numeric types | 15:36:09 |
 raitobezarius (DECT: 7248) | In reply to @weethet:catgirl.cloud
@raitobezarius:matrix.org please review https://gerrit.lix.systems/c/lix/+/3862 In ~ 5 days, yeah | 15:35:52 |
| Charles | and left that as an implementation detail | 15:36:25 |
| emily | it depends what you mean by "JSON". | 15:36:29 |
| emily | the original terrible specification defines syntax and says basically nothing about semantics at all https://www.json.org/json-en.html | 15:36:45 |
