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

181–190 of 196 posts

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

#181

Post by boomlinde »

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.

fseek(3) etc, and using stat(2) to determine allocation sizes springs to mind as things you might want to do on a normal file that will not work as expected on a character device.

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

#182

Post by boomlinde »

derefr wrote: post #101
caymanjim wrote: post #77

Earlier quoted context omitted.

Much Unix software today is written by people who really don't appreciate or understand Unix. It leads to things like Homebrew (early on, at least) completely taking over and breaking /usr/local; to command-line utilities using a single dash (-) precending both short and long option names (granted, --long-opts is a GNUism, but it's a well-established standard); commands that output color by default even when the outp…

Tangent: Homebrew itself doesn’t really choose to take over /usr/local; rather, it just accepts that there exists POSIX software that is way too hard for most machines to compile, and so must be distributed precompiled; and yet where that precompilation implies a burning-in of an installation prefix at build time, which therefore cannot be customized at install time. And so that software must be compiled to assume so…

> and yet where that precompilation implies a burning-in of an installation prefix at build time

Not necessarily. Plenty of software uses relative paths that work regardless of prefix. Off the top of my head, Node.js is distributed in this way.

> you’d need to add that /usr/pkg directory to an unbounded number of little scripts here and there to make things truly work.

How so? Are there that many scripts that entirely replace the PATH environment variable? In Linux, I just include my system wide path additions in /etc/profile which will be set for every login. For things like cron jobs or service scripts, which don't inherit the environment of a login shell, you will need to source the profile or use absolute paths, but that's about the only caveat I can think of.

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

#183

Post by melbourne_mat »

vips7L wrote: post #105
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…

Don't forget powershell's Convert-FromJson :) https://docs.microsoft.com/en-us/powershell/module/microsoft...

That is so not jq! I've really been pining for jq on my current Windows project :-(

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

#184

Post by davesnx »

brundolf wrote: post #179

I'd love to hear some speculation - from the author or otherwise - as to why a fresh OCaml implementation would so dramatically outperform a mature C implementation

There are a few good asumtions about why is faster, there are just speculations since I didn't profile jq or query-json.

The feature that I think penalizes a lot jq is "def functions", the capacity of define any function that can be available during run-time.

This creates a few layers, one of the difference is the interpreter and the linker, the responsible for getting all the builtin functions and compile them have them ready to use at runtime.

The other pain point is the architecture of the operations on top of jq, since it's a stack based. In query-json it's a piped recursive operations.

Aside from the code, the OCaml stack, menhir has been proved to be really fast when creating those kind of compilers.

I will dig more into performance and try to profile both tools in order to improve mine.

Thanks

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

#187

Post by davesnx »

skywhopper wrote: post #163

This is cool, but I’m not sure it’s fair to claim it’s “faster” yet when it doesn’t do 95% of what jq does—-particularly the command line options. If it’s still faster when you can match 80% of the functionality, then it might be a claim worth making.

Exactly I didn't claim to be faster in all the cases, since there's no feature parity and I won't make it that way.

For the set of operations that I implement it it's faster, that's true.

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

#190

Post by davesnx »

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…

Thanks, next time if you paste the list somewhere else you can add query-json :P
Post reply on HN