jsonpp chokes on multiline input about jsonpp HOT 9 CLOSED

Known and allowed so that jsonpp can parse files containing newline separated json objects. See https://github.com/jmhodges/jsonpp/blob/master/data/multiple.json etc.

I could be convinced to add a flag to change this behavior if given a patch and a set of use cases that aren't exceedingly rare.

from jsonpp.

Actually, thinking on this again, we aren't going to support this. Newlines are not allowed in json objects and we're not going to fake that.

from jsonpp.

I'm confused: 7 months ago I took your assertion that newlines aren't allowed on faith, but today I came across this Stack Overflow question about whitespace in JSON.

Also, on json.org:

Whitespace can be inserted between any pair of tokens. Excepting a few encoding details, that completely describes the language.

So, if I may be so bold, please cite your sources or consider reopening this issue.

Also: Would it be feasible to use a more streaming-friendly json parser that would read its input until all its braces match, then stop reading and return the string?

• Objects need matching {}
• Arrays need matching []
• Strings need matching ""
• Numbers can't have whitespace
• All that's left are true, false and null, which also cannot have whitespace.

from jsonpp.

It looks like you are right. However, it would break the agreement that multi-line files can be parsed by jsonpp as multiple objects, which is inordinately useful for dealing with log lines of json objects. While additional work could be done to parse json objects arbitrarily, it's not worth my time.

Feel free to fork and submit a pull request.

from jsonpp.

Indeed, I see Go's json parser only takes byte arrays, not a Reader. Pity.

I totally respect this not being worth your time to implement. This could be a good place to dip my toes into Go for the first time.

This seems like a decent compromise. If you wouldn't mind answering a couple more questions: does this approach seem reasonable?

1. Read a line of input (and note which line number it is, for step 3).
2. Attempt to pretty-print it.
   • If there's a parse error, consider saving it for later error-reporting and go back to #1.
   • Otherwise, clear any saved-up error messages.
3. Repeat until the end of input, then print any saved-up error messages.

This should handle most cases except when there are 2 JSON objects that aren't newline-separated. It's not the most efficient approach for many-line objects, but it wouldn't be much worse than current behavior for currently-functioning inputs.

(Then again, it won't fail fast in the middle of your log file if a closing brace got dropped somehow.)

from jsonpp.

I just looked at this again, and I was right. Note that the "char" part of the grammar only shows up in the "string" context. This will not change.

from jsonpp.

I was surprised by the apparent clash between your answer (the "char" part of the sidebar grammar summary and "Whitespace can be inserted between any pair of tokens" in the body of that page, so I took at look at RFC 4627:

Insignificant whitespace is allowed before or after any of the six
structural characters.

 ws = *(
            %x20 /              ; Space
            %x09 /              ; Horizontal tab
            %x0A /              ; Line feed or New line
            %x0D                ; Carriage return
        )

The RFC also shows two example JSON objects that span multiple lines.

Then again, this is almost completely moot because neither of us are presently inclined to patch jsonpp. Fare thee well, sir.

from jsonpp.

A file containing a single newline at the end of the file doesn't contain two lines. It contains one line. cat, vim, and emacs get this right. Sublime Text, for example, gets this wrong.

bmamba:~ bat$ echo '{"a":1, "b": 2}' | cat -n
     1  {"a":1, "b": 2}
bmamba:~ bat$

I think this is valid input that jsonpp is rejecting.

from jsonpp.

It seems sort of silly to hold to the standard for json when at least one purpose of jsonpp is to create json with newlines in it.

from jsonpp.