cl-json icon indicating copy to clipboard operation
cl-json copied to clipboard

Decoding to fluid objects appears to fail in recent versions of SBCL

Open dfmorrison opened this issue 9 years ago • 4 comments

Decoding JSON to fluid objects appears to not work in recent versions of SBCL. For example, the following works fine in SBCL 1.1.0 on Linux (Ubuntu 14.04.3):

* (format t "~@{~A~%~}"
        (asdf:component-version (asdf:find-system :cl-json))
        (lisp-implementation-type)
        (lisp-implementation-version)
        (software-type)
        (software-version)
        (machine-type)
        (machine-version))
0.5.0
SBCL
1.1.0
Linux
3.16.0-50-generic
X86-64
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
NIL
* (json:with-decoder-simple-clos-semantics
    (json:decode-json-from-string
     "{ \"foo\": [1, 2, 3], \"bar\": true }"))

#<#<JSON:FLUID-CLASS NIL {10055708B3}> {100560D693}>

However, in the latest SBCL, 1.3.2, it fails:

* (format t "~@{~A~%~}"
        (asdf:component-version (asdf:find-system :cl-json))
        (lisp-implementation-type)
        (lisp-implementation-version)
        (software-type)
        (software-version)
        (machine-type)
        (machine-version))
0.5.0
SBCL
1.3.2
Linux
3.16.0-50-generic
X86-64
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
NIL
* (json:with-decoder-simple-clos-semantics
    (json:decode-json-from-string
     "{ \"foo\": [1, 2, 3], \"bar\": true }"))

debugger invoked on a SB-PCL::SLOTD-INITIALIZATION-ERROR in thread
#<THREAD "main thread" RUNNING {1002A4C6E3}>:
  Invalid SB-MOP:SLOT-DEFINITION initialization: the initialization argument
  :NAME was constant: :FOO.
See also:
  AMOP, Initialization of Slot Definition Metaobjects

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((:METHOD INITIALIZE-INSTANCE :BEFORE (SB-MOP:SLOT-DEFINITION)) #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION {10049862D3}> :NAME :FOO :INITFORM #<unused argument> :INITFUNCTION #<unused argument> :TYPE #<unused argument> :ALLOCATION NIL :INITARGS NIL :DOCUMENTATION NIL) [fast-method]
0] 

It appears to have begun failing in this way at SBCL version 1.2.0 or earlier:

* (format t "~@{~A~%~}"
        (asdf:component-version (asdf:find-system :cl-json))
        (lisp-implementation-type)
        (lisp-implementation-version)
        (software-type)
        (software-version)
        (machine-type)
        (machine-version))
0.5.0
SBCL
1.2.0
Linux
3.16.0-50-generic
X86-64
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
NIL
* (json:with-decoder-simple-clos-semantics
    (json:decode-json-from-string
     "{ \"foo\": [1, 2, 3], \"bar\": true }"))

debugger invoked on a SB-PCL::SLOTD-INITIALIZATION-ERROR in thread
#<THREAD "main thread" RUNNING {1002BF5053}>:
  Invalid SB-MOP:SLOT-DEFINITION initialization: the initialization argument
  :NAME was constant: :FOO.
See also:
  AMOP, Initialization of Slot Definition Metaobjects

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((:METHOD INITIALIZE-INSTANCE :BEFORE (SB-MOP:SLOT-DEFINITION)) #<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION #<unbound slot>> :NAME :FOO :INITFORM #<unused argument> :INITFUNCTION #<unused argument> :TYPE #<unused argument> :ALLOCATION NIL :INITARGS NIL :DOCUMENTATION NIL) [fast-method]
0] 

dfmorrison avatar Feb 01 '16 19:02 dfmorrison

I tried to poke at this, but went astray when trying to inspect the slot definition. It seems to have no name, which either borks the SBCL inspector, or the SLIME interface to the inspector.

rpgoldman avatar Feb 01 '16 19:02 rpgoldman

Thanks for reporting, I have quite little time to look at this now sadly.

hankhero avatar Feb 01 '16 19:02 hankhero

Seems to be a quirk of sbcl. It doesn't like it when you use keyword package for MOP stuff. As a workaround, if you change cl-json:*json-symbols-package* to your own package, it works okay.

JonathanSmith avatar Feb 23 '16 17:02 JonathanSmith

It also doesn't work on LispWorks (and never did), because LispWorks also does not allow constant symbols as slot names.

Yehouda avatar Mar 04 '20 15:03 Yehouda