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

131–140 of 173 posts

Re: FracturedJson

#131

Post by ramraj07 »

whoamii wrote: post #87
ramraj07 wrote: post #71

Earlier quoted context omitted.

I dont know if you spend a fraction of your life scrolling vertically through megabyte sizes json files, but if something can reduce the height of the file thats welcome. We dont need to read every single line fro left to right, we just need to quickly browse through the entire file. If a line in this format is longer than fits the screen, its likely we dont need to know whats in the cut off right corner anyway.

Gigabytes even (people do the silliest things). But ‘find’ gets me there 90% of the time, and at that point the amount of vertical scrolling isn’t really any different than in a 2kb file.

Your usecase is different then. Some of us actually want to browse through the entire json.

Re: FracturedJson

#132

Post by gritzko »

I am a bit saddened by the fact people get obsessed by syntactic innovation or even less than that. Don't we have plenty of urgent problems around us?

Re: FracturedJson

#133

Post by teruakohatu »

gritzko wrote: post #132

I am a bit saddened by the fact people get obsessed by syntactic innovation or even less than that. Don't we have plenty of urgent problems around us?

People have a problem and are trying to solve it. We are not all required, nor able, to solve whatever the world’s most urgent problem is today.

In this case they are formatting JSON in an easier to read way. It’s not an alternative to CRDT, it is a totally different issue.

Re: FracturedJson

#134

Post by gritzko »

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…

Probably, we need a formal data format, because JSON is just a notation. It does not mandate the bit width of numbers, for example, or whether ints are different from floats. Once there is such formal model, we can map it 1:1 between representations.

I am writing this because I work on a related topic https://replicated.wiki/blog/args.html

Re: FracturedJson

#135

Post by gritzko »

teruakohatu wrote: post #133
gritzko wrote: post #132

I am a bit saddened by the fact people get obsessed by syntactic innovation or even less than that. Don't we have plenty of urgent problems around us?

People have a problem and are trying to solve it. We are not all required, nor able, to solve whatever the world’s most urgent problem is today. In this case they are formatting JSON in an easier to read way. It’s not an alternative to CRDT, it is a totally different issue.

What can I say. I want all problems in my life to be like that.

Re: FracturedJson

#136

Post by gritzko »

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.

Did you read "Parsing JSON is a minefield"?

Re: FracturedJson

#137

Post by staticshock »

simonw wrote: post #15
polshaw wrote: post #4

Is there an option for it to read the contents from a pipe? that's by far my biggest use for the jq app.

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.

Re: FracturedJson

#138

Post by Androcles »

That is remarkable. I recently implemented this very functionality in Python using roughly 200 lines of code, completely unaware that a pre-built library was available.

Re: FracturedJson

#139

Post by kreco »

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…

I haven't, but it's an interesting format for sure.

I've found a more comprehensive documentation here. [1]

At first glance, I would say it's a bit more complex that it should for a "human readable" format.

[1] https://edn-format.dev/

Re: FracturedJson

#140

Post by piskov »

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

Post reply on HN