peterohler

6 ms·

1.
by peterohler 4mo ago
Well, blog entry is still there at https://orbisappsec.com/blog/critical-buffer-overflow-in-ojs... but it is total nonsense and a hallucination.
2.
by peterohler 4mo ago
I was contacted by the submitter and they apologized and removed the blog entry. It was AI generated. It was nice to see they were upstanding enough to correct it. That's a plus in my book.
3.
False Security
5 points by peterohler 4mo ago|4 comments
4.
by peterohler 6mo ago
Another alternative is oj, https://github.com/ohler55/ojg . I don't know how the performance compares to jq or any others but it does use JSONPath as the query language. It has a few other options for making nicely
5.
by peterohler 6mo ago
I've been writing Lisp code off and one since the 80s. The standard for Common Lisp has to be sbcl but the REPL is pretty minimal. The available packages tend to be more limited than Go which I've been using a lot lately. I did fi
6.
by peterohler 8mo ago
Over the last 2 or 3 years I've been building a Common LISP implementation in Go so that Go packages can be utilized by LISP code. Building a REPL with lots of interactive features was rewarding as was taking up the challenges of the o
7.
by peterohler 9mo ago
Thanks for the help.
8.
Serious Lisp Written in Go(github.com)
10 points by peterohler 9mo ago|4 comments
9.
by peterohler 9mo ago
After several years of development here is a mostly Common LISP implementation written in Go with a REPL, CLOS, generics, Flavors, and much more.
10.
Discover JSON(github.com)
3 points by peterohler 10mo ago|1 comments
11.
by peterohler 11mo ago
If you prefer JSONPath as a query language, oj from https://github.com/ohler55/ojg provides that functionality. It can also be installed with brew. (disclaimer, I'm the author of OjG)
12.
by peterohler 1y ago
I'm clearly biased but oj which uses JSONPath is my preferred JSON manipulator. It can be installed with brew. It may not be for everyone but some of you might like it.
13.
by peterohler 2y ago
My experience is quite a bit different. Of course the examples I would use are more like what you might expect in real code. The comparison should be against code that calls a function that either returns and error and checks that error or
14.
by peterohler 2y ago
Merged. Didn't seem to make much difference though. Results for the original Oj parser are pretty close to the core json now. I'll have to update the README for Oj. It's a bit stale. The new Oj::Parser is still much faster if
15.
by peterohler 2y ago
If you would like to discuss separately on a call or chats I'd be up for that. Maybe kick around a few ideas.
16.
by peterohler 2y ago
I missed responding to your assertion that the Oj::Parser was not thread safe. An individual Oj::Parser instance is not thread safe just like other Ruby object such as a Hash but multiple Oj::Parser instances can be created in as many threa
17.
by peterohler 2y ago
Just so you know, I am impressed by the depth you've delved into with JSON parsing and dumping. It looks like a lot of time and effort went into the analysis.
18.
by peterohler 2y ago
The strict mode benchmarks for Oj are in the test/perf_strict.rb. Others are are in perf_*.rb. If callback parsing is not supported that's fine. Oj does support callback parsing as it allows elements in a JSON to be ignored. That
19.
by peterohler 2y ago
Using the benchmarks in the Oj test directory Oj has a slight advantage over the core json for dumping but not enough to make much difference. The comparison for Oj strict parsing compared to the core json is more substantial as 1.37 times
20.
by peterohler 2y ago
Oj author here. While it's flattering to have Oj be the standard to beat I'd like to point out that most of the issues with Oj revolve around the JSON gem and Rails doing a monkey patch dance and Oj trying to keep pace with the ch
21.
by peterohler 2y ago
There are a few more tolerant versions of JSON. In OjG I called the format SEN https://github.com/ohler55/ojg/blob/develop/sen.md
22.
by peterohler 3y ago
Very cool. I don't know if it's too much of an ask but could you adopt that to also work with OjG which uses JSONPath for instead of the jq syntax. I'd be glad to help if you are up for it. My apologies if I am out of line.
23.
by peterohler 3y ago
I found Jq to be difficult to use which is why Oj, https://github.com/ohler55/ojg is based on JSONPath. There still are a lot of options but it only takes a couple of help screens to figure out what the options are.
24.
by peterohler 3y ago
You might want to take a look at https://github.com/ohler55/ojg . It takes a different approach with a single pass parser. There are some performance benchmarks included on the README.md landing page.
25.
Oj Is on Tap(github.com)
2 points by peterohler 3y ago|1 comments
26.
by peterohler 3y ago
The Oj JSON parser and data extractor is now available on brew. The oj application is similar to jq but relies on JSONPath instead of the jq language. brew tap ohler55/tap brew install oj
27.
by peterohler 4y ago
For some specific cases simdjson might be the fastest but it does fare as well in other cases as seen here: https://github.com/ohler55/compare-go-json or here: https://github.com/ohler55/ojc/b
28.
by peterohler 4y ago
For me OjG ( https://github.com/ohler55/ojg ) has been great. I regularly use it on files that can not be loaded into memory. The best JSON file format for multiple record is one JSON document per record all in the same
29.
by peterohler 5y ago
Electric stoves are fine until the power goes out. With power issue in California it's nice to be able to cook a meal on the stove instead of resorting to a tiny camp stove.
30.
by peterohler 5y ago
Another alternative is the oj app (ojg/cmd/oj) which is part of https://github.com/ohler55/ojg . It relies on JSONPath for extraction and manipulation of JSON.

More ›