From andrew_philpot at yahoo.com Wed Aug 12 19:25:10 2009 From: andrew_philpot at yahoo.com (Andrew Philpot) Date: Wed, 12 Aug 2009 12:25:10 -0700 (PDT) Subject: [cl-serializer-devel] Two issues, one resolved, for CL-SERIALIZER in Allegro 8.1 Message-ID: <379975.18355.qm@web65413.mail.ac4.yahoo.com> #1. (SETF LOGBITP) is not defined in ACL 8.1 (nor in CLISP), and as far as I can tell isn't part of the standard nor can be portably defined. I'm changing (SETF (LOGBITP x y) z) to (SETF y (DPB z (BYTE 1 x) y) (2 places). Maybe (SETF LDB) is better? #2. It seems that cl-serializer assumes that objects of type BASE-CHAR must be 8-bit characters, and thus can be encoded in a single byte. But this isn't the case in Allegro, where (TYPEP (CODE-CHAR 257) 'BASE-CHAR) is true. I didn't find a good way to get into the type detection logic to cause multi-byte characters to do the right thing. Suggestions? Andrew From andrew_philpot at yahoo.com Wed Aug 12 22:33:13 2009 From: andrew_philpot at yahoo.com (Andrew Philpot) Date: Wed, 12 Aug 2009 15:33:13 -0700 (PDT) Subject: [cl-serializer-devel] (no subject) Message-ID: <866382.67920.qm@web65415.mail.ac4.yahoo.com> [also sent to pc at p-cos.net] CL-SERIALIZER calls CLOSER-MOP:SLOT-DEFINITION-ALLOCATION on a class object that might be a STANDARD-CLASS and might not (e.g. a STRUCTURE-CLASS).? In SBCL, both of these are defined, but in Allegro 8.1, the only method on this generic function is on STANDARD-CLASS. Does it make sense to (1) extend the GF for the Allegro case in CLOSER-MOP to return NIL or some other sensible value (2) embed an appropriate check in the CL-SERIALIZER client code or (3) do you have another suggestion? Thanks, Andrew Philpot USC ISI From attila.lendvai at gmail.com Wed Aug 12 23:30:17 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 13 Aug 2009 01:30:17 +0200 Subject: [cl-serializer-devel] (no subject) In-Reply-To: <866382.67920.qm@web65415.mail.ac4.yahoo.com> References: <866382.67920.qm@web65415.mail.ac4.yahoo.com> Message-ID: > Does it make sense to (1) extend the GF for the Allegro case in > CLOSER-MOP to return NIL or some other sensible value (2) embed an > appropriate check in the CL-SERIALIZER client code or (3) do you have > another suggestion? my take is basically (2): define separate (de)serializers for structure-object's and standard-object's instead of a shared (def serializer-deserializer slot-object ...) and use them appropriately from (def serializer-deserializer structure-object ... ) and (def serializer-deserializer standard-object +standard-object-code+ ...). maybe dealing with funcallable-standard-class, too if necessary. this requires a good knowledge of the related part of the standard, and/or an environment with many enough lisps to be able to run practical tests quickly. i personally have neither at the moment, but Levy may have some words on this. patches are very welcome, though! :) -- attila From attila.lendvai at gmail.com Thu Aug 13 00:10:19 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 13 Aug 2009 02:10:19 +0200 Subject: [cl-serializer-devel] Two issues, one resolved, for CL-SERIALIZER in Allegro 8.1 In-Reply-To: <379975.18355.qm@web65413.mail.ac4.yahoo.com> References: <379975.18355.qm@web65413.mail.ac4.yahoo.com> Message-ID: > #1. (SETF LOGBITP) is not defined in ACL 8.1 (nor in CLISP), and as > far as I can tell isn't part of the standard nor can be portably > defined. > > I'm changing (SETF (LOGBITP x y) z) > to (SETF y (DPB z (BYTE 1 x) y) ? ? ?(2 places). > Maybe (SETF LDB) is better? Levy is in the middle of a big refactor/cleanup of all our projects, so i don't want to commit this before syncing up: (defmacro bit-value (index integer) `(logbitp index integer)) (define-setf-expander bit-value (index integer &environment env) (multiple-value-bind (temps vals stores store-form access-form) (get-setf-expansion integer env) (with-unique-names (ind store) (bind ((stemp (first stores))) (values `(,ind , at temps) `(,index , at vals) (list store) `(let ((,stemp (dpb (if ,store 1 0) (byte 1 ,ind) ,access-form))) ,store-form ,store) `(logbitp ,ind ,access-form)))))) > #2. It seems that cl-serializer assumes that objects of type > BASE-CHAR must be 8-bit characters, and thus can be encoded in a > single byte. But this isn't the case in Allegro, where (TYPEP > (CODE-CHAR 257) 'BASE-CHAR) is true. I didn't find a good way to > get into the type detection logic to cause multi-byte characters to > do the right thing. Suggestions? my first take on this is that on platforms where there's no difference between character and base-char, there's no point in fooling around with simple-base-string's, which are optimizations anyway. so, some #+ magic could get rid of this optimization where it is pointless anyway... -- attila From andrew_philpot at yahoo.com Thu Aug 13 17:51:24 2009 From: andrew_philpot at yahoo.com (Andrew Philpot) Date: Thu, 13 Aug 2009 10:51:24 -0700 (PDT) Subject: [cl-serializer-devel] (no subject) Message-ID: <197757.97744.qm@web65416.mail.ac4.yahoo.com> Date:? ? Thu, 13 Aug 2009 13:43:14 +0200 From:? ? Pascal Costanza To:? ? ? Andrew Philpot Subject: Re: CLOSER-MOP:SLOT-DEFINITION-ALLOCATION On 12 Aug 2009, at 23:26, Andrew Philpot wrote: > [also redirected to cl-serializer-devel] [I didn't see that in the headers, so I don't know how to respond to cl-serializer-devel.] > CL-SERIALIZER calls CLOSER-MOP:SLOT-DEFINITION-ALLOCATION on a class > object that might be a STANDARD-CLASS and might not (e.g. a > STRUCTURE-CLASS).? In SBCL, both of these are defined, but in Allegro > 8.1, the only method on this generic function is on STANDARD-CLASS. > Does it make sense to (1) extend the GF for the Allegro case in > CLOSER-MOP to return NIL or some other sensible value (2) embed an > appropriate check in the CL-SERIALIZER client code or (3) do you have > another suggestion? Thanks a lot for asking. The CLOS MOP specification specifies methods for these accessor functions only for the CLOS metaobject classes, but explicitly not for structure classes (or other entities). Since Common Lisp implementations are allowed to do whatever they want for structure classes, I cannot ensure that whatever I want to define for structure classes in Closer to MOP will actually be portable (now and in the future). So I prefer not to touch structure classes. I think the best option for you is to provide your own layer on top of the CLOS MOP that abstracts away from these differences. So define something like: (defgeneric cl-serializer:slot-definition-allocation (...) ???(:method (... closer-mop:standard-slot-definition ...) ? ? (closer-mop:slot-definition-allocation ...)) ???(:method (... structure-slot ...) ...)) I hope this helps, Pascal - -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium