Congratulations! We're almost back to the basic functionality we used to have with XSLT.
Jaq – A jq clone focused on correctness, speed, and simplicity
91–100 of 254 posts
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#92Earlier quoted context omitted.
Does this https://www.bing.com/videos/riverview/relatedvideo?q=Jacques... really sound like Jock to you? There is a significant sharp "æ" sound, the same as in Jack/dʒæk
It sounds like [a] to me, not [æ]. The a in the name Jacques is pronounced as in the word father . The a in the name Jack is pronounced as in cat.
As someone who has heard the name "Jack" pronounced by Americans many, many, many times in their life... that Jaques video sounds entirely in-range of the variety of pronunciations I hear for Jack.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#93I started using yq over jq. Any significant differences?
Which yq? I prefer https://github.com/mikefarah/yq to https://github.com/kislyuk/yq .
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#94Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.
Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such, which gives you 53 bits of precision for integers.
Also hey, been a while ;)
Edit: I stand corrected, the latest spec (rfc8259) only formally specifies the textual format, but not the semantics of numbers.
However, it does have this to say:
> This specification allows implementations to set limits on the range/and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
In practice, most implementations treat JSON as a subset of Javascript, which implies that numbers are 64-bit floats.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#95Congratulations! We're almost back to the basic functionality we used to have with XSLT.
To be fair, xslt is a lot more verbose than `map(.*2)`
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#96While jq is a very powerful tool, I've also been using DuckDB a lot lately. SQL is a much more natural language if the data is somewhat tabular.
I've found the same. I store all raw json output into a sqlite table, create virtual columns from it, then do a shell loop off of a select. Nested loops become unnested, and debugability is leagues better because I have the exact record in the db to examine and replay.
I've noticed what I'm creating are DAGs, and that I'm constantly restarting it from the last-successfully-proccessed record. Is there a `Make`-like tool to represent this? Make doesn't have sql targets, but full-featured dag processors like Airflow are way too heavyweight to glue together shell snippets.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#97Earlier 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.
I don't think many people would choose to start writing a new CLI in C++. That's just making things difficult for yourself.
There are some domains where I might still pick C++ over Rust - especially games and GUIs. The Rust ecosystem for those hasn't matched C++ yet.
But not for a CLI app. Especially one like this that doesn't have any difficult dependencies.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#98Regarding correctness, will it display uint64 numbers without truncating them? That's my biggest pet peeve with jq currently.
Unfortunately JSON numbers are 64 bit floats, so if you're standards compliant you have to treat them as such, which gives you 53 bits of precision for integers. Also hey, been a while ;) Edit: I stand corrected, the latest spec (rfc8259) only formally specifies the textual format, but not the semantics of numbers. However, it does have this to say: > This specification allows implementations to set limits on the ran…
JSON does not define a precision for numbers, so: it's often float64 (but note -0 is allowed, but NaN and +/-Inf are not), but it depends on your language, parser config, etc.
Many will produce higher precision but parse as float64 by default. But maximally-compatible JSON systems should always handle arbitrary precision.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#99It'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.
Nice find. I think I'll try it out. Although I was hoping for a real SQL type experience. I don't understand why no one just copies SQL so I can write a query like "SELECT * FROM $json WHERE x>1".
Everyone seems to want to invent their own new esoteric symbolic query language as if everything they do is a game of code golf. I really wish everyone would move away from this old Unix mentality of extremely concise, yet not-self-evident syntax and do more like the power shell way.
Re: Jaq – A jq clone focused on correctness, speed, and simplicity
#100It'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.
I can also recommend checking https://github.com/tidwall/jj