January 2010 - cl-json-devel - mailman3.common-lisp.net

Re: [cl-json-devel] Omnibus patch
by Henrik Hjelte 17 Jan '10

17 Jan '10

On Thu, Jan 14, 2010 at 5:47 PM, Robert Goldman <rpgoldman(a)sift.info> wrote: > OK, here's a file with all of my patches. I have applied the patches, it looks really good. Thanks a lot, Henrik

1 0

[cl-json-devel] not a darcs expert...
by Robert Goldman 14 Jan '10

14 Jan '10

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

2 1

[cl-json-devel] Suggestion for JSON-RPC function table
by Robert Goldman 14 Jan '10

14 Jan '10

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

2 3

[cl-json-devel] cl-json json-rpc SMD
by Henrik Hjelte 07 Jan '10

07 Jan '10

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

2 2

[cl-json-devel] Question about NIL translation
by Robert Goldman 06 Jan '10

06 Jan '10

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? Thanks, R

3 5

[cl-json-devel] Failures in json tests
by Robert Goldman 06 Jan '10

06 Jan '10

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-ERROR @ #x1001aa33c2> 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-ERROR @ #x10013e37f2> 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-ERROR @ #x10013dd8d2> 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-ERROR @ #x1001ad4162> 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-ERROR @ #x100144c6f2> 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: #<SIMPLE-ERROR @ #x10014c2342> 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

2 3

[cl-json-devel] Patch for parse-number on allegro
by Robert Goldman 05 Jan '10

05 Jan '10

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.

1 0

[cl-json-devel] Patch to catch simple-errors in parse-number on allegro
by Robert Goldman 02 Jan '10

02 Jan '10

This makes parse-number a /little/ better at overflow catching on allegro. Still not great.

1 0

[cl-json-devel] One more test patch
by Robert Goldman 02 Jan '10

02 Jan '10

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: #<SIMPLE-ERROR @ #x10011cc4d2> This integer is too large to be converted to single float: 9576382008924608925438958107673314324491693655815563891153405565665341876800352852394225538552941729291820613661575166989445039381263497156161143929125722546256573774437329061133895730629115316789606625346210648020024430405704583267406160006712284392153191377850076868489733840083893490872873866024814260649647904262828015650262789364087017465337661244504443087023011145384661734876080789710396809324669592973038430564702258761529776211196551827242728904820978641510009765625.. -------------------------------- -------------------------------- PASS-1 []: Unexpected Error: #<SIMPLE-ERROR @ #x10012ccaa2> This integer is too large to be converted to single float: 9576382008924608925438958107673314324491693655815563891153405565665341876800352852394225538552941729291820613661575166989445039381263497156161143929125722546256573774437329061133895730629115316789606625346210648020024430405704583267406160006712284392153191377850076868489733840083893490872873866024814260649647904262828015650262789364087017465337661244504443087023011145384661734876080789710396809324669592973038430564702258761529776211196551827242728904820978641510009765625.. -------------------------------- -------------------------------- DECODER-PERFORMANCE []: Unexpected Error: #<SIMPLE-ERROR @ #x10011e8962> 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

1 1

[cl-json-devel] Patch for cl-json.asd
by Robert Goldman 02 Jan '10

02 Jan '10

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)

1 0