From excl-forum-distribution-owner Fri Jan 1 18:41:11 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150182>; Fri, 1 Jan 1993 18:41:04 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20365; Fri, 1 Jan 93 15:19:53 PST Received: from news.funet.fi by ucbvax.Berkeley.EDU (5.63/1.43) id AA25651; Fri, 1 Jan 93 15:26:39 -0800 Received: by news.funet.fi; Sat, 2 Jan 93 01:29:25 +0200 Received: from USENET by funet.fi with netnews for allegro-cl@ucbvax.berkeley.edu (allegro-cl@ucbvax.berkeley.edu) (contact news-gw@funet.fi if you have questions) Date: Fri, 1 Jan 1993 16:33:15 -0500 From: bbs.maddox@gilligan.tsoft.net (Otto Maddox) Organization: The TSoft BBS and Public Access Unix, +1 415 969 8238 Subject: TESTING TESTING Message-Id: <5DwPwB6w165w@tsoft.net> Sender: ngw@news.funet.fi To: allegro-cl@ucbvax.berkeley.edu * TEST * [] Charles Durand [] +1 415 969 1634 Internet: bbs.maddox@tsoft.net From excl-forum-distribution-owner Sun Jan 3 16:07:15 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150195>; Sun, 3 Jan 1993 16:07:10 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA22295; Sun, 3 Jan 93 12:37:29 PST Received: from centralsparc.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA13400; Sun, 3 Jan 93 12:44:21 -0800 Received: by centralsparc.Berkeley.EDU (4.1/1.42) id AA22294; Sun, 3 Jan 93 12:37:25 PST Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA08129; Wed, 16 Dec 92 03:15:42 PST Received: from [133.5.32.101] by ucbvax.Berkeley.EDU (5.63/1.43) id AA03138; Wed, 16 Dec 92 03:22:43 -0800 Received: by iris.is.kyushu-u.ac.jp (4.1/2.7W-NIS-DNS) id AA25617; Wed, 16 Dec 92 20:26:34 JST Date: Wed, 16 Dec 1992 06:26:34 -0500 From: Jung ki tae Return-Path: Message-Id: <9212161126.AA25617@iris.is.kyushu-u.ac.jp> To: Allegro-CL@ucbvax.berkeley.edu Subject: Multi-Loop parallel is possible? How do you do? I am Jung, a student of Kyusyu Uni. in Japan. I am writing a Natural language processing program using Allegro CLiP Release 3.0.3 march 1990, on Sequent S2000 (using 20 processors) I refer to the manual of Allegro CLiP, but I have a basic(?) program. I want to write multi-loop parallel,but I can't understand only the manual. At first,I produce a number of processes, each process has many cases and I want to make processes as the number of cases. And I would like to start it parallelly. In the manual, the forker game is also parallel program, we just decide how many times we want to start the processes before it starts.(fig.1) When We can't predict how many times before it (outer loop & inner loop) starts, It can be done HOW? Of cource, when we know how many times start of the outer loop, we can not predict inner loop's before the outer loop is ended.(fig.2) If is there any possible way, please answer it "HOW" or "No", as soon as possible. | | ------------------ ---------- -------- -------- ;;parallel part | | | | | | | | | | ;;parallel part | | | | | | | /|\ /\ /|\ /|\ /|\ /|\ /|\ ;;parallel part (fig.1) .... .. ... ... ... ..... ... ;;parallel part (fig.2) for example,(fig.2);;;;wrong example (defun AAA () (...............................) (...............................) (...............................);;; these parts is different than "next-net" (multiple-value-bind (point word-list)(ret-dict point ...) (mapcar #'(lambda (word) (multiple-value-bind (.. hin-list)(return-info word) (make-lwp (progn ( ....... ) ( ....... ) (mapcar #'(lambda (hin) (make-lwp (progn (....) (next-net hin) ))) hin-list ) (start-lwps);;;; need or not ?? )))) word-list ) (start-lwps) )) (defun next-net (hin) (let (( ....) ( ....) ) ( ...... ) (multiple-value-bind (point word-list)(ret-dict point ...) (mapcar #'(lambda (word) (multiple-value-bind (.. hin-list)(return-info word) (make-lwp (progn ( ....... ) ( ....... ) (mapcar #'(lambda (hin) (make-lwp (progn (case ... (next-net hin) .... (next2-net hin) .... (next3-net hin) )))) hin-list ) (start-lwps);;; need or not ?? )))) word-list ) (start-lwps) ))) (defun ret-dict (point ...) (.......)) (defun return-info (word) (.......)) ---------------------------------------------------------------------------- jung@ninshiki.is.kyushu-u.ac.jp From excl-forum-distribution-owner Tue Jan 5 14:27:41 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150195>; Tue, 5 Jan 1993 14:27:30 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA23996; Tue, 5 Jan 93 11:11:24 PST Received: from cbis.ece.drexel.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA25700; Tue, 5 Jan 93 11:18:21 -0800 Received: from ipcsg1.ece.drexel.edu by cbis.ECE.Drexel.EDU (5.67/1.34) id AA07948; Tue, 5 Jan 93 14:18:21 EST Received: by ipcsg1.ece.drexel.edu (911016.SGI/1.34) id AA05378; Tue, 5 Jan 93 10:40:31 -0500 From: sanjay@ipcsg1.ece.drexel.edu (Sanjay Bhasin) Message-Id: <9301051540.AA05378@ipcsg1.ece.drexel.edu> Subject: no subject (file transmission) To: allegro-cl@ucbvax.berkeley.edu (Discussion group for Common Lisp) Date: Tue, 5 Jan 1993 10:40:31 -0500 X-Mailer: ELM [version 2.3 PL11] Hi, I am in the process of developing a system to perform segmentation using an Expert System. I was wondering if you knew of shells available for the SGI that were inexpensive or public domain and would run under your product. From excl-forum-distribution-owner Wed Jan 6 18:23:57 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150205>; Wed, 6 Jan 1993 18:23:51 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26049; Wed, 6 Jan 93 15:00:08 PST Received: from drums.reasoning.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA19151; Wed, 6 Jan 93 15:07:10 -0800 Received: from windchime.reasoning.com by drums.reasoning.com with SMTP (5.61/25-eef) id AA16102; Wed, 6 Jan 93 23:07:40 GMT for allegro-cl@berkeley.edu Date: Wed, 6 Jan 1993 18:07:40 -0500 From: William Brew Message-Id: <9301062307.AA16102@drums.reasoning.com> Received: by windchime.reasoning.com.res_no_yp (4.1/SMI-4.1) id AA18079; Wed, 6 Jan 93 15:07:36 PST To: allegro-cl@ucbvax.berkeley.edu Subject: foreign loading C++ code Reply-To: bill@reasoning.com Allegro currently is set up for foreign loading of C or Fortran. I would like to foreign load C++ code. Some questions: 1. Has anybody done this? If so, what problems occured? Was the effort successful? 2. Does Franz plan to suport foreign loading of C++? If so, when? 3. One problem that I can think of is static initialization and destruction. The Cfront C++ compiler handles static initialization by generating a function with a name like _sti_xxxx for each file that is compiled. Ordinarily, the C++ linker arranges for the static init functions that are in a particular executable to be called at startup. Obviously when foreign loading into lisp this does not happen. It is easy enough to call the static initialization functions from lisp. The problem is knowing what their names are. I have been working around the problem by building a dummy executable and then doing something like nm dummy | grep _sti_ to find the names. This technique is rather clumsy. One step towards a solution would be a lisp function that lets me map through the entry points in a lisp so as to find the ones that correspond to static initializers. Any suggestions on how to do this? -bill- William Brew Reasoning Systems Inc. From excl-forum-distribution-owner Mon Jan 25 04:59:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150184>; Mon, 25 Jan 1993 04:59:16 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11282; Mon, 25 Jan 93 01:31:10 PST Received: from relay2.UU.NET by ucbvax.Berkeley.EDU (5.63/1.43) id AA09398; Mon, 25 Jan 93 01:38:12 -0800 Received: from uni-sb.de by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27210; Mon, 25 Jan 93 04:38:43 -0500 Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930116) id AA18279; Mon, 25 Jan 93 10:38:42 +0100 Received: from disco-sol.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA21502; Mon, 25 Jan 93 10:40:15 +0100 Date: Mon, 25 Jan 1993 04:42:31 -0500 Message-Id: <9301250942.AA17994@disco-sol.dfki.uni-sb.de> Received: by disco-sol.dfki.uni-sb.de; Mon, 25 Jan 93 10:42:31 +0100 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: neis@dfki.uni-sb.de (Ingo Neis) To: Allegro-CL@ucbvax.berkeley.edu Subject: Please Add Me To The Mail List Reply-To: neis@dfki.uni-sb.de Hello! I've a little problem with the multiprocessing-code: I'm working on a Sparkstation/Unix X11 environment and I shall write a graphical interface for our parser. The main problem I have, is to choose a window toolkit that allows me to: - write text into it - draw lines - resize it (but without polling the window the whole time) - have scroll bars If anybody knows about a free toolkit, please write me back. Actually I work with a toolkit, developed at our institute, but the only way I can catch a window resize is to check the size the whole time. I intend to write a small function and let it with mp:process-wait wait until a button is pressed, but i've never seen an example program, that uses mp:process-wait. Please, could someone post me an example? Thank You! Ingo L. Neis From excl-forum-distribution-owner Mon Jan 25 09:02:12 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150184>; Mon, 25 Jan 1993 09:02:08 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11362; Mon, 25 Jan 93 05:41:35 PST Received: from pride.uchicago.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA11013; Mon, 25 Jan 93 05:48:38 -0800 From: berger@cs.uchicago.edu Return-Path: Received: by pride.uchicago.edu (4.1/UofC4.3x) id AA03137; Mon, 25 Jan 93 07:49:18 CST Date: Mon, 25 Jan 1993 08:49:18 -0500 Message-Id: <9301251349.AA03137@pride.uchicago.edu> To: neis@dfki.uni-sb.de, Allegro-CL@ucbvax.berkeley.edu In-Reply-To: Ingo Neis's message of Mon, 25 Jan 93 10:42:31 +0100 <9301250942.AA17994@disco-sol.dfki.uni-sb.de> Subject: Please Add Me To The Mail List Ingo, The best free (or commercial) toolkit around for Common Lisp users is GARNET from CMU. It provides everything you asked for and lots of built-in gadgets and widgets. You can get more info about it from garnet@cs.cmu.edu. Write them and they will tell you how to obtain GARNET by anonymous ftp. Here's a brief excerpt from the abstract (typos are mine): "The Garnet User Interface Development Environment contains a comprehensive set of tools that make it significantly easier to design and implement highly interactive, graphical direct manipulation user interfaces. Garnet provides a high level of support, while still being Look-and-Feel independent and providing the applications with tremendous flexibility." I found Garnet to be well-documented and supported. If you want to avoid reinventing a probably much inferior wheel, drop them a line. -Jeff Berger P.S. My only connection with Garnet is as a satisfied user. Jeff Berger |USmail: Ryerson 256 berger@cs.uchicago.edu | Artificial Intelligence Lab PH: (312) 702-8584 | 1100 East 58th Street FX: (312) 702-8487 | Chicago, IL 60637 From excl-forum-distribution-owner Tue Jan 26 02:24:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150184>; Tue, 26 Jan 1993 02:24:19 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11926; Mon, 25 Jan 93 23:01:35 PST Received: from HAIFA.MT.CS.CMU.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA07686; Mon, 25 Jan 93 23:08:35 -0800 Received: from haifa.mt.cs.cmu.edu by HAIFA.MT.CS.CMU.EDU id aa05685; 26 Jan 93 2:08:29 EST To: neis@dfki.uni-sb.de Reply-To: toad@cs.cmu.edu Cc: Allegro-CL@ucbvax.berkeley.edu Subject: Using mp:process-wait to service X In-Reply-To: Your message of Mon, 25 Jan 93 10:42:31 +0100. <9301250942.AA17994@disco-sol.dfki.uni-sb.de> Date: Tue, 26 Jan 1993 02:08:15 -0500 Message-Id: <5683.728032095@HAIFA.MT.CS.CMU.EDU> From: Todd_Kaufmann@haifa.mt.cs.cmu.edu Running a separate process to handle X11 input events is the only acceptable way to do it without freezing up your lisp (no user input) or spinning away cycles polling the server. Here is a simplified version of what I have used for a few years. It is trivially ported to Lucid CL (strictly a mechanical transform). For CMU CL, see system:serve-event and *display-event-handlers. *Most* uses of MP for display and/or input/output functions can be ported to CMU CL using this functionality (I ported CLM to CMUCL in this manner). Most other functionality can be had with alarm signals & handlers, and closures, though it can get rather messy. Hopefully threads will come soon. Here is a brief summary of the functions here: xapp -- starts up xapp-server function in a separate process, restarting and/or killing existing process. xapp-server -- the function that waits for X events, and then calls default-event-handler on them default-event-handler -- dispatch according to the event type. notice these other functions (exposure, buttonpress, etc) are not defined here. This skeleton should be suitable for simple applications. (I believe a copy was once in garnet.) Things to watch out for: - multiple processes drawing in a window can cause locking problems. I suggest you do your own scheduling if necessary - debugging MP's can be tricky and confusing. You probably want to add some error handling and/or catching in xapp-server - you should be familiar with xlib:event-case, and understand the comment ";; every clause should return T, not NIL!" (experts may ignore) Free code, enjoy. Disclaimer: this code has worked for over 3 years in allegro, in versions 3.x and 4.0, probably 4.1. It assumes CLX is loaded, and the obvious specials (eg, *display*) are set and functional. Derived and simplified from working code; only the names have been changed to protect the innocent. Some settling may have occurred during posting. Void where prohibited. Compile for best results. Not responsible for generated garbage or your failings. I don't have time to look at it, but bribery works. Todd Kaufmann Center for Machine Translation Carnegie Mellon University +1 412 268 7130 fax: +1 412 268 6298 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Culled from other code by Todd Kaufmann on or about 26-Jan-93, 02:04. ;;; ;;; Assumes CLX loaded & running, *display* is valid. ;;; You must define event-handling functions. ;;; (defvar *xapp-proc-name* "Xapp-window") #+excl (require :process) #+excl (defun xapp (&key restart) (let ((proc (find *xapp-proc-name* mp:*all-processes* :key #'mp:process-name :test #'string=))) (cond ((and restart proc) (format *debug-io* "~&Killing old process..") (mp:process-kill proc) (format *debug-io* ". done.~%")) (restart (format *debug-io* "~&Process ~s wasn't running. Creating...")) (proc (format *debug-io* "~&Restarting existing ~s." *xapp-proc-name*) (return-from xapp (mp:process-reset proc))) (t (format *debug-io* "Starting up process to serve the window.")) ) (mp:process-run-function *xapp-proc-name* #'xapp-server *display* )) ) (defun xapp-server (display) (loop (when (xlib:event-listen display 20) (default-event-handler display))) ) (defvar *event-debug* nil "When non-nil, produces debugging info from default-event-handler.") (defun default-event-handler (display) "Event handler for the fg-windows" ;; every clause should return T, not NIL! (when *event-debug* (format t "In default-event-handler~%")) (if (xlib:display-p display) (xlib:event-case (display :discard-p t :force-output-p t) (:EXPOSURE (event-window count) (Exposure *event-debug* event-window count display)) (:ENTER-NOTIFY (event-window) (Enter-Notify *event-debug* event-window)) (:NO-EXPOSURE () t) (:Button-Press (event-window x y code) (ButtonPress *event-debug* event-window x y code)) (:Button-Release (event-window x y) (ButtonRelease *event-debug* event-window x y)) (:Motion-notify () (when *event-debug* (format t "Motion Notify in default-event-handler~%")) t ) (:key-press (event-window state code x y) (call-window-key-function display event-window state code x y) t) (OTHERWISE (event-key) (when *event-debug* (format t "Illegal event: ~S~%" event-key)) t)) ; else (when *EVENT-DEBUG* (format t "Bad Display value: ~A~%" display))) (when *event-debug* (format t "Exiting default-event-handler~%") (force-output)) ) From excl-forum-distribution-owner Tue Jan 26 21:29:54 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Tue, 26 Jan 1993 21:29:47 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA12975; Tue, 26 Jan 93 18:06:23 PST Received: from hadar.cs.Buffalo.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA20671; Tue, 26 Jan 93 18:13:22 -0800 Received: by hadar.cs.Buffalo.EDU (4.1/1.01) id AA09481; Tue, 26 Jan 93 21:14:44 EST Date: Tue, 26 Jan 1993 21:14:44 -0500 From: hans@cs.buffalo.edu (Hans Chalupsky) Message-Id: <9301270214.AA09481@hadar.cs.Buffalo.EDU> To: allegro-cl@ucbvax.berkeley.edu Subject: How to change the package in an inspector window of Composer Hi, I was wondering whether there is a straightforward way of changing the package used in the presentation of the symbols in an inspector window, for example, if I am in the user package and do :wi l only to find out that all of l's elements are in some other-package and hence are displayed with their package prefixes which I don't want to see. The only way I could make this work was to look at the value of cw:*all-window-streams* find the window object that corresponds to the inspector window in question (say it is the first), and then do something like (setf (wt::inspector-window-package (first cw:*all-window-streams*)) (find-package 'other-package)) Now, after clicking on REFETCH on my inspector window the package change will take effect and symbols will be displayed according to the new package value. Achieving this by starting up a new inspector in a different package is only a viable option if one is pretty much at the top level, but not if one has finally found the important objects at the end of a long inspection/subinspection chain. Any hints much appreciated, I couldn't find anything related to this in the Composer manual. Hans hans@cs.buffalo.edu Hans Chalupsky, Dept. of CS, 226 Bell Hall, SUNY@Buffalo, NY 14260. From excl-forum-distribution-owner Wed Jan 27 13:46:38 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150202>; Wed, 27 Jan 1993 13:46:35 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA13824; Wed, 27 Jan 93 10:18:27 PST Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA22222; Wed, 27 Jan 93 10:25:27 -0800 Received: by atc.boeing.com (5.57) id AA12789; Wed, 27 Jan 93 10:29:21 -0800 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Wed, 27 Jan 93 10:27 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA06161; Wed, 27 Jan 93 10:26:16 PST Received: by fritz.ata (4.1/SMI-4.1) id AA03490; Wed, 27 Jan 93 10:25:59 PST Date: Wed, 27 Jan 1993 13:26:16 -0500 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: Detecting class definitions To: allegro-cl@ucbvax.berkeley.edu Message-Id: <9301271826.AA06161@gumby.ata> Hi: X-Envelope-To: allegro-cl@berkeley.edu I would like to detect when a new class is defined or redefined. That is, when a new class is defined/redefined with defclass. I would also like to do this for generic function objects. Is there something I can specialize in the MOP that will allow me to do this? Thanks ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com Seattle, Wa. From excl-forum-distribution-owner Thu Feb 4 06:59:58 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150214>; Thu, 4 Feb 1993 06:59:48 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA21969; Thu, 4 Feb 93 03:37:32 PST Received: from news.funet.fi by ucbvax.Berkeley.EDU (5.63/1.43) id AA21626; Thu, 4 Feb 93 03:45:18 -0800 Received: by news.funet.fi; Thu, 4 Feb 1993 13:47:29 +0200 Received: from USENET by funet.fi with netnews for allegro-cl@ucbvax.berkeley.edu (allegro-cl@ucbvax.berkeley.edu) (contact news-gw@funet.fi if you have questions) Date: Thu, 4 Feb 1993 08:37:29 -0500 From: ks@cs.tut.fi (Syst{ Kari) Organization: Tampere Univ. of Technology, Finland. Subject: How to get rid of extra warnings ? Message-Id: Sender: ngw@news.funet.fi To: allegro-cl@ucbvax.berkeley.edu My application creates lisp-code which is then loaded and compiled. The machine generated code has quite often variables that are never used. As a result I get several screenfulls of warnings: ; While compiling (:anonymous-lambda 246): Warning: variable CO is never used Warning: variable MA is never used Does anybody know how to get rid of these annoying messages ? -- % This article represents my personal views. % Kari Systa, Tampere Univ. Technology, Box 553, 33101 Tampere, Finland % work: +358 31 162585 fax: +358 31 162913 home: +358 31 177412 % Internet: ks@cs.tut.fi X.400: C=fi ADMD=fumail O=TUT OU=CS S=ks From excl-forum-distribution-owner Thu Feb 4 07:14:23 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150214>; Thu, 4 Feb 1993 07:14:15 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA21983; Thu, 4 Feb 93 03:57:04 PST Received: from liasun6.epfl.ch by ucbvax.Berkeley.EDU (5.63/1.43) id AA22574; Thu, 4 Feb 93 04:04:50 -0800 Received: by liasun6.epfl.ch (Smail3.1.28.1 #3) id m0nK5Jq-0008R6C; Thu, 4 Feb 93 13:04 MET Message-Id: Date: Thu, 4 Feb 1993 07:04:00 -0500 From: simon@lia.di.epfl.ch (Simon Leinen) To: ks@cs.tut.fi (Syst{ Kari) Cc: allegro-cl@ucbvax.berkeley.edu Subject: How to get rid of extra warnings ? In-Reply-To: References: > The machine generated code has quite often variables that are never > used. As a result I get several screenfulls of warnings: > > ; While compiling (:anonymous-lambda 246): > Warning: variable CO is never used > Warning: variable MA is never used > > > Does anybody know how to get rid of these annoying messages ? Yes. If your code generator can easily determine which variables are used and which aren't, you can add IGNORED declarations for the unused variables. (let ((foo ...) (bar ...)) (declare (ignore bar)) ;; generated code that uses FOO, but not BAR ...) If this is somehow difficult, use the IGNORABLE declaration on all potentially unused variables: (let ((foo ...) (bar ...)) (declare (ignorable foo bar)) ;; generated code that may or may not use FOO and BAR ...) -- Simon. From excl-forum-distribution-owner Mon Feb 8 15:05:06 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Mon, 8 Feb 1993 15:05:00 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26095; Mon, 8 Feb 93 11:21:23 PST Received: from NL.CS.CMU.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA14307; Mon, 8 Feb 93 11:29:12 -0800 Date: Mon, 8 Feb 1993 13:27:00 -0500 From: Peter Shell To: allegro-cl@ucbvax.berkeley.edu Subject: subscription request Message-Id: Sender: pshell@nl.cs.cmu.edu Please add me to your mailing list. --Pete Shell (pshell@cmu.edu) From excl-forum-distribution-owner Mon Feb 8 16:23:13 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Mon, 8 Feb 1993 16:23:10 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26228; Mon, 8 Feb 93 12:53:34 PST Received: from NL.CS.CMU.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA18236; Mon, 8 Feb 93 13:01:21 -0800 Date: Mon, 8 Feb 1993 15:59:24 -0500 From: Peter Shell To: allegro-cl@ucbvax.berkeley.edu Subject: Please add me to your mailing list. Message-Id: Sender: pshell@nl.cs.cmu.edu Please add me to your mailing list for Allegro. --Pete Shell (pshell@cmu.edu) From excl-forum-distribution-owner Mon Feb 8 21:08:15 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Mon, 8 Feb 1993 21:08:10 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26433; Mon, 8 Feb 93 17:38:17 PST Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA00303; Mon, 8 Feb 93 17:46:07 -0800 Received: by atc.boeing.com (5.57) id AA09253; Mon, 8 Feb 93 17:49:22 -0800 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Mon, 8 Feb 93 17:48 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA07931; Mon, 8 Feb 93 17:45:59 PST Received: by fritz.ata (4.1/SMI-4.1) id AA11074; Mon, 8 Feb 93 17:45:50 PST Date: Mon, 8 Feb 1993 20:45:59 -0500 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: Macrolet To: allegro-cl@ucbvax.berkeley.edu Message-Id: <9302090145.AA07931@gumby.ata> Hi: X-Envelope-To: allegro-cl@berkeley.edu I am trying to use MACROLET to hide the global definition of a macro name with my own version. I want to define a function that accepts a form to be evaluated in the lexical environment of the MACROLET. I know that I must have to deal with the environment argument to macroexpand-1 but can't seem to grok it. The following never seems to expand the form correctly. (defun foo (form) (macrolet ((my-macro (&rest x) `(funcall #'+ ,@x))) (format t "~&Form: ~a~%Expansion: ~a~&" form (macroexpand-1 form)) (eval (macroexpand-1 form)) )) => (foo '(my-macro 1 2 3)) This should return 6 but the eval causes an undefined function error since the expansion is never really done. So, how do I get macroexpand-1 to recognize the lexical environment that the my-macro macro is defined in? From excl-forum-distribution-owner Tue Feb 9 05:33:00 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Tue, 9 Feb 1993 05:32:51 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA27095; Tue, 9 Feb 93 01:28:36 PST Received: from relay2.UU.NET by ucbvax.Berkeley.EDU (5.63/1.43) id AA21350; Tue, 9 Feb 93 01:36:24 -0800 Received: from uni-sb.de by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19825; Tue, 9 Feb 93 04:34:41 -0500 Organization: Universitaet des Saarlandes D-W-6600 Saarbruecken, Germany Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930116) id AA01477; Tue, 9 Feb 93 10:34:14 +0100 Received: from disco-sol.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA11978; Tue, 9 Feb 93 10:35:58 +0100 From: "Abdel Kader Diagne" Message-Id: <9302090938.AA22985@disco-sol.dfki.uni-sb.de> Received: by disco-sol.dfki.uni-sb.de; Tue, 9 Feb 93 10:38:20 +0100 To: allegro-cl@ucbvax.berkeley.edu Subject: Defining a Macro Date: Tue, 9 Feb 1993 04:38:20 -0500 I am trying to define a macro to construct expressions like '(fcn-1 [arg1-val [arg2-val]]) where arg1-val and arg2-val are (the values of) the arguments of the macro. I think, the usual way to do it is defining a macro like (defmacro BUILD-MY-EXPRESSION (arg1 arg2) `'(fcn-1 [,arg1 [,arg2]])) But that doesn't work: the evaluation of the form (BUILD-MY-EXPRESSION 'test1 'test2) returns (FCN-1 [,ARG1 [,ARG2]]) instead of (FCN-1 [TEST1 [TEST2]]). I suppose it is due to the fact that #\[ is a macro-character associated to a specific function. If so, is there a way to use it locally as a usual char? Reformulation of the problem: I would like to define a macro that returns the same expression as the function defined below: (defun BUILD-MY-EXPRESSION (arg1 arg2) (let ((my-expr (format nil "(fcn-1 [~a [~a]])"arg1 arg2))) my-expr)) Any clue ? I'll be grateful on any help. Thanks in advance. --akd. From excl-forum-distribution-owner Wed Feb 10 10:24:19 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150183>; Wed, 10 Feb 1993 10:24:11 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA28324; Wed, 10 Feb 93 06:44:36 PST Received: from sparky.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA20676; Wed, 10 Feb 93 06:52:24 -0800 Return-Path: Received: by sparky.Franz.COM (4.1/FI-2.0) id AA16014; Wed, 10 Feb 93 06:50:53 PST From: smh@franz.com (Steve Haflich) Message-Id: <9302101450.AA16014@sparky.Franz.COM> To: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Cc: allegro-cl@ucbvax.berkeley.edu Subject: Re: Macrolet In-Reply-To: Your message of Mon, 08 Feb 93 17:45:59 -0800. <9302090145.AA07931@gumby.ata> Date: Wed, 10 Feb 1993 09:50:52 -0500 > From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> > > I am trying to use MACROLET to hide the global definition of a macro > name with my own version. I want to define a function that accepts a > form to be evaluated in the lexical environment of the MACROLET. > > I know that I must have to deal with the environment argument to > macroexpand-1 but can't seem to grok it. The following never seems to > expand the form correctly. > > (defun foo (form) > (macrolet ((my-macro (&rest x) > `(funcall #'+ ,@x))) > (format t "~&Form: ~a~%Expansion: ~a~&" form (macroexpand-1 form)) > (eval (macroexpand-1 form)) > )) > > => (foo '(my-macro 1 2 3)) > > This should return 6 but the eval causes an undefined function error > since the expansion is never really done. > > So, how do I get macroexpand-1 to recognize the lexical environment > that the my-macro macro is defined in? There is a misconception here about how and when lexical analysis (which includes macroexpansion) gets done. Conceptually, macroexpansion and the accompanying analysis of forms within lexical environments are done when forms are promoted into functions. There is some latitude when this happens, but the language standard requires that it happen no later than when a function is COMPILEd or COMPILE-FILEd, and allows it to happen immediately when the FUNCTION special form is processed by EVAL. (One important time when this happens is when the intepreter executes a DEFUN.) Indeed this is typically done in "compiler-only" implementations. The important point is that once a form has been lexically analyzed and converted into functionhood (or "promoted" or "closed over", depending on the literature) the lexical environment is discarded. The task of lexical analysis is precisely to process and eliminate MACROLET, SYMBOL-MACROLET, DECLARE, and other lexical constructs. Conceptualy, lexical analysis happens "all at once" whenever forms are promoted into functions. The body of forms that are analyzed together are: a single top-level form in a file being compiled; a lambda expression that is the second argument to COMPILE or the first argument in a COERCE to type FUNCTION; and the argument for to EVAL. The language is defined this way because if it were not true that lexical analysis happens all at once, effective compilation of the lexical language would be impossible. Once a lexical body of forms has been analyzed into code, it is in general impossible to inject any new forms into that body. Your function is trying to preserve the lexical construct that exists at the time of its definition and use them at the time of its execution. There are hideous kludges to do what you're trying to do in an implementation that has a real interpreter, provided you're willing not to compile FOO, but they will fail in other compiler-only implementations. Probably a clearer way to implement what you're trying to do is something like this: <1> (defun foo (form) (eval `(macrolet ((my-macro (&rest x) `(funcall #'+ ,@x))) ,form))) foo <2> (foo '(my-macro 1 2 3)) 6 This will work portably both interpreted and compiled. The idea is that both the MACROLET and its expansion occur in the same lexical body of code (the argument to EVAL) and so undergo lexical processing together. From excl-forum-distribution-owner Thu Feb 11 20:18:58 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150205>; Thu, 11 Feb 1993 20:18:56 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00357; Thu, 11 Feb 93 16:46:08 PST Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA04201; Thu, 11 Feb 93 16:53:55 -0800 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA29600; Thu, 11 Feb 93 16:53:58 PST Date: Thu, 11 Feb 1993 19:53:58 -0500 From: smh@franz.com (Steve Haflich) Message-Id: <9302120053.AA29600@akbar.Franz.COM> To: diagne@dfki.uni-sb.de Class: bh Bh-Id: spr7631 Bh: append spr7631 customer Subject: Re: [spr7631] Defining a Macro Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu [This matter has been assigned the tracking identifier "spr7631". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] From: "Abdel Kader Diagne" To: allegro-cl@ucbvax.berkeley.edu Date: Tue, 09 Feb 93 10:38:20 +0100 I am trying to define a macro to construct expressions like '(fcn-1 [arg1-val [arg2-val]]) where arg1-val and arg2-val are (the values of) the arguments of the macro. I think, the usual way to do it is defining a macro like (defmacro BUILD-MY-EXPRESSION (arg1 arg2) `'(fcn-1 [,arg1 [,arg2]])) But that doesn't work: the evaluation of the form (BUILD-MY-EXPRESSION 'test1 'test2) returns (FCN-1 [,ARG1 [,ARG2]]) instead of (FCN-1 [TEST1 [TEST2]]). I suppose it is due to the fact that #\[ is a macro-character associated to a specific function. If so, is there a way to use it locally as a usual char? Reformulation of the problem: I would like to define a macro that returns the same expression as the function defined below: (defun BUILD-MY-EXPRESSION (arg1 arg2) (let ((my-expr (format nil "(fcn-1 [~a [~a]])"arg1 arg2))) my-expr)) Any clue ? It's not really clear from your message what you want your macro to do. The "square bracket" characters `[' and `]' do not have any special meaning in Common Lisp reader syntax -- they are just like alphabetic characters such as `A' and `Z'. Since the brackets don't mean anything, it's not clear what you mean by expressions like '(fcn-1 [arg1-val [arg2-val]]) Your later example (format nil "(fcn-1 [~a [~a]])"arg1 arg2) suggests that you intend the macro to construct a string, but this otherwise seems unlikely. Part of the confusion here may be between lisp expressions which are trees of conses and the representation of lisp expressions as characters (e.g. in a file) that are input and output by the lisp reader and printer. These are very different things, of course, like the difference between a horse and a picture of a horse. When one reads something like this in a lisp manual (fcn arg1 [arg2]) it means that fcn can be called with either one or two arguments. But any _particular_ form that is a call to fcn will be represented as a 2- or 3-element list. The metasyntax using square brackets to represent an optional syntactic component never actually appears in a program. The purpose of a lisp macro is to substitute one executable lisp subform for another. All three of the following are potentially valid lisp forms: (fcn-1) which is a list of length 1, probably representing a zero-argument call to the function fcn-1; (fcn-1 'test1 'test2) which is a list of length 3, probably representing a two-argument call to the function fcn-1; "(fcn-1 ['test1 [test2]])" which is a string of length 24 and which evaluates to itself (i.e. the same sting) when evaluated. Which kind of thing is it that you want your macro to substitute into your code? From excl-forum-distribution-owner Fri Feb 12 05:47:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150185>; Fri, 12 Feb 1993 05:47:27 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00957; Fri, 12 Feb 93 01:48:31 PST Received: from relay2.UU.NET by ucbvax.Berkeley.EDU (5.63/1.43) id AA29169; Fri, 12 Feb 93 01:56:15 -0800 Received: from uni-sb.de by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18761; Fri, 12 Feb 93 04:52:13 -0500 Organization: Universitaet des Saarlandes D-W-6600 Saarbruecken, Germany Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930116) id AA08810; Fri, 12 Feb 93 10:51:50 +0100 Received: from disco-sol.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA01202; Fri, 12 Feb 93 10:53:37 +0100 From: "Abdel Kader Diagne" Message-Id: <9302120956.AA14172@disco-sol.dfki.uni-sb.de> Received: by disco-sol.dfki.uni-sb.de; Fri, 12 Feb 93 10:56:01 +0100 To: smh@franz.com (Steve Haflich) Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr7631] Defining a Macro In-Reply-To: Your message of "Thu, 11 Feb 93 16:53:58 PST." <9302120053.AA29600@akbar.Franz.COM> Date: Fri, 12 Feb 1993 04:56:00 -0500 >> It's not really clear from your message what you want your macro to do. ... I would like to construct RHET Statements for inserting facts in the RHET database. --RHET is a knowledge representation tool developed at the University of Rochester--. Facts are represented in RHET by expressions of the form [pred-name arg0 .. argn]. For example [Parent [John] [Mary]] may be interpreted as "John is a parent of Mary" or [Dog [Snoopi]] for "Snoopi is a dog". And what I want is a macro or function that for example takes two arguments, arg1 and arg2, and constructs an expression representing the fact "arg2 ist a arg1"; .i.e., [arg1 [arg2]]. To resume I like to define a function 'build-rhet-axiom' such that the evaluation of (build-rhet-axiom 'dog 'snoopi) returns the expression '[dog [snoopi]]. As I reported in my previous message the simple definition (defmacro BUILD-MY-EXPRESSION (arg1 arg2) `'(rassert [,arg1 [,arg2]])) didn't work; the evaluation of the form (BUILD-MY-EXPRESSION 'test1 'test2) returned (rassert [,arg1 [,arg2]]) instead of (rassert [test1 [test2]]). It worked as soon as I replace the square brackets by any other alphabetic character. I hope the formulation of the problem is now clear enough. Sorry for the inconveniences my first message might be caused. Regards, --akd. From excl-forum-distribution-owner Fri Feb 12 18:04:07 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150195>; Fri, 12 Feb 1993 18:04:02 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA01361; Fri, 12 Feb 93 14:23:54 PST Received: from FUSSEN.MT.CS.CMU.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA02219; Fri, 12 Feb 93 14:31:37 -0800 Received: from fussen.mt.cs.cmu.edu by FUSSEN.MT.CS.CMU.EDU id aa14805; 12 Feb 93 17:29:53 EST To: Abdel Kader Diagne Cc: Allegro-CL@ucbvax.berkeley.edu, bugs@franz.com Return-Receipt-To: toad@cs.cmu.edu Reply-To: toad@cs.cmu.edu Subject: Re: [spr7631] Defining a Macro In-Reply-To: Your message of Fri, 12 Feb 93 10:56:00 +0100. <9302120956.AA14172@disco-sol.dfki.uni-sb.de> Date: Fri, 12 Feb 1993 17:29:50 -0500 Message-Id: <14803.729556190@FUSSEN.MT.CS.CMU.EDU> From: Todd_Kaufmann@fussen.mt.cs.cmu.edu > I hope the formulation of the problem is now clear enough. No, you're really confused. > To resume I like to define a function 'build-rhet-axiom' such that the evaluation > of (build-rhet-axiom 'dog 'snoopi) returns the expression '[dog [snoopi]]. " '[dog [snoopi]] " is not an expression, so your request makes no sense. This is like saying you want a C expression like " i = i + 3; " in lisp. It makes no sense. There is a big difference between textual output and a lisp value. IF you just want output to send to another program, then (format stream "~&[~a [~a]]" arg1 arg2) will work. IF RHET is a tool in lisp, then either: (1) it will provide functions to construct what you want or primitives with which to do so. (2) you have to figure out the structure that it is storing them in. There may be a special structure print function which produces output in the format "[foo [bar]]", but then this isn't strict Common Lisp, but an extension defined by your tool. If there are reader extensions to allow "[a [b]]" as input, then there may not be explicit functions (as mentioned in (1)), but only accessible through the reader, so (read-from-string "[a [b]]") should work. Talk to the tool authors about this lack of functionality. You might also be able to determine what the reader macro is doing by quoting the expression. For example, '`(x ,(+ 2 3)) usually expands to something implementation dependent (in this case constrained by CL semantics to happen at runtime since generally the value can only be known then). Similarly, see if typing '[a [b]] produces a form, or if the expression is constructed at read time. If the latter, you may be able to get farther by looking at the reader function, uncompiling or disassembling if necessary. If there are no reader extensions, > (defmacro BUILD-MY-EXPRESSION (arg1 arg2) > `'(rassert [,arg1 [,arg2]])) > > didn't work; the evaluation of the form (BUILD-MY-EXPRESSION 'test1 'test2) > returned (rassert [,arg1 [,arg2]]) instead of (rassert [test1 [test2]]). > It worked as soon as I replace the square brackets by any other alphabetic > character. then indeed there is nothing special about the bracket characters, and the expression makes just as much sense as (defmacro BUILD-MY-EXPRESSION (arg1 arg2) `'(rassert q,arg1 q,arg2zz)) for any two characters q and z. In this case, it should *not* work, for any such characters, because the symbol "arg2zz" will be undefined. This statement provides the most information: > ... the evaluation of the form (BUILD-MY-EXPRESSION 'test1 'test2) > returned (rassert [,arg1 [,arg2]]) instead of (rassert [test1 [test2]]). This shows: that "[" is a reader extension, which works at read time. Thus, you can do no substitution of symbols for literals. The only way around this is indirectly through the reader (see (2) above). Also, talk to the implementators to find another way to get the desired run-time functionality. Todd Kaufmann From excl-forum-distribution-owner Mon Feb 15 05:45:42 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150183>; Mon, 15 Feb 1993 05:45:14 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03973; Mon, 15 Feb 93 01:35:41 PST Received: from relay2.UU.NET by ucbvax.Berkeley.EDU (5.63/1.43) id AA07279; Mon, 15 Feb 93 01:43:14 -0800 Received: from uni-sb.de by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA22700; Mon, 15 Feb 93 04:39:21 -0500 Organization: Universitaet des Saarlandes D-W-6600 Saarbruecken, Germany Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930116) id AA14318; Mon, 15 Feb 93 10:39:03 +0100 Received: from disco-sol.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA04284; Mon, 15 Feb 93 10:40:51 +0100 From: "Abdel Kader Diagne" Message-Id: <9302150943.AA09714@disco-sol.dfki.uni-sb.de> Received: by disco-sol.dfki.uni-sb.de; Mon, 15 Feb 93 10:43:16 +0100 To: Todd_Kaufmann@fussen.mt.cs.cmu.edu Cc: Allegro-CL@ucbvax.berkeley.edu, bugs@franz.com, toad@cs.cmu.edu, laubsch@hpljl.hpl.hp.com Subject: Re: [spr7631] Defining a Macro In-Reply-To: Your message of "Fri, 12 Feb 93 17:29:50 EST." <14803.729556190@FUSSEN.MT.CS.CMU.EDU> Date: Mon, 15 Feb 1993 04:43:16 -0500 It' me again. >> To resume I like to define a function 'build-rhet-axiom' such that the evaluation >> of (build-rhet-axiom 'dog 'snoopi) returns the expression '[dog [snoopi]]. Excuse me, as mentioned in the rest of the message in question, the output of (build-rhet-axiom 'dog 'snoopi) is supposed to be the (unevaluated) rhet command '(assert:rassert [dog [snoopi]]) instead of '[dog [snoopi]). > This is like saying you want a C expression like " i = i + 3; " in lisp. Not exactly the same. I don't just like to construct something like an expression (that makes no sense for my purposes, that's a wrong interpretation of the problem formulation). I rather try to to construct a (Lisp) form that (when evaluated) will cause the insertion of some axioms into an existing database. >> IF RHET is a tool in lisp, then either: >> (1) it will provide functions to construct what you want or primitives with >> which to do so. >> ... That's right (cf. statement above). The square bracket [ is a reader extension in RHET. That's what the function 'build-rhet-axiom' doesn't work the way I expect. I made the experience in a Lisp environment not containing RHET, as you can see below, it works (thanks to Gabriel Inaebnit and Todd Kaufmann) USER(1): (defmacro BUILD-RHET-AXIOM (arg1 arg2) `'(rassert [,arg1 [,arg2 ]])) BUILD-RHET-AXIOM USER(2): (BUILD-RHET-AXIOM 'test1 'test2) (RASSERT [ 'TEST1 [ 'TEST2 ]]) USER(3): So, the question remains the same, namely: Is there an elegant way to define "build-rhet-axiom" (without format and read-from-string) such that it returns the expected result, even if the square bracket [ is a reader extension? Thanks in advance. --akd. From excl-forum-distribution-owner Mon Feb 15 12:58:46 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150218>; Mon, 15 Feb 1993 12:58:41 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA04064; Mon, 15 Feb 93 08:59:42 PST Received: from cayuga.cs.rochester.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA10659; Mon, 15 Feb 93 09:07:32 -0800 Received: from alabaster.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA27906; Mon, 15 Feb 93 12:06:02 -0500 Received: by alabaster.cs.rochester.edu (4.1/x) id AA00293; Mon, 15 Feb 93 12:05:57 EST Date: Mon, 15 Feb 1993 12:05:57 -0500 From: miller@cs.rochester.edu Message-Id: <9302151705.AA00293@alabaster.cs.rochester.edu> To: diagne@dfki.uni-sb.de Cc: toad@cs.cmu.edu, Allegro-CL@ucbvax.berkeley.edu, bugs@franz.com In-Reply-To: Todd_Kaufmann@fussen.mt.cs.cmu.edu's message of Fri, 12 Feb 93 17:29:50 EST <14803.729556190@FUSSEN.MT.CS.CMU.EDU> Subject: [spr7631] Defining a Macro Hmm. Good thing I read this list; too bad I've been behind in my mail. Anyway, I'm the author of Rhet, so I think I can clear all this up. Rhet defines reader macros for [ and ] (amoung others). So it doesn't work to just macro expand into that since the parser has to see what's inside. The read-from-string suggestion would work, of course, but there are lower level primitives for constructing the terms directly (e.g. CONS-RHET-FORM), and that's what you really want to do. Look at the programmer's guide for help on the various functions available (tr 363); and the definition of the macro DEFRHETPRED (in assert-axioms.lisp) which probably does more than you want, but you'll possibly be able to start with that and cut out what you don't need; or at least use it as a roadmap. Remember you have the source code for Rhet, so use meta-dot when you need to find a function. I'll be happy to be of further assistance if you need it; just email me at miller@cs.rochester.edu (I'm not in every day this month, but I will get back to you as soon as I can). Note that (cons-rhet-form 'dog 'snoopi) -> [dog snoopi] or assuming you've defined a type t-dog: (let ((var (create-rvariable "?mydog" (make-i-type 't-dog)))) (cons-rhet-form 'dog var)) -> [dog ?mydog*T-DOG] etc; there should be more examples in the manuals. So you may not need your macro at all in light of cons-rhet-form. You can do (rassert (cons-rhet-form 'dog 'snoopi)) for instance to assert [dog snoopi] to the kb. Apologies for cluttering up these lists with Rhet stuff; I just wanted everyone to know the matter should be closed :-). Regards, Brad Miller From excl-forum-distribution-owner Fri Feb 19 16:10:06 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150204>; Fri, 19 Feb 1993 16:09:57 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07685; Fri, 19 Feb 93 12:18:00 PST Received: from drums.reasoning.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA10603; Fri, 19 Feb 93 12:25:54 -0800 Received: by drums.reasoning.com (5.61/25-eef) id AA16493; Fri, 19 Feb 93 12:23:22 -0800 for Allegro-CL@ucbvax.berkeley.edu Date: Fri, 19 Feb 1993 15:23:22 -0500 From: Eric McCarthy Message-Id: <9302192023.AA16493@drums.reasoning.com> To: Allegro-CL@ucbvax.berkeley.edu Subject: How do I tell if a file is a plain file or a directory? Reply-To: eric@reasoning.com If "/tmp/subdir" is a directory and "/tmp/foo.lisp" is a plain file: .> (probe-file "/tmp/subdir") #p"/tmp/subdir" .> (probe-file "/tmp/subdir/") #p"/tmp/subdir/" .> (probe-file "/tmp/foo.lisp") #p"/tmp/foo.lisp" .> (probe-file "/tmp/foo.lisp/") #p"/tmp/foo.lisp/" <- NIL seems more sensible How do I tell from lisp if a given file is a plain file or directory, aside from doing (excl:run-shell-command "/bin/test -d filename")? ----------------- Eric McCarthy Reasoning Systems eric@reasoning.com From excl-forum-distribution-owner Mon Feb 22 12:37:57 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150188>; Mon, 22 Feb 1993 12:37:46 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10416; Mon, 22 Feb 93 08:51:52 PST Received: from isgate.is by ucbvax.Berkeley.EDU (5.63/1.43) id AA13129; Mon, 22 Feb 93 08:50:00 -0800 Received: from lexis.hi.is by isgate.is (5.65c8/ISnet/14-10-91); Mon, 22 Feb 1993 16:47:20 GMT Received: by lexis.hi.is (AIX 2.1 2/smail2.5/11-22-88) id AA00999; Mon, 22 Feb 93 16:21:59 GMT Received: by ohpsi.lexis.hi.is (AIX 3.2/UCB 5.64/smail2.5/11-22-88) id AA14560; Mon, 22 Feb 1993 16:44:56 GMT From: jorgen@lexis.hi.is (Jorgen Pind) Message-Id: <9302221644.AA14560@ohpsi.lexis.hi.is> Subject: Please remove my name from this list To: Allegro-CL@ucbvax.berkeley.edu Date: Mon, 22 Feb 1993 11:44:55 -0500 X-Mailer: ELM [version 2.3 PL5] X-Charset: ASCII X-Char-Esc: 29 Please remove my name from this list thanks Jorgen Pind From excl-forum-distribution-owner Mon Feb 22 21:17:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150185>; Mon, 22 Feb 1993 21:17:20 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10727; Mon, 22 Feb 93 16:41:59 PST Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA00755; Mon, 22 Feb 93 16:49:53 -0800 Return-Path: Received: from lava.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA16503; Mon, 22 Feb 93 16:43:10 PST Received: by lava.Franz.COM (4.1/FI-2.0) id AA00850; Mon, 22 Feb 93 16:49:23 PST Date: Mon, 22 Feb 1993 19:49:23 -0500 From: georgej@franz.com (George Jacob) Message-Id: <9302230049.AA00850@lava.Franz.COM> To: eric@reasoning.com Class: bh Bh-Id: spr7699 Bh: append spr7699 Subject: Re: [spr7699] How do I tell if a file is a plain file or a directory? Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu | .> (probe-file "/tmp/subdir") | #p"/tmp/subdir" | .> (probe-file "/tmp/subdir/") | #p"/tmp/subdir/" | .> (probe-file "/tmp/foo.lisp") | #p"/tmp/foo.lisp" | .> (probe-file "/tmp/foo.lisp/") | #p"/tmp/foo.lisp/" <- NIL seems more sensible Our reading of the language spec indicates that there is no implementation-independent way of making this distinction. We tend to use the function, excl::probe-file-non-directory, for this purpose, but of course it is as unportable as your solution. --------------------------------------------------------------- George Jacob Internet: georgej@franz.com Franz Inc., uucp: uunet!franz!georgej 1995 University Avenue, Phone: (510) 548-3600 Berkeley, CA 94704. FAX: (510) 548-8253 --------------------------------------------------------------- From excl-forum-distribution-owner Tue Feb 23 12:46:25 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150191>; Tue, 23 Feb 1993 12:46:22 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11442; Tue, 23 Feb 93 08:41:08 PST Received: from NL.CS.CMU.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA23076; Tue, 23 Feb 93 08:49:03 -0800 Date: Tue, 23 Feb 1993 11:46:50 -0500 From: Peter Shell To: allegro-cl@ucbvax.berkeley.edu Subject: I/O efficiency question Message-Id: Sender: pshell@nl.cs.cmu.edu I have an Allegro 4.1 program (running on a Sun Sparcstation-II) which does file i/o with large files (over a megabyte). I am trying to optimize the file i/o and noticed that 'read-char' and 'write-char' are fairly slow, the reason being that they first call for example: (METHOD STREAM:STREAM-READ-CHAR (STREAM:FUNDAMENTAL-CHARACTER-INPUT-STREAM)) and then: stream:stream-read-char. When I tried calling stream:stream-read-char directly, it went faster but still tried invoking the (METHOD STREAM:STREAM-READ-CHAR ...). By calling EXCL::STM-FILE-BUFFERED-READ-CHAR and EXCL::STM-FILE-BUFFERED-WRITE-CHAR directly I was able to bypass the method stuff, speeding up my program considerably (45%). I would rather not call internal Allegro functions, but I can't seem to find a way around this. I tried putting a (declare (type STREAM:FUNDAMENTAL-CHARACTER-INPUT-STREAM stream)) and (declare (optimize (speed 3) (safety 0) (debug 0))) in my read/write functions, but this didn't seem to help. So my question is, is there a more elagent way to do this, and if not, why not make the compiler bypass the method stuff for read-char and write-char if it knows that the type is a character stream? Thanks, Pete Shell pshell@cmu.edu From excl-forum-distribution-owner Tue Feb 23 17:19:11 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150200>; Tue, 23 Feb 1993 17:19:08 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11516; Tue, 23 Feb 93 13:32:17 PST Received: from alpha.Xerox.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA02088; Tue, 23 Feb 93 13:40:05 -0800 Received: from skye.parc.xerox.com ([13.2.16.192]) by alpha.xerox.com with SMTP id <11602>; Tue, 23 Feb 1993 13:38:32 PST Received: by skye.parc.xerox.com id <32262>; Tue, 23 Feb 1993 13:38:24 -0800 From: Doug Cutting To: pshell@nl.cs.cmu.edu Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: Peter Shell's message of Tue, 23 Feb 1993 08:46:50 -0800 Subject: Re: I/O efficiency question Message-Id: <93Feb23.133824pst.32262@skye.parc.xerox.com> Date: Tue, 23 Feb 1993 16:38:19 -0500 > Date: Tue, 23 Feb 1993 08:46:50 -0800 > From: Peter Shell > > By calling EXCL::STM-FILE-BUFFERED-READ-CHAR and > EXCL::STM-FILE-BUFFERED-WRITE-CHAR directly I was able to bypass > the method stuff, speeding up my program considerably (45%). If you really want to make your program burn, try the following: (defmacro fast-read-char (stream) #+(and allegro (version>= 4)) `(stream:stream-read-char ,stream) #+lucid`(lcl:fast-read-char ,stream nil :eof) #-(or (and allegro (version>= 4)) lucid) `(read-char ,stream nil :eof)) (defmacro fast-read-file-char (stream) `(fast-read-char ,stream)) #+(and allegro (version>= 4)) (define-compiler-macro fast-read-file-char (stream) `(macrolet ((stream-slots (stream) `(the simple-vector (svref ,stream 1))) (stream-buffer (slots) `(the simple-string (svref ,slots 11))) (stream-buffpos (slots) `(the fixnum (svref ,slots 12))) (stream-maxbuffpos (slots) `(the fixnum (svref ,slots 13)))) (declare (optimize (speed 3) (safety 0))) (let* ((stream ,stream) (slots (stream-slots stream)) (buffpos (stream-buffpos slots)) (maxbuffpos (stream-maxbuffpos slots))) (declare (fixnum buffpos maxbuffpos)) (if (>= buffpos maxbuffpos) (stream:stream-read-char stream) (prog1 (schar (stream-buffer slots) buffpos) (when (= (setf (stream-buffpos slots) (the fixnum (1+ buffpos))) maxbuffpos) (setf (stream-maxbuffpos slots) 0))))))) From excl-forum-distribution-owner Fri Feb 26 14:33:18 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150178>; Fri, 26 Feb 1993 14:33:14 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14025; Fri, 26 Feb 93 10:47:09 PST Received: from sauquoit.gsfc.nasa.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA05820; Fri, 26 Feb 93 10:55:05 -0800 Message-Id: <9302261855.AA05820@ucbvax.Berkeley.EDU> Received: by sauquoit.gsfc.nasa.gov (16.8/16.2) id AA18447; Fri, 26 Feb 93 13:48:27 -0500 Date: Fri, 26 Feb 1993 13:48:27 -0500 From: Secret Agent Man To: allegro-cl@ucbvax.berkeley.edu Subject: Add my name to the mailing list. Could you please add my name to the mailing list? Thanks, Bob Cromp NASA/Goddard Space Flight Center cromp@sauquoit.gsfc.nasa.gov From excl-forum-distribution-owner Fri Mar 5 18:37:32 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150194>; Fri, 5 Mar 1993 18:37:25 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20460; Fri, 5 Mar 93 14:48:48 PST Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA24734; Fri, 5 Mar 93 14:56:49 -0800 Received: by atc.boeing.com (5.57) id AA15072; Fri, 5 Mar 93 15:00:48 -0800 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Fri, 5 Mar 93 14:58 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA06322; Fri, 5 Mar 93 14:56:19 PST Received: by fritz.ata (4.1/SMI-4.1) id AA05993; Fri, 5 Mar 93 14:56:11 PST Date: Fri, 5 Mar 1993 17:56:19 -0500 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: Lexical equivalent of progv To: allegro-cl@ucbvax.berkeley.edu Message-Id: <9303052256.AA06322@gumby.ata> Hi: X-Envelope-To: allegro-cl@berkeley.edu Is there an equivalent of progv for lexical variables? That is, I want a form that accepts a list of variable names, and a list of values and binds those values to *lexical* variables over the body of the form. Progv does this but binds values to *dynamic* variables. Thanks ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com Seattle, Wa. From excl-forum-distribution-owner Fri Mar 5 20:12:28 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150207>; Fri, 5 Mar 1993 20:12:21 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20505; Fri, 5 Mar 93 16:32:04 PST Received: from darkstar.isi.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA28411; Fri, 5 Mar 93 16:40:04 -0800 Received: from hpai12.isi.edu by darkstar.isi.edu (5.65c/5.61+local-11) id ; Fri, 5 Mar 1993 16:39:57 -0800 Message-Id: <199303060039.AA00995@darkstar.isi.edu> To: bha@gumby.boeing.com Subject: [Re: Lexical equivalent of progv] Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9303052256.AA06322@gumby.ata> Date: Fri, 5 Mar 1993 19:40:38 -0500 From: Neil Goldman What makes a lexical variable LEXICAL is that the place where it is bound andl all uses of that binding are lexically apparent in the program. (which implies they can be determined by a compiler) Progv allows a program to COMPUTE the names of the variables, meaning that they are NOT lexically apparent --- the same PROGV form can bind variables of different names (even different numbers of vars) from one execution to the next. So there can't be direct analog. You could, with a macro, define a lexical progv that took an UNEVALUATED list of variables and an EVALUATED list of bindings, e.g. (defmacro LPROGV (varlist vallist &body b) (unless (every #'symbolp varlist) (error "illegal variable list")) `(apply #'(lambda (&optional ,@varlist &rest ignore) (declare (ignore ignore)) ,.body) ,vallist)) This would, like PROGV, allow the valuelist to contain either fewer or more values than the varlist. Unlike PROGV, if the value list contained fewer values than the varlist, the excess vars would be bound to NIL. (There is no concept of an unbound LEXICAL variable in common lisp. I imagine the designers assume that by allowing optional parameters in lambda lists to have both defaults AND supplied-p indicators, programmers could live with that restriction. Personally, I think it would hve been better to have the unbound concept for lexical variables as well as specials, but I can't tell if UNBOUND is really at the root of your request or not.) neil goldman From excl-forum-distribution-owner Fri Mar 5 21:12:49 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150209>; Fri, 5 Mar 1993 21:12:41 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20540; Fri, 5 Mar 93 17:21:23 PST Received: from alpha.Xerox.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA00238; Fri, 5 Mar 93 17:29:14 -0800 Received: from skye.parc.xerox.com ([13.2.16.192]) by alpha.xerox.com with SMTP id <11765>; Fri, 5 Mar 1993 17:26:31 PST Received: by skye.parc.xerox.com id <32262>; Fri, 5 Mar 1993 17:26:21 -0800 From: Doug Cutting To: bha@gumby.boeing.com Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: bha's message of Fri, 5 Mar 1993 14:56:19 -0800 <9303052256.AA06322@gumby.ata> Subject: Re: Lexical equivalent of progv Message-Id: <93Mar5.172621pst.32262@skye.parc.xerox.com> Date: Fri, 5 Mar 1993 20:26:11 -0500 > Date: Fri, 5 Mar 1993 14:56:19 -0800 > From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> > > Is there an equivalent of progv for lexical variables? > > That is, I want a form that accepts a list of variable names, and > a list of values and binds those values to *lexical* variables over > the body of the form. Progv does this but binds values to *dynamic* > variables. In short, no. If first-class environments had made it into the language, then you could build (or augment) an environment and then evaluate the body in this environment. (First-class environments are discussed on pages 207-214 of CLtL2, but they've since been removed from the language.) Still, you're stuck evaluating the body -- it won't run compiled. To compile it you'd need to be able to declare that a variable will be lexically bound (which you can't), so that the compiler does not either break or warn and use a dynamic reference. Not to mention that non-lexical bindings of lexical variables is rather contradictory. Doug From excl-forum-distribution-owner Mon Mar 8 03:23:24 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150204>; Mon, 8 Mar 1993 03:23:17 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA22643; Sun, 7 Mar 93 23:25:00 PST Received: from moncol.monmouth.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA19444; Sun, 7 Mar 93 23:33:01 -0800 Message-Id: <9303080733.AA19444@ucbvax.Berkeley.EDU> From: kosaka@moncol.monmouth.edu Date: Wed, 3 Mar 1993 14:32:00 -0500 To: allegro-cl@ucbvax.berkeley.edu Content-Type: text Content-Length: 166 When I try to compile codes containing return-from, I get compilation error stating return-from label NIL isn't visible. Can you tell me what I am doing wrong? -MK From excl-forum-distribution-owner Tue Mar 9 14:46:23 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150239>; Tue, 9 Mar 1993 14:46:17 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA24443; Tue, 9 Mar 93 11:10:34 PST Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA28142; Tue, 9 Mar 93 11:18:34 -0800 Return-Path: Received: from rubix.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA17332; Tue, 9 Mar 93 11:15:29 PST Received: by rubix.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA03213; Tue, 9 Mar 93 11:10:20 PST Date: Tue, 9 Mar 1993 14:10:20 -0500 From: dm@franz.com (David Margolies) Message-Id: <9303091910.AA03213@rubix.Franz.COM> To: kosaka@moncol.monmouth.edu Class: bh Bh-Id: spr7837 Bh: append spr7837 Subject: Re: [spr7837] Compiling code containing return-from Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Your problem report has been assigned a tracking id of spr7837. Please use this id in the subject line of any mail related to it so that we may better track communication on your inquiry. Also, please address mail to bugs@franz.com as well as me, so your questions can be answered if I am unavailable. When I try to compile codes containing return-from, I get compilation error stating return-from label NIL isn't visible. Can you tell me what I am doing wrong? -MK Well, not with just this amount of information 8-). I tried the example in the CLMAN page on RETURN-FROM, and it worked interpreted, compiled without error, and worked compiled. This was on Allegro CL 4.1 on a Sparcstation. It is possible that the behavior in the version you are running is different, which is why it is useful to us if you include the Allegro CL version number (its in the banner printed when Lisp comes up) and the type of machine in every message and problem report. Do you have a sample of code which fails? Note that RETURN-FROM requires a name argument that names the block being returned from. Is it possible you left that out (and the result form was NIL instead)? Anyway, here is the example from CLMAN: Allegro CL 4.1 [SPARC; R1] (5/29/92 15:51) Copyright (C) 1985-1992, Franz Inc., Berkeley, CA, USA. All Rights Reserved. ;; Optimization settings: safety 1, space 1, speed 1, debug 2 ;; For a complete description of all compiler switches given the current ;; optimization settings evaluate (EXPLAIN-COMPILER-SETTINGS). ;; Starting socket daemon and emacs-lisp interface... USER(1): (defun block-test (arg) (block outer (format nil "arg is a list of length ~d" (block inner (if (atom arg) (return-from outer "arg is an atom") (return-from inner (length arg))))))) BLOCK-TEST USER(2): (block-test 1.0) "arg is an atom" USER(3): (block-test '(1 2 3)) "arg is a list of length 3" USER(4): (compile 'block-test) BLOCK-TEST NIL NIL USER(5): (block-test 1.0) "arg is an atom" USER(6): (block-test '(1 2 3)) "arg is a list of length 3" USER(7): I look forward to getting more information on the problem you are having. David Margolies Franz Inc. From excl-forum-distribution-owner Thu Mar 11 18:42:55 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150196>; Thu, 11 Mar 1993 18:42:44 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26388; Thu, 11 Mar 93 14:43:56 PST Received: from Mail.Think.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA07832; Thu, 11 Mar 93 14:51:59 -0800 Received: from Think.COM by mail.think.com; Thu, 11 Mar 93 17:49:46 -0500 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Thu, 11 Mar 93 17:49:36 EST Date: Thu, 11 Mar 1993 17:49:00 -0500 From: Barry Margolin Reply-To: luv-93-organizer@ai.sri.com Subject: Call for papers for LUV '93, Cambridge,MA To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, info-dylan@cambridge.apple.com, scheme@mc.lcs.mit.edu Included-Msgs: <930311161656_76470.3334_EHC27-3@CompuServe.COM>, The message of 11 Mar 1993 11:16 EST from 76470.3334@compuserve.com, The message of 11 Mar 1993 11:16 EST from An Event To Remember Message-Id: <19930311224928.9.BARMAR@occam.think.com> ------Begin Forwarded Message------ Date: Thu, 11 Mar 1993 11:16 EST From: An Event To Remember <76470.3334@compuserve.com> To: Luv '93 Subject: Call for papers for LUV '93, Cambridge,MA CALL FOR PAPERS FOR THE 1993 INTERNATIONAL LISP USERS AND VENDORS CONFERENCE: Cambridge, MA; August 9-13 Traditionally, LUV papers address the practical applications of Lisp. This year, in addition to these traditional experience papers the committee is also seeking papers that focus on Lisp and education. Papers may discuss either Lisp education, or the use of Lisp in furthering education in other areas. The relationship between Lisp and software engineering education, or Lisp and computer science education are especially appropriate subjects. Application of Lisp to further education in other areas are also good candidates. The material must clearly demonstrate a practical value from the use of the Lisp language or Lisp technology; as such, papers need not be especially innovative nor original, but preference will be given to previously undisseminated reports or experiences. Topics in the area of programming languages and environments are welcome; but untested or purely theoretical ideas without a clear direction towards the theme of the conference would be less suitable. Authors should submit 7 copies of their papers to the Conference Organizers: c/o ALU, P.O. Box 294, Malvern, PA 19355. The length of the written papers should not exceed 10 pages (numbered, font size 10pt or larger). Accepted papers will appear in the written proceedings, which will be distributed at the conference. The authors of certain selected papers will be invited to make a 20-minute verbal presentation at the technical talks sessions during the conference. Time constraints will likely prevent the verbal presentation of all accepted papers. Other accepted papers will be presented during a poster paper session. Abstracts must be received by April 30, 1993 (along with papers if ready). Final papers must be received by June 7, 1993. Each should include a return postal address and a telephone number; an electronic mail address should also be included, if available. Authors will be notified of the acceptance or rejection of their papers by July 5, 1993. Corrections and alterations to the papers, if any, may be done up until July 19, 1993, which is the final date for receipt of a camera-ready copy. Authors of accepted paper will be required to sign a release for publication in the conference proceedings. Authors may retain the copyright themselves if they wish by installing their own copyright notice in the paper. Previously copyrighted material may still be published depending on the permission to publish; in this case, the previous copyright and notice of permission should appear in the paper. Persons interested in the student competition should contact the Conference Organizers (address above) for submission requirements and further details. Both technical papers and descriptions of Lisp applications are valid entries. Submission and acceptance dates, as well as acceptable themes, are the same as for other authors. If you wish to receive a registration brochure please contact the Conference Organizers via: e-mail at Luv-93-organizer@ai.sri.com ,or mail at the above address, or by phone at 215-651-2990. ------End Forwarded Message------ This message is being posted to many large mailing lists; please don't cc the original recipients when replying. From excl-forum-distribution-owner Mon Mar 15 17:26:47 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150211>; Mon, 15 Mar 1993 17:26:40 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00463; Mon, 15 Mar 93 13:35:12 PST Received: from Mail.Think.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA01826; Mon, 15 Mar 93 13:43:15 -0800 Received: from Think.COM by mail.think.com; Mon, 15 Mar 93 16:39:55 -0500 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Mon, 15 Mar 93 16:39:37 EST Date: Mon, 15 Mar 1993 16:39:00 -0500 From: Barry Margolin Reply-To: luv-93-organizer@ai.sri.com Subject: LUV '93 call for papers: changes to student submission only To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, info-dylan@cambridge.apple.com, scheme@mc.lcs.mit.edu Included-Msgs: <930315165622_76470.3334_EHC23-1@CompuServe.COM>, The message of 15 Mar 1993 11:56 EST from 76470.3334@compuserve.com, The message of 15 Mar 1993 11:56 EST from An Event To Remember Message-Id: <19930315213931.9.BARMAR@occam.think.com> ------Begin Forwarded Message------ Date: Mon, 15 Mar 1993 11:56 EST From: An Event To Remember <76470.3334@compuserve.com> To: Luv '93 Subject: call for papers:changes to student submission only CALL FOR PAPERS FOR THE 1993 INTERNATIONAL LISP USERS AND VENDORS CONFERENCE: Cambridge, MA; August 9-13 Traditionally, LUV papers address the practical applications of Lisp. This year, in addition to these traditional experience papers the committee is also seeking papers that focus on Lisp and education. Papers may discuss either Lisp education, or the use of Lisp in furthering education in other areas. The relationship between Lisp and software engineering education, or Lisp and computer science education are especially appropriate subjects. Application of Lisp to further education in other areas are also good candidates. The material must clearly demonstrate a practical value from the use of the Lisp language or Lisp technology; as such, papers need not be especially innovative nor original, but preference will be given to previously undisseminated reports or experiences. Topics in the area of programming languages and environments are welcome; but untested or purely theoretical ideas without a clear direction towards the theme of the conference would be less suitable. Authors should submit 7 copies of their papers to the Conference Organizers: c/o ALU, P.O. Box 294, Malvern, PA 19355. The length of the written papers should not exceed 10 pages (numbered, font size 10pt or larger). Accepted papers will appear in the written proceedings, which will be distributed at the conference. The authors of certain selected papers will be invited to make a 20-minute verbal presentation at the technical talks sessions during the conference. Time constraints will likely prevent the verbal presentation of all accepted papers. Other accepted papers will be presented during a poster paper session. Abstracts must be received by April 30, 1993 (along with papers if ready). Final papers must be received by June 7, 1993. Each should include a return postal address and a telephone number; an electronic mail address should also be included, if available. Authors will be notified of the acceptance or rejection of their papers by July 5, 1993. Corrections and alterations to the papers, if any, may be done up until July 19, 1993, which is the final date for receipt of a camera-ready copy. Authors of accepted paper will be required to sign a release for publication in the conference proceedings. Authors may retain the copyright themselves if they wish by installing their own copyright notice in the paper. Previously copyrighted material may still be published depending on the permission to publish; in this case, the previous copyright and notice of permission should appear in the paper. There will be a seperate track for Student papers. Submission and acceptance dates, as well as acceptable themes, are the same as for other authors. Acepted papers will appear in the written proceedings (please see above instructions regarding copyright and permission to publish requirements). If you wish to receive a registration brochure please contact the Conference Organizers via: e-mail at Luv-93-organizer@ai.sri.com ,or mail at the above address, or by phone at 215-651-2990. ------End Forwarded Message------ From excl-forum-distribution-owner Mon Mar 15 19:29:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150226>; Mon, 15 Mar 1993 19:29:37 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00532; Mon, 15 Mar 93 15:46:33 PST Received: from quark.isi.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA04817; Mon, 15 Mar 93 15:54:29 -0800 Received: from berio.isi.edu by quark.isi.edu (5.65c/5.61+local-10) id ; Mon, 15 Mar 1993 15:53:02 -0800 Message-Id: <199303152353.AA07964@quark.isi.edu> To: Allegro-CL@ucbvax.berkeley.edu Subject: image size limit Reply-To: whitney@isi.edu Date: Mon, 15 Mar 1993 18:52:59 -0500 From: Richard Whitney Folks, In trying to load a large knowledge base I get the following: Error: An allocation request for 64 bytes caused a need for 15990784 more bytes of heap. This would exceed the image size limit set at initial build. [condition type: STORAGE-CONDITION] I assume this is an Allegro limit and not a Unix limit: % limit filesize filesize unlimited I found no documentation regarding parameters under my control; I now assume the correction is to be done at Allegro build time via the inquiry "Size of the preallocated heap [60m]:", which I found in the 4.2 installation guide. If this is the case, I can say that it would be very helpful to have some control over this so that I don't have to go back to the installer and have it all redone. For comparison, the size of a similar Lucid image is 74 megabytes. Cheers, Richard From excl-forum-distribution-owner Tue Mar 23 21:51:50 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150196>; Tue, 23 Mar 1993 21:51:27 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07937; Tue, 23 Mar 93 18:01:55 PST Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA29706; Tue, 23 Mar 93 18:10:06 -0800 Received: by atc.boeing.com (5.57) id AA05668; Tue, 23 Mar 93 18:13:50 -0800 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Tue, 23 Mar 93 18:11 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA24292; Tue, 23 Mar 93 18:09:02 PST Received: by fritz.ata (4.1/SMI-4.1) id AA21259; Tue, 23 Mar 93 18:08:54 PST Date: Tue, 23 Mar 1993 21:09:02 -0500 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: MOP programming - compile vs. load To: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Message-Id: <9303240209.AA24292@gumby.ata> X-Envelope-To: allegro-cl@berkeley.edu ACL 4.2beta Hi all: I am attempting to implement an extension to CLOS via the MOP and am having some trouble with compile versus load time execution of class metaobject methods. As background, here is a brief explanation of what I am trying to accomplish. I have a need to "surround" *every* method of an object with some body of code. It is highly desirable that the implementation mechanism is transparent as possible with respect to those methods that are surrounded. I don't believe that defining a special method metaobject is appropriate for implementing surround behavior. Anyway, not all methods of a particular generic function necessarily have the surround behavior. I also do not think that :around methods are the appropriate mechanism for implementing surround behavior. The surround behavior is more closely associated with the behavior of a particular class, not the individual methods. For class hierarchies, a "mixin" class may be a component of a class that does not have the surround behavior. Thus, in this context the methods associated with the mixin class should not have surround behavior. Therefore, I believe that defining a class metaobject is probably the most appropriate mechanism for implementing surround behavior. The class metaobject can then be used to "declare" the intention that a particular class (and therefore its methods) have surround behavior. The ultimate use of this mechanism is to implement what I call "gated" objects. Conceptually, gated objects are objects that have a (Dykstra, Brinch Hansen) "monitor" that surrounds them. This monitor moderates concurrent access to a gated object such that one and only one thread of control can execute a (direct or inherited) method of the object at any point in time. Thus, we have an object-oriented mechanism for controlling concurrent access to shared resources (code and data). So, what I have done is to define a metaclass called encapsulated-class that defines the base behavior upon which gated objects will be built (so called "surround" or "encapsulated" methods). An encapsulated class has a "shadow" class that is its dual. For each encapsulated class, there is an encapsulator class. For each method of the encapsulated class, there is a "trampoline" method of the encapsulator class that embodies the "surround" processing. When a new encapsulated class is defined (via defclass with a :metaclass of encapsulated-class) a new encapsulator class is defined behind the scenes (again via defclass). As methods are defined for an encapsulated class, "trampoline" methods are defined for the encapsulator class behind the scenes. When an instance of an encapsulated class is made, its dual (the encapsulator) is also made. What is returned from the make-instance method for an encapsulated class is actually the encapsulator instance. Thus, any methods destined for the encapsulated object are actually handled by the encapsulator object. Any "surround" processing is performed by the encapsulator trampoline method, then control is passed to the real method in the encapsulated object. For gated objects, this involves obtaining a "lock" associated with the encapsulator object before calling the real method in the encapsulated object. OK, all this stuff seems to be working except for one "tiny" problem. When an encapsulated class is "compiled," it is actually instantiated (that is the encapsulated-class class metaobject is instantiated). This causes the initialize-instance method on the encapsulated-class class metaobject to be called. This is where I hook in to define the encapsulated class. The problem is, at *compile time*, certain data structures (such as the superclass of an encapsulated class) are ill defined (the superclass is a forward-referenced-class). When the "compiled" code is "loaded", this causes the class metaobject to be seemingly instantiated again (?) and initialize-instance to be called again (no, *not* reinitialize-instance). But my processing (which the first time thru at compile time did a defclass of the encapsulator class) now ends up (indirectly) invoking reinitialize-instance on the encapsulator class (since I do the defclass of the encapsulator class again as I am unable to distinguish compile time from load time execution). What I need to do (I think) is to defer my processing that is hooked into the initialize-instance method on the encapsulated-class class metaobject until *not* compile time. Note that when I *evaluate* the defclass form of the encapsulated class (instead of compile it), everything works just fine! Also, what is going on at compile and load time such that the initialize-instance method is called two times - once at compile time then again at load time? Whew! Anybody have any thoughts on this? Thanks ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com Seattle, Wa. From excl-forum-distribution-owner Thu Mar 25 11:50:13 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150146>; Thu, 25 Mar 1993 11:49:48 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA09479; Thu, 25 Mar 93 08:05:17 PST Received: from uni-sb.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA21552; Thu, 25 Mar 93 08:13:13 -0800 Organization: Universitaet des Saarlandes D-W-6600 Saarbruecken, Germany Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930226) id AA26844; Thu, 25 Mar 93 17:09:57 +0100 Received: from disco-sol.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA01177; Thu, 25 Mar 93 17:12:28 +0100 From: "Abdel Kader Diagne" Message-Id: <9303251615.AA23932@disco-sol.dfki.uni-sb.de> Received: by disco-sol.dfki.uni-sb.de; Thu, 25 Mar 93 17:15:11 +0100 To: allegro-cl@ucbvax.berkeley.edu, common-lisp@mcc.com Subject: printers for structures Date: Thu, 25 Mar 1993 11:15:11 -0500 Hi, I'm looking for a way of using optional printers for structures. In some cases I like to use the default lisp printer, and in other cases a user-defined pretty printer; e.g., what I want is to switch (depending on the value of a pre-defined variable) between the default printer and a user-defined pretty-printer for a given structure. Any idea how to do that? Thanks in advance. ---Kader. From excl-forum-distribution-owner Thu Mar 25 18:31:36 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150182>; Thu, 25 Mar 1993 18:31:25 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA09559; Thu, 25 Mar 93 10:53:22 PST Received: from brazil.cambridge.apple.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA25459; Thu, 25 Mar 93 11:01:22 -0800 Received: from ministry.cambridge.apple.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef) id AA09051; Thu, 25 Mar 93 14:02:33 -0500 for allegro-cl@ucbvax.berkeley.edu Received: from bill.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef) id AA29037; Thu, 25 Mar 93 13:54:42 -0500 Message-Id: <9303251854.AA29037@cambridge.apple.com> Date: Thu, 25 Mar 1993 15:02:42 -0500 To: "Abdel Kader Diagne" From: bill@cambridge.apple.com (Bill St. Clair) Subject: Re: printers for structures Cc: allegro-cl@ucbvax.berkeley.edu, common-lisp@mcc.com At 17:15 3/25/93 +0100, Abdel Kader Diagne wrote: >Hi, > >I'm looking for a way of using optional printers for structures. In some >cases I like to use the default lisp printer, and in other cases a user-defined >pretty printer; e.g., what I want is to switch (depending on the value of a >pre-defined variable) between the default printer and a user-defined >pretty-printer for a given structure. >Any idea how to do that? > >Thanks in advance. >---Kader. The following works in Macintosh Common Lisp. I haven't tested it anywhere else. ------------------------------------------------------------------------ (defstruct foo x y) (defvar *print-foos-pretty* nil) (defmethod print-object ((o foo) stream) (if *print-foos-pretty* (format stream "#" 'foo 'x (foo-x o) 'y (foo-y o)) (call-next-method))) #| ; Test code (let ((foo (make-foo)) (*print-foos-pretty* nil)) (print foo) (setq *print-foos-pretty* t) (print foo) nil) |# From excl-forum-distribution-owner Fri Mar 26 14:24:30 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150226>; Fri, 26 Mar 1993 14:24:15 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10363; Fri, 26 Mar 93 10:39:08 PST Received: from linus.mitre.org by ucbvax.Berkeley.EDU (5.63/1.43) id AA15383; Fri, 26 Mar 93 10:47:11 -0800 Return-Path: Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA29109; Fri, 26 Mar 93 13:45:39 -0500 Posted-Date: Fri, 26 Mar 93 13:45:35 EST Received: by thelonius.mitre.org (5.61/RCF-4C) id AA22399; Fri, 26 Mar 93 13:45:36 -0500 Message-Id: <9303261845.AA22399@thelonius.mitre.org> To: allegro-cl@ucbvax.berkeley.edu, common-lisp@mcc.com Subject: Re: printers for structures Date: Fri, 26 Mar 1993 13:45:35 -0500 From: john@linus.mitre.org Bill St. Clair (bill@cambridge.apple.com) writes: The following works in Macintosh Common Lisp. I haven't tested it anywhere else. (defstruct foo x y) (defvar *print-foos-pretty* nil) (defmethod print-object ((o foo) stream) (if *print-foos-pretty* (format stream "#" 'foo 'x (foo-x o) 'y (foo-y o)) (call-next-method))) This works in Allegro 4.1 also. BUT, in the ANSI draft, structures are not required to print via PRINT-OBJECT, although that might seem counter-intuitive. The draft says (p 8-10) If :PRINT-FUNCTION [is] not supplied ... then a default printing function is provided for the structure that prints out all its slots using #S syntax. Supplying :PRINT-FUNCTION ... is equivalent to defining an appropriate method on the PRINT-OBJECT generic function. The first paragraph would seem to indicate that every structure has a :PRINT-FUNCTION function, whether you define it or not, and thus :PRINT-OBJECT methods on an included structure class aren't inherited. In the second paragraph, it's not clear what "equivalent" means, as Sandra Loosemoore has pointed out in public review comments. For one thing, :PRINT-FUNCTION functions have different argument structure than PRINT-OBJECT. This confusion will probably be rectified in the next draft, but for now it's yet another example of how hard it is to properly integrate new features (CLOS) and old (DEFSTRUCT). John Burger john@mitre.org From excl-forum-distribution-owner Fri Mar 26 15:31:36 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150212>; Fri, 26 Mar 1993 15:31:22 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10391; Fri, 26 Mar 93 11:40:39 PST Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA17819; Fri, 26 Mar 93 11:48:43 -0800 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA09881; Fri, 26 Mar 93 11:45:49 PST From: smh@franz.com (Steve Haflich) Message-Id: <9303261945.AA09881@akbar.Franz.COM> To: john@linus.mitre.org Cc: allegro-cl@ucbvax.berkeley.edu, common-lisp@mcc.com Subject: Re: printers for structures In-Reply-To: Your message of Fri, 26 Mar 93 13:45:35 -0500. <9303261845.AA22399@thelonius.mitre.org> Date: Fri, 26 Mar 1993 14:45:48 -0500 > From: john@linus.mitre.org > > Bill St. Clair (bill@cambridge.apple.com) writes: > > The following works in Macintosh Common Lisp. I haven't tested it > anywhere else. > > (defstruct foo x y) > > (defvar *print-foos-pretty* nil) > > (defmethod print-object ((o foo) stream) > (if *print-foos-pretty* > (format stream "#" > 'foo 'x (foo-x o) 'y (foo-y o)) > (call-next-method))) > > This works in Allegro 4.1 also. BUT, in the ANSI draft, structures > are not required to print via PRINT-OBJECT, although that might seem > counter-intuitive. I disagree with this conclusion. The dpANS says under PRINT-OBJECT that the printer calls PRINT-OBJECT; PRINT-OBJECT is _not_ called by user code; that the implementation must provide methods so that all objects have an applicable method. Although the spec doesn't explicitly state that the printer _must_ call PRINT-OBJECT for every object and subobject printed, one can infer this rather easily from the above requirements; otherwise the requirement that there always be an applicable method doesn't is unmotivated. The matter was certainly clearer in CLtL2, p.852, where the requirement was explicit. I don't know why that text was dropped, but I don't remember any late X3J13 action affecting it so the change must have been editorial (whether or not intentional). > The draft says (p 8-10) > > If :PRINT-FUNCTION [is] not supplied ... then a default printing > function is provided for the structure that prints out all its slots > using #S syntax. > > Supplying :PRINT-FUNCTION ... is equivalent to defining an > appropriate method on the PRINT-OBJECT generic function. > > The first paragraph would seem to indicate that every structure has a > :PRINT-FUNCTION function, whether you define it or not, and thus > :PRINT-OBJECT methods on an included structure class aren't inherited. > In the second paragraph, it's not clear what "equivalent" means, as > Sandra Loosemoore has pointed out in public review comments. For one > thing, :PRINT-FUNCTION functions have different argument structure > than PRINT-OBJECT. I think this conclusion is amiss as well. If supplying a :PRINT-FUNCTION is equivalent to defining a PRINT-OBJECT method on the class, then inheritance of the method by subclasses is clearly the natural order of things. There was some sentiment on X3J13 that the crufty :PRINT-FUNCTION mechanism would better have been deprecated, but removing it would have broken lots of existing programs. Maintaining it is implementationally messy because the printer has to pass that silly level argument which the printer now handles completely internally, but otherwise the automatically-generated PRINT-OBJECT method is just a closure over the :print-function function. > This confusion will probably be rectified in the next draft, but for > now it's yet another example of how hard it is to properly integrate > new features (CLOS) and old (DEFSTRUCT). Of course, there is a completely _different_ mechanism that might be more appropriate to your needs. You can use SET-PPRINT-DISPATCH to customize the pretty printer's dispatch. As Water's writeup points out, this mechanism allows rapid changes between print setups by lambda binding *PRINT-PPRINT-DISPATCH*. Of course, some implementations might not implement this yet, or you might not be able to use print with *PRINT-PRETTY* true, or whatever. From excl-forum-distribution-owner Tue Mar 30 19:19:08 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150241>; Tue, 30 Mar 1993 19:18:55 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14046; Tue, 30 Mar 93 15:40:59 PST Received: from mayflower.merl.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA21447; Tue, 30 Mar 93 15:49:15 -0800 Received: by merl.com (4.1/SMI-4.0) id AA17516; Tue, 30 Mar 93 18:46:42 EST Date: Tue, 30 Mar 1993 18:46:42 -0500 From: osborne@merl.com (Randy Osborne) Message-Id: <9303302346.AA17516@merl.com> Organization: Mitsubishi Electric Research Laboratories, Inc. Cambridge, Massachusetts, USA To: allegro-cl@ucbvax.berkeley.edu Subject: Call for Papers Call for papers Lisp and Symbolic Computation Special Issue on Parallel Symbolic Applications Papers are solicited for a special issue of the International Journal on Lisp and Symbolic Computation (LASC) on Parallel Symbolic Applications. Submissions should provide a thorough investigation and presentation of a particular large "symbolic" application (or application family) in some language and on some machine (or machines). In this call for papers, "symbolic" refers to a whole spectrum of applications that emphasize the manipulation of symbolic data rather than arithmetic computation on numeric data. This spectrum extends far beyond obviously "symbolic" applications such as symbolic algebra systems to include any application involving dynamic data structures and dynamic, data-dependent execution patterns, typically with irregular structure. Such applications may even contain numeric computation components. Examples of problems whose solutions often include a "symbolic" component might be: * Search problems * Combinatorial optimization problems * VLSI layout, wire routing, and test generation * Simulation * Design verification and theorem proving * Program analysis and optimization * Manipulation of algebraic expressions * Case and rule based reasoning systems * Natural language processing * Parts assembly modeling, molecular modeling * Unstructured sparse graph and matrix problems The primary goal of this special issue is to contribute a stock of large applications that are well described, well understood, and easily accessible to the parallel symbolic research community. It is expected that these applications will be useful as benchmark programs (for speed and qualitative comparisons) in language, run-time system, and architecture research. A secondary goal of this special issue is to present the current state-of-the-art in languages and run-time systems for parallel symbolic computing. Each submission should describe the principle(s) of the application(s). Each paper should include a description of the application problem and a description of the sequential and parallel algorithms used to solve it. Authors should describe the application implementation, language design, language implementation, run-time system, and architecture issues and research as they see fit. For each application there should exist: 1) sample "real world" input data and associated output data 2) source code, in some common language such as Scheme, ML, Common Lisp, and C++, of at least one sequential implementation 3) source code for parallel implementation(s) 4) execution timings of sequential and parallel implementations with the data sets in (1). The timing for at least one sequential implementation must correspond to the source code given in (2). The conditions under which these timings are obtained must be fully and clearly stated (e.g. language, language implementation/compiler, run-time system/operating system, machine description and machine parameters). Papers must contain the execution timings (or a reasonable summary of such timings) described in (4) and reasonable descriptions of the input data in (1) and source codes in (2) and (especially) (3). To make the applications widely available to the research community, the input and output data for (1) and full source codes for (2) and (3) must be: * available for anonymous ftp or equivalent from the author, or * supplied to the manager of an anonymous ftp site to be designated, or * both of above. These source codes should describe "stand alone" applications, so any libraries used should be included (unless they are well known or available publicly). Such repositories should also include any further timing data as well as instructions on how to run the applications and what to time. Submissions are due 1 September 1993, with publication expected in the first quarter of 1994. Papers should be approximately 16 LASC formatted pages in length -- about 7000 words. Accepted papers will have to be submitted in LaTeX format using LASC's standard LaTeX style file (available via anonymous ftp from cs.utah.edu in pub/kluwer.sty). Authors should submit 5 copies of a full paper with abstract. Submissions should be sent to the special-issue editor: Randy Osborne Mitsubishi Electric Research Labs 201 Broadway Cambridge, Massachusetts U.S.A. 02139 osborne@merl.com FAX 617-621-7550 From excl-forum-distribution-owner Wed Mar 31 23:05:03 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150337>; Wed, 31 Mar 1993 23:04:49 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14973; Wed, 31 Mar 93 19:10:59 PST Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA05056; Wed, 31 Mar 93 19:19:12 -0800 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA20978; Wed, 31 Mar 93 19:16:23 PST Date: Wed, 31 Mar 1993 22:16:23 -0500 From: smh@franz.com (Steve Haflich) Message-Id: <9304010316.AA20978@akbar.Franz.COM> To: <@ada3.ca.boeing.com:bha@gumby.boeing.com> Class: bh Bh-Id: spr7983 Bh: append spr7983 expire Subject: Re: [spr7983] MOP programming - compile vs. load Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu [This matter has been assigned the tracking identifier "spr7983". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> ACL 4.2beta I am attempting to implement an extension to CLOS via the MOP and am having some trouble with compile versus load time execution of class metaobject methods. As background, here is a brief explanation of what I am trying to accomplish. I have a need to "surround" *every* method of an object with some body of code. It is highly desirable that the implementation mechanism is transparent as possible with respect to those methods that are surrounded. I don't believe that defining a special method metaobject is appropriate for implementing surround behavior. Anyway, not all methods of a particular generic function necessarily have the surround behavior. I also do not think that :around methods are the appropriate mechanism for implementing surround behavior. The surround behavior is more closely associated with the behavior of a particular class, not the individual methods. For class hierarchies, a "mixin" class may be a component of a class that does not have the surround behavior. Thus, in this context the methods associated with the mixin class should not have surround behavior. Therefore, I believe that defining a class metaobject is probably the most appropriate mechanism for implementing surround behavior. The class metaobject can then be used to "declare" the intention that a particular class (and therefore its methods) have surround behavior. Hmm, the implementation you describe below suggest you may be misspeaking slightly. What you seem to want is to have surround behavior on the entire effective method for generic-functions defined on one of your classes, not separately on each applicable method called by the effective method. This is a quite different thing. ... When an instance of an encapsulated class is made, its dual (the encapsulator) is also made. What is returned from the make-instance method for an encapsulated class is actually the encapsulator instance. Thus, any methods destined for the encapsulated object are actually handled by the encapsulator object. Any "surround" processing is performed by the encapsulator trampoline method, then control is passed to the real method in the encapsulated object. For gated objects, this involves obtaining a "lock" associated with the encapsulator object before calling the real method in the encapsulated object. OK, all this stuff seems to be working except for one "tiny" problem. When an encapsulated class is "compiled," it is actually instantiated (that is the encapsulated-class class metaobject is instantiated). This causes the initialize-instance method on the encapsulated-class class metaobject to be called. This is where I hook in to define the encapsulated class. The problem is, at *compile time*, certain data structures (such as the superclass of an encapsulated class) are ill defined (the superclass is a forward-referenced-class). When the "compiled" code is "loaded", this causes the class metaobject to be seemingly instantiated again (?) and initialize-instance to be called again (no, *not* reinitialize-instance). But my processing (which the first time thru at compile time did a defclass of the encapsulator class) now ends up (indirectly) invoking reinitialize-instance on the encapsulator class (since I do the defclass of the encapsulator class again as I am unable to distinguish compile time from load time execution). What I need to do (I think) is to defer my processing that is hooked into the initialize-instance method on the encapsulated-class class metaobject until *not* compile time. Note that when I *evaluate* the defclass form of the encapsulated class (instead of compile it), everything works just fine! Also, what is going on at compile and load time such that the initialize-instance method is called two times - once at compile time then again at load time? The crux of this behavior is the problem faced by compile-file, and the requirements placed on compile-file processing of DEFCLASS by CLtL2 and the dpANS. Basically, compile-file processing of a DEFCLASS at compile-file time _shouldn't_ define the class in the compiling lisp world because that could break things in the running world if a like-named class exists but is incompatible. This is no different from the behavior of DEFMETHOD in not putting the method into effect at compile time, but only later when the compiled file is loaded. On the other hand, DEFCLASS is obviously required to `define' the class because there are lots of ways the class object is needed at compile-file time. So the solution is for the DEFCLASS macroexpansion to create a new class object at compile time and secret it away in he environment the compiler maintatins to contain information about the ongoing compilation. This is no different from the behavior with DFSTRUCT, DEFTYPE, DEFMACRO, etc. So, you can't assume that the class object being manipulated at compile-file time is the same EQ object that would be operated upon if that compiled file is subsequently loaded into the same running lisp image. It isn't. To focus on your original problem, I don't have a lot of time to try to write a solution, which is a shame, because the problem is interesting. Here's just a casual comment: One thing that wasn't clear in the description of your solution was how CLOS or DEFMETHOD knows to apply the trampoline mechanism to a particular generic function. My guess you DEFGENERIC these functions to have a different metaclass? If so, then I wonder why you use the rather involved complicated encapsulator class mechanism instead of using a method on CLOS:COMPUTE-EFFECTIVE-METHOD to do the wrapping. Since COMPUTE-EFFECTIVE-METHOD receives a list of applicable methods, locking behavior could if necessary depend on the presence of a method with some particular qualifer which would be deleted before your COMPUTE-EFFECTIVE-METHOD method calls it's next method. (This is similar to defining your own method combination, but there is no way I know of for a method combination to do wrapping and delegate the rest of method combination to some other method combination, and so you'd have to duplicate all of standard method combination yourself, which is unattractive.) What I mean is something like: (defclass my-generic-function (standard-generic-function) () (:metaclass clos:funcallable-standard-class)) (defmethod clos:compute-effective-method ((gf my-generic-function) method-combination methods) (flet ((locking-qualifier-p (meth) (equal (clos:method-qualifiers meth) '(:locking)))) (if (some #'locking-qualifier-p methods) (let ((values (multiple-value-list (call-next-method gf method-combination (remove-if #'locking-qualifier-p meths))))) (apply #'values `(with-locking ,(car values)) (cdr values))) (call-next-method)))) Locking behavior depends on there being a method defined like this, but the method is never actually called: (defmethod some-gf :locking ((x one-of-my-classes))) I haven't tried running this, but I think it is portable use of the MOP. From excl-forum-distribution-owner Thu Apr 1 13:46:29 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150355>; Thu, 1 Apr 1993 13:46:14 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15731; Thu, 1 Apr 93 09:16:53 PST Received: from linus.mitre.org by ucbvax.Berkeley.EDU (5.63/1.43) id AA24279; Thu, 1 Apr 93 09:25:08 -0800 Return-Path: Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA03690; Thu, 1 Apr 93 12:25:05 -0500 Posted-Date: Thu, 01 Apr 93 12:25:02 EST Received: by thelonius.mitre.org (5.61/RCF-4C) id AA02306; Thu, 1 Apr 93 12:25:03 -0500 Message-Id: <9304011725.AA02306@thelonius.mitre.org> To: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Subject: Allegro 4.1 on a Sparc 10 Date: Thu, 1 Apr 1993 12:25:02 -0500 From: john@linus.mitre.org Howdy - I'm sending this as a bug-report as well as to the mailing list because I'm hoping to get some information from both Franz and other Allegro users. My basic question is, why isn't my Allegro code very much faster on a Sparc 10 than a Sparc 2? I'm running Allegro CL 4.1 [SPARC; R1]. The first thing to say is that a standard Allegro image cannot run on both a 10 and a non-10 (something to do with the stack location). So we installed the relevant patches, and now have an image that can run on both. To my vast disappointment, however, my system (a natural language understander) runs only marginally faster on the 10 (approximately 1.4 times faster). Now, if I remember right, a 10 is supposed to have approximately 2.5 to 3 times the cojones of a 2, measured in spec marks. Some simple, purely numeric test code that I wrote does indeed run at least 3 times faster. Even some simple, non-numeric test code (lots of consing, calls to MEMBER, EQUAL, etc.) runs about twice as fast. But my big, hairy, heavily CLOSified system just isn't that much faster. Just to make sure it wasn't the patched image, I compared the unpatched and the patched Allegro (on a Sparc 2), and there was no appreciable difference in performance. So, do any other users have any experience with 10s yet? Does Franz have any intuitions about this situation? I'd greatly appreciate any information. I imagine the mailing list as a whole would be interested as well. John Burger john@mitre.org From excl-forum-distribution-owner Thu Apr 1 16:16:42 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150180>; Thu, 1 Apr 1993 16:16:27 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15871; Thu, 1 Apr 93 12:12:31 PST Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA00425; Thu, 1 Apr 93 12:20:40 -0800 Received: by atc.boeing.com (5.57) id AA09103; Thu, 1 Apr 93 12:21:56 -0800 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Thu, 1 Apr 93 12:20 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA00707; Thu, 1 Apr 93 12:17:32 PST Received: by fritz.ata (4.1/SMI-4.1) id AA00584; Thu, 1 Apr 93 12:17:29 PST Date: Thu, 1 Apr 1993 15:17:32 -0500 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: Allegro 4.1 on a Sparc 10 To: john@linus.mitre.org Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Message-Id: <9304012017.AA00707@gumby.ata> In-Reply-To: john@linus.mitre.org's message of Thu, 01 Apr 93 12:25:02 EST <9304011725.AA02306@thelonius.mitre.org> X-Envelope-To: allegro-cl@ucbvax.berkeley.edu > Howdy - > > I'm sending this as a bug-report as well as to the mailing list > because I'm hoping to get some information from both Franz and other > Allegro users. My basic question is, why isn't my Allegro code very > much faster on a Sparc 10 than a Sparc 2? > > I'm running Allegro CL 4.1 [SPARC; R1]. The first thing to say is > that a standard Allegro image cannot run on both a 10 and a non-10 > (something to do with the stack location). So we installed the > relevant patches, and now have an image that can run on both. To my > vast disappointment, however, my system (a natural language > understander) runs only marginally faster on the 10 (approximately 1.4 > times faster). > > Now, if I remember right, a 10 is supposed to have approximately 2.5 > to 3 times the cojones of a 2, measured in spec marks. Some simple, > purely numeric test code that I wrote does indeed run at least 3 times > faster. Even some simple, non-numeric test code (lots of consing, > calls to MEMBER, EQUAL, etc.) runs about twice as fast. > > But my big, hairy, heavily CLOSified system just isn't that much > faster. Just to make sure it wasn't the patched image, I compared the > unpatched and the patched Allegro (on a Sparc 2), and there was no > appreciable difference in performance. > > So, do any other users have any experience with 10s yet? Does Franz > have any intuitions about this situation? > > I'd greatly appreciate any information. I imagine the mailing list as > a whole would be interested as well. > > John Burger > john@mitre.org > > Well, thats what the vendor says! Of course we all believe that don't we! For whatever its worth, your number of 1.4 is about what we got doing performance benchmarks with ACL 4.1 (actually ICAD). We ran *lots* of code thru the compiler and did *long* runtime checks. The compilation tests on the Sparc 10 (model 41) were approximately 1.5 - 1.75 times faster than a Sparc 2. The runtime tests were a little slower 1.5 - 1.6 times faster than a Sparc 2. Interesting to note that most of our runtime tests were CPU limited. Sun even put a special piece of H/W on to see what was going on because they didn't believe the numbers either. And sure enough the application was CPU limited. The paging behavior was quite well behaved. We ran with 64Mbytes of real memory and 400Mbytes of swap space. With 128Mbytes of real memory on the Sparc 10 the performance numbers did not appreciably change. Finally, running the Gabriel benchmarks ran a little better - 1.75 - 2.2 times as fast as a Sparc 2. I wouldn't get too nit picky about the numbers. Benchmarks are a black art anyways - there are just too many independent variables. Its qualitatitive at best. ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com Seattle, Wa. From excl-forum-distribution-owner Fri Apr 2 03:55:21 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150207>; Fri, 2 Apr 1993 03:55:08 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA16177; Thu, 1 Apr 93 23:14:16 PST Received: from [133.2.1.1] by ucbvax.Berkeley.EDU (5.63/1.43) id AA24603; Thu, 1 Apr 93 23:22:24 -0800 Received: by green-hill.csrl.aoyama.ac.jp (4.1/6.5J.alpha2) id AA28900; Fri, 2 Apr 93 16:20:57 JST Date: Fri, 2 Apr 1993 02:20:57 -0500 From: Masayuki Ida Return-Path: Message-Id: <9304020720.AA28900@green-hill.csrl.aoyama.ac.jp> To: john@linus.mitre.org Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu, ida@csrl.aoyama.ac.jp In-Reply-To: john@linus.mitre.org's message of Thu, 01 Apr 93 12:25:02 EST <9304011725.AA02306@thelonius.mitre.org> Subject: Allegro 4.1 on a Sparc 10 Organization: Computer Science Research Lab., Aoyama Gakuin Univ. Reply-To: ida@csrl.aoyama.ac.jp >>Date: Thu, 01 Apr 93 12:25:02 EST >>From: john@linus.mitre.org >> >>I'm sending this as a bug-report as well as to the mailing list >>because I'm hoping to get some information from both Franz and other >>Allegro users. My basic question is, why isn't my Allegro code very >>much faster on a Sparc 10 than a Sparc 2? This is really what I am wondering. >>Now, if I remember right, a 10 is supposed to have approximately 2.5 >>to 3 times the cojones of a 2, measured in spec marks. Some simple, >>purely numeric test code that I wrote does indeed run at least 3 times >>faster. Even some simple, non-numeric test code (lots of consing, >>calls to MEMBER, EQUAL, etc.) runs about twice as fast. >> ... >>So, do any other users have any experience with 10s yet? Does Franz >>have any intuitions about this situation? >> >>I'd greatly appreciate any information. I imagine the mailing list as >>a whole would be interested as well. We had no SS2. We are now using SS10 from Oct. 92, as a kind of replacement from 4/260. So I don't have any info and I really want to know the reason. Rumor says recompilation of every library of C codes using Sun's new C compiler (not allegro level lib) is needed to get the full functions of SuperSPARC. ... but I am not sure. I don't like to purchase Sun C compiler to run Allegro fast. Masa Ida From excl-forum-distribution-owner Fri Apr 2 14:23:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150225>; Fri, 2 Apr 1993 14:23:29 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA17012; Fri, 2 Apr 93 09:48:38 PST Received: from [128.95.181.7] by ucbvax.Berkeley.EDU (5.63/1.43) id AA15869; Fri, 2 Apr 93 09:56:57 -0800 Date: Fri, 2 Apr 1993 12:48:48 -0500 From: IRA@merry.radonc.washington.edu (Ira Kalet) Message-Id: <930402094848.20200221@merry.radonc.washington.edu> Subject: Allegro 4.1 on a Sparc 10 and other benchmark fables To: allegro-cl@ucbvax.berkeley.edu X-Vmsmail-To: SMTP%"allegro-cl@ucbvax.berkeley.edu" I read with interest the comments about real life applications running not as fast as expected on a Sparc 10 vs a Sparc 2. We have a complex application that involves interactive 3-d graphics, medical image display, a small widget set and user interface kit that I wrote instead of using CLIM (it uses CLX). As we were about to purchase 6 new workstations, and we had gone to extremes to make our code portable (easier in CL than most other languages), we benchmarked our code on a variety of systems, including the following: DEC5000/240 Ultrix IBM RS6000/340 AIX Silicon Graphics Indigo XS24 Hewlett-Packard 720 HP-UX 8.07 Hewlett-Packard 735 HP-UX 9.0 (with a little help from Duane) Sun Sparcstation 10/30 with GT graphics, SunOS 4.1 (the HP systems had CRX 8 bit graphics) The Sparc 10, the SGI Indigo and the HP 720 were all about the same level of performance, the DEC5000 was comparable on most operations involving moving large amounts of data (pixmaps, arrays, etc.), and the DEC and IBM were a lot slower in the most compute intensive parts. The HP 735 was about twice as fast as the nearest competitor. The timings were all wall clock timings since the application is pretty interactive, and we didn't have time to sete up something more elaborate. Particular points included: The Sun was better at reading in large (25MB) data sets than any of the others, the IBM was the worst in pretty all aspects. We also ran a floating point intensive Pascal program on all the above systems, and got big surprises: the DEC5000/240 outperformed the Sparc 10 and the IBM by significant margins. This flatly disagrees with the Spec FP and LINPACK numbers. I believe our results reflect compiler technology since our program is big and good optimization makes a difference. On this HP came out on top and SGI second. We saw a factor of 2 to 4 difference from what would be predicted by the "standard" benchmarks. We ordered 3 HP 735's and 3 HP 715's. Benchmarking is indeed a black art but if you run your own code you can trust that the numbers are real. Aside from HP-UX 9.0 we had no problem installing Allegro CL on all the machines, we made no modifications to any of our code, and all the vendors we worked with were helpful, friendly and supportive (most of all Franz, of course). Oh, yes, the comparision with Sparc 2. We ran the Pascal program on our Sun 4/470 and it ran about 3 times faster on the Sparc 10 as on the 4/470. I just ran our wall clock lisp benchmarks also, and got varying results. On file i/o the Sparc 10 is more than twice as fast. On the interactive graphics, I get a factor of more than 2 on some operations, a little less than 2 on others, and on one - computing a new image with a new linear gray map, the 4/470 and Sparc 10 take the same time, in fact the 4/470 is a little faster. Go figure. Ira Kalet Radiation Oncology Dept. RC-08 University of Washington Seattle, WA 98195 From excl-forum-distribution-owner Fri Apr 2 20:59:53 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150183>; Fri, 2 Apr 1993 20:59:51 -0500 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA17409; Fri, 2 Apr 93 16:26:28 PST Received: from [192.132.95.84] by ucbvax.Berkeley.EDU (5.63/1.43) id AA25363; Fri, 2 Apr 93 16:34:24 -0800 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA03483; Fri, 2 Apr 93 16:30:16 PST Received: by clay.Franz.COM (4.0/FI-2.0) id AA15579; Fri, 2 Apr 93 16:31:36 PST Date: Fri, 2 Apr 1993 19:31:36 -0500 From: duane@franz.com (Duane Rettig) Message-Id: <9304030031.AA15579@clay.Franz.COM> To: john@linus.mitre.org Class: bh Bh-Id: spr8043 Bh: append spr8043 customer Subject: Re: [spr8043] Allegro 4.1 on a Sparc 10 Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu, rek@franz.com, hanoch@franz.com, stu@franz.com Your problem report has been assigned tracking id spr8043. Please use it in the subject line of any correspondences regarding your problem report. >> I'm sending this as a bug-report as well as to the mailing list >> because I'm hoping to get some information from both Franz and other >> Allegro users. My basic question is, why isn't my Allegro code very >> much faster on a Sparc 10 than a Sparc 2? >> >> I'm running Allegro CL 4.1 [SPARC; R1]. The first thing to say is >> that a standard Allegro image cannot run on both a 10 and a non-10 >> (something to do with the stack location). So we installed the >> relevant patches, and now have an image that can run on both. To my >> vast disappointment, however, my system (a natural language >> understander) runs only marginally faster on the 10 (approximately 1.4 >> times faster). >> >> Now, if I remember right, a 10 is supposed to have approximately 2.5 >> to 3 times the cojones of a 2, measured in spec marks. Some simple, >> purely numeric test code that I wrote does indeed run at least 3 times >> faster. Even some simple, non-numeric test code (lots of consing, >> calls to MEMBER, EQUAL, etc.) runs about twice as fast. >> >> But my big, hairy, heavily CLOSified system just isn't that much >> faster. Just to make sure it wasn't the patched image, I compared the >> unpatched and the patched Allegro (on a Sparc 2), and there was no >> appreciable difference in performance. >> >> So, do any other users have any experience with 10s yet? Does Franz >> have any intuitions about this situation? >> >> I'd greatly appreciate any information. I imagine the mailing list as >> a whole would be interested as well. My thanks to those others who have submitted answers to your question. An oversimplified encapsulation of what they stated is "your mileage may vary." Of course, we can't just leave it at that, and we have been doing some research into this phenomenon. History: When we first heard of this problem from another customer in November, we asked Sun about it. Sun loaned us a Sparc 10 Model 30 for a month, since we had none of our own to run any experiments on. We gathered some initial findings, some of which resulted in some immediate speedups in development versions of Allegro CL. At the end of the month, we decided that we should purchse a Sparc 10 of our own. We have now received this Sparc 10/30, and will continue to work on characterizing and speeding up the lisp so that it scales better on the 10. Where improvements to the lisp are possible, I have beeen working in some cases on Allegro CL 4.1, but most of my effort has been spent in the 4.2 development sources, since it has the best chance of significant improvements. Allegro CL 4.2 has a different compiler that does a better job of register allocation and allows such features as unboxed 32-bit integers, functions that don't link in a stack frame, and tail-call elimination (very useful for this study). Allegro CL 4.2 also has 30-bit fixnums (although the currently released 4.2.beta.0 still has 29-bit fixnums) which provides advantages for array accessing. In all cases that I refer to Allegro CL 4.2 below, I am referring to the current development version, and not to any released version (as of yet). Initial Findings: Certain aspects of the Sparc 10 do not scale up from the Sparc 2 as well as others. The cpu itself is certainly fast, but so far we have found several areas which affect lisp performance: 1. Register-window saving/restoring: The 10/30 seems to take longer to save out its register-window set than the sparc 2. Thus, if the program you are running does deep recursion, windows will be saved more, and the total run time will increase. In Allegro CL, the deepest recursion tendency is in CLOS and closified streams code. I spent some time tuning the streams code with the specific idea in mind that the code should be "flattened out" using tail-call-merging and functions that do not link in a stack frame (i.e. functions that do not use the "save" and "restore" instructions). There is still some work that needs to be done in this area, and since we did not get long with the loaner Sparc 10, we could not do accurate measurements of how well the optimizations did (bear in mind that the same optimizations are also likely to speed up operations on the sparc2 as well!). 2. Fixed-point multiply/divide instructions: The Sparc Version 8 architecture allows for a hardware multiply (smul) and divide (sdiv) instruction to be implemented. Additionally, the same instruction decodes when executed on a sparc 2 cause an unimplemented-instruction trap, at which point the operating system does the multiply/divide and returns as if the instruction were really implemented. This emulation is both a blessing and a curse: I don't yet know how to tell for sure whether a particular sparc chip has the multiply/divide hardware or not. We perform integer multiplies by doing a primitive call to an assembler function whose address is in a table. This function either calls the software version of the multiply, which is about 35 instructions, or it executes the hardware multiply instruction (and a setup instruction) which takes two instructions. Incidentally, we cannot just move to the new hardware multiply, because if a sparc2 "executes" this instruction, it takes several hundred instructions to take the trap, go through the software multiply, and return. Thus, we will need to figure out how to determine at lisp startup time exactly whether the ccurrent machine on which the lisp is running has the hardware multiply or not. 3. Floating-point conversion: I did not get very far with this one in my experimentation, because it was discovered fairly late in the loaner period. There _seems_ to be some lack of scalability when you mix single-float and double-float code. I have not had a chance yet to look at this deeper. If you have any code that simply declares numbers as "float" instead of single-float or double-float, or if you do a double-float calculation on a single-float constant, you may end up going through some data type conversion. This problem has plagued us enough times that we have added a (muffle-able) warning that checks against any float declarations (as opposed to single-float or double-float). 4. Memory latency: There are differences in memory latency between the sparc 2, the 10/30 and the 10/41. This affects how the system performs in the presence of "interlocked" reads (i.e. read-from memory into a register, and then use that register to read again from memory). Allegro CL 4.2 has slightly better interlocking characteristics than 4.1, although there are still some things we can do. 5. PSO: In addition to memory latency, there is another memory issue that affects performance. The Sparc version 8 architecture manual defines a PSO bit, which may or may not be implemeted. The older sparcs all implement TSO, or Total Store Ordering, in which there is conceptually no data cache between your virtual address space and your real address space. When your program writes to a data location, every processor (including the instruction-fetch mechanism) will see the data you wrote out, and is not in danger of seeing the old data. Those sparcs that implement PSO, or Partial Store Ordering, are really providing what has become the more traditional write-through-cache technique. This of course would have ramifications on lisp, because we would need to flush the cache whenever a code vector moves. On the other hand, we have had quite a bit of experience with other architectures that only provide write-through cache, so this would not be a problem. The TSO concept is inherently slower than PSO, because the hardware is forced to perform checks to guarantee synchronicity. PSO is faster, but also more dangerous, since some programs, especially those which rely on multiple CPU execution or on executing code in data space, would need modification in order to run in PSO mode. I understand that the only sparc that implements PSO is the chip that is in the model 41. I am told, though, that the PSO bit cannot be turned on by a user, and there are not yet any plans to allow specific programs to turn on this bit on (on a per-process basis). I have tried to provide you with some of the insights we have obtained over the past few months. I hope these help you to reconcile the actual performance gains you see with the expectations you were given. Please feel free to ask me more questions, or to make suggestions. Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Mon Apr 5 17:11:03 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150178>; Mon, 5 Apr 1993 17:10:57 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20017; Mon, 5 Apr 93 13:08:30 PDT Received: from cleo.cs.umass.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA20555; Mon, 5 Apr 93 13:16:50 -0700 Received: from stimpy.cs.umass.edu by cleo.cs.umass.edu (6.65/Ultrix2.0-B) id AA11303; Mon, 5 Apr 1993 16:09:25 -0400 Received: by stimpy.cs.umass.edu (5.57/Ultrix3.0-C) id AA19950; Mon, 5 Apr 93 16:17:53 -0400 Date: Mon, 5 Apr 1993 16:17:53 -0400 From: jmccarth%stimpy@cs.umass.edu (Joe McCarthy) Message-Id: <9304052017.AA19950@stimpy.cs.umass.edu> To: allegro-cl@ucbvax.berkeley.edu Cc: feng@lorax.cs.umass.edu Subject: Tracing SETF on structures Reply-To: JMCCARTHY@cs.umass.edu Howdy, We have a structure defined by (DEFSTRUCT NP-RECORD ... RELATED-NP ...) and we would like to be able to set up tracing so that we can see whenever the RELATED-NP field of an NP-RECORD is changed, i.e.,, whenever a form such as (SETF (NP-RECORD-RELATED-NP ) ) is executed. In Section 5.4 of the Allegro CL Common Lisp User Guide (Version 4.1, March 1992, page 5-29), the following example is given: (trace ((method (setf slot-1) (t baz)))) (trace ((method foo :before (integer)))) (trace ((method foo :after (integer)))) Unfortunately, I am unable to interpret how I can use this example to set up the tracing I want. In particular, I'm not sure what SLOT-1, and (T BAZ) mean. Taking a guess at a mapping, I tried the following (trace ((method (setf related-np) (t np-record)))) but this yielded: Error: (METHOD (SETF RELATED-NP) (T NP-RECORD)) does not have a function definition Can anyone help me figure out how to set up the desired tracing? Thanks, in advance, for any assistance. Joe. From excl-forum-distribution-owner Mon Apr 5 18:29:46 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150180>; Mon, 5 Apr 1993 18:29:41 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20049; Mon, 5 Apr 93 14:39:35 PDT Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA21274; Mon, 5 Apr 93 14:47:30 -0700 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA00520; Mon, 5 Apr 93 14:44:22 PDT Date: Mon, 5 Apr 1993 17:44:22 -0400 From: smh@franz.com (Steve Haflich) Message-Id: <9304052144.AA00520@akbar.Franz.COM> To: JMCCARTHY@cs.umass.edu Class: bh Bh-Id: spr8063 Bh: append spr8063 expire Subject: Re: [spr8063] Tracing SETF on structures Cc: bugs@franz.com, feng@lorax.cs.umass.edu, allegro-cl@ucbvax.berkeley.edu [This matter has been assigned the tracking identifier "spr8063". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] From: jmccarth%stimpy@cs.umass.edu (Joe McCarthy) We have a structure defined by (DEFSTRUCT NP-RECORD ... RELATED-NP ...) and we would like to be able to set up tracing so that we can see whenever the RELATED-NP field of an NP-RECORD is changed, i.e.,, whenever a form such as (SETF (NP-RECORD-RELATED-NP ) ) is executed. In Section 5.4 of the Allegro CL Common Lisp User Guide (Version 4.1, March 1992, page 5-29), the following example is given: (trace ((method (setf slot-1) (t baz)))) (trace ((method foo :before (integer)))) (trace ((method foo :after (integer)))) Unfortunately, I am unable to interpret how I can use this example to set up the tracing I want. In particular, I'm not sure what SLOT-1, and (T BAZ) mean. Taking a guess at a mapping, I tried the following (trace ((method (setf related-np) (t np-record)))) but this yielded: Error: (METHOD (SETF RELATED-NP) (T NP-RECORD)) does not have a function definition Can anyone help me figure out how to set up the desired tracing? The short answer is that you can't. The only thing that can be traced is a function. The language does not specify _how_ defstruct slots are interfaced to the SETF macro. Although defining CLOS-like setf functions with names like (SETF SLOT-1) would be one plausible implementation, another much more traditional implementation is to define them as if by DEFSETF. This means that setf expansions of defstruct slot accessor functions in most implementations macroexpand into some sort of imlementation-dependent code. This is not much different from the traditional inlining of the slot accessors themselves on most implementations, except that since the accessor is a real function with a real name, you can prevent the inlining by declaring or proclaiming it NOTINLINE. But defstruct settors aren't functions and don't have names, so you can't make declaratons on nor trace them. The only thing you can do would be to define the slot accessors under different names. Macrology would make this more palatable, but the basic idea would be: (defstruct (foo (:conc-name :.foo-)) slot-1) (defun foo-slot-1 (x) (.foo-slot-1 x)) (defun (setf foo-slot-1) (v x) (setf (.foo-slot-1 x) v)) Since the `public' names FOO-SLOT-1 and (SETF FOO-SLOT-1) are now real functions (with the corresponding runtime overhead) they can reliably be traced. The syntax for the setf function is (TRACE ((SETF FOO-SLOT-1))). From excl-forum-distribution-owner Mon Apr 5 19:37:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150180>; Mon, 5 Apr 1993 19:37:16 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA20087; Mon, 5 Apr 93 15:44:03 PDT Received: from lug.cs.brandeis.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA21665; Mon, 5 Apr 93 15:52:00 -0700 Received: from lug (localhost) by lug.cs.brandeis.edu (5.0/SMI-SVR4) id AA01657; Mon, 5 Apr 93 18:47:23 EDT Message-Id: <9304052247.AA01657@lug.cs.brandeis.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: Re: Tracing SETF on structures In-Reply-To: Your message of "Mon, 05 Apr 1993 16:17:53 EDT." <9304052017.AA19950@stimpy.cs.umass.edu> Date: Mon, 5 Apr 1993 18:47:23 -0400 From: "T.S. Waterman" Content-Length: 1720 >From: jmccarth%stimpy@cs.umass.edu (Joe McCarthy) >Subject: Tracing SETF on structures >is executed. In Section 5.4 of the Allegro CL Common Lisp User Guide >(Version 4.1, March 1992, page 5-29), the following example is given: > > (trace ((method (setf slot-1) (t baz)))) > (trace ((method foo :before (integer)))) > (trace ((method foo :after (integer)))) > >Unfortunately, I am unable to interpret how I can use this example to >set up the tracing I want. In particular, I'm not sure what SLOT-1, >and (T BAZ) mean. > >Taking a guess at a mapping, I tried the following > > (trace ((method (setf related-np) (t np-record)))) > >but this yielded: > >Error: (METHOD (SETF RELATED-NP) (T NP-RECORD)) does not have a function > definition > >Can anyone help me figure out how to set up the desired tracing? Hi Joe, This is a problem related to the the naming of SETF methods under CLOS in allegro. The short answer is that the call to trace is (trace ((method (setf np-record-related-np) (t np-record)))) instead of (as you had) > (trace ((method (setf related-np) (t np-record)))) The explanation is short, too: SETF functions (see CLtL2, sec 7.1) are a list whose car is SETF. In allegro, SETF functions seem to be treated as method specifiers on the generic SETF function. When DEFSTRUCT creates a slot-reader function, such as NP-RECORD-RELATED-NP (a function of 1 arg of type NP-RECORD) it automatically creates a slot-writer function, (SETF NP-RECORD-RELATED-NP), which will take 2 arguments: the new value, and an NP-RECORD. The specification for tracing methods is ((METHOD method-name) arg-type-list) which here becomes ((method (setf NP-RECORD-RELATED-NP)) (T NP-RECORD)) --ts From excl-forum-distribution-owner Wed Apr 7 15:25:45 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150188>; Wed, 7 Apr 1993 15:25:35 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA21719; Wed, 7 Apr 93 11:35:05 PDT Received: from darkstar.isi.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA12967; Wed, 7 Apr 93 11:43:22 -0700 Received: from hpai08.isi.edu by darkstar.isi.edu (5.65c/5.61+local-11) id ; Wed, 7 Apr 1993 11:40:49 -0700 Message-Id: <199304071840.AA18002@darkstar.isi.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: Allegro CL\PC Reply-To: allard@isi.edu Date: Wed, 7 Apr 1993 14:50:21 -0400 From: Dennis Allard (310-399-4740) Anyone have experience yet with the PC version of Allegro? I am thinking of acquiring it and porting our AP5 spec language extension to Lisp to it. Is it CLtL edition 1 or edition 2 compatible? Is its CLOS implementation up to date? Is it buggy? Is its garbage collector good? Does it do ephemeral garbage collection? How good is its windows interface? How usable is its runtime packager? Does it run fast enough on a 486-DX33? Overall, are you as comfortable with it as with other mature Common Lisps? Dennis Allard allard@isi.edu From excl-forum-distribution-owner Fri Apr 9 13:44:51 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150223>; Fri, 9 Apr 1993 13:44:38 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00245; Fri, 9 Apr 93 10:00:55 PDT Received: from mammoth.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA00674; Fri, 9 Apr 93 10:09:17 -0700 Received: from hyper.franz.com by mammoth.Berkeley.EDU (5.61/1.37) id AA03846; Fri, 9 Apr 93 09:10:52 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA20341; Fri, 9 Apr 93 09:09:06 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA12316; Fri, 9 Apr 93 09:09:05 PDT Message-Id: <9304091609.AA12316@sole.Franz.COM> To: allegro-cl@ucbvax.berkeley.edu Subject: new release of emacs-lisp interface to support epoch 4.2 Date: Fri, 9 Apr 1993 12:09:04 -0400 From: Kevin Layer Content-Length: 4368 Version 2.0.4 of Franz Inc.'s GNU Emacs-Allegro CL interface is now released. There are misc fixes (ChangeLog below from 2.0.1, the last public release) and the following new versions of emacs supported: - GNU Emacs 18.59 - Epoch 4.2 If you want to get and install this new version, grab /vendor/franz/emacs/emacs-lisp-2.0.4.tar.Z from ftp.uu.net (355265 bytes) and uncompress and extract the resulting tar file, which will create an `fi' directory in the place it is extracted. This new `fi' directory is a replacement for the one you are currently using EXCEPT FOR `fi/manual', which is NOT contained in the above .tar.Z file. So, the steps to install are: 1. uncompress, `tar x', 2. move fi/manual directory to new fi directory, and 3. replace old fi directory with new one. If you have questions or problems, send mail to bugs@franz.com. ----- Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 =============================================================================== public release 2.0.4 =============================================================================== Fri Apr 9 08:09:23 1993 Kevin Layer (layer@sole) * subproc.el: properly string-match $ for env variabie substitution Tue Mar 23 10:08:35 1993 Kevin Layer (layer@ice) * Makefile: testit rule * UserGuide.n: update * modes.el: move fi:in-package-regexp and fi:default-in-package-regexp to this file; set comment-column only when unbound; >>> fi:define-emacs-lisp-mode, default is `t'. * indent.el: change defclass indent spec * keys.el: comment * utils.el: fix fi::explode * subproc.el: fix directory tracking for relative pathnames * site-init.el: new variable fi::load-subprocess-files (default `t'). * clman.el: totally revamped (uses OBLIST.el now) =============================================================================== public release 2.0.3 (with ACL 4.1 on the HP700) =============================================================================== Mon Dec 14 17:30:28 1992 Kevin Layer (layer@ice) >>> * shell.el: put fi:shell-mode-bang under control of variable, >>> turned off by default: fi:shell-mode-use-history * subproc.el: for the hp700: don't assume `rsh' is there, check for `remsh' first. Also, `localhost' doesn't exist so default to (system-name). * utils.el: new function fi::command-exists-p Thu Dec 10 06:01:08 1992 Kevin Layer (layer@ice) * rlogin.el: new function: fi:rlogin-new-user =============================================================================== public release 2.0.2 (with ACL 4.2 beta under CLIM 2.0 beta) =============================================================================== Mon Oct 5 08:43:27 1992 Kevin Layer (layer@ice) * clman.el: allow symbols from different packages to be retrieved Fri Oct 2 09:08:06 1992 Kevin Layer (layer@ice) * leep.el: hack for epoch 4.2 Thu Sep 24 17:58:38 1992 Kevin Layer (layer@ice) * indent.el: handle named-function Thu Sep 17 10:46:30 1992 Kevin Layer (layer@ice) * indent.el: make auto-file-mode in #||# comments work like indented text mode. * site-init.el: version 2.0.2 * keys.el: use only the first 128 entries in keymap (for Epoch 4.2) * changes.el: pass fi:emacs-to-lisp-transaction-directory to scm::list-changed-definitions * lze.el: pass fi:emacs-to-lisp-transaction-directory to evaluation request Wed Aug 19 07:14:19 1992 Kevin Layer (layer@ice) * changes.el: use find-backup-file-name instead of make-backup-file-name. >>> * shell.el: fi:shell-mode-bang that expands !$ * ring.el: added fi:pop-input-last-word (for new shell-mode ! command) Tue Aug 4 15:49:10 1992 Kevin Layer (layer@ice) * Doc.el: member-equal -> fi:member-equal * utils.el: added fi:member-equal * keys.el: use (current-global-map) instead of variable global-map * filec.el: replace-match for file completion only if search successful Thu Jul 23 15:06:32 1992 Kevin Layer (layer@ice) * lze.el: don't echo results in minibuffer if fi:echo-evals-from-buffer-in-listener-p is non-nil Wed Jul 22 11:34:56 1992 Kevin Layer (layer@ice) >>> * filec.el: implement filename abbreviations, where something like /foo/bar/baz could expand to /foobar/bartab/bazmaster. From excl-forum-distribution-owner Tue Apr 13 20:36:32 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Tue, 13 Apr 1993 20:36:25 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA05546; Tue, 13 Apr 93 16:47:29 PDT Received: from cayuga.cs.rochester.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA18964; Tue, 13 Apr 93 16:55:45 -0700 Received: from alabaster.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA08213; Tue, 13 Apr 93 19:53:07 -0400 Received: by alabaster.cs.rochester.edu (4.1/x) id AA05445; Tue, 13 Apr 93 19:53:06 EDT Date: Tue, 13 Apr 1993 19:53:06 -0400 From: miller@cs.rochester.edu Message-Id: <9304132353.AA05445@alabaster.cs.rochester.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: indenting new macros (code indenting via pretty-printer) I know about fi:lisp-indent-hook, but I'm looking to modify the code generated by the "not-so-pretty" printer, e.g. (with-open-file (stream ...) (write '(defun foo (bletch) (when *foo* (let*-non-null ...))) :stream stream :escape t :pretty t)) where let*-non-null is a locally defined macro. Come to think about it, looks like none of the macros (defun, let) get indented right; so maybe the answer to this is to write my own code pretty-printer :-(. Well, nobody dies, it's just hard to read ;-) Thanks for any pointers/clues. Brad Miller miller@cs.rochester.edu From excl-forum-distribution-owner Wed Apr 14 13:30:09 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Wed, 14 Apr 1993 13:29:57 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06253; Wed, 14 Apr 93 09:28:13 PDT Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA27451; Wed, 14 Apr 93 09:36:38 -0700 Received: by atc.boeing.com (5.57) id AA28515; Wed, 14 Apr 93 09:40:29 -0700 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Wed, 14 Apr 93 09:36 PST Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA11929; Wed, 14 Apr 93 09:36:13 PDT Received: by fritz.ata (4.1/SMI-4.1) id AA05005; Wed, 14 Apr 93 09:36:08 PDT Date: Wed, 14 Apr 1993 12:36:13 -0400 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: indenting new macros (code indenting via pretty-printer) To: miller@cs.rochester.edu Cc: allegro-cl@ucbvax.berkeley.edu Message-Id: <9304141636.AA11929@gumby.ata> In-Reply-To: miller@cs.rochester.edu's message of Tue, 13 Apr 93 19:53:06 EDT <9304132353.AA05445@alabaster.cs.rochester.edu> X-Envelope-To: allegro-cl@ucbvax.berkeley.edu > I know about fi:lisp-indent-hook, but I'm looking to modify the code > generated by the "not-so-pretty" printer, e.g. > > (with-open-file (stream ...) > (write '(defun foo (bletch) > (when *foo* > (let*-non-null ...))) > :stream stream > :escape t > :pretty t)) > > where let*-non-null is a locally defined macro. Come to think about it, > looks like none of the macros (defun, let) get indented right; so maybe > the answer to this is to write my own code pretty-printer :-(. Well, nobody > dies, it's just hard to read ;-) > > Thanks for any pointers/clues. > > Brad Miller > miller@cs.rochester.edu Have you tried pprint and friends? Here is something that I hacked together to pretty print CMU defsystem forms for a defsystem editor that I hacked together in CLIM. Just arrange to have the form pretty printed to you open stream. For defun and other lisp stuff pprint should do the trick if you get it setup correctly. I always wanted a pretty printer that worked on the ASCII source code rather than the Lisp list data structure. Preserves case and comments you know. Something like the ACL indent region stuff in GNU Emacs but the ability to get the output to a file. One could do this with appropriate GNU Emacs Lisp code and even arrange to use GNU Emacs as a batch indentation program - just some SMOPS. Seems as if this would be a generally useful extension to the fi stuff - eh Franz? Anyways, here is the pprint code: ================================================================================ ;;; Pretty print defsystem forms using CL pprint facility. ;;; This *has* to be done in a fixed pitch font to work correctly. (defun pprint-defsystem (form &optional (stream *standard-output*)) (let ((*standard-output* stream)) (pprint-logical-block (nil form :prefix "(" :suffix ")") ;; defsystem (write (pprint-pop)) (pprint-exit-if-list-exhausted) (write-char #\space) ;; (write (pprint-pop)) (pprint-exit-if-list-exhausted) (pprint-indent :block 1) (pprint-newline :mandatory) ;; system keyword/value pairs... (pprint-component1 (cddr form)) ))) (defun pprint-components (form &optional (stream *standard-output*)) (let ((*standard-output* stream)) ;; We are passed a list of component specifications. ;; Print each component specification in the list as a block. (pprint-logical-block (nil form :prefix "(" :suffix ")") (loop do (pprint-component (pprint-pop)) ;; No more components to process? (pprint-exit-if-list-exhausted) ;; Each component list starts on a new line. (pprint-newline :mandatory))))) (defun pprint-component (form &optional (stream *standard-output*)) (let ((*standard-output* stream)) ;; Each component specification is a list of keyword/value pairs. ;; Print pairs in a block. (pprint-logical-block (nil form :prefix "(" :suffix ")") (pprint-component1 form stream)))) (defun pprint-component1 (form &optional (stream *standard-output*)) (let ((*standard-output* stream)) (pprint-logical-block (nil form) (loop with key with value do ;; Keyword... (setf key (pprint-pop)) (write key) (pprint-exit-if-list-exhausted) ;in case malformed... (write-char #\space) ;; Value... (setf value (pprint-pop)) (if (eq key :components) ;; Print components list... (pprint-components value) (write value)) ;; Any more keyword/value pairs to process? (pprint-exit-if-list-exhausted) ;; Each keyword/value pair appears on a new line. (pprint-newline :mandatory))))) ;;; ---------------------------------------------------------------------- ;;; A test of the pretty printer... (defun pptest () (pprint-defsystem '(mk:defsystem foo :source-pathname "abc" :binary-pathname "def" :depends-on (a b c) :components ((:file "abc" :source-pathname "abc" :binary-pathname "def" :package mk :components ((:file "xyz" :source-pathname "def" :binary-pathname "xyz" :package mk) (:file "nnn" :source-pathname "111" :package ids))) (:file "def" :source-pathname "def" :binary-pathname "def" :components ((:file "nnnxyz" :source-pathname "nnndef" :binary-pathname "nnnxyz" :package mk) (:file "nnn" :source-pathname "111" :package ids)) :package mk))))) ================================================================================ ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com P.O. Box 3707 M.S. 6A-PX Seattle, Wa. 98124-2207 From excl-forum-distribution-owner Wed Apr 14 14:14:12 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150188>; Wed, 14 Apr 1993 14:14:07 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06297; Wed, 14 Apr 93 09:55:36 PDT Received: from cayuga.cs.rochester.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA28480; Wed, 14 Apr 93 10:03:51 -0700 Received: from alabaster.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA11632; Wed, 14 Apr 93 13:01:10 -0400 Received: by alabaster.cs.rochester.edu (4.1/x) id AA05660; Wed, 14 Apr 93 13:01:09 EDT Date: Wed, 14 Apr 1993 13:01:09 -0400 From: miller@cs.rochester.edu Message-Id: <9304141701.AA05660@alabaster.cs.rochester.edu> To: @ada3.ca.boeing.com:bha@gumby.boeing.com Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: bha's message of Wed, 14 Apr 93 09:36:13 PDT <9304141636.AA11929@gumby.ata> Subject: indenting new macros (code indenting via pretty-printer) > Date: Wed, 14 Apr 93 09:36:13 PDT > From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Thanks for the code! Yes, I was looking with great trepidation on the pprint chapter of cltl/2, and hoped there was something simple already 'out there' for standard lisp code with mild work for new macros... esp. given the examples for "pprint-defun" and "pprint-let"... and additions weren't intuitively obvious. Your example code should help me there! Thanks again! From excl-forum-distribution-owner Thu Apr 15 09:05:04 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Thu, 15 Apr 1993 09:04:59 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07104; Thu, 15 Apr 93 04:54:20 PDT Received: from uni-sb.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA10857; Thu, 15 Apr 93 05:02:04 -0700 Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930331) id AA06391; Thu, 15 Apr 93 14:00:09 +0200 Received: from asl-sun3.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA20493; Thu, 15 Apr 93 14:02:55 +0200 Date: Thu, 15 Apr 1993 08:05:07 -0400 Message-Id: <9304151205.AA16922@asl-sun3.dfki.uni-sb.de> Received: by asl-sun3.dfki.uni-sb.de; Thu, 15 Apr 93 14:05:07 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: oe@dfki.uni-sb.de (Stephan Oepen) To: allegro-cl@ucbvax.berkeley.edu Cc: smh@franz.com, bugs@franz.com Subject: [smh@Franz.COM: Re: [spr7955] named pipes question] Reply-To: oe@dfki.uni-sb.de i am forwarding this to the `allegro-cl' mailing list to get comments from other common-lisp users. many thanx to Steve Haflic for the detailed explanation. however, i come to think that the topic deserves further discussion in the light of the forthcoming ansi `standard'. i still do not fully understand why common-lisp implementations on systems with fifos as `ordinary' file system objects shall in principle be unable to handle the synchronization problems on named pipes (and similar `communication lines', e.g. ttys) in general one could think of two possible setups: (1) open() (from inside lisp) on fifos blocks until both sides of the pipe are connected to some process (in the appropriate direction). (2) open() immediately returns but calls to read() or write() will block until the associated stream is `fully connected'. from the Allegro CL (on Unix) implementation point of view i see the point that in a multi-processing image blocking system calls _are_ a serious problem. moreover, reading the open(2) man page gives the impression that actually there is no way to call open(2) non-blocking for writing on fifos without getting an error (instead of a file descriptor |:-) as long as nobody is reading from the other end. --- hence, option (2) from above seems to be out (and, anyhow, i think (1) should be preferred). so, if blocking system calls in a multi-processing image are a hassle (which i understand), yes, option (1) definitely requires active polling. only, why do i have to do that work myself? i would probably expect either a decent common-lisp standard to know about fifo-like objects (and define (1) as the appropriate behaviour) or at least want my Unix common-lisp implementation to provide that functionality as an (extra free bonus |:-) implementation-specific add-on. other opinions? - oe ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84 ;;; - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; [--- start of forwarded message ---] Return-Path: Date: Thu, 1 Apr 93 15:09:37 PST From: smh@Franz.COM (Steve Haflich) To: oe@dfki.uni-sb.de Class: bh Bh-Id: spr7955 Bh: append spr7955 expire Subject: Re: [spr7955] named pipes question Cc: bugs@Franz.COM [This matter has been assigned the tracking identifier "spr7955". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] Date: Tue, 23 Mar 93 17:38:16 +0100 Message-Id: <9303231638.AA01997@disco-elc5> ... but as i write it, here is a `real' bug report concerning Allegro CL 4.1 itself: i tried to read from and write to named pipes on sparcs (SunOS 4.1.1 and 4.1.3) and run into trouble as soon as i call open() (from lisp) with whatever arguments to `:if-exists' one can think of. what i get is an `interrupted system call' error because the open(2) blocks until both sides of the fifo are connected to some process; additionally some of the `:if-exists' arguments force a call to lseek(2) on the file descriptor which again results in an error. i figure that handling of named pipes as ordinary file system objects is quite tricky if you want to stick to the CLtL2 arguments to open(). one would probably have to stat(2) the file first, for fifos add the `O_NDELAY' flag to the open(2) call and presumably mark the resulting stream as (possibly) incomplete open so that following calls to read() and write() would block. Yes. The simple truth is that the only portable way to open a stream (ignoring indirect streams and string streams) is to call open with a pathname in the file system. The language definition considers file names to name regular files, and in fact, the Allegro language implementation make no special consideration of filesystem nodes that might name real devices, pseudo devices, or sockets. Any manipulation of such objects are outside the standard, and therefore (at least some of them) must be done with non-portable code. Unix has two kinds of system calls, "slow" calls that are potentially interruptible (returning EINTR) and "fast" calls which return immediately. open() on a filesystem file is "fast" and is supposed to return immediately, but open on a named pipe is slow and may hang for an arbitrarily large time. The Common Lisp OPEN function is not appropriate for such files, at least not in a multiprocessing image. I don't think this is particularly a Lisp problem, in that I can't think of any way even in C to wait for a named pipe to be in a state that wouldn't block, other than using polling. our solution finally was to run-shell-command() cat(1) to read and write to named pipes but i honestly dislike that. What this does, in effect, is to form off a separate Unix process (the cat) which doesn't matter if it blocks for a long time in the open. Polling is one alternative to this design, but that's also ugly in that it imposes runtime load on your machine. To use it, you would have to defforeign _open (obviously with a different Lisp name, since CL:OPEN is already taken) and then call it with the pathname and the O_NDELAY flag, looping with a process-sleep until open returns a nonnegative value. Once you have obtained a file descriptor, you can use this to wrap a stream around it: (make-instance 'excl::bidirectional-terminal-stream :fn-in fd :fn-out fd) This is taken from the function ipc:make-ipc-terminal-stream in the library file ipc.cl. You might want to examine this file for some other examples of networking, although I don't think anything there addresses the problem of waiting indefinitely for a the other end of a socket to become connected. I hope this information is of some use. It's a hard problem. [--- end of forwarded message ---] From excl-forum-distribution-owner Thu Apr 15 14:11:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150179>; Thu, 15 Apr 1993 14:11:25 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07169; Thu, 15 Apr 93 10:14:37 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA17844; Thu, 15 Apr 93 10:23:01 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA07770; Thu, 15 Apr 93 10:25:59 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA15796; Thu, 15 Apr 93 10:26:09 PDT Message-Id: <9304151726.AA15796@sole.Franz.COM> To: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Class: bh Bh-Id: spr8140 Bh: append spr8140 Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Subject: Re: indenting new macros (code indenting via pretty-printer) Date: Thu, 15 Apr 1993 13:26:06 -0400 From: Kevin Layer Content-Length: 814 >> I always wanted a pretty printer that worked on the ASCII source code >> rather than the Lisp list data structure. Preserves case and comments >> you know. Something like the ACL indent region stuff in GNU Emacs but >> the ability to get the output to a file. One could do this with >> appropriate GNU Emacs Lisp code and even arrange to use GNU Emacs as a >> batch indentation program - just some SMOPS. Seems as if this would >> be a generally useful extension to the fi stuff - eh Franz? This wouldn't be too hard, at all. In fact, all the pieces are there for anyone, not just us, to do it. I'll file an RFE for it, though. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Thu Apr 15 15:05:55 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <150195>; Thu, 15 Apr 1993 15:05:49 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07206; Thu, 15 Apr 93 11:05:11 PDT Received: from alpha.Xerox.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA18256; Thu, 15 Apr 93 11:13:36 -0700 Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <11623>; Thu, 15 Apr 1993 11:13:05 PDT Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc) id AA10696; Thu, 15 Apr 93 14:13:03 EDT Message-Id: <9304151813.AA10696@fliff.wrc.xerox.com> To: oe@dfki.uni-sb.de Cc: allegro-cl@ucbvax.berkeley.edu, smh@franz.com, bugs@franz.com Subject: Re: [smh@Franz.COM: Re: [spr7955] named pipes question] In-Reply-To: Your message of "Thu, 15 Apr 1993 05:05:07 PDT." <9304151205.AA16922@asl-sun3.dfki.uni-sb.de> Date: Thu, 15 Apr 1993 14:12:57 -0400 From: Jim Mayer > > Unix has two kinds of system calls, "slow" calls that are potentially > interruptible (returning EINTR) and "fast" calls which return > immediately. open() on a filesystem file is "fast" and is supposed to > return immediately, but open on a named pipe is slow and may hang for > an arbitrarily large time. The Common Lisp OPEN function is not > appropriate for such files, at least not in a multiprocessing image. > I don't think this is particularly a Lisp problem, in that I can't > think of any way even in C to wait for a named pipe to be in a state > that wouldn't block, other than using polling. Under SunOS 4.1.1 one can specify an O_NDELAY option to "open". Then, if the open is for reading, the call will return immediately with a file descriptor (which can then be fed to "select"). For writing to a named pipe with O_NDELAY set "open" returns an error (ENXIO). Personally, I find the second behavior obnoxious... the behavior of "connect" seems better. Anyway, the following would work reasonably well as an implementation of the Common Lisp "open" command: (1) Do an "open" with O_NDELAY specified. (2) If the open succeeds, you win. (3) If the open fails with ENXIO: (3a) Stat the file... if it is not a named pipe, return a failure. (3b) Otherwise, either start a polling loop or (better) fork off a subprocess to do the open and have it return the file descriptor using unix domain IPC over a pipe. The nice thing about the unix domain IPC approach is that you only pay the price when necessary, and the descriptor that you finally end up with is a "real" descriptor. In my opinion, the whole I/O system should be written to use non-blocking I/O. On the other hand, a standard unix threads package with MT safe library calls should be available pretty soon and would make things a lot easier for implementors. -- Jim Mayer Phone: (716) 422-9407 Webster Research Center Intelnet phone: 8*222-9407 Xerox Corporation Internet Email: mayer@wrc.xerox.com 800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox Webster, New York 14580 Facsimile: (716) 265-7133 From excl-forum-distribution-owner Mon Apr 19 21:32:11 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238215>; Mon, 19 Apr 1993 21:32:05 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11961; Mon, 19 Apr 93 17:32:08 PDT Received: from Mail.Think.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA05770; Mon, 19 Apr 93 17:40:22 -0700 Received: from Telecaster.Think.COM by mail.think.com; Mon, 19 Apr 93 20:40:02 -0400 From: Barry Margolin Received: by telecaster.think.com (4.1/Think-1.2) id AA11221; Mon, 19 Apr 93 20:40:02 EDT Date: Mon, 19 Apr 1993 20:40:02 -0400 Message-Id: <9304200040.AA11221@telecaster.think.com> To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, info-dylan@cambridge.apple.com, scheme@mc.lcs.mit.edu, news.news.announce.conferences@think.com Subject: Lisp Conference Announcement Reply-To: LUV-93-ORGANIZER@ai.sri.com 1993 Lisp Users Group Meeting: LUV-93: Lisp & Education The board members of the Association of Lisp Users (ALU) invite you to learn about the latest developments in Lisp by attending the Third International Lisp Users and Vendors Conference to be held August 9-14, 1993 at the Cambridge Marriott, Cambridge, Massachusetts. The ALU is the voice of the international Lisp user community. By holding our annual conference, we promote communication between the users and vendors of Lisp and Lisp-based applications. For more information, email the following information form to An Event to Remember at LUV-93-ORGANIZER@AI.SRI.COM, or phone 215-651-2990. -------------------------------- cut here -------------------------------- Name: Address: Telephone: FAX: Email: I would like to become a member of ALU - send membership form. ______ I would like to submit a paper - send call for papers. ______ I would like to attend LUV-93 - send registration form. ______ I would need hotel accomodations. ______ I am interested in student housing. ______ I would like to attend the following 4 tutorials, if offered: ____ 01) CLOS: Object-Oriented Programming in Lisp ____ 02) Adv. CLOS: Implementations, the AMOP, and more ____ 03) CLIM: Developing Portable User Interfaces ____ 04) Good Lisp Programming Style ____ 05) Performance Optimization ____ 06) Porting Lisp code ____ 07) Closures, Continuations, and Coroutines ____ 08) Metaprogramming Lisp using Macros ____ 09) Interfacing to SQL ____ 10) AutoLisp Programming for AutoCAD ____ 11) GNU Emacs Lisp Programming ____ 12) Lisp programming for Interleaf ____ 13) Common Lisp for Scheme Programmers ____ 14) Scheme for Common Lisp Programmers I would like to hear discussions on the following topics OR from the following persons: From excl-forum-distribution-owner Wed Apr 21 17:55:06 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238226>; Wed, 21 Apr 1993 17:55:03 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA13908; Wed, 21 Apr 93 13:59:31 PDT Received: from pride.uchicago.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA25394; Wed, 21 Apr 93 14:07:56 -0700 From: berger@cs.uchicago.edu Return-Path: Received: by pride.uchicago.edu (4.1/UofC4.3x) id AA08239; Wed, 21 Apr 93 16:05:23 CDT Date: Wed, 21 Apr 1993 17:05:23 -0400 Message-Id: <9304212105.AA08239@pride.uchicago.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: Modifying DIRECTORY The Allegro (4.1) CL version of the function DIRECTORY returns its list of pathnames in modification-date order (ala ls -c). I'm using code written elsewhere which uses this function, but assumes the pathnames are in alphabetical order. The Allegro Manual warns against messing with the package-lock system, but can anyone tell me what sort of disaster I might be courting by doing the following? (let ((oldirectory (symbol-function 'directory))) (excl:without-package-locks (defun DIRECTORY (&rest args) (sort (apply oldirectory args) #'string-lessp :key #'file-namestring)) ) ) -Jeff B. Jeff Berger |USmail: Ryerson 256 berger@cs.uchicago.edu | Artificial Intelligence Lab PH: (312) 702-8584 | 1100 East 58th Street FX: (312) 702-8487 | Chicago, IL 60637 From excl-forum-distribution-owner Thu Apr 22 03:31:10 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238279>; Thu, 22 Apr 1993 03:30:57 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14175; Wed, 21 Apr 93 23:24:30 PDT Received: from klara.hrp.no by ucbvax.Berkeley.EDU (5.63/1.43) id AA14232; Wed, 21 Apr 93 23:32:57 -0700 Received: from bingen.hrp.no by klara.hrp.no with SMTP (16.6/IFE3.0) id AA21928; Thu, 22 Apr 93 08:32:47 +0200 From: Eyvind Ness Posted-Date: Thu, 22 Apr 93 6:32 GMT Received-Date: Thu, 22 Apr 93 08:32:47 +0200 Received: by bingen.hrp.no ; Thu, 22 Apr 93 08:32:46 +0200 Message-Id: <9304220632.AA25208@bingen.hrp.no> Date: Thu, 22 Apr 1993 02:32:00 -0400 Reply-To: Eyvind.Ness@hrp.no To: berger@cs.uchicago.edu Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9304212105.AA08239@pride.uchicago.edu> Subject: Modifying DIRECTORY X-Mailer: GNU Emacs 18.58.29 with VM 5.21 (beta) ;; Date: Wed, 21 April 93, 16:05 CDT ;; From: berger@cs.uchicago.edu ;; ;; The Allegro (4.1) CL version of the function DIRECTORY returns its ;; list of pathnames in modification-date order (ala ls -c). I'm using ;; code written elsewhere which uses this function, but assumes the ;; pathnames are in alphabetical order. The Allegro Manual warns against ;; messing with the package-lock system, but can anyone tell me what sort ;; of disaster I might be courting by doing the following? ;; ;; ;; (let ((oldirectory (symbol-function 'directory))) ;; (excl:without-package-locks ;; (defun DIRECTORY (&rest args) ;; (sort ;; (apply oldirectory args) ;; #'string-lessp ;; :key #'file-namestring)) ;; ) ;; ) Hi Jeff, I'm also a bit annoyed by the persistence with which Allegro protects the built-in CL symbols - I can't even locally override CL fundefs within an FLET/LABELS without having a flood of warnings thrown at me. In your case, however, you might want to consider the ADVICE util to modify the DIRECTORY function: USER(11): (directory ".") (#p"./errno.o" #p"./top-level-wrapper.fasl" #p"./top-level-wrapper.lisp.~1~" #p"./TAGLIST.~31~" #p"./TAGS.~31~" #p"./TAGLIST.~32~" #p"./COPMA-II.lisp" #p"./top-level-wrapper.lisp" #p"./TAGS.~32~" #p"./TAGLIST" ...) Unsorted, default listing returned. USER(12): (excl:defadvice directory :around (sort :do-it #'string-lessp :key #'file-namestring)) DIRECTORY USER(13): (directory ".") (#p"./bup-4-4-92" #p"./COPMA-II.lisp" #p"./enlib" #p"./errno.o" #p"./example" #p"./junk" #p"./kernel" #p"./Makefile" #p"./manual-make" #p"./networking" ...) USER(14): Sorted, as intended. Cheers, Eyvind. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Eyvind Ness Internet: Eyvind.Ness@HRP.No Research Scientist Voicenet: +47 69 183100 ext. 275 CRS Division Faxnet: +47 69 187109 OECD HRP Papernet: PO Box 173, N-1751 Halden, Norway ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -Applicants must also have extensive knowledge of Unix, although they should have sufficiently good programming taste to not consider this an achievement. MIT AI Lab job ad in Comm. of the ACM, vol. 35, no. 6, June 1992, pp. 160 From excl-forum-distribution-owner Thu Apr 22 11:29:24 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238216>; Thu, 22 Apr 1993 11:29:17 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14779; Thu, 22 Apr 93 07:13:25 PDT Received: from ncbi.nlm.nih.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA03909; Thu, 22 Apr 93 07:21:53 -0700 Received: from work.nlm.nih.gov by ncbi.nlm.nih.gov (4.1/SMI-4.1) id AA00851; Thu, 22 Apr 93 10:19:21 EDT Received: by work.nlm.nih.gov (920330.SGI/5.6) id AA02963; Thu, 22 Apr 93 10:19:48 -0400 Date: Thu, 22 Apr 1993 10:19:48 -0400 From: hunter@ncbi.nlm.nih.gov (Larry Hunter) Message-Id: <9304221419.AA02963@work.nlm.nih.gov> To: allegro-cl@ucbvax.berkeley.edu Subject: reading numbers as symbols Reply-To: Hunter@nlm.nih.gov I'm fishing for zip codes in large email files, and I would like to read preserving leading zeros in numbers. I wrote a function that looks for potnums in strings and puts || escapes around them. It works, but it is inelegant and inefficient to have to read strings, then escape the potential numbers, then read-from-string. I would prefer to get the reader to treat all tokens that are potential numbers as symbols. Something like setting the *read-base* to 0 :-). Is there some straightforward way to do this that I missed? Larry From excl-forum-distribution-owner Thu Apr 22 12:54:54 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238228>; Thu, 22 Apr 1993 12:54:52 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA14818; Thu, 22 Apr 93 09:05:48 PDT Received: from ncbi.nlm.nih.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA08450; Thu, 22 Apr 93 09:14:17 -0700 Received: from work.nlm.nih.gov by ncbi.nlm.nih.gov (4.1/SMI-4.1) id AA12360; Thu, 22 Apr 93 12:14:15 EDT Received: by work.nlm.nih.gov (920330.SGI/5.6) id AA03053; Thu, 22 Apr 93 12:14:42 -0400 Date: Thu, 22 Apr 1993 12:14:42 -0400 From: hunter@ncbi.nlm.nih.gov (Larry Hunter) Message-Id: <9304221614.AA03053@work.nlm.nih.gov> To: allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9304221608.AA09237@hpai19.isi.edu> "donc@ISI.EDU" Subject: reading numbers as symbols Reply-To: Hunter@nlm.nih.gov Perhaps I should have been clearer the first go round. I got several responses to my question about reading potnums as symbols like this: Wouldn't it work to do the read with a readtable where all the numbers were given the same syntax class as alphabetic characters? The answer is no. Digits ARE alphabetic characters -- their interpretation as numbers depends only on the radix (*read-base*) value. So (set-syntax-from-char #\1 #\A) T (set-syntax-from-char #\0 #\A) T (read-from-string "00001") 1 5 (read-from-string "0000A") 0000A 5 (let ((*read-base* 16)) (read-from-string "0000A")) 10 5 From excl-forum-distribution-owner Thu Apr 22 20:54:54 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237408>; Thu, 22 Apr 1993 20:54:52 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15106; Thu, 22 Apr 93 16:56:19 PDT Received: from giane.cs.umass.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA27584; Thu, 22 Apr 93 17:04:47 -0700 Received: by giane.cs.umass.edu (5.57/Ultrix3.0-C) id AA24511; Thu, 22 Apr 93 20:04:12 -0400 Date: Thu, 22 Apr 1993 20:04:12 -0400 From: kevin@freya.cs.umass.edu Message-Id: <9304230004.AA24511@giane.cs.umass.edu> To: berger@cs.uchicago.edu Cc: allegro-cl@ucbvax.berkeley.edu Subject: Modifying DIRECTORY Reply-To: gallagher@cs.umass.edu > Date: Wed, 21 April 93, 16:05 CDT > From: berger@cs.uchicago.edu > > The Allegro (4.1) CL version of the function DIRECTORY returns its > list of pathnames in modification-date order (ala ls -c). I'm using > code written elsewhere which uses this function, but assumes the > pathnames are in alphabetical order. The Allegro Manual warns against > messing with the package-lock system, but can anyone tell me what sort > of disaster I might be courting by doing the following? > > > (let ((oldirectory (symbol-function 'directory))) > (excl:without-package-locks > (defun DIRECTORY (&rest args) > (sort > (apply oldirectory args) > #'string-lessp > :key #'file-namestring)))) The consequence of this (in this case `disaster' is probably too strong a word) is that if another program did a similar trick to get the files in size order then one of the two programs will break. A better way to do this is to shadow the symbol DIRECTORY in your package so that any changes you make to its behaviour will only be seen by your program. E.g., (in-package :my-package) (eval-when (compile load eval) (shadow 'directory)) (defun directory (&rest args) (sort (apply #'cl:directory args) #'string-lessp :key #'file-namestring)) From excl-forum-distribution-owner Thu Apr 22 23:24:44 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237408>; Thu, 22 Apr 1993 23:24:35 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15333; Thu, 22 Apr 93 19:42:22 PDT Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA04302; Thu, 22 Apr 93 19:50:48 -0700 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA00752; Thu, 22 Apr 93 19:47:57 PDT From: smh@franz.com (Steve Haflich) Message-Id: <9304230247.AA00752@akbar.Franz.COM> To: Hunter@nlm.nih.gov Cc: allegro-cl@ucbvax.berkeley.edu Subject: Re: reading numbers as symbols In-Reply-To: Your message of Thu, 22 Apr 93 10:19:48 -0400. <9304221419.AA02963@work.nlm.nih.gov> Date: Thu, 22 Apr 1993 22:47:55 -0400 > From: hunter@ncbi.nlm.nih.gov (Larry Hunter) > > I'm fishing for zip codes in large email files, and I would like to read > preserving leading zeros in numbers. > > I wrote a function that looks for potnums in strings and puts || escapes > around them. It works, but it is inelegant and inefficient to have to read > strings, then escape the potential numbers, then read-from-string. > > I would prefer to get the reader to treat all tokens that are potential > numbers as symbols. Something like setting the *read-base* to 0 :-). > > Is there some straightforward way to do this that I missed? The way you would do this is by creating your own readtable, using SET-MACRO-CHARACTER, in which the ten digits would be nonterminatingp and have a dispatch function that builds a string. But I think that using the Common Lisp reader in this application is simply inappropriate, and this is a fairly common design mistake. The READ function is a complicated subroutine, extendable by mediation of the readtable, that converts a stream of characters into a recursively nested Lisp object, capable of creating many different types according to the external syntax described in CLtL Chapter 2. READ is modular, and uses lower-level functions such as READ-CHAR to obtain characters. Your application intends to scan a stream of characters representing a printed representation of a mailing list and presumably collect or otherwise process zip codes. Presumably this application will also use the lower-level functions such as READ-CHAR, READ-LINE, and friends, but nothing about this application is reminiscent of the task performed by the READ function, which includes constructing lists, complex numbers, conses, ratios, and pathnames. The machinery of READ seems more likely to get in your way than to help solve the task. To look at it another way, mailing lists are usually sloppy data, with occasional strange or botched punctiation. Imagine that just one entry has a colon char somewhere in it. Suppose some creative company has a name with an unbalanced parenthesis. Suppose an entry "Mr . Foo" has an unintended space before the period. Suppose an entry has a "#" in it, such as an apartment number, and perhaps even a "#.". All these things will likely cause the reader to signal error, because these syntax elements have meaning to READ that they don't have in a mailing list. From excl-forum-distribution-owner Fri Apr 23 06:29:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237411>; Fri, 23 Apr 1993 06:29:08 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15973; Fri, 23 Apr 93 02:02:39 PDT Received: from adler.ims.uni-stuttgart.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA20358; Fri, 23 Apr 93 02:11:00 -0700 Received: from milan.ims.uni-stuttgart.de by adler.ims.uni-stuttgart.de (4.1/IMS-1.1) id AA08256; Fri, 23 Apr 93 11:10:08 +0200 Date: Fri, 23 Apr 1993 05:10:08 -0400 From: Oliver Christ Message-Id: <9304230910.AA08256@adler.ims.uni-stuttgart.de> Received: by milan.ims.uni-stuttgart.de id AA05183; Fri, 23 Apr 93 11:10:07 +0200 To: gallagher@cs.umass.edu Cc: berger@cs.uchicago.edu, allegro-cl@ucbvax.berkeley.edu In-Reply-To: kevin@freya.cs.umass.edu's message of Thu, 22 Apr 93 20:04:12 -0400 <9304230004.AA24511@giane.cs.umass.edu> Subject: Modifying DIRECTORY Reply-To: oli@ims.uni-stuttgart.de >>>>> On Thu, 22 Apr 93 20:04:12 -0400, kevin@freya.cs.umass.edu said: kevin> A better way to do this is to shadow the symbol DIRECTORY in your kevin> package so that any changes you make to its behaviour will only be kevin> seen by your program. E.g., kevin> (in-package :my-package) kevin> (eval-when (compile load eval) kevin> (shadow 'directory)) kevin> (defun directory (&rest args) kevin> (sort (apply #'cl:directory args) #'string-lessp kevin> :key #'file-namestring)) Another way would be to add a :sort-by clause to #'directory, with possible arguments :name :size :date etc. Although it's possibly too late for X3J13 to do this. I don't know whether Franz is willing to alter this locally within ACL, although my X3J13 specs of 9-APR-92 say that an implementation is allowed to add such keyword args. Oli From excl-forum-distribution-owner Fri Apr 23 10:56:32 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237410>; Fri, 23 Apr 1993 10:56:27 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA16068; Fri, 23 Apr 93 06:47:07 PDT Received: from bunny.gte.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA22239; Fri, 23 Apr 93 06:55:28 -0700 Received: from henry by bunny.gte.com (5.61/GTEL2.19) id AA26435; Fri, 23 Apr 93 09:55:17 -0400 Date: Fri, 23 Apr 1993 09:54:00 -0400 From: Bud Frawley Subject: Modifying DIRECTORY To: berger@cs.uchicago.edu Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9304230004.AA24511@giane.cs.umass.edu> Message-Id: <19930423135451.9.BUD@henry.gte.com> Why is it important to modify the existing definition? The typical function-building style of Lisp suggests that one write one's own Sorted-Directory function with keywords for the order predicate and the element key. From excl-forum-distribution-owner Fri Apr 23 15:35:45 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237411>; Fri, 23 Apr 1993 15:35:40 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA16282; Fri, 23 Apr 93 11:48:16 PDT Received: from pride.uchicago.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA00604; Fri, 23 Apr 93 11:56:43 -0700 From: berger@cs.uchicago.edu Return-Path: Received: by pride.uchicago.edu (4.1/UofC4.3x) id AA12149; Fri, 23 Apr 93 13:56:39 CDT Date: Fri, 23 Apr 1993 14:56:39 -0400 Message-Id: <9304231856.AA12149@pride.uchicago.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: Modifying DIRECTORY Thanks to all concerned for the response to my simple problem. I see that I didn't make things quite clear enough and some confusion resulted. First of all, I'd say using the ADVICE facility looks like the cleanest solution. I believe Franz even suggests ADVICE as a way of modifying compiled code. I should have been a little more explicit in my original problem description. I'm building a CL system which uses GARNET, a GUI developed by worthy people at CMU. It comes with many built-in gadgets including a file-loading gadget which presents a scrolling menu of files which can be selected for loading. The items in the menu are built by invoking DIRECTORY on a user-specified directory. The GARNET code assumes the returned pathnames are in alphabetic order. I wanted to get the file-loading gadget to produce menu items in alphabetic order without altering and recompiling the GARNET code which is used by others, or making my own copy of the code, or ... Hence the suggestions involving defining a new SORTED-DIRECTORY function or using the package system, while fine for other circumstances, didn't fit my problem. Thanks again. -Jeff B. From excl-forum-distribution-owner Mon Apr 26 11:55:33 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238500>; Mon, 26 Apr 1993 11:55:16 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA19615; Mon, 26 Apr 93 07:47:29 PDT Received: from uni-sb.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA23776; Mon, 26 Apr 93 07:55:14 -0700 Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930331) id AA06703; Mon, 26 Apr 93 16:53:44 +0200 Received: from disco-elc1.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA09398; Mon, 26 Apr 93 16:56:00 +0200 Date: Mon, 26 Apr 1993 10:49:37 -0400 Message-Id: <9304261449.AA05465@disco-elc1> Received: by disco-elc1; Mon, 26 Apr 93 16:49:37 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: konrad@dfki.uni-sb.de (Karsten Konrad) To: allegro-cl@ucbvax.berkeley.edu Subject: Labels are slow! Reply-To: konrad@dfki.uni-sb.de Hello! While testing some program-generated Lisp-Code, I discovered a strange behaviour of labels in ACL. The two functions below obviously do the same (hm, nothing useful..), but the version with the labels uses about 7.2MB of memory when called a 50000 times; test0, on the other hand, needs only 32 bytes! Of course, there also is a loss of performance, about factor 80 or so. (defun test0 (cnode) (OR (AND (EQ CNODE 'A) (symbolp cnode)) (AND (EQ CNODE 'B) (symbolp cnode)) (AND (EQ CNODE 'C) (symbolp cnode)))) (defun test1 (cnode) (LABELS ((ZGEN-580 NIL (DECLARE (INLINE ZGEN-579)) (OR (AND (EQ CNODE 'A) (ZGEN-579)) (AND (EQ CNODE 'B) (ZGEN-579)) (AND (EQ CNODE 'C) (ZGEN-579)))) (ZGEN-579 NIL (symbolp cnode))) (ZGEN-580))) BTW, the (declare (inline .. trick is ignored by the compiler. Other Lisps (e.g. Lucid) don't show such extreme use of memory and time. Is there a way to fix this? /; Mon, 26 Apr 1993 13:23:20 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA19703; Mon, 26 Apr 93 09:35:27 PDT Received: from peoplesparc.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA27557; Mon, 26 Apr 93 09:43:47 -0700 Received: by peoplesparc.Berkeley.EDU (4.1/1.42) id AA08389; Mon, 26 Apr 93 09:40:50 PDT Date: Mon, 26 Apr 1993 12:40:50 -0400 From: fateman@peoplesparc.berkeley.edu (Richard Fateman) Message-Id: <9304261640.AA08389@peoplesparc.Berkeley.EDU> To: allegro-cl@ucbvax.berkeley.edu Subject: tiff or other image formats in lisp Are there packages for reading/writing/displaying TIFF or other image formats in Allegro CL? A pile of links to the libtiff.a routines might be sufficient. I'm using Allegro 4.1 on a SPARC station. My commitment to TIF is rather insubstantial, and if tools for pbm or other formats were better, I could use them. I have only monochrome (and not even gray-scale) images from a scanner. Thanks. Richard Fateman From excl-forum-distribution-owner Tue Apr 27 19:34:51 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237408>; Tue, 27 Apr 1993 19:34:49 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00521; Tue, 27 Apr 93 15:57:09 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA21475; Tue, 27 Apr 93 16:05:37 -0700 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA22739; Tue, 27 Apr 93 16:08:01 PDT Received: by clay.Franz.COM (4.0/FI-2.0) id AA02369; Tue, 27 Apr 93 16:05:34 PDT Date: Tue, 27 Apr 1993 19:05:34 -0400 From: duane@franz.com (Duane Rettig) Message-Id: <9304272305.AA02369@clay.Franz.COM> To: konrad@dfki.uni-sb.de Class: bh Bh-Id: spr8255 Bh: append spr8255 expire Subject: Re: [spr8255] Labels are slow! Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Your problem report has been assigned tracking id spr8255. Please use it in the subject line of any correspondences regarding your problem report. >> While testing some program-generated Lisp-Code, I discovered a strange >> behaviour of labels in ACL. The two functions below obviously do the >> same (hm, nothing useful..), but the version with the labels uses about >> 7.2MB of memory when called a 50000 times; test0, on the other hand, >> needs only 32 bytes! Of course, there also is a loss of performance, about >> factor 80 or so. >> >> (defun test0 (cnode) >> (OR (AND (EQ CNODE 'A) (symbolp cnode)) >> (AND (EQ CNODE 'B) (symbolp cnode)) >> (AND (EQ CNODE 'C) (symbolp cnode)))) >> >> (defun test1 (cnode) >> (LABELS ((ZGEN-580 NIL >> (DECLARE (INLINE ZGEN-579)) >> (OR (AND (EQ CNODE 'A) (ZGEN-579)) >> (AND (EQ CNODE 'B) (ZGEN-579)) >> (AND (EQ CNODE 'C) (ZGEN-579)))) >> (ZGEN-579 NIL (symbolp cnode))) >> (ZGEN-580))) We are aware of this problem, and have made it high priority to fix it. Allegro CL 4.2, which is currently in beta, mitigates the problem somewhat, and a complete fix is high on our list of enhancements for after 4.2. Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Wed Apr 28 06:10:20 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237408>; Wed, 28 Apr 1993 06:10:13 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA01350; Wed, 28 Apr 93 01:47:51 PDT Received: from sparky.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA14574; Wed, 28 Apr 93 01:56:20 -0700 Return-Path: Received: by sparky.Franz.COM (4.1/FI-2.0) id AA01432; Wed, 28 Apr 93 01:56:34 PDT Date: Wed, 28 Apr 1993 04:56:34 -0400 From: smh@franz.com (Steve Haflich) Message-Id: <9304280856.AA01432@sparky.Franz.COM> To: berger@cs.uchicago.edu Class: bh Bh-Id: spr8220 Bh: append spr8220 expire Subject: Re: [spr8220] Modifying DIRECTORY Cc: bugs@franz.com, oli@ims.uni-stuttgart.de, allegro-cl@ucbvax.berkeley.edu, gallagher@cs.umass.edu [This matter has been assigned the tracking identifier "spr8220". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] This is some followup on the allegro-cl discussion over the last few days. From: berger@cs.uchicago.edu Date: Wed, 21 Apr 93 16:05:23 CDT The Allegro (4.1) CL version of the function DIRECTORY returns its list of pathnames in modification-date order (ala ls -c). I'm using code written elsewhere which uses this function, but assumes the pathnames are in alphabetical order. Ummm, one thing everyone seems to have missed is that this isn't true. It may happen some of the time on some platforms, but on others the order is the order entries appear in the directory. Perhaps you're running under Mach? The Allegro Manual warns against messing with the package-lock system, but can anyone tell me what sort of disaster I might be courting by doing the following? (let ((oldirectory (symbol-function 'directory))) (excl:without-package-locks (defun DIRECTORY (&rest args) (sort (apply oldirectory args) #'string-lessp :key #'file-namestring)) ) ) First, the order of the list returned by the DIRECTORY function is not specified by the language standard, so any code depending on it is broken in the sense of not being portable Common Lisp. I don't know of anything your proposed advice will break, but what you are doing is making a global modification to the function defuned on the public symbol common-lisp:directory, and I agree with the opinion of Kevin Gallagher that this is dangerous. If no one else cares about the returned order, that's fine, but if some other code depends on the order of the returned list, you might break it. Worse, if some other implementor tries to do some similar (but not identical) kludge for some other purpose, one or the other of you will lose. For example, you might want case-sensitive sorting, but other might want case-insensitive. I think the morale is first that the Garnet code is slightly broken in depending on non-standard behavior of a standard function. If you can't bring yourself to modify its source locally, then it is preferable to find some way to modify its behavior in a way that doesn't affect other applications running in the lisp world. Shadowing the symbol seen by the package seen by the Garnet code seems the way to do this, if it is practical, as was suggested by both Gallagher and Oliver Christ. If it's not possible, then your advice isn't particularly dangerous, but consider yourself warned. On the notion of adding keyword arguments to the directory function, there isn't any reason why it wouldn't be practical, but it hardly solves the problem of portability unless X3J13 makes them mandatory additions to the language. X3J13's current philosophy is that further features shouldn't be added to the language (at least for this round) unless the features are both important and cannot easily be programmed by the user (with acceptable efficiency, etc.). Clearly sorting the list returned by directory fails the second test. It is just as easy and more flexible for user code to wrap its own sort around the call to directory. This, IMO, is what the Garnet code should have done. From excl-forum-distribution-owner Wed Apr 28 16:52:07 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237415>; Wed, 28 Apr 1993 16:52:01 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA01590; Wed, 28 Apr 93 13:20:37 PDT Received: from [129.83.10.1] by ucbvax.Berkeley.EDU (5.63/1.43) id AA08254; Wed, 28 Apr 93 13:28:58 -0700 Return-Path: Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA07480; Wed, 28 Apr 93 16:28:51 -0400 Posted-Date: Wed, 28 Apr 93 16:28:48 -0400 Received: by thelonius.mitre.org (5.61/RCF-4C) id AA15944; Wed, 28 Apr 93 16:28:49 -0400 Message-Id: <9304282028.AA15944@thelonius.mitre.org> To: allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8255] Labels are slow! Date: Wed, 28 Apr 1993 16:28:48 -0400 From: john@linus.mitre.org Could someone from Franz explain some of the issues involved with this example, so we users can look for analogous problem spots in our current code? Is the problem simply the extra function-call overhead, or is it that the LABELS functions are closures, necessitating the dreaded COPY-FUNCTION. I tend to use internal functions a lot, and I'd really like to know what the tradeoffs are, if they're as dramatic as this example seems to indicate. John Burger john@mitre.org From excl-forum-distribution-owner Wed Apr 28 18:33:50 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237419>; Wed, 28 Apr 1993 18:33:43 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA01622; Wed, 28 Apr 93 14:08:23 PDT Received: from [192.132.95.84] by ucbvax.Berkeley.EDU (5.63/1.43) id AA09683; Wed, 28 Apr 93 14:16:45 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA10669; Wed, 28 Apr 93 14:19:09 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA25786; Wed, 28 Apr 93 14:19:47 PDT Message-Id: <9304282119.AA25786@sole.Franz.COM> To: Eyvind.Ness@hrp.no Class: bh Bh-Id: spr8239 Bh: append spr8239 Cc: bugs@franz.com, weber@franz.com, stu@franz.com, berger@cs.uchicago.edu, allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8239] package-lock warning messages Date: Wed, 28 Apr 1993 17:19:45 -0400 From: Kevin Layer Content-Length: 1155 Your problem report has been assigned a tracking id of spr8239. Please use this id in the subject line of any mail related to it so that we may better track communication on your inquiry. Also, please address mail to bugs@franz.com as well as me, so your questions can be answered if I am unavailable. >> I'm also a bit annoyed by the persistence with which Allegro protects >> the built-in CL symbols - I can't even locally override CL fundefs >> within an FLET/LABELS without having a flood of warnings thrown at me. This is discussed in the Allegro CL User Guide, page 3-25, volume 1. In short, you can disable package locking, though it is strongly discouraged. You would not believe how many sprs we had because people did this: (defstruct instance ...) which obviously clashes with make-instance if package locking is not enabled. Also, there is a typo in the User Guide: the variable excl:*enable-package-lock-errors* is really excl:*enable-package-locked-errors*. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Thu Apr 29 04:57:05 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237422>; Thu, 29 Apr 1993 04:56:56 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA01735; Thu, 29 Apr 93 00:06:36 PDT Received: from [158.36.44.10] by ucbvax.Berkeley.EDU (5.63/1.43) id AA24918; Thu, 29 Apr 93 00:14:54 -0700 Received: from bingen.hrp.no by klara.hrp.no with SMTP (16.6/IFE3.0) id AA20704; Thu, 29 Apr 93 09:14:23 +0200 From: Eyvind Ness Posted-Date: Thu, 29 Apr 93 7:14 GMT Received-Date: Thu, 29 Apr 93 09:14:23 +0200 Received: by bingen.hrp.no ; Thu, 29 Apr 93 09:14:22 +0200 Message-Id: <9304290714.AA17564@bingen.hrp.no> Date: Thu, 29 Apr 1993 03:14:00 -0400 Reply-To: Eyvind.Ness@hrp.no To: layer@franz.com Cc: bugs@franz.com, weber@franz.com, stu@franz.com, berger@cs.uchicago.edu, allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9304282119.AA25786@sole.Franz.COM> Subject: Re: [spr8239] package-lock warning messages X-Mailer: GNU Emacs 18.58.29 with VM 5.21 (beta) ;; Date: Wed, 28 April 1993, 14:19 -0700 ;; From: Kevin Layer ;; ;; >> I'm also a bit annoyed by the persistence with which Allegro protects ;; >> the built-in CL symbols - I can't even locally override CL fundefs ;; >> within an FLET/LABELS without having a flood of warnings thrown at me. ;; ;; This is discussed in the Allegro CL User Guide, page 3-25, volume 1. ;; In short, you can disable package locking, though it is strongly ;; discouraged. You would not believe how many sprs we had because ;; people did this: ;; ;; (defstruct instance ...) ;; ;; which obviously clashes with make-instance if package locking is not ;; enabled. Yes. Yes. Most of us know already, I think. What is so strange, in my opinion, is that you can't *locally* override a cl-symbol within the body of an FLET or LABELS without getting lots of annoying warning messages. Note that I'm not making a permanent *change* to the cl-definition - it's only a *temporary* redefinition of it. Also, I have not found a proper way to bind EXCL:*ENABLE-PACKAGE-LOCKED-ERRORS* to NIL while compiling and using a macro-definition that expands to a function that uses FLET on a cl-symbol. What I have is something like: (defmacro franz-dislikes-this-macro (&rest body) ... `(let ((excl:*enable-package-locked-errors* nil)) ... . ,body)) Which, needless to say, expands into a million warning messages at compile time. In addition, the effect is that the redefiniton attempt will be ignored. I don't want to enter a discussion on the justification of such a macro. I'm also aware of the fact that even if I bind the function definition of a cl-symbol, the original function could be compiled inline into some of the code within the body of the binding, risking that the new fundef will remain unused throughout the body. The following script should illustrate my point: USER(5): (defmacro bs (&rest body) `(let ((excl:*enable-package-locked-errors* nil)) (flet ((break (&rest args) (declare (ignore args)) "no brakes allowed")) . ,body))) BS USER(6): (compile 'bs) BS NIL NIL USER(7): :ma (bs (some-bullshit)) (LET ((*ENABLE-PACKAGE-LOCKED-ERRORS* NIL)) (FLET ((BREAK (&REST ARGS) (DECLARE (IGNORE ARGS)) "no brakes allowed")) (SOME-BULLSHIT))) USER(8): (defun using-bs () (bs (funcall 'break "brakes?"))) USING-BS USER(9): (compile 'using-bs) ; While compiling USING-BS: Warning: Compiling a FUNCTION definition for the name BREAK as a FLET. This name is in the #1=COMMON-LISP package and defining it will be a violation for portable programs. The package #1# has PACKAGE-DEFINITION-LOCK set, which causes the system to check for this violation. USING-BS T T USER(10): (using-bs) Break: brakes? Restart actions (select using :continue): 0: return from break. [1c] USER(11): :pop USER(12): (uncompile 'using-bs) USING-BS USER(13): (LET ((*ENABLE-PACKAGE-LOCKED-ERRORS* NIL)) (compile 'using-bs)) USING-BS NIL NIL USER(14): (using-bs) Break: brakes? Restart actions (select using :continue): 0: return from break. [1c] USER(15): :pop USER(16): ;; Also, there is a typo in the User Guide: the variable ;; excl:*enable-package-lock-errors* is really ;; excl:*enable-package-locked-errors*. Fortunately, using the nice Emacs Lisp completion feature that is a built-in of the Franz Elisp package and the ILISP package, many of these errors can be avoided. Eyvind. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Eyvind Ness Internet: Eyvind.Ness@HRP.No Research Scientist Voicenet: +47 69 183100 ext. 275 CRS Division Faxnet: +47 69 187109 OECD HRP Papernet: PO Box 173, N-1751 Halden, Norway ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ From excl-forum-distribution-owner Thu Apr 29 14:46:15 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237429>; Thu, 29 Apr 1993 14:46:05 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02384; Thu, 29 Apr 93 10:13:13 PDT Received: from [128.220.13.26] by ucbvax.Berkeley.EDU (5.63/1.43) id AA11731; Thu, 29 Apr 93 09:45:10 -0700 Message-Id: <9304291645.AA11731@ucbvax.Berkeley.EDU> Received: by server.cs.jhu.edu; Thu, 29 Apr 93 12:44:50 -0400 Date: Thu, 29 Apr 1993 12:44:49 -0400 From: chu@server.cs.jhu.edu Sender: chu@server.cs.jhu.edu To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu Subject: Re: Lisp Conference Announcement Reply-To: pchu@aplcomm.jhuapl.edu I may have just inadvertantly CC'ed my LUV form to a bunch of lisp-related groups. Sorry about that. -- Phil Chu internet: pchu@aplcomm.jhuapl.edu From excl-forum-distribution-owner Thu Apr 29 14:58:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238216>; Thu, 29 Apr 1993 14:58:37 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02397; Thu, 29 Apr 93 10:28:10 PDT Received: from [128.220.13.26] by ucbvax.Berkeley.EDU (5.63/1.43) id AA11561; Thu, 29 Apr 93 09:39:51 -0700 Message-Id: <9304291639.AA11561@ucbvax.Berkeley.EDU> Received: by server.cs.jhu.edu; Thu, 29 Apr 93 12:38:49 -0400 Date: Thu, 29 Apr 1993 12:38:47 -0400 From: chu@server.cs.jhu.edu Sender: chu@server.cs.jhu.edu To: LUV-93-ORGANIZER@ai.sri.com Cc: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu Subject: Re: Lisp Conference Announcement Reply-To: pchu@aplcomm.jhuapl.edu Name: Philip H. Chu Address: 1900 Thames St. Apt. 322, Baltimore MD 21231 Telephone: (410) 276-4630 FAX: Email: pchu@aplcomm.jhuapl.edu I would like to become a member of ALU - send membership form. ____X__ I would like to submit a paper - send call for papers. ______ I would like to attend LUV-93 - send registration form. ___X___ I would need hotel accomodations. ___X___ I am interested in student housing. ______ I would like to attend the following 4 tutorials, if offered: ____ 01) CLOS: Object-Oriented Programming in Lisp ____ 02) Adv. CLOS: Implementations, the AMOP, and more ____ 03) CLIM: Developing Portable User Interfaces ____ 04) Good Lisp Programming Style ____ 05) Performance Optimization ____ 06) Porting Lisp code ____ 07) Closures, Continuations, and Coroutines ____ 08) Metaprogramming Lisp using Macros ____ 09) Interfacing to SQL ____ 10) AutoLisp Programming for AutoCAD ____ 11) GNU Emacs Lisp Programming ____ 12) Lisp programming for Interleaf ____ 13) Common Lisp for Scheme Programmers ____ 14) Scheme for Common Lisp Programmers I would like to hear discussions on the following topics OR from the following persons: From excl-forum-distribution-owner Thu Apr 29 15:01:32 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238215>; Thu, 29 Apr 1993 15:01:25 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02385; Thu, 29 Apr 93 10:17:59 PDT Received: from vm1.ulg.ac.be by ucbvax.Berkeley.EDU (5.63/1.43) id AA12954; Thu, 29 Apr 93 10:26:14 -0700 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Thu, 29 Apr 93 19:25:44 +0200 Received: from [192.91.200.75] by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA23756; Thu, 29 Apr 93 19:28:27 +0200 Message-Id: <9304291728.AA23756@montefiore.ulg.ac.be> Date: Thu, 29 Apr 1993 14:34:31 -0400 To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu, pchu@aplcomm.jhuapl.edu From: "Vincent Keunen" X-Sender: vk@montefiore.ulg.ac.be Subject: Re: Lisp Conference Announcement At 12:44 29/04/93 -0400, chu@server.cs.jhu.edu wrote : >I may have just inadvertantly CC'ed my LUV form to a bunch of >lisp-related groups. Sorry about that. >-- > >Phil Chu >internet: pchu@aplcomm.jhuapl.edu It's ok. We'll just see if this brings more or less people to the conference... ;-) Vincent -- Keunen Vincent R&D, Software Engineer keunen@montefiore.ulg.ac.be tel: +32 41 407282 fax: +32 41 481170 From excl-forum-distribution-owner Thu Apr 29 15:36:35 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238215>; Thu, 29 Apr 1993 15:36:21 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02479; Thu, 29 Apr 93 11:14:38 PDT Received: from aspen.CS.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA12338; Thu, 29 Apr 93 10:05:50 -0700 Received: by aspen.CS.Berkeley.EDU (5.63/1.42) id AA14447; Thu, 29 Apr 93 10:05:39 -0700 Date: Thu, 29 Apr 1993 13:05:39 -0400 From: boyland@aspen.cs.berkeley.edu Message-Id: <9304291705.AA14447@aspen.CS.Berkeley.EDU> To: allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8239] package-lock warning messages ] From: Eyvind Ness ] Date: Thu, 29 Apr 93 7:14 GMT ] ] ;; Date: Wed, 28 April 1993, 14:19 -0700 ] ;; From: Kevin Layer ] ;; ] ;; >> I'm also a bit annoyed by the persistence with which Allegro protects ] ;; >> the built-in CL symbols - I can't even locally override CL fundefs ] ;; >> within an FLET/LABELS without having a flood of warnings thrown at me. ] ;; ] ;; This is discussed in the Allegro CL User Guide, page 3-25, volume 1. ] ;; In short, you can disable package locking, though it is strongly ] ;; discouraged. You would not believe how many sprs we had because ] ;; people did this: ] ;; ] ;; (defstruct instance ...) ] ;; ] ;; which obviously clashes with make-instance if package locking is not ] ;; enabled. ] ] Yes. Yes. Most of us know already, I think. What is so strange, in my ] opinion, is that you can't *locally* override a cl-symbol within the ] body of an FLET or LABELS without getting lots of annoying warning ] messages. Note that I'm not making a permanent *change* to the ] cl-definition - it's only a *temporary* redefinition of it. There's one more hazard you may not have thought of: some macro you use in the body (or even a compiler macro) may expand into code which uses the system function you have shadowed. CLtL2 talks about this on pages 259-261. On the other hand, it sounds like you're willing to take these risks. ] not found a proper way to bind EXCL:*ENABLE-PACKAGE-LOCKED-ERRORS* to ] NIL while compiling and using a macro-definition that expands to a ] function that uses FLET on a cl-symbol. What I have is something like: ] ] (defmacro franz-dislikes-this-macro (&rest body) ] ... ] `(let ((excl:*enable-package-locked-errors* nil)) ] ... ] . ,body)) ] The "let" is bound at the wrong time: at evaluation time, not at compile time. Since you're already doing all these other things, you shouldn't mind using cltl1:compiler-let (defmacro compile-without-package-locks (&rest body) `(cltl1:compiler-let ((excl:*enable-package-locked-errors* nil)) ,@body)) USER(35): (defun test-break (x) (compile-without-package-locks (flet ((break (&rest x) (format t "~&no brakes!"))) (when (> x 3) (break)) (* x x)))) TEST-BREAK USER(36): (test-break 45) no brakes! 2025 ... USER(38): (compile 'test-break) ; While compiling (FLET TEST-BREAK BREAK): Warning: variable X is never used TEST-BREAK T T USER(39): (test-break 45) no brakes! 2025 John (boyland@cs.berkeley.edu) From excl-forum-distribution-owner Thu Apr 29 21:38:40 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238215>; Thu, 29 Apr 1993 21:38:27 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02652; Thu, 29 Apr 93 17:34:54 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA17266; Thu, 29 Apr 93 17:43:19 -0700 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA00898; Thu, 29 Apr 93 17:45:23 PDT Received: by clay.Franz.COM (4.0/FI-2.0) id AA05046; Thu, 29 Apr 93 17:42:56 PDT Date: Thu, 29 Apr 1993 20:42:56 -0400 From: duane@franz.com (Duane Rettig) Message-Id: <9304300042.AA05046@clay.Franz.COM> To: john@linus.mitre.org Class: bh Bh-Id: spr8255 Bh: append spr8255 expire Subject: Re: [spr8255] Labels are slow! Cc: bugs@franz.com, konrad@dfki.uni-sb.de, allegro-cl@ucbvax.berkeley.edu, weber@franz.com >> Could someone from Franz explain some of the issues involved with this >> example, so we users can look for analogous problem spots in our >> current code? Is the problem simply the extra function-call overhead, >> or is it that the LABELS functions are closures, necessitating the >> dreaded COPY-FUNCTION. LABELS and FLET functions are (of course) compiled as closures when lexical variables are closed over. In addition, a LABELS function that refers to another LABELS function (either indirectly by calling it or by treating it as a first-class object) also creates a closure. In the example code: (defun test1 (cnode) (LABELS ((ZGEN-580 NIL (DECLARE (INLINE ZGEN-579)) (OR (AND (EQ CNODE 'A) (ZGEN-579)) (AND (EQ CNODE 'B) (ZGEN-579)) (AND (EQ CNODE 'C) (ZGEN-579)))) (ZGEN-579 NIL (symbolp cnode))) (ZGEN-580))) the variable CNODE is closed over by both LABELS functions. Even if ZGEN-580 did not refer to CNODE, its reference to the closure ZGEN-579 would by itself also have been sufficient to cause it to be implemented as a closure. In Allegro CL 4.1, the creation and calling of closures is slow. We also recognize that in certain cases, some level of "open-coding" can eliminate the internal functions altogether. In order to do so, the internal functions must provably never be used as first-class objects. (There may be some inlinable cases where they are indeed be used as first-class objects, but in no cases can the function objects be made externally visible, e.g. by returning the function, etc.) Our first step in fixing this speed problem was in making closures much more efficient. In Allegro CL 4.2 beta, functions are never copied in order to create closures, and the code itself is much smaller and faster. We have made some further improvements to this in 4.2 beta2 (due out very soon). Our second step will be to enhance the data-flow analysis to recognize those internal functions that are never used as first-class objects, and to transform their code inline. "Inline" here covers a number of techniques beyond simple inlining of the code, but they are semantically equivalent. >> I tend to use internal functions a lot, and I'd really like to know >> what the tradeoffs are, if they're as dramatic as this example seems >> to indicate. It should not be necessary to recode your application to not use internal functions, since we are highly motivated to fix those problems with inlinable cases; you could run the profiler on your code and just modify those functions that show up high on the flat profile. Also, Allegro CL 4.2 should be of immediate help. >> John Burger >> john@mitre.org Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Thu Apr 29 23:32:14 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237431>; Thu, 29 Apr 1993 23:32:02 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02682; Thu, 29 Apr 93 19:27:30 PDT Received: from ames.arc.nasa.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA18032; Thu, 29 Apr 93 19:35:52 -0700 Received: from esl.UUCP by ames.arc.nasa.gov with UUCP id AA14911 (5.65c/IDA-1.4.4); Thu, 29 Apr 1993 14:23:25 -0700 Received: from apogee.ESL.COM by esl.ESL.COM (4.1/SMI-4.1) id AA16262; Thu, 29 Apr 93 14:18:28 PDT Received: from stax.ESL.COM by apogee.ESL.COM (4.1/SMI-4.1) id AA05092; Thu, 29 Apr 93 14:13:06 PDT Date: Thu, 29 Apr 1993 17:13:06 -0400 From: jrd@apogee.esl.com (Jon Degenhardt) Message-Id: <9304292113.AA05092@apogee.ESL.COM> Received: by stax.ESL.COM (4.1/SMI-4.1) id AA05276; Thu, 29 Apr 93 14:15:01 PDT To: Eyvind.Ness@hrp.no Cc: layer@franz.com, bugs@franz.com, weber@franz.com, stu@franz.com, berger@cs.uchicago.edu, allegro-cl@ucbvax.berkeley.edu, jrd@apogee.esl.com Reply-To: jrd@esl.com In-Reply-To: Eyvind Ness's message of Thu, 29 Apr 93 7:14 GMT <9304290714.AA17564@bingen.hrp.no> Subject: [spr8239] package-lock warning messages > Date: Thu, 29 Apr 93 > From: Eyvind.Ness@hrp.no > > ... What is so strange, in my > opinion, is that you can't *locally* override a cl-symbol within the > body of an FLET or LABELS without getting lots of annoying warning > messages. Note that I'm not making a permanent *change* to the > cl-definition - it's only a *temporary* redefinition of it. I'm curious as to why you want to overide a cl-symbol, globaly or locally. The main reason I've seen to do this is to overcome specific problems porting code written for a different language varient. Is there a general programming situation or style where this is the correct problem solving method? --Jon Degenhardt From excl-forum-distribution-owner Fri Apr 30 04:00:55 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237419>; Fri, 30 Apr 1993 04:00:50 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA02759; Fri, 30 Apr 93 00:32:00 PDT Received: from klara.hrp.no by ucbvax.Berkeley.EDU (5.63/1.43) id AA21169; Fri, 30 Apr 93 00:40:31 -0700 Received: from bingen.hrp.no by klara.hrp.no with SMTP (16.6/IFE3.0) id AA27026; Fri, 30 Apr 93 09:37:41 +0200 From: Eyvind Ness Posted-Date: Fri, 30 Apr 93 7:37 GMT Received-Date: Fri, 30 Apr 93 09:37:41 +0200 Received: by bingen.hrp.no ; Fri, 30 Apr 93 09:37:40 +0200 Message-Id: <9304300737.AA12410@bingen.hrp.no> Date: Fri, 30 Apr 1993 03:37:00 -0400 Reply-To: Eyvind.Ness@hrp.no To: jrd@esl.com Cc: layer@franz.com, allegro-cl@ucbvax.berkeley.edu In-Reply-To: <9304292113.AA05092@apogee.ESL.COM> Subject: [spr8239] package-lock warning messages X-Mailer: GNU Emacs 18.58.29 with VM 5.21 (beta) ;; Date: Thu, 29 April 93, 14:13 PDT ;; From: Jon Degenhardt ;; ;; > Date: Thu, 29 Apr 93 ;; > From: Eyvind.Ness@hrp.no ;; > ;; > ... What is so strange, in my ;; > opinion, is that you can't *locally* override a cl-symbol within the ;; > body of an FLET or LABELS without getting lots of annoying warning ;; > messages. Note that I'm not making a permanent *change* to the ;; > cl-definition - it's only a *temporary* redefinition of it. ;; ;; I'm curious as to why you want to overide a cl-symbol, globaly or ;; locally. The main reason I've seen to do this is to overcome specific ;; problems porting code written for a different language varient. Is ;; there a general programming situation or style where this is the ;; correct problem solving method? I warned that I was not interested in discussing the rationale behind such a functionality, but anyway, let me just tell you what I'm doing, if that could make you feel better: I have an eval-server, evaluating random client code. One of the built-in functions that I want to shadow is CL:BREAK, because this function normally will require an interactive debugging environment (which, of course, is non-existent here). My shadow BREAK will print a warning and return immediately. Right now I have to make do with wrapping a general HANDLER-BIND around the client code to be evaluated. Conditions raised by CL:BREAK will be trapped, but I'd rather complete the evaluation with my own version of CL:BREAK. I haven't carefully studied the contents of the condition object raised by CL:BREAK, but my experience so far indicates that there is a general lack of portability in this area - restarts provided by one Lisp implementation is called something different (or doesn't even exist) in other implementations. It's so much simpler to just locally shadow a function binding, and I really cannot see why Franz makes such a fuss about preventing programmers to do it. Eyvind Ness, Research Scientist, OECD Halden Reactor Project, Norway. ~/.signature: No such file or directory ;-) From excl-forum-distribution-owner Fri Apr 30 09:34:12 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237422>; Fri, 30 Apr 1993 09:34:06 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03346; Fri, 30 Apr 93 05:38:17 PDT Received: from yeti.mdcorp.ksc.nasa.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA00254; Fri, 30 Apr 93 05:46:48 -0700 Received: by meglos.mdcorp.ksc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA02341; Fri, 30 Apr 1993 08:45:10 -0400 Date: Fri, 30 Apr 1993 08:45:10 -0400 From: kuznick@meglos.mdcorp.ksc.nasa.gov (david kuznick) Message-Id: <9304301245.AA02341@meglos.mdcorp.ksc.nasa.gov> To: pchu@aplcomm.jhuapl.edu Cc: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu In-Reply-To: chu@server.cs.jhu.edu's message of Thu, 29 Apr 93 12:44:49 -0400 <9304291645.AA05630@Sunset.AI.SRI.COM> Subject: Lisp Conference Announcement Date: Thu, 29 Apr 93 12:44:49 -0400 From: chu@server.cs.jhu.edu Sender: chu@server.cs.jhu.edu Reply-To: pchu@aplcomm.jhuapl.edu I may have just inadvertantly CC'ed my LUV form to a bunch of lisp-related groups. Sorry about that. -- Phil Chu internet: pchu@aplcomm.jhuapl.edu And then I CC'd a followup to everyone too. Sorry all. David Kuznick - kuznick@meglos.mdcorp.ksc.nasa.gov "C++ also supports the notion of 'friends': cooperative classes that are permitted to see each other's private parts" Booch:_Object Oriented Design_ I always said that C++ was a perverted language... From excl-forum-distribution-owner Fri Apr 30 10:52:14 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237426>; Fri, 30 Apr 1993 10:52:06 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03361; Fri, 30 Apr 93 07:12:25 PDT Received: from saguenay.IRO.UMontreal.CA by ucbvax.Berkeley.EDU (5.63/1.43) id AA02966; Fri, 30 Apr 93 07:20:52 -0700 Received: from matagami.iro.umontreal.ca by saguenay.IRO.UMontreal.CA (4.1-SMI/MX) id AA07667; Fri, 30 Apr 93 10:20:48 EDT Return-Path: Date: Fri, 30 Apr 1993 10:20:47 -0400 From: Andre Mayers Message-Id: <9304301420.AA28276@matagami.iro.umontreal.ca> To: Allegro-CL@ucbvax.berkeley.edu Subject: problem with the stepper I don't know how to get rid of the " 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) " when I use the stepper. Someone know the solution or the cause of that. Example: ----------------------------------------------------------- USER(35): (setq *inconnu* (make-instance 'schema-inconnu :r-visuelle "12+34")) # USER(36): (step search**) ; Fast loading from bundle code/step.fasl. 0 USER(37): (interprete *inconnu*) -------------BEFORE------------------ -----------SCHEMA-INCONNU--------------------- vector[3] 0 1 2 no: 1 ** objet-central :# classe-possible :NOMBRES-ENTIERS-POSITIFS syntaxe : #(SYMB+ SUITE-DE-CHIFFRES-CL) PARENT-NIL 1: (SEARCH** (R-PSYCHO SCHEMA) (POS-CIBLE SCHEMA) (CLASSE-POSSIBLE SCHEMA) (SYNTAXE-POSSIBLE SCHEMA)) [step] USER(38): 2: (R-PSYCHO SCHEMA) [step] USER(38): :so result 2: #(# # #) 2: (POS-CIBLE SCHEMA) [step] USER(39): :so result 2: 1 2: (CLASSE-POSSIBLE SCHEMA) [step] USER(40): :so result 2: NOMBRES-ENTIERS-POSITIFS 2: (SYNTAXE-POSSIBLE SCHEMA) [step] USER(41): :so result 2: #(SYMB+ SUITE-DE-CHIFFRES-CL) 2: T => T 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(42): :so result 2: NIL 0: 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(43): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(44): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(45): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(46): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(47): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(48): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(49): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(50): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(51): :so result 2: NIL (SEARCH** #(# # 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(52): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(53): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(54): :so result 2: NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(55): :so result 2: NIL #) 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) [step] USER(56)::so :so result 2: NIL 1 NOMBRES-ENTIERS-POSITIFS #(SYMB+ SUITE-DE-CHIFFRES-CL)) 2: NIL => NIL 2: (BLOCK SEARCH** (LET ((P #)) (COND (# NIL) (# #)))) [step] USER(57): :so result 2: #(# #) 2: NIL => NIL 2: (AND (CONSP EXCL::X) (LET ((EXCL::X #)) (MEMBER EXCL::X '`EXCL::BQ-QUOTE))) ... ... It can be very long ----------------------------------------------------------- Bonne Journee ----------------------------------------- Andre Mayers (mayers@iro.UMontreal.CA) ----------------------------------------- From excl-forum-distribution-owner Fri Apr 30 12:25:16 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237413>; Fri, 30 Apr 1993 12:25:13 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03423; Fri, 30 Apr 93 08:33:52 PDT Received: from thames.ads.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA05370; Fri, 30 Apr 93 08:42:13 -0700 Received: by thames.ads.com (4.1/1.34v1.3) id AA00418; Fri, 30 Apr 93 11:43:29 EDT Date: Fri, 30 Apr 1993 11:43:29 -0400 From: jclose@chesapeake.ads.com (Jeff Close) Message-Id: <9304301543.AA00418@thames.ads.com> To: kuznick@meglos.mdcorp.ksc.nasa.gov Cc: pchu@aplcomm.jhuapl.edu, common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu In-Reply-To: david kuznick's message of Fri, 30 Apr 1993 08:45:10 -0400 <9304301245.AA02341@meglos.mdcorp.ksc.nasa.gov> Subject: Re: Lisp Conference Announcement Reply-To: jclose@ads.com Date: Fri, 30 Apr 1993 08:45:10 -0400 From: kuznick@meglos.mdcorp.ksc.nasa.gov (david kuznick) ... [David's sig:] David Kuznick - kuznick@meglos.mdcorp.ksc.nasa.gov "C++ also supports the notion of 'friends': cooperative classes that are permitted to see each other's private parts" Booch:_Object Oriented Design_ I always said that C++ was a perverted language... Not only that, they refer to these private parts as 'members'. From excl-forum-distribution-owner Mon May 3 06:16:05 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237411>; Mon, 3 May 1993 06:15:56 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06499; Mon, 3 May 93 02:11:49 PDT Received: from relay1.geis.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA24292; Mon, 3 May 93 02:20:05 -0700 Received: by relay1.geis.com (15.11/15.6) id AA06427; Mon, 3 May 93 05:22:06 edt From: agip@geinfosvcs.geis.com Message-Id: <9305030922.AA06427@relay1.geis.com> Date: Mon, 3 May 1993 05:07:00 -0400 To: allegro-cl@ucbvax.berkeley.edu Subject: Unsubscribing... X-Geinfosvcs-Id: 9828945 I'd like to unsubscribe this mailing list, but I can't send a request to the proper address (ie allegro-cl-request), because of its exceeding length. Can anyone do it for me? Thanks. [PC ID 20:123456789:19605] From excl-forum-distribution-owner Tue May 4 11:53:41 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237419>; Tue, 4 May 1993 11:53:35 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07643; Tue, 4 May 93 08:04:26 PDT Received: from vm.nrc.ca by ucbvax.Berkeley.EDU (5.63/1.43) id AA16032; Tue, 4 May 93 08:12:59 -0700 Received: from coursmtp.nrc.ca by VM.NRC.CA (IBM VM SMTP V2R1) with TCP; Tue, 04 May 93 11:11:24 EDT Received: by coursmtp.nrc.ca with Microsoft Mail id <2BE687F7@coursmtp.nrc.ca>; Tue, 04 May 93 11:12:55 EDT From: dJackson@ibd.lan.nrc.ca To: allegro-cl@ucbvax.berkeley.edu Subject: Anyone used ipc.cl? Lisp over TCP/IP? Date: Tue, 4 May 1993 11:09:00 -0400 Message-Id: <2BE687F7@coursmtp.nrc.ca> Encoding: 18 TEXT X-Mailer: Microsoft Mail V3.0 Hi folks, I'd like to set up my Indigo running Allegro CL as a Lisp eval-server (maybe more, let's start with this) to another machine sending requests over TCP/IP. Kevin Layer (layer@franz.com) has pointed me to the code in /lib/code/ipc.cl as a model of how the emacs-lisp connection is done, but I'd like to check whether anyone out there has trod this path before I wander into this unfamiliar land any further. Road maps, anyone? :-) Thanks for your time, -Dick Dick Jackson djackson@ibd.nrc.ca Institute for Biodiagnostics National Research Council Canada Winnipeg From excl-forum-distribution-owner Tue May 4 12:52:48 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237421>; Tue, 4 May 1993 12:52:42 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07658; Tue, 4 May 93 09:00:48 PDT Received: from vm.nrc.ca by ucbvax.Berkeley.EDU (5.63/1.43) id AA17956; Tue, 4 May 93 09:09:21 -0700 Received: from coursmtp.nrc.ca by VM.NRC.CA (IBM VM SMTP V2R1) with TCP; Tue, 04 May 93 12:07:47 EDT Received: by coursmtp.nrc.ca with Microsoft Mail id <2BE6952D@coursmtp.nrc.ca>; Tue, 04 May 93 12:09:17 EDT From: dJackson@ibd.lan.nrc.ca To: allegro-cl@ucbvax.berkeley.edu Subject: Re: Lisp over TCP/IP (clarification!) Date: Tue, 4 May 1993 12:07:00 -0400 Message-Id: <2BE6952D@coursmtp.nrc.ca> Encoding: 12 TEXT X-Mailer: Microsoft Mail V3.0 I realize that my last message didn't quite convey my intent clearly enough. (but thanks to Richard Fateman for the tip on getting the usual emacs-lisp connection to happen across machines) I want an even more tenuous connection, where something OTHER than emacs can send Lisp eval requests, e.g. a Telnet client, or a Lisp running on a slower hardware platform that wants to be a MIPS-parasite to my Indigo! Telnet read/write would seem to be the protocol I'd want to use. Thanks again, -Dick djackson@ibd.nrc.ca From excl-forum-distribution-owner Wed May 12 11:14:48 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237321>; Wed, 12 May 1993 11:14:37 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA15293; Wed, 12 May 93 07:34:13 PDT Received: from sicmail.epfl.ch by ucbvax.Berkeley.EDU (5.63/1.43) id AA08732; Wed, 12 May 93 07:42:51 -0700 Received: from ligsg15.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <10070-0@sicmail.epfl.ch>; Wed, 12 May 1993 16:42:41 +0200 Date: Wed, 12 May 1993 10:42:48 -0400 From: matomira@ligsg15.epfl.ch (Fernando D. Mato Mira) Message-Id: <9305121442.AA05440@ligsg15.epfl.ch> To: allegro-cl@ucbvax.berkeley.edu Subject: Composer presenting listeners for Lemacs? Hello, Sorry, but, has anybody hacked leep.el in order to support Allegro Composer presenting listeners in Lemacs (Lucid Emacs)? Thanks in advance. Fernando D. Mato Mira Computer Graphics Lab "Only CLOS is good enough" Swiss Federal Institute of Technology (EPFL) CH-1015 Lausanne Switzerland matomira@di.epfl.ch NeXTMail : matomira@lignext.epfl.ch (fix pending) FAX : +41 (21) 693 - 5328 From excl-forum-distribution-owner Thu May 13 05:13:47 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237326>; Thu, 13 May 1993 05:13:33 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA16072; Thu, 13 May 93 01:22:20 PDT Received: from fhg.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA13617; Thu, 13 May 93 01:30:39 -0700 Received: by fhg.de (mail-gw.fhg.de) with PRESMTP; Thu, 13 May 93 10:30:20 +0200 from FHG-GATEWAY Received: by fhg.de (mail-gw.fhg.de) with SMTP; Thu, 13 May 93 10:30:13 +0200 from rabbit.isst.fhg.de Message-Id: <9305130830.AA23732@fhg.de> Received: from iapetus by rabbit.isst.fhg.de with SMTP (PP) id <07767-0@rabbit.isst.fhg.de>; Thu, 13 May 1993 10:28:54 +0200 Date: Thu, 13 May 1993 05:28:54 -0400 To: Allegro-CL@ucbvax.berkeley.edu From: ulrich.kriegel@isst.fhg.de (E. Ulrich Kriegel) X-Sender: ukriegel@isst.fhg.de Subject: compiling methods Hello from Berlin, I need your help to solve two problems: 1. even when I call in ACL4.1 excl:dumplisp with the :restart-function the named function does not start after loading the dump - thats my minor problem 2. for a certain reason I cannot :cf a lot of files of my project - ancompiler for EuLisp. So we collect all functions and call compile for each of them after loading our compiler. However a lot is done using generic functions and methods. Is there an equivalent to compile for methods or what else can I do to speed up my system. Thanks in advance --ulrich --------------------------------------------------------- Dr. E.Ulrich Kriegel, ulrich.kriegel@isst.fhg.de, (++49 30) 20372-346 Fraunhofer Institute for Software Engineering and Systems Engineering (FhG ISST), Kurstrasse 33, D-O-1086 Berlin, FRG fax: (++49 30) 20372-207 ==> ATTN: new ZIP # (valid from July 1st, 1993) D-10117 Berlin ===================================================================== From excl-forum-distribution-owner Mon May 17 10:19:56 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237361>; Mon, 17 May 1993 10:19:48 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA19814; Mon, 17 May 93 06:28:44 PDT Received: from mammoth.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA28217; Mon, 17 May 93 06:37:08 -0700 Received: from [139.165.32.1] by mammoth.Berkeley.EDU (5.61/1.37) id AA24800; Mon, 17 May 93 06:36:44 -0700 Received: from montefiore.ulg.ac.be by vm1.ulg.ac.be (IBM VM SMTP V2R2) with TCP; Mon, 17 May 93 15:28:51 +0200 Received: from [192.91.200.75] by montefiore.ulg.ac.be (4.1/SMI-4.1) id AA07564; Mon, 17 May 93 15:30:28 +0200 Message-Id: <9305171330.AA07564@montefiore.ulg.ac.be> Date: Mon, 17 May 1993 10:36:21 -0400 To: CLIM Bulletin Board From: "Vincent Keunen" X-Sender: vk@montefiore.ulg.ac.be Subject: Info on the CLIM library (long msg.) Cc: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu, info-mcl@cambridge.apple.com I recently received a number of requests regarding the clim library. Here is a summary of what's going on. I took the liberty to forward this message to a number of lisp related mailing lists because it seems some of the people requesting information were not aware of the existence of the list. I apologize to all of you who are not interested in clim. Vincent Keunen ------------------------------------------- General information about the clim-library: The clim-library is a repository for user contributed code for the clim environment. CLIM is "Common Lisp Interface Manager", the standard being developed and supported by most lisp providers (Symbolics, Lucid, Franz, Harlequin, Apple,...). Access is available to anyone by anonymous ftp. Ask your system manager if you don't know how to ftp from your machine. Do a ftp to cambridge.apple.com (134.149.2.3), enter "anonymous" as user-id, then @ as the password. Use the ftp "cd pub/clim" command to change to the correct directory and try "dir" to see the directory. (use "help" to see other ftp commands) To get files use the ftp "get" command, to put your files on the server, use "put". There is also a mailing list discussing CLIM: send a request for subscription to clim-request@bbn.com Here is a list of the current contents of the library: 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls (0 bytes). total 20 -rw-rw-rw- 1 ftp camb 2584 Apr 28 18:55 ABSTRACTS.clim-library -rw-rw-rw- 1 ftp camb 1072 Aug 26 1992 README.clim-library drwxrwxrwx 5 ftp camb 1024 Apr 21 21:11 clim-1 drwxrwxrwx 5 ftp camb 512 May 4 12:48 clim-1-and-2 drwxrwxrwx 2 ftp camb 512 Apr 20 14:42 clim-2 drwxrwxrwx 2 ftp camb 512 Sep 10 1992 mail-archives drwxrwxrwx 2 ftp camb 512 Dec 2 16:42 papers ./clim-1: total 2466 -rw-rw-rw- 1 ftp camb 3441 Mar 12 09:11 accept-multiple-fields-swm.text -rw-rw-rw- 1 ftp camb 3624 Oct 8 1992 bboard-pane.lisp -rw-rw-rw- 1 ftp camb 16891 Sep 14 1992 bitblt.lisp -rw-rw-rw- 1 ftp camb 8617 Oct 30 1992 change-mouse-glyph.lisp -rw-rw-rw- 1 ftp camb 728071 Jun 3 1992 clim-demo.sit.hqx -rw-rw-rw- 1 ftp camb 4973 Feb 17 14:41 clim-tests-framework.lisp -rw-rw-rw- 1 ftp camb 10867 Oct 8 1992 clos-inspector.lisp -rw-rw-rw- 1 ftp camb 8254 Oct 12 1992 color-presentation-type.lisp drwxrwxrwx 2 ftp camb 512 Apr 20 16:31 ctv-menu -rw-rw-rw- 1 ftp camb 17505 Mar 9 10:31 custom-records.lisp -rw-rw-rw- 1 ftp camb 113147 Mar 15 21:30 dir-mgr.tar.Z drwxrwxrwx 2 ftp camb 512 Apr 22 08:52 ed -rw-rw-rw- 1 ftp camb 34445 Apr 22 08:49 ed.tar.Z -rw-rw-rw- 1 ftp camb 82424 Mar 3 19:30 fast-tables.lisp -rw-rw-rw- 1 ftp camb 1672 Mar 2 00:54 fast-tables.readme -rw-rw-rw- 1 ftp camb 10669 Oct 28 1992 icon-examples.lisp -rw-rw-rw- 1 ftp camb 14393 Oct 28 1992 icons-stuff-from-j-close.lisp -rw-rw-rw- 1 ftp camb 2867 Mar 12 09:11 incremental-redisplay-swm.text -rw-rw-rw- 1 ftp camb 24398 Mar 18 14:58 input-editor-patches.lisp -rw-rw-rw- 1 ftp camb 61830 Mar 17 11:15 kytron.lisp -rw-rw-rw- 1 ftp camb 17086 Sep 9 1992 multiple-menus.lisp -rw-rw-rw- 1 ftp camb 11175 Nov 4 1992 ordered-menu-items.lisp -rw-rw-rw- 1 ftp camb 21694 Oct 8 1992 peek-clim.lisp -rw-rw-rw- 1 ftp camb 7153 Oct 26 1992 picture-buttons.lisp drwxrwxrwx 2 ftp camb 512 Apr 21 21:14 postscript -rw-rw-rw- 1 ftp camb 9823 Dec 11 18:17 recycle-presentations-and-output-records.lisp -rw-rw-rw- 1 ftp camb 9035 Mar 10 16:45 working-cursor.lisp ./clim-1/ctv-menu: total 126 -rw-rw-rw- 1 ftp camb 374 Apr 20 16:36 README -rw-rw-rw- 1 ftp camb 55171 Apr 20 16:31 ctv-menu.lisp -rw-rw-rw- 1 ftp camb 1582 Apr 20 16:31 display-env.lisp ./clim-1/ed: total 192 -rw-rw-rw- 1 ftp camb 3465 Apr 22 08:51 README -rw-rw-rw- 1 ftp camb 2842 Apr 22 08:51 ed-commands-doc.lisp -rw-rw-rw- 1 ftp camb 2434 Apr 22 08:51 ed-commands.lisp -rw-rw-rw- 1 ftp camb 3548 Apr 22 08:51 ed-packages.lisp -rw-rw-rw- 1 ftp camb 6391 Apr 22 08:51 ed-stream.lisp -rw-rw-rw- 1 ftp camb 31101 Apr 22 08:51 ed.lisp -rw-rw-rw- 1 ftp camb 1378 Apr 22 08:51 ed.system -rw-rw-rw- 1 ftp camb 2551 Apr 22 08:51 site-specific.lisp -rw-rw-rw- 1 ftp camb 9963 Apr 22 08:52 wed-frame-commands.lisp -rw-rw-rw- 1 ftp camb 10321 Apr 22 08:52 wed-frame.lisp -rw-rw-rw- 1 ftp camb 1997 Apr 22 08:52 wed-stream.lisp -rw-rw-rw- 1 ftp camb 15766 Apr 22 08:52 wed.lisp ./clim-1/postscript: total 262 -rw-rw-rw- 1 ftp camb 26983 Apr 23 21:13 post-init.lisp -rw-rw-rw- 1 ftp camb 79779 Apr 23 21:13 postscript.lisp -rw-rw-rw- 1 ftp camb 19600 Apr 23 21:13 ps-doc.txt ./clim-1-and-2: total 6 drwxrwxrwx 2 ftp camb 512 May 4 12:48 contrib drwxrwxrwx 2 ftp camb 512 May 4 12:48 dwim drwxrwxrwx 5 ftp camb 512 Apr 28 17:51 scigraph ./clim-1-and-2/contrib: total 0 ./clim-1-and-2/dwim: total 0 ./clim-1-and-2/scigraph: total 486 -rw-rw-rw- 1 ftp camb 3091 May 4 12:50 README drwxrwxrwx 2 ftp camb 512 Apr 28 16:44 contrib drwxrwxrwx 2 ftp camb 512 Apr 28 17:49 dwim drwxrwxrwx 2 ftp camb 1024 Apr 28 17:51 scigraph -rw-rw-rw- 1 ftp camb 234639 May 4 12:51 scigraph.tar.Z ./clim-1-and-2/scigraph/contrib: total 0 ./clim-1-and-2/scigraph/dwim: total 330 -rw-rw-rw- 1 ftp camb 10767 May 4 12:48 draw.lisp -rw-rw-rw- 1 ftp camb 3886 May 4 12:48 dwim-system.lisp -rw-rw-rw- 1 ftp camb 8615 May 4 12:48 export.lisp -rw-rw-rw- 1 ftp camb 15001 May 4 12:48 extensions.lisp -rw-rw-rw- 1 ftp camb 5082 May 4 12:48 feature-case.lisp -rw-rw-rw- 1 ftp camb 4246 May 4 12:48 load-dwim.lisp -rw-rw-rw- 1 ftp camb 25546 May 4 12:48 macros.lisp -rw-rw-rw- 1 ftp camb 3405 May 4 12:48 package.lisp -rw-rw-rw- 1 ftp camb 35907 May 4 12:48 present.lisp -rw-rw-rw- 1 ftp camb 27660 May 4 12:48 tv.lisp -rw-rw-rw- 1 ftp camb 22551 May 4 12:48 wholine.lisp ./clim-1-and-2/scigraph/scigraph: total 890 -rw-rw-rw- 1 ftp camb 21721 May 4 12:48 annotated-graph.lisp -rw-rw-rw- 1 ftp camb 33646 May 4 12:48 annotations.lisp -rw-rw-rw- 1 ftp camb 10129 May 4 12:49 axis.lisp -rw-rw-rw- 1 ftp camb 4628 May 4 12:49 basic-classes.lisp -rw-rw-rw- 1 ftp camb 22875 May 4 12:49 basic-graph.lisp -rw-rw-rw- 1 ftp camb 7957 May 4 12:49 color.lisp -rw-rw-rw- 1 ftp camb 9967 May 4 12:49 contour.lisp -rw-rw-rw- 1 ftp camb 10728 May 4 12:49 copy.lisp -rw-rw-rw- 1 ftp camb 6209 May 4 12:49 demo-frame.lisp -rw-rw-rw- 1 ftp camb 24864 May 4 12:49 draw.lisp -rw-rw-rw- 1 ftp camb 4749 May 4 12:49 dump.lisp -rw-rw-rw- 1 ftp camb 5414 May 4 12:49 duplicate-methods.lisp -rw-rw-rw- 1 ftp camb 4252 May 4 12:49 duplicate.lisp -rw-rw-rw- 1 ftp camb 15094 May 4 12:49 equation.lisp -rw-rw-rw- 1 ftp camb 4690 May 4 12:49 export.lisp -rw-rw-rw- 1 ftp camb 10157 May 4 12:49 frame.lisp -rw-rw-rw- 1 ftp camb 7244 May 4 12:49 graph-classes.lisp -rw-rw-rw- 1 ftp camb 43347 May 4 12:49 graph-data.lisp -rw-rw-rw- 1 ftp camb 30304 May 4 12:49 graph-mixins.lisp -rw-rw-rw- 1 ftp camb 10288 May 4 12:49 legend.lisp -rw-rw-rw- 1 ftp camb 2219 May 4 12:49 load-scigraph.lisp -rw-rw-rw- 1 ftp camb 11555 May 4 12:49 menu-tools.lisp -rw-rw-rw- 1 ftp camb 16327 May 4 12:49 mouse.lisp -rw-rw-rw- 1 ftp camb 24989 May 4 12:49 moving-object.lisp -rw-rw-rw- 1 ftp camb 1934 May 4 12:49 package.lisp -rw-rw-rw- 1 ftp camb 17699 May 4 12:50 popup-accept-methods.lisp -rw-rw-rw- 1 ftp camb 11544 May 4 12:50 popup-accept.lisp -rw-rw-rw- 1 ftp camb 14426 May 4 12:50 present.lisp -rw-rw-rw- 1 ftp camb 14002 May 4 12:50 random.lisp -rw-rw-rw- 1 ftp camb 2355 May 4 12:50 scigraph-system.lisp -rw-rw-rw- 1 ftp camb 25200 May 4 12:50 scigraph.doc -rw-rw-rw- 1 ftp camb 7648 May 4 12:50 symbol.lisp ./clim-2: total 3718 -rw-rw-rw- 1 ftp camb 15332 Aug 28 1992 chooser.lisp -rw-rw-rw- 1 ftp camb 9706 Sep 25 1992 clim-2-draft-spec.readme -rw-rw-rw- 1 ftp camb 1841516 Sep 25 1992 clim.ps -rw-rw-rw- 1 ftp camb 8219 Dec 18 15:35 indented-lists.lisp -rw-rw-rw- 1 ftp camb 17056 Apr 20 22:38 multiple-menus.lisp -rw-rw-rw- 1 ftp camb 3115 Mar 5 16:56 xhardcopy.lisp ./mail-archives: total 2296 -rw-rw-rw- 1 ftp camb 50685 Sep 10 1992 clim-archive-1990.Z -rw-rw-rw- 1 ftp camb 363681 Sep 10 1992 clim-archive-1991.Z -rw-rw-rw- 1 ftp camb 743901 Sep 10 1992 clim-archive-1992.Z ./papers: total 6 -rw-rw-rw- 1 ftp camb 2092 Dec 2 16:42 CLIB-paper.readme 226 Transfer complete. Vincent -- Keunen Vincent R&D, Software Engineer keunen@montefiore.ulg.ac.be tel: +32 41 407282 fax: +32 41 481170 From excl-forum-distribution-owner Thu May 20 13:44:22 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237312>; Thu, 20 May 1993 13:44:12 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA22393; Thu, 20 May 93 10:16:38 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA06242; Thu, 20 May 93 10:25:14 -0700 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA20510; Thu, 20 May 93 10:26:39 PDT Received: by clay.Franz.COM (4.0/FI-2.0) id AA22072; Thu, 20 May 93 10:25:09 PDT Date: Thu, 20 May 1993 13:25:09 -0400 From: duane@franz.com (Duane Rettig) Message-Id: <9305201725.AA22072@clay.Franz.COM> To: ulrich.kriegel@isst.fhg.de Class: bh Bh-Id: spr8404 Bh: append spr8404 Subject: Re: [spr8404] compiling methods Cc: bugs@franz.com, nuket@franz.com, allegro-cl@ucbvax.berkeley.edu Your problem report has been assigned tracking id spr8404. Please use it in the subject line of any correspondences regarding your problem report. >> Hello from Berlin, >> I need your help to solve two problems: >> 1. even when I call in ACL4.1 excl:dumplisp with the :restart-function the >> named function does not start after loading the dump - thats my minor >> problem Can you send me a test case that I can reproduce here? If you send me a simple restart function and the exact dumplisp command you used which failed to restart properly, I can try to figure out what is wrong. >> 2. for a certain reason I cannot :cf a lot of files of my project - >> ancompiler for EuLisp. So we collect all functions and call compile for >> each of them after loading our compiler. However a lot is done using >> generic functions and methods. Are you saying that those files in your project are EuLisp source files, as opposed to Allegro CL source files? If so, you might want to consider making a top-level alias like ":ecf" which would compile the EuLisp files in the same way as :cf compiles CL files. >> Is there an equivalent to compile for methods or what else can I do to >> speed up my system. I assume that you want to know how to name meethods so that you can compile them. First, to get a list of methods for a generic function, call clos:generic-function-methods with the generic function as an argument. You will get a list of methods. For each of these methods, clos::method-to-definition-spec will return a name that you can use as arguments to most Allegro CL functions that accept a function name (including compile, disassemble, fboundp, fdefinition, etc.) In general, method names are of the form (method ( ...)) I will await your reply to deal with question #1. Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Fri May 21 16:38:08 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237329>; Fri, 21 May 1993 16:38:01 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA23371; Fri, 21 May 93 12:49:19 PDT Received: from Mail.Think.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA21840; Fri, 21 May 93 12:58:00 -0700 Received: from Think.COM by mail.think.com; Fri, 21 May 93 15:56:45 -0400 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Fri, 21 May 93 15:56:26 EDT Date: Fri, 21 May 1993 15:56:00 -0400 From: Barry Margolin Reply-To: luv-93-organizer@ai.sri.com Subject: LUV-93 Announcement To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, info-dylan@cambridge.apple.com, scheme@mc.lcs.mit.edu, news.comp.emacs@think.com, news.comp.object@think.com Included-Msgs: <930520162217_76470.3334_EHC52-1@CompuServe.COM>, The message of 20 May 1993 12:22 EDT from 76470.3334@compuserve.com, The message of 20 May 1993 12:22 EDT from An Event To Remember Message-Id: <19930521195614.8.BARMAR@occam.think.com> Please don't reply to me; email questions should be sent to luv-93-organizer@ai.sri.com. And definitely don't cc your reply to all the original recipients! ------Begin Forwarded Message------ Date: Thu, 20 May 1993 12:22 EDT From: An Event To Remember <76470.3334@compuserve.com> To: Barry Margolin Subject: LUV-93 Announcement -------------------REGISTRATION INFORMATION!!!!!!--------------------------- LUV'93:Third International Lisp Users and Vendors Conference August 9-13, 1993:Cambridge Marriott, Cambridge, MA Lisp and Education ---------------------------------------------------------------------------- Order of contents: Program information Location/Accomodations Special Airfare Tutorial Schedule/Descriptions Registration Form PROGRAM The Association of Lisp Users is pleased to announce the Third International Lisp Users and Vendors Conference. Sponsored by the Association of Lisp Users and vendors of Lisp and Lisp-based products, including Franz, Lucid, Harlequin, Venue,and Itasca. LUV '93 will be another opportunity for users to exchange ideas and promote the benefits of the Lisp programming language. The Association of Lisp Users is the voice of the international Lisp user community. By holding our annual conference, we promote communication and the dissemination of information between the vendors of Lisp and Lisp applications, and the users of these products. Our opinions are sought by the Lisp industry, most of which is well represented at our annual conference. The theme for LUV '93 is Lisp and Education. For over 20 years, Lisp has been used to teach advanced computer science topics at major universities. Now, introductory computer science courses are being taught using dialects of Lisp, allowing students to concentrate on basic concepts and principles instead of mechanics. Many of the features of Lisp that make it a popular language for education have also caused Industry to embrace Lisp. They have done this by learning to use the Lisp-based extension languages embedded in popular applications, such as AutoCAD, GNU Emacs, and Interleaf. In this year's conference, Monday and Tuesday are dedicated to improving Lispers' software engineering skills through two days of tutorials. Featured speakers will include David Moon of Apple Computer, Inc. on Wednesday along with technical & paper presentations. Special interest group meetings will also be held Wednesday. On Thursday the vendors will be making presentations about their lastest products. Friday the Annual Meeting will be held followed by the traditional no-cost tutorial (topic still to be determined). LOCATION/ACCOMODATIONS This year the conference returns to the birthplace of Lisp and one of the primary centers of the present day Lisp community, Cambridge, MA. Our host hotel is the Cambridge Marriott, conveniently located at the Kendall Square station on the red line and adjacent to MIT. Nearby Boston attractions include Harvard Square, Beacon Hill and Feneuil Hall Marketplace. A limited number of rooms have been reserved at a conference rate of $98 single & $108 double/night. Please complete the housing form indicating your hotel preferences and reservations will be made for you and guaranteed for late arrival (after 6pm) if you include a credit card number. Any changes in your reservations before August 1st should be directed to An Event To Remember, the conference organizers; changes after August 1st should be made directly with the hotel. SPECIAL AIRFARE The Association of Lisp Users has designated Carlson Travel Network/Pack n' Go Travel as the official travel agency for LUV '93. Pack n' Go Travel can arrange for travel from any point of origin and guarantee the best airfare on the market. Even after tickets have been issued, CTN/Pack n' Go Travel continues to monitor airfares and can reticket to obtain a lower fare if one becomes available. The Association of Lisp Users has also negotiated special conference airfares through Continental Airlines. Each participant will receive 5% off the lowest available fare when booked through CTN/Pack n' Go Travel. Please call CTN/Pack n' Go Travel to make your flight arrangements: Carlson Travel Network/Pack n' Go Travel 347 North Pottstown Pike, Exton, PA 19341 1-800-937-2256 TUTORIAL SCHEDULE/DESCRIPTIONS Monday Tutorials Monday AM: CLOS I: Object-Oriented Programming in Common Lisp This half day tutorial is an introduction to the Common Lisp Object System, the object oriented extention to the proposed ANSI standard Common Lisp. Attendees are expected to be familiar with Common Lisp programming concepts.(Instructor: Allan Wechsler,Symbolics,Inc.) Interfacing Lisp with Other Languages Lisp applications can access code written in other programming languages via Foreign Function Interfaces (FFIs). The primary focus of this tutorial will be to show how C code and data may be used within Common Lisp. Examples will be drawn from UNIX and possibly PC Common Lisp implementations. (Instructor: Charley Cox, Franz Inc.) GNU EMACS Lisp Programming This half day tutorial will present the EMACS expension language, EMACS Lisp which allows users to not only customize the popular EMACS editor, but also allows the development of active documents applications that interact with the user. (Instructor: to be determined) Monday PM: CLOS II-Advanced CLOS and the Meta-Object Protocol This tutorial will cover meta-object protocols for CLOS as well as existing implementational techniques and their consequences. Also to be covered are advanced topics such as complex initializations protocols. A good understanding of CLOS as well as Lisp is assumed. (Instructor: Jon L. White, Lucid, Inc.) Metaprogramming using Macros The Common Lisp macro facility is extremely powerful, but it's advanced features can be difficult to use. Learn when and how to use macros to improve your coding style and productivity. (Instructor: Allan Wechsler,Symbolics,Inc.) Closures, Continuations, and Coroutines The "continuation passing" style of programming is a powerful technique that can be used to implement a number of useful control structures, including backtracking and coroutines, in a simple and elegant manner. Continuation passing can be confusing if you are not familiar with it, but this tutorial will teach you to understand and write programs using this technique. (Instructor: Louis Steinberg, Rutgers Univ.) Tuesday Tutorials Tuesday AM: CLIM I This tutorial will show how to use the Common Lisp Interface Manager to build interfaces to appllication programs. Topics to be covered include application frames,presentations,menus and dialogs,commands,command tables, interaction styles, and drawing graphics. Knowledge of Lisp is assumed. (Instructor: to be determined) Common Lisp for Scheme Programmers This tutorial will introduce Scheme Lisp programming to experienced Common Lisp programmers. Scheme programming concepts will be presented in a way that allows experienced Common lisp programmers to contrast these two main stream Lisp dialects. (Instructor: Allan Wechsler,Symbolics,Inc.) Good Lisp Programming Style This tutorial will present good Lisp programming style heuristics. It will deal with style issues at the individual function level as well as at the complete system level.(Instructor: to be determined) Tuesday PM: CLIM II This tutorial builds on the concepts covered in CLIM I(a pre- requisite to taking this course). Topics to be covered include hardcopy, pointer manipulation,tracking the pointer, incremental redisplay,table and graph formatting,drawing in color,the drawing environment, and doing transformations.(Instructor: to be determined) Scheme for Common Lisp Programmers This tutorial will introduce Common Lisp programming to experienced Scheme Lisp programmers. Common Lisp programming concepts will be presented in a way that allows experienced Scheme Lisp programmers to contrast these two main stream Lisp dialects. (Instructor: Allan Wechsler,Symbolics,Inc.) Optimizing Lisp Code This tutorial will first present some general guidelines to optimizing Lisp code that can be used regardless of specific Lisp system details. Then specific details will be presented that are more relevant to a given Lisp compiler implementation. Topics will include profiling, some common algorithmic optimizations, consing, declarations and type checking, garbage collection, using C code, arrays and delivery considerations. (Instructor: Jim Veitch, Franz Inc.) -------------------REGISTRATION FORM--------------------------------------- (PRINT HARDCOPY, NO REGISTRATIONS ACCEPTED VIA E-MAIL!!!) Name:_______________________________________ Company:____________________________________ Address:____________________________________ City:_______________________________________ State (Country):____________________________Zip:_______________ Telephone:( )______________________Fax:( )______________ Electronic Mail:___________________________________(please print clearly) Please circle programs and fees:ft student rec before on-site (circle one per time period) or academic 6/30/93 (after 6/30/93) Mon. AM -CLOS I $50.00 $125.00 $175.00 tutorial -Interfacing -GNU EMACS Mon. PM -CLOS II $50.00 $125.00 $175.00 tutorial -Macrology -Closures Tues.. AM -CLIM I $50.00 $125.00 $175.00 tutorial -CL for Scheme -Good Style Tues. PM -CLIM II $50.00 $125.00 $175.00 tutorial -Scheme for CL -Optimization Wednesday-Friday session $100.00 $400.00 $500.00 Total Enclosed:_________ HOTEL RESERVATIONS: Housing preference: single double Room Mate:____________ Arrival date:____________Departure date:_____________ Credit card information (to guarantee late arrival ONLY): please circle AMEX DC MC VISA Account #:__________________________________Exp. date:_____________ Signature:__________________________________ ABSOLUTELY NO REGISTRATIONS WILL BE ACCEPTED VIA E-MAIL!!!!!!! International attendees may FAX registrations at any time. Domestic attendees may only FAX registrations after July 15th. Mail with check or money order made payable(US funds only) to: ALU, P.O. Box 294, Malvern, PA 19355-0294,attn: LUV '93 Registration (we are sorry but we can not accept credit cards for registration fees) for US Govt purchase orders,please contact An Event To Remember,215-651-2990 REGISTRATIONS WILL BE CONFIRMED IN WRITTING BY MAIL OR FAX. Cancellations in writing before June 18th receive 50% refund,afterwards 25% -------ABSOLUTELY NO REGISTRATIONS WILL BE ACCEPTED VIA E-MAIL!!!!!!!------- ------End Forwarded Message------ From excl-forum-distribution-owner Sun May 23 11:47:17 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.cs.toronto.edu with SMTP id <237334>; Sun, 23 May 1993 11:47:03 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA25433; Sun, 23 May 93 08:28:04 PDT Received: from SILVER.LCS.MIT.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA12822; Sun, 23 May 93 08:36:48 -0700 Received: by silver.lcs.mit.edu id AA09999; Sun, 23 May 93 11:35:52 -0400 Date: Sun, 23 May 1993 11:35:52 -0400 From: acw@silver.lcs.mit.edu (Allan C. Wechsler) Message-Id: <9305231535.AA09999@silver.lcs.mit.edu> To: luv-93-organizer@ai.sri.com Cc: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, scheme@mc.lcs.mit.edu, news.comp.emacs@think.com, news.comp.object@think.com In-Reply-To: Barry Margolin's message of Fri, 21 May 1993 15:56 -0400 <19930521195614.8.BARMAR@occam.think.com> Subject: LUV-93 Announcement I apologize for the wide distribution, but I felt a correction to the recent announcement by the LUV-93 organizers was necessary. To wit: I do not work for Symbolics, not represent them in any way. I'm doing my tutorials at LUV-93 as a private contractor. (Plug: My services are available. Call me to discuss your Lisp training needs.) Allan C. Wechsler 32 Poplar St. Belmont, MA 02178-4427 617-484-3647 acw@silver.lcs.mit.edu From excl-forum-distribution-owner Mon May 24 14:08:45 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.cs.toronto.edu with SMTP id <238227>; Mon, 24 May 1993 14:08:28 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26035; Mon, 24 May 93 10:43:27 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA11756; Mon, 24 May 93 10:52:11 -0700 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA29174; Mon, 24 May 93 10:53:36 PDT Received: by clay.Franz.COM (4.0/FI-2.0) id AA25255; Mon, 24 May 93 10:52:04 PDT Date: Mon, 24 May 1993 13:52:04 -0400 From: duane@franz.com (Duane Rettig) Message-Id: <9305241752.AA25255@clay.Franz.COM> To: ulrich.kriegel@isst.fhg.de Class: bh Bh-Id: spr8404 Bh: append spr8404 expire Subject: Re: [spr8404] compiling methods Cc: bugs@franz.com, nuket@franz.com, allegro-cl@ucbvax.berkeley.edu >> (eval-when (load eval compile) >> (defvar *my-readtable* (copy-readtable *readtable*)) >> (defun apply-restart() >> (setq debugging::*ti-verbose* nil) >> (if (boundp '*my-readtable*) >> (setq *readtable* *my-readtable*))) >> (excl:dumplisp :name "apply" >> :restart-function #'apply-restart >> :checkpoint nil)) Ah, yes; *readtable*! The basic problem is that the restart function is being executed before, and therefore outside of the context of, the initial top-level listener. The variable *readtable* is one of those "globals" that are not truly global with respect to multiprocewssing, and so it gets rebound for each process. You can work around this in several ways. Instead of using setq, you can use tpl:setq-default (described in the user guide, page 2-16). Or, you can remove *readtable* from the alist described on page 2-18. Or, if you are using multiprocessing and want the original readtable for normal CL operation in other processes, you can simply setq the readtable in the desired process before you do the dumplisp. Let me know if one of these methods does not solve your problem. Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Tue May 25 14:25:06 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237319>; Tue, 25 May 1993 14:24:58 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA26897; Tue, 25 May 93 10:30:12 PDT Received: from uni-sb.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA24751; Tue, 25 May 93 10:38:45 -0700 Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930513) id AA18211; Tue, 25 May 93 19:38:36 +0200 Received: from disco-elc5.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA01648; Tue, 25 May 93 19:41:11 +0200 Date: Tue, 25 May 1993 13:43:58 -0400 Message-Id: <9305251743.AA06324@disco-elc5> Received: by disco-elc5; Tue, 25 May 93 19:43:58 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: oe@dfki.uni-sb.de (Stephan Oepen) To: allegro-cl@ucbvax.berkeley.edu Subject: `bandwidth' of Allegro CL -- Emacs interface Reply-To: oe@dfki.uni-sb.de dear friends, we are running Allegro CL with {GNU Emacs | Epoch} interface version 2.0.4 from Epoch 4.2 _with_ EIGHT_BIT_KEYBOARD (or whatever that variable was called) defined. --- hence, when using fonts with appropriate iso 8859/1 encoding Epoch can input and display 8 bit characters. among other things, we are doing german morphology in our system (remember: `ue' and `sz' in ``es mueszte gehen'' usually are single characters over here |:-) so that it would be kind of useful to be able to input those to Allegro CL (which itself seems to be perfectly happy about 8 bit characters though as far as i know there is nothing really requesting that capability in CLtL2). the default of course was to not have it work (on input through Epoch bit 7 got stripped --- input from file and output worked fine); after forcing Epoch to settle the communication channel on pipes instead of on ptys (by setting `process-connection-type' to nil) things seem to work fine. so, i figure there is something affecting only the input in ptys (or does the printout from the lisp world come back to Epoch some other way) --- anyone out there with a reasonable explanation? (oh, yes: stty(1) tells me the pty is setup `cs8', no parity, `-strip'.) however, the main question remains: do i loose any of the Allegro -- {GNU Emacs | Epoch} interface capabilities when running on pipes? thanx - oe btw: as long as we are awaiting bash 1.13 ... is there a decent shell that can handle 8 bit input yet? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84 ;;; - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From excl-forum-distribution-owner Fri May 28 09:29:01 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237332>; Fri, 28 May 1993 09:28:54 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA29412; Fri, 28 May 93 03:43:54 PDT Received: from [134.96.7.230] by ucbvax.Berkeley.EDU (5.63/1.43) id AA25974; Fri, 28 May 93 03:52:20 -0700 Received: from dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930528) id AA28717; Fri, 28 May 93 12:52:07 +0200 Received: from disco-elc5.dfki.uni-sb.de with SMTP by dfki.uni-sb.de (5.65/UniSB-2.2/DFKI-1.0/061991) id AA03401; Fri, 28 May 93 12:52:08 +0200 Date: Fri, 28 May 1993 06:57:26 -0400 Message-Id: <9305281057.AA09498@disco-elc5> Received: by disco-elc5; Fri, 28 May 93 12:57:26 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: oe@dfki.uni-sb.de (Stephan Oepen) To: allegro-cl@ucbvax.berkeley.edu Subject: `bandwidth' of Allegro CL -- Emacs interface Reply-To: oe@dfki.uni-sb.de dear friends, we are running Allegro CL with {GNU Emacs | Epoch} interface version 2.0.4 from Epoch 4.2 _with_ EIGHT_BIT_KEYBOARD (or whatever that variable was called) defined. --- hence, when using fonts with appropriate iso 8859/1 encoding Epoch can input and display 8 bit characters. among other things, we are doing german morphology in our system (remember: `ue' and `sz' in ``es mueszte gehen'' usually are single characters over here |:-) so that it would be kind of useful to be able to input those to Allegro CL (which itself seems to be perfectly happy about 8 bit characters though as far as i know there is nothing really requesting that capability in CLtL2). the default of course was to not have it work (on input through Epoch bit 7 got stripped --- input from file and output worked fine); after forcing Epoch to settle the communication channel on pipes instead of on ptys (by setting `process-connection-type' to nil) things seem to work fine. so, i figure there is something affecting only the input in ptys (or does the printout from the lisp world come back to Epoch some other way) --- anyone out there with a reasonable explanation? (oh, yes: stty(1) tells me the pty is setup `cs8', no parity, `-strip'.) however, the main question remains: do i loose any of the Allegro -- {GNU Emacs | Epoch} interface capabilities when running on pipes? thanx - oe btw: as long as we are awaiting bash 1.13 ... is there a decent shell that can handle 8 bit input yet? ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84 ;;; - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From excl-forum-distribution-owner Tue Jun 1 13:36:25 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237346>; Tue, 1 Jun 1993 13:36:17 -0400 Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by centralsparc.Berkeley.EDU (4.1/1.42) id AA02787; Tue, 1 Jun 93 09:48:22 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA01871; Tue, 1 Jun 93 09:57:10 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA06997; Tue, 1 Jun 93 09:58:10 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA00515; Tue, 1 Jun 93 09:59:52 PDT Message-Id: <9306011659.AA00515@sole.Franz.COM> To: allegro-cl@ucbvax.berkeley.edu Subject: GNU Emacs 19.8 (or later) and the Allegro Emacs-Lisp interface Date: Tue, 1 Jun 1993 12:59:52 -0400 From: Kevin Layer Content-Length: 958 Since 19.8 (through .10) was released in the last week, I thought I'd head off the avalanche of questions regarding the Franz emacs-lisp interface. We believe that the emacs-lisp interface will work with GNU Emacs 19.x (were x is > 7). The only thing that will not work is the presenting lisp listeners in Allegro Composer--that works currently only under Epoch. Regarding lemacs 19.x (where x < 8), the same comments above apply, except there is a problem with the `mark' command (it was changed incompatibly in lemacs) and some things might be a little weird (C-c C-p, for example, works the first time only). In the next month or two I expect to have another public release of the emacs-lisp interface, and I expect it will work better with all `current' versions of emacs. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Wed Jun 2 12:15:36 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237353>; Wed, 2 Jun 1993 12:15:24 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03537; Wed, 2 Jun 93 08:20:51 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA05596; Wed, 2 Jun 93 08:29:39 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA00399; Wed, 2 Jun 93 08:30:26 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA08149; Wed, 2 Jun 93 08:32:20 PDT Message-Id: <9306021532.AA08149@sole.Franz.COM> To: oe@dfki.uni-sb.de Class: bh Bh-Id: spr8482 Bh: append spr8482 Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8482] `bandwidth' of Allegro CL -- Emacs interface Date: Wed, 2 Jun 1993 11:32:19 -0400 From: Kevin Layer Content-Length: 1021 >> after >> forcing Epoch to settle the communication channel on pipes instead of >> on ptys (by setting `process-connection-type' to nil) things seem to >> work fine. >> >> so, i figure there is something affecting only the input in ptys (or >> does the printout from the lisp world come back to Epoch some other >> way) --- anyone out there with a reasonable explanation? (oh, yes: >> stty(1) tells me the pty is setup `cs8', no parity, `-strip'.) I don't understand what the problem with "input in ptys" you are talking about. Please explain. >> however, the main question remains: do i loose any of the Allegro -- >> {GNU Emacs | Epoch} interface capabilities when running on pipes? I didn't know about the variable process-connection-type until I read your message. I suspect that it should have no effect, but I can't say for sure. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Tue Jun 8 04:23:48 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237317>; Tue, 8 Jun 1993 04:23:41 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA03785; Tue, 8 Jun 93 00:15:10 PDT Received: from ames.arc.nasa.gov by ucbvax.Berkeley.EDU (5.63/1.43) id AA25573; Tue, 8 Jun 93 00:24:03 -0700 Received: from esl.UUCP by ames.arc.nasa.gov with UUCP id AA12336 (5.65c/IDA-1.4.4 for allegro-cl@ucbvax.berkeley.edu); Tue, 8 Jun 1993 00:00:16 -0700 Received: from apogee.ESL.COM by esl.ESL.COM (4.1/SMI-4.1) id AA15937; Mon, 7 Jun 93 12:43:42 PDT Received: from stax.ESL.COM by apogee.ESL.COM (4.1/SMI-4.1) id AA17289; Mon, 7 Jun 93 12:40:29 PDT Date: Mon, 7 Jun 1993 15:40:29 -0400 From: jrd@apogee.esl.com (Jon Degenhardt) Message-Id: <9306071940.AA17289@apogee.ESL.COM> Received: by stax.ESL.COM (4.1/SMI-4.1) id AA17721; Mon, 7 Jun 93 12:40:22 PDT To: allegro-cl@ucbvax.berkeley.edu Cc: jrd@apogee.esl.com Reply-To: jrd@esl.com Subject: CLIM indentation and the Allegro Emacs-Lisp interface I'm looking for emacs indentation definitions for CLIM operators which work with the Allegro Emacs-Lisp interface. Does anyone know of a good set? Here's what I have so far: (put 'surrounding-output-with-border 'fi:lisp-indent-hook 1) (put 'indenting-output 'fi:lisp-indent-hook 1) (put 'accepting-values 'fi:lisp-indent-hook 1) (put 'define-application-frame 'fi:lisp-indent-hook '(like defclass)) I'm pretty sure these are not the best, but they do work better than none at all. Thanks, --Jon Degenhardt From excl-forum-distribution-owner Tue Jun 8 09:29:58 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237315>; Tue, 8 Jun 1993 09:29:49 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA04349; Tue, 8 Jun 93 05:36:09 PDT Received: from deneb.dfn.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA06132; Tue, 8 Jun 93 05:44:49 -0700 Received: from fbihh.informatik.uni-hamburg.de by deneb.dfn.de (4.1/SMI-4.2) id AA01756; Tue, 8 Jun 93 14:43:00 +0200 Received: from ki6.informatik.uni-hamburg.de by fbihh.informatik.uni-hamburg.de (5.65+/FBIHH-1.6) with SMTP; id AA20213; Tue, 8 Jun 93 14:43:09 +0200 Received: from ki11.informatik.uni-hamburg.de by ki6.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA10271; Tue, 8 Jun 93 14:47:51 +0200 Date: Tue, 8 Jun 1993 08:47:51 -0400 From: lothar@ki6.informatik.uni-hamburg.de (Lothar Hotz) Message-Id: <9306081247.AA10271@ki6.informatik.uni-hamburg.de> Received: by ki11.informatik.uni-hamburg.de (4.1/SMI-4.1) id AA05531; Tue, 8 Jun 93 14:48:15 +0200 To: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Cc: lothar@fbhihh.informatik.uni-hamburg.de Subject: Is this a bug or not? Hey fans, Define: (defclass meta1 (standard-class) ()) in one file, and compile and load this file. Define: (defclass my-metaclass (meta1) ()) (defclass my-class () () (:metaclass my-metaclass)) in another file (say meta-error.lisp), compiling this file leads to: USER(395): (compile-file "meta-error.lisp") ; --- Compiling file /users/lothar/prokon/konwerk-obk/meta-error.lisp --- ; While compiling (:TOP-LEVEL-FORM "meta-error.lisp" 2): Error: While computing the class precedence list of the class named META1. The class named META1 is a forward referenced class. The class named META1 is a direct superclass of the class named META1. [condition type: PROGRAM-ERROR] Restart actions (select using :continue): 0: retry the compilation of /users/lothar/prokon/konwerk-obk/meta-error.lisp 1: continue compiling /users/lothar/prokon/konwerk-obk/meta-error.lisp but generate no output file [changing package from "COMMON-LISP-USER" to "CLOS"] [1] CLOS(396): Having all definitions in one file, or separating the definition of my-class in another file, or simply loading the file meta-error.lisp lead to the desired behaviour (i.e. defining the classes without an error). The problem might occure because meta1 is not known in the compiler environment, there for a forward referenced class is created...? Are there any other solutions as separating definitions in files? Best wishes lothar Lothar Hotz University of Hamburg phone: +49-40-4123-6536 Departement of Computer Science fax: +49-40-4123-6530 Bodenstedtstrasse 16 email: HOTZ@fbihh.informatik.uni-hamburg.de 2000 Hamburg 50 Germany From excl-forum-distribution-owner Tue Jun 8 10:14:49 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237315>; Tue, 8 Jun 1993 10:14:46 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA04371; Tue, 8 Jun 93 06:29:54 PDT Received: from watson.ibm.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA07895; Tue, 8 Jun 93 06:38:41 -0700 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3759; Tue, 08 Jun 93 09:38:39 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 5783; Tue, 8 Jun 1993 09:38:37 EDT Received: from emerax6.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 08 Jun 93 09:38:37 EDT Received: by emerax6.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA14896; Tue, 8 Jun 1993 09:38:35 -0400 Date: Tue, 8 Jun 1993 09:38:35 -0400 From: jsp@watson.ibm.com (Scott Penberthy) Message-Id: <9306081338.AA14896@emerax6.watson.ibm.com> To: jrd@esl.com Cc: allegro-cl@ucbvax.berkeley.edu, jrd@apogee.esl.com In-Reply-To: Jon Degenhardt's message of Mon, 7 Jun 93 12:40:29 PDT <9306071940.AA17289@apogee.ESL.COM> Subject: CLIM indentation and the Allegro Emacs-Lisp interface Jon, I've attached some indentation hackery that I find useful. Cheers, Scott (put 'defclass 'fi:common-lisp-indent-hook 2) (put 'menu-choose-from-drawer 'fi:common-lisp-indent-hook 2) (put 'with-text-face 'fi:common-lisp-indent-hook 1) (put 'with-menu 'fi:common-lisp-indent-hook 1) (put 'with-translation 'fi:common-lisp-indent-hook 1) (put 'define-ucpop-command 'fi:common-lisp-indent-hook 2) (put 'formatting-item-list 'fi:common-lisp-indent-hook 1) (put 'formatting-cell 'fi:common-lisp-indent-hook 1) (put 'with-output-as-presentation 'fi:common-lisp-indent-hook 1) (put 'with-text-style 'fi:common-lisp-indent-hook 1) (put 'accepting-values 'fi:common-lisp-indent-hook 1) (put 'surrounding-output-with-border 'fi:common-lisp-indent-hook 1) (put 'define-border-type 'fi:common-lisp-indent-hook 2) (put 'with-output-to-output-record 'fi:common-lisp-indent-hook 1) (put 'with-room-for-graphics 'fi:common-lisp-indent-hook 1) From excl-forum-distribution-owner Tue Jun 8 13:40:45 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237318>; Tue, 8 Jun 1993 13:40:40 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA04470; Tue, 8 Jun 93 09:53:25 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA14657; Tue, 8 Jun 93 10:02:14 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA10735; Tue, 8 Jun 93 10:03:04 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA16307; Tue, 8 Jun 93 10:04:55 PDT Message-Id: <9306081704.AA16307@sole.Franz.COM> To: jrd@apogee.esl.com Class: bh Bh-Id: spr8563 Bh: append spr8563 Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8563] GNU Emacs 19.8 (or later) and the Allegro Emacs-Lisp interface Date: Tue, 8 Jun 1993 13:04:54 -0400 From: Kevin Layer Content-Length: 1913 >> If your planning another public release of the Allegro Emacs-Lisp >> interface, perhaps you could add in some CLIM indentation definitions. >> Your CLIM developers may have a set they use. I just sent a message to >> allegro-cl about this also. Already done. I've included them below so you can use them now (by inserting the below form into your .emacs). Be sure to put it before the load of fi/site-init.el, so when you get the new release of the emacs-lisp interface any changes will supercede what you put in your .emacs. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 (let ((tag 'fi:common-lisp-indent-hook)) ;; for clim 2.x (put 'dolist-noting-progress tag '(like dolist)) (put 'dotimes-noting-progress tag '(like dolist)) (put 'indenting-output tag 1) (put 'filling-output tag 1) (put 'dragging-output tag 1) (put 'noting-progress tag 1) (put 'vertically tag 1) (put 'bulletin-board tag 1) (put 'scrolling tag 1) (put 'horizontally tag 1) (put 'bordering tag 1) (put 'spacing tag 1) (put 'outlining tag 1) (put 'tabling tag 1) (put 'labelling tag 1) (put 'updating-output tag 1) (put 'surrounding-output-with-border tag 1) (put 'formatting-item-list tag 1) (put 'formatting-table tag 1) (put 'formatting-row tag 1) (put 'formatting-column tag 1) (put 'formatting-cell tag 1) (put 'tracking-pointer tag 1) (put 'with-bounding-rectangle* tag 2) (put 'with-scaling tag 1) (put 'with-rotation tag 1) (put 'with-presentation-type-decoded tag 1) (put 'letf-globally tag 1) (put 'horizontally tag 1) (put 'catch-abort-gestures tag 1) (put 'accepting-values tag 1) (put 'accept-values-command-button tag 1) (put 'changing-space-requirements tag 1) (put 'define-application-frame tag '(like defclass)) ) From excl-forum-distribution-owner Wed Jun 9 19:17:35 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237321>; Wed, 9 Jun 1993 19:17:31 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA05683; Wed, 9 Jun 93 15:45:19 PDT Received: from cayuga.cs.rochester.edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA06743; Wed, 9 Jun 93 15:54:10 -0700 Received: from artery.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/y) id AA16064; Wed, 9 Jun 93 18:54:12 -0400 Received: by artery.cs.rochester.edu (5.61/y) id AA26748; Wed, 9 Jun 93 18:54:06 -0400 Date: Wed, 9 Jun 1993 18:54:06 -0400 From: miller@cs.rochester.edu Message-Id: <9306092254.AA26748@artery.cs.rochester.edu> To: allegro-cl@ucbvax.berkeley.edu Subject: locatives; supported-p? alternatives-p? Hi, I've got an algorithm that's begging for locatives (i.e. for those of you who don't recall lispms: a way to refer to, say, the car or cdr of a cons cell (for destructive update) w/o having the cell in front of you). My question is, is there some version of these (even "internal" that I can use inside a (with-all-due-respect ...))? Application: Lets call "?x" a variable. Variables can have values, and can become unbound (via backtracking), but you can't assign a variable to have a different value than it already has. (yep, prolog model of assignment). here's what a "list" might look like... thanks to binding variables to lists of other variables... where -> denotes a binding. (?x->:b . ?y->(?z->:c . ?q->nil)) to denote the list (:b :c) Now the reason locatives come in handy: when we bind ?x, it would be extremely handy to update the locative for ?x in the above list with the binding. In this manner the above list would be represented (at some point in the run time) as (:b :c) and if we, e.g. backtrack the binding to ?q we'd update the locative to put back the variable, e.g. (:b :c . ?q) I'm pursuing this, because it turns out about 70% or so of the time my system uses to run some benchmarks is in examining such lists, and getting rid of the variables. Instead of where it should be spending most of the time: in unification. I realize I can keep track of all parent cons cells instead of having direct locatives, or use extensible vectors and offsets instead of lists; right now I'm looking for the highest efficiency solution which would seem to be the locative. Extensible vectors are slower than lists for small sizes (I've metered), esp. on consing up new vectors. Other suggestions are welcome, of course! Thanks for taking the time to read this!! Brad Miller miller@cs.rochester.edu From excl-forum-distribution-owner Thu Jun 10 16:10:23 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237322>; Thu, 10 Jun 1993 16:10:20 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06411; Thu, 10 Jun 93 12:18:36 PDT Received: from acrab.cs.sfu.ca by ucbvax.Berkeley.EDU (5.63/1.43) id AA18802; Thu, 10 Jun 93 12:27:32 -0700 Received: by acrab.cs.sfu.ca id AA04488 (5.65c/IDA-1.4.4 for allegro-cl@ucbvax.berkeley.edu); Thu, 10 Jun 1993 12:27:29 -0700 Date: Thu, 10 Jun 1993 15:27:29 -0400 From: Gary Hall Message-Id: <199306101927.AA04488@acrab.cs.sfu.ca> To: allegro-cl@ucbvax.berkeley.edu Subject: Allegro news group subscription request Please include me in the Allegro news group. Gary Hall | Voice (604) 291-3208 | INTERNET: hall@cs.sfu.ca Centre for Systems Science | Fax (604) 291-4424 | Simon Fraser University | Burnaby, B.C. V5A 1S6 | From excl-forum-distribution-owner Thu Jun 10 17:35:12 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237321>; Thu, 10 Jun 1993 17:35:05 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06474; Thu, 10 Jun 93 13:43:19 PDT Received: from bunny.gte.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA22094; Thu, 10 Jun 93 13:52:10 -0700 Received: from centauri by bunny.gte.com (5.61/GTEL2.19) id AA22257; Thu, 10 Jun 93 16:52:05 -0400 Received: by centauri.gte.com (4.1/SMI-4.1) id AA01700; Thu, 10 Jun 93 16:54:15 EDT Date: Thu, 10 Jun 1993 16:54:15 -0400 From: mr04%centauri@gte.com (M. Rajini Kanth) Message-Id: <9306102054.AA01700@centauri.gte.com> To: allegro-cl@ucbvax.berkeley.edu Subject: Allegro news group subscription Please remove me from the Allegro news group... mr04@gte.com --M. Rajini Kanth From excl-forum-distribution-owner Thu Jun 10 18:17:59 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237325>; Thu, 10 Jun 1993 18:17:53 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA06513; Thu, 10 Jun 93 14:25:34 PDT Received: from centralsparc.Berkeley.EDU by ucbvax.Berkeley.EDU (5.63/1.43) id AA23760; Thu, 10 Jun 93 14:34:15 -0700 Received: by centralsparc.Berkeley.EDU (4.1/1.42) id AA06512; Thu, 10 Jun 93 14:25:09 PDT Date: Thu, 10 Jun 1993 17:25:09 -0400 Message-Id: <9306102125.AA06512@centralsparc.Berkeley.EDU> From: Allegro-CL-request@ucbvax.berkeley.edu Sender: cox@ucbvax.berkeley.edu Reply-To: allegro-cl-request@ucbvax.berkeley.edu To: allegro-cl@ucbvax.berkeley.edu Subject: Administrivia Reminder Reminder: If you want your address added, deleted, or changed on this list, the place to send your requests is to Allegro-CL-request@Berkeley.EDU [case doesn't matter] This is the normal convention for network mailing lists (ie, requests for list 'list@host' go to 'list-request@host'). Since this is an open and unmoderated list, anything sent to the "Allegro-CL@Berkeley.EDU" address is immediately forwarded to the subscribers. Charley Cox Allegro-CL-request@Berkeley.EDU From excl-forum-distribution-owner Fri Jun 11 13:18:12 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <238222>; Fri, 11 Jun 1993 13:17:31 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA07283; Fri, 11 Jun 93 09:54:21 PDT Received: from atc.boeing.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA24714; Fri, 11 Jun 93 10:03:17 -0700 Received: by atc.boeing.com (5.57) id AA20318; Fri, 11 Jun 93 10:07:25 -0700 Return-Path: bha <@ada3.ca.boeing.com:bha@gumby> Received: from gumby.ata by ada3.ca.boeing.com; Fri, 11 Jun 93 10:03 PDT Received: from fritz.ata by gumby.ata (4.1/SMI-4.1) id AA10630; Fri, 11 Jun 93 10:01:58 PDT Received: by fritz.ata (4.1/SMI-4.1) id AA10536; Fri, 11 Jun 93 10:01:52 PDT Date: Fri, 11 Jun 1993 13:01:58 -0400 From: bha <@ada3.ca.boeing.com:bha@gumby.boeing.com> Subject: Communicating Lisp images To: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu Message-Id: <9306111701.AA10630@gumby.ata> Hi: X-Envelope-To: allegro-cl@berkeley.edu Do you have any examples/samples of code that facilitates communication between two ACL images? What I want to do is implement a simple eval server where an ACL image (4.2beta) acts as a client and communicates with an ICAD image (ACL 4.1beta) acting as a server. I suppose that I would also need this mechanism to start the ICAD image in a synchronous manner if it was not already running such that the client could communicate with it. I presume that one could do this with the stuff in ipc.cl from the distribution but was hoping that there was something laying around that I could use out of the box. Thanks for any pointers. ba Brian H. Anderson (206) 234-0881 Boeing Commercial Airplane Co. bha@gumby.boeing.com P.O. Box 3707 M.S. 6A-PX Seattle, Wa. 98124-2207 From excl-forum-distribution-owner Mon Jun 14 04:51:06 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237343>; Mon, 14 Jun 1993 04:50:55 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA09982; Mon, 14 Jun 93 01:10:03 PDT Received: from sics.se by ucbvax.Berkeley.EDU (5.63/1.43) id AA24692; Mon, 14 Jun 93 01:18:58 -0700 Received: from tarrega.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA01260; Mon, 14 Jun 93 10:18:46 +0200 Received: by tarrega.sics.se (5.65+bind 1.7+ida 1.4.2/SICSclient-1.1) id AA08732 (for cutting@sics.se); Mon, 14 Jun 93 10:18:45 +0200 Date: Mon, 14 Jun 1993 04:18:45 -0400 From: cutting@sics.se Message-Id: <9306140818.AA08732@tarrega.sics.se> To: bha%gumby.boeing.com@ada3.ca.boeing.com Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu In-Reply-To: bha's message of Fri, 11 Jun 1993 10:01:58 PDT <9306111701.AA10630@gumby.ata> Subject: Communicating Lisp images Date: Fri, 11 Jun 1993 10:01:58 PDT From: bha Do you have any examples/samples of code that facilitates communication between two ACL images? What I want to do is implement a simple eval server where an ACL image (4.2beta) acts as a client and communicates with an ICAD image (ACL 4.1beta) acting as a server. We've used the following in ACL 4.1, mostly to talk to lisp from shell scripts, but it also works from lisp to lisp. A sample client is given at the end. Enjoy. Doug (eval-when (compile eval load) (require :ipc) (require :process)) (cl:defpackage :eval-service (:use :common-lisp :ipc :mp) (:export *eval-service-port* eval-server *eval-server-stream* force-prin1)) (cl:in-package :eval-service) (defvar *eval-service-port* 4322) (defvar *eval-server-stream* nil) (defun eval-server (&key (port *eval-service-port*) (binds `((*package* ,(find-package :cl-user)))) background) (start-lisp-listener-daemon :use-lep t :inet-port port :binds binds) (unless background (process-wait "waiting" #'(lambda (p) (not (process-active-p p))) (process-name-to-process "TCP Listener Socket Daemon")))) (defmethod start-process-for-network-stream (stream (p (eql :eval-service)) &rest args) (apply #'process-run-function (read stream) #'eval-server-proc stream args)) (defun eval-server-proc (stream &key binds &allow-other-keys) (unwind-protect (eval-server-loop stream binds) (excl::clear-output-1 stream) (close stream))) (defvar *tracing* t) (defun eval-server-loop (stream binds &aux (process-name (process-name *current-process*))) (handler-bind ((stream-error #'(lambda (condition) (when *tracing* (format *error-output* "~&; ~A EXITING: ~?~%" process-name (simple-condition-format-control condition) (simple-condition-format-arguments condition))) (return-from eval-server-loop)))) (let ((*eval-server-stream* stream) (*print-pretty* nil)) (progv (mapcar #'car binds) (mapcar #'cadr binds) (when *tracing* (format *error-output* "~&; ~A OPEN~%" process-name)) (loop (let ((form (error-trapping-read stream))) (case form (:exit (return)) (:error (force-prin1 :error stream)) (t (force-prin1 (error-trapping-eval form) stream))))) (when *tracing* (format *error-output* "~&; ~A EXIT~%" process-name)))))) (defun force-prin1 (obj stream) (prin1 obj stream) (terpri stream) (force-output stream)) (defun error-trapping-read (stream) (handler-bind ((simple-error #'(lambda (condition) (when *tracing* (format *error-output* "~&; ~A READ ERROR: ~?~%" (process-name *current-process*) (simple-condition-format-control condition) (simple-condition-format-arguments condition))) ;; skip the rest of the input ;; assume each input is contained on one line (when (listen) (read-line stream)) (return-from error-trapping-read :error)))) (read stream))) (defun error-trapping-eval (form &aux (process-name (process-name *current-process*))) (when *tracing* (let ((*print-length* 5) (*print-level* 3)) (format *error-output* "~&; ~A > ~S~%" process-name form))) (handler-bind ((simple-error #'(lambda (condition) (when *tracing* (format *error-output* "~&; ~A EVAL ERROR: ~?~%" process-name (simple-condition-format-control condition) (simple-condition-format-arguments condition))) ;; all errors return :ERROR (return-from error-trapping-eval :error)))) (eval form))) ;;;; simple client (defun remote-exec (host) ;; client side (let ((stream (open-network-stream :host host :port *eval-service-port*))) ;; first send type of connection and name (force-prin1 :eval-service stream) (force-prin1 (format nil "~A@~A" (system:getenv "USER") (system:getenv "HOST")) stream) (loop (format t "~A > " host) (let ((input (read))) (force-prin1 input stream) (when (eq input :exit) (return)) (force-prin1 (read stream) *standard-output*))))) From excl-forum-distribution-owner Thu Jun 17 18:59:31 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237364>; Thu, 17 Jun 1993 18:59:24 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA12777; Thu, 17 Jun 93 14:56:58 PDT Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA14848; Thu, 17 Jun 93 15:05:51 -0700 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA12989; Thu, 17 Jun 93 15:03:42 PDT Date: Thu, 17 Jun 1993 18:03:42 -0400 From: smh@franz.com (Steve Haflich) Message-Id: <9306172203.AA12989@akbar.Franz.COM> To: lothar@ki6.informatik.uni-hamburg.de Class: bh Bh-Id: spr8565 Bh: append spr8565 expire Subject: Re: [spr8565] Is this a bug or not? Cc: bugs@franz.com, lothar@fbhihh.informatik.uni-hamburg.de, allegro-cl@ucbvax.berkeley.edu [This matter has been assigned the tracking identifier "spr8565". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] From: lothar@ki6.informatik.uni-hamburg.de (Lothar Hotz) To: bugs@Franz.COM, allegro-cl@ucbvax.berkeley.edu Subject: Is this a bug or not? Define: (defclass meta1 (standard-class) ()) in one file, and compile and load this file. Define: (defclass my-metaclass (meta1) ()) (defclass my-class () () (:metaclass my-metaclass)) in another file (say meta-error.lisp), compiling this file leads to: USER(395): (compile-file "meta-error.lisp") ; --- Compiling file /users/lothar/prokon/konwerk-obk/meta-error.lisp --- ; While compiling (:TOP-LEVEL-FORM "meta-error.lisp" 2): Error: While computing the class precedence list of the class named META1. The class named META1 is a forward referenced class. The class named META1 is a direct superclass of the class named META1. [condition type: PROGRAM-ERROR] Having all definitions in one file, or separating the definition of my-class in another file, or simply loading the file meta-error.lisp lead to the desired behaviour (i.e. defining the classes without an error). The problem might occure because meta1 is not known in the compiler environment, there for a forward referenced class is created...? Are there any other solutions as separating definitions in files? I've been giving this question some thought. I think the issue itself is a lot clearer than what the language standards say about it. It you look through CLtL2, there is no explicit discussion whether a class defined during a file compilation may be used as the :METACLASS for a DEFCLASS in the same file. However, the explicit requirements on COMPILER-FILE procesing of a DEFCLASS at top level of a file (CLtL2 p.690) -- only that the class name may be used in the same file as a DEFMETHOD specializer and in type declarations -- suggest that use in :METACLASS is not portable. In addition, one can make a good argument why such a guarantee would impose impossible problems on the MOP. Since the MOP needs to operate using class objects, and since the MOP needs to operate at compile-file time (at least if expected optimizations are to be possible), then an instance of the metaclass must be created at compile-file time. But in general the appearance of a DEFCLASS at compile-file time does _not_ make that class instantiable at compile time, so it's hard to see how a DEFCLASS can be used subsequently in the same file as a metaclass. The fact that it works in _some_ simple test cases is in part accidental; certainly you can't in a single file write any _methods_ on the metaclass and expect them to operate at compile time, and the existence of specialized methods is the usual reason for defining your own metaclass. Unfortunately, if you accept this line of reasoning, we still need to contend with the draft ANSI spec. I was quite surprised to notice that it adds the requirement (dpANS p.7-65): "[The] compiler must make this class name ... be recognized as a valid class name ... for use as the :metaclass option of a subsequent defclass." (This statement is actually pretty vague as it stands. Any symbol that isn't exported from the COMMON-LISP package is a "valid" class name, at least syntacically, so presumably the intention here of "valid" is that the usage won't signal error. But that requires that the metaclass must be instantiable, and this requirement isn't placed on any other defclass forms. What's worse, the fact that a defclass will be used as a metaclass isn't even discernable from the defclass itself; it only becomes evident when the defclass that uses it is encountered.) I'm a member of X3J13, and I don't remember this change ever being considered by the committee. I suspect it was an innocent editorial cleanup that wasn't carefully considered for its implications. I'm asking around X3J13 to figure out how this happened, and I'll probably try to get it removed. From excl-forum-distribution-owner Wed Jun 23 08:16:08 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237324>; Wed, 23 Jun 1993 08:15:54 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA18508; Wed, 23 Jun 93 04:32:41 PDT Received: from uhics.ics.Hawaii.Edu by ucbvax.Berkeley.EDU (5.63/1.43) id AA09280; Wed, 23 Jun 93 04:41:46 -0700 Received: from (zilch.ics.Hawaii.Edu) by uhics.ics.Hawaii.Edu (4.1/SMI-4.1) id AA02165; Wed, 23 Jun 93 01:40:30 HST Received: by (4.1/zilch.ics.Hawaii.Edu) id AA17583; Wed, 23 Jun 93 01:40:28 HST From: nayak@uhics.ics.hawaii.edu Illegal-Object: Syntax error in Message-Id: value found on relay.cs.toronto.edu: Message-Id: <9306231140.AA17583@> ^-illegal subdomain in domain Subject: Need help in building a stand alone lisp binary To: allegro-cl@ucbvax.berkeley.edu Date: Wed, 23 Jun 1993 07:40:25 -0400 X-Mailer: ELM [version 2.3 PL11] Hi, I get the following error when I try to build a lisp binary. Basically I am trying the install.sh script given in technical memo #19: "Delivering applications written in ACL". The error occurs when ucl is run. Basically this is my output. For people who know of this sort of thing the error occurs when ucl is run when making $(binary) in the Makefile Mf. If this is of any use we are running SunOS 4.1.3 on a Sparc 1 - 10. -- Venkatesh Nayak Grad Student ICS, UH Manoa ---------------------- Creating user.blob from /usr/ics/cl/build/cl-train-devel.cvs.Z /home/3/nayak/ttchen/app-wrap.cvs processed from standard input, read 3015 codevector(s) dropped 337 replications Dropped 980 duplicates Wrote 1697 vectors, 1215512 bytes to /tmp/cvs17010 rcp /tmp/cvs17010 nfs.ics:/home/3/nayak/ttchen/user.blob rm /tmp/cvs17010 creating /tmp/cvs17010 from user.blob (1215512 bytes) rcp /tmp/cvs17010 nfs.ics:/home/3/nayak/ttchen/static.o rm /tmp/cvs17010 /bin/mv cl_nih ../lib rm -f ucl nm -go ucl | sed 's/.* \([^ ]*\)$/\1/' | grep -v ' U ' | sort | uniq > uclsyms for i in `comm -12 removesyms uclsyms`; do /usr/ics/cl/build/bin/symbash -s $i -f ucl; done rm -f uclsyms Initial generation spread = 1 Allocated 12587064 bytes for old space Allocated 2097152 bytes for new space ; fasl-bundle skipping file sys/startup.fasl... sendsig: bad signal stack pid=17094, sig=10 sigsp = 0xf7863d80, action = 0x55a9f8, upc = 0x17d14 sh: 17094 Illegal instruction - core dumped *** Error code 132 make: Fatal error: Command failed for target `/home/3/nayak/ttchen/app-wrap' newspace=300k oldspace=256k compiler=no devel=no xcw=no composer=no From excl-forum-distribution-owner Thu Jun 24 14:48:08 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237325>; Thu, 24 Jun 1993 14:47:57 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA21125; Thu, 24 Jun 93 11:09:40 PDT Received: from linus.mitre.org by ucbvax.Berkeley.EDU (5.63/1.43) id AA12269; Thu, 24 Jun 93 11:18:45 -0700 Return-Path: Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S) id AA21804; Thu, 24 Jun 93 14:18:41 -0400 Posted-Date: Thu, 24 Jun 93 14:18:37 -0400 Received: by thelonius.mitre.org (5.61/RCF-4C) id AA06642; Thu, 24 Jun 93 14:18:38 -0400 Message-Id: <9306241818.AA06642@thelonius.mitre.org> To: allegro-cl@ucbvax.berkeley.edu Subject: Allegro CL 4.2beta2.0 Date: Thu, 24 Jun 1993 14:18:37 -0400 From: john@linus.mitre.org Howdy - We just received version 4.2beta2.0 of ALCL, and I'm wondering what to expect. I intend to fully read the accompanying release notes, but I thought I'd get a little information as quickly as possible. My questions are directed at users who have this release, as well as Franz folks. For context, we run principally on Sparc2s and a Sparc10. My understanding is that the compiler is quite a bit smarter in this release. What sort of speed (and memory) improvements might we notice if we did nothing at all to our code? (We currently have fairly minimal declarations.) What would we gain with more liberal declarations (that we wouldn't have gained from the previous release)? Finally, are there any "gotcha"s that other users have run into, that aren't delineated in the release notes? Thanks for any information you can provide. John Burger john@mitre.org From excl-forum-distribution-owner Thu Jun 24 17:22:25 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237316>; Thu, 24 Jun 1993 17:22:19 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA21221; Thu, 24 Jun 93 13:35:47 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA19330; Thu, 24 Jun 93 13:44:50 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA28897; Thu, 24 Jun 93 13:45:37 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA26054; Thu, 24 Jun 93 13:45:19 PDT Message-Id: <9306242045.AA26054@sole.Franz.COM> To: john@linus.mitre.org Class: bh Bh-Id: spr8691 Bh: append spr8691 Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu, stu@franz.com Subject: Re: [spr8691] Allegro CL 4.2beta2.0 Date: Thu, 24 Jun 1993 16:45:09 -0400 From: Kevin Layer Content-Length: 774 Allegro CL 4.2.beta2.0 fulfills three requirements: - it runs on Solaris 2.1 or later - it runs the newest version of CLIM (2.0.beta2.0) - it has optimized since the ACL 4.1 release The compiler is smarter, the size of compiled functions are smaller, and the system has generally been optimized a bit more than ACL 4.1. There is not a big difference in the types of declarations to which the compiler pays attention. As for "gotchas", this release, especially the Solaris 2.x version, is very new. We will not be widely distributing this beta release because it is just that, beta software. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Fri Jun 25 12:19:03 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237331>; Fri, 25 Jun 1993 12:18:59 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA22016; Fri, 25 Jun 93 08:46:09 PDT Received: from nttta.NTT.JP by ucbvax.Berkeley.EDU (5.63/1.43) id AA21033; Fri, 25 Jun 93 08:55:08 -0700 Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Fri, 25 Jun 93 16:24:01 JST Received: by YECL.ntt.jp (4.1/NTTcs02b) with TCP; Fri, 25 Jun 93 16:25:08 JST Received: by ntttsd.ntt.jp (4.1/NTTcs02b) with TCP; Fri, 25 Jun 93 16:23:58 JST Message-Id: <9306250723.AA03008@ntttsd.ntt.jp> To: allegro-cl@ucbvax.berkeley.edu Subject: Accesing CLOS objects from C? Date: Fri, 25 Jun 1993 03:23:56 -0400 From: Kazunobu Kashiwabuchi Hi, I am making a c function which can be a CLOS-method or a part of it. To establish this functionality, CLOS objects should be accessed directly from C functions. Unfortunately, unlike other basic LISP objects(e.g. LIST, FIXNUM), the structure of CLOS-objects are not described in lib/misc/lisp.h. Does anyone know how to access CLOS-objects from C? Or am I doing dirty work?? I think the easiest way is that at first CLOS-object is cut into basic LISP object by CLOS-methods and then passed into C functions and the return values are composed again into CLOS-object. But I think this will cost a lot of overhead. I am also interested at this point. Any comment is appreciated. Thanks in advance. 'buchi Kashiwabuchi Kazunobu Transport Processing Laboratory NTT Transmission Systems Labs. From excl-forum-distribution-owner Mon Jun 28 13:37:57 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237344>; Mon, 28 Jun 1993 13:37:49 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00214; Mon, 28 Jun 93 09:36:15 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA19960; Mon, 28 Jun 93 09:45:22 -0700 Return-Path: Received: from clay.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA05180; Mon, 28 Jun 93 09:44:46 PDT Received: by clay.Franz.COM (4.0/FI-2.0) id AA10577; Mon, 28 Jun 93 09:43:51 PDT Date: Mon, 28 Jun 1993 12:43:51 -0400 From: duane@franz.com (Duane Rettig) Message-Id: <9306281643.AA10577@clay.Franz.COM> To: nayak@uhics.ics.hawaii.edu Class: bh Bh-Id: spr8675 Bh: append spr8675 expire Subject: Re: [spr8675] Need help in building a stand alone lisp binary Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu >> ./config +defaults temp=/tmp config_debug=yes \ >> binary=$HOME/ttchen/app-wrap library=../lib \ ;;-----------------------------------^^^^^^^^^^^^^^ >> restart_function=application-top-level $sdir/app-wrap.fasl \ >> +presto stub_file=$sdir/app-wrap.stubs +text $sdir/app-wrap.cvs >> composer=no xcw=no devel=no compiler=no \ >> oldspace=256k newspace=300k You are allowed to specify the existing library, as you have done, if you are planning to keep it around. However, you should be specifying an absolute pathname instead of a relative one. This is because the lisp must always be able to find the library, no matter what directory it is currently in. Try specifying an absolute pathname for the library and let me know if you have any other problems with the installation. >> Initial generation spread = 1 >> Allocated 12587064 bytes for old space >> Allocated 2097152 bytes for new space >> ; fasl-bundle skipping file sys/startup.fasl... >> >> This time it core dumps. The actual failure that occurs when the ucl tries to load the startup file (from files.bu in the library directory) may vary, but this ungraceful death has been fixed in 4.2.beta2. Duane Rettig, Franz Inc. 1995 University Avenue, Suite 275 duane@Franz.COM (internet) Berkeley, CA 94704 uunet!franz!duane (uucp) Phone: (510) 548-3600; FAX: (510) 548-8253 From excl-forum-distribution-owner Mon Jun 28 16:43:46 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <237332>; Mon, 28 Jun 1993 16:43:24 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA00332; Mon, 28 Jun 93 13:01:54 PDT Received: from akbar.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA27653; Mon, 28 Jun 93 13:11:01 -0700 Return-Path: Received: by akbar.Franz.COM (4.1/FI-2.0) id AA22220; Mon, 28 Jun 93 13:10:13 PDT Date: Mon, 28 Jun 1993 16:10:13 -0400 From: smh@franz.com (Steve Haflich) Message-Id: <9306282010.AA22220@akbar.Franz.COM> To: buchi@ntttsd.ntt.jp Class: bh Bh-Id: spr8701 Bh: append spr8701 expire Subject: Re: [spr8701] Accesing CLOS objects from C? Cc: bugs@franz.com, allegro-cl@ucbvax.berkeley.edu [This matter has been assigned the tracking identifier "spr8701". Please refer to it in any followup communication. Also, be sure to cc bugs@franz.com so that if I am unavailable someone else will be able to respond.] Subject: Accesing CLOS objects from C? Date: Fri, 25 Jun 93 16:23:56 +0900 From: Kazunobu Kashiwabuchi I am making a c function which can be a CLOS-method or a part of it. To establish this functionality, CLOS objects should be accessed directly from C functions. Unfortunately, unlike other basic LISP objects(e.g. LIST, FIXNUM), the structure of CLOS-objects are not described in lib/misc/lisp.h. Does anyone know how to access CLOS-objects from C? Or am I doing dirty work?? Thanks for pointing out that the structure of STANDARD-INSTANCE objects is not contained in the file lisp.h. I will try to have this fixed in a future release. However, there are good reasons why the structure cannot be described completely for C. The main reason is that CLOS is described (through the Metaobject Protocol) in terms of itself, and therefore many of the details of representation can be customized or overridden by programs. This is very different than for all the other types of objects implemented by Lisp. However, here are some basics that may give you what you need. Any object that is a STANDARD-INSTANCE is represented similar to a SIMPLE-VECTOR of length 2 (although the type code is different and the length field not present). You can't use SVREF from lisp on a STADNARD-INSTANCE. Instead, use EXCL::STANDARD-INSTANCE-REF. Element 0 of a STANDARD-INSTANCE is the `wrapper' of the class which is a SIMPLE-VECTOR. Element 4 of the wrapper is the instance's CLASS object, which of course is itself another STANDARD-INSTANCE. Element 1 of a STANDARD-INSTANCE is a SIMPLE-VECTOR of instance-allocated slots. The tricky thing is figuring the index of any particular slot in that vector, since that is computed at class-finalization time and depends on all the superclasses of the class. (Unfortunately, the MOP function SLOT-DEFINITION-LOCATION isn't implemented in 4.1.) I _think_ in the default case the instance slots will occur in the reverse of the order of the list of slot definition objects returned by CLOS:CLASS-SLOTS. I won't bother describing the representation of class-allocated slots here. I think the easiest way is that at first CLOS-object is cut into basic LISP object by CLOS-methods and then passed into C functions and the return values are composed again into CLOS-object. But I think this will cost a lot of overhead. I am also interested at this point. Any comment is appreciated. This is analogous to the distinction between `by reference' and `by value' in languages like C. If you pass the contents of individual slots to your foreign function, then you aren't passing the STANDARD-INSTANCE to C at all, and therefore the question of representation is irrelevant. All accesses to slots can be done with normal CL functions (e.g. SLOT-VALUE and (SETF SLOT-VALUE), or else individual slot accessors). Whether this will impose unacceptable overhead depends on your particular application. I suspect that _if_ the overhead is acceptable, then it is desirable _not_ to try to manipulate standard instances directly from C. Your code will probably be easier to understand and maintain. From excl-forum-distribution-owner Wed Jul 7 13:32:02 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <452109>; Wed, 7 Jul 1993 13:31:50 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA09441; Wed, 7 Jul 93 09:11:01 PDT Received: from [134.96.7.230] by ucbvax.Berkeley.EDU (5.63/1.43) id AA04111; Wed, 7 Jul 93 06:31:08 -0700 Received: from gs-serv1.dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930701) id AA16804; Wed, 7 Jul 93 15:30:00 +0200 Received: from disco-elc5.dfki.uni-sb.de by gs-serv1.dfki.uni-sb.de id AA08509; Wed, 7 Jul 93 15:29:51 +0200 Date: Wed, 7 Jul 1993 09:35:19 -0400 Message-Id: <9307071335.AA15274@disco-elc5> Received: by disco-elc5; Wed, 7 Jul 93 15:35:19 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: oe@dfki.uni-sb.de (Stephan Oepen) To: allegro-cl@ucbvax.berkeley.edu Cc: kiefer@dfki.uni-sb.de Subject: sparc ii vs. sparc 10 Reply-To: oe@dfki.uni-sb.de friends, for a couple of weeks now we have a sparc 10 set up under SunOS 4.1.3 (two cpus, lots of memory); among the first things we found out about it was that the acl (4.1) executable built on a sparc ii would not run on the 10 because of what is known as the `difference in stack allocation bug'. the friendly and helpful people (yes, they really are nice people) at franz inc. advised us to install patch 0138 available as `sparc-acl-4.1-stack-fix-patch.tar.Z' on ftp.uu.net which is supposed to address the problem; however, installing the patch simply makes no difference for us: executables built on sparc ii refuse to startup on the 10 with the ususal message: The environment this lisp is running in has used up too much stack. It cannot be restarted and, likewise, executables built on the sparc 10 dump core on the ii with an illegal instruction error (for those interested: in new_sysvector_pvec()). now, i cannot imagine that we are the only site trying to run the same acl 4.1 executable on sparc ii and 10 architectures; anyone out there with experiences in this direction (like: `yes, we do that all the time --- no problem' or `no clue; there is no money for a 10' |:-). am i doing something wrong? what makes it worse: from time to time we get very weird errors from code compiled on a sparc ii fasl loaded (into a different executable) on the 10. usually, then, few functions simply return random results; evaluating the function definition (from exactly the source file corresponding to the fasl file) makes the problem go away (note, that we `fasl' load instead of `libfasl' loading --- should not make a difference, i guess). someone who had similar things happen to him before? thanks for your interest - oe ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84 ;;; - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From excl-forum-distribution-owner Wed Jul 7 14:59:07 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <452106>; Wed, 7 Jul 1993 14:58:57 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA09507; Wed, 7 Jul 93 11:18:08 PDT Received: from pigseye.mmm.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA09298; Wed, 7 Jul 93 11:27:17 -0700 Received: by pigseye.mmm.com (4.1/SMI-4.1) id AA27288; Wed, 7 Jul 93 13:26:31 CDT Date: Wed, 7 Jul 1993 14:26:07 -0400 From: jecollins@mmm.com (John Collins) Message-Id: <9307071826.AA08762@aspen.mmm.com> To: oe@dfki.uni-sb.de Cc: allegro-cl@ucbvax.berkeley.edu In-Reply-To: Stephan Oepen's message of Wed, 7 Jul 93 15:35:19 +0200 <9307071335.AA15274@disco-elc5> Subject: sparc ii vs. sparc 10 We also had the problem of sparc 2 images not being able to start up on the sparc 10; we solved it by going to 4.2 Beta, so I don't know what else to say. ------------------------------------------------------------------------ John Collins Phone: +1 (612) 736 0778 3M Company FAX: +1 (612) 733 2165 3M Center, Building 260-6A-08 Internet: jecollins@mmm.com St. Paul, MN 55144-1000 or jcollins@cs.umn.edu ------------------------------------------------------------------------ From excl-forum-distribution-owner Thu Jul 8 15:01:38 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <452125>; Thu, 8 Jul 1993 15:01:32 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10410; Thu, 8 Jul 93 10:59:16 PDT Received: from uni-sb.de by ucbvax.Berkeley.EDU (5.63/1.43) id AA26895; Thu, 8 Jul 93 11:08:24 -0700 Received: from gs-serv1.dfki.uni-sb.de with SMTP by uni-sb.de (5.65++/UniSB-2.2/930701) id AA02742; Thu, 8 Jul 93 20:07:55 +0200 Received: from disco-elc5.dfki.uni-sb.de by gs-serv1.dfki.uni-sb.de id AA08171; Thu, 8 Jul 93 20:07:44 +0200 Date: Thu, 8 Jul 1993 14:13:12 -0400 Message-Id: <9307081813.AA16530@disco-elc5> Received: by disco-elc5; Thu, 8 Jul 93 20:13:12 +0200 Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken From: oe@dfki.uni-sb.de (Stephan Oepen) To: jecollins@mmm.com, dane@hld9.hlds.com, oli@ims.uni-stuttgart.de Cc: allegro-cl@ucbvax.berkeley.edu Subject: Re: sparc ii vs. sparc 10 Reply-To: oe@dfki.uni-sb.de so, thanks to the people who mail(1)-ed me their experiences with acl executables on sparc ii and 10. the votes are two to one that the patch does not work; so, i still fell confused. however, it is agreed upon that the current beta version of 4.2 solves the problem and that it is a reasonable strategy to try and move to 4.2. well, we are waiting for the tape these days; we will see then. |:-} - oe ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Stephan Oepen, Duerkheimer Str. 7, 66oo Saarbruecken, (o681) - 3o2 52 84 ;;; - oe@dfki.uni-sb.de | oe@cs.tu-berlin.de | oe@gnu.ai.mit.edu - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From excl-forum-distribution-owner Fri Jul 9 05:00:27 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <452105>; Fri, 9 Jul 1993 05:00:13 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA10894; Fri, 9 Jul 93 01:04:25 PDT Received: from hyper.franz.com by ucbvax.Berkeley.EDU (5.63/1.43) id AA24568; Fri, 9 Jul 93 01:13:32 -0700 Return-Path: Received: from sole.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA07123; Fri, 9 Jul 93 01:14:15 PDT Received: from sole (localhost) by sole.Franz.COM (5.0/FI-2.0) id AA07139; Fri, 9 Jul 93 01:13:50 PDT Message-Id: <9307090813.AA07139@sole.Franz.COM> To: oe@dfki.uni-sb.de (Stephan Oepen) Class: bh Bh-Id: spr8509 Bh: append spr8509 customer Cc: bugs@franz.com, ks@dfki.uni-sb.de, netter@dfki.uni-sb.de, allegro-cl@ucbvax.berkeley.edu Subject: Re: [spr8509] needs sparc patch Date: Fri, 9 Jul 1993 04:13:48 -0400 From: Kevin Layer Content-Length: 295 Are you a CLIM user? It is known that build CLIM into the image made by config will cause the patch to be disabled. Kevin Layer, Franz Inc. 1995 University Avenue, Suite 275 layer@Franz.COM (internet) Berkeley, CA 94704 USA Phone: (510) 548-3600 FAX: (510) 548-8253 From excl-forum-distribution-owner Fri Jul 9 19:12:30 1993 Received: from centralsparc.Berkeley.EDU ([128.32.131.97]) by relay.cs.toronto.edu with SMTP id <452177>; Fri, 9 Jul 1993 19:12:17 -0400 Received: from ucbvax.Berkeley.EDU by centralsparc.Berkeley.EDU (4.1/1.42) id AA11517; Fri, 9 Jul 93 15:44:59 PDT Received: from Mail.Think.COM by ucbvax.Berkeley.EDU (5.63/1.43) id AA20884; Fri, 9 Jul 93 15:54:12 -0700 Received: from Think.COM by mail.think.com; Fri, 9 Jul 93 18:53:15 -0400 Received: from OCCAM.THINK.COM by Early-Bird.Think.COM; Fri, 9 Jul 93 18:53:11 EDT Date: Fri, 9 Jul 1993 18:53:00 -0400 From: Barry Margolin Reply-To: luv-93-organizer@ai.sri.com Subject: REMINDER Lisp Users and Vendors Conference To: common-lisp@ai.sri.com, slug@ai.sri.com, news.comp.lang.lisp@think.com, news.comp.ai@think.com, info-mcl@cambridge.apple.com, allegro-cl@ucbvax.berkeley.edu, kcl@cli.com, lispworks@harlqn.co.uk, info-dylan@cambridge.apple.com, scheme@mc.lcs.mit.edu Message-Id: <19930709225305.3.BARMAR@occam.think.com> This is a reminder of the Lisp Users and Vendors Conference which will be held August 9-13, 1993 in Cambridge, MA. Registrations by mail are no longer being accepted, BUT registrations on-site` will still be accepted. For more information, and to check availability of seats in the Monday and Tuesday tutorial sessions, contact: ALU c/o An Event to Remember P.O. Box 294 Malvern, PA 19355-0294 Phone 215-651-2990 Email luv-93-organizer@ai.sri.com