From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Oct 24 18:18:46 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22330; Mon, 24 Oct 88 18:18:46 PDT Received: from PECAN.CS.ROCHESTER.EDU ([192.5.53.206]) by SAIL.Stanford.EDU with TCP; 24 Oct 88 18:16:16 PDT Received: from DOUGHNUT.CS.ROCHESTER.EDU by PECAN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 4702; Mon 24-Oct-88 21:07:30 EDT Date: Mon, 24 Oct 88 21:06 EDT From: Brad Miller Subject: Re: Issue: EVAL-OTHER (Version 2) To: Jon L White Cc: masinter.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8810210017.AA06100@bhopal> Message-Id: <19881025010655.7.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Sender: miller@CS.ROCHESTER.EDU Reply-To: miller@CS.ROCHESTER.EDU Organization: University of Rochester, Department of Computer Science Postal-Address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627 Phone: 716-275-1118 Date: Thu, 20 Oct 88 17:17:51 PDT From: Jon L White re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. I can't agree with this at all. CL is an extremely useful programming language, and with CLOS added it is incredibly more useful. EVAL is a boringly obscure operation to apply to any piece of data -- it merely decodes the syntatic means by which programs are written. Writing programs encoded as strings rather than lists and symbols, or encoded in *any* other random datatype, is hardly a great step forward. While that last sentence might be open to continuing theoretical debate, there is the practical observation that MacLisp/NIL *did* make such an extension (using the object-oriented system called EXTEND), and there were virtually no meaningful uses of it. [I'm not 100% sure but I think Glenn Burke may have used it somehow in the Layered System Building project. Apologies, if that use was "meaningful".] In fact, the EVAL-related extension that really has some vocal supporters behind it is to *increase* the level on standardization in the coding of EVAL, so that research projects into the likes of debuggers and window systems can put more "hooks" into the interpreter. See Henry Lieberman's "Common Eval" proposal. -- JonL -- I plan on writing you a response to this, but I'm currently swamped; just to let you know that my silence isn't agreement. I suspect the fault was mostly mine: I only gave a trivial example of such use, and I can give much better ones from my work on the RHET project. The short cleanup is that while theoretically a full-blown generic EVAL is "interesting", I certainly *don't* consider it practical. I'm simply trying to allow the user to specify an eval-function for user created types, rather than having them always self-eval. Generating code for these types as (EVAL-YOURSELF ) rather than doesn't seem to be a particularly difficult implementation problem, nor do I think it has a particular bad effect on debuggers. Appropriate method combination for EVAL-YOURSELF should allow for a debugger hook (though I've not thought this through carefully). Thanks for your response. More later, ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller} From Owners-CommonLoops.PA@Xerox.COM Wed Oct 26 12:13:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23847; Wed, 26 Oct 88 12:13:15 PDT Received: from Riesling.ms by ArpaGateway.ms ; 26 OCT 88 10:31:34 PDT Return-Path: Redistributed: CommonLoops.PA Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 26 OCT 88 10:26:49 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05294; 22 Oct 88 20:35 BST Date: Sat, 22 Oct 88 20:46:08 BST Message-Id: <11455.8810221946@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: PCL/CLOS performance To: Gregor.pa@Xerox.COM In-Reply-To: Gregor.pa@com.xerox's message of Thu, 20 Oct 88 10:38 PDT Cc: kempf@sun.com, CommonLoops.PA@Xerox.COM > Date: Fri, 14 Oct 88 15:27:30 BST > From: Jeff Dalton > I assume that since you have sent your message (6 days) enough other > messages have gone by to clarify this. But this is important enough > that it is worth addressing directly. Actually, I haven't seen that many replies, and none said all that you did. So thank you. > Well, (1) is it not the case that TICLOS is not PCL? If so, it may > not say all that much about PCL performance. > > Yes, TICLOS is not PCL. But it has an architecture quite similar to the > one PCL has. There are some differences which stem from having the kind > of hardware tag checking they have, and some other differences which are > a matter of differing philosophy. OK. One reason I asked is that we're often told in WG-16 meetings not to judge CLOS by PCL but rather (so it seems) by TICLOS. And by a sort of transitivity argument it seemed that we shouldn't judge PCL by TICLOS. I also asked in a slightly earlier message whether there were any implementations other than TICLOS and PCL and whether any were on stock hardware (as opposed to adaptable to stock hardware). My motives there were similar, I suppose, namely to find out what the evidence for CLOS performance amounts to. I don't mind if CLOS and PCL turn out to be fast. Indeed, I would be pleased. > (2) If a Common Lisp > is reasonably fast otherwise but slow for PCL, it is at least > reasonable to suspect PCL rather than the Common Lisp's code > generation. > > No No No. If an unoptimized port of PCL is slow in a Common Lisp which > otherwise has good performance it says absolutely nothing about real PCL > performance. PCL is fundamentally designed to require implementation > specific tuning. There are certain critical code sequences which must > be "hand coded" because no sane Common Lisp compiler will emit the > proper code sequence. Now I understand. I thought the message I was answering had in mind that PCL was slow in KCL because KCL code generation was poor *in general*, not that certain adaptations hadn't been made. > The feature of PCL is that these code sequences are quite isolated, > quite small, and it should be possible to write them for any Common > Lisp (any one I have seen anyways). > Besides, not everyone can afford a super-CL. The object system should > be such that it is not too hard to get performance from it comparable > to that of the rest of CL. > > I think the fact that PCL can be gotten to competitive performance in > any Common Lisp satisifies this concern. From Owners-CommonLoops.pa@Xerox.COM Wed Oct 26 12:33:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24050; Wed, 26 Oct 88 12:33:31 PDT Received: from Burger.ms by ArpaGateway.ms ; 26 OCT 88 12:05:14 PDT Return-Path: Redistributed: CommonLoops.pa Received: from mitre-bedford.ARPA ([26.3.0.66]) by Xerox.COM ; 26 OCT 88 12:00:43 PDT From: jcf%linus@mitre-bedford.ARPA Posted-From: The MITRE Corp., Bedford, MA Received: from kochel.sun.uucp by linus.MENET (3.2/4.7) id AA01127; Wed, 26 Oct 88 14:57:03 EDT Posted-Date: Wed, 26 Oct 88 15:00:45 EDT Received: by kochel.sun.uucp (3.2/SMI-3.0DEV3) id AA02353; Wed, 26 Oct 88 15:00:45 EDT Date: Wed, 26 Oct 88 15:00:45 EDT Message-Id: <8810261900.AA02353@kochel.sun.uucp> To: CommonLoops.pa@Xerox.COM Cc: jcf@mitre-bedford.ARPA Subject: Request for Flavors subset in PCL Does anyone know where I can get the source code for a basic Flavors subset written in PCL or in Common Lisp? Thanks for any information. Jim Fohlin linus!jcf@MITRE-BEDFORD.ARPA (617) 271-7505 linus!jcf.UUCP From Owners-commonloops.pa@Xerox.COM Thu Oct 27 12:58:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA09513; Thu, 27 Oct 88 12:58:53 PDT Received: from Riesling.ms by ArpaGateway.ms ; 27 OCT 88 11:18:03 PDT Return-Path: <@EN-C06.Prime.COM,@ENB.Prime.COM,@ENI.Prime.COM,@s66.Prime.COM:SOBO@s66.Prime.COM> Redistributed: commonloops.pa Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 27 OCT 88 11:15:04 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 27 Oct 88 14:15:21 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 27 Oct 88 14:02:22 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 27 Oct 88 14:08:03 EDT Received: (from user SOBO) by s66.Prime.COM; 27 Oct 88 13:59:32 EST To: commonloops.pa@Xerox.COM From: SOBO@s66.Prime.COM Date: 27 Oct 88 13:59:32 EST Message-Id: <881027-111803-15700@Xerox> To: (commonloops.pa@xerox.com) From: Nadine Sobolevitch (sobo@s66) Date: 27 Oct 88 1:57 PM Subject: New version of Symbolics Window Inspector patch for AAAI-PCL. This may be a bit late in the day, but I just switched to AAAI-PCL and updated my Inspector patches to handle the changes. ;;; -*- Mode: LISP; Package: TV; Base: 8; Syntax: Zetalisp -*- ;;;This file provides changes to the Symbolics Window Inspector to make it behave ;;;in a useful way vis-a-vis Portable Common Loops instances. ;;;This code has been updated to run in 8/28/88 PCL. ;;;Also, it now handles shared and unbound slots in a nice way. ;;;PCL is the Portable Common Loops package. ;;;PCL:IWMC-CLASS is the Common Lisp "type-of" a Portable Common Loops object. ;;;New code (not in the default Symbolics Window Inspector) is in lower case. ;;;I have eliminated use of multiple fonts in this file in order to make this code ;;;easily readable even on ASCII terminals. However, bear in mind that any font used ;;;to write a string in this file will be preserved in the Inspector window. Thus, ;;;in my own code, I write " [shared slot]" and "[unbound slot]" in italics in order ;;;to make the Inspector display easier to read. ;;;Shuts up compiler redefinition query (record-source-file-name 'inspect-setup-object-display-list 'defun t) (DEFUN INSPECT-SETUP-OBJECT-DISPLAY-LIST (OBJECT WINDOW &OPTIONAL TOP-ITEM LABEL &AUX DISPLAY-LIST ARG STR ALT-PRINT-FUN FIRST-TOP-ITEM OBJ-LABEL (OOBJECT OBJECT)) (MACROLET ((INSPECT-DATA-TYPE (TYPE) `(MULTIPLE-VALUE (DISPLAY-LIST ARG ALT-PRINT-FUN FIRST-TOP-ITEM OBJ-LABEL) (SEND WINDOW ,(INTERN (STRING-APPEND "OBJECT-" TYPE) SI:PKG-KEYWORD-PACKAGE) OBJECT)))) (FLET ((INSPECT-TYPECASE () (CL:TYPECASE OBJECT (INSPECTOR-STACK-FRAME (INSPECT-DATA-TYPE STACK-FRAME)) (FLAVOR-MESSAGE-HANDLER (INSPECT-DATA-TYPE FLAVOR-MESSAGE-HANDLER)) (SI:BASIC-HASH-TABLE (INSPECT-DATA-TYPE BASIC-HASH-TABLE)) (pcl:iwmc-class (inspect-data-type class-instance)) (SCL:STRUCTURE (INSPECT-DATA-TYPE NAMED-STRUCTURE)) (SCL:INSTANCE (INSPECT-DATA-TYPE INSTANCE)) (SCL:ARRAY (INSPECT-DATA-TYPE ARRAY)) (LIST (INSPECT-DATA-TYPE LIST)) (SYMBOL (INSPECT-DATA-TYPE SYMBOL)) (SYS:DYNAMIC-CLOSURE (INSPECT-DATA-TYPE CLOSURE)) (COMPILED-FUNCTION (INSPECT-DATA-TYPE COMPILED-FUNCTION)))) (INSPECT-FORCED-TYPE (TYPE) (COND ((SCL:EQUAL-TYPEP TYPE 'INSPECTOR-STACK-FRAME) (INSPECT-DATA-TYPE STACK-FRAME)) ((SCL:EQUAL-TYPEP TYPE 'FLAVOR-MESSAGE-HANDLER) (INSPECT-DATA-TYPE FLAVOR-MESSAGE-HANDLER)) ((SCL:EQUAL-TYPEP TYPE 'SI:BASIC-HASH-TABLE) (INSPECT-DATA-TYPE BASIC-HASH-TABLE)) ((scl:equal-typep type 'pcl:iwmc-class) (inspect-data-type class-instance)) ((SCL:EQUAL-TYPEP TYPE 'CL:STRUCTURE) (INSPECT-DATA-TYPE NAMED-STRUCTURE)) ((SCL:EQUAL-TYPEP TYPE 'SCL:INSTANCE) (INSPECT-DATA-TYPE INSTANCE)) ((SCL:EQUAL-TYPEP TYPE 'SCL:ARRAY) (INSPECT-DATA-TYPE ARRAY)) ((SCL:EQUAL-TYPEP TYPE 'LIST) (INSPECT-DATA-TYPE LIST)) ((SCL:EQUAL-TYPEP TYPE 'SYMBOL) (INSPECT-DATA-TYPE SYMBOL)) ((SCL:EQUAL-TYPEP TYPE 'DYNAMIC-CLOSURE) (INSPECT-DATA-TYPE CLOSURE)) ((SCL:EQUAL-TYPEP TYPE 'COMPILED-FUNCTION) (INSPECT-DATA-TYPE COMPILED-FUNCTION))))) (LOOP NAMED RETRY-TYPE-ANALYSIS DO (SETQ OBJECT (CATCH 'INSPECT-REAL-OBJECT ; IF THIS IS THROWN TO, ; THE VALUE IS A BETTER OBJECT TO LOOK AT. ; TOO BAD THE HEADER WON'T REVEAL THAT THIS ; HAPPENED. (INSPECT-FORCED-TYPE (CATCH 'INSPECT-FORCE-TYPE ; IS THIS IS THROWN TO, ; THE VALUE IS A BETTER TYPE TO ; LOOK AT. AGAIN, TOO BAD THAT THERE ; IS NO PROVISION TO ANNOTATE. (INSPECT-TYPECASE) (RETURN-FROM RETRY-TYPE-ANALYSIS NIL))) (RETURN-FROM RETRY-TYPE-ANALYSIS NIL)))))) (LIST OBJECT (OR ALT-PRINT-FUN 'INSPECT-PRINTER) ARG DISPLAY-LIST (OR TOP-ITEM FIRST-TOP-ITEM 0) (OR LABEL OBJ-LABEL (LIST NIL NIL NIL NIL (LABEL-STYLE (SEND WINDOW ':LABEL)) (IF (LISTP OOBJECT) "a list" (NSUBSTRING (SETQ STR (FORMAT NIL "~S~%" OOBJECT)) 0 (STRING-SEARCH-CHAR #\CR STR))))))) ;;;Needed revision because pcl:all-slots went away in 8/28/88 pcl. ;;;Also, needed to handle unbound slots. ;;;(incidentally, pcl:describe-instance does not do this!) (defmethod (:object-class-instance basic-inspect) (obj) (let* ((class (pcl:class-of obj)) (slots (loop for slotd in (pcl:class-slots class) for slot-name = (pcl:slotd-name slotd) collecting (list slot-name (pcl:slotd-allocation slotd) (if (pcl:slot-boundp obj slot-name) (pcl:slot-value obj slot-name) 'slot-unbound)))) (maxl -1) (result (list '("") `("A Common Loops instance of " (:item class ,class))))) (loop for (name allocation value) in slots when (eql allocation :instance) do (setq maxl (max (flatsize name) maxl)) else do (setq maxl (max (+ (flatsize name) 16) maxl)) ;room for " [shared slot]" finally (setq maxl (+ maxl 2))) (loop for (name allocation value) in slots do (push `((:item class-iv ,name) ,@(and (eql allocation :class) '(" [shared slot]")) (:colon ,maxl) ,(if (eql value 'slot-unbound) "[unbound slot]" `(:item class-ivvalue ,value))) result)) (nreverse result))) (defun (class-iv set-function) (item new-value object) (let ((slot (third (second item)))) (setf (pcl:slot-value object slot) new-value))) (defprop class-iv t only-when-modify) From Owners-commonloops.pa@Xerox.COM Thu Oct 27 17:54:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12253; Thu, 27 Oct 88 17:54:28 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 27 OCT 88 17:44:46 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 27 OCT 88 17:38:17 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 27 Oct 88 17:35:27 pdt Received: from loopback by hplwhh.HPL.HP.COM; Thu, 27 Oct 88 17:34:05 pdt To: cl-windows@SAIL.STANFORD.EDU Cc: commonloops.pa@Xerox.COM Subject: OBJECT-ORIENTED CLX X-Mailer: mh6.5 Date: Thu, 27 Oct 88 17:34:01 PDT Message-Id: <3463.594002041@hplwhh> From: Warren Harris The following is a very rough outline of how CLX might look if it were an object-oriented program. We've been kicking this idea around in our lab for a little while now and felt it was time to get some real feedback on whether this was a good idea or not. All comments are welcome. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; ;;;; AN OBJECT-ORIENTED CLX ;;;; ;;;; (A ROUGH DRAFT) ;;;; ;;;; Warren Harris, HP Labs ;;;; #| This document is an attempt to address some of the issues of combining CLX with object-oriented programming. It is the desire that this "low level" interface to X11 will be sufficient to implement higher level extensions such as those found in CLUE in a convenient and extensible way. Throughout this document we make use of the CLOS meta-object protocol. In particular, a new meta-class is defined, X-CLASS, which makes convenient the specification of objects allocated external to the Lisp process (in the X server). In this meta-class, a new slot-descriptor is defined, X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation, namely :X-SERVER. Specifying :X-SERVER allocation does not reserve space in the actual CLOS object for the value, but instead defines reader and writer methods which actually perform the X protocol requests. (There may be other slot-descriptor declarations necessary in the actual implementation, such as which position the argument takes in the protocol request, or how to convert between the Lisp representation and the protocol representation. For more difficult request functions, explicit DEFMETHOD forms must be written. However, it is still beneficial to think of these attributes as "slots", allocated in the X server process.) One difficulty with the old CLX model is that some objects are created in the server process simultaneous with their creation in the Lisp process. This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs. Other objects are created in the server process some time after their creation in the Lisp process. This includes DISPLAYs, and FONTs. This object-oriented version of CLX takes the uniform approach of delaying the creation of all server allocated objects until the OPEN-OBJECT generic function is called. This has some distinct advantages: 1. It allows MAKE-INSTANCE and the standard CLOS initialization to be used to create all CLX objects. 2. It allows the objects' states to be remembered between Lisp sessions. This second point is a significant advantage since Lisp images can typically be stored on disk via some SAVE-WORLD command. Lisp images with saved CLX objects can then be recreated numerous times. (Note: the way this works is that while a window is open, all :X-SERVER allocated instance variable accesses go through the X server. When the window is closed, the values of these slots as they currently exist in the server are re-cached in the lisp objects before the server object is actually destroyed. That way, the next time the window is opened the state is remembered.) Although this document describes vaporware at this point, it should be pointed out that all these concepts have been verified in an X10 Lisp interface developed by HP Labs called "Xenon". (Xenon is not distributable due to its heavy reliance on HP-CL's foreign function mechanism.) This document has also left out all the actual CLX function and macros. The intention is that most of the functions in the existing CLX document will become generic. They were not included here at the present time due to lazyness. |# ;;; X-OBJECT ;;; ;;; This class represents the root of the CLX object hierarchy. (defclass x-object () () (:metaclass x-class)) ;;; EXTERNAL-OBJECT ;;; ;;; These are objects which are allocated in the X server process. They must ;;; be explicitly opened and closed by the Lisp process. (defclass external-object (x-object) ((xid :type card32 :allocation :instance) (display :type display :reader display :allocation :instance)) (:metaclass x-class)) (defgeneric open-object (external-object)) (defgeneric close-object (external-object)) (defgeneric open-p (external-object)) ;;; X-PLIST-MIXIN ;;; ;;; These are objects with external X properties. It is an error to ;;; instantiate this class directly. (defclass x-plist-mixin (x-object) ((x-plist :type list :initform nil :initarg :x-plist :accessor x-plist :allocation :x-server)) (:metaclass x-class)) (defgeneric get-x-prop (x-plist-object x-prop-name &key type (start 0) end delete-p (result-type 'list) transform) (declare (type x-plist-mixin x-plist-object) (type xatom property) (type (or null xatom) type) (type array-index start) (type (or null array-index) end) (type boolean delete-p) (type type result-type) (type (or null (function (integer) t)) transform) (values data type format bytes-after))) (defgeneric set-x-prop (x-plist-object x-prop-name x-prop-value type format &key (mode :replace) (start 0) end transform) (declare (type x-plist-mixin x-plist-object) (type xatom x-prop-name type) (type (member 8 16 32) format) (type sequence x-prop-value) (type (member :replace :prepend :append) mode) (type array-index start) (type (or null array-index) end) (type (or null (function (t) integer)) transform))) (defgeneric rem-x-prop (x-plist-object x-prop-name) (declare (type x-plist-mixin x-plist-object) (type xatom x-prop-name))) ;;; DRAWABLE (defclass drawable (x-plist-mixin external-object) ((parent :type int16 :initform 0 :initarg :parent :reader parent :allocation :x-server) (outside-left :type int16 :initform 0 :initarg :outside-left :accessor outside-left :allocation :x-server) (outside-top :type int16 :initform 0 :initarg :outside-top :accessor outside-top :allocation :x-server) (inside-width :type card16 :initform 1 :initarg :inside-width :accessor inside-width :allocation :x-server) (inside-height :type card16 :initform 1 :initarg :inside-height :accessor inside-height :allocation :x-server) (border-width :type card16 :initform 0 :initarg :border-width :accessor border-width :allocation :x-server) (depth :type card16 :initform 0 :initarg :depth :accessor depth :allocation :x-server)) (:metaclass x-class)) ;;; WINDOW (defclass window (drawable) ((i/o-class :type (member :copy :input-output :input-only) :initform :copy :initarg :i/o-class :reader i/o-class :allocation :x-server) (visual :type (or (member :copy) visual) :initform :copy :initarg :visual :reader visual :allocation :x-server) (background-color :type (or null (member :none :parent-relative) pixel pixmap) :initform nil :initarg :background-color :accessor background-color :allocation :x-server) (border-color :type (or null (member :copy) pixel pixmap) :initform nil :initarg :border-color :accessor border-color :allocation :x-server) (window-gravity :type (or null win-gravity) :initform nil :initarg :window-gravity :accessor window-gravity :allocation :x-server) (bit-gravity :type (or null bit-gravity) :initform nil :initarg :bit-gravity :accessor bit-gravity :allocation :x-server) (backing-store :type (or null (member :not-useful :when-mapped :always)) :initform nil :initarg :backing-store :accessor backing-store :allocation :x-server) (backing-planes :type (or null pixel) :initform nil :initarg :backing-planes :accessor backing-planes :allocation :x-server) (backing-color :type (or null pixel) :initform nil :initarg :backing-color :accessor backing-color :allocation :x-server) (save-under :type (or null (member :on :off)) :initform nil :initarg :save-under :accessor save-under :allocation :x-server) (event-mask :type (or null event-mask) :initform nil :initarg :event-mask :accessor event-mask :allocation :x-server) (do-not-propagate-mask :type (or null device-event-mask) :initform nil :initarg :do-not-propagate-mask :accessor do-not-propagate-mask :allocation :x-server) (override-redirect :type (or null (member :on :off)) :initform nil :initarg :override-redirect :accessor override-redirect :allocation :x-server) (colormap :type (or null (member :copy) colormap) :initform nil :initarg :colormap :accessor colormap :allocation :x-server) (cursor :type (or null (member :none) cursor) :initform nil :initarg :cursor :accessor cursor :allocation :x-server) (colormap-installed-p :type boolean :reader colormap-installed-p :allocation :x-server) (all-event-masks :type mask32 :reader all-event-masks :allocation :x-server) (map-state :type (member :unmapped :unviewable :viewable) :reader map-state :allocation :x-server)) (:metaclass x-class)) (defgeneric (setf priority) (mode window &optional sibling)) ;;; PIXMAP (defclass pixmap (drawable) () (:metaclass x-class)) ;;; DISPLAY (defclass display (x-plist-mixin external-object) ((protocol-major-version :type card16 :reader protocol-major-version :allocation :x-server) (protocol-minor-version :type card16 :reader protocol-minor-version :allocation :x-server) (vendor-name :type string :reader vendor-name :allocation :x-server) (release-number :type card32 :reader release-number :allocation :x-server) (image-lsb-first-p :type boolean :reader image-lsb-first-p :allocation :x-server) (bitmap-formap :type bitmap-format :reader bitmap-formap :allocation :x-server) (pixmap-formats :type (list pixmap-format) :reader pixmap-formats :allocation :x-server) (roots :type (list screen) :reader roots :allocation :x-server) (motion-buffer-size :type card32 :reader motion-buffer-size :allocation :x-server) (max-request-length :type card16 :reader max-request-length :allocation :x-server) (min-keycode :type card8 :reader min-keycode :allocation :x-server) (max-keycode :type card8 :reader max-keycode :allocation :x-server) (error-handler :type (or (sequence (function (&rest key-vals))) (function (&rest key-vals))) :initform #'display-handle-error :initarg :error-handler :accessor error-handler :allocation :x-server) (flush-handler ;; this was called "display-after-function" :type (or null (function (display))) :initform nil :initarg :flush-handler :accessor flush-handler :allocation :x-server)) (:metaclass x-class)) ;;; SCREEN ;;; ;;; Screens need not be explicitly created and opened. In some sense, they ;;; are substructures of display objects. (defclass screen (x-object) ((root :type window :reader root :initarg :root :reader root :allocation :x-server) (width :type card16 :initarg :width :reader width :allocation :x-server) (height :type card16 :initarg :height :reader height :allocation :x-server) (width-in-millimeters :type card16 :initarg :width-in-millimeters :reader width-in-millimeters :allocation :x-server) (height-in-millimeters :type card16 :initarg :height-in-millimeters :reader height-in-millimeters :allocation :x-server) (depths :type (alist (image-depth depth) ((list visual-info) visuals)) :initarg :depths :reader depths :allocation :x-server) (root-depth :type image-depth :initarg :root-depth :reader root-depth :allocation :x-server) (root-visual :type card29 :initarg :root-visual :reader root-visual :allocation :x-server) (default-colormap :type colormap :initarg :default-colormap :reader default-colormap :allocation :x-server) (white-pixel :type pixel :initarg :white-pixel :reader white-pixel :allocation :x-server) (black-pixel :type pixel :initarg :black-pixel :reader black-pixel :allocation :x-server) (min-installed-maps :type card16 :initarg :min-installed-maps :reader min-installed-maps :allocation :x-server) (max-installed-maps :type card16 :initarg :max-installed-maps :reader max-installed-maps :allocation :x-server) (backing-stores :type (member :never :when-mapped :always) :initarg :backing-stores :reader backing-stores :allocation :x-server) (save-unders-p :type boolean :initarg :save-unders-p :reader save-unders-p :allocation :x-server) (event-mask-at-open :type mask32 :initarg :event-mask-at-open :reader event-mask-at-open :allocation :x-server)) (:metaclass x-class)) ;;; GCONTEXT (defclass gcontext (external-object) ((drawable :type drawable :initform nil :initarg :drawable :accessor drawable :allocation :x-server) (boolean-function :type (or null boole-constant) :initform nil :initarg :boolean-function :accessor boolean-function :allocation :x-server) (plane-mask :type (or null pixel) :initform nil :initarg :plane-mask :accessor plane-mask :allocation :x-server) (foreground-color :type (or null pixel) :initform nil :initarg :foreground-color :accessor foreground-color :allocation :x-server) (background-color :type (or null pixel) :initform nil :initarg :background-color :accessor background-color :allocation :x-server) (line-width :type (or null card16) :initform nil :initarg :line-width :accessor line-width :allocation :x-server) (line-style :type (or null (member :solid :dash :double-dash)) :initform nil :initarg :line-style :accessor line-style :allocation :x-server) (cap-style :type (or null (member :not-last :butt :round :projecting)) :initform nil :initarg :cap-style :accessor cap-style :allocation :x-server) (join-style :type (or null (member :miter :round :bevel)) :initform nil :initarg :join-style :accessor join-style :allocation :x-server) (fill-style :type (or null (member :solid :tiled :opaque-stippled :stippled)) :initform nil :initarg :fill-style :accessor fill-style :allocation :x-server) (fill-rule :type (or null (member :even-odd :winding)) :initform nil :initarg :fill-rule :accessor fill-rule :allocation :x-server) (arc-mode :type (or null (member :chord :pie-slice)) :initform nil :initarg :arc-mode :accessor arc-mode :allocation :x-server) (tile :type (or null pixmap) :initform nil :initarg :tile :accessor tile :allocation :x-server) (stipple :type (or null pixmap) :initform nil :initarg :stipple :accessor stipple :allocation :x-server) (ts-x :type (or null int16) :initform nil :initarg :ts-x :accessor ts-x :allocation :x-server) (ts-y :type (or null int16) :initform nil :initarg :ts-y :accessor ts-y :allocation :x-server) (font :type (or null fontable) :initform nil :initarg :font :accessor font :allocation :x-server) (subwindow-mode :type (or null (member :clip-by-children :include-inferiors)) :initform nil :initarg :subwindow-mode :accessor subwindow-mode :allocation :x-server) (exposures :type (or null (member :on :off)) :initform nil :initarg :exposures :accessor exposures :allocation :x-server) (clip-x :type (or null int16) :initform nil :initarg :clip-x :accessor clip-x :allocation :x-server) (clip-y :type (or null int16) :initform nil :initarg :clip-y :accessor clip-y :allocation :x-server) (clip-mask :type (or null (member :none) pixmap rect-seq) :initform nil :initarg :clip-mask :accessor clip-mask :allocation :x-server) (clip-ordering :type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) :initform nil :initarg :clip-ordering :accessor clip-ordering :allocation :x-server) (dash-offset :type (or null card16) :initform nil :initarg :dash-offset :accessor dash-offset :allocation :x-server) (dashes :type (or null (or card8 (sequence card8))) :initform nil :initarg :dashes :accessor dashes :allocation :x-server) (cache-p :type boolean :initform t :initarg :cache-p :accessor cache-p :allocation :x-server)) (:metaclass x-class)) ;;; CURSOR (defclass cursor (external-object) ((source :type pixmap :initarg :source :reader source :allocation :x-server) (mask :type (or null pixmap) :initform nil :initarg :mask :reader mask :allocation :x-server) (outside-left :type card16 :initarg :outside-left :reader outside-left :allocation :x-server) (outside-top :type card16 :initarg :outside-top :reader outside-top :allocation :x-server) (foreground-color :type color :initarg :foreground-color :accessor foreground-color :allocation :x-server) (background-color :type color :initarg :background-color :accessor background-color :allocation :x-server)) (:metaclass x-class)) ;;; GLIPH-CURSOR (defclass gliph-cursor (cursor) ((source-font :type font :initarg :source-font :reader source-font :allocation :x-server) (source-char :type card16 :initarg :source-char :reader source-char :allocation :x-server) (mask-font :type font :initarg :mask-font :reader mask-font :allocation :x-server) (mask-char :type card16 :initarg :mask-char :reader mask-char :allocation :x-server)) (:metaclass x-class)) ;;; FONT (defclass font (x-plist-mixin external-object) ((display :type display :initarg :display :reader display :allocation :x-server) (name :type stringable :initarg :name :reader name :allocation :x-server) (direction :type draw-direction :reader direction :allocation :x-server) (min-char :type card16 :reader min-char :allocation :x-server) (max-char :type card16 :reader max-char :allocation :x-server) (min-byte1 :type card8 :reader min-byte1 :allocation :x-server) (max-byte1 :type card8 :reader max-byte1 :allocation :x-server) (min-byte2 :type card8 :reader min-byte2 :allocation :x-server) (max-byte2 :type card8 :reader max-byte2 :allocation :x-server) (all-chars-exist-p :type boolean :reader all-chars-exist-p :allocation :x-server) (default-char :type card16 :reader default-char :allocation :x-server) (ascent :type int16 :reader ascent :allocation :x-server) (decent :type int16 :reader decent :allocation :x-server)) (:metaclass x-class)) ;;; COLORMAP (defclass colormap (external-object) ((visual :type card29 :initarg :visual :reader visual :allocation :x-server) (window :type window :initarg :window :reader window :allocation :x-server) (alloc-p :type boolean :initarg :alloc-p :reader alloc-p :allocation :x-server)) (:metaclass x-class)) ;;; COLOR (defclass color (external-object) ((red :type rgb-val :initform 0.0 :initarg :red :accessor red :allocation :x-server) (green :type rgb-val :initform 0.0 :initarg :green :accessor green :allocation :x-server) (blue :type rgb-val :initform 0.0 :initarg :blue :accessor blue :allocation :x-server)) (:metaclass x-class)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; #| HANDLING X EVENTS Events are handled by this system in one of two ways, by the EVENT-CASE macro and by the PROCESS-EVENT function. EVENT-CASE gives the user localized control over how X events are handled within the lexical scope of a program. Since I am proposing little or no change to the existing CLX EVENT-CASE macro, I will leave it out of this discussion. PROCESS-EVENT invokes the default event handlers for a given class of window. This is different from the current CLX in that handlers are associated with window classes instead of just display objects. For each X event type there is a corresponding handler method. This method is invoked by dispatching off of the type of the event-window and the type of the event. These methods would not be called by the user explicitly, but would be called from within the PROCESS-EVENT function. There are three alternatives to how to organize this multimethod dispatch: 1. By defining one event handler method for each type of event. Each of these methods would do a single dispatch off of the type of window. (This was the approach taken by Xenon.) The dispatch which invokes the method corresponding to the event type is handled by magic inside PROCESS-EVENT. Here are some examples: (defmethod handle-key-press-event ((w window) child same-screen-p x y root-x root-y state time code) ...) (defmethod handle-unmap-notify-event ((w window) configure-p) ...) One advantage of this approach is that the user can write event handler methods which dispatch off of other arguments as well. Here is an example of how to use this type of handler: (defclass active-border-window (window) ((event-mask :initform '(:enter-notify :leave-notify)) (active-color :type color :accessor active-color) (inactive-color :type color :accessor inactive-color))) (defmethod handle-enter-notify-event ((w active-border-window) ...) (with-slots (active-color) w (setf (border-color w) active-color))) (defmethod handle-leave-notify-event ((w active-border-window) ...) (with-slots (inactive-color) w (setf (border-color w) inactive-color))) These methods, in some sense, become part of the class definition. 2. By using a single CLOS multimethod which does two dispatches: one off of the type of window, and an EQL dispatch off of the event keyword. The advantage of this approach is that the keywords correspond to the keywords in the EVENT-CASE macro. Here are some examples of these methods: (defmethod handle-event ((w window) (event-keyword (eql :key-press)) &rest args) ...) (defmethod handle-event ((w window) (event-keyword (eql :key-release)) &rest args) ...) The disadvantage of this is the &REST argument. This is necessary because not all event handlers are called with the same arguments. It would be up to the user to decipher the position of an argument in the ARGS list. An alternative to this might be to use keyword arguments with &ALLOW-OTHER-KEYS. 3. The final approach would be to define actual event classes and dispatch off the window instance and the event instance. (I believe XCL took this approach.) Here's an example: (defclass enter-notify-event (x-event) ((window :type window :accessor window) (child :type (or null window) :accessor child) ...)) (defmethod handle-event ((w window) (e enter-notify-event)) ...) The advantage of this approach is that it makes the implicit hierarchy of X event types explicit. Making this hierarchy explicit allows us to do some interesting method lookup defaulting. One could imagine exploiting multiple inheritance to provide increased flexibility: (defclass key-press-event (key-event press-event) ...) These new abstract event classes could be used by very general methods: (defmethod handle-event ((w foo-window) (e press-event)) (format t "Something was pressed.~%")) One question with this approach is how to map out this event hierarchy in lisp. The X11 server doesn't really make any use of the hierarchy, and the user may be fooled into thinking that subclassing an existing event class would magically begin being utilized by CLX. Another disadvantage to this is that generating CLOS objects for each X event can be very expensive. Although using resource caches is possible this still seems to be more trouble than its worth. I recommend alternative 1. |# Respectfully submitted, Warren Harris From Owners-commonloops.pa@Xerox.COM Fri Oct 28 09:31:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21339; Fri, 28 Oct 88 09:31:58 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 OCT 88 09:25:02 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 28 OCT 88 09:21:16 PDT Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA21527; Fri, 28 Oct 88 09:17:14 PDT Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA16756; Fri, 28 Oct 88 09:20:06 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA13108; Fri, 28 Oct 88 09:20:18 PDT Message-Id: <8810281620.AA13108@suntana.sun.com> To: Warren Harris Cc: cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, hmuller%suntana@Sun.COM Subject: Re: OBJECT-ORIENTED CLX In-Reply-To: Your message of Thu, 27 Oct 88 17:34:01 -0700. <3463.594002041@hplwhh> Date: Fri, 28 Oct 88 09:20:15 PDT From: kempf@Sun.COM General Comments ---------------- CLX may be the wrong place to CLOSify. Pushing CLOS into the Common Lisp kernel is a better long term solution in my opinion, if making the low level interface to windows should be object oriented. This would have the additional effect of allowing extensibility in other things, like pathnames. For example, it would be nice to be able to extend pathnames so that edit buffers could be used. That way, streams could be opened on edit buffers without special machinery. Windows could benefit as well. A better short term solution is a host window system independent object-oriented layer which targets to X via CLX as one option. Since there are other window systems out there besides X (e.g. Coral Common Lisp runs on the Mac and targets to the Mac window system), and, indeed, others may come along in the future, it would rather seem more approprate to provide a "window virtual machine" which abstracts away from the underlying host window system as much as possible. This would isolate Lisp applications from the host window system, and would fit more in with the general nature and philosophy of Lisp as an abstraction away from the machine. The "window machine", in this case, is X. Specifics --------- >In >particular, a new meta-class is defined, X-CLASS, which makes convenient >the specification of objects allocated external to the Lisp process (in the >X server). This new metaclass is a good idea, but why restrict it just to X? Why not have a DISTRIBUTED-OBJECT metaclass? >In this meta-class, a new slot-descriptor is defined, >X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation, >namely :X-SERVER. Specifying :X-SERVER allocation does not reserve space >in the actual CLOS object for the value, but instead defines reader and >writer methods which actually perform the X protocol requests. (There may I don't understand why this is needed. This could be done with an X-SERVER-MIXIN which is mixed with all the Lisp classes representing X objects, then defining the appropriate qualified methods on the slot accessor functions to perform the protocol requests. Is performance a concern? If so, then won't the round trip server time dwarf the amount of time needed to do the qualified method invocation? My understanding of X is that the types of resources in the server are not extensible. If so, then the qualified methods for slot access can be defined and delivered as a nonextensible interface. So the flexibility of a metaclass isn't needed. >One difficulty with the old CLX model is that some objects are created in >the server process simultaneous with their creation in the Lisp process. >This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs. Other objects are >created in the server process some time after their creation in the Lisp >process. This includes DISPLAYs, and FONTs. This object-oriented >version of CLX takes the uniform approach of delaying the creation of all >server allocated objects until the OPEN-OBJECT generic function is called. This will solve the problem of object creation, but it doesn't solve the problem of co-ordinating asynchronous state changes in the client and server. This is a general problem with programming using distributed objects. >(Note: the way >this works is that while a window is open, all :X-SERVER allocated instance >variable accesses go through the X server. When the window is closed, the >values of these slots as they currently exist in the server are re-cached >in the lisp objects before the server object is actually destroyed. That >way, the next time the window is opened the state is remembered.) OK, now I understand how you propose to solve the cache consistency problem between client and server-by simply not caching any state in the client! Hmmm. What about performance? Having to go round trip to the server just to figure out the height of a character in a multifont display could slow display of a complex multifont view to a crawl. > 2. It allows the objects' states to be remembered between Lisp > sessions. > >This second point is a significant advantage since Lisp images can >typically be stored on disk via some SAVE-WORLD command. Lisp images with >saved CLX objects can then be recreated numerous times. This is certainly an advantage, but an easier solution is to modify the underlying CLX functions to do this. To me, the fact that they don't do this already is a bug in CLX. This is not an inherent advantage of your design. >1. By defining one event handler method for each type of event. Each of >these methods would do a single dispatch off of the type of window. (This >was the approach taken by Xenon.) The dispatch which invokes the method >corresponding to the event type is handled by magic inside PROCESS-EVENT. > ... >I recommend alternative 1. This is way too inflexible. Event dispatch is not extensible, except by subclassing windows. >3. The final approach would be to define actual event classes and dispatch >off the window instance and the event instance. (I believe XCL took this >approach.) This sounds like the right approach. Now, both window classes and event classes are extensible. >One question with this approach is how to map out this event hierarchy in >lisp. The X11 server doesn't really make any use of the hierarchy, and the >user may be fooled into thinking that subclassing an existing event class >would magically begin being utilized by CLX. If the event dispatcher is not chained to the X server, it may be possible to define events inside Lisp which have nothing to do with the X server. For example, one event might be VIEW-CHANGED, which would be used by a Model/View/Controller type application framework to allow a model (which may even be in a separate Unix process) to notify its views that they should update themselves. By isolating event dispatch in one place, multiprocessing code is reduced (for those Lisps which have multiprocessing), thus reducing the need for concern about race conditions and deadlocks. >Another disadvantage to this is that generating CLOS objects for each X >event can be very expensive. Although using resource caches is possible >this still seems to be more trouble than its worth. One or a few event objects per event type is not unreasonable. Thanks for you ideas. jak From Owners-commonloops.pa@Xerox.COM Sun Oct 30 22:58:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20105; Sun, 30 Oct 88 22:58:15 PST Received: from Salvador.ms by ArpaGateway.ms ; 30 OCT 88 22:56:16 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 30 OCT 88 22:54:15 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA03449; Mon, 31 Oct 88 01:53:08 EST Received: by mcvax.cwi.nl via EUnet; Sun, 30 Oct 88 07:07:34 +0100 (MET) Received: from dx7. by ecn-nlerf.com (4.0/SMI-4.0) id AA10894; Fri, 28 Oct 88 08:51:49 GMT Date: Fri, 28 Oct 88 08:51:49 GMT From: wim@ecn-nlerf.com (Wim Rijnsburger) Message-Id: <8810280851.AA10894@ecn-nlerf.com> To: commonloops.pa@Xerox.COM Subject: Please add me to this mailing list Cc: johnB@ecn-nlerf.com Could you please the folowing alias name on the CLOS distribution list: ...!mcvax!ecn!lisp-list Thanks! Wim. --------------------------------------------------------------------- Wim Rijnsburger e-mail: mcvax!ecn!wim Netherlands Energy Research Foundation, ECN P.O. Box 1, 1755 ZG Petten(NH), Holland phone : +31 2246 4336 From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Oct 31 18:46:30 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02884; Mon, 31 Oct 88 18:46:30 PST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88 18:43:19 PST Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 11:51:25 PST Date: 31 Oct 88 11:51 PST From: masinter.pa@Xerox.COM Subject: Re: Issue: EVAL-OTHER (Version 2) In-Reply-To: Brad Miller 's message of Mon, 24 Oct 88 21:06 EDT To: miller@CS.ROCHESTER.EDU Cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <881031-115125-6109@Xerox> The proposal EVAL-OTHER:SELF-EVALUATE in Issue: EVAL-OTHER (Version 2) was voted on at the October 1988 X3J13 meeting and accepted. This does not preclude a subsequent proposal to make the "self-evaluation" of objects be a standard generic function where only the default method is the identity function, but might change the wording in which you would couch such a proposal. If you were to use the "cleanup" committee's proposal format, you should use a different issue name, e.g., EVAL-GENERIC. If you (or anyone) wants to see the guidelines for cleanup proposals, let me know. From Owners-commonloops.pa@Xerox.COM Sun Nov 6 02:39:24 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10548; Sun, 6 Nov 88 02:39:24 PST Received: from Burger.ms by ArpaGateway.ms ; 04 NOV 88 13:26:09 PST Return-Path: Redistributed: commonloops.pa Received: from ads.com ([128.229.30.16]) by Xerox.COM ; 04 NOV 88 13:19:45 PST Received: by ads.com (5.59/1.17) id AA11351; Thu, 3 Nov 88 22:44:34 PST Date: Thu, 3 Nov 88 22:44:34 PST From: John W. Dye Jr. Message-Id: <8811040644.AA11351@ads.com> To: commonloops.pa@Xerox.COM Subject: AAAI-pcl code walker Cc: jdye@ads.com In converting between St. Paddys PCL and AAAI (bout time huh?), I found a difference in the code walker that I could use help getting around. Basically it is very simple, the code walker breaks on forms like '((foo)). It calls get-walker-template with '(foo) and signals an error because there is no template for it. For example: VIEW> (walker:walk-form '((frob))) >>Error: Can't get template for (FROB) WALKER::GET-WALKER-TEMPLATE: Required arg 0 (X): (FROB) :A 0: Abort to Lisp Top Level -> :b WALKER::GET-WALKER-TEMPLATE <- WALKER::WALK-FORM-INTERNAL <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> In general, I would like to define a walker template for all '(( XXX )) forms that simply tells the walker to walk each subform. Any suggestions? JD jdye@ads.com From Owners-commonloops.pa@Xerox.COM Sun Nov 6 23:12:35 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18612; Sun, 6 Nov 88 23:12:35 PST Received: from Riesling.ms by ArpaGateway.ms ; 06 NOV 88 23:04:07 PST Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 06 NOV 88 23:01:56 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA14683; Mon, 7 Nov 88 01:57:42 EST Date: Mon, 7 Nov 88 01:59:40 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA20231; Mon, 7 Nov 88 01:59:40 EST Message-Id: <8811070659.AA20231@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: some PCL patches Cc: Gregor.pa@Xerox.COM, burdorf@rand.org I have made a number of changes to PCL (8/28/88) after examining the performance of Chris Burdorf's carwash program in KCL. The carwash program (with 20 cars) makes about 10000 method calls, and about 90% of those calls are to slot accessor methods. The first thing I noticed was that GET/SET-SLOT-VALUE-CACHE-MISS was called a significant fraction of all slot accesses, so I found an alternative to the use of %LOGAND with the cache-mask with better behavior, which eliminated cache collisions for the carwash program. This only improved things slightly. The next thing I tried was to eliminate the use of MAKE-INDIVIDUAL-METHOD-DCODE. This made the carwash program run 7 times faster! I think that in KCL (and possibly in some other implementations), it is never worthwile to use MAKE-INDIVIDUAL-METHOD-DCODE. Also, in some implementations, MAKE-INDIVIDUAL-METHOD-DCODE might be faster than MAKE-MULTI-METHOD-DCODE, but slower than MAKE-ALL-STD-CLASS-READERS-DCODE (which doesn't actually have to call any method). The carwash program (with 20 cars) now runs in about .4 seconds in KCL on a SUN4, when compiled with safety 0 (this is the minimum time of several trials); without the changes marked with #+xkcl the program runs in .9 seconds; and before making any of these changes to PCL it ran in about 7.8 seconds. With 50 cars, the minimum run time of 20 trials was .93 seconds, and the average run time was 1.3 seconds (the difference here is due to gc, which ran 8 times in the 20 trials). The version of KCL that I use includes the akcl-1-79 patches by Bill Schelter, and some patches I have made myself; the changes in this message will work in any version of KCL, or, for that matter, any CL implementation supported by PCL. Rick Harris (in-package "PCL") ;; in low.lisp (defmacro %ash (integer count) `(locally (declare (optimize (speed 3) (safety 0))) (the fixnum (ash (the fixnum ,integer) ,count)))) (defmacro %mod (x y) `(locally (declare (optimize (speed 3) (safety 0))) (the fixnum (mod (the fixnum ,x) (the fixnum ,y))))) (defun primep (x) (dotimes (i (1- (isqrt x)) t) (when (zerop (mod x (+ i 2))) (return nil)))) (defun largest-prime (x) (loop (when (primep x) (return x)) (decf x))) ;; Try to make every bit of the fixnum argument affect the result. ;; This should probably replace %logand everywhere in PCL: ;; object-cache-no, cache-key-from-wrappers*, lookup-pv-*. (defmacro fixnum-cache-no (mask fixnum) (unless (constantp mask) (error "FIXNUM-CACHE-NO requires its first argument (mask) to be a constant")) (let* ((mask-value (eval mask)) (lsize (integer-length mask-value)) (size (ash 1 lsize)) (words-per-entry (1+ (logxor mask-value (1- size)))) (lwords-per-entry (integer-length (1- words-per-entry))) (entries (/ size words-per-entry))) `(%ash (%mod ,fixnum ,(largest-prime entries)) ,lwords-per-entry))) ;; in kcl-low.lisp #+kcl (progn ;; The reason these are here is because the KCL compiler does ;; not allow LET to return FIXNUM values as values of (c) type int, hence ;; the use of LOCALLY (which expands into (LET () (DECLARE ...) ...)) ;; forces conversion of ints to objects. (defmacro %logand (&rest args) (reduce-variadic-to-binary 'logand args 0 t 'fixnum)) (defmacro %logxor (&rest args) (reduce-variadic-to-binary 'logxor args 0 t 'fixnum)) (defmacro %+ (&rest args) (reduce-variadic-to-binary '+ args 0 t 'fixnum)) (defmacro %1+ (x) `(the fixnum (1+ (the fixnum ,x)))) (defmacro %svref (vector index) `(svref (the simple-vector ,vector) (the fixnum ,index))) (defsetf %svref (vector index) (new-value) `(setf (svref (the simple-vector ,vector) (the fixnum ,index)) ,new-value)) (defmacro %ash (integer count) `(the fixnum (ash (the fixnum ,integer) ,count))) (defmacro %mod (x y) ; this differs from mod when y is negative `(let ((%x ,x) (%y ,y)) (declare (fixnum %x %y)) (if (< %x 0) (let ((%r (rem %x %y))) (declare (fixnum %r)) (if (zerop %r) %r (the fixnum (- %y %r)))) (the fixnum (rem %x %y))))) (setf (get 'cclosure-env 'compiler::inline-always) (list '((t) t nil nil "(#0)->cc.cc_env"))) #+xkcl ; kcl can't use turbo-closures because of a gc bug in mark_object; xkcl fixes the bug (progn (CLines "object tc_cc_env_nthcdr (n,tc)" "object n,tc; " "{return (type_of(tc)==t_cclosure&& " " tc->cc.cc_turbo!=NULL&& " " type_of(n)==t_fixnum)? " " tc->cc.cc_turbo[fix(n)]: " ; assume that n is in bounds " Cnil; " "} " ) (defentry tc-cclosure-env-nthcdr (object object) (object tc_cc_env_nthcdr)) (setf (get 'tc-cclosure-env-nthcdr 'compiler::inline-unsafe) '(((fixnum t) t nil nil "(#1)->cc.cc_turbo[#0]"))) ) ) ;; in fin.lisp #+kcl (progn (defun allocate-funcallable-instance-1 () (let ((fin (allocate-funcallable-instance-2)) (env (make-list funcallable-instance-closure-size :initial-element nil))) (set-cclosure-env fin env) #+xkcl (si:turbo-closure fin) (dotimes (i (1- funcallable-instance-closure-size)) (pop env)) (setf (car env) *funcallable-instance-marker*) fin)) ;; this replaces funcallable-instance-data-1, set-funcallable-instance-data-1, and the defsetf (defmacro funcallable-instance-data-1 (fin data &environment env) ;; The stupid compiler won't expand macros before deciding on optimizations, ;; so we must do it here. (let* ((pos-form (macroexpand `(funcallable-instance-data-position ,data) env)) (index-form (if (constantp pos-form) (- funcallable-instance-closure-size (eval pos-form) 2) `(- funcallable-instance-closure-size (funcallable-instance-data-position ,data) 2)))) #+xkcl `(car (tc-cclosure-env-nthcdr ,index-form ,fin)) #-xkcl `(nth ,index-form (cclosure-env ,fin)))) ) ;; in slots.lisp (defmacro slot-value-cache-offset (instance wrapper sxhash) `(fixnum-cache-no slot-value-cache-mask (%logxor (validate-wrapper ,instance ,wrapper) ,sxhash))) (defmacro get-slot-value-1 (instance wrapper static-slots sxhash slot-name) `(let ((offset (slot-value-cache-offset ,instance ,wrapper ,sxhash)) (cache *slot-value-cache*) (pos 0)) (declare (fixnum offset pos)) (without-interrupts (if (and (eq (%svref cache offset) ,wrapper) (eq (%svref cache (%+ offset 1)) ,slot-name)) (progn (setq pos (%svref cache (%+ offset 2))) (with-interrupts (get-slot-value-2 ,instance ,wrapper ,slot-name ,static-slots pos))) (with-interrupts (get-slot-value-cache-miss ,instance ,wrapper ,static-slots ,slot-name offset)))))) (defmacro set-slot-value-1 (nv instance wrapper static-slots sxhash slot-name) `(let ((offset (slot-value-cache-offset ,instance ,wrapper ,sxhash)) (cache *slot-value-cache*) (pos 0)) (declare (fixnum offset pos)) (without-interrupts (if (and (eq (%svref cache offset) ,wrapper) (eq (%svref cache (%+ offset 1)) ,slot-name)) (progn (setq pos (%svref cache (%+ offset 2))) (with-interrupts (set-slot-value-2 ,nv ,instance ,wrapper ,slot-name ,static-slots pos))) (with-interrupts (set-slot-value-cache-miss ,nv ,instance ,wrapper ,static-slots ,slot-name offset)))))) (defun compute-discriminator-code-1 (generic-function) (let ((combined (generic-function-combined-methods generic-function)) (methods (generic-function-methods generic-function)) (std-class (find-class 'standard-class)) (t-class *the-class-t*) (r/w nil)) (cond ((null methods) (make-no-methods-dcode generic-function)) ((and (null (cdr combined)) (every #'(lambda (x) (eq x t-class)) (caar combined))) (make-default-method-only-dcode generic-function)) #|| ((dolist (e combined) (when (dolist (specl (car e)) (when (listp specl) (return 't)))) (return 't)) (make-individual-method-dcode generic-function)) ||# ((not (dolist (m methods) (let* ((specls (method-type-specifiers m)) (spec0 (car specls)) (spec1 (cadr specls))) (cond ((and (memq r/w '(nil r)) (standard-reader-method-p m) (not (listp spec0)) (if (symbolp spec0) (and (neq spec0 'standard-generic-function) (neq spec0 'generic-function)) (eq (class-of spec0) std-class))) (setq r/w 'r)) ((and (memq r/w '(nil w)) (standard-writer-method-p m) (not (listp spec1)) (if (symbolp spec1) (and (neq spec1 'standard-generic-function) (neq spec1 'generic-function)) (eq (class-of spec1) std-class))) (setq r/w 'w)) (t (return t)))))) (if (eq r/w 'r) (make-all-std-class-readers-dcode generic-function) (make-all-std-class-writers-dcode generic-function))) (t (make-multi-method-dcode generic-function))))) ;; End of patches to PCL To fix (any version of) KCL so that it can use the changes marked with #+xkcl: edit the function mark_object in the file kcl/c/gbc.c, changing the lines: case t_cclosure: mark_object(x->cc.cc_name); mark_object(x->cc.cc_env); mark_object(x->cc.cc_data); if (x->cc.cc_start == NULL) break; if (what_to_collect == t_contiguous) { if (get_mark_bit((int *)(x->cc.cc_start))) break; mark_contblock(x->cc.cc_start, x->cc.cc_size); if (x->cc.cc_turbo != NULL) { for (i = 0, y = x->cc.cc_env; type_of(y) == t_cons; i++, y = y->c.c_cdr); mark_contblock((char *)(x->cc.cc_turbo), i*sizeof(object)); } } break; to case t_cclosure: mark_object(x->cc.cc_name); mark_object(x->cc.cc_env); mark_object(x->cc.cc_data); if (what_to_collect == t_contiguous) if (x->cc.cc_turbo != NULL) { for (i = 0, y = x->cc.cc_env; type_of(y) == t_cons; i++, y = y->c.c_cdr); mark_contblock((char *)(x->cc.cc_turbo), i*sizeof(object)); } if (x->cc.cc_start == NULL) break; if (what_to_collect == t_contiguous) { if (get_mark_bit((int *)(x->cc.cc_start))) break; mark_contblock(x->cc.cc_start, x->cc.cc_size); } break; From Gregor.pa@Xerox.COM Mon Nov 7 08:37:54 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21382; Mon, 7 Nov 88 08:37:54 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 NOV 88 08:32:34 PST Date: Mon, 7 Nov 88 08:28 PST From: Gregor.pa@Xerox.COM Subject: Re: FTPing PCL To: David H. West Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811071434.AA04750@itivax.iti> Message-Id: <19881107162854.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 7 Nov 88 09:34:17 EST From: dhw%iti@umix.cc.umich.edu (David H. West) It appears that arisia no longer accepts anonymous FTP login. Is there still a way to get PCL by FTP? In the aftermath of the virus, anonymous FTP is currently disabled on arisia. It will be re-enabled shortly. We will send a message to the CommonLoops list at that time. ------- From Owners-commonloops.PA@Xerox.COM Mon Nov 7 12:29:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24184; Mon, 7 Nov 88 12:29:42 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 NOV 88 12:24:36 PST Return-Path: Redistributed: commonloops.PA Received: from cacfs.army.mil ([192.33.5.1]) by Xerox.COM ; 07 NOV 88 12:22:38 PST Date: Sun, 6 Nov 88 17:55:27 CST From: CPT Pat Vye Message-Id: <8811062355.AA02964@cac-3> To: commonloops.PA@Xerox.COM Subject: Request for public domain CLOS Cc: pvye@cacfs.army.mil Hello. . . I am trying to get a public domain version of Common Lisp Object Oriented System and any documentation. I was told that ARISIA might have a version but I have been unable to get through to FTP a copy. Is there any way you could help? Thank you very much in advance. Pat Vyec From Owners-commonloops.pa@Xerox.COM Mon Nov 7 21:20:56 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03607; Mon, 7 Nov 88 21:20:56 PST Received: from Burger.ms by ArpaGateway.ms ; 07 NOV 88 19:46:14 PST Return-Path: Redistributed: commonloops.pa Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 07 NOV 88 19:44:49 PST Received: from blackcomb.rand.org by rand.org; Mon, 7 Nov 88 19:19:06 PST Received: from localhost by blackcomb.arpa; Mon, 7 Nov 88 19:19:57 PST Message-Id: <8811080319.AA07297@blackcomb.arpa> To: commonloops.pa@Xerox.COM Subject: Status of the PCL's metaclass implementation Date: Mon, 07 Nov 88 19:19:53 PST From: shane%blackcomb@rand.org 1] Could someone give me a clear distinction between a superclass and a metaclass. When would one want to use a metaclass; and what baggage is required by metaclasses. ;;; -------------------- ;;; I defined a metaclass as follows: ;;; -------------------- (defclass my-standard-class1 () ((my-slot :accessor my-slot)) (:metaclass standard-class)) NIL (setq mcs1 (find-class 'my-standard-class1)) # (describe mcs1) The class # is an instance of class #. Name: MY-STANDARD-CLASS1 Class-Precedence-List: (MY-STANDARD-CLASS1 OBJECT T) Local-Supers: (OBJECT) Direct-Subclasses: NIL # ;;; -------------------- ;;; Then I tried to define another class such that my-slot is one of ;;; the class' slots: ;;; -------------------- (defclass my-class1 () () (:metaclass my-standard-class1)) Error: No matching method for the generic-function #, when called with arguments (# MY-CLASS1 NIL NIL NIL). [1] :zoom Evaluation stack: ->(ERROR "No matching method for the generic-function ~S,~@ when called with arguments ~S." # ...) (|(METHOD NO-APPLICABLE-METHOD (T))| # # ...) (NOTICE-METHODS-CHANGE-2 # (# # MY-CLASS1 ...)) (#:|.NOTICE-METHODS-CHANGE.a714c663| # # ...) (CACHING-DCODE-MISS # #(NIL NIL #(2 (NAME CLASS-PRECEDENCE-LIST LOCAL-SUPERS ...) NIL ...) ...) ...) (#:|..$RANDOM-FORMS$.a714c68a.a714c68b| # MY-CLASS1 ...) (DEFCLASS (DEFCLASS MY-CLASS1) (COMPILE LOAD EVAL)) ... more older frames ... [1] :pop ;;; -------------------- ;;; Then I defined another class: ;;; -------------------- (defclass my-standard-class2 (standard-class) ((my-slot :accessor my-slot))) NIL (setq msc2 (find-class 'my-standard-class2)) # (describe msc2) The class # is an instance of class #. Name: MY-STANDARD-CLASS2 Class-Precedence-List: (MY-STANDARD-CLASS2 STANDARD-CLASS CLASS OBJECT T) Local-Supers: (STANDARD-CLASS) Direct-Subclasses: NIL # # ;;; -------------------- ;;; And again I tried to define another class such that my-slot is one of ;;; the class' slots: ;;; -------------------- (defclass my-class2 () () (:metaclass my-standard-class2)) Error: The class # was specified as a super-class of the class #; but the meta-classes # and # are incompatible. [1] :zoom Evaluation stack: ->(ERROR "The class ~S was specified as a~%super-class of the class ~S;~%~ but the meta-classes ~S and~%~S are incompatible." # ...) (|(METHOD CHECK-SUPER-METACLASS-COMPATIBILITY (T T))| # #) (CACHING-DCODE-MISS # #(NIL NIL NIL ...) ...) (#:|..$RANDOM-FORMS$.a714c67e.a714c67f| # #) (NOTICE-METHODS-CHANGE-2 # (# #)) (#:|.NOTICE-METHODS-CHANGE.a714c663| # #) (|(METHOD UPDATE-CLASS (STANDARD-CLASS))| # :DIRECT-SUPERCLASSES ...) ... more older frames ... ;;; -------------------- Obviously, neither one of these attempts worked. Essentially what I want is to be able to access the my-slot slot by: (setf (my-slot mc1) 'hello) => HELLO (my-slot mc1) => HELLO 2] When describing an instance, containing an unbound slot, is an error the proper response? For instance, (defclass c1 () ((a))) (describe (make-instance 'c1)) => # is an instance of class #: The following slots have :INSTANCE allocation:Error: The slot A is unbound in the object #. Thank you, Darrell Shane P.S> I am running 8/28/88 (beta rev 1) AAAI PCL under Franz Allegro CL 3.0.1 [sun3]. From Owners-commonloops.pa@Xerox.COM Tue Nov 8 07:27:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08381; Tue, 8 Nov 88 07:27:02 PST Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 88 07:18:46 PST Return-Path: Redistributed: commonloops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 08 NOV 88 07:17:48 PST To: shane%blackcomb@RAND-UNIX.ARPA Cc: commonloops.pa@Xerox.COM Subject: Re: Status of the PCL's metaclass implementation In-Reply-To: Your message of Mon, 07 Nov 88 19:19:53 -0800. <8811080319.AA07297@blackcomb.arpa> Date: Tue, 08 Nov 88 10:18:57 -0500 From: kanderso@PEBBLES.BBN.COM Message-Id: <881108-071846-1879@Xerox> To: commonloops.pa@xerox.com Subject: Status of the PCL's metaclass implementation Date: Mon, 07 Nov 88 19:19:53 PST From: shane%blackcomb@rand.org 1] Could someone give me a clear distinction between a superclass and a metaclass. When would one want to use a metaclass; and what baggage is required by metaclasses. ;;; -------------------- ;;; I defined a metaclass as follows: ;;; -------------------- (defclass my-standard-class1 () ((my-slot :accessor my-slot)) (:metaclass standard-class)) NIL (setq mcs1 (find-class 'my-standard-class1)) # (describe mcs1) The class # is an instance of class #. Name: MY-STANDARD-CLASS1 Class-Precedence-List: (MY-STANDARD-CLASS1 OBJECT T) Local-Supers: (OBJECT) Direct-Subclasses: NIL # ;;; -------------------- ;;; Then I tried to define another class such that my-slot is one of ;;; the class' slots: ;;; -------------------- (defclass my-class1 () () (:metaclass my-standard-class1)) Error: No matching method for the generic-function #, when called with arguments (# MY-CLASS1 NIL NIL NIL). The metaobject protocol is asking my-standard-class1 to handle expand-defclass which it doesn't handle. Your example below is built on standard-class which does handle it, so expand-defclass then works. ;;; -------------------- ;;; Then I defined another class: ;;; -------------------- (defclass my-standard-class2 (standard-class) ((my-slot :accessor my-slot))) This stands a chance of being a metaclass, but see below ... ;;; -------------------- ;;; And again I tried to define another class such that my-slot is one of ;;; the class' slots: ;;; -------------------- (defclass my-class2 () () (:metaclass my-standard-class2)) Error: The class # was specified as a super-class of the class #; but the meta-classes # and # are incompatible. [1] :zoom Evaluation stack: Your class my-class2 is built on OBJECT which is has metaclass standard-nclass. PCL checks to see if it is ok to mix classes from 2 different metaclasses using check-super-metaclass-compatibility your metaclass must provide a non nil response if this is OK. This should be better documented. Since you want this most of the time, i use the following metaclass mixin. (defclass compatible-class-mixin () ()) (defmethod check-super-metaclass-compatibility ((class compatible-class-mixin) (super standard-class)) t) ;;; -------------------- Obviously, neither one of these attempts worked. Essentially what I want is to be able to access the my-slot slot by: (setf (my-slot mc1) 'hello) => HELLO (my-slot mc1) => HELLO Your approach is correct. Try it again after adding the mixin. 2] When describing an instance, containing an unbound slot, is an error the proper response? For instance, (defclass c1 () ((a))) (describe (make-instance 'c1)) => # is an instance of class #: The following slots have :INSTANCE allocation:Error: The slot A is unbound in the object #. I believe patches for this have come over the list. Thank you, Darrell Shane P.S> I am running 8/28/88 (beta rev 1) AAAI PCL under Franz Allegro CL 3.0.1 [sun3]. From Owners-commonloops.pa@Xerox.COM Tue Nov 8 17:04:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11776; Tue, 8 Nov 88 17:04:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 NOV 88 16:17:06 PST Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 08 NOV 88 16:14:40 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA01456; Tue, 8 Nov 88 17:48:54 EST Date: Tue, 8 Nov 88 17:47:51 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA13714; Tue, 8 Nov 88 17:47:51 EST Message-Id: <8811082247.AA13714@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: some PCL patches There is an error in my previous posting: > The next thing I tried was to eliminate the use of MAKE-INDIVIDUAL-METHOD-DCODE. > This made the carwash program run 7 times faster! > I think that in KCL (and possibly in some other implementations), it is never worthwile > to use MAKE-INDIVIDUAL-METHOD-DCODE. Also, in some implementations, > MAKE-INDIVIDUAL-METHOD-DCODE might be faster than MAKE-MULTI-METHOD-DCODE, > but slower than MAKE-ALL-STD-CLASS-READERS-DCODE (which doesn't actually have > to call any method). > > (defun compute-discriminator-code-1 (generic-function) > ... > #|| > ((dolist (e combined) > (when (dolist (specl (car e)) > (when (listp specl) (return 't)))) > (return 't)) > (make-individual-method-dcode generic-function)) > ||# I have discovered that my problems with compute-discriminator-code-1 and make-individual-method-dcode were due to an error that I made when I applied the patch involving compute-discriminator-code-1 and make-default-method-only-dcode that Gregor sent to commonloops on Thu, 1 Sep 88 19:57 PDT. Please ignore the change to compute-discriminator-code-1 that I sent out. All of the other patches in my message are OK, and will be quite helpful if you have KCL. Rick From kiuchi.pa@Xerox.COM Tue Nov 8 19:27:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13906; Tue, 8 Nov 88 19:27:46 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 NOV 88 19:17:40 PST Date: 8 Nov 88 19:14 PST Sender: kiuchi.pa@Xerox.COM Subject: Arisia anonymous ftp From: CommonLoops-Request.pa@Xerox.COM Reply-To: CommonLoops-Request.pa@Xerox.COM To: CommonLoops.pa@Xerox.COM Cc: kiuchi.pa@Xerox.COM, berg%pwtc@labrea.stanford.edu Message-Id: <881108-191740-1416@Xerox> Due to the Arpanet virus/worm, arisia's anonymous ftp is had been disabled. Now, the service is back up. Please send mailing list requests or other administrative stuff to: CommonLoops-Request@Xerox.com Thank you. Yasuhiko Kiuchi (Kiuchi.pa@Xerox.com) From Owners-CommonLoops.pa@Xerox.COM Wed Nov 9 09:23:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19093; Wed, 9 Nov 88 09:23:31 PST Received: from Semillon.ms by ArpaGateway.ms ; 09 NOV 88 09:13:07 PST Return-Path: Redistributed: CommonLoops.pa Received: from duke.cs.duke.edu ([128.109.140.1]) by Xerox.COM ; 09 NOV 88 09:10:30 PST Received: from summanulla.mc.duke.edu by duke.cs.duke.edu (5.59/DUKE/08-19-88) id AA05988; Wed, 9 Nov 88 12:12:44 EST Received: by summanulla.mc.duke.edu (3.2/DUKE/3-1-88) id AA03696; Wed, 9 Nov 88 12:09:27 EST Date: Wed, 9 Nov 88 12:09:27 EST Message-Id: <8811091709.AA03696@summanulla.mc.duke.edu> To: CommonLoops.pa@Xerox.COM From: Status.of.CLOS.and.associated.software.for"production"work@summanulla.mc.duke.edu Sender: crm@summanulla.mc.duke.edu I am about to start coding a proof-of-principle system to go with my dissertation research in domain-specialized programming languages/ visual programming systems. I have been entertaining the idea that Common Lisp, CLOS, and X Windows would be an appropriate programming environment for this; I'm not that experienced a Lisp programmer, however, so I have some questions. I'd be happy to hear anyone's opinion on the questions. For all of these questions, please keep in mind that the only Common Lisp I have available is KCL (with the Austin modifications, although I could rebuild without if necessary.) (1) How stable is CLOS at this point? How likely am I to exercise significant bugs that are difficult to work around? (2) Is there a significant amount of CLOS code available, so I have some good examples from which to learn coding style inclusive-or dirty but useful tricks? (3) The only OOP interface to X windows of which I am aware is CLUE. How stable is CLUE? What has been others's experience coding applications using CLUE? Are there other interfaces I should consider? Should I consider building my own toolkit directly from CLX? (4) is there available an EMACS-like editor, in the public domain or freely usable, that is portable to Common LISP directly? I can always run a subsidiary GNU Emacs or emacsclient, but I'd rather have a slightly crippled LISP emacs I can put my own hooks into. (I plan to encapsulate it in an editor-object anyway, so compatibility with CLOS doesn't seem an issue. Am I wrong?) Thanks everyone, Charlie Martin (...!mcnc!duke!crm, crm@summanulla.mc.duke.edu) (if summanulla doesn't work, use crm@cs.duke.edu) From Owners-commonloops.pa@Xerox.COM Wed Nov 9 12:23:34 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20290; Wed, 9 Nov 88 12:23:34 PST Received: from Semillon.ms by ArpaGateway.ms ; 09 NOV 88 12:12:01 PST Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 09 NOV 88 12:09:52 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Wed, 9 Nov 88 11:46:13 pst Received: from loopback by hplwhh.HPL.HP.COM; Wed, 9 Nov 88 11:44:51 pst To: Gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM X-Mailer: mh6.5 Date: Wed, 09 Nov 88 11:44:48 PST Message-Id: <14577.595107888@hplwhh> From: Warren Harris Is there any reason AAAI PCL is calling MAKE-INSTANCE from within CLASS-PROTOTYPE instead of ALLOCATE-INSTANCE? This is causing me problems. I have a macro that expands into: (eval-when (eval load) (setf (class-slot-value (find-class ...) ') ...)) I've changed it in my local version, but I don't know if something else will break. Warren From Owners-commonloops.pa@Xerox.COM Thu Nov 10 19:35:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15400; Thu, 10 Nov 88 19:35:26 PST Received: from Salvador.ms by ArpaGateway.ms ; 10 NOV 88 16:22:50 PST Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 10 NOV 88 16:19:46 PST Received: by ti.com id AA23045; Thu, 10 Nov 88 18:20:18 CST Received: from dsg by tilde id AA22727; Thu, 10 Nov 88 18:06:29 CST Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 10 Nov 88 18:07:40 CST Message-Id: <2804198856-3550037@Sierra> Sender: KK@Sierra.csc.ti.com Date: Thu, 10 Nov 88 18:07:36 CST From: Kerry Kimbrough To: CommonLoops.PA@Xerox.COM Subject: setf generic functions A question about the CLOS spec: are there any restrictions on lambda lists allowed for setf generic functions? For example, is the following valid? (DEFMETHOD (SETF foo) (new-value (c a-class) :key x y) ...) (SETF (foo object) value :x 5) Neither the CLOS spec nor Keene address this question. In fact, both documents need a lot of improvement here; information about setf'ers is sketchy and unlocalized. From Owners-commonloops.pa@Xerox.COM Thu Nov 10 19:38:51 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15440; Thu, 10 Nov 88 19:38:51 PST Received: from Riesling.ms by ArpaGateway.ms ; 10 NOV 88 16:46:50 PST Return-Path: Redistributed: commonloops.pa Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 10 NOV 88 16:44:51 PST Received: from taos.rand.org by rand.org; Thu, 10 Nov 88 16:36:38 PST Received: from localhost by taos.arpa; Thu, 10 Nov 88 16:33:34 PST Message-Id: <8811110033.AA07398@taos.arpa> To: commonloops.pa@Xerox.COM, David_McArthur , steph%ixta@rand.org Subject: Richard Harris' speed up's for PCL under KCL Date: Thu, 10 Nov 88 16:33:32 PST From: burdorf%taos@rand.org I got the following results before and after Richard Harris' hacks to speed up PCL under KCL. Before 20 cars 28.650 After 1.883 Before 50 cars 90.617 After 7.540 These times were for a Sun 3/60. I found it interesting that compared to allegro, xkcl was faster with 20 cars, but slower with 50 cars. ERNIE is still faster, but the gap is now much smaller than it was at first. I think this is great, but please don't stop here concerning efficiency. THE FASTER THE BETTER. Chris From Owners-CommonLoops.PA@Xerox.COM Fri Nov 11 10:17:07 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21822; Fri, 11 Nov 88 10:17:07 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 11 NOV 88 09:44:39 PST Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 11 NOV 88 09:26:01 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Fri, 11 Nov 88 09:25:07 pst Received: from loopback by hplwhh.HPL.HP.COM; Fri, 11 Nov 88 09:23:25 pst To: Kerry Kimbrough Cc: CommonLoops.PA@Xerox.COM Subject: Re: setf generic functions In-Reply-To: Your message of "Thu, 10 Nov 88 18:07:36 CST." <2804198856-3550037@Sierra> Date: Fri, 11 Nov 88 09:23:22 PST Message-Id: <16722.595272202@hplwhh> From: Warren Harris Since you can say: (defsetf foo (c &key x y) (new-value) ...) in CL, I think the following would make more sense in CLOS: (DEFMETHOD (SETF foo) (new-value (c a-class) :key x y) ...) (SETF (foo object :x 5) value) ^^^^^ I believe this works in AAAI PCL. Warren From Owners-commonloops.pa@Xerox.COM Fri Nov 11 12:02:55 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22862; Fri, 11 Nov 88 12:02:55 PST Received: from Burger.ms by ArpaGateway.ms ; 11 NOV 88 11:09:52 PST Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 11 NOV 88 10:19:02 PST Received: by ti.com id AA29243; Fri, 11 Nov 88 12:19:32 CST Received: from dsg by tilde id AA12487; Fri, 11 Nov 88 12:01:49 CST Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 11 Nov 88 12:02:46 CST Message-Id: <2804263416-3799237@Sierra> Sender: KK@Sierra.csc.ti.com Date: Fri, 11 Nov 88 12:03:36 CST From: Kerry Kimbrough To: CommonLoops.PA@Xerox.COM Subject: Re: setf generic functions In-Reply-To: Msg of Fri, 11 Nov 88 09:23:22 PST from Warren Harris > Date: Fri, 11 Nov 88 09:23:22 PST > From: Warren Harris > Subject: Re: setf generic functions > To: Kerry Kimbrough > Cc: CommonLoops.PA@Xerox.COM > In-Reply-To: Your message of "Thu, 10 Nov 88 18:07:36 CST." > <2804198856-3550037@Sierra> > > Since you can say: > > (defsetf foo (c &key x y) (new-value) ...) > > in CL, I think the following would make more sense in CLOS: > > (DEFMETHOD (SETF foo) (new-value (c a-class) :key x y) > ...) > > (SETF (foo object :x 5) value) > ^^^^^ > > I believe this works in AAAI PCL. > > Warren You're right, this is the correct setf call. I've been informed that setf functions are being examined not just as a CLOS issue, but as an extension to CL itself. Still think the CLOS working group should publish better documentation for CLOS setf'ers, perhaps in some temporary form such as an appendix or papal bull. From Owners-commonloops.pa@Xerox.COM Fri Nov 11 12:06:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22926; Fri, 11 Nov 88 12:06:28 PST Received: from Riesling.ms by ArpaGateway.ms ; 11 NOV 88 11:57:14 PST Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 11 NOV 88 11:55:16 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA01885; Fri, 11 Nov 88 14:53:18 EST Date: Fri, 11 Nov 88 14:53:17 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA15538; Fri, 11 Nov 88 14:53:17 EST Message-Id: <8811111953.AA15538@turing.cs.rpi.edu> To: cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM Subject: PCL, CLX, and CLUE in KCL I have put the versions of AKCL, PCL, CLX, and CLUE that I use in the directory pub/lisp, on the host turing.cs.rpi.edu, for anonymous ftp retrieval. The AKCL is akcl-1-79 (KCL with enhancements by Bill Schelter), with additional enhancements that I made. The PCL is named "8/28/88 (beta rev 1) AAAI PCL ", but includes a couple of patches that Gregor Kiczales sent to the commonloops list, and a bunch of patches I made to improve PCL's performance in KCL. The CLX is a version that TI made available along with CLUE version 1.15. And CLUE is CLUE version 1.15. I have made patches to KCL and CLUE to make INTERACTIVE-STREAMS work in KCL. I have not tested these systems very much, and you will probably discover bugs: for instance, KCL's (lack of) support for SETF CHAR-BIT causes problems for CLX. I have created a mailing list for people who use this version of KCL, called kcl-x@turing.cs.rpi.edu (with kcl-x-request@turing.cs.rpi.edu) Rick Harris From Owners-commonloops.pa@Xerox.COM Fri Nov 11 18:01:32 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20290; Wed, 9 Nov 88 12:23:34 PST Received: from Semillon.ms by ArpaGateway.ms ; 09 NOV 88 12:12:01 PST Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 09 NOV 88 12:09:52 PST Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Wed, 9 Nov 88 11:46:13 pst Received: from loopback by hplwhh.HPL.HP.COM; Wed, 9 Nov 88 11:44:51 pst To: Gregor.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM X-Mailer: mh6.5 Date: Wed, 09 Nov 88 11:44:48 PST Message-Id: <14577.595107888@hplwhh> From: Warren Harris Is there any reason AAAI PCL is calling MAKE-INSTANCE from within CLASS-PROTOTYPE instead of ALLOCATE-INSTANCE? This is causing me problems. I have a macro that expands into: (eval-when (eval load) (setf (class-slot-value (find-class ...) ') ...)) I've changed it in my local version, but I don't know if something else will break. Warren From Owners-commonloops.pa@Xerox.COM Sun Nov 13 14:48:36 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14839; Sun, 13 Nov 88 14:48:36 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 NOV 88 14:09:41 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 13 NOV 88 14:07:29 PST To: commonloops.pa@Xerox.COM Subject: Symbolics carwash and MacIvory mods Date: Sun, 13 Nov 88 16:58:08 -0500 From: Mike Thome Message-Id: <881113-140941-1104@Xerox> First, some timings for the carwash program on symbolics systems: --# cars-- --3650 (no fpa)-- --MacIvory-- 10 0.4 sec 0.65 sec 100 9.8 sec 18.4 sec Notes: 1. Both machines are without Rick Harris' mods... I tried them and they actually slowed things down slightly on symbolics. 2. MacIvory paging is quite expensive - the 100 car case time includes ~ 1.5 secs memory management overhead! Included at the end are the only mods I needed to make to get clos working on the MacIvory. This is a very preliminary port, mostly assuming that the ivory is a 3600 (VERY wrong), so a careful conversion (i.e. a good ivory-low.lisp) should be better. -mike thome (mthome@bbn.com) ;;; 3600-low.lisp (defun set-function-name-1 (fn ignore new-name) ;changed to use list form (mt 881026) (cond ((or (funcallable-instance-p fn) (si:lexical-closure-p fn)) (let ((env (si:lexical-closure-environment fn))) (setf (gethash env dbg:*closure-names*) new-name))) ((compiled-function-p fn) (let* ((cca (si:compiled-function-cca fn)) (debug #-imach (si:%p-contents-offset cca 2) #+imach (sys:cca-extra-info cca))) (setf (car debug) new-name))) ((and (listp fn) (eq (car fn) 'si:digested-lambda)) (let ((debug (caddr fn))) (setf (caddr fn) (cons new-name (cdr debug)))))) fn) ;;; defsys.lisp (defvar *port* '(#+Genera Genera #+Genera-Release-6 Rel-6 #+Genera-Release-7-1 Rel-7-1 #+Genera-Release-7-2 Rel-7-2 #+Genera-Release-7-3 Rel-7-3 #+imach Ivory #+Lucid Lucid #+Xerox Xerox #+Xerox-Lyric Xerox-Lyric #+Xerox-Medley Xerox-Medley #+TI TI #+(and dec vax common) Vaxlisp #+KCL KCL #+excl excl #+:CMU CMU #+HP HP #+:gclisp gclisp #+pyramid pyramid #+:coral coral)) (defvar *pathname-extensions* (let ((files-renamed-p t) (proper-extensions (car '(#+(and Genera (not imach)) ("lisp" . "bin") #+(and Genera imach) ("lisp" . "ibin") #+(and dec common vax (not ultrix)) ("LSP" . "FAS") #+(and dec common vax ultrix) ("lsp" . "fas") #+KCL ("lsp" . "o") #+Xerox ("lisp" . "dfasl") #+(and Lucid MC68000) ("lisp" . "lbin") #+(and Lucid VAX) ("lisp" . "vbin") #+(and Lucid Prime) ("lisp" . "pbin") #+(and Lucid SUNRise) ("lisp" . "sbin") #+(and Lucid SPARC) ("lisp" . "sbin") #+(and Lucid IBM-RT-PC) ("lisp" . "bbin") #+(and excl allegro) ("lisp" . "fasl") #+(and excl (not allegro)) ("cl" . "fasl") #+:CMU ("slisp" . "sfasl") #+HP ("l" . "b") #+TI ("lisp" . #.(string (si::local-binary-file-type))) #+:gclisp ("LSP" . "F2S") #+pyramid ("clisp" . "o") #+:coral ("lisp" . "fasl") )))) (cond ((null proper-extensions) '("l" . "lbin")) ((null files-renamed-p) (cons "lisp" (cdr proper-extensions))) (t proper-extensions)))) ;;; also, the defsystem needs to load rel-7-2-patches when on an ivory (we use symbolics ;;; defsystem forms instead of the provided system). From Owners-CommonLoops.pa@Xerox.COM Sun Nov 13 20:20:03 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16609; Sun, 13 Nov 88 20:20:03 PST Received: from Burger.ms by ArpaGateway.ms ; 13 NOV 88 20:18:23 PST Return-Path: Redistributed: CommonLoops.pa Received: from caen.engin.umich.edu ([35.1.5.2]) by Xerox.COM ; 13 NOV 88 20:17:22 PST Received: by caen.engin.umich.edu (5.59.1/umix-2.0) id 3fa748ddd.000b179; Sun, 13 Nov 88 23:08:41 EST Date: Sun, 13 Nov 88 23:08:41 EST From: thoms@caen.engin.umich.edu (Dale E Thoms) Message-Id: <3fa748ddd.000b179@caen.engin.umich.edu> To: CommonLoops.pa@Xerox.COM Subject: Debugging in PCL Has anyone written any debugging tools specifically for use with PCL/CLOS? Any references to papers, and/or code would be appreciated. Even if you don't know of any tools for object-oriented debugging, how do you go about debugging methods and instances as opposed to ordinary functions? Thanks, Dale Thoms thoms@caen.engin.umich.edu AI Lab University of Michigan Ann Arbor, Michigan 48109-2110 From Owners-commonloops.pa@Xerox.COM Mon Nov 14 12:05:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23248; Mon, 14 Nov 88 12:05:31 PST Received: from Salvador.ms by ArpaGateway.ms ; 14 NOV 88 10:24:52 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 14 NOV 88 09:47:53 PST Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA19004; Mon, 14 Nov 88 08:01:11 PST Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA08767; Mon, 14 Nov 88 08:03:58 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA24213; Mon, 14 Nov 88 08:04:21 PST Message-Id: <8811141604.AA24213@suntana.sun.com> To: thoms@caen.engin.umich.edu (Dale E Thoms) Cc: CommonLoops.pa@Xerox.COM Subject: Re: Debugging in PCL In-Reply-To: Your message of Sun, 13 Nov 88 23:08:41 -0500. <3fa748ddd.000b179@caen.engin.umich.edu> Date: Mon, 14 Nov 88 08:04:19 PST From: kempf@Sun.COM I have written some code to enhance the Sun Symbolic Programming Environment (SPE) 1.0 to support debugging CLOS. This includes source finding (Meta-.) browsing of CLOS instances, class browser, integration with the window debugger, etc. The name of the environment is Clos du Soleil, and it is available free to people using SPE. The code is specific to SPE, since it depends heavily on the application framework used to build SPE, which was not written in CLOS, and so it is not portable to other Lisps. Currently, SPE 1.0 is available running on Lucid Common Lisp 2.1.3, and I intend to port it to 3.0 eventually. If you are interested, send me e-mail and I'll put you in touch with someone who can help you. jak From Owners-CommonLoops.PA@Xerox.COM Mon Nov 14 14:59:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29003; Mon, 14 Nov 88 14:59:42 PST Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 12:27:26 PST Return-Path: <@arisia.Xerox.COM,@lll-winken.UUCP,@lll-crg,@lll-tis:bedleson@daitc> Redistributed: CommonLoops.PA Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 14 NOV 88 12:24:20 PST Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.59++/IDA-1.2.6) id AA22736; Mon, 14 Nov 88 11:56:39 PST Received: by lll-winken.llnl.gov (smail2.5) id AA13816; 14 Nov 88 12:02:39 EST (Mon) Received: by lll-crg.llnl.gov (5.51/1.14) id AA07367; Mon, 14 Nov 88 08:47:35 PST Return-Path: Received: by tis.llnl.gov (4.0/1.14-TIS) id AA07810; Mon, 14 Nov 88 08:05:12 PST Received: by daitc.daitc.mil (5.52++/24-Aug-88) id AA05926; Mon, 14 Nov 88 09:58:47 EST Message-Id: <8811141458.AA05926@daitc.daitc.mil> Date: Mon, 14 Nov 88 09:58:46 From: bedleson%daitc%lll-tis@lll-crg.UUCP (Brenda Edleson) Subject: Re: setf generic functions To: CommonLoops.PA@Xerox.COM X-Orig-Date: Thu, 10 Nov 88 18:07:36 CST X-Orig-From: KK@Sierra.csc.ti.com X-Orig-Message-Id: <2804198856-3550037@Sierra> Status: N Please add my name to the mailing list of CLOS and remove Brenda Edleson (bedleson@daitc.daitc.mil) since she is no longer employed at our site. Thanks, Duc Tran duc@daitc.daitc.mil ARPANET ..!uunet!daitc!duc UUCP From Owners-CommonLoops.pa@Xerox.COM Mon Nov 14 17:26:30 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01753; Mon, 14 Nov 88 17:26:30 PST Received: from Salvador.ms by ArpaGateway.ms ; 14 NOV 88 15:48:18 PST Return-Path: Redistributed: CommonLoops.pa Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 14 NOV 88 15:44:14 PST Received: from taos.rand.org by rand.org; Mon, 14 Nov 88 15:22:25 PST Received: from localhost by taos.arpa; Mon, 14 Nov 88 15:19:12 PST Message-Id: <8811142319.AA10273@taos.arpa> To: CommonLoops.pa@Xerox.COM Subject: PCL 70 times slower than Ernie with 1000 cars. Date: Mon, 14 Nov 88 15:19:10 PST From: burdorf%taos@rand.org I'm sorry to report this sad fact, but Bruce Florman requested that I do a comparison between ERNIE and PCL with 1000 cars on the carwash simulation. The timings I got were as follows: 8/28/88 (beta rev 1) AAAI PCL running under Allegro on a SUN 3/60: cpu time (non-gc) 4198300 msec user, 4966 msec system cpu time (gc) 673450 msec user, 734 msec system cpu time (total) 4871750 msec user, 5700 msec system real time 4932560 msec ERNIE on a SUN 3/60: runtime=63070 (the time is in milliseconds) gctime=0 The timings were about the same for both ERNIE and PCL with 20 cars, but with 1000 cars, there is no comparision. ERNIE is 78.2077 times faster!!! I realize that this is not the final version of PCL. I hope that this major performance gap can be narrowed in the future. Chris From Owners-CommonLoops.pa@Xerox.COM Mon Nov 14 19:20:49 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03716; Mon, 14 Nov 88 19:20:49 PST Received: from Salvador.ms by ArpaGateway.ms ; 14 NOV 88 19:14:31 PST Return-Path: Redistributed: CommonLoops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 14 NOV 88 19:12:09 PST To: burdorf%taos@RAND-UNIX.ARPA Cc: CommonLoops.pa@Xerox.COM Subject: Re: PCL 70 times slower than Ernie with 1000 cars. In-Reply-To: Your message of Mon, 14 Nov 88 15:19:10 -0800. <8811142319.AA10273@taos.arpa> Date: Mon, 14 Nov 88 22:02:57 -0500 From: Mike Thome Message-Id: <881114-191431-2848@Xerox> How about giving us some theories as to why PCL is so much slower than ERNIE with 1000 cars (is that a K-car?) when they are about the same for smaller cases... I know very well that the PCL implementation of the carwash program conses like mad and, at least on symbolics-related systems, large numbers of cars tend to lead to a better measure of paging & gc speed than processing speed. It makes me very suspicious of comparisons between ernie and pcl when ernie spends 0 time in gc. Is Allegro CL one of the faster versions of CL (I take it that Ernie is not Allegro based)? How about the Allegro PCL port relative to other ports? Inquiring minds want to know! From Owners-commonloops.pa@Xerox.COM Tue Nov 15 12:28:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10506; Tue, 15 Nov 88 12:28:27 PST Received: from Burger.ms by ArpaGateway.ms ; 15 NOV 88 10:09:21 PST Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 15 NOV 88 10:07:39 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA07133; Tue, 15 Nov 88 13:05:12 EST Date: Tue, 15 Nov 88 13:05:29 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA25627; Tue, 15 Nov 88 13:05:29 EST Message-Id: <8811151805.AA25627@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: generating cache offsets I have been examining the reasons that %LOGAND did not work well in KCL for generating slot value cache offsets, and I no longer believe that the problem was with %LOGAND. Instead, I think the (cache collision) problem is that AKCL's implementation of SXHASH produces results with an unfortunate distribution. AKCL builds a fixnum from the first, second, second last, and last characters of the the symbol's print-name. When PCL does %LOGAND on this number, all that is left is bit positions 5 to 0 of the second last character's code, and bit positions 7 to 2 of the last character's code. I compared AKCL's SXHASH implementation with KCL's SXHASH implementation, and noticed that KCL's implementation just returns (FLOOR (SI:ADDRESS x) 4), when x is a symbol, in violation of CLtL's definition of SXHASH. Fix: 1) Either remove my changes to get-slot-value-1 and set-slot-value-1. (These changes were the only part of my message of November 7 that affected implementations other than KCL.) Or change fixnum-cache-no to: (defmacro fixnum-cache-no (mask fixnum) (unless (constantp mask) (error "FIXNUM-CACHE-NO requires its first argument (mask) to be a constant")) (let* ((mask-value (eval mask)) (lsize (integer-length mask-value)) (size (ash 1 lsize)) (words-per-entry (1+ (logxor mask-value (1- size)))) (lwords-per-entry (integer-length (1- words-per-entry)))) `(%logand ,mask (%ash ,fixnum ,lwords-per-entry)))) The usefulness of the %ash above depends on the sxhash implementation: it will help in KCL (otherwise slots named A and B will always collide), it (probably) will not help in Symbolics, and it will help in Lucid (SUN3) (otherwise slots named B and C will always collide). 2) If you do have KCL, patch SXHASH: ;; in kcl-patches (in-package "SYSTEM") (eval-when (compile load eval) (unless (fboundp 'sxhash-internal) (setf (symbol-function 'sxhash-internal) (symbol-function 'sxhash))) ) (defun sxhash (object) (if (symbolp object) (let* ((string (symbol-name object)) (length (length string)) (h 0)) (declare (fixnum h length)) (dotimes (i length h) (declare (fixnum i)) (setq h (the fixnum (+ (the fixnum (+ (the fixnum (ash h 8)) (the fixnum h))) (the fixnum (char-code (aref string i)))))))) (sxhash-internal object))) Rick Harris From Owners-commonloops.pa@Xerox.COM Tue Nov 15 12:45:03 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10764; Tue, 15 Nov 88 12:45:03 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 15 NOV 88 12:04:04 PST Return-Path: Redistributed: commonloops.pa Received: from jade.berkeley.edu ([128.32.136.9]) by Xerox.COM ; 15 NOV 88 12:00:26 PST Received: from dewey.soe.berkeley.edu by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.18B) id AA11229; Tue, 15 Nov 88 11:59:54 PST Received: by dewey.soe.berkeley.edu (5.51/SMI-3.0DEV3.8) id AA07362; Tue, 15 Nov 88 11:57:46 PST Date: Tue, 15 Nov 88 11:57:46 PST From: mkent@SOE.Berkeley.EDU (Marty Kent) Message-Id: <8811151957.AA07362@dewey.soe.berkeley.edu> To: commonloops.pa@Xerox.COM Subject: New book on CLOS programming? I understand there's a new book out on programming in CLOS, and this book features examples and is presented in a generally tutorial style. If anyone out here can tell me the name, author or publisher of the book, I would be very happy. If you have (any of) this information, please mail to me directly, since I don't normally get the postings from this group. Thanks much. . . Marty Kent Sixth Sense Research and Development 415/642 0288 415/548 9129 MKent@dewey.soe.berkeley.edu {uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu Kent's heuristic: Look for it first where you'd most like to find it. From Gregor.pa@Xerox.COM Tue Nov 15 12:48:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10809; Tue, 15 Nov 88 12:48:47 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 12:44:49 PST Date: Tue, 15 Nov 88 12:41 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: burdorf%taos@rand.org Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811142319.AA10273@taos.arpa> Message-Id: <19881115204137.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 14 Nov 88 15:19:10 PST From: burdorf%taos@rand.org I'm sorry to report this sad fact, but Bruce Florman requested that I do a comparison between ERNIE and PCL with 1000 cars on the carwash simulation. In short your numbers are: PCL 4871 seconds (81 minutes) Ernie 63 seconds (1 minute) So that the PCL version of the program is about 78 times slower than the Ernie version. At the end of this message is a version of the carwash program converted to using defstruct and typecase. I can tell you that this version of the program, on a SUN4, in Lucid Lisp, compiled with the prodcution compiler took more than 40 minutes to run (I got tired of waiting for it to finish). This suggests that what is going on here has nothing to do with the object system, but is in fact an artifact of the program. One question I would ask is who wrote the original carwash program? What process was taken to convert that version to the PCL version? I ask is because when I look at the carwash program I see a number of astounding performance bugs. This kind of math is not specialty, but it appears to me that these bugs are more than quadratic in the number of cars. There are also a number of what appear to be off by 1 errors, but I can't tell whether they effect performance. I suspect, but can't know, that in the conversion from ERNIE code to PCL code, some performance inefficiences were inadvertently introduced which have nothing to do with the underlying object system. Once again, I would ask to see the code for the Ernie version of the program. Please try comparing this version of the program with both the ERNIE and PCL versions. Because time is money, you might want to try all three with 500 cars rather than 1000. (defstruct bert) (defstruct (simulator (:include bert) (:conc-name nil)) (things-to-do nil) (history nil) (db nil)) (defstruct (clock (:include bert) (:conc-name nil)) (current-time 0) (actors-running nil) (ticksize 1)) (defvar *clock* (make-clock)) (defun do-after (obj n action) (let ((l (things-to-do obj)) (ti (+ (current-time *clock*) n))) (when (or (not l) (< ti (caar l))) (setf (actors-running *clock*) (inserttm (cons ti obj) (actors-running *clock*)))) (setf (things-to-do obj) (inserttm (cons ti action) (things-to-do obj))))) (defun tick (cl) (let ((newtime (+ (current-time *clock*) (ticksize *clock*)))) (do* ((events (actors-running *clock*) (actors-running *clock*))) ((not (and events (>= newtime (caar events))))) (setf (current-time *clock*) (caar events)) (do ((ev events (cdr ev))) ((not (and ev (equal (current-time *clock*) (caar ev))))) (pop (actors-running *clock*)) (atick (cdar ev)))) (setf (current-time *clock*) newtime))) (defun atick (obj) (let ((ttd nil)) (do nil ((not (and (setq ttd (things-to-do obj)) (>= (current-time *clock*) (caar ttd))))) (EVAL (CDAR TTD)) (pop (things-to-do obj))) (when (things-to-do obj) (setf (actors-running *clock*) (mergetm (cons (caar (things-to-do obj)) obj) (actors-running *clock*)))))) (defun run (cl) (do nil ((not (actors-running cl))) (tick cl))) (DEFUN TICK-TIMES (CL N) ;This is weird, it used (DOTIMES (I (1- N)) ;to use a hand coded do (TICK CL))) ;instead of dotimes. It ;also only does it n-1 ;times not n times. (defun inserttm (itm l) (cond ((null l) (list itm)) ((< (car itm) (CAR (CAR l))) (cons itm l)) (t (cons (car l) (inserttm itm (cdr l)))))) (defun mergetm (itm l) (cond ((member itm l) l) (t (inserttm itm l)))) (defstruct (delayer (:include simulator) (:conc-name nil)) (twxwindow nil) (twxautopix nil) (twautofont nil) (IQ nil) (car-x-pos nil) (car-y-pos nil) (queue-x-pos nil) (queue-y-pos nil) (in-use nil) (delay-factor nil)) (defstruct (vacuumer (:include delayer) (:conc-name nil)) (illegal-alien nil) (vacuumer-ashtray-contents nil) (carwash1-iq nil) (carwash2-iq nil) (carwash1-delay nil) (carwash2-delay nil)) (defstruct (waxer (:include delayer))) (defstruct (carwash (:include delayer))) (defstruct (autos (:include simulator) (:conc-name nil)) (autos-ashtray-contents nil)) (defun ashtray-contents (obj) (etypecase obj (vacuumer (vacuumer-ashtray-contents obj)) (autos (autos-ashtray-contents obj)))) (defvar autoinstances nil) (defvar vacuumer1 (make-vacuumer ':delay-factor 3 ':illegal-alien t ':carwash1-delay 12 ':carwash2-delay 2 ':queue-x-pos 10 ':queue-y-pos 100 ':car-x-pos 50 ':car-y-pos 175)) (defvar waxer1 (make-waxer ':delay-factor 8 ':queue-x-pos 400 ':queue-y-pos 120 ':car-x-pos 430 ':car-y-pos 175)) (defvar carwash1 (make-carwash ':delay-factor 12 ':queue-x-pos 100 ':queue-y-pos 10 ':car-x-pos 200 ':car-y-pos 80)) (defvar carwash2 (make-carwash ':delay-factor 2 ':queue-x-pos 100 ':queue-y-pos 280 ':car-x-pos 200 ':car-y-pos 205)) (defun add-to-queue (obj auto) ;add a new entry to an object's input queue. (setf (iq obj) (APPEND (iq obj) (list auto)))) (defun next-iq-entry (obj) ;process the next iq entry off of a queue. (cond ((iq obj) (do-after obj 0.1 `(write-icon ',obj)) (do-after obj 0.2 `(finish ',obj ',(car (iq obj)))) (setf (in-use obj) t) (setf (iq obj) (cdr (iq obj)))))) (defun not-in-use (obj) ;This function sets the delayer to not in use. (setf (in-use obj) nil)) (defun write-icon (obj) nil) (defun finish-carwash (cwash auto) ;pass the automobile off to the next position. (let ((st (delay-factor cwash))) (do-after cwash st `(write-icon ',cwash)) (do-after waxer1 st `(add-to-queue waxer1 ',auto)) (do-after waxer1 (+ st 0.1) `(next-iq-entry waxer1)) (do-after cwash st `(not-in-use ',cwash)) (do-after cwash st `(next-iq-entry ',cwash)))) (defun leaving-vacuum (vac auto)) (defun stopped-stealing (vax auto)) (defun finish (station auto) (etypecase station (carwash (finish-carwash station auto)) (vacuumer (finish-vacuumer station auto)) (waxer (finish-waxer station auto)))) (defun finish-vacuumer (vac auto) ;preschedule getting the carwash queues. (let* ((vacst (delay-factor vac)) (queue1 (iq carwash1)) (queue2 (iq carwash2)) (empty-carwash (cond ((in-use carwash1) carwash2) ((in-use carwash2) carwash1) ((> (length queue1) (length queue2)) carwash2) (t carwash1))) (delay nil) (st (delay-factor empty-carwash))) (when (and (eq (autos-ashtray-contents auto) 'money) (illegal-alien vac)) (do-after vac 0.5 `(stopped-stealing ',vac ',auto))) (setq delay (+ st (find-times (if (eq empty-carwash carwash1) queue1 queue2)))) (do-after empty-carwash vacst `(add-to-queue ',empty-carwash ',auto)) (do-after empty-carwash delay `(next-iq-entry ',empty-carwash)) (do-after vac vacst `(leaving-vacuum ',vac ',auto)) (do-after vac vacst `(next-iq-entry ',vac)) (do-after vac vacst `(write-icon ',vac)))) (defun find-times (x) (if x (length x) 1)) (defun finish-waxer (wax auto) ;see if more to wax. (let ((st (delay-factor wax))) (do-after wax st `(write-icon ',wax)) (do-after wax st `(next-iq-entry ',wax)))) (defun get-going () (setf (iq vacuumer1) nil) (setf (things-to-do vacuumer1) nil) (setf (things-to-do waxer1) nil) (setf (iq waxer1) nil) (setf (things-to-do carwash1) nil) (setf (iq carwash1) nil) (setf (things-to-do carwash2) nil) (setf (iq carwash2) nil) (setf (actors-running *clock*) nil) (do ((auto (car autoinstances) (car restainst)) (restainst (cdr autoinstances) (cdr restainst)) (n 1 (1+ n))) ((null restainst)) (add-to-queue vacuumer1 (eval auto))) ; (flush-screen artist) (next-iq-entry vacuumer1) (run *clock*)) (defun init-graphics () nil) (defun generate-cars (n) (setq autoinstances nil) (do ((x 1 (1+ x))) ((< n x)) (write-car-instance x))) (defun write-car-instance ( num) (let ((rnum (random num)) (instance (intern (format nil "AUTO-~D" num)))) (setq autoinstances (cons instance autoinstances)) (eval `(defvar ,instance (make-autos ':autos-ashtray-contents (case (rem ,rnum 3) (0 'ashes) (1 'gum) (2 'money))))))) ------- From Gregor.pa@Xerox.COM Tue Nov 15 13:03:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10903; Tue, 15 Nov 88 13:03:15 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 12:55:03 PST Date: Tue, 15 Nov 88 12:52 PST From: Gregor.pa@Xerox.COM Subject: Re: generating cache offsets To: Richard Harris Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811151805.AA25627@turing.cs.rpi.edu> Message-Id: <19881115205226.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 15 Nov 88 13:05:29 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) I have been examining the reasons that %LOGAND did not work well in KCL for generating slot value cache offsets, and I no longer believe that the problem was with %LOGAND. Instead, I think the (cache collision) problem is that AKCL's implementation of SXHASH produces results with an unfortunate distribution. AKCL builds a fixnum from the first, second, second last, and last characters of the the symbol's print-name. When PCL does %LOGAND on this number, all that is left is bit positions 5 to 0 of the second last character's code, and bit positions 7 to 2 of the last character's code. Actually the part of the code you are optimizing isn't used much in PCL anymore. Slot access via accessor methods actually uses a special kind of dcode, and slot access via slot-value in the body of the method uses permutation vectors. So I wouldn't expect these changes to have a significant effect on the performance of a program written in pcl. Most of the other patches you have sent out do have a significant effect, and we are merging them into our sources here. ------- From Owners-commonloops.pa@Xerox.COM Tue Nov 15 14:16:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11582; Tue, 15 Nov 88 14:16:29 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 NOV 88 14:03:03 PST Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 15 NOV 88 14:00:53 PST Date: Tue, 15 Nov 88 16:57:51 EST From: weltyc@fs3.cs.rpi.edu (Christopher A. Welty) Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA07515; Tue, 15 Nov 88 16:57:51 EST Message-Id: <8811152157.AA07515@fs3.cs.rpi.edu> To: mkent@soe.berkeley.edu Cc: commonloops.pa@Xerox.COM In-Reply-To: Marty Kent's message of Tue, 15 Nov 88 11:57:46 PST <8811151957.AA07362@dewey.soe.berkeley.edu> Subject: New book on CLOS programming? i have here a book called "Object Oriented Programming in Common LISP, a Programmers Guide to CLOS" by Sonya E. Keene, Published by Addison-Wesley. It's by no means a reference manual, but a fairly good tutorial and even introduction to object oriented programming (as it were). Also, Winston+Horn's LISP Book 3rd Edition has a lot on CLOS.... ===== Christopher Welty --- Asst. Director, RPI CS Labs weltyc@cs.rpi.edu ...!njin!nyser!weltyc From Owners-commonloops.pa@Xerox.COM Tue Nov 15 14:29:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11675; Tue, 15 Nov 88 14:29:43 PST Received: from Riesling.ms by ArpaGateway.ms ; 15 NOV 88 14:18:08 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 15 NOV 88 14:13:11 PST Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA10882; Tue, 15 Nov 88 14:10:15 PST Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA05225; Tue, 15 Nov 88 14:12:54 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA27076; Tue, 15 Nov 88 14:13:17 PST Message-Id: <8811152213.AA27076@suntana.sun.com> To: mkent@SOE.Berkeley.EDU (Marty Kent) Cc: commonloops.pa@Xerox.COM Subject: Re: New book on CLOS programming? In-Reply-To: Your message of Tue, 15 Nov 88 11:57:46 -0800. <8811151957.AA07362@dewey.soe.berkeley.edu> Date: Tue, 15 Nov 88 14:13:14 PST From: kempf@Sun.COM The name of the book is "An Introduction to Object-Oriented Programming in Common Lisp", the author is Sonia Keene. jak From Owners-CommonLoops.pa@Xerox.COM Tue Nov 15 14:31:56 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11699; Tue, 15 Nov 88 14:31:56 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 NOV 88 14:20:34 PST Return-Path: Redistributed: CommonLoops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 15 NOV 88 14:09:34 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA07525; Tue, 15 Nov 88 17:05:01 EST Date: Tue, 15 Nov 88 17:05:20 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA01608; Tue, 15 Nov 88 17:05:20 EST Message-Id: <8811152205.AA01608@turing.cs.rpi.edu> To: burdorf%taos@rand.org Subject: Re: PCL 70 times slower than Ernie with 1000 cars. Cc: CommonLoops.pa@Xerox.COM Some notes on the carwash program. 1) random The carwash generates its data using a series of calls to the function RANDOM. Thus comparisons of this program in different CL implementations will (probably) be using different data. Since the data generation program, GENERATE-CARS, uses (EVAL `(DEFVAR ...)) and RANDOM, some care must be taken to get exactly reproducable data even in one CL implementation. 2) fraction of the time spent in pcl The data that I have gathered and summarized below indicates that it is impossible to speed up the carwash program by more than 25% by improving PCL. I think that the version of this program that is written in ERNIE really isn't as similar as you say it is. Try changing the carwash program so that it runs without alteration of the source code in either PCL or ERNIE (using macros and #+), and reporting timings you get from that. (If you do this, I would like to get a copy of your code). All the times here were measured on a SUN4/280 using PCL 8/28/88 with some patches and akcl-1-79 with some patches. The estimated times were computed using the average times reported below. +++++ 200 cars, instrumented estimated run times conses 557399 (by explicit calls to cons, list, and append in the carwash program) CachingDF method calls 29637 1.0 secs cache misses 340 0.2 secs ReaderDF method calls 191502 6.1 secs cache misses 14 0.0 secs WriterDF method calls 50593 1.6 secs cache misses 11 0.0 secs Reads 0 Get-Slot-Value cache misses 0 Writes 0 Set-Slot-Value cache misses 0 (slot-value is called in only one place in this program; I believe that slot-value performance does not matter here) real time 91.9 secs run time 83.5 secs +++++ 200 cars, uninstrumented estimated run time of PCL operations real time 48.3 secs run time 37.0 secs 9.0 secs +++++ 100000 calls to a CachingDF (2 args, no rest arg, disc. on first arg only) real time 3.8 secs run time 3.4 secs +++++ 10000 calls to pcl::caching-dcode-miss (2 args, no rest arg, disc. on first arg only) real time 6.6 secs run time 5.9 secs +++++ 100000 calls to a ReaderDF real time 3.6 secs run time 3.2 secs +++++ 100000 calls to a WriterDF real time 3.3 secs run time 3.2 secs Rick Harris From Owners-CommonLoops.pa@Xerox.COM Tue Nov 15 14:34:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11730; Tue, 15 Nov 88 14:34:37 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 14:23:49 PST Return-Path: Redistributed: CommonLoops.pa Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 15 NOV 88 14:18:29 PST Received: from taos.rand.org by rand.org; Tue, 15 Nov 88 13:50:53 PST Received: from localhost by taos.arpa; Tue, 15 Nov 88 13:47:36 PST Message-Id: <8811152147.AA11437@taos.arpa> To: burdorf%taos@rand.org, CommonLoops.pa@Xerox.COM, burdorf%taos@rand.org Subject: Re: PCL 70 times slower than Ernie with 1000 cars. In-Reply-To: Your message of Mon, 14 Nov 88 22:02:57 EST. <881114-191431-2848@Xerox> Date: Tue, 15 Nov 88 13:47:34 PST From: burdorf%taos@rand.org Hello, 1. I talked to the creator of ERNIE, he says that the major difference between ERNIE and PCL that he could see right off was that ERNIE allows you to put declarations on your methods that get around the dispatching problem (it is not required though). Message invokations are then straight function calls. Gregor, I appreciate the defstruct version of the carwash program, but myself and everyone else at RAND feels that it is missing the whole point. They say that typecases are known to be slow. They are not suprised that they typecase version is slower than PCL. The fact is that if you use the correct declarations in Ernie there is no typecaseing or method dispatch problem, it's just a flat out (call subr). 2. I ran the carwash with 1000 objects with KCL on the SUN 3/60 and it was twice as slow as the Allegro version. I kept an audit trail of page faults and I got very little. 3. I can't give out anything on ERNIE. I don't know if you are familiar with Daniel Ellesberg, but he walked out of RAND with the Pentagon Papers and ever since then RAND is super uptight about letting anything out. I would have to get about 8 people to approve it and it would take about a month or more. If I just send it out, I could get Fired. I'm allowed to talk about it though. I don't make these rules. I did have someone else here (Bruce Florman) go over the code in both PCL and ERNIE versions and he said they were the same execept for the special declares for methods in ERNIE. I don't think that the comment that I must've screwed up when I converted from ERNIE to PCL is constructive. If there is a faster way to code the carwash simulation in PCL, then show me? 4. As for garbage collection, the PSL image that I run ERNIE in is 10 megs, compared with about 4.5 megs for the Allegro I run PCL in. That may account for the fact that there is no GC's when I run ERNIE. 5. When I find some time, I will convert Gregor's defstruct version of the carwash so that there are no typecases (ie. get rid of the general purpose functions.) I think that would greatly speed up the defstruct version. Chris From Owners-commonloops.pa@Xerox.COM Tue Nov 15 14:40:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11753; Tue, 15 Nov 88 14:40:33 PST Received: from Riesling.ms by ArpaGateway.ms ; 15 NOV 88 14:34:21 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 15 NOV 88 14:13:11 PST Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA10882; Tue, 15 Nov 88 14:10:15 PST Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA05225; Tue, 15 Nov 88 14:12:54 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA27076; Tue, 15 Nov 88 14:13:17 PST Message-Id: <8811152213.AA27076@suntana.sun.com> To: mkent@SOE.Berkeley.EDU (Marty Kent) Cc: commonloops.pa@Xerox.COM Subject: Re: New book on CLOS programming? In-Reply-To: Your message of Tue, 15 Nov 88 11:57:46 -0800. <8811151957.AA07362@dewey.soe.berkeley.edu> Date: Tue, 15 Nov 88 14:13:14 PST From: kempf@Sun.COM The name of the book is "An Introduction to Object-Oriented Programming in Common Lisp", the author is Sonia Keene. jak From Lanning.pa@Xerox.COM Tue Nov 15 15:23:22 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12206; Tue, 15 Nov 88 15:23:22 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 15:16:22 PST Date: 15 Nov 88 15:10 PST From: Stan Lanning Subject: Re: Debugging in PCL In-Reply-To: thoms@caen.engin.umich.edu (Dale E Thoms)'s message of Sun, 13 Nov 88 23:08:41 EST To: thoms@caen.engin.umich.edu (Dale E Thoms) Cc: CommonLoops.pa@Xerox.COM Message-Id: <881115-151622-4573@Xerox> For those of you using Envos (nee Xerox) Lisp, PCL comes with a file or two that define some useful environment hacks. > Methods and class are understood by the SourceManager. Methods are named ( qualifier ... (specializer ...)). > Backtrace shows methods and generic-functions, not the raw gibberish that is "really" there. Selecting a method from the backtrace window will let you edit that method. > The inspector knows about objects, and shows the slots & values instead of the "real" structure of the objects. The inspector computes the slots and values via generic-functions, so you can specialize what is shown in the inspector. > (ed ') will prompt you to select a particular method on the generic-function, saving a lot of typing. I'm sure there's some other stuff, but I can't remember it right now. ----- smL From Owners-CommonLoops.pa@Xerox.COM Tue Nov 15 16:43:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16609; Sun, 13 Nov 88 20:20:03 PST Received: from Burger.ms by ArpaGateway.ms ; 13 NOV 88 20:18:23 PST Return-Path: Redistributed: CommonLoops.pa Received: from caen.engin.umich.edu ([35.1.5.2]) by Xerox.COM ; 13 NOV 88 20:17:22 PST Received: by caen.engin.umich.edu (5.59.1/umix-2.0) id 3fa748ddd.000b179; Sun, 13 Nov 88 23:08:41 EST Date: Sun, 13 Nov 88 23:08:41 EST From: thoms@caen.engin.umich.edu (Dale E Thoms) Message-Id: <3fa748ddd.000b179@caen.engin.umich.edu> To: CommonLoops.pa@Xerox.COM Subject: Debugging in PCL Has anyone written any debugging tools specifically for use with PCL/CLOS? Any references to papers, and/or code would be appreciated. Even if you don't know of any tools for object-oriented debugging, how do you go about debugging methods and instances as opposed to ordinary functions? Thanks, Dale Thoms thoms@caen.engin.umich.edu AI Lab University of Michigan Ann Arbor, Michigan 48109-2110 From Gregor.pa@Xerox.COM Tue Nov 15 16:53:52 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10809; Tue, 15 Nov 88 12:48:47 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 12:44:49 PST Date: Tue, 15 Nov 88 12:41 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: burdorf%taos@rand.org Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811142319.AA10273@taos.arpa> Message-Id: <19881115204137.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 14 Nov 88 15:19:10 PST From: burdorf%taos@rand.org I'm sorry to report this sad fact, but Bruce Florman requested that I do a comparison between ERNIE and PCL with 1000 cars on the carwash simulation. In short your numbers are: PCL 4871 seconds (81 minutes) Ernie 63 seconds (1 minute) So that the PCL version of the program is about 78 times slower than the Ernie version. At the end of this message is a version of the carwash program converted to using defstruct and typecase. I can tell you that this version of the program, on a SUN4, in Lucid Lisp, compiled with the prodcution compiler took more than 40 minutes to run (I got tired of waiting for it to finish). This suggests that what is going on here has nothing to do with the object system, but is in fact an artifact of the program. One question I would ask is who wrote the original carwash program? What process was taken to convert that version to the PCL version? I ask is because when I look at the carwash program I see a number of astounding performance bugs. This kind of math is not specialty, but it appears to me that these bugs are more than quadratic in the number of cars. There are also a number of what appear to be off by 1 errors, but I can't tell whether they effect performance. I suspect, but can't know, that in the conversion from ERNIE code to PCL code, some performance inefficiences were inadvertently introduced which have nothing to do with the underlying object system. Once again, I would ask to see the code for the Ernie version of the program. Please try comparing this version of the program with both the ERNIE and PCL versions. Because time is money, you might want to try all three with 500 cars rather than 1000. (defstruct bert) (defstruct (simulator (:include bert) (:conc-name nil)) (things-to-do nil) (history nil) (db nil)) (defstruct (clock (:include bert) (:conc-name nil)) (current-time 0) (actors-running nil) (ticksize 1)) (defvar *clock* (make-clock)) (defun do-after (obj n action) (let ((l (things-to-do obj)) (ti (+ (current-time *clock*) n))) (when (or (not l) (< ti (caar l))) (setf (actors-running *clock*) (inserttm (cons ti obj) (actors-running *clock*)))) (setf (things-to-do obj) (inserttm (cons ti action) (things-to-do obj))))) (defun tick (cl) (let ((newtime (+ (current-time *clock*) (ticksize *clock*)))) (do* ((events (actors-running *clock*) (actors-running *clock*))) ((not (and events (>= newtime (caar events))))) (setf (current-time *clock*) (caar events)) (do ((ev events (cdr ev))) ((not (and ev (equal (current-time *clock*) (caar ev))))) (pop (actors-running *clock*)) (atick (cdar ev)))) (setf (current-time *clock*) newtime))) (defun atick (obj) (let ((ttd nil)) (do nil ((not (and (setq ttd (things-to-do obj)) (>= (current-time *clock*) (caar ttd))))) (EVAL (CDAR TTD)) (pop (things-to-do obj))) (when (things-to-do obj) (setf (actors-running *clock*) (mergetm (cons (caar (things-to-do obj)) obj) (actors-running *clock*)))))) (defun run (cl) (do nil ((not (actors-running cl))) (tick cl))) (DEFUN TICK-TIMES (CL N) ;This is weird, it used (DOTIMES (I (1- N)) ;to use a hand coded do (TICK CL))) ;instead of dotimes. It ;also only does it n-1 ;times not n times. (defun inserttm (itm l) (cond ((null l) (list itm)) ((< (car itm) (CAR (CAR l))) (cons itm l)) (t (cons (car l) (inserttm itm (cdr l)))))) (defun mergetm (itm l) (cond ((member itm l) l) (t (inserttm itm l)))) (defstruct (delayer (:include simulator) (:conc-name nil)) (twxwindow nil) (twxautopix nil) (twautofont nil) (IQ nil) (car-x-pos nil) (car-y-pos nil) (queue-x-pos nil) (queue-y-pos nil) (in-use nil) (delay-factor nil)) (defstruct (vacuumer (:include delayer) (:conc-name nil)) (illegal-alien nil) (vacuumer-ashtray-contents nil) (carwash1-iq nil) (carwash2-iq nil) (carwash1-delay nil) (carwash2-delay nil)) (defstruct (waxer (:include delayer))) (defstruct (carwash (:include delayer))) (defstruct (autos (:include simulator) (:conc-name nil)) (autos-ashtray-contents nil)) (defun ashtray-contents (obj) (etypecase obj (vacuumer (vacuumer-ashtray-contents obj)) (autos (autos-ashtray-contents obj)))) (defvar autoinstances nil) (defvar vacuumer1 (make-vacuumer ':delay-factor 3 ':illegal-alien t ':carwash1-delay 12 ':carwash2-delay 2 ':queue-x-pos 10 ':queue-y-pos 100 ':car-x-pos 50 ':car-y-pos 175)) (defvar waxer1 (make-waxer ':delay-factor 8 ':queue-x-pos 400 ':queue-y-pos 120 ':car-x-pos 430 ':car-y-pos 175)) (defvar carwash1 (make-carwash ':delay-factor 12 ':queue-x-pos 100 ':queue-y-pos 10 ':car-x-pos 200 ':car-y-pos 80)) (defvar carwash2 (make-carwash ':delay-factor 2 ':queue-x-pos 100 ':queue-y-pos 280 ':car-x-pos 200 ':car-y-pos 205)) (defun add-to-queue (obj auto) ;add a new entry to an object's input queue. (setf (iq obj) (APPEND (iq obj) (list auto)))) (defun next-iq-entry (obj) ;process the next iq entry off of a queue. (cond ((iq obj) (do-after obj 0.1 `(write-icon ',obj)) (do-after obj 0.2 `(finish ',obj ',(car (iq obj)))) (setf (in-use obj) t) (setf (iq obj) (cdr (iq obj)))))) (defun not-in-use (obj) ;This function sets the delayer to not in use. (setf (in-use obj) nil)) (defun write-icon (obj) nil) (defun finish-carwash (cwash auto) ;pass the automobile off to the next position. (let ((st (delay-factor cwash))) (do-after cwash st `(write-icon ',cwash)) (do-after waxer1 st `(add-to-queue waxer1 ',auto)) (do-after waxer1 (+ st 0.1) `(next-iq-entry waxer1)) (do-after cwash st `(not-in-use ',cwash)) (do-after cwash st `(next-iq-entry ',cwash)))) (defun leaving-vacuum (vac auto)) (defun stopped-stealing (vax auto)) (defun finish (station auto) (etypecase station (carwash (finish-carwash station auto)) (vacuumer (finish-vacuumer station auto)) (waxer (finish-waxer station auto)))) (defun finish-vacuumer (vac auto) ;preschedule getting the carwash queues. (let* ((vacst (delay-factor vac)) (queue1 (iq carwash1)) (queue2 (iq carwash2)) (empty-carwash (cond ((in-use carwash1) carwash2) ((in-use carwash2) carwash1) ((> (length queue1) (length queue2)) carwash2) (t carwash1))) (delay nil) (st (delay-factor empty-carwash))) (when (and (eq (autos-ashtray-contents auto) 'money) (illegal-alien vac)) (do-after vac 0.5 `(stopped-stealing ',vac ',auto))) (setq delay (+ st (find-times (if (eq empty-carwash carwash1) queue1 queue2)))) (do-after empty-carwash vacst `(add-to-queue ',empty-carwash ',auto)) (do-after empty-carwash delay `(next-iq-entry ',empty-carwash)) (do-after vac vacst `(leaving-vacuum ',vac ',auto)) (do-after vac vacst `(next-iq-entry ',vac)) (do-after vac vacst `(write-icon ',vac)))) (defun find-times (x) (if x (length x) 1)) (defun finish-waxer (wax auto) ;see if more to wax. (let ((st (delay-factor wax))) (do-after wax st `(write-icon ',wax)) (do-after wax st `(next-iq-entry ',wax)))) (defun get-going () (setf (iq vacuumer1) nil) (setf (things-to-do vacuumer1) nil) (setf (things-to-do waxer1) nil) (setf (iq waxer1) nil) (setf (things-to-do carwash1) nil) (setf (iq carwash1) nil) (setf (things-to-do carwash2) nil) (setf (iq carwash2) nil) (setf (actors-running *clock*) nil) (do ((auto (car autoinstances) (car restainst)) (restainst (cdr autoinstances) (cdr restainst)) (n 1 (1+ n))) ((null restainst)) (add-to-queue vacuumer1 (eval auto))) ; (flush-screen artist) (next-iq-entry vacuumer1) (run *clock*)) (defun init-graphics () nil) (defun generate-cars (n) (setq autoinstances nil) (do ((x 1 (1+ x))) ((< n x)) (write-car-instance x))) (defun write-car-instance ( num) (let ((rnum (random num)) (instance (intern (format nil "AUTO-~D" num)))) (setq autoinstances (cons instance autoinstances)) (eval `(defvar ,instance (make-autos ':autos-ashtray-contents (case (rem ,rnum 3) (0 'ashes) (1 'gum) (2 'money))))))) ------- From Lanning.pa@Xerox.COM Tue Nov 15 17:36:52 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12206; Tue, 15 Nov 88 15:23:22 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 NOV 88 15:16:22 PST Date: 15 Nov 88 15:10 PST From: Stan Lanning Subject: Re: Debugging in PCL In-Reply-To: thoms@caen.engin.umich.edu (Dale E Thoms)'s message of Sun, 13 Nov 88 23:08:41 EST To: thoms@caen.engin.umich.edu (Dale E Thoms) Cc: CommonLoops.pa@Xerox.COM Message-Id: <881115-151622-4573@Xerox> For those of you using Envos (nee Xerox) Lisp, PCL comes with a file or two that define some useful environment hacks. > Methods and class are understood by the SourceManager. Methods are named ( qualifier ... (specializer ...)). > Backtrace shows methods and generic-functions, not the raw gibberish that is "really" there. Selecting a method from the backtrace window will let you edit that method. > The inspector knows about objects, and shows the slots & values instead of the "real" structure of the objects. The inspector computes the slots and values via generic-functions, so you can specialize what is shown in the inspector. > (ed ') will prompt you to select a particular method on the generic-function, saving a lot of typing. I'm sure there's some other stuff, but I can't remember it right now. ----- smL From Owners-CommonLoops.pa@Xerox.COM Wed Nov 16 06:53:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20402; Wed, 16 Nov 88 06:53:42 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 NOV 88 06:45:26 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@RACINE.ACA.MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 16 NOV 88 06:44:03 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Wed 16 Nov 88 08:43:46-CST Date: Wed, 16 Nov 88 08:43 CST From: Nat Ballou Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: CommonLoops.pa@Xerox.COM Cc: burdorf%taos@rand.org Message-Id: <19881116144313.1.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 ---> Who would ever want to measure the performance of code like this???? (defun write-car-instance ( num) (let ((rnum (random num)) (instance (intern (format nil "AUTO-~D" num)))) ------ (setq autoinstances (cons instance autoinstances)) (eval `(defvar ,instance (make-autos ---- ------ ':autos-ashtray-contents (case (rem ,rnum 3) (0 'ashes) (1 'gum) (2 'money))))))) From Owners-commonloops.pa@Xerox.COM Wed Nov 16 07:47:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20768; Wed, 16 Nov 88 07:47:40 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 NOV 88 07:46:03 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 16 NOV 88 07:44:47 PST Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA24228; Wed, 16 Nov 88 07:41:59 PST Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA23995; Wed, 16 Nov 88 07:44:53 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA29111; Wed, 16 Nov 88 07:45:17 PST Message-Id: <8811161545.AA29111@suntana.sun.com> To: kempf@Sun.COM Cc: mkent@SOE.Berkeley.EDU (Marty Kent), commonloops.pa@Xerox.COM Subject: Re: New book on CLOS programming? In-Reply-To: Your message of Tue, 15 Nov 88 14:13:14 -0800. <8811152213.AA27076@suntana.sun.com> Date: Wed, 16 Nov 88 07:45:14 PST From: kempf@Sun.COM That's "Sonya" not "Sonia" Keene. Sorry for the typo. jak From Gregor.pa@Xerox.COM Wed Nov 16 11:15:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22328; Wed, 16 Nov 88 11:15:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 NOV 88 11:09:44 PST Date: Wed, 16 Nov 88 11:04 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: burdorf%taos@rand.org Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811152147.AA11437@taos.arpa> Message-Id: <19881116190402.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Please don't send anymore of these message until you are ready to show us the source code in ERNIE. There is no basis in fact to believe that you are comparing apples to apples. Other people on the list have pointed to irregularities in your measurements, but none of us can conclude anything without knowing exactly what the comparison is. Statements like "my friend Bill compared the two programs and said they were the same" just don't cut it. This is a (basically) scientific community. If you are going to make performance claims or discuss measurements you have to show exactly what you measured and how you measured it. That is what makes it possible for others to respond to your claims directly. It is also what makes it possible for us as implementors to know how to improve the performance of our systems. If it becomes possible for you to make the code available, and you decide to present your performance numbers again, you might consider checking your results with other individuals before sending them to such a large list. It is often a good idea to subject provacative claims to some sort of external peer review before presenting them to a large audience. ------- From Owners-CommonLoops.pa@Xerox.COM Wed Nov 16 13:02:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23176; Wed, 16 Nov 88 13:02:10 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 NOV 88 12:55:43 PST Return-Path: Redistributed: CommonLoops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 16 NOV 88 12:52:18 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA09206; Wed, 16 Nov 88 15:47:18 EST Date: Wed, 16 Nov 88 15:47:32 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA20285; Wed, 16 Nov 88 15:47:32 EST Message-Id: <8811162047.AA20285@turing.cs.rpi.edu> To: ballou@racine.aca.mcc.com Subject: Re: PCL 70 times slower than Ernie with 1000 cars. Cc: CommonLoops.pa@Xerox.COM, burdorf%taos@rand.org Who is measuring the performance of that code? That code creates the data which the code that is measured uses. I should point out, though, that the code that is measured uses EVAL of forms created with backquote rather than FUNCALL of lexical closures. I don't think the carwash program is a very good benchmark for CLOS, but it is the only one that I know about. If you have some CLOS code (which you can distribute freely), that you think would be a better benchmark, please tell us about it. Rick Harris From Owners-commonloops.pa@Xerox.COM Wed Nov 16 14:27:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24486; Wed, 16 Nov 88 14:27:09 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 NOV 88 14:25:09 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 16 NOV 88 14:22:29 PST Received: from vuse.Vanderbilt.Edu by uunet.UU.NET (5.59/1.14) id AA14722; Wed, 16 Nov 88 17:20:03 EST Received: from ee6.vuse.uucp by vuse.vanderbilt.edu (4.0/SMI-3.2) id AA15764; Wed, 16 Nov 88 16:19:28 CST Received: by ee6.vuse.uucp (3.2/SMI-3.2) id AA19310; Wed, 16 Nov 88 16:16:02 CST Date: Wed, 16 Nov 88 16:16:02 CST From: brian@vuse.vanderbilt.edu (Brian Antao) Message-Id: <8811162216.AA19310@ee6.vuse.uucp> To: gregor.pa@Xerox.COM Subject: moderating clos mailing list Cc: commonloops.pa@Xerox.COM Gregor, Could you somewhat moderate the CLOS mailing list to filter out a lot of the absolute trash that has been posted on lately. I thought the purposes of mailing lists are to disseminate ideas and questions of a wide interest and usefulness pertaining the clos/pcl design and operationality, and aimed at I suppose a more scientifically minded community. This is not a place to post discussions from a bunch of hackers trying to impose on their personal unfounded biases. Thanks. --Brian. From Owners-CommonLoops.PA@Xerox.COM Wed Nov 16 14:38:21 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24551; Wed, 16 Nov 88 14:38:21 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 NOV 88 14:29:14 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@RACINE.ACA.MCC.COM> Redistributed: CommonLoops.PA Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 16 NOV 88 14:26:04 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Wed 16 Nov 88 16:20:25-CST Date: Wed, 16 Nov 88 16:18 CST From: Nat Ballou Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: CommonLoops.PA@Xerox.COM Message-Id: <19881116221844.6.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Would someone please point out to me exactly what code is being measured in the car wash program. It seems to be a very strange Common Lisp program - never mind PCL. "I should point out, though, that the code that is measured uses EVAL of forms created with backquote rather than FUNCALL of lexical closures." Yeah, this is usually not something anyone would want to time. Nat Ballou From Owners-commonloops.pa@Xerox.COM Wed Nov 16 18:43:07 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26771; Wed, 16 Nov 88 18:43:07 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 NOV 88 18:35:30 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 16 NOV 88 18:32:25 PST To: commonloops.pa@Xerox.COM Subject: RE: PCL isn't so bad after all (even at washing cars!) Date: Wed, 16 Nov 88 21:27:09 -0500 From: Mike Thome Message-Id: <881116-183530-1286@Xerox> Since everyone seemed to have been thrown into convulsions at the thought of PCL being so mind-bogglingly bad, I thought I'd look into the problem. First (to keep everyone reading) here are my results w/1000 cars: Machine: Symbolics 3650 (best of 4 trials - 'cept for the original :-) ---code--- ---total time (page&gc time)--- original clos port: 61.65 min (13.33 min) below (modified): 28.25 sec (1.6 sec) <- ~130 times speedup no methods in the clos-simulation part (only the carwash part): 27.65 sec (1.7 sec) Now that we're all awake, here's what I did: (1) cut out much needless consing. (2) cut out most refs to global vars. (3) turned EVALs into APPLYs. (4) turned a few complex-recursive functions into iterative ones. (5) reorganized style/syntax (mostly for my own sake) In doing the obove, I assumed that what the original benchmark was intended to measure was the carwash itself, as opposed to the simulator (which, frankly, directly translated would not have run efficiently in any language I know of). So I felt no restrictions on rewriting much of the simulator functions to be more efficient without changing the functionality. The second (slightly faster) modified time above is for the simulation with all generic functions that have only 1 method turned into regular functions (Chris mentioned that in Ernie, one can add declarations inside methods to achieve this effect - you lose the some of the error catching capability, but it may be faster). I'm still not really convinced that the carwash is the right benchmark (especially after all this!), mostly because the difference between implementing all gfns with one method as functions made such a small difference. Finally, I gather that Ernie is quite a different language from lisp, and I'm not at all convinced that we're not comparing apples and monkey wrenches. Anyway - below is the source for my version of the benchmark... still could use tuning, but at least we're much better off than we were. -mik ;------------------------------------------------ ;;; -*- Package: PCL; Syntax: Common-Lisp -*- ;;; clos-simulator.lsp ;;; ;;; Author: Chris Burdorf ;;; Taken from Dave McArthur's Bert simulator. ;;; Modified by Mike Thome (mthome@bbn.com) 16 Nov '88 ;;; (I *KNEW* that pcl couldn't be THAT bad!) ;;; ;;; Here are the two files. To run the system: ;;; 1. load clos-simulator first ;;; 2. after loading the carwash, do (generate-cars num) where num ;;; is the number of automobiles in the simulation. I used 20 for my tests. ;;; 3. Then type (get-going). That should do it. (defclass bert nil nil) (defclass simulator (bert) ((things-to-do :accessor things-to-do :initform nil) ; elem = (time . (func . args)) (history :accessor history :initform nil) (db :accessor db :initform nil))) (defclass clock (bert) ((current-time :accessor current-time :initform 0) (actors-running :accessor actors-running :initform nil) ; elem = (time . simulator) (ticksize :accessor ticksize :initform 1))) (defvar *clock* (make-instance 'clock)) ;;;Insert an action into an object's agenda after time n. (defmethod do-after ((obj simulator) n action) (let ((l (things-to-do obj)) (ti (+ (current-time *clock*) n))) (when (or (not l) (< ti (caar l))) (setf (actors-running *clock*) (inserttm (cons ti obj) (actors-running *clock*)))) (setf (things-to-do obj) (inserttm (cons ti action) (things-to-do obj))))) (defvar *clocktrace nil) (defmethod tick ((cl clock)) "Cycle through all the actors and execute methods to be done at this time." (let ((newtime (+ (current-time cl) (ticksize cl)))) (do* ((events (actors-running cl) (actors-running cl))) ((or (null events) (> (caar events) newtime))) (setf (current-time cl) (caar events)) (do ((ev events (cdr ev))) ((or (null ev) (/= (current-time cl) (caar ev)))) (pop (actors-running cl)) ;;(when *clocktrace (format t "\/\/") (format t (cdar events))) (atick (cdar ev) cl))) (setf (current-time cl) newtime))) (defmethod atick ((obj bert) cl) "Execute messages to be done at this time." (let ((ttd nil)) (loop (when (or (null (setq ttd (car (things-to-do obj)))) (< (current-time cl) (car ttd))) (return)) (apply (cadr ttd) (cddr ttd)) (pop (things-to-do obj))) (when ttd (setf (actors-running cl) (mergetm (cons (car ttd) obj) (actors-running cl)))))) ;;;;;;;;;;;; ;;;run the simulation until there are no more actors running. (defmethod run ((cl clock)) (loop (if (actors-running cl) (tick cl) (return)))) (defmethod tick-times ((cl clock) n) (dotimes (j (1- n)) (tick cl))) ;; inserttm inserts events or plans into a list of same to maintain ;; a minimum first ordering of elements. a plan or event element ;; is a cons of a time (integer) followed by action or actor (defun inserttm (itm l) (let ((itm-time (car itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (<= itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons)))))))) #+ignore ; this one works as advertised (defun mergetm (itm l) (let ((itm-time (car itm)) (itm-rest (cdr itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (< itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons))) (when (and (= itm-time (caar this-cons)) (equal itm-rest (cdar this-cons))) (return l))))))) ;;; this is a direct translation from the original... and is not likely to work. ;;; However, changing to the above (working) code slows things down a little - ;;; probably because of the expense of doing lots of EQUALs. Note that things would ;;; be even faster if inserttm were used instead of mergetm. ;; mergetm inserts as above but only if itm is not already in l (defun mergetm (itm l) (let ((itm-time (car itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (< itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons))) (when (eql itm (car this-cons)) (return l))))))) ;;;------------------------------------------------------------------------ ;;; -*- Package: PCL; Syntax: Common-Lisp -*- ;;; CLASS STRUCTURE & ATTRIBUTES ;;; load clos-simulator.lisp first ;;; File: Carwash.lsp ;; carwash simulation ; time warp version using twbert and functional access of variables. ; author: Chris Burdorf ; date: 7-87 ;; Classes (defclass delayer (simulator) ((twxwindow :accessor twxwindow :initform nil) (twxautopix :accessor twautopix :initform nil) (twautofont :accessor twautofont :initform nil) (IQ :accessor IQ :initform nil) (car-x-pos :accessor car-x-pos :initform nil) (car-y-pos :accessor car-y-pos :initform nil) (queue-x-pos :accessor queue-x-pos :initform nil) (queue-y-pos :accessor queue-y-pos :initform nil) (in-use :accessor in-use :initform nil) (delay-factor :accessor delay-factor :initform nil))) (defclass vacuumer (delayer) ((illegal-alien :accessor illegal-alien :initform nil) (ashtray-contents :accessor ashtray-contents :initform nil) (carwash1-iq :accessor carwash1-iq :initform nil) (carwash2-iq :accessor carwash2-iq :initform nil) (carwash1-delay :accessor carwash1-delay :initform nil) (carwash2-delay :accessor carwash2-delay :initform nil))) (defclass waxer (delayer) nil) (defclass carwash (delayer) nil) (defclass autos (simulator) ((ashtray-contents :accessor ashtray-contents :initform nil))) (defvar autoinstances nil) ;Instances% (defvar vacuumer1 (make-instance 'vacuumer :delay-factor 3 :illegal-alien t :carwash1-delay 12 :carwash2-delay 2 :queue-x-pos 10 :queue-y-pos 100 :car-x-pos 50 :car-y-pos 175)) (defvar waxer1 (make-instance 'waxer :delay-factor 8 :queue-x-pos 400 :queue-y-pos 120 :car-x-pos 430 :car-y-pos 175)) (defvar carwash1 (make-instance 'carwash :delay-factor 12 :queue-x-pos 100 :queue-y-pos 10 :car-x-pos 200 :car-y-pos 80)) (defvar carwash2 (make-instance 'carwash :delay-factor 2 :queue-x-pos 100 :queue-y-pos 280 :car-x-pos 200 :car-y-pos 205)) ;methods; (defmethod add-to-queue ((obj delayer) (auto autos)) "add a new entry to an object's input queue." ;;(format t "Adding ~a to ~a's input queue.~%" auto obj) (setf (iq obj) (nconc (iq obj) (list auto)))) (defmethod next-iq-entry ((obj delayer)) "process the next iq entry off of a queue." (when (iq obj) ;;(format t "~a on auto ~a~%" obj (car (iq obj))) (do-after obj 0.1 `(write-icon ,obj)) (do-after obj 0.2 `(finish ,obj ,(car (iq obj)))) (setf (in-use obj) t (iq obj) (cdr (iq obj))))) (defmethod not-in-use ((obj delayer)) "This function sets the delayer to not in use." (setf (in-use obj) nil)) (defmethod write-icon ((obj delayer)) "write the icon to expose or to erase from the screen." nil) (defmethod finish ((cwash carwash) auto) "pass the automobile off to the next position." ;;(format t "~a is leaving ~a~%" auto cwash) (let ((st (delay-factor cwash))) (do-after cwash st `(write-icon ,cwash)) (do-after waxer1 st `(add-to-queue ,waxer1 ,auto)) (do-after waxer1 (+ st 0.1) `(next-iq-entry ,waxer1)) (do-after cwash st `(not-in-use ,cwash)) (do-after cwash st `(next-iq-entry ,cwash)))) (defmethod leaving-vacuum ((vac vacuumer) (auto autos)) "This method causes the car to leave the vacuumer." ;;(format t "~a leaving vacuum ~a.~%" auto vac) ) (defmethod stopped-stealing ((vax vacuumer) (auto autos)) "indicate to graphics that you are no longer stealing money." ;;(format t "~a stopped stealing money from ~a~%" vax auto) ) (defmethod finish ((vac vacuumer) (auto autos)) ;preschedule getting the carwash queues. (let* ((vacst (delay-factor vac)) (queue1 (iq carwash1)) (queue2 (iq carwash2)) (empty-carwash (cond ((in-use carwash1) carwash2) ((in-use carwash2) carwash1) ((> (length queue1) (length queue2)) carwash2) (t carwash1))) (delay nil) (st (delay-factor empty-carwash))) (when (and (eq (ashtray-contents auto) 'money)(illegal-alien vac)) ;;(format t "~a is stealing money from ~a~%" vac auto) (do-after vac 0.5 `(stopped-stealing ,vac ,auto))) (setq delay (+ st (find-times (if (eq empty-carwash carwash1) queue1 queue2)))) (do-after empty-carwash vacst `(add-to-queue ,empty-carwash ,auto)) (do-after empty-carwash delay `(next-iq-entry ,empty-carwash)) (do-after vac vacst `(leaving-vacuum ,vac ,auto)) (do-after vac vacst `(next-iq-entry ,vac)) (do-after vac vacst `(write-icon ,vac)))) (defun find-times (x) (if x (length x) 1)) (defmethod finish ((wax waxer) auto) ;;(format t "~a is leaving ~a~%" auto wax) (let ((st (delay-factor wax))) (do-after wax st `(write-icon ,wax)) (do-after wax st `(next-iq-entry ,wax)))) (defun get-going () (setf (iq vacuumer1) nil (things-to-do vacuumer1) nil (things-to-do waxer1) nil (iq waxer1) nil (things-to-do carwash1) nil (iq carwash1) nil (things-to-do carwash2) nil (iq carwash2) nil (actors-running *clock*) nil) (dolist (auto autoinstances) (add-to-queue vacuumer1 auto)) (next-iq-entry vacuumer1) (run *clock*)) ;------------------------graphics initialization --------------------- (defun init-graphics () nil) (defun generate-cars (n) (let ((collection nil)) (dotimes (i n) (push (make-instance 'autos :ashtray-contents (case (rem i 3) (0 'ashes) (1 'gum) (2 'money))) collection)) (setq autoinstances collection)) 'done) From Owners-commonloops.pa@Xerox.COM Wed Nov 16 18:57:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26878; Wed, 16 Nov 88 18:57:47 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 NOV 88 18:56:08 PST Return-Path: Redistributed: commonloops.pa Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 16 NOV 88 18:52:54 PST Received: from whitechapel.media.mit.edu by media-lab.media.mit.edu (5.59/4.8) id AA09515; Wed, 16 Nov 88 21:52:36 EST Received: by whitechapel (3.2/4.8) id AA09936; Wed, 16 Nov 88 21:52:12 EST Date: Wed, 16 Nov 88 21:52:12 EST From: Michael Sokolov Message-Id: <8811170252.AA09936@whitechapel> To: brian@vuse.vanderbilt.edu Cc: gregor.pa@Xerox.COM, commonloops.pa@Xerox.COM Subject: moderating clos mailing list I agree that most of the discussion on ERNIE vs. PCL has been unsubstantiated name-calling, but it does raise an interesting issue: namely, the issue of type declarations. There are obviously going to be cases where types will be known at compile time and it will be optimal to compile out the method-decoding and class-specialization: CLOS doesn't seem to address this. MS From Gregor.pa@Xerox.COM Wed Nov 16 19:12:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22328; Wed, 16 Nov 88 11:15:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 NOV 88 11:09:44 PST Date: Wed, 16 Nov 88 11:04 PST From: Gregor.pa@Xerox.COM Subject: Re: PCL 70 times slower than Ernie with 1000 cars. To: burdorf%taos@rand.org Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811152147.AA11437@taos.arpa> Message-Id: <19881116190402.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Please don't send anymore of these message until you are ready to show us the source code in ERNIE. There is no basis in fact to believe that you are comparing apples to apples. Other people on the list have pointed to irregularities in your measurements, but none of us can conclude anything without knowing exactly what the comparison is. Statements like "my friend Bill compared the two programs and said they were the same" just don't cut it. This is a (basically) scientific community. If you are going to make performance claims or discuss measurements you have to show exactly what you measured and how you measured it. That is what makes it possible for others to respond to your claims directly. It is also what makes it possible for us as implementors to know how to improve the performance of our systems. If it becomes possible for you to make the code available, and you decide to present your performance numbers again, you might consider checking your results with other individuals before sending them to such a large list. It is often a good idea to subject provacative claims to some sort of external peer review before presenting them to a large audience. ------- From Owners-commonloops.pa@Xerox.COM Wed Nov 16 19:31:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26771; Wed, 16 Nov 88 18:43:07 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 NOV 88 18:35:30 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 16 NOV 88 18:32:25 PST To: commonloops.pa@Xerox.COM Subject: RE: PCL isn't so bad after all (even at washing cars!) Date: Wed, 16 Nov 88 21:27:09 -0500 From: Mike Thome Message-Id: <881116-183530-1286@Xerox> Since everyone seemed to have been thrown into convulsions at the thought of PCL being so mind-bogglingly bad, I thought I'd look into the problem. First (to keep everyone reading) here are my results w/1000 cars: Machine: Symbolics 3650 (best of 4 trials - 'cept for the original :-) ---code--- ---total time (page&gc time)--- original clos port: 61.65 min (13.33 min) below (modified): 28.25 sec (1.6 sec) <- ~130 times speedup no methods in the clos-simulation part (only the carwash part): 27.65 sec (1.7 sec) Now that we're all awake, here's what I did: (1) cut out much needless consing. (2) cut out most refs to global vars. (3) turned EVALs into APPLYs. (4) turned a few complex-recursive functions into iterative ones. (5) reorganized style/syntax (mostly for my own sake) In doing the obove, I assumed that what the original benchmark was intended to measure was the carwash itself, as opposed to the simulator (which, frankly, directly translated would not have run efficiently in any language I know of). So I felt no restrictions on rewriting much of the simulator functions to be more efficient without changing the functionality. The second (slightly faster) modified time above is for the simulation with all generic functions that have only 1 method turned into regular functions (Chris mentioned that in Ernie, one can add declarations inside methods to achieve this effect - you lose the some of the error catching capability, but it may be faster). I'm still not really convinced that the carwash is the right benchmark (especially after all this!), mostly because the difference between implementing all gfns with one method as functions made such a small difference. Finally, I gather that Ernie is quite a different language from lisp, and I'm not at all convinced that we're not comparing apples and monkey wrenches. Anyway - below is the source for my version of the benchmark... still could use tuning, but at least we're much better off than we were. -mik ;------------------------------------------------ ;;; -*- Package: PCL; Syntax: Common-Lisp -*- ;;; clos-simulator.lsp ;;; ;;; Author: Chris Burdorf ;;; Taken from Dave McArthur's Bert simulator. ;;; Modified by Mike Thome (mthome@bbn.com) 16 Nov '88 ;;; (I *KNEW* that pcl couldn't be THAT bad!) ;;; ;;; Here are the two files. To run the system: ;;; 1. load clos-simulator first ;;; 2. after loading the carwash, do (generate-cars num) where num ;;; is the number of automobiles in the simulation. I used 20 for my tests. ;;; 3. Then type (get-going). That should do it. (defclass bert nil nil) (defclass simulator (bert) ((things-to-do :accessor things-to-do :initform nil) ; elem = (time . (func . args)) (history :accessor history :initform nil) (db :accessor db :initform nil))) (defclass clock (bert) ((current-time :accessor current-time :initform 0) (actors-running :accessor actors-running :initform nil) ; elem = (time . simulator) (ticksize :accessor ticksize :initform 1))) (defvar *clock* (make-instance 'clock)) ;;;Insert an action into an object's agenda after time n. (defmethod do-after ((obj simulator) n action) (let ((l (things-to-do obj)) (ti (+ (current-time *clock*) n))) (when (or (not l) (< ti (caar l))) (setf (actors-running *clock*) (inserttm (cons ti obj) (actors-running *clock*)))) (setf (things-to-do obj) (inserttm (cons ti action) (things-to-do obj))))) (defvar *clocktrace nil) (defmethod tick ((cl clock)) "Cycle through all the actors and execute methods to be done at this time." (let ((newtime (+ (current-time cl) (ticksize cl)))) (do* ((events (actors-running cl) (actors-running cl))) ((or (null events) (> (caar events) newtime))) (setf (current-time cl) (caar events)) (do ((ev events (cdr ev))) ((or (null ev) (/= (current-time cl) (caar ev)))) (pop (actors-running cl)) ;;(when *clocktrace (format t "\/\/") (format t (cdar events))) (atick (cdar ev) cl))) (setf (current-time cl) newtime))) (defmethod atick ((obj bert) cl) "Execute messages to be done at this time." (let ((ttd nil)) (loop (when (or (null (setq ttd (car (things-to-do obj)))) (< (current-time cl) (car ttd))) (return)) (apply (cadr ttd) (cddr ttd)) (pop (things-to-do obj))) (when ttd (setf (actors-running cl) (mergetm (cons (car ttd) obj) (actors-running cl)))))) ;;;;;;;;;;;; ;;;run the simulation until there are no more actors running. (defmethod run ((cl clock)) (loop (if (actors-running cl) (tick cl) (return)))) (defmethod tick-times ((cl clock) n) (dotimes (j (1- n)) (tick cl))) ;; inserttm inserts events or plans into a list of same to maintain ;; a minimum first ordering of elements. a plan or event element ;; is a cons of a time (integer) followed by action or actor (defun inserttm (itm l) (let ((itm-time (car itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (<= itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons)))))))) #+ignore ; this one works as advertised (defun mergetm (itm l) (let ((itm-time (car itm)) (itm-rest (cdr itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (< itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons))) (when (and (= itm-time (caar this-cons)) (equal itm-rest (cdar this-cons))) (return l))))))) ;;; this is a direct translation from the original... and is not likely to work. ;;; However, changing to the above (working) code slows things down a little - ;;; probably because of the expense of doing lots of EQUALs. Note that things would ;;; be even faster if inserttm were used instead of mergetm. ;; mergetm inserts as above but only if itm is not already in l (defun mergetm (itm l) (let ((itm-time (car itm))) (cond ((null l) (list itm)) (t (do* ((prev-cons nil this-cons) (this-cons l (cdr this-cons))) ((or (null this-cons) (< itm-time (caar this-cons))) (if prev-cons (progn (rplacd prev-cons (cons itm this-cons)) l) (cons itm this-cons))) (when (eql itm (car this-cons)) (return l))))))) ;;;------------------------------------------------------------------------ ;;; -*- Package: PCL; Syntax: Common-Lisp -*- ;;; CLASS STRUCTURE & ATTRIBUTES ;;; load clos-simulator.lisp first ;;; File: Carwash.lsp ;; carwash simulation ; time warp version using twbert and functional access of variables. ; author: Chris Burdorf ; date: 7-87 ;; Classes (defclass delayer (simulator) ((twxwindow :accessor twxwindow :initform nil) (twxautopix :accessor twautopix :initform nil) (twautofont :accessor twautofont :initform nil) (IQ :accessor IQ :initform nil) (car-x-pos :accessor car-x-pos :initform nil) (car-y-pos :accessor car-y-pos :initform nil) (queue-x-pos :accessor queue-x-pos :initform nil) (queue-y-pos :accessor queue-y-pos :initform nil) (in-use :accessor in-use :initform nil) (delay-factor :accessor delay-factor :initform nil))) (defclass vacuumer (delayer) ((illegal-alien :accessor illegal-alien :initform nil) (ashtray-contents :accessor ashtray-contents :initform nil) (carwash1-iq :accessor carwash1-iq :initform nil) (carwash2-iq :accessor carwash2-iq :initform nil) (carwash1-delay :accessor carwash1-delay :initform nil) (carwash2-delay :accessor carwash2-delay :initform nil))) (defclass waxer (delayer) nil) (defclass carwash (delayer) nil) (defclass autos (simulator) ((ashtray-contents :accessor ashtray-contents :initform nil))) (defvar autoinstances nil) ;Instances% (defvar vacuumer1 (make-instance 'vacuumer :delay-factor 3 :illegal-alien t :carwash1-delay 12 :carwash2-delay 2 :queue-x-pos 10 :queue-y-pos 100 :car-x-pos 50 :car-y-pos 175)) (defvar waxer1 (make-instance 'waxer :delay-factor 8 :queue-x-pos 400 :queue-y-pos 120 :car-x-pos 430 :car-y-pos 175)) (defvar carwash1 (make-instance 'carwash :delay-factor 12 :queue-x-pos 100 :queue-y-pos 10 :car-x-pos 200 :car-y-pos 80)) (defvar carwash2 (make-instance 'carwash :delay-factor 2 :queue-x-pos 100 :queue-y-pos 280 :car-x-pos 200 :car-y-pos 205)) ;methods; (defmethod add-to-queue ((obj delayer) (auto autos)) "add a new entry to an object's input queue." ;;(format t "Adding ~a to ~a's input queue.~%" auto obj) (setf (iq obj) (nconc (iq obj) (list auto)))) (defmethod next-iq-entry ((obj delayer)) "process the next iq entry off of a queue." (when (iq obj) ;;(format t "~a on auto ~a~%" obj (car (iq obj))) (do-after obj 0.1 `(write-icon ,obj)) (do-after obj 0.2 `(finish ,obj ,(car (iq obj)))) (setf (in-use obj) t (iq obj) (cdr (iq obj))))) (defmethod not-in-use ((obj delayer)) "This function sets the delayer to not in use." (setf (in-use obj) nil)) (defmethod write-icon ((obj delayer)) "write the icon to expose or to erase from the screen." nil) (defmethod finish ((cwash carwash) auto) "pass the automobile off to the next position." ;;(format t "~a is leaving ~a~%" auto cwash) (let ((st (delay-factor cwash))) (do-after cwash st `(write-icon ,cwash)) (do-after waxer1 st `(add-to-queue ,waxer1 ,auto)) (do-after waxer1 (+ st 0.1) `(next-iq-entry ,waxer1)) (do-after cwash st `(not-in-use ,cwash)) (do-after cwash st `(next-iq-entry ,cwash)))) (defmethod leaving-vacuum ((vac vacuumer) (auto autos)) "This method causes the car to leave the vacuumer." ;;(format t "~a leaving vacuum ~a.~%" auto vac) ) (defmethod stopped-stealing ((vax vacuumer) (auto autos)) "indicate to graphics that you are no longer stealing money." ;;(format t "~a stopped stealing money from ~a~%" vax auto) ) (defmethod finish ((vac vacuumer) (auto autos)) ;preschedule getting the carwash queues. (let* ((vacst (delay-factor vac)) (queue1 (iq carwash1)) (queue2 (iq carwash2)) (empty-carwash (cond ((in-use carwash1) carwash2) ((in-use carwash2) carwash1) ((> (length queue1) (length queue2)) carwash2) (t carwash1))) (delay nil) (st (delay-factor empty-carwash))) (when (and (eq (ashtray-contents auto) 'money)(illegal-alien vac)) ;;(format t "~a is stealing money from ~a~%" vac auto) (do-after vac 0.5 `(stopped-stealing ,vac ,auto))) (setq delay (+ st (find-times (if (eq empty-carwash carwash1) queue1 queue2)))) (do-after empty-carwash vacst `(add-to-queue ,empty-carwash ,auto)) (do-after empty-carwash delay `(next-iq-entry ,empty-carwash)) (do-after vac vacst `(leaving-vacuum ,vac ,auto)) (do-after vac vacst `(next-iq-entry ,vac)) (do-after vac vacst `(write-icon ,vac)))) (defun find-times (x) (if x (length x) 1)) (defmethod finish ((wax waxer) auto) ;;(format t "~a is leaving ~a~%" auto wax) (let ((st (delay-factor wax))) (do-after wax st `(write-icon ,wax)) (do-after wax st `(next-iq-entry ,wax)))) (defun get-going () (setf (iq vacuumer1) nil (things-to-do vacuumer1) nil (things-to-do waxer1) nil (iq waxer1) nil (things-to-do carwash1) nil (iq carwash1) nil (things-to-do carwash2) nil (iq carwash2) nil (actors-running *clock*) nil) (dolist (auto autoinstances) (add-to-queue vacuumer1 auto)) (next-iq-entry vacuumer1) (run *clock*)) ;------------------------graphics initialization --------------------- (defun init-graphics () nil) (defun generate-cars (n) (let ((collection nil)) (dotimes (i n) (push (make-instance 'autos :ashtray-contents (case (rem i 3) (0 'ashes) (1 'gum) (2 'money))) collection)) (setq autoinstances collection)) 'done) From Gregor.pa@Xerox.COM Wed Nov 16 19:33:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27825; Wed, 16 Nov 88 19:33:41 PST Received: from Semillon.ms by ArpaGateway.ms ; 16 NOV 88 19:31:20 PST Date: Wed, 16 Nov 88 19:28 PST From: Gregor.pa@Xerox.COM Subject: Re: moderating clos mailing list To: Michael Sokolov Cc: brian@vuse.vanderbilt.edu, commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811170252.AA09936@whitechapel> Message-Id: <19881117032827.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 16 Nov 88 21:52:12 EST From: Michael Sokolov I agree that most of the discussion on ERNIE vs. PCL has been unsubstantiated name-calling, but it does raise an interesting issue: namely, the issue of type declarations. There are obviously going to be cases where types will be known at compile time and it will be optimal to compile out the method-decoding and class-specialization: CLOS doesn't seem to address this. Actually, CLOS does address this in two distinct and important ways. 1) Under certain compiler optimizations, I think you can expect a CLOS implementation to optimize out method lookup in code like the following. (defclass foo () ()) (defclass bar () ()) (defmethod doit ((f foo)) ...) (defmethod doit ((b bar)) ...) .. (progn (dolist (f *the-foos*) (doit (the foo f))) (dolist (b *the-bars*) (doit (the bar b)))) .. I think you can also expect code like this to optimize out the method lookup for calls to the generic function inner. (defmethod outer ((f foo)) .. (inner f) ..) (defmethod outer ((b bar)) .. (inner b) ..) (defmethod inner ((f foo)) ..) (defmethod inner ((b bar)) ..) 2) Using the metaobject protocol, you can do certain optimizations by hand. For example, Mike Thome mentioned in his message that he replaced all the one method generic functions with ordinary functions. When he did this, he was assuming the code had no bugs so that whenever that generic function was called, its only method was appropriate. Here is PCL code that does that by direct manipulation of the metaobjects. It has the advantage that you can switch the optimization on and off for already loaded code. To use it you first call gather-generic-functions to collect up the generic functions that are in your package. Then make-generic-functions-unsafe converts them to use this optimization. make-generic-functions-safe converts them back. (in-package 'pcl) (defclass unsafe-gf (standard-generic-function) () (:metaclass funcallable-standard-class)) (defmethod compute-discriminator-code ((gf unsafe-gf)) (let ((methods (generic-function-methods gf))) (if (and methods (null (cdr methods)) (null (every #'(lambda (m) (or (standard-reader-method-p m) (standard-writer-method-p m))) methods))) (method-function (car methods)) (call-next-method)))) (defvar *generic-functions* ()) (defun gather-generic-functions (package) (do-symbols (symbol package) (let ((fn nil)) (when (and (fboundp symbol) (setq fn (symbol-function symbol)) (pcl::generic-function-p fn)) (pushnew fn *generic-functions*))))) (defun make-generic-functions-unsafe () (let ((unsafe-class (find-class 'unsafe-gf))) (dolist (gf *generic-functions*) (change-class gf unsafe-class) (update-discriminator-code gf)))) (defun make-generic-functions-safe () (let ((safe-class (find-class 'standard-generic-function))) (dolist (gf *generic-functions*) (change-class gf safe-class) (update-discriminator-code gf)))) ------- From Owners-commonloops.pa@Xerox.COM Wed Nov 16 22:30:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01696; Wed, 16 Nov 88 21:59:20 PST Received: from Riesling.ms by ArpaGateway.ms ; 16 NOV 88 21:57:27 PST Return-Path: Redistributed: commonloops.pa Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 16 NOV 88 21:56:12 PST Received: from taos.rand.org by rand.org; Wed, 16 Nov 88 21:23:46 PST Received: from localhost by taos.arpa; Wed, 16 Nov 88 21:19:48 PST Message-Id: <8811170519.AA00628@taos.arpa> To: Mike Thome Cc: commonloops.pa@Xerox.COM, burdorf%taos@rand.org Subject: Re: PCL isn't so bad after all (even at washing cars!) In-Reply-To: Your message of Wed, 16 Nov 88 21:27:09 EST. <881116-183530-1286@Xerox> Date: Wed, 16 Nov 88 21:19:46 PST From: burdorf%taos@rand.org Thanks Mike, I agree that the version I had was flawed. Sorry about that everybody. Chris From Owners-commonloops.pa@Xerox.COM Thu Nov 17 15:47:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11292; Thu, 17 Nov 88 15:47:58 PST Received: from Burger.ms by ArpaGateway.ms ; 17 NOV 88 15:45:44 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 17 NOV 88 13:59:33 PST Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA19536; Thu, 17 Nov 88 08:34:44 PST Received: from suntana.sun.com by snail.Sun.COM (4.0/SMI-4.0) id AA05110; Thu, 17 Nov 88 08:37:37 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA01853; Thu, 17 Nov 88 08:38:03 PST Message-Id: <8811171638.AA01853@suntana.sun.com> To: CommonLoops.pa@Xerox.COM, burdorf%taos@rand.org Subject: Re: PCL 70 times slower than Ernie with 1000 cars. In-Reply-To: Your message of Wed, 16 Nov 88 08:43:00 -0600. <19881116144313.1.BALLOU@LILITH.ACA.MCC.COM> Date: Thu, 17 Nov 88 08:37:59 PST From: kempf@Sun.COM As has been mentioned, this "benchmark" is not particularly enlightening. PCL runs faster than CommonObjects, some workstation implementations of Flavors, and the Strobe KR language. In the case of Strobe, between 1 and 2 orders of magnitude speedup were obtained by rewriting it on top of the metaobject protocol. For the CommonObjects numbers, see my paper in the 87 OOPSLA Proceedings. For Flavors, measure it in your favorite vendor's implementation. But please stop comparing it to a system which is not widely available, and won't ever be, from the looks of it. The point about declarations is valid, however. There should be some way of declaring that the parameters to a particular generic function invocation are limited to a particular set of classes, though a sufficiently smart compiler (when, oh when will one appear?) can infer this information to a degree. jak From Owners-commonloops.pa@Xerox.COM Fri Nov 18 08:16:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20116; Fri, 18 Nov 88 08:16:33 PST Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 88 08:15:00 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 18 NOV 88 08:13:19 PST To: commonloops.pa@Xerox.COM Subject: What would a good PCL benchmark make? Date: Fri, 18 Nov 88 11:03:02 -0500 From: Mike Thome Message-Id: <881118-081500-4082@Xerox> Now that we're done washing cars... Which features of PCL/CLOS particularly stress the various PCL implementations? Do we want to measure the best-case dispatch speed only, or should we worry about forcing cache misses in our bechmarks? SLOT-VALUE? Accessors? with-slots? I've been using a small program which started its life as an N-body program - since then its had it's math ripped out and a number of body classes with odd behaviors added. It does no consing once it gets started, very little math, and lots of method calls (with 1 or 2 dispatching args). What can I do to make it as slow as possible by beating on pcl? -mik From Owners-commonloops.pa@Xerox.COM Fri Nov 18 10:26:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21910; Fri, 18 Nov 88 10:26:42 PST Received: from Salvador.ms by ArpaGateway.ms ; 18 NOV 88 10:21:45 PST Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 18 NOV 88 10:19:16 PST Received: by paris.Berkeley.EDU (5.57/1.25) id AA01065; Fri, 18 Nov 88 10:17:45 PST From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8811181817.AA01065@paris.Berkeley.EDU> To: Mike Thome Cc: commonloops.pa@Xerox.COM Subject: Re: What would a good PCL benchmark make? In-Reply-To: Your message of Fri, 18 Nov 88 11:03:02 EST. <881118-081500-4082@Xerox> Reply-To: larus@ginger.Berkeley.EDU Date: Fri, 18 Nov 88 10:17:39 PST In my experience, small benchmarks are not particularly useful for predicting PCL's behavior on real programs. PCL makes heavy use of caches and small programs don't fill the caches or cause collisions in the hash tables. Large programs, with hundreds of methods and classes, expose a lot of weak points in the PCL implementation. If anyone is interested, I can send them detailed timings of one such large program, which show that PCL's cost is around 75% of the total execution time. /Jim From Owners-CommonLoops.pa@Xerox.COM Mon Nov 21 08:36:00 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24572; Mon, 21 Nov 88 08:36:00 PST Received: from Cabernet.ms by ArpaGateway.ms ; 21 NOV 88 07:53:24 PST Return-Path: Redistributed: CommonLoops.pa Received: from mcnc.mcnc.org ([128.109.131.1]) by Xerox.COM ; 21 NOV 88 07:51:52 PST Received: from mercury.cs.unc.edu by mcnc.mcnc.org (5.59/MCNC/5-16-88) id AA09237; Mon, 21 Nov 88 10:51:28 EST Received: from dopey.cs.unc.edu by mercury.cs.unc.edu (5.54/UNC/6-17-88) id AA00236; Mon, 21 Nov 88 10:51:13 Received: by dopey.cs.unc.edu (5.54/UNC/06-13-88) id AA07522; Mon, 21 Nov 88 10:51:06 Date: Mon, 21 Nov 88 10:51:06 From: William Clagett Message-Id: <8811211551.AA07522@dopey.cs.unc.edu> To: CommonLoops.pa@Xerox.COM Subject: PCL on Symbolics machines Has anybody run any timing tests on Symbolics machines for Flavors vs. PCL? I realize this isn't really comparing apples and apples, but we have a large system, running under flavors on Symbolics machines, that we would like to convert to PCL. We have intentionally avoided using anything that would be difficult to port (we've even avoided :before and :after daemons because they weren't implemented in PCL when we started). We want to be able to use some of the nicer features of PCL, but are afraid that the performance hit may not be worth it. Any input would be appreciated. Bruce Clagett clagett@cs.unc.edu From Owners-CommonLoops.pa@Xerox.COM Tue Nov 22 22:30:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20831; Tue, 22 Nov 88 22:30:02 PST Received: from Riesling.ms by ArpaGateway.ms ; 22 NOV 88 19:34:12 PST Return-Path: Redistributed: CommonLoops.pa Received: from gort.cs.Buffalo.EDU ([128.205.32.1]) by Xerox.COM ; 22 NOV 88 19:31:41 PST Received: from sybil.cs.Buffalo.EDU by gort.cs.Buffalo.EDU (5.59/1.1) id AA07856; Mon, 21 Nov 88 14:32:03 EST Received: by sybil.cs.Buffalo.EDU (4.12/1.1) id AA05734; Mon, 21 Nov 88 14:31:25 est Date: Mon, 21 Nov 88 14:31:25 est From: bettingr@cs.Buffalo.EDU (Keith E. Bettinger) Message-Id: <8811211931.AA05734@sybil.cs.Buffalo.EDU> To: CommonLoops.pa@Xerox.COM Subject: Problems getting PCL up under KCl/IBCL... I have been having trouble getting PCL up under KCl/IBCL, and am hoping that I can get some help. The files compile all right, but when I load the file "test.lisp" into it, one test fails and one test bombs upon loading. Below is a script demonstrating this behavior. Note that I have left in the script several nagging bugs that I could get around. I would appreciate any assistance. Thank you much. Keith ----- Script started on Mon Nov 21 13:14:03 1988 gort pcl 51 >kcl KCl (Kyoto Common Lisp) June 3, 1987 >(load "defsys") Loading defsys.lsp Finished loading defsys.lsp T >(pcl::load-pcl) Loading binary of KCL-PATCHES... Warning: DEFMACRO is being redefined. Loading binary of PKG... Error: The variable *EXPORTS* is unbound. Error signalled by LOAD. Broken at LOAD. Type :H for Help. PCL>>:q Top level. >(load "pkg.lsp") Loading pkg.lsp Finished loading pkg.lsp T >(pcl::load-pcl) Loading binary of KCL-PATCHES... Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of KCL-LOW... Loading binary of FIN... Loading binary of DEFS... Loading binary of BOOT... Loading binary of VECTOR... Loading binary of SLOTS... Loading binary of MKI... Loading binary of INIT... Loading binary of DEFCLASS... Loading binary of STD-CLASS... Loading binary of BRAID1... Loading binary of FSC... Loading binary of METHODS... Loading binary of COMBIN... Loading binary of DCODE... Loading binary of DCODE-PRE1... Loading binary of FIXUP... Loading binary of HIGH... Warning: DESCRIBE is being redefined. Loading binary of COMPAT... (:PORTABLE-COMMONLOOPS :PCL PCL::IBCL COMPILER::BUGGY-CC VAX UNIX BSD COMMON KCL) >(load "test") Loading test.lsp Error: No lambda expression is assigned to the symbol DO-TEST. Error signalled by COND. Broken at ERROR. Type :H for Help. PCL>>(load "test") Loading test.lsp The compiler was called recursively. Cannot compile DO-TEST. The compiler was called recursively. Cannot compile DO-TEST-ERROR. The compiler was called recursively. Cannot compile CLEANUP-DO-TEST. Testing types for early classes...OK Testing types for late classes...OK Testing built-in-class-of... class-of #C(1 2) was NUMBER not COMPLEX FAILED! Testing existence of generic-functions for accessors of early classes...OK Testing early reader/writer methods are appropriate class...OK Testing typep works for standard-classes...OK Testing accessors and readers should NOT be inherited...OK Testing :accessor and :reader methods go away...OK Testing :accessor-prefix methods go away...OK Testing constructors go away... The compiler was called recursively. Cannot compile NIL. The compiler was called recursively. Cannot compile NIL.OK Testing Simple with-accessors test -- does not really exercise the walker....OK Testing Simple with-slots test -- does not really exercise the walker....OK Testing with-slots inside of lexical closures...OK Testing redefinition of default method has proper effect...OK Testing call-next-method passes original arguments...OK Testing call-next-method closures pass original arguments - 1...OK Testing call-next-method closures pass original arguments - 2...OK Testing call-next-method passes supplied arguments...OK Testing call-next-method closures pass supplied arguments - 1...OK Testing call-next-method closures pass supplied arguments - 2...OK Testing call-next-method inside of default value form of &optional...OK Testing specifying :type when superclass doesn't...OK Testing Leaky next methods...OK Testing shared-initialize with T argument and no initargs...OK Testing shared-initialize with T argument and initargs...OK Testing initialization arguments rules test...OK Testing more tests for initialization arguments rules...OK Testing initialization protocols...OK Testing update-instance-for-different-class...OK Testing only needed forms should be evaluated in initializing instances...OK Testing update-instance-for-different-class/change-class...OK Testing update-instance-for-redefined-class/make-instance-obsolete... The compiler was called recursively. Cannot compile NIL. Error: The function NIL is undefined. Error signalled by POS-RHO. Backtrace: > evalhook > load > let > let > catch > block > unless > and > POS-RHO Broken at ERROR. PCL>>:q Top level. >(bye) Bye. gort pcl 52 >^Dexit script done on Mon Nov 21 13:33:59 1988 ------------------------------------------------------------------------- Keith E. Bettinger "Paradise SUNY at Buffalo Computer Science Is exactly like Where you are right now CSNET: bettingr@Buffalo.CSNET Only much much BITNET: bettingr@sunybcs.BITNET Better" - Laurie Anderson INTERNET: bettingr@cs.buffalo.edu UUCP: ..{bbncca,decvax,dual,rocksvax,watmath,sbcs}!sunybcs!bettingr ------------------------------------------------------------------------- From Owners-COMMONLOOPS.PA@Xerox.COM Fri Nov 25 01:02:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14350; Fri, 25 Nov 88 01:02:39 PST Received: from Salvador.ms by ArpaGateway.ms ; 25 NOV 88 00:43:36 PST Return-Path: <@CUNYVM.CUNY.EDU:MAILER@ICINECA2.BITNET> Redistributed: COMMONLOOPS.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 25 NOV 88 00:41:37 PST Received: from ICINECA2.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 7508; Fri, 25 Nov 88 03:39:10 EDT Date: Fri, 25 Nov 88 09:39 N From: Reply-To: Subject: pcl benchmarks To: COMMONLOOPS.PA@Xerox.COM X-Original-To: "COMMONLOOPS.PA@XEROX.COM" Message-Id: <881125-004336-14561@Xerox> Message-id: <6522> Date: FRI, 25-NOV-88 09:39 N From: Reply-To: (alternate reply) Comments: INFN.IT domain is equivalent to BITNET domain: INFNET; INFNET will be disestablished Dec 31, 1988 Subject: pcl benchmarks To: X-Original-To: @[.adrs]clos, BRAJNIK Distribution-File: commonloops.pa@xerox.com I would like to know whether there exists some standard benchmark for comparing different pcl implementations. If there is any I would like to have the sources and some results of it (possibly on Symbolics 3620, MacIvory, Explorer II and MicroExplorer). Thank you. Giorgio Brajnik Dipartimento di Matematica e Informatica Universita' di Udine Via Zanon, 6 I-33100 UDINE - ITALY ph: (432) 29.57.16 fax: (432) 29.08.82 email: BRAJNIK%UDUNIV.INFN.IT@ICINECA2.BITNET From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Nov 25 09:09:07 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15892; Fri, 25 Nov 88 09:09:07 PST Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88 09:06:24 PST Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa03986; 25 Nov 88 14:47 GMT Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT Date: Fri, 25 Nov 88 14:46:28 WET From: Flash Sheridan To: common-lisp-object-system Cc: common-lisp-object-system-specification-request Subject: specification request [plain text] Reply-To: sheridan@NSS.Cs.Ucl.AC.UK Message-Id: <8811251448.a025197@sequent.cs.qmc.ac.uk> I'd like to get an electronic copy of the CLOS spec [including the MetaClass chapter]. I'd also appreciate any other info. I'm running AAAI-88 PCL on Coral Common Lisp. From: flash@cs.qmc.ac.uk (Flash Sheridan) Reply-To: sheridan@nss.cs.ucl.ac.uk Portal,MacNet: FlashsMom From Gregor.pa@Xerox.COM Mon Nov 28 18:02:18 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29224; Mon, 28 Nov 88 18:02:18 PST Received: from Semillon.ms by ArpaGateway.ms ; 28 NOV 88 10:22:10 PST Date: Sat, 26 Nov 88 16:47 PST From: Gregor.pa@Xerox.COM Subject: Re: Problems getting PCL up under KCl/IBCL... To: Keith E. Bettinger Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8811211931.AA05734@sybil.cs.Buffalo.EDU> Message-Id: <19881127004753.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 21 Nov 88 14:31:25 est From: bettingr@cs.Buffalo.EDU (Keith E. Bettinger) I have been having trouble getting PCL up under KCl/IBCL, and am hoping that I can get some help. The files compile all right, but when I load the file "test.lisp" into it, one test fails and one test bombs upon loading. Ignore these problems with the test.lisp file. Your pcl is actually working pretty well. If you run into problems in your own code with "compiler cannot be called recursively" errors see the comments in one of the recent notes.text files for instructions on how to get around this. ------- From Owners-commonloops.pa@Xerox.COM Mon Nov 28 23:35:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04697; Mon, 28 Nov 88 23:19:16 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 NOV 88 13:05:47 PST Return-Path: <@RELAY.CS.NET:ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET> Redistributed: commonloops.pa Received: from RELAY.CS.NET ([10.4.0.5]) by Xerox.COM ; 28 NOV 88 11:04:04 PST Received: from relay2.cs.net by RELAY.CS.NET id aa02733; 28 Nov 88 1:21 EST Received: from utokyo-relay by RELAY.CS.NET id ad14016; 28 Nov 88 1:05 EST Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET) id AA15216; Mon, 28 Nov 88 14:18:07 JST Date: Mon, 28 Nov 88 13:23:12 JST From: Masayuki Ida Return-Path: Message-Id: <8811280423.AA07107@kepa.cc.aoyama.junet> To: commonloops.pa@Xerox.COM Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNet Subject: MSPS-game (Re: PCL benchmark) Two years ago, when I was interested in the measurement of PCL, I got an idea to try to have an index to measure the PCL performance. I wrote a code and tested with several implementations as a coffee break entertainment. I called it MSPS for 'Message Send Per Second'. The recent discussion of this mail box triggered me to remember MSPS-game of two years ago. Benchmarking always assumes a model and my model for MSPS was 25% classical method with two arguments, 25% muti-method, 50% default arguments. and 50% inherited access, 50% non-inherited access. This assumption is not 'scientific' but from my intuition at that time. If we can have more realistic model, we may have a common measure for generic function call overhead. Here is the source for it. Masayuki Ida Aoyama Gakuin Univ. Japan ----------------- cut here ---------------- ;;; -*- Syntax: Common-Lisp; Package: USER; Base: 10; Mode: LISP -*- ;;; ;;; a simple test program 'yattegoran' for PCL/CLOS ;;; this program gives us a measure for generic function call performace ;;; in MSPS (Message Send Per Second) ;;; ;;; 1986.12.10 Masayuki Ida, Aoyama Gakuin University ;;; 1988.11.25 Masayuki Ida updated to comform CLOS ;;; ;;; ;;; Features tested here are ;;; Single inheritance, discrimination with multiple arguments, ;;; Instance creation, built-in class handling ;;; ;;; several data ;;; PCL on KCL (Ultrix 8600) in 1986. interpreted!!! ;;; with CommonLoops real 24.417 sec CPU 4.783 sec ;;; without message send real 0.250 sec CPU 0.100 sec ;;; - )____________________________________________ ;;; - 4.683 sec for 200 message send ;;; ===> 200/4.683 = 42.7 Message Send Per Second. ;;; ---- ;;; PCL on Allegro CL (SUN-4 260) in 1988. compiled!!! ;;; with PCL CPU (total user time) 250 msec real time: 440 msec ;;; without PCL CPU (total user time) 0 msec real time: 0 msec ;;; -)______________________________________ ;;; 250 msec for 200 message send ;;; ===> 200/0.250 = 800.0 Message Send Per Second. ;;; ----- (interpreted version is 632 MSPS) ;;; ;;; The above data DOES NOT show the performance comparison of different CL implementation, ;;; since 1)machines used are quite different, ;;; 2)the source codes are slightly different(86 version uses ndefstruct and defmeth...) ;;; 3)Allegro version is compiled and mesured, but not for KCL-case, ;;; 4)there are two year time difference to progress. ;;; ( Rather it shows the advances of PCL implementation techniques in some extent.) ;;; --------------- The Model ---------------------------- ;;; This value reflects the following assumption: ;;; 1) 25% classical method with two arguments, 50% with default arguments ;;; 2) 25% multi-method ;;; 3) 50% non inherited access, 50% inherited access ;;; ------------------------------------------------------- (defvar *x*) (defclass foo () (x)) (defclass bar (foo)()) (defmethod yattegoran ((x foo) (y number)) (if (= y 0) 1 (yattegoran (setq *x* (make-instance 'bar)) (yattegoran y nil)))) (defmethod yattegoran ((x bar) y) (if (= y 0) 1 (yattegoran (setq *x* (make-instance 'foo)) (yattegoran y nil)))) (defmethod yattegoran (x y) (1- x)) (time (yattegoran (make-instance 'foo) 100)) ; ====> (1) (defun yatte1 (x y) (if (= y 0) 1 (yatte2 x (yatte3 y nil)))) (defun yatte2 (x y) (if (= y 0) 1 (yatte1 x (yatte3 y nil)))) (defun yatte3 (x y) (1- x)) (time (yatte1 nil 100)) ; ====> (2) ;; get the difference of the CPU times in (1) and (2). (for compiled codes, (2) is negligible) ;; divide 200 by it. (CAUTION: exactly speaking, yattegoran-foo-number is called 51 times, ;; yattegoran-bar-t called 50 times,yattegoran-t-t called 100 times. so the sum itself is 201) ;; ;; PCL(St.Patrick day version) on Allegro CL 3.0.1 on SUN-4 '88 Fall has 800MSPS ;; which TRY to mean the implementation can do 800 generic function calls per second. ;; Comment: the reason why I inserted meaningless setq to *x* is to provide a chance ;; to measure slot access things in the future. If method-dispatching is the ;; only target to measure, dropping setqs gives slightly better value. ;; The possible target: MSPS value should be more closer to usual function call. ;; Say, 10K MSPS with FULL function CLOS is possible ? From hdavis.pa@Xerox.COM Tue Nov 29 00:03:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05654; Tue, 29 Nov 88 00:03:48 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 NOV 88 19:04:33 PST Date: 28 Nov 88 19:02 PST From: hdavis.pa@Xerox.COM Subject: Re: MSPS-game (Re: PCL benchmark) In-Reply-To: Masayuki Ida 's message of Mon, 28 Nov 88 13:23:12 JST To: Masayuki Ida Cc: commonloops.pa@Xerox.COM Message-Id: <881128-190433-4098@Xerox> I don't think Ida's code is quite fair to pcl, or lives up to its promises. Despite his claim that the pcl half is "25% classical method with two argument, 50% with default arguments, 25% multi-method", actually, the multi-method discriminator code has to be called at every generic function call. Thus, this may be a fair test of multi-methods, but pcl optimizes for the common case of single-argument method discrimination. In addition, the code does a make-instance with every generic function call but not for the regular function calls, mixing in this expensive operation with the generic function call. We should sort these cases out. Finally, it is not clear how inheritance is being tested in the code. Just to test multi-methods vs. discrimination on a single argument vs. regular function call (although that's not really fair), I ran the following simple code in Xerox CommonLisp: (in-package "BERK" :use '("LISP" "PCL")) (defclass foo () ()) (defvar *foo* (make-instance 'foo)) (defclass bar () ()) (defvar *bar* (make-instance 'bar)) (defmethod call-me ((x foo) y) (if (zerop y) nil (call-me *bar* (1- y)))) (defmethod call-me ((x bar) y) (if (zerop y) nil (call-me *foo* (1- y)))) (defmethod mm-call-me ((x1 foo) (x2 bar) y) (if (zerop y) nil (mm-call-me *bar* *foo* (1- y)))) (defmethod mm-call-me ((x1 bar) (x2 foo) y) (if (zerop y) nil (mm-call-me *foo* *bar* (1- y)))) (defun call-me-foo (x y) (if (zerop y) nil (call-me-bar *bar* (1- y)))) (defun call-me-bar (x y) (if (zerop y) nil (call-me-foo *foo* (1- y)))) Results were: (time (call-me *bar* 500)) ==> 42 ms (time (mm-call-me *bar* *foo* 500) ==> first: 129 ms others: 61 ms (time (call-me-foo *foo* 500)) ==> 20 ms and, for good measure, (time (make-instance 'foo) :repeat 500) ==> 1602 ms (time (pcl::*make-instance 'foo) :repeat 500)=> 3960 ms make-instance creates 2 lists, 1 oned-array, and 1 instance per call. *make-instances creates 12 lists, 1 oned-array, and 1 instance per call. So I think it's fair to say that Ida's numbers largely reflect the time for make-instance, and not really the overhead for generic function calls. I must say I was pleasantly surprised to find that generic function calls only take 2-3 times a regular function call in XCL. Is this true in other Lisps as well? How about tests for slot accessors? -- Harley PS My *pcl-system-date* is "9/21/88 (beta) Pre-Workshop PCL" From hdavis.pa@Xerox.COM Tue Nov 29 00:08:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05704; Tue, 29 Nov 88 00:08:28 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 NOV 88 19:18:08 PST Date: 28 Nov 88 19:16 PST From: hdavis.pa@Xerox.COM Subject: Re: MSPS-game (Re: PCL benchmark) In-Reply-To: Masayuki Ida 's message of Mon, 28 Nov 88 13:23:12 JST To: Masayuki Ida Cc: commonloops.pa@Xerox.COM Message-Id: <881128-191808-4120@Xerox> Actually, when I tested the following, even simpler, code, I got even better results: (defmethod do-nothing ((x foo)) nil) (defmethod do-nothing ((x bar)) nil) (defmethod mm-do-nothing ((x bar) (y foo)) nil) (defmethod mm-do-nothing ((x foo) (y bar)) nil) (defun do-nothing-foo (x) nil) Results: (time (do-nothing *foo*) :repeat 500) ==> 176 ms (time (mm-do-nothing *foo* *bar*) :repeat 500) ==> 224 ms (time (do-nothing-foo *foo*) :repeat 500) ==> 149 ms -- Harley From Owners-CommonLoops.pa@Xerox.COM Fri Dec 2 02:20:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17899; Fri, 2 Dec 88 02:20:01 PST Received: from Riesling.ms by ArpaGateway.ms ; 30 NOV 88 13:36:31 PST Return-Path: Redistributed: CommonLoops.pa Received: from gort.cs.Buffalo.EDU ([128.205.32.1]) by Xerox.COM ; 30 NOV 88 13:31:24 PST Received: from sybil.cs.Buffalo.EDU by gort.cs.Buffalo.EDU (5.59/1.1) id AA09205; Tue, 29 Nov 88 12:45:42 EST Received: by sybil.cs.Buffalo.EDU (4.12/1.1) id AA21725; Tue, 29 Nov 88 12:44:51 est Date: Tue, 29 Nov 88 12:44:51 est From: bettingr@cs.Buffalo.EDU (Keith E. Bettinger) Message-Id: <8811291744.AA21725@sybil.cs.Buffalo.EDU> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Sat, 26 Nov 88 16:47 PST <19881127004753.5.GREGOR@PORTNOY.parc.xerox.com> Subject: Problems getting PCL up under KCl/IBCL... Date: Sat, 26 Nov 88 16:47 PST From: Gregor.pa@Xerox.COM Date: Mon, 21 Nov 88 14:31:25 est From: bettingr@cs.Buffalo.EDU (Keith E. Bettinger) I have been having trouble getting PCL up under KCl/IBCL, and am hoping that I can get some help. The files compile all right, but when I load the file "test.lisp" into it, one test fails and one test bombs upon loading. Ignore these problems with the test.lisp file. Your pcl is actually working pretty well. [ ... ] ^^^^^^^^^^^ ------- ``Pretty well'' is not very reassuring. What is the difference between ``running'' and ``running pretty well''?! I can understand ignoring the fact that test.lisp bombs. But do you really think I should ignore the fact that the "built-in-class-of" test failed outright? Can you be more specific please? Thank you. ------------------------------------------------------------------------- Keith E. Bettinger "Paradise SUNY at Buffalo Computer Science Is exactly like Where you are right now CSNET: bettingr@Buffalo.CSNET Only much much BITNET: bettingr@sunybcs.BITNET Better" - Laurie Anderson INTERNET: bettingr@cs.buffalo.edu UUCP: ..{bbncca,decvax,dual,rocksvax,watmath,sbcs}!sunybcs!bettingr ------------------------------------------------------------------------- From Owners-commonloops.pa@Xerox.COM Fri Dec 2 08:28:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19682; Fri, 2 Dec 88 08:28:05 PST Received: from Salvador.ms by ArpaGateway.ms ; 29 NOV 88 17:25:53 PST Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 29 NOV 88 16:53:50 PST Received: from hpljl.HPL.HP.COM (hpljl.hpl.hp.com) by hplms2.hp.com; Tue, 29 Nov 88 16:53:46 pst Received: by hpljl.HPL.HP.COM; Tue, 29 Nov 88 16:52:59 pst Date: Tue, 29 Nov 88 16:52:59 pst From: Joachim Laubsch Message-Id: <8811300052.AA11804@hpljl.HPL.HP.COM> To: commonloops.pa@Xerox.COM Subject: type-of under Lucid for HP-UX 6.2 The implementation of CLOS that I use gives: (type-of ) ==> PCL::IWMC-CLASS rather than the type of the instance. Does anybody have a fix, or am I using an old version? -*- Joachim (laubsch@hplabs.hp.com). From Owners-commonloops.pa@Xerox.COM Fri Dec 2 08:32:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19697; Fri, 2 Dec 88 08:32:28 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 30 NOV 88 11:22:33 PST Return-Path: Redistributed: commonloops.pa Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 30 NOV 88 11:08:07 PST Received: from victoria.media.mit.edu by media-lab.media.mit.edu (5.59/4.8) id AA01522; Wed, 30 Nov 88 14:07:35 EST Received: by victoria (3.2/4.8) id AA18604; Wed, 30 Nov 88 14:05:46 EST Date: Wed, 30 Nov 88 14:05:46 EST From: Michael Sokolov Message-Id: <8811301905.AA18604@victoria> To: commonloops.pa@Xerox.COM Subject: method ordering Here's a question for all you PCL wizards. Suppose I define four classes as follows: (defclass foo0 () nil) (defclass foo1 (foo0) nil) (defclass bar0 nil nil) (defclass bar1 (bar0) nil) And then define methods "test" on all possible two-way combinations: (defmethod test ((f foo1) (b bar1)) (print "1 1") (call-next-method)) i.e. (test foo0 bar0) (test foo0 bar1) (test foo1 bar0), and (test foo1 bar1). My first question is how does PCL decide in what order the methods are to be invoked? Does method (test foo0 bar1) come before or after (test bar0 foo1)? Is it the order of creation of the methods. This was my best guess. And my next question is how can this be affected within the methods? I.e. is it possible to write a method on the most specific classes (foo1 and bar1) which explicitly calls a method defined on, say, foo0 and bar0, skipping the in-between methods. Answers would be greatly appreciated. I'm sure this is in the manual somewhere, but I thought this would be a question of general interest, so I mailed it to the list. MS From Owners-CommonLoops.pa@Xerox.COM Fri Dec 2 15:10:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00379; Fri, 2 Dec 88 15:10:14 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 01 DEC 88 14:50:16 PST Return-Path: Redistributed: CommonLoops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 01 DEC 88 14:45:57 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA18718; Thu, 1 Dec 88 17:45:45 EST Received: by mcvax.cwi.nl via EUnet; Thu, 1 Dec 88 20:29:32 +0100 (MET) Received: by inria.inria.fr via Fnet-EUnet; Thu, 1 Dec 88 11:54:03 +0100 (MET) Received: by imag.imag.fr (5.51/5.17) id AA08477; Thu, 1 Dec 88 10:00:09 +0100 Received: by csinn (1.1/CSI2.0) id AA06909; Thu, 1 Dec 88 10:03:03 GMT Return-Path: Received: by magic (1.1/CSI2.0) id AA11798; Thu, 1 Dec 88 10:01:52 -0100 Date: Thu, 1 Dec 88 10:01:52 -0100 From: Jean Pierre Schiltz Message-Id: <8812010901.AA11798@magic> To: CommonLoops.pa@Xerox.COM Subject: Mailing list request Please remove me from the CommonLoops mailing list ; thanks. Jean-Pierre Schiltz - Cap Sogeti Innovation - Tel : +33 (1) 46 22 60 27 118 rue de Tocqueville - 75017 Paris - France. schiltz@crp.capsogeti.fr ...uunet!mcvax!inria!imag!csinn!schiltz (-: ..."The quick brown fox jumps over the lazy dog..." (Scheidegger)... :-) From Owners-commonloops.pa@Xerox.COM Fri Dec 2 20:29:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03524; Fri, 2 Dec 88 20:29:25 PST Received: from Burger.ms by ArpaGateway.ms ; 02 DEC 88 01:15:26 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 02 DEC 88 01:14:14 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA28996; Fri, 2 Dec 88 04:13:54 EST Received: by mcvax.cwi.nl via EUnet; Fri, 2 Dec 88 09:28:14 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA25544; Fri, 2 Dec 88 07:16:25 +0100 Received: from sparc.delphi by delphi.uucp (3.2/SMI-3.2) id AA07417; Thu, 1 Dec 88 18:49:09 +0100 Received: by sparc.delphi (4.0/SMI-4.0) id AA08503; Thu, 1 Dec 88 18:50:48 +0100 Date: Thu, 1 Dec 88 18:50:48 +0100 From: beppe%delphi%mcvax@uunet.UU.NET (Giuseppe Attardi) Message-Id: <8812011750.AA08503@sparc.delphi> To: commonloops.pa@Xerox.COM Subject: carwash simulator I am puzzled by the claims in your message on November 16th: First (to keep everyone reading) here are my results w/1000 cars: Machine: Symbolics 3650 (best of 4 trials - 'cept for the original :-) ---code--- ---total time (page&gc time)--- original clos port: 61.65 min (13.33 min) below (modified): 28.25 sec (1.6 sec) <- ~130 times speedup no methods in the clos-simulation part (only the carwash part): 27.65 sec (1.7 sec) I have run both the original version and your modified version on a SUN4 with DELPHI Common LISP, and the difference is not so significant (no more than 30% faster then the original). This is exactly what I expected, given the kind of changes that you report: (1) cut out much needless consing. (2) cut out most refs to global vars. (3) turned EVALs into APPLYs. (4) turned a few complex-recursive functions into iterative ones. (5) reorganized style/syntax (mostly for my own sake) I can see that item (1) allows you to save 13 min. of gc time. Still I can't see where you are saving the remaining 48 minutes. By the way, I am not sure whether it is proper to run this benchmark with 1000 cars, since size of memory and gc time become dominant factors in the execution time. If you confirm your results, I would be quite curious to know which one of these items contributes to the ~130 fold speedup. Beppe ----- From Owners-commonloops.pa@Xerox.COM Fri Dec 2 21:30:16 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04170; Fri, 2 Dec 88 21:30:16 PST Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 88 13:40:56 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 02 DEC 88 13:37:19 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA12878; Fri, 2 Dec 88 13:40:07 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA12911; Fri, 2 Dec 88 12:58:26 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA00333; Fri, 2 Dec 88 12:58:57 PST Message-Id: <8812022058.AA00333@suntana.sun.com> To: Michael Sokolov Cc: commonloops.pa@Xerox.COM Subject: Re: method ordering In-Reply-To: Your message of Wed, 30 Nov 88 14:05:46 -0500. <8811301905.AA18604@victoria> Date: Fri, 02 Dec 88 12:58:54 PST From: kempf@Sun.COM >My first question is how does PCL decide in what order the methods are >to be invoked? Does method (test foo0 bar1) come before or after (test >bar0 foo1)? Is it the order of creation of the methods. This was my >best guess. The algorithm for deciding which method is the most specific (and thus which gets executed first after generic dispatch) is described in detail in Chapter 1 of the CLOS spec. Baring method combination and EQL methods, the bottom line is that the classes of the arguments are compared with the classes of the specialized formal parameters from left to right. A match occurs if the class of the argument is an element of the class precedence list of the specialized formal parameter. The method is selected if there are no more parameters to examine (i.e. a hit occurs on each parameter). In practice, there are short cuts which speed up dispatch, but, in principle, this is what is happening. >And my next question is how can this be affected within the methods? In a word, no. The only ways to affect the method execution sequence is to either use method combination to define daemon methods or use call-next-method. Call-next-method only allows you to call the next most specific method (defined, again, in Chapter 1 of the CLOS spec). jak From Owners-commonloops.pa@Xerox.COM Fri Dec 2 21:49:19 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04488; Fri, 2 Dec 88 21:49:19 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 02 DEC 88 18:21:08 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 02 DEC 88 18:16:13 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA19888; Fri, 2 Dec 88 18:17:33 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA12715; Fri, 2 Dec 88 12:52:21 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA00319; Fri, 2 Dec 88 12:52:52 PST Message-Id: <8812022052.AA00319@suntana.sun.com> To: Joachim Laubsch Cc: commonloops.pa@Xerox.COM Subject: Re: type-of under Lucid for HP-UX 6.2 In-Reply-To: Your message of Tue, 29 Nov 88 16:52:59 -0800. <8811300052.AA11804@hpljl.HPL.HP.COM> Date: Fri, 02 Dec 88 12:52:50 PST From: kempf@Sun.COM Joachin: This is part of what making PCL into real CLOS is all about. jak From Owners-commonloops.pa@Xerox.COM Sat Dec 3 05:50:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08571; Sat, 3 Dec 88 05:50:48 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 DEC 88 05:41:00 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 03 DEC 88 05:39:11 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA05147; Sat, 3 Dec 88 08:39:00 EST From: cho@cs.aber.ac.uk Received: by mcvax.cwi.nl via EUnet; Sat, 3 Dec 88 14:34:07 +0100 (MET) Received: from cs.aber.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa29958; 3 Dec 88 13:23 GMT Received: from ares.cs.aber.ac.uk by athene.cs.aber.ac.uk; Sat, 3 Dec 88 13:23:47 GMT Date: Sat, 3 Dec 88 13:23:49 GMT Message-Id: <2382.8812031323@ares.cs.aber.ac.uk> To: "commonloops.pa" Please remove me from the common loops mailing list Chris Orgill, tel +44 970 623111 x3227 AI & Robotics Research Group, email cho%cs.aber.ac.uk@uunet.uu.net (ARPA) Computer Science Department, cho@uk.ac.aber.cs (JANET) University College of Wales, Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. From Gregor.pa@Xerox.COM Mon Dec 5 18:18:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07429; Mon, 5 Dec 88 18:18:01 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 13:54:34 PST Date: Mon, 5 Dec 88 13:51 PST From: Gregor.pa@Xerox.COM Subject: PCL by tape To: CommonLoops.PA@Xerox.COM Message-Id: <19881205215126.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Finally, there is a mechanism for getting PCL releases by tape. The newly formed ENVOS corporation has agreed to distribute PCL by tape for a nominal fee. For $200, ENVOS will send you a UNIX TAR tape of PCL. They will also include a copy of the CLOS specification, and a copy of the First CLOS Workshop proceedings. Send $200, cash, check, or PO to: Lucy Isbell Envos 1157 San Antonio Rd Mt View, CA 94043 Or call (415) 966-6200 with a purchase order number. Be sure to specify cartridge or reel format. ENVOS may also be able to make and send other magnetic media formats like disks, call them for more information. ------- From Owners-commonloops.pa@Xerox.COM Mon Dec 5 21:34:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11734; Mon, 5 Dec 88 21:34:40 PST Received: from Salvador.ms by ArpaGateway.ms ; 05 DEC 88 15:47:32 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 05 DEC 88 15:41:17 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA27836; Mon, 5 Dec 88 15:44:33 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA11783; Mon, 5 Dec 88 15:41:11 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA06945; Mon, 5 Dec 88 15:41:37 PST Message-Id: <8812052341.AA06945@suntana.sun.com> To: commonloops.pa@Xerox.COM Cc: kempf@Sun.COM Subject: (generic-function-pretty-arglist (symbol-function 'initialize-instance)) Date: Mon, 05 Dec 88 15:41:32 PST From: kempf@Sun.COM This breaks in NCONC in Lucid 3.0 with the message that INITARGS is not a list. Here is the backtrace: -> (pcl::generic-function-pretty-arglist (symbol-function 'pcl::initialize-instance)) ERROR: INITARGS is not a list. ->-> :b SYSTEM:LIST-ERROR <- NCONC <- |(METHOD GENERIC-FUNCTION-PRETTY-ARGLIST (STANDARD-GENERIC-FUNCTION))| <- EVAL ->-> :n 1 NCONC: Rest arg 0 (LISTS): ((&REST . INITARGS) INITARGS NIL) ->-> :n 1 |(METHOD GENERIC-FUNCTION-PRETTY-ARGLIST (STANDARD-GENERIC-FUNCTION))|: Required arg 0 (GENERIC-FUNCTION): # ->-> jak From Owners-CommonLoops.pa@Xerox.COM Mon Dec 5 21:40:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11806; Mon, 5 Dec 88 21:40:46 PST Received: from Riesling.ms by ArpaGateway.ms ; 05 DEC 88 14:03:01 PST Return-Path: Redistributed: CommonLoops.pa Received: from Score.Stanford.EDU ([10.3.0.11]) by Xerox.COM ; 05 DEC 88 13:59:27 PST Date: Mon, 5 Dec 88 13:59:17 PST From: Dan Larner Subject: Port of PCL to TI To: CommonLoops.pa@Xerox.COM Cc: Larner@SCORE.STANFORD.EDU Message-Id: <12452080168.48.LARNER@Score.Stanford.EDU> I am trying to bring up PCL on a TI MicroExplorer, and run into a few problems during compilation. The first problem (shown at end of this note) occurred in DEFS.Lisp, where MAPC was getting a dotted list via a call from COMPILER::CW-EXPRESSION, via an earlier SETF expansion. I patched (safely, I think?) around this problem with the following two functions and piece of advice: (defun dotted-listp (arg) "T iff arg is a list, and its last cons is a dotted pair, else NIL" (and (listp arg) (not (eq nil (cdr (last arg)))))) (defun undotlist (alist) "alist assumed to be a dotted list, the list is surgically changed to undotted form, and returned" (rplacd (last alist) (list (cdr (last alist)))) alist) ;;; advice to compiler::cw-expression to make sure the exp argument ;;; isn't a dotted list resulting in a mapc error later on (mapc ;;; will try to take the car of an atom) (advise compiler::cw-expression :before no-dotted-lists 0 (cond ((dotted-listp (first arglist)) ;; make a copy per TI manual (setf arglist (copy-list arglist)) (undotlist (first arglist))))) The second problem encountered, and one that I have not yet tackled, occurs during the compilation of VECTOR.LISP (also shown at end of this note). Any people to contact, helpful hints, or other suggestions about PCL on the TI would be greatly appreciated. Dan Larner Allen-Bradley Co., 1201 S. 2nd St., Milwaukee, WI 53204 (414) 382-4096 Larner@Score.Stanford.Edu ********************* *** FIRST PROBLEM *** ********************* > (pcl::compile-pcl) Compiling TI-PATCHES... Loading binary of TI-PATCHES... . . . Compiling FIN... Loading binary of FIN... Compiling DEFS... << While compiling |SETF GET-SETF-FUNCTION| >> Error expanding macro SETF: The argument to CAR, #:G5586, was of the wrong type. The function expected a cons. Enter the window-based debugger? (Y, N, or A) No. >>Trap #o20453 (ARGTYP CONS M-T T CAR CAR) The argument to CAR, #:G5586, was of the wrong type. The function expected a cons. While in the function MAPC \ COMPILER::CW-EXPRESSION \ COMPILER:CW-TOP-LEVEL Error occurred while compiling |SETF GET-SETF-FUNCTION| Debugger entered while in the following function: MAPC (P.C. = 17) Arg 0 (FCT): COMPILER::CW-EXPRESSION Arg 1 (LIST): #:G5586 Rest arg (LISTS): NIL Warning: the default cons area is COMPILER::COMPILATION-AREA-2 in #. ]Abort *********************** *** SECOND PROBLEM *** *********************** (pcl::compile-pcl) Loading binary of TI-PATCHES... . . . Loading binary of BOOT... Compiling VECTOR... << While compiling LOOKUP-PV-MISS-1 >> Error in compile-time evaluation of (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) ...) The function SPEC is undefined. Enter the window-based debugger? (Y, N, or A) No. >>Trap #o31332 (TRANS-TRAP) The function SPEC is undefined. While in the function ENSURE-GENERIC-FUNCTION \ EARLY-ADD-NAMED-METHOD \ (:INTERNAL REDIRECT-EARLY-FUNCTION-INTERNAL 0) Debugger entered while in the following function: ENSURE-GENERIC-FUNCTION (P.C. = 81) Arg 0 (SPEC): LOOKUP-PV-MISS-1 Rest arg (KEYS): NIL ] Meta-Control-B Full Backtrace Of All ENSURE-GENERIC-FUNCTION (P.C. = 81) Arg 0 (SPEC): LOOKUP-PV-MISS-1 Rest arg (KEYS): NIL EARLY-ADD-NAMED-METHOD (P.C. = 28) Arg 0 (GENERIC-FUNCTION-NAME): LOOKUP-PV-MISS-1 Arg 1 (QUALIFIERS): NIL Arg 2 (SPECIALIZERS): (STANDARD-CLASS T T) Arg 3 (ARGLIST): (CLASS SLOTS PV) Arg 4 (FUNCTION): (LAMBDA (CLASS SLOTS PV) (DECLARE (CLASS CLASS STANDARD-CLASS)) (PROGN CLASS) (BLOCK LOOKUP-PV-MISS-1 (LET # # PV))) Rest arg (OPTIONS): (:DOCUMENTATION NIL) (:INTERNAL REDIRECT-EARLY-FUNCTION-INTERNAL 0) (P.C. = 10) Rest arg (ARGS): (LOOKUP-PV-MISS-1 NIL (STANDARD-CLASS T T) (CLASS SLOTS PV) (LAMBDA (CLASS SLOTS PV) (DECLARE #) (PROGN CLASS) (BLOCK LOOKUP-PV-MISS-1 #)) :DOCUMENTATION NIL) LOAD-DEFMETHOD-INTERNAL (P.C. = 105) Arg 0 (GF-SPEC): LOOKUP-PV-MISS-1 Arg 1 (QUALIFIERS): NIL Arg 2 (SPECIALIZERS): (STANDARD-CLASS T T) Arg 3 (LAMBDA-LIST): (CLASS SLOTS PV) Arg 4 (DOC): NIL Arg 5 (ISL-CACHE-SYMBOL): NIL Arg 6 (PLIST): NIL Arg 7 (FN): (LAMBDA (CLASS SLOTS PV) (DECLARE (CLASS CLASS STANDARD-CLASS)) (PROGN CLASS) (BLOCK LOOKUP-PV-MISS-1 (LET # # PV))) Arg 8 (METHOD-CLASS): STANDARD-METHOD LOAD-DEFMETHOD (P.C. = 39) Arg 0 (CLASS): STANDARD-METHOD Arg 1 (NAME): LOOKUP-PV-MISS-1 Arg 2 (QUALS): NIL Arg 3 (SPECLS): (STANDARD-CLASS T T) Arg 4 (LL): (CLASS SLOTS PV) Arg 5 (DOC): NIL Arg 6 (ISL-CACHE-SYMBOL): NIL Arg 7 (PLIST): NIL Arg 8 (FN): (LAMBDA (CLASS SLOTS PV) (DECLARE (CLASS CLASS STANDARD-CLASS)) (PROGN CLASS) (BLOCK LOOKUP-PV-MISS-1 (LET # # PV))) SYS:*EVAL (P.C. = 544) Arg 0 (FORM): (# (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) SYS:EVAL1 (P.C. = 27) Arg 0 (FORM): (# (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) Arg 1 (NOHOOK): T COMPILER:EVAL-FOR-TARGET (P.C. = 207) Arg 0 (FORM): (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) Arg 1 (ENVIRONMENT): NIL COMPILER::COMPILE-TIME-EVAL (P.C. = 142) Arg 0 (FORM): (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) Arg 1 (TYPE): TICL:MACRO Arg 2 (ENVIRONMENT): NIL COMPILER::QC-FILE-COMMON (P.C. = 110) Arg 0 (FORM): (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) Arg 1 (TYPE): TICL:MACRO COMPILER:COMPILE-DRIVER (P.C. = 449) Arg 0 (OFORM): (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE (STANDARD-CLASS T T)) (QUOTE (CLASS SLOTS PV)) (QUOTE NIL) (QUOTE NIL) ...) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL Arg 3 (COMPILE-TIME-TOO): T Arg 4 (TOP-LEVEL-P): NIL COMPILER:COMPILE-DRIVER (P.C. = 336) Arg 0 (OFORM): (PROGN (LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE LOOKUP-PV-MISS-1) (QUOTE NIL) (QUOTE #) (QUOTE #) (QUOTE NIL) (QUOTE NIL) ...)) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL Arg 3 (COMPILE-TIME-TOO): T Arg 4 (TOP-LEVEL-P): NIL COMPILER:COMPILE-DRIVER (P.C. = 336) Arg 0 (OFORM): (PROGN (PROGN (LOAD-DEFMETHOD # # # # # # # ...))) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL Arg 3 (COMPILE-TIME-TOO): T Arg 4 (TOP-LEVEL-P): NIL COMPILER:COMPILE-DRIVER (P.C. = 300) Arg 0 (OFORM): (EVAL-WHEN (COMPILE LOAD EVAL) (PROGN (PROGN #))) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL Arg 3 (COMPILE-TIME-TOO): NIL Arg 4 (TOP-LEVEL-P): T COMPILER:COMPILE-DRIVER (P.C. = 336) Arg 0 (OFORM): (DEFMETHOD LOOKUP-PV-MISS-1 ((CLASS STANDARD-CLASS) SLOTS PV) (LET (#) (DOLIST # #) PV)) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL Arg 3 (COMPILE-TIME-TOO): NIL Arg 4 (TOP-LEVEL-P): T COMPILER:COMPILE-DRIVER (P.C. = 190) Arg 0 (OFORM): (DEFMETHOD LOOKUP-PV-MISS-1 ((CLASS STANDARD-CLASS) SLOTS PV) (LET (#) (DOLIST # #) PV)) Arg 1 (PROCESS-FN): # Arg 2 (OVERRIDE-FN): NIL --Defaulted args:-- Arg 3 (COMPILE-TIME-TOO): NIL Arg 4 (TOP-LEVEL-P): T COMPILER::QC-FILE-WORK-COMPILE (P.C. = 40) Arg 0 (FORM): (DEFMETHOD LOOKUP-PV-MISS-1 ((CLASS STANDARD-CLASS) SLOTS PV) (LET (#) (DOLIST # #) PV)) COMPILER:COMPILE-STREAM (P.C. = 677) Arg 0 (INPUT-STREAM): # Arg 1 (GENERIC-PATHNAME): #RFS::MAC-PATHNAME "HardDisk: HARDDISK:LARNER:PCL:VECTOR"S Arg 2 (FASD-FLAG): # Arg 3 (PROCESS-FN): # Arg 4 (QC-FILE-LOAD-FLAG): NIL Arg 5 (QC-FILE-IN-CORE-FLAG): NIL Arg 6 (PACKAGE-SPEC): NIL Arg 7 (FILE-LOCAL-DECLARATIONS): ((TICL:DEF INSTANCE-SLOT-POSITION TICL:MACRO TICL:NAMED-LAMBDA (INSTANCE-SLOT-POSITION #) (SYS::*MACROARG* &OPTIONAL SYS::*MACROENVIRONMENT*) (BLOCK INSTANCE-SLOT-POSITION SYS::*MACROENVIRONMENT* # #)) (TICL:DEF CACHE-KEY-FROM-WRAPPERS TICL:MACRO TICL:NAMED-LAMBDA (CACHE-KEY-FROM-WRAPPERS #) (SYS::*MACROARG* &OPTIONAL SYS::*MACROENVIRONMENT*) (BLOCK CACHE-KEY-FROM-WRAPPERS SYS::*MACROENVIRONMENT* # #))) Arg 8 (IGNORE): NIL Arg 9 (COMPILING-WHOLE-FILE-P): T --Defaulted args:-- Arg 10 (OPERATION-TYPE): NIL ZLC:QC-FILE (P.C. = 423) Arg 0 (INFILE): #RFS::MAC-PATHNAME "HardDisk: HARDDISK:LARNER:PCL:VECTOR.LISP"S Arg 1 (OUTFILE): #RFS::MAC-PATHNAME "HardDisk: HARDDISK:LARNER:PCL:VECTOR.XLD"S Arg 2 (LOAD-FLAG): NIL Arg 3 (IN-CORE-FLAG): NIL Arg 4 (PACKAGE-SPEC): NIL Arg 5 (FILE-LOCAL-DECLARATIONS): NIL Arg 6 (DONT-SET-DEFAULT-P): T Arg 7 (IGNORE): NIL Arg 8 (IGNORE): NIL COMPILE-FILE (P.C. = 90) Arg 0 (INPUT-FILENAME): #RFS::MAC-PATHNAME "HardDisk: HARDDISK:LARNER:PCL:VECTOR.LISP"S Rest arg: (:OUTPUT-FILE #RFS::MAC-PATHNAME "HardDisk: HARDDISK:LARNER:PCL:VECTOR.XLD"S) ;;; REST OF BACKTRACE TO TOP LEVEL ][Abort all] ------- From Owners-CommonLoops.pa@Xerox.COM Tue Dec 6 21:15:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA25099; Tue, 6 Dec 88 21:15:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 DEC 88 21:13:45 PST Return-Path: Redistributed: CommonLoops.pa Received: from sumex-aim.stanford.edu ([36.44.0.6]) by Xerox.COM ; 06 DEC 88 21:11:20 PST Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AA13827; Tue, 6 Dec 88 21:12:07 PST Date: Tue, 6 Dec 88 21:12:07 PST From: sotos@SUMEX-AIM.STANFORD.EDU (John Sotos) Message-Id: <8812070512.AA13827@sumex-aim.stanford.edu> To: CommonLoops.pa@Xerox.COM Subject: CLOS timetable What is the best estimate of when the CLOS standard will be finalized? Thanks. John From Owners-commonloops.pa@Xerox.COM Wed Dec 7 07:52:00 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03491; Wed, 7 Dec 88 07:52:00 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 07:50:29 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 07 DEC 88 07:47:24 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA03286; Wed, 7 Dec 88 10:47:07 EST From: cho@cs.aber.ac.uk Received: by mcvax.cwi.nl via EUnet; Wed, 7 Dec 88 15:55:52 +0100 (MET) Received: from cs.aber.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa14627; 7 Dec 88 12:49 GMT Received: from ares.cs.aber.ac.uk by athene.cs.aber.ac.uk; Wed, 7 Dec 88 12:49:43 GMT Date: Wed, 7 Dec 88 12:49:43 GMT Message-Id: <1870.8812071249@ares.cs.aber.ac.uk> To: larner Cc: postmaster@ukc.ac.uk, "commonloops.pa" , mdt@compsci.aberystwyth.ac.uk Subject: Re: Port of PCL to TI I have now received 30+ identical copies of this mail ! As we pay for incoming mail, you will understand my urgency in asking you to ascertain whether your mailer is at fault or whether the fault lies in the Owners-CommonLoops redistribution mechanism. It is particularly provoking since I asked to be removed from this list last week ! Regards, Chris Orgill, tel +44 970 623111 x3227 AI & Robotics Research Group, email cho%cs.aber.ac.uk@uunet.uu.net (ARPA) Computer Science Department, cho@uk.ac.aber.cs (JANET) University College of Wales, Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. From Owners-commonloops.pa@Xerox.COM Wed Dec 7 14:56:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03524; Fri, 2 Dec 88 20:29:25 PST Received: from Burger.ms by ArpaGateway.ms ; 02 DEC 88 01:15:26 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 02 DEC 88 01:14:14 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA28996; Fri, 2 Dec 88 04:13:54 EST Received: by mcvax.cwi.nl via EUnet; Fri, 2 Dec 88 09:28:14 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA25544; Fri, 2 Dec 88 07:16:25 +0100 Received: from sparc.delphi by delphi.uucp (3.2/SMI-3.2) id AA07417; Thu, 1 Dec 88 18:49:09 +0100 Received: by sparc.delphi (4.0/SMI-4.0) id AA08503; Thu, 1 Dec 88 18:50:48 +0100 Date: Thu, 1 Dec 88 18:50:48 +0100 From: beppe%delphi%mcvax@uunet.UU.NET (Giuseppe Attardi) Message-Id: <8812011750.AA08503@sparc.delphi> To: commonloops.pa@Xerox.COM Subject: carwash simulator I am puzzled by the claims in your message on November 16th: First (to keep everyone reading) here are my results w/1000 cars: Machine: Symbolics 3650 (best of 4 trials - 'cept for the original :-) ---code--- ---total time (page&gc time)--- original clos port: 61.65 min (13.33 min) below (modified): 28.25 sec (1.6 sec) <- ~130 times speedup no methods in the clos-simulation part (only the carwash part): 27.65 sec (1.7 sec) I have run both the original version and your modified version on a SUN4 with DELPHI Common LISP, and the difference is not so significant (no more than 30% faster then the original). This is exactly what I expected, given the kind of changes that you report: (1) cut out much needless consing. (2) cut out most refs to global vars. (3) turned EVALs into APPLYs. (4) turned a few complex-recursive functions into iterative ones. (5) reorganized style/syntax (mostly for my own sake) I can see that item (1) allows you to save 13 min. of gc time. Still I can't see where you are saving the remaining 48 minutes. By the way, I am not sure whether it is proper to run this benchmark with 1000 cars, since size of memory and gc time become dominant factors in the execution time. If you confirm your results, I would be quite curious to know which one of these items contributes to the ~130 fold speedup. Beppe ----- From Owners-commonloops.pa@Xerox.COM Wed Dec 7 15:08:34 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08571; Sat, 3 Dec 88 05:50:48 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 DEC 88 05:41:00 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 03 DEC 88 05:39:11 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA05147; Sat, 3 Dec 88 08:39:00 EST From: cho@cs.aber.ac.uk Received: by mcvax.cwi.nl via EUnet; Sat, 3 Dec 88 14:34:07 +0100 (MET) Received: from cs.aber.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa29958; 3 Dec 88 13:23 GMT Received: from ares.cs.aber.ac.uk by athene.cs.aber.ac.uk; Sat, 3 Dec 88 13:23:47 GMT Date: Sat, 3 Dec 88 13:23:49 GMT Message-Id: <2382.8812031323@ares.cs.aber.ac.uk> To: "commonloops.pa" Please remove me from the common loops mailing list Chris Orgill, tel +44 970 623111 x3227 AI & Robotics Research Group, email cho%cs.aber.ac.uk@uunet.uu.net (ARPA) Computer Science Department, cho@uk.ac.aber.cs (JANET) University College of Wales, Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. From Gregor.pa@Xerox.COM Wed Dec 7 15:41:07 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07429; Mon, 5 Dec 88 18:18:01 PST Received: from Semillon.ms by ArpaGateway.ms ; 05 DEC 88 13:54:34 PST Date: Mon, 5 Dec 88 13:51 PST From: Gregor.pa@Xerox.COM Subject: PCL by tape To: CommonLoops.PA@Xerox.COM Message-Id: <19881205215126.4.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Finally, there is a mechanism for getting PCL releases by tape. The newly formed ENVOS corporation has agreed to distribute PCL by tape for a nominal fee. For $200, ENVOS will send you a UNIX TAR tape of PCL. They will also include a copy of the CLOS specification, and a copy of the First CLOS Workshop proceedings. Send $200, cash, check, or PO to: Lucy Isbell Envos 1157 San Antonio Rd Mt View, CA 94043 Or call (415) 966-6200 with a purchase order number. Be sure to specify cartridge or reel format. ENVOS may also be able to make and send other magnetic media formats like disks, call them for more information. ------- From Owners-commonloops.pa@Xerox.COM Wed Dec 7 16:35:21 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03491; Wed, 7 Dec 88 07:52:00 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 07:50:29 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 07 DEC 88 07:47:24 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA03286; Wed, 7 Dec 88 10:47:07 EST From: cho@cs.aber.ac.uk Received: by mcvax.cwi.nl via EUnet; Wed, 7 Dec 88 15:55:52 +0100 (MET) Received: from cs.aber.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa14627; 7 Dec 88 12:49 GMT Received: from ares.cs.aber.ac.uk by athene.cs.aber.ac.uk; Wed, 7 Dec 88 12:49:43 GMT Date: Wed, 7 Dec 88 12:49:43 GMT Message-Id: <1870.8812071249@ares.cs.aber.ac.uk> To: larner Cc: postmaster@ukc.ac.uk, "commonloops.pa" , mdt@compsci.aberystwyth.ac.uk Subject: Re: Port of PCL to TI I have now received 30+ identical copies of this mail ! As we pay for incoming mail, you will understand my urgency in asking you to ascertain whether your mailer is at fault or whether the fault lies in the Owners-CommonLoops redistribution mechanism. It is particularly provoking since I asked to be removed from this list last week ! Regards, Chris Orgill, tel +44 970 623111 x3227 AI & Robotics Research Group, email cho%cs.aber.ac.uk@uunet.uu.net (ARPA) Computer Science Department, cho@uk.ac.aber.cs (JANET) University College of Wales, Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. From Gregor.pa@Xerox.COM Wed Dec 7 16:39:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10735; Wed, 7 Dec 88 16:39:37 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 15:57:39 PST Date: Wed, 7 Dec 88 11:16 PST From: Gregor.pa@Xerox.COM Subject: Re: CLOS timetable To: John Sotos Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812070512.AA13827@sumex-aim.stanford.edu> Message-Id: <19881207191633.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 6 Dec 88 21:12:07 PST From: sotos@sumex-aim.stanford.edu (John Sotos) What is the best estimate of when the CLOS standard will be finalized? As you know, Chapters 1 and 2 have been accepted by the X3J13 committee, and so those are now out of the hands of the CLOS subcommittee. It is important to keep in mind that X3J13 has not voted on a draft of the entire ANSI Common Lisp language yet, so it is possible that X3J13 will make minor changes in those chapters. I would say that such changes are extremely unlikely. I think you can safely consider document 88-002R (as published in SIGPLAN notices and soon to appear in LAFP) to be the final version of chapters 1 and 2. We are still working on chapter 3. We promised the X3J13 committee that we would give them a draft of chapter 3 to vote on at the January 16th meeting. We will be mailing a draft to the X3J13 committee on December 15th. Between December 15th and the January 16th, we will continue to work on that draft. But the changes we will make in that period will be to improve presentation and fix bugs. I expect the full X3J13 committee will be able to vote on chapter 3 in Hawaii. It is possible that there will be some minor changes that will need to be made after the Hawaii meeting. These changes could be handled as part of the normal editorial process for the entire ANSI Common Lisp language. Such a change would of course have to get the approval of the full X3J13 committee at a later meeting. So, you can expect chapter 3 to be essentially finalized in mid January. ------- From Owners-commonloops.pa@Xerox.COM Wed Dec 7 20:09:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03491; Wed, 7 Dec 88 07:52:00 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 07:50:29 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 07 DEC 88 07:47:24 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA03286; Wed, 7 Dec 88 10:47:07 EST From: cho@cs.aber.ac.uk Received: by mcvax.cwi.nl via EUnet; Wed, 7 Dec 88 15:55:52 +0100 (MET) Received: from cs.aber.ac.uk by kestrel.Ukc.AC.UK via Janet (UKC CAMEL FTP) id aa14627; 7 Dec 88 12:49 GMT Received: from ares.cs.aber.ac.uk by athene.cs.aber.ac.uk; Wed, 7 Dec 88 12:49:43 GMT Date: Wed, 7 Dec 88 12:49:43 GMT Message-Id: <1870.8812071249@ares.cs.aber.ac.uk> To: larner Cc: postmaster@ukc.ac.uk, "commonloops.pa" , mdt@compsci.aberystwyth.ac.uk Subject: Re: Port of PCL to TI I have now received 30+ identical copies of this mail ! As we pay for incoming mail, you will understand my urgency in asking you to ascertain whether your mailer is at fault or whether the fault lies in the Owners-CommonLoops redistribution mechanism. It is particularly provoking since I asked to be removed from this list last week ! Regards, Chris Orgill, tel +44 970 623111 x3227 AI & Robotics Research Group, email cho%cs.aber.ac.uk@uunet.uu.net (ARPA) Computer Science Department, cho@uk.ac.aber.cs (JANET) University College of Wales, Aberystwyth, Dyfed, United Kingdom. SY23 3BZ. From Gregor.pa@Xerox.COM Wed Dec 7 20:35:13 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10735; Wed, 7 Dec 88 16:39:37 PST Received: from Semillon.ms by ArpaGateway.ms ; 07 DEC 88 15:57:39 PST Date: Wed, 7 Dec 88 11:16 PST From: Gregor.pa@Xerox.COM Subject: Re: CLOS timetable To: John Sotos Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812070512.AA13827@sumex-aim.stanford.edu> Message-Id: <19881207191633.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 6 Dec 88 21:12:07 PST From: sotos@sumex-aim.stanford.edu (John Sotos) What is the best estimate of when the CLOS standard will be finalized? As you know, Chapters 1 and 2 have been accepted by the X3J13 committee, and so those are now out of the hands of the CLOS subcommittee. It is important to keep in mind that X3J13 has not voted on a draft of the entire ANSI Common Lisp language yet, so it is possible that X3J13 will make minor changes in those chapters. I would say that such changes are extremely unlikely. I think you can safely consider document 88-002R (as published in SIGPLAN notices and soon to appear in LAFP) to be the final version of chapters 1 and 2. We are still working on chapter 3. We promised the X3J13 committee that we would give them a draft of chapter 3 to vote on at the January 16th meeting. We will be mailing a draft to the X3J13 committee on December 15th. Between December 15th and the January 16th, we will continue to work on that draft. But the changes we will make in that period will be to improve presentation and fix bugs. I expect the full X3J13 committee will be able to vote on chapter 3 in Hawaii. It is possible that there will be some minor changes that will need to be made after the Hawaii meeting. These changes could be handled as part of the normal editorial process for the entire ANSI Common Lisp language. Such a change would of course have to get the approval of the full X3J13 committee at a later meeting. So, you can expect chapter 3 to be essentially finalized in mid January. ------- From kiuchi.pa@Xerox.COM Wed Dec 7 21:07:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14281; Wed, 7 Dec 88 19:28:12 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 88 19:14:01 PST Date: 7 Dec 88 19:12 PST From: kiuchi.pa@Xerox.COM Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Cc: kiuchi.pa@Xerox.COM Message-Id: <881207-191401-2555@Xerox> There is a new version of PCL on arisia.xerox.com. The *pcl-system-date* for this version is 12/7/88. This version has major improvements in the generic function caching mechanism. This version has been tested in the following Lisps: Symbolics 7.2 Coral 1.2 Lucid 3.0 KCL (October 15, 1987) We will test it in Envos MEDLEY shortly. In addition, we expect it works in these lisps, if you try it in one of them, let us know what happens. ExCL TI ------- From Owners-commonloops.pa@Xerox.COM Thu Dec 8 07:29:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22510; Thu, 8 Dec 88 07:29:14 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 08 DEC 88 07:25:55 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 08 DEC 88 07:20:15 PST Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Thu 8 Dec 88 09:20:01-CST Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA23432; Thu, 8 Dec 88 09:19:58 CST Date: Thu, 8 Dec 88 09:19:55 CST From: Rob Pettengill Message-Id: <8812081519.AA14276@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA14276; Thu, 8 Dec 88 09:19:55 CST To: commonloops.pa@Xerox.COM Subject: Re: new version of PCL First the good news. The new PCL does compile, load, and run the test file in Franz Allegro 3.0.1 (with patches 1, 3, 12, 21.2, 22). A minor nit: the notes.text file refers to this as the 12/27/88 version rather than the 12/7/88 version. A major bug in effective method computation which was present in the last version, 8/28/88, is still present in the new 12/7/88 version. I am enclosing my bug report with a workaround for that version. I have not yet checked to see if the workaround given below is still valid. ;rob ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Date: Wed, 7 Sep 88 14:54:59 CDT From: Rob Pettengill To: Gregor.pa@Xerox.com Subject: Bug in effective method computation (compute-combination-points) Cc: CommonLoops.pa@Xerox.COM, halasz ;;; -*- Mode:Lisp; Package: pclt; Syntax:COMMON-LISP; Base:10 -*- #| ; (LISP-IMPLEMENTATION-TYPE) = Allegro CL ; (LISP-IMPLEMENTATION-VERSION) = 3.0.1 [sun3] (8/16/88 17:44) ; (SOFTWARE-TYPE) = SMI Unix ; (MACHINE-TYPE) = Sun Microsystems ; PCL::*PCL-SYSTEM-DATE* = 8/28/88 (beta rev 1) AAAI PCL This file illustrates a bug in the computation of combined methods which results in the the effective method missing certain inherited methods. A simple class hierarchy with a single method foo that illustrates this bug is shown below. A-WITH-FOO / \ / \ / \ / \ B-WITH-FOO C-WITH-FOO | / | | / | | / | D-WITH-FOO E-WITHOUT-FOO \ / \ / \ / \ / \ / \ / F-WITH-BAZ-THAT-CALLS-FOO The expected outcome of a call to BAZ on an instance of F-WITH-BAZ-THAT-CALLS-FOO should be (pclt::run-test) Hello from BAZ in F Hello from FOO in D-WITH-FOO Hello from FOO in B-WITH-FOO Hello from FOO in C-WITH-FOO Hello from FOO in A-WITH-FOO NIL however the actual outcome is (pclt::run-test) Hello from BAZ in F Hello from FOO in B-WITH-FOO Hello from FOO in C-WITH-FOO Hello from FOO in A-WITH-FOO NIL We have found a kludge that fixes this particular case by the following change to combin.lisp (defun compute-combination-points (generic-function) (let* ((gf-methods (generic-function-methods generic-function)) (result ())) (dolist (m (append gf-methods gf-methods)) ______________________________ changed from gf-methods so that the list of methods is traversed twice ... |# (IN-PACKAGE 'PCLT :USE '(PCL LISP)) (defclass A-WITH-FOO () () ) (defmethod FOO ((SELF A-WITH-FOO)) (format t "~%Hello from FOO in A-WITH-FOO") ) (defclass B-WITH-FOO (A-WITH-FOO) () ) (defmethod FOO ((SELF B-WITH-FOO)) (format t "~%Hello from FOO in B-WITH-FOO") (call-next-method)) (defclass C-WITH-FOO (A-WITH-FOO) ( ) ) (defmethod FOO ((SELF C-WITH-FOO)) (format t "~%Hello from FOO in C-WITH-FOO") (call-next-method) ) (defclass D-WITH-FOO (B-WITH-FOO C-WITH-FOO) ;was bordered- ... () ) (defmethod FOO ((SELF D-WITH-FOO)) (format t "~%Hello from FOO in D-WITH-FOO") (call-next-method) ) (defclass E-WITHOUT-FOO (C-WITH-FOO) () ) (defclass F-WITH-BAZ-THAT-CALLS-FOO (D-WITH-FOO E-WITHOUT-FOO) () ) (defmethod BAZ ((SELF F-WITH-BAZ-THAT-CALLS-FOO)) (format t "~%Hello from BAZ in F") (FOO SELF)) (defun run-test () (let ((x (make-instance 'F-WITH-BAZ-THAT-CALLS-FOO))) (baz x))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Robert C. Pettengill, MCC Software Technology Program P. O. Box 200195, Austin, Texas 78720 ARPA: rcp@mcc.com PHONE: (512) 338-3533 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp From Owners-CommonLoops.pa@Xerox.COM Thu Dec 8 09:44:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24000; Thu, 8 Dec 88 09:44:43 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 08 DEC 88 09:41:53 PST Return-Path: Redistributed: CommonLoops.pa Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 08 DEC 88 09:31:36 PST Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05630; 8 Dec 88 16:39 GMT Date: Thu, 8 Dec 88 16:47:26 GMT Message-Id: <5044.8812081647@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: new version of PCL To: kiuchi.pa@Xerox.COM, CommonLoops.pa@Xerox.COM In-Reply-To: kiuchi.pa@com.xerox's message of 7 Dec 88 19:12 PST Cc: kiuchi.pa@Xerox.COM > There is a new version of PCL on arisia.xerox.com. > This version has been tested in the following Lisps: > KCL (October 15, 1987) What is this beast? The version from U-Texas is dated June 3, 1987. I have asked the KCl mailing list if they know of a later version, and they do not. -- Jeff Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton From Owners-commonloops.pa@Xerox.COM Thu Dec 8 10:01:54 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA23841; Thu, 8 Dec 88 09:40:56 PST Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 09:37:03 PST Return-Path: <@arisia.Xerox.COM,@lll-winken.UUCP,@att:lgm@ihlpf> Redistributed: commonloops.pa Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 08 DEC 88 09:33:06 PST Received: from lll-winken.UUCP by arisia.Xerox.COM with UUCP (5.59++/IDA-1.2.6) id AA23595; Thu, 8 Dec 88 09:34:03 PST Date: Thu, 8 Dec 88 09:34:03 PST Message-Id: <8812081734.AA23595@arisia.Xerox.COM> Received: by lll-winken.llnl.gov (smail2.5) id AA18646; 8 Dec 88 09:20:39 PST (Thu) Received: by att.ATT.COM (smail2.6 - att-ih) id AA15937; 8 Dec 88 10:52:47 CST (Thu) From: lgm@ihlpf.UUCP (Lawrence G Mayka +1 312 416 5166) To: commonloops.pa@Xerox.COM Subject: How to get CLOS Workshop proceedings? I'm new to this mailing list, so forgive me if the answer to this has been posted in the past: How do I get a copy of the proceedings of the CLOS Workshop? A recent posting said that Envos would including a copy of the proceedings *with* a purchase of PCL on tape; but I called Envos, and they don't seem willing to sell copies of the proceedings alone. Is there any other source, and how much do the proceedings cost? Lawrence G. Mayka AT&T Bell Laboratories att!ihlpf!lgm From Owners-commonloops.pa@Xerox.COM Thu Dec 8 12:47:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA26555; Thu, 8 Dec 88 12:47:41 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 12:37:18 PST Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 08 DEC 88 12:33:52 PST Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Thu 8 Dec 88 14:33:41-CST Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA02885; Thu, 8 Dec 88 14:33:38 CST Date: Thu, 8 Dec 88 14:33:35 CST From: Rob Pettengill Message-Id: <8812082033.AA14639@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA14639; Thu, 8 Dec 88 14:33:35 CST To: commonloops.pa@Xerox.COM Subject: find-method & new pcl I noticed that find-method is still not in PCL. However pcl::real-get-method is an appears to have exactly the functionality of find-method. If so should this be renamed or at least exported under the name find-method? (pcl::real-get-method (symbol-function 'pcl:print-object) () (mapcar #'pcl:find-class '(pcl::STANDARD-METHOD t)) nil) # ;rob From Owners-commonloops.PA@Xerox.COM Thu Dec 8 13:38:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27266; Thu, 8 Dec 88 13:38:08 PST Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 13:20:06 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 13:08:52 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA20665; Thu, 8 Dec 88 16:08:31 EST Date: Thu, 8 Dec 88 16:08:31 EST From: Arun Welch Message-Id: <8812082108.AA20665@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM, aisupport.PA@Xerox.COM Subject: clos-browser, Xerox/Envos Lisp Is the version that's on arisia current? The clos-browser file is dated 21-mar, but the web-editor is dated 31-Aug. Also, is the pcl-env-internal file missing or just not needed any more? On a lighter note, the clos-browser file is copyrighted 1987, 1988, 1900, 1901... someone have their COPYRIGHTFLG set but their date/time off? For some wierd reason, I have difficulty believing you folks actually wrote it back then ("Sherman, set the Way-Back Machine for 1901. We have to write a CLOS-Browser." :-) ...arun From Owners-commonloops.PA@Xerox.COM Thu Dec 8 13:55:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27467; Thu, 8 Dec 88 13:55:01 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 13:42:34 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 13:29:20 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA21716; Thu, 8 Dec 88 16:28:59 EST Date: Thu, 8 Dec 88 16:28:59 EST From: Arun Welch Message-Id: <8812082128.AA21716@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Missing P in Xerox-patches I suspect he last four lines in xerox-patches.lisp should be (if (null compiler::*made-changes*) (setf (compiler::node-meta-p compiler::node) compiler:context) ; Note the -p ^^ (setf (compiler::node-meta-p compiler::node) nil))) compiler::node) instead of (if (null compiler::*made-changes*) (setf (compiler::node-meta- compiler::node) compiler:context) (setf (compiler::node-meta-p compiler::node) nil))) compiler::node) ...arun From lanning.pa@Xerox.COM Thu Dec 8 13:58:04 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27476; Thu, 8 Dec 88 13:58:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 13:44:22 PST Date: Thu, 08 Dec 88 13:39:03 PST From: lanning.pa@Xerox.COM Subject: Re: clos-browser, Xerox/Envos Lisp In-Reply-To: <8812082108.AA20665@tut.cis.ohio-state.edu> To: Arun Welch Cc: commonloops.pa@Xerox.COM, aisupport.pa@Xerox.COM Message-Id: <881208-134422-4453@Xerox> I have no reason to believe that the Clos-browse will work in the current PCL. Nobody has worked on it or the web-browser for quite a while. But you are welcome to fix it and post a working version. (How's that for a lighter note?) -msL From Owners-commonloops.pa@Xerox.COM Thu Dec 8 14:31:30 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27808; Thu, 8 Dec 88 14:31:30 PST Received: from Burger.ms by ArpaGateway.ms ; 08 DEC 88 14:09:24 PST Return-Path: Redistributed: commonloops.pa Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 14:05:31 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA23661; Thu, 8 Dec 88 17:05:10 EST Date: Thu, 8 Dec 88 17:05:10 EST From: Arun Welch Message-Id: <8812082205.AA23661@tut.cis.ohio-state.edu> To: lanning.pa@Xerox.COM Cc: commonloops.pa@Xerox.COM, aisupport.pa@Xerox.COM In-Reply-To: lanning.pa@xerox.com's message of Thu, 08 Dec 88 13:39:03 PST <881208-134422-4453@Xerox> Subject: clos-browser, Xerox/Envos Lisp Me and my big mouth... :-). No promises, but it's a possibility... If anyone else is working on this outside of Xerox/Envos, could you send me a message? ...arun From Owners-CommonLoops.PA@Xerox.COM Thu Dec 8 14:35:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA27843; Thu, 8 Dec 88 14:35:25 PST Received: from Salvador.ms by ArpaGateway.ms ; 08 DEC 88 14:15:55 PST Return-Path: Redistributed: CommonLoops.PA Received: from polya.Stanford.EDU ([36.8.0.160]) by Xerox.COM ; 08 DEC 88 14:09:48 PST Received: by polya.Stanford.EDU (5.59/25-eef) id AA02849; Thu, 8 Dec 88 14:10:25 PDT Date: Thu, 8 Dec 88 14:10:25 PDT From: Lockheed Message-Id: <8812082210.AA02849@polya.Stanford.EDU> To: CommonLoops.PA@Xerox.COM Subject: help Hi, tried to ftp the CLOS files from parcvax.xerox.com and it asked for user/password. Tried guest/guest but no luck. Do we need to know an account or are we using ftp wrong? Thanx, Jon Schlossberg, et al. lockheed@polya.stanford.edu From Owners-commonloops.PA@Xerox.COM Thu Dec 8 14:47:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28009; Thu, 8 Dec 88 14:47:17 PST Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 88 14:44:06 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 14:30:35 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA25193; Thu, 8 Dec 88 17:29:43 EST Date: Thu, 8 Dec 88 17:29:43 EST From: Arun Welch Message-Id: <8812082229.AA25193@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Bug in Low.lisp The last lines in Low.lisp are: (defun record-definition (type spec &rest args) (declare ignore type spec args)) ()) Shouldn't that be (declare (ignore type spec args))? and in fact, should the whole thing be there at all? Grepping the sources turns it up in a couple of the other -low files, is it just a place-holder (albeit mis-defined)? ...arun From kiuchi.pa@Xerox.COM Thu Dec 8 15:16:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28288; Thu, 8 Dec 88 15:16:47 PST Received: from Burger.ms by ArpaGateway.ms ; 08 DEC 88 15:06:34 PST Date: 8 Dec 88 15:03 PST From: kiuchi.pa@Xerox.COM Subject: Re: new version of PCL In-Reply-To: Jeff Dalton 's message of Thu, 8 Dec 88 16:47:26 GMT To: Jeff Dalton Cc: kiuchi.pa@Xerox.COM, CommonLoops.pa@Xerox.COM Message-Id: <881208-150634-4662@Xerox> We have tested new version of PCL on IBUKI Common Lisp 01/01 October 15, 1987. Yasuhiko From Owners-commonloops.PA@Xerox.COM Thu Dec 8 15:28:04 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28384; Thu, 8 Dec 88 15:28:04 PST Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 88 15:19:59 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 15:04:46 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA26496; Thu, 8 Dec 88 18:04:26 EST Date: Thu, 8 Dec 88 18:04:26 EST From: Arun Welch Message-Id: <8812082304.AA26496@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Bug in Xerox-low.lisp I suspect that the last form in xerox-low.lisp should be: (defun set-function-name-1 (fn new-name uninterned-name) (cond ((typep fn 'il:compiled-closure) (il:\\rplptr (compiled-closure-fnheader fn) 4 new-name) ((when (and (consp uninterned-name) (eq (car uninterned-name) 'method))) (let ((debug (si::compiled-function-debugging-info fn))) (when debug (setf (cdr debug) uninterned-name))))) (t nil)) fn) rather than it's current form. ...arun From Owners-commonloops.PA@Xerox.COM Thu Dec 8 16:03:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28765; Thu, 8 Dec 88 16:03:48 PST Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 88 15:56:23 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 15:04:46 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA26496; Thu, 8 Dec 88 18:04:26 EST Date: Thu, 8 Dec 88 18:04:26 EST From: Arun Welch Message-Id: <8812082304.AA26496@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Bug in Xerox-low.lisp I suspect that the last form in xerox-low.lisp should be: (defun set-function-name-1 (fn new-name uninterned-name) (cond ((typep fn 'il:compiled-closure) (il:\\rplptr (compiled-closure-fnheader fn) 4 new-name) ((when (and (consp uninterned-name) (eq (car uninterned-name) 'method))) (let ((debug (si::compiled-function-debugging-info fn))) (when debug (setf (cdr debug) uninterned-name))))) (t nil)) fn) rather than it's current form. ...arun From Owners-commonloops.PA@Xerox.COM Thu Dec 8 16:52:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29285; Thu, 8 Dec 88 16:52:23 PST Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 88 16:37:53 PST Return-Path: Redistributed: commonloops.PA Received: from Princeton.EDU ([10.7.0.96]) by Xerox.COM ; 08 DEC 88 16:34:38 PST Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/1.87) id AA29380; Thu, 8 Dec 88 19:34:36 EST Received: by winnie.Princeton.EDU (4.12/1.65) id AA09640; Thu, 8 Dec 88 19:34:17 est Date: Thu, 8 Dec 88 19:34:17 est From: eliot@winnie.Princeton.EDU (eliot handelman) Message-Id: <8812090034.AA09640@winnie.Princeton.EDU> To: commonloops.PA@Xerox.COM Subject: Cute PCL in KCl Cc: eliot@winnie.Princeton.EDU I got the new PCL up in KCl of June 3, 1987 (what's the October 15 ed? utexas still has the June 3 version for ftp) on a vax running 4.2 BSD without any problems other than: 1. "make-keyword" in the turbo-closure patch had to be replaced with "make-ordinary" 2. I take it this time 'IBCL does NOT have to be pushed onto *features* 3. pkg.o didn't know about *exports* but did when I recompiled it (very mysterious) 4. KCl loads "init" on startup and so init.lsp had to be renamed 5. my KCl failed on the type of #(2,1) in the test file (an old KCl bug which has, I think, been fixed?) One other thing: is there some way to prevent PCl from compiling constructors, must they be compiled at all? The KCl compiler, as is known, is the slowest in the world and we don't like compiling things on the fly unless we have important phone calls to make or whatever. Now if only I can figure out how to make music with this thing. Best, Eliot Handelman Music Dept, Princeton U. From Owners-commonloops.PA@Xerox.COM Thu Dec 8 17:06:30 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA29620; Thu, 8 Dec 88 17:06:30 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 17:04:22 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 08 DEC 88 16:52:47 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA29985; Thu, 8 Dec 88 19:52:27 EST Date: Thu, 8 Dec 88 19:52:27 EST From: Arun Welch Message-Id: <8812090052.AA29985@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Son of Xerox-Low.lisp Oops, I screwed up. The correct version of the last form in the file should be: (defun set-function-name-1 (fn new-name uninterned-name) (cond ((typep fn 'il:compiled-closure) (il:\\rplptr (compiled-closure-fnheader fn) 4 new-name) ; add the '(' for this form ^ (when (and (consp uninterned-name) (eq (car uninterned-name) 'method)) (let ((debug (si::compiled-function-debugging-info fn))) (when debug (setf (cdr debug) uninterned-name))))) (t nil)) fn) The previous version, while now semantically correct, is functionally wrong. Sorry. ...arun From Owners-commonloops.pa@Xerox.COM Thu Dec 8 17:54:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00012; Thu, 8 Dec 88 17:54:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 17:49:16 PST Return-Path: <@RELAY.CS.NET:kawabe@etl.jp> Redistributed: commonloops.pa Received: from RELAY.CS.NET ([10.4.0.5]) by Xerox.COM ; 08 DEC 88 17:44:41 PST Received: from relay2.cs.net by RELAY.CS.NET id aq05132; 8 Dec 88 17:13 EST Received: from etl.jp by RELAY.CS.NET id aa00695; 8 Dec 88 16:18 EST Received: from KS301A by etlcom.etl.junet (3.2/6.3Junet-1.0) id AA24542; Thu, 8 Dec 88 17:12:43 JST Message-Id: <2806560643-1301951@KS301A> Sender: HAL@etl.jp Date: Thu, 8 Dec 88 17:10:43 NIL From: Haruyuki Kawabe To: commonloops.pa@Xerox.COM Subject: PCL for TI Explorer tracing the Evaluation of (defmethod quux ((x integer)) x) : (1 ENTER SET-FUNCTION-NAME: (LAMBDA (X) (DECLARE (CLASS X INTEGER)) (PROGN X) (BLOCK QUUX X)) (METHOD QUUX (INTEGER))) (1 EXIT SET-FUNCTION-NAME: (LAMBDA (X) (DECLARE (CLASS X INTEGER)) (PROGN X) (BLOCK QUUX X))) (1 ENTER LOAD-DEFMETHOD-INTERNAL: QUUX NIL (INTEGER) (X) NIL NIL NIL (LAMBDA (X) (DECLARE (CLASS X INTEGER)) (PROGN X) (BLOCK QUUX X)) STANDARD-METHOD) (1 ENTER ENSURE-GENERIC-FUNCTION: QUUX :LAMBDA-LIST (X)) (1 ENTER SET-FUNCTION-NAME: # QUUX) (1 EXIT SET-FUNCTION-NAME: #) (1 EXIT ENSURE-GENERIC-FUNCTION: #) (1 ENTER INSTALL-DISCRIMINATING-FUNCTION: # #) (1 ENTER SET-FUNCALLABLE-INSTANCE-FUNCTION: # #) (1 EXIT SET-FUNCALLABLE-INSTANCE-FUNCTION: #) (1 EXIT INSTALL-DISCRIMINATING-FUNCTION: #) (1 EXIT LOAD-DEFMETHOD-INTERNAL: NIL) In ENSURE-GENERIC-FUNCTION, SET-FUNCTION-NAME set the function name of # to QUUX, but after that in SET-FUNCALLABLE-INSTANCE-FUNCTION, (setf (lexical-closure-function #) (lexical-closure-function #)) is executed. So SET-FUNCTION-NAME is ineffecitve. Haruyuki Kawabe Knowledge Systems Nihon Unisys, Ltd. 2-17-51 Akasaka, Minato-ku, Tokyo 107, JAPAN e-mail: kawabe%etl.jp@relay.cs.net From Gregor.pa@Xerox.COM Thu Dec 8 17:57:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00043; Thu, 8 Dec 88 17:57:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 88 17:53:50 PST Date: Thu, 8 Dec 88 17:50 PST From: Gregor.pa@Xerox.COM Subject: Re: Cute PCL in KCl To: eliot handelman Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812090034.AA09640@winnie.Princeton.EDU> Message-Id: <19881209015023.8.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 8 Dec 88 19:34:17 est From: eliot@winnie.Princeton.EDU (eliot handelman) One other thing: is there some way to prevent PCl from compiling constructors, must they be compiled at all? I don't understand your problem here? When are constructors being compiled when you don't want them to be? Constructors should only be compiled when the file containing the defconstructor form is compiled. Constructors should not be compiled when the file is loaded, when constructors are called, or class or method definitions change. ------- From Gregor.pa@Xerox.COM Thu Dec 8 18:15:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00304; Thu, 8 Dec 88 18:15:26 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 18:01:57 PST Date: Thu, 8 Dec 88 17:49 PST From: Gregor.pa@Xerox.COM Subject: Re: Cute PCL in KCl To: eliot handelman Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812090034.AA09640@winnie.Princeton.EDU> Message-Id: <19881209014947.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 8 Dec 88 19:34:17 est From: eliot@winnie.Princeton.EDU (eliot handelman) One other thing: is there some way to prevent PCl from compiling constructors, must they be compiled at all? I don't understand your problem here? When are constructors being compiled when you don't want them to be? Constructors should only be compiled when the file containing the defconstructor form is compiled. Constructors should not be compiled when the file is loaded, when constructors are called, or class or method definitions change. ------- From Gregor.pa@Xerox.COM Thu Dec 8 18:38:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00691; Thu, 8 Dec 88 18:38:39 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 18:15:41 PST Date: Thu, 8 Dec 88 17:57 PST From: Gregor.pa@Xerox.COM Subject: Re: find-method & new pcl To: Rob Pettengill Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812082033.AA14639@perseus.sw.mcc.com> Message-Id: <19881209015703.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 8 Dec 88 14:33:35 CST From: Rob Pettengill I noticed that find-method is still not in PCL. However pcl::real-get-method is an appears to have exactly the functionality of find-method. If so should this be renamed or at least exported under the name find-method? What you really want to call is get-method. One of the methods on get-method just calls real-get-method. Call get-method for now, it will be renamed to find-method shortly. ------- From Gregor.pa@Xerox.COM Thu Dec 8 18:44:11 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00349; Thu, 8 Dec 88 18:18:24 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 18:07:21 PST Date: Thu, 8 Dec 88 17:55 PST From: Gregor.pa@Xerox.COM Subject: Re: Bug in Low.lisp To: Arun Welch Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812082229.AA25193@tut.cis.ohio-state.edu> Message-Id: <19881209015517.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 8 Dec 88 17:29:43 EST From: Arun Welch The last lines in Low.lisp are: (defun record-definition (type spec &rest args) (declare ignore type spec args)) ()) On arisia, low.lisp already reads correctly. Perhaps there was a file transfer error to your site or something like that. and in fact, should the whole thing be there at all? Grepping the sources turns it up in a couple of the other -low files, is it just a place-holder (albeit mis-defined)? Some xxx-low files don't have definitions of this function. In those cases, the definition in low.lisp is used. This is the case with many of the other definitions in low.lisp as well. ------- From kiuchi.pa@Xerox.COM Thu Dec 8 19:10:12 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01303; Thu, 8 Dec 88 19:10:12 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 19:03:40 PST Date: 8 Dec 88 18:57 PST From: kiuchi.pa@Xerox.COM Subject: Re: Cute PCL in KCl In-Reply-To: eliot@winnie.Princeton.EDU (eliot handelman)'s message of Thu, 8 Dec 88 19:34:17 est To: eliot@winnie.Princeton.EDU (eliot handelman) Cc: commonloops.PA@Xerox.COM Message-Id: <881208-190340-5200@Xerox> 1. "make-keyword" in the turbo-closure patch had to be replaced with "make-ordinary" *features* patch in kcl-mods.text is for IBCL. The point is if you aren't using xkcl and you would like to have the turbo-closure patch, you need to add :TURBO-CLOSURE to the *feature* for KCL or IBCL. 2. I take it this time 'IBCL does NOT have to be pushed onto *features* Yes. 3. pkg.o didn't know about *exports* but did when I recompiled it (very mysterious) This is the only problem we have. You need to load "pkg.lisp" before loading "pkg.o" in KCL/IBCL. 4. KCl loads "init" on startup and so init.lsp had to be renamed You don't need to change extensions from lisp to lsp. You only need to put (defvar *pathname-extensions* '("lisp" . "o")) into your init.lsp file. 5. my KCl failed on the type of #(2,1) in the test file (an old KCl bug which has, I think, been fixed?) I think this is the bug in your KCL. In IBCL(10/15/1987) we don't have any fail in loading test.lisp. Yasuhiko Kiuchi (kiuchi.pa@Xerox.com) From Owners-commonloops.PA@Xerox.COM Fri Dec 9 12:25:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10537; Fri, 9 Dec 88 12:25:37 PST Received: from Burger.ms by ArpaGateway.ms ; 09 DEC 88 10:52:48 PST Return-Path: Redistributed: commonloops.PA Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 09 DEC 88 10:48:11 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA16857; Fri, 9 Dec 88 13:47:51 EST Date: Fri, 9 Dec 88 13:47:51 EST From: Arun Welch Message-Id: <8812091847.AA16857@tut.cis.ohio-state.edu> To: commonloops.PA@Xerox.COM Subject: Bringing up a new PCL Does anyone have any feel for what it takes to bring up PCL starting from a pure CL and the files on arisia as they stand now? In other words, if I had a CL, and wanted PCL/CLOS, how many man-months would it be to get it? How much is involved in tracking the moving CLOS target? ...arun From Owners-commonloops.pa@Xerox.COM Fri Dec 9 12:42:04 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10887; Fri, 9 Dec 88 12:42:04 PST Received: from Riesling.ms by ArpaGateway.ms ; 09 DEC 88 12:26:39 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 09 DEC 88 12:18:04 PST To: commonloops.pa@Xerox.COM Subject: A few questions on PCL Date: Fri, 09 Dec 88 15:13:29 -0500 From: Mike Thome Message-Id: <881209-122639-6834@Xerox> I've got a few questions for the "community" relating to pcl: 1) Cache mechanism - although I haven't yet looked at this part of the new version, I assume the new cache method ("mirror" lookup for 2nd chance before slowing WAY down) is used. How does this method differ (in efficiency) from the fairly standard "try the next cache location" algorithm in normal hash table theory? 2) Defmethod currently returns the method object of the method it just defined. Why doesn't it return the method's name (i.e. "(method foo (t))" my reasoning is to be like defun). 3) In an optimal PCL debugging environment, how much of the internals of pcl should be invisible to a baktrace? Should call-next-method appear? What about combined method objects or the generic function call itself? thanks, -mike thome (mthome@bbn.com) From Owners-commonloops.pa@Xerox.COM Fri Dec 9 12:47:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11019; Fri, 9 Dec 88 12:47:23 PST Received: from Salvador.ms by ArpaGateway.ms ; 09 DEC 88 12:35:55 PST Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 09 DEC 88 12:32:23 PST To: Giuseppe Attardi Cc: commonloops.pa@Xerox.COM Subject: Re: carwash simulator In-Reply-To: Your message of Thu, 01 Dec 88 18:50:48 +0100. <8812011750.AA08503@sparc.delphi> Date: Fri, 09 Dec 88 15:26:44 -0500 From: Mike Thome Message-Id: <881209-123555-6863@Xerox> (my face is red - I think) I'm not at all certain what happened, but it certainly looks as though the timings I published on the modified carwash program are VERY suspect-- I certainly have not been able to duplicate 'em since. As others have reported, a speedup of 30% seems pretty reasonable (and mostly unrelated to PCL performance). I'm not planning to wash any more cars... are you? -mike thome (mthome@bbn.com) From Owners-commonloops.PA@Xerox.COM Fri Dec 9 13:09:06 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11523; Fri, 9 Dec 88 13:09:06 PST Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 88 12:59:18 PST Return-Path: Redistributed: commonloops.PA Received: from Princeton.EDU ([10.7.0.96]) by Xerox.COM ; 09 DEC 88 12:55:59 PST Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/1.89) id AA03537; Fri, 9 Dec 88 15:55:59 EST Received: by winnie.Princeton.EDU (4.12/1.65) id AA12628; Fri, 9 Dec 88 15:55:39 est Date: Fri, 9 Dec 88 15:55:39 est From: eliot@winnie.Princeton.EDU.Princeton.EDU (eliot handelman) Message-Id: <8812092055.AA12628@winnie.Princeton.EDU> To: Gregor.pa@Xerox.COM Subject: Re: Cute PCL in KCl Cc: commonloops.PA@Xerox.COM >Date: Thu, 8 Dec 88 17:50 PST >From: Gregor.pa@Xerox.COM > >>Date: Thu, 8 Dec 88 19:34:17 est >>From: eliot@winnie.Princeton.EDU (eliot handelman) >> >>One other thing: is there some way to prevent PCl from compiling constructors, >>must they be compiled at all? > >I don't understand your problem here? When are constructors being >compiled when you don't want them to be? > >Constructors should only be compiled when the file containing the >defconstructor form is compiled. Constructors should not be compiled >when the file is loaded, when constructors are called, or class or >method definitions change. That seems reasonable. So what's going on here? > *features* (:PORTABLE-COMMONLOOPS :PCL COMPILER::BUGGY-CC VAX UNIX BSD COMMON KCL :TURBO-CLOSURE) > (defclass zit () (volume)) NIL > (defconstructor make-zit zit (v) :volume v) NIL > (setq a (make-zit 24)) End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 # ;; further calls to make-zit don't call the compiler > (setq b (make-zit 1200)) # -Eliot From Gregor.pa@Xerox.COM Fri Dec 9 13:32:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11660; Fri, 9 Dec 88 13:24:19 PST Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 13:22:56 PST Date: Fri, 9 Dec 88 13:19 PST From: Gregor.pa@Xerox.COM Subject: Re: Bringing up a new PCL To: Arun Welch Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8812091847.AA16857@tut.cis.ohio-state.edu> Message-Id: <19881209211918.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 9 Dec 88 13:47:51 EST From: Arun Welch Does anyone have any feel for what it takes to bring up PCL starting from a pure CL and the files on arisia as they stand now? In other words, if I had a CL, and wanted PCL/CLOS, how many man-months would it be to get it? It depends on the Common Lisp in question of course. Given a reasonably debugged Common Lisp I believe I can make a PCL port to it in under two days. If the Common Lisp has a lot of bugs, or is just generally slow, it could take longer of course. How much is involved in tracking the moving CLOS target? I am not sure I understand this question, so let me reword it and answer that question. Once I have this port of PCL, how much work will I have to do to maintain it as PCL evolves to conform to the standard? Very little. Maybe 1 or 2 weeks total. If on the other hand, you also want to take advantage of the changes that will be made to PCL to make it have higher performance that will take more work. Depending on how much of the performance you want to get, and depending on the architecture of your Lisp, this could take from 1 to 3 months. Then there is the time it would take to really retrofit PCL to be a super high performance CLOS implementation in your Lisp. I can't begin to estimate how much work that would take. ------- From Gregor.pa@Xerox.COM Fri Dec 9 14:13:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14486; Fri, 9 Dec 88 14:13:20 PST Received: from Semillon.ms by ArpaGateway.ms ; 09 DEC 88 14:11:52 PST Date: Fri, 9 Dec 88 14:07 PST From: Gregor.pa@Xerox.COM Subject: Re: A few questions on PCL To: Mike Thome Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 9 Dec 88 12:13 PST from Mike Thome Message-Id: <19881209220701.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 09 Dec 88 15:13:29 -0500 From: Mike Thome I've got a few questions for the "community" relating to pcl: 1) Cache mechanism - although I haven't yet looked at this part of the new version, I assume the new cache method ("mirror" lookup for 2nd chance before slowing WAY down) is used. How does this method differ (in efficiency) from the fairly standard "try the next cache location" algorithm in normal hash table theory? Its hard to tell. There are some conjectures that the mirror location is better because the next location might be occupied by the class that was created immediately after the current class. Computing the mirror probably doesn't take any longer, so in secondary hit case, this scheme is just as fast. It is easy to write a tool that takes a snapshot of a running program and statically compares these two techniques. I wrote such a hacked up tool and it suggested that the mirror was slightly better than the next. I certainly wouldn't want to make that as a justified claim without making more careful measurements with a large program base. For one thing, a lot of it depends on how the class numbers are generated. 2) Defmethod currently returns the method object of the method it just defined. Why doesn't it return the method's name (i.e. "(method foo (t))" my reasoning is to be like defun). Two reasons, one important and one very important. - important, this is what the spec says - very important, methods don't have names. Generic functions have names. We worked real hard in CLOS to try to separate names from the actual program objects. One step in that is to eliminate gratuitous names, like names for methods. 3) In an optimal PCL debugging environment, how much of the internals of pcl should be invisible to a baktrace? Should call-next-method appear? What about combined method objects or the generic function call itself? I personally expect there will be a lot of interesting design here. I would think that call-next-method should definitely be visible. I would think the generic function call should be visible. Probably something to indicate the effective method should be visible as well. Of course all of these should be handled better than they are in most PCL ports. Stan Lanning's PCL port to Envos Medley handles all of these pretty well. It displays the actual generic function and method objects on the stack. This is another example of the kind of thing you need to do if you want to attain a clean separation between names and program objects. The advantage to Stan's scheme is that if you have an anymous generic function and some methods on it, and you wind up in the debugger, the debugger handles them gracefully. ------- From Owners-commonloops.pa@Xerox.COM Sat Dec 10 15:18:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA28396; Sat, 10 Dec 88 15:18:58 PST Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 88 11:37:33 PST Return-Path: Redistributed: commonloops.pa Received: from A.GP.CS.CMU.EDU ([128.2.242.7]) by Xerox.COM ; 10 DEC 88 11:35:05 PST Date: Sat, 10 Dec 88 14:33:52 EST From: Christopher.McConnell@A.GP.CS.CMU.EDU To: commonloops.pa@Xerox.COM Subject: Temporary work arounds for defgeneric and defstruct specializers Message-Id: <881210-113733-2434@Xerox> Here are two work arounds that I have been using for a while. The first defines a defgeneric that does the simple things like generate setf methods and the generic function. No guarantee is made that it does everything. The second work around allows you to write methods that specialize on defstructs. It is portable except for determining the super-type of a structure. Fill in your super-type at #+lucid. There are some problems with the workaround. It causes the wrapper functions to get recompiled the first time they are used after defining a structure. It also potentially slows down dispatch since the extra tests for the structures are included in the wrappers. Anyway, if you really need to write defstruct specializers, it works. It might also be a good idea to use a special macro rather than redefining defstruct, but at least this way you don't have to think about it! ;;; -*- Mode: LISP; Package: pcl; Syntax: Common-lisp; Base: 10.; -*- ;;;%Header ;;;---------------------------------------------------------------------------- ;;; ;;; CLOS extensions ;;; ;;; Author: Chris McConnell ;;; (in-package 'pcl) (export '(defgeneric)) ;;; ;;; NOTE: Define defgeneric until it really exists... (defmacro DEFGENERIC (name lambda-list &rest options) `(progn ,(when (listp name) `(do-standard-defsetf-1 ',(second name))) (pcl::ensure-generic-function ',name :lambda-list ',lambda-list ,@(let ((new nil)) (dolist (option options new) (dolist (part (reverse option)) (push part new))))))) ;;; ;;; This whole set of hair is based on PCL's high.lisp. Some day, it will be ;;; built into defstruct. It allows you to define defstructs without ;;; much penalty, but the first time you call a generic function, it ;;; rebuilds the type wrappers, so it can take a while. ;;; (defun make-built-in-class-subs () (mapcar #'(lambda (e) (let ((class (car e)) (class-subs ())) (dolist (s *built-in-classes*) (when (memq class (cadr s)) (pushnew (car s) class-subs))) (cons class class-subs))) (cons '(t) *built-in-classes*))) (defun make-built-in-class-tree () (let ((subs (make-built-in-class-subs))) (labels ((descend (class) (cons class (mapcar #'descend (cdr (assq class subs)))))) (descend 't)))) (defun make-built-in-wrapper-of-body () (make-built-in-wrapper-of-body-1 (make-built-in-class-tree) 'x #'get-built-in-wrapper-symbol)) (defun make-built-in-class-of-body () (make-built-in-wrapper-of-body-1 (make-built-in-class-tree) 'x #'get-built-in-class-symbol)) (defun make-built-in-wrapper-of-body-1 (tree var get-symbol) (let ((*specials* ())) (declare (special *specials*)) (let ((inner (make-built-in-wrapper-of-body-2 tree var get-symbol))) `(locally (declare (special .,*specials*)) ,inner)))) (defun make-built-in-wrapper-of-body-2 (tree var get-symbol) (declare (special *specials*)) (let ((symbol (funcall get-symbol (car tree)))) (push symbol *specials*) (let ((sub-tests (mapcar #'(lambda (x) (make-built-in-wrapper-of-body-2 x var get-symbol)) (cdr tree)))) `(and (typep ,var ',(car tree)) ,(if sub-tests `(or ,.sub-tests ,symbol) symbol))))) ;;; (defun DEFINE-BUILT-IN-CLASS (name supers) "Define a new built in CLOS class. Typically for structures." (let ((proto (class-prototype (find-class 'built-in-class)))) (add-named-class proto name supers () ()) (let ((class-symbol (get-built-in-class-symbol name)) (wrapper-symbol (get-built-in-wrapper-symbol name)) (class (find-class name)) (cell (or (assoc name *built-in-classes*) (first (push (list name) *built-in-classes*))))) (set class-symbol class) (set wrapper-symbol (class-wrapper class)) ;; This is a funky trick to rebuild the wrappers, next time they are ;; referenced. (rplacd cell (list supers)) (setf (symbol-function 'built-in-wrapper-of) #'(lambda (x) (setf (symbol-function 'built-in-wrapper-of) (compile nil `(lambda (x) ,(make-built-in-wrapper-of-body)))) (built-in-wrapper-of x)) (symbol-function 'built-in-class-of) #'(lambda (x) (setf (symbol-function 'built-in-class-of) (compile nil `(lambda (x) ,(make-built-in-class-of-body)))) (built-in-class-of x)))))) ;;; ;;; Redefine the LISP defstruct macro so that structures are ;;; automatically added to the built-in-class lattice. This is a very ;;; simple minded implementation that does not handle changing the ;;; inheritance of defstructs. ;;; (eval-when (compile load eval) (unless (macro-function 'old-defstruct) (setf (macro-function 'old-defstruct) (macro-function 'defstruct)))) (defmacro DEFSTRUCT (name-and-options &rest body) (let* ((include (when (listp name-and-options) (second (assoc :include (cdr name-and-options))))) (supertype (or include #+lucid t)) (name (if (listp name-and-options) (first name-and-options) name-and-options))) `(eval-when (compile load eval) (define-built-in-class ',name '(,supertype)) (old-defstruct ,name-and-options ,@body)))) From Owners-commonloops.PA@Xerox.COM Sat Dec 10 20:22:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00368; Sat, 10 Dec 88 20:22:26 PST Received: from Salvador.ms by ArpaGateway.ms ; 10 DEC 88 18:26:29 PST Return-Path: Redistributed: commonloops.PA Received: from Princeton.EDU ([10.7.0.96]) by Xerox.COM ; 10 DEC 88 18:24:31 PST Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/1.89) id AA07271; Sat, 10 Dec 88 21:24:42 EST Received: by winnie.Princeton.EDU (4.12/1.65) id AA19636; Sat, 10 Dec 88 21:24:24 est Date: Sat, 10 Dec 88 21:24:24 est From: eliot@winnie.Princeton.EDU.Princeton.EDU (eliot handelman) Message-Id: <8812110224.AA19636@winnie.Princeton.EDU> To: commonloops.PA@Xerox.COM Subject: Bugged new-defmacro for KCl Calling member on a list whose last cons is a dotted pair causes an error in KCl, so the definition of new-defmacro in kcl-patches.lsp makes those kinds of lambda-lists for macros impossible. Here's my stupid little fix. (Actually the same problem occurs for find, butlast etc. Has anyone fixed KCl so that this doesn't happen?) (defun new-defmacro (form env) (let ((defmacro (car form)) (name (cadr form)) (ll (caddr form)) ;;params (body (cdddr form)) (&env nil)) (cond ((not (and (eq defmacro 'defmacro) (symbolp name) *** (null (cdr (last ll))) (listp ll))) ;; Something is wrong, but we'll pass the whole thing off ;; to the real defmacro and let it detect the error and ;; complain about it in its own way. (funcall *defmacro* form env)) [...] -Eliot From Owners-CommonLoops.pa@Xerox.COM Sun Dec 11 22:42:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10427; Sun, 11 Dec 88 22:42:02 PST Received: from Salvador.ms by ArpaGateway.ms ; 11 DEC 88 22:40:01 PST Return-Path: Redistributed: CommonLoops.pa Received: from uc.msc.umn.edu ([192.12.250.2]) by Xerox.COM ; 11 DEC 88 22:38:31 PST Received: from rohini.telecomm.umn.edu by uc.msc.umn.edu (5.59/1.14) id AA15554; Mon, 12 Dec 88 00:35:23 CDT Received: from umn-cs.cs.umn.edu by rohini.telecomm.umn.edu; Mon, 12 Dec 88 00:39:22 CST Date: Mon, 12 Dec 88 00:40:10 CST From: "Vijay Rajan" Message-Id: <8812120640.AA27076@umn-cs.cs.umn.edu> Received: by umn-cs.cs.umn.edu; Mon, 12 Dec 88 00:40:10 CST To: CommonLoops.pa@Xerox.COM Subject: PCL Dear sir, I obtained a copy of the PCL software using anonymous ftp from arisia.xerox.com. on 11th dec. As requested in the documentation I would like to inform you of this, and will also mail any bug-reports or suggestions for improvement to the same address. My address is jayrajan@umn-cs.cs.umn.edu Thanking You, -Vijay Rajan From Owners-commonloops.pa@Xerox.COM Mon Dec 12 08:34:03 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15209; Mon, 12 Dec 88 08:34:03 PST Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 08:32:02 PST Return-Path: Redistributed: commonloops.pa Received: from cs.columbia.edu ([128.59.16.20]) by Xerox.COM ; 12 DEC 88 08:28:31 PST Received: by cs.columbia.edu (5.59++/0.1) id AA20406; Mon, 12 Dec 88 11:28:26 EST Date: Mon, 12 Dec 88 11:28:25 EST From: Michael van Biema To: Gregor.pa@Xerox.COM Cc: Mike Thome , commonloops.pa@Xerox.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Fri, 9 Dec 88 14:07 PST Message-Id: Another perhaps even more important reason that the method as opposed to the name should be return when a method is created is that: a method IS an object and should behave like one! Michael From Owners-commonloops.pa@Xerox.COM Mon Dec 12 10:38:42 1988 Received: from [13.0.12.232] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16840; Mon, 12 Dec 88 10:38:42 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 12 DEC 88 10:33:24 PST Return-Path: Redistributed: commonloops.pa Received: from cs.columbia.edu ([128.59.16.20]) by Xerox.COM ; 12 DEC 88 10:24:16 PST Received: by cs.columbia.edu (5.59++/0.1) id AA23557; Mon, 12 Dec 88 13:24:08 EST Date: Mon, 12 Dec 88 13:24:07 EST From: Michael van Biema To: commonloops.pa@Xerox.COM Subject: Are the various "benchmark" programs available Message-Id: somewhere? If not why don't we make a place so everybody can share in the fun! Michael From Owners-commonloops.PA@Xerox.COM Mon Dec 12 14:43:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21665; Mon, 12 Dec 88 14:43:31 PST Received: from Salvador.ms by ArpaGateway.ms ; 12 DEC 88 12:33:15 PST Return-Path: Redistributed: commonloops.PA Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 12 DEC 88 12:30:15 PST Received: from steinmetz.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA28673; Mon, 12 Dec 88 15:30:03 EST Received: from eraserhead.steinmetz.GE.COM (eraserhead.ARPA) by kbsvax.steinmetz (1.2/1.1x Steinmetz) id AA03393; Mon, 12 Dec 88 15:28:12 est Received: by eraserhead.steinmetz.GE.COM (4.0/SMI-4.0) id AA05963; Mon, 12 Dec 88 15:25:09 EST Date: Mon, 12 Dec 88 15:25:09 EST From: duff%eraserhead%steinmetz@uunet.UU.NET (David A Duff) Message-Id: <8812122025.AA05963@eraserhead.steinmetz.GE.COM> To: kempf@sun.com, CommonLoops.PA@Xerox.COM Reply-To: duff@eraserhead.steinmetz.Ge.Com Subject: Re: generic-function-pretty-arglist Newsgroups: mail.clos In-Reply-To: <6238@vdsvax.steinmetz.ge.com> Organization: GE Corporate Research and Development, Schenectady, NY [Re: getting an error in a call to generic-function-pretty-arglist] I have encountered the same problem. I fixed it, but since I hadn't been getting pcl mail in a while, I didn't bother reporting it -- I figured someone would have fixed and reported it by now. Anyway, the problem is in the file methods.lisp in the function generic-function-pretty-arglist. Here is the patched 8/24 version. I haven't had a chance to get the new version yet, so I don't know if this change is compatible. I think it probably is. To patch an existing pcl: just re-evaluate this new definition. There don't seem to be any serious side-effects. (defmethod generic-function-pretty-arglist ((generic-function standard-generic-function)) (let ((methods (generic-function-methods generic-function)) (arglist ())) (when methods (multiple-value-bind (required optional rest key allow-other-keys) (method-pretty-arglist (car methods)) (dolist (m (cdr methods)) (multiple-value-bind (method-key method-allow-other-keys) (method-pretty-arglist-1 m) (setq key (union key method-key)) (setq allow-other-keys (or allow-other-keys method-allow-other-keys)))) (when allow-other-keys (setq arglist '(&allow-other-keys))) (when key (setq arglist (nconc (list '&key) key arglist))) ;; I made a small patch here. This bug was making lucid's debugger ;; ill. d.d. 10/26/88 ;(when rest ; (setq arglist (nconc (list '&rest) rest arglist))) (when rest (setq arglist (nconc (list '&rest rest) arglist))) (when optional (setq arglist (nconc (list '&optional) optional arglist))) (nconc required arglist))))) -- Dave Duff GE Research and Development Center duff@eraserhead.steinmetz.ge.com Schenectady, New York uunet!steinmetz!eraserhead!duff 518-387-5649 From Will_Snow.AISNorth@Xerox.COM Mon Dec 12 14:50:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21832; Mon, 12 Dec 88 14:50:53 PST Received: from Riesling.ms by ArpaGateway.ms ; 12 DEC 88 14:21:08 PST Sender: "Will_Snow.AISNorth"@Xerox.COM Date: 12 Dec 88 14:17:38 PST (Monday) Subject: Re: How to get CLOS Workshop proceedings? From: "Will_Snow.AISNorth"@Xerox.COM To: lgm@ihlpf.UUCP Cc: commonloops.PA@Xerox.COM In-Reply-To: lgm%ihlpf:UUCP:Xerox's message of 8 Dec 88 09:33 Message-Id: <881212-142108-5180@Xerox> Envos now sells the PCL documentation separately. Contact Lucy Isbell Envos Corporation (415) 966 - 6200 --will snow Envos Corp. From Owners-commonloops.PA@Xerox.COM Mon Dec 12 15:46:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22462; Mon, 12 Dec 88 15:46:02 PST Received: from Burger.ms by ArpaGateway.ms ; 12 DEC 88 15:42:26 PST Return-Path: Redistributed: commonloops.PA Received: from gabriell ([18.43.0.156]) by Xerox.COM ; 12 DEC 88 15:41:07 PST Received: by BADEN.AI.MIT.EDU; Mon, 12 Dec 88 18:48:55 est Date: Mon, 12 Dec 88 18:48:55 est From: stone@BADEN.AI.MIT.EDU (David Goldstone) Message-Id: <8812122348.AA20614@gabriell> To: "Will_Snow.AISNorth"@Xerox.COM Cc: lgm%ihlpf@BADEN.AI.MIT.EDU, commonloops.PA@Xerox.COM In-Reply-To: "Will_Snow.AISNorth"@xerox.com's message of 12 Dec 88 14:17:38 PST (Monday) <881212-142108-5180@Xerox> Subject: How to get CLOS Workshop proceedings? Reply-To: stone@wheaties.ai.mit.edu Zippy-Says: I am a traffic light, and Alan Ginzberg kidnapped my laundry in 1927! Sender: "Will_Snow.AISNorth"@xerox.com Date: 12 Dec 88 14:17:38 PST (Monday) From: "Will_Snow.AISNorth"@xerox.com Envos now sells the PCL documentation separately. Contact Lucy Isbell Envos Corporation (415) 966 - 6200 --will snow Envos Corp. Perhaps this has been noticed before, but when I read these lines, I read them as critical commentary "Envos will snow"... or something like that... meaning "Envos will try a snow job" or something... later stone From Owners-CommonLoops.pa@Xerox.COM Tue Dec 13 14:07:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07777; Tue, 13 Dec 88 14:07:33 PST Received: from Riesling.ms by ArpaGateway.ms ; 13 DEC 88 12:09:44 PST Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 13 DEC 88 12:07:23 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: carwash PCL/Flavors comparison Date: Tue, 13 Dec 88 15:09:42 -0500 From: kanderso@PEBBLES.BBN.COM Message-Id: <881213-120944-7720@Xerox> I converted Mike Thome's version of the carwash demo into Flavors. Here are some timing results: 8/28 12/7 CARS PCL PCL Flavors pcl/flavors 20 .715 .659 .291 2.26 50 2.24 2.19 .934 2.34 100 7.36 7.24 4.17 1.76 Notes: 0. These times were the median of the last 3 of 4 times generated using: (progn (generate-cars N) (scl:without-interrupts (dotimes (i 4) (time (get-going))))) 1. Here, newest PCL is faster than the old one by about 8 - 10%! 2. Here, Flavors is about 2.3 times faster than PCL. My conversion relys on dispatch only being done on the first argument, although some PCL methods are defined on 2 arguments. This demo only tests method and accessor use, which is reasonable, but not the only things to compare. 3. The carwash has a distinct N squared behavior, so for large N the PCL/Flavors performance is less important. Rewriting the simulation to use queues rather than nconcing lists, should reduce this. 4. This are the machine parameters: Symbolics System, FEP1:>enhanced-pci-from-pci.load.1 3640 Processor, 1536K words Physical memory, 21250K words Swapping space. Genera 7.2 BBN Rhythm & Blues 5. Here is the flavor conversion code: ;;; Just enough to get carwash converted to FLAVORS. (in-package 'car :use '(lisp)) (shadowing-import '(flavor::self) 'car) (import '(flavor::make-instance) 'car) (defmacro defclass (name supers slots) `(flavor::defflavor ,name ,(map 'list #'(lambda (s) (list (first s) (getf (cdr s) :initform))) slots) ,supers (:conc-name nil) :writable-instance-variables :readable-instance-variables :initable-instance-variables)) (defmacro defmethod (name args &body body) (let ((class (second (first args))) (me (first (first args)))) (setq args (map 'list #'(lambda (a) (if (consp a) (first a) a)) (cdr args))) `(flavor::defmethod (,name ,class) ,args (let ((,me self)) ,@body)))) From Owners-CommonLoops.pa@Xerox.COM Tue Dec 13 18:16:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07777; Tue, 13 Dec 88 14:07:33 PST Received: from Riesling.ms by ArpaGateway.ms ; 13 DEC 88 12:09:44 PST Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 13 DEC 88 12:07:23 PST To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: carwash PCL/Flavors comparison Date: Tue, 13 Dec 88 15:09:42 -0500 From: kanderso@PEBBLES.BBN.COM Message-Id: <881213-120944-7720@Xerox> I converted Mike Thome's version of the carwash demo into Flavors. Here are some timing results: 8/28 12/7 CARS PCL PCL Flavors pcl/flavors 20 .715 .659 .291 2.26 50 2.24 2.19 .934 2.34 100 7.36 7.24 4.17 1.76 Notes: 0. These times were the median of the last 3 of 4 times generated using: (progn (generate-cars N) (scl:without-interrupts (dotimes (i 4) (time (get-going))))) 1. Here, newest PCL is faster than the old one by about 8 - 10%! 2. Here, Flavors is about 2.3 times faster than PCL. My conversion relys on dispatch only being done on the first argument, although some PCL methods are defined on 2 arguments. This demo only tests method and accessor use, which is reasonable, but not the only things to compare. 3. The carwash has a distinct N squared behavior, so for large N the PCL/Flavors performance is less important. Rewriting the simulation to use queues rather than nconcing lists, should reduce this. 4. This are the machine parameters: Symbolics System, FEP1:>enhanced-pci-from-pci.load.1 3640 Processor, 1536K words Physical memory, 21250K words Swapping space. Genera 7.2 BBN Rhythm & Blues 5. Here is the flavor conversion code: ;;; Just enough to get carwash converted to FLAVORS. (in-package 'car :use '(lisp)) (shadowing-import '(flavor::self) 'car) (import '(flavor::make-instance) 'car) (defmacro defclass (name supers slots) `(flavor::defflavor ,name ,(map 'list #'(lambda (s) (list (first s) (getf (cdr s) :initform))) slots) ,supers (:conc-name nil) :writable-instance-variables :readable-instance-variables :initable-instance-variables)) (defmacro defmethod (name args &body body) (let ((class (second (first args))) (me (first (first args)))) (setq args (map 'list #'(lambda (a) (if (consp a) (first a) a)) (cdr args))) `(flavor::defmethod (,name ,class) ,args (let ((,me self)) ,@body)))) From Owners-commonloops.pa@Xerox.COM Tue Dec 13 19:16:02 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11056; Tue, 13 Dec 88 18:53:17 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 13 DEC 88 18:51:30 PST Return-Path: Redistributed: commonloops.pa Received: from WILMA.BBN.COM ([128.89.1.216]) by Xerox.COM ; 13 DEC 88 18:47:40 PST To: Mike Thome Cc: commonloops.pa@Xerox.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Fri, 09 Dec 88 15:13:29 -0500. <881209-122639-6834@Xerox> Date: Tue, 13 Dec 88 21:41:18 -0500 From: kanderso@WILMA.BBN.COM Message-Id: <881213-185130-8705@Xerox> To: commonloops.pa@Xerox.COM Subject: A few questions on PCL Date: Fri, 09 Dec 88 15:13:29 -0500 From: Mike Thome Message-Id: <881209-122639-6834@Xerox> I've got a few questions for the "community" relating to pcl: 1) Cache mechanism - although I haven't yet looked at this part of the new version, I assume the new cache method ("mirror" lookup for 2nd chance before slowing WAY down) is used. How does this method differ (in efficiency) from the fairly standard "try the next cache location" algorithm in normal hash table theory? Trying the next cache location tends to lead to chains of filled hash locations as the table fills up. This is because if location I is filled than there is a good chance I+1 is filled too, because some nearby slot has overflowed. I believe i can find a paper on this somewhere in the early CACM's. I believe that the same argument holds for "mirror" lookup, which if i remember Gregor's description,is that if location I is filled, look at L - I, where L is the length of the table. This is just a permutation of the above idea. However, Gregor adds a twist that if the mirror position is full, rather than looking at a nearby position or the mirror of a nearby position, search linearly from the start of the table for a free spot. Now this linear search is even worse than the one above, but it only occurs in the unlikely(?) event that the previous 2 slots are full. A better way might be to compute the second slot to try as a pseudo random function of the key, which would tend to distinquish things that have the same hash address. Symbolics simply grows their hash tables whenever the going gets tough, and if you do this you can tolerate a fairly poor secondary hashing scheme. Of course, trading space for time on a paging machine may not be the best thing either which is probably why Gregor never grew the caches before. Data, simulated or actual would clearly help here. k From Owners-CommonLoops.pa@Xerox.COM Wed Dec 14 01:57:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16501; Wed, 14 Dec 88 01:57:41 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 14 DEC 88 01:56:29 PST Return-Path: Redistributed: CommonLoops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 14 DEC 88 01:53:46 PST Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA24243; Wed, 14 Dec 88 04:53:33 EST Received: by mcvax.cwi.nl via EUnet; Tue, 13 Dec 88 17:47:44 +0100 (MET) Received: by inria.inria.fr via Fnet-EUnet; Tue, 13 Dec 88 16:33:19 +0100 (MET) Received: from magnon.laas.fr (magnon.ARPA) by laas.laas.fr, Tue, 13 Dec 88 16:31:40 -0100 Received: by magnon.laas.fr, Tue, 13 Dec 88 16:29:50 +0100 Received: by lasso.laas.fr (5.51/5.17) id AA10294; Tue, 13 Dec 88 14:38:52 +0100 Date: Tue, 13 Dec 88 14:38:52 +0100 From: ralph%lasso%mcvax@uunet.UU.NET (Ralph P. Sobek) Message-Id: <8812131338.AA10294@lasso.laas.fr> To: CommonLoops.pa@Xerox.COM, kiuchi.pa@Xerox.COM Subject: Re: new version of PCL (12/7/88) Cc: Felix@AI.SRI.COM Keywords: Context diffs, Non-technical | There is a new version of PCL on arisia.xerox.com. | | The *pcl-system-date* for this version is 12/7/88. It's great to hear that the progress on pcl/CLOS continues! Unfortunately, just before getting your message someone kindly sent me the AAAI-88 beta release version. My first question: is this a major release like the 8/24/88 version? If so, is it possible or worthwhile to make available context diffs (a la Unix) so that we could upgrade to the new version? I assume that this solution would be attractive to all, even through FTP, who have Unix machines. Of course, the importance is what percent smaller a context-diff would be compared to a full release! As a starter, I compared the St. Patricks and AAAI versions. The compressed diffs occupied 52% of the AAAI size (also compressed). Excuse me for diverting attention from the more technical questions. Ralph P. Sobek | UUCP: uunet!mcvax!inria!lasso!ralph, or | ralph@lasso.uucp LAAS-CNRS | Internet: ralph@laas.laas.fr, or 7, avenue du Colonel-Roche | ralph%laas.laas.fr@uunet.UU.NET F-31077 Toulouse Cedex, FRANCE | ARPA: sobek@eclair.Berkeley.EDU (forwarded\ +(33) 61-33-62-66 | BITNET/EARN: SOBEK@FRMOP11 \ to UUCP ) From Owners-commonloops.pa@Xerox.COM Wed Dec 14 07:55:32 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18430; Wed, 14 Dec 88 07:55:32 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 14 DEC 88 07:54:14 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 14 DEC 88 07:50:32 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA25866; Wed, 14 Dec 88 07:53:09 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA22093; Wed, 14 Dec 88 07:49:49 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA04611; Wed, 14 Dec 88 07:50:23 PST Message-Id: <8812141550.AA04611@suntana.sun.com> To: kanderso@PEBBLES.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@PEBBLES.BBN.COM Subject: Re: carwash PCL/Flavors comparison In-Reply-To: Your message of Tue, 13 Dec 88 15:09:42 -0500. <881213-120944-7720@Xerox> Date: Wed, 14 Dec 88 07:50:18 PST From: kempf@Sun.COM I have not tried the carwash demo, but some benchmarks we have run comparing Flavors and PCL on Sun Common Lisp 2.1 indicate PCL is faster by about the same margin you indicated Flavors was on the Symbolics. If there is interest, I can look into posting the results. I suspect that the same would be true for other standard hardware implementations of Flavors and PCL. jak From Owners-commonloops.pa@Xerox.COM Wed Dec 14 10:07:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19434; Wed, 14 Dec 88 10:07:25 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 14 DEC 88 09:13:23 PST Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 14 DEC 88 09:10:28 PST Received: by paris.Berkeley.EDU (5.57/1.25) id AA04313; Wed, 14 Dec 88 09:09:01 PST From: larus@paris.berkeley.edu (James Larus) Message-Id: <8812141709.AA04313@paris.Berkeley.EDU> To: kanderso@wilma.bbn.com Cc: Mike Thome , commonloops.pa@Xerox.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Tue, 13 Dec 88 21:41:18 EST. <881213-185130-8705@Xerox> Reply-To: larus@ginger.Berkeley.EDU Date: Wed, 14 Dec 88 09:08:53 PST I will second Ken's observation that the new version of PCL is only a bit (~5-10%) faster than the old one. Gregor tells me that it can be tuned, but an new hash function might also help. The biggest performance improvement that I got came from using DEFCONSTRUCTOR (in the file construct.lisp) instead of the crufty MAKE-INSTANCE protocol. By changing entirely to DEFCONSTRUCTOR, I speed up Curare by 25%. One warning though. DEFCONSTRUCTUR is much closer to the CLOS semantics than the old MAKE-INSTANCE, but it does not do much error checking. In particular, you need to provide an :INITARG declaration for each field that you specify in DEFCONSTRUCTOR. If you don't, then the fields are silently not initialized. There is lot of published work on non-chained hashing schemes. Unfortunaely, I'm too busy and lazy to look it up. However, there is one scheme that I remember from a compiler class that should work well here. It is called quadratic linear rehashing. Assume we want a hash value between 0 and S. Let H be the initial hash value computed from the object. Then compute the sequence of hash values: H_i = (H + i*i) mod S If S is prime, then this scheme tends to spread the hash probes over the entire table (note the resemblence to pseudo-random number generators). Of course, this is an expensive operation on machines without hardware fixnum multiple and divide operations (do people run Lisp on such machines?). /Jim From Owners-commonloops.pa@Xerox.COM Wed Dec 14 10:20:56 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19862; Wed, 14 Dec 88 10:20:56 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 DEC 88 10:04:37 PST Return-Path: Redistributed: commonloops.pa Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 14 DEC 88 10:01:37 PST Received: from a-boy.media.mit.edu by media-lab.media.mit.edu (5.59/4.8) id AA29910; Wed, 14 Dec 88 11:28:38 EST Received: by a-boy (3.2/4.8) id AA07089; Wed, 14 Dec 88 11:29:02 EST Date: Wed, 14 Dec 88 11:29:02 EST From: Michael Sokolov Message-Id: <8812141629.AA07089@a-boy> To: commonloops.pa@Xerox.COM Subject: goodbye Please remove me from this mailing list. Sorry for the global distribution. Thanks, Mike Sokolov From Owners-commonloops.pa@Xerox.COM Wed Dec 14 10:45:34 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19287; Wed, 14 Dec 88 10:02:29 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 14 DEC 88 09:15:56 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 14 DEC 88 09:13:17 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09227g; Wed, 14 Dec 88 09:10:31 PST Received: by bhopal id AA14127g; Wed, 14 Dec 88 09:12:30 PST Date: Wed, 14 Dec 88 09:12:30 PST From: Jim McDonald Message-Id: <8812141712.AA14127@bhopal> To: kanderso@WILMA.BBN.COM Cc: mthome@vax.bbn.com, commonloops.pa@Xerox.COM In-Reply-To: kanderso@WILMA.BBN.COM's message of Tue, 13 Dec 88 21:41:18 -0500 <881213-185130-8705@Xerox> Subject: A few questions on PCL Knuth has a fairly detailed chapter on hashing in Vol. 3 of The Art of Computer Programming. The bottom line is that double hashing is preferable to using any kind of fixed offset or mirror location, etc. (Use one hash function for the initial probe, then another that produces a psuedo-random increment for successive probes which is relatively prime to the size of the table.) A further modification reorders the hash table after unsuccessful probes in manner reminiscent of balancing n-ary trees. Knuth calls this "Brent's variation of Algorithm D". See the charts on pages 524 and 539. jlm From Bobrow.pa@Xerox.COM Wed Dec 14 13:50:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24546; Wed, 14 Dec 88 13:50:46 PST Received: from Semillon.ms by ArpaGateway.ms ; 14 DEC 88 13:49:00 PST Date: 14 Dec 88 13:44 PST From: Danny Bobrow Subject: Re: A few questions on PCL In-Reply-To: Jim McDonald 's message of Wed, 14 Dec 88 09:12:30 PST To: Jim McDonald Cc: kanderso@WILMA.BBN.COM, mthome@vax.bbn.com, commonloops.pa@Xerox.COM Message-Id: <881214-134900-10388@Xerox> Knuth has a fairly detailed chapter on hashing in Vol. 3 of The Art of Computer Programming. The bottom line is that double hashing is preferable to using any kind of fixed offset or mirror location, etc. (Use one hash function for the initial probe, then another that produces a psuedo-random increment for successive probes which is relatively prime to the size of the table.) We chose the mirror lookup position to minimize the time to find the secondary hash location (+1 would have done that as well). The linear lookup after the two direct probes starts from a fixed end of the table. The mirror position ensures that the two probe positions are at opposite ends of the table. A further modification reorders the hash table after unsuccessful probes in manner reminiscent of balancing n-ary trees. Knuth calls this "Brent's variation of Algorithm D". Our algorithm is like Brent's variation in that it reorders the hash table to make repeated uses of the same probe faster. See the charts on pages 524 and 539. We expect that our algorithm will be much like Brent's in behavior; with a policy of growing the tables when they get relatively full, we hop to keep successful lookup time close to optimal, minimizing raw instructions to do a successful cache lookup, and maximizing the chance of a successful hit on the first two probes. From Owners-commonloops.pa@Xerox.COM Wed Dec 14 14:55:34 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19434; Wed, 14 Dec 88 10:07:25 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 14 DEC 88 09:13:23 PST Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 14 DEC 88 09:10:28 PST Received: by paris.Berkeley.EDU (5.57/1.25) id AA04313; Wed, 14 Dec 88 09:09:01 PST From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8812141709.AA04313@paris.Berkeley.EDU> To: kanderso@wilma.bbn.com Cc: Mike Thome , commonloops.pa@Xerox.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Tue, 13 Dec 88 21:41:18 EST. <881213-185130-8705@Xerox> Reply-To: larus@ginger.Berkeley.EDU Date: Wed, 14 Dec 88 09:08:53 PST I will second Ken's observation that the new version of PCL is only a bit (~5-10%) faster than the old one. Gregor tells me that it can be tuned, but an new hash function might also help. The biggest performance improvement that I got came from using DEFCONSTRUCTOR (in the file construct.lisp) instead of the crufty MAKE-INSTANCE protocol. By changing entirely to DEFCONSTRUCTOR, I speed up Curare by 25%. One warning though. DEFCONSTRUCTUR is much closer to the CLOS semantics than the old MAKE-INSTANCE, but it does not do much error checking. In particular, you need to provide an :INITARG declaration for each field that you specify in DEFCONSTRUCTOR. If you don't, then the fields are silently not initialized. There is lot of published work on non-chained hashing schemes. Unfortunaely, I'm too busy and lazy to look it up. However, there is one scheme that I remember from a compiler class that should work well here. It is called quadratic linear rehashing. Assume we want a hash value between 0 and S. Let H be the initial hash value computed from the object. Then compute the sequence of hash values: H_i = (H + i*i) mod S If S is prime, then this scheme tends to spread the hash probes over the entire table (note the resemblence to pseudo-random number generators). Of course, this is an expensive operation on machines without hardware fixnum multiple and divide operations (do people run Lisp on such machines?). /Jim From Bobrow.pa@Xerox.COM Wed Dec 14 15:26:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA24546; Wed, 14 Dec 88 13:50:46 PST Received: from Semillon.ms by ArpaGateway.ms ; 14 DEC 88 13:49:00 PST Date: 14 Dec 88 13:44 PST From: Danny Bobrow Subject: Re: A few questions on PCL In-Reply-To: Jim McDonald 's message of Wed, 14 Dec 88 09:12:30 PST To: Jim McDonald Cc: kanderso@WILMA.BBN.COM, mthome@vax.bbn.com, commonloops.pa@Xerox.COM Message-Id: <881214-134900-10388@Xerox> Knuth has a fairly detailed chapter on hashing in Vol. 3 of The Art of Computer Programming. The bottom line is that double hashing is preferable to using any kind of fixed offset or mirror location, etc. (Use one hash function for the initial probe, then another that produces a psuedo-random increment for successive probes which is relatively prime to the size of the table.) We chose the mirror lookup position to minimize the time to find the secondary hash location (+1 would have done that as well). The linear lookup after the two direct probes starts from a fixed end of the table. The mirror position ensures that the two probe positions are at opposite ends of the table. A further modification reorders the hash table after unsuccessful probes in manner reminiscent of balancing n-ary trees. Knuth calls this "Brent's variation of Algorithm D". Our algorithm is like Brent's variation in that it reorders the hash table to make repeated uses of the same probe faster. See the charts on pages 524 and 539. We expect that our algorithm will be much like Brent's in behavior; with a policy of growing the tables when they get relatively full, we hop to keep successful lookup time close to optimal, minimizing raw instructions to do a successful cache lookup, and maximizing the chance of a successful hit on the first two probes. From Owners-commonloops.pa@Xerox.COM Thu Dec 15 00:46:54 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06870; Thu, 15 Dec 88 00:46:54 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 DEC 88 00:45:45 PST Return-Path: <@RELAY.CS.NET:vargasje@midway.ece.scarolina.edu> Redistributed: commonloops.pa Received: from RELAY.CS.NET ([192.31.103.4]) by Xerox.COM ; 15 DEC 88 00:43:15 PST Received: from relay2.cs.net by RELAY.CS.NET id aa21951; 15 Dec 88 3:39 EST Received: from ece.scarolina.edu by RELAY.CS.NET id ab14027; 15 Dec 88 3:33 EST To: commonloops.pa@Xerox.COM Subject: change name in mailing list Date: Wed, 14 Dec 88 12:44:34 EST From: vargasje@midway.ece.scarolina.edu Sender: vargasje@midway.ece.scarolina.edu Message-Id: <881215-004545-1601@Xerox> Please change my name in the mailing list, from vargasje@midway.ece.scarolina.edu to clos@midway.ece.scarolina.edu Thanks From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 15 09:35:56 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10531; Thu, 15 Dec 88 09:35:56 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:35:09 PST Received: by ti.com id AA15075; Thu, 15 Dec 88 11:33:56 CST Received: from Kelvin by tilde id AA07810; Thu, 15 Dec 88 11:23:07 CST Message-Id: <2807198566-13859327@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Thu, 15 Dec 88 11:22:46 CST From: David N Gray To: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: CLOS lambda-list congruence I have a question for the CLOS gurus; I hope this is the appropriate mailing list. In testing a program we are writing for automatically translating source code from Flavors to CLOS, I found that by far the biggest problem with the automatically translated code is non-congruence of method parameters. When writing flavors, I often had a method with parameters like (a b &optional x y) but would then write a :BEFORE or :AFTER method with parameters like (a b &rest ignore) which worked fine with flavors, but CLOS considers these lambda lists to not be equivalent. Can someone explain why this particular restriction is necessary? Although the above example is merely a nuisance, a more troubling case is a method which translates to: (DEFMETHOD PRINT-DESCRIPTION ((SELF TRANSPORTER) &REST ARGS) (WITH-SLOTS (POSITION) SELF (APPLY #'PRINT-DESCRIPTION POSITION ARGS))) Here I don't want to enumerate the optional arguments because I want to let the function (or in this case, method) being called do the defaulting. I don't see why the implementation couldn't permit this. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 15 09:53:56 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10757; Thu, 15 Dec 88 09:53:56 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:53:10 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA12937; Thu, 15 Dec 88 09:55:06 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA01535; Thu, 15 Dec 88 09:51:41 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07455; Thu, 15 Dec 88 09:52:16 PST Message-Id: <8812151752.AA07455@suntana.sun.com> To: David N Gray Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: CLOS lambda-list congruence In-Reply-To: Your message of Thu, 15 Dec 88 11:22:46 -0600. <2807198566-13859327@Kelvin> Date: Thu, 15 Dec 88 09:52:13 PST From: kempf@Sun.COM The lambda list congruence rules are designed to re-enforce the generic function as an interface mechanism. In this design, the lambda list is the interface to a distributed implementation, namely the methods. The congruence rules match the generic function interface to the implementation. This is a fundamentally different design from old Flavors (but similar to new Flavors, see Moon's paper in the 1986 OOPSLA Proceedings). Therefore, a simple syntactic transformation may be insufficient to handle the translation. I ran into a similar problem doing CommonObjects on CommonLoops. CommonObjects allows methods defined on different classes to have the same name but differing lambda lists. In CommonObjects, methods are defined on classes as in old Flavors or Smalltalk, so classes form individual namespaces for methods. This is semantically distinct from generic functions, where the package system is used to form namespaces. If you want to preserve the old semantics, and alternative is to implement your own generic function type using the metaobject protocol, which relaxes the restriction on lambda list congruence. jak From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 15 11:18:29 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11731; Thu, 15 Dec 88 11:18:29 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Dec 88 11:17:32 PST Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 509134; 15 Dec 88 14:15:31 EST Date: Thu, 15 Dec 88 14:19 EST From: David A. Moon Subject: Re: CLOS lambda-list congruence To: kempf@Sun.COM Cc: David N Gray , Common-Lisp-Object-System@SAIL.STANFORD.EDU In-Reply-To: <8812151752.AA07455@suntana.sun.com> Message-Id: <19881215191956.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Thu, 15 Dec 88 09:52:13 PST From: kempf@Sun.COM This is a fundamentally different design from old Flavors (but similar to new Flavors, see Moon's paper in the 1986 OOPSLA Proceedings). Just to set the record straight, the lambda list congruence rules in CLOS are not based on New Flavors. They are a new design that as far as I know was not previously implemented. I think they are correct, though. It's true that there are legitimate applications for relaxing these rules to require only that the number of required arguments be equal, and making a new class of method would be one good way to do that. Another possibility would be to invent an implementation-dependent decoration of the lambda-list and an extension of the congruence rules implemented by the standard classes of generic function and method to take that decoration into account. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Dec 15 11:20:39 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA11766; Thu, 15 Dec 88 11:20:39 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 11:19:47 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA15046; Thu, 15 Dec 88 11:21:26 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA05899; Thu, 15 Dec 88 11:17:36 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07629; Thu, 15 Dec 88 11:17:58 PST Message-Id: <8812151917.AA07629@suntana.sun.com> To: David A. Moon Cc: kempf@Sun.COM, David N Gray , Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: CLOS lambda-list congruence In-Reply-To: Your message of Thu, 15 Dec 88 14:19:00 -0500. <19881215191956.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Thu, 15 Dec 88 11:17:52 PST From: kempf@Sun.COM >Just to set the record straight, the lambda list congruence rules in CLOS >are not based on New Flavors. They are a new design that as far as I I stand corrected. Thank you. jak From Owners-commonloops.pa@Xerox.COM Thu Dec 15 13:27:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12479; Thu, 15 Dec 88 13:27:38 PST Received: from Burger.ms by ArpaGateway.ms ; 15 DEC 88 10:47:55 PST Return-Path: Redistributed: commonloops.pa Received: from XN.LL.MIT.EDU ([10.2.0.10]) by Xerox.COM ; 15 DEC 88 10:21:45 PST Received: by XN.LL.MIT.EDU; Thu, 15 Dec 88 12:17:50 EST Date: Thu, 15 Dec 88 12:17:50 EST From: root@XN.LL.MIT.EDU (The Big Cheese) Posted-Date: Thu, 15 Dec 88 12:17:50 EST Message-Id: <8812151717.AA18577@XN.LL.MIT.EDU> To: commonloops.pa@Xerox.COM Subject: Please remove from mailing list Cc: kathy@XN.LL.MIT.EDU Sorry this is going to the whole list, but I can't find anything in the messages on hand listing an address for a moderator or for administrative traffic. Please remove ll-xn from your mailing list. I am uncertain of the precise form of the account, as it is being gatewayed here into a local mailing list, however I suspect it is probably either commonloopsmail@ll-xn.arpa or commonloopsmail@xn.ll.mit.edu We no longer have any users here subscribing, so traffic to the list is just going into the bit bucket. Thank you. Kathryn L. Smith System Administrator, MIT Lincoln Lab. (kathy@xn.ll.mit.edu or ll-xn!kathy) From Owners-CommonLoops.pa@Xerox.COM Thu Dec 15 13:30:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12489; Thu, 15 Dec 88 13:30:58 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 DEC 88 10:47:55 PST Return-Path: Redistributed: CommonLoops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 15 DEC 88 10:18:58 PST Posted-Date: Thu, 15 Dec 88 10:18:54 PST Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA26034; Thu, 15 Dec 88 10:19:06 PST To: CommonLoops.pa@Xerox.COM Cc: brill@vaxa.isi.edu Subject: destroying classes Date: Thu, 15 Dec 88 10:18:54 PST Message-Id: <26021.598213134@vaxa.isi.edu> From: Dave Brill We are using large PCL nets here, and it takes several minutes to redefine a class near the top of the net. We would like to be able to simply rebuild the net under such circumstances. Will it be possible to use "cmakunbound" (when implemented) to expunge PCL classes? Is any mechanism for destroying classes available now? From Owners-commonloops.pa@Xerox.COM Thu Dec 15 13:50:19 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12763; Thu, 15 Dec 88 13:50:19 PST Received: from Riesling.ms by ArpaGateway.ms ; 15 DEC 88 11:42:25 PST Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 15 DEC 88 11:07:41 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA14675; Thu, 15 Dec 88 11:10:46 PST Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA05294; Thu, 15 Dec 88 11:07:14 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07582; Thu, 15 Dec 88 11:07:48 PST Message-Id: <8812151907.AA07582@suntana.sun.com> To: commonloops.pa@Xerox.COM Cc: gregor.pa@Xerox.COM Subject: Redefining Traced Generic Functions Date: Thu, 15 Dec 88 11:07:45 PST From: kempf@Sun.COM At various times, people have reported that it is not possible to redefine a generic function which is being traced without ENSURE-GENERIC-FUNCTION complaining that it is not a generic function. This happens because the wrapper is, in fact, not a generic function, so it can't be passed. The following code fixes this problem in Lucid Common Lisp 3.0: ;;from defs.lisp (defun gdefinition (spec) (parse-gspec spec (name (or (macro-function name) ;?? (symbol-generic-function name))) (name (symbol-generic-function (get-setf-function-name name))))) ;;Should go in lucid-low.lisp. ;;symbol-generic-function-If the function is traced or advised, return the ;; function traced or advised. #+lucid (defun symbol-generic-function (symbol) (lucid::trace-get-real-procedure (symbol-function symbol))) ;;The reverse operation, SETF-ing a traced function, should work fine in ;; lucid, but maybe not in others. From Gregor.pa@Xerox.COM Thu Dec 15 14:54:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13608; Thu, 15 Dec 88 14:54:27 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 DEC 88 14:49:41 PST Date: Thu, 15 Dec 88 14:44 PST From: Gregor.pa@Xerox.COM Subject: Re: destroying classes To: Dave Brill Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <26021.598213134@vaxa.isi.edu> Message-Id: <19881215224432.7.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 15 Dec 88 10:18:54 PST From: Dave Brill We are using large PCL nets here, and it takes several minutes to redefine a class near the top of the net. We would like to be able to simply rebuild the net under such circumstances. Will it be possible to use "cmakunbound" (when implemented) to expunge PCL classes? Is any mechanism for destroying classes available now? Three comments: - PCL is scheduled for some improvement in the speed at which classes are updated. The new metaobject protocol makes it possible to do this much more efficiently than before (thanks to Patrick Dussud). In addition, the existing implementation doesn't have to be anywhere near as stupid as it is. So, you can expect this to get better. Over the years, the flavors implementations have improved dramatically in this regard. - cmakunbound is (setf (find-class ) nil) - you can use setf with find-class now, and it will have exactly the specified behavior. But, that behavior may not be what you are thinking of. For example, you will have to reload any methods that mentioned the class by name, and other things may be surprising. You have to remember that *basically* CLOS converts names to objects (metaobjects) at load time, and then manipulates only the metaobjects. So, doing a setf of find-class to nil (or any other value) doesn't affect any running code that doesn't explicitly depend on the name to metaobject mapping. So, for example, code that calls typep with a symbol as a second argument or code that calls type-of is affected. ------- From Owners-commonloops.pa@Xerox.COM Thu Dec 15 17:40:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15264; Thu, 15 Dec 88 17:40:48 PST Received: from Salvador.ms by ArpaGateway.ms ; 15 DEC 88 17:30:30 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 15 DEC 88 17:28:04 PST Posted-Date: Thu, 15 Dec 88 17:29:01 PST Message-Id: <8812160129.AA04558@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA04558; Thu, 15 Dec 88 17:29:08 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: Compiler Warning from MAKE-PARAMETER-REFERENCES Date: Thu, 15 Dec 88 17:29:01 PST Sender: goldman@vaxa.isi.edu Can someone explain the following warning issued when I compile the DEFMETHOD form below? "Warning (not associated with any definition): In defmethod M23 (TEST23), there is a redundant ignore declaration for the parameter X." If this warning is appropriate here, why? If not here, where? I thought IGNORE declarations were only correct when they WERE "redundant" !!! Neil ---------------------------------------------------------------- (defclass test23 () ()) (defmethod m23 ((x test23)) (declare (ignore x)) 7) From cutting.pa@Xerox.COM Thu Dec 15 19:50:55 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16433; Thu, 15 Dec 88 19:50:55 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 DEC 88 19:12:02 PST Date: 15 Dec 88 19:09 PST From: cutting.pa@Xerox.COM Subject: Re: Compiler Warning from MAKE-PARAMETER-REFERENCES In-Reply-To: goldman@vaxa.isi.edu's message of Thu, 15 Dec 88 17:29:01 PST To: goldman@vaxa.isi.edu Cc: commonloops.pa@Xerox.COM Message-Id: <881215-191202-2909@Xerox> From: goldman@vaxa.isi.edu Subject: Compiler Warning from MAKE-PARAMETER-REFERENCES Date: Thu, 15 Dec 88 17:29:01 PST Can someone explain the following warning issued when I compile the DEFMETHOD form below? "Warning (not associated with any definition): In defmethod M23 (TEST23), there is a redundant ignore declaration for the parameter X." (defmethod m23 ((x test23)) (declare (ignore x)) 7) The CLOS spec says: "The expansion of the DEFMETHOD macro 'refers to' each specialized parameter." (p 2-40) Thus it's wrong to (declare (ignore ...)) any such parameter. My guess is that in this case PCL implements your method body as a function with one argument, X, declared to be ignored as method dispatch has already happened by the time it is called, and your method body was noticed to not reference X. Your further declaration caused the compiler to complain of redundant ignore declarations, as indeed there were two. Doug From Gregor.pa@Xerox.COM Thu Dec 15 20:02:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16483; Thu, 15 Dec 88 20:02:33 PST Received: from Semillon.ms by ArpaGateway.ms ; 15 DEC 88 20:00:13 PST Date: Thu, 15 Dec 88 19:58 PST From: Gregor.pa@Xerox.COM Subject: Re: Compiler Warning from MAKE-PARAMETER-REFERENCES To: cutting.pa@Xerox.COM Cc: goldman@vaxa.isi.edu, commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 15 Dec 88 19:09 PST from cutting.pa Message-Id: <19881216035830.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: 15 Dec 88 19:09 PST From: cutting.pa From: goldman@vaxa.isi.edu Can someone explain the following warning issued when I compile the DEFMETHOD form below? "Warning (not associated with any definition): In defmethod M23 (TEST23), there is a redundant ignore declaration for the parameter X." (defmethod m23 ((x test23)) (declare (ignore x)) 7) The CLOS spec says: "The expansion of the DEFMETHOD macro 'refers to' each specialized parameter." (p 2-40) Thus it's wrong to (declare (ignore ...)) any such parameter. My guess is that in this case PCL implements your method body as a function with one argument, X, declared to be ignored as method dispatch has already happened by the time it is called, and your method body was noticed to not reference X. Your further declaration caused the compiler to complain of redundant ignore declarations, as indeed there were two. Almost right. Actually, PCL itself issues that warning. There is some question as to whether it should issue the warning or silently remove the redundant warning. I made it warn to help remind people that they didn't need to type those declares. ------- From Owners-CommonLoops.PA@Xerox.COM Fri Dec 16 07:51:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19030; Fri, 16 Dec 88 07:51:41 PST Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 88 07:49:43 PST Return-Path: Redistributed: CommonLoops.PA Received: from cs.utah.edu ([128.110.4.21]) by Xerox.COM ; 16 DEC 88 07:47:59 PST Received: from esunix.UUCP by cs.utah.edu (5.59/utah-2.1-cs) id AA06981; Fri, 16 Dec 88 08:47:57 MST Received: by roma.EandS.com (3.2/SMI-3.2) id AA15388; Thu, 15 Dec 88 14:35:23 MST Date: Thu, 15 Dec 88 14:35:23 MST From: csteury%roma%esunix@cs.utah.edu (Craig Steury) Message-Id: <8812152135.AA15388@roma.EandS.com> To: CommonLoops@cs.utah.edu Subject: Add to mailing list Hi, Can you add me to this mailing list. Thanks, Craig Steury Evans & Sutherland (801) 582-5847 Salt Lake City, UT 84108 steury@cs.utah.edu From Owners-commonloops.pa@Xerox.COM Fri Dec 16 09:38:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19759; Fri, 16 Dec 88 09:38:46 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 DEC 88 09:34:02 PST Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 16 DEC 88 09:30:59 PST Received: by paris.Berkeley.EDU (5.57/1.25) id AA06113; Fri, 16 Dec 88 09:29:51 PST From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8812161729.AA06113@paris.Berkeley.EDU> To: commonloops.pa@Xerox.COM Subject: [David E. Wallace: Re: A few questions on PCL ] Reply-To: larus@ginger.Berkeley.EDU Date: Fri, 16 Dec 88 09:29:47 PST ------- Forwarded Message Return-Path: wallace%hpldew@hplabs.HP.COM Message-Id: <8812151744.AA09867@hpldew.HP.COM> To: larus%ginger.Berkeley.EDU%Berkeley.EDU%hplabs@hplabs.HP.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Wed, 14 Dec 88 09:08:53 -0800. <8812141709.AA04313@paris.Berkeley.EDU> Date: Thu, 15 Dec 88 09:44:34 PST From: David E. Wallace > There is lot of published work on non-chained hashing schemes. > Unfortunaely, I'm too busy and lazy to look it up. However, there is > one scheme that I remember from a compiler class that should work well > here. It is called quadratic linear rehashing. Assume we want a hash > value between 0 and S. Let H be the initial hash value computed from > the object. Then compute the sequence of hash values: > > H_i = (H + i*i) mod S > > If S is prime, then this scheme tends to spread the hash probes over > the entire table (note the resemblence to pseudo-random number > generators). Of course, this is an expensive operation on machines > without hardware fixnum multiple and divide operations (do people run > Lisp on such machines?). > > /Jim It looks like it's something of a moot point for PCL, but why do you need hardware multiply and divide (except for the initial hashing)? Use the fact that i*i = (i-1)*(i-1) + 2*i-1, and you can compute the sequence H_i using only addition, subtraction, and comparison. In pseudo-C: probe = H; incr = 1; while (hash_table[probe] != EMPTY && hash_table[probe] != key && incr < S) { probe += incr; incr += 2; if (probe >= S) probe -= S; } /* Now if hash_table[probe] == key, success, else failure */ Since probe and incr are kept in the range 0...S-1, their sum must fall in the range 0...2*S-2, so no more than one subtraction is ever needed to normalize probe. This version may be faster even on machines with hardware multiply and divide, if addition and subtraction are sufficiently faster. One of the weaknesses of quadratic hashing is that you can only reach locations offset from your starting point by a quadratic residue (mod S), so you will only try about half the possible locations in the table before wrapping around. The wrap-around corresponds to the point where incr wraps around S. The above code uses this condition to terminate the loop, since no new probes will be generated beyond this point. Feel free to forward this to the mailing list if you think the point is of general interest. Dave W. ------- End of Forwarded Message From Owners-commonloops.pa@Xerox.COM Fri Dec 16 10:25:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA19759; Fri, 16 Dec 88 09:38:46 PST Received: from Chardonnay.ms by ArpaGateway.ms ; 16 DEC 88 09:34:02 PST Return-Path: Redistributed: commonloops.pa Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 16 DEC 88 09:30:59 PST Received: by paris.Berkeley.EDU (5.57/1.25) id AA06113; Fri, 16 Dec 88 09:29:51 PST From: larus@paris.berkeley.edu (James Larus) Message-Id: <8812161729.AA06113@paris.Berkeley.EDU> To: commonloops.pa@Xerox.COM Subject: [David E. Wallace: Re: A few questions on PCL ] Reply-To: larus@ginger.Berkeley.EDU Date: Fri, 16 Dec 88 09:29:47 PST ------- Forwarded Message Return-Path: wallace%hpldew@hplabs.HP.COM Message-Id: <8812151744.AA09867@hpldew.HP.COM> To: larus%ginger.Berkeley.EDU%Berkeley.EDU%hplabs@hplabs.HP.COM Subject: Re: A few questions on PCL In-Reply-To: Your message of Wed, 14 Dec 88 09:08:53 -0800. <8812141709.AA04313@paris.Berkeley.EDU> Date: Thu, 15 Dec 88 09:44:34 PST From: David E. Wallace > There is lot of published work on non-chained hashing schemes. > Unfortunaely, I'm too busy and lazy to look it up. However, there is > one scheme that I remember from a compiler class that should work well > here. It is called quadratic linear rehashing. Assume we want a hash > value between 0 and S. Let H be the initial hash value computed from > the object. Then compute the sequence of hash values: > > H_i = (H + i*i) mod S > > If S is prime, then this scheme tends to spread the hash probes over > the entire table (note the resemblence to pseudo-random number > generators). Of course, this is an expensive operation on machines > without hardware fixnum multiple and divide operations (do people run > Lisp on such machines?). > > /Jim It looks like it's something of a moot point for PCL, but why do you need hardware multiply and divide (except for the initial hashing)? Use the fact that i*i = (i-1)*(i-1) + 2*i-1, and you can compute the sequence H_i using only addition, subtraction, and comparison. In pseudo-C: probe = H; incr = 1; while (hash_table[probe] != EMPTY && hash_table[probe] != key && incr < S) { probe += incr; incr += 2; if (probe >= S) probe -= S; } /* Now if hash_table[probe] == key, success, else failure */ Since probe and incr are kept in the range 0...S-1, their sum must fall in the range 0...2*S-2, so no more than one subtraction is ever needed to normalize probe. This version may be faster even on machines with hardware multiply and divide, if addition and subtraction are sufficiently faster. One of the weaknesses of quadratic hashing is that you can only reach locations offset from your starting point by a quadratic residue (mod S), so you will only try about half the possible locations in the table before wrapping around. The wrap-around corresponds to the point where incr wraps around S. The above code uses this condition to terminate the loop, since no new probes will be generated beyond this point. Feel free to forward this to the mailing list if you think the point is of general interest. Dave W. ------- End of Forwarded Message From Owners-commonloops.pa@Xerox.COM Fri Dec 16 13:58:08 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.6) id AA03197; Fri, 16 Dec 88 13:58:08 PST Received: from Burger.ms by ArpaGateway.ms ; 16 DEC 88 13:39:45 PST Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([10.2.0.27]) by Xerox.COM ; 16 DEC 88 13:38:04 PST Posted-Date: Fri, 16 Dec 88 13:38:27 PST Message-Id: <8812162138.AA25650@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA25650; Fri, 16 Dec 88 13:38:30 PST To: commonloops.pa@Xerox.COM From: goldman@vaxa.isi.edu Subject: ignore declarations/ defmethod specialization Date: Fri, 16 Dec 88 13:38:27 PST Sender: goldman@vaxa.isi.edu The paragraph in the spec certainly explains why PCL may choose to issue this warning. I can see the rationale for considering a specialized parameter to not be "IGNORED". [But the treatment of a specializer of T as distinct from having no specializer seems specious to me, and a source of trouble -- or at least a nuisance -- for automatic programming/ transformation systems.] neil From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Dec 16 15:06:28 1988 Received: from Sail.Stanford.EDU by arisia with SMTP (5.59++/IDA-1.2.6) id AA03717; Fri, 16 Dec 88 15:06:28 PST Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 15:05:36 PST Received: by ti.com id AA20847; Fri, 16 Dec 88 17:04:19 CST Received: from Kelvin by tilde id AA10157; Fri, 16 Dec 88 16:52:03 CST Message-Id: <2807304730-3722733@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Fri, 16 Dec 88 16:52:10 CST From: David N Gray To: kempf@Sun.COM Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: CLOS lambda-list congruence In-Reply-To: Msg of Thu, 15 Dec 88 09:52:13 PST from kempf@Sun.COM > The lambda list congruence rules are designed to re-enforce the generic > function as an interface mechanism. In this design, the lambda list > is the interface to a distributed implementation, namely the methods. > The congruence rules match the generic function interface to the > implementation. OK, but I don't see how the examples I cited are inconsistent with this philosophy. > If you want to preserve the old semantics, and alternative is to implement > your own generic function type using the metaobject protocol, which > relaxes the restriction on lambda list congruence. Looking at document 88-003, I can't find any provision for being able to do that. Is that a new feature in the forthcoming draft? From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Dec 16 16:18:52 1988 Received: from Sail.Stanford.EDU by arisia with SMTP (5.59++/IDA-1.2.6) id AA04098; Fri, 16 Dec 88 16:18:52 PST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Dec 88 16:18:02 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA04559; Fri, 16 Dec 88 16:20:08 PST Received: from suntana.sun.com ([129.144.42.122]) by snail.Sun.COM (4.1/SMI-4.0) id AA21443; Fri, 16 Dec 88 15:35:33 PST Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA10428; Fri, 16 Dec 88 15:34:37 PST Message-Id: <8812162334.AA10428@suntana.sun.com> To: David N Gray Cc: kempf@Sun.COM, Common-Lisp-Object-System@SAIL.STANFORD.EDU Subject: Re: CLOS lambda-list congruence In-Reply-To: Your message of Fri, 16 Dec 88 16:52:10 -0600. <2807304730-3722733@Kelvin> Date: Fri, 16 Dec 88 15:34:31 PST From: kempf@Sun.COM >Looking at document 88-003, I can't find any provision for being >able to do that. Is that a new feature in the forthcoming draft? As I have not yet received a copy of 88-003, I can't say. jak