Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FracturedJson

github.com

Post reply on HN
Print view View original

141–150 of 173 posts

Re: FracturedJson

#141

Post by jbeninger »

kreco wrote: post #63
kstenerud wrote: post #48

This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…

Can you tell me what was the context that lead you to create this? Unrelated JSON experience: I worked on a serializer which save/load json files as well as binary file (using a common interface). From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem) So I change the json format into something way more lax (optional comma, optional colon, optional quotes,…

I'm in the JS ecosystem pretty regularly and "restrictive with no benefit" is the right description. I use JSON5 now when I have to, which greatly reduces the restrictions. I already have a build step so throwing in a JSON5 -> JSON converter is negligible.

As for FracturedJson, it looks great. The basic problem statement of "either minified and unreadable or prettified and verbose" isn't one I had put my finger on before, but now that it's been said I can't unsee it.

Re: FracturedJson

#142

Post by esrauch »

kstenerud wrote: post #116
esrauch wrote: post #77

Earlier quoted context omitted.

This is very interesting, though the limitations for 'security' reasons seem somewhat surprising to me compared to the claim "Anything JSON can do, it can do. Anything JSON can't do, it can't do.". Simplest example, "a\u0000b" is a perfectly valid and in-bounds JSON string that valid JSON data sets may have in it. Doesn't it end up falling short of 'Anything JSON can do, it can do" to refuse to serialize that string?

"a\u0000b" ("a" followed by a vertical tabulation control code) is also a perfectly valid and in-bounds BONJSON string. What BONJSON rejects is any invalid UTF-8 sequences, which shouldn't even be present in the data to begin with.

My example was a three character string where the second one is \u0000, which is the NUL character in the middle of the string.

The spec on the GitHub says that it is banned to include NUL under a security stance, that someone that after parse someone might do strlen and accidentally truncate to a shorter string in C.

Which I think has some premise, but its a valid string contents in JSON (and in Utf8), so it is deliberately breaking 1:1 parity with JSON parity in the name of a security hypothetical.

Re: FracturedJson

#143

Post by strunz »

piskov wrote: post #140

The lengths people go to (not) use the XML. It has everything: comments, validation, schema, what have you. Though, I guess, the only(?) great XML workflow is with C# LINQ

Generally much larger for the same date and not readable unless using something that indents. Even then, I'd argue it's still less legible.

Re: FracturedJson

#144

Post by rednafi »

How many times do you actually need to look at large JSONs? The cost of readability is too high, IMO.

Personally, I don't spend much time looking at complex JSON; a binary format like Protobuf along with a typed DSL is often what you need. You can still derive JSON from Proto if you need that. In return, you get faster transport and type safety.

Also, on another note, tools like jq are so ubiquitous that any format that isn't directly supported by jq will have a really hard time seeing mass adoption.

Re: FracturedJson

#145

Post by jedbrooke »

I had to do a double take on the repo author here :)

this tool also looks super useful, I spend so much time at work looking at json logs that this will surely come in handy. It’s the kind of thing I didn’t even know I needed, but now that I saw it it makes perfect sense.

Re: FracturedJson

#146

Post by zzo38computer »

Sardtok wrote: post #118
kreco wrote: post #63

Earlier quoted context omitted.

Can you tell me what was the context that lead you to create this? Unrelated JSON experience: I worked on a serializer which save/load json files as well as binary file (using a common interface). From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem) So I change the json format into something way more lax (optional comma, optional colon, optional quotes,…

Have you heard of EDN? It's mostly used in Clojure and ClojureScript, as it is to Clojure what JSON is to JS. If you need custom data types, you can use tagged elements, but that requires you to have functions registered to convert the data type to/from representable values (often strings). It natively supports quite a bit more than JSON does, without writing custom data readers/writers. https://github.com/edn-format…

Another thing to possibly consider would be ASN.1 (you can also use the nonstandard extensions that I made up, called ASN.1X, if you want some of the additional types I included such as a key/value list). (You are not required to implement or use all of the types or other features of ASN.1 in your programs; only use the parts that you use for your specific application.) Unlike EDN, ASN.1 has a proper byte string type, it is not limited to Unicode, it has a clearly defined canonical form (DER, which is probably the best format (and is the format used by X.509 certificates); BER is too messy), etc. DER is a binary format (and the consistent framing of different types in DER makes it easier to implement and work with than the formats that use inconsistent framing, although that also makes it less compact); I made up a text format called TER, which is intended to be converted to DER.

Re: FracturedJson

#147

Post by [deleted] »

re wrote: post #130
fcoury wrote: post #114

I ported it to Rust with a cli tool that allows you to format json in this format: https://github.com/fcoury/fracturedjson-rs https://crates.io/crates/fracturedjson And install with: cargo install fracturedjson > $ fjson --help Rust port of FracturedJsonJs: human-friendly JSON formatter with optional comment support. Usage: fjson [OPTIONS] [FILE]... Arguments: [FILE]... Input file(s). If not specified, reads from std…

Ports are a derivative work; you should preserve the original author's copyright attribution.

[deleted]

Re: FracturedJson

#148

Post by minitech »

Y-bar wrote: post #27
merelysounds wrote: post #19

Earlier quoted context omitted.

This is a reference to YAML parsing the two letter ISO country code for Norway: country: no As equivalent to a boolean falsy value: country: false It is a relatively common source of problems. One solution is to escape the value: country: “no” More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

Current PyYAML:

  >>> import yaml
  >>> yaml.safe_load("country: NO")
  {'country': False}
Other people did not stop having this problem.

It might be that there’s some setting that fixes this or some better library that everyone should be switching to, but YAML has nothing that I want and has been a repeated source of footguns, so I haven’t found it worth looking into. (I am vaguely aware that different tools do configure YAML parsing with different defaults, which is actually worse. It’s another layer of complexity on an already unnecessarily complex base language.)

Re: FracturedJson

#149

Post by simonw »

staticshock wrote: post #137
simonw wrote: post #15

Earlier quoted context omitted.

There's a C# CLI app in the repo: https://github.com/j-brooke/FracturedJson/blob/main/Fracture... Output is to standard out, or a file specified by the --outfile switch. Input is from either standard in, or from a file if using the --file switch It looks like both the JavaScript version and the new Python C# wrapper have equivalent CLI tools as well.

I don't see a CLI tool in the Typescript repo.

Huh, you're right - could have sworn I saw one but I must have been mistaken.

Re: FracturedJson

#150

Post by boxed »

odyssey7 wrote: post #58
boxed wrote: post #45

Earlier quoted context omitted.

With mutation testing you can guarantee that all the behavior in the code is tested.

UC Berkeley: “Top-level functional equivalence requires that, for any possible set of inputs x, the two pieces of code produce the same output. … testing, or input-output (I/O) equivalence, is the default correctness metric used by the community. … It is infeasible to guarantee full top-level functional equivalence (i.e., equivalence for any value of x) with testing since this would require testing on a number of inp…

How is that relevant for mutation testing?
Post reply on HN