lisp/ 040770 005204 001752 00000000000 04674004443 010303 5 0 ilpsoft ilp 1 0 lisp/opus38.92.aa 100660 005204 001752 00001720466 03510114624 010710 0 37777777777 1 0 # Franz Lisp distribution Opus 38.89 mkdir franz mkdir franz/h mkdir franz/vax mkdir franz/68k mkdir liszt mkdir liszt/vax mkdir liszt/68k mkdir doc mkdir utils mkdir pearl mkdir lisplib mkdir lisplib/manual mkdir lisplib/autorun cat > ./Makefile ${LispDist}/lispas setupx: (X=`pwd`; cd ${LibDir};\ make Liszt="$$X/liszt/${Mach}/nliszt -e '(sstatus feature for-${Mach})'" xtra) (cd liszt/${Mach}; make -f Makefile2 xtra) genlispscript: @echo \# Franz Lisp distribution Opus ${Version} @echo mkdir franz @echo mkdir franz/h @echo mkdir franz/vax @echo mkdir franz/68k @echo mkdir liszt @echo mkdir liszt/vax @echo mkdir liszt/68k @echo mkdir doc @echo mkdir utils @echo mkdir pearl @echo mkdir lisplib @echo mkdir lisplib/manual @echo mkdir lisplib/autorun @scriptcat . . ${Src} @echo chmod 775 lispconf @(cd franz ; make scriptcatall) @(cd franz/vax ; make scriptcatall) @(cd franz/68k ; make scriptcatall) @(cd liszt ; make scriptcatall) @(cd liszt/vax ; make scriptcatall) @(cd liszt/68k ; make scriptcatall) @(cd doc ; make LibDir=${LibDir} scriptcatall) @(cd utils ; make scriptcatall ) @(X=`pwd` ; cd pearl ; make CdTo=$$X scriptcatall) @(X=`pwd` ; cd ${LibDir} ; make CdTo=$$X scriptcatall) @echo \# end of Franz Lisp Distribution genas68: @(echo mkdir as68;cd as68; make scriptcat) genxtra: @(X=`pwd` ; cd ${LibDir} ; make CdTo=$$X scriptcatxtra) @(cd liszt/${Mach} ; make -f Makefile2 scriptcatxtra) clean: cd franz ; make clean cd franz/vax; make clean cd franz/68k; make clean cd liszt ; make clean cd liszt/vax; make clean cd liszt/68k; make clean cd doc ; make clean vdist-dim: rdist -v -d host=dim dist-dim: rdist -d host=dim EndOfFile cat > ./ReadMe ./lispconf Make$$ mv Make$$ Makefile ! franz/h/lconf.h echo "#define $argv[1] 1" >>! franz/h/lconf.h rm -f franz/h/{aout,lispo}.h cp /usr/include/a.out.h franz/h/aout.h cp /usr/include/a.out.h franz/h/lispo.h breaksw default: echo "use: lispconf type" echo " where type is one of " echo " vax_4_1 vax_4_1a vax_4_1c vax_4_2 vax_4_3" echo " vax_eunice_vms" echo " sun_4_1c sun_unisoft dual_unisoft pixel_unisoft " echo " sun_4_2beta lisa_unisys3 mc500_2_0" exit 1 endsw set ifusft="" set ifsys3="" switch ($argument) case vax_*: set VAX mach="vax" (echo vax ucbstd; cat Makefile) | awk -f cvt.awk > Make$$ mv Make$$ Makefile Make$$ mv Make$$ Makefile Make$$ (echo unisoft $ifsys3;\ cat franz/68k/Makefile) |awk -f cvt.awk > franz/68k/Make$$ rm -f franz/h/{lispo,aout}.h cp franz/h/duallispo.h franz/h/lispo.h cp franz/h/dualaout.h franz/h/aout.h cp franz/h/hpagsiz.h franz/h/pagsiz.h cp lisplib/autorun/unisoft lisplib/autorun/68k breaksw case sun_4_2beta: case sun_4_2: set ifsunII=sunII case sun_4_1c: (echo sun; cat liszt/68k/Makefile) | awk -f cvt.awk > Make$$ (echo sun $ifsunII; cat franz/68k/Makefile)\ | awk -f cvt.awk > franz/68k/Make$$ cp lisplib/autorun/sun4.2 lisplib/autorun/68k breaksw case mc500_2_*: (echo mc500; cat liszt/68k/Makefile) | awk -f cvt.awk > Make$$ (echo mc500; cat franz/68k/Makefile)\ | awk -f cvt.awk > franz/68k/Make$$ cp lisplib/autorun/mc500 lisplib/autorun/68k breaksw endsw rm -f liszt/68k/Makefile sed "s%^RootDir = .*%RootDir = `pwd`%" Make$$ > liszt/68k/Makefile rm -f Make$$ rm -f franz/68k/Makefile mv franz/68k/Make$$ franz/68k/Makefile if ($ifusft/x == unisoft/x) then switch ($argument) case sun_unisoft: set OFFSET=0x40000 breaksw case dual_unisoft: set OFFSET=0x800000 breaksw case pixel_unisoft: case lisa_unisys3: set OFFSET=0x20000 breaksw endsw sed "s%^OFFSET = .*%OFFSET = $OFFSET%"\ lisplib/autorun/68k > temp$$ mv temp$$ lisplib/autorun/68k ./lispnews means 'the previous expression printed'. prinlevel and prinlength are set to reasonable values to prevent the expression from getting too large (showstack t) : same as above but print all expressions. (showstack 5) : print only the first 5 expressions. of course, 5 is not the only possible numeric argument. (showstack lev 3) : set prinlevel to 3 before printing (showstack len 4) : set prinlength to 4 before printing the above arguments can be used in combination. The default value of prinlevel is showstack-prinlevel, that of prinlength is showstack-prinlength. the default showstack printer is the value of showstack-printer (default is 'print'). baktrace accepts the same arguments as showstack, but it ignores the prinlevel and prinlength arguments. From jkf Sat Apr 24 08:55:18 1982 To: local-lisp Subject: lisp opus 38.12, liszt 8.05 Status: RO these changes and enhancements were made: 1) the function 'function' in the interpreter acts just like 'quote' In the compiler, 'function' will act like 'quote' unless the argument is a lambda expression, in which case liszt will replace the lambda expression with a unique symbol. That unique symbol's function cell will contain a compiled version of the lambda expression. These changes will make Franz compatible with Maclisp type lisps, as far as the treatment of 'function' 2) Mechanisms were added to permit user written C or Fortran code to call lisp code. Everything isn't quite ready yet. 3) Signal was fixed so that if you ask for a signal to be ignored, the operating system will be notified. The correct way to fork a lisp is now: (cond ((fork) (signal 2 (prog1 (signal 2) (wait))))) 4) You can select the default function trace uses to print the arguments and results. Just lambda bind trace-printer to the name of the function you want it to use. The standard trace-printer sets prinlevel and prinlength to the values of trace-prinlevel and trace-prinlength before printing. By default, trace-prinlevel is 4, and trace-prinlength is 5 From jkf Sun Apr 25 23:46:16 1982 To: local-lisp Subject: lisp opus 38.13 Status: RO Functions 1+ and 1- are now part of the interpreter, rather than being made equivalent to add1 and sub1. From jkf Wed Apr 28 09:52:43 1982 To: local-lisp Subject: Opus 38.14 Status: RO Has these new features: 1) the message [load filename] will appear before load reads in a lisp source file. This can be disabled by setting $ldprint to nil. 2) a function 'truename' as been added. It takes a port and returns the name of the file associated with that port. It returns a string if there is a file associated with the port, otherwise it returns nil. From jkf Wed Apr 28 10:36:34 1982 To: local-lisp Subject: more on opus 38.14 Status: RO $ldprint is lambda bound to nil during the loading of the lisprc file. From jkf Wed May 5 08:30:00 1982 To: local-lisp Subject: opus 38.15 Status: RO a minor modification: 'makhunk' is now more efficient. From jkf Wed May 5 20:56:40 1982 To: local-lisp Subject: Opus 38.16 Status: RO A new function was added: (hunk-to-list 'h_hunk) returns the elements of h_hunk as a list. Also, the error message printed when an oversized print name is encountered has been improved. From jkf Fri May 7 20:03:40 1982 To: local-lisp Subject: Liszt version 8.06 Status: RO Local declarations are now supported. You can say: (defun foo (a b) (declare (special a)) ... body ...) and the special declaration for 'a' will affect the body of function foo only. The 'a' which is an argument to foo will also be special in this case. Declarations may be 1) at the top level, not within a function body. 2) at the beginning of a 'lambda' body. 3) at the beginning of a 'prog' body 4) at the beginning of a 'do' body. 'the beginning' means either the first, second or third form in the body. When the compiler is searching for declarations, it will not macroexpand. Fixnum declarations now have meaning. If you do (declare (fixnum i j)) then (greaterp i j) will be converted to (>& i j) The declare function is now defined in the compiler. Previously, the only way to declare something was for the compiler to 'compile' the declaration form. Now, if you load or fasl in a file with a declare statement in it, the declare statement will have the proper effect in the compiler. (function (lambda () ...)), (function (nlambda () ...)) and (function (lexpr () ...)) are all supported. From jkf Wed May 12 08:15:37 1982 To: local-lisp Subject: Lisp Opus 38.17 Status: RO ... has a minor bug fix: The port returned by 'fileopen' will now print correctly. From jkf Tue May 25 06:18:04 1982 Date: 25-May-82 06:17:51-PDT (Tue) From: jkf Subject: opus 38.18 Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue) To: local-lisp Status: RO The msg macro will now evaluate all atom arguments except the ones for carriage control (N B). Thus if you used (msg foo) you should now use (msg "foo"). From jkf Thu May 27 08:29:29 1982 To: local-lisp Subject: liszt 8.08 Status: RO Fixes a bug in the code which converts generic arithmetic to fixnum only arithmetic. Liszt was converting from generic to fixnum operators based on the first argument only due to a typo in the code. From jkf Wed Jun 9 07:25:19 1982 To: local-lisp Subject: lisp Opus 38.20 Status: RO There is now a character macro for reading hexadecimal. #x1f = #X1f = #X1F = 31 #x-1f = -31 From jkf Thu Jun 17 15:42:54 1982 To: local-lisp Subject: Lisp Opus 38.21 Status: RO Has two routines for interfacing with termcap. These routines were written by morris djavaher and are meant to be called by lisp programs which have yet to be installed. From jkf Tue Jun 22 09:09:25 1982 Date: 22-Jun-82 09:09:13-PDT (Tue) From: jkf Subject: opus 38.22 Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue) To: local-lisp Status: RO setq with no arguments will now return nil. From jkf Wed Jun 30 19:05:54 1982 Date: 30-Jun-82 19:05:32-PDT (Wed) From: jkf (John Foderaro) Subject: liszt 8.09 Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed) To: local-lisp Status: RO liszt will now look in 12 places for an init file when it starts up. It will load in the first one it comes to only. The files it looks for are: { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , } From jkf Tue Sep 14 08:53:03 1982 Date: 14-Sep-82 08:52:44-PDT (Tue) From: jkf (John Foderaro) Subject: lisp opus 38.26 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999; 14-Sep-82 08:53:03-PDT (Tue) To: local-lisp Status: RO Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx. Now it reads them (and other similar symbols) correctly. From jkf Sat Oct 2 15:15:48 1982 Date: 2-Oct-82 15:15:32-PDT (Sat) From: jkf (John Foderaro) Subject: lisp opus 38.27 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796; 2-Oct-82 15:15:48-PDT (Sat) To: local-lisp Status: RO If you set the variable top-level-print to a non nil value, then that value will be used by the top-level to print out the result of the evaluation. This has effect in break loops too. For example, if you want the pretty printer to print out the top level values, type (setq top-level-print 'pp-form). From jkf Sun Oct 3 19:28:45 1982 Date: 3-Oct-82 19:28:29-PDT (Sun) From: jkf (John Foderaro) Subject: lisp opus 38.28 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829; 3-Oct-82 19:28:45-PDT (Sun) To: local-lisp Status: RO A modification has been made to the load function. Normally if you type (load 'x), the load function will first try to fasl the file x.o and failing that it will try to load x.l If you (setq load-most-recent t), and if x.l and x.o both exist, then load will fasl or load the most recently modified file. The load-most-recent flag only has an effect if you type the filename without a trailing .l or .o. From jkf Tue Oct 5 21:01:55 1982 Date: 5-Oct-82 21:01:33-PDT (Tue) From: jkf (John Foderaro) Subject: liszt 8.12, lisp 38.29 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358; 5-Oct-82 21:01:55-PDT (Tue) To: local-lisp Status: RO Liszt will now check that you are passing the correct number of arguments to functions. As a result, some files which have compiled without complaint in the past may compile now with warnings or errors. In this note, I'll explain what the compiler knows, what it looks for in your program, and how you can help the compiler understand your program. For each function, liszt either knows nothing about the the number of arguments to a function, or it knows the minimum number of arguments, or the maximum number of arguments, or both the minimum and maximum number of arguments. This information comes about in one of three ways: 1) it is known when liszt starts (by virtue of a value stored under the fcn-info indicator on a function's property list) 2) it is declared by the user, either via (declare (*arginfo ...)) or (declare (*args ...)) [see below] 3) it is determined when a (lambda) function is compiled. When a lambda is compiled, the compiler can easily figure out the minimum and maximum number of arguments. When an nlambda or lexpr function is compiled, the compiler doesn't make a guess as to how many arguments are expected. The user should use the (declare (*args ...)) form to tell the compiler how many arguments are expected. For lexpr's generated via 'defun' using &optional and &rest keywords, the correct declaration is generated automatically. Once liszt determines the number of arguments to a function, it uses that information to check that the function is called with the correct number of arguments. It does not check calls to the function that occured before it determined the correct number of arguments. [This backward checking will be added sometime in the future.] If liszt finds that a function is called with the wrong number of arguments, it prints an informative message. That message is a error if the function being called is one which is open coded by the compiler. The message is a warning otherwise. The reason for the distinction is that you are free to redefine functions not open coded by the compiler. If the number of arguments is not correct, it may just be that the compiler's database and your code are refering to two different functions. If you redefine system functions, you should use the (declare (*arginfo ...)) form to let the compiler know about the number of arguments expected by your version of the functions. You can declare the number of arguments to functions using this form (declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...)) where each min or max is either a fixnum or nil (meaning "I don't know") for example, here are some `correct' declarations: (declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil))) explanation: (read 0 2) means that the function read expects between 0 and 2 arguments (inclusive). (cons 2 2) means that cons expects 2 arguments. (boole 3 nil) means that boole expects at least 3 arguments. (append nil nil) means that append expects any number of arguments, this is equivalent to (append 0 nil). The *arginfo declaration is usually made at the top level of a file. To declare the argument characteristics of the current function being compiled use the '*args' declaration. It looks somewhat like the *arginfo declaration. It is best explained with examples (def read (lexpr (n) (declare (*args 0 2)) ... code for read )) (def process (nlambda (x) (declare (*args 1 3)) ... code for process )) Note: the *args declaration is not needed for lambda's. If you get an error or warning which you believe is incorrect, it is probably due to an incorrect database entry. Please let me know and I will fix it immediately. I expect that there will be quite a few of these errors because much of the database was built by hand. From jkf Fri Oct 8 12:55:45 1982 Date: 8-Oct-82 12:55:31-PDT (Fri) From: jkf (John Foderaro) Subject: lisp 38.30, liszt 8.13 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140; 8-Oct-82 12:55:45-PDT (Fri) To: local-lisp Status: RO There are now three new functions for dealing with processes: *process *process-send *process-receive These functions are designed to replace the 'process' function, which, due to its nlambda'ness, was difficult to use. All of the above functions are lambda's or lexpr's. See chapter 6 of the manual (its on-line) for the details of these functions. This is a quick summary: (*process-send 'st_command) tells the shell to run the command st_command concurrently, and returns a write-only port. Characters written to this port will appear at the standard input of st_command. example: (setq p (*process-send "mail jkf")) (print 'HiThere p) (close p) (*process-receive 'st_command) tells the shell to run st_command concurrently, and returns a read-only port. Characters written to the standard output by st_command will be available by reading from the given port. Characters written on the standard error by st_command will appear on lisp's the standard error (the terminal most likely). example: ; to see if foo is logged in: (setq p (*process-receive "u")) (do ((user (read p '**eof**) (read p '**eof**))) ((eq '**eof** user) (print 'Not-Logged-In)) (cond ((eq 'foo user) (print 'Is-Logged-In)))) (close p) (*process 'st_command ['g_readp ['g_writep]]) this is the general function which process, *process-send and *process-receive call. If called with one argument it starts the new process and waits for it to end, e.g: (*process (concat "vi " filename)) In this case *process return the exit code of the process. The g_readp and g_writep arguments, if given, tell *process to run the process concurrently. If g_read is non nil then *process will return a port just like *process-receive. If g_writep is non-nil, then *process will set up a pipe like *process-send. *process will return a list of the form (readport writeport process-id) where readport and writeport will only be a port if g_readp or g_writep are non nil. A little know fact about processes is that a process, once started, cannot die and disappear until its parent asks about its status. Take the mail example given above: (setq p (*process-send "mail jkf")) (print 'HiThere p) (close p) after the mail process finishes it work, it will attempt to die, returning an integer called the 'exit status'. However until the lisp program asks about its status the mail process will remain in existence in a Zombie state, somewhere between life and death. ps will show this: PID TT STAT TIME COMMAND 3876 p0 Z 0:01 A user is only allowed a small number of processes, so if you continue to generate processes and leave them around as Zombies, you will eventually run out of processes. The way to let the Zombie die is to call the wait function, e.g. -> (wait) (3876 . 0) -> this says that process 3876 died with exit status 0. Also, when you exit lisp the shell will clean up the Zombies. If you start a process with (*process "vi foo") then lisp will wait for it to complete before continuing, so you don't have to worry about Zombies. You only have to worry if you run a process concurrently, such as when you use *process-send or *process-receive. From jkf Tue Oct 12 10:44:22 1982 Date: 12-Oct-82 10:43:52-PDT (Tue) From: jkf (John Foderaro) Subject: lisp opus 38.31 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82]) id A29800; 12-Oct-82 10:44:22-PDT (Tue) To: local-lisp Status: RO new function: (time-string ['x_time]) if given no arguments, it returns the current time as a string. if given an argument, x_time, then it converts that argument to a time string and returns that string. The argument should represent the number of seconds since Jan 1, 1970 (GMT). note that this makes (status ctime) obsolete. From jkf Tue Oct 12 14:35:26 1982 Date: 12-Oct-82 14:34:10-PDT (Tue) From: jkf (John Foderaro) Subject: also in opus 38.31 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82]) id A05086; 12-Oct-82 14:35:26-PDT (Tue) To: local-lisp Status: RO If top-level-read is set to a non nil value, then the lisp top level will funcall it to read a form for evaluation. It will be funcalled with two arguments, a port and an eof marker. top-level-read will be used in break levels too. Be very careful when setting top-level-read because if you set it to an illegal value, there is no way to correct it. From jkf Tue Oct 19 18:54:18 1982 Date: 19-Oct-82 18:54:02-PDT (Tue) From: jkf (John Foderaro) Subject: lisp tags Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A00195; 19-Oct-82 18:54:18-PDT (Tue) To: franz-friends Status: RO We also use vi style tags so emacs users and vi users can share the same tags file. Rather than modify ctags, we use this shell script: #!/bin/csh # make a tags file for lisp source files. # use: # lisptags foo.l bar.l baz.l ... bof.l # generate the file 'tags' # awk -f /usr/local/lib/ltags $* | sort > tags where the file /usr/local/lib/ltags is /^\(DEF/ { print $2 " " FILENAME " ?^" $0 "$?" } /^\(def/ { print $2 " " FILENAME " ?^" $0 "$?" } From jkf Tue Oct 19 22:50:40 1982 Date: 19-Oct-82 22:50:29-PDT (Tue) From: jkf (John Foderaro) Subject: Lisp Opus 38.32, Liszt 8.14 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A03968; 19-Oct-82 22:50:40-PDT (Tue) To: local-lisp Status: RO Topic 1: liszt can now autoload macros. If liszt encounters a symbol without a function definition but with a macro-autoload indicator on the property list, then the value of the indicator is a file to load which should define the macro. The interpreter's undefined function handler will also look for macro-autoload properties, thus you needn't give a symbol both an autoload and a macro-autoload property. The default lisp contains macro-autoload properties for the macros defstruct, loop and defflavor. Topic 2: It is now possible to define 'compiler only macros' or cmacros. A cmacro acts like a normal macro, but will only be used by the compiler. A cmacro is stored on the property list of a symbol under the indicator 'cmacro'. Thus a function can have a normal definition and a cmacro definition. The macro 'defcmacro' has a syntax identical to 'defmacro' and creates cmacros instead of macros. For an example of the use of cmacros, see the definitions of nthcdr and nth in /usr/lib/lisp/common2.l Topic 3: If the form (foo ...) is macro expanded and the result also begins with the symbol foo, then liszt will stop macro expanding (previously it got into an infinite loop). Topic 4: The function nth has been added to Franz. (nth 'x_index 'l_list) returns the nth element of l_list, where the car of the list is accessed with (nth 0 'l_list) The macros (push 'g_value 'g_stack), and (pop 'g_stack ['g_into]) have been added to franz. typical uses (setq foo nil) (push 'xxx foo) (push 123 foo) now foo = (123 xxx) (pop foo) returns 123 now foo = (xxx) (pop foo yyy) returns xxx and sets yyy to xxx Topic 5: The version of Flavors written at Mit for Franz have been transported here. Flavors is a system for doing object oriented programming in lisp. The documentation for flavors in the Lisp Machine manual from Mit. Since Lisp Machine manuals are rather scarce around here, perhaps we can find someone to make copies of the flavor chapter for those interested in it. There is a description of the unique features of the Franz Flavors in /usr/lib/lisp/flavors.usage. As mentioned above, the flavors code will be autoloaded when you call 'defflavor' for the first time. Our local flavors expert is Eric Cooper (r.ecc). From jkf Fri Oct 22 15:46:51 1982 Date: 22-Oct-82 15:46:32-PDT (Fri) From: jkf (John Foderaro) Subject: lisp opus 38.34 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A05610; 22-Oct-82 15:46:51-PDT (Fri) To: local-lisp Status: RO Franz lisp now has a form of closure called an fclosure. A fclosure is a compromise between a funarg and the type of functional object that we currently have in Franz. In this short note, I'll explain through examples what fclosures are and where you might use them, and finally describe the new functions. The fclosure system was designed to be compatible with the Lisp Machine closures, so you may want to look at a Lisp Machine manual for more information. fclosure are related to closures in this way: (fclosure '(a b) 'foo) (let ((a a) (b b)) (closure '(a b) 'foo)) A example of the use of fclosures: ->(setq counter 0) 0 ->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter))))) fclosure[1] The function 'fclosure' creates a new type of object called a fclosure. A fclosure object contains a functional object, and a set of symbols and values for the symbols. In the above example, the fclosure functional object is (lambda (val) (setq counter (+ val counter))) and the set of symbols and values just contains the symbol 'counter' and zero, the value of counter when the fclosure was created. When a fclosure is funcall'ed: 1) the lisp system lambda binds the symbols in the fclosure to their values in the fclosure. 2) it continues the funcall on the functional object of the fclosure 3) finally it un-lambda binds the symbols in the fclosure and at the same time stores the current values of the symbols in the fclosure. To see what that means, let us continue the example: -> (funcall x 32) 32 -> (funcall x 21) 53 Notice that the fclosure is saving the value of the symbol 'counter'. Each time a fclosure is created, new space is allocated for saving the values of the symbols. If we executed the same fclosure function: ->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter))))) fclosure[1] We now have two independent counters: -> (funcall y 2) 2 -> (funcall y 12) 14 -> (funcall x 3) 56 To summarize: (fclosure 'l_vars 'g_funcobj) l_vars is a list of symbols (not containing nil) g_funcobj is lambda expression or a symbol or another fclosure examples: (fclosure '(foo bar baz) 'plus) (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #' which will make the compiler compile the lambda expression. There are time when you want to share variables between fclosures. This can be done if the fclosures are created at the time times using fclosure-list: (fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...]) This creates a list of closures such that if a symbol appears in l_varsN and l_varsM then its value will be shared between the closures associated with g_funcobjN and g_funcobjM. example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y)) '(c a) '(lambda () (setq c a)))) (fclosure[4] fclosure[7]) -> (funcall (car x) 123) ; set the value of a in the 1st fclosure 123 -> (funcall (cadr x)) ; read the same value in the 2nd fclosure 123 Other fclosure functions: (fclosure-alist 'c_fclosure) returns an assoc list giving the symbols and values in the fclosure (fclosurep 'g_obj) returns t iff g_obj is a fclosure (fclosure-function 'c_fclosure) returns the functional object of the fclosure Note: If a throw (or error) occurs during the evaluation of a fclosure, which passes control out of the fclosure, then current values of the symbols will not be stored. This may be a bug. We could set up an unwind-protect, but it would then take longer to funcall a fclosure. If you think an unwind protect is important, let me know. Note 2: you can also 'apply' a fclosure. From jkf Sat Oct 23 08:58:07 1982 Date: 23-Oct-82 08:57:53-PDT (Sat) From: jkf (John Foderaro) Subject: more on closures Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A21572; 23-Oct-82 08:58:07-PDT (Sat) To: local-lisp Status: RO I sent the maryland people the flavors.usage file from mit so that they could compare their implementation with mit's. What follows is their analysis. Some of the differences between the two versions is due to different schemes for getting around the fact that franz didn't have a form of closure. RZ has indicated that now that franz has fclosures, it may be possible to use more of the 'official' lisp machine flavor code. fclosures will probably affect the maryland implementation too: Date: 22 Oct 82 15:39:18 EDT (Fri) From: Liz Allen Subject: flavors To: jkf at Ucb-C70 Via: UMCP-CS; 23 Oct 82 9:09-EDT Wow, implementing closure in one day is amazing. We had thought about writing some kind of closure... We've been discussing how having closures would affect our code. It might make it easier to read and modify, but it might be less efficient. Can you tell us how your implementation works and what it looks like to a user? About the MIT implementation. Ours is probably better in a couple of respects but probably loses a couple of places, too. Pros: 1. With ours, there is no need to discard instances when redefining a flavor. The only time this would be necessary is if the instance variables change which rarely happens since methods change much more often than the instance variables. Without a structure editor, you tend to reload the file containing flavors in order to change a method. 2. We can compile files with flavors (he didn't say if you can compile MIT's Franz flavors) and when they are compiled they run *fast*. Most of the overhead occurs at combine time and compiled flavors shouldn't have to be recombined. 3. We use hunks to store instance variables (actually, an instance is a hunk whose cxr 0 is the name of the flavor and whose cxr n (> 0) are the values of instance variables). We pay a price at combine time since instance variable references in method code are replaced with cxr and rplacx calls (but MIT pays the same price in putting hash calls in the methods), but we win over MIT since the cxr calls are much faster than the hash table calls. We do have to have "ghost" methods which are copies of methods containing different cxr calls when the referenced variables of a method don't align in flavors which inherit the method. This, however, happens only rarely. 4. We handle getting and setting instance variables better than the MIT implementation -- we don't need to send a message and the syntax is much better. We recently added the functions > which get and set instance variables, eg: (> foo 'instance-var 'value) where foo is a flavor instance. 5. Our describe function has a hook which (if the variable *debugging-flavors* is set to non-nil) allows the user to follow pointers to any instances referenced in the describe. This is done by assigning to a variable (made from its unique id) the value of the instance. Cons: 1. They implement more things from Lisp Machine flavors (like wrappers/whoppers, init-keywords), but we really haven't found the need for them. We implement less closely to LM flavors, but in a way that's better suited to Franz Lisp. 2. We didn't implement the method table as a hash table, but there's no reason why we couldn't. 3. Things we don't have, but could easily implement include: describe-method, defun-method/declare-flavor-instance-variables, and storing flavor information in hunks instead of on the property lists. 4. We don't handle method types like :and and :or. We just have primary/untyped methods and :before and :after daemons. We have people reading our documentation. After we get some feedback from them, we'll send the tape and docs to you. That should be early next week. -Liz Allen and Randy Trigg From jkf Mon Oct 25 12:56:59 1982 Date: 25-Oct-82 12:55:44-PDT (Mon) From: jkf (John Foderaro) Subject: lisp Opus 38.35, liszt 8.15 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A17542; 25-Oct-82 12:56:59-PDT (Mon) To: local-lisp Status: RO New features: 1) tilde-expansion: franz will now expand filenames which begin with ~ just like csh does. It will only do the expansion if the symbol tilde-expansion has a non-nil value. The default value for tilde-expansion is t. These functions do tilde expansion: If I've left any out, let me know: load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir sys:access, sys:unlink [these are new functions, see below] 2) liszt will remove its temporary file if given a SIGTERM signal (SIGTERM is sent by default when you give the kill command from the shell) 3) load will now print a helpful message if an read error occurs when it is reading a file. 4) new functions: (lexpr-funcall 'function 'arg1 ... 'argn) This is a cross between funcall and apply. The last argument, argn, must be a list (possibly empty). The element of list argn are stacked and then the function is funcalled. For example: (lexpr-funcall 'list 'a 'b 'c '(d e f)) is the same as (funcall 'list 'a 'b 'c 'd 'e 'f) Also (lexpr-funcall 'list 'a 'b 'c nil) is the same as (funcall 'list 'a 'b 'c) (tilde-expand 'st_filename) returns: symbol whose pname is the filename, with a leading tilde expanded. if st_filename doesn't begin with a tilde, it just returns st_filename (username-to-dir 'st_name) returns: the home directory of the given user, if that user exists. Saves old information so doesn't have to keep searching the passwd file. Some low level system functions. These are listed here for completeness. The perform a function from the unix library (see the unix manual for details). (sys:getpwnam 'st_username) return passwd file info. (sys:access 'st_file 'x_mode) (sys:unlink 'st_file) Bug fixes: 1) patom will handle prinlevel and prinlength correctly. 2) it is now safe for an interpreted function to redefine itself. 3) the information return by 'evalframe' about a funcall'ed function is now correct. From jkf Mon Oct 25 14:57:00 1982 Date: 25-Oct-82 14:56:25-PDT (Mon) From: jkf (John Foderaro) Subject: 'if' macro: request for comments Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A21567; 25-Oct-82 14:57:00-PDT (Mon) To: local-lisp Status: RO Would anyone object if we added a macro called 'if' to the default franz system? 'if' is a common name and I want to make sure that it doesn't break any existing code before I add it. Some background: At mit the 'if' macro is used all over the place. Its form is (if [ ]) I've always felt that macros should make the code more readable and that the 'if' macro makes code more obscure because it isn't easy to tell in complicated 'if' expressions where the and 's begin. Also, there is no provision for an 'elseif' expression. I wrote a macro called 'If' which uses keywords to separate clauses. (If then [elseif then ]* [else ]) These two macros are not incompatible. one macro could do the job of both. There is an ambigous case: (if p then x) could be (cond (p then) (t x)) or (cond (p x)) but it isn't likely that 'if' macro users would write something like that. Thus I propose that we add a macro, if, which act's like 'If' if its second arg is 'then' or like 'if' it the second arg is not 'then' and there are two or three arguments. Other cases would cause an error. From jkf Mon Oct 25 22:37:24 1982 Date: 25-Oct-82 22:37:09-PDT (Mon) From: jkf (John Foderaro) Subject: opus 38.36 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A01666; 25-Oct-82 22:37:24-PDT (Mon) To: local-lisp Status: RO I've added the 'if' macro to franz. If you have any objections, it is still not too late to voice them. I've also defined 'If' to be the same as 'if'. As I mentioned in my earlier request for comments, the 'if' macro is a cross between the mit version and a locally written version using keywords. The following documentation describes the various forms. As you know, you can test out the 'if' macro by using apply. for example: => (apply 'if '(if a then b c elseif d thenret else e)) (cond (a b c) (d) (t e)) ; ; This macro is compatible with both the crufty mit-version and ; the keyword version at ucb. ; ; simple summary: ; non-keyword use: ; (if a b) ==> (cond (a b)) ; (if a b c d e ...) ==> (cond (a b) (t c d e ...)) ; with keywords: ; (if a then b) ==> (cond (a b)) ; (if a thenret) ==> (cond (a)) ; (if a then b c d e) ==> (cond (a b c d e)) ; (if a then b c else d) ==> (cond (a b c) (t d)) ; (if a then b c elseif d thenret else g) ; ==> (cond (a b c) (d) (t g)) ; ; ; ; ; In the syntax description below, ; optional parts are surrounded by [ and ], ; + means one or more instances. ; | means 'or' ; is an lisp expression which isn't a keyword ; The keywords are: then, thenret, else, elseif. ; is also a lisp expression which isn't a keyword. ; ; ::= ; | ; ; ::= (if ) ; | (if ) ; ; ::= (if [ ] ) ; ; ::= then + ; | thenret ; ; ::= else + ; | elseif [ ] From jkf Tue Oct 26 09:20:25 1982 Date: 26-Oct-82 09:20:04-PDT (Tue) From: jkf (John Foderaro) Subject: no more jkfmacs Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A11552; 26-Oct-82 09:20:25-PDT (Tue) To: local-lisp Status: RO Since Franz now has the push, pop, if and msg macros, there is no reason for jkfmacs to exist. I've removed the code in jkfmacs and replaced it with a warning message which will be printed if you load it. If you used the jkfmacs version of 'push' you will have to go through your code and switch the order of arguments. The Franz version is (push value stack) Also, the unpush macro, defined in jkfmacs, no longer exists: just use pop with one argument. From jkf Wed Oct 27 20:35:07 1982 Date: 27-Oct-82 20:34:25-PDT (Wed) From: jkf (John Foderaro) Subject: liszt 8.16 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A27561; 27-Oct-82 20:35:07-PDT (Wed) To: local-lisp Status: RO Back on May 6, a modification to liszt was made which turned 'declare' into a user callable function which provided information to the compiler. The purpose of the change was to permit one to 'load' a file containing declarations, instead of 'include'ing it. It turns out that this was a bad idea since if the compiler were to evaluate an interpreted function with local declarations, it would assume that those local declarations were describing the current file being compiled. Thus declare has it old meaning: it is a no-op unless the compiler is compiling the form. If one really wants to actively declare something, we've added the function 'liszt-declare', which looks just like declare but can be evaluated within the compiler. If you are confused by all this, don't worry. There is very little chance that it will affect you. From jkf Fri Oct 29 09:34:11 1982 Date: 29-Oct-82 09:33:59-PDT (Fri) From: jkf (John Foderaro) Subject: cmacros Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A08411; 29-Oct-82 09:34:11-PDT (Fri) To: local-lisp Status: RO A week ago, Joe Faletti mentioned that one problem with cmacros is that if you redefine a function, the cmacro property stays around and thus the redefinition of the function isn't communicate to the compiler. He suggested that whenever a function is defined (via 'def' or when fasl'ed in) any cmacro properties should be remprop'ed. I've been trying to think of an alternative to this, but I can't think of one. Unless someone has a better idea, I'll implement his suggestion. This means that if you want to define the function 'foo' and a cmacro for 'foo', the cmacro definition must appear later in the file than 'foo's definition. From jkf Fri Oct 29 10:11:36 1982 Date: 29-Oct-82 10:10:54-PDT (Fri) From: jkf (John Foderaro) Subject: LetS: An Expressional Loop Notation Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A09176; 29-Oct-82 10:11:36-PDT (Fri) To: local-lisp Status: RO I've got a copy of a paper by Richard Waters (at mit) describing a system for writing loops in lisp (and other languages). Basically you describe the loop in functional programming terms (similar to Backus's FP, or apl) and the LetS package converts it into an iterative form for efficient execution in lisp. We don't have the LetS code here to play with, and we probably won't be able to get it for a while since our arpanet connection is hopelessly clogged for anything but tiny messages. However you might be interested in stopping by my office and looking at the paper. From jkf Fri Oct 29 12:06:47 1982 Date: 29-Oct-82 12:06:08-PDT (Fri) From: jkf (John Foderaro) Subject: Re: cmacros Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A12141; 29-Oct-82 12:06:47-PDT (Fri) To: baden, local-lisp In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday) Status: RO I could make it a 'Note'. I would prefer not to make it a warning because such redefinition is guaranteed to occur when the compiler compiles itself and the lisp code part of the lisp system. From fateman Sat Oct 30 09:17:49 1982 To: franz-friends Subject: fugue # 2 Status: RO FUGUE Notes An occasional publication of the Franz Lisp User Group under Unix and Eunice (FUGUE) Number 2 (October, 1982) edited by Richard J. Fateman University of California Berkeley CA 94720 USA fateman@berkeley 1. Welcome! It seems about time to publish the second of these newsletters, since we have accumulated a number of new items. We would also like to relay to others such informa- tion as has been forwarded to us. The reports of projects at Berkeley (and elsewhere) may strike sympathetic chords with other research. 2. New programs 2.1. OPS-5 OPS-5 is a "production system" written by Charles Forgy of CMU. It appears to work just fine in Franz, and is in wide use. Interested persons may obtain copies of documen- tation and the program from Charles.Forgy@CMU-10A. ( Charles Forgy, Computer Science Department, Carnegie-Mellon Univer- sity, Pittsburgh, PA 15213) It is their policy to send it to anyone who wants it free of charge. 2.2. GLISP GLISP is a system which provides interesting linguistic features for generic operations and data abstraction. Writ- ten by Gordon Novak at Stanford University, it was origi- nally developed for Interlisp, but has been ported to other lisps, including Franz. 2.3. Flavors There are now two distinct implementations, apparently with identical functionally, of "flavors" as appearing in the MIT Lisp Machine software. One is described in TR-1174, ____________________ 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, SRI Int'l, and Univ. of Calif. 9 "Franz Flavors" by Richard J. Wood (Dept of C.S., Univ. of Maryland, College Pk, MD 20742). The other was written by Juan R. Loaiza of MIT, Laboratory for Computer Science. We have a copy of the latter on-line here, and expect to receive a copy of the Maryland one, shortly. Eric Cooper here at Berkeley is in charge of the flavors situation. There is an implementation of closures, mostly compati- ble with the Lisp Machine specification, announced by John Foderaro for Opus 38.33. The incompatibility is a result of what we perceive to be a high performance penalty for eso- terica. 2.4. Database Interfaces Jim Larus at UCB has cooked up interfaces to both the INGRES relational database system, and the simpler TROLL database system. These will be described in his forthcoming MS report, along with the next item. 2.5. Cursor-control and Menus Larus has provided an implementation of screen manage- ment which uses the UNIX "curses" package for primitive win- dow management. A menu-based interface has also been developed as part of this. 2.6. Vaxima and Algebraic Manipulation A new version of vaxima, the VAX version of the MACSYMA algebraic manipulation system, was released in July by UCB, incorporating some bug fixes, improved programs, and a large number of user-contributed subroutine libraries. This was made available to test-site licensees. Unfortunately, MIT has suspended new test-site licensing since about April, 1982. We hope that MIT will be liberalizing its distribu- tion policy to non-commercial sites. See the note below about MACSYMA being sold. As a counterpoint to this, UC Berkeley has received a substantial grant from the System Development Foundation for work on Mathematical Representation and Manipulation, which should result in some more advanced systems for application of computers to symbolic mathematics. Recruiting for researchers, staff, and students is underway now, and interested persons should contact Richard Fateman. 2.7. VLSI Design Rule Checker Lyra, written in Lisp by Michael Arnold, is a retarget- able, hierarchical, design rule checker for VLSI circuits. Lyra features a rule compiler (also written in Lisp of course!) which translates symbolic design rule descriptions to lisp code for checking the rules. Lyra was used for the RISC project. It is currently being used extensively at Berkeley, and will be included in the Fall-82 distribution of of the Berkeley CAD tools. For more information contact Michael Arnold or John Ousterhout at Berkeley. 2.8. Generic Arithmetic As a proposed extension to Franz arithmetic, Richard Fateman, Keith Sklower and Scott Morrison, have written a simple-minded generic arithmetic package which includes modules which can be loaded to support exact rational arith- metic, software-simulated IEEE extended arithmetic, arbi- trary precision floating point, complex, interval, and mul- tivariate polynomial. Combinations of some of these are sup- ported, although the package is as yet incomplete in some areas. The IEEE arithmetic simulation is written in C. These packages are probably not in good enough shape for casual use by others. 3. New features Various performance enhancements and bug fixes have been incorporated in versions of Franz (now on Opus 38.33 and the compiler, Liszt 8.14) These are mentioned in brief here; more details accompany updates of the system and manual included in the forthcoming Berkeley 4.2BSD UNIX dis- tribution. 3.1. Franz We added a switch to cause the evaluator to save macro expansions so they need only be expanded once. We added vector and vector-immediate data types. We rewrote showstack and backtrace so they are easier to use. We made the lisp to foreign function interface more secure. The system now allows foreign function to call lisp functions. We added closures and support flavors, features from the Lisp Machine. 3.2. Liszt Liszt will check the number of arguments to system functions and user defined functions. 9 9 Liszt supports local declarations. Liszt will automatically compile lambda expressions headed by the function `function'. Liszt supports compiler-only macros and will autoload macros if necessary. 4. MC68000 Keith Sklower and Kevin Layer have been working on the MC68000 version of Franz under the UNIX operating system (using a DUAL System 83). While the current configuration is a swapping system, the Lisp should be able to use the full address space of the CPU. We expect to have this system run- ning on the UNIX 4.2 BSD SUN software, too. The base system on the DUAL, including the interpreter, reader, bignums, fasl, works; the compiler is being perfected. 5. Other Lisps We now have, in-house tried 4 (other) VAX UNIX lisp systems: YLISP, Interlisp, PSL, and VLISP. We know that Interlisp can run also on VMS using the Eunice package. Interested parties can contact David Dyer at USC-ISI. There is also a version of lisp which runs on VMS only, namely NIL, from MIT, which appears to be undergoing limited dis- tribution. Two other lisps under development under UNIX are Yale's answer to NIL, namely "T", and Common Lisp, from CMU and friends. Counting Franz, that makes 7 lisp systems for the VAX computer line. Not counting variants on 2 operating systems. A Paen to standardization. Dick Gabriel states some useful principles for com- parisons in the conference record of the 1982 ACM Lisp and Functional Programming Conference, which was held in August. We understand he now has a collection of some 18 programs which he is continuing to time on various systems. 6. Work in Progress 6.1. BITGRAPH SUN AED-512 Greg Foster at UCB is working on raster-graphics sup- port in Franz for the 800 by 1000 b/w raster displays of the BBN Bitgraph and/or the SUN Workstation, and possibly the color 512 by 512 AED system. We are probably going to han- dle mice and Bitpad (stylus) input for pointing. There are lots of projects we hear about with similar systems, e.g. just recently from the University of Maryland, using UNIX and multiplexed files for window management of a 68000-based home-grown workstation. 6.2. RISC-LISP Yes, Reduced Instruction Set Computer fans, who else but UCB would be so bold... Carl Ponder is examining the issues involved in constructing a fast lisp interpreter and compiler for the RISC architecture. You see, we have all these chips... 7. Work Contemplated 7.1. Fast Number Compiler Undergraduate Jeff Cohen at Berkeley is starting to look at this. There are several industrial concerns that have expressed interest in using such a system, but expected it to be subsidized by someone else. 7.2. IBM Franz Even more nibbles on this one, but not yet. 8. Business News 8.1. Eunice SOLD Some of you may have heard that the Eunice software package was sold by SRI to the Wollongong Group, a UNIX sup- port group in Palo Alto. Prices range from $2k (educa- tional) to $5k (commercial). Naturally this package is of interest beyond the availability of Franz Lisp. We have not compared this product to other similar ones, but we know that TWG has been distributing a working Franz opus 38. As far as alternatives to Eunice, we are aware of a system developed at Rice University, and another by Human Computing Resources (HCR) in Toronto. We have not evaluated either of these. 8.2. MACSYMA SOLD MIT has sold exclusive rights to MACSYMA, a large alge- braic manipulation system, to Symbolics, Inc. of Cambridge Mass. This package runs in Franz Lisp, (among other Lisps) We hope that soon it will again be available to educational institutions with VAX systems either from us or Symbolics, at a nominal charge. We understand that commercial licenses (from Symbolics) for versions of MACSYMA on PDP-10s, Lisp Machines, etc. will distributed at non-nominal prices and offered with maintenance contracts. From liz.umcp-cs@UDel-Relay Mon Nov 1 17:43:52 1982 Date: 29 Oct 82 12:04:24 EDT (Fri) From: Liz Allen Subject: Re: Flavor system To: ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc Cc: randy.umcp-cs at UDel-Relay In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley Via: UMCP-CS; 30 Oct 82 5:40-EDT Status: RO Date: 25 October 1982 16:29-EDT From: ECC@MIT-MC@Berkeley Subject: Flavor system To: FRANZ-FRIENDS at MIT-MC Can someone give me a pointer to the Franz flavor system developed by U. Maryland? I am looking for information on how to FTP the files -- what machine, whether public, what files, etc. Since the U. of Maryland is not (yet) an Arpanet host, you can't FTP files directly from here. We are right now completing some documentation for all of our hacks -- including documentation for some recent improvements for our flavors system. When that documentation is complete, we will be ready to distribute the packages developed here. Besides flavors, this includes a top level called userexec which is based on INTERLISP's top level and a production system called YAPS similar to but more flexible than OPS5. We are supposed to become an Arpanet host in a few months... (Read open ended period of time.) Meanwhile, if you would like to get our code, mail me a tape, and I will mail it back with the code and documentation on it. I'd appreciate it if someone would volunteer to let other folks FTP the files from their machine until we do become an Arpanet host. My address is: Liz Allen Univ of Maryland Dept of Computer Science College Park MD 20783 (301) 454-4247 liz.umcp-cs@udel-relay -Liz From jkf Wed Nov 3 15:49:29 1982 Date: 3-Nov-82 15:48:50-PST (Wed) From: jkf (John Foderaro) Subject: lisp opus 38.40 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A16460; 3-Nov-82 15:49:29-PST (Wed) To: local-lisp Status: RO putprop will now put new properties at the head of the property list. From ecc@UCBARPA Thu Nov 4 10:28:49 1982 Date: 4-Nov-82 10:19:26-PST (Thu) From: ecc@UCBARPA (Eric C. Cooper) Subject: Lisp song Message-Id: Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82]) id A24537; 4-Nov-82 10:19:28-PST (Thu) Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A00305; 4-Nov-82 10:28:49-PST (Thu) To: local-lisp@kim Status: O [This has been forwarded from uucp through Xerox through info-lispm.] >From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982 Another Glitch in the Call ------- ------ -- --- ---- (Sung to the tune of a recent Pink Floyd song.) We don't need no indirection We don't need no flow control No data typing or declarations Hey! Did you leave the lists alone? Chorus: All in all, it's just a pure-LISP function call. We don't need no side effect-ing We don't need no scope control No global variables for execution Hey! Did you leave those args alone? (Chorus) We don't need no allocation We don't need no special nodes No dark bit-flipping in the functions Hey! Did you leave the bits alone? (Chorus) We don't need no compilation We don't need no load control No link edit for external bindings Hey! Did you leave that source alone? (Chorus, and repeat) From jkf Sat Nov 13 20:53:41 1982 Date: 13-Nov-82 20:53:16-PST (Sat) From: jkf (John Foderaro) Subject: lisp opus 38.41 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A00490; 13-Nov-82 20:53:41-PST (Sat) To: local-lisp Status: O added functions: (remq 'g_val 'l_list) - just like remove but uses eq instead of equal (command-line-args) - returns a list of the command line arguments when lisp was started. This function will return only those arguments typed by the user, even if the lisp was started with the autorun feature (liszt -r). (sys:gethostname) - returns the name of the machine. (status domain) - returns 'ucb' here. From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982 Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST Date: 28 Nov 1982 11:47:28-EST From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A Subject: (random) problems Status: RO I am having two problems using (random) in Franz lisp. The first problem is that I can't find any way to set the seed. Every time I enter lisp, the generator is in the same state. I have had to resort to cfasling a c procedure that calls srand() (as (random) seems to be defined in c by a call on rand()). Is there a way to do this within lisp? The other problem is more serious. The generator seems to generate tight cycles for (at least) arguments that are small powers of 2. For example, repeatedly executing (random 2) yields the sequence 01010101..., and (random 4) yields 01230123.... These sequences apparently occur no matter to what value I set the seed. Does anyone one know what I could be doing wrong, or have a working random number generator? From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982 Status: O From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982 Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng To: franz-friends at Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST Status: O To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay From jkf Tue Nov 30 09:21:10 1982 Date: 30-Nov-82 09:21:10-PST (Tue) From: jkf (John Foderaro) Subject: opus 38.42 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA11699; 30-Nov-82 09:21:10-PST (Tue) To: local-lisp Status: O added: (sys:link 'oldname 'newname) that what the ln program does. changed: the order of arguments to the vset functions is now: (vset 'vector 'index 'value). [This shouldn't affect anyone since vectors haven't been officially released yet and won't be until I make one more major modification] setf now knows about vectors. You can say (setf (vref 'vector 'index) 'value) and not have to worry about the order of arguments to vset. From jkf Tue Nov 30 10:42:00 1982 Date: 30-Nov-82 10:42:00-PST (Tue) From: jkf (John Foderaro) Subject: Re: opus 38.42 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA13143; 30-Nov-82 10:42:00-PST (Tue) To: jeffc, local-lisp In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday) Status: O It can't do symbolic links (I've only been adding system calls that I had a use for). setf is a generalized setq. The target can be an expression which locates a value. setf figures out how to store in the target. for example: (setf x 3) == (setq x 3) (setf (car x) 3) == (rplaca x 3) (setf (get foo 'bar) 3) == (putprop foo 3 'bar) the target must be something it has been 'taught' to understand, or it can be a macro, in which case setf macro-expands it and takes another look. The setf macro (and a list of targets it knows about is in /usr/lib/lisp/common2.l) From jkf@UCBKIM Wed Dec 1 09:13:23 1982 Date: 1-Dec-82 09:13:03-PST (Wed) From: jkf@UCBKIM (John Foderaro) Subject: Random Numbers in Franz Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA03615; 1-Dec-82 09:13:03-PST (Wed) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A18406; 1-Dec-82 09:13:23-PST (Wed) To: franz-friends@berkeley Status: RO Date: 29-Nov-82 15:56:09-PST (Mon) From: alice!sola!mitch Subject: Random Numbers in Franz To: alice!ucbvax!franz-friends In general, it is very bad practice to compute a random number between 0 and n by any expression such as (mod (random) n). In fact, Franz's random function does exactly that, returning the number generated by the C function rand(3) modulo n. This technique uses only the rightmost bits of successive calls to rand, and the righmost n bits of congruential sequences (like that returned by rand(3)) have a period of AT MOST 2**n (See Knuth vol.2 p. 12). So using the rightmost two bits will indeed give you sequences of at most period 4. (If your lisp doesn't have this behavior, you're not using the standard rand.) A better way to do it is to use the high order bits, by dividing the entire range up into n pieces and then seeing where you fall. (This method is biased if n is of the same order as the range, though.) The code I use is: (or (getd '$old-random) (putd '$old-random (getd 'random))) (defun random n (cond ((eq n 0) ($old-random)) ((fix (quotient (boole 1 ($old-random) #o 7777777777) (quotient #o 7777777777 (arg 1))))))) Mitch Marcus From jkf Thu Dec 2 08:04:37 1982 Date: 2-Dec-82 08:04:37-PST (Thu) From: jkf (John Foderaro) Subject: Franz Lisp distribution Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA14414; 2-Dec-82 08:04:37-PST (Thu) To: franz-friends, net-lang-lisp@k Status: O Franz Lisp Distribution This note describes our distribution policy for Franz Lisp. What is being distributed: We distribute only source code in order to keep the distribution small and relatively Unix independent. Makefiles are provided to build the entire lisp system from source, even if you don't have a version of lisp running already. This process takes about 3 cpu hours on a Vax 780. [This version for the Vax only, a 68000 version is being worked on. Contact ucbkim.sklower@berkeley or ucbkim.layer@berkeley] The following source is provided: lisp interpreter, compiler (liszt), cross reference program (lxref), lisp manual, and other utility programs: trace, step, debug, cmu library functions, (and other minor ones), and these packages from the MIT lisp library: defstruct, loop, flavors. [These programs are provided as a convenience to those who can't access the arpanet and copy them. There is no documentation for them in the Franz Lisp manual. The best source of documentation is the Lisp Machine manual (available from MIT, Symbolics or LMI)] Regarding Flavors: there are two implementations of flavors for Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc)) and one from the University of Maryland (contact person Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is exactly like flavors on the Lisp Machine (due to differences between Lisp Machine lisp and Franz Lisp), and the implementations differ from each other. We incorporated the Mit version into the standard distribution because the high bandwidth between here and MIT will insure that it keeps up to date with the current Franz. This is not to imply that it is the better implementation. We haven't had enough experience with flavors to judge. Those seriously interested in Flavors should contact Liz Allen and ask for the Tech Report on the Univ Of Maryland Flavors system. What is the form of the distribution: The files are packaged in a giant (2.1Mbyte) shell script. Running this shell script through 'sh' will result in a directory tree. A ReadMe file in the current directory will contain instructions on building the lisp system. The shell script is broken into a number of smaller files. The current distribution looks like: % ls total 2092 195 opus38.40.aa 195 opus38.40.ae 195 opus38.40.ai 195 opus38.40.ab 195 opus38.40.af 195 opus38.40.aj 195 opus38.40.ac 195 opus38.40.ag 142 opus38.40.ak 195 opus38.40.ad 195 opus38.40.ah The '38.40' means Opus 38, minor version 40. These numbers may be different by the time you get your distribution. In order to extract the lisp files from this shell script, you need only type: cat * | sh To get a copy of the distribution: The distribution may be obtained either using FTP from an arpanet site, or on a magnetic tape through the U.S Mail. Arpanet: The files are stored on the ucb-c70 (NCP) arpanet host in the directory /users/lisp/lispuser. If you have an account on the ucb-c70, you are free to take FTP a copy of these files. If you do not have an account on the ucb-c70, send me (jkf@berkeley) a message and I will set up a temporary account for you. If you are on a TCP host, write me and we will set up an account on one of our Vax's for you to FTP the files. Eventually we will have an anonymous login on a TCP machine. Mag Tape: In order to get a copy of the distribution mailed to you, send a check to cover our tape copying and mailing costs (fees are listed below). We will purchase the mag tape and you are free to keep it. Please do NOT send us a tape. Fees: $50 - distribution tape mailed 3rd class add $10 - a copy of the Lisp Manual (we will only send one copy, you are free to photocopy it) add $7 - send tape via 1st class mail. -or- $15 - for just a copy of the Lisp Manual The address to send checks to is Keith Sklower EECS/Computer Science Division 524 Evans Hall University of California Berkeley, CA 94720 All checks should be made out to "Regents, University of California." We require pre-payment. We will not invoice or process purchase orders. Disclaimers: This distribution works on the latest versions of Unix running at Berkeley (4.1a). We can't guarantee that it will work on older versions (although, if you are running 4.1, it is almost certain that it will work, but we have not verified it). VMS users who are using a typical Unix compatibility package will probably not be able to build a lisp from this distribution unless they know a great deal about VMS and their compatibility package. At least one package (Eunice) supports Franz at this time. Redistribution: If you get a copy of the distribution, you are free to give it to other people. We appreciate being informed of new sites so they can be put on a mailing list (electronic and conventional). This list is used to announce new releases. To be put on this list, send U.S. Mail to Keith Sklower (address above) or to franz-friends-request@berkeley or ucbvax!franz-friends-request From jkf Mon Dec 6 08:50:45 1982 Date: 6-Dec-82 08:50:45-PST (Mon) From: jkf (John Foderaro) Subject: opus 38.43 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA12951; 6-Dec-82 08:50:45-PST (Mon) To: local-lisp Status: O The size of vectors is now recorded in bytes rather than longwords. We've imported a few more commands to deal with fclosures. (symeval-in-fclosure 'fclosure 'symbol) (set-in-fclosure 'fclosure 'symbol 'value) (let-fclosed vars function) From jkf Mon Dec 13 10:35:43 1982 Date: 13-Dec-82 10:35:43-PST (Mon) From: jkf (John Foderaro) Subject: enhancemants to trace Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA12160; 13-Dec-82 10:35:43-PST (Mon) To: local-lisp Status: O The function 'retrace' will insure that all functions which should be traced are indeed traced. This will solve the problem of reloading a file whose functions are traced. After you load a file, you can type (retrace) and those functions which became untraced during the loading process, will be traced again. The top-level-print and top-level-read variables will now take effect within a trace break. From jkf Tue Dec 14 12:40:41 1982 Date: 14-Dec-82 12:40:41-PST (Tue) From: jkf (John Foderaro) Subject: Re: #!, exec and lisp Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA10379; 14-Dec-82 12:40:41-PST (Tue) To: lime!burdvax!puder Cc: franz-friends In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon) Status: O It is easy to make #! do a zapline. If you have a recent version of lisp, just execute: (defsharp ! (x) (zapline)) (this could be put in your .lisprc, if you don't want to affect other people). The problem with adding this to Franz by default is that the sharpsign macro is shared by a number of lisps and few of them run under Unix. Therefore, few other lisps are going to want #! to be zapline. Regarding the -f switch: The -f switch is used to communicate between the bootstrap at the beginning of a fasl file and the lisp interpreter. It wasn't meant as a general 'fasl this file' switch for users to make use of. The choice of '-f' was bad, it should have been something more unique like '-- autorun' so that a user would be unlikely to type it. We have avoided assigning meanings to switches on lisp's command line because we want to give each user the opportunity to assign whatever meaning he wants to whatever switch he wants. It isn't difficult to write a program to scan the command line. Re: The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be necessary, because the exec syscall supplies the full path name, because the shell has already done the path searching on the command name. The only place that might have to be searched is the current directory. This isn't true. (argv 0) is the command that you typed, not the full path name to the command. Only by prepending all the directories in the search list can you find the location of the command. ---john foderaro From jkf Mon Jan 10 15:04:02 1983 Date: 10-Jan-83 15:04:02-PST (Mon) From: jkf (John Foderaro) Subject: opus 38.45 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA19240; 10-Jan-83 15:04:02-PST (Mon) To: local-lisp Status: O showstack will again report correctly for compiled calls if the transfer tables are unlinked (status translink nil). From jkf Mon Jan 10 19:46:06 1983 Date: 10-Jan-83 19:46:06-PST (Mon) From: jkf (John Foderaro) Subject: opus 38.46 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA24831; 10-Jan-83 19:46:06-PST (Mon) To: local-lisp Status: O This version incorporates some fixes from mit. You shouldn't notice any differences but if you do, let me know. From jkf Wed Jan 12 09:03:32 1983 Date: 12-Jan-83 09:03:32-PST (Wed) From: jkf (John Foderaro) Subject: opus38.47 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA01981; 12-Jan-83 09:03:32-PST (Wed) To: local-lisp Status: O The setf macro will now handle all car and cdr forms (i.e. c{ad}+r). Thanks to peter norvig for this. There is a new macro called 'defvar'. It is used to declare special variables and optionally to give them an initial value. It is used at top level in a file (outside of defuns). forms: (defvar foo) ; declares foo to be special (defvar bar 3) ; declares bar to be special and when this file is read in ; bar will be given the value 3 if it is unbound. An advantage of '(defvar foo)' over '(declare (special foo))' is that if a file containing defvars is loaded (or fasl'ed) in during compilation, the variables mentioned in the defvar's will be declared special. The only way to have that effect with '(declare (special foo))' is to 'include' the file. There is a new macro, 'environment', which can be used at the beginning of a file to specify what sort of environment this file needs in order to be compiled or run. For example: (environment (compile eval) (files mymacros othermacros) (compile) (syntax maclisp)) says that when compiling or loading into the interpreter, the files mymacros and othermacros should be loaded (if they aren't loaded already). When compiling, the maclisp syntax should be used. The general form of 'environment' is: (environment when1 what1 when2 what2 ... ... whenN whatN) the when's are a subset of (eval compile load), and the symbols have the same meaning as they do in 'eval-when'. The what's are either (files file1 file2 ... fileN) insure that the named files are loaded. To see if fileX is loaded, it looks for a 'version' property under fileX's property list. Thus to prevent multiple loading, you should put (putprop 'myfile t 'version) at the end of myfile.l (syntax type) type is either maclisp, intlisp, ucilisp, franzlisp This sets the syntax correctly. There are additional macros to set of standard environments: (environment-maclisp) sets up the maclisp environment. This is what you would get by using the -m switch to liszt. (environment-lmlisp) sets up the lisp machine environment. This is like maclisp but it has additional macros. It is possible to add when's and what's to the specialized environments, e.g. (environment-maclisp (compile eval) (files foo bar)) From norvig Wed Jan 12 13:12:45 1983 To: jkf local-lisp Subject: defvar Status: O Shouldn't defvar take any number of arguments, like setq? As it is, (defvar a 1 b 2) sets a to 1, but ignores the other arguments. From fateman Wed Jan 12 13:23:08 1983 To: jkf local-lisp norvig Subject: Re: defvar Status: O I suspect the extra arguments to defvar are used in other systems for storage of documentation strings in appropriate places. E.g. (defvar dozen 12 "initially 12 except in the baker system when it is 13") causes some association with defvar and documentation should be put on a file. From jkf Wed Jan 12 14:25:02 1983 Date: 12-Jan-83 14:25:02-PST (Wed) From: jkf (John Foderaro) Subject: Re: defvar Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA13079; 12-Jan-83 14:25:02-PST (Wed) To: norvig, local-lisp In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday) Status: O fateman is correct that there is an optional third argument for documentation. We don't want to add multiple arguments because defvar it will mean that code we write here can't be transported to other lisp which only expect one defvar argument. From jkf Thu Jan 13 09:49:13 1983 Date: 13-Jan-83 09:49:13-PST (Thu) From: jkf (John Foderaro) Subject: liszt 8.17 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00331; 13-Jan-83 09:49:13-PST (Thu) To: local-lisp Status: O The vector reference functions are open coded. These are vref, vrefi-byte, vrefi-word, vrefi-long From G:alpines Thu Jan 13 20:31:34 1983 Date: 13 Jan 1983 20:24-PST From: alpines@G (Harry Weeks at Vax-Populi) Subject: Franz on 68000's Message-Id: Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83]) id AA12970; 13-Jan-83 20:28:37-PST (Thu) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA14908; 13-Jan-83 20:31:34-PST (Thu) To: franz@BERKELEY Cc: franz-friends@BERKELEY Status: O >Date: 13 Jan 1983 20:01-PST From: G.alpines at Berkeley (Harry Weeks at Vax-Populi) Subject: Franz on 68000's. To: franz-friends-request@Berkeley Message-Id: Please put me on your mailing list for information concerning implementation of Franz, esp. on 68000's, but I'd like to keep informed generally as well. Thanks. Harry Weeks Bytek 1730 Solano Avenue Berkeley, CA 94707 (415) 527-1157 From jkf Sun Jan 16 21:22:54 1983 Date: 16-Jan-83 21:22:54-PST (Sun) From: jkf (John Foderaro) Subject: change to lisptags program Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA23656; 16-Jan-83 21:22:54-PST (Sun) To: local-lisp Status: O lisptags will now surround the search string with /'s instead of ?'s in order to be compatible with ctags. Both types should work with vi, emacs people will probably have to make a minor modification to their tags.ml file. My version in ~jkf/elib/tags.ml. From jkf Tue Jan 18 16:43:23 1983 Date: 18-Jan-83 16:43:23-PST (Tue) From: jkf (John Foderaro) Subject: lisp opus 38.48, liszt 8.19 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA10935; 18-Jan-83 16:43:23-PST (Tue) To: local-lisp Status: O This is a long message so I'll put the most important thing first, in case you choose not to read the rest of the message: *** object files generated by liszt 8.19 will not run in any lisp *** older than 38.48. Object files which were generated by *** liszt's before 8.19 will continue to work in the new lisp. There were two major changes to lisp and liszt: 1) compiled functions will test at runtime to make sure that they are passed the correct number of arguments. 2) the lambda list keywords &optional, &rest and &aux are open compiled in an efficient manner. I'll refresh your memory on what the possible forms are for the & keywords: the formal parameter list of a def has this form ( required-args [ &optional optional-arguments ] [ &rest rest-argument ] [ &aux aux-arguments ]) as in this example which shows all possible forms: (def foo (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g) (compute))) the meaning and forms of the various parts of the formal parameter list are: required-args: a sequence of n (zero or more) symbols which will be bound to the first n actual arguments. optional-args: a sequence of m (zero or more) symbols which will be bound to the next m actual arguments if they are present, or to default values. the forms of an optional argument are: foo - bind foo to the argument if it present, otherwise bind it to nil (foo (expr)) - bind foo to the argument if it is present, otherwise evaluate (expr) and bind foo to the result. (foo (expr) foo-p) - bind foo to the argument if it is present, otherwise evaluate (expr) and bind foo to the result. Also, bind foo-p to t if the argument is present, otherwise bind foo-p to nil. foo-p will be treated like an &aux variable (see below) but it should NOT be declared in the &aux list! rest-arg : a single symbol which will be bound to a list of the rest of the arguments. This list is cons'ed up each time the function is called. aux-args : these args are just like arguments to let or prog within the function body so this & keyword isn't really necessary (but there are few things in lisp that really are necessary). the forms of the aux arg are: foo - bind foo to nil (foo (expr)) - evaluate (expr) and bind foo to the result. The compiler understands the &keywords but the interpreter does not. 'def' will convert a form with &keywords to a lexpr which is almost equivalent. The differences are: The interpreted form, being a lexpr, is allowed to use the 'arg' function. The compiled form, even with optional args, is not a lexpr and thus 'arg' is illegal. The order that &aux variables are lambda bound is slightly different between interpreted and compiled code. As long as default expressions reference no formal parameters after them in the formal parameter list, there should be no problems. The interpreted version will not check for the correct number of arguments. Local functions cannot have &keywords. If you have any questions on this, send me mail. This change should only break functions which expect a variable number of argument and which don't declare the fact using &optional programs. There may be, of course, implementation errors. If you notice anything unusual please let me know right away. The old compiler will be in /usr/ucb/oliszt for a while. From layer Thu Jan 20 01:55:55 1983 Date: 20-Jan-83 01:55:55-PST (Thu) From: layer (Kevin Layer) Subject: liszt 8.20 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA17788; 20-Jan-83 01:55:55-PST (Thu) To: local-lisp Phone: (415) 652-2405 Status: O There are now three new command line features for liszt: 1. -E , where will be evaluated before compilation starts. For example, the setting of constants can be done in this way: liszt -E '(setq foobar "***foobar-string***")' foobar.l and in the file being compiled, foobar is accessed as '#.foobar. 2. -I , where will be loaded (via load) before compilation starts. 3. A combination of the -S and -o switches will set the .s file, as in: liszt -S -o foo.vax.s foo.l where previously, the -S determined the name of the .s file (foo.s in the above example). From jkf Thu Jan 20 19:42:38 1983 Date: 20-Jan-83 19:42:38-PST (Thu) From: jkf (John Foderaro) Subject: some mods to liszt 8.20 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA07334; 20-Jan-83 19:42:38-PST (Thu) To: local-lisp Status: O the -E and -I flags are now -e and -i there may be more than one -i flag given on the command line. From fateman Thu Jan 20 20:20:31 1983 To: local-lisp Subject: fame, if not fortune Status: RO In the latest Scientific American, Feb. 1983, Hofstader's column is the first of several on the programming language "lisp". He mentions the particular dialect he is using .... Franz ! From wilensky Thu Jan 20 20:57:27 1983 Date: 20-Jan-83 20:57:27-PST (Thu) From: wilensky (Robert Wilensky) Subject: Re: fame, if not fortune Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA08824; 20-Jan-83 20:57:27-PST (Thu) To: fateman, local-lisp In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday) Status: RO On the other hand, being referenced by Hofstader is a dubious honor. From UCBKIM:jkf Fri Jan 21 08:15:04 1983 Date: 21-Jan-83 08:11:01-PST (Fri) From: UCBKIM:jkf (John Foderaro) Subject: test message, ignore Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA18650; 21-Jan-83 08:11:01-PST (Fri) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA24887; 21 Jan 83 08:09:27 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA18766; 21-Jan-83 08:15:04-PST (Fri) To: franz-friends@BERKELEY Status: O This will give our mailer a chance to tell me how many of our franz friends are no longer reachable. From JTSCHUDY@USC-ISIE Sat Jan 22 16:42:19 1983 Date: 22 Jan 1983 1634-PST From: JTSCHUDY@USC-ISIE Subject: MAILINGLIST ADDITION Message-Id: Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA01747; 22 Jan 83 16:37:17 PST (Sat) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA18903; 22-Jan-83 16:42:19-PST (Sat) To: franz-friends@BERKELEY Status: O Hi! My name is Jim. I am presently attending the Naval Post Graduate School in Monterey California. I am in the Air Force enrolled in a DOD sponsored graduate degree in Command Control and Communications Systems Technology. i would like to be added to your mailing list. My net address is JTSCHUDY at ISIE. Thanks - Jim. ------- From jkf Sat Jan 22 17:38:41 1983 Date: 22-Jan-83 17:38:41-PST (Sat) From: jkf (John Foderaro) Subject: opus 38.49 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA20020; 22-Jan-83 17:38:41-PST (Sat) To: local-lisp Status: O A longstanding bug in the determination of the number of free dtpr objects has been found and fixed. The effect of this bug was that the function which is responsible for allocating more memory pages didn't allocate enough dtpr pages because it thought that there were a large number of cells free. From MCLINDEN@RUTGERS Mon Jan 24 10:33:14 1983 Date: 24 Jan 1983 1324-EST From: Sean McLinden Subject: Franz Lisp and floating point accelerator Message-Id: Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA19602; 24 Jan 83 10:25:06 PST (Mon) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA27143; 24-Jan-83 10:33:14-PST (Mon) To: franz-friends@UCBVAX Status: O Has anyone determined if a floating point accelerator speeds up Vax Franz Lisp jobs in any significant fashion? Pointers would be appreciated. Sean McLinden Decision Systems Lab ------- From mike@rand-unix Mon Jan 24 18:47:03 1983 Date: Monday, 24 Jan 1983 15:34-PST From: mike@RAND-UNIX Subject: emacs interface to franz? Message-Id: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00058; 24 Jan 83 16:08:36 PST (Mon) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00921; 24-Jan-83 18:47:03-PST (Mon) To: franz-friends@BERKELEY Status: O Does anyone have a snazzy interface to emacs for franz? Thanks, Michael From @udel-relay.ARPA,@UDel-Relay:[email protected] Tue Jan 25 16:29:19 1983 Date: 25 Jan 1983 9:58-EST From: Tim Finin Subject: emacs interface to franz? Message-Id: Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA29320; 25 Jan 83 16:22:57 PST (Tue) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA01561; 25-Jan-83 16:29:19-PST (Tue) Return-Path: To: mike@Rand-Unix Cc: franz-friends@BERKELEY Via: UPenn; 25 Jan 83 19:21-EST Status: O We have a simple interface from Franz to Emacs, but I much prefer to go the other way, i.e. run Franz as a inferior job under Emacs. I believe there are several Emacs packages which allow one to run inferior jobs in an Emacs window (I have my own which is, unfortunately totally undocumented). Some of the benefits of this set up include: - one has all of the text editing functions available in Emacs - one has many lisp-based editing functions available in Emacs (thru mock-lisp packages like electriclisp) - one has a history of the session in the editing buffer - one has an environment which supports multiple concurrent processes running in seperate windows. - it is very easy to experiment with new interface features such as symbol completion and re-evaluation of previously issued commands Tim From CARR@UTAH-20 Fri Jan 28 08:19:08 1983 Date: 28 Jan 1983 0912-MST From: Harold Carr Subject: franz distribution Message-Id: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA20646; 28 Jan 83 08:15:18 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA16991; 28-Jan-83 08:19:08-PST (Fri) To: franz-friends@UCBVAX Status: O What is the distribution policy? I work for a company that has opus 36 and is now currently running opus 37. Here at the University of Utah we are running opus 38.04. Is it OK to make a tape of the University's 38.04 to bring my company more up to date? Do I have to make it more formal by signing a transfer agreement or by obtaining the release directly from Berkeley? Thanks in advance, Harold Carr CARR@UTAH-20 ------- From UCBKIM:jkf Fri Jan 28 15:09:32 1983 Date: 28-Jan-83 08:34:33-PST (Fri) From: UCBKIM:jkf Subject: Re: franz distribution Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA17319; 28-Jan-83 08:34:33-PST (Fri) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA02275; 28 Jan 83 14:58:37 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00402; 28-Jan-83 15:09:32-PST (Fri) To: CARR@UTAH-20 Cc: franz-friends@UCBVAX In-Reply-To: Your message of 28 Jan 1983 0912-MST Status: O Here is our current distribution policy. This differs a bit from the one sent out a month ago [in particular, we now have anonymous ftp] -[Fri Jan 28 08:31:45 1983 by jkf]- Franz Lisp Distribution This note describes our distribution policy for Franz Lisp. What is being distributed: We distribute only source code in order to keep the distribution small and relatively Unix independent. Makefiles are provided to build the entire lisp system from source, even if you don't have a version of lisp running already. This process takes about 3 cpu hours on a Vax 780. [This version for the Vax only, a 68000 version is being worked on. Contact ucbkim.sklower@berkeley or ucbkim.layer@berkeley] The following source is provided: lisp interpreter, compiler (liszt), cross reference program (lxref), lisp manual, and other utility programs: trace, step, debug, cmu library functions, (and other minor ones), and these packages from the MIT lisp library: defstruct, loop. [These programs are provided as a convenience to those who can't access the arpanet and copy them. There is no documentation for them in the Franz Lisp manual. The best source of documentation is the Lisp Machine manual (available from MIT, Symbolics or LMI)] Regarding Flavors: there are two implementations of flavors for Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc)) and one from the University of Maryland (contact person Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is exactly like flavors on the Lisp Machine (due to differences between Lisp Machine lisp and Franz Lisp), and the implementations differ from each other. The MIT version cannot be distributed by us (yet) due to licensing problems. If you have a Lisp Machine Source license from Symbolics, you should be able to get a copy from MIT. For a Tech Report on Maryland flavors, write to Liz Allen. What is the form of the distribution: The files are packaged in a giant (2.1Mbyte) shell script. Running this shell script through 'sh' will result in a directory tree. A ReadMe file in the current directory will contain instructions on building the lisp system. The shell script is broken into a number of smaller files. The current distribution looks like: total 2089 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae The '38.50' means Opus 38, minor version 50. These numbers may be different by the time you get your distribution. In order to extract the lisp files from this shell script, you need only type: cat * | sh To get a copy of the distribution: The distribution may be obtained either using FTP from an arpanet site, or on a magnetic tape through the U.S Mail. Arpanet: The files are stored on the arpanet host 'ucb-vax' [ if you have an out of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its internet number is 10.2.0.78]. You can login as 'anonymous'. Use your name as the password. The files are in the subdirectory pub/lisp. For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp. Mag Tape: In order to get a copy of the distribution mailed to you, send a check to cover our tape copying and mailing costs (fees are listed below). We will purchase the mag tape and you are free to keep it. Please do NOT send us a tape. Fees: $50 - distribution tape mailed 3rd class add $10 - a copy of the Lisp Manual (we will only send one copy, you are free to photocopy it) add $7 - send tape via 1st class mail. -or- $15 - for just a copy of the Lisp Manual The address to send checks to is Keith Sklower EECS/Computer Science Division 524 Evans Hall University of California Berkeley, CA 94720 All checks should be made out to "Regents, University of California." We require pre-payment. We will not invoice or process purchase orders. Disclaimers: This distribution works on the latest versions of Unix running at Berkeley (4.1a). We can't guarantee that it will work on older versions (although, if you are running 4.1, it is almost certain that it will work, but we have not verified it). VMS users who are using a typical Unix compatibility package will probably not be able to build a lisp from this distribution unless they know a great deal about VMS and their compatibility package. At least one package (Eunice) supports Franz at this time. Redistribution: If you get a copy of the distribution, you are free to give it to other people. We appreciate being informed of new sites so they can be put on a mailing list (electronic and conventional). This list is used to announce new releases. To be put on this list, send U.S. Mail to Keith Sklower (address above) or to franz-friends-request@berkeley or ucbvax!franz-friends-request From Kim:fateman Sun Jan 30 02:12:28 1983 Date: 28 Jan 83 08:32:08 PST (Fri) From: Kim:fateman (Richard Fateman) Subject: Re: franz distribution Message-Id: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA21039; 28 Jan 83 08:31:58 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA10132; 30-Jan-83 02:12:28-PST (Sun) To: CARR@UTAH-20 Cc: franz-friends@ucbvax Status: O Our policy is that you may move copies of Franz elsewhere without notifying us. We continue to be interested in sharing anything you or your company wish to provide us, in suggestions, programs, etc. From UCBCAD:pettengi Sun Jan 30 02:33:52 1983 Date: 28-Jan-83 10:54:51-PST (Fri) From: UCBCAD:pettengi (Rob Pettengill) Subject: emacs interface to franz? Message-Id: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82]) id AA26156; 28-Jan-83 10:54:51-PST (Fri) Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00374; 28 Jan 83 12:53:44 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA10578; 30-Jan-83 02:33:52-PST (Sun) To: mike@rand-unix, franz-friends@ucbvax Cc: pettengi@UCBCAD Status: O While I was at TI I used a very nice interface that let one start up a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run under our VMS. Try Kashtan@SRI-AI. Rob Pettengill E-Systems, Dallas, Tx. From UCBKIM:jkf Sun Jan 30 02:44:27 1983 Date: 28-Jan-83 08:34:33-PST (Fri) From: UCBKIM:jkf (John Foderaro) Subject: Re: franz distribution Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA17319; 28-Jan-83 08:34:33-PST (Fri) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA02275; 28 Jan 83 14:58:37 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA10772; 30-Jan-83 02:44:27-PST (Sun) To: CARR@UTAH-20 Cc: franz-friends@UCBVAX In-Reply-To: Your message of 28 Jan 1983 0912-MST Status: RO Here is our current distribution policy. This differs a bit from the one sent out a month ago [in particular, we now have anonymous ftp] -[Fri Jan 28 08:31:45 1983 by jkf]- Franz Lisp Distribution This note describes our distribution policy for Franz Lisp. What is being distributed: We distribute only source code in order to keep the distribution small and relatively Unix independent. Makefiles are provided to build the entire lisp system from source, even if you don't have a version of lisp running already. This process takes about 3 cpu hours on a Vax 780. [This version for the Vax only, a 68000 version is being worked on. Contact ucbkim.sklower@berkeley or ucbkim.layer@berkeley] The following source is provided: lisp interpreter, compiler (liszt), cross reference program (lxref), lisp manual, and other utility programs: trace, step, debug, cmu library functions, (and other minor ones), and these packages from the MIT lisp library: defstruct, loop. [These programs are provided as a convenience to those who can't access the arpanet and copy them. There is no documentation for them in the Franz Lisp manual. The best source of documentation is the Lisp Machine manual (available from MIT, Symbolics or LMI)] Regarding Flavors: there are two implementations of flavors for Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc)) and one from the University of Maryland (contact person Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is exactly like flavors on the Lisp Machine (due to differences between Lisp Machine lisp and Franz Lisp), and the implementations differ from each other. The MIT version cannot be distributed by us (yet) due to licensing problems. If you have a Lisp Machine Source license from Symbolics, you should be able to get a copy from MIT. For a Tech Report on Maryland flavors, write to Liz Allen. What is the form of the distribution: The files are packaged in a giant (2.1Mbyte) shell script. Running this shell script through 'sh' will result in a directory tree. A ReadMe file in the current directory will contain instructions on building the lisp system. The shell script is broken into a number of smaller files. The current distribution looks like: total 2089 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae The '38.50' means Opus 38, minor version 50. These numbers may be different by the time you get your distribution. In order to extract the lisp files from this shell script, you need only type: cat * | sh To get a copy of the distribution: The distribution may be obtained either using FTP from an arpanet site, or on a magnetic tape through the U.S Mail. Arpanet: The files are stored on the arpanet host 'ucb-vax' [ if you have an out of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its internet number is 10.2.0.78]. You can login as 'anonymous'. Use your name as the password. The files are in the subdirectory pub/lisp. For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp. Mag Tape: In order to get a copy of the distribution mailed to you, send a check to cover our tape copying and mailing costs (fees are listed below). We will purchase the mag tape and you are free to keep it. Please do NOT send us a tape. Fees: $50 - distribution tape mailed 3rd class add $10 - a copy of the Lisp Manual (we will only send one copy, you are free to photocopy it) add $7 - send tape via 1st class mail. -or- $15 - for just a copy of the Lisp Manual The address to send checks to is Keith Sklower EECS/Computer Science Division 524 Evans Hall University of California Berkeley, CA 94720 All checks should be made out to "Regents, University of California." We require pre-payment. We will not invoice or process purchase orders. Disclaimers: This distribution works on the latest versions of Unix running at Berkeley (4.1a). We can't guarantee that it will work on older versions (although, if you are running 4.1, it is almost certain that it will work, but we have not verified it). VMS users who are using a typical Unix compatibility package will probably not be able to build a lisp from this distribution unless they know a great deal about VMS and their compatibility package. At least one package (Eunice) supports Franz at this time. Redistribution: If you get a copy of the distribution, you are free to give it to other people. We appreciate being informed of new sites so they can be put on a mailing list (electronic and conventional). This list is used to announce new releases. To be put on this list, send U.S. Mail to Keith Sklower (address above) or to franz-friends-request@berkeley or ucbvax!franz-friends-request From Kim:fateman Mon Jan 31 19:30:20 1983 Date: 28 Jan 83 08:32:08 PST (Fri) From: Kim:fateman (Richard Fateman) Subject: Re: franz distribution Message-Id: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA21039; 28 Jan 83 08:31:58 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA03502; 31-Jan-83 19:30:20-PST (Mon) To: CARR@UTAH-20 Cc: franz-friends@ucbvax Status: O Our policy is that you may move copies of Franz elsewhere without notifying us. We continue to be interested in sharing anything you or your company wish to provide us, in suggestions, programs, etc. From UCBCAD:pettengi Mon Jan 31 19:55:02 1983 Date: 28-Jan-83 10:54:51-PST (Fri) From: UCBCAD:pettengi (Rob Pettengill) Subject: emacs interface to franz? Message-Id: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82]) id AA26156; 28-Jan-83 10:54:51-PST (Fri) Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00374; 28 Jan 83 12:53:44 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA03987; 31-Jan-83 19:55:02-PST (Mon) To: mike@rand-unix, franz-friends@ucbvax Cc: pettengi@UCBCAD Status: O While I was at TI I used a very nice interface that let one start up a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run under our VMS. Try Kashtan@SRI-AI. Rob Pettengill E-Systems, Dallas, Tx. From Kim:fateman Mon Jan 31 21:34:44 1983 Date: 28 Jan 83 08:32:08 PST (Fri) From: Kim:fateman (Richard Fateman) Subject: Re: franz distribution Message-Id: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA21039; 28 Jan 83 08:31:58 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00642; 31-Jan-83 21:34:44-PST (Mon) To: CARR@UTAH-20 Cc: franz-friends@ucbvax Status: RO Our policy is that you may move copies of Franz elsewhere without notifying us. We continue to be interested in sharing anything you or your company wish to provide us, in suggestions, programs, etc. From UCBCAD:pettengi Mon Jan 31 22:12:30 1983 Date: 28-Jan-83 10:54:51-PST (Fri) From: UCBCAD:pettengi (Rob Pettengill) Subject: emacs interface to franz? Message-Id: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82]) id AA26156; 28-Jan-83 10:54:51-PST (Fri) Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00374; 28 Jan 83 12:53:44 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA01266; 31-Jan-83 22:12:30-PST (Mon) To: mike@rand-unix, franz-friends@ucbvax Cc: pettengi@UCBCAD Status: O While I was at TI I used a very nice interface that let one start up a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run under our VMS. Try Kashtan@SRI-AI. Rob Pettengill E-Systems, Dallas, Tx. From UCBKIM:jkf Tue Feb 1 10:35:21 1983 Date: 1-Feb-83 10:32:24-PST (Tue) From: UCBKIM:jkf (John Foderaro) Subject: multiple messages Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00599; 1-Feb-83 10:32:24-PST (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00473; 1 Feb 83 10:32:35 PST (Tue) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA00644; 1-Feb-83 10:35:21-PST (Tue) To: franz-friends@ucbvax Status: RO I'm sorry for the multiple messages. The franz-friends mailing list is huge and the machine which does the mailing is crashing often. Our local mail wizard informs me that if it crashes while in the middle of sending mail it will not have a record of who it sent to before the crash. I hope you don't get too many copies of this message. From mike@rand-unix Wed Feb 2 05:33:01 1983 Date: Tuesday, 1 Feb 1983 15:06-PST From: mike@RAND-UNIX Subject: response to "emacs interface to franz?" Message-Id: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00221; 2 Feb 83 05:25:50 PST (Wed) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA24463; 2-Feb-83 05:33:01-PST (Wed) To: franz-friends@BERKELEY Cc: mike@RAND-UNIX Status: RO Here are the responses that I received to my question "What's out there for emacs?" ------- Forwarded Messages Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983 Date: Mon 24 Jan 83 22:43:01-PST From: Jay Lark Subject: Re: emacs interface to franz? To: [email protected] In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST I'm sure you've probably received several messages similar to this one, but just in case... There exists the capability in Unix Emacs to run a process in its own buffer. Typein can be directed to the process, and output is just sent right to the buffer. This is an excellent way of running Lisp, because you get all of the nice Emacs features (paren balancing, local sexpr editing) at essentially no cost. I have been largely unsuccessful with trying to run Emacs under Lisp. The process package is part of the standard Unix Emacs distribution. Jay Lark ------- ------- Message 2 Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983 Date: 25 Jan 1983 7:20-MST From: Russ Fish (host 10.0.0.4) Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Cc: utah-gr!galway@UTAH-CS In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST We have been running our PSL (Portable Standard Lisp) in gemacs (Gosling's emacs) windows for some time. I suspect it would be a minor hack to convert it to Franz, but haven't done it and am not a Franz user. I could mail you our .ml code if you wanted to undertake converting it to Franz (or just using it for inspiration and hacking your own) and distributing it to Franz folks. It works like this: The lisp process is associated with a gemacs buffer/window. In that window you can carry on a normal line-by-line conversation, if you wish. sends the current line, (back to mark, which is left after the prompt) into the lisp. We mostly use the PSL in Rlisp syntax, which is algol-like, but this part of the code is just a wrapping for the new-shell function in process.ml with appropriate editting syntax set, so you could do the same with no work for any Lisp. You can send an expression, fn def, etc. from any other lisp-mode window with a single keypress. Echoing as input in the dialog window is inhibited if a prefix arg is provided, so you don't have to look at long exprs or fn defs again, just the lisp response. Sending multiple line exprs in response to a single prompt depends on the fact that PSL numbers the prompts for history, like the c-shell. A gemacs mlisp output filter process monitors the output for toploop prompts and feeds another line of input if the same prompt number comes back, instead of printing the prompt. The result is pretty classy. You get the full many-window gemacs editing environment with tags, etc. for random-access navigation and just send chunks of code as you change them. The extreme of usage is "menu" like windows which contain debugging code in clusters rather than sequences. You select exprs with the cursor and send them in any order. We also provide key fns for the common case of sending single lines to the toploop or single-character commands to the break-loop without editting them into a buffer. Best respond directly to me, since I am not on Franz-Friends. -Russ Fish (Fish@Utah-20, utah-cs!fish) ------- Message 3 Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983 Return-Path: Date: 25 Jan 83 15:13:51 EST (Tue) From: Bruce Israel Subject: Re: emacs interface to franz? To: mike@RAND-UNIX In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX Via: UMCP-CS; 25 Jan 83 20:45-EST We have a few franzemacs interfaces, but I'm not sure what you mean. One is the process.ml package that comes with gosling's emacs (the emacs that I assume you are talking about). With this package, you can run franz inside a window from within emacs and have the facilities of an editor along with lisp. The other thing we have is a local Franz package called the load1 package. This package was written for compiling flavors (like in the lisp machine; another local package) and has a function called vi. (vi 'lisp-function) will call the editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the file which contains the definition of the lisp function, positioning the editor at the point in the file where the function is defined. Upon exiting the editor, it asks you if you want to reload the modified file. To edit a function from a file this way, the file must have been load1'ed previously so that the info on where the function is stored and what type it is will have been saved. Load1 will distinguish between different types of functions, ie. defflavors, defmethods, defmacros, defuns etc. and will search for the correct definition in the file. Is this what you mean? If you like I can send you the four or five files necessary. - Bruce ------- Message 4 Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983 Date: 27 Jan 1983 09:44-EST From: Carl.Ebeling@CMU-CS-VLSI Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Message-Id: In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14 I have an electric lisp package and process package for emacs. It includes 'zap-function-to-lisp' among other things. It is for Gosling's emacs and uses the subprocess facility. I can mail them to you if you like. Carl ------- End of Forwarded Messages From UCBKIM:jkf Wed Feb 2 08:19:19 1983 Date: 2-Feb-83 08:14:21-PST (Wed) From: UCBKIM:jkf (John Foderaro) Subject: multiple messages fixed? Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA25937; 2-Feb-83 08:14:21-PST (Wed) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00384; 2 Feb 83 08:10:26 PST (Wed) Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00477; 2 Feb 83 08:14:35 PST (Wed) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA26020; 2-Feb-83 08:19:19-PST (Wed) To: franz-friends@ucbvax Status: RO I've broken the franz-friends mailing list over two machines. I hope that this will fix the problem of mail to franz-friends crashing ucbvax every thirty minutes. If you get multiple copies of this message, please do not tell me about it, I will already know. From jkf Thu Feb 10 21:45:17 1983 Date: 10-Feb-83 21:45:17-PST (Thu) From: jkf (John Foderaro) Subject: liszt 8.21 Message-Id: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA16021; 10-Feb-83 21:45:17-PST (Thu) To: local-lisp Status: O more functions open coded: vsize, vsize-byte, vsize-word, vectorp, vectorip From PSI.KROHNFELDT@UTAH-20 Fri Feb 11 15:09:11 1983 Date: 11 Feb 1983 1601-MST From: Jed Krohnfeldt Subject: cfasl Message-Id: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07475; 11 Feb 83 15:02:05 PST (Fri) Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07565; 11 Feb 83 15:06:37 PST (Fri) Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA14422; 11-Feb-83 15:09:11-PST (Fri) To: Franz-friends@UCBVAX Status: O I am having trouble using cfasl in franz 38.04. I keep getting the message "ld: /usr/ucb/lisp : no namelist". Can anyone decipher this for me? Thanks... ------- From apm@cmu-ri-isl Mon Feb 14 07:31:54 1983 Date: 14 Feb 1983 10:24:21-EST From: Andrew.Mendler@CMU-RI-ISL Subject: franz lisp under5 vms 3.0 Message-Id: Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3) id AA27879; 14 Feb 83 07:31:54 PST (Mon) Received: by UCBKIM.ARPA (3.310/3.3) id AA01172; 14 Feb 83 15:50:41 PST (Mon) To: [email protected] Status: O Does anyone have a copy of Franz Lisp and the compiler that works under VMS version 3.0? From @udel-relay:tim.unc@UDel-Relay Mon Feb 14 02:52:18 1983 Date: 13 Feb 83 14:34:48 EST (Sun) From: Tim Maroney Subject: cfasl: no namelist Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3) id AA25792; 14 Feb 83 02:52:18 PST (Mon) Received: by UCBKIM.ARPA (3.310/3.3) id AA02234; 14 Feb 83 16:18:42 PST (Mon) To: [email protected] Via: UNC; 14 Feb 83 5:43-EST Status: O I don't seem to be able to write Jed Krohnfeldt, and this answer is probably of general interest anyway. The message "ld: no namelist" means that some well-meaning system admin has stripped the lisp executable file to save space; unfortunately, this makes the dynamic loading used by cfasl impossible. Lisp will have to be recompiled (groan). No Franz Lisp executable file should EVER be stripped. Tim Maroney tim.unc@udel-relay decvax!duke!unc!tim From Mark.Sherman@CMU-CS-A Sat Feb 12 21:38:46 1983 Date: 13 February 1983 0034-EST (Sunday) From: Mark.Sherman@CMU-CS-A Subject: Space and Leakage Message-Id: Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07842; 12 Feb 83 21:38:46 PST (Sat) Received: by UCBKIM.ARPA (3.310/3.3) id AA02341; 14 Feb 83 16:21:29 PST (Mon) To: franz-friends@UCB-VAX Status: O Can someone tell me how the maximum amount of storage that franz lisp uses is decided? I can force the size up to (about) 3050 pages (according to "ps") and then get the message "storage exhausted". I have been told (and have seen) other jobs get substantially more space; can franz get more pages as well? (I am using the cshell and have already used the limit command to raise my process size up to 32 megabytes, or so I think.) I have also been told that the garbage collector leaks, that is, not all of the garbage is really collected. Does anyone have good ideas about how much (or fast) this happens, or if there is some way to minimize the lost space? (Please send responses directly to me as I am not on this list.) -Mark Sherman (Sherman@CMU-CS-A) From @udel-relay:Mac.uvacs.Virginia@UDel-Relay Fri Feb 18 21:04:31 1983 Date: 18 Feb 83 12:42:40-EST (Fri) From: Mac.uvacs@UDel-Relay Subject: global nonspecial variables Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5) id AA26020; 18 Feb 83 21:04:31 PST (Fri) Received: by UCBKIM.ARPA (3.310/3.5) id AA00656; 21 Feb 83 01:59:26 PST (Mon) To: [email protected] Via: Virginia; 18 Feb 83 23:58-EST Status: O Does the Liszt compiler have any notion of global variables -- free variables with fast access, without any rebinding? I think the MACLISP compiler has something like this for variables beginning "**". Alex Colvin uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac csnet:mac@virginia arpa: mac.uvacs@udel-relay From jkf@UCBKIM Mon Feb 21 09:19:56 1983 Date: 21 Feb 83 09:19:43 PST (Mon) From: jkf@UCBKIM (John Foderaro) Subject: Re: global nonspecial variables Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA02798; 21 Feb 83 09:19:43 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA13982; 21 Feb 83 09:11:52 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA02805; 21 Feb 83 09:19:56 PST (Mon) To: Mac.uvacs@UDel-Relay, [email protected] In-Reply-To: Your message of 18 Feb 83 12:42:40-EST (Fri) Status: O I don't understand the distinction between what you call a global variable and a special variable. A special variable in Franz Lisp (and any other shallow bound lisp) can be accessed rapidly and is only rebound if you put it in a lambda, prog or do variable list. From jkf@UCBKIM Fri Feb 25 08:29:01 1983 Date: 25 Feb 83 08:28:45 PST (Fri) From: jkf@UCBKIM (John Foderaro) Subject: research position at edinburgh Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA00528; 25 Feb 83 08:28:45 PST (Fri) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA00867; 25 Feb 83 08:18:48 PST (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA00537; 25 Feb 83 08:29:01 PST (Fri) To: [email protected] Status: O DEPARTMENT OF ARTIFICIAL INTELLIGENCE UNIVERSITY OF EDINBURGH RESEARCH FELLOW A Research Fellowship is available within the Programming Systems Development Group. The post has been created specifically to provide a modern LISP system for the Perq computer running under ICL MicroCode UNIX, and is funded by the Science and Engineering Research Council. Experience in implementing systems would be advantageous, as would be a knowledge of LISP and C. Access will be available to an SERC DECsystem-10 running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as to Perqs. The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds sterling, according to age and experience. The post is funded for a period of two years from the date of appointment. Further particulars of the post can be obtained from: Administrative Assistant Department of Artificial Intelligence University of Edinburgh Forrest Hill Edinburgh EH1 2QL SCOTLAND phone 031-667-1011 x2554 or by contacting RAE%EDXA%UCL-CS@ISID (Networks permitting) Applications should be made by March 17th, 1983. From layer Sat Mar 5 20:12:57 1983 Date: 5 Mar 83 20:12:57 PST (Sat) From: layer (Kevin Layer) Subject: process function Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA18927; 5 Mar 83 20:12:57 PST (Sat) Phone: (415) 652-2405 To: local-lisp Status: O The process function now looks in the environment at the SHELL variable. If present, it will use this as the default shell to execute your command. If not present, csh and then sh are tried (in that order). From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay Tue Mar 8 06:04:10 1983 Date: 8 Mar 1983 2:32-EST From: Susan Pintzuk Subject: lisp statistical packages Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14) id AA13004; 8 Mar 83 06:01:54 PST (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA08297; 8 Mar 83 06:04:10 PST (Tue) To: [email protected] Via: UPenn; 8 Mar 83 3:49-EST Status: O do any franz-lisp packages exist which calculate mean, standard deviation, %n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.? if so, how do i obtain a copy? From jkf Tue Mar 8 09:10:46 1983 Date: 8 Mar 83 09:10:46 PST (Tue) From: jkf (John Foderaro) Subject: opus38.56 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA09423; 8 Mar 83 09:10:46 PST (Tue) To: local-lisp Status: O If $gcprint is set to a non nil value, then just before a garbage collection is begun, the message 'gc:' will be printed on the tty. As before, after the garbage collection is finished, the statistics message in square brackets will be printed. From fateman Wed Mar 9 09:54:31 1983 Date: 9 Mar 83 09:54:31 PST (Wed) From: fateman (Richard Fateman) Subject: need a job Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA14754; 9 Mar 83 09:54:31 PST (Wed) To: local-lisp Status: O porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP computer? Wanna live in Denver? There is a recruiter in town from Denelcor at Marriot Inn, Jim Holly. There is an ad posted on 5th floor bulletin board. From jkf Sat Mar 19 17:44:33 1983 Date: 19 Mar 83 17:44:33 PST (Sat) From: jkf (John Foderaro) Subject: liszt 8.24 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA25091; 19 Mar 83 17:44:33 PST (Sat) To: local-lisp Status: O The vax and 68k versions of liszt have been combined into one set of source files. This is mainly a textual change, but some functions in the compiler have been modified in reduce the machine dependent code. Be on the lookout for strange errors. From fateman Tue Mar 22 20:52:11 1983 Date: 22 Mar 83 20:52:11 PST (Tue) From: fateman (Richard Fateman) Subject: T Lisp Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA05935; 22 Mar 83 20:52:11 PST (Tue) To: local-lisp Status: RO I have a preliminary manual for the T dialect of Lisp, created at Yale. It is being offered for sale by Cognitive Systems, Inc. for $1000/CPU (educational price). It offers features from Lisp and Scheme. It runs on VAX and Apollo 68000 systems. From jkf Thu Mar 24 08:29:31 1983 Date: 24 Mar 83 08:29:31 PST (Thu) From: jkf (John Foderaro) Subject: liszt 8.25 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA06735; 24 Mar 83 08:29:31 PST (Thu) To: local-lisp Status: O If you do this: liszt -x a/b/c.l -o x/y/z.o then the cross reference file will be put in x/y/z.x Before this version, it would have gone into a/b/c.x From jkf Thu Mar 24 15:00:37 1983 Date: 24 Mar 83 15:00:37 PST (Thu) From: jkf (John Foderaro) Subject: liszt 8.26 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA11144; 24 Mar 83 15:00:37 PST (Thu) To: local-lisp Status: O liszt will now pass the assembler the -V switch. This tells the assembler to keep its intermediate file in core rather than putting it in /tmp. This should make assembly slightly faster and also permit large lisp files to be compiled on systems with small /tmp's. From @udel-relay.ARPA:tim.unc@UDel-Relay Sat Mar 26 03:41:05 1983 Date: 25 Mar 83 15:03:29 EST (Fri) From: Tim Maroney Subject: open coding of (function (lambda ...)) Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17) id AB02371; 26 Mar 83 03:37:13 PST (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA00854; 26 Mar 83 03:41:05 PST (Sat) To: [email protected] Via: UNC; 25 Mar 83 19:43-EST Status: O This doesn't seem to work. I'm using Liszt version 8.10, University of Maryland distribution. The documentation in the file "lispnews" is sketchy, but it seems that compiling and loading the file: (setq appsum (function (lambda (x) (apply 'sum x)))) should leave a bcd object in appsum's value, but it doesn't. It leaves the uncompiled lambda. Am I doing something wrong? Tim Maroney decvax!duke!unc!tim tim.unc@udel-relay From jkf@UCBKIM Sat Mar 26 08:46:44 1983 Date: 26 Mar 83 08:46:28 PST (Sat) From: jkf@UCBKIM (John Foderaro) Subject: Re: open coding of (function (lambda ...)) Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA02453; 26 Mar 83 08:46:28 PST (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17) id AA05012; 26 Mar 83 08:42:50 PST (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA02462; 26 Mar 83 08:46:44 PST (Sat) To: tim.unc@UDel-Relay Cc: [email protected] In-Reply-To: Your message of 25 Mar 83 15:03:29 EST (Fri) Status: O Liszt only compiles functions, not literals it finds in files. To make this statement be compiled: (setq appsum (function (lambda (x) (apply 'sum x)))) you should surround it with a function defintion: (defun junk () (setq appsum (function (lambda (x) (apply 'sum x))))) From CARR@UTAH-20 Mon Apr 4 14:53:09 1983 Date: 4 Apr 1983 0922-MST From: Harold Carr Subject: Franz/Common lisp Message-Id: Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA07020; 4 Apr 83 09:11:40 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA01683; 4 Apr 83 14:53:09 PST (Mon) To: [email protected] Cc: KROHNFELDT@UTAH-20 Status: O Does anyone have any sort of Common Lisp compatibility package for Franz? If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20). ------- From jeff@aids-unix Tue Apr 5 12:42:46 1983 Date: 4 Apr 1983 11:06:49 PST (Monday) From: Jeff Dean Subject: knowledge representation language Message-Id: Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA26557; 5 Apr 83 12:42:11 PST (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA16443; 5 Apr 83 12:42:46 PST (Tue) To: [email protected] Status: O Does anyone have a knowledge representation language (such as FRL or KL-ONE) available under Franz Lisp? Jeff Dean arpa: jeff@aids-unix uucp: ...ucbvax!jeff@aids-unix From jkf Tue Apr 5 13:08:06 1983 Date: 5 Apr 83 13:08:06 PST (Tue) From: jkf (John Foderaro) Subject: lisp opus 38.57 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA16969; 5 Apr 83 13:08:06 PST (Tue) To: local-lisp Status: RO This version has a number of internal changes to make it compilable on 68k. If you notice it acting abnormally, let me know. From FAHLMAN@CMU-CS-C Thu Apr 7 07:50:06 1983 Date: Thu, 7 Apr 1983 10:46 EST From: Scott E. Fahlman Subject: Franz/Common lisp Message-Id: Received: ID ; 7 Apr 83 10:46:59 EST Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA13873; 7 Apr 83 07:49:42 PST (Thu) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA18082; 7 Apr 83 07:50:06 PST (Thu) To: Harold Carr Cc: [email protected] In-Reply-To: Msg of 4 Apr 1983 11:22-EST from Harold Carr Status: RO Harold, A couple of things make it seem unlikely that anyone would have such a package right now. First, we don't even have a final Common Lisp manual yet -- Guy's next draft is due very soon, but there will be some tuning and hassling after that. Second, there are things in Common Lisp that would be very tough to fake on Franz: lexical binding, generic sequences, some of the hairy number types, character objects, etc. Common Lisp is pretty close to being a superset of Franz, so I would expect to see Franz compatibility packages in Common Lisp, but not vice versa. Third, if anyone were writing such a package, they would be crazy not to have arranged for access to our code that implements all of the hairy functions, and nobody has done this to my knowledge. My standard advice is for people to continue to code in Franz with the knowledge that they can easily convert their code to Common Lisp whenever the DEC Common Lisp is available to them. This should be a one-time conversion, since moving the other way after "going native" in Common Lisp would be very tough. If someone does pop up with a compatibility package -- even a partial one -- I would be interested in hearing about it. -- Scott From fateman@UCBKIM Sun Apr 10 19:52:14 1983 Date: 10 Apr 83 19:50:59 PST (Sun) From: fateman@UCBKIM (Richard Fateman) Subject: Re: Franz/Common lisp Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA06176; 10 Apr 83 19:50:59 PST (Sun) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA10019; 10 Apr 83 19:49:55 PST (Sun) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA06192; 10 Apr 83 19:52:14 PST (Sun) To: carr@utah-20, fahlman@cmu-cs-c Cc: [email protected] Status: RO I think that a common-lisp-compatibility package written in Franz would not be as difficult as all that. If Common Lisp (TM of DEC?) were available on all the same machines at the same price, (appx. $0.) and CL were in fact a superset of Franz for all practical purposes, and with similar or better efficiency, etc. Why would anyone bother? Of course if CL does not meet all of the objectives (e.g. price, machines), then a CL-to-Franz "translator" might make sense. With that in mind, I would like to officially request a copy of the Common Lisp language (as implemented in CL, presumably), as soon as it becomes available (i.e. no later than when it is a "product" of DEC, and probably at "beta" test time). I agree fully with Scott that trying to do this with an incomplete language specification is unwise. I am also not making any commitment to do anything with CL at Berkeley, but since we are building tools for our own applications, and CL might be useful, we might consider an efficient merge of ideas. From jkf@UCBKIM Mon Apr 11 08:07:39 1983 Date: 11 Apr 83 06:42:43 PST (Mon) From: jkf@UCBKIM (John Foderaro) Subject: mail to this mailing list Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA11378; 11 Apr 83 06:42:43 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA07288; 11 Apr 83 08:05:32 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA11949; 11 Apr 83 08:07:39 PST (Mon) To: [email protected] Status: RO I'm sorry that people who mail to this mailing list must put up with lots of mail errors from our local mailer. The problem is not that we have a lot of illegal addresses, but that over the three day period that the mailer tries to deliver the mail, some of the destination sites never respond. I think that this is due primarily to the fact that many sites are running new mail and networking software. Hopefully this will improve over time. john foderaro From jkf Fri Apr 22 09:59:09 1983 Date: 22 Apr 83 09:59:09 PST (Fri) From: jkf (John Foderaro) Subject: lisp opus 38.59 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA20996; 22 Apr 83 09:59:09 PST (Fri) To: local-lisp Status: RO Input like 1.2.3 and 1..2 will now be read as single symbols rather than two consecutive numbers. From jkf Sun May 8 00:02:54 1983 Date: 8 May 83 00:02:54 PDT (Sun) From: jkf (John Foderaro) Subject: opus 38.60 Message-Id: Received: by UCBKIM.ARPA (3.310/3.5) id AA22344; 8 May 83 00:02:54 PDT (Sun) To: local-lisp Cc: rms Status: RO Thanks to some suggestions from rms we are now one step closer to full closures. fclosures will now work if called recursively. It is still true that the only way to make fclosures share variables is to use fclosure-list. symeval-in-fclosure may return the wrong value if the closure is 'active'. This will be fixed eventually. From mbr@nprdc Sat May 21 07:37:23 1983 Date: 20 May 1983 14:57:55-PDT From: mbr@NPRDC Subject: lam9.c and curses Message-Id: Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29) id AA16172; 21 May 83 07:34:43 PDT (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA08856; 21 May 83 07:37:23 PDT (Sat) Reply-To: mbr To: [email protected] Cc: mbr@NPRDC Status: O When we attempted to cfasl a file that used the curses package of screen control routines into Franz 38.40, we got the message _ospeed: /usr/libcurses.a (cr_tty.o) multiply defined. The apparent cause of this cryptic remark is that in lam9.c there is an extern variable ospeed. There are a number of tantalizing routines in this source file dealing with termcaps that are apparently not called by anyone. Are there plans for these routines? Does anyone use them (heaven forbid they should be documented!). Our current fix is to just change ospeed to ospiid which so far has had no dire effects, but I am interested in others experience. The curses stuff seems to work fine after this modification. Mark Rosenstein From jkf Wed May 25 12:15:54 1983 Date: 25 May 83 12:15:54 PDT (Wed) From: jkf (John Foderaro) Subject: opus 38.61 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA01144; 25 May 83 12:15:54 PDT (Wed) To: local-lisp Status: O symeval-in-fclosure and set-in-fclosure now work (thanks to keith). selectq is now a part of standard franz. selectq is just like caseq except it allows 'otherwise' as well as 't' for the key which means 'if nothing else matches, use this clause'. From cornwell@nrl-css Wed May 25 12:51:17 1983 Date: Wed, 25 May 83 15:14:19 EDT From: Mark Cornwell Subject: Franz on the Sun Message-Id: Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29) id AA02600; 25 May 83 12:50:26 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA01878; 25 May 83 12:51:17 PDT (Wed) To: [email protected] Cc: cornwell@NRL-CSS Status: O Our group at NRL is planning to purchase Sun workstations. I currently have a substantial amount of code written in Franz Lisp that I want to run on the Sun. What is the status of the Berkeley group porting Franz to the Sun? How do I get a copy? Also, I have a few concerns about configuring a Sun to run Franz well. The basic desktop Sun workstation provides 1 Mbyte of physical memory. This can be extended to 2 Mbyte or one can add an Ethernet interface *but not both*. Since I am unwilling to give up my Ethernet interface I may be forced to run Franz in 1 Mbyte and contend with the added paging overhead (using a 68010 running 4.2bsd and a local disk). Has anyone out there had experience running Franz Lisp on a Sun in such a configuration? Can I get away without the 2 Mbyte extension? I think your answers would be of general interest. -- Mark (caught between a rock and a hard place?) Cornwell From baden@UCBKIM Wed May 25 13:51:39 1983 Date: 25 May 83 13:32:01 PDT (Wed) From: baden@UCBKIM (Scott B. Baden) Subject: Re: Franz on the Sun Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA02716; 25 May 83 13:32:01 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA03753; 25 May 83 13:50:52 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA03002; 25 May 83 13:51:39 PDT (Wed) To: [email protected] Cc: cornwell@NRL-CSS Status: O Which sun are you using? My office mate says that he has seen a sun configured with 2MB of memory AND an Ethernet board. From mike%Rice.Rice@Rand-Relay Fri May 27 19:51:33 1983 Date: Fri, 27 May 83 18:18:47 CDT From: Mike.Caplinger Subject: Re: Franz on the Sun Return-Path: Message-Id: Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29) id AA19088; 27 May 83 19:50:15 PDT (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA02221; 27 May 83 19:51:33 PDT (Fri) To: [email protected] In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed) Via: Rice; 27 May 83 19:14-PDT Status: RO As I type I'm bringing up the 68K version of Opus 38 (now FTPable from UCB-VAX) on a SUN running 4.1c. There don't seem to be any major problems so far, but the compiler doesn't run on a system with all the net servers on it because it runs out of memory. I've been told this is because there's a bug in 4.1c that forces it to only use 1/2 of the swap partition. I'm having to run standalone to compile the compiler; I don't yet know whether I'll be able to compile other stuff without this rather extreme fix. As I use the system more I will post more info to this group. From narain@rand-unix Tue May 31 10:49:00 1983 Date: Tuesday, 31 May 1983 10:45-PDT From: narain@rand-unix Subject: Interrupt question Message-Id: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29) id AA10893; 31 May 83 10:47:26 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA13428; 31 May 83 10:49:00 PDT (Tue) To: [email protected] Cc: narain@rand-unix Status: O Hi, I would be grateful if you could tell me what is the equivalent of Interlisp's control-h (followed by OK) in Franzlisp. In other words, I wish to interrupt a Franzlisp program, from time to time, examine its state and allow it to continue from the interrupted point. -- Sanjai From [email protected] Tue May 31 19:31:04 1983 Date: 31 May 83 17:28:35 PDT (Tue) From: [email protected] Subject: packages Message-Id: Received: by LBL-CSAM.ARPA (3.320/3.21) id AA16451; 31 May 83 17:28:35 PDT (Tue) Received: by UCBVAX.ARPA (3.341/3.31) id AA02877; 31 May 83 19:30:00 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA22745; 31 May 83 19:31:04 PDT (Tue) To: [email protected] Status: O Does a version of LispMachine ``packages'' or some similar oblist partitioning scheme exist for franz? Having just integrated several independently coded modules, I think something like that would be very useful. -thanks Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve From fateman Tue Jun 14 11:48:32 1983 Date: 14 Jun 83 11:48:32 PDT (Tue) From: fateman (Richard Fateman) Subject: "macsyma on a chip?" Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA06756; 14 Jun 83 11:48:32 PDT (Tue) To: macsyma-i@mit-mc Cc: franz-friends Status: O Well, sort of. We now have Macsyma running on a Motorola 68000 - based system with 6 megabytes of real memory. The operating system is a Unisoft UNIX system, which has been ported to some large number (>65) boxes. The Pixel people were kind enough to lend us a machine with enough real memory to make virtual memory unnecessary. It takes a long time to load up, but once running, it is quite responsive, and appears to be about 60% of a VAX 11/780 in terms of CPU time. We have not shaken down everything, but since the source code is unchanged from the VAX, we expect the bugs to be limited to lisp compilation glitches, or differences between versions of the UNIX system. From jkf Wed Jun 15 10:42:05 1983 Date: 15 Jun 83 10:42:05 PDT (Wed) From: jkf (John Foderaro) Subject: Opus 38.62 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA20591; 15 Jun 83 10:42:05 PDT (Wed) To: local-lisp Status: O There is no longer a limit on the size of bignums, strings or symbol names which can be read by the reader [other than the size of virtual memory]. The value of lisp-library-directory will determine where cfasl finds its private version of the loader. (changes by sklower) From @CMU-CS-C:UI.TYJ@CU20D Wed Jun 15 18:22:55 1983 Date: 14 Jun 1983 1812-EDT From: Tai Jin Subject: franz mailing liszt Message-Id: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA16599; 14 Jun 83 15:14:36 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA28806; 15 Jun 83 18:22:55 PDT (Wed) To: franz-friends%berkeley@CMCSC Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC Status: O Hi, we would like to be added to your mailing list. We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS) running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center for Computing Activities). Is anyone out there working on an UTS/IBM implementation? Any information will be greatly appreciated. Thanks, Tai Jin Travis Winfrey ------- From @CMU-CS-C:Ui.Travis@CU20D Thu Jun 16 09:47:39 1983 Date: 16 Jun 1983 1243-EDT From: Travis Lee Winfrey Subject: Porting Franz lisp to Amdahl Unix Message-Id: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA25470; 16 Jun 83 09:46:15 PDT (Thu) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA06352; 16 Jun 83 09:47:39 PDT (Thu) To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D, kim.fateman%berkeley@CMCSC Status: O Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's Unix running on a IBM 4341. We are working from a copy that runs on the VAX. We would be very interested in seeing any versions that runs both on the VAX and some other machine, such as the 68000. We are also interested in seeing any documentation on other porting efforts, regardless of what machine. Thanks, Tai Jin Travis Winfrey ------- From jkf Sun Jun 19 15:43:34 1983 Date: 19 Jun 83 15:43:34 PDT (Sun) From: jkf (John Foderaro) Subject: opus 38.63 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA19626; 19 Jun 83 15:43:34 PDT (Sun) To: local-lisp Status: O Added functions: (vputprop 'Vv_vector 'g_value 'g_indicator) (vget 'Vv_vector 'g_indicator) work just like putprop and get, but modify the vector property list. Also: you can determine which function is called by lisp to print a vector by placing the function to call on the vector's property list under indicator 'print'. The print function is called with two arguments: the vector and the port. For example: => (defun printv (v port) (patom "A vector of size " port) (print (vsize v) port)) printv => (setq xx (new-vector 10)) vector[40] => (vputprop xx 'printv 'print) printv => xx A vector of size 10 => From jkf Sun Jun 19 22:47:42 1983 Date: 19 Jun 83 22:47:42 PDT (Sun) From: jkf (John Foderaro) Subject: opus 38.64 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA23164; 19 Jun 83 22:47:42 PDT (Sun) To: local-lisp Cc: jpg@Mit-mc Status: O added the function (^ 'x_a 'x_b) which computes x_a to the x_b power and always returns a fixnum result (it currently wraps around on overflow). From JPG@MIT-MC Sun Jun 19 22:54:00 1983 Date: 20 June 1983 01:53 EDT From: Jeffrey P. Golden Subject: ^ Message-Id: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA15160; 19 Jun 83 22:53:57 PDT (Sun) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA23228; 19 Jun 83 22:54:00 PDT (Sun) To: jkf@UCBKIM Cc: JPG@MIT-MC, local-lisp@UCBKIM Status: O Date: 19 Jun 83 22:47:42 PDT From: jkf%UCBKIM@Berkeley Subject: opus 38.64 To: local-lisp%UCBKIM@Berkeley Cc: jpg@Mit-mc added the function (^ 'x_a 'x_b) which computes x_a to the x_b power and always returns a fixnum result (it currently wraps around on overflow). The Maclisp ^ errors out in this case with the message: ;RESULT LARGER THAN FIXNUM - ^ From narain@rand-unix Mon Jun 20 22:09:31 1983 Date: Monday, 20 Jun 1983 22:00-PDT From: narain@rand-unix Subject: Re: Interrrupt question Message-Id: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA00276; 20 Jun 83 22:09:20 PDT (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA09633; 20 Jun 83 22:09:31 PDT (Mon) To: [email protected] Cc: narain@rand-unix Status: O TWIMC ----- Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp: i.e. if you wish to interrupt a Franzlisp computation, browse around the state and resume computation: Hit DEL; Browse; (return t) This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay). -- Sanjai From Tim%UPenn.UPenn@UDel-Relay Tue Jun 21 14:52:53 1983 Date: Tue, 21 Jun 83 10:33 EDT From: Tim Finin Subject: interrupting Franz Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA12930; 21 Jun 83 14:52:36 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA21097; 21 Jun 83 14:52:53 PDT (Tue) To: [email protected] Via: UPenn; 21 Jun 83 17:40-EDT Status: O Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz. From jkf Sat Jun 25 13:49:37 1983 Date: 25 Jun 83 13:49:37 PDT (Sat) From: jkf (John Foderaro) Subject: opus 38.65 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA25527; 25 Jun 83 13:49:37 PDT (Sat) To: local-lisp Status: O If you have automatic case conversion set (i.e. (sstatus uctolc t)), then symbols with lower case letters will be escaped by print. From layer Tue Jul 5 00:26:29 1983 Date: 5 Jul 1983 0026-PDT (Tuesday) From: layer (Kevin Layer) Subject: lisp opus 38.67 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA05911; 5 Jul 83 00:26:29 PDT (Tue) Phone: (415) 652-2405 To: local-lisp Cc: layer Status: O The function 'sortcar' has been slightly changed: if the second arg is nil, then the ordering function 'alphalessp' is assumed ('sort' does it this way). Kevin From layer Wed Jul 6 00:02:33 1983 Date: 6 Jul 83 00:02:33 PDT (Wed) From: layer (Kevin Layer) Subject: liszt opus 8.30 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA24776; 6 Jul 83 00:02:33 PDT (Wed) Phone: (415) 652-2405 To: local-lisp Cc: sklower, jkf Status: O All modifications should be transparent, but if there are problems relating to the autorun feature (-r flag), please let me know. Kevin From sklower Thu Jul 7 00:27:52 1983 Date: 7 Jul 83 00:27:52 PDT (Thu) From: sklower (Keith Sklower) Subject: Franz, opus38.68 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA10697; 7 Jul 83 00:27:52 PDT (Thu) To: local-lisp Status: O Franz now escapes UPPER case letters instead of lower case letters when (status uctolc) is enabled, so that (read (print x)) is an identity operation on atom printnames. Also, we made (explode) conform to what maclisp does with opposite-than-normal character-cases. From Ira%UPenn.UPenn@UDel-Relay Fri Jul 8 01:46:25 1983 Date: Thu, 7 Jul 83 22:13 EDT From: Ira Winston Subject: Eliza Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA16294; 8 Jul 83 01:45:43 PDT (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA01687; 8 Jul 83 01:46:25 PDT (Fri) To: [email protected] Via: UPenn; 8 Jul 83 3:07-EDT Status: O Does anyone have a version of Eliza that runs under Franz Lisp? From layer Fri Jul 8 18:04:10 1983 Date: 8 Jul 1983 1804-PDT (Friday) From: layer (Kevin Layer) Subject: lisp opus 38.69 Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA07142; 8 Jul 83 18:04:10 PDT (Fri) Phone: (415) 652-2405 To: local-lisp Cc: layer Status: O 'setf' now knows about 'nthelem', and there are two new functions: (readdir 's_direct) returns a list of the contents of the directory s_direct. (dirp 's_name) returns s_name if s_name is a directory. This doesn't insure that you can read the directory, though (only uses stat(2)). Kevin From layer Fri Jul 8 20:57:13 1983 Date: 8 Jul 1983 2057-PDT (Friday) From: layer (Kevin Layer) Subject: new function readdir Message-Id: Received: by UCBKIM.ARPA (3.340/3.5) id AA00480; 8 Jul 83 20:57:13 PDT (Fri) Phone: (415) 652-2405 To: local-lisp Fcc: record Status: O The function 'readdir' and 'dirp' should not be relied on yet, since they are provisional, because they are implemented with C library functions only available on 4.1+ systems. Kevin From Pwh%GaTech.GATech@UDel-Relay Tue Jul 12 18:08:46 1983 Date: 11 Jul 83 20:36:32-EDT (Mon) From: Subject: Franz flavors? Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA03336; 12 Jul 83 18:07:40 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA20140; 12 Jul 83 18:08:46 PDT (Tue) To: [email protected] Cc: jlk.Gatech@UDel-Relay Via: GATech; 12 Jul 83 2:43-EDT Status: O We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our long awaited Symbolics Lisp Machine up and running and are trying to establish some measure of compatability between Franz and Zeta Lisp (as appropriate). Janet seems to recall some mention of a flavor package for Franz. Is this Berkley based or can anyone provide some clues as to where to check next? Also, when is the next release of Franz scheduled and what features will it incorporate? If the flavor package is non-existent, we will probably be forced to develop one here and will, of course, be glad to pass anything useful along. phil hutto From narain@rand-unix Tue Jul 12 20:10:42 1983 Date: Tuesday, 12 Jul 1983 19:49-PDT From: narain@rand-unix Subject: Re: Franz flavors? Message-Id: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA05908; 12 Jul 83 20:09:41 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA21387; 12 Jul 83 20:10:42 PDT (Tue) To: Cc: [email protected], jlk.Gatech@UDEL-RELAY In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon). Status: O We at Rand are interested in developing a set of guidelines for writing code that will be compatible with each of Zeta- Franz- and PSL Lisps. I would be grateful if you could tell us of what your experiences have been with making Franzlisp code work on the Symbolics machine. We would gladly share our own with you if you wish; incidentally we also have an IJCAI paper on a related issue. -- Sanjai Narain From liz.umcp-cs@UDel-Relay Wed Jul 13 00:55:26 1983 Date: 13 Jul 83 03:09:39 EDT (Wed) From: Liz Allen Subject: Re: Franz flavors? Return-Path: Message-Id: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA10367; 13 Jul 83 00:54:32 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA24477; 13 Jul 83 00:55:26 PDT (Wed) To: pwh.gatech@UDel-Relay, [email protected] Cc: jlk.Gatech@UDel-Relay Via: UMCP-CS; 13 Jul 83 3:23-EDT Status: O Here at the Univ of Maryland, we do have an implementation of flavors in Franz Lisp and have used it successfully in several large systems. It doesn't contain all the features of the Lisp Machine Flavors, but it does implement all the major ones. It is also different in a few ways that are necessitated by the limitations of Franz Lisp (shallow binding without invisible pointers or true closures -- though closures may be in the very newest versions of Franz -- we have opus 38.26). The package uses a hashing scheme for looking up methods, and the function Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35) id AA05735; Thu, 14 Jul 83 11:06:45 PDT Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA13687; 14 Jul 83 11:07:57 PDT (Thu) Apparently-To: Status: O I am interested in obtaining a GOOD random number generator that is callable from Franz. My only real requirements are that it accept a seed (so that I can duplicate the same series), is fairly good (try doing several (random 4)'s in Franz and see what you get), and is of intermediate speed. If you know of such an animal please send me mail telling me how to get it. thanks From kanderso@bbn-vax Thu Jul 14 12:49:58 1983 Date: 14 Jul 1983 15:47:19 EDT (Thursday) From: Ken Anderson Subject: Random numbers Message-Id: Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35) id AA06936; Thu, 14 Jul 83 12:48:49 PDT Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA15607; 14 Jul 83 12:49:58 PDT (Thu) To: [email protected] Cc: Malcolm.McRoberts@CMU-RI-ISL Status: O Here is a random number generator i use. It seems to work fairly well, but i have not looked to closely at the statistics. Since it will occasionally require bignums, it is probably not the fastest either. I was just looking for something that was likely to be portable between LISP's. I would be very interested in hearing your evaluation of it. k ;;; RANDOM NUMBERS (declare (macros t)) (include math.h) (defvar $uniform-a 16807) ; = 7^5 (defvar $mersenne-prime 2147483647) ; = 2^31 - 1 (defvar $mersenne-prime-1 (- $mersenne-prime 1)) (defmacro with-seed (s-newseed . body) ; evaluates body with the seed of the random numbers set to s-newseed. ; the value of s-newseed is updated. Thus this is a way of ; Keepining several sequences of random numbers with their own seeds `(let (($uniform-seed ,s-newseed)) (prog1 (progn ,@body) (setq ,s-newseed $uniform-seed)))) (defun uniform-basic (previous-fixnum) ; -> a fixnum 0 2^31 - 2. ; The basic idea is new = A^k * old (mod p) ; where A is a primitive root of p, k is not a factor of p-1 ; and p is a large prime. ; This is a good random number generator but is not be the fastest! ; On FRANZ LISP, and LISP MACHINE it will require bignums since ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder ; can be done more efficiently. ; See: Linus Schrage, A More Portable Fortran Random Number Generator, ; ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979. (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime)) (defvar $uniform-seed 53) ; 0 the next uniform random number in the sequence ; To have your own sequence, rebind $uniform-seed. (setq $uniform-seed (uniform-basic $uniform-seed))) (defun uniform-between (low-num high-num) ; -> a uniform random number, x, low-num a gaussian random variable with mean 0.0 and ; standard deviation 1.0. ; Good tails. (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0)))) (sin (*$ $2pi (uniform-between 0.0 1.0))))) (defun gaussian-random (mean standard-deviation) (+$ mean (*$ (gaussian-random-1) standard-deviation))) ;;(defun gaussian (x) ;; (* (sqrt $2pi) ;; (exp (minus (// (square x) 2.0))))) (defun random-yes-no (fraction-yes) ( Received: by UCBKIM.ARPA (3.340/3.5) id AA19498; 30 Jul 83 15:46:42 PDT (Sat) Phone: (415) 652-2405 To: local-lisp Status: O Vset is now open coded. There should be no visible change in the behaviour of vectors, except in speed (greater, that is), and vsize-{byte,word} work properly now. Bugs to me. Kevin From jkf Mon Aug 1 14:41:28 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA03743; Mon, 1 Aug 83 14:41:28 PDT Date: Mon, 1 Aug 83 14:41:28 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: defstruct Status: O defstruct now understands two more types of structures: :vector :named-vector A named vector has the defstruct structure name on the vector property list, thus an instance of the foo structure would print as 'foo[8]'. :named-vector is now the default structure type (instead of :hunk). From jkf Tue Aug 2 15:20:04 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA26686; Tue, 2 Aug 83 15:20:04 PDT Date: Tue, 2 Aug 83 15:20:04 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: lisp opus 38.70 Status: RO When a vector is printed, the size in square brackets will be the number of entries (not the number of bytes). The size printed for vectori objects will continue to be the number of bytes. Also, if the property of a vector is a list with the car being a non nil symbol, and if that list doesn't have a print property, then that symbol will be printed rather than 'vector' or 'vectori'. From layer Thu Aug 4 02:10:12 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA11660; Thu, 4 Aug 83 02:10:12 PDT From: layer (Kevin Layer) Phone: (415) 652-2405 Date: 4 Aug 1983 0210-PDT (Thursday) Message-Id: To: local-lisp Subject: liszt opus 8.34 Status: RO I just installed a new compiler. For the vax, there shouldn't be any visible changes, though a couple of vector bugs were fixed. For the 68000, the vector access functions are now open coded, and the new one was installed on mike, rob, and chip in /usr/ucb. Kevin From FRD@SU-AI Fri Aug 5 15:57:17 1983 Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2) id AA10610; Fri, 5 Aug 83 15:57:17 PDT Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35) id AA10357; Fri, 5 Aug 83 15:54:22 PDT Message-Id: Date: 05 Aug 83 1353 PDT From: Fred Lakin Subject: Franz & SUNs To: franz-friends@BERKELEY Status: RO I am interested in connectons between Franz and SUN workstations. Like how far along is Franz on the SUN? Is there some package which allows Franz on a VAX to use a SUN as a display device? Any info on this matter would be appreciated. Thnaks, Fred Lakin From tektronix!ogcvax!metheus!tombl Sat Aug 6 09:49:57 1983 Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2) id AA21229; Sat, 6 Aug 83 09:49:57 PDT Received: by UCBVAX.ARPA (3.347/3.35) id AA13549; Sat, 6 Aug 83 09:40:11 PDT Message-Id: From: ogcvax!metheus!tombl To: ogcvax!tektronix!ucbvax!franz-friends Cc: ogcvax!tektronix!ucbvax!sklower Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT Subject: bug in Opus 38.66 Date: Fri Aug 5 20:46:56 1983 Status: O A bug present in previous versions is also present in 38.66 of Franz. cfasl fails (in most cases) to close the file it reads from. Consequently, mysterious events occur when the maximum number of open file descriptors is reached. The fix is made in the file ffasl.c. "close(fildes)" should be prepended to the two return sequences from (the Unix code for) Lcfasl: ------------------------------------------------------------------ Old: 146c146 {close(fildes); Restorestack(); return(nil);} 149a150 > close(fildes); ------------------------------------------------------------------ Tom Blenko Metheus Corp. ucbvax!tektronix!ogcvax!metheus!tombl allegra!ogcvax!metheus!tombl From FRD@SU-AI Sun Aug 7 12:34:43 1983 Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2) id AA10610; Fri, 5 Aug 83 15:57:17 PDT Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35) id AA10357; Fri, 5 Aug 83 15:54:22 PDT Message-Id: Date: 05 Aug 83 1353 PDT From: Fred Lakin Subject: Franz & SUNs To: franz-friends@BERKELEY Status: O I am interested in connectons between Franz and SUN workstations. Like how far along is Franz on the SUN? Is there some package which allows Franz on a VAX to use a SUN as a display device? Any info on this matter would be appreciated. Thnaks, Fred Lakin From jkf Mon Aug 8 09:06:49 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA06584; Mon, 8 Aug 83 09:06:49 PDT Date: Mon, 8 Aug 83 09:06:49 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: opus 38.72 Status: O A bug was fixed in defmacro which caused the &protect option and displace-macros to interact poorly. From jkf Fri Aug 12 22:11:13 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA25610; Fri, 12 Aug 83 22:11:13 PDT Date: Fri, 12 Aug 83 22:11:13 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: opus 38.73 Status: O 'equal' will now compare all types of vectors for equality. 'copy' will now copy all types of vectors. From layer Mon Aug 15 20:03:53 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA03597; Mon, 15 Aug 83 20:03:53 PDT From: layer (Kevin Layer) Phone: (415) 652-2405 Date: 15 Aug 1983 2003-PDT (Monday) Message-Id: To: local-lisp Subject: liszt opus 8.35 Fcc: record Status: RO Several things have changed: 1) Bugs in the open coding of vectors have been fixed. 2) Minor re-organization of the compiler source code. 3) The routine to determine whether or not tail merging is possible underwent major modification. 4) Lexpr's are compiled differently, or rather the way lexpr args are accessed has changed. For those that want to know, here is the nitty gritty: Consider a the following lexpr: (defun test nargs ...). The arguments to the lexpr are stacked on the name stack (low to high number), and then nargs is stacked. The user is allowed to change the binding of 'nargs' to anything he likes, so we have to have another way to access the arguments on the name stack (i.e., other than an offset from nargs). Before, a pointer to the argument base was pushed on the C stack, so that indexing could be done from there. The addressing modes used to do this are not available on the MC68000 (something like *n(fp)[Rx]), so now nargs is pushed on the name stack twice, and the location of an argument can be easily calculated as an offset from nargs. In short, lots of thing changed. The SUN's should be updated in the next couple of days (after I test it out). Bugs to me... Kevin From jkf Mon Aug 15 23:11:08 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA05928; Mon, 15 Aug 83 23:11:08 PDT Date: Mon, 15 Aug 83 23:11:08 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: opus 38.74 Status: O If a vector has a 'unique' property on it's property list, then it will not be copied by 'copy'. 'untrace' will now autoload /usr/lib/lisp/trace. A number of functions and macros were contributed by the bair group: ( 'fx_arg1 'fx_arg2) [or (>& 'x_arg1 'x_arg2)] is nil, otherwise nil. The general function, = 'fx_arg1 'fx_arg2) (>=& 'x_arg1 'x_arg2) RETURNS: t iff (=, can take more than two arguments. (litatom 'g_arg) RETURNS: t iff g_arg is an atom, but not a number. (nequal 'g_x 'g_y) RETURNS: t iff g_x is not equal to g_y, otherwise nil. (lineread [['p_port] ['s_flag]]) RETURNS: a list consisting of s-expressions on a line from the port p_port (or piport if p_port is not given). If an s-expression (e.g., a list) takes more than one line, or a line terminates in a space or tab, then lineread continues reading until an expression ends at the end of a line. NOTE: If s_flag is t, then if the first character on a line is a newline, lineread performs a tyi and returns nil. If s_flag is nil or not present, lineread does a read skipping over any blank lines to make sure that an s-expression is actu- ally read. SIDE EFFECT: lineread uses read, advancing the port character pointer. 9 9 (defv g_arg1 g_arg2) EQUIVALENT TO: (set g_arg1 g_arg2) (pp-form 'g_form ['p_port] ['n_lmar]) RETURNS: nil SIDE EFFECT: g_form is pretty-printed to the port p_port (or poport if p_port is not given). If pp-form is also supplied with an integer (n_lmar), that integer will be used as a left margin setting (0 is the default). This is the function which pp uses (n_lmar = 0). pp-form does not look for function definitions or values of variables, it just prints out the form it is given. NOTE: This is useful as a top-level-printer, c.f. top- level in Chapter 6. (sload 's_file1 ...) SIDE EFFECT: The files named are opened for reading and each form is read, optionally printed, and evaluated. NOTE: What sload prints is controlled by the special atom $sldprint. If $sldprint is t (default), then if a form is recognizable as a function definition, only the function name is printed, otherwise the whole form is printed. If $sldprint is eq to value, then the result of each form's evaluation will also be printed. Printing the forms' values can be controlled by setting sload-print equal to the name of the function to be called. sload recognizes named functions by looking at the sloadprintarg property of the function name. The value of the sloadprintarg property should be the argument number of the function name. For the standard Franz Lisp func- tions, the properties are already set. EXAMPLE: (defprop def 1 sloadprintarg) ; This is the default--declaring that ; the name of the function definition is the ; first argu- ment. 9 9 The functions described below are an alternative to the gensym facility. They generate new symbols by attaching counter numbers to the ends of the symbols' names. An example follows of how the functions are used. ____________________________________________________ -> (initsym joe (john 5)) ; initializing new symbol counters (joe0 john5) -> (newsym john) ; create a new symbol john6 -> (newsym chuck) ; symbol need not be initsym'ed chuck0 -> (oldsym john) ; get current symbol john6 -> (allsym john) ; get all symbols between 0 and counter (john0 john1 john2 john3 john4 john5 john6) -> (allsym (john 5)) ; get all symbols between 5 and counter (john5 john6) -> (remsym joe (john 4)) ; remob all interned symbols ; associated with joe and from ; john4 to the current john ; symbol--returns symbols with symbol counters ; before doing remsym (joe0 john6) -> (symstat joe john) ((joe nil) (john 3)) ____________________________________________________ (initsym g_arg1 ...) WHERE: g_argi is a list (n_counteri s_argi) or a string s_argi (which is equivalent to (0 s_argi)). RETURNS: a list of interned identifiers using the sym- bol counters n_counteri, i.e., the result of concatenating s_argi to n_counteri. EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5) NOTE: See also newsym, oldsym, allsym, remsym, and sym- stat functions. 9 9 (newsym s_arg) RETURNS: an interned identifier formed by concatenating the name s_arg to the symbol counter for s_arg. The symbol counter is stored on the property list of s_arg under symctr. If there is no counter, a counter of 0 is used and added to the property list. Thus, a symbol need not be initsymed. EXAMPLE: (initsym joe (john5)) ==> (joe0 john5) (newsym john) ==> john6 (newsym joe) ==> joe1 NOTE: See also initsym, oldsym, allsym, remsym, and symstat functions. (oldsym s_arg) RETURNS: the identifier using the current symbol counter for s_arg, rather than creating a new identifier. If no symbol counter exists for s_arg, then s_arg is returned. NOTE: See also initsym, newsym, allsym, remsym, and symstat functions. (allsym g_arg) WHERE: g_arg is a list (s_arg n_counter) or a string s_arg (equivalent to (s_arg 0)). RETURNS: a list of all the created identifiers between n_counter and the current symbol counter for s_arg. EXAMPLE: (allsym john) ==> (john0 john1 john2) NOTE: See also initsym, newsym, oldsym, remsym, and symstat functions. (remsym g_arg1 ...) WHERE: g_argi is a list (s_argi n_counteri) or a string s_argi (which is equivalent to (s_argi 0)). RETURNS: a list of symbols s_argi with the current sym- bol counters. SIDE EFFECT: remsym remob's all the created identifiers between zero and the current symbol counter for s_argi. NOTE: See also initsym, newsym oldsym, allsym, and sym- stat functions. (symstat s_arg1 ...) RETURNS: a list of pairs consisting of (s_argi symctri) where symctri is s_argi's current symbol counter. NOTE: See also initsym, newsym, oldsym, allsym, and remsym functions. 9 9 From jkf Thu Aug 18 19:25:45 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA09885; Thu, 18 Aug 83 19:25:45 PDT Date: Thu, 18 Aug 83 19:25:45 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: opus 38.75 Status: O evalhook and funcallhook can now be executed without setting (*rset t) and (sstatus evalhook t). Although they can be executed, they won't have any effect unless and until (*rset t) and (sstatus evalhook t) are done. The reason for this change is that now one can turn off stepping by (sstatus evalhook nil) and then continue the evaluation with evalhook and funcallhook. Those who use the new top-level 'tpl' will notice a few new commands dealing with stepping when you type '?help'. These new commands are ?step, ?soff, and ?sc. Details of the commands are available using the help mechanism (e.g. '?help step'). From jkf Fri Aug 19 13:54:26 1983 Received: by ucbkim.ARPA (4.2/4.2) id AA20017; Fri, 19 Aug 83 13:54:26 PDT Date: Fri, 19 Aug 83 13:54:26 PDT From: jkf (John Foderaro) Message-Id: To: local-lisp Subject: liszt 8.36 Status: O The compiler will now compile the form (*no-macroexpand*