Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24833; Tue, 20 Feb 90 18:45:28 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 20 FEB 90 18:37:53 PST Return-Path: Redistributed: commonloops.pa Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 20 FEB 90 18:36:07 PST Received: by ames.arc.nasa.gov (5.61/1.2); Tue, 20 Feb 90 18:35:37 -0800 Received: from herald. by ntmtv.com (3.2/SMI-3.2) id AA17163; Tue, 20 Feb 90 09:47:27 PST Received: by herald. (4.0/SMI-4.0) id AA05728; Tue, 20 Feb 90 09:42:58 PST From: irvine%ntmtv.uucp@ames.arc.nasa.gov (Chuck Irvine) Message-Id: <9002201742.AA05728@herald.> Date: Tue, 20 Feb 90 09:34:47 PST Subject: no success with bitftp To: commonloops.pa@Xerox.COM Has anyone been successful in obtaining PCL through the bitftp method that Gregor described? I tried it last Friday (Feb 16) and as yet have not received anything back. I also sent the suggested message to get more info regarding bitftp and have received no response from that either. One more question, what is the complete pathname to the pcl tarfile, "pub/pcl" or "/pcl" or what? Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27911; Tue, 20 Feb 90 20:40:23 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 20 FEB 90 20:40:10 PST Return-Path: <@SKAGIT.atc.boeing.com.ARPANET:snicoud@atc.boeing.com> Redistributed: commonloops.PA Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 20 FEB 90 20:34:21 PST Received: by atc.boeing.com on Tue, 20 Feb 90 20:34:46 PST Date: Tue, 20 Feb 90 20:42 PST From: Stephen Nicoud Subject: RE: no success with bitftp To: Chuck Irvine Cc: CommonLoops.PA@Xerox.COM Message-Id: <19900221044226.0.SLN@SKAGIT.atc.boeing.com> Date: 21 Feb 90 03:59:50 GMT From: irvine%ntmtv.uucp@ames.arc.nasa.gov (Chuck Irvine) One more question, what is the complete pathname to the pcl tarfile, "pub/pcl" or "/pcl" or what? It's arisia.xerox.com:/pcl/tarfile. Here's an ftp directory listing of arisia.xerox.com:/pcl/* : > ftp arisia.xerox.com Connected to arisia.xerox.com. 220 arisia FTP server (Version 4.165 Tue Dec 6 18:32:49 PST 1988) ready. 331 Guest login ok, send ident as password. 230 Guest login ok, access restrictions apply. ftp> cd pcl 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls (0 bytes). total 979 drwxrwxrwx 2 393 100 512 Feb 20 13:15 archive drwxrwxr-x 2 375 100 512 Jun 29 1989 doc -rw-r--r-- 1 375 100 991232 Feb 16 15:55 tarfile drwxr-xr-x 2 481 100 512 Oct 26 1988 web 226 Transfer complete. 255 bytes received in 0.65 seconds (0.38 Kbytes/s) ftp> bye 221 Goodbye. > Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28020; Tue, 20 Feb 90 20:46:12 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 20 FEB 90 20:46:00 PST Return-Path: Redistributed: commonloops.PA Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 20 FEB 90 20:39:05 PST Received: by uunet.uu.net (5.61/1.14) with UUCP id AB17576; Tue, 20 Feb 90 23:38:15 -0500 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA04192; Tue, 20 Feb 90 17:54:37 PST Received: by crisp.Franz.COM (4.0/FI-1.0) id AA07562; Tue, 20 Feb 90 17:54:02 PST Date: Tue, 20 Feb 90 17:54:02 PST From: jim@franz.com (Jim Veitch) Message-Id: <9002210154.AA07562@crisp.Franz.COM> To: smith%cam.sri.com@Warbucks.AI.SRI.COM Subject: Re: Allegro-tailored PCL Cc: cl-bugs@franz.com, commonloops.PA@Xerox.COM Date: Tue, 20 Feb 90 10:04:20 GMT From: smith%cam.sri.com@Warbucks.AI.SRI.COM (Arnold Smith) To: cl-bugs@Franz.COM Subject: Allegro-tailored PCL Cc: smith%cam.sri.com@Warbucks.AI.SRI.COM, commonloops@xerox.com As Franz has been in the habit of tailoring the released versions of PCL to Allegro (particularly with regard to case-sensitivity, I think), will there in due course be a directory from which we Allegro users can ftp the new version of PCL with the Franz mods already installed? Yes, we will be doing this in due course. Actually, we don't even know how much tailoring will be required, yet, so we are not doing it just yet. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08010; Wed, 21 Feb 90 02:40:57 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 21 FEB 90 01:49:19 PST Return-Path: <@CUNYVM.CUNY.EDU:PT_MAGEE@VAX.ACS.OPEN.AC.UK> Redistributed: commonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 21 FEB 90 01:47:54 PST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4669; Wed, 21 Feb 90 04:46:33 EST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 9211; Wed, 21 Feb 90 09:38:20 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5416; Wed, 21 Feb 90 09:38:19 GM Via: UK.AC.OU.ACSVAX; 21 FEB 90 9:38:14 GMT Date: Wed, 21 FEB 90 09:38:50 GMT From: PT_MAGEE%VAX.ACS.OPEN.AC.UK@CUNYVM.CUNY.EDU To: commonLoops.pa@Xerox.COM Subject: FTP Sender: JANET "PT_MAGEE@UK.AC.OPEN.ACS.VAX" Message-Id: <900221-014919-3841@Xerox> In the directory pub at arisia.xerox.com there are four files thus: pcl-beta.tar.Z pcl-env-internal.lisp pcl.tar.Z pcr.tar.Z My guess is #3 is the one. ergo FTP file should be FTP arisia.xerox.com UUENCODE CD pub BINARY GET pcl.tar.Z QUIT Is this right? (serious disclaimer here!!!) Pete Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21416; Wed, 21 Feb 90 09:49:47 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 21 FEB 90 09:38:00 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 21 FEB 90 09:23:35 PST Received: by uunet.uu.net (5.61/1.14) with UUCP id AA01663; Wed, 21 Feb 90 12:22:59 -0500 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA06265; Wed, 21 Feb 90 08:19:48 PST Received: by frisky.Franz.COM (3.2/FI-1.0) id AA04376; Wed, 21 Feb 90 08:18:49 PST Date: Wed, 21 Feb 90 08:18:49 PST From: jkf@franz.com (Sean Foderaro) Message-Id: <9002211618.AA04376@frisky.Franz.COM> To: smith%cam.sri.com@Warbucks.AI.SRI.COM Subject: Re: [spr1113] Allegro-tailored PCL Bh: append spr1113 Cc: bugs@franz.com, commonloops.pa@Xerox.COM I think that Jim Veitch might have misunderstood your question. We do have some programs we use to convert PCL sources to a more Unix-friendly style (all files end in newlines, it can run in any case sensitivity mode). Unfortunately some of this process isn't automatic (just look at all the calls to intern of a format created string). Thus we usually don't do the conversion right away, preferring to wait and see how stable a version will be before we grab it. It would be easier for me to send your our conversion tools than for you to wait for us to do the conversion each time. Send me mail if you are interested. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23566; Thu, 22 Feb 90 02:21:55 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 21 FEB 90 22:06:26 PST Date: Tue, 20 Feb 90 11:45 PST From: Gregor.pa@Xerox.COM Subject: bugs in BITFTP documentation To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-8.text.newest Message-Id: <19900220194515.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no There were some bugs in the previous version of the directions for using BITFTP. Hopefully, this version is right. Please let me know. ---------------- 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'. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23812; Thu, 22 Feb 90 02:43:09 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 21 FEB 90 22:06:57 PST Date: Wed, 21 Feb 90 11:14 PST From: Gregor.pa@Xerox.COM Subject: Re: no success with bitftp To: Chuck Irvine Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-8.text.newest In-Reply-To: <9002201742.AA05728@herald.> Message-Id: <19900221191428.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 20 Feb 90 09:34:47 PST From: ntmtv!irvine@ames.arc.nasa.gov (Chuck Irvine) Has anyone been successful in obtaining PCL through the bitftp method that Gregor described? I tried it last Friday (Feb 16) and as yet have not received anything back. I also sent the suggested message to get more info regarding bitftp and have received no response from that either. One more question, what is the complete pathname to the pcl tarfile, "pub/pcl" or "/pcl" or what? The directory is /pcl, as some have noted and is reflected in the corrected instructions I sent out yesterday. But, I must say that I myself have not received anything back from Princeton when I asked for a copy of PCL. I was just given these directions from somone else, so I will let others explore this and let all of us know when they get a working set of directions. Hopefully someone will get this to work soon. Gregor ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27406; Thu, 22 Feb 90 07:31:14 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 22 FEB 90 07:25:20 PST Return-Path: <@CUNYVM.CUNY.EDU:SARTI@ICE622.GE.CNR.IT> Redistributed: CommonLoops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 22 FEB 90 06:57:31 PST Received: from ICNUCEVX.CNUCE.CNR.IT by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3453; Thu, 22 Feb 90 09:56:09 EST Received: from ICE622 by ICNUCEVX.CNUCE.CNR.IT; Thu, 22 Feb 90 15:56 MET Date: Thu, 22 Feb 90 15:55 MET From: SARTI%ICE622.GE.CNR.IT@CUNYVM.CUNY.EDU Subject: Princeton bitftp service To: CommonLoops.pa@Xerox.COM Message-Id: X-Original-To: clos, SARTI X-Envelope-To: CommonLoops.pa@Xerox.com Date: Wed, 21 Feb 90 11:14 PST From: Gregor.pa@Xerox.COM But, I must say that I myself have not received anything back from Princeton when I asked for a copy of PCL. I was just given these directions from somone else, so I will let others explore this and let all of us know when they get a working set of directions. Hopefully someone will get this to work soon. We have successfully downloaded PCL beta 3 rel through the bitftp service at Princeton. This is the message we sent: From: ICE622::SARTI "LUIGI SARTI" 20-FEB-1990 09:28:53.82 To: Orig_To! bitftp@pucc, SARTI CC: Subj: FTP arisia.xerox.com UUENCODE CD pcl BINARY GET tarfile QUIT We got this answer: From: CNUCE::IN%"BITFTP@PUCC.BITNET" "Princeton BITNET FTP Server" 20-FEB-199 0 22:35:13.36 To: SARTI@ICE622.GE.CNR.IT CC: Subj: BITFTP REPLY Received: from ICNUCEVM.CNUCE.CNR.IT by ICNUCEVX.CNUCE.CNR.IT; Tue, 20 Feb 90 22:34 MET Received: from PUCC.PRINCETON.EDU by ICNUCEVM.CNUCE.CNR.IT (Mailer R2.03B) with BSMTP id 1287; Tue, 20 Feb 90 22:35:04 MET Received: by PUCC (Mailer R2.06X) id 0774; Tue, 20 Feb 90 09:59:25 EST Date: Tue, 20 Feb 1990 09:57:23 EST From: Princeton BITNET FTP Server Subject: BITFTP REPLY To: SARTI@ICE622.GE.CNR.IT Message-id: X-Envelope-to: SARTI@ICE622.GE.CNR.IT > FTP arisia.xerox.com UUENCODE > CD pcl >> OPEN ARISIA.XEROX.COM <<< 220 arisia FTP server (Version 4.165 Tue Dec 6 18:32:49 PST 1988 ) ready. >> USER anonymous SARTI@ICE622.GE.CNR.IT >>> USER anonymous <<< 331 Guest login ok, send ident as password. >>> PASS ******** <<< 230 Guest login ok, access restrictions apply. > CD pcl >> CD pcl >>> CWD pcl <<< 250 CWD command successful. > BINARY >> BINARY FIXED 128 >>> TYPE i <<< 200 Type set to I. > GET tarfile >> GET tarfile SARTI.TARFILE.D ( REPLACE >>> PORT 128,112,129,99,11,194 <<< 200 PORT command successful. >>> RETR tarfile <<< 150 Opening BINARY mode data connection for tarfile (991232 byte s). <<< 226 Transfer complete. >>>> File "tarfile" sent to you as "SARTI TARFILE". > QUIT >> CLOSE >>> QUIT <<< 221 Goodbye. Along with this message, we received 19 other messages. We stripped out the first 18 lines of the protocol (with `tail +18l ) we concatenated them all in the proper order ('cat), uudecoded the big file obtaining a SARTI.TARFILE file which was "untarred" with `tar xvf SARTI.TARFILE This produced a ./pcl directory containing all the beta 3 files. --------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19524; Mon, 26 Feb 90 13:58:29 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 26 FEB 90 11:08:03 PST Date: Mon, 26 Feb 90 11:05 PST From: Gregor.pa@Xerox.COM Subject: important performance patch To: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-8.text.newest Message-Id: <19900226190536.8.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no The following patch, to Rainy Day PCL, fixes a problem which, in some programs, can cause serious performance problems. You should make this patch right away. ;from dfun.lisp (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) (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))))))))) ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02851; Wed, 28 Feb 90 16:32:54 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 28 FEB 90 15:39:46 PST Return-Path: Redistributed: commonloops.pa Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 28 FEB 90 15:38:30 PST Received: by ames.arc.nasa.gov (5.61/1.2); Wed, 28 Feb 90 15:38:24 -0800 Received: from herald. by ntmtv.com (3.2/SMI-3.2) id AA19670; Wed, 28 Feb 90 14:37:32 PST Received: by herald. (4.0/SMI-4.0) id AA08313; Wed, 28 Feb 90 14:35:50 PST From: irvine%ntmtv.uucp@ames.arc.nasa.gov (Chuck Irvine) Message-Id: <9002282235.AA08313@herald.> Date: Wed, 28 Feb 90 14:21:43 PST Subject: a problem with "un taring". To: commonloops.pa@Xerox.COM I'm having some trouble with the "bitftp" procedure for getting the pcl sources. Can anyone help? ... I did succeed in getting the proper mail files and uudecoding them. I assume that the file resulting from "uudecode" is not compressed as that is what the "uncompress" command says when trying to uncompress it. The real problem occurs when I try to untar the tar file. After successfully extracting all of the "text" files, e.g. 12-7-88-notes.text, the tar command encounters a checksum error when it trys to extract the first "lisp" file, boot.lisp. I tried changing 5Es to 7Es, as suggested in the bitftp help, to no avail. Does anyone have any idea what might be going wrong? Any help appreciated. Chuck Irvine Northern Telecom Technology, Mountain View, CA Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04932; Wed, 28 Feb 90 12:30:32 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 28 FEB 90 09:04:09 PST Return-Path: Redistributed: commonloops.pa Received: from CYCLOPS.DREA.dnd.CA ([192.12.62.47]) by Xerox.COM ; 28 FEB 90 08:38:44 PST Date: Wed, 28 Feb 90 11:56 AST From: Gavin L. Hemphill Subject: Possible bug/typo in Rainy Day PCL To: commonloops.pa@Xerox.COM Message-Id: <19900228155644.3.GAVIN@CYCLOPS.DREA.dnd.CA> Alias-Address: HEMPHILL@NCS.DND.CA Postal-Address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada Phone-Number: (902) 426-3100 [8:00am to 4:15pm Atlantic time] Template-For-Reply: DEFAULT-REPLY-MIDDLE-TEMPLATE In 2/16/90 PCL -- Rainy Day PCL, in the file std-class.lisp. In the method "reinitialize-instance :after" there is a call to "apply #'update-dependent class dependent initargs". The function update-dependent does not appear to be defined anywhere. G++ ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04846; Wed, 28 Feb 90 12:25:50 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 28 FEB 90 07:05:35 PST Return-Path: Redistributed: CommonLoops.pa Received: from RELAY.CS.NET ([192.31.103.4]) by Xerox.COM ; 28 FEB 90 06:58:53 PST Received: from [129.13.10.90] by RELAY.CS.NET id ac15524; 28 Feb 90 8:58 EST Received: from [129.69.1.198] by iraun1.ira.uka.de id aa01169; 28 Feb 90 15:56 MET Received: by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 28 Feb 90 15:55:40 +0100 From: Thomas Schwab Message-Id: <9002281456.AA19939@diana.informatik.uni-stuttgart.de> Received: by diana.informatik.uni-stuttgart.de; Wed, 28 Feb 90 15:56:44 +0100 Subject: Magic number 8 in Rainy Day PCL ??? To: CommonLoops.pa@Xerox.COM Date: Wed, 28 Feb 90 15:56:42 MET DST X-Mailer: ELM [version 2.2 PL15] We have some serious problems with the use of metaclasses in the "Rainy Day" version of PCL. The following lines of code perform an "accessor miss" error at the 8th read access to the slot. This error occurs in ACL, LUCID and Symbolics GENERA 7.2. Similar errors occur if you use 8 "setf"s to set the slot. -------------------------- CUT HERE ----------------------------------- (in-package 'pcl) (defclass my-meta-class (pcl::standard-class)()) (defclass my-class () ((slot-a :initform "default" :reader read-a)) (:metaclass my-meta-class)) (setq inst (make-instance 'my-class)) (format t "inst created~%") (format t "1. access~%") (read-a inst) (format t "2. access~%") (read-a inst) (format t "3. access~%") (read-a inst) (format t "4. access~%") (read-a inst) (format t "5. access~%") (read-a inst) (format t "6. access~%") (read-a inst) (format t "7. access~%") (read-a inst) (format t "8. access~%") (read-a inst) -------------------------- CUT HERE ----------------------------------- Is 8 a "magic number" for the Rainy Day Version :-) Is this a known problem and are there any fixes available? -- ============================================================================== Thomas Schwab schwab@ifi.informatik.uni-stuttgart.dbp.de Institut fuer Informatik Abtl. Dialogsysteme Herdweg 51 D - 7000 Stuttgart 1 Tel.: (+49 | 0) 711-121-1358 ============================================================================== Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04588; Fri, 2 Mar 90 17:22:05 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 01 MAR 90 11:53:17 PST Return-Path: Redistributed: CommonLoops.PA Received: from boulder.Colorado.EDU ([128.138.238.18]) by Xerox.COM ; 01 MAR 90 11:49:02 PST Return-Path: Received: by boulder.Colorado.EDU (cu-hub.890824) Received: by newsigi.colorado.edu (cu.generic.890828) From: Andreas Girgensohn Message-Id: <9003011948.AA03478@newsigi.colorado.edu> Subject: Bug in Mike Thome's Enhancement To: CommonLoops.PA@Xerox.COM (PCL Mailing List) Date: Thu, 1 Mar 90 12:48:50 MDT X-Mailer: ELM [version 2.2 PL0] I found a bug in the enhancement for Genera, here is a fix: Andreas Girgensohn andreasg@boulder.colorado.edu ;;; genera-low.lisp (defun pcl-fdefine-helper (gspec qualifiers specializers fn) (let* ((dlist (scl:debugging-info fn)) (class (cadr (assoc 'pcl-method-class dlist))) (doc (cadr (assoc 'pcl-documentation dlist))) (llist (cadr (assoc 'pcl-lambda-list dlist))) (plist (cadr (assoc 'pcl-plist dlist)))) (load-defmethod (or class 'standard-method) gspec qualifiers specializers llist ; was: (arglist fn) doc (getf plist :isl-cache-symbol) plist fn))) Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18408; Sun, 4 Mar 90 15:31:26 -0800 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Sun 4 Mar 90 17:28:32-CST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 754574; 4 Mar 90 18:28:02 EST Date: Sun, 4 Mar 90 18:28 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: Common-Lisp-Object-System@MCC.COM Message-Id: <19900304232802.8.MOON@EUPHRATES.SCRC.Symbolics.COM> I've noticed that the CLOS standard consists of three parts, only one of which is becoming an actual standard, and I want to do something about it. The three parts are: the stuff that's being standardized in ANSI CL (basically the 88-002R report as amended by later X3J13 actions), the basic metaobject stuff that everyone has to have for internal reasons anyway, and the blue-sky metaobject stuff that isn't really figured out yet, which allows you to do hairy things like use CLOS to build entirely new object systems. What concerns me is that the lack of progress on the third part has caused an unnecessary failure of standardization of the second part. I believe the second part is pretty important for a number of programs, including CLIM and applications based on CLIM. What I'd like to do about this is to create a de facto standard by having everyone agree on the names to use for this basically non-controversial stuff. This would not be so much a standard as simply people agreeing not to become inconsistent for no reason. Programs written using these features would not be fully ANSI Common Lisp compliant, but in practice would be moderately portable if most CLOS implementations agree on a de facto standard. The full CLOS metaobject facility provides a model of the system that can be used both for introspection (a program examining its own structure) and for extension (changing the behavior of metaobjects and implementation of new object-oriented languages within the CLOS framework). What is being proposed here is only introspection. While extension is useful and needed, it is clearly more difficult and not as ready for standardization as introspection, so it will have to wait until later. What Symbolics and Lucid have both done is to go through the 89-003 report (Gregor's draft proposal for metaobjects) and use the names proposed there for anything that seems to make sense to standardize on at this time, while skipping over anything that looks like it is not really figured out yet, and leaving out everything that is not needed to do just introspection. We'd like to propose this set of names with these spellings as at least a starting point for a de facto standard. Symbolics uses these names both in Genera 8.0 CLOS and in Cloe 3.0 CLOS (neither of which is released yet, but will be soon). Genera runs on Symbolics 3600 and Ivory hardware, Cloe runs on Intel 386 hardware. Lucid uses these names in the upcoming Lucid 4.0 release (now in Beta test on SUN hardware). Both Symbolics and Lucid have a few slight differences from this proposal in their upcoming releases, because the releases had to be frozen before the proposal was finished; those differences are noted below. I'd like to get other CLOS implementors, in addition to Lucid and Symbolics, involved in this informal standard. For now we are only proposing names, not precise definitions of what they do. The definitions will be necessary, but they are a lot of work so we'll do that later, after we see whether it is possible to agree on the names. At Symbolics we came up with three packages (COMMON-LISP, CLOS, and CLOS-INTERNALS). COMMON-LISP is the package whose contents is defined by ANSI Common Lisp. CLOS is the package that exports all the "standardized" symbols of CLOS, not only the ones defined by ANSI Common Lisp but also some others that make sense to standardize on in a de facto way. The idea is that a program can :USE CLOS in its DEFPACKAGE, or use CLOS: package prefixes throughout the program, to get the CLOS facilities that one would expect to be portable to other implementations. The name and existence of the CLOS package is part of the proposed de facto standard. CLOS-INTERNALS exports the things that we might want wizardly users and our own tools to use, but that are not being proposed for standardization. Things in CLOS-INTERNALS are not necessarily compatible even among Symbolics' own various implementations and are not being proposed as a standard. There's no need even to agree on the name of that package; indeed, Lucid does not use that particular package name. Exporting the ANSI Common Lisp standardized symbols of CLOS from the package named CLOS facilitates using CLOS in programs that are otherwise written using the CLtL dialect rather than the ANSI dialect. I believe the policy we're working from can be succinctly stated as "exports from the CLOS package are all and only those symbols which are the current (draft proposed) ANSI standard CLOS or seem likely to be recommended for future ANSI standardization." The remainder of this message lists the proposed external symbols of the CLOS package, in three parts. The first part is a list of the extensions to standardized CLOS being proposed at this time. The second part is a list of additional extensions that only apply to Common Lisps that support locatives. That list is being proposed at this time, but does not apply to most Common Lisp implementations; these symbols would only exist in implementations that actually have locatives. The third part is a list of the symbols in standardized CLOS, for completeness. NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: CLASS-DEFAULT-INITARGS CLOS generic function CLASS-DIRECT-DEFAULT-INITARGS CLOS generic function CLASS-DIRECT-SLOTS CLOS generic function CLASS-DIRECT-SUBCLASSES CLOS generic function CLASS-DIRECT-SUPERCLASSES CLOS generic function CLASS-PRECEDENCE-LIST CLOS generic function CLASS-PROTOTYPE CLOS generic function CLASS-SLOTS CLOS generic function COMPUTE-EFFECTIVE-METHOD CLOS generic function FORWARD-REFERENCED-CLASS class name FUNCALLABLE-STANDARD-CLASS class name GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER CLOS generic function GENERIC-FUNCTION-DECLARATIONS CLOS generic function GENERIC-FUNCTION-INITIAL-METHODS CLOS generic function GENERIC-FUNCTION-LAMBDA-LIST CLOS generic function GENERIC-FUNCTION-METHOD-CLASS CLOS generic function GENERIC-FUNCTION-METHOD-COMBINATION CLOS generic function GENERIC-FUNCTION-METHODS CLOS generic function GENERIC-FUNCTION-NAME CLOS generic function METHOD-FUNCTION CLOS generic function METHOD-GENERIC-FUNCTION CLOS generic function METHOD-LAMBDA-LIST CLOS generic function METHOD-SLOT-NAME CLOS generic function METHOD-SPECIALIZERS CLOS generic function SLOT-BOUNDP-USING-CLASS CLOS generic function SLOT-DEFINITION class name SLOT-DEFINITION-ALLOCATION CLOS generic function SLOT-DEFINITION-INITARGS CLOS generic function SLOT-DEFINITION-INITFORM CLOS generic function SLOT-DEFINITION-INITFUNCTION CLOS generic function SLOT-DEFINITION-NAME CLOS generic function SLOT-DEFINITION-READERS CLOS generic function SLOT-DEFINITION-TYPE CLOS generic function SLOT-DEFINITION-WRITERS CLOS generic function SLOT-EXISTS-P-USING-CLASS CLOS generic function SLOT-MAKUNBOUND-USING-CLASS CLOS generic function SLOT-VALUE-USING-CLASS CLOS generic function, SETFable, LOCFable SPECIALIZER-DIRECT-GENERIC-FUNCTIONS CLOS generic function SPECIALIZER-DIRECT-METHODS CLOS generic function STANDARD-ACCESSOR-METHOD class name STANDARD-READER-METHOD class name STANDARD-SLOT-DEFINITION class name STANDARD-WRITER-METHOD class name Notes: The CLASS-xxx accessors always work, no explicit "finalize" is required. We're not sure whether this is a change from 89-003 or not. Using SETF with any of these names not indicated to be SETFable should signal an error. The following symbols are exported from the CLOS package by both Symbolics and Lucid, but are not being proposed for a standard at this time, for the reasons given: CLASS-DIRECT-METHODS use SPECIALIZER-DIRECT-METHODS CLASS-FINALIZED-P not needed for introspection COMPUTE-CLASS-PRECEDENCE-LIST use CLASS-PRECEDENCE-LIST SPECIALIZER-DIRECT-METHODS is more general than CLASS-DIRECT-METHODS. COMPUTE-CLASS-PRECEDENCE-LIST is needed for extension, where users define new methods for it to implement different CPL rules, but for introspection it is just a slower version of CLASS-PRECEDENCE-LIST. Lucid's CLOS package exports several additional symbols as well: LIST-ALL-CLASSES, TRACE-METHOD, UNDEFMETHOD, UNTRACE-METHOD. These are not being proposed for standardization right now. Symbolics' CLOS package exports several additional symbols as well: CLASS-DEFAULT-DIRECT-SUPERCLASSES, DIRECT-SLOT-DEFINITION, EFFECTIVE-SLOT-DEFINITION, STANDARD-DIRECT-CLASS-SLOT-DEFINITION, STANDARD-DIRECT-SLOT-DEFINITION, STANDARD-EFFECTIVE-SLOT-DEFINITION, STRUCTURE-DIRECT-SLOT-DEFINITION, STRUCTURE-EFFECTIVE-SLOT-DEFINITION, STRUCTURE-SLOT-DEFINITION. These are not being proposed for standardization right now. NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE, ONLY IN COMMON LISP IMPLEMENTATIONS THAT HAVE LOCATIVES: SLOT-DEFINITION-LOCATORS CLOS generic function STANDARD-LOCATOR-METHOD class name Notes: These names are only meaningful in implementations that have the "locatives" extension, and would not exist in other implementations. They do not exist in Symbolics Cloe, nor in Lucid. Where a function is listed as "LOCFable", that attribute only applies in implementations that have the "locatives" extension. ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: While we're at it, I might as well include this list of the symbols that Symbolics thinks are defined by the CLOS standard. These are all the symbols with pages in chapter 2 of 88-002R, plus other symbols that are mentioned in 88-002R with the apparent intention of being part of the standard, plus several symbols added by later X3J13 actions. Note that neither Symbolics or Lucid has implemented GENERIC-FLET, GENERIC-FUNCTION as a special form, GENERIC-LABELS, and WITH-ADDED-METHODS in their current implementations. Lucid also has not yet implemented DEFINE-METHOD-COMBINATION. The other missing global definitions are because the standard specifies only a local definition for those symbols. I think a careful reading will also show that the implementation from which this table was generated has not yet implemented a couple of specified condition types. Lucid exports all of the symbols listed here except for MAKE-LOAD-FORM and MAKE-LOAD-FORM-SAVING-SLOTS, which are not implemented yet. (A few others are only exported by a last-minute patch to the Lucid 4.0.0 Beta-1 version.) ADD-METHOD CLOS generic function ALLOCATE-INSTANCE CLOS generic function BUILT-IN-CLASS class name CALL-METHOD ***No global definition found*** CALL-NEXT-METHOD ***No global definition found*** CHANGE-CLASS CLOS generic function CLASS class name CLASS-NAME CLOS generic function, SETFable CLASS-OF function COMPUTE-APPLICABLE-METHODS CLOS generic function DEFCLASS macro DEFGENERIC macro DEFINE-METHOD-COMBINATION macro DEFMETHOD macro DESCRIBE-OBJECT CLOS generic function DOCUMENTATION CLOS generic function, SETFable ENSURE-GENERIC-FUNCTION function FIND-CLASS function, SETFable FIND-METHOD CLOS generic function FUNCTION-KEYWORDS CLOS generic function GENERIC-FLET ***No global definition found*** GENERIC-FUNCTION class name GENERIC-LABELS ***No global definition found*** INITIALIZE-INSTANCE CLOS generic function INVALID-METHOD-ERROR function MAKE-INSTANCE CLOS generic function MAKE-INSTANCES-OBSOLETE CLOS generic function MAKE-LOAD-FORM CLOS generic function MAKE-LOAD-FORM-SAVING-SLOTS function MAKE-METHOD ***No global definition found*** METHOD class name METHOD-COMBINATION class name, DOCUMENTATION type METHOD-COMBINATION-ERROR function METHOD-QUALIFIERS CLOS generic function NEXT-METHOD-P ***No global definition found*** NO-APPLICABLE-METHOD CLOS generic function NO-NEXT-METHOD CLOS generic function PRINT-OBJECT CLOS generic function REINITIALIZE-INSTANCE CLOS generic function REMOVE-METHOD CLOS generic function SETF macro, DOCUMENTATION type SHARED-INITIALIZE CLOS generic function SLOT-BOUNDP function SLOT-EXISTS-P function SLOT-MAKUNBOUND function SLOT-MISSING CLOS generic function SLOT-UNBOUND CLOS generic function SLOT-VALUE function, SETFable, LOCFable STANDARD CLOS method-combination STANDARD-CLASS class name STANDARD-GENERIC-FUNCTION class name STANDARD-METHOD class name STANDARD-OBJECT class name STRUCTURE-CLASS class name STRUCTURE-OBJECT class name SYMBOL-MACROLET special form UPDATE-INSTANCE-FOR-DIFFERENT-CLASS CLOS generic function UPDATE-INSTANCE-FOR-REDEFINED-CLASS CLOS generic function WITH-ACCESSORS macro WITH-ADDED-METHODS ***No global definition found*** WITH-SLOTS macro Notes: ALLOCATE-INSTANCE did not get its own page in 88-002R, but (some of) the authors of that document say that was simply a mistake. At this point there should probably be an X3J13 cleanup to clarify that ALLOCATE-INSTANCE is part of the language. Note that LOAD-OBJECTS:MAKE-LOAD-FORM assumes the existence of ALLOCATE-INSTANCE and that user-written MAKE-LOAD-FORM methods that return two values will typically use ALLOCATE-INSTANCE in the first value. The symbol ALLOCATE-INSTANCE is not exported from the CLOS package by Genera 8.0, but it is exported by Lucid. The lack of export in Genera is just a bug. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21776; Sun, 4 Mar 90 21:52:37 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 04 MAR 90 21:52:18 PST Return-Path: Redistributed: CommonLoops.pa Received: from carame.ecn.purdue.edu ([128.46.150.152]) by Xerox.COM ; 04 MAR 90 21:51:10 PST Received: by carame.ecn.purdue.edu (5.61/1.19jrs) id AA06523; Mon, 5 Mar 90 00:51:18 -0500 Received: from Version.6.23.N.CUILIB.3.44.SNAP.NOT.LINKED.carame.ecn.purdue.edu.Unknown.Machine.Type via MS.5.5.carame.ecn.purdue.edu.sun3_35; Mon, 5 Mar 90 00:51:15 -0500 (EST) Message-Id: Date: Mon, 5 Mar 90 00:51:15 -0500 (EST) From: William R Burdick To: CommonLoops.pa@Xerox.COM Subject: mailing list Please remove me from this mailing list. -- Bill Burdick burdick@cello.ecn.purdue.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29379; Mon, 5 Mar 90 04:37:54 -0800 Received: from PinotNoir.ms by ArpaGateway.ms ; 05 MAR 90 04:33:29 PST Sender: "MAZIERE_TAURAN_CHRISTOPHE.CBVMANRXF"@Xerox.COM Date: 5 Mar 90 04:26:56 PST (Monday) Subject: Rainy day on XNS server From: "MAZIERE_TAURAN_CHRISTOPHE.CBVMANRXF"@Xerox.COM To: Gregor.PA@Xerox.COM Cc: CommonLoops.PA@Xerox.COM Message-Id: <900305-043329-9611@Xerox> Hi, We have many problems to obtain the new version of PCL through the bitftp method. I have got 5 Parts of the Uuencoded tarfile (Part 19, 14, 7, 2, 16) but after this I have received an Email from CINSupport:All Areas:Xerox which said: "Do not request files from Arpa Internet archive servers because the Xerox CIN transatlantic lines and mail servers do not have the capacity to handle the huge tarfiles You requested. Please find a way to obtain the files you want directly in Europe without going through the Xerox Arpanet gateway". Could it be possible to put the Rainy Day release on {NB:Parc:Xerox} ( source code and DFASL) ? Christophe Maziere-Tauran Rank Xerox France. Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01098; Mon, 5 Mar 90 09:38:48 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01054; Mon, 5 Mar 90 09:37:59 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01023; Mon, 5 Mar 90 09:37:36 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01007; Mon, 5 Mar 90 09:37:27 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00991; Mon, 5 Mar 90 09:37:20 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00975; Mon, 5 Mar 90 09:37:13 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00966; Mon, 5 Mar 90 09:37:08 -0800 Received: from arisia.Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00956; Mon, 5 Mar 90 09:37:00 -0800 Received: from Xerox.COM by arisia with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00944; Mon, 5 Mar 90 09:36:53 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAR 90 08:03:10 PST Return-Path: Redistributed: CommonLoops.pa Received: from watstat.waterloo.edu ([129.97.129.33]) by Xerox.COM ; 05 MAR 90 07:52:20 PST Received: by watstat.waterloo.edu id ; Mon, 5 Mar 90 10:52:08 EST Date: Mon, 5 Mar 90 10:52:08 EST From: Greg Anglin Message-Id: <9003051552.AA21037@watstat.waterloo.edu> To: CommonLoops.pa@Xerox.COM Subject: generic fcn describe in Rainy Daay I have successfully compiled Rainy Day PCL in Coral Allegro CL 1.2.2 (not 1.3). Everything seems to work just fine except for generic function describe: ? (defclass foo () ((bar :accessor bar :initarg :bar))) # ? (defmethod describe ((f foo)) (format t "~&BAR ~S" (bar f)) (values)) > Error: DESCRIBE already names an ordinary function or a macro, you may want to replace it with a generic function, but doing so will require that you decide what to do with the existing function definition. The PCL-specific function MAKE-SPECIALIZABLE may be useful to you. > While executing: PCL::GENERIC-CLOBBERS-FUNCTION > Type Command-/ to continue, Command-. to abort. 1 > With Victoria Day PCL in ACL 1.2.2 I had no difficulty with describe. Has there been a change in the specification, or is this just a problem with the antiquated ACL I'm using? Thanks, Greg Anglin (dganglin@watstat.waterloo.edu) Department of Statistics and Actuarial Science University of Waterloo Waterloo, ON N2L 3G1 Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13066; Mon, 5 Mar 90 14:34:52 -0800 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 5 Mar 90 16:31:29-CST Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA13289g; Mon, 5 Mar 90 14:29:42 PST Received: by challenger id AA21743g; Mon, 5 Mar 90 14:30:30 PST Date: Mon, 5 Mar 90 14:30:30 PST From: David Gray Message-Id: <9003052230.AA21743@challenger> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@MCC.COM, McCreary@dsg.csc.ti.com In-Reply-To: David A. Moon's message of Sun, 4 Mar 90 18:28 EST <19900304232802.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Proposed de facto standard subset of metaobjects > What concerns me is that the lack of progress on the third part has caused an > unnecessary failure of standardization of the second part. I think there has been lack of progress on both the second and third parts (although in the case of the second part, it appears to have been due more to loss of interest than to any technical problems), but I'm glad to see an effort to get things moving again. > ... What I'd like to do about this is to create a de facto standard by > having everyone agree on the names to use for this basically > non-controversial stuff. ... Sounds like a good goal; at least, better than nothing. I still feel bad that what you call the third part is apparently being allowed to lapse into oblivion without ever being completed and without even publishing the partial results so that someone else could continue the work. > ... While extension is useful and needed, it is clearly more difficult > and not as ready for standardization as introspection, so it will have to > wait until later. Some parts are readier than others. > ... We'd like to propose > this set of names with these spellings as at least a starting point for a de > facto standard. ... I'd like > to get other CLOS implementors, in addition to Lucid and Symbolics, > involved in this informal standard. What you propose here is very similar to what has been done in release 6 of the TI Explorer. I'll comment on a couple of points here, but since I no longer work for TI and don't even have access to an Explorer now, I can't check all the details; perhaps someone at TI will do that. > At Symbolics we came up with three packages (COMMON-LISP, CLOS, and > CLOS-INTERNALS). ... The Explorer has corresponding packages COMMON-LISP, CLOS, and TICLOS. The CLOS package export list includes the symbols from chapter 3 (although many are not defined), while extensions are exported only from TICLOS. > NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: It looks like most, if not all, of these are already implemented on the Explorer, although some may have been done after release 6 (which is what is currently shipped to customers). > The CLASS-xxx accessors always work, no explicit "finalize" is required. > We're not sure whether this is a change from 89-003 or not. The Explorer requires explicit finalization for certain accessors, as specified in 88-003, since 89-003 does not say, and no one was interested in discussing the question at the time. > Lucid's CLOS package exports several additional symbols as well: > LIST-ALL-CLASSES, TRACE-METHOD, UNDEFMETHOD, UNTRACE-METHOD. These > are not being proposed for standardization right now. The Explorer has an UNDEFMETHOD macro, but it is exported from TICLOS (and TICL), not CLOS. > Symbolics' CLOS package exports several additional symbols as well: > CLASS-DEFAULT-DIRECT-SUPERCLASSES, DIRECT-SLOT-DEFINITION, > EFFECTIVE-SLOT-DEFINITION, STANDARD-DIRECT-CLASS-SLOT-DEFINITION, > STANDARD-DIRECT-SLOT-DEFINITION, STANDARD-EFFECTIVE-SLOT-DEFINITION, > STRUCTURE-DIRECT-SLOT-DEFINITION, STRUCTURE-EFFECTIVE-SLOT-DEFINITION, > STRUCTURE-SLOT-DEFINITION. These are not being proposed for standardization > right now. I believe that these were all implemented on the Explorer in the work I did after release 6. > NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE, ONLY IN > COMMON LISP IMPLEMENTATIONS THAT HAVE LOCATIVES: > SLOT-DEFINITION-LOCATORS CLOS generic function > STANDARD-LOCATOR-METHOD class name The Explorer supports locatives, but I don't recognize what these names would mean. The Explorer permits defining methods on generic functions named (LOCF SLOT-VALUE), (LOCF SLOT-VALUE-USING-CLASS), etc, by analogy to (SETF ...) generic functions. > ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE: ... > Note that neither Symbolics or Lucid has implemented GENERIC-FLET, > GENERIC-FUNCTION as a special form, GENERIC-LABELS, and WITH-ADDED-METHODS in > their current implementations. These are implemented on the Explorer, except that WITH-ADDED-METHODS is a hack that does not fully conform to the specifications (I agree that it should be removed from the standard). > Lucid also has not yet implemented DEFINE-METHOD-COMBINATION. The Explorer has this. The only obvious discrepancy I notice in the list of symbols is that the Explorer unfortunately still implements SYMBOL-MACROLET as a macro instead of a special form. > ALLOCATE-INSTANCE did not get its own page in 88-002R, but (some of) the > authors of that document say that was simply a mistake. At this point there > should probably be an X3J13 cleanup to clarify that ALLOCATE-INSTANCE is part > of the language. I agree. > ... The symbol ALLOCATE-INSTANCE is not exported from the CLOS package > by Genera 8.0, > but it is exported by Lucid. The lack of export in Genera is just a bug. It is exported from the Explorer's CLOS package. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13209; Mon, 5 Mar 90 14:45:16 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 05 MAR 90 12:04:00 PST Return-Path: Redistributed: commonloops.pa Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 05 MAR 90 11:36:00 PST Received: by ames.arc.nasa.gov (5.61/1.2); Mon, 5 Mar 90 11:36:03 -0800 Received: from herald. by ntmtv.com (3.2/SMI-3.2) id AA24108; Mon, 5 Mar 90 11:24:54 PST Received: by herald. (4.0/SMI-4.0) id AA06288; Mon, 5 Mar 90 11:23:13 PST From: irvine%ntmtv.uucp@ames.arc.nasa.gov (Chuck Irvine) Message-Id: <9003051923.AA06288@herald.> Date: Mon, 05 Mar 90 11:18:42 PST Subject: latest available meta object docs and rainy day correspondence To: commonloops.pa@Xerox.COM Is the latest version of the meta object documentation available on a server and to what extent does "rainy day" pcl correspond to the meta object specification. Also, how firm is the the current meta object spec? Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13350; Mon, 5 Mar 90 14:49:56 -0800 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Mon 5 Mar 90 16:43:27-CST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 755509; 5 Mar 90 17:42:08 EST Date: Mon, 5 Mar 90 17:42 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: David Gray Cc: Common-Lisp-Object-System@MCC.COM, McCreary@dsg.csc.ti.com In-Reply-To: <9003052230.AA21743@challenger> Message-Id: <19900305224201.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 5 Mar 90 14:30:30 PST From: David Gray Thanks for the Explorer information, and I hope that someone from TI will confirm or correct it. I only have access to Explorer release 5, not release 6, right now, so I haven't been able to check myself what names were chosen in TI-CLOS. One clarification: > NON-ANSI-STANDARD SYMBOLS EXPORTED BY THE CLOS PACKAGE, ONLY IN > COMMON LISP IMPLEMENTATIONS THAT HAVE LOCATIVES: > SLOT-DEFINITION-LOCATORS CLOS generic function > STANDARD-LOCATOR-METHOD class name The Explorer supports locatives, but I don't recognize what these names would mean. The Explorer permits defining methods on generic functions named (LOCF SLOT-VALUE), (LOCF SLOT-VALUE-USING-CLASS), etc, by analogy to (SETF ...) generic functions. SLOT-DEFINITION-LOCATORS is like SLOT-DEFINITION-WRITERS, and STANDARD-LOCATOR-METHOD is like STANDARD-WRITER-METHOD, except that they involve functions named (LOCF reader) instead of functions named (SETF reader). These probably exist in TI-CLOS, although I don't know whether they have the same names spelled the same way. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14583; Mon, 5 Mar 90 15:45:56 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 05 MAR 90 14:54:38 PST Return-Path: <@CUNYVM.CUNY.EDU:BALL@YALEMED.BITNET> Redistributed: commonloops.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 05 MAR 90 14:52:22 PST Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9398; Mon, 05 Mar 90 17:50:53 EST Date: Mon, 5 Mar 90 17:52 EST From: Subject: number of allowabke To: commonloops.PA@Xerox.COM X-Original-To: commonloops.PA@Xerox.COM, BALL Message-Id: <900305-145438-11857@Xerox> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14672; Mon, 5 Mar 90 15:49:30 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 05 MAR 90 15:06:35 PST Return-Path: <@CUNYVM.CUNY.EDU:BALL@YALEMED.BITNET> Redistributed: commonloops.PA Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 05 MAR 90 15:01:49 PST Received: from YALEMED.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 9518; Mon, 05 Mar 90 18:00:09 EST Date: Mon, 5 Mar 90 18:01 EST From: Subject: number of allowable classes To: commonloops.PA@Xerox.COM X-Original-To: commonloops.PA@Xerox.COM, BALL Message-Id: <900305-150635-11901@Xerox> Is there a limit to the number of classes allowable in Rainy Day PCL? I cannot seem to make an instance of class #1037 when Rainy Day PCL is compiled under Allegro COMMON LISP 1.3.1. The class seems to be created OK, but make-instance when called to make an instance of the class seems to go into an infinite loop. Make-instance works fine on class #1036. ? (room) There are at least 2443736 bytes of available RAM. ? *classes* 1036 ? (defclass class1037 (standard-object) ()) # ? (make-instance (class-object 'class1037)) Aborted ? Any suggestions? S. Ball Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15024; Mon, 5 Mar 90 16:05:10 -0800 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 5 Mar 90 17:16:57-CST Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA13635g; Mon, 5 Mar 90 15:15:28 PST Received: by challenger id AA21835g; Mon, 5 Mar 90 15:16:16 PST Date: Mon, 5 Mar 90 15:16:16 PST From: David Gray Message-Id: <9003052316.AA21835@challenger> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@MCC.COM, McCreary@dsg.csc.ti.com In-Reply-To: David A. Moon's message of Mon, 5 Mar 90 17:42 EST <19900305224201.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Proposed de facto standard subset of metaobjects > SLOT-DEFINITION-LOCATORS is like SLOT-DEFINITION-WRITERS, and > STANDARD-LOCATOR-METHOD is like STANDARD-WRITER-METHOD, except > that they involve functions named (LOCF reader) instead of > functions named (SETF reader). > These probably exist in TI-CLOS, although I don't know whether they > have the same names spelled the same way. Oh, I see. No, the Explorer doesn't have these because locatives don't have a DEFCLASS slot option comparable to :READER and :WRITER; an explicit DEFMETHOD using (LOCF (SLOT-VALUE ...)) would be required. Since few people use locatives, I don't think it would be worthwhile for :ACCESSOR to imply automatically creating a LOCF method as well as a SETF method. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15492; Mon, 5 Mar 90 16:32:39 -0800 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Mon 5 Mar 90 18:28:49-CST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 755599; 5 Mar 90 19:28:10 EST Date: Mon, 5 Mar 90 19:28 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: David Gray Cc: Common-Lisp-Object-System@MCC.COM, McCreary@dsg.csc.ti.com In-Reply-To: <9003052316.AA21835@challenger> Message-Id: <19900306002818.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 5 Mar 90 15:16:16 PST From: David Gray the Explorer doesn't have these because locatives don't have a DEFCLASS slot option comparable to :READER and :WRITER; an explicit DEFMETHOD using (LOCF (SLOT-VALUE ...)) would be required. Since few people use locatives, I don't think it would be worthwhile for :ACCESSOR to imply automatically creating a LOCF method as well as a SETF method. The way we did it, :ACCESSOR does what the CLOS standard says, and if you want a LOCF method, you have to use :LOCATOR (an extension to the language). I agree that locatives are not heavily used. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28093; Thu, 8 Mar 90 04:14:08 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 07 MAR 90 11:33:41 PST Return-Path: Redistributed: commonloops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 07 MAR 90 11:29:03 PST Received: by mcsun.EU.net via EUnet; Wed, 7 Mar 90 18:47:19 +0100 (MET) Received: from prl.philips.co.uk by kestrel.Ukc.AC.UK with UUCP id aa06800; 7 Mar 90 17:24 GMT Received: from apollo10.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 7 Mar 90 17:11:44 gmt From: Ashok Gupta Date: Wed, 7 Mar 90 17:12:09 utc Message-Id: <387.9003071712@apollo10.prl.philips.co.uk> To: commonloops.pa@Xerox.COM, irvine%ntmtv.uucp@relay.eu.net Subject: Re: a problem with From: irvine (Chuck Irvine) Date: Wed, 28 Feb 90 14:21:43 PST I'm having some trouble with the "bitftp" procedure for getting the pcl sources. Can anyone help? ... I did succeed in getting the proper mail files and uudecoding them. I assume that the file resulting from "uudecode" is not compressed as that is what the "uncompress" command says when trying to uncompress it. The real problem occurs when I try to untar the tar file. After successfully extracting all of the "text" files, e.g. 12-7-88-notes.text, the tar command encounters a checksum error when it trys to extract the first "lisp" file, boot.lisp. I'm having exactly the same problem. Anyone able to help ? Ash Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14531; Thu, 8 Mar 90 13:43:57 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 07 MAR 90 14:11:21 PST Return-Path: Redistributed: CommonLoops.PA Received: from fs3.cs.rpi.edu ([128.213.4.10]) by Xerox.COM ; 07 MAR 90 14:07:57 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA10910; Wed, 7 Mar 90 17:05:54 EST Date: Wed, 7 Mar 90 17:05:20 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA10337; Wed, 7 Mar 90 17:05:20 EST Message-Id: <9003072205.AA10337@turing.cs.rpi.edu> To: CommonLoops.PA@Xerox.COM Subject: some fixes for Rainy Day PCL Here are some fixes for "2/16/90 Rainy Day PCL (beta 3)". Rick Harris ==================== Problem: generic-functions which come from early-generic-functions are unnamed. boot.lisp fix-early-generic-functions Change: (when noisyp (format t "trampoline...")) (fix-structure early-gf) (when noisyp (format t "fixed...")) ! (apply #'initialize-instance early-gf default-initargs) (dolist (early-method early-methods) To: (when noisyp (format t "trampoline...")) (fix-structure early-gf) (when noisyp (format t "fixed...")) ! (apply #'initialize-instance early-gf ! :name early-gf-spec default-initargs) (dolist (early-method early-methods) ==================== Problem: compute-primary-cache-location dies when there are no wrappers. cache.lisp compute-primary-cache-location Change: (defun compute-primary-cache-location (field mask wrappers) ! (if (not (consp wrappers)) (logand mask (wrapper-ref wrappers field)) (let ((location 0)) To: (defun compute-primary-cache-location (field mask wrappers) ! (if (not (listp wrappers)) (logand mask (wrapper-ref wrappers field)) (let ((location 0)) ==================== Problem: raise-metatype should return T only when the specializer is T. raise-metatype does not recognize specializers having non-standard metaclasses. cache.lisp raise-metatype Change: (class-of (class-of (eql-specializer-object x))) (class-of x)))) (cond ((eq x *the-class-t*) t) ! ((eq meta-specializer standard) 'standard-instance) ! ((eq meta-specializer fsc) 'standard-instance) ! ; ((eq meta-specializer structure) 'structure-instance) ! ((eq meta-specializer built-in) 'built-in-instance) ! (t 't))))) To: (class-of (class-of (eql-specializer-object x))) (class-of x)))) (cond ((eq x *the-class-t*) t) ! ((*subtypep meta-specializer standard) 'standard-instance) ! ((*subtypep meta-specializer fsc) 'standard-instance) ! ; ((*subtypep meta-specializer structure) 'structure-instance) ! ((*subtypep meta-specializer built-in) 'built-in-instance) ! (t (error "PCL can not handle the specializer ~S~ ! (meta-specializer ~S)" new-specializer meta-specializer)))))) ==================== Problem: accessor-miss causes performance problems Date: Mon, 26 Feb 90 11:05 PST From: Gregor.pa@Xerox.COM The following patch, to Rainy Day PCL, fixes a problem which, in some programs, can cause serious performance problems. You should make this patch right away. dfun.lisp accessor-miss Change: (cond ((null nfunction) (no-applicable-method gf args)) ((or invalidp (null nindex)) (apply nfunction args)) To: (cond ((null nfunction) (no-applicable-method gf args)) + ((null ntype) + (checking) + (apply nfunction args)) ((or invalidp (null nindex)) (apply nfunction args)) ==================== Problem: Method calls without enough required arguments cause trouble. compute-applicable-methods seems to be a good place to handle this problem. methods.lisp compute-applicable-methods Change: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (every #'specializer-applicable-p (method-specializers method) arguments)) (sorter (method-1 method-2) To: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (let ((arguments-tail arguments)) ! (dolist (m-spec (method-specializers method) t) ! (unless arguments-tail ! (error "The function ~S requires at least ~D arguments" ! (generic-function-name generic-function) ! (length (gf-arg-info generic-function)))) ! (unless (specializer-applicable-p m-spec (pop arguments-tail)) ! (return nil))))) (sorter (method-1 method-2) compute-applicable-methods Change: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (every #'specializer-applicable-p (method-specializers method) arguments)) (sorter (method-1 method-2) To: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (let ((arguments-tail arguments)) ! (dolist (m-spec (method-specializers method) t) ! (unless arguments-tail ! (error "The function ~S requires at least ~D arguments" ! (generic-function-name generic-function) ! (length (gf-arg-info generic-function)))) ! (unless (specializer-applicable-p m-spec (pop arguments-tail)) ! (return nil))))) (sorter (method-1 method-2) init.lisp make-instance Change: (compute-applicable-methods #'shared-initialize ! (list (class-prototype class))))))) To: (compute-applicable-methods #'shared-initialize ! (list (class-prototype class) t)))))) reinitialize-instance Change: (compute-applicable-methods #'shared-initialize ! (list instance)))))) To: (compute-applicable-methods #'shared-initialize ! (list instance nil)))))) update-instance-for-different-class Change: (compute-applicable-methods #'shared-initialize ! (list current))))) To: (compute-applicable-methods #'shared-initialize ! (list current nil))))) ; nil? update-instance-for-redefined-class (compute-applicable-methods #'shared-initialize ! (list instance))))) To: (compute-applicable-methods #'shared-initialize ! (list instance added-slots))))) ==================== Problem: Uncompiled discriminating functions can cause problems. methods.lisp compute-discriminating-function Change: (defmethod compute-discriminating-function ((gf standard-generic-function)) (let* ((state (gf-dfun-state gf)) ! (dfun (cond ((null state) (make-initial-dfun gf)) ! ((consp state) (car state)) ! (t state)))) (doctor-dfun-for-the-debugger gf dfun))) To: (defmethod compute-discriminating-function ((gf standard-generic-function)) (let* ((state (gf-dfun-state gf)) ! (dfun (typecase state ! (null (make-initial-dfun gf)) ! (function state) ! (cons (car state))))) (doctor-dfun-for-the-debugger gf dfun))) Change: (defun update-dfun (generic-function dfun &optional cache) (let ((ostate (gf-dfun-state generic-function))) ! (when (consp ostate) (free-cache (cdr ostate))) (setf (gf-dfun-state generic-function) (if cache (cons dfun cache) dfun)) (invalidate-dfun-internal generic-function))) To: (defun update-dfun (generic-function dfun &optional cache) (let ((ostate (gf-dfun-state generic-function))) ! (unless (typep ostate '(or null function)) (free-cache (cdr ostate))) (setf (gf-dfun-state generic-function) (if cache (cons dfun cache) dfun)) (invalidate-dfun-internal generic-function))) Change: (defun invalidate-discriminating-function (generic-function) (let ((ostate (gf-dfun-state generic-function))) ! (when (consp ostate) (free-cache (cdr ostate))) (setf (gf-dfun-state generic-function) nil) (invalidate-dfun-internal generic-function))) To: (defun invalidate-discriminating-function (generic-function) (let ((ostate (gf-dfun-state generic-function))) ! (unless (typep ostate '(or null function)) (free-cache (cdr ostate))) (setf (gf-dfun-state generic-function) nil) (invalidate-dfun-internal generic-function))) ==================== Problem: Some compilers complain when variables declared to be of type (vector t) are initially bound to nil. plap.lisp lap-reg-initial-value-form Change: (defun lap-reg-initial-value-form (reg) (cond ((member reg *lap-i-regs*) 0) ! ((member reg *lap-v-regs*) nil) ((member reg *lap-t-regs*) nil) (t (error "What kind of register is ~S?" reg)))) To: + (defconstant *empty-vector* '#()) + (defun lap-reg-initial-value-form (reg) (cond ((member reg *lap-i-regs*) 0) ! ((member reg *lap-v-regs*) '*empty-vector*) ((member reg *lap-t-regs*) nil) (t (error "What kind of register is ~S?" reg)))) vector.lisp add-pv-binding Change: (gather t metatypes)))) `((let ((.ISL. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) ! (.PV. nil) ,@(remove nil slot-variables)) (declare ,(make-isl-type-declaration '.ISL.) To: (gather t metatypes)))) `((let ((.ISL. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) ! (.PV. *empty-vector*) ,@(remove nil slot-variables)) (declare ,(make-isl-type-declaration '.ISL.) ==================== Problem: do-standard-defsetf-1 for KCL causes setf forms to evaluate its arguments in the wrong order. defs.lisp do-standard-defsetf-1 Change: #+kcl (let ((helper (gensym))) - ;; - ;; KCL's setf macro generates better code when setf methods are - ;; defined by (defsetf x y) than when they are defined by the - ;; long form of defsetf or by define-setf-method. - ;; (setf (macro-function helper) ! #'(lambda (form env &aux (args (cdr form))) (declare (ignore env)) ! `(,setf-function-name ,(car (last args)) ,@(butlast args)))) (eval `(defsetf ,function-name ,helper))) To: #+kcl (let ((helper (gensym))) (setf (macro-function helper) ! #'(lambda (form env) (declare (ignore env)) ! (let* ((loc-args (butlast (cdr form))) ! (bindings (mapcar #'(lambda (x) `(,(gensym) ,x)) loc-args)) ! (vars (mapcar #'car bindings))) ! `(let ,bindings ! (,setf-function-name ,(car (last form)) ,@vars))))) (eval `(defsetf ,function-name ,helper))) ==================== Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01702; Thu, 8 Mar 90 19:43:15 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 08 MAR 90 13:19:16 PST Return-Path: <@RIVERSIDE.SCRC.Symbolics.COM:peter@skywalker.ENTERPRISE.dialnet.symbolics.com> Redistributed: commonloops.pa Received: from RIVERSIDE.SCRC.Symbolics.COM ([128.81.41.21]) by Xerox.COM ; 08 MAR 90 13:17:08 PST Received: from skywalker.ENTERPRISE.dialnet.symbolics.com (DIAL|4413563792) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 431464; 8 Mar 90 16:15:27 EST Date: Thu, 8 Mar 90 17:39 0000 From: Peter Magee Reply-To: pt_magee@vax.acs.open.ac.uk Subject: EuroPAL Announcement To: commonloops.pa%xerox.com@RIVERSIDE.SCRC.SYMBOLICS.COM, slug%ai.sri.com@RIVERSIDE.SCRC.SYMBOLICS.COM Fcc: SKYWALKER:>PETER>outgoing.mail.newest Message-Id: <19900308173917.2.PETER@skywalker.ENTERPRISE.dialnet.symbolics.com> Europal 90 On Monday 26th March the first European Conference on the Practical Application of Lisp, Europal 90, will be held at Churchill College, Cambridge, UK. With twelve keynote and invited speakers, over thirty submitted papers and three major panel sessions the event now looks set to become a landmark on the international conference circuit. In total, almost fifty speakers from throughout Europe, the USA and Japan have agreed to contribute to this years event. Indeed the list of distinguished keynote and invited speakers reads like a who's who in Lisp. These include Richard P. Gabriel (Lucid), Prof. Gerry Sussman (MIT), Howard Shrobe, Gregor Kiczales and Professor Masayuki Ida of Japan, Prof. Erik Sandewall (Sweden), Guiseppe Atardi (Italy), Mark Son-Bell and Luc Steels (from the Free University, Brussels and the Europal 90 conference chairman). The event will begin on Monday 26th March with a choice of 2 tutorials. The first tutorial is entitled Introduction to Common Lisp and Object-Oriented Programming and will be presented by Tony Hasemer and John Domingue of the Open University. Based on their book Common Lisp Programming their experience of the problems faced by novice Lisp users is the major influence on the style and content of this course. The second tutorial is entitled The Common Lisp Object System - CLOS and is given by Gregor Kiczales from the System Sciences Laboratory at Xerox PARC. Gregor is an active member of the team that designed and developed the CLOS and is a frequent leader of these advanced tutorial sessions. There are also a number of half-day tutorials running concurrently with the main conference which begins on Tuesday, 27th March with an opening address by the conference organiser David Lloyd and the conference chairman, Luc Steels. This will be followed by a keynote address by Richard P. Gabriel entitled Lisp: Good News, Bad News, and How to Win Big! The conference then splits into 2 parallel tracks for the rest of the conference until the final keynote address on Thursday afternoon. This will be given by Prof. Gerry Sussman and is entitled Intelligence in Scientific Computing. Europal'90 is aimed at the entire Lisp community and a great deal of excitement has been generated by this first ever opportunity to focus on the capabilities of Lisp and the ways in which it is being developed for the 1990's. This conference is designed to present the practical issues concerned with the delivery of Lisp-based applications and with particular emphasis on Lisp as the foremost language for object-oriented programming. For details on how to book for the conference and tutorials, or for any information regarding the event, please contact: David Lloyd Conference Organiser Europal'90, PO Box 110 Dorking, Surrey, RH5 4FB, U.K. Phone: 44-(0)306-889485 Fax: 44-(0)306-741293 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18135; Fri, 9 Mar 90 01:24:58 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 09 MAR 90 01:24:27 PST Return-Path: Redistributed: CommonLoops.PA Received: from kwai.inria.fr ([192.5.60.25]) by Xerox.COM ; 09 MAR 90 01:23:16 PST X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; 09 Mar 90 10:24:13+0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; 09 Mar 90 10:20:57+0100 Date: 09 Mar 90 10:20:57+0100 From: Jiri Dvorak To: In-Reply-To: <9003072205.AA10337@turing.cs.rpi.edu> Subject: Re: some fixes for Rainy Day PCL & Problems with AKCL Message-Id: <642*dvorak@iam.unibe.ch> The patch for (defmethod compute-applicable-methods is given twice in the mail with the patches. Shouldn't the second be a patch for (defmethod compute-applicable-methods-using-classes ?? By the way: I haven't been able to compile Rainy Day PCL in akcl-1-465, it always crashes when loading the binary 'defs.o' (after having compiled 'defs.lisp'). The error message is a stack or heap overflow. This happens also with all the patches installed. Is this a known problem? Regards, Jiri Dvorak dvorak@iam.unibe.ch or Institute for Informatics dvorak%iam.unibe.ch@relay.cs.net University of Berne UUCP: ..!uunet!mcsun!iam.unibe.ch!dvorak Switzerland Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03408; Fri, 9 Mar 90 05:25:05 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 09 MAR 90 05:24:32 PST Return-Path: Redistributed: CommonLoops.PA Received: from funet.fi ([128.214.1.1]) by Xerox.COM ; 09 MAR 90 05:21:02 PST Received: by funet.fi; id AA29670; Fri, 9 Mar 90 15:20:33 +0200 Received: by pepper.rc.Nokia.Fi (4.0/6-mar-87) id AA24550; Fri, 9 Mar 90 15:20:05 +0200 Date: Fri, 9 Mar 90 15:20:05 +0200 From: jussila@pepper.rc.Nokia.Fi (Pekka Jussila RC 910) Message-Id: <9003091320.AA24550@pepper.rc.Nokia.Fi> To: CommonLoops.PA@Xerox.COM Subject: Redefining classes in PCL. I use PCL with Lucid Common Lisp 3.0. I have been trying to add slots into already defined PCL classes and hoping that the dynamic inheritance would cause the slots to be updated into instances created before redefining the class. This does not seem to happen without visiting the debugger first. Here are three examples to clarify the behaviour of functions slot-exists-p and slot-boundp in these situations. ---------------------------------------------------------------------- ;;; EXAMPLE 1: ;;; I try to ask the value of slot of the old instance after ;;; adding a slot into a class: > (pcl:defclass hau () ()) NIL > (setf *hau-1* (pcl:make-instance 'hau)) # > (pcl:defclass hau () ((new-slot :initarg :new-slot :initform 'new-slot))) NIL > (pcl:slot-value *hau-1* 'new-slot) >>Error: When attempting to read the slot's value (slot-value), the slot NEW-SLOT is missing from the object #. PCL:SLOT-MISSING: Required arg 0 (CLASS): # Required arg 1 (INSTANCE): # Required arg 2 (SLOT-NAME): NEW-SLOT Required arg 3 (OPERATION): PCL:SLOT-VALUE Optional arg 4 (NEW-VALUE): NIL :A 0: Abort to Lisp Top Level -> 0 Abort to Lisp Top Level Back to Lisp Top Level > (pcl:slot-value *hau-1* 'new-slot) NEW-SLOT ---------------------------------------------------------------------- ;;; EXAMPLE 2: ;;; I add another slot in the class and look, if that slot ;;; exists in the old instance and then if it is bound in it. > (pcl:defclass hau () ((new-slot :initarg :new-slot :initform 'new-slot) (other-new-slot :initarg :other-new-slot :initform 'other-new))) NIL > (pcl:slot-exists-p *hau-1* 'other-new-slot) T > (pcl:slot-boundp *hau-1* 'other-new-slot) >>Error: When attempting to test to see if slot is bound (slot-boundp), the slot OTHER-NEW-SLOT is missing from the object #. PCL:SLOT-MISSING: Required arg 0 (CLASS): # Required arg 1 (INSTANCE): # Required arg 2 (SLOT-NAME): OTHER-NEW-SLOT Required arg 3 (OPERATION): PCL:SLOT-BOUNDP Optional arg 4 (NEW-VALUE): NIL :A 0: Abort to Lisp Top Level -> 0 Abort to Lisp Top Level Back to Lisp Top Level > (pcl:slot-boundp *hau-1* 'other-new-slot) T ---------------------------------------------------------------------- ;;; EXAMPLE 3: ;;; I manage to update the instance [after adding again a ;;; new slot into the class] by printing it. > (pcl:defclass hau () ((new-slot :initarg :new-slot :initform 'new-slot) (other-new-slot :initarg :other-new-slot :initform 'other-new) (third-new :initarg :third-new :initform 'third-new))) NIL > *hau-1* # > (pcl:slot-value *hau-1* 'third-new) THIRD-NEW > ---------------------------------------------------------------------- It seems, that my old instance needs one print after redefining the class to be updated. Is there any other way to get this done ? CLOS says, that the updating of each instance happens at `some time' before any slot of that instance is accessed. When is that ? -- Pekka Jussila, Nokia Research Center. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22842; Fri, 9 Mar 90 10:06:11 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 09 MAR 90 10:00:16 PST Return-Path: Redistributed: CommonLoops.PA Received: from fs3.cs.rpi.edu ([128.213.4.10]) by Xerox.COM ; 09 MAR 90 09:58:14 PST Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA16134; Fri, 9 Mar 90 12:56:19 EST Date: Fri, 9 Mar 90 12:55:40 EST From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA03068; Fri, 9 Mar 90 12:55:40 EST Message-Id: <9003091755.AA03068@turing.cs.rpi.edu> To: CommonLoops.PA@Xerox.COM Subject: Additional fixes to Rainy Day PCL Here are some additional fixes to Rainy Day PCL. Rick Harris ==================== Problem: Method calls without enough required arguments cause trouble. compute-applicable-methods seems to be a good place to handle this problem. >> This was almost fixed in my previous message. methods.lisp compute-applicable-methods -- The previous fix was wrong: -- it used (length (gf-arg-info generic-function)) -- instead of (arg-info-number-required (gf-arg-info generic-function)) -- in the call to error. Change: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (every #'specializer-applicable-p (method-specializers method) arguments)) (sorter (method-1 method-2) To: (defmethod compute-applicable-methods ((generic-function generic-function) arguments) (labels ((filter (method) ! (let ((arguments-tail arguments)) ! (dolist (m-spec (method-specializers method) t) ! (unless arguments-tail ! (error "The function ~S requires at least ~D arguments" ! (generic-function-name generic-function) ! (arg-info-number-required (gf-arg-info generic-function)))) ! (unless (specializer-applicable-p m-spec (pop arguments-tail)) ! (return nil))))) (sorter (method-1 method-2) compute-applicable-methods-using-classes Change: (defmethod compute-applicable-methods-using-classes ((generic-function generic-function) classes) (labels ((filter (method) ! (every #'specializer-applicable-using-class-p (method-specializers method) ! classes)) (sorter (method-1 method-2) To: (defmethod compute-applicable-methods-using-classes ((generic-function generic-function) classes) (labels ((filter (method) ! (let ((classes-tail classes)) ! (dolist (m-spec (method-specializers method) t) ! (unless classes-tail ! (error "The function ~S requires at least ~D arguments" ! (generic-function-name generic-function) ! (arg-info-number-required (gf-arg-info generic-function)))) ! (unless (specializer-applicable-using-class-p ! m-spec (pop classes-tail)) ! (return nil))))) (sorter (method-1 method-2) construct.lisp compute-constructor-code ((class std-class) (constructor constructor)) Change: (make (compute-applicable-methods #'make-instance (list class))) (default ! (compute-applicable-methods #'default-initargs (list class))) (allocate (compute-applicable-methods #'allocate-instance (list class))) (initialize (compute-applicable-methods #'initialize-instance (list proto))) (shared (compute-applicable-methods #'shared-initialize (list proto t))) - (supplied-initarg-names - (constructor-supplied-initarg-names constructor)) (code-generators (constructor-code-generators constructor))) To: (make (compute-applicable-methods #'make-instance (list class))) + (supplied-initarg-names + (constructor-supplied-initarg-names constructor)) (default ! (compute-applicable-methods #'default-initargs ! (list class supplied-initarg-names))) ;? (allocate (compute-applicable-methods #'allocate-instance (list class))) (initialize (compute-applicable-methods #'initialize-instance (list proto))) (shared (compute-applicable-methods #'shared-initialize (list proto t))) (code-generators (constructor-code-generators constructor))) (flet ((call-code-generator (generator) (when (null generator) ==================== Problem: initial-dfun sometimes calls APPLY wtih NIL as the function. methods.lisp protect-cache-miss-code Change: (defmacro protect-cache-miss-code (gf args &body body) ! (once-only (gf args) ! `(if (memq ,gf *invalid-dfuns-on-stack*) ! (apply (get-secondary-dispatch-function ,gf ,args) ,args) ! (let ((*invalid-dfuns-on-stack* (cons ,gf *invalid-dfuns-on-stack*))) ! ,@body)))) To: (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) ! (no-applicable-method ,gf ,args) ! (apply ,function ,args))) ! (let ((*invalid-dfuns-on-stack* (cons ,gf *invalid-dfuns-on-stack*))) ! ,@body))))) ==================== Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22027; Fri, 9 Mar 90 18:56:21 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 09 MAR 90 12:05:20 PST Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 09 MAR 90 12:02:47 PST To: lgm@ihlpf.att.com Cc: commonloops.pa@Xerox.COM Subject: Re: Difficulty with lambda-list congruence, specifically &KEY In-Reply-To: Your message of Wed, 14 Feb 90 09:39:00 -0600. <900214-085750-8227@Xerox> Date: Fri, 09 Mar 90 15:07:28 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900309-120520-11855@Xerox> Redistributed: commonloops.pa From: lgm@ihlpf.att.com Date: Wed, 14 Feb 90 09:39 CST >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166) To: commonloops.pa@xerox.com Subject: Difficulty with lambda-list congruence, specifically &KEY Our group is attempting to use CLOS to maintain plug-compatible, upward-compatible interfaces between the components of a large, complex, long-lived, evolving software system. We are having difficulty, however, with lambda-list congruence; specifically, with the requirement that If any lambda-list mentions &REST or &KEY, each lambda-list must mention one or both of them. This restriction means that if someone defines a method on a generic function FUNC to take, say, a single (required) argument, then no one else's later FUNC method can extend the FUNC interface to accept additional (keyword) arguments; at least, not without modifying the original FUNC method (which is not desirable from a methodological point of view). This seems to match your system requirement of plug-compatibility. When you define your protocols you should be able to identify which functions are likely to require &key arguments (such as make-instance). One (methodological) workaround is to dictate the inclusion of &KEY in the lambda-list of every method of every publicly advertised generic function. This, however, is not possible for automatically generated methods; in particular, slot accessors (including readers and writers) take only required arguments. Don't forget that processing &key arguments is expensive, you probably don't want to do it for every function call. Thus, either any publicly advertised generic function which counts a slot accessor as one of its methods must be billed as "nonextensible" in our terminology, or we must generate our own accessors via DEFMETHOD (and thereby lose the benefit of any accessor optimizations provided by the CLOS vendor). I don't think that adding &key's will provide all the extentability you'll need in an evolving system. Why not let your protocol evolve over time. Your 1995 code could have keywords, and your 1990 methods could be redefined to call the 1995 methods with default arguments. Presumably we could use the meta-object protocol to define the object system behavior we desire, but we're reluctant to take such a step just yet. Does anyone have any comments or ideas about our difficulty? Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01944; Sat, 10 Mar 90 12:16:56 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 10 MAR 90 11:39:01 PST Date: Sat, 10 Mar 90 11:38 PST From: Gregor.pa@Xerox.COM Subject: Re: Magic number 8 in Rainy Day PCL ??? To: Thomas Schwab Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9002281456.AA19939@diana.informatik.uni-stuttgart.de> Message-Id: <19900310193814.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no From: Thomas Schwab We have some serious problems with the use of metaclasses in the "Rainy Day" version of PCL. I don't know what an accessor miss error is. Do you mean it signals some sort of error message? Or do you mean that some internal PCL function gets called? I don't get any kind of error message when I run the following code: (in-package 'pcl) (defclass my-meta-class (pcl::standard-class)()) (defclass my-class () ((slot-a :initform "default" :reader read-a)) (:metaclass my-meta-class)) (let ((inst (make-instance 'my-class))) (dotimes (i 8) (read-a inst))) ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01969; Sat, 10 Mar 90 12:20:36 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 10 MAR 90 11:50:58 PST Date: Sat, 10 Mar 90 11:50 PST From: Gregor.pa@Xerox.COM Subject: Re: generic fcn describe in Rainy Daay To: Greg Anglin Cc: CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9003051552.AA21037@watstat.waterloo.edu> Message-Id: <19900310195001.0.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 5 Mar 90 10:52:08 EST From: Greg Anglin I have successfully compiled Rainy Day PCL in Coral Allegro CL 1.2.2 (not 1.3). Everything seems to work just fine except for generic function describe: In the CLOS specification, there is no generic function called DESCRIBE. There is a generic function called DESCRIBE-OBJECT and that is implemented in Rainy Day PCL. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22619; Mon, 12 Mar 90 11:09:59 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 12 MAR 90 06:42:58 PST Return-Path: Redistributed: commonloops.pa Received: from att-in.att.com ([192.20.239.129]) by Xerox.COM ; 12 MAR 90 06:41:16 PST From: lgm@ihlpf.att.com Date: Mon, 12 Mar 90 08:36 CST >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166) To: kanderso@DINO.BBN.COM Cc: commonloops.pa@Xerox.COM Subject: Re: Difficulty with lambda-list congruence, specifically &KEY Message-Id: <900312-064258-16588@Xerox> >Don't forget that processing &key arguments is expensive, you probably >don't want to do it for every function call. Ideally, only methods that actually use the keyword arguments need to "process" them. Older methods need merely discard the (unused) keyword arguments. More importantly, our criteria of extensibility, upward compatibility etc. need not apply to all function calls, only to generic functions that represent interfaces between software components. >I don't think that adding &key's will provide all the extentability >you'll need in an evolving system. No, but together with the other features of ANSI Common Lisp and CLOS, they can go a long way. >Why not let your protocol evolve over time. Your 1995 code could have >keywords, and your 1990 methods could be redefined to call the 1995 >methods with default arguments. A prime criterion is to evolve the system without disturbing old code. Changing old code can break existing features - an intolerable catastrophe as far as our customers are concerned. Besides, engineering constraints (e.g., continuous uptime, real-time response) encourage the redefinition of as little code as possible. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02786; Mon, 12 Mar 90 14:20:37 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAR 90 10:19:54 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 MAR 90 10:16:33 PST To: CommonLoops.pa@Xerox.COM Subject: [kanderso@dino: Re: Difficulty with lambda-list congruence... ] Date: Mon, 12 Mar 90 13:31:18 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900312-101954-17212@Xerox> The original version of this may not have gotten to the commonloops list. Sorry for any duplications. ------- Forwarded Message To: REEDER%kebc.icl.stc.co.uk@nsfnet-relay.ac.uk cc: commonloops.pa%XEROX.COM%RELAY.CS.NET%NSFNET-RELAY.AC.UK@nsfnet-relay.ac.uk, mwr%kebc.icl.stc.co.uk@nsfnet-relay.ac.uk Subject: Re: Difficulty with lambda-list congruence... In-reply-to: Your message of Fri, 16 Feb 90 11:44:03 +0000. <6650.9002161144@sparc4.kebc.icl.stc.co.uk> Date: Sun, 11 Mar 90 11:56:14 -0500 From: kanderso@dino I recently had a similar experience converting a 130,000 line program from AAAI PCL to Victoria day pcl. The major problem was lambda list congruency, which forced me to edit about 100 lines of software. Occasionally in the old system, functions were used little more as a hook. Dispatch was only used on the first argument, and variants of the argument lists had anywhere from 1 to 5 arguments. I don't consider this particularly good for long term maintenance of the system. I like to think of CLOS a Behavior oriented, rather than Object oriented. Thus a generic function is an interface to some behavior, or relationship between objects, no one object is superior to the other necessarily. If you want the old behavior, you must now plan for it by providing &rest and &key args. A little more planning, may not be so bad, at least for the systems i work on. k ------- End of Forwarded Message Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13217; Tue, 13 Mar 90 01:25:27 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 12 MAR 90 14:42:52 PST Date: Mon, 12 Mar 90 14:39 PST From: Gregor.pa@Xerox.COM Reply-To: Gregor.PA@Xerox.COM Subject: informal poll To: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest Message-Id: <19900312223940.7.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I would like to do an informal poll of what people are doing with CLOS. In the past, I have had a pretty good sense, but lately as there are so many more people I don't really know all the different kinds of things people are doing. If you are free to give a general description of what you are doing with CLOS, and can spare 5 minutes to write a couple of sentences about it, I would really appreciate it. Please send your replies only to me, it will just swamp the list otherwise. I will send out a copy of whatever summary I develop to the whole list. Thanks in advance for your help. Gregor ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13514; Tue, 13 Mar 90 01:29:57 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 12 MAR 90 14:14:54 PST Date: Mon, 12 Mar 90 14:12 PST From: Gregor.pa@Xerox.COM Subject: Re: generic fcn describe in Rainy Daay To: Bob Kirby Cc: Greg Anglin , CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9003121843.AA17323@postgres.Berkeley.EDU> Message-Id: <19900312221246.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Mon, 12 Mar 90 10:43:46 -0800 From: kirby@postgres.Berkeley.EDU (Bob Kirby) In my version of the CLOS spec published in SIGPLAN (Vol. 23, Sep. 1988, p2-42) , the generic function is called "describe" not "describe-object". I hope that you intend to follow the published spec or else promptly publish revisions. A subsequent X3J13 vote changed this by adding the generic function DESCRIBE-OBJECT. DESCRIBE is now an ordinary function which simply defaults its second argument and calls DESCRIBE-OBJECT. For more information, see page 698 of the second edition of Guy Steele's book. X3J13 is the final authority on all of these issues. CLOS is not considered to be a stand-alone standard but rather an integral part of ANSI Common Lisp. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20615; Tue, 13 Mar 90 05:02:37 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 13 MAR 90 01:39:08 PST Return-Path: Redistributed: CommonLoops.pa Received: from inria.inria.fr ([128.93.8.1]) by Xerox.COM ; 13 MAR 90 01:37:17 PST Received: by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA11842; Tue, 13 Mar 90 10:35:17 +0100 (MET) From: ralph@orion.laas.fr Received: from orion.laas.fr by laas.laas.fr, Tue, 13 Mar 90 10:32:30 +0100 Received: by orion.laas.fr, Tue, 13 Mar 90 10:34:48 +0100 Date: Tue, 13 Mar 90 10:34:48 +0100 Message-Id: <9003130934.AA08832@orion.laas.fr> To: CommonLoops.pa@Xerox.COM Cc: gupta@prl.philips.co.uk, irvine%ntmtv.uucp@ames.arc.nasa.gov Subject: Re: a problem with BITFTP Reply-To: ralph@orion.laas.fr I have had no trouble recovering Rainy Day PCL (beta 3) through BITFTP. I used exactly the commands already posted to this mailing list. Have you tried the suggestions in BITFTP's help message, in case the uuencoded file gets corrupted? Good luck, Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU =============================================================================== Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20660; Tue, 13 Mar 90 05:08:30 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 12 MAR 90 09:38:53 PST Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 12 MAR 90 09:35:11 PST To: lgm@ihlpf.att.com Cc: commonloops.pa@Xerox.COM Subject: Re: Difficulty with lambda-list congruence, specifically &KEY In-Reply-To: Your message of Mon, 12 Mar 90 08:36:00 -0600. Date: Mon, 12 Mar 90 12:23:40 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900312-093853-17075@Xerox> From: lgm@ihlpf.att.com Date: Mon, 12 Mar 90 08:36 CST >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166) To: kanderso@DINO.BBN.COM Cc: commonloops.pa@xerox.com Subject: Re: Difficulty with lambda-list congruence, specifically &KEY >Don't forget that processing &key arguments is expensive, you probably >don't want to do it for every function call. Ideally, only methods that actually use the keyword arguments need to "process" them. Older methods need merely discard the (unused) keyword arguments. In a good LISP, that might be true. In the LISP i use, (defun foo (x &key y z) (declare ignore y z) x) is 3.4 times slower than (defun foo (x) x). because the argument list is processed, keywords verified, and given default values before the body of the function runs. More importantly, our criteria of extensibility, upward compatibility etc. need not apply to all function calls, only to generic functions that represent interfaces between software components. Yes, hopefully it will be obvious which functions in a protocol will require keyword arguments, so the problem you are talking about will be relatively rare. >I don't think that adding &key's will provide all the extentability >you'll need in an evolving system. No, but together with the other features of ANSI Common Lisp and CLOS, they can go a long way. >Why not let your protocol evolve over time. Your 1995 code could have >keywords, and your 1990 methods could be redefined to call the 1995 >methods with default arguments. A prime criterion is to evolve the system without disturbing old code. Changing old code can break existing features - an intolerable catastrophe as far as our customers are concerned. Besides, engineering constraints (e.g., continuous uptime, real-time response) encourage the redefinition of as little code as possible. This is a demanding environment. How do you distribute and install bug fixes and new versions? Perhaps the opposite of my suggestion might work - write the new software in terms of the old methods. So, now say, you are using (FOO X), and you realize you need (FOO-91 X &KEY Y Z). Your new software can use FOO-91 and the old can continue to use FOO. You you want to refer to both versions as FOO, you could use a macro or something to hide the differences. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24043; Thu, 15 Mar 90 03:15:05 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 13 MAR 90 12:19:13 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@ERNEST.ACA.MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 13 MAR 90 12:17:04 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Tue 13 Mar 90 14:17:02-CST Date: Tue, 13 Mar 90 14:15 CST From: Nat Ballou Subject: Overloading of primitive operators To: CommonLoops.pa@Xerox.COM Message-Id: <19900313201554.9.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 One (of the few?) advantage(s) that C++ holds over CLOS is the ability to overload the primitive operators in C. For example, C++ allows one to overload the equivalent Common Lisp operators eq, aref, not, +, -, *, /, mod, >, <, etc. I am under the impression that ANSI Common Lisp (with CLOS) will not allow such operators to be overloaded. Is this correct? If so, why? The ability of to overload the primitive language operators can greatly simplify the syntax of classes which are specializations of CL types (i.e., a sparse matrix class or a persistent, extendible hash class). It would be rather ironic if C++, with its rather small reserved namespace, allowed such overloading, whereas ANSI CL, with an enormous reserved namespace, did not. Nat Ballou MCC Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24731; Thu, 15 Mar 90 03:20:37 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 90 13:16:06 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@ERNEST.ACA.MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 14 MAR 90 13:14:34 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Wed 14 Mar 90 14:23:03-CST Date: Wed, 14 Mar 90 14:22 CST From: Nat Ballou Subject: Re: Overloading of primitive operators To: commonloops.pa@Xerox.COM Message-Id: <19900314202213.3.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 Larry Masinter offers the following solution: As a Common Lisp user, you can do this [overload primitive operators] yourself, by shadowing the functions you want to make generic with the default implementation being the standard CL: one. The use of the term "shadowing" is confusing to me. Do you mean "shadowing" as in shadowing a symbol? If so, this solution involves some fairly inconvenient changes (e.g., not using the "LISP" package). However, if by "shadowing" you mean use another name, then this is a non-solution to the original problem. Nat Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26195; Thu, 15 Mar 90 04:48:35 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 14 MAR 90 02:20:25 PST Return-Path: Redistributed: CommonLoops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 14 MAR 90 02:17:03 PST Received: by mcsun.EU.net via EUnet; Wed, 14 Mar 90 11:16:12 +0100 (MET) Received: from prl.philips.co.uk by kestrel.Ukc.AC.UK with UUCP id aa26466; 14 Mar 90 10:04 GMT Received: from apollo54.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Wed, 14 Mar 90 09:57:43 gmt From: Ashok Gupta Date: Wed, 14 Mar 90 09:55:02 gmt Message-Id: <905.9003140955@apollo54.prl.philips.co.uk> To: ralph@orion.laas.fr Subject: Re: a problem with BITFTP Cc: CommonLoops.pa@Xerox.COM Date: Tue, 13 Mar 90 10:34:48 +0100 I have had no trouble recovering Rainy Day PCL (beta 3) through BITFTP. I used exactly the commands already posted to this mailing list. Have you tried the suggestions in BITFTP's help message, in case the uuencoded file gets corrupted? The problem I had (as did Chuck Irvine) was not covered by the BITFTP help notes. Each uudecoded file had an extra line at the bottom, which required removal. Also, there should be no after the last ASCII text character. Editing each of the 19 files in this way and then `cat'ing, `tar'ing etc. worked fine. I guess the problem is a 'feature' of some mailers or gateways and therefore worth remembering as one may encounter it in the future, when receiving other uuencoded mail from other sources or paths. Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice : +44 293 785544 ext 5647 JANET : gupta@prl.philips.co.uk ARPA : gupta%prl.philips.co.uk@nsfnet-relay.ac.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26995; Thu, 15 Mar 90 06:10:45 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 15 MAR 90 04:50:13 PST Return-Path: Redistributed: CommonLoops.PA Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 15 MAR 90 04:48:51 PST Received: by mcsun.EU.net with SMTP; Thu, 15 Mar 90 13:48:47 +0100 (MET) Received: from sbsvax by unido.informatik.uni-dortmund.de with UUCP (UNIDO-2.0.1.d) via EUnet for xerox.com id AY29454; Thu, 15 Mar 90 00:48:05 +0100 Received: from fb14vax with SMTP by cs.uni-sb.de (5.61/UniSB-2.1) id AA12868; Wed, 14 Mar 90 23:28:31 +0100 From: "Petra Sommer" Date: Wed, 14 Mar 90 23:28:28 +0100 Message-Id: <9003142228.AA08711@fb14vax.cs.uni-sb.de> Received: by fb14vax.cs.uni-sb.de; Wed, 14 Mar 90 23:28:28 +0100 To: CommonLoops.PA@Xerox.COM Subject: mail list -- add please add petra@cs.uni-sb.de to mailing list. ------------------------------------------------------------------ |NET: petra@cs.uni-sb.de | |----------------------------------------------------------------| |POST: Petra Sommer | | FB 14 - Informatik IV | | Universitaet des Saarlandes | | Im Stadtwald 15 | | D-6600 Saarbruecken 11 | | Federal Republic of Germany | ------------------------------------------------------------------ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27052; Thu, 15 Mar 90 06:13:56 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 90 10:11:00 PST Return-Path: Redistributed: CommonLoops.pa Received: from watstat.waterloo.edu ([129.97.129.33]) by Xerox.COM ; 14 MAR 90 10:09:08 PST Received: by watstat.waterloo.edu id ; Wed, 14 Mar 90 13:08:43 EST Date: Wed, 14 Mar 90 13:08:43 EST From: Greg Anglin Message-Id: <9003141808.AA16605@watstat.waterloo.edu> To: CommonLoops.pa@Xerox.COM Subject: (setf (apply #'accessor ...)) Hi -- Suppose I have (defclass foobar () ((foo :accessor foo))) (setf bar (make-instance 'foobar)) Then clearly I can do (setf (foo bar) 42) but it seems, at least under MACL 1.2.2 and Rainy Day PCL, that (setf b (list bar)) (setf (apply #'foo b) 42) is not permitted. There are uglier ways to do this that work, but I'd really rather not resort to them. I am having difficulty with this sort of thing because the generic function I'm creating takes a number, determined at runtime, of arguments (as &rest) in addition to the instance being accessed. The situation is exactly the same as the example given for #'aref in CLtL p96-97 (1st ed ... still waiting for my copy of 2nd ed), and it would be nice if setf for generic functions had this capability as well as CL functions. Any comments? Greg Anglin Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27534; Thu, 15 Mar 90 06:52:48 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAR 90 06:51:58 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@ERNEST.ACA.MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 15 MAR 90 06:48:37 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Thu 15 Mar 90 08:48:35-CST Date: Thu, 15 Mar 90 08:47 CST From: Nat Ballou Subject: Access protection To: commonloops.pa@Xerox.COM Message-Id: <19900315144735.5.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 Another possible advantage of C++ over CLOS is the private/public/protected mechanism. Roughly speaking, a public method or slot can be invoked on a class instance by anyone. A private method or slot can be invoked only by the direct methods of a class, and a protected method or slot can be invoked by a direct or indirect method (i.e., a method on a subclass) of a class. If we were to use Common Lisp packages for this purpose, there seems to be a few inconveniences. First, suppose that I have a method and a setf method defined for the symbol FOO. Suppose I want the method FOO to be public, but not the setf method FOO. How can I do this without renaming my setf method? Will the method specification (SETF FOO) have a package of its own in ANSI CL? The Common Lisp export/import mechanism may be able to provide functionality similar to the public/private mechanism in C++. However, it is unclear how to best implement the protected mechanism. Things become even more difficult when one allows a subclass to change an inherited method or slot from public to private, as in C++. Ideas, comments? Nat Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29284; Thu, 15 Mar 90 08:27:11 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 15 MAR 90 08:23:28 PST Return-Path: Redistributed: commonloops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 15 MAR 90 08:21:22 PST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: by luke (4.0/SMI-4.0) id AA09858; Thu, 15 Mar 90 11:19:24 EST From: "dsr@luke.mitre.org"@mbunix.mitre.org (Douglas S. Rand) Message-Id: <9003151619.AA09858@luke> To: Nat Ballou Cc: commonloops.pa@Xerox.COM, dsr@mbunix.mitre.org Subject: Re: Access protection In-Reply-To: Your message of Thu, 15 Mar 90 08:47:00 -0600. <19900315144735.5.BALLOU@LILITH.ACA.MCC.COM> Date: Thu, 15 Mar 90 11:19:21 EST It's important to separate two entirely different issues. There are two features to C++. The first feature is some support for object oriented programming. The second feature is basically data abstraction or data hiding. OOP does not automatically include the second feature. In particular the LISP environment is one where people often hack around and nearly every manipulation is possible. This said there is an answer to the (setf foo) problem. Instead of declaring the slot with :accessor foo you declare it with :reader foo and no setf function is generated. I'm not sure what, if anything, will happen in a WITH-SLOTS form if you use SETF. Cheers, Doug Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04443; Thu, 15 Mar 90 12:33:28 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAR 90 08:58:13 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@ERNEST.ACA.MCC.COM> Redistributed: commonloops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 15 MAR 90 08:54:29 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Thu 15 Mar 90 10:53:54-CST Date: Thu, 15 Mar 90 10:53 CST From: Nat Ballou Subject: Re: Access protection To: commonloops.pa@Xerox.COM Message-Id: <19900315165301.7.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 It's important to separate two entirely different issues. There are two features to C++. The first feature is some support for object oriented programming. The second feature is basically data abstraction or data hiding. OOP does not automatically include the second feature. I'm simply trying to match features. I'm not trying to say whether such things are part of OOP or not (i.e., from your point of view, I am simply trying to do OOP with a little data abstraction and/or data hiding :-). In particular the LISP environment is one where people often hack around and nearly every manipulation is possible. This said there is an answer to the (setf foo) problem. Instead of declaring the slot with :accessor foo you declare it with :reader foo and no setf function is generated. I'm not sure what, if anything, will happen in a WITH-SLOTS form if you use SETF. I realize that a hacker can do anthing s/he wants. I also realize that if a programmer does not use '::' syntax, and makes use of only the exported functionality of a package, the same programmer can achieve an environment similar to C++ (with public/private/protected methods and slots). In doing so, some nice features of CLOS (i.e., SETF methods) cannot be used if the same programmer wants to present a consistent interface to users. For those lisp hackers who put everything (AND the kitchen sink) in the same package ... never mind :-) Nat Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04571; Thu, 15 Mar 90 12:42:15 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAR 90 11:34:11 PST Return-Path: Redistributed: CommonLoops.pa Received: from cambridge.apple.com ([134.149.2.3]) by Xerox.COM ; 15 MAR 90 11:28:53 PST Received: by cambridge.apple.com (4.1/SMI-DDN) id AA05857; Thu, 15 Mar 90 14:13:13 EST Date: Thu, 15 Mar 90 14:13:13 EST From: bill@cambridge.apple.com (Bill St. Clair) Message-Id: <9003151913.AA05857.bill@cambridge.apple.com> To: dganglin%watstat.waterloo.edu@eddie.mit.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Greg Anglin's message of Wed, 14 Mar 90 13:08:43 EST <9003141808.AA16605@watstat.waterloo.edu> Subject: (setf (apply #'accessor ...)) Redistributed: CommonLoops.pa Date: Wed, 14 Mar 90 13:08:43 EST From: Greg Anglin [...] (setf b (list bar)) (setf (apply #'foo b) 42) [...] CLtL2 does NOT include the use of (setf (apply ...) ...) that you want here. It's easy to write what you want, however: (setf b (list bar)) (apply #'(setf foo) 42 b) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08288; Thu, 15 Mar 90 15:37:35 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 90 14:02:45 PST Return-Path: Redistributed: CommonLoops.PA Received: from Think.COM ([131.239.2.1]) by Xerox.COM ; 15 MAR 90 13:58:55 PST Received: from Fafnir.Think.COM by Think.COM; Thu, 15 Mar 90 16:58:28 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Thu, 15 Mar 90 16:56:54 EST Received: by verdi.think.com; Thu, 15 Mar 90 16:58:20 EST Date: Thu, 15 Mar 90 16:58:20 EST From: gls@Think.COM (Guy Steele) Message-Id: <9003152158.AA25893@verdi.think.com> To: CommonLoops.PA@Xerox.COM, common-lisp@sail.stanford.edu Cc: GLS@Think.COM Subject: ANSI CL Spec Date: Wed, 14 Mar 90 06:08 PST From: Bruce Esrig To: commonloops-request.PA Subject: ANSI CL Spec Is Steele, 2nd ed. the current best presentation of ANSI Common Lisp ? Bruce Esrig esrig%oravax.uucp@cu-arpa.cs.cornell.edu Perhaps the following text, excerpted from the preface to the second edition of "Common Lisp: The Language", will shed some light on the intended relationship of that book to the standard: ---------------------------------------------------------------- X3J13 has completed the bulk of its technical work in rectifying the 1984 definition and codifying extensions to that definition that have received widespread use and approval. A draft standard is now being prepared; it will probably be available in 1990. There will then be a period (required by ANSI) for public review. X3J13 must then consider the comments it receives and respond appropriately. If the comments result in substantial changes to the draft standard, multiple public review periods may be required before the draft can be approved as an American National Standard. Fortunately, X3J13 has done an outstanding job of documenting its work. ... By my count, by June 1989 some 186 [proposals] were approved as language changes.... The purpose of this second edition is to bridge the gap between the first edition and the forthcoming ANSI standard for Common Lisp. Because of the requirement for formal public review, it will be some time yet before the ANSI standard is final. This book in no way resembles the forthcoming standard (which is being written independently by Kathy Chapman of Digital Equipment Corporation with assistance from the X3J13 Drafting Subcommittee). I have incorporated into this second edition a great deal of material based on the votes of X3J13, in order to give the reader a picture of where the language is heading. My purpose here is not simply to quote the X3J13 documents verbatim but to paraphrase them and relate them to the structure of the first edition. A single vote by X3J13 may be discussed in many parts of this book, and a single passage of this book may be affected by many of the votes. I wish to be very clear: this book is not an official document of X3J13, though it is based on publicly available material produced by X3J13. In no way does this book constitute a definitive description of the forthcoming ANSI standard. The committee's decisions have been remarkably stable (it has rescinded earlier decisions only two or three times), and I do not expect radical changes in direction. Nevertheless, it is quite probable that the draft standard will be substantively revised in response to editorial review or public comment. I have therefore reported here on the actions of X3J13 not to inscribe them in stone, but to make clear how the language of the first edition is likely to change. I have tried to be careful in my wording to avoid saying ``the language has been changed'' and to state simply that ``X3J13 voted at such-and-so time to make the following change.'' Until the day when an official ANSI Common Lisp standard emerges, it is likely that the 1984 definition of Common Lisp will continue to be used widely. This book has been designed to be used as a reference both to the 1984 definition and to the language as modified by the actions of X3J13. ---------------------------------------------------------------- --Guy Steele Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08371; Thu, 15 Mar 90 15:42:11 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 90 15:36:04 PST Return-Path: <@MCC.COM,@LILITH.ACA.MCC.COM:ballou@ERNEST.ACA.MCC.COM> Redistributed: CommonLoops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 15 MAR 90 15:34:32 PST Received: from LILITH.ACA.MCC.COM by MCC.COM with TCP/SMTP; Thu 15 Mar 90 17:34:30-CST Date: Thu, 15 Mar 90 17:33 CST From: Nat Ballou Subject: RE: Overloading of primitive operators To: CommonLoops.pa@Xerox.COM Message-Id: <19900315233311.3.BALLOU@LILITH.ACA.MCC.COM> Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 Shadowing the symbols doesn't mean that you can't use the LISP package. Here's a quick and dirty example: [...] You are now free to define your own methods for + and - which are specialized on any class you like, including, but not limited to, subclasses of NUMBER. But if I do this, for any package to use my package's definition of +, it too must shadow the +. Such a package better shadow such symbols before using the LISP package, and heavens forbid if some package other than mine also pulls the same trick on the operator +... The idea of using shadowed symbols is not a real solution since one has really introduced a new symbol (i.e., the symbols have the same name, but are two different symbols). In C++, the user of an overloaded primitive operator does not need to do anything special. Nat Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08288; Thu, 15 Mar 90 15:37:35 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 90 14:02:45 PST Return-Path: Redistributed: CommonLoops.PA Received: from Think.COM ([131.239.2.1]) by Xerox.COM ; 15 MAR 90 13:58:55 PST Received: from Fafnir.Think.COM by Think.COM; Thu, 15 Mar 90 16:58:28 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Thu, 15 Mar 90 16:56:54 EST Received: by verdi.think.com; Thu, 15 Mar 90 16:58:20 EST Date: Thu, 15 Mar 90 16:58:20 EST From: gls@Think.COM (Guy Steele) Message-Id: <9003152158.AA25893@verdi.think.com> To: CommonLoops.PA@Xerox.COM, common-lisp@sail.stanford.edu Cc: GLS@Think.COM Subject: ANSI CL Spec Date: Wed, 14 Mar 90 06:08 PST From: Bruce Esrig To: commonloops-request.PA Subject: ANSI CL Spec Is Steele, 2nd ed. the current best presentation of ANSI Common Lisp ? Bruce Esrig esrig%oravax.uucp@cu-arpa.cs.cornell.edu Perhaps the following text, excerpted from the preface to the second edition of "Common Lisp: The Language", will shed some light on the intended relationship of that book to the standard: ---------------------------------------------------------------- X3J13 has completed the bulk of its technical work in rectifying the 1984 definition and codifying extensions to that definition that have received widespread use and approval. A draft standard is now being prepared; it will probably be available in 1990. There will then be a period (required by ANSI) for public review. X3J13 must then consider the comments it receives and respond appropriately. If the comments result in substantial changes to the draft standard, multiple public review periods may be required before the draft can be approved as an American National Standard. Fortunately, X3J13 has done an outstanding job of documenting its work. ... By my count, by June 1989 some 186 [proposals] were approved as language changes.... The purpose of this second edition is to bridge the gap between the first edition and the forthcoming ANSI standard for Common Lisp. Because of the requirement for formal public review, it will be some time yet before the ANSI standard is final. This book in no way resembles the forthcoming standard (which is being written independently by Kathy Chapman of Digital Equipment Corporation with assistance from the X3J13 Drafting Subcommittee). I have incorporated into this second edition a great deal of material based on the votes of X3J13, in order to give the reader a picture of where the language is heading. My purpose here is not simply to quote the X3J13 documents verbatim but to paraphrase them and relate them to the structure of the first edition. A single vote by X3J13 may be discussed in many parts of this book, and a single passage of this book may be affected by many of the votes. I wish to be very clear: this book is not an official document of X3J13, though it is based on publicly available material produced by X3J13. In no way does this book constitute a definitive description of the forthcoming ANSI standard. The committee's decisions have been remarkably stable (it has rescinded earlier decisions only two or three times), and I do not expect radical changes in direction. Nevertheless, it is quite probable that the draft standard will be substantively revised in response to editorial review or public comment. I have therefore reported here on the actions of X3J13 not to inscribe them in stone, but to make clear how the language of the first edition is likely to change. I have tried to be careful in my wording to avoid saying ``the language has been changed'' and to state simply that ``X3J13 voted at such-and-so time to make the following change.'' Until the day when an official ANSI Common Lisp standard emerges, it is likely that the 1984 definition of Common Lisp will continue to be used widely. This book has been designed to be used as a reference both to the 1984 definition and to the language as modified by the actions of X3J13. ---------------------------------------------------------------- --Guy Steele Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27199; Fri, 16 Mar 90 06:36:39 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAR 90 18:27:21 PST Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 15 MAR 90 18:24:32 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA12678g; Thu, 15 Mar 90 18:22:42 PST Received: by kent-state id AA01162g; Thu, 15 Mar 90 18:24:01 PST Date: Thu, 15 Mar 90 18:24:01 PST From: Jon L White Message-Id: <9003160224.AA01162@kent-state> To: bill@cambridge.apple.com Cc: dganglin%watstat.waterloo.edu@eddie.mit.edu, CommonLoops.pa@Xerox.COM In-Reply-To: Bill St. Clair's message of Thu, 15 Mar 90 14:13:13 EST <9003151913.AA05857.bill@cambridge.apple.com> Subject: (setf (apply #'accessor ...)) re: Redistributed: CommonLoops.pa Date: Wed, 14 Mar 90 13:08:43 EST From: Greg Anglin [...] (setf b (list bar)) (setf (apply #'foo b) 42) [...] CLtL2 does NOT include the use of (setf (apply ...) ...) that you want here. It's easy to write what you want, however: (setf b (list bar)) (apply #'(setf foo) 42 b) Lucid's CLOS permits the former usage too, exactly as Greg Anglin expects it. I wonder what the other CLOS implementations do? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27287; Fri, 16 Mar 90 06:47:44 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 90 18:41:44 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 15 MAR 90 18:40:06 PST To: Nat Ballou Cc: CommonLoops.pa@Xerox.COM Subject: Re: Overloading of primitive operators In-Reply-To: Your message of Tue, 13 Mar 90 14:15:00 -0600. <19900313201554.9.BALLOU@LILITH.ACA.MCC.COM> Date: Thu, 15 Mar 90 21:58:25 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900315-184144-7075@Xerox> Redistributed: CommonLoops.pa Date: Tue, 13 Mar 90 14:15 CST From: Nat Ballou Subject: Overloading of primitive operators To: CommonLoops.pa@xerox.com Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 One (of the few?) advantage(s) that C++ holds over CLOS is the ability to overload the primitive operators in C. For example, C++ allows one to overload the equivalent Common Lisp operators eq, aref, not, +, -, *, /, mod, >, <, etc. I am under the impression that ANSI Common Lisp (with CLOS) will not allow such operators to be overloaded. Is this correct? If so, why? I believe this is correct. I presume one reason why is to allow current implementations of LISP to remain relatively efficient, without a lot of work. For example, functions like EQ, NOT, and CAR, are inline coded for speed. If everything became generic overnight, LISP would be a lot slower until we added a lot of type information, and got better at type deduction. I believe C++'s overloading is more like pattern matching on types of operands at compile time, rather than generic function dispatch. This lets C++ do a lot of inlining. I hope that over time, LISP will become more completely object oriented, since this would allow efficiencies that currently aren't possible (inline method dispatch for example). This plus good compiler optimizations could make a very high performance LISP. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27339; Fri, 16 Mar 90 06:52:32 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 90 16:07:35 PST Return-Path: Redistributed: commonloops.pa Received: from mbunix.mitre.org ([129.83.20.100]) by Xerox.COM ; 15 MAR 90 16:05:56 PST Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Received: by luke (4.0/SMI-4.0) id AA09875; Thu, 15 Mar 90 11:32:58 EST Date: Thu, 15 Mar 90 11:32:58 EST From: "dsr@luke.mitre.org"@mbunix.mitre.org (Douglas S. Rand) Message-Id: <9003151632.AA09875@luke> To: commonloops.pa@Xerox.COM Subject: constructors It used to be the case that a defclass had the side effect of creating the class during compilation. Has this gone away? (i.e. do I need to put my defconstructor forms in another file?) Doug Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16736; Fri, 16 Mar 90 16:38:54 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAR 90 18:23:02 PST Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 15 MAR 90 18:19:05 PST To: Nat Ballou Cc: commonloops.pa@Xerox.COM Subject: Re: Access protection In-Reply-To: Your message of Thu, 15 Mar 90 08:47:00 -0600. <19900315144735.5.BALLOU@LILITH.ACA.MCC.COM> Date: Thu, 15 Mar 90 21:38:28 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900315-182302-702@Xerox> Redistributed: commonloops.pa Date: Thu, 15 Mar 90 08:47 CST From: Nat Ballou Subject: Access protection To: commonloops.pa@xerox.com Postal-Address: 3500 West Balcones Ctr. Dr., Austin, TX 78759 Phone: (512) 338-3376 I did not get these messages in order, so i'll respond to them individually. Another possible advantage of C++ over CLOS is the private/public/protected mechanism. Roughly speaking, a public method or slot can be invoked on a class instance by anyone. A private method or slot can be invoked only by the direct methods of a class, and a protected method or slot can be invoked by a direct or indirect method (i.e., a method on a subclass) of a class. Yes, at first i worried that CLOS did not enforce encapsulation issues. Now i don't worry about it so much. I worry about encapsulation, i just don't worry about enforcing it. During debugging, it is useful to be able to have access to an objects private parts temporarily. For example, supose you were stuck at some point and knew, you needed to some private behavior X. You'd then have to make it public, before you could continue to debug. By the time you were done debugging, you might have to make a lot of things temporarily public, and you might forget to make them private later, and over time, users might rely on it being public... This problem gets amplified in big programming projects. Programmers may agree amongst themselves to make everything public to speed development, without telling management... CLOS encourages encapsulation, without enforcing it. Also, if you accepted the public/private duality, since CLOS has a meta level, you also have to decide what metapublic and metaprivate mean. If we were to use Common Lisp packages for this purpose, there seems to be a few inconveniences. First, suppose that I have a method and a setf method defined for the symbol FOO. Suppose I want the method FOO to be public, but not the setf method FOO. How can I do this without renaming my setf method? Will the method specification (SETF FOO) have a package of its own in ANSI CL? Put FOO in a public package, and (SETF FOO) in a private package. The Common Lisp export/import mechanism may be able to provide functionality similar to the public/private mechanism in C++. However, it is unclear how to best implement the protected mechanism. Things become even more difficult when one allows a subclass to change an inherited method or slot from public to private, as in C++. Aternatively, you could probably use the metaclass protocol to identify private violations. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17810; Fri, 16 Mar 90 17:47:01 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 90 06:25:52 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 16 MAR 90 06:23:54 PST To: Nat Ballou Cc: CommonLoops.pa@Xerox.COM Subject: Re: Overloading of primitive operators In-Reply-To: Your message of Thu, 15 Mar 90 17:33:00 -0600. <19900315233311.3.BALLOU@LILITH.ACA.MCC.COM> Date: Fri, 16 Mar 90 09:41:51 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900316-062552-810@Xerox> But if I do this, for any package to use my package's definition of +, it too must shadow the +. Such a package better shadow such symbols before using the LISP package, and heavens forbid if some package other than mine also pulls the same trick on the operator +... At least i the LISP i'm using, this works fine: ;;; Make a package the way you like it: (make-package 'nat-lisp :use '(pcl lisp)) (shadow '(lisp:+ lisp:-) 'nat-lisp) (export '(nat:+ nat:-) 'nat-lisp) ;;; Define the functions you want ... ;;; Define a package for users to use: (make-package 'nat-lisp-user :use '(nat-lisp pcl lisp)) (in-package 'nat-lisp-user) ... now users can use your generic lisp ... The idea of using shadowed symbols is not a real solution since one has really introduced a new symbol (i.e., the symbols have the same name, but are two different symbols). In C++, the user of an overloaded primitive operator does not need to do anything special. Perhaps, but you get what you want for about 5 lines of software. Not only do you get the behavior you want in nat:+, but you also get the implementor's lisp:+ to build it in terms of. This gives you something to use while you write a truely object oriented LISP from scratch, and get X3J13 to accept it as a standard. BTW, C++ does place restrictions on operators that can be overloaded [at least in 1984]. For example, you can't change the syntax of an operator, and you can't add new ones like "**" for exponentiation. These issues don't even come up in LISP. To be fare, perhaps you should start a discussion about this on some C++ group. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17861; Fri, 16 Mar 90 17:51:52 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 90 10:00:47 PST Date: Fri, 16 Mar 90 09:59 PST From: Gregor.pa@Xerox.COM Subject: Re: constructors To: Douglas S. Rand <"dsr@luke.mitre.org"@mbunix.mitre.org> Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9003151632.AA09875@luke> Message-Id: <19900316175911.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 15 Mar 90 11:32:58 EST From: "dsr@luke.mitre.org"@mbunix.mitre.org (Douglas S. Rand) It used to be the case that a defclass had the side effect of creating the class during compilation. Has this gone away? (i.e. do I need to put my defconstructor forms in another file?) This issue is addressed in the notes.text file distributed with the current PCL. Look there for details. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18445; Fri, 16 Mar 90 18:31:50 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 90 10:15:51 PST Date: Fri, 16 Mar 90 10:14 PST From: Gregor.pa@Xerox.COM Subject: Re: (setf (apply #'accessor ...)) To: Jon L White Cc: bill@cambridge.apple.com, dganglin%watstat.waterloo.edu@eddie.mit.edu, CommonLoops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9003160224.AA01162@kent-state> Message-Id: <19900316181413.9.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Thu, 15 Mar 90 18:24:01 PST From: Jon L White Lucid's CLOS permits the former usage too, exactly as Greg Anglin expects it. I wonder what the other CLOS implementations do? Do you mean that the following works too: (defsetf foo set-foo) (setf (apply #'foo x) y) and (defun (setf bar) (new x) ..) (setf (apply #'bar x) y) This seems a bit problematic to me since SETF is a macro which operates on symbols and APPLY is a function which operates on functions. I guess you can make it work in practice but... I'm no fair judge since I never liked SETF anyways. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18513; Fri, 16 Mar 90 18:36:08 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 90 12:22:19 PST Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 16 MAR 90 12:20:21 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA17935g; Fri, 16 Mar 90 12:18:37 PST Received: by kent-state id AA01929g; Fri, 16 Mar 90 12:19:57 PST Date: Fri, 16 Mar 90 12:19:57 PST From: Jon L White Message-Id: <9003162019.AA01929@kent-state> To: Gregor.pa@Xerox.COM Cc: bill@cambridge.apple.com, dganglin%watstat.waterloo.edu@eddie.mit.edu, CommonLoops.pa@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Fri, 16 Mar 90 10:14 PST <19900316181413.9.GREGOR@SPIFF.parc.xerox.com> Subject: (setf (apply #'accessor ...)) re: Do you mean that the following works too: (defsetf foo set-foo) (setf (apply #'foo x) y) Greg's query was only about the mechanically-generated accessor generic functions, and that's the only thing I meant. I don't have any particular interest in the more general DEFSETF question. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18789; Fri, 16 Mar 90 18:56:34 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 90 03:42:40 PST Return-Path: <@mitvma.mit.edu:ZSIMOPBE@DB0TUI6.BITNET> Redistributed: COMMONLOOPS.PA Received: from mitvma.mit.edu ([18.92.0.3]) by Xerox.COM ; 16 MAR 90 03:41:11 PST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3632; Fri, 16 Mar 90 06:40:16 EST Received: from DB0TUI6.BITNET (ZSIMOPBE) by MITVMA.MIT.EDU (Mailer R2.05) with BSMTP id 9470; Fri, 16 Mar 90 06:40:15 EST Received: by tub.UUCP; Fri, 16 Mar 90 12:39:33 +0100; AA05452 Received: by opal.cs.tu-berlin.de; Fri, 16 Mar 90 12:39:26 +0100; AA23288 Date: Fri, 16 Mar 90 12:39:26 +0100 From: Simon Leinen Message-Id: <9003161139.AA23288@opal.cs.tu-berlin.de> Received: by charger.cs.tu-berlin.de; Fri, 16 Mar 90 12:39:23 +0100; AA03486 To: CommonLoops.pa%Xerox.COM%tub.BITNET@MITVMA.MIT.EDU Subject: Small enhancement for (Rainy Day) PCL under Allegro CL We use the following addition to `env.lisp' on Allegro CL 3.1.4, Sun-3 and Sun-4. I believe it works on other versions of ACL/ExCL, too. The purpose is that COMPILE-FILE should print out messages while compiling methods and classes. It defines a wrapper around an unexported, undocumented internal compiler function, so use on your own risk. -------------------- cut here and insert into `env.lisp' -------------------- ;;; The compiler will now print progress messages when it is compiling ;;; a method or class definition. ;;; #+ExCL (progn (defvar *old-compile-process-form*) (defun pcl-process-form (form) (when (consp form) (case (first form) ((defmethod) (format t "; Compiling method ~$~S~^ ~~%" (name-of-defmethod form))) ((defclass) (format t "; Compiling class ~S~%" (second form))))) (funcall *old-compile-process-form* form)) (defun name-of-defmethod (defmethod-form) (multiple-value-bind (name qualifiers lambda-list body) (parse-defmethod (rest defmethod-form)) (declare (ignore body)) `(,name ,@qualifiers ,(specialized-lambda-list-specializers lambda-list)))) (eval-when (eval load) (unless (boundp '*old-compile-process-form*) (setq *old-compile-process-form* (symbol-function 'compiler::compile-process-form)) (setf (symbol-function 'compiler::compile-process-form) #'pcl-process-form))) ) -- Simon Leinen. simon@opal.cs.tu-berlin.de simon%opal@db0tui6.bitnet simon@tubopal.UUCP Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19577; Tue, 20 Mar 90 07:19:27 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 20 MAR 90 06:42:55 PST Return-Path: Redistributed: CommonLoops.PA Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 20 MAR 90 06:40:20 PST Received: by mcsun.EU.net with SMTP; Tue, 20 Mar 90 15:40:15 +0100 (MET) Received: from sbsvax by unido.informatik.uni-dortmund.de with UUCP (UNIDO-2.0.1.d) via EUnet for mcsun.eu.net id AP28969; Tue, 20 Mar 90 15:37:24 +0100 Received: from fb14vax with SMTP by cs.uni-sb.de (5.61/UniSB-2.1) id AA24284; Tue, 20 Mar 90 15:22:16 +0100 From: "Petra Sommer" Date: Tue, 20 Mar 90 15:22:12 +0100 Message-Id: <9003201422.AA12655@fb14vax.cs.uni-sb.de> Received: by fb14vax.cs.uni-sb.de; Tue, 20 Mar 90 15:22:12 +0100 To: CommonLoops.PA@Xerox.COM Subject: insert classes? Hi, maybe this is an old question: how can i insert a pcl-class into an existing class-hierarchy? e.g. class A supers class B, insert new class C should lead to class A supers class C supers class B Thanks in advance Petra ------------------------------------------------------------------ |NET: petra@cs.uni-sb.de | |----------------------------------------------------------------| |POST: Petra Sommer | | FB 14 - Informatik IV | | Universitaet des Saarlandes | | Im Stadtwald 15 | | D-6600 Saarbruecken 11 | | Federal Republic of Germany | ------------------------------------------------------------------ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23301; Tue, 20 Mar 90 10:43:19 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAR 90 09:54:34 PST Return-Path: Redistributed: CommonLoops.PA Received: from pooh.parc.xerox.com ([13.2.16.167]) by Xerox.COM ; 20 MAR 90 09:39:57 PST Received: from bullwinkle.parc.Xerox.COM by pooh.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09170; Tue, 20 Mar 90 09:38:40 PST Date: Tue, 20 Mar 90 09:38 PST From: Danny Bobrow Subject: Re: insert classes? To: petra@cs.uni-sb.de Cc: CommonLoops.PA@Xerox.COM Message-Id: <19900320173858.8.BOBROW@BULLWINKLE.parc.xerox.com> Date: Tue, 20 Mar 90 15:22:12 +0100 From: "Petra Sommer" Hi, maybe this is an old question: how can i insert a pcl-class into an existing class-hierarchy? e.g. class A supers class B, insert new class C should lead to class A supers class C supers class B Thanks in advance Petra Assume you had started with (defclass a (b) ...) ... Then Evaluate (defclass c (b) ...) and then evaluate: (defclass a (c) ...) CLOS guarantees that the new definition will override the old one and that instances of a will be updated to the new structure the next time a method is called on them. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26609; Tue, 20 Mar 90 13:07:42 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 90 13:04:56 PST Return-Path: Redistributed: CommonLoops.PA Received: from WIZARD.OZ.CS.CMU.EDU ([128.2.218.66]) by Xerox.COM ; 20 MAR 90 13:02:58 PST Received: from wizard.oz.cs.cmu.edu by WIZARD.OZ.CS.CMU.EDU id aa06503; 20 Mar 90 16:01:56 EST To: CommonLoops.PA@Xerox.COM Subject: Re: insert classes? In-Reply-To: Your message of Tue, 20 Mar 90 09:38:00 -0800. <19900320173858.8.BOBROW@BULLWINKLE.parc.xerox.com> Date: Tue, 20 Mar 90 16:01:51 EST Message-Id: <6501.637966911@WIZARD.OZ.CS.CMU.EDU> From: Joseph.Bates@WIZARD.OZ.CS.CMU.EDU Danny Bobrow writes, Assume you had started with (defclass a (b) ...) ... Then Evaluate (defclass c (b) ...) [*] [referenced below] and then evaluate: (defclass a (c) ...) CLOS guarantees that the new definition will override the old one and that instances of a will be updated to the new structure the next time a method is called on them. But this requires that the definition of A still be available when C is to be inserted. Is it possible to do the insertion without having to retain the text of the definition of A? That is, using only the info on the line tagged by [*] above? (Or perhaps also using the knowledge that A is a subclass of B.) Joe Bates Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01018; Tue, 20 Mar 90 16:40:10 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 20 MAR 90 14:15:17 PST Return-Path: Redistributed: commonloops.pa Received: from att-in.att.com ([192.20.239.129]) by Xerox.COM ; 20 MAR 90 14:11:28 PST From: lgm@ihlpf.att.com Date: Tue, 20 Mar 90 16:04 CST >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166) To: commonloops.pa@Xerox.COM Subject: Compilation dependencies in CLOS Message-Id: <900320-141517-2123@Xerox> I am examining the issue of CLOS compilation dependencies. One concern is with some redefinition dependencies stated or implied in Steele's CLtL/2e. Pages 686-687 state that the compiler "may also assume that a class defined by DEFCLASS in the compile-time environment will be defined in the run-time environment in such a way as to have the same superclasses and metaclass." Taken to its extreme, this seems to permit an implementation to compile all methods on the assumption of a fixed class inheritance graph, such that any modification of that graph would require massive recompilation. Except during specifically requested "block compilations," I hope that commercial CLOS vendors actually permit the arbitrary modification of superclass lists (with recompilation of only the modified class definition and nothing else). Another concern of mine is with the last sentence on Page 777 of CLtL/2e: "Any accessors specified by WITH-ACCESSORS must already have been defined before they are used." But the use of an accessor is simply an ordinary function call (for a read) or a call to one of the new (SETF ) functions (for a write). Function calls have always been independent of the function's definition; and the new SETF rules described on Page 128 effectively make calls to (SETF ) functions independent of their definition. So why do we need any restriction on WITH-ACCESSORS? I could also ask why WITH-ACCESSORS can't have the same slot-list shorthand that WITH-SLOTS permits, but that's yet another question. A third difficulty I have is with the use of undefined classes. Consider a DEFCLASS which in its superclass list includes a name not yet defined as a class; or a DEFMETHOD which has a parameter specializer name that is not yet defined as a class. Can/Must a CLOS implementation permit such references to undefined classes? If so, does such usage in effect create a "forward-referenced class"? What operations (e.g., FIND-CLASS) are legal on a "forward-referenced class"? When such a class is later defined via DEFCLASS, are all previous references guaranteed to work properly without recompilation? The final question is one of efficiency. Are typical implementations going to penalize any of this independence? In other words, will I be offered two modes, a "development" mode that supports compilation independence but generates poor code and a "production" mode that generates efficient code but imposes onerous compilation dependencies? Unfortunately, I do not have a running version of the latest PCL, so I would also be interested to know how well PCL in particular deals with these concerns. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01147; Tue, 20 Mar 90 16:44:25 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 90 14:59:12 PST Date: Tue, 20 Mar 90 14:57 PST From: Gregor.pa@Xerox.COM Subject: Re: insert classes? To: Petra Sommer Cc: CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9003201422.AA12655@fb14vax.cs.uni-sb.de> Message-Id: <19900320225746.6.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no In Rainy Day PCL, the following function should do what you want: (defun insert-class (class below above) (flet ((get-class (n) (if (pcl::classp n) n (find-class n)))) (let ((c (get-class class)) (b (get-class below)) (a (get-class above))) (reinitialize-instance c :direct-superclasses (list b)) (reinitialize-instance a :direct-superclasses (subst c b (class-direct-superclasses a)))))) if you had (defclass foo () ()) (defclass baz (foo some-other-class) ()) and you wanted to stick bar in between baz and foo, you could say: (defclass bar () ()) (insert-class 'bar 'foo 'baz) ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01339; Tue, 20 Mar 90 16:51:24 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAR 90 15:57:53 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 20 MAR 90 15:56:17 PST Received: by DINO.BBN.COM id aa24770; 20 Mar 90 18:46 EST To: CommonLoops.pa@Xerox.COM Cc: kanderson@DINO.BBN.COM Subject: defconstructor question Date: Tue, 20 Mar 90 19:04:09 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900320-155753-2464@Xerox> I need to do something like: (apply #'make-instance class plist) on large classes, with big plists. Using make-instance this way, is extremely slow. Could defconstructor be used to provide some help with this case? k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05840; Tue, 20 Mar 90 21:00:04 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 20 MAR 90 20:59:50 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 20 MAR 90 20:55:20 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA19196g; Tue, 20 Mar 90 20:52:48 PST Received: by kent-state id AA01416g; Tue, 20 Mar 90 20:54:07 PST Date: Tue, 20 Mar 90 20:54:07 PST From: Jon L White Message-Id: <9003210454.AA01416@kent-state> To: lgm@ihlpf.att.com Cc: commonloops.pa@Xerox.COM In-Reply-To: lgm@ihlpf.att.com's message of Tue, 20 Mar 90 16:04 CST <900320-141517-2123@Xerox> Subject: Compilation dependencies in CLOS You ask some very good questions, Larry, I hope they will be remembered when the X3J13 proposal is sent out for public review. -- Concering the phrase of CLtL/2e "the compiler "may also assume that a class defined by DEFCLASS in the compile-time environment will be defined in the run-time environment in such a way as to have the same superclasses and metaclass." I think you are right in saying that, taken to the extreme, this is an untenable constraint. But I vaguely felt that the tenor of the X3J13 group was that this was a miminal requirement that at ***load-time***, as opposed to the full duration of run-time, the class would be defined as described. It probably didn't get said very well in the X3J13 documents, and hence probably not very well in CLtL/2e, because there was hope by some folks that we could all agree on what a "virtual compilation environment" should mean. When the compiler would encounter a DEFCLASS in a file, it would effectively "evaluate" that form in the virtual environment set up to represent the ultimate runtime image; but it would not evaluate the form in the top-level environment of the compiler's image. The reason for such a plan is somewhat akin to the cross-compilation problem -- that you don't want the mere act of compiling a file that happens to contain definitions contradicting those in the running image to destory that compiler's running image. So "virtual environments" didn't make it. But thinking about them apparently diverted some energy that might otherwise have been spent clarifying paragraphs like the one you quote above. Incidentally, the problem is not limited to DEFCLASS; I think it may not be so easy to ascertain whether the compiler, when encountering a top-level DEFMACRO in a file: (1) must evaluate the defmacro form, possibly "un-doing" the definition at the end of the compile-file (or "compilation unit") scoping; (2) must NOT evaluate the defmacro form; (3) must NOT evaluate the defmacro form, but MUST make it available for macroexpansion in subsequent code to be compiled in the file; (4) choose exactly one of (1), (2), or (3); (5) none of the above. -- Concering the phrase of CLtL/2e: "Any accessors specified by WITH-ACCESSORS must already have been defined before they are used." I think "used" means "actually called, at runtime"; it doesn't mean the more fearsome "referenced by previously processed code". By analogy, any function automatically generated by a :writer slot option must be defined before it is used. Now, in my opinion, this restriction is too trivial to be worth mentioning; and as your extensive critique shows, it even seems to be misleading. -- Concering your question: A third difficulty I have is with the use of undefined classes. Consider a DEFCLASS which in its superclass list includes a name not yet defined as a class; or a DEFMETHOD which has a parameter specializer name that is not yet defined as a class. Can/Must a CLOS implementation permit such references to undefined classes? 88-002R, page 2-24 states that an implementation must allow "forward references" in other class definitions. However it also says that a class must be defined before it may be "used" as a parameter specializer in a method. Effectively, this means that a DEFMETHOD may not be evaluated until all its specialized classes are (fully?) defined. Note that the compiler can compile top-level calls to DEFMETHOD without evaluating them. -- Concering your question: What operations (e.g., FIND-CLASS) are legal on a "forward-referenced class"? When such a class is later defined via DEFCLASS, are all previous references guaranteed to work properly without recompilation? The only "previous references" that could exist are in the superclass lists of other class definitions. A metaobject protocol would permit some way of finding out whether or not a class was "fully defined", meaning none of its direct superclasses are "forward" references, and all of its direct superclasses are themselves fully defined. But alas we didn't get that part of CLOS into the spec -- not even into the "de facto metaobject standard" proposal that Dave Moon and I worked up earlier this year, and which was sent out to selected mailing lists as: Date: Sun, 4 Mar 90 18:28 EST From: David A. Moon Subject: Proposed de facto standard subset of metaobjects To: Common-Lisp-Object-System@MCC.COM . . . However, I did raise just this question to the X3J13 community back in January [and there were no electronic replies, but several verbal replies saying that FIND-CLASS shouldn't "find" forward references]: Date: Wed, 10 Jan 90 05:12:51 PST From: Jon L White To: x3j13@sail.stanford.edu Cc: cl-cleanup@sail.stanford.edu Subject: FIND-CLASS for "forward-referenced" classes? Should FIND-CLASS find a "class" that has only been mentioned in a forward-referenced way, as a direct-superclass of a non-finalized class? Does the name of such "class" constitue a valid type-specifier? E.g., (defclass FOO (BAR) (a b c)) defines a non-finalized class named FOO, but does it define one named BAR? Chapters 1&2 of the CLOS specification do not specify how one should arrange to make "forward" references to superclasses work. Chapter 3 suggest somewhat indirectly an implementation technique of actually creating a class object, to use as a stub, for such a reference. But there seems to be no requirement that it must be implemented this way; some implementations do it this way, and some apparently just keep around internal lists of the class names that were referenced in a "forward" way. Arguing against letting FIND-CLASS return a forward-referenced-class object is that the existence of such an actual class-object is merely an implementational artifact, and may not even be portable. From a larger point of view, one could ask why the mere mention of a potential class named BAR, when defining the class named FOO, should give any legitimate definition for BAR; certainly when you make a forward reference to a function name, you don't define that funcion; i.e. (DEFUN FOO (X) (LIST (BAR X X))) will define FOO, but not define BAR. Arguing for letting *something* find the forward-referenced class is the fact that when using the metaobject protocols in an implementation that supports forward references this way, you will eventually want a handle on the actual object. Finally, it must be asked, what is the behaviour of the type system on non-finalized classes (i.e., classes which have some direct, or even non-direct, superclass that hasn't been defined yet). Clearly, TYPEP is moot, since you can't make instances of non-finalized classes. But what about subtypep? The answer for non-finalized class names probably should be consistent with the answer for forward-referenced class names. One possible alternative is simply to say that the class names (or class objects too) don't become valid type specifiers until the class is fully defined. -- Finally, concering your worry: "... will I be offered two modes, a 'development' mode that supports compilation independence but generates poor code and a 'production' mode that generates efficient code but imposes onerous compilation dependencies?" Well, the *hope* of some of the X3J13 members was that there would be vendors who would offer you that choice. As far as I know now, no commercial vendor is actually planning to do so. There was a VERY interesting research paper presented at the last CLOS workshop (in conjunction with the 1989 OOPSLA conference in New Orleans) by a guy from Coherent Thought; they had essentially done the "production" mode version of CLOS -- at least as far as their application was concerned -- and the overall speed difference was only 25%. Disappointing. That isn't to say that there isn't *some* benchmark to be found that wouldn't show a factor of 3 to 5 speedup by this kind of technology, but that this one naturally occuring application wasn't greatly affected by it. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18674; Thu, 22 Mar 90 06:32:20 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAR 90 16:10:53 PST Return-Path: Redistributed: commonloops.pa Received: from att-in.att.com ([192.20.239.129]) by Xerox.COM ; 21 MAR 90 16:09:54 PST From: lgm@ihlpf.att.com Date: Wed, 21 Mar 90 17:40 CST >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166) To: commonloops.pa@Xerox.COM Subject: Shared slots, and the generality of WITH-ACCESSORS Message-Id: <900321-161053-6016@Xerox> I have a couple more questions/suggestions with regard to CLOS that I'd appreciate comments on. Is there any clear way to refer to a shared slot of a class even if an instance of the class is not available, indeed perhaps before any instance of that class has been made? The standard referencing mechanism is SLOT-VALUE, but it requires an instance. I've heard that the class prototype (if the meta-object protocol specifies it) can access a shared slot, but does even the class prototype exist if no actual instance of the class has been made? It seems that the canonical semantic definition of WITH-ACCESSORS (via SYMBOL-MACROLET) would accommodate not only a standard class' slot accessors, but also any monadic function FUNC having a corresponding (SETF FUNC) function; or even any monadic form FORM having some corresponding SETF form. (Of course, the new rules for SETF guarantee that *every* form FORM has a corresponding SETF form; the default is (SETF FORM).) This use of WITH-ACCESSORS would be a useful shorthand, at least for instances of DEFSTRUCT and in fact for any composite data structure, all the way down to a CONS. WITH-ACCESSORS is then no longer CLOS-specific at all, except for compiler optimizations. For example: (WITH-ACCESSORS ((CAR CAR) (CDR CDR)) CONS (SETF CAR 1) (SETF CDR 2) ) effectively alters the CAR and CDR of CONS to be 1 and 2, respectively. Of course, such usage makes the utility of a shorthand form of WITH-ACCESSORS (analogous to the short form of WITH-SLOTS) more obvious. The shorthand would look like: (WITH-ACCESSORS (CAR CDR) CONS (SETF CAR 1) (SETF CDR 2) ) Is this at all reasonable? Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18851; Thu, 22 Mar 90 06:37:13 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 21 MAR 90 16:21:49 PST Date: Wed, 21 Mar 90 16:20 PST From: Gregor.pa@Xerox.COM Subject: Re: defconstructor question To: kanderso@DINO.BBN.COM Cc: CommonLoops.pa@Xerox.COM, kanderson@DINO.BBN.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: The message of 20 Mar 90 16:04 PST from kanderso@DINO.BBN.COM Message-Id: <19900322002012.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 20 Mar 90 19:04:09 -0500 From: kanderso@DINO.BBN.COM I need to do something like: (apply #'make-instance class plist) on large classes, with big plists. Using make-instance this way, is extremely slow. Could defconstructor be used to provide some help with this case? There is a serious performance bug in the current (Rainy Day) version of PCL. The effect of this bug is to cause MAKE-INSTANCE to be very slow unless it is used through its DEFCONSTRUCTOR interface. I hope to be able to address this bug sometime the week after next. I won't be able to get to it until then, if I can get to it then. If anyone else is interested in tackling it, and wants to hear my ideas about how to generalize the defconstructor mechanism is to a much simpler mechanism which can be used to optimize all calls to make-instance, send me a message. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19061; Thu, 22 Mar 90 06:41:37 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAR 90 06:26:29 PST Return-Path: Redistributed: commonloops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 22 MAR 90 05:20:36 PST Received: by mcsun.EU.net via EUnet; Thu, 22 Mar 90 14:20:30 +0100 (MET) Received: from prl.philips.co.uk by kestrel.Ukc.AC.UK with UUCP id aa03565; 22 Mar 90 13:04 GMT Received: from apollo54.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Thu, 22 Mar 90 12:35:03 gmt From: Ashok Gupta Date: Thu, 22 Mar 90 12:32:07 gmt Message-Id: <1276.9003221232@apollo54.prl.philips.co.uk> To: commonloops.pa@Xerox.COM Subject: Compiling RainyDay in Lucid on Apollo's Having two problems .... 1) RainyDay PCL's not compiling in Lucid 3.00 on an Apollo. Specifically, the problem's in the last form in `env.lisp' :- (eval-when (eval load) (unless (boundp '*old-compile-process-form*) (setq *old-compile-process-form* (symbol-function 'compiler::compile-process-form)) (setf (symbol-function 'compiler::compile-process-form) #'pcl-process-form))) It refers to the COMPILER package which does not exist. Perhaps a dispatching macro is missing; one of #+:Xerox or #+:ExCL (?) or Lucid needs an equivalent form ?. There must be loads of PCL users who also use Lucid so I presume the problem's been identified and the solution's trivial. Perhaps there's a typo somewhere ? ... 2) (pcl::compile-pcl) ... Loading binary of BRAID... Loading binary of FSC... Loading binary of METHODS... Loading binary of COMBIN... >>Error: The symbol *THE-CLASS-STANDARD-OBJECT* has no global value. .... Is it OK to add the following in methods.lisp ? :- (defvar *the-class-standard-object* (find-class 'standard-object)) Thanks Ash Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14680; Thu, 22 Mar 90 22:25:43 -0800 Received: from Salvador.ms by ArpaGateway.ms ; 22 MAR 90 16:28:04 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 22 MAR 90 16:26:34 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA04992g; Thu, 22 Mar 90 16:24:46 PST Received: by kent-state id AA03287g; Thu, 22 Mar 90 16:26:01 PST Date: Thu, 22 Mar 90 16:26:01 PST From: Jon L White Message-Id: <9003230026.AA03287@kent-state> To: gupta@prl.philips.co.uk Cc: commonloops.pa@Xerox.COM In-Reply-To: Ashok Gupta's message of Thu, 22 Mar 90 12:32:07 gmt <1276.9003221232@apollo54.prl.philips.co.uk> Subject: Compiling RainyDay in Lucid on Apollo's Ashok, my copy of "RainyDay" doesn't have any such forms in it as you refer to being in the env.lisp file. I did the FTP'ing on Feb 17, 1990. Gregor: have you updated the sources on arisia after that time? I have used this PCL at Lucid in 3.0 level and 4.0 level images without incident; however, I've not explicitly tried it on an Apollo machine. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11932; Fri, 23 Mar 90 13:39:12 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 90 12:23:58 PST Return-Path: Redistributed: commonloops.pa Received: from uc.msc.umn.edu ([128.101.1.3]) by Xerox.COM ; 23 MAR 90 12:22:28 PST Received: from molbio.cbs.umn.edu by uc.msc.umn.edu (5.59/1.14) id AA17658; Fri, 23 Mar 90 14:22:26 CST From: "Peter N. Saurugger" Message-Id: <9003232023.AA04600@molbio.cbs.umn.edu> Received: by molbio.cbs.umn.edu; Fri, 23 Mar 90 14:23:18 CST Subject: Re: Shared slots, and the generality of WITH-ACCESSORS To: lgm@ihlpf.att.com (Lawrence G Mayka +1 708 713 5166) Date: Fri, 23 Mar 90 14:23:18 CDT Cc: commonloops.pa@Xerox.COM In-Reply-To: <900321-161053-6016@Xerox>; from "Lawrence G Mayka +1 708 713 5166" at Mar 21, 90 5:40 pm X-Mailer: ELM [version 2.3test PL26] > > Is there any clear way to refer to a shared slot of a class even > if an instance of the class is not available, indeed perhaps > before any instance of that class has been made? The standard > referencing mechanism is SLOT-VALUE, but it requires an instance. > I've heard that the class prototype (if the meta-object protocol > specifies it) can access a shared slot, but does even the class > prototype exist if no actual instance of the class has been made? > As I have put to consideration earlier, I would like to support above notion, and extend it to the access of any slot in classes (I would like to access default values in the class where I assign those values). Here is a (moderated) overview of the previous discussions, some of which may be useful to you: Slot descriptions are kept on the class, so you can access the default value with something like: (defun default-value (slot-name class) (slotd-initform (find-slotd 'name (class-slots class)))) -- this works nicely in the case where I used the :initform slot option, but slotd-initform does not access default-values (a class-option). Anyway, this brought me on the track to a possible route, using the accessor class-options on a class-object. --Peter N. Saurugger Molecular Biology Computing Center UofMN Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16411; Fri, 23 Mar 90 17:44:26 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 23 MAR 90 16:48:44 PST Return-Path: Redistributed: commonloops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 23 MAR 90 16:46:37 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA14212g; Fri, 23 Mar 90 16:44:39 PST Received: by kent-state id AA04506g; Fri, 23 Mar 90 16:45:56 PST Date: Fri, 23 Mar 90 16:45:56 PST From: Jon L White Message-Id: <9003240045.AA04506@kent-state> To: peter-s@molbio.cbs.umn.edu Cc: lgm@ihlpf.att.com, commonloops.pa@Xerox.COM In-Reply-To: "Peter N. Saurugger"'s message of Fri, 23 Mar 90 14:23:18 CDT <9003232023.AA04600@molbio.cbs.umn.edu> Subject: Shared slots, and the generality of WITH-ACCESSORS You should be aware that the output of the function SLOTD-INITFORM is a _program_ to be run, which will in turn produce the default value. ("program" == "function of 0 arguments"). Similarly, the output of CLASS-DEFAULT-INITARGS (if there be such a function) would have to be pairings between initarg names (like, :foo) and programs to be run. Each and every call to MAKE-INSTANCE might invoke said programs. The CLOS spec contains very detailed language spelling out just which subset of such programs will be invoked, depending on the class definition and the explicitly passed initargs. But carefully note the following example: (defclass widget () ((frob :initform (progn (punch-paper-tape 3) 15)))) (loop for i from 1 to 10 collect (make-instance 'widget)) The loop will return a list of 10 widgets, each with their 'frob' slots initialized to 15; but 30 feet of paper tape will have been punched as a side-effect too. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27550; Tue, 27 Mar 90 05:20:43 -0800 Received: from Chardonnay.ms by ArpaGateway.ms ; 26 MAR 90 12:30:59 PST Return-Path: Redistributed: CommonLoops.pa Received: from inria.inria.fr ([128.93.8.1]) by Xerox.COM ; 26 MAR 90 10:30:57 PST Received: by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA04193; Mon, 26 Mar 90 18:31:44 +0200 (MET) From: ericd@orion.laas.fr Received: from orion.laas.fr by laas.laas.fr, Mon, 26 Mar 90 16:35:35 +0200 Return-Receipt-To: ericd@orion.laas.fr Received: by orion.laas.fr, Mon, 26 Mar 90 16:38:25 +0200 Date: Mon, 26 Mar 90 16:38:25 +0200 Message-Id: <9003261438.AA22723@orion.laas.fr> To: CommonLoops.pa@Xerox.COM Subject: Examples of Meta-Object Protocol I would very much appreciate some short examples of the use of the Meta-Object Protocol. Gleaning through my archives of Commonloops has not provided much information. Maybe I've missed something. Thanks a lot, Eric Dekneuvel ericd@laas.fr Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27615; Tue, 27 Mar 90 05:25:29 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 27 MAR 90 02:16:13 PST Return-Path: Redistributed: CommonLoops.PA Received: from humu.nosc.mil ([128.49.64.1]) by Xerox.COM ; 27 MAR 90 02:14:23 PST Received: by humu.nosc.mil (5.59/1.27) id AA19343; Tue, 27 Mar 90 00:14:17 HST Date: Tue, 27 Mar 90 00:14:17 HST From: margeris@humu.nosc.mil (Arthur J. Margerison) Message-Id: <9003271014.AA19343@humu.nosc.mil> To: CommonLoops.PA@Xerox.COM Subject: PCL ------- Please add my name to the PCL mailing list. Thanks, A. J. Margerison ------- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04077; Tue, 27 Mar 90 11:01:19 -0800 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 27 Mar 90 12:56:59-CST Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 27 Mar 90 10:55:56 PST Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 768378; 27 Mar 90 13:15:44 EST Date: Tue, 27 Mar 90 13:15 EST From: Sonya Keene Subject: MOP To: common-lisp-object-system@sail.stanford.edu Message-Id: <19900327181541.7.SKEENE@JUNCO.SCRC.Symbolics.COM> Does the current Metaobject Protocol live in a standard place where people can get it over the network? What is the canonical response to information requests about the MOP? Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20192; Thu, 29 Mar 90 14:15:04 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 29 MAR 90 12:09:22 PST Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 29 MAR 90 12:06:59 PST Received: from nitrex.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA29081; Thu, 29 Mar 90 15:05:06 -0500 Date: Thu, 29 Mar 90 15:05:06 -0500 From: macintosh%nitrex.uucp@uunet.uu.net Message-Id: <9003292005.AA29081@uunet.uu.net> Apparently-To: commonloops.pa@xerox.com To Whom It May Concern, I'm trying to get some information on how to obtain a copy of Portable Common Loops that runs in VAX Lisp 3.0 under VMS version 5.2. Any information on how to do this would be greatly appreciated. I should also tell you that I'm interested in obtaining a tape as opposed to FTPing the software. We have high security precautions here at BP America and it is impossible to FTP over an outside network. I will be more than willing to pick up any cost associated with preparing and delivering this tape. Thank you very much! Dr. Doug Mac Intosh BP America Warrensville Research Center 4440 Warrensville Center Road Cleveland, Ohio 44128-2837 Phone: (216) 581-6338 E-Mail: macintosh@bp.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02139; Fri, 30 Mar 90 11:44:22 -0800 Received: from Semillon.ms by ArpaGateway.ms ; 30 MAR 90 10:07:59 PST Return-Path: Redistributed: CommonLoops.pa Received: from risc.com ([130.50.4.1]) by Xerox.COM ; 30 MAR 90 10:06:25 PST Received: from saturn.risc.com by risc.com (4.0/SMI-4.0) id AA04091; Fri, 30 Mar 90 10:06:50 PST Message-Id: <9003301806.AA04091@risc.com> Received: by saturn.risc.com (4.0/SMI-4.0) id AA00711; Fri, 30 Mar 90 09:56:21 PST Date: Fri, 30 Mar 90 09:56:21 PST From: bss@risc.com (Bruce Seely) To: ericd@orion.laas.fr Cc: CommonLoops.pa@Xerox.COM In-Reply-To: ericd@orion.laas.fr's message of Mon, 26 Mar 90 16:38:25 +0200 <9003261438.AA22723@orion.laas.fr> Subject: Examples of Meta-Object Protocol Redistributed: CommonLoops.pa From: ericd@orion.laas.fr Return-Receipt-To: ericd@orion.laas.fr Date: Mon, 26 Mar 90 16:38:25 +0200 I would very much appreciate some short examples of the use of the Meta-Object Protocol. Gleaning through my archives of Commonloops has not provided much information. Maybe I've missed something. Thanks a lot, Eric Dekneuvel ericd@laas.fr Did you get any response to this? I'm also interested in examples of the use of the Meta-Object protocol. I have been watching the list for responses to your question, but haven't seen anything. If people send you stuff, would you mind either posting a summary to the list or at least sending it to me? Thanks much. Bruce Seely bss@risc.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02692; Fri, 30 Mar 90 18:20:55 -0800 Received: from Cabernet.ms by ArpaGateway.ms ; 30 MAR 90 16:11:58 PST Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 30 MAR 90 16:08:17 PST Received: by DINO.BBN.COM id aa03150; 30 Mar 90 18:58 EST To: ericd@orion.laas.fr Cc: CommonLoops.pa@Xerox.COM Subject: Re: Examples of Meta-Object Protocol In-Reply-To: Your message of Mon, 26 Mar 90 16:38:25 +0200. <9003261438.AA22723@orion.laas.fr> Date: Fri, 30 Mar 90 19:09:38 -0500 From: kanderso@DINO.BBN.COM Message-Id: <900330-161158-1318@Xerox> OK, here are some short examples. They might have once run in some PCL. Is that enough of a disclaimer? It is basically a file i have been using for experimentation. I have also added structures to PCL, and others at BBN have added method combination, specialized slots, and various metaclasses to support knowledge based systems. My attempt at Key units is probably incomplete, and people have told me that my imlementation of delegation is wrong. But, i hope this is better than nothing: ;;;-*-Mode:LISP; Package:(PCL LISP 1000000000); Base:10; Syntax:Common-lisp -*- (defclass named-mixin () ((name :initarg :name :initform NIL :reader name))) (defmethod print-object ((thing named-mixin) stream) (printing-random-thing (thing stream) (format stream "~a ~a" (class-name (class-of thing)) (name thing)))) (defclass compatible-class-mixin () () (:documentation "A metaclass mixin that provides compatibility with standard-class.")) (defmethod check-super-metaclass-compatibility ((class compatible-class-mixin) (super standard-class)) t) (defmethod describe ((thing compatible-class-mixin) &rest args) (apply 'describe-instance thing args)) (defclass instances-class-mixin () ((instances :initform () :accessor class-instances)) (:documentation "Lets a class record its instances.")) (defmethod make-instance ((class instances-class-mixin) &rest initargs) (declare (ignore initargs)) (let ((instance (call-next-method))) (add-instance class instance) instance)) (defmethod add-instance ((class instances-class-mixin) instance) (pushnew instance (class-instances class))) (defmethod remove-instance ((class instances-class-mixin) instance) (setf (class-instances class) (delete instance (class-instances class) :test #'eq))) ;;; This version uses :class allocated slots, so each instance knows ;;; who its siblings are but the class doesn't know who its instances ;;; are. (defclass i-mixin () ((instances :initform () :accessor instances :allocation :class))) (defmethod *initialize-instance :before ((object i-mixin) &rest initargs) (pushnew object (instances object))) (defclass foo-x (i-mixin) ((x) (y))) (defclass foo-y (i-mixin) ((z) (y))) #|| ;;; Example. (defclass instance-recording-class (instances-class-mixin compatible-class-mixin standard-class) ()) (defclass ifrob () ((x :initarg x :accessor x) (y :initarg y :accessor y)) (:metaclass instance-recording-class)) (defclass jfrob (ifrob) ((z :initarg x :accessor z)) (:metaclass instance-recording-class)) (setq x (make-instance 'ifrob)) (setq y (make-instance 'jfrob)) (class-instances (find-class 'ifrob)) ||# ;;; Metaclass for allocating objects from a class resource. (defclass resource-allocate-class-mixin () ((resource :initform () :accessor class-resource))) (defmethod allocate-instance ((class resource-allocate-class-mixin) &rest initargs) (or (apply #'resource-allocate class initargs) (call-next-method))) (defmethod resource-allocate ((class resource-allocate-class-mixin) &rest initargs) (declare (ignore initargs)) (pop (class-resource class))) (defmethod deallocate ((instance object)) (deallocate-instance (class-of instance) instance)) (defmethod deallocate-instance ((class resource-allocate-class-mixin) instance) (pushnew instance (class-resource class))) #|| (defclass robot-class (resource-allocate-class-mixin instances-class-mixin standard-class) ()) (defclass robot (named-mixin) () (:metaclass robot-class)) (setq a (make-instance 'robot :name 'mary)) (setq b (make-instance 'robot :name 'ken)) (deallocate b) (setq c (make-instance 'robot :name 'strange)) ||# ;;; ;;; Something like KEY UNITS ;;; (defvar *knowledgebase* NIL) (defclass unit (compatible-class-mixin standard-class) ((kb :initform *knowledgebase* :initarg :kb) (creator :initarg :creator) (date-created :initarg :date-created) (modifier :initarg :modifier) (date-modified :initarg :date-modified) (comment :initarg :comment) (member-parents :initform () :initarg :member-parents :accessor class-member-parents) (own-slots :initform () :initarg :own-slots :accessor class-own-slots))) (defclass classes-2 (unit) () (:metaclass unit)) (defclass entities (unit) () (:metaclass unit)) ;;; ;;; Patch std-class.lisp ;;; KRA 89/3/30: Let class-change happen if the metaclass of a class changes. ;;; ;;; CLASS-FOR-REDEFINITION old-class proto-class name ds-options slotds ;;; protocol: class definition ;;; ;;; When a class is being defined, and a class with that name already exists ;;; a decision must be made as to what to use for the new class object, and ;;; whether to update the old class object. For this, class-for-redefinition ;;; is called with the old class object, the prototype of the new class, and ;;; the name ds-options and slotds corresponding to the new definition. ;;; It should return the class object to use as the new definition. It is ;;; OK for this to be old-class if that is appropriate. ;;; (defmethod class-for-redefinition ((old-class standard-class) (proto-class standard-class) name local-supers local-slot-slotds extra) (declare (ignore name local-supers local-slot-slotds extra)) (UNLESS (EQ (CLASS-OF OLD-CLASS) (CLASS-OF PROTO-CLASS)) (CHANGE-CLASS OLD-CLASS (CLASS-OF PROTO-CLASS))) old-class) (defunit ships (entities) (classes) ((crew)) ()) (defunit sailing-ships (ships) (classes) ((masts) (sails)) ()) (defunit cutty-sark () (sailing-ships) () ((masts :initform 3) (crew :initform 12))) ;;; This is a feable attempt. For each unit named NAME we define a metaclass ;;; NAME-CLASS that provides own-slot inheritance. ;;; With a bit more work, i believe, we could avoid the metaclass, by ;;; rewriting add-named-class to let make-instance take options like ;;; member-parents and own-slots, and return an appropriate instance. ;;; otherwise, how are options to be used, anyway. (defmacro defunit (name superclasses member-parents member-slots own-slots) (let ((*initfunctions* ())) (declare (special *initfunctions*)) (flet ((canonicalize-slot-specifications (slots) (cons 'list (mapcar #'(lambda (spec) (canonicalize-slot-specification name spec)) slots)))) (setq member-slots (canonicalize-slot-specifications member-slots)) (setq own-slots (canonicalize-slot-specifications own-slots)) `(let ,(mapcar #'cdr *initfunctions*) (make-unit ',name ',superclasses ',member-parents ,member-slots ,own-slots))))) (defun make-unit (name superclasses member-parents member-slots own-slots) (add-named-class (class-prototype (find-unit-metaclass name member-parents own-slots)) name superclasses member-slots ())) (defun find-unit-metaclass (name member-parents own-slots) (if (or (cdr member-parents) own-slots) (add-named-class (class-prototype (find-class 'classes)) (intern (format nil "~S-CLASS" name)) member-parents own-slots ()) (find-class (first member-parents)))) (add-named-class -> update-class 1 of supperclasses or member parents is nil. If there are superclasses, this unit is a class. I'ts slots are its own-slots and the slots of its member-parents. (if superclasses ;; Make a class (let* ((metaclass (find-member-parents-class member-parents))) (when own-slots (setq metaclass (add-named-class (class-prototype metaclass) (format nil "~A-CLASS" name) (or member-parents (list (find-class 'classes))) own-slots nil))) (add-named-class (class-prototype metaclass) name superclasses member-slots nil)) ;; Make a member instance (let ((class (if member-parents (find-member-parents-class member-parents) 'entities))) (when own-slots (setq class (add-named-class (class-prototype class) (format nil "~A-CLASS" name) (find-member-parents-class member-parents) own-slots nil))) (*make-instance class :name name)) )) (defclass ships (unit) ((base)) (:metaclass unit)) (defclass frob-1 () (x y) (:metaclass unit)) (defflavor ENTITIES () (classes)) (defclass KNOWLEDGEBASES (classes) ((KBMETHODFILE ()) (KBSIZE 0) (KEE.DEVELOPMENT.VERSION.NUMBER 0) (KEE.MAJOR.VERSION.NUMBER 2) (KEE.MINOR.VERSION.NUMBER 1) (KEE.PATCH.VERSION.NUMBER 3) (KEEVERSION 'KEE2.1) (units (make-hash-table))) (:default-init-plist :kb nil)) ;;; ;;; DELEGATION ;;; (defclass delegate-mixin () ((delegate-to :initform nil :initarg :delegate-to :reader delegate-to ;; No :writer so we can't change delegation, because that may cause ;; invalidating a lot of caches. ))) (defmethod delegate-to ((thing t)) ;; Normally don't delegate. nil) (defmethod no-applicable-method ((gf standard-generic-function) &rest args) ;; Try delegation. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (call-next-method)))) (defmethod delegate ((gf standard-generic-function) &rest args) ;; Delegate is like apply. (let ((method (apply #'find-delegated-method gf args))) (if method (apply method args) (apply #'buck-stops-here gf args)))) (defmethod buck-stops-here ((gf standard-generic-function) &rest args) (error "Sorry, the buck stops here: ~S ~S" gf args)) (defmethod find-delegated-method ((gf standard-generic-function) (client delegate-mixin) &rest args) ;; Try delegating on the first argument. (let ((server (delegate-to client))) (if server (apply #'generic-function-effective-method gf server args)))) (defmethod find-delegated-method ((gf standard-generic-function) thing &rest args) ;; Try delegating on the second argument if there is one. Otherwise just try to ;; find an effective method. (or (and args (let ((server (delegate-to (first args)))) (if server (apply #'generic-function-effective-method gf thing server (cdr args))))) (apply #'generic-function-effective-method gf thing args))) (defmethod generic-function-effective-method ((gf standard-generic-function) &rest args) ;; Returns a function that is the effective method when GF is applied to ARGS. (cdr (last (apply #'lookup-method-internal gf (generic-function-combined-methods gf) #'car args)))) (defmethod slot-missing (class (instance delegate-mixin) slot-name operation &optional new-value) (declare (ignore class)) (let ((server (delegate-to instance))) (if server (if (eq operation 'slot-value) (slot-value server slot-name) (setf (slot-value server slot-name) new-value)) (call-next-method)))) #|| ;;; Example (defclass x-pos () ((x :initarg :x :accessor x))) (defclass y-pos () ((y :initarg :y :accessor y))) (defclass x-point (delegate-mixin x-pos) ()) (defclass horizontal-line (y-pos) ((p1 :accessor p1) (p2 :accessor p2))) (defmethod initialize-instance :after ((instance horizontal-line) &rest initargs) (declare (ignore initargs)) (setf (p1 instance) (*make-instance 'x-point :delegate-to instance :x 0) (p2 instance) (*make-instance 'x-point :delegate-to instance :x 100))) (setq hl (make-instance 'horizontal-line :y 20)) (y (p1 hl)) (y (make-instance 'x-point)) ||# ;;; ;;; Descrimination on non class objects ;;; TABLES: (defmethod table-get ((table list) key) (let ((item (assoc key table))) (if item (values (cdr item) t)))) (defmethod table-get ((table hash-table) key) (gethash key table)) (defmethod (setf table-get) (new (table hash-table) key) (setf (gethash key table) new)) (defmethod (setf table-get) (new (table list) key) (let ((item (assoc key table))) (if item (setf (cdr item) new) (nconc table (list (cons key new)))))) ;;; What if you wanted something that was wrapped in a class wrapper? ;;; It seems that CLASS-OF can't be generic. It requires special information about ;;; each major type of object universe. ;;; Before CLOS: (defmethod add-instance-of ((class class) instance) (pushnew instance (class-instances class)) (add-instance-of-inverse instance class)) ;;; With CLOS: (defmethod add-instance-of :before ((class class) instance) (pushnew instance (class-instances class))) (defmethod add-instance-of :before ((class class) (instance multi-instance-mixin)) (pushnew class (instance-of instance))) (defmethod display-on ((self displayable-object) (window window)) ... draw operations on window ...) (defmethod display-on :around ((self displayable-object) (window careful-window)) (while-drawing-carefully-on (window) (call-next-method))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03441; Tue, 3 Apr 90 20:24:39 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 03 APR 90 12:11:11 PDT Return-Path: Redistributed: CommonLoops.PA Received: from pooh.parc.xerox.com ([13.2.16.167]) by Xerox.COM ; 03 APR 90 12:07:04 PDT Received: from bullwinkle.parc.Xerox.COM by pooh.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02113; Tue, 3 Apr 90 12:06:30 PDT Date: Tue, 3 Apr 90 12:06 PDT From: Danny Bobrow Subject: Re: insert classes? To: Joseph.Bates@WIZARD.OZ.CS.CMU.EDU Cc: CommonLoops.PA@Xerox.COM Message-Id: <19900403190626.2.BOBROW@BULLWINKLE.parc.xerox.com> Date: Tue, 20 Mar 90 16:01:51 EST From: Joseph.Bates@WIZARD.OZ.CS.CMU.EDU Danny Bobrow writes, Assume you had started with (defclass a (b) ...) ... Then Evaluate (defclass c (b) ...) [*] [referenced below] and then evaluate: (defclass a (c) ...) CLOS guarantees that the new definition will override the old one and that instances of a will be updated to the new structure the next time a method is called on them. But this requires that the definition of A still be available when C is to be inserted. Is it possible to do the insertion without having to retain the text of the definition of A? That is, using only the info on the line tagged by [*] above? (Or perhaps also using the knowledge that A is a subclass of B.) Joe Bates Sorry for the delay; I was away. The problem you mention is one reason for have a metaobject protocol, with classes as first class objects. So to do what you want, (defclass c (b) ...) and then (reinitialize-instance (find-class 'a) :direct-superclasses (list (find-class 'c))) This will change the direct-superclasses of A without affecting the rest of its definition (e.g. slots defined, accessors). This works in Rainy Day PCL. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25282; Wed, 4 Apr 90 10:23:28 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 04 APR 90 09:38:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from ygdrasil ([128.32.131.186]) by Xerox.COM ; 04 APR 90 09:35:03 PDT Received: by ygdrasil (5.57/1.37) id AA03082; Wed, 4 Apr 90 09:34:24 PDT Date: Wed, 4 Apr 90 09:34:24 PDT From: faustus@yew.berkeley.edu (Wayne A. Christopher) Message-Id: <9004041634.AA03082@ygdrasil> To: CommonLoops.PA@Xerox.COM Subject: subtypep? It seems that subtypep doesn't work with classes: (defclass foo () ()) (defclass bar (foo) ()) (subtypep 'foo 'bar) nil nil (subtypep 'bar 'foo) nil nil This is Allegro CL 3.1.beta.28 [DEC 3100] (8/3;8/7/89) -- I'm not sure which version of PCL. Is this one of the ways PCL doesn't match CLOS? Is there a list of these differences somewhere? Wayne Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00430; Wed, 4 Apr 90 13:43:37 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 4 Apr 90 15:35:46-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 4 Apr 90 13:34:38 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA02906; Wed, 4 Apr 90 13:35:17 pdt Received: from localhost by hplap.HPL.HP.COM; Wed, 4 Apr 90 13:34:59 pdt Full-Name: Andreas Paepcke Message-Id: <9004042034.AA11896@hplap.HPL.HP.COM> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Call for contribution: A "CLOS Report" Publication X-Mailer: mh6.5 Date: Wed, 04 Apr 90 13:34:57 PDT From: Andreas Paepcke With the standardization of chapters 1 and 2 done and people slaving away at building applications, I feel it is time to make CLOS more accessible to people with various degrees of interest. I am therefore soliciting your help in working towards a publication to accomplish this. I have in mind a collection of papers by members of the CLOS community, which would be published in a place where it is easiliy available to a broad audience. This serves the purpose both of popularizing CLOS and of ensuring recognition for the contributors. The appendix of this message contains a draft of the collection's categorization. I am now looking for participation and/or suggestions to get this project off the ground. Examples: * Does the categorization make sense? * Do you recommend an existing paper to be reprinted in the collection? * Would you like to contribute a new paper? * Do you know of someone else who might be able to contribute? * Can you volunteer to help with the editing process? If you can produce a paper, I would very much like to hear from you informally soon. It is enough to explain which category you want to address and very roughly what you have in mind. This will make planning a lot easier because it will help me decide which contributions I must actively reach out for to get coverage. Please help me gather some of this data by the end of April. As a separate project, I am organizing this year's CLOS Users and Implementors Workshop to be held in the context of OOPSLA '90. I will send out the call for participation as soon as the OOPSLA administration gives a green light. This should be by May 28. Even though the Workshop is separate from the publication described here, there will be linkage in that work done for the Workshop can find its way into the publication. Hoping to hear from you soon, Andreas Hewlett-Packard Laboratory Palo Alto, Ca 94304 paepcke@hplabs.hp.com 415-857-7398 ;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;; %----------------------------------------------------- % Summary Categorization of Papers %--------------------------------- Prologue: What is it like to build a language? Short introduction to CLOS Applications Contrasting CLOS with other languages CLOS Analysis and Discussion CLOS implementations Open research issues Glossary Annotated Bibliography Index over all papers Author Index Prologue: What is it like to build a language? ---------------------------------------------- Audience: General, not necessarily CLOS or even language-oriented. Example contents: - How were existing languages used as blueprints? - How was the design effort organized? - Comments on PCL's implementation and distribution. - Honestly: Was CLOS designed top-down, bottom-up, upside-down, inside-out or without any of the fashionable CASE disciplines? - How did the standardization process work? Any advice for others who want to standardize something? Short introduction to CLOS: --------------------------- Very top level, a few pages that make a casual reader aware of what CLOS is about. If someone has heard the term "CLOS" a lot and wants to know what it is, this should be the place to go to. Example contents: - The five CLOS building blocks. - A few programming examples. - Maybe the architecture (MOP concept). - References to more in-depth sources. Applications: ------------- Contributions in this category should go into some depth. While some parts could be accessible to a casually browsing audience, other parts of the contributions should satisfy a more serious reader who is considering the use of CLOS for her own purposes. Example contents: - What does the application do? - Why was CLOS chosen as the implementation language in the first place? - Where did CLOS shine for the application, where did it weaken or fail? There might be a discussion of how other languages would have worked out for this particular application. - How did the language affect the application design? - How is the application delivered? (ex: Is there a small CLOS delivery kernel?) Contrasting CLOS with other languages: -------------------------------------- Contributions may be arbitrarily complex and specialized, although it would be good to have one or two papers accessible to an interested computer scientist who knows some other object-oriented language and wants an easy way of finding the correct mental pigeon hole for CLOS. It would be nice if contributions were dialectic. Maybe two or more authors with violently different opinions could get together and produce one sharp-edged discussion. Example contents: - Strong and weak points of CLOS vs. other languages. - Classification of languages along a particular theme (ex: realization of functional programming, extensibility, oop philosophy, speed/functionality tradeoffs, etc.) - Classification of applications by which languages would be optimal for their realizations. CLOS Analysis and Discussion: ----------------------------- This is for very CLOS-specific contributions. Like papers in the "language contrasting" category, possibly combative, but *technical* pro/con flames combined into one paper would be interesting if they help to focus a reader's attention on some CLOS aspect. Example contents: - Was the MOP a good idea? - Is the MOP-level class hierarchy sensible? - What were the CLOS architectural tradeoffs? Why were particular alternatives chosen? - Which tradeoffs were resolved to CLOS' detriment. CLOS implementations: --------------------- This is to be a non-commercial category. Papers may point out implementation issues, even if the author(s) have not produced any implementation themselves. Example contents: - Which parts of CLOS are easy to implement, which are hard? - Are there clever optimization opportunities? - Are there language aspects that should have been defined differently, given the experience gained from an actual implemention process. Open research issues: --------------------- The audience for papers in this category would be a competent computer scientist looking for something to do. Example contents: - Anything Glossary: --------- Short definitions of CLOS terms. Annotated Bibliography: ----------------------- This is to cover the range from casual interest to very specific CLOS issues. It would be nice if this could be a union of the bibliographies of the papers. Index ----- Terms, concepts, etc. covering all the papers. Author Index ------------ Names and addresses Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00460; Wed, 4 Apr 90 13:45:31 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 04 APR 90 13:37:41 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.176.66]) by Xerox.COM ; 04 APR 90 13:35:21 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA02906; Wed, 4 Apr 90 13:35:17 pdt Received: from localhost by hplap.HPL.HP.COM; Wed, 4 Apr 90 13:34:59 pdt Full-Name: Andreas Paepcke Message-Id: <9004042034.AA11896@hplap.HPL.HP.COM> To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Call for contribution: A "CLOS Report" Publication X-Mailer: mh6.5 Date: Wed, 04 Apr 90 13:34:57 PDT From: Andreas Paepcke With the standardization of chapters 1 and 2 done and people slaving away at building applications, I feel it is time to make CLOS more accessible to people with various degrees of interest. I am therefore soliciting your help in working towards a publication to accomplish this. I have in mind a collection of papers by members of the CLOS community, which would be published in a place where it is easiliy available to a broad audience. This serves the purpose both of popularizing CLOS and of ensuring recognition for the contributors. The appendix of this message contains a draft of the collection's categorization. I am now looking for participation and/or suggestions to get this project off the ground. Examples: * Does the categorization make sense? * Do you recommend an existing paper to be reprinted in the collection? * Would you like to contribute a new paper? * Do you know of someone else who might be able to contribute? * Can you volunteer to help with the editing process? If you can produce a paper, I would very much like to hear from you informally soon. It is enough to explain which category you want to address and very roughly what you have in mind. This will make planning a lot easier because it will help me decide which contributions I must actively reach out for to get coverage. Please help me gather some of this data by the end of April. As a separate project, I am organizing this year's CLOS Users and Implementors Workshop to be held in the context of OOPSLA '90. I will send out the call for participation as soon as the OOPSLA administration gives a green light. This should be by May 28. Even though the Workshop is separate from the publication described here, there will be linkage in that work done for the Workshop can find its way into the publication. Hoping to hear from you soon, Andreas Hewlett-Packard Laboratory Palo Alto, Ca 94304 paepcke@hplabs.hp.com 415-857-7398 ;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;; %----------------------------------------------------- % Summary Categorization of Papers %--------------------------------- Prologue: What is it like to build a language? Short introduction to CLOS Applications Contrasting CLOS with other languages CLOS Analysis and Discussion CLOS implementations Open research issues Glossary Annotated Bibliography Index over all papers Author Index Prologue: What is it like to build a language? ---------------------------------------------- Audience: General, not necessarily CLOS or even language-oriented. Example contents: - How were existing languages used as blueprints? - How was the design effort organized? - Comments on PCL's implementation and distribution. - Honestly: Was CLOS designed top-down, bottom-up, upside-down, inside-out or without any of the fashionable CASE disciplines? - How did the standardization process work? Any advice for others who want to standardize something? Short introduction to CLOS: --------------------------- Very top level, a few pages that make a casual reader aware of what CLOS is about. If someone has heard the term "CLOS" a lot and wants to know what it is, this should be the place to go to. Example contents: - The five CLOS building blocks. - A few programming examples. - Maybe the architecture (MOP concept). - References to more in-depth sources. Applications: ------------- Contributions in this category should go into some depth. While some parts could be accessible to a casually browsing audience, other parts of the contributions should satisfy a more serious reader who is considering the use of CLOS for her own purposes. Example contents: - What does the application do? - Why was CLOS chosen as the implementation language in the first place? - Where did CLOS shine for the application, where did it weaken or fail? There might be a discussion of how other languages would have worked out for this particular application. - How did the language affect the application design? - How is the application delivered? (ex: Is there a small CLOS delivery kernel?) Contrasting CLOS with other languages: -------------------------------------- Contributions may be arbitrarily complex and specialized, although it would be good to have one or two papers accessible to an interested computer scientist who knows some other object-oriented language and wants an easy way of finding the correct mental pigeon hole for CLOS. It would be nice if contributions were dialectic. Maybe two or more authors with violently different opinions could get together and produce one sharp-edged discussion. Example contents: - Strong and weak points of CLOS vs. other languages. - Classification of languages along a particular theme (ex: realization of functional programming, extensibility, oop philosophy, speed/functionality tradeoffs, etc.) - Classification of applications by which languages would be optimal for their realizations. CLOS Analysis and Discussion: ----------------------------- This is for very CLOS-specific contributions. Like papers in the "language contrasting" category, possibly combative, but *technical* pro/con flames combined into one paper would be interesting if they help to focus a reader's attention on some CLOS aspect. Example contents: - Was the MOP a good idea? - Is the MOP-level class hierarchy sensible? - What were the CLOS architectural tradeoffs? Why were particular alternatives chosen? - Which tradeoffs were resolved to CLOS' detriment. CLOS implementations: --------------------- This is to be a non-commercial category. Papers may point out implementation issues, even if the author(s) have not produced any implementation themselves. Example contents: - Which parts of CLOS are easy to implement, which are hard? - Are there clever optimization opportunities? - Are there language aspects that should have been defined differently, given the experience gained from an actual implemention process. Open research issues: --------------------- The audience for papers in this category would be a competent computer scientist looking for something to do. Example contents: - Anything Glossary: --------- Short definitions of CLOS terms. Annotated Bibliography: ----------------------- This is to cover the range from casual interest to very specific CLOS issues. It would be nice if this could be a union of the bibliographies of the papers. Index ----- Terms, concepts, etc. covering all the papers. Author Index ------------ Names and addresses Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26414; Thu, 5 Apr 90 12:50:01 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 05 APR 90 09:54:03 PDT Return-Path: Redistributed: CommonLoops.PA Received: from uc.msc.umn.edu ([128.101.1.3]) by Xerox.COM ; 05 APR 90 09:50:43 PDT Received: from molbio.cbs.umn.edu by uc.msc.umn.edu (5.59/1.14) id AA09027; Thu, 5 Apr 90 11:50:47 CDT Date: Thu, 5 Apr 90 10:38:52 CDT From: "Peter N. Saurugger" Message-Id: <9004051538.AA10656@molbio.cbs.umn.edu> Received: by molbio.cbs.umn.edu; Thu, 5 Apr 90 10:38:52 CDT To: faustus@yew.berkeley.edu Subject: Re: subtypep? Cc: CommonLoops.PA@Xerox.COM It's not only subtypep, but also type-of doesn't behave as described e.g. in S.Keene 's book. Since she must have had a working version of the language, I wonder which version it is (was). I am using the rainy day PCL as supplied with ALlegro CL (on a SparcStation). Some anonymous "iwmc-class" is returned for all PCL objects instead of their proper class type: (defclass foo () ()) (defclass bar (foo) ()) (subtypep 'foo 'bar) nil nil (type-of 'bar) symbol (type-of (class-of 'bar)) iwmc-class (setq *bar* (make-instance 'bar)) # (type-of *bar*) iwmc-class (class-of *bar*) # (type-of (class-of *bar*)) iwmc-class Peter Norbert Saurugger MBCC, UofMN Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26640; Thu, 5 Apr 90 12:59:09 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 05 APR 90 10:56:17 PDT Date: Thu, 5 Apr 90 10:44 PDT From: Gregor.pa@Xerox.COM Subject: Re: subtypep? To: Peter N. Saurugger Cc: faustus@yew.berkeley.edu, CommonLoops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9004051538.AA10656@molbio.cbs.umn.edu> Message-Id: <19900405174447.4.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no If you read far enough back in the notes.text files you will find something about this. The general idea is that PCL doesn't want to redefine existing functions in Common Lisp. So, what it does is define other functions with `similar' names that can be used instead. In the newest version of PCL, I believe there are functions called PCL:TYPEP, PCL:SUBTYPEP and PCL:TYPE-OF which should do what you want. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28503; Thu, 5 Apr 90 14:53:36 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 05 APR 90 13:38:26 PDT Return-Path: Redistributed: CommonLoops.PA Received: from ygdrasil ([128.32.131.186]) by Xerox.COM ; 05 APR 90 13:35:36 PDT Received: by ygdrasil (5.57/1.37) id AA03904; Thu, 5 Apr 90 13:34:52 PDT Date: Thu, 5 Apr 90 13:34:52 PDT From: faustus@yew.berkeley.edu (Wayne A. Christopher) Message-Id: <9004052034.AA03904@ygdrasil> To: Gregor.pa@Xerox.COM Cc: peter-s@molbio.cbs.umn.edu, CommonLoops.PA@Xerox.COM In-Reply-To: Gregor.pa@Xerox.COM's message of Thu, 5 Apr 90 10:44 PDT <19900405174447.4.GREGOR@SPIFF.parc.xerox.com> Subject: subtypep? I was under the impression that you could define a CL type to be a subtype of another one, which would allow PCL to use the same mechanism, but I guess you can't do that. Thanks for the info, Wayne Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12117; Thu, 5 Apr 90 22:14:48 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 05 APR 90 21:17:32 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 05 APR 90 21:15:24 PDT Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA28788g; Thu, 5 Apr 90 21:12:54 PDT Received: by kent-state id AA02253g; Thu, 5 Apr 90 21:14:05 PDT Date: Thu, 5 Apr 90 21:14:05 PDT From: Jon L White Message-Id: <9004060414.AA02253@kent-state> To: faustus@yew.berkeley.edu, Gregor.pa@Xerox.COM Cc: peter-s@molbio.cbs.umn.edu, CommonLoops.PA@Xerox.COM In-Reply-To: Wayne A. Christopher's message of Thu, 5 Apr 90 13:34:52 PDT <9004052034.AA03904@ygdrasil> Subject: subtypep? re: I was under the impression that you could define a CL type to be a subtype of another one, which would allow PCL to use the same mechanism, but I guess you can't do that. Thanks for the info, I know this may sound a bit pedagogical, but the type system of CL is just a "mathematical langauge" of __type specifiers__; DEFTYPE does not provide any mechanism for new, structured data definitions. True, there are a few built-in mappings from type-specifiers to primitive data objects -- CONS, INTEGER etc, -- but the *only* extension mechanism in CL which allows new TYPE's to be assigned to new categories of objects is DEFSTRUCT. Since PCL choose to implement objects of metaclass STANDARD-CLASS as little defstruct instances, then an unmodified CL implementation must report them as such. Actually, consider the alternatives in the portable subset of all Common Lisp implementations. Were standard-object's implemented as, say, simple-vector's or cons's, then I'm sure you be much more unhappy with the resulting type confusions. The X3J13 committee in fact had to add some additional requirements of disjointedness for built-in types in Common Lisp -- primarily so that classes could unambiguously be assigned for an interesting subset of built-in types. Remember: not all CL types have classes behind them; and as a mathematical language, there are infinitely many CL types which denote the same set of objects [Exercise: find three more type specifiers denoting the same set of objects as (UNSIGNED-BYTE 8).] As a consequence of several X3J13 proposals, one may deduce that the set of objects in any "standard" class must be disjoint from the set of objects in any "structure" class; and this implies that no type specifier can simultaneously refer to both of them [because the intersection of two such classes is null.] Although you could construct a type (i.e., type specifier) that represents the union of these two classes -- e.g., (OR ) I don't believe that CLOS implementations will allow you to construct a class that is effectively the union of these two classes. The CLOS proposal X3J13/88-002R may not explicitly forbid this situation, but implementations are typically done in such a way that no "structure" class can have a a "standard" class as a super-class, and vice-versa. PCL enforces this restriction by means of methods on the generic function CHECK-SUPER-METACLASS-COMPATIBILITY. A consequence of the above comments is that no portable program (such as PCL) can hope to compensate completely for the deficiencies of the 1984 Common Lisp data typing system; that is why the proposed ANSI Common Lisp will be slightly different, and hopefully slightly better, than the 1984 version. Although user's programs may postpone some of the difficulties by calling PCL:SUBTYPEP instead of LISP:SUBTYPEP, they will not be able (in a portable way) to fix up the internal calls that a particular CL implementaion may make to LISP:SUBTYPEP, and to other internal functions like it. I apologize for this note dragging on for so long; but the topic is often filled with confusion or misinformation. If I haven't been moderately clear in my comments above, then please contact me privately first, and perhaps we can "debug" a better explanation of the CL type system constraints before flooding the net with all the intermediate comments. -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04713; Fri, 6 Apr 90 14:19:49 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 6 Apr 90 16:14:22-CDT Received: from siemens.siemens.com (siemens-gw.siemens.com) by SAIL.Stanford.EDU with TCP; 6 Apr 90 14:13:01 PDT Received: by siemens.siemens.com (5.54/1.15) id AA10380; Fri, 6 Apr 90 17:14:02 EST Received: by demon.siemens.com (5.57/RTL-CLIENT-SUBSIDIARY) id AA17011; Fri, 6 Apr 90 17:13:28 EDT Date: Fri, 6 Apr 90 17:13:28 EDT From: liu@demon.siemens.com (Peiya Liu) Message-Id: <9004062113.AA17011@demon.siemens.com> To: Common-Lisp-Object-System@sail.stanford.edu Subject: Including my name in your mailing address I wonder if you could include my e-mail address:liu@siemens.com in your mailing list. I hope to get regular messages from this newsgroup. Thanks for attention. Peiya ----- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06717; Mon, 9 Apr 90 06:42:40 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 08 APR 90 04:32:32 PDT Return-Path: Redistributed: commonloops.PA Received: from life.ai.mit.edu ([128.52.32.80]) by Xerox.COM ; 08 APR 90 04:31:23 PDT Received: from cocoa-krispies (cocoa-krispies.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA19576; Sun, 8 Apr 90 07:31:32 EDT From: sbchanin@ai.mit.edu (Steve Chanin) Received: by cocoa-krispies (4.0/AI-4.10) id AA07159; Sun, 8 Apr 90 07:30:54 EDT Date: Sun, 8 Apr 90 07:30:54 EDT Message-Id: <9004081130.AA07159@cocoa-krispies> To: commonloops.PA@Xerox.COM Subject: Porting code to new PCL Reply-To: sbchanin@ai.mit.edu An MIT class for which I'm the teaching assistant has course software which was written to run with old versions of pcl and lucid. I was trying to patch it so, I could bring it up on the unix boxes in the AI lab which run Lucid version 3 (the code now runs with an old version of pcl on Lucid 2.x). Iftp a copy of the new release of pcl from xerox.com and it compiles fine on a sparc. However when I try to compile the clas software I get all kinds of conflicts between methods with the same name (defined on different classes) which have different numbers of arguments. Are there any PCL wizards out there how would be willing to talk to me about this stuff? Thanks, Steve P.S. - Some of the files have (defclass foo ..) and (defmethod bar ...) in the same file, so I put in the two (pushnew 'compile ...) described in the notes. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21174; Mon, 9 Apr 90 14:51:27 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 90 11:36:32 PDT Return-Path: Redistributed: commonloops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 09 APR 90 11:29:17 PDT To: sbchanin@ai.mit.edu Cc: commonloops.PA@Xerox.COM Subject: Re: Porting code to new PCL In-Reply-To: Your message of Sun, 08 Apr 90 07:30:54 -0400. <9004081130.AA07159@cocoa-krispies> Date: Mon, 09 Apr 90 14:47:36 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900409-113632-6534@Xerox> Redistributed: commonloops.PA From: Steve Chanin Date: Sun, 8 Apr 90 07:30:54 EDT To: commonloops.PA@xerox.com Subject: Porting code to new PCL Reply-To: sbchanin@ai.mit.edu An MIT class for which I'm the teaching assistant has course software which was written to run with old versions of pcl and lucid. I was trying to patch it so, I could bring it up on the unix boxes in the AI lab which run Lucid version 3 (the code now runs with an old version of pcl on Lucid 2.x). Iftp a copy of the new release of pcl from xerox.com and it compiles fine on a sparc. However when I try to compile the clas software I get all kinds of conflicts between methods with the same name (defined on different classes) which have different numbers of arguments. Are there any PCL wizards out there PCL now enforce lambda list congruency between all methods of a generic function. So you will have to change your defmethods. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21246; Mon, 9 Apr 90 14:54:44 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 90 11:46:16 PDT Date: Mon, 9 Apr 90 11:36 PDT From: Gregor.pa@Xerox.COM Subject: Re: Porting code to new PCL To: sbchanin@ai.mit.edu Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9004081130.AA07159@cocoa-krispies> Message-Id: <19900409183648.3.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no The section on congruence of lambda lists is on page 791 in the new edition of Steele. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21380; Mon, 9 Apr 90 15:00:03 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 90 11:45:00 PDT Date: Mon, 9 Apr 90 11:35 PDT From: Gregor.pa@Xerox.COM Subject: Re: Porting code to new PCL To: sbchanin@ai.mit.edu Cc: commonloops.PA@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9004081130.AA07159@cocoa-krispies> Message-Id: <19900409183524.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Sun, 8 Apr 90 07:30:54 EDT From: sbchanin@ai.mit.edu (Steve Chanin) An MIT class for which I'm the teaching assistant has course software which was written to run with old versions of pcl and lucid. I was trying to patch it so, I could bring it up on the unix boxes in the AI lab which run Lucid version 3 (the code now runs with an old version of pcl on Lucid 2.x). Iftp a copy of the new release of pcl from xerox.com and it compiles fine on a sparc. However when I try to compile the clas software I get all kinds of conflicts between methods with the same name (defined on different classes) which have different numbers of arguments. Are there any PCL wizards out there how would be willing to talk to me about this stuff? It sounds like the code in question isn't legal CLOS code. Specifically, it sounds like it has lambda list congruence errors. You need to look at the section of chapter 1 (which in my printing of the spec is on age 1-25) which lays out the congruence for methods of a generic function. Earlier versions of PCL were more lenient about this which is why the code used to work. There is also information about this in some of the recent xxx-notes.text files, you might want to read those. ------- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04520; Wed, 11 Apr 90 14:07:14 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 11 Apr 90 15:41:19-CDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 90 13:40:02 PDT Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 90 13:35:45 PDT Date: Wed, 11 Apr 90 13:34 PDT From: Gregor.pa@Xerox.COM Subject: Re: Call for contribution: A "CLOS Report" Publication To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <19900411011133.2.GREGOR@SPIFF.parc.xerox.com> Message-Id: <19900411203426.8.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no I want to apologize to the many hundreds of people who, because of my ineptitude, received copies of a message I meant to send only to Andreas Paepcke. Gregor ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03374; Fri, 13 Apr 90 16:11:32 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 13 APR 90 14:10:36 PDT Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 13 APR 90 14:08:47 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@DINO.BBN.COM Subject: CLOS Caches Clash Date: Fri, 13 Apr 90 17:24:39 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900413-141036-21090@Xerox> The following patch fixes a bug in Victoria Day PCL (sorry we're still using it). Running generic functions in parallel process could let use the same cache. Rainy PCL puts WITHOUT-INTERRUPTS around the equivalent pieces of code. This code uses SI:STORE-CONDITIONAL which is machine specific but much nicer. Perhaps PCL should provide something like it for those implementations who can handle it. k ;;; Accessing the cache cache must be atomic. ;;; PCL should have a STORE-CONDITIONAL function defined in LOW.LISP (defun get-generic-function-cache (size) (let* ((expt (floor (log size 2))) (thread (* expt 2)) (count (1+ thread)) (existing nil)) (when (>= count (array-dimension *free-generic-function-caches* 0) 2) (error "Generic function cache of unprecedented size returned.")) (setq existing (svref *free-generic-function-caches* thread)) (cond ((null existing) (incf (svref *free-generic-function-caches* count)) (make-generic-function-cache size)) ((SI:STORE-CONDITIONAL (SCL:LOCF(svref *free-generic-function-caches* thread)) existing (svref existing 0)) (flush-generic-function-caches-internal existing) existing) (T (GET-GENERIC-FUNCTION-CACHE SIZE))))) ; Try again (defun free-generic-function-cache (cache) (let* ((size (array-dimension cache 0)) (expt (floor (log size 2))) (thread (* expt 2)) (count (1+ thread))) (when (>= count (array-dimension *free-generic-function-caches* 0) 2) (error "Generic function cache of unprecedented size returned.")) (setf (svref cache 0) (svref *free-generic-function-caches* thread)) (OR (SI:STORE-CONDITIONAL (SI:LOCF (SVREF *FREE-GENERIC-FUNCTION-CACHES* THREAD)) (SVREF *FREE-GENERIC-FUNCTION-CACHES* THREAD) CACHE) (FREE-GENERIC-FUNCTION-CACHE CACHE)))) ; Try again Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09235; Mon, 16 Apr 90 22:16:16 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 16 APR 90 10:54:57 PDT Date: Mon, 16 Apr 90 10:53 PDT From: Gregor.pa@Xerox.COM Subject: Re: Pre-compiling methods To: George Williams Cc: commonloops.pa@Xerox.COM Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9004102056.AA11476@huntsai.boeing.com> Message-Id: <19900416175319.2.GREGOR@SPIFF.parc.xerox.com> Line-Fold: no Date: Tue, 10 Apr 90 15:56:25 cdt From: george@huntsai.boeing.com (George Williams) I've been told that the "Rainy Day (beta 3)" version of PCL doesn't actually compile the methods until they are used. In some implementations, such as Mac Allegro CL, when we're trying to build stand alone applications, the compiler is not present in the generated application. Yes, PCL doesn't compile the effective (often called combined) methods until they are used. Is there a mechanism to compile all of the methods that have been defined, but not referenced, so that when the (stand-alone) application is generated all of the methods will be present? PCL has a feeble mechanism called (precompile-random-code-segments). In order for it to work you must have, at some point, run your application through enough of its paces that all the combined methods will be used. It is pretty easy to do something better, which just generates and compiles the methods. This is one of the many things I plan to leave to the vendors to do. I believe that at this point, at least one of them has done it. Perhaps someone can send out some portable code that does this. ------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06333; Tue, 17 Apr 90 21:04:08 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 17 APR 90 20:08:53 PDT Return-Path: Redistributed: CommonLoops.PA Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 17 APR 90 20:07:11 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15112; Tue, 17 Apr 90 20:07:36 PDT Date: Tue, 17 Apr 90 20:07 PDT From: Gregor J. Kiczales Subject: a time for everything To: CommonLoops.PA@Xerox.COM Message-Id: <19900418030711.2.GREGOR@SPIFF.parc.xerox.com> In the past couple of weeks I have had a number of conversations with various Lisp vendors about their CLOS implementation plans. As most of you know, a number of vendors have already released their own native CLOS implementations. Other vendors have been planning to base their initial CLOS products on enhanced versions of PCL. It now appears to be the case that the last of the vendors planning to base their initial implementations on PCL have begun the modifications they plan to make. They are now off on their own track. This is great news, it means that no matter what Common Lisp you use, you will soon have access to a supported, product-quality CLOS implementation. It also implies that the PCL development effort here at PARC has come to a natural transition point. It is now time for PCL development to subside and let vendor development take over. The vendors will be able to do things that never could happen in PCL. In order to facilitate the transition to the various vendor-specific CLOS implementations, and to help all existing PCL users wait until their vendor has an implementation available, I plan to coordinate one more release of PCL. This release will be Rainy Day PCL, with the various patches that have been suggested since it was sent out. IF YOU HAVE SUCH A PATCH, PLEASE SEND IT TO ME EVEN IF YOU HAVE SENT IT BEFORE. We will also provide a permanent home (on arisia.xerox.com) for copies of the PCL sources and related public domain CLOS code. In the future, if you have modifications to PCL or other code you would like to store on arisia, contact me and I will help coordinate this. In addition, to provide a forum for CLOS users to discuss the language and their work with it, PARC will continue to maintain the CommonLoops@xerox.com mailing list. I want to thank all the people who have, in the past few years, helped with PCL. I especially want to thank all of those patient PCL users. Your use of PCL, and the comments you made, provided a lot of feedback to the CLOS design group. This feedback helped shape CLOS into the language it is today. Gregor Kiczales Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19219; Wed, 18 Apr 90 05:52:22 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 18 APR 90 05:52:02 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 18 APR 90 05:50:13 PDT To: "Gregor J. Kiczales" Cc: CommonLoops.PA@Xerox.COM Subject: Re: a time for everything In-Reply-To: Your message of Tue, 17 Apr 90 20:07:00 -0700. <19900418030711.2.GREGOR@SPIFF.parc.xerox.com> Date: Wed, 18 Apr 90 09:03:36 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900418-055202-6991@Xerox> Redistributed: CommonLoops.PA Date: Tue, 17 Apr 90 20:07 PDT From: "Gregor J. Kiczales" Subject: a time for everything To: CommonLoops.PA@xerox.com ... It now appears to be the case that the last of the vendors planning to base their initial implementations on PCL have begun the modifications they plan to make. They are now off on their own track. This is great news, it means that no matter what Common Lisp you use, you will soon have access to a supported, product-quality CLOS implementation. This may be a sign of CLOS' maturity, but a vendor CLOS is pretty useless for some of us until it supports a MOP. The job isn't done until then. It could be a Rainy Day for a long time. ... I want to thank all the people who have, in the past few years, helped with PCL. I especially want to thank all of those patient PCL users. Your use of PCL, and the comments you made, provided a lot of feedback to the CLOS design group. This feedback helped shape CLOS into the language it is today. Thank you too, Gregor. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20162; Wed, 18 Apr 90 06:48:00 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 18 APR 90 06:47:30 PDT Return-Path: Redistributed: CommonLoops.PA Received: from caf.MIT.EDU ([18.62.0.232]) by Xerox.COM ; 18 APR 90 06:44:34 PDT Received: from DARJEELING.MIT.EDU by caf.MIT.EDU with SMTP id AA29995; Wed, 18 Apr 90 09:44:17 -0400 Date: Wed, 18 Apr 90 09:44 EDT From: Michael McIlrath Subject: Re: a time for everything To: kanderso@DINO.BBN.COM Cc: CommonLoops.PA@Xerox.COM In-Reply-To: <900418-055202-6991@Xerox> Message-Id: <19900418134440.6.MBM@DARJEELING.MIT.EDU> Date: Wed, 18 Apr 90 09:03:36 -0400 From: kanderso@DINO.BBN.COM Redistributed: CommonLoops.PA Date: Tue, 17 Apr 90 20:07 PDT From: "Gregor J. Kiczales" Subject: a time for everything To: CommonLoops.PA@xerox.com ... It now appears to be the case that the last of the vendors planning to base their initial implementations on PCL have begun the modifications they plan to make. They are now off on their own track. This is great news, it means that no matter what Common Lisp you use, you will soon have access to a supported, product-quality CLOS implementation. This may be a sign of CLOS' maturity, but a vendor CLOS is pretty useless for some of us until it supports a MOP. The job isn't done until then. It could be a Rainy Day for a long time. Hear, hear. ... I want to thank all the people who have, in the past few years, helped with PCL. I especially want to thank all of those patient PCL users. Your use of PCL, and the comments you made, provided a lot of feedback to the CLOS design group. This feedback helped shape CLOS into the language it is today. Thank you too, Gregor. Hear, hear!! Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21532; Thu, 19 Apr 90 00:46:40 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 18 APR 90 15:20:04 PDT Return-Path: <@ugw.utcs.utoronto.ca:dave@metform.Eng.McMaster.CA> Redistributed: Commonloops.pa Received: from ugw.utcs.utoronto.ca ([128.100.100.3]) by Xerox.COM ; 18 APR 90 15:18:14 PDT Received: from McMaster.CA (stdin) by ugw.utcs.utoronto.ca with BSMTP id 58614; Wed, 18 Apr 90 18:13:15 EDT Received: from GRAvax.McMaster.CA by McMaster.CA; Wed, 18 Apr 90 18:14 EDT Received: from metform.Eng.McMaster.CA by GRAvax.McMaster.CA; Wed, 18 Apr 90 17:19 EDT Received: by metform.Eng.McMaster.CA (4.0/SMI-4.0) id AA02625; Wed, 18 Apr 90 17:16:46 EDT Date: Wed, 18 Apr 90 17:16:46 EDT From: Dave Lentz Subject: browser To: Commonloops.pa@Xerox.COM Message-Id: <9004182116.AA02625@metform.Eng.McMaster.CA> Hi. I was able to connect with the xerox.com machine last week, but for the last couple of days connection has been refused. I am interested in the browser, and webeditor i saw under /pcl directory. Can you provide general info on these (just a couple of lines on their purpose). Also how do i ftp to the machine. Dave Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04329; Thu, 19 Apr 90 04:54:32 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 19 APR 90 01:46:11 PDT Return-Path: <@CUNYVM.CUNY.EDU:SP1@IPG.PH.KCL.AC.UK> Redistributed: CommonLoops.PA Received: from arisia.Xerox.COM ([13.1.100.206]) by Xerox.COM ; 19 APR 90 01:44:28 PDT Received: from cunyvm.cuny.edu by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23491; Thu, 19 Apr 90 01:44:35 -0700 Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 5076; Thu, 19 Apr 90 04:43:44 EDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1857; Thu, 19 Apr 90 09:41:57 BST Via: UK.AC.KCL.PH.IPG; 19 APR 90 9:41:51 BST Date: Thu, 19 APR 90 09:41:34 BST From: SP1%IPG.PH.KCL.AC.UK@CUNYVM.CUNY.EDU To: CommonLoops.PA@arisia.Xerox.COM Subject: Subscription request Sender: JANET "SP1@UK.AC.KCL.PH.IPG" Message-Id: <24A033B3_000DB788.009356E1B07ED980$4_1@UK.AC.KCL.PH.IPG> Originally-To: EARN"CommonLoops.PA@Arisia.Xerox.COM" Originally-From: PHCLUS::SP1 "Simon Protheroe" Mailer: Janet_Mailshr V3.4 (23-May-1989) Please could you add me to the CommonLoops mailing list. My apologies if this request should have gone somewhere else - I tried a couple of obvious candidates, but they bounced my mail Many thanks, Simon Protheroe sp1@ipg.ph.kcl.ac.uk Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00575; Thu, 19 Apr 90 17:18:15 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 19 APR 90 13:24:38 PDT Return-Path: Redistributed: commonloops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 19 APR 90 13:22:01 PDT Return-Path: Received: from LocalHost by ra.cs.ucla.edu (Sendmail 5.61a+YP/2.10) id AA24221; Thu, 19 Apr 90 13:25:32 -0700 Message-Id: <9004192025.AA24221@ra.cs.ucla.edu> To: CommonLoops.PA@Xerox.COM Subject: precompile-random-code-segments Date: Thu, 19 Apr 90 13:25:24 PDT From: mujica@CS.UCLA.EDU in notes.text 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 What is a ? Is this a package name? Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01636; Thu, 19 Apr 90 17:57:12 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 19 APR 90 14:35:55 PDT Return-Path: Redistributed: CommonLoops.PA Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 19 APR 90 14:33:46 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23524; Thu, 19 Apr 90 14:33:38 PDT Date: Thu, 19 Apr 90 14:33 PDT From: Gregor J. Kiczales Subject: Re: precompile-random-code-segments To: mujica@CS.UCLA.EDU Cc: CommonLoops.PA@Xerox.COM In-Reply-To: <9004192025.AA24221@ra.cs.ucla.edu> Message-Id: <19900419213311.6.GREGOR@SPIFF.parc.xerox.com> is the name of your program. So, if you have a bunch of files that make a system called CAD-TOOLS, you would put the symbol CAD-TOOLS in for . Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA04547; Thu, 19 Apr 90 19:52:38 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 19 APR 90 19:51:35 PDT Return-Path: Redistributed: commonloops.pa Received: from relay.cc.u-tokyo.ac.jp ([192.41.197.3]) by Xerox.COM ; 19 APR 90 19:50:25 PDT Received: from ccut.cc.u-tokyo.ac.jp by relay.cc.u-tokyo.ac.jp (5.61/2.7W) id AA21027; Fri, 20 Apr 90 11:50:18 +0900 Received: from aoyama.cc.aoyama.ac.jp by ccut.cc.u-tokyo.ac.jp (5.61/6.4J.6-ut2.53) id AA09907; Fri, 20 Apr 90 11:50:13 +0900 Received: by aoyama.cc.aoyama.ac.jp (4.0/6.4J.6-agu4) id AA15911; Fri, 20 Apr 90 11:50:00 JST Received: by kepa.cc.aoyama.ac.jp (4.0/6.4J.5-aguac) id AA08213; Fri, 20 Apr 90 11:49:10 JST Date: Fri, 20 Apr 90 11:49:10 JST From: Masayuki Ida Return-Path: Message-Id: <9004200249.AA08213@kepa.cc.aoyama.ac.jp> To: gregor@parc.xerox.com Cc: commonloops.pa@Xerox.COM, ida@cc.aoyama.ac.jp Subject: Metaclass bug in Rainy Day PCL ? I received the following log from Mr. Noritoshi Rokujo @ Fujitsu. I think something is wrong with Rainy Day version, since the same code is OK with Victoria Day. Masayuki Ida Aoyama Gakuin Univ. PS: Thank you Gregor for your continuous efforts on PCL. You did great jobs on object oriented world for Common Lisp and on mutual understanding between US and Japan. -- simplified sources causing problems -- ;;;-*- Mode:Lisp;Package:PCL;Base:10;Syntax:Common-Lisp; -*- ;;; (in-package 'pcl) (defclass my-metaclass (standard-class) ()) (defmethod check-super-metaclass-compatibility ((class my-metaclass) (super standard-class)) t) (defclass box01 ()() (:metaclass my-metaclass)) (defclass box02 ()() (:metaclass my-metaclass)) (defclass box03 ()() (:metaclass my-metaclass)) (defclass box04 ()() (:metaclass my-metaclass)) (defclass box05 ()() (:metaclass my-metaclass)) (defmethod open-box ((arg1 box01)) (format t "This is a instance of BOX01~%")) (defmethod open-box ((arg1 box02)) (format t "This is a instance of BOX02~%")) (defmethod open-box ((arg1 box03)) (format t "This is a instance of BOX03~%")) (defmethod open-box ((arg1 box04)) (format t "This is a instance of BOX04~%")) (defmethod open-box ((arg1 box05)) (format t "This is a instance of BOX05~%")) ----- A session causes unexpected actions ----- > (open-box (make-instance 'box01)) This is a instance of BOX01 NIL > (open-box (make-instance 'box02)) This is a instance of BOX02 NIL > (open-box (make-instance 'box03)) This is a instance of BOX02 NIL > (open-box (make-instance 'box04)) This is a instance of BOX02 NIL > (open-box (make-instance 'box05)) This is a instance of BOX02 NIL ----- box03, box4, box5 cases are incorrect ----- testes with the following: SUN3-60 SunOS4.0.3 SunCommonLisp(Lucid CommonLisp) 3.0.1 2/16/90 Rainy Day PCL (beta 3) ----------------------------------------------------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09484; Thu, 19 Apr 90 23:52:41 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 19 APR 90 23:50:10 PDT Return-Path: Redistributed: commonloops.pa Received: from ra.cs.ucla.edu ([131.179.128.33]) by Xerox.COM ; 19 APR 90 23:48:36 PDT Return-Path: Received: from LocalHost by ra.cs.ucla.edu (Sendmail 5.61a+YP/2.10) id AA24821; Thu, 19 Apr 90 23:51:35 -0700 Message-Id: <9004200651.AA24821@ra.cs.ucla.edu> To: Gregor J. Kiczales Cc: mujica@CS.UCLA.EDU, CommonLoops.PA@Xerox.COM Subject: Re: precompile-random-code-segments In-Reply-To: Your message of Thu, 19 Apr 90 14:33:00 -0700. <19900419213311.6.GREGOR@SPIFF.parc.xerox.com> Date: Thu, 19 Apr 90 23:51:32 PDT From: mujica@CS.UCLA.EDU on Thu, 19 Apr 90 14:33 PDT, Gregor J. Kiczales said: > is the name of your program. So, if you have a bunch > of files that make a system called CAD-TOOLS, you would put the symbol > CAD-TOOLS in for . I am still unclear about this. What is a system? How does PCL know about systems? I am running Lucid Lisp under SunOS 4.0. There is no functionality for defining a "system" in my environment. Should I use your defsystem function? Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27311; Fri, 20 Apr 90 09:16:23 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 20 APR 90 07:15:23 PDT Return-Path: Redistributed: commonloops.pa Received: from fs3.cs.rpi.edu ([128.213.4.10]) by Xerox.COM ; 20 APR 90 07:12:36 PDT Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept) id AA07855; Fri, 20 Apr 90 10:08:36 EDT Date: Fri, 20 Apr 90 10:08:30 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA17937; Fri, 20 Apr 90 10:08:30 EDT Message-Id: <9004201408.AA17937@turing.cs.rpi.edu> To: ida@cc.aoyama.ac.jp Subject: Re: Metaclass bug in Rainy Day PCL ? Cc: commonloops.pa@Xerox.COM There is a bug in the handling of specializers having user-defined metatypes in Rainy Day PCL. The following patch, which is part of a group of patches that I sent to the commonloops list on March 7, will improve things. Your example works correctly in my copy of Rainy Day PCL, which contains all the patches I sent to the list on March 7 and 9. Richard Harris ==================== Problem: raise-metatype should return T only when the specializer is T. raise-metatype does not recognize specializers having non-standard metaclasses. cache.lisp raise-metatype Change: (class-of (class-of (eql-specializer-object x))) (class-of x)))) (cond ((eq x *the-class-t*) t) ! ((eq meta-specializer standard) 'standard-instance) ! ((eq meta-specializer fsc) 'standard-instance) ! ; ((eq meta-specializer structure) 'structure-instance) ! ((eq meta-specializer built-in) 'built-in-instance) ! (t 't))))) To: (class-of (class-of (eql-specializer-object x))) (class-of x)))) (cond ((eq x *the-class-t*) t) ! ((*subtypep meta-specializer standard) 'standard-instance) ! ((*subtypep meta-specializer fsc) 'standard-instance) ! ; ((*subtypep meta-specializer structure) 'structure-instance) ! ((*subtypep meta-specializer built-in) 'built-in-instance) ! (t (error "PCL can not handle the specializer ~S~ ! (meta-specializer ~S)" new-specializer meta-specializer)))))) ==================== Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27630; Fri, 20 Apr 90 18:05:44 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 90 10:37:00 PDT Return-Path: Redistributed: CommonLoops.PA Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 20 APR 90 10:30:50 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26828; Fri, 20 Apr 90 10:30:27 PDT Date: Fri, 20 Apr 90 10:29 PDT From: Gregor J. Kiczales Subject: Re: precompile-random-code-segments To: mujica@CS.UCLA.EDU Cc: CommonLoops.PA@Xerox.COM In-Reply-To: <9004200651.AA24821@ra.cs.ucla.edu> Message-Id: <19900420172958.4.GREGOR@SPIFF.parc.xerox.com> PCL doesn't know about systems, this doesn't have anything to do with a defsystem facility. Its just a way of saying these are the precompilations for your program to keep them separate from the precompilations for someone else's program. Put your name there if you like, it will work as well as anything else. This facility doesn't really work all that well. As I said a few days ago, most of the vendors have improved it. One this those improvements do is they get rid of the having to put a silly name there. Maybe we will get a patch to PCL that makes this fix from someone. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28454; Thu, 26 Apr 90 05:55:29 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 25 APR 90 03:58:30 PDT Return-Path: Redistributed: Commonloops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 25 APR 90 03:57:24 PDT Received: by mcsun.EU.net with SMTP; Wed, 25 Apr 90 12:57:29 +0200 (MET) Received: from gmdzi.gmd.DE by unido.informatik.uni-dortmund.de with SMTP via EUnet (UNIDO-2.0.1.h) via EUnet for mcsun.eu.net id AM15778; Wed, 25 Apr 90 12:56:41 +0100 Received: by gmdzi.UUCP id AA05018; Wed, 25 Apr 90 12:57:44 -0200 Message-Id: <9004251057.AA05018@gmdzi.UUCP> To: Commonloops.pa@Xerox.COM Subject: Mailing List Request Date: Wed, 25 Apr 90 12:57:43 +0100 From: thomas%gmdzi.uucp@relay.eu.net Hello! Please remove my e-mail address from the Commonloops mailing list. Thank you, Tom Gordon Thomas F. Gordon email: thomas@gmdzi.uucp GMD / F3 phone: (+49 2241) 14-2665 Schloss Birlinghoven D-5205 Sankt Augustin 1, FRG Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28484; Thu, 26 Apr 90 05:59:32 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 25 APR 90 03:41:28 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lanai.cs.ucla.edu ([131.179.128.13]) by Xerox.COM ; 25 APR 90 03:40:02 PDT Received: by lanai.cs.ucla.edu (Sendmail 5.61a+YP/2.31) id AA08053; Wed, 25 Apr 90 03:40:03 -0700 Date: Wed, 25 Apr 90 03:40:03 PDT From: Trent Lange Message-Id: <900425.104003z.07820.lange@lanai.cs.ucla.edu> To: Gregor J. Kiczales Cc: CommonLoops.PA@Xerox.COM Subject: Accessor performance In-Reply-To: Message of Tue, 17 Apr 90 20:07 PDT from "Gregor J. Kiczales " <19900418030711.2.GREGOR@SPIFF.parc.xerox.com> There is a major performance decrease in Rainy Day pcl for the standard slot accessor methods when a standard method with the same name exists for another class. e.g. (defclass a () ((param1 :accessor param1 :initform 'param1-default))) (defclass b () ()) (defmethod param1 ((self b)) 'b-param1-value) I couldn't figure out the reason for it, but it seems pcl resorts to calling slot-value-using-class (rather than the standard-reader-method?) in these kinds of cases. This slows slot access down by a factor of 5. On the other hand, the time to call a standard accessor method on an object seems to be (basically) unaffected by whether other objects have the same slot accessor name defined, and the time to call standard methods seems (basically) unaffected by the number of same-named standard methods and accessor methods. It therefore doesn't seem that the slowed standard slot access is caused by added overhead on calculating method combination. Is there some way that pcl could be changed to use the normal standard-reader/writer-methods at all times, rather than using slot-value-using-class when standard methods exists? - Trent Lange Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17064; Fri, 27 Apr 90 14:10:05 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 27 APR 90 10:43:51 PDT Return-Path: Redistributed: CommonLoops.pa Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 27 APR 90 10:38:41 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23436; Fri, 27 Apr 90 10:38:29 PDT Date: Fri, 27 Apr 90 10:37 PDT From: Gregor J. Kiczales Subject: Re: problem/suggestion To: Don Cohen Cc: goldman@vaxa.isi.edu, CommonLoops.pa@Xerox.COM In-Reply-To: <9004271719.AA07004@vaxa.isi.edu> Message-Id: <19900427173753.9.GREGOR@SPIFF.parc.xerox.com> Date: Fri, 27 Apr 90 10:19:54 PDT From: Don Cohen I'm running :RAINY-DAY-PCL on symbolics genera7.2 and having problems with a method that has a large number (~200) of methods specialized by EQL. (It's a code walker and methods are specialized by lisp functions/special forms/macros/ ...) The problem seems to be in get-normal-secondary-dispatch-function calling get-function calling get-function-generator calling get-new-function-generator calling the compiler with a lambda expression containing a very long argument list. (Is this really necessary?) Also, generate-discrimination-net seems to (in addition to running a long time) produce a terrible algorithm. Instead of compiling into a deeply nested conditional, I suggest a hashtable for all the EQL methods (if there are more than some threshold number). It is true that the Rainy Day PCL implementation of EQL specializers is pretty bad. Its almost as bad as EQL specializers themselves! I am not going to fix this, because PCL development is now essentially over. In your particular case, where the code in question sounds like it is program or at the very least macro generated, you might want to consider switching away from using EQL specializers to using a hash table. Use the hash table for the discrimination on individual objects (symbols in your case) and use generic function for discrimination on classes. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16383; Tue, 1 May 90 00:48:36 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 30 APR 90 15:30:21 PDT Return-Path: Redistributed: commonloops.pa Received: from rand.org ([192.5.14.33]) by Xerox.COM ; 30 APR 90 15:29:10 PDT Received: from bedrock.rand.org by rand.org; Mon, 30 Apr 90 15:24:54 -0700 Received: from localhost by bedrock.rand.org; Mon, 30 Apr 90 15:25:04 PDT Message-Id: <9004302225.AA15414@bedrock.rand.org> To: commonloops.pa@Xerox.COM, cl-windows@sail.stanford.edu Cc: hefley%bedrock@rand.org, dave%rincon@rand.org Subject: hypercard for CL and cwo Date: Mon, 30 Apr 90 15:25:01 PDT From: hefley%bedrock@rand.org Hi, I'm wondering if anyone knows of hypercard systems with hooks into Common Lisp, preferably with hooks into X, and ideally with hooks into an object-oriented system, like CLOS. If anyone has some information, I'd appreciate it if you could send me a message. Thanks in advance, Charlene Hefley hefley@rand.org Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19956; Tue, 1 May 90 18:18:07 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 90 12:55:52 PDT Return-Path: Redistributed: CommonLoops.pa Received: from linus.mitre.org ([129.83.10.1]) by Xerox.COM ; 30 APR 90 12:52:39 PDT Return-Path: Received: from clouseau.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA09918; Mon, 30 Apr 90 15:50:53 -0400 Full-Name: John D. Burger Posted-Date: Mon, 30 Apr 90 15:50:46 EDT Received: by clouseau.mitre.org (5.61/RCF-4C) id AA01654; Mon, 30 Apr 90 15:50:50 -0400 From: john@linus.mitre.org Message-Id: <9004301950.AA01654@clouseau.mitre.org> To: CommonLoops.pa@Xerox.COM Subject: #:TOP-LEVL-FORM-FROM-HELL Date: Mon, 30 Apr 90 15:50:46 EDT Sender: john@linus.mitre.org -------- In Rainy Day PCL, in Genera 7.2, nothing seems to know about any real generic functions or methods. Everything is an internal function of a function like #:TOP-LEVEL-FORM1941. In my archives, I noticed a message that seemed to refer to a fix that Mike Thome sent out, possibly for an earlier version of PCL. I can't find the fix, however. If anyone does have this fix, can you send it along? These top-level-form functions are driving me crazy. How is anyone able to debug PCL programs with these things in them? - John Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20154; Tue, 1 May 90 18:31:45 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 01 MAY 90 18:29:51 PDT Return-Path: Redistributed: CommonLoops.pa Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 01 MAY 90 18:28:43 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09323; Tue, 1 May 90 18:29:20 PDT Date: Tue, 1 May 90 18:28 PDT From: Gregor J. Kiczales Subject: new version of PCL To: CommonLoops.pa@Xerox.COM Message-Id: <19900502012839.6.GREGOR@SPIFF.parc.xerox.com> There is a new version of PCL on arisia.xerox.com. This version, May Day PCL, is essentially Rainy Day PCL plus most of the various patches people have mailed out. The patches that didn't get included were the ones that had more to do with the programming environment. Barring unforseen circumstances, this is the last release of PCL I will produce. Gregor Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22619; Tue, 1 May 90 21:12:50 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 01 MAY 90 21:12:45 PDT Return-Path: Redistributed: commonloops.pa Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 01 MAY 90 21:11:04 PDT Received: by atc.boeing.com on Tue, 1 May 90 21:09:42 PDT Date: Tue, 1 May 90 21:15 PDT From: Stephen L. Nicoud Subject: RE: new version of PCL To: commonloops.pa@Xerox.COM In-Reply-To: The message of 1 May 90 19:22 PDT from Gregor J. Kiczales Message-Id: <19900502041542.3.SLN@SKAGIT.atc.boeing.com> Date: 2 May 90 02:22:49 GMT From: Gregor J. Kiczales There is a new version of PCL on arisia.xerox.com. In defclass.lisp of May Day PCL, system:*compiler-message-string* should be lucid::*compiler-message-string*. Steve Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26283; Wed, 2 May 90 00:23:08 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 90 00:22:40 PDT Sender: "MAZIERE_TAURAN_CHRISTOPHE.CBVMANRXF"@Xerox.COM Date: 2 May 90 00:17:01 PDT (Wednesday) Subject: Re: new version of PCL From: CMT.CBVMANRXF@Xerox.COM To: gregor@parc.xerox.com Cc: CommonLoops.PA@Xerox.COM Message-Id: <900502-002240-3491@Xerox> Gregor, Can you put the new version of PCL on {NB:PARC:XEROX} for me please? Christophe. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22752; Wed, 2 May 90 15:47:11 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 MAY 90 08:32:11 PDT Return-Path: Redistributed: CommonLoops.pa Received: from inria.inria.fr ([128.93.8.1]) by Xerox.COM ; 02 MAY 90 08:29:03 PDT Received: by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA05068; Wed, 2 May 90 17:25:38 +0200 (MET) From: ralph@orion.laas.fr Received: from orion.laas.fr by laas.laas.fr, Wed, 2 May 90 14:37:40 +0200 Return-Receipt-To: ralph@orion.laas.fr Received: by orion.laas.fr, Wed, 2 May 90 14:42:05 +0200 Date: Wed, 2 May 90 14:42:05 +0200 Message-Id: <9005021242.AA03783@orion.laas.fr> To: Gregor J. Kiczales Cc: CommonLoops.pa@Xerox.COM In-Reply-To: <19900502012839.6.GREGOR@SPIFF.parc.xerox.com> Subject: Re: new version of PCL Reply-To: ralph@orion.laas.fr In <<19900502012839.6.GREGOR@SPIFF.parc.xerox.com>> Gregor J. Kiczales writes: | There is a new version of PCL on arisia.xerox.com. | | Barring unforseen circumstances, this is the last release of PCL I will | produce. Thanks a lot for the continued support. Will the Meta Object Protocol documentation ever come out, now? 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 =============================================================================== Reliable software should kill people reliably! -Andy Mickel, Pascal News #13,78 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24490; Wed, 2 May 90 17:21:07 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 90 12:23:03 PDT Return-Path: Redistributed: CommonLoops.PA Received: from boulder.Colorado.EDU ([128.138.238.18]) by Xerox.COM ; 02 MAY 90 12:17:56 PDT Return-Path: Received: by boulder.Colorado.EDU (cu-hub.890824) Received: by newsigi.colorado.edu (cu.generic.890828) From: Andreas Girgensohn Message-Id: <9005021915.AA29681@newsigi.colorado.edu> Subject: Re: #:TOP-LEVL-FORM-FROM-HELL To: CommonLoops.PA@Xerox.COM (PCL Mailing List), john@linus.mitre.org Date: Wed, 2 May 90 13:15:33 MDT In-Reply-To: <20519@boulder.Colorado.EDU>; from ": john@linus.mitre.org" at May 2, 90 2:21 am X-Mailer: ELM [version 2.2 PL16] > In Rainy Day PCL, in Genera 7.2, nothing seems to know about any real > generic functions or methods. Everything is an internal function > of a function like #:TOP-LEVEL-FORM1941. In my archives, I noticed > a message that seemed to refer to a fix that Mike Thome sent out, > possibly for an earlier version of PCL. I can't find the fix, however. > > If anyone does have this fix, can you send it along? These top-level-form > functions are driving me crazy. How is anyone able to debug PCL programs > with these things in them? > > - John I'm very disappointed that Mike Thome's enhancements have not been included in May Day PCL. To make things worse the call to gensym in make-top-level-form has been replaced by a call to make-symbol. Now all methods have the same name in Genera. I repost Mike's enhancements (I hope he doesn't mind). They worked in Rainy Day PCL (I have not tested them in May Day PCL). One small patch: (arglist fn) in pcl-fdefine-helper has to be replaced by (cadr (assoc 'pcl-lambda-list dlist)). Andreas Girgensohn andreasg@boulder.colorado.edu ------------------------------------------------------------------------------ >From: Mike Thome Subject: PCL enhancement for Genera (7.x: x>2) Date: 10 Feb 90 09:28:19 GMT Below is a patch for PCL which teaches Genera 7.2 (&7.4) to understand pcl-method function specs of the form `(METHOD ,gf-name ,@method-qualifiers (,@method-specializers)) and PCL (2/8/90 Beta 2) to use 'em. These mods may be used in a base compile to get rid of all those ugly gensymed top-level-form symbols in warnings, and (as a side effect) makes M-. and who-calls work nicely. Enjoy! -mik (mthome@bbn.com, mthome@thalamus.bu.edu) . . . . . . . . . . . . . . . . . . . . . . . . ;;; -*- Package: PCL -*- ;;; This set of mods alters the behavior of defmethod so that it works ;;; correctly with the symbolics debugging & loading systems. ;;; ;;; Based on Beta2 2/8/90 PCL ;;; ;;; Notes: ;;; 1. we no longer need to rely on the TOP-LEVEL hack. ;;; 2. defmethods expand into DEFUNs (which get thier bodies compiled... even on ;;; smbx!) and we rely on the fspec mechanism to do the load-defmethod. ;;; 3. This is a (working) second cut, so the code is pretty ugly, and only ;;; minimally modifies original code (leaving various warnings, etc). ;;; 4. See code for more details ;;; ;;; -mike thome (mthome@bbn.com): 6 Feb 90 ;;; ;; New (& complete) fspec handler. ;; 1. uses a single #'equal htable where stored elements are (fn . plist) ;; (maybe we should store the method object instead) ;; 2. also implements the fspec-plist operators here. ;; 3. fdefine not only stores the method, but actually does the loading here! ;; ;;; ;;; genera-low.lisp (replaces old method-function-spec-handler) ;;; ;; New (& complete) fspec handler. ;; 1. uses a single #'equal htable where stored elements are (fn . plist) ;; (maybe we should store the method object instead) ;; 2. also implements the fspec-plist operators here. ;; 3. fdefine not only stores the method, but actually does the loading here! ;; (defvar *method-htable* (make-hash-table :test #'equal :size 500)) (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)))))) ;; this guy is just a stub to make the fspec handler simpler (and so I could trace it ;; easier). (defun pcl-fdefine-helper (gspec qualifiers specializers fn) (let* ((dlist (scl:debugging-info fn)) (class (cadr (assoc 'pcl-method-class dlist))) (doc (cadr (assoc 'pcl-documentation dlist))) (plist (cadr (assoc 'pcl-plist dlist)))) (load-defmethod (or class 'standard-method) gspec qualifiers specializers (arglist fn) doc (getf plist :isl-cache-symbol) plist fn))) ;; define a few special declarations to get pushed onto the function's debug-info ;; list... note that we do not need to do a (proclaim (declarations ...)) here. ;; (eval-when (compile load eval) (setf (get 'pcl-plist 'si:debug-info) t) (setf (get 'pcl-documentation 'si:debug-info) t) (setf (get 'pcl-method-class 'si:debug-info) t) (setf (get 'pcl-lambda-list 'si:debug-info) t) ) ;;; ;;; boot.lisp (expand-defmethod for genera *only*, and addition to ;;; 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) (declare (ignore doc plist)) (let ((fn-args (cadadr fn-form)) (fn-body (cddadr fn-form))) `(defun (method ,name ,@qualifiers ,specializers) ,fn-args (declare ,@(when proto-method `((pcl-method-class ,(class-name (class-of proto-method))))) (pcl-lambda-list ,(specialized-lambda-list-lambda-list lambda-list))) ,@fn-body)))) ;; this is also modified (mt) (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))) (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)))))))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24608; Wed, 2 May 90 17:29:45 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 02 MAY 90 06:45:29 PDT Return-Path: Redistributed: commonloops.pa Received: from mcsun.EU.net ([192.16.202.1]) by Xerox.COM ; 02 MAY 90 06:43:10 PDT Received: by mcsun.EU.net with SMTP; Wed, 2 May 90 15:43:05 +0200 (MET) Received: from coeur by hp4nl.nluug.nl with UUCP via EUnet id AA17965 (5.58.1.14/2.14); Wed, 2 May 90 15:44:45 MET Received: by coeur.UUCP; Wed, 2 May 90 15:35:50 +0200 (MET) Date: Wed, 2 May 90 15:35:50 +0200 From: keulen%coeur.uucp@relay.eu.net (Hans van Keulen) Organisation: Courseware Europe b.v. Ebbehout 1 1507 EA Zaandam, The Netherlands Phone: +31 75 172201 Fax: +31 75 311502 Message-Id: <9005021335.AA23954@coeur.UUCP> To: commonloops.pa@Xerox.COM Subject: PCL-CLOS compatibility Hi, We are considering to use PCL for building a prototype for one of the DELTA projects of the European Community. We will be using Xerox-1186 machines with Xerox-Medley and a Sun 3/60 with Sun Common Lisp. However, we are afraid of two things: 1) PCL may deviate from the CLOS standard (X3J13) unnoticedly: > Date: Wed, 31 Jan 90 20:41 PST > From: Gregor.pa@Xerox.COM > Subject: Re: Benchmarking CLOS ..... > 2) PCL is not CLOS. PCL is a portable implementation with some > interesting architectural ideas, I believe it can be made to > perform relatively well, but most of the current ports do not > perform adequately. > 3) Not all ports of PCL are created equal. The P in PCL means > that PCL can be ported relatively easily, not that it is written > in pure Common Lisp. 2) PCL may contain unexpected bugs. Two things which may result in quite time-consumable activities (and headache evoking). We would like to hear about experiences of others in using PCL and opinions on whether it is a good idea to use it (there is of course a trade-off in using plain Common Lisp and a non-optimum PCL). We would also like to know how or where, if available, we can get an overview of the differences between PCL and CLOS. Hans van Keulen Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25669; Wed, 2 May 90 18:39:05 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 MAY 90 08:19:24 PDT Return-Path: Redistributed: CommonLoops.pa Received: from src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 02 MAY 90 08:16:16 PDT Return-Path: Received: by src.honeywell.com (4.0/smail2.6.3/SRCv0.25); Wed, 2 May 90 10:16:14 CDT id AA29906 for CommonLoops.pa@xerox.com at xerox.com Posted-Date: 2 May 90 15:16:12 GMT To: CommonLoops.pa@Xerox.COM Path: srcsip!gendibal!alarson From: alarson@SRC.Honeywell.COM (Aaron Larson) Newsgroups: ext.commonloops Subject: Re: new version of PCL Message-Id: <70249@srcsip.UUCP> Date: 2 May 90 15:16:12 GMT References: <70163@srcsip.UUCP> Sender: news@src.honeywell.COM Lines: 1 In-Reply-To: Gregor J. Kiczales's message of 2 May 90 02:23:59 GMT It looks like cpatch and quadlap have been omitted from pcl/tarfile. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25968; Wed, 2 May 90 18:48:06 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 02 MAY 90 13:40:22 PDT Return-Path: Redistributed: commonloops.pa Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 02 MAY 90 13:37:39 PDT Received: by atc.boeing.com on Wed, 2 May 90 13:36:14 PDT Date: Wed, 2 May 90 13:42 PDT From: Stephen L. Nicoud Subject: problem with &key args in defmethod? To: commonloops.pa@Xerox.COM Cc: Stephen L. Nicoud Message-Id: <19900502204216.4.SLN@SKAGIT.atc.boeing.com> (defclass a () nil) (defmethod a-m1 ((self a) &optional (a-opt :jumbo) &key (a-key :mumbo)) (with-slots nil self (format t "~s, ~s" a-opt a-key))) This simple example using Rainy and May Day PCL (but not Victoria Day) causes my Sun/Lucid CL 3.0.2 image to break with: ">>Trap: Bus error" on the defmethod form. In fact, I have several defmethod's that crash the system in this manner. The only thing I see that they have in common is &key arguments. It compiles okay in Victoria Day PCL in Lucid3.0.2 and on my Genera 7.2 system using May Day. I haven't tried it in Victoria or Rainy Day PCL on Genera 7.2. Appended is the macroexpansion I get on the Lucid 3.0.2 May Day defmethod form and after that a listing from the debugger. Any ideas on this? Thanks for your assistance. Steve -- Stephen L. Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences (COMPILER-LET ((LUCID::*COMPILER-MESSAGE-STRING* (OR LUCID::*COMPILER-MESSAGE-STRING* "(DEFMETHOD A-M1 (A))"))) (EVAL-WHEN (COMPILE LOAD EVAL) (PCL::LOAD-DEFMETHOD 'STANDARD-METHOD 'A-M1 'NIL (LIST 'A) '(SELF &OPTIONAL (A-OPT :JUMBO) &KEY (A-KEY :MUMBO)) 'NIL 'NIL 'NIL #'(LAMBDA (SELF &OPTIONAL (A-OPT :JUMBO) &KEY (A-KEY :MUMBO) &ALLOW-OTHER-KEYS) (DECLARE (PCL::CLASS SELF A) (OPTIMIZE (:FAST-ENTRY T))) (PROGN SELF) (BLOCK A-M1 ((LAMBDA NIL (DECLARE (OPTIMIZE (:FAST-ENTRY T))) (LET ((#:VALUE5737 SELF)) (DECLARE (PCL::VARIABLE-REBINDING #:VALUE5737 SELF)) #:VALUE5737 (FORMAT T "~s, ~s" A-OP A-KEY))))))))) > (compile-file "~/key-bug.lisp") ;;; You are using the compiler in production mode (compilation-speed = 0) ;;; Generation of runtime error checking code is disabled (safety = 0) ;;; Tail recursion elimination is enabled (speed = 3) ;;; Reading source file "/home/sanpoil0/snicoud/key-bug.lisp" ;;; Compiling (DEFCLASS A) ;;; Compiling (DEFMETHOD A-M1 (A)) >>Trap: Bus error LUCID:COMPILE-FORM: Required arg 0 (FORM): (LUCID-COMMON-LISP:DEFINE-FUNCTION (QUOTE LUCID::%TOPLEVEL-THUNK) (FUNCTION (LAMBDA NIL # NIL))) Required arg 1 (MODE): LUCID::TOPLEVEL Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) :A 0: Abort to Lisp Top Level -> :b LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> :n LUCID:COMPILE-FORM: Required arg 0 (FORM): (EVAL-WHEN (COMPILE LOAD EVAL) (PCL::LOAD-DEFMETHOD (QUOTE STANDARD-METHOD) (QUOTE A-M1) (QUOTE NIL) (LIST #) (QUOTE #) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (FUNCTION #))) Required arg 1 (MODE): LUCID::ALREADY-EVALUATED-IN-COMPILER Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) -> :n LUCID:COMPILE-FORM: Required arg 0 (FORM): (DEFMETHOD A-M1 ((SELF A) &OPTIONAL (A-OPT :JUMBO) &KEY (A-KEY :MUMBO)) (WITH-SLOTS NIL SELF (FORMAT T "~s, ~s" A-OPT A-KEY))) Required arg 1 (MODE): LUCID::TOPLEVEL Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) -> :n COMPILE-FILE: Required arg 0 (INPUT-PATHNAME): "~/key-bug.lisp" Rest arg 1 (KEYS): NIL Keyword arg 2 (OUTPUT-FILE): NIL Keyword arg 3 (TARGET): NIL Keyword arg 4 (BLOCK-COMPILE-PRESCAN): NIL Keyword arg 5 (COMPILE-BLOCK): NIL Keyword arg 6 (FASLSTATE): NIL -> :a Abort to Lisp Top Level Back to Lisp Top Level > Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26225; Wed, 2 May 90 18:59:35 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 02 MAY 90 13:43:41 PDT Return-Path: Redistributed: CommonLoops.PA Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 02 MAY 90 13:41:17 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12209; Wed, 2 May 90 13:41:48 PDT Date: Wed, 2 May 90 13:41 PDT From: Gregor J. Kiczales Subject: RE: new version of PCL To: Stephen L. Nicoud , Stanley's Tool Works , Andreas Girgensohn Cc: CommonLoops.PA@Xerox.COM Message-Id: <19900502204106.6.GREGOR@SPIFF.parc.xerox.com> There is a newer version of PCL on arisia. It is May Day PCL (REV 2). It fixes all of the following: Date: Tue, 1 May 90 20:56 PDT From: Stephen L. Nicoud In defclass.lisp of May Day PCL, system:*compiler-message-string* should be lucid::*compiler-message-string*. Date: Wed, 2 May 90 08:39:25 PDT From: Stanley's Tool Works Trying to install the final PCL in /import/pcl/may-day/. It compiled fine in Lucid (after changing system:mumble to lucid::mumble). But it loses in Franz since it's missing the files cpatch and quadlap. Date: Wed, 2 May 90 13:15:33 MDT From: Andreas Girgensohn I'm very disappointed that Mike Thome's enhancements have not been included in May Day PCL. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29706; Thu, 3 May 90 12:21:52 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 03 MAY 90 09:03:09 PDT Return-Path: Redistributed: CommonLoops.pa Received: from linus.mitre.org ([129.83.10.1]) by Xerox.COM ; 03 MAY 90 08:38:44 PDT Return-Path: Received: from pollum.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA05447; Thu, 3 May 90 10:48:26 -0400 Full-Name: John D. Burger Posted-Date: Thu, 03 May 90 10:48:12 EDT Received: by pollum.mitre.org (5.61/RCF-4C) id AA09431; Thu, 3 May 90 10:48:18 -0400 From: john@linus.mitre.org Message-Id: <9005031448.AA09431@pollum.mitre.org> To: CommonLoops.pa@Xerox.COM Reply-To: john@mitre.org Subject: EXPAND-DEFMETHOD-INTERNAL bug Date: Thu, 03 May 90 10:48:12 EDT In looking at Mike Thome's improvements on the TOP-LEVEL-FORM stuff (posted by Andreas Girgensohn), I noticed a potential bug. The bug is actually present in the original version of EXPAND-DEFMETHOD-INTERNAL in Rainy Day and May Day PCLs, as well as the modified version. EXPAND-DEFMETHOD-INTERNAL incorrectly expands method definitions of the form (DEFMETHOD BLOOP (X Y Z) (CALL-NEXT-METHOD) (CALL-NEXT-METHOD X Y Z) ) EXPAND-DEFMETHOD-INTERNAL's walker function basically takes the last call to CALL-NEXT-METHOD as the indicator for whether or not CALL-NEXT-METHOD is invoked in the no argument situation. Thus the first CALL-NEXT-METHOD in the BLOOP method breaks, because the internal function has been defined in the expansion so as to insist on arguments. The fix should be made to the function EXPAND-DEFMETHOD-INTERNAL, in BOOT.LISP. The function is 90+ lines long, so I won't reproduce it all here. Inside the FLET of WALK-FUNCTION, the form (SETQ SAVE-ORIGINAL-ARGS (NOT (CDR FORM))) should be replaced by (UNLESS (REST FORM) (SETF SAVE-ORIGINAL-ARGS T)) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09475; Thu, 3 May 90 16:30:44 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 03 MAY 90 11:31:16 PDT Return-Path: Redistributed: CommonLoops.PA Received: from jade.berkeley.edu ([128.32.136.9]) by Xerox.COM ; 03 MAY 90 10:21:59 PDT Received: from icsib1.Berkeley.EDU by jade.berkeley.edu (5.61.1/1.16.23) id AA16814; Thu, 3 May 90 10:19:07 PDT Received: by icsib1.berkeley.edu. (4.0/SMI-4.0) id AA08525; Thu, 3 May 90 10:21:23 PDT Date: Thu, 3 May 90 10:21:23 PDT From: hws%icsib1.Berkeley.EDU@jade.berkeley.edu (Heinz Schmidt) Message-Id: <9005031721.AA08525@icsib1.berkeley.edu.> To: CommonLoops.PA@Xerox.COM Subject: [gregor@parc.xerox.com: RE: new version of PCL] > There is a newer version of PCL on arisia. It is May Day PCL (REV 2). Under Coral Allegro CL 1.2.2 I changed plap.lisp: (defconstant *empty-vector* '#()) to: (defvar *empty-vector* '#()) to get it compiled. Under AKCL 1-473 on a Sun 4/110 I couldn't compile the system (neither May Day nor May Day rev 2). Compilation hangs when compile-pcl tries to load defs.o and never returns from loading. Is there anybody out there who uses pcl under akcl? -------------------------------------------------------------------------- Heinz W. Schmidt hws@icsi.berkeley.edu International Computer Science Institute, Berkeley (415) 643-9153 x175 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09512; Thu, 3 May 90 16:32:36 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 90 15:28:00 PDT Return-Path: Redistributed: CommonLoops.pa Received: from jade.berkeley.edu ([128.32.136.9]) by Xerox.COM ; 03 MAY 90 15:25:12 PDT Received: from icsib1.Berkeley.EDU by jade.berkeley.edu (5.61.1/1.16.23) id AA22260; Thu, 3 May 90 15:22:24 PDT Received: by icsib1.berkeley.edu. (4.0/SMI-4.0) id AA09706; Thu, 3 May 90 15:24:42 PDT Date: Thu, 3 May 90 15:24:42 PDT From: hws%icsib1.Berkeley.EDU@jade.berkeley.edu (Heinz Schmidt) Message-Id: <9005032224.AA09706@icsib1.berkeley.edu.> To: CommonLoops.pa@Xerox.COM Cc: hws%icsib1.Berkeley.EDU@jade.berkeley.edu Subject: akcl port In a previous email today I reported on problems with compiling May Day (Rev 2) under akcl 1-473. I've now compiled the system bypassing the defsystem facility of pcl. Just compile-load'ing each of the relevant files works fine (except for a minor change of one of the precom files that ends in a comment not followed by a carriage return; akcl comment-reader apparently doesn't look for eof's). The reason of the original problem is still unclear, though. Looking into the stack I found cyclic structures representing the system transformations and dependencies. I suspect that this is not ok and assume there is some memory management error in akcl that shows up its ugly face here. -- Heinz Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09685; Thu, 3 May 90 16:41:22 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 90 14:36:38 PDT Return-Path: Redistributed: commonloops.pa Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 03 MAY 90 14:35:00 PDT Received: by atc.boeing.com on Thu, 3 May 90 14:33:24 PDT Date: Thu, 3 May 90 14:39 PDT From: Stephen L. Nicoud Subject: Re: problem with &key args in defmethod? To: Phil Race , Stephen L. Nicoud Cc: commonloops.pa@Xerox.COM In-Reply-To: <16168.9005031248@sparc8.fs.icl.stc.co.uk> Message-Id: <19900503213943.3.SLN@SKAGIT.atc.boeing.com> [Added commonloops.pa@xerox.com] Date: Thu, 3 May 90 13:48:36 BST From: Phil Race (ICL Strategic Systems Services) I had a similar problem, not necessarily identical, also using Sun/Lucid 3.0. and Rainy Day PCL when building CLUE7.1 There was a complaint about an &allow-other-keys. I was initially looking at the wrong method until I realised this was introduced during macro- expansion of the move-focus method. If I recall this method also had a &optional. My hopefully harmless kludge was to add &rest rest-options and the the method then compiled OK. You might care to try the same kludge. I cannot make any promises since I moused your code into my PCL and it worked fine. Before: (defmethod move-focus ((composite composite) &optional (direction :next) &key start revert-to) After: (defmethod move-focus ((composite composite) &optional (direction :next) &rest rest-options &key start revert-to) I have no idea what the underlying cause is and I don't have the time at the mom ent to go looking for it. Phil Race, ICL Strategic Systems Services, Cardinal House, St Mary's Parsonage Manchester M3 2NL ENGLAND Tel: +44 61 833 9111 x2204 Email: philr@uk.co.stc.icl.fs Yes, this does seem to do the trick. Thanks, Steve -- Stephen L. Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25241; Fri, 4 May 90 05:15:55 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 04 MAY 90 05:14:43 PDT Return-Path: <@NSFnet-Relay.AC.UK,@ai.leeds.ac.uk:philr@fs.icl.stc.co.uk> Redistributed: commonloops.pa Received: from NSFnet-Relay.AC.UK ([128.86.8.6]) by Xerox.COM ; 04 MAY 90 05:13:05 PDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa12314; 4 May 90 11:53 BST Via: fs.icl.stc.co.uk (ss0.ARPA); Fri, 4 May 90 11:00:45 GMT Received: from sparc8.fs.icl.stc.co.uk by fs.icl.stc.co.uk; Fri, 4 May 90 10:59:31 BST From: Phil Race (ICL Strategic Systems Services) Date: Fri, 4 May 90 10:59:42 BST Message-Id: <18543.9005040959@sparc8.fs.icl.stc.co.uk> To: philr%fs.icl.stc.co.uk@NSFnet-Relay.AC.UK, snicoud@atc.boeing.com Subject: Re: problem with &key args in defmethod? Cc: commonloops.pa@Xerox.COM Follow up to the above: BTW I just had another break, identical to yours when compiling using the lucid3.0 production compiler. The code had up until 5 mins ago been going through the development compiler OK, so beware as this is almost bound to occur for you. Phil Race, ICL Strategic Systems Services, Cardinal House, St Mary's Parsonage Manchester M3 2NL ENGLAND Tel: +44 61 833 9111 x2204 Email: philr@uk.co.stc.icl.fs Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09755; Fri, 4 May 90 12:49:47 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 04 MAY 90 09:21:04 PDT Return-Path: Redistributed: commonloops.pa Received: from stuartcard.parc.xerox.com ([13.2.17.38]) by Xerox.COM ; 04 MAY 90 09:18:27 PDT Received: by stuartcard.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA00924; Fri, 4 May 90 09:18:31 PDT Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.stuartcard.parc.xerox.com.sun4.40 via MS.5.6.stuartcard.parc.xerox.com.sun4_40; Fri, 4 May 90 09:18:31 -0700 (PDT) Message-Id: Date: Fri, 4 May 90 09:18:31 -0700 (PDT) From: "Stuart K. Card" To: commonloops.pa@Xerox.COM Subject: Please remove me Please remove me from this DL. Thank you. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11730; Fri, 4 May 90 14:24:42 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAY 90 14:21:19 PDT Return-Path: Redistributed: commonloops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 04 MAY 90 14:20:15 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA24123; Fri, 4 May 90 17:20:02 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA28909; Fri, 4 May 90 13:50:47 PDT Received: by frisky.Franz.COM (3.2/FI-1.0) id AA22443; Fri, 4 May 90 13:50:24 PDT From: jkf@franz.com (Sean Foderaro) Message-Id: <9005042050.AA22443@frisky.Franz.COM> To: commonloops.pa@Xerox.COM Subject: defsys.lisp Date: Fri, 04 May 90 13:50:23 PDT In the latest defsys.lisp you should put #+sun4 before the line beginning (cpatch ...) and the one beginning (quadlsp ...) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01026; Mon, 7 May 90 18:38:25 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAY 90 11:41:27 PDT Return-Path: Redistributed: commonloops.pa Received: from Neon.Stanford.EDU ([36.8.0.158]) by Xerox.COM ; 07 MAY 90 11:39:16 PDT Received: by Neon.Stanford.EDU (5.61/25-eef) id AA09398; Mon, 7 May 90 11:39:17 -0700 Date: Mon, 7 May 90 11:39:16 PDT From: Leonid Frants To: commonloops.pa@Xerox.COM Subject: Please remove me from this mailing list Message-Id: ... Thank you. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01335; Mon, 7 May 90 19:51:18 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 07 MAY 90 13:43:04 PDT Return-Path: <@CUNYVM.CUNY.EDU:KUIL@HROEUR51.BITNET> Redistributed: commonloops.pa Received: from CUNYVM.CUNY.EDU ([128.228.1.2]) by Xerox.COM ; 07 MAY 90 13:42:09 PDT Received: from HROEUR51.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3517; Mon, 07 May 90 16:40:50 EDT Date: Mon, 7 May 90 12:54 N From: Subject: remove me from the mailing list. To: commonloops.pa@Xerox.COM X-Original-To: commonloops.pa@Xerox.COM, KUIL Message-Id: <900507-134304-11255@Xerox> Please remove me from the Mailing List. Thank you. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01389; Mon, 7 May 90 19:53:49 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 07 MAY 90 15:50:21 PDT Return-Path: Redistributed: commonloops.pa Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 07 MAY 90 15:49:12 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29443; Mon, 7 May 90 15:50:02 PDT Date: Mon, 7 May 90 15:49 PDT From: Gregor J. Kiczales Subject: Re: remove me from the mailing list. To: commonloops.pa@Xerox.COM In-Reply-To: <900507-134304-11255@Xerox> Message-Id: <19900507224914.7.GREGOR@SPIFF.parc.xerox.com> Date: Mon, 7 May 90 12:54 N From: Please remove me from the Mailing List. Thank you. Before we get a whole spate of these, let me remind people that the proper way to ask to be removed from the mailing list; or to have your address changed; or to ask why you are getting 372 copies of each message (the answer to this last question is always Unix); or anything else having to do with mailing list administration is to send a message to: CommonLoops-Request@Parc.Xerox.com The many hundreds of people who read this list don't all want to know that you are leaving us; changing your address; or getting too many copies of each message. Thanks Gregor Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02833; Mon, 7 May 90 21:26:55 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 7 May 90 23:25:00-CDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA11098g; Mon, 7 May 90 20:35:03 PDT Site: Received: by ptl-club id AA05154g; Mon, 7 May 90 20:34:40 PDT Date: Mon, 7 May 90 20:34:40 PDT From: Jon L White Message-Id: <9005080334.AA05154@ptl-club> To: Common-Lisp-Object-System@MCC.COM Subject: Lazy error signaling? 88-002R, page 1-30 says: "In standard method combination, if there is an applicable method bug no applicable primary method, an error is signaled." Some have interpreted that to mean that it is OK to define an :around method that doesn't call CALL-NEXT-METHOD, since the error signaling in this case should only be triggered when an attempt is made to call the non-existent primary method. Others take the stricter view that the error should be signaled at effective-method computation time, regardless of whether or not CALL-NEXT-METHOD is involved. Anyone of you out there got an opinion on this one? -- JonL -- Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11712; Tue, 8 May 90 07:33:48 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 8 May 90 09:32:05-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 791072; 8 May 90 10:31:34 EDT Date: Tue, 8 May 90 10:33 EDT From: David A. Moon Subject: Lazy error signaling? To: Jon L White Cc: Common-Lisp-Object-System@MCC.COM In-Reply-To: <9005080334.AA05154@ptl-club> Message-Id: <19900508143309.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Mon, 7 May 90 20:34:40 PDT From: Jon L White 88-002R, page 1-30 says: "In standard method combination, if there is an applicable method bug no applicable primary method, an error is signaled." Some have interpreted that to mean that it is OK to define an :around method that doesn't call CALL-NEXT-METHOD, since the error signaling in this case should only be triggered when an attempt is made to call the non-existent primary method. Others take the stricter view that the error should be signaled at effective-method computation time, regardless of whether or not CALL-NEXT-METHOD is involved. All this part of 88-002R takes no stand on exactly when these errors are signalled. The way I remember the CLOS design discussions, the intent was that the program was erroneous if there was no applicable primary method, regardless of whether the flow of control would actually try to reach that primary method or not. This is what you call the stricter view. In Genera 8.0.1, compute-effective-method signals the error. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12711; Tue, 8 May 90 08:27:43 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 08 MAY 90 07:45:38 PDT Return-Path: Redistributed: commonloops.pa Received: from scotland.bbn.com ([46.8.0.63]) by Xerox.COM ; 08 MAY 90 07:44:14 PDT Received: from ash.scotland.bbn.com by scotland.bbn.com (4.0/SMI-DDN) id AA10702; Tue, 8 May 90 10:30:09 BST Received: by ash.scotland.bbn.com (4.0/SMI-3.2) id AA00871; Tue, 8 May 90 10:29:59 BST Date: Tue, 8 May 90 10:29:59 BST From: sjr@scotland.bbn.com Message-Id: <9005080929.AA00871@ash.scotland.bbn.com> To: commonloops.pa@Xerox.COM Subject: Please remove my name Cc: sjr@scotland.bbn.com I am not sure how I got added to the commonloops mail list (I suspect that someone in BBN Cambridge could answer this) but please remove my name. Thank you, Simon Redford Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13004; Tue, 8 May 90 08:39:01 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Tue 8 May 90 10:36:18-CDT Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA14752g; Tue, 8 May 90 08:35:39 PDT Received: by challenger id AA03599g; Tue, 8 May 90 08:34:51 PDT Date: Tue, 8 May 90 08:34:51 PDT From: Patrick Dussud Message-Id: <9005081534.AA03599@challenger> To: jonl@lucid.com Cc: Common-Lisp-Object-System@MCC.COM In-Reply-To: Jon L White's message of Mon, 7 May 90 20:34:40 PDT <9005080334.AA05154@ptl-club> Subject: Lazy error signaling? Site: Date: Mon, 7 May 90 20:34:40 PDT From: Jon L White 88-002R, page 1-30 says: "In standard method combination, if there is an applicable method bug no applicable primary method, an error is signaled." Some have interpreted that to mean that it is OK to define an :around method that doesn't call CALL-NEXT-METHOD, since the error signaling in this case should only be triggered when an attempt is made to call the non-existent primary method. Others take the stricter view that the error should be signaled at effective-method computation time, regardless of whether or not CALL-NEXT-METHOD is involved. Anyone of you out there got an opinion on this one? -- JonL -- TICLOS takes the stricter view, it signal an error at compute-effective-method time. This tends to get supported by the sample code of the standard method combination in 88-002R page 2-35. The code clearly states that at least one primary is required, regardless of the flow of control in the :around method. Patrick. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10271; Wed, 9 May 90 05:13:45 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 09 MAY 90 05:12:15 PDT Return-Path: <@MCC.COM:loeffler@mcc.com> Redistributed: CommonLoops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 09 MAY 90 05:11:04 PDT Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Wed 9 May 90 07:11:02-CDT Date: Wed, 9 May 90 07:10:54 CDT From: loeffler@mcc.com (David D. Loeffler) Posted-Date: Wed, 9 May 90 07:10:54 CDT Message-Id: <9005091210.AA07802@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (4.0/ACAv4.1i) id AA07802; Wed, 9 May 90 07:10:54 CDT To: nie@cs.albany.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: nie@cs.albany.edu's message of Mon, 12 Feb 90 16:04:09 -0500 <9002122104.AA13073@berry.albany.edu> Subject: PCL Reply-To: David D. Loeffler You have been added. Sorry for the delay but requests for additions/deletions to mailing lists should normally go to the "-request" list. In this case: common-lisp-object-system-request@mcc.com Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA10519; Wed, 9 May 90 05:22:36 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 09 MAY 90 05:20:30 PDT Return-Path: <@MCC.COM:loeffler@mcc.com> Redistributed: CommonLoops.pa Received: from MCC.COM ([128.62.11.10]) by Xerox.COM ; 09 MAY 90 05:17:10 PDT Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Wed 9 May 90 07:17:16-CDT Date: Wed, 9 May 90 07:17:13 CDT From: loeffler@mcc.com (David D. Loeffler) Posted-Date: Wed, 9 May 90 07:17:13 CDT Message-Id: <9005091217.AA07805@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (4.0/ACAv4.1i) id AA07805; Wed, 9 May 90 07:17:13 CDT To: burdick@carame.ecn.purdue.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: William R Burdick's message of Mon, 5 Mar 90 00:51:15 -0500 (EST) Subject: mailing list Reply-To: David D. Loeffler Redistributed: CommonLoops.pa Date: Mon, 5 Mar 90 00:51:15 -0500 (EST) From: William R Burdick Please remove me from this mailing list. -- Bill Burdick burdick@cello.ecn.purdue.edu Sorry, but I can not find your name on the list. Maybe you are getting the mail from some remote redistribution mailing list. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27243; Thu, 10 May 90 02:13:42 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAY 90 01:25:25 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 ; 10 MAY 90 01:23:49 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 447524; 10 May 90 04:22:34 EDT Date: Thu, 10 May 90 00:24 PDT From: Richard Lamson Subject: Can't abbreviate built-in classes; can't write methods for PATHNAME To: CommonLoops.pa@Xerox.COM Supersedes: <19900506203128.0.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Comments: Retransmission of failed mail. Message-Id: <19900510072457.3.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY") (2 0 (NIL 0) (NIL :BOLD NIL) "CPTFONTCB") (3 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI") (4 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB") (5 0 (NIL 0) (:FIX :ITALIC :NORMAL) "CPTFONTI") Fonts: CPTFONT, TINY, CPTFONTCB, CPTFONTI, CPTFONTCB, CPTFONTI Line-Fold: No 1In Symbolics 3620 in Genera 7.2, System 376.166, Experimental Logical Pathnames Translation Files NEWEST, Utilities 27.31, Server Utilities 28.5, Hardcopy 118.17, Zmail 165.23, LMFS 102.8, Tape 82.19, Nsage 27.246, Extended Help 18.4, Documentation Database 62.1, Mailer 17.1, Print Spooler 16.1, Domain Name Server 17.1, Experimental ILA-SF-Site-System 1.23, Experimental ILA-SF-Site-Server-System 3.25, microcode 3620-FPA-MIC 420, FEP 208, fep0:>g208-lisp.flod(4), fep0:>g208-loaders.flod(4), fep0:>g208-debug.flod(2), fep0:>g208-info.flod(4), Machine serial number 20194 on Symbolics 3620 #20194 (Max Fleischer): 0Is there a genuine Bug-PCL mailing list? Here is exactly what I did: (in-package 'test-package :use '(PCL lisp)) (shadow "INTEGER" 'test-package) (deftype integer () 'lisp:integer) (defmethod foo ((foo integer)) foo) I originally wanted to be doing this: (in-package 'clim-lisp) (shadow 'pathname) (deftype pathname () 'lisp:pathname) (defmethod pathname ((string string)) (parse-namestring string)) (defmethod pathname ((pathname pathname)) pathname) (defmethod pathname ((stream stream)) (stream-pathname stream)) but PATHNAME is not a PCL built-in class, so I decided to try this with INTEGER. 1. What is the right way to do what I want? Just saying (defclass integer (lisp:integer) ()) doesn't work: it creates a standard class. If you then define a method on this new class, it can't be invoked (see second backtrace below). You can't create a built-in class by specifying (defclass integer (lisp:integer) () (:metaclass pcl:built-in-class)) because this is prohibited by PCL. 2. Why isn't PATHNAME a built-in class? 2Error: TEST-PACKAGE::INTEGER used as a specializer, but is not the name of a class. 0While in the function (:INTERNAL PCL:PARSE-SPECIALIZERS 0 PCL:PARSE)  PCL:PARSE-SPECIALIZERS  PCL:REAL-ADD-NAMED-METHOD The condition signalled was SYS:FATAL-ERROR 2(:INTERNAL PCL:PARSE-SPECIALIZERS 0 PCL:PARSE)0 (P.C. = 13) 3(from MAX:>pcl>pcl-for-the-nineties>boot) 2PCL:PARSE-SPECIALIZERS0 (P.C. = 15) 3(from MAX:>pcl>pcl-for-the-nineties>boot) 2PCL:REAL-ADD-NAMED-METHOD0 (P.C. = 11) 3(from MAX:>pcl>pcl-for-the-nineties>methods) 2PCL:LOAD-DEFMETHOD-INTERNAL0 (P.C. = 73) 3(from MAX:>pcl>pcl-for-the-nineties>boot) 2PCL:LOAD-DEFMETHOD0 (P.C. = 36) 3(from MAX:>pcl>pcl-for-the-nineties>boot) 0================================================================= Second backtrace: I typed (defclass integer (lisp:integer) ()) (defmethod foo ((foo integer)) foo) (foo 4) and the following occurred: 4Error: The symbol NIL has an invalid function definition NIL 0 5Rest Arg: 0(4) 4PCL:INITIAL-DFUN0 5(from MAX:>pcl>pcl-for-the-nineties>dfun) 0 Arg 0 (PCL:ARGS): (4) Arg 1 (PCL:GENERIC-FUNCTION): # # is an instance of class #: The following slots have :INSTANCE allocation: SOURCE NIL PLIST NIL PRETTY-ARGLIST NIL VALID-P NIL EFFECTIVE-METHOD-FUNCTIONS NIL DFUN-STATE NIL ARG-INFO # METHOD-COMBINATION # METHOD-CLASS # METHODS (#) NAME TEST-PACKAGE::FOO # is an instance of class #: The following slots have :INSTANCE allocation: PLIST NIL SOURCE ((PCL:DEFMETHOD TEST-PACKAGE::FOO (TEST-PACKAGE::INTEGER)) NIL) FUNCTION # LAMBDA-LIST (TEST-PACKAGE::FOO) SPECIALIZERS (#) GENERIC-FUNCTION # # is a class, it is an instance of PCL:STANDARD-CLASS. Its proper name is TEST-PACKAGE::INTEGER. The direct superclasses are: (INTEGER), and the direct subclasses are: (). The class precedence list is: (TEST-PACKAGE::INTEGER INTEGER RATIONAL NUMBER T) There are 1 methods specialized for this class. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16756; Sat, 12 May 90 08:33:28 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Sat 12 May 90 10:29:50-CDT Received: by charon.MIT.EDU id AA23029; Sat, 12 May 90 11:29:20 EDT Date: Sat, 12 May 90 11:29:20 EDT From: kab@CHARON.MIT.EDU (Kim A. Barrett) Message-Id: <9005121529.AA23029@charon.MIT.EDU> To: dussud@lucid.com Cc: jonl@lucid.com, Common-Lisp-Object-System@MCC.COM In-Reply-To: Patrick Dussud's message of Tue, 8 May 90 08:34:51 PDT <9005081534.AA03599@challenger> Subject: Lazy error signaling? >> Date: Mon, 7 May 90 20:34:40 PDT >> From: Jon L White >> >> 88-002R, page 1-30 says: >> >> "In standard method combination, if there is an applicable method >> bug no applicable primary method, an error is signaled." >> >> Some have interpreted that to mean that it is OK to define an :around >> method that doesn't call CALL-NEXT-METHOD, since the error signaling >> in this case should only be triggered when an attempt is made to call >> the non-existent primary method. Others take the stricter view that >> the error should be signaled at effective-method computation time, >> regardless of whether or not CALL-NEXT-METHOD is involved. >> >> Anyone of you out there got an opinion on this one? >> >> -- JonL -- > TICLOS takes the stricter view, it signal an error at > compute-effective-method time. This tends to get supported by the sample code > of the standard method combination in 88-002R page 2-35. The code clearly > states that at least one primary is required, regardless of the flow of > control in the :around method. > > Patrick. But the implementation of (... :required t) could be done via binding the method list to a list of one method which will do the error signaling when called. I don't think the sample code is really that strong an argument for early error signaling here. One problem with signaling the error at compute-effective-method time is that it prevents precomputing of combined methods. I know PCL used to precompute combined methods and put them into a sort of discrimination network. For some of the nodes in the network, it might not be valid to call the function because no primary method is present. One way this can come about is when loading a file which adds methods to a generic function, and there are calls to the generic function which occur during the load. I noticed this ambiguity a long time ago, including it in one of my reviews of the standard (or maybe just of 88-002R), and never heard anything more about it (like most of my review comments). For current practice, IIM-CLOS does lazy signaling via a call to a generic function called NO-PRIMARY-METHOD (which is analogous to NO-APPLICABLE-METHOD), allowing specialization of its behavior. An effect similar to specialization of NO-PRIMARY-METHOD can be achieved by defining specialized method-combination types, but this can lead to a massive proliforation of method-combination types and generally seemed to us to be the wrong way to go. kab Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12430; Mon, 14 May 90 08:27:49 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 14 May 90 10:23:28-CDT Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA00631g; Mon, 14 May 90 08:22:29 PDT Received: by challenger id AA04941g; Mon, 14 May 90 08:21:52 PDT Date: Mon, 14 May 90 08:21:52 PDT From: Patrick Dussud Message-Id: <9005141521.AA04941@challenger> To: kab@CHARON.MIT.EDU Cc: jonl@lucid.com, Common-Lisp-Object-System@MCC.COM In-Reply-To: Kim A. Barrett's message of Sat, 12 May 90 11:29:20 EDT <9005121529.AA23029@charon.MIT.EDU> Subject: Lazy error signaling? Date: Sat, 12 May 90 11:29:20 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) >> Date: Mon, 7 May 90 20:34:40 PDT >> From: Jon L White >> >> 88-002R, page 1-30 says: >> >> "In standard method combination, if there is an applicable method >> bug no applicable primary method, an error is signaled." >> >> Some have interpreted that to mean that it is OK to define an :around >> method that doesn't call CALL-NEXT-METHOD, since the error signaling >> in this case should only be triggered when an attempt is made to call >> the non-existent primary method. Others take the stricter view that >> the error should be signaled at effective-method computation time, >> regardless of whether or not CALL-NEXT-METHOD is involved. >> >> Anyone of you out there got an opinion on this one? >> >> -- JonL -- > TICLOS takes the stricter view, it signal an error at > compute-effective-method time. This tends to get supported by the sample code > of the standard method combination in 88-002R page 2-35. The code clearly > states that at least one primary is required, regardless of the flow of > control in the :around method. > > Patrick. But the implementation of (... :required t) could be done via binding the method list to a list of one method which will do the error signaling when called. I don't think the sample code is really that strong an argument for early error signaling here. This is not what the description of define-method-combination says. Since method combination composition is accessible to the programmer with DEFINE-METHOD-COMBINATION, it is bacd practice for the implementation to add obscure system defined methods in places that are visible by the programmer. The list of primary methods inside of a define-method-combination should be bound to a list of method either defined by user-code, or supplied by the implementation when documented as such. One problem with signaling the error at compute-effective-method time is that it prevents precomputing of combined methods. I know PCL used to precompute combined methods and put them into a sort of discrimination network. For some of the nodes in the network, it might not be valid to call the function because no primary method is present. One way this can come about is when loading a file which adds methods to a generic function, and there are calls to the generic function which occur during the load. I don't think it prevents precomputing of combined methods. Methods can be computed at any stage such as compile-file time or while figuring out effective methods for other argument classes, but could be forgotten at that time if METHOD-COMBINATION-ERROR is called. This is what TI-CLOS does in some cases. Patrick. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07302; Mon, 14 May 90 15:43:26 -0700 Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Mon 14 May 90 17:39:50-CDT Received: by charon.MIT.EDU id AA04651; Mon, 14 May 90 17:59:36 EDT Date: Mon, 14 May 90 17:59:36 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9005142159.AA04651@charon.MIT.EDU> To: dussud@lucid.com Cc: jonl@lucid.com, Common-Lisp-Object-System@MCC.COM In-Reply-To: Patrick Dussud's message of Mon, 14 May 90 08:21:52 PDT <9005141521.AA04941@challenger> Subject: Lazy error signaling? > ... bad practice for the implementation to add obscure system defined methods > in places that are visible by the programmer. ... Right. My suggested possible implementation of (... :required t) is completely bogus. I was confused about how our implementation of STANDARD method combination works (it doesn't use (primary () :required t) at all). Regarding precomputing of combined methods and METHOD-COMBINATION-ERROR, this only works if the place doing the precomputing knows how to detect and gracefully handle a corresponding call to METHOD-COMBINATION-ERROR. Since we didn't specify much about the behavior of METHOD-COMBINATION-ERROR, this is currently impossible in portable code. Of course, it's not clear that precomputing methods can be done for any useful purpose without a metaobject proposal anyway. kab Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07925; Mon, 14 May 90 15:57:54 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Mon 14 May 90 17:46:38-CDT Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA04067g; Mon, 14 May 90 15:45:44 PDT Received: by challenger id AA05999g; Mon, 14 May 90 15:45:06 PDT Date: Mon, 14 May 90 15:45:06 PDT From: Patrick Dussud Message-Id: <9005142245.AA05999@challenger> To: kab@charon.MIT.EDU Cc: jonl@lucid.com, Common-Lisp-Object-System@MCC.COM In-Reply-To: Kim A. Barrett's message of Mon, 14 May 90 17:59:36 EDT <9005142159.AA04651@charon.MIT.EDU> Subject: Lazy error signaling? Date: Mon, 14 May 90 17:59:36 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Regarding precomputing of combined methods and METHOD-COMBINATION-ERROR, this only works if the place doing the precomputing knows how to detect and gracefully handle a corresponding call to METHOD-COMBINATION-ERROR. Since we didn't specify much about the behavior of METHOD-COMBINATION-ERROR, this is currently impossible in portable code. Of course, it's not clear that precomputing methods can be done for any useful purpose without a metaobject proposal anyway. kab I was thinking of the cases where the implementation does effective method precomputing. For these cases the code does not have to be portable. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09061; Mon, 14 May 90 23:57:09 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 01:53:28-CDT Received: from media-lab (media-lab.media.mit.edu) by SAIL.Stanford.EDU with TCP; 14 May 90 23:52:10 PDT Received: by media-lab (5.57/4.8) id AA27966; Tue, 15 May 90 02:54:23 EDT Date: Tue, 15 May 90 02:54:23 EDT From: Steve Strassmann Message-Id: <9005150654.AA27966@media-lab> To: commonloops-request@arisia.Xerox.COM Cc: hp-support@lucid.com, Common-Lisp-Object-System@sail.stanford.edu Subject: May Day PCL won't compile in HP Lucid 3.0 What is the correct address for PCL bug reports like this one? I hesitate to mail it to CommonLoops@Xerox.com, for fear that will go to too broad an audience, but there doesn't seem to be anything else advertised in the get-pcl.text file that comes with PCL. And bug-CommonLoops@Xerox.com doesn't exist. Anyway, on with the bug report: This error occurs on an HP 835, HP-UX 7.0, Lucid 3.0, base-lisp, with no lisp-init file loaded. I cannot compile the "5/1/90 May Day PCL (REV 2)" release of PCL, using either Lucid's production or development compiler. Below are two transcripts, from a compile-pcl session with each, because they stop in different places. I deleted pcl/*.hbin before doing each of these sessions. Also, there's a bunch of package export warnings from lucid-low that could be cleaned up. ------------------------------------------------------------------------------ ;;; HP Common Lisp, Development Environment, 29 January 1990. ;;; HP-9000, Series 800, Product no. HP92640, Rev. X.00.01 ;;; ;;; Copyright (c) 1988, 1989 by Hewlett-Packard, Co., All Rights Reserved. ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989 by Lucid, Inc., All Rights Reserved. ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Hewlett-Packard. It may not be copied ;;; for any reason other than for archival and backup purposes. > (proclaim '(optimize (safety 1) (speed 3) (compilation-speed 0))) T > (report-compiler-options) ;;; Compiler options are: ;;; TARGET....................PA ;;; EGC........................T ;;; SHOW-OPTIMIZATIONS.......NIL ;;; UNDEF-WARNINGS.............T ;;; WARNINGS...................T ;;; DOCUMENTATION..............T ;;; READ-SAFETY..............NIL ;;; WRITE-SAFETY.............NIL ;;; BOUNDS-CHECK.............NIL ;;; FILE-MESSAGES..............T ;;; MESSAGES.................NIL ;;; FAST-ENTRY...............NIL ;;; TAIL-MERGE.................T ;;; NOTINLINE................NIL ;;; Compiler optimizations are: ;;; SPEED......................3 ;;; SAFETY.....................1 ;;; SPACE......................0 ;;; COMPILATION-SPEED..........0 > (load "/lisp/pcl/defsys.lisp") ;;; Loading source file "defsys.lisp" #P"/lisp/pcl/defsys.lisp" > (pcl::compile-pcl) Compiling PKG... ;;; 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 "pkg.lisp" ;;; Writing binary file "pkg.hbin" Loading binary of PKG... Compiling WALK... ;;; Reading source file "walk.lisp" ;;; Writing binary file "walk.hbin" Loading binary of WALK... Compiling ITERATE... ;;; Reading source file "iterate.lisp" ;;; Writing binary file "iterate.hbin" Loading binary of ITERATE... Compiling MACROS... ;;; Reading source file "macros.lisp" ;;; Writing binary file "macros.hbin" Loading binary of MACROS... Compiling LOW... ;;; Reading source file "low.lisp" ;;; Writing binary file "low.hbin" Loading binary of LOW... Compiling LUCID-LOW... ;;; Reading source file "lucid-low.lisp" ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Writing binary file "lucid-low.hbin" Loading binary of LUCID-LOW... ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. Compiling FIN... ;;; Reading source file "fin.lisp" ;;; Writing binary file "fin.hbin" Loading binary of FIN... Compiling DEFCLASS... ;;; Reading source file "defclass.lisp" ;;; While compiling EXPAND-DEFCLASS ;;; Warning: Free variable *DEFCLASS-TIMES* assumed to be special ;;; Writing binary file "defclass.hbin" Loading binary of DEFCLASS... Compiling DEFS... ;;; Reading source file "defs.lisp" ;;; Writing binary file "defs.hbin" Loading binary of DEFS... Compiling FNGEN... ;;; Reading source file "fngen.lisp" ;;; Writing binary file "fngen.hbin" Loading binary of FNGEN... Compiling LAP... ;;; Reading source file "lap.lisp" ;;; Writing binary file "lap.hbin" Loading binary of LAP... Compiling PLAP... ;;; Reading source file "plap.lisp" >>Error: LUCID::T0 should be a LIST LUCID:COMPILE-FORM: Required arg 0 (FORM): (LUCID-COMMON-LISP:DEFINE-FUNCTION (QUOTE LAP-OPCODE) (FUNCTION (LAMBDA # #))) Required arg 1 (MODE): LUCID::TOPLEVEL Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) :C 0: Use a new value :A 1: Abort to Lisp Top Level -> :b LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- COMPILE-MODULE <- OPERATE-ON-SYSTEM <- COMPILE-PCL <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> ------------------------------------------------------------------------------ ;;; HP Common Lisp, Development Environment, 29 January 1990. ;;; HP-9000, Series 800, Product no. HP92640, Rev. X.00.01 ;;; ;;; Copyright (c) 1988, 1989 by Hewlett-Packard, Co., All Rights Reserved. ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989 by Lucid, Inc., All Rights Reserved. ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Hewlett-Packard. It may not be copied ;;; for any reason other than for archival and backup purposes. > (proclaim '(optimize (safety 3) (speed 1) (compilation-speed 3))) T > (report-compiler-options) ;;; Compiler options are: ;;; TARGET....................PA ;;; EGC........................T ;;; SHOW-OPTIMIZATIONS.......NIL ;;; UNDEF-WARNINGS.............T ;;; WARNINGS...................T ;;; DOCUMENTATION..............T ;;; READ-SAFETY................T ;;; WRITE-SAFETY...............T ;;; BOUNDS-CHECK...............T ;;; FILE-MESSAGES..............T ;;; MESSAGES.................NIL ;;; FAST-ENTRY...............NIL ;;; TAIL-MERGE...............NIL ;;; NOTINLINE................NIL ;;; Compiler optimizations are: ;;; SPEED......................1 ;;; SAFETY.....................3 ;;; SPACE......................0 ;;; COMPILATION-SPEED..........3 > (load "/lisp/pcl/defsys.lisp") ;;; Loading source file "defsys.lisp" #P"/lisp/pcl/defsys.lisp" > (pcl::compile-pcl) Compiling PKG... ;;; You are using the compiler in development mode (compilation-speed = 3) ;;; Generation of full safety checking code is enabled (safety = 3) ;;; Elimination of unnecessary variables is disabled (speed = 1) ;;; Reading source file "pkg.lisp" ;;; Writing binary file "pkg.hbin" Loading binary of PKG... Compiling WALK... ;;; Reading source file "walk.lisp" ;;; Writing binary file "walk.hbin" Loading binary of WALK... Compiling ITERATE... ;;; Reading source file "iterate.lisp" ;;; Writing binary file "iterate.hbin" Loading binary of ITERATE... Compiling MACROS... ;;; Reading source file "macros.lisp" ;;; Writing binary file "macros.hbin" Loading binary of MACROS... Compiling LOW... ;;; Reading source file "low.lisp" ;;; Writing binary file "low.hbin" Loading binary of LOW... Compiling LUCID-LOW... ;;; Reading source file "lucid-low.lisp" ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Writing binary file "lucid-low.hbin" Loading binary of LUCID-LOW... ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. Compiling FIN... ;;; Reading source file "fin.lisp" ;;; Writing binary file "fin.hbin" Loading binary of FIN... Compiling DEFCLASS... ;;; Reading source file "defclass.lisp" ;;; While compiling EXPAND-DEFCLASS ;;; Warning: Free variable *DEFCLASS-TIMES* assumed to be special ;;; Writing binary file "defclass.hbin" Loading binary of DEFCLASS... Compiling DEFS... ;;; Reading source file "defs.lisp" ;;; Writing binary file "defs.hbin" Loading binary of DEFS... Compiling FNGEN... ;;; Reading source file "fngen.lisp" ;;; Writing binary file "fngen.hbin" Loading binary of FNGEN... Compiling LAP... ;;; Reading source file "lap.lisp" ;;; Writing binary file "lap.hbin" Loading binary of LAP... Compiling PLAP... ;;; Reading source file "plap.lisp" ;;; Writing binary file "plap.hbin" Loading binary of PLAP... Compiling CACHE... ;;; Reading source file "cache.lisp" ;;; While compiling EXPAND-CACHE ;;; Warning: Variable IGNORE is bound but not referenced ;;; Writing binary file "cache.hbin" Loading binary of CACHE... Compiling DLAP... ;;; Reading source file "dlap.lisp" ;;; Writing binary file "dlap.hbin" Loading binary of DLAP... Compiling BOOT... ;;; Reading source file "boot.lisp" ;;; Writing binary file "boot.hbin" Loading binary of BOOT... Compiling VECTOR... ;;; Reading source file "vector.lisp" ;;; Writing binary file "vector.hbin" Loading binary of VECTOR... Compiling SLOTS... ;;; Reading source file "slots.lisp" ;;; Writing binary file "slots.hbin" Loading binary of SLOTS... Compiling INIT... ;;; Reading source file "init.lisp" ;;; Writing binary file "init.hbin" Loading binary of INIT... Compiling STD-CLASS... ;;; Reading source file "std-class.lisp" ;;; While compiling ENSURE-CLASS-VALUES ;;; Warning: Variable PROTO is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (STD-CLASS T)) ;;; Warning: Variable DIRECT-SUPERCLASSES is bound but not referenced ;;; While compiling (DEFMETHOD REINITIALIZE-INSTANCE :BEFORE (STD-CLASS)) ;;; Warning: Variable DIRECT-SLOTS is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (BUILT-IN-CLASS T)) ;;; Warning: Variable INITARGS is bound but not referenced ;;; Writing binary file "std-class.hbin" Loading binary of STD-CLASS... ;;; Expanding Reserved Memory ;;; GC: 217926 words [871704 bytes] of dynamic storage in use. ;;; 240824 words [963296 bytes] of free storage available before a GC. ;;; 699574 words [2798296 bytes] of free storage available if GC is disabled. Compiling CPL... ;;; Reading source file "cpl.lisp" ;;; Writing binary file "cpl.hbin" Loading binary of CPL... Compiling BRAID... ;;; Reading source file "braid.lisp" ;;; Writing binary file "braid.hbin" Loading binary of BRAID... Compiling FSC... ;;; Reading source file "fsc.lisp" ;;; Writing binary file "fsc.hbin" Loading binary of FSC... Compiling METHODS... ;;; Reading source file "methods.lisp" ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :AFTER (STANDARD-METHOD T)) ;;; Warning: Variable SLOT-NAMES is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (STANDARD-GENERIC-FUNCTION T)) ;;; Warning: Variable DOCUMENTATION is bound but not referenced ;;; While compiling COMPUTE-PRECEDENCE ;;; Warning: Variable NREQ is bound but not referenced ;;; While compiling REAL-ADD-METHOD ;;; Warning: Variable LAMBDA-LIST is bound but not referenced ;;; Writing binary file "methods.hbin" Loading binary of METHODS... Compiling COMBIN... ;;; Reading source file "combin.lisp" ;;; Writing binary file "combin.hbin" Loading binary of COMBIN... Compiling DFUN... ;;; Reading source file "dfun.lisp" ;;; Writing binary file "dfun.hbin" Loading binary of DFUN... Compiling FIXUP... ;;; Reading source file "fixup.lisp" >>Error: The value of X, :METHOD-COMBINATION, should be a LIST CAR: Required arg 0 (X): :METHOD-COMBINATION :C 0: Use a new value :A 1: Abort to Lisp Top Level -> :b CAR <- |(METHOD COMPUTE-DEFAULT-INITARGS (STD-CLASS T T))| <- UPDATE-CLASS <- |(METHOD FINALIZE-INHERITANCE (STD-CLASS))| <- |(METHOD ALLOCATE-INSTANCE (FUNCALLABLE-STANDARD-CLASS))| <- (:INTERNAL EARLY-DFUN DO-MAIN-COMBINED-METHOD) <- EARLY-DFUN <- (:INTERNAL EARLY-UPDATE-DISCRIMINATOR-CODE 1) <- FIX-EARLY-GENERIC-FUNCTIONS <- EVAL <- LUCID:COMPILE-FORM <- COMPILE-FILE <- COMPILE-MODULE <- OPERATE-ON-SYSTEM <- COMPILE-PCL <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09170; Tue, 15 May 90 00:01:02 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 MAY 90 14:55:02 PDT Return-Path: Redistributed: CommonLoops.pa Received: from p.lanl.gov ([128.165.4.4]) by Xerox.COM ; 14 MAY 90 14:53:23 PDT Received: from zaphod.lanl.gov by p.lanl.gov (5.61/1.14) id AA10072; Mon, 14 May 90 15:53:21 -0600 Received: by zaphod.lanl.gov.lanl.gov (4.1/SMI-4.1) id AA21118; Mon, 14 May 90 15:53:35 MDT Date: Mon, 14 May 90 15:53:35 MDT From: egdorf%zaphod@LANL.GOV (Skip Egdorf) Message-Id: <9005142153.AA21118@zaphod.lanl.gov.lanl.gov> To: CommonLoops.pa@Xerox.COM Subject: Once again - A browser? This has been discussed before, but I cannot find the references... What class browsers have been written and/or are available for PCL? I know that each vendor will be including something with their version of CLOS, but I would like something a bit portable. Thanks. Skip Egdorf hwe@lanl.gov Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA24502; Tue, 15 May 90 14:02:17 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 15 MAY 90 13:45:14 PDT Return-Path: Redistributed: CommonLoops.PA Received: from media-lab ([18.85.0.2]) by Xerox.COM ; 15 MAY 90 13:38:41 PDT Received: by media-lab (5.57/4.8) id AA08196; Tue, 15 May 90 16:39:55 EDT Date: Tue, 15 May 90 16:39:55 EDT From: Steve Strassmann Message-Id: <9005152039.AA08196@media-lab> To: CommonLoops.PA@Xerox.COM In-Reply-To: Stephen L. Nicoud's message of Tue, 15 May 90 08:22 PDT <19900515152200.4.SLN@SKAGIT.atc.boeing.com> Subject: May Day PCL won't compile in HP Lucid 3.0 This error occurs on an HP 835, HP-UX 7.0, Lucid 3.0, base-lisp, with no lisp-init file loaded. I cannot compile the "5/1/90 May Day PCL (REV 2)" release of PCL, using either Lucid's production or development compiler. Below are transcripts from a compile-pcl session with each, since it stops in different places for different compilers. I deleted pcl/*.hbin before doing each of these sessions. ------------------------------------------------------------------------------ ;;; HP Common Lisp, Development Environment, 29 January 1990. ;;; HP-9000, Series 800, Product no. HP92640, Rev. X.00.01 ;;; ;;; Copyright (c) 1988, 1989 by Hewlett-Packard, Co., All Rights Reserved. ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989 by Lucid, Inc., All Rights Reserved. ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Hewlett-Packard. It may not be copied ;;; for any reason other than for archival and backup purposes. > (proclaim '(optimize (safety 1) (speed 3) (compilation-speed 0))) T > (report-compiler-options) ;;; Compiler options are: ;;; TARGET....................PA ;;; EGC........................T ;;; SHOW-OPTIMIZATIONS.......NIL ;;; UNDEF-WARNINGS.............T ;;; WARNINGS...................T ;;; DOCUMENTATION..............T ;;; READ-SAFETY..............NIL ;;; WRITE-SAFETY.............NIL ;;; BOUNDS-CHECK.............NIL ;;; FILE-MESSAGES..............T ;;; MESSAGES.................NIL ;;; FAST-ENTRY...............NIL ;;; TAIL-MERGE.................T ;;; NOTINLINE................NIL ;;; Compiler optimizations are: ;;; SPEED......................3 ;;; SAFETY.....................1 ;;; SPACE......................0 ;;; COMPILATION-SPEED..........0 > (load "/lisp/pcl/defsys.lisp") ;;; Loading source file "defsys.lisp" #P"/lisp/pcl/defsys.lisp" > (pcl::compile-pcl) Compiling PKG... ;;; 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 "pkg.lisp" ;;; Writing binary file "pkg.hbin" Loading binary of PKG... Compiling WALK... ;;; Reading source file "walk.lisp" ;;; Writing binary file "walk.hbin" Loading binary of WALK... Compiling ITERATE... ;;; Reading source file "iterate.lisp" ;;; Writing binary file "iterate.hbin" Loading binary of ITERATE... Compiling MACROS... ;;; Reading source file "macros.lisp" ;;; Writing binary file "macros.hbin" Loading binary of MACROS... Compiling LOW... ;;; Reading source file "low.lisp" ;;; Writing binary file "low.hbin" Loading binary of LOW... Compiling LUCID-LOW... ;;; Reading source file "lucid-low.lisp" ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Writing binary file "lucid-low.hbin" Loading binary of LUCID-LOW... ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. Compiling FIN... ;;; Reading source file "fin.lisp" ;;; Writing binary file "fin.hbin" Loading binary of FIN... Compiling DEFCLASS... ;;; Reading source file "defclass.lisp" ;;; While compiling EXPAND-DEFCLASS ;;; Warning: Free variable *DEFCLASS-TIMES* assumed to be special ;;; Writing binary file "defclass.hbin" Loading binary of DEFCLASS... Compiling DEFS... ;;; Reading source file "defs.lisp" ;;; Writing binary file "defs.hbin" Loading binary of DEFS... Compiling FNGEN... ;;; Reading source file "fngen.lisp" ;;; Writing binary file "fngen.hbin" Loading binary of FNGEN... Compiling LAP... ;;; Reading source file "lap.lisp" ;;; Writing binary file "lap.hbin" Loading binary of LAP... Compiling PLAP... ;;; Reading source file "plap.lisp" >>Error: LUCID::T0 should be a LIST LUCID:COMPILE-FORM: Required arg 0 (FORM): (LUCID-COMMON-LISP:DEFINE-FUNCTION (QUOTE LAP-OPCODE) (FUNCTION (LAMBDA # #))) Required arg 1 (MODE): LUCID::TOPLEVEL Required arg 2 (OUTPUT): # Rest arg 3 (OUTARGS): (# # #) :C 0: Use a new value :A 1: Abort to Lisp Top Level -> :b LUCID:COMPILE-FORM <- LUCID:COMPILE-FORM <- COMPILE-FILE <- COMPILE-MODULE <- OPERATE-ON-SYSTEM <- COMPILE-PCL <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> ------------------------------------------------------------------------------ ;;; HP Common Lisp, Development Environment, 29 January 1990. ;;; HP-9000, Series 800, Product no. HP92640, Rev. X.00.01 ;;; ;;; Copyright (c) 1988, 1989 by Hewlett-Packard, Co., All Rights Reserved. ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989 by Lucid, Inc., All Rights Reserved. ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Hewlett-Packard. It may not be copied ;;; for any reason other than for archival and backup purposes. > (proclaim '(optimize (safety 3) (speed 1) (compilation-speed 3))) T > (report-compiler-options) ;;; Compiler options are: ;;; TARGET....................PA ;;; EGC........................T ;;; SHOW-OPTIMIZATIONS.......NIL ;;; UNDEF-WARNINGS.............T ;;; WARNINGS...................T ;;; DOCUMENTATION..............T ;;; READ-SAFETY................T ;;; WRITE-SAFETY...............T ;;; BOUNDS-CHECK...............T ;;; FILE-MESSAGES..............T ;;; MESSAGES.................NIL ;;; FAST-ENTRY...............NIL ;;; TAIL-MERGE...............NIL ;;; NOTINLINE................NIL ;;; Compiler optimizations are: ;;; SPEED......................1 ;;; SAFETY.....................3 ;;; SPACE......................0 ;;; COMPILATION-SPEED..........3 > (load "/lisp/pcl/defsys.lisp") ;;; Loading source file "defsys.lisp" #P"/lisp/pcl/defsys.lisp" > (pcl::compile-pcl) Compiling PKG... ;;; You are using the compiler in development mode (compilation-speed = 3) ;;; Generation of full safety checking code is enabled (safety = 3) ;;; Elimination of unnecessary variables is disabled (speed = 1) ;;; Reading source file "pkg.lisp" ;;; Writing binary file "pkg.hbin" Loading binary of PKG... Compiling WALK... ;;; Reading source file "walk.lisp" ;;; Writing binary file "walk.hbin" Loading binary of WALK... Compiling ITERATE... ;;; Reading source file "iterate.lisp" ;;; Writing binary file "iterate.hbin" Loading binary of ITERATE... Compiling MACROS... ;;; Reading source file "macros.lisp" ;;; Writing binary file "macros.hbin" Loading binary of MACROS... Compiling LOW... ;;; Reading source file "low.lisp" ;;; Writing binary file "low.hbin" Loading binary of LOW... Compiling LUCID-LOW... ;;; Reading source file "lucid-low.lisp" ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Writing binary file "lucid-low.hbin" Loading binary of LUCID-LOW... ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. Compiling FIN... ;;; Reading source file "fin.lisp" ;;; Writing binary file "fin.hbin" Loading binary of FIN... Compiling DEFCLASS... ;;; Reading source file "defclass.lisp" ;;; While compiling EXPAND-DEFCLASS ;;; Warning: Free variable *DEFCLASS-TIMES* assumed to be special ;;; Writing binary file "defclass.hbin" Loading binary of DEFCLASS... Compiling DEFS... ;;; Reading source file "defs.lisp" ;;; Writing binary file "defs.hbin" Loading binary of DEFS... Compiling FNGEN... ;;; Reading source file "fngen.lisp" ;;; Writing binary file "fngen.hbin" Loading binary of FNGEN... Compiling LAP... ;;; Reading source file "lap.lisp" ;;; Writing binary file "lap.hbin" Loading binary of LAP... Compiling PLAP... ;;; Reading source file "plap.lisp" ;;; Writing binary file "plap.hbin" Loading binary of PLAP... Compiling CACHE... ;;; Reading source file "cache.lisp" ;;; While compiling EXPAND-CACHE ;;; Warning: Variable IGNORE is bound but not referenced ;;; Writing binary file "cache.hbin" Loading binary of CACHE... Compiling DLAP... ;;; Reading source file "dlap.lisp" ;;; Writing binary file "dlap.hbin" Loading binary of DLAP... Compiling BOOT... ;;; Reading source file "boot.lisp" ;;; Writing binary file "boot.hbin" Loading binary of BOOT... Compiling VECTOR... ;;; Reading source file "vector.lisp" ;;; Writing binary file "vector.hbin" Loading binary of VECTOR... Compiling SLOTS... ;;; Reading source file "slots.lisp" ;;; Writing binary file "slots.hbin" Loading binary of SLOTS... Compiling INIT... ;;; Reading source file "init.lisp" ;;; Writing binary file "init.hbin" Loading binary of INIT... Compiling STD-CLASS... ;;; Reading source file "std-class.lisp" ;;; While compiling ENSURE-CLASS-VALUES ;;; Warning: Variable PROTO is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (STD-CLASS T)) ;;; Warning: Variable DIRECT-SUPERCLASSES is bound but not referenced ;;; While compiling (DEFMETHOD REINITIALIZE-INSTANCE :BEFORE (STD-CLASS)) ;;; Warning: Variable DIRECT-SLOTS is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (BUILT-IN-CLASS T)) ;;; Warning: Variable INITARGS is bound but not referenced ;;; Writing binary file "std-class.hbin" Loading binary of STD-CLASS... ;;; Expanding Reserved Memory ;;; GC: 217926 words [871704 bytes] of dynamic storage in use. ;;; 240824 words [963296 bytes] of free storage available before a GC. ;;; 699574 words [2798296 bytes] of free storage available if GC is disabled. Compiling CPL... ;;; Reading source file "cpl.lisp" ;;; Writing binary file "cpl.hbin" Loading binary of CPL... Compiling BRAID... ;;; Reading source file "braid.lisp" ;;; Writing binary file "braid.hbin" Loading binary of BRAID... Compiling FSC... ;;; Reading source file "fsc.lisp" ;;; Writing binary file "fsc.hbin" Loading binary of FSC... Compiling METHODS... ;;; Reading source file "methods.lisp" ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :AFTER (STANDARD-METHOD T)) ;;; Warning: Variable SLOT-NAMES is bound but not referenced ;;; While compiling (DEFMETHOD SHARED-INITIALIZE :BEFORE (STANDARD-GENERIC-FUNCTION T)) ;;; Warning: Variable DOCUMENTATION is bound but not referenced ;;; While compiling COMPUTE-PRECEDENCE ;;; Warning: Variable NREQ is bound but not referenced ;;; While compiling REAL-ADD-METHOD ;;; Warning: Variable LAMBDA-LIST is bound but not referenced ;;; Writing binary file "methods.hbin" Loading binary of METHODS... Compiling COMBIN... ;;; Reading source file "combin.lisp" ;;; Writing binary file "combin.hbin" Loading binary of COMBIN... Compiling DFUN... ;;; Reading source file "dfun.lisp" ;;; Writing binary file "dfun.hbin" Loading binary of DFUN... Compiling FIXUP... ;;; Reading source file "fixup.lisp" >>Error: The value of X, :METHOD-COMBINATION, should be a LIST CAR: Required arg 0 (X): :METHOD-COMBINATION :C 0: Use a new value :A 1: Abort to Lisp Top Level -> :b CAR <- |(METHOD COMPUTE-DEFAULT-INITARGS (STD-CLASS T T))| <- UPDATE-CLASS <- |(METHOD FINALIZE-INHERITANCE (STD-CLASS))| <- |(METHOD ALLOCATE-INSTANCE (FUNCALLABLE-STANDARD-CLASS))| <- (:INTERNAL EARLY-DFUN DO-MAIN-COMBINED-METHOD) <- EARLY-DFUN <- (:INTERNAL EARLY-UPDATE-DISCRIMINATOR-CODE 1) <- FIX-EARLY-GENERIC-FUNCTIONS <- EVAL <- LUCID:COMPILE-FORM <- COMPILE-FILE <- COMPILE-MODULE <- OPERATE-ON-SYSTEM <- COMPILE-PCL <- EVAL <- SYSTEM:ENTER-TOP-LEVEL -> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17567; Thu, 17 May 90 04:49:44 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 90 02:01:38 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 17 MAY 90 02:00:17 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA27272g; Thu, 17 May 90 01:58:51 PDT Received: by ptl-club id AA05031g; Thu, 17 May 90 01:56:09 PDT Date: Thu, 17 May 90 01:56:09 PDT From: Jon L White Message-Id: <9005170856.AA05031@ptl-club> To: gregor@parc.xerox.com Cc: CommonLoops.PA@Xerox.COM Subject: Emmendation to MayDay, for HP's Precision Architecture The MayDay release is missing one item of relevance to Lucid's "PA" port to the HP Series 800 machines. To be added to the list for *pathname-extensions*, in defsys.lisp: #+(and Lucid PA) ("lisp" . "hbin") -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA17646; Thu, 17 May 90 04:54:30 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 17 MAY 90 02:30:12 PDT Return-Path: Redistributed: CommonLoops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 17 MAY 90 02:27:42 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA27358g; Thu, 17 May 90 02:25:30 PDT Received: by ptl-club id AA05051g; Thu, 17 May 90 02:22:44 PDT Date: Thu, 17 May 90 02:22:44 PDT From: Jon L White Message-Id: <9005170922.AA05051@ptl-club> To: straz@media-lab.media.mit.edu Cc: CommonLoops.PA@Xerox.COM In-Reply-To: Steve Strassmann's message of Tue, 15 May 90 16:39:55 EDT <9005152039.AA08196@media-lab> Subject: May Day PCL won't compile in HP Lucid 3.0 Both of these problems are due to bugs in the underlying Lisp, rather than due to PCL. They don't occur either in Lucid's other 3.0 ports, nor in the 4.0 "Beta" for the HP 850; but alas I realize that it is the 850 with a 3.0 release that you are stuck with right now. Perhaps there will be a patch for these two bugs. Note the internal Lucid bug numbers: Bug #05490 -- a certain case of ECASE is mishandled by the compiler [this is an Production compiler problem corresponding to your error msg ">>Error: LUCID::T0 should be a LIST"] Bug #05491 -- DELETE-DUPLICATES screws up with :KEY = #'CAR [this *might* also be due to a root cause of miscompilation by the Production compiler; it is the problem corresponding to your error msg ">>Error: The value of X, :METHOD-COMBINATION, should be a LIST"] -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20516; Tue, 22 May 90 00:04:58 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 21 MAY 90 14:43:12 PDT Return-Path: Redistributed: commonloops.pa Received: from polyslo.CalPoly.EDU ([129.65.17.1]) by Xerox.COM ; 21 MAY 90 14:34:10 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA03653; Mon, 21 May 90 14:33:55 -0700 Date: Mon, 21 May 90 14:33:55 -0700 From: jrobinso@polyslo.CalPoly.EDU (Joseph L. Robinson) Message-Id: <9005212133.AA03653@polyslo.CalPoly.EDU> To: commonloops.pa@Xerox.COM Subject: pcl install problems Hi, I am having trouble installing PCL on KCL here at Cal Poly. I have gotten through a good number of files, but I am stuck at one spot. I get a segmentation fault just after the compiling messaage in the file fixup.lisp. All that this file does is call the function fix-early-generic-functions. The definition of this function is in boot.lisp and there is a comment there about a particular class that must have at least one instance. I tried putting in a call to (make-instance class-name), but I still get the segmentation fault with no other message. Any ideas about what this problem could be? Joseph Robinson (jrobinso@polyslo.calpoly.edu) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26752; Tue, 22 May 90 08:40:07 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 90 08:38:24 PDT Return-Path: Redistributed: commonloops.pa Received: from atc.boeing.com ([130.42.28.80]) by Xerox.COM ; 22 MAY 90 08:36:43 PDT Received: by atc.boeing.com on Tue, 22 May 90 08:35:35 PDT Date: Tue, 22 May 90 08:41 PDT From: Stephen L. Nicoud Subject: Locatives and Class slots To: commonloops.pa@Xerox.COM, slug@ai.sri.com Cc: snicoud@atc.boeing.com Message-Id: <19900522154121.3.SLN@SKAGIT.atc.boeing.com> I'm converting an application using New Flavors to use PCL on a Symbolics 3650 (7.2). I have several cases where the code uses a flavor instance variable as an argument to SCL:LOCF. The resulting locative is then used with SCL:PROCESS-LOCK and SCL:PROCESS-UNLOCK. I can't seem to get the same functionality with class slots. Would anyone care to make suggestions about how to proceed? Is there a way to get a locative to a PCL class slot? Steve -- Stephen L. Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26885; Tue, 22 May 90 08:51:18 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 MAY 90 08:50:37 PDT Return-Path: Redistributed: commonloops.pa Received: from CCRMA-F4.Stanford.Edu ([36.49.0.192]) by Xerox.COM ; 22 MAY 90 08:48:10 PDT Message-Id: Date: 22 May 90 08:45 PDT From: Rick Taube To: commonloops.pa@Xerox.COM While attempting to compile May Day PCL in Franz on a NeXT machine: "5/1/90 May Day PCL (REV 2)" Allegro CL 3.1 [NeXT] (8/30/89) I get the following error while compiling CPATCH.LISP: Compiling CPATCH... ; --- Compiling file /private/Net/cm-nnfs/user/hkt/cl/pcl/may-day/cpatch.lisp --- 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 [changing package from "USER" to "HYPERION"] If I continue the compilation process I get an additional error in quadlap.lisp with an unknown package "R": ; --- Compiling file /private/Net/cm-nnfs/user/hkt/cl/pcl/may-day/quadlap.lisp --- ; 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] [changing package from "USER" to "COMPILER"] [1] Both CPATCH.LISP and QUADLAP.LISP appear to be files specific to Franz Lisp and the LAP code interface. rick taube hkt@ccrma-f4.stanford.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27296; Tue, 22 May 90 09:04:34 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 90 09:04:10 PDT Return-Path: Redistributed: commonloops.pa Received: from spade.parc.xerox.com ([13.1.100.26]) by Xerox.COM ; 22 MAY 90 09:02:32 PDT Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA10270; Tue, 22 May 90 09:02:29 PDT Message-Id: <9005221602.AA10270@spade.parc.xerox.com> Date: Tue, 22 May 90 09:02:29 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: HKT@CCRMA-F4.Stanford.Edu Cc: commonloops.pa@Xerox.COM In-Reply-To: Rick Taube's message of 22 May 90 08:45 PDT Line-Fold: NO The conditionalization of these files in defsys.lisp must be wrong. Change it (using #+) so that cpatch and quadlap are only used on SPARC machines. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28250; Tue, 22 May 90 10:05:26 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 90 10:04:06 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 ; 22 MAY 90 10:02:28 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 451074; 22 May 90 13:01:10 EDT Date: Tue, 22 May 90 09:08 PDT From: Richard Lamson Subject: Locatives and Class slots To: Stephen L. Nicoud , commonloops.pa@Xerox.COM, slug@Warbucks.AI.SRI.COM Cc: rsl@max-fleischer.ila-sf.dialnet.symbolics.com In-Reply-To: <19900522154121.3.SLN@SKAGIT.atc.boeing.com> Message-Id: <19900522160834.0.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No Date: Tue, 22 May 90 08:41 PDT From: snicoud@atc.boeing.com (Stephen L. Nicoud) I'm converting an application using New Flavors to use PCL on a Symbolics 3650 (7.2). I have several cases where the code uses a flavor instance variable as an argument to SCL:LOCF. The resulting locative is then used with SCL:PROCESS-LOCK and SCL:PROCESS-UNLOCK. I can't seem to get the same functionality with class slots. Would anyone care to make suggestions about how to proceed? Is there a way to get a locative to a PCL class slot? Nope. In 7.4 and 8.0, there is a way to make a lock instance, using PROCESS:MAKE-LOCK, which can then be locked inside a dynamic extent with PROCESS:WITH-LOCK; you would just put that lock instance into a slot. Of course, in 8.0 you can use Genera CLOS, which will allow locatives to instance slots, I think. In 7.2, one way to do this is to make the slot be a cons, and use its CAR as the lock cell. Here is how I might go about having locks on objects in general (untested, but probably right in form): (defclass locking-mixin () (lock :initform (list nil))) (defmethod with-locked-thing-internal ((locked-thing locking-mixin) continuation &optional (whostate "Lock")) (declare (sys:downward-funarg continuation)) (with-slots (lock) locked-thing (si:with-lock-held ((car lock) :whostate whostate) ; Genera macro (funcall continuation)))) (defmacro with-locked-thing ((thing &optional (whostate '"Lock")) &body body) `(flet ((continuation () ,@body)) (with-locked-thing-internal ,thing #'continuation whostate))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29175; Tue, 22 May 90 10:37:56 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAY 90 10:24:01 PDT Return-Path: Redistributed: commonloops.pa Received: from mail.think.com ([131.239.16.33]) by Xerox.COM ; 22 MAY 90 10:13:29 PDT Return-Path: Received: from Occam.Think.COM by mail.think.com; Tue, 22 May 90 13:13:21 -0400 Date: Tue, 22 May 90 13:13 EDT From: Barry Margolin Subject: Locatives and Class slots To: Stephen L. Nicoud Cc: commonloops.pa@Xerox.COM, slug@Warbucks.AI.SRI.COM In-Reply-To: <19900522154121.3.SLN@SKAGIT.atc.boeing.com> Message-Id: <19900522171316.4.BARMAR@OCCAM.THINK.COM> Date: Tue, 22 May 90 08:41 PDT From: snicoud@atc.boeing.com (Stephen L. Nicoud) I'm converting an application using New Flavors to use PCL on a Symbolics 3650 (7.2). I have several cases where the code uses a flavor instance variable as an argument to SCL:LOCF. The resulting locative is then used with SCL:PROCESS-LOCK and SCL:PROCESS-UNLOCK. I can't seem to get the same functionality with class slots. Would anyone care to make suggestions about how to proceed? Is there a way to get a locative to a PCL class slot? Wait for Genera 8.0 before doing the conversion. Symbolics CLOS allows LOCF to be used with slots. With PCL you probably need to use internal functions to get at the representation, and then use LOCF with that. barmar Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00233; Tue, 22 May 90 15:00:17 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 22 May 90 16:49:31-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 22 May 90 14:48:12 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA15476; Tue, 22 May 90 14:49:41 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA03605; Tue, 22 May 90 14:49:06 pdt Message-Id: <9005222149.AA03605@hplap.hpl.hp.com> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Third CLOS Users and Implementors Workshop X-Mailer: mh6.5 Date: Tue, 22 May 90 14:49:05 PDT From: Andreas Paepcke 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 Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00189; Tue, 22 May 90 14:59:21 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 MAY 90 14:51:03 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.176.66]) by Xerox.COM ; 22 MAY 90 14:49:18 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA15476; Tue, 22 May 90 14:49:41 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA03605; Tue, 22 May 90 14:49:06 pdt Message-Id: <9005222149.AA03605@hplap.hpl.hp.com> To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Third CLOS Users and Implementors Workshop X-Mailer: mh6.5 Date: Tue, 22 May 90 14:49:05 PDT From: Andreas Paepcke 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 Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15801; Wed, 23 May 90 15:04:26 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 23 MAY 90 15:00:41 PDT Return-Path: <@RIVERSIDE.SCRC.Symbolics.COM:doughty@F.ILA.Dialnet.Symbolics.COM> Redistributed: commonloops.pa Received: from RIVERSIDE.SCRC.Symbolics.COM ([128.81.41.21]) by Xerox.COM ; 22 MAY 90 16:05:32 PDT Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 451310; 22 May 90 19:04:22 EDT Received: from BUGS-BUNNY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37372; Tue 22-May-90 19:05:26 EDT Date: Tue, 22 May 90 19:04 EDT From: Dennis L. Doughty Subject: Locatives and Class slots To: barmar@Think.COM Cc: snicoud@atc.boeing.com, commonloops.pa@Xerox.COM, slug@Warbucks.AI.SRI.COM, doughty@fuji.ila.dialnet.symbolics.com In-Reply-To: <19900522171316.4.BARMAR@OCCAM.THINK.COM> Message-Id: <19900522230422.0.DOUGHTY@BUGS-BUNNY.ILA.Dialnet.Symbolics.COM> Line-Fold: No Date: Tue, 22 May 90 13:13 EDT From: barmar@Think.COM (Barry Margolin) Date: Tue, 22 May 90 08:41 PDT From: snicoud@atc.boeing.com (Stephen L. Nicoud) I'm converting an application using New Flavors to use PCL on a Symbolics 3650 (7.2). I have several cases where the code uses a flavor instance variable as an argument to SCL:LOCF. The resulting locative is then used with SCL:PROCESS-LOCK and SCL:PROCESS-UNLOCK. I can't seem to get the same functionality with class slots. Would anyone care to make suggestions about how to proceed? Is there a way to get a locative to a PCL class slot? Wait for Genera 8.0 before doing the conversion. Symbolics CLOS allows LOCF to be used with slots. With PCL you probably need to use internal functions to get at the representation, and then use LOCF with that. barmar In Victoria Day PCL this used to work. I haven't tested it in any other PCL. pcl:: (defun locate-in-instance (instance slot) (let* ((static-slots (sys:eval-in-instance instance 'static-slots)) (wrapper (sys:eval-in-instance instance 'wrapper)) (slots (elt wrapper 1)) (slot-position (position slot slots))) (sys:locf (aref static-slots slot-position)))) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18586; Wed, 23 May 90 17:36:53 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 23 MAY 90 16:54:50 PDT Return-Path: Redistributed: commonloops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 22 MAY 90 19:17:57 PDT To: "Stephen L. Nicoud" Cc: commonloops.pa@Xerox.COM, slug@warbucks.ai.sri.com Subject: Re: Locatives and Class slots In-Reply-To: Your message of Tue, 22 May 90 08:41:00 -0700. <19900522154121.3.SLN@SKAGIT.atc.boeing.com> Date: Tue, 22 May 90 22:27:38 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900523-165450-1720@Xerox> Date: Tue, 22 May 90 08:41 PDT From: "Stephen L. Nicoud" Subject: Locatives and Class slots To: commonloops.pa@xerox.com, slug@warbucks.ai.sri.com cc: snicoud@atc.boeing.com I'm converting an application using New Flavors to use PCL on a Symbolics 3650 (7.2). I have several cases where the code uses a flavor instance variable as an argument to SCL:LOCF. The resulting locative is then used with SCL:PROCESS-LOCK and SCL:PROCESS-UNLOCK. I can't seem to get the same functionality with class slots. Would anyone care to make suggestions about how to proceed? Is there a way to get a locative to a PCL class slot? I have made additions to VD PCL that provides LOCF and LETF support. I have not had a chance to add this to MayDay! Mayday! PCL. The basic idea is to extend the walker to handle LETF, and define optimizers for slot-location. It is a bit tricky because of how with-slots works, but it shouldn't be much different than before. I can send you what i have if you like. k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA18624; Wed, 23 May 90 17:38:34 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 90 17:07:35 PDT Return-Path: Redistributed: CommonLoops.pa Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 22 MAY 90 19:57:17 PDT To: CommonLoops.pa@Xerox.COM Cc: kanderson@DINO.BBN.COM Subject: General 8 allocate-funcallable-instance-1 Date: Tue, 22 May 90 23:05:31 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900523-170735-1761@Xerox> The following #+Genera function (from fin.lisp) does not work in general 8.0 because they added fin as a type of lexical closure. (defun allocate-funcallable-instance-1 () (let* ((whole-fin (make-list (+ 3 (length funcallable-instance-data)))) (new-fin (sys:%make-pointer-offset sys:dtp-lexical-closure whole-fin 0))) ;; ;; note that we DO NOT turn the real lex-closure part of the fin into ;; a dotted pair, because (1) the machine doesn't care and (2) if we ;; did the garbage collector would reclaim everything after the lexical ;; function. ;; (setf (sys:%p-contents-offset new-fin 2) *funcallable-instance-marker*) (setf (si:lexical-closure-function new-fin) #'(lambda (ignore &rest ignore-them-too) (declare (ignore ignore ignore-them-too)) (called-fin-without-function))) #+GENERA-RELEASE-8 (SETF (SI:LEXICAL-CLOSURE-SUBTYPE NEW-FIN) SI:LEXICAL-CLOSURE-SUBTYPE-LEXICAL-CLOSURE) #+ignore (setf (si:lexical-closure-environment new-fin) nil) new-fin)) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19034; Wed, 23 May 90 17:55:33 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 23 MAY 90 17:53:05 PDT Return-Path: Redistributed: CommonLoops.pa Received: from ifi.informatik.uni-stuttgart.de ([129.69.1.198]) by Xerox.COM ; 23 MAY 90 01:54:36 PDT Received: from is.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Wed, 23 May 90 10:53:01 +0200 Received: by is.informatik.uni-stuttgart.de; Wed, 23 May 90 10:54:05 +0200 Message-Id: <2852441617-3740681@MANGO> Sender: rathke@MANGO.informatik.uni-stuttgart.de Date: Wed, 23 May 90 10:53:37 NIL From: Christian Rathke To: CommonLoops.pa@Xerox.COM Subject: slot-method-using-class there seems to be a problem in May-Day-PCL (under LUCID 3.0) with extending slot-method-using-class. The following does not lead to the execution of the additional before method: (in-package 'pcl) (defclass foo () ((x :initform nil))) (defmethod slot-value-using-class :before ((c standard-class) (o foo) slotname) (format t "~%executing slot-value-using-class")) (setq bar (make-instance 'foo)) (slot-value-using-class (find-class 'foo) bar 'x) This used to work in Victoria-Day-PCL. Please help. Thank you. -Christian ============================================================================== Christian Rathke rathke@informatik.uni-stuttgart.de Institut fuer Informatik Universitaet Stuttgart Forststrasse 86 D - 7000 Stuttgart 1 Tel.: (+49 711) 121-1436 ============================================================================== Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01681; Thu, 24 May 90 18:40:25 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 24 MAY 90 11:26:10 PDT Return-Path: Redistributed: commonloops.pa Received: from polyslo.CalPoly.EDU ([129.65.17.1]) by Xerox.COM ; 24 MAY 90 11:18:00 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA29555; Thu, 24 May 90 11:17:44 -0700 Date: Thu, 24 May 90 11:17:44 -0700 From: jrobinso@polyslo.CalPoly.EDU (Joseph L. Robinson) Message-Id: <9005241817.AA29555@polyslo.CalPoly.EDU> To: commonloops.pa@Xerox.COM Subject: pcl install problems Hi, Thanks for the previous responses. I am still having trouble with getting PCL up on KCL. Here is the configuration information that I forgot to include in my last message... Running KCL (June 3, '87) on a Sun 3/50 with a file server (Sun 3/260?). SUN OS 4.0.3 cc 1.103 (This is what I guess that PCL is using, is there a way to change that to use gcc? We have the latest version.) The machines only have 4 meg of RAM, and 10 meg of swap. (There are some color machines with 8 meg RAM and 30 meg swap, but I haven't been using those.) I added the call to (si:catch-bad-signals) before starting the compile of PCL, and I now get the following error message (which is much better than just a segmentation fault, although I don't know what signal 11 means). Any new suggestions are welcomed. Joseph (jrobinso@polyslo.calpoly.edu) --------------------------------------------------------------------- Compiling /blackbird/home/clos/pcl_src/fixup.lisp. Error: Signal 11 caught. The internal memory may be broken. You should check the signal and exit from Lisp. Error signalled by FIX-EARLY-GENERIC-FUNCTIONS. Backtrace: > eval > FIX-EARLY-GENERIC-FUNCTIONS ; (FIX-EARLY-GENERIC-FUNCTIONS) is being compiled. ;;; The form (FIX-EARLY-GENERIC-FUNCTIONS) was not evaluated successfully. ;;; You are recommended to compile again. Successfully called fix-early-generic-functions. No FASL generated. Loading binary of FIXUP... Error: Cannot open the file /blackbird/home/clos/pcl_bin/fixup.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. >> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA19480; Fri, 25 May 90 10:38:01 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 25 MAY 90 10:37:17 PDT Return-Path: Redistributed: commonloops.pa Received: from polyslo.CalPoly.EDU ([129.65.17.1]) by Xerox.COM ; 25 MAY 90 10:34:49 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA02514; Fri, 25 May 90 10:34:32 -0700 Date: Fri, 25 May 90 10:34:32 -0700 From: jrobinso@polyslo.CalPoly.EDU (Joseph L. Robinson) Message-Id: <9005251734.AA02514@polyslo.CalPoly.EDU> To: commonloops.pa@Xerox.COM Subject: sill install problems Hi, Thanks for the previous responses. I am still having trouble with getting PCL up on KCL. Here is the configuration information that I forgot to include in my last message... Running KCL (June 3, '87) on a Sun 3/50 with a file server (Sun 3/260?). SUN OS 4.0.3 cc 1.103 (This is what I guess that PCL is using, is there a way to change that to use gcc? We have the latest version.) The machines only have 4 meg of RAM, and 10 meg of swap. (There are some color machines with 8 meg RAM and 30 meg swap, but I haven't been using those.) I added the call to (si:catch-bad-signals) before starting the compile of PCL, and I now get the following error message (which is much better than just a segmentation fault, although I don't know what signal 11 means). Any new suggestions are welcomed. Joseph (jrobinso@polyslo.calpoly.edu) --------------------------------------------------------------------- Compiling /blackbird/home/clos/pcl_src/fixup.lisp. Error: Signal 11 caught. The internal memory may be broken. You should check the signal and exit from Lisp. Error signalled by FIX-EARLY-GENERIC-FUNCTIONS. Backtrace: > eval > FIX-EARLY-GENERIC-FUNCTIONS ; (FIX-EARLY-GENERIC-FUNCTIONS) is being compiled. ;;; The form (FIX-EARLY-GENERIC-FUNCTIONS) was not evaluated successfully. ;;; You are recommended to compile again. Successfully called fix-early-generic-functions. No FASL generated. Loading binary of FIXUP... Error: Cannot open the file /blackbird/home/clos/pcl_bin/fixup.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. >> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22474; Fri, 25 May 90 13:13:06 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 25 MAY 90 13:07:12 PDT Return-Path: <@SKUNK.CS.CMU.EDU:maeda@WOMBAT.CS.CMU.EDU> Redistributed: CommonLoops.pa Received: from CS.CMU.EDU ([128.2.222.173]) by Xerox.COM ; 25 MAY 90 13:03:35 PDT Received: from skunk.cs.cmu.edu by CS.CMU.EDU id aa20318; 25 May 90 16:02:30 EDT Date: Fri, 25 May 90 16:02 EDT From: "Christopher M. Maeda" Reply-To: cmaeda@CS.CMU.EDU Subject: changing &key/&rest in generic function lambda lists To: CommonLoops.pa@Xerox.COM Message-Id: <19900525200225.2.MAEDA@SKUNK.CS.CMU.EDU.CMU.EDU> I noticed this weird behavior in MayDay R2 PCL on a 3600 running rel 7.2. I not (yet) on the list so excuse me if this has been brought up before. ;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: (FOO :USE (LISP PCL)); Base: 10 -*- ;;;; The defgeneric/defmethod arglist processor sometimes gets wedged if ;;;; I change the arglist of a generic function. (defclass random1 () ()) ;;; Define a method... (defgeneric random-function ((foo random1)) ) ;;; Do something stupid... (defmethod random-function ((foo random1) &key bar) t) ;;; Fix it (ie recompile) (defgeneric random-function ((foo random1) &rest rest-args) ) ;;; This still breaks... (defmethod random-function ((foo random1) &key bar) t) ;;; Yet when we do it right the first time... (defclass random2 () ()) (defgeneric random2-function ((foo random2) &rest keyword-args) ) ;;; It compiles with no problem... (defmethod random2-function ((foo random2) &key bar) t) ;;; Is this an error? ;;; I also noticed that if I do ;;; (setf (symbol-function 'random-function) nil) ;;; and recompile the defgeneric form, things work out ok. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA28859; Fri, 25 May 90 16:08:37 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 25 May 90 18:00:30-CDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA00815g; Fri, 25 May 90 15:59:08 PDT Received: by ptl-club id AA00336g; Fri, 25 May 90 10:09:07 PDT Date: Fri, 25 May 90 10:09:07 PDT From: Jon L White Message-Id: <9005251709.AA00336@ptl-club> To: common-lisp-object-system@mcc.com Subject: Why can't DEFMETHOD talk to FORWARD-REFERENCED classes? Can anyone justify the restriction in 88-002R, p.2-24, that requires "A class must be defined before it can be used as a parameter specializer in a DEFMETHOD form"? Several questions have cropped up in the Lucid user community: (1) What does "defined" mean? does it mean fully-defined such that an instance can be made? [see the preceeding restriction for MAKE-INSTANCE, on p.2-24] Or, could it be "defined" as simply being some forward-referenced class [i.e., no DEFCLASS has ever been done for it, but it was mentioned in the super- classes list of some other defined class] (2) When is a class considered to be "used" in a DEFMETHOD form? Super-eagerly, at the time of macroexpansion of the DEFMETHOD form? Or, eagerly, at the time of evaluation of the DEFMETHOD form? Or, lazyily, at the first invocation of the generic function? Or, lazily, at the first invocation of that particular method? (3) Is this restriction peculiar to DEFMETHOD, or should it apply to ADD-METHOD also? I'm tempted to think that this restriction was imposed before WITH-SLOTS took its present form -- perhaps it was felt that it was necessary to disambiguate between special-variable references and slot "variable" references in method code, such as you might have to do in SmallTalk or Flavors. But this is not the case in CLOS; and if this is the only reason for such a restriction, then it is overly burdening the user community. Incidentally, if *any* reasoning about the slots structure of the specialized class is behind this restriction, then the answer to the first question above must be "fully-defined", since inherited slots contribute to a class's slots structure. -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08039; Mon, 28 May 90 15:10:51 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 90 15:08:50 PDT Return-Path: Redistributed: CommonLoops.pa Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 28 MAY 90 12:23:43 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA19465g; Mon, 28 May 90 09:32:12 PDT Received: by ptl-club id AA01607g; Mon, 28 May 90 09:33:50 PDT Date: Mon, 28 May 90 09:33:50 PDT From: Jon L White Message-Id: <9005281633.AA01607@ptl-club> To: cmaeda@CS.CMU.EDU Cc: CommonLoops.pa@Xerox.COM In-Reply-To: "Christopher M. Maeda"'s message of Fri, 25 May 90 16:02 EDT <19900525200225.2.MAEDA@SKUNK.CS.CMU.EDU.CMU.EDU> Subject: changing &key/&rest in generic function lambda lists re: . . . ;;; Define a method... (defgeneric random-function ((foo random1)) ) ;;; Do something stupid... (defmethod random-function ((foo random1) &key bar) t) . . . The basic problem you have here is that your comments are interchanged. The "stupid" thing you did was in the DEFGENERIC form, not in the DEFMETHOD one. Recall that a DEFGENERIC wants a "lambda list", which is more like a prototype lambda-list for a (regular) function rather than a specialized-lambda-list for a method. As a result of that gaffe, PCL puts something totally random in the arglist slot of the the generic function, which as you might suspect isn't congruent with your method lambda-list. I suspect a CLOS implementation ought to signal an error for such a morphological error in a DEFGENERIC form. -- JonL -- P.S. Above, I say "slot" loosely, as PCL accesses this information with GENERIC-FUNCTION-PRETTY-ARGLIST rather than the more expected GENERIC-FUNCTION-LAMBDA-LIST. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08129; Mon, 28 May 90 15:19:07 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 90 15:11:04 PDT Return-Path: <@VALLECITO.SCRC.Symbolics.COM:Hornig@PROTO-RIVERSIDE.SCRC.Symbolics.COM> Redistributed: CommonLoops.pa Received: from VALLECITO.SCRC.Symbolics.COM ([128.81.41.92]) by Xerox.COM ; 28 MAY 90 12:25:30 PDT Received: from CRAWLER.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via INTERNET with SMTP id 341390; 28 May 90 10:58:07 EDT Date: Fri, 25 May 90 06:35 EDT From: Charles Hornig Subject: General 8 allocate-funcallable-instance-1 To: CommonLoops.pa@Xerox.COM In-Reply-To: <900523-170735-1761@Xerox> Supersedes: <19900525185229.4.HORNIG@CRAWLER.SCRC.Symbolics.COM>, <19900525204049.2.HORNIG@CRAWLER.SCRC.Symbolics.COM> Comments: Retransmission of failed mail. Retransmission of failed mail. Message-Id: <19900525103547.2.HORNIG@CRAWLER.SCRC.Symbolics.COM> Date: Tue, 22 May 90 23:05:31 -0400 From: kanderso@DINO.BBN.COM The following #+Genera function (from fin.lisp) does not work in general 8.0 because they added fin as a type of lexical closure. This change doesn't work. It smashes the CDR-code of the lexical closure to be CDR-NORMAL, which disconnects the first 2 words from the rest of the FIN. At some point the GC will separate them, resulting in disaster. Making PCL work in 8.0 is not this easy. I have a version of May Day PCL that runs in 8.0. I'm willing to send it to anyone who can maintain a publicly-accessible copy. (defun allocate-funcallable-instance-1 () (let* ((whole-fin (make-list (+ 3 (length funcallable-instance-data)))) (new-fin (sys:%make-pointer-offset sys:dtp-lexical-closure whole-fin 0))) ;; ;; note that we DO NOT turn the real lex-closure part of the fin into ;; a dotted pair, because (1) the machine doesn't care and (2) if we ;; did the garbage collector would reclaim everything after the lexical ;; function. ;; (setf (sys:%p-contents-offset new-fin 2) *funcallable-instance-marker*) (setf (si:lexical-closure-function new-fin) #'(lambda (ignore &rest ignore-them-too) (declare (ignore ignore ignore-them-too)) (called-fin-without-function))) #+GENERA-RELEASE-8 (SETF (SI:LEXICAL-CLOSURE-SUBTYPE NEW-FIN) SI:LEXICAL-CLOSURE-SUBTYPE-LEXICAL-CLOSURE) #+ignore (setf (si:lexical-closure-environment new-fin) nil) new-fin)) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08538; Mon, 28 May 90 15:51:59 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 28 MAY 90 15:50:54 PDT Return-Path: Redistributed: commonloops.pa Received: from polyslo.CalPoly.EDU ([129.65.17.1]) by Xerox.COM ; 28 MAY 90 13:04:56 PDT Received: by polyslo.CalPoly.EDU (5.61/2.890629) id AA02746; Mon, 28 May 90 10:25:27 -0700 Date: Mon, 28 May 90 10:25:27 -0700 From: jrobinso@polyslo.CalPoly.EDU (Joseph L. Robinson) Message-Id: <9005281725.AA02746@polyslo.CalPoly.EDU> To: commonloops.pa@Xerox.COM Subject: PCL problems Hi, Thanks for the previous responses. I am still having trouble with getting PCL up on KCL. Here is the configuration information that I forgot to include in my last message... Running KCL (June 3, '87) on a Sun 3/50 with a file server (Sun 3/260?). SUN OS 4.0.3 cc 1.103 (This is what I guess that PCL is using, is there a way to change that to use gcc? We have the latest version.) The machines only have 4 meg of RAM, and 10 meg of swap. (There are some color machines with 8 meg RAM and 30 meg swap, but I haven't been using those.) I added the call to (si:catch-bad-signals) before starting the compile of PCL, and I now get the following error message (which is much better than just a segmentation fault, although I don't know what signal 11 means). Any new suggestions are welcomed. Joseph (jrobinso@polyslo.calpoly.edu) --------------------------------------------------------------------- Compiling /blackbird/home/clos/pcl_src/fixup.lisp. Error: Signal 11 caught. The internal memory may be broken. You should check the signal and exit from Lisp. Error signalled by FIX-EARLY-GENERIC-FUNCTIONS. Backtrace: > eval > FIX-EARLY-GENERIC-FUNCTIONS ; (FIX-EARLY-GENERIC-FUNCTIONS) is being compiled. ;;; The form (FIX-EARLY-GENERIC-FUNCTIONS) was not evaluated successfully. ;;; You are recommended to compile again. Successfully called fix-early-generic-functions. No FASL generated. Loading binary of FIXUP... Error: Cannot open the file /blackbird/home/clos/pcl_bin/fixup.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. >> Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22035; Tue, 29 May 90 09:22:40 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 90 09:11:18 PDT Return-Path: Redistributed: commonloops.pa Received: from turing.cs.rpi.edu ([128.213.1.1]) by Xerox.COM ; 29 MAY 90 09:09:49 PDT Date: Tue, 29 May 90 12:04:54 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA20449; Tue, 29 May 90 12:04:54 EDT Message-Id: <9005291604.AA20449@turing.cs.rpi.edu> To: jrobinso@polyslo.calpoly.edu Subject: Re: pcl install problems Cc: commonloops.pa@Xerox.COM If you want to make May Day PCL work in KCL, you will need to change the file kcl-patches.lisp: change the line that looks like #| to #-(or akcl xkcl)(progn and change the line that looks like |# to ) I am not certain that PCL will work in KCL even with the change above. If you still get this problem after applying this change, you (or someone) needs to use adb or dbx to examine the c stack to find out what c function is currently running and to find out where in fix-early-generic-functions that the problem occurs. You may want to get AKCL instead, from rascal.ics.utexas.edu, and run PCL with it. Richard Harris Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27516; Thu, 31 May 90 08:15:55 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 31 MAY 90 05:58:54 PDT Return-Path: <@mercury.med.pitt.edu:gerhard@med.pitt.edu> Redistributed: commonloops.pa Received: from mercury.med.pitt.edu ([130.49.146.100]) by Xerox.COM ; 31 MAY 90 05:57:57 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA00535; Thu, 31 May 90 08:57:54 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA17328; Thu, 31 May 90 08:57:48 EDT Date: Thu, 31 May 90 08:57:48 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9005311257.AA17328@deimos.med.pitt.edu> To: commonloops.pa@Xerox.COM Subject: add to list Please add me to the mailing list. Gerhard Werner MD gerhard@deimos.med.pitt.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03981; Thu, 31 May 90 11:41:25 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 31 MAY 90 06:11:28 PDT Return-Path: <@mercury.med.pitt.edu:gerhard@med.pitt.edu> Redistributed: commonloops.pa Received: from mercury.med.pitt.edu ([130.49.146.100]) by Xerox.COM ; 31 MAY 90 06:00:54 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA00543; Thu, 31 May 90 09:00:51 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA17345; Thu, 31 May 90 09:00:47 EDT Date: Thu, 31 May 90 09:00:47 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9005311300.AA17345@deimos.med.pitt.edu> To: commonloops.pa@Xerox.COM Subject: Introductory material on common loops We have recently acquired the pcl package and are using with with Allegro CL. We would appreciate any pointers to introductory material on common loops, along with some sample code. We have previously been using the CLOS package. Gerhard Werner MD gerhard@deimos.med.pitt.edu Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29427; Fri, 1 Jun 90 14:24:42 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 01 JUN 90 13:18:10 PDT Return-Path: Redistributed: commonloops.PA Received: from ames.arc.nasa.gov ([128.102.18.3]) by Xerox.COM ; 01 JUN 90 13:16:44 PDT Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 1 Jun 90 13:16:51 -0700 Received: from moe.ESL.COM by esl.ESL.COM (4.1/SMI-4.1) id AA00959; Fri, 1 Jun 90 13:13:26 PDT Received: by moe.ESL.COM (3.2/SMI-3.2) id AA11660; Fri, 1 Jun 90 13:12:21 PDT Date: Fri, 1 Jun 90 13:12:21 PDT From: kirby@moe.esl.com (Robert L. Kirby, Ph.D.) Message-Id: <9006012012.AA11660@moe.ESL.COM> To: commonloops.PA@Xerox.COM Subject: MACL 1.3.2 PCL fin.lisp Since the gateway was down for over a week, I don't know if this was reported before. On a MACII or an SE running Macintosh System 6.0.4, MACL 1.3.2, and "5/1/90 May Day PCL (REV 2)", in order to compile PCL, I have needed to alter the file fin.lisp to contain: ;;; Make uvector-based objects (like funcallable instances) print better. #+: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))) Bob Kirby Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29066; Sun, 3 Jun 90 10:23:48 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 03 JUN 90 01:18:16 PDT Return-Path: Redistributed: commonloops.pa Received: from cosmos.acs.calpoly.edu ([129.65.18.1]) by Xerox.COM ; 03 JUN 90 01:16:13 PDT Received: from altair.acs.calpoly.edu by cosmos.acs.calpoly.edu (4.1/1.881115) id AA00768; Sun, 3 Jun 90 01:16:20 PDT Received: by altair.acs.calpoly.edu (4.1/SMI-4.0) id AA06139; Sat, 2 Jun 90 15:21:32 PDT Date: Sat, 2 Jun 90 15:21:32 PDT From: tstein@altair.acs.calpoly.edu (Tomas D Stein) Message-Id: <9006022221.AA06139@altair.acs.calpoly.edu> To: commonloops.pa@Xerox.COM Problems installing PCL on KCL: Trying to avoid the segmentation violation when compiling we hand-loaded the particular source file. Apparently a construct (defmacro) is missing for defmethod. We could not find any. We did find a (make-defdefiner ...) in pcl_env.lisp. But this seems to be Interlisp and therefore not to be loaded for PCL. Any suggestions or hints are appreciated. Tomas tstein@polyslo.CalPoly.EDU Joseph jrobinso@ployslo.CalPoly.EDU -------------------------------------------------------------- Broken at LOAD. >>(load "fix-early.lisp") T >>(fix-early-generic-functions) Error: The function ALLOCATE-INSTANCE is undefined. Error signalled by FIX-EARLY-GENERIC-FUNCTIONS. Backtrace: > evalhook > FIX-EARLY-GENERIC-FUNCTIONS Broken at LOAD. >>:p Broken at OR. >>:p Broken at PCL::LOAD-BINARY. >>(defmethod tomas ((method standard-method)) (print "hello")) Error: The function DEFMETHOD is undefined. Error signalled by EVALHOOK. Backtrace: > EVALHOOK Broken at PCL::LOAD-BINARY. >>(load "pcl_src/pcl-env.lisp") ;PCL-ENV Copyright (c) 1987, 1988, 1989, by Xerox Corporation. All rights reser ved. Error: There is no package with the name IL. Error signalled by LOAD. Backtrace: > evalhook > load Broken at PCL::LOAD-BINARY. -------------------------------------------------------------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09288; Tue, 5 Jun 90 03:12:33 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 04 JUN 90 13:41:39 PDT Return-Path: Redistributed: CommonLoops.pa Received: from atanasoff.cs.iastate.edu ([129.186.3.1]) by Xerox.COM ; 04 JUN 90 12:25:16 PDT Received: from bambam.cs.iastate.edu by atanasoff.cs.iastate.edu (4.0) id AA15064; Mon, 4 Jun 90 14:22:20 -0500 Received: by bambam.cs.iastate.edu (3.24) id AA06334; Mon, 4 Jun 90 14:24:42 CDT Date: Mon, 4 Jun 90 14:24:42 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) Message-Id: <9006041924.AA06334@bambam.cs.iastate.edu> To: CommonLoops.pa@Xerox.COM Subject: Installation failed for PCL on Sun-3/50... (long) Hi, I'm not sure who is responsible for this problem, but I can't install PCL using AKCL version 1.478 on a Sun-3/50 running Unix 4.2, Release 3.5. I have replaced the "kcl-low.lisp" file in the PCL distribution with the same-named file from rascal.ics.utexas.edu. That file compiled okay, but the problem is that the "fin.lisp" file now has an error, since it is referencing the macro %cclosure-env. This error has the following trace: ------------------------------------------------- (load "defsys.lisp") (setq pcl::*pathname-extensions* '("lisp" . "o")) ;(setq pcl::*pcl-directory* (truename "./")) (or (probe-file "kcl-patches.lisp-") ;replace kcl-patches.lisp by empty file (system "mv kcl-patches.lisp kcl-patches.lisp- ; echo > kcl-patches.lisp")) (pcl::compile-pcl) AKCL (Austin Kyoto Common Lisp) Version(1.478) Fri Jun 1 21:58:41 CDT 1990 Contains Enhancements by W. Schelter Changes in version 1-455 definitely require recompilation of user files. >Loading defsys.lisp Finished loading defsys.lisp T >("lisp" . "o") >#"/usr1/src/sun/local/pcl/kcl-patches.lisp-" >Loading binary of KCL-PATCHES... Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of KCL-LOW... Compiling FIN... Compiling /nfs/fred/usr1/src/sun/local/pcl/fin.lisp. Error: Cannot expand the SETF form (%CCLOSURE-ENV FIN). Error signalled by SYSTEM::SETF-HELPER. Backtrace: > macroexpand > funcall ; (DEFUN ALLOCATE-FUNCALLABLE-INSTANCE-1 ...) is being compiled. ;;; The macro form (SETF (%CCLOSURE-ENV FIN) ENV) was not expanded successfully. Error: Cannot expand the SETF form (%CCLOSURE-ENV FIN). Error signalled by SYSTEM::SETF-HELPER. Backtrace: > funcall > funcall ;;; The macro form (SETF ...) was not expanded successfully. ;; Warning: The variable ENV is not used. No FASL generated. Loading binary of FIN... Error: Cannot open the file /nfs/fred/usr1/src/sun/local/pcl/fin.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. >>Bye. -------------------------------------------- I installed a "fix" for this error, which was to use the old definition of %cclosure-env from the PCL-standard file "kcl-low.lisp" file. This seemed to work, but now I get a different, although perhaps related error, as shown by the following trace. ---------------------------------------------- AKCL (Austin Kyoto Common Lisp) Version(1.478) Fri Jun 1 21:58:41 CDT 1990 Contains Enhancements by W. Schelter Changes in version 1-455 definitely require recompilation of user files. >Loading defsys.lisp Finished loading defsys.lisp T >("lisp" . "o") >#"/usr1/src/sun/local/pcl/kcl-patches.lisp-" >Loading binary of KCL-PATCHES... Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of KCL-LOW... Loading binary of FIN... Loading binary of DEFCLASS... Loading binary of DEFS... Unrecoverable error: Can't allocate. Good-bye!. /usr/local/bin/kcl: 10058 abort - core dumped --------------------------------------------- I made usre that the stacksize on Unix was as large as can be. But this doesn't help. Any ideas? Gary Leavens Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA20514; Tue, 5 Jun 90 13:16:16 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 5 Jun 90 15:05:18-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 5 Jun 90 13:03: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 AA03459; Tue, 5 Jun 90 13:05:29 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA02015; Tue, 5 Jun 90 13:04:53 pdt Message-Id: <9006052004.AA02015@hplap.hpl.hp.com> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: CLOS Report Project: Status and more Contribution Opportunities X-Mailer: mh6.5 Date: Tue, 05 Jun 90 13:04:52 PDT From: Andreas Paepcke Some weeks back I mailed out the call for papers for our CLOS Report publication. That original call is attached again for convenience. The purpose of this message is to let people know about the status of the project and to encourage further potential contributors. We now have a very nice spread of projected contributions, covering most areas in the Call for Papers: the introductory material at this point contains an intellectual history of the language, a short introduction to CLOS features and an introduction to the MOP. The relationship of CLOS to other languages is covered so far with a comparison of CLOS and Eiffel, the analysis of some CLOS aspects in light of the notion of type in ML and the use of the MOP in the context of Smalltalk, as compared to CLOS. Some papers will try to show how the MOP idea - as exemplified in the definition and implementation of CLOS - can have a broader impact. Other papers include thoughts about CLOS style/usage, various applications and, possibly, a paper on the design rationale of CLOS. This will try to recall some of the important design decisions that were made in the past. Several of the sections above can obviously be expanded and thereby provide an opportunity for contribution. Comparisons with other languages and applications which use CLOS are examples. Papers on applications should, of course, emphasize CLOS, rather than the application. Apart from papers, I would be interested to hear input on which past design issues/motivations/gotchas should be included in a rationale paper. The idea is to avoid losing lessons learned during the development of CLOS and its implementation. Deadline for papers is to be October 1. Recall that the audience is intended to be broad. The Report will be a single source for people interested in learning about CLOS and its issues on various levels of sophistication. This is the reason for the spread from introductory to theoretical papers. If you plan to contribute, please drop me a couple of lines to help me continue with my planning. An extended abstract would be an excellent entry to the CLOS Workshop in the Fall at OOPSLA (deadline Aug 1). The Call for Papers for that went out a couple of weeks ago. Submission and attendance at the Workshop is, however, not a prerequisite for participation in the CLOS Report project. Hoping to hear from you, Andreas ;;;;;;;;;;;;;;;;;;;;; Original Call for Papers for CLOS Report ;;;;;;;;;;;;;;;;;;;;; Call for contribution: A "CLOS Report" Publication -------------------------------------------------- With the standardization of chapters 1 and 2 done and people slaving away at building applications, I feel it is time to make CLOS more accessible to people with various degrees of interest. I am therefore soliciting your help in working towards a publication to accomplish this. I have in mind a collection of papers by members of the CLOS community, which would be published in a place where it is easiliy available to a broad audience. This serves the purpose both of popularizing CLOS and of ensuring recognition for the contributors. The appendix of this message contains a draft of the collection's categorization. I am now looking for participation and/or suggestions to get this project off the ground. Examples: * Does the categorization make sense? * Do you recommend an existing paper to be reprinted in the collection? * Would you like to contribute a new paper? * Do you know of someone else who might be able to contribute? * Can you volunteer to help with the editing process? If you can produce a paper, I would very much like to hear from you informally soon. It is enough to explain which category you want to address and very roughly what you have in mind. This will make planning a lot easier because it will help me decide which contributions I must actively reach out for to get coverage. Please help me gather some of this data. As a separate project, I am organizing this year's CLOS Users and Implementors Workshop to be held in the context of OOPSLA '90. I will send out the call for participation as soon as the OOPSLA administration gives a green light. This should be by May 28. Even though the Workshop is separate from the publication described here, there will be linkage in that work done for the Workshop can find its way into the publication. Hoping to hear from you soon, Andreas Hewlett-Packard Laboratory Palo Alto, Ca 94304 paepcke@hplabs.hp.com 415-857-7398 ;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;; %----------------------------------------------------- % Summary Categorization of Papers %--------------------------------- Prologue: What is it like to build a language? Short introduction to CLOS Applications Contrasting CLOS with other languages CLOS Analysis and Discussion CLOS implementations Open research issues Glossary Annotated Bibliography Index over all papers Author Index Prologue: What is it like to build a language? ---------------------------------------------- Audience: General, not necessarily CLOS or even language-oriented. Example contents: - How were existing languages used as blueprints? - How was the design effort organized? - Comments on PCL's implementation and distribution. - Honestly: Was CLOS designed top-down, bottom-up, upside-down, inside-out or without any of the fashionable CASE disciplines? - How did the standardization process work? Any advice for others who want to standardize something? Short introduction to CLOS: --------------------------- Very top level, a few pages that make a casual reader aware of what CLOS is about. If someone has heard the term "CLOS" a lot and wants to know what it is, this should be the place to go to. Example contents: - The five CLOS building blocks. - A few programming examples. - Maybe the architecture (MOP concept). - References to more in-depth sources. Applications: ------------- Contributions in this category should go into some depth. While some parts could be accessible to a casually browsing audience, other parts of the contributions should satisfy a more serious reader who is considering the use of CLOS for her own purposes. Example contents: - What does the application do? - Why was CLOS chosen as the implementation language in the first place? - Where did CLOS shine for the application, where did it weaken or fail? There might be a discussion of how other languages would have worked out for this particular application. - How did the language affect the application design? - How is the application delivered? (ex: Is there a small CLOS delivery kernel?) Contrasting CLOS with other languages: -------------------------------------- Contributions may be arbitrarily complex and specialized, although it would be good to have one or two papers accessible to an interested computer scientist who knows some other object-oriented language and wants an easy way of finding the correct mental pigeon hole for CLOS. It would be nice if contributions were dialectic. Maybe two or more authors with violently different opinions could get together and produce one sharp-edged discussion. Example contents: - Strong and weak points of CLOS vs. other languages. - Classification of languages along a particular theme (ex: realization of functional programming, extensibility, oop philosophy, speed/functionality tradeoffs, etc.) - Classification of applications by which languages would be optimal for their realizations. CLOS Analysis and Discussion: ----------------------------- This is for very CLOS-specific contributions. Like papers in the "language contrasting" category, possibly combative, but *technical* pro/con flames combined into one paper would be interesting if they help to focus a reader's attention on some CLOS aspect. Example contents: - Was the MOP a good idea? - Is the MOP-level class hierarchy sensible? - What were the CLOS architectural tradeoffs? Why were particular alternatives chosen? - Which tradeoffs were resolved to CLOS' detriment. CLOS implementations: --------------------- This is to be a non-commercial category. Papers may point out implementation issues, even if the author(s) have not produced any implementation themselves. Example contents: - Which parts of CLOS are easy to implement, which are hard? - Are there clever optimization opportunities? - Are there language aspects that should have been defined differently, given the experience gained from an actual implemention process. Open research issues: --------------------- The audience for papers in this category would be a competent computer scientist looking for something to do. Example contents: - Anything Glossary: --------- Short definitions of CLOS terms. Annotated Bibliography: ----------------------- This is to cover the range from casual interest to very specific CLOS issues. It would be nice if this could be a union of the bibliographies of the papers. Index ----- Terms, concepts, etc. covering all the papers. Author Index ------------ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA21366; Tue, 5 Jun 90 14:03:20 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 05 JUN 90 13:06:56 PDT Return-Path: Redistributed: commonloops.pa Received: from hplms2.hpl.hp.com ([15.255.176.66]) by Xerox.COM ; 05 JUN 90 13:05:04 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA03459; Tue, 5 Jun 90 13:05:29 pdt Received: from localhost by hplap.hpl.hp.com with SMTP (15.11/15.5+IOS 3.14) id AA02015; Tue, 5 Jun 90 13:04:53 pdt Message-Id: <9006052004.AA02015@hplap.hpl.hp.com> To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: CLOS Report Project: Status and more Contribution Opportunities X-Mailer: mh6.5 Date: Tue, 05 Jun 90 13:04:52 PDT From: Andreas Paepcke Some weeks back I mailed out the call for papers for our CLOS Report publication. That original call is attached again for convenience. The purpose of this message is to let people know about the status of the project and to encourage further potential contributors. We now have a very nice spread of projected contributions, covering most areas in the Call for Papers: the introductory material at this point contains an intellectual history of the language, a short introduction to CLOS features and an introduction to the MOP. The relationship of CLOS to other languages is covered so far with a comparison of CLOS and Eiffel, the analysis of some CLOS aspects in light of the notion of type in ML and the use of the MOP in the context of Smalltalk, as compared to CLOS. Some papers will try to show how the MOP idea - as exemplified in the definition and implementation of CLOS - can have a broader impact. Other papers include thoughts about CLOS style/usage, various applications and, possibly, a paper on the design rationale of CLOS. This will try to recall some of the important design decisions that were made in the past. Several of the sections above can obviously be expanded and thereby provide an opportunity for contribution. Comparisons with other languages and applications which use CLOS are examples. Papers on applications should, of course, emphasize CLOS, rather than the application. Apart from papers, I would be interested to hear input on which past design issues/motivations/gotchas should be included in a rationale paper. The idea is to avoid losing lessons learned during the development of CLOS and its implementation. Deadline for papers is to be October 1. Recall that the audience is intended to be broad. The Report will be a single source for people interested in learning about CLOS and its issues on various levels of sophistication. This is the reason for the spread from introductory to theoretical papers. If you plan to contribute, please drop me a couple of lines to help me continue with my planning. An extended abstract would be an excellent entry to the CLOS Workshop in the Fall at OOPSLA (deadline Aug 1). The Call for Papers for that went out a couple of weeks ago. Submission and attendance at the Workshop is, however, not a prerequisite for participation in the CLOS Report project. Hoping to hear from you, Andreas ;;;;;;;;;;;;;;;;;;;;; Original Call for Papers for CLOS Report ;;;;;;;;;;;;;;;;;;;;; Call for contribution: A "CLOS Report" Publication -------------------------------------------------- With the standardization of chapters 1 and 2 done and people slaving away at building applications, I feel it is time to make CLOS more accessible to people with various degrees of interest. I am therefore soliciting your help in working towards a publication to accomplish this. I have in mind a collection of papers by members of the CLOS community, which would be published in a place where it is easiliy available to a broad audience. This serves the purpose both of popularizing CLOS and of ensuring recognition for the contributors. The appendix of this message contains a draft of the collection's categorization. I am now looking for participation and/or suggestions to get this project off the ground. Examples: * Does the categorization make sense? * Do you recommend an existing paper to be reprinted in the collection? * Would you like to contribute a new paper? * Do you know of someone else who might be able to contribute? * Can you volunteer to help with the editing process? If you can produce a paper, I would very much like to hear from you informally soon. It is enough to explain which category you want to address and very roughly what you have in mind. This will make planning a lot easier because it will help me decide which contributions I must actively reach out for to get coverage. Please help me gather some of this data. As a separate project, I am organizing this year's CLOS Users and Implementors Workshop to be held in the context of OOPSLA '90. I will send out the call for participation as soon as the OOPSLA administration gives a green light. This should be by May 28. Even though the Workshop is separate from the publication described here, there will be linkage in that work done for the Workshop can find its way into the publication. Hoping to hear from you soon, Andreas Hewlett-Packard Laboratory Palo Alto, Ca 94304 paepcke@hplabs.hp.com 415-857-7398 ;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;; %----------------------------------------------------- % Summary Categorization of Papers %--------------------------------- Prologue: What is it like to build a language? Short introduction to CLOS Applications Contrasting CLOS with other languages CLOS Analysis and Discussion CLOS implementations Open research issues Glossary Annotated Bibliography Index over all papers Author Index Prologue: What is it like to build a language? ---------------------------------------------- Audience: General, not necessarily CLOS or even language-oriented. Example contents: - How were existing languages used as blueprints? - How was the design effort organized? - Comments on PCL's implementation and distribution. - Honestly: Was CLOS designed top-down, bottom-up, upside-down, inside-out or without any of the fashionable CASE disciplines? - How did the standardization process work? Any advice for others who want to standardize something? Short introduction to CLOS: --------------------------- Very top level, a few pages that make a casual reader aware of what CLOS is about. If someone has heard the term "CLOS" a lot and wants to know what it is, this should be the place to go to. Example contents: - The five CLOS building blocks. - A few programming examples. - Maybe the architecture (MOP concept). - References to more in-depth sources. Applications: ------------- Contributions in this category should go into some depth. While some parts could be accessible to a casually browsing audience, other parts of the contributions should satisfy a more serious reader who is considering the use of CLOS for her own purposes. Example contents: - What does the application do? - Why was CLOS chosen as the implementation language in the first place? - Where did CLOS shine for the application, where did it weaken or fail? There might be a discussion of how other languages would have worked out for this particular application. - How did the language affect the application design? - How is the application delivered? (ex: Is there a small CLOS delivery kernel?) Contrasting CLOS with other languages: -------------------------------------- Contributions may be arbitrarily complex and specialized, although it would be good to have one or two papers accessible to an interested computer scientist who knows some other object-oriented language and wants an easy way of finding the correct mental pigeon hole for CLOS. It would be nice if contributions were dialectic. Maybe two or more authors with violently different opinions could get together and produce one sharp-edged discussion. Example contents: - Strong and weak points of CLOS vs. other languages. - Classification of languages along a particular theme (ex: realization of functional programming, extensibility, oop philosophy, speed/functionality tradeoffs, etc.) - Classification of applications by which languages would be optimal for their realizations. CLOS Analysis and Discussion: ----------------------------- This is for very CLOS-specific contributions. Like papers in the "language contrasting" category, possibly combative, but *technical* pro/con flames combined into one paper would be interesting if they help to focus a reader's attention on some CLOS aspect. Example contents: - Was the MOP a good idea? - Is the MOP-level class hierarchy sensible? - What were the CLOS architectural tradeoffs? Why were particular alternatives chosen? - Which tradeoffs were resolved to CLOS' detriment. CLOS implementations: --------------------- This is to be a non-commercial category. Papers may point out implementation issues, even if the author(s) have not produced any implementation themselves. Example contents: - Which parts of CLOS are easy to implement, which are hard? - Are there clever optimization opportunities? - Are there language aspects that should have been defined differently, given the experience gained from an actual implemention process. Open research issues: --------------------- The audience for papers in this category would be a competent computer scientist looking for something to do. Example contents: - Anything Glossary: --------- Short definitions of CLOS terms. Annotated Bibliography: ----------------------- This is to cover the range from casual interest to very specific CLOS issues. It would be nice if this could be a union of the bibliographies of the papers. Index ----- Terms, concepts, etc. covering all the papers. Author Index ------------ Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22212; Tue, 5 Jun 90 14:45:17 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 05 JUN 90 12:48:29 PDT Return-Path: Redistributed: CommonLoops.pa Received: from turing.cs.rpi.edu ([128.213.1.1]) by Xerox.COM ; 05 JUN 90 12:45:57 PDT Date: Tue, 5 Jun 90 15:45:36 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA17968; Tue, 5 Jun 90 15:45:36 EDT Message-Id: <9006051945.AA17968@turing.cs.rpi.edu> To: CommonLoops.pa@Xerox.COM Subject: May Day PCL with KCL and AKCL Some notes on using "5/1/90 May Day PCL (REV 2)" with KCL and AKCL. If you are using May Day PCL with KCL or AKCL and are having problems, you might find answers here. 1. Because of a bug in KCL's reader, you must add a return character to the end of precom2.lisp. 2. KCL will try to load the PCL file "init" when it starts up, if you rename the files as is mentioned in defsys.lisp. I suggest that you do not rename any file except maybe "defsys", and also that you change the (files-renamed-p t) to (files-renamed-p nil) in defsys.lisp. 3. If you are using KCL (instead of AKCL), you will need to change the file kcl-patches.lisp: change the line that looks like #| to #-(or akcl xkcl)(progn and change the line that looks like |# to ) 4. If you are using AKCL, you do not need to do anything to the file kcl-patches.lisp. 5. While fixup.lisp compiles, there will be a long pause, because KCL's compiler is not reentrant, and some uncompiled code is run. If you want, you can change the form (fix-early-generic-functions) to (fix-early-generic-functions t) in fixup.lisp to see what is happening. 6. If you want, you can apply the changes in kcl-mods.text to your KCL or AKCL to make PCL run faster. The file kcl-mods.text is different from what it was in earlier versions of PCL. If you do not make these changes, or if you made the old changes, things will still work. 7. If you are using AKCL, and you previously used the kcl-low.lisp file from rascal.ics.utexas.edu, you should not use it this time. The kcl-low.lisp that comes with May Day PCL works fine. If you insist on using an old version of kcl-low.lisp, you will need to use an old version of the KCL part of fin.lisp as well. 8. If you are using a recent version of AKCL, you might want to do a (setq compiler::*compile-ordinaries* t) before compiling PCL. Read the entry for compile-file in the akcl file doc/DOC to decide. I do not do this myself, but it might make things faster. 9. I recommend that you use AKCL version 457 or newer rather than using KCL or an older version of AKCL, because there are some bugs in KCL that cause problems for May Day PCL. 10. I have tested May Day PCL in AKCL version 473 three ways so far: (1) Using (proclaim '(optimize (speed 3) (safety 1) (space 0))), and without the changes to AKCL in kcl-mods.text, (2) Using (proclaim '(optimize (speed 3) (safety 1) (space 0))), and with the changes to AKCL in kcl-mods.text, (3) Using (proclaim '(optimize (speed 3) (safety 0) (space 0))) (Note: this is what you get by default), and with the changes to AKCL in kcl-mods.text. I have had no problems. Richard Harris Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22219; Tue, 5 Jun 90 14:48:10 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 90 14:15:18 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 ; 05 JUN 90 14:14:01 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 455820; 5 Jun 90 17:13:02 EDT Date: Tue, 5 Jun 90 13:30 PDT From: Richard Lamson Subject: Bugs we have found in MayDay PCL To: CommonLoops.pa@Xerox.COM Supersedes: <19900605173334.2.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Comments: Retransmission of failed mail. Message-Id: <19900605203040.5.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No 1. The code which constructs the dispatch functions for generic functions doesn't work for EQL methods. This is especially surprising since EQL methods did work in some earlier version of PCL. 2. :AROUND methods for generic functions which take optional arguments get rewritten under Genera into methods which cannot be loaded because PCL claims the argument lists are not congruent. For example, (defclass test () ((test-list :initform nil))) (defmethod test-one ((test test) &optional test-p) (declare (ignore test-p)) (null test)) (defmethod test-one :around ((test test) &optional test-p) (declare (ignore test-p)) (or (null *standard-output*) (call-next-method))) Error: Attempt to add the method # to the generic function #. But the method has "fewer" optional arguments than the generic function. This happens because the second method is rewritten as follows: (DEFUN (PCL:METHOD TEST-ONE :AROUND (TEST)) (#:TEST &REST #:AMPERSAND-ARGS) ...) which appears not to be congruent to the other method definition. A patch for this problem appears at the end of this message. 3. PCL uses some of the parameters to methods, and doesn't bother to remove the IGNORE declarations for those parameters: (defmethod test-two ((test test) thing1 thing2) (declare (ignore thing2)) (push thing1 (slot-value test 'test-list))) For Function (PCL:METHOD TEST-TWO (TEST T T)) While compiling THING2: The ignored variable THING2 was referenced. ----------------------------------------------------------------- Patch for the lambda-list congruence bug: ;===================================== (SYSTEM-INTERNALS:BEGIN-PATCH-SECTION) (SYSTEM-INTERNALS:PATCH-SECTION-SOURCE-FILE "PCL:MAY-DAY-PCL;GENERA-LOW.LISP.2") (SYSTEM-INTERNALS:PATCH-SECTION-ATTRIBUTES "-*- Mode:LISP; Package:(PCL Lisp 1000); Base:10.; Syntax:Common-lisp; Patch-File: Yes -*-") (defun pcl-fdefine-helper (gspec qualifiers specializers fn) (let* ((dlist (scl:debugging-info fn)) (class (cadr (assoc 'pcl-method-class dlist))) (doc (cadr (assoc 'pcl-documentation dlist))) (lambda-list (let ((ll-stuff (assoc 'pcl-lambda-list dlist))) (if ll-stuff (cadr ll-stuff) (arglist fn)))) (plist (cadr (assoc 'pcl-plist dlist)))) (load-defmethod (or class 'standard-method) gspec qualifiers specializers lambda-list doc (getf plist :isl-cache-symbol) plist fn))) ----------------------------------------------------------------- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01513; Wed, 6 Jun 90 18:34:39 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 06 JUN 90 14:57:40 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 ; 06 JUN 90 14:51:09 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 456597; 6 Jun 90 17:15:48 EDT Date: Wed, 6 Jun 90 13:29 PDT From: Richard Lamson Subject: Spurious warning about ignored variables fixed. To: CommonLoops.pa@Xerox.COM Cc: rsl@max-fleischer.ila-sf.dialnet.symbolics.com, York@max-fleischer.ila-sf.dialnet.symbolics.com Message-Id: <19900606202944.9.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL NIL :TINY) "TINY") Fonts: CPTFONT, TINY Line-Fold: No 1In Symbolics 3620 PCL in Genera 7.2, System 376.166, Experimental Logical Pathnames Translation Files NEWEST, Utilities 27.31, Server Utilities 28.5, Hardcopy 118.17, Zmail 165.23, LMFS 102.8, Tape 82.19, Nsage 27.246, Extended Help 18.4, Documentation Database 62.1, Mailer 17.1, Print Spooler 16.1, Domain Name Server 17.1, Experimental ILA-SF-Site-System 1.24, Experimental ILA-SF-Site-Server-System 3.25, microcode 3620-FPA-MIC 420, FEP 208, fep0:>g208-lisp.flod(4), fep0:>g208-loaders.flod(4), fep0:>g208-debug.flod(2), fep0:>g208-info.flod(4), Machine serial number 20194, PCL version: 5/1/90 May Day PCL (REV 2) (from PCL:MAY-DAY-PCL;DEFSYS) on Symbolics 3620 #20194 (Max Fleischer): 0Here is a patch which fixes the following problem: If you have a method which IGNOREs one of its required (unclassed) arguments, which also uses SLOT-VALUE on a constant slot-name, the method body gets rewritten in such a way that the variable is used, but the IGNORE declaration is not removed, so you get warned that you have used a variable you never reference textually in your program. The fix is to remove the IGNORE declaration for a variable you know you will use (all required arguments to such a method). The change is the form between the ";;; ===..." lines below. (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)))))))) Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07161; Mon, 11 Jun 90 23:10:54 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 12 Jun 90 00:55:43-CDT Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jun 90 22:54:14 PDT Received: from spade.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06682; Mon, 11 Jun 90 22:55:21 -0700 Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA03477; Mon, 11 Jun 90 22:55:13 PDT Message-Id: <9006120555.AA03477@spade.parc.xerox.com> Date: Mon, 11 Jun 90 22:55:13 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: common-lisp-object-system@sail.stanford.edu Subject: initargs and change-class Line-Fold: NO It appears that we never made the change to have change-class and update-instance-for-redefined-class accept initialization arguments. We should do this, a number of people have asked for it, it is consistent, simple, and provides an elegant way to pass information about why the class is being changed. In fact, it seems (to me at least) that this is just something we forgot to do before rather than a real decision we made not to do it. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA08944; Tue, 12 Jun 90 18:55:20 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 12 Jun 90 20:46:28-CDT Received: from charon.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jun 90 18:45:05 PDT Received: by charon.MIT.EDU id AA02678; Tue, 12 Jun 90 21:45:43 EDT Date: Tue, 12 Jun 90 21:45:43 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9006130145.AA02678@charon.MIT.EDU> To: gregor@parc.xerox.com Cc: common-lisp-object-system@sail.stanford.edu In-Reply-To: Gregor J. Kiczales's message of Mon, 11 Jun 90 22:55:13 PDT <9006120555.AA03477@spade.parc.xerox.com> Subject: initargs and change-class > It appears that we never made the change to have change-class and > update-instance-for-redefined-class accept initialization arguments. 88-002R p.2-85 describes update-instance-for-redefined-class as accepting initargs. If change-class were to be changed to accept initargs, the merging of these initargs with the initargs currently computed for the call to update-instance-for-different-class would have to be defined. kab Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09214; Tue, 12 Jun 90 19:09:01 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 12 Jun 90 20:52:01-CDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 Jun 90 18:49:58 PDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 807850; 12 Jun 90 21:50:50 EDT Date: Tue, 12 Jun 90 21:54 EDT From: David A. Moon Subject: initargs and change-class To: Gregor J. Kiczales Cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: <9006120555.AA03477@spade.parc.xerox.com> Message-Id: <19900613015442.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Line-Fold: No Date: Mon, 11 Jun 90 22:55:13 PDT From: Gregor J. Kiczales It appears that we never made the change to have change-class and update-instance-for-redefined-class accept initialization arguments. We should do this, a number of people have asked for it, it is consistent, simple, and provides an elegant way to pass information about why the class is being changed. Of course you really mean update-instance-for-different-class, not update-instance-for-redefined-class, or do you have some way to get initialization arguments passed through to the automatic calls to update-instance-for-redefined-class that happen when an obsolete instance is touched? Both update-instance-for-different-class and update-instance-for-redefined-class already accept initialization arguments, so the only issue is change-class. I don't see any harm in adding initialization arguments to change-class and having it pass them through. In fact, it seems (to me at least) that this is just something we forgot to do before rather than a real decision we made not to do it. I don't remember it ever being discussed. At this point we need to go through a formal change process even if we claim we forgot, since the CLOS specification has been published in numerous places, translated into Japanese, engraved on the side of a space probe launched to Mars, etc. It is technically an incompatible change since all user-defined methods for CHANGE-CLASS will get congruency errors after the change is made. However, I would have been in favor if you had proposed it last week. Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09735; Tue, 12 Jun 90 19:52:26 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 12 Jun 90 21:45:42-CDT Received: from charon.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jun 90 19:44:18 PDT Received: by charon.MIT.EDU id AA02942; Tue, 12 Jun 90 22:45:19 EDT Date: Tue, 12 Jun 90 22:45:19 EDT From: kab@charon.MIT.EDU (Kim A. Barrett) Message-Id: <9006130245.AA02942@charon.MIT.EDU> To: kab@charon.MIT.EDU Cc: gregor@parc.xerox.com, common-lisp-object-system@sail.stanford.edu In-Reply-To: Kim A. Barrett's message of Tue, 12 Jun 90 21:45:43 EDT <9006130145.AA02678@charon.MIT.EDU> Subject: initargs and change-class > If change-class were to be changed to accept initargs, the merging of these > initargs with the initargs currently computed for the call to > update-instance-for-different-class would have to be defined. Ignore that -- I was spacing out. Also, I agree with Moon's comment -- to change change-class really requires the formal procedures. The initargs argument to update-instance-for-different-class seems to have rather limited utility without being able to specify initargs to change-class though. kab Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05774; Wed, 13 Jun 90 04:20:47 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 12 JUN 90 22:17:16 PDT Return-Path: Redistributed: commonloops.PA Received: from media-lab ([18.85.0.2]) by Xerox.COM ; 12 JUN 90 22:16:07 PDT Received: by media-lab (5.57/DA1.0.2) id AA08586; Wed, 13 Jun 90 01:15:43 EDT Date: Wed, 13 Jun 90 01:15:43 EDT From: Steve Strassmann Message-Id: <9006130515.AA08586@media-lab> To: clue-bugs@dsg.csc.ti.com, hp-support@lucid.com Cc: commonloops.PA@Xerox.COM Subject: CLUE won't compile On an HP 835 running HP-UX 7.0, X11R4, Lucid 3.0, I loaded CLX (MIT R4.2), then PCL (5/22/89 Victoria Day), then attempted to compile CLUE (a user interface package), and got the error below. Is this a problem in PCL or in CLUE? ------------------------------------------------------------------------------ > (cd "/lisp/clue") #P"/lisp/clue7.1/" > (load "defsys") ;;; Loading source file "defsys.lisp" #P"/lisp/clue7.1/defsys.lisp" > (pcl::operate-on-system 'clue :compile) Loading binary of CLUE... Loading binary of CLX-PATCH... ;;; Warning: Redefining function CREATE-WINDOW which used to be defined in "/lisp/clx/requests.lisp" Loading binary of WINDOW-DOC... Loading binary of GC-CACHE... Loading binary of DEFCONTACT... Compiling INTRINSICS... ;;; You are using the compiler in development mode (compilation-speed = 3) ;;; Generation of full safety checking code is enabled (safety = 3) ;;; Optimization of tail calls is disabled (speed = 2) ;;; Reading source file "/lisp/clue/intrinsics.lisp" ;;; Expanding Reserved Memory ;;; GC: 174946 words [699784 bytes] of dynamic storage in use. ;;; 283804 words [1135216 bytes] of free storage available before a GC. ;;; 742554 words [2970216 bytes] of free storage available if GC is disabled. ;;; GC: 174946 words [699784 bytes] of dynamic storage in use. ;;; 283804 words [1135216 bytes] of free storage available before a GC. ;;; 742554 words [2970216 bytes] of free storage available if GC is disabled. >>Trap: Stack overflow SYSTEM:GC-INTERNAL: Required arg 0 (SIZE): 0 :A 0: Abort to Lisp Top Level -> :b SYSTEM:GC-INTERNAL <- PCL::|(METHOD ORDER-SLOTDS (STANDARD-CLASS T T))| <- PCL::UPDATE-SLOTS--CLASS <- PCL::|(METHOD PROPAGATE-CLASS-UPDATE (STANDARD-CLASS T T T))| <- PCL::|(METHOD UPDATE-CLASS (STANDARD-CLASS))| <- PCL::COMPUTE-COLUMN-SPECIALIZERS <- PCL::COMPUTE-COMBINATION-POINTS <- PCL::COMPUTE-COMBINED-METHODS <- PCL::NOTICE-METHODS-CHANGE-1 <- (:INTERNAL (:INTERNAL NIL 0) PCL::RESET-GFS) <- PCL::|(METHOD UPDATE-METHOD-INHERITANCE (STANDARD-CLASS T T))| <- PCL::|(METHOD PROPAGATE-CLASS-UPDATE (STANDARD-CLASS T T T))| <- PCL::|(METHOD UPDATE-CLASS (STANDARD-CLASS))| <- PCL::COMPUTE-COLUMN-SPECIALIZERS <- PCL::COMPUTE-COMBINATION-POINTS <- PCL::COMPUTE-COMBINED-METHODS <- PCL::NOTICE-METHODS-CHANGE-1 <- (:INTERNAL (:INTERNAL NIL 0) PCL::RESET-GFS) <- PCL::|(METHOD UPDATE-METHOD-INHERITANCE (STANDARD-CLASS T T))| <- PCL::|(METHOD PROPAGATE-CLASS-UPDATE (STANDARD-CLASS T T T))| <- PCL::|(METHOD UPDATE-CLASS (STANDARD-CLASS))| <- PCL::COMPUTE-COLUMN-SPECIALIZERS <- PCL::COMPUTE-COMBINATION-POINTS <- PCL::COMPUT... ^C interrupt after stack overflow in the debugger Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05817; Wed, 13 Jun 90 04:25:56 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 12 JUN 90 15:51:11 PDT Return-Path: Redistributed: CommonLoops.pa Received: from spade.parc.xerox.com ([13.1.100.26]) by Xerox.COM ; 12 JUN 90 15:49:46 PDT Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA03680; Tue, 12 Jun 90 15:49:29 PDT Message-Id: <9006122249.AA03680@spade.parc.xerox.com> Date: Tue, 12 Jun 90 15:49:29 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: leavens@bambam.cs.iastate.edu Cc: CommonLoops.pa@Xerox.COM, wfs@nicolas.ma.utexas.edu In-Reply-To: Gary Leavens's message of Tue, 12 Jun 90 16:48:32 CDT <9006122148.AA01305@bambam.cs.iastate.edu> Subject: Re: Problems building PCL with AKCL 1-455 on HP-UX (long) Line-Fold: NO Date: Tue, 12 Jun 90 16:48:32 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) I tried to tell the PCL implementors about this before and never got any response. This is a good opportunity for me to clarify something about the current status of PCL development. As I announced in a long message a couple of months ago, there isn't anyone at PARC doing PCL development or maintenance anymore. At this time, what we are doing here is maintaining a copy of the sources, maintaining the mailing list, and coordinating modifications other people may make to the sources. I will also try to answer as many questions as I can about using PCL. But, I will not be handling bug reports or feature requests. At this stage, that is being done by other PCL users outside of PARC. Or, more appropriately, by the vendor (distributor) of each of the Common Lisp implementations. With regard to your specific problem, I had thought that Richard Harris had sent mail about it, but I could be mistaken. Gregor Kiczales Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05841; Wed, 13 Jun 90 04:28:46 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 12 JUN 90 14:54:59 PDT Return-Path: Redistributed: CommonLoops.pa Received: from atanasoff.cs.iastate.edu ([129.186.3.1]) by Xerox.COM ; 12 JUN 90 14:49:01 PDT Received: from bambam.cs.iastate.edu by atanasoff.cs.iastate.edu (4.0) id AA26168; Tue, 12 Jun 90 16:45:59 -0500 Received: by bambam.cs.iastate.edu (3.24) id AA01305; Tue, 12 Jun 90 16:48:32 CDT Date: Tue, 12 Jun 90 16:48:32 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) Message-Id: <9006122148.AA01305@bambam.cs.iastate.edu> To: CommonLoops.pa@Xerox.COM, wfs@nicolas.ma.utexas.edu Subject: Problems building PCL with AKCL 1-455 on HP-UX (long) Hi, I tried to tell the PCL implementors about this before and never got any response. Perhaps the message got lost. I've been trying to build the latest version of PCL with the latest version of AKCL on Sun 3/50's and HP 9000/300 series computers. But I always run into the same problem, a value-stack overflow. I am using the "May Day PCL (REV 2)", augmented with the file kcl-low.lisp from rescal.ics.utexas.edu in the pub directory. I start up kcl and use the following input (load "defsys.lisp") (setq pcl::*pathname-extensions* '("lisp" . "o")) (or (probe-file "kcl-patches.lisp-") ;replace kcl-patches.lisp by empty file (system "mv kcl-patches.lisp kcl-patches.lisp- ; echo > kcl-patches.lisp")) (pcl::compile-pcl) :b :vs and get output below, which may help in debugging. Any ideas? Gary Leavens ??????trace follows?????? AKCL (Austin Kyoto Common Lisp) Version(1.478) Mon Jun 04 13:05:56 EDT 1990 Contains Enhancements by W. Schelter Changes in version 1-455 definitely require recompilation of user files. >Loading defsys.lisp Finished loading defsys.lisp T >("lisp" . "o") >#"/usr1/src/local/pcl/kcl-patches.lisp-" >Loading binary of KCL-PATCHES...Building symbol table for /usr/src/local/akcl/unixport/saved_kcl .. Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of KCL-LOW... Loading binary of FIN... Loading binary of DEFCLASS... Loading binary of DEFS... Error: Value stack overflow. Error signalled by LOAD-DEFCLASS. Broken at LOAD-DEFCLASS. Type :H for Help. PCL>>Backtrace: > eval > compile-pcl > let > cond > operate-on-system > let > let > labels > progn > loop > let > let > if > if > progn > load-module > let* > load-binary > or > load > let > LOAD-DEFCLASS NIL PCL>> IHS[5]: # ---> VS[25] IHS[6]: (COMPILE-PCL (&OPTIONAL M) (LET () #)) ---> VS[29] IHS[7]: LET ---> VS[33] IHS[8]: COND ---> VS[33] IHS[9]: (OPERATE-ON-SYSTEM (NAME MODE &OPTIONAL ARG ...) (LET # # #)) ---> VS[40] VS[40]: ((PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) VS[41]: NIL VS[42]: ((OPERATE-ON-SYSTEM BLOCK #<@00251CF8>)) VS[43]: ((LET ((SYSTEM (GET-SYSTEM NAME))) (UNLESS SYSTEM (ERROR "Can't find system with name ~S." NAME)) (LET ((*SYSTEM-DIRECTORY* (FUNCALL (CAR SYSTEM))) (MODULES (CADR SYSTEM)) (TRANSFORMATIONS NIL)) (LABELS ((LOAD-SOURCE (NAME PATHNAME) (FORMAT T "~&Loading source of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-BINARY (NAME PATHNAME) (FORMAT T "~&Loading binary of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-MODULE (M) (LET* ((NAME (MODULE-NAME M)) (*LOAD-VERBOSE* NIL) (BINARY (MAKE-BINARY-PATHNAME NAME))) (LOAD-BINARY NAME BINARY))) (COMPILE-MODULE (M) (FORMAT T "~&Compiling ~A..." (MODULE-NAME M)) (UNLESS PRINT-ONLY (LET ((NAME (MODULE-NAME M))) (COMPILE-FILE (MAKE-SOURCE-PATHNAME NAME) :OUTPUT-FILE (MAKE-PATHNAME :DEFAULTS (MAKE-BINARY-PATHNAME NAME) :VERSION :NEWEST))))) (TRUE (&REST IGNORE) (DECLARE (IGNORE IGNORE)) 'T)) (SETQ TRANSFORMATIONS (ECASE MODE (:COMPILE (MAKE-TRANSFORMATIONS MODULES #'COMPILE-FILTER #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE-SOME (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (MEMBER (MODULE-NAME M) ARG) (COMPILE-FILTER M TRANSFORMS))) #'MAKE-COMPILE-TRANSFORMATION)) (:QUERY-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:CONFIRM-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (AND (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Go ahead and compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:LOAD (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-LOAD-TRANSFORMATION)) (:QUERY-LOAD (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (DECLARE (IGNORE TRANSFORMS)) (Y-OR-N-P "Load ~A?" (MODULE-NAME M))) #'MAKE-LOAD-WITHOUT-DEPENDENCIES-TRANSFORMATION)))) (PROGN (LOOP (WHEN (NULL TRANSFORMATIONS) (RETURN T)) (LET ((TRANSFORM (POP TRANSFORMATIONS))) (ECASE (CAR TRANSFORM) (:COMPILE (COMPILE-MODULE (CADR TRANSFORM))) (:LOAD (LOAD-MODULE (CADR TRANSFORM))))))))))) IHS[10]: LET ---> VS[44] VS[44]: ((SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) VS[45]: NIL VS[46]: ((OPERATE-ON-SYSTEM BLOCK #<@00251CF8>)) VS[47]: ((UNLESS SYSTEM (ERROR "Can't find system with name ~S." NAME)) (LET ((*SYSTEM-DIRECTORY* (FUNCALL (CAR SYSTEM))) (MODULES (CADR SYSTEM)) (TRANSFORMATIONS NIL)) (LABELS ((LOAD-SOURCE (NAME PATHNAME) (FORMAT T "~&Loading source of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-BINARY (NAME PATHNAME) (FORMAT T "~&Loading binary of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-MODULE (M) (LET* ((NAME (MODULE-NAME M)) (*LOAD-VERBOSE* NIL) (BINARY (MAKE-BINARY-PATHNAME NAME))) (LOAD-BINARY NAME BINARY))) (COMPILE-MODULE (M) (FORMAT T "~&Compiling ~A..." (MODULE-NAME M)) (UNLESS PRINT-ONLY (LET ((NAME (MODULE-NAME M))) (COMPILE-FILE (MAKE-SOURCE-PATHNAME NAME) :OUTPUT-FILE (MAKE-PATHNAME :DEFAULTS (MAKE-BINARY-PATHNAME NAME) :VERSION :NEWEST))))) (TRUE (&REST IGNORE) (DECLARE (IGNORE IGNORE)) 'T)) (SETQ TRANSFORMATIONS (ECASE MODE (:COMPILE (MAKE-TRANSFORMATIONS MODULES #'COMPILE-FILTER #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE-SOME (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (MEMBER (MODULE-NAME M) ARG) (COMPILE-FILTER M TRANSFORMS))) #'MAKE-COMPILE-TRANSFORMATION)) (:QUERY-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:CONFIRM-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (AND (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Go ahead and compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:LOAD (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-LOAD-TRANSFORMATION)) (:QUERY-LOAD (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (DECLARE (IGNORE TRANSFORMS)) (Y-OR-N-P "Load ~A?" (MODULE-NAME M))) #'MAKE-LOAD-WITHOUT-DEPENDENCIES-TRANSFORMATION)))) (PROGN (LOOP (WHEN (NULL TRANSFORMATIONS) (RETURN T)) (LET ((TRANSFORM (POP TRANSFORMATIONS))) (ECASE (CAR TRANSFORM) (:COMPILE (COMPILE-MODULE (CADR TRANSFORM))) (:LOAD (LOAD-MODULE (CADR TRANSFORM)))))))))) IHS[11]: LET ---> VS[48] VS[48]: ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) VS[49]: NIL VS[50]: ((OPERATE-ON-SYSTEM BLOCK #<@00251CF8>)) VS[51]: ((LABELS ((LOAD-SOURCE (NAME PATHNAME) (FORMAT T "~&Loading source of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-BINARY (NAME PATHNAME) (FORMAT T "~&Loading binary of ~A..." NAME) (OR PRINT-ONLY (LOAD PATHNAME))) (LOAD-MODULE (M) (LET* ((NAME (MODULE-NAME M)) (*LOAD-VERBOSE* NIL) (BINARY (MAKE-BINARY-PATHNAME NAME))) (LOAD-BINARY NAME BINARY))) (COMPILE-MODULE (M) (FORMAT T "~&Compiling ~A..." (MODULE-NAME M)) (UNLESS PRINT-ONLY (LET ((NAME (MODULE-NAME M))) (COMPILE-FILE (MAKE-SOURCE-PATHNAME NAME) :OUTPUT-FILE (MAKE-PATHNAME :DEFAULTS (MAKE-BINARY-PATHNAME NAME) :VERSION :NEWEST))))) (TRUE (&REST IGNORE) (DECLARE (IGNORE IGNORE)) 'T)) (SETQ TRANSFORMATIONS (ECASE MODE (:COMPILE (MAKE-TRANSFORMATIONS MODULES #'COMPILE-FILTER #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-COMPILE-TRANSFORMATION)) (:RECOMPILE-SOME (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (MEMBER (MODULE-NAME M) ARG) (COMPILE-FILTER M TRANSFORMS))) #'MAKE-COMPILE-TRANSFORMATION)) (:QUERY-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (OR (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:CONFIRM-COMPILE (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (AND (COMPILE-FILTER M TRANSFORMS) (Y-OR-N-P "Go ahead and compile ~A?" (MODULE-NAME M)))) #'MAKE-COMPILE-TRANSFORMATION)) (:LOAD (MAKE-TRANSFORMATIONS MODULES #'TRUE #'MAKE-LOAD-TRANSFORMATION)) (:QUERY-LOAD (MAKE-TRANSFORMATIONS MODULES #'(LAMBDA (M TRANSFORMS) (DECLARE (IGNORE TRANSFORMS)) (Y-OR-N-P "Load ~A?" (MODULE-NAME M))) #'MAKE-LOAD-WITHOUT-DEPENDENCIES-TRANSFORMATION)))) (PROGN (LOOP (WHEN (NULL TRANSFORMATIONS) (RETURN T)) (LET ((TRANSFORM (POP TRANSFORMATIONS))) (ECASE (CAR TRANSFORM) (:COMPILE (COMPILE-MODULE (CADR TRANSFORM))) (:LOAD (LOAD-MODULE (CADR TRANSFORM))))))))) VS[52]: (LAMBDA-BLOCK-CLOSURE ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) ((TRUE FUNCTION (LAMBDA-BLOCK-CLOSURE ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) ((TRUE FUNCTION (LAMBDA-BLOCK-CLOSURE ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) ((TRUE FUNCTION (LAMBDA-BLOCK-CLOSURE ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM ((LAMBDA-CLOSURE () () () () *PCL-DIRECTORY*) (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (REL-7-2-PATCHES TI-PATCHES PYR-PATCHES XEROX-PATCHES KCL-PATCHES IBCL-PATCHES GCL-PATCHES PKG WALK ITERATE MACROS LOW GENERA-LOW LUCID-LOW XEROX-LOW TI-LOW VAXL-LOW KCL-LOW IBCL-LOW EXCL-LOW CMU-LOW HP-LOW GOLD-LOW PYR-LOW CORAL-LOW FIN DEFCLASS DEFS FNGEN LAP PLAP CPATCH QUADLAP CACHE DLAP BOOT VECTOR SLOTS INIT STD-CLASS CPL BRAID FSC METHODS COMBIN DFUN FIXUP DEFCOMBIN CTYPES CONSTRUCT ENV COMPAT PRECOM1 PRECOM2 PRECOM4))) (PRINT-ONLY NIL) (ARG NIL) (MODE :COMPILE) (NAME PCL)) ((TRUE FUNCTION (LAMBDA-BLOCK-CLOSURE ((TRANSFORMATIONS ((:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:COMPILE #) (:LOAD #) (:COMPILE #) (:LOAD #) (:COMPILE #))) (MODULES (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #)) (SYSTEM and so on .... Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06027; Wed, 13 Jun 90 04:40:37 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 11 JUN 90 18:56:00 PDT Return-Path: Redistributed: commonloops.PA Received: from media-lab ([18.85.0.2]) by Xerox.COM ; 11 JUN 90 18:53:10 PDT Received: by media-lab (5.57/4.8) id AA04381; Mon, 11 Jun 90 21:45:12 EDT Date: Mon, 11 Jun 90 21:45:12 EDT From: Steve Strassmann Message-Id: <9006120145.AA04381@media-lab> To: commonloops.PA@Xerox.COM, bug-clx@expo.lcs.mit.edu Cc: hp-support@lucid.com, clue-bugs@dsg.csc.ti.com Subject: Can't load CLX after loading PCL On an HP 9000/835 running HP-UX 7.0, Lucid 3.0, with Victoria Day PCL and CLX R4.2: [For the purposes of this bug report, a "clean" world means freshly booted base-lisp, where neither PCL nor CLX have been compiled or loaded. Also, I alway restart with a clean lisp after compiling either system] On a clean lisp world, I can compile and run either PCL or CLX. If I load CLX onto a clean world, I can then compile and run PCL. But if I load PCL onto a clean world, then try compiling CLX, it hangs just as I try loading socket.o. The only way out is to bash the lisp process with a kill -9. I get the impression that if PCL is loaded, CLX compiles differently than if it isn't. Is this correct? In particular, the CLUE system assumes that xlib:window and xlib:pixmap are PCL classes rather than defstructs. Why does PCL prevent CLX from compiling? Will CLUE (and other such systems that need both) work ok if I compile-load CLX first, then PCL? ------------------------------------------------------------------------------ ;;; HP Common Lisp, Development Environment, 29 January 1990. ;;; HP-9000, Series 800, Product no. HP92640, Rev. X.00.01 ;;; ;;; Copyright (c) 1988, 1989 by Hewlett-Packard, Co., All Rights Reserved. ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989 by Lucid, Inc., All Rights Reserved. ;;; ;;; This software product contains confidential and trade secret ;;; information belonging to Hewlett-Packard. It may not be copied ;;; for any reason other than for archival and backup purposes. > > > > (cd "/lisp/pcl") #P"/lisp/pcl/" > (load "defsys") ;;; Loading source file "defsys.lisp" #P"/lisp/pcl/defsys.lisp" > (pcl:load-pcl) Loading binary of PKG... Loading binary of WALK... Loading binary of ITERATE... Loading binary of MACROS... Loading binary of LOW... Loading binary of LUCID-LOW... ;;; Warning: %POINTER is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: DEFSTRUCT-SIMPLE-PREDICATE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: ARGLIST is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NAMED-LAMBDA is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: *PRINT-STRUCTURE* is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: NEW-STRUCTURE is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: STRUCTURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDUREP is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-SYMBOL is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: SET-PROCEDURE-REF is being imported from the LUCID package into ;;; the "PCL" package, but it isn't external in LUCID. ;;; Warning: Redefining macro %LOGAND which used to be defined in "low.lisp" ;;; Warning: Redefining macro %ASH which used to be defined in "low.lisp" ;;; Warning: Redefining macro WITHOUT-INTERRUPTS which used to be defined in "low.lisp" ;;; Warning: Redefining macro MAKE-MEMORY-BLOCK which used to be defined in "low.lisp" ;;; Warning: Redefining function IWMC-CLASS-P which used to be defined in structure IWMC-CLASS in "low.lisp" ;;; Warning: Redefining macro OBJECT-CACHE-NO which used to be defined in "low.lisp" ;;; Warning: Redefining function SET-FUNCTION-NAME-1 which used to be defined in "low.lisp" ;;; Warning: Redefining function PRINTING-RANDOM-THING-INTERNAL which used to be defined in "macros.lisp" Loading binary of FIN... Loading binary of DEFS... Loading binary of BOOT... Loading binary of VECTOR... Loading binary of SLOTS... Loading binary of INIT... Loading binary of DEFCLASS... Loading binary of STD-CLASS... Loading binary of POINTS... Loading binary of BRAID1... Loading binary of FSC... Loading binary of METHODS... Loading binary of COMBIN... Loading binary of DCODE... Loading binary of PRECOM1... Loading binary of PRECOM2... Loading binary of PRECOM3... Loading binary of PRECOM4... Loading binary of FIXUP... ;;; Warning: Redefining function PRINT-IWMC-CLASS which used to be defined in "low.lisp" ;;; Warning: Redefining function CHECK-INITARGS-1 which used to be defined in "init.lisp" Loading binary of CONSTRUCT... Loading binary of ENV... Loading binary of HIGH... ;;; Warning: Redefining function BUILT-IN-WRAPPER-OF which used to be defined in "low.lisp" ;;; Warning: Redefining function BUILT-IN-CLASS-OF which used to be defined in "low.lisp" Loading binary of COMPAT... (:PORTABLE-COMMONLOOPS :PCL :HP835 :MULTITASKING :LCL3.0 :EGC :PQC :COMPILER :LOOP :IEEE-FLOATING-POINT :PA :UNIX :LUCID :COMMON-LISP) > (cd "/lisp/clx/") #P"/lisp/clx/" > (load "defsystem") ;;; Loading source file "defsystem.lisp" #P"/lisp/clx/defsystem.lisp" > (xlib:compile-clx "" "" :compile-c nil) ;;; Default paths: #P"" #P"" ;;; Changing compiler to (safety 1) (speed 3) (compilation-speed 0) ;;; Loading foreign files [ Here lisp hangs, and can only be stopped with process kill -9. But without PCL, the same call to XLIB:COMPILE-CLX works fine.] Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11637; Wed, 13 Jun 90 06:49:31 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUN 90 06:48:32 PDT Return-Path: <@mercury.med.pitt.edu:gerhard@med.pitt.edu> Redistributed: commonloops.pa Received: from mercury.med.pitt.edu ([130.49.146.100]) by Xerox.COM ; 13 JUN 90 06:46:52 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA23962; Wed, 13 Jun 90 09:45:33 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA05377; Wed, 13 Jun 90 09:45:30 EDT Date: Wed, 13 Jun 90 09:45:30 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9006131345.AA05377@deimos.med.pitt.edu> To: common-lisp-object-system@sail.stanford.edu, commonloops.pa@Xerox.COM, paepcke@hplap.hpl.hp.com Subject: Re: CLOS Report Project: Status and more Contribution Opportunities Thank you very much for your message. I am not ready to report anything substantial, but I would be very interested in eventually obtaining a copy of the proceedings. Will there be a publication ? Gerhard Werner Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11722; Wed, 13 Jun 90 06:55:20 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 13 Jun 90 08:47:15-CDT Received: from mercury.med.pitt.edu by SAIL.Stanford.EDU with TCP; 13 Jun 90 06:45:50 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA23962; Wed, 13 Jun 90 09:45:33 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA05377; Wed, 13 Jun 90 09:45:30 EDT Date: Wed, 13 Jun 90 09:45:30 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9006131345.AA05377@deimos.med.pitt.edu> To: common-lisp-object-system@sail.stanford.edu, commonloops.pa@xerox.com, paepcke@hplap.hpl.hp.com Subject: Re: CLOS Report Project: Status and more Contribution Opportunities Thank you very much for your message. I am not ready to report anything substantial, but I would be very interested in eventually obtaining a copy of the proceedings. Will there be a publication ? Gerhard Werner Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA11976; Wed, 13 Jun 90 07:14:42 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 13 Jun 90 08:52:52-CDT Received: from mercury.med.pitt.edu by SAIL.Stanford.EDU with TCP; 13 Jun 90 06:51:26 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA23985; Wed, 13 Jun 90 09:52:05 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA05423; Wed, 13 Jun 90 09:51:56 EDT Date: Wed, 13 Jun 90 09:51:56 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9006131351.AA05423@deimos.med.pitt.edu> To: gregor@parc.xerox.com, kab@charon.mit.edu Subject: Re: initargs and change-class Cc: common-lisp-object-system@sail.stanford.edu Thank you for your reply and comments. Gerhard Werner Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12158; Wed, 13 Jun 90 07:26:09 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 13 Jun 90 08:53:48-CDT Received: from mercury.med.pitt.edu by SAIL.Stanford.EDU with TCP; 13 Jun 90 06:52:26 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA23995; Wed, 13 Jun 90 09:53:23 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA05429; Wed, 13 Jun 90 09:53:21 EDT Date: Wed, 13 Jun 90 09:53:21 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9006131353.AA05429@deimos.med.pitt.edu> To: Moon@stony-brook.scrc.symbolics.com, gregor@parc.xerox.com Subject: Re: initargs and change-class Cc: common-lisp-object-system@sail.stanford.edu Thank you for your reply Gerhard Werner Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13675; Wed, 13 Jun 90 08:46:47 -0700 Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Wed 13 Jun 90 10:37:56-CDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 808036; 13 Jun 90 11:16:14 EDT Date: Wed, 13 Jun 90 11:20 EDT From: David A. Moon Subject: FYI: a metaobject extension To: Common-Lisp-Object-System@mcc.com Message-Id: <19900613152009.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Just for your information, not as a proposal, here's a brief description of a metaobject protocol extension that I had to make recently in order to implement efficiently a somewhat complex form of parameterized type inheritance. The basic need is for one argument to a method to be different from the argument passed to the generic function, in a way controlled by the relationship between the class of another argument to the generic function and the class on which the method specializes that argument. The implementation technique is for method combination to insert into the effective method form code that computes the modified argument. The first extension is a way to make CALL-METHOD able to change the arguments. If CALL-METHOD has more than two arguments, then its lambda-list is (method &key next-methods arguments), where :next-methods is the same as the second argument in the standard syntax, and :arguments is an alist of argument substitutions ((index substitute)...) where index is a 0-origin index into the argument list and substitute is a form to be evaluated to produce the replacement value for that argument. The form can depend on the original values of that and other arguments, picked up through the :ARGUMENTS option to DEFINE-METHOD-COMBINATION. The second extension was a modified form of COMPUTE-EFFECTIVE-METHOD with more arguments, including information about the classes of the arguments that will be supplied to the generic function when this effective method is executed. I don't want to describe the exact way this was done, but only to point out that it is a deficiency of the current metaobject protocol that this information is not made available. 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. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14279; Wed, 13 Jun 90 09:30:52 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 13 JUN 90 06:59:20 PDT Return-Path: Redistributed: CommonLoops.pa Received: from atanasoff.cs.iastate.edu ([129.186.3.1]) by Xerox.COM ; 13 JUN 90 06:54:27 PDT Received: from bambam.cs.iastate.edu by atanasoff.cs.iastate.edu (4.0) id AA29660; Wed, 13 Jun 90 08:51:37 -0500 Received: by bambam.cs.iastate.edu (3.24) id AA01980; Wed, 13 Jun 90 08:54:11 CDT Date: Wed, 13 Jun 90 08:54:11 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) Message-Id: <9006131354.AA01980@bambam.cs.iastate.edu> To: wfs@nicolas.ma.utexas.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Bill Schelter's message of Tue, 12 Jun 90 17:31:57 -0500 <9006122231.AA02559@nicolas.ma.utexas.edu> Subject: Re: Problems building PCL with AKCL 1-455 on HP-UX Bill, Thanks very much for your suggestion of using (setq compiler::*compile-ordinaries* t) to compile the PCL files with AKCL. It seems to work! At least, I'm getting past the previous errors. Thanks again, Gary Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14575; Wed, 13 Jun 90 09:50:28 -0700 Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 13 Jun 90 11:43:30-CDT Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Jun 90 09:42:07 PDT Received: from spade.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14419; Wed, 13 Jun 90 09:43:11 -0700 Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA03840; Wed, 13 Jun 90 09:43:02 PDT Message-Id: <9006131643.AA03840@spade.parc.xerox.com> Date: Wed, 13 Jun 90 09:43:02 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp-object-system@SAIL.STANFORD.EDU In-Reply-To: David A. Moon's message of Tue, 12 Jun 90 21:54 EDT <19900613015442.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: Re: initargs and change-class Line-Fold: NO Date: Tue, 12 Jun 90 21:54 EDT From: David A. Moon Line-Fold: No Date: Mon, 11 Jun 90 22:55:13 PDT From: Gregor J. Kiczales It appears that we never made the change to have change-class and update-instance-for-redefined-class accept initialization arguments. We should do this, a number of people have asked for it, it is consistent, simple, and provides an elegant way to pass information about why the class is being changed. Of course you really mean update-instance-for-different-class, not update-instance-for-redefined-class, Right. I don't remember it ever being discussed. At this point we need to go through a formal change process even if we claim we forgot, since the CLOS specification has been published in numerous places, translated into Japanese, engraved on the side of a space probe launched to Mars, etc. Right. I didn't mean, by the casual nature of my message to suggest otherwise. I meant more that we, as the original CLOS committee, should recommened to X3J13 that this si a good change to make. Very much in the spirit of many of the minor corrections we made last week. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06492; Thu, 14 Jun 90 19:15:07 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 13 JUN 90 13:46:54 PDT Return-Path: Redistributed: CommonLoops.pa Received: from emx.utexas.edu ([128.83.1.33]) by Xerox.COM ; 13 JUN 90 13:45:02 PDT Received: from nicolas.ma.utexas.edu by emx.utexas.edu (5.61/1.8) id AA09405; Wed, 13 Jun 90 15:26:53 -0500 Date: Wed, 13 Jun 90 15:25:46 -0500 From: wfs@nicolas.ma.utexas.edu (Bill Schelter) Posted-Date: Wed, 13 Jun 90 15:25:46 -0500 Message-Id: <9006132025.AA03584@nicolas.ma.utexas.edu> Received: by nicolas.ma.utexas.edu (5.61/5.51) id AA03584; Wed, 13 Jun 90 15:25:46 -0500 To: leavens@bambam.cs.iastate.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gary Leavens's message of Wed, 13 Jun 90 08:54:11 CDT <9006131354.AA01980@bambam.cs.iastate.edu> Subject: Re: Problems building PCL with AKCL 1-455 on HP-UX Reply-To: wfs@nicolas.ma.utexas.edu Thanks very much for your suggestion of using (setq compiler::*compile-ordinaries* t) to compile the PCL files with AKCL. It seems to work! At least, I'm getting past the previous errors. I have added this to kcl-low.lisp on rascal. Please let me know if the tests work out and the exact version of pcl you are using from xerox. Thanks Bill Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06654; Thu, 14 Jun 90 19:27:07 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUN 90 08:01:21 PDT Return-Path: Redistributed: CommonLoops.pa Received: from turing.cs.rpi.edu ([128.213.1.1]) by Xerox.COM ; 13 JUN 90 07:59:40 PDT Date: Wed, 13 Jun 90 10:59:05 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA08853; Wed, 13 Jun 90 10:59:05 EDT Message-Id: <9006131459.AA08853@turing.cs.rpi.edu> To: leavens@bambam.cs.iastate.edu Subject: Re: Installation failed for PCL on Sun-3/50... (long) Cc: CommonLoops.pa@Xerox.COM Here is your answer. >> Date: Mon, 4 Jun 90 14:24:42 CDT >> From: leavens@bambam.cs.iastate.edu (Gary Leavens) >> Hi, >> I'm not sure who is responsible for this problem, but I can't install >> PCL using AKCL version 1.478 on a Sun-3/50 running Unix 4.2, Release 3.5. >> I have replaced the "kcl-low.lisp" file in the PCL distribution with >> the same-named file from rascal.ics.utexas.edu. >> ... > > Date: Tue, 5 Jun 90 15:45:36 EDT > From: harrisr@turing.cs.rpi.edu (Richard Harris) > Some notes on using "5/1/90 May Day PCL (REV 2)" with KCL and AKCL. > > If you are using May Day PCL with KCL or AKCL and are having problems, > you might find answers here. > ... > 4. If you are using AKCL, you do not need to do anything to the > file kcl-patches.lisp. > ... > 7. If you are using AKCL, and you previously used the kcl-low.lisp > file from rascal.ics.utexas.edu, you should not use it this time. > The kcl-low.lisp that comes with May Day PCL works fine. If you > insist on using an old version of kcl-low.lisp, you will need to > use an old version of the KCL part of fin.lisp as well. > ... > Richard Harris Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA07986; Thu, 14 Jun 90 21:28:41 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 14 JUN 90 11:46:31 PDT Return-Path: Redistributed: commonloops.pa Received: from spade.parc.xerox.com ([13.1.100.26]) by Xerox.COM ; 14 JUN 90 11:42:32 PDT Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA04254; Thu, 14 Jun 90 11:42:32 PDT Message-Id: <9006141842.AA04254@spade.parc.xerox.com> Date: Thu, 14 Jun 90 11:42:32 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: jona@whale.ils.nwu.edu Cc: commonloops.pa@Xerox.COM In-Reply-To: Kemi Jona's message of Thu, 14 Jun 90 10:00:45 CDT <9006141500.AA02145@whale.ils.nwu.edu> Subject: Re: Disabling compiler in PCL Line-Fold: NO Date: Thu, 14 Jun 90 10:00:45 CDT From: Kemi Jona I am using PCL with Mac Allegro Common Lisp and would like to be able to make a standalone application. The problem is that the compiler is not included in such an application, so any calls to the compiler do nothing. I believe this is a problem when creating new instances in PCL. Can anyone confirm that PCL does in fact make calls to the compiler when new instances are created? I am nearly certain that it does. Second, and more importantly, is there any mechanism by which I can instruct PCL not to call the compiler? There are certain cases where PCL calls the compiler at runtime. This tends to happen when it encounters a generic function or effective method `shape' that it has never seen before. There is a way to get it to precompile these, see the release notes for a description of the macro precompile-random-code-segments. There is also a way to tell PCL not to try and call the compiler, even if it would like to. You can do this by setting the variable *COMPILER-PRESENT-P* to nil. For more information on this, see the definition of COMPILE-LAMBDA in the file low.lisp. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA09657; Fri, 15 Jun 90 00:04:38 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 90 13:27:31 PDT Return-Path: Redistributed: CommonLoops.pa Received: from atanasoff.cs.iastate.edu ([129.186.3.1]) by Xerox.COM ; 14 JUN 90 13:21:25 PDT Received: from bambam.cs.iastate.edu by atanasoff.cs.iastate.edu (4.0) id AA12643; Thu, 14 Jun 90 15:18:30 -0500 Received: by bambam.cs.iastate.edu (3.24) id AA03893; Thu, 14 Jun 90 15:21:06 CDT Date: Thu, 14 Jun 90 15:21:06 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) Message-Id: <9006142021.AA03893@bambam.cs.iastate.edu> To: CommonLoops.pa@Xerox.COM Subject: kcl-low.lisp with gcc bug fix? When trying to compile PCL as is using gcc, I got fatal compiler errors related to a line in the turbo-closure patch of kcl-low.lisp. For the sake of gcc I had to change the expression cc->cc_env to cc->cc.cc_env As someone who switches programming langauges a lot, my C may be rusty, but I think the right-hand side is technically better, since it picks out the cc union member and then the cc_env field. Gcc likes it better. It may be less portable, I don't know. In context, here is the change as found by "diff -c7 kcl-low.lisp~ kcl-low.lisp" on Unix (the ! flags the line in question): *** kcl-low.lisp~ Wed Jun 13 10:21:49 1990 --- kcl-low.lisp Thu Jun 14 12:33:33 1990 *************** *** 60,74 **** #-turbo-closure-env-size (clines " object cclosure_env_nthcdr (n,cc) int n; object cc; { object env; if(n<0)return Cnil; if(type_of(cc)!=t_cclosure)return Cnil; ! env=cc->cc_env; while(n-->0) {if(type_of(env)!=t_cons)return Cnil; env=env->c.c_cdr;} return env; }") #+turbo-closure-env-size --- 60,74 ---- #-turbo-closure-env-size (clines " object cclosure_env_nthcdr (n,cc) int n; object cc; { object env; if(n<0)return Cnil; if(type_of(cc)!=t_cclosure)return Cnil; ! env=cc->cc.cc_env; while(n-->0) {if(type_of(env)!=t_cons)return Cnil; env=env->c.c_cdr;} return env; }") #+turbo-closure-env-size You might also want to change this in other spots, for example a few lines below which are conditionally compiled with #+turbo-closure-env-size. Gary Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12349; Fri, 15 Jun 90 04:07:07 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUN 90 11:47:59 PDT Return-Path: Redistributed: CommonLoops.pa Received: from atanasoff.cs.iastate.edu ([129.186.3.1]) by Xerox.COM ; 13 JUN 90 11:46:07 PDT Received: from bambam.cs.iastate.edu by atanasoff.cs.iastate.edu (4.0) id AA02551; Wed, 13 Jun 90 13:43:20 -0500 Received: by bambam.cs.iastate.edu (3.24) id AA02325; Wed, 13 Jun 90 13:45:55 CDT Date: Wed, 13 Jun 90 13:45:55 CDT From: leavens@bambam.cs.iastate.edu (Gary Leavens) Message-Id: <9006131845.AA02325@bambam.cs.iastate.edu> To: CommonLoops.pa@Xerox.COM Cc: leavens@bambam.cs.iastate.edu Subject: A stupid question Thanks to everyone's help, I got "5/1/90 May Day PCL (REV 2)" to compile with AKCL version 1.478 (on an HP 9000/300 series computer). It also loads. Now for the stupid question: how do I use it? It's not clear from the "documentation". I expected that after executing (pcl::load-pcl) the LISP interpreter would be in a state where I could type in a class definition: (defclass foo () ()) but I get an error: Error: The function DEFCLASS is undefined. Error signalled by EVAL. However, (pcl:defclass foo () ()) works. But does one always have to qualify such symbols? To avoid this I tried executing (use-package 'pcl) but I get the following: Error: Cannot use #<"PCL" package> from #<"USER" package>, because PCL:DEFCLASS and DEFCLASS will cause a name conflict. Error signalled by USE-PACKAGE. That seems odd, given the previous error.... I tried using defsystem and operate-on-system but they don't seem to be defined or exported by the pcl package. Can someone provide me a *small* example? Gary Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12397; Fri, 15 Jun 90 04:12:52 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 14 JUN 90 08:04:54 PDT Return-Path: Redistributed: commonloops.pa Received: from acns.nwu.edu ([129.105.49.1]) by Xerox.COM ; 14 JUN 90 08:01:57 PDT Received: from whale.ils.nwu.edu by acns.acns.nwu.edu id aa09001; 14 Jun 90 10:01 CDT Return-Path: Received: by whale.ils.nwu.edu (4.0/SMI-4.0) id AA02145; Thu, 14 Jun 90 10:00:45 CDT Date: Thu, 14 Jun 90 10:00:45 CDT From: Kemi Jona Message-Id: <9006141500.AA02145@whale.ils.nwu.edu> To: commonloops.pa@Xerox.COM Subject: Disabling compiler in PCL I am using PCL with Mac Allegro Common Lisp and would like to be able to make a standalone application. The problem is that the compiler is not included in such an application, so any calls to the compiler do nothing. I believe this is a problem when creating new instances in PCL. Can anyone confirm that PCL does in fact make calls to the compiler when new instances are created? I am nearly certain that it does. Second, and more importantly, is there any mechanism by which I can instruct PCL not to call the compiler? If not, then using PCL in standalone applications with Allegro CL on the Mac is going to be impossible. Thanks in advance, --Kemi ------------------------------------------------ Kemi Jona jona@ils.nwu.edu Institute for the Learning Sciences 1890 Maple Ave.; Room 304 Evanston, IL 60201 (708) 491-3500 ext. 7100 Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12670; Fri, 15 Jun 90 04:54:15 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 15 JUN 90 02:06:31 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 ; 15 JUN 90 02:02:48 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 460808; 15 Jun 90 05:02:33 EDT Date: Thu, 14 Jun 90 23:53 PDT From: Richard Lamson Subject: [rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM: Please patch this into PCL] To: CommonLoops.pa@Xerox.COM Included-Msgs: <19900324022209.8.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM>, The message of 23 Mar 90 18:22 PST from rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM, The message of 23 Mar 90 18:22 PST from Richard Lamson Message-Id: <19900615065305.3.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No Date: Fri, 23 Mar 90 18:22 PST From: Richard Lamson Subject: Please patch this into PCL To: Gregor@PARC.Xerox.COM cc: Bill-and-Dennis@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM I have modified your method for NO-APPLICABLE-METHOD as follows: (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) (apply generic-function args)) I find that when I fix the problem which was causing the error to occur, I just want to press and have the system retry the call. This seemed the best way to do this, short of figuring out how method dispatch works and signalling/throwing into the guts thereof. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA12686; Fri, 15 Jun 90 04:56:42 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 13 JUN 90 07:05:53 PDT Return-Path: <@mercury.med.pitt.edu:gerhard@med.pitt.edu> Redistributed: CommonLoops.pa Received: from mercury.med.pitt.edu ([130.49.146.100]) by Xerox.COM ; 13 JUN 90 07:04:18 PDT Received: from deimos.med.pitt.edu by mercury.med.pitt.edu (2.1/3.9) id AA24013; Wed, 13 Jun 90 10:02:57 EDT Received: by deimos.med.pitt.edu (2.1/3.9) id AA05492; Wed, 13 Jun 90 10:02:54 EDT Date: Wed, 13 Jun 90 10:02:54 EDT From: gerhard@med.pitt.edu (Gerhard Werner) Message-Id: <9006131402.AA05492@deimos.med.pitt.edu> To: CommonLoops.pa@Xerox.COM, leavens@bambam.cs.iastate.edu, wfs@nicolas.ma.utexas.edu Subject: Re: Problems building PCL with AKCL 1-455 on HP-UX (long) Thank youn for your reply and the code listing. Gerhard Werner (gw@cadre.dsl.pitt.edu) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA13885; Fri, 15 Jun 90 06:32:37 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 15 JUN 90 02:05:56 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 ; 15 JUN 90 02:02:12 PDT Received: from MAX-FLEISCHER.ILA-SF.DIALNET.SYMBOLICS.COM by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 460807; 15 Jun 90 05:02:07 EDT Date: Thu, 14 Jun 90 23:49 PDT From: Richard Lamson Subject: [rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM: Generic functions don't test for keyword validity.] To: CommonLoops.pa@Xerox.COM Cc: rsl@max-fleischer.ila-sf.dialnet.symbolics.com Included-Msgs: <19900426174700.6.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM>, The message of 26 Apr 90 10:47 PDT from rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM, The message of 26 Apr 90 10:47 PDT from Richard Lamson Message-Id: <19900615064914.2.RSL@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM> Line-Fold: No Date: Thu, 26 Apr 90 10:47 PDT From: Richard Lamson Subject: Generic functions don't test for keyword validity. To: BUG-PCL cc: rsl@MAX-FLEISCHER.ILA-SF.Dialnet.Symbolics.COM If you call TEST-METHOD (defined below) on an instance of TEST-CLASS with a keyword other than :K1, it doesn't blow up. This is clearly wrong. Although it's OK to put &ALLOW-OTHER-KEYS into the method function itself, the generic function is required to check for valid keywords. [I was originally writing to complain that the DEFMETHOD expansion always contained &ALLOW-OTHER-KEYS, but that appears to be allowed by CLtL.] (defclass test-class ()()) (defmethod test-method ((test test-class) &key k1) (progn k1)) (defvar test (make-instance 'test-class)) (test-method test :random-keyword t) ;; Doesn't barf! Clearly wrong. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA25100; Fri, 15 Jun 90 13:25:25 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 90 09:23:13 PDT Return-Path: Redistributed: CommonLoops.pa Received: from uunet.uu.net ([192.48.96.2]) by Xerox.COM ; 15 JUN 90 09:21:24 PDT Received: by uunet.uu.net (5.61/1.14) with UUCP id AA16937; Fri, 15 Jun 90 12:21:28 -0400 Received: by franz.Franz.COM (MC 2.0/FI-1.0) id AA10849; Fri, 15 Jun 90 08:55:28 PDT Received: by fiona.Franz.COM (4.0/FI-1.0) id AA02815; Fri, 15 Jun 90 08:55:36 PDT Date: Fri, 15 Jun 90 08:55:36 PDT From: smh@franz.com (Steve Haflich) Message-Id: <9006151555.AA02815@fiona.Franz.COM> To: leavens@bambam.cs.iastate.edu Cc: CommonLoops.pa@Xerox.COM In-Reply-To: Gary Leavens's message of Wed, 13 Jun 90 13:45:55 CDT <9006131845.AA02325@bambam.cs.iastate.edu> Subject: A stupid question From: leavens@bambam.cs.iastate.edu (Gary Leavens) (defclass foo () ()) but I get an error: Error: The function DEFCLASS is undefined. Error signalled by EVAL. However, (pcl:defclass foo () ()) works. But does one always have to qualify such symbols? To avoid this I tried executing (use-package 'pcl) but I get the following: Error: Cannot use #<"PCL" package> from #<"USER" package>, because PCL:DEFCLASS and DEFCLASS will cause a name conflict. Error signalled by USE-PACKAGE. That seems odd, given the previous error.... The USE-PACKAGE error happens because you created the symbol USER::DEFCLASS when you typed the first DEFCLASS form. The subsequent attempt to inherit PCL:DEFCLASS causes a name conflict. This error would not have happened if you hadn't already typed the first form. CLtL1 (p.178 ff) requires this error to be continuable, but I don't know if KCL supports this continuation. Alternatively, you could have removed the mistaken symbol from the USER package using UNINTERN. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05161; Tue, 19 Jun 90 04:53:53 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 18 JUN 90 22:48:43 PDT Return-Path: Redistributed: CommonLoops.PA Received: from inria.inria.fr ([128.93.8.1]) by Xerox.COM ; 18 JUN 90 22:47:19 PDT Received: from litp.ibp.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA21659; Tue, 19 Jun 90 07:46:21 +0200 (MET) Received: by litp.ibp.fr (5.61++/IDA-1.2.8) id AA25104; Tue, 19 Jun 90 07:46:58 +0200 Date: Tue, 19 Jun 90 07:46:58 +0200 From: Benoit HABERT Message-Id: <9006190546.AA25104@litp.ibp.fr> To: CommonLoops.PA@Xerox.COM Subject: Problems with Victoria Day implementation of PCL I am using the PCL implementation Victoria Day to implement a parser (a chart parser, for unification based grammars). In the output files of the parser, I came accross items like: # Scanning Victoria-Day source files, I did not find the string "unknown-object" Furthermore, (make-instance 'unknown-object) triggers an error. There is no class named "unknown-object" While parsing the same text, with the same grammar and the same dictionary, I noticed that the "unknown-objects" appeared at slightly different places. For instance (I am using French Trade-Unions manifestos to test my parser): First parse of a text: e entrai^\nant par la> me^me # des de la personne d autant plus importantes # re la gestion et au contro^le de la participation des entreprises a> l effort de construction # le *1% # et re l extension a> toutes les entreprises du secteur prive< qui n y sont pas encore soumises # au secteur public et nation\alise< et au secteur agricole # le paritarism\e\ re tous les niveaux # et dans toutes les instances de de l emploi judicieux des fonds collect\e\ ) Second parse of the same text e me^me "," des de la personne d autant plus importantes ";" re la gestion et au contro^le de la participation des entreprises a> l effort de construction "(" le *1% ")" et re toutes les entreprises du secteur prive< qui n y sont pas encore soumises "," au secteur public et nationalise< et au secteur agricole ";" le paritarisme re tous les niveaux # et dans toutes les instances de de l emploi judicieux des fonds collect\e\ Redistributed: CommonLoops.PA Received: from NL.CS.CMU.EDU ([128.2.222.56]) by Xerox.COM ; 20 JUN 90 06:53:42 PDT Received: from nl.cs.cmu.edu by NL.CS.CMU.EDU id aa19677; 20 Jun 90 9:52:14 EDT To: Benoit HABERT Cc: CommonLoops.PA@Xerox.COM Reply-To: todd.kaufmann@NL.CS.CMU.EDU Subject: Re: Problems with Victoria Day implementation of PCL In-Reply-To: Your message of Tue, 19 Jun 90 07:46:58 +0200. <9006190546.AA25104@litp.ibp.fr> Date: Wed, 20 Jun 90 09:51:40 EDT Message-Id: <19674.645889900@NL.CS.CMU.EDU> From: Todd.Kaufmann@NL.CS.CMU.EDU > et dans toutes les instances de de # l emploi judicieux des fonds collect\e\ (with Victoria Day in Allegro). Could that be the problem? -todd Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA03095; Wed, 20 Jun 90 09:32:55 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 20 JUN 90 07:36:19 PDT Return-Path: Redistributed: CommonLoops.PA Received: from DINO.BBN.COM ([128.89.3.8]) by Xerox.COM ; 20 JUN 90 07:34:20 PDT To: Benoit HABERT Cc: CommonLoops.PA@Xerox.COM Subject: Re: Problems with Victoria Day implementation of PCL In-Reply-To: Your message of Tue, 19 Jun 90 07:46:58 +0200. <9006190546.AA25104@litp.ibp.fr> Date: Wed, 20 Jun 90 10:55:36 -0400 From: kanderso@DINO.BBN.COM Message-Id: <900620-073619-4591@Xerox> Redistributed: CommonLoops.PA Date: Tue, 19 Jun 90 07:46:58 +0200 From: Benoit HABERT To: CommonLoops.PA@xerox.com Subject: Problems with Victoria Day implementation of PCL I am using the PCL implementation Victoria Day to implement a parser (a chart parser, for unification based grammars). In the output files of the parser, I came accross items like: # Scanning Victoria-Day source files, I did not find the string "unknown-object" Furthermore, (make-instance 'unknown-object) triggers an error. There is no class named "unknown-object" While parsing the same text, with the same grammar and the same dictionary, I noticed that the "unknown-objects" appeared at slightly different places. For instance (I am using French Trade-Unions manifestos to test my parser): First parse of a text: e entrai^\nant par ... As one can notice in these samples, these "unknown-objects" occur "in bursts", then do not appear for a while, and occur again. They replace seemingly punctuation marks which were represented as strings so as not to interfere with Common Lisp macro- characters. To test this hypothesis, I replaced in the test text strings like ";" by symbols like |;| and "unknown-objects" did not appear any more in the output files. Another hint: I did not came accross this problem with Rainy Day. Have you any idea about the origin of this problem, and any solution (apart from avoiding strings !) Benoit Habert Off hand, this doesn't seem like a PCL problem. Rather it seems like a problem with your parser, or the LISP you are using, or perhaps some interaction between them and PCL. Are these unknown-objects PCL instance? What class are they? k Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA22139; Wed, 20 Jun 90 16:35:21 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 20 JUN 90 14:45:12 PDT Return-Path: Redistributed: commonloops.pa Received: from NSFnet-Relay.AC.UK ([128.86.8.6]) by Xerox.COM ; 20 JUN 90 14:44:05 PDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa05177; 20 Jun 90 21:11 BST From: tim@cstr.edinburgh.ac.uk Date: Wed, 20 Jun 90 21:21:42 BST Message-Id: <5021.9006202021@kahlo.cstr.ed.ac.uk> To: info-1100@cis.ohio-state.edu, commonloops.pa@Xerox.COM Subject: CLOS Browser for Xerox Medley X-Organisation: Dandelion Preservation Society I've recently been playing with he CLOS Browser code which was distributed with some version of PCL (Victoria Day?) which I picked up ages ago. I basically have it working, although there's lots of stuff I still need to fix. What I'd like to know is: does anyone out there have a definitive most-recent version of this & if so where can I lay my hands on it? The version I have claims to be 0.02 and basically dates from 1988 I think. I just want to avoid doing work I needn't! Thanks --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 Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA06177; Wed, 20 Jun 90 21:50:56 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 20 JUN 90 21:50:45 PDT Return-Path: Redistributed: CommonLoops.pa Received: from spade.parc.xerox.com ([13.1.100.26]) by Xerox.COM ; 20 JUN 90 21:49:14 PDT Received: by spade.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA05990; Wed, 20 Jun 90 21:49:06 PDT Message-Id: <9006210449.AA05990@spade.parc.xerox.com> Date: Wed, 20 Jun 90 21:49:06 PDT From: Gregor J. Kiczales Sender: gregor@parc.xerox.com To: CommonLoops.pa@Xerox.COM, Common-Lisp-Object-System@Sail.Stanford.Edu Subject: Reflection Workshop Line-Fold: NO (apologies to those of you who will receive this twice) CALL FOR PARTICIPATION ECOOP/OOPSLA-90 Workshop on Reflection and Metalevel Architectures in Object-Oriented Programming Monday, October 22, 1990 Ottawa, Canada Reflective programming languages have tremendous practical value. In fact, external facilities are often provided for non-reflective languages to mimic reflective behaviors. Reflective languages provide natural debugging and tracing facilities as part of the language and not as facilities supplied by the external environment. A reflective language is also capable of performing self evaluation tasks such as code analysis and verification, which are difficult to achieve in a non-reflective language. This workshop will focus on all issues related to reflection and metalevel architectures in object-oriented programming. Presentations and discussion will address both the theoretical foundations and practical applications of reflection in programming languages and environments. The workshop will have three main sessions: theory, implementation, and applications. In the first session, participants are expected to define precisely the vocabulary and terminology used for describing reflection in programming languages in general and in OOP in particular. Examples of such vocabulary are reification, metalevel, reflective facilities, structure reflection, and computational reflection. As part of this session, the discussion should also identify the relationship between metalevel architectures and reflection in object-oriented programming. For example, are metaobjects and metalevel architectures necessary, sufficient, or necessary and sufficient to achieve reflection, and if so why? The discussion should also address the problems associated with infinite metaregression and whether these problems represent, in theory, a threat to the concept of reflection. The second session will focus on practical issues related to implementation of reflective object-oriented languages and environments. Participants will discuss architectures of current languages that support reflective facilities and how they achieve reflection. The penalties and/or efficiency considerations that result from implementing reflection in a language and the techniques used to deal with these issues should be addressed as part of this session. The last session will be devoted to applications that benefit from reflection and metalevel architectures. Examples of such applications are concurrency, distributed systems, persistent objects/databases, language extensions, and self modifying code. Participants should focus on features of the reflective facilities that facilitate the implementation of their applications and discuss the difficulties they may encounter if the application was implemented in a non-reflective environment. Workshop attendance will be by invitation only and is limited to 30 participants. Invitations will be issued on the basis of extended abstracts or position papers. Appropriate papers should not be less than 3 single spaced pages and should state clearly their authors' position and supporting arguments for issues related to one or more of the following topics: - Definitions and terminology of reflection. - Architectures for achieving reflection. - The level on which reflection is implemented (object, underlying language, metalevel). - Implementation of OOP languages and environments that support reflection. - Advantages and disadvantages of reflection in OOP. - Reflection in concurrent systems. - Applications of reflective facilities. The papers will be reviewed by members of the workshop committee and acceptance will be based on both the relevance of the work to the workshop theme and the quality and clarity of the papers. Accepted papers will be distributed to the participants before the workshop, and based on the workshop outcome, we may elect to generate some form of formal publication that will include longer versions of the accepted submissions. Send five copies of extended abstract before August 1, 1990 to: --------------------------------------------------------------- Mamdouh H. Ibrahim EDS Research & Development 3551 Hamlin Rd, 4th. Floor Auburn Hills, MI 48057 USA Phone: (313) 370-1629 e-mail: mhi@edsdrd.eds.com Important Dates: ---------------- August 1, 1990 Deadline for receiving extended abstracts. September 17, 1990 Notification of invitation or rejection. For further information, contact any of the workshop organizers. Workshop organizers: -------------------- Jean-Pierre Briot (European Coordinator) Universite Paris VI - LITP briot@litp.ibp.fr Brian Foote (USA Coordinator) University of Illinois, Urbana-Champaign foote@cs.uiuc.edu Gregor Kiczales (USA Coordinator) Xerox PARC gregor.pa@xerox.com Mamdouh H. Ibrahim (Chair) EDS Research & Development mhi@edsdrd.eds.com Satoshi Matsuoka (Far East Coordinator) University of Tokyo, Japan matsu@is.s.u-tokyo.ac.jp Takuo Watanabe (Far East Coordinator) Tokyo Institute of Technology Japan takuo@is.titech.ac.jp Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA01384; Thu, 21 Jun 90 08:14:02 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 21 JUN 90 08:12:09 PDT Return-Path: Redistributed: commonloops.PA Received: from piccolo.ecn.purdue.edu ([128.46.130.163]) by Xerox.COM ; 21 JUN 90 08:08:03 PDT Received: from localhost by piccolo.ecn.purdue.edu (5.61/1.22jrs) id AA02974; Thu, 21 Jun 90 10:08:07 -0500 Message-Id: <9006211508.AA02974@piccolo.ecn.purdue.edu> To: commonloops.PA@Xerox.COM Subject: Re: May Day PCL with AKCL Date: Thu, 21 Jun 90 10:08:04 EST From: dmc@piccolo.ecn.purdue.edu I have read the "Some notes on using "5/1/90 May Day PCL (REV 2)" with KCL and AKCL." by Richard Harris, however I am having difficulty getting PCL to compile in AKCL 473 on a sparcstation. When I do not use (setq compiler::*compile-ordinaries* t) I get a value stack overflow! When I use (setq compiler::*compile-ordinaries* t) I get the following: AKCL (Austin Kyoto Common Lisp) Version(1.473) Thu May 10 13:29:51 EST 1990 Contains Enhancements by W. Schelter >(load "defsys.lsp") Loading defsys.lsp Finished loading defsys.lsp T >(setq compiler::*compile-ordinaries* t)(pcl:compile-pcl) T >(in-package 'pcl) #<"PCL" package> PCL>(compile-pcl) Compiling KCL-PATCHES... Compiling /home/orchestra3/dmc/range/clos/kcl-patches.lisp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 Finished compiling /home/orchestra3/dmc/range/clos/kcl-patches.o. Loading binary of KCL-PATCHES... ;... ;... (many apparently successfully compiling files, with some warnings ;... ;... Compiling FIXUP... Compiling /home/orchestra3/dmc/range/clos/fixup.lisp. Error: #<# 20033424> is not of type STD-INSTANCE. Error signalled by THE. Backtrace: > eval > fix-early-generic-functions > method-lambda-list > lambda-closure > prog > setf > THE ; (FIX-EARLY-GENERIC-FUNCTIONS) is being compiled. ;;; The form (FIX-EARLY-GENERIC-FUNCTIONS) was not evaluated successfully. ;;; You are recommended to compile again. No FASL generated. Loading binary of FIXUP... Error: Cannot open the file /home/orchestra3/dmc/range/clos/fixup.o. Error signalled by LOAD. Broken at LOAD. Type :H for Help. PCL>>:q Starting a fresh akcl, and doing a (pcl::compile-pcl) results in the same message again. Does anyone have a clue to what the problem is? -- Prof. David Chelberg (dmc@piccolo.ecn.purdue.edu) Received: from MCC.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA05172; Thu, 21 Jun 90 17:42:02 -0700 Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 21 Jun 90 19:30:25-CDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA11201g; Thu, 21 Jun 90 17:28:09 PDT Received: by ptl-club id AA09249g; Thu, 21 Jun 90 17:29:25 PDT Date: Thu, 21 Jun 90 17:29:25 PDT From: Jon L White Message-Id: <9006220029.AA09249@ptl-club> To: Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: Common-Lisp-Object-System@mcc.com In-Reply-To: David A. Moon's message of Wed, 13 Jun 90 11:20 EDT <19900613152009.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Subject: FYI: a metaobject extension 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? -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27027; Fri, 22 Jun 90 00:05:52 -0700 Received: from Chardonnay.ms by ArpaGateway.ms ; 21 JUN 90 22:03:08 PDT Return-Path: Redistributed: commonloops.PA Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 21 JUN 90 22:01:35 PDT Received: by media-lab.media.mit.edu (5.57/DA1.0.2) id AA02384; Fri, 22 Jun 90 01:01:40 EDT Date: Fri, 22 Jun 90 01:01:40 EDT From: Steve Strassmann Message-Id: <9006220501.AA02384@media-lab.media.mit.edu> To: jonl@lucid.com Cc: clue-bugs@dsg.csc.ti.com, hp-support@lucid.com, commonloops.PA@Xerox.COM In-Reply-To: Jon L White's message of Thu, 21 Jun 90 21:20:17 PDT <9006220420.AA09392@ptl-club> Subject: CLUE won't compile Date: Thu, 21 Jun 90 21:20:17 PDT From: Jon L White re: On an HP 835 running HP-UX 7.0, X11R4, Lucid 3.0, I know that the 1990 versions of PCL are much better at avoiding these metacircular screws -- perhaps you could try using the 5/2/90 "May Day" PCL instead of "Victoria Day". Yes, but as I discovered earlier (and you confirmed), May Day PCL doesn't work in Lucid 3.0. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27227; Fri, 22 Jun 90 00:09:47 -0700 Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUN 90 21:21:57 PDT Return-Path: Redistributed: commonloops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 21 JUN 90 21:21:14 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA13100g; Thu, 21 Jun 90 21:19:01 PDT Received: by ptl-club id AA09392g; Thu, 21 Jun 90 21:20:17 PDT Date: Thu, 21 Jun 90 21:20:17 PDT From: Jon L White Message-Id: <9006220420.AA09392@ptl-club> To: straz@media-lab.media.mit.edu Cc: clue-bugs@dsg.csc.ti.com, hp-support@lucid.com, commonloops.PA@Xerox.COM In-Reply-To: Steve Strassmann's message of Wed, 13 Jun 90 01:15:43 EDT <9006130515.AA08586@media-lab> Subject: CLUE won't compile re: On an HP 835 running HP-UX 7.0, X11R4, Lucid 3.0, I loaded CLX (MIT R4.2), then PCL (5/22/89 Victoria Day), then attempted to compile CLUE (a user interface package), and got the error below. Is this a problem in PCL or in CLUE? 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. I know that the 1990 versions of PCL are much better at avoiding these metacircular screws -- perhaps you could try using the 5/2/90 "May Day" PCL instead of "Victoria Day". -- JonL -- Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14182; Fri, 22 Jun 90 19:43:07 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 90 13:15:12 PDT Return-Path: Redistributed: commonloops.PA Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 22 JUN 90 13:13:45 PDT Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA19026g; Fri, 22 Jun 90 13:09:25 PDT Received: by ptl-club id AA09881g; Fri, 22 Jun 90 13:10:40 PDT Date: Fri, 22 Jun 90 13:10:40 PDT From: Jon L White Message-Id: <9006222010.AA09881@ptl-club> To: straz@media-lab.media.mit.edu Cc: clue-bugs@dsg.csc.ti.com, hp-support@lucid.com, commonloops.PA@Xerox.COM In-Reply-To: Steve Strassmann's message of Fri, 22 Jun 90 01:01:40 EDT <9006220501.AA02384@media-lab.media.mit.edu> Subject: CLUE won't compile re: May Day PCL doesn't work in Lucid 3.0. Ooops. [Well, lets make that a bit more specific so as not to scare off all other Lucid 3.0 users.] There's a "Production" compiler bug in the HP 835 version that affects the deeply nested label usages in May Day; this bug isn't present in the HP 300 series in any release number, nor is it present (to my knowledge) in any other 3.0 release. Have you tried the so-called "Development" compiler? -- JonL -- P.S. I'll also see what can be done about getting HP to distribute a patch for that nested/contorted labels compiler bug. Timing for this probably won't be super optimistic. Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA14559; Fri, 22 Jun 90 19:50:32 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 22 JUN 90 18:55:15 PDT Return-Path: Redistributed: commonloops.PA Received: from ifi.informatik.uni-stuttgart.de ([129.69.1.198]) by Xerox.COM ; 22 JUN 90 18:27:20 PDT Received: from is.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with SMTP; Fri, 22 Jun 90 13:40:39 +0200 Received: by is.informatik.uni-stuttgart.de; Fri, 22 Jun 90 13:42:14 +0200 Message-Id: <2855046572-14757493@XPL2> Sender: FORSTER@XPL2.ARPA Date: Fri, 22 Jun 90 14:29:32 NIL From: Peter Forster To: commonloops.PA@Xerox.COM Subject: PCL Install Problems I've been trying to compile the latest version of PCL with the Macintosh Allegro Common Lisp. During (pcl::compile-pcl) the following error occurs: ---------------------------- (pcl::compile-pcl) COMPILING .. LOADING.. ....... COMPILING STD-CLASS... LOADING BINARY OF STD-CLASS... ERROR: # IS NOT A VALID ARGUMENT TO CCL::%UVREF . WHILE EXECUTING: CCL::%UVREF TYPE COMMAND-/ TO CONTINUE, COMMAND-. TO ABORT. PCL> ----------------------------------- Any suggestions? I am using the "May Day PCL (REV 2)" and MACL 1.3.1 Peter Forster Uni Stuttgart Fachbereich Informatik Abteilung Intelligente Systeme Forststr. 86 BR Deutschland forster@informatik.uni-stuttgart.de Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA02189; Sat, 23 Jun 90 17:37:50 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 22 JUN 90 20:06:29 PDT Return-Path: Redistributed: commonloops.pa Received: from jessica.stanford.edu ([36.21.0.20]) by Xerox.COM ; 22 JUN 90 20:05:35 PDT Received: from LOCALHOST by jessica.stanford.edu (5.59/25-eef) id AA04958; Fri, 22 Jun 90 20:05:47 PDT Message-Id: <9006230305.AA04958@jessica.stanford.edu> To: CommonLoops.pa@Xerox.COM Subject: Error while compiling pcl version May 1 1990 Date: Fri, 22 Jun 90 20:05:46 -0700 From: buc@jessica.stanford.edu The following error occurred during the compilation of the May 1st 1990 version of pcl; Compiling FIN... Compiling /s3/A/buc/Pcl/fin.lsp. >>Error: Cannot expand the SETF form (%CCLOSURE-ENV FIN). SETF (IHS[37]) Arg 0: (SETF (%CCLOSURE-ENV FIN) ENV) Arg 1: NIL Restart options (Type :C ): :Q, 0: Lisp Top Level Type :H for a list of debugger commands. PCL -> Environment information: SparcStation 1 SunOS Release 4.0.3 IBUKI Common Lisp release 01/01 October 15, 1987 Any assistance will be greatly appreciated, thank you. Rob Richards Supercomputer & Workstation Support Staff AIR Stanford University Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA15846; Sun, 24 Jun 90 16:55:52 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 24 JUN 90 16:54:16 PDT Return-Path: Redistributed: commonloops.pa Received: from jessica.stanford.edu ([36.21.0.20]) by Xerox.COM ; 24 JUN 90 16:53:22 PDT Received: from LOCALHOST by jessica.stanford.edu (5.59/25-eef) id AA10670; Sun, 24 Jun 90 16:53:27 PDT Message-Id: <9006242353.AA10670@jessica.stanford.edu> To: CommonLoops.pa@Xerox.COM Subject: Error while compiling pcl version May 1 1990 Date: Sun, 24 Jun 90 16:53:26 -0700 From: buc@jessica.stanford.edu The following error occurred during the compilation of the May 1st 1990 version of pcl; Compiling FIN... Compiling /s3/A/buc/Pcl/fin.lsp. >>Error: Cannot expand the SETF form (%CCLOSURE-ENV FIN). SETF (IHS[37]) Arg 0: (SETF (%CCLOSURE-ENV FIN) ENV) Arg 1: NIL Restart options (Type :C ): :Q, 0: Lisp Top Level Type :H for a list of debugger commands. PCL -> Environment information: SparcStation 1 SunOS Release 4.0.3 IBUKI Common Lisp release 01/01 October 15, 1987 Any assistance will be greatly appreciated, thank you. Rob Richards Supercomputer & Workstation Support Staff AIR Stanford University Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA00976; Mon, 25 Jun 90 14:23:33 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 25 JUN 90 05:48:26 PDT Sender: "MAZIERE_TAURAN_CHRISTOPHE.CBVMANRXF"@Xerox.COM Date: 25 Jun 90 05:46:57 PDT (Monday) Subject: Re: remove me from the mailing list. From: gregor@parc.xerox.com To: commonloops.PA@Xerox.COM In-Reply-To: <900507-134304-11255@Xerox> Message-Id: <900625-054826-974@Xerox> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: Gregor J. Kiczales Subject: Re: remove me from the mailing list. To: commonloops.pa In-Reply-To: <900507-134304-11255@Xerox> Return-Path: Redistributed: commonloops.pa Received: from piglet.parc.xerox.com ([13.1.100.229]) by Xerox.COM ; 07 MAY 90 15:49:12 PDT Received: from spiff.parc.Xerox.COM by piglet.parc.xerox.com with SMTP (5.61+/IDA-1.2.8/gandalf) id AA29443; Mon, 7 May 90 15:50:02 PDT Original-Date: Mon, 7 May 90 15:49 PDT Message-Id: <19900507224914.7.GREGOR@SPIFF.parc.xerox.com> GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV Date: Mon, 7 May 90 12:54 N From: Please remove me from the Mailing List. Thank you. Before we get a whole spate of these, let me remind people that the proper way to ask to be removed from the mailing list; or to have your address changed; or to ask why you are getting 372 copies of each message (the answer to this last question is always Unix); or anything else having to do with mailing list administration is to send a message to: CommonLoops-Request@Parc.Xerox.com The many hundreds of people who read this list don't all want to know that you are leaving us; changing your address; or getting too many copies of each message. Thanks Gregor Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA23077; Wed, 27 Jun 90 19:20:55 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 27 JUN 90 14:37:52 PDT Return-Path: Redistributed: commonloops.pa Received: from soleil.cs.UMD.EDU ([128.8.128.14]) by Xerox.COM ; 27 JUN 90 14:36:58 PDT Received: from localhost by soleil.cs.UMD.EDU (5.61/UMIACS-0.9/04-05-88) id AA27328; Wed, 27 Jun 90 17:37:06 -0400 Message-Id: <9006272137.AA27328@soleil.cs.UMD.EDU> To: commonloops.pa@Xerox.COM Subject: CLOS Workshop Date: Wed, 27 Jun 90 17:37:02 -0400 From: Josh Lubell I would like more information about the upcoming CLOS workshop, but Andreas Paepke (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 AA26531; Thu, 28 Jun 90 00:18:04 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 27 JUN 90 23:50:47 PDT Return-Path: Redistributed: commonloops.pa Received: from dbl2.CES.CWRU.Edu ([129.22.16.42]) by Xerox.COM ; 27 JUN 90 23:49:26 PDT Received: by dbl2.CES.CWRU.Edu (5.61/ane.03.01.89.14) id AA00142; Thu, 28 Jun 90 02:49:37 -0400 Date: Thu, 28 Jun 90 02:49:37 -0400 From: William Tang Message-Id: <9006280649.AA00142@dbl2.CES.CWRU.Edu> To: commonloops.pa@Xerox.COM Subject: Please unsubscribe Sorry about sending this but commonloops.pa-request doesn't seem to exist. I am leaving school and will have to unsubscribe before I get another email address. -wt Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA27530; Thu, 28 Jun 90 01:49:36 -0700 Received: from Semillon.ms by ArpaGateway.ms ; 28 JUN 90 01:40:16 PDT Return-Path: Redistributed: commonloops.PA Received: from media-lab.media.mit.edu ([18.85.0.2]) by Xerox.COM ; 28 JUN 90 01:39:16 PDT Received: by media-lab.media.mit.edu (5.57/DA1.0.2) id AA20912; Thu, 28 Jun 90 04:39:33 EDT Date: Thu, 28 Jun 90 04:39:33 EDT From: Steve Strassmann Message-Id: <9006280839.AA20912@media-lab.media.mit.edu> To: commonloops.PA@Xerox.COM, hp-support@lucid.com Subject: request for binary extension In PCL, could you please add the following line to defsys.lisp, to support Lucid on HP machines? Thanks. ------------------------------------------------------------------------------ (defvar *pathname-extensions* ... #+(and Lucid PA) ("lisp" . "hbin") ...) Received: from Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA16669; Thu, 28 Jun 90 17:27:30 -0700 Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 90 16:26:52 PDT Return-Path: Redistributed: commonloops.pa Received: from turing.cs.rpi.edu ([128.213.1.1]) by Xerox.COM ; 28 JUN 90 16:21:01 PDT Date: Thu, 28 Jun 90 19:20:17 EDT From: harrisr@turing.cs.rpi.edu (Richard Harris) Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept) id AA25016; Thu, 28 Jun 90 19:20:17 EDT 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. ;>>> Date: Tue, 3 Apr 90 12:06 PDT ;>>> From: Danny Bobrow ;>>> Subject: Re: insert classes? ;>>> Cc: CommonLoops.PA@Xerox.COM ;>>> ... ;>>> (reinitialize-instance (find-class 'a) ;>>> :direct-superclasses (list (find-class 'c))) ;>>> ;>>> This will change the direct-superclasses of A without affecting the ;>>> rest of its definition (e.g. slots defined, accessors). ;In May Day PCL, this call to reinitialize-instance does indeed affect ;the rest of its definition. I just created an extra class which ;has no (direct) slots or accessors in order to avoid this problem. ;Here are the bugs I had to fix in order to make class redefinition work: ;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) ...).] ;2. Change fill-cache so that it does not assume that its argument ; is not already in the cache. This is important because invalid ; wrappers can cause the cache miss function primary-pv-cache-miss ; to be called, and the corresponding valid wrappers might already be ; in the cache. ; [added an extra argument to line-valid-p, and changed the calls to it.] ;3. Change add-pv-binding to insert code to update the wrapper variables ; after calling primary-pv-cache-miss. ; [emit-dlap and add-pv-binding were reorganized, added the function ; emit-pv-dlap.] ;*** This is not a patch file. You must edit the files ;*** cache.lisp, dlap.lisp, and vector.lisp. ;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))))) ;(defvar *local-cache-functions* ; `( ;... ;; ;; 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))) (dotimes (i (nkeys) t) (let ((wrapper (cache-ref (cache) (+ loc i)))) (when (or (null wrapper) (and wrappers (eq wrapper (if (consp wrappers) (pop wrappers) wrappers))) (invalid-wrapper-p wrapper)) (return nil)))))) ;... ; )) ;;; ;;; returns T or NIL ;;; (defun fill-cache-p (forcep field cache wrappers value) (with-local-cache-functions (cache) (let* ((primary (location-line (compute-primary-cache-location field (mask) wrappers)))) (multiple-value-bind (free emptyp) (find-free-cache-line primary field cache wrappers) (when (or forcep emptyp) (fill-line free wrappers value) t))))) ;;; ;;; Returns NIL or (values ) ;;; ;;; This is only called when it isn't possible to put the entry in the cache ;;; the easy way. That is, this function assumes that FILL-CACHE-P has been ;;; called as returned NIL. ;;; ;;; If this returns NIL, it means that it wasn't possible to find a wrapper ;;; field for which all of the entries could be put in the cache (within the ;;; limit). ;;; (defun adjust-cache (field cache wrappers value) (with-local-cache-functions (cache) (let ((ncache (get-cache (size)))) (do ((nfield field (next-wrapper-field nfield))) ((null nfield) (free-cache ncache) nil) (labels ((try-one-fill-from-line (line) (fill-cache-from-cache-p nil nfield ncache cache line)) (try-one-fill (wrappers value) (fill-cache-p nil nfield ncache wrappers value))) (if (and (dotimes (i (nlines) t) (when (and (null (line-reserved-p i)) (line-valid-p i wrappers)) (unless (try-one-fill-from-line i) (return nil)))) (try-one-fill wrappers value)) (return (values nfield ncache)) (flush-cache-internal ncache))))))) ;;; ;;; returns: (values ) ;;; (defun expand-cache (field cache wrappers value) (declare (values field cache) (ignore field)) (with-local-cache-functions (cache) (multiple-value-bind (ignore size) (compute-cache-parameters (nkeys) (valuep) (* (nlines) 2)) (let* ((ncache (get-cache size)) (nfield (wrapper-field 'number))) (labels ((do-one-fill-from-line (line) (unless (fill-cache-from-cache-p nil nfield ncache cache line) (do-one-fill (line-wrappers line) (line-value line)))) (do-one-fill (wrappers value) (multiple-value-bind (adj-field adj-cache) (adjust-cache nfield ncache wrappers value) (if adj-field (setq nfield adj-field ncache adj-cache) (fill-cache-p t nfield ncache wrappers value)))) (try-one-fill (wrappers value) (fill-cache-p nil nfield ncache wrappers value))) (dotimes (i (nlines)) (when (and (null (line-reserved-p i)) (line-valid-p i wrappers)) (do-one-fill-from-line i))) (unless (try-one-fill wrappers value) (do-one-fill wrappers value)) (values nfield ncache)))))) ;;; ;;; This is the heart of the cache filling mechanism. It implements the decisions ;;; about where entries are placed. ;;; ;;; Find a line in the cache at which a new entry can be inserted. ;;; ;;; ;;; is in fact empty? ;;; (defun find-free-cache-line (primary field cache &optional wrappers) (declare (values line empty?)) (with-local-cache-functions (cache) (let ((limit (funcall (limit-fn) (nlines))) (wrappedp nil)) (when (line-reserved-p primary) (setq primary (next-line primary))) (labels (;; ;; Try to find a free line starting at . ;; is the primary line of the entry we are finding a free ;; line for, it is used to compute the seperations. ;; (find-free (p s) (do* ((line s (next-line line)) (nsep (line-separation p s) (1+ nsep))) (()) (if (null (line-valid-p line wrappers)) ;If this line is empty or (return (values line t)) ;invalid, just use it. (let ((osep (line-separation (line-primary field line) line))) (if (and wrappedp (>= line primary)) ;; ;; have gone all the way around the cache, time to quit ;; (return (values line nil)) (when (cond ((or (= nsep limit)) t) ((= nsep osep) (zerop (random 2))) ((> nsep osep) t) (t nil)) ;; ;; Try to displace what is in this line so that we ;; can use the line. ;; (return (values line (displace line))))))) (if (= line (1- (nlines))) (setq wrappedp t)))) ;; ;; Given a line, attempt to free up that line by moving its ;; contents elsewhere. Returns nil when it wasn't possible to ;; move the contents of the line without dumping something on ;; the floor. ;; (displace (line) (if (= line (1- (nlines))) (setq wrappedp t)) (multiple-value-bind (dline dempty?) (find-free (line-primary field line) (next-line line)) (when dempty? (copy-line line dline) t)))) (find-free primary primary))))) ;dlap.lisp (defun dlap-wrappers (metatypes) (mapcar #'(lambda (x) (and (neq x 't) (allocate-register 'vector))) metatypes)) (defun dlap-wrapper-moves (wrappers args metatypes miss-label slot-regs) (gathering1 (collecting) (iterate ((mt (list-elements metatypes)) (arg (list-elements args)) (wrapper (list-elements wrappers)) (i (interval :from 0))) (when wrapper (gather1 (emit-fetch-wrapper mt arg wrapper miss-label (nth i slot-regs))))))) (defun emit-dlap (args metatypes miss-label hit miss value-reg &optional slot-regs) (let* ((wrappers (dlap-wrappers metatypes)) (nwrappers (remove nil wrappers)) (wrapper-moves (dlap-wrapper-moves wrappers args metatypes miss-label slot-regs))) (prog1 (emit-dlap-internal nwrappers wrapper-moves hit miss miss-label value-reg) (mapc #'deallocate-register nwrappers)))) ;vector.lisp (defun add-pv-binding (method-body plist required-parameters) (let* ((isl (getf plist :isl)) (isl-cache-symbol (make-symbol "isl-cache"))) (nconc plist (list :isl-cache-symbol isl-cache-symbol)) (with-gathering ((slot-variables (collecting)) (metatypes (collecting))) (iterate ((slots (list-elements isl)) (i (interval :from 0))) (cond (slots (gather (slot-vector-symbol i) slot-variables) (gather 'standard-instance metatypes)) (t (gather nil slot-variables) (gather t metatypes)))) `((let ((.ISL. (locally (declare (special ,isl-cache-symbol)) ,isl-cache-symbol)) (.PV. *empty-vector*) ,@(remove nil slot-variables)) (declare ,(make-isl-type-declaration '.ISL.) ,(make-pv-type-declaration '.PV.)) (let* ((cache (%isl-cache .ISL.)) (size (%isl-size .ISL.)) (mask (%isl-mask .ISL.)) (field (%isl-field .ISL.))) ,(generating-lap-in-lisp '(cache size mask field) required-parameters (flatten-lap (emit-pv-dlap required-parameters metatypes slot-variables)))) ,@method-body))))) (defun emit-pv-dlap (required-parameters metatypes slot-variables) (let* ((slot-regs (mapcar #'(lambda (sv) (and sv (operand :lisp-variable sv))) slot-variables)) (wrappers (dlap-wrappers metatypes)) (nwrappers (remove nil wrappers))) (flet ((wrapper-moves (miss-label) (dlap-wrapper-moves wrappers required-parameters metatypes miss-label slot-regs))) (prog1 (emit-dlap-internal nwrappers ;wrapper-regs (wrapper-moves 'pv-miss) ;wrapper-moves (opcode :exit-lap-in-lisp) ;hit (flatten-lap ;miss (opcode :label 'pv-miss) (opcode :move (operand :lisp `(primary-pv-cache-miss .ISL. ,@required-parameters)) (operand :lisp-variable '.PV.)) (apply #'flatten-lap (wrapper-moves 'pv-wrapper-miss)) ; -- Maybe the wrappers have changed. (opcode :label 'pv-wrapper-miss) (opcode :exit-lap-in-lisp)) 'pv-miss ;miss-label (operand :lisp-variable '.PV.)) ;value-reg (mapc #'deallocate-register nwrappers))))) ------- Richard Harris