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

121–130 of 173 posts

Re: FracturedJson

#121

Post by zzo38computer »

kstenerud wrote: post #69
imiric wrote: post #52

Earlier quoted context omitted.

That's neat, but I'm much more intrigued by your Concise Encoding project[1]. I see that it only has a single Go reference implementation that hasn't been updated in 3 years. Is the project still relevant? Thanks for sharing your work! [1]: https://concise-encoding.org/

Thanks! I'm actually having second thoughts with Concise Encoding. It's gotten very big with all the features it has, which makes it less likely to be adopted (people don't like new things). I've been toying around with a less ambitious format called ORB: https://github.com/kstenerud/orb It's essentially an extension of BONJSON (so it can read BONJSON documents natively) that adds extra types and features. I'm still…

I use ASN.1X, so I use some types that those other formats do not have. Some of the types of ASN.1 are: unordered set, ISO 2022 string, object identifier, bit string. I added some additional types into ASN.1X, such as: TRON string, rational numbers, key/value list (with any types for keys and for values (and the types of keys do not necessarily have to match); for one thing, keys do not have to be Unicode), and reference to other nodes. However, ASN.1 (and ASN.1X) does not distinguish between qNaN and sNaN. I had also made up TER, which is a text format that can be converted to DER (like how ORT can be converted to ORB, although its working is differently, and is not compatible with JSON (TER somewhat resembles PostScript)).

Your extensions of JSON with comments, hexadecimal notation, optional commas, etc is useful though (my own program to convert JSON to DER does treat commas as spaces, although that is an implementation detail).

Re: FracturedJson

#122

Post by andix »

I like this idea a lot. Currently the biggest issue for adoption seems to be the missing packages for most programming languages, and for homebrew/etc.

It should even be possible to compile the dotnet library to a C-compatible shared library and provide packages for many other languages.

Re: FracturedJson

#123

Post by Y-bar »

Etheryte wrote: post #103
Y-bar wrote: post #93

Earlier quoted context omitted.

I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.

I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people run…

That’s about 99% of the argument I am making. The problem is legacy software and bad certification workflows, not the software being used.

If I’m working with Java it’s indeed conceivable that I could update with some effort.

If I’m working with Node it’s conceivable that I could update with some effort.

If I working with YAML is it not conceivable that I could update with some effort?

PHP is stupid because version 3 did not support object oriented programming.

CSS is bad because version 2 did not support grid layouts or flexbox.

Why should I critique on these based on something that they have fixed a long time ago instead of working on updating to the version which contain the fix I am complaining about?

There is a gradient limit where the onus shifts squarely to one side once the spec has changed and a number of libraries have begun supporting the new spec.

Re: FracturedJson

#124

Post by ruuda »

jcims wrote: post #57
hnlmorg wrote: post #32

Earlier quoted context omitted.

Powerful but not sufficient. There’s plenty of us who don’t use jq for various reasons.

LLMs have allowed me to start using jq for more than pretty printing JSON.

Give https://rcl-lang.org/#intuitive-json-queries a try! It can fill a similar role, but the syntax is very similar to Python/TypeScript/Rust, so you don’t need an LLM to write the query for you.

Re: FracturedJson

#125

Post by klysm »

simonw wrote: post #17

It looks like there are two maintained implementations of this at the moment - one in C# https://github.com/j-brooke/FracturedJson/wiki/.NET-Library and another in TypeScript/JavaScript https://github.com/j-brooke/FracturedJsonJs . They each have their own test suite. There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code…

This is also basically a pure function which makes it super simple to write a harness.

Re: FracturedJson

#126

Post by wizzwizz4 »

JonChesterfield wrote: post #117
wizzwizz4 wrote: post #73

Earlier quoted context omitted.

You can guarantee that all the cases in the code are tested. That doesn't necessarily mean that all the behaviour is tested. If two implementations use very different approaches, which happen to have different behaviour on the Mersenne primes (for deep mathematical reasons), but one of them special-cases byte values using a lookup table generated from the other, you wouldn't expect mutation testing to catch the discr…

I think if you hit full path coverage in each of them independently and run all the cases through both and check they're consistent you're still done. Or branch coverage for the lesser version, the idea is still to generate interesting cases based on each implementation, not based solely on one of them.

If the buggy implementation relies indirectly on the assumption that 2^n - 1 is composite, by performing a calculation that's only valid for composite values on a prime value, there won't be a separate path for the failing case. If the Mersenne numbers don't affect flow control in a special way in either implementation, there's no reason for the path coverage heuristic to produce a case that distinguishes the implementations.

Re: FracturedJson

#127

Post by wizzwizz4 »

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.

You're thinking of "a\u000b". "a\u0000b" is the three-character string also written "a\x00b".

Re: FracturedJson

#128

Post by jcims »

ruuda wrote: post #124
jcims wrote: post #57

Earlier quoted context omitted.

LLMs have allowed me to start using jq for more than pretty printing JSON.

Give https://rcl-lang.org/#intuitive-json-queries a try! It can fill a similar role, but the syntax is very similar to Python/TypeScript/Rust, so you don’t need an LLM to write the query for you.

Nice! Thanks!

Re: FracturedJson

#129

Post by fcoury »

simonw wrote: post #17

It looks like there are two maintained implementations of this at the moment - one in C# https://github.com/j-brooke/FracturedJson/wiki/.NET-Library and another in TypeScript/JavaScript https://github.com/j-brooke/FracturedJsonJs . They each have their own test suite. There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code…

Just ported it to rust and plan on maintaining it if you want to add it to your original comment.

More details on a sibling comment:

https://github.com/fcoury/fracturedjson-rs https://crates.io/crates/fracturedjson

Comment with details: https://news.ycombinator.com/item?id=46468641

Re: FracturedJson

#130

Post by re »

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.
Post reply on HN