On Tue, 07 Aug 2007 18:52:42 +0200, Tamas Papp wrote:
> I define this simple class:
>
> (defclass rgb ()
> ((red :initform 0d0 :type double-float :initarg :red :accessor red)
> (green :initform 0d0 :type double-float :initarg :green :accessor
> green) (blue :initform 0d0 :type double-float :initarg :blue
> :accessor blue)))
>
> (defmethod print-object ((obj rgb) stream)
> (print-unreadable-object (obj stream :type t)
> (with-slots (red green blue) obj
> (format stream "red: ~a green: ~a blue: ~a" red green blue))))
>
> (defconstant +white+ (make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0))
Stop right there! Read your CLHS for defconstant :
"If a defconstant form appears as a top level form, the compiler must
recognize that name names a constant variable. An implementation may
choose to evaluate the value-form at compile time, load time, or both.
Therefore, users must ensure that the initial-value can be evaluated at
compile time (regardless of whether or not references to name appear in
the file) and that it always evaluates to the same value."
Now you may want to note :
(eq (make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0)
(make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0))
=> ?
Then you can either try something like DEFINE-CONSTANT from the SBCL
manual, or DEFVAR, DEFINE-SYMBOL-MACRO, etc etc.
hth,
drewc
> ;; this one gives the error message:
> ;; don't know how to dump #<RGB red: 1.0d0 green: 1.0d0 blue: 1.0d0>
> ;; (default MAKE-LOAD-FORM method called). (defun foo (&optional (color
> +white+))
> (+ (red color) (green color) (blue color)))
>
> ;; this one works fine
> (defun bar (&key (color +white+))
> (+ (red color) (green color) (blue color)))
>
> I would like to learn what is causing the error and how I can avoid it.
>
> Tamas
--
Posted via a free Usenet account from http://www.teranews.com
Drew Crampsie <·············@gmail.com> writes:
> On Tue, 07 Aug 2007 18:52:42 +0200, Tamas Papp wrote:
>
>> I define this simple class:
>>
>> (defclass rgb ()
>> ((red :initform 0d0 :type double-float :initarg :red :accessor red)
>> (green :initform 0d0 :type double-float :initarg :green :accessor
>> green) (blue :initform 0d0 :type double-float :initarg :blue
>> :accessor blue)))
>>
>> (defmethod print-object ((obj rgb) stream)
>> (print-unreadable-object (obj stream :type t)
>> (with-slots (red green blue) obj
>> (format stream "red: ~a green: ~a blue: ~a" red green blue))))
>>
>> (defconstant +white+ (make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0))
>
> Stop right there! Read your CLHS for defconstant :
>
> "If a defconstant form appears as a top level form, the compiler must
> recognize that name names a constant variable. An implementation may
> choose to evaluate the value-form at compile time, load time, or both.
> Therefore, users must ensure that the initial-value can be evaluated at
> compile time (regardless of whether or not references to name appear in
> the file) and that it always evaluates to the same value."
>
> Now you may want to note :
>
> (eq (make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0)
> (make-instance 'rgb :red 1d0 :green 1d0 :blue 1d0))
>
> => ?
>
> Then you can either try something like DEFINE-CONSTANT from the SBCL
> manual, or DEFVAR, DEFINE-SYMBOL-MACRO, etc etc.
Thanks, but this doesn't solve my problem. I am aware of what you
mentioned, and I am using the workaround suggested in the SBCL manual.
But for this simplified example, I wanted to keep things standard.
Any suggestions about the original question would still be welcome --
at least to see if this happens in other Lisps or is something SBCL
specific.
Tamas
>> ;; this one gives the error message:
>> ;; don't know how to dump #<RGB red: 1.0d0 green: 1.0d0 blue: 1.0d0>
>> ;; (default MAKE-LOAD-FORM method called). (defun foo (&optional (color
>> +white+))
>> (+ (red color) (green color) (blue color)))
>>
>> ;; this one works fine
>> (defun bar (&key (color +white+))
>> (+ (red color) (green color) (blue color)))
>>
>> I would like to learn what is causing the error and how I can avoid it.
>>
>> Tamas
>
> --
> Posted via a free Usenet account from http://www.teranews.com
From: Kent M Pitman
Subject: Re: error: don't know how to dump ..., &key vs &optional
Date:
Message-ID: <u8x8mwm5j.fsf@nhplace.com>
Tamas Papp <······@gmail.com> writes:
> Any suggestions about the original question would still be welcome --
> at least to see if this happens in other Lisps or is something SBCL
> specific.
Dunno SBCL but it may not matter...
The compiler is probably trying to dump out your RGB instance to the
compiled file, since you're using DEFCONSTANT.
See, for example:
http://www.lispworks.com/documentation/HyperSpec/Body/03_bd.htm
Just changing that to DEFPARAMETER would probably fix it since then
the object would not be in the compiled file. A print-object method
would not help, and incidentally, if it did, your method is defined
to signal an error. The default MAKE-LOAD-FORM for a struct would
work, but the one for classes I don't think will. [I haven't looked
at this in a while.] See also:
http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ld_.htm
I seriously doubt the &optional vs &key is making a difference.
Maybe it just only warns you once and you're assuming one works
and one doesn't.
Kent M Pitman <······@nhplace.com> writes:
> Tamas Papp <······@gmail.com> writes:
>
>> Any suggestions about the original question would still be welcome --
>> at least to see if this happens in other Lisps or is something SBCL
>> specific.
>
> Dunno SBCL but it may not matter...
>
> The compiler is probably trying to dump out your RGB instance to the
> compiled file, since you're using DEFCONSTANT.
>
> See, for example:
> http://www.lispworks.com/documentation/HyperSpec/Body/03_bd.htm
>
> Just changing that to DEFPARAMETER would probably fix it since then
> the object would not be in the compiled file. A print-object method
> would not help, and incidentally, if it did, your method is defined
> to signal an error. The default MAKE-LOAD-FORM for a struct would
> work, but the one for classes I don't think will. [I haven't looked
> at this in a while.] See also:
>
> http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ld_.htm
>
> I seriously doubt the &optional vs &key is making a difference.
> Maybe it just only warns you once and you're assuming one works
> and one doesn't.
Thank you very much. Following the second link, I think I fixed the
problem using
(defmethod make-load-form ((obj rgb) &optional environment)
(declare (ignore environment))
`(make-instance 'rgb :red ',(red obj) :green',(green obj) :blue ',(blue obj)))
Tamas
Nikodemus Siivola <·········@random-state.net> writes:
> On Aug 8, 10:56 am, Tamas Papp <······@gmail.com> wrote:
>
>> (defmethod make-load-form ((obj rgb) &optional environment)
>> (declare (ignore environment))
>> `(make-instance 'rgb :red ',(red obj) :green',(green obj) :blue ',(blue obj)))
>
> You may also want to look at MAKE-LOAD-FORM-SAVING-SLOTS.
Thanks Nikodemus.
A question: the rgb class has derived classes with extra slots (alpha
channels, etc). It would be nice if I could just write this method
once for all of them. Is there a way to get the slot names for a
class of an object as a list?
Thanks,
Tamas
From: Thomas A. Russ
Subject: Re: error: don't know how to dump ..., &key vs &optional
Date:
Message-ID: <ymihcn9ud1m.fsf@blackcat.isi.edu>
Tamas Papp <······@gmail.com> writes:
> Nikodemus Siivola <·········@random-state.net> writes:
>
> > On Aug 8, 10:56 am, Tamas Papp <······@gmail.com> wrote:
> >
> >> (defmethod make-load-form ((obj rgb) &optional environment)
> >> (declare (ignore environment))
> >> `(make-instance 'rgb :red ',(red obj) :green',(green obj) :blue ',(blue obj)))
> >
> > You may also want to look at MAKE-LOAD-FORM-SAVING-SLOTS.
>
> Thanks Nikodemus.
>
> A question: the rgb class has derived classes with extra slots (alpha
> channels, etc). It would be nice if I could just write this method
> once for all of them.
I think that is what MAKE-LOAD-FORM-SAVING-SLOTS does. From the
Hyperspec, it seems that if you leave the value of the slot-namess
keyword unspecified, you will get exactly the behavior you want:
"Slot-names is a list of the names of the slots to preserve. If
slot-names is not supplied, its value is all of the local slots"
There is further a note that this can be useful in writing
MAKE-LOAD-FORM methods. Try
(defmethod make-load-form ((obj rgb) &optional environment)
(make-load-form-saving-slots obj :environment environment))
and see if it does what you want.
> Is there a way to get the slot names for a
> class of an object as a list?
This requires using the MOP. Look for a function named CLASS-SLOTS
using apropos:
(apropos "CLASS-SLOTS")
to see if your implementation has this available.
> Thanks,
>
> Tamas
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> I think that is what MAKE-LOAD-FORM-SAVING-SLOTS does. From the
> Hyperspec, it seems that if you leave the value of the slot-namess
> keyword unspecified, you will get exactly the behavior you want:
>
> "Slot-names is a list of the names of the slots to preserve. If
> slot-names is not supplied, its value is all of the local slots"
Thank you, I missed that.
> There is further a note that this can be useful in writing
> MAKE-LOAD-FORM methods. Try
>
> (defmethod make-load-form ((obj rgb) &optional environment)
> (make-load-form-saving-slots obj :environment environment))
>
> and see if it does what you want.
It works perfectly.
Tamas
Larry Clapp <·····@theclapp.org> wrote:
+---------------
| Rob Warnock <····@rpw3.org> wrote:
| > Note that depending on the implementation this might require having
| > *PRINT-CIRCLE* set to T for the MAKE-LOAD-FORM to work, e.g.:
| ...
| > cmu> (make-load-form *x*)
| > (ALLOCATE-INSTANCE (FIND-CLASS 'FOO))
| > (PROGN
| > (SETF (SLOT-VALUE #S(FOO :A 12 :B BAZ :C "string") 'A) '12)
| > (SETF (SLOT-VALUE #S(FOO :A 12 :B BAZ :C "string") 'B) 'BAZ)
| > (SETF (SLOT-VALUE #S(FOO :A 12 :B BAZ :C "string") 'C) '"string"))
| > cmu>
| >
| > Now that's probably *not* going to "do what you want"!! ;-}
| > But this may:
| > cmu> (setf *print-circle* t)
| > T
| > cmu> (make-load-form *x*)
| > (ALLOCATE-INSTANCE (FIND-CLASS 'FOO))
| > (PROGN
| > (SETF (SLOT-VALUE #1=#S(FOO :A 12 :B BAZ :C #2="string") 'A) '12)
| > (SETF (SLOT-VALUE #1# 'B) 'BAZ)
| > (SETF (SLOT-VALUE #1# 'C) '#2#))
| > cmu>
|
| I am not familiar with the semantics of MAKE-LOAD-FORM. Are you
| telling me it works by way of READ-FROM-STRING? Otherwise, I don't
| understand your example.
+---------------
No, I was mistaken [as I was kindly advised off-list].
See, I was just noodling around in the REPL and observed that:
(1) MAKE-LOAD-FORM's results were not printed in a useful form
[required object identities were lost]; and
(2) printing with *PRINT-CIRCLE* set to T made it *appear*
to be more useful; but
(3) later I realized that the above PROGN form doesn't return a
useful value, and what you really need for the second return
value of MAKE-LOAD-FORM to be usable across a WRITE/READ cycle
is for it to look like this:
cmu> (PROGN
(SETF (SLOT-VALUE #1=#S(FOO :A 12 :B BAZ :C #2="string") 'A) '12)
(SETF (SLOT-VALUE #1# 'B) 'BAZ)
(SETF (SLOT-VALUE #1# 'C) '#2#)
#1#)
#S(FOO :A 12 :B BAZ :C "string")
cmu>
But since CMUCL's MAKE-LOAD-FORM *doesn't* return the latter,
my whole assumption was/is flawed.
So, sorry for the confusion. "Never mind..."
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607