| 14 Aug 2025 |
 emily | also, I don't think this should be a major consideration, but I suspect that making the negative case error out with nlohmann_json would be a pain | 16:51:33 |
| emily | because it is already a float by the time you see it, because of being a value that does not fit into the integer types | 16:51:59 |
| emily | I mean I guess you can compare the float but float precision issues may make that weird | 16:52:13 |
| emily | and you have to determine whether it "could be" an integer | 16:52:20 |
| emily | let's put it this way | 16:52:35 |
| emily | if we were going to hard-reject JSON integer values | 16:52:40 |
| emily | it should be based on the -(2^53)+1 to (2^53)-1 interoperable range | 16:53:09 |
| emily | and happen on the serialization end as well | 16:53:18 |
| emily | (IMO) | 16:53:22 |
| emily | that would be undesirable though because of fromJSON being abused for general integer-parsing | 16:53:32 |
| emily | so we're already outside the bounds of the fully interoperable JSON format | 16:53:44 |
 jade_ | also fromJSON may take some json that isn't actually getting operated on in nix except for rearrangement (e.g. the large integers don't actually get touched) | 16:54:05 |
| emily | well, the large integers will still get clobbered precision-wise | 16:54:23 |
| emily | that's sort of inevitable though | 16:54:32 |
| emily | and why people who put large integers into JSON put them in strings generally | 16:54:42 |
| jade_ | yes, i just mean that they had it coming to a degree; having any json parsing error out is unfortunate | 16:54:52 |
| emily | Nixpkgs just does the funny thing because of Nix's lack of useful parsing functions | 16:54:53 |
| emily | right | 16:54:56 |
| emily | I will probably prepare a revert of that fromJSON change in the absence of strong objection / someone who wants to try and make it do the same for negative integers | 16:55:24 |
| emily | I wish someone had told Douglas Crockford what semantics are | 16:55:39 |
| emily | further context for this is https://github.com/NixOS/nixpkgs/pull/433710 because it turns out that fromTOML is a total mess (working on a stack locally) | 16:56:05 |
| jade_ | i would like consistent behaviour with pos/neg integers ideally and i would rather it be a total function. so ya | 16:56:08 |
| emily | btw what's the intended way to update functional2 snapshots with a just-built Lix? | 16:57:29 |
| emily | PATH=build/… hacks? | 16:57:33 |
| jade_ | "did we wire that in yet" -helle | 16:59:28 |
| emily | hm, seems that doesn't work | 16:59:29 |
| emily | btw, Nix recently started forbidding NUL bytes in string literals, fromJSON, etc.; how do we feel about backporting that? | 17:00:18 |
| emily | I know it's "language versioning" kind of territory but the behaviour is also super broken so if they're pulling off the bandaid already… | 17:00:36 |
| jade_ | I think it's the _NIX_TEST_ACCEPT=1 thing, and iirc you can just run functional2 with pytest in lix (assuming the fresh lix is in fact in PATH and you've rehashed in zsh etc) | 17:00:59 |
| emily | yes the problem is getting it in $PATH | 17:01:27 |
