JSON Lines support
Lassi Kortela
(21 Jan 2020 12:05 UTC)
|
||
Re: JSON Lines support
Amirouche Boubekki
(21 Jan 2020 15:00 UTC)
|
||
Re: JSON Lines support
Lassi Kortela
(21 Jan 2020 22:47 UTC)
|
||
Re: JSON Lines support
John Cowan
(21 Jan 2020 22:51 UTC)
|
||
Re: JSON Lines support Lassi Kortela (21 Jan 2020 23:07 UTC)
|
||
Re: JSON Lines support
John Cowan
(22 Jan 2020 00:11 UTC)
|
||
Pretty-printing JSON
Lassi Kortela
(22 Jan 2020 00:22 UTC)
|
||
Re: Pretty-printing JSON
John Cowan
(22 Jan 2020 02:28 UTC)
|
||
Different kinds of JSON writers, and naming them
Lassi Kortela
(22 Jan 2020 11:52 UTC)
|
||
Re: Different kinds of JSON writers, and naming them
John Cowan
(22 Jan 2020 18:37 UTC)
|
||
Re: Different kinds of JSON writers, and naming them
Lassi Kortela
(22 Jan 2020 22:33 UTC)
|
||
Re: Different kinds of JSON writers, and naming them
John Cowan
(22 Jan 2020 22:44 UTC)
|
||
Re: Different kinds of JSON writers, and naming them
Duy Nguyen
(23 Jan 2020 10:01 UTC)
|
||
Optional features in SRFIs
Lassi Kortela
(24 Jan 2020 15:30 UTC)
|
||
Re: Optional features in SRFIs
Lassi Kortela
(24 Jan 2020 15:35 UTC)
|
||
Re: Optional features in SRFIs
Arthur A. Gleckler
(24 Jan 2020 15:57 UTC)
|
||
Re: Optional features in SRFIs
John Cowan
(24 Jan 2020 17:01 UTC)
|
||
Re: Optional features in SRFIs
Lassi Kortela
(24 Jan 2020 17:07 UTC)
|
||
(missing)
|
||
Re: Optional features in SRFIs
Lassi Kortela
(24 Jan 2020 18:43 UTC)
|
||
Re: Optional features in SRFIs
Lassi Kortela
(24 Jan 2020 17:12 UTC)
|
> A JSON writer that doesn't prettyprint by adding additional whitespace > is automatically conforming to JSON Lines provided you call (newline > port) afterwards. Likewise, such a writer can be made to conform to > JSON Sequence by calling (write-char #\x001E port) before and (newline > port) after. I've actually used JSON Lines to write logs from an application, and having these concerns in mind is not enjoyable when you know your production log will be corrupted in case you didn't remember to take everything into account :) I'd rather call a standard procedure whose name says it is guaranteed to conform. But maybe that's just my quirks. > IMO prettyprinting should be done outboard anyway. Not sure what you mean exactly, but in practice, being able to jot down some data into a human-readable file by calling (write-pretty-json ...) is really useful. Standard support for sorted keys is great for the same reason, but it was covered in the other thread :) In general, most JSON dumps are not big enough that the extra whitespace or sorting are performance issues, and they can turn a human-unreadable file into a readable one. Truly large JSON dumps are often compressed with gzip or better anyway. I'm not sure whether or not it's better for the default output to be indented, but it's great if there's *some* easy-to-use procedure that indents and sorts, even if it's a different one, as long as it's standard. Pretty-printing options to the normal write procedure are also fine IMHO. Getting the pretty-printing wrong is not stressful in the way that writing potentially non-conforming data is.