Steel Bank Common Lisp

On 10 December 2011 12:15, Tamas Papp <tkpapp@...> wrote:

> Redefining structures (with a different layout, or factoring out parts
> to an included structure, etc) sometimes causes glitches like
>
> The value
>  #S(AXIS
>     :TITLE "y"
>     :TITLE-MARGIN 20
>     :DECORATION-MARGIN #S(XY :X 25 :Y 45)
>     :MARK 3
>     :ANNOTATION-DISTANCE 6
>     :SPACING #S(XY :X 50 :Y 30))
> is not of type
>  AXIS.
>   [Condition of type TYPE-ERROR]

This is pretty much expected when redefining structures unless you're
exceedingly careful.

You have in your image instances of structures using the old layout,
which then break when used with the new accessors and predicates.
(Usual suspects include DEFVARs, LOAD-TIME-VALUEs, DEFGLOBALs, closed
over values, EQL-specializers, and slots with :ALLOCATION :CLASS)

Now, in /some/ cases it would be possibly to destructively update the
instance to match the new layout. (Eg. same slots but in different
order.) It is not, however, possible in the general.

For things where allocation or slot access speed is not at premium
(AXIS above doesn't look like it), you're propably better off using
DEFCLASS, since it allows instances to be updated.

You may also consider writing a DEFOBJECT that can expand to either
DEFSTRUCT or DEFCLASS as needed, so that you can switch to DEFCLASS
when you're working on the system, and DEFSTRUCT when deploying.

Cheers,

 - nikodemus

On Sat, 10 Dec 2011, Nikodemus Siivola wrote:

> On 10 December 2011 12:15, Tamas Papp <tkpapp@...> wrote:
> 
> > Redefining structures (with a different layout, or factoring out parts
> > to an included structure, etc) sometimes causes glitches like
> >
> > The value
> >  #S(AXIS
> >     :TITLE "y"
> >     :TITLE-MARGIN 20
> >     :DECORATION-MARGIN #S(XY :X 25 :Y 45)
> >     :MARK 3
> >     :ANNOTATION-DISTANCE 6
> >     :SPACING #S(XY :X 50 :Y 30))
> > is not of type
> >  AXIS.
> >   [Condition of type TYPE-ERROR]
> 
> This is pretty much expected when redefining structures unless you're
> exceedingly careful.
> 
> You have in your image instances of structures using the old layout,
> which then break when used with the new accessors and predicates.
> (Usual suspects include DEFVARs, LOAD-TIME-VALUEs, DEFGLOBALs, closed
> over values, EQL-specializers, and slots with :ALLOCATION :CLASS)

I thought about that, but I got this error even when I regenerated the
instances according to the new layout.  Of course, I don't know how
deeply SBCL inlines the layout, so it could happen that I forgot to
recompile something, but I did an asdf reload and still got the error
message.

> For things where allocation or slot access speed is not at premium
> (AXIS above doesn't look like it), you're propably better off using
> DEFCLASS, since it allows instances to be updated.

Speed is irrelevant per se in this application, I am using structures
because of the extremely nice read/write syntax (I guess one could
write a mixin class with some MOP magic to emulate this though, but am
not comfortable enough with the MOP just yet).

> You may also consider writing a DEFOBJECT that can expand to either
> DEFSTRUCT or DEFCLASS as needed, so that you can switch to DEFCLASS
> when you're working on the system, and DEFSTRUCT when deploying.

Great suggestion, I think I may end up doing that.

Thanks,

Tamas

On 10 December 2011 17:10, Tamas Papp <tkpapp@...> wrote:

> I thought about that, but I got this error even when I regenerated the
> instances according to the new layout.

Do you inline MAKE-AXIS? If so, you need to also recompile sites that
call it, or they will use the old layout.

Cheers,

 -- nikodemus

On Dec 10, 2011, at 16:10 , Tamas Papp wrote:
> On Sat, 10 Dec 2011, Nikodemus Siivola wrote:
> 
>> On 10 December 2011 12:15, Tamas Papp <tkpapp@...> wrote:
>> 
>>> Redefining structures (with a different layout, or factoring out parts
>>> to an included structure, etc) sometimes causes glitches like
>>> 
>>> The value
>>>  #S(AXIS
>>>     :TITLE "y"
>>>     :TITLE-MARGIN 20
>>>     :DECORATION-MARGIN #S(XY :X 25 :Y 45)
>>>     :MARK 3
>>>     :ANNOTATION-DISTANCE 6
>>>     :SPACING #S(XY :X 50 :Y 30))
>>> is not of type
>>>  AXIS.
>>>   [Condition of type TYPE-ERROR]
>> 
>> This is pretty much expected when redefining structures unless you're
>> exceedingly careful.
>> 
>> You have in your image instances of structures using the old layout,
>> which then break when used with the new accessors and predicates.
>> (Usual suspects include DEFVARs, LOAD-TIME-VALUEs, DEFGLOBALs, closed
>> over values, EQL-specializers, and slots with :ALLOCATION :CLASS)
> 
> I thought about that, but I got this error even when I regenerated the
> instances according to the new layout.  Of course, I don't know how
> deeply SBCL inlines the layout, so it could happen that I forgot to
> recompile something, but I did an asdf reload and still got the error
> message.


Quote from The Hyperspec:

"The consequences of redefining a defstruct structure are undefined."

Maybe this has been mentioned already, and maybe SBCL makes more of an effort to support structure redefinition, but still...

On Sat, 10 Dec 2011, Raymond Wiker wrote:

> On Dec 10, 2011, at 16:10 , Tamas Papp wrote:
> 
> > I thought about that, but I got this error even when I regenerated the
> > instances according to the new layout.  Of course, I don't know how
> > deeply SBCL inlines the layout, so it could happen that I forgot to
> > recompile something, but I did an asdf reload and still got the error
> > message.
> 
> 
> Quote from The Hyperspec:
> 
> "The consequences of redefining a defstruct structure are undefined."
> 
> Maybe this has been mentioned already, and maybe SBCL makes more of
> an effort to support structure redefinition, but still... 

Sure, the standard basically says that I should not do it, and should
not complain if I do and bad things happen.  Which is a reasonable
attitude I guess.

Is there a way I could have quick-dirty print-object methods defined
for classes?  Does not need to be readable, but it is so nice to punt
on the nice printed representations of structures when I am trace'ing.
Otherwise, I would be much better off with classes.  Maybe someone
already has a mixin class or something similar in a library that I
have missed.

Tamas

On Dec 10, 2011, at 20:02 , Tamas Papp wrote:
> On Sat, 10 Dec 2011, Raymond Wiker wrote:
> 
>> On Dec 10, 2011, at 16:10 , Tamas Papp wrote:
>> 
>>> I thought about that, but I got this error even when I regenerated the
>>> instances according to the new layout.  Of course, I don't know how
>>> deeply SBCL inlines the layout, so it could happen that I forgot to
>>> recompile something, but I did an asdf reload and still got the error
>>> message.
>> 
>> 
>> Quote from The Hyperspec:
>> 
>> "The consequences of redefining a defstruct structure are undefined."
>> 
>> Maybe this has been mentioned already, and maybe SBCL makes more of
>> an effort to support structure redefinition, but still... 
> 
> Sure, the standard basically says that I should not do it, and should
> not complain if I do and bad things happen.  Which is a reasonable
> attitude I guess.
> 
> Is there a way I could have quick-dirty print-object methods defined
> for classes?  Does not need to be readable, but it is so nice to punt
> on the nice printed representations of structures when I am trace'ing.
> Otherwise, I would be much better off with classes.  Maybe someone
> already has a mixin class or something similar in a library that I
> have missed.
> 
> Tamas


Maybe something like this (which uses a bit of MOP, namely class-slots and slot-definition-name):

(defmethod print-object ((object my-base-class-or-mixin) stream)
  (print-unreadable-object (object stream :type t :identity t)
    (dolist (slot-def (class-slots (class-of object)))
      (let ((slot-name (slot-definition-name slot-def)))
        (format stream "~&~a: ~a~%" slot-name (slot-value object slot-name))))))

On Sat, 10 Dec 2011, Raymond Wiker wrote:

> On Dec 10, 2011, at 20:02 , Tamas Papp wrote:
> > On Sat, 10 Dec 2011, Raymond Wiker wrote:
> > 
> >> On Dec 10, 2011, at 16:10 , Tamas Papp wrote:
> >> 
> >>> I thought about that, but I got this error even when I regenerated the
> >>> instances according to the new layout.  Of course, I don't know how
> >>> deeply SBCL inlines the layout, so it could happen that I forgot to
> >>> recompile something, but I did an asdf reload and still got the error
> >>> message.
> >> 
> >> 
> >> Quote from The Hyperspec:
> >> 
> >> "The consequences of redefining a defstruct structure are undefined."
> >> 
> >> Maybe this has been mentioned already, and maybe SBCL makes more of
> >> an effort to support structure redefinition, but still... 
> > 
> > Sure, the standard basically says that I should not do it, and should
> > not complain if I do and bad things happen.  Which is a reasonable
> > attitude I guess.
> > 
> > Is there a way I could have quick-dirty print-object methods defined
> > for classes?  Does not need to be readable, but it is so nice to punt
> > on the nice printed representations of structures when I am trace'ing.
> > Otherwise, I would be much better off with classes.  Maybe someone
> > already has a mixin class or something similar in a library that I
> > have missed.
> > 
> > Tamas
> 
> 
> Maybe something like this (which uses a bit of MOP, namely class-slots and slot-definition-name):
> 
> (defmethod print-object ((object my-base-class-or-mixin) stream)
>   (print-unreadable-object (object stream :type t :identity t)
>     (dolist (slot-def (class-slots (class-of object)))
>       (let ((slot-name (slot-definition-name slot-def)))
>         (format stream "~&~a: ~a~%" slot-name (slot-value object slot-name))))))

Thanks, I also found fare-mop:simple-print-object-mixin which does
something like this.

Best,

Tamas