From: Christophe R. <cs...@ca...> - 2003-06-09 08:05:21
|
Daniel Barlow <da...@us...> writes: Two comments... > +(defmacro def-stream-class (name superclasses slots &rest options) > + (let ((slots (copy-tree slots))) > + (dolist (slot slots) (remf (cdr slot) 'sb-pcl::location)) > + `(defclass ,name ,superclasses ,slots ,@options))) > [...] > - (j-listen :type j-listen-fn sb-pcl::location 18) > + (j-listen :initform #'sb-kernel:ill-in :type j-listen-fn sb-pcl::location 18) For non-funcallable-instances, SBCL's PCL now respects COMPUTE-SLOTS return value for deciding slot locations. Maybe this is what you want to be using for those location things? > - (t (error "Don't know how to handle input handle &A" fd)))))) > + (t (error "Don't know how to handle input handle &S" fd)))))) I think this one is still wrong :-) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <ger...@t-...> - 2003-06-09 10:42:40
|
Christophe Rhodes <cs...@ca...> writes: > > - (j-listen :type j-listen-fn sb-pcl::location 18) > > + (j-listen :initform #'sb-kernel:ill-in :type j-listen-fn sb-pcl::location 18) > > For non-funcallable-instances, SBCL's PCL now respects COMPUTE-SLOTS > return value for deciding slot locations. Maybe this is what you want > to be using for those location things? FYI. I've sent Paul Foley a patch for CMUCL that implements a new slot option for specifying a slot location like in the diff above. The reason why such an option might be needed is that the simple-streams implementation contains a number of performance-critical paths where slots are accessed in non-methods, to avoid the generic function call overhead. I can't do much to speed up slot access outside of methods, alas, so something else has to be used. That something else could be what Allegro does to speed up its simple-streams: a mechanism for allocating slots to specified locations plus a WITH- macro, whose name I forget, and a SM macro for accessing slots within that WITH-, which translates slot access effectively to an SVREF. Not that I particularly like that design... |
From: Christophe R. <cs...@ca...> - 2003-06-09 11:03:56
|
ger...@t-... (Gerd Moellmann) writes: > Christophe Rhodes <cs...@ca...> writes: > >> > - (j-listen :type j-listen-fn sb-pcl::location 18) >> > + (j-listen :initform #'sb-kernel:ill-in :type j-listen-fn sb-pcl::location 18) >> >> For non-funcallable-instances, SBCL's PCL now respects COMPUTE-SLOTS >> return value for deciding slot locations. Maybe this is what you want >> to be using for those location things? > > I've sent Paul Foley a patch for CMUCL that implements a new slot > option for specifying a slot location like in the diff above. > > The reason why such an option might be needed is that the > simple-streams implementation contains a number of > performance-critical paths where slots are accessed in non-methods, to > avoid the generic function call overhead. What's wrong with MOP:STANDARD-INSTANCE-ACCESS coupled with a method on MOP:COMPUTE-SLOTS to allocate those slots which are accessed in the critical path in known locations? As far as I can tell, this is what MOP:STANDARD-INSTANCE-ACCESS is meant to be for. Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <ger...@t-...> - 2003-06-09 11:36:45
|
Christophe Rhodes <cs...@ca...> writes: > What's wrong with MOP:STANDARD-INSTANCE-ACCESS coupled with a method > on MOP:COMPUTE-SLOTS to allocate those slots which are accessed in the > critical path in known locations? As far as I can tell, this is what > MOP:STANDARD-INSTANCE-ACCESS is meant to be for. I wrote a metaclass for Paul awhile ago that does this, but using a metaclass clashes with the simple-streams specification, IIRC. IMHO, the simple-streams design is leaking ACL-specific implementation details in this respect. It's certainly not very MOPish. |
From: Christophe R. <cs...@ca...> - 2003-06-09 12:28:49
|
ger...@t-... (Gerd Moellmann) writes: > Christophe Rhodes <cs...@ca...> writes: > >> What's wrong with MOP:STANDARD-INSTANCE-ACCESS coupled with a method >> on MOP:COMPUTE-SLOTS to allocate those slots which are accessed in the >> critical path in known locations? As far as I can tell, this is what >> MOP:STANDARD-INSTANCE-ACCESS is meant to be for. > > I wrote a metaclass for Paul awhile ago that does this, but using a > metaclass clashes with the simple-streams specification, IIRC. Do you remember what gave you that impression? A quick skim of <http://www.franz.com/support/documentation/6.2/doc/streams.htm> didn't cause anything to leap to mind; since defining stream classes goes through DEF-STREAM-CLASS, that can easily add a (:METACLASS SIMPLE-STREAM-CLASS) option to the DEFCLASS that's produced. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: <ger...@t-...> - 2003-06-09 12:38:56
|
Christophe Rhodes <cs...@ca...> writes: > > I wrote a metaclass for Paul awhile ago that does this, but using a > > metaclass clashes with the simple-streams specification, IIRC. > > Do you remember what gave you that impression? I'm afraid I don't remember; it's too long ago already. And I didn't keep the mails either, it seems. Maybe Paul remembers. |
From: David L. <da...@li...> - 2003-06-09 12:40:25
|
Quoting Christophe Rhodes (cs...@ca...): > Do you remember what gave you that impression? A quick skim of > <http://www.franz.com/support/documentation/6.2/doc/streams.htm> > didn't cause anything to leap to mind; since defining stream classes > goes through DEF-STREAM-CLASS, that can easily add a (:METACLASS > SIMPLE-STREAM-CLASS) option to the DEFCLASS that's produced. That is my hope, too. I am using simple streams for BLOBs here, so everything works out best when a BLOB-STREAM is a PERSISTENT-CLASS. Not sure how that interacts with optimized stream slot access, but it seems to work. However, I don't see why the ACL approch would not be suitable. Granted, it looks slightly ugly. But on the plus side it allows a simple implementation using S-I-A as Christophe suggested, doesn't it? |