I switched to jless and never looked back. The user interface is miles ahead of everything else
It's not the same. The jq is not just a viewer. It's a JSON query lang processor.
Jaq – A jq clone focused on correctness, speed, and simplicity
181–190 of 254 posts
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#182Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.
I believe this has improved in jq 1.7: https://github.com/jqlang/jq/releases/tag/jq-1.7 > Use decimal number literals to preserve precision. Comparison operations respects precision but arithmetic operations might truncate.
This is still broken in jq 1.7 for sufficiently long exponents
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#183Earlier quoted context omitted.
What would be your choice if you would need to write high performing CLI tool?
The other options are C, C++, Go, and maybe Ada or Zig, though I haven't seen many CLI tools written in those two in practice. In practice, it seems like Go, Rust, and C++ are the preferred languages for newer CLI tools, although I have no data; my conclusion is based on my general perception. Older ones, C and Perl.
Zig
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#184Earlier quoted context omitted.
I believe this has improved in jq 1.7: https://github.com/jqlang/jq/releases/tag/jq-1.7 > Use decimal number literals to preserve precision. Comparison operations respects precision but arithmetic operations might truncate.
This is still broken in jq 1.7 for sufficiently long exponents
From a quick test it looks like it supports exponents up to 9 digits long (i.e. 1.0e999999999), which, frankly, seems pretty reasonable; it's hard for me to imagine a use case where you'd want to represent numbers larger than that.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#185> nan > nan is false, while nan If this wrong behavior from jq, or some artifact consistent with how the floating point spec is defined, surprising, but faithful to IEEE 754 nonetheless?
I used Bard after trying unsuccessfully to decipher the wikipedia page and Bard says, according to IEEE 754, nan nan should return false (0)
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#186[flagged]
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#187Earlier quoted context omitted.
As the benchmarks show, jaq is pretty significantly faster than jq. I've commented before that I expect Rust to be a language that is generally faster than even C or C++ in a way that's hard to capture in small benchmarks, because the borrow checker permits code to be written safely that does less copying that other languages have to do for safety. Given the nature of what jq/jaq does, I wouldn't be surprised that th…
FWIW, I see no difference. (hyperfine 1.17.0, jq 1.7, jaq 1.2.0) $ hyperfine -N -w 100 -m 1000 -L bin jq,jaq "echo '[1,2,3]' | {bin} '.[1]'" Benchmark 1: echo '[1,2,3]' | jq '.[1]' Time (mean ± σ): 3.4 ms ± 1.7 ms [User: 0.6 ms, System: 2.6 ms] Range (min … max): 0.7 ms … 5.8 ms 1000 runs Benchmark 2: echo '[1,2,3]' | jaq '.[1]' Time (mean ± σ): 3.4 ms ± 1.7 ms [User: 0.5 ms, System: 2.7 ms] Range (min … max): 0.7 ms…
That would still be a microbenchmark. Given that the benchmarks in the post take on the order of seconds to run, I am assuming they are not microbenchmarks, or at least, much less "micro"benchmarks. I would hope some sort of standard JSON querying benchmarking suite would include some substantial, hundreds-of-kilobyes or more JSON samples in it.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#188It's so awesome when projects shout out other projects that they're similar to or inspired by or not replacements for. I learned about https://github.com/yamafaktory/jql from the readme of this project and it's what I've been looking for for a long time, thank you! That's not to take away from JAQ by any means I just find the JQ style syntax uber hard to grokk so jql makes more sense for me.
Very nice in this regard is gron, too. It simply flattens any json into lines of key value format, making it compatible with grep and other simple stream operations. https://github.com/tomnomnom/gron
And also https://github.com/adamritter/fastgron that I've just discovered.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#189> nan > nan is false, while nan If this wrong behavior from jq, or some artifact consistent with how the floating point spec is defined, surprising, but faithful to IEEE 754 nonetheless?
IIRC, any comparison using a nan must fail (return false) according to the IEEE spec.
I think it is a bit more complex, since NaN is defined to be "unordered" with respect to all other values (including other NaNs), and so any relation for which unordered values result in true (e.g., compareQuietNotEqual) will return true. (See section 5.11)
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#190Congratulations! We're almost back to the basic functionality we used to have with XSLT.
You could use an elaborate filter with jq (see https://stackoverflow.com/a/73040814/452614) to transform JSON to XML and then use an XQuery implementation to process the document. It would be quite powerful, especially if the implementation supports XML Schema. I have not tested it.
Or https://github.com/AtomGraph/JSON2XML which is based on https://www.w3.org/TR/xslt-30/#json-to-xml-mapping
It even looks like we could use an XSLT 3 processor with the json-to-xml function (https://www.w3.org/TR/xslt-30/#func-json-to-xml) and then use XQuery or stay with XSLT 3.
Now I have to test it.