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