From jkf Tue Apr 13 00:12:22 1982 To: /na/doe/jkf/lispnews Subject: new features Status: RO In response to requests from franz users, these enhancements have been made: In Lisp 38.07, if the lisp variable 'displace-macros' is set to non-nil, then when a macro expansion is done by the evaluator, the resulting expansion replaces the original call. This means that macro expansion is only done once. In Liszt 8.03, the 'function' function is open coded. If you have (function (lambda ....)) in your code then the lambda expression is compiled as a separate function and the result of the function call is a 'bcd' object which points to that compiled lambda. From jkf Sun Apr 18 13:16:46 1982 To: local-lisp Subject: opus 38.09 Status: RO The new features of this version are: If the load function ends up fasl'ing in a file, then load will do what is necessary to insure that the new functions are linked in correctly. Previously, if you turned on the transfer tables with (sstatus translink on) or (sstatus translink t) and then fasl'ed in functions which already existed, the old versions of the functions would still be used, unless you did (sstatus translink on) yourself. Now this is done automatically. tyi now accepts a second argument which is the object to return upon eof. -1 is the default. (pp-form 'g_obj ['p_port]) should be used instead of $prpr for pretty printing a form. The storage allocator and collector has been modified to add two new data types: vector and vector immediate. They are not in their final form so I suggest that you not try to use them. However, be on the lookout for garbage collection bugs. From jkf Wed Apr 21 07:45:54 1982 To: local-lisp Subject: liszt 8.04 Status: RO the new features of liszt 8.04 are: 1) init files: Before liszt begins compiling, it looks for an init file to load in. It first searches in the current directory, and then it searches your home directory (getenv 'HOME). It looks for file names: .lisztrc.o .lisztrc.l lisztrc.o lisztrc.l It loads only the first one it finds. 2) interrupt handling If you interrupt liszt (with ^C typically), it will remove its temporary file and exit. 3) preallocation of space It preallocates space in order to reduce the number of gc's done during compiling. From jkf Wed Apr 21 13:47:50 1982 To: local-lisp Subject: lisp opus 38.10 Status: RO lisp will now look for a lisprc in a way similar to liszt. It will first search in . and then in $HOME It will look for the file .lisprc or lisprc ending with .o, .l and then just .lisprc or lisprc. Shortly, it will only look for files ending in .l and .o since we don't want to encourage files with non-standard filename extensions. From jkf Wed Apr 21 23:40:59 1982 To: local-lisp Subject: lisp opus 38.11 Status: RO I finally got sick of showstack and baktrace and rewrote them in lisp, rincorporating some of the features people have been requesting. Showstack now works as follows: (showstack) : show all interesting forms. Forms resulting from the trace package are not printed as well as extraneous calls to eval. In the form printed, the special form <**> 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: <8208141553.9999@UCBKIM.BERKELEY.ARPA> 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: <8209022215.10796@UCBKIM.BERKELEY.ARPA> 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: <8209040228.9829@UCBKIM.BERKELEY.ARPA> 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: <8209060401.6358@UCBKIM.BERKELEY.ARPA> 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: <8209081955.4140@UCBKIM.BERKELEY.ARPA> 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: <8209121744.29800@UCBKIM.BERKELEY.ARPA> 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: <8209122135.5086@UCBKIM.BERKELEY.ARPA> 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: <8209200154.195@UCBKIM.BERKELEY.ARPA> 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: <8209200550.3968@UCBKIM.BERKELEY.ARPA> 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: <8209222246.5610@UCBKIM.BERKELEY.ARPA> 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: <8209231558.21572@UCBKIM.BERKELEY.ARPA> 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 << and >> which get and set instance variables, eg: (<< foo 'instance-var) and (>> 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: <8209251956.17542@UCBKIM.BERKELEY.ARPA> 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: <8209252157.21567@UCBKIM.BERKELEY.ARPA> 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: <8209260537.1666@UCBKIM.BERKELEY.ARPA> 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: <8209261620.11552@UCBKIM.BERKELEY.ARPA> 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: <8209280335.27561@UCBKIM.BERKELEY.ARPA> 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: <8209291634.8411@UCBKIM.BERKELEY.ARPA> 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: <8209291711.9176@UCBKIM.BERKELEY.ARPA> 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: <8209291906.12141@UCBKIM.BERKELEY.ARPA> 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: <8210032349.16460@UCBKIM.BERKELEY.ARPA> 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: <8210041819.24539@UCBARPA.BERKELEY.ARPA> 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: <8210140453.490@UCBKIM.BERKELEY.ARPA> 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: <8210301721.11699@UCBKIM.BERKELEY.ARPA> 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: <8210301842.13143@UCBKIM.BERKELEY.ARPA> 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: <8211011713.3615@UCBKIM.BERKELEY.ARPA> 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: <8211021604.14414@UCBKIM.BERKELEY.ARPA> 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: <8211061650.12951@UCBKIM.BERKELEY.ARPA> 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: <8211131835.12160@UCBKIM.BERKELEY.ARPA> 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: <8211142040.10379@UCBKIM.BERKELEY.ARPA> 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: <8300102304.19240@UCBKIM.BERKELEY.ARPA> 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: <8300110346.24831@UCBKIM.BERKELEY.ARPA> 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: <8300121703.1981@UCBKIM.BERKELEY.ARPA> 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: <8300122225.13079@UCBKIM.BERKELEY.ARPA> 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: <8300131749.331@UCBKIM.BERKELEY.ARPA> 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: <83/01/13 2024.733@Vax-Populi> 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: <83/01/13 2001.733@Vax-Populi> 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: <8300170522.23656@UCBKIM.BERKELEY.ARPA> 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: <8300190043.10935@UCBKIM.BERKELEY.ARPA> 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: <8300200955.17788@UCBKIM.BERKELEY.ARPA> 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: <8300210342.7334@UCBKIM.BERKELEY.ARPA> 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: <8300210457.8824@UCBKIM.BERKELEY.ARPA> 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: <8300211611.18650@UCBKIM.BERKELEY.ARPA> 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: <8300230037.1747@UCBVAX.BERKELEY.ARPA> 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: <8300230138.20020@UCBKIM.BERKELEY.ARPA> 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: <8300241825.19602@UCBVAX.BERKELEY.ARPA> 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: <8300250008.58@UCBVAX.BERKELEY.ARPA> 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:Tim@UPenn.UPenn Tue Jan 25 16:29:19 1983 Date: 25 Jan 1983 9:58-EST From: Tim Finin Subject: emacs interface to franz? Message-Id: <8300260022.29320@UCBVAX.BERKELEY.ARPA> 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: <8300281615.20646@UCBVAX.BERKELEY.ARPA> 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: <8300281634.17319@UCBKIM.BERKELEY.ARPA> 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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> 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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> 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: <8300281634.17319@UCBKIM.BERKELEY.ARPA> 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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> 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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> 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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> 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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> 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: <8301011832.599@UCBKIM.BERKELEY.ARPA> 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: <8301021325.221@UCBVAX.BERKELEY.ARPA> 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: mike@RAND-UNIX.ARPA 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 <8300250008.58@UCBVAX.BERKELEY.ARPA> Via: UMCP-CS; 25 Jan 83 20:45-EST We have a few franz<->emacs 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: <412526661/ce@CMU-CS-VLSI> 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: <8301021614.25937@UCBKIM.BERKELEY.ARPA> 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: <8301110545.16021@UCBKIM.BERKELEY.ARPA> 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: <8301112302.7475@UCBVAX.BERKELEY.ARPA> 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: <8302141531.27879@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8302141052.25792@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <13Feb83 003422 MS40@CMU-CS-A> 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: <8302190504.26020@UCBVAX.ARPA> 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: FRANZ-FRIENDS@BERKELEY.ARPA 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: <8302211719.2798@UCBKIM.ARPA> 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, FRANZ-FRIENDS@BERKELEY.ARPA 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: <8302251628.528@UCBKIM.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8303060412.18927@UCBKIM.ARPA> 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: <8303081401.AA13004@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8303081710.9423@UCBKIM.ARPA> 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: <8303091754.14754@UCBKIM.ARPA> 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: <8303200144.25091@UCBKIM.ARPA> 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: <8303230452.5935@UCBKIM.ARPA> 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: <8303241629.6735@UCBKIM.ARPA> 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: <8303242300.11144@UCBKIM.ARPA> 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: <8303261137.AB02371@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8303261646.2453@UCBKIM.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304041711.AA07020@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304052042.AA26557@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304052108.16969@UCBKIM.ARPA> 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: <8304071549.AA13873@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304110350.6176@UCBKIM.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304111442.11378@UCBKIM.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8304221759.20996@UCBKIM.ARPA> 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: <8305080702.22344@UCBKIM.ARPA> 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: <8305211434.AA16172@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8305251915.1144@UCBKIM.ARPA> 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: <8305251950.AA02600@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8305252032.2716@UCBKIM.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <1983.05.27.18.18.47.150.08942@dione.rice> 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: franz-friends@BERKELEY.ARPA 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: <8305311747.AA10893@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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 lbl-csam!steve@ssc-vax.UUCP Tue May 31 19:31:04 1983 Date: 31 May 83 17:28:35 PDT (Tue) From: ssc-vax!steve@lbl-csam.UUCP Subject: packages Message-Id: <8306010028.AA16451@LBL-CSAM.ARPA> 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: ucbvax!franz-friends@lbl-csam.UUCP 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: <8306141848.6756@UCBKIM.ARPA> 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: <8306151742.20591@UCBKIM.ARPA> 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: <8306142214.AA16599@UCBVAX.ARPA> 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: <8306161646.AA25470@UCBVAX.ARPA> 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: <8306192243.19626@UCBKIM.ARPA> 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: <8306200547.23164@UCBKIM.ARPA> 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: <8306200553.AA15160@UCBVAX.ARPA> 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: <8306210509.AA00276@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8306212152.AA12930@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8306252049.25527@UCBKIM.ARPA> 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: <5390.30.426237985@ucbkim> 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: <8307060702.24776@UCBKIM.ARPA> 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: <8307070727.10697@UCBKIM.ARPA> 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: <8307080845.AA16294@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <7031.30.426560643@ucbkim> 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: <465.30.426571029@ucbkim> 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: <8307130107.AA03336@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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: <8307130309.AA05908@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA, jlk.Gatech@UDEL-RELAY In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon). <8307130107.AA03336@UCBVAX.ARPA> 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: <8307130754.AA10367@UCBVAX.ARPA> 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, franz-friends@BERKELEY.ARPA 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 <- which is used to send a message to an object is written in C. Together, this makes it an efficient implementation. We are currently working on a new policy for distributing flavors, our other lisp packages and our window package. When we have worked it out, I will announce the details here. -Liz From @MIT-MC:mdm@cmu-ri-isl Thu Jul 14 11:07:57 1983 Date: 14 Jul 1983 14:03:01-EDT From: Malcolm.McRoberts@CMU-RI-ISL Subject: random numbers Message-Id: <8307141806.AA05735@UCBVAX.ARPA> 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: <8307141948.AA06936@UCBVAX.ARPA> 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: franz-friends@BERKELEY.ARPA 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 < fixnum < 2^31 - 1 ; Repeated calls will generate fixnums in the range ; 1 -> 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 < fixnum < $mersenne-prime-1 (defun uniform () ; -> 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 <= x <= high-num ; If low-num and high-num are fixnums, a fixnum is returned. (cond ((not (and (fixp low-num) (fixp high-num))) (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1)) (-$ high-num low-num)))) (t (+ low-num (// (uniform) (// $mersenne-prime-1 (max 1 (- high-num low-num -1)))))))) (defun gaussian-random-1 () ; -> 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) (<= (uniform-between 0.0 1.0) fraction-yes)) From layer Sat Jul 30 15:46:42 1983 Date: 30 Jul 1983 1546-PDT (Saturday) From: layer (Kevin Layer) Subject: liszt opus 8.33 Message-Id: <19472.30.428453197@ucbkim> 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: <8308012141.AA03743@ucbkim.ARPA> 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: <8308022220.AA26686@ucbkim.ARPA> 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: <11649.30.428836207@ucbkim> 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: <8308052254.AA10357@UCBVAX.ARPA> 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: <8308061640.AA13549@UCBVAX.ARPA> 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 < {Restorestack(); return(nil);} --- Fixed: > {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: <8308052254.AA10357@UCBVAX.ARPA> 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: <8308081606.AA06584@ucbkim.ARPA> 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: <8308130511.AA25610@ucbkim.ARPA> 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: <3556.30.429851029@ucbkim> 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: <8308160611.AA05928@ucbkim.ARPA> 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 ...) (<=& 'x_arg1 'x_arg2) RETURNS: t iff (> 'fx_arg1 'fx_arg2) [or (>& 'x_arg1 'x_arg2)] is nil, otherwise nil. The general function, <=, can take more than two argu- ments. (>= 'fx_arg1 'fx_arg2) (>=& 'x_arg1 'x_arg2) RETURNS: t iff (< 'fx_arg1 'fx_arg2 ...) [or (<& 'x_arg1 'x_arg2)] is nil, otherwise nil. NOTE: The general function, >=, 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: <8308190225.AA09885@ucbkim.ARPA> 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: <8308192054.AA20017@ucbkim.ARPA> To: local-lisp Subject: liszt 8.36 Status: O The compiler will now compile the form (*no-macroexpand*
) in a special way: if is a function call, e.g. (name arg1 ...), then any macro properties of 'name' will be ignored for this invocation. This permits one to write macros which attempt an optimization, and if that fails, then call the standard function. *no-macroexpand* is not a function that can be called, thus forms with *no-macroexpand* are likely to be 'cmacros'. Here is an example: (defcmacro length (x &protect (x)) `(if (null ,x) then 0 elseif (null (cdr ,x)) then 1 else (*no-macroexpand* (length ,x)))) [in case you are wondering, the `&protect (x)' means that should the actual argument to 'length' be a non atom, defcmacro will lambda bind the value, insuring that it is only evaluated once] From layer Wed Aug 24 22:18:34 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA12256; Wed, 24 Aug 83 22:18:34 PDT From: layer (Kevin Layer) Phone: (415) 652-2405 Date: 24 Aug 1983 2218-PDT (Wednesday) Message-Id: <12219.30.430636709@ucbkim> To: local-lisp Subject: liszt on kim Status: O The liszt that I installed on kim yesterday, compiled eq's wrong in some rare cases. I installed a new one this evening that fixes this, but if you compiled any programs with the bad one, you might consider re-compiling them... Kevin From fateman Thu Aug 25 13:58:59 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA21033; Thu, 25 Aug 83 13:58:59 PDT Date: Thu, 25 Aug 83 13:58:59 PDT From: fateman (Richard Fateman) Message-Id: <8308252058.AA21033@ucbkim.ARPA> To: local-lisp Status: O I have a copy of the latest Common Lisp manual... the Excelsior Edition. From patel@UCLA-LOCUS Tue Aug 30 21:58:38 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA29417; Tue, 30 Aug 83 21:58:38 PDT Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4) id AA06203; Tue, 30 Aug 83 21:50:26 PDT Message-Id: <8308310450.AA06203@ucbvax.ARPA> Date: Tue, 30 Aug 83 21:44:13 PDT From: Dorab Patel To: franz-friends@BERKELEY Subject: bug fix for 'insert' in opus 38.50 Status: O The function 'insert' in Opus 38.50 does not perform as advertised in the manual if the last argument is non-nil (i.e. if no duplicates are allowed. It still insists on putting the duplicate element into the list. The fix is in /usr/lib/lisp/common2.l. Just change the default setting of the 'comparefn' to that given below instead of (function alphalessp). Here is an excerpt from the modified file. [.....] (def insert (lambda (x l comparefn nodups) (cond ((null l) (list x)) ((atom l) (error "an atom, can't be inserted into" l)) (t (cond ((null comparefn) (setq comparefn (function (lambda (x y) (or (alphalessp x y) (equal x y))))))) (prog (l1 n n1 y) (setq l1 l) (setq n (length l)) a (setq n1 (/ (add1 n) 2)) (setq y (Cnth l1 n1)) [..........] From jkf Sun Sep 4 09:59:01 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA03721; Sun, 4 Sep 83 09:59:01 PDT Date: Sun, 4 Sep 83 09:59:01 PDT From: jkf (John Foderaro) Message-Id: <8309041659.AA03721@ucbkim.ARPA> To: local-lisp Subject: opus 38.77 Status: O The 'error' function used to print its arguments and then call 'err' to cause the familar 'call to err' error. The problem with this is that even if you wrap your compuatation with (errset ... nil), the error message will still be printed. In opus 38.77, this problem has been fixed. A new function was added: (err-with-message 'st_message ['g_value]) This causes an error to be signaled with the given message. The message will only be printed if an '(errset ... nil)' isn't being executed. Normally nil is returned from an errset if an error occured. If you provide g_value, then it will be returned from the errset. [Not surprisingly, 'error' now uses 'err-with-message'] Also, 'error' now takes any number of arguments. In concatenates them, separated by spaces, and this is the error message passed to err-with-message. From narain@rand-unix Fri Sep 9 13:32:24 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA16481; Fri, 9 Sep 83 13:32:24 PDT Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7) id AA11010; Fri, 9 Sep 83 13:31:58 PDT Message-Id: <8309092031.AA11010@ucbvax.ARPA> Date: Friday, 9 Sep 1983 10:55-PDT To: franz-friends@BERKELEY Cc: narain@rand-unix Subject: Franzlisp Question From: narain@rand-unix Status: O Hello all: I would be grateful if you could answer another question regarding Franzlisp. How does one make Franzlisp continue from an error? For example when Lisp gives an error message like "x unbound variable", is it possible to bind x to a value and make Lisp continue from that point? Right now we have to start over again and it is very time consuming. -- Sanjai From AUSTIN@DEC-MARLBORO.ARPA Fri Sep 9 13:46:45 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA16843; Fri, 9 Sep 83 13:46:45 PDT Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7) id AA11248; Fri, 9 Sep 83 13:46:26 PDT Date: 9 Sep 1983 1427-EDT From: AUSTIN@DEC-MARLBORO To: FRANZ-FRIENDS@BERKELEY Subject: LIST MEMBERSHIP Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO> Status: O PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION. MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO. THANKS! -------- From jkf Sat Sep 10 12:34:14 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA28421; Sat, 10 Sep 83 12:34:14 PDT Date: Sat, 10 Sep 83 12:34:14 PDT From: jkf (John Foderaro) Message-Id: <8309101934.AA28421@ucbkim.ARPA> To: local-lisp Subject: opus 38.78 Status: O The new functions contributed by the bair group dealing with symbol creation have been changed from fexprs to exprs (lambdas) and lexprs. The new documentation follows: 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 exam- ple 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. (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. From jkf@ucbkim Wed Sep 14 08:04:14 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA14801; Wed, 14 Sep 83 08:04:14 PDT Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA04212; Wed, 14 Sep 83 08:03:58 PDT Received: by ucbkim.ARPA (4.6/4.2) id AA14786; Wed, 14 Sep 83 08:03:43 PDT Date: Wed, 14 Sep 83 08:03:43 PDT From: jkf@ucbkim (John Foderaro) Message-Id: <8309141503.AA14786@ucbkim.ARPA> To: franz-friends@BERKELEY Subject: lisp distribution Status: O A number of you have noticed that ftp'ing the lisp distribution from ucb-vax can be slow at times. As a result, we've made 'ucb-arpa' the primary distribution machine. You can ftp from ucb-arpa using an anonymous login (with your name as password). The files are in the pub/lisp subdirectory. john foderaro From liz%umcp-cs@UDel-Relay Mon Sep 26 19:41:37 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA24055; Mon, 26 Sep 83 19:41:37 PDT Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7) id AA07367; Mon, 26 Sep 83 16:28:58 PDT Message-Id: <8309262328.AA07367@ucbvax.ARPA> Date: 26 Sep 83 15:22:00 EDT (Mon) From: Liz Allen Return-Path: Subject: Maryland software distribution To: franz-friends@BERKELEY Via: UMCP-CS; 26 Sep 83 17:46-EDT Status: O This is to announce the availability of the Univ of Maryland software distribution. This includes source code for the following: 1. The flavors package written in Franz Lisp. This package has been used successfully in a number of large systems at Maryland, and while it does not implement all the features of Lisp Machine Flavors, the features present are as close to the Lisp Machine version as possible within the constraints of Franz Lisp. (Note that Maryland flavors code *can* be compiled.) 2. Other Maryland Franz hacks including the INTERLISP-like top level, the lispbreak error handling package, the for macro and the new loader package. 3. The YAPS production system written in Franz Lisp. This is similar to OPS5 but more flexible in the kinds of lisp expressions that may appear as facts and patterns (sublists are allowed and flavor objects are treated atomically), the variety of tests that may appear in the left hand sides of rules and the kinds of actions may appear in the right hand sides of rules. In addition, YAPS allows multiple data bases which are flavor objects and may be sent messages such as "fact" and "goal". 4. The windows package in the form of a C loadable library. This flexible package allows convenient management of multiple contexts on the screen and runs on ordinary character display terminals as well as bit-mapped displays. Included is a Franz lisp interface to the window library, a window shell for executing shell processes in windows, and a menu package (also a C loadable library). You should be aware of the fact that the lisp software is based on Franz Opus 38.26 and that we will be switching to the newer version of lisp that comes with Berkeley 4.2 whenever that comes out. --------------------------------------------------------------------- To obtain the Univ of Maryland distribution tape: 1. Fill in the form below, make a hard copy of it and sign it. 2. Make out a check to University of Maryland Foundation for $100, mail it and the form to: Liz Allen Univ of Maryland Dept of Computer Science College Park MD 20742 3. If you need an invoice, send me mail, and I will get one to you. Don't forget to include your US Mail address. Upon receipt of the money, we will mail you a tape containing our software and the technical reports describing the software. We will also keep you informed of bug fixes via electronic mail. --------------------------------------------------------------------- The form to mail to us is: In exchange for the Maryland software tape, I certify to the following: a. I will not use any of the Maryland software distribution in a commercial product without obtaining permission from Maryland first. b. I will keep the Maryland copyright notices in the source code, and acknowledge the source of the software in any use I make of it. c. I will not redistribute this software to anyone without permission from Maryland first. d. I will keep Maryland informed of any bug fixes. e. I am the appropriate person at my site who can make guarantees a-d. Your signature, name, position, phone number, U.S. and electronic mail addresses. --------------------------------------------------------------------- If you have any questions, etc, send mail to me: -Liz Allen, U of Maryland, College Park MD Usenet: ...!seismo!umcp-cs!liz Arpanet: liz%umcp-cs@Udel-Relay From fateman Thu Sep 29 14:50:17 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA10806; Thu, 29 Sep 83 14:50:17 PDT Date: Thu, 29 Sep 83 14:50:17 PDT From: fateman (Richard Fateman) Message-Id: <8309292150.AA10806@ucbkim.ARPA> To: franz-friends Subject: survey Cc: fateman Status: O I am trying to collect some statistics on usage of Franz. I would like to get answers to these questions: (1) Your location: (2) The number of computers at your location (actively) running Franz: (3) Have you produced a locally modified manual? (y/n) (4) Are other Lisps in use there? (names?) (5) Do you use Franz for instruction? research? (6) Are you distributing or selling packages "on top of" Franz? (You may also send comments you wish; I will compile results and redistribute, so please do not respond to "franz-friends", but to me.) Thanks. From jkf Thu Sep 29 23:04:29 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA04355; Thu, 29 Sep 83 23:04:29 PDT Date: Thu, 29 Sep 83 23:04:29 PDT From: jkf (John Foderaro) Message-Id: <8309300604.AA04355@ucbkim.ARPA> To: local-lisp Subject: opus 38.80 Status: O Two new functions: (character-index 'st_string 'xst_char) returns the position of the character xst_char in the string st_string. The position of the first character is '1' (1-based indexing was chosen because substring also uses 1-based indexing). If the character is not in the string, nil is returned. xst_char, as its prefix implies, can either be the fixnum value of a character (commonly written #/x), or a symbol or string, in which case the first character is used. (sleep 'x_seconds) sleep for x_seconds. From jkf Sat Oct 1 21:42:29 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA16280; Sat, 1 Oct 83 21:42:29 PDT Date: Sat, 1 Oct 83 21:42:29 PDT From: jkf (John Foderaro) Message-Id: <8310020442.AA16280@ucbkim.ARPA> To: local-lisp Subject: opus 38.81 Status: O new function (sys:nice 'x_delta-priority) this increments your nice value (decrements your process priority) by x_delta-priority. x_delta-priority can only be negative if you are root, of course. From unmvax!gatech!pwh Tue Oct 4 08:35:04 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA23488; Tue, 4 Oct 83 08:35:04 PDT Received: by ucbvax.ARPA (4.12/4.7) id AA07616; Tue, 4 Oct 83 08:05:43 PDT From: unmvax!gatech!pwh Message-Id: <8310041505.AA07616@ucbvax.ARPA> Date: 1 Oct 83 19:44:56-EDT (Sat) Original-From: To: franz-friends@BERKELEY Subject: why a HOLE (duck) ? Status: RO Could someone explain to me what HOLE is all about in the vax dependent Franz code? I've scrutinized the code and read the preliminary Franz implementation manual too many times and still can't figure it... phil hutto From mbr@nprdc Sat Oct 8 15:59:38 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA08262; Sat, 8 Oct 83 15:59:38 PDT Received: from nprdc (nprdc.ARPA) by ucbvax.ARPA (4.12/4.7) id AA23633; Sat, 8 Oct 83 15:58:02 PDT Message-Id: <8310082258.AA23633@ucbvax.ARPA> Date: 8 Oct 1983 15:52:17-PDT From: Mark Rosenstein Reply-To: mbr@NPRDC To: franz-friends@BERKELEY Subject: bugs in liszt 8.36 Status: RO Problem: -I flag doesn't work Solution?? in file tlev.l change 'i to 'I in line 127 (notice that -i flag includes files and it is imposible to get into uci mode) Problem: while compiling get message: Undefined function called from compiled code e-sub2 Solution?? in file tlev.l change e-sub2 to e-sub in line 298 (I don't swear by this solution--my stuff seems to compile ok but no promises) From jkf Wed Oct 12 06:11:15 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA29652; Wed, 12 Oct 83 06:11:15 PDT Date: Wed, 12 Oct 83 06:11:15 PDT From: John Foderaro (on an h19-u) Message-Id: <8310121311.AA29652@ucbkim.ARPA> To: local-lisp Subject: New AI language in the works Cc: Status: RO From: Skef Wholey >From an article "Computing Women" in a shoddy little pseudo-magazine called "Ampersand" that was stuck inside CMU's student newspaper this week: Our final tip involves a different kind of research. Is a breakthough in computing happening right on your own campus? MIT and Carnegie-Mellon University, for example, are busy developing a brainchild called Lisp. If successful, Lisp may become the standard language of ``artificially intelligent'' computers that ``think'' within a limited sphere on their own. Imagine your marketability if you've worked with a poineer in this field. Skip a football game some Saturday afternoon and see what the Prof is doing with HIS spare time. It could be profitable to you. From @MIT-MC:apm@cmu-ri-isl1 Fri Oct 14 09:27:56 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA14501; Fri, 14 Oct 83 09:27:56 PDT Received: from MIT-MC (mit-mc.ARPA) by ucbvax.ARPA (4.12/4.7) id AA00195; Fri, 14 Oct 83 09:26:15 PDT Message-Id: <8310141626.AA00195@ucbvax.ARPA> Date: 14 Oct 1983 12:22:28-EDT From: Andrew.Mendler@CMU-RI-ISL1 Subject: eunice version of franz Apparently-To: Status: RO What is the most recent version of franz lisp that is available under eunice? In particular is opus38.55 available? Thanks in advance. From sklower Fri Oct 14 09:45:15 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA14694; Fri, 14 Oct 83 09:45:15 PDT Date: Fri, 14 Oct 83 09:45:15 PDT From: sklower (Keith Sklower) Message-Id: <8310141645.AA14694@ucbkim.ARPA> To: franz-friends Subject: eunice version of franz Status: RO We have opus38.79 working on David Kashtan's machine. The source is integrated with the vax-unix and 68000 versions, all available by anonymous ftp, or as the regular tape distribution. I have had one report from a eunice user that the installation didn't get past construction the kernel, but it could be due to insufficient quota. From jkf Sun Oct 16 16:39:35 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA03935; Sun, 16 Oct 83 16:39:35 PDT Date: Sun, 16 Oct 83 16:39:35 PDT From: John Foderaro (on an aaa-60-s) Message-Id: <8310162339.AA03935@ucbkim.ARPA> To: local-lisp Subject: opus 38.82 Cc: Status: RO I'm working on a simple record (destruct-like) package. Consequently, I've made 'defrecord' autoload my record package. This will cause problems if there are people who use the name 'defrecord' as a non-macro function. If this will cause you problems, please speak up. From procter@UCBMIRO Mon Oct 17 08:59:02 1983 Received: from UCBMIRO.ARPA by ucbkim.ARPA (4.6/4.2) id AA01206; Mon, 17 Oct 83 08:59:02 PDT Date: 16 Oct 83 22:56:00 PDT (Sun) From: procter@UCBMIRO (Steve Procter) Subject: cfasl Message-Id: <8310170556.AA01323@UCBMIRO.ARPA> Received: by UCBMIRO.ARPA (3.340/3.29) id AA01323; 16 Oct 83 22:56:00 PDT (Sun) To: local-lisp@ucbkim Status: O How are arguements passed from lisp to the C routines? I wrote a program which just printed the arguements passed to it, and when I cfasl'd it and used it, I got argc > 500000... steve procter procter@ucbmiro From jkf Mon Oct 17 10:08:37 1983 Received: by ucbkim.ARPA (4.6/4.2) id AA02418; Mon, 17 Oct 83 10:08:37 PDT Date: Mon, 17 Oct 83 10:08:37 PDT From: John Foderaro (on an h19-u) Message-Id: <8310171708.AA02418@ucbkim.ARPA> To: procter@UCBMIRO Subject: Re: cfasl Cc: local-lisp In-Reply-To: Your message of 16 Oct 83 22:56:00 PDT (Sun) Status: O Arguments are passed to C functions in the normal C way (on the stack not as strings on the command line). There are examples in the lisp manual (in the section on foreign functions). From whm.Arizona@Rand-Relay Fri Oct 28 05:44:39 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2) id AA20395; Fri, 28 Oct 83 05:44:39 pdt Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13) id AA14289; Fri, 28 Oct 83 05:43:48 pdt Message-Id: <8310281243.AA14289@ucbvax.ARPA> Date: 28 Oct 1983 01:12:45-PST From: whm.arizona@Rand-Relay Return-Path: Subject: Memory management in Franz Date-Sent: 28 Oct 83 01:12:42 MST (Fri) To: franz-friends@BERKELEY Via: Arizona; 28 Oct 83 2:37-PDT Status: O I've got a couple of questions about Franz Lisp storage management that I wondering if somebody "in the know" might be able to answer. I tried this on net.lang.lisp, but didn't get any answers. First, Franz seems to support non-relocatable data objects such as external functions. Are such objects managed by having two logical regions in managed memory, one for relocatable objects and one for non-relocatable objects? Such a scheme has been used in other systems that require garbage collection and I was wondering if Franz uses this or some other scheme. Second, I've heard (but not tried) that Franz allows non-relocatable data to be allocated via brk/sbrk. Is this true? (Actually, I suppose I'd like information on any storage management implementations for any languages (w/ automatic storage management) that allow non-relocatable data to be dynamically allocated that don't use the aforementioned scheme.) Thanks, Bill Mitchell whm.arizona@rand-relay p.s. I'm not on the Franz-Friends list, so if you would, please mail me any replies. From whm.Arizona@Rand-Relay Mon Oct 31 04:55:33 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2) id AA29912; Mon, 31 Oct 83 04:55:33 pst Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13) id AA08771; Mon, 31 Oct 83 04:54:49 pst Message-Id: <8310311254.AA08771@ucbvax.ARPA> Date: 31 Oct 1983 00:41:38-PST From: whm.arizona@Rand-Relay Return-Path: Subject: Memory management in Franz Date-Sent: 31 Oct 83 00:41:36 MST (Mon) To: franz-friends@BERKELEY Via: Arizona; 31 Oct 83 1:36-PST Status: O [My apologies if this is a repeat; I got some very wierd messages back from the Berkeley mailer on my first attempt to send this.] I've got a couple of questions about Franz Lisp storage management that I wondering if somebody "in the know" might be able to answer. I tried this on net.lang.lisp, but didn't get any answers. First, Franz seems to support non-relocatable data objects such as external functions. Are such objects managed by having two logical regions in managed memory, one for relocatable objects and one for non-relocatable objects? Such a scheme has been used in other systems that require garbage collection and I was wondering if Franz uses this or some other scheme. Second, I've heard (but not tried) that Franz allows non-relocatable data to be allocated via brk/sbrk. Is this true? (Actually, I suppose I'd like information on any storage management implementations for any languages (w/ automatic storage management) that allow non-relocatable data to be dynamically allocated that don't use the aforementioned scheme.) Thanks, Bill Mitchell whm.arizona@rand-relay p.s. I'm not on the Franz-Friends list, so if you would, please mail me any replies. From pjt@brl-voc Tue Nov 1 06:52:11 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13) id AA03145; Tue, 1 Nov 83 06:52:11 pst Received: from BRL-VOC (brl-voc.ARPA) by ucbvax.ARPA (4.16/4.13) id AA01150; Tue, 1 Nov 83 06:51:14 pst Message-Id: <8311011451.AA01150@ucbvax.ARPA> Date: Tue, 1 Nov 83 9:44:54 EST From: Paul Tanenbaum To: Ailist-requests@sri-ai, Franz-Friends@BERKELEY Cc: pjt@brl-voc Subject: mailing list Status: O Please cons me onto your mailing list Thanks, paul From norvig Fri Nov 4 14:14:16 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA20986; Fri, 4 Nov 83 14:14:16 pst Date: Fri, 4 Nov 83 14:14:16 pst From: norvig (Peter Norvig) Message-Id: <8311042214.AA20986@ucbkim.ARPA> To: mills@ernie Subject: Graphics on Suns Cc: local-lisp Status: O I want a lisp-callable package to display trees and graphs on the suns. This is for showing semantic nets, and it would also be useful for showing how procedures call each other, like Interlisp's masterscope. Does anyone know of such a package? From kanderso@bbn-vax Fri Nov 4 19:55:59 1983 Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13) id AA26540; Fri, 4 Nov 83 19:55:59 pst Received: from bbn-vax (bbn-vax.ARPA) by ucbvax.ARPA (4.16/4.13) id AA03738; Fri, 4 Nov 83 19:55:52 pst Message-Id: <8311050355.AA03738@ucbvax.ARPA> Date: Fri, 4 Nov 83 22:55 EST From: Ken Anderson Subject: Why no &keywords in local functions? To: franz-friends@BERKELEY Status: O With liszt version 8.29 (Opus 38.66 of Franz) I get the following message: ?Error: save.l: save-install: local functions can't use &keyword's save-install When compiling the function (declared as a localf): (defun save-install (thing table &aux type handler) ; Install thing in hash table, and recursively install its parts. (cond ((memq (setq type (save-type thing)) '(symbol number))) ; Needn't install (t (cond ((zerop (save-count++ thing)) ; Increment access count, and install parts of thing if it ; is being installe (cond ((setq handler (get type 'save-install-parts)) (funcall handler thing table)) (t (ferror "Don't Know how to save ~S~%" thing)))))))) This used to work in earlier Opuses (like 38.44). Can you explain the change. From norvig Tue Nov 8 01:51:03 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA20986; Fri, 4 Nov 83 14:14:16 pst Date: Fri, 4 Nov 83 14:14:16 pst From: norvig (Peter Norvig) Message-Id: <8311042214.AA20986@ucbkim.ARPA> To: mills@ernie Subject: Graphics on Suns Cc: local-lisp Status: O I want a lisp-callable package to display trees and graphs on the suns. This is for showing semantic nets, and it would also be useful for showing how procedures call each other, like Interlisp's masterscope. Does anyone know of such a package? From norvig Tue Nov 8 02:03:27 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA20986; Fri, 4 Nov 83 14:14:16 pst Date: Fri, 4 Nov 83 14:14:16 pst From: norvig (Peter Norvig) Message-Id: <8311042214.AA20986@ucbkim.ARPA> To: mills@ernie Subject: Graphics on Suns Cc: local-lisp Status: O I want a lisp-callable package to display trees and graphs on the suns. This is for showing semantic nets, and it would also be useful for showing how procedures call each other, like Interlisp's masterscope. Does anyone know of such a package? From sklower Thu Nov 17 17:03:27 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA01897; Thu, 17 Nov 83 17:03:27 pst Date: Thu, 17 Nov 83 17:03:27 pst From: sklower (Keith Sklower) Message-Id: <8311180103.AA01897@ucbkim.ARPA> To: local-lisp Subject: lisp sources Status: O Franz now resides in /usr/franz. From jkf Tue Nov 22 09:33:32 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA15675; Tue, 22 Nov 83 09:33:32 pst Date: Tue, 22 Nov 83 09:33:32 pst From: John Foderaro (on an h19-u) Message-Id: <8311221733.AA15675@ucbkim.ARPA> To: local-lisp Subject: liszt 8.39 Cc: Status: O The -W switch has been added to liszt. When specified, if a compilation causes any warning messages to given (such as a symbol declared special), then the compiler will not perform the assembly and will return a non-zero exit status (for 'make's benefit). Liszt will continue to compile after it has seen a warning, even if -W is given, to permit as many warnings as possible to be made in each compile. From barry%umcp-cs@CSNet-Relay Tue Nov 22 17:14:09 1983 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA23508; Tue, 22 Nov 83 17:14:09 pst Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.21/4.15) id AA06655; Tue, 22 Nov 83 17:13:29 pst Message-Id: <8311230113.AA06655@UCB-VAX.ARPA> Date: 22 Nov 83 12:48:01 EST (Tue) From: Barry Perricone Return-Path: Subject: Franz for VMS To: franz-friends@BERKELEY Via: UMCP-CS; 22 Nov 83 19:25-EST Status: O I need to know if anybody has a version of Franz for the Vax series under VMS which includes 'liszt'. Also one which when a 'dumplisp' is performed will output a file which can execute as a stand-alone (i.e., does not need to be "restored"). I would appreciate any information on this matter, and if one exists information on how I could obtain a copy of it. Thanks in advance, Barry P. From alfred.ct@Rand-Relay Sat Dec 3 22:40:07 1983 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA12594; Sat, 3 Dec 83 22:40:07 pst Received: from rand-relay.ARPA by UCB-VAX.ARPA (4.22/4.16) id AA06631; Sat, 3 Dec 83 21:43:27 pst Message-Id: <8312040543.AA06631@UCB-VAX.ARPA> Date: 3 Dec 1983 11:58:11-PST From: alfred.ct@Rand-Relay Return-Path: Subject: Deficiency in Franz GC To: franz-friends@BERKELEY Via: ct; 3 Dec 83 12:46-PST Status: RO This really isn't a bug so much as a deficiency in the code. We are running Opus 38.26 and recently had need to increase the constant TTSIZE (in config.h) above the default 10216. It turns out that this breaks the garbage collector which will fail to completely clear the array bitmapi if given a TTSIZE greater 10216 (during the clearing out of bit maps). The offending code is in Talloc.c (or alloc.c, depending on your Opus). The old code is: /* try the movc5 to clear the bit maps */ /* the maximum number of bytes we can clear in one sweep is * 2^16 (or 1<<16 in the C lingo) */ bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; if(bytestoclear > MAXCLEAR) { blzero(((int) &bitmapi[((int)beginsweep>>7)]) + MAXCLEAR, bytestoclear - MAXCLEAR); bytestoclear = MAXCLEAR; } blzero((int)&bitmapi[((int)beginsweep)>>7],bytestoclear); and the fixed version that we have been running for several weeks now is: /* try the movc5 to clear the bit maps */ /* the maximum number of bytes we can clear in one sweep is * 2^16 (or 1<<16 in the C lingo) */ bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; {int count = 0; while (bytestoclear > 0) { if(bytestoclear > MAXCLEAR) { blzero(((int) &bitmapi[((int)beginsweep>>7)])+count*MAXCLEAR, MAXCLEAR); ++count; } else blzero(((int)&bitmapi[((int)beginsweep)>>7]+count*MAXCLEAR), bytestoclear); bytestoclear -= MAXCLEAR; } } The old code is still present in Opus 38.56. Alfred Correira Paul Robertson ...ucbvax!nbires!ctvax!alfred (UUCP) alfred.ct@Rand-Relay (CSNET) From fateman Tue Dec 13 09:11:00 1983 Received: by ucbkim.ARPA (4.16/4.13) id AA03666; Tue, 13 Dec 83 08:31:30 pst Date: Tue, 13 Dec 83 08:31:30 pst From: fateman (Richard Fateman) Message-Id: <8312131631.AA03666@ucbkim.ARPA> To: local-lisp Cc: pattrsn Status: O I have just received a copy of the new Common Lisp Reference Manual (The Mary Poppins Edition ... Practically Perfect in Every Way) ... it is 385 pages long. From hoey@nrl-aic Wed Jan 11 12:58:53 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA06395; Wed, 11 Jan 84 12:58:53 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA03955; Wed, 11 Jan 84 12:58:55 pst Message-Id: <8401112058.AA03955@UCB-VAX.ARPA> Date: 11 Jan 1984 14:43-EST From: Dan Hoey Subject: Problems with arrays in Franz Apparently-To: Status: O From hoey@nrl-aic Wed Jan 11 13:10:01 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA06529; Wed, 11 Jan 84 13:10:01 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA04150; Wed, 11 Jan 84 13:09:46 pst Message-Id: <8401112109.AA04150@UCB-VAX.ARPA> Date: 11 Jan 1984 14:43-EST From: Dan Hoey Subject: Problems with arrays in Franz To: FRANZ-FRIENDS@BERKELEY Status: O Hard to believe but it was less than two and a half years ago that someone was having trouble using Franz arrays... Date: 17 Jul 1981 17:06:22-PDT From: CSVAX.jkf at Berkeley To: FININ@WHARTON-10 cc: franz-friends at MIT-MC Subject: Re: ... the maclisp-style array package. In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday). From: FININ@WHARTON-10 Subject: ... the maclisp-style array package. ... [3] We've been having problems with the MacLisp compatable array package - it doesn't work! Does anyone have a debugged version? Can you be more specific? We use it in Vax Macsyma without any problems. Personally I feel that Maclisp arrays were invented by a madman and no new code should be written using them. -- john foderaro Well, I used the Maclisp array package because I didn't want to waste time writing my own. Instead I spent hours looking for the bug in this code: -> (let ((factorial (*array () () 100.))) (store (factorial 0) 1) (do ((i 1 (1+ i))) ((= i 100.)) (store (factorial i) (times i (factorial (1- i))))) (factorial 10.)) 285656 To make a long story short, this lossage is because the second argument to *array being nil tells the garbage collector not to scan the array. The factorial of ten gets tossed in the bit bucket, where it unfortunately looks like a fixnum. To fix the example, change the first line of the example to -> (let ((factorial (*array () t 100.))) To save someone else from excruciatingly wrong answers, change the documentation in Section 2. (*array 's_name 's_type 'x_dim1 ... 'x_dimn) (array s_name s_type x_dim1 ... x_dimn) WHERE: s_type may be one of t, nil, fixnum, flonum, fixnum-block and flonum-block. ... < In FRANZ LISP arrays of type t, nil, fix- < num and flonum are equivalent and the elements of < these arrays can be any type of lisp object. --- > In FRANZ LISP arrays of type t, fixnum, > and flonum are equivalent and the elements of > these arrays can be any type of lisp object. > Type nil arrays may also contain any type of lisp > object, but they are not marked by the garbage > collector (see 9.2.2) and can lose data if used > incorrectly. Fixnum-block and flonum-block arrays are res- tricted to fixnums and flonums respectively and are used mainly to communicate with foreign func- tions (see 8.4). Dan From hoey@nrl-aic Wed Jan 11 16:23:56 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA06395; Wed, 11 Jan 84 12:58:53 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA03955; Wed, 11 Jan 84 12:58:55 pst Message-Id: <8401112058.AA03955@UCB-VAX.ARPA> Date: 11 Jan 1984 14:43-EST From: Dan Hoey Subject: Problems with arrays in Franz Apparently-To: Status: O From fateman@ucbdali Sun Jan 15 14:58:17 1984 Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13) id AA00458; Sun, 15 Jan 84 14:58:17 pst Received: by ucbdali.ARPA (4.22/4.18) id AA02865; Sun, 15 Jan 84 14:58:51 pst Date: Sun, 15 Jan 84 14:58:51 pst From: fateman@ucbdali (Richard Fateman) Message-Id: <8401152258.AA02865@ucbdali.ARPA> To: franz-friends@ucbdali Subject: FUGUE.3 Status: O FUGUE Notes An occasional publication of the Franz Lisp User Group under Unix and Eunice (FUGUE) Number 3 (January, 1984) edited by Richard J. Fateman University of California Berkeley CA 94720 USA fateman@berkeley _1. _W_e_l_c_o_m_e! It seems about time to publish the third 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. _N_e_w _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s Franz now runs on a number of Motorola 68000 and 68010 systems, including DUAL, PIXEL, Apple-LISA (UNIX), and undoubtedly a large number of other UNISOFT Inc. UNIX ports. (The LISA has only a 1 megabyte address space, and hence cannot run the compiler. It can load cross-compiled pro- grams.) Non-UNISOFT UNIX systems we have Franz running on include the 4.2BSD" Sun Microsystems operating system. Some work is beginning on high-speed VLSI chips for Lisp, using the reduced instruction set technology which has been successfully used at UCB in the past. More information on this will be available in the near future. _3. _N_e_w _p_r_o_g_r_a_m_s _3._1. _V_a_x_i_m_a _a_n_d _A_l_g_e_b_r_a_i_c _M_a_n_i_p_u_l_a_t_i_o_n Macsyma runs on the 68000 workstations with sufficient memory both virtual and real. At least 4 megabytes of vir- tual is needed, but benchmarks suggest that anything less than 2 megabytes of real memory is painful. We recommend 4 or more real megabytes. The PIXEL machine with 6 megabytes (unpaged) is our fastest real-time Macsyma system, (CPU-time is about 25% longer than reported VAX-780 CPU time, but more to the point, CPU-time is equal to real-time). Distribution ____________________ 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, SRI Int'l, and Univ. of Calif. 9 of 68000 Macsyma will presumably be done by Symbolics, (con- tact RP@mit-mc, with a cc to fateman@berkeley if you are interested). Development of a new algebra system and user applica- tion modules is proceeding, and a programming language called Newspeak, initially implemented on top of Franz, is the principal vehicle. This is described in John Foderaro's PhD dissertation, available from the CS Division at UCB. (Newspeak is hierarchical, object-oriented, and strongly typed; is compiler-based, and should provide efficient access to machine resources). While the algebra code is progressing well, we are not yet ready to set a release date for the user-end of the system, tentatively named Xi. _4. _N_e_w _f_e_a_t_u_r_e_s As usual, various performance enhancements and bug fixes have been incorporated in versions of Franz (now on Opus 38.87 and the compiler, Liszt 8.39) Most changes made it into the recent Berkeley 4.2BSD UNIX distribution, and reported alterations will not be repeated here. _5. _O_t_h_e_r _L_i_s_p_s We understand that a version of PSL will be supported by Hewlett Packard, on its workstations, and that Common Lisp, from DEC will have initial field-test in January, 1984. We believe PSL should be available from Utah in a form for running on 4.2BSD VAX UNIX; similarly for "T" from Cognitive Systems. We believe that a Common-Lisp support package for Franz may be constructed, but probably not at UC under current funding. (see Business news below, though). _6. _W_o_r_k _i_n _P_r_o_g_r_e_s_s _6._1. _G_r_a_p_h_i_c_s Gregg Foster has constructed a graphics Franz Lisp which includes the full Sun Microsystems Graphics package for Sun-2 systems, and Keith Sklower has constructed a C- structure package in Franz to enable programmers to more easily construct arbitrary C-structures in Lisp, to pass to C. Various demonstration programs have been written to access the smooth-curve plotting capabilities, variable-size fonts, etc. _6._2. _I_B_M _F_r_a_n_z Still more nibbles on this one, but not yet. We heard a rumor of work at Columbia University. (also see the next item.) 9 9 _7. _B_u_s_i_n_e_s_s _N_e_w_s _7._1. _F_r_a_n_z _I_n_c A new software company has been formed to support Franz and application programs, and is seeking customers in 3 categories: (a) manufacturers of hardware wishing to obtain a Lisp system and/or Lisp support; (b) software producers who wish to have reliable access to experts in Franz, for enhancement, support, training or porting of existing code. (c) end-users who are using Franz or applications written in Franz and need help in customizing, debugging, conversion to or from other dialects, etc. The University of California will continue to distri- bute Franz Lisp on its current basis, but your questions about support in any of these categories, or about future plans, can be directed to Franz Inc. Most of the principals at UC will be participating in this venture. Contact Franz Inc. via fkunze@berkeley, or (to avoid abuse of various net- work privileges), Fritz Kunze, President, Franz Inc., 6321 Thornhill Drive, Oakland, Ca 94611 (415) 339-1481. 9 9 From cowan@AEROSPACE Thu Jan 19 09:56:25 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA14836; Thu, 19 Jan 84 09:56:25 pst Received: from aerospace.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA02684; Thu, 19 Jan 84 09:55:33 pst Message-Id: <8401191755.AA02684@UCB-VAX.ARPA> Date: Thu, 19 Jan 84 09:55:01 PST From: Ric Cowan To: franz-friends@BERKELEY Subject: Help Status: O Hi, I'm starting a new project and would like to use Franz lisp. It is a large application that needs to: (1) Run on a VAX 11/780 under VMS. (2) Interface with INGRESS. (3) Support a menu driven interface with VT100 type terminals. Is Franz lisp a viable language to use? Thanks in advance, Ric Cowan From levitt@aids-unix Thu Jan 26 17:44:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA10074; Thu, 26 Jan 84 17:44:03 pst Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA02121; Thu, 26 Jan 84 17:01:25 pst Message-Id: <8401270101.AA02121@UCB-VAX.ARPA> Date: 26 Jan 1984 16:25:55-PST From: Tod Levitt To: franz-friends@BERKELEY Subject: report PAM 124, "Parlez vous Franz..." by James Larus Cc: levitt@aids-unix Status: O I am trying to obtain a copy of PAM report 124 which discusses interfacing foreign functions to Franzlisp. Can someone please point me at a source for this document? Thanks... Tod Levitt (levitt@aids-unix) From jkf@ucbmike Fri Jan 27 08:44:54 1984 Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13) id AA15308; Fri, 27 Jan 84 08:44:54 pst Date: Fri, 27 Jan 84 08:44:40 pst From: John Foderaro (on an h19-u) Message-Id: <8401271644.2469@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA02469; Fri, 27 Jan 84 08:44:40 pst To: local-lisp@kim Subject: lisp 38.88 Cc: Status: O The 'msg' macro now accepts the special form (T 'x_column), and it spaces over to that column (plus 1). -> (msg "foo" (T 10) "bar" N "baz" (T 11) "bof" N) foo bar baz bof nil -> Note that the method used to locate the column only works if nothing has yet been actually written on the line. Problems will occur if you drain the port in the middle of the line. For example: -> (msg "foo" D (T 10) "bar" N << here we drain after "foo" "foo" (T 10) "bar" N) foo bar << thus column 11 turns out to be column 14 foo bar nil -> From jkf@ucbmike Tue Jan 31 10:55:51 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA20759; Tue, 31 Jan 84 10:55:51 pst Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12296; Tue, 31 Jan 84 10:51:34 pst Date: Tue, 31 Jan 84 10:51:33 pst From: John Foderaro (on an sun-e) Message-Id: <8401311851.1218@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA01218; Tue, 31 Jan 84 10:51:33 pst To: franz-friends@BERKELEY Subject: LISPcraft, a book on Lisp and Franz. Cc: Status: O A new Lisp book is due out March 23rd which may be especially interesting to Franz Lisp users or potential Franz Lisp users. The title is `LISPcraft' and it was written by Robert Wilensky, a Computer Science professor at Berkeley who teaches AI programming courses. The book starts at first principles and teaches Lisp programming, and then goes on to Franz-specific topics such as debugging, read macros, error handling, and compilation. Then there are chapters on Lisp applications: pattern matching and databases. Finally it contains a complete description of all Franz functions. details: LISPcraft, by Robert Wilensky 385 pages, $19.95 publisher: W. W. Norton, 500 5th Avenue, N.Y. N.Y. 10110 800-223-2584 From jkf@ucbmike Fri Feb 3 08:03:58 1984 Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13) id AA19272; Fri, 3 Feb 84 08:03:58 pst Date: Fri, 3 Feb 84 08:04:17 pst From: John Foderaro (on an h19-u) Message-Id: <8402031604.2117@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA02117; Fri, 3 Feb 84 08:04:17 pst To: local-lisp@kim Subject: opus 38.89 Cc: Status: O In opus 38.88 the msg macro was extended to make (T n) put the cursor on column n+1. Others had extended the msg macro in a conflicting way, so we decided to convert over to their extensions. So forget what you read in the opus38.88 message, and remember this: (C n) go to column n. The first column on the line is column 1. If the cursor is beyond column n, then go to the next line and go to column n. (T m) print m tab characters From jkf Thu Feb 16 10:32:03 1984 Received: by ucbkim.ARPA (4.16/4.22) id AA16308; Thu, 16 Feb 84 10:32:03 pst Date: Thu, 16 Feb 84 10:32:03 pst From: John Foderaro (on an sun-e) Message-Id: <8402161832.AA16308@ucbkim.ARPA> To: local-lisp Subject: opus 38.90 Cc: Status: O For those of you using the 'tpl' toplevel, the new command ?fast will set all switches for maximum speed: (*rset nil) (sstatus translink on) (setq displace-macros t) From wilensky@ucbdali Wed Feb 22 09:58:43 1984 Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA16486; Wed, 22 Feb 84 09:58:43 pst Received: by ucbdali.ARPA (4.22/4.22) id AA06784; Wed, 22 Feb 84 09:57:21 pst Date: Wed, 22 Feb 84 09:57:21 pst From: wilensky@ucbdali (Robert Wilensky) Message-Id: <8402221757.AA06784@ucbdali.ARPA> To: andy@aids-unix, franz-friends@ucbdali Subject: Re: Franz Flavors & software copyright In-Reply-To: Your message of 21 Feb 1984 16:29-PST Status: O Thanks for your clarification. Everything you said is consistent with my understanding of the situation. And you are correct in emphasizing the complexity of the issue. But I want to stress my main point. This is that the ``author'' holds the copyright. It may be unclear who the author is, but it is clearly NOT the university. In addition, many pieces of ``university-developed'' software have contributions by unfunded students, and by faculty, whose salary is not paid by the gov't (except maybe during the summer). Furthermore, it would seem to be unclear who the author is if it is, say, a student working as a gov't sponsored r. a. For example, the student's thesis is presumably his to copyright, even if the student were paid by the gov't because it was not part of what he was paid to do. One could argue that a concommitant program has the same status unless it were specifically contracted for. Let me state that my main purpose was not to promote people selling their code, but rather, to stop the universities from impeding its distribution. As far as I know, the gov't hasn't tried to prevent us from giving each other our software, but many universities have. Therefore, we are better off leaving them out of the picture entirely - legally this seems to be a sound position. From jkf@ucbmike Wed Mar 14 09:04:55 1984 Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22) id AA00884; Wed, 14 Mar 84 09:04:55 pst Date: Wed, 14 Mar 84 08:58:51 pst From: John Foderaro (on an h19-u) Message-Id: <8403141658.3782@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA03782; Wed, 14 Mar 84 08:58:51 pst To: fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory Subject: lisps running wild Cc: local-lisp@kim In-Reply-To: Your message of Tue, 13 Mar 84 21:45:25 pst Status: O re: From: chris@ucbcory (Chris Guthrie) We are having a good deal of trouble with them being left running instead of dying and killing the load here. The problem is that people are setting a flag in their lisp init files which instruct lisp to ignore 'end of file' (much like the c shell). If a connection is broken (ipc connection breaks or modem hangs up), then lisp is sent a hangup signal (which it ignores) and then a continuous sequence of 'end of files' which it ignores after a bit of processing. The solution is this: If you have something in your init file which instructs lisp to ignore end of files (such as (sstatus ignoreeof t)), then you should also have (signal 1 'exit) in the init file so lisp will exit upon a hangup. From mcgeer Wed Mar 14 09:37:45 1984 Received: by ucbkim.ARPA (4.16/4.22) id AA01437; Wed, 14 Mar 84 09:37:45 pst Date: Wed, 14 Mar 84 09:37:45 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8403141737.AA01437@ucbkim.ARPA> To: jkf@ucbmike, chris@cory, layer@ucbdali, sklower@ucbdali, fateman@ucbdali Subject: Re: lisps running wild Cc: local-lisp In-Reply-To: Your message of Wed, 14 Mar 84 08:58:51 pst Status: O John, your top level sets the ignoreeof flag. Does it also set the appropriate signal, or should your users do that themselves? From jkf@ucbmike Wed Mar 14 09:48:04 1984 Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22) id AA01603; Wed, 14 Mar 84 09:48:04 pst Date: Wed, 14 Mar 84 09:42:15 pst From: John Foderaro (on an h19-u) Message-Id: <8403141742.3833@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA03833; Wed, 14 Mar 84 09:42:15 pst To: mcgeer@ucbkim, fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory Subject: Re: lisps running wild Cc: local-lisp@ucbkim In-Reply-To: Your message of Wed, 14 Mar 84 09:37:45 pst Status: O Since ignoreeof is always set in the new top level, I'll make 'exit on hangup' the default if you use the new top level. From ROD@SU-AI.ARPA Sat Mar 17 13:45:58 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22) id AA05623; Sat, 17 Mar 84 13:45:58 pst Received: from SU-AI.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA12441; Sat, 17 Mar 84 13:47:35 pst Message-Id: <8403172147.AA12441@UCB-VAX.ARPA> Date: 17 Mar 84 1347 PST From: Rod Brooks Subject: Don't use Franz sortcar! To: franz-friends@BERKELEY Status: O Somewhat bizzarely it seems that Franz Lisp sort and sortcar have different time complexities. sort is good and sortcar is bad so I suggest you convert your sortcar's to sort's until someone sorts this out. The code and transcript below use both sort and sortcar to sort a list of length n (the list happens to start in precisely reverse order). A count of the number of calls to the comparison function is kept. The results show that sort takes n*log(n) comparisons while sortcar takes n*n. The problem should be fixable by throwing out code as there must be two sorters lurking in there! ;;;;;;;;;;;;;;; (defun gen (n) (do ((i 0 (1+ i)) (l () (cons (cons i ()) l))) ((= i n) l))) (defun compare (x y) (setq *count* (1+ *count*)) (< x y)) (defun compare-cars (x y) (compare (car x) (car y))) (defun count-sort (n) (let ((*count* 0)) (sort (gen n) #'compare-cars) *count*)) (defun count-sortcar (n) (let ((*count* 0)) (sortcar (gen n) #'compare) *count*)) (defun test (n) (let ((csort (count-sort n)) (csortcar (count-sortcar n))) (list n csort csortcar (/$ (float csort) (*$ (float n) (log n))) (/$ (float csortcar) (float (* n n)))))) ;;;;;;;;;;;;;;; Here's the transcript. The lists of 5 elements are: n compares for sort compares for sortcar compares for sort / n*log(n) compares for sortcar / n*n Franz Lisp, Opus 38 -> (load 'test) t -> (test 3) (3 3 6 0.910239226626837 0.6666666666666667) -> (test 100) (100 460 9900 0.9988773083774791 0.99) -> (test 200) (200 1020 39800 0.9625697456705496 0.995) -> (test 300) (300 1440 89700 0.8415468193831012 0.9966666666666667) -> (test 400) (400 2240 159600 0.9346629619469353 0.9975) -> From @MIT-MC:smh@MIT-EMS Wed Mar 28 06:11:15 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA06408; Wed, 28 Mar 84 06:11:15 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA23759; Wed, 28 Mar 84 06:10:43 pst Message-Id: <8403281410.AA23759@UCB-VAX.ARPA> Date: 28 Mar 1984 09:09:38-EST From: To: franz-friends@BERKELEY Subject: Fixes for setf return value problem Status: O As FranzFriends readers will know, my message several days ago generated a number of comments. The clear consensus was that setf should be fixed, not the documentation. This was obvious. The reason I didn't suggest the fix myself was that I felt it was far more important to preserve compatibility between Franz and the various other more-or-less-source-compatible Lisps (aka Common Lisps). It was my impression that code relying on the value returned by setf would not be portable. I have since learned that Common Lisp does indeed define setf to return the new value (its second argument), and that other implementations (i.e. MIT and Symbolics Lisp Machines) indeed work this way. (Mind you, I haven't checked this myself -- the information is second hand.) The fixes to setf are quite straightforward and are brief enough that I am including them below. For each case that the setf macro evaluates to a {rplaca, rplacd, rplacx} the corresponding {car, cdr, cxr} is now wrapped around it. The Liszt compiler seems smart enough to remove the extra reference if the value is ignored. The new setf functions follow. The starting version is the Opus 38.69 common2 identified by: ;; common2.l -[Fri Jul 8 17:46:13 1983 by layer]- (Although only two lines of setf-check-car+d were changed, the entire function is included because the change is difficult to locate by context.) I suggest these changes be made in the official sources. Whoever wants to install them should edit common2.l and remake the Franz interpreter. The Liszt compiler does not need to be changed. ==================== ; modified 27Mar84 SMH@MIT-EMS@MT-MC (see comment below) ; (defun setf-check-cad+r (name) (if (eq (getcharn name 1) #/c) then (let ((letters (nreverse (cdr (exploden name))))) (if (eq (car letters) #/r) then (do ((xx (cdr letters) (cdr xx))) ((null xx) ;; form is c{ad}+r, setf form is ;; (rplac (cr x)) (setq letters (nreverse letters)) (eval `(defsetf ,name (e v) ; SMH@MIT-EMS@MIT-MC ; added next line and matching rparen. (list ',(implode `(#/c ,(car letters) #/r)) (list ',(concat "rplac" (ascii (car letters))) (list ',(implode `(#/c ,@(cdr letters))) (cadr e)) v)))) ; SMH@MIT-EMS@MIT-MC t) (if (not (memq (car xx) '(#/a #/d))) then (return nil))))))) . . . ;--- other setf's for car's and cdr's are generated automatically ; ; modified 27Mar84 SMH@MIT-EMS@MIT-MC ; Now whenever setf macro expands to a rplac[adx], the corresponding c[adx]r ; is now wrapped around it so that setf consistently returns its second arg. ; The compiler is smart enough to remove the extra operation if the value ; is not used. ; (defsetf car (e v) `(car (rplaca ,(cadr e) ,v))) (defsetf caar (e v) `(car (rplaca (car ,(cadr e)) ,v))) (defsetf cadr (e v) `(car (rplaca (cdr ,(cadr e)) ,v))) (defsetf cdr (e v) `(cdr (rplacd ,(cadr e) ,v))) (defsetf cdar (e v) `(cdr (rplacd (car ,(cadr e)) ,v))) (defsetf cddr (e v) `(cdr (rplacd (cdr ,(cadr e)) ,v))) (defsetf cxr (e v) `(cxr ,(cadr e) (rplacx ,(cadr e) ,(caddr e) ,v))) . . . (defsetf nth (e v) `(car (rplaca (nthcdr ,(cadr e) ,(caddr e)) ,v))) (defsetf nthelem (e v) `(car (rplaca (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v))) (defsetf nthcdr (e v) `(cdr (rplacd (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v))) . . . ; (defsetf args (e v) `(args ,(cadr e) ,v)) ; no longer implemented? ==================== Steven Haflich MIT Experimental Music Studio (617)253-7441 smh@mit-ems@mit-mc decvax!genrad!mit-ems!smh From fateman@ucbdali Thu Mar 29 12:07:33 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA20323; Thu, 29 Mar 84 12:07:33 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA22790; Thu, 29 Mar 84 12:07:08 pst Received: by ucbdali.ARPA (4.24/4.22) id AA04139; Thu, 29 Mar 84 12:07:10 pst Date: Thu, 29 Mar 84 12:07:10 pst From: fateman@ucbdali (Richard Fateman) Message-Id: <8403292007.AA04139@ucbdali.ARPA> To: franz-friends@BERKELEY Subject: commercialization of Franz Status: O Some people may have gotten the incorrect impression that the University of California will cease sending out tapes of Franz Lisp. We intend to continue distribution of the latest version which is the property of UCB. This is currently opus 38.91. This distribution works, so far as we know, on SUN releases (0.4, 1.0, 1.1) and Masscomp, and VAX 4.2BSD. Such distributions will continue, and will continue to be unsupported. Although we have made reasonable efforts to provide a useful, portable, efficient, and complete system, we have spent too much of our time and our sponsors' money in answering questions about installation-dependent difficulties or (what USUALLY turns out to be non-existent) bugs. I might point out that many of the questions come from commercial users. Franz Inc. was formed to provide a mechanism for support, transportation of Franz Lisp to new architectures, enhancements, documentation, etc. It has the (non-exclusive) right to use, distribute, (etc) Franz Lisp, and intends to produce enhancements that the University does not have funding for. I expect that if enhancements of Franz Lisp at UCB are produced, these will next be made available on 4.3 BSD tapes. Earlier distributions of contributed software or locally produced software MAY occur, but cannot be promised. I expect that there will continue to be a large number of Franz Lisp users who are satisfied with the university distribution (on 4.2BSD) or on the separate tapes (e.g. after opus 38.79) that UCB is sending out. Others will want the enhanced, supported, version from Franz Inc. The divergence of versions, some of which has already occurred with local variants of older systems being redistributed, seems inevitable regardless of Franz Inc. I hope this clarifies UCB's position. From @MIT-MC:smh@MIT-EMS Wed Apr 4 15:44:42 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA07196; Wed, 4 Apr 84 15:44:42 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA01892; Wed, 4 Apr 84 15:14:05 pst Message-Id: <8404042314.AA01892@UCB-VAX.ARPA> Date: 4 Apr 1984 16:44:49-EST From: To: franz-friends@BERKELEY Subject: Re: recent suggested fix to setf Status: O There was one mistake in my recent posting with fixes for the Franz setf function. I said that it was not necessary to remake liszt (the compiler). This was wrong: code compiled with an old copy of liszt will not use the modified setf definitions. The fix is simply to remake liszt after the new Franz interpreter has been generated. Sorry about any confusion. Steve Haflich MIT Experimental Music Studio decvax!genrad!mit-ems!smh smh@mit-ems@mit-mc From MCLINDEN@RUTGERS.ARPA Wed Apr 18 20:37:26 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA16547; Wed, 18 Apr 84 20:37:26 pst Received: from RUTGERS.ARPA (rutgers.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA29663; Wed, 18 Apr 84 20:36:21 pst Message-Id: <8404190436.AA29663@UCB-VAX.ARPA> Date: 18 Apr 84 23:37:14 EST From: Sean McLinden Subject: [Sean McLinden : Re: Franz on Suns under 4.2?] To: franz-friends@BERKELEY Status: O Mail-From: MCLINDEN created at 18-Apr-84 23:33:56 Date: 18 Apr 84 23:33:56 EST From: Sean McLinden Subject: Re: Franz on Suns under 4.2? To: allegra!jdd@UCB-VAX.ARPA cc: MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "allegra!jdd@Berkeley (John DeTreville)" of 18 Apr 84 13:10:10 EST I must be missing something with all of this discussion of Franz Lisp on Suns. We have had no trouble at all running the current (opus 38.91?) Berkeley release on Suns and have been running Sun Franz Lisp for nearly a year now. The only serious problem that I can recall happened a few sub versions ago and was due to a logical error in the C-coded algorithm which determined when to garbage collect (as things would have it, it never did). The result was that liszt was unable to compile some of the lisp coded sources due to the 2 Meg/process limit imposed by the Sun operating system (the bug existed in the Vax version as well but one would only see it if the lisp image exceeded 6 megs which is rare for a compiler run). Perhaps you could be more explicit in describing what, exactly, the problem is. The people at Berkeley most probably have Suns and I am sure that they don't release Sun versions without testing them. Sean McLinden Decision Systems Lab University of Pittsburgh School of Medicine ------- ------- From varghese%colostate.csnet@csnet-relay.arpa Fri May 25 18:47:11 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20472; Fri, 25 May 84 18:47:11 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA23631; Fri, 25 May 84 18:45:35 pdt Message-Id: <8405260145.AA23631@UCB-VAX.ARPA> Received: From colostate.csnet by csnet-relay; 25 May 84 21:17 EDT Date: Fri, 25 May 84 13:47:24 mdt From: varghese%colostate.csnet@csnet-relay.arpa Received: by csu-cs.UUCP (4.12/3.14) id AA11606; Fri, 25 May 84 13:47:24 mdt To: FRANZ-FRIENDS.BERKELEY@csnet-relay.arpa Subject: Addition to mailing list Please add us to the mailing list. Since there will be more than one person at this site who wants to be on the mailing list we decided to get everything mailed to one central mailbox. The mailbox address for this mailing list is frnzlist@colostate Please note that this is a CSnet address. Thank you, Joe Varghese varghese@colostate From trk@cmu-cs-g.arpa Sun Jun 3 19:15:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA07648; Sun, 3 Jun 84 19:15:03 pdt Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA24832; Sun, 3 Jun 84 19:13:42 pdt Date: 3 Jun 1984 22:02-EST From: Todd.Kueny@CMU-CS-G.ARPA Subject: Please add my name to the list To: FRANZ-FRIENDS@BERKELEY Message-Id: <455162572/trk@CMU-CS-G> Please add my name to the FRANZ-FRIENDS list. -Todd K. From Jonl.pa@Xerox.ARPA Sun Jun 3 23:24:19 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA09575; Sun, 3 Jun 84 23:24:19 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA27487; Sun, 3 Jun 84 23:22:53 pdt Message-Id: <8406040622.AA27487@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT Date: 3 Jun 84 23:22 PDT From: Jonl.pa@XEROX.ARPA Subject: This is a test To: Franz-Friends@BERKELEY Sorry to bother you -- this is only a test of correct forwarding on this mailing list. From @MIT-MC:sl@cmu-ri-isl1.arpa Mon Jun 18 17:09:37 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA21265; Mon, 18 Jun 84 17:09:37 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA19453; Mon, 18 Jun 84 17:07:25 pdt Message-Id: <8406190007.AA19453@UCB-VAX.ARPA> Date: 18 Jun 1984 12:48:57-EDT From: Simon.Lowenfeld@CMU-RI-ISL1 Subject: old messages Apparently-To: Is there some kind of archive for old postings? I am interested in the Franz/T argument from earlier this year. From wkc@Ardc.ARPA Tue Jun 19 07:36:37 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA01983; Tue, 19 Jun 84 07:36:37 pdt Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA01762; Tue, 19 Jun 84 07:34:31 pdt Message-Id: <8406191434.AA01762@UCB-VAX.ARPA> Date: Tue, 19 Jun 84 10:31:27 EDT From: William K. Cadwallender (LCWSL) To: franz-friends@BERKELEY Subject: Franz for VAX730 We are about to purchase a VAX730 with BSD4.2 UNIX. Has anyone out thereheard of a port of Franz, or ANY LISP to a 730? Please reply to the net or directly to wkc@ARDC. Bill Cadwallender (wkc@ARDC) From RZ@MIT-MC Thu Jun 21 19:26:57 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA08546; Thu, 21 Jun 84 19:26:57 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA27996; Thu, 21 Jun 84 19:24:37 pdt Message-Id: <8406220224.AA27996@UCB-VAX.ARPA> Date: 21 June 1984 22:28-EDT From: Richard E. Zippel Subject: MIT flavors To: franz-friends@BERKELEY Cc: zymelman@MITRE, smh@MIT-VAX In-Reply-To: Msg of 21 Jun 1984 9:19:16 EDT () from Ari Zymelman I am happy to report than the MIT flavor system is finally available. I won't try to correct the numerous bits of misinformation that have been spread about this other than to say that the MIT flavor system can now be freely distributed, if it is not used for profit, and the MIT copyrights are maintained in the sources. Berkeley has a copy of the most recent version of the code and should include it in their standard distributions shortly. From hoey@nrl-aic Wed Jun 27 14:24:24 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA19372; Wed, 27 Jun 84 14:24:24 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA13744; Wed, 27 Jun 84 14:21:16 pdt Message-Id: <8406272121.AA13744@UCB-VAX.ARPA> Date: 27 Jun 1984 16:42-EDT From: Dan Hoey Subject: Incorrect "make fromasm" in 68k franz 38.91 To: franz-friends@BERKELEY Cc: dejong@nrl-aic, franz-bugs@BERKELEY Problem: The "make fromasm" option for franz installation on a 68k does not work as distributed. Diagnosis: The assembler is used to convert *.s files into *.o. But the output of as defaults to "a.out" and is not overridden, so no *.o files are produced. Fixes: Specify the output file in the fromasm: option in lisplib/Makefile and liszt/68k/Makefile. In lisplib/Makefile, and (if make copylibrary has been done) in /usr/lib/lisp/Makefile, change < for i in *.s; do echo $$i; ${LibDir}/as $$i; done ---- > for i in *.s; do echo $$i; \ > ${LibDir}/as $$i -o `basename $$i .s`.o; done In liszt/68k/Makefile, change < for i in *.s; do echo $$i; as $$i; done ---- > for i in *.s; do echo $$i; \ > as $$i -o `basename $$i .s`.o; done Bugs: 1. One version specifies ${LibDir}/as, the other uses vanilla as. I didn't change it, but perhaps the liszt/68k/Makefile should also specify ${LibDir}/as. 2. Isn't there a cleaner way of doing this? Can a ".s.o:" rule be specified? Dan From @MIT-MC:rsw@cmu-cs-h.arpa Mon Jul 9 22:06:26 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA17486; Mon, 9 Jul 84 22:06:26 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA24170; Mon, 9 Jul 84 22:05:52 pdt Message-Id: <8407100505.AA24170@UCB-VAX.ARPA> Date: 9 Jul 1984 21:10:53-EDT From: Richard.Wallace@CMU-CS-H Subject: Bell quote Apparently-To: Lisp, designed about 1960 by John McCarthy, impressed me so much that I included the critcal data access primitives in the architecture of the DEC System 10 in 1965 (still about the fastest Lisp computer). - C. Gordon Bell IEEE Computer June, 1984 From kanderso@bbn-vax Tue Jul 10 11:41:39 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA25755; Tue, 10 Jul 84 11:41:39 pdt Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA06454; Tue, 10 Jul 84 11:29:28 pdt Message-Id: <8407101829.AA06454@UCB-VAX.ARPA> Date: Tue, 10 Jul 84 14:28 EDT From: Ken Anderson Subject: Problem compiling flavors in Opus 83.79 To: franz-friends@BERKELEY Cc: franz-composers@BERKELEY, lbagnall@bbn, jchung@bbn When trying to make flavors from the version in pub/lib on ucbkim, liszt complains about calling an undefined function e-sub2. Here is the output of my makefile. Any suggestions? liszt -a flavorm Compilation begins with Liszt vax version 8.36 source: flavorm.l, result: flavorm.o [fasl /usr/lib/lisp/machacks.o] [autoload /usr/lib/lisp/struct] [fasl /usr/lib/lisp/struct.o] flavor-plist flavor-init-keywords flavor-initable-instance-variables flavor-settable-instance-variables flavor-gettable-instance-variables flavor-default-handler flavor-which-operations flavor-depends-on-all flavor-includes flavor-depended-on-by flavor-depends-on flavor-method-table flavor-all-instance-variables flavor-local-instance-variables flavor-name flavor-method-hash-table flavor-bindings make-flavor alter-flavor instancep instancep::cmacro:g00079 send lexpr-send send-self lexpr-send-self g00100::send %Note: flavorm.l: Compilation complete %Note: flavorm.l: Time: Real: 0:32, CPU: 0:11.10, GC: 0:0.00 for 0 gcs %Note: flavorm.l: Assembly begins %Note: flavorm.l: Assembly completed successfully liszt -a flavors Compilation begins with Liszt vax version 8.36 source: flavors.l, result: flavors.o [fasl /usr/lib/lisp/machacks.o] [fasl /usr/lib/lisp/lmhacks.o] [fasl flavorm.o] defflavor defun-method [autoload /usr/lib/lisp/struct] [fasl /usr/lib/lisp/struct.o] instance-variable-boundp instance-flavor instance-flavor::cmacro:g00068 instance-function instance-function::cmacro:g00075 get-flavor instance-typep flavor-additional-instance-variables flavor-additional-instance-variables::cmacro:g00101 flavor-instance-variable-initializations flavor-instance-variable-initializations::cmacro:g00108 flavor-remaining-default-plist flavor-remaining-default-plist::cmacro:g00115 flavor-remaining-init-keywords flavor-remaining-init-keywords::cmacro:g00122 flavor-all-initable-instance-variables flavor-all-initable-instance-variables::cmacro:g00129 g00133::flavor Undefined function called from compiled code e-sub2 ?Error: flavors.l: : Lisp error during compilation make: *** Error code 1 *** From jkf@ucbmike Tue Jul 10 12:18:28 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA27111; Tue, 10 Jul 84 12:18:28 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA07135; Tue, 10 Jul 84 12:06:28 pdt Date: Tue, 10 Jul 84 12:07:07 pdt From: John Foderaro (on an sun) Message-Id: <8407101907.3780@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA03780; Tue, 10 Jul 84 12:07:07 pdt To: kanderso@bbn-vax, franz-friends@BERKELEY Subject: Re: Problem compiling flavors in Opus 83.79 Cc: jchung@bbn, lbagnall@bbn, franz-composers@BERKELEY In-Reply-To: Your message of Tue, 10 Jul 84 14:28 EDT This bug was fixed a while back, but apparently after you got your lisp distribution. You should get the latest lisp distribution. From @MIT-MC:stw@cmu-cs-spice.arpa Tue Jul 10 13:29:15 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA28822; Tue, 10 Jul 84 13:29:15 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA08350; Tue, 10 Jul 84 13:28:25 pdt Message-Id: <8407102028.AA08350@UCB-VAX.ARPA> Date: 10 Jul 1984 13:46:05-EDT From: Suzanne.Woolf@CMU-CS-SPICE Subject: pretty printer Apparently-To: Does anyone out there know of a well-documented pretty printer for lisp? A friend of mine needs one that can be hacked up. Franz Lisp would be ideal, but anything similar is fine. Please send replies to: Jaffe@cmu-psy-a Thanks. From @MIT-MC:smh@MIT-EMS Tue Jul 10 15:29:20 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA02481; Tue, 10 Jul 84 15:29:20 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA10890; Tue, 10 Jul 84 15:28:30 pdt Message-Id: <8407102228.AA10890@UCB-VAX.ARPA> Date: 10 Jul 1984 18:24:02-EDT From: To: franz-friends@BERKELEY, kanderso@bbnvax Subject: Re: Problem compiling flavors in Opus 83.79 A very quick check reveals the following suspiciousness: The function in flavors.l being compiled when the failure occurs is apparently: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS) (SELECTQ OPERATION (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE)) (:PRINT-SELF (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS)) (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF)))) (:DESCRIBE (DESCRIBE-FLAVOR SELF)) (OTHERWISE (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION)))) This is the first appearance in the file of defun with a "function spec" instead of a symbol as the first argument. This is a Lisp Machine hack which basically means to squirrel the functional object away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR. (More precisely, the first arg is the Maclisp compatability syntax for (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...) Liszt could be choking as it tries to store into the function-definition slot of something other than a symbol. Such abilities of defun are not documented in Franz, and it might be that your defun macro in common0.l has not been extended for such usage. Locally it is defined as follows: ;--- defun ; maclisp style function defintion ; (def defun (macro (l) (prog (name type arglist body specind specnam) (setq name (cadr l) l (cddr l)) (cond ((dtpr name) (cond ((memq (cadr name) '(macro expr fexpr lexpr)) (setq l (cons (cadr name) l) name (car name))) (t (setq specnam (car name) specind (cadr name) name (concat (gensym) "::" specnam)))))) (cond ((null (car l)) (setq type 'lambda)) ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l))) ((eq 'expr (car l)) (setq type 'lambda l (cdr l))) ((eq 'macro (car l)) (setq type 'macro l (cdr l))) ((atom (car l)) (setq type 'lexpr l (nconc (list (list (car l))) (cdr l)))) (t (setq type 'lambda))) (setq body (list 'def name (cons type l))) (cond (specnam (return (list 'progn ''compile body (list 'putprop (list 'quote specnam) (list 'getd (list 'quote name)) (list 'quote specind))))) (t (return body)))))) You could also check by invoking liszt without arguments and then asking it (testmac '(defun (foo bar) () (hello goodbye))) and seeing if it properly generates (progn 'compile (defun ... ) (putprop ... )) On another matter, I have recently been making a number of minor bugfixes to the flavor and various other MIT compatibility packages. These files come indirecly from Maclisp or Lisp Machines, and the ports have generally never been exercised sufficiently to check all the obscure features. These fixes postdate the versions Rich Zippel recently transmitted to Berkeley. I will shortly distribute the new versions to Berkeley. Believe it or not, the flavor system really does work under Franz. So do hash tables, defstruct, format, etc. I use them every day. Steve Haflich, MIT Experimental Music Studio smh@mit-ems@mit-mc {decvax!genrad, ihnp4}!mit-eddie!smh From abar@ucbernie Tue Jul 10 23:04:16 1984 Received: from ucbernie.ARPA by ucbkim.ARPA (4.28/4.27) id AA08764; Tue, 10 Jul 84 23:04:16 pdt Received: by ucbernie.ARPA (4.28/4.30) id AA06176; Tue, 10 Jul 84 23:02:56 pdt Date: Tue, 10 Jul 84 23:02:56 pdt From: abar@ucbernie (Robert Abarbanel) Message-Id: <8407110602.AA06176@ucbernie.ARPA> To: franz-friends@ucbernie Subject: &optional, &rest, &aux Any way to get these &args to work without compilation... that is, when a function is working interpreted? From kanderso@bbn-vax Wed Jul 11 12:25:52 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA17391; Wed, 11 Jul 84 12:25:52 pdt Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA19991; Wed, 11 Jul 84 12:24:54 pdt Message-Id: <8407111924.AA19991@UCB-VAX.ARPA> Date: Wed, 11 Jul 84 15:24 EDT From: Ken Anderson Subject: bugs in hash.l and array.l To: franz-friends@BERKELEY Cc: lbagnall@bbn, jchung@bbn To get Flavors working in Opus 38.91 you will need to fix a bug in lisplib/hash.l. Change all occurances of "getlength" to "vsize". Although unrelated to Flavors, there are several problems with the functions, fillarray fillarrayarray and listarray in lisplib/array.l. Here is an ed script produced by diff: 285,286c (cond ((or (arrayp arr) ; KRA (and (symbolp arr) (arrayp (setq arr (getd arr)))))) . 282,283c (lexpr (n) (prog (arr size typ ret newv) . 280a ; KRA 83-11-2: Arrays need not be symbols. . 279c (replace (arrayref arrto i) (arrayref arrfrom i))) (return arrto)))) ; KRA . 270c (cond ((cdr ls) (setq ls (cdr ls))))) (return arr)))) ; KRA . 244a ; KRA 83-11-2: Fillarray and fillarrayarray should return the array! . From jkf@ucbmike Wed Jul 11 13:43:49 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA20014; Wed, 11 Jul 84 13:43:49 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA21120; Wed, 11 Jul 84 13:32:32 pdt Date: Wed, 11 Jul 84 13:32:52 pdt From: John Foderaro (on an sun) Message-Id: <8407112032.5402@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA05402; Wed, 11 Jul 84 13:32:52 pdt To: franz-friends@BERKELEY Subject: Re: &optional, &rest, &aux Cc: franz-composers@BERKELEY In-Reply-To: Your message of 11 Jul 1984 15:12:07-EDT The problem with the &optional and &rest was due to abar using the cmufile package, which redefines 'def' and doesn't look for those keywords. From uucp-5@cmu-cs-g.arpa Wed Jul 11 20:29:28 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA25212; Wed, 11 Jul 84 20:29:28 pdt Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA28089; Wed, 11 Jul 84 20:28:27 pdt Reply-To: cadre!sm@CMU-CS-G.ARPA Received: by cadre.UUCP (4.12/3.14) id AA22394; Wed, 11 Jul 84 23:22:09 edt Date: Wed, 11 Jul 84 23:22:09 edt From: cadre!sm (Sean McLinden) Message-Id: <8407120322.AA22394@cadre.UUCP> To: jkf@ucbmike.BERKELEY Subject: redefinition of existing flavors Cc: franz-friends@BERKELEY As distributed by Berkeley, the flavors package on Opus 38.89 appears to work in all cases except when a flavor is redefined and perform-flavor-redefinition is invoked. The problem, I thought, was in copy-hunk-contents, since the default structures (and therefore flavors), in Opus 38.89, are VECTORS, not HUNKS. However, modifying copy-hunk-contents to copy VECTORS did not, completely, fix the problem (i.e, the first modification after redefinition of copy-hunk-contents caused an error, the second worked but then describe did not work for old instances of the flavor). Before delving into code with which I am unfamiliar are there any differences between Opus 38.89 and 38.91 which might explain this? Sean McLinden Decision Systems Lab University of Pittsburgh From harrison@nrl-aic Thu Jul 12 07:15:39 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA28967; Thu, 12 Jul 84 07:15:39 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA07280; Thu, 12 Jul 84 07:14:50 pdt Date: 12 Jul 1984 10:08-EDT From: Patrick Harrison Subject: Lisp for Honeywell 6060 DPS-8 To: ailist@sri-ai Cc: franz-friends@BERKELEY Message-Id: <84/07/12 1008.550@NRL-AIC> Am looking for information on current versions of LISP (FranzLisp, MacLisp) running in a Honeywell 6060, DPS-8 environment. Would also like to implement OPS5 on same. Address: Dr. Patrick Harrison Computer Science Department U.S. Naval Academy Annapolis, Maryland 21402. Responses to above address or From @MIT-MC:mhs@MIT-HTVAX Tue Jul 17 12:45:10 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA00659; Tue, 17 Jul 84 12:45:10 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA02214; Mon, 16 Jul 84 16:28:19 pdt Message-Id: <8407162328.AA02214@UCB-VAX.ARPA> Date: 16 Jul 1984 16:32:48-EDT From: mhs@mit-htvax@mit-mc To: franz-friends@berkeley@mit-mc Subject: Small bug in flavors.l Cc: mhs@mit-htvax@mit-mc The following test demonstrates a problem with flavors.l as it is distributed with Release 38.91. (The "a" after the minor number indicates a couple of changes made locally - mostly involving preloading struct, loop and such. flavors.l wasn't touched.) The problem is that simple method combination doesn't work for trivial reasons. A fix is suggested below. As the example shows, the combined method for :PROGN combination is wrong. (:OR, :LIST ... all have the same problem). Franz Lisp, Opus 38.91a (with Zetalisp compatability package) -> (defflavor object (color) () :gettable-instance-variables :settable-instance-variables :initable-instance-variables (:method-combination (:progn :base-flavor-last :test1))) object -> (defmethod (object :test1) () (format t "~&object :test1~%")) (:method object :test1) -> (defflavor car (price) (object) :gettable-instance-variables :settable-instance-variables :initable-instance-variables) car -> (defmethod (car :test1) () (format t "~&car :test1~%")) (:method car :test1) -> (setq car (make-instance 'car)) # -> (send car ':test1) |Error:| eval: Undefined function :progn <1>: (debug) <------debug------> :bk <------debug------> <--- you are here (eval (debug)) (break-err-handler (|ER%undef| 0 t |eval: Undefined function | :progn)) (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.)) ((lambda (.daemon-caller-args.) .daemon-caller-args. (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.))) (do ((g00005 g00004 (|1-| g00005)) (g00006 () (cons (arg g00005) g00006))) ((< g00005 1) g00006))) , , , (send car (quote :test1)) (eval (send car (quote :test1))) Look at the combined method: (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.)) I think the problem is caused by the fact that in the older package system, the keyword package inherited from the global package. Thus :PROGN (in the keyword package) was the same atom as PROGN (in global). However, this isn't true in Franz. :PROGN isn't EQ to PROGN, and it shouldn't be. (The same problem occurs for all of the other simple method combination types too, e.g. :OR, :LIST ...). One possible fix is to add an alist (SIMPLE-METHOD-COMBINATION-TYPE-ALIST) to store the correspondence between :PROGN and PROGN, like so: (I just tested this code locally and it seemed to work.) #+franz (DEFCONST SIMPLE-METHOD-COMBINATION-TYPE-ALIST '((:PROGN . PROGN) (:AND . AND) (:OR . OR) (:MAX . MAX) (:MIN . MIN) (:+ . +) (:APPEND . APPEND) (:NCONC . NCONC))) (DEFUN SIMPLE-METHOD-COMBINATION (FL MAGIC-LIST-ENTRY) (LET ((METHODS (GET-CERTAIN-METHODS MAGIC-LIST-ENTRY NIL NIL NIL NIL)) (WRAPPERS-P (SPECIALLY-COMBINED-METHODS-PRESENT MAGIC-LIST-ENTRY))) (OR (AND (NOT WRAPPERS-P) (NULL (CDR METHODS)) (CAR METHODS)) (HAVE-COMBINED-METHOD FL MAGIC-LIST-ENTRY) (MAKE-COMBINED-METHOD FL MAGIC-LIST-ENTRY ;; In the old package system, :progn maps to progn trivially ;; via package inheritance (keyword inherits from global). ;; In Franz, we use an alist to implement the mapping. (CONS #-franz (CADR MAGIC-LIST-ENTRY) #+franz (CDR (ASSQ (CADR MAGIC-LIST-ENTRY) SIMPLE-METHOD-COMBINATION-TYPE-ALIST)) (MAPCAR 'METHOD-CALL METHODS)))))) From "Gladd Tom"@LLL-MFE.ARPA Wed Jul 18 10:44:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA00765; Wed, 18 Jul 84 10:44:03 pdt Received: from LLL-MFE.ARPA (lll-mfe.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA01412; Wed, 18 Jul 84 10:42:20 pdt Message-Id: <8407181742.AA01412@UCB-VAX.ARPA> Date: Wed, 18 Jul 84 10:35 PDT From: "Gladd Tom"@LLL-MFE.ARPA Subject: join list 619-453-6580 To: franz-friends@BERKELEY i would like to join your list. i am very interested in list in general and have been trying to learn it in a near vacuum (small hi-tech company in sandiego. i am especially interested in advanced coding techniques (at least beyond the standard texts). my background is theoretical plasma physics. i have used and am very interested in macsyma. my address is "gladd tom%cma"@lll-mfe.arpa From @MIT-MC:pmk@cmu-ri-isl2.arpa Wed Jul 25 10:06:41 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA08698; Wed, 25 Jul 84 10:06:41 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA19747; Wed, 25 Jul 84 10:05:06 pdt Message-Id: <8407251705.AA19747@UCB-VAX.ARPA> Date: 25 Jul 1984 12:30:25-EDT From: Philip.Kasprzyk@CMU-RI-ISL2 Subject: Lisp Speed Benchmarks Apparently-To: ~v I am interested in determining the absolute speed of execution of a lisp system. I realize that this is a complicated task that is application and implementation dependant. Nevertheless I am seeking the following: 1) A "gibson mix" style benchmark for lisp based systems. 2) Any data that experienced users of lisp may have regarding performance. (I don't care what machine or dialect of lisp is reported) 3) Any method or program which translates a lisp program into another target high level language with execution speed as its objective. (I don't mean a normal lisp compiler) Can anyone out there help me? If so send mail to pmk@isl2. From mab@aids-unix Fri Jul 27 14:35:21 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA29865; Fri, 27 Jul 84 14:35:21 pdt Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04068; Fri, 27 Jul 84 14:33:40 pdt Message-Id: <8407272133.AA04068@UCB-VAX.ARPA> Date: 27 Jul 84 14:23:47 PDT (Fri) From: Mike Brzustowicz Subject: Benchmarks To: franz-friends@BERKELEY Does anyone have any small LISP programs that can be abused as benchmarks? (They need to be small is source only.) I need some very soon. Thanks! -Mike From Masinter.pa@Xerox.ARPA Fri Jul 27 15:15:06 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA01124; Fri, 27 Jul 84 15:15:06 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04900; Fri, 27 Jul 84 15:13:09 pdt Message-Id: <8407272213.AA04900@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT Date: 27 Jul 84 15:14 PDT From: Masinter.pa@XEROX.ARPA Subject: Re: Benchmarks In-Reply-To: Mike Brzustowicz 's message of 27 Jul 84 14:23:47 PDT (Fri) To: mab@AIDS-UNIX.ARPA Cc: franz-friends@BERKELEY Here's a good benchmark: (defun nilret () nil) this is a good test of how fast your lisp returns NIL. I also like (defun retjunk (x) (cond((junkp x) 'junk) ((cdr x) (retjunk (car x))) ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x)))) (t (retjunk (cons 'junk x)))) (defun junkp (x) (equal (reverse (explode x)) (reverse (explode 'junk)))) This benchmark measures how fast your lisp can return junk, executing the retjunk function. Both of the benchmarks have the adavantage that they are small and can be abused as benchmarks. From @USC-ECL.ARPA:BENSON@ECLD Tue Jul 31 20:02:20 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA21521; Tue, 31 Jul 84 20:02:20 pdt Received: from USC-ECL.ARPA (usc-ecl.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA02839; Tue, 31 Jul 84 20:00:29 pdt Message-Id: <8408010300.AA02839@UCB-VAX.ARPA> Received: from ECLD by ECLA with ECLnet; Tue 31 Jul 84 19:56:31-PDT Date: Tue 31 Jul 84 19:33:52-PDT From: Eric Benson Subject: Re: Lisp Speed Benchmarks To: Philip.Kasprzyk@CMU-RI-ISL2.ARPA Cc: BENSON@ECLD.#ECLnet, Franz-Friends@BERKELEY In-Reply-To: Message from "Philip.Kasprzyk@CMU-RI-ISL2" of Wed 25 Jul 84 09:30:25-PDT There is a set of benchmarks which have been run on a variety of Lisp systems which have been compiled by Richard Gabriel at Stanford. You should contact Paul Wieneke (PW@SU-AI) for more information. ------- From narain@rand-unix Wed Aug 1 12:31:21 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@BERKELEY Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain From fateman@ucbdali Wed Aug 1 13:24:30 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03438; Wed, 1 Aug 84 13:24:30 pdt Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA01542; Wed, 1 Aug 84 13:06:01 pdt Received: by ucbdali.ARPA (4.24/4.27) id AA00994; Wed, 1 Aug 84 13:07:35 pdt Date: Wed, 1 Aug 84 13:07:35 pdt From: fateman@ucbdali (Richard Fateman) Message-Id: <8408012007.AA00994@ucbdali.ARPA> To: franz-friends@BERKELEY, narain@rand-unix Subject: Re: Fast recompiling This would be an interesting feature, but it is complicated by the possibility that the compilation environment is built up in a typical large Franz system, by processing the whole file. I think that the interlisp situation is usually simpler. For example, in recompiling Macsyma, sometimes a file itself or function definitions in it do not change at all. A "macro definition" file which is included in the compilation environment can, however, change the generated code, substantially. Something like UNIX's "make" might be needed. Alternatively, you can use smaller files... From jkf@ucbmike Thu Aug 2 16:10:04 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16097; Thu, 2 Aug 84 16:10:04 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00501; Thu, 2 Aug 84 16:08:09 pdt Date: Thu, 2 Aug 84 16:09:45 pdt From: John Foderaro (on an sun) Message-Id: <8408022309.1757@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA01757; Thu, 2 Aug 84 16:09:45 pdt To: franz-friends@BERKELEY Subject: repeated messages Cc: I'm sorry about the repeated messages. Our mailing machine got a bit overloaded. I've modified the organization of the list to try to fix the problem. From NET-ORIGIN@MIT-MC Fri Aug 3 15:15:44 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26463; Fri, 3 Aug 84 15:15:44 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04086; Fri, 3 Aug 84 15:13:41 pdt Received: from mit-heracles (mit-heracles.ARPA) by mit-charon (4.12/4.7) id AA13781; Fri, 3 Aug 84 14:32:51 edt Received: by mit-heracles (4.12/4.7) id AA20045; Fri, 3 Aug 84 14:35:30 edt From: yba@mit-heracles (Mark H Levine) Message-Id: <8408031835.AA20045@mit-heracles> Date: 3 Aug 1984 1435-EDT (Friday) To: franz-friends@BERKELEY Subject: Opus 37.79 building from source Has anyone published a fix to the bug that causes "rawlisp" to take a memory fault when built from vanilla 4.2bsd sources? It seems that the routine "getatom" in franz/alloc.c calls strcmp with "name" equal to "mod" and "aptr -> a.pname" equal to CNIL (-4). This is presumably a side effect of some other error; it still causes a memory fault in strcmp and prevents building from source. The sources have some Sept. '83 changes to the library code, but are otherwise con- sistent with all the 4.2 code I have seen. Got a fix handy? From liz@maryland Mon Aug 6 07:41:41 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16830; Mon, 6 Aug 84 07:41:41 pdt Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA06949; Mon, 6 Aug 84 07:39:52 pdt Received: by maryland.ARPA (4.12/4.7) id AA01505; Mon, 6 Aug 84 10:40:52 edt Date: Mon, 6 Aug 84 10:40:52 edt From: liz@maryland (Liz Allen) Message-Id: <8408061440.AA01505@maryland.ARPA> To: franz-friends@BERKELEY, yba%mit-heracles@csnet-relay.ARPA Subject: Re: Opus 37.79 building from source That sounds like an error I ran into recently -- only it was with Opus 38.91 and it was also because I was adding more strings to rawlisp. Anyway, the fix was easy and is probably worth trying. Go into franz/data.c and change the size of i_strbuf and make it bigger. Ours was 600, and I made it 1000. You'll also need to change the initialization for i_strbuf; I changed ours from "i_strbuf + 599" to "i_strbuf + 999". Hope this helps! -Liz From smotroff@bbncct Wed Aug 8 14:39:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23393; Wed, 8 Aug 84 14:39:03 pdt Received: from bbncct (bbncct.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA21105; Wed, 8 Aug 84 14:39:58 pdt Message-Id: <8408082139.AA21105@UCB-VAX.ARPA> Date: Wed, 8 Aug 84 17:28:58 EDT From: Ira Smotroff Subject: add me to the list To: franz-friends@BERKELEY please add my name to the franz-friends list smotroff at bbn From booker@nrl-aic Fri Aug 10 06:18:45 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13113; Fri, 10 Aug 84 06:18:45 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA14441; Fri, 10 Aug 84 06:19:43 pdt Message-Id: <8408101319.AA14441@UCB-VAX.ARPA> Date: 10 Aug 1984 09:09:24-PDT From: Lashon Booker To: franz-friends@BERKELEY Subject: Interlisp Compatibility Package? Has anyone written an Interlisp compatibility package for Franz? Thanks. Lashon Booker booker@nrl-aic From @MIT-MC:smh@MIT-EMS Fri Aug 10 13:14:44 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01017; Fri, 10 Aug 84 13:14:44 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA21922; Fri, 10 Aug 84 13:15:43 pdt Message-Id: <8408102015.AA21922@UCB-VAX.ARPA> Date: 10 Aug 1984 16:06:48-EDT From: smh@mit-ems@mit-mc To: franz-friends@BERKELEY Subject: (atom VECTOR): franz vs liszt Versions: Franz 38.91, Liszt 8.39, and probably most others. Description: The atom predicate operates inconsistently between compiled and interpreted code when passed a vector or vectori. Repeat-by: Create and compile a file containing the following definition: (defun atum(x) (atom x)) After loading it into the interpreter the following results can be obtained: (setq v (vector 1 2 3)) (atom v) ===> t (atum v) ===> nil Discussion: According to the manual, atom returns "t iff g_arg is not a list or hunk object." By this definition, the interpreter is correct and the compiler incorrect. However, one can make a strong argument that vectors, analogously to hunks, should not be considered atoms. Therefore, the both the documentation and interpreter should be changed. (It is doubtful very much existing code depends on this.) Suggested fix: Change the definition of atom section 2 of the manual to read: "t iff g_arg is not a list, hunk, vector, or vectori object." Add the following definition to franz/h/global.h, after the existing definition of HUNKP: #define HUNKORVECP(a1) ((TYPE(a1) >= 11) & (TYPE(a1) <= 19)) Change the definition of Latom in franz/lam1.c: lispval Latom() { register struct argent *lb = lbot; chkarg(1,"atom"); ==> if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val))) return(nil); else return(tatom); } Alternative suggested fix: If franz-composers really feel that atom ought to treat hunks and vectors differently (sigh?), then fix the compiler instead of the interpreter and documentation. The most important thing is that interpreted and compiler do the same thing! In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition of the mask constant. Random (constructive) flame: The interpreter definition above has to lookup the type of its argument expensively in the typetable *three* times, to wit: #define ATOX(a1) ((((int)(a1)) - OFFSET) >> 9) #define TYPE(a1) ((typetable+1)[ATOX(a1)]) While compiled code is admirably streamlined, the interpreter could be made significantly faster here and elsewhere if TYPE were evaluated only once and held for examination in a temporary. This would require a bunch more type predicate DEFINEs operating on TYPE values instead of object addresses. Steve Haflich smh%mit-ems@mit-mc {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh From JonL.pa@Xerox.ARPA Mon Aug 13 13:25:44 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03640; Mon, 13 Aug 84 13:25:44 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05890; Mon, 13 Aug 84 13:26:52 pdt Message-Id: <8408132026.AA05890@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 13 AUG 84 13:24:39 PDT Date: 13 Aug 84 13:24 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 10 Aug 84 16:06:48 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: franz-friends@BERKELEY, GSB@MIT-ML.ARPA, ALAN@MIT-MC.ARPA Perhaps this bug should be forwarded to BUG-LISP@MIT-MC, since the original design flaw is in MacLisp. The problem is that when Hunks were first invented, there where some who wanted them as "annotated" list cells (hence, they weren't ATOMs) while other wanted them as small VECTORs (hence there should be ATOMs). The resolution was some awful switch setting for whether or not to treat them as ATOMs, but I don't remember the default setting, nor the final results. -- JonL -- From ALAN@MIT-MC Mon Aug 13 17:15:11 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07443; Mon, 13 Aug 84 17:15:11 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA10564; Mon, 13 Aug 84 17:16:03 pdt Message-Id: <8408140016.AA10564@UCB-VAX.ARPA> Date: 13 August 1984 20:08-EDT From: Alan Bawden Subject: (atom VECTOR): franz vs liszt To: JonL.pa@XEROX Cc: GSB@MIT-MC, franz-friends@BERKELEY, smh@MIT-EMS In-Reply-To: Msg of 13 Aug 84 13:24 PDT from JonL.pa at XEROX.ARPA Date: 13 Aug 84 13:24 PDT From: JonL.pa at XEROX ... The resolution was some awful switch setting for whether or not to treat them as ATOMs, but I don't remember the default setting, nor the final results. There are indeed a couple of switches that control various random aspects of hunks, but none of them have any effect on their atomic or non-atomic nature. Hunks are never atoms in MacLisp. Everybody agrees that this is a loss, but at this point it is rather deeply ingrained into things to think about changing it. From jmiller@csnet-relay.csnet Tue Aug 14 01:53:12 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13476; Tue, 14 Aug 84 01:53:12 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA23091; Tue, 14 Aug 84 01:54:22 pdt Message-Id: <8408140854.AA23091@UCB-VAX.ARPA> Received: From ct.csnet by csnet-relay; 14 Aug 84 4:31 EDT Date: 13 Aug 1984 20:46:42-PST From: jmiller%ct.csnet@csnet-relay.arpa To: franz-friends@BERKELEY Subject: bug in assoc The following illustrates a rather unpleasant bug in Franz's ASSOC (as of 38.26, anyhow). Be forewarned.... ------------------------------------------------------------------------------ 8_(setq l '((a 1) (b 2) (c 3))) ;;set up an a-list ((a 1) (b 2) (c 3)) 9_(setq foo 'l) ;;FOO points to the NAME of the a-list l 10_(setq bar 'foo) ;;BAR points to the NAME of the NAME of foo ;;the a-list 11_(assoc 'b l) ;;This does the right thing (b 2) 12_(assoc 'b foo) ;;Gag me with a mouse -- should err (b 2) ;;with "bad arg to " 13_(assoc 'b bar) ;;Double gag me with a mouse!! (b 2) ------------------------------------------------------------------------ For the record, ASSQ is flawed in the same way. Jim Miller Computer Thought, Dallas jmiller@ctvax.csnet ...!convex!ctvax!jmiller From @MIT-MC:smh@MIT-EMS Tue Aug 14 07:35:27 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14507; Tue, 14 Aug 84 07:35:27 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA26447; Tue, 14 Aug 84 07:36:36 pdt Message-Id: <8408141436.AA26447@UCB-VAX.ARPA> Date: 14 Aug 1984 08:40:00-EDT From: smh@mit-ems@mit-mc To: ALAN@mit-mc, GSB@mit-mc, JonL.pa@parc-maxc Subject: (atom VECTOR): franz vs liszt Cc: franz-friends@BERKELEY Gentlemen, I think we are losing grasp on the original bug report. This is probably my fault for including a discourse on the philosophy of hunks (:-) in the bug report. Maclisp ain't gonna change about hunks, and it would be a poor idea for Franz to change. Anyway, the bug is with vectors. In Franz, compiled and interpreted code disagree whether a vector is an atom. Certainly no one can defend this! Maclisp doesn't *have* vectors, does it? Steve Haflich smh%mit-ems@mit-mc From mcgeer Tue Aug 14 11:03:10 1984 Received: by ucbkim.ARPA (4.24/4.27) id AA17397; Tue, 14 Aug 84 11:03:10 pdt Date: Tue, 14 Aug 84 11:03:10 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141803.AA17397@ucbkim.ARPA> Phone: (415) 236-8262 To: ALAN@MIT-MC, JonL.pa@XEROX Subject: Re: (atom VECTOR): franz vs liszt Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC In-Reply-To: Your message of 13 August 1984 20:08-EDT The predicate atom in Franz appears to be: (defun atom(foo) (if foo then (not (or (hunkp foo) (dtpr foo))) else t)) whereas a more natural implementation, it seems to me, is: (defun atom(foo) (or (symbolp foo) (numberp foo))) Since it seems to me that: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo)) should always be non-nil for non-nil objects. Or, better put, that vectors, hunks, dtprs, atoms, and arrays should partition the data space. No? Rick. From mcgeer Tue Aug 14 11:53:28 1984 Received: by ucbkim.ARPA (4.24/4.27) id AA18832; Tue, 14 Aug 84 11:53:28 pdt Date: Tue, 14 Aug 84 11:53:28 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141853.AA18832@ucbkim.ARPA> Phone: (415) 236-8262 To: jmiller%ct.csnet@csnet-relay.arpa, franz-friends Subject: Re: bug in assoc Cc: In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST "'Curiouser and curiouser', said Alice". I dug out the source for assoc (38.79), and here it is: (def assoc (lambda (val alist) (do ((al alist (cdr al))) ((null al) nil) (cond ((null (car al))) ((not (dtpr (car al))) (error "bad arg to assoc" al)) ((equal val (caar al)) (return (car al))))))) So nothing particularly screwy is going on here. However, when I do the traces (after setting up stuff the way you did), I get: => (assoc 'b 'l) 1 assoc (b l) 1 assoc (b 2) (b 2) => (assoc 'b ''l) 1 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {1} bar foo {1} (assoc 'b 'foo) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} foo l {1} bar foo {1} (assoc 'b bar) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} (assoc 'b ''l) |2 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {2} Which is certainly *very* odd... From mcgeer Tue Aug 14 12:06:20 1984 Received: by ucbkim.ARPA (4.24/4.27) id AA19018; Tue, 14 Aug 84 12:06:20 pdt Date: Tue, 14 Aug 84 12:06:20 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141906.AA19018@ucbkim.ARPA> Phone: (415) 236-8262 To: ALAN@MIT-MC, JonL.pa@XEROX Subject: Re: (atom VECTOR): franz vs liszt Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC Sorry to anyone who's getting this twice: I can't figure out from the mailer error message who got it and who didn't... The predicate atom in Franz appears to be: (defun atom(foo) (if foo then (not (or (hunkp foo) (dtpr foo))) else t)) whereas a more natural implementation, it seems to me, is: (defun atom(foo) (or (symbolp foo) (numberp foo))) Since it seems to me that: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo)) should always be non-nil for non-nil objects. Or, better put, that vectors, hunks, dtprs, atoms, and arrays should partition the data space. No? Rick. From PSZ@MIT-MC Tue Aug 14 13:53:19 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20310; Tue, 14 Aug 84 13:53:19 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA03508; Tue, 14 Aug 84 13:54:23 pdt Message-Id: <8408142054.AA03508@UCB-VAX.ARPA> Date: 14 August 1984 16:37-EDT From: Peter Szolovits Subject: on the issue of the "ATOMness" of hunks To: ALAN@MIT-MC Cc: GSB@MIT-MC, PSZ@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY, smh@MIT-EMS In-Reply-To: Msg of 13 Aug 1984 20:08-EDT from Alan Bawden I have a small quarrel with Alan Bawden's statement that "hunks never being atoms in Maclisp" is a universally-agreed bug. There are indeed useful structures that one would like to build in Lisp that act as CONS cells (i.e., CAR and CDR are applicable), but that can have further structure. I have sorely missed such objects in Lisp Machine Lisp and NIL, where flavor-instances are always atomic, when I wanted to build Brand X (interned "list structure" and universal property lists). In Maclisp, I could do this using hunks, though even that was not completely right because I wanted to be able to disallow RPLACA and RPLACD while allowing CAR and CDR, and this was hard, given the hunk abstraction. I would, however, love to have non-atomic flavor-instances From @MIT-MC:smh@MIT-EMS Tue Aug 14 14:28:47 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20792; Tue, 14 Aug 84 14:28:47 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA04288; Tue, 14 Aug 84 14:29:41 pdt Message-Id: <8408142129.AA04288@UCB-VAX.ARPA> Date: 14 Aug 1984 17:13:29-EDT From: smh@mit-ems@mit-mc To: mcgeer@ucbkim@BERKELEY Subject: Re: bug in assoc Cc: franz-friends@BERKELEY, jmiller@ct.csnet@udel-relay@mit-mc As McGeer@ucbkim points out, the code for assoc is (in common0.l): (def assoc (lambda (val alist) (do ((al alist (cdr al))) ((null al) nil) (cond ((null (car al))) ((not (dtpr (car al))) (error "bad arg to assoc" al)) ((equal val (caar al)) (return (car al))))))) The reason for the reported strange behavior of assoc is as simple as it is obscure! First a couple hints: - This code is inside the executable franz interpreter and therefore runs compiled. - The same strangeness is exhibited by assq, which is C-coded inside the Franz kernel. - Both the cdr of a dtpr and the value of an atom are stored at offset zero within their respective structures. The car and plist similarly share the same offset within their structures. - If you try to run the above assoc definition interpreted, it will properly fail to work, or rather, it will complain about a bad arg to car. - Of course, c[ad]r in the interpreter carfully check their arguments; In the compiler, they simple indirect through pointers for maximum speed. Finally, in case by now it isn't absolutely clear to everyone what is going on, assoc is (sort of) comparing val against the plist of bar and subsequently foo, and then each time automagically effectively doing a symeval on the atom to continue scanning down the "cdr" of the alist. Moral: Although the interpreter tries pretty hard to do the dynamic typing and implied typechecking for which lisp is famous, type checking in compiled code is often a myth. Correct code only necessarily works correctly when given corrent arguments. Steve Haflich MIT Experimental Music Studio smh%mit-ems@mit-mc {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh From JonL.pa@Xerox.ARPA Wed Aug 15 16:33:44 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00784; Wed, 15 Aug 84 16:33:44 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05115; Wed, 15 Aug 84 14:20:30 pdt Message-Id: <8408152120.AA05115@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 14:19:35 PDT Date: 15 Aug 84 14:18 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: Alan Bawden 's message of 13 Aug 84 20:08 EDT To: ALAN@MIT-MC.ARPA Cc: JonL.pa@XEROX.ARPA, GSB@MIT-MC.ARPA, franz-friends@BERKELEY, smh@MIT-EMS.ARPA [Ah, confusion with Interlisp here]. I meant to say "The resolution was some awful switch setting for whether or not to treat them as LISTs" rather than "to treat them as ATOMs". The switch name is HUNKP. Interlisp's ATOM predicate is defined simply as (NOT (LISTP x)), and LISTP is true only of cons cells [thus (LISTP NIL) is false]. -- JonL -- From JonL.pa@Xerox.ARPA Wed Aug 15 18:21:08 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02292; Wed, 15 Aug 84 18:21:08 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA09647; Wed, 15 Aug 84 18:21:57 pdt Message-Id: <8408160121.AA09647@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT Date: 15 Aug 84 18:18 PDT From: JonL.pa@XEROX.ARPA Subject: Re: bug in assoc In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: "mcgeer@ucbkim"@BERKELEY, franz-friends@BERKELEY, "jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA Common Lisp also faces the possibility of inconsistent system code due to the handling of cases marked "is an error" (see Manual, sec. 1.2.4); that is, it is undefined as to what happens if you apply CAR to a non-LISTP. All portable system code should therefore certify the type of a datum before taking car or cdr. ASSOC (and ASSQ) from the Franz sources clearly doesn't check the type of the arguments before carcdring away on them. Well, why not "all system code should certify the type before taking car/cdr . . . " -- it certainly can't hurt to "signal an error" rather than fall into some undefined morass. -- JonL -- From JonL.pa@Xerox.ARPA Wed Aug 15 19:49:22 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02844; Wed, 15 Aug 84 19:49:22 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA10989; Wed, 15 Aug 84 19:50:13 pdt Message-Id: <8408160250.AA10989@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 19:48:41 PDT Date: 15 Aug 84 15:00 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 08:40:00 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA, JonL.pa@XEROX.ARPA, franz-friends@BERKELEY MacLisp indeed does have VECTORs, STRINGs, CLASSes, etc. in an extended SmallTalk-like hierarchy, but they are not in the initial system. Some of these used to have autoload properties, but I'm not sure about the state of things now. None of the extended stuff got documented in the 1983 MacLisp manual, mostly because of Pitman's personal preferences for not using the extended stuff. HUNKs are relevant, because the extended heirarchy uses the USRHUNK feature in order to cause system functions to "trap out" on hunks, thereby viewing them in an object-oriented way rather than as lists (Glaaaag!) or as mere simple vectors. -- JonL -- From MLY@MIT-MC Wed Aug 15 22:49:17 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04730; Wed, 15 Aug 84 22:49:17 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA13406; Wed, 15 Aug 84 22:49:59 pdt Message-Id: <8408160549.AA13406@UCB-VAX.ARPA> Date: 16 August 1984 01:49-EDT From: Richard Mlynarik Subject: on the issue of the "ATOMness" of hunks To: PSZ@MIT-MC Cc: ALAN@MIT-MC, GSB@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY, smh@MIT-EMS In-Reply-To: Msg of 14 Aug 1984 16:37-EDT from Peter Szolovits From: Peter Szolovits I have a small quarrel with Alan Bawden's statement that "hunks never being atoms in Maclisp" is a universally-agreed bug. There are indeed useful structures that one would like to build in Lisp that act as CONS cells (i.e., CAR and CDR are applicable), but that can have further structure. I have sorely missed such objects in Lisp Machine Lisp and NIL, where flavor-instances are always atomic, when I wanted to build Brand X (interned "list structure" and universal property lists). In Maclisp, I could do this using hunks, though even that was not completely right because I wanted to be able to disallow RPLACA and RPLACD while allowing CAR and CDR, and this was hard, given the hunk abstraction. I would, however, love to have non-atomic flavor-instances The MIT lisp machine system makes some attempt to "support" this sort of thing, by sending :CAR, :CDR, etc messages to instances. The result is that you get an error about an unclaimed message, rather than one about an attempt to take the car of a non-nil atom. LISTP and CONSP both still return NIL when applied to an instance. The way to get RPLACA (or SETF of CAR), etc to not work is simply to not define methods for doing these operations... Is is not really clear to me what the value of such is, unless you get tired of typing too many "(SEND"'s. From goldfarb%ucf.csnet@csnet-relay.arpa Fri Aug 17 16:44:40 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00202; Fri, 17 Aug 84 16:44:40 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA01032; Fri, 17 Aug 84 16:45:24 pdt Received: From ucf.csnet by csnet-relay; 17 Aug 84 19:26 EDT Received: by ucf-cs.UUCP (4.12/4.7) id AA00852; Fri, 17 Aug 84 15:29:05 edt Date: Fri, 17 Aug 84 15:29:05 edt From: Ben Goldfarb Message-Id: <8408171929.AA00852@ucf-cs.UUCP> To: franz-friends@BERKELEY Subject: ChangeLog The ReadMe file in /usr/src/cmd/ucb/lisp states that there are ChangeLog files in the subdirectories franz and liszt. We got no such files on our distribution tape (Berkeley 4.2bsd). I'd appreciate receiving copies of these files, along with any other documentation of differences between the 4.2 version and prior versions of Franz Lisp. Thanks, Ben Goldfarb University of Central Florida uucp: {duke,decvax,princeton}!ucf-cs!goldfarb ARPA: goldfarb.ucf-cs@csnet.relay csnet: goldfarb@ucf From gvax.bromley@Cornell.ARPA Sun Aug 26 20:48:24 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA11969; Sun, 26 Aug 84 20:48:24 pdt Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA18166; Sun, 26 Aug 84 20:46:52 pdt Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30) id AA16455; Sun, 26 Aug 84 23:48:12 edt Date: Sun, 26 Aug 84 23:45:55 edt From: gvax.bromley@Cornell.ARPA (Mark Bromley) Message-Id: <8408270345.AA14288@CORNELL-GVAX.ARPA> Received: by CORNELL-GVAX.ARPA (4.30/4.30) id AA14288; Sun, 26 Aug 84 23:45:55 edt To: gvax.arpa-franz@Cornell.ARPA Subject: Bug in open coding of vseti in Liszt 8.36 If (vseti vector index expression) gets open coded by the compiler, the resulting value is the value of index, not the value of expression. This also holds for vseti-byte and vseti-word. The problem is in d_vset in vector.l. The code which builds the return value for immediate vectors assumes that the value of expression is in index-reg, but it never gets put there. One solution would be to change the lines (if g-loc then (if (eq type 'byte) (occuring about 3/4 of the way through d_vset) to (if g-loc then (setq temp (cadr (assq type '((byte cvtbl) (word cvtwl) (long movl))))) (e-write3 temp vect-val index-reg) (if (eq type 'byte) Mark Bromley bromley@cornell From forwarder@UWVAX Mon Aug 27 14:25:15 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19881; Mon, 27 Aug 84 14:25:15 pdt Received: from wisc-rsch.arpa (wisc-rsch.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05251; Mon, 27 Aug 84 14:23:30 pdt Date: Mon, 27 Aug 84 16:26:07 cdt Message-Id: <8408272126.AA14734@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Mon, 27 Aug 84 16:26:07 cdt To: franz-friends@BERKELEY Subject: FRANZ to VI and back Cc: neves@wisc-rsch.arpa Sender: forwarder@UWVAX From: neves@wisc-rsch.arpa Escuse me if this is a simple question, but i am a Unix novice. What is the best way to go between VI & Franz when debugging a program? The way I currently do it is to ctrl-Z out of Franz, FG to my VI process, correct my code, FG back to FRANZ, load the corrected code. Is there a better way (do not tell me about Emacs because that is not an option)? -thanks, david From rad@mitre-bedford Mon Aug 27 14:52:55 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20435; Mon, 27 Aug 84 14:52:55 pdt Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05840; Mon, 27 Aug 84 14:51:11 pdt Message-Id: <8408272151.AA05840@UCB-VAX.ARPA> Date: Monday, 27 Aug 1984 17:45-EDT From: rad@Mitre-Bedford To: neves@WISC-RSCH.ARPA Cc: franz-friends@BERKELEY, neves@WISC-RSCH.ARPA Subject: Re: FRANZ to VI and back In-Reply-To: Your message of Monday, 27 Aug 1984 17:26-EDT. <8408272126.AA14734@wisc-rsch.arpa> >>Escuse me if this is a simple question, but i am a Unix novice. >>What is the best way to go between VI & Franz when debugging a >>program? The way I currently do it is to ctrl-Z out of Franz, >>FG to my VI process, correct my code, FG back to FRANZ, load the >>corrected code. Is there a better way (do not tell me about >>Emacs because that is not an option)? It's undocumented in the franz opus 37 manual, but may be in the opus 38: In franz, type (vi foo) and lisp will spin up vi. If it can't find the file foo, it tries for foo.l before creating a new file. If you invoke it as (vil foo), it will load foo back in after you exit from vi. There are similar functions called ex and exl. If you're using BSD4.2, you probably have opus 38. A new book is out called Lispcraft. It is based on franz, opus 38 in particular. You might want to pick that up. The old standby, Lisp, by Winston and Horn, documented Maclisp which is close to franz. Their new, 2nd edition is based on Common Lisp, however, which is different, so watch out! If you don't like ex or vi (say you're an ed-masochist), there are hooks for other editors. Put the following in the .lisprc file in your home directory: (def ed (nlambda (x) (exvi 'ed x nil))) (def edl (nlambda (x) (exvi 'ed x t))) These will give you the same function as ex/vi and exl/vil except using ed. These functions are found in /usr/lib/lisp/auxfns0.l (opus 37, anyway). Dick Dramstad rad@mitre-bedford From liz@maryland Tue Aug 28 10:17:28 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA28395; Tue, 28 Aug 84 10:17:28 pdt Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA24861; Tue, 28 Aug 84 10:15:46 pdt Received: by maryland.ARPA (4.12/4.7) id AA20274; Tue, 28 Aug 84 10:59:06 edt Date: Tue, 28 Aug 84 10:59:06 edt From: liz@maryland (Liz Allen) Message-Id: <8408281459.AA20274@maryland.ARPA> To: neves@WISC-RSCH.ARPA, rad@Mitre-Bedford Subject: Re: FRANZ to VI and back Cc: franz-friends@BERKELEY One feature of our vi functions is to ask (after returning from vi) whether or not you want to load the file. This gives you the freedom to decide later when you know if you modified the file. To implement this, you could change the last line of exvi from: (cond (doload (load edit_file))) to: (cond ((or doload (query "Load " edit_file "? ")) (load edit_file))) and define query: (defmacro (&rest prompt) `(progn (msg ,@prompt) (yesp (read)))) (or something like that). Exvi is defined in common1.l. Enjoy! -Liz PS You could also send me mail asking about getting our software! From @MIT-MC:iaeh@cmu-ri-isl2.arpa Wed Aug 29 08:09:14 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09035; Wed, 29 Aug 84 08:09:14 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA15198; Wed, 29 Aug 84 08:09:05 pdt Message-Id: <8408291509.AA15198@UCB-VAX.ARPA> Date: 29 Aug 1984 11:06:09-EDT From: Ingemar.Hulthage@CMU-RI-ISL2 Subject: Vector algebra Apparently-To: I am writing a package of functions for vector algebra in arbitrary (finite) dimensions and it occured to me that I ought to post a message to find out if something like this is alredy available. I am looking forward to the replies From @MIT-MC:iaeh@cmu-ri-isl2.arpa Fri Aug 31 10:16:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04497; Fri, 31 Aug 84 10:16:03 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA03527; Fri, 31 Aug 84 10:15:41 pdt Message-Id: <8408311715.AA03527@UCB-VAX.ARPA> Date: 31 Aug 1984 13:15:27-EDT From: Ingemar.Hulthage@CMU-RI-ISL2 Subject: matrix inversion Apparently-To: I need to numerically invert matrices of varying sizes and I would appreciate pointers to any lisp functions that can do that. From mccune@aids-unix Fri Aug 31 10:42:29 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA05060; Fri, 31 Aug 84 10:42:29 pdt Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA04133; Fri, 31 Aug 84 10:41:52 pdt Message-Id: <8408311741.AA04133@UCB-VAX.ARPA> Date: 31 Aug 84 10:40:13 PDT (Fri) From: Brian McCune Subject: Mailing list To: franz-friends@BERKELEY Please remove my name from franz-friends. Thanks. Brian McCune MCCUNE@AIDS-UNIX From ucsbcsl!dave@engrvax Tue Sep 4 11:22:20 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA10583; Tue, 4 Sep 84 11:22:20 pdt Received: by UCB-VAX.ARPA (4.24/4.33) id AA26490; Tue, 4 Sep 84 11:22:10 pdt From: ucsbcsl!dave@engrvax Received: from engrvax.UCSB (engrvax.ARPA) by ucsbcsl.UCSB (4.12/3.14.ucsb) id AA27209; Tue, 4 Sep 84 10:55:08 pdt Date: Tue, 4 Sep 84 10:55:52 pdt Message-Id: <8409041755.AA20764@engrvax.UCSB> Received: by engrvax.UCSB (4.12/3.14.ucsb) id AA20764; Tue, 4 Sep 84 10:55:52 pdt To: franz-friends@BERKELEY Subject: I have moved. Please change my mailing address to be 'ucsbcsl!chi!dave' from 'ucsbcsl!dave'. Thanks. From liz@maryland Wed Sep 5 08:34:45 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19892; Wed, 5 Sep 84 08:34:45 pdt Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA14415; Wed, 5 Sep 84 08:34:27 pdt Received: by maryland.ARPA (4.12/4.7) id AA09320; Wed, 5 Sep 84 11:33:56 edt Date: Wed, 5 Sep 84 11:33:56 edt From: liz@maryland (Liz Allen) Message-Id: <8409051533.AA09320@maryland.ARPA> To: franz-friends@BERKELEY Subject: Maryland software I'm mailing the announcement here again since a few things have changed since I last sent it out here and I have had requests for it. Currently, we are completing the 4.2 switchover and will (hopefully) be starting to distribute it by the end of September. -Liz Allen ----------------------------------------------------------------- Greetings: This is to announce the availability of the Univ of Maryland software distribution. This includes source code for the follow- ing packages which are currently running on a VAX 11/780 under Berkeley UNIX(tm) 4.1: (1) The flavors package written in Franz Lisp. This package has been used successfully in a number of large systems at Mary- land, and while it does not implement all the features of Lisp Machine Flavors, the features present are as close to the Lisp Machine version as possible within the constraints of Franz Lisp. (Note that Maryland flavors code *can* be compiled.) (2) Other Maryland Franz hacks including the INTERLISP-like top level, the lispbreak error handling package, the for macro and the new loader package. (3) The YAPS production system written in Franz Lisp. This is similar to OPS5 but more flexible in the kinds of lisp expressions that may appear as facts and patterns (sublists are allowed and flavor objects are treated atomically), the variety of tests that may appear in the left hand sides of rules and the kinds of actions may appear in the right hand sides of rules. In addition, YAPS allows multiple data bases which are flavor objects and may be sent messages such as "fact" and "goal". (4) The windows package in the form of a C loadable library. This flexible package allows convenient management of multi- ple contexts on the screen and runs on ordinary character display terminals as well as bit-mapped displays. Included is a Franz lisp interface to the window library, a window shell for executing shell processes in windows, and a menu package (also a C loadable library). (5) The phone program. This is a facility to allow two or more users to type messages to each other in separate windows on a tty screen. It uses the Maryland window package and CMU's IPC facility. (6) The calend program, an appointment calendar maintainer. It uses a user file of reminding messages and dates for remind- ing, and can notify a user by messages printed to his termi- nal, sending them mail, or nagging them to get off the ter- minal at a certain time of day. It allows one-time only, weekly, biweekly, monthly, yearly and other similar methods for being reminded. (7) The bbd program, a multiple bulletin board system loosely based on the 'msgs' program. It accepts character-oriented commands and allows user-definable bulletin-boards. (8) Rzasm, a relocating Z80 cross-assembler. Running on the vax it puts out ld-style object files. Its features include, among others: free-form input; (very) long variable/label names; conditional assembly; macros (in 'm4' format); digit labels; global, external, common and local common declara- tions; data and text segments; support of the "undocumented" Z80 instructions (that work on high and low bytes of the index registers separately); expressions using C syntax; and string constants. (9) Zrun, a z80 microprocessor simulator. Zrun simulates the execution of a z80 with 64k RAM, as directed by user com- mands. In addition to the essential commands that cause an rzasm object program to be loaded and executed, there are commands to examine and set registers, flags, and memory locations, to set a breakpoint, to single-step through a program, to re-direct the flow of data through the z80 ports, etc. The distribution currently runs under Berkeley Unix 4.1, but we will be upgrading to 4.2 in early July and the upgrade should be ready for distribution in September. At that time, we will begin to put both the 4.1 and 4.2 sources on the distribution tape. If you are running 4.2 or plan to be running 4.2 in the near future, it is probably worth your while to wait for it. Also at that time, the fee for the distribution will go up from $100 to $250. We also include Franz Lisp in the distribution since it is easier to do that than to describe all the small changes that we have made to the Franz sources. For the 4.1 distribution, we send Franz Opus 38.26. For the 4.2 distribution, we do not yet know which Franz we will be mailing, but it will be whichever we get with our 4.2 Berkeley Unix. How to obtain a tape: To obtain the Univ of Maryland distribution tape: (1) Fill in the form below and sign it. Please indicate whether you want just the 4.1 distribution, both the 4.1 and 4.2 distributions or if you will be obtaining the distribution via a third party or via the Arpanet. (2) Make out a check to "University of Maryland Foundation" for $100 (US dollars) or for $250 (US dollars) if you want the 4.2 distribution. Mail the check and form to: Liz Allen Univ of Maryland Dept of Computer Science College Park MD 20742 (3) If you need an invoice, send me mail. Don't forget to include your non-electronic mailing address. Upon receipt of the money, we will mail you a tape containing our software and the technical reports describing the software. We will also keep you informed of bug fixes via electronic mail. We have an electronic mailing address for this kind of thing. It is: Usenet: ...!seismo!umcp-cs!um-software Arpanet: um-software@maryland Please note that bug fixes will be done only insofar they are consistent with the research purposes of the University of Mary- land. If you have any technical questions, etc, send mail to the above mailing list. If you have any administrative questions, contact Diane Miller via electronic mail: Usenet: ...!seismo!umcp-cs!despina Arpanet: despina@maryland or via phone at (301) 454-4251. Liz Allen Usenet: ...!seismo!umcp-cs!liz Arpanet: liz@maryland ----------------------------------------------------------------- In exchange for the Maryland software tape, I certify to the fol- lowing: a. I will not use any of the Maryland software distribution in a commercial product without obtaining permission from Mary- land first. b. I will keep the Maryland copyright notices in the source code, and acknowledge the source of the software in any use I make of it. c. I will not redistribute this software to anyone without per- mission from Maryland first. d. I will keep Maryland informed of any bug fixes. e. I understand that the software I will be receiving has been developed for research purposes only and may be good for absolutely nothing. The University of Maryland offers no warranties of any kind. Bug fixes will be done only insofar they are consistent with the research purposes of the University of Maryland. f. I am the appropriate person at my site who can make the guarantees in parts a through e. g. I would like the package indicated below: ___ 4.1 distribution only. I have enclosed a check for $100. ___ 4.1 and 4.2 distribution. I have enclosed a check for $250. I also understand that the 4.2 distribution is not yet ready and that there will be a delay until at least August or September before my tape arrives. ___ License and technical reports only. I have enclosed a check for $100 and will obtain the distribution from a site that already has the distribtution or will get it from Maryland via the Arpanet. (Please note specifics at the bottom of the form.) Signature: ______________________________ Name: ______________________________ Position: ______________________________ Company or Organization: ______________________________ Address: ______________________________ ______________________________ Phone number: ______________________________ Electronic mail address: ______________________________ From gvax.bromley@Cornell.ARPA Wed Sep 5 16:11:17 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA25823; Wed, 5 Sep 84 16:11:17 pdt Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA21315; Wed, 5 Sep 84 16:10:58 pdt Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30) id AA15943; Wed, 5 Sep 84 19:11:13 edt Date: Wed, 5 Sep 84 19:06:27 edt From: gvax.bromley@Cornell.ARPA (Mark Bromley) Message-Id: <8409052306.AA19770@CORNELL-GVAX.ARPA> Received: by CORNELL-GVAX.ARPA (4.30/4.30) id AA19770; Wed, 5 Sep 84 19:06:27 edt To: franz-friends@BERKELEY Subject: Bug in open coding of vseti in Liszt 8.36 There is a mistake in the open coding of (vseti vector index expression). When the generated code is executed it returns the value of the index expression and not the value of expression. The problem is in d_vset in liszt/vector.l. The code in d_vset that generates the assembler code to compute the return value assumes that code has been generated to put the value of expression in index-reg. This assumption is false. I don't know the 68000 well enough to suggest a solution for it, but the following should work for the VAX. Change the lines (if g-loc then (if (eq type 'byte) (occuring about 3/4 of the way through d_vset) to (if g-loc then #+for-vax (progn (setq temp (cadr (assq type '((byte cvtbl) (word cvtwl) (long movl))))) (e-write3 temp vect-val index-reg) ) #+for-68k (comment Do the same thing for the 68k) (if (eq type 'byte) Also, what is the current Berkeley distribution policy. I tried ftp'ing from ucbvax, but the pub/lisp directory there is empty. I'd like to get my hands on a distribution that has the flavors package in it. Mark Bromley bromley@cornell From jkf@ucbmike Tue Oct 30 12:19:45 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02909; Tue, 30 Oct 84 12:19:45 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA23363; Tue, 30 Oct 84 11:43:13 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA04265; Tue, 30 Oct 84 12:43:39 pst Date: Tue, 30 Oct 84 12:43:39 pst From: John Foderaro (on a sun) Message-Id: <8410302043.AA04265@ucbmike.arpa> To: mrose%udel-dewey.delaware@udel-relay.ARPA, franz-friends@BERKELEY Subject: Re: Where is franz-friends-request In-Reply-To: Your message of 28 Oct 84 10:04:05 EST (Sun) franz-friends-request@berkeley is valid. occasionlly the mailer tries to look in the alias table while it is being updated. From liz@tove Tue Oct 30 13:18:32 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03406; Tue, 30 Oct 84 13:18:32 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA24224; Tue, 30 Oct 84 12:15:01 pst Received: by tove.ARPA (4.12/4.7) id AA09504; Thu, 25 Oct 84 16:46:39 edt From: Liz Allen Message-Id: <8410252046.AA09504@tove.ARPA> Date: 25 Oct 1984 1646-EDT (Thursday) To: Rene Bach Cc: franz-friends@BERKELEY Subject: Re: A question In-Reply-To: Your message of Thu 25 Oct 84 09:31:09-PDT. <8410251628.AA00848@UCB-VAX.ARPA> From: Rene Bach I am new on this list and haven't seen any other messages. There isn't too much mail here. Is there a way to find out what are all the atoms which have been defined in Franz (a la mapatoms of INterlisp) ?? The functions (oblist) returns a list of all the atoms. -Liz From neves%wisc-ai.uwisc@wisc-crys.ARPA Tue Oct 30 14:38:15 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04963; Tue, 30 Oct 84 14:38:15 pst Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA27563; Tue, 30 Oct 84 14:36:12 pst Received: from wisc-ai.uwisc by wisc-crys.arpa; Tue, 30 Oct 84 16:35:00 cst Date: Tue, 30 Oct 84 16:34:59 cst From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) Message-Id: <8410302234.AA21547@wisc-ai.uwisc> Received: by wisc-ai.uwisc; Tue, 30 Oct 84 16:34:59 cst To: franz-friends@BERKELEY Subject: vi/franz question This is a vi/franz question. I would like to use "=" in VI to indent my lisp code. When I type "=" in front of some lisp code I get No alternate filename to substitute for #0 How do I indent Lisp code (besides using autoindent)? -Thanks, David From Johnson%udel-dewey.delaware@udel-relay.ARPA Wed Oct 31 05:54:58 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04156; Wed, 31 Oct 84 05:54:58 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07029; Wed, 31 Oct 84 05:52:24 pst Message-Id: <8410311352.AA07029@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a018834 ;31 Oct 84 8:55 EST Date: Wed, 31 Oct 84 8:47:19 EST From: johnson To: franz-friends@BERKELEY Cc: johnson%udel-dewey.delaware@udel-relay.ARPA Subject: response to lisp/vi question in response to: >I would like to use "=" in VI to indent my lisp code. When I >type "=" in front of some lisp code I get >No alternate filename to substitute for #0 >How do I indent Lisp code (besides using autoindent)? 1. When I type "=" in vi (without :set lisp) I get no response at all. Is it possible that you defined a macro named "=" ? { check your ~/.exrc file for a line beginning: :map = } 2. Even after: :set lisp A single "=" does not seem to cause the correct action, however, two successive "="s do. to summarize: 1. remove any mapping of "=" from ~/.exrc 2. :set lisp 3. use "==" rather than "=" - johnson@udel-ee From raf%bostonu.csnet@csnet-relay.arpa Wed Oct 31 11:35:57 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07802; Wed, 31 Oct 84 11:35:57 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA13682; Wed, 31 Oct 84 11:33:13 pst Received: from bostonu by csnet-relay.csnet id ac00303; 31 Oct 84 14:27 EST Received: by csvaxa.ARPA (4.12/4.7) id AA14678; Wed, 31 Oct 84 13:53:18 est Date: Wed, 31 Oct 84 13:53:18 est From: Rafail Ostrovsky Message-Id: <8410311853.AA14678@csvaxa.ARPA> To: FRANZ-FRIENDS%ucb-vax.arpa@csnet-relay.arpa Subject: MAILING LIST Hello. I would like to subscribe to your mailing list. I am a grad. student at Boston U. My address is: raf%bostonu.csnet@CSNET-RELAY.CSNET Thank you, -Raf From neves%wisc-ai.uwisc@wisc-crys.ARPA Wed Oct 31 12:40:33 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09034; Wed, 31 Oct 84 12:40:33 pst Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA15180; Wed, 31 Oct 84 12:37:38 pst Received: from wisc-ai.uwisc by wisc-crys.arpa; Wed, 31 Oct 84 14:35:47 cst Date: Wed, 31 Oct 84 14:35:55 cst From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) Message-Id: <8410312035.AA25488@wisc-ai.uwisc> Received: by wisc-ai.uwisc; Wed, 31 Oct 84 14:35:55 cst To: franz-friends@BERKELEY Subject: re: Indenting lisp code in VI Thanks for the response on indenting for Franz. It seems as though our systems people do not use Lisp and so have set up everyone's .exrc file to map = to something else. Your site might be doing the same thing to this or other VI/Lisp features! Stop them now. From @MIT-MC:iaeh@cmu-ri-isl2.arpa Wed Oct 31 17:37:36 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14939; Wed, 31 Oct 84 17:37:36 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA02960; Wed, 31 Oct 84 17:14:37 pst Message-Id: <8411010114.AA02960@UCB-VAX.ARPA> Date: 31 Oct 84 20:08:41 EST From: Ingemar.Hulthage@CMU-RI-ISL2 Subject: Floating point division To: BBoard.Maintainer@CMU-CS-A Is there a pre-defined function in Franz Lisp that never uses integer division when it differs from floating point division ? Obviously it is easy to write (quotient (float a) b) or to write a function/macro with the same effect. However, since Franz does a good job of dealing with different kinds of numbers in other cases, it is inconvenient and inefficient if such a function is not available in the system. From eng20201%BOSTONU.bitnet@WISCVM.ARPA Thu Nov 1 16:02:58 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA05698; Thu, 1 Nov 84 16:02:58 pst Received: from WISCVM.ARPA (wiscvm.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA08850; Thu, 1 Nov 84 16:00:19 pst Message-Id: <8411020000.AA08850@UCB-VAX.ARPA> Received: from ENG20201@BOSTONU.BITNET by WISCVM.ARPA on 11/01/84 at 18:00:40 CST Date: 1-Nov-84 18:58:53 EST From: John Sutter Subject: Pretty typer To: franz-friends@BERKELEY Cc: eng20201%BOSTONU.bitnet@WISCVM.ARPA ----- Does anyone know of a pretty typer for Franz Lisp?.. If you do, please reply to me directly. Thanks ---- John ----- From holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa Sun Nov 4 14:39:06 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03203; Sun, 4 Nov 84 14:39:06 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04466; Sun, 4 Nov 84 14:36:25 pst Received: from ubc by csnet-relay.csnet id a004399; 4 Nov 84 15:43 EST Date: Sun, 4 Nov 84 12:37:03 pst Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst From: Neal Holtz To: franz-friends%ucb-vax.arpa@csnet-relay.arpa Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Message-Id: 133:holtz@carleton.cdn Subject: Franz on Apollos (or, Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative. From holtz%carleton.cdn%ubc.csnet@csnet-relay.arpa Sun Nov 4 14:39:20 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03212; Sun, 4 Nov 84 14:39:20 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04473; Sun, 4 Nov 84 14:36:37 pst Received: from ubc by csnet-relay.csnet id a004408; 4 Nov 84 15:45 EST Date: Sun, 4 Nov 84 12:37:03 pst Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst From: Neal Holtz To: franz-friends%ucb-vax.arpa@csnet-relay.arpa Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Message-Id: 133:holtz@carleton.cdn Subject: Franz on Apollos (or, Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative. From fkunze%ucbopal.CC%ucb-vax.arpa@csnet-relay.arpa Sun Nov 4 23:25:12 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03125; Sun, 4 Nov 84 23:25:12 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04781; Sun, 4 Nov 84 23:22:27 pst Received: from ucb-vax.arpa by csnet-relay.arpa id a006482; 5 Nov 84 2:21 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04236; Sun, 4 Nov 84 22:58:35 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.27.2) id AA14292; Sun, 4 Nov 84 22:59:18 pst Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28) id AA03601; Sun, 4 Nov 84 22:59:26 pst Date: Sun, 4 Nov 84 22:59:26 pst From: Fritz Kunze Message-Id: <8411050659.AA03601@ucbopal.CC.Berkeley.ARPA> To: franz-friends%ucb-vax.arpa%csnet-relay.arpa@csnet-relay.arpa, holtz%carleton.cdn%ubc.csnet%csnet-relay.arpa@csnet-relay.arpa Subject: Re: Franz on Apollos (or, Fritz Kunze, where are you?) We are working on an Apollo port right now. Due to some non-standard features in the Apollo operating system, the port is requiring far more time than we originally anticipated. We are very close to a working interpreter, but the compiler will require more time. Are you interested in the Interpreter first? ---Fritz Kunze Franz Inc. 2920 Domingo, suite 203 Berkeley, CA 94705 (415) 540-1224 From abrams@mitre Mon Nov 5 11:41:38 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08762; Mon, 5 Nov 84 11:41:38 pst Received: from mitre (mitre.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA06184; Mon, 5 Nov 84 11:38:18 pst Message-Id: <8411051938.AA06184@UCB-VAX.ARPA> Date: 5 Nov 1984 14:17:36 EST (Monday) From: Marshall Abrams Subject: Call for papers: Expert Systems Symposium To: add1:@mitre Cc: abrams@mitre Call for Papers Expert Systems in Government Conference October 23-25, 1985 THE CONFERENCE objective is to allow the developers and implementers of expert systems in goverenment agencies to exchange information and ideas first hand for the purpose of improving the quality of existing and future expert systems in the government sector. Artificial Intelligence (AI) has recently been maturing so rapidly that interest in each of its various facets, e.g., robotics, vision, natural language, supercomputing, and expert systems, has acquired an increasing following and cadre of practitioners. PAPERS are solicited which discuss the subject of the conference. Original research, analysis and approaches for defining expert systems issues and problems such as those identified in the anticipated session topics, methodological approaches for analyzing the scope and nature of expert system issues, and potential solutions are of particular interest. Completed papers are to be no longer than 20 pages including graphics and are due 1 May 1985. Four copies of papers are to be sent to: Dr. Kamal Karna, Program Chairman MITRE Corporation W852 1820 Dolley Madison Boulevard McLean, Virginia 22102 Phone (703) 883-5866 ARPANET: Karna @ Mitre Notification of acceptance and manuscript preparation instructions will be provided by 20 May 1985. THE CONFERENCE is sponsored by the IEEE Computer Society and The MITRE Corporation in cooperation with The Association for Computing Machinery, The american Association for Artificial Intelligence and The American Institute of Aeronautics and Astronautics National Capital Section. This conference will offer high quality technical exchange and published proceedings. It will be held at Tyson's Westpark Hotel, Tysons Corner, McLean, VA, suburban Washington, D.C. TOPICS OF INTEREST The topics of interest include the expert systems in the following applications domains (but are not limited to): 1. Professional: Accounting, Consulting, Engineering, Finance, Instruction, Law, Marketing, Management, Medicine Systems, Intelligent DBMS 2. Office Automation: Text Understanding, Intelligent 3. Command & Control: Intelligence Analysis, Planning, Targeting, Communications, Air Traffic Control 4. Exploration: Space, Prospecting, Mineral, Oil Archeology 5. Weapon Systems: Adaptive Control, Electronic Warfare, Star Wars, Target Identification 6. System Engineering: Requirements, Preliminary Design, Critical Design, Testing, and QA 7. Equipment: Design Monitoring, Control, Diagnosis, Maintenance, Repair, Instruction 8. Project Management: Planning, Scheduling, Control 9. Flexible Automation: Factory and Plan Automation 10. Software: Automatic Programming, Specifications, Design, Production, Maintenance and Verification and Validation 11. Architecture: Single, Multiple, Distributed Problem Solving Tools 12. Imagery: Photo Interpretation, Mapping, etc. 13. Education: Concept Formation, Tutoring, Testing, Diagnosis, Learning 14. Entertainment and Intelligent Games, Investment and Expert Advice Giving: Finances, Retirement, Purchasing, Shopping, Intelligent Information Retrieval From decvax!utzoo!dciem!nrcaero!clan.carleton!holtz Mon Nov 5 17:32:56 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14064; Mon, 5 Nov 84 17:32:56 pst Received: by UCB-VAX.ARPA (4.24/4.39) id AA14362; Mon, 5 Nov 84 17:30:11 pst Return-Path: Received: by decvax.UUCP (4.12/1.0) id AA28321; Mon, 5 Nov 84 16:46:11 est Date: Sun, 4 Nov 84 21:23:59 est From: Neal Holtz Message-Id: <8411050223.AA07104@clan. UUCP> Received: by clan. UUCP (4.12/3.14) id AA07104; Sun, 4 Nov 84 21:23:59 est To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends Subject: Franz on Apollos (or -- Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative. From asb@SCRC-STONY-BROOK.ARPA Tue Nov 6 16:15:33 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA25403; Tue, 6 Nov 84 16:15:33 pst Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA06061; Tue, 6 Nov 84 16:12:18 pst Message-Id: <8411070012.AA06061@UCB-VAX.ARPA> Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 122057; Tue 6-Nov-84 19:13:41-EST Date: Tue, 6 Nov 84 19:11 EST From: Richard Brenner Subject: Job Opportunities To: maple-sys@BERKELEY, symalg%rand-unix.arpa%csnet-relay.arpa@SCRC-CUPID.ARPA, franz-friends@BERKELEY In-Reply-To: The message of 6 Nov 84 15:51-EST from Richard Pavelle Symbolics, Inc. of Cambridge is the acknowledged leader in the field of Symbolic Processing, offering the premier LISP-based Symbolic Processor for advanced problem-solving applications. We are a fast-growing, high-tech company with new, modern facilities right in Cambridge. Recent expansion has created opportunities for the following experienced professionals: Member of Technical Staff You will assist with maintenance and enhancement of MACSYMA, a large Computer Algebra System written in LISP and used by engineers and scientists for performing symbolic computations. Immediate projects could include design and implementation of tools for conversion to Common LISP, improving modularity, modernizing the user interface, improving performance, and design and implementation of new mathematical packages based on the latest available algorithms. Work will be performed on all versions of MACSYMA using Symbolics 3600 Family Lisp Machines. A strong background in mathematics and Lisp programming is preferred. Experience with MACSYMA is desirable. Technical Sales Support Engineer You will provide technical support to our internal sales staff, to customers and to prospective customers. Responsibilities include assistance at demonstration sites, installations on several kinds of machines, and a full range of customer support activities. This could include design, development and delivery of a trainging course for MACSYMA users. Qualified applicants will have experience with a high-level language, preferably MACSYMA. Good written and verbal communication skills and prior software project involvement are desired. B.S. degree or equivalent and 2 years experience preferred. Qualified candidates should send their resume,in strict confidence, including salary history, to Gina Setteducati, Personnel Supervisor, Symbolics, Inc., 11 Cambridge Center, Cambridge, MA 02142. An equal opportunity employer. From ssc-vax!steve@uw-beaver.arpa Wed Nov 7 19:52:19 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08630; Wed, 7 Nov 84 19:52:19 pst Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA05368; Wed, 7 Nov 84 18:51:47 pst Received: by uw-beaver.arpa (4.12/2.2) id AA00936; Wed, 7 Nov 84 17:50:03 pst Return-Path: Received: by ssc-vax (4.12/4.7) id AA06915; Wed, 7 Nov 84 17:24:40 pst Date: Wed, 7 Nov 84 17:24:40 pst From: ssc-vax!steve@uw-beaver.arpa (Steve White) Message-Id: <8411080124.AA06915@ssc-vax> To: uw-beaver!franz-friends@BERKELEY Subject: readtable within fasl In "fasl.c" before the literals are read back out of the object file, the readtable is rebound to the 'standard-readtable'. This short-circuits any type of character macro expansion. Does anyone known a workaround for this? In NIL you can specify the readtable associated with the object code, I guess I'm wondering how to mimic this behavior in franz? thanks steve white (ssc-vax!steve@uw-beaver) From @MIT-MC:smh@MIT-EDDIE Thu Nov 8 07:49:13 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12925; Thu, 8 Nov 84 07:49:13 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA17112; Thu, 8 Nov 84 07:46:31 pst Message-Id: <8411081546.AA17112@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA20888; Thu, 8 Nov 84 10:33:41 est Date: Thu, 8 Nov 84 10:33:41 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: Re: readtable within fasl I too was bothered by fasl's insistence on using the standard readtable to process literals in liszt-compiled files until I realized the reason for this limitation: All source input to liszt is processed by `read' -- that is, the compiler reads only forms, never ascii strings. In order to place a literal form in an object file, liszt must essentially convert the form back into ASCII via `print'. (Actually, a somewhat modified version which knows how to wrap an assembler `.asciz' directive around the printed representation of the form, etc.) Unfortunately, liszt can make no easy assumption about what strange readtable is likely to be active at load time, so the only sane choice is to use the standard readtable. In other words, you shouldn't think of literal forms stored in a fasl object file as external (ASCII) representation of lisp data. Rather, liszt/fasl use ASCII as a convenient "position-independent" encoding of a form which has already been processed by read at compile time. This is entirely analogous to what traditional compilers and assemblers do with numeric constants represented in ASCII inside a program, except their compiler-to-loader data format uses the native binary number representation of the object machine. One could argue that this isn't really a limitation provided one is willing and able to provide the desired readtable at compile time. Usually this isn't a problem, although I once I had a macro which wanted to insert into a form a particular uninterned symbol which (obviously) couldn't even exist until execution time. I was forced to wrap the form inside another function which would accomplish the substitution at load time. There is no reason liszt could not be made to copy ASCII forms into the fasl file without read->print translation, but this would require changes to the compiler and to fasl format, things not to be done lightly. If you *really* need the facility, and don't need to read huge volumes of data, you could include ASCII forms inside a fasl file by encoding them as lisp strings, and seeing that they get processed by an appropriate function at load time, something like: (defun strange-read (str) (let ((readtable strange-readtable)) (readlist (explodec str)))) Then you can do things like: (setq foo (strange-read ") a b )c d( e (") [What? You don't like my readtable with the parens reversed?] The invocation of `strange-read' can, of course, be conveniently macrofied. If appropriate, automatic printing of literal strings can also be performed by compile time macros. You will have to deal with the problem of escaping quotes inside these forms, and you might want to enable string garbage collection if you do a lot of this sort of thing. I know it's ugly, but... Steve Haflich From @MIT-MC:smh@MIT-EDDIE Thu Nov 8 12:17:02 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15294; Thu, 8 Nov 84 12:17:02 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA22393; Thu, 8 Nov 84 11:59:13 pst Message-Id: <8411081959.AA22393@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA21531; Thu, 8 Nov 84 12:51:14 est Date: Thu, 8 Nov 84 12:51:14 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: Re: Re: readtable within fasl There was a typo in my previous mailing. The function "explodec" should have been "exploden". From BACH@SU-SCORE.ARPA Thu Nov 8 14:24:38 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16474; Thu, 8 Nov 84 14:24:38 pst Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA25584; Thu, 8 Nov 84 14:22:00 pst Message-Id: <8411082222.AA25584@UCB-VAX.ARPA> Date: Thu 8 Nov 84 14:21:16-PST From: Rene Bach Subject: printing delayed in Eunice To: franz-friends@BERKELEY Cc: bach@SU-SCORE.ARPA It appears that printing gets delayed in Eunice. What I mean by that is that I have a print statement which should indicate that the system is progressing. However, the system is chugging along, nothing shows for a long while and then the printing happens ALL at ONCE ! As if the output was buffered and go printed when something else needed to be printed. As anyone run across this before ? Is there a flag one needs to set ? Has it to do with Eunice ? What I am printing is just an atom and a ", ". When I print longer stuff, no buffering is noticed. Thanks Rene ------- From JonL.pa@Xerox.ARPA Thu Nov 8 16:34:36 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17894; Thu, 8 Nov 84 16:34:36 pst Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA27172; Thu, 8 Nov 84 15:30:06 pst Message-Id: <8411082330.AA27172@UCB-VAX.ARPA> Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 84 15:29:24 PST Date: 8 Nov 84 15:22 PST From: JonL.pa@XEROX.ARPA Subject: Re: readtable within fasl In-Reply-To: Steven M. Haflich 's message of Thu, 8 Nov 84 10:33:41 est To: smh@mit-eddie.ARPA Cc: franz-friends@BERKELEY The problems with a user-tailorable READ is one of the reasons why, over 12 years ago, we chose a format for MacLisp's FASL files that is somewhat akin to a position-independent list encoding. (But in fact, it was primarily for speed that the READ-oriented option was abandoned). However, there was still the need to introduce load-time evaluation, in order to create structures that can't be known even faintly at compile time; there is an "internal" marker, accessible to the MacLisp user as a global variable (named SQUID, I believe), so that the portions of a structure that need to be eval'd at load time could be marked. E.g. (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE)))) and the #, signals a spot for load-time evaluation, even though the overall structure is essentally a QUOTE form. One needn't imagine that #, is the only client of this "internal" marker -- it provides the way to get all but the trivial datatypes into quotified structures; for example, I may have an input syntax for arrays, but still PRINT won't put them out (MacLisp PRINT won't, at least), and certainly not every conceivable datatype needs a special encoding for the FASL file format; merely a LIST, which is viewed as a general program by EVAL, is satisfactory to create any createable datatype instance. Interlisp too has a loadtime evaluation construct, but it may only replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such as indicated by the #, above. A primary reason for this limitation is the similarity of Interlisp's and Franz's compiler output formats -- basically an ascii string to which READ is applied. MacLisp's loader is indeed quite more complex, but it results in a space savings for the FASL files and a considerable time savings when loading them. -- Jon L White -- From @MIT-MC:nss@cmu-ri-isl3.arpa Fri Nov 9 12:09:40 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26238; Fri, 9 Nov 84 12:09:40 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA04311; Fri, 9 Nov 84 12:06:51 pst Message-Id: <8411092006.AA04311@UCB-VAX.ARPA> Date: 9 Nov 84 14:02:29 EST From: Nancy.Skooglund@CMU-RI-ISL3 Subject: opening file for output, append To: BBoard.Maintainer@CMU-CS-A Does anyone know how to open a file for output in Franz lisp and @i(append) to that file? The function "outfile" always deletes the old version first. Thanks, Nancy Skooglund From @MIT-MC:day@cmu-cs-h.arpa Sun Nov 11 11:57:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16052; Sun, 11 Nov 84 11:57:03 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA15747; Sun, 11 Nov 84 11:54:17 pst Message-Id: <8411111954.AA15747@UCB-VAX.ARPA> Date: 11 Nov 84 00:15:49 EST From: David.Yaskin@CMU-CS-H Subject: Franz Question To: BBoard.Maintainer@CMU-CS-A How does one change the depth and length of list returned from functions. While using CMULisp it keeps returning & instead of my list. David Yaskin ( day@h) From Johnson%udel-dewey.delaware@udel-relay.ARPA Sun Nov 11 19:11:37 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19376; Sun, 11 Nov 84 19:11:37 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA21463; Sun, 11 Nov 84 19:08:46 pst Message-Id: <8411120308.AA21463@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a010044 ;11 Nov 84 22:09 EST Date: Sun, 11 Nov 84 22:07:41 EST From: johnson To: David.Yaskin@cmu-cs-h.ARPA Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA Subject: Re: Franz Question -------------------- for franz ----------------------------- In franz lisp, 'prinlevel' is a variable controlling the depth to which the top-level is to print lists, 'prinlength' controls how many elements of a list are printed by the top-level. For either variable, a value of 'nil' represents infinite depth or length. If franz is printing expressions as '&' then prinlevel has a value of 0. you should (setq prinlevel nil) to print lists of arbitrary depth. (see Appendix B of the Franz manual) ---------------- for CMU -------------------- In CMULisp, tlprint does the top-level printing, and this is defined, (in, at least the 2 systems that I use) as: '(lambda (x) (printlev x 4)) if your functions always return &, then perhaps someone has defined it as '(lambda (x) (printlev x 0)) if you want to change it you may either: 1. (sstatus translink nil) (defun tlprint (x) (printlev x )) OR, the solution I prefer: 2. (load 'toplevel) ; unnecessary in some installations. (defun tlprint (x) (top-print x)) causing 'prinlevel' and 'prinlength' to have the effect described above for the franz system. NB: the tempting solution: (defun tlprint (x) (printlev x prinlevel)) FAILS in the case that prinlevel is nil -johnson@udel-ee From Johnson%udel-dewey.delaware@udel-relay.ARPA Sun Nov 11 19:31:52 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19491; Sun, 11 Nov 84 19:31:52 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA21770; Sun, 11 Nov 84 19:29:03 pst Message-Id: <8411120329.AA21770@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a010257 ;11 Nov 84 22:29 EST Date: Sun, 11 Nov 84 22:21:49 EST From: johnson To: Nancy.Skooglund@cmu-ri-isl3.ARPA Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA Subject: Re: opening file for output, append In later versions of franz, 'outfile' takes a second argument; to open a file for appending: (setq portname (outfile ' 'a)) {try: (help outfile) for a full description.} If this does not work on your version, I have a hack that associates a port with ANY open file descriptor, but it uses 4.x system calls, - so don't request it unless the you can't use the new 'outfile' function. -johnson@udel-ee From @MIT-MC:nss@cmu-ri-isl1.arpa Mon Nov 12 06:45:39 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22731; Mon, 12 Nov 84 06:45:39 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA01316; Mon, 12 Nov 84 06:42:54 pst Message-Id: <8411121442.AA01316@UCB-VAX.ARPA> Date: 12 Nov 84 09:34:14 EST From: Nancy.Skooglund@CMU-RI-ISL1 Subject: append to file answer found To: BBoard.Maintainer@CMU-CS-A Thanks to all who responded to my Franz lisp question about opening a file for output and appending to it. Here's how it works: (outfile ' 'a) 'a may be replaced by any symbol or string whose name begins with a. Nancy From JAAKOV@WISDOM.BITNET Tue Nov 13 04:26:24 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04324; Tue, 13 Nov 84 04:26:24 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA20746; Tue, 13 Nov 84 04:25:59 pst Received: from wisdom.BITNET by ucbjade.CC.Berkeley.ARPA (4.17/4.27.5) id AA10274; Tue, 13 Nov 84 04:24:53 pst Received: by wisdom.BITNET (4.12/4.7) id AA01997; Tue, 13 Nov 84 11:29:45 -0200 Date: Tue, 13 Nov 84 11:29:45 -0200 From: jaakov@wisdom.BitNet (Jacob Levy) Message-Id: <8411130929.AA01997@wisdom.BITNET> To: franz-list@wisdom.BitNet Subject: Announcement of new Lisp for UN*X 4.x VAXen I don't know if this is the appropriate place for this announcement, but here goes anyway :- YLISP, a Coroutine-based Lisp System for VAXen. -=============================================- A friend of mine, Yitzhak Dimitrovski, and myself, wrote a Lisp system for UN*X 4.x systems on VAXen. It has the following features :- o - Coroutines and closures. The system uses these to implement the user-interface, single-stepping and error-handling. It's easy to write a scheduler and time-share YLISP between two or more user programs. o - Multiple-dimension arrays. o - Multiple name spaces (oblists) arranged in a tree hierarchy. This is similar to the Lisp Machine facility. o - Defstruct structure definition package. o - Flavors object-oriented programming tools. o - User-extensible evaluator (it is possible to (re)define the actions of 'eval', 'apply' and 'print' relative to all user- and pre-defined types). o - Integer arithmetic. No floating-point, sorry. don't think that that's really necessary, but *could* be hacked. No BIGNUMs either. o - Good user-interface with history, sophisticated error handling and function-call and variable-assignment tracing facilities. o - Extensive library of ported and user-contributed programs,such as a variant of the Interlisp structure editor, 'loop' macro, 'mlisp' Pascal-like embedded language, etc. o - Compiler that generates efficient native assembler code for the VAXen. The compiler is provided as a separate program,due to size considerations. The compiler is written entirely in Lisp, of course. o - Extensive online documentation, as well as a 400-page manual describing the whole system from a programmer's point of view. The system is named 'YLISP', and was written for 4.1 when we were students at the Hebrew University at Jerusalem. Since then, Yitzhak has left for the US and is currently a Ph.D. student in Prof. Schwartz's Supercomputer group at Courant. I have continued to develop the system on my own, and have ported it to UN*X 4.2. I am looking for a site that is willing to handle the distribution of this software from the US, by letting one FTP it from their computer. Alternatively, I am also willing to supply people with magtapes of YLISP, for the cost of the tape and handling charges (about 70$ a piece). If you are interested, please respond by electronic mail to one of the addresses given below. I will be ready to start distributing the system in two weeks' time. Rusty Red (AKA Jacob Levy) BITNET: jaakov@wisdom CSNET and ARPA: jaakov%wisdom.bitnet@wiscvm.ARPA UUCP: (if all else fails..) ..!decvax!humus!wisdom!jaakov From ssc-vax!steve@uw-beaver.arpa Tue Nov 13 06:20:04 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04848; Tue, 13 Nov 84 06:20:04 pst Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05430; Mon, 12 Nov 84 15:45:22 pst Received: by uw-beaver.arpa (4.12/2.2) id AA28549; Mon, 12 Nov 84 15:43:15 pst Return-Path: Received: by ssc-vax (4.12/4.7) id AA03520; Mon, 12 Nov 84 09:58:10 pst Date: Mon, 12 Nov 84 09:58:10 pst From: ssc-vax!steve@uw-beaver.arpa (Steve White) Message-Id: <8411121758.AA03520@ssc-vax> To: uw-beaver!JonL.pa@XEROX, uw-beaver!smh@mit-eddie Subject: Re: readtable within fasl Cc: uw-beaver!franz-friends@BERKELEY My problem was a bit simplier then the general case you mention. In MRS a 'variable' is really a reader-macro ($) that at read time assigns a special value to each variable-base-name. Basically it does a (set (implode `(|$| . ,(explodec name))) 'bl). for side-effects of marking the symbol as a variable. When compiling files containing MRS code the compiler would execute the call inside its environment, placing the *unbound* literals (as .asciz) in the object file to be READ in at load time... so MRS would get the symbols and treat them as symbols not variables. The only reason i mention this is that the workaround used might be useful for others seeking side effects within macros etc. My workaround (h.a.c.k) was to use a special variable liszt-eof-forms as a queue of the above SET forms and to provide a different macro expansion for compile-time. So (setsyntax '|$| 'macro #'(lambda nil (let ((varname (implode `(|$| ,@(explodec (read)))))) (addq `(setq ,varname 'bl) liszt-eof-forms) varname))) ;; return variable name to liszt! [where ADDQ does the correct thing if the variable has already been seen], adds the following to the object file .asciz "$xyz" .asciz "(setq $xyz 'bl)" which basically works (don't gag!) steve white YAP -- (yet another problem) : does anyone at MIT have a list of fixes to franz 38.91 to make the zeta-lisp environment work :-) I started fixing a few things but it looks like something that might MIT may have already done. ((or any plans to put NIL under UNIX? 8-) )) From ucscc!pravda@ucscd.ucscc.UUCP Thu Nov 15 18:09:13 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12102; Thu, 15 Nov 84 18:09:13 pst Received: by UCB-VAX.ARPA (4.24/4.39) id AA11658; Thu, 15 Nov 84 18:09:11 pst Received: from ucscd.UCSC (ucscd.ARPA) by ucscc.UCSC (4.12/4.7) id AA23553; Thu, 15 Nov 84 10:48:02 pst Received: by ucscd.UCSC (4.12/4.7) id AA04900; Thu, 15 Nov 84 10:45:19 pst Date: Thu, 15 Nov 84 10:45:19 pst From: ucscc!pravda@ucscd.ucscc.UUCP (05550000) Message-Id: <8411151845.AA04900@ucscd.UCSC> To: ucbvax!franz-friends@c.CC Subject: mailing list name change Please stop sending to ucscc!figgy instead add ucbvax!ucscc!lispers Thank you. From weeks@ucbruby.CC Thu Nov 15 20:51:49 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13810; Thu, 15 Nov 84 20:51:49 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA14507; Thu, 15 Nov 84 20:51:52 pst Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA) by ucbjade.CC.Berkeley.ARPA (4.18/4.27.5) id AA01653; Thu, 15 Nov 84 20:51:05 pst Received: by ucbruby.CC.Berkeley.ARPA (4.18/4.27.6) id AA02961; Thu, 15 Nov 84 20:50:39 pst Date: Thu, 15 Nov 84 20:50:39 pst From: weeks@ucbruby.CC (Harry Weeks) Message-Id: <8411160450.AA02961@ucbruby.CC.Berkeley.ARPA> To: franz-friends@BERKELEY Subject: Lisp implementation details. Are there any technical reports or memoranda available which describe the internal workings of Franz? -- Harry From @MIT-MC:tg@cmu-cs-cad.arpa Wed Nov 28 11:32:50 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15208; Wed, 28 Nov 84 11:32:50 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA14658; Wed, 28 Nov 84 11:32:04 pst Message-Id: <8411281932.AA14658@UCB-VAX.ARPA> Date: 28 Nov 84 14:24:42 EST From: Timothy.Glavin@CMU-CS-CAD Subject: cmulisp docs To: BBoard.Maintainer@CMU-CS-A Does anyone know the location of on-line documentation for cmulisp. If not, is there a source for hard copy documentation? I have the Foderaro Franz Lisp Manual, I only looking for info on the CMU ideosyncracies. -- Tim (tg@cad) From smith@nrl-aic Fri Nov 30 09:17:53 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15087; Fri, 30 Nov 84 09:17:53 pst Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA24282; Fri, 30 Nov 84 09:15:33 pst Date: 30 Nov 1984 11:50-EST From: Russ Smith Subject: bugs using flavors (and more) To: franz-friends@BERKELEY Message-Id: <470681409/smith@nrl-aic> I recently installed opus 38.91 on our VAX780 under 4.2BSD. The installation went smoothly. The files used for the installation appear to be the most recent available from ucbkim. This includes the flavors stuff with appropriate modifications (for example, fixing hash.l to use "vsize" instead of "getlength" on a vector). The flavors stuff I scarfed TODAY was dated October 2nd I believe. Anyway, I tried out some things with flavors and, in particular, with "describe"...with the following result (done with "script"): ============================================================================= % lisp Franz Lisp, Opus 38.91 -> (defflavor ob () () :settable-instance-variables) [autoload /usr/lib/lisp/flavors] [fasl /usr/lib/lisp/flavors.o] [fasl /usr/lib/lisp/machacks.o] [fasl /usr/lib/lisp/lmhacks.o] [fasl /usr/lib/lisp/flavorm.o] [fasl /usr/lib/lisp/vanilla.o] ob -> (describe 'ob) [autoload /usr/lib/lisp/describe] [fasl /usr/lib/lisp/describe.o] ob has property flavor: flavor[17] Error: Undefined function called from compiled code defstruct-description-name <1>: (exit) ============================================================================= [Well, "defstruct-description-name" is used all over the "/usr/lib/lisp/struct.l" set of functions...apparently mostly with no arguments...which, I think, is wrong. One fix made by SMH to "describe.l" replaced a call on this macro with one with an argument. But that's NOT this problem anyway.] (1) Is there a known fix to get the "describe", or anything else that uses the "defstruct-description-name" macro, working correctly? (2) Could it be that some sort of extended "defflavor" would load in an appropriate file which on-the-fly defines this macro? That is, did I do TOO simple a "defflavor"? [For example, doing: (load '/usr/pub/lisp/struct.l) allows one to "(pp defstruct-description-name)" showing that it requires an argument...without the "load" it is undefined.] (3) Could the copy of the ftpable (???) opus38.91 files we have be out of date (seem to be from around June 84)? Any help would be much appreciated. We are attempting to develop some stuff for use on both an LMI Lisp Machine and the VAX. This has thrown the proverbial wrench into the work(s)... Russ Navy Center for Applied Research in Artificial Intelligence (whew!) From MCLINDEN@RUTGERS.ARPA Sat Dec 1 15:40:10 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04698; Sat, 1 Dec 84 15:40:10 pst Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA03439; Sat, 1 Dec 84 14:28:56 pst Message-Id: <8412012228.AA03439@UCB-VAX.ARPA> Date: 30 Nov 84 22:45:59 EST From: Sean McLinden Subject: Re: bugs using flavors (and more) To: smith@NRL-AIC.ARPA, franz-friends@BERKELEY Cc: MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "Russ Smith " of 30 Nov 84 11:50:00 EST There is a bug in the way that describe is compiled according to the makefile. Basically the problem is that defstruct-description-name is a macro which is NOT compiled so that when you fasl the compiled version of struct (as you are compiling describe), you don't get the proper definition for defstruct-description-name. You can either 1). load struct.l when compiling describe.l or 2). (declare (macros t)) in struct.l and recompile. Sean McLinden Decision Systems Laboratory ------- From sridhar%wsu.csnet@csnet-relay.arpa Sat Dec 1 17:03:50 1984 Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27) id AA06036; Sat, 1 Dec 84 16:55:15 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.38) id AA08322; Sat, 1 Dec 84 16:50:50 pst Message-Id: <8412020050.AA08322@ucbernie.ARPA> Received: from wsu by csnet-relay.csnet id a012949; 1 Dec 84 19:41 EST Date: Sat, 1 Dec 84 12:47 PST From: "S. Sridhar" To: franz-friends@UCBERNIE.ARPA Cc: sridhar%wsu.csnet@csnet-relay.arpa Subject: Documentation pblms. Hi, I am an ardent Franz hack here at Wash. St. Univ, Pullman. I need some specific info on Franz Lisp. There is no documentation on 'Structures' in the Franz Lisp manual, that we have here. (This is dated June 1983. The version we have is Opus 38.69, June 1983). Specifically I need documentaion on all the macros related to the use of structures like defstruct. I know for sure that these macros are available on our system, but I am having problems on their usage. The on-line documentation does not give any help either. Maybe you have an updated version of the Franz Lisp manual. Can you help around, please ? As another instance, functions relating to hashtables are available here but there is no documentation for it. Thanks. Sridhar ------ From smith@nrl-aic Mon Dec 3 12:17:10 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04104; Mon, 3 Dec 84 12:17:10 pst Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA16806; Mon, 3 Dec 84 12:14:27 pst Date: 3 Dec 1984 06:36-EST From: Russ Smith Subject: followup to "flavors bugs (and more)" To: franz-friends@BERKELEY Message-Id: <470921820/smith@nrl-aic> This is a followup to a previous note I sent requesting help with fixing Opus 38.91 of Franz and Flavors running on a Vax780 under 4.2BSD. First, I want to thank the many people who had helpful suggestions on what may have been going wrong. Given the small amount of information I provided on the problem, some of them were remarkably relevant. The problem had to do with certain functions such as "describe" going south when invoked on a FLAVOR object. The solution was (at least) two fold. One, which I alluded to in the previous note, had to do with the distributed file "hash.l" containing invalid calls on the intrinsic "getlength" function with a vector argument. These calls had to be changed to "vsize" instead (actually "getlength" could probably have been redefined to allow vectors...). Whatever, that solved that part. The second solution had to do with how WE at NCARAI were installing Franz. We have a set of directories for "local" software into which we wanted to put the "new" Franz. As such, I went through all the "Makefile"s and changed default directories for such things as the libraries and objects, etc. While doing this, it was noted that certain files in the "lisplib" directory had hard-coded the default names for, for example, the library. Since our library was not in the same place as this default, these lines were "commented out" (with an "exit")...with the result that the Franz and Liszt installations did not go as smoothly as I thought. It turns out that these lines also should be changed to reflect the appropriate directory. They are in the files "buildlisp.l", "common1.l", and "fix.l" in the lisplib directory (possibly others exist as well). The pertinent lines read something like: (or (boundp 'default-library-directory) (setq default-library-directory '/usr/lib/lisp)) During the installation (done on a CRT) I was doing something else. Thus when the mods made (namely changing the "setq" call above into an "exit") were invoked, I didn't notice later that a number of things which SHOULD have happened didn't (they'd gone off the screen...). Needless to say, this caused all sorts of bizarre inconsistencies (especially since our last installation DID use the default directories...). Anyway, notes for the future: (1) If ftp'ing Franz from ucbkim be sure to get the stuff in the "flavors" directory as well. This contains a new "hash.l" modified by SMH to use "vsize" rather than "getlength". (2) If not using the default directories for the installation, change the names in the above files as well to reflect the appropriate place(s)...sigh. Yours (with an apparently working Franz+flavors), Russ Navy Center for Applied Research in Artificial Intelligence (whew!) From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 12:49:49 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20917; Tue, 4 Dec 84 12:49:49 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA24636; Tue, 4 Dec 84 12:13:23 pst Message-Id: <8412042013.AA24636@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA19371; Tue, 4 Dec 84 14:50:26 est Date: Tue, 4 Dec 84 14:50:26 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: the *real* flavor sources (etc.) For some time I have been using and maintaining enhanced versions of the several Franz lisplib modules which implement various Lisp Machine compatibilities, most notably, the FLAVOR system and FORMAT output. jkf@berkeley has authorized me to announce public availability of these files via anonymous ftp from UCBKIM. These seven files are compatible with Opus 38.91, but supersede the versions in the 39.91 distribution. There are a number of bugfixes and new features. UCBKIM supports FTP with login "anonymous" and any password. The files are: ~anonymous/pub/flavors/Makefile flavors.l flavorm.l vanilla.l hash.l describe.l format.l The changes are too many to describe in detail. Many of the FLAVOR system changes are for compatibility with changes to Franz, although a few non-working or missing features (but not all) have been bludgeoned into functionality. In particular, wrappers work. The FORMAT module fixes a number of format directives which apparently never worked. However, some of the hairier ones are known still to be defective. This "completely unsupported" software is graciously being made available to all takers without any promises whatever: there is no promise of correctness, and no promise of support. Also, the sources total 160K and unsuitable for uucp distribution, and I don't have time to deal with tape requests [sorry]. The above notwithstanding, I am as eager as anyone for additional improvements to the code. Anyone with additional bugfixes is encouraged to communicate to me, and I will try to integrate the code. I will try to respond to bug reports, but it may be a rather low priority business. Steve Haflich MIT Experimental Music Studio ARPA: smh@mit-eddie@mit-mc UUCP: {ihnp4, decvax!genrad}!mit-eddie!smh From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 19:32:49 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26327; Tue, 4 Dec 84 19:32:49 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA26237; Tue, 4 Dec 84 13:26:17 pst Message-Id: <8412042126.AA26237@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA20260; Tue, 4 Dec 84 15:44:20 est Date: Tue, 4 Dec 84 15:44:20 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: fix for describe.l Cc: MCLINDEN@RUTGERS@MIT-MC, smith@nrl-aic@mit-mc Previous postings have correctly identified the problem (which was fixed long ago in the versions announced today). The best fix is to change the (environment-lmlisp) invocation near the beginning of describe.l to read as follows, then recompile it: (environment-lmlisp (compile eval) (files struct flavorm)) The struct and flavorm modules do not need to be around when the compiled describe code is executed, so omitting load from the eval-when saves some unnecessary fasl's. Describe, by the way, is useful even when flavors and defstructs are not being used. For instance, it will report the source module in which a compiled function lives. Steve Haflich smh@mit-eddie@mit-mc {ihnp4, decvax!genrad}!mit-eddie!smh From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 22:49:05 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA29026; Tue, 4 Dec 84 22:49:05 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05974; Tue, 4 Dec 84 20:50:44 pst Message-Id: <8412050450.AA05974@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA24308; Tue, 4 Dec 84 23:50:01 est Date: Tue, 4 Dec 84 23:50:01 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: Franz documentation for MIT LM code Cc: sridhar%wsu.csnet@csnet-relay Sorry to report that there really is no official documentation for the several Franz lisplib modules which implement a measure of compatibility with Zetalisp, the dialect running on MIT Lisp Machines (and, more or less, on Symbolics and LMI machines). The Franz source code was adapted from the MIT Lisp machine code several years ago; there is still approximate compatibility, although new features and certain semantic subtleties have diverged. Driven partially by natural evolution and partially by the standardization efforts of Common Lisp, Lisp Machine compatibility is something of a moving target. But do not despair; there are two standardly available sources for documentation. Reading them will give a very usable idea about the packages. Unfortunately, a few unimplemented features and semantic differences will have to be discovered by experimentation or examination of the source code. (What do you want for free? :-) (1) If you have available a MIT Lisp Machine Manual, the sections on defstruct, flavors, format, hash, and loop output are still reasonable approximations of documentation for the Franz versions. Incidentally, the `Blue' MIT Lisp Machine Manual circa 1981 corresponds most closely with the Franz inplementation, although a few more recent features have been retrofitted. If available, Symbolics documentation is probably only very slightly less good -- the older, the better. (2) For defstruct, hash, and format the Guy Steele , published by Digital Press (a branch of DEC), is usefully close to the existing Franz code. Again, experimentation and examination of the source code will resolve the details. Unfortunately, Flavors and the loop macro are not (yet) part of the Common Lisp specification, and may well be very different when they are. Unofficially, there is another even better hope. The MIT Athena project will be `releasing' these packages into their standard Franz system this in another month or two. They are commencing a quick effort to edit Lisp Machine documentation into proper format for inclusion as appendixes in the Franz manual. If at all possible, I will attempt to get the results publically distributed. (Translation: My assistance is essential to this documentation, so I am in position to insist they be `reasonable' about it...) But no promises just yet. Steve Haflich MIT From MAILER@CUNYVM.BITNET Thu Dec 6 13:53:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03880; Thu, 6 Dec 84 13:53:03 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA27039; Thu, 6 Dec 84 11:43:13 pst Received: from CUNYVM.BITNET by ucbjade.CC.Berkeley.ARPA (4.19/4.30) id AA27252; Thu, 6 Dec 84 11:44:10 pst Message-Id: <8412061944.AA27252@ucbjade.CC.Berkeley.ARPA> Received: by CUNYVM id 8508; Thu, 06 Dec 84 14:41:26 EST Date: Thu, 6 Dec 84 14:39 EST From: Henry Nussbacher To: , , , , , Can you please register the following user to your lists: arpalist%cunyvm.BITNET Thank you, Henry Nussbacher BITNET Network Information Center From mike@rice.ARPA Thu Dec 6 18:20:03 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07782; Thu, 6 Dec 84 18:20:03 pst Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05141; Thu, 6 Dec 84 17:55:14 pst Received: from thule by rice.ARPA (AA02673); Thu, 6 Dec 84 19:41:33 CST Received: by thule (AA02845); Thu, 6 Dec 84 19:38:53 cst Date: Thu, 6 Dec 84 19:38:53 cst From: Mike Caplinger Message-Id: <8412070138.AA02845@thule> To: franz-friends@BERKELEY Subject: bug in 68k Opus 38.91 arrays In 68k Opus 38.91, the expression (array foo flonum-block 4 4) generates an "Error: IMPROPER USE OF SET". On the VAX, in Opus 38.79, this worked fine. What's happening? (I am on a Sun, compiled with sun_4_2.) - Mike From @MIT-MULTICS.ARPA:POSTMASTER@VANDERBILT.MAILNET Sat Dec 8 05:42:09 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA25844; Sat, 8 Dec 84 05:42:09 pst Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA22892; Sat, 8 Dec 84 05:39:47 pst Received: from VANDERBILT.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2648813816713007@MIT-MULTICS.ARPA>; 08 Dec 1984 08:36:56 est Date: 06 Dec 84 15:26 CDT From: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA Reply-To: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA To: "franz-friends"@BERKELEY Subject: FranzLISP on the S9000 Message-Id: <30788@VUCCG1COM> In-Reply-To: <30731@VUCCG1COM> The AI Group at Vanderbilt would like to join the franz-friends mailing list. We have version 38.87 running on the IBM Inruments S9000 under CSOS 1.1, a very non-UNIX opsys. Both interpreter and compiler are working and a farily large general-purpose expert system tool set written on a VAX is up and running. From MOHAN@USC-ECLC.ARPA Mon Dec 10 12:06:53 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA18655; Mon, 10 Dec 84 12:06:53 pst Received: from USC-ECLC.ARPA (usc-eclc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA04397; Mon, 10 Dec 84 12:04:27 pst Message-Id: <8412102004.AA04397@UCB-VAX.ARPA> Date: Mon 10 Dec 84 12:03:06-PST From: MOHAN@USC-ECLC.ARPA Subject: array - space To: franz-friends@BERKELEY Cc: mohan@USC-ECLC.ARPA I am working with images stored as fixnum arrays (with delta =1 i.e. four pixels packed into a word) aux as unmarked arrays. (I am on a VAX under Eunice). How do I deallocate the array-space once I am done with it? (I use small-segment to allocate space for the array). Also I would appreciate any pointers of how to speed up programs with nested do loops (order of 512x512 x(5 x 5) itterations). Thanks, -Rakesh Mohan. ------- From mike@rice.ARPA Mon Dec 10 15:37:50 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20942; Mon, 10 Dec 84 15:37:50 pst Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA08450; Mon, 10 Dec 84 15:35:12 pst Received: from iapetus by rice.ARPA (AA26746); Mon, 10 Dec 84 17:28:43 CST Received: by iapetus (AA16942); Mon, 10 Dec 84 17:29:45 CST Date: Mon, 10 Dec 84 17:29:45 CST From: Mike Caplinger Message-Id: <8412102329.AA16942@iapetus> To: franz-friends@BERKELEY Subject: gensym and the compiler How does one get code like the following: ; construct an identity transformation matrix. (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (store (name i i) 1.0)) name) ) to work under the compiler? Compiled, this refuses to believe in the existence of name. Do I need to declare it as a lambda? Is there a way to declare arrays? - Mike From jkf@ucbmike Mon Dec 10 16:03:40 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA21396; Mon, 10 Dec 84 16:03:40 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA08955; Mon, 10 Dec 84 16:01:22 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA06150; Mon, 10 Dec 84 16:04:09 pst Date: Mon, 10 Dec 84 16:04:09 pst From: John Foderaro (on a sun) Message-Id: <8412110004.AA06150@ucbmike.arpa> To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY Subject: Re: array - space Cc: mohan@USC-ECLC.ARPA In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST You would be better off using immediate vectors (vectori) which are garbage collected. Items allocated with small-segment aren't gc'ed. From jkf@ucbmike Mon Dec 10 17:08:13 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22000; Mon, 10 Dec 84 17:08:13 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA10131; Mon, 10 Dec 84 17:05:36 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA06315; Mon, 10 Dec 84 17:08:19 pst Date: Mon, 10 Dec 84 17:08:19 pst From: John Foderaro (on a sun) Message-Id: <8412110108.AA06315@ucbmike.arpa> To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY Subject: Re: array - space Cc: mohan@USC-ECLC.ARPA In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST One small correction: small-segment space is garbage collected and reclaimed, but only as individual elements: adjacent free elements are not combined. Vectors are different: adjacent free vectors are combined into larger vectors. From @MIT-MC:smh@MIT-EDDIE Mon Dec 10 19:02:52 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23540; Mon, 10 Dec 84 19:02:52 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA11754; Mon, 10 Dec 84 18:21:17 pst Message-Id: <8412110221.AA11754@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA03264; Mon, 10 Dec 84 21:20:04 est Date: Mon, 10 Dec 84 21:20:04 est From: Steven M. Haflich To: franz-friends@BERKELEY Subject: re: gensym and the compiler wants to know how to make this function work: ; construct an identity transformation matrix. (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (store (name i i) 1.0)) name) ) The problem is that send is a macro (see lisplib/array.l), and at compile time it is impossible for it to determine exactly the "data type" of name. Therefore, it expands the function to: (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (name 1.0 i i)) name) ) Essentially, it just assumes 'name is a symbol which has an array in its function binding, or else which symevals (possibly recursively) to something that is either an array, or a symbol with an array in its function binding. When the compiler compiles the expansion, it assumes that it wants to call the function-binding of name, not the function-binding of symeval of name. In the interpreter it happens to work because eval of a list in the interpreter (but not the compiler) is defined to repetitively evaluate the car of the list until it finds a recognizable function or array. (See chapter 4.) But note!! If 'name also has a function binding, the interpreter will find it instead of the array! What you really want to do, then, is this: (defun tm-new () (let ((name (gensym))) (*array name 'flonum-block 4 4) (do i 0 (1+ i) (= i 4) (funcall name 1.0 i i)) name) ) This guarantees that name gets symevaled once before the interpreter checks for function bindings, which also does the right thing in compiled code. Unfortunately, you will have to write this out by hand. I don't see any way that the send macro can be fixed. If it always returned the extra funcall, then this simple case wouldn't work compiled: (array foo ...) (store foo ...) Did anyone follow any of this? From BACH@SUMEX-AIM.ARPA Tue Dec 11 20:05:09 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06334; Tue, 11 Dec 84 20:05:09 pst Received: from SUMEX-AIM.ARPA (sumex-aim.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA15218; Tue, 11 Dec 84 20:03:46 pst Message-Id: <8412120403.AA15218@UCB-VAX.ARPA> Date: Tue 11 Dec 84 20:04:16-PST From: Rene Bach Subject: Porting FRANZ to other OS running C ? To: franz-friends@BERKELEY I am interested in finding out if someone has ported FRANZ to some other OS than UNIX. A friend of mine is interested in running a LISP under VMS at no cost. He has C on his machine. Is this feasible, how much work is involved ? What about porting FRANZ to some UNIX look alike ? How much work is involved ? Thanks for any leads Rene ------- From MCLINDEN@RUTGERS.ARPA Tue Dec 11 20:44:19 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06672; Tue, 11 Dec 84 20:44:19 pst Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA16044; Tue, 11 Dec 84 20:42:36 pst Message-Id: <8412120442.AA16044@UCB-VAX.ARPA> Date: 11 Dec 84 23:41:49 EST From: Sean McLinden Subject: Re: Franz documentation for MIT LM code To: smh%MIT-EDDIE@MIT-MC.ARPA, franz-friends@BERKELEY Cc: sridhar%wsu.csnet@CSNET-RELAY.ARPA, MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "Steven M. Haflich " of 4 Dec 84 23:50:01 EST Regarding the documentation for Franz Lisp and the MIT/Lisp Machine compatibility packages: Another option exists for those who might be interested. We at Decision Systems Lab have been using a modified version of Opus 38.89 which in- cludes the defstruct and flavors code already described. It also in- cludes an Interlisp compatibility package which allows Interlisp records as well as most of the CLISP forms (these are actually very easily simulated with LOOP but we chose a strategy which is more in keeping with the Interlisp implementation of CLISP involving hashed definitions for CLISP forms. The modified Lisp has all of the up-to-date flavors code and an edited version of the manual which describes the format, defstruct, and CLISP packages (borrowing heavily from the Laser edition of the Common Lisp manual by Guy Steele). It also includes a re-organization of much of the older manual into a more coherent form, and a number of examples of more difficult concepts. If there is any interest I can make this publicly available. It would be of little value to simply have the additional chapter since it refers, heavily, to material in other sections. Also, flavors is not, yet included, since the status of flavors in Franz was uncertain up to a few months ago. For those interested, I will not be prepared to answer requests before Christmas but after that I'll be around and can handle almost anything. Sean McLinden Decision Systems Laboratory University of Pittsburgh ------- From @MIT-MC:ZZZ.RLK@MIT-OZ Wed Dec 12 21:51:39 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08208; Wed, 12 Dec 84 21:51:39 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA07258; Wed, 12 Dec 84 21:03:56 pst Message-Id: <8412130503.AA07258@UCB-VAX.ARPA> Date: Wednesday, 12 December 1984, 19:53-EST From: Robert L. Krawitz Reply-To: rlk%mit-eecs at mit-mc.arpa To: franz-friends@BERKELEY Hi. I'm writing a term paper on the procedure call in various languages, perhaps on various languages on the VAX, perhaps just on the procedure call in various dialects of Lisp on the Vax. Could someone mail me some info on this subject (i. e. the calling conventions, how/if the Vax procedure call instructions are used, etc.) quickly, as this is the last week of classes and I don't want to take too long on this paper. Thanks. Robert^Z From psm@mitre-bedford Mon Dec 17 09:05:35 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20993; Mon, 17 Dec 84 09:05:35 pst Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA19421; Mon, 17 Dec 84 09:04:32 pst Message-Id: <8412171704.AA19421@UCB-VAX.ARPA> Date: 17 Dec 1984 11:56:37-EST From: psm@Mitre-Bedford To: franz-friends@BERKELEY Subject: Please add me to your mailing list. Cc: psm@Mitre-Bedford Hi, Would you please add me to your mailing list/ user's group. (I hope this is the right place to make the request & it's not franz-friends-request or something like that. Sorry for the inconvenience if it is.) Peter Mager (psm@mitre-bedford) From jkf@ucbmike Mon Dec 17 13:01:48 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00901; Mon, 17 Dec 84 13:01:48 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24456; Mon, 17 Dec 84 13:00:55 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA15009; Mon, 17 Dec 84 13:03:16 pst Date: Mon, 17 Dec 84 13:03:16 pst From: John Foderaro (on a sun) Message-Id: <8412172103.AA15009@ucbmike.arpa> To: psm@Mitre-Bedford, franz-friends@BERKELEY Subject: Re: Please add me to your mailing list. Cc: psm@Mitre-Bedford In-Reply-To: Your message of 17 Dec 1984 11:56:37-EST I've added you to franz-friends. From jkf@ucbmike Mon Dec 17 13:06:53 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01005; Mon, 17 Dec 84 13:06:53 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40) id AA24568; Mon, 17 Dec 84 13:05:59 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA15044; Mon, 17 Dec 84 13:08:10 pst Date: Mon, 17 Dec 84 13:08:10 pst From: John Foderaro (on a sun) Message-Id: <8412172108.AA15044@ucbmike.arpa> To: franz-friends@BERKELEY Subject: I'll be away Cc: For the new few weeks I'll be unable to handle franz-friends requests. Happy Holidays to all of you. john foderaro From @MIT-MC:wah@cmu-cs-ius.arpa Mon Dec 17 13:08:08 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01035; Mon, 17 Dec 84 13:08:08 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA24610; Mon, 17 Dec 84 13:07:10 pst Message-Id: <8412172107.AA24610@UCB-VAX.ARPA> Date: 17 Dec 84 16:02:13 EST From: Wilson.Harvey@CMU-CS-IUS Subject: appending to files in lisp? To: BBoard.Maintainer@CMU-CS-A Does anyone have a function that will allow them to append to a file? I need to open a file and write some data to it then, at a later time, reopen the same file and add some more data to it. The only things that I could find in Franz were "infile" and "outfile", and "outfile" truncates the file when called. It would be nice if the function would create the file if it didn't already exist, but that is not necessary. Thanks. --Wilson P.S. I tried writing a C-function to handle this, but I didn't have any luck passing the FILE pointer back into Franz. It didn't recognize the pointer as a port, and I don't know how to set it straight. From cadwall@Ardc.ARPA Mon Dec 17 13:31:59 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01357; Mon, 17 Dec 84 13:31:59 pst Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA25405; Mon, 17 Dec 84 13:30:56 pst Message-Id: <8412172130.AA25405@UCB-VAX.ARPA> Date: Mon, 17 Dec 84 16:23:16 EST From: William K. Cadwallender (LCWSL) To: franz-friends@BERKELEY Subject: Please change my ID The computer people here at ARDC have changed my ID: I was wkc@ARDC, I am now cadwall@ARDC. Please update the franz-friends mailer accordingly. Thanks, Bill Cadwallender (now cadwall@ARDC) From liz@tove Tue Dec 18 12:19:24 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00302; Tue, 18 Dec 84 12:19:24 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA04349; Tue, 18 Dec 84 11:54:53 pst Received: by tove.ARPA (4.12/4.7) id AA26165; Tue, 18 Dec 84 14:54:41 est From: Liz Allen Message-Id: <8412181954.AA26165@tove.ARPA> Date: 18 Dec 1984 1454-EST (Tuesday) To: Wilson.Harvey@CMU-CS-IUS Cc: franz-friends@BERKELEY Subject: Re: appending to files in lisp? In-Reply-To: Your message of 17 Dec 84 16:02:13 EST. <8412172107.AA24610@UCB-VAX.ARPA> To append to a file, use the outfile function's second argument: (setq oport (outfile ' 'append)) This is discussed in the documentation for outfile in the Franz Lisp Manual. -Liz From @MIT-MC:wah@cmu-cs-ius.arpa Tue Dec 18 16:46:44 1984 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02563; Tue, 18 Dec 84 16:46:44 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA10079; Tue, 18 Dec 84 16:15:50 pst Message-Id: <8412190015.AA10079@UCB-VAX.ARPA> Date: 17 Dec 84 23:04:24 EST From: Wilson.Harvey@CMU-CS-IUS Subject: appendfile question answered To: BBoard.Maintainer@CMU-CS-A Wow, was that an easy question. All the responces were equally simple (use "fileopen" with mode = a, or use "outfile" with the extra argument "append"). I must have an outdated copy of the manual because I could find none of these "features" documented. A hearty "Thank you" to all who responded. Wilson From johnson@UDEL-EECIS2.DELAWARE Wed Jan 2 03:00:04 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08140; Wed, 2 Jan 85 03:00:04 pst Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40) id AA01144; Wed, 2 Jan 85 02:51:04 pst Message-Id: <8501021051.AA01144@UCB-VAX.ARPA> Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a029713 ;2 Jan 85 5:57 EST To: franz-friends@BERKELEY Cc: johnson@udel-dewey Subject: franz on 68k-based systems? (esp NCR tower) Date: 02 Jan 85 05:57:37 EST (Wed) From: johnson Has anyone out there had experience using franz (or similar lisps) on an NCR tower or tower XP? (or any other 68k-based unix system ?) I am interested in answers to these questions: 1. What version of (franz) lisp are you using. 2. Are there any special problems you've discovered in this system? 3. How does this system perform? (compared to franz on a VAX 11/70, assuming you have had experience with both) 4. Where did you obtain your version of (franz) lisp and how? (what media, what cost, under what terms or license?) thanks in advance, johnson@udel-ee From sridhar%wsu.csnet@csnet-relay.arpa Thu Jan 24 00:31:15 1985 Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27) id AA12825; Thu, 24 Jan 85 00:31:15 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.40) id AA15268; Thu, 24 Jan 85 00:31:03 pst Message-Id: <8501240831.AA15268@ucbernie.ARPA> Received: from wsu by csnet-relay.csnet id a006053; 24 Jan 85 3:16 EST Date: Wed, 23 Jan 85 21:50 PST From: "S. Sridhar" To: cross%lsu.csnet@csnet-relay.arpa Cc: franz-friends@UCBERNIE.ARPA Subject: pretty printing Is there any way I can pretty-print Franz lisp function (or files) with all the comments in tact. Right now when I use the built in pp, it pretty prints and strips off all comments. I mean is there any built-in function that does this. Thanks. Sridhar (sridhar@wsu) From fsbrn@BRL-VOC.ARPA Thu Jan 24 05:33:59 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14557; Thu, 24 Jan 85 05:33:59 pst Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA00666; Thu, 24 Jan 85 05:16:27 pst Message-Id: <8501241316.AA00666@UCB-VAX.ARPA> Date: Thu, 24 Jan 85 7:59:46 EST From: "Ferd Brundick (VLD/LTTB)" To: "S. Sridhar" Cc: Franz-Friends@BERKELEY Subject: Re: pretty printing Haah, Franz's (read) function trashes all comments on input. [Which means you can document your data files.] You have to pretty-print the original code before Franz gets it. I don't know of any stand-alone programs to do this (surely someone has written one). I use Berkeley's "vi" editor because it has a lisp mode; all input is automatically pretty-printed if you say :set ai lisp (ai stands for autoindent) Another way is to execute the vi "=" command while in lisp mode. All of this is documented in the vi manual. Hope this helps. dsw, fferd Fred S. Brundick USABRL, APG, MD. From @MIT-MC:smh@MIT-EMS Thu Jan 24 06:01:33 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14651; Thu, 24 Jan 85 06:01:33 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA00458; Thu, 24 Jan 85 06:00:41 pst Message-Id: <8501241400.AA00458@UCB-VAX.ARPA> Received: by mit-ems.Mit-chaos.Arpa id AA25956; Thu, 24 Jan 85 08:59:42 est Date: Thu, 24 Jan 85 08:59:42 est From: Steven Haflich To: franz-friends@BERKELEY, sridhar%wsu.csnet@csnet-relay Subject: Re: pretty printing Since comments are not part of a Lisp form returned by `read', clearly no pretty-print function can do what you want. Certainly a far more complicated pretty-printer could be written which would be passed an ascii file to read and which would somehow preserve comments inside the form in order to regurgitate them during formatting. The problem has several complications, however, such as how to handle ascii Lisp text with conditionalized inclusions (`#+' constructions)... Instead, what you want is probably provided the Lisp-mode `grind' facilities available in several popular text editors -- in particular, EMACS. (I know CCA EMACS works, and believe Gosling EMACS does also.) In these editors a couple keystrokes will specify a region of text and apply one of several Lisp-indentation algorithms to it. They almost always indent in reasonable ways, and attempt to do reasonable things with comments, at least. The ones with which I am familiar will *not*, however, adjust line length length by moving either comment or Lisp text from line to line. This is not a great problem for normal human-typed text, such as programs, since one tends not to type absurdly long lines. From peck@sri-spam Wed Feb 6 12:01:17 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA28782; Wed, 6 Feb 85 12:01:17 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA04441; Wed, 6 Feb 85 12:00:09 pst Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16) id AA08198; Wed, 6 Feb 85 12:00:05 pst Message-Id: <8502062000.AA08198@sri-spam.ARPA> Date: 06 Feb 85 11:59:58 PST (Wed) To: ailist-request@sri-ai, franz-friends@BERKELEY Subject: AI, Lisp, Graphics on SUN computers? From: peck@sri-spam I would like to here from anyone using SUN computers who can supply answers or comments on any of these issues: Is Franz the only (best) lisp available? Has anyone used the Maryland Flavors to create useful tools/extensions? Any support for sun graphics (windows, menus,etc) a la Interlisp-D? Any differential reports of Prolog (Quintus) vs Lisp ? Any obvious alternative to SUN? (vendor in same class (Tektronix?)) Worst or hidden problems, pitfalls, gotcha's, etc. > Can real AI development (even applications) be supported on SUN's? < From kessler%utah-orion@utah-cs Wed Feb 6 15:58:12 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03031; Wed, 6 Feb 85 15:58:12 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA06871; Wed, 6 Feb 85 13:46:19 pst Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1) id AA03096; Wed, 6 Feb 85 14:37:05 MST Received: by utah-orion.ARPA (4.42/4.40.1) id AA10406; Wed, 6 Feb 85 14:36:22 MST Date: Wed, 6 Feb 85 14:36:22 MST From: kessler%utah-orion@utah-cs (Robert Kessler) Message-Id: <8502062136.AA10406@utah-orion.ARPA> To: peck@sri-spam.ARPA Cc: ailist-request@sri-ai.ARPA, franz-friends@BERKELEY Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message) In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed). <8502062000.AA08198@sri-spam.ARPA> > I would like to here from anyone using SUN computers > who can supply answers or comments on any of these issues: > Is Franz the only (best) lisp available? We have finally finished porting Portable Standard LISP (PSL) to yet another machine. This time it is now running on the SUN. Initial timing measurements indicate that its speed is somewhere between a Vax 750 and 780 (all running PSL), and about twice as fast as Franz running the REDUCE algebra system test on Suns. We are now running the Gabriel benchmarks to discover where it fits in the set. For more details see the announcement at the end of this message. > Has anyone used the Maryland Flavors to create useful tools/extensions? PSL provides support for a simple flavors package that seems quite useful. However, the current version has no inheritance. > Any support for sun graphics (windows, menus,etc) a la Interlisp-D? We have oload working which allows you to call externally compiled routines (like other c sources). So the interface should be easy to add (but we haven't done it). > Any differential reports of Prolog (Quintus) vs Lisp ? None that I know of. > Any obvious alternative to SUN? (vendor in same class (Tektronix?)) PSL also runs on Apollo's and HP Series 200 (both 68K based machines). We have also ported a simple "educational" version to the 128K Macintosh which is used in a beginning programming class. We plan on moving at least the Standard LISP subset and compiler to the 512K mac (so if you want to go really cheap...... :-) ) > Worst or hidden problems, pitfalls, gotcha's, etc. We had a lot of problems with the Sun port. Some were hardware related, others were differences between Unix 4.2 on the Sun and on the Vax. After we get some more experience using PSL on the machine, maybe we could report more. > > Can real AI development (even applications) be supported on SUN's? < I think so, as long as you can get one with enough memory. Some of our applications running on HP 9836's (which doesn't have virtual memory) really fly (better than a 780 in speed). So, memory is really a key to a fast machine. > Bob. PSL 3.2 for the SUN Workstation We are pleased to announce that Portable Standard LISP (PSL) version 3.2 is now available for the Sun workstation. PSL is about the power, speed and flavor of Franz LISP or MACLISP, with growing influence from Common LISP. It is recognized as an efficient and portable LISP implementation with many more capabilities than described in the 1979 Standard LISP Report. PSL's main strength is its portability across many different systems, including: Vax BSD Unix, Vax VMS, Extended Addressing DecSystem-20 Tops-20, Apollo DOMAIN Aegis, and HP Series 200. A version for the IBM-370 is in beta test and two Cray versions are being used on an experimental basis. Since PSL generates very efficient code, it is an ideal delivery vehicle for LISP based applications (we can also provide PSL reseller licenses for binary only and source distributions). PSL is distributed for the various systems with executables, all sources, an approximately 500 page manual and release notes. The release notes describe how to install the system and how to rebuild the various modules. We are charging $750 for the Sun version of PSL for Commercial Site licenses. Non-profit institutions and all other versions of PSL will not be charged a license fee. We are also charging a $250 tape distribution fee for each system. PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard, Rand, Stanford, Columbia and over 250 other sites. Many existing programs and applications have been adapted to PSL including Hearn's REDUCE computer algebra system and GLISP, Novak's object oriented LISP dialect. These are available from Hearn and Novak. To obtain a copy of the license and order form, please send a NET message or letter with your US MAIL address to: Utah Symbolic Computation Group Secretary University of Utah - Dept. of Computer Science 3160 Merrill Engineering Building Salt Lake City, Utah 84112 ARPANET: CRUSE@UTAH-20 USENET: utah-cs!cruse From cas@cvl Thu Feb 21 11:40:59 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17380; Thu, 21 Feb 85 11:40:59 pst Received: from cvl.ARPA (cvl.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA23930; Thu, 21 Feb 85 11:33:27 pst Received: by cvl.ARPA (4.12/4.7) id AA09421; Thu, 21 Feb 85 14:38:26 est Date: Thu, 21 Feb 85 14:38:26 est From: cas@cvl (Cliff Shaffer) Message-Id: <8502211938.AA09421@cvl.ARPA> To: franz-friends@BERKELEY Subject: database system request Does anybody know of a database system written in FRANZ or easily compatible with FRANZ? We have written a lot of software for a geographic information system, and may want to redo the section which handles random bits of information associated with polygons or points stored in a map. Right now we store this information as a property list on an atom associated with the polygon or point in question. This becomes very inefficient when we want to find all such atoms with a particular value for some arbitrary property. Equally importantly, there is very little relationship between the set of properties associated with each polygon or point, so a system storing a fixed length record for each polygon, with fields for each piece of information, would not work. Any suggestions? Cliff Shaffer cas@cvl From layer@ucbdali Thu Feb 21 12:54:14 1985 Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27) id AA18356; Thu, 21 Feb 85 12:54:14 pst Received: by ucbdali.ARPA (4.24/4.40) id AA16858; Thu, 21 Feb 85 12:53:47 pst Date: Thu, 21 Feb 85 12:53:47 pst From: layer@ucbdali (Kevin Layer) Message-Id: <8502212053.AA16858@ucbdali.ARPA> Phone: (415) 652-2405 To: cas@cvl, franz-friends@kim Subject: Re: database system request You could use the dbm library, as supplied by UNIX (/usr/lib/libdbm.a), via cfasl and getaddress. Kevin From freemant%rpi.csnet@csnet-relay.arpa Mon Feb 25 04:50:50 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20175; Mon, 25 Feb 85 04:50:50 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.41) id AA24603; Mon, 25 Feb 85 04:43:20 pst Date: Mon, 25 Feb 85 04:43:17 pst Message-Id: <8502251243.AA24603@UCB-VAX.ARPA> Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST From: freemant%rpi.csnet@csnet-relay.arpa To: franz-friends@BERKELEY Hello! Our version of lxref didn't work right when it was passed the -a option, so I fixed it. Someone may want to use the -a option on lxref one of these days, so I am mailing you my fixes in hopes that you will distribute them. Things are kind of chaotic around here, so I am not sure that I was working with the most current version of lxref. Make sure that your current version of lxref matches the code that I changed before you edit in my changes. The origional definition of the function process-annotate-file left files open. Because the lisp interpreter can only have a finite number of files open at once, this caused lxref to bomb when it was given a large job to do. To fix this, I changed the definition of process-annotate-file from: (defun process-annotate-file (filename) (let (sourcep outp) ; make sure file exists and write annotate file as a ; file with the prefix #, (if (null (errset (setq sourcep (infile filename)))) then (msg "will ignore that file " N) else ; will write to file.A (erasing the final l) (let ((filen (concat "#," filename))) (setq outp (outfile filen)) (anno-it sourcep outp) (close outp) ; now mv the original filename to #dfilename ; and the annotated file to the original file (let ((oldcopy (concat "#." filename))) (if (null (errset (progn (if (probef oldcopy) then (sys:unlink oldcopy)) (sys:link filename oldcopy) (sys:unlink filename) (sys:link filen filename) (sys:unlink filen)))) then (msg "An error occured while mving files around " N "files possibly affected " filename oldcopy filen))))))) to: (defun process-annotate-file (filename) (let (sourcep outp) ; make sure file exists and write annotate file as a ; file with the prefix #, (if (null (errset (setq sourcep (infile filename)))) then (msg "will ignore that file " N) else ; will write to file.A (erasing the final l) (let ((filen (concat "#," filename))) (setq outp (outfile filen)) (anno-it sourcep outp) (close outp) (close sourcep) ; now mv the original filename to #dfilename ; and the annotated file to the original file (let ((oldcopy (concat "#." filename))) (if (null (errset (progn (if (probef oldcopy) then (sys:unlink oldcopy)) (sys:link filename oldcopy) (sys:unlink filename) (sys:link filen filename) (sys:unlink filen)))) then (msg "An error occured while mving files around " N "files possibly affected " filename oldcopy filen))))))) Note that the only change is the insertion of one close statement. The other bug I found was that find-func miserably failed to do its job right. The origional version of the function looked like this: (defun find-func (buf) ; first locate first space or tab (do ((i 1 (1+ i)) (max (cxr 0 buf)) (die)) ((or (setq die (not (<& i max))) (memq (cxr i buf) '(#\space #\tab))) (if die then nil ; can find it, so give up else ; find first non blank (do ((ii i (1+ ii))) ((or (setq die (not (<& ii max))) (not (memq (cxr ii buf) '(#\space #\tab)))) (if (or die (eq (cxr ii buf) #\lpar)) then nil else ; fid first sep or left paren (do ((iii (1+ ii) (1+ iii))) ((or (not (<& iii max)) (memq (cxr iii buf) '(#\space #\tab #\lpar))) (implode-fun buf ii (1- iii))))))))))) Not unsurprisingly, this code didn't work. I discarded it and rewrote the function in a much simpler fashion: (defun find-func (buf) (let ((i 1) (max (cxr 0 buf)) (result nil)) (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab))) do (setq i (+ i 1))) (loop while (and (not (greaterp i max)) (memq (cxr i buf) '(#\space #\tab))) do (setq i (+ i 1))) (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab #.(getcharn '|(| 1)))) do (setq result (cons (cxr i buf) result)) (setq i (+ i 1))) (if result then (implode (reverse result)) else nil))) The error in the origional definition of find-func caused the -a option to always do nothing. It is surprising that no one caught the fact that the -a option was useless earlier. (However, I am not sure that the source that I was looking at came from your tape, so perhaps it isn't your fault.) In any case, my version works. Bye! Tim Freeman freemant@rpi From bane@gymble Wed Feb 27 12:20:08 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19926; Wed, 27 Feb 85 12:20:08 pst Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA13078; Wed, 27 Feb 85 12:12:21 pst Received: by gymble.ARPA (4.12/4.7) id AA25775; Wed, 27 Feb 85 15:17:32 est Date: Wed, 27 Feb 85 15:17:32 est From: John R. Bane Message-Id: <8502272017.AA25775@gymble.ARPA> To: franz-friends@BERKELEY Subject: symeval 'feature' I've just finished a half-hour "It works interpreted but not compiled" debugging session with a user who was new to compiling Franz, and I have a complaint. The function 'symeval' works misleadingly differently interpreted and compiled. Compiled symeval open-codes into a symbol value-cell reference. This is fine. Interpreted symeval is implemented as a pointer to 'eval'. This loses because something like (symeval '(+ 1 2)) is not an error interpreted, and it should be because it turns into the worst kind of bug when compiled, since it'll return some random pointer from cons node space. This 'feature' was observed in Opus 38.91. From neves@wisc-ai.arpa Thu Feb 28 11:37:06 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04105; Thu, 28 Feb 85 11:37:06 pst Received: from wisc-ai.arpa (wisc-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA08982; Thu, 28 Feb 85 11:29:20 pst Date: Thu, 28 Feb 85 13:34:20 cst From: neves@wisc-ai.arpa (David Neves) Message-Id: <8502281934.AA26546@wisc-ai.arpa> Received: by wisc-ai.arpa; Thu, 28 Feb 85 13:34:20 cst To: franz-friends@BERKELEY Subject: franz to vi & back We have a heavily loaded vax on which we run our Lisp classes. It seems to me that we could lessen the load by not having VI start up anew every time the student does a VIL in Franz. It would be nice to have two processes, one Lisp and the other VI. There would be a function (like VIL) in Franz that would start up a VI process if there wasn't one and if there was a VI process just goto it. When the student is finished editing the file he/she would hit a key that would save out the file and return to Lisp (without killing the VI process). I believe that Gosling Emacs had something like this, only more sophisticated. My questions. Has anyone done this for Franz & VI? Would this help the load average on a VAX? If no one has done it, would it be difficult to do? -Thanks, David From moore.losangel%ibm-sj.csnet@csnet-relay.arpa Thu Feb 28 16:20:09 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08882; Thu, 28 Feb 85 16:20:09 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA05586; Thu, 28 Feb 85 16:12:12 pst Message-Id: <8503010012.AA05586@UCB-VAX.ARPA> Received: from ibm-sj by csnet-relay.csnet id ac15203; 28 Feb 85 19:11 EST Date: Thu, 28 Feb 85 15:34:11 PST From: Jim moore To: info-ibmpc@usc-isi.ARPA, franz-friends@BERKELEY Subject: Can/does Franz exist on PC/IX or VM/IX? I am looking for a high quality LISP to run under PC(VM)/IX. Is Franzlisp the one? Who & How? If not, which? Thanks in advance -- Jim Moore (MOORE.LOSANGEL@IBM) p.s. pls reply directly since I'm not on this list. From johnson@udel-dewey.ARPA Fri Mar 1 04:29:27 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17511; Fri, 1 Mar 85 04:29:27 pst Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA18449; Fri, 1 Mar 85 04:21:31 pst Message-Id: <8503011221.AA18449@UCB-VAX.ARPA> Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009017 ;1 Mar 85 7:18 EST To: David Neves Cc: franz-friends@BERKELEY, johnson@udel-dewey Subject: Re: franz to vi & back In-Reply-To: Your message of Thu, 28 Feb 85 13:34:20 cst. <8502281934.AA26546@wisc-ai.arpa> Date: 01 Mar 85 07:18:11 EST (Fri) From: johnson@udel-dewey Subject: franz to vi & back > We have a heavily loaded vax on which we run our Lisp classes. It > seems to me that we could lessen the load by not having VI start > up anew every time the student does a VIL in Franz. > > It would be nice to have two processes, one Lisp and the other VI. > There would be a function (like VIL) in Franz that would start up > a VI process if there wasn't one and if there was a VI process just > goto it. When the student is finished editing the file he/she would > hit a key that would save out the file and return to Lisp (without > killing the VI process). I believe that Gosling Emacs had something > like this, only more sophisticated. > > My questions. Has anyone done this for Franz & VI? Would this help > the load average on a VAX? If no one has done it, would it be difficult > to do? > I have developed something similar to what you describe, for franz running under bsd4.2 It was moderately difficult at the time, but I was just learning to exploit job control. in this system, the user invokes: (vif foo) to edit the function foo. when he is finished editing, he saves the current buffer by: :w then exits the editor by pressing: ^Z [NOT wq!!] (getting users o use ^Z rather than wq is the biggest difficulty) the function is the read from a temporary file which is created by vif. if the user later wishes to modify the SAME function [often the case] he simply invokes: (vif) - and is returned to the [stopped] editing session EXACTLY where he left it. [ providing some motivation for putting up with ^Z ] The system people around here aren't too adventurous, so the only people who use this system are my friends and myself, so I can't say what effect it has on the load, [but it can only help] one problem: files in /tmp may accumulate, as there is no way to force a user to clean up all editing sessions before exiting lisp. [but that is what /tmp is for!] you might warn your system people to remove all VIF files that are over 2days old, or something like that. note: this package knows about changes made by [cmu]edit, and may be simplified if you are using a system where cmuedit is unavailable. NOTE!!!!!! Neither the University of Delaware nor Apperson H. Johnson relinquishes any rightts toi this software. Please do NOT transfer the software without written permission from both The University of Delaware and Apperson H. Johnson. ********************************************************** setting up the system: Script started on Fri Mar 1 06:49:30 1985 % make jced cc -c jced.c cc -c eroar.c ld -o jcedmod.o -r jced.o eroar.o % lisp Franz Lisp, Opus 38.79 -> [load 'vif] [load vif.l] /usr/lib/lisp/nld -N -x -A /usr/ucb/lisp -T 95800 jcedmod.o -e _jced_ -o /tmp/Li8788.0 -lc t -> [dumplisp newlisp] nil -> (exit) script done on Fri Mar 1 06:51:45 1985 ******************************************************************* "newlisp" is now the lisp to use - you can put it in some directory in youtr student's path ---------- here is vif.l -------------------------------- (setq sccid "#(@)vif.l V1.1 johnson@udel 10/13/84") (eval-when (compile) (msg "vif doen't work compiled!!!\\ "N) (exit)) (declare (localf sccid)) ; ; uses job-control to allow ^Z from 'vi' to return to inside of ; Lisp function ; ; ::vif:: ; ; Usage: (vif []) ; returns: t if function is loaded without errors, nil otherwise ; side-effect: starts vi with temporary file, ; ; does NOT REMOVE FILE UNLESS SUCCESSFUL LOAD HAS BEEN MADE ; AND user has "quit" the editor ; ; - allows ~instantaneous return to file being edited if ; vi has been exited by ^Z (or whatever the susp character is, [see stty.1]) ; ; NOTE: file and vi session may stay "LIVE" even between invocations!!! ; eg: ; ; (def jnk '(lambda (x) "i am jnk")) ; ; (vif jnk) ; --> vi session, followed by :w, and then ^Z ; t ; followed by : ; (vif jnk ) ; or: ; (vif) ; --> INSTANTLY returns to former vi session !! ; ; ; (declare (special *jced_lastf* *jced_lastc* %changes)) (def vif (nlambda (fn) (prog (res tf er ppflag) (cond (fn (cond ((or (not (boundp '*jced_lastf*)) (neq *jced_lastf* (car fn))) (setq ppflag t) (setq *jced_lastf* (car fn)))))) (cond ((boundp '*jced_lastf*) (setq tf (substring (concat '/tmp/VF (concat (syscall 20) (concat '_ *jced_lastf*))) 1)) (cond ((and (boundp '%changes) (memq *jced_lastf* %changes) (or (not (boundp '*jced_lastc*)) (neq *jced_lastc* (memq *jced_lastf* %changes)))) (setq ppflag t))) (cond (ppflag (eval (list 'pp (list 'F tf) *jced_lastf*))))) (t (msg "vif: edit what ??" N) (return nil))) lp (setq res (jced_ tf "")) (setq er nil) (setq ER%all '(lambda (x) (setq er t)) ) (cond ((not (probef tf)) (msg "vif: cannot find " tf) (cond ((eq res 1) (msg " want to return to the editor? {y/n} ") (cond ((eq (read) 'y) (go lp))) (return nil))) (msg " sorry." N) (makunbound '*jced_lastf*) (return t))) (errset (load tf)) (cond ((boundp '%changes) (setq *jced_lastc* (memq *jced_lastf* %changes)))) (cond (er (msg "vif: want to fix " *jced_lastf* "? {y/n} ") (cond ((eq (read) 'y) (go lp))))) (cond ((eq res 0) (makunbound '*jced_lastf*) (syscall 10 tf) (return t)) (t (return nil)))))) ; ; include modules written in C (cfasl 'jcedmod.o '_jced_ 'jced_ "integer-function") ; initialization string for jced (jced_ ":se lisp " "edinit") ; editor to use (jced_ "/usr/ucb/vi" "editor") --------------- ------- jced.c --------------- static char sccid[] = "@(#)jced.c 1.1 johnson@udel 11/2/84"; #include #include #include #include #include #include #include #include #define streq(s1,s2) (0 == strcmp(s1,s2)) #define file_exist(FN) (0 == access(FN,F_OK)) static int chpgrp, pgrp; static union wait status; static struct stat st0,st1; static struct sigvec sv1 = { SIG_IGN, 0, 0}; static struct sigvec sv0; static char curname[128]; static char ed_buf[] = "/usr/ucb/vi"; static char init_buf[] = ""; static char myname_buf[] = "jced_"; static char *editor = ed_buf; static char *edinit = init_buf; static char *myname = myname_buf; /* ::jced_:: * * Usage: (jced_ "filename" "") * * jced_ is a job-control editor * * - starts an editor session with "filename" * (or resumes it if there is a 'living' session with that file) * - returns 1 if the session remains alive, 0 if the session is over * * NOTE: if the SECOND argument is not the EMPTY string, * then the following special calls may apply: * * (jced_ "/usr/ucb/vi" "editor") * - causes jced to use /usr/ucb/vi as the editor (this is the default) * * : (jced_ ":se bla" "edinit") * - causes jced cause the editor to pretend that the user typed ":se bla" * every time the editor is invoked (the default is "") * * : (jced_ "jced_" "myname") * - causes jced to use the name "jced_" in its prompts and messages * (this is the default) * */ int jced_(fname,cmd) char *fname, *cmd; { union wait status; char resp[2]; if (*cmd) { if (streq(cmd,"editor")) newstring(&editor,fname); else if (streq(cmd,"edinit")) newstring(&edinit,fname); else if (streq(cmd,"myname")) newstring(&myname,fname); else fprintf(stderr,"%s: %s is an unknown command",myname,cmd); return(0); } if (*curname) { if (*fname && !streq(fname,curname)) { if (file_exist(curname)) eroar(unlink(curname),0,"unlink %",curname); kvil_(); strcpy(curname,fname); begin_vi(); resume_vi(); } else { /* * if file has been modified elsewhere, * new editing session is needed */ if (file_exist(curname)) { eroar(stat(curname,&st1),0,"stat"); if(st0.st_mtime != st1.st_mtime) { kvil_(); strcpy(curname,fname); begin_vi(); } } resume_vi(); } } else if (*fname) { strcpy(curname,fname); begin_vi(); resume_vi(); } else return(0); return((*curname) ? 1 : 0); } /* to be called when a function is modified elsewhwre */ kvil_() { eroar(killpg(chpgrp,SIGKILL),0,"killpg %d",chpgrp); wait3(&status,WUNTRACED,0); curname[0] = '\0'; } static begin_vi() { if (chpgrp = fork()) { pgrp = getpgrp(0); eroar(setpgrp(chpgrp,chpgrp),0,"setpgrp"); } else { fakeinput(edinit); execlp(editor,editor,curname,0); fprintf(stderr,"%s: exec of %s failed\n",myname,editor); } } static resume_vi() { char dum[2]; for (;;) { eroar(sigvec(SIGTTOU,&sv1,&sv0),0,"sigvec -IGN TTOU"); eroar(ioctl(0,TIOCSPGRP,&chpgrp),0,"SPGRP chpgrp"); if (file_exist(curname)) eroar(stat(curname,&st1),0,"stat"); else st1.st_mtime = 0; killpg(chpgrp,SIGCONT); wait3(&status,WUNTRACED,0); eroar(ioctl(0,TIOCSPGRP,&pgrp),0,"ioctl SPGRP pid"); eroar(sigvec(SIGTTOU,&sv0,0),0,"sigvec -DFL TTOU"); if (file_exist(curname)) eroar(stat(curname,&st0),0,"stat"); else st0.st_mtime = st1.st_mtime; if(!status.w_status) { curname[0] = '\0'; break; } if(st0.st_mtime == st1.st_mtime) { fprintf(stderr,"%s: %s was not modified, try again? {y/n} ", myname, curname); if (1 == scanf("%1s",dum) && dum[0] == 'n') break; } else break; } } static fakeinput(s) char *s; { int i; /* pretend s was typed at the terminal */ for(i=0;s[i]; ++i) ioctl(0,TIOCSTI,s+i); } static newstring(sptr,s) char **sptr, *s; { char *s2, *malloc(); if (NULL == (s2 = malloc(1 + strlen(s)))) { fprintf(stderr,"%s: malloc failed\n",myname); } else { strcpy(s2,s); *sptr = s2; } } --------------------------- eroar.c -------------------- static char sccid[] = "@(#)eroar.c 1.0 johnson@udel 10/13/84"; /* ::eroar.c:: * * error reporter-handler for faulty system function calls * * Usage: eroar( , , , * , , ...... ); * * behavior: * if the system call is successful, returns (1) immediately * else * prints out the error message (from the printf pattern) * and prints an error explanation * if exit-code is non-zero, exits with that code * else returns (0) */ #include #include #define ERR_BUFMAX 128 extern int sys_nerr, errno; extern char *sys_errlist[]; eroar(expr,code,s,p1,p2,p3,p4,p5,p6,p7,p8,p9) int expr,code; char *s; { static char errbuf[ERR_BUFMAX]; if (-1 != expr) return(1); fprintf(stderr,s,p1,p2,p3,p4,p5,p6,p7,p8,p9); fprintf(stderr,": %s\n", (0 < errno && errno < sys_nerr) ? sys_errlist[errno] : "UNKNOWN ERROR"); if (code) exit(code); return(0); } ----------------- makefile ----------------------- jced : jcedmod.o jcedmod.o : jced.o eroar.o ld -o jcedmod.o -r jced.o eroar.o ------------------------------------------------------- ... (share a little joke with the world) ... net: johnson@udel-ee usmail: Apperson H. Johnson 618 Lehigh Rd. apt S11 Newark, De. 19711 -------------------------------------------------------- From jshaver@apg-3 Fri Mar 1 13:37:57 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22358; Fri, 1 Mar 85 13:21:35 pst Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA28355; Fri, 1 Mar 85 13:13:39 pst Message-Id: <8503012113.AA28355@UCB-VAX.ARPA> Date: 1 Mar 1985 16:15:48 EST (Friday) From: John Shaver STEEP-TM-AC 879-7602 Subject: Vax availability To: franz-friends@BERKELEY Cc: jshaver@apg-3 Is Franz Lisp available for the VAX? Please respond directly to me, as I am not on the list. Please add me to the list. Thank you. This is an Otrona Attache 1200 bps John From jshaver@apg-3 Mon Mar 4 06:10:51 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA11236; Mon, 4 Mar 85 06:10:51 pst Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA03832; Mon, 4 Mar 85 06:05:00 pst Message-Id: <8503041405.AA03832@UCB-VAX.ARPA> Date: 4 Mar 1985 9:09:27 EST (Monday) From: John Shaver STEEP-TM-AC 879-7602 Subject: Returned mail: User unknown To: franz-friends@BERKELEY Cc: jshaver@apg-3 ----BEGINNING OF FORWARDED MESSAGES---- Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA28859; Fri, 1 Mar 85 13:34:56 pst Received: by ucbkim.ARPA (4.24/4.27) id AA00121; Fri, 1 Mar 85 13:37:57 pst Date: 1 Mar 1985 16:15:48 EST (Friday) From: MAILER-DAEMON%ucbkim@Berkeley (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8503012137.AA00121@ucbkim.ARPA> To: ----- Transcript of session follows ----- >>> RCPT To: <<< 550 ... User unknown 550 franz-friends-3@ucbmike... User unknown >>> RCPT To: <<< 550 ... User unknown 550 franz-friends-score@ucbmike... User unknown ----- Unsent message follows ----- Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22358; Fri, 1 Mar 85 13:21:35 pst Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA28355; Fri, 1 Mar 85 13:13:39 pst Message-Id: <8503012113.AA28355@UCB-VAX.ARPA> Date: 1 Mar 1985 16:15:48 EST (Friday) From: John Shaver STEEP-TM-AC 879-7602 Subject: Vax availability To: franz-friends@BERKELEY Cc: jshaver@apg-3 Is Franz Lisp available for the VAX? Please respond directly to me, as I am not on the list. Please add me to the list. Thank you. This is an Otrona Attache 1200 bps John ----END OF FORWARDED MESSAGES---- Is it something I'm doing? From jshaver@apg-3 Mon Mar 4 06:16:15 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA11275; Mon, 4 Mar 85 06:16:15 pst Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA03880; Mon, 4 Mar 85 06:10:25 pst Message-Id: <8503041410.AA03880@UCB-VAX.ARPA> Date: 4 Mar 1985 9:10:31 EST (Monday) From: John Shaver STEEP-TM-AC 879-7602 Subject: mail request failure To: franz-friends@BERKELEY Cc: jshaver@apg-3 ----BEGINNING OF FORWARDED MESSAGES---- Received: from CMU-CS-A.ARPA (cmu-cs-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA29648; Fri, 1 Mar 85 14:05:23 pst Message-Id: <8503012205.AA29648@UCB-VAX.ARPA> Date: 1 Mar 85 17:8:8 EST From: Mailer To: <@BERKELEY:jshaver@apg-3> Reply-To: Gripe Subject: mail request failure ----- Transcript of session follows ----- Mail being sent from disk area [N900AR0M] *NMail 1 Mar 85 17:06:02 EST;@UCB-VAX.ARPA:jshaver@apg-3;927920.QED[n900ar0m];mark.stevenson@cmua 1 Mar 85 17:8:8 EST ?%No such person as 'mark.stevenson' at CMU-CS-A. ----- Unsent message follows ----- Received: from UCB-VAX.ARPA by CMU-CS-A.ARPA; 1 Mar 85 17:05:57 EST Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA28701; Fri, 1 Mar 85 13:30:28 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22358; Fri, 1 Mar 85 13:21:35 pst Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA28355; Fri, 1 Mar 85 13:13:39 pst Message-Id: <8503012113.AA28355@UCB-VAX.ARPA> Date: 1 Mar 1985 16:15:48 EST (Friday) From: John Shaver STEEP-TM-AC 879-7602 Subject: Vax availability To: franz-friends@Berkeley Cc: jshaver@apg-3 Is Franz Lisp available for the VAX? Please respond directly to me, as I am not on the list. Please add me to the list. Thank you. This is an Otrona Attache 1200 bps John ----END OF FORWARDED MESSAGES---- Try a return address of RREINER@Simtel20. They forward everything to me. From fsbrn@BRL-VOC.ARPA Tue Mar 5 08:17:28 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00161; Tue, 5 Mar 85 08:17:28 pst Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA09879; Tue, 5 Mar 85 08:11:28 pst Message-Id: <8503051611.AA09879@UCB-VAX.ARPA> Date: Tue, 5 Mar 85 11:13:21 EST From: "Ferd Brundick (VLD/LTTB)" To: Franz-Friends@BERKELEY Cc: Meself Subject: Trace bug Haah, We recently installed some revisions to our 4.2 BSD system, and the Joseph Lister package is apparently broken. Since our system administrators don't use Franz, I poked around in the file trace.l. An error run is shown below: -> (getsyntax '\;) vsplicing-macro -> (trace intersect) [autoload /usr/lib/lisp/trace] [load /usr/lib/lisp/trace.l] [load /usr/lib/lisp/charmac.l] Error: Unbound Variable: ;; <1>: (getsyntax '\;) vcharacter The trace code that is executing is: (eval-when (eval) (setq old-read-table-trace readtable) (setq readtable (makereadtable t)) (setq old-uctolc-value (status uctolc)) (sstatus uctolc nil) ; turn off case conversion (load 'charmac) (setsyntax '\; 'macro 'zapline) ) What I think is happening is that the readtable is being clobbered by the (makereadtable t) line. The file charmac.l starts off with a comment line, but the definition of ';' has changed in the readtable. I copied trace.l and reversed the last 2 lines so ';' is macro'd to zapline BEFORE charmac.l is loaded. I can then load trace.l and (trace) functions with no trouble. My question is: Why did I have to reverse those lines ?? (trace) used to work fine. Is there a problem with (makereadtable) that I need to fix ?? We are running Opus 38.79. dsw, fferd Fred S. Brundick USABRL, APG, MD. "Me ears are on the wrong side of me 'ead." From fsbrn@BRL-VOC.ARPA Tue Mar 5 14:55:27 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00189; Tue, 5 Mar 85 14:55:27 pst Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA16643; Tue, 5 Mar 85 13:15:11 pst Message-Id: <8503052115.AA16643@UCB-VAX.ARPA> Date: Tue, 5 Mar 85 16:14:14 EST From: "Ferd Brundick (VLD/LTTB)" To: Franz-Friends@BERKELEY Cc: Ferd Brundick , kanderso@bbn-vax.ARPA Subject: Re: Trace bug Haah, >>Why aren't you loading the compiled version of trace? >>Would that help? That was the what the person who stumbled onto the bug said. (I don't use the trace package myself because everything works the first time :-). I don't see how that would matter because compiled code is just as wrong; it just bombs faster. Besides, my slightly obsolete Franz manual says "the trace package ... usually in the file /usr/lib/lisp/trace.l". I'm just wondering why the file doesn't work any more when it used to. I'd rather fix the problem permanently instead of patching around it. dsw, fferd Fred S. Brundick USABRL, APG, MD. "I think I pulled a muscle in me ear." From hamscher@MIT-HTVAX.ARPA Tue Mar 19 16:50:09 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22357; Tue, 19 Mar 85 16:50:09 pst Received: from MIT-HTVAX.ARPA (mit-htvax.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA05308; Tue, 19 Mar 85 11:49:40 pst Received: by MIT-HTVAX.ARPA (4.12/4.7) id AA21434; Tue, 19 Mar 85 14:50:20 est Date: Tue, 19 Mar 85 14:50:20 est From: Walter Hamscher Message-Id: <8503191950.AA21434@MIT-HTVAX.ARPA> To: Franz-Friends@BERKELEY Subject: Franz -> Common Lisp ? Reply-to: hamscher@mit-htvax.arpa Is there a common lisp that runs on 4.2 BSD? Seems to me this is a vacuum that many folks must be trying to fill. I am wondering: (1) Who's working on one? <> (2) Is there a common lisp compatability package for franz? <> (3) Are folks at UCB thinking of spinning off a common lisp from the existing franz implementation? <> All answers and pointers appreciated. Thanks, Walter Hamscher From shebs@utah-cs Wed Mar 20 17:27:57 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08685; Wed, 20 Mar 85 17:27:57 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA11992; Wed, 20 Mar 85 16:51:20 pst Received: by utah-cs.ARPA (4.42/4.40.2) id AA01825; Wed, 20 Mar 85 17:48:26 MST Date: Wed, 20 Mar 85 17:48:26 MST From: shebs@utah-cs (Stanley Shebs) Message-Id: <8503210048.AA01825@utah-cs.ARPA> To: Franz-Friends@BERKELEY, hamscher@mit-htvax.arpa Subject: Re: Franz -> Common Lisp ? We have several versions of compatibility stuff for PSL (and it would work under Franz without much change). We're trying to get CL while retaining the speed of PSL, so we haven't yet embarked on a full standalone CL... stan shebs From ingrid@UCLA-LOCUS.ARPA Thu Mar 21 11:05:39 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA18463; Thu, 21 Mar 85 11:05:39 pst Received: from ucla-locus.arpa (ucla-locus.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA12504; Thu, 21 Mar 85 10:37:45 pst Date: Thu, 21 Mar 85 10:35:28 PST From: Ingrid Zukerman To: franz-friends@BERKELEY Subject: setq command changes code Message-Id: <480278128-16289-ingrid@UCLA-LOCUS.ARPA> I have the following problems: 1. After performing the command (setq x (list ... )), I noticed that the code in the function that initializes x was also changed to the new value. After consulting with my guru, he pointed out that this might be due to a sharing pattern I am not aware of, or to the way in which assignments are performed (e.g., by passing a pointer). I wasn't able to find this information, so my question is were I could find it in order to avoid such occurrences in the future. Of course, if somebody up there is terribly curious and wants to look at a transcript of the session, I'll be very appreciative. 2. The most updated copy we have of Franz is Opus 38.5. I hear that it is now Opus 38.91. What should I do in order to get an updated copy? Please don't advise me to contact the person in charge, because this person (who no longer wishes to be in charge) told me to contact you. Thanks very much. --Ingrid From franz!schlafly Mon Mar 25 18:03:33 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20019; Mon, 25 Mar 85 18:03:33 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA21825; Mon, 25 Mar 85 17:57:20 pst Received: by ucbkim.ARPA (4.24/4.27) id AA20010; Mon, 25 Mar 85 18:03:19 pst Received: by franz.uucp (1.2/3.14) id AA00961; Mon, 25 Mar 85 17:36:52 pst Date: Mon, 25 Mar 85 17:36:52 pst From: franz!schlafly (Roger Schlafly) Message-Id: <8503260136.AA00961@franz.uucp> To: franz-friends@BERKELEY Subject: programs written in Franz Lisp I am compiling a list of expert systems and expert system building tools which are written in Franz Lisp. I would appreciate it if people would send me: (1) The name of each such program. (2) A brief description of what it does. (3) Whether it is available to the public. (4) An electronic address for obtaining more information. I will then make this list available to anyone who requests it. Roger Schlafly ucbvax!franz!schlafly From franz!schlafly Mon Mar 25 20:02:47 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA21162; Mon, 25 Mar 85 20:02:47 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA23786; Mon, 25 Mar 85 19:56:37 pst Received: by ucbkim.ARPA (4.24/4.27) id AA21150; Mon, 25 Mar 85 20:02:36 pst Received: by franz.uucp (1.2/3.14) id AA01276; Mon, 25 Mar 85 19:37:31 pst Date: Mon, 25 Mar 85 19:37:31 pst From: franz!schlafly (Roger Schlafly) Message-Id: <8503260337.AA01276@franz.uucp> To: franz-friends@BERKELEY Subject: programs written in Franz Lisp I am compiling a list of expert systems and expert system building tools which are written in Franz Lisp. I would appreciate it if people would send me: (1) The name of each such program. (2) A brief description of what it does. (3) Whether it is available to the public. (4) An electronic address for obtaining more information. I will then make this list available to anyone who requests it. Roger Schlafly ucbvax!franz!schlafly From carter%ubc.csnet@csnet-relay.arpa Tue Mar 26 12:52:24 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00886; Tue, 26 Mar 85 12:52:24 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA11893; Tue, 26 Mar 85 12:46:01 pst Received: from ubc by csnet-relay.csnet id a017378; 26 Mar 85 15:03 EST Received: from ubc-vision.UUCP by ubc.csnet id AA04906; Tue, 26 Mar 85 12:01:03 pst Date: Tue, 26 Mar 85 12:00:43 pst From: Alan Carter Message-Id: <8503262000.AA09422@ubc-vision.UUCP> Received: by ubc-vision.UUCP id AA09422; Tue, 26 Mar 85 12:00:43 pst To: franz-friends@BERKELEY Subject: Lisp interface to C functions Does anyone know if there is a problem with calling malloc and free from C functions which are called by Franz ? Alan Carter carter@ubc-vision.UUCP From mcgeer Tue Mar 26 16:06:57 1985 Received: by ucbkim.ARPA (4.24/4.27) id AA03620; Tue, 26 Mar 85 16:06:57 pst Date: Tue, 26 Mar 85 16:06:57 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503270006.AA03620@ucbkim.ARPA> To: prolog@ernie, franz-friends Subject: Lisp is faster than Prolog? Cc: A number of articles in recent IEEE Spectra have discussed Silicon Compilation in Prolog, and concluded with a statement to the effect: for performance reasons, we will go to Lisp for a production version. Is Lisp really faster than Prolog? I used to think so. Some time ago, I wrote a Prolog interpreter in Lisp: after several versions, I gave up, because I couldn't make my Prolog fast. Its best speed was 100 LIPS through the append loop on a 780, or about 7% of the speed of C-Prolog (1500 LIPS, according to the literature. Then it occured to me that I could not expect my Prolog to run faster than an equivalent function coded in Lisp. I coded the function, and the result was the following: (def my-append (lambda (x y) (cond (x (cons (car x) (my-append (cdr x) y))) (t y)))) it can be seen that the time of the computation is invariant with respect to the second argument. Hence, for all the tests to be mentioned, the second argument is '(1 2 3 4 5). I ran the program on the lists consisting of the first 100, 250, and 300 integers. The results were the following: list length ticks (60/sec) LIPS equivalent 100 14 429 250 29 517 300 34 529 Or about one-third the published speed of of the same function in CProlog on a 780. I then wondered how the native Franz append would do. This function is compiled, and is optimized for tail recursion, so the experiment is not really fair to CProlog. In any case: list length ticks LIPS equivalent 100 3 2000 250 8 1875 300 10 1800 I don't know what this proves, but I know what it doesn't prove. The Lisp used, by the way, was Franz version 38.96 on a Vax 11/780 at the University of California at Berkeley. Despite numerous queries to Edinburgh, we still don't have a version of C-Prolog for comparative measurement here, so I can't personally vouch for the 1500 LIPS claim. Rick. From chris@maryland Tue Mar 26 16:18:52 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03876; Tue, 26 Mar 85 16:18:52 pst Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA16580; Tue, 26 Mar 85 16:12:34 pst Received: by maryland.ARPA (4.12/4.7) id AA23203; Tue, 26 Mar 85 19:17:28 est Date: Tue, 26 Mar 85 19:17:28 est From: Chris Torek Message-Id: <8503270017.AA23203@maryland.ARPA> To: carter%ubc.csnet@csnet-relay.ARPA Subject: Re: Lisp interface to C functions Cc: franz-friends@BERKELEY I believe that there were. In U of M Franz, we stuck in a version of malloc and free that uses the Lisp allocator to get unGCable memory, and a host of problems with the window library went away ... (the window library uses malloc & free quite, er, freely :-) ). Chris From narain@rand-unix Tue Mar 26 18:17:38 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA06939; Tue, 26 Mar 85 18:17:38 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA18369; Tue, 26 Mar 85 17:39:36 pst Received: by rand-unix.ARPA; Tue, 26 Mar 85 17:33:48 pst From: Sanjai Narain Message-Id: <8503270133.AA16864@rand-unix.ARPA> Date: 26 Mar 85 17:33:41 PST (Tue) To: Rick McGeer Cc: prolog@ernie, franz-friends@ucbkim, narain@rand-unix Subject: Re: Lisp is faster than Prolog? In-Reply-To: Your message of Tue, 26 Mar 85 16:06:57 pst. <8503270006.AA03620@ucbkim.ARPA> Your first comparison of Prolog and Lisp is not very meaningful. You are comparing a Prolog implemented in Lisp with a Lisp implemented in C. Perhaps you could try to compare Lisp in Lisp with Prolog in Lisp. In a certain sense, your comparison of Franzlisp and C-Prolog infact indicates the superiority of C-Prolog. C-Prolog can be used to do append and all other functional programming at almost the speed of FranzLisp. However, in C-Prolog, you can do also do deduction, searching, pattern matching and a lot of other AI-stuff at the same speed. To do these in Franzlisp you must write Lisp functions and suffer the loss in speed associated with simulating functionality in a high-level language. -- Sanjai From mcgeer Tue Mar 26 18:30:58 1985 Received: by ucbkim.ARPA (4.24/4.27) id AA07153; Tue, 26 Mar 85 18:30:58 pst Date: Tue, 26 Mar 85 18:30:58 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503270230.AA07153@ucbkim.ARPA> To: narain@rand-unix Subject: Re: Lisp is faster than Prolog? Cc: narain@rand-unix, franz-friends, prolog@ernie In-Reply-To: Your message of 26 Mar 85 17:33:41 PST (Tue) You misunderstood my message. Prolog-in-Lisp really isn't under examination: the only reason I brought it up was that it provided the original motivation for the experiment (I wanted to determine a limit on the speed I could expect out of my Prolog, reasoning that it could not possibly be faster than native-coded Lisp.) The rest of your letter is essentially correct: the figures imply that CProlog is at least as fast as Franz, since the relevant test is interpreted code in each language (i.e., the first set of figures). However, this should not imply that I believe that Prolog is a "better" language than Lisp (I don't want to get into *that* debate), or imply that Lisp has no advantages over Prolog. Lisp may have real advantages over Prolog, but there is no reason to believe that speed is one of them. Rick. From hilfingr@ucbrenoir Wed Mar 27 01:06:00 1985 Received: from ucbrenoir.ARPA by ucbkim.ARPA (4.24/4.27) id AA11390; Wed, 27 Mar 85 01:06:00 pst Received: by ucbrenoir.ARPA (4.24/4.42) id AA03594; Wed, 27 Mar 85 01:07:16 pst Date: Wed, 27 Mar 85 01:07:16 pst From: hilfingr@ucbrenoir (Paul Hilfinger) Message-Id: <8503270907.AA03594@ucbrenoir.ARPA> To: mcgeer@ucbkim, narain@rand-unix Subject: Re: Lisp is faster than Prolog? A personal plea Cc: prolog@ernie, franz-friends@ucbkim In-Reply-To: Your message of 26 Mar 85 17:33:41PST Please, please, please stop trying to compare the performance of Lisp and Prolog by considering micro-benchmarks! Even in languages that are essentially "the same" (from my perspective as a semanticist/language designer or from the perspective of a Prolog programmer, FORTRAN, Pascal, Modula 2, and Ada are all the same); such benchmarks are imperfect guides. When comparing Lisp and Prolog, where the programs one might write to do a particular problem might be radically different in strategy, anything that compares the performance of tiny programs conveys almost no useful information. Please, please, please, PLEASE don't try to compare Prolog with Lisp (etc.) using LIPS as a part of the measure! In comparing Prolog implementations, I suppose LIPS might be of some interest, but when comparing Lisp with Prolog, they don't help at all. The reason is simple: if Lisp is not suited for doing logical inferences (in the Prolog sense) quickly, then the good Lisp programmer simply does not formulate his solution using logical inferences. (Patient: Doctor! Doctor! It hurts when I do this. Doctor: Well, then don't do that.) It's like saying that my APL implementation, which uses lazy evaluation and a bit of cleverness to compute +/ ,((iota n) o.= iota n) x A +.x B (the trace of the matrix product of nxn matrices A and B, I think) in time O(n^2) instead of O(n^3), is "faster" than my FORTRAN implementation, which requires time O(n^3) to do a direct transcription of this algorithm (actually forming the full matrix product). I think it wrong to say "To do [deduction, searching, pattern matching and other AI-stuff] in Franzlisp you must write Lisp functions and suffer the loss in speed associated with simulating functionality in a high-level language." because one DOESN'T use simulation if one wants speed, but instead goes after an entirely different kind of solution (I won't argue that this solution is "just as easy" as the Prolog solution; there are certainly many instances in which Prolog solutions are simpler, and I haven't the foggiest notion what the story is for large systems.) * * * Finally, a question. I was struck by Sanjai Narain's comment: "However, in C-Prolog, you can do also do deduction, searching, pattern matching and a lot of other AI-stuff at the same speed." I notice that the Prolog digest is full of interesting puzzles whose solution involves search. But are these representative? I think pattern matching is certainly a big part of any Prolog program, but do deduction and searching really form a big part of actual Prolog applications in practice? I recall an article by Drew McDermott called the "The Prolog Phenonmenon" that appeared (I think) in SIGArt at some point, maybe July '82. He asked why it was that Prolog had not died out, as had PLANNER, which also purported to support searching et al. He said some things on what he liked and disliked about Prolog, and then made the following comment (emphasis mine): "The Europeans went in a different direction [from the Americans in reaction to the problems of PLANNER-like languages]. What they liked best about logic was its variable-binding machinery. Their attitude towards backtracking has been simply that it is a programmer's duty to remember that his program will be executed backward as well as forward, that his programs must correct bad guesses as well as exploit good ones. If the backwards execution blows up, he must debug his program, not rewrite the interpreter [the American approach], just as with more prosaic kinds of infinite loops. Once this burden was shifted away from the language implementer and onto the programmer, the logical [!] next step was to freeze the interpreter design and make it as efficient as possible. THE RESULT IS A PROGRAMMING LANGUAGE, NOT A PROBLEM SOLVER OR THEOREM PROVER; it doesn't compete with NOAH, but with Lisp. And it's my impression that it competes pretty well. "The effect is to reverse the usual images of the American and European computer scientists. In this case, the Americans have pursued impractical theoretical studies, while the Europeans have bummed the hell out of a hack." (By "backward execution," he is referring to backtracking, I believe). To put this another way, one doesn't use Prolog's backtracking to do AI-style (i.e., very large) search, but rather to do very local and carefully- controlled "search," in the sense of "search this list (tree, ....) for an element equal to this one" or "try all permutations of this tiny set for one that satisfies P." Likewise, one doesn't use it to do what an AI investigator would call "deduction." One CAN convince the Prolog machinery to do more general AI-style searching efficiently, but only at the expense of vastly obscuring the original clear, simple, declarative form of the program. Not being a real Prolog hacker (yet) I don't really know how accurate this view is, and would appreciate some reaction (preferably semi-quantitative). From franz!jkf Wed Mar 27 08:03:25 1985 Received: by ucbkim.ARPA (4.24/4.27) id AA13270; Wed, 27 Mar 85 08:03:25 pst Received: by franz.uucp (1.2/3.14) id AA06162; Wed, 27 Mar 85 07:59:36 pst Date: Wed, 27 Mar 85 07:59:36 pst From: franz!jkf (John Foderaro) Message-Id: <8503271559.AA06162@franz.uucp> To: hilfingr@ucbrenoir.BERKELEY, narain@rand-unix.ARPA, mcgeer@ucbkim.BERKELEY Subject: Re: Lisp is faster than Prolog? A personal plea Cc: franz-friends@ucbkim.BERKELEY, prolog@ernie In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst While I find the discussion of Prolog vrs Lisp interesting, please do don't include franz-friends in on the discussion. When the mailing list has strayed off the topic of Franz Lisp in the past, I've gotten inundated with complaints. Thanks. John Foderaro From mcgeer Wed Mar 27 10:22:15 1985 Received: by ucbkim.ARPA (4.24/4.27) id AA15354; Wed, 27 Mar 85 10:22:15 pst Date: Wed, 27 Mar 85 10:22:15 pst From: Rick McGeer (on an aaa-60-s) Message-Id: <8503271822.AA15354@ucbkim.ARPA> To: hilfingr@ucbrenoir, narain@rand-unix Subject: Re: Lisp is faster than Prolog? A personal plea Cc: franz-friends, prolog@ernie In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst Good point, Paul, but I think you're missing something. First you plead with us not to use micro-benchmarks, then you point out (correctly) that the strategy that one would use to write a program in Lisp instead of Prolog can often differ. I would think that the implication from the latter observation is that large programs are fundamentally incomparable, and I think that that is probably correct. So if you deny us micro-benchmarks, then we can not measure the relative performance of these languages at all (or, more precisely, the standard implementations of these languages on the 11/780). Hence we might as well accept the statements "Prolog is faster than Lisp" or "Lisp is faster than Prolog" or "Lisp is faster than assembler" as essentially meaningless statements, since we can't quantify any of them. Let me sputter out making one final point. LIPS is not all that bad a measure. Perhaps if we called it "cycles through the append loop" or "function calls per second" (essentially identical statements) I think most people would agree that this is a fair measure of the performance of any Lisp. After all, Lisp does nothing other than call functions and manipulate lists. I'm certainly not going to take issue with the rest of your letter, which is really more directed at Sanjai's claims than mine, and walks rather closer to debates on programming style than any sane man should dare to go. I remain, sir, Y'r obedient servant, Rick McGeer. From jeffr@sri-spam Fri Mar 29 16:22:50 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09984; Fri, 29 Mar 85 16:22:50 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA04718; Fri, 29 Mar 85 16:16:10 pst Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16) id AA29100; Fri, 29 Mar 85 16:22:32 pst Message-Id: <8503300022.AA29100@sri-spam.ARPA> Date: 29 Mar 85 16:22:30 PST (Fri) To: franz-friends@BERKELEY Subject: Problems Forking Around From: jeffr@sri-spam I am having problems getting child processes forked from Franz to exit cleanly. If I execute a simple forking function, such as (defun fork_test () (prog (pid) (cond ((setq pid (fork)) (return pid))) (exit) ] from the Franz interpreter, a zombie process is created which doesn't exit until I exit the interpreter. The same result holds when fork_test is called from a compiled Franz daemon which is not associated with a tty. It's Friday and I'm out of ideas; any you have, even if only speculation, would be greatly appreciated. - Jeff Rininger SRI International From larus@ucbdali Fri Mar 29 16:50:22 1985 Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27) id AA10643; Fri, 29 Mar 85 16:50:22 pst Received: by ucbdali.ARPA (4.24/4.42) id AA04603; Fri, 29 Mar 85 16:50:11 pst Message-Id: <8503300050.AA04603@ucbdali.ARPA> To: jeffr@sri-spam.ARPA Cc: franz-friends@ucbdali Subject: Re: Problems Forking Around In-Reply-To: Your message of 29 Mar 85 16:22:30 PST (Fri). <8503300022.AA29100@sri-spam.ARPA> Date: 29 Mar 85 16:50:02 PST (Fri) From: larus@ucbdali This is a not-very-well-known bug/feature of Franz/Unix. Try adding a (wait) call in the main routine and the zombies will go away. /Jim From weeks@ucbruby.CC Fri Mar 29 18:23:00 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA11898; Fri, 29 Mar 85 18:23:00 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA07034; Fri, 29 Mar 85 18:16:19 pst Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1) id AA11566; Fri, 29 Mar 85 18:22:39 pst Received: by ucbruby.CC.Berkeley.ARPA (4.19/4.34.1) id AA10320; Fri, 29 Mar 85 18:21:53 pst Date: Fri, 29 Mar 85 18:21:53 pst From: weeks@ucbruby.CC (Harry Weeks) Message-Id: <8503300221.AA10320@ucbruby.CC.Berkeley.ARPA> To: jeffr@sri-spam Subject: Re: Problems Forking Around Cc: franz-friends@BERKELEY It is a characteristic of Unix that processes do not really die until they are waited for. Your `zombie' process will not die until you (wait) for it. The (wait) function returns the dotted pair (pid . status). Thus the following examples will spawn children that immediately die. --Harry In simplest terms: (def beget (lambda nil (cond ((fork) (wait)) (t (exit 0))))) In more realistic terms: (def beget (lambda nil (prog (child) (setq child (fork)) (cond ((null child) ; child branch: (fork) evaluated to nil (exit 0)) ((> child 0) ; parent branch: (fork) evaluated to pid (princ "Begot ") (princ child) (princ ".") (terpri) (return (beget:wait child))) ((< child 0) ; error branch (princ "Birth pain.") (terpri) (return child)) (t ; impossible branch (princ "Impossible pain.") (terpri) (return -1)))))) (def beget:wait (lambda (child) (prog (pvec) (setq pvec (wait)) (cond ((= (car pvec) child) ; child we are waiting for died (return (cdr pvec))) ((< (car pvec) 0) ; error (princ "Wait error.") (terpri) (return (car pvec))) (t ; another child died, keep waiting for ours (return (beget:wait child))))))) From carter%ubc.csnet@csnet-relay.arpa Tue Apr 2 16:48:37 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15047; Tue, 2 Apr 85 16:48:37 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA26876; Tue, 2 Apr 85 16:48:19 pst Received: from ubc by csnet-relay.csnet id a008974; 2 Apr 85 19:35 EST Received: from ubc-vision.UUCP by ubc.csnet id AA06552; Tue, 2 Apr 85 16:28:06 pst Date: Tue, 2 Apr 85 16:27:59 pst From: Alan Carter Message-Id: <8504030027.AA14795@ubc-vision.UUCP> Received: by ubc-vision.UUCP id AA14795; Tue, 2 Apr 85 16:27:59 pst To: franz-friends@BERKELEY Subject: C interface Does anyone know if it is OK to call malloc and free from C functions called by lisp? -- Alan Carter carter@ubc-vision.UUCP From dennis%boulder.csnet@csnet-relay.arpa Wed Apr 3 19:05:09 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09023; Wed, 3 Apr 85 19:05:09 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA24595; Wed, 3 Apr 85 19:04:50 pst Message-Id: <8504040304.AA24595@UCB-VAX.ARPA> Received: from boulder by csnet-relay.csnet id af16243; 3 Apr 85 21:51 EST Received: by boulder.UCBOULDER (4.30/4.7) id AA10745; Wed, 3 Apr 85 09:58:09 mst Date: Wed, 3 Apr 85 09:58:09 mst From: Dennis Heimbigner To: carter%ubc.csnet@csnet-relay.arpa, franz-friends@BERKELEY Subject: Re: C interface If I recall correctly, the pre-4.2 malloc did not appear to work with franz because it assumed that it had control of all of free memory. The malloc for 4.2 uses a buddy system and should not care if, for example, franz has pre-empted pieces of virtual memory for its own use. On the other side, franz only looks at the memory it gets from sbrk, so it doesn't care about malloc'd areas of virtual memory. .lp More to the point, I have been using malloc inside cfasl'd code and have not yet seen a problem. Dennis Heimbigner dennis.boulder@csnet-relay. From @seismo.ARPA:prlb2!vauclair@seismo.ARPA Fri Apr 5 01:13:08 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA27833; Fri, 5 Apr 85 01:13:08 pst Received: from seismo.ARPA (css-ring-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA25779; Fri, 5 Apr 85 01:12:50 pst Return-Path: Received: from prlb2.UUCP by seismo.ARPA with UUCP; Fri, 5 Apr 85 04:12:31 EST Received: by prlb2.UUCP (4.12/4.7) id AA01128; Fri, 5 Apr 85 10:36:51 -0200 Date: Fri, 5 Apr 85 10:36:51 -0200 From: prlb2!vauclair@seismo.ARPA (Marc Vauclair) Message-Id: <8504050836.AA01128@prlb2.UUCP> To: franz-friends@BERKELEY Subject: Profiling options in Franz Lisp. Opus 38.91. UoM Var. 3.5. Does anyone know how to set up profiling in Franz Lisp ? We have Franz Lisp of University of Maryland : Opus 38.91, UoM Variation 3.5. I have already made the following modifications : 1) as stated in the makefile : ../franz/vax/Makefile I have removed the # in : ------------------------------------------------------------------------------ ProfFlag = # -XP ProfFlag2 = # -DPROF ------------------------------------------------------------------------------ giving : ------------------------------------------------------------------------------ ProfFlag = -XP ProfFlag2 = -DPROF ------------------------------------------------------------------------------ 2) I've changed in ../franz/vax/Makefile the line : ------------------------------------------------------------------------------ /lib/cpp $< -I../h |\ ------------------------------------------------------------------------------ to : ------------------------------------------------------------------------------ /lib/cpp ${ProfFlag2} $< -I../h |\ ------------------------------------------------------------------------------ 3) I've changed in ../franz/vax/Makefile/qfuncl.c the lines : ------------------------------------------------------------------------------ #ifdef PROF .set indx,0 #define Profile \ movab prbuf+indx,r0 \ .set indx,indx+4 \ jsb mcount #define Profile2 \ movl r0,r5 \ Profile \ movl r5,r0 #else #define Profile #define Profile2 #endif ------------------------------------------------------------------------------ to : ------------------------------------------------------------------------------ #ifdef PROF .set indx,0 #define Profile \ movab prbuf+indx,r0 ; \ .set indx,indx+4 ; \ jsb mcount #define Profile2 \ movl r0,r5 ; \ Profile ; \ movl r5,r0 #else #define Profile #define Profile2 #endif ------------------------------------------------------------------------------ After all these modifications, we have the following error message when making it slow : ------------------------------------------------------------------------------ ld -x -o rawlisp -e start ../low.o ../lowaux.o crt0.o ../alloc.o ../data.o bigmath.o qfuncl.o vax.o ../lisp.o ../eval.o ../eval2.o ../inits.o ../io.o ../error.o ../sysat.o ../lam1.o ../lam2.o ../lam3.o ../lam4.o ../lam5.o ../lam6.o ../lam7.o ../lam8.o ../lam9.o ../lamr.o ../lamp.o ../fex1.o ../fex2.o ../fex3.o ../fex4.o ../fexr.o ../fpipe.o ../subbig.o ../pbignum.o ../divbig.o ../ffasl.o ../fasl.o ../trace.o ../evalf.o ../frame.o ../lamgc.o ../lamuom.o ../hash.o -lm -lc -ltermlib mcount: ld:/lib/libc.a(mon.o): multiply defined *** Error code 2 Stop. *** Error code 1 Stop. ------------------------------------------------------------------------------ From franz!schlafly Fri Apr 5 11:19:37 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02221; Fri, 5 Apr 85 11:19:37 pst Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA04091; Fri, 5 Apr 85 11:18:48 pst Received: by ucbkim.ARPA (4.24/4.27) id AA02177; Fri, 5 Apr 85 11:18:45 pst Received: by franz.uucp (1.2/3.14) id AA00261; Fri, 5 Apr 85 10:37:18 pst Date: Fri, 5 Apr 85 10:37:18 pst From: franz!schlafly (Roger Schlafly) Message-Id: <8504051837.AA00261@franz.uucp> To: franz-friends@BERKELEY Subject: Franz Lisp applications Here is my list of Franz Lisp applications. Enough people requested copies that I am sending it to all franz-friends. If anyone sees any notable omissions, please send me a message and I will augment the list. Roger Schlafly ucbvax!franz!schlafly ============================================================ AI and Expert System Tools and Applications Developed or Running under Franz Lisp + OPS-5 A rule based environment for developing expert systems. Available from Franz Inc. with Franz LISP at no charge, or at no charge from Carnegie Mellon University. Computer Science Department, Carnegie Mellon University, Schenley Park, Pittsburgh PA 15213. (412) 578-2592 + Flavors An object oriented extension of Lisp, developed at MIT and the University of Maryland. Used on the Symbolics Lisp machines. Available from Franz Inc. at no charge to pur- chasers of Franz Lisp. + DUCK DUCK is an expert systems development environment. Available from Smart Systems Technology, 6870 Elm St. McLean, VA. 22101 (703) 448-8562. + Boyer-Moore Theorem Prover Available from Prof. Robert Boyer, University of Texas, Aus- tin. Computer Science Department, 3-28 Painter Hall, University of Texas, Austin, Texas 78712. (512) 471-7316 + GLISP GLISP is a high-level language which is based on Lisp and is compiled into Lisp. It was developed at the University of Texas at Austin by Prof. Gordon Novak. Object-centered pro- gramming is supported. Message interpretations can be looked up at compile time to produce efficient code. A window-based editor, GEV, is available to inspect and edit data according to its data structure description. GLISP is available from Franz Inc. at no charge to purchasers of Franz Lisp, or from the University of Texas at Austin, Prof. Gordon Novak, Computer Science Department, 3-28 Painter Hall, University of Texas, Austin, Texas 78712. (512) 471- 7316 + FRL A frame representation language for AI development. Available from Steven Rosenberg, Hewlett Packard (415) 857 5902 + MRS A logic based knowledge representation system. Available from Stanford University. Attention: Pattie McCabe SUMEX Computing Facility, Stanford University Medical Center, Room TB105, Stanford, California 94305, (415) 497-5141 + Macsyma Developed at MIT, Macsyma is a program that carries out sym- bolic computation. It will solve all those integrals you learned about in your calculus class, as well as systems of differential equations and other mathematical problems. + Reduce Reduce is similar to Macsyma. It was developed at the University of Utah. Computer Science Department, 3160 Mer- rill Engineering Bldg. Salt Lake City, Utah 84112. (801) 484-7651 Ext 205 + XCON Digital Equipment's famous expert system, written in OPS-5, originally ran on top of Franz Lisp. XCON configures com- puters before shipment. + ACE Automatic Cable Expertise : A knowledge based expert system that provides trouble-shooting and diagnostic reports for telephone company managers. Developed by Stolfo, Vesonder and others at AT&T Bell Labs. For details see "The Fifth Generation Challenge" Proceedings ACM '84 Annual Conference. + Slang A circuit design and analysis tool. It has been used to design several integrated circuits at U.C. Berkeley. A detailed description is in the masters thesis of Korbin Van Dyke at U.C. Berkeley. Available from: Industrial Liason Program, EECS Department, University of California, Berkeley CA 94720 (415) 642-0253 + Lyra A VLSI design rule checker. A description is in the masters thesis of Michael Arnold at U.C. Berkeley. + Pearl A database and AI representation language written in Franz Lisp. Available from Franz Inc. at no charge to purchasers of Franz Lisp. + YAPS Yet Another Production System. Developed by Liz Allen at the University of Maryland. A forward driven production rule system similar to OPS-5, but with added flexibility. YAPS supports objects in facts, and defines an object that is a complete production system, so you can have more than one expert around at a time. See "YAPS: A Production System Meets Object" by Liz Allen in AAAI-83 for more information. YAPS is available at nominal cost from the Universtiy of Maryland. The license fee is $100 for BSD 4.1, $250 for 4.2. It's also Arpanet FTP'able for $100 for either ver- sion. Contact Bob Bane on Arpanet at bane@maryland or on Usenet at ...seismo!umcp-cs!bane or contact Liz Allen at liz@tove.arpa or seismo!umcp-cs!liz . + GENIE GENeric Inference Engine. An expert system development tool. Written by John Dumer, Tim Hanratty, Paul Tanenbaum, and Fred S. Brundick. For more information contact: Fred S. Brundick, + The Berkeley UNIX Consultant An expert System incorporating a natural language interface which answers questions about UNIX. Under development at U.C. Berkeley. USABRL, APG, MD. + ROSS and SWIRL ROSS is an object-oriented language developed for building knowledge based simulations. SWIRL is a program written in ROSS that embeds knowledge about defensive and offensive air battle strategies. Developed by Narain, McArthur and Klahr at The Rand Corporation, 1700 Main Street, Santa Monica CA 90406. These systems were implemented in various LISP environments including Franz LISP. A comparison of hte various environments in terms of CPU usage, real-time usage and user aids can be found in an article by the above in the proceedings of the 1983 International Joint Conference on Artificial Intelligence, Karlsruhe, W. Germany. From liz@tove Sat Apr 6 09:35:22 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13697; Sat, 6 Apr 85 09:35:22 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA24792; Sat, 6 Apr 85 09:35:09 pst Received: by tove.ARPA (4.12/4.7) id AA10092; Sat, 6 Apr 85 12:36:17 est Message-Id: <8504061736.AA10092@tove.ARPA> To: franz!schlafly@BERKELEY (Roger Schlafly) Cc: franz-friends@BERKELEY Subject: Re: Franz Lisp applications In-Reply-To: Your message of Fri, 5 Apr 85 10:37:18 pst. <8504051837.AA00261@franz.uucp> Date: 06 Apr 85 12:36:04 EST (Sat) From: Liz Allen A correction to one of the entries. From: franz!schlafly@Berkeley (Roger Schlafly) + Flavors An object oriented extension of Lisp, developed at MIT and the University of Maryland. Used on the Symbolics Lisp machines. Available from Franz Inc. at no charge to pur- chasers of Franz Lisp. Actually, there are two implmentations of flavors available for Franz; one written at MIT and the other at Univ of Maryland. Franz Inc distributes the one from MIT and we (at UofM) distribute our version as part of the Maryland software distribution (which includes Franz 38.91). For more information about getting our distribution, contact Bob Bane bane@gymble.arpa or seismo!umcp-cs!bane. -Liz From wfi%ucsc.csnet@csnet-relay.arpa Tue Apr 9 02:28:37 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07208; Tue, 9 Apr 85 02:28:37 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA14376; Tue, 9 Apr 85 02:27:14 pst Message-Id: <8504091027.AA14376@UCB-VAX.ARPA> Received: from ucsc by csnet-relay.csnet id ad14837; 9 Apr 85 5:28 EST Received: by vger.UCSC (4.12/4.7) id AA27515; Mon, 8 Apr 85 14:09:04 pst Date: Mon, 8 Apr 85 14:09:04 pst From: wfi <@csnet-relay.arpa,@ucsc.CSNET:wfi@ucsc.CSNET (Wayne F. Iba)> To: franz-friends@BERKELEY Subject: franz profiling Cc: wfi@ucsc.CSNET There is a short note in the documentation of liszt that "if the lisp system is built with profiling", then using the -p option will allow use of the UNIX prof command etc. Can someone explain how to rebuild (if necessary) our lisp system accordingly? Thanks --wayne (wfi%ucsc.csnet) From klahr@rand-unix Tue Apr 9 10:03:37 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09758; Tue, 9 Apr 85 10:03:37 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA20618; Tue, 9 Apr 85 10:02:11 pst Received: by rand-unix.ARPA; Tue, 9 Apr 85 09:41:46 pst From: Phil Klahr Message-Id: <8504091741.AA17861@rand-unix.ARPA> Date: 09 Apr 85 09:41:40 PST (Tue) To: FRANZ-FRIENDS@BERKELEY Cc: randvax!klahr Subject: IJCAI-85 Registration -- Please post The International Joint Conference on Artificial Intelligence will be meeting in Los Angeles (at UCLA) August 18-23, 1985. Conference brochures (including registration information) have already been mailed out. If you have not received one, or would like extras, contact IJCAI-85 c/o AAAI 445 Burgess Drive Menlo Park, CA 94025 415-328-3123 or 415-321-1118 Registration will be limited to 5,000 people. Based on early projections, up to 7,000 people may wish to attend, so early registration is highly encouraged (if not necessary). As a bonus, early registrants will receive a substantial reduction in registration costs. Through June 28, registration fees are $175 ($80 for students); for registrations received after June 28 but prior to July 26, fees will be $225 ($100 for students); and for on-site registration (if available), fees will be $275 ($125 for students). Substantial reductions for early tutorial registrations are also in effect. Further information on the technical conference, the tutorials, the exhibition, and housing can be found in the conference brochure. From jeffr@sri-spam Tue Apr 9 16:38:17 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00472; Tue, 9 Apr 85 16:38:17 pst Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA29765; Tue, 9 Apr 85 16:36:41 pst Received: by sri-spam.ARPA (4.22/4.16) id AA05175; Tue, 9 Apr 85 16:37:20 pst Date: Tue, 9 Apr 85 16:37:20 pst From: jeffr@sri-spam (Jeff Rininger) Message-Id: <8504100037.AA05175@sri-spam.ARPA> To: franz-friends@BERKELEY Does anyone know of (or have) a Franz function that returns a character corresponding to a given fixnum representation, but without the pesky symbol delimiters that `ascii' returns ? From g_keaton%scarolina.csnet@csnet-relay.arpa Sat Apr 13 23:33:19 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22504; Sat, 13 Apr 85 23:33:19 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA13927; Sat, 13 Apr 85 23:32:05 pst Message-Id: <8504140732.AA13927@UCB-VAX.ARPA> Received: from scarolina by csnet-relay.csnet id a013785; 14 Apr 85 2:36 EST Date: Fri, 12 Apr 85 13:01 EST From: Bonnell To: FRANZ-FRIENDS@BERKELEY Subject: Problems with *process. I am attempting to have a Lisp process talk to a C process using Lisp's *process function. This function works fine with system commands such as 'ls' but fails when the C process is a typical user program. I hope someone has run into similar difficulties and can provide some enlightenment. We are using a set Sun workstations running Berkley Unix. The same problem also occurs on our VAX. Thanks, Gar Keaton From narain@rand-unix Mon Apr 15 11:33:17 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08082; Mon, 15 Apr 85 11:33:17 pst Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA08871; Mon, 15 Apr 85 11:31:51 pst Received: by rand-unix.ARPA; Mon, 15 Apr 85 11:29:44 pst From: Sanjai Narain Message-Id: <8504151929.AA12668@rand-unix.ARPA> Date: 15 Apr 85 11:29:40 PST (Mon) To: Bonnell Cc: FRANZ-FRIENDS@BERKELEY, narain@rand-unix Subject: Re: Problems with *process. In-Reply-To: Your message of Fri, 12 Apr 85 13:01 EST. <8504140732.AA13927@UCB-VAX.ARPA> I once set up a link between Franzlisp and C-Prolog using process instead of *process and it worked fine. It was on Vax 11/780, but it was most probably on an earlier version of Unix, rather than 4.2bsd. -- Sanjai Narain From chin@ucbdali Sat Apr 20 11:50:19 1985 Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27) id AA03799; Sat, 20 Apr 85 11:50:19 pst Received: by ucbdali.ARPA (4.24/4.45) id AA08585; Sat, 20 Apr 85 11:50:12 pst Date: Sat, 20 Apr 85 11:50:12 pst From: chin@ucbdali (David N. Chin) Message-Id: <8504201950.AA08585@ucbdali.ARPA> To: franz-friends@ucbdali Subject: profiling Does anyone have a profiling package for FRANZ that provides execution time statistics? The prof.l package in the lisplib only provides call frequency statistics, and the liszt -p option only works if lisp was created with profiling (not to mention that you would have to recompile all your code to use it). Thanks in advance, David Chin chin@BERKELEY ucbvax!chin From smh@mit-eddie.ARPA Sun Apr 21 14:13:02 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17063; Sun, 21 Apr 85 14:13:02 pst Received: from mit-eddie.ARPA (mit-eddie.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45) id AA03920; Sun, 21 Apr 85 14:11:39 pst Received: by mit-eddie.ARPA (4.12/4.8) id AA03273; Sun, 21 Apr 85 17:11:05 est Date: Sun, 21 Apr 85 17:11:05 est From: Steven M. Haflich Message-Id: <8504212211.AA03273@mit-eddie.ARPA> To: franz-friends@BERKELEY Subject: Gnu EMACS customization for Lisp Lisp hackers who use Gnu EMACS might want to try this useful customization. It emulates the standard keybinding of CCA EMACS that makes C-Z (i.e. control-Z) a prefix which both CONTROL- and META-izes to the following keystroke. This is particularly useful for Lisp because most of the special Lisp editing commands are bound to ESC CONTROL characters. This text can be placed in the personal .emacs file in your home directory. The suspend-emacs function previously run by C-Z is still available as either C-X C-Z or C-Z C-Z . But first: The two "^Z" strings in the text below have been sanitized to pass through mailers and, as mailed, contain a two character sequence representing CONTROL-Z to humans. You will have to edit them to contain the single literal character C-Z, which can be typed in EMACS via the two-keystroke sequence: C-Q C-Z . ====================================== (defun c-m-prefix () "Apply both META and CONTROL to the next command character" (interactive) (command-execute (lookup-key esc-map (char-to-string (logand 31 (read-char)))))) (define-key global-map "^Z" 'c-m-prefix) (define-key esc-map "^Z" 'suspend-emacs) From @MIT-MC:wah@cmu-cs-ius.arpa Tue Apr 23 17:48:24 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46) id AA18909; Tue, 23 Apr 85 17:48:24 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA10636; Tue, 23 Apr 85 17:46:11 pst Message-Id: <8504240146.AA10636@UCB-VAX.ARPA> Received: from CMU-CS-IUS.ARPA by MIT-MC.ARPA; 22 APR 85 12:13:41 EST Date: 22 Apr 85 12:05:53 EST From: Wilson.Harvey@CMU-CS-IUS Subject: #ifdef for liszt? To: BBoard.Maintainer@CMU-CS-A Is there anything for the lisp compiler akin to the "#ifdef" statement for the C compiler? Can anyone point me to something similar? Thanks. -- Wilson From liz@tove Wed Apr 24 12:02:32 1985 Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46) id AA01778; Wed, 24 Apr 85 12:02:32 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA02711; Wed, 24 Apr 85 12:00:04 pst Received: by tove.ARPA (4.12/4.7) id AA15012; Wed, 24 Apr 85 15:00:27 est Message-Id: <8504242000.AA15012@tove.ARPA> To: Wilson.Harvey@cmu-cs-ius Cc: franz-friends@BERKELEY Subject: Re: #ifdef for liszt? In-Reply-To: Your message of 22 Apr 85 12:05:53 EST. <8504240146.AA10636@UCB-VAX.ARPA> Date: 24 Apr 85 15:00:16 EST (Wed) From: Liz Allen From: Wilson.Harvey@CMU-CS-IUS Is there anything for the lisp compiler akin to the "#ifdef" statement for the C compiler? Can anyone point me to something similar? Thanks. -- Wilson The reader has built into it a switch that works in both liszt and lisp. You can tell lisp whether or not to read an expression by putting before that expression something like: #+feature #-feature #+(or feature ...) #+(and feature ...) where feature is on iff it is on the "(status features)" list (which can be modified). Thus you can do something like this: #-uomlisp (defun morerecent (file1 file2) ...) since uomlisp is turned only in Franz's that contain all our hacks and morerecent happens to already be defined in our stuff. If you look at the liszt code, you'll see lots of "#+vax"'s and "#+68k"'s where the code needs to be different, eg: (defun cc-foo (x y z) (bar #+vax vax-arg #+68k 68k-arg) ...) It can be quite convenient especially when you have two lisps that are almost the same, you can maintain just one source containing these things whenever the sources for the different lisps must be different. I know this stuff is documented in the code in charmac.l; I can't remember right now if it is documented in the Franz reference manual and I don't have it with me right now to check. Hope this helps. -Liz