Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17027; Fri, 29 Jun 90 19:41:53 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 29 JUN 90 15:01:12 PDT Return-Path: Redistributed: commonloops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 29 JUN 90 14:59:32 PDT Received: from medusa ([192.31.213.13]) by heavens-gate.lucid.com id AA09568g; Fri, 29 Jun 90 14:55:38 PDT Received: by medusa id AA00696g; Fri, 29 Jun 90 14:54:59 PDT Date: Fri, 29 Jun 90 14:54:59 PDT From: Jim Healy Message-Id: <9006292154.AA00696@medusa> To: straz@media-lab.media.mit.edu Cc: jonl@lucid.com, clue-bugs@dsg.csc.ti.com, hp-support@lucid.com, commonloops.PA@Xerox.COM Subject: Re: CLUE won't compile Steve, In a separate message, I'll mail you a patch for bug-5405 for the HP9000. This patch fixes a labels compiler bug in HP Common Lisp 3.0 that was causing the production compiler to give an error while compiling BRAID.LISP in the May Day version of PCL. This should allow you to compile the May Day version of PCL and hopefully get past the "metacircular screw" bug in PCL that JonL mentioned in a previous message: Date: Thu, 21 Jun 90 21:20:17 PDT From: Jon L White The backtrace you showed is a classic case of the "metacircular screw" -- namely, at some point PCL::NOTICE-METHODS-CHANGE-1 is called on an "invalid" generic-function in order to update its list of combined, effective methods; but alas the update computation requires the _use_ of the very generic function undergoing update! and so it gets into an infinite recursion of calls to PCL::NOTICE-METHODS-CHANGE-1. Jim Healy Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17168; Fri, 29 Jun 90 19:49:30 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 29 JUN 90 06:00:24 PDT Return-Path: Redistributed: commonloops.pa Received: from soleil.cs.UMD.EDU ([128.8.128.14]) by Xerox.COM ; 29 JUN 90 05:59:10 PDT Received: from localhost by soleil.cs.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA29741; Fri, 29 Jun 90 08:59:10 -0400 Message-Id: <9006291259.AA29741@soleil.cs.UMD.EDU> To: commonloops.pa@Xerox.COM Subject: CLOS Workshop Date: Fri, 29 Jun 90 08:59:06 -0400 From: Josh Lubell I would like more information about the upcoming CLOS workshop, but Andreas Paepcke (the organizer) is away until late July. Since the deadline for submissions is August 1, I would appreciate it if someone could get in touch with me. Can anyone out there help me? You can either respond by email, or you can call me at 301-231-2643. Thanks! Josh Lubell lubell@cs.umd.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26476; Mon, 2 Jul 90 12:14:44 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 JUL 90 12:13:54 PDT Return-Path: Redistributed: commonloops.pa Received: from turing.cs.rpi.edu ([128.213.1.1]) by Xerox.COM ; 02 JUL 90 12:11:29 PDT Date: Mon, 2 Jul 90 15:10:10 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA15379; Mon, 2 Jul 90 15:10:10 EDT Message-Id: <9007021910.AA15379@turing.cs.rpi.edu> To: commonloops.pa@Xerox.COM Subject: Re: May Day PCL bugs affecting instances of redefined classes There is a mistake in one of the changes to PCL given in the message: > Date: Thu, 28 Jun 90 19:20:17 EDT > From: harrisr@turing.cs.rpi.edu (Richard Harris) > Message-Id: <9006282320.AA25016@turing.cs.rpi.edu> > To: commonloops.pa@Xerox.COM > Subject: May Day PCL bugs affecting instances of redefined classes > > Here are some bugs in May Day PCL I have found while > redefining classes which have existing instances. > If you made the changes in that message, change line-valid-p to be: ;; ;; Given a line number, return true IFF the line is full and ;; there are no invalid wrappers in the line, and the line's ;; wrappers are different from wrappers. ;; An error is signalled if the line is reserved. ;; (line-valid-p (line wrappers) (when (line-reserved-p line) (error "Line is reserved.")) (let ((loc (line-location line)) (wrappers-mismatch-p (null wrappers))) (dotimes (i (nkeys) wrappers-mismatch-p) (let ((wrapper (cache-ref (cache) (+ loc i)))) (when (or (null wrapper) (invalid-wrapper-p wrapper)) (return nil)) (unless (and wrappers (eq wrapper (if (consp wrappers) (pop wrappers) wrappers))) (setq wrappers-mismatch-p t)))))) ----- Richard Harris Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16712; Tue, 3 Jul 90 02:13:21 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 03 JUL 90 02:12:21 PDT Return-Path: Redistributed: commonLoops.PA Received: from sirius.ucs.adelaide.edu.au ([129.127.40.3]) by Xerox.COM ; 03 JUL 90 02:10:39 PDT Received: from lux.sait.edu.au by sirius.ucs.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.8) id AA08786; Tue, 3 Jul 1990 18:40:02 +0930 Received: from levels.sait.oz (lv.sait.edu.au) by lux.sait.edu.au (4.0/SMI-4.0) id AA09422 for commonLoops@xerox.com Date: Tue, 3 Jul 90 18:39 +0930 From: Jenny.Rowland@lv.sait.edu.au Subject: PCL Sender: "Jenny.Rowland@sait.edu.au, FS2-50, X3056" To: commonLoops.PA@Xerox.COM Message-Id: <6DE3BAF7850F401343@sait.edu.au> X-Envelope-To: commonLoops@xerox.com X-Vms-To: IN%"commonLoops@xerox.com" X-Vms-Cc: MAJGR I have some files relating to PCL - the latest version seems to be 12/7/88. Could you please tell me: 1. Is there a later version? - for VAX/VMS 2. How do I obtain it - ie which files and which FTP site? 3. What do I do with it then. I find the notes included with my current version a little cryptic. Do you have some clearer instruction? Thank you for your help, Jenny Rowland ------------------------------------------------------------------------------- Jennifer Rowland, Lecturer, School of Mathematics and Computer Studies, South Australian Institute of Technology, Levels Campus, The Levels, S.A., 5095 Phone: (+61-8) 343 3056 Email: Jenny.Rowland@sait.edu.au Fax: (+61-8) 343 3203 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18903; Tue, 3 Jul 90 04:46:02 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 03 JUL 90 04:44:04 PDT Return-Path: Redistributed: commonloops.pa Received: from sirius.ucs.adelaide.edu.au ([129.127.40.3]) by Xerox.COM ; 03 JUL 90 04:42:37 PDT Received: from lux.sait.edu.au by sirius.ucs.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.8) id AA10335; Tue, 3 Jul 1990 21:12:33 +0930 Received: from levels.sait.oz (lv.sait.edu.au) by lux.sait.edu.au (4.0/SMI-4.0) id AA09727 for commonloops.pa@xerox.com Date: Tue, 3 Jul 90 21:12 +0930 From: Jenny.Rowland@lv.sait.edu.au Subject: PCL Sender: "Jenny.Rowland@sait.edu.au, FS2-50, X3056" To: commonloops.pa@Xerox.COM Message-Id: <6DCE677935AF401F4C@sait.edu.au> X-Envelope-To: commonloops.pa@xerox.com X-Vms-To: IN%"commonloops.pa@xerox.com" X-Vms-Cc: MAJGR I have some files relating to PCL - the latest version seems to be 12/7/88. Could you please tell me: 1. Is there a later version? - for VAX/VMS 2. How do I obtain it - ie which files and which FTP site? 3. What do I do with it then. I find the notes included with my current version a little cryptic. Do you have some clearer instruction? Thank you for your help, Jenny Rowland ------------------------------------------------------------------------------- Jennifer Rowland, Lecturer, School of Mathematics and Computer Studies, South Australian Institute of Technology, Levels Campus, The Levels, S.A., 5095 Phone: (+61-8) 343 3056 Email: Jenny.Rowland@sait.edu.au Fax: (+61-8) 343 3203 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04676; Tue, 3 Jul 90 14:52:49 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 03 JUL 90 10:12:17 PDT Return-Path: Redistributed: commonloops.pa Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 03 JUL 90 10:08:55 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA00709; Tue, 3 Jul 90 10:09:24 PDT Message-Id: <9007031709.AA00709@roo.parc.xerox.com> Date: Tue, 3 Jul 90 10:09:24 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com Cc: commonloops.pa@Xerox.COM In-Reply-To: Jenny.Rowland@lv.sait.edu.au's message of Tue, 3 Jul 90 21:12 +0930 <6DCE677935AF401F4C@sait.edu.au> Subject: Re: PCL Line-Fold: NO Date: Tue, 3 Jul 90 21:12 +0930 From: Jenny.Rowland@lv.sait.edu.au I have some files relating to PCL - the latest version seems to be 12/7/88. Actually, the latest version is May of 90. Following is the standard information about PCL which may be helpful to you. Portable CommonLoops (PCL) started out as an implementation of CommonLoops written entirely in CommonLisp. It is in the process of being converted to an implementation of CLOS. Currently it implements a only a subset of the CLOS specification. Unfortunately, there is no detailed description of the differences between PCL and the CLOS specification, the source code is often the best documentation. Currently, PCL runs in the following implementations of Common Lisp: EnvOS Medley Symbolics (Release 7.2) Lucid (3.0) ExCL (Franz Allegro 3.0.1) KCL (June 3, 1987) AKCL (1.86, June 30, 1987) Ibuki Common Lisp (01/01, October 15, 1987) TI (Release 4.1) Coral Common Lisp (Allegro 1.2) Golden Common Lisp (3.1) CMU VAXLisp (2.0) HP Common Lisp Pyramid Lisp There are several ways of obtaining a copy of PCL. *** Arpanet Access to PCL *** The primary way of getting PCL is by Arpanet FTP. The files are stored on arisia.xerox.com. You can copy them using anonymous FTP (username "anonymous", password "anonymous"). There are several directories which are of interest: /pcl This directory contains the PCL sources as well as some rudimentary documentation (including this file). All of these files are combined into a single Unix TAR file. The name of this file is "tarfile". Extract the individual files from this tarfile by saying: tar -xf tarfile * where `tarfile' is the name you have given the tarfile in your directory. Once you have done this, the following files are of special interest: readme.text READ IT notes.text contains notes about the current state of PCL, and some instructions for installing PCL at your site. You should read this file whenever you get a new version of PCL. get-pcl.text contains the latest draft of this message /pcl/doc This directory contains TeX source files for the most recent draft of the CLOS specification. There are TeX source files for two documents called concep.tex and functi.tex. These correspond to chapter 1 and 2 of the CLOS specification. /pcl/archive This directory contains the joint archives of two important mailings lists: CommonLoops@Xerox.com is the mailing list for all PCL users. It carries announcements of new releases of PCL, bug reports and fixes, and general advice about how to use PCL and CLOS. Common-Lisp-Object-System@Sail.Stanford.edu is a small mailing list used by the designers of CLOS. The file cloops.text is always the newest of the archive files. The file cloops1.text is the oldest of the archive files. Higher numbered versions are more recent versions of the files. *** Getting PCL on Macintosh floppies *** PCL is listed in APDAlog. It is distributed on Macintosh floppies. This makes it possible for people who don't have FTP access to arisia (but who do have a Macintosh) to get PCL. For $40 you receive a version of PCL and a copy of the CLOS spec (X3J13 document number 88-002R). The APDAlog catalog number is T0259LL/A and you can order by calling: From the U.S. (800)282-2732 From Canada (800)637-0029 International (408)562-3910 FAX (408)562-3971 NOTE: Whenever there is a new release of PCL you want, you should probably wait a couple of months before ordering it from APDAlog. We want to let new PCL's stabilize a bit before sending it to them, and it will take them some time to integrate the new disks into their distribution. *** Using the BITFTP server at Princeton *** For people who can't FTP from Internet (Arpanet) hosts, but who have mail access to the BITNET, there exists a way to get the PCL files using the BITFTP service provided by Princeton Univerity. If you know exactly where to find the files that interest you, this is quite easy. In particular, you have to know: * the Internet host name of the host that maintains the files (such as `arisia.Xerox.COM') * the directory where to find the files, relative to the root of the FTP tree (i.E. `pub') * whether the files are binary or ASCII text. * the names of the files (say `pcl90.tar.Z' and `pcl90.README') To do this, send a message to BITFTP@PUCC (or BITFTP@PUCC.BITNET if you aren't on BITNET itself). The subject line of the message will be ignored. The text (body) of the message should be: FTP arisia.xerox.com UUENCODE CD pcl BINARY GET tarfile QUIT Then you wait (probably for about a day when you are in Europe) and eventually you will receive E-Mail messages from BITFTP@PUCC (or BITFTP2%PUCC...) with subject lines like `uudecoded file tarfile part 13'. Then you have to carefully concatenate the contents of ALL of these files in the correct order. Note: The following works on our Suns and should work on any Berkeley UNIX machine. If you don't have the `compress' or `zcat' program, you can get a free version (with MIT's X Window System distribution, for example). The resulting file can be `uudecode'd like this: dagobert% uudecode name-of-the-assembled-file This will give you a file tarfile.Z (it may actually have a different name; then you may want to rename it in the first place). The `.Z' at the end means that the file you now have is compressed. You can uncompress it with `uncompress tarfile. You can untar the uncompressed file with `tar -xvf tarfile'. This will write all files in the tarfile to the current directory. If you want to know more about the BITFTP service, send a letter to `BITFTP@PUCC' that contains the single line `HELP'. *** Xerox Internet Access to PCL *** Xerox XNS users can get PCL from {NB:PARC:XEROX} Send any comments, bug-reports or suggestions for improvements to: CommonLoops.pa@Xerox.com Send mailing list requests or other administrative stuff to: CommonLoops-Request@Xerox.com Thanks for your interest in PCL. ---------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12334; Tue, 3 Jul 90 18:06:05 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 03 JUL 90 17:59:29 PDT Return-Path: Redistributed: CommonLoops.PA Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 03 JUL 90 17:58:11 PDT Received: from helmholtz.arc.nasa.gov by ames.arc.nasa.gov (5.64/1.2); Tue, 3 Jul 90 17:58:06 -0700 Received: by helmholtz.arc.nasa.gov (4.1/SMI-4.0) id AA01275; Tue, 3 Jul 90 17:55:01 PDT Date: Tue, 3 Jul 90 17:55:01 PDT From: eero@helmholtz.arc.nasa.gov (Eero Simoncelli) Message-Id: <9007040055.AA01275@helmholtz.arc.nasa.gov> To: CommonLoops.PA@Xerox.COM Subject: Changing default slot values (or initforms) Is there a mechanism for altering the initforms of slots of an existing class? I couldn't find this in the spec, but it seems like a useful ability. From a top-level point of view, a user should be able to alter the slots of an instance, or alter the default values of those slots for the entire class. Eero. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17179; Thu, 5 Jul 90 16:31:00 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 05 JUL 90 11:29:05 PDT Return-Path: Redistributed: CommonLoops.PA Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 05 JUL 90 11:27:40 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA08299; Thu, 5 Jul 90 11:28:08 PDT Message-Id: <9007051828.AA08299@roo.parc.xerox.com> Date: Thu, 5 Jul 90 11:28:08 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: eero@helmholtz.arc.nasa.gov Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Eero Simoncelli's message of Tue, 3 Jul 90 17:55:01 PDT <9007040055.AA01275@helmholtz.arc.nasa.gov> Subject: Re: Changing default slot values (or initforms) Line-Fold: NO Date: Tue, 3 Jul 90 17:55:01 PDT From: eero@helmholtz.arc.nasa.gov (Eero Simoncelli) Is there a mechanism for altering the initforms of slots of an existing class? I couldn't find this in the spec, but it seems like a useful ability. Its a little difficult for me to tell exactly what you are asking. It seems like it could be one of two things, and the answer is different in each case. 1) Is there a mechanism for changing the initform of a slot of a class that I HAVE DEFINED. The answer here is YES, and there are two ways to do it. One way is to take the original defclass form, edit it to have the new initform, and then re-evaluate it. CLOS makes it clear that this is well-defined. Any instances created afterwards will use the new initform. Using the metaobject protocol (if your implementation supports it), it is possible to write a function which will change the initform of any given slot. It would go something like this: (defun change-initform (class slot-name form fn) (let* ((slots (class-direct-slots class)) (slot (find slot-name slots :key #'slot-definition-name)) (new (make-instance (class-of slot) :name (slot-definition-name slot) :allocation (slot-definition-allocation slot) :initform form :initfunction fn :type (slot-definition-type slot) :readers (slot-definition-readers slot) :writers (slot-definition-writers slot)))) (reinitalize-instance class :direct-slots (cons new (remove slot slots))))) So, give a class FOO, with a slot X, you could change its initform to 1 by doing: (CHANGE-INITFORM (FIND-CLASS 'FOO) 'X '1 #'(LAMBDA () 1)). 2) The second question you could be asking is how can I change an initform of a slot of a class that I DID NOT DEFINE. The criticial point here is that you probably shouldn't. In general, slots tend to be internal, implementation details of a class. Most often, you shouldn't even know what slots a class you didn't define has. You certainly shouldn't be mucking around with internal things like what the initforms are. If the implementor of the class wanted to give you this kind of control, they would have defined an initarg for the class. Given that, you could define your own subclass of that class and use the :default-initargs mechanism to get whatever default behavior you want. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27990; Tue, 10 Jul 90 19:05:12 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 10 JUL 90 13:41:01 PDT Return-Path: Redistributed: CommonLoops.PA Received: from aplcen.apl.jhu.edu ([128.220.101.4]) by Xerox.COM ; 10 JUL 90 13:38:45 PDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA16256; Tue, 10 Jul 90 16:38:45 EDT Date: Tue, 10 Jul 90 16:38:45 EDT From: hall@aplcen.apl.jhu.edu (Marty Hall) Message-Id: <9007102038.AA16256@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: CommonLoops.PA@Xerox.COM Subject: Assigning default slot value plus side effects? I'm new to CLOS, so excuse me if this is a basic question. I have a slot that, whenever a value is stored in it, I want side effects to occur. For the sake of illustration lets say that I just want to execute a format statement saying the slot has the specified value. This, of course, is simple: I just write a :after method on (setf ) for that slot. Ie (defclass foo () ((bar :accessor bar)) ) (defmethod (setf bar) :after (bar-value (object foo)) (format t "~%Put the value ~S into bar slot of ~S." bar-value object)) My problem is with a default value for the slot. I want to assign a default value, but still have my after method fire. Ie I added a :initform to the bar slot of foo objects. However, initialize-instance uses setf on slot-value, rather than using the accessor, so my :after method does not fire when I make an instance of foo. Certainly I could omit the :initform, do make-instance, then use my accessor to set the value. But this seems to somewhat contradict the object-oriented nature. Have I overlooked an obvious approach? Is there some way to make an after method on (setf (slot-value 'bar)) ? Thanks for any suggestions- - Marty Hall ------------------------------------------------------------------- hall@aplcen.apl.jhu.edu Artificial Intelligence Lab hall%aplcen.apl.jhu.edu@cunyvm.bitnet AAI Corp ..!uunet!aplcen!hall PO Box 126 (301) 683-6455 Hunt Valley, MD 21030 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00950; Wed, 11 Jul 90 16:22:56 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 11 JUL 90 16:06:44 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uc.msc.umn.edu ([137.66.1.3]) by Xerox.COM ; 11 JUL 90 16:05:18 PDT Received: from molbio.cbs.umn.edu by uc.msc.umn.edu (5.59/1.14) id AA17199; Wed, 11 Jul 90 18:05:14 CDT From: "Peter N. Saurugger" Message-Id: <9007112304.AA01720@molbio.cbs.umn.edu> Received: by molbio.cbs.umn.edu; Wed, 11 Jul 90 18:04:15 CDT Subject: Re: Assigning default slot value plus side effects? To: hall@aplcen.apl.jhu.edu (Marty Hall) Date: Wed, 11 Jul 90 18:04:14 CDT Cc: CommonLoops.PA@Xerox.COM In-Reply-To: <9007112231.AA01495@molbio.cbs.umn.edu>; from "Peter N. Saurugger" at Jul 11, 90 5:31 pm X-Mailer: ELM [version 2.3test PL26] > I'm new to CLOS, so excuse me if this is a basic question. I'm not quite new, but ran into the same problem (and have not found any *elegant* way to circumvent the problem: usually I write the slot values after initializing the instance, as you suggested) > > (defclass foo () ((bar :accessor bar)) ) > > (defmethod (setf bar) :after (bar-value (object foo)) > (format t "~%Put the value ~S into bar slot of ~S." bar-value object)) > > My problem is with a default value for the slot. I want to assign a default > value, but still have my after method fire. Ie I added a :initform to > the bar slot of foo objects. However, initialize-instance > uses setf on slot-value, rather than using the accessor, so my :after > method does not fire when I make an instance of foo. > Short of rewriting shared-initialize (I guess in init.cl) to use accessors (if available) instead of slot-value ... - you could use the following (and ugly) kludge: (defmethod initialize-instance :after ((object foo)) (setf (bar object) (bar object)) ) You have to specify this for every object-slot combination you want to show this behaviour. Of course, you could specialize it on any instance of standard-class, and update all the slots of this object the way it is shown above for a single slot. While the X3JI3 Specs mention the possibility of adding to the existing initialization-protocol, the behaviour you describe does not seem to be mentioned in this document. I agree very strongly with you that on initialization I would expect the same behaviour as when updating a slot. I do not know whether these specs still can be amended, but if there is no major reason against this, why not "vote" on the possibility of an amendment to the behaviour of shared-initialize ? Peter N. Saurugger, Director peter-s@molbio.cbs.umn.edu Molecular Biology Computing Center Coll.Biol.Sci., UofMN Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23621; Thu, 12 Jul 90 13:06:28 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 12 JUL 90 11:50:46 PDT Return-Path: <@YALEVM.YCC.Yale.Edu:Sheldon_Ball.MEDINF@yccatsmtp.ycc.yale.edu> Redistributed: commonloops.pa Received: from YALEVM.YCC.Yale.Edu ([130.132.1.4]) by Xerox.COM ; 12 JUL 90 11:47:31 PDT Received: from yccatsmtp.ycc.yale.edu by YALEVM.YCC.Yale.Edu (IBM VM SMTP R1.2.1) with TCP; Thu, 12 Jul 90 14:49:14 EDT Date: 12 Jul 90 14:52:52 From: Sheldon Ball Subject: Suitability id CLOS To: commonloops.pa@Xerox.COM Message-Id: <900712-115046-6034@Xerox> Subject: Time: 2:43 PM OFFICE MEMO Suitability id CLOS Date: 7/12/90 I recently received a reviewer's comments concerning an application of PCL in the domain of molecular pathology. These comments included the criticism "CLOS is NOT well suited to the development of very large knowledge bases." Does anyone disagree or should I accept this as constructive criticism? Sheldon Ball Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07127; Thu, 12 Jul 90 18:27:00 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 12 JUL 90 16:13:59 PDT Return-Path: <@CUNYVM.CUNY.EDU:BALL@YALEMED.BITNET> Redistributed: commonLoops.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 12 JUL 90 16:13:03 PDT Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4481; Thu, 12 Jul 90 19:12:04 EDT Date: Thu, 12 Jul 90 19:12 EST From: Subject: suitability of CLOS for large KB To: commonLoops.PA@Xerox.COM X-Original-To: commonLoops.PA@xerox.COM, BALL Message-Id: <900712-161359-7007@Xerox> I recently received a reviewer's comments concerning a manuscript I submitted describing an application of PCL in the domain of molecular pathology. In these comments was the criticism "CLOS is NOT well suited to the development of very large knowledge bases." Does anyone disagree or should I accept this as constructive criticism? Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18335; Fri, 13 Jul 90 07:35:24 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 90 17:34:01 PDT Return-Path: Redistributed: commonLoops.PA Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 12 JUL 90 17:31:55 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA00926; Thu, 12 Jul 90 17:32:28 PDT Message-Id: <9007130032.AA00926@roo.parc.xerox.com> Date: Thu, 12 Jul 90 17:32:28 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Cc: commonLoops.PA@Xerox.COM In-Reply-To: 's message of Thu, 12 Jul 90 19:12 EST <900712-161359-7007@Xerox> Subject: Re: suitability of CLOS for large KB Line-Fold: NO Date: Thu, 12 Jul 90 19:12 EST From: X-Original-To: commonLoops.PA@xerox.COM, BALL I recently received a reviewer's comments concerning a manuscript I submitted describing an application of PCL in the domain of molecular pathology. In these comments was the criticism "CLOS is NOT well suited to the development of very large knowledge bases." Does anyone disagree or should I accept this as constructive criticism? This comment is too terse for me to agree (or disagree). About all I can say about it is I don't understand it. Part of the problem is that I don't understand whether the emphasis is supposed to be on `very large', `knowledge bases' or `development'. I have tried making sense of it all three ways and can't. Perhaps you can find out more just what was meant? Or maybe you already have enough context to provide us with some more interpretation. One thing which might help would be to know what, if anything, the reviewer was implicitly comparing CLOS to? Were there specific problems this comment was in response to? Was the comment really about CLOS, or about a specific implementation (you mention PCL but I don't know about the reviewer, and I would hope that no one in a position to review papers would make the mistake of confusing PCL with CLOS in any of these dimensions). In general, I can't imagine accepting a comment like this one as constructive criticism without having both a clearer picture of exactly what was meant, and being told what the evidence was to support the claim. There are a number of people, many of them on this mailing list, who have successfully used CLOS in very large systems, in development situations, and in knowledge base systems. Some of them have even done development of very large knowledge base systems. Perhaps if we can learn more about what this comment was intended to mean, the experience of those people can be brought to bear on the problem of evaluating its correctness and relevance to your situation. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18743; Fri, 13 Jul 90 07:45:40 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JUL 90 06:54:49 PDT Return-Path: Redistributed: CommonLoops.PA Received: from aplcen.apl.jhu.edu ([128.220.101.4]) by Xerox.COM ; 13 JUL 90 06:52:22 PDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA18884; Fri, 13 Jul 90 09:52:29 EDT Date: Fri, 13 Jul 90 09:52:29 EDT From: hall@aplcen.apl.jhu.edu (Marty Hall) Message-Id: <9007131352.AA18884@aplcen.apl.jhu.edu> X-Mailer: Mail User's Shell (6.1 4/26/88) To: CommonLoops.PA@Xerox.COM Subject: List of slots for object? Is there a general (non-PCL specific) way of getting a list of the slots of an object? In PCL you can do (pcl::slots-to-inspect (class-of ) ) but, to my embarrassment, I have been unable to find a general CLOS method in Steele or Keene, but I probably didn't know where to look. I assume there is a way, since "describe" would make use of it... Thanks- - Marty Hall ------------------------------------------------------ hall@aplcen.apl.jhu.edu, hall%aplcen@jhunix.bitnet, ..uunet!aplcen!hall Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18817; Fri, 13 Jul 90 07:48:56 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUL 90 06:42:27 PDT Return-Path: Redistributed: CommonLoops.PA Received: from aplcen.apl.jhu.edu ([128.220.101.4]) by Xerox.COM ; 13 JUL 90 06:41:04 PDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA18570; Fri, 13 Jul 90 09:41:10 EDT Date: Fri, 13 Jul 90 09:41:10 EDT From: hall@aplcen.apl.jhu.edu (Marty Hall) Message-Id: <9007131341.AA18570@aplcen.apl.jhu.edu> In-Reply-To: "Peter N. Saurugger"'s message of Jul 11, 18:04 X-Mailer: Mail User's Shell (6.1 4/26/88) To: CommonLoops.PA@Xerox.COM Subject: Re: Assigning default slot value plus side effects? I had an application where, there were side effects that needed to occur for all values in a certain slot of a class of objects. I noted that it was obvious how to do this for changed values, by attaching a :after method to (setf ) on the slot, but that I couldn't find a way to make use of default values this way, because initialize-instance uses slot-value (not the accessors) for putting values in slots. Of course, I could write my own initialization function that initializes the object then puts in the values using the accessors, but (being new to clos), I wondered if I had overlooked something clean way of doing it. Peter Saurugger responded that he didn't think there was any clean approach, and went on to say: > > While the X3JI3 Specs mention the possibility of adding to the existing > initialization-protocol, the behaviour you describe does not seem to be > mentioned in this document. > > I agree very strongly with you that on initialization I would expect the > same behaviour as when updating a slot. I do not know whether these specs > still can be amended, but if there is no major reason against this, why > not "vote" on the possibility of an amendment to the behaviour of > shared-initialize ? How does one "vote"? Also, does anyone know the motivation of X3J13 for using slot-value instead of the accessors for initialization? Is there a big efficiency win there? - Marty Hall ------------------------------------------------------ hall@aplcen.apl.jhu.edu, hall%aplcen@jhunix.bitnet, ..uunet!aplcen!hall Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19357; Fri, 13 Jul 90 08:13:59 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUL 90 08:07:11 PDT Return-Path: Redistributed: commonLoops.PA Received: from WIZARD.OZ.CS.CMU.EDU ([128.2.209.119]) by Xerox.COM ; 13 JUL 90 08:05:25 PDT Received: from wizard.oz.cs.cmu.edu by WIZARD.OZ.CS.CMU.EDU id aa04197; 13 Jul 90 11:03:44 EDT To: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Cc: commonLoops.PA@Xerox.COM, Joseph.Bates@WIZARD.OZ.CS.CMU.EDU Subject: Re: suitability of CLOS for large KB In-Reply-To: Your message of Thu, 12 Jul 90 19:12:00 -0500. <900712-161359-7007@Xerox> Date: Fri, 13 Jul 90 11:03:39 EDT Message-Id: <4195.647881419@WIZARD.OZ.CS.CMU.EDU> From: Joseph.Bates@WIZARD.OZ.CS.CMU.EDU My experience has been that nothing is well suited to very large knowledge bases. For merely large knowledge bases, such as somewhat larger than what fits into the paging space allocated to Lisp, you might be able to use CLOS and include a subsystem for moving data back and forth to disk. However, the few PCL implementations I have used are all rather slow, so if speed is a concern then PCL may not be a good choice. Joe Bates Carnegie Mellon SCS joseph.bates@cs.cmu.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25290; Fri, 13 Jul 90 12:04:02 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JUL 90 11:18:43 PDT Return-Path: Redistributed: commonloops.pa Received: from vx.acs.umn.edu ([128.101.63.1]) by Xerox.COM ; 13 JUL 90 11:17:14 PDT Date: Fri, 13 Jul 90 13:17 CDT From: RAZ@vx.acs.umn.edu Subject: request help with installing PCL on Vax and Mac To: commonloops.pa@Xerox.COM Message-Id: <6634FE4B405FA03476@UMNACVX.BITNET> X-Envelope-To: commonloops.pa@xerox.com X-Vms-To: IN%"commonloops.pa@xerox.com" I am having some problems installing May Day PCL with both Vax Lisp 3.1 and Macintosh Allegro CL 1.3.2 The first error I get with Vax Lisp is in the file FNGEN.LSP: Error in COMPUTE-CONSTANTS Compile time fatal error while executing #:MAKE-&ENV-FOR-CLC-I2660 Error signalled by ERROR Error message would have been: "Invalid operation on lexical environment: #:G1539 #" Surrounding forms: (GATHERING1 (APPENDING) (WALK-FORM LAMBDA NIL #'(LAMBDA # # #))) (MACROLET ((APPENDING NIL `#)) (GATHERING1 (APPENDING) (WALK-FORM LAMBDA NIL #'#))) (BLOCK COMPUTE-CONSTANTS (MACROLET (#) (GATHERING1 # #))) The error I get on the Mac is in the file FSC: Error: Can't determine class of # Any help would be greatly appreciated. Ron Zacharski Univ of Minnesota Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25452; Fri, 13 Jul 90 12:07:29 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 90 11:13:23 PDT Return-Path: Redistributed: CommonLoops.PA Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 13 JUL 90 11:08:48 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA06748; Fri, 13 Jul 90 11:09:24 PDT Message-Id: <9007131809.AA06748@roo.parc.xerox.com> Date: Fri, 13 Jul 90 11:09:24 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: hall@aplcen.apl.jhu.edu Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Marty Hall's message of Fri, 13 Jul 90 09:52:29 EDT <9007131352.AA18884@aplcen.apl.jhu.edu> Subject: Re: List of slots for object? Line-Fold: NO Date: Fri, 13 Jul 90 09:52:29 EDT From: hall@aplcen.apl.jhu.edu (Marty Hall) X-Mailer: Mail User's Shell (6.1 4/26/88) Is there a general (non-PCL specific) way of getting a list of the slots of an object? In PCL you can do (pcl::slots-to-inspect (class-of ) ) In the metaobject protocol, you can do: (class-slots (class-of )) to get a list of slot-definition metaobjects. You can convert that to a list of slot names by doing: (mapcar #'slot-definition-name (class-slots (class-of ))) Most, but not all, CLOS implementations support this part of the metaobject protocol. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26605; Fri, 13 Jul 90 12:55:12 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JUL 90 11:22:08 PDT Return-Path: Redistributed: commonloops.pa Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 13 JUL 90 11:20:46 PDT Received: by atc.boeing.com on Fri, 13 Jul 90 11:20:03 PDT Received: by huntsai.boeing.com (1.2/Ultrix2.0-B) id AA07618; Fri, 13 Jul 90 13:22:55 cdt Date: Fri, 13 Jul 90 13:22:55 cdt From: george@huntsai.boeing.com (George Williams) Message-Id: <9007131822.AA07618@huntsai.boeing.com> To: commonloops.pa@Xerox.COM Subject: Re: Assigning default slot value plus side effects? In a recent submission from hall@aplcen.apl.jhu.edu (Marty Hall): > ... initialize-instance >uses slot-value (not the accessors) for putting values in slots. > ... >Peter Saurugger responded that he didn't think there was any clean >approach, and went on to say: >> >> While the X3JI3 Specs mention the possibility of adding to the existing >> initialization-protocol, the behaviour you describe does not seem to be >> mentioned in this document. >> >> I agree very strongly with you that on initialization I would expect the >> same behaviour as when updating a slot. It seems like one reason why you would _not_ want the initialization protocol to invoke the accessor methods is that these methods frequently depend on the slot being already initialized. E.g., an :after method which increments the slot value after each reference. George Williams Boeing Computer Services Internet: george@huntsai.boeing.com [preferred] POBox 240002, M/S JA-74 UUCP: ...!uunet!uw-beaver!bcsaic!huntsai!george Huntsville AL 35824-6402 Phone: 205+461-2597 BTN: 861-2597 Received: from [13.0.12.232] by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21424; Sat, 14 Jul 90 01:04:38 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 13 JUL 90 11:32:02 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 13 JUL 90 11:29:21 PDT To: Marty Hall Cc: CommonLoops.PA@Xerox.COM Subject: Re: Assigning default slot value plus side effects? In-Reply-To: Your message of Fri, 13 Jul 90 09:41:10 -0400. <9007131341.AA18570@aplcen.apl.jhu.edu> Date: Fri, 13 Jul 90 14:50:47 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900713-113202-9630@Xerox> Redistributed: CommonLoops.PA Date: Fri, 13 Jul 90 09:41:10 EDT From: Marty Hall X-Mailer: Mail User's Shell (6.1 4/26/88) To: CommonLoops.PA@xerox.com Subject: Re: Assigning default slot value plus side effects? I had an application where, there were side effects that needed to occur for all values in a certain slot of a class of objects. I noted that it was obvious how to do this for changed values, by attaching a :after method to (setf ) on the slot, but that I couldn't find a way to make use of default values this way, because initialize-instance uses slot-value (not the accessors) for putting values in slots. Of course, I could write my own initialization function that initializes the object then puts in the values using the accessors, but (being new to clos), I wondered if I had overlooked something clean way of doing it. Peter Saurugger responded that he didn't think there was any clean approach, and went on to say: > > While the X3JI3 Specs mention the possibility of adding to the existing > initialization-protocol, the behaviour you describe does not seem to be > mentioned in this document. > > I agree very strongly with you that on initialization I would expect the > same behaviour as when updating a slot. I do not know whether these specs > still can be amended, but if there is no major reason against this, why > not "vote" on the possibility of an amendment to the behaviour of > shared-initialize ? How does one "vote"? Also, does anyone know the motivation of X3J13 for using slot-value instead of the accessors for initialization? Is there a big efficiency win there? I don't know what all the motivation is, but i can think of 2 reasons for using SLOT-VALUE: 1. Not all slots have accessors, but every slot can be SLOT-VALUE'd. 2. It is certainly much faster to fill the slot, than it its to run the SETF method. Since in most cases, the setf method simply fills the slot every MAKE-INSTANCE would be needlessly slowed down. I vote for using SLOT-VALUE and i'll do the extra work when i need to. MAKE-INSTANCE is already slow enough. The way i usually do this is to put an AFTER method on INITIALIZE-INSTANCE that does the (SETF ). If you really want this for every slot of every class you make, you can write your own metaclass to do SHARED-INITIALIZE using (SETF ) for the slots that have accessors. k Received: from [13.0.12.232] by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22727; Sat, 14 Jul 90 01:15:08 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUL 90 23:48:13 PDT Return-Path: Redistributed: commonLoops.PA Received: from Sun.COM ([192.9.9.1]) by Xerox.COM ; 13 JUL 90 23:47:10 PDT Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10205; Fri, 13 Jul 90 12:28:16 PDT Received: from towser.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09378; Fri, 13 Jul 90 12:28:12 PDT Received: by towser.Eng.Sun.COM (4.0/SMI-4.0) id AA00631; Fri, 13 Jul 90 12:26:56 PDT Date: Fri, 13 Jul 90 12:26:56 PDT From: mcbride@eng.sun.com (Philp McBride) Message-Id: <9007131926.AA00631@towser.Eng.Sun.COM> To: BALL%YALEMED.BITNET@MITVMA.MIT.EDU Cc: commonLoops.PA@Xerox.COM, mcbride@eng.sun.com In-Reply-To: 's message of Thu, 12 Jul 90 19:12 EST <900712-161359-7007@Xerox> Subject: suitability of CLOS for large KB > I recently received a reviewer's comments concerning a manuscript > I submitted describing an application of PCL in the domain of > molecular pathology. In these comments was the criticism "CLOS is > NOT well suited to the development of very large knowledge > bases." Does anyone disagree or should I accept this as > constructive criticism? I would not accept that as constructive criticism. It is very inappropriate for a reviewer at this point in the development of a new language to make such a comment. It can only be subjective at this stage in the development of CLOS. What does the reviewer mean by "not well suited?" If by this comment the reviewer meant that CLOS was not complex enough to handle representing "knowledge," there are a couple of counter arguments. CLOS with its meta-object protocol can be augmented to have some or all of the features of most frame systems. Even, for you "neats" out there, to the point of being compatable with first order logic or with your favorite non-monotonic logic. Another approach would be to use CLOS to implement a knowledge representation system. This has been shown to be quite effective (see Joshua for a Flavors example). If, on the other hand, the reviewer meant that CLOS was not well suited from a performance point of view. There have been no theoretical or computational analysis of why CLOS would perform better or worse than other object oriented systems with very large "knowledge bases." And, since the meta-object protocol gives the user the ability to change the implementation of objects, there are clearly a lot of possibilities for performance. -Philip We are just now seeing the first versions of commercial CLOS implementations. And given that the meta-object protocol of CLOS allows the user to redefine the implementation of object implementations since we are just now seeing a few fully developed CLOS implementations. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02817; Sat, 14 Jul 90 12:01:24 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUL 90 11:22:54 PDT Return-Path: Redistributed: commonLoops.pa Received: from recycle.parc.xerox.com ([13.1.100.189]) by Xerox.COM ; 14 JUL 90 11:22:15 PDT Received: by recycle.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA01102; Sat, 14 Jul 90 11:23:25 PDT Message-Id: <9007141823.AA01102@recycle.parc.xerox.com> Date: Sat, 14 Jul 90 11:23:25 PDT To: commonLoops.pa@Xerox.COM In-Reply-To: Philp McBride's message of Fri, 13 Jul 90 12:26:56 PDT <9007131926.AA00631@towser.Eng.Sun.COM> Subject: Re: suitability of CLOS for large KB From: Larry Masinter Sender: masinter@parc.xerox.com "Not well-suited to" is different from "unsuitable for"; "CLOS" is different from "a KRL built out of CLOS using the meta-object protocol". I imagine that folks who have spent the last decade building elaborate knowledge-representation systems have found use for features in those systems that aren't built into CLOS. Perhaps Common Lisp with CLOS is more suitable for building extensible representation systems than, say, Common Lisp without CLOS (I hope so; it was certainly one of the design goals) but the only CLOS mechanism of inference is inheritance, which certainly isn't enough by itself for most large representation problems. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19943; Tue, 17 Jul 90 01:13:03 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 16 JUL 90 11:39:47 PDT Return-Path: Redistributed: commonloops.pa Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 16 JUL 90 10:51:16 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA26912; Mon, 16 Jul 90 10:51:40 PDT Message-Id: <9007161751.AA26912@roo.parc.xerox.com> Date: Mon, 16 Jul 90 10:51:40 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: riedesel@daneel.den.mmc.com Cc: commonloops.pa@Xerox.COM In-Reply-To: Billy Joel's message of Mon, 16 Jul 90 10:26:27 MDT <9007161626.AA11586@daneel> Subject: Re: defclass options Line-Fold: NO Date: Mon, 16 Jul 90 10:26:27 MDT From: Billy Joel However, I have also been using :accessor-prefix in my classes. This lets me basically use the accessor-prefix for all the slots in my class for both reading and writing instead of having to go and set :reader and :writer on each slot. This option was removed from the language quite some time ago, probably more than two years. It was also removed from PCL. If you are still using it, you must be using a pretty old version of PCL. For full details of why it was removed, you can check the archives on arisia.xerox.com. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20007; Tue, 17 Jul 90 01:19:05 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUL 90 13:33:36 PDT Return-Path: <@tektronix.tek.com:alt@k2.wv.tek.com> Redistributed: CommonLoops.pa Received: from RELAY.CS.NET ([192.31.103.4]) by Xerox.COM ; 16 JUL 90 13:30:55 PDT Received: from tektronix.tek.com by RELAY.CS.NET id aa00199; 16 Jul 90 16:29 EDT Received: by tektronix.TEK.COM (5.51/7.1) id AA01024; Mon, 16 Jul 90 13:30:50 PDT Received: by orca.wv.tek.com (5.51/7.1) id AA20175; Mon, 16 Jul 90 11:44:11 PDT Received: by k2.WV.TEK.COM (5.17/6.24) id AA04843; Mon, 16 Jul 90 11:42:00 PDT From: Al Tabayoyon Message-Id: <9007161842.AA04843@k2.WV.TEK.COM> Date: Mon, 16 Jul 90 11:41:59 PDT To: CommonLoops.pa@Xerox.COM Cc: alt@k2.WV Subject: PCL CLUE documentation notes that a copy of PCL can be obtained from you. Please send me a copy of PCL (version Victoria Day '89 ???). Al Tabayoyon Interactive Technologies Division Tektronix, Inc. Wilsonville Industrial Park P.O. Box 1000, M/S 60-850 Wilsonville, OR 97070-1000 {CS,ARPA}net: alt%orca.wv.tek.com@relay.cs.net Phone: (503) 685-2149 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20106; Tue, 17 Jul 90 01:29:29 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 16 JUL 90 10:13:43 PDT Return-Path: Redistributed: commonloops.pa Received: from mmc.com ([129.243.0.4]) by Xerox.COM ; 16 JUL 90 09:28:37 PDT Received: by mmc.com (netmgr.010490) Return-Path: Received: by den.mmc.com (everest.021690) Received: by daneel.den.mmc.com (daneel.mmc.generic.101389) Date: Mon, 16 Jul 90 10:26:27 MDT From: Billy Joel Message-Id: <9007161626.AA11586@daneel> To: commonloops.pa@Xerox.COM Subject: defclass options I'm a bit confused. In the defclass definition in the SIGPLAN notices (as well as CLTL2ed) there are three clas options: :default-initargs, :documentation and :metaclass. However, I have also been using :accessor-prefix in my classes. This lets me basically use the accessor-prefix for all the slots in my class for both reading and writing instead of having to go and set :reader and :writer on each slot. Is this a non-supported option I am using or what? (Maybe I am missing something in the document I am reading...) Thanks, Joel Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08273; Tue, 17 Jul 90 17:14:05 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 17 JUL 90 16:27:49 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 17 JUL 90 16:20:54 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA14665; Tue, 17 Jul 90 19:20:45 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA25972; Tue, 17 Jul 90 15:38:13 PDT Received: by ox.Franz.COM (4.0/FI-1.0) id AA00404; Tue, 17 Jul 90 15:38:21 PDT Date: Tue, 17 Jul 90 15:38:21 PDT From: jarl@franz.com (Jarl Nilsson) Message-Id: <9007172238.AA00404@ox.Franz.COM> To: riedesel@daneel.den.mmc.com Cc: commonloops.pa@Xerox.COM Subject: Re: defclass options Date: Mon, 16 Jul 90 10:51:40 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: riedesel@daneel.den.mmc.com Subject: Re: defclass options Date: Mon, 16 Jul 90 10:26:27 MDT From: Billy Joel However, I have also been using :accessor-prefix in my classes. This lets me basically use the accessor-prefix for all the slots in my class for both reading and writing instead of having to go and set :reader and :writer on each slot. This option was removed from the language quite some time ago, probably more than two years. It was also removed from PCL. If you are still using it, you must be using a pretty old version of PCL. For full details of why it was removed, you can check the archives on arisia.xerox.com. Just to be clear, the feature still existed in 5/22/89 PCL (Victoria Day). That version is distributed with Allegro CL (because of dependencies with certain add on software - the most recent PCL also works with the current version of Allegro CL). The feature is obsolete and code should be converted to use either :ACCESSOR or :READER and :WRITER on each slot. Note further that accessors are no longer created by default. Therefore, there is nothing for the accessor prefix to be prefixed to. If you specify an accessor (with :ACCESSOR, :READER, or :WRITER) you have to specify a name anyway so you can add your prefix there, if you want. /jarl ____________________________________________________ Jarl Atle Nilsson (home) (415) 524-8110 Franz inc. (work) (415) 548-3600 1995 University ave INTERNET: jarl@franz.com Berkeley, CA 94704 UUCP: uunet!franz!jarl Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17700; Wed, 18 Jul 90 05:17:52 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 18 JUL 90 03:11:40 PDT Return-Path: Redistributed: CommonLoops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 18 JUL 90 03:10:37 PDT Received: by mcsun.EU.net with SMTP; Wed, 18 Jul 90 12:10:34 +0200 (MET) Received: from phigate by hp4nl.nluug.nl with UUCP via EUnet id AA20185 (5.58.1.14/2.14); Wed, 18 Jul 90 12:12:47 MET Received: by philips.nl; Wed, 18 Jul 90 12:07:25 +0200 Received: by philtis.cft.philips.nl; Wed, 18 Jul 90 10:29:46 +0200 From: lcn@philtis.cft.philips.nl (Leo C. Noordhuizen @ Philips CFT Automation/DCC) Message-Id: <9007180829.AA16763@philtis.cft.philips.nl> Subject: CLOS To: CommonLoops.pa@Xerox.COM Date: Wed, 18 Jul 90 10:29:33 MET DST Cc: lcn@philtis.cft.philips.nl (Leo C. Noordhuizen @ Philips CFT Automation/DCC) X-Mailer: ELM [version 2.2 PL0] L.s., I am very interested in getting the CLOS system. Could you please advise me what action I should take to obtain a copy of the sources ? Thanks very much, Kind regards, Leo Noordhuizen Philips - CFT Eindhoven, The Netherlands Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19688; Wed, 18 Jul 90 07:15:42 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 18 JUL 90 07:12:04 PDT Return-Path: <@MCC.COM:loeffler@mcc.com> Redistributed: commonloops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 18 JUL 90 07:09:12 PDT Received: from phoenix.aca.mcc.com by MCC.COM with TCP/SMTP; Wed 18 Jul 90 09:09:09-CDT Date: Wed, 18 Jul 90 09:09:05 CDT From: loeffler@mcc.com (David D. Loeffler) Posted-Date: Wed, 18 Jul 90 09:09:05 CDT Message-Id: <9007181409.AA20655@phoenix.aca.mcc.com> Received: by phoenix.aca.mcc.com (4.0/ACAv4.1i) id AA20655; Wed, 18 Jul 90 09:09:05 CDT To: frants@Neon.Stanford.EDU Cc: commonloops.pa@Xerox.COM In-Reply-To: Leonid Frants's message of Mon, 7 May 90 11:39:16 PDT Subject: Please remove me from this mailing list Reply-To: David D. Loeffler Redistributed: commonloops.pa Date: Mon, 7 May 90 11:39:16 PDT From: Leonid Frants ... Thank you. "clos%eva.slu.se"@forsythe.stanford.edu, You are not on the main distribution list. Look at other redistribution lists at Stanford. Above is one redistribution list for Stanford. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02743; Wed, 18 Jul 90 17:02:05 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 90 16:57:47 PDT Return-Path: Redistributed: CommonLoops.PA Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 18 JUL 90 16:56:43 PDT Received: from newton.arc.nasa.gov by ames.arc.nasa.gov (5.64/1.2); Wed, 18 Jul 90 16:56:32 -0700 Received: by newton.arc.nasa.gov (4.1/SMI-4.0) id AA13688; Wed, 18 Jul 90 16:46:49 PDT Date: Wed, 18 Jul 90 16:46:49 PDT From: eero@newton.arc.nasa.gov (Eero Simoncelli) Message-Id: <9007182346.AA13688@newton.arc.nasa.gov> To: CommonLoops.PA@Xerox.COM Subject: Any plans for a finalize-instance method? Are there any plans to incorporate a "finalize-instance" method (complementing the initialize-instance method) in the CLOS spec? This method would be called after the instance was orphaned (i.e. all references destroyed), but before it was garbage-collected. Obviously, this requires an implementation-dependent hook into the garbage-collection process. This would allow cleanup of allocated foreign or system structures, static data resources, etc. Eero. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23258; Thu, 19 Jul 90 14:19:43 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 90 21:05:02 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 18 JUL 90 21:04:02 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA10524; Wed, 18 Jul 90 23:20:26 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA01432; Wed, 18 Jul 90 20:01:46 PDT Received: by fiona.Franz.COM (4.0/FI-1.0) id AA03985; Wed, 18 Jul 90 20:01:39 PDT Date: Wed, 18 Jul 90 20:01:39 PDT From: smh@franz.com (Steve Haflich) Message-Id: <9007190301.AA03985@fiona.Franz.COM> To: eero@newton.arc.nasa.gov Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Eero Simoncelli's message of Wed, 18 Jul 90 16:46:49 PDT <9007182346.AA13688@newton.arc.nasa.gov> Subject: Any plans for a finalize-instance method? From: eero@newton.arc.nasa.gov (Eero Simoncelli) Are there any plans to incorporate a "finalize-instance" method (complementing the initialize-instance method) in the CLOS spec? This method would be called after the instance was orphaned (i.e. all references destroyed), but before it was garbage-collected. Obviously, this requires an implementation-dependent hook into the garbage-collection process. This would allow cleanup of allocated foreign or system structures, static data resources, etc. Franz's 4.0 release will provide object finalization, as do some other implementations, but I doubt X3J13 would agree to require it in the language spec on two grounds: First, some existing implementations might not be able to provide finalization. The "guidelines" under which X3J13 chose to work are require in lieu of compelling reasons, no languages changes would be adopted that would present insurmountable difficulties for existing implementations. (For example, the features tagged and untagged hardware find easy and difficult are sometimes quite different.) Second, requiring finalization might preclude novel future gc strategies, and it would be contrary to a standardization effort to require features with uncertain implications for future development. By the way, I see no reason to limit finalization to standard instances. It can be defined over all non-immediate objects (i.e., approximately those objects which cannot be identity checked by #'eq.) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25352; Thu, 19 Jul 90 15:09:36 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 19 JUL 90 14:55:27 PDT Return-Path: Redistributed: commonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 19 JUL 90 14:54:32 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA00295g; Thu, 19 Jul 90 14:51:20 PDT Received: by ptl-club id AA07944g; Thu, 19 Jul 90 14:54:41 PDT Date: Thu, 19 Jul 90 14:54:41 PDT From: Jon L White Message-Id: <9007192154.AA07944@ptl-club> To: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Cc: commonLoops.PA@Xerox.COM In-Reply-To: 's message of Thu, 12 Jul 90 19:12 EST <900712-161359-7007@Xerox> Subject: suitability of CLOS for large KB Shel, I've read the responses so far to your quest, and want to add my concurrance to those who say that the critique out of context just isn't specific enough to know what is at the heart of the problem. However, let me give you a hypothetical but very specific criticism of one attempt to implement a database in CLOS. I mean this only as a sample of how specific one would want to be in criticism, rather than to suggest that it applies in your case. Ocasionally, a programmer will distribute some data using class- and EQL- specialization on generic functions, and the volume of such reaches the point where he clearly has a database problem rather than a generic- function one. The use of these CLOS features -- which have a kind of database underlying them -- to circumvent the use of more standard data- basing packages or techniques is surely inappropriate. It is worth noting that EQL specialization isn't even intended to be a replacement for the rather limited kind of "database" tool already found in Common Lisp, namely Hash Tables. I used the term "database" rather than the one you mentioned ("Knowledge Base"); this is to make the hypothetical criticism more clear, and allow for some fuzziness as to what constitutes a "Knowledge Base". Note also that the relative efficiency of generic-function dispatch versus hash-tables or database isn't specifically in question here, although that should be a legitimate area of concern to the programmer. Of course, the judgement of whether or not one is perverting the use of generic-function specialization could vary from reviewer to reviewer. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00802; Mon, 23 Jul 90 19:31:47 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 23 JUL 90 16:12:08 PDT Return-Path: <@RIVERSIDE.SCRC.Symbolics.COM:rsl@MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM> Redistributed: CommonLoops.pa Received: from RIVERSIDE.SCRC.Symbolics.COM ([128.81.41.21]) by Xerox.COM ; 23 JUL 90 16:10:17 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 476615; 23 Jul 90 19:07:29 EDT Date: Mon, 23 Jul 90 09:37 PDT From: Richard Lamson Subject: EQL specializers under Genera To: CommonLoops.pa@Xerox.COM, Moon@symbolics.com Supersedes: <19900719194204.8.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Comments: Retransmission of failed mail. Message-Id: <19900723163753.3.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No The current PCL implementation for Genera doesn't handle EQL specializers correctly. The value of the constant against which to compare the argument is never evaluated. At first I tried fixing this by patching the specializer parser to evaluate the object, but I realized that this has problems getting the environment in which to call EVAL. I adopted a mixed strategy in which the special rewrite of methods continues (it still expands to (DEFUN (PCL:METHOD ,GF-NAME ,@QUALIFIERS ,SPECIALIZERS) ...) but now it also has a call to LOAD-DEFMETHOD at load time; this call was essentially cribbed from the portable copy of EXPAND-DEFMETHOD. Here are the changes: In BOOT.LISP: 1. Make the Genera version of EXPAND-DEFMETHOD expand into DEFUN and a call to LOAD-DEFMETHOD. 2. Remove the special declarations inserted into the method body in the Genera case; these were only needed because LOAD-DEFMETHOD was being called with a couple of arguments derived from these declarations (in EXPAND-DEFMETHOD-INTERNAL). ================================================================= #+Genera (defun expand-defmethod (proto-method name qualifiers lambda-list body env) (when (listp name) (do-standard-defsetf-1 (cadr name))) (multiple-value-bind (fn-form specializers doc plist) (expand-defmethod-internal name qualifiers lambda-list body env) (let ((fn-args (cadadr fn-form)) (fn-body (cddadr fn-form)) (method-name `(method ,name ,@qualifiers ,specializers))) `(progn (defun ,method-name ,fn-args ,@fn-body) (load-defmethod ',(if proto-method (class-name (class-of proto-method)) 'standard-method) ',name ',qualifiers (list ,@(mapcar #'(lambda (specializer) (if (and (consp specializer) (eq (car specializer) 'eql)) ``(eql ,,(cadr specializer)) `',specializer)) specializers)) ',(specialized-lambda-list-lambda-list lambda-list) ',doc ',(getf plist :isl-cache-symbol) ;Paper over a bug in KCL by ;passing the cache-symbol ;here in addition to in the ;plist. ',plist #',method-name))))) (defun expand-defmethod-internal (generic-function-name qualifiers specialized-lambda-list body env) (declare (values fn-form specializers doc) (ignore qualifiers)) (when (listp generic-function-name) (do-standard-defsetf-1 (cadr generic-function-name))) (multiple-value-bind (documentation declarations real-body) (extract-declarations body) (multiple-value-bind (parameters lambda-list specializers) (parse-specialized-lambda-list specialized-lambda-list) (let* ((required-parameters (mapcar #'(lambda (r s) (declare (ignore s)) r) parameters specializers)) (parameters-to-reference (make-parameter-references specialized-lambda-list required-parameters declarations generic-function-name specializers)) (class-declarations `(declare ,@(remove nil (mapcar #'(lambda (a s) (and (symbolp s) (neq s 't) `(class ,a ,s))) parameters specializers)))) (method-lambda ;; Remove the documentation string and insert the ;; appropriate class declarations. The documentation ;; string is removed to make it easy for us to insert ;; new declarations later, they will just go after the ;; cadr of the method lambda. The class declarations ;; are inserted to communicate the class of the method's ;; arguments to the code walk. (let () `(lambda ,lambda-list ,class-declarations ,@declarations (progn ,@parameters-to-reference) (block ,(if (listp generic-function-name) (cadr generic-function-name) generic-function-name) ,@real-body)))) (call-next-method-p nil) ;flag indicating that call-next-method ;should be in the method definition (next-method-p-p nil) ;flag indicating that next-method-p ;should be in the method definition (save-original-args nil) ;flag indicating whether or not the ;original arguments to the method ;must be preserved. This happens ;for two reasons: ; - the method takes &mumble args, ; so one of the lexical functions ; might be used in a default value ; form ; - call-next-method is used without ; arguments at least once in the ; body of the method (original-args ()) (applyp nil) ;flag indicating whether or not the ;method takes &mumble arguments. If ;it does, it means call-next-method ;without arguments must be APPLY'd ;to original-args. If this gets set ;true, save-original-args is set so ;as well (aux-bindings ()) ;Suffice to say that &aux is one of ;damndest things to have put in a ;language. (slots (mapcar #'list required-parameters)) (plist ()) (walked-lambda nil)) (flet ((walk-function (form context env) (cond ((not (eq context ':eval)) form) ((not (listp form)) form) ((eq (car form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args (not (cdr form))) form) ((eq (car form) 'next-method-p) (setq next-method-p-p 't) form) ((and (eq (car form) 'function) (cond ((eq (cadr form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args 't) form) ((eq (cadr form) 'next-method-p) (setq next-method-p-p 't) form) (t nil)))) ((and (or (eq (car form) 'slot-value) (eq (car form) 'set-slot-value)) (symbolp (cadr form)) (constantp (caddr form))) (let ((parameter (can-optimize-access (cadr form) required-parameters env))) (if (null parameter) form (ecase (car form) (slot-value (optimize-slot-value slots parameter form)) (set-slot-value (optimize-set-slot-value slots parameter form)))))) (t form)))) (setq walked-lambda (walk-form method-lambda env #'walk-function)) ;; ;; Add &allow-other-keys to the lambda list as an interim ;; way of implementing lambda list congruence rules. ;; (when (and (memq '&key lambda-list) (not (memq '&allow-other-keys lambda-list))) (let* ((rll (reverse lambda-list)) (aux (memq '&aux rll))) (setq lambda-list (if aux (progn (setf (cdr aux) (cons '&allow-other-keys (cdr aux))) (nreverse rll)) (nconc (nreverse rll) (list '&allow-other-keys)))))) ;; Scan the lambda list to determine whether this method ;; takes &mumble arguments. If it does, we set applyp and ;; save-original-args true. ;; ;; This is also the place where we construct the original ;; arguments lambda list if there has to be one. (dolist (p lambda-list) (if (memq p lambda-list-keywords) (if (eq p '&aux) (progn (setq aux-bindings (cdr (memq '&aux lambda-list))) (return nil)) (progn (setq applyp t save-original-args t) (push '&rest original-args) (push (make-symbol "AMPERSAND-ARGS") original-args) (return nil))) (push (make-symbol (symbol-name p)) original-args))) (setq original-args (if save-original-args (nreverse original-args) ())) (multiple-value-bind (ignore walked-declarations walked-lambda-body) (extract-declarations (cddr walked-lambda)) (declare (ignore ignore)) (when (some #'cdr slots) (setq slots (slot-name-lists-from-slots slots)) (setq plist (list* :isl slots plist)) (setq walked-lambda-body (add-pv-binding walked-lambda-body plist required-parameters)) (dolist (dcl-stm walked-declarations) (dolist (dcl (cdr dcl-stm)) (when (eql (car dcl) 'ignore) (setf (cdr dcl) (set-difference (cdr dcl) required-parameters)))))) (when (or next-method-p-p call-next-method-p) (setq plist (list* :needs-next-methods-p 't plist))) ;;; changes are here... (mt) (let ((fn-body (if (or call-next-method-p next-method-p-p) (add-lexical-functions-to-method-lambda walked-declarations walked-lambda-body `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body) original-args lambda-list save-original-args applyp aux-bindings call-next-method-p next-method-p-p) `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body)))) ; #+Genera ; (setq fn-body `(lambda ,(cadr fn-body) ; (declare (pcl-documentation ,documentation) ; (pcl-plist ,plist)) ; ,@(cddr fn-body))) ; (values `(function ,fn-body) specializers documentation plist)))))))) ================================================================= In GENERA-LOW.LISP: Remove the call to PCL-FDEFINE-HELPER and the one lexical variable bound only for the call to it; this function is no longer in use and can be removed. You still need the function-spec handler and the hash table because LOAD-DEFMETHOD is still called with #'(PCL:METHOD ...) at load time. ================================================================= (si:define-function-spec-handler method (op spec &optional arg1 arg2) (if (eq op 'sys:validate-function-spec) (and (let ((gspec (cadr spec))) (or (symbolp gspec) (and (listp gspec) (eq (car gspec) 'setf) (symbolp (cadr gspec)) (null (cddr gspec))))) (let ((tail (cddr spec))) (loop (cond ((null tail) (return nil)) ((listp (car tail)) (return t)) ((atom (pop tail))) (t (return nil)))))) (let ((table *method-htable*) (key spec)) (case op ((si:fdefinedp si:fdefinition) (car (gethash key table nil))) (si:fundefine (remhash key table)) (si:fdefine (let ((old (gethash key table nil)) ; (gspec (cadr spec)) (quals nil) (specs nil) (ptr (cddr spec))) (setq specs (loop (cond ((null ptr) (return nil)) ((listp (car ptr)) (return (car ptr))) (t (push (pop ptr) quals))))) ; (pcl-fdefine-helper gspec (nreverse quals) specs arg1) (setf (gethash key table) (cons arg1 (cdr old))))) (si:get (let ((old (gethash key table nil))) (getf (cdr old) arg1))) (si:plist (let ((old (gethash key table nil))) (cdr old))) (si:putprop (let ((old (gethash key table nil))) (unless old (setf old (cons nil nil)) (setf (gethash key table) old)) (setf (getf (cdr old) arg2) arg1))) (si:remprop (let ((old (gethash key table nil))) (when old (remf (cdr old) arg1)))) (otherwise (si:function-spec-default-handler op spec arg1 arg2)))))) ================================================================= Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00185; Fri, 27 Jul 90 17:12:40 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 90 16:08:05 PDT Return-Path: Redistributed: commonloops.pa Received: from elsinore.parc.xerox.com ([13.2.16.5]) by Xerox.COM ; 27 JUL 90 16:07:12 PDT Received: by elsinore.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA00381; Fri, 27 Jul 90 16:07:24 PDT Message-Id: <9007272307.AA00381@elsinore.parc.xerox.com> Date: Fri, 27 Jul 90 16:07:24 PDT From: Doug Cutting To: commonloops.pa@Xerox.COM Subject: optimizations for CALL-NEXT-METHOD Cc: cutting@parc.xerox.com CALL-NEXT-METHOD is currently implemented with FLET. The locally defined function refers lexically to the next method to be executed and to the list of remaining methods. This must be done to allow for methods which take advantage of CALL-NEXT-METHOD's indefinite extent, e.g. by returning #'CALL-NEXT-METHOD. Thus in some unusual cases a closure must actually be created. Unfortunately some compilers (e.g. Franz 3.1 & Lucid's development compiler) do not optimize the common case where a closure need not be created. For those who prefer code to prose: PCL wraps method bodies which refer to CALL-NEXT-METHOD with code that looks something like: (lambda (#:arg1 #:arg2) (let ((.next-method. (car *next-methods*)) (.next-methods. (cdr *next-method*))) (flet ((call-next-method () (if .next-method. (let ((*next-methods* .next-methods.)) (funcall .next-method. #:arg1 #:arg2)) (error "No next method.")))) (let ((arg1 #:arg1) (arg2 #:arg2)) ... body containing (CALL-NEXT-METHOD) ...)))) With many compilers every call to this method results in the creation of closures (over #:arg1 and #:arg2, and over .next-method. and .next-methods.). Not only is this slow, it's also consy. Until these compilers get smarter one can use the patch below, which has PCL perform the optimization for a few common cases. The trick is to use MACROLET in place of FLET when feasable. This renders the above fragment as: (lambda (#:arg1 #:arg2) (let ((.next-method. (car *next-methods*)) (.next-methods. (cdr *next-methods*))) (macrolet ((call-next-method () '(if .next-method. (let ((*next-methods* .next-methods.)) (funcall .next-method. #:arg1 #:arg2)) (error "No next method.")))) (let ((arg1 #:arg1) (arg2 #:arg2)) ... body containing (CALL-NEXT-METHOD) ...)))) I've tested this with May Day PCL and achieved an 8x speedup in Franz Allegro 3.1.13 for a CALL-NEXT-METHOD benchmark. If I don't recieve any complaints about this I'll merge it into the PCL sources on arisia.xerox.com. It implements the above optimization for methods without any optional arguments which call CALL-NEXT-METHOD with or without arguments. There are intermediate cases which could be optimized and are still not, e.g. when a method body contains both (CALL-NEXT-METHOD) and #'CALL-NEXT-METHOD, or when #'CALL-NEXT-METHOD has only dynamic extent, as in the case where it's the first arg to MAPCAR. The only disadvantage is that the code size of methods which invoke CALL-NEXT-METHOD in more than one place may grow somewhat. (Xerox users: This patch has been installed in /import/pcl/next.) All the changes are confined to boot.lisp: 345a346,347 > (closurep nil) ;flag indicating that #'call-next-method > ;was seen in the body of a method 378c380,381 < (setq save-original-args (not (cdr form))) --- > (unless (cdr form) > (setq save-original-args t)) 386a390 > (setq closurep t) 389a394 > (setq closurep t) 474c479,480 < next-method-p-p) --- > next-method-p-p > closurep) 499,500c505,544 < next-method-p-p) < (cond ((and (null save-original-args) --- > next-method-p-p > closurep) > (cond ((and (null closurep) > (null applyp) > (null save-original-args)) > ;; OK to use MACROLET, CALL-NEXT-METHOD is always passed some args, and > ;; all args are mandatory (else APPLYP would be true). > `(lambda ,lambda-list > ,@walked-declarations > (let ((.next-method. (car *next-methods*)) > (.next-methods. (cdr *next-methods*))) > (macrolet ((call-next-method ,lambda-list > '(if .next-method. > (let ((*next-methods* .next-methods.)) > (funcall .next-method. ,@lambda-list)) > (error "No next method."))) > (next-method-p () `(not (null .next-method.)))) > ,@walked-lambda-body)))) > ((and (null closurep) > (null applyp) > save-original-args) > ;; OK to use MACROLET. CALL-NEXT-METHOD is sometimes called in the > ;; body with zero args, so we have to save the original args. > (if save-original-args > ;; CALL-NEXT-METHOD is sometimes called with no args > `(lambda ,original-args > (let ((.next-method. (car *next-methods*)) > (.next-methods. (cdr *next-methods*))) > (macrolet ((call-next-method (&rest cnm-args) > `(if .next-method. > (let ((*next-methods* .next-methods.)) > (funcall .next-method. > ,@(if cnm-args cnm-args ',original-args))) > (error "No next method."))) > (next-method-p () `(not (null .next-method.)))) > (let* (,@(mapcar #'list lambda-list original-args) > ,@aux-bindings) > ,@walked-declarations > ,@walked-lambda-body)))))) > ((and (null save-original-args) Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28612; Sun, 29 Jul 90 12:41:40 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Sun 29 Jul 90 14:29:31-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 29 Jul 90 12:27:46 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA10633; Sun, 29 Jul 90 12:29:17 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA01587; Sun, 29 Jul 90 12:28:45 pdt Message-Id: <9007291928.AA01587@hplap.hpl.hp.com> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Update on Third CLOS Users and Implementors Workshop X-Mailer: mh6.5 Date: Sun, 29 Jul 90 12:28:36 PDT From: Andreas Paepcke I don't know how well the OOPSLA information dissemination machinery works. So here is a repeat of the original call for participation in this year's CLOS Workshop and a bit of update information: The day of the Workshop is now set: The Games will commence on Sunday, Oct. 21 '90 in the context of OOPSLA in Ottawa I attach the original summons of the gladiators for your convenience. Several of you have asked for an extension, partly due to AAAI. Please let me know if you have had trouble with something like this as well. For those of you who are interested in attending, please let me know your expectations to help me plan the agenda details successfully. Which information do you minimally want to take home with you? Would you like to hear a particular person speak? Do you like presentations to guide discussions or are you into free-style wrestling? (Be warned that there will be metal detectors at the door). Do you have particular discussion topics on your mind? Please drop me a note. Looking forward, Andreas ;;;;;;;;;;;;;;;;;;;; Original Call for Participation ;;;;;;;;;;;;;;; Third CLOS Users and Implementor's Workshop 1990 `Now What?' The first CLOS Workshop in 1988 was organized to bring the CLOS community together and to make known which areas were being addressed in university and industrial centers. The 1989 Workshop was dominated by introspection, the examination of issues important at the time. CLOS has now matured to a point where it is time to take stock and to understand what should happen next. One goal will need to be the projection of CLOS out into the community. An obviously important component of this is the organization and publication of projects that use CLOS. A second component must be a clarification of what is still missing and how CLOS should be improved or completed. A third component, finally, is reflection on how the language has advanced the state of the art or has a potential for doing this. This year's Workshop is to serve a dual purpose. The first is to let us touch bases to learn what has been happening in the CLOS community and what is to be done next. The second is to provide material and direction for the "CLOS Report", a publication that will highlight the many facets of the language and its history. This will be a collection of full length papers to be published some time after the Workshop. We hope that our meeting and its associated short papers can draw attention to contributions that should make their way into such a collection. The format of the Workshop reflects these two goals. We will try to divide the day into three units. The first will be a critical look back to where we have been. We will try to identify, collect and evaluate decisions we made to ensure that we learn all we can from CLOS' rich, hectic history. This could involve an analysis of what worked well and what went wrong. It would also be useful simply to spell out which constraints led to particular decisions and whether our resolutions were meaningful. The second unit will be an attempt to compile a representative list of projects which use CLOS for various purposes. Our goal will be to assemble a portfolio of projects that illuminate different aspects of the language. These could, for instance, include the metaobject protocol, CLOS' approach to inheritance, method combination or other issues. Emphasis will be on broad coverage. The third unit, finally, will attempt to produce a roadmap, or at least a series of mile stones to identify what needs to happen during the next two or three years and how it could be achieved. The hope is that this unit will profit from the review and survey of the first two units. To get units one and three started we plan to invite two speakers each, who will present opposing, controversial views of ten minutes each. Afterwards, we will turn to plenum discussion. The Workshop logistics will follow OOPSLA ACM guidelines. Attendance will have to be limited to 30 contributors. Each contributor will need to submit a short position paper of two to five pages. Each paper should be classified to indicate which of the three units the paper addresses: 1. Looking back 2. Taking stock 3. Future needs To summarize: The `looking back' unit has the purpose of isolating what we learned. The `taking stock' unit is to produce a portfolio of projects that highlight different aspects of the language. The `future needs' unit should try to clarify what needs to be done next. Papers may include compilations of issues, provocative questions or hypotheses which can be used to stimulate and guide discussion in particular areas. The papers will be reviewed, and up to 30 of them will be selected for inclusion in the Workshop. We will try to have these papers bound and mailed to participants before OOPSLA to make the Workshop as efficient as possible. Please submit five copies of your papers by August 1 1990 to: Andreas Paepcke Hewlett-Packard Laboratory 1501 Page Mill Rd. Palo Alto, Ca. 94304-1126 paepcke@hplabs.hp.com Tel: 415-857-7398 Fax: 415-857-8526 We also welcome suggestions for the Workshop format, suggestions for speakers or other feedback that will help make our Workshop a success. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23921; Mon, 30 Jul 90 15:01:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 30 JUL 90 08:10:21 PDT Return-Path: <@tektronix.tek.com:alt@k2.wv.tek.com> Redistributed: CommonLoops.pa Received: from RELAY.CS.NET ([192.31.103.4]) by Xerox.COM ; 30 JUL 90 08:05:01 PDT Received: from tektronix.tek.com by RELAY.CS.NET id aa15132; 30 Jul 90 11:05 EDT Received: by tektronix.TEK.COM (5.51/7.1) id AA07255; Mon, 30 Jul 90 08:05:23 PDT Received: by orca.wv.tek.com (5.51/7.1) id AA10115; Mon, 30 Jul 90 08:02:30 PDT Received: by k2.WV.TEK.COM (5.17/6.24) id AA21935; Mon, 30 Jul 90 07:59:10 PDT From: Al Tabayoyon Message-Id: <9007301459.AA21935@k2.WV.TEK.COM> Date: Mon, 30 Jul 90 07:59:09 PDT To: CommonLoops.pa@Xerox.COM Cc: alt@k2.WV Subject: Problems building PCL I sent the following to bug@Franz hoping they had an answer but have yet to receive a reply. Perhaps you can help me with my problem. Thanks, Al Tabayoyon ------------------------------------------------------------------------ LISP IMPLEMENTATION DETAILS: =========================== LISP-IMPLEMENTATION-TYPE: Allegro CL LISP-IMPLEMENTATION-VERSION: 3.0.1 [tek4300] (4/27/90 9:16) MACHINE-TYPE: Tektronix 4300 MACHINE-VERSION: SOFTWARE-TYPE: Utek (UTek 4.1) SOFTWARE-VERSION: SHORT-SITE-NAME: k2 *features* is (:CLX-CL-ERROR :CLX-MIT-R4 :XLIB :CLX :MULTIPROCESSING :UNIX :TEKCL :TEKTRONIX :TEK4300 :ALLEGRO :ALLEGRO-V3.0 :COMMON-LISP :EXCL :FRANZ-INC :GSGC) USER INFORMATION: =========================== Al Tabayoyon Interactive Technologies Division Tektronix, Inc. Wilsonville Industrial Park P.O. Box 1000, M/S 60-850 Wilsonville, OR 97070-1000 {CS,ARPA}net: alt%orca.wv.tek.com@relay.cs.net Phone: (503) 685-2149 4300P33 Tek Common Lisp Version 3.0.1 Serial Number B020140 PROBLEM DESCRIPTION: =========================== When attempting to build the "5/1/90 May Day PCL (REV 2)" version of PCL that I obtained via anonymous FTP from Xerox, I run into problems with two files, "cpatch.cl" and quadlap.cl". This version of PCL should work with Allegro CL version 3.0.1. Have you run into these problems? Am I really missing a package? What do I need to do to continue. --------- cpatch.cl ;; -[Thu Feb 22 08:38:07 1990 by jkf]- --------- Compiling CPATCH... ; --- Compiling file /usr/lib/cl/pcl/cpatch.cl --- Warning: Symbol TAIL-FUNCALL declared special Warning: Symbol QP-END-BLOCK declared special Error: Attempt to take the value of the unbound symbol R-FUNCTION-START-ADJ --------- quadlap.cl ;; $Header: quadlap.cl,v 1.1 90/02/21 08:54:42 jkf Exp Locker: jkf $ --------- Compiling QUADLAP... ; --- Compiling file /usr/lib/cl/pcl/quadlap.cl --- ; Compiling PCL-MAKE-LAMBDA ; Compiling PCL-MAKE-VARREC ; Compiling PCL-MAKE-LAP ; Compiling MAKE-PREG ; Compiling PREG-P ; Compiling PCL::EXCL-LAP-CLOSURE-GENERATOR Error: Package "R" not found. [file position = 4935] Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02469; Tue, 31 Jul 90 11:29:47 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 31 Jul 90 13:27:43-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 827729; 31 Jul 90 14:27:10 EDT Date: Tue, 31 Jul 90 14:31 EDT From: David A. Moon Subject: FYI: a metaobject extension To: Jon L White Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: <9006220029.AA09249@ptl-club> Message-Id: <19900731183118.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Thu, 21 Jun 90 17:29:25 PDT From: Jon L White re: By the way, although it's not really part of this, in the same project I also had to extend DEFMETHOD to allow a parameter specializer name to be a class rather than a class name. This was necessary because not all classes have names. This was the only place in CLOS I could find where a class object cannot be used where a class name is accepted, so I think it's an inconsistency and would propose to change it if the CLOS language were not stable. That looks like a bug/oversight in the documentation of CLOS. Can't we just agree that that's what was originally meant? There have been no answers to this after a month, so I guess that proves we can't agree. I myself would like to see the change, but am unwilling to disrupt the fragile X3J13 process by proposing it. I do note that CLIM depends on this feature in four Common Lisp implementations (in each of them it was either already present or trivial to add). Of course when I say "CLIM" you have to ask "which version?" Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06591; Tue, 31 Jul 90 14:32:51 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Tue 31 Jul 90 16:29:41-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16131>; Tue, 31 Jul 1990 14:31:08 PDT Received: by spade.parc.xerox.com id <167>; Tue, 31 Jul 1990 14:29:20 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: jonl@lucid.com, Common-Lisp-Object-System@mcc.com In-Reply-To: David A. Moon's message of Tue, 31 Jul 90 14:31 EDT <19900731183118.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: FYI: a metaobject extension Line-Fold: NO Message-Id: <90Jul31.142920pdt.167@spade.parc.xerox.com> Date: Tue, 31 Jul 1990 14:29:20 PDT Date: Thu, 21 Jun 90 17:29:25 PDT From: Jon L White That looks like a bug/oversight in the documentation of CLOS. Can't we just agree that that's what was originally meant? Date: Tue, 31 Jul 90 14:31 EDT From: David A. Moon There have been no answers to this after a month, so I guess that proves we can't agree. I myself would like to see the change, but am unwilling to disrupt the fragile X3J13 process by proposing it. I do note that CLIM depends on this feature in four Common Lisp implementations (in each of them it was either already present or trivial to add). Of course when I say "CLIM" you have to ask "which version?" This has been on my list of messages to try and reply to. I was hoping to find time to write a thoughtful and detailed reply. Barring that here is a shorter comment. I don't think this a good feature to add, and I don't think that I could possibly construe it as `what we originally meant'. I believe this feature flies in the face of the name/metaobject separation we worked so hard to get right. I also believe that this name/metaobject separation is one of the significant contributions of CLOS to the world of Lisp-based OOLs, so it is important to keep it right. I believe that the proper way to do this is by making a method object and calling add-method. Yes, its true that Chapter 3 isn't an official standard, but certainly within your own implementation you could have done that, and CLIM could do it as well. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11069; Wed, 1 Aug 90 01:52:01 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 31 JUL 90 11:21:30 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.176.66]) by Xerox.COM ; 31 JUL 90 11:11:54 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA10633; Sun, 29 Jul 90 12:29:17 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA01587; Sun, 29 Jul 90 12:28:45 pdt Message-Id: <9007291928.AA01587@hplap.hpl.hp.com> To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Update on Third CLOS Users and Implementors Workshop X-Mailer: mh6.5 Date: Sun, 29 Jul 90 12:28:36 PDT From: Andreas Paepcke I don't know how well the OOPSLA information dissemination machinery works. So here is a repeat of the original call for participation in this year's CLOS Workshop and a bit of update information: The day of the Workshop is now set: The Games will commence on Sunday, Oct. 21 '90 in the context of OOPSLA in Ottawa I attach the original summons of the gladiators for your convenience. Several of you have asked for an extension, partly due to AAAI. Please let me know if you have had trouble with something like this as well. For those of you who are interested in attending, please let me know your expectations to help me plan the agenda details successfully. Which information do you minimally want to take home with you? Would you like to hear a particular person speak? Do you like presentations to guide discussions or are you into free-style wrestling? (Be warned that there will be metal detectors at the door). Do you have particular discussion topics on your mind? Please drop me a note. Looking forward, Andreas ;;;;;;;;;;;;;;;;;;;; Original Call for Participation ;;;;;;;;;;;;;;; Third CLOS Users and Implementor's Workshop 1990 `Now What?' The first CLOS Workshop in 1988 was organized to bring the CLOS community together and to make known which areas were being addressed in university and industrial centers. The 1989 Workshop was dominated by introspection, the examination of issues important at the time. CLOS has now matured to a point where it is time to take stock and to understand what should happen next. One goal will need to be the projection of CLOS out into the community. An obviously important component of this is the organization and publication of projects that use CLOS. A second component must be a clarification of what is still missing and how CLOS should be improved or completed. A third component, finally, is reflection on how the language has advanced the state of the art or has a potential for doing this. This year's Workshop is to serve a dual purpose. The first is to let us touch bases to learn what has been happening in the CLOS community and what is to be done next. The second is to provide material and direction for the "CLOS Report", a publication that will highlight the many facets of the language and its history. This will be a collection of full length papers to be published some time after the Workshop. We hope that our meeting and its associated short papers can draw attention to contributions that should make their way into such a collection. The format of the Workshop reflects these two goals. We will try to divide the day into three units. The first will be a critical look back to where we have been. We will try to identify, collect and evaluate decisions we made to ensure that we learn all we can from CLOS' rich, hectic history. This could involve an analysis of what worked well and what went wrong. It would also be useful simply to spell out which constraints led to particular decisions and whether our resolutions were meaningful. The second unit will be an attempt to compile a representative list of projects which use CLOS for various purposes. Our goal will be to assemble a portfolio of projects that illuminate different aspects of the language. These could, for instance, include the metaobject protocol, CLOS' approach to inheritance, method combination or other issues. Emphasis will be on broad coverage. The third unit, finally, will attempt to produce a roadmap, or at least a series of mile stones to identify what needs to happen during the next two or three years and how it could be achieved. The hope is that this unit will profit from the review and survey of the first two units. To get units one and three started we plan to invite two speakers each, who will present opposing, controversial views of ten minutes each. Afterwards, we will turn to plenum discussion. The Workshop logistics will follow OOPSLA ACM guidelines. Attendance will have to be limited to 30 contributors. Each contributor will need to submit a short position paper of two to five pages. Each paper should be classified to indicate which of the three units the paper addresses: 1. Looking back 2. Taking stock 3. Future needs To summarize: The `looking back' unit has the purpose of isolating what we learned. The `taking stock' unit is to produce a portfolio of projects that highlight different aspects of the language. The `future needs' unit should try to clarify what needs to be done next. Papers may include compilations of issues, provocative questions or hypotheses which can be used to stimulate and guide discussion in particular areas. The papers will be reviewed, and up to 30 of them will be selected for inclusion in the Workshop. We will try to have these papers bound and mailed to participants before OOPSLA to make the Workshop as efficient as possible. Please submit five copies of your papers by August 1 1990 to: Andreas Paepcke Hewlett-Packard Laboratory 1501 Page Mill Rd. Palo Alto, Ca. 94304-1126 paepcke@hplabs.hp.com Tel: 415-857-7398 Fax: 415-857-8526 We also welcome suggestions for the Workshop format, suggestions for speakers or other feedback that will help make our Workshop a success. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12124; Wed, 1 Aug 90 02:09:16 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 31 JUL 90 02:27:27 PDT Return-Path: <@RIVERSIDE.SCRC.Symbolics.COM:rsl@MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM> Redistributed: CommonLoops.pa Received: from RIVERSIDE.SCRC.Symbolics.COM ([128.81.41.21]) by Xerox.COM ; 31 JUL 90 02:25:32 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 479923; 30 Jul 90 19:32:50 EDT Date: Mon, 30 Jul 90 15:33 PDT From: Richard Lamson Subject: More bugs in PCL To: CommonLoops.pa@Xerox.COM Cc: rsl@max-fleischer.ila-sf.dialnet.symbolics.com Message-Id: <19900730223326.9.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No PCL calls NO-APPLICABLE-METHOD incorrectly; it passes the arguments to the generic function as the second argument rather than as a rest argument. I have made a set of changes which fixes this, included below. In addition, I made NO-APPLICABLE-METHOD use CERROR to signal the error; the restart applies the generic function to the same arguments (which is why I had to fix the problem with calling NO-APPLICABLE-METHOD incorrectly). Also, I added "#+Genera (declare (dbg:invisible-frame :pcl-internals))" to a number of functions so they don't appear in backtraces unless specifically requested under Genera. You can request invisible frames in stack movement with control-meta-N, and c-m-P, and can see them in backtraces with c-m-B. You can also push :PCL-INTERNALS onto the list DBG:*INVISIBLE-FRAME-TYPES-TO-SHOW* if you're debugging PCL. I also fixed the problem with PCL EQL method dispatches; it turned out that the problem was that at load time the "constant" in the EQL method definition was not getting evaluated, so the constant needed to be EQL to '(QUOTE FOO) instead of 'FOO. Also, DEFMETHOD was not telling the compiler that the generic function was a function, which was causing the compiler to issue spurious warnings about calling functions which were not defined. I added a #+Genera clause to SETFBOUNDP. Finally, Dave Linden (DCPL@ILA.Dialnet.Symbolics.COM) fixed a bug in the walker handler for PROG/PROG*. It was not possible to walk over a PROG which had a block name, which some Genera macro was generating. There is one remaining really irritating bug, which is that DEFCONSTRUCTOR causes a warning that the function involved was defined twice when the file is loaded. This is because DEFCONSTRUCTOR expands into (progn (defun (&rest ignore) (error "Constructor not loaded")) (something-which-actually-defines-constructor)) That first subform should really be (proclaim '(function )) or equivalent. I will probably be providing such a patch soon if I can figure out how to make it work in the Franz environment we are also using. ================================================================= Here is a copy of my PCL-PATCHES file. ;;; -*- Mode: LISP; Syntax: Common-lisp; Package: PCL; Base: 10; Patch-File: T -*- (in-package 'pcl) (pushnew ':pcl-internals dbg:*all-invisible-frame-types*) ;;; From FIN.LISP: ;;; ;;; The inner closure of this function will have its code vector replaced ;;; by a hand-coded fast jump to the function that is stored in the ;;; captured-lexical variable. In effect, that code is a hand- ;;; optimized version of the code for this inner closure function. ;;; (defun make-trampoline (function) (declare (optimize (speed 3) (safety 0))) #'(lambda (&rest args) #+Genera (declare (dbg:invisible-frame :pcl-internals)) (apply function args))) ;;; From METHODS.LISP: (defmacro protect-cache-miss-code (gf args &body body) (let ((function (gensym)) (appl (gensym))) (once-only (gf args) `(if (memq ,gf *invalid-dfuns-on-stack*) (multiple-value-bind (,function ,appl) (get-secondary-dispatch-function ,gf ,args) (if (null ,appl) (apply #'no-applicable-method ,gf ,args) (apply ,function ,args))) (let ((*invalid-dfuns-on-stack* (cons ,gf *invalid-dfuns-on-stack*))) ,@body))))) (defmethod no-applicable-method (generic-function &rest args) (cerror "Retry call to ~S" "No matching method for the generic-function ~S,~@ when called with arguments ~S." generic-function args) (let ((*invalid-dfuns-on-stack* (remove generic-function *invalid-dfuns-on-stack*))) (invalidate-discriminating-function generic-function) (apply generic-function args))) ;;; From DFUN.LISP: (defun make-initial-dfun (generic-function) #'(lambda (&rest args) #+Genera (declare (dbg:invisible-frame :pcl-internals)) (initial-dfun args generic-function))) (defun invalidate-dfun-internal (generic-function) ;; ;; Set the funcallable instance function to something that just calls ;; invalid-dfun, that is, arrange to use lazy evaluation to update the ;; dfun later. ;; (set-funcallable-instance-function generic-function #'(lambda (&rest args) #+Genera (declare (dbg:invisible-frame :pcl-internals)) (invalid-dfun generic-function args))) ;; ;; Except that during bootstrapping, we would like to update the dfun ;; right away, and this arranges for that. ;; (when *invalidate-discriminating-function-force-p* (let ((*invalid-dfuns-on-stack* (cons generic-function *invalid-dfuns-on-stack*))) (set-funcallable-instance-function generic-function (compute-discriminating-function generic-function))))) (defun invalid-dfun (gf args) #+Genera (declare (dbg:invisible-frame :pcl-internals)) (protect-cache-miss-code gf args (let ((new-dfun (compute-discriminating-function gf))) (set-funcallable-instance-function gf new-dfun) (apply gf args)))) (defun accessor-miss (gf ostate otype new object oindex ow0 ow1 field cache) (declare (ignore ow1)) (let ((args (ecase otype ;The congruence rules assure (reader (list object)) ;us that this is safe despite (writer (list new object))))) ;not knowing the new type yet. (protect-cache-miss-code gf args (multiple-value-bind (wrappers invalidp nfunction applicable) (cache-miss-values gf args) (multiple-value-bind (ntype nindex) (accessor-miss-values gf applicable args) ;; ;; The following lexical functions change the state of the ;; dfun to that which is their name. They accept arguments ;; which are the parameters of the new state, and get other ;; information from the lexical variables bound above. ;; (flet ((two-class (index w0 w1) (when (zerop (random 2)) (psetf w0 w1 w1 w0)) (ecase ntype (reader (update-to-two-class-readers-dfun gf w0 w1 index)) (writer (update-to-two-class-writers-dfun gf w0 w1 index)) )) (one-index (index &optional field cache) (ecase ntype (reader (update-to-one-index-readers-dfun gf index field cache)) (writer (update-to-one-index-writers-dfun gf index field cache)) )) (n-n (&optional field cache) (ecase ntype (reader (update-to-n-n-readers-dfun gf field cache)) (writer (update-to-n-n-writers-dfun gf field cache)))) (checking () (update-to-checking-dfun gf nfunction)) ;; ;; ;; (do-fill (valuep limit-fn update-fn) (multiple-value-bind (nfield ncache) (fill-cache field cache 1 valuep limit-fn wrappers nindex) (unless (and (= nfield field) (eq ncache cache)) (funcall update-fn nfield ncache))))) (cond ((null nfunction) (apply #'no-applicable-method gf args)) ((null ntype) (checking) (apply nfunction args)) ((or invalidp (null nindex)) (apply nfunction args)) ((not (or (std-instance-p object) (fsc-instance-p object))) (checking) (apply nfunction args)) ((neq ntype otype) (checking) (apply nfunction args)) (t (ecase ostate (one-class (if (eql nindex oindex) (two-class nindex ow0 wrappers) (n-n))) (two-class (if (eql nindex oindex) (one-index nindex) (n-n))) (one-index (if (eql nindex oindex) (do-fill nil #'one-index-limit-fn #'(lambda (nfield ncache) (one-index nindex nfield ncache))) (n-n))) (n-n (unless (consp nindex) (do-fill t #'n-n-accessors-limit-fn #'n-n)))) (apply nfunction args))))))))) (defun checking-miss (generic-function args ofunction field cache) (protect-cache-miss-code generic-function args (let* ((arg-info (gf-arg-info generic-function)) (nkeys (arg-info-nkeys arg-info))) (multiple-value-bind (wrappers invalidp nfunction) (cache-miss-values generic-function args) (cond (invalidp (apply nfunction args)) ((null nfunction) (apply #'no-applicable-method generic-function args)) ((eq ofunction nfunction) (multiple-value-bind (nfield ncache) (fill-cache field cache nkeys nil #'checking-limit-fn wrappers nil) (unless (and (= nfield field) (eq ncache cache)) (update-to-checking-dfun generic-function nfunction nfield ncache))) (apply nfunction args)) (t (update-to-caching-dfun generic-function) (apply nfunction args))))))) (defun caching-miss (generic-function args ofield ocache) (protect-cache-miss-code generic-function args (let* ((arg-info (gf-arg-info generic-function)) (nkeys (arg-info-nkeys arg-info))) (multiple-value-bind (wrappers invalidp function) (cache-miss-values generic-function args) (cond (invalidp (apply function args)) ((null function) (apply #'no-applicable-method generic-function args)) (t (multiple-value-bind (nfield ncache) (fill-cache ofield ocache nkeys t #'caching-limit-fn wrappers function) (unless (and (= nfield ofield) (eq ncache ocache)) (update-to-caching-dfun generic-function nfield ncache))) (apply function args))))))) ;;; ;;; The dynamically adaptive method lookup algorithm is implemented is ;;; implemented as a kind of state machine. The kinds of discriminating ;;; function is the state, the various kinds of reasons for a cache miss ;;; are the state transitions. ;;; ;;; The code which implements the transitions is all in the miss handlers ;;; for each kind of dfun. Those appear here. ;;; ;;; Note that within the states that cache, there are dfun updates which ;;; simply select a new cache or cache field. Those are not considered ;;; as state transitions. ;;; (defun initial-dfun (args generic-function) #+Genera (declare (dbg:invisible-frame :pcl-internals)) (protect-cache-miss-code generic-function args (multiple-value-bind (wrappers invalidp nfunction applicable) (cache-miss-values generic-function args) (multiple-value-bind (ntype nindex) (accessor-miss-values generic-function applicable args) (cond ((null applicable) (apply #'no-applicable-method generic-function args)) (invalidp (apply nfunction args)) ((and ntype nindex) (ecase ntype (reader (update-to-one-class-readers-dfun generic-function wrappers nindex)) (writer (update-to-one-class-writers-dfun generic-function wrappers nindex))) (apply nfunction args)) (ntype (apply nfunction args)) (t (update-to-checking-dfun generic-function nfunction) (apply nfunction args))))))) ;;; From DEFSYS.LISP #+Genera ;;; Make sure Genera bug mail contains the PCL bug data. A little ;;; kludgy, but what the heck. If they didn't mean for people to do ;;; this, they wouldn't have made private patch notes be flavored ;;; objects, right? Right. (progn (scl:defflavor pcl-private-patch-info ((description)) ()) (scl:defmethod (sct::private-patch-info-description pcl-private-patch-info) () (or description (setf description (string-append "PCL version: " pcl:*pcl-system-date*)))) (scl:defmethod (sct::private-patch-info-pathname pcl-private-patch-info) () *pcl-directory*) (unless (find-if #'(lambda (x) (typep x 'pcl-private-patch-info)) sct::*private-patch-info*) (push (scl:make-instance 'pcl-private-patch-info) sct::*private-patch-info*))) ;;; From GENERA-LOW.LISP: (SCL:FUNDEFINE 'PCL-FDEFINE-HELPER) ;; No longer in use. ;;; Remove the call to PCL-FDEFINE-HELPER; the method expansion now calls ;;; LOAD-DEFMETHOD instead. (sys:define-function-spec-handler method (op spec &optional arg1 arg2) (if (eq op 'sys:validate-function-spec) (and (let ((gspec (cadr spec))) (or (symbolp gspec) (and (listp gspec) (eq (car gspec) 'setf) (symbolp (cadr gspec)) (null (cddr gspec))))) (let ((tail (cddr spec))) (loop (cond ((null tail) (return nil)) ((listp (car tail)) (return t)) ((atom (pop tail))) (t (return nil)))))) (let ((table *method-htable*) (key spec)) (case op ((si:fdefinedp si:fdefinition) (car (gethash key table nil))) (si:fundefine (remhash key table)) (si:fdefine (let ((old (gethash key table nil)) (quals nil) (specs nil) (ptr (cddr spec))) (setq specs (loop (cond ((null ptr) (return nil)) ((listp (car ptr)) (return (car ptr))) (t (push (pop ptr) quals))))) (setf (gethash key table) (cons arg1 (cdr old))))) (si:get (let ((old (gethash key table nil))) (getf (cdr old) arg1))) (si:plist (let ((old (gethash key table nil))) (cdr old))) (si:putprop (let ((old (gethash key table nil))) (unless old (setf old (cons nil nil)) (setf (gethash key table) old)) (setf (getf (cdr old) arg2) arg1))) (si:remprop (let ((old (gethash key table nil))) (when old (remf (cdr old) arg1)))) (otherwise (si:function-spec-default-handler op spec arg1 arg2)))))) ;===================================== #+Genera (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) #+Ignore (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "PCL:MAY-DAY-PCL;BOOT.LISP.2") #+Genera (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*-Mode: LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*-") #+Genera (defun expand-defmethod (proto-method name qualifiers lambda-list body env) (when (listp name) (do-standard-defsetf-1 (cadr name))) (multiple-value-bind (fn-form specializers doc plist) (expand-defmethod-internal name qualifiers lambda-list body env) (let ((fn-args (cadadr fn-form)) (fn-body (cddadr fn-form)) (method-name `(method ,name ,@qualifiers ,specializers))) `(progn (proclaim '(function ,name)) (defun ,method-name ,fn-args ,@fn-body) (load-defmethod ',(if proto-method (class-name (class-of proto-method)) 'standard-method) ',name ',qualifiers (list ,@(mapcar #'(lambda (specializer) (if (and (consp specializer) (eq (car specializer) 'eql)) ``(eql ,,(cadr specializer)) `',specializer)) specializers)) ',(specialized-lambda-list-lambda-list lambda-list) ',doc ',(getf plist :isl-cache-symbol) ;Paper over a bug in KCL by ;passing the cache-symbol ;here in addition to in the ;plist. ',plist #',method-name))))) (defun expand-defmethod-internal (generic-function-name qualifiers specialized-lambda-list body env) (declare (values fn-form specializers doc) (ignore qualifiers)) (when (listp generic-function-name) (do-standard-defsetf-1 (cadr generic-function-name))) (multiple-value-bind (documentation declarations real-body) (extract-declarations body) (multiple-value-bind (parameters lambda-list specializers) (parse-specialized-lambda-list specialized-lambda-list) (let* ((required-parameters (mapcar #'(lambda (r s) (declare (ignore s)) r) parameters specializers)) (parameters-to-reference (make-parameter-references specialized-lambda-list required-parameters declarations generic-function-name specializers)) (class-declarations `(declare ,@(remove nil (mapcar #'(lambda (a s) (and (symbolp s) (neq s 't) `(class ,a ,s))) parameters specializers)))) (method-lambda ;; Remove the documentation string and insert the ;; appropriate class declarations. The documentation ;; string is removed to make it easy for us to insert ;; new declarations later, they will just go after the ;; cadr of the method lambda. The class declarations ;; are inserted to communicate the class of the method's ;; arguments to the code walk. (let () `(lambda ,lambda-list ,class-declarations ,@declarations (progn ,@parameters-to-reference) (block ,(if (listp generic-function-name) (cadr generic-function-name) generic-function-name) ,@real-body)))) (call-next-method-p nil) ;flag indicating that call-next-method ;should be in the method definition (next-method-p-p nil) ;flag indicating that next-method-p ;should be in the method definition (save-original-args nil) ;flag indicating whether or not the ;original arguments to the method ;must be preserved. This happens ;for two reasons: ; - the method takes &mumble args, ; so one of the lexical functions ; might be used in a default value ; form ; - call-next-method is used without ; arguments at least once in the ; body of the method (original-args ()) (applyp nil) ;flag indicating whether or not the ;method takes &mumble arguments. If ;it does, it means call-next-method ;without arguments must be APPLY'd ;to original-args. If this gets set ;true, save-original-args is set so ;as well (aux-bindings ()) ;Suffice to say that &aux is one of ;damndest things to have put in a ;language. (slots (mapcar #'list required-parameters)) (plist ()) (walked-lambda nil)) (flet ((walk-function (form context env) (cond ((not (eq context ':eval)) form) ((not (listp form)) form) ((eq (car form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args (not (cdr form))) form) ((eq (car form) 'next-method-p) (setq next-method-p-p 't) form) ((and (eq (car form) 'function) (cond ((eq (cadr form) 'call-next-method) (setq call-next-method-p 't) (setq save-original-args 't) form) ((eq (cadr form) 'next-method-p) (setq next-method-p-p 't) form) (t nil)))) ((and (or (eq (car form) 'slot-value) (eq (car form) 'set-slot-value)) (symbolp (cadr form)) (constantp (caddr form))) (let ((parameter (can-optimize-access (cadr form) required-parameters env))) (if (null parameter) form (ecase (car form) (slot-value (optimize-slot-value slots parameter form)) (set-slot-value (optimize-set-slot-value slots parameter form)))))) (t form)))) (setq walked-lambda (walk-form method-lambda env #'walk-function)) ;; ;; Add &allow-other-keys to the lambda list as an interim ;; way of implementing lambda list congruence rules. ;; (when (and (memq '&key lambda-list) (not (memq '&allow-other-keys lambda-list))) (let* ((rll (reverse lambda-list)) (aux (memq '&aux rll))) (setq lambda-list (if aux (progn (setf (cdr aux) (cons '&allow-other-keys (cdr aux))) (nreverse rll)) (nconc (nreverse rll) (list '&allow-other-keys)))))) ;; Scan the lambda list to determine whether this method ;; takes &mumble arguments. If it does, we set applyp and ;; save-original-args true. ;; ;; This is also the place where we construct the original ;; arguments lambda list if there has to be one. (dolist (p lambda-list) (if (memq p lambda-list-keywords) (if (eq p '&aux) (progn (setq aux-bindings (cdr (memq '&aux lambda-list))) (return nil)) (progn (setq applyp t save-original-args t) (push '&rest original-args) (push (make-symbol "AMPERSAND-ARGS") original-args) (return nil))) (push (make-symbol (symbol-name p)) original-args))) (setq original-args (if save-original-args (nreverse original-args) ())) (multiple-value-bind (ignore walked-declarations walked-lambda-body) (extract-declarations (cddr walked-lambda)) (declare (ignore ignore)) (when (some #'cdr slots) (setq slots (slot-name-lists-from-slots slots)) (setq plist (list* :isl slots plist)) (setq walked-lambda-body (add-pv-binding walked-lambda-body plist required-parameters)) (dolist (dcl-stm walked-declarations) (dolist (dcl (cdr dcl-stm)) (when (eql (car dcl) 'ignore) (setf (cdr dcl) (set-difference (cdr dcl) required-parameters)))))) (when (or next-method-p-p call-next-method-p) (setq plist (list* :needs-next-methods-p 't plist))) ;;; changes are here... (mt) (let ((fn-body (if (or call-next-method-p next-method-p-p) (add-lexical-functions-to-method-lambda walked-declarations walked-lambda-body `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body) original-args lambda-list save-original-args applyp aux-bindings call-next-method-p next-method-p-p) `(lambda ,lambda-list ,@walked-declarations ,.walked-lambda-body)))) (values `(function ,fn-body) specializers documentation plist)))))))) ;===================================== #+Genera (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) #+Ignore (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "PCL:MAY-DAY-PCL;DEFS.LISP.2") #+Genera (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*-Mode: LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*-") (defun setfboundp (symbol) #+Genera (not (null (get-properties (symbol-plist symbol) 'lt::(derived-setf-function trivial-setf-method setf-equivalence setf-method)))) #+Lucid (locally (declare (special lucid::*setf-inverse-table* lucid::*simple-setf-method-table* lucid::*setf-method-expander-table*)) (or (gethash symbol lucid::*setf-inverse-table*) (gethash symbol lucid::*simple-setf-method-table*) (gethash symbol lucid::*setf-method-expander-table*))) #+kcl (or (get symbol 'si::setf-method) (get symbol 'si::setf-update-fn) (get symbol 'si::setf-lambda)) #+Xerox (or (get symbol :setf-inverse) (get symbol 'il:setf-inverse) (get symbol 'il:setfn) (get symbol :shared-setf-inverse) (get symbol :setf-method-expander) (get symbol 'il:setf-method-expander)) #+:coral (or (get symbol 'ccl::setf-inverse) (get symbol 'ccl::setf-method-expander)) #-(or Genera Lucid KCL Xerox :coral) nil) ;===================================== #+Genera (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) #+Ignore (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "CLIM:MAY-DAY-PCL;WALK.LISP.2") #+Genera (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode:LISP; Package:(WALKER LISP 1000); Base:10; Syntax:Common-lisp -*-") #-Genera (in-package 'WALKER) (defun walk-prog/prog* (form context old-env sequentialp) (walker-environment-bind (new-env old-env) (let* ((possible-block-name (second form)) (blocked-prog (and (symbolp possible-block-name) (not (eq possible-block-name 'nil))))) (multiple-value-bind (let/let* block-name bindings body) (if blocked-prog (values (car form) (cadr form) (caddr form) (cdddr form)) (values (car form) nil (cadr form) (cddr form))) (let* ((walked-bindings (walk-bindings-1 bindings old-env new-env context sequentialp)) (walked-body (walk-declarations body #'(lambda (real-body real-env) (walk-tagbody-1 real-body context real-env)) new-env))) (if block-name (relist* form let/let* block-name walked-bindings walked-body) (relist* form let/let* walked-bindings walked-body))))))) #-Genera (in-package 'PCL) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12582; Wed, 1 Aug 90 02:26:20 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 30 JUL 90 22:03:06 PDT Return-Path: Redistributed: CommonLoops.pa Received: from TAMU.EDU ([128.194.15.2]) by Xerox.COM ; 30 JUL 90 22:02:20 PDT Received: from visual2.tamu.edu by TAMU.EDU (AA21283); Tue, 31 Jul 90 00:01:11 CDT Received: by visual2.tamu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA14055; Tue, 31 Jul 90 00:03:55 GMT-0600 Date: Tue, 31 Jul 90 00:03:55 GMT-0600 From: james@visual2.tamu.edu (James Saxon) Message-Id: <9007310603.AA14055@visual2.tamu.edu> To: CommonLoops.pa@Xerox.COM Subject: CommonWindows Am I hoping for too much that there's a CommonWindows version of Allegro that will interface well with PCL and take place all on a Sun 4.1 OS? James Saxon Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23117; Wed, 1 Aug 90 08:00:31 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 09:55:25-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 828085; 1 Aug 90 10:55:05 EDT Date: Wed, 1 Aug 90 10:59 EDT From: David A. Moon Subject: Re: FYI: a metaobject extension To: Gregor Kiczales Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: <90Jul31.142920pdt.167@spade.parc.xerox.com> Message-Id: <19900801145913.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Tue, 31 Jul 1990 14:29:20 PDT From: Gregor Kiczales I believe this feature flies in the face of the name/metaobject separation we worked so hard to get right. I also believe that this name/metaobject separation is one of the significant contributions of CLOS to the world of Lisp-based OOLs, so it is important to keep it right. I believe that the proper way to do this is by making a method object and calling add-method. Yes, its true that Chapter 3 isn't an official standard, but certainly within your own implementation you could have done that, and CLIM could do it as well. This sounds like an ideal application of the phrase "semantic chasm." A minor change to the application program is to require that part of the application to be rewritten in an entirely different (sub)language? Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25554; Wed, 1 Aug 90 09:18:11 -0700 Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 11:14:33-CDT Received: from roo.parc.xerox.com by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25443; Wed, 1 Aug 90 09:14:33 -0700 Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA03960; Wed, 1 Aug 90 09:14:19 PDT Message-Id: <9008011614.AA03960@roo.parc.xerox.com> Date: Wed, 1 Aug 90 09:14:19 PDT From: Gregor Kiczales Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: David A. Moon's message of Wed, 1 Aug 90 10:59 EDT <19900801145913.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: FYI: a metaobject extension Line-Fold: NO Date: Wed, 1 Aug 90 10:59 EDT From: David A. Moon Line-Fold: No This sounds like an ideal application of the phrase "semantic chasm." A minor change to the application program is to require that part of the application to be rewritten in an entirely different (sub)language? How minor a change is it really when you go from knowing the (name of the) class a method will be specialized to at compile time to knowing nothing about the class until load time? From the perspective of our colleagues in the rest of the OO community (C++, Objective-C in particular), this difference would appear pretty substantial. Many would argue against it outright, others would just nod and say that its the kind of crazy thing "those Lisp people" are always doing. I actually believe the difference is pretty substantial as well. This combination of `dynamic linking' and `treating programs as first class data objects' is important and powerful. In the second case, that is what is happening, and I believe that to avoid confusion, its best to program in way that makes it clear what you are doing. Finally, here is another way of thinking about it. This is phrased in terms of direct confusion to users, and the kind of trouble we (the Common Lisp community) always seems to be getting in with our users. Note that it would not be surprising if the change you are talking about had an effect on the performance of the method in question --- slot accesses within its body would be likely not to be optimized. Now suppose that some poor user, who doesn't think quite so hard notices this feature (that defmethod takes class objects) and starts to write a bunch of code this new way. Suppose in particular they start to use this kind of method definition when the other would do. Then they complain about how bad a language CLOS is because it doesn't properly optimize slot access etc. Some wizard looks at their code, says "You aren't supposed to program this way, can't you see that there is no way for these slot accesses to be optimized! You should be writing this other way!" In these kinder and more gentle days, perhaps the wizard wouldn't scream but would just fix all the code for them. Either way, the Lisp community loses a customer because the user says "This is too complicated, two things that look a lot the same compile completely differently." Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26932; Wed, 1 Aug 90 10:01:49 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 11:57:46-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 828132; 1 Aug 90 12:57:22 EDT Date: Wed, 1 Aug 90 13:01 EDT From: David A. Moon Subject: Re: FYI: a metaobject extension To: Gregor Kiczales Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: <9008011614.AA03960@roo.parc.xerox.com> Message-Id: <19900801170120.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No We seem to have gotten out of synch somehow. Nothing in your message has anything at all to do with what I thought we were talking about, which is allowing macros to expand into (defmethod gf ((x #) y z) body...) in addition to the present ability for macros to expand into (defmethod gf ((x c) y z) body...) This certainly has nothing to do with deferring anything until load time. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28766; Wed, 1 Aug 90 10:48:34 -0700 Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 12:44:02-CDT Received: from roo.parc.xerox.com by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28586; Wed, 1 Aug 90 10:44:09 -0700 Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA04880; Wed, 1 Aug 90 10:44:03 PDT Message-Id: <9008011744.AA04880@roo.parc.xerox.com> Date: Wed, 1 Aug 90 10:44:03 PDT From: Gregor Kiczales Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: David A. Moon's message of Wed, 1 Aug 90 13:01 EDT <19900801170120.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: FYI: a metaobject extension Line-Fold: NO Date: Wed, 1 Aug 90 13:01 EDT From: David A. Moon Line-Fold: No We seem to have gotten out of synch somehow. Nothing in your message has anything at all to do with what I thought we were talking about, which is allowing macros to expand into (defmethod gf ((x #) y z) body...) Hmm, I think we are still in sync. Specifically, do you imagine allowing macros to expand that way as part of file compiling? How could that work? Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02021; Wed, 1 Aug 90 12:26:46 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 14:22:46-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 828206; 1 Aug 90 15:22:11 EDT Date: Wed, 1 Aug 90 15:26 EDT From: David A. Moon Subject: Re: FYI: a metaobject extension To: Gregor Kiczales Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: <9008011744.AA04880@roo.parc.xerox.com> Message-Id: <19900801192618.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Wed, 1 Aug 90 10:44:03 PDT From: Gregor Kiczales Date: Wed, 1 Aug 90 13:01 EDT From: David A. Moon Line-Fold: No We seem to have gotten out of synch somehow. Nothing in your message has anything at all to do with what I thought we were talking about, which is allowing macros to expand into (defmethod gf ((x #) y z) body...) Hmm, I think we are still in sync. Specifically, do you imagine allowing macros to expand that way as part of file compiling? Yes. I don't just imagine it, I do it. How could that work? The class has to have an applicable MAKE-LOAD-FORM method, obviously, so that the class can be made available as a parameter specializer name at load time. This is really no different from using a symbol as a parameter specializer name, we're just using a class in place of a class-name. Does it help clarify things if I tell you that implementing this feature in PCL required adding this one-line change to parse-specializers? ((typep spec 'class) spec) Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09606; Wed, 1 Aug 90 15:22:08 -0700 Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Wed 1 Aug 90 17:19:52-CDT Received: from roo.parc.xerox.com by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09545; Wed, 1 Aug 90 15:20:04 -0700 Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA07720; Wed, 1 Aug 90 15:20:00 PDT Message-Id: <9008012220.AA07720@roo.parc.xerox.com> Date: Wed, 1 Aug 90 15:20:00 PDT From: Gregor Kiczales Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: David A. Moon's message of Wed, 1 Aug 90 15:26 EDT <19900801192618.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: FYI: a metaobject extension Line-Fold: NO Date: Wed, 1 Aug 90 15:26 EDT From: David A. Moon Line-Fold: No Yes. I don't just imagine it, I do it. The class has to have an applicable MAKE-LOAD-FORM method, obviously, so that the class can be made available as a parameter specializer name at load time. This is really no different from using a symbol as a parameter specializer name, we're just using a class in place of a class-name. I am about to leave for a few days, and as I originally thought, there is more to say about than there is time for before I go. But, even though I see how you are making this work, and had thought of it, it doesn't convince me. Very much the opposite. Just for starters notice that what you are doing is making a distinction between classes for which it is possible to write a MAKE-LOAD-FORM method and classes for which that is difficult or not possible. The only such general purpose method I can imagine would work only for properly named classes. So, it really is a just what you say "using a class metaobject in a way that is no different from using the class name". Well then we have blurred the distinction between metaobjects and names. We should keep having this debate. I think it is important, or at the very least interesting. I will make real effort to organize and collect all my thoughts on it in one message rather than put them out one at a time like this. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14390; Wed, 1 Aug 90 17:44:02 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 01 AUG 90 14:20:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from dale.eng.umd.edu ([128.8.133.32]) by Xerox.COM ; 01 AUG 90 14:19:47 PDT Received: by dale.eng.umd.edu (5.61/umdeng-0.3/05-15-90) id AA13528; Wed, 1 Aug 90 17:19:41 -0400 Date: Wed, 1 Aug 90 17:19:41 -0400 From: ohc@eng.umd.edu (Hyeong-Cheol Oh) Message-Id: <9008012119.AA13528@dale.eng.umd.edu> To: CommonLoops.PA@Xerox.COM Subject: installing PCL under IBCL Cc: ohc@eng.umd.edu I have been trying to install PCL under IBCL here, but it is not working. I'd like to find out if I am doing something wrong or there is some bug, since you said it should work in IBCL (October 15, 1987) but hasn't been tested there yet. I renamed all the files to have .lsp extension and edited the *pcl-directory* variable appropriately. I tried running ibcl and then doing (load "/meta/ohc/PCL_S/defsys.lsp") and (pcl::compile-pcl) but this produced an error message looking like the following: >>Error: Cannot expand the SETF form (%CCLOSURE-ENV FIN). SETF (IHS[23]) Arg 0: (SETF (%CCLOSURE-ENV FIN) ENV) Arg 1: NIL I learned that the functions %CCLOSURE-ENV and CCLOSURE-ENV-NTHCDR were defined kcl-low.lsp. So I compiled and loaded the file kcl-low.lsp before I did (pcl::compile-pcl). But I got another error message looking like the following: Loading binary of BRAID... >>Error: 2 is not a vector. Load (IHS[22]) I would appreciate it if you could tell me if I am doing something stupid. Or if this version of PCL doesn't work in IBCL, is there some fix? Thanks for your help. Hyeong-Cheol Oh Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14499; Wed, 1 Aug 90 17:47:12 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 01 AUG 90 09:20:52 PDT Return-Path: Redistributed: CommonLoops.pa Received: from roo.parc.xerox.com ([13.2.16.72]) by Xerox.COM ; 01 AUG 90 09:19:32 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA04006; Wed, 1 Aug 90 09:19:40 PDT Message-Id: <9008011619.AA04006@roo.parc.xerox.com> Date: Wed, 1 Aug 90 09:19:40 PDT From: Gregor Kiczales Sender: gregor@parc.xerox.com To: CommonLoops.pa@Xerox.COM Subject: new version of Chapter 3 Line-Fold: NO At long last, I can announce to the world that there is a new version of chapter 3 (The Metaobject Protocol) publicly available. This isn't a final version at all, there is a lot that remains to be done. Even so, this version is much better than previous versions (in my opinion at least). The following note from the cover of the document is informative: Since this document was last made publicly available, large parts of it have been extensively revised. The revised material is the same in spirit as the previous draft but is, we hope, much more clear and precise. In addition, a number of bugs and design flaws have been fixed. Note that in many cases, the parts that have been revised provide a strong model for what will be done to parts that have not yet been revised. One example is that the section ``Initialization of Class Metaobjects'' has been revised, but the sections on initialization of other kinds of metaobjects have not yet been. Another example is that the generic functions named add-xxx have been revised, but the ones named remove-xxx have not yet been. This document is available for anonymous FTP from arisia.xerox.com. In the directory /pcl/mop there are two files: moptex.Z This is a compressed tar file of all the stuff you need to run Chapter 3 through TeX. Well, not all the stuff you need, you will have to provide your own TeX wizard if (hah!) something goes wrong. mop.ps.Z This is a compressed Postscript file for Chapter 3. Probably, you want to FTP one or the other but not both of these files. Enjoy Gregor Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00113; Tue, 7 Aug 90 08:14:01 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 7 Aug 90 10:05:41-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 830318; 7 Aug 90 11:04:51 EDT Date: Tue, 7 Aug 90 11:09 EDT From: David A. Moon Subject: error checking of args to CALL-NEXT-METHOD To: Doug Cutting Cc: cl-cleanup@sail.stanford.edu, common-lisp-object-system@MCC.COM In-Reply-To: <9008062258.AA01070@elsinore.parc.xerox.com> Message-Id: <19900807150937.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No [common-lisp-object-system mailing list added] Date: Mon, 6 Aug 90 15:58:51 PDT From: Doug Cutting The CLOS spec states (page 2-13): When providing arguments to CALL-NEXT-METHOD, the following rule must be satisfied or an error is signaled: The ordered set of methods applicable for a changed set of arguments for CALL-NEXT-METHOD must be the same as the ordered set of applicable methods for the original arguments to the generic function. The phrase "an error is signaled" seems overly restrictive. PCL does not detect this situation and I can see no way of ensuring it does without severely impacting performance. Why not amend this to read "an error should be signaled" or even "the results are undefined"? The performance impact need not be severe since usually the specialized arguments will not be changed, and that can be tested first. If any specialized arguments are not EQ, go to out-of-line code that checks whether any specialized arguments have different classes, and if so calls COMPUTE-APPLICABLE-METHODS to see if the restriction is violated. Programs that switch to arguments of different classes would be slow, unless that checking is cached somehow, but other programs would not be significantly affected. However, even though I don't believe the performance impact is necessarily severe, I'm not sure that checking for this particular error is all that important. CLOS in Symbolics Genera 8.0.1 and Symbolics Cloe 3.0 does not signal an error in this situation either. I used the following test case: (defclass tst1 ()()) (defclass tst2 (tst1) ()) (defmethod tst1 ((x tst1) y) (format t "~&tst1 primary method: ~S ~S" x y)) (defmethod tst1 ((x tst2) y) (format t "~&tst2 primary method: ~S ~S" x y)) (defmethod tst1 :around ((x tst2) y) (format t "~&tst2 around method: ~S ~S" x y) (call-next-method y x)) (setq tst1 (make-instance 'tst1) tst2 (make-instance 'tst2)) (tst1 tst2 tst2) ;okay tst2 around method: # # tst2 primary method: # # (tst1 tst2 tst1) ;invalid tst2 around method: # # tst2 primary method: # # "An error should be signaled" is problematical unless we can define the exact point in the program where safety is to be evaluated to decide whether an error must be signalled. "The consequences are undefined" would permit the most implementation freedom but provide the least safety to users. "The consequences are unspecified" looks as difficult to implement as "an error is signalled" in some implementations (this wording would forbid having optimized SETF of SLOT-VALUE go to the wrong memory location in a program that calls CALL-NEXT-METHOD with invalid arguments). Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03637; Thu, 9 Aug 90 22:47:50 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 10 Aug 90 00:32:02-CDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA26002g; Thu, 9 Aug 90 22:28:07 PDT Received: by ptl-club id AA02530g; Thu, 9 Aug 90 22:32:28 PDT Date: Thu, 9 Aug 90 22:32:28 PDT From: Jon L White Message-Id: <9008100532.AA02530@ptl-club> To: gregor@parc.xerox.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp-Object-System@mcc.com In-Reply-To: Gregor Kiczales's message of Tue, 31 Jul 1990 14:29:20 PDT <90Jul31.142920pdt.167@spade.parc.xerox.com> Subject: FYI: a metaobject extension re: I believe this feature flies in the face of the name/metaobject separation we worked so hard to get right. I also believe that this name/metaobject separation is one of the significant contributions of CLOS to the world of Lisp-based OOLs, so it is important to keep it right. I believe that the proper way to do this is by making a method object and calling add-method. See 88-002R, page 1-15, second paragraph: "The proper name of every class is a valid type specifier. In addition, every class object is a valid type specifier." The separation here, for type-specifier names, is not the one you seem to be suggesting. Accordingly, the consistent thing is to expect that a type-specifier denoting a class can serve as a parameter-specializer-name denoting a class. This is all that Moon seems to have asked for. I simply don't understand any of the points you have been trying to make in rebuttal to him. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26936; Tue, 14 Aug 90 09:10:37 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 14 Aug 90 10:53:04-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 14 Aug 90 08:51:09 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA18200; Tue, 14 Aug 90 08:52:53 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA02479; Tue, 14 Aug 90 08:52:31 pdt Message-Id: <9008141552.AA02479@hplap.hpl.hp.com> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: OOPSLA 90 Workshop Deadlines Extended X-Mailer: mh6.5 Date: Tue, 14 Aug 90 08:52:30 PDT From: Andreas Paepcke As you know from previous messages, I am this year's organizer for the CLOS Workshop, which will be held in the context of OOPSLA '90 on Sunday, Oct 21 '90 in Ottawa. It is a one-day workshop. The deadline for the submission of position papers was Aug 1. I have just received word from the OOPSLA organization asking workshop organizers to extend this deadline to September 1 because the conference programs went out very late and some people are apparently just receiving them now. The CLOS Workshop will comply with this request. You are therefore welcome to submit position papers until that time. I attach the original call for participation again. PLEASE, the earlier you can submit, the better for everyone. Looking forward, Regards, Andreas ;;;;;;;;;;;;;;;;;;;;;;; Original Call for Participation ;;;;;;;;;;;;;;;;; Third CLOS Users and Implementor's Workshop 1990 `Now What?' The first CLOS Workshop in 1988 was organized to bring the CLOS community together and to make known which areas were being addressed in university and industrial centers. The 1989 Workshop was dominated by introspection, the examination of issues important at the time. CLOS has now matured to a point where it is time to take stock and to understand what should happen next. One goal will need to be the projection of CLOS out into the community. An obviously important component of this is the organization and publication of projects that use CLOS. A second component must be a clarification of what is still missing and how CLOS should be improved or completed. A third component, finally, is reflection on how the language has advanced the state of the art or has a potential for doing this. This year's Workshop is to serve a dual purpose. The first is to let us touch bases to learn what has been happening in the CLOS community and what is to be done next. The second is to provide material and direction for the "CLOS Report", a publication that will highlight the many facets of the language and its history. This will be a collection of full length papers to be published some time after the Workshop. We hope that our meeting and its associated short papers can draw attention to contributions that should make their way into such a collection. The format of the Workshop reflects these two goals. We will try to divide the day into three units. The first will be a critical look back to where we have been. We will try to identify, collect and evaluate decisions we made to ensure that we learn all we can from CLOS' rich, hectic history. This could involve an analysis of what worked well and what went wrong. It would also be useful simply to spell out which constraints led to particular decisions and whether our resolutions were meaningful. The second unit will be an attempt to compile a representative list of projects which use CLOS for various purposes. Our goal will be to assemble a portfolio of projects that illuminate different aspects of the language. These could, for instance, include the metaobject protocol, CLOS' approach to inheritance, method combination or other issues. Emphasis will be on broad coverage. The third unit, finally, will attempt to produce a roadmap, or at least a series of mile stones to identify what needs to happen during the next two or three years and how it could be achieved. The hope is that this unit will profit from the review and survey of the first two units. To get units one and three started we plan to invite two speakers each, who will present opposing, controversial views of ten minutes each. Afterwards, we will turn to plenum discussion. The Workshop logistics will follow OOPSLA ACM guidelines. Attendance will have to be limited to 30 contributors. Each contributor will need to submit a short position paper of two to five pages. Each paper should be classified to indicate which of the three units the paper addresses: 1. Looking back 2. Taking stock 3. Future needs To summarize: The `looking back' unit has the purpose of isolating what we learned. The `taking stock' unit is to produce a portfolio of projects that highlight different aspects of the language. The `future needs' unit should try to clarify what needs to be done next. Papers may include compilations of issues, provocative questions or hypotheses which can be used to stimulate and guide discussion in particular areas. The papers will be reviewed, and up to 30 of them will be selected for inclusion in the Workshop. We will try to have these papers bound and mailed to participants before OOPSLA to make the Workshop as efficient as possible. Please submit five copies of your papers by August 1 1990 to: Andreas Paepcke Hewlett-Packard Laboratory 1501 Page Mill Rd. Palo Alto, Ca. 94304-1126 paepcke@hplabs.hp.com Tel: 415-857-7398 Fax: 415-857-8526 We also welcome suggestions for the Workshop format, suggestions for speakers or other feedback that will help make our Workshop a success. Looking foward to hearing from you, Andreas Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04654; Fri, 17 Aug 90 11:29:48 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 17 Aug 90 13:26:13-CDT Received: from Forsythe.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Aug 90 11:24:21 PDT Received: by Forsythe.Stanford.EDU; Fri, 17 Aug 90 11:28:14 PDT Date: Fri, 17 Aug 90 15:13:26 AST From: Andre de Souza Mello Valente Subject: DISTRIBUTED CLOS IMPLEMENTATION: ASK FOR HELP To: COMMON-LISP-OBJECT-SYSTEM@SAIL.STANFORD.EDU Message-Id: <805@LNCC.BITNET> I am implementing a distributed version of CLOS, and I have some "silly" doubts about some implementation strategies and techniques. Maybe someone can help me and suggest a solution: a) How can I intercept the CL evaluation to use my own dispatcher (the CLOS dispatcher, of course)? I thought about using eval-hook or apply-hook, but there are some problems. For instance, when you are using one of these functions and get an error, the interpreter make a throw that goes back to the interpreter top-level - and you should reinitialize to use the desired eval or apply again. b) How can I intercept the printing system to use the CLOS one (with "print-object")? We have to take care of two major possibilities: calling explicitly one of print, write, format, etc.; calling implicitly via the interpreter (in the read-eval-print cycle). Although it seems not, the second is very important because you have to print un-re-readable strings for the CLOS objects (#<...). c) How can I create the new versions of typep, type-of, etc., using the older ones? I tried to create a new package and shadow the CL ones, but had no success. BTW, I tried the same with print, but got nothing also. I am using Gold Hill CL in a PC (DOS), with a 386 Humming Board, but I am trying to find (if possible) implementation-independent solutions to these problems. If not possible at all, is anyone aware of a good E-mail contact at Gold Hill I can use to adress this kind of question? If there is anyone interested in discussing my implementation, it is a pleasure for me, also. Andre Valente Instituto Tecnologico de Aeronautica, Brazil userasmv@lncc.bitnet Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07042; Fri, 17 Aug 90 13:20:06 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 17 Aug 90 15:13:51-CDT Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Aug 90 13:11:59 PDT Received: from roo.parc.xerox.com by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06906; Fri, 17 Aug 90 13:14:24 -0700 Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA07232; Fri, 17 Aug 90 13:14:19 PDT Message-Id: <9008172014.AA07232@roo.parc.xerox.com> Date: Fri, 17 Aug 90 13:14:19 PDT From: Gregor Kiczales Sender: gregor@parc.xerox.com To: USERASMV%LNCC.BITNET@Forsythe.Stanford.EDU Cc: COMMON-LISP-OBJECT-SYSTEM@SAIL.STANFORD.EDU In-Reply-To: Andre de Souza Mello Valente 's message of Fri, 17 Aug 90 15:13:26 AST <805@LNCC.BITNET> Subject: Re: DISTRIBUTED CLOS IMPLEMENTATION: ASK FOR HELP Line-Fold: NO Date: Fri, 17 Aug 90 15:13:26 AST From: Andre de Souza Mello Valente I am implementing a distributed version of CLOS, and I have some "silly" doubts about some implementation strategies and techniques. Maybe someone can help me and suggest a solution: A general comment is that you should get a copy of PCL, which may provide a useful starting point for your work. PCL is a portable implementation of (most of) CLOS. It is available for free from Xerox (by anonymous FTP). For more information, send a message to CommonLoops-Coordinator@parc.xerox.com. a) How can I intercept the CL evaluation to use my own dispatcher (the CLOS dispatcher, of course)? I thought about using eval-hook or apply-hook, but there are some problems. For instance, when you are using one of these functions and get an error, the interpreter make a throw that goes back to the interpreter top-level - and you should reinitialize to use the desired eval or apply again. If you look in PCL, you will see a technique which just makes the individual functions which are generic use a special dispatcher. At a lower level is an implementation of objects called funcallable instances. These are functions which you can set the code of. b) How can I intercept the printing system to use the CLOS one (with "print-object")? We have to take care of two major possibilities: calling explicitly one of print, write, format, etc.; calling implicitly via the interpreter (in the read-eval-print cycle). Although it seems not, the second is very important because you have to print un-re-readable strings for the CLOS objects (#<...). In large part, this isn't possible without the sources of the underlying Common Lisp. For objects defined by defstruct you can use :print-function, but for most other things it is hard to get this to work. This is one the the things PCL doesn't support properly about CLOS. c) How can I create the new versions of typep, type-of, etc., using the older ones? I tried to create a new package and shadow the CL ones, but had no success. BTW, I tried the same with print, but got nothing also. This is very hard to get completely right without access to the sources from the underlying lisp. PCL includes a version of this that works mostly right, you should look at that. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08184; Fri, 17 Aug 90 14:14:00 -0700 Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Fri 17 Aug 90 15:55:16-CDT Received: by atc.boeing.com on Fri, 17 Aug 90 13:54:23 PDT Date: Fri, 17 Aug 90 13:54 PDT From: Stephen L. Nicoud Subject: DISTRIBUTED CLOS IMPLEMENTATION: ASK FOR HELP To: Andre de Souza Mello Valente Cc: common-lisp-object-system@mcc.com In-Reply-To: The message of 17 Aug 90 11:33 PDT from Andre de Souza Mello Valente Message-Id: <19900817205429.3.SLN@SKAGIT.atc.boeing.com> Date: 17 Aug 90 18:33:41 GMT From: Andre de Souza Mello Valente c) How can I create the new versions of typep, type-of, etc., using the older ones? I tried to create a new package and shadow the CL ones, but had no success. BTW, I tried the same with print, but got nothing also. If the intent is to modify the behavior of these functions for only those programs which use your system, then the new-package/shadow/redefine steps should work okay. (Assuming the programs which use your system now call your functions; which can be realized more or less transparently through some appropriate combination of package-use'ng, shadow'ng and/or shadowing-import'ng.) If the intent is to modify the behavior for all callers of these "redefined" functions then I know of at least a couple of options. First, if your CL implementation provides an ADVICE facility then I'd suggest using that to modify the behavior of functions whose definition you have no control over. Of the CL implementations I have used (TI, Symbolics, Franz Allegro, & Lucid), they all have an ADVICE facility. I don't know about GHCL. Alternatively, you could use the poor man's route via storing the function objects of the functions you want modified and then use your code to define a new definition for the lisp: symbol. This is the technique utilized by the Express Windows system. For example, something like this might work: (lisp:make-package :my-package :use '(lisp)) (in-package :my-package) (defparameter *shadowed-functions* '(typep ... )) (shadow *shadowed-functions* :my-package) (defun my-typep (object type) ) (defun typep (object type) (or (lisp-typep object type) (my-typep object type))) Other similar redefinitons ... . . . (defun setup-lisp-functions (functions) (dolist (function functions) (let ((local-name (intern (concatenate 'STRING "LISP-" (symbol-name function)))) (new-function (intern (symbol-name function))) (cl-function function)) (unless (fboundp local-name) (setf (symbol-function local-name) (symbol-function cl-function))) (when (fboundp new-function) (setf (symbol-function cl-function) (symbol-function new-function)))))) (setup-lisp-functions *shadowed-functions*) Care must be taken with this approach. If you, say, get a patch from your CL vendor for one of the "redefined" functions, you'll have to reinstall your modification. I always felt uneasy about this approach, although I'm not sure why. I'm never quite sure how this affects the rest of the CL system for other things (like TRACE, for instance). Perhaps others more knowledgeable can comment on the implications and possible risks. Steve -- Stephen L. Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16905; Wed, 22 Aug 90 12:36:55 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 22 Aug 90 14:02:17-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 837134; 22 Aug 90 14:53:26 EDT Date: Wed, 22 Aug 90 14:56 EDT From: David A. Moon Subject: call-next-method with arguments To: Kim A. Barrett Cc: common-lisp-object-system@mcc.com, cl-cleanup@mcc.com In-Reply-To: <9008172324.AA28712@charon.MIT.EDU> Message-Id: <19900822185603.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Fri, 17 Aug 90 19:24:27 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Partly in response to the recent question on one of the mailing lists about the error signaling behavior for call-next-method with arguments that don't correspond to the same ordered set of applicable methods as the original arguments, I recently made another pass over some parts of 88-002R and have the following questions. Here are my personal opinions on your questions: 1. If call-next-method is called with arguments, should it check for wrong number of arguments? Probably, at least in safe circumstances. Yes, it should be just like calling the generic function except that only a subset of the usual applicable methods are used. This is quite easy to implement. 2. If call-next-method is called with arguments, some of which are keyword arguments, should the receiving `effective' method redo exact key checking? This is probably expensive. Assuming safe code of course, since unsafe code isn't required to check, due to a vote at the 6/90 meeting. Yes, it should be just like calling the generic function except that only a subset of the usual applicable methods are used. There's a subtle point here: it has to use the original set of applicable methods, not the smaller set, for checking the keyword arguments, or else call-next-method with no arguments would sometimes be invalid. I don't think this is any harder to implement than keyword argument checking always is. 3. If call-next-method is called with arguments which specify a different set of applicable methods and there is no next method available, does the check for changed applicable methods occur or does no-next-method get called with the new arguments? Probably should be the former. Yes. This is quite easy to implement. 4. If call-next-method is called with arguments, it is supposed to signal an error if the ordered set of methods applicable to the new arguments differs from the ordered set of methods applicable to the original arguments. However, the order of methods is not well defined, since applicable methods may have the same specializers but different qualifiers, and there is no ordering constraint between such methods. Is compute-applicable-methods required to be consistent in its ordering of such methods (a currently undocumented constraint), or does call-next-method need to handle this situation (making the handling of call-next-method with arguments even slower). The specification should be clarified to say that the new and old sets of applicable methods must have the same elements and where the order of two elements is defined by the specification, it must be the same in both sets. It should be up to the implementation to choose to do this by imposing a total ordering on the methods or by making call-next-method use something other than EQUAL to do the checking. I don't think this is a change, I think this is what the words "the same as" used in the specification mean. 5. Should the checking for different applicable methods by call-next-method fall into the realm covered by {issue whose name escapes me, passed at 6/90 meeting making argument quantity and exact keyword checking be `should signal'}. That is, do we want to permit this checking to be elided in unsafe code. ARGUMENT-MISMATCH-ERROR. Yes. It was a collective mistake by X3J13 that this did not get included in that cleanup issue. (As the author of the issue I'll accept 50% of the responsibility, but certainly not 100%). By the way I am not at present aware of any CLOS implementations that signal this error. Eliding the checking in unsafe code is quite easy to implement. 6. The description of call-method is completely silent on the question of whether or when its arguments are evaluated. The uses of call-method in the examples for define-method-combination clearly indicate that the arguments are not evaluated. Yes, they are not evaluated. Depending on what are the conventions for describing macro arguments used in this specification, the specification may in fact already be specifying that they are not evaluated. But I like it better to be explicit about this. 7. The description of call-method does not make clear what lexical environment the form in a make-method entry is supposed to be executed in. Presumably it is the lexical environment in which the call-method form is executed. For this to be true it is essential that call-method not evaluate its arguments. Yes. I was not sure I had ever seen this feature of call-next-method (supplying arguments to it) used in real life, so I looked at CLIM, a medium-large CLOS-based program. The version of CLIM I looked at uses call-next-method in 42 places, of which 31 are without arguments and 11 are with arguments. Of those 11, 4 are mistakes (the arguments are not actually changed) and the remainder only change the value of numerical arguments that are never specialized. Most of these 7 look like their speed matters. Most of them don't involve keyword arguments, but I think one does. All of them could reasonably be compiled unsafe if that is truly necessary for performance. I also looked at some CLIM applications and none of them used call-next-method at all. I conclude that the issues you've brought up can't just be dismissed as unimportant. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20026; Wed, 22 Aug 90 14:54:09 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Wed 22 Aug 90 16:51:02-CDT Received: by charon.MIT.EDU id AA17857; Wed, 22 Aug 90 17:50:50 EDT Date: Wed, 22 Aug 90 17:50:50 EDT From: kab@CHARON.MIT.EDU (Kim A. Barrett) Message-Id: <9008222150.AA17857@charon.MIT.EDU> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@mcc.com, cl-cleanup@mcc.com In-Reply-To: David A. Moon's message of Wed, 22 Aug 90 14:56 EDT <19900822185603.2.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: call-next-method with arguments 4. If call-next-method is called with arguments, it is supposed to signal an error if the ordered set of methods applicable to the new arguments differs from the ordered set of methods applicable to the original arguments. However, the order of methods is not well defined ... . Is compute-applicable-methods required to be consistent in its ordering of such methods ..., or does call-next-method need to handle this situation ... ... It should be up to the implementation to choose to do this by imposing a total ordering on the methods or by making call-next-method use something other than EQUAL to do the checking. I don't think the implementation can impose a total ordering on the methods, since COMPUTE-APPLICABLE-METHODS is now a generic function (Issue COMPUTE-APPLICABLE-METHODS, passed 6/90), so either it must be constrained to return consistent results, or CALL-NEXT-METHOD must use something other than EQUAL to match the two lists. I think the latter is probably the right way to deal with this. Other than that I think we agree on all points. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08600; Fri, 24 Aug 90 02:07:34 -0700 Received: from Korbel.OSBU_North.Xerox.xns by alpha.xerox.com via XNS id <16170>; Fri, 24 Aug 1990 00:46:55 PDT X-Ns-Transport-Id: 0000AA00025518392A61 Date: Fri, 24 Aug 1990 00:37:28 PDT Errors-To: Owners-CommonLoops.PA@xerox.com From: "\"nmj%cs.flinders.oz.au\"".GV@xerox.com Subject: Creating new method combinations To: CommonLoops.PA@xerox.com Illegal-Object: Syntax error in Message-ID: value found on alpha.xerox.com: Message-ID: <"24-Aug-90 0:37:28 PDT".*"\"nmj%cs.flinders.oz.au\"".GV@Xerox.com> ^-illegal end of message identification Message-Id: <90Aug24.004655pdt.16170@alpha.xerox.com> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV To: CommonLoops.PA Subject: Creating new method combinations From: nick(j). Return-Path: Redistributed: CommonLoops.PA Received: from kurango.cs.flinders.oz.au ([129.96.1.3]) by Xerox.COM ; 24 AUG 90 00:37:17 PDT Received: by kurango.cs.flinders.oz.au (5.61+IDA+MU/FU-5.8) id AA20632; Fri, 24 Aug 1990 17:06:59 +0930 Message-Id: <9008240736.AA20632@kurango.cs.flinders.oz.au> Original-Date: Fri, 24 Aug 90 17:06:55 +0930 GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV (wrt 22/5/90 PCL (REV 2) and AKCL 1.485) I've been trying to create new method combinations using: "define-method-combination" (long form) and the object returned is: # (for a combination called "rule"). What I'd like to do is have this new combination method replace the original standard combination (by setq'ing pcl::*standard-method-combination* with this value!?! am I an the right track?????) If I attempt this I get the following error: Error: When initializing the generic-function #: The :METHOD-COMBINATION initialization argument was: #. It must be a method combination object. Error signalled by SHARED-INITIALIZE. Broken at SHARED-INITIALIZE. Type :H for Help. Has anyone got any pointers as to how one might replace the standard method combination with a user defined? PS I known this defeats the purpose of the mail group but could any responses be mailed directly, as I'm not sure if the mail groups mail is getting thro' Thanx in advance. (nick j) +------------------------------------------------------------------------+ | Nick Jeitner PH (08) 201 2874 | | Flinders University FAX (08) 201 2904 | | Skool of Info Sci and Tech email nmj@kurango.cs.flinders.oz.au | | GPO Box 2100, Adelaide SA, 5001. | +------------------------------------------------------------------------+ Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26009; Fri, 24 Aug 90 11:53:18 -0700 Received: from Dove.Parc.Xerox.xns by alpha.xerox.com via XNS id <16198>; Fri, 24 Aug 1990 08:35:59 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16187>; Fri, 24 Aug 1990 08:32:33 PDT Received: from imicefr.cefriel.it by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8917; Fri, 24 Aug 90 11:29:03 EDT Received: by IMICEFR (Mailer R2.05) id 6712; Fri, 24 Aug 90 17:30:37 ITA X-Ns-Transport-Id: 08002008D0FD00017D86 Date: Fri, 24 Aug 1990 10:18:59 PDT From: "Ulrico Canzi - CEFRIEL, Milano, Italy" Subject: CLOS Browser To: commonloops.PARC@xerox.com Message-Id: <90Aug24.083233pdt.16187@alpha.xerox.com> I am a AI researcher. Up to the now I used Knowledge Craft or KEE and Common Lisp. Actually I am passing to CLOS. Does it exists a graphical environment built on CLX able to display or handle CLOS classes and instances? The computers I have are two IBM PS-2/80 with AIX and the Common Lisp I will buy is AllegroCL (but I am still in time to change my choice to Lucid or IBUKI whenever needed). My best thanks and regards, Ulrico Canzi Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03376; Sat, 25 Aug 90 18:25:44 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16182>; Sat, 25 Aug 1990 18:26:27 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16182>; Sat, 25 Aug 1990 18:22:57 PDT Received: by spade.parc.xerox.com id <265>; Sat, 25 Aug 1990 18:21:38 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00018357 Date: Sat, 25 Aug 1990 18:21:26 PDT From: Gregor Kiczales Subject: Re: Creating new method combinations In-Reply-To: "\"\\\"nmj%cs.flinders.oz.au\\\"\".GV@Xerox.com's message of Fri, 24 Aug 1990 00:37:28 PDT <90Aug24.004655pdt.16170@alpha.xerox.com>" To: nmj@cs.flinders.oz.au Cc: CommonLoops.PARC@Xerox.com Message-Id: <90Aug25.182138pdt.265@spade.parc.xerox.com> Subject: Creating new method combinations From: nick(j). (wrt 22/5/90 PCL (REV 2) and AKCL 1.485) I've been trying to create new method combinations using: "define-method-combination" (long form) and the object returned is: # (for a combination called "rule"). What I'd like to do is have this new combination method replace the original standard combination (by setq'ing pcl::*standard-method-combination* with this value!?! am I an the right track?????) The short answer is that you can't do this. What you are trying to do is, for all intensive purposes, analogous to saying "well, for my program, I would like cons to do something a little different, so I will just redefine it." What you may want to do is shadow the symbol DEFGENERIC in your package, changing its behavior so that, by default, it uses your kind of method combination. One, overly simple, way to do this is as follows: (in-package 'my-package) (shadow 'defgeneric) (defmacro defgeneric (name ll &rest options) `(pcl:defgeneric ,name ,ll (:method-combination rule) ,@options)) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23221; Mon, 27 Aug 90 20:32:00 -0700 Received: from Dove.Parc.Xerox.xns by alpha.xerox.com via XNS id <16574>; Mon, 27 Aug 1990 20:00:42 PDT Received: from ptolemy.arc.nasa.gov ([128.102.25.4]) by alpha.xerox.com with SMTP id <16639>; Mon, 27 Aug 1990 18:56:16 PDT Received: from rayleigh.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Mon, 27 Aug 90 17:20:49 PDT Received: by rayleigh.arc.nasa.gov (4.1/) id ; Mon, 27 Aug 90 17:20:53 PDT X-Ns-Transport-Id: 08002008D0FD00018B88 Date: Mon, 27 Aug 1990 17:20:48 PDT From: Andrew Philpot Subject: feature? bug? To: CommonLoops.PARC@Xerox.com Message-Id: <9008280020.AA17926@ptolemy.arc.nasa.gov> I am having problems with :AROUND methods placed on argument lists which are completely unspecialized, i.e., whose class is T. This is the simplest case in which I detect this behavior. It doesn't seem to happen when you make this a method on some other built-in class like SYMBOL. It also doesn't happen unless there are both primary and arounds of the same name both on class T. ;; begin code (use-package :pcl) (defmethod try ((thing t)) nil) (defmethod try :around ((thing t)) nil) ;;; end code When you then execute (try t) you get an error: Error: No matching method for the generic-function #, when called with arguments (NIL). Backtrace at this point reveals: ->(ERROR "No matching method for the generic-function ~S,~@ when called with arguments ~S." # ...) (ERROR "No matching method for the generic-function ~S,~@ when called with arguments ~S." # ...) (NO-APPLICABLE-METHOD # NIL) (METHOD-FUNCTION NIL) (#:|..$RANDOM-FORMS$.a9df4d10.a9df4d11| (CALL-METHOD NIL NIL) :EVAL ...) (SIMPLE-CODE-WALKER (CALL-METHOD NIL NIL) NIL ...) (#:|.$RANDOM-FORMS$.a9df4d10| (CALL-METHOD NIL NIL)) (MAKE-EFFECTIVE-METHOD-FUNCTION # (CALL-METHOD NIL NIL)) ... more older frames ... I have been through the most recent "cloops.text" archive and have just subscribed to the mailing list. Thanks for any assistance. Andrew ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; PCL information: PCL system date: 5/22/89 Victoria Day PCL Lisp Implementation type: Allegro CL Lisp Implementation version: 3.1.13 [Sun3] (4/24/90) *features*: (:LOOP LOOP :COMPOSER :FAKE-ACTIVE-REGIONS :PCL :CLOS :BIG-ENDIAN :GSGC :M68881 :M68020 :ALLEGRO-V3.1 :FRANZ-INC :EXCL :ALLEGRO :COMMON-LISP :CONFORMING-IEEE :IEEE :FLAVORS :SUNOS4.0 :SUN :M68K :SUN3 :UNIX :NASA-RIA :MULTIPROCESSING :CLX :XLIB :CLX-MIT-R4 :CLX-CL-ERROR :CW-X) Andrew Philpot philpot@ptolemy.arc.nasa.gov ***************************************************************** * "The use of Cobol cripples the mind: its teaching, therefore, * * should be regarded as a criminal offense." - Dijkstra * ***************************************************************** Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11899; Tue, 28 Aug 90 04:49:58 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16209>; Tue, 28 Aug 1990 04:50:24 PDT Received: from mcsun.EU.net ([192.16.202.1]) by alpha.xerox.com with SMTP id <16209>; Tue, 28 Aug 1990 04:47:32 PDT Received: by mcsun.EU.net with SMTP; Tue, 28 Aug 90 13:44:22 +0200 (MET) Received: from coeur by hp4nl.nluug.nl with UUCP via EUnet id AA25885 (5.58.1.14/2.14); Tue, 28 Aug 90 13:46:42 MET Received: by coeur.UUCP; Tue, 28 Aug 90 13:14:40 +0200 (MET) Organisation: Courseware Europe b.v. Ebbehout 1 1507 EA Zaandam, The Netherlands Phone: +31 75 172201 Fax: +31 75 311502 X-Ns-Transport-Id: 08002008D0FD00018FE8 Date: Tue, 28 Aug 1990 04:14:40 PDT From: beentjes%coeur.uucp@relay.eu.net (Hans Beentjes) Subject: Compiling PCL on Xerox To: commonloops.PARC@Xerox.com Message-Id: <9008281114.AA23441@coeur.UUCP> Last month we tried to install the latest version of PCL, May-Day-Pcl (version 2), on a Xerox 1186. We ran into the following problem in compiling the source-code: In compiling "fixup.lisp": the function "fix-early-generic-functions" is unknown. To compile this file this function will have to be evaluated. We want to know if anybody using a Xerox 1186 running Medley has ran into the same problem or if anybody succeeded in installing this version of PCL. If so, please let us know how the installation should be done. We also like to know which problems might occur when we port source-code we develop on a Xerox under AAAI-PCL to our Sun 3/60 on which the May-Day version runs. The last thing we like to know is if there exist a Graphical tool like Grapher on the Xerox for a Sun (perhaps built in PCL?) to display graphs. Kind Regards, Hans Beentjes. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09629; Wed, 29 Aug 90 08:03:28 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Wed 29 Aug 90 09:50:12-CDT Received: by charon.MIT.EDU id AA12595; Wed, 29 Aug 90 10:50:01 EDT Date: Wed, 29 Aug 90 10:50:01 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9008291450.AA12595@charon.MIT.EDU> To: cl-cleanup@mcc.com, common-lisp-object-system@mcc.com Subject: predicate function in method group specifiers In the description of method group specifiers for DEFINE-METHOD-COMBINATION, a symbol can appear as a predicate function instead of a qualifier pattern. However, it isn't clear whether the symbol refers to the global function or if it can refer to a local function in whose scope the DEFINE-METHOD-COMBINATION form appears. That is, in the following example, will the call to foo-method-p generated to determine whether a method is matched call the global or the local definition. (defun foo-method-p ...) (flet ((foo-method-p ...)) (define-method-combination foo () ((methods foo-method-p)) ...)) Either choice can be easily implemented. Global would make this similar to a SATISFIES type specifier, but I don't think these two situations are really analogous. Somewhat related to this is the question of whether the predicate name permitted to name a macro (either global or local). If global definitions are used then the answer probably must be no. If local definitions are used when present, then it is certainly possible. The consistent answer is to use the lexical function when present, and that macro names are permitted, and may be what was actually intended. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09898; Wed, 29 Aug 90 08:21:50 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Wed 29 Aug 90 10:01:40-CDT Received: by charon.MIT.EDU id AA12624; Wed, 29 Aug 90 11:01:33 EDT Date: Wed, 29 Aug 90 11:01:33 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9008291501.AA12624@charon.MIT.EDU> To: cl-cleanup@mcc.com, common-lisp-object-system@mcc.com Subject: Class STANDARD-SLOT-DESCRIPTION I recently found another class name in 88-002R which may not have been officially blessed. The DOCUMENTATION generic function has a primary method specialized on the class STANDARD-SLOT-DESCRIPTION. I have not been able to find any other mention of this class in 88-002R or the draft standard, and it was not included in either of the issues from the 6/90 meeting which made some of the random CLOS metaobject classes official (TYPE-OF-AND-PREDEFINED-CLASSES and SANDRAS-TRIVIAL-ISSUES). If we are going to be consistent about these, then we should also have a SLOT-DESCRIPTION class (with the exception of OBJECT, for every class named STANDARD-xxx we currently have a class named xxx). Note also that the most recent draft of CLOS Chapter 3 I've seen (dated 6/6/90) calls these classes STANDARD-SLOT-DEFINITION and SLOT-DEFINITION. I personally have a mild preference for DESCRIPTION rather than DEFINITION. Do we want to say anything at all about these classes in the standard? Since I don't think they are very useful without a metaobject protocol, perhaps we should just forget them and remove the reference from the description of the DOCUMENTATION function. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10149; Wed, 29 Aug 90 08:36:33 -0700 Received: from lucid.com ([192.26.25.1]) by MCC.COM with TCP/SMTP; Wed 29 Aug 90 10:32:40-CDT Received: from caligula ([192.31.212.63]) by heavens-gate.lucid.com id AA29590g; Wed, 29 Aug 90 08:28:08 PDT Received: by caligula id AA03768g; Wed, 29 Aug 90 08:29:59 PDT Date: Wed, 29 Aug 90 08:29:59 PDT From: Jon L White Message-Id: <9008291529.AA03768@caligula> To: kab@charon.MIT.EDU Cc: cl-cleanup@mcc.com, common-lisp-object-system@mcc.com In-Reply-To: Kim A. Barrett's message of Wed, 29 Aug 90 11:01:33 EDT <9008291501.AA12624@charon.MIT.EDU> Subject: Class STANDARD-SLOT-DESCRIPTION Last winter, Moon and I came up with what seemed to be a de-facto standard for a meta-object protocol -- not the "last word", but a minimally useful subset that Symbolics, Lucid, and the latest PCL could generally agree upon (I think Franz too gave assent by silence). This list included SLOT-DEFINITION and STANDARD-SLOT-DEFINITION as class names, along with several score of "introspective" functions. Dave sent out the entire proposal to common-lisp-object-system@mcc.com on March 4, 1990. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12206; Wed, 29 Aug 90 10:11:38 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16261>; Wed, 29 Aug 1990 10:00:04 PDT Received: from ptolemy.arc.nasa.gov ([128.102.25.4]) by alpha.xerox.com with SMTP id <16267>; Wed, 29 Aug 1990 09:48:47 PDT Received: from rayleigh.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 29 Aug 90 09:47:37 PDT Received: by rayleigh.arc.nasa.gov (4.1/) id ; Wed, 29 Aug 90 09:47:36 PDT X-Ns-Transport-Id: 08002008D0FD00019B5A Date: Mon, 27 Aug 1990 17:20:48 PDT From: Andrew Philpot Subject: feature? bug? To: CommonLoops.PARC@Xerox.com, CommonLoops.PARC@Xerox.com Message-Id: <9008291647.AA01766@ptolemy.arc.nasa.gov> I am having problems with :AROUND methods placed on argument lists which are completely unspecialized, i.e., whose class is T. This is the simplest case in which I detect this behavior. It doesn't seem to happen when you make this a method on some other built-in class like SYMBOL. It also doesn't happen unless there are both primary and arounds of the same name both on class T. ;; begin code (use-package :pcl) (defmethod try ((thing t)) nil) (defmethod try :around ((thing t)) nil) ;;; end code When you then execute (try t) you get an error: Error: No matching method for the generic-function #, when called with arguments (NIL). Backtrace at this point reveals: ->(ERROR "No matching method for the generic-function ~S,~@ when called with arguments ~S." # ...) (ERROR "No matching method for the generic-function ~S,~@ when called with arguments ~S." # ...) (NO-APPLICABLE-METHOD # NIL) (METHOD-FUNCTION NIL) (#:|..$RANDOM-FORMS$.a9df4d10.a9df4d11| (CALL-METHOD NIL NIL) :EVAL ...) (SIMPLE-CODE-WALKER (CALL-METHOD NIL NIL) NIL ...) (#:|.$RANDOM-FORMS$.a9df4d10| (CALL-METHOD NIL NIL)) (MAKE-EFFECTIVE-METHOD-FUNCTION # (CALL-METHOD NIL NIL)) ... more older frames ... I have been through the most recent "cloops.text" archive and have just subscribed to the mailing list. Thanks for any assistance. Andrew ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; PCL information: PCL system date: 5/22/89 Victoria Day PCL Lisp Implementation type: Allegro CL Lisp Implementation version: 3.1.13 [Sun3] (4/24/90) *features*: (:LOOP LOOP :COMPOSER :FAKE-ACTIVE-REGIONS :PCL :CLOS :BIG-ENDIAN :GSGC :M68881 :M68020 :ALLEGRO-V3.1 :FRANZ-INC :EXCL :ALLEGRO :COMMON-LISP :CONFORMING-IEEE :IEEE :FLAVORS :SUNOS4.0 :SUN :M68K :SUN3 :UNIX :NASA-RIA :MULTIPROCESSING :CLX :XLIB :CLX-MIT-R4 :CLX-CL-ERROR :CW-X) Andrew Philpot philpot@ptolemy.arc.nasa.gov ***************************************************************** * "The use of Cobol cripples the mind: its teaching, therefore, * * should be regarded as a criminal offense." - Dijkstra * ***************************************************************** Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03649; Wed, 29 Aug 90 13:40:42 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 29 Aug 90 15:31:40-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 839984; 29 Aug 90 16:31:00 EDT Date: Wed, 29 Aug 90 16:33 EDT From: David A. Moon Subject: Class STANDARD-SLOT-DESCRIPTION To: Kim A. Barrett , Jon L White Cc: cl-cleanup@mcc.com, common-lisp-object-system@mcc.com In-Reply-To: <9008291501.AA12624@charon.MIT.EDU>, <9008291529.AA03768@caligula> Message-Id: <19900829203334.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 29 Aug 90 11:01:33 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) I recently found another class name in 88-002R which may not have been officially blessed. The DOCUMENTATION generic function has a primary method specialized on the class STANDARD-SLOT-DESCRIPTION. I have not been able to find any other mention of this class in 88-002R or the draft standard, and it was not included in either of the issues from the 6/90 meeting which made some of the random CLOS metaobject classes official (TYPE-OF-AND-PREDEFINED-CLASSES and SANDRAS-TRIVIAL-ISSUES). I think what you are seeing is that much of the text in chapter 2 was written with the assumption that chapter 3 would exist. When chapter 3 was goal-reduced, chapter 2 was not rewritten to reflect that fact. If we are going to be consistent about these, then we should also have a SLOT-DESCRIPTION class (with the exception of OBJECT, for every class named STANDARD-xxx we currently have a class named xxx). Note also that the most recent draft of CLOS Chapter 3 I've seen (dated 6/6/90) calls these classes STANDARD-SLOT-DEFINITION and SLOT-DEFINITION. I personally have a mild preference for DESCRIPTION rather than DEFINITION. I prefer the spelling DEFINITION over DESCRIPTION. DESCRIPTION sounds to me like a documentation string rather than an object. Do we want to say anything at all about these classes in the standard? Since I don't think they are very useful without a metaobject protocol, perhaps we should just forget them and remove the reference from the description of the DOCUMENTATION function. I don't see any point in documenting methods specialized to metaobjects when we don't have a metaobject protocol. Documenting the methods is mainly for the benefit of users defining their own methods, so they know where the system methods are and whether they will be shadowing them or not. But in the absence of a metaobject protocol users can't usefully define their own methods. However, maybe there is some reason I'm not seeing why these methods should be documented in chapter 2 rather than chapter 3, and hence be included in the ANSI Common Lisp spec. Date: Wed, 29 Aug 90 08:29:59 PDT From: Jon L White Last winter, Moon and I came up with what seemed to be a de-facto standard for a meta-object protocol -- not the "last word", but a minimally useful subset that Symbolics, Lucid, and the latest PCL could generally agree upon (I think Franz too gave assent by silence). I don't think it was by silence. I vaguely remember Franz explicitly agreeing that it was a good step. This list included SLOT-DEFINITION and STANDARD-SLOT-DEFINITION as class names, along with several score of "introspective" functions. Dave sent out the entire proposal to common-lisp-object-system@mcc.com on March 4, 1990. Agreed. By the way, this was explicitly not proposed to be included in ANSI Common Lisp, only to be a first step towards an agreed upon metaobject protocol beyond ANSI Common Lisp. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05409; Wed, 29 Aug 90 14:00:00 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 29 Aug 90 15:41:29-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 839996; 29 Aug 90 16:40:51 EDT Date: Wed, 29 Aug 90 16:43 EDT From: David A. Moon Subject: predicate function in method group specifiers To: Kim A. Barrett Cc: cl-cleanup@mcc.com, common-lisp-object-system@mcc.com In-Reply-To: <9008291450.AA12595@charon.MIT.EDU> Message-Id: <19900829204332.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 29 Aug 90 10:50:01 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) In the description of method group specifiers for DEFINE-METHOD-COMBINATION, a symbol can appear as a predicate function instead of a qualifier pattern. However, it isn't clear whether the symbol refers to the global function or if it can refer to a local function in whose scope the DEFINE-METHOD-COMBINATION form appears. That is, in the following example, will the call to foo-method-p generated to determine whether a method is matched call the global or the local definition. (defun foo-method-p ...) (flet ((foo-method-p ...)) (define-method-combination foo () ((methods foo-method-p)) ...)) Either choice can be easily implemented. Global would make this similar to a SATISFIES type specifier, but I don't think these two situations are really analogous. Somewhat related to this is the question of whether the predicate name permitted to name a macro (either global or local). If global definitions are used then the answer probably must be no. If local definitions are used when present, then it is certainly possible. The consistent answer is to use the lexical function when present, and that macro names are permitted, and may be what was actually intended. That's what Symbolics CLOS does. The predicate symbol is simply put into the car of a form. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12743; Wed, 29 Aug 90 18:51:40 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16276>; Wed, 29 Aug 1990 18:50:11 PDT Received: from roo.parc.xerox.com ([13.2.16.72]) by alpha.xerox.com with SMTP id <16276>; Wed, 29 Aug 1990 18:47:23 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02315; Wed, 29 Aug 90 18:48:22 PDT X-Ns-Transport-Id: 08002008D0FD0001A048 Date: Wed, 29 Aug 1990 18:48:22 PDT From: Gregor Kiczales Subject: Re: feature? bug? In-Reply-To: "Andrew Philpot's message of Mon, 27 Aug 1990 17:20:48 PDT <9008291647.AA01766@ptolemy.arc.nasa.gov>" To: philpot@ptolemy.arc.nasa.GOV Cc: CommonLoops.PARC@Xerox.com, CommonLoops.PARC@Xerox.com Message-Id: <9008300148.AA02315@roo.parc.xerox.com> X-Ns-Transport-Id: 08002008D0FD00019B5A Date: Mon, 27 Aug 1990 17:20:48 PDT From: Andrew Philpot I am having problems with :AROUND methods placed on argument lists which are completely unspecialized, i.e., whose class is T. (defmethod try ((thing t)) nil) (defmethod try :around ((thing t)) nil) When you then execute (try t) you get an error: This is without a doubt a bug in the PCL you are using. You are using Victoria Day PCL, which is more than a year old. I think that if you get the new version of PCL you will find that this bug is fixed. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12823; Wed, 29 Aug 90 18:57:02 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16279>; Wed, 29 Aug 1990 18:55:34 PDT Received: from roo.parc.xerox.com ([13.2.16.72]) by alpha.xerox.com with SMTP id <16279>; Wed, 29 Aug 1990 18:52:15 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02344; Wed, 29 Aug 90 18:53:31 PDT X-Ns-Transport-Id: 08002008D0FD0001A04D Date: Wed, 29 Aug 1990 18:53:31 PDT From: Gregor Kiczales Subject: change in list format To: CommonLoops.pa@arisia.Xerox.COM Reply-To: kiuchi.pa@arisia.Xerox.COM Message-Id: <9008300153.AA02344@roo.parc.xerox.com> The purpose of this message is to propose a change to the format of the CommonLoops mailing list --- we are suggesting that this mailing list be replaced with a new usenet newsgroup. At this time, the CommonLoops mailing list has grown quite large, with an estimated 800 readers. It requires at least one hour per day of maintenance to keep it running. Even with that amount of work, there are still many problems with duplicate messages (as many of you have noticed). Also, now that CLOS is a standard, and there are starting to be many implementations other than PCL, it seems appropriate to focus the discussion on the use of CLOS rather than the use of PCL. The precise proposal is to: 1) Decommission the CommonLoops list. 2) Create a new usenet bboard (probably called "comp.object.clos".) The charter of the bboard would be discussion of the use, future development and implementation of the Common Lisp Object System. 3) PCL sources and old archives of the CommonLoops list would still be maintained on arisia.parc.xerox.com. At this time, we would like to know whether there are people on this mailing list who would object to moving to the Usenet BBoard format. Please reply to this message only if this change would be a problem for you. Providing that this change does not pose too many problems, expect us to contact you with information about how you can participate in the usenet voting process to form the new newsgroup. Gregor Kiczales Yasuhiko Kiuchi Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19285; Thu, 30 Aug 90 08:24:42 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16262>; Thu, 30 Aug 1990 08:23:14 PDT Received: from jupiter.risc.com ([130.50.5.1]) by alpha.xerox.com with SMTP id <16262>; Thu, 30 Aug 1990 08:20:36 PDT Received: from magrathea.risc.com by jupiter.risc.com (4.0/SMI-4.0) id AA28698; Thu, 30 Aug 90 08:19:32 PDT Received: by magrathea.risc.com (4.0/SMI-4.0) id AA00208; Thu, 30 Aug 90 08:21:36 PDT X-Ns-Transport-Id: 08002008D0FD0001A378 Date: Thu, 30 Aug 1990 08:21:36 PDT From: bss@magrathea.risc.COM (Bruce Seely) Subject: method caching problem w/ Allegro CL?? To: CommonLoops.PARC@Xerox.com Message-Id: <9008301521.AA00208@magrathea.risc.com> We consistently get the result demonstrated below. The fifth time a method is called, a bus error occurs. We guess that there is a method caching problem. Has anyone else experienced this? Using: Mayday PCL in Allegro CL 3.1.13.1 on a SPARCstation 1+ with XCL and CLIM also loaded. ++++++++++++++++++++++++++++ script follows ++++++++++++++++++++++++++++++++++++ Allegro CL 3.1.13.1 [Sun4] (0/0/0) Copyright (C) 1985-1990, Franz Inc., Berkeley, CA, USA T (use-package 'pcl) Error: Using package `PCL' results in name conflicts for these symbols: (DEFCLASS FIND-CLASS WITH-SLOTS METHOD-COMBINATION-ERROR SLOT-UNBOUND CHANGE-CLASS SYMBOL-MACROLET METHOD-QUALIFIERS GENERIC-LABELS ENSURE-GENERIC-FUNCTION DEFGENERIC UPDATE-INSTANCE-FOR-REDEFINED-CLASS CALL-NEXT-METHOD CLASS-NAME REINITIALIZE-INSTANCE GENERIC-FLET INVALID-METHOD-ERROR FIND-METHOD STANDARD-CLASS SLOT-BOUNDP SLOT-MAKUNBOUND CALL-METHOD INITIALIZE-INSTANCE SHARED-INITIALIZE FUNCTION-KEYWORDS SLOT-MISSING NO-APPLICABLE-METHOD CLASS-OF WITH-ACCESSORS UPDATE-INSTANCE-FOR-DIFFERENT-CLASS MAKE-INSTANCES-OBSOLETE MAKE-INSTANCE REMOVE-METHOD DEFINE-METHOD-COMBINATION COMPUTE-APPLICABLE-METHODS NO-NEXT-METHOD SLOT-VALUE SLOT-EXISTS-P PRINT-OBJECT ADD-METHOD DEFMETHOD NEXT-METHOD-P WITH-ADDED-METHODS) Restart actions (select using :continue): 0: unintern the conflicting symbols in the `USER' package. [1c] :cont T (defclass my-class () ((var1 :accessor var1))) # (defmethod set-var1 (new-val (instance my-class)) (setf (var1 instance) new-val)) # (setq my-instance (make-instance 'my-class)) # (set-var1 5 my-instance) 5 (set-var1 5 my-instance) 5 (set-var1 5 my-instance) 5 (#) (set-var1 5 my-instance) 5 #(0 #(16615116 14097773 15398856 8907981 3420810 16621470 866414 3884872 T (VAR1) ...)) (set-var1 5 my-instance) Error: Received signal number 10 (Bus error) [1] Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20106; Thu, 30 Aug 90 09:39:35 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16288>; Thu, 30 Aug 1990 09:38:05 PDT Received: from charlie.ece.scarolina.edu ([129.252.22.20]) by alpha.xerox.com with SMTP id <16175>; Thu, 30 Aug 1990 09:32:24 PDT Received: by charlie.ece.scarolina.edu (5.57/Ultrix3.0-C) id AA03335; Thu, 30 Aug 90 11:44:12 EDT Received: from jev by midway.ece.scarolina.edu id aa02301; 30 Aug 90 12:27 EDT Received: by jev.ece.scarolina.edu (4.0/SMI-4.0) id AA01132; Thu, 30 Aug 90 12:31:49 EDT X-Ns-Transport-Id: 08002008D0FD0001A414 Date: Thu, 30 Aug 1990 09:31:49 PDT From: "Prof. Vargasje" To: commonloops.PARC@Xerox.com Message-Id: <9008301631.AA01132@jev.ece.scarolina.edu> change of email-address Please change my e-mail address from vargasje@midway.ece.scarolina.edu to vargasje@ece.scarolina.edu Thanks. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20628; Thu, 30 Aug 90 10:27:02 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16296>; Thu, 30 Aug 1990 10:25:20 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16290>; Thu, 30 Aug 1990 10:21:59 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA16680; Thu, 30 Aug 90 13:21:46 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA16419; Thu, 30 Aug 90 09:24:36 PDT Received: by frisky.Franz.COM (3.2/FI-1.0) id AA13901; Thu, 30 Aug 90 09:24:55 PDT Bh: append spr1889 X-Ns-Transport-Id: 08002008D0FD0001A484 Date: Thu, 30 Aug 1990 09:24:55 PDT From: jkf@franz.com (Sean Foderaro) Subject: Re: [spr1889] method caching problem w/ Allegro CL?? To: bss@magrathea.risc.COM Cc: bugs@franz.com, CommonLoops.PARC@XEROX.COM Message-Id: <9008301624.AA13901@frisky.Franz.COM> >> We consistently get the result demonstrated below. The fifth time a method is >> called, a bus error occurs. We guess that there is a method caching >> problem. I'll check into this and let you know what I find. John Foderaro Franz Inc. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25257; Thu, 30 Aug 90 15:40:08 -0700 Received: from Dove.Parc.Xerox.xns by alpha.xerox.com via XNS id <16304>; Thu, 30 Aug 1990 15:38:31 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16292>; Thu, 30 Aug 1990 08:16:48 PDT Received: from p.lanl.gov by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19192; Thu, 30 Aug 90 08:15:05 -0700 Received: from zaphod.lanl.gov by p.lanl.gov (5.61/1.14) id AA27554; Thu, 30 Aug 90 09:13:40 -0600 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA00733; Thu, 30 Aug 90 09:14:15 MDT X-Ns-Transport-Id: 08002008D0FD0001A36D Date: Thu, 30 Aug 1990 08:14:15 PDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Subject: change in list format In-Reply-To: "Gregor Kiczales's message of Wed, 29 Aug 1990 18:53:31 PDT <9008300153.AA02344@roo.parc.xerox.com>" To: kiuchi.pa@arisia.Xerox.COM Cc: CommonLoops.pa@arisia.Xerox.COM Message-Id: <9008301514.AA00733@zaphod.lanl.gov.lanl.gov> I think that a) The change of direction from PCL to more general CLOS discussion is an excellent idea. b) The movement to a USENET newsgroup is a very good idea. However, are there those on the mailing list who do not have USENET access? Will a parallel mailing list (shorter than now) of those who do not have USENET access still be required? c) There have already been CLOS questions and discussion on comp.lang.lisp. Is this, perhaps, a better forum than creation of a new newsgroup for what is now (almost anyway?) a part of Common Lisp? In any case, please send something to the mailing list when it is time to vote for creation of any new nesgroup so that we can all vote. I have missed new group announcements before this... Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29660; Thu, 30 Aug 90 23:22:17 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16318>; Thu, 30 Aug 1990 23:20:52 PDT Received: from TAMU.EDU ([128.194.15.2]) by alpha.xerox.com with SMTP id <16321>; Thu, 30 Aug 1990 23:17:10 PDT Received: from visual2.tamu.edu by TAMU.EDU (AA13243); Fri, 31 Aug 90 01:16:22 CDT Received: by visual2.tamu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA02465; Fri, 31 Aug 90 01:19:04 GMT-0600 X-Ns-Transport-Id: 08002008D0FD0001AA4D Date: Fri, 31 Aug 1990 00:19:04 PDT From: james@visual2.tamu.edu (James Saxon) Subject: Bingo on the Bus Error... To: CommonLoops.PARC@xerox.com Message-Id: <9008310719.AA02465@visual2.tamu.edu> I'm using the latest PCL version and also common-windows and now that somebody else has caught the cue, it seems that I too am having a bomb on the fifth method call of one of my methods. Yet at the same time, I'm running another large system with many recrusive and non recursive method calls which does not bomb at all... This takes place in Allegro 3.1 (the latest version, just shipped). James Saxon Scientific Visualization Laboratory Texas A&M University Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00900; Fri, 31 Aug 90 02:47:42 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16310>; Fri, 31 Aug 1990 02:46:01 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16310>; Fri, 31 Aug 1990 02:42:59 PDT Received: from inria.inria.fr by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00879; Fri, 31 Aug 90 02:43:35 -0700 Received: by inria.inria.fr (5.64+/89.0.8) via Fnet-EUnet id AA25849; Fri, 31 Aug 90 11:40:39 +0200 (MET) Received: from orion.laas.fr by laas.laas.fr, Fri, 31 Aug 90 11:30:25 +0200 Return-Receipt-To: ralph@orion.laas.fr Received: by orion.laas.fr, Fri, 31 Aug 90 11:39:30 +0200 X-Ns-Transport-Id: 08002008D0FD0001AAEB Date: Fri, 31 Aug 1990 02:39:30 PDT From: ralph@orion.laas.fr Subject: Re: change in list format In-Reply-To: <9008301514.AA00733@zaphod.lanl.gov.lanl.gov> To: egdorf%zaphod@LANL.GOV (Skip Egdorf) Cc: kiuchi.pa@arisia.Xerox.COM, CommonLoops.pa@arisia.Xerox.COM Reply-To: ralph@orion.laas.fr Message-Id: <9008310939.AA12879@orion.laas.fr> I disagree that comp.lang.lisp is a good newsgroup for such discussions. True, there is some discussion there concerning CLOS, but nowhere near as important as the discussions in the commonloops mailing list. I would prefer that those discussions go also to a CLOS only newsgroup. I would support either comp.object.clos or comp.lang.lisp.clos. There exist already the lisp subgroups comp.lang.lisp.franz and comp.lang.lisp.x! Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16813; Fri, 31 Aug 90 19:51:32 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16352>; Fri, 31 Aug 1990 19:49:59 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16352>; Fri, 31 Aug 1990 19:46:58 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA10717; Fri, 31 Aug 90 22:43:46 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA21989; Fri, 31 Aug 90 14:18:47 PDT Received: by frisky.Franz.COM (3.2/FI-1.0) id AA01752; Fri, 31 Aug 90 14:19:13 PDT Bh: append spr1889 X-Ns-Transport-Id: 08002008D0FD0001B0D2 Date: Fri, 31 Aug 1990 14:19:13 PDT From: jkf@franz.com (Sean Foderaro) Subject: Re: [spr1889] method caching problem w/ Allegro CL?? To: bss@magrathea.risc.COM Cc: bugs@franz.com, james@visual2.tamu.EDU, CommonLoops.PARC@Xerox.com Message-Id: <9008312119.AA01752@frisky.Franz.COM> I've found the cause of this problem: (set-var1 5 my-instance) 5 (#) (set-var1 5 my-instance) 5 #(0 #(16615116 14097773 15398856 8907981 3420810 16621470 866414 3884872 T (VAR1) ...)) (set-var1 5 my-instance) Error: Received signal number 10 (Bus error) [1] There are two pcl files to edit. The changes are as follows. This only applies to the Allegro CL on the sparc (since that is the only combination of lisp and architecture in which the fast lap compiler is implemented): *** dfun.cl.0 Fri Aug 31 11:53:53 1990 --- dfun.cl Fri Aug 31 11:58:03 1990 *************** *** 684,690 **** (gather1 (get-valid-wrapper arg)))))))) (multiple-value-bind (function appl) (get-secondary-dispatch-function generic-function args) ! (values wrappers invalidp function appl))))) (defun accessor-miss-values (generic-function applicable args) (declare (values type index)) --- 684,696 ---- (gather1 (get-valid-wrapper arg)))))))) (multiple-value-bind (function appl) (get-secondary-dispatch-function generic-function args) ! (values wrappers invalidp (coerce-to-function function) appl))))) ! ! (defun coerce-to-function (x) ! #-excl x ! #+excl (cond ((and (consp x) (eq 'lambda (car x))) ! (comp::.primcall 'make-interp-function-obj x)) ! (t x))) (defun accessor-miss-values (generic-function applicable args) (declare (values type index)) *** quadlap.cl.0 Fri Aug 31 12:21:32 1990 --- quadlap.cl Fri Aug 31 12:22:03 1990 *************** *** 576,583 **** (qe lsl :u (list (get-treg-of op1) shiftamt) :d (list op-treg))) else (setq op-treg (get-treg-of op1))) ! ! (qe return :u (list op-treg)))) (:go (qe bra :arg (cadr lap))) --- 576,584 ---- (qe lsl :u (list (get-treg-of op1) shiftamt) :d (list op-treg))) else (setq op-treg (get-treg-of op1))) ! ! (qe move :u (list op-treg) :d *mv-treg-target*) ! (qe return :u *mv-treg-target*))) (:go (qe bra :arg (cadr lap))) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06083; Mon, 3 Sep 90 02:46:12 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16589>; Mon, 3 Sep 1990 02:44:42 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16589>; Mon, 3 Sep 1990 02:39:36 PDT Received: from cunyvm.cuny.edu by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05953; Mon, 3 Sep 90 02:40:46 -0700 Received: from ICE.GE.CNR.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 7655; Mon, 03 Sep 90 05:38:04 EDT X-Envelope-To: CommonLoops.pa@arisia.Xerox.COM, kiuchi.pa@arisia.Xerox.COM X-Vms-To: IN%"kiuchi.pa@arisia.Xerox.COM" X-Vms-Cc: IN%"CommonLoops.pa@arisia.Xerox.COM" AUGUSTO VIARENGO,SARTI X-Ns-Transport-Id: 08002008D0FD0001B6FF Date: Mon, 3 Sep 1990 02:11:00 PDT From: LUIGI SARTI Subject: Re: change in list format To: kiuchi.pa@arisia.Xerox.COM, CommonLoops.pa@arisia.Xerox.COM Message-Id: <3D7270410B9FE002B1@ICE.GE.CNR.IT> Skip Egdorf writes [<9008301514.AA00733@zaphod.lanl.gov.lanl.gov>]: > b) The movement to a USENET newsgroup is a very good idea. However, > are there those on the mailing list who do not have USENET access? > Will a parallel mailing list (shorter than now) of those who do > not have USENET access still be required? I'm afraid we don't have USENET access, and would appreciate the effort of maintaining a *(shorter than now)* mailing list. Regards. Luigi Sarti Istituto per le Tecnologie Didattiche Consiglio Nazionale delle Ricerche Via all'Opera Pia, 11 16145 GENOVA (ITALY) tel: +39 10 308883 e-mail: SARTI@ICE.GE.CNR.IT or SARTI@IGEICE.BITNET Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12290; Wed, 5 Sep 90 13:07:44 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16445>; Wed, 5 Sep 1990 13:07:33 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16436>; Wed, 5 Sep 1990 12:58:24 PDT Received: by spade.parc.xerox.com id <272>; Wed, 5 Sep 1990 12:58:04 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0001C89F Date: Fri, 31 Aug 1990 10:03:13 PDT From: Gregor Kiczales Subject: issues related to list change To: CommonLoops.pa@arisia.Xerox.COM Message-Id: <90Sep5.125804pdt.272@spade.parc.xerox.com> So far, two issues have come up in regard to the proposal to move the discussion currently on CommonLoops to a usenet bboard. Let me try and address these: 1) Many people don't read usenet bboards. Why not move the mailing list to MCC with the rest of the Common-Lisp-xxx mailing lists. I certainly understand this position. Not long ago I didn't read usenet bboards. But, there are a couple of issues here. It is a sad but true fact that maintaining a large mailing list is a lot of work, and even when well done the reliability is not what one would like. Moreover, there are a lot more people who can reliably read usenet news than can get email. Another way of saying this is that the usenet bboards seem to be where the masses are. If we really want to have a medium to communicate with a lot of users, that seems to be the place to go. One possibility is to do a gatewayed bboard where everything sent to the bboard goes to a mailing list and vice versa. Then the mailing list could be much smaller, perhaps it would only be for backwards compatibility for some of the people who don't want to read bboards. I will explore this. 2) Should we use comp.lang.lisp? My opinion is that we shouldn't. I believe that CLOS deserves its own discussion forum. As for the specific name comp.object.clos, my idea was that most of the people in the Lisp community know that CLOS is an OO system for Common Lisp. Many of the people in the (very fast growing) OO community don't know about CLOS. I wanted to make CLOS more known to them. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16360; Wed, 5 Sep 90 15:56:30 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16627>; Wed, 5 Sep 1990 15:56:04 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16629>; Wed, 5 Sep 1990 15:50:46 PDT Received: from LUCID.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16247; Wed, 5 Sep 90 15:50:20 -0700 Received: from caligula ([192.31.212.63]) by heavens-gate.lucid.com id AA27342g; Wed, 5 Sep 90 15:45:13 PDT Received: by caligula id AA11397g; Wed, 5 Sep 90 15:47:22 PDT X-Ns-Transport-Id: 08002008D0FD0001D4C7 Date: Wed, 5 Sep 1990 15:47:22 PDT From: Jon L White Subject: issues related to list change In-Reply-To: "Gregor Kiczales's message of Fri, 31 Aug 1990 10:03:13 PDT <90Sep5.125804pdt.272@spade.parc.xerox.com>" To: gregor@parc.xerox.com Cc: CommonLoops.pa@arisia.Xerox.COM Message-Id: <9009052247.AA11397@caligula> re: Moreover, there are a lot more people who can reliably read usenet news than can get email. . . . If we really want to have a medium to communicate with a lot of users, that seems to be the place to go. I wonder how much this list -- CommonLoops.pa@arisia.Xerox.COM -- serves as a "news board" reaching lots of users, and how much it serves as an explicit user-group mailing list. If the latter, then reaching people who can't use email doesn't seem to be an important goal. re: 2) Should we use comp.lang.lisp? My opinion is that we shouldn't. Ditto, but possibly for stronger reasons than you are thinking. Using comp.object.clos won't preclude CLOS discussion happening on Common-Lisp@mcc.com any more than comp.lang.lisp subsumes the role that the more specific mcc.com list has. And it would still have the drawback of a "news" list rather than a more interactive email list. While I agree with your goal to provide a forum for higher level discussion of CLOS, I am seriously wondering about the role that CommonLoops.pa plays in bug-reporting, and in bug-fix sharing, for the extant PCL's. Even though I must represent a company that has a CLOS product "in the field" now, we cannot ignore the fact that numerous users out there will be conservatively bound to their PCL code for some time yet. For example, I wanted to send you some additions to defsys.lisp and fin.lisp files to account for upcoming Lucid ports on prominent hardware and revamped ports on existing hardware. But I'm still not sure how the integration and distribution of these incremental changes will happen. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03619; Thu, 6 Sep 90 07:32:39 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16422>; Thu, 6 Sep 1990 07:32:19 PDT Received: from soleil.cs.UMD.EDU ([128.8.128.14]) by alpha.xerox.com with SMTP id <16422>; Thu, 6 Sep 1990 07:28:03 PDT Received: from localhost by soleil.cs.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA06873; Thu, 6 Sep 90 10:27:33 -0400 X-Ns-Transport-Id: 08002008D0FD0001F08B Date: Thu, 6 Sep 1990 07:27:31 PDT From: Josh Lubell Subject: Metaobject Protocol in MACL 2.0 To: info-macl@cambridge.apple.COM, CommonLoops.PARC@Xerox.com Message-Id: <9009061427.AA06873@soleil.cs.UMD.EDU> Will the CLOS that's supposed to be in MACL 2.0 include any of the Metaobject Protocol (MOP) functionality? While I applaud Apple for including CLOS in the new release and for changing Object Lisp objects in its implementation to CLOS objects, Apple should realize that a CLOS implementation without MOP functionality has limited utility. Since the MOP has not yet been finalized, I would be satisfied if Apple would support a subset of the MOP and document the functions used in their implementation that support additional MOP functionality. That way, I will be able to locally implement the MOP to support my applications.. I am currently using MACL 1.3.2 with Portable Commonloops (PCL), and I am making extensive use of the MOP. If MACL 2.0 were to include a fast CLOS with an adequate subset of the MOP included, then my code would compile and run significantly faster. However, without adequate MOP functionality, I would be forced to continue using PCL. Are there other MACL users who would like to see the MOP as part of the next release. If so, then let's make sure Apple knows we're out there! Josh Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05410; Thu, 6 Sep 90 08:41:23 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16432>; Thu, 6 Sep 1990 08:41:06 PDT Received: from apple.com ([130.43.2.2]) by alpha.xerox.com with SMTP id <16432>; Thu, 6 Sep 1990 08:38:29 PDT Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA28141; Thu, 6 Sep 90 08:37:58 -0700 for commonloops.pa@xerox.com Received: from cambridge.apple.com (ministry.cambridge.apple.com) by goofy.apple.com with SMTP (5.61/25-eef) id AA01045; Thu, 6 Sep 90 08:37:52 -0700 for commonloops.pa@xerox.com Received: from [127.0.0.1] by cambridge.apple.com with SMTP (5.64/25-eef) id AA21919; Thu, 6 Sep 90 11:21:43 -0400 for commonloops.pa@xerox.com X-Ns-Transport-Id: 08002008D0FD0001F108 Date: Thu, 6 Sep 1990 08:21:41 PDT From: bill@cambridge.apple.COM Subject: Re: Metaobject Protocol in MACL 2.0 In-Reply-To: "Your message of Thu, 06 Sep 90 10:27:31 -0400. <9009061427.AA06873@soleil.cs.UMD.EDU>" To: Josh Lubell Cc: info-macl@cambridge.apple.COM, CommonLoops.PARC@Xerox.com Message-Id: <9009061521.AA21919@cambridge.apple.com> To: info-macl@cambridge.apple.com, CommonLoops.pa@xerox.com Subject: Metaobject Protocol in MACL 2.0 Date: Thu, 06 Sep 90 10:27:31 -0400 From: Josh Lubell Will the CLOS that's supposed to be in MACL 2.0 include any of the Metaobject Protocol (MOP) functionality? While I applaud Apple for including CLOS in the new release and for changing Object Lisp objects in its implementation to CLOS objects, Apple should realize that a CLOS implementation without MOP functionality has limited utility. Since the MOP has not yet been finalized, I would be satisfied if Apple would support a subset of the MOP and document the functions used in their implementation that support additional MOP functionality. That way, I will be able to locally implement the MOP to support my applications.. I am currently using MACL 1.3.2 with Portable Commonloops (PCL), and I am making extensive use of the MOP. If MACL 2.0 were to include a fast CLOS with an adequate subset of the MOP included, then my code would compile and run significantly faster. However, without adequate MOP functionality, I would be forced to continue using PCL. Are there other MACL users who would like to see the MOP as part of the next release. If so, then let's make sure Apple knows we're out there! Josh In the interest of releasing MACL 2.0 in a timely manner, it will conform to the specifications in CLtL, Second Edition: no MOP. We hope to provide at least a subset of the MOP in a future release. Exactly what this subset is will depend a lot on what the Lisp community decides about the definition of the MOP. Said a little less formally: I wanna write a MOP, but I ain't yet had the time. Those who need PCL's MOP can continue to use PCL in MACL 2.0. Bill Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14223; Thu, 6 Sep 90 16:03:47 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16391>; Thu, 6 Sep 1990 16:03:21 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16472>; Thu, 6 Sep 1990 16:00:48 PDT Received: from postgres.Berkeley.EDU by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14140; Thu, 6 Sep 90 16:00:32 -0700 Received: by postgres.Berkeley.EDU (5.61/1.29) id AA27166; Thu, 6 Sep 90 15:59:52 -0700 X-Ns-Transport-Id: 08002008D0FD0001F570 Date: Thu, 6 Sep 1990 15:59:52 PDT From: larry@postgres.Berkeley.EDU (Larry Rowe) Subject: Picasso GUI Development System Release Announcement To: Commonloops.pa@arisia.Xerox.COM, allegro-cl@ucbarpa.Berkeley.EDU, bloom1@thumper.bellcore.COM, carey@cs.wisc.EDU, cl-windows@sail.stanford.EDU, dcmartin@cs.wisc.EDU, dewitt@cs.wisc.EDU, djohnson@ray.csc.ti.com, dw@siemens.siemens.COM, ebm@ibm.COM, jonl@lucid.COM, kempf@sun.COM, mbm@DARJEELING.MIT.EDU, metz@iam.unibe.ch, rod@cs.UMD.EDU, sbz@cs.brown.EDU, shan@hplmcs.hpl.hp.COM, shoens@ibm.COM, rcattell%dorado.uucp@sun.com Cc: cimsoft@argon.Berkeley.EDU, picasso_g@postgres.Berkeley.EDU, postgres_g@postgres.Berkeley.EDU Message-Id: <9009062259.AA27166@postgres.Berkeley.EDU> Picasso Graphical User Interface Development System Lawrence A. Rowe Computer Science Division - EECS Dept University of California Berkeley, CA 94720 (phone: 415-642-5117; email: larry@postgres.Berkeley.EDU) Picasso is a graphical user interface (GUI) development system that includes an object-oriented interface toolkit and application framework. The toolkit contains a library of predefined interface abstractions (e.g., buttons, scrollbars, menus, forms, text fields, lists and tables, graphics fields, video field, etc.), geometry managers, and a constraint system. The constraint system is used to implement triggered behaviors and to bind variables to interface abstractions. The application framework provides high-level objects to define GUI's including modal dialog boxes and non-modal frames and panels. These objects are similar to procedures and co-routines in a conventional programming language in that they have local variables and they can be called with parameters. Different types of parameter passing are used to specify when updates are propagated to different views of the information displayed. Picasso is implemented in Common Lisp using the Common Lisp Object System and the CLX interface to the X Window System. Currently, it runs on Unix systems including Sun-3's and Sparcstations, DECStation 3100's, and Sequent Balance in Franz Allegro Common Lisp. We have developed several applications in the system including: 1) a facility manager tool that displays a 2D schematic view of an IC fabrication laboratory and that allows users to access other facility and manufacturing information stored in a relational dbms (e.g., equipment, utility, and lot information), 2) an interactive executer/debugger for a robot programming language that can be used to teach novices how to program in Lisp, and 3) a hypermedia system that includes video, text, and graphic data. We are currently working on a direct manipulation application development interface and enhancements to and applications of the hypermedia system. A paper describing the application framework and a reference manual are available. Papers describing our use of CLOS to implement Picasso, the facility management tool, and the hypermedia system are currently being written. If you are interested in receiving these papers send email to picasso@postgres.Berkeley.EDU. Picasso is currently being used at three sites outside Berkeley. If you want to get a copy of the system you can either FTP it from Berkeley (postgres@Berkeley.EDU (128.32.149.1)) or send us a check for $150 (US) drawn on a US bank and we'll be glad to send you a tar tape. Please indicate whether you want a Sun, DEC, or 8mm tape. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18368; Thu, 6 Sep 90 21:35:58 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16354>; Thu, 6 Sep 1990 21:35:47 PDT Received: from green-hill.csrl.aoyama.ac.jp ([133.2.1.1]) by alpha.xerox.com with SMTP id <16509>; Thu, 6 Sep 1990 21:32:46 PDT Received: by green-hill.csrl.aoyama.ac.jp (4.1/6.5J.alpha1) id AA13135; Fri, 7 Sep 90 13:31:13 JST Received: by kepa.csrl.aoyama.ac.jp (4.1/6.4J.5-aguac) id AA08688; Fri, 7 Sep 90 13:31:49 JST Return-Path: X-Ns-Transport-Id: 08002008D0FD0001F76B Date: Fri, 7 Sep 1990 06:31:49 PDT From: Masayuki Ida Subject: change in list format In-Reply-To: "Masayuki Ida's message of Mon, 3 Sep 90 21:34:17 JST <9009031234.AA07621@kepa.csrl.aoyama.ac.jp>" To: gregor@parc.xerox.com Cc: kiuchi.pa@arisia.Xerox.COM, ida@csrl.aoyama.ac.jp, keisuke@kepa.csrl.aoyama.ac.jp, commonloops.PARC@Xerox.com Message-Id: <9009070431.AA08688@kepa.csrl.aoyama.ac.jp> >>Date: Mon, 3 Sep 90 21:34:17 JST >>From: Masayuki Ida >> >> If someone on this redistibution list may feel >> that stopping this pcl mail redistribution mechanism is not >> confortable, please send me mail. >> (I am OK to continue to send even when the mailing list will be >> moved to USENET newsgroup, since I myself do not like to make >> extra procedure to peek newsgroup and will make a trick on news >> reader to send me commonloops mails as private mails to me and >> this mechanism will also serve as a switching mechanism >> between news system and mailing system.) >> >>Masayuki Ida >> For a few years, I have been keeping a mail forwarding mechanism as Parc people know. For the above mail, which was sent to the commonloops mails local redistribution list, I got several mails saying 'please send me as mail anyway'. (Some persons are OK to shift to news group) So, I will keep commonloops mail forwarding in Japan for the people who likes to have them as mails. I myself like to receive as mail. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29420; Mon, 10 Sep 90 11:26:35 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16599>; Mon, 10 Sep 1990 11:26:02 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16578>; Mon, 10 Sep 1990 11:19:26 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA02548; Mon, 10 Sep 90 14:18:21 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA07414; Mon, 10 Sep 90 10:54:25 PDT Received: by lava.Franz.COM (4.0/FI-1.0) id AA04230; Mon, 10 Sep 90 10:54:52 PDT X-Ns-Transport-Id: 08002008D0FD00020732 Date: Mon, 10 Sep 1990 10:54:52 PDT Sender: ila@franz.com From: rsl@ILA.COM Subject: DEFMETHOD automagic references considered random To: CommonLoops.PARC@Xerox.com Cc: rsl@ILA.COM Reply-To: rsl@ILA.COM Message-Id: <9009101754.AA04230@lava.Franz.COM> Can someone please explain to me the reason why specialized arguments are automagically referenced in the bodies of methods? Yes, I know that DEFMETHOD is documented to do this; my real question is why this is so. For example, (defmethod adopt ((parent basic-node) (child parentless-mixin)) (error "Attempt to adopt ~S, a parentless child" child)) does not warn that PARENT is an unused variable, and (defmethod adopt ((parent basic-node) (child parentless-mixin)) (declare (ignore parent)) (error "Attempt to adopt ~S, a parentless child" child)) DOES warn that PARENT is used after being declared IGNOREd. It seems to me that this violates a principle of the IGNORE declaration, namely that specific textual references in the body should be what counts for "references". [Of course, by the same reasoning, (dotimes (i n) (declare (ignore i)) (do-something-which-does-not-use-I)) should also be correct, but most implementations warn about the hidden uses of the variable I.] Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02345; Mon, 10 Sep 90 13:34:45 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16643>; Mon, 10 Sep 1990 13:34:17 PDT Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <16640>; Mon, 10 Sep 1990 13:31:10 PDT Received: by atc.boeing.com on Mon, 10 Sep 90 13:29:05 PDT X-Ns-Transport-Id: 08002008D0FD00020888 Date: Mon, 10 Sep 1990 13:28:00 PDT From: Stephen L Nicoud Subject: DEFMETHOD automagic references considered random In-Reply-To: "The message of 10 Sep 90 12:54 PDT from rsl@ILA.COM" To: rsl@ILA.COM Cc: commonloops.PARC@Xerox.com Message-Id: <19900910202821.9.SNICOUD@SKAGIT.atc.boeing.com> Date: 10 Sep 90 19:54:55 GMT From: rsl@ILA.COM [description of inconsistencies of UNUSED/IGNORE'd variables in DEFMETHOD and DOTIMES] A rather lengthy debate/discussion ensued in late July/eary August when I broached the subject to the Common Lisp mailing list (common-lisp@mcc.com) of the contradictory behavior of IGNORE declarations in DOTIMES. I believe a proposal will be made at the next ANSI Common Lisp Committee (X3J13) meeting which will attempt to address this issue. In the mean time, you're probably stuck with the inconsistent behavior. I believe I still have the messages from that discussion and can forward them to you if you desire. Steve -- Stephen L. Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01645; Mon, 10 Sep 90 16:20:49 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16247>; Mon, 10 Sep 1990 16:20:37 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16247>; Mon, 10 Sep 1990 16:12:58 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA06360g; Mon, 10 Sep 90 16:07:45 PDT Received: by caligula id AA15538g; Mon, 10 Sep 90 16:10:06 PDT X-Ns-Transport-Id: 08002008D0FD00020AA2 Date: Mon, 10 Sep 1990 16:10:06 PDT From: Jon L White Subject: DEFMETHOD automagic references considered random In-Reply-To: "rsl@ILA.COM's message of Mon, 10 Sep 1990 10:54:52 PDT <9009101754.AA04230@lava.Franz.COM>" To: rsl@ILA.COM Cc: CommonLoops.PARC@xerox.com Message-Id: <9009102310.AA15538@caligula> re: Can someone please explain to me the reason why specialized arguments are automagically referenced in the bodies of methods? Part of the purpose of the specialized variables is to do method selection "within the generic function itself"; so there is a sense in which the formal parameter variable is being indirectly referenced. For example, in the following generic function WHAT-COUNT, no method at all explicitly references the variable "x"; (defmethod what-count ((x foo)) 1) (defmethod what-count ((x bar)) 2) (defmethod what-count ((x baz)) 3) but the discrimination must have referenced it implicitly, just as surely as if it had been written as a non-generic function as follows: (defun what-count (x) (etypecase x (foo 1) (bar 2) (baz 3))) -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29017; Tue, 11 Sep 90 09:18:39 -0700 Received: from GoldenMail.Parc.Xerox.xns by alpha.xerox.com via XNS id <16649>; Tue, 11 Sep 1990 09:18:10 PDT X-Ns-Transport-Id: 0000AA007B742B512AA2 Date: Tue, 11 Sep 1990 09:13:33 PDT From: rsl@max-fleischer.sf.dialnet.ila.com Subject: DEFMETHOD automagic references considered random In-Reply-To: <9009102310.AA15538@caligula> To: jonl@lucid.COM Cc: CommonLoops.PARC@xerox.com, rsl@max-fleischer.sf.dialnet.ila.com Reply-To: rsl@ILA.COM Message-Id: <"11-Sep-90 9:13:33 PDT".*.rsl@MAX-FLEISCHER.SF.DIALNET.ILA.COM> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Richard Lamson Subject: DEFMETHOD automagic references considered random To: Jon L White cc: CommonLoops.PARC, rsl@MAX-FLEISCHER.SF.Dialnet.ILA.COM In-Reply-To: <9009102310.AA15538@caligula> Reply-To: rsl@ILA.COM Return-Path: <@FUJI.ILA.COM:rsl@MAX-FLEISCHER.SF.DIALNET.ILA.COM> Received: from FUJI.ILA.COM ([140.186.2.33]) by Xerox.COM ; 11 SEP 90 09:13:21 PDT Received: from MAX-FLEISCHER.SF.DIALNET.ILA.COM by FUJI.ILA.COM via DIAL with SMTP id 55742; 11 Sep 90 12:08:26 EDT Original-Date: Mon, 10 Sep 90 18:47 PDT Message-ID: <19900911014743.9.RSL@MAX-FLEISCHER.SF.Dialnet.ILA.COM> Line-fold: No GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV Date: Mon, 10 Sep 90 16:10:06 PDT From: Jon L White re: Can someone please explain to me the reason why specialized arguments are automagically referenced in the bodies of methods? Part of the purpose of the specialized variables is to do method selection "within the generic function itself"; so there is a sense in which the formal parameter variable is being indirectly referenced. For example, in the following generic function WHAT-COUNT, no method at all explicitly references the variable "x"; (defmethod what-count ((x foo)) 1) (defmethod what-count ((x bar)) 2) (defmethod what-count ((x baz)) 3) but the discrimination must have referenced it implicitly, just as surely as if it had been written as a non-generic function as follows: (defun what-count (x) (etypecase x (foo 1) (bar 2) (baz 3))) I think this is the same argument as this other related issue: Suppose I write a function which takes keywords, and, although I don't care what value is passed in for a particular keyword, I wish to know whether or not that keyword was actually passed in: (defun random-test (&rest all-the-stuff &key (nonsense nil nonsense-p) &allow-other-keys) (if nonsense-p (apply nonsensical-random-test all-the-stuff) (apply no-nonsense-random-test all-the-stuff))) Is the compiler correct in warning me that I do not use the value of the lexical variable NONSENSE? I claim that I must supply an IGNORE declaration for NONSENSE if I want to suppress that warning. I base this philosophically on the argument that the variable NONSENSE is not referenced anywhere in the scope of its binding. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11870; Tue, 11 Sep 90 17:43:35 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16663>; Tue, 11 Sep 1990 17:43:28 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16652>; Tue, 11 Sep 1990 17:38:20 PDT Received: by spade.parc.xerox.com id <274>; Tue, 11 Sep 1990 17:38:00 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00021593 Date: Tue, 11 Sep 1990 17:37:50 PDT Xns-Originator: <@spade.parc.xerox.com:gregor@xerox.COM> Sender: gregor@parc.xerox.com Errors-To: From: Gregor Kiczales , kiuchi.pa@arisia.Xerox.COM Subject: change to mailing list format To: CommonLoops.PARC@xerox.com Message-Id: <90Sep11.173800pdt.274@spade.parc.xerox.com> Many people suggested that it would be better to form a new usenet newsgroup and also keep a mailing list. Then, the two could be gatewayed --- people who like usenet could read it there, people who like email could keep getting email. We have checked out what it would take to do this, and it seems pretty straightforward. So, we would like to proceed with this plan. The first step is to convince the usenet community that it makes sense to form a new newsgroup for us. I just posted a call for discussion of a new newsgroup to news.announce.newgroups, comp.lang.lisp and comp.object. It would be great if those of you who do read usenet, and who would like to see a usenet newsgroup version of this mailing list could support this action in the discussion there. In a couple of weeks, there will be an actual vote in the usenet forum, we will let you know when that happens. Following is the text of the message that we sent to propose the new newsgroup. Gregor Yasuhiko -------- We propose forming a new usenet newsgroup called comp.object.clos. This would be an unmoderated forum for discussion of the Common Lisp Object System (CLOS) object-oriented programming language. Topics appropriate for disucssion would include: programming techniques, implementation techniques, comments about existing implementations, extensions to the language, relation to other object-oriented programming languages, educational materials etc. For those of you who may be unfamiliar with CLOS, it is part of the emerging ANSI standard for Common Lisp. At present, there at least 10 CLOS implementations in the market or under development. The formation of this newsgroup is part of a two step process of reorganizing the existing CommonLoops@Xerox.com mailing list. Currently, this mailing list is the largest CLOS users mailing list, we estimate that over eight hundred people receive it as email. In the first step, this mailing list will be moved and renamed to CLOS@MCC.COM. The second step, pending approval of the usenet community, is to create the new newsgroup and gateway it with this mailing list. This new gatewayed format will allow many of the people who currently have technical trouble reading the mailing list to get access to it. In addition, we beileve that the nature of the discussion is such that many people would prefer to receive it as a newsgroup. We estimate that several hundred of the people who currently receive the mailing list as email will immediately switch to reading it as a usenet newsgroup. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17612; Wed, 12 Sep 90 00:15:55 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16661>; Wed, 12 Sep 1990 00:15:41 PDT Received: from mcsun.EU.net ([192.16.202.1]) by alpha.xerox.com with SMTP id <16663>; Wed, 12 Sep 1990 00:05:41 PDT Received: by mcsun.EU.net with SMTP; Wed, 12 Sep 90 09:05:05 +0200 Received: from hcsrnd by hp4nl.nluug.nl with UUCP via EUnet id AA07306 (5.58.1.14/2.14); Wed, 12 Sep 90 09:07:41 MET Received: from client-24. by hcsrnd (4.0/SMI-4.0) id AA23558; Wed, 12 Sep 90 08:56:16 +0200 X-Ns-Transport-Id: 08002008D0FD00021751 Date: Tue, 11 Sep 1990 23:56:16 PDT From: tusveld%hcsrnd.uucp@relay.eu.net (Fred Tusveld) Subject: A request To: CommonLoops.PARC@xerox.com Message-Id: <9009120656.AA23558@hcsrnd> Please add me to your mailing-list. Thanks in advance. Fred Tusveld HCS Technology, Industrial Automation, R&D Landdrostlaan 51, 7302 HA Apeldoorn The Netherlands tel. +31 55 498600 tusveld@hcsrnd.uucp.nl or hcsrnd!tusveld@relay.EU.net Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01118; Thu, 13 Sep 90 22:38:07 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16708>; Thu, 13 Sep 1990 22:37:57 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16703>; Thu, 13 Sep 1990 22:34:24 PDT Received: from kddlab.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA03605; Fri, 14 Sep 90 01:33:45 -0400 Received: by kddlab.kddlabs.co.jp (4.0/6.2Junet) id AA05317; Fri, 14 Sep 90 14:26:58 JST Received: from atr-hr.atr.co.jp by atrpost.atr.co.jp (3.2/6.4J.6-atr1.0) id AA25898; Fri, 14 Sep 90 13:50:18 JST Received: by atr-hr.atr.co.jp (1.2/6.4J.6-atr1.0) id AA14614; Fri, 14 Sep 90 13:48:31+0900 Return-Path: X-Ns-Transport-Id: 08002008D0FD000229DC Date: Fri, 14 Sep 1990 06:48:00 PDT Sender: useq%kddlab.uucp@uunet.uu.NET From: ebg%atr-hr.atr.co.jp%kddlab.uucp@uunet.uu.NET (Edward B. Gamble) Subject: Problem with type declarations in PCL. To: JonL@lucid.COM Cc: CommonLoops.PARC@xerox.com, ebg@ai.mit.EDU Message-Id: <9009140448.AA14614@atr-hr.atr.co.jp> I've been trying to load PCL (dated 5/1/90 May Day PCL (Rev 2)) and CLX (from the X11R4 distribution). CLX refuses to compile because of errors such as: ;;; After loading PCL... > (xlib::compile-clx) ;;; Default paths: #P"" #P"" ;;; cc -c socket.c -o socket.o -DUNIXCONN ;;; Loading foreign files ;;; Loading foreign object file "socket.o" ;;; Reading library file "/lib/libc.a" ;;; You are using the compiler in production mode (compilation-speed = 0) ;;; Generation of argument count checking code is enabled (safety = 1) ;;; Optimization of tail calls is enabled (speed = 3) ;;; Reading source file "depdefs.lisp" ;;; Writing binary file "depdefs.sbin3" ;;; Loading binary file "depdefs.sbin3" ;;; Reading source file "clx.lisp" ;;; Expanding Reserved Memory ;;; GC: 188394 words [753576 bytes] of dynamic storage in use. ;;; 270356 words [1081424 bytes] of free storage available before a GC. ;;; 729106 words [2916424 bytes] of free storage available if GC is disabled. ;;; While compiling PRINT-COLOR ;;; Warning: Illegal type specifier in (TYPE COLOR COLOR) ;;; While compiling COLOR-RGB ;;; Warning: Illegal type specifier in (TYPE COLOR COLOR) ;;; While compiling PRINT-DISPLAY ;;; Warning: Illegal type specifier in (TYPE DISPLAY DISPLAY) ;;; While compiling PRINT-DRAWABLE ;;; Warning: Illegal type specifier in (TYPE DRAWABLE DRAWABLE) ...at this point I stopped the compilation. Had I let it continue, the compiler would stop when compiling image.lisp in the CLX distribution owing to similar errors. This problem will not occur if I compile CLX with the PCL distributed by SUN. Are you familier with this bug? Is it something easily fixed? Is this issue moot in SunOS 4.1? My company doesn't have 4.1 yet because our Connection Machine software is currently not compatible with 4.1 I'd appreciate your help. E-mail to Japan can be flakey. Please call if possible (connect to Japan (country code 81) then dial all these numbers) 07747-2-4913. If nobody answers try 07749-5-1438. Ed Gamble ATR Auditory and Visual Processing Labs Seika-cho Soraku-gun Kyoto 619-02 Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09607; Fri, 14 Sep 90 09:21:17 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16749>; Fri, 14 Sep 1990 09:21:10 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16750>; Fri, 14 Sep 1990 09:16:57 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA21946g; Fri, 14 Sep 90 09:11:35 PDT Received: by caligula id AA20436g; Fri, 14 Sep 90 09:14:03 PDT X-Ns-Transport-Id: 08002008D0FD00022D6D Date: Fri, 14 Sep 1990 09:14:03 PDT From: Jon L White Subject: Problem with type declarations in PCL. In-Reply-To: "Edward B. Gamble's message of Fri, 14 Sep 90 13:48:31+0900 <9009140448.AA14614@atr-hr.atr.co.jp>" To: ebg%atr-hr.atr.co.jp%kddlab.uucp@uunet.UU.NET Cc: CommonLoops.PARC@xerox.com, ebg@ai.mit.EDU Message-Id: <9009141614.AA20436@caligula> re: This problem will not occur if I compile CLX with the PCL distributed by SUN. Are you familier with this bug? Is it something easily fixed? The symptoms you reproduced are not immediately familiar to me as a particular PCL problem, nor would I expect the SunOS version to be a factor at all. What exactly is the version of Common Lisp you have? is it Sun Common Lisp 3.0 for the Sun4 machine? Also, what is the version name of "the PCL distributed by SUN?" The more recent PCL -- called "May Day" and dated around the 2'nd of May 1990 -- would probably be more correct. -- JonL -- P.S. I'm continuing the reply to the CommonLoops mailing list simply because such incompatibilities between versions of Sun Common Lisp, PCL, and X11 might be relevant to other readers. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10467; Fri, 14 Sep 90 09:50:04 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16763>; Fri, 14 Sep 1990 09:49:49 PDT Received: from aplcen.apl.jhu.edu ([128.220.101.4]) by alpha.xerox.com with SMTP id <16751>; Fri, 14 Sep 1990 09:41:37 PDT Received: by aplcen.apl.jhu.edu (5.57/Ultrix2.4-XDccg) id AA26934; Fri, 14 Sep 90 12:39:44 -0400 X-Mailer: Mail User's Shell (6.1 4/26/88) X-Ns-Transport-Id: 08002008D0FD00022DC9 Date: Fri, 14 Sep 1990 09:39:44 PDT From: hall@aplcen.apl.jhu.EDU (Marty Hall) Subject: Comp.object.clos? To: CommonLoops.PARC@xerox.com Message-Id: <9009141639.AA26934@aplcen.apl.jhu.edu> Gregor mentioned that a call for discussion re comp.object.clos was going out on the Usenet groups comp.object, comp.lang.lisp, etc. I did not see the announcement in either group. Did it go out? - Marty Hall Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10671; Fri, 14 Sep 90 09:58:23 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16757>; Fri, 14 Sep 1990 09:57:47 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16750>; Fri, 14 Sep 1990 09:53:29 PDT Received: by spade.parc.xerox.com id <273>; Fri, 14 Sep 1990 09:53:17 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00022E13 Date: Fri, 14 Sep 1990 09:53:07 PDT Sender: From: Gregor Kiczales Subject: Re: Comp.object.clos? In-Reply-To: "Marty Hall's message of Fri, 14 Sep 1990 09:39:44 PDT <9009141639.AA26934@aplcen.apl.jhu.edu>" To: hall@aplcen.apl.jhu.EDU Cc: CommonLoops.PARC@xerox.com Message-Id: <90Sep14.095317pdt.273@spade.parc.xerox.com> The message was posted to those lists and news.announce.newgroups. Because the latter is moderated, it has to wait until the moderator decides to send it out. Which I was told would be today. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15819; Fri, 14 Sep 90 12:10:40 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16709>; Fri, 14 Sep 1990 12:10:26 PDT Received: from TAMU.EDU ([128.194.15.2]) by alpha.xerox.com with SMTP id <16710>; Fri, 14 Sep 1990 12:08:38 PDT Received: from snaefell.tamu.edu.tamu.edu (SNAEFELL.TAMU.EDU) by TAMU.EDU (AA27139); Fri, 14 Sep 90 14:06:35 CDT Received: by snaefell.tamu.edu.tamu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA16203; Fri, 14 Sep 90 14:06:22 CDT X-Ns-Transport-Id: 08002008D0FD0002309C Date: Fri, 14 Sep 1990 12:06:22 PDT From: colin@snaefell.tamu.EDU (Colin Allen) Subject: Problem compiling pcl (5/5/90) on NeXT 1.0/Allegro Common Lisp To: CommonLoops.PARC@xerox.com Message-Id: <9009141906.AA16203@snaefell.tamu.edu.tamu.edu> Greg, I am cc-ing this to CommonLoops@xerox.arpa--I hope that is the right address for that group. Thanks for the info. excl-low is getting compiled and loaded, and I can't immediately see anything wrong in defs, and it too is compiled and loaded successfully. Here's a more detailed description of what is happening while running pcl::pcl-compile; after the file vector.cl is successfully compiled, and during the load of vector.fasl, this message appears: attempt to call `|SETF PCL gdefinition|' which is an undefined function. If continued, prompt for a new function, instead of `|SETF PCL gdefinition|'. HERE'S WHAT I HAVE BEEN ABLE TO FIND OUT FROM THE DEBUGGER: [1c] :zoom Evaluation stack: ->(cerror "prompt for a new function, instead of `~s'." "attempt to call `~s' which is an undefined function." ...) (ensure-generic-function-using-class nil wrapper-fetcher) (ensure-generic-function wrapper-fetcher) (early-add-named-method wrapper-fetcher nil ...) (add-named-method wrapper-fetcher nil ...) (load-defmethod-internal wrapper-fetcher nil ...) (nil) (excl::fasload #) ... more older frames ... FROM THIS IT SEEMS LIKE THE LAST FUNCTION CALLED BEFORE THE ERROR IS ENSURE-GENERIC-FUNCTION-USING-CLASS. SO, I DID A BIT OF EXPLORATION TO TRY TO FIND OUT WHY IT HAD BOMBED OUT. THE FIRST THING IT DOES IS PUSH THE NEW ITEM ONTO THE LIST *EARLY-GENERIC-FUNCTIONS*, SO I CHECKED IT OUT... [1c] *early-generic-functions* (wrapper-fetcher) SO THAT HAS BEEN DONE. THE NEXT THING IT DOES IS SET THE GDEFINITION OF THE NEW ITEM TO A VALUE, WHICH IS APPARENTLY NOT HAPPENING... [1c] (gdefinition 'wrapper-fetcher) Error: Symbol wrapper-fetcher does not have a function definition. Restart actions (select using :continue): 0: prompt for a new function, instead of `|SETF PCL gdefinition|'. [2] :pop Previous error: attempt to call `|SETF PCL gdefinition|' which is an undefined function. If continued, prompt for a new function, instead of `|SETF PCL gdefinition|'. [1c] (gethash 'gdefinition *setf-function-names*) |SETF PCL gdefinition| t SO IT APPEARS TO ME THAT SOMETHING IS WRONG WITH THE DEFINITION OF GDEFINITIONS IN DEFS.CL AFTER ALL. TROUBLE IS I DON'T KNOW WHAT! Any help is much appreciated!! Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17405; Fri, 14 Sep 90 12:56:01 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16720>; Fri, 14 Sep 1990 12:55:33 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16716>; Fri, 14 Sep 1990 12:51:13 PDT Received: by spade.parc.xerox.com id <275>; Fri, 14 Sep 1990 12:50:48 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002312E Date: Fri, 14 Sep 1990 12:50:43 PDT Sender: From: Gregor Kiczales Subject: Re: Problem compiling pcl (5/5/90) on NeXT 1.0/Allegro Common Lisp In-Reply-To: "Colin Allen's message of Fri, 14 Sep 1990 11:58:33 PDT <9009141858.AA16167@snaefell.tamu.edu.tamu.edu>" To: colin@snaefell.tamu.EDU Cc: CommonLoops.pa@arisia.Xerox.COM Message-Id: <90Sep14.125048pdt.275@spade.parc.xerox.com> I believe I see your problem now. You are using franz common lisp in its lowercase (or case preserving) mode. Apparently, some of the definitions of GDEFINITION and friends don't work properly in the mode. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18923; Fri, 14 Sep 90 14:02:11 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16719>; Fri, 14 Sep 1990 14:02:03 PDT Received: from TAMU.EDU ([128.194.15.2]) by alpha.xerox.com with SMTP id <16701>; Fri, 14 Sep 1990 14:00:42 PDT Received: from snaefell.tamu.edu.tamu.edu (SNAEFELL.TAMU.EDU) by TAMU.EDU (AA29276); Fri, 14 Sep 90 15:58:36 CDT Received: by snaefell.tamu.edu.tamu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA16566; Fri, 14 Sep 90 15:58:19 CDT X-Ns-Transport-Id: 08002008D0FD00023212 Date: Fri, 14 Sep 1990 13:58:19 PDT From: colin@snaefell.tamu.EDU (Colin Allen) Subject: Re: Problem compiling pcl (5/5/90) on NeXT 1.0/All To: Gregor Kiczales Cc: CommonLoops.PARC@xerox.com Message-Id: <9009142058.AA16566@snaefell.tamu.edu.tamu.edu> Greg, pcl compiled correctly. The offending piece of code in defsys.cl was the following: #+allegro (case *current-case-mode* (:case-sensitive-lower (user::set-case-mode :case-insensitive-lower)) (:case-sensitive-upper (user::set-case-mode :case-insensitive-upper))) The second to last line here should say: (:case-sensitive-lower (user::set-case-mode :case-insensitive-upper)) Another problem with this piece of code is that it should come before the (in -package "PCL") statement. Otherwise, the variable *current-case-mode* is not recognized. (I guess this could also be fixed by prefixing excl: rather than moving the lines). Thanks for the help. Colin Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19201; Fri, 14 Sep 90 14:15:12 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16721>; Fri, 14 Sep 1990 14:14:51 PDT Received: from nettlerash.berkeley.edu ([128.32.136.9]) by alpha.xerox.com with SMTP id <16727>; Fri, 14 Sep 1990 14:13:02 PDT Received: from icsib1.Berkeley.EDU by nettlerash.berkeley.edu (5.64/1.34+1) id AA08144; Fri, 14 Sep 90 14:12:34 -0700 Received: by icsib1.berkeley.edu. (4.0/SMI-4.0) id AA11218; Fri, 14 Sep 90 14:10:57 PDT Illegal-Object: Syntax error in Message-Id: value found on alpha.xerox.com: Message-Id: <9009142110.AA11218@icsib1.berkeley.edu.> ^-illegal subdomain in domain X-Ns-Transport-Id: 08002008D0FD0002322D Date: Fri, 14 Sep 1990 14:10:57 PDT From: hws@icsib1.berkeley.EDU (Heinz Schmidt) Subject: Problem compiling pcl (5/5/90) on NeXT 1.0/Allegro Common Lisp In-Reply-To: "Colin Allen's message of Fri, 14 Sep 1990 12:06:22 PDT <9009141906.AA16203@snaefell.tamu.edu.tamu.edu>" To: colin@snaefell.tamu.EDU Cc: CommonLoops.PARC@xerox.com Message-Id: <90Sep14.141302pdt.16727@alpha.xerox.com> > attempt to call `|SETF PCL gdefinition|' which is an undefined function. > If continued, prompt for a new function, instead of `|SETF PCL gdefinition|'. This reads like your excl distinguishes lower and uppercase. This messes up PCL. Here are the first few lines of the init file I use on the Next (set-case-mode :case-insensitive-upper) (in-package 'user) (proclaim '(optimize (speed 3) (safety 1) (space 0))) (setq *print-nickname* t) ; print package nicknames instead of full names (setq *redefinition-warnings* t) -- Heinz -------------------------------------------------------------------------- Heinz W. Schmidt hws@icsi.berkeley.edu International Computer Science Institute, Berkeley (415) 642-4275 x175 Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20035; Fri, 14 Sep 90 14:53:11 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16719>; Fri, 14 Sep 1990 14:52:58 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16720>; Fri, 14 Sep 1990 14:50:54 PDT Received: from LNCC.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2508; Fri, 14 Sep 90 17:48:20 EDT X-Ns-Transport-Id: 08002008D0FD0002327E Date: Fri, 14 Sep 1990 15:41:42 PDT Sender: From: Andre de Souza Mello Valente Subject: A CLOS testing program and more... To: CommonLoops.PARC@xerox.com Message-Id: <20267@LNCC.BITNET> I am looking for some additional information and aid about CLOS. If anybody can help me, thank you! a) I am looking for a program to test a CLOS implementation. I think that maybe some people from Franz, Coral, Xerox, Symbolics, etc. can have something like this. I am also looking for a good "example" program (the type you put in a presentation). It should be simple, please. I tried the examples of Sonia Keene's book, but they are quite difficult and strange to my target public (beginners). Of course I can create such one, but it is like reinventing the wheel... b) I am looking for an E-mail contact in Gold Hill, to discuss some aspects about a CLOS implementation in GCL. I am having trouble with some implemantation-specific aspects of GCL. c) I am looking for a paper or more lengthy work about the history of POO in Lisp. I have papers about Loops (Common Loops, PCL), CommonObjects, ObjVLisp, Flavors and Oaklisp, but no one telling how was this evolution in a "neutral" perspective. By the way, if anybody knows about any other OOLisp, please tell me. d) I have seen a lot of references to a CL Cleanup Comitee. How can I get basic/detailed information about it? Is there any documentation about its work? e) Is there any new version of document 88-002R available? Is it planned to write such one? I have the version that was published in SIGPLAN Notices in 1988. Thanks, Andre Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27837; Fri, 14 Sep 90 23:47:15 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16717>; Fri, 14 Sep 1990 23:47:01 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16717>; Fri, 14 Sep 1990 23:44:33 PDT Received: from kddlab.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA00732; Sat, 15 Sep 90 02:44:01 -0400 Received: by kddlab.kddlabs.co.jp (4.0/6.2Junet) id AA04006; Sat, 15 Sep 90 15:30:18 JST Received: from atr-hr.atr.co.jp by atrpost.atr.co.jp (3.2/6.4J.6-atr1.0) id AA22126; Sat, 15 Sep 90 13:01:32 JST Received: by atr-hr.atr.co.jp (1.2/6.4J.6-atr1.0) id AA02385; Sat, 15 Sep 90 12:59:40+0900 Return-Path: X-Ns-Transport-Id: 08002008D0FD00023554 Date: Sat, 15 Sep 1990 05:59:00 PDT Sender: useq%kddlab.uucp@uunet.UU.NET From: ebg%atr-hr.atr.co.jp%kddlab.uucp@uunet.UU.NET (Edward B. Gamble) Subject: Problem with type declarations in PCL. In-Reply-To: "Jon L White's message of Fri, 14 Sep 90 09:14:03 PDT <9009141614.AA20436@caligula>" To: jonl@lucid.COM Cc: CommonLoops.PARC@xerox.com Message-Id: <9009150359.AA02385@atr-hr.atr.co.jp> All the following is based on Sun Common Lisp 3.0 for the Sun-4 with patches loaded -> 3.0.1. The production compiler is loaded either on top of lisp-3-0-base or from lisp-3-0-full. 1) CLX compiles (and runs my limited examples) if it is compiled before PCL is loaded. (CLX use defstruct in that case; not defclass) 2) I have not tried compiling CLX on top of Sun's PCL "8/24/88 (beta) AAAI PCL" Actually, I don't remember if I've tried... 3) For May Day PCL (Rev 2) 5/1/90 : It seems that at compile time PCL classes do not have a known type. CLX uses lots of forms like this: (defclass foo () ()) (defun bar (a-foo) (declare (type foo a-foo)) ) (defun baz (a-foo) (identity (the foo a-foo))) Compilation of the above forms produces: > (compile-file "test.lisp") ;;; Reading source file "test.lisp" ;;; While compiling BAR ;;; Warning: Illegal type specifier in (TYPE FOO A-FOO) >>Error: FOO is an unknown type. LUCID:COMPILE-FORM: :A 0: Abort to Lisp Top Level -> 0 ;;; Backtrace shows that compiler is processing 'BAZ when the error occurs. Whose error is this: PCL's, CLX's, or mine? -- Ed Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10312; Sat, 15 Sep 90 20:01:04 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16788>; Sat, 15 Sep 1990 20:00:43 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16771>; Sat, 15 Sep 1990 17:45:08 PDT Received: by spade.parc.xerox.com id <287>; Sat, 15 Sep 1990 17:35:44 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00023794 Date: Sat, 15 Sep 1990 17:35:32 PDT Sender: From: Gregor Kiczales Subject: Re: Problem with type declarations in PCL. In-Reply-To: "Edward B. Gamble's message of Sat, 15 Sep 1990 05:59:00 PDT <9009150359.AA02385@atr-hr.atr.co.jp>" To: ebg%atr-hr.atr.co.jp%kddlab.uucp@uunet.UU.NET Cc: jonl@lucid.COM, CommonLoops.PARC@xerox.com Message-Id: <90Sep15.173544pdt.287@spade.parc.xerox.com> Date: Sat, 15 Sep 1990 05:59:00 PDT From: ebg%atr-hr.atr.co.jp%kddlab.uucp@uunet.UU.NET (Edward B. Gamble) It seems that at compile time PCL classes do not have a known type. CLX uses lots of forms like this: (defclass foo () ()) (defun bar (a-foo) (declare (type foo a-foo)) ) ;;; Warning: Illegal type specifier in (TYPE FOO A-FOO) >>Error: FOO is an unknown type. Put the following somewhere in your stuff, or edit the definition of this variable that appears in defs.lisp: (push 'compile pcl::*defclass-times*) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04430; Mon, 17 Sep 90 09:53:16 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16792>; Mon, 17 Sep 1990 09:42:50 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16787>; Mon, 17 Sep 1990 09:33:59 PDT Received: from hawaii.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA19738; Mon, 17 Sep 90 12:33:20 -0400 Received: by hawaii.odb.com (4.0/SMI-4.0) id AA14364; Mon, 17 Sep 90 12:08:42 EDT X-Ns-Transport-Id: 08002008D0FD00023E7F Date: Mon, 17 Sep 1990 09:08:42 PDT Sender: krugg%odb.com%hawaii.uucp@uunet.UU.NET From: krugg@odb.com (Kenneth W. Rugg) Subject: A CLOS testing program and more... In-Reply-To: "Andre de Souza Mello Valente's message of Fri, 14 Sep 1990 15:41:42 PDT <20267@LNCC.BITNET>" To: USERASMV%LNCC.BITNET%CUNYVM.CUNY.EDU%uunet.uucp@uunet.UU.NET Cc: CommonLoops.PARC@xerox.com Message-Id: <9009171608.AA14364@hawaii.odb.com> > b) I am looking for an E-mail contact in Gold Hill, to discuss some > aspects about a CLOS implementation in GCL. I am having trouble with > some implemantation-specific aspects of GCL. Unfortunately there isn't any email access to Gold Hill. I used to work there so if you have specific questions I might be able to help a bit, but it has been a while, almost a year, since I worked there so I may be a bit rusty. I assume that you have their telephone number. If not it's (617) 621-3300. I know it's sometimes better to have implementation discussions via email though (easier to get the parens to match. :-) I did work on the lisp implementation as well as the (very) quick and dirty port of PCL to GCLisp, but as I said I am a bit rusty. I've been doing mostly C with a little bit of SmallTalk and Lucid Lisp programming of late. Anyway feel free to ask and I'll try to help. Also I know a few other folks that might be helpful that I may be able to get in touch with. We (the developers) always wanted to do a real object system, but always had other deliverables to address. Anyway... Best of Luck, Ken Rugg, Object Databases krugg@odb.com Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01817; Wed, 19 Sep 90 13:27:13 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16843>; Wed, 19 Sep 1990 13:16:51 PDT Received: from ptolemy.arc.nasa.gov ([128.102.25.4]) by alpha.xerox.com with SMTP id <16839>; Wed, 19 Sep 1990 13:05:59 PDT Received: from rayleigh.arc.nasa.gov by ptolemy.arc.nasa.gov (4.1/) id ; Wed, 19 Sep 90 13:04:26 PDT Path: ptolemy!philpot Newsgroups: ri.commonloops Organization: NASA-Ames Research Center, Moffett Field, CA Lines: 39 X-Ns-Transport-Id: 08002008D0FD000253D1 Date: Wed, 19 Sep 1990 13:04:18 PDT From: philpot@ptolemy.arc.nasa.GOV (philpot) Subject: EQL specializers To: CommonLoops.PARC@Xerox.com Message-Id: <8118@rayleigh.ptolemy.arc.nasa.gov> Is there any good reason that the following, (in-package :pcl) (defmethod divide ((dividend number) (divisor number)) (/ dividend divisor)) (defmethod divide ((dividend number) (zero (eql 0))) (error "Cannot divide by zero.")) which was taken from Keene, p. 94, should not work in PCL? Actually, I get an error message at load time, to the following effect: Error: No matching method for the generic-function #, when called with arguments ((EQL 0)) but then after I abort out of the debugger, instances will reflect the new definition, i.e., (divide 12 0) will be handled specially. I am using: PCL system date: 5/22/89 Victoria Day PCL Lisp Implementation type: Allegro CL Lisp Implementation version: 3.1.13 [Sun3] (4/24/90) *features*: (:LOOP LOOP :COMPOSER :FAKE-ACTIVE-REGIONS :PCL :CLOS :BIG-ENDIAN :GSGC :M68881 :M68020 :ALLEGRO-V3.1 :FRANZ-INC :EXCL :ALLEGRO :COMMON-LISP :CONFORMING-IEEE :IEEE :FLAVORS :SUNOS4.0 :SUN :M68K :SUN3 :UNIX :NASA-RIA :MULTIPROCESSING :CLX :XLIB :CLX-MIT-R4 :CLX-CL-ERROR :CW-X) I am told that we cannot upgrade to the newer May Day PCL because of Franz incompatibilities. If the fix to this is only available in May Day, then I guess I will just patch CLASS-NAME locally and live with it. Andrew Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03117; Wed, 19 Sep 90 13:55:24 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16797>; Wed, 19 Sep 1990 13:55:13 PDT Received: from roo.parc.xerox.com ([13.2.16.72]) by alpha.xerox.com with SMTP id <16844>; Wed, 19 Sep 1990 13:49:25 PDT Received: by roo.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA25456; Wed, 19 Sep 90 13:49:04 PDT X-Ns-Transport-Id: 08002008D0FD00025446 Date: Wed, 19 Sep 1990 13:49:04 PDT From: Gregor Kiczales Subject: Re: EQL specializers In-Reply-To: "philpot's message of Wed, 19 Sep 1990 13:04:18 PDT <8118@rayleigh.ptolemy.arc.nasa.gov>" To: philpot@ptolemy.arc.nasa.GOV Cc: CommonLoops.PARC@xerox.com Message-Id: <9009192049.AA25456@roo.parc.xerox.com> I forget at little about that older version of PCL, but I think it doesn't support EQL specializers. That would certainly explain the kind of error you are getting. To get eql specializers, you will have to use a newer version of PCL. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11154; Thu, 20 Sep 90 17:34:15 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16859>; Thu, 20 Sep 1990 17:34:08 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16859>; Thu, 20 Sep 1990 17:26:14 PDT Received: by spade.parc.xerox.com id <236>; Thu, 20 Sep 1990 17:25:19 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00026009 Date: Thu, 20 Sep 1990 17:25:16 PDT Sender: From: Gregor Kiczales Subject: comp.object.clos To: CommonLoops@arisia.Xerox.COM Message-Id: <90Sep20.172519pdt.236@spade.parc.xerox.com> The discussion about the new comp.object.clos newsgroup is now active on news.newgroups. If you have an interest in getting this mailing list and expanded CLOS discussion in the usenet format, you might want to post a message of support in that forum. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21786; Fri, 21 Sep 90 07:07:33 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16915>; Fri, 21 Sep 1990 07:07:21 PDT Received: from lanai.cs.ucla.edu ([131.179.128.13]) by alpha.xerox.com with SMTP id <16915>; Fri, 21 Sep 1990 07:02:40 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA16266; Fri, 21 Sep 90 07:00:26 -0700 X-Ns-Transport-Id: 08002008D0FD00026380 Date: Fri, 21 Sep 1990 07:00:26 PDT From: Trent Lange Subject: Compilation of methods per class. To: commonloops.PARC@Xerox.com Message-Id: <900921.140026z.16258.lange@lanai.cs.ucla.edu> Has anybody developed a method class that "compiles" methods by building a separate big lambda for each method on each class? The finalized method lambda for each class would have method selection and combination already done (with the code for auxiliary methods and call-next-methods embedded within them). ---- E.g. Given: (defmethod foo ((self class1)) (foo-class1-body)) (defmethod foo :around ((self class2)) (foo-class2-body-begin) (call-next-method) (foo-class2-body-end)) (defmethod foo :after ((self class3)) (foo-class3-body)) (defclass runtime12 (class2 class1) ()()) (defclass runtime13 (class3 class1) ()()) With this, the compiled foo method's lambda for runtime12 would end up (roughly) something like: (defun foo-runtime12-lambda (self) (foo-class2-body-begin) (funcall #'foo-class1-lambda self) (foo-class2-body-end)) And for runtime13: (defun foo-runtime13-lambda (self) (funcall #'foo-class1-lambda self) (funcall #'foo-class3-lambda self)) With foo-class1-lambda, etc. being the obvious. --- Although this would take more code size (since each class used at run time would have to have its own lambda for each method), it would seem to dramatically speed up runtime processing, since there wouldn't have to be any method combination each time a method is called. It would especially speed up processing for systems in which inner-loop methods called have several auxilary methods. And as long as their aren't too many different classes with actual instances at runtime, then the extra space needed for the compiled lambdas shouldn't be too large. Of course, it would be especially helpful if we could choose for each method's generic function whether we want it's methods to be compiled by class or not. So, before I go and code this up myself, has anybody done this or a variation of it? Do any of the vendor's CLOS versions do it? And is there a reason that PCL doesn't do it, besides the extra space it would need (and perhaps complexity of PCL)? Thanks, - Trent Lange lange@cs.ucla.edu Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00507; Fri, 21 Sep 90 11:18:25 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16877>; Fri, 21 Sep 1990 11:07:44 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16910>; Fri, 21 Sep 1990 11:03:48 PDT Received: by spade.parc.xerox.com id <236>; Fri, 21 Sep 1990 10:55:57 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD000265B6 Date: Fri, 21 Sep 1990 10:55:48 PDT Sender: From: Gregor Kiczales Subject: comp.object.clos discussion To: CommonLoops@arisia.Xerox.COM Message-Id: <90Sep21.105557pdt.236@spade.parc.xerox.com> Yesterday, I gave the wrong name for the newsgroup in which the followup discussion of the new CLOS newsgroup was being held. The correct name is news.groups. Gregor Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00674; Fri, 21 Sep 90 11:24:19 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16887>; Fri, 21 Sep 1990 11:22:53 PDT Received: from p.lanl.gov ([128.165.4.4]) by alpha.xerox.com with SMTP id <16129>; Fri, 21 Sep 1990 11:09:00 PDT Received: from zaphod.lanl.gov by p.lanl.gov (5.61/1.14) id AA04526; Fri, 21 Sep 90 12:08:16 -0600 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA01898; Fri, 21 Sep 90 12:08:20 MDT X-Ns-Transport-Id: 08002008D0FD000265DE Date: Fri, 21 Sep 1990 11:08:20 PDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Subject: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Fri, 21 Sep 1990 07:00:26 PDT <900921.140026z.16258.lange@lanai.cs.ucla.edu>" To: lange@cs.ucla.EDU Cc: commonloops.PARC@xerox.com Message-Id: <9009211808.AA01898@zaphod.lanl.gov.lanl.gov> > Has anybody developed a method class that "compiles" methods > by building a separate big lambda for each method on each class? > The finalized method lambda for each class would have method selection > and combination already done (with the code for auxiliary methods and > call-next-methods embedded within them). > > ... > > - Trent Lange > lange@cs.ucla.edu This is essentially how KEE does its standard method combination. In essence, the 'generic function' (slot with valueclass 'method' on the unit representing the object owning the method) is built at method definition time rather than at run time. The advantage, as you point out, is that the single lambda representing the code to be executed is in one place, compilable, etc. The main disadvantage is that the CLOS style of method combination seems to fit better with the Lisp style of late binding. The main effect of this is that it becomes difficult to redefine a single method of the generic function at run time, as it is hard to identify just what parts of the final lambda should be removed, changed, or added to. I have an implementation of a CLOS subset that allows defclass, defmethod, etc to be used in a KEE environment with the implementation being in terms of KEE units. This allows a very CLOS'y style to be used with existing KEE applications. A big constraint is that I have not implemented any of the redefinition portions of the CLOS spec due to the limitation described above. Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00967; Fri, 21 Sep 90 11:35:35 -0700 Received: from Cipher.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Fri, 21 Sep 1990 11:35:21 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16873>; Fri, 21 Sep 1990 11:29:41 PDT Received: by spade.parc.xerox.com id <269>; Fri, 21 Sep 1990 11:29:25 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002660E Date: Fri, 21 Sep 1990 11:29:24 PDT Sender: From: Gregor Kiczales Subject: Re: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Fri, 21 Sep 1990 07:00:26 PDT <900921.140026z.16258.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: commonloops.PARC@xerox.com Message-Id: <90Sep21.112925pdt.269@spade.parc.xerox.com> The basic PCL architecture does something very close to what (I believe) you are suggesting. Whether a given port of PCL actually produces code of the same quality as your example would compile to depends on a number of things. First among these is whether the fast %FUNCALL and %APPLY instructions were properly ported. I am not saying that PCL produces exactly the same code, its code looks more like: (defun foo-runtime12 (self) (let ((*next-methods* '#,(list #'foo-class1-lambda self))) (foo-runtime12-inner self))) (defun foo-runtime12-inner (self) (declare (special *next-methods*)) (let ((next-method (car *next-methods*))) (foo-class2-body-begin) (%funcall #'next-method self) ;You should read this as a funcall ;that needs no error-checking. The ;number of arguments are sure to be ;right. (foo-class2-body-end))) As compared to your version: (defun foo-runtime12-lambda (self) (foo-class2-body-begin) (funcall #'foo-class1-lambda self) (foo-class2-body-end)) PCL does the following extra work: % 1 tail-recursive function call (foo-runtime-12 to foo-runtime-12-inner) % special variable binding % special variable access % special variable unbinding * unsafe CAR (memory read) Admittedly, that is a reasonable amount of extra work but it is important to note that the operations marked with "%" instead of "*" wouldn't have to be done in a better port of the PCL architecture. That is, if when rewriting PCL you are allowed to talk to the innards of the compiler and agree about a special place to pass the next methods, you can just pass these in a register, and the tail-recursive fn call can really be a jump. You would still have to do the unsafe CAR though, and the jump would, in all likelyhood, be out-of-line. One other point is that the technique PCL is using avoids the problem of increased code size you point out. In general, the PCL architecture tries pretty hard to decrease the amount of runtime code because back when we first started thinking about it machines had modest sized instruction caches. So, I guess what I am saying is that if you are using PCL, you may not get a tremendous amount of boost out of the optimization you show. It depends on what port you are using. But, there are some related optimizations that may really win for you. For example, consider half-a-dozen classes (c1 - c6), and some generic functions (g1-g3). Suppose that each generic function accepts only one argument, and that each generic function has a method specialized to each class. Suppose moreover, that g1 is the real external entrypoint, and that all methods on g1 must call g2 and g3. (defclass c1 () ()) (defmethod g1 ((x c1)) (defclass c2 () ()) (something-c1 (g2 x) (g3 x))) . . (defmethod g1 ((x c2)) (something-c2 (g2 x) (g3 x))) (defmethod g2 ((x c1)) (defmethod g3 ((x c1)) ..) ..) (defmethod g2 ((x c2)) (defmethod g3 ((x c2)) ..) ..) . . . . The point being that once you are inside a method on g1, you can know what method on g2 and g3 you will end up calling. Then, it is worth rewriting methods for g1, that have direct calls to the appropriate methods for g2 and g3. PCL doesn't do this, I wish it did. The best work on doing stuff like this is, to my knowledge, the SELF work done at Stanford. One final note, when thinking about CLOS implementation, I have found it easier to keep my thoughts straight if I avoid the use of phrases like "each class would have its own code for each method." Thinking of methods as being associated with classes seems to make it difficult to generalize to multi-methods. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19987; Sat, 22 Sep 90 11:28:49 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16933>; Sat, 22 Sep 1990 11:28:20 PDT Received: from sunc7.cs.uiuc.edu ([128.174.244.87]) by alpha.xerox.com with SMTP id <16933>; Sat, 22 Sep 1990 11:24:43 PDT Received: from localhost.cs.uiuc.edu by sunc7.cs.uiuc.edu with SMTP (5.62+/IDA-1.2.8) id AA18642; Sat, 22 Sep 90 13:24:04 -0500 X-Ns-Transport-Id: 08002008D0FD00026C84 Date: Sat, 22 Sep 1990 11:24:01 PDT From: carroll@suna0.cs.uiuc.edu Subject: Possible bug in kcl-low.lsp To: commonloops.PARC@xerox.com Message-Id: <9009221824.AA18642@sunc7.cs.uiuc.edu> Setup: Interactive SysV3.2, '386, AKCL 492, 5/1/90 MayDay (2) PCL. I applied to the kcl-mods.text patchs to AKCL, made AKCL, and then tried to compile PCL. The compilation failed in kcl-low.lsp. The problem was that in the function cclosure_env_nthcdr (defined using (clines)), a reference is made to env->cc_env. The compiler chokes on this. I think it should be env->cc.cc_env. Other references to the member cc_env are of this form. I made this change, and was then able to successfully complete the compilation, generate a new saved PCL image, and load our CLOS system. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07235; Mon, 24 Sep 90 20:47:21 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 24 Sep 90 22:41:19-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA10366g; Mon, 24 Sep 90 20:35:55 PDT Received: by caligula id AA03190g; Mon, 24 Sep 90 20:38:43 PDT Date: Mon, 24 Sep 90 20:38:43 PDT From: Jon L White Message-Id: <9009250338.AA03190@caligula> To: moon@symbolics.com Cc: common-lisp-object-system@mcc.com Subject: Making (CLASS-OF ) be EQ to Kim Barrett has been using Lucid CLOS, and wanted to model the CLOS hierarchy in a parallel fashion; in particular, he needed to make the parallel to the circular link at STANDARD-CLASS. This pointed up three anomalies to me, and I wonder what your thoughts are about them, and how Symbolics CLOS handles those cases. 1. 88-002R defines the actions of a system-supplied method for UPDATE-INSTANCE-FOR-DIFFERENT-CLASS, specialized to the point STANDARD-OBJECT,STANDARD-OBJECT. But it doesn't mention the special action that obviously must be taken when the object being submitted to CHANGE-CLASS is itself a class-object -- namely all the instances of that class should be marked obsolete. Of course, the same is true if the class's metaclass has been redefined. So I would think that there should be system-supplied :BEFORE methods on these two updators, specialized to CLASS,CLASS to care for that. 2. So Kim's attempt to do: (setq my-std-class (defclass my-std-class (standard-class) ())) (change-class my-std-class my-std-class) failed because the aforesaid :BEFORE method marks the class as having obsolete instances, and the primary method makes the class be a direct instance of itself. Thus the update protocol falls into an infinite regress fetching the class of an obsolete instance and needing to update that class object first, and so on. Since this particular example is of a class that really doesn't have any instances, then I suggested a workaround of just overriding the system-supplied methods at the point CLASS,CLASS and jumping immediately to the "next most specific method." But there's a problem here -- you can't say that in CLOS. At least you can't say it without rolling your own (albeit trivial) method delegation coding (I was tempted to say "method-combination coding" here, but I really don't think that is quite right). This seems to point out a lacuna in CLOS as compared to flavors. Didn't flavors used to have a thing called SEND-AS? I know we had to put SEND-AS and LEXPR-SEND-AS in that "EXTEND" object system of MacLisp/NIL back in 1980 or 1981 in order for it to be able to emulate flavors. So I just don't see how to do that in CLOS directly; consequently, the suggested workaround just unrolls the source-code for the primary method on STANDARD-OBJECT,STANDARD-OBJECT (and of course this would fail if there were other qualified methods on that point). Note that it uses an :AROUND method on CLASS,CLASS, as I do not want to commit to whether the intruding piece of behaviour is implemented as a :BEFORE method, or as just some line in a primary method. Here is the proffered workaround: (setq my-std-class (defclass my-std-class (standard-class) ())) (defmethod update-instance-for-different-class :around ((previous class) (current class) &rest initargs) (declare (dynamic-extent initargs)) ;; We'd like to say simply "Run the next most specific effective method" ;; but there's no way to say that in an :around method. Alternatively, ;; we'd like to say "Dispatch this function again, as if the types ;; of the arguments were one up in their superclass chains," but there's ;; no way to say that either. So we have just inserted a copy of the ;; source code for the primary method at STANDARD-OBJECT,STANDARD-OBJECT ;; which is only 1 line long anyway. (clos::common-update-for-different-class previous current initargs)) (change-class my-std-class my-std-class) (remove-method #'update-instance-for-different-class (find-method #'update-instance-for-different-class '(:around) (list (find-class 'class) (find-class 'class)))) I realize that if one knows precisely how the "intruding behaviour" is implemented in terms of direct methods, one could just remove those methods temporarily, and later restore them. But the :AROUND method approach is so tempting because one would think that is part of the purpose of having :AROUND be dominant in the standard method combination technique. Besides, I really expect the "intruding behaviour" to be implemented a different way between in some subsequent release; so it would be better not to know whether it comes from a :BEFORE method or from a primary method. 3. Shouldn't it be "consequences undefined" if you try to call MAKE-INSTANCES-OBSOLETE on STANDARD-CLASS? In fact, shouldn't it be "consequences undefined" to call CHANGE-CLASS on any of the basic metabojects? The cleanup issue LISP-SYMBOL-REDEFINITION (as of mid 1989) doesn't cover these cases of altering system-supplied classes; nor does it seem to cover the case of altering a system-supplied function whose name isn't a symbol -- e.g., (SETF SLOT-VALUE). To be general, that issue should perhaps have been named LISP-NAME-REDEFINITION, and we should have had "method specs" names for methods, so that the prohibition against redefinition would also apply to things like: (METHOD CHANGE-CLASS (STANDARD-OBJECT)) ;sure (METHOD SHARED-INITIALIZE :AFTER (STANDARD-CLASS)) ;maybe? Possibly these prohibitions are implied by other language in 88-002R, but the cleanup issue LISP-SYMBOL-REDEFINITION looks like it is trying to be a comprehensive enumeration of what it is you shouldn't redefine. My apologies if these questions have been addressd in the past, and my memory just doesn't recall them. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02497; Tue, 25 Sep 90 04:33:26 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16873>; Tue, 25 Sep 1990 04:11:55 PDT Received: from lanai.cs.ucla.edu ([131.179.128.13]) by alpha.xerox.com with SMTP id <16875>; Tue, 25 Sep 1990 04:08:54 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA10248; Tue, 25 Sep 90 04:07:35 -0700 X-Ns-Transport-Id: 08002008D0FD00027ABC Date: Tue, 25 Sep 1990 04:07:35 PDT From: Trent Lange To: rivieres@parc.xerox.com, faieta@parc.xerox.com, gregor@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, gregor@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM Subject: Re: Compilation of methods per class. In-Reply-To: "Message of Fri, 21 Sep 1990 11:29:24 PDT from \"Gregor Kiczales \" <90Sep21.112925pdt.269@spade.parc.xerox.com> Message-Id: <90Sep25.041155pdt.16873@alpha.xerox.com> " To: Gregor Kiczales cc: commonloops.PARC@Xerox.com Message-ID: <900925.110735z.10208.lange@lanai.cs.ucla.edu> >The basic PCL architecture does something very close to what (I believe) >you are suggesting. Whether a given port of PCL actually produces code >of the same quality as your example would compile to depends on a number >of things. First among these is whether the fast %FUNCALL and %APPLY >instructions were properly ported. > >I am not saying that PCL produces exactly the same code, its code looks >more like: > >(defun foo-runtime12 (self) > (let ((*next-methods* '#,(list #'foo-class1-lambda self))) > (foo-runtime12-inner self))) > >(defun foo-runtime12-inner (self) > (declare (special *next-methods*)) > (let ((next-method (car *next-methods*))) > (foo-class2-body-begin) > (%funcall #'next-method self) ;You should read this as a funcall > ;that needs no error-checking. The > ;number of arguments are sure to be > ;right. > (foo-class2-body-end))) > >As compared to your version: > (defun foo-runtime12-lambda (self) > (foo-class2-body-begin) > (funcall #'foo-class1-lambda self) > (foo-class2-body-end)) > >PCL does the following extra work: > > % 1 tail-recursive function call (foo-runtime-12 to foo-runtime-12-inner) > % special variable binding > % special variable access > % special variable unbinding > * unsafe CAR (memory read) This indeed looks like the kind of code that I was hoping was generated. However, it doesn't seem to explain the kinds of running time I get on method calls in generic May Day PCL running in both Lucid and Franz lisp. Whenever I have the same method defined for several different classes and call the method at least once for instances of each of those classes, the time PCL takes to execute the method call goes up, sometimes dramatically. Having the same method defined differently on just four different classes generally almost doubles the amount of time taken when it is only defined on one class. The increase in time taken also increases when auxilary methods are used (even for classes which inherit no auxilaries) or when classes have primary methods that are overridden. For one particular method in my program that has a total of about 20 different primary and auxilary definitions on different classes, and which uses those definitions in various mixin combinations on the runtime classes, the basic method call takes five times as long as it does when it is defined one only one class. The above slowdowns in runtime is what led me to believe that some method combination or lookup is being done each time a method is called. This is why I was wondering if anybody (or any of the vendors) had done method compilation so that "each class would have its own code for each method." If that was done, then each method call on a particular class should take a constant amount of time, regardless of the number of other places the method was defined, (plus or minus time needed for the generic function to look up the method's code on the class). Can you think of any relatively simple modifications to the PCL code that would do this for people that are willing to accept the increased code size? (It would be especially useful if one could declare that specific time-critical methods should be compiled per class, but that all other methods use the normal combination method). Thanks, - Trent Lange Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05627; Tue, 25 Sep 90 08:05:23 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 25 Sep 90 10:00:42-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 850318; 25 Sep 1990 11:00:22-0400 Date: Tue, 25 Sep 1990 11:03-0400 From: David A. Moon Subject: Making (CLASS-OF ) be EQ to To: Jon L White Cc: common-lisp-object-system@mcc.com In-Reply-To: <9009250338.AA03190@caligula> Message-Id: <19900925150339.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Mon, 24 Sep 1990 23:38 EDT From: Jon L White .... This seems to point out a lacuna in CLOS as compared to flavors. Didn't flavors used to have a thing called SEND-AS? I know we had to put SEND-AS and LEXPR-SEND-AS in that "EXTEND" object system of MacLisp/NIL back in 1980 or 1981 in order for it to be able to emulate flavors. One of the features of Flavors, when it was introduced in 1981, was the elimination of SEND-AS. I forget the names of the object systems that preceded Flavors, but they all used SEND-AS as their approach to controlling inheritance (this was borrowed from Smalltalk) and as a result were nearly impossible to use. Flavors used method combination instead of SEND-AS and CLOS follows in that tradition. The rest of your message is incomprehensible on first reading, having so many layers of metaobjects, but I'll look at it later. It might be that the answer is simply that object-oriented programming is not a substitute for figuring out what you want your program to be able to do and designing it accordingly. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06087; Tue, 25 Sep 90 08:32:27 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16878>; Tue, 25 Sep 1990 08:32:11 PDT Received: from venera.isi.edu ([128.9.0.32]) by alpha.xerox.com with SMTP id <16878>; Tue, 25 Sep 1990 08:28:47 PDT Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local) id ; Tue, 25 Sep 90 08:28:07 -0700 Posted-Date: Tue, 25 Sep 90 11:28:00 EDT Received: by hpai23 (14.5/4.0.3-3) id AA19689; Tue, 25 Sep 90 11:28:04 edt X-Ns-Transport-Id: 08002008D0FD00027BF2 Date: Tue, 25 Sep 1990 08:28:00 PDT From: Neil Goldman Subject: method combination -- mayday PCL To: commonloops.PARC@Xerox.com Cc: goldman@hpai23.isi.EDU Message-Id: <9009251528.AA19689@hpai23> Has anyone encountered (and perhaps fixed) a problem with MAYDAY pcl involving the use of the :ARGUMENTS option to DEFINE-METHOD-COMBINATION? My source code: (define-method-combination help-string-merge () ((primary () :required t)) (:arguments form) `(block :done ,@(mapcar #'(lambda (method) `(when (multiple-value-call #'merge-into-help-strings (call-method ,method ())) (return-from :done nil))) primary) (structure-inherit-help-string ,form))) Which macroexpands into: (PROGN '(DEFINE-METHOD-COMBINATION HELP-STRING-MERGE) (EVAL-WHEN (LOAD EVAL) (PCL::LOAD-LONG-DEFCOMBIN 'HELP-STRING-MERGE (QUOTE NIL) #'(LAMBDA (PCL::.GENERIC-FUNCTION. PCL::.METHOD-COMBINATION. PCL::.APPLICABLE-METHODS.) (PROGN PCL::.GENERIC-FUNCTION. PCL::.METHOD-COMBINATION. PCL::.APPLICABLE-METHODS.) (BLOCK PCL::.LONG-METHOD-COMBINATION-FUNCTION. (LET ((PCL::INNER-RESULT. (LET ((FORM '#:G74750) PRIMARY #:G74749) (DOLIST (PCL::.METHOD. PCL::.APPLICABLE-METHODS.) (LET ((PCL::.QUALIFIERS. (METHOD-QUALIFIERS PCL::.METHOD.)) (PCL::.SPECIALIZERS. (PCL::METHOD-SPECIALIZERS PCL::.METHOD.))) (PROGN PCL::.QUALIFIERS. PCL::.SPECIALIZERS.) (COND ((OR (NULL PCL::.QUALIFIERS.)) (IF (EQUAL #:G74749 PCL::.SPECIALIZERS.) (RETURN-FROM PCL::.LONG-METHOD-COMBINATION-FUNCTION. '(ERROR "More than one method of type ~S ~ with the same specializers." 'PRIMARY)) (SETQ #:G74749 PCL::.SPECIALIZERS.)) (PUSH PCL::.METHOD. PRIMARY))))) (WHEN (NULL PRIMARY) (RETURN-FROM PCL::.LONG-METHOD-COMBINATION-FUNCTION. '(ERROR "No ~S methods." 'PRIMARY))) (SETQ PRIMARY (NREVERSE PRIMARY)) (LIST* 'BLOCK ':DONE (APPEND (MAPCAR #'(LAMBDA (METHOD) (LIST* 'WHEN (LIST 'MULTIPLE-VALUE-CALL '#'MERGE-INTO-HELP-STRINGS (LIST* 'CALL-METHOD METHOD '(NIL))) '((RETURN-FROM :DONE NIL)))) PRIMARY) (LIST (LIST 'STRUCTURE-INHERIT-HELP-STRING FORM))))))) (LIST* 'APPLY (LIST 'FUNCTION (LIST 'LAMBDA '(#:G74750 &REST PCL::.IGNORE.) '(DECLARE (IGNORE PCL::.IGNORE.)) PCL::INNER-RESULT.)) '(PCL::.COMBINED-METHOD-ARGS.)))))))) when compiling Warning: Symbol PCL::.COMBINED-METHOD-ARGS. declared special and, not surprisingly, when run, error Unbound Symbol PCL::.COMBINED-METHOD-ARGS. The source of the reference to this symbol is the PCL function DEAL-WITH-ARGUMENTS-OPTION, which appears to be written expecting a variable by this name to be (lexically perhaps) bound around the code it produces. I can find no other references to the symbol PCL::.COMBINED-METHOD-ARGS. in the PCL sources I have. (defun deal-with-arguments-option (wrapped-body arguments-option) (let* ((intercept-lambda-list (gathering1 (collecting) (dolist (arg arguments-option) (if (memq arg lambda-list-keywords) (gather1 arg) (gather1 (gensym)))))) (intercept-rebindings (gathering1 (collecting) (iterate ((arg (list-elements arguments-option)) (int (list-elements intercept-lambda-list))) (unless (memq arg lambda-list-keywords) (gather1 `(,arg ',int))))))) ;; ;; (setf (cadr wrapped-body) (append intercept-rebindings (cadr wrapped-body))) ;; ;; Be sure to fill out the intercept lambda list so that it can ;; be too short if it wants to. ;; (cond ((memq '&rest intercept-lambda-list)) ((memq '&allow-other-keys intercept-lambda-list)) ((memq '&key intercept-lambda-list) (setq intercept-lambda-list (append intercept-lambda-list '(&allow-other-keys)))) (t (setq intercept-lambda-list (append intercept-lambda-list '(&rest .ignore.))))) `(let ((inner-result. ,wrapped-body)) `(apply #'(lambda ,',intercept-lambda-list ,,(when (memq '.ignore. intercept-lambda-list) ''(declare (ignore .ignore.))) ,inner-result.) .combined-method-args.)))) Received: from LUCID.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06314; Tue, 25 Sep 90 08:40:46 -0700 Received: from challenger (challenger.lucid.com) by heavens-gate.lucid.com id AA15009g; Tue, 25 Sep 90 08:34:33 PDT Received: by challenger id AA10612g; Tue, 25 Sep 90 08:39:40 PDT Date: Tue, 25 Sep 90 08:39:40 PDT From: Peter Benson Message-Id: <9009251539.AA10612@challenger> To: lange@CS.UCLA.EDU Cc: rivieres@parc.xerox.com, faieta@parc.xerox.com, gregor@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, gregor@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM, commonloops.PARC@Xerox.com In-Reply-To: Trent Lange's message of Tue, 25 Sep 1990 04:07:35 PDT <90Sep25.041155pdt.16873@alpha.xerox.com> Subject: Compilation of methods per class. From: Trent Lange To: Gregor Kiczales cc: commonloops.PARC@Xerox.com Message-ID: <900925.110735z.10208.lange@lanai.cs.ucla.edu> This indeed looks like the kind of code that I was hoping was generated. However, it doesn't seem to explain the kinds of running time I get on method calls in generic May Day PCL running in both Lucid and Franz lisp. Whenever I have the same method defined for several different classes and call the method at least once for instances of each of those classes, the time PCL takes to execute the method call goes up, sometimes dramatically. Having the same method defined differently on just four different classes generally almost doubles the amount of time taken when it is only defined on one class. The increase in time taken also increases when auxilary methods are used (even for classes which inherit no auxilaries) or when classes have primary methods that are overridden. For one particular method in my program that has a total of about 20 different primary and auxilary definitions on different classes, and which uses those definitions in various mixin combinations on the runtime classes, the basic method call takes five times as long as it does when it is defined one only one class. I don't know exactly how you did your timings. It is important to understand that the the effective method functions a computed lazily in PCL. That is, effective methods are not made until the generic function is called the first time. That's so you don't make lots of effective methods that apply only to intermediate states. When timing things in PCL make sure you call each relevant generic function at least once before you get real timings and after any changes to the class hierarchy or adding new methods. I think there is a function in PCL that will eagerly create all the effective methods, but I can't remember the name. You could call that function before doing timings to get reliable number too. If the timings still slow down considerably either the generic functions are getting invalidated at runtime (adding methods, redefining classes, and some other things can cause this) or there is a real problem. It really should work the way Gregor described it. -ptr- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06543; Tue, 25 Sep 90 08:48:41 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16875>; Tue, 25 Sep 1990 08:48:30 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16875>; Tue, 25 Sep 1990 08:45:20 PDT Received: from challenger (challenger.lucid.com) by heavens-gate.lucid.com id AA15009g; Tue, 25 Sep 90 08:34:33 PDT Received: by challenger id AA10612g; Tue, 25 Sep 90 08:39:40 PDT X-Ns-Transport-Id: 08002008D0FD00027C16 Date: Tue, 25 Sep 1990 08:39:40 PDT From: Peter Benson Subject: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Tue, 25 Sep 1990 04:07:35 PDT <90Sep25.041155pdt.16873@alpha.xerox.com>" To: lange@CS.UCLA.EDU Cc: rivieres@parc.xerox.com, faieta@parc.xerox.com, gregor@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, gregor@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM, commonloops.PARC@xerox.com Message-Id: <9009251539.AA10612@challenger> From: Trent Lange To: Gregor Kiczales cc: commonloops.PARC@Xerox.com Message-ID: <900925.110735z.10208.lange@lanai.cs.ucla.edu> This indeed looks like the kind of code that I was hoping was generated. However, it doesn't seem to explain the kinds of running time I get on method calls in generic May Day PCL running in both Lucid and Franz lisp. Whenever I have the same method defined for several different classes and call the method at least once for instances of each of those classes, the time PCL takes to execute the method call goes up, sometimes dramatically. Having the same method defined differently on just four different classes generally almost doubles the amount of time taken when it is only defined on one class. The increase in time taken also increases when auxilary methods are used (even for classes which inherit no auxilaries) or when classes have primary methods that are overridden. For one particular method in my program that has a total of about 20 different primary and auxilary definitions on different classes, and which uses those definitions in various mixin combinations on the runtime classes, the basic method call takes five times as long as it does when it is defined one only one class. I don't know exactly how you did your timings. It is important to understand that the the effective method functions a computed lazily in PCL. That is, effective methods are not made until the generic function is called the first time. That's so you don't make lots of effective methods that apply only to intermediate states. When timing things in PCL make sure you call each relevant generic function at least once before you get real timings and after any changes to the class hierarchy or adding new methods. I think there is a function in PCL that will eagerly create all the effective methods, but I can't remember the name. You could call that function before doing timings to get reliable number too. If the timings still slow down considerably either the generic functions are getting invalidated at runtime (adding methods, redefining classes, and some other things can cause this) or there is a real problem. It really should work the way Gregor described it. -ptr- Received: from LUCID.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09252; Tue, 25 Sep 90 10:58:39 -0700 Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA16410g; Tue, 25 Sep 90 10:52:21 PDT Received: by caligula id AA04026g; Tue, 25 Sep 90 10:55:09 PDT Date: Tue, 25 Sep 90 10:55:09 PDT From: Jon L White Message-Id: <9009251755.AA04026@caligula> To: lange@CS.UCLA.EDU Cc: rivieres@parc.xerox.com, faieta@parc.xerox.com, gregor@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, gregor@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM In-Reply-To: Trent Lange's message of Tue, 25 Sep 1990 04:07:35 PDT <90Sep25.041155pdt.16873@alpha.xerox.com> Subject: Compilation of methods per class. re: Whenever I have the same method defined for several different classes and call the method at least once for instances of each of those classes, the time PCL takes to execute the method call goes up, sometimes dramatically. Having the same method defined differently on just four . . . The circumstances you relate above are precisely the symptoms one would expect when there is a breakdown in the assumptions underlying the PCL generic-function caching technique. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09947; Tue, 25 Sep 90 11:22:16 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Tue 25 Sep 90 13:16:49-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA16633g; Tue, 25 Sep 90 11:11:22 PDT Received: by caligula id AA04061g; Tue, 25 Sep 90 11:14:12 PDT Date: Tue, 25 Sep 90 11:14:12 PDT From: Jon L White Message-Id: <9009251814.AA04061@caligula> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@mcc.com In-Reply-To: David A. Moon's message of Tue, 25 Sep 1990 11:03-0400 <19900925150339.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Making (CLASS-OF ) be EQ to Yea, there were numerous thorny issues connected to that one line of code -- (change-class my-std-class my-std-class). Here's a high-order, three-line summary of each one: 1. When CHANGE-CLASS is applied to a class object, shouldn't it also call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago said yes.] Should this be as a :BEFORE method specialized to class CLASS? 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? 3. Have we adequately enumerated in a single place the kinds of system definitions that user code can redefine without suffering "undefined consequences"; e.g., are SETF function names and methods covered? I'm especially interested in what Symbolics does for point 1. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11987; Tue, 25 Sep 90 13:04:32 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Tue 25 Sep 90 15:02:32-CDT Received: from challenger (challenger.lucid.com) by heavens-gate.lucid.com id AA17640g; Tue, 25 Sep 90 12:57:09 PDT Received: by challenger id AA11805g; Tue, 25 Sep 90 13:02:14 PDT Date: Tue, 25 Sep 90 13:02:14 PDT From: Peter Benson Message-Id: <9009252002.AA11805@challenger> To: jonl@lucid.com Cc: common-lisp-object-system@mcc.com In-Reply-To: Jon L White's message of Tue, 25 Sep 90 11:14:12 PDT <9009251814.AA04061@caligula> Subject: Making (CLASS-OF ) be EQ to Date: Tue, 25 Sep 90 11:14:12 PDT From: Jon L White Yea, there were numerous thorny issues connected to that one line of code -- (change-class my-std-class my-std-class). Here's a high-order, three-line summary of each one: 1. When CHANGE-CLASS is applied to a class object, shouldn't it also call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago said yes.] Yes. I think you and I had a discussion about this some time ago too. As I remember we decided this was true. Should this be as a :BEFORE method specialized to class CLASS? I don't think that is necessary. I suspect that users should be allowed to define their own :BEFORE, :AFTER, and :AROUND for system supplied generic functions. I think the spec isn't exactly clear about that. I think it should say exactly what methods are defined for what generic functions s the user will know if what she is doing is going to redefine a system supplied method. 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? I don't think there is any way to do this short of defining a new kind of method combination. It would seem there is no way to do this on a generic function defined by someone else. I don't there should be a way to do this by default. It seems to break modularity. 3. Have we adequately enumerated in a single place the kinds of system definitions that user code can redefine without suffering "undefined consequences"; e.g., are SETF function names and methods covered? Probably not. The method signatures for the system defined methods are listed on the function pages in Chapter 2. Although not explicitly stated, redefining primary methods with those qualifiers should clearly cause 'undefined' behavior. It is not clear whether or not the user is allowed to define :BEFORE, :AFTER, or :AROUND methods with the same specializers. This should be made explicit. I don't care which way it is decided. -ptr- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15587; Tue, 25 Sep 90 16:29:18 -0700 Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16921>; Tue, 25 Sep 1990 16:29:08 PDT Received: by spade.parc.xerox.com id <269>; Tue, 25 Sep 1990 16:28:34 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: jonl@lucid.com Cc: lange@CS.UCLA.EDU, rivieres@parc.xerox.com, faieta@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM In-Reply-To: Jon L White's message of Tue, 25 Sep 1990 10:55:09 PDT <9009251755.AA04026@caligula> Subject: Re: Compilation of methods per class. Line-Fold: NO Message-Id: <90Sep25.162834pdt.269@spade.parc.xerox.com> Date: Tue, 25 Sep 1990 16:28:25 PDT Date: Tue, 25 Sep 1990 10:55:09 PDT From: Jon L White The circumstances you relate above are precisely the symptoms one would expect when there is a breakdown in the assumptions underlying the PCL generic-function caching technique. Can you elaborate on this? st port of PCL actually distributed from PARC is for Franz Common Lisp 3.x on the SPARC. This port gets closer to the architectural PCL than any other. The initial CLOS products of some vendors are based on PCL, so in some sense those could be considered really good ports of PCL, they are not available directly from PARC of course. The third is that there are still a number of bugs in PCL, and you may have tripped across one of them. In all of these cases, if you could send a short version of the benchmark you are using we could say more about it, and give you an idea which, if any, of these three issues is relevant. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15753; Tue, 25 Sep 90 16:39:42 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Tue 25 Sep 90 18:37:29-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16920>; Tue, 25 Sep 1990 16:37:39 PDT Received: by spade.parc.xerox.com id <269>; Tue, 25 Sep 1990 16:37:21 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: jonl@lucid.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@MCC.COM In-Reply-To: Jon L White's message of Tue, 25 Sep 1990 11:14:12 PDT <9009251814.AA04061@caligula> Subject: Re: Making (CLASS-OF ) be EQ to Line-Fold: NO Message-Id: <90Sep25.163721pdt.269@spade.parc.xerox.com> Date: Tue, 25 Sep 1990 16:37:14 PDT X-Ns-Transport-Id: 08002008D0FD00027DCC Date: Tue, 25 Sep 1990 11:14:12 PDT From: Jon L White 3. Have we adequately enumerated in a single place the kinds of system definitions that user code can redefine without suffering "undefined consequences"; e.g., are SETF function names and methods covered? (and, from a previous message) (METHOD CHANGE-CLASS (STANDARD-OBJECT)) ;sure (METHOD SHARED-INITIALIZE :AFTER (STANDARD-CLASS)) ;maybe? The newest MOP document, draft 11 of July 30, lays out the necessary restrictions for part of this in some detail. It doesn't address the issue of non-symbol function names, but that one is easy. It does focus on the issue of what method definitions it is legal for users to do. The short answer is that it isn't possible for a user to do either of the method definitions you list. 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? Without changing the method combination, or the class of the generic function, you can't. Two reasons: First, 88-002R CLOS is not one of the OOLs that supports this sort of thing. Second, CLOS with MOP, doesn't provide base-level initiated, runtime reflective incursion. To do a reflective incursion such as this one, which gives you casually-connected access to the method dispatch mechanism, you have to have expressed your desire to have this control ahead of time. The way to do this is to change either the method combination, or the generic function class. Received: from LUCID.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16357; Tue, 25 Sep 90 17:09:09 -0700 Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA20262g; Tue, 25 Sep 90 17:01:15 PDT Received: by caligula id AA04730g; Tue, 25 Sep 90 17:04:03 PDT Date: Tue, 25 Sep 90 17:04:03 PDT From: Jon L White Message-Id: <9009260004.AA04730@caligula> To: gregor@parc.xerox.com Cc: lange@CS.UCLA.EDU, rivieres@parc.xerox.com, faieta@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM In-Reply-To: Gregor Kiczales's message of Tue, 25 Sep 1990 16:28:25 PDT <90Sep25.162834pdt.269@spade.parc.xerox.com> Subject: Compilation of methods per class. re: Date: Tue, 25 Sep 1990 10:55:09 PDT From: Jon L White The circumstances you relate above are precisely the symptoms one would expect when there is a breakdown in the assumptions underlying the PCL generic-function caching technique. Can you elaborate on this? The assumption that breaks down is that most or all of the lookup requests find the entry in the cache (first probe or "mirror" probe). Unless the more recent PCL has changed algorithms, there are lots of reasonable circumstances where there will be a "cache miss" path taken even though the entry is present someplace in the cache. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17595; Tue, 25 Sep 90 17:48:30 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Tue 25 Sep 90 19:46:32-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA20376g; Tue, 25 Sep 90 17:11:33 PDT Site: Received: by caligula id AA04778g; Tue, 25 Sep 90 17:14:21 PDT Date: Tue, 25 Sep 90 17:14:21 PDT From: Jon L White Message-Id: <9009260014.AA04778@caligula> To: gregor@parc.xerox.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@MCC.COM In-Reply-To: Gregor Kiczales's message of Tue, 25 Sep 1990 16:37:14 PDT <90Sep25.163721pdt.269@spade.parc.xerox.com> Subject: Making (CLASS-OF ) be EQ to re: (METHOD CHANGE-CLASS (STANDARD-OBJECT)) ;sure (METHOD SHARED-INITIALIZE :AFTER (STANDARD-CLASS)) ;maybe? The short answer is that it isn't possible for a user to do either of the method definitions you list. Right. What I was suggesting is that these prohibitions be spelled out in the same place in the spec that spells out the LISP-SYMBOL-REDEFINITION restrictions. [By the bye, my comments ";sure" and ";mabye" above are to imply that I'm sure this one is restricted, and that maybe the other one ought to be too.] re: 2. If there are methods defined on function FOO at classes respectively ,then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? . . . The way to do this is to change either the method combination, or the generic function class. Yea, that's what I was afraid of. Since the purpose in doing it was just to suppress the MAKE-INSTANCES-OBSOLETE call so that Kim's circular linkup could be made, then some lower-level kludge would be, I guess, just as acceptable. Like the :AROUND method that just "in-lines" the effective method that it wanted to "delegate" to. Incidentally, this sort of request could also be viewed as supporting the need for COMPUTE-EFFECTIVE-METHOD, even though there are no new metaclasses or generic-function-classes or method-combinations. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24619; Tue, 25 Sep 90 21:12:37 -0700 Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16912>; Tue, 25 Sep 1990 21:12:20 PDT Received: by spade.parc.xerox.com id <269>; Tue, 25 Sep 1990 21:12:06 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: jonl@lucid.com Cc: lange@CS.UCLA.EDU, rivieres@parc.xerox.com, faieta@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM In-Reply-To: Jon L White's message of Tue, 25 Sep 1990 17:04:03 PDT <9009260004.AA04730@caligula> Subject: Re: Compilation of methods per class. Line-Fold: NO Message-Id: <90Sep25.211206pdt.269@spade.parc.xerox.com> Date: Tue, 25 Sep 1990 21:11:58 PDT Site: Date: Tue, 25 Sep 1990 17:04:03 PDT From: Jon L White The assumption that breaks down is that most or all of the lookup requests find the entry in the cache (first probe or "mirror" probe). Unless the more recent PCL has changed algorithms, there are lots of reasonable circumstances where there will be a "cache miss" path taken even though the entry is present someplace in the cache. In the new PCL, the runtime dispatch starts at the primary location and scans the entire cache until it gets back to the primary. It is the cache filling mechanism which takes responsibility for ensuring that entries will always be close to their primary location. This division of labor makes the runtime dispatcher simpler and so a little faster. You lose a little on very large caches that were going to miss anyways; but that would be easy to fix by introducing a specialized dispatcher for large caches that didn't scan more than a certain number of entries. This whole strategy is explained better in the LFP90 paper on PCL. There was a horrible bug in Victoria Day PCL which had symptoms like what you are mentioning --- an entry could be in the cache, but there would still be a cache miss. I recall that bug being fixed, but I don't know if the patch was widely distributed. I don't remember what version of PCL Trent Lange was running. Received: from LUCID.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27248; Tue, 25 Sep 90 23:10:15 -0700 Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA23933g; Tue, 25 Sep 90 23:02:20 PDT Received: by caligula id AA05091g; Tue, 25 Sep 90 23:05:08 PDT Date: Tue, 25 Sep 90 23:05:08 PDT From: Jon L White Message-Id: <9009260605.AA05091@caligula> To: gregor@parc.xerox.com Cc: lange@CS.UCLA.EDU, rivieres@parc.xerox.com, faieta@parc.xerox.com, gerson@parc.xerox.com, brotsky@parc.xerox.com, bobrow@parc.xerox.com, kimber@parc.xerox.com, cutting@parc.xerox.com, robertso@parc.xerox.com, rodrigue@parc.xerox.com, rao@parc.xerox.com, haarslev@parc.xerox.com, cloops-arisia@arisia.Xerox.COM In-Reply-To: Gregor Kiczales's message of Tue, 25 Sep 1990 21:11:58 PDT <90Sep25.211206pdt.269@spade.parc.xerox.com> Subject: Compilation of methods per class. re: There was a horrible bug in Victoria Day PCL which had symptoms like what you are mentioning --- an entry could be in the cache, but there would still be a cache miss. I recall that bug being fixed, but I don't know if the patch was widely distributed. The behaviour I'm referring to was present in previous versions too (at least one -- maybe more). It wasn't really a bug in that it would still correctly find the cached entry; but it was a performance pitfall in that it had to go out of line at unpredictable times to do it. Lucid's CLOS uses a different approach to generic function "caching", which doesn't follow any of the PCL versions nor of that referred to in the L&FP90 paper. Rather, it is more akin to TICLOS's. Method-functions and other data are being "cached" (in a general sense) from the lookup phase; but the data-structure in which the cached entries are stored is a hash-table rather than a cache. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06952; Wed, 26 Sep 90 06:32:14 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Wed, 26 Sep 1990 06:21:44 PDT Received: from lanai.cs.ucla.edu ([131.179.128.13]) by alpha.xerox.com with SMTP id <16133>; Wed, 26 Sep 1990 06:18:09 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA09323; Wed, 26 Sep 90 06:17:12 -0700 X-Ns-Transport-Id: 08002008D0FD000285EB Date: Wed, 26 Sep 1990 06:17:12 PDT From: Trent Lange Subject: Re: Compilation of methods per class. In-Reply-To: "Message of Tue, 25 Sep 1990 16:26:20 PDT from \"Gregor Kiczales \" <90Sep25.162633pdt.281@spade.parc.xerox.com>" To: Gregor Kiczales Cc: commonloops.PARC@Xerox.com Message-Id: <900926.131712z.09320.lange@lanai.cs.ucla.edu> There definitely may be something to the differences in method lookup between different ports of PCL being a partial explanation to the problem. Calls on generic functions in Franz CL 3.1.13.1 on a Sun 4 seem much less likely to break (i.e. slow down) when those functions are specialized to multiple classes than their equivalent calls in Lucid 3.0 on the Apollos and Sun 4s. Here is about as small a benchmark I can make to show the problem significantly: ;;; (defclass everybody-inherit-class () ()) (defclass primary-class1 (everybody-inherit-class) ()) (defclass primary-class2 (everybody-inherit-class) ()) (defclass primary-class3 (everybody-inherit-class) ()) (defclass primary-class4 (everybody-inherit-class) ()) (defclass around-class1 () ()) (defclass around-class2 () ()) (defclass around-class3 () ()) (defclass around-class4 () ()) (defclass class1 (primary-class1) ()) (defclass class2 (primary-class2) ()) (defclass class3 (primary-class3) ()) (defclass class4 (primary-class4) ()) (defclass class11 (around-class1 primary-class1) ()) (defclass class22 (around-class2 primary-class2) ()) (defclass class33 (around-class3 primary-class3) ()) (defclass class44 (around-class4 primary-class4) ()) (defmethod really-fast-foo ((self everybody-inherit-class)) ;; Method not defined on any other classes. 'really-fast-foo) (defmethod fast-foo ((self everybody-inherit-class)) ;; Method with one primary and one :around method defined. 'fast-foo) (defmethod slow-foo ((self everybody-inherit-class)) ;; Method with primary defined separately on 5 classes and ;; :around on 4 classes. 'slow-foo) (defmethod slow-foo ((self primary-class1)) 'slow-foo1) (defmethod slow-foo ((self primary-class2)) 'slow-foo2) (defmethod slow-foo ((self primary-class3)) 'slow-foo3) (defmethod slow-foo ((self primary-class4)) 'slow-foo4) (defmethod fast-foo :around ((self around-class1)) (cons 'fast-foo-around (call-next-method))) (defmethod slow-foo :around ((self around-class1)) (cons 'slow-foo-around1 (call-next-method))) (defmethod slow-foo :around ((self around-class2)) (cons 'slow-foo-around1 (call-next-method))) (defmethod slow-foo :around ((self around-class3)) (cons 'slow-foo-around1 (call-next-method))) (defmethod slow-foo :around ((self around-class4)) (cons 'slow-foo-around1 (call-next-method))) (defvar i1 (make-instance 'class1)) (defvar i2 (make-instance 'class2)) (defvar i3 (make-instance 'class3)) (defvar i4 (make-instance 'class4)) (defvar i11 (make-instance 'class11)) (defvar i22 (make-instance 'class22)) (defvar i33 (make-instance 'class33)) (defvar i44 (make-instance 'class44)) ;;; The following is the (gruesome) benchmark macro that I have built to measure run times as accurately as possible across platforms. I apologize for its length, but timing differences such as these are hard to tease out (because of the need to average over a large number of calls and problems with inconsistent interruptions such as garbage collections during a large number of calls). ;;; (defmacro time-test (&rest args) ;; Macro which attempts to accurately measure the amount of real time ;; (in microseconds) that expressions take to run when compiled. ;; Example call: (time-test (sin 3.2) (princ-to-string (sin 3.2))) ;; To do this, each of the expressions being tested is used as the body of ;; a separate function having a null lambda list (named #'expr1, #'expr2, etc) ;; which is then compiled. To calculate the time taken, the function is ;; essentially cycled Iter of times, with the average time taken by each ;; call of the expression being equal to the total time to iterate the ;; function it is the body of minus the total time taken to iterate (for the ;; same number of cycles) an empty function (#'empty-lambda). ;; Because the real time taken for each function call will vary ;; depending upon other processes running on the machine, garbage ;; collections, and the state of virtual memory, the iterations are ;; broken up into a number of different Epochs (defaults to 10, but can be ;; passed as a key) for which Iter iterages are done and the average time ;; per function call taken for each. At the end of all of the epochs, ;; the average amounts of time taken for each expression are printed out, ;; first overall, and then successively with the epochs whose average time ;; deviates most from the mean average time removed. Thus the final line ;; printed tends to show the average amount of time taken for each expression ;; function calls, minus expression calls on which garbage collections, etc. ;; were done, and therefore (hopefully) close to the "true" real time taken ;; by the expression. ;; E.g. ;; > (time-test (sin 3.2) (princ-to-string 3.2) :epochs 6) ;; Epochs 6, iterations 150... ;; 6 2,684 720,555 31,890 ;; 5 2,004 732,108 29,970 ;; 4 3,077 727,762 29,412 ;; 3 2,777 719,136 29,601 ;; 2 2,618 19,049,310 29,426 ;; 1 3,480 721,983 28,989 ;; 0.07396 100.75935 0.79684 ;; 0.07806 19.31490 0.78612 5 best ;; 0.07437 19.26291 0.78939 4 best ;; ;; In the above, the first six lines are each of the epochs, with the ;; numbers representing total time (in internal clock units) taken to do ;; 150 iterations minus the time for 150 iterations of the #'empty-lambda. ;; The last column is the time taken for 150 iterations of #'empty-lambda. ;; E.g. on the first epoch (#6), 150 (sin 3.2) took 2,684 clock units and ;; (princ-to-string 3.2) took 720,555. Notice that on the second to last ;; epoch a garbage collection happened during the princ-to-string iterations. ;; The final lines shows the average time, in microseconds, for each call ;; of expression, with the last line showing the average over the 4 best ;; (i.e. closest to mean average time) epochs. ;; NOTE: The fewer other processes running on the machine at the same ;; time (even typing), the more accurate a measure this macro will return. (let ((expressions (before-keyword args)) ; List of expressions to compare (expr-fns NIL)) ; Names of expression functions `(progn ;; ;; Build functions (empty-lambda), (expr1), (expr2), ... ;; (defun empty-lambda () NIL) ,@(let ((expr-num 0) (expr-fns-defun-code NIL)) (dolist (expr expressions) (incf expr-num) (push (read-from-string (concatenate 'string "EXPR" (princ-to-string expr-num))) expr-fns) (push `(defun ,(car expr-fns) () NIL ,expr) expr-fns-defun-code)) (push 'empty-lambda expr-fns) expr-fns-defun-code) ;; ;; Compile functions (empty-lambda), (expr1), (expr2), ... ;; ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (push `(unless (compiled-function-p #',expr-fn) (compile ',expr-fn)) code)) code) (let ((start-time nil) (end-time nil) (empty-lambda-time nil) (iter ,(key-value :iter args)) ; Iterations per comparison (epochs ,(key-value :epochs args)) ; Number of separate comparisons (time ,(or (key-value :time args) ; Desired total time comparing (* (length expressions) 10)))) ;; ;; Make sure expressions are in core memory. ;; ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (push `(,expr-fn) code)) code) ;; ;; Estimate time for one iteration through all functions. ;; (setf start-time (get-internal-real-time)) (dotimes (i 10) ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (push `(,expr-fn) code)) code)) (setf end-time (get-internal-real-time)) (setf empty-lambda-time (/ (/ (- end-time start-time) 10) internal-time-units-per-second)) ;; ;; Calculate iter and/or epochs from this (if not provided). ;; (cond ((null iter) (unless epochs (setf epochs 10)) (let* ((exact-iter (/ (/ time empty-lambda-time) epochs)) (iter-divider (expt 10 (1- (round (log exact-iter 10)))))) (setf iter (* iter-divider (ceiling (/ exact-iter iter-divider)))))) ((null epochs) (setf epochs (round (/ (/ time empty-lambda-time) iter))))) (format t "~%Epochs ~A, iterations ~A...~%" epochs iter) ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (push `(setf (get ',expr-fn 'epoch-times) NIL) code)) code) (dotimes (i epochs) (empty-lambda) ;; ;; Calculate one epoch's time for empty-lambda function call. ;; (setf start-time (get-internal-real-time)) (dotimes (i iter) (empty-lambda)) (setf end-time (get-internal-real-time)) (setf empty-lambda-time (- end-time start-time)) (push empty-lambda-time (get 'empty-lambda 'epoch-times)) (format t "~4D" (- epochs i)) ;; ;; Calculate and display one epoch's time for each expr. ;; ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (unless (eq expr-fn 'empty-lambda) (push `(progn (,expr-fn) (setf start-time (get-internal-real-time)) (do ((i 0 (1+ i))) ((>= i iter)) (,expr-fn)) (setf end-time (get-internal-real-time)) (format t "~10:D" (- (- end-time start-time) empty-lambda-time)) (push (- (- end-time start-time) empty-lambda-time) (get ',expr-fn 'epoch-times))) code))) code) (format t "~10:D~%" empty-lambda-time)) ;; ;; Display average times (in milliseconds) for each expression, ;; removing the worst deviator each time, until only the 50% ;; closest to the mean have their average displayed. ;; (dotimes (num-remove (round (/ epochs 2))) (format t " ") ,@(let ((code NIL)) (dolist (expr-fn expr-fns) (push `(format t "~10,5F" (/ (/ (list-mean (setf (get ',expr-fn 'epoch-times) (remove-mean-deviators (get ',expr-fn 'epoch-times) :number (if (eq num-remove 0) 0 1)))) iter) (/ internal-time-units-per-second 1000))) code)) code) (if (eq num-remove 0) (format t "~%") (format t "~5D best~%" (- epochs num-remove)))))))) (defun before-keyword (list) ;; Return all of the elements in the list before the first keyword. (do ((elements list (cdr elements)) (before-list NIL)) ((or (null elements) (keywordp (car elements))) (reverse before-list)) (setf before-list (cons (car elements) before-list)))) (defun key-value (key lambda-list &optional (default-value NIL)) ;; If key is on lambda-list, then its value is returned, otherwise ;; default-value is returned. (do ((elements lambda-list (cdr elements))) ((or (null elements) (eq (car elements) key)) (if elements (cadr elements) default-value)))) (defun list-mean (list &key (key #'identity)) "Returns the mean of the list." (float (/ (let ((sum 0)) (dolist (element list) (setf sum (+ sum (funcall key element)))) sum) (length list)))) (defun remove-mean-deviators (list &key (number NIL) (percentage NIL) (key #'identity)) "Returns list with the elements which deviate the most from the list's mean removed. Number removed equals either number or percentage of the list's length." (unless number (setf number (if percentage (floor (* (length list) percentage)) 1))) (cond ((<= number 0) list) (t (remove-mean-deviators (do ((elements list (cdr elements)) (pos 0 (1+ pos)) (list-mean (list-mean list :key key)) (worst-pos 0) (worst-deviation 0) (current-deviation NIL)) ((null elements) (remove-nth worst-pos list)) (when (> (setf current-deviation (abs (- (funcall key (car elements)) list-mean))) worst-deviation) (setf worst-deviation current-deviation) (setf worst-pos pos))) :number (1- number) :key key)))) (defun remove-nth (n list) ;; Return a list that is list with its nth element removed. (let ((nth (nthcdr n list))) (append (ldiff list nth) (cdr nth)))) ;;;;;;;;;;; The result in Lucid on the Sun 4: > (time-test (really-fast-foo i1) (fast-foo i1) (slow-foo i1) (slow-foo i2) (slow-foo i3) (slow-foo i4) (fast-foo i11) (slow-foo i11) (slow-foo i22) (slow-foo i33) (slow-foo i44)) Epochs 10, iterations 6000... ... 0.01069 0.01916 0.02417 0.02933 0.02427 0.04161 0.10385 0.10587 0.12332 0.11860 0.09630 Here the time-test benchmark does 10 "epochs", with each epoch doing first 6000 iterations of (really-fast-foo i1), then 6000 iterations of (fast-foo i1), etc. The final numbers are the averaged time (in msec) for each function call over all epochs. As you can see, a call of the generic function #'really-fast-foo, only defined as a primary on everybody-inherit-class, here takes ~0.011 msec. A call of (fast-foo i1), which is also specialized as an :around on around-class1, takes nearly twice as long (0.019 msec), even though i1 doesn't inherit that :around. The #'slow-foo generic function calls, which are specialized on multiple different classes, take anywhere from 2-4 times as long (0.024 - 0.041 msec). The differences aren't quite as large on the :around-using classes (i11, i22, i33, and i44), but it is the calling of these methods that causes the slowdowns on the active primary-only using methods. Slowdowns get even more dramatic for generic functions having larger numbers of different specialized methods that are "mixed and matched" more normally than these. I couldn't illustrate any significant differences in run times with this test file in Franz, though I do get them (up to 10 times slowdown, as I do in Lucid) with my large program that has some generic-functions specialized on over 20 different classes with a number of variable mixins on run-time classes. Another question brought up by all this is why generic function calls on classes that have :arounds with one call-next-method take so much longer than calls on classes that only have a primary? E.g. fast-foo on class11 here takes 5x as long (3x as long in Franz) as fast-foo on class1 (0.104 msec vs 0.019 msec). Isn't all of the "hard" work done in looking up the effective method for a class in the first place? If the effective methods were computed and stored for each run-time class, then a call-next-method should (basically) involve primarily an additional funcall of a (known) next method function, which should be trivial in comparison to the effective-method-function lookup done by the generic function. Hopefully this will help you see what is going on. Thanks again for looking into these questions, - Trent Lange Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08242; Wed, 26 Sep 90 07:21:45 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Wed, 26 Sep 1990 07:21:25 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16135>; Wed, 26 Sep 1990 07:17:52 PDT Received: from fed.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA04979; Wed, 26 Sep 90 10:17:06 -0400 Received: from arccs3.FRB.GOV by fed.FRB.GOV (4.1/SMI-4.0) id AA03096; Wed, 26 Sep 90 08:48:53 BST Received: from localhost by arccs3.FRB.GOV (4.1/SMI-4.0) id AA14360; Wed, 26 Sep 90 08:53:44 EDT Illegal-Object: Syntax error in From: address found on alpha.xerox.com: From: Ron I.Herman ^ ^-illegal period in phrase \-phrases containing '.' must be quoted X-Ns-Transport-Id: 08002008D0FD00028671 Date: Wed, 26 Sep 1990 00:53:42 PDT From: m1rih00%fed.uucp@uunet.UU.NET Subject: Latest version of PCL To: commonloops.PARC@Xerox.com Message-Id: <9009261253.AA14360@arccs3.FRB.GOV> What is the latest version of PCL? We're returning to some earlier work using 5/22/89 Victoria PCL in conjunction with KCL. Ron Herman Federal Reserve Board Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10593; Wed, 26 Sep 90 08:49:21 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16134>; Wed, 26 Sep 1990 08:49:12 PDT Received: from elsinore.parc.xerox.com ([13.2.16.5]) by alpha.xerox.com with SMTP id <16129>; Wed, 26 Sep 1990 08:43:38 PDT Received: by elsinore.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02703; Wed, 26 Sep 90 08:43:15 PDT X-Ns-Transport-Id: 08002008D0FD0002871E Date: Wed, 26 Sep 1990 08:43:15 PDT From: Doug Cutting Subject: Re: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Wed, 26 Sep 1990 06:17:12 PDT <900926.131712z.09320.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: cutting@parc.xerox.com, commonloops.parc@xerox.com Message-Id: <9009261543.AA02703@elsinore.parc.xerox.com> Date: Wed, 26 Sep 1990 06:17:12 PDT From: Trent Lange Another question brought up by all this is why generic function calls on classes that have :arounds with one call-next-method take so much longer than calls on classes that only have a primary? E.g. fast-foo on class11 here takes 5x as long (3x as long in Franz) as fast-foo on class1 (0.104 msec vs 0.019 msec). On July 27th I submitted a patch for May Day PCL which significantly improved the performance of the common use of CALL-NEXT-METHOD in (at least) Franz Allegro 3.1 and Lucid's development compiler. (Lucid's production compiler already implements it as an optimization, as other compilers should.) In Franz it gave my benchmarks an eightfold speedup. It's not clear which of Lucid's compilers you're using, so I can't be sure this will help you, but I suspect it will. If you'd like I can send you the patch. In July I promised to merge it into the sources on Arisia if no bugs in it were found. As none have been reported I shall now do this (as soon as I have a chance). Doug Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11665; Wed, 26 Sep 90 09:17:11 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16137>; Wed, 26 Sep 1990 09:16:52 PDT Received: from elsinore.parc.xerox.com ([13.2.16.5]) by alpha.xerox.com with SMTP id <16134>; Wed, 26 Sep 1990 09:12:27 PDT Received: by elsinore.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02726; Wed, 26 Sep 90 09:12:13 PDT X-Ns-Transport-Id: 08002008D0FD0002876F Date: Wed, 26 Sep 1990 09:12:13 PDT From: Doug Cutting Subject: Re: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Wed, 26 Sep 1990 06:17:12 PDT <900926.131712z.09320.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: cutting@parc.xerox.com, commonloops.PARC@xerox.com Message-Id: <9009261612.AA02726@elsinore.parc.xerox.com> Date: Wed, 26 Sep 1990 06:17:12 PDT From: Trent Lange (defmethod fast-foo :around ((self around-class1)) (cons 'fast-foo-around (call-next-method))) (defmethod slow-foo :around ((self around-class1)) (cons 'slow-foo-around1 (call-next-method))) [ ... ] These conses are probably confusing your timings, mostly with GC overhead. If you feel you must do some real computation here, fixnum arithmetic might be better. And you might also check that your test macro itself (which I've not read carefully) does not cons. Most CLOS benchmarks should be executable without consing. (Methods which play games with #'CALL-NEXT-METHOD are a notable exception.) Consing often indicates a poor implementation of some CLOS facility, sometimes due to missing compiler optimizations. Doug Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16636; Wed, 26 Sep 90 10:30:43 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16140>; Wed, 26 Sep 1990 10:30:28 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16134>; Wed, 26 Sep 1990 10:22:34 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA28500g; Wed, 26 Sep 90 10:15:33 PDT Received: by caligula id AA00732g; Wed, 26 Sep 90 10:18:26 PDT X-Ns-Transport-Id: 08002008D0FD00028848 Date: Wed, 26 Sep 1990 10:18:26 PDT From: Jon L White Subject: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Wed, 26 Sep 1990 06:17:12 PDT <900926.131712z.09320.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: gregor@parc.xerox.com, commonloops.PARC@xerox.com Message-Id: <9009261718.AA00732@caligula> re: I couldn't illustrate any significant differences in run times with this test file in Franz, though I do get them (up to 10 times slowdown, as I do in Lucid) with my large program that has some generic-functions specialized on over 20 different classes with a number of variable mixins on run-time classes. This is precisely the symptom of the "cache assumption breakdown." Namely, you probably can't get the identically same example to be the breakdown case in two different implementations of Lisp, because just the slightest change in "hashing numbers" used for the overall technique will skew the distribution of entries in the cache. There is a verrrry non-linear change here for just a trivial skew. The other relevant tidbit is the factore of 10; that is exactly the slowdown factor I observed several years ago when first noticeing the "assumptions breakdown" problem. Compare this factor with the following numbers. re: Another question brought up by all this is why generic function calls on classes that have :arounds with one call-next-method take so much longer than calls on classes that only have a primary? E.g. fast-foo on class11 here takes 5x as long (3x as long in Franz) as fast-foo on class1 (0.104 msec vs 0.019 msec). Isn't all of the "hard" work done in looking up the effective method for a class in the first place? If the effective methods were computed and stored for each run-time class, then a call-next-method should (basically) involve primarily an additional funcall of a (known) next method function, which should be trivial in comparison to the effective-method-function lookup done by the generic function. You are right in your analyses here -- the observable slowdown ought to be the extra layer of function-entry-and-argument-collection, and subsequent argument-re-spreading-and-function-apply. In this arena, the observable time differences between a "very best" port of the PCL technology and a "pedestrian" port ought to be in the range of the 3-to-5 that you saw at the micro level between Franz and Lucid on the Sun4. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18985; Wed, 26 Sep 90 11:43:27 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16134>; Wed, 26 Sep 1990 11:43:11 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16132>; Wed, 26 Sep 1990 11:41:34 PDT Received: by spade.parc.xerox.com id <289>; Wed, 26 Sep 1990 11:41:19 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD00028924 Date: Wed, 26 Sep 1990 11:41:11 PDT Sender: From: Gregor Kiczales Subject: Re: Latest version of PCL In-Reply-To: "m1rih00%fed.uucp@uunet.UU.NET's message of Wed, 26 Sep 1990 00:53:42 PDT <9009261253.AA14360@arccs3.FRB.GOV>" To: m1rih00%fed.uucp@uunet.UU.NET Cc: commonloops.PARC@xerox.com Message-Id: <90Sep26.114119pdt.289@spade.parc.xerox.com> The latest version is May Day PCL, 5/1/90. It is available on arisia. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22393; Wed, 26 Sep 90 13:25:52 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16146>; Wed, 26 Sep 1990 13:25:34 PDT Received: from kanga.parc.xerox.com ([13.2.16.53]) by alpha.xerox.com with SMTP id <16144>; Wed, 26 Sep 1990 13:20:35 PDT Received: from miles.parc.xerox.com by kanga.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05614; Wed, 26 Sep 90 13:20:27 PDT Received: by miles (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA00252; Wed, 26 Sep 90 13:17:17 PDT X-Ns-Transport-Id: 08002008D0FD00028A56 Date: Wed, 26 Sep 1990 13:17:17 PDT From: rodrigue@parc.xerox.com Subject: Re: Compilation of methods per class. To: Jon L White Cc: commonloops.parc@xerox.com Message-Id: <9009262017.AA00252@miles> >From: Jon L White >Date: Tue, 25 Sep 1990 23:05:08 PDT >Subject: Compilation of methods per class. > >re: There was a horrible bug in Victoria Day PCL which had symptoms like > what you are mentioning --- an entry could be in the cache, but there > would still be a cache miss. I recall that bug being fixed, but I don't > know if the patch was widely distributed. > >The behaviour I'm referring to was present in previous versions too(at least >one -- maybe more). It wasn't really a bug in that it wouldstill correctly find >the cached entry; but it was a performance pitfall >in that it had to go out of line at unpredictable times to do it. > >Lucid's CLOS uses a different approach to generic function "caching", >which doesn't follow any of the PCL versions nor of that referred to inthe >L&FP90 paper. Rather, it is more akin to TICLOS's. Method-functionsand >other data are being "cached" (in a general sense) from the lookup >phase; but the data-structure in which the cached entries are stored is >ahash-table rather than a cache. > > > >-- JonL -- What do you mean "go out of line"?? What went out line and what did it do when it was "out if line"?? The "cache" implemented in the May Day version of PCL is a simple vector. The algorithm used by May Day to fill the cache (described in LFP'90) is, in many aspects, similar to open hashing, where the hash table is flat. >From: Jon L White >Date: Wed, 26 Sep 1990 10:18:26 PDT >Subject: Compilation of methods per class. > >re: I couldn't illustrate any significant differences in run times with > this test file in Franz, though I do get them (up to 10 times slowdown, > as I do in Lucid) with my large program that has some generic-functions > specialized on over 20 different classes with a number of variable mixins > on run-time classes. > >This is precisely the symptom of the "cache assumption breakdown." >Namely, you probably can't get the identically same example to be the >breakdown case in two different implementations of Lisp, because >just the slightest change in "hashing numbers" used for the overall >technique will skew the distribution of entries in the cache. There >is a verrrry non-linear change here for just a trivial skew. In Victoria Day PCL, the hashing numbers are assigned sequentially. If you set the variable pcl::*last-wrapper-cache-no* to 0 (or any constant) before defining the classes to be used in the benchmarks, you will always get the same hash number assignment. However, I seriously doubt that having different hash numbers would cause the "non-linear" changes Trent discovered. Nevertheless, if Trent's version of Victoria Day has not been fixed for the bug that Gregor mentioned, it would exhibit some slowdown, especially for larger cache sizes, where the bug's effects can be more prominent. By the way, I still don't know what is meant by "cache assumption breakdown". In May Day PCL, this has all changed, because during lookup, the entire hash table is scanned. It is the responsibility of the filler to put entries close to their primary hash location. -Luis Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25706; Wed, 26 Sep 90 14:37:00 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16148>; Wed, 26 Sep 1990 14:36:45 PDT Received: from elsinore.parc.xerox.com ([13.2.16.5]) by alpha.xerox.com with SMTP id <16157>; Wed, 26 Sep 1990 14:30:51 PDT Received: by elsinore.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02918; Wed, 26 Sep 90 14:26:47 PDT X-Ns-Transport-Id: 08002008D0FD00028B30 Date: Wed, 26 Sep 1990 14:26:47 PDT From: Doug Cutting Subject: [cutting@parc.xerox.com: optimizations for CALL-NEXT-METHOD] To: commonloops.parc@xerox.com Message-Id: <9009262126.AA02918@elsinore.parc.xerox.com> I've made the following patch to the PCL sources on Arisia. Thus the tarfile for May Day PCL now has a write date of September 26. I hope that's not too confusing. Date: Fri, 27 Jul 90 16:07:24 PDT From: Doug Cutting To: commonloops.pa@Xerox.COM Subject: optimizations for CALL-NEXT-METHOD CALL-NEXT-METHOD is currently implemented with FLET. The locally defined function refers lexically to the next method to be executed and to the list of remaining methods. This must be done to allow for methods which take advantage of CALL-NEXT-METHOD's indefinite extent, e.g. by returning #'CALL-NEXT-METHOD. Thus in some unusual cases a closure must actually be created. Unfortunately some compilers (e.g. Franz 3.1 & Lucid's development compiler) do not optimize the common case where a closure need not be created. For those who prefer code to prose: PCL wraps method bodies which refer to CALL-NEXT-METHOD with code that looks something like: (lambda (#:arg1 #:arg2) (let ((.next-method. (car *next-methods*)) (.next-methods. (cdr *next-method*))) (flet ((call-next-method () (if .next-method. (let ((*next-methods* .next-methods.)) (funcall .next-method. #:arg1 #:arg2)) (error "No next method.")))) (let ((arg1 #:arg1) (arg2 #:arg2)) ... body containing (CALL-NEXT-METHOD) ...)))) With many compilers every call to this method results in the creation of closures (over #:arg1 and #:arg2, and over .next-method. and .next-methods.). Not only is this slow, it's also consy. Until these compilers get smarter one can use the patch below, which has PCL perform the optimization for a few common cases. The trick is to use MACROLET in place of FLET when feasable. This renders the above fragment as: (lambda (#:arg1 #:arg2) (let ((.next-method. (car *next-methods*)) (.next-methods. (cdr *next-methods*))) (macrolet ((call-next-method () '(if .next-method. (let ((*next-methods* .next-methods.)) (funcall .next-method. #:arg1 #:arg2)) (error "No next method.")))) (let ((arg1 #:arg1) (arg2 #:arg2)) ... body containing (CALL-NEXT-METHOD) ...)))) I've tested this with May Day PCL and achieved an 8x speedup in Franz Allegro 3.1.13 for a CALL-NEXT-METHOD benchmark. If I don't recieve any complaints about this I'll merge it into the PCL sources on arisia.xerox.com. It implements the above optimization for methods without any optional arguments which call CALL-NEXT-METHOD with or without arguments. There are intermediate cases which could be optimized and are still not, e.g. when a method body contains both (CALL-NEXT-METHOD) and #'CALL-NEXT-METHOD, or when #'CALL-NEXT-METHOD has only dynamic extent, as in the case where it's the first arg to MAPCAR. The only disadvantage is that the code size of methods which invoke CALL-NEXT-METHOD in more than one place may grow somewhat. (Xerox users: This patch has been installed in /import/pcl/next.) All the changes are confined to boot.lisp: 345a346,347 > (closurep nil) ;flag indicating that #'call-next-method > ;was seen in the body of a method 378c380,381 < (setq save-original-args (not (cdr form))) --- > (unless (cdr form) > (setq save-original-args t)) 386a390 > (setq closurep t) 389a394 > (setq closurep t) 474c479,480 < next-method-p-p) --- > next-method-p-p > closurep) 499,500c505,544 < next-method-p-p) < (cond ((and (null save-original-args) --- > next-method-p-p > closurep) > (cond ((and (null closurep) > (null applyp) > (null save-original-args)) > ;; OK to use MACROLET, CALL-NEXT-METHOD is always passed some args, and > ;; all args are mandatory (else APPLYP would be true). > `(lambda ,lambda-list > ,@walked-declarations > (let ((.next-method. (car *next-methods*)) > (.next-methods. (cdr *next-methods*))) > (macrolet ((call-next-method ,lambda-list > '(if .next-method. > (let ((*next-methods* .next-methods.)) > (funcall .next-method. ,@lambda-list)) > (error "No next method."))) > (next-method-p () `(not (null .next-method.)))) > ,@walked-lambda-body)))) > ((and (null closurep) > (null applyp) > save-original-args) > ;; OK to use MACROLET. CALL-NEXT-METHOD is sometimes called in the > ;; body with zero args, so we have to save the original args. > (if save-original-args > ;; CALL-NEXT-METHOD is sometimes called with no args > `(lambda ,original-args > (let ((.next-method. (car *next-methods*)) > (.next-methods. (cdr *next-methods*))) > (macrolet ((call-next-method (&rest cnm-args) > `(if .next-method. > (let ((*next-methods* .next-methods.)) > (funcall .next-method. > ,@(if cnm-args cnm-args ',original-args))) > (error "No next method."))) > (next-method-p () `(not (null .next-method.)))) > (let* (,@(mapcar #'list lambda-list original-args) > ,@aux-bindings) > ,@walked-declarations > ,@walked-lambda-body)))))) > ((and (null save-original-args) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28132; Wed, 26 Sep 90 15:47:13 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16146>; Wed, 26 Sep 1990 15:47:02 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16151>; Wed, 26 Sep 1990 15:44:14 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA01442g; Wed, 26 Sep 90 15:36:30 PDT Received: by caligula id AA01364g; Wed, 26 Sep 90 15:39:24 PDT X-Ns-Transport-Id: 08002008D0FD00028C05 Date: Wed, 26 Sep 1990 15:39:24 PDT From: Jon L White Subject: Compilation of methods per class. In-Reply-To: "rodrigue@parc.xerox.com's message of Wed, 26 Sep 90 13:17:17 PDT <9009262017.AA00252@miles>" To: rodrigue@parc.xerox.com Cc: commonloops.parc@xerox.com Message-Id: <9009262239.AA01364@caligula> re: What do you mean "go out of line"?? What went out line and what did it do when it was "out if line"?? . . . By the way, I still don't know what is meant by "cache assumption breakdown". You should look at the Victoria Day and prior sources, for the uses of the function DCODE-CACHE-MISS. Calling it is "out of line"; calling it when the entry is actually in the cache is the "assumption breakdown". I say "breakdown", because it is plausible to suffer the order-of-magnitude loss to go "out of line" if it rarely happens; this is the classic analysis for caching. But an application can randomly fall into a hole where a substantial fraction of its lookups are in this case. Trent's symptoms are quite consistent with this, and less consistent with the other explanations. re: In Victoria Day PCL, the hashing numbers are assigned sequentially. . . . However, I seriously doubt that having different hash numbers would cause the "non-linear" changes Trent discovered. The "breakdown" problem isn't caused by differing hashing numbers -- rather, those differences can mask the problem at times making it very hard to reproduce exactly. I hope my previous msg didn't give you the wrong impression about what part these numbers play. Furthermore, sequential assignment of the class hashing numbers won't guarantee repeatablility of the problem across ports -- it is sensitive to the order in which the classes are assigned, and the order in which method are called on generic funtions (i.e., the way in which the cache's are filled up with entries). Just a tiny variation in any of these between two ports can make one avoid the problem where the other falls into it. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01334; Wed, 26 Sep 90 17:33:01 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Wed, 26 Sep 1990 17:32:41 PDT Received: from kanga.parc.xerox.com ([13.2.16.53]) by alpha.xerox.com with SMTP id <16136>; Wed, 26 Sep 1990 17:26:13 PDT Received: from miles.parc.xerox.com by kanga.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07201; Wed, 26 Sep 90 17:26:07 PDT Received: by miles (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA00308; Wed, 26 Sep 90 17:22:54 PDT X-Ns-Transport-Id: 08002008D0FD00028CFB Date: Wed, 26 Sep 1990 17:22:54 PDT From: rodrigue@parc.xerox.com Subject: Re: Compilation of methods per class. To: Jon L White Cc: commonloops.parc@xerox.com Message-Id: <9009270022.AA00308@miles> >From: Jon L White >Date: Wed, 26 Sep 1990 15:39:24 PDT >Subject: Compilation of methods per class. > >re: What do you mean "go out of line"?? What went out line and what >did it do when it was "out if line"?? > . . . By the way, I still don't know what is meant by "cache > assumption breakdown". > >You should look at the Victoria Day and prior sources, for the uses of >the function DCODE-CACHE-MISS. Calling it is "out of line"; calling it >when the entry is actually in the cache is the "assumption breakdown". > >I say "breakdown", because it is plausible to suffer the >order-of-magnitudeloss to go "out of line" if it rarely happens; this is >the classic analysis for caching. But an application can randomly fall >into a hole where asubstantial fraction of its lookups are in this case. >Trent's symptoms arequite consistent with this, and less consistent with >the other explanations. Are you saying that the Victoria Day cache lookup code can get repeated misses (calls to DCODE-CACHE-MISS) even though the entry is, or should be, in the cache? If so, this is exactly the bug that Gregor referred to. A fix is appended to this message. >Furthermore, sequential assignment of the class hashing numbers >won'tguarantee repeatablility of the problem across ports -- it is >sensitiveto the order in which the classes are assigned, and the order >in whichmethod are called on generic funtions (i.e., the way in which >the cache's are filled up with entries). Just a tiny variation in any of >these between two ports can make one avoid the problem where the >other falls into it. It seems to me that deterministic assignment of hashing numbers is all you need to guarantee repeatability in Victoria Day. The benchmarks run in the same order in any port, which means that classes and methods will be created and called in the same order. Also, Victoria Day is completely deterministic, in the sense that it never calls the function random. Please elaborate on exactly where non-determinism is introduced. -Luis ******** The patched version of DCODE-CACHE-MISS is included below. There is only one change, and it can be located by searching for the string "++". Basically, under certain circumstances the bug causes cache entries to be shifted around to locations where the lookup routine doesn't look or to locations where they qualify to be "dropped on the floor". If this happens, the next time the generic function is called, the damaged entries will not be found, and thus the lookup code will get a cache miss. May Day PCL doesn't suffer from this, since the lookup code checks the whole cache for an entry. It is the responsibility of the filler code to make sure that entries are placed close to their primary locations. ;;;-*-Mode:LISP; Package:(PCL LISP 1000); Base:10; Syntax:Common-lisp -*- ;;; ;;; ************************************************************************* ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990 Xerox Corporation. ;;; All rights reserved. ;;; ;;; Use and copying of this software and preparation of derivative works ;;; based upon this software are permitted. Any distribution of this ;;; software or derivative works must comply with all applicable United ;;; States export control laws. ;;; ;;; This software is made available AS IS, and Xerox Corporation makes no ;;; warranty about the software, its performance or its conformity to any ;;; specification. ;;; ;;; Any person obtaining a copy of this software is requested to send their ;;; name and post office or electronic mail address to: ;;; CommonLoops Coordinator ;;; Xerox PARC ;;; 3333 Coyote Hill Rd. ;;; Palo Alto, CA 94304 ;;; (or send Arpanet mail to CommonLoops-Coordinator.pa@Xerox.arpa) ;;; ;;; Suggestions, comments and requests for improvements are also welcome. ;;; ************************************************************************* ;;; (in-package 'pcl) ;;; This dcode-cache-miss is for Victoria Day PCL (defun dcode-cache-miss (gf ;actual generic function tertiary-miss-fn ;function to call if the ;scan of the next entries ;also misses cache ;the cache size ;size of the cache in `words' mask ;the cache mask line-size ;line size in `words' nkeys ;number of keys per entry next-scan-limit ;The limit of next entries ;to scan before declaring a ;tertiary miss. When filling ;the cache, this controls how ;many next slots to try before ;declaring a cache miss. expandp ;If this is false, don't ;expand the cache no matter ;what. dcode-constructor ;Passed to EXPAND-DCODE-CACHE &rest wrappers-and-args) ;A list whose first NKEYS ;elements are wrappers. The ;remaining elements are the ;required arguments to the ;function. (macrolet ((compute-mirror (loc) `(- size line-size ,loc)) (compute-loc-from-line (line-loc) `(compute-wrapper-cache-location-from-line cache ,line-loc mask line-size nkeys))) (tagbody restart (let* ((entries-have-value-p (%< nkeys line-size)) ;; Recompute the primary location for ourselves, since this ;; version of the computation will do obsolete instance traps. ;; It also side-effects the list of wrappers if there are any ;; new wrappers as a result of obsolete traps. (primary (compute-wrapper-cache-location-1 mask line-size nkeys wrappers-and-args)) (mirror (compute-mirror primary)) (free-next 0) (value nil)) (labels ((fill-line (loc) (let ((tail wrappers-and-args)) (dotimes (i nkeys) (setf (%svref cache (%+ i loc)) (pop tail))) (when entries-have-value-p (setf (%svref cache (%+ nkeys loc)) value)))) (copy-line (from to) (dotimes (i nkeys) (setf (%svref cache (%+ to i)) (%svref cache (%+ from i)))) (when entries-have-value-p (setf (%svref cache (%+ nkeys to)) (%svref cache (%+ nkeys from))))) (fill-primary () (when (%svref cache primary) (displace-primary)) (fill-line primary)) (displace-primary () (cond ((zerop mirror) (copy-to-next primary)) ((null (%svref cache mirror)) (copy-line primary mirror)) (t (let* ((mirror-contents-primary ;; ++ Bug fix ;; changed line below from ;; (compute-loc-from-line primary) to: (compute-loc-from-line mirror))) (cond ((zerop mirror-contents-primary) ;; The contents of the mirror location ;; are obsolete. Drop it on the floor. (copy-line primary mirror)) ((= mirror-contents-primary mirror) ;; The mirror is the primary location ;; of its contents. Leave it there. (copy-to-next primary)) (t (copy-to-next mirror) (copy-line primary mirror))))))) (copy-to-next (loc) (do ((scan-loc (%mod (%+ primary line-size) size) (%mod (%+ scan-loc line-size) size)) (limit next-scan-limit limit)) ((zerop limit) (when expandp (expand-cache))) (unless (zerop scan-loc) (unless (= scan-loc mirror) (when (or (%= scan-loc free-next) (null (%svref cache scan-loc)) (not (dotimes (i nkeys) (unless (zerop (wrapper-cache-no (%svref cache (%+ i scan-loc)))) (return t)))) (zerop (compute-loc-from-line scan-loc))) (return (copy-line loc scan-loc)))) (decf limit)))) (expand-cache () (setq cache (expand-dcode-cache gf cache size line-size nkeys next-scan-limit dcode-constructor) size (generic-function-cache-size cache) mask (make-wrapper-cache-mask (floor size line-size)) primary (compute-wrapper-cache-location-1 mask line-size nkeys wrappers-and-args) mirror (compute-mirror primary) expandp nil))) ;; ;; First, get the actual value. If this cache just has keys, ;; and no values, we will use NIL as the value. ;; ;; First try to find it by scanning cache lines after primary. ;; This scan stops when we reach next-scan-limit which is the ;; maximimum number of next lines to try. ;; ;; If we find the element before the limit, great. Otherwise, ;; this is a tertiary cache miss. Note that this doesn't cause ;; a refill. The refill will come later when we try to add ;; this entry to the cache. We use the variable FREE-NEXT to ;; show that this next location is now up for grabs though. ;; (without-interrupts (setq value (block scan-cache (do ((try (%mod (%+ primary line-size) size) (%mod (%+ try line-size) size)) (limit next-scan-limit limit)) ((zerop limit) (return-from scan-cache (prog2 (interrupts-on) (apply tertiary-miss-fn gf (nthcdr nkeys wrappers-and-args)) (interrupts-off)))) (unless (zerop try) ;The zero entry of the ;cache is never used! (let ((tail wrappers-and-args)) (unless (dotimes (i nkeys) (unless (eq (%svref cache (%+ i try)) (pop tail)) (return t))) (setq free-next try) (return-from scan-cache (and entries-have-value-p (%svref cache (%+ nkeys try)))))) (decf limit))))) (unless (or (eq value '..no-applicable-method..) (symbolp value)) (let ((old-count (cache-lock-count cache))) (setf (cache-lock-count cache) (if (= old-count most-positive-fixnum) 1 (1+ old-count))) (fill-primary))) (return-from dcode-cache-miss value))))))) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03505; Wed, 26 Sep 90 19:03:16 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16129>; Wed, 26 Sep 1990 19:03:04 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16151>; Wed, 26 Sep 1990 19:01:38 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA02556g; Wed, 26 Sep 90 18:55:07 PDT Received: by caligula id AA01703g; Wed, 26 Sep 90 18:58:01 PDT X-Ns-Transport-Id: 08002008D0FD00028D91 Date: Wed, 26 Sep 1990 18:58:01 PDT From: Jon L White Subject: Compilation of methods per class. In-Reply-To: "rodrigue@parc.xerox.com's message of Wed, 26 Sep 90 17:22:54 PDT <9009270022.AA00308@miles>" To: rodrigue@parc.xerox.com Cc: commonloops.parc@xerox.com Message-Id: <9009270158.AA01703@caligula> re: Are you saying that the Victoria Day cache lookup code can get repeated misses (calls to DCODE-CACHE-MISS) even though the entry is, or should be, in the cache? If so, this is exactly the bug that Gregor referred to. A fix is appended to this message. Your comments seems to equate "cache miss" with calling DCODE-CACHE-MISS. Despite the tempting analogy of the function's name, this is not the case, for DCODE-CACHE-MISS serves a triple purpose: (1) cache replacement step on a true miss (2) search of alternate cache "lines" when the entry is in the cache, but isn't present in the first "line" (or, perhaps second line too). (3) cache refilling, from old contents, when it is expanded to a new size. I think the bug fix you mention might be relevant to the glitch where caches were being needlesly expanded, rather than undergoing the usual "cache replacement" algorithm. As such, it is a performace loss, but is not in any substantial way relevant to the "breakdown in assumptions". That breakdown, as I previously mentioned, turns on the total percentage of lookups that result in out-of-line calls (sum of 1 and 2 above), and would still be apparent after loading in the patch. [Trent: can you clarify whether or not you have installed the patch?] If, as you said previously, someone switched the PCL technique in the May 1990 version *** so that it doesn't use classical caching techniques (in particular, so that it forgoes "cache replacement" on true miss) *** then they must have understood the "breakdown" issue. Contact me privately if this is still unclear. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11705; Thu, 27 Sep 90 10:53:31 -0700 Message-Id: <9009271753.AA11705@arisia.Xerox.COM> Received: from pucc.PRINCETON.EDU by MCC.COM with TCP/SMTP; Thu 27 Sep 90 12:47:06-CDT Received: from UKACRL.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 2147; Thu, 27 Sep 90 13:43:52 EDT Received: from RL.IB by UKACRL.BITNET (Mailer R2.03B) with BSMTP id 1544; Thu, 27 Sep 90 16:28:16 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.03B) with BSMTP id 4971; Thu, 27 Sep 90 16:28:15 BST Via: UK.AC.OU.ACSVAX; 27 SEP 90 16:28:09 BST Date: Thu, 27 SEP 90 15:58:15 GMT From: PT_MAGEE%VAX.ACS.OPEN.AC.UK@pucc.PRINCETON.EDU To: common-lisp-object-system@mcc.com Subject: Good discussion on General OO stuff Sender: JANET "PT_MAGEE@UK.AC.OPEN.ACS.VAX" Is there a good discussion on what types of things are *required* for a system in order to call it Object Oriented? We're constantly coming up against systems which say 'We've got a real object system' and then discover that they have no multiple inheritance, methods, classes, no good class redefinition abilites etc. Obviously some of this is still up for discussion (eg some people don't believe multiple inheritance is good let alone neccesary) and some is fairly subjective (ie should a class be an instance of a class) but we would love to have a good set of examples that we can give to these developers and receive some quantifiable data - rather like Codds 10 rules for relational databases. Is anyone doing this already or maybe a favorite little trick that you ask when you meet someone who uses your 'most loathed object system'. I may consider putting these together for public consumption if there is some interest. Thanks Peter T. Magee Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23306; Thu, 27 Sep 90 14:35:07 -0700 Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Thu 27 Sep 90 16:18:23-CDT Received: from nero.parc.xerox.com by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22399; Thu, 27 Sep 90 14:18:37 -0700 Received: by nero.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA01248; Thu, 27 Sep 90 14:18:22 PDT Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.nero.parc.xerox.com.sun4.40 via MS.5.6.nero.parc.xerox.com.sun4_40; Thu, 27 Sep 90 14:18:22 -0700 (PDT) Message-Id: Date: Thu, 27 Sep 90 14:18:22 -0700 (PDT) From: Danny Bobrow To: common-lisp-object-system@MCC.COM, PT_MAGEE%VAX.ACS.OPEN.AC.UK@pucc.PRINCETON.EDU Subject: Re: Good discussion on General OO stuff In-Reply-To: <90Sep27.105351pdt.16152@alpha.xerox.com> References: <90Sep27.105351pdt.16152@alpha.xerox.com> There is an excellent paper by Bjorne Stroustrup called "What is Object Oriented Programming?" that appeared in C++ Usenix Newss, and perhaps other places. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00827; Thu, 27 Sep 90 17:06:40 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 27 Sep 90 19:01:23-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 852068; 27 Sep 1990 20:01:09-0400 Date: Thu, 27 Sep 1990 20:04-0400 From: David A. Moon Subject: Making (CLASS-OF ) be EQ to To: Jon L White Cc: common-lisp-object-system@mcc.com In-Reply-To: <9009251814.AA04061@caligula> Message-Id: <19900928000454.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Tue, 25 Sep 1990 14:14 EDT From: Jon L White Yea, there were numerous thorny issues connected to that one line of code -- (change-class my-std-class my-std-class). Here's a high-order, three-line summary of each one: Thanks. 1. When CHANGE-CLASS is applied to a class object, shouldn't it also call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago said yes.] Perhaps. Doesn't it also need to check metaclass compatibility? You shouldn't be able to use CHANGE-CLASS to change to a metaclass that uses a totally incompatible representation, just as you can't use subclassing to do that. And if the metaclasses are compatible, maybe it isn't really necessary to make the instances obsolete. I don't really have a strong opinion on what should happen here. Should this be as a :BEFORE method specialized to class CLASS? No opinion. 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? This is just CALL-NEXT-METHOD, so you must mean something that I didn't understand. 3. Have we adequately enumerated in a single place the kinds of system definitions that user code can redefine without suffering "undefined consequences"; e.g., are SETF function names and methods covered? This is metaobject protocol business. I looked at LISP-SYMBOL-REDEFINITION:MAR89-X3J13 version 8 and expected that it would prohibit this entirely, but in fact it's silent on the point. However, in the absence of a metaobject protocol defining what it means, it's clearly unsupportable for users to define methods on Lisp-supplied generic functions. Maybe another issue covered this, or maybe it's a hole in the language waiting to be filled by the metaobject protocol. I'm especially interested in what Symbolics does for point 1. I imagine the consequences are undefined. I don't really know. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02640; Thu, 27 Sep 90 17:47:13 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Thu 27 Sep 90 19:43:23-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16174>; Thu, 27 Sep 1990 17:43:12 PDT Received: by spade.parc.xerox.com id <274>; Thu, 27 Sep 1990 17:43:09 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: Moon%STONY-BROOK.SCRC.Symbolics.COM@MCC.COM Cc: jonl@lucid.com, common-lisp-object-system@MCC.COM In-Reply-To: 's message of Thu, 27 Sep 1990 17:04:00 PDT <19900928000454.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: Making (CLASS-OF ) be EQ to Line-Fold: NO Message-Id: <90Sep27.174309pdt.274@spade.parc.xerox.com> Date: Thu, 27 Sep 1990 17:43:05 PDT I looked at LISP-SYMBOL-REDEFINITION:MAR89-X3J13 version 8 and expected that it would prohibit this entirely, but in fact it's silent on the point. However, in the absence of a metaobject protocol defining what it means, it's clearly unsupportable for users to define methods on Lisp-supplied generic functions. Maybe another issue covered this, or maybe it's a hole in the language waiting to be filled by the metaobject protocol. At the last X3J13 meeting, I pointed out that the latest version of LISP-SYMBOL-REDEFINITION was deficient in this respect. I also gave the relevant text from the latest MOP to Kim Barrett, and he got the revised version when it came out in July. I suspect that text could be lifted into the final ANSI draft. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03359; Thu, 27 Sep 90 18:02:38 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 27 Sep 90 19:55:09-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA13458g; Thu, 27 Sep 90 17:49:34 PDT Received: by caligula id AA03245g; Thu, 27 Sep 90 17:52:27 PDT Date: Thu, 27 Sep 90 17:52:27 PDT From: Jon L White Message-Id: <9009280052.AA03245@caligula> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@mcc.com In-Reply-To: David A. Moon's message of Thu, 27 Sep 1990 20:04-0400 <19900928000454.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Making (CLASS-OF ) be EQ to re: 1. When CHANGE-CLASS is applied to a class object, shouldn't it also call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago said yes.] Perhaps. Doesn't it also need to check metaclass compatibility? Hmmmmm, now that you mention it . . . I guess checking VALIDATE-SUPERCLASS on the class-prototypes is ok? 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? This is just CALL-NEXT-METHOD, so you must mean something that I didn't understand. I don't think CALL-NEXT-METHOD does exactly that. For example, CALL-NEXT-METHOD from within a single :AROUND method defined at the point will invoke (probably) the primary method defined at , rather than, say, the "effective" method defined for point . I may have misunderstood the semantics of SEND-AS, but that what I expected it to mean -- "Treat this argument, for purposes of message/generic-function dispatch, as if it's type were explicity FOOBAR rather than it's real type." Now, I fully agree with you that replaceing Method Combination by simply SEND-AS/LEXPR-SEND-AS is a loss; but an ocasional "exceptional" use of this flavorized kludge might not be so bad. As my first note mentioned, one is very tempted to use :AROUND methods and CALL-NEXT-METHOD; but as Gregor indicated, CLOS just isn't one of "those" kinds of language that make explicit delegation like this easy. re: [redefinition prohibitions for various CLOS constructs ...] Maybe another issue covered this, or maybe it's a hole in the language waiting to be filled by the metaobject protocol. Probably the latter. By now, it's become a crater. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06123; Fri, 28 Sep 90 07:32:14 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 28 Sep 90 09:28:04-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 852264; 28 Sep 1990 10:28:07-0400 Date: Fri, 28 Sep 1990 10:31-0400 From: David A. Moon Subject: Making (CLASS-OF ) be EQ to To: Jon L White Cc: common-lisp-object-system@mcc.com In-Reply-To: <9009280052.AA03245@caligula> Message-Id: <19900928143152.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Thu, 27 Sep 1990 20:52 EDT From: Jon L White re: 1. When CHANGE-CLASS is applied to a class object, shouldn't it also call MAKE-INSTANCES-OBSOLETE on it? [PCL mail from some time ago said yes.] Perhaps. Doesn't it also need to check metaclass compatibility? Hmmmmm, now that you mention it . . . I guess checking VALIDATE-SUPERCLASS on the class-prototypes is ok? I wouldn't know. 2. If there are methods defined on function FOO at classes respectively , then how can one temporary override the effective method at that point, and cause it to defer to the next most specific one? This is just CALL-NEXT-METHOD, so you must mean something that I didn't understand. I don't think CALL-NEXT-METHOD does exactly that. For example, CALL-NEXT-METHOD from within a single :AROUND method defined at the point will invoke (probably) the primary method defined at , rather than, say, the "effective" method defined for point . I may have misunderstood the semantics of SEND-AS, but that what I expected it to mean -- "Treat this argument, for purposes of message/generic-function dispatch, as if it's type were explicity FOOBAR rather than it's real type." Now, I fully agree with you that replaceing Method Combination by simply SEND-AS/LEXPR-SEND-AS is a loss; but an ocasional "exceptional" use of this flavorized kludge might not be so bad. As my first note mentioned, one is very tempted to use :AROUND methods and CALL-NEXT-METHOD; but as Gregor indicated, CLOS just isn't one of "those" kinds of language that make explicit delegation like this easy. I think I might understand what you're getting at now. Here's how I react to this sort of thing: The programmer has recognized that a certain method provides some functionality that he would like to invoke, and wants to have a name for that method and call it by its name. Well, Lisp already has a way to name pieces of functionality and allow them to be called by name, and I don't think we need to add another one. The invokable functionality should have been made a function in its own right, and the body of the method should have been a call to that function. In the more general case where it was a set of methods that the programmer wanted to invoke, this functionality should have been made a generic function in its own right, and the method for one generic function should be a call to the other generic function. The "problem" with what I say here is that the modularity has to be worked out in advance. I wouldn't allow people to reach inside an existing program and, without changing the source code of that program, pull out some functionality that they want, but which was not packaged into a function by the author of that program. Indeed, I wouldn't allow that. Years ago I had some experience with object systems that worked that way and my conclusion was that it was a bad idea. I think the author of the program has to decide what the modularity is and what the protocols are, and the user of the program has to live with that or else get the program changed "officially." Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07928; Fri, 28 Sep 90 08:15:26 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16190>; Fri, 28 Sep 1990 08:15:09 PDT Received: from pucc.PRINCETON.EDU ([128.112.129.99]) by alpha.xerox.com with SMTP id <16186>; Fri, 28 Sep 1990 08:08:37 PDT Received: from UKACRL.BITNET by pucc.PRINCETON.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6835; Fri, 28 Sep 90 10:04:25 EDT Received: from RL.IB by UKACRL.BITNET (Mailer R2.03B) with BSMTP id 2566; Fri, 28 Sep 90 14:18:36 BST Received: from RL.IB by UK.AC.RL.IB (Mailer R2.03B) with BSMTP id 0226; Fri, 28 Sep 90 14:18:35 BST Via: UK.AC.OU.ACSVAX; 28 SEP 90 14:18:28 BST X-Ns-Transport-Id: 08002008D0FD00029B3A Date: Fri, 28 Sep 1990 07:18:51 PDT Sender: From: PT_MAGEE%VAX.ACS.OPEN.AC.UK@pucc.PRINCETON.EDU Subject: Good discussion on General OO stuff To: commonloops.parc@xerox.com Message-Id: <90Sep28.080837pdt.16186@alpha.xerox.com> Is there a good discussion on what types of things are *required* for a system in order to call it Object Oriented? We're constantly coming up against systems which say 'We've got a real object system' and then discover that they have no multiple inheritance, methods, classes, no good class redefinition abilites etc. Obviously some of this is still up for discussion (eg some people don't believe multiple inheritance is good let alone neccesary) and some is fairly subjective (ie should a class be an instance of a class) but we would love to have a good set of examples that we can give to these developers and receive some quantifiable data - rather like Codds 10 rules for relational databases. Is anyone doing this already or maybe a favorite little trick that you ask when you meet someone who uses your 'most loathed object system'. I may consider putting these together for public consumption if there is some interest. Thanks Peter T. Magee Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12703; Fri, 28 Sep 90 20:28:27 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 28 Sep 90 22:26:22-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA25851g; Fri, 28 Sep 90 20:20:09 PDT Received: by caligula id AA04433g; Fri, 28 Sep 90 20:23:06 PDT Date: Fri, 28 Sep 90 20:23:06 PDT From: Jon L White Message-Id: <9009290323.AA04433@caligula> To: PT_MAGEE%VAX.ACS.OPEN.AC.UK@pucc.PRINCETON.EDU Cc: common-lisp-object-system@mcc.com In-Reply-To: PT_MAGEE%VAX.ACS.OPEN.AC.UK@pucc.PRINCETON.EDU's message of Thu, 27 SEP 90 15:58:15 GMT <9009271747.AA09394@lucid.com> Subject: Good discussion on General OO stuff re: ... we would love to have a good set of examples that we can give to these developers and receive some quantifiable data - rather like Codds 10 rules for relational databases. I'm very skeptical that the buzz word of "Object-Oriented" will ever submit to a codification (no pun) as easily as "relational database" did. However, towards your goal, I wouldn't hesitate to recommend the very accessible article introductory article "The Object of Desire" in the May 1 1989 issue of Datamation. The author (whose name has ocasionally appeared on this email list) makes a strikingly simple, strong case for multiple inheritance in terms of the fundamentals of OO programming -- program reuse, separation of operations from their names, extension through inhertiance specialization, and so on. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13542; Fri, 28 Sep 90 21:30:52 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 28 Sep 90 23:28:35-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA26341g; Fri, 28 Sep 90 21:23:06 PDT Received: by caligula id AA04488g; Fri, 28 Sep 90 21:26:05 PDT Date: Fri, 28 Sep 90 21:26:05 PDT From: Jon L White Message-Id: <9009290426.AA04488@caligula> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@mcc.com In-Reply-To: David A. Moon's message of Fri, 28 Sep 1990 10:31-0400 <19900928143152.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Making (CLASS-OF ) be EQ to re: The invokable functionality should have been made a function in its own right, and the body of the method should have been a call to that function. . . . The "problem" with what I say here is that the modularity has to be worked out in advance. I wouldn't allow people to reach inside an existing program and, without changing the source code of that program, pull out some functionality that they want, but which was not packaged into a function by the author of that program. Well that's precisely the "rub". The object-oriented approach is that Programmer A's interface, which includes a listing of the methods and their signatures, should be usable by programmer B without having to delve into the source code (as I ultimately wound up doing for Kim!) However, the unit of functionality needed by this very temporary patch was the effective method for specializers ; and by all that is holy in CLOS and OO languages in general, that cannot be packaged out into a function by any of the various method's authors. This is not the first time such a need was perceived. Last summer (of 1989) some guy from a European research center was starting to port an application from their own home-grown Object-Oriented system into Lucid's CLOS, and found a low-frequency place where APPLY-METHOD was just the cat's meow. Although I very much dislike the word COMPUTE in COMPUTE-EFFECTIVE-METHOD (I would prefer something like FIND, or GET, or whatever ... but who cares), it would seem that these two might go hand-in-hand towards satisfying this perceived need for the very ocasional "delegation." -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00602; Sat, 29 Sep 90 15:42:58 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16133>; Sat, 29 Sep 1990 15:32:36 PDT Received: from lanai.cs.ucla.edu ([131.179.128.13]) by alpha.xerox.com with SMTP id <16322>; Sat, 29 Sep 1990 15:14:18 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA13344; Fri, 28 Sep 90 16:42:39 -0700 X-Ns-Transport-Id: 08002008D0FD0002A200 Date: Fri, 28 Sep 1990 16:42:39 PDT From: Trent Lange Subject: Re: Compilation of methods per class. In-Reply-To: "Message of Wed, 26 Sep 90 10:18:26 PDT from \"Jon L White \" <9009261718.AA00732@caligula>.news." To: commonloops.PARC@Xerox.com Message-Id: <900928.234239z.13313.lange@lanai.cs.ucla.edu> I installed Doug Cutting's call-next-method patch, but I unfortunately couldn't detect any significant speedup, at least in Lucid 3.0.1 on the Sun-4 or even Allegro 3.1.13.1 on the Sun-4. (Changing the conses in the body of my test methods to fixnum arithmetic made no difference in the timings either.) I've been using May Day (rev 2) in all cases. Most of the hypotheses so far involve the caching scheme in Victoria Day and older versions of PCL. Are there any ideas why these generic function call slowdowns might occur in May Day? I don't know if this helps any, but further experimentation revealed that the time to process a generic function call is dramatically effected by an interaction between the order in which the first generic function call on each class occurs and the order in which the first make-instance on the class occurs. This is true for even the simplest example, e.g. with classes and methods: (defclass everybody-inherit-class () ()) (defclass class1 (everybody-inherit-class) ()) (defclass class2 (everybody-inherit-class) ()) (defmethod really-fast-foo ((self everybody-inherit-class)) 10) (defmethod slow-foo ((self class1)) 31) (defmethod slow-foo ((self class2)) 32) If the first usages are: (defvar i1 (make-instance 'class1)) (defvar i2 (make-instance 'class2)) (slow-foo i1) (slow-foo i2) Then the following run times results (Lucid on Sun-4): > (time-test (really-fast-foo i1) (slow-foo i1) (slow-foo i2))) 0.01181 0.01394 0.01392 If, on the other hand, the two make-instances are swapped OR the first calls to slow-foo are swapped, then the times are 0.01181, 0.01810, and 0.01652 (respectively). If both are swapped, then the times go back to the original. These difference in run times themselves aren't huge (between 17 and 53% over the generic specialized only once, but perhaps they are a clue as to what is going on the larger case. When I made these kinds of changes for the test file I sent out last time (with 5 primary and 4 :around specializations of slow-foo), the run time differences were more dramatic, making times range from nearly as fast as the generic functions with single specializations to 3 times slower by only varying order of initial generic function calls. Hopefully this will mean something to somebody, though maybe not. - Trent Lange Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28713; Mon, 1 Oct 90 02:08:20 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16230>; Mon, 1 Oct 1990 01:47:07 PDT Received: from sun2.nsfnet-relay.ac.uk ([128.86.8.45]) by alpha.xerox.com with SMTP id <16219>; Mon, 1 Oct 1990 01:44:00 PDT Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk with SMTP inbound id aa01083; Mon, 1 Oct 90 8:28:56 +0000 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa01608; 1 Oct 90 8:33 BST X-Ns-Transport-Id: 08002008D0FD0002A873 Date: Sat, 29 Sep 1990 11:38:43 PDT From: tim@cstr.edinburgh.ac.uk Subject: PRINT-OBJECT, May-day classes & methods in same file To: commonloops.PARC@Xerox.com Message-Id: <6538.9009291838@kahlo.cstr.ed.ac.uk> I have two, hopefully simple questions about May-day PCL. I often use fairly complex after methods for INITIALIZE-INSTANCE, typically for filling slots from a file. It *seems* to be the case that trying to print an object before INITIALIZE-INSTANCE has done its work is dangerous; is this true? It would make good sense if it was. The second question is to do with the business of not being able to have DEFCLASS and DEFMETHOD forms in the same file. Well I do, and I never got around to applying the fix mentioned in the notes.text file. But. The way I almost always work is: Load the source of the file. Edit & redefine things. Compile the file (in the Lisp image with the source loaded). The point being that I (virtually?) never compile methods in images which don't have the classes defined anyway by virtue of the source being loaded (Or, more probably, the source to any modifications + the previous compiled version). Is it the case that the resulting compiled file *will* work OK? It seems to on both the implementations I use (Xerox Medley & Franz Allegro CL). --tim Tim Bradshaw. Internet: tim%ed.cstr@nsfnet-relay.ac.uk UUCP: ...!uunet!mcvax!ukc!cstr!tim JANET: tim@uk.ac.ed.cstr "Quis custodiet ipsos custodes?" Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11581; Mon, 1 Oct 90 08:44:49 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16308>; Mon, 1 Oct 1990 08:44:19 PDT Received: from ulrik.uio.no ([129.240.2.4]) by alpha.xerox.com with SMTP id <16266>; Mon, 1 Oct 1990 08:35:15 PDT Received: from humanist.uio.no by ulrik.uio.no with SMTP id ; Mon, 1 Oct 1990 15:52:44 +0100 X-Ns-Transport-Id: 08002008D0FD0002AA0E Date: Mon, 1 Oct 1990 07:52:34 PDT From: Rolf Lindgren Subject: pcl to Kyoto Common Lisp To: CommonLoops.PARC@Xerox.COM Message-Id: <9010011452.AAhumanist03576@humanist.uio.no> Below is a transcript of an attempt to compile pcl to Kyoto Common Lisp on a DECStation 3100. A way into the process, kcl reports that the stack limit is exceeded, dumps core and aborts. The most interesting part, I assume, is the very last screenfull. Any suggestions that leads to a solution to the problem is greatly appreciated. Thank you. Rolf Lindgren | "The opinions expressed above are 612 Bjerke Studentheim | not necessarily those of anyone" N-0589 OSLO 5 | rolfl@humanist.uio.no Script started on Mon Oct 1 15:35:35 1990 /hf/humanist/u1/rolfl humanist-1> kcl AKCL (Austin Kyoto Common Lisp) Version(1.492) Fri Sep 28 11:37:02 MET DST 1990 Contains Enhancements by W. Schelter Changes in version 1-455 definitely require recompilation of user files. Dokumentasjon i ~rolfl/src/akcl/docs og i ~rolfl/doc/kcl, sp|rsm}l og erfaringer til rolfl@ulrik. >(load "src/pcl/defsys.lsp") Loading src/pcl/defsys.lsp Finished loading src/pcl/defsys.lsp T >(pcl::compile-pcl) Compiling KCL-PATCHES... Compiling /hf/humanist/u1/rolfl/src/pcl/kcl-patches.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/kcl-patches.o. Loading binary of KCL-PATCHES... Compiling PKG... Compiling /hf/humanist/u1/rolfl/src/pcl/pkg.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/pkg.o. Loading binary of PKG... Compiling WALK... Compiling /hf/humanist/u1/rolfl/src/pcl/walk.lsp. End of Pass 1. ;; Note: Tail-recursive call of WALK-TEMPLATE was replaced by iteration. ;; Note: Tail-recursive call of WALK-TEMPLATE was replaced by iteration. ;; Note: Tail-recursive call of WALK-TEMPLATE-HANDLE-REPEAT-1 was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/walk.o. Loading binary of WALK... Compiling ITERATE... Compiling /hf/humanist/u1/rolfl/src/pcl/iterate.lsp. ; (DEFUN OPTIMIZE-ITERATE-FORM ...) is being compiled. ;; Warning: The ignored variable V is used. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/iterate.o. Loading binary of ITERATE... Compiling MACROS... Compiling /hf/humanist/u1/rolfl/src/pcl/macros.lsp. End of Pass 1. ;; Note: Tail-recursive call of MAKE-CAXR was replaced by iteration. ;; Note: Tail-recursive call of MAKE-CDXR was replaced by iteration. ;; Note: Tail-recursive call of REDUCE-CONSTANT was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/macros.o. Loading binary of MACROS... Compiling LOW... Compiling /hf/humanist/u1/rolfl/src/pcl/low.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/low.o. Loading binary of LOW... Compiling KCL-LOW... Compiling /hf/humanist/u1/rolfl/src/pcl/kcl-low.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/kcl-low.o. Loading binary of KCL-LOW... Compiling FIN... Compiling /hf/humanist/u1/rolfl/src/pcl/fin.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/fin.o. Loading binary of FIN... Compiling DEFCLASS... Compiling /hf/humanist/u1/rolfl/src/pcl/defclass.lsp. ; (DEFUN EXPAND-DEFCLASS ...) is being compiled. ;; The variable *DEFCLASS-TIMES* is undefined. ;; The compiler will assume this variable is a global. End of Pass 1. ;; Note: Tail-recursive call of COLLECT-FORMS was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/defclass.o. Loading binary of DEFCLASS... Compiling DEFS... Compiling /hf/humanist/u1/rolfl/src/pcl/defs.lsp. ; (DEFUN DO-SATISFIES-DEFTYPE ...) is being compiled. ;; Warning: The variable EXPAND-FN is not used. End of Pass 1. ;; Note: Tail-recursive call of *TYPEP was replaced by iteration. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /hf/humanist/u1/rolfl/local/lib/pcl/defs.o. Loading binary of DEFS...grow failed because stack limit exceeded, pid 3433, proc saved_kcl ts = 0x158, ds = 0x727, ss = 0x80 grow failed because stack limit exceeded, pid 3433, proc saved_kcl ts = 0x158, ds = 0x727, ss = 0x80 grow failed because stack limit exceeded, pid 3433, proc saved_kcl ts = 0x158, ds = 0x727, ss = 0x80 sendsig: can't grow stack, pid 3433, proc saved_kcl grow failed because stack limit exceeded, pid 3433, proc saved_kcl ts = 0x158, ds = 0x727, ss = 0x80 /local/bin/kcl: 3433 Illegal instruction - core dumped /hf/humanist/u1/rolfl humanist-2> exit script done on Mon Oct 1 15:44:01 1990 Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12176; Mon, 1 Oct 90 08:55:49 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Mon 1 Oct 90 10:41:12-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 852979; 1 Oct 1990 11:40:33-0400 Date: Mon, 1 Oct 1990 11:44-0400 From: David A. Moon Subject: Making (CLASS-OF ) be EQ to To: Jon L White Cc: common-lisp-object-system@mcc.com In-Reply-To: <9009290426.AA04488@caligula> Message-Id: <19901001154428.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Sat, 29 Sep 1990 00:26 EDT From: Jon L White re: The invokable functionality should have been made a function in its own right, and the body of the method should have been a call to that function. . . . The "problem" with what I say here is that the modularity has to be worked out in advance. I wouldn't allow people to reach inside an existing program and, without changing the source code of that program, pull out some functionality that they want, but which was not packaged into a function by the author of that program. Well that's precisely the "rub". The object-oriented approach is that Programmer A's interface, which includes a listing of the methods and their signatures, should be usable by programmer B without having to delve into the source code (as I ultimately wound up doing for Kim!) However, the unit of functionality needed by this very temporary patch was the effective method for specializers ; and by all that is holy in CLOS and OO languages in general, that cannot be packaged out into a function by any of the various method's authors. Not so, it can be packaged into a generic function. This is not the first time such a need was perceived. Last summer (of 1989) some guy from a European research center was starting to port an application from their own home-grown Object-Oriented system into Lucid's CLOS, and found a low-frequency place where APPLY-METHOD was just the cat's meow. Although I very much dislike the word COMPUTE in COMPUTE-EFFECTIVE-METHOD (I would prefer something like FIND, or GET, or whatever ... but who cares), it would seem that these two might go hand-in-hand towards satisfying this perceived need for the very ocasional "delegation." I certainly believe that this is a perceived need. I show no sign of ever being convinced that it is a real need, i.e. that there is no other reasonable way to get the job done. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12327; Mon, 1 Oct 90 09:01:25 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16137>; Mon, 1 Oct 1990 09:01:06 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16184>; Mon, 1 Oct 1990 08:57:42 PDT Received: by spade.parc.xerox.com id <274>; Mon, 1 Oct 1990 08:57:16 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002AAE0 Date: Mon, 1 Oct 1990 08:57:02 PDT Sender: From: Gregor Kiczales Subject: Re: PRINT-OBJECT, May-day classes & methods in same file In-Reply-To: "tim@cstr.edinburgh.ac.uk's message of Sat, 29 Sep 1990 11:38:43 PDT <6538.9009291838@kahlo.cstr.ed.ac.uk>" To: tim@cstr.edinburgh.ac.uk Cc: commonloops.PARC@xerox.com Message-Id: <90Oct1.085716pdt.274@spade.parc.xerox.com> X-Ns-Transport-Id: 08002008D0FD0002A873 Date: Sat, 29 Sep 1990 11:38:43 PDT From: tim@cstr.edinburgh.ac.uk I often use fairly complex after methods for INITIALIZE-INSTANCE, typically for filling slots from a file. It *seems* to be the case that trying to print an object before INITIALIZE-INSTANCE has done its work is dangerous; is this true? It would make good sense if it was. Well, this depends on the print-object method you have defined, applicable to objects of that class. If that method generates an error, perhaps by attempting to access an unbound slot, then the printer will run into troubles (exactly what kind depends on what Lisp you are using, and whether you were in the debugger to start with.) PCL's default methods on print-object are written so that they won't cause such errors, you may want to re-write your methods to also do this checking. Is it the case that the resulting compiled file *will* work OK? It seems to on both the implementations I use (Xerox Medley & Franz Allegro CL). Yes, it will. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18857; Mon, 1 Oct 90 11:45:05 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16228>; Mon, 1 Oct 1990 11:44:45 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16302>; Mon, 1 Oct 1990 11:39:52 PDT Received: by spade.parc.xerox.com id <276>; Mon, 1 Oct 1990 11:37:46 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002ACC0 Date: Mon, 1 Oct 1990 11:37:46 PDT Sender: From: Gregor Kiczales Subject: Re: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Fri, 28 Sep 1990 16:42:39 PDT <900928.234239z.13313.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: commonloops.PARC@xerox.com Message-Id: <90Oct1.113746pdt.276@spade.parc.xerox.com> I am unable to reproduce quite the results you show. At the end of this message is some code which is largely based on your example. It differs only in the timing macro used, and that it automates (using PCL internal stuff) the process of restarting from scratch to `fill the caches' in the other order. Using this data, I show that for 10000 calls to SLOW-FOO, the best time (in seconds, on a SUN 4/330, in Lucid 3.0.1) is .13. Whatever variation there is doesn't seem to be related to the order in which the `caches are filled'. This, of course, ignores the first run of each test after doing a reset to allow time for the caches to fill. Could you try this code, or look at this code, to see how it differs with what you are measuring. Gregor (use-package 'pcl) (defclass everybody-inherit-class () ()) (defclass class1 (everybody-inherit-class) ()) (defclass class2 (everybody-inherit-class) ()) (defmethod really-fast-foo ((self everybody-inherit-class)) 10) (defmethod slow-foo ((self class1)) 31) (defmethod slow-foo ((self class2)) 32) (defvar i1 (make-instance 'class1)) (defvar i2 (make-instance 'class2)) (defun test (x y) (let ((i1 (make-instance 'class1)) (i2 (make-instance 'class2))) (setq y (/ y 2)) (dotimes (i x) (reset) (dotimes (i y) (slow-foo i1) (slow-foo i2)) (time (dotimes (i y) (slow-foo i1) (slow-foo i2))) (time (dotimes (i y) (slow-foo i1) (slow-foo i2))) (reset) (dotimes (i y) (slow-foo i1) (slow-foo i2)) (time (dotimes (i y) (slow-foo i2) (slow-foo i1))) (time (dotimes (i y) (slow-foo i2) (slow-foo i1)))))) (defun reset () (pcl::invalidate-discriminating-function #'slow-foo) (pcl::invalidate-discriminating-function #'really-fast-foo)) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00008; Mon, 1 Oct 90 16:21:12 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16208>; Mon, 1 Oct 1990 16:20:30 PDT Received: from turing.cs.rpi.edu ([128.213.1.1]) by alpha.xerox.com with SMTP id <16137>; Mon, 1 Oct 1990 15:10:02 PDT Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA09487; Mon, 1 Oct 90 18:08:57 EDT X-Ns-Transport-Id: 08002008D0FD0002AF37 Date: Mon, 1 Oct 1990 15:08:57 PDT From: harrisr@turing.cs.rpi.EDU (Richard Harris) Subject: Redefinition of classes having existing instances To: commonloops.parc@xerox.com Message-Id: <9010012208.AA09487@turing.cs.rpi.edu> Redefinition of classes having existing instances can make the old instances unusable because of two bugs. Here are test cases and fixes for both bugs. -------------- Richard Harris ----------------------------------------------- ;1. Fix a bug in invalidate-wrapper: when the state is obsolete, ; the state of every previous wrapper must be changed to obsolete. ; [added the form (when (eq state 'obsolete) ...).] ;Test (defclass c1 () ()) (defclass c1a () ()) (defclass c3 (c1) ((a :initform 'one)))) (defmethod test ((v c3)) (slot-value v 'a)) (print (test (setq z1 (make-instance 'c3)))) ; => ONE (defclass c3 (c1a) ((a :initform 'one)))) (defclass c2 () ((b :initform 'two))) (defclass c3 (c2) ((a :initform 'one))) (print (test (setq z2 (make-instance 'c3)))) ; => ONE (defclass c2 () ((b :initform 'two))) (print (test z2)) ; => TWO (print (test z1)) ; error - - - - - - - - - - - - ;cache.lisp (defun invalidate-wrapper (owrapper state nwrapper) (ecase state ((flush obsolete) (let ((new-previous ())) ;; ;; First off, a previous call to invalidate-wrapper may have recorded ;; owrapper as an nwrapper to update to. Since owrapper is about to ;; be invalid, it no longer makes sense to update to it. ;; ;; We go back and change the previously invalidated wrappers so that ;; they will now update directly to nwrapper. This corresponds to a ;; kind of transitivity of wrapper updates. ;; (dolist (previous (gethash owrapper *previous-nwrappers*)) (when (eq state 'obsolete) ; obsolete must override flush (setf (car previous) 'obsolete)) (setf (cadr previous) nwrapper) (push previous new-previous)) (iterate ((type (list-elements wrapper-layout)) (i (interval :from 0))) (when (eq type 'number) (setf (wrapper-ref owrapper i) 0))) (push (setf (wrapper-state owrapper) (list state nwrapper)) new-previous) (setf (gethash owrapper *previous-nwrappers*) () (gethash nwrapper *previous-nwrappers*) new-previous))))) ----------------------------------------------- ;2. The code generated by add-pv-binding (called by defmethod) is not prepared to handle cache misses caused by invalid wrappers, but discriminating functions which call protect-cache-miss-code do not always call check-wrapper-validity. ;Test (defclass c1 () ()) (defclass c2 () ((b :initform 'two))) (defclass c3 (c2) ((a :initform 'one))) (defvar *list1*) (setq *list1* (list (make-instance 'c3) (make-instance 'c3))) (defvar *list2*) (setq *list2* (list (make-instance 'c3) (make-instance 'c3))) (defclass c3 (c1) ((a :initform 'one)))) (defclass c3 (c2) ((a :initform 'one))) (defmethod test-list ((v c3) &rest list) (if list (cons (slot-value v 'a) (apply #'test-list list)) (list (slot-value v 'a)))) (pcl::invalidate-discriminating-function #'test-list) (print (apply #'test-list *list1*)) ; => (TWO TWO) (print (apply #'test-list *list2*)) ; => (TWO TWO); (ONE TWO) if invalidate-wrapper is fixed - - - - - - - - - - - - ;methods.lisp (defmacro protect-cache-miss-code (gf args &body body) (let ((wrappers (gensym)) (invalidp (gensym)) (function (gensym)) (appl (gensym))) (once-only (gf args) `(if (memq ,gf *invalid-dfuns-on-stack*) (multiple-value-bind (,wrappers ,invalidp ,function ,appl) (cache-miss-values ,gf ,args) (declare (ignore ,wrappers ,invalidp)) (if (null ,appl) (no-applicable-method ,gf ,args) ; or maybe (apply #'no-applicable-method ,gf ,args) (apply ,function ,args))) (let ((*invalid-dfuns-on-stack* (cons ,gf *invalid-dfuns-on-stack*))) ,@body))))) ----------------------------------------------- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06205; Mon, 1 Oct 90 18:19:17 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16137>; Mon, 1 Oct 1990 18:08:16 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16208>; Mon, 1 Oct 1990 18:03:21 PDT Received: by spade.parc.xerox.com id <266>; Mon, 1 Oct 1990 18:02:54 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002B0A5 Date: Mon, 1 Oct 1990 18:02:46 PDT Sender: From: Gregor Kiczales Subject: patches to PCL To: CommonLoops.pa@arisia.Xerox.COM Reply-To: gregor@parc.xerox.com Message-Id: <90Oct1.180254pdt.266@spade.parc.xerox.com> In the past few months, a number of people have sent out patches to PCL. These fix a variety of bugs, so are really important, especially to new users. Unfortunately, with the notable exception of Doug Cutting's patch and some patches to support Genera 8.0, none of these has made it into the sources on arisia. The purpose of this message is to ask whether there is someone out there who would be willing to merge the patches back into the May Day REV 2 sources now on arisia. If someone would volunteer for this it would be great, especially for the new people who pick up the old sources and then end up complaining about the same bugs that have already been fixed. If you would be willing to do this, please send me a message. Thanks in advance. Gregor Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05049; Tue, 2 Oct 90 05:13:21 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16313>; Tue, 2 Oct 1990 05:13:08 PDT Received: from lanai.cs.ucla.edu ([131.179.128.13]) by alpha.xerox.com with SMTP id <16323>; Tue, 2 Oct 1990 05:10:10 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA12746; Tue, 2 Oct 90 05:05:16 -0700 X-Ns-Transport-Id: 08002008D0FD0002B310 Date: Tue, 2 Oct 1990 05:05:16 PDT From: Trent Lange Subject: Re: Compilation of methods per class. In-Reply-To: "Message of Mon, 1 Oct 1990 11:37:46 PDT from \"Gregor Kiczales \" <90Oct1.113746pdt.276@spade.parc.xerox.com>-col" To: Gregor Kiczales Cc: commonloops.parc@xerox.com Message-Id: <901002.120516z.12647.lange@lanai.cs.ucla.edu> >I am unable to reproduce quite the results you show. > >At the end of this message is some code which is largely based on your >example. It differs only in the timing macro used, and that it >automates (using PCL internal stuff) the process of restarting from >scratch to `fill the caches' in the other order. > >Using this data, I show that for 10000 calls to SLOW-FOO, the best time >(in seconds, on a SUN 4/330, in Lucid 3.0.1) is .13. Whatever variation >there is doesn't seem to be related to the order in which the `caches >are filled'. This, of course, ignores the first run of each test after >doing a reset to allow time for the caches to fill. > >Could you try this code, or look at this code, to see how it differs >with what you are measuring. > >Gregor The code measured exactly what I was measuring, except for one thing: >(defun test (x y) > (let ((i1 (make-instance 'class1)) > (i2 (make-instance 'class2))) > (setq y (/ y 2)) > (dotimes (i x) > (reset) > (dotimes (i y) (slow-foo i1) (slow-foo i2)) > (time (dotimes (i y) (slow-foo i1) (slow-foo i2))) > (time (dotimes (i y) (slow-foo i1) (slow-foo i2))) > (reset) > (dotimes (i y) (slow-foo i1) (slow-foo i2)) > (time (dotimes (i y) (slow-foo i2) (slow-foo i1))) > (time (dotimes (i y) (slow-foo i2) (slow-foo i1)))))) The 3rd to last line should be: (dotimes (i y) (slow-foo i2) (slow-foo i1)) Once I switched it to that (so that the cache is filled first with i2), my run on a Sun-4 in Lucid 3.0.1 showed the same problem I found earlier. The first two timings for 10,000 calls took a best of 0.13 seconds (like yours), but the last two took a best of 0.17 seconds. So unless there's something screwy with my May Day PCL, the run time in Lucid definitely seems to be dependent upon the order in which the caches are filled (and with generic functions having more than two specializations, sometimes quite adversely affected by that order). However, they don't seem to be dependent on cache-filling order in Allegro. Of course, I don't know what this tells us about the more important problem, that of the general generic-function call slowdown in Lucid when they are specialized on a number of different classes. - Trent Lange Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18804; Tue, 2 Oct 90 10:20:24 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16325>; Tue, 2 Oct 1990 10:20:08 PDT Received: from turing.cs.rpi.edu ([128.213.1.1]) by alpha.xerox.com with SMTP id <16295>; Tue, 2 Oct 1990 10:14:39 PDT Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA26626; Tue, 2 Oct 90 13:13:37 EDT X-Ns-Transport-Id: 08002008D0FD0002B534 Date: Tue, 2 Oct 1990 10:13:37 PDT From: harrisr@turing.cs.rpi.EDU (Richard Harris) Subject: May Day PCL with all the patches To: commonloops.parc@xerox.com Message-Id: <9010021713.AA26626@turing.cs.rpi.edu> The file may-day-pcl-rev-3.tar (available for anonymous ftp from turing.cs.rpi.edu, in the directory /pub/lisp) contains May Day PCL with (almost) all the patches that have been sent to this list. It contains a file (diff) which shows the differences between the PCL in arisia.xerox.com:/pcl/tarfile (the current version) and itself. If you have sent patches to May Day PCL to this list, please check to see that they have been incorporated. Richard Harris Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15559; Tue, 2 Oct 90 19:09:48 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16366>; Tue, 2 Oct 1990 18:59:29 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16389>; Tue, 2 Oct 1990 18:54:40 PDT Received: by spade.parc.xerox.com id <280>; Tue, 2 Oct 1990 18:46:57 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002BA15 Date: Tue, 2 Oct 1990 18:46:43 PDT Sender: From: Gregor Kiczales Subject: Re: Compilation of methods per class. In-Reply-To: "Trent Lange's message of Tue, 2 Oct 1990 05:05:16 PDT <901002.120516z.12647.lange@lanai.cs.ucla.edu>" To: lange@CS.UCLA.EDU Cc: commonloops.parc@xerox.com Message-Id: <90Oct2.184657pdt.280@spade.parc.xerox.com> Date: Tue, 2 Oct 1990 05:05:16 PDT From: Trent Lange Once I switched it to that (so that the cache is filled first with i2), my run on a Sun-4 in Lucid 3.0.1 showed the same problem I found earlier. The first two timings for 10,000 calls took a best of 0.13 seconds (like yours), but the last two took a best of 0.17 seconds. So unless there's something screwy with my May Day PCL, the run time in Lucid definitely seems to be dependent upon the order in which the caches are filled (and with generic functions having more than two specializations, sometimes quite adversely affected by that order). However, they don't seem to be dependent on cache-filling order in Allegro. Now, we may be getting somewhere. There is no doubt that in the Lucid port of PCL, cache operations are going to run slower than in the Franz port. So in your case, where filling the caches in the `other order' may affect the cache layout, and consequently affect the number of probes required, one might expect Lucid performance to suffer more than Franz. Similarly, in the case with methods on a number of classes, where more cache probes may also be required, we would expect Lucid performance to degrade faster than Franz. Let's look a little more carefully at what this means. The benchmarks in question measure the time it takes to do generic function call overhead. That is all they measure. That is why, when you produce a case where the overhead is greater (more cache probes are required) the numbers go up by what seem to be alarming percentages. But, what these numbers don't measure is the percentage of the total runtime of a real program which is going to generic function call overhead. That is, when you generate a case where the generic function call overhead goes up by 50%, we certainly don't expect the time your entire real program takes to run to go up by 50%. In fact, a 50% increase in generic function overhead is likely to likely to have a very small effect on total system performance. I don't have any hard data on this, but I believe JonL has some which he could share with us. Now, there are two important caveats to what I am saying: First, if generic function call overhead goes up by really large amounts (say greater than a factor of 3) it may start to become a serious issue in the performance of real programs. Second, there are certainly pathological programs, of which this benchmark is one, where 50% changes in the generic function call overhead will have close to 50% effect on the performance of the total program. Finally, it is important to point out that this difference in the performance of PCL in Lucid and Franz Lisp has nothing to do with the two Lisps. It shouldn't be taken as comment on the quality of either Lisp, or as an indication of the quality of each vendor's future CLOS products. For a variety of reasons, the Franz port of PCL has simply had more work done to it. In particular, the Franz port of PCL has a custom LAP code assembler. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04691; Wed, 3 Oct 90 10:49:04 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Wed 3 Oct 90 12:46:53-CDT Received: by charon.MIT.EDU id AA03312; Wed, 3 Oct 90 13:46:47 EDT Date: Wed, 3 Oct 90 13:46:47 EDT From: kab@CHARON.MIT.EDU (Kim A. Barrett) Message-Id: <9010031746.AA03312@charon.MIT.EDU> To: common-lisp-object-system@mcc.com Subject: specializer-direct-xxx generic functions The defacto list of CLOS symbol names includes the functions SPECIALIER-DIRECT-METHODS and SPECIALIZER-DIRECT-GENERIC-FUNCTIONS, which are described in the Metaobject Protocol as returning the obvious lists. It seems to me that there is a rather bad interaction between these and the special forms GENERIC-FLET and GENERIC-LABELS, since it seems to require that the mechanisms for computing the results for the SPECIALIZER-xxx functions are going to have to either be able to do a heap walk to search for the items to be returned (this seems just generally impractical) or maintain references to the appropriate objects. This would seem to violate possible DYNAMIC-EXTENT declarations on the local generic functions. It would also seem to be difficult to dereference the local functions so that they can be garbage collected. While I can certainly understand the desire to have these functions for purposes of introspection, its not clear to me that they are actually required for the implementation. I seem to remember that PCL at one time used CLASS-DIRECT-GENERIC-FUNCTIONS to find generic functions whose caches needed to be cleared due to a change in the class hierarchy. However, a recent paper by Gregor and Luis Rodriguez describes a technique for handling this update problem that don't use this mechanism (though I don't know if they've actually been implemented in PCL). Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09905; Wed, 3 Oct 90 12:15:15 -0700 Received: from sumex-aim.stanford.edu by MCC.COM with TCP/SMTP; Wed 3 Oct 90 14:06:22-CDT Received: from (MSOB-NetD-130.Stanford.EDU) by sumex-aim.stanford.edu (4.0/inc-1.0) id AA16768; Wed, 3 Oct 90 12:08:20 PDT Date: Wed, 3 Oct 1990 12:14:19 PDT From: Harold Lehmann Subject: MOP To: common-lisp-object-system@mcc.com Message-Id: Where could I find a copy of the Metaobject Protocol? Thanks, Harold ------- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06771; Wed, 3 Oct 90 21:10:59 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Wed 3 Oct 90 22:54:27-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16422>; Wed, 3 Oct 1990 20:54:53 PDT Received: by spade.parc.xerox.com id <276>; Wed, 3 Oct 1990 20:54:38 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: lehmann@sumex-aim.stanford.edu Cc: common-lisp-object-system@mcc.COM In-Reply-To: Harold Lehmann's message of Wed, 3 Oct 1990 12:14:19 PDT Subject: Re: MOP Line-Fold: NO Message-Id: <90Oct3.205438pdt.276@spade.parc.xerox.com> Date: Wed, 3 Oct 1990 20:54:25 PDT On arisia.xerox.com, in the /pcl/mop directory, there is a copy of the latest version of the MOP produced by PARC. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07210; Wed, 3 Oct 90 21:22:00 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Wed 3 Oct 90 23:00:54-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16423>; Wed, 3 Oct 1990 21:01:21 PDT Received: by spade.parc.xerox.com id <283>; Wed, 3 Oct 1990 21:01:08 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: kab@charon.MIT.EDU Cc: common-lisp-object-system@mcc.COM In-Reply-To: Kim A. Barrett's message of Wed, 3 Oct 1990 10:46:47 PDT <9010031746.AA03312@charon.MIT.EDU> Subject: Re: specializer-direct-xxx generic functions Line-Fold: NO Message-Id: <90Oct3.210108pdt.283@spade.parc.xerox.com> Date: Wed, 3 Oct 1990 21:01:06 PDT Mumble, the interaction between generic-flet/labels, the metaobject protocol, weak pointers and finalization is certainly one of the least well worked out parts of the Metaobject Protocol. Issues like these are going to need a lot of work in the next few years as we figure how to expand the MOP ideas. But I am not sure what you are proposing. SPECIALIZER-DIRECT-METHODS isn't in 88-002R as it is. Implementors who do MOP stuff can either put it in or not. Personally, I would do so, even if it meant not implementing generic-flet. Alternatively, I might do it by having the methods generated by generic-flet not get recorded. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02370; Thu, 4 Oct 90 08:01:22 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 4 Oct 90 09:47:59-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 854664; 4 Oct 1990 10:47:34-0400 Date: Thu, 4 Oct 1990 10:51-0400 From: David A. Moon Subject: Re: specializer-direct-xxx generic functions To: Gregor Kiczales Cc: kab@charon.MIT.EDU, common-lisp-object-system@mcc.COM In-Reply-To: <90Oct3.210108pdt.283@spade.parc.xerox.com> Message-Id: <19901004145147.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Thu, 4 Oct 1990 00:01 EDT From: Gregor Kiczales Mumble, the interaction between generic-flet/labels, the metaobject protocol, weak pointers and finalization is certainly one of the least well worked out parts of the Metaobject Protocol. Issues like these are going to need a lot of work in the next few years as we figure how to expand the MOP ideas. But I am not sure what you are proposing. SPECIALIZER-DIRECT-METHODS isn't in 88-002R as it is. Implementors who do MOP stuff can either put it in or not. Personally, I would do so, even if it meant not implementing generic-flet. Alternatively, I might do it by having the methods generated by generic-flet not get recorded. Another possibility that could be explored would be for generic-flet/-labels/-function to have two kinds of metaobjects: for want of a better name I'll call them template-generic-function/template-method, and closure-generic-function/closure-method. A generic-flet form would create the template metaobjects once when the form is processed, and would create a new set of closure metaobjects each time it is executed. The analogy is intended to be to compiled functions and closures of compiled functions. SPECIALIZER-DIRECT-METHODS then would return the template-methods. This way the set of objects to be returned by SPECIALIZER-DIRECT-METHODS would be poroprtional to the static size of the program rather than to the dynamic size of the program's execution. This is an old Scott Cyphers idea that has not been adequately worked out; I wouldn't guarantee that it will turn out to work, but it's a possibility. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03205; Thu, 4 Oct 90 08:19:13 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Thu 4 Oct 90 09:58:33-CDT Received: by charon.MIT.EDU id AA07480; Thu, 4 Oct 90 10:57:42 EDT Date: Thu, 4 Oct 90 10:57:42 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9010041457.AA07480@charon.MIT.EDU> To: gregor@parc.xerox.com Cc: common-lisp-object-system@mcc.COM In-Reply-To: Gregor Kiczales's message of Wed, 3 Oct 1990 21:01:06 PDT <90Oct3.210108pdt.283@spade.parc.xerox.com> Subject: specializer-direct-xxx generic functions > SPECIALIZER-DIRECT-METHODS isn't in 88-002R as it is. Implementors who do > MOP stuff can either put it in or not. Personally, I would do so, even if it > meant not implementing generic-flet. Alternatively, I might do it by having > the methods generated by generic-flet not get recorded. Not implementing generic-flet and friends is not really an option for most implementations without action from X3J13, and some members of the committee (specifically rpg) have stated a strong desire to keep them in. SPECIALIZER-DIRECT-METHODS was included in a list of names proposed as being part of a `defacto standard'. Including an unessential and very hard to implement feature in such a proposal is not likely to encourage it along the way towards general acceptance. If the generic-flet excluded semantics were adopted, applications which depended on the complete list semantics would fail, so it seems like a good idea to decide what is going on here early, before anyone has a chance to write themselves into a hole. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07486; Thu, 4 Oct 90 09:21:24 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 4 Oct 90 11:18:01-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 854711; 4 Oct 1990 12:17:44-0400 Date: Thu, 4 Oct 1990 12:21-0400 From: David A. Moon Subject: specializer-direct-xxx generic functions To: Kim A. Barrett Cc: gregor@parc.xerox.com, common-lisp-object-system@mcc.COM In-Reply-To: <9010041457.AA07480@charon.MIT.EDU> Message-Id: <19901004162157.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Thu, 4 Oct 1990 10:57 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Not implementing generic-flet and friends is not really an option for most implementations without action from X3J13 I wonder. Symbolics' implementation has been out there for almost a year if you count from the beta test, and half a year if you count from the release, and to my knowledge no customer has yet complained about the fact that generic-flet, generic-labels, and generic-function are not implemented. Maybe application developers have no use for these constructs at present. We'd like to implement them, but they were too low priority to make it into the first release, and the lack of feedback on this decision suggests that maybe they're too low priority to belong in the standard. Certainly other stuff like make-load-forms seems to be a much higher priority. SPECIALIZER-DIRECT-METHODS was included in a list of names proposed as being part of a `defacto standard'. Including an unessential and very hard to implement feature in such a proposal is not likely to encourage it along the way towards general acceptance. Well, note that that proposed `de facto standard' included the name, but did not include any specification of what the name meant. This was not an accident. If the generic-flet excluded semantics were adopted, applications which depended on the complete list semantics would fail, so it seems like a good idea to decide what is going on here early, before anyone has a chance to write themselves into a hole. Agreed. That's why it wasn't a proposed `de jure standard.' The intent was only that implementors who choose to implement these things should agree on the same names. It's a larger project to define the semantics. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11406; Thu, 4 Oct 90 10:35:15 -0700 Received: from alpha.xerox.com by MCC.COM with TCP/SMTP; Thu 4 Oct 90 12:26:48-CDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16184>; Thu, 4 Oct 1990 10:27:11 PDT Received: by spade.parc.xerox.com id <276>; Thu, 4 Oct 1990 10:26:59 PDT From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: kab@charon.MIT.EDU, common-lisp-object-system@mcc.COM In-Reply-To: 's message of Thu, 4 Oct 1990 07:51:00 PDT <19901004145147.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: specializer-direct-xxx generic functions Line-Fold: NO Message-Id: <90Oct4.102659pdt.276@spade.parc.xerox.com> Date: Thu, 4 Oct 1990 10:26:48 PDT From: Line-Fold: No Another possibility that could be explored would be for generic-flet/-labels/-function to have two kinds of metaobjects: for want of a better name I'll call them template-generic-function/template-method, and closure-generic-function/closure-method. A generic-flet form would create the template metaobjects once when the form is processed, and would create a new set of closure metaobjects each time it is executed. This seems like a promising way out of this problem. A way out needs to be found at some point since specializer-direct-methods is an important part of the MOP. I also concur with your comment that generic-flet/labels may not be that critical. In general, I don't think we designed those well, although I am not sure it would be possible to do them well in Common Lisp, it may be they can only be done well in Scheme. One symptom of their failing: we can create lexically scoped generic function definitions, but we can't create lexically-scoped class definitions. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29847; Thu, 4 Oct 90 16:26:47 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 4 Oct 90 18:19:00-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA03401g; Thu, 4 Oct 90 16:13:06 PDT Received: by caligula id AA13276g; Thu, 4 Oct 90 16:16:15 PDT Date: Thu, 4 Oct 90 16:16:15 PDT From: Jon L White Message-Id: <9010042316.AA13276@caligula> To: gregor@parc.xerox.com Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, kab@charon.MIT.EDU, common-lisp-object-system@mcc.COM In-Reply-To: Gregor Kiczales's message of Thu, 4 Oct 1990 10:26:48 PDT <90Oct4.102659pdt.276@spade.parc.xerox.com> Subject: specializer-direct-xxx generic functions re: One symptom of their failing: we can create lexically scoped generic function definitions, but we can't create lexically-scoped class definitions. Of course, this is not limited to CLASS definitions; a common thread of complaint form the Lucid user community is the inability to make lexically-scoped (and hence stack-allocated) defstruct definitions. And in a sense, the continual call for "stack-allocated" LISTs and ARRAYs begs for additional functionality in the language to express dynamic-extent data. As I recall, the presence of GFLET, GFLABELS, and GFUNCTION was pushed primarily to keep the analogy between "generic" functions and ordinary functions as close as possible; it was not pushed out of a sense of fanatical lexicalism. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10362; Fri, 5 Oct 90 08:34:49 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 5 Oct 90 10:23:39-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 855284; 5 Oct 1990 11:19:54-0400 Date: Fri, 5 Oct 1990 11:24-0400 From: David A. Moon Subject: specializer-direct-xxx generic functions To: Jon L White Cc: gregor@parc.xerox.com, kab@CHARON.MIT.EDU, common-lisp-object-system@mcc.COM In-Reply-To: <9010042316.AA13276@caligula> Message-Id: <19901005152416.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Thu, 4 Oct 1990 19:16 EDT From: Jon L White re: One symptom of their failing: we can create lexically scoped generic function definitions, but we can't create lexically-scoped class definitions. Of course, this is not limited to CLASS definitions; a common thread of complaint form the Lucid user community is the inability to make lexically-scoped (and hence stack-allocated) defstruct definitions. You mean defstruct instances, not defstruct definitions. And in a sense, the continual call for "stack-allocated" LISTs and ARRAYs begs for additional functionality in the language to express dynamic-extent data. Which X3J13 added not long ago in the form of the DYNAMIC-EXTENT declaration. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20410; Fri, 5 Oct 90 11:16:04 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Fri 5 Oct 90 12:55:29-CDT Received: by charon.MIT.EDU id AA13055; Fri, 5 Oct 90 13:55:12 EDT Date: Fri, 5 Oct 90 13:55:12 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9010051755.AA13055@charon.MIT.EDU> To: jonl@lucid.com Cc: gregor@parc.xerox.com, Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@mcc.COM In-Reply-To: Jon L White's message of Thu, 4 Oct 90 16:16:15 PDT <9010042316.AA13276@caligula> Subject: specializer-direct-xxx generic functions > {Gregor} > One symptom of their failing: we can create lexically scoped generic > function definitions, but we can't create lexically-scoped class > definitions. > {JonL} > Of course, this is not limited to CLASS definitions; a common thread of > complaint form the Lucid user community is the inability to make > lexically-scoped (and hence stack-allocated) defstruct definitions. I think you are confused about what Gregor was refering to. What you are talking about is handled by the DYNAMIC-EXTENT declaration. Gregor is talking about something like CLASS-LET (to use a name I've heard before for this construct) which is a lexical analog to DEFCLASS. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02618; Fri, 5 Oct 90 18:37:24 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 5 Oct 90 20:35:01-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA21373g; Fri, 5 Oct 90 18:28:45 PDT Received: by caligula id AA15482g; Fri, 5 Oct 90 18:31:56 PDT Date: Fri, 5 Oct 90 18:31:56 PDT From: Jon L White Message-Id: <9010060131.AA15482@caligula> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: gregor@parc.xerox.com, kab@CHARON.MIT.EDU, common-lisp-object-system@mcc.COM In-Reply-To: David A. Moon's message of Fri, 5 Oct 1990 11:24-0400 <19901005152416.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: specializer-direct-xxx generic functions Re: Of course, this is not limited to CLASS definitions; a common thread of complaint form the Lucid user community is the inability to make lexically-scoped (and hence stack-allocated) defstruct definitions. You mean defstruct instances, not defstruct definitions. A little Double-Dipping here. I mean lexically-scoped defstruct definitions, and stack-allocated defstruct instances. Not the same things at all. Looks like I squeezed too much into one line. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02941; Fri, 5 Oct 90 18:48:51 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 5 Oct 90 20:38:31-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA21440g; Fri, 5 Oct 90 18:32:33 PDT Received: by caligula id AA15494g; Fri, 5 Oct 90 18:35:43 PDT Date: Fri, 5 Oct 90 18:35:43 PDT From: Jon L White Message-Id: <9010060135.AA15494@caligula> To: kab@charon.MIT.EDU Cc: gregor@parc.xerox.com, Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@mcc.COM In-Reply-To: Kim A. Barrett's message of Fri, 5 Oct 90 13:55:12 EDT <9010051755.AA13055@charon.MIT.EDU> Subject: specializer-direct-xxx generic functions re: What you are talking about is handled by the DYNAMIC-EXTENT declaration. Not all of it! I was talking about both things; see previous reply to moon too. The only point I had hoped to make by throwing in the reference to stack allocation was that the drive for lexical scoping came from the *potential* for performance rather than from a sense of language purity. Oddly enough, lexical scoping for generic functions (and probably for classes too) seeems to be going in the wrong direction for performance. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25267; Wed, 10 Oct 90 15:53:52 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16224>; Wed, 10 Oct 1990 15:43:16 PDT Received: from turing.cs.rpi.edu ([128.213.1.1]) by alpha.xerox.com with SMTP id <16224>; Wed, 10 Oct 1990 15:40:16 PDT Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA18499; Wed, 10 Oct 90 18:39:13 EDT X-Ns-Transport-Id: 08002008D0FD0002FC06 Date: Wed, 10 Oct 1990 15:39:13 PDT From: harrisr@turing.cs.rpi.EDU (Richard Harris) Subject: Re: problems compiling may-day-pcl-rev-3 To: commonloops.PARC@Xerox.COM Message-Id: <9010102239.AA18499@turing.cs.rpi.edu> The current (October 10) version of turing.cs.rpi.edu:/pub/lisp/may-day-pcl-rev-3.tar fixes a bug which prevented fixup.lisp from compiling. Richard Harris Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01541; Wed, 10 Oct 90 21:19:11 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16261>; Wed, 10 Oct 1990 21:18:48 PDT Received: from spade.parc.xerox.com ([13.1.100.26]) by alpha.xerox.com with SMTP id <16261>; Wed, 10 Oct 1990 21:15:18 PDT Received: by spade.parc.xerox.com id <287>; Wed, 10 Oct 1990 21:15:04 PDT Fake-Sender: gregor@parc.xerox.com X-Ns-Transport-Id: 08002008D0FD0002FE66 Date: Wed, 10 Oct 1990 21:14:58 PDT Sender: From: Gregor Kiczales Subject: Re: problems compiling may-day-pcl-rev-3 In-Reply-To: "Richard Harris's message of Wed, 10 Oct 1990 15:39:13 PDT <9010102239.AA18499@turing.cs.rpi.edu>" To: harrisr@turing.cs.rpi.EDU Cc: commonloops.PARC@xerox.com Message-Id: <90Oct10.211504pdt.287@spade.parc.xerox.com> Date: Wed, 10 Oct 1990 15:39:13 PDT From: harrisr@turing.cs.rpi.EDU (Richard Harris) The current (October 10) version of turing.cs.rpi.edu:/pub/lisp/may-day-pcl-rev-3.tar fixes a bug which prevented fixup.lisp from compiling. Thanks for incorporating all these patches and making them available. I copied this file to the /pcl directory on arisia. That will make it easier for pcl users who may not have seen your message to find it. The file is called /pcl/tarfile-rev-3. Gregor Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05725; Thu, 11 Oct 90 04:59:44 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16270>; Thu, 11 Oct 1990 04:59:24 PDT Received: from research.att.com ([192.20.225.2]) by alpha.xerox.com with SMTP id <16270>; Thu, 11 Oct 1990 04:53:18 PDT Received: by research; Thu Oct 11 07:52:10 EDT 1990 X-Ns-Transport-Id: 08002008D0FD0003001B Date: Thu, 11 Oct 1990 04:52:05 PDT Sender: From: tk@allegra.tempo.nj.att.com (Thomas Kirk) Subject: Re: CALL FOR VOTES: comp.lang.clos In-Reply-To: "kiuchi@parc.xerox.com's message of 8 Oct 90 00:09:51 GMT" To: commonloops@arisia.Xerox.COM (Yasuhiko Kiuchi(SSL)) Message-Id: <90Oct11.045318pdt.16270@alpha.xerox.com> yes Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08814; Thu, 11 Oct 90 08:16:34 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16282>; Thu, 11 Oct 1990 08:16:14 PDT Received: from turing.cs.rpi.edu ([128.213.1.1]) by alpha.xerox.com with SMTP id <16285>; Thu, 11 Oct 1990 08:13:06 PDT Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA02747; Thu, 11 Oct 90 11:11:05 EDT X-Ns-Transport-Id: 08002008D0FD00030146 Date: Thu, 11 Oct 1990 08:11:05 PDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Subject: May Day PCL Rev 3 with ExCL on SUN4s To: commonloops.PARC@xerox.com Message-Id: <9010111511.AA02747@turing.cs.rpi.edu> If you are using May Day PCL Rev 3 with ExCL on SUN4s, you need to edit the file defsys.lisp, adding the line #+(and excl sun4) sun4-excl after the line (defvar *port* Richard Harris Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13522; Thu, 11 Oct 90 12:59:18 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16166>; Thu, 11 Oct 1990 12:58:39 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16155>; Thu, 11 Oct 1990 12:53:40 PDT Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1872; Thu, 11 Oct 90 15:51:26 EDT X-Original-To: commonloops.parc@xerox.com, BALL X-Ns-Transport-Id: 08002008D0FD0003047D Date: Thu, 11 Oct 1990 13:52:00 PDT Sender: From: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Subject: compiling pcl on MACL 1.3.1 To: commonloops.parc@xerox.com Message-Id: <90Oct11.125340pdt.16155@alpha.xerox.com> I attempted to compile pcl obtained from arisia "/pcl/tarfile-rev-3" on Macintosh Allegro Common Lisp 1.3.1. I get an error while compiling fin.lisp. ;Loading "Hard Disk:Lisp 1.3.1:May Day pcl:defsys.lisp"... Compiler warnings for function LOAD-TRUENAME : Unused lexical variable (#:G104) ? (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 CORAL-LOW... > Warning: FUNCTION PRINTING-RANDOM-THING-INTERNAL originally defined in: (CCL; May Day pcl:macros.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION SET-FUNCTION-NAME-1 originally defined in: (CCL;May Day pcl :low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION DOCTOR-DFUN-FOR-THE-DEBUGGER originally defined in: (CCL;Ma y Day pcl:low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE Compiling FIN... > Error: Undefined function: PRINT-UVECTOR-OBJECT . > While executing: CCL::%FUNCTION > Type Command-/ to continue, Command-. to abort. 1 > 1 > Aborted ? ;; Sheldon Ball Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16861; Thu, 11 Oct 90 16:10:03 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16205>; Thu, 11 Oct 1990 16:09:42 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16205>; Thu, 11 Oct 1990 16:07:54 PDT Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4435; Thu, 11 Oct 90 19:05:34 EDT X-Original-To: commonloops@parc.xerox.com, BALL X-Ns-Transport-Id: 08002008D0FD000306C6 Date: Thu, 11 Oct 1990 17:00:00 PDT Sender: From: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Subject: compiling pcl on MACL 1.3.1 To: commonloops@arisia.Xerox.COM Message-Id: <90Oct11.160754pdt.16205@alpha.xerox.com> I attempted to compile pcl obtained from arisia "/pcl/tarfile-rev-3" on Macintosh Allegro Common Lisp 1.3.1. I get an error while compiling fin.lisp. ;Loading "Hard Disk:Lisp 1.3.1:May Day pcl:defsys.lisp"... Compiler warnings for function LOAD-TRUENAME : Unused lexical variable (#:G104) ? (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 CORAL-LOW... > Warning: FUNCTION PRINTING-RANDOM-THING-INTERNAL originally defined in: (CCL; May Day pcl:macros.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION SET-FUNCTION-NAME-1 originally defined in: (CCL;May Day pcl :low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION DOCTOR-DFUN-FOR-THE-DEBUGGER originally defined in: (CCL;Ma y Day pcl:low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE Compiling FIN... > Error: Undefined function: PRINT-UVECTOR-OBJECT . > While executing: CCL::%FUNCTION > Type Command-/ to continue, Command-. to abort. 1 > 1 > Aborted ? ;; Sheldon Ball Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19620; Thu, 11 Oct 90 19:15:27 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16227>; Thu, 11 Oct 1990 19:15:07 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16227>; Thu, 11 Oct 1990 19:12:55 PDT Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 6264; Thu, 11 Oct 90 22:10:27 EDT X-Original-To: commonloops.parc@xerox.arpa, BALL X-Ns-Transport-Id: 08002008D0FD000307E2 Date: Thu, 11 Oct 1990 20:11:00 PDT Sender: From: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Subject: compiling pcl on MACL 1.3.1 To: commonloops.parc@xerox.com Message-Id: <90Oct11.191255pdt.16227@alpha.xerox.com> I attempted to compile pcl obtained from arisia "/pcl/tarfile-rev-3" on Macintosh Allegro Common Lisp 1.3.1. I get an error while compiling fin.lisp. ;Loading "Hard Disk:Lisp 1.3.1:May Day pcl:defsys.lisp"... Compiler warnings for function LOAD-TRUENAME : Unused lexical variable (#:G104) ? (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 CORAL-LOW... > Warning: FUNCTION PRINTING-RANDOM-THING-INTERNAL originally defined in: (CCL; May Day pcl:macros.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION SET-FUNCTION-NAME-1 originally defined in: (CCL;May Day pcl :low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE > Warning: FUNCTION DOCTOR-DFUN-FOR-THE-DEBUGGER originally defined in: (CCL;Ma y Day pcl:low.lisp) is now being redefined in: CCL;May Day pcl:coral-low.lisp > While executing: CCL::RECORD-SOURCE-FILE Compiling FIN... > Error: Undefined function: PRINT-UVECTOR-OBJECT . > While executing: CCL::%FUNCTION > Type Command-/ to continue, Command-. to abort. 1 > 1 > Aborted ? ;; Sheldon Ball Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26905; Fri, 12 Oct 90 05:43:48 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16254>; Fri, 12 Oct 1990 05:43:26 PDT Received: from inria.inria.fr ([128.93.8.1]) by alpha.xerox.com with SMTP id <16256>; Fri, 12 Oct 1990 05:40:49 PDT Received: from [192.44.65.45] by inria.inria.fr (5.64+/89.0.8) via Fnet-EUnet id AA24031; Fri, 12 Oct 90 13:16:58 +0100 (MET) Received: from orion.laas.fr by laas.laas.fr, Fri, 12 Oct 90 09:53:56 +0100 Received: by orion.laas.fr, Fri, 12 Oct 90 10:04:47 +0100 X-Ns-Transport-Id: 08002008D0FD00030A84 Date: Fri, 12 Oct 1990 02:04:47 PDT From: "Ralph P. Sobek" Subject: Re: problems compiling may-day-pcl-rev-3 In-Reply-To: <90Oct10.211504pdt.287@spade.parc.xerox.com> To: Gregor Kiczales Cc: commonloops.PARC@xerox.com Reply-To: ralph@vega.laas.fr Message-Id: <9010120904.AA18655@orion.laas.fr> Gregor Kiczales wrote: | | Thanks for incorporating all these patches and making them available. | | I copied this file to the /pcl directory on arisia. That will make it | easier for pcl users who may not have seen your message to find it. The | file is called /pcl/tarfile-rev-3. Is there the possibility to make a `diff' dile available for the differences between May Day Rev II and the new May Day Rev 3 pcl? I assume that the diffs would be reasonably small in comparison to the retrieval of /pcl/tarfile-rev-3 at arisia. It might even be of interest to mail them to this group, depending upon size. If all elese fails, could someone e-mail me such a `diff' file. Thanks, Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28681; Fri, 12 Oct 90 08:55:46 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16217>; Fri, 12 Oct 1990 08:55:32 PDT Received: from turing.cs.rpi.edu ([128.213.1.1]) by alpha.xerox.com with SMTP id <16260>; Fri, 12 Oct 1990 08:52:52 PDT Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA02663; Fri, 12 Oct 90 11:51:55 EDT X-Ns-Transport-Id: 08002008D0FD00030BCF Date: Fri, 12 Oct 1990 08:51:55 PDT From: harrisr@turing.cs.rpi.EDU (Richard Harris) Subject: differences between May Day Rev II and May Day Rev 3 To: ralph@vega.laas.fr Cc: commonloops.PARC@xerox.com, gregor@parc.xerox.com Message-Id: <9010121551.AA02663@turing.cs.rpi.edu> The file arisia.xerox.com:/pcl/rev-3-diff contains the differences between May Day Rev II and May Day Rev 3, that is the differences between /pcl/tarfile.old (5/2/90) and /pcl/tarfile-rev-3 (10/12/90). This file is 134182 bytes long. It is large because there were many patches for Genera. Richard Harris Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01407; Fri, 12 Oct 90 11:33:30 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16306>; Fri, 12 Oct 1990 11:32:57 PDT Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by alpha.xerox.com with SMTP id <16278>; Fri, 12 Oct 1990 10:25:15 PDT Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5476; Fri, 12 Oct 90 13:22:53 EDT X-Original-To: commonloops.parc@xerox.arpa, BALL X-Ns-Transport-Id: 08002008D0FD00030CAB Date: Fri, 12 Oct 1990 11:22:00 PDT Sender: From: BALL%YALEMED.BITNET@CUNYVM.CUNY.EDU Subject: patch for MACL To: commonloops.parc@xerox.com Message-Id: <90Oct12.102515pdt.16278@alpha.xerox.com> I don't know anything about Macintosh Allegro Common Lisp, but I have a suggestion. Try moving the definition of print-uvector-object in fin.lisp into the eval-when that follows, so that print-uvector-object will be defined at compile-time too. Richard Harris Thanks, this patch for fin.lisp on arisia in /pcl/tarfile-rev-3 seems toe-rev-3 seems toe-rev-3 l Lisp ;;; #+:coral (progn (defconstant ccl::$v_istruct 22) (defvar ccl::initial-fin-slots (make-list (length funcallable-instance-data))) (defconstant ccl::fin-function 1) (defconstant ccl::fin-data (+ ccl::FIN-function 1)) (defun allocate-funcallable-instance-1 () (apply #'ccl::%gvector ccl::$v_istruct 'ccl::funcallable-instance #'(lambda (&rest ignore) (declare (ignore ignore)) (called-fin-without-function)) ccl::initial-fin-slots)) ;;; Make uvector-based objects (like funcallable instances) print better. #+:ccl-1.3 ;;; Inform the print system about funcallable instance uvectors. #+:ccl-1.3 (eval-when (eval compile load) (defun print-uvector-object (obj stream &optional print-level) (declare (ignore print-level)) (print-object obj stream)) (pushnew (cons 'ccl::funcallable-instance #'print-uvector-object) ccl:*write-uvector-alist* :test #'equal)) (defun funcallable-instance-p (x) (and (eq (ccl::%type-of x) 'ccl::internal-structure) (eq (ccl::%uvref x 0) 'ccl::funcallable-instance))) (defun set-funcallable-instance-function (fin new-value) (unless (funcallable-instance-p fin) (error "~S is not a funcallable-instance." fin)) (unless (functionp new-value) (error "~S is not a function." new-value)) (ccl::%uvset fin ccl::FIN-function new-value)) (defmacro funcallable-instance-data-1 (fin data-name) `(ccl::%uvref ,fin (+ (funcallable-instance-data-position ,data-name) ccl::FIN-data))) (defsetf funcallable-instance-data-1 (fin data) (new-value) `(ccl::%uvset ,fin (+ (funcallable-instance-data-position ,data) ccl::FIN-data) ,new-value)) ); End of #+:coral Thanks again, Sheldon Ball Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11013; Tue, 16 Oct 90 13:01:06 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16582>; Tue, 16 Oct 1990 11:53:33 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16770>; Tue, 16 Oct 1990 11:27:45 PDT Received: from TRACER.ARMY.MIL by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00398; Tue, 16 Oct 90 11:15:55 -0700 Received: by tracer.army.mil (sendmail(4.12)/25-eef) id AA08942; Tue, 16 Oct 90 13:12:46 cdt X-Ns-Transport-Id: 08002008D0FD000325F3 Date: Tue, 16 Oct 1990 06:14:42 PDT Sender: From: markus%swg1.uucp@tracer.army.mil Subject: PCL/KEE problem To: commonloops.parc@tracer.uucp Message-Id: <9010161815.AA00398@arisia.Xerox.COM> Hello, I manage a network of Sun 4s that are being used to develop a simulation using PCL under Sun Common Lisp 4.0 (alpha release). We are currently using the Cinco de Mayo PCL(5/5/89). We have tried to compile the latest version (I ftp'd the tarfile last week) and get load errors in the BRAID1 module. Do you know of any fixes that can take care of this problem? If not, is there a place where I can get the 5/22/89 Victoria PCL which (as it's notes file says) is like the Cinco de Mayo release but "actually works". My developers are building their simulation in Intellicorp's KEE using PCL to get CLOS functionality. We have been trying to fix some problems and when we added some patches to the LISP, PCL broke. Any help would be GREATLY appreciated (sorry, can't give financial rewards...Congress has yet to decide to keep paying us). Mark E. Soderlund US Army Internet: markus@tracer.army.mil TRADOC Analysis Command - OAC Phone: (913)684-5135 (07:30-16:30 CST) ATRC-FTC (Building 391) Autovon: 552-5135 Fort Leavenworth, KS 66027-5210 Fax: (913)684-2344 or (913)684-3859 Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11013; Tue, 16 Oct 90 13:01:06 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16582>; Tue, 16 Oct 1990 11:53:33 PDT Received: from arisia.Xerox.COM ([13.1.100.206]) by alpha.xerox.com with SMTP id <16770>; Tue, 16 Oct 1990 11:27:45 PDT Received: from TRACER.ARMY.MIL by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00398; Tue, 16 Oct 90 11:15:55 -0700 Received: by tracer.army.mil (sendmail(4.12)/25-eef) id AA08942; Tue, 16 Oct 90 13:12:46 cdt X-Ns-Transport-Id: 08002008D0FD000325F3 Date: Tue, 16 Oct 1990 06:14:42 PDT Sender: From: markus%swg1.uucp@tracer.army.mil Subject: PCL/KEE problem To: commonloops.parc@tracer.uucp Message-Id: <9010161815.AA00398@arisia.Xerox.COM> Hello, I manage a network of Sun 4s that are being used to develop a simulation using PCL under Sun Common Lisp 4.0 (alpha release). We are currently using the Cinco de Mayo PCL(5/5/89). We have tried to compile the latest version (I ftp'd the tarfile last week) and get load errors in the BRAID1 module. Do you know of any fixes that can take care of this problem? If not, is there a place where I can get the 5/22/89 Victoria PCL which (as it's notes file says) is like the Cinco de Mayo release but "actually works". My developers are building their simulation in Intellicorp's KEE using PCL to get CLOS functionality. We have been trying to fix some problems and when we added some patches to the LISP, PCL broke. Any help would be GREATLY appreciated (sorry, can't give financial rewards...Congress has yet to decide to keep paying us). Mark E. Soderlund US Army Internet: markus@tracer.army.mil TRADOC Analysis Command - OAC Phone: (913)684-5135 (07:30-16:30 CST) ATRC-FTC (Building 391) Autovon: 552-5135 Fort Leavenworth, KS 66027-5210 Fax: (913)684-2344 or (913)684-3859 Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14620; Wed, 17 Oct 90 06:20:36 -0700 Message-Id: <9010171320.AA14620@arisia.Xerox.COM> Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 17 Oct 90 08:17:19-CDT Received: from tracer.army.mil by SAIL.Stanford.EDU with TCP; 17 Oct 90 05:59:31 PDT Received: by tracer.army.mil (sendmail(4.12)/25-eef) id AA23581; Wed, 17 Oct 90 07:59:11 cdt From: markus%swg1.uucp@tracer.army.mil To: common-lisp-object-system%tracer.uucp@sail.stanford.edu Subject: CLOS Availability Date: Wed Oct 17 08:00:42 1990 I manage a network of Sun 4's and Symbolics that are being used to design a simulation under KEE. The design team is presently using PCL to get OOPS functionality but have stated a desire to migrate to CLOS. Is CLOS available for the Symbolics Genera 7.2 and Sun Common Lisp 4 environments? If yes, has anyone used it along with Intellicorp's KEE 3.1? Mark E. Soderlund US Army Internet: markus@tracer.army.mil TRADOC Analysis Command - OAC Phone: (913)684-5135 (07:30-16:30 CST) ATRC-FTC (Building 391) Autovon: 552-5135 Fort Leavenworth, KS 66027-5210 Fax: (913)684-2344 or (913)684-3859 Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16088; Wed, 17 Oct 90 07:38:26 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 17 Oct 90 09:36:02-CDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Oct 90 07:33:48 PDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 860216; 17 Oct 1990 10:07:46-0400 Date: Wed, 17 Oct 1990 10:12-0400 From: David A. Moon Subject: CLOS Availability To: markus@tracer.army.mil Cc: common-lisp-object-system@sail.stanford.edu, CGay@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: The message of 17 Oct 1990 08:00 EDT from swg1!markus@tracer.army.mil Message-Id: <19901017141222.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Wed, 17 Oct 1990 08:00 EDT From: swg1!markus@tracer.army.mil Is CLOS available for the Symbolics Genera 7.2 and Sun Common Lisp 4 environments? CLOS is included in Symbolics Genera 8.0 and later releases, and Symbolics Cloe 3.0 and later releases. CLOS will not run in earlier releases. (I'm not the source for Sun information.) If yes, has anyone used it along with Intellicorp's KEE 3.1? CLOS and KEE coexist okay in the same Lisp world. I haven't heard anything about anyone using them together, I don't know what would be involved in that. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20677; Wed, 17 Oct 90 10:56:27 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Wed 17 Oct 90 12:53:39-CDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA23527g; Wed, 17 Oct 90 10:47:19 PDT Received: by caligula id AA03064g; Wed, 17 Oct 90 10:50:54 PDT Date: Wed, 17 Oct 90 10:50:54 PDT From: Jon L White Message-Id: <9010171750.AA03064@caligula> To: markus@tracer.army.mil Cc: commonloops.pa@xerox.com, common-lisp-object-system@mcc.com In-Reply-To: markus%swg1.uucp@tracer.army.mil's message of Tue, 16 Oct 1990 06:14:42 PDT <9010161815.AA00398@arisia.Xerox.COM> Subject: CLOS Availability and PCL/KEE problem CLOS is included in the Sun Common Lisp 4.0 release; it will not work in prior releases. Last I heard, product delivery by Sun of the 4.0 release is scheduled before the end of this month; but talk to a Sun representative to be sure. I know that you can have all of FLAVORS, PCL, and CLOS running in the same Sun 4.0 image; but I don't know for sure about KEE coexisting with any of these systems. Lucid, Inc. is the supplier to Sun of Sun Common Lisp; the same CLOS will be available in all the other platforms that Lucid supports, but only in the 4.0 releases and later. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20710; Wed, 17 Oct 90 10:58:58 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16179>; Wed, 17 Oct 1990 10:58:31 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16138>; Wed, 17 Oct 1990 10:54:17 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA23527g; Wed, 17 Oct 90 10:47:19 PDT Received: by caligula id AA03064g; Wed, 17 Oct 90 10:50:54 PDT X-Ns-Transport-Id: 08002008D0FD00032F8D Date: Wed, 17 Oct 1990 10:50:54 PDT From: Jon L White Subject: CLOS Availability and PCL/KEE problem In-Reply-To: "markus%swg1.uucp@tracer.army.mil's message of Tue, 16 Oct 1990 06:14:42 PDT <9010161815.AA00398@arisia.Xerox.COM>" To: markus@tracer.army.MIL Cc: commonloops.parc@xerox.com, common-lisp-object-system@mcc.COM Message-Id: <9010171750.AA03064@caligula> CLOS is included in the Sun Common Lisp 4.0 release; it will not work in prior releases. Last I heard, product delivery by Sun of the 4.0 release is scheduled before the end of this month; but talk to a Sun representative to be sure. I know that you can have all of FLAVORS, PCL, and CLOS running in the same Sun 4.0 image; but I don't know for sure about KEE coexisting with any of these systems. Lucid, Inc. is the supplier to Sun of Sun Common Lisp; the same CLOS will be available in all the other platforms that Lucid supports, but only in the 4.0 releases and later. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26268; Wed, 17 Oct 90 14:39:35 -0700 Received: from p.Lanl.GOV by MCC.COM with TCP/SMTP; Wed 17 Oct 90 16:36:22-CDT Received: from zaphod.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA04066; Wed, 17 Oct 90 15:35:48 -0600 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA00274; Wed, 17 Oct 90 15:36:02 MDT Date: Wed, 17 Oct 90 15:36:02 MDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Message-Id: <9010172136.AA00274@zaphod.lanl.gov.lanl.gov> To: jonl@lucid.com Cc: markus@tracer.army.mil, commonloops.parc@xerox.com, common-lisp-object-system@mcc.com In-Reply-To: Jon L White's message of Wed, 17 Oct 1990 10:50:54 PDT <9010171750.AA03064@caligula> Subject: RE: CLOS Availability and PCL/KEE problem > From: Jon L White > > CLOS is included in the Sun Common Lisp 4.0 release; ... > > I know that you can have all of FLAVORS, PCL, and CLOS running in the > same Sun 4.0 image; but I don't know for sure about KEE coexisting with > any of these systems. Intellicorp, in its wisdom, has been DELIVERING KEE on an ALPHA release of Sun Common Lisp 4.0 for SPARC platforms. This version (called 4.0a3) has a compiler bug which prevents PCL from being compiled and does not have an internal version of CLOS. As a stopgap, as an interesting excercise, as a bridge for those migrating from KEE's O-O stuff to CLOS, and for several other reasons, I have a very reasonable subset of CLOS that is implemented as a syntactic front-end to KEE's unit creation and method invocation stuff. In principle, one writes code with CLOS and the classes, instances, and generic functions are constructed from KEE units and methods. I have used the system for a reasonable project with enough success that I intend this to be my standard KEE programming interface from this point on. A description of the package has been presented at the small, but always interesting, AI in DOE conference. Either the paper or the system are available to anyone who wants them. Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26248; Wed, 17 Oct 90 14:38:53 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16306>; Wed, 17 Oct 1990 14:38:33 PDT Received: from p.Lanl.GOV ([128.165.4.4]) by alpha.xerox.com with SMTP id <16308>; Wed, 17 Oct 1990 14:37:21 PDT Received: from zaphod.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA04066; Wed, 17 Oct 90 15:35:48 -0600 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA00274; Wed, 17 Oct 90 15:36:02 MDT X-Ns-Transport-Id: 08002008D0FD000331E1 Date: Wed, 17 Oct 1990 14:36:02 PDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Subject: RE: CLOS Availability and PCL/KEE problem In-Reply-To: "Jon L White's message of Wed, 17 Oct 1990 10:50:54 PDT <9010171750.AA03064@caligula>" To: jonl@lucid.COM Cc: markus@tracer.army.MIL, commonloops.parc@xerox.com, common-lisp-object-system@mcc.COM Message-Id: <9010172136.AA00274@zaphod.lanl.gov.lanl.gov> > From: Jon L White > > CLOS is included in the Sun Common Lisp 4.0 release; ... > > I know that you can have all of FLAVORS, PCL, and CLOS running in the > same Sun 4.0 image; but I don't know for sure about KEE coexisting with > any of these systems. Intellicorp, in its wisdom, has been DELIVERING KEE on an ALPHA release of Sun Common Lisp 4.0 for SPARC platforms. This version (called 4.0a3) has a compiler bug which prevents PCL from being compiled and does not have an internal version of CLOS. As a stopgap, as an interesting excercise, as a bridge for those migrating from KEE's O-O stuff to CLOS, and for several other reasons, I have a very reasonable subset of CLOS that is implemented as a syntactic front-end to KEE's unit creation and method invocation stuff. In principle, one writes code with CLOS and the classes, instances, and generic functions are constructed from KEE units and methods. I have used the system for a reasonable project with enough success that I intend this to be my standard KEE programming interface from this point on. A description of the package has been presented at the small, but always interesting, AI in DOE conference. Either the paper or the system are available to anyone who wants them. Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27139; Wed, 17 Oct 90 15:09:06 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16314>; Wed, 17 Oct 1990 15:08:49 PDT Received: from nettlesome.berkeley.edu ([128.32.136.38]) by alpha.xerox.com with SMTP id <16297>; Wed, 17 Oct 1990 15:07:33 PDT Received: from elmer-fudd.Berkeley.EDU by nettlesome.berkeley.edu (5.64/1.34) id AA10040; Wed, 17 Oct 90 14:43:36 -0700 Received: by elmer-fudd.berkeley.edu. (4.0/SMI-4.0) id AA04218; Wed, 17 Oct 90 15:06:01 PDT Illegal-Object: Syntax error in Message-Id: value found on alpha.xerox.com: Message-Id: <9010172206.AA04218@elmer-fudd.berkeley.edu.> ^-illegal subdomain in domain X-Ns-Transport-Id: 08002008D0FD0003322B Date: Wed, 17 Oct 1990 15:06:01 PDT From: konstan@elmer-fudd.berkeley.EDU (Joe Konstan) Subject: Readers, methods, and congruent lambda lists To: commonloops.parc@xerox.com Message-Id: <90Oct17.150733pdt.16297@alpha.xerox.com> I recall this being discussed before on this list, but am afraid I don't remember the outcome. Here is the problem: I would like to define methods that take keywords and that have the same name as slot-readers: For instance: (defclass foo () ((a-slot :reader width))) (defmethod width ((Self string) &key (font nil) &allow-other-keys (get-string-width self font)) This results in an error based on incongurent lambda lists: Error: the method and generic function differ in whether they accept rest or keyword arguments. I've tried different forms of defgeneric, and still seem unable to resolve this. I see three possibilities: 1. There is a way to handle this that I an unaware of (i.e. telling the reader to allow other keys). 2. I should abandon the :reader definition and instead define a reader method by hand using slot-value (do I lose the added efficiency a reader method can have?). 3. I should give up on the idea of keeping the names the same and rename one or the other. Ideas? Joe Konstan konstan@postgres.Berkeley.edu Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05492; Wed, 17 Oct 90 20:43:50 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16499>; Wed, 17 Oct 1990 20:43:23 PDT Received: from lucid.com ([192.31.212.72]) by alpha.xerox.com with SMTP id <16444>; Wed, 17 Oct 1990 20:30:05 PDT Received: from caligula (caligula.lucid.com) by heavens-gate.lucid.com id AA26667g; Wed, 17 Oct 90 19:43:01 PDT Received: by caligula id AA03864g; Wed, 17 Oct 90 19:46:39 PDT X-Ns-Transport-Id: 08002008D0FD000334EC Date: Wed, 17 Oct 1990 19:46:39 PDT From: Jon L White Subject: Readers, methods, and congruent lambda lists In-Reply-To: "Joe Konstan's message of Wed, 17 Oct 1990 15:06:01 PDT <90Oct17.150733pdt.16297@alpha.xerox.com>" To: konstan@elmer-fudd.berkeley.EDU Cc: commonloops.parc@xerox.com Message-Id: <9010180246.AA03864@caligula> re: I would like to define methods that take keywords and that have the same name as slot-readers: For instance: . . . This results in an error based on incongurent lambda lists: Yup, you can't do that in CLOS. Methods for a named generic function seem to allow overloading of the name for that function, but you can't do just any old overloading; in particular, the lambda-list congruency issue will intrude. There is discussion galore in the archives on this issue, if you care to read through it. Although it probably won't be quite as efficient as using the automated reader methods, many implementations of CLOS that I'm familiar with will do some sort of optimization of SLOT-VALUE in the limited context presented by writing your own reader method. E.g., (defmethod snoop-around ((x big-room) &key constraints) . . . a random method body . . . ) (defmethod snoop-around ((x duplex) &rest ignore) ;; a user-written pseudo reader method. (declare (ignore ignore)) (slot-value x 'basement)) This latter method will probably be relatively speedy; it may be twice as slow the super-optimized :reader methods, but it won't be 10 to 100 times as slow, which is what an unoptimzed call to SLOT-VALUE could be. On the other hand, many folks who might have to read your source code would probably find it easier to do so if you took your third solution. -- JonL -- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17847; Thu, 25 Oct 90 13:04:07 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16476>; Thu, 25 Oct 1990 12:53:30 PDT Received: from inria.inria.fr ([128.93.8.1]) by alpha.xerox.com with SMTP id <16457>; Thu, 25 Oct 1990 12:43:34 PDT Received: from litp.ibp.fr by inria.inria.fr (5.64+/90.0.9) via Fnet-EUnet id AA28019; Thu, 25 Oct 90 19:10:01 +0100 (MET) Received: from zeta.ibp.fr by litp.ibp.fr with SMTP (5.61++/IDA-1.2.8) id AA23617; Thu, 25 Oct 90 19:06:50 +0100 Received: by zeta.ibp.fr (4.0/SMI-4.0) id AA00315; Thu, 25 Oct 90 19:08:21 +0100 Organization: Universite Pierre et Marie Curie Paris VI - LITP Aile 45-55 - Piece 205 - Equipe CLIP 4 Place Jussieu, F-75252 PARIS CEDEX 05 voice : +33 (1) 44-27-40-55 fax : +33 (1) 44-27-62-86 X-Ns-Transport-Id: 08002008D0FD00037A0F Date: Thu, 25 Oct 1990 11:08:20 PDT From: fxtv@zeta.ibp.FR (Francois-Xavier TESTARD-VAILLANT) Subject: Initialize-instance and Franz To: Gregor Kiczales Cc: commonloops.PARC@xerox.com, bsmith@postgres.Berkeley.EDU Message-Id: <9010251808.AA00315@zeta.ibp.fr> Here is a short session of Picasso (Allegro+clx+pcl+picasso). It seems that this works with lucid but not there. Why? Francois-Xavier ---- (defclass foo () ((bar :reader get-bar :writer set-bar))) NIL (defmethod initialize-instance :after ((self foo) &rest args) (format T "Initializing foo...~%")) NIL (make-instance 'foo) ---- ;using lucid 3.0 + pcl > (defclass foo () ((bar :reader get-bar :writer set-bar))) # > (defmethod initialize-instance :after ((self foo) &rest args) (format T "Initializing foo...~%")) # > (make-instance 'foo) Initializing foo... # > Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21494; Thu, 25 Oct 90 15:36:54 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16442>; Thu, 25 Oct 1990 15:36:34 PDT Received: from postgres.Berkeley.EDU ([128.32.149.1]) by alpha.xerox.com with SMTP id <16448>; Thu, 25 Oct 1990 15:33:23 PDT Received: by postgres.Berkeley.EDU (5.61/1.29) id AA04665; Thu, 25 Oct 90 15:28:21 -0700 X-Ns-Transport-Id: 08002008D0FD00037C57 Date: Thu, 25 Oct 1990 15:28:21 PDT From: bsmith@postgres.Berkeley.EDU (Brian Smith) Subject: Re: Initialize-instance and Franz In-Reply-To: "Mail from 'fxtv@zeta.ibp.FR (Francois-Xavier TESTARD-VAILLANT)' dated Thu, 25 Oct 1990 11:08:20 PDT" To: fxtv@zeta.ibp.FR, gregor@parc.xerox.com Cc: commonloops.PARC@xerox.com Message-Id: <9010252228.AA04665@postgres.Berkeley.EDU> Regarding Francois-Xavier's message of Oct 25: From fxtv@zeta.ibp.FR Thu Oct 25 14:28:25 1990 Subject: Initialize-instance and Franz To: Gregor Kiczales Cc: commonloops.PARC@xerox.com, bsmith@postgres.Berkeley.EDU Here is a short session of Picasso (Allegro+clx+pcl+picasso). It seems that this works with lucid but not there. Why? Francois-Xavier ---- (defclass foo () ((bar :reader get-bar :writer set-bar))) NIL (defmethod initialize-instance :after ((self foo) &rest args) (format T "Initializing foo...~%")) NIL (make-instance 'foo) ---- ;using lucid 3.0 + pcl > (defclass foo () ((bar :reader get-bar :writer set-bar))) # > (defmethod initialize-instance :after ((self foo) &rest args) (format T "Initializing foo...~%")) # > (make-instance 'foo) Initializing foo... # > ====================================================================== The problem is that picasso is based on the 12/88 pcl, which doesn't use the CLOS initialization protocol. Hence, initialize-instance :after method is never called. Francois -- I'll mail you a seperate message how to get around this problem. It'll be fixed in the next version of picasso, which will use the newest pcl. ----- Brian C. Smith arpa: bsmith@postgres.Berkeley.EDU University of California, Berkeley uucp: uunet!ucbarpa!postgres!bsmith Computer Sciences Department phone: (415)642-9585 Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00545; Fri, 26 Oct 90 02:20:40 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16451>; Fri, 26 Oct 1990 02:20:16 PDT Received: from rimfaxe.diku.dk ([129.142.96.49]) by alpha.xerox.com with SMTP id <16451>; Fri, 26 Oct 1990 02:17:57 PDT Received: by rimfaxe.diku.dk (5.61++/IDA-1.2.8) id AA21115; Fri, 26 Oct 90 10:16:38 +0100 X-Ns-Transport-Id: 08002008D0FD00038105 Date: Fri, 26 Oct 1990 02:16:38 PDT Sender: jank@rimfaxe.diku.DK From: Jan K|lander Subject: comp.lang.clos NetNews Grops To: commonloops.PARC@xerox.com Message-Id: <9010260916.AA21115@rimfaxe.diku.dk> My vote is YES. --Jan Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06302; Fri, 26 Oct 90 09:04:31 -0700 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16465>; Fri, 26 Oct 1990 09:04:01 PDT Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <16484>; Fri, 26 Oct 1990 09:02:11 PDT Received: by atc.boeing.com on Fri, 26 Oct 90 09:01:11 PDT X-Ns-Transport-Id: 08002008D0FD0003835C Date: Fri, 26 Oct 1990 09:02:00 PDT From: Stephen L Nicoud Subject: Inspecting PCL objects in Franz. To: commonloops.PARC@xerox.com, allegro-cl@berkeley.EDU, bugs@franz.com Message-Id: <19901026160256.3.SNICOUD@SKAGIT.atc.boeing.com> I can't inspect PCL objects in Franz Allegro CL. I've searched the PCL mail archives and didn't see anything related to the inability to inspect PCL objects in Franz Allegro CL. Allegro CL: 3.1.13 PCL: Victoria Day (the default PCL supplied with Allegro CL 3.1.13) Sun 3/60 (defclass ship () (a b)) NIL (setq b (make-instance 'ship)) # (inspect b) Error: Illegal vector object passed to svref: NIL :zo Evaluation stack: ->(ERROR "Illegal vector object passed to svref: ~s" NIL) (SVREF NIL 3) (INSPECT::INSPECT-CTL #) (INSPECT::INSPECT-PUSH # "(inspect ...)") (INSPECT #) (EVAL (INSPECT B)) ... more older frames ... *features* = (:ERASMUS-SUN :ERASMUS :EW :EW-GOODWILL :X :DEFPACKAGE :EW-CLOS :PCL-VICTORIA :BFS :BECL :SUNOS4 :SUNOS4.1 :COMPOSER :FAKE-ACTIVE-REGIONS :BIG-ENDIAN :GSGC :M68881 :M68020 :ALLEGRO-V3.1 :FRANZ-INC :EXCL :ALLEGRO :COMMON-LISP :CONFORMING-IEEE :IEEE :FLAVORS :SUNOS4.0 :SUN :M68K :SUN3 :UNIX :CLOS :PCL :MULTIPROCESSING :CLX :XLIB :CLX-MIT-R4 :CLX-CL-ERROR LOOP :LOOP :HAS-RCSNOTE :METACOURIER :METACOURIER-1-2 :METAC-1-2 :METAC :CW-X) Stephen Nicoud Boeing Advanced Technology Center for the Computer Sciences Bellevue, WA snicoud@atc.boeing.com Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00650; Fri, 26 Oct 90 12:08:46 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16471>; Fri, 26 Oct 1990 12:08:23 PDT Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <16492>; Fri, 26 Oct 1990 11:59:51 PDT Received: by atc.boeing.com on Fri, 26 Oct 90 11:58:43 PDT X-Ns-Transport-Id: 08002008D0FD000385F0 Date: Fri, 26 Oct 1990 12:00:00 PDT From: Stephen L Nicoud Subject: Inspecting PCL objects in Franz. In-Reply-To: <9010261852.AA02716@aspen.ciam.serc.mmm.com> To: John Collins Cc: snicoud@atc.boeing.COM, allegro-cl@ucbvax.Berkeley.EDU, commonloops.PARC@xerox.com, bugs@franz.com Message-Id: <19901026190027.2.SNICOUD@SKAGIT.atc.boeing.com> Date: Fri, 26 Oct 90 13:52:47 CDT From: collins@aspen.serc.3m.com (John Collins) I tried the same example, and here is the result: (defclass ship () (a b)) # (setq b (make-instance 'ship)) # (inspect b) SHIP instance @ #xf9eb6e = # 0 Class --------> PCL::STANDARD-CLASS instance = .long item. 1 A ------------> The symbol :|Unbound Slot| 2 B ------------> The symbol :|Unbound Slot| [1] :pop My configuration is LISP-IMPLEMENTATION-TYPE: Allegro CL LISP-IMPLEMENTATION-VERSION: 3.1.13 [Sun4] (4/24/90) ... Allegro Composer: Composer Final 1.0.17.2 (4/19/90 17:15) ... pcl::*pcl-system-date* : "5/22/89 Victoria Day PCL" Either there is something different about the way PCL is configured for Composer, or you must not have something set up correctly. The Composer window inspector also works. John Collins Your right about something in my lisp not being setup correctly. I tried what you did in a fresh image and got the same results. I'll have to fish around some more. Thanks, Steve Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03478; Fri, 26 Oct 90 14:06:51 -0700 Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <16484>; Fri, 26 Oct 1990 14:06:33 PDT Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16484>; Fri, 26 Oct 1990 14:01:49 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA08396; Fri, 26 Oct 90 16:19:09 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA27320; Fri, 26 Oct 90 12:51:41 PDT Received: by fiona.Franz.COM (4.0/FI-1.0) id AA17774; Fri, 26 Oct 90 12:50:12 PDT Bh: append spr2142 X-Ns-Transport-Id: 08002008D0FD000387BA Date: Fri, 26 Oct 1990 12:50:12 PDT From: smh@franz.com (Steve Haflich) Subject: Re: [spr2142] Inspecting PCL objects in Franz. To: snicoud@atc.boeing.COM Cc: bugs@franz.com, allegro-cl@ucbvax.Berkeley.EDU, commonloops.PARC@xerox.com Message-Id: <9010261950.AA17774@fiona.Franz.COM> [This question has been assigned the tracking identifier "spr2142". Please refer to it in any followup communication.] The inspector knows about pcl objects, so perhaps something is corrupted in your image. Here is my duplication of your test, plus some extra forms to show where the inspector obtains its handler for pcl instances: Allegro CL 3.1.13 [Sun3] (4/24/90) Copyright (C) 1985-1990, Franz Inc., Berkeley, CA, USA (require :pcl) ; Fast loading /fiona/cl2/lib/sun3/3.1.13/lib/code/pcl.fasl. T (use-package :pcl) T (defclass ship () (a b)) NIL (setq b (make-instance 'ship)) # (inspect b) ; Fast loading /fiona/cl2/lib/sun3/3.1.13/lib/code/inspect.fasl. SHIP instance @ #xb3bec1 = # 0 Class --------> PCL::STANDARD-CLASS instance = .long item. 1 A ------------> The symbol :|Unbound Slot| 2 B ------------> The symbol :|Unbound Slot| [1] (type-of b) PCL::IWMC-CLASS [1] (describe 'pcl::iwmc-class) PCL::IWMC-CLASS is a SYMBOL It is unbound It is INTERNAL in the PCL package Its property list has these indicator/value pairs: :WINSPECTOR-FUNCTION # :INSPECTOR-TYPE-FUNCTION # :INSPECTOR-FUNCTION # EXCL::%STRUCTURE-DEFINITION # [1] The interface between the inspector and pcl is in the file pcl/excl-low, so you should have the source to examine. If you need any more help figuring this out let bugs@franz.com know. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03794; Fri, 26 Oct 90 14:17:50 -0700 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16473>; Fri, 26 Oct 1990 14:17:23 PDT Received: from TAMU.EDU ([128.194.15.2]) by alpha.xerox.com with SMTP id <16488>; Fri, 26 Oct 1990 14:11:01 PDT Received: from snaefell.tamu.edu.tamu.edu (SNAEFELL.TAMU.EDU) by TAMU.EDU (AA12345); Fri, 26 Oct 90 16:06:32 CDT Received: by snaefell.tamu.edu.tamu.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA01176; Fri, 26 Oct 90 16:09:50 CDT X-Ns-Transport-Id: 08002008D0FD000387E9 Date: Fri, 26 Oct 1990 14:09:50 PDT From: colin@snaefell.tamu.EDU (Colin Allen) Subject: compiling pcl with kcl and an amdahl 5860 To: commonloops.PARC@xerox.com Message-Id: <9010262109.AA01176@snaefell.tamu.edu.tamu.edu> Does anyone have experience (or suggestions) on compiling pcl with kyoto common lisp on an amdahl 5860 running uts/unix? I have been looking at the kcl patches and there are some hardware specific changes intended for kcl/main.c but I do not know where I should put them. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11380; Mon, 29 Oct 90 17:09:17 -0800 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16155>; Mon, 29 Oct 1990 17:08:58 PST Received: from arcadia.Berkeley.EDU ([128.32.149.48]) by alpha.xerox.com with SMTP id <16175>; Mon, 29 Oct 1990 17:06:14 PST Received: by arcadia.Berkeley.EDU (5.61/1.29) id AA04282; Mon, 29 Oct 90 17:02:25 -0800 X-Ns-Transport-Id: 08002008D0FD00039C6E Date: Mon, 29 Oct 1990 17:02:25 PST From: chungl@postgres.Berkeley.EDU (Chung Liu) Subject: pcl::precompile-random-code-segments To: commonloops.parc@xerox.com Message-Id: <9010300102.AA04282@arcadia.Berkeley.EDU> In notes.text of the May Day PCL, it says: > * You probably also want to begin using a precom file for your system. > Do this by having a file whose only contents is > > (pcl::precompile-random-code-segments ) > > don't quote > > for example, for the clim system, the precom file has the one line: > > (pcl::precompile-random-code-segments clim) > > compile this file after loading and running your system for a while. > load it before loading and running your system for a while. > load it before loading your compiled system. A future version of this > feature won't require you to have run your system for a while, it will > only require that you have loaded it. Could someone explain to me what this precom file does? I couldn't quite understand it from the notes. Does it improve the performance of PCL? Also, what does "loading and running your system for a while" mean? Thanks in advance. Chung Liu (chungl@postgres.berkeley.edu) Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09187; Thu, 1 Nov 90 20:09:47 -0800 Received: from Dispatch.Parc.Xerox.xns by alpha.xerox.com via XNS id <16429>; Thu, 1 Nov 1990 20:08:23 PST X-Ns-Transport-Id: 0000AA0089EAAF652AF0 Date: Thu, 1 Nov 1990 20:07:00 PST From: Yasuhiko_Kiuchi.PARC@xerox.com Subject: VOTING RESULT: comp.lang.clos To: CommonLoops.PARC@xerox.com Cc: kiuchi.pa@xerox.com, gregor@parc.xerox.com Message-Id: <90Nov1.200823pst.16429@alpha.xerox.com> This message is result of the vote to create the newsgroup comp.lang.clos. This will be posted and sent to news.announce.newgroups, comp.lang.lisp and comp.object USENET newsgroup and CommonLoops mailing-list. ---------- The voting for comp.lang.clos is over. The results are: YES: 146 NO: 9 The proposal to create the newsgroup passed. We will send a control message to create the group comp.lang.clos after the waiting period. This newsgroup will be gatewayed to the CLOS mailing-list. The detail of the gateway and mailing-list will be posted to the new group and current CommonLoops.parc@Xerox.com mailing-list. The voting list follows: YES Votes: --------- anderson@sapir.COG.JHU.EDU (Stephen R. Anderson) leavens@bambam.cs.iastate.edu (Gary Leavens) silbar%dac@LANL.GOV (Dick Silbar) liew@cs.rutgers.edu David Gadbois emv@math.lsa.umich.edu (Edward Vielmetti) hws@icsib1.berkeley.edu (Heinz Schmidt) Michael Greenwald Brian Hayes - Sigma Xi Peter Benson yg80 (Peter Chalmers) fritzson@PRC.Unisys.com mandel@frodo.forwiss.uni-passau.de (Luis Mandel) px%fctunl.rccn.pt@CUNYVM.CUNY.EDU (Joaquim Baptista [pxQuim]) "Mark R. Adler -- AI Applications " davel@whutt.att.com (David Loewenstern) Hallvard Traetteberg xanthian@zorch.sf-bay.org (Kent Paul Dolan) bwb@unhd.unh.edu (Brent Benson) Bob Kirby Christopher Owens hall@aplcen.apl.jhu.edu (Marty Hall) Arun Welch Martin Boyer spr@prism.gatech.edu (Stefan Roth) Chris Richardson moore%cdr@cs.utah.edu (Timothy B. Moore) Dan Pierson Andreas Girgensohn Mohammad Pourheidari Dan Brotsky Kevin Thompson Stan Lanning jdye@ads.com (John W. Dye Jr.) Mikel Evins jkf@Franz.COM (Sean Foderaro) Curt Stevens gerson@parc.xerox.com rodrigue@parc.xerox.com George Robertson Susanne Jul:PARC:xerox (Susanne Jul) Larry Masinter john%amc.com%uunet.uucp@parcplace.uucp (John Sambrook) bic@cgl.ucsf.edu (Bruce Cohen) rww%ibuki.com@apple.uucp (Richard Weyhrauch) barry@ute.columbia.ncr.com (Barry Shelton) bouma@cs.purdue.edu rich@kate.coyote.trw.com (Rich Messenger) geoff@camex.com (Geoffrey S. Knauth) "Mark A. Tapia" Francois Felix INGRAND Arie Covrigaru hmueller@wfsc4.tamu.edu (Hal Mueller) osc!jgk@ames.arc.nasa.gov (Joe Keane) shashank@diamond (Shashank Joshi) Masuda:KSPA:Fuji Xerox (Yoshihiro Masuda) Kevin Gallagher WOODL@ACOUST.BYU.EDU (Larry Wood) Brian Foote ks@dfki.uni-sb.de (Kurt Schreiner) Winfried Barth tombre@loria.crin.fr (Karl Tombre) martin@computer-science.manchester.ac.uk (Martin Peim) Juergen Kopp Bjarne Steensgaard-Madsen Morten Marquard James L Mayer:wbst128:xerox (Jim Mayer) Dale Moberg rshapiro@arris.com (Richard Shapiro) Todd.Kaufmann@MADRID.MT.CS.CMU.EDU (todd) dz@irst.it (Massimo Dal Zotto) Danny Bobrow T.B.Dinesh rist@ultima.csd.uts.EDU.AU (Robert Rist) jbrown@wfsc4.tamu.edu (Jim Brown) will taylor coulman@ale.usask.ca (Randy A. Coulman) tim@cstr.edinburgh.ac.uk (Tim Bradshaw) andrew@isor.vuw.ac.nz Mitchell Marks john@linus.mitre.org (John D. Burger) Andrew Philpot mlease@blaze.tamu.edu (Mark Lease) Juergen Christoffel rdh@thumper.bellcore.com (Ralph Hill) Michael_I_Summers@cup.portal.com Magnus Ljungberg Jeff Dalton dmc@piccolo.ecn.purdue.edu (David M Chelberg) gil@banyan.banyan.com (Gil Pilz@Eng@Banyan) mike@acc.stolaf.edu ssmith@mprgate.mpr.ca (Shaun Smith) lisp5!simon%prosun.UUCP%TUB.BITNET@mitvma.mit.edu (Simon Leinen) lstead@breeze.bellcore.com Richard Lynch Peter Clitherow Ronald BODKIN kuba%starcom%navtech@sj.ate.slb.com (Kuba Kubalski) Nick Levine tk@allegra.tempo.nj.att.com John Richards m1pkd00@fed.frb.gov (Prasad Dharmasena) Anton Beschta fed!m1rab01@uunet.UU.NET edsdrd!gss@uunet.UU.NET (Gary Schiltz) layer@Franz.COM (Kevin Layer) Thomas_E_Morgan@cup.portal.com bard@cs.cornell.edu (Bard Bloom) "Maria Gini" Kurt Normark kenneth@EB.se (Kenneth Persson) reich%kestrel@AUSTIN.LOCKHEED.COM (Al Reich) marc@vlsi.polymtl.ca (Marc Paquette) mckay@PRC.Unisys.COM (Donald P McKay) miller@cs.rochester.edu Paula Ross wostner@garnet.berkeley.edu (Ulf Wostner) michael%km21@ztivax.siemens.com (Michael Sieper) msch%km21@ztivax.siemens.com (Matthias Schneider) Rolf Lindgren Stephen L Nicoud barley@atc.boeing.com denis@vlsi.polymtl.ca (Denis R. Martin) azayan@atc.boeing.com Randy Groves William K.Erickson Daniel Choy Edelson mikeb%wdl31@wdl1.wdl.fac.com (Michael H Bender) dcmartin@cs.wisc.edu (David C. Martin) alarson@src.honeywell.com (Aaron Larson) al@huntsai.boeing.com (Al Underbrink) David S.Miller Phil@ASLAN.Narnia.RPAL.COM (Phil Stubblefield) sam@hyperion.ESL.COM (Sam Hahn) David Wright Harri Poyhonen STella@xanadu.com csteury@bambam.es.com (Craig Steury) ntmtv!shea@ames.arc.nasa.gov (Ray Shea) Jan K|lander NO Votes: ---------- supple@en.ecn.purdue.edu (Murray R Supple) bruce@sonyd1.Broadcast.Sony.COM (Bruce Lilly) v7fs1!jls@apple.com (James Seidman) Jim Roche ado@elsie.nci.nih.gov (Arthur David Olson) david@elroy.Jpl.Nasa.Gov (David Robinson) Daniel A Haug fitz@wang.com (Tom Fitzgerald) wjwhite%well.uucp@apple.uucp (William J. White) Gregor Kiczales Yasuhiko Kiuchi Xerox PARC ---------- Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02073; Fri, 2 Nov 90 10:50:36 -0800 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16456>; Fri, 2 Nov 1990 10:49:16 PST Received: from p.Lanl.GOV ([128.165.4.4]) by alpha.xerox.com with SMTP id <16460>; Fri, 2 Nov 1990 10:41:58 PST Received: from zaphod.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA16863; Fri, 2 Nov 90 11:41:26 -0700 Received: by zaphod.lanl.gov.lanl.gov (4.0/SMI-4.0) id AA24804; Fri, 2 Nov 90 11:41:33 MST X-Ns-Transport-Id: 08002008D0FD0003CA4C Date: Fri, 2 Nov 1990 10:41:33 PST From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Subject: CLOS subset on KEE availablity To: commonloops.parc@xerox.com Message-Id: <9011021841.AA24804@zaphod.lanl.gov.lanl.gov> A few weeks ago, I said ... As a stopgap, as an interesting excercise, as a bridge for those migrating from KEE's O-O stuff to CLOS, and for several other reasons, I have a very reasonable subset of CLOS that is implemented as a syntactic front-end to KEE's unit creation and method invocation stuff. In principle, one writes code with CLOS and the classes, instances, and generic functions are constructed from KEE units and methods. I have used the system for a reasonable project with enough success that I intend this to be my standard KEE programming interface from this point on. A description of the package has been presented at the small, but always interesting, AI in DOE conference. Either the paper or the system are available to anyone who wants them. Due to the response to my mention of the package, I am making it available via anonymous ftp from zaphod.lanl.gov (128.165.44.202) To retrieve the software and the paper, % ftp zaphod.lanl.gov 220 zaphod FTP server (SunOS 4.0) ready. Name (your-machine:your-name): anonymous 331 Guest login ok, send ident as password. Password: your-name@your-machine (naturally, won't echo) 230 Guest login ok, access restrictions apply. ftp> cd pub 250 CWD command successful. ftp> bin 200 Type set to I. ftp> get clos-on-kee.tar 200 PORT command successful. 150 Binary data connection for clos-on-kee.tar (128.165.44.202,1083) (73728 bytes). 226 Binary Transfer complete. local: clos-on-kee.tar remote: clos-on-kee.tar 73728 bytes received in .13 seconds (5.5e+02 Kbytes/s) ftp> quit If you need individual files rather than a tar archive, or if you just want the paper, you may ftp> cd pub/clos-on-kee and access the individual files. Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18604; Fri, 2 Nov 90 14:28:32 -0800 Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <16495>; Fri, 2 Nov 1990 14:27:02 PST Received: from p.Lanl.GOV ([128.165.4.4]) by alpha.xerox.com with SMTP id <16495>; Fri, 2 Nov 1990 14:24:24 PST Received: from zaphod.lanl.gov by p.Lanl.GOV (5.61/1.14) id AA22244; Fri, 2 Nov 90 15:24:08 -0700 Received: by zaphod.lanl.gov.lanl.gov (4.0/SMI-4.0) id AA24995; Fri, 2 Nov 90 15:24:15 MST X-Ns-Transport-Id: 08002008D0FD0003CD07 Date: Fri, 2 Nov 1990 14:24:15 PST From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Subject: Sigh... a bug clos-on-kee To: commonloops.parc@xerox.com Message-Id: <9011022224.AA24995@zaphod.lanl.gov.lanl.gov> Naturally, 15 minutes after I announce to the world that I have something available, I find a bug. In my CLOS subset on KEE announced earlier today, there is a bug in the parsing of a defclass form such that (defclass foo () () :documentation "doc string" :metaclass my-metaclass) is accepted rather than (defclass foo () () (:documentation "doc string") (:metaclass my-metaclass)) I guess this shows just how much I use these in real CLOS/PCL and how well I read the spec. The fixed version is available on zaphod.lanl.gov via anonymous ftp using the same instructions as before. Please send any bugs found or comments regarding the package to Sorry for the problem. Skip Egdorf hwe@lanl.gov Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02958; Mon, 5 Nov 90 06:22:02 -0800 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16557>; Mon, 5 Nov 1990 06:10:02 PST Received: from ti.com ([128.247.159.141]) by alpha.xerox.com with SMTP id <16556>; Mon, 5 Nov 1990 06:05:16 PST Received: by ti.com id AA00210; Sat, 3 Nov 90 16:32:39 -0600 Received: from tilde by ti-csl id AA00272; Sat, 3 Nov 90 16:29:23 CST Received: from Islington-Terrace by tilde id AA06362; Sat, 3 Nov 90 13:50:24 -0600 Moon: Waning Gibbous (99% of full) X-Ns-Transport-Id: 08002008D0FD0003D997 Date: Sat, 3 Nov 1990 11:48:32 PST From: Paul Fuqua Subject: Trouble with PCL on Franz Allegro 3.0.1beta To: commonloops.parc@xerox.com Message-Id: <2866650512-10802843@Islington-Terrace> I'm trying to bring up PCL, CLX, and CLUE on Franz Allegro 3.0.1beta (8/23/88) on a Sun 4. I've built this combination on AKCL (thanks to Richard Harris's helpful notes), so I'm not totally new at this, but I was looking for more performance and this Allegro was laying around from a previous project. Unfortunately, I'm having trouble with PCL. Also unfortunately, upgrading is not an option if it costs anything. I have successfully built Victoria Day PCL, and CLX atop it, but CLUE uses lots of methods with EQL specialisers and this PCL (or this instance of it) goes into an infinite loop when it sees one. I have not successfully built May Day PCL (revs 2 and 3) -- it dies in fix-early-generic-functions, either during the first allocate-instance (an ISL structure is being corrupted), or after fixing two or three functions (runs out of swap space at 30 MB). I had to make a couple of changes to quadlap to handle 3.0.1beta, but I've also tried leaving it out entirely, with no difference. Does anyone have any helpful ideas? Victoria Day PCL would be fine if there's a fix for the EQL specialisers, but May Day PCL would be even better. Any fixes or suggestions appreciated. Paul Fuqua pf@csc.ti.com, ti-csl!pf Texas Instruments Computer Science Center, Dallas, Texas "I f***ed up." "Yes, but you gave it 100% effort." -- Mystic Pizza Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13922; Mon, 5 Nov 90 12:31:28 -0800 Received: from uc.msc.edu by MCC.COM with TCP/SMTP; Mon 5 Nov 90 14:19:27-CST Received: from [130.99.20.1] by uc.msc.edu (5.59/MSC-2.01/900718) id AA10515; Mon, 5 Nov 90 14:19:05 CST Received: from aspen.ciam.serc.mmm.com by mmm.serc.3m.com ( 3M/SERC - 4.0/BDR-1.0) id AA17048; Mon, 5 Nov 90 14:24:48 CST Received: from oak.ciam.serc.mmm.com by aspen.ciam.serc.mmm.com (4.0/SMI-4.0) id AA06502; Mon, 5 Nov 90 14:23:50 CST Date: Mon, 5 Nov 90 14:23:50 CST From: collins@aspen.serc.3m.com (John Collins) Message-Id: <9011052023.AA06502@aspen.ciam.serc.mmm.com> Received: by oak.ciam.serc.mmm.com (4.0/SMI-4.0) id AA03211; Mon, 5 Nov 90 14:26:29 CST To: common-lisp-object-system@mcc.com Cc: berlin@hplabs.hpl.hp.com, paepcke@hplap.hpl.hp.com Subject: CLOS programming style Greetings - At the Users and Implementor's Workshop in Ottawa last week, I agreed to pull together a chapter for the upcoming CLOS Report on "CLOS Programming Style". The purpose of this message is to solicit suggestions and ideas for such an undertaking. My understanding is that the intended audience for the book covers the spectrum from new users of CLOS to experienced CLOS programmers and specialists in object-oriented programming in general. I want to cover stylistic issues in program design and in presentation of the design and implementation to the reader. Appropriate topics might include - features of CLOS to use or avoid in various situations. - issues to consider in designing and documenting a protocol (see Lucy Berlin's paper in OOPSLA '90). I am particularly interested in what you tell a user of a protocol (the programmer who needs to use its facilities pretty much "as is") and what you tell the programmer who needs to extend it. - techniques that encourage extensibility and reusability. - interesting examples of use of method combination and multimethods (one idea that comes to mind is a way of using method combination to implement contract checking/enforcement as in eiffel) - efficiency traps that might not be obvious to the uninitiated (I don't want to dwell on this, but some examples of inefficient and more efficient ways to do the same thing might be useful). - slots vs. accessors: when is it appropriate to "advertise" the implementation of a class and contemplate use of slot-value, and when is it appropriate to "hide" the implementation under a layer of accessors. As David Moon has pointed out, anything anyone says on the topic of programming style is bound to be at least a little controversial; my goal is not to achieve consensus, but to pull together some examples and to get readers to think about some important issues. Any pointers or examples you can send me will be acknowledged and appreciated. Thank you in advance. Received: from alpha.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21408; Sat, 10 Nov 90 15:18:02 -0800 Received: from Mercury.Parc.Xerox.xns by alpha.xerox.com via XNS id <16948>; Sat, 10 Nov 1990 15:17:55 PST Received: from uunet.uu.net ([192.48.96.2]) by alpha.xerox.com with SMTP id <16948>; Sat, 10 Nov 1990 15:15:53 PST Received: from vigyan.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA07028; Sat, 10 Nov 90 18:15:45 -0500 Received: by shakti.ernet.in (1.2/Ultrix2.0-B) for ernet.in id AA29996; Sat, 10 Nov 90 22:29:09+0530 Apparently-To: commonloops%xerox.com@uunet.uucp X-Ns-Transport-Id: 08002008D0FD00041F8E Date: Sat, 10 Nov 1990 14:29:00 PST From: asood%vigyan.uucp@ncst.ernet.in To: commonloops.PARC@Xerox.com Message-Id: <9011102315.AA07028@uunet.uu.net>  We have a n old version of commonCommonLoops and would like to get a recent version. From: vigyan!asood X-Comment: From: vigyan!asood - Header Corrected at shakti.ernet.in Can you please tell how to get the rexcent version (If it is compatible with Common LIsp isp Object System)? Thanks Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00201; Wed, 14 Nov 90 10:40:38 -0800 Date: Wed 14 Nov 90 12:22:46-CST From: "David D. Loeffler" Subject: YET ANOTHER TEST MESSAGE To: cl-editorial@MCC.COM, cl-windows@MCC.COM, common-lisp@MCC.COM, common-lisp-object-system@MCC.COM, cl-compiler@MCC.COM, x3j13@MCC.COM Message-Id: <12637900849.43.AI.LOEFFLER@MCC.COM> Sorry for so many test messages but I am finding some real surprises. This will probably not be the last test message. ------- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02402; Wed, 14 Nov 90 12:20:59 -0800 Date: Wed 14 Nov 90 12:53:38-CST From: "David D. Loeffler" Subject: Last test message for today. To: cl-editorial@MCC.COM, cl-windows@MCC.COM, cl-cleanup@MCC.COM, common-lisp@MCC.COM, common-lisp-object-system@MCC.COM, x3j13@MCC.COM, cl-compiler@MCC.COM Message-Id: <12637906467.43.AI.LOEFFLER@MCC.COM> Until tomorrow! ------- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15831; Mon, 26 Nov 90 11:13:36 -0800 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 26 Nov 90 13:09:21-CST Received: from ucsd.edu by SAIL.Stanford.EDU with TCP; 26 Nov 90 11:08:56 PST Received: from odin.ucsd.edu by ucsd.edu; id AA16370 sendmail 5.64/UCSD-2.1-sun via SMTP Mon, 26 Nov 90 11:08:51 -0800 for Common-Lisp-Object-System@Sail.Stanford.edu Received: by odin.UCSD.EDU (5.59/UCSDPSEUDO.3) id AA21154 for Common-Lisp-Object-System@Sail.Stanford.edu; Mon, 26 Nov 90 11:08:49 PST From: wargo%cs@ucsd.edu (Dave Wargo) Message-Id: <9011261908.AA21154@odin.UCSD.EDU> Subject: CLOS for a mac. To: Common-Lisp-Object-System@Sail.Stanford.edu Date: Mon, 26 Nov 90 11:08:48 PST X-Mailer: ELM [version 2.3 PL8] Hi there; I am trying to put up CLOS on a mac and am a little confused. Having ftp'ed the file from arisia.xerox.com and tared the file I don't see anything like "CLOS.hqx" which is what I expected. In any case would you be so kind as to point me in the right direction? Dave Wargo dwargo@odin.ucsd.edu Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14395; Fri, 22 Feb 91 08:20:03 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 22 Feb 91 10:13:58-CST Received: from hplms26.hpl.hp.com by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA29381; Fri, 22 Feb 91 08:12:53 -0800 Received: from [15.4.88.79] by hplms26.hpl.hp.com with SMTP (16.5/15.5+IOS 3.20) id AA13367; Thu, 21 Feb 91 16:59:27 -0800 Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA00975; Thu, 21 Feb 91 16:56:47 pst Message-Id: <9102220056.AA00975@hplap.hpl.hp.com> To: Common-Lisp-Object-System@Sail.Stanford.edu Subject: CLOS Workshop '91 Organizer Volunteer? X-Mailer: mh6.5 Date: Thu, 21 Feb 91 16:56:46 PST From: Andreas Paepcke I will not be able to organize a CLOS workshop this year. Last year's event was held in the context of OOPSLA '90. This worked well. The job of a workshop organizer involves submitting a workshop proposal to the OOPSLA organization by April 1, publicizing the event, slapping the proceedings together, organizing the day and writing a short summary for the OOPSLA proceedings addendum. The reward for the work is the joy of putting together a gathering from which people leave refreshed and animated. Finding and working with the moderators is in itself stimulating, and the thinking involved can help structure one's own research. This year's OOPSLA will be held in Phoenix, Oct 6-12. For anyone interested I could provide last year's proceedings and a run-down of last year's event. Regards, Andreas Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03579; Fri, 15 Mar 91 19:42:07 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Fri 15 Mar 91 21:36:36-CST Received: from uunet.UU.NET by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA28025; Fri, 15 Mar 91 19:36:36 -0800 Received: by uunet.uu.net with UUCP (5.61/UUNET-primary-gateway) id AA22016; Fri, 15 Mar 91 22:36:32 -0500 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA11013; Fri, 15 Mar 91 18:20:58 PST Received: by vapor.Franz.COM (4.1/FI-1.0) id AA20177; Fri, 15 Mar 91 18:36:00 PST Message-Id: <9103160236.AA20177@vapor.Franz.COM> To: common-lisp-object-system@sail.stanford.edu Subject: Is a class object a valid method specializer? Date: Fri, 15 Mar 91 18:35:59 -0800 From: Chris Richardson For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? ----- Chris Richardson, Franz Inc. 1995 University Avenue, Suite 275 cer@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!cer (uucp) Phone: (415) 548-3600; FAX: (415) 548-8253 Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01368; Mon, 18 Mar 91 10:24:29 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 11:25:26-CST Received: from MEILLET.ILA.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA16317; Mon, 18 Mar 91 09:24:56 -0800 Received: from chestnut.com (ALMOND.CHESTNUT.COM) by meillet.ila.com (4.1/ILA-4.10) id AA05039; Mon, 18 Mar 91 12:23:19 EST Received: by chestnut.com (4.1/SMI-4.1) id AA02190; Mon, 18 Mar 91 12:23:43 EST Date: Mon, 18 Mar 91 12:23:43 EST From: kab@chestnut.com (Kim Barrett) Message-Id: <9103181723.AA02190@chestnut.com> To: moon@brazil.cambridge.apple.com Cc: cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: David A. Moon's message of Mon, 18 Mar 91 11:49:04 <9103181700.AA05819@brazil.cambridge.apple.com> Subject: Is a class object a valid method specializer? >> Date: Fri, 15 Mar 91 18:35:59 -0800 >> From: Chris Richardson >> >> For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? > > Date: Mon, 18 Mar 91 11:49:04 > From: moon@brazil.cambridge.apple.com (David A. Moon) > > No in 88-002R, yes in ANSI Common Lisp. I don't immediately remember what > cleanup removed the restriction. I don't remember any such cleanup, and searching my online copies of the passed proposals has failed to find one. I do remember this question being discussed some time ago. I think the discussion took place on this (the clos) list, and was triggered by Moon mentioning a recent extension added to Symbolic's implementation to permit something like what Chris describes. My recollection is that such a thing was considered reasonable, but it may have never gone beyond that (ie. maybe nobody ever got around to bringing this up for x3j13 to consider). Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03138; Mon, 18 Mar 91 11:11:48 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 10:49:26-CST Received: from brazil.cambridge.apple.com by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA14988; Mon, 18 Mar 91 08:49:21 -0800 Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA05819; Mon, 18 Mar 91 12:00:40 -0500 for common-lisp-object-system@sail.stanford.edu Message-Id: <9103181700.AA05819@brazil.cambridge.apple.com> Date: Mon, 18 Mar 91 11:49:04 From: moon@brazil.cambridge.apple.com (David A. Moon) To: Chris Richardson Subject: Re: Is a class object a valid method specializer? Cc: common-lisp-object-system@sail.stanford.edu > Date: Fri, 15 Mar 91 18:35:59 -0800 > From: Chris Richardson > > For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? No in 88-002R, yes in ANSI Common Lisp. I don't immediately remember what cleanup removed the restriction. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03684; Mon, 18 Mar 91 11:19:59 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 12:01:01-CST Received: from brazil.cambridge.apple.com by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA17508; Mon, 18 Mar 91 10:00:54 -0800 Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA05942; Mon, 18 Mar 91 13:11:57 -0500 for common-lisp-object-system@sail.stanford.edu Message-Id: <9103181811.AA05942@brazil.cambridge.apple.com> Date: Mon, 18 Mar 91 13:00:20 From: moon@brazil.cambridge.apple.com (David A. Moon) To: kab@chestnut.com (Kim Barrett) Subject: Re: Is a class object a valid method specializer? Cc: cer@franz.com, common-lisp-object-system@sail.stanford.edu > Date: Mon, 18 Mar 91 12:23:43 EST > From: kab@chestnut.com (Kim Barrett) > > >> Date: Fri, 15 Mar 91 18:35:59 -0800 > >> From: Chris Richardson > >> > >> For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? > > > > Date: Mon, 18 Mar 91 11:49:04 > > From: moon@brazil.cambridge.apple.com (David A. Moon) > > > > No in 88-002R, yes in ANSI Common Lisp. I don't immediately remember what > > cleanup removed the restriction. > > I don't remember any such cleanup, and searching my online copies of the passed > proposals has failed to find one. > > I do remember this question being discussed some time ago. I think the > discussion took place on this (the clos) list, and was triggered by Moon > mentioning a recent extension added to Symbolic's implementation to permit > something like what Chris describes. My recollection is that such a thing was > considered reasonable, but it may have never gone beyond that (ie. maybe nobody > ever got around to bringing this up for x3j13 to consider). See page 4-15 of X3J13 draft 8.81. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03854; Mon, 18 Mar 91 11:22:30 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 12:13:54-CST Received: from MEILLET.ILA.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA17851; Mon, 18 Mar 91 10:13:27 -0800 Received: from chestnut.com (ALMOND.CHESTNUT.COM) by meillet.ila.com (4.1/ILA-4.10) id AA05076; Mon, 18 Mar 91 13:10:52 EST Received: by chestnut.com (4.1/SMI-4.1) id AA02261; Mon, 18 Mar 91 13:11:08 EST Date: Mon, 18 Mar 91 13:11:08 EST From: kab@chestnut.com (Kim Barrett) Message-Id: <9103181811.AA02261@chestnut.com> To: moon@brazil.cambridge.apple.com Cc: kmp@symbolics.com Cc: cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: David A. Moon's message of Mon, 18 Mar 91 13:00:20 <9103181811.AA05942@brazil.cambridge.apple.com> Subject: Is a class object a valid method specializer? > > >> For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? > > > > > > No in 88-002R, yes in ANSI Common Lisp. I don't immediately remember > > > what cleanup removed the restriction. > > > > I don't remember any such cleanup, and searching my online copies of the > > passed proposals has failed to find one. > > See page 4-15 of X3J13 draft 8.81. Well, that's pretty unambiguous. I wonder where it came from though. I've added Kent to the recipients, in case he can shed some light on that question. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04469; Mon, 18 Mar 91 11:35:10 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 13:23:25-CST Received: from LUCID.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA20383; Mon, 18 Mar 91 11:23:22 -0800 Received: from kuwait ([192.31.212.118]) by heavens-gate.lucid.com id AA09847g; Mon, 18 Mar 91 11:20:04 PST Received: by kuwait id AA09031g; Mon, 18 Mar 91 11:24:40 PST Date: Mon, 18 Mar 91 11:24:40 PST From: Jon L White Message-Id: <9103181924.AA09031@kuwait> To: kab@chestnut.com Cc: moon@brazil.cambridge.apple.com, kmp@symbolics.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: Kim Barrett's message of Mon, 18 Mar 91 13:11:08 EST <9103181811.AA02261@chestnut.com> Subject: Is a class object a valid method specializer? My memory of the situation was that it was brough up on (maybe?) the "mop" mailing list last fall, when the 11-Jul-90 MOP proposal was being disucssed. Moon claimed it was probably an oversight, and several of us agreed with him (I amongst those in agreement). However, at least one person disagreed (I think Gregor?), but didn't make the disagreement explicit other than "user interface" considerations. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06449; Mon, 18 Mar 91 12:15:49 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 14:12:20-CST Received: from STONY-BROOK.SCRC.Symbolics.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA21629; Mon, 18 Mar 91 12:12:15 -0800 Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 920451; 18 Mar 1991 13:59:38-0500 Date: Mon, 18 Mar 1991 14:02-0500 From: Kent M Pitman Subject: Is a class object a valid method specializer? To: kab@chestnut.com Cc: moon@brazil.cambridge.apple.com, kmp@symbolics.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: <9103181811.AA02261@chestnut.com> Message-Id: <19910318190225.2.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Mon, 18 Mar 1991 13:11 EST From: kab@chestnut.com (Kim Barrett) > > >> For example, is (defmethod foo ((x #.(find-class t))) ... ) legal? > > > > > > No in 88-002R, yes in ANSI Common Lisp. I don't immediately remember > > > what cleanup removed the restriction. > > > > I don't remember any such cleanup, and searching my online copies of the > > passed proposals has failed to find one. > > See page 4-15 of X3J13 draft 8.81. Well, that's pretty unambiguous. I wonder where it came from though. I've added Kent to the recipients, in case he can shed some light on that question. Hmmmm. Well, it wasn't in the text Kathy gave me and there's no comment saying where it came from. (For most potentially controversial things like this, I've been following Kathy's lead and trying to leave comments behind to help me justify changes that might get challenged.) I did a Find String of "specializer" in all the passed cleanup issues and didn't discover any which would support this change. (Not surprising since changes due to cleanups usually get marked in the source in order for indexing to notice them.) My guess is that some reviewer that I trusted said it should be the other way--or perhaps even more likely said as an aside that they wished it were the other way and I misinterpreted their comment to be saying that it was just wrong in the source. (Presumably the fact that the change seems right to me made me more susceptible.) I'd suggest that someone raise it as an issue at the meeting under editorial feedback, and propose to affirm the wording that's there (if they like it) or to revert it (if they don't). Sorry about all the confusion. I really am not trying hard not to secretly sneak things in like this. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07630; Mon, 18 Mar 91 12:28:04 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 14:12:19-CST Received: from STONY-BROOK.SCRC.Symbolics.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA21630; Mon, 18 Mar 91 12:12:15 -0800 Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 920468; 18 Mar 1991 14:25:24-0500 Date: Mon, 18 Mar 1991 14:28-0500 From: Kent M Pitman Subject: Is a class object a valid method specializer? To: jonl%kuwait@lucid.com Cc: kab@chestnut.com, moon@brazil.cambridge.apple.com, kmp@symbolics.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: <9103181924.AA09031@kuwait> Message-Id: <19910318192810.6.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Mon, 18 Mar 1991 14:24 EST From: Jon L White My memory of the situation was that it was brough up on (maybe?) the "mop" mailing list last fall, when the 11-Jul-90 MOP proposal was being disucssed. Moon claimed it was probably an oversight, and several of us agreed with him (I amongst those in agreement). However, at least one person disagreed (I think Gregor?), but didn't make the disagreement explicit other than "user interface" considerations. Btw, without the ability to name a class object here, the entire defmethod layer is not accessible to programs that deal with anonymous classes. I regard this as more than `mere user interface' since it may force some programmers to access an entire new level of substrate which they might otherwise never have any need to know or use. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08320; Mon, 18 Mar 91 12:40:38 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 14:17:54-CST Received: from brazil.cambridge.apple.com by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA21724; Mon, 18 Mar 91 12:17:48 -0800 Received: from [90.223.0.23] by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA06164; Mon, 18 Mar 91 15:28:28 -0500 for common-lisp-object-system@sail.stanford.edu Message-Id: <9103182028.AA06164@brazil.cambridge.apple.com> Date: Mon, 18 Mar 91 15:16:52 From: moon@brazil.cambridge.apple.com (David A. Moon) To: Kent M Pitman Subject: Re: Is a class object a valid method specializer? Cc: kab@chestnut.com, moon@brazil.cambridge.apple.com, kmp@symbolics.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu I remember now that CLIM uses the feature, which suggests that it is current practice in some implementations. I don't have a copy of CLIM myself so I can't check this. Presumably I am referring to CLIM 1.0 rather than 0.9. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08525; Mon, 18 Mar 91 18:20:46 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 20:18:12-CST Received: from alpha.Xerox.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA10272; Mon, 18 Mar 91 18:17:52 -0800 Received: from anchor.parc.xerox.com ([13.2.17.241]) by alpha.xerox.com with SMTP id <16408>; Mon, 18 Mar 1991 14:15:41 PST Received: by anchor.parc.xerox.com id <3664>; Mon, 18 Mar 1991 13:16:26 -0800 From: Gregor Kiczales Sender: Gregor Kiczales Fake-Sender: gregor@parc.xerox.com To: jonl%kuwait@lucid.com Cc: kab@chestnut.com, moon@brazil.cambridge.apple.com, kmp@symbolics.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: Jon L White's message of Mon, 18 Mar 91 11:24:40 PST <9103181924.AA09031@kuwait> Subject: Re: Is a class object a valid method specializer? Line-Fold: NO Message-Id: <91Mar18.131626pst.3664@anchor.parc.xerox.com> Date: Mon, 18 Mar 1991 13:16:21 PST Date: Mon, 18 Mar 91 11:24:40 PST From: Jon L White My memory of the situation was that it was brough up on (maybe?) the "mop" mailing list last fall, when the 11-Jul-90 MOP proposal was being disucssed. Moon claimed it was probably an oversight, and several of us agreed with him (I amongst those in agreement). However, at least one person disagreed (I think Gregor?), but didn't make the disagreement explicit other than "user interface" considerations. My disagreement has to do with the difference between specializers and specializer names. Clearly class (meta)objects are valid specializer (meta)objects. I don't think they are valid as names though. But I now remember giving in on this. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08719; Mon, 18 Mar 91 18:38:38 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 20:36:59-CST Received: from LUCID.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA10476; Mon, 18 Mar 91 18:36:55 -0800 Received: from kuwait ([192.31.212.118]) by heavens-gate.lucid.com id AA10773g; Mon, 18 Mar 91 18:33:31 PST Received: by kuwait id AA09399g; Mon, 18 Mar 91 18:38:11 PST Date: Mon, 18 Mar 91 18:38:11 PST From: Jon L White Message-Id: <9103190238.AA09399@kuwait> To: KMP@STONY-BROOK.SCRC.Symbolics.COM Cc: kab@chestnut.com, moon@brazil.cambridge.apple.com, jonl_cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Mon, 18 Mar 1991 14:28-0500 <19910318192810.6.KMP@BOBOLINK.SCRC.Symbolics.COM> Subject: Is a class object a valid method specializer? re: Btw, without the ability to name a class object here, the entire defmethod layer is not accessible to programs that deal with anonymous classes. I regard this as more than `mere user interface' since it may force some programmers to access an entire new level of substrate which they might otherwise never have any need to know or use. Without recalling specifically who invoked the "user interface" argument, I recall the thread of it being that the MOP was supposed to be the "functional interface" whereas DEFMETHOD was not. Counter to that argument was my own that points out how CLOS opens the spectre of class objects being _type-specifiers_ just as much as class names are. Thus, a "parameter specializer name", which is used as a type-restriction in a DEFMETHOD form (EQL excluded for the moment), should logically include the class object too, since both the class name and the class object specify the same data type. Just for the record, I've verified that Moon's comment about "current practice" applies to Lucid's 4.0 relase. I hope we don't have to debate this publicly; can't we just agree amongst ourselves not to bring it up at Mountain View this week? -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08833; Mon, 18 Mar 91 18:54:38 -0800 Received: from Sunburn.Stanford.EDU by MCC.COM with TCP; Mon 18 Mar 91 20:52:40-CST Received: from STONY-BROOK.SCRC.Symbolics.COM by Sunburn.Stanford.EDU with SMTP (5.61+IDA/25-eef) id AA10625; Mon, 18 Mar 91 18:52:36 -0800 Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 920767; 18 Mar 1991 21:48:53-0500 Date: Mon, 18 Mar 1991 21:51-0500 From: Kent M Pitman Subject: Is a class object a valid method specializer? To: jonl%kuwait@lucid.com Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, kab@chestnut.com, moon@brazil.cambridge.apple.com, cer@franz.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: <9103190238.AA09399@kuwait> Message-Id: <19910319025137.3.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Mon, 18 Mar 1991 21:38 EST From: Jon L White ... I hope we don't have to debate this publicly; can't we just agree amongst ourselves not to bring it up at Mountain View this week? If there is no one disagreeing, why should bringing it up imply debate? I am very uncomfortable with the idea of retaining something in the standard which I cannot cite a reference for. As a matter of policy, I would prefer for things that have semantic impact to be voted upon so that people don't get the idea that I'm abusing my power as editor. Why wouldn't this just be a quick and simple unanimous vote in favor of blessing the wording that is perhaps-accidentally now present in the spec? [In other words, if there's someone who would vote against it, can they please identify themselves now?] This is also important because some people are tracking CLtL+Cleanups (by which I generically include LOOP, Errors, and CLOS as cleanups) and assuming they are up to date. Little details like this which are not part of the database audit trail are sure to show up somewhere down the line as even worse confusion. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07595; Mon, 8 Apr 91 08:47:27 -0700 Received: from netmgr.MMC.COM by MCC.COM with TCP; Mon 8 Apr 91 10:36:58-CDT Received: by mmc.com (netmgr.010490) Return-Path: Received: by den.mmc.com (everest.021690) Received: by maxai.den.mmc.com (maxai.mmc.generic.101389) Date: Mon, 8 Apr 91 09:36:50 edt From: Rick Duffy Message-Id: <9104081336.AA04344@maxai> To: common-lisp-object-system@mcc.com Subject: Clos Please Add me to the Common-lisp-object-system distribution list. Thanks! Rick Duffy Martin Marietta Astronautics (303) 971-2420 rick@maxai.den.mmc.com Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18863; Sat, 18 May 91 06:08:56 -0700 Message-Id: <9105181308.AA18863@arisia.Xerox.COM> Received: from UICVM.uic.edu by MCC.COM with TCP; Sat 18 May 91 08:07:54-CDT Received: from BRFUEM.BITNET by UICVM.uic.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 9558; Sat, 18 May 91 08:08:03 CDT Received: from BRFUEM.BITNET (HJBORTOL) by BRFUEM.BITNET (Mailer R2.07) with BSMTP id 5856; Sat, 18 May 91 10:07:08 C Date: Sat, 18 May 91 10:06:24 C From: HJBORTOL%BRFUEM.BITNET@UICVM.uic.edu Organization: Fundacao Universidade Estadual de Maringa - Brasil Subject: Subscription To: common-lisp-object-system@mcc.com, common-lisp-object-system-request@mcc.com X-Acknowledge-To: Greetings ... My name is Humberto Jose Bortolossi and I'm a math's professor at Fundacao Universidade Estadual de Maringa', Brazil. I'm studying symbolical mathematics, a field of Artificial Intelligence. So, I would like to get into Common Lisp mailing list. Thanks very much in advance. Humberto Jose Bortolossi Department of Mathematics BITNET: HJBORTOL@BRFUEM.BITNET ------------------------------------------------------------------------------- ================= ~~~~~~~~~~~~~~~~~~~~~~~~~~ ||||| ||||| Humberto Jose Bortolossi ~~~~~~~~~ ||| ||| Department of Mathematics - F U E M ~~~~~~~ ||| ||| ||| ||| BITNET >>> HJBORTOL at BRFUEM.BITNET ||| ||| ~~~~~~ ANSP >>> HJBORTOL at BRFUEM.ANPR.BR ||||| ||||| ~~~~~~~~~~~~~~ ================= ~~~~~~~~~~~~~~~~~~~~~ TELEFAX >>> (0442) 22-2754 -------------------------------------------------------------------------------