[cl-json-devel] One more test patch

[Robert Goldman]

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: allegro-test-patch
URL: <https://mailman.common-lisp.net/pipermail/cl-json-devel/attachments/20100102/94fa473a/attachment.ksh>