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

JJ: JSON Stream Editor

github.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: JJ: JSON Stream Editor

#31

Post by Calzifer »

capableweb wrote: post #24
j1elo wrote: post #23

I'll take the chance to bring attention to the maintenance issues that 'jq' has been having in the last years [1]; there hasn't been a new release since 2018, which IMO wouldn't necessarily be a bad thing if not for the fact that the main branch has been collecting improvements and bug fixes [2] since then. A group of motivated users are currently talking about what direction to take; a fork is being considered in or…

What exactly is missing/broken in jq right now which warrants a fork? I've been using jq daily for years, and I can't remember the last time I hit a bug (must have been many years ago) and I can't recall any features I felt been missing for the years I've been using it. For me it's kind of done. It could be faster, but then I tend to program a solution myself instead, otherwise I feel like it's Done Enough.

What I miss from jq and what is implemented but unreleased is platform independent line delimiters.

jq on Windows produces \r\n terminated lines which can be annoying when used with Cygwin / MSYS2 / WSL. The '--binary' option to not convert line delimiters is one of those pending improvements.

https://github.com/stedolan/jq/commit/0dab2b18d73e561f511801...

Re: JJ: JSON Stream Editor

#32

Post by planede »

Rygian wrote: post #26

This behaviour looks confusing to me: $ echo '{"name":{"first":"Tom","middle":"null","last":"Smith"}}' | jj name.middle null $ echo '{"name":{"first":"Tom","last":"Smith"}}' | jj name.middle null It can be avoided with option '-r' which should be the default, but is not.

I don't get this behavior for your second command, it just seems to return an empty string.

edit:

There are three cases to cover:

1. The value at the path exists and not null.

2. The value at the path exists and is null.

3. The value at the path doesn't exist.

jj seems to potentially confuse 1 and 2 without the -r flag. "middle": "null" and "middle": null more specifically. It probably confuses "middle": "" and missing value as well, that's 1 and 3.

Re: JJ: JSON Stream Editor

#34

Post by j1elo »

capableweb wrote: post #24
j1elo wrote: post #23

I'll take the chance to bring attention to the maintenance issues that 'jq' has been having in the last years [1]; there hasn't been a new release since 2018, which IMO wouldn't necessarily be a bad thing if not for the fact that the main branch has been collecting improvements and bug fixes [2] since then. A group of motivated users are currently talking about what direction to take; a fork is being considered in or…

What exactly is missing/broken in jq right now which warrants a fork? I've been using jq daily for years, and I can't remember the last time I hit a bug (must have been many years ago) and I can't recall any features I felt been missing for the years I've been using it. For me it's kind of done. It could be faster, but then I tend to program a solution myself instead, otherwise I feel like it's Done Enough.

I wouldn't say I need the program to grow with more features, but at the bare minimum they should have been more diligent with cutting releases after accepting bug fixes, instead of letting those contributions langish on the main development branch out of reach for users.

I mean it would be understandable if the maintainers didn't have the time to keep working on it at all, but clearly the review work was done to accept some patches so why not make .point releases to allow the fixed code reach users via their distribution's channels?

Re: JJ: JSON Stream Editor

#35

Post by wvh »

I've been using the gjson (get) and sjson (set) libraries this is based on for many years in Go code to avoid deserialising JSON responses. Those libraries act on a byte array and can get only the value(s) you want without creating structs and other objects all over the place, giving you a speed bump and less allocations if all you need is a simple value. It's been working well.

This program could be an alternative to jq for simple uses.

Re: JJ: JSON Stream Editor

#36

Post by pdimitar »

AeroNotix wrote: post #27
lathiat wrote: post #7

Earlier quoted context omitted.

The limiting speed factor of jq for me is, by far, figuring out how to write the expression I need to parse a fairly small amount of data. I do a bunch of support analysis and often writing a one-liner to put into a shell script to extract some bit of JSON to re-use later in the script. Often this is going to be used only once by me or a customer to run some task. Followed closely by figuring out the path to the area…

emacs has a command to get the current path at point.

Which one is it exactly, please? I'd like to use it.

Re: JJ: JSON Stream Editor

#37

Post by untech »

notorandit wrote: post #33

Interesting. How often do you manipulate a 1+MB JSON file? Maybe I am wrong, but going from 0.01s to 0.001s doesn't motivate me to switch to jj.

Datasets are often stored in (sometimes gzipped) jsonlines format in my field (NLP). The file size could reach 100s of GBs.

Re: JJ: JSON Stream Editor

#39

Post by jjoonathan »

capableweb wrote: post #24
j1elo wrote: post #23

I'll take the chance to bring attention to the maintenance issues that 'jq' has been having in the last years [1]; there hasn't been a new release since 2018, which IMO wouldn't necessarily be a bad thing if not for the fact that the main branch has been collecting improvements and bug fixes [2] since then. A group of motivated users are currently talking about what direction to take; a fork is being considered in or…

What exactly is missing/broken in jq right now which warrants a fork? I've been using jq daily for years, and I can't remember the last time I hit a bug (must have been many years ago) and I can't recall any features I felt been missing for the years I've been using it. For me it's kind of done. It could be faster, but then I tend to program a solution myself instead, otherwise I feel like it's Done Enough.

> It could be faster

A decaffinated sloth could be faster.

Re: JJ: JSON Stream Editor

#40

Post by strunz »

capableweb wrote: post #24
j1elo wrote: post #23

I'll take the chance to bring attention to the maintenance issues that 'jq' has been having in the last years [1]; there hasn't been a new release since 2018, which IMO wouldn't necessarily be a bad thing if not for the fact that the main branch has been collecting improvements and bug fixes [2] since then. A group of motivated users are currently talking about what direction to take; a fork is being considered in or…

What exactly is missing/broken in jq right now which warrants a fork? I've been using jq daily for years, and I can't remember the last time I hit a bug (must have been many years ago) and I can't recall any features I felt been missing for the years I've been using it. For me it's kind of done. It could be faster, but then I tend to program a solution myself instead, otherwise I feel like it's Done Enough.

The README fir Jj points out how it is exponentially faster than jq. Presumably some of those improvements would help this.
Post reply on HN