November 2012 - cl-json-devel - mailman3.common-lisp.net

[cl-json-devel] cl-json depends on lisp reader?
by Sven Emtell 27 Nov '12

27 Nov '12

Hi everyone! I use cl-json with LispWorks 6.1. When delivering an app, I am trying to minimize the size of it by setting delivery level 5. The cl-json function "decode-json-from-string" does not seem to like this without explicitly keeping the Lisp Reader using the delivery keyword (:keep-lisp-reader). Since the Lisp Reader is unnecessary for the rest of the app, I would like to leave it out when delivering. Any thoughts on this? PS. I will also send a similar message to the LispWorks list, if that is more appropriate. Thanks! Sven Emtell

3 5

[cl-json-devel] Any objection to bumping the ASDF :version
by Robert Goldman 18 Nov '12

18 Nov '12

The new version of CL-JSON offers a READ-free version of the library. Since there was interest in this for shipping compiler-free executables, maybe we should make it detectable in ASDF dependencies. I'd propose either bumping to 0.4.3 (patchlevel) or, since this feature is persistent, we might want to bump to 0.5.0 The latter would permit people who want the READ-free version of the library to require (:version cl-json 0.5) in their dependencies. Also, how about we add tags to the repo for releases? Cheers, r

2 1

[cl-json-devel] Any interest in moving from darcs to git?
by Robert Goldman 13 Nov '12

13 Nov '12

I have had some unpleasant issues with darcs working on cl-json, and I find that working with it is very badly hampered by its lack of mindshare compared with other DVCSes. In particular: 1. The darcs maintainers are unable to supply binaries for Mac OSX. 2. No one has stepped up to the plate to provide a graphical UI for working with darcs. Not only are these a nuisance in and of themselves (the former especially, since darcs does not build on an out-of-the-box install of the Haskell Platform), they are the signs of a tool that does not have an adequately robust support community. Combine this with the oddity of the usage model, compared with other DCVSes,[1] and you have real problems. I am not volunteering to maintain CL-JSON, so it is ultimately not up to me. But I have submitted a number of patches, so I feel that I have standing at least to offer the suggestion. Note that I don't think that darcs, in and of itself, is a bad system. But there are more than enough DCVSes out there, and we can use one less of them. Best regards, Robert [1] See, for example: http://darcs.net/FAQ#how-do-i-go-back-to-an-older-version-of-my-repository

3 5

[cl-json-devel] darcs patch: fix-fiveam-test-comparisons (and 1 more)
by rpgoldman＠sift.info 05 Nov '12

05 Nov '12

2 patches for repository http://common-lisp.net/project/cl-json/darcs/cl-json: Sun Nov 4 15:49:32 CST 2012 rpgoldman(a)sift.info * fix-fiveam-test-comparisons FiveAM would like the expected value to be before the computed value, for best printing when tests fail. I reversed the arguments to the JSON-NUMBER test to agree with this convention. Sun Nov 4 15:52:54 CST 2012 rpgoldman(a)sift.info * remove-read-from-string-from-parse-number PARSE-NUMBER used to use READ-FROM-STRING. This was causing problems with some application-building systems. We replace use of the reader (through read-from-string) by PARSE-NUMBER.

3 3

[cl-json-devel] darcs patch: fix-fiveam-test-comparisons (and 1 more)
by rpgoldman＠sift.info 05 Nov '12

05 Nov '12

2 patches for repository http://common-lisp.net/project/cl-json/darcs/cl-json: Sun Nov 4 15:49:32 CST 2012 rpgoldman(a)sift.info * fix-fiveam-test-comparisons FiveAM would like the expected value to be before the computed value, for best printing when tests fail. I reversed the arguments to the JSON-NUMBER test to agree with this convention. Sun Nov 4 15:52:54 CST 2012 rpgoldman(a)sift.info * remove-read-from-string-from-parse-number PARSE-NUMBER used to use READ-FROM-STRING. This was causing problems with some application-building systems. We replace use of the reader (through read-from-string) by PARSE-NUMBER.

1 0