cl-json-devel

cl-json-devel@common-lisp.net

116 discussions

What's the status of this library?
by Robert Goldman 04 Mar '20

04 Mar '20

Does it have a maintainer currently? There are issues and merge requests on GitHub (https://github.com/hankhero/cl-json) that are just stuck. Should some fork take over the mantle of being "official"? Is there anyone who is willing to take this over? I'm not, sorry -- I have too many projects to manage already. If there *is* someone to take this over, maybe they could contact the folks at common-lisp.net to transfer ownership of the project page there, and add a pointer to the new GitHub repo.

1 0

Specifiy top-level json class in lisp
by Ernesto Alfonso 13 Oct '18

13 Oct '18

Hi, I find the concept of allowing the remote party to specify the lisp class/package into which a JSON object should be decoded interesting. I think it allows for objects at any nesting level to be decoded to the correct lisp class and can be powerful. In my opinion this also introduces some coupling of the internal service implementation, like class and package names, with the remote client. But it also requires control over the remote JSON object structure, which may work for a JS script that is owned by the same service, but doesn't seem to work for a third-party service API. In my case I'm trying to use cl-json to decode several types of third-party service API's objects, e.g. an oauth server's response, a geocoding response, etc, and I'd like for cl-json to decode the class for me, instead of either - doing a manual transformation for each object, - adding a json-to-class utility outside of cl-json, - pre-processing the JSON object to add the expected "prototype" fields before cl-json:decode, which seems like a hack Basically, I'd like to know if I can do something like: (cl-json:decode-json-from-source *stream* my-class) Is this possible in CL-JSON? I am also aware of JSON-MOP, but it currently doesn't support inherited class slots and I'd like to avoid introducing another dependency just to decode to my intended lisp object. Thanks, Ernesto

1 0

[cl-json-devel] Slot name with digits raise condition UNBOUND-SLOT
by Олег 23 Jan '13

23 Jan '13

Thanks, Boris. Олег.

1 0

[cl-json-devel] Slot name with digits raise condition UNBOUND-SLOT
by Олег 22 Jan '13

22 Jan '13

(json:with-decoder-simple-clos-semantics (let ((json:*json-symbols-package* nil)) (let ((x (json:decode-json-from-string "{\"foo1\": [1, 2, 3], \"bar1\": true, \"baz1\": \"!\"}"))) (with-slots (foo1 bar1 baz1) x (values x foo1 bar1 baz1))))) The slot FOO1 is unbound in the object #<#<JSON:FLUID-CLASS NIL {1004085F33}> {1003CAFB43}>. [Condition of type UNBOUND-SLOT] Олег.

2 1

[cl-json-devel] Achieving round-tripping for symbols with cl-json
by Dave Cooper 13 Jan '13

13 Jan '13

Hi All, Sorry if this has been covered, I am a bit late to the party on the mailing list here... anyway: is there a conventional way to achieve round-tripping of e.g. plists with cl-json? For example: CL-USER> (setq obj (list :|iid| NIL :|bashee| (list :|%rp%| NIL))) (:|iid| NIL :|bashee| (:|%rp%| NIL)) CL-USER> (json:encode-json-to-string obj) "[\"iid\",null,\"bashee\",[\"%rp%\",null]]" CL-USER> (json:decode-json-from-string (json:encode-json-to-string obj)) ("iid" NIL "bashee" ("%rp%" NIL)) At the end here, what I really want is the identical plist back: (:|iid| NIL :|bashee| (:|%rp%| NIL)) The CL-JSON documentation is clear that symbols in Lisp go to strings in JSON, which come back as strings in Lisp --- but is there any general, conventional technique people are using on top of this to preserve printable Lisp objects (mainly I'm talking about symbols here) through round-trips Lisp->JSON->Lisp? Up until now we have been using base64 encoding for this kind of thing: (base64-encode (format nil "~s" obj)) to get the Lisp stuff into a format for the web page which can be passed through e.g. as the parameter for an Ajax call, then (read-from-string (base64-decode ...)) back in Lisp to get it back and usable in Lisp. Putting everything into a base64 encoded string avoids problems with having to escape characters or other weirdness caused by strange characters which can confuse JavaScript. But this gets to be kind of cryptic (it makes the web page source code pretty much unreadable for humans), and I am learning that it starts failing for UTF-8 characters, etc, unless we are very careful about our base64 encoding. So I am hoping to standardize on JSON for this kind of thing, if there is a generally accepted way to do round-tripping. Plus I want to use json for scraping specific form-control values from a web page through Ajax (right now we have god-awful Javascript with all kinds of crazy character-escaping workarounds to do this). But I think that is another topic... Anyway am I barking up the wrong tree here trying to get round-tripping with cl-json? Regards, Dave -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

2 1

[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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-json-devel