Received: from ucb-vax.berkeley.edu by MIT-MC.ARPA 1 Nov 85 16:48:02 EST Received: by ucb-vax.berkeley.edu (5.31/1.2) id AA00223; Fri, 1 Nov 85 13:27:31 PST Received: by dali.ARPA (5.31/4.48) id AA02130; Fri, 1 Nov 85 13:27:07 PST Date: Fri, 1 Nov 85 13:27:07 PST From: fateman@dali.berkeley.edu (Richard Fateman) Message-Id: <8511012127.AA02130@dali.ARPA> To: Bennett@su-score.arpa, FRANZ-FRIENDS-INCOMING%CSL60%TI-CSL@csnet-relay.arpa, \,.bbd-franz-friends@nrl-aic.arpa, fateman@dali.berkeley.edu, franz-friends-local@mit-mc.arpa, franz-friends-yale@yale.arpa, franz-friends.gatech@csnet-relay.arpa, franz-friends.umn-cs@csnet-relay.arpa, franz-friends.ct@csnet-relay.arpa, franz-friends.ubc@csnet-relay.arpa, franz-friends@aids-unix.arpa, franz-friends@rand-unix.arpa, franz-friends@rice.edu, franz-friends@sri-spam.arpa, franz-lisp@nrl-css.arpa, franz@maryland.arpa, franzfriends@cu-arpa.cs.cornell.edu, frnzlist.colostate@csnet-relay.arpa, franz-friends%okstate@csnet-relay.arpa, franz.ucf-cs@csnet-relay.arpa, lisp-news@lbl-csam.arpa, lisplist%lsu@csnet-relay.arpa, local-franz-friends@usc-ecl.arpa, post-franz-friends.unc@csnet-relay.arpa, post-franz-friends@lanl.arpa, uci-franz-friends@uci.arpa Subject: New implementation of Franz? Actually, a compatible version of Franz (compatible with VAX/UNIX, and the 680x0 UNIX systems) might be made available on an as-yet-unannounced UNIX-based workstation made by a major computer manufacturer. It appears that this would be coupled with substantial donations of the hardware to universities, by the manufacturer. If the attractiveness of the workstation TO YOU would be enhanced by the availability of Franz Lisp, please send me a note. (don't respond to franz-friends.) As a group, we can lobby more effectively, and get the manufacturer to supply it. You may also include comments about the desirability of additional dialects of Lisp. Thanks, Richard Fateman, UC Berkeley.  Received: from UCB-VAX by MIT-MC.ARPA 13 Oct 85 16:59:27 EDT Received: by UCB-VAX (5.28/5.12) id AA27771; Sun, 13 Oct 85 13:56:41 PDT Received: from kim (ucbkim) by ucbmike.ARPA (1.1/4.48) id AA00115; Wed, 9 Oct 85 13:56:57 pdt Received: by kim (5.28/5.12) id AA06307; Fri, 11 Oct 85 19:56:25 PDT Received: by UCB-VAX (5.28/5.12) id AA01765; Fri, 11 Oct 85 19:56:11 PDT Received: by sdcsvax.ARPA (5.28/4.41) id AA08044; Fri, 11 Oct 85 15:35:25 PDT hops=0 From: dcdwest!benson@sdcsvax.arpa (Peter Benson) Date: Fri, 11 Oct 85 15:14:30 pdt Message-Id: <8510112214.AA04005@dcdwest.ITT> Received: by dcdwest.ITT; Fri, 11 Oct 85 15:14:30 pdt To: franz-friends@UCB-VAX.Berkeley.EDU Subject: Could you ... put me on the mailing list ?? Thanks. _ Peter Benson | ITT Defense Communications Division (619)578-3080 | 10060 Carroll Canyon Road decvax!ittvax!dcdwest!benson | San Diego, CA 92131 ucbvax!sdcsvax!dcdwest!benson |  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 7 Oct 85 13:59:29 EDT Received: by UCB-VAX.ARPA (5.28/5.11) id AA05424; Mon, 7 Oct 85 10:54:11 PDT Received: from ucbkim by ucbmike.ARPA (1.1/4.48) id AA04152; Mon, 7 Oct 85 10:54:19 pdt Received: by ucbkim (5.28/5.12) id AA02846; Mon, 7 Oct 85 10:41:27 PDT Received: by UCB-VAX.ARPA (5.28/5.11) id AA00642; Mon, 7 Oct 85 06:55:41 PDT Received: by mitre.ARPA (4.12/4.7) id AA11068; Mon, 7 Oct 85 09:56:30 edt Message-Id: <8510071356.AA11068@mitre.ARPA> To: franz-friends@UCB-VAX.Berkeley.EDU Cc: sokol@mitre.arpa Subject: arpa list Date: 07 Oct 85 09:55:24 EDT (Mon) From: Lisa Sokol Could you please add my name to your mailing list-- sokol@mitre Thank youl Lisa Sokol  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 11 Sep 85 20:55:58 EDT Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA00815; Wed, 11 Sep 85 17:53:27 pdt Received: from ucbkim.ARPA by ucbmike.ARPA (1.1/3.5) id AA03859; Wed, 11 Sep 85 17:56:57 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3) id AA01203; Wed, 11 Sep 85 17:53:47 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA00745; Wed, 11 Sep 85 17:49:44 pdt Received: by ucbdali.ARPA (5.5/4.48) id AA06062; Wed, 11 Sep 85 17:48:39 PDT Date: Wed, 11 Sep 85 17:48:39 PDT From: sklower%ucbdali@Berkeley (Keith Sklower) Message-Id: <8509120048.AA06062@ucbdali.ARPA> To: rsm@carl.UTEXAS.EDU Subject: -H flag Cc: franz-friends@Berkeley we have built macsyma here at berkeley without using the -H flag on the sun. The only thing it would buy you is sharing of text space if two people were running macsyma on the same sun, a foolish proposition at best. Just link rawlisp to rawhlisp.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 27 Aug 85 22:01:58 EDT Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA15549; Tue, 27 Aug 85 18:57:22 pdt Received: from ucbkim.ARPA by ucbmike.ARPA (1.1/3.5) id AA08971; Tue, 27 Aug 85 19:00:12 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3) id AA12084; Tue, 27 Aug 85 18:54:44 PDT Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3) id AA15443; Tue, 27 Aug 85 18:51:23 pdt Received: from smu by csnet-relay.csnet id ae17053; 27 Aug 85 21:47 EDT Received: by csevax.smu (4.12/4.7) id AA20402; Tue, 27 Aug 85 17:01:03 cdt Date: 27 Aug 1985 16:55-EST From: leff%smu.csnet@csnet-relay.ARPA Subject: To: franz-friends@Berkeley Message-Id: <494027757/leff@smu> One of our Franz users (Opus 38.79) has gotten the error message "Space request would exceed maximum memory allocation [Storage space totally exhausted] Error: Space exhausted when allocating list" I seem to recall reading in the manual that there was some function to reconfigure the amount of space used by cons as opposed to print-name space or something but a search of the manual fails to turn anything up. Is there anything I can do for our user short of telling him to write his code to use less memory space." (Note to moderator: This sounds like a straightforward question but it has got us stumped. Perhaps you can forward it to someone who can answer it without bothering the whole net.) Thanks, Leff  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 19 Aug 85 18:59:47 EDT Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA08589; Mon, 19 Aug 85 15:56:38 pdt Received: from ucbkim.ARPA by ucbmike.ARPA (1.1/3.5) id AA04235; Mon, 19 Aug 85 15:56:23 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3) id AA00203; Mon, 19 Aug 85 15:55:07 PDT Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3) id AA06773; Mon, 19 Aug 85 14:22:12 pdt Message-Id: <8508192122.AA06773@UCB-VAX.ARPA> Received: from mtu by csnet-relay.csnet id a001523; 19 Aug 85 17:23 EDT Received: by mtu.UUCP (4.12/4.7) id AA22034; Mon, 19 Aug 85 09:58:17 edt Date: Mon, 19 Aug 85 09:58:17 edt From: John Lowther To: franz-friends@Berkeley Subject: List Membership Cc: john%mtu.CSNET@CSNET-RELAY.ARPA Please add Michigan Technological University ( c/o John Lowther) to franz-friends@BERKELEY distribution. Thanks, Dr. John Lowther Associate Professor of Computer Science Computer Science Michigan Technological University Houghton, Michigan 49931 Office: (906) 487-2183 Secretary: (906) 487-2068 uucp: {lanl, ihnp4, glacier}!mtu!john arpa/csnet: john%mtu@csnet-relay  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 22 Jul 85 10:30:58 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/5.3) id AA22675; Mon, 22 Jul 85 07:19:35 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA04249; Mon, 22 Jul 85 07:24:21 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA29235; Mon, 22 Jul 85 07:23:24 pdt Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by UCB-VAX.ARPA (4.24/5.3) id AA22657; Mon, 22 Jul 85 07:17:56 pdt Message-Id: <8507221417.AA22657@UCB-VAX.ARPA> Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 22 Jul 85 10:22:52 EDT Date: 22 July 1985 1022-EDT From: Karsten.Schwans@CMU-CS-A To: BBoard.Maintainer@CMU-CS-A Subject: FranzLisp IPC Attention: franzlisp bboard We are having trouble with FranzLisp on Berkeley 4.2. We don't seem to be able to call the Berkeley IPC without causing undue danamge to the system. Does anyone have a working piece of code you might send us Thanks, Karsten P.S.: Pleas send responses to Schwan@ohio-state.csnet or schwans@cmua  Received: from UCB-VAX.ARPA by MIT-MC.ARPA.ARPA; 15 Jul 85 17:05:48 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/5.2) id AA05761; Mon, 15 Jul 85 13:57:27 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00169; Mon, 15 Jul 85 14:02:31 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA09840; Mon, 15 Jul 85 13:57:48 pdt Received: from SRI-AI.ARPA (sri-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2) id AA05591; Mon, 15 Jul 85 13:52:21 pdt Message-Id: <8507152052.AA05591@UCB-VAX.ARPA> Date: Mon 15 Jul 85 13:56:28-PDT From: KASHTAN@SRI-AI.ARPA Subject: Re: Franz, Eunice, 4.0 To: jpg@MIT-MC.ARPA, zoll@CMU-PSY-A.ARPA Cc: franz-friends@Berkeley Here is a VERY simple "C" program that will patch the VMS image header to make the "hdrblkcnt" 1 instead of 0. You can use this program any time you do a dumplisp and want to run it on VMS 4.0 (without having to recompile the basic Franz Lisp): main(argc,argv) char *argv[]; { int i; for(i = 1; i < argc; i++) patch(argv[i]); } patch(filename) char *filename; { int fd; char hdrblkcnt = 1; fd = open(filename,2); if (fd < 0) {perror("open"); return;} lseek(fd,16,0); write(fd,&hdrblkcnt,1); close(fd); } David -------  Received: from UCB-VAX.ARPA by MIT-MC.ARPA.ARPA; 11 Jul 85 23:33:22 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/5.2) id AA08334; Thu, 11 Jul 85 20:24:36 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA01721; Thu, 11 Jul 85 20:27:43 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA01049; Thu, 11 Jul 85 20:23:07 pdt Received: from MIT-MC.ARPA (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2) id AA27795; Wed, 10 Jul 85 09:44:41 pdt Date: Wed, 10 Jul 85 12:50:05 EDT From: Jeffrey P. Golden Subject: Franz Lisp for Eunice 4.1 To: franz-friends@Berkeley Cc: JPG@MIT-MC.ARPA Message-Id: <[MIT-MC.ARPA].570311.850710.JPG> We are running Franz Lisp, opus 38.79 in VMS 4.1, Eunice 4.1 . The way "funny" VMS filenames such as i.am.funny (two dots) and longfilename.l (more than 9 characters in first-filename) are hashed by Eunice was changed from version 3.X (HSN/HSH filename extensions) to version 4.X ($-sign encoding). The problem is even though we are running in VMS/Eunice 4.1, Franz only understands the VMS/Eunice 3.X funny filename hashing e.g. for (load "longfilename.l") . It gives a "file not found error" if the filename is hashed using the 4.X hashing scheme. Can anyone clarify this situation for me? I.e. is it likely to be a Franz problem or a Eunice problem we are facing? We have not rebuilt Franz yet, but would this help? Would recompiling some C file help? There's a function cvt_unix_to_vms . Is this the culprit? Is this a Franz function or a Eunice function? Any advice would be appreciated. Also, some .exe files work fine without rebuilding from 3.X . Others err out with: [EUNICE: $IMGACT failed, Status = %X84d8cbc - Couldn't get message string]. Does anyone know what this means?  Received: from UCB-VAX.ARPA by MIT-MC.ARPA.ARPA; 9 Jul 85 22:27:16 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/5.2) id AA13367; Tue, 9 Jul 85 19:19:51 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00360; Tue, 9 Jul 85 19:22:56 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA01193; Tue, 9 Jul 85 09:29:07 pdt Received: from anl-mcs.ARPA (anl-mcs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2) id AA09323; Tue, 9 Jul 85 07:08:27 pdt Return-Path: Received: by anl-mcs.ARPA ; Tue, 9 Jul 85 09:12:21 cdt Date: Tue, 9 Jul 85 09:12:21 cdt From: boyle@anl-mcs (James M. Boyle) Message-Id: <8507091412.AA10613@anl-mcs.ARPA> To: arango@uci-icse, franz-friends@Berkeley, schlimmer@uci-icse Subject: Re: Namestack Overflow; Large list storage Cc: boyle@anl-mcs In the directory franz/h search for NAMESIZE in the file global.h and change it; then rebuild the system. (Use a `make clean' first, because not all the dependencies are in the makefile, I think. You can rebuild with `make fast' [ha!]). I changed the NAMESIZE in our system from 3072 to 16384 without difficulty. However, I have a problem, franz-friends--I tried to increase the list storage (TTSIZE) from the default 6000 or so 512 byte pages to 32000. When the storage goes above the 10216 pages or so, I get bizzare behavior, usually culminating in an illegal instruction. Is 10216 somehow a hard limit on the list storage size? Has anyone built a system bigger than 10216 and had it work for large jobs? (This is not a problem with our system datasize limit; it happens before the datasize is exceeded.) Thanks. Jim Boyle  Received: from UCB-VAX.ARPA by MIT-MC.ARPA.ARPA; 9 Jul 85 22:17:44 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/5.2) id AA13185; Tue, 9 Jul 85 19:10:40 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00353; Tue, 9 Jul 85 19:13:43 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA00559; Tue, 9 Jul 85 08:46:46 pdt Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2) id AA09926; Tue, 9 Jul 85 07:46:38 pdt Received: by tove.ARPA (4.12/4.7) id AA02537; Tue, 9 Jul 85 10:49:16 edt Message-Id: <8507091449.AA02537@tove.ARPA> To: Jeff Schlimmer Cc: franz-friends@Berkeley, arango@uci-icse Subject: Re: Namestack Overflow In-Reply-To: Your message of 08 Jul 85 10:02:13 PDT (Mon). <8507081658.AA03142@UCB-VAX.ARPA> Date: 09 Jul 85 10:48:56 EDT (Tue) From: Liz Allen From: Jeff Schlimmer Several of the graduate students here at UCI are working on a large Franz Lisp program which requires several hundred levels of recursion. This causes a namestack overflow error in Franz. Is there a way to expand the size of the namestack? Yes, there is. In ../franz/h/global.h, there is a #define for NAMESIZE which is the size of the name stack. It can be changed to something larger. -Liz  Received: from UCB-VAX.ARPA by MIT-MC.ARPA.ARPA; 8 Jul 85 14:42:09 EDT Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.48) id AA05135; Mon, 8 Jul 85 11:34:06 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00143; Mon, 8 Jul 85 11:36:55 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48) id AA20308; Mon, 8 Jul 85 10:03:43 pdt Received: from UCI-ICSE (uci-icse.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48) id AA03142; Mon, 8 Jul 85 09:58:53 pdt Message-Id: <8507081658.AA03142@UCB-VAX.ARPA> To: franz-friends@Berkeley Cc: schlimmer@uci-icse, arango@uci-icse Subject: Namestack Overflow Date: 08 Jul 85 10:02:13 PDT (Mon) From: Jeff Schlimmer Received: from Localhost by UCI-ICSE; 08 Jul 85 10:02:27 PDT (Mon) Several of the graduate students here at UCI are working on a large Franz Lisp program which requires several hundred levels of recursion. This causes a namestack overflow error in Franz. Is there a way to expand the size of the namestack? --Jeff Schlimmer --Guillermo Arango  Received: from UCB-VAX.ARPA by MIT-MC.ARPA 17 Jun 85 17:04:54 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.46) id AA25645; Mon, 17 Jun 85 13:57:14 pdt Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA03085; Mon, 17 Jun 85 14:01:02 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46) id AA01719; Mon, 17 Jun 85 13:57:45 pdt Received: from CMU-PSY-A (cmu-psy-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA25593; Mon, 17 Jun 85 13:54:08 pdt Message-Id: <8506172054.AA25593@UCB-VAX.ARPA> Date: Monday, 17 Jun 85 16:50:28 EDT From: jaffe@cmu-psy-a (elliot jaffe) Subject: Cursor Package? To: franz-friends@Berkeley Does anyone out there have a working cursor package for franz lisp? I know that the franz distribution at one time came with such a package, but the version that I have does not work. For some reason, a function called "ospeed" is defined both in franz and in curses. I am working on a VMS machine with version 38.91. I've also got franz on a Sun workstation (version 41.?) but both franzs have the same problem. Any help with a cursor package or pointers to such a package would be greatly appreciated. Replies to: Jaffe@cmu-psy-a.arpa Thanks, Elliot Jaffe.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 APR 85 01:50:24 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.46) id AA03147; Wed, 24 Apr 85 12:18:51 pst Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA03035; Wed, 24 Apr 85 12:20:38 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46) id AA01778; Wed, 24 Apr 85 12:02:32 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA02711; Wed, 24 Apr 85 12:00:04 pst Received: by tove.ARPA (4.12/4.7) id AA15012; Wed, 24 Apr 85 15:00:27 est Message-Id: <8504242000.AA15012@tove.ARPA> To: Wilson.Harvey@cmu-cs-ius Cc: franz-friends@Berkeley Subject: Re: #ifdef for liszt? In-Reply-To: Your message of 22 Apr 85 12:05:53 EST. <8504240146.AA10636@UCB-VAX.ARPA> Date: 24 Apr 85 15:00:16 EST (Wed) From: Liz Allen From: Wilson.Harvey@CMU-CS-IUS Is there anything for the lisp compiler akin to the "#ifdef" statement for the C compiler? Can anyone point me to something similar? Thanks. -- Wilson The reader has built into it a switch that works in both liszt and lisp. You can tell lisp whether or not to read an expression by putting before that expression something like: #+feature #-feature #+(or feature ...) #+(and feature ...) where feature is on iff it is on the "(status features)" list (which can be modified). Thus you can do something like this: #-uomlisp (defun morerecent (file1 file2) ...) since uomlisp is turned only in Franz's that contain all our hacks and morerecent happens to already be defined in our stuff. If you look at the liszt code, you'll see lots of "#+vax"'s and "#+68k"'s where the code needs to be different, eg: (defun cc-foo (x y z) (bar #+vax vax-arg #+68k 68k-arg) ...) It can be quite convenient especially when you have two lisps that are almost the same, you can maintain just one source containing these things whenever the sources for the different lisps must be different. I know this stuff is documented in the code in charmac.l; I can't remember right now if it is documented in the Franz reference manual and I don't have it with me right now to check. Hope this helps. -Liz  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 24 APR 85 22:18:45 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA04037; Sun, 21 Apr 85 14:17:55 pst Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA01247; Sun, 21 Apr 85 14:19:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17063; Sun, 21 Apr 85 14:13:02 pst Received: from mit-eddie.ARPA (mit-eddie.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA03920; Sun, 21 Apr 85 14:11:39 pst Received: by mit-eddie.ARPA (4.12/4.8) id AA03273; Sun, 21 Apr 85 17:11:05 est Date: Sun, 21 Apr 85 17:11:05 est From: Steven M. Haflich Message-Id: <8504212211.AA03273@mit-eddie.ARPA> To: franz-friends@Berkeley Subject: Gnu EMACS customization for Lisp Lisp hackers who use Gnu EMACS might want to try this useful customization. It emulates the standard keybinding of CCA EMACS that makes C-Z (i.e. control-Z) a prefix which both CONTROL- and META-izes to the following keystroke. This is particularly useful for Lisp because most of the special Lisp editing commands are bound to ESC CONTROL characters. This text can be placed in the personal .emacs file in your home directory. The suspend-emacs function previously run by C-Z is still available as either C-X C-Z or C-Z C-Z . But first: The two "^Z" strings in the text below have been sanitized to pass through mailers and, as mailed, contain a two character sequence representing CONTROL-Z to humans. You will have to edit them to contain the single literal character C-Z, which can be typed in EMACS via the two-keystroke sequence: C-Q C-Z . ====================================== (defun c-m-prefix () "Apply both META and CONTROL to the next command character" (interactive) (command-execute (lookup-key esc-map (char-to-string (logand 31 (read-char)))))) (define-key global-map "^Z" 'c-m-prefix) (define-key esc-map "^Z" 'suspend-emacs)  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 23 APR 85 21:12:03 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.46) id AA10812; Tue, 23 Apr 85 17:51:21 pst Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA02568; Tue, 23 Apr 85 17:53:36 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46) id AA18909; Tue, 23 Apr 85 17:48:24 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA10636; Tue, 23 Apr 85 17:46:11 pst Message-Id: <8504240146.AA10636@UCB-VAX.ARPA> Received: from CMU-CS-IUS.ARPA by MIT-MC.ARPA; 22 APR 85 12:13:41 EST Date: 22 Apr 85 12:05:53 EST From: Wilson.Harvey@CMU-CS-IUS Subject: #ifdef for liszt? To: BBoard.Maintainer@CMU-CS-A Is there anything for the lisp compiler akin to the "#ifdef" statement for the C compiler? Can anyone point me to something similar? Thanks. -- Wilson  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 15 APR 85 14:36:58 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA08931; Mon, 15 Apr 85 11:34:30 pst Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00178; Mon, 15 Apr 85 11:37:00 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08082; Mon, 15 Apr 85 11:33:17 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA08871; Mon, 15 Apr 85 11:31:51 pst Received: by rand-unix.ARPA; Mon, 15 Apr 85 11:29:44 pst From: Sanjai Narain Message-Id: <8504151929.AA12668@rand-unix.ARPA> Date: 15 Apr 85 11:29:40 PST (Mon) To: Bonnell Cc: FRANZ-FRIENDS@Berkeley, narain@rand-unix Subject: Re: Problems with *process. In-Reply-To: Your message of Fri, 12 Apr 85 13:01 EST. <8504140732.AA13927@UCB-VAX.ARPA> I once set up a link between Franzlisp and C-Prolog using process instead of *process and it worked fine. It was on Vax 11/780, but it was most probably on an earlier version of Unix, rather than 4.2bsd. -- Sanjai Narain  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 15 APR 85 13:07:55 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA07149; Mon, 15 Apr 85 10:05:03 pst Received: from ucbkim.ARPA by ucbmike.arpa (1.1/4.33) id AA00137; Mon, 15 Apr 85 10:07:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22504; Sat, 13 Apr 85 23:33:19 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA13927; Sat, 13 Apr 85 23:32:05 pst Message-Id: <8504140732.AA13927@UCB-VAX.ARPA> Received: from scarolina by csnet-relay.csnet id a013785; 14 Apr 85 2:36 EST Date: Fri, 12 Apr 85 13:01 EST From: Bonnell To: FRANZ-FRIENDS@Berkeley Subject: Problems with *process. I am attempting to have a Lisp process talk to a C process using Lisp's *process function. This function works fine with system commands such as 'ls' but fails when the C process is a typical user program. I hope someone has run into similar difficulties and can provide some enlightenment. We are using a set Sun workstations running Berkley Unix. The same problem also occurs on our VAX. Thanks, Gar Keaton  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 9 APR 85 19:45:11 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA29923; Tue, 9 Apr 85 16:40:44 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA02637; Tue, 9 Apr 85 16:42:01 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00472; Tue, 9 Apr 85 16:38:17 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA29765; Tue, 9 Apr 85 16:36:41 pst Received: by sri-spam.ARPA (4.22/4.16) id AA05175; Tue, 9 Apr 85 16:37:20 pst Date: Tue, 9 Apr 85 16:37:20 pst From: jeffr@sri-spam (Jeff Rininger) Message-Id: <8504100037.AA05175@sri-spam.ARPA> To: franz-friends@Berkeley Does anyone know of (or have) a Franz function that returns a character corresponding to a given fixnum representation, but without the pesky symbol delimiters that `ascii' returns ?  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 9 APR 85 13:07:16 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA20684; Tue, 9 Apr 85 10:04:27 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA02495; Tue, 9 Apr 85 10:06:07 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09758; Tue, 9 Apr 85 10:03:37 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA20618; Tue, 9 Apr 85 10:02:11 pst Received: by rand-unix.ARPA; Tue, 9 Apr 85 09:41:46 pst From: Phil Klahr Message-Id: <8504091741.AA17861@rand-unix.ARPA> Date: 09 Apr 85 09:41:40 PST (Tue) To: FRANZ-FRIENDS@Berkeley Cc: randvax!klahr@Berkeley Subject: IJCAI-85 Registration -- Please post The International Joint Conference on Artificial Intelligence will be meeting in Los Angeles (at UCLA) August 18-23, 1985. Conference brochures (including registration information) have already been mailed out. If you have not received one, or would like extras, contact IJCAI-85 c/o AAAI 445 Burgess Drive Menlo Park, CA 94025 415-328-3123 or 415-321-1118 Registration will be limited to 5,000 people. Based on early projections, up to 7,000 people may wish to attend, so early registration is highly encouraged (if not necessary). As a bonus, early registrants will receive a substantial reduction in registration costs. Through June 28, registration fees are $175 ($80 for students); for registrations received after June 28 but prior to July 26, fees will be $225 ($100 for students); and for on-site registration (if available), fees will be $275 ($125 for students). Substantial reductions for early tutorial registrations are also in effect. Further information on the technical conference, the tutorials, the exhibition, and housing can be found in the conference brochure.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 9 APR 85 05:32:16 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.45) id AA14406; Tue, 9 Apr 85 02:29:41 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA02318; Tue, 9 Apr 85 02:31:19 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07208; Tue, 9 Apr 85 02:28:37 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA14376; Tue, 9 Apr 85 02:27:14 pst Message-Id: <8504091027.AA14376@UCB-VAX.ARPA> Received: from ucsc by csnet-relay.csnet id ad14837; 9 Apr 85 5:28 EST Received: by vger.UCSC (4.12/4.7) id AA27515; Mon, 8 Apr 85 14:09:04 pst Date: Mon, 8 Apr 85 14:09:04 pst From: wfi <@csnet-relay.arpa,@ucsc.CSNET:wfi@ucsc.CSNET (Wayne F. Iba)> To: franz-friends@Berkeley Subject: franz profiling Cc: wfi.ucsc@CSNET-RELAY.ARPA There is a short note in the documentation of liszt that "if the lisp system is built with profiling", then using the -p option will allow use of the UNIX prof command etc. Can someone explain how to rebuild (if necessary) our lisp system accordingly? Thanks --wayne (wfi%ucsc.csnet)  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 6 APR 85 14:38:26 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA24840; Sat, 6 Apr 85 09:37:31 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA00661; Sat, 6 Apr 85 09:38:36 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13697; Sat, 6 Apr 85 09:35:22 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA24792; Sat, 6 Apr 85 09:35:09 pst Received: by tove.ARPA (4.12/4.7) id AA10092; Sat, 6 Apr 85 12:36:17 est Message-Id: <8504061736.AA10092@tove.ARPA> To: franz!schlafly@Berkeley (Roger Schlafly) Cc: franz-friends@Berkeley Subject: Re: Franz Lisp applications In-Reply-To: Your message of Fri, 5 Apr 85 10:37:18 pst. <8504051837.AA00261@franz.uucp> Date: 06 Apr 85 12:36:04 EST (Sat) From: Liz Allen A correction to one of the entries. From: franz!schlafly@Berkeley (Roger Schlafly) + Flavors An object oriented extension of Lisp, developed at MIT and the University of Maryland. Used on the Symbolics Lisp machines. Available from Franz Inc. at no charge to pur- chasers of Franz Lisp. Actually, there are two implmentations of flavors available for Franz; one written at MIT and the other at Univ of Maryland. Franz Inc distributes the one from MIT and we (at UofM) distribute our version as part of the Maryland software distribution (which includes Franz 38.91). For more information about getting our distribution, contact Bob Bane bane@gymble.arpa or seismo!umcp-cs!bane. -Liz  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 6 APR 85 13:36:05 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA25581; Sat, 6 Apr 85 10:33:44 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA01422; Thu, 21 Mar 85 11:15:25 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA18463; Thu, 21 Mar 85 11:05:39 pst Received: from ucla-locus.arpa (ucla-locus.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA12504; Thu, 21 Mar 85 10:37:45 pst Date: Thu, 21 Mar 85 10:35:28 PST From: Ingrid Zukerman To: franz-friends@Berkeley Subject: setq command changes code Message-Id: <480278128-16289-ingrid@UCLA-LOCUS.ARPA> I have the following problems: 1. After performing the command (setq x (list ... )), I noticed that the code in the function that initializes x was also changed to the new value. After consulting with my guru, he pointed out that this might be due to a sharing pattern I am not aware of, or to the way in which assignments are performed (e.g., by passing a pointer). I wasn't able to find this information, so my question is were I could find it in order to avoid such occurrences in the future. Of course, if somebody up there is terribly curious and wants to look at a transcript of the session, I'll be very appreciative. 2. The most updated copy we have of Franz is Opus 38.5. I hear that it is now Opus 38.91. What should I do in order to get an updated copy? Please don't advise me to contact the person in charge, because this person (who no longer wishes to be in charge) told me to contact you. Thanks very much. --Ingrid  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 5 APR 85 14:33:02 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA04383; Fri, 5 Apr 85 11:28:13 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA09990; Fri, 5 Apr 85 11:24:54 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02221; Fri, 5 Apr 85 11:19:37 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA04091; Fri, 5 Apr 85 11:18:48 pst Received: by ucbkim.ARPA (4.24/4.27) id AA02177; Fri, 5 Apr 85 11:18:45 pst Received: by franz.uucp (1.2/3.14) id AA00261; Fri, 5 Apr 85 10:37:18 pst Date: Fri, 5 Apr 85 10:37:18 pst From: franz!schlafly@Berkeley (Roger Schlafly) Message-Id: <8504051837.AA00261@franz.uucp> To: franz-friends@Berkeley Subject: Franz Lisp applications Here is my list of Franz Lisp applications. Enough people requested copies that I am sending it to all franz-friends. If anyone sees any notable omissions, please send me a message and I will augment the list. Roger Schlafly ucbvax!franz!schlafly ============================================================ AI and Expert System Tools and Applications Developed or Running under Franz Lisp + OPS-5 A rule based environment for developing expert systems. Available from Franz Inc. with Franz LISP at no charge, or at no charge from Carnegie Mellon University. Computer Science Department, Carnegie Mellon University, Schenley Park, Pittsburgh PA 15213. (412) 578-2592 + Flavors An object oriented extension of Lisp, developed at MIT and the University of Maryland. Used on the Symbolics Lisp machines. Available from Franz Inc. at no charge to pur- chasers of Franz Lisp. + DUCK DUCK is an expert systems development environment. Available from Smart Systems Technology, 6870 Elm St. McLean, VA. 22101 (703) 448-8562. + Boyer-Moore Theorem Prover Available from Prof. Robert Boyer, University of Texas, Aus- tin. Computer Science Department, 3-28 Painter Hall, University of Texas, Austin, Texas 78712. (512) 471-7316 + GLISP GLISP is a high-level language which is based on Lisp and is compiled into Lisp. It was developed at the University of Texas at Austin by Prof. Gordon Novak. Object-centered pro- gramming is supported. Message interpretations can be looked up at compile time to produce efficient code. A window-based editor, GEV, is available to inspect and edit data according to its data structure description. GLISP is available from Franz Inc. at no charge to purchasers of Franz Lisp, or from the University of Texas at Austin, Prof. Gordon Novak, Computer Science Department, 3-28 Painter Hall, University of Texas, Austin, Texas 78712. (512) 471- 7316 + FRL A frame representation language for AI development. Available from Steven Rosenberg, Hewlett Packard (415) 857 5902 + MRS A logic based knowledge representation system. Available from Stanford University. Attention: Pattie McCabe SUMEX Computing Facility, Stanford University Medical Center, Room TB105, Stanford, California 94305, (415) 497-5141 + Macsyma Developed at MIT, Macsyma is a program that carries out sym- bolic computation. It will solve all those integrals you learned about in your calculus class, as well as systems of differential equations and other mathematical problems. + Reduce Reduce is similar to Macsyma. It was developed at the University of Utah. Computer Science Department, 3160 Mer- rill Engineering Bldg. Salt Lake City, Utah 84112. (801) 484-7651 Ext 205 + XCON Digital Equipment's famous expert system, written in OPS-5, originally ran on top of Franz Lisp. XCON configures com- puters before shipment. + ACE Automatic Cable Expertise : A knowledge based expert system that provides trouble-shooting and diagnostic reports for telephone company managers. Developed by Stolfo, Vesonder and others at AT&T Bell Labs. For details see "The Fifth Generation Challenge" Proceedings ACM '84 Annual Conference. + Slang A circuit design and analysis tool. It has been used to design several integrated circuits at U.C. Berkeley. A detailed description is in the masters thesis of Korbin Van Dyke at U.C. Berkeley. Available from: Industrial Liason Program, EECS Department, University of California, Berkeley CA 94720 (415) 642-0253 + Lyra A VLSI design rule checker. A description is in the masters thesis of Michael Arnold at U.C. Berkeley. + Pearl A database and AI representation language written in Franz Lisp. Available from Franz Inc. at no charge to purchasers of Franz Lisp. + YAPS Yet Another Production System. Developed by Liz Allen at the University of Maryland. A forward driven production rule system similar to OPS-5, but with added flexibility. YAPS supports objects in facts, and defines an object that is a complete production system, so you can have more than one expert around at a time. See "YAPS: A Production System Meets Object" by Liz Allen in AAAI-83 for more information. YAPS is available at nominal cost from the Universtiy of Maryland. The license fee is $100 for BSD 4.1, $250 for 4.2. It's also Arpanet FTP'able for $100 for either ver- sion. Contact Bob Bane on Arpanet at bane@maryland or on Usenet at ...seismo!umcp-cs!bane or contact Liz Allen at liz@tove.arpa or seismo!umcp-cs!liz . + GENIE GENeric Inference Engine. An expert system development tool. Written by John Dumer, Tim Hanratty, Paul Tanenbaum, and Fred S. Brundick. For more information contact: Fred S. Brundick, + The Berkeley UNIX Consultant An expert System incorporating a natural language interface which answers questions about UNIX. Under development at U.C. Berkeley. USABRL, APG, MD. + ROSS and SWIRL ROSS is an object-oriented language developed for building knowledge based simulations. SWIRL is a program written in ROSS that embeds knowledge about defensive and offensive air battle strategies. Developed by Narain, McArthur and Klahr at The Rand Corporation, 1700 Main Street, Santa Monica CA 90406. These systems were implemented in various LISP environments including Franz LISP. A comparison of hte various environments in terms of CPU usage, real-time usage and user aids can be found in an article by the above in the proceedings of the 1983 International Joint Conference on Artificial Intelligence, Karlsruhe, W. Germany.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 5 APR 85 04:17:33 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA25824; Fri, 5 Apr 85 01:15:48 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA09727; Fri, 5 Apr 85 01:12:39 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA27833; Fri, 5 Apr 85 01:13:08 pst Received: from seismo.ARPA (css-ring-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA25779; Fri, 5 Apr 85 01:12:50 pst Return-Path: Received: from prlb2.UUCP by seismo.ARPA with UUCP; Fri, 5 Apr 85 04:12:31 EST Received: by prlb2.UUCP (4.12/4.7) id AA01128; Fri, 5 Apr 85 10:36:51 -0200 Date: Fri, 5 Apr 85 10:36:51 -0200 From: prlb2!vauclair@seismo.ARPA (Marc Vauclair) Message-Id: <8504050836.AA01128@prlb2.UUCP> To: franz-friends@Berkeley Subject: Profiling options in Franz Lisp. Opus 38.91. UoM Var. 3.5. Does anyone know how to set up profiling in Franz Lisp ? We have Franz Lisp of University of Maryland : Opus 38.91, UoM Variation 3.5. I have already made the following modifications : 1) as stated in the makefile : ../franz/vax/Makefile I have removed the # in : ------------------------------------------------------------------------------ ProfFlag = # -XP ProfFlag2 = # -DPROF ------------------------------------------------------------------------------ giving : ------------------------------------------------------------------------------ ProfFlag = -XP ProfFlag2 = -DPROF ------------------------------------------------------------------------------ 2) I've changed in ../franz/vax/Makefile the line : ------------------------------------------------------------------------------ /lib/cpp $< -I../h |\ ------------------------------------------------------------------------------ to : ------------------------------------------------------------------------------ /lib/cpp ${ProfFlag2} $< -I../h |\ ------------------------------------------------------------------------------ 3) I've changed in ../franz/vax/Makefile/qfuncl.c the lines : ------------------------------------------------------------------------------ #ifdef PROF .set indx,0 #define Profile \ movab prbuf+indx,r0 \ .set indx,indx+4 \ jsb mcount #define Profile2 \ movl r0,r5 \ Profile \ movl r5,r0 #else #define Profile #define Profile2 #endif ------------------------------------------------------------------------------ to : ------------------------------------------------------------------------------ #ifdef PROF .set indx,0 #define Profile \ movab prbuf+indx,r0 ; \ .set indx,indx+4 ; \ jsb mcount #define Profile2 \ movl r0,r5 ; \ Profile ; \ movl r5,r0 #else #define Profile #define Profile2 #endif ------------------------------------------------------------------------------ After all these modifications, we have the following error message when making it slow : ------------------------------------------------------------------------------ ld -x -o rawlisp -e start ../low.o ../lowaux.o crt0.o ../alloc.o ../data.o bigmath.o qfuncl.o vax.o ../lisp.o ../eval.o ../eval2.o ../inits.o ../io.o ../error.o ../sysat.o ../lam1.o ../lam2.o ../lam3.o ../lam4.o ../lam5.o ../lam6.o ../lam7.o ../lam8.o ../lam9.o ../lamr.o ../lamp.o ../fex1.o ../fex2.o ../fex3.o ../fex4.o ../fexr.o ../fpipe.o ../subbig.o ../pbignum.o ../divbig.o ../ffasl.o ../fasl.o ../trace.o ../evalf.o ../frame.o ../lamgc.o ../lamuom.o ../hash.o -lm -lc -ltermlib mcount: ld:/lib/libc.a(mon.o): multiply defined *** Error code 2 Stop. *** Error code 1 Stop. ------------------------------------------------------------------------------  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 3 APR 85 22:08:53 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA24653; Wed, 3 Apr 85 19:07:08 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA08856; Wed, 3 Apr 85 19:04:20 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09023; Wed, 3 Apr 85 19:05:09 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA24595; Wed, 3 Apr 85 19:04:50 pst Message-Id: <8504040304.AA24595@UCB-VAX.ARPA> Received: from boulder by csnet-relay.csnet id af16243; 3 Apr 85 21:51 EST Received: by boulder.UCBOULDER (4.30/4.7) id AA10745; Wed, 3 Apr 85 09:58:09 mst Date: Wed, 3 Apr 85 09:58:09 mst From: Dennis Heimbigner To: carter%ubc.csnet@csnet-relay.ARPA, franz-friends@Berkeley Subject: Re: C interface If I recall correctly, the pre-4.2 malloc did not appear to work with franz because it assumed that it had control of all of free memory. The malloc for 4.2 uses a buddy system and should not care if, for example, franz has pre-empted pieces of virtual memory for its own use. On the other side, franz only looks at the memory it gets from sbrk, so it doesn't care about malloc'd areas of virtual memory. .lp More to the point, I have been using malloc inside cfasl'd code and have not yet seen a problem. Dennis Heimbigner dennis.boulder@csnet-relay.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 2 APR 85 19:53:38 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA26953; Tue, 2 Apr 85 16:51:13 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA08184; Tue, 2 Apr 85 16:48:52 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15047; Tue, 2 Apr 85 16:48:37 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA26876; Tue, 2 Apr 85 16:48:19 pst Received: from ubc by csnet-relay.csnet id a008974; 2 Apr 85 19:35 EST Received: from ubc-vision.UUCP by ubc.csnet id AA06552; Tue, 2 Apr 85 16:28:06 pst Date: Tue, 2 Apr 85 16:27:59 pst From: Alan Carter Message-Id: <8504030027.AA14795@ubc-vision.UUCP> Received: by ubc-vision.UUCP id AA14795; Tue, 2 Apr 85 16:27:59 pst To: franz-friends@Berkeley Subject: C interface Does anyone know if it is OK to call malloc and free from C functions called by lisp? -- Alan Carter carter@ubc-vision.UUCP  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 29 MAR 85 21:27:45 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA07105; Fri, 29 Mar 85 18:19:05 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA05684; Fri, 29 Mar 85 18:24:11 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA11898; Fri, 29 Mar 85 18:23:00 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA07034; Fri, 29 Mar 85 18:16:19 pst Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1) id AA11566; Fri, 29 Mar 85 18:22:39 pst Received: by ucbruby.CC.Berkeley.ARPA (4.19/4.34.1) id AA10320; Fri, 29 Mar 85 18:21:53 pst Date: Fri, 29 Mar 85 18:21:53 pst From: weeks%ucbruby.CC@Berkeley (Harry Weeks) Message-Id: <8503300221.AA10320@ucbruby.CC.Berkeley.ARPA> To: jeffr@sri-spam Subject: Re: Problems Forking Around Cc: franz-friends@Berkeley It is a characteristic of Unix that processes do not really die until they are waited for. Your `zombie' process will not die until you (wait) for it. The (wait) function returns the dotted pair (pid . status). Thus the following examples will spawn children that immediately die. --Harry In simplest terms: (def beget (lambda nil (cond ((fork) (wait)) (t (exit 0))))) In more realistic terms: (def beget (lambda nil (prog (child) (setq child (fork)) (cond ((null child) ; child branch: (fork) evaluated to nil (exit 0)) ((> child 0) ; parent branch: (fork) evaluated to pid (princ "Begot ") (princ child) (princ ".") (terpri) (return (beget:wait child))) ((< child 0) ; error branch (princ "Birth pain.") (terpri) (return child)) (t ; impossible branch (princ "Impossible pain.") (terpri) (return -1)))))) (def beget:wait (lambda (child) (prog (pvec) (setq pvec (wait)) (cond ((= (car pvec) child) ; child we are waiting for died (return (cdr pvec))) ((< (car pvec) 0) ; error (princ "Wait error.") (terpri) (return (car pvec))) (t ; another child died, keep waiting for ours (return (beget:wait child)))))))  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 29 MAR 85 19:57:54 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA05614; Fri, 29 Mar 85 16:48:35 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA05645; Fri, 29 Mar 85 16:53:45 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27) id AA10643; Fri, 29 Mar 85 16:50:22 pst Received: by ucbdali.ARPA (4.24/4.42) id AA04603; Fri, 29 Mar 85 16:50:11 pst Message-Id: <8503300050.AA04603@ucbdali.ARPA> To: jeffr@sri-spam.ARPA Cc: franz-friends%ucbdali@Berkeley Subject: Re: Problems Forking Around In-Reply-To: Your message of 29 Mar 85 16:22:30 PST (Fri). <8503300022.AA29100@sri-spam.ARPA> Date: 29 Mar 85 16:50:02 PST (Fri) From: larus%ucbdali@Berkeley This is a not-very-well-known bug/feature of Franz/Unix. Try adding a (wait) call in the main routine and the zombies will go away. /Jim  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 29 MAR 85 19:31:52 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA04899; Fri, 29 Mar 85 16:22:28 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA05632; Fri, 29 Mar 85 16:27:32 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09984; Fri, 29 Mar 85 16:22:50 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA04718; Fri, 29 Mar 85 16:16:10 pst Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16) id AA29100; Fri, 29 Mar 85 16:22:32 pst Message-Id: <8503300022.AA29100@sri-spam.ARPA> Date: 29 Mar 85 16:22:30 PST (Fri) To: franz-friends@Berkeley Subject: Problems Forking Around From: jeffr@sri-spam I am having problems getting child processes forked from Franz to exit cleanly. If I execute a simple forking function, such as (defun fork_test () (prog (pid) (cond ((setq pid (fork)) (return pid))) (exit) ] from the Franz interpreter, a zombie process is created which doesn't exit until I exit the interpreter. The same result holds when fork_test is called from a compiled Franz daemon which is not associated with a tty. It's Friday and I'm out of ideas; any you have, even if only speculation, would be greatly appreciated. - Jeff Rininger SRI International  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 27 MAR 85 13:27:06 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA04274; Wed, 27 Mar 85 10:18:03 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA04241; Wed, 27 Mar 85 10:23:57 pst Received: by ucbkim.ARPA (4.24/4.27) id AA15354; Wed, 27 Mar 85 10:22:15 pst Date: Wed, 27 Mar 85 10:22:15 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503271822.AA15354@ucbkim.ARPA> To: hilfingr%ucbrenoir@Berkeley, narain@rand-unix Subject: Re: Lisp is faster than Prolog? A personal plea Cc: franz-friends%ucbkim@Berkeley, prolog%ernie@Berkeley In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst Good point, Paul, but I think you're missing something. First you plead with us not to use micro-benchmarks, then you point out (correctly) that the strategy that one would use to write a program in Lisp instead of Prolog can often differ. I would think that the implication from the latter observation is that large programs are fundamentally incomparable, and I think that that is probably correct. So if you deny us micro-benchmarks, then we can not measure the relative performance of these languages at all (or, more precisely, the standard implementations of these languages on the 11/780). Hence we might as well accept the statements "Prolog is faster than Lisp" or "Lisp is faster than Prolog" or "Lisp is faster than assembler" as essentially meaningless statements, since we can't quantify any of them. Let me sputter out making one final point. LIPS is not all that bad a measure. Perhaps if we called it "cycles through the append loop" or "function calls per second" (essentially identical statements) I think most people would agree that this is a fair measure of the performance of any Lisp. After all, Lisp does nothing other than call functions and manipulate lists. I'm certainly not going to take issue with the rest of your letter, which is really more directed at Sanjai's claims than mine, and walks rather closer to debates on programming style than any sane man should dare to go. I remain, sir, Y'r obedient servant, Rick McGeer.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 27 MAR 85 11:09:06 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA01558; Wed, 27 Mar 85 07:59:59 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA04186; Wed, 27 Mar 85 08:05:54 pst Received: by ucbkim.ARPA (4.24/4.27) id AA13270; Wed, 27 Mar 85 08:03:25 pst Received: by franz.uucp (1.2/3.14) id AA06162; Wed, 27 Mar 85 07:59:36 pst Date: Wed, 27 Mar 85 07:59:36 pst From: franz!jkf@Berkeley (John Foderaro) Message-Id: <8503271559.AA06162@franz.uucp> To: hilfingr%ucbrenoir@Berkeley, narain@rand-unix.ARPA, mcgeer%ucbkim@Berkeley Subject: Re: Lisp is faster than Prolog? A personal plea Cc: franz-friends%ucbkim@Berkeley, prolog%ernie@Berkeley In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst While I find the discussion of Prolog vrs Lisp interesting, please do don't include franz-friends in on the discussion. When the mailing list has strayed off the topic of Franz Lisp in the past, I've gotten inundated with complaints. Thanks. John Foderaro  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 27 MAR 85 04:18:06 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA26364; Wed, 27 Mar 85 01:08:24 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA04016; Wed, 27 Mar 85 01:13:28 pst Received: from ucbrenoir.ARPA by ucbkim.ARPA (4.24/4.27) id AA11390; Wed, 27 Mar 85 01:06:00 pst Received: by ucbrenoir.ARPA (4.24/4.42) id AA03594; Wed, 27 Mar 85 01:07:16 pst Date: Wed, 27 Mar 85 01:07:16 pst From: hilfingr%ucbrenoir@Berkeley (Paul Hilfinger) Message-Id: <8503270907.AA03594@ucbrenoir.ARPA> To: mcgeer%ucbkim@Berkeley, narain@rand-unix Subject: Re: Lisp is faster than Prolog? A personal plea Cc: prolog%ernie@Berkeley, franz-friends%ucbkim@Berkeley In-Reply-To: Your message of 26 Mar 85 17:33:41PST Please, please, please stop trying to compare the performance of Lisp and Prolog by considering micro-benchmarks! Even in languages that are essentially "the same" (from my perspective as a semanticist/language designer or from the perspective of a Prolog programmer, FORTRAN, Pascal, Modula 2, and Ada are all the same); such benchmarks are imperfect guides. When comparing Lisp and Prolog, where the programs one might write to do a particular problem might be radically different in strategy, anything that compares the performance of tiny programs conveys almost no useful information. Please, please, please, PLEASE don't try to compare Prolog with Lisp (etc.) using LIPS as a part of the measure! In comparing Prolog implementations, I suppose LIPS might be of some interest, but when comparing Lisp with Prolog, they don't help at all. The reason is simple: if Lisp is not suited for doing logical inferences (in the Prolog sense) quickly, then the good Lisp programmer simply does not formulate his solution using logical inferences. (Patient: Doctor! Doctor! It hurts when I do this. Doctor: Well, then don't do that.) It's like saying that my APL implementation, which uses lazy evaluation and a bit of cleverness to compute +/ ,((iota n) o.= iota n) x A +.x B (the trace of the matrix product of nxn matrices A and B, I think) in time O(n^2) instead of O(n^3), is "faster" than my FORTRAN implementation, which requires time O(n^3) to do a direct transcription of this algorithm (actually forming the full matrix product). I think it wrong to say "To do [deduction, searching, pattern matching and other AI-stuff] in Franzlisp you must write Lisp functions and suffer the loss in speed associated with simulating functionality in a high-level language." because one DOESN'T use simulation if one wants speed, but instead goes after an entirely different kind of solution (I won't argue that this solution is "just as easy" as the Prolog solution; there are certainly many instances in which Prolog solutions are simpler, and I haven't the foggiest notion what the story is for large systems.) * * * Finally, a question. I was struck by Sanjai Narain's comment: "However, in C-Prolog, you can do also do deduction, searching, pattern matching and a lot of other AI-stuff at the same speed." I notice that the Prolog digest is full of interesting puzzles whose solution involves search. But are these representative? I think pattern matching is certainly a big part of any Prolog program, but do deduction and searching really form a big part of actual Prolog applications in practice? I recall an article by Drew McDermott called the "The Prolog Phenonmenon" that appeared (I think) in SIGArt at some point, maybe July '82. He asked why it was that Prolog had not died out, as had PLANNER, which also purported to support searching et al. He said some things on what he liked and disliked about Prolog, and then made the following comment (emphasis mine): "The Europeans went in a different direction [from the Americans in reaction to the problems of PLANNER-like languages]. What they liked best about logic was its variable-binding machinery. Their attitude towards backtracking has been simply that it is a programmer's duty to remember that his program will be executed backward as well as forward, that his programs must correct bad guesses as well as exploit good ones. If the backwards execution blows up, he must debug his program, not rewrite the interpreter [the American approach], just as with more prosaic kinds of infinite loops. Once this burden was shifted away from the language implementer and onto the programmer, the logical [!] next step was to freeze the interpreter design and make it as efficient as possible. THE RESULT IS A PROGRAMMING LANGUAGE, NOT A PROBLEM SOLVER OR THEOREM PROVER; it doesn't compete with NOAH, but with Lisp. And it's my impression that it competes pretty well. "The effect is to reverse the usual images of the American and European computer scientists. In this case, the Americans have pursued impractical theoretical studies, while the Europeans have bummed the hell out of a hack." (By "backward execution," he is referring to backtracking, I believe). To put this another way, one doesn't use Prolog's backtracking to do AI-style (i.e., very large) search, but rather to do very local and carefully- controlled "search," in the sense of "search this list (tree, ....) for an element equal to this one" or "try all permutations of this tiny set for one that satisfies P." Likewise, one doesn't use it to do what an AI investigator would call "deduction." One CAN convince the Prolog machinery to do more general AI-style searching efficiently, but only at the expense of vastly obscuring the original clear, simple, declarative form of the program. Not being a real Prolog hacker (yet) I don't really know how accurate this view is, and would appreciate some reaction (preferably semi-quantitative).  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 MAR 85 21:36:22 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA19246; Tue, 26 Mar 85 18:27:25 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03802; Tue, 26 Mar 85 18:32:30 pst Received: by ucbkim.ARPA (4.24/4.27) id AA07153; Tue, 26 Mar 85 18:30:58 pst Date: Tue, 26 Mar 85 18:30:58 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503270230.AA07153@ucbkim.ARPA> To: narain@rand-unix Subject: Re: Lisp is faster than Prolog? Cc: narain@rand-unix, franz-friends%ucbkim@Berkeley, prolog%ernie@Berkeley In-Reply-To: Your message of 26 Mar 85 17:33:41 PST (Tue) You misunderstood my message. Prolog-in-Lisp really isn't under examination: the only reason I brought it up was that it provided the original motivation for the experiment (I wanted to determine a limit on the speed I could expect out of my Prolog, reasoning that it could not possibly be faster than native-coded Lisp.) The rest of your letter is essentially correct: the figures imply that CProlog is at least as fast as Franz, since the relevant test is interpreted code in each language (i.e., the first set of figures). However, this should not imply that I believe that Prolog is a "better" language than Lisp (I don't want to get into *that* debate), or imply that Lisp has no advantages over Prolog. Lisp may have real advantages over Prolog, but there is no reason to believe that speed is one of them. Rick.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 MAR 85 21:28:57 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA19134; Tue, 26 Mar 85 18:20:48 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03792; Tue, 26 Mar 85 18:25:55 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06939; Tue, 26 Mar 85 18:17:38 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA18369; Tue, 26 Mar 85 17:39:36 pst Received: by rand-unix.ARPA; Tue, 26 Mar 85 17:33:48 pst From: Sanjai Narain Message-Id: <8503270133.AA16864@rand-unix.ARPA> Date: 26 Mar 85 17:33:41 PST (Tue) To: Rick McGeer Cc: prolog%ernie@Berkeley, franz-friends%ucbkim@Berkeley, narain@rand-unix Subject: Re: Lisp is faster than Prolog? In-Reply-To: Your message of Tue, 26 Mar 85 16:06:57 pst. <8503270006.AA03620@ucbkim.ARPA> Your first comparison of Prolog and Lisp is not very meaningful. You are comparing a Prolog implemented in Lisp with a Lisp implemented in C. Perhaps you could try to compare Lisp in Lisp with Prolog in Lisp. In a certain sense, your comparison of Franzlisp and C-Prolog infact indicates the superiority of C-Prolog. C-Prolog can be used to do append and all other functional programming at almost the speed of FranzLisp. However, in C-Prolog, you can do also do deduction, searching, pattern matching and a lot of other AI-stuff at the same speed. To do these in Franzlisp you must write Lisp functions and suffer the loss in speed associated with simulating functionality in a high-level language. -- Sanjai  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 MAR 85 20:02:40 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA16459; Tue, 26 Mar 85 16:07:49 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03687; Tue, 26 Mar 85 16:13:01 pst Received: by ucbkim.ARPA (4.24/4.27) id AA03620; Tue, 26 Mar 85 16:06:57 pst Date: Tue, 26 Mar 85 16:06:57 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503270006.AA03620@ucbkim.ARPA> To: prolog%ernie@Berkeley, franz-friends%ucbkim@Berkeley Subject: Lisp is faster than Prolog? A number of articles in recent IEEE Spectra have discussed Silicon Compilation in Prolog, and concluded with a statement to the effect: for performance reasons, we will go to Lisp for a production version. Is Lisp really faster than Prolog? I used to think so. Some time ago, I wrote a Prolog interpreter in Lisp: after several versions, I gave up, because I couldn't make my Prolog fast. Its best speed was 100 LIPS through the append loop on a 780, or about 7% of the speed of C-Prolog (1500 LIPS, according to the literature. Then it occured to me that I could not expect my Prolog to run faster than an equivalent function coded in Lisp. I coded the function, and the result was the following: (def my-append (lambda (x y) (cond (x (cons (car x) (my-append (cdr x) y))) (t y)))) it can be seen that the time of the computation is invariant with respect to the second argument. Hence, for all the tests to be mentioned, the second argument is '(1 2 3 4 5). I ran the program on the lists consisting of the first 100, 250, and 300 integers. The results were the following: list length ticks (60/sec) LIPS equivalent 100 14 429 250 29 517 300 34 529 Or about one-third the published speed of of the same function in CProlog on a 780. I then wondered how the native Franz append would do. This function is compiled, and is optimized for tail recursion, so the experiment is not really fair to CProlog. In any case: list length ticks LIPS equivalent 100 3 2000 250 8 1875 300 10 1800 I don't know what this proves, but I know what it doesn't prove. The Lisp used, by the way, was Franz version 38.96 on a Vax 11/780 at the University of California at Berkeley. Despite numerous queries to Edinburgh, we still don't have a version of C-Prolog for comparative measurement here, so I can't personally vouch for the 1500 LIPS claim. Rick.  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 MAR 85 19:23:36 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA16633; Tue, 26 Mar 85 16:15:40 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03696; Tue, 26 Mar 85 16:20:55 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03876; Tue, 26 Mar 85 16:18:52 pst Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA16580; Tue, 26 Mar 85 16:12:34 pst Received: by maryland.ARPA (4.12/4.7) id AA23203; Tue, 26 Mar 85 19:17:28 est Date: Tue, 26 Mar 85 19:17:28 est From: Chris Torek Message-Id: <8503270017.AA23203@maryland.ARPA> To: carter%ubc.csnet@csnet-relay.ARPA Subject: Re: Lisp interface to C functions Cc: franz-friends@Berkeley I believe that there were. In U of M Franz, we stuck in a version of malloc and free that uses the Lisp allocator to get unGCable memory, and a host of problems with the window library went away ... (the window library uses malloc & free quite, er, freely :-) ). Chris  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 26 MAR 85 16:45:26 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA12131; Tue, 26 Mar 85 12:56:31 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03595; Tue, 26 Mar 85 13:01:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00886; Tue, 26 Mar 85 12:52:24 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA11893; Tue, 26 Mar 85 12:46:01 pst Received: from ubc by csnet-relay.csnet id a017378; 26 Mar 85 15:03 EST Received: from ubc-vision.UUCP by ubc.csnet id AA04906; Tue, 26 Mar 85 12:01:03 pst Date: Tue, 26 Mar 85 12:00:43 pst From: Alan Carter Message-Id: <8503262000.AA09422@ubc-vision.UUCP> Received: by ubc-vision.UUCP id AA09422; Tue, 26 Mar 85 12:00:43 pst To: franz-friends@Berkeley Subject: Lisp interface to C functions Does anyone know if there is a problem with calling malloc and free from C functions which are called by Franz ? Alan Carter carter@ubc-vision.UUCP  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 25 MAR 85 23:13:23 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA21873; Mon, 25 Mar 85 17:59:42 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03072; Mon, 25 Mar 85 18:05:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20019; Mon, 25 Mar 85 18:03:33 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA21825; Mon, 25 Mar 85 17:57:20 pst Received: by ucbkim.ARPA (4.24/4.27) id AA20010; Mon, 25 Mar 85 18:03:19 pst Received: by franz.uucp (1.2/3.14) id AA00961; Mon, 25 Mar 85 17:36:52 pst Date: Mon, 25 Mar 85 17:36:52 pst From: franz!schlafly@Berkeley (Roger Schlafly) Message-Id: <8503260136.AA00961@franz.uucp> To: franz-friends@Berkeley Subject: programs written in Franz Lisp I am compiling a list of expert systems and expert system building tools which are written in Franz Lisp. I would appreciate it if people would send me: (1) The name of each such program. (2) A brief description of what it does. (3) Whether it is available to the public. (4) An electronic address for obtaining more information. I will then make this list available to anyone who requests it. Roger Schlafly ucbvax!franz!schlafly  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 25 MAR 85 23:06:41 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA23853; Mon, 25 Mar 85 19:59:08 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA03118; Mon, 25 Mar 85 20:04:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA21162; Mon, 25 Mar 85 20:02:47 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA23786; Mon, 25 Mar 85 19:56:37 pst Received: by ucbkim.ARPA (4.24/4.27) id AA21150; Mon, 25 Mar 85 20:02:36 pst Received: by franz.uucp (1.2/3.14) id AA01276; Mon, 25 Mar 85 19:37:31 pst Date: Mon, 25 Mar 85 19:37:31 pst From: franz!schlafly@Berkeley (Roger Schlafly) Message-Id: <8503260337.AA01276@franz.uucp> To: franz-friends@Berkeley Subject: programs written in Franz Lisp I am compiling a list of expert systems and expert system building tools which are written in Franz Lisp. I would appreciate it if people would send me: (1) The name of each such program. (2) A brief description of what it does. (3) Whether it is available to the public. (4) An electronic address for obtaining more information. I will then make this list available to anyone who requests it. Roger Schlafly ucbvax!franz!schlafly  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 20 MAR 85 20:40:45 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA14588; Wed, 20 Mar 85 17:30:08 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA00909; Wed, 20 Mar 85 17:37:24 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08685; Wed, 20 Mar 85 17:27:57 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA11992; Wed, 20 Mar 85 16:51:20 pst Received: by utah-cs.ARPA (4.42/4.40.2) id AA01825; Wed, 20 Mar 85 17:48:26 MST Date: Wed, 20 Mar 85 17:48:26 MST From: shebs@utah-cs (Stanley Shebs) Message-Id: <8503210048.AA01825@utah-cs.ARPA> To: Franz-Friends@Berkeley, hamscher@mit-htvax.ARPA Subject: Re: Franz -> Common Lisp ? We have several versions of compatibility stuff for PSL (and it would work under Franz without much change). We're trying to get CL while retaining the speed of PSL, so we haven't yet embarked on a full standalone CL... stan shebs  Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 20 MAR 85 04:15:37 EST Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.42) id AA10979; Tue, 19 Mar 85 16:55:19 pst Received: from ucbkim.ARPA (ucbkim-ec) by ucbmike.arpa (1.1/4.33) id AA00307; Tue, 19 Mar 85 17:02:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22357; Tue, 19 Mar 85 16:50:09 pst Received: from MIT-HTVAX.ARPA (mit-htvax.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA05308; Tue, 19 Mar 85 11:49:40 pst Received: by MIT-HTVAX.ARPA (4.12/4.7) id AA21434; Tue, 19 Mar 85 14:50:20 est Date: Tue, 19 Mar 85 14:50:20 est From: Walter Hamscher Message-Id: <8503191950.AA21434@MIT-HTVAX.ARPA> To: Franz-Friends@Berkeley Subject: Franz -> Common Lisp ? Reply-to: hamscher@mit-htvax.arpa Is there a common lisp that runs on 4.2 BSD? Seems to me this is a vacuum that many folks must be trying to fill. I am wondering: (1) Who's working on one? <> (2) Is there a common lisp compatability package for franz? <> (3) Are folks at UCB thinking of spinning off a common lisp from the existing franz implementation? <> All answers and pointers appreciated. Thanks, Walter Hamscher  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA24628; Mon, 25 Feb 85 04:45:43 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA11477; Mon, 25 Feb 85 04:56:42 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20175; Mon, 25 Feb 85 04:50:50 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA24603; Mon, 25 Feb 85 04:43:20 pst Date: Mon, 25 Feb 85 04:43:17 pst Message-Id: <8502251243.AA24603@UCB-VAX.ARPA> Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST From: freemant%rpi.csnet@csnet-relay.ARPA To: franz-friends@Berkeley Hello! Our version of lxref didn't work right when it was passed the -a option, so I fixed it. Someone may want to use the -a option on lxref one of these days, so I am mailing you my fixes in hopes that you will distribute them. Things are kind of chaotic around here, so I am not sure that I was working with the most current version of lxref. Make sure that your current version of lxref matches the code that I changed before you edit in my changes. The origional definition of the function process-annotate-file left files open. Because the lisp interpreter can only have a finite number of files open at once, this caused lxref to bomb when it was given a large job to do. To fix this, I changed the definition of process-annotate-file from: (defun process-annotate-file (filename) (let (sourcep outp) ; make sure file exists and write annotate file as a ; file with the prefix #, (if (null (errset (setq sourcep (infile filename)))) then (msg "will ignore that file " N) else ; will write to file.A (erasing the final l) (let ((filen (concat "#," filename))) (setq outp (outfile filen)) (anno-it sourcep outp) (close outp) ; now mv the original filename to #dfilename ; and the annotated file to the original file (let ((oldcopy (concat "#." filename))) (if (null (errset (progn (if (probef oldcopy) then (sys:unlink oldcopy)) (sys:link filename oldcopy) (sys:unlink filename) (sys:link filen filename) (sys:unlink filen)))) then (msg "An error occured while mving files around " N "files possibly affected " filename oldcopy filen))))))) to: (defun process-annotate-file (filename) (let (sourcep outp) ; make sure file exists and write annotate file as a ; file with the prefix #, (if (null (errset (setq sourcep (infile filename)))) then (msg "will ignore that file " N) else ; will write to file.A (erasing the final l) (let ((filen (concat "#," filename))) (setq outp (outfile filen)) (anno-it sourcep outp) (close outp) (close sourcep) ; now mv the original filename to #dfilename ; and the annotated file to the original file (let ((oldcopy (concat "#." filename))) (if (null (errset (progn (if (probef oldcopy) then (sys:unlink oldcopy)) (sys:link filename oldcopy) (sys:unlink filename) (sys:link filen filename) (sys:unlink filen)))) then (msg "An error occured while mving files around " N "files possibly affected " filename oldcopy filen))))))) Note that the only change is the insertion of one close statement. The other bug I found was that find-func miserably failed to do its job right. The origional version of the function looked like this: (defun find-func (buf) ; first locate first space or tab (do ((i 1 (1+ i)) (max (cxr 0 buf)) (die)) ((or (setq die (not (<& i max))) (memq (cxr i buf) '(#\space #\tab))) (if die then nil ; can find it, so give up else ; find first non blank (do ((ii i (1+ ii))) ((or (setq die (not (<& ii max))) (not (memq (cxr ii buf) '(#\space #\tab)))) (if (or die (eq (cxr ii buf) #\lpar)) then nil else ; fid first sep or left paren (do ((iii (1+ ii) (1+ iii))) ((or (not (<& iii max)) (memq (cxr iii buf) '(#\space #\tab #\lpar))) (implode-fun buf ii (1- iii))))))))))) Not unsurprisingly, this code didn't work. I discarded it and rewrote the function in a much simpler fashion: (defun find-func (buf) (let ((i 1) (max (cxr 0 buf)) (result nil)) (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab))) do (setq i (+ i 1))) (loop while (and (not (greaterp i max)) (memq (cxr i buf) '(#\space #\tab))) do (setq i (+ i 1))) (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab #.(getcharn '|(| 1)))) do (setq result (cons (cxr i buf) result)) (setq i (+ i 1))) (if result then (implode (reverse result)) else nil))) The error in the origional definition of find-func caused the -a option to always do nothing. It is surprising that no one caught the fact that the -a option was useless earlier. (However, I am not sure that the source that I was looking at came from your tape, so perhaps it isn't your fault.) In any case, my version works. Bye! Tim Freeman freemant@rpi  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA26112; Thu, 21 Feb 85 12:52:19 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA09072; Thu, 21 Feb 85 13:00:21 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27) id AA18356; Thu, 21 Feb 85 12:54:14 pst Received: by ucbdali.ARPA (4.24/4.40) id AA16858; Thu, 21 Feb 85 12:53:47 pst Date: Thu, 21 Feb 85 12:53:47 pst From: layer%ucbdali@Berkeley (Kevin Layer) Message-Id: <8502212053.AA16858@ucbdali.ARPA> Phone: (415) 652-2405 To: cas@cvl, franz-friends%kim@Berkeley Subject: Re: database system request You could use the dbm library, as supplied by UNIX (/usr/lib/libdbm.a), via cfasl and getaddress. Kevin  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA24007; Thu, 21 Feb 85 11:35:52 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA09044; Thu, 21 Feb 85 11:43:51 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17380; Thu, 21 Feb 85 11:40:59 pst Received: from cvl.ARPA (cvl.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA23930; Thu, 21 Feb 85 11:33:27 pst Received: by cvl.ARPA (4.12/4.7) id AA09421; Thu, 21 Feb 85 14:38:26 est Date: Thu, 21 Feb 85 14:38:26 est From: cas@cvl (Cliff Shaffer) Message-Id: <8502211938.AA09421@cvl.ARPA> To: franz-friends@Berkeley Subject: database system request Does anybody know of a database system written in FRANZ or easily compatible with FRANZ? We have written a lot of software for a geographic information system, and may want to redo the section which handles random bits of information associated with polygons or points stored in a map. Right now we store this information as a property list on an atom associated with the polygon or point in question. This becomes very inefficient when we want to find all such atoms with a particular value for some arbitrary property. Equally importantly, there is very little relationship between the set of properties associated with each polygon or point, so a system storing a fixed length record for each polygon, with fields for each piece of information, would not work. Any suggestions? Cliff Shaffer cas@cvl  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA11223; Wed, 6 Feb 85 17:34:13 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00111; Wed, 6 Feb 85 16:54:59 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03031; Wed, 6 Feb 85 15:58:12 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA06871; Wed, 6 Feb 85 13:46:19 pst Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1) id AA03096; Wed, 6 Feb 85 14:37:05 MST Received: by utah-orion.ARPA (4.42/4.40.1) id AA10406; Wed, 6 Feb 85 14:36:22 MST Date: Wed, 6 Feb 85 14:36:22 MST From: kessler%utah-orion@utah-cs (Robert Kessler) Message-Id: <8502062136.AA10406@utah-orion.ARPA> To: peck@sri-spam.ARPA Cc: ailist-request@sri-ai.ARPA, franz-friends@Berkeley Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message) In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed). <8502062000.AA08198@sri-spam.ARPA> > I would like to here from anyone using SUN computers > who can supply answers or comments on any of these issues: > Is Franz the only (best) lisp available? We have finally finished porting Portable Standard LISP (PSL) to yet another machine. This time it is now running on the SUN. Initial timing measurements indicate that its speed is somewhere between a Vax 750 and 780 (all running PSL), and about twice as fast as Franz running the REDUCE algebra system test on Suns. We are now running the Gabriel benchmarks to discover where it fits in the set. For more details see the announcement at the end of this message. > Has anyone used the Maryland Flavors to create useful tools/extensions? PSL provides support for a simple flavors package that seems quite useful. However, the current version has no inheritance. > Any support for sun graphics (windows, menus,etc) a la Interlisp-D? We have oload working which allows you to call externally compiled routines (like other c sources). So the interface should be easy to add (but we haven't done it). > Any differential reports of Prolog (Quintus) vs Lisp ? None that I know of. > Any obvious alternative to SUN? (vendor in same class (Tektronix?)) PSL also runs on Apollo's and HP Series 200 (both 68K based machines). We have also ported a simple "educational" version to the 128K Macintosh which is used in a beginning programming class. We plan on moving at least the Standard LISP subset and compiler to the 512K mac (so if you want to go really cheap...... :-) ) > Worst or hidden problems, pitfalls, gotcha's, etc. We had a lot of problems with the Sun port. Some were hardware related, others were differences between Unix 4.2 on the Sun and on the Vax. After we get some more experience using PSL on the machine, maybe we could report more. > > Can real AI development (even applications) be supported on SUN's? < I think so, as long as you can get one with enough memory. Some of our applications running on HP 9836's (which doesn't have virtual memory) really fly (better than a 780 in speed). So, memory is really a key to a fast machine. > Bob. PSL 3.2 for the SUN Workstation We are pleased to announce that Portable Standard LISP (PSL) version 3.2 is now available for the Sun workstation. PSL is about the power, speed and flavor of Franz LISP or MACLISP, with growing influence from Common LISP. It is recognized as an efficient and portable LISP implementation with many more capabilities than described in the 1979 Standard LISP Report. PSL's main strength is its portability across many different systems, including: Vax BSD Unix, Vax VMS, Extended Addressing DecSystem-20 Tops-20, Apollo DOMAIN Aegis, and HP Series 200. A version for the IBM-370 is in beta test and two Cray versions are being used on an experimental basis. Since PSL generates very efficient code, it is an ideal delivery vehicle for LISP based applications (we can also provide PSL reseller licenses for binary only and source distributions). PSL is distributed for the various systems with executables, all sources, an approximately 500 page manual and release notes. The release notes describe how to install the system and how to rebuild the various modules. We are charging $750 for the Sun version of PSL for Commercial Site licenses. Non-profit institutions and all other versions of PSL will not be charged a license fee. We are also charging a $250 tape distribution fee for each system. PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard, Rand, Stanford, Columbia and over 250 other sites. Many existing programs and applications have been adapted to PSL including Hearn's REDUCE computer algebra system and GLISP, Novak's object oriented LISP dialect. These are available from Hearn and Novak. To obtain a copy of the license and order form, please send a NET message or letter with your US MAIL address to: Utah Symbolic Computation Group Secretary University of Utah - Dept. of Computer Science 3160 Merrill Engineering Building Salt Lake City, Utah 84112 ARPANET: CRUSE@UTAH-20 USENET: utah-cs!cruse  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA11223; Wed, 6 Feb 85 17:34:13 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00111; Wed, 6 Feb 85 16:54:59 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03031; Wed, 6 Feb 85 15:58:12 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA06871; Wed, 6 Feb 85 13:46:19 pst Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1) id AA03096; Wed, 6 Feb 85 14:37:05 MST Received: by utah-orion.ARPA (4.42/4.40.1) id AA10406; Wed, 6 Feb 85 14:36:22 MST Date: Wed, 6 Feb 85 14:36:22 MST From: kessler%utah-orion@utah-cs (Robert Kessler) Message-Id: <8502062136.AA10406@utah-orion.ARPA> To: peck@sri-spam.ARPA Cc: ailist-request@sri-ai.ARPA, franz-friends@Berkeley Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message) In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed). <8502062000.AA08198@sri-spam.ARPA> > I would like to here from anyone using SUN computers > who can supply answers or comments on any of these issues: > Is Franz the only (best) lisp available? We have finally finished porting Portable Standard LISP (PSL) to yet another machine. This time it is now running on the SUN. Initial timing measurements indicate that its speed is somewhere between a Vax 750 and 780 (all running PSL), and about twice as fast as Franz running the REDUCE algebra system test on Suns. We are now running the Gabriel benchmarks to discover where it fits in the set. For more details see the announcement at the end of this message. > Has anyone used the Maryland Flavors to create useful tools/extensions? PSL provides support for a simple flavors package that seems quite useful. However, the current version has no inheritance. > Any support for sun graphics (windows, menus,etc) a la Interlisp-D? We have oload working which allows you to call externally compiled routines (like other c sources). So the interface should be easy to add (but we haven't done it). > Any differential reports of Prolog (Quintus) vs Lisp ? None that I know of. > Any obvious alternative to SUN? (vendor in same class (Tektronix?)) PSL also runs on Apollo's and HP Series 200 (both 68K based machines). We have also ported a simple "educational" version to the 128K Macintosh which is used in a beginning programming class. We plan on moving at least the Standard LISP subset and compiler to the 512K mac (so if you want to go really cheap...... :-) ) > Worst or hidden problems, pitfalls, gotcha's, etc. We had a lot of problems with the Sun port. Some were hardware related, others were differences between Unix 4.2 on the Sun and on the Vax. After we get some more experience using PSL on the machine, maybe we could report more. > > Can real AI development (even applications) be supported on SUN's? < I think so, as long as you can get one with enough memory. Some of our applications running on HP 9836's (which doesn't have virtual memory) really fly (better than a 780 in speed). So, memory is really a key to a fast machine. > Bob. PSL 3.2 for the SUN Workstation We are pleased to announce that Portable Standard LISP (PSL) version 3.2 is now available for the Sun workstation. PSL is about the power, speed and flavor of Franz LISP or MACLISP, with growing influence from Common LISP. It is recognized as an efficient and portable LISP implementation with many more capabilities than described in the 1979 Standard LISP Report. PSL's main strength is its portability across many different systems, including: Vax BSD Unix, Vax VMS, Extended Addressing DecSystem-20 Tops-20, Apollo DOMAIN Aegis, and HP Series 200. A version for the IBM-370 is in beta test and two Cray versions are being used on an experimental basis. Since PSL generates very efficient code, it is an ideal delivery vehicle for LISP based applications (we can also provide PSL reseller licenses for binary only and source distributions). PSL is distributed for the various systems with executables, all sources, an approximately 500 page manual and release notes. The release notes describe how to install the system and how to rebuild the various modules. We are charging $750 for the Sun version of PSL for Commercial Site licenses. Non-profit institutions and all other versions of PSL will not be charged a license fee. We are also charging a $250 tape distribution fee for each system. PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard, Rand, Stanford, Columbia and over 250 other sites. Many existing programs and applications have been adapted to PSL including Hearn's REDUCE computer algebra system and GLISP, Novak's object oriented LISP dialect. These are available from Hearn and Novak. To obtain a copy of the license and order form, please send a NET message or letter with your US MAIL address to: Utah Symbolic Computation Group Secretary University of Utah - Dept. of Computer Science 3160 Merrill Engineering Building Salt Lake City, Utah 84112 ARPANET: CRUSE@UTAH-20 USENET: utah-cs!cruse  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA11142; Wed, 6 Feb 85 17:30:40 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00117; Wed, 6 Feb 85 16:55:20 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA28782; Wed, 6 Feb 85 12:01:17 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA04441; Wed, 6 Feb 85 12:00:09 pst Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16) id AA08198; Wed, 6 Feb 85 12:00:05 pst Message-Id: <8502062000.AA08198@sri-spam.ARPA> Date: 06 Feb 85 11:59:58 PST (Wed) To: ailist-request@sri-ai, franz-friends@Berkeley Subject: AI, Lisp, Graphics on SUN computers? From: peck@sri-spam I would like to here from anyone using SUN computers who can supply answers or comments on any of these issues: Is Franz the only (best) lisp available? Has anyone used the Maryland Flavors to create useful tools/extensions? Any support for sun graphics (windows, menus,etc) a la Interlisp-D? Any differential reports of Prolog (Quintus) vs Lisp ? Any obvious alternative to SUN? (vendor in same class (Tektronix?)) Worst or hidden problems, pitfalls, gotcha's, etc. > Can real AI development (even applications) be supported on SUN's? <  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA00482; Thu, 24 Jan 85 06:02:14 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01886; Thu, 24 Jan 85 06:00:42 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14651; Thu, 24 Jan 85 06:01:33 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA00458; Thu, 24 Jan 85 06:00:41 pst Message-Id: <8501241400.AA00458@UCB-VAX.ARPA> Received: by mit-ems.Mit-chaos.Arpa id AA25956; Thu, 24 Jan 85 08:59:42 est Date: Thu, 24 Jan 85 08:59:42 est From: Steven Haflich To: franz-friends@Berkeley, sridhar%wsu.csnet@csnet-relay Subject: Re: pretty printing Since comments are not part of a Lisp form returned by `read', clearly no pretty-print function can do what you want. Certainly a far more complicated pretty-printer could be written which would be passed an ascii file to read and which would somehow preserve comments inside the form in order to regurgitate them during formatting. The problem has several complications, however, such as how to handle ascii Lisp text with conditionalized inclusions (`#+' constructions)... Instead, what you want is probably provided the Lisp-mode `grind' facilities available in several popular text editors -- in particular, EMACS. (I know CCA EMACS works, and believe Gosling EMACS does also.) In these editors a couple keystrokes will specify a region of text and apply one of several Lisp-indentation algorithms to it. They almost always indent in reasonable ways, and attempt to do reasonable things with comments, at least. The ones with which I am familiar will *not*, however, adjust line length length by moving either comment or Lisp text from line to line. This is not a great problem for normal human-typed text, such as programs, since one tends not to type absurdly long lines.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA00206; Thu, 24 Jan 85 05:34:24 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01874; Thu, 24 Jan 85 05:32:53 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14557; Thu, 24 Jan 85 05:33:59 pst Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA00666; Thu, 24 Jan 85 05:16:27 pst Message-Id: <8501241316.AA00666@UCB-VAX.ARPA> Date: Thu, 24 Jan 85 7:59:46 EST From: "Ferd Brundick (VLD/LTTB)" To: "S. Sridhar" Cc: Franz-Friends@Berkeley Subject: Re: pretty printing Haah, Franz's (read) function trashes all comments on input. [Which means you can document your data files.] You have to pretty-print the original code before Franz gets it. I don't know of any stand-alone programs to do this (surely someone has written one). I use Berkeley's "vi" editor because it has a lisp mode; all input is automatically pretty-printed if you say :set ai lisp (ai stands for autoindent) Another way is to execute the vi "=" command while in lisp mode. All of this is documented in the vi manual. Hope this helps. dsw, fferd Fred S. Brundick USABRL, APG, MD.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.41) id AA27503; Thu, 24 Jan 85 00:34:10 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01652; Thu, 24 Jan 85 00:32:25 pst Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27) id AA12825; Thu, 24 Jan 85 00:31:15 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.40) id AA15268; Thu, 24 Jan 85 00:31:03 pst Message-Id: <8501240831.AA15268@ucbernie.ARPA> Received: from wsu by csnet-relay.csnet id a006053; 24 Jan 85 3:16 EST Date: Wed, 23 Jan 85 21:50 PST From: "S. Sridhar" To: cross%lsu.csnet@csnet-relay.ARPA Cc: franz-friends@UCBERNIE.ARPA Subject: pretty printing Is there any way I can pretty-print Franz lisp function (or files) with all the comments in tact. Right now when I use the built in pp, it pretty prints and strips off all comments. I mean is there any built-in function that does this. Thanks. Sridhar (sridhar@wsu)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA01152; Wed, 2 Jan 85 02:52:15 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA25935; Wed, 2 Jan 85 03:08:49 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08140; Wed, 2 Jan 85 03:00:04 pst Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA01144; Wed, 2 Jan 85 02:51:04 pst Message-Id: <8501021051.AA01144@UCB-VAX.ARPA> Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a029713 ;2 Jan 85 5:57 EST To: franz-friends@Berkeley Cc: johnson@udel-dewey Subject: franz on 68k-based systems? (esp NCR tower) Date: 02 Jan 85 05:57:37 EST (Wed) From: johnson Has anyone out there had experience using franz (or similar lisps) on an NCR tower or tower XP? (or any other 68k-based unix system ?) I am interested in answers to these questions: 1. What version of (franz) lisp are you using. 2. Are there any special problems you've discovered in this system? 3. How does this system perform? (compared to franz on a VAX 11/70, assuming you have had experience with both) 4. Where did you obtain your version of (franz) lisp and how? (what media, what cost, under what terms or license?) thanks in advance, johnson@udel-ee  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA04769; Tue, 18 Dec 84 12:20:33 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA16206; Tue, 18 Dec 84 12:23:59 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00302; Tue, 18 Dec 84 12:19:24 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA04349; Tue, 18 Dec 84 11:54:53 pst Received: by tove.ARPA (4.12/4.7) id AA26165; Tue, 18 Dec 84 14:54:41 est From: Liz Allen Message-Id: <8412181954.AA26165@tove.ARPA> Date: 18 Dec 1984 1454-EST (Tuesday) To: Wilson.Harvey@CMU-CS-IUS Cc: franz-friends@Berkeley Subject: Re: appending to files in lisp? In-Reply-To: Your message of 17 Dec 84 16:02:13 EST. <8412172107.AA24610@UCB-VAX.ARPA> To append to a file, use the outfile function's second argument: (setq oport (outfile ' 'append)) This is discussed in the documentation for outfile in the Franz Lisp Manual. -Liz  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA10628; Tue, 18 Dec 84 16:47:24 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA16410; Tue, 18 Dec 84 16:50:57 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02563; Tue, 18 Dec 84 16:46:44 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA10079; Tue, 18 Dec 84 16:15:50 pst Message-Id: <8412190015.AA10079@UCB-VAX.ARPA> Date: 17 Dec 84 23:04:24 EST From: Wilson.Harvey@CMU-CS-IUS Subject: appendfile question answered To: BBoard.Maintainer@CMU-CS-A Wow, was that an easy question. All the responces were equally simple (use "fileopen" with mode = a, or use "outfile" with the extra argument "append"). I must have an outdated copy of the manual because I could find none of these "features" documented. A hearty "Thank you" to all who responded. Wilson  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA25498; Mon, 17 Dec 84 13:33:41 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15083; Mon, 17 Dec 84 13:36:02 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01357; Mon, 17 Dec 84 13:31:59 pst Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA25405; Mon, 17 Dec 84 13:30:56 pst Message-Id: <8412172130.AA25405@UCB-VAX.ARPA> Date: Mon, 17 Dec 84 16:23:16 EST From: William K. Cadwallender (LCWSL) To: franz-friends@Berkeley Subject: Please change my ID The computer people here at ARDC have changed my ID: I was wkc@ARDC, I am now cadwall@ARDC. Please update the franz-friends mailer accordingly. Thanks, Bill Cadwallender (now cadwall@ARDC)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24848; Mon, 17 Dec 84 13:15:40 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15070; Mon, 17 Dec 84 13:18:00 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01005; Mon, 17 Dec 84 13:06:53 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24568; Mon, 17 Dec 84 13:05:59 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA15044; Mon, 17 Dec 84 13:08:10 pst Date: Mon, 17 Dec 84 13:08:10 pst From: John Foderaro (on a sun) Message-Id: <8412172108.AA15044@ucbmike.arpa> To: franz-friends@Berkeley Subject: I'll be away Cc: For the new few weeks I'll be unable to handle franz-friends requests. Happy Holidays to all of you. john foderaro  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24722; Mon, 17 Dec 84 13:11:28 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15059; Mon, 17 Dec 84 13:13:45 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01035; Mon, 17 Dec 84 13:08:08 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA24610; Mon, 17 Dec 84 13:07:10 pst Message-Id: <8412172107.AA24610@UCB-VAX.ARPA> Date: 17 Dec 84 16:02:13 EST From: Wilson.Harvey@CMU-CS-IUS Subject: appending to files in lisp? To: BBoard.Maintainer@CMU-CS-A Does anyone have a function that will allow them to append to a file? I need to open a file and write some data to it then, at a later time, reopen the same file and add some more data to it. The only things that I could find in Franz were "infile" and "outfile", and "outfile" truncates the file when called. It would be nice if the function would create the file if it didn't already exist, but that is not necessary. Thanks. --Wilson P.S. I tried writing a C-function to handle this, but I didn't have any luck passing the FILE pointer back into Franz. It didn't recognize the pointer as a port, and I don't know how to set it straight.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24505; Mon, 17 Dec 84 13:03:26 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15027; Mon, 17 Dec 84 13:05:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00901; Mon, 17 Dec 84 13:01:48 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24456; Mon, 17 Dec 84 13:00:55 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA15009; Mon, 17 Dec 84 13:03:16 pst Date: Mon, 17 Dec 84 13:03:16 pst From: John Foderaro (on a sun) Message-Id: <8412172103.AA15009@ucbmike.arpa> To: psm@Mitre-Bedford, franz-friends@Berkeley Subject: Re: Please add me to your mailing list. Cc: psm@Mitre-Bedford In-Reply-To: Your message of 17 Dec 1984 11:56:37-EST I've added you to franz-friends.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA19483; Mon, 17 Dec 84 09:07:09 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA14846; Mon, 17 Dec 84 09:09:29 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20993; Mon, 17 Dec 84 09:05:35 pst Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA19421; Mon, 17 Dec 84 09:04:32 pst Message-Id: <8412171704.AA19421@UCB-VAX.ARPA> Date: 17 Dec 1984 11:56:37-EST From: psm@Mitre-Bedford To: franz-friends@Berkeley Subject: Please add me to your mailing list. Cc: psm@Mitre-Bedford Hi, Would you please add me to your mailing list/ user's group. (I hope this is the right place to make the request & it's not franz-friends-request or something like that. Sorry for the inconvenience if it is.) Peter Mager (psm@mitre-bedford)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA08591; Wed, 12 Dec 84 22:01:41 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA08942; Wed, 12 Dec 84 22:03:25 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08208; Wed, 12 Dec 84 21:51:39 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA07258; Wed, 12 Dec 84 21:03:56 pst Message-Id: <8412130503.AA07258@UCB-VAX.ARPA> Date: Wednesday, 12 December 1984, 19:53-EST From: Robert L. Krawitz Reply-To: rlk%mit-eecs at mit-mc.arpa To: franz-friends@Berkeley Hi. I'm writing a term paper on the procedure call in various languages, perhaps on various languages on the VAX, perhaps just on the procedure call in various dialects of Lisp on the Vax. Could someone mail me some info on this subject (i. e. the calling conventions, how/if the Vax procedure call instructions are used, etc.) quickly, as this is the last week of classes and I don't want to take too long on this paper. Thanks. Robert^Z  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA16148; Tue, 11 Dec 84 20:47:01 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA07823; Tue, 11 Dec 84 20:48:59 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06672; Tue, 11 Dec 84 20:44:19 pst Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA16044; Tue, 11 Dec 84 20:42:36 pst Message-Id: <8412120442.AA16044@UCB-VAX.ARPA> Date: 11 Dec 84 23:41:49 EST From: Sean McLinden Subject: Re: Franz documentation for MIT LM code To: smh%MIT-EDDIE@MIT-MC.ARPA, franz-friends@Berkeley Cc: sridhar%wsu.csnet@CSNET-RELAY.ARPA, MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "Steven M. Haflich " of 4 Dec 84 23:50:01 EST Regarding the documentation for Franz Lisp and the MIT/Lisp Machine compatibility packages: Another option exists for those who might be interested. We at Decision Systems Lab have been using a modified version of Opus 38.89 which in- cludes the defstruct and flavors code already described. It also in- cludes an Interlisp compatibility package which allows Interlisp records as well as most of the CLISP forms (these are actually very easily simulated with LOOP but we chose a strategy which is more in keeping with the Interlisp implementation of CLISP involving hashed definitions for CLISP forms. The modified Lisp has all of the up-to-date flavors code and an edited version of the manual which describes the format, defstruct, and CLISP packages (borrowing heavily from the Laser edition of the Common Lisp manual by Guy Steele). It also includes a re-organization of much of the older manual into a more coherent form, and a number of examples of more difficult concepts. If there is any interest I can make this publicly available. It would be of little value to simply have the additional chapter since it refers, heavily, to material in other sections. Also, flavors is not, yet included, since the status of flavors in Franz was uncertain up to a few months ago. For those interested, I will not be prepared to answer requests before Christmas but after that I'll be around and can handle almost anything. Sean McLinden Decision Systems Laboratory University of Pittsburgh -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA15233; Tue, 11 Dec 84 20:05:43 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA07792; Tue, 11 Dec 84 20:07:50 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06334; Tue, 11 Dec 84 20:05:09 pst Received: from SUMEX-AIM.ARPA (sumex-aim.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA15218; Tue, 11 Dec 84 20:03:46 pst Message-Id: <8412120403.AA15218@UCB-VAX.ARPA> Date: Tue 11 Dec 84 20:04:16-PST From: Rene Bach Subject: Porting FRANZ to other OS running C ? To: franz-friends@Berkeley I am interested in finding out if someone has ported FRANZ to some other OS than UNIX. A friend of mine is interested in running a LISP under VMS at no cost. He has C on his machine. Is this feasible, how much work is involved ? What about porting FRANZ to some UNIX look alike ? How much work is involved ? Thanks for any leads Rene -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA12597; Mon, 10 Dec 84 19:02:49 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06436; Mon, 10 Dec 84 19:05:37 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23540; Mon, 10 Dec 84 19:02:52 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA11754; Mon, 10 Dec 84 18:21:17 pst Message-Id: <8412110221.AA11754@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA03264; Mon, 10 Dec 84 21:20:04 est Date: Mon, 10 Dec 84 21:20:04 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: re: gensym and the compiler wants to know how to make this function work: ; construct an identity transformation matrix. (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (store (name i i) 1.0)) name) ) The problem is that send is a macro (see lisplib/array.l), and at compile time it is impossible for it to determine exactly the "data type" of name. Therefore, it expands the function to: (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (name 1.0 i i)) name) ) Essentially, it just assumes 'name is a symbol which has an array in its function binding, or else which symevals (possibly recursively) to something that is either an array, or a symbol with an array in its function binding. When the compiler compiles the expansion, it assumes that it wants to call the function-binding of name, not the function-binding of symeval of name. In the interpreter it happens to work because eval of a list in the interpreter (but not the compiler) is defined to repetitively evaluate the car of the list until it finds a recognizable function or array. (See chapter 4.) But note!! If 'name also has a function binding, the interpreter will find it instead of the array! What you really want to do, then, is this: (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (funcall name 1.0 i i)) name) ) This guarantees that name gets symevaled once before the interpreter checks for function bindings, which also does the right thing in compiled code. Unfortunately, you will have to write this out by hand. I don't see any way that the send macro can be fixed. If it always returned the extra funcall, then this simple case wouldn't work compiled: (array foo ...) (store foo ...) Did anyone follow any of this?  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA08979; Mon, 10 Dec 84 16:03:27 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06161; Mon, 10 Dec 84 16:06:22 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA21396; Mon, 10 Dec 84 16:03:40 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA08955; Mon, 10 Dec 84 16:01:22 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA06150; Mon, 10 Dec 84 16:04:09 pst Date: Mon, 10 Dec 84 16:04:09 pst From: John Foderaro (on a sun) Message-Id: <8412110004.AA06150@ucbmike.arpa> To: MOHAN@USC-ECLC.ARPA, franz-friends@Berkeley Subject: Re: array - space Cc: mohan@USC-ECLC.ARPA In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST You would be better off using immediate vectors (vectori) which are garbage collected. Items allocated with small-segment aren't gc'ed.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA10299; Mon, 10 Dec 84 17:12:04 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06340; Mon, 10 Dec 84 17:14:45 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22000; Mon, 10 Dec 84 17:08:13 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA10131; Mon, 10 Dec 84 17:05:36 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA06315; Mon, 10 Dec 84 17:08:19 pst Date: Mon, 10 Dec 84 17:08:19 pst From: John Foderaro (on a sun) Message-Id: <8412110108.AA06315@ucbmike.arpa> To: MOHAN@USC-ECLC.ARPA, franz-friends@Berkeley Subject: Re: array - space Cc: mohan@USC-ECLC.ARPA In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST One small correction: small-segment space is garbage collected and reclaimed, but only as individual elements: adjacent free elements are not combined. Vectors are different: adjacent free vectors are combined into larger vectors.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA08592; Mon, 10 Dec 84 15:42:01 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06063; Mon, 10 Dec 84 15:44:38 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20942; Mon, 10 Dec 84 15:37:50 pst Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA08450; Mon, 10 Dec 84 15:35:12 pst Received: from iapetus by rice.ARPA (AA26746); Mon, 10 Dec 84 17:28:43 CST Received: by iapetus (AA16942); Mon, 10 Dec 84 17:29:45 CST Date: Mon, 10 Dec 84 17:29:45 CST From: Mike Caplinger Message-Id: <8412102329.AA16942@iapetus> To: franz-friends@Berkeley Subject: gensym and the compiler How does one get code like the following: ; construct an identity transformation matrix. (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (store (name i i) 1.0)) name) ) to work under the compiler? Compiled, this refuses to believe in the existence of name. Do I need to declare it as a lambda? Is there a way to declare arrays? - Mike  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA04493; Mon, 10 Dec 84 12:08:50 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA05937; Mon, 10 Dec 84 12:11:21 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA18655; Mon, 10 Dec 84 12:06:53 pst Received: from USC-ECLC.ARPA (usc-eclc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA04397; Mon, 10 Dec 84 12:04:27 pst Message-Id: <8412102004.AA04397@UCB-VAX.ARPA> Date: Mon 10 Dec 84 12:03:06-PST From: MOHAN@USC-ECLC.ARPA Subject: array - space To: franz-friends@Berkeley Cc: mohan@USC-ECLC.ARPA I am working with images stored as fixnum arrays (with delta =1 i.e. four pixels packed into a word) aux as unmarked arrays. (I am on a VAX under Eunice). How do I deallocate the array-space once I am done with it? (I use small-segment to allocate space for the array). Also I would appreciate any pointers of how to speed up programs with nested do loops (order of 512x512 x(5 x 5) itterations). Thanks, -Rakesh Mohan. -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA22911; Sat, 8 Dec 84 05:41:15 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA03777; Sat, 8 Dec 84 05:42:32 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA25844; Sat, 8 Dec 84 05:42:09 pst Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA22892; Sat, 8 Dec 84 05:39:47 pst Received: from VANDERBILT.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2648813816713007@MIT-MULTICS.ARPA>; 08 Dec 1984 08:36:56 est Date: 06 Dec 84 15:26 CDT From: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA Reply-To: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA To: "franz-friends"@Berkeley Subject: FranzLISP on the S9000 Message-Id: <30788@VUCCG1COM> In-Reply-To: <30731@VUCCG1COM> The AI Group at Vanderbilt would like to join the franz-friends mailing list. We have version 38.87 running on the IBM Inruments S9000 under CSOS 1.1, a very non-UNIX opsys. Both interpreter and compiler are working and a farily large general-purpose expert system tool set written on a VAX is up and running.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA05716; Thu, 6 Dec 84 18:21:13 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01695; Thu, 6 Dec 84 18:22:08 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07782; Thu, 6 Dec 84 18:20:03 pst Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05141; Thu, 6 Dec 84 17:55:14 pst Received: from thule by rice.ARPA (AA02673); Thu, 6 Dec 84 19:41:33 CST Received: by thule (AA02845); Thu, 6 Dec 84 19:38:53 cst Date: Thu, 6 Dec 84 19:38:53 cst From: Mike Caplinger Message-Id: <8412070138.AA02845@thule> To: franz-friends@Berkeley Subject: bug in 68k Opus 38.91 arrays In 68k Opus 38.91, the expression (array foo flonum-block 4 4) generates an "Error: IMPROPER USE OF SET". On the VAX, in Opus 38.79, this worked fine. What's happening? (I am on a Sun, compiled with sun_4_2.) - Mike  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA29986; Thu, 6 Dec 84 13:53:23 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01497; Thu, 6 Dec 84 13:54:17 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03880; Thu, 6 Dec 84 13:53:03 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA27039; Thu, 6 Dec 84 11:43:13 pst Received: from CUNYVM.BITNET by ucbjade.CC.Berkeley.ARPA (4.19/4.30) id AA27252; Thu, 6 Dec 84 11:44:10 pst Message-Id: <8412061944.AA27252@ucbjade.CC.Berkeley.ARPA> Received: by CUNYVM id 8508; Thu, 06 Dec 84 14:41:26 EST Date: Thu, 6 Dec 84 14:39 EST From: Henry Nussbacher To: , , , , , Can you please register the following user to your lists: arpalist%cunyvm.BITNET Thank you, Henry Nussbacher BITNET Network Information Center  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA08935; Tue, 4 Dec 84 23:02:21 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21268; Tue, 4 Dec 84 23:06:01 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA29026; Tue, 4 Dec 84 22:49:05 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05974; Tue, 4 Dec 84 20:50:44 pst Message-Id: <8412050450.AA05974@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA24308; Tue, 4 Dec 84 23:50:01 est Date: Tue, 4 Dec 84 23:50:01 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: Franz documentation for MIT LM code Cc: sridhar%wsu.csnet@csnet-relay Sorry to report that there really is no official documentation for the several Franz lisplib modules which implement a measure of compatibility with Zetalisp, the dialect running on MIT Lisp Machines (and, more or less, on Symbolics and LMI machines). The Franz source code was adapted from the MIT Lisp machine code several years ago; there is still approximate compatibility, although new features and certain semantic subtleties have diverged. Driven partially by natural evolution and partially by the standardization efforts of Common Lisp, Lisp Machine compatibility is something of a moving target. But do not despair; there are two standardly available sources for documentation. Reading them will give a very usable idea about the packages. Unfortunately, a few unimplemented features and semantic differences will have to be discovered by experimentation or examination of the source code. (What do you want for free? :-) (1) If you have available a MIT Lisp Machine Manual, the sections on defstruct, flavors, format, hash, and loop output are still reasonable approximations of documentation for the Franz versions. Incidentally, the `Blue' MIT Lisp Machine Manual circa 1981 corresponds most closely with the Franz inplementation, although a few more recent features have been retrofitted. If available, Symbolics documentation is probably only very slightly less good -- the older, the better. (2) For defstruct, hash, and format the Guy Steele , published by Digital Press (a branch of DEC), is usefully close to the existing Franz code. Again, experimentation and examination of the source code will resolve the details. Unfortunately, Flavors and the loop macro are not (yet) part of the Common Lisp specification, and may well be very different when they are. Unofficially, there is another even better hope. The MIT Athena project will be `releasing' these packages into their standard Franz system this in another month or two. They are commencing a quick effort to edit Lisp Machine documentation into proper format for inclusion as appendixes in the Franz manual. If at all possible, I will attempt to get the results publically distributed. (Translation: My assistance is essential to this documentation, so I am in position to insist they be `reasonable' about it...) But no promises just yet. Steve Haflich MIT  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA04308; Tue, 4 Dec 84 19:37:04 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA20988; Tue, 4 Dec 84 19:40:37 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26327; Tue, 4 Dec 84 19:32:49 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA26237; Tue, 4 Dec 84 13:26:17 pst Message-Id: <8412042126.AA26237@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA20260; Tue, 4 Dec 84 15:44:20 est Date: Tue, 4 Dec 84 15:44:20 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: fix for describe.l Cc: MCLINDEN@RUTGERS@MIT-MC, smith@nrl-aic@mit-mc Previous postings have correctly identified the problem (which was fixed long ago in the versions announced today). The best fix is to change the (environment-lmlisp) invocation near the beginning of describe.l to read as follows, then recompile it: (environment-lmlisp (compile eval) (files struct flavorm)) The struct and flavorm modules do not need to be around when the compiled describe code is executed, so omitting load from the eval-when saves some unnecessary fasl's. Describe, by the way, is useful even when flavors and defstructs are not being used. For instance, it will report the source module in which a compiled function lives. Steve Haflich smh@mit-eddie@mit-mc {ihnp4, decvax!genrad}!mit-eddie!smh  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA25700; Tue, 4 Dec 84 13:00:12 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA20513; Tue, 4 Dec 84 13:03:43 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20917; Tue, 4 Dec 84 12:49:49 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA24636; Tue, 4 Dec 84 12:13:23 pst Message-Id: <8412042013.AA24636@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA19371; Tue, 4 Dec 84 14:50:26 est Date: Tue, 4 Dec 84 14:50:26 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: the *real* flavor sources (etc.) For some time I have been using and maintaining enhanced versions of the several Franz lisplib modules which implement various Lisp Machine compatibilities, most notably, the FLAVOR system and FORMAT output. jkf@berkeley has authorized me to announce public availability of these files via anonymous ftp from UCBKIM. These seven files are compatible with Opus 38.91, but supersede the versions in the 39.91 distribution. There are a number of bugfixes and new features. UCBKIM supports FTP with login "anonymous" and any password. The files are: ~anonymous/pub/flavors/Makefile flavors.l flavorm.l vanilla.l hash.l describe.l format.l The changes are too many to describe in detail. Many of the FLAVOR system changes are for compatibility with changes to Franz, although a few non-working or missing features (but not all) have been bludgeoned into functionality. In particular, wrappers work. The FORMAT module fixes a number of format directives which apparently never worked. However, some of the hairier ones are known still to be defective. This "completely unsupported" software is graciously being made available to all takers without any promises whatever: there is no promise of correctness, and no promise of support. Also, the sources total 160K and unsuitable for uucp distribution, and I don't have time to deal with tape requests [sorry]. The above notwithstanding, I am as eager as anyone for additional improvements to the code. Anyone with additional bugfixes is encouraged to communicate to me, and I will try to integrate the code. I will try to respond to bug reports, but it may be a rather low priority business. Steve Haflich MIT Experimental Music Studio ARPA: smh@mit-eddie@mit-mc UUCP: {ihnp4, decvax!genrad}!mit-eddie!smh  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA11064; Sat, 1 Dec 84 22:26:09 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17402; Sat, 1 Dec 84 17:05:57 pst Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27) id AA06036; Sat, 1 Dec 84 16:55:15 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.38) id AA08322; Sat, 1 Dec 84 16:50:50 pst Message-Id: <8412020050.AA08322@ucbernie.ARPA> Received: from wsu by csnet-relay.csnet id a012949; 1 Dec 84 19:41 EST Date: Sat, 1 Dec 84 12:47 PST From: "S. Sridhar" To: franz-friends@UCBERNIE.ARPA Cc: sridhar%wsu.csnet@csnet-relay.ARPA Subject: Documentation pblms. Hi, I am an ardent Franz hack here at Wash. St. Univ, Pullman. I need some specific info on Franz Lisp. There is no documentation on 'Structures' in the Franz Lisp manual, that we have here. (This is dated June 1983. The version we have is Opus 38.69, June 1983). Specifically I need documentaion on all the macros related to the use of structures like defstruct. I know for sure that these macros are available on our system, but I am having problems on their usage. The on-line documentation does not give any help either. Maybe you have an updated version of the Franz Lisp manual. Can you help around, please ? As another instance, functions relating to hashtables are available here but there is no documentation for it. Thanks. Sridhar ------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA16866; Mon, 3 Dec 84 12:18:41 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA19168; Mon, 3 Dec 84 12:22:01 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04104; Mon, 3 Dec 84 12:17:10 pst Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA16806; Mon, 3 Dec 84 12:14:27 pst Date: 3 Dec 1984 06:36-EST From: Russ Smith Subject: followup to "flavors bugs (and more)" To: franz-friends@Berkeley Message-Id: <470921820/smith@nrl-aic> This is a followup to a previous note I sent requesting help with fixing Opus 38.91 of Franz and Flavors running on a Vax780 under 4.2BSD. First, I want to thank the many people who had helpful suggestions on what may have been going wrong. Given the small amount of information I provided on the problem, some of them were remarkably relevant. The problem had to do with certain functions such as "describe" going south when invoked on a FLAVOR object. The solution was (at least) two fold. One, which I alluded to in the previous note, had to do with the distributed file "hash.l" containing invalid calls on the intrinsic "getlength" function with a vector argument. These calls had to be changed to "vsize" instead (actually "getlength" could probably have been redefined to allow vectors...). Whatever, that solved that part. The second solution had to do with how WE at NCARAI were installing Franz. We have a set of directories for "local" software into which we wanted to put the "new" Franz. As such, I went through all the "Makefile"s and changed default directories for such things as the libraries and objects, etc. While doing this, it was noted that certain files in the "lisplib" directory had hard-coded the default names for, for example, the library. Since our library was not in the same place as this default, these lines were "commented out" (with an "exit")...with the result that the Franz and Liszt installations did not go as smoothly as I thought. It turns out that these lines also should be changed to reflect the appropriate directory. They are in the files "buildlisp.l", "common1.l", and "fix.l" in the lisplib directory (possibly others exist as well). The pertinent lines read something like: (or (boundp 'default-library-directory) (setq default-library-directory '/usr/lib/lisp)) During the installation (done on a CRT) I was doing something else. Thus when the mods made (namely changing the "setq" call above into an "exit") were invoked, I didn't notice later that a number of things which SHOULD have happened didn't (they'd gone off the screen...). Needless to say, this caused all sorts of bizarre inconsistencies (especially since our last installation DID use the default directories...). Anyway, notes for the future: (1) If ftp'ing Franz from ucbkim be sure to get the stuff in the "flavors" directory as well. This contains a new "hash.l" modified by SMH to use "vsize" rather than "getlength". (2) If not using the default directories for the installation, change the names in the above files as well to reflect the appropriate place(s)...sigh. Yours (with an apparently working Franz+flavors), Russ Navy Center for Applied Research in Artificial Intelligence (whew!)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA04841; Sat, 1 Dec 84 15:53:09 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17332; Sat, 1 Dec 84 15:54:45 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04698; Sat, 1 Dec 84 15:40:10 pst Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA03439; Sat, 1 Dec 84 14:28:56 pst Message-Id: <8412012228.AA03439@UCB-VAX.ARPA> Date: 30 Nov 84 22:45:59 EST From: Sean McLinden Subject: Re: bugs using flavors (and more) To: smith@NRL-AIC.ARPA, franz-friends@Berkeley Cc: MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "Russ Smith " of 30 Nov 84 11:50:00 EST There is a bug in the way that describe is compiled according to the makefile. Basically the problem is that defstruct-description-name is a macro which is NOT compiled so that when you fasl the compiled version of struct (as you are compiling describe), you don't get the proper definition for defstruct-description-name. You can either 1). load struct.l when compiling describe.l or 2). (declare (macros t)) in struct.l and recompile. Sean McLinden Decision Systems Laboratory -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA24319; Fri, 30 Nov 84 09:19:05 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15551; Fri, 30 Nov 84 09:21:18 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15087; Fri, 30 Nov 84 09:17:53 pst Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA24282; Fri, 30 Nov 84 09:15:33 pst Date: 30 Nov 1984 11:50-EST From: Russ Smith Subject: bugs using flavors (and more) To: franz-friends@Berkeley Message-Id: <470681409/smith@nrl-aic> I recently installed opus 38.91 on our VAX780 under 4.2BSD. The installation went smoothly. The files used for the installation appear to be the most recent available from ucbkim. This includes the flavors stuff with appropriate modifications (for example, fixing hash.l to use "vsize" instead of "getlength" on a vector). The flavors stuff I scarfed TODAY was dated October 2nd I believe. Anyway, I tried out some things with flavors and, in particular, with "describe"...with the following result (done with "script"): ============================================================================= % lisp Franz Lisp, Opus 38.91 -> (defflavor ob () () :settable-instance-variables) [autoload /usr/lib/lisp/flavors] [fasl /usr/lib/lisp/flavors.o] [fasl /usr/lib/lisp/machacks.o] [fasl /usr/lib/lisp/lmhacks.o] [fasl /usr/lib/lisp/flavorm.o] [fasl /usr/lib/lisp/vanilla.o] ob -> (describe 'ob) [autoload /usr/lib/lisp/describe] [fasl /usr/lib/lisp/describe.o] ob has property flavor: flavor[17] Error: Undefined function called from compiled code defstruct-description-name <1>: (exit) ============================================================================= [Well, "defstruct-description-name" is used all over the "/usr/lib/lisp/struct.l" set of functions...apparently mostly with no arguments...which, I think, is wrong. One fix made by SMH to "describe.l" replaced a call on this macro with one with an argument. But that's NOT this problem anyway.] (1) Is there a known fix to get the "describe", or anything else that uses the "defstruct-description-name" macro, working correctly? (2) Could it be that some sort of extended "defflavor" would load in an appropriate file which on-the-fly defines this macro? That is, did I do TOO simple a "defflavor"? [For example, doing: (load '/usr/pub/lisp/struct.l) allows one to "(pp defstruct-description-name)" showing that it requires an argument...without the "load" it is undefined.] (3) Could the copy of the ftpable (???) opus38.91 files we have be out of date (seem to be from around June 84)? Any help would be much appreciated. We are attempting to develop some stuff for use on both an LMI Lisp Machine and the VAX. This has thrown the proverbial wrench into the work(s)... Russ Navy Center for Applied Research in Artificial Intelligence (whew!)