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

Q: A faster re-implementaiton of jq written in Reason Native/OCaml

github.com

Post reply on HN
Print view View original

111–120 of 196 posts

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#111

Post by davesnx »

freedomben wrote: post #91
davesnx wrote: post #80

Earlier quoted context omitted.

Nothing that can be fixed later?

Thanks for this. I've been planning a similar work for years and haven't gotten off my ass (too many other projects lol). I definitely agree that reading from stdin is critical if I'll be able to use it. Don't take the criticism too hard though (especially the "author doesn't appreciate unix" stuff. Sometimes we can be such assholes to each other). Nice work!

I'm happy with the critics.

Judging is free and I didn't consider stdin as something to spend time on yet. Will do, now that some people raise it.

Thanks :D

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#112

Post by stingraycharles »

nondave wrote: post #107
toastal wrote: post #8

Are we sure it should get a single-letter 'q' binary name though? Docs seem to point that it's short for 'query-json'? Why not call it 'query-json' and let the user decide that as a shell alias or whatever. Even the ubiquitous 'ls' and 'cd' are two characters.

Also clashes with this existing q: https://en.m.wikipedia.org/wiki/Q_(programming_language_from...

Which is relatively established and widely used (although mainly in finance). It was the first thing I thought about.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#114

Post by diggan »

saagarjha wrote: post #108
diggan wrote: post #92

Earlier quoted context omitted.

1 is easy to work around (handy tip incoming for any tools that _seem_ to not support stdin but actually do, as stdin is also available as a file in unix): echo '{"foo": "bar"}' | query-json ".foo" /dev/stdin

Tools that accept filenames often expect you give them a real file, as they’ll do things on it that may not be supported by the various “it’s a file descriptor pretending to be something on disk” solutions.

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#115

Post by cristoperb »

aasasd wrote: post #82

For everyone pining for a Jq with a different syntax: I have a bunch of links to alternatives collected, you might want to try some of them (some may be for different things than JSON): https://github.com/fiatjaf/awesome-jq https://github.com/TomConlin/json2xpath https://github.com/antonmedv/fx https://github.com/fiatjaf/jiq https://github.com/simeji/jid https://github.com/jmespath/jp https://github.com/cube2222/jql…

My go-to for simple queries is https://github.com/tidwall/jj

It is not nearly as expressive as jq, but it is faster for my use cases (written in golang).

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#116

Post by specialist »

jakuboboza wrote: post #18

Do we need to make jq faster ? Anyone has issues with current speed ? Is there any specific reason other than "because we can" ?

Batting practice.

We'd all be better off if plebes grew their skills by reimplementing common tools.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#117

Post by ebg13 »

diggan wrote: post #114
saagarjha wrote: post #108

Earlier quoted context omitted.

Tools that accept filenames often expect you give them a real file, as they’ll do things on it that may not be supported by the various “it’s a file descriptor pretending to be something on disk” solutions.

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Anything that seeks, which you can't do on a pipe.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#118

Post by centimeter »

diggan wrote: post #114
saagarjha wrote: post #108

Earlier quoted context omitted.

Tools that accept filenames often expect you give them a real file, as they’ll do things on it that may not be supported by the various “it’s a file descriptor pretending to be something on disk” solutions.

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Seeking doesn’t work on stdin for example. Or mmapping, I imagine

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#119

Post by ogdrhr »

diggan wrote: post #114
saagarjha wrote: post #108

Earlier quoted context omitted.

Tools that accept filenames often expect you give them a real file, as they’ll do things on it that may not be supported by the various “it’s a file descriptor pretending to be something on disk” solutions.

Hm, do you have any examples handy? It's not that I don't believe you, it's just that in all the years I've been using this, it has always worked. Granted, I'm only using it for reading data, not for saving stuff to /dev/stdin, which would obviously fail.

Not the best example here, but try to open a file descriptor in VSCode. I had a scenario where I wanted to diff a file on two different servers with a user-specified diff tool, and certain ones won't even operate in a read-only manner.
Post reply on HN