From Owners-commonloops.pa@Xerox.COM Thu Sep 22 13:23:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13154; Tue, 20 Sep 88 18:13:42 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 SEP 88 08:07:26 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 20 SEP 88 07:57:47 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA08872; Tue, 20 Sep 88 07:55:32 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA06666; Tue, 20 Sep 88 07:58:27 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07512; Tue, 20 Sep 88 07:58:19 PDT Message-Id: <8809201458.AA07512@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: Doug Ruth , commonloops.pa@Xerox.COM Subject: Re: :type bug? In-Reply-To: Your message of Mon, 19 Sep 88 21:36:00 -0700. <19880920043640.5.GREGOR@PORTNOY.parc.xerox.com> Date: Tue, 20 Sep 88 07:58:17 -0700 From: kempf@Sun.COM >(defclass foo () ((a :type number))) >(defclass bar () ((a))) > >Clearly, the following are true: > >(slotd-type (car (class-slots (find-class 'foo)))) ==> NUMBER >(slotd-type (car (class-slots (find-class 'bar)))) ==> NUMBER I think what you mean here is: (defclass foo () ((a :type number))) (defclass bar (foo) ((a))) Otherwise: (slotd-type (car (class-slots (find-class 'bar)))) ==> T or? jak From Owners-CommonLoops.pa@Xerox.COM Thu Sep 22 13:52:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA20633; Wed, 21 Sep 88 10:05:53 PDT Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 09:15:49 PDT Return-Path: <@CUNYVM.CUNY.EDU:K311770@AEARN.BITNET> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 21 SEP 88 09:13:44 PDT Received: from AEARN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1063; Wed, 21 Sep 88 12:12:12 EDT Received: by AEARN (Mailer X1.25) id 1335; Wed, 21 Sep 88 16:36:36 EDT Date: Wed, 21 Sep 88 15:29:23 EDT From: Hubert Hofbauer Subject: Re: metaobject protocol documentation To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Your message of Mon, 19 Sep 88 22:48 PDT Message-Id: <880921-091549-596@Xerox> Please send me the draft of the metaobject documentation. At RISC Linz we are currently evaluating PCL as a basis for our symbolic computation library. An important issue in this field are parameterized types - families of classes - such as zmod N, polynomial over A-FIELD in VARS, matrix DIMS of DOMAIN,... , where N, A-FIELD, VARS, DIMS, and DOMAIN are parameters for type zmod, polynomial, and matrix. We would like something like (DEFCLASS (ZMOD N) ...) and (DEFMETHOD xxx ((Z (ZMOD N))... )... ). Related work has been done at Tektronix for Smalltalk - the VIEWS system. Has anybody tried to do something similar for PCL? Thank you, Hubert PS: I have chapter 1 & 2 of the CLOS draft and 'St.Patricks Day' PCL. I cannot get the new versions. A friend who FTPed and sent it as mail cannot do it anymore. Please help an EARN (=BITNET in Europe) user! +-----------------------------------------------+-----------------------+ ! Hubert Hofbauer (research assistant) ! K311770@AEARN.BITNET ! ! Research Institute for Symbolic Computation ! RISC ! ! Johannes-Kepler-Universitaet Linz ! JKU Linz ! ! A-4040 Linz ! Austria / Europe ! +-----------------------------------------------+-----------------------+ From Owners-COMMONLOOPS.PA@Xerox.COM Thu Sep 22 14:14:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA24566; Mon, 19 Sep 88 09:02:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 09:08:08 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 ; 19 SEP 88 09:01:36 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 19 Sep 88 12:01:32 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 19 Sep 88 11:57:42 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 19 Sep 88 12:04:02 EDT Received: (from user SOBO) by s66.Prime.COM; 19 Sep 88 11:57:21 EST Subject: Recording method definitions To: COMMONLOOPS.PA@Xerox.COM From: SOBO@s66.Prime.COM Date: 19 Sep 88 11:57:21 EST Message-Id: <880919-090808-1429@Xerox> Can someone please tell me why recording the source file for method definitions is *still* disabled on the Symbolics? Nadine Sobolevitch From Owners-CommonLoops.pa@Xerox.COM Thu Sep 22 14:44:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA25566; Mon, 19 Sep 88 10:50:35 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 10:50:28 PDT Return-Path: Redistributed: CommonLoops.pa Received: from rand-unix.arpa ([10.3.0.7]) by Xerox.COM ; 19 SEP 88 10:43:29 PDT Received: by rand-unix.arpa; Mon, 19 Sep 88 09:53:47 PDT Message-Id: <8809191653.AA28806@rand-unix.arpa> To: Gregor.pa@Xerox.COM Cc: CommonLoops.pa@Xerox.COM, dave@rand-unix.ARPA, shane@rand-unix.ARPA, steph%ixta@rand-unix.ARPA, burdorf@rand-unix.ARPA Subject: Re: redefining methods In-Reply-To: Your message of Sun, 18 Sep 88 17:28 PDT. <19880919002813.3.GREGOR@PORTNOY.parc.xerox.com> Date: Mon, 19 Sep 88 09:53:33 PDT From: burdorf@rand-unix.ARPA I double checked and found that I can redefine methods. The problem occurred when I had traced a method and tried to redefine it. The trace code redefined the method as an expr and thus PCL wouldn't allow the trace code to be redefined as a method. At the time I sent the message, I wasn't aware of this problem. The way I get around this problem is to untrace the method, redefine it, and then trace it again. It is a pain, because I have to remember what's a method and what's a function, but it works. Chris Burdorf From Owners-CommonLoops.PA@Xerox.COM Thu Sep 22 15:14:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA00045; Mon, 19 Sep 88 16:14:09 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 SEP 88 12:57:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 19 SEP 88 12:55:00 PDT Date: Mon, 19 Sep 88 12:40:11 PDT From: bmiller@vaxa.isi.edu (Brent Miller) Posted-Date: Mon, 19 Sep 88 12:40:11 PDT Message-Id: <8809191940.AA02150@vaxa.isi.edu> Received: by vaxa.isi.edu (5.54/5.51) id AA02150; Mon, 19 Sep 88 12:40:11 PDT To: CommonLoops.PA@Xerox.COM Subject: Please put me on the mailing list Thanks. From Owners-commonloops.pa@Xerox.COM Thu Sep 22 15:44:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13154; Tue, 20 Sep 88 18:13:42 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 SEP 88 08:07:26 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 20 SEP 88 07:57:47 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA08872; Tue, 20 Sep 88 07:55:32 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA06666; Tue, 20 Sep 88 07:58:27 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA07512; Tue, 20 Sep 88 07:58:19 PDT Message-Id: <8809201458.AA07512@suntana.sun.com> To: Gregor.pa@Xerox.COM Cc: Doug Ruth , commonloops.pa@Xerox.COM Subject: Re: :type bug? In-Reply-To: Your message of Mon, 19 Sep 88 21:36:00 -0700. <19880920043640.5.GREGOR@PORTNOY.parc.xerox.com> Date: Tue, 20 Sep 88 07:58:17 -0700 From: kempf@Sun.COM >(defclass foo () ((a :type number))) >(defclass bar () ((a))) > >Clearly, the following are true: > >(slotd-type (car (class-slots (find-class 'foo)))) ==> NUMBER >(slotd-type (car (class-slots (find-class 'bar)))) ==> NUMBER I think what you mean here is: (defclass foo () ((a :type number))) (defclass bar (foo) ((a))) Otherwise: (slotd-type (car (class-slots (find-class 'bar)))) ==> T or? jak From Owners-CommonLoops.pa@Xerox.COM Thu Sep 22 17:58:41 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA07105; Thu, 22 Sep 88 17:58:41 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 22 SEP 88 12:04:37 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 22 SEP 88 12:00:13 PDT Received: from fafnir.think.com by Think.COM; Thu, 22 Sep 88 11:18:55 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Thu, 22 Sep 88 11:27:22 EDT Received: by sauron.think.com; Thu, 22 Sep 88 11:27:19 EDT Date: Thu, 22 Sep 88 11:27:19 EDT From: salem@Think.COM Message-Id: <8809221527.AA18879@sauron.think.com> To: common-loops@Think.COM Subject: Exports should include standard types The list of symbols exported from PCL probably should include the names of the classes defined in the CLOS document. These include at least : standard-class standard-object object built-in-class structure-class -- jim From Owners-commonloops.pa@Xerox.COM Thu Sep 22 18:09:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA07422; Thu, 22 Sep 88 18:09:38 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 21 SEP 88 17:33:27 PDT Return-Path: Redistributed: commonloops.pa Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 21 SEP 88 17:30:42 PDT Received: from a-boy.media.mit.edu by media-lab.media.mit.edu (5.59/4.8) id AA12939; Wed, 21 Sep 88 20:30:23 EDT Received: by a-boy (3.2/4.8) id AB01482; Mon, 22 Aug 88 20:30:05 EDT Date: Mon, 22 Aug 88 20:30:05 EDT From: Michael Sokolov Message-Id: <8808230030.AB01482@a-boy> To: commonloops.pa@Xerox.COM Subject: Lucid compiler barfs For some strange reason, the Lucid compiler goes into an infinite loop when trying to compile the function "describe-instance" in high.lisp of 8/28/88 AAAI PCL. While tail merging, It complains about the argument list to describe-slot: > ;;; Compiling function DESCRIBE-INSTANCE...tail merging... ;;; Warning: Malformed optional argument (ALLOCATION (QUOTE NIL) ALLOC-P ALLOC-P ALLOC-P ALLOC-P ALLOC-P ... (etc) This seems like a compiler bug to me, but this seems to patch over the rough spots: (The key here is to make alloc-p an explicit keyword argument and bypass whatever weirdness is happening as a result of the supplied-p parameter. I don't claim to understand it.) ____________________________________________________________________ (defun describe-instance (object &optional (stream t)) (let* ((class (class-of object)) (slotds (slots-to-inspect class object)) (max-slot-name-length 0) (instance-slotds ()) (class-slotds ()) (other-slotds ())) (flet ((adjust-slot-name-length (name) (setq max-slot-name-length (max max-slot-name-length (length (the string (symbol-name name)))))) (describe-slot (name value &optional allocation &key alloc-p) (if alloc-p (format stream "~% ~A ~S ~VT ~S" name allocation (+ max-slot-name-length 7) value) (format stream "~% ~A~VT ~S" name max-slot-name-length value)))) ;; Figure out a good width for the slot-name column. (dolist (slotd slotds) (adjust-slot-name-length (slotd-name slotd)) (case (slotd-allocation slotd) (:instance (push slotd instance-slotds)) (:class (push slotd class-slotds)) (otherwise (push slotd other-slotds)))) (setq max-slot-name-length (min (+ max-slot-name-length 3) 30)) (format stream "~%~S is an instance of class ~S:" object class) (when instance-slotds (format stream "~% The following slots have :INSTANCE allocation:") (dolist (slotd (nreverse instance-slotds)) (describe-slot (slotd-name slotd) (slot-value object (slotd-name slotd))))) (when class-slotds (format stream "~% The following slots have :CLASS allocation:") (dolist (slotd (nreverse class-slotds)) (describe-slot (slotd-name slotd) (slot-value object (slotd-name slotd))))) (when other-slotds (format stream "~% The following slots have allocation as shown:") (dolist (slotd (nreverse other-slotds)) (describe-slot (slotd-name slotd) (slot-value object (slotd-name slotd)) (slotd-allocation slotd) :alloc-p t))) (values)))) From Owners-commonloops.pa@Xerox.COM Fri Sep 23 17:11:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA21128; Fri, 23 Sep 88 17:11:10 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 17:10:38 PDT Return-Path: Redistributed: commonloops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 23 SEP 88 17:09:40 PDT Return-Path: Received: from sauron.think.com by Think.COM; Fri, 23 Sep 88 20:10:00 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Fri, 23 Sep 88 20:08:06 EDT Date: Fri, 23 Sep 88 20:08 EDT From: Jim Salem Subject: PCL Genera 7.2 bugfixes To: mthome@vax.bbn.com, commonloops.pa@Xerox.COM In-Reply-To: <880921-132646-1431@Xerox> Message-Id: <19880924000837.3.SALEM@POLYCARP.THINK.COM> One more bug fix I found absolutely necessary was to uncomment the following lines from REL-7-2-PATCHES.LISP :: (defun (:property pcl::top-level-form lt:mapforms) (original-form form usage) (lt::mapforms-list original-form form (cddr form) 'eval usage)) I could not even get the TEST.LISP file to compile without doing that. I am somewhat mystified how this could ever work without it. It was necessary both in the "8/28/88 (beta rev 1) AAAI PCL " version and the prior version. It's fantastic to have software include tests ! -- jim salem@think.com From Owners-commonloops.pa@Xerox.COM Mon Sep 26 09:29:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA10853; Mon, 26 Sep 88 09:29:01 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 88 08:50:28 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 26 SEP 88 08:48:28 PDT To: commonloops.pa@Xerox.COM Subject: Yet another 7.2 patch Date: Mon, 26 Sep 88 11:40:10 -0400 From: Mike Thome Message-Id: <880926-085028-3862@Xerox> The following patch fixes that annoying problem where qualified methods are not properly indented by zwei. enjoy, -mike (mthome@bbn.com) = = = = = = = = ;;; -*- Package: PCL -*- ;;; PATCH 3600-LOW.LISP ;;; patch to fix indentation of method forms in cases with qualifiers. ;;; MT - 880926 #|| ;; before... (defmethod foo ((x number) y) ; this is ok whatever) (defmethod foo :after ((x number) y) ; this is not whatever) ;; after... (defmethod foo ((x number) y) ; this is ok whatever) (defmethod foo :after ((x number) y) ; this is too, now. whatever) ||# (defun zwei:pcl-method-indentation (BP1 BP LASTPAREN lastsexp space-width sym) (declare (ignore sym space-width lastsexp)) (let* ((ipt bp1) (nsexps (do* ((sbp (zwei:forward-char lastparen 1) (zwei:forward-sexp sbp 1 nil 0 bp)) (count 0)) ((null sbp) count) (let* ((sbp1 (zwei:forward-over zwei:*whitespace-chars* sbp bp)) (ch (zwei:bp-char sbp1))) (when (zwei:bp-= sbp1 bp) (return count)) (when (= count 1) (setf ipt sbp1)) ; should this be a copy-bp? (unless (char-equal ch #\:) (incf count)))))) (case nsexps ((0 1) (values bp1 nil 2)) ((2) (values ipt nil 0)) (t (values bp1 nil 2))))) (zwei:defindentation (defmethod . zwei:pcl-method-indentation)) From Owners-commonloops.pa@Xerox.COM Mon Sep 26 09:48:57 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA11046; Mon, 26 Sep 88 09:48:57 PDT Received: from Salvador.ms by ArpaGateway.ms ; 26 SEP 88 09:44:18 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 26 SEP 88 09:39:33 PDT To: commonloops.pa@Xerox.COM Subject: One more Genera bugfix. Date: Mon, 26 Sep 88 12:31:09 -0400 From: Mike Thome Message-Id: <880926-094418-3936@Xerox> This patch fixes the bug where traced generic functions cause an error if you try adding or redefining methods on that gfn (this bug was discussed a little last (?) week, and has been annoying me for the longest time....) -mike (mthome@bbn.com) = = = = = = ;;; PATCH BOOT.LISP ;;; Fixed problem where traced generic functions are not redefinable (the original ;;; of the below function took the encapsulation as the gfn itself). ;;; MT - 880926 ;;; (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) #+genera ; MT ((si:function-encapsulated-p spec) (apply #'ensure-generic-function (si:unencapsulate-function-spec spec) keys)) (existing #+Lispm (zl:signal 'generic-clobbers-function :name spec) #-Lispm (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) From Owners-commonloops.pa@Xerox.COM Mon Sep 26 10:23:19 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA21128; Fri, 23 Sep 88 17:11:10 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 17:10:38 PDT Return-Path: Redistributed: commonloops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 23 SEP 88 17:09:40 PDT Return-Path: Received: from sauron.think.com by Think.COM; Fri, 23 Sep 88 20:10:00 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Fri, 23 Sep 88 20:08:06 EDT Date: Fri, 23 Sep 88 20:08 EDT From: Jim Salem Subject: PCL Genera 7.2 bugfixes To: mthome@vax.bbn.com, commonloops.pa@Xerox.COM In-Reply-To: <880921-132646-1431@Xerox> Message-Id: <19880924000837.3.SALEM@POLYCARP.THINK.COM> One more bug fix I found absolutely necessary was to uncomment the following lines from REL-7-2-PATCHES.LISP :: (defun (:property pcl::top-level-form lt:mapforms) (original-form form usage) (lt::mapforms-list original-form form (cddr form) 'eval usage)) I could not even get the TEST.LISP file to compile without doing that. I am somewhat mystified how this could ever work without it. It was necessary both in the "8/28/88 (beta rev 1) AAAI PCL " version and the prior version. It's fantastic to have software include tests ! -- jim salem@think.com From Owners-commonloops.pa@Xerox.COM Mon Sep 26 10:53:31 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA10853; Mon, 26 Sep 88 09:29:01 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 88 08:50:28 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 26 SEP 88 08:48:28 PDT To: commonloops.pa@Xerox.COM Subject: Yet another 7.2 patch Date: Mon, 26 Sep 88 11:40:10 -0400 From: Mike Thome Message-Id: <880926-085028-3862@Xerox> The following patch fixes that annoying problem where qualified methods are not properly indented by zwei. enjoy, -mike (mthome@bbn.com) = = = = = = = = ;;; -*- Package: PCL -*- ;;; PATCH 3600-LOW.LISP ;;; patch to fix indentation of method forms in cases with qualifiers. ;;; MT - 880926 #|| ;; before... (defmethod foo ((x number) y) ; this is ok whatever) (defmethod foo :after ((x number) y) ; this is not whatever) ;; after... (defmethod foo ((x number) y) ; this is ok whatever) (defmethod foo :after ((x number) y) ; this is too, now. whatever) ||# (defun zwei:pcl-method-indentation (BP1 BP LASTPAREN lastsexp space-width sym) (declare (ignore sym space-width lastsexp)) (let* ((ipt bp1) (nsexps (do* ((sbp (zwei:forward-char lastparen 1) (zwei:forward-sexp sbp 1 nil 0 bp)) (count 0)) ((null sbp) count) (let* ((sbp1 (zwei:forward-over zwei:*whitespace-chars* sbp bp)) (ch (zwei:bp-char sbp1))) (when (zwei:bp-= sbp1 bp) (return count)) (when (= count 1) (setf ipt sbp1)) ; should this be a copy-bp? (unless (char-equal ch #\:) (incf count)))))) (case nsexps ((0 1) (values bp1 nil 2)) ((2) (values ipt nil 0)) (t (values bp1 nil 2))))) (zwei:defindentation (defmethod . zwei:pcl-method-indentation)) From Owners-commonloops.pa@Xerox.COM Mon Sep 26 11:25:13 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA11046; Mon, 26 Sep 88 09:48:57 PDT Received: from Salvador.ms by ArpaGateway.ms ; 26 SEP 88 09:44:18 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 26 SEP 88 09:39:33 PDT To: commonloops.pa@Xerox.COM Subject: One more Genera bugfix. Date: Mon, 26 Sep 88 12:31:09 -0400 From: Mike Thome Message-Id: <880926-094418-3936@Xerox> This patch fixes the bug where traced generic functions cause an error if you try adding or redefining methods on that gfn (this bug was discussed a little last (?) week, and has been annoying me for the longest time....) -mike (mthome@bbn.com) = = = = = = ;;; PATCH BOOT.LISP ;;; Fixed problem where traced generic functions are not redefinable (the original ;;; of the below function took the encapsulation as the gfn itself). ;;; MT - 880926 ;;; (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) #+genera ; MT ((si:function-encapsulated-p spec) (apply #'ensure-generic-function (si:unencapsulate-function-spec spec) keys)) (existing #+Lispm (zl:signal 'generic-clobbers-function :name spec) #-Lispm (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) From Owners-COMMONLOOPS.PA@Xerox.COM Wed Sep 28 17:32:13 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA12713; Wed, 28 Sep 88 17:32:13 PDT Received: from Riesling.ms by ArpaGateway.ms ; 28 SEP 88 16:15:18 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 ; 28 SEP 88 16:13:05 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 28 Sep 88 19:13:07 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 28 Sep 88 19:00:07 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 28 Sep 88 19:04:24 EDT Received: (from user SOBO) by s66.Prime.COM; 28 Sep 88 18:56:56 EST Subject: 8/28/88 PCL ON PRIME LUCID COMMON LISP (VERSION 1.2) To: COMMONLOOPS.PA@Xerox.COM From: SOBO@s66.Prime.COM Date: 28 Sep 88 18:56:56 EST Message-Id: <880928-161518-1882@Xerox> Does not compile. When it reaches the top-level form "(pre-make-caching-discriminating-functions" in *compiling* the file DCODE-PRE1.LISP (I don't understand why this happens since the form has an "eval-when (load)" wrapped around it), it goes into endless garbage collection. Note: the amount of dynamic structure space actually used from one garbage collect to another remains large and unchanged. If you manage to break it in the short time between garbage collections, the actual function being called is usually LUCID::%ZERO-REGION, called from PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS. Help, anyone? From Owners-commonloops.PA@Xerox.COM Wed Sep 28 17:36:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA12759; Wed, 28 Sep 88 17:36:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 17:12:12 PDT Return-Path: Redistributed: commonloops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 28 SEP 88 17:08:30 PDT Date: Wed, 28 Sep 88 15:16:20 PDT From: bmiller@vaxa.isi.edu (Brent Miller) Posted-Date: Wed, 28 Sep 88 15:16:20 PDT Message-Id: <8809282216.AA06339@vaxa.isi.edu> Received: by vaxa.isi.edu (5.54/5.51) id AA06339; Wed, 28 Sep 88 15:16:20 PDT To: commonloops.PA@Xerox.COM Subject: Does anyone have the 3/17/88 PCL ?? Cc: bmiller@vaxa.isi.edu HELP! Does anyone have the St. Patrick's Day PCL (3/17/88) ?? Our only copy of PCL (3/17/88) was deleted and expunged by mistake. And no, believe it or not, it had never been backed up! And yes, a lot of code around here depends on it! We are not yet ready to move to a more recent release of PCL (although we may have no choice now) and would GREATLY appreciate it if someone out there who has this release could send us a copy. Thanks! Brent Miller bmiller@vaxa.isi.edu (213) 822-1511 ext 273 From Owners-commonloops.PA@Xerox.COM Wed Sep 28 19:18:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13256; Wed, 28 Sep 88 19:18:20 PDT Received: from Burger.ms by ArpaGateway.ms ; 28 SEP 88 19:05:35 PDT Return-Path: Redistributed: commonloops.PA Received: from wucs1.wustl.edu ([128.252.123.12]) by Xerox.COM ; 28 SEP 88 19:03:24 PDT Return-Path: Received: by wucs1.wustl.edu (5.59/1.33); id AA17417; Wed, 28 Sep 88 21:02:49 CDT Date: Wed, 28 Sep 88 21:02:49 CDT From: grs@wucs1.wustl.edu (Guillermo Ricardo Simari) Message-Id: <8809290202.AA17417@wucs1.wustl.edu> To: commonloops.PA@Xerox.COM Subject: PCL on KCL I tried to compile PCL on AKCL (1.65) but I get a core dumped after a while. Any help? Does anybody successfully compiled it on KCL? Thank you very much in advance, Guillermo R. Simari Washington University Department of Computer Science Campus Box 1045 St. Louis, MO, 63130, U.S.A. E-Mail: grs@wucs1.wustl.edu From Owners-commonloops.pa@Xerox.COM Wed Sep 28 23:08:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA13906; Wed, 28 Sep 88 23:08:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 22:57:44 PDT Return-Path: Redistributed: commonloops.pa Received: from vlsi.caltech.edu ([192.12.18.4]) by Xerox.COM ; 28 SEP 88 22:56:16 PDT Received: by vlsi.caltech.edu (5.54/1.2) id AA15780; Wed, 28 Sep 88 22:57:48 PDT Date: Wed, 28 Sep 88 22:57:48 PDT From: newton@vlsi.caltech.edu (Mike Newton) Message-Id: <8809290557.AA15780@vlsi.caltech.edu> To: grs@wucs1.wustl.edu Subject: Re: PCL on KCL Cc: commonloops.pa@Xerox.COM Using akcl 1-65 on a sun 3 running sun3.5OS, i managed to get PCL to compile fine w/ the following two changes: [1] move init.lsp to pinit.lsp and change the defsys.lsp to reflect this change [2] When creating a load version, load 'pkg.lsp' then load all the .o files - mike ps: gcc 1.28 has a bug in it that AKCL trips on. I've searched for it, but have not found it yet. From Owners-commonloops.PA@Xerox.COM Thu Sep 29 09:13:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA17770; Thu, 29 Sep 88 09:13:42 PDT Received: from Burger.ms by ArpaGateway.ms ; 29 SEP 88 09:07:01 PDT Return-Path: Redistributed: commonloops.PA Received: from cheddar.cs.wisc.edu ([128.105.2.113]) by Xerox.COM ; 29 SEP 88 09:04:51 PDT Message-Id: <8809291603.AA05943@cheddar.cs.wisc.edu> Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Thu, 29 Sep 88 11:03:32 CDT From: "David C. Martin" Organization: University of Wisconsin - Madison Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin Phone: 608/262-6624 (O) To: bmiller@vaxa.isi.edu (Brent Miller) Cc: commonloops.PA@Xerox.COM Precedence: special-delivery In-Reply-To: Your message of Wed, 28 Sep 88 15:16:20 PDT <8809282216.AA06339@vaxa.isi.edu> Subject: Re: Does anyone have the 3/17/88 PCL ?? Date: Thu, 29 Sep 88 11:03:28 -0500 Sender: dcmartin@cs.wisc.edu You can ftp the Franz Allegro version sources from camelot.berkeley.edu. I believe the file is pcl-03.17.88.tar.Z. dcm -------- Your message: HELP! Does anyone have the St. Patrick's Day PCL (3/17/88) ?? Our only copy of PCL (3/17/88) was deleted and expunged by mistake. And no, believe it or not, it had never been backed up! And yes, a lot of code around here depends on it! We are not yet ready to move to a more recent release of PCL (although we may have no choice now) and would GREATLY appreciate it if someone out there who has this release could send us a copy. Thanks! Brent Miller bmiller@vaxa.isi.edu (213) 822-1511 ext 273 -------- From Owners-commonloops.pa@Xerox.COM Thu Sep 29 23:12:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA26105; Thu, 29 Sep 88 23:12:48 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 29 SEP 88 23:11:52 PDT Return-Path: Redistributed: commonloops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 29 SEP 88 23:10:03 PDT Posted-Date: Thu, 29 Sep 88 22:09:33 PST Message-Id: <8809300609.AA02615@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA02615; Thu, 29 Sep 88 23:09:48 PDT To: commonloops.pa@Xerox.COM Cc: brill@vaxa.isi.edu Subject: new PCL on Explorers Date: Thu, 29 Sep 88 22:09:33 PST From: Dave Brill Has anyone got the AAAI PCL running on a TI Explorer? We are having the same problem that was reported here recently, namely that &rest doesn't seem to be working right in "defsetf". This happens in "do-standard-defsetf" and causes a compilation error in DEFS. We would appreciate hearing from anyone who has a fix for this problem. Thanks. Dave Brill From Owners-commonloops.pa@Xerox.COM Fri Sep 30 07:38:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.3) id AA02671; Fri, 30 Sep 88 07:38:05 PDT Received: from Salvador.ms by ArpaGateway.ms ; 30 SEP 88 07:22:20 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 30 SEP 88 07:20:34 PDT From: Dan Cerys Sender: cerys@bbn.com To: brill@VAXA.ISI.EDU Cc: commonloops.pa@Xerox.COM In-Reply-To: Dave Brill's message of Thu, 29 Sep 88 22:09:33 PST <8809300609.AA02615@vaxa.isi.edu> Subject: new PCL on Explorers Date: Fri, 30 Sep 88 10:13:42 EDT Message-Id: <880930-072220-2058@Xerox> Dave, There is a patch from TI for the Explorer problem of DEFSETF and &rest args. You should be able to get it by calling your friendly TI support folks. BUT, this fix will only get you over one problem onto another. You will then run into a problem the first time add-method is called in vector.lisp. It looks like a macro expansion problem that results in RPLACA of NIL. I haven't had the time to check whether this is a TI problem or problem in the TI-specific PCL code (i.e., in FIN.LISP). If you find the problem, please let us know about it. Dan From Owners-CommonLoops.pa@Xerox.COM Sun Oct 2 11:58:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA20880; Sun, 2 Oct 88 11:58:28 PDT Received: from Burger.ms by ArpaGateway.ms ; 02 OCT 88 11:58:07 PDT Return-Path: <@MITVMA.MIT.EDU:AIDEN@umaecs.BITNET> Redistributed: CommonLoops.pa Received: from MITVMA.MIT.EDU ([18.92.0.3]) by Xerox.COM ; 02 OCT 88 11:56:15 PDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3065; Sun, 02 Oct 88 14:54:42 EDT Received: from UMAECS (AIDEN) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3063; Sun, 02 Oct 88 14:54:41 EDT Date: Sun, 2 Oct 88 14:51 EDT From: "Eric H. Nielsen" Subject: Bug in class allocated slot initialization To: CommonLoops.pa@Xerox.COM X-Vms-To: IN%"CommonLoops.pa@Xerox.COM",AIDEN Message-Id: <881002-115807-2605@Xerox> I am using the the pcl version 8/2/88 (beta) August 2nd, 1988 with some patches. I have found a bug in the initialization of class allocated slots: It occurs only when pcl::*slotd-unsupplied* is eq to the initialized value, e.g. t or nil. ;;; Sun Common Lisp, Development Environment 2.1.1, 4-Mar-88 ....... blah blah blah > pcl::*slotd-unsupplied* (PCL::*SLOTD-UNSUPPLIED*) > (use-package 'pcl) T > (defclass top () ((class-alloc-slot :allocation :class :initform "INIT AT THE TOP"))) NIL > (defclass bottom (top)((class-alloc-slot :allocation :class :initform nil))) NIL > (setq top (make-instance 'top) bottom (make-instance 'bottom)) # > (slot-value top 'class-alloc-slot) "INIT AT THE TOP" > (slot-value bottom 'class-alloc-slot) NIL > (setq pcl::*slotd-unsupplied* nil) NIL > (defclass middle (top) ((class-alloc-slot :allocation :class :initform nil))) NIL > (setq middle (make-instance 'middle)) # > (slot-value middle 'class-alloc-slot) "INIT AT THE TOP" > ; ; Now the instance of class "middle" has inherited the value of "class-alloc-s lot" ; from the class "top" which is incorrect. Any fixes? and does this occur with the newer release? Eric Nielsen Dept of Mechanical Engineering University of Massachusetts at Amherst AIDEN@UMAECS.bitnet From Owners-commonloops.pa@Xerox.COM Mon Oct 3 15:09:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA29947; Mon, 3 Oct 88 15:09:25 PDT Received: from Salvador.ms by ArpaGateway.ms ; 03 OCT 88 12:40:47 PDT Return-Path: Redistributed: commonloops.pa Received: from potomac.ads.com ([10.5.0.25]) by Xerox.COM ; 03 OCT 88 12:14:19 PDT Received: by potomac.ads.com (5.59/1.18) id AA08721; Mon, 3 Oct 88 14:25:59 EDT Date: Mon, 3 Oct 88 14:25:59 EDT From: Mark D. Grover Message-Id: <8810031825.AA08721@potomac.ads.com> To: commonloops.pa@Xerox.COM Subject: "incomplete" PCL definitions under Genera 7.2 I run 8/28/88 (beta rev 1) AAAI PCL under Genera 7.2 (ECO 6:System 376.158). I receive the following notification for every class I define (the PCL test file as well as my own). I have installed (in sources) the first three of the four Genera 7.2 patches posted to this mailing list. I am a novice PCL user, but familiar with the CLOS manual, Flavors and the LISPM. Has anyone else had this occur? Why is the compilation and load reported as "incomplete" by Genera? No error is reported at compilation, load or make-instance time. The notifications appear (one for each class) a few minutes after compilation, and at regular intervals thereafter. It is truly annoying. 9/27 17:22:26 While loading file LINDENWALD:>pdce>nrs>classes: A change to the type NRS:BASIC-NODE (Incomplete) started at 9/27/88 17:17:02. Until this definition is completed, the type, and the mouse sensitivity tables will be inconsistent. It is suggested you first retry the definition, to try to install a complete definition for the type. If that is successful, you will need to force the type to completion manually, as shown below. This type definition should be found in the file LINDENWALD:>pdce>nrs>classes. This may be forced to completion with the following form, but the result may not be completely consistent. (DW:FINISH-TYPE-REDEFINITION 'NRS:BASIC-NODE :FORCE-P T) - MDG - From Owners-CommonLoops.pa@Xerox.COM Tue Oct 4 17:44:18 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18365; Tue, 4 Oct 88 17:44:18 PDT Received: from Burger.ms by ArpaGateway.ms ; 04 OCT 88 16:53:00 PDT Return-Path: Redistributed: CommonLoops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 04 OCT 88 16:51:14 PDT Posted-Date: Tue, 04 Oct 88 15:50:56 PST Message-Id: <8810042350.AA20741@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA20741; Tue, 4 Oct 88 16:50:59 PDT To: CommonLoops.pa@Xerox.COM, macgreg@vaxa.isi.edu Subject: PCL on TI's Date: Tue, 04 Oct 88 15:50:56 PST From: macgreg@vaxa.isi.edu Has anyone succeeded in getting the AAAI version of PCL up on an Explorer? If so, we'd like to hear how you did it. As of last week, there were at least two major bugs that prevent successful compilation of PCL on TI Explorers. The first is due to a problem with the TI compiler's inability to handle a DEFSETF containing an &REST argument. There are a few patches floating around to correct that problem. The second problem appears to be due to problems in the TI-specific code in FIN.LISP, or maybe in TI.LOW. It occurs on the first attempt to compile a "defmethod" form in VECTOR.LISP. Fixing it appears to require the services of an expert in both low-level PCL (the funcallable instance code) and in TI internals, since all of the relevant TI functions are prefixed with SYS:. I am almost certain that I received a broadcast message from someone at MIT containing a patch for this second bug. However, no one else here at ISI received such a message, and my mailer chose that particular occasion to trash a few messages, including that one. Possibly I am hallucinating, due to overly wishful thinking. If necessary, we'll dive in and try to fix it ourselves, but we first want to find out if someone else can save us the trouble. - Bob Mac Gregor From Owners-commonloops.pa@Xerox.COM Tue Oct 4 18:00:13 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA29947; Mon, 3 Oct 88 15:09:25 PDT Received: from Salvador.ms by ArpaGateway.ms ; 03 OCT 88 12:40:47 PDT Return-Path: Redistributed: commonloops.pa Received: from potomac.ads.com ([10.5.0.25]) by Xerox.COM ; 03 OCT 88 12:14:19 PDT Received: by potomac.ads.com (5.59/1.18) id AA08721; Mon, 3 Oct 88 14:25:59 EDT Date: Mon, 3 Oct 88 14:25:59 EDT From: Mark D. Grover Message-Id: <8810031825.AA08721@potomac.ads.com> To: commonloops.pa@Xerox.COM Subject: "incomplete" PCL definitions under Genera 7.2 I run 8/28/88 (beta rev 1) AAAI PCL under Genera 7.2 (ECO 6:System 376.158). I receive the following notification for every class I define (the PCL test file as well as my own). I have installed (in sources) the first three of the four Genera 7.2 patches posted to this mailing list. I am a novice PCL user, but familiar with the CLOS manual, Flavors and the LISPM. Has anyone else had this occur? Why is the compilation and load reported as "incomplete" by Genera? No error is reported at compilation, load or make-instance time. The notifications appear (one for each class) a few minutes after compilation, and at regular intervals thereafter. It is truly annoying. 9/27 17:22:26 While loading file LINDENWALD:>pdce>nrs>classes: A change to the type NRS:BASIC-NODE (Incomplete) started at 9/27/88 17:17:02. Until this definition is completed, the type, and the mouse sensitivity tables will be inconsistent. It is suggested you first retry the definition, to try to install a complete definition for the type. If that is successful, you will need to force the type to completion manually, as shown below. This type definition should be found in the file LINDENWALD:>pdce>nrs>classes. This may be forced to completion with the following form, but the result may not be completely consistent. (DW:FINISH-TYPE-REDEFINITION 'NRS:BASIC-NODE :FORCE-P T) - MDG - From Owners-CommonLoops.pa@Xerox.COM Tue Oct 4 18:30:01 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18365; Tue, 4 Oct 88 17:44:18 PDT Received: from Burger.ms by ArpaGateway.ms ; 04 OCT 88 16:53:00 PDT Return-Path: Redistributed: CommonLoops.pa Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 04 OCT 88 16:51:14 PDT Posted-Date: Tue, 04 Oct 88 15:50:56 PST Message-Id: <8810042350.AA20741@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA20741; Tue, 4 Oct 88 16:50:59 PDT To: CommonLoops.pa@Xerox.COM, macgreg@vaxa.isi.edu Subject: PCL on TI's Date: Tue, 04 Oct 88 15:50:56 PST From: macgreg@vaxa.isi.edu Has anyone succeeded in getting the AAAI version of PCL up on an Explorer? If so, we'd like to hear how you did it. As of last week, there were at least two major bugs that prevent successful compilation of PCL on TI Explorers. The first is due to a problem with the TI compiler's inability to handle a DEFSETF containing an &REST argument. There are a few patches floating around to correct that problem. The second problem appears to be due to problems in the TI-specific code in FIN.LISP, or maybe in TI.LOW. It occurs on the first attempt to compile a "defmethod" form in VECTOR.LISP. Fixing it appears to require the services of an expert in both low-level PCL (the funcallable instance code) and in TI internals, since all of the relevant TI functions are prefixed with SYS:. I am almost certain that I received a broadcast message from someone at MIT containing a patch for this second bug. However, no one else here at ISI received such a message, and my mailer chose that particular occasion to trash a few messages, including that one. Possibly I am hallucinating, due to overly wishful thinking. If necessary, we'll dive in and try to fix it ourselves, but we first want to find out if someone else can save us the trouble. - Bob Mac Gregor From CL-Compiler-mailer@SAIL.STANFORD.EDU Wed Oct 5 13:43:28 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA00239; Wed, 5 Oct 88 13:43:28 PDT Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 12:41:50 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02898; Wed, 5 Oct 88 12:35:41 PDT Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0) id AA15109; Wed, 5 Oct 88 12:38:05 PDT Received: by lukasiewicz.sun.com (4.0/SMI-4.0) id AA09635; Wed, 5 Oct 88 11:31:32 PDT Date: Wed, 5 Oct 88 11:31:32 PDT From: jrose@Sun.COM (John Rose) Message-Id: <8810051831.AA09635@lukasiewicz.sun.com> To: jlm@lucid.com Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson%mist@MULTIMAX.ENCORE.COM Cc: sandra%defun@cs.utah.edu Cc: CL-Compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: Jim McDonald's message of Fri, 30 Sep 88 12:07:09 PDT <8809301907.AA01035@bhopal> Subject: Issue: DEFINE-OPTIMIZER Date: Wed, 28 Sep 88 15:32:23 PDT From: Jim McDonald I would prefer to see a rule-based approach, at least as the normal way of declaring optimizations. A more programmable approach would be used only when the rule processor is inadequate. E.g., I find it much easier to read rules of the form: ((*) ) or ((*) (*) ) .... Hear, hear. (See below.) Date: Wed, 28 Sep 88 17:07:21 MDT From: sandra%defun@cs.utah.edu (Sandra J Loosemore) ...while I think that just about all compilers do some kind of pattern-matching transformations, everybody seems to use a different technique and syntax for specifying them, and we'd probably get into religious wars if we tried to standardize one or another of them. (I know of at least a half-dozen different ones that have been used in the various compilers developed here at Utah within the past 2 or 3 years!) Perhaps CLOS can eventually supply a partial consensus on how to organize these things. (See below.) Date: Thu, 29 Sep 88 11:20 EDT From: Kent M Pitman I think the way Symbolics does its optimizers (I haven't looked recently) is to allow multiple optimizers on a function and to give each a name, so that you can selectively redefine each. In effect, it defines INTERNAL-DEFINE-OPTIMIZER function optimizer-name bvl &BODY forms so that (effectively) you could define DEFINE-OPTIMIZER as (DEFMACRO DEFINE-OPTIMIZER (NAME BVL &BODY FORMS) `(INTERNAL-DEFINE-OPTIMIZER ,NAME ANSI-CL-INTERFACE ,BVL ,@FORMS)) .... CLOS has a mechanism for named function parts; see below. Date: Fri, 30 Sep 88 12:07:09 PDT From: Jim McDonald ... I should note that Lucid's compiler-macro facility allows one to define a symbol to be treated as a function at eval-time but a macro at compile-time. One obvious use of compiler-macros is to implement optimizers. The drawback is the one I alluded to earlier -- there is just one compiler-macro for a symbol, so you run the risk of a brain-dead dotimes if you try to optimize it as in my example above. (I'd be tempted to suggest a compiler-macro-time analog to defadvice, but that seems too hairy, too dependent on the whole idea of compiler-macros, and too fraught with the dangers I railed against earlier.) Yes it's hairy, but maybe we can lean on CLOS. .... Attaching multiple transformation rules on one function seems superior to having to express all the logic in a monolithic optimizer function. After all, some Lisp functions will be complex enough to admit several independent optimization strategies, each encodable by a different rule. Perhaps two vendors or programmers want to add strategies to the same function; it's unclear how to do this through a monolithic optimizer. One might object that only the function's author should get to optimize it, but that's not the case when the function is well-known and the occasion for optimizing it arises when some specialized __argument__ appears for it. E.g., (SQRT (MY-EXPONENTIAL X)) => (MY-EXPONENTIAL (/ X 2)), or perhaps something like (SEARCH WORD (MY-INDEXED-STRING X)) => (MY-INDEXED-SEARCH WORD X). Even if it's agreed that we want multiple optimization rules on a single function, there is still the problem of (1) arranging for the separate compilation and eventual combination of the rules, and (2) specifying the language(s) used to write the patterns which guard the rules. I believe CLOS supplies excellent answers to (1), and eventually will enable an answer to (2). It seems to me that, in the interests of economy, whenever there is a situation in Common Lisp where multiple, separately compilable program fragments are being combined into single functions (e.g., DEFADVICE, optimizer rules), that service should be if at all possible supplied by CLOS. Using CLOS has a number of advantages: * Implementors have less work, since they use CLOS method combination machinery. In some cases, they may only need to write a DEFINE-METHOD-COMBINATION which organizes the program fragments the way they want. * Users have a standard interface for defining, undefining, and querying for program fragments. * Any CLOS program management tools (e.g., browsers) are immediately applicable. To summarize, you get the usual advantages of integration. Classes per se needn't enter the picture at all. I'm thinking of something like this, for starters: (defmethod compiler:transform sqrt-exp ((fn (eql 'sqrt)) &rest args) (backquote-case args (`((my-exp ,x)) `(my-exp (/ ,x 2))) (otherwise (call-next-method)))) (In place of the hypothetical BACKQUOTE-CASE, put your own favorite pattern matcher.) The key is using the method qualifier syntax (SQRT-EXP, here) for differentiating fragments of code. If the CLOS specializer syntax is usable ((EQL 'SQRT), here), that's great, but unspecialized methods are perfectly valid too. [Parenthetical Note: To implement advice this way, you'd probably want to introduce a new function specifier syntax, analogous (SETF FOO): (defmethod (advise foo) :before ensure-open-foo-files (&rest ignore) (declare (ignore ignore)) (unless (foo-files-open-p) (open-foo-files))) Note that use of two method qualifiers. That's OK, and the abstraction's DEFINE-METHOD-COMBINATION declaration gets to assign the appropriate meaning to them.] That should show how CLOS addresses problem (1), of managing code fragments. Problem (2), the construction of rule guard patterns, may be partially addressible in CLOS, some day. The key is realizing that your favorite pattern language for Lisp forms probably has enough structure to impose a type/subtype structure on the universe of Lisp forms. In other words, it makes sense to pretend that patterns in your language (e.g., `((my-exp ,x)) above) define form types, and that there is an inclusion structure on these types, with less specific patterns being supertypes. (When talking about these issues to the CLOS people, I have referred to such a system of patterns or predicates as a "description language".) If CLOS provides enough extensibility of specializer syntax (and that's a big if, actually), it will be possible to express optimizer rules even more cleanly, using CLOS. Here's a final example, in which a form-discriminating specializer is used (with a syntax pulled out of a hat, I admit): (defmethod compiler:transform ((:form `(sqrt (my-exp ,x)))) `(my-exp (/ ,x 2))) Note that since the specializers suffice to differentiate the rules, there is less need for qualifiers (e.g., the symbol SQRT-EXP above). The CLOS spec. does not discuss extensibility of specializers, yet. For this, we await the famous but mysterious third chapter of the spec, the Meta-Object Protocol. By the way, a useful second argument to COMPILER:OPTIMIZE would be an environment, to allow for type checking or macroexpansion. I've used list structure patterns in the examples above, but I could equally well have used patterns which discriminated things like declared type, if I understood enough about Lisp compiler type inference to construct a plausible example. As Sandra says, there are any number of pattern languages out there. I'm certainly not suggesting it's easy to settle on one, but I am saying that using CLOS would help us settle some of the simpler issues (like separate compilation of rules), allowing us to devote more energy to the hard ones (like pattern languages). In fact, I don't see why several pattern languages couldn't be used in the same Lisp. After all, EQL and class specializers co-exist now, and they could be viewed as two different languages. The bottom line is that CLOS has a lot of services to offer, and Common Lisp should take advantage of them where possible. -- John From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Oct 5 15:05:04 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA01591; Wed, 5 Oct 88 15:05:04 PDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:03:16 PDT Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59461; 5 Oct 88 17:50:52 EDT Date: Wed, 5 Oct 88 17:52 EDT From: Brad Miller Subject: Q about CLOS To: common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <19881005215228.4.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 None of the doc I've scrounged for CLOS answers this simple question, so anyone who can enlighten me, thanks... is EVAL a generic function (message)? is APPLY? Thanks, ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller} From Owners-commonloops.pa@Xerox.COM Wed Oct 5 17:40:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA03255; Wed, 5 Oct 88 17:40:20 PDT Received: from Burger.ms by ArpaGateway.ms ; 05 OCT 88 10:24:07 PDT Return-Path: Redistributed: commonloops.pa Received: from mitre-bedford.ARPA ([26.3.0.66]) by Xerox.COM ; 05 OCT 88 10:20:11 PDT Posted-From: The MITRE Corp., Bedford, MA Received: from faron.sun.uucp by linus.MENET (3.2/4.7) id AA12761; Wed, 5 Oct 88 13:18:10 EDT Posted-Date: Wed, 05 Oct 88 13:18:06 EDT Received: from localhost by faron.sun.uucp (3.2/SMI-3.0DEV3) id AA04166; Wed, 5 Oct 88 13:18:08 EDT Message-Id: <8810051718.AA04166@faron.sun.uucp> To: CommonLoops.pa@Xerox.COM Cc: grover@potonac.ads.com, mthome@vax.bbn.com Subject: Yes, it is truly annoying..... Date: Wed, 05 Oct 88 13:18:06 EDT From: rich%linus@mitre-bedford.ARPA Received: by potomac.ads.com (5.59/1.18) id AA08721; Mon, 3 Oct 88 14:25:59 EDT Date: Mon, 3 Oct 88 14:25:59 EDT From: Mark D. Grover To: commonloops.pa@Xerox.COM Subject: "incomplete" PCL definitions under Genera 7.2 I receive the following notification for every class I define (the PCL test file as well as my own). I have installed (in sources) the first three of the four Genera 7.2 patches posted to this mailing list. Has anyone else had this occur? Why is the compilation and load reported as "incomplete" by Genera? No error is reported at compilation, load or make-instance time. The notifications appear (one for each class) a few minutes after compilation, and at regular intervals thereafter. It is truly annoying. Yes, we have encountered this error, and we are mystified too! SOME of these errors seem to go away when we re-compiled, re-booted and then re-loaded. From Owners-commonloops.pa@Xerox.COM Wed Oct 5 17:46:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA03451; Wed, 5 Oct 88 17:46:08 PDT Received: from Burger.ms by ArpaGateway.ms ; 05 OCT 88 08:31:47 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 ; 05 OCT 88 08:29:10 PDT Received: from ENB.Prime.COM by EN-C06.Prime.COM; 05 Oct 88 11:28:59 EDT Received: from ENI.Prime.COM by ENB.Prime.COM; 05 Oct 88 11:19:07 EDT Received: from s66.Prime.COM by ENI.Prime.COM; 05 Oct 88 11:23:29 EDT Received: (from user SOBO) by s66.Prime.COM; 05 Oct 88 11:15:52 EST To: commonloops.pa@Xerox.COM From: SOBO@s66.prime.com Date: 05 Oct 88 11:15:52 EST Message-Id: <881005-083147-490@Xerox> To: (commonloops.pa@xerox.com) From: Nadine Sobolevitch (sobo@s66) Date: 05 Oct 88 10:41 AM Subject: Compiling 8/28/88 PCL on Prime Lucid Common Lisp There is an endless (garbage-production and) garbage-collection loop that occurs during the compilation of the file pcl/dcode-pre1.lisp when you try to compile the new PCL on Lucid Common Lisp on the Prime. I sent a note on this problem to the commonloops mailing list about a week ago. Owing to mailer problems at this end of the line, I don't know if the note reached its destination or not. My apologies if this is a duplicate. And if anybody has seen any *response* to the previous note, could someone please send me a copy? Note: the distribution file pcl/lucid-low.lisp has some bugs which we have fixed in order to get this far in the compilation. In particular, the redefination of sys::defadvice should be the redefinition of lucid:: defadvice (and similarly for some functions called by defadvice). Lisp was called with 48 reserved segments and 128 dynamic segments. (64 kbytes/segment) ;;; Lucid Common Lisp, Version 1.2, June 22, 1988 ;;; Copyright (C) 1988 by Lucid, Inc. All Rights Reserved ;;; EDIT-CMD-LINE installed. > (load "clos*>pcl-aaai>defsys.lisp") ;;; Loading source file "CLOS*>PCL-AAAI>DEFSYS.LISP" #P"CLOS*>PCL-AAAI>DEFSYS.LISP" > (in-package 'pcl) # > (compile-pcl) Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of LUCID-LOW... ;;; Warning: Redefining %LOGAND ;;; Warning: Redefining MAKE-MEMORY-BLOCK ;;; Warning: Redefining OBJECT-CACHE-NO ;;; Warning: Redefining SET-FUNCTION-NAME-1 ;;; Warning: Redefining PRINTING-RANDOM-THING-INTERNAL 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... Compiling DCODE-PRE1... ;;; Reading input file #P"CLOS*>PCL-AAAI>DCODE-PRE1.LISP" ;;; GC: 104478 words [417912 bytes] of dynamic storage in use. ;;; 1992172 words [7968688 bytes] of free storage available before a GC. ;;; 4088822 words [16355288 bytes] of free storage available if GC is disabled. ;;; GC: 104476 words [417904 bytes] of dynamic storage in use. ;;; 1992174 words [7968696 bytes] of free storage available before a GC. ;;; 4088824 words [16355296 bytes] of free storage available if GC is disabled. *** Deferring This Asynchronous Interrupt *** >>Deferred Interrupt (noticed during function return): QUIT$ LUCID:%ZERO-REGION: Required arg 0 (ADDRESS): 220397568 Required arg 1 (SEGMENT-COUNT): 1 :A Abort to Lisp Top Level :C Will resume normal return -> :b LUCID:%ZERO-REGION <- PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS <- LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- LET <- IF <- PROGN <- BLOCK <- COMPILE-MODULE <- IF <- ECASE <- LET <- PROGN <- PROGN <- TAGBODY <- BLOCK <- PROGN <- LABELS <- LET <- PROGN <- LET <- BLOCK <- OPERATE-ON-SYSTEM <- RETURN-FROM <- IF <- PROGN <- BLOCK <- BLOCK <- COMPILE-PCL <- EVAL <- unnamed function -> :n PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS: Required arg 0 (FORM): (PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS ((1 NIL # ...) (2 NIL # ...) (2 NIL # ...) ...)) Required arg 1 (ENVIRONMENT): NIL -> :n LUCID:COMPILE-FORM: Required arg 0 (FORM): (PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS ((1 NIL # ...) (2 NIL # ...) (2 NIL # ...) ...)) Required arg 1 (MODE): LUCID::NOT-COMPILE-TIME Required arg 2 (OUTPUT): # Rest arg (OUTARGS): (# # #) -> :n LUCID:COMPILE-FORM: Required arg 0 (FORM): (EVAL-WHEN (LOAD) (PRE-MAKE-CACHING-DISCRIMINATING-FUNCTIONS (# # # ...))) Required arg 1 (MODE): LUCID::NOT-COMPILE-TIME Required arg 2 (OUTPUT): # Rest arg (OUTARGS): (# # #) -> :n LET: Original code: (LET ((NAME #)) (COMPILE-FILE (MAKE-SOURCE-PATHNAME NAME) :OUTPUT-FILE ...)) Local 0 (NAME): DCODE-PRE1 -> (room t) ;;; 296416 words [1185664 bytes] of dynamic storage in use. ;;; 1800234 words [7200936 bytes] of free storage available before a GC. ;;; 3896884 words [15587536 bytes] of free storage available if GC is disabled. ;;; Semi-space Size: 4096K bytes [64 segments] ;;; Current Dynamic Area: Dynamic-0-Area ;;; GC Status: Enabled ;;; Reserved Free Space: 1920K bytes [30 segments] ;;; Memory Growth Limit: 32768K bytes [512 segments], total ;;; Memory Growth Rate: 256K bytes [4 segments] ;;; Reclamation Ratio: 33% desired free after garbage collection ;;; Area Information: ;;; Name Size [used/allocated] ;;; ---- ---- ;;; Dynamic-0-Area 580K/4096K bytes, 10/64 segments ;;; Dynamic-1-Area 0K/4096K bytes, 0/64 segments ;;; Static-Area 867K/892K bytes, 14/14 segments ;;; Readonly-Pointer-Area 295K/320K bytes, 5/5 segments ;;; Readonly-Non-Pointer-Area 1782K/1791K bytes, 28/28 segments NIL -> :a ;;; Compilation aborted, object file not written Back to Lisp Top Level > (user::quit) From Owners-commonloops.pa@Xerox.COM Wed Oct 5 17:53:59 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA03667; Wed, 5 Oct 88 17:53:59 PDT Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 10:08:16 PDT Return-Path: Redistributed: commonloops.pa Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 05 OCT 88 10:05:49 PDT Received: from host52430 by media-lab.media.mit.edu (5.59/4.8) via CHAOS with CHAOS id AA26588; Wed, 5 Oct 88 12:56:38 EDT Date: Wed, 5 Oct 88 12:56 EDT From: michael sokolov Subject: errors compiling pcl under Symbolics 7.1 To: commonloops.pa@Xerox.COM Message-Id: <881005125621.1.SOKOLOV@SCIENCE-PARK.MEDIA.MIT.EDU> While compiling slots.lisp, I got the following error: Error: The symbol NIL has an invalid function definition... (This while compiling (defmethod (setf class-direct-methods)... ). In fact, this error seems to crop up whenever I try to compile a setf method; i.e. something that looks like (defmethod (setf foo) (args) (etc)(etc)) Unfortunately, I am not enough of a Symbolics wizard to be able to figure out what is going on. Has anyone else run into this problem, and if so do you know what to do about it? We have begun to depend rather heavily on PCL here, and unfortunately I blew away our pre-AAAI PCL when I I ftp'ed the new one, so I'd very much like to get this new PCL working ASAP Thanks, Mike Sokolov From Owners-commonloops.pa@Xerox.COM Wed Oct 5 19:19:57 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA04693; Wed, 5 Oct 88 19:19:57 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 05 OCT 88 19:11:39 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 05 OCT 88 19:10:05 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Wed, 5 Oct 88 19:09:37 pdt Received: from loopback by hplwhh.HPL.HP.COM; Wed, 5 Oct 88 19:09:15 pdt To: commonloops.pa@Xerox.COM Subject: tracing generic functions X-Mailer: mh6.5 Date: Wed, 05 Oct 88 19:09:13 PDT Message-Id: <7603.592106953@hplwhh> From: Warren Harris Does the CLOS spec say anything about what should happen when you trace a generic function? I notice that in the AAAI PCL (Lucid) the following doesn't work: > (trace no-applicable-method) (NO-APPLICABLE-METHOD) > (generic-function-methods #'no-applicable-method) >>Error: No matching method for the generic-function #, when called with arguments (#). NOTICE-METHODS-CHANGE-2: Required arg 0 (GENERIC-FUNCTION): # Required arg 1 (ARGS): (# #) :A Abort to Lisp Top Level -> Sorry if this is in the spec and I missed it. Warren From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Oct 5 19:35:40 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA05025; Wed, 5 Oct 88 19:35:40 PDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 19:34:00 PDT Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59502; 5 Oct 88 22:21:29 EDT Date: Wed, 5 Oct 88 22:23 EDT From: Brad Miller Subject: Re: Issue: EVAL-OTHER (Version 2) To: common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <881005-152958-1624@Xerox> Message-Id: <19881006022307.0.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 I'd like to propose an alternative (or rather elaboration) to EVAL-OTHER:SELF-EVALUATE, currently... Proposal (EVAL-OTHER:SELF-EVALUATE): Standard data types (those mentioned by CLtL) other than those for which a more explicit evaluation rule exists would be defined to self-evaluate. Such data types include, for example, structures, arrays, vectors, and pathnames. Structure types defined by users using DEFSTRUCT should also self-evaluate unless an explicit implementation type for the structure is given in the DEFSTRUCT, in which case the rule for evaluation of that type should be used. (This is important in the case of type LIST.) I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that explicitly specifies the eval behavior. Rational: When using lisp to build an embedded language, one can already define via a DEFSTRUCT option what the printer for the object should be. One can also, via character macros define a specific parse behavior. One cannot, however, currently define an EVAL behavior. For example, I can define #\[ and #\] to denote the beginning and end of information for consing a structure FOO via character macros which will print the same way. e.g. [A FOO] may really be internally #S(FOO SLOT1: A SLOT2: FOO SLOT3: NIL) what I may want to define is that (cons [A FOO] [B FOO]) return (A B) because the EVAL option on foo returned the value of SLOT1. In general, one could define that instances and structure objects (the latter are probably instances given CLOS) all handle an EVAL message which the user can use to explicitly define the behavior. The default handler returns the object itself, which is compatible with the EVAL-OTHER:SELF-EVALUATE proposal already made. Similar arguments to the above can be made for APPLY. The ultimate idea is that user created objects can be treated as first class objects, just like symbols. Comments? ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller} From Owners-CommonLoops.pa@Xerox.COM Wed Oct 5 19:58:50 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA05559; Wed, 5 Oct 88 19:58:50 PDT Received: from Burger.ms by ArpaGateway.ms ; 05 OCT 88 19:52:01 PDT Redistributed: CommonLoops.pa Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 19:50:06 PDT Date: 5 Oct 88 19:50 PDT From: lanning.pa@Xerox.COM Subject: Re: Needed: Info on LISP X based toolkits In-Reply-To: salem@Think.COM's message of Mon, 26 Sep 88 03:45:54 EDT To: cl-windows@Think.COM, CommonLoops.pa@Xerox.COM Message-Id: <881005-195201-2107@Xerox> I would like to take this opportunity to flame about CLUE, in the hope that somebody out there will take the time to educate me. I hope this stirs up a debate on both lists. [Note: when I say "lisp", I mean Common Lisp. And CLOS is an official part of Common Lisp.] CLUE claims to be an object-oriented, portable user-interface toolkit written in lisp. To quote from the manual: CLUE could be described as a translation of the X-Toolkit "intrinsics" into the domain of Common Lisp and CLOS. The problem is that this is modeling a large object-oriented Lisp program on the X-Toolkit. Now if the X-Toolkit were a great example of o-o programming, or if Lisp were no better at o-o programming than C, this might make sense. But if those statements were true, I can't see that Lisp has anything to offer beyond C, and I think we should just trade in our ()'s for {}'s. There is one possible reason for basing CLUE on the X-Toolkit: if there were a way of importing C code from the toolkit in a way that made it follow the CLUE protocol exactly. That could win because we (Lisp'ers) could take advantage of their (C'ers) code without having to think twice. But I haven't heard anybody mention this possibility. Even if this were possible, there is no portable way to import foreign code. Finally, this argument is based entirely on economics. Not that I have much against economics, but I don't think it is the only (or even the major) measure of worth. The history of o-o programming and window environments are closely coupled. With lisp we can do much more that duplicate some other conception of a UI toolkit. But this will take time and effort. CLOS is a new and unique language; it is elegant, powerful, efficient (well, maybe), and fun. We have not had enough experience to understand what the "correct" style of programming in CLOS is, or know how it will change the way we think about programming. What is needed is not a premature UI toolkit standard based on some impoverished language's notion of programming, but a long-term effort by a large community to try to understand what CLOS really is, what it is really good for, and what it says about the ways to construct such a system. Let a thousand systems bloom. And for god's sake, let them bloom in public where we can all appreciate them and learn from them. Now that I've stepped on almost everybody's toes, is there anybody out there with something to say? Speak up now... -smL From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Wed Oct 5 23:13:27 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA10898; Wed, 5 Oct 88 23:13:27 PDT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 23:12:15 PDT Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471537; Thu 6-Oct-88 02:10:54 EDT Date: Thu, 6 Oct 88 02:10 EDT From: Kent M Pitman Subject: Re: Issue: EVAL-OTHER (Version 2) To: miller@CS.Rochester.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Wed, 5 Oct 88 22:23 EDT From: Brad Miller ... I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that explicitly specifies the eval behavior. ... The problem to this is that it's the same as allowing fexprs. This is something we've worked hard to eliminate from CL because it is opaque to compilation. You could argue that MACROEXPAND-1 should be a generic function I suppose. I have no strong feeling on that subject right now, but I'm biased against it because we are very close to casting this stuff in concrete and I don't feel totally comfortable that I understand the consequences of doing so. One minor procedural matter: You're more likely to get this considered if you write up the proposal in full rather than just as a little fragment. I count 194 cleanup topics that have been raised, and it's getting harder and harder to `maintain' them. Some are destined to fall through the cracks for lack of time and anything that people have a minor bias against can be very easily pocket-veto'd if it doesn't come in in a form that we can directly vote on... From Owners-commonloops.pa@Xerox.COM Thu Oct 6 04:10:47 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA00689; Thu, 6 Oct 88 04:10:47 PDT Received: from Salvador.ms by ArpaGateway.ms ; 06 OCT 88 00:20:26 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 06 OCT 88 00:17:51 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 00:16:12 pdt Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 00:15:49 pdt To: lanning.pa@Xerox.COM Cc: cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM Cc: bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com Subject: Re: Needed: Info on LISP X based toolkits In-Reply-To: Your message of "05 Oct 88 19:50:00 PDT." <881005-195201-2107@Xerox> Date: Thu, 06 Oct 88 00:15:45 PDT Message-Id: <8041.592125345@hplwhh> From: Warren Harris > I would like to take this opportunity to flame about CLUE, in the hope that > somebody out there will take the time to educate me. I hope this stirs up > a debate on both lists. About a year and a half ago there was a long discussion between Mike McMahon, Robert Scheifler and myself regarding whether CLX should be required to be object-oriented or not. I'm just wondering if a year and a half and a CLUE later, if there isn't some new insight or consensus in this area. As Mike pointed out, there should be several abstract layers to a window system: 1. definition of the virtual console - the X server protocol 2. language bindings for level (1) - CLX 3. window/stream objects - requires CLOS - requires CL streams to be implemented as objects 4. access to the window manager (?) 5. a full UIMS system (??) One of the fundamental questions raised was whether (2) should be visible from (3) or not -- that is, should the programmer know anything about CLX in order to program his native "window system" (albeit Genera, Common Windows, etc.). The answer to this should be no, since the goal is to provide the programmer with a nice high-level interface environment, and backwards compatibility when and if (3) is reimplemented atop CLX. In this case, it is irrelevant whether CLX is implemented with objects or not. However, when the issue of portability arises, the programmer will be forced to revert to CLX (being a part of the CL specification), or some layer defined on top of CLX (such as CLUE). The question arises again whether CLX should be visible to this new layer (call it (2.5)). In this case the answer is probably yes, since you are undoubtedly programming to extend this lowest common denominator. Now the implementation of CLX *is* relevant. One might argue that level (3) might be entirely adopted by CL and consequently the issue of its portability goes away. CLUE might be viewed as an attempt at this, but it has taken the approach of leaving various parts of CLX visible (so it is really a (2.5)). Adopting a full level (3) would pretty much leave (2) obsolete, and since level (3) would then have to be at least as powerful as (2), we would consequently be programming to just a different version of (2). This argues for the (2.5) (CLUE) approach: use some of CLX when appropriate, and use object-oriented programming when we must extend it. Several objections have been raised to object-orienting CLX. One is that the window system protocol must be well thought out: > I should also point out that the message passing LISP machine window > system has a big pitfall. One must be crystal clear on the contract of > those messages, i.e. on the window protocol. In some cases, this is > done reasonably well; for example, there is a proper distinction between > :SET-EDGES and :CHANGE-OF-SIZE-OR-MARGINS. However, no such factoring > out has been done for :EXPOSE. This makes the interposition of > application specific behavior problematic, and quite subject to the > whims on flavor method combination. This is really a no-op argument. Why wasn't the lisp machine window system protocol fixed or enhanced? If the real reason was backwards compatibility, we're not faced with that problem while trying to define a standard. Hopefully our past experience with the lisp machine and sufficient experience with CLX will help us standardize on both a necessary and sufficient protocol. Another objection raised was the violation of low level contracts by subclasses of the window class: > For similar reasons, I object to > the methodology in some window systems of building cursor-following > graphics by means of daemons on the fundamental graphics methods. By > doing so, you completely muddle the contract of those methods, and almost > guarantee that 50% of the graphics library routines you might want to > call won't work in your window. I argue that this is exactly what object-oriented programming is for. How can you define "won't work"? Violation of the programmer's intention? If the real worry is that critical subsystems will seize up because we've redefined some system method, this is not possible. Since the X server is communicated with through a well defined (non object-oriented) protocol, the server will never freeze because some client defined a bad application. The application simply will not run. I must point out that I believed all these objections for a while, but after trying to define my own (2.5) window system, I realized that 50% of it was simply shadowing what my level (2) protocol (an Xlib foreign function interface) already provided. There were window, font, pixmap, display and other objects that corresponded directly to X concepts. There were methods that directly corresponded to X requests (xe:resize was equivalent to xlib:XConfigureWindow). I had given the programmer the ability to override or attach daemons to X operations (which is what I wanted to accomplish, as does CLUE). The disadvantage was that I had succeeded in giving the programmer a whole new way of naming the same operations. (As an aside: I never understood why CLX didn't use the same naming conventions as Xlib. Being unfortunate and sometimes having to resort to C, that's one more set of bindings I have to learn!) I'm not really suggesting that CLX exactly mimic Xlib. On the contrary I would like to see some of Xlib's concepts eradicated from CLX. An example is the distinction between font and font-info structures. I think these are in Xlib simply as an excuse for not having multiple return value and keyword parameters. Why should the user have to know what properties of a font reside in the font itself, and what properties reside in the "info" structure? Lisp offers many advantages over C, not the least of which is the ability to define dynamically scoped macros such as with-state which greatly enhance the efficiency of CLX while making the programmer's job easier. The fact that C can't do this is unfortunate. C programmers have to think harder. I believe CLX should be modernized to the point of embracing object-oriented programming. In combination with CLOS, it would provide an extensible platform upon which to build a level (3), (4) or (5) interface system. The higher levels would not be confined to expose any of CLX or X server concepts, but would be allowed to if they so desired. CLUE could be implemented on such a platform in a *portable* way. (One of the objections I have to CLUE is that you must bastardize your version of CLX to run it. Some day this won't be possible.) I object to CLUE for several reasons. Primarily, it seems to be an excuse for what CLX is not. I'm not saying the concept of a Common Lisp User Environment should be eliminated, but we should rethink what we mean by supporting various levels of a window system. I think this means providing a set of classes which understand both the X server and the necessities of CL (such as streams), and a means of extending these classes when *necessary*. CLX already makes a feeble attempt at objects with defstructs. If it really meant what it said about the various levels in a window system, why didn't it just pass around X id's as integers? That's what Xlib does. (CLX programmers actually get handed these ids in event-handler routines. They don't tell you what to do with them thought (like how to lookup the associated xlib:window object).) I also object to CLUE as it stands for other reasons. For one, the degree to which CLUE is object-oriented is completely ad hoc. Why can't I specialize the xlib:font or xlib:display class? (I actually tried to do this recently, in the same way CLUE redefines xlib:window. Then I realized that xlib:display is a subtype of xlib:buffer for *efficiency* reasons!) Related to this is the fact that none of the operations on the classes xlib:drawable, xlib:window and xlib:pixmap were made generic. If I want to specialize xlib:window or xlib:contact in CLUE, why can't I write a map-window method? (Was this in the name of efficiency or what?) Finally, the notion of callbacks seems more like a throwback to C to me. Perhaps this is what Lanning is alluding to in his comments about the XToolKit. Why aren't these callbacks generic functions which can be overridden or inherited by subclasses of the class for which they're defined? That would seem cleaner and more straight forward to me. Perhaps the primary consideration in the back of the CLX implementors heads is that of efficiency -- will object-oriented programming slow down CLX too much? Maybe this is the real motivation behind the cursor-following graphics argument. If this consideration is relevant for CLX, then isn't it relevant for all object-oriented programs? Or are there classes of applications that demand efficiency at the cost of extensibility? Is CLX such an application? I remember the same arguments being made for the CLOS meta-object protocol, Smalltalk contexts, etc. I think if we're going to take that kind of attitude ("object-oriented programming is ok for fooling around, but when it comes to 'production quality code'...") we're kidding ourselves. I'm sorry if the flames are hot. I appreciate the insight and effort that went into both CLX and CLUE. CLUE is a step in the right direction because it manifests X concepts in an extensible way. I just think we would be premature to adopt either of them at their current conceptualization. Since CLUE goes against Scheifler and McMahon's original considerations about encapsulating the lowest level of the window system, I'm curious what they think now that it seems to have caught on. Warren Harris HP Labs From Owners-commonloops.pa@Xerox.COM Thu Oct 6 08:13:33 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA01860; Thu, 6 Oct 88 08:13:33 PDT Received: from Riesling.ms by ArpaGateway.ms ; 06 OCT 88 08:09:51 PDT Return-Path: <@KILLINGTON.LCS.MIT.EDU:RWS@zermatt.lcs.mit.edu> Redistributed: commonloops.pa Received: from EXPO.LCS.MIT.EDU ([18.30.0.212]) by Xerox.COM ; 06 OCT 88 08:07:31 PDT Received: by expo.lcs.mit.edu; Thu, 6 Oct 88 09:43:29 EDT Date: Thu, 6 Oct 88 09:43 EDT From: Robert Scheifler Subject: CLUE and CLX To: harris%hplwhh@hplabs.hp.com, lanning.pa@Xerox.COM Cc: cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com In-Reply-To: <8041.592125345@hplwhh> Message-Id: <19881006134336.7.RWS@KILLINGTON.LCS.MIT.EDU> Date: Thu, 06 Oct 88 00:15:45 PDT From: Warren Harris As an aside: I never understood why CLX didn't use the same naming conventions as Xlib. I'm not sure exactly what you mean by "the same" here. We wanted the CLX stuff in it's own package, and it didn't seem to make too much sense to me to put in a redundant prefix "X" (e.g. xlib:x-create-window). Also, Xlib uses CapitalizationToDistinguishWords, and the general CL convention is-to-use-hyphens, and CLX follows that convention. The CLX interface was largely defined "ignorant of Xlib", so as to keep an open mind about how it should be structured. After the fact, we did do a comparison, and my recollection is that they are reasonably close. But, I think CLX kept a little closer to the names used in the protocol spec, whereas Xlib kept a little closer to names that were used in X10. On the contrary I would like to see some of Xlib's concepts eradicated from CLX. An example is the distinction between font and font-info structures. There are no font-info structures in CLX, in case someone was confused by an implication here. I believe CLX should be modernized to the point of embracing object-oriented programming. I would be interested in understanding more specifically what you have in mind. If it really meant what it said about the various levels in a window system, why didn't it just pass around X id's as integers? The only reason Xlib doesn't pass around an "object" for a resource is because of garbage collection problems. Early Xlibs (previous versions of X) went back and forth on this one, trying to do what CLX does but failing due to the C environment. The bundling exists because it is very convenient. CLX programmers actually get handed these ids in event-handler routines. Yes, there were efficiency arguments here, perhaps inconsequential ones. They don't tell you what to do with them thought (like how to lookup the associated xlib:window object). The CLX doc does tell you to use make-window to perform this mapping. Perhaps the primary consideration in the back of the CLX implementors heads is that of efficiency -- will object-oriented programming slow down CLX too much? That wasn't the motivation. Partly it was an issue of whether a single object system was sufficiently stable and standardized to be able to make it a requirement (the answer seemed to be No). Also lurking around was the notion of being able to use essentially the same interface in other lisp dialects. Also, it wasn't at all obvious that we could quickly reach consensus on what an O-O CLX should look like (in terms of raising CLX to a higher level). And, it wasn't at all obvious that CLX should show through at the higher level (all the issues you enumerated). Since CLUE goes against Scheifler and McMahon's original considerations about encapsulating the lowest level of the window system, I'm curious what they think now that it seems to have caught on. I have too many flowers blooming right now, and I have a hard time keeping up with all the details of all of them. I do not consider myself a Lisp/OOPS expert in the same league as many of the rest of you out there; I'd much rather have you experts combine forces to produce the right thing. From Owners-CommonLoops.pa@Xerox.COM Thu Oct 6 08:16:40 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA01894; Thu, 6 Oct 88 08:16:40 PDT Received: from Salvador.ms by ArpaGateway.ms ; 06 OCT 88 08:09:53 PDT Return-Path: <@KILLINGTON.LCS.MIT.EDU:RWS@zermatt.lcs.mit.edu> Redistributed: CommonLoops.pa Received: from EXPO.LCS.MIT.EDU ([18.30.0.212]) by Xerox.COM ; 06 OCT 88 08:08:23 PDT Received: by expo.lcs.mit.edu; Thu, 6 Oct 88 08:13:54 EDT Date: Thu, 6 Oct 88 08:14 EDT From: Robert Scheifler Subject: at least one's blooming To: lanning.pa@Xerox.COM, cl-windows@think.com, CommonLoops.pa@Xerox.COM In-Reply-To: <881005-195006-2101@Xerox> Message-Id: <19881006121402.1.RWS@KILLINGTON.LCS.MIT.EDU> Date: 5 Oct 88 19:50 PDT From: lanning.pa@xerox.com What is needed is not a premature UI toolkit standard Who said anything about CLUE being a standard (adopted by whom)? Let a thousand systems bloom. And for god's sake, let them bloom in public where we can all appreciate them and learn from them. Thankfully, TI is taking on the burden of making one system bloom, and bloom in public. If you have specific criticisms of CLUE or suggestions for improvements, I'm positive the CLUE folks would love to have your input. They've been quite responsive to other people's comments. If you've got a better system in mind, by all means describe it, and go off and implement it and make it public. From Owners-commonloops.pa@Xerox.COM Thu Oct 6 08:21:50 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA01916; Thu, 6 Oct 88 08:21:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 88 08:16:53 PDT Return-Path: Redistributed: commonloops.pa Received: from cu-arpa.cs.cornell.edu ([128.84.253.3]) by Xerox.COM ; 06 OCT 88 08:13:12 PDT Received: from WRATH.CS.CORNELL.EDU by cu-arpa.cs.cornell.edu (5.59/4.30) id AA14196; Thu, 6 Oct 88 11:11:43 EDT From: klapper@antiphos.UUCP Received: by wrath.cs.cornell.edu (5.54/4.30) id AA09172; Thu, 6 Oct 88 11:11:14 EDT Received: by oravax.UUCP (5.51/5.17) id AA29620; Thu, 6 Oct 88 10:59:09 EDT Received: by antiphos.UUCP (3.2/SMI-3.2) id AA10995; Thu, 6 Oct 88 10:59:59 EDT Date: Thu, 6 Oct 88 10:59:59 EDT Message-Id: <8810061459.AA10995@antiphos.UUCP> To: commonloops.pa@Xerox.COM, victoria.media.mit.edu@VICTORIA.MEDIA.MIT.EDU Subject: Re: errors compiling pcl under Symbolics 7.1 Cc: hook%antiphos@cu-arpa.cs.cornell.edu, klapper%antiphos@cu-arpa.cs.cornell.edu You should incorporate some patches for Genera 7.2 that Mike Thome submitted to this mailing list a couple of weeks ago. In particular, his load-defmethod and load-defmethod-internal patches fix the definition of methods for setf's. Allow me to take this opportunity to present the changes which allowed us to get PCL up and running on the Symbolics under Genera 7.1. This may be incomplete, since several patches from this mailing list may have been installed before I got my hands on it. I have presented top-level forms in their entirety rather than incremental directions so that all changes to that form, both known and unknown, are reflected. ------------------------Start of changes---------------------------- ;;; Changes to PCL for 7.1 which allowed our stuff to work ;;; Changes to 3600-low ;;; Comments removed (Thome's patch) (defun record-definition (type spec &rest args) (declare (ignore args)) (case type (method (if (listp (cadr spec)) (si:record-source-file-name spec 'method) (si:record-source-file-name spec 'method))) (class (si:record-source-file-name spec 'defclass) (si:record-source-file-name spec 'deftype) ))) ;;; eq -> equal (Thome's patch) (defvar *method-fdefs* (make-hash-table :test #'equal :size 500)) (defvar *method-setf-fdefs* (make-hash-table :test #'equal :size 500)) ;;; Added (fboundp 'generic-function-p) before it is called. ;;; Fails miserably without it (defun setup-function-specs-to-edit-advice-1 (spec) (and (or (symbolp spec) (and (listp spec) (eq (car spec) 'setf))) (gboundp spec) (fboundp 'generic-function-p) (generic-function-p (gdefinition spec)) (mapcar #'(lambda (m) (make-method-spec spec (method-qualifiers m) (unparse-specializers (method-type-specifiers m)))) (generic-function-methods (gdefinition spec))))) ;;; Changes to 7debug ;;; Note: I changed defsys.lisp so that 7debug would be loaded for 7.1 ;;; (member fspec *uninteresting-functions*) -> (gethash fspec *uninteresting-functions*) ;;; *uninteresting-functions* is a list in 7.1 (at least for us). (defun frame-interesting-p (frame &optional (censor-invisible-frames *censor-invisible-frames*)) (labels ((uninternalize-fspec (fspec) ;; Internal functions of uninteresting functions are uninteresting (if (and (listp fspec) (eq (first fspec) :internal)) (if (and (or (eq (fourth fspec) 'si:with-process-interactive-priority-body) (eq (fourth fspec) 'si:with-process-non-interactive-priority-body)) (not (memq :process-priority *invisible-frame-types-to-show*))) ;; These things aren't interesting (return-from frame-interesting-p nil) (uninternalize-fspec (second fspec))) fspec))) (if (and censor-invisible-frames (frame-invisible-p frame)) nil (let* ((function (frame-function frame)) (fspec (uninternalize-fspec (function-name-for-debugger frame)))) (and (neq fspec function) ;Not an unnamed LAMBDA expression (not (member fspec *uninteresting-functions*)) (not (member fspec si:*digested-special-forms*))))))) ;;; Housecleaning: removed show-all-compiled-7-1 & show-all-compiled-7-2, using #+ and #- instead #-genera-Release-7-2 (defun show-all-compiled (&optional show-source-file-p) (let* ((*printing-monitor-message* t) (frame *current-frame*) (function (frame-function frame))) (format t "~V~S~" *emphasis-character-style* (function-name-for-debugger frame)) (when show-source-file-p (print-function-source-file function)) (format t "~2%") ;; Print the arguments, including the rest-arg which is a local (let ((local-start (print-frame-args *current-frame* 1 t))) (cond ((frame-active-p *current-frame*) ;; Print the rest of the locals, if the frame is active (print-frame-locals *current-frame* local-start 1) (format t "~%~VDisassembled code:~" *deemphasis-character-style*) (show-all-compiled-1 frame function) ;; This kludge is to prevent the prompt from triggering a **MORE** ;; when it comes out on the bottom line of the window (if (memq :notice (send standard-output :which-operations)) (send standard-output :notice :input-wait))))))) #+genera-Release-7-2 (defun show-all-compiled (&optional show-source-file-p) (let* ((*printing-monitor-message* t) (frame *current-frame*) (function (frame-function frame))) (format t "~V~S~" *emphasis-character-style* (FUNCTION-NAME-FOR-DEBUGGER FRAME)) ;; KRA: (lframe-function-name *current-language* function nil)) (when show-source-file-p (print-function-source-file function)) (format t "~2%") ;; Print the arguments, including the rest-arg which is a local (let ((local-start (print-frame-args *current-frame* 1 t))) (cond ((frame-active-p frame) ;; Print the rest of the locals, if the frame is active (print-frame-locals frame local-start 1) (lframe-show-code-for-function *current-language* frame function (lframe-show-source-code-p *current-language*) :brief nil) ;; This kludge is to prevent the prompt from triggering a **MORE** ;; when it comes out on the bottom line of the window (when (memq :notice (send standard-output :which-operations)) (send standard-output :notice :input-wait)))))) ;;; Changes to boot ;;; Fixes function-spec for methods once load-defmethod-internal ;;; returns a useful value (Thome's patch) (defun load-defmethod (class name quals specls ll doc isl-cache-symbol plist fn) (let ((method-spec (make-method-spec name quals specls))) (record-definition 'method method-spec) (setq fn (set-function-name fn method-spec)) (let ((method (load-defmethod-internal name quals specls ll doc isl-cache-symbol plist fn class))) #+Genera (when method ; patched... MT 880829 (scl:fdefine method-spec fn)) method-spec))) (defun load-defmethod-internal (gf-spec qualifiers specializers lambda-list doc isl-cache-symbol plist fn method-class) (when (listp gf-spec) (do-standard-defsetf-1 (cadr gf-spec))) (when plist (setq plist (copy-list plist)) ;Do this to keep from affecting ;the plist that is about to be ;dumped when we are compiling. (let ((uisl (getf plist :isl)) (isl nil)) (when uisl (setq isl (intern-slot-lists uisl)) (setf (getf plist :isl) isl)) (when isl-cache-symbol (setf (getf plist :isl-cache-symbol) isl-cache-symbol) (set isl-cache-symbol isl))) (setf (method-function-plist fn) plist)) (let ((method (add-named-method gf-spec qualifiers specializers lambda-list fn :documentation doc))) (unless (or (eq method-class 'standard-method) (eq (find-class method-class nil) (class-of method))) (format *error-output* "At the time the method with qualifiers ~:~S and~%~ specializers ~:S on the generic function ~S~%~ was compiled, the method-class for that generic function was~%~ ~S. But, the method class is now ~S, this~%~ may mean that this method was compiled improperly." qualifiers specializers gf-spec method-class (class-name (class-of method)))) method ; return a useful value (MT) )) ;;; Housecleaning: added generic-function-class to the ignore declaration (defun ensure-generic-function (spec &rest keys &key lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class) (declare (ignore lambda-list argument-precedence-order declarations documentation method-combination generic-function-class method-class)) (let ((existing (and (gboundp spec) (gdefinition spec)))) (cond ((null existing) (let ((new (apply #'ensure-gf-internal spec keys))) (setq new (set-function-name new spec)) (setf (gdefinition spec) new))) ((funcallable-instance-p existing) existing) (existing #+Lispm (zl:signal 'generic-clobbers-function :name spec) #-Lispm (error "~S already names an ordinary function or a macro,~%~ it can't be converted to a generic function." spec))))) ;;; Changes to defs ;;; Commented out class-options as an argument to do-standard-defsetfs (do-standard-defsetfs method-function-plist method-function-get get-setf-function gdefinition ; class-options ;also above class-instance-slots slotd-name slot-value--std slot-value--fsc slot-value-using-class ) ;;; Changes to defsys ;;; made 7debug part of 7.1 and 7.2 systems (defsystem pcl *pcl-directory* ;; file load compile files which port ;; environment environment force the of ;; recompilation ;; of this file ((rel-6-patches t t () rel-6) (rel-7-1-patches t t () rel-7-1) (rel-7-2-patches t t () rel-7-2) (ti-patches t t () ti) (pyr-patches t t () pyramid) (xerox-patches t t () xerox) (kcl-patches t t () kcl) (pkg t t ()) (walk (pkg) (pkg) ()) (iterate t t ()) (macros t t ()) (low (pkg macros) t (macros)) (3600-low (low) (low) (low) Genera) (lucid-low (low) (low) (low) Lucid) (Xerox-low (low) (low) (low) Xerox) (ti-low (low) (low) (low) TI) (vaxl-low (low) (low) (low) vaxlisp) (kcl-low (low) (low) (low) KCL) (excl-low (low) (low) (low) excl) (cmu-low (low) (low) (low) CMU) (hp-low (low) (low) (low) HP) (gold-low (low) (low) (low) gclisp) (pyr-low (low) (low) (low) pyramid) (coral-low (low) (low) (low) coral) (fin t t (low)) (defs t t (macros iterate)) (boot t t (defs fin)) (vector t t (boot defs fin)) (slots t t (boot defs low fin)) (mki t t (boot defs low fin)) (init t t (boot defs low fin)) (defclass t t (boot defs low fin slots)) (std-class t t (boot defs low fin slots)) (braid1 t t (boot defs low fin)) (fsc t t (slots boot defs low fin)) (methods t t (boot defs low fin slots)) (combin t t (boot defs low fin)) (dcode t t (defs low vector fin slots)) (dcode-pre1 t t (defs low fin vector slots dcode)) (fixup t t (boot defs low fin)) (high t t (boot defs low fin)) (compat t t ()) (7debug t t () #+Genera-Release-7-1 rel-7-1 #+Genera-Release-7-2 rel-7-2 #-Genera-Release-7 rel-7) )) ;;; Changes to fin ;;; More from Thome's patch ;;; put into #+Genera section (proclaim '(inline applyable-thing-p)) (defun applyable-thing-p (thing) (or (functionp thing) (and (consp thing) (eq (car thing) 'si:digested-lambda)))) (defun set-funcallable-instance-function (fin new-value) (cond ((not (funcallable-instance-p fin)) (error "~S is not a funcallable-instance" fin)) ((not (applyable-thing-p new-value)) (error "~S is not a function." new-value)) ((and (si:lexical-closure-p new-value) (compiled-function-p (si:lexical-closure-function new-value))) (let* ((fin-env (si:lexical-closure-environment fin)) (new-env (si:lexical-closure-environment new-value)) (new-env-size (zl:length new-env)) (fin-env-size (- funcallable-instance-closure-size (length funcallable-instance-data)))) (cond ((<= new-env-size fin-env-size) (dotimes (i fin-env-size) (setf (sys:%p-contents-offset fin-env i) (and (< i new-env-size) (sys:%p-contents-offset new-env i)))) (setf (si:lexical-closure-function fin) (si:lexical-closure-function new-value))) (t (set-funcallable-instance-function fin (make-trampoline new-value)))))) (t (set-funcallable-instance-function fin (make-trampoline new-value))))) ;;; Changes to iterate ;;; (return-from ,block-name) -> (return-from ,block-name (values)) (defun optimize-iterate-form (type clauses body iterate-env) (let* ((temp-vars *iterate-temp-vars-list*) (block-name (gensym)) (finish-form `(return-from ,block-name (values))) (bound-vars (mapcan #'(lambda (clause) (let ((names (first clause))) (if (listp names) (copy-list names) (list names)))) clauses)) iterate-decls generator-decls update-forms bindings final-bindings leftover-body) (do ((tail bound-vars (cdr tail))) ((null tail)) ; check for duplicates (when (member (car tail) (cdr tail)) (warn "variable appears more than once in iterate: ~s" (car tail)))) (flet ((get-iterate-temp nil ; make temporary var. note ; that it is ok to re-use these ; symbols in each iterate, ; because they are not used ; within body. (or (pop temp-vars) (gensym)))) (dolist (clause clauses) (cond ((or (not (consp clause)) (not (consp (cdr clause)))) (warn "bad syntax in iterate: clause not of form (var iterator): ~s" clause)) (t (unless (null (cddr clause)) (warn "probable parenthesis error in iterate clause--more than 2 elements: ~s" clause)) (multiple-value-bind (let-body binding-type let-bindings localdecls otherdecls extra-body) (expand-into-let (second clause) type iterate-env) ;; we have expanded the generator clause and parsed it into its ;; let pieces. (prog* ((vars (first clause)) gen-args renamed-vars) (#+Genera-Release-7-1 block #+Genera-Release-7-1 punt1 #-Genera-Release-7-1 progn (setq vars (if (listp vars) (copy-list vars) (list vars))) ; vars is now a (fresh) list of ; all iteration vars bound in ; this clause (when (setq let-body (function-lambda-p let-body 1)) ;; we have something of the form #'(lambda ;; (finisharg) ...), possibly with some let bindings ;; around it. (setq let-body (cdr let-body)) (setq gen-args (pop let-body)) (when let-bindings ;; the first transformation we want to perform is ;; "let-eversion": turn (let* ((generator (let ;; (..bindings..) #'(lambda ...)))) ..body..) into ;; (let* (..bindings.. (generator #'(lambda ...))) ;; ..body..). this transformation is valid if ;; nothing in body refers to any of the bindings, ;; something we can assure by alpha-converting the ;; inner let (substituting new names for each var). ;; of course, none of those vars can be special, but ;; we already checked for that above. (multiple-value-setq (let-bindings renamed-vars) (rename-let-bindings let-bindings binding-type iterate-env leftover-body #'get-iterate-temp)) (setq leftover-body nil) ; if there was any leftover ; from previous, it is now ; consumed ) (let ((finish-arg (first gen-args))) ;; the second transformation is substituting the ;; body of the generator (lambda (finish-arg) . ;; gen-body) for its appearance in the update form ;; (funcall generator #'(lambda () finish-form)), ;; then simplifying that form. the requirement for ;; this part is that the generator body not refer to ;; any variables that are bound between the ;; generator binding and the appearance in the loop ;; body. the only variables bound in that interval ;; are generator temporaries, which have unique ;; names so are no problem, and the iteration ;; variables themselves: all of them in the case of ;; iterate, only the remaining ones in the case of ;; iterate*. we'll discover the story as we walk ;; the body. (multiple-value-bind (finishdecl other rest) (parse-declarations let-body gen-args) (declare (ignore finishdecl)) ; pull out declares, if any, ; separating out the one(s) ; referring to the finish arg, ; which we will throw away (when other ; combine remaining decls with ; decls extracted from the let, ; if any (setq otherdecls (nconc otherdecls other))) (setq let-body (cond (otherdecls ; there are interesting ; declarations, so have to keep ; it wrapped. `(let nil (declare ,@otherdecls) ,@rest)) ((null (cdr rest)) ; only one form left (first rest))))) (setq let-body (walk-form let-body iterate-env #'(lambda (form context env) (declare (ignore context)) ;; need to substitute renamed-vars, as well as ;; turn (funcall finish-arg) into the finish ;; form (cond ((symbolp form) (let (renaming) (cond ((and (eq form finish-arg) (variable-same-p form env iterate-env)) ; an occurrence of the finish ; arg outside of funcall ; context--i can't handle this (maybe-warn :definition "couldn't optimize ~s because generator ~s does something with its finish arg besides funcall it." type (second clause)) #-Genera-Release-7-1 (go punt) #+Genera-Release-7-1 (return-from punt1 nil) ) ((and (setq renaming (assoc form renamed-vars )) (variable-same-p form env iterate-env)) ; reference to one of the vars ; we're renaming (cdr renaming)) ((and (member form bound-vars) (variable-same-p form env iterate-env)) ; form is a var that is bound ; in this same iterate, or ; bound later in this iterate*. ; this is a conflict. (maybe-warn :user "couldn't optimize ~s because generator ~s is closed over ~s, in conflict with another iteration variable.~@[ you may have meant to use iterate*~]" type (second clause) form (eq type 'iterate)) #-Genera-Release-7-1 (go punt) #+Genera-Release-7-1 (return-from punt1 nil) ) (t form)))) ((and (consp form) (eq (first form) 'funcall) (eq (second form) finish-arg) (variable-same-p (second form) env iterate-env)) ; (funcall finish-arg) => ; finish-form (unless (null (cddr form)) (maybe-warn :definition "generator for ~s applied its finish arg to > 0 arguments ~s--ignored." (second clause) (cddr form))) finish-form) (t form))))) ;; gen-body is now a form which, when evaluated, ;; returns updated values for the iteration ;; variable(s) (push (mv-setq (copy-list vars) let-body) update-forms) ;; note possible further optimization: if the above ;; expanded into (setq var (prog1 oldvalue ;; prepare-for-next-iteration)), as so many do, then ;; we could in most cases split the prog1 into two ;; pieces: do the (setq var oldvalue) here, and do ;; the prepare-for-next-iteration at the bottom of ;; the loop. this does a slight optimization of the ;; prog1 and also rearranges the code in a way that ;; a reasonably clever compiler might detect how to ;; get rid of redundant variables altogether (such ;; as happens with interval and list-tails); that ;; would make the whole thing closer to what you ;; might have coded by hand. however, to do this ;; optimization, we need to assure that (a) the ;; prepare-for-next-iteration refers freely to no ;; vars other than the internal vars we have ;; extracted from the let, and (b) that the code has ;; no side effects. these are both true for all the ;; iterators defined by this module, but how shall ;; we represent side-effect info and/or tap into the ;; compiler's knowledge of same? (when localdecls ; there were declarations for ; the generator locals--have to ; keep them for later, and ; rename the vars mentioned (setq generator-decls (nconc generator-decls (mapcar #'(lambda (decl) (let ((head (car decl))) (cons head (if (eq head 'type) (cons (second decl) (sublis renamed-vars (cddr decl))) (sublis renamed-vars (cdr decl)))))) localdecls)))) (go finish-clause))) (maybe-warn :definition "could not optimize ~s clause ~s because generator not of form (let[*] ... (function (lambda (finish) ...)))" type (second clause)) );end of block punt1 or progn #-Genera-Release-7-1 punt (let ((gvar (get-iterate-temp)) (generator (second clause))) ;; for some reason, we can't expand this guy, so go with ;; the formal semantics: bind a var to the generator, ;; then call it in the update section (setq let-bindings (list (list gvar (cond (leftover-body; have to use this up `(progn ,@(prog1 leftover-body (setq leftover-body nil)) generator)) (t generator))))) (push (mv-setq (copy-list vars) `(funcall ,gvar #'(lambda nil ,finish-form)) ) update-forms)) finish-clause (case type (iterate ; for iterate, don't bind any ; iv's until all exprs are ; evaluated, so defer this (setq final-bindings (nconc final-bindings vars)) (setq vars nil) (when extra-body ; have to save this for next ; clause, too (setq leftover-body (nconc leftover-body extra-body)) (setq extra-body nil))) (iterate* ; pop off the vars we have now ; bound from the list of vars ; to watch out for--we'll bind ; them right now (dolist (v vars) #-Genera (declare (ignore v)) (pop bound-vars)))) (setq bindings (nconc bindings let-bindings (cond (extra-body ; there was some computation to ; do after the bindings--here's ; our chance (cons (list (first vars) `(progn ,@extra-body nil)) (rest vars))) (t vars)))))))))) (do ((tail body (cdr tail))) ((not (and (consp tail) (consp (car tail)) (eq (caar tail) 'declare))) ; tail now points at first ; non-declaration. if there ; were declarations, pop them ; off so they appear in the ; right place (unless (eq tail body) (setq iterate-decls (ldiff body tail)) (setq body tail)))) `(block ,block-name (let* ,(append bindings final-bindings) ,@(and generator-decls `((declare ,@generator-decls))) ,@iterate-decls ,@leftover-body (loop ,@(nreverse update-forms) ,@body))))) ;;; (return) -> (return (values)) (defun optimize-gathering-form (clauses body gathering-env) (let* (acc-info leftover-body top-bindings finish-forms top-decls) (dolist (clause clauses) (multiple-value-bind (let-body binding-type let-bindings localdecls otherdecls extra-body) (expand-into-let (second clause) 'gathering gathering-env) (prog* ((acc-var (first clause)) renamed-vars accumulator realizer) (when (and (consp let-body) (eq (car let-body) 'values) (consp (setq let-body (cdr let-body))) (setq accumulator (function-lambda-p (car let-body)) ) (consp (setq let-body (cdr let-body))) (setq realizer (function-lambda-p (car let-body) 0)) (null (cdr let-body))) ;; Macro returned something of the form (VALUES #'(lambda ;; (value) ...) #'(lambda () ...)), a function to ;; accumulate values and a function to realize the result. (when binding-type ;; Gatherer expanded into a LET (cond (otherdecls (maybe-warn :definition "Couldn't optimize GATHERING clause ~S because its expansion carries declarations about more than the bound variables: ~S" (second clause) `(declare ,@otherdecls)) (go punt))) (when let-bindings ;; The first transformation we want to perform is a ;; variant of "LET-eversion": turn (mv-bind (acc ;; real) (let (..bindings..) (values #'(lambda ...) ;; #'(lambda ...))) ..body..) into (let* ;; (..bindings.. (acc #'(lambda ...)) (real ;; #'(lambda ...))) ..body..). This transformation ;; is valid if nothing in body refers to any of the ;; bindings, something we can assure by ;; alpha-converting the inner let (substituting new ;; names for each var). Of course, none of those ;; vars can be special, but we already checked for ;; that above. (multiple-value-setq (let-bindings renamed-vars) (rename-let-bindings let-bindings binding-type gathering-env leftover-body)) (setq top-bindings (nconc top-bindings let-bindings )) (setq leftover-body nil) ; If there was any leftover ; from previous, it is now ; consumed )) (setq leftover-body (nconc leftover-body extra-body)) ; Computation to do after these ; bindings (push (cons acc-var (rename-and-capture-variables accumulator renamed-vars gathering-env)) acc-info) (setq realizer (rename-variables realizer renamed-vars gathering-env)) (push (cond ((null (cdddr realizer)) ; Simple (LAMBDA () expr) => ; expr (third realizer)) (t ; There could be declarations ; or something, so leave as a ; LET (cons 'let (cdr realizer)))) finish-forms) (unless (null localdecls) ; Declarations about the LET ; variables also has to ; percolate up (setq top-decls (nconc top-decls (sublis renamed-vars localdecls)))) (return (values))) (maybe-warn :definition "Couldn't optimize GATHERING clause ~S because its expansion is not of the form (VALUES #'(LAMBDA ...) #'(LAMBDA () ...))" (second clause)) punt (let ((gs (gensym)) (expansion `(multiple-value-list ,(second clause)))) ; Slow way--bind gensym to the ; macro expansion, and we will ; funcall it in the body (push (list acc-var gs) acc-info) (push `(funcall (cadr ,gs)) finish-forms) (setq top-bindings (nconc top-bindings (list (list gs (cond (leftover-body `(progn ,@(prog1 leftover-body (setq leftover-body nil)) ,expansion)) (t expansion)))))))))) (setq body (walk-gathering-body body gathering-env acc-info)) (cond ((eq body :abort) ; Couldn't finish expansion nil) (t `(let* ,top-bindings ,@(and top-decls `((declare ,@top-decls))) ,body ,(cond ((null (cdr finish-forms)); just a single value (car finish-forms)) (t `(values ,@(reverse finish-forms))))))))) ;;; Changes to pkg.lisp ;;; We need to import these symbols #+3600 (import '(sys:%instance-ref sys:instancep) *the-pcl-package*) ;;; And don't need to export them. Also, %instancep -> instancep (defvar *other-exports* '( get-setf-function get-setf-function-name standard-class standard-generic-function standard-method make initialize mki class-prototype class object essential-class class-name class-precedence-list class-local-supers class-local-slots class-direct-subclasses class-direct-methods class-slots method-arglist method-argument-specifiers method-function method-equal slotd-name slot-missing define-meta-class %allocate-instance ;; %instance-ref ;; instancep %instance-meta-class allocate-instance optimize-slot-value optimize-setf-of-slot-value add-named-class class-for-redefinition add-class supers-changed slots-changed check-super-metaclass-compatibility make-slotd compute-class-precedence-list walk-method-body walk-method-body-form add-named-method add-method remove-named-method remove-method find-method find-method-internal )) ;;; Changes to slots ;;; Symbolics likes the initial values of constants to be constants ;;; and not just expressions which evaluate to constants (defvar slot-value-cache-mask (make-cache-mask slot-value-cache-size 3)) ;;; Changes to vector ;;; (return) -> (return nil) (defun cache-key-from-wrappers-1 (cache-size specialized-positions objects) (let ((offset 0) (nspecialized 0) (i 0)) (dolist (obj objects) (when (null specialized-positions) (return nil)) (when (= i (car specialized-positions)) (setq specialized-positions (cdr specialized-positions)) (incf nspecialized) (let* ((wrapper (wrapper-of-1 obj)) (number (wrapper-cache-no wrapper))) (when (zerop number) (setq wrapper (obsolete-instance-trap wrapper obj) number (wrapper-cache-no wrapper))) (setq offset (%logxor offset number)))) (incf i)) (%logand offset (make-cache-mask cache-size (1+ nspecialized))))) ------------------------End of changes------------------------------ Hope this helps. Carl Klapper Odyssey Research Associates, Inc. 301A Harris B. Dates Drive Ithaca, NY 14850 (607) 277-2020 klapper%oravax.uucp@cu-arpa.cs.cornell.edu From Owners-commonloops.pa@Xerox.COM Thu Oct 6 08:25:11 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA01955; Thu, 6 Oct 88 08:25:11 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 88 08:21:29 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 06 OCT 88 08:19:16 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA18474; Thu, 6 Oct 88 08:09:22 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA06158; Thu, 6 Oct 88 08:12:15 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA02232; Thu, 6 Oct 88 08:12:16 PDT Message-Id: <8810061512.AA02232@suntana.sun.com> To: Warren Harris Cc: lanning.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com Subject: Re: Needed: Info on LISP X based toolkits In-Reply-To: Your message of Thu, 06 Oct 88 00:15:45 -0700. <8041.592125345@hplwhh> Date: Thu, 06 Oct 88 08:12:14 PDT From: kempf@Sun.COM I pretty much agree with what Warren had to say in his note except for the following: > 1. definition of the virtual console > - the X server protocol > 2. language bindings for level (1) > - CLX > 3. window/stream objects > - requires CLOS > - requires CL streams to be implemented as objects This assumes (as does the rest of Warren's note) that the host window system is and will always be X. There are currently Common Lisp implementations running on Mac's and PC's which don't target to X host systems. Furthermore, both NeWS and Display Postscript (which will be on the NeXT machine) aren't X based. The big win of Common Lisp in general is that it defines a high level virtual machine which insulates application developers from the underlying hardware. It seems as if a "window virtual machine" combining Level 2 & 3 insulating application developers from the underlying host window systems could make window based applications more portable. Since the window virtual machine is likely to require stream objects, it seems more appropriate to implement it as a combination of 2 & 3. Thus the underlying window system would remain opaque to the application, and the window virtual machine level could be nicely object-oriented. The "thousand flowers" in Stan's original note could then bloom at the toolkit level, since different applications are likely to require different ways of interacting with them. jak From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Oct 6 10:36:23 1988 Received: from [36.86.0.194] by arisia with SMTP (5.59++/IDA-1.2.5) id AA02724; Thu, 6 Oct 88 10:36:23 PDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 10:34:39 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 10:30:30 pdt Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 10:30:06 pdt To: Kent M Pitman , miller@CS.Rochester.EDU Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Cleanup@SAIL.STANFORD.EDU Subject: Re: Issue: EVAL-OTHER (Version 2) In-Reply-To: Your message of "Thu, 06 Oct 88 02:10:00 EDT." <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Thu, 06 Oct 88 10:30:02 PDT Message-Id: <8592.592162202@hplwhh> From: Warren Harris I don't know about making EVAL a generic function due to the ramifications this has on the compiler, but there are several other places in CL in which functions should be required to be generic. One example might be in the equality area. Common Lisp seems to have a wealth of equality predicates, EQ, EQL, EQUAL, EQUALP, =, STRING=, CHAR= ... and you kind of pick and choose based on what you know about the application. It would be nice to have at least one version of equality which did the right thing based on what it was comparing. Perhaps this is EQUALP. EQUALP already looks inside both cons cells and arrays, why not extend it to look inside objects too. I suggest the following definition of EQUALP: (defmethod equalp ((x t) (y t)) (eq x y)) (defmethod equalp ((x character) (y character)) (char-equal x y)) (defmethod equalp ((x number) (y number)) (= x y)) (defmethod equalp ((x cons) (y cons)) (or (eq x y) (and (equalp (car x) (car y)) (equalp (cdr x) (cdr y))))) (defmethod equalp ((x object) (y object)) (let ((cx (class-of x)) (cy (class-of y))) (or (eq x y) (and (eq cx cy) (every #'(lambda (slotd) (let ((name (slotd-name slotd))) (equalp (slot-value-using-class cx x name) (slot-value-using-class cx y name)))) (class-slots cx)))))) (defmethod equalp ((x array) (y array)) ...) COERCE is another good candidate for being made generic. Like the print system which is required to go through the PRINT-OBJECT method, COERCE could ultimately invoke a generic layer: (defun coerce (thing type) (case type (t (coerce-object thing (find-class type))))) (defmethod coerce-object ((thing t) (c class)) (error "~S cannot be coerced to type ~S." thing (class-name c))) This would allow the user to write class specific coercion routines. One objection has been raised to this proposal by Moon: > But it's meaningful for COERCE's second argument to be a type specifier that > does not name a class. CLtL gives as an example (vector (complex short-float)). > It would be inconsistent to do some coercions with classes and others through > some other mechanism. I don't think your idea will work without a larger > recasting of Common Lisp in object-oriented terms. While that's an interesting > project for investigation, I suspect it would quickly go way beyond the > proper charter of a standardization effort. I think the above code demonstrates how this can indeed work given CL's non-class type specifiers. COERCE itself is not required to be generic, it is simplied required to ultimately call COERCE-OBJECT. This is exactly the requirement placed on PRINT. > One minor procedural matter: You're more likely to get this considered if > you write up the proposal in full rather than just as a little fragment. How do I do this? How does it look, and who do I send it to? Warren Harris HP Labs From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Thu Oct 6 11:57:54 1988 Received: from Sail.Stanford.EDU by arisia with SMTP (5.59++/IDA-1.2.5) id AA03114; Thu, 6 Oct 88 11:57:54 PDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 11:56:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 11:22:48 PDT Date: Thu, 6 Oct 88 11:22 PDT From: Gregor.pa@Xerox.COM Subject: Re: Q about CLOS To: miller@CS.ROCHESTER.EDU Cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <19881005215228.4.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <19881006182238.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 5 Oct 88 17:52 EDT From: Brad Miller None of the doc I've scrounged for CLOS answers this simple question, so anyone who can enlighten me, thanks... is EVAL a generic function (message)? is APPLY? Neither of these is a generic-function. ------- From Owners-commonloops.pa@Xerox.COM Thu Oct 6 12:31:10 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA03228; Thu, 6 Oct 88 12:31:10 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 88 11:36:46 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 06 OCT 88 11:20:10 PDT Received: by ti.com id AA19400; Thu, 6 Oct 88 13:19:19 CDT Received: from dsg by tilde id AA22119; Thu, 6 Oct 88 13:08:13 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88 13:07:46 CDT Message-Id: <2801153312-6211532@Sierra> Sender: KK@Sierra.csc.ti.com Date: Thu, 6 Oct 88 13:08:32 CDT From: Kerry Kimbrough To: Robert Scheifler Cc: harris%hplwhh@hplabs.hp.com, lanning.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com Subject: Re: CLX and OOP In-Reply-To: Msg of Thu, 6 Oct 88 09:43 EDT from Robert Scheifler Regarding the proper relationship between CLX and OOP: First, I believe there will be little disagreement with the notion that this relationship must be defined in terms of CLOS. But one idea that occurs immediately is that CLX could be "CLOS-ified" in a straight-forward way by defining all of its base objects (window, display, font, etc.) as CLOS classes and defining all of its functions as generics. Maybe the "all"'s should be "most"'s, but you get the idea. Without having actually gone through the whole exercise, I presume that this could be done without change to any of the function/type names or lambda lists. What do people see as the pro's and con's of this? BTW: This is sorta what CLUE does, except only window is (re)defined as a class and none of of the CLX functions are made generic. In terms of changes to off-the-shelf CLX, this was the least we could do, so that's what we did. Also: this kind of "CLOS-ified" CLX has little (if anything) to do with the issue of "What is the best X toolkit interface for Lisp." From Gregor.pa@Xerox.COM Thu Oct 6 12:34:07 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA03248; Thu, 6 Oct 88 12:34:07 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 11:57:19 PDT Date: Thu, 6 Oct 88 11:55 PDT From: Gregor.pa@Xerox.COM Subject: Re: Bug in class allocated slot initialization To: Eric H. Nielsen Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 2 Oct 88 11:51 PDT from Eric H. Nielsen Message-Id: <19881006185503.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Sun, 2 Oct 88 14:51 EDT From: "Eric H. Nielsen" I am using the the pcl version 8/2/88 (beta) August 2nd, 1988 with some patches. I have found a bug in the initialization of class allocated slots: It occurs only when pcl::*slotd-unsupplied* is eq to the initialized value, e.g. t or nil. (setq pcl::*slotd-unsupplied* nil) You can't set the value of pcl::*slotd-unsupplied*! I don't know what you are trying to achieve by doing this, but it is punching PCL in the nose pretty hard, and so you get the bug you observe. ------- From fischer.pa@Xerox.COM Thu Oct 6 12:42:11 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA03292; Thu, 6 Oct 88 12:42:11 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 12:16:41 PDT Date: 6 Oct 88 12:08 PDT From: fischer.pa@Xerox.COM Subject: Re: CLX and OOP In-Reply-To: Kerry Kimbrough 's message of Thu, 6 Oct 88 13:08:32 CDT To: Kerry Kimbrough Cc: Robert Scheifler , harris%hplwhh@hplabs.hp.com, lanning.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com Message-Id: <881006-121641-1160@Xerox> I suspect some of this will become moot once full U/I toolkits are released in C, since there's more value to their use than a very general low level interface like CLX or XLib. To cast it into Stan's metaphor, those are the flowers most of us are likely to find attractive. Usually low level design issues are driven by users of the design. Right now, I think there's only a very small community of CLUE/CLX users. There are likely to be much larger communities using and driving the design of forthcoming C based U/I toolkits. Ideally we should work *with* them. Perhaps we're getting mired in low level interfaces when higher level ones would be more appropriate to consider for the near term? "Advance work" for the next generation of toolkit interfaces. (ron) From Owners-CommonLoops.pa@Xerox.COM Thu Oct 6 12:45:28 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA03324; Thu, 6 Oct 88 12:45:28 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 06 OCT 88 12:00:19 PDT Return-Path: Redistributed: CommonLoops.pa Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 06 OCT 88 11:56:50 PDT Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471918; Thu 6-Oct-88 14:53:04 EDT Date: Thu, 6 Oct 88 14:52 EDT From: Mike McMahon Subject: Re: Needed: Info on LISP X based toolkits To: lanning.pa@Xerox.COM Cc: cl-windows@Think.COM, CommonLoops.pa@Xerox.COM In-Reply-To: <881005-195006-2101@Xerox> Message-Id: <19881006185258.3.MMCM@OWL.SCRC.Symbolics.COM> Date: 5 Oct 88 19:50 PDT From: lanning.pa@xerox.com The history of o-o programming and window environments are closely coupled. With lisp we can do much more that duplicate some other conception of a UI toolkit. But this will take time and effort. CLOS is a new and unique language; it is elegant, powerful, efficient (well, maybe), and fun. We have not had enough experience to understand what the "correct" style of programming in CLOS is, or know how it will change the way we think about programming. What is needed is not a premature UI toolkit standard based on some impoverished language's notion of programming, but a long-term effort by a large community to try to understand what CLOS really is, what it is really good for, and what it says about the ways to construct such a system. I wonder how the word "standard" crept into your discourse. Or rather, why you think the existence of one standard precludes all others. The beauty of a reasonable, low-level standard like X and its direct CLX analogue is that you can have platform hardware independence and peaceful coexistence of a multitude of toolkits, or standards if you prefer. Whoever told you that you had to program your user interfaces in CLUE lied to you. CLUE gives a reasonably straightforward implementation of X toolkit intrinsics for application writers who are familiar with those to use today. This is valuable while other ideas are worked out. In my opinion, CLOS is not new and unique, although it shows considerably more rigor and maturity than its predecessors. It will indeed be interesting to see how its application within a larger community of programmers develops into an accepted (correct) style. From my experience with the use of similar LISP based object systems for UIMS construction, I have come to believe that the use of object orientation to implement widget operations or window dressing is considerably less profound than some of the higher level generic behaviors. From Owners-CommonLoops.pa@Xerox.COM Thu Oct 6 19:04:01 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA08304; Thu, 6 Oct 88 19:04:01 PDT Received: from Riesling.ms by ArpaGateway.ms ; 06 OCT 88 19:01:05 PDT Return-Path: Redistributed: CommonLoops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 06 OCT 88 18:59:22 PDT To: Mike McMahon Cc: lanning.pa@Xerox.COM, cl-windows@THINK.COM, CommonLoops.pa@Xerox.COM Subject: Re: Needed: Info on LISP X based toolkits In-Reply-To: Your message of Thu, 06 Oct 88 14:52:00 -0400. <19881006185258.3.MMCM@OWL.SCRC.Symbolics.COM> Date: Thu, 06 Oct 88 21:49:08 -0400 From: Mike Thome Message-Id: <881006-190105-1952@Xerox> "I wonder how the word "standard" crept into your discourse. Or rather, why you think the existence of one standard precludes all others. The beauty of a reasonable, low-level standard like X and its direct CLX analogue is that you can have platform hardware independence and peaceful coexistence of a multitude of toolkits, or standards if you prefer." Wazzat?!? Obviously you are using some definition of "standard" I have been previously unaware of... The issue at hand (I thought) is to work towards an OO-{window,user-interface}-{system,toolkit,"standard"} that we could all more-or-less agree is sortof right enough to actually use so that we can all write portable user interfaces. If X/clx/clue/whatever is to be one of MANY (key word here) possible platforms to build a REAL standard user interface package on, then it is the wrong level to be arguing at. From Owners-CommonLoops.pa@Xerox.COM Fri Oct 7 07:41:43 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA15824; Fri, 7 Oct 88 07:41:43 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 07 OCT 88 07:39:31 PDT Return-Path: Redistributed: CommonLoops.pa Received: from risc.com ([10.5.0.7]) by Xerox.COM ; 07 OCT 88 07:38:02 PDT Received: from planets.risc.com (jupiter.risc.com) by risc.com (4.0/SMI-DDN) id AA08672; Fri, 7 Oct 88 07:37:01 PDT Received: from saturn.planets.risc.com by planets.risc.com (3.2/SMI-3.2) id AA11712; Fri, 7 Oct 88 07:34:58 PDT Message-Id: <8810071434.AA11712@planets.risc.com> Date: Fri, 7 Oct 88 07:35:12 PDT From: mas@jupiter.risc.com To: mthome@VAX.BBN.COM Cc: MMcM@SCRC-STONY-BROOK.ARPA, lanning.pa@Xerox.COM, cl-windows@THINK.COM, CommonLoops.pa@Xerox.COM In-Reply-To: Mike Thome's message of Thu, 06 Oct 88 21:49:08 -0400 <881006-190105-1952@Xerox> Subject: Needed: Info on LISP X based toolkits From Owners-commonloops.pa@Xerox.COM Fri Oct 7 16:10:54 1988 Received: from Xerox.COM by arisia with SMTP (5.59++/IDA-1.2.5) id AA01955; Thu, 6 Oct 88 08:25:11 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 88 08:21:29 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 06 OCT 88 08:19:16 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA18474; Thu, 6 Oct 88 08:09:22 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA06158; Thu, 6 Oct 88 08:12:15 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA02232; Thu, 6 Oct 88 08:12:16 PDT Message-Id: <8810061512.AA02232@suntana.sun.com> To: Warren Harris Cc: lanning.pa@Xerox.COM, cl-windows@SAIL.STANFORD.EDU, commonloops.pa@Xerox.COM, bkessler%hplwhh@hplabs.hp.com, cline%hplwhh@hplabs.hp.com Subject: Re: Needed: Info on LISP X based toolkits In-Reply-To: Your message of Thu, 06 Oct 88 00:15:45 -0700. <8041.592125345@hplwhh> Date: Thu, 06 Oct 88 08:12:14 PDT From: kempf@Sun.COM I pretty much agree with what Warren had to say in his note except for the following: > 1. definition of the virtual console > - the X server protocol > 2. language bindings for level (1) > - CLX > 3. window/stream objects > - requires CLOS > - requires CL streams to be implemented as objects This assumes (as does the rest of Warren's note) that the host window system is and will always be X. There are currently Common Lisp implementations running on Mac's and PC's which don't target to X host systems. Furthermore, both NeWS and Display Postscript (which will be on the NeXT machine) aren't X based. The big win of Common Lisp in general is that it defines a high level virtual machine which insulates application developers from the underlying hardware. It seems as if a "window virtual machine" combining Level 2 & 3 insulating application developers from the underlying host window systems could make window based applications more portable. Since the window virtual machine is likely to require stream objects, it seems more appropriate to implement it as a combination of 2 & 3. Thus the underlying window system would remain opaque to the application, and the window virtual machine level could be nicely object-oriented. The "thousand flowers" in Stan's original note could then bloom at the toolkit level, since different applications are likely to require different ways of interacting with them. jak environment. The bundling exists because it is very convenient. CLX programmers actually get handed these ids in event-handler routines. Yes, there were efficiency arguments here, perhaps inconsequential ones. They don't tell you what to do with them thought (like how to lookup the associated xlib:window object). The CLX doc does tell you to use make-window to perform this mapping. Perhaps the primary consideration in the back of the CLX implementors heads is that of efficiency -- will object-oriented programming slow down CLX too much? That wasn't the motivation. Partly it was an issue of whether a single object system was sufficiently stable and standardized to be able to make it a requirement (the answer seemed to be No). Also lurking around was the notion of being able to use essentially the same interface in other lisp dialects. Also, it wasn't at all obvious that we could quickly reach consensus on what an O-O CLX should look like (in terms of raising CLX to a higher level). And, it wasn't at all obvious that CLX should show through at the higher level (all the issues you enumerated). Since CLUE goes against Scheifler and McMahon's original considerations about encapsulating the lowest level of the window system, I'm curious what they think now that it seems to have caught on. I have too many flowers blooming right now, and I have a hard time keeping up with all the details of all of them. I do not consider myself a Lisp/OOPS expert in the same league as many of the rest of you out there; I'd much rather have you experts combine forces to produce the right thing. From Owners-commonloops.pa@Xerox.COM Fri Oct 7 18:23:45 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA02163; Fri, 7 Oct 88 18:23:45 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 07 OCT 88 15:23:53 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 07 OCT 88 15:19:52 PDT Received: by ti.com id AA29971; Fri, 7 Oct 88 17:19:58 CDT Received: from dsg by tilde id AA25029; Fri, 7 Oct 88 17:08:20 CDT Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 7 Oct 88 17:07:52 CDT Message-Id: <2801254139-12269376@Sierra> Sender: KK@Sierra.csc.ti.com Date: Fri, 7 Oct 88 17:08:59 CDT From: Kerry Kimbrough To: CommonLoops.pa@Xerox.COM Subject: CLOS Chapter 3 The metaclass protocol -- What is the most recent available version of this? Where can I get a copy? How stable is this chapter now? Am I having fun yet? From Owners-commonloops.pa@Xerox.COM Fri Oct 7 18:27:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA02205; Fri, 7 Oct 88 18:27:17 PDT Received: from Burger.ms by ArpaGateway.ms ; 07 OCT 88 15:32:24 PDT Return-Path: Redistributed: commonloops.pa Received: from VAX.BBN.COM ([128.89.0.91]) by Xerox.COM ; 07 OCT 88 15:31:14 PDT To: commonloops.pa@Xerox.COM Subject: types & record-source-file stuff Date: Fri, 07 Oct 88 18:10:05 -0400 From: Mike Thome Message-Id: <881007-153224-1235@Xerox> To those getting warnings while compiling the aaai-pcl and getting warnings about "incomplete type definitions" try the following as a better patch to 3600-low.lisp: (defun record-definition (type spec &rest args) (declare (ignore args)) (case type (method (if (listp (cadr spec)) (si:record-source-file-name spec 'method) (si:record-source-file-name spec 'method))) (class (si:record-source-file-name spec 'defclass) (si:record-source-file-name spec 'deftype (eq sys:inhibit-fdefine-warnings t) :start-type-definition nil)))) It appears that the handling of deftype changed a bit in the 7.1 to 7.2 transition - in that now the record-source-file-name call for deftypes also triggers a locking of the presentation system while a new type is being defined. Unfortunately, this means that it wants some other form to get evaluated later to say "I'm done defining now", and it isn't clear what pcl should do about this (if anything). Anyway, this seems to do the trick for me. -mik From Gregor.pa@Xerox.COM Fri Oct 7 18:39:48 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA02388; Fri, 7 Oct 88 18:39:48 PDT Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 17:18:39 PDT Date: Fri, 7 Oct 88 17:16 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL on TI's To: macgreg@vaxa.isi.edu Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810042350.AA20741@vaxa.isi.edu> Message-Id: <19881008001605.0.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 04 Oct 88 15:50:56 PST From: macgreg@vaxa.isi.edu Has anyone succeeded in getting the AAAI version of PCL up on an Explorer? If so, we'd like to hear how you did it. As of last week, there were at least two major bugs that prevent successful compilation of PCL on TI Explorers. The first is due to a problem with the TI compiler's inability to handle a DEFSETF containing an &REST argument. I have installed this patch in the PCL sources. The second problem appears to be due to problems in the TI-specific code in FIN.LISP, or maybe in TI.LOW. It occurs on the first attempt to compile a "defmethod" form in VECTOR.LISP. I do not have a patch for this. If someone could send me one, or help me develop one I would like to install it in the sources ------- From Gregor.pa@Xerox.COM Fri Oct 7 18:42:59 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA02416; Fri, 7 Oct 88 18:42:59 PDT Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 17:42:32 PDT Date: Fri, 7 Oct 88 17:40 PDT From: Gregor.pa@Xerox.COM Subject: bugs old and new To: CommonLoops.PA@Xerox.COM Message-Id: <19881008004043.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no In the next release of PCL, all of the following messages have been addressed. This includes all the message I have in my file from: Leonid V. Belyaev Doug Ruth John Foderaro Warren Harris Mike Thome There are other messages in my file that I haven't dealt with yet. I will get to those next week after the X3J13 meeting. First part of each message follows: Date: Wed, 24 Aug 88 20:24:20 PDT From: Leonid V. Belyaev In HP CommonLISP II, which is essentially Lucid, BOTH Lucid and HP features are defined. Some of the code, especially in the defsys file, does NOT particularly appreciate that. Date: Thu, 25 Aug 88 02:59:45 PDT From: Leonid V. Belyaev (slot-value (find-class 'standard-class) 'prototype) generates the following strange errors (the first two lines are NOT a misedit): >>Error: The slot NAME is unbound in the object #< >>Error: The slot NAME is unbound in the object #. Date: Thu, 25 Aug 88 13:49:42 PST From: Doug Ruth I still have problems compiling the file boot.lisp with the latest (8/24) release. Specifically the function MAKE-PARAMETER-REFERENCES will not compile. Date: Mon, 29 Aug 88 01:50:10 PDT From: Leonid V. Belyaev Gregor, sorry to bother you yet again, but it looks like there is a problem with the KCL version of AAAI PCL. The following is a script, which shows two major events that may clarify for you what the problem is. First, the variable *exports* is unbound in the compiled version of PKG (it IS bound in the interpreted version, see the very end). Second, during compilation of VECTOR, KCL generates numerous errors and barfs. Note that HP CommonLISP II (Lucid, really) has 0 problems once I fix *features*, DEFSYS and STD-CLASS to do the right things. From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Date: Tue, 30 Aug 88 10:01:37 PDT I'd like for pcl to run in any of the four case modes we support and while that has been possible with few modifications in the past, recently the number of modifictions has grown so I thought I'd let you know about them so you can add them to the master source if you feel it is a good idea. Date: Tue, 30 Aug 88 11:24:19 PDT From: Warren Harris Here's a fix to the DESCRIBE generic function to handle unbound slots. The code as supplied with AAAI PCL breaks when an unbound slot is encountered: Date: Tue, 30 Aug 88 10:18:50 PDT From: Warren Harris There are a few modifications I've had to make to get PCL to run under HP/Lucid CL. I just thought I'd pass them on so I don't have to do them each time. Basically, where ever you have "#+HP", this needs to be changed to "#+(and HP (not Lucid))" (sick, isn't it?). This occurs in "fin", "walk" and "defsys". Date: Wed, 31 Aug 88 10:50:10 -0400 From: Mike Thome ;;; Patch 3600-LOW.LISP ;;; The major problem with the original fspec code is that the hash ;;; tables used #'EQ ... and since the keys are lists... (defvar *method-fdefs* (make-hash-table :test #'equal :size 500)) (defvar *method-setf-fdefs* (make-hash-table :test #'equal :size 500)) Date: Wed, 14 Sep 88 18:03:39 -0400 From: Mike Thome Below are two patches, one *correctly* fixes a bug that I previously reported (and "fixed" - the old patch replaced a "function" with a "quote" to attempt to get rid of a digested-lambda form in EXPAND- DEFMETHOD-INTERNAL... the correct (original) source is at the very end). The second fixes an anomaly in symbolics presentation stuff... probably should go into rel-7-2-patches.) Date: Wed, 21 Sep 88 16:11:28 -0400 From: Mike Thome Below are some commented bugfixes for PCL (AAAI release) under Symbolics Genera 7.2. The bulk of them are environment hacks, but there are a few significant bugfixes in there (read the comments). Date: Mon, 26 Sep 88 11:40:10 -0400 From: Mike Thome The following patch fixes that annoying problem where qualified methods are not properly indented by zwei. ------- From Owners-CommonLoops.PA@Xerox.COM Sun Oct 9 07:35:32 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA15125; Sun, 9 Oct 88 07:35:32 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 09 OCT 88 07:32:44 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.PA Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 09 OCT 88 07:31:02 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Sun 9 Oct 88 09:30:49-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA20703; Sun, 9 Oct 88 09:30:42 CDT Date: Sun, 9 Oct 88 09:30:39 CDT From: Rob Pettengill Message-Id: <8810091430.AA08510@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA08510; Sun, 9 Oct 88 09:30:39 CDT To: Gregor.pa@Xerox.COM Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Fri, 7 Oct 88 17:40 PDT <19881008004043.3.GREGOR@PORTNOY.parc.xerox.com> Subject: bugs old and new Gregor, Just a reminder on this bug which could start biting others as they compose more complicated class hierarchies ... 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))) From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Mon Oct 10 13:54:33 1988 Received: from [36.86.0.194] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA25036; Mon, 10 Oct 88 13:54:33 PDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88 13:52:43 PDT Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 59923; Mon 10-Oct-88 16:41:37 EDT Date: Mon, 10 Oct 88 16:41 EDT From: Brad Miller Subject: Re: Issue: EVAL-OTHER (Version 2) To: masinter.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU Cc: Warren Harris In-Reply-To: <881008-164009-2324@Xerox> Message-Id: <19881010204134.1.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: 8 Oct 88 16:40 PDT From: masinter.pa@Xerox.COM The official procedure for participating in the Common Lisp Standardization effort is through your representitive to the X3J13 committee. While we're willing to accept proposals from the community at large, there's a large amount of work involved in the actual creation of the standard, and a fair amount of context. Well, I guess I'm part of the "community at large" but let me make one inflammatory comment... w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. It seems to me the better approach is to make CLOS the language, and "traditional" CL the subset. I know I would be a lot happier (as a heavy user of CL) that way. I'd be happy to write this up as a formal proposal if that is what's needed, but I don't really know what to do... edit Issue: EVAL-OTHER and make it version 3, or do something else? Asbestos suit on. ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller} From Owners-CommonLoops.PA@Xerox.COM Mon Oct 10 16:30:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA25932; Mon, 10 Oct 88 16:30:37 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 10 OCT 88 15:46:36 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 10 OCT 88 15:44:55 PDT Received: from localhost by rand.org; Mon, 10 Oct 88 15:08:03 PDT Message-Id: <8810102208.AA01749@rand.org> To: CommonLoops.PA@Xerox.COM Subject: PCL benchmark Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I just ran a simulation benchmark in PCL. It is a queueing simulation. To get it to run under PCL, I took the simulator from our own object system called ERNIE and converted it into PCL. I then converted the queueing simulation into PCL. The timings I got were as follows: Ernie 4 seconds PCL 30 seconds ERNIE runs under PSL. The version of PCL I have runs under AKCL. I found it interesting at the CLOS workshop that people shot down arguements about C++ as being faster, because it is an entirely different language. Well, PSL is LISP, not the same dialect as COMMON LISP, but faster. Nonetheless, PSL is not 7.5 times faster than COMMON LISP. ERNIE is just a much faster object system than PCL. In fact, compared to ERNIE, PCL looks like a real dog. I hope people are getting upset about this, because performance is a BIG issue, especially for simulation. Clearly, PCL is a much nicer system to use than ERNIE, but not all of the projects here can afford Dorados to just run toy simulations. The big simulations require big machines and efficient object systems. If people want PCL/CLOS to be used as a production system, serious performance improvements will have to be made. Otherwise, it will just be a nice toy. Chris Burdorf p.s. I could probably make my benchmark code available if anyone is interested. From Lanning.pa@Xerox.COM Mon Oct 10 17:03:06 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA26128; Mon, 10 Oct 88 17:03:06 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 OCT 88 17:00:16 PDT Date: 10 Oct 88 16:57 PDT From: Stan Lanning Subject: Re: PCL benchmark In-Reply-To: Chris Burdorf 's message of Mon, 10 Oct 88 15:07:58 PDT To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Message-Id: <881010-170016-4693@Xerox> I think you may be confusing CLOS with PCL (something that we all did at the workshop, I'm afraid). The discusions at the workshop regarding performance were about reasonable performance expectations for PCL *in the (near) future*. These performance expectations in turn are not as good as "native" implementations (like the TI version) that was also discussed. The current PCL (whatever version you are running -- you didn't say) is far from the best that it can be. But that will be changing soon. Gregor is off at an X3J13 meeting this week. I'm sure he will have a few words to say when he returns. ----- smL From Owners-CommonLoops.PA@Xerox.COM Mon Oct 10 18:46:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA26847; Mon, 10 Oct 88 18:46:46 PDT Received: from Salvador.ms by ArpaGateway.ms ; 10 OCT 88 18:44:34 PDT Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 10 OCT 88 18:42:33 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Mon, 10 Oct 88 18:41:58 pdt Received: from loopback by hplwhh.HPL.HP.COM; Mon, 10 Oct 88 18:41:32 pdt To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of "Mon, 10 Oct 88 15:07:58 PDT." <8810102208.AA01749@rand.org> Date: Mon, 10 Oct 88 18:41:29 PDT Message-Id: <11863.592537289@hplwhh> From: Warren Harris Maybe you should describe ERNIE briefly. What features do you attribute its speed to? Is it because it does not do multimethod lookup, or is slot access somehow inherently faster? Is it because it was compiled with the PSL "system-lisp" level of optimization? We've found that the use of system-lisp in HP-CL I (a PSL derivative) increased its speed by orders of magnitude (i.e. in some cases we were looking at much more than 7.5 times faster than "legal" Common Lisp). From Owners-commonloops.pa@Xerox.COM Tue Oct 11 07:40:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA04241; Tue, 11 Oct 88 07:40:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 OCT 88 07:37:06 PDT Return-Path: Redistributed: commonloops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 11 OCT 88 07:34:28 PDT To: Warren Harris Cc: commonloops.pa@Xerox.COM Subject: Re: tracing generic functions In-Reply-To: Your message of Wed, 05 Oct 88 19:09:13 -0700. <7603.592106953@hplwhh> Date: Tue, 11 Oct 88 10:33:34 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881011-073706-5434@Xerox> To: commonloops.pa@xerox.com Subject: tracing generic functions X-Mailer: mh6.5 Date: Wed, 05 Oct 88 19:09:13 PDT Message-Id: <7603.592106953@hplwhh> From: Warren Harris Does the CLOS spec say anything about what should happen when you trace a generic function? I notice that in the AAAI PCL (Lucid) the following doesn't work: > (trace no-applicable-method) (NO-APPLICABLE-METHOD) > (generic-function-methods #'no-applicable-method) >>Error: No matching method for the generic-function #, when called with arguments (#). NOTICE-METHODS-CHANGE-2: Required arg 0 (GENERIC-FUNCTION): # Required arg 1 (ARGS): (# #) :A Abort to Lisp Top Level -> Sorry if this is in the spec and I missed it. Warren What happened is that when you traced no-applicable-method, trace wrapped some advice around it. So i no longer appears as a generic. If you really want to get confused, try recompiling a no-applicable-method method after you've traced it. To make PCL really work, we need to make advice smarter about generic functions and visa vera. k From Owners-CommonLoops.PA@Xerox.COM Tue Oct 11 10:10:12 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA04985; Tue, 11 Oct 88 10:10:12 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 11 OCT 88 09:53:40 PDT Return-Path: Redistributed: CommonLoops.PA Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 11 OCT 88 09:48:37 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA00534; Tue, 11 Oct 88 09:47:30 PDT From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8810111647.AA00534@paris.Berkeley.EDU> To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT. <8810102208.AA01749@rand.org> Reply-To: larus@ginger.Berkeley.EDU Date: Tue, 11 Oct 88 09:47:27 PDT I, and probably everyone else who has written a large, time-intensive program with PCL, have noticed the same problems. The current implementation of PCL has a number of serious performance bugs that Gregor is aware of. PCL consumes about 80% of the time in my code. The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods (20% of the time spend in one discriminator function). Compounding this problem is the slow speed of the cache miss code (20-30% of the time). The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. Gregor is aware of these problems and may have fixed them for the next release. I certainly hope so and I doubt that I'm the only one. /Jim From Owners-CommonLoops.PA@Xerox.COM Tue Oct 11 10:56:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA05228; Tue, 11 Oct 88 10:56:14 PDT Received: from Salvador.ms by ArpaGateway.ms ; 11 OCT 88 10:44:59 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 11 OCT 88 10:37:04 PDT Received: from localhost by rand.org; Tue, 11 Oct 88 10:12:47 PDT Message-Id: <8810111712.AA11214@rand.org> To: Warren Harris Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 18:41:29 PDT. <11863.592537289@hplwhh> Date: Tue, 11 Oct 88 10:12:44 PDT From: Chris Burdorf Firstly, No I didn't use any PSL "system" level of optimization. I've done some benchmarks between AKCL, and PSL and PSL is about twice as fast in the best cases. I'm not all that familiar with the internals of ERNIE, but I know that when you declare a class, you can list the methods associated with that class. This information is utilizated by the compiler to compile method invokations directly into function calls. Basically, ERNIE is set up so a lot of the decisions made by the object system are done at compile time as oppossed to run time as in PCL. Chris Burdorf From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 11:45:45 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA17927; Wed, 12 Oct 88 11:45:45 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 OCT 88 10:48:44 PDT Return-Path: Redistributed: CommonLoops.PA Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 12 OCT 88 10:46:14 PDT To: larus@GINGER.Berkeley.EDU Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Tue, 11 Oct 88 09:47:27 -0700. <8810111647.AA00534@paris.Berkeley.EDU> Date: Wed, 12 Oct 88 13:38:25 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881012-104844-1868@Xerox> Return-Path: Redistributed: CommonLoops.PA Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 11 OCT 88 09:48:37 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA00534; Tue, 11 Oct 88 09:47:30 PDT From: James Larus Message-Id: <8810111647.AA00534@paris.Berkeley.EDU> To: Chris Burdorf Cc: CommonLoops.PA@xerox.com Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT. <8810102208.AA01749@rand.org> Reply-To: larus@ginger.berkeley.edu Date: Tue, 11 Oct 88 09:47:27 PDT I, and probably everyone else who has written a large, time-intensive program with PCL, have noticed the same problems. The current implementation of PCL has a number of serious performance bugs that Gregor is aware of. PCL consumes about 80% of the time in my code. This does sound awful, but remember that some of this work would have to be done if you used some other implementation method. The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods (20% of the time spend in one discriminator function). Compounding this problem is the slow speed of the cache miss code (20-30% of the time). This is a good point, in the few systems i've studied, there are a few functions with lots of methods. Maybe there is an object oriented version of Zipf's law which might be something like "80 % of the time is spent in the 20% of the generic functions with the most methods". Jim, do your statistics support anything like this? Gregor is talking about letting the caches grow. The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! I think you can argue about the details of the meta level protocol for MAKE-INSTANCE, but in real programs, the generality of MAKE-INSTANCE is quite useful. Automatic GC is also useful, but in real programs when you need performance, you may need to come up with alternative methods. It would probably be a good metaprogramming exercise to write a FAST-MAKE-INSTANCE-CLASS-MIXIN. Heres one way to do it: In one application, Dave Plumber of Symbolics avoided FLAVOR:MAKE-INSTANCE overhead by allocating enough raw space to fit an instance, smashing the type bits properly, and copying initial slot values from a protototype. His comments indicate he didn't advocate programming this way, but he sure could make instances fast. Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. Gregor is aware of these problems and may have fixed them for the next release. I certainly hope so and I doubt that I'm the only one. /Jim From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 11:56:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18012; Wed, 12 Oct 88 11:56:43 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 OCT 88 11:47:57 PDT Return-Path: Redistributed: CommonLoops.PA Received: from SUMEX-AIM.Stanford.EDU ([10.0.0.56]) by Xerox.COM ; 12 OCT 88 11:38:40 PDT Date: Wed, 12 Oct 88 11:32:26 PDT From: James Rice Subject: CLOS, the book? To: CommonLoops.PA@Xerox.COM Message-Id: <12437886737.53.RICE@SUMEX-AIM.Stanford.EDU> At the workshop there was a lot of talk about the new book on CLOS programming. I even saw a copy for a few seconds but didn't write down the relevant data to enable me to track down a copy. Does anyone know any of the following: a) Author b) Title c) Publisher d) Whether it's actually any good? Many thanks in advance, Rice. ------- From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 12:50:14 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18416; Wed, 12 Oct 88 12:50:14 PDT Received: from Salvador.ms by ArpaGateway.ms ; 12 OCT 88 12:47:48 PDT Return-Path: <@EN-C06.Prime.COM:doug@zaphod.prime.com> Redistributed: CommonLoops.PA Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 12 OCT 88 12:45:27 PDT Received: from primerd.prime.com by EN-C06.Prime.COM; 12 Oct 88 15:44:55 EDT Received: from zaphod.prime.com by primerd.prime.com (4.0/SMI-4.0) id AA04141; Wed, 12 Oct 88 15:43:32 EDT Received: by zaphod.prime.com (4.0/SMI-4.0) id AA07463; Wed, 12 Oct 88 15:39:31 EDT Date: Wed, 12 Oct 88 15:39:31 EDT From: doug@zaphod.prime.com (Douglas Rand) Message-Id: <8810121939.AA07463@zaphod.prime.com> To: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark Cc: , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com It seems that a CLOS implementation could statically call the "right" method in unambiguous cases and that with some bookkeeping this would not break on addition of a new, more specific, method. This would be akin to the current declarations having effects on such standard generic functions as +, -, * and /. I think this is particularly possible inside most methods since most of the work is done on the passed object anyway. A competing factor that is making PCL slow right now is lack of serious optimization in method creation and slot access. I'd be interested in estimates from Gregor on the extent of difference this would make. Doug Rand (doug@zaphod.prime.com) From Owners-commonloops.PA@Xerox.COM Wed Oct 12 13:13:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18535; Wed, 12 Oct 88 13:13:47 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 OCT 88 13:05:11 PDT Return-Path: Redistributed: commonloops.PA Received: from ads.com ([128.229.30.16]) by Xerox.COM ; 12 OCT 88 13:02:28 PDT Received: from minerva.ads.com by ads.com (5.59/1.17) id AA00712; Sun, 11 Sep 88 13:03:29 PDT Received: by minerva.ads.com.emerald_city.arpa (3.2/SMI-3.2) id AA03305; Wed, 12 Oct 88 13:16:51 PDT Date: Wed, 12 Oct 88 13:16:51 PDT From: sowre%minerva@ads.com (Sam Owre) Message-Id: <8810122016.AA03305@minerva.ads.com.emerald_city.arpa> To: commonloops.PA@Xerox.COM Subject: Please add me Please add me to your mailing list Thanks Sam Owre From Owners-commonloops.pa@Xerox.COM Wed Oct 12 13:34:00 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18720; Wed, 12 Oct 88 13:34:00 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 OCT 88 13:16:25 PDT Return-Path: <@EN-C06.Prime.COM:doug@zaphod.prime.com> Redistributed: commonloops.pa Received: from EN-C06.Prime.COM ([192.5.58.32]) by Xerox.COM ; 12 OCT 88 13:14:31 PDT Received: from primerd.prime.com by EN-C06.Prime.COM; 12 Oct 88 16:14:07 EDT Received: from zaphod.prime.com by primerd.prime.com (4.0/SMI-4.0) id AA04413; Wed, 12 Oct 88 16:12:48 EDT Received: by zaphod.prime.com (4.0/SMI-4.0) id AA07515; Wed, 12 Oct 88 16:08:54 EDT Date: Wed, 12 Oct 88 16:08:54 EDT From: doug@zaphod.prime.com (Douglas Rand) Message-Id: <8810122008.AA07515@zaphod.prime.com> To: Rice@SUMEX-AIM.STANFORD.EDU Subject: Re: CLOS, the book? Cc: commonloops.pa@Xerox.COM Author: Sonya Keene Title: Object-Oriented Programming in Common LISP Publisher: Addison Wesley ISBN 0 - 201 - 17589 - 4 So far it's OK but it has a lot of examples that would only work on a LispM and that's not so great. I certainly is more readable for most folks then the specification, but that isn't suprising since the spec. is, quite correctly, aimed at implementers and not application developers. Doug Rand From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 13:37:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18771; Wed, 12 Oct 88 13:37:17 PDT Received: from Semillon.ms by ArpaGateway.ms ; 12 OCT 88 13:27:09 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.PA Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 OCT 88 13:23:36 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Wed 12 Oct 88 14:55:19-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA17772; Wed, 12 Oct 88 14:54:56 CDT Date: Wed, 12 Oct 88 14:54:54 CDT From: Rob Pettengill Message-Id: <8810121954.AA14555@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA14555; Wed, 12 Oct 88 14:54:54 CDT To: larus@paris.berkeley.edu Cc: kanderso@PEBBLES.BBN.COM, burdorf@RAND-UNIX.ARPA, CommonLoops.PA@Xerox.COM In-Reply-To: kanderso@PEBBLES.BBN.COM's message of Wed, 12 Oct 88 13:38:25 -0400 <881012-104844-1868@Xerox> Subject: PCL benchmark Redistributed: CommonLoops.PA From: James Larus To: Chris Burdorf Cc: CommonLoops.PA@xerox.com Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT. <8810102208.AA01749@rand.org> Reply-To: larus@ginger.berkeley.edu Date: Tue, 11 Oct 88 09:47:27 PDT ... The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods (20% of the time spend in one discriminator function). Compounding this problem is the slow speed of the cache miss code (20-30% of the time). ... I believe that the performance of the cache has been greatly improved recently. Previously the low order bits of the byte address of the word aligned class-wrapper were used for the cache key - this resulted in caches that could never be more than 25% full. This gave a very high probability of thrashing. Gregor's new scheme allows full use of the cache with 3 layers of possible cache hits: the key location, the folded key location, and any location in the cache. This should dramaticly improve the previous cache performance. It would be nice to have dynamicly expandable caches in the future. For now, it is also easy to recompile PCL with a larger cache. ;rob 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 Wed Oct 12 13:45:07 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18856; Wed, 12 Oct 88 13:45:07 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 13:29:30 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.PA Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 OCT 88 13:25:24 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Wed 12 Oct 88 14:57:33-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA17801; Wed, 12 Oct 88 14:57:25 CDT Date: Wed, 12 Oct 88 14:57:23 CDT From: Rob Pettengill Message-Id: <8810121957.AA14569@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA14569; Wed, 12 Oct 88 14:57:23 CDT To: Rice@SUMEX-AIM.STANFORD.EDU Cc: CommonLoops.PA@Xerox.COM In-Reply-To: James Rice's message of Wed, 12 Oct 88 11:32:26 PDT <12437886737.53.RICE@SUMEX-AIM.Stanford.EDU> Subject: CLOS, the book? "Object-Oriented Programming in Common Lisp" Sonya E. Keene, Addison-Wesley, 1988, ISBN 0-201-17589-4 $26.75 ;rob 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 Wed Oct 12 13:49:25 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18913; Wed, 12 Oct 88 13:49:25 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 OCT 88 13:29:12 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 12 OCT 88 13:24:50 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: generic-function-effective-method? Date: Wed, 12 Oct 88 16:14:16 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881012-132912-2319@Xerox> The CLOS MOP doesn't define a function like GENERIC-FUNCTION-EFFECTIVE-METHOD, though i think it would be quite easy to do and fairly useful: The CLOS spec suggests that the internals of a generic generic function might look something like: (lambda (&rest args) ;; Find the effective method. (let ((m (apply #'generic-function-effective-method .gf. args))) (if m (apply m args) ; Run it. (apply #'no-applicable-method .gf. args)))) Where .gf. is the generic function we are trying to run. Although it would be very slow to actually do it this way, it nicely separates the method discrimination from the application of the effective method (which really isn't a method, is it?). PCL avoids doing this at all cost, in fact it tries to combine discrimination and effective method application as tightly as possible. However, a programmer might occasionally use this: EXAMPLE 1: Pull discrimination out of a loop: ;;; Rather than: (dotimes (i 10000) (generic-frob object)) ;;; One could write: (let ((m (generic-function-effective-method generic-frob object))) (dotimes (i 10000) (funcall m object))) ; Hope no one is redefining generic-frob. OK, so ideally where only saving a few instructions, BUT they can add up. EXAMPLE 2: Method delegation. The essence of method delegation is: (defclass delegate-mixin () ((delegate-to :initform nil :initarg :delegate-to :reader delegate-to))) (defmethod delegate-to ((thing t)) ;; Normally don't delegate. nil) (defmethod delegate ((gf standard-generic-function) &rest args) ;; Delegate is like apply. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (apply #'buck-stops-here gf args)))) (defmethod find-delegated-method ((gf standard-generic-function) (client delegate-mixin) &rest args) (let ((server (delegate-to client))) (if server (apply #'generic-function-effective-method gf server args)))) (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (apply #'delegate gf args)) OK, so it isn't fast, but it works. I think it would be useful to have such generic functions as GENERIC-FUNCTION-EFFECTIVE-METHOD for meta level hacking. I realize it adds more to the languages, but it does make small extentions easier, and more portable, and has good expository value. k From Owners-commonloops.pa@Xerox.COM Wed Oct 12 14:10:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19075; Wed, 12 Oct 88 14:10:10 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 OCT 88 13:53:53 PDT Return-Path: Redistributed: commonloops.pa Received: from ti.com ([10.7.0.46]) by Xerox.COM ; 12 OCT 88 13:49:43 PDT Received: by ti.com id AA07090; Wed, 12 Oct 88 15:49:17 CDT Received: from Atom by tilde id AA16682; Wed, 12 Oct 88 15:41:32 CDT Message-Id: <2801680881-3041283@Atom> Sender: FORD@Atom.csc.ti.com Date: Wed, 12 Oct 88 15:41:21 CDT From: Steve Ford To: James Rice Cc: CommonLoops.PA@Xerox.COM Subject: Re: CLOS, the book? In-Reply-To: Msg of Wed, 12 Oct 88 11:32:26 PDT from James Rice At the workshop there was a lot of talk about the new book on CLOS programming. I even saw a copy for a few seconds but didn't write down the relevant data to enable me to track down a copy. Does anyone know any of the following: a) Author b) Title c) Publisher d) Whether it's actually any good? Many thanks in advance, Rice. ------- a) Sonya E. Keene b) "Object-Oriented Programming in Common Lisp A Programmer's Guide to CLOS" c) Addison-Wesley d) Yes There was a big pile of them at the Stanford bookstore last week. Steve Ford From Owners-commonloops.pa@Xerox.COM Wed Oct 12 14:20:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19196; Wed, 12 Oct 88 14:20:53 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 14:14:12 PDT Return-Path: Redistributed: commonloops.pa Received: from tut.cis.ohio-state.edu ([128.146.8.60]) by Xerox.COM ; 12 OCT 88 14:11:38 PDT Received: by tut.cis.ohio-state.edu (5.54/2.880920) id AA00651; Wed, 12 Oct 88 17:11:44 EDT Date: Wed, 12 Oct 88 17:11:44 EDT From: welch@tut.cis.ohio-state.edu (Arun Welch) Message-Id: <8810122111.AA00651@tut.cis.ohio-state.edu> To: commonloops.pa@Xerox.COM Subject: Workshop notes For those of us who couldn't make it to the workshop, is there going to be a proceedings or workshop notes published? ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@tut.cis.ohio-state.edu From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 14:35:58 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19346; Wed, 12 Oct 88 14:35:58 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 14:30:57 PDT Return-Path: Redistributed: CommonLoops.PA Received: from cheddar.cs.wisc.edu ([128.105.2.113]) by Xerox.COM ; 12 OCT 88 14:28:22 PDT Message-Id: <8810122126.AA05546@cheddar.cs.wisc.edu> Received: from localhost.WISC.EDU by cheddar.cs.wisc.edu; Wed, 12 Oct 88 16:26:03 CDT From: "David C. Martin" Organization: University of Wisconsin - Madison Email: dcmartin@cheddar.cs.wisc.edu or ..!ucbvax!dcmartin Phone: 608/262-6624 (O) To: James Rice Cc: CommonLoops.PA@Xerox.COM Precedence: special-delivery In-Reply-To: Your message of Wed, 12 Oct 88 11:32:26 PDT <12437886737.53.RICE@SUMEX-AIM.Stanford.EDU> Subject: Re: CLOS, the book? Date: Wed, 12 Oct 88 16:25:59 -0500 Sender: dcmartin@cs.wisc.edu Just bought it.. $25, seems good so far, haven't read much, but flipping through it seems to cover just about everything but a small fraction of the functions and the metaobject protocol. Object-Oriented Programming in Common Lisp (A Programmer's Guide to CLOS), Sonya E. Keene, Addison-Wesley, ISBN: 0-201-17589-4 dcm From Owners-commonloops.pa@Xerox.COM Wed Oct 12 15:32:43 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19673; Wed, 12 Oct 88 15:32:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 15:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 12 OCT 88 15:28:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02839; Wed, 12 Oct 88 15:25:20 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA19790; Wed, 12 Oct 88 15:28:11 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA14730; Wed, 12 Oct 88 15:28:12 PDT Message-Id: <8810122228.AA14730@suntana.sun.com> To: doug@zaphod.prime.com (Douglas Rand) Cc: CommonLoops.PA@Xerox.COM, , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com Subject: Re: PCL benchmark In-Reply-To: Your message of Wed, 12 Oct 88 15:39:31 -0400. <8810121939.AA07463@zaphod.prime.com> Date: Wed, 12 Oct 88 15:28:08 PDT From: kempf@Sun.COM Class creation tends to be on the slow side too. For languages where this happens at load time, there is no problem (except for waiting for loads) but Strobe creates classes on the fly and so it tends to be slow. I don't know how much can be done about this, however, other than general speedup in instance creation and generic function invocation. jak From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 23:04:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA17927; Wed, 12 Oct 88 11:45:45 PDT Received: from Burger.ms by ArpaGateway.ms ; 12 OCT 88 10:48:44 PDT Return-Path: Redistributed: CommonLoops.PA Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 12 OCT 88 10:46:14 PDT To: larus@GINGER.Berkeley.EDU Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Tue, 11 Oct 88 09:47:27 -0700. <8810111647.AA00534@paris.Berkeley.EDU> Date: Wed, 12 Oct 88 13:38:25 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881012-104844-1868@Xerox> Return-Path: Redistributed: CommonLoops.PA Received: from paris.Berkeley.EDU ([128.32.150.46]) by Xerox.COM ; 11 OCT 88 09:48:37 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA00534; Tue, 11 Oct 88 09:47:30 PDT From: James Larus Message-Id: <8810111647.AA00534@paris.Berkeley.EDU> To: Chris Burdorf Cc: CommonLoops.PA@xerox.com Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 PDT. <8810102208.AA01749@rand.org> Reply-To: larus@ginger.berkeley.edu Date: Tue, 11 Oct 88 09:47:27 PDT I, and probably everyone else who has written a large, time-intensive program with PCL, have noticed the same problems. The current implementation of PCL has a number of serious performance bugs that Gregor is aware of. PCL consumes about 80% of the time in my code. This does sound awful, but remember that some of this work would have to be done if you used some other implementation method. The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods (20% of the time spend in one discriminator function). Compounding this problem is the slow speed of the cache miss code (20-30% of the time). This is a good point, in the few systems i've studied, there are a few functions with lots of methods. Maybe there is an object oriented version of Zipf's law which might be something like "80 % of the time is spent in the 20% of the generic functions with the most methods". Jim, do your statistics support anything like this? Gregor is talking about letting the caches grow. The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! I think you can argue about the details of the meta level protocol for MAKE-INSTANCE, but in real programs, the generality of MAKE-INSTANCE is quite useful. Automatic GC is also useful, but in real programs when you need performance, you may need to come up with alternative methods. It would probably be a good metaprogramming exercise to write a FAST-MAKE-INSTANCE-CLASS-MIXIN. Heres one way to do it: In one application, Dave Plumber of Symbolics avoided FLAVOR:MAKE-INSTANCE overhead by allocating enough raw space to fit an instance, smashing the type bits properly, and copying initial slot values from a protototype. His comments indicate he didn't advocate programming this way, but he sure could make instances fast. Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. Gregor is aware of these problems and may have fixed them for the next release. I certainly hope so and I doubt that I'm the only one. /Jim From Owners-CommonLoops.PA@Xerox.COM Wed Oct 12 23:18:44 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18856; Wed, 12 Oct 88 13:45:07 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 13:29:30 PDT Return-Path: <@MCC.COM:rcp%sw.MCC.COM@MCC.COM> Redistributed: CommonLoops.PA Received: from MCC.COM ([10.3.0.62]) by Xerox.COM ; 12 OCT 88 13:25:24 PDT Received: from milano.sw.mcc.com by MCC.COM with TCP/SMTP; Wed 12 Oct 88 14:57:33-CDT Received: from perseus.sw.mcc.com by milano.sw.mcc.com (5.51/STP1.56) id AA17801; Wed, 12 Oct 88 14:57:25 CDT Date: Wed, 12 Oct 88 14:57:23 CDT From: Rob Pettengill Message-Id: <8810121957.AA14569@perseus.sw.mcc.com> Received: by perseus.sw.mcc.com (3.2/STP1.14) id AA14569; Wed, 12 Oct 88 14:57:23 CDT To: Rice@SUMEX-AIM.STANFORD.EDU Cc: CommonLoops.PA@Xerox.COM In-Reply-To: James Rice's message of Wed, 12 Oct 88 11:32:26 PDT <12437886737.53.RICE@SUMEX-AIM.Stanford.EDU> Subject: CLOS, the book? "Object-Oriented Programming in Common Lisp" Sonya E. Keene, Addison-Wesley, 1988, ISBN 0-201-17589-4 $26.75 ;rob 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 Wed Oct 12 23:44:51 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA18913; Wed, 12 Oct 88 13:49:25 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 12 OCT 88 13:29:12 PDT Return-Path: Redistributed: CommonLoops.pa Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 12 OCT 88 13:24:50 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@PEBBLES.BBN.COM Subject: generic-function-effective-method? Date: Wed, 12 Oct 88 16:14:16 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881012-132912-2319@Xerox> The CLOS MOP doesn't define a function like GENERIC-FUNCTION-EFFECTIVE-METHOD, though i think it would be quite easy to do and fairly useful: The CLOS spec suggests that the internals of a generic generic function might look something like: (lambda (&rest args) ;; Find the effective method. (let ((m (apply #'generic-function-effective-method .gf. args))) (if m (apply m args) ; Run it. (apply #'no-applicable-method .gf. args)))) Where .gf. is the generic function we are trying to run. Although it would be very slow to actually do it this way, it nicely separates the method discrimination from the application of the effective method (which really isn't a method, is it?). PCL avoids doing this at all cost, in fact it tries to combine discrimination and effective method application as tightly as possible. However, a programmer might occasionally use this: EXAMPLE 1: Pull discrimination out of a loop: ;;; Rather than: (dotimes (i 10000) (generic-frob object)) ;;; One could write: (let ((m (generic-function-effective-method generic-frob object))) (dotimes (i 10000) (funcall m object))) ; Hope no one is redefining generic-frob. OK, so ideally where only saving a few instructions, BUT they can add up. EXAMPLE 2: Method delegation. The essence of method delegation is: (defclass delegate-mixin () ((delegate-to :initform nil :initarg :delegate-to :reader delegate-to))) (defmethod delegate-to ((thing t)) ;; Normally don't delegate. nil) (defmethod delegate ((gf standard-generic-function) &rest args) ;; Delegate is like apply. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (apply #'buck-stops-here gf args)))) (defmethod find-delegated-method ((gf standard-generic-function) (client delegate-mixin) &rest args) (let ((server (delegate-to client))) (if server (apply #'generic-function-effective-method gf server args)))) (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (apply #'delegate gf args)) OK, so it isn't fast, but it works. I think it would be useful to have such generic functions as GENERIC-FUNCTION-EFFECTIVE-METHOD for meta level hacking. I realize it adds more to the languages, but it does make small extentions easier, and more portable, and has good expository value. k From Owners-commonloops.pa@Xerox.COM Thu Oct 13 00:28:59 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19673; Wed, 12 Oct 88 15:32:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 15:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 12 OCT 88 15:28:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02839; Wed, 12 Oct 88 15:25:20 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA19790; Wed, 12 Oct 88 15:28:11 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA14730; Wed, 12 Oct 88 15:28:12 PDT Message-Id: <8810122228.AA14730@suntana.sun.com> To: doug@zaphod.prime.com (Douglas Rand) Cc: CommonLoops.PA@Xerox.COM, , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com Subject: Re: PCL benchmark In-Reply-To: Your message of Wed, 12 Oct 88 15:39:31 -0400. <8810121939.AA07463@zaphod.prime.com> Date: Wed, 12 Oct 88 15:28:08 PDT From: kempf@Sun.COM Class creation tends to be on the slow side too. For languages where this happens at load time, there is no problem (except for waiting for loads) but Strobe creates classes on the fly and so it tends to be slow. I don't know how much can be done about this, however, other than general speedup in instance creation and generic function invocation. jak From Owners-CommonLoops.PA@Xerox.COM Thu Oct 13 08:05:27 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA27722; Thu, 13 Oct 88 08:05:27 PDT Received: from Burger.ms by ArpaGateway.ms ; 13 OCT 88 07:53:07 PDT Return-Path: Redistributed: CommonLoops.PA Received: from PEBBLES.BBN.COM ([128.89.1.5]) by Xerox.COM ; 13 OCT 88 07:52:13 PDT To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Mon, 10 Oct 88 15:07:58 -0700. <8810102208.AA01749@rand.org> Date: Thu, 13 Oct 88 10:55:47 -0400 From: kanderso@PEBBLES.BBN.COM Message-Id: <881013-075307-3754@Xerox> I assume you are using the latest PCL. Can you say anything about why you thing ERNIE is so much faster? I think it would be great to collect a bunch of benchmarks. Do you what of PCL your simulation tends to measure? k From Owners-commonloops.pa@Xerox.COM Thu Oct 13 08:28:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA27802; Thu, 13 Oct 88 08:28:26 PDT Received: from Salvador.ms by ArpaGateway.ms ; 13 OCT 88 08:12:34 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 13 OCT 88 08:10:10 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA15138; Thu, 13 Oct 88 08:07:44 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA05080; Thu, 13 Oct 88 08:10:41 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA16624; Thu, 13 Oct 88 08:10:45 PDT Message-Id: <8810131510.AA16624@suntana.sun.com> To: commonLoops.pa@Xerox.COM Subject: PCL/CLOS performance In-Reply-To: Your message of Wed, 12 Oct 88 13:38:25 -0400. <881012-104844-1868@Xerox> Date: Thu, 13 Oct 88 08:10:43 PDT From: kempf@Sun.COM I would caution people who are unhappy with PCL performance to take a look at what your underlying Common Lisp is doing. Depending on your Common Lisp, the performance of current PCL generic function invocation can vary from 3.5X to 15X a function call. There is much that can be done in an implementation dependent manner to speed up PCL, however, it is unfair to say that CLOS or PCL is a dog just because the Common Lisp you happen to be using doesn't generate particularly good code at the moment. If you are otherwise happy with your Common Lisp, then talk to whoever is supporting it about improving code generation, otherwise, look into getting a new one. In the long run, I think everyone's Common Lisp should converge to about 2.0-2.5X a function call for a single argument dispatch message send, possibly faster, if the TICLOS implementation is any guide. jak From Owners-CommonLoops.PA@Xerox.COM Thu Oct 13 12:20:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA00082; Thu, 13 Oct 88 12:20:15 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 OCT 88 10:15:41 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 13 OCT 88 09:56:34 PDT Received: from localhost by rand.org; Thu, 13 Oct 88 09:48:10 PDT Message-Id: <8810131648.AA17008@rand.org> To: kanderso@pebbles.bbn.com Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Thu, 13 Oct 88 10:55:47 D. Date: Thu, 13 Oct 88 09:47:58 PDT From: Chris Burdorf I had it running under the 8/8/88 version of PCL. Due to people's comments I am trying to get it running under the latest version of PCL with a test copy of Allegro(I couldn't get the latest PCL to work under my copy of AKCL). However, I've found that I have to change some of the code in my simulation that worked under the AKCL PCL, but doesn't work under the allegro PCL. Meanwhile, my boss is flaming at me to get some other things done, so I'll have to put it on the backburner for awhile. I'll let you know when I get it to run. Ernie is faster because at compilation it handles much of the decision making that PCL handles at runtime. Chris From Owners-CommonLoops.PA@Xerox.COM Thu Oct 13 12:38:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA01922; Thu, 13 Oct 88 12:38:17 PDT Received: from Burger.ms by ArpaGateway.ms ; 13 OCT 88 11:45:47 PDT Return-Path: <@CUNYVM.CUNY.EDU:YLIKOSKI@FINFUN.BITNET> Redistributed: CommonLoops.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 13 OCT 88 11:44:30 PDT Received: from FINFUN.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1783; Thu, 13 Oct 88 13:54:23 EDT Date: Thu, 13 Oct 88 18:23 O From: Antti Ylikoski tel +358 0 457 2704 Subject: the availability of CLOS without FTP To: CommonLoops.PA@Xerox.COM X-Vms-To: @CLOS,YLIKOSKI Message-Id: <881013-114547-4331@Xerox> I haven't access to the File Transfer Protocol (FTP), and I would like to get the PCL version of the CLOS. Is it possible to get the CLOS either a) on a tape or b) with UUCP to the user ay@hutcs.hut.fi ? Thanks in advance, Andy Ylikoski ------------------------------------------------------------------------------ Antti Ylikoski |YLIKOSKI@FINFUN (BITNET) Helsinki University of Technology | Laboratory of Information Processing |ay@hutcs.hut.fi (UUCP) Science |YLIKOSKI@OPMVAX.KPO.FI Otakaari 5 A | SF-02150 Espoo, Finland | ------------------------------------------------------------------------------ From Owners-CommonLoops.PA@Xerox.COM Thu Oct 13 15:46:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA04659; Thu, 13 Oct 88 15:46:09 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 OCT 88 15:20:36 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 13 OCT 88 15:11:42 PDT Received: from localhost by rand.org; Thu, 13 Oct 88 14:59:50 PDT Message-Id: <8810132159.AA22984@rand.org> To: kanderso@pebbles.bbn.com Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Thu, 13 Oct 88 10:55:47 D. <881013-075307-3754@Xerox> Date: Thu, 13 Oct 88 14:59:46 PDT From: Chris Burdorf I got my carwash benchmark demo working under Allegro. I also checked the Ernie version and it was not entirely consistent with the PCL version, so I corrected that (sorry). The more correct (than the previous) timings I have now stand at: Ernie 7 seconds Allegro PCL 20 seconds AKCL PCL 30 seconds. I have already sent out the code to two people. Let me know if any of the rest of you are interested in getting it. Chris Burdorf From Owners-commonloops.pa@Xerox.COM Fri Oct 14 01:10:04 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19673; Wed, 12 Oct 88 15:32:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 15:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 12 OCT 88 15:28:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02839; Wed, 12 Oct 88 15:25:20 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA19790; Wed, 12 Oct 88 15:28:11 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA14730; Wed, 12 Oct 88 15:28:12 PDT Message-Id: <8810122228.AA14730@suntana.sun.com> To: doug@zaphod.prime.com (Douglas Rand) Cc: CommonLoops.PA@Xerox.COM, , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com Subject: Re: PCL benchmark In-Reply-To: Your message of Wed, 12 Oct 88 15:39:31 -0400. <8810121939.AA07463@zaphod.prime.com> Date: Wed, 12 Oct 88 15:28:08 PDT From: kempf@Sun.COM Class creation tends to be on the slow side too. For languages where this happens at load time, there is no problem (except for waiting for loads) but Strobe creates classes on the fly and so it tends to be slow. I don't know how much can be done about this, however, other than general speedup in instance creation and generic function invocation. jak From Owners-commonloops.pa@Xerox.COM Fri Oct 14 01:55:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA27802; Thu, 13 Oct 88 08:28:26 PDT Received: from Salvador.ms by ArpaGateway.ms ; 13 OCT 88 08:12:34 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 13 OCT 88 08:10:10 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA15138; Thu, 13 Oct 88 08:07:44 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA05080; Thu, 13 Oct 88 08:10:41 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA16624; Thu, 13 Oct 88 08:10:45 PDT Message-Id: <8810131510.AA16624@suntana.sun.com> To: commonLoops.pa@Xerox.COM Subject: PCL/CLOS performance In-Reply-To: Your message of Wed, 12 Oct 88 13:38:25 -0400. <881012-104844-1868@Xerox> Date: Thu, 13 Oct 88 08:10:43 PDT From: kempf@Sun.COM I would caution people who are unhappy with PCL performance to take a look at what your underlying Common Lisp is doing. Depending on your Common Lisp, the performance of current PCL generic function invocation can vary from 3.5X to 15X a function call. There is much that can be done in an implementation dependent manner to speed up PCL, however, it is unfair to say that CLOS or PCL is a dog just because the Common Lisp you happen to be using doesn't generate particularly good code at the moment. If you are otherwise happy with your Common Lisp, then talk to whoever is supporting it about improving code generation, otherwise, look into getting a new one. In the long run, I think everyone's Common Lisp should converge to about 2.0-2.5X a function call for a single argument dispatch message send, possibly faster, if the TICLOS implementation is any guide. jak From Owners-CommonLoops.PA@Xerox.COM Fri Oct 14 02:25:56 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA00082; Thu, 13 Oct 88 12:20:15 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 OCT 88 10:15:41 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 13 OCT 88 09:56:34 PDT Received: from localhost by rand.org; Thu, 13 Oct 88 09:48:10 PDT Message-Id: <8810131648.AA17008@rand.org> To: kanderso@pebbles.bbn.com Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Thu, 13 Oct 88 10:55:47 D. Date: Thu, 13 Oct 88 09:47:58 PDT From: Chris Burdorf I had it running under the 8/8/88 version of PCL. Due to people's comments I am trying to get it running under the latest version of PCL with a test copy of Allegro(I couldn't get the latest PCL to work under my copy of AKCL). However, I've found that I have to change some of the code in my simulation that worked under the AKCL PCL, but doesn't work under the allegro PCL. Meanwhile, my boss is flaming at me to get some other things done, so I'll have to put it on the backburner for awhile. I'll let you know when I get it to run. Ernie is faster because at compilation it handles much of the decision making that PCL handles at runtime. Chris From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Fri Oct 14 15:13:06 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA15082; Fri, 14 Oct 88 15:13:06 PDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Oct 88 15:10:23 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 14:50:43 PDT Date: 14 Oct 88 14:50 PDT From: masinter.pa@Xerox.COM Subject: Re: Issue: EVAL-OTHER (Version 2) In-Reply-To: Brad Miller 's message of Mon, 10 Oct 88 16:41 EDT To: miller@CS.ROCHESTER.EDU Cc: common-lisp-object-system@SAIL.STANFORD.EDU Message-Id: <881014-145043-7455@Xerox> My impression from hearing about current applications of CLOS is that your assertion "w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL" is not true. CLOS claim to integration in CL comes both from the integration of method invocation with function call and the integration of the class hierarchy with the previous Common Lisp type hierarchy. Both of those allow for treating CLOS as the language and CLtL as the previous subset. CLOS and CL are consistent in treating the type hierarchy as the mechanism of dispatching on varying forms of behavior, but not relying too heavily on the function-as-object style which is popular in Scheme. The notion of making APPLY (or FUNCALL) generic is possibly quite interesting, although it implies a different model of "object oriented" than the one currently embodied in Common Lisp and CLOS. From Gregor.pa@Xerox.COM Fri Oct 14 19:36:12 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA17864; Fri, 14 Oct 88 19:36:12 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 19:28:31 PDT Date: Fri, 14 Oct 88 19:25 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Chris Burdorf Cc: Stan Lanning , Warren Harris , larus@ginger.Berkeley.EDU, kanderso@PEBBLES.BBN.COM, Douglas Rand , Rob Pettengill , kempf@Sun.COM, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810102208.AA01749@rand.org>, The message of 10 Oct 88 16:57 PDT from Stan Lanning , <11863.592537289@hplwhh>, <8810111647.AA00534@paris.Berkeley.EDU>, <8810111712.AA11214@rand.org>, The message of 12 Oct 88 10:38 PDT from kanderso@PEBBLES.BBN.COM, <8810121939.AA07463@zaphod.prime.com>, <8810121954.AA14555@perseus.sw.mcc.com>, <8810122228.AA14730@suntana.sun.com>, The message of 13 Oct 88 07:55 PDT from kanderso@PEBBLES.BBN.COM, <8810131510.AA16624@suntana.sun.com>, <8810131648.AA17008@rand.org>, <8810132159.AA22984@rand.org>, <8810142022.AA08760@taos.arpa> Message-Id: <19881015022537.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I hope people are getting upset about this, because performance is a BIG issue, especially for simulation. It does make me upset when a user is unhappy about a performance problem they are having. PCL performance is not what it could be, but as you heard at the workshop, there are plans to improve it dramatically by focusing on the implementation specific parts of it. Other implementation efforts, such as TI CLOS, provide encouragement that the result of these efforts will provide quite high performance. Date: Thu, 13 Oct 88 14:59:46 PDT From: Chris Burdorf Ernie 7 seconds Allegro PCL 20 seconds AKCL PCL 30 seconds. Hmm. It runs for me in .4 seconds in Lucid Lisp (SUN 4/110). I wonder what we are doing differently. There are a number issues involved is assessing the performance of any implementation of CLOS. Many of these have been raised in some of the earlier replies to your message. In this message, I will try to address some other issues, and try to summarize what need to be done next. *** Comparing Apples and Oranges *** This is a serious problem when measuring CLOS performance. Danny and I have been saying that it is important to measure "comparable programs". Among other things, we mean is that when re-writing a program from some other language to CLOS, it is important to be sure that the re-written program is as close as possible in functionality to the original. If CLOS doesn't let you get the re-write close, that reflects a problem with CLOS. But its important to try to use CLOS in the way that gets the most correct re-write. Of course this can take a couple of passes since we are all just learning how best to use the language. Taking advantage of the high performance aspects of a language can be deceptive. Stan Lanning has an interesting example of this which I hope he will send out on Monday. Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I just ran a simulation benchmark in PCL. It is a queueing simulation. To get it to run under PCL, I took the simulator from our own object system called ERNIE and converted it into PCL. I then converted the queueing simulation into PCL. The timings I got were as follows: Ernie 4 seconds PCL 30 seconds ERNIE runs under PSL. The version of PCL I have runs under AKCL. There are many possible problems here. Warren Harris mentioned the most prominent one. What is Ernie? In one of your later messages, you said that Ernie does earlier binding than CLOS does. Do you mean that Ernie is a statically typed language? Or does Ernie do "block compiling" by default? Either of these would make it a significantly different language than standard CLOS. Of course it is quite easy to customize CLOS to have these properties, perhaps that should be investigated. Also, what did the code look like in Ernie? Are you sure that when you did the translation you didn't add more "object orientedness" than was there in the first place. One specific question is whether, in Ernie, the accessors are generic. If the KCL port supported structure classes, you could experiment with rewriting this program using defstruct instead of defclass. A very serious issue is the quality of the KCL port of PCL. It is lousy, PCL performance in KCL is worse than in any other Common Lisp I know of. This is my fault, its just that not as much work has been done on the KCL port as on other ports. This shouldn't be too hard to fix. The people at Ibuki have promised to help with this, so there should be some significant improvement on this front soon. Also of importance is the difference between KCL and PSL. For a specific program, two Lisps which are otherwise relatively comparable can differ a lot. If the program happens to stress a place where the two lisps differ, the results can be dramatic. The PCL--KCL, Ernie--PSL relationships are also important. PCL is a portable program, and as I said, the KCL port of PCL is bad. You say that you do not use the PSL system-lisp optimization, but perhaps the implementor of Ernie does use it? When you compiled PCL in KCL did you set safety to 0 and speed to 3? *** Caching Problems *** Date: Tue, 11 Oct 88 09:47:27 PDT From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus) The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods ... Three comments: - Chris' code never gets cache misses, so this is not a problem in his system. - The issue is not whether the generic function has more than 32 methods. Rather it is how many different classes of arguments the generic function is called with. - As Rob Pettengill pointed out we have a much better strategy for dealing with this now, and we expect to have dynamically expanding caches this month. I hope this will make a significant difference in the performance of your program. The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. The metaobject mechanism is not really what causes performance problems in the initialization protocol. Users have wanted extensible initialization protocols in languages which didn't have a metaobject protocol. The initialization protocol is extensible, that can cause performance problems. But these are relatively easy to deal with. Patrick Dussud's implementation and mine both have techniques for solving them. The specific version of the constructor code that will be in the next release is not portable, but it is just an interim version of a mechanism that will be portable. In tests of the new mechanism at PARC, we have seen increases in instance creation performance of up to 100 times. An important point is that Chris' program doesn't call make-instance when it is "running", so that isn't causing him problems. *** Watch Out for Bugs *** I notice in the code you sent me that it prints a lot of messages when the simulator is running. I assume you commented out all these calls to format before you took these measurements, but the times you sent were so much greater than the .4 seconds I measured that I wonder. Certainly something like this could throw the timing off completely. *** Summary *** The following are needed: - more information about Ernie - what your program looked like when it was written in Ernie - make sure PCL was compiled with speed 3 and safety 0. - try a different port of PCL. - improve the port of PCL you have - check on the measurement technique used. Specifically make sure the calls to format were commented out. Each of these will tell us a little about what is going on here. I take your complaint about PCL performance quite seriously, but before things can be improved, we need to know what to improve. ------- From Owners-commonloops.pa@Xerox.COM Sat Oct 15 16:03:47 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19673; Wed, 12 Oct 88 15:32:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 15:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 12 OCT 88 15:28:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02839; Wed, 12 Oct 88 15:25:20 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA19790; Wed, 12 Oct 88 15:28:11 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA14730; Wed, 12 Oct 88 15:28:12 PDT Message-Id: <8810122228.AA14730@suntana.sun.com> To: doug@zaphod.prime.com (Douglas Rand) Cc: CommonLoops.PA@Xerox.COM, , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com Subject: Re: PCL benchmark In-Reply-To: Your message of Wed, 12 Oct 88 15:39:31 -0400. <8810121939.AA07463@zaphod.prime.com> Date: Wed, 12 Oct 88 15:28:08 PDT From: kempf@Sun.COM Class creation tends to be on the slow side too. For languages where this happens at load time, there is no problem (except for waiting for loads) but Strobe creates classes on the fly and so it tends to be slow. I don't know how much can be done about this, however, other than general speedup in instance creation and generic function invocation. jak From Gregor.pa@Xerox.COM Sat Oct 15 16:43:49 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA17864; Fri, 14 Oct 88 19:36:12 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 19:28:31 PDT Date: Fri, 14 Oct 88 19:25 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Chris Burdorf Cc: Stan Lanning , Warren Harris , larus@ginger.Berkeley.EDU, kanderso@PEBBLES.BBN.COM, Douglas Rand , Rob Pettengill , kempf@Sun.COM, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810102208.AA01749@rand.org>, The message of 10 Oct 88 16:57 PDT from Stan Lanning , <11863.592537289@hplwhh>, <8810111647.AA00534@paris.Berkeley.EDU>, <8810111712.AA11214@rand.org>, The message of 12 Oct 88 10:38 PDT from kanderso@PEBBLES.BBN.COM, <8810121939.AA07463@zaphod.prime.com>, <8810121954.AA14555@perseus.sw.mcc.com>, <8810122228.AA14730@suntana.sun.com>, The message of 13 Oct 88 07:55 PDT from kanderso@PEBBLES.BBN.COM, <8810131510.AA16624@suntana.sun.com>, <8810131648.AA17008@rand.org>, <8810132159.AA22984@rand.org>, <8810142022.AA08760@taos.arpa> Message-Id: <19881015022537.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I hope people are getting upset about this, because performance is a BIG issue, especially for simulation. It does make me upset when a user is unhappy about a performance problem they are having. PCL performance is not what it could be, but as you heard at the workshop, there are plans to improve it dramatically by focusing on the implementation specific parts of it. Other implementation efforts, such as TI CLOS, provide encouragement that the result of these efforts will provide quite high performance. Date: Thu, 13 Oct 88 14:59:46 PDT From: Chris Burdorf Ernie 7 seconds Allegro PCL 20 seconds AKCL PCL 30 seconds. Hmm. It runs for me in .4 seconds in Lucid Lisp (SUN 4/110). I wonder what we are doing differently. There are a number issues involved is assessing the performance of any implementation of CLOS. Many of these have been raised in some of the earlier replies to your message. In this message, I will try to address some other issues, and try to summarize what need to be done next. *** Comparing Apples and Oranges *** This is a serious problem when measuring CLOS performance. Danny and I have been saying that it is important to measure "comparable programs". Among other things, we mean is that when re-writing a program from some other language to CLOS, it is important to be sure that the re-written program is as close as possible in functionality to the original. If CLOS doesn't let you get the re-write close, that reflects a problem with CLOS. But its important to try to use CLOS in the way that gets the most correct re-write. Of course this can take a couple of passes since we are all just learning how best to use the language. Taking advantage of the high performance aspects of a language can be deceptive. Stan Lanning has an interesting example of this which I hope he will send out on Monday. Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I just ran a simulation benchmark in PCL. It is a queueing simulation. To get it to run under PCL, I took the simulator from our own object system called ERNIE and converted it into PCL. I then converted the queueing simulation into PCL. The timings I got were as follows: Ernie 4 seconds PCL 30 seconds ERNIE runs under PSL. The version of PCL I have runs under AKCL. There are many possible problems here. Warren Harris mentioned the most prominent one. What is Ernie? In one of your later messages, you said that Ernie does earlier binding than CLOS does. Do you mean that Ernie is a statically typed language? Or does Ernie do "block compiling" by default? Either of these would make it a significantly different language than standard CLOS. Of course it is quite easy to customize CLOS to have these properties, perhaps that should be investigated. Also, what did the code look like in Ernie? Are you sure that when you did the translation you didn't add more "object orientedness" than was there in the first place. One specific question is whether, in Ernie, the accessors are generic. If the KCL port supported structure classes, you could experiment with rewriting this program using defstruct instead of defclass. A very serious issue is the quality of the KCL port of PCL. It is lousy, PCL performance in KCL is worse than in any other Common Lisp I know of. This is my fault, its just that not as much work has been done on the KCL port as on other ports. This shouldn't be too hard to fix. The people at Ibuki have promised to help with this, so there should be some significant improvement on this front soon. Also of importance is the difference between KCL and PSL. For a specific program, two Lisps which are otherwise relatively comparable can differ a lot. If the program happens to stress a place where the two lisps differ, the results can be dramatic. The PCL--KCL, Ernie--PSL relationships are also important. PCL is a portable program, and as I said, the KCL port of PCL is bad. You say that you do not use the PSL system-lisp optimization, but perhaps the implementor of Ernie does use it? When you compiled PCL in KCL did you set safety to 0 and speed to 3? *** Caching Problems *** Date: Tue, 11 Oct 88 09:47:27 PDT From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus) The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods ... Three comments: - Chris' code never gets cache misses, so this is not a problem in his system. - The issue is not whether the generic function has more than 32 methods. Rather it is how many different classes of arguments the generic function is called with. - As Rob Pettengill pointed out we have a much better strategy for dealing with this now, and we expect to have dynamically expanding caches this month. I hope this will make a significant difference in the performance of your program. The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. The metaobject mechanism is not really what causes performance problems in the initialization protocol. Users have wanted extensible initialization protocols in languages which didn't have a metaobject protocol. The initialization protocol is extensible, that can cause performance problems. But these are relatively easy to deal with. Patrick Dussud's implementation and mine both have techniques for solving them. The specific version of the constructor code that will be in the next release is not portable, but it is just an interim version of a mechanism that will be portable. In tests of the new mechanism at PARC, we have seen increases in instance creation performance of up to 100 times. An important point is that Chris' program doesn't call make-instance when it is "running", so that isn't causing him problems. *** Watch Out for Bugs *** I notice in the code you sent me that it prints a lot of messages when the simulator is running. I assume you commented out all these calls to format before you took these measurements, but the times you sent were so much greater than the .4 seconds I measured that I wonder. Certainly something like this could throw the timing off completely. *** Summary *** The following are needed: - more information about Ernie - what your program looked like when it was written in Ernie - make sure PCL was compiled with speed 3 and safety 0. - try a different port of PCL. - improve the port of PCL you have - check on the measurement technique used. Specifically make sure the calls to format were commented out. Each of these will tell us a little about what is going on here. I take your complaint about PCL performance quite seriously, but before things can be improved, we need to know what to improve. ------- From Gregor.pa@Xerox.COM Sun Oct 16 11:33:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA06685; Sun, 16 Oct 88 11:33:20 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 11:29:22 PDT Date: Sun, 16 Oct 88 11:26 PDT From: Gregor.pa@Xerox.COM Subject: Re: Failed attempt to create a metaclass To: John Collins Cc: kenner@umn-cs.cs.umn.edu, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810071808.AA05547@mmm.3m.com> Message-Id: <19881016182649.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 07 Oct 88 13:08:06 CDT From: collins@mmm.3m.com (John Collins) I am trying to make a class that keeps a list of its instances around. This looked like a metaclass problem, so I wrote the following: (using the 8/28/88 version of PCL under Coral's Allegro Common Lisp on a Mac+) There is some debate about whether this is best done with a metaclass, or whether it is fine to do it with a mixin class that provides this behavior. This message includes both implementations. I can't tell from your message what problems you were having exactly, but I have tested the code I am sending you, so you shouldn't have problems with it. MAKE-INSTANCE is documented as a generic function, but is a function in PCL. I would have liked to specialize it for the subclass I created. *MAKE-INSTANCE is the current name for MAKE-INSTANCE. I can't stress enough how important it is to read the notes.text file carefully. There is nowhere near enough documentation for PCL, but what there is is essential reading. The symbol STANDARD-CLASS is not exported from the "PCL" package. Maybe you didn't intend to export it until the metaobject protocol is documented. Yes. DEFGENERIC doesn't seem to be defined. Maybe this is one of those differences between CLOS and PCL. Yes. The code follows: (in-package 'collins :use '(pcl lisp)) (import (mapcar #'(lambda (s) (find-symbol s (find-package 'pcl))) '("STANDARD-CLASS" "*MAKE-INSTANCE" "CHECK-SUPER-METACLASS-COMPATIBILITY" "*INITIALIZE-INSTANCE" "CLASS-PROTOTYPE"))) ;;; ;;; An implementation using a new metaclass. ;;; (defclass instance-list-class (standard-class) ((all-instances :initform nil :reader class-all-instances)) (:documentation "A metaclass that keeps track of its instances")) (defmethod check-super-metaclass-compatibility ((sub instance-list-class) (sup standard-class)) t) (defmethod check-super-metaclass-compatibility ((sub standard-class) (sup instance-list-class)) t) (defmethod *make-instance ((class instance-list-class) &rest args) (declare (ignore args)) (let ((instance (call-next-method))) (push instance (slot-value class 'all-instances)) instance)) (defclass foo () () (:metaclass instance-list-class)) ;;; ;;; An implementation using a mixin class. ;;; (defclass record-instances-mixin () ((all-instances-db :initform (make-hash-table :test #'eq :size 20) :allocation :class)) (:documentation "A mixin class to record all instances.")) (defmethod *initialize-instance :after ((inst record-instances-mixin) &rest initargs) (declare (ignore initargs)) (push inst (gethash (class-of inst) (slot-value inst 'all-instances-db) ())) inst) (defmethod class-all-instances ((class standard-class)) (class-all-instances-1 (class-prototype class) class)) (defmethod class-all-instances-1 ((proto record-instances-mixin) class) (gethash class (slot-value proto 'all-instances-db) ())) (defclass bar (record-instances-mixin) ()) ------- From Gregor.pa@Xerox.COM Sun Oct 16 11:59:53 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA06779; Sun, 16 Oct 88 11:59:53 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 11:56:52 PDT Date: Sun, 16 Oct 88 11:52 PDT From: Gregor.pa@Xerox.COM Subject: Re: generic-function-effective-method? To: kanderso@PEBBLES.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@PEBBLES.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 12 Oct 88 13:14 PDT from kanderso@PEBBLES.BBN.COM Message-Id: <19881016185239.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 12 Oct 88 16:14:16 -0400 From: kanderso@PEBBLES.BBN.COM The CLOS MOP doesn't define a function like GENERIC-FUNCTION-EFFECTIVE-METHOD, though i think it would be quite easy to do and fairly useful: Yes, it is useful, your two examples are not uncommon. It is easy enough to write using chapter 3 stuff that we don't provide it all packaged up. Another reason is that sometimes you want the "effective method", and sometimes you want a function you can apply. (defmethod generic-function-effective-method ((gf standard-generic-function) args) (let ((combin (generic-function-method-combination gf)) (methods (compute-applicable-methods gf args))) (compute-effective-method gf combin methods))) PCL avoids doing this at all cost, in fact it tries to combine discrimination and effective method application as tightly as possible. However, a programmer might occasionally use this: EXAMPLE 1: Pull discrimination out of a loop: ;;; Rather than: (dotimes (i 10000) (generic-frob object)) ;;; One could write: (let ((m (generic-function-effective-method generic-frob object))) (dotimes (i 10000) (funcall m object))) ; Hope no one is redefining generic-frob. OK, so ideally where only saving a few instructions, BUT they can add up. In order to do this, you would have to do some other playing around. The "effective method" itself is not a function that can be called. You make it into a function using make-method-function. Then you can call it using apply-method-function. ------- From Gregor.pa@Xerox.COM Sun Oct 16 12:10:37 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA06840; Sun, 16 Oct 88 12:10:37 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 12:05:46 PDT Date: Sun, 16 Oct 88 12:02 PDT From: Gregor.pa@Xerox.COM Subject: Re: CLOS Chapter 3 To: Kerry Kimbrough Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <2801254139-12269376@Sierra> Message-Id: <19881016190234.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 7 Oct 88 17:08:59 CDT From: Kerry Kimbrough The metaclass protocol -- What is the most recent available version of this? Where can I get a copy? How stable is this chapter now? Am I having fun yet? We are busy working away on Chapter 3. There is no version of it available now, since we are between drafts. We have promised to have a final draft available in December for voting on at the January X3J13 meeting. This draft will be available to the entire mailing list in December. ------- From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Sun Oct 16 13:20:11 1988 Received: from [36.86.0.194] by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA07121; Sun, 16 Oct 88 13:20:11 PDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Oct 88 13:16:48 PDT Received: from blacksox ([192.9.201.39]) by LUCID.COM id AA04291g; Sun, 16 Oct 88 13:16:40 PDT Received: by blacksox id AA00239g; Sun, 16 Oct 88 13:12:45 pdt Date: Sun, 16 Oct 88 13:12:45 pdt From: Eric Benson Message-Id: <8810162012.AA00239@blacksox> To: common-lisp-object-system@SAIL.STANFORD.EDU Subject: CLOS analogue to TYPEP and SUBTYPEP I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS. Given two class objects, I need to know whether one is a superclass of the other. I can't seem to find such a function in Chapter 2. Have I missed something, is this relegated to Chapter 3, or is there something inherently bogus about what I'm trying to do? It seems like a rather ordinary thing, not terribly metaclassy. This came up while writing a program using CLOS that is intended to be a simple example. From Common-Lisp-Object-System-mailer@SAIL.STANFORD.EDU Sun Oct 16 15:48:52 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA07682; Sun, 16 Oct 88 15:48:52 PDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Oct 88 15:45:20 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 15:45:05 PDT Date: Sun, 16 Oct 88 15:44 PDT From: Gregor.pa@Xerox.COM Subject: Re: CLOS analogue to TYPEP and SUBTYPEP To: Eric Benson Cc: common-lisp-object-system@SAIL.STANFORD.EDU Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810162012.AA00239@blacksox> Message-Id: <19881016224404.9.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Sun, 16 Oct 88 13:12:45 pdt From: Eric Benson I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS. Given two class objects, I need to know whether one is a superclass of the other. I can't seem to find such a function in Chapter 2. Have I missed something, is this relegated to Chapter 3, or is there something inherently bogus about what I'm trying to do? It seems like a rather ordinary thing, not terribly metaclassy. This came up while writing a program using CLOS that is intended to be a simple example. According to CLOS, you should be able to pass class objects or class names to subtypep and typep. PCL hasn't yet arranged for this to work for obvious reasons. I believe there is a function in PCL called sub-class-p or subclassp which does what you want. I would check, but that isn't so easy just now. ------- From Owners-commonloops.pa@Xerox.COM Sun Oct 16 23:44:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA19673; Wed, 12 Oct 88 15:32:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 88 15:29:48 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 12 OCT 88 15:28:26 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA02839; Wed, 12 Oct 88 15:25:20 PDT Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0) id AA19790; Wed, 12 Oct 88 15:28:11 PDT Received: from localhost by suntana.sun.com (4.0/SMI-4.0) id AA14730; Wed, 12 Oct 88 15:28:12 PDT Message-Id: <8810122228.AA14730@suntana.sun.com> To: doug@zaphod.prime.com (Douglas Rand) Cc: CommonLoops.PA@Xerox.COM, , Burdorf@zaphod.prime.com, Chris@zaphod.prime.com Subject: Re: PCL benchmark In-Reply-To: Your message of Wed, 12 Oct 88 15:39:31 -0400. <8810121939.AA07463@zaphod.prime.com> Date: Wed, 12 Oct 88 15:28:08 PDT From: kempf@Sun.COM Class creation tends to be on the slow side too. For languages where this happens at load time, there is no problem (except for waiting for loads) but Strobe creates classes on the fly and so it tends to be slow. I don't know how much can be done about this, however, other than general speedup in instance creation and generic function invocation. jak From Gregor.pa@Xerox.COM Mon Oct 17 00:14:28 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA17864; Fri, 14 Oct 88 19:36:12 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 19:28:31 PDT Date: Fri, 14 Oct 88 19:25 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Chris Burdorf Cc: Stan Lanning , Warren Harris , larus@ginger.berkeley.edu, kanderso@PEBBLES.BBN.COM, Douglas Rand , Rob Pettengill , kempf@Sun.COM, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810102208.AA01749@rand.org>, The message of 10 Oct 88 16:57 PDT from Stan Lanning , <11863.592537289@hplwhh>, <8810111647.AA00534@paris.Berkeley.EDU>, <8810111712.AA11214@rand.org>, The message of 12 Oct 88 10:38 PDT from kanderso@PEBBLES.BBN.COM, <8810121939.AA07463@zaphod.prime.com>, <8810121954.AA14555@perseus.sw.mcc.com>, <8810122228.AA14730@suntana.sun.com>, The message of 13 Oct 88 07:55 PDT from kanderso@PEBBLES.BBN.COM, <8810131510.AA16624@suntana.sun.com>, <8810131648.AA17008@rand.org>, <8810132159.AA22984@rand.org>, <8810142022.AA08760@taos.arpa> Message-Id: <19881015022537.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I hope people are getting upset about this, because performance is a BIG issue, especially for simulation. It does make me upset when a user is unhappy about a performance problem they are having. PCL performance is not what it could be, but as you heard at the workshop, there are plans to improve it dramatically by focusing on the implementation specific parts of it. Other implementation efforts, such as TI CLOS, provide encouragement that the result of these efforts will provide quite high performance. Date: Thu, 13 Oct 88 14:59:46 PDT From: Chris Burdorf Ernie 7 seconds Allegro PCL 20 seconds AKCL PCL 30 seconds. Hmm. It runs for me in .4 seconds in Lucid Lisp (SUN 4/110). I wonder what we are doing differently. There are a number issues involved is assessing the performance of any implementation of CLOS. Many of these have been raised in some of the earlier replies to your message. In this message, I will try to address some other issues, and try to summarize what need to be done next. *** Comparing Apples and Oranges *** This is a serious problem when measuring CLOS performance. Danny and I have been saying that it is important to measure "comparable programs". Among other things, we mean is that when re-writing a program from some other language to CLOS, it is important to be sure that the re-written program is as close as possible in functionality to the original. If CLOS doesn't let you get the re-write close, that reflects a problem with CLOS. But its important to try to use CLOS in the way that gets the most correct re-write. Of course this can take a couple of passes since we are all just learning how best to use the language. Taking advantage of the high performance aspects of a language can be deceptive. Stan Lanning has an interesting example of this which I hope he will send out on Monday. Date: Mon, 10 Oct 88 15:07:58 PDT From: Chris Burdorf I just ran a simulation benchmark in PCL. It is a queueing simulation. To get it to run under PCL, I took the simulator from our own object system called ERNIE and converted it into PCL. I then converted the queueing simulation into PCL. The timings I got were as follows: Ernie 4 seconds PCL 30 seconds ERNIE runs under PSL. The version of PCL I have runs under AKCL. There are many possible problems here. Warren Harris mentioned the most prominent one. What is Ernie? In one of your later messages, you said that Ernie does earlier binding than CLOS does. Do you mean that Ernie is a statically typed language? Or does Ernie do "block compiling" by default? Either of these would make it a significantly different language than standard CLOS. Of course it is quite easy to customize CLOS to have these properties, perhaps that should be investigated. Also, what did the code look like in Ernie? Are you sure that when you did the translation you didn't add more "object orientedness" than was there in the first place. One specific question is whether, in Ernie, the accessors are generic. If the KCL port supported structure classes, you could experiment with rewriting this program using defstruct instead of defclass. A very serious issue is the quality of the KCL port of PCL. It is lousy, PCL performance in KCL is worse than in any other Common Lisp I know of. This is my fault, its just that not as much work has been done on the KCL port as on other ports. This shouldn't be too hard to fix. The people at Ibuki have promised to help with this, so there should be some significant improvement on this front soon. Also of importance is the difference between KCL and PSL. For a specific program, two Lisps which are otherwise relatively comparable can differ a lot. If the program happens to stress a place where the two lisps differ, the results can be dramatic. The PCL--KCL, Ernie--PSL relationships are also important. PCL is a portable program, and as I said, the KCL port of PCL is bad. You say that you do not use the PSL system-lisp optimization, but perhaps the implementor of Ernie does use it? When you compiled PCL in KCL did you set safety to 0 and speed to 3? *** Caching Problems *** Date: Tue, 11 Oct 88 09:47:27 PDT From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus) The first bug is that the caches for the discriminator functions have 32 entries. While a fixed-size cache works for some generic functions, it fails miserably for generic functions with more than 32 methods ... Three comments: - Chris' code never gets cache misses, so this is not a problem in his system. - The issue is not whether the generic function has more than 32 methods. Rather it is how many different classes of arguments the generic function is called with. - As Rob Pettengill pointed out we have a much better strategy for dealing with this now, and we expect to have dynamically expanding caches this month. I hope this will make a significant difference in the performance of your program. The second bug is that MAKE-INSTANCE is incredibly expensive. The metaobject hair and parsing property list make for nice, general systems that are too expensive to use in real programs. In fact, I'd argue that the CLOS standard should be rejected on this grounds! Gregor has a workaround that involves using another constructor that can be precompiled. This extension is, however, not part of CLOS and so will not be portable. The metaobject mechanism is not really what causes performance problems in the initialization protocol. Users have wanted extensible initialization protocols in languages which didn't have a metaobject protocol. The initialization protocol is extensible, that can cause performance problems. But these are relatively easy to deal with. Patrick Dussud's implementation and mine both have techniques for solving them. The specific version of the constructor code that will be in the next release is not portable, but it is just an interim version of a mechanism that will be portable. In tests of the new mechanism at PARC, we have seen increases in instance creation performance of up to 100 times. An important point is that Chris' program doesn't call make-instance when it is "running", so that isn't causing him problems. *** Watch Out for Bugs *** I notice in the code you sent me that it prints a lot of messages when the simulator is running. I assume you commented out all these calls to format before you took these measurements, but the times you sent were so much greater than the .4 seconds I measured that I wonder. Certainly something like this could throw the timing off completely. *** Summary *** The following are needed: - more information about Ernie - what your program looked like when it was written in Ernie - make sure PCL was compiled with speed 3 and safety 0. - try a different port of PCL. - improve the port of PCL you have - check on the measurement technique used. Specifically make sure the calls to format were commented out. Each of these will tell us a little about what is going on here. I take your complaint about PCL performance quite seriously, but before things can be improved, we need to know what to improve. ------- From Gregor.pa@Xerox.COM Mon Oct 17 00:46:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.5) id AA06779; Sun, 16 Oct 88 11:59:53 PDT Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 11:56:52 PDT Date: Sun, 16 Oct 88 11:52 PDT From: Gregor.pa@Xerox.COM Subject: Re: generic-function-effective-method? To: kanderso@PEBBLES.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@PEBBLES.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: The message of 12 Oct 88 13:14 PDT from kanderso@PEBBLES.BBN.COM Message-Id: <19881016185239.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Wed, 12 Oct 88 16:14:16 -0400 From: kanderso@PEBBLES.BBN.COM The CLOS MOP doesn't define a function like GENERIC-FUNCTION-EFFECTIVE-METHOD, though i think it would be quite easy to do and fairly useful: Yes, it is useful, your two examples are not uncommon. It is easy enough to write using chapter 3 stuff that we don't provide it all packaged up. Another reason is that sometimes you want the "effective method", and sometimes you want a function you can apply. (defmethod generic-function-effective-method ((gf standard-generic-function) args) (let ((combin (generic-function-method-combination gf)) (methods (compute-applicable-methods gf args))) (compute-effective-method gf combin methods))) PCL avoids doing this at all cost, in fact it tries to combine discrimination and effective method application as tightly as possible. However, a programmer might occasionally use this: EXAMPLE 1: Pull discrimination out of a loop: ;;; Rather than: (dotimes (i 10000) (generic-frob object)) ;;; One could write: (let ((m (generic-function-effective-method generic-frob object))) (dotimes (i 10000) (funcall m object))) ; Hope no one is redefining generic-frob. OK, so ideally where only saving a few instructions, BUT they can add up. In order to do this, you would have to do some other playing around. The "effective method" itself is not a function that can be called. You make it into a function using make-method-function. Then you can call it using apply-method-function. ------- From Owners-commonloops.PA@Xerox.COM Mon Oct 17 07:26:42 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13067; Mon, 17 Oct 88 07:26:42 PDT Received: from Salvador.ms by ArpaGateway.ms ; 17 OCT 88 05:31:20 PDT Return-Path: Redistributed: commonloops.PA Received: from BCLVXA ([26.16.0.176]) by Xerox.COM ; 17 OCT 88 05:30:17 PDT Date: Mon, 17 Oct 88 08:32 EST From: BREED@battelle.arpa Subject: PCL mailing list. To: commonloops.PA@Xerox.COM X-Vms-To: IN%"commonloops@xerox.com" Message-Id: <881017-053120-2225@Xerox> I would like to be removed from the mailing list. Thankyou. From Owners-commonloops.PA@Xerox.COM Mon Oct 17 10:49:06 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA14759; Mon, 17 Oct 88 10:49:06 PDT Received: from Salvador.ms by ArpaGateway.ms ; 17 OCT 88 08:19:40 PDT Return-Path: Redistributed: commonloops.PA Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 17 OCT 88 08:18:48 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.39); Mon, 17 Oct 88 10:18:38 CDT Received: by killdeer.AUSTIN.LOCKHEED.COM (3.2/1.4) for commonloops.PA@xerox.com; Mon, 17 Oct 88 10:17:57 CDT Date: Mon, 17 Oct 88 10:17:57 CDT From: M V Lapolla Message-Id: <8810171517.AA13338@killdeer.AUSTIN.LOCKHEED.COM> To: commonloops.PA@Xerox.COM Subject: Mailing List Please remove me from the list. Thanks. M. From Owners-commonloops.pa@Xerox.COM Mon Oct 17 15:42:11 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20005; Mon, 17 Oct 88 15:42:11 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 17 OCT 88 13:29:52 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 17 OCT 88 13:26:02 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA08617; Mon, 17 Oct 88 16:23:24 EDT Date: Mon, 17 Oct 88 16:23:45 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA08848; Mon, 17 Oct 88 16:23:45 EDT Message-Id: <8810172023.AA08848@turing.cs.rpi.edu> To: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark Cc: commonloops.pa@Xerox.COM Gregor, Could you give me some reasons why PCL performance is bad in KCL? I might be able to help improve KCL if I know where to look. The following two forms allow iwmc-class-p to be expanded inline into code that has no function calls (assuming safety is 0 or 1). This works in both (unaltered) KCL and AKCL. ;in kcl-low (si:define-compiler-macro iwmc-class-p (x) (once-only (x) `(and (si:structurep ,x) (do ((n (si:structure-name ,x))) ((null n) nil) (when (eq n 'iwmc-class-p) return t) (setq n (get n 'si::structure-include)))))) (dolist (inline '((si:structurep ((t) compiler::boolean nil nil "type_of(#0)==t_structure") compiler::inline-always) (si:structure-name ((t) t nil nil "(#0)->str.str_name") compiler::inline-unsafe))) (setf (get (first inline) (third inline)) (list (second inline)))) Rick Harris From Owners-commonloops.PA@Xerox.COM Tue Oct 18 04:29:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01974; Tue, 18 Oct 88 04:29:08 PDT Received: from Salvador.ms by ArpaGateway.ms ; 17 OCT 88 20:02:39 PDT Return-Path: Redistributed: commonloops.PA Received: from cpsvax.cps.msu.edu ([35.8.56.111]) by Xerox.COM ; 17 OCT 88 20:01:09 PDT Received: by cpsvax.cps.msu.edu (1.2/4.2); id AA10405; Mon, 17 Oct 88 23:00:29 edt Date: Mon, 17 Oct 88 23:00:29 edt From: pegah@cpsvax.cps.msu.edu (Mahmoud Pegah) Message-Id: <8810180300.AA10405@cpsvax.cps.msu.edu> To: commonloops.PA@Xerox.COM Subject: Mailing List Cc: pegah@cpsvax.cps.msu.edu Would you please add my name to the mailing list. Thanks. pegah@cpsvax.cps.msu.edu -Mahmoud Pegah AI/KBS Group Computer Science Dept. Mich. State Univ. From Gregor.pa@Xerox.COM Tue Oct 18 04:31:18 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01986; Tue, 18 Oct 88 04:31:18 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 20:29:10 PDT Date: Mon, 17 Oct 88 20:27 PDT From: Gregor.pa@Xerox.COM Subject: but Billy did it To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest Message-Id: <19881018032704.6.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Tim: But Mommy, Billy smeared grease all over HIS sister's new dress. Tim's mother: Just because Billy did it doesn't mean you should, now go to your room. ...and so also does it go in network mailing list land. Just because one person sent a message to the entire list asking to be taken off the list doesn't mean everyone should. If you want off the list, send a message to CommonLoops-Request@Xerox.com. Anybody else who sends a request message to the whole list, goes to their room without dinner. (<<--- joke, ha! laugh) ------- From Owners-commonloops.pa@Xerox.COM Tue Oct 18 04:33:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01992; Tue, 18 Oct 88 04:33:08 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 17:44:10 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.5.1]) by Xerox.COM ; 17 OCT 88 17:41:59 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA08844; Mon, 17 Oct 88 20:39:58 EDT Date: Mon, 17 Oct 88 20:40:21 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA13289; Mon, 17 Oct 88 20:40:21 EDT Message-Id: <8810180040.AA13289@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: PCL benchmark There was an error in my previous message: the line (when (eq n 'iwmc-class-p) return t) in (si:define-compiler-macro iwmc-class-p (x) should be (when (eq n 'iwmc-class) (return t) The remaining thing that must be done so that method lookup and slot access in KCL will not cause unnecessary function calling is to declare some of variables that always have fixnum values. Otherwise, KCL always allocates storage (2 words) each time these variables are bound or set. Rick Harris ;(defvar *pcl-system-date* "8/28/88 (beta rev 1) AAAI PCL ") ;in slots (defmacro get-slot-value-1 (instance wrapper static-slots sxhash slot-name) `(let ((offset (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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 (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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)))))) (defmacro slotd-position (slotd-name slotds) `(let ((slotd-name ,slotd-name)) (do ((pos 0 (+ pos 1)) (slotds ,slotds (cdr slotds))) ((null slotds) nil) (declare (type #-kcl integer #+kcl fixnum pos) (type list slotds)) (and (eq slotd-name (slotd-name (car slotds))) (return pos))))) ;in dcode (define-function-template all-std-class-readers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0) (val nil)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (and (eq (r/w-cache-key) wrapper) (neq (setq val (%svref (iwmc-class-static-slots arg) (r/w-cache-val))) ',*slot-unbound*)) val (with-interrupts (all-std-class-readers-miss arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template all-std-class-writers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (new-value arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. new-value arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (eq (r/w-cache-key) wrapper) (setf (%svref (iwmc-class-static-slots arg) (r/w-cache-val)) new-value) (with-interrupts (all-std-class-writers-miss new-value arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template caching-discriminating-function (required restp specialized-positions cache-size) '(.GENERIC-FUNCTION. .CACHE.) (let* ((nspecialized ;the number of specialized ;arguments (length specialized-positions)) (line-size ;the number of elements in ;a line of the cache (+ nspecialized 1)) (args (gathering ((args (collecting))) (dotimes (i required) (gather (dcode-arg-symbol i) args)))) (wrapper-bindings (gathering ((bindings (collecting))) (dolist (pos specialized-positions) (gather (list (dcode-wrapper-symbol pos) `(wrapper-of-2 ,(nth pos args))) bindings)))) (wrappers (mapcar #'car wrapper-bindings))) `(function (lambda (,@args ,@(and restp '(&rest rest-arg))) (locally (declare (optimize (speed 3) (safety 0) #+lucid (lucid::compilation-speed 0))) (prog ((method-function nil) ,@wrapper-bindings (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (setq offset (cache-key-from-wrappers ,cache-size ,line-size ,@wrappers)) (if (setq method-function (cached-method .cache. offset ,@wrappers)) (return ,(if restp `(apply method-function ,@args rest-arg) `(funcall method-function ,@args))) (progn ;; *** ;; *** Backing cache lookup code goes here. ;; *** (return (caching-dcode-miss .generic-function. .cache. ',cache-size ',specialized-positions ,(and restp 'rest-arg) ,@args)))))))))) ;in vector (defun add-pv-binding (method-body plist required-parameters specializers) (flet ((parameter-class (param) (iterate ((req (list-elements required-parameters)) (spec (list-elements specializers))) (when (eq param req) (return spec))))) (let* ((isl (getf plist :isl)) (n-classes 0) (cache-size (compute-primary-pv-cache-size isl)) (wrapper-var-pool '(w1 w2 w3 w4 w5 w6 w7 w8 w9)) (isl-cache-symbol (make-symbol "isl-cache"))) (nconc plist (list :isl-cache-symbol isl-cache-symbol)) (multiple-value-bind (wrapper-bindings wrapper-vars wrappers-and-parameters eq-tests) (gathering ((bindings (collecting)) (vars (collecting)) (w+p (collecting)) (eqs (collecting))) (iterate ((slots (list-elements isl)) (param (list-elements required-parameters))) (when slots (let ((class (find-class (parameter-class param))) (var (or (pop wrapper-var-pool) (gensym)))) (gather var vars) (gather var w+p) (gather param w+p) (gather `(,var (,(wrapper-fetcher class) ,param)) bindings) (gather `(eq ,var (%svref .cache. ,(make-%+ '.offset. n-classes))) eqs) (incf n-classes))))) `((let ((.isl. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) (.pv. nil)) (setq .pv. (let* ((.cache. (car .isl.)) ,@wrapper-bindings (.offset. (cache-key-from-wrappers ,cache-size ,(1+ n-classes) ,@wrapper-vars))) (declare (type #-kcl integer #+kcl fixnum .offset.)) (if (and ,@eq-tests) (%svref .cache. ,(make-%+ '.offset. n-classes)) (primary-pv-cache-miss .isl. .offset. ,@wrappers-and-parameters)))) .,method-body)))))) From Owners-CommonLoops.PA@Xerox.COM Tue Oct 18 04:35:09 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01998; Tue, 18 Oct 88 04:35:09 PDT Received: from Salvador.ms by ArpaGateway.ms ; 17 OCT 88 11:33:38 PDT Return-Path: Redistributed: CommonLoops.PA Received: from vaxa.isi.edu ([128.9.0.33]) by Xerox.COM ; 17 OCT 88 11:32:20 PDT Posted-Date: Mon, 17 Oct 88 10:31:54 PST Message-Id: <8810171831.AA25006@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA25006; Mon, 17 Oct 88 11:31:57 PDT To: CommonLoops.PA@Xerox.COM Cc: macgreg@vaxa.isi.edu Subject: Is PCL still portable? Date: Mon, 17 Oct 88 10:31:54 PST From: macgreg@vaxa.isi.edu Once upon a time PCL was intended to run on any version of Common Lisp without modification, and ".LOW" files were intended to be optional, used to speed up the implementation. It appears that both the ".LOW" files and "FIN.LISP" have reached a point where one can't run PCL on a new Common Lisp without installing machine- or compiler-specific code. Is this true? If so, is it possible that some compiler-independent code could be added to restore the portability? If not, maybe the start-up documentation could be augmented to indicate how to bring up the portable version. Having a portable version of the PCL code would make it easier to bring PCL up on a new Lisp, and would provide a guide indicating what functionality PCL expects of a compiler, and where optimizations should be made. Right now, the various implementations collectively define an implicit guide, but there appears to be no centralized place in the code indicating what customizations are expected. From Owners-CommonLoops.pa@Xerox.COM Tue Oct 18 07:55:20 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA04483; Tue, 18 Oct 88 07:55:20 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 OCT 88 07:53:06 PDT Return-Path: Redistributed: CommonLoops.pa Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 18 OCT 88 07:52:15 PDT Received: from hpljan.HPL.HP.COM (hpljan.hpl.hp.com) by hplms2.hp.com; Tue, 18 Oct 88 07:51:54 pdt Received: from loopback by hpljan.HPL.HP.COM; Tue, 18 Oct 88 07:51:36 pdt Message-Id: <8810181451.AA02049@hpljan.HPL.HP.COM> To: CommonLoops.pa@Xerox.COM Subject: please discontinue Date: Tue, 18 Oct 88 07:51:31 PDT From: nerbonne%hpljan@hplabs.hp.com Please remove me from your distribution list. Thanks, John nerbonne From Owners-CommonLoops.PA@Xerox.COM Tue Oct 18 10:50:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05579; Tue, 18 Oct 88 10:50:39 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 OCT 88 10:48:26 PDT Return-Path: Redistributed: CommonLoops.PA Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 18 OCT 88 10:45:30 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa06231; 13 Oct 88 17:48 BST Date: Thu, 13 Oct 88 17:50:07 BST Message-Id: <24458.8810131650@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: PCL benchmark To: Stan Lanning , Chris Burdorf In-Reply-To: Stan Lanning's message of 10 Oct 88 16:57 PDT Cc: CommonLoops.PA@Xerox.COM > I think you may be confusing CLOS with PCL (something that we all did at > the workshop, I'm afraid). The discusions at the workshop regarding > performance were about reasonable performance expectations for PCL *in the > (near) future*. These performance expectations in turn are not as good as > "native" implementations (like the TI version) that was also discussed. Is the TI version a complete, working, available system? If so, on which machines? Does it depend on special hardware? Are there any *other* native implementations? On stock hardware? Unfortunately, most people have to base their view of CLOS on PCL because it's the only version for stock hardware they've seen. -- JD From Owners-commonloops.PA@Xerox.COM Tue Oct 18 11:20:49 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA05756; Tue, 18 Oct 88 11:20:49 PDT Received: from Salvador.ms by ArpaGateway.ms ; 18 OCT 88 11:18:41 PDT Return-Path: Redistributed: commonloops.PA Received: from shrike.Austin.Lockheed.COM ([192.31.24.65]) by Xerox.COM ; 18 OCT 88 11:02:28 PDT Received: by shrike.Austin.Lockheed.COM (4.0/1.39); Tue, 18 Oct 88 13:01:12 CDT Received: by killdeer.AUSTIN.LOCKHEED.COM (3.2/1.4) for pegah@cpsvax.cps.msu.edu; Tue, 18 Oct 88 13:01:10 CDT Date: Tue, 18 Oct 88 13:01:10 CDT From: M V Lapolla Message-Id: <8810181801.AA14477@killdeer.AUSTIN.LOCKHEED.COM> To: commonloops.PA@Xerox.COM, pegah@cpsvax.cps.msu.edu Subject: Re: Mailing List From @bbn.com,@WILMA.BBN.COM,@bbn.com,@arisia.xerox.com:Owners-commonloops.PA@xerox.com Tue Oct 18 08:06:11 1988 Redistributed: commonloops.PA To: commonloops.PA@xerox.com Subject: Mailing List Cc: pegah@cpsvax.cps.msu.edu Would you please add my name to the mailing list. Thanks. pegah@cpsvax.cps.msu.edu -Mahmoud Pegah AI/KBS Group Computer Science Dept. Mich. State Univ. WAIT A SECOND. I THINK THAT PEOPLE WHO ASK TO BE INCLUDED ON THE LIST SHOULD BE SENT TO THEIR ROOMS WITHOUT DINNER, TOO! ;-) <- Billy. (Kidding.) From Gregor.pa@Xerox.COM Tue Oct 18 13:30:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA07078; Tue, 18 Oct 88 13:30:40 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 13:25:01 PDT Date: Tue, 18 Oct 88 13:21 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Jeff Dalton Cc: Stan Lanning , Chris Burdorf , CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <24458.8810131650@subnode.aiai.ed.ac.uk> Message-Id: <19881018202159.1.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Thu, 13 Oct 88 17:50:07 BST From: Jeff Dalton Is the TI version a complete, working, available system? If so, on which machines? Does it depend on special hardware? Are there any *other* native implementations? On stock hardware? I can't speak for availability of the TI implementation. What I know of it technically is that it looks real good, and has good performance. It depends on microcode of their chip to run, so in some sense it is a custom implementation. On the other hand, the basic architecture is portable, it shares many ideas with PCL. We are at a stage where many vendors have agreed to help in the porting of PCL. The PCL architecture can support a much higher level of performance, this just requires digging into the underlying lisp a little more. In the next few months, I expect PCL performance will increase pretty dramatically. I expect most vendors will use this highly optimized PCL for a while (1 or 2 releases) and then will begin more agressive custom implementation efforts. Some vendors will begin these sooner than others of course, as we have seen TI has already done one. Unfortunately, most people have to base their view of CLOS on PCL because it's the only version for stock hardware they've seen. This isn't all that unfortunate, as I have said PCL performance can be improved dramatically with a modest amount of effort. What is unfortunate is that people assume that the PCL performance they get in one Common Lisp is the same as the PCL performance they would get in all Common Lisps. This just isn't true. ------- From Owners-CommonLoops.PA@Xerox.COM Tue Oct 18 20:13:29 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10389; Tue, 18 Oct 88 20:13:29 PDT Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 19:30:13 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 18 OCT 88 19:27:37 PDT Received: from localhost by rand.org; Tue, 18 Oct 88 18:47:37 PDT Message-Id: <8810190147.AA12717@rand.org> To: Gregor.pa@Xerox.COM Cc: Chris Burdorf , Stan Lanning , Warren Harris , larus@ginger.berkeley.edu, kanderso@pebbles.bbn.com, Douglas Rand , Rob Pettengill , kempf@sun.com, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM, steph%ixta@rand.org, jeff%venus@rand.org, Bruce_Florman Subject: Re: PCL benchmark In-Reply-To: Your message of Fri, 14 Oct 88 19:25:00 PDT. <19881015022537.6.GREGOR@PORTNOY.parc.xerox.com> Date: Tue, 18 Oct 88 18:46:56 PDT From: Chris Burdorf Ok, I got rid of the formats and compiled with safety set to 0 and speed at 3. I got the following times: AKCL 20 cars real time : 8.550 secs run time : 8.483 secs ---------------------- 50 cars real time : 28.133 secs run time : 26.300 secs Allegro ----------- 20 cars cpu time (non-gc) 1984 msec user, 0 msec system cpu time (gc) 0 msec user, 0 msec system cpu time (total) 1984 msec user, 0 msec system real time 2020 msec 50 cars cpu time (non-gc) 5300 msec user, 67 msec system cpu time (gc) 967 msec user, 0 msec system cpu time (total) real time 6340 msec ERNIE ----------- 20 cars --- 1.0003 50 cars --- 2.686 I ran them on a sun 3/60. I couldn't compile pcl under allegro with safety at 0 and speed at 3, but I could compile the simulation. It's clear that PCL is faster under some Common LISP's than others. I did 50 cars, because the numbers with 20 were too low. Note with 50 cars, ERNIE is 10 times faster than AKCL PCL. It's also close to 2.5 times faster than ALLEGRO PCL. I can't tell you much about ERNIE, because it is funded by DOD and I don't want to get tried for treason. It's basically a reimplemtation of FLAVORS. It has practically everything Flavors has, but it was designed especially to be fast. I double checked my ERNIE code and it looks to do the same things as my PCL code. You'll have to take my word for it. I can't send you the code. I wouldn't say that comparing ERNIE and PCL is like comparing APPLES and ORANGES, but rather TANGERINES and ORANGES. ORANGES are bigger, but they take longer to eat. My main reason for sending out this comparison of ERNIE and PCL was not to try and convert people to ERNIE, but to try to stir a dialog on efficiency. Hopefully PCL will be fast for all of us: rich or poor. Chris From Owners-CommonLoops.PA@Xerox.COM Tue Oct 18 20:24:10 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10505; Tue, 18 Oct 88 20:24:10 PDT Received: from Burger.ms by ArpaGateway.ms ; 18 OCT 88 20:18:40 PDT Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 18 OCT 88 19:49:10 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 18 Oct 88 19:48:33 pdt Received: from loopback by hplwhh.HPL.HP.COM; Tue, 18 Oct 88 19:47:57 pdt To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of "Tue, 18 Oct 88 18:46:56 PDT." <8810190147.AA12717@rand.org> Date: Tue, 18 Oct 88 19:47:53 PDT Message-Id: <20982.593232473@hplwhh> From: Warren Harris > It has practically everything Flavors has, but it was > designed especially to be fast. Sounds like a contradiction to me. You have to think of the things PCL is buying you that you're not taking into account in the simulation time. For one, can you dynamically add methods to a class/generic-function in ERNIE, or is there a class-redefinition protocol to help you at development time? All these things contribute levels of indirection and consequently speed degradation at runtime, but with the benefit of enhancing functionality simplifying development. The trick is for the PCL system to eliminate levels of indirection with appropriate declarations and/or smarts. This will come with time, but of course you must realize that it can never come as close to the speed of a system like ERNIE which was designed under certain simplifying assumptions. I'd say it sounds like you're comparing ORANGES to COPPER-TUBING or something. Have you tried C for speed? From Owners-CommonLoops.pa@Xerox.COM Tue Oct 18 21:47:36 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12395; Tue, 18 Oct 88 21:47:36 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 18 OCT 88 21:40:29 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 18 OCT 88 21:38:08 PDT Received: from fafnir.think.com by Think.COM; Wed, 19 Oct 88 00:40:18 EDT Return-Path: Received: from sauron.think.com by fafnir.think.com; Tue, 18 Oct 88 20:19:05 EDT Received: from POLYCARP.THINK.COM by sauron.think.com; Tue, 18 Oct 88 20:19:03 EDT Date: Tue, 18 Oct 88 20:19 EDT From: Jim Salem Subject: I like to use method combination To: common-loops@Think.COM Message-Id: <19881019001939.2.SALEM@POLYCARP.THINK.COM> PCL doesn't currently support CLOS's method combination. However, I'd like to use another method combination type besides the standard one. Questions : - Will PCL support method combination anytime soon ? When ? - Has anyone tried to implement this in PCL already ? Since those are probably both NO, I'm willing to dive in and try to implement it but I'd like a little info/help. My strategy is to add a method-combination slot to the standard-generic-function class (in defs.lisp) and then modify the appropriate function(s) in combin.lisp to generate the appropriate code. A cursory reading of combin.lisp suggests the only function I need modify is COMPUTE-EFFECTIVE-METHOD-BODY. Is this reasonable ? What is likely to lose ? [Of course if this wins, there will be free code for all. :-)] Thanks, jim From Owners-commonloops.pa@Xerox.COM Wed Oct 19 05:32:57 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA17522; Wed, 19 Oct 88 05:32:57 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 05:30:40 PDT Return-Path: Redistributed: commonloops.pa Received: from G.BBN.COM ([192.1.2.67]) by Xerox.COM ; 19 OCT 88 05:29:26 PDT Date: Wed, 19 Oct 88 08:30:09 EDT From: R. Shapiro Subject: method combination To: salem@THINK.COM Cc: commonloops.pa@Xerox.COM Message-Id: <881019-053040-6356@Xerox> I have an implementation of DEFINE-METHOD-COMBINATION (short & long form) and definitions for most of the combinations built in to Flavors. With a small amount of legal work, I can give this out. It's only been tested on Symbolics but I believe it's all in pure portable CommonLisp. Richard Shapiro/RSHAPIRO@BBN.COM ------- From Owners-CommonLoops.pa@Xerox.COM Wed Oct 19 06:48:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18439; Wed, 19 Oct 88 06:48:15 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 06:46:01 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 19 OCT 88 06:44:25 PDT Received: from fafnir.think.com by Think.COM; Wed, 19 Oct 88 09:44:58 EDT Received: from Think.COM by fafnir.think.com; Wed, 19 Oct 88 09:42:42 EDT Return-Path: Received: from PEBBLES.BBN.COM by Think.COM; Wed, 19 Oct 88 09:44:40 EDT Message-Id: <8810191344.AA02490@Think.COM> To: Jim Salem Cc: common-loops@Think.COM Subject: Re: I like to use method combination In-Reply-To: Your message of Tue, 18 Oct 88 20:19:00 -0400. <19881019001939.2.SALEM@POLYCARP.THINK.COM> Date: Wed, 19 Oct 88 09:42:06 -0400 From: kanderso@pebbles.bbn.com Date: Tue, 18 Oct 88 20:19 EDT From: Jim Salem Subject: I like to use method combination To: common-loops@think.com Message-Id: <19881019001939.2.SALEM@POLYCARP.THINK.COM> PCL doesn't currently support CLOS's method combination. However, I'd like to use another method combination type besides the standard one. Questions : - Will PCL support method combination anytime soon ? When ? Well, this is something planned, but we seem to be concentrating on performance. - Has anyone tried to implement this in PCL already ? Yes, we have one which we are trying to make available. We expected PCL to have this so we didn't push it too hard. But, everything seems to take longer than we expect.... Since those are probably both NO, I'm willing to dive in and try to implement it but I'd like a little info/help. My strategy is to add a method-combination slot to the standard-generic-function class (in defs.lisp) and then modify the appropriate function(s) in combin.lisp to generate the appropriate code. Yes, our approach was to just use a slot that wasn't currently use. A cursory reading of combin.lisp suggests the only function I need modify is COMPUTE-EFFECTIVE-METHOD-BODY. Is this reasonable ? What is likely to lose ? [Of course if this wins, there will be free code for all. :-)] Yes, basically, but you must also provide defgeneric and the method combination defining macros. Thanks, jim From Lanning.pa@Xerox.COM Wed Oct 19 09:38:26 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00168; Wed, 19 Oct 88 09:38:26 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 OCT 88 08:14:23 PDT Date: 19 Oct 88 08:11 PDT From: Stan Lanning Subject: Re: PCL benchmark In-Reply-To: Jeff Dalton 's message of Thu, 13 Oct 88 17:50:07 BST To: Jeff Dalton Cc: Stan Lanning , Chris Burdorf , CommonLoops.PA@Xerox.COM Message-Id: <881019-081423-6567@Xerox> I raised the point about CLOS v PCL because the original note slammed CLOS, not PCL. The CLOS committee went to great pains to make sure that CLOS was *effeciently* implementable, even on stock hardware. From what I have heard, they succeeded. My worry is that CLOS may get an undeserved bad reputation, based on stories that start out "CLOS is *slow*; I ran this test in PCL and...". In fact, even giving PCL a bad rep is undeserved. To complain that the current version (or worse, some past version) is slow compared to some more mature code is unfair. Might as well complain that it isn't much good at generating reports, esp. compared to COBOL. So let's remember: PCL is not CLOS, and PCL is not anywhere near done. ----- smL e wrapper static-slots sxhash slot-name) `(let ((offset (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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 (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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)))))) (defmacro slotd-position (slotd-name slotds) `(let ((slotd-name ,slotd-name)) (do ((pos 0 (+ pos 1)) (slotds ,slotds (cdr slotds))) ((null slotds) nil) (declare (type #-kcl integer #+kcl fixnum pos) (type list slotds)) (and (eq slotd-name (slotd-name (car slotds))) (return pos))))) ;in dcode (define-function-template all-std-class-readers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0) (val nil)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (and (eq (r/w-cache-key) wrapper) (neq (setq val (%svref (iwmc-class-static-slots arg) (r/w-cache-val))) ',*slot-unbound*)) val (with-interrupts (all-std-class-readers-miss arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template all-std-class-writers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (new-value arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. new-value arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (eq (r/w-cache-key) wrapper) (setf (%svref (iwmc-class-static-slots arg) (r/w-cache-val)) new-value) (with-interrupts (all-std-class-writers-miss new-value arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template caching-discriminating-function (required restp specialized-positions cache-size) '(.GENERIC-FUNCTION. .CACHE.) (let* ((nspecialized ;the number of specialized ;arguments (length specialized-positions)) (line-size ;the number of elements in ;a line of the cache (+ nspecialized 1)) (args (gathering ((args (collecting))) (dotimes (i required) (gather (dcode-arg-symbol i) args)))) (wrapper-bindings (gathering ((bindings (collecting))) (dolist (pos specialized-positions) (gather (list (dcode-wrapper-symbol pos) `(wrapper-of-2 ,(nth pos args))) bindings)))) (wrappers (mapcar #'car wrapper-bindings))) `(function (lambda (,@args ,@(and restp '(&rest rest-arg))) (locally (declare (optimize (speed 3) (safety 0) #+lucid (lucid::compilation-speed 0))) (prog ((method-function nil) ,@wrapper-bindings (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (setq offset (cache-key-from-wrappers ,cache-size ,line-size ,@wrappers)) (if (setq method-function (cached-method .cache. offset ,@wrappers)) (return ,(if restp `(apply method-function ,@args rest-arg) `(funcall method-function ,@args))) (progn ;; *** ;; *** Backing cache lookup code goes here. ;; *** (return (caching-dcode-miss .generic-function. .cache. ',cache-size ',specialized-positions ,(and restp 'rest-arg) ,@args)))))))))) ;in vector (defun add-pv-binding (method-body plist required-parameters specializers) (flet ((parameter-class (param) (iterate ((req (list-elements required-parameters)) (spec (list-elements specializers))) (when (eq param req) (return spec))))) (let* ((isl (getf plist :isl)) (n-classes 0) (cache-size (compute-primary-pv-cache-size isl)) (wrapper-var-pool '(w1 w2 w3 w4 w5 w6 w7 w8 w9)) (isl-cache-symbol (make-symbol "isl-cache"))) (nconc plist (list :isl-cache-symbol isl-cache-symbol)) (multiple-value-bind (wrapper-bindings wrapper-vars wrappers-and-parameters eq-tests) (gathering ((bindings (collecting)) (vars (collecting)) (w+p (collecting)) (eqs (collecting))) (iterate ((slots (list-elements isl)) (param (list-elements required-parameters))) (when slots (let ((class (find-class (parameter-class param))) (var (or (pop wrapper-var-pool) (gensym)))) (gather var vars) (gather var w+p) (gather param w+p) (gather `(,var (,(wrapper-fetcher class) ,param)) bindings) (gather `(eq ,var (%svref .cache. ,(make-%+ '.offset. n-classes))) eqs) (incf n-classes))))) `((let ((.isl. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) (.pv. nil)) (setq .pv. (let* ((.cache. (car .isl.)) ,@wrapper-bindings (.offset. (cache-key-from-wrappers ,cache-size ,(1+ n-classes) ,@wrapper-vars))) (declare (type #-kcl integer #+kcl fixnum .offset.)) (if (and ,@eq-tests) (%svref .cache. ,(make-%+ '.offset. n-classes)) (primary-pv-cache-miss .isl. .offset. ,@wrappers-and-parameters)))) .,method-body)))))) From Gregor.pa@Xerox.COM Wed Oct 19 09:59:57 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00721; Wed, 19 Oct 88 09:59:57 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 OCT 88 09:52:15 PDT Date: Wed, 19 Oct 88 09:49 PDT From: Gregor.pa@Xerox.COM Subject: Re: I like to use method combination To: Jim Salem Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <19881019001939.2.SALEM@POLYCARP.THINK.COM> Message-Id: <19881019164934.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 18 Oct 88 20:19 EDT From: Jim Salem PCL doesn't currently support CLOS's method combination. However, I'd like to use another method combination type besides the standard one. Questions : - Will PCL support method combination anytime soon ? When ? - Has anyone tried to implement this in PCL already ? I have the largest part of one implemented and tested. It mostly just needs to be connected to the rest of the code. I believe it is in the file combin. I can't say now when that will happen, but it will be in the next two months since the metaobject protocol "reimplimentation" needs OR and PROGN combination. ------- From Owners-CommonLoops.PA@Xerox.COM Wed Oct 19 10:31:05 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10505; Tue, 18 Oct 88 20:24:10 PDT Received: from Burger.ms by ArpaGateway.ms ; 18 OCT 88 20:18:40 PDT Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 18 OCT 88 19:49:10 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 18 Oct 88 19:48:33 pdt Received: from loopback by hplwhh.HPL.HP.COM; Tue, 18 Oct 88 19:47:57 pdt To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of "Tue, 18 Oct 88 18:46:56 PDT." <8810190147.AA12717@rand.org> Date: Tue, 18 Oct 88 19:47:53 PDT Message-Id: <20982.593232473@hplwhh> From: Warren Harris > It has practically everything Flavors has, but it was > designed especially to be fast. Sounds like a contradiction to me. You have to think of the things PCL is buying you that you're not taking into account in the simulation time. For one, can you dynamically add methods to a class/generic-function in ERNIE, or is there a class-redefinition protocol to help you at development time? All these things contribute levels of indirection and consequently speed degradation at runtime, but with the benefit of enhancing functionality simplifying development. The trick is for the PCL system to eliminate levels of indirection with appropriate declarations and/or smarts. This will come with time, but of course you must realize that it can never come as close to the speed of a system like ERNIE which was designed under certain simplifying assumptions. I'd say it sounds like you're comparing ORANGES to COPPER-TUBING or something. Have you tried C for speed? From Owners-CommonLoops.pa@Xerox.COM Wed Oct 19 11:24:57 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18439; Wed, 19 Oct 88 06:48:15 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 06:46:01 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 19 OCT 88 06:44:25 PDT Received: from fafnir.think.com by Think.COM; Wed, 19 Oct 88 09:44:58 EDT Received: from Think.COM by fafnir.think.com; Wed, 19 Oct 88 09:42:42 EDT Return-Path: Received: from PEBBLES.BBN.COM by Think.COM; Wed, 19 Oct 88 09:44:40 EDT Message-Id: <8810191344.AA02490@Think.COM> To: Jim Salem Cc: common-loops@Think.COM Subject: Re: I like to use method combination In-Reply-To: Your message of Tue, 18 Oct 88 20:19:00 -0400. <19881019001939.2.SALEM@POLYCARP.THINK.COM> Date: Wed, 19 Oct 88 09:42:06 -0400 From: kanderso@pebbles.bbn.com Date: Tue, 18 Oct 88 20:19 EDT From: Jim Salem Subject: I like to use method combination To: common-loops@think.com Message-Id: <19881019001939.2.SALEM@POLYCARP.THINK.COM> PCL doesn't currently support CLOS's method combination. However, I'd like to use another method combination type besides the standard one. Questions : - Will PCL support method combination anytime soon ? When ? Well, this is something planned, but we seem to be concentrating on performance. - Has anyone tried to implement this in PCL already ? Yes, we have one which we are trying to make available. We expected PCL to have this so we didn't push it too hard. But, everything seems to take longer than we expect.... Since those are probably both NO, I'm willing to dive in and try to implement it but I'd like a little info/help. My strategy is to add a method-combination slot to the standard-generic-function class (in defs.lisp) and then modify the appropriate function(s) in combin.lisp to generate the appropriate code. Yes, our approach was to just use a slot that wasn't currently use. A cursory reading of combin.lisp suggests the only function I need modify is COMPUTE-EFFECTIVE-METHOD-BODY. Is this reasonable ? What is likely to lose ? [Of course if this wins, there will be free code for all. :-)] Yes, basically, but you must also provide defgeneric and the method combination defining macros. Thanks, jim From Gregor.pa@Xerox.COM Wed Oct 19 11:44:33 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01525; Wed, 19 Oct 88 11:44:33 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 OCT 88 11:06:51 PDT Date: Wed, 19 Oct 88 11:02 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Chris Burdorf Cc: Stan Lanning , Warren Harris , larus@ginger.berkeley.edu, kanderso@pebbles.bbn.com, Douglas Rand , Rob Pettengill , kempf@sun.com, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM, steph%ixta@rand.org, jeff%venus@rand.org, Bruce_Florman Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810190147.AA12717@rand.org> Message-Id: <19881019180246.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 18 Oct 88 18:46:56 PDT From: Chris Burdorf I got rid of the formats and compiled with safety set to 0 and speed at 3. I got the following times: Gathering these times into one table we get: 20 cars 50 cars ERNIE 1.000 2.686 PCL in AKCL 8.483 (x8) 26.300 (x10) (speed 3, safety 0) PCL in Allegro 2.020 (x2) 6.340 (x2.4) (default compiler settings) In these numbers, the PCL version of your program takes from 202% to 979% the time of the Ernie version. Judging from these numbers, I would say that you should start writing the rest of your code in CLOS. If the program you sent is an accurate measure of what your programs really do, CLOS is going to do better for you than Ernie. Why do I say this: - You claim that Ernie is finely tuned for performance. I believe you. I claim that PCL is not operating anywhere near its "theoretical" performance. Believe me. - The best compilation you were able to give PCL in Allegro was with default compiler settings. I am not sure, but I think this has a significant negative effect. I will look into this. I would also be interested in knowing why you couldn't compiler it with speed 3 and safety 0, this is a bug which should be fixed. - From looking at your program, I believe it depends more than anything else on the performance of reader generic functions (those generic functions which have automatically defined reader methods on them). Those will go considerably faster in more tuned versions of PCL. In your Franz version, they will probably be 2 - 3 times faster. In your KCL version they may be as much as 7 - 8 times faster. - The next most critical number for your program is generic function call overhead. In more tuned ports of PCL this will improve the same way that reader generic functions will (2 - 3 times in Allegro, 7 - 8 times in KCL). I can't tell you much about ERNIE, because it is funded by DOD and I don't want to get tried for treason. It's basically a reimplemtation of FLAVORS. It has practically everything Flavors has, but it was designed especially to be fast. This does and doesn't make sense to me. Does: The Ernie performance numbers don't look all that good, they seem to be what one would expect from flavors. Doesn't: If I were designing something with efficiency as my single I wouldn't start from Flavors. If efficiency were not my my single goal, I would start with CLOS. CLOS has the go good ideas from Flavors (and other languages as well) and has been carefully designed to allow efficient implementation. Another point is that CLOS, with its metaobject protocol, can allow more efficient user controlled, "staticizing" or "block compilation". My main reason for sending out this comparison of ERNIE and PCL was not to try and convert people to ERNIE, but to try to stir a dialog on efficiency. Hopefully PCL will be fast for all of us: rich or poor. Yes, this is an important dialog. As for your cost concern, I believe PCL will run well in KCL as well as in more expensive lisps. ------- From Owners-commonloops.pa@Xerox.COM Wed Oct 19 13:06:03 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01992; Tue, 18 Oct 88 04:33:08 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 17:44:10 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.5.1]) by Xerox.COM ; 17 OCT 88 17:41:59 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA08844; Mon, 17 Oct 88 20:39:58 EDT Date: Mon, 17 Oct 88 20:40:21 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA13289; Mon, 17 Oct 88 20:40:21 EDT Message-Id: <8810180040.AA13289@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: PCL benchmark There was an error in my previous message: the line (when (eq n 'iwmc-class-p) return t) in (si:define-compiler-macro iwmc-class-p (x) should be (when (eq n 'iwmc-class) (return t) The remaining thing that must be done so that method lookup and slot access in KCL will not cause unnecessary function calling is to declare some of variables that always have fixnum values. Otherwise, KCL always allocates storage (2 words) each time these variables are bound or set. Rick Harris ;(defvar *pcl-system-date* "8/28/88 (beta rev 1) AAAI PCL ") ;in slots (defmacro get-slot-value-1 (instance wrapper static-slots sxhash slot-name) `(let ((offset (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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 (%logand slot-value-cache-mask (%logxor (validate-wrapper ,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)))))) (defmacro slotd-position (slotd-name slotds) `(let ((slotd-name ,slotd-name)) (do ((pos 0 (+ pos 1)) (slotds ,slotds (cdr slotds))) ((null slotds) nil) (declare (type #-kcl integer #+kcl fixnum pos) (type list slotds)) (and (eq slotd-name (slotd-name (car slotds))) (return pos))))) ;in dcode (define-function-template all-std-class-readers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0) (val nil)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (and (eq (r/w-cache-key) wrapper) (neq (setq val (%svref (iwmc-class-static-slots arg) (r/w-cache-val))) ',*slot-unbound*)) val (with-interrupts (all-std-class-readers-miss arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template all-std-class-writers-dcode () '(.GENERIC-FUNCTION. .CACHE.) (let () `(function (lambda (new-value arg) (locally (declare (optimize (speed 3) (safety 0))) (let* ((wrapper (and (iwmc-class-p arg) (iwmc-class-class-wrapper arg))) (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (if (null wrapper) (no-applicable-method .GENERIC-FUNCTION. new-value arg) (progn (setq offset (cache-key-from-wrappers ,generic-function-cache-size 2 wrapper)) (without-interrupts (if (eq (r/w-cache-key) wrapper) (setf (%svref (iwmc-class-static-slots arg) (r/w-cache-val)) new-value) (with-interrupts (all-std-class-writers-miss new-value arg wrapper .cache. ,generic-function-cache-size offset .generic-function.)))))))))))) (define-function-template caching-discriminating-function (required restp specialized-positions cache-size) '(.GENERIC-FUNCTION. .CACHE.) (let* ((nspecialized ;the number of specialized ;arguments (length specialized-positions)) (line-size ;the number of elements in ;a line of the cache (+ nspecialized 1)) (args (gathering ((args (collecting))) (dotimes (i required) (gather (dcode-arg-symbol i) args)))) (wrapper-bindings (gathering ((bindings (collecting))) (dolist (pos specialized-positions) (gather (list (dcode-wrapper-symbol pos) `(wrapper-of-2 ,(nth pos args))) bindings)))) (wrappers (mapcar #'car wrapper-bindings))) `(function (lambda (,@args ,@(and restp '(&rest rest-arg))) (locally (declare (optimize (speed 3) (safety 0) #+lucid (lucid::compilation-speed 0))) (prog ((method-function nil) ,@wrapper-bindings (offset 0)) (declare (type #-kcl integer #+kcl fixnum offset)) (setq offset (cache-key-from-wrappers ,cache-size ,line-size ,@wrappers)) (if (setq method-function (cached-method .cache. offset ,@wrappers)) (return ,(if restp `(apply method-function ,@args rest-arg) `(funcall method-function ,@args))) (progn ;; *** ;; *** Backing cache lookup code goes here. ;; *** (return (caching-dcode-miss .generic-function. .cache. ',cache-size ',specialized-positions ,(and restp 'rest-arg) ,@args)))))))))) ;in vector (defun add-pv-binding (method-body plist required-parameters specializers) (flet ((parameter-class (param) (iterate ((req (list-elements required-parameters)) (spec (list-elements specializers))) (when (eq param req) (return spec))))) (let* ((isl (getf plist :isl)) (n-classes 0) (cache-size (compute-primary-pv-cache-size isl)) (wrapper-var-pool '(w1 w2 w3 w4 w5 w6 w7 w8 w9)) (isl-cache-symbol (make-symbol "isl-cache"))) (nconc plist (list :isl-cache-symbol isl-cache-symbol)) (multiple-value-bind (wrapper-bindings wrapper-vars wrappers-and-parameters eq-tests) (gathering ((bindings (collecting)) (vars (collecting)) (w+p (collecting)) (eqs (collecting))) (iterate ((slots (list-elements isl)) (param (list-elements required-parameters))) (when slots (let ((class (find-class (parameter-class param))) (var (or (pop wrapper-var-pool) (gensym)))) (gather var vars) (gather var w+p) (gather param w+p) (gather `(,var (,(wrapper-fetcher class) ,param)) bindings) (gather `(eq ,var (%svref .cache. ,(make-%+ '.offset. n-classes))) eqs) (incf n-classes))))) `((let ((.isl. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) (.pv. nil)) (setq .pv. (let* ((.cache. (car .isl.)) ,@wrapper-bindings (.offset. (cache-key-from-wrappers ,cache-size ,(1+ n-classes) ,@wrapper-vars))) (declare (type #-kcl integer #+kcl fixnum .offset.)) (if (and ,@eq-tests) (%svref .cache. ,(make-%+ '.offset. n-classes)) (primary-pv-cache-miss .isl. .offset. ,@wrappers-and-parameters)))) .,method-body)))))) From Owners-CommonLoops.PA@Xerox.COM Wed Oct 19 13:36:03 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10505; Tue, 18 Oct 88 20:24:10 PDT Received: from Burger.ms by ArpaGateway.ms ; 18 OCT 88 20:18:40 PDT Return-Path: Redistributed: CommonLoops.PA Received: from hplms2.hpl.hp.com ([15.255.16.26]) by Xerox.COM ; 18 OCT 88 19:49:10 PDT Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 18 Oct 88 19:48:33 pdt Received: from loopback by hplwhh.HPL.HP.COM; Tue, 18 Oct 88 19:47:57 pdt To: Chris Burdorf Cc: CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of "Tue, 18 Oct 88 18:46:56 PDT." <8810190147.AA12717@rand.org> Date: Tue, 18 Oct 88 19:47:53 PDT Message-Id: <20982.593232473@hplwhh> From: Warren Harris > It has practically everything Flavors has, but it was > designed especially to be fast. Sounds like a contradiction to me. You have to think of the things PCL is buying you that you're not taking into account in the simulation time. For one, can you dynamically add methods to a class/generic-function in ERNIE, or is there a class-redefinition protocol to help you at development time? All these things contribute levels of indirection and consequently speed degradation at runtime, but with the benefit of enhancing functionality simplifying development. The trick is for the PCL system to eliminate levels of indirection with appropriate declarations and/or smarts. This will come with time, but of course you must realize that it can never come as close to the speed of a system like ERNIE which was designed under certain simplifying assumptions. I'd say it sounds like you're comparing ORANGES to COPPER-TUBING or something. Have you tried C for speed? From Owners-CommonLoops.pa@Xerox.COM Wed Oct 19 14:06:15 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA18439; Wed, 19 Oct 88 06:48:15 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 06:46:01 PDT Return-Path: Redistributed: CommonLoops.pa Received: from Think.COM ([10.4.0.6]) by Xerox.COM ; 19 OCT 88 06:44:25 PDT Received: from fafnir.think.com by Think.COM; Wed, 19 Oct 88 09:44:58 EDT Received: from Think.COM by fafnir.think.com; Wed, 19 Oct 88 09:42:42 EDT Return-Path: Received: from PEBBLES.BBN.COM by Think.COM; Wed, 19 Oct 88 09:44:40 EDT Message-Id: <8810191344.AA02490@Think.COM> To: Jim Salem Cc: common-loops@Think.COM Subject: Re: I like to use method combination In-Reply-To: Your message of Tue, 18 Oct 88 20:19:00 -0400. <19881019001939.2.SALEM@POLYCARP.THINK.COM> Date: Wed, 19 Oct 88 09:42:06 -0400 From: kanderso@pebbles.bbn.com Date: Tue, 18 Oct 88 20:19 EDT From: Jim Salem Subject: I like to use method combination To: common-loops@think.com Message-Id: <19881019001939.2.SALEM@POLYCARP.THINK.COM> PCL doesn't currently support CLOS's method combination. However, I'd like to use another method combination type besides the standard one. Questions : - Will PCL support method combination anytime soon ? When ? Well, this is something planned, but we seem to be concentrating on performance. - Has anyone tried to implement this in PCL already ? Yes, we have one which we are trying to make available. We expected PCL to have this so we didn't push it too hard. But, everything seems to take longer than we expect.... Since those are probably both NO, I'm willing to dive in and try to implement it but I'd like a little info/help. My strategy is to add a method-combination slot to the standard-generic-function class (in defs.lisp) and then modify the appropriate function(s) in combin.lisp to generate the appropriate code. Yes, our approach was to just use a slot that wasn't currently use. A cursory reading of combin.lisp suggests the only function I need modify is COMPUTE-EFFECTIVE-METHOD-BODY. Is this reasonable ? What is likely to lose ? [Of course if this wins, there will be free code for all. :-)] Yes, basically, but you must also provide defgeneric and the method combination defining macros. Thanks, jim From Gregor.pa@Xerox.COM Wed Oct 19 14:55:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA01525; Wed, 19 Oct 88 11:44:33 PDT Received: from Semillon.ms by ArpaGateway.ms ; 19 OCT 88 11:06:51 PDT Date: Wed, 19 Oct 88 11:02 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL benchmark To: Chris Burdorf Cc: Stan Lanning , Warren Harris , larus@ginger.berkeley.edu, kanderso@pebbles.bbn.com, Douglas Rand , Rob Pettengill , kempf@sun.com, susan@lucid.com, ajcole@ai.leeds.ac.uk, Chris@zaphod.prime.com, CommonLoops.PA@Xerox.COM, steph%ixta@rand.org, jeff%venus@rand.org, Bruce_Florman Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <8810190147.AA12717@rand.org> Message-Id: <19881019180246.3.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Tue, 18 Oct 88 18:46:56 PDT From: Chris Burdorf I got rid of the formats and compiled with safety set to 0 and speed at 3. I got the following times: Gathering these times into one table we get: 20 cars 50 cars ERNIE 1.000 2.686 PCL in AKCL 8.483 (x8) 26.300 (x10) (speed 3, safety 0) PCL in Allegro 2.020 (x2) 6.340 (x2.4) (default compiler settings) In these numbers, the PCL version of your program takes from 202% to 979% the time of the Ernie version. Judging from these numbers, I would say that you should start writing the rest of your code in CLOS. If the program you sent is an accurate measure of what your programs really do, CLOS is going to do better for you than Ernie. Why do I say this: - You claim that Ernie is finely tuned for performance. I believe you. I claim that PCL is not operating anywhere near its "theoretical" performance. Believe me. - The best compilation you were able to give PCL in Allegro was with default compiler settings. I am not sure, but I think this has a significant negative effect. I will look into this. I would also be interested in knowing why you couldn't compiler it with speed 3 and safety 0, this is a bug which should be fixed. - From looking at your program, I believe it depends more than anything else on the performance of reader generic functions (those generic functions which have automatically defined reader methods on them). Those will go considerably faster in more tuned versions of PCL. In your Franz version, they will probably be 2 - 3 times faster. In your KCL version they may be as much as 7 - 8 times faster. - The next most critical number for your program is generic function call overhead. In more tuned ports of PCL this will improve the same way that reader generic functions will (2 - 3 times in Allegro, 7 - 8 times in KCL). I can't tell you much about ERNIE, because it is funded by DOD and I don't want to get tried for treason. It's basically a reimplemtation of FLAVORS. It has practically everything Flavors has, but it was designed especially to be fast. This does and doesn't make sense to me. Does: The Ernie performance numbers don't look all that good, they seem to be what one would expect from flavors. Doesn't: If I were designing something with efficiency as my single I wouldn't start from Flavors. If efficiency were not my my single goal, I would start with CLOS. CLOS has the go good ideas from Flavors (and other languages as well) and has been carefully designed to allow efficient implementation. Another point is that CLOS, with its metaobject protocol, can allow more efficient user controlled, "staticizing" or "block compilation". My main reason for sending out this comparison of ERNIE and PCL was not to try and convert people to ERNIE, but to try to stir a dialog on efficiency. Hopefully PCL will be fast for all of us: rich or poor. Yes, this is an important dialog. As for your cost concern, I believe PCL will run well in KCL as well as in more expensive lisps. ------- From Owners-CommonLoops.PA@Xerox.COM Wed Oct 19 15:14:35 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA02861; Wed, 19 Oct 88 15:14:35 PDT Received: from Burger.ms by ArpaGateway.ms ; 19 OCT 88 15:02:14 PDT Return-Path: Redistributed: CommonLoops.PA Received: from rand.org ([10.3.0.7]) by Xerox.COM ; 19 OCT 88 15:00:49 PDT Received: from localhost by rand.org; Wed, 19 Oct 88 14:46:40 PDT Message-Id: <8810192146.AA25927@rand.org> To: Warren Harris Cc: Chris Burdorf , CommonLoops.PA@Xerox.COM Subject: Re: PCL benchmark In-Reply-To: Your message of Tue, 18 Oct 88 19:47:53 PDT. <20982.593232473@hplwhh> Date: Wed, 19 Oct 88 14:46:27 PDT From: Chris Burdorf You can add methods dynamically to ERNIE. If ERNIE and PCL were as close in functionality at C and ERNIE, then we wouldn't need ERNIE and we would just use C. Chris From Owners-commonloops.PA@Xerox.COM Wed Oct 19 16:28:23 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03450; Wed, 19 Oct 88 16:28:23 PDT Received: from Salvador.ms by ArpaGateway.ms ; 19 OCT 88 16:26:25 PDT Return-Path: Redistributed: commonloops.PA Received: from KL.SRI.COM ([10.1.0.2]) by Xerox.COM ; 19 OCT 88 16:24:48 PDT Date: Wed, 19 Oct 88 16:24:42 PDT From: Wei-Han Chu Subject: duplicate messages To: commonloops.PA@Xerox.COM Cc: chu@KL.SRI.COM Message-Id: <12439774950.17.CHU@KL.SRI.COM> As of late, I am consistently getting serveral duplicate copies for each message from the PCL mailing list. Is this a problem for any one else? ------- From Owners-commonloops.pa@Xerox.COM Wed Oct 19 20:39:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06557; Wed, 19 Oct 88 20:39:39 PDT Received: from Riesling.ms by ArpaGateway.ms ; 19 OCT 88 20:35:50 PDT Return-Path: Redistributed: commonloops.pa Received: from alpha ([129.22.16.10]) by Xerox.COM ; 19 OCT 88 20:34:28 PDT Received: by alpha (5.58/25-eef) id AA12336; Wed, 19 Oct 88 23:26:58 EDT Date: Wed, 19 Oct 88 23:26:58 EDT From: Hao Tang Message-Id: <8810200326.AA12336@alpha> To: commonloops.pa@Xerox.COM Subject: re: duplicate messages > As of late, I am consistently getting serveral duplicate copies... I have also been receiving duplicated copies. Could someone check to see where the problem is? Tang@alpha.ces.cwru.edu From Owners-commonloops.PA@Xerox.COM Wed Oct 19 21:04:34 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06696; Wed, 19 Oct 88 21:04:34 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 21:02:34 PDT Return-Path: Redistributed: commonloops.PA Received: from vlsi.caltech.edu ([192.12.18.4]) by Xerox.COM ; 19 OCT 88 21:00:57 PDT Received: by vlsi.caltech.edu (5.54/1.2) id AA01629; Wed, 19 Oct 88 21:02:51 PDT Date: Wed, 19 Oct 88 21:02:51 PDT From: newton@vlsi.caltech.edu (Mike Newton) Message-Id: <8810200402.AA01629@vlsi.caltech.edu> To: commonloops.PA@Xerox.COM Subject: Duplicate messages I, too am getting many duplicates. - mike From Owners-CommonLoops.PA@Xerox.COM Wed Oct 19 21:33:56 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA06782; Wed, 19 Oct 88 21:33:56 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 88 21:31:57 PDT Return-Path: <@RELAY.CS.NET:Ambler@cssun.cs.ukans.edu> Redistributed: CommonLoops.PA Received: from RELAY.CS.NET ([10.4.0.5]) by Xerox.COM ; 19 OCT 88 21:30:33 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa28580; 19 Oct 88 20:54 EDT Received: from csvax.cs.ukans.edu by RELAY.CS.NET id ac22608; 19 Oct 88 20:38 EDT Received: from cssun by csvax.cs.ukans.edu id aa27993; 19 Oct 88 13:10 CDT Date: Wed, 19 Oct 88 13:10:12 CDT From: Ambler@cssun.cs.ukans.edu To: CommonLoops.PA@Xerox.COM Cc: ambler@cssun.cs.ukans.edu Subject: Xerox Common Loops Message-Id: <8810191310.aa27993@csvax.cs.ukans.edu> I have only recently discovered the Common Loops package distributed with Sun Common Lisp 2.1 and have begun to use it considerably. So far I have had few problems, but I am sure that by now there must be a more recent version. Can you tell me what is the current version and how to obtain it? Thanks. Allen Ambler, Dept. of Comp. Sci., U. of Kansas 66044 (913)864-4482 From Owners-commonLoops.pa@Xerox.COM Thu Oct 20 01:35:49 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA08749; Thu, 20 Oct 88 01:35:49 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 01:33:43 PDT Return-Path: Redistributed: commonLoops.pa Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 20 OCT 88 01:27:21 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05040; 14 Oct 88 15:25 BST Date: Fri, 14 Oct 88 15:27:30 BST Message-Id: <26647.8810141427@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: PCL/CLOS performance To: kempf In-Reply-To: kempf@com.sun's message of Thu, 13 Oct 88 08:10:43 PDT > I would caution people who are unhappy with PCL performance to take a look > at what your underlying Common Lisp is doing. Depending on your Common > Lisp, the performance of current PCL generic function invocation can > vary from 3.5X to 15X a function call. There is much that can be done in > an implementation dependent manner to speed up PCL, however, it is > unfair to say that CLOS or PCL is a dog just because the Common > Lisp you happen to be using doesn't generate particularly good code > at the moment. If you are otherwise happy with your Common Lisp, then > talk to whoever is supporting it about improving code generation, > otherwise, look into getting a new one. In the long run, I think > everyone's Common Lisp should converge to about 2.0-2.5X a function > call for a single argument dispatch message send, possibly faster, if > the TICLOS implementation is any guide. Well, (1) is it not the case that TICLOS is not PCL? If so, it may not say all that much about PCL performance. (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. 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. From Owners-commonLoops.pa@Xerox.COM Thu Oct 20 03:43:21 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA10331; Thu, 20 Oct 88 03:43:21 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 03:41:13 PDT Return-Path: Redistributed: commonLoops.pa Received: from NSS.Cs.Ucl.AC.UK ([128.41.9.3]) by Xerox.COM ; 20 OCT 88 03:36:40 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05040; 14 Oct 88 15:25 BST Date: Fri, 14 Oct 88 15:27:30 BST Message-Id: <26647.8810141427@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: PCL/CLOS performance To: kempf In-Reply-To: kempf@com.sun's message of Thu, 13 Oct 88 08:10:43 PDT > I would caution people who are unhappy with PCL performance to take a look > at what your underlying Common Lisp is doing. Depending on your Common > Lisp, the performance of current PCL generic function invocation can > vary from 3.5X to 15X a function call. There is much that can be done in > an implementation dependent manner to speed up PCL, however, it is > unfair to say that CLOS or PCL is a dog just because the Common > Lisp you happen to be using doesn't generate particularly good code > at the moment. If you are otherwise happy with your Common Lisp, then > talk to whoever is supporting it about improving code generation, > otherwise, look into getting a new one. In the long run, I think > everyone's Common Lisp should converge to about 2.0-2.5X a function > call for a single argument dispatch message send, possibly faster, if > the TICLOS implementation is any guide. Well, (1) is it not the case that TICLOS is not PCL? If so, it may not say all that much about PCL performance. (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. 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. From Owners-commonloops.pa@Xerox.COM Thu Oct 20 06:06:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA12325; Thu, 20 Oct 88 06:06:40 PDT Received: from Riesling.ms by ArpaGateway.ms ; 20 OCT 88 06:04:38 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.1.14]) by Xerox.COM ; 20 OCT 88 06:03:02 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA13149; Thu, 20 Oct 88 09:00:38 EDT Received: from localhost.ARPA by yy.cicg.rpi.edu (1.2/1.2-RPI-CICG) id AA00345; Thu, 20 Oct 88 08:28:52 edt Message-Id: <8810201228.AA00345@yy.cicg.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: Duplicate messages Date: Thu, 20 Oct 88 08:28:47 EDT From: phil@yy.cicg.rpi.edu I am also getting duplicates. However, not consistently, rather only occasionally. The last "dupe" I got originated from jeff@aiai... It seems that the messages that are delayed longer are more likely to be duplicated. I just got Jeff's message this morning (as did the rest of you by the looks of the headers). - Phil From Owners-commonloops.PA@Xerox.COM Thu Oct 20 08:08:21 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13472; Thu, 20 Oct 88 08:08:21 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 OCT 88 08:06:23 PDT Return-Path: Redistributed: commonloops.PA Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 20 OCT 88 08:03:18 PDT Received: from a-boy.media.mit.edu by media-lab.media.mit.edu (5.59/4.8) id AA01561; Thu, 20 Oct 88 11:02:54 EDT Received: by a-boy (3.2/4.8) id AB12409; Thu, 20 Oct 88 11:00:44 EDT Date: Thu, 20 Oct 88 11:00:44 EDT From: Michael Sokolov Message-Id: <8810201500.AB12409@a-boy> To: CHU@KL.SRI.COM Cc: commonloops.PA@Xerox.COM, chu@KL.SRI.COM Subject: duplicate messages I think we're all getting messages from both commonloops.PA and CommonLoops.PA; does this soubd right? From Owners-commonloops.PA@Xerox.COM Thu Oct 20 08:54:08 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA13595; Thu, 20 Oct 88 08:54:08 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 20 OCT 88 08:52:01 PDT Return-Path: Redistributed: commonloops.PA Received: from MAXINE.CS.YALE.EDU ([128.36.0.10]) by Xerox.COM ; 20 OCT 88 08:49:34 PDT Received: by MAXINE.CS.YALE.EDU; Thu, 20 Oct 88 11:52:31 EDT Date: Thu, 20 Oct 88 11:52:31 EDT From: Aaron Cohn Message-Id: <8810201552.AA12370@MAXINE.CS.YALE.EDU> To: CHU@KL.SRI.COM, sokolov@a-boy.media.mit.edu Subject: Re: duplicate messages Cc: commonloops.PA@Xerox.COM correct. From Gregor.pa@Xerox.COM Thu Oct 20 10:19:17 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA15621; Thu, 20 Oct 88 10:19:17 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 10:16:43 PDT Date: Thu, 20 Oct 88 10:12 PDT From: Gregor.pa@Xerox.COM Subject: Re: duplicate messages To: Wei-Han Chu , fritzson@PRC.Unisys.COM, Hao Tang , Mike Newton , phil@yy.cicg.rpi.edu, Michael Sokolov , Aaron Cohn Cc: JLarson.pa@Xerox.COM, commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <12439774950.17.CHU@KL.SRI.COM>, <8810200216.AA00981@caesar.PRC.Unisys.COM>, <8810200326.AA12336@alpha>, <8810200402.AA01629@vlsi.caltech.edu>, <8810201228.AA00345@yy.cicg.rpi.edu>, <8810201500.AB12409@a-boy>, <8810201552.AA12370@MAXINE.CS.YALE.EDU> Message-Id: <19881020171250.2.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Read on, real content at the end. Date: Wed, 19 Oct 88 16:24:42 PDT From: Wei-Han Chu As of late, I am consistently getting serveral duplicate copies for each message from the PCL mailing list. Is this a problem for any one else? Date: Wed, 19 Oct 88 22:16:38 EDT From: fritzson@PRC.Unisys.COM I am also getting duplicates of SOME messages. There is no particular pattern that describes which messages are delivered twice. Date: Wed, 19 Oct 88 23:26:58 EDT From: Hao Tang I have also been receiving duplicated copies. Could someone check to see where the problem is? Date: Wed, 19 Oct 88 21:02:51 PDT From: newton@vlsi.caltech.edu (Mike Newton) I, too am getting many duplicates. Date: Thu, 20 Oct 88 08:28:47 EDT From: phil@yy.cicg.rpi.edu I am also getting duplicates. However, not consistently, rather only occasionally. The last "dupe" I got originated from jeff@aiai... It seems that the messages that are delayed longer are more likely to be duplicated. Date: Thu, 20 Oct 88 11:00:44 EDT From: Michael Sokolov I think we're all getting messages from both commonloops.PA and CommonLoops.PA; does this soubd right? Date: Thu, 20 Oct 88 11:52:31 EDT From: Aaron Cohn correct. Actually the person who is closest to right is phil@yy.cicg.rpi.edu. No one mentioned the best answer which is its a bug in sendmail. Certain entries in the mail queue get errors, and then sendmail tries to deliver the message to everyone on the list over and over again. <> Our mailer hackers here are working hard to fix this problem, but the size and complexity of the CommonLoops list makes it difficult. The current idea for a fix will reduce the incidence with which people get duplicate messages, but will not eliminate it completely. Needless to say, messages about problems like this are best sent to the CommonLoops-Request address. ------- From hdavis.pa@Xerox.COM Thu Oct 20 10:36:46 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16239; Thu, 20 Oct 88 10:36:46 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 88 10:25:26 PDT Date: 20 Oct 88 10:23 PDT From: hdavis.pa@Xerox.COM Subject: Re: duplicate messages In-Reply-To: Gregor.pa's message of Thu, 20 Oct 88 10:12 PDT To: commonloops.PA@Xerox.COM Cc: Wei-Han Chu , fritzson@PRC.Unisys.COM, Hao Tang , Mike Newton , phil@yy.cicg.rpi.edu, Michael Sokolov , Aaron Cohn , JLarson.pa@Xerox.COM Message-Id: <881020-102526-3604@Xerox> Recently I've been receiving not just two, but tens of messages with duplicate semantic content. Will someone please look into this problem? -- Harley From Gregor.pa@Xerox.COM Thu Oct 20 10:55:18 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA16686; Thu, 20 Oct 88 10:55:18 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 10:42:32 PDT Date: Thu, 20 Oct 88 10:38 PDT From: Gregor.pa@Xerox.COM Subject: Re: PCL/CLOS performance To: Jeff Dalton Cc: kempf@sun.com, CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest In-Reply-To: <26647.8810141427@subnode.aiai.ed.ac.uk> Message-Id: <19881020173850.5.GREGOR@PORTNOY.parc.xerox.com> Line-Fold: no Date: Fri, 14 Oct 88 15:27:30 BST From: Jeff Dalton Well, (1) is it not the case that TICLOS is not PCL? If so, it may not say all that much about PCL performance. (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. 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. 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. It is also important to note that the TICLOS implementation could be converted to run on stock hardware. Some changes would have to be made to account for the absence of tags, but much of the code could be retained. (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. 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 Thu Oct 20 14:15:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA20220; Thu, 20 Oct 88 14:15:38 PDT Received: from Burger.ms by ArpaGateway.ms ; 20 OCT 88 14:09:33 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.UU.NET ([192.12.141.129]) by Xerox.COM ; 20 OCT 88 14:07:30 PDT Received: from vuse.Vanderbilt.Edu by uunet.UU.NET (5.59/1.14) id AA05857; Thu, 20 Oct 88 16:33:23 EDT Received: by vuse.vanderbilt.edu (4.0/SMI-3.2) id AA15778; Thu, 20 Oct 88 15:33:51 CDT Date: Thu, 20 Oct 88 15:33:51 CDT From: brian@vuse.vanderbilt.edu (Brian Antao) Message-Id: <8810202033.AA15778@vuse.vanderbilt.edu> To: commonloops.pa@Xerox.COM Subject: new addition Could you add me to your CLOS distribution list. Thanks in advance. -- Brian. Email: brian@vuse.vanderbilt.edu Smail: Brian Antao, Vanderbilt University, Box 5393, Station B, Nashville, TN 37235. From Owners-CommonLoops.PA@Xerox.COM Thu Oct 20 15:28:40 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA21228; Thu, 20 Oct 88 15:28:40 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 88 15:16:20 PDT Return-Path: Redistributed: CommonLoops.PA Received: from ads.com ([128.229.30.16]) by Xerox.COM ; 20 OCT 88 15:13:22 PDT Received: by ads.com (5.59/1.17) id AA22745; Thu, 20 Oct 88 15:13:53 PDT Date: Thu, 20 Oct 88 15:13:53 PDT From: John W. Dye Jr. Message-Id: <8810202213.AA22745@ads.com> To: CommonLoops.PA@Xerox.COM Subject: method specalization on defstructs We have some need to be able to specalize methods on defstructs. We have been doing this by using pcl:define-built-in-classes on the names of our defstructs. When swithching from St-paddys-day to AAAI pcl we have encountered problems with doing the following: This is loaded in a file (package view). (setq *view-built-in-classes* '((dynamic-struct (t)) (view-rep-struct (dynamic-struct)) (point-struct (view-rep-struct)) (2d-point (point-struct)) )) (setq pcl::*built-in-classes* (append pcl::*built-in-classes* *view-built-in-classes*)) (pcl::define-built-in-classes) (defstruct (DYNAMIC-STRUCT) dynamic-slot) Lisp trace: VIEW> (setq s (make-dynamic-struct)) #S(DYNAMIC-STRUCT DYNAMIC-SLOT NIL) VIEW> (defmethod blues ((object number)) (print "blues number")) BLUES VIEW> (defmethod blues ((object dynamic-struct)) (print "blues dynamic-struct")) BLUES VIEW> (blues 13) "blues number" "blues number" VIEW> (blues s) >>Error: No matching method for the generic-function #, when called with arguments (#S(DYNAMIC-STRUCT DYNAMIC-SLOT NIL)). NO-APPLICABLE-METHOD: Required arg 0 (GENERIC-FUNCTION): # :A 0: Abort to Lisp Top Level -> :A Abort to Lisp Top Level Back to Lisp Top Level VIEW> (pcl::describe-class (find-class 'dynamic-struct)) The class # is an instance of class #. Name: DYNAMIC-STRUCT Class-Precedence-List: (DYNAMIC-STRUCT T) Local-Supers: (T) Direct-Subclasses: (VIEW-REP-STRUCT) # VIEW> Should this work?? Am I the victim of package problems?? Am I doing something inherently evil?? Should I be locked in a closet with the pcl source until I understand how method lookup works?? JD jdye@ads.com From CL-Cleanup-mailer@SAIL.STANFORD.EDU Thu Oct 20 17:31:38 1988 Received: from Sail.Stanford.EDU by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA22218; Thu, 20 Oct 88 17:31:38 PDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88 17:19:53 PDT Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08318g; Thu, 20 Oct 88 17:19:26 PDT Received: by bhopal id AA06100g; Thu, 20 Oct 88 17:17:51 PDT Date: Thu, 20 Oct 88 17:17:51 PDT From: Jon L White Message-Id: <8810210017.AA06100@bhopal> To: miller@CS.ROCHESTER.EDU Cc: masinter.pa@Xerox.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU, harris%hplwhh@hplabs.hp.com In-Reply-To: Brad Miller's message of Mon, 10 Oct 88 16:41 EDT <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Subject: Issue: EVAL-OTHER (Version 2) 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 -- From Owners-CommonLOOPS.pa@Xerox.COM Fri Oct 21 04:07:39 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA00217; Fri, 21 Oct 88 04:07:39 PDT Received: from Semillon.ms by ArpaGateway.ms ; 21 OCT 88 03:29:27 PDT Return-Path: <@CUNYVM.CUNY.EDU:ay%cs.hut.fi@santra.hut.fi> Redistributed: CommonLOOPS.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 21 OCT 88 03:26:54 PDT Received: from FINHUTC.HUT.FI by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 1736; Fri, 21 Oct 88 06:26:22 EDT Received: from FINHUTC.HUT.FI by FINHUTC.HUT.FI (Mailer X1.25) with BSMTP id 5585; Fri, 21 Oct 88 11:55:49 EET Received: from santra.hut.fi by FINHUTC.HUT.FI ; 21 Oct 88 11:55:48 EET Received: from cs.hut.fi (cs-hut-router.hut.fi) by santra.hut.fi (5.57/ida/6.7/TeKoLa) id AA13395; Fri, 21 Oct 88 11:55:15 +0200 Received: by cs.hut.fi (3.2/6.6/S-TeKoLa) id AA01364; Fri, 21 Oct 88 11:55:12 +0200 Date: Fri, 21 Oct 88 11:55:12 +0200 From: Antti Ylikoski Message-Id: <8810210955.AA01364@cs.hut.fi> To: CommonLOOPS.pa@Xerox.COM Cc: ay@cs.hut.fi Subject: a request for inclusion Could you please add me to the Common Lisp Object System (CLOS) mailing list. I would also be very grateful if you could let me know if it is possible to obtain the PCL system from Xerox on a tape. I haven't access to arisia.xerox.com via FTP. Thanks, Andy Ylikoski Helsinki University of Technology Lab of Information Processing Science Otakaari 1 A SF-02150 Espoo 15, Finland From Owners-commonloops.pa@Xerox.COM Fri Oct 21 10:04:38 1988 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.59++/IDA-1.2.6) id AA03103; Fri, 21 Oct 88 10:04:38 PDT Received: from Semillon.ms by ArpaGateway.ms ; 21 OCT 88 09:58:11 PDT Return-Path: Redistributed: commonloops.pa Received: from Sun.COM ([10.7.0.2]) by Xerox.COM ; 21 OCT 88 09:55:02 PDT Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA24386; Fri, 21 Oct 88 09:52:35 PDT Received: from Ecd.Sun.COM (suneast) by snail.Sun.COM (4.0/SMI-4.0) id AA19299; Fri, 21 Oct 88 09:55:26 PDT Received: from symbol.sunecd.com by Ecd.Sun.COM (3.2/SMI-3.2) id AA06040; Fri, 21 Oct 88 12:55:07 EDT Return-Path: Received: by symbol.sunecd.com (3.2/SMI-2.0) id AA10082; Fri, 21 Oct 88 12:58:02 EDT Date: Fri, 21 Oct 88 12:58:02 EDT From: cdr%symbol%suneast@Sun.COM (Constantine Rasmussen - Sun ECD) Message-Id: <8810211658.AA10082@symbol.sunecd.com> To: commonloops.pa@Xerox.COM Subject: Addition to list Please add me to this list if I'm not already on it. This is my 2nd request. Thank you. Constantine Rasmussen Sun Microsystems, East Coast Div. F658 (508) 671-0404 2 Federal Street; Billerica, Mass. 01824 ARPA: cdr@sun.com USENET: {cbosgd,decvax,hplabs,seismo}!sun!cdr