From henrik at evahjelte.com Fri Jan 1 16:36:39 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Fri, 1 Jan 2010 17:36:39 +0100 Subject: [cl-json-devel] Question about NIL translation In-Reply-To: <4B3D22E4.4020107@sift.info> References: <4B3D22E4.4020107@sift.info> Message-ID: <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> On Thu, Dec 31, 2009 at 11:17 PM, Robert Goldman wrote: > Continuing to work on my CL-JSON based JSON-RPC server, I am concerned > about the fact that we translate NIL -> null. > > If a CL function returns NIL, and the return value is simply encoded > into the JSON return package, then we get a message that /should/ > indicate an error, according to the JSON-RPC server. > > In fact, if our CL function is invoked by JSON-RPC, then we really > should have NIL either encoded as [] or as false, but /never/ as null. > > Any ideas about how we should modify invoke-rpc-parsed to fix this? > > What is the right way to tell CL-JSON to encode a false? Cl-json currently has three encoders. Traditionally the most used and the one used in json-rpc is the guessing encoder (see testcases for documentation). It is not very good if you want fine-grained control, then I'd say that the explicit encoder I recently added is more convenient. Another alternative is the streaming encoder. With the explicit encode json false is (false) To fix this, I'd probably add an option to (or even recode) json-rpc to use the explicit-encoder instead. Preferably backwards compatible so code that uses json-rpc and uses the guessing-encoder doesn't break. Maybe a function called defun-json-rpc-explicit? The backward compatiblity could be preserved by encoding the old defun-json-rpc using the guessing encoder, then passing it as a json-string to the explicit encoder using the (json "some json string") format. I think this sounds more job than it is, it should not be very difficult. /Henrik From henrik at evahjelte.com Fri Jan 1 16:21:03 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Fri, 1 Jan 2010 17:21:03 +0100 Subject: [cl-json-devel] Another json-rpc question In-Reply-To: <4B3BC5EF.2020005@sift.info> References: <4B3BC5EF.2020005@sift.info> Message-ID: <50e8e4f61001010821h67d57321x77014c5de1a40c36@mail.gmail.com> On Wed, Dec 30, 2009 at 10:28 PM, Robert Goldman wrote: > I was testing my error handling code and had some trouble with the > restarts in invoke-rpc. > > A number of these restarts seem to take an error-object as an argument. > ?But when I tested my own CL-JSON methods I couldn't figure out how to > get these error-objects into the restart. ?How is that to be done? I have sent errors like this: (json-rpc:send-error "Wrong email adress" 1234) Also see the function make-json-rpc-error-object-1.1 that can be used with send-error-object. From looking at the code it seems the error-object should be an a-list that can be encoded using the guessing encoder. Hope it helps. /Henrik From rpgoldman at sift.info Sat Jan 2 02:56:19 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Fri, 01 Jan 2010 20:56:19 -0600 Subject: [cl-json-devel] Question about NIL translation In-Reply-To: <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> References: <4B3D22E4.4020107@sift.info> <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> Message-ID: <4B3EB5D3.3030601@sift.info> On 1/1/10 Jan 1 -10:36 AM, Henrik Hjelte wrote: > On Thu, Dec 31, 2009 at 11:17 PM, Robert Goldman wrote: >> Continuing to work on my CL-JSON based JSON-RPC server, I am concerned >> about the fact that we translate NIL -> null. >> >> If a CL function returns NIL, and the return value is simply encoded >> into the JSON return package, then we get a message that /should/ >> indicate an error, according to the JSON-RPC server. >> >> In fact, if our CL function is invoked by JSON-RPC, then we really >> should have NIL either encoded as [] or as false, but /never/ as null. >> >> Any ideas about how we should modify invoke-rpc-parsed to fix this? >> >> What is the right way to tell CL-JSON to encode a false? > > Cl-json currently has three encoders. Traditionally the most used and > the one used in json-rpc is the guessing encoder (see testcases for > documentation). It is not very good if you want fine-grained control, > then I'd say that the explicit encoder I recently added is more > convenient. Another alternative is the streaming encoder. With the > explicit encode json false is (false) > > To fix this, I'd probably add an option to (or even recode) json-rpc > to use the explicit-encoder instead. Preferably backwards compatible > so code that uses json-rpc and uses the guessing-encoder doesn't > break. Maybe a function called defun-json-rpc-explicit? The backward > compatiblity could be preserved by encoding the old defun-json-rpc > using the guessing encoder, then passing it as a json-string to the > explicit encoder using the (json "some json string") format. I think > this sounds more job than it is, it should not be very difficult. > What about making the type argument to defun-json-rpc optional instead of mandatory. If the default is explicit encoding then we'd still have backward compatibility without adding a new, more verbose-named defun? The CL-JSON spec for 1.1 seems like a real mess --- it's not at all clear what should happen if you invoke a method over CL-JSON that returns a null value (e.g., a JS function with no return). The 2.0 (draft) spec seems to have a much clearer approach to this.... I'm inclined to just move to observing the draft 2.0 spec. Best, r From rpgoldman at sift.info Sat Jan 2 21:16:32 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 15:16:32 -0600 Subject: [cl-json-devel] Failures in json tests Message-ID: <4B3FB7B0.5040207@sift.info> Just ran the cl-json test suite (patch to cl-json.asd that makes this easier will follow) and got seven failures: Failure Details: -------------------------------- DECODER-PERFORMANCE-WITH-SIMPLIFIED-CAMEL-CASE []: Unexpected Error: # File #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does not exist... -------------------------------- -------------------------------- PASS-3 []: Unexpected Error: # File #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass3.json" does not exist... -------------------------------- -------------------------------- PASS-1 []: Unexpected Error: # File #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does not exist... -------------------------------- -------------------------------- DECODER-PERFORMANCE []: Unexpected Error: # File #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does not exist... -------------------------------- -------------------------------- PASS-2 []: Unexpected Error: # File #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass2.json" does not exist... -------------------------------- -------------------------------- TEST*JSON-SYMBOLS-PACKAGE* []: Unexpected Error: # slot-definition did not receive a valid :name initarg.. -------------------------------- -------------------------------- JSON-BIND-IN-BIND-BUG []: RESULT2 evaluated to "(0 ((ID . pingId) (NAME . ping)) NIL (((NAME . tableTennisGroupName) (ID . tableTennisGroupId))))", which is not STRING= to "(0 NIL NIL (NIL))".. -------------------------------- Running on ACL 8.1, MacOSX. Best, R From rpgoldman at sift.info Sat Jan 2 21:21:43 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 15:21:43 -0600 Subject: [cl-json-devel] Patch for cl-json.asd Message-ID: <4B3FB8E7.7000506@sift.info> This patch makes it easier to test CL-JSON by adding a test-op to the system definition. You can now just eval (asdf:oos 'asdf:test-op :cl-json) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: asdf-patch URL: From rpgoldman at sift.info Sat Jan 2 21:53:30 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 15:53:30 -0600 Subject: [cl-json-devel] Failures in json tests In-Reply-To: <4B3FB7B0.5040207@sift.info> References: <4B3FB7B0.5040207@sift.info> Message-ID: <4B3FC05A.2020509@sift.info> On 1/2/10 Jan 2 -3:16 PM, Robert Goldman wrote: > Just ran the cl-json test suite (patch to cl-json.asd that makes this > easier will follow) and got seven failures: > > Failure Details: > -------------------------------- > DECODER-PERFORMANCE-WITH-SIMPLIFIED-CAMEL-CASE []: > Unexpected Error: # > File > #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does > not exist... > -------------------------------- > -------------------------------- > PASS-3 []: > Unexpected Error: # > File > #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass3.json" does > not exist... > -------------------------------- > -------------------------------- > PASS-1 []: > Unexpected Error: # > File > #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does > not exist... > -------------------------------- > -------------------------------- > DECODER-PERFORMANCE []: > Unexpected Error: # > File > #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass1.json" does > not exist... > -------------------------------- > -------------------------------- > PASS-2 []: > Unexpected Error: # > File > #P"/Users/rpg/lisp/cl-json/t/allegro-8.1a-64bit-macosx-x86-64/pass2.json" does > not exist... OK, I know what's going on with the file-errors. The problem is that ASDF now by default uses asdf-binary-locations and relocates binaries into different locations (this is necessary so that the same source files can be compiled into, e.g., both SBCL and ACL, both of which apply the .fasl extension to the compiler's outputs). This means that *load-pathname* cannot be used raw as a way of finding the .json data files. I have a patch to propose that gets around this by recording *load-truename* inside the .asd file (which is not moved) instead of inside the .lisp files. Patch will follow, r From rpgoldman at sift.info Sat Jan 2 22:02:40 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 16:02:40 -0600 Subject: [cl-json-devel] Failures in json tests In-Reply-To: <4B3FC05A.2020509@sift.info> References: <4B3FB7B0.5040207@sift.info> <4B3FC05A.2020509@sift.info> Message-ID: <4B3FC280.5080105@sift.info> On 1/2/10 Jan 2 -3:53 PM, Robert Goldman wrote: > On 1/2/10 Jan 2 -3:16 PM, Robert Goldman wrote: > I have a patch to propose that gets around this by recording > *load-truename* inside the .asd file (which is not moved) instead of > inside the .lisp files. > > Patch will follow, > r > I'm having a darcs problem now. I have 3 patches. I have sent two of them already, so I was going to send the current one alone. However, when I use darcs send, I tell it 'n' to sending the two patches I have already sent. When I give the n to the second of three patches, darcs says that I have no patches to send at all and exits. Shall I send this patch? (2/3) [ynWvpxqadjk], or ? for help: n You don't want to send any patches, and that's fine with me! [rpgoldman-2:~/lisp/cl-json] rpg% Has anyone seen this problem? Does anyone know if there's a workaround? Meanwhile, here is the new patch mashed together with the last one. Sorry, but I don't know what else to do. Best, r -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: asdf-patches URL: From rpgoldman at sift.info Sat Jan 2 22:42:37 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 16:42:37 -0600 Subject: [cl-json-devel] One more test patch Message-ID: <4B3FCBDD.3060507@sift.info> I have found that there are some problems with allegro like CMU's limitation on not having keywords naming slots, and on MacOSX (even 64-bit) some problems with very large numbers. Patch attached adds some feature-checking to disable these tests for Allegro. I still have some remaining test failures: Failure Details: -------------------------------- DECODER-PERFORMANCE-WITH-SIMPLIFIED-CAMEL-CASE []: Unexpected Error: # This integer is too large to be converted to single float: 9576382008924608925438958107673314324491693655815563891153405565665341876800352852394225538552941729291820613661575166989445039381263497156161143929125722546256573774437329061133895730629115316789606625346210648020024430405704583267406160006712284392153191377850076868489733840083893490872873866024814260649647904262828015650262789364087017465337661244504443087023011145384661734876080789710396809324669592973038430564702258761529776211196551827242728904820978641510009765625.. -------------------------------- -------------------------------- PASS-1 []: Unexpected Error: # This integer is too large to be converted to single float: 9576382008924608925438958107673314324491693655815563891153405565665341876800352852394225538552941729291820613661575166989445039381263497156161143929125722546256573774437329061133895730629115316789606625346210648020024430405704583267406160006712284392153191377850076868489733840083893490872873866024814260649647904262828015650262789364087017465337661244504443087023011145384661734876080789710396809324669592973038430564702258761529776211196551827242728904820978641510009765625.. -------------------------------- -------------------------------- DECODER-PERFORMANCE []: Unexpected Error: # This integer is too large to be converted to single float: 9576382008924608925438958107673314324491693655815563891153405565665341876800352852394225538552941729291820613661575166989445039381263497156161143929125722546256573774437329061133895730629115316789606625346210648020024430405704583267406160006712284392153191377850076868489733840083893490872873866024814260649647904262828015650262789364087017465337661244504443087023011145384661734876080789710396809324669592973038430564702258761529776211196551827242728904820978641510009765625.. -------------------------------- -------------------------------- JSON-BIND-IN-BIND-BUG []: RESULT2 evaluated to "(0 ((ID . pingId) (NAME . ping)) NIL (((NAME . tableTennisGroupName) (ID . tableTennisGroupId))))", which is not STRING= to "(0 NIL NIL (NIL))".. -------------------------------- The last one seems to reflect a lingering bug in CL-JSON, and is not related to Allegro. The other three all seem to have to do with numeric overflows like the ones I commented out in the attached patch. Since these are baked into the files, I wasn't sure how to fix this. The problem seems to be that Allegro blows up with numeric overflows in the read-from-string call in parse-number and, unfortunately, the error isn't one of the two that cl-json tests for: (or reader-error #+ecl arithmetic-error). Yet more unfortunately, there is no nice error class here hoisted by ACL for CL-JSON to detect; ACL just raises a simple-error..... I have a kludgy patch for this, but I can't say I'm really happy with it. Also, the code in the tests seems to assume that there will be an error of condition class floating-point-overflow raised, but alas, that isn't what's raised here. Best, r -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: allegro-test-patch URL: From rpgoldman at sift.info Sat Jan 2 22:49:29 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 16:49:29 -0600 Subject: [cl-json-devel] One more test patch In-Reply-To: <4B3FCBDD.3060507@sift.info> References: <4B3FCBDD.3060507@sift.info> Message-ID: <4B3FCD79.5080707@sift.info> On 1/2/10 Jan 2 -4:42 PM, Robert Goldman wrote: > I have found that there are some problems with allegro like CMU's > limitation on not having keywords naming slots, and on MacOSX (even > 64-bit) some problems with very large numbers. > > > The other three all seem to have to do with numeric overflows like the > ones I commented out in the attached patch. Since these are baked into > the files, I wasn't sure how to fix this. > > The problem seems to be that Allegro blows up with numeric overflows in > the read-from-string call in parse-number and, unfortunately, the error > isn't one of the two that cl-json tests for: (or reader-error #+ecl > arithmetic-error). Yet more unfortunately, there is no nice error class > here hoisted by ACL for CL-JSON to detect; ACL just raises a > simple-error..... > > I have a kludgy patch for this, but I can't say I'm really happy with it. > > Also, the code in the tests seems to assume that there will be an error > of condition class floating-point-overflow raised, but alas, that isn't > what's raised here. > OK, this actually seems like it is an allegro bug. I don't seem to be able to persuade allegro to raise a floating-point-overflow error. I will contact Franz and see what they say. best, r From rpgoldman at sift.info Sat Jan 2 23:09:19 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 02 Jan 2010 17:09:19 -0600 Subject: [cl-json-devel] Patch to catch simple-errors in parse-number on allegro Message-ID: <4B3FD21F.6000501@sift.info> This makes parse-number a /little/ better at overflow catching on allegro. Still not great. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: allegro-float-overflow-patch URL: From rpgoldman at sift.info Tue Jan 5 20:22:59 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Tue, 05 Jan 2010 14:22:59 -0600 Subject: [cl-json-devel] Patch for parse-number on allegro Message-ID: <4B439FA3.1040009@sift.info> Allegro CL raises different errors on numeric overflow when reading from string than do other lisps. This patch looks for those errors. Thanks to the folks @ Franz for helping me figure out how to detect the right errors. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: catch-read-numeric-overflow-on-allegro.patch URL: From henrik at evahjelte.com Wed Jan 6 11:49:11 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Wed, 6 Jan 2010 12:49:11 +0100 Subject: [cl-json-devel] Failures in json tests In-Reply-To: <4B3FC280.5080105@sift.info> References: <4B3FB7B0.5040207@sift.info> <4B3FC05A.2020509@sift.info> <4B3FC280.5080105@sift.info> Message-ID: <50e8e4f61001060349y6d7972feg33c32627f215f405@mail.gmail.com> On Sat, Jan 2, 2010 at 11:02 PM, Robert Goldman wrote: > On 1/2/10 Jan 2 -3:53 PM, Robert Goldman wrote: >> On 1/2/10 Jan 2 -3:16 PM, Robert Goldman wrote: > > I'm having a darcs problem now. ?I have 3 patches. ?I have sent two of > them already, so I was going to send the current one alone. > > However, when I use darcs send, I tell it 'n' to sending the two patches > I have already sent. ?When I give the n to the second of three patches, > darcs says that I have no patches to send at all and exits. I think this is a feature of darcs. The third patch depends on the second patch (maybe because they touch a common line in some file). I saw some whitespace cleanups that got into your patches that you might not be aware of, so it might be unintuitive. Anyway darcs refuses to send just the third patch because it can't be applied without the second. Anyway: I have now applied all your patches, everything seems to work, thanks! /Henrik From henrik at evahjelte.com Wed Jan 6 13:10:59 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Wed, 6 Jan 2010 14:10:59 +0100 Subject: [cl-json-devel] Question about NIL translation In-Reply-To: <4B3EB5D3.3030601@sift.info> References: <4B3D22E4.4020107@sift.info> <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> <4B3EB5D3.3030601@sift.info> Message-ID: <50e8e4f61001060510g3cd5bb71q4a37132f75bc5eff@mail.gmail.com> > What about making the type argument to defun-json-rpc optional instead > of mandatory. ?If the default is explicit encoding then we'd still have > backward compatibility without adding a new, more verbose-named defun? yes, good idea. I had actually forgotten I had added some support for different encoders in json-rpc. I think the reason I don't had the type argument optional is because I am a weak coder, I just don't know how to make type &optional in the right way. I guess you can put all three type lambda-list and body as one &rest and parse it. On the other hand: I personally don't have a strong problem with breaking backwards compatibilty in this way, it is only for a small subset of cl-json and it breaks you old code in an "nice" way, throwing an error that is easy to fix. (defmacro defun-json-rpc (name type lambda-list &body body) > > The CL-JSON spec for 1.1 seems like a real mess --- it's not at all > clear what should happen if you invoke a method over CL-JSON that > returns a null value (e.g., a JS function with no return). > > The 2.0 (draft) spec seems to have a much clearer approach to this.... > > I'm inclined to just move to observing the draft 2.0 spec. Yes why not? I am not aware of the exact differences, except that 2.0 has named parameters. Maybe it is possible to expose a function both as 1.1 and 2.0? /Henrik From henrik at evahjelte.com Wed Jan 6 13:44:58 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Wed, 6 Jan 2010 14:44:58 +0100 Subject: [cl-json-devel] cl-json json-rpc SMD Message-ID: <50e8e4f61001060544g441d3c24vd56147dbb0a9badb@mail.gmail.com> Since there is some activity with json-rpc I have added some code we use for generating SMD-descriptions to json-rpc.lisp, in case it is useful. It is commented out since it is was only used inhouse and we never got around to add it properly to cl-json. /Henrik From rpgoldman at sift.info Wed Jan 6 13:46:25 2010 From: rpgoldman at sift.info (Robert P. Goldman) Date: Wed, 6 Jan 2010 07:46:25 -0600 Subject: [cl-json-devel] Question about NIL translation In-Reply-To: <50e8e4f61001060510g3cd5bb71q4a37132f75bc5eff@mail.gmail.com> References: <4B3D22E4.4020107@sift.info> <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> <4B3EB5D3.3030601@sift.info> <50e8e4f61001060510g3cd5bb71q4a37132f75bc5eff@mail.gmail.com> Message-ID: I have most of a patch for providing JSON-RPC 2.0 support. I will try to submit it by the end of the week. What about a json-rpc type of :Boolean? This would take the raw output of the cl function and turn it into true or false according to cl rules. We could also have a type of :array as alternative, that would turn any sequence into a json array and would turn NIL into [] (singleton return values would signal an error). Just a thought; haven't considered the implications deeply... On Jan 6, 2010, at 7:10, Henrik Hjelte wrote: >> What about making the type argument to defun-json-rpc optional >> instead >> of mandatory. If the default is explicit encoding then we'd still >> have >> backward compatibility without adding a new, more verbose-named >> defun? > > yes, good idea. I had actually forgotten I had added some support for > different encoders in json-rpc. > > I think the reason I don't had the type argument optional is because I > am a weak coder, I just don't know how to make type &optional in the > right way. I guess you can put all three type lambda-list and body as > one &rest and parse it. On the other hand: I personally don't have a > strong problem with breaking backwards compatibilty in this way, it is > only for a small subset of cl-json and it breaks you old code in an > "nice" way, throwing an error that is easy to fix. > > (defmacro defun-json-rpc (name type lambda-list &body body) > >> >> The CL-JSON spec for 1.1 seems like a real mess --- it's not at all >> clear what should happen if you invoke a method over CL-JSON that >> returns a null value (e.g., a JS function with no return). >> >> The 2.0 (draft) spec seems to have a much clearer approach to >> this.... >> >> I'm inclined to just move to observing the draft 2.0 spec. > > Yes why not? I am not aware of the exact differences, except that 2.0 > has named parameters. > > Maybe it is possible to expose a function both as 1.1 and 2.0? > > /Henrik From rpgoldman at sift.info Wed Jan 6 15:35:31 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 06 Jan 2010 09:35:31 -0600 Subject: [cl-json-devel] cl-json json-rpc SMD In-Reply-To: <50e8e4f61001060544g441d3c24vd56147dbb0a9badb@mail.gmail.com> References: <50e8e4f61001060544g441d3c24vd56147dbb0a9badb@mail.gmail.com> Message-ID: <4B44ADC3.4060909@sift.info> On 1/6/10 Jan 6 -7:44 AM, Henrik Hjelte wrote: > Since there is some activity with json-rpc I have added some code we > use for generating SMD-descriptions to json-rpc.lisp, in case it is > useful. It is commented out since it is was only used inhouse and we > never got around to add it properly to cl-json. I'm a little confused by this patch. It seems to assume that there is a lot of material associated with the JSON-RPC function name in the table *json-rpc-method-definitions*, in particular parameter lists. But defun-json-rpc doesn't seem to cache these values.... Are you using a macro around defun-json-rpc, or an alternate version? thanks, r From rpgoldman at sift.info Wed Jan 6 15:29:13 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 06 Jan 2010 09:29:13 -0600 Subject: [cl-json-devel] Question about NIL translation In-Reply-To: References: <4B3D22E4.4020107@sift.info> <50e8e4f61001010836o24c68ba7i98a82e342afe37ee@mail.gmail.com> <4B3EB5D3.3030601@sift.info> <50e8e4f61001060510g3cd5bb71q4a37132f75bc5eff@mail.gmail.com> Message-ID: <4B44AC49.80302@sift.info> On 1/6/10 Jan 6 -7:46 AM, Robert P. Goldman wrote: > I have most of a patch for providing JSON-RPC 2.0 support. I will try > to submit it by the end of the week. > > What about a json-rpc type of :Boolean? This would take the raw output > of the cl function and turn it into true or false according to cl > rules. We could also have a type of :array as alternative, that would > turn any sequence into a json array and would turn NIL into [] > (singleton return values would signal an error). A quick follow-up: would it be acceptable to create a generic function like this: (defgeneric encode-json-rpc-value (keyword value) (:documentation "An extensible set of methods for encoding JSON-RPC values according to a keyword specification") (:method (keyword value) (declare (ignore value)) (error "Keyword ~a does not correspond to any JSON-RPC encoding" keyword)) (:method ((keyword (eql :guessing) value) ....)) and use this to replace the ecase in INVOKE-RPC-PARSED ? That would make it easier for people to come up with their own encoding schemes. If you like, I will try to supply a patch. best, r > > Just a thought; haven't considered the implications deeply... > > On Jan 6, 2010, at 7:10, Henrik Hjelte wrote: > >>> What about making the type argument to defun-json-rpc optional >>> instead >>> of mandatory. If the default is explicit encoding then we'd still >>> have >>> backward compatibility without adding a new, more verbose-named >>> defun? >> >> yes, good idea. I had actually forgotten I had added some support for >> different encoders in json-rpc. >> >> I think the reason I don't had the type argument optional is because I >> am a weak coder, I just don't know how to make type &optional in the >> right way. I guess you can put all three type lambda-list and body as >> one &rest and parse it. On the other hand: I personally don't have a >> strong problem with breaking backwards compatibilty in this way, it is >> only for a small subset of cl-json and it breaks you old code in an >> "nice" way, throwing an error that is easy to fix. >> >> (defmacro defun-json-rpc (name type lambda-list &body body) >> >>> >>> The CL-JSON spec for 1.1 seems like a real mess --- it's not at all >>> clear what should happen if you invoke a method over CL-JSON that >>> returns a null value (e.g., a JS function with no return). >>> >>> The 2.0 (draft) spec seems to have a much clearer approach to >>> this.... >>> >>> I'm inclined to just move to observing the draft 2.0 spec. >> >> Yes why not? I am not aware of the exact differences, except that 2.0 >> has named parameters. >> >> Maybe it is possible to expose a function both as 1.1 and 2.0? >> >> /Henrik > > _______________________________________________ > cl-json-devel mailing list > cl-json-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-json-devel From henrik at evahjelte.com Thu Jan 7 08:11:17 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Thu, 7 Jan 2010 09:11:17 +0100 Subject: [cl-json-devel] cl-json json-rpc SMD In-Reply-To: <4B44ADC3.4060909@sift.info> References: <50e8e4f61001060544g441d3c24vd56147dbb0a9badb@mail.gmail.com> <4B44ADC3.4060909@sift.info> Message-ID: <50e8e4f61001070011x3cfd4a5dq4561f1ba8fef3ddc@mail.gmail.com> On Wed, Jan 6, 2010 at 4:35 PM, Robert Goldman wrote: > I'm a little confused by this patch. ?It seems to assume that there is a > lot of material associated with the JSON-RPC function name in the table > *json-rpc-method-definitions*, in particular parameter lists. > > But defun-json-rpc doesn't seem to cache these values.... > > Are you using a macro around defun-json-rpc, or an alternate version? A macro wrapper for the specific project, but it should be possible to add the parameter info somewhere inside cl-json, perhaps in the hashtable for exposed functions that already exists. Sorry the code is not cleaned up.. /Henrik From rpgoldman at sift.info Wed Jan 13 22:08:24 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 13 Jan 2010 16:08:24 -0600 Subject: [cl-json-devel] Suggestion for JSON-RPC function table Message-ID: <4B4E4458.1060308@sift.info> In the current version of CL-JSON, defining a json-rpc-function puts the /function/ in a hash-table. I have been wrestling with testing my json-rpc-2.0 code and find that this structure makes my code hard to debug. In particular, I can't effectively TRACE a function that's exported from cl-json. How would you feel about putting the symbol that /names/ the function into the hash-table, instead of the function itself? At the expense of another hash-table lookup, we get the ability to trace our exported functions.... No code change to speak of, since the call to apply will work on the function name as well as the function object. Best, r From henrik at evahjelte.com Wed Jan 13 22:29:47 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Wed, 13 Jan 2010 23:29:47 +0100 Subject: [cl-json-devel] Suggestion for JSON-RPC function table In-Reply-To: <4B4E4458.1060308@sift.info> References: <4B4E4458.1060308@sift.info> Message-ID: <50e8e4f61001131429s7b728fa5v9283641439ff3971@mail.gmail.com> On Wed, Jan 13, 2010 at 11:08 PM, Robert Goldman wrote: > In the current version of CL-JSON, defining a json-rpc-function puts the > /function/ in a hash-table. > > I have been wrestling with testing my json-rpc-2.0 code Great, I saw you were active on the json-rpc mailing list as well. and find that > this structure makes my code hard to debug. ?In particular, I can't > effectively TRACE a function that's exported from cl-json. While you are testing, you might consider coding some testcases at the same time. > How would you feel about putting the symbol that /names/ the function > into the hash-table, instead of the function itself? I don't see any problems with this. /Henrik From rpgoldman at sift.info Wed Jan 13 23:59:05 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 13 Jan 2010 17:59:05 -0600 Subject: [cl-json-devel] Suggestion for JSON-RPC function table In-Reply-To: <50e8e4f61001131429s7b728fa5v9283641439ff3971@mail.gmail.com> References: <4B4E4458.1060308@sift.info> <50e8e4f61001131429s7b728fa5v9283641439ff3971@mail.gmail.com> Message-ID: <4B4E5E49.7000400@sift.info> On 1/13/10 Jan 13 -4:29 PM, Henrik Hjelte wrote: > On Wed, Jan 13, 2010 at 11:08 PM, Robert Goldman wrote: >> In the current version of CL-JSON, defining a json-rpc-function puts the >> /function/ in a hash-table. >> >> I have been wrestling with testing my json-rpc-2.0 code > > Great, I saw you were active on the json-rpc mailing list as well. > > and find that >> this structure makes my code hard to debug. In particular, I can't >> effectively TRACE a function that's exported from cl-json. > > While you are testing, you might consider coding some testcases at the > same time. Yes, I have been --- I have been extending the existing JSON-RPC tests with others that exercise the new :boolean and :array coding schemes, and also that check both 1.1 and 2.0 behaviors. I am holding off submitting my patches until such a time as I have those tests in place and passing. best, r From rpgoldman at sift.info Thu Jan 14 02:48:39 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 13 Jan 2010 20:48:39 -0600 Subject: [cl-json-devel] Suggestion for JSON-RPC function table In-Reply-To: <4B4E5E49.7000400@sift.info> References: <4B4E4458.1060308@sift.info> <50e8e4f61001131429s7b728fa5v9283641439ff3971@mail.gmail.com> <4B4E5E49.7000400@sift.info> Message-ID: <4B4E8607.40709@sift.info> OK, attached is a darcs patch that changes the way the function table is populated, so that it holds function names, rather than functions. Next patch will be to add json-rpc 2.0 support. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: record-function-names-not-functions.patch URL: From rpgoldman at sift.info Thu Jan 14 02:58:28 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Wed, 13 Jan 2010 20:58:28 -0600 Subject: [cl-json-devel] not a darcs expert... Message-ID: <4B4E8854.7070401@sift.info> I have a patch that adds json-rpc-2.0 support. I am trying to get darcs to give it to me to send. But darcs won't let me. I'm not sure if it's because of the name I gave the patch, "add-json-rpc-2.0-support", or whether it's because darcs has some theory about patch dependencies that I don't understand. I ask it to send this patch, and it asks me about other patches that I don't want to send, and then it says "You don't want to send any patches, and that's fine with me!" to which my reply is "No, YOU don't want to send any patches, Mr. Darcs program, and that's not fine with me." Sorry, but this VCS was not my choice, and I don't have time to both wrestle darcs into submission AND add json-rpc 2.0 support... I'm hoping that the community will be OK with my choosing to do the latter. Any help would be much appreciated, R From henrik at evahjelte.com Thu Jan 14 08:21:57 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Thu, 14 Jan 2010 09:21:57 +0100 Subject: [cl-json-devel] not a darcs expert... In-Reply-To: <4B4E8854.7070401@sift.info> References: <4B4E8854.7070401@sift.info> Message-ID: <50e8e4f61001140021m25c42487s1620a52d93440311@mail.gmail.com> On Thu, Jan 14, 2010 at 3:58 AM, Robert Goldman wrote: > I have a patch that adds json-rpc-2.0 support. Great! > > I am trying to get darcs to give it to me to send. > > But darcs won't let me. ?I'm not sure if it's because of the name I gave > the patch, "add-json-rpc-2.0-support", or whether it's because darcs has > some theory about patch dependencies that I don't understand. It is not because of the naming, it is about dependencies. > I ask it to send this patch, and it asks me about other patches that I > don't want to send, and then it says "You don't want to send any > patches, and that's fine with me!" to which my reply is "No, YOU don't > want to send any patches, Mr. Darcs program, and that's not fine with me." Darcs compares your repo with the one you pulled from, and since your patches probably are related (touches similar lines), it want you to send all the patches that are needed. This should be no problem at all, just send all as a patch bundle. I think it might be whitespace cleanups from your editor that makes all your patches dependent to an extent you don't agree with. I use darcsum.el to easily select what to include in a patch, I try to keep only logically related changes in each patch. I can support you more off-list. If you really don't want to send all patches as one bundle just send me a zip file when you are finished and I will record some patches. Thanks, Henrik From henrik at evahjelte.com Sun Jan 17 22:18:31 2010 From: henrik at evahjelte.com (Henrik Hjelte) Date: Sun, 17 Jan 2010 23:18:31 +0100 Subject: [cl-json-devel] Omnibus patch In-Reply-To: <4B4F4A8D.20504@sift.info> References: <4B4F4A8D.20504@sift.info> Message-ID: <50e8e4f61001171418t1b42f0b9jef7d4658b0a6d434@mail.gmail.com> On Thu, Jan 14, 2010 at 5:47 PM, Robert Goldman wrote: > OK, here's a file with all of my patches. I have applied the patches, it looks really good. Thanks a lot, Henrik