Hacker News: peterohler

New comment by peterohler in "False Security"

peterohler — Wed, 13 May 2026 17:29:11 +0000

Well, blog entry is still there at https://orbisappsec.com/blog/critical-buffer-overflow-in-ojs... but it is total nonsense and a hallucination.

New comment by peterohler in "False Security"

peterohler — Wed, 13 May 2026 15:17:58 +0000

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.

False Security

peterohler — Wed, 13 May 2026 12:51:05 +0000

I got bitten yesterday by a PR submitted by Orbis Security that was a one line change that actually did nothing but was used to trumpet what an amazing fix it was for a blog article which was also full of inaccuracies.

The PR was useful though as it show that the supposed fix was in a function that was never called. I removed it this morning.

The PR if anyone is interested is https://github.com/ohler55/oj/pull/1011

Comments URL: https://news.ycombinator.com/item?id=48121241

Points: 5

# Comments: 4

New comment by peterohler in "A Faster Alternative to Jq"

peterohler — Fri, 27 Mar 2026 12:17:57 +0000

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 formatted JSON and colorizing JSON.

New comment by peterohler in "Getting Started in Common Lisp"

peterohler — Tue, 10 Mar 2026 07:35:31 +0000

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 find a way to have a more functional REPL and also have access to all the Go packages by writing SLIP (https://github.com/ohler55/slip). Yes I know this is a plug for SLIP and if that offends anyone I apologize. The reasons mentioned for developing it are valid though and I've managed to use Lisp for almost all the data mining and processing tasks.

New comment by peterohler in "Ask HN: What are you working on? (January 2026)"

peterohler — Sun, 11 Jan 2026 23:14:54 +0000

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 object systems (CLOS and Flavors) and generics. Just open sourced it at the start of January. https://github.com/ohler55/slip

New comment by peterohler in "Serious Lisp Written in Go"

peterohler — Mon, 05 Jan 2026 22:40:17 +0000

Thanks for the help.

New comment by peterohler in "Serious Lisp Written in Go"

peterohler — Mon, 05 Jan 2026 22:29:54 +0000

After several years of development here is a mostly Common LISP implementation written in Go with a REPL, CLOS, generics, Flavors, and much more.

Serious Lisp Written in Go

peterohler — Mon, 05 Jan 2026 22:29:54 +0000

Article URL: https://github.com/ohler55/slip

Comments URL: https://news.ycombinator.com/item?id=46505993

Points: 10

# Comments: 4

Discover JSON

peterohler — Tue, 11 Nov 2025 14:31:33 +0000

Article URL: https://github.com/ohler55/ojg/blob/develop/discover.md

Comments URL: https://news.ycombinator.com/item?id=45887669

Points: 3

# Comments: 1

New comment by peterohler in "Show HN: JSON Query"

peterohler — Mon, 27 Oct 2025 18:59:39 +0000

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)

New comment by peterohler in "A Common Lisp jq replacement"

peterohler — Sat, 03 May 2025 12:23:21 +0000

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.

New comment by peterohler in "The cost of Go's panic and recover"

peterohler — Wed, 05 Mar 2025 03:19:05 +0000

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 one that panics and recovers. The overhead of returning the extra error and then the conditional used to check that error is more than a panic on error and recovery somewhere up the stack. This was not true in the early days of go but it is true today.

It really depends on the code being written. Try one approach then the other and see if it works better in your situation. For the example in the article there is really no need for an error check in the idiomatic case so why compare that to using panic. If there was an error to check the result would be much different.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 22:21:42 +0000

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 not restricted to the current Rails environment.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 22:02:05 +0000

If you would like to discuss separately on a call or chats I'd be up for that. Maybe kick around a few ideas.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 21:46:54 +0000

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 threads as desired. The reason each individual Oj::Parser is not thread safe is that it stores the parser state.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 21:31:40 +0000

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.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 21:30:18 +0000

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 save memory, GC, and performance. Your choice of course just as including callback parsers is a choice for Oj.

Ok, so you picked options that you knew would fail. Again you choice but there are certainly others that would trade a slight improvement in performance to not have 16+ significant digits. It's a choice. You are certainly entitled to you opinion but that doesn't mean everyone will share them.

I'm not sure what platform you are testing on but i'm sure there will be variations depending on the OS and the hardware. I tested on MacOS M1.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 19:46:56 +0000

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 faster. The benchmarks use a hash of mixed types included some nested elements.

The callback parsers (Saj and Scp) also show a performance advantage as does the most recent Oj::Parser.

As for the dumping of floats that are at the edge of precision (16 places), Oj does round to to 15 places if the last 4 of a 16 digit float is "0001" or "9999" if the float precision is not set to zero. That is intentional. If that is not the desired behavior and the Ruby conversion is preferred then setting the float precision to zero will not round. You picked the wrong options for your example.

I would like to say that the core json has a come a very long way since Oj was created and is now outstanding. If the JSON gem had started out where it is now I doubt I would have bothered writing Oj.

New comment by peterohler in "Optimizing Ruby's JSON, Part 4"

peterohler — Fri, 03 Jan 2025 15:01:15 +0000

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 changes. The Oj.mimic_JSON attempts to replace the JSON gem and only replaces the monkey patches made by that gem. The preferred approach for Oj outside of trying to mimic the JSON gem to to never monkey patch. That approach is used in all other modes that are not mimicking the JSON gem or Rails. I should point out that other Oj modes perform much better than the JSON gem and Rails modes.