From henrik at evahjelte.com Sun Aug 3 20:14:01 2008 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 3 Aug 2008 22:14:01 +0200 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> Message-ID: <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> On Wed, Jul 23, 2008 at 7:32 PM, Boris Smilga wrote: > ?3. This suggests a design similar in spirit to SAX, with a set of > handlers triggered by "events". I like your idea, it will make cl-json very configurable. You are on the spot on the requirements list in my opinion. Here are some thoughts: 1. There will be a lot of variables for the callback functions. Some may say it is ugly. But: if we can encapsule them with a function to set them all, I think it is OK. The alternative is probably to implement this OO style with what I think they call the "strategy" pattern, but I don't think it is obviously prettier and the performance will probably be a little bit worse. 2. I think the A (Accumulator) version seems to be good, and If it has other advantages as you write, I think we should go for it. 3. Will you do it, or should we just put it on the TODO list until someone wants to do it? By the way, some things that I might want to do if we should release a new version: * remove the parenscript dependency. * add a little sample implementation of JSONP Any other wishes? /Henrik Hjelte From hans at huebner.org Sun Aug 3 23:58:46 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 3 Aug 2008 18:58:46 -0500 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> Message-ID: On Sun, Aug 3, 2008 at 15:14, Henrik Hjelte wrote: > Any other wishes? I don't quite like the serialization mechanism that cl-json provides. The attempt to map from a Lisp datatype to a certain json structure is necessarily imperfect because no 1:1 relationship exists, and the requirement to first make up a data structure and then call encode-json to convert it to a json string is wasteful. A streaming serialization API is more useful, as one has more control over the json format that is being generated and the need to make up a data structure that can uniquely be mapped to json structures is removed. It is inspired by CXML's streaming serialization which I find very easy and straightforward to use. I have written something that allows my application code to use a similar scheme, see http://bknr.net/trac/browser/trunk/projects/quickhoney/src/handlers.lisp?rev=3723#L437 - The implementation of the json serializer is in http://bknr.net/trac/browser/trunk/projects/quickhoney/src/json.lisp, but it is kind of hackish because it tries to reuse some of cl-json's serialization facilities for atomic types and jumps some hoops to make the correct separators between serialized elements be generated. This could certainly be improved, yet it works for me and I'd be glad to see this or a similar mechanism be integrated into cl-json. -Hans From henrik at evahjelte.com Mon Aug 4 10:47:36 2008 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 4 Aug 2008 12:47:36 +0200 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> Message-ID: <50e8e4f60808040347g1915238fn689fc1f6c253d3f5@mail.gmail.com> On Mon, Aug 4, 2008 at 1:58 AM, Hans H?bner wrote: > I don't quite like the serialization mechanism that cl-json provides. > The attempt to map from a Lisp datatype to a certain json structure is > necessarily imperfect because no 1:1 relationship exists, and the > requirement to first make up a data structure and then call > encode-json to convert it to a json string is wasteful. In principle yes. But to defend the current way, it make a clear division of concerns, separating the code for formating output from the code for logic. > > A streaming serialization API is more useful, as one has more control > over the json format that is being generated and the need to make up a > data structure that can uniquely be mapped to json structures is > removed. I agree to a large degree, but in many situations it is nice to have a simple to use format and API. What is simple is of course up to debate. But in the sample below, I think cl-jsons current encoder could save some code lines. But, why not have both, I am sure there are lots of situations were your idea will be better? In a way this is the reverse situation of the decoder issue that Boris has. > It is inspired by CXML's streaming serialization which I > find very easy and straightforward to use. It is the SAX thing that is used for serailization that is the inspiration? CXML also has a klacks parser which is inspired from the Java Streaming XML API, and I know there is a project jettison that implements JSON for this API. A cool feature would be if a json parser/serializer could be used as a simple drop in replacement for an existing xml parser/geneneratior, there are a few to choose from. > This could certainly be improved, yet it works for me I haven't looked much at the internals, but the API seems very good from the example below. > and I'd be glad > to see this or a similar mechanism be integrated into cl-json. > I agree, I think we should do something along your lines in cl-json. But I also want to preserve the current simple interface. /Henrik This is a neat sample from your code. ;;------------------------------------------------------------------------------ (defmethod handle-object ((handler json-news-archive-handler) (channel rss-channel)) (with-json-response () (with-object-element ("months") (with-json-array () (dolist (month (sort (rss-channel-archived-months channel) (lambda (a b) (if (= (first a) (first b)) (> (second a) (second b)) (> (first a) (first b)))))) (with-json-array () (encode-array-element (first month)) (encode-array-element (second month)))))))) ;;------------------------------------------------------------------------------ ;; If I am not wrong, this is how it would look in the ;; current cl-json implementation. (defmethod handle-object ((handler json-news-archive-handler) (channel rss-channel)) (encode-json-response ;; or similar (with-object-element ("months") (sort (rss-channel-archived-months channel) (lambda (a b) (if (= (first a) (first b)) (> (second a) (second b)) (> (first a) (first b)))))))) From hans at huebner.org Mon Aug 4 12:48:46 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 4 Aug 2008 07:48:46 -0500 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: <50e8e4f60808040347g1915238fn689fc1f6c253d3f5@mail.gmail.com> References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> <50e8e4f60808040347g1915238fn689fc1f6c253d3f5@mail.gmail.com> Message-ID: On Mon, Aug 4, 2008 at 05:47, Henrik Hjelte wrote: > On Mon, Aug 4, 2008 at 1:58 AM, Hans H?bner wrote: > >> I don't quite like the serialization mechanism that cl-json provides. >> The attempt to map from a Lisp datatype to a certain json structure is >> necessarily imperfect because no 1:1 relationship exists, and the >> requirement to first make up a data structure and then call >> encode-json to convert it to a json string is wasteful. > > In principle yes. But to defend the current way, it make a clear division of > concerns, separating the code for formating output from the code for logic. I don't quite understand what you mean by that. My concern with the current mechanism is that it is not transparent: As there is no 1:1 mapping between native Lisp datatypes and json structures, the application needs to be aware of the desired JSON structure format anyway. One would have to have kind of a "JSON Schema" that is external to the application and describes the format in an abstract way if one really wanted to keep the format specification outside of the application code. I am not sure if that would be the right direction, though. The idea of JSON is to keep things simple. >> A streaming serialization API is more useful, as one has more control >> over the json format that is being generated and the need to make up a >> data structure that can uniquely be mapped to json structures is >> removed. > > I agree to a large degree, but in many situations it is nice to > have a simple to use format and API. What is simple is of course up > to debate. But in the sample below, I think cl-jsons current encoder > could save some code lines. But, why not have both, I am sure > there are lots of situations were your idea will be better? I am not advocating that the current API should be removed. I just don't like it and would have to have more control over the format without having to first create a data structure that accidentially serializes to what I want to have. Even with a specially crafted structure, I would have to make explicit calls to specialized JSON functions to select how I want lists to be serialized. A streaming API would be unambiguous in that respect, as it does not iterate over data structures itself. I am a big fan of saving code lines, but in general, terseness can't overrule correctness and ambiguity should be avoided. > In a way this is the reverse situation of the decoder issue that Boris > has. > >> It is inspired by CXML's streaming serialization which I >> find very easy and straightforward to use. > > It is the SAX thing that is used for serailization that is the inspiration? > CXML also has a klacks parser which is inspired from the Java > Streaming XML API, and I know there is a project jettison that > implements JSON for this API. The CXML XML serializer is inspired by SAX. > A cool feature would be if a json parser/serializer could be used as a > simple drop in replacement for an existing xml parser/geneneratior, > there are a few to choose from. I'm not sure if you would not end up with a half-baked solution that works either inefficient or restricts both the XML schemata and JSON structures that you can create interchangeably. I would leave such a plug-compatible layer up to the application programmer to write, if desired. > ;;------------------------------------------------------------------------------ > (defmethod handle-object ((handler json-news-archive-handler) > (channel rss-channel)) > (with-json-response () > (with-object-element ("months") > (with-json-array () > (dolist (month (sort (rss-channel-archived-months channel) > (lambda (a b) > (if (= (first a) (first b)) > (> (second a) (second b)) > (> (first a) (first b)))))) > (with-json-array () > (encode-array-element (first month)) > (encode-array-element (second month)))))))) > > ;;------------------------------------------------------------------------------ > ;; If I am not wrong, this is how it would look in the > ;; current cl-json implementation. > > (defmethod handle-object ((handler json-news-archive-handler) > (channel rss-channel)) > (encode-json-response ;; or similar > (with-object-element ("months") > (sort (rss-channel-archived-months channel) > (lambda (a b) > (if (= (first a) (first b)) > (> (second a) (second b)) > (> (first a) (first b)))))))) I am not sure how an ENCODE-JSON-RESPONSE function would decide whether a list should be serialized as an object or as an array. This is the basic problem that the streaming API solves. I think that no ENCODE-JSON-RESPONSE function exists that matches the requirements of every application, and as such it would be better to provide the building blocks that can be used to universally generate any JSON format that exists. -Hans From boris.smilga at gmail.com Wed Aug 6 23:51:41 2008 From: boris.smilga at gmail.com (Boris Smilga) Date: Thu, 7 Aug 2008 03:51:41 +0400 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> <50e8e4f60808031314m7fbe75cdt78d47ef046cf8b06@mail.gmail.com> Message-ID: <8F280010-A1A7-4BA9-BB5C-A12E2EE293CF@gmail.com> On 4 Aug 2008, at 00:14, Henrik Hjelte wrote: > I like your idea, it will make cl-json very configurable. You are on > the spot on the requirements list in my opinion. Here are some > thoughts: > > 1. There will be a lot of variables for the callback functions. Some > may say it is ugly. > > But: if we can encapsule them with a function to set them all, I > think it is OK. Absolutely. I would say, something like: (defun set-handlers (&key boolean integer float start-string string-char end-string start-array array-element end-array start-object object-key object-element end-object) (setf *boolean-handler* boolean *integer-handler* integer #| the same for other handlers |# )) > The alternative is probably to implement this OO style with what I > think > they call the "strategy" pattern, but I don't think it is obviously > prettier > and the performance will probably be a little bit worse. Do you mean, along the lines of (defclass json-parser () ((boolean-handler :accessor boolean-handler :initarg :boolean :type function :allocation :class) #| more handler slots |# )) with specific parser semantics being subclasses of the same? > 2. I think the A (Accumulator) version seems to be good, and If it has > other advantages as you write, I think we should go for it. Actually, I rather prefer B, which is cleaner, though, probably, worse performing. I think I'm going to implement both and run some heavy workload tests to see how bad the regression could be, and then we'll decide. > 3. Will you do it, or should we just put it on the TODO list until > someone wants to do it? I'll do it. It's not that much work. For the time being, let's keep things in a separate file (or even two of them, for the two options of devolving information). We'll then copy over the better one into decoder.lisp and discard the other one. > By the way, some things that I might want to do if we should release a > new version: > * remove the parenscript dependency. The only feature of parenscript used by cl-json is the function SYMBOL-TO-JS. I can, of course, substitute my own implementation. > * add a little sample implementation of JSONP This, in my best judgement, is not the most urgent priority, and can be easily added after improving the encoder (e.g. in the way that Hans argues for). Sincerely, - B.Sm. From boris.smilga at gmail.com Wed Aug 20 00:57:21 2008 From: boris.smilga at gmail.com (Boris Smilga) Date: Wed, 20 Aug 2008 04:57:21 +0400 Subject: [cl-json-devel] Re: proposed: improvements to encoder (was: decoder) customization In-Reply-To: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> Message-ID: Now, as to what Hans has proposed regarding the encoder. I completely side with his idea of a streaming API. Currently, the only possible means of customization is to add methods to the ENCODE-JSON generic function. This is, obviously, not very good, because (a) the GF eventually gets cluttered by multitude obscure heterogenous methods; (b) it is not possible to have different encoding strategies for one and the same data type; (c) the library really adds no value, as the technicalities of JSON syntax still have to be dealt with inside the new method. I have to admit I don't quite understand Henrik's objections against the proposal. As far as I see, there is no conflict at all between that and the current simple API, as the latter can be absolutely gracefully reimplemented on top of the former. E.g., instead of (defmethod encode-json ((s sequence) stream) (with-sequence-iterator (generator s) (write-json-array generator stream))) we could write something like (defmethod encode-json ((s sequence) stream) (with-json-array (:stream stream) (map nil #'encode-array-element s))) The user of the library is, of course, free to write his own encoder specialized for his own classes, as nothing prevents him from calling encode-json in his default method, e.g.: (defmethod my-own-encode-json ((obj my-class) stream) (with-json-object (:stream stream) (with-object-element ("initial") (my-own-encode-json (get-value-for-initial-field obj) stream)) (with-object-element ("subsequent") (my-own-encode-json (get-value-for-subsequent-field obj) stream)))) (defmethod my-own-encode-json ((value t) stream) (encode-json value stream)) CL-JSON can very well provide some syntactic sugar for objects, along the lines of: (defmacro with-json-object-for-fields ((field (&rest fields) &key stream) &body body) `(with-json-object (:stream stream) ,@(loop for (name getter) in fields collect `(with-object-element (,name) (let ((,field ,getter)) , at body))))) Which allows us to rewrite the method above as (defmethod my-own-encode-json ((obj my-class) stream) (with-json-object-for-slots (slot (("initial" (get-value-for-initial-field obj)) ("subsequent" (get-value-for-subsequent-field obj))) :stream stream) (my-own-encode-json slot stream))) This kind of encoder transparency shall make for a natural and useful counterpart to decoder customizability. Sincerely, - B. Smilga. P.S. I was thinking about a customizable encoder myself, but only came up with a very clumsy idea of exporting WRITE-JSON-OBJECT and WRITE-JSON-ARRAY, and having their GENERATOR-FN arguments return callbacks where customized encoding is needed. We would have (defmethod encode-json ((fn function) stream) (funcall fn stream)) and then use that in the following manner: (defmethod my-own-encode-json ((obj my-class) stream) (write-json-object (make-my-class-iterator obj) stream)) (defun make-my-class-iterator (obj) (let ((state :initial)) (lambda () (ecase state (:initial (setq state :subsequent) (values t :initial-field (lambda (stream) ; a callback (my-own-encode-json (get-value-for-initial-field obj) stream)))) (:subsequent (setq state :final) (values t :subsequent-field (lambda (stream) ; another one (my-own-encode-json (get-value-for-subsequent-field obj) stream)))) (:final nil))))) Compared to Hans's approach, mine is just an insult to good taste and common sense. From boris.smilga at gmail.com Wed Aug 20 01:00:58 2008 From: boris.smilga at gmail.com (Boris Smilga) Date: Wed, 20 Aug 2008 05:00:58 +0400 Subject: [cl-json-devel] proposed: improvements to decoder customization References: Message-ID: <9012CD50-21C1-4A4C-905D-CFEF50190A5A@gmail.com> On 7 Aug 2008, at 03:51, Boris Smilga wrote: > On 4 Aug 2008, at 00:14, Henrik Hjelte wrote: >> 2. I think the A (Accumulator) version seems to be good, and If it >> has >> other advantages as you write, I think we should go for it. > > Actually, I rather prefer B, which is cleaner, though, probably, worse > performing. I think I'm going to implement both and run some heavy > workload tests to see how bad the regression could be, and then we'll > decide. Please find attached a patch bundle with the implementation of the decoder in two flavours: with extra arguments and with dynamic json-structure-scope variables. They are in two separate files, with much code overlap between the two. So let us choose which one we eventually want. The workload tests were done as follows. First, I generated a random huge json file (see the code in the attached file random-json.lisp; the output was generated by running (with-open-file (s #p"test.in" :direction :output) (generate-random-json s 120)) which yielded some 214 KB of json data, with maximum depth of nesting 21). The contents of the file was then fed to DECODE-JSON under different setups, by running (with-open-file (s #p"test.in") (time (decode-json s))) NB: To get comparable results for CLOS semantics, I had to reboot Lisp between tests. This is because implementations usually employ optimizations geared toward stable CLOS-style classes. With the kind of transient classes that we create from prototypeless JSON objects the optimizations actually can cause performance to degrade, sometimes severely. See my exchange with Gary Byers from Clozure on the openmcl-devel mailing list: http://clozure.com/pipermail/openmcl-devel/2008-August/008458.html, http://clozure.com/pipermail/openmcl-devel/2008-August/008463.html. Hence, now that we have a customizable decoder, I would either scrape transient classes altogether, substituting some default prototype (e.g. {"lispClass":"cons"}, or some wrapper around alists, as in st-json), or else post big notices in red letters: ?Thou Shalt Not Omit Prototypes? all over the place. The test results are thus: Clozure CL v. 1.2 RC1 (DarwinPPC32) on 1.5 GHz PowerBook G4 with 1.25 GB RAM. List semantics: With the extra-args approach: 1.442 sec. run time, 10,209,120 bytes allocated. With the dynamic-vars approach: 1.571 sec. run time, 12,317,928 bytes allocated. CLOS semantics: Extra-args: 10.870 sec. run time, 34,559,256 bytes allocated. Dynamic-vars: 10.961 sec. run time, 34,972,216 bytes allocated. ************ SBCL 1.0.18 on the same. List semantics: Extra-args: 1.163 sec. run time, 18,111,072 bytes allocated. Dynamic-vars: 1.218 sec. run time, 18,407,344 bytes allocated. CLOS semantics: Extra-args: 7.193 sec. run time, 96,173,152 bytes allocated. Dynamic-vars: 7.451 sec. run time, 96,767,968 bytes allocated. ************ CLisp 2.40 on the same: List semantics: Extra-args: 1.351 sec. run time, 8,328,464 bytes allocated. Dynamic-vars: 1.406 sec. run time, 8,447,900 bytes allocated. CLOS semantics: Extra-args: 9.057 sec. run time, 28,362,544 bytes allocated. Dynamic-vars: 9.112 sec. run time, 28,775,504 bytes allocated. ************ SBCL 1.0.17 on 2 GHz AMD 64 3000+ with 512 MB RAM. List semantics: Extra-args: 0.472 sec. run time, 19,891,336 bytes allocated. Dynamic-vars: 0.471 sec. run time, 20,187,112 bytes allocated. CLOS semantics: Extra-args: 2.171 sec. run time, 80,166,760 bytes allocated. Dynamic-vars: 2.180 sec. run time, 80,724,960 bytes allocated. I would say that the regression is fairly benign, never more than 9% run time and 20% memory, on average 2% run time and 4% memory. I allow myself once again to state my preference for the dynamic-vars approach, which has a much cleaner interface. Cleaner?especially so as the elaborate passing-around of handler states could be done away with altogether and replaced by handler-side changing of the state of dynamic variables. The implementation of the two simple semantics in decoder-vars.lisp illustrates this point: a beginning-of-structure handler initializes the variables *ACCUMULATOR* and *ACCUMULATOR-LAST*, and structure-element handlers imperatively modify their state. As the variables have json-structure scope, sub-structures cannot clobber their parent structures' accumulators. There were two more important sets of changes. Firstly, the basic json reader was redesigned to work in terms of tokens. A token is either a number literal, a symbol, or a punctuation mark (string characters and escape sequences can be seen as tokens as well). This modularizes the design into a lower-level tokenizer part and a higher-level decoder part. Secondly, I have substituted my own version of CAMEL-CASE-TO-LISP to handle conventions like "JSONAllCapitals" (? "+JSON+-ALL-CAPITALS"), "TWO_WORDS" (? "+TWO-WORDS+"), and "camelCase_mixed_4_PARTS" (? "CAMEL-CASE--MIXED--+4-PARTS+"). Sincerely, - B. Smilga. -------------- next part -------------- A non-text attachment was scrubbed... Name: two-falvours-of-new-decoder.dpatch.gz Type: application/x-gzip Size: 7716 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: random-json.lisp Type: application/octet-stream Size: 1923 bytes Desc: not available URL: -------------- next part -------------- From henrik at evahjelte.com Sun Aug 24 20:34:11 2008 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 24 Aug 2008 22:34:11 +0200 Subject: [cl-json-devel] proposed: improvements to decoder customization In-Reply-To: <9012CD50-21C1-4A4C-905D-CFEF50190A5A@gmail.com> References: <9012CD50-21C1-4A4C-905D-CFEF50190A5A@gmail.com> Message-ID: <50e8e4f60808241334k65aa816ncc63d64141601716@mail.gmail.com> 2008/8/20 Boris Smilga : > On 7 Aug 2008, at 03:51, Boris Smilga wrote: > Please find attached a patch bundle with the implementation of > the decoder in two flavours: with extra arguments and with > dynamic json-structure-scope variables. They are in two separate > files, with much code overlap between the two. So let us choose > which one we eventually want Sorry for a late response, I just tried to apply these, but you must have forgotten a patch: darcs apply two-falvours-of-new-decoder.dpatch darcs: Cannot apply this patch bundle, since we're missing: Wed Jul 23 18:39:16 CEST 2008 Boris Smilga * Added some test cases for decoder CLOS semantics and prototypes. But it seems great ! /Henrik From henrik at evahjelte.com Sun Aug 24 21:28:30 2008 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 24 Aug 2008 23:28:30 +0200 Subject: [cl-json-devel] Re: proposed: improvements to encoder (was: decoder) customization In-Reply-To: References: <30B0F7B1-A050-4433-B2B0-63F56840A60F@gmail.com> Message-ID: <50e8e4f60808241428k177fdf3euce5e45200d9e9796@mail.gmail.com> On Wed, Aug 20, 2008 at 2:57 AM, Boris Smilga wrote: > Now, as to what Hans has proposed regarding the encoder. I > completely side with his idea of a streaming API. > > I have to admit I don't quite understand Henrik's objections > against the proposal. I really don't have any objections against it, I think it is good. The only thing is that I also want to preserve the old way, since it suits me fine. > As far as I see, there is no conflict at > all between that and the current simple API, as the latter can be > absolutely gracefully reimplemented on top of the former. Great, thanks for clarifying that. /Henrik From srinu.kadem at gmail.com Mon Aug 25 12:04:57 2008 From: srinu.kadem at gmail.com (srinivasa reddy kadem) Date: Mon, 25 Aug 2008 08:04:57 -0400 Subject: [cl-json-devel] usage of cl-json Message-ID: <7ccbb6aa0808250504q1a772216qbfe0380755dbaece@mail.gmail.com> Already we are using cl-json in our product development, I'm not sure which version we are using now. But it is belongs to old source code(I think it is downloaded very long back). Our team did some customization in the source code which meet our requirements. I want to update this into newer versions. Please let me know how to use it and where I can download latest version of cl-json.In what way it should be embedded it into our application. Let me know you need any further clarification. Anybody please help me or give suggestions. -- Thanks, Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik at evahjelte.com Mon Aug 25 21:57:12 2008 From: henrik at evahjelte.com (Henrik Hjelte) Date: Mon, 25 Aug 2008 23:57:12 +0200 Subject: [cl-json-devel] usage of cl-json In-Reply-To: <7ccbb6aa0808250504q1a772216qbfe0380755dbaece@mail.gmail.com> References: <7ccbb6aa0808250504q1a772216qbfe0380755dbaece@mail.gmail.com> Message-ID: <50e8e4f60808251457i591ce5e2ve3ad1b7ccd0bd5bb@mail.gmail.com> On Mon, Aug 25, 2008 at 2:04 PM, srinivasa reddy kadem wrote: > > Already we are using cl-json in our product development, I'm not sure which > version we are using now. But it is belongs to old source code(I think it is > downloaded very long back). Actually, not very much has changed since the first version. > > Our team did some customization in the source code which meet our > requirements. I want to update this into newer versions. Darcs is great if you want to move patches between versions. I get curious, isn't this something you want to share with us? I am interested, what are the cusomizations, is it related to the current discussion on a new interface? > > Please let me know how to use it See the testcases for examples and where I can download latest version of > cl-json.In what way it should be embedded it into our application. That information is on the project site, http://common-lisp.net/projects/cl-json Is it unclear? There are a few releases, and a darcs repo. The darcs repo contains newer things, it is usually very stable but you never know. The last days I added some new patches, and we will add new patches the coming months, see the discussion on this mailing list about an new interface which means you will be able to control how cl-json maps to lisp in more detail. This might make the darcs repo a bit more unstable for a while. > > Let me know you need any further clarification. And vice versa. /Henrik From srinu.kadem at gmail.com Tue Aug 26 10:00:53 2008 From: srinu.kadem at gmail.com (srinivasa reddy kadem) Date: Tue, 26 Aug 2008 06:00:53 -0400 Subject: [cl-json-devel] usage of cl-json In-Reply-To: <50e8e4f60808251457i591ce5e2ve3ad1b7ccd0bd5bb@mail.gmail.com> References: <7ccbb6aa0808250504q1a772216qbfe0380755dbaece@mail.gmail.com> <50e8e4f60808251457i591ce5e2ve3ad1b7ccd0bd5bb@mail.gmail.com> Message-ID: <7ccbb6aa0808260300v49a1dad0tcaca80035bf57f1b@mail.gmail.com> On Mon, Aug 25, 2008 at 2:04 PM, srinivasa reddy kadem wrote: > > Already we are using cl-json in our product development, I'm not sure which > version we are using now. But it is belongs to old source code(I think it is > downloaded very long back). Actually, not very much has changed since the first version. I compared our existing json code with latest json (cl-json_0.3.1). I'm not found any major differences. For me it seems to be fine to use older version of cl-json. > > Our team did some customization in the source code which meet our > requirements. I want to update this into newer versions. Darcs is great if you want to move patches between versions. I get curious, isn't this something you want to share with us? I am interested, what are the cusomizations, is it related to the current discussion on a new interface? Once Darcs is stable or I'm comport and able to integrate this to our application, we'll start to embed Darcs. Our changes are not related to current discussions on a new interface. We customized some functions which will best suite our application. Even these changes are very minimal. > > Please let me know how to use it See the testcases for examples Right now I'm going through the test cases and sample examples provided along with the software. example test cases and others are simply superb and very useful. and where I can download latest version of > cl-json.In what way it should be embedded it into our application. That information is on the project site, http://common-lisp.net/projects/cl-json Is it unclear? There are a few releases, and a darcs repo. The darcs repo contains newer things, it is usually very stable but you never know. The last days I added some new patches, and we will add new patches the coming months, see the discussion on this mailing list about an new interface which means you will be able to control how cl-json maps to lisp in more detail. This might make the darcs repo a bit more unstable for a while. > > Let me know you need any further clarification. And vice versa. How can I participate in the development of Darcs and where to download it. /Henrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From s11 at member.fsf.org Fri Aug 29 04:32:32 2008 From: s11 at member.fsf.org (Stephen Compall) Date: Thu, 28 Aug 2008 23:32:32 -0500 Subject: [cl-json-devel] [PATCH] Explicitly test for alist instead of type error Message-ID: Clozure CL (current SVN, maybe release I dunno) does this: (map 'list #'identity '(x . "abc")) => (x #\b #\c) Which breaks the alist case in encoder.lisp. So, pending a fix for Clozure, I made a workaround that tests explicitly for a proper alist instead. Attached is the Darcs patch: -------------- next part -------------- A non-text attachment was scrubbed... Name: json.test-for-alist.darcs.patch Type: text/x-diff Size: 7397 bytes Desc: the patch URL: -------------- next part -------------- -- I write stuff at http://failex.blogspot.com/ now. But the post formatter and themes are terrible for sharing code, the primary content, so it might go away sooner or later. From s11 at member.fsf.org Fri Aug 29 19:12:59 2008 From: s11 at member.fsf.org (Stephen Compall) Date: Fri, 29 Aug 2008 14:12:59 -0500 Subject: [cl-json-devel] Re: [PATCH] Explicitly test for alist instead of type error In-Reply-To: (Stephen Compall's message of "Thu, 28 Aug 2008 23:32:32 -0500") References: Message-ID: Stephen Compall writes: > Clozure CL (current SVN, maybe release I dunno) does this: > > (map 'list #'identity '(x . "abc")) > => (x #\b #\c) > > Which breaks the alist case in encoder.lisp. And is furthermore permissible behavior, as discussed in http://trac.clozure.com/openmcl/ticket/328 -- so a program may not anyway portably rely on the above signaling a type-error. -- I write stuff at http://failex.blogspot.com/ now. But the post formatter and themes are terrible for sharing code, the primary content, so it might go away sooner or later.