<thibm>
This prevent one to write a unicode literal (e.g., builtins.toJSON { a = "\\uf0a0"; }. This will evaluate to (once unescaped): {"a":"\\uf0a0"}
<thibm>
I'll add that this case is not tested in src/libutil/tests/json.cc. All the tests about escaping (e.g. "\n") do not test strings that contains the "\" character.
orivej has joined #nixos-dev
<sterni>
thibm: this is intentional: a \ in a string gets escaped to \\
__monty__ has joined #nixos-dev
<thibm>
sterni: sure, I got the intention. I'm not sure it's valid, though. A Nix-string like <an unicode \u005C string> (written \\u005C in Nix code) should be converted to JSON as <an unicode \u005C string>, not as <an unicode \\005C string>
<thibm>
This would need more logic. Indeed, the \ character alone must be escaped to \\, but not the string \u (and maybe other?)
<sterni>
thibm: this is correct if your string contains \u005C you woudln't want to have it be converted into an unicode literal in JSON
<sterni>
thibm: what you would propose would be that (builtins.fromJSON (builtins.toJSON "\\u005C")) == "\\"
<sterni>
thibm: Nix is completely unaware of unicode and all nix strings are byte squences, utf-8 enconded by convention in nixpkgs
<sterni>
thibm: the JSON standard says that you *may* encode unicode code point, but since you don't have it, as long as your string is utf-8 encoded it is fine
<thibm>
sterni: However, I feel like starting to make exceptions in toJSON from Nix string literals (just a bunch of characters) seems wrong
<thibm>
yes totally.
<thibm>
sterni: I'll add this test, if that answers your question: toJSON(out, "\\u005C"); ASSERT_EQ(out.str(), "\"\\u005C\"");
<LinuxHackerman>
thibm: I don't see any exceptions here?
<sterni>
I'm also not quite sure what you are getting at
<thibm>
LinuxHackerman: the exception is that "\abcd" is translated to "\\abc" while "\uabcd" is translated to "\uabcd"
<sphalerite>
> builtins.fromJSON ''"\u005c"''
<{^_^}>
\u characters in JSON strings are currently not supported
<sphalerite>
wait what
<thibm>
oh
<thibm>
ah, that's the parser side
<thibm>
not the generator
<sphalerite>
anyway, where would you expect \u escapes to be generated?
<sphalerite>
\\ is fine, no?
<thibm>
no it's not
<thibm>
In json, "\\uabcd" and "\uabcd" are two different strings
Synthetica has joined #nixos-dev
<sphalerite>
of course
<thibm>
and from Nix, there is no way to write "\uabcd" right now
<sphalerite>
> builtins.toJSON "🥕" # but why would you need to?
<{^_^}>
"\"🥕\""
<thibm>
sphalerite: why not :)
<thibm>
sphalerite: the user case was "my text editor do not display the codepoint nicely so I want to write in the \u form" (it was not me, I proposed to write the unicode character directly to solve the toJSON issue at the first place)
<thibm>
Still, it's a bug from my point of view
<sphalerite>
I mean, you can still manually write a JSON string within a nix string like ''"\u005c"''
<sphalerite>
I don't get what the bug is
<sphalerite>
you want toJSON to be configurable, so it will output either \u sequences or just the character directly?
<thibm>
manually, sure. What if you try to put that in a config option that generates the JSON for you?
<sphalerite>
So this has nothing to do with JSON, but you want _nix_ strings to support \u sequences?
<sphalerite>
nix string literals*
<sterni>
thibm: this is not solvable in nix as long as nix strings are byte sequences
<thibm>
sphalerite: it does not matter if toJSON put the character or the \u sequence, it's equilavlent. The bug is that toJSON currently generates neither of those
<sterni>
or it would mean that builtins.fromJSON would need to decode it as some unicode encoding and then convert it to JSON
<thibm>
sterni: yes, the more I think about it, the more I feel like there is no elegant solution
<thibm>
sterni: do you mean that we would use fromJSON to parse a string in order to generate a correct string JSON value in toJSON?
<abathur>
gchristensen: with the caveat that it does need some cleanup (commits unsquashed for clarity, and there's a pseudo-python file included that just exists to make the big-picture ~process clearer), my personal opinion is that it's otherwise ready
<gchristensen>
want to clean it up?
<gchristensen>
let's merge it ...
<abathur>
clarity/reviewability
<abathur>
I think the history can be squashed on merge? the file that needs removing is `scripts/darwin_volume_reference.py`. I can also do both, though I do need to finish an email up first :)
<gchristensen>
agreed
<gchristensen>
okay ... I need to figure out the things I changed in this system's config so I can get it working from a fresh deploy ...
<gchristensen>
I wish I had a second mac I could use to experient :)
<rmcgibbo[m]>
hexa-: i downloaded the kea-1.9.6 package, and it looks to me like there is in fact no such pattern in Makefile.am.
<hexa->
rmcgibbo[m]: the line hint is wrong
<rmcgibbo[m]>
oh. yeah it just doesn't know the line because the check is based on grepping the log.
LinuxHackerman has quit [Ping timeout: 245 seconds]
kalbasit[m] has quit [Ping timeout: 245 seconds]
vaibhavsagar has quit [Ping timeout: 245 seconds]
LinuxHackerman has joined #nixos-dev
<sterni>
Ericson2314: okay I'm through, sorry it took so long, I don't think I noticed anything major
thefloweringash has quit [Ping timeout: 245 seconds]
<Ericson2314>
sterni no worries at all. Thanks so much!
kalbasit[m] has joined #nixos-dev
vaibhavsagar has joined #nixos-dev
thefloweringash has joined #nixos-dev
<sterni>
I wonder if we can refactor some of the llvmPackages to use generic derivation expressions
tomberek has joined #nixos-dev
<sterni>
especially for some of the libraries at least for some version ranges they are very similar
<sterni>
I can imagine that this would make such large scale changes much easier in the future
<sterni>
of course the exrpession in question would probably be an lib.optional* mess to a certain extent
<qyliss>
Ericson2314: turns out NetBSD 8.0 doesn't support aarch64 at all, so I can't test binaries on my new NetBSD laptop
<qyliss>
so I think upgrading to 9.x will have to come before getting dynamically linked binaries to run
<Ericson2314>
qyliss ok well then to dust off that commit then. I hope now that it's working it will be far easier than my hail mary version bump when it wasn't.
<qyliss>
Ericson2314: do you want to bump everything in your PR to 9.1, or shall I?
<Ericson2314>
qyliss I don't *want* so be my guest but I can do it if you are busy too
<qyliss>
Ericson2314: tbh I'm looking for a distraction
<Ericson2314>
Well I think I'm due to get back on task so sure go ahead
<abathur>
If anyone could use some glory: I think the merge of nix#4289 lights a path to full uninstall/reinstall support. I can't pursue it any time soon, but I'm happy to discuss as needed. I wrote a proof-of-concept this fall that may be reheatable as a starting point.