Live data from Hacker News

Viewing profile — peterohler

peterohler

HN member
Joined
Sun, Apr 23, 2017, 3:53 PM UTC
HN karma
233
Public activity
97 items

About peterohler

C developer with projects with JSON, Ruby, Go, Graph databases, fast web server, and more. https://github.com/ohler55/oj https://github.com/ohler55/ox https://github.com/ohler55/ojc https://github.com/ohler55/ojg https://github.com/ohler55/agoo https://github.com/ohler55/agoo-c https://github.com/ohler55/graphql-test-tool

Recent public activity

  1. comment
    Comment #48124879

    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. comment
    Comment #48123077

    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…

  3. story
    False Security

    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 articl…

  4. comment
    Comment #47541799

    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 f…

  5. comment
    Comment #47320139

    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 th…

  6. comment
    Comment #46581517

    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…

  7. comment
    Comment #46506128

    Thanks for the help.

  8. comment
    Comment #46505994

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

  9. story
  10. story
  11. comment
    Comment #45724931

    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 O…

  12. comment
    Comment #43878583

    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. comment
    Comment #43262245

    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 func…

  14. comment
    Comment #42590081

    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 stal…

  15. comment
    Comment #42589900

    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. comment
    Comment #42589810

    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 m…

  17. comment
    Comment #42589697

    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. comment
    Comment #42589684

    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…

  19. comment
    Comment #42588838

    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 …

  20. comment
    Comment #42586205

    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 …

  21. comment
    Comment #42368931

    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. comment
    Comment #39761001

    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 u…

  23. comment
    Comment #38190733

    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 …

  24. comment
    Comment #38151212

    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 REA…

  25. comment
    Comment #37759028

    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 ins…