![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to lispnews CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / pgrm / lisp|
Return to lispnews CVS log | Up to [CSRG BSD Unix] / 43BSDReno / pgrm / lisp |
1.1 root 1: From jkf Tue Apr 13 00:12:22 1982
2: To: /na/doe/jkf/lispnews
3: Subject: new features
4: Status: RO
5:
6: In response to requests from franz users, these enhancements have been
7: made:
8:
9: In Lisp 38.07, if the lisp variable 'displace-macros' is set to non-nil,
10: then when a macro expansion is done by the evaluator, the resulting
11: expansion replaces the original call. This means that macro expansion
12: is only done once.
13:
14: In Liszt 8.03, the 'function' function is open coded. If you have
15: (function (lambda ....))
16: in your code then the lambda expression is compiled as a separate function
17: and the result of the function call is a 'bcd' object which points
18: to that compiled lambda.
19:
20:
21:
22: From jkf Sun Apr 18 13:16:46 1982
23: To: local-lisp
24: Subject: opus 38.09
25: Status: RO
26:
27: The new features of this version are:
28: If the load function ends up fasl'ing in a file, then load will
29: do what is necessary to insure that the new functions are linked in
30: correctly. Previously, if you turned on the transfer tables with
31: (sstatus translink on) or (sstatus translink t) and then fasl'ed in
32: functions which already existed, the old versions of the functions
33: would still be used, unless you did (sstatus translink on) yourself.
34: Now this is done automatically.
35:
36: tyi now accepts a second argument which is the object to return
37: upon eof. -1 is the default.
38:
39: (pp-form 'g_obj ['p_port]) should be used instead of $prpr
40: for pretty printing a form.
41:
42: The storage allocator and collector has been modified to add
43: two new data types: vector and vector immediate. They are not in
44: their final form so I suggest that you not try to use them.
45: However, be on the lookout for garbage collection bugs.
46:
47:
48:
49: From jkf Wed Apr 21 07:45:54 1982
50: To: local-lisp
51: Subject: liszt 8.04
52: Status: RO
53:
54: the new features of liszt 8.04 are:
55:
56: 1) init files:
57: Before liszt begins compiling, it looks for an init file to load in.
58: It first searches in the current directory, and then it searches
59: your home directory (getenv 'HOME).
60: It looks for file names:
61: .lisztrc.o .lisztrc.l lisztrc.o lisztrc.l
62: It loads only the first one it finds.
63:
64: 2) interrupt handling
65: If you interrupt liszt (with ^C typically), it will remove its
66: temporary file and exit.
67:
68: 3) preallocation of space
69: It preallocates space in order to reduce the number of gc's done
70: during compiling.
71:
72:
73:
74:
75:
76: From jkf Wed Apr 21 13:47:50 1982
77: To: local-lisp
78: Subject: lisp opus 38.10
79: Status: RO
80:
81: lisp will now look for a lisprc in a way similar to liszt.
82:
83: It will first search in . and then in $HOME
84: It will look for the file .lisprc or lisprc ending with .o, .l and then
85: just .lisprc or lisprc.
86:
87: Shortly, it will only look for files ending in .l and .o since we don't
88: want to encourage files with non-standard filename extensions.
89:
90:
91:
92:
93:
94: From jkf Wed Apr 21 23:40:59 1982
95: To: local-lisp
96: Subject: lisp opus 38.11
97: Status: RO
98:
99: I finally got sick of showstack and baktrace and rewrote them in lisp,
100: rincorporating some of the features people have been requesting.
101: Showstack now works as follows:
102: (showstack) : show all interesting forms. Forms resulting from
103: the trace package are not printed as well as
104: extraneous calls to eval. In the form printed,
105: the special form <**> means 'the previous expression
106: printed'. prinlevel and prinlength are set to
107: reasonable values to prevent the expression from
108: getting too large
109: (showstack t) : same as above but print all expressions.
110: (showstack 5) : print only the first 5 expressions. of course, 5
111: is not the only possible numeric argument.
112: (showstack lev 3) : set prinlevel to 3 before printing
113: (showstack len 4) : set prinlength to 4 before printing
114: the above arguments can be used in combination.
115:
116: The default value of prinlevel is showstack-prinlevel, that of prinlength
117: is showstack-prinlength. the default showstack printer is the
118: value of showstack-printer (default is 'print').
119:
120: baktrace accepts the same arguments as showstack, but it ignores the
121: prinlevel and prinlength arguments.
122:
123:
124:
125:
126: From jkf Sat Apr 24 08:55:18 1982
127: To: local-lisp
128: Subject: lisp opus 38.12, liszt 8.05
129: Status: RO
130:
131: these changes and enhancements were made:
132:
133: 1) the function 'function' in the interpreter acts just like 'quote'
134: In the compiler, 'function' will act like 'quote' unless the
135: argument is a lambda expression, in which case liszt will replace
136: the lambda expression with a unique symbol. That unique symbol's
137: function cell will contain a compiled version of the lambda
138: expression. These changes will make Franz compatible with Maclisp
139: type lisps, as far as the treatment of 'function'
140:
141: 2) Mechanisms were added to permit user written C or Fortran code to call
142: lisp code. Everything isn't quite ready yet.
143:
144: 3) Signal was fixed so that if you ask for a signal to be ignored, the
145: operating system will be notified. The correct way to fork a lisp
146: is now:
147: (cond ((fork) (signal 2 (prog1 (signal 2) (wait)))))
148:
149: 4) You can select the default function trace uses to print the arguments and
150: results. Just lambda bind trace-printer to the name of the function
151: you want it to use. The standard trace-printer sets prinlevel and
152: prinlength to the values of trace-prinlevel and trace-prinlength before
153: printing. By default, trace-prinlevel is 4, and trace-prinlength is 5
154:
155:
156:
157:
158:
159: From jkf Sun Apr 25 23:46:16 1982
160: To: local-lisp
161: Subject: lisp opus 38.13
162: Status: RO
163:
164: Functions 1+ and 1- are now part of the interpreter, rather than
165: being made equivalent to add1 and sub1.
166:
167:
168:
169: From jkf Wed Apr 28 09:52:43 1982
170: To: local-lisp
171: Subject: Opus 38.14
172: Status: RO
173:
174: Has these new features:
175: 1) the message [load filename] will appear before load
176: reads in a lisp source file. This can be disabled by
177: setting $ldprint to nil.
178: 2) a function 'truename' as been added. It takes a port
179: and returns the name of the file associated with that port.
180: It returns a string if there is a file associated with
181: the port, otherwise it returns nil.
182:
183:
184:
185: From jkf Wed Apr 28 10:36:34 1982
186: To: local-lisp
187: Subject: more on opus 38.14
188: Status: RO
189:
190: $ldprint is lambda bound to nil during the loading of the lisprc file.
191:
192:
193:
194:
195: From jkf Wed May 5 08:30:00 1982
196: To: local-lisp
197: Subject: opus 38.15
198: Status: RO
199:
200: a minor modification: 'makhunk' is now more efficient.
201:
202:
203: From jkf Wed May 5 20:56:40 1982
204: To: local-lisp
205: Subject: Opus 38.16
206: Status: RO
207:
208: A new function was added:
209: (hunk-to-list 'h_hunk)
210: returns the elements of h_hunk as a list.
211:
212: Also, the error message printed when an oversized print name is encountered
213: has been improved.
214:
215:
216:
217: From jkf Fri May 7 20:03:40 1982
218: To: local-lisp
219: Subject: Liszt version 8.06
220: Status: RO
221:
222:
223: Local declarations are now supported. You can say:
224: (defun foo (a b)
225: (declare (special a))
226: ... body ...)
227:
228: and the special declaration for 'a' will affect the body of function
229: foo only. The 'a' which is an argument to foo will also be special
230: in this case. Declarations may be
231: 1) at the top level, not within a function body.
232: 2) at the beginning of a 'lambda' body.
233: 3) at the beginning of a 'prog' body
234: 4) at the beginning of a 'do' body.
235:
236: 'the beginning' means either the first, second or third form in the body.
237: When the compiler is searching for declarations, it will not macroexpand.
238:
239:
240: Fixnum declarations now have meaning. If you do
241: (declare (fixnum i j))
242: then
243: (greaterp i j) will be converted to (>& i j)
244:
245: The declare function is now defined in the compiler. Previously,
246: the only way to declare something was for the compiler to 'compile'
247: the declaration form. Now, if you load or fasl in a file with
248: a declare statement in it, the declare statement will have the
249: proper effect in the compiler.
250:
251:
252: (function (lambda () ...)), (function (nlambda () ...)) and
253: (function (lexpr () ...)) are all supported.
254:
255:
256:
257: From jkf Wed May 12 08:15:37 1982
258: To: local-lisp
259: Subject: Lisp Opus 38.17
260: Status: RO
261:
262: ... has a minor bug fix: The port returned by 'fileopen' will now print
263: correctly.
264:
265:
266:
267: From jkf Tue May 25 06:18:04 1982
268: Date: 25-May-82 06:17:51-PDT (Tue)
269: From: jkf
270: Subject: opus 38.18
271: Via: ucbkim.EtherNet (V3.100 [3/27/82]); 25-May-82 06:18:04-PDT (Tue)
272: To: local-lisp
273: Status: RO
274:
275: The msg macro will now evaluate all atom arguments except the ones
276: for carriage control (N B). Thus if you used (msg foo) you should
277: now use (msg "foo").
278:
279:
280:
281: From jkf Thu May 27 08:29:29 1982
282: To: local-lisp
283: Subject: liszt 8.08
284: Status: RO
285:
286: Fixes a bug in the code which converts generic arithmetic to fixnum only
287: arithmetic. Liszt was converting from generic to fixnum operators based on
288: the first argument only due to a typo in the code.
289:
290:
291:
292:
293: From jkf Wed Jun 9 07:25:19 1982
294: To: local-lisp
295: Subject: lisp Opus 38.20
296: Status: RO
297:
298: There is now a character macro for reading hexadecimal.
299: #x1f = #X1f = #X1F = 31
300: #x-1f = -31
301:
302:
303:
304: From jkf Thu Jun 17 15:42:54 1982
305: To: local-lisp
306: Subject: Lisp Opus 38.21
307: Status: RO
308:
309: Has two routines for interfacing with termcap. These routines were
310: written by morris djavaher and are meant to be called by lisp programs
311: which have yet to be installed.
312:
313:
314:
315:
316: From jkf Tue Jun 22 09:09:25 1982
317: Date: 22-Jun-82 09:09:13-PDT (Tue)
318: From: jkf
319: Subject: opus 38.22
320: Via: ucbkim.EtherNet (V3.120 [6/17/82]); 22-Jun-82 09:09:25-PDT (Tue)
321: To: local-lisp
322: Status: RO
323:
324: setq with no arguments will now return nil.
325:
326:
327:
328: From jkf Wed Jun 30 19:05:54 1982
329: Date: 30-Jun-82 19:05:32-PDT (Wed)
330: From: jkf (John Foderaro)
331: Subject: liszt 8.09
332: Via: ucbkim.EtherNet (V3.130 [6/26/82]); 30-Jun-82 19:05:54-PDT (Wed)
333: To: local-lisp
334: Status: RO
335:
336: liszt will now look in 12 places for an init file when it starts up.
337: It will load in the first one it comes to only.
338: The files it looks for are:
339:
340: { ./ , $HOME } { .lisztrc , lisztrc } { .o , .l , }
341:
342:
343:
344:
345: From jkf Tue Sep 14 08:53:03 1982
346: Date: 14-Sep-82 08:52:44-PDT (Tue)
347: From: jkf (John Foderaro)
348: Subject: lisp opus 38.26
349: Message-Id: <[email protected]>
350: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09999;
351: 14-Sep-82 08:53:03-PDT (Tue)
352: To: local-lisp
353: Status: RO
354:
355: Franz used to read the symbols 4dxx 4Dxx and 4Exx as 4exx. Now it reads
356: them (and other similar symbols) correctly.
357:
358:
359:
360:
361: From jkf Sat Oct 2 15:15:48 1982
362: Date: 2-Oct-82 15:15:32-PDT (Sat)
363: From: jkf (John Foderaro)
364: Subject: lisp opus 38.27
365: Message-Id: <[email protected]>
366: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a10796;
367: 2-Oct-82 15:15:48-PDT (Sat)
368: To: local-lisp
369: Status: RO
370:
371: If you set the variable top-level-print to a non nil value, then that
372: value will be used by the top-level to print out the result of the
373: evaluation. This has effect in break loops too.
374: For example, if you want the pretty printer to print out the top level
375: values, type (setq top-level-print 'pp-form).
376:
377:
378:
379:
380:
381: From jkf Sun Oct 3 19:28:45 1982
382: Date: 3-Oct-82 19:28:29-PDT (Sun)
383: From: jkf (John Foderaro)
384: Subject: lisp opus 38.28
385: Message-Id: <[email protected]>
386: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a09829;
387: 3-Oct-82 19:28:45-PDT (Sun)
388: To: local-lisp
389: Status: RO
390:
391: A modification has been made to the load function.
392: Normally if you type (load 'x), the load function will first try to fasl
393: the file x.o and failing that it will try to load x.l
394: If you (setq load-most-recent t), and if x.l and x.o both exist, then
395: load will fasl or load the most recently modified file.
396: The load-most-recent flag only has an effect if you type the filename
397: without a trailing .l or .o.
398:
399:
400:
401:
402: From jkf Tue Oct 5 21:01:55 1982
403: Date: 5-Oct-82 21:01:33-PDT (Tue)
404: From: jkf (John Foderaro)
405: Subject: liszt 8.12, lisp 38.29
406: Message-Id: <[email protected]>
407: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a06358;
408: 5-Oct-82 21:01:55-PDT (Tue)
409: To: local-lisp
410: Status: RO
411:
412: Liszt will now check that you are passing the correct number of arguments
413: to functions. As a result, some files which have compiled without
414: complaint in the past may compile now with warnings or errors. In this
415: note, I'll explain what the compiler knows, what it looks for in your
416: program, and how you can help the compiler understand your program.
417:
418: For each function, liszt either knows nothing about the the number of
419: arguments to a function, or it knows the minimum number of arguments, or the
420: maximum number of arguments, or both the minimum and maximum number of
421: arguments. This information comes about in one of three ways:
422: 1) it is known when liszt starts (by virtue of a value stored under the
423: fcn-info indicator on a function's property list)
424: 2) it is declared by the user, either via (declare (*arginfo ...))
425: or (declare (*args ...)) [see below]
426: 3) it is determined when a (lambda) function is compiled.
427: When a lambda is compiled, the compiler can easily figure out the
428: minimum and maximum number of arguments.
429: When an nlambda or lexpr function is compiled, the compiler doesn't
430: make a guess as to how many arguments are expected. The user should
431: use the (declare (*args ...)) form to tell the compiler how many
432: arguments are expected.
433: For lexpr's generated via 'defun' using &optional and &rest keywords,
434: the correct declaration is generated automatically.
435: Once liszt determines the number of arguments to a function, it uses that
436: information to check that the function is called with the correct number of
437: arguments. It does not check calls to the function that occured before it
438: determined the correct number of arguments. [This backward checking will
439: be added sometime in the future.]
440:
441: If liszt finds that a function is called with the wrong number of
442: arguments, it prints an informative message. That message is a error if the
443: function being called is one which is open coded by the compiler. The
444: message is a warning otherwise. The reason for the distinction is that
445: you are free to redefine functions not open coded by the compiler. If the
446: number of arguments is not correct, it may just be that the compiler's
447: database and your code are refering to two different functions.
448: If you redefine system functions, you should use the
449: (declare (*arginfo ...)) form to let the compiler know about the number
450: of arguments expected by your version of the functions.
451:
452: You can declare the number of arguments to functions using this form
453:
454: (declare (*arginfo (fcnname1 min1 max1) (fcnname2 min2 max2) ...))
455: where each min or max is either a fixnum or nil (meaning "I don't know")
456:
457: for example, here are some `correct' declarations:
458:
459: (declare (*arginfo (read 0 2) (cons 2 2) (boole 3 nil) (append nil nil)))
460:
461: explanation:
462: (read 0 2) means that the function read expects between 0 and 2
463: arguments (inclusive).
464: (cons 2 2) means that cons expects 2 arguments.
465: (boole 3 nil) means that boole expects at least 3 arguments.
466: (append nil nil) means that append expects any number of arguments,
467: this is equivalent to (append 0 nil).
468:
469:
470: The *arginfo declaration is usually made at the top level of a file.
471:
472: To declare the argument characteristics of the current function being
473: compiled use the '*args' declaration. It looks somewhat like the
474: *arginfo declaration.
475:
476: It is best explained with examples
477:
478: (def read
479: (lexpr (n)
480: (declare (*args 0 2))
481: ... code for read
482: ))
483:
484: (def process
485: (nlambda (x)
486: (declare (*args 1 3))
487: ... code for process
488: ))
489:
490: Note: the *args declaration is not needed for lambda's.
491:
492:
493:
494: If you get an error or warning which you believe is incorrect, it is
495: probably due to an incorrect database entry. Please let me know and I will
496: fix it immediately. I expect that there will be quite a few of these
497: errors because much of the database was built by hand.
498:
499:
500:
501:
502:
503:
504: From jkf Fri Oct 8 12:55:45 1982
505: Date: 8-Oct-82 12:55:31-PDT (Fri)
506: From: jkf (John Foderaro)
507: Subject: lisp 38.30, liszt 8.13
508: Message-Id: <[email protected]>
509: Received: by UCBKIM.BERKELEY.ARPA (3.193 [9/6/82]) id a04140;
510: 8-Oct-82 12:55:45-PDT (Fri)
511: To: local-lisp
512: Status: RO
513:
514: There are now three new functions for dealing with processes:
515: *process
516: *process-send
517: *process-receive
518:
519: These functions are designed to replace the 'process' function, which, due
520: to its nlambda'ness, was difficult to use. All of the above functions
521: are lambda's or lexpr's.
522:
523: See chapter 6 of the manual (its on-line) for the details of these
524: functions. This is a quick summary:
525:
526: (*process-send 'st_command)
527: tells the shell to run the command st_command concurrently, and returns
528: a write-only port. Characters written to this port will appear at
529: the standard input of st_command.
530: example:
531: (setq p (*process-send "mail jkf"))
532: (print 'HiThere p)
533: (close p)
534:
535:
536: (*process-receive 'st_command)
537: tells the shell to run st_command concurrently, and returns a
538: read-only port. Characters written to the standard output by
539: st_command will be available by reading from the given port.
540: Characters written on the standard error by st_command will
541: appear on lisp's the standard error (the terminal most likely).
542: example:
543: ; to see if foo is logged in:
544: (setq p (*process-receive "u"))
545: (do ((user (read p '**eof**) (read p '**eof**)))
546: ((eq '**eof** user) (print 'Not-Logged-In))
547: (cond ((eq 'foo user) (print 'Is-Logged-In))))
548: (close p)
549:
550:
551: (*process 'st_command ['g_readp ['g_writep]])
552: this is the general function which process, *process-send and
553: *process-receive call. If called with one argument it
554: starts the new process and waits for it to end, e.g:
555: (*process (concat "vi " filename))
556: In this case *process return the exit code of the process.
557:
558: The g_readp and g_writep arguments, if given, tell *process to
559: run the process concurrently. If g_read is non nil then
560: *process will return a port just like *process-receive.
561: If g_writep is non-nil, then *process will set up a pipe like
562: *process-send.
563: *process will return a list of the form
564: (readport writeport process-id)
565: where readport and writeport will only be a port if g_readp
566: or g_writep are non nil.
567:
568:
569: A little know fact about processes is that a process, once started,
570: cannot die and disappear until its parent asks about its status.
571: Take the mail example given above:
572: (setq p (*process-send "mail jkf"))
573: (print 'HiThere p)
574: (close p)
575: after the mail process finishes it work, it will attempt to die, returning
576: an integer called the 'exit status'. However until the lisp program
577: asks about its status the mail process will remain in existence
578: in a Zombie state, somewhere between life and death. ps will show this:
579:
580: PID TT STAT TIME COMMAND
581: 3876 p0 Z 0:01 <exiting>
582:
583: A user is only allowed a small number of processes, so if you continue
584: to generate processes and leave them around as Zombies, you will eventually
585: run out of processes. The way to let the Zombie die is to call
586: the wait function, e.g.
587: -> (wait)
588: (3876 . 0)
589: ->
590: this says that process 3876 died with exit status 0.
591:
592: Also, when you exit lisp the shell will clean up the Zombies.
593:
594: If you start a process with (*process "vi foo") then lisp will wait
595: for it to complete before continuing, so you don't have to worry about
596: Zombies. You only have to worry if you run a process concurrently,
597: such as when you use *process-send or *process-receive.
598:
599:
600:
601:
602:
603:
604:
605: From jkf Tue Oct 12 10:44:22 1982
606: Date: 12-Oct-82 10:43:52-PDT (Tue)
607: From: jkf (John Foderaro)
608: Subject: lisp opus 38.31
609: Message-Id: <[email protected]>
610: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
611: id A29800; 12-Oct-82 10:44:22-PDT (Tue)
612: To: local-lisp
613: Status: RO
614:
615: new function: (time-string ['x_time])
616: if given no arguments, it returns the current time as a string.
617:
618: if given an argument, x_time, then it converts that argument to
619: a time string and returns that string.
620: The argument should represent the number of seconds since
621: Jan 1, 1970 (GMT).
622:
623: note that this makes (status ctime) obsolete.
624:
625:
626:
627: From jkf Tue Oct 12 14:35:26 1982
628: Date: 12-Oct-82 14:34:10-PDT (Tue)
629: From: jkf (John Foderaro)
630: Subject: also in opus 38.31
631: Message-Id: <[email protected]>
632: Received: by UCBKIM.BERKELEY.ARPA (3.220 [10/11/82])
633: id A05086; 12-Oct-82 14:35:26-PDT (Tue)
634: To: local-lisp
635: Status: RO
636:
637: If top-level-read is set to a non nil value, then the lisp
638: top level will funcall it to read a form for evaluation.
639: It will be funcalled with two arguments, a port and an eof marker.
640: top-level-read will be used in break levels too.
641: Be very careful when setting top-level-read because if you set it
642: to an illegal value, there is no way to correct it.
643:
644:
645:
646:
647:
648: From jkf Tue Oct 19 18:54:18 1982
649: Date: 19-Oct-82 18:54:02-PDT (Tue)
650: From: jkf (John Foderaro)
651: Subject: lisp tags
652: Message-Id: <[email protected]>
653: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
654: id A00195; 19-Oct-82 18:54:18-PDT (Tue)
655: To: franz-friends
656: Status: RO
657:
658: We also use vi style tags so emacs users and vi users can share the same
659: tags file. Rather than modify ctags, we use this shell script:
660:
661: #!/bin/csh
662: # make a tags file for lisp source files.
663: # use:
664: # lisptags foo.l bar.l baz.l ... bof.l
665: # generate the file 'tags'
666: #
667: awk -f /usr/local/lib/ltags $* | sort > tags
668:
669:
670: where the file /usr/local/lib/ltags is
671:
672: /^\(DEF/ { print $2 " " FILENAME " ?^" $0 "$?" }
673: /^\(def/ { print $2 " " FILENAME " ?^" $0 "$?" }
674:
675:
676:
677: From jkf Tue Oct 19 22:50:40 1982
678: Date: 19-Oct-82 22:50:29-PDT (Tue)
679: From: jkf (John Foderaro)
680: Subject: Lisp Opus 38.32, Liszt 8.14
681: Message-Id: <[email protected]>
682: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
683: id A03968; 19-Oct-82 22:50:40-PDT (Tue)
684: To: local-lisp
685: Status: RO
686:
687:
688: Topic 1:
689: liszt can now autoload macros. If liszt encounters a symbol without
690: a function definition but with a macro-autoload indicator on the
691: property list, then the value of the indicator is a file to load which
692: should define the macro.
693:
694: The interpreter's undefined function handler will also look for
695: macro-autoload properties, thus you needn't give a symbol both an
696: autoload and a macro-autoload property.
697:
698: The default lisp contains macro-autoload properties for the macros
699: defstruct, loop and defflavor.
700:
701: Topic 2:
702: It is now possible to define 'compiler only macros' or cmacros.
703: A cmacro acts like a normal macro, but will only be used by the
704: compiler. A cmacro is stored on the property list of a
705: symbol under the indicator 'cmacro'. Thus a function can
706: have a normal definition and a cmacro definition.
707: The macro 'defcmacro' has a syntax identical to 'defmacro' and
708: creates cmacros instead of macros.
709: For an example of the use of cmacros, see the definitions
710: of nthcdr and nth in /usr/lib/lisp/common2.l
711:
712: Topic 3:
713: If the form (foo ...) is macro expanded and the result also begins
714: with the symbol foo, then liszt will stop macro expanding (previously
715: it got into an infinite loop).
716:
717: Topic 4:
718: The function nth has been added to Franz.
719: (nth 'x_index 'l_list)
720: returns the nth element of l_list, where the car of the list
721: is accessed with (nth 0 'l_list)
722:
723: The macros (push 'g_value 'g_stack), and
724: (pop 'g_stack ['g_into])
725: have been added to franz.
726: typical uses
727: (setq foo nil)
728: (push 'xxx foo)
729: (push 123 foo)
730: now foo = (123 xxx)
731: (pop foo) returns 123
732: now foo = (xxx)
733: (pop foo yyy) returns xxx and sets yyy to xxx
734:
735:
736: Topic 5:
737: The version of Flavors written at Mit for Franz have been transported
738: here. Flavors is a system for doing object oriented programming in
739: lisp. The documentation for flavors in the Lisp Machine manual
740: from Mit. Since Lisp Machine manuals are rather scarce around here,
741: perhaps we can find someone to make copies of the flavor chapter for
742: those interested in it. There is a description of the unique
743: features of the Franz Flavors in /usr/lib/lisp/flavors.usage.
744: As mentioned above, the flavors code will be autoloaded
745: when you call 'defflavor' for the first time.
746: Our local flavors expert is Eric Cooper (r.ecc).
747:
748:
749:
750:
751:
752:
753:
754: From jkf Fri Oct 22 15:46:51 1982
755: Date: 22-Oct-82 15:46:32-PDT (Fri)
756: From: jkf (John Foderaro)
757: Subject: lisp opus 38.34
758: Message-Id: <[email protected]>
759: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
760: id A05610; 22-Oct-82 15:46:51-PDT (Fri)
761: To: local-lisp
762: Status: RO
763:
764:
765: Franz lisp now has a form of closure called an fclosure. A fclosure is a
766: compromise between a funarg and the type of functional object that we
767: currently have in Franz. In this short note, I'll explain through examples
768: what fclosures are and where you might use them, and finally describe the new
769: functions. The fclosure system was designed to be compatible with the Lisp
770: Machine closures, so you may want to look at a Lisp Machine manual for more
771: information. fclosure are related to closures in this way:
772: (fclosure '(a b) 'foo) <==> (let ((a a) (b b)) (closure '(a b) 'foo))
773:
774: A example of the use of fclosures:
775:
776: ->(setq counter 0)
777: 0
778: ->(setq x (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
779: fclosure[1]
780:
781: The function 'fclosure' creates a new type of object called a fclosure.
782: A fclosure object contains a functional object, and a set of symbols and
783: values for the symbols. In the above example, the fclosure functional
784: object is (lambda (val) (setq counter (+ val counter)))
785: and the set of symbols and values just contains the symbol 'counter' and
786: zero, the value of counter when the fclosure was created.
787:
788: When a fclosure is funcall'ed:
789: 1) the lisp system lambda binds the symbols in the fclosure to their
790: values in the fclosure.
791: 2) it continues the funcall on the functional object of the fclosure
792: 3) finally it un-lambda binds the symbols in the fclosure and at the
793: same time stores the current values of the symbols in the fclosure.
794:
795: To see what that means, let us continue the example:
796: -> (funcall x 32)
797: 32
798: -> (funcall x 21)
799: 53
800:
801: Notice that the fclosure is saving the value of the symbol 'counter'.
802: Each time a fclosure is created, new space is allocated for saving
803: the values of the symbols.
804: If we executed the same fclosure function:
805: ->(setq y (fclosure '(counter) '(lambda (val) (setq counter (+ val counter)))))
806: fclosure[1]
807:
808: We now have two independent counters:
809: -> (funcall y 2)
810: 2
811: -> (funcall y 12)
812: 14
813: -> (funcall x 3)
814: 56
815:
816: To summarize:
817:
818: (fclosure 'l_vars 'g_funcobj)
819: l_vars is a list of symbols (not containing nil)
820: g_funcobj is lambda expression or a symbol or another fclosure
821:
822: examples: (fclosure '(foo bar baz) 'plus)
823: (fclosure '(a b) #'(lambda (x) (plus x a))) notice the #'
824: which will make the compiler compile the
825: lambda expression.
826:
827:
828: There are time when you want to share variables between fclosures.
829: This can be done if the fclosures are created at the time times using
830: fclosure-list:
831:
832: (fclosure-list 'l_vars1 'g_funcobj1 ['l_vars2 'g_funcobj2 ... ...])
833: This creates a list of closures such that if a symbol appears in
834: l_varsN and l_varsM then its value will be shared between the
835: closures associated with g_funcobjN and g_funcobjM.
836:
837: example: -> (setq x (fclosure-list '(a) '(lambda (y) (setq a y))
838: '(c a) '(lambda () (setq c a))))
839: (fclosure[4] fclosure[7])
840: -> (funcall (car x) 123) ; set the value of a in the 1st fclosure
841: 123
842: -> (funcall (cadr x)) ; read the same value in the 2nd fclosure
843: 123
844:
845:
846: Other fclosure functions:
847:
848: (fclosure-alist 'c_fclosure)
849: returns an assoc list giving the symbols and values in the fclosure
850:
851: (fclosurep 'g_obj)
852: returns t iff g_obj is a fclosure
853:
854: (fclosure-function 'c_fclosure)
855: returns the functional object of the fclosure
856:
857:
858:
859: Note: If a throw (or error) occurs during the evaluation of a fclosure,
860: which passes control out of the fclosure, then current values of the
861: symbols will not be stored. This may be a bug. We could set up
862: an unwind-protect, but it would then take longer to funcall
863: a fclosure. If you think an unwind protect is important, let me know.
864:
865: Note 2: you can also 'apply' a fclosure.
866:
867:
868:
869:
870:
871:
872: From jkf Sat Oct 23 08:58:07 1982
873: Date: 23-Oct-82 08:57:53-PDT (Sat)
874: From: jkf (John Foderaro)
875: Subject: more on closures
876: Message-Id: <[email protected]>
877: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
878: id A21572; 23-Oct-82 08:58:07-PDT (Sat)
879: To: local-lisp
880: Status: RO
881:
882: I sent the maryland people the flavors.usage file from mit so that they
883: could compare their implementation with mit's. What follows is their
884: analysis. Some of the differences between the two versions is due to
885: different schemes for getting around the fact that franz didn't have a form
886: of closure. RZ has indicated that now that franz has fclosures, it may be
887: possible to use more of the 'official' lisp machine flavor code. fclosures
888: will probably affect the maryland implementation too:
889: Date: 22 Oct 82 15:39:18 EDT (Fri)
890: From: Liz Allen <liz.umcp-cs@UDel-Relay>
891: Subject: flavors
892: To: jkf at Ucb-C70
893: Via: UMCP-CS; 23 Oct 82 9:09-EDT
894:
895: Wow, implementing closure in one day is amazing. We had thought
896: about writing some kind of closure... We've been discussing how
897: having closures would affect our code. It might make it easier to
898: read and modify, but it might be less efficient. Can you tell us
899: how your implementation works and what it looks like to a user?
900:
901: About the MIT implementation. Ours is probably better in a couple
902: of respects but probably loses a couple of places, too. Pros:
903:
904: 1. With ours, there is no need to discard instances when
905: redefining a flavor. The only time this would be necessary
906: is if the instance variables change which rarely happens
907: since methods change much more often than the instance
908: variables. Without a structure editor, you tend to reload the
909: file containing flavors in order to change a method.
910:
911: 2. We can compile files with flavors (he didn't say if you
912: can compile MIT's Franz flavors) and when they are compiled
913: they run *fast*. Most of the overhead occurs at combine
914: time and compiled flavors shouldn't have to be recombined.
915:
916: 3. We use hunks to store instance variables (actually, an
917: instance is a hunk whose cxr 0 is the name of the flavor and
918: whose cxr n (> 0) are the values of instance variables). We
919: pay a price at combine time since instance variable references
920: in method code are replaced with cxr and rplacx calls (but MIT
921: pays the same price in putting hash calls in the methods), but
922: we win over MIT since the cxr calls are much faster than the
923: hash table calls. We do have to have "ghost" methods which
924: are copies of methods containing different cxr calls when the
925: referenced variables of a method don't align in flavors
926: which inherit the method. This, however, happens only
927: rarely.
928:
929: 4. We handle getting and setting instance variables better
930: than the MIT implementation -- we don't need to send a message
931: and the syntax is much better. We recently added the
932: functions << and >> which get and set instance variables, eg:
933:
934: (<< foo 'instance-var)
935: and
936: (>> foo 'instance-var 'value)
937:
938: where foo is a flavor instance.
939:
940: 5. Our describe function has a hook which (if the variable
941: *debugging-flavors* is set to non-nil) allows the user to
942: follow pointers to any instances referenced in the describe.
943: This is done by assigning to a variable (made from its unique
944: id) the value of the instance.
945:
946: Cons:
947:
948: 1. They implement more things from Lisp Machine flavors
949: (like wrappers/whoppers, init-keywords), but we really haven't
950: found the need for them. We implement less closely to LM
951: flavors, but in a way that's better suited to Franz Lisp.
952:
953: 2. We didn't implement the method table as a hash table, but
954: there's no reason why we couldn't.
955:
956: 3. Things we don't have, but could easily implement include:
957: describe-method, defun-method/declare-flavor-instance-variables,
958: and storing flavor information in hunks instead of on the
959: property lists.
960:
961: 4. We don't handle method types like :and and :or. We just
962: have primary/untyped methods and :before and :after daemons.
963:
964: We have people reading our documentation. After we get some feedback
965: from them, we'll send the tape and docs to you. That should be early
966: next week.
967:
968: -Liz Allen and Randy Trigg
969:
970:
971:
972:
973:
974:
975:
976: From jkf Mon Oct 25 12:56:59 1982
977: Date: 25-Oct-82 12:55:44-PDT (Mon)
978: From: jkf (John Foderaro)
979: Subject: lisp Opus 38.35, liszt 8.15
980: Message-Id: <[email protected]>
981: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
982: id A17542; 25-Oct-82 12:56:59-PDT (Mon)
983: To: local-lisp
984: Status: RO
985:
986:
987: New features:
988: 1) tilde-expansion: franz will now expand filenames which begin with ~
989: just like csh does. It will only do the expansion if
990: the symbol tilde-expansion has a non-nil value. The default
991: value for tilde-expansion is t.
992: These functions do tilde expansion: If I've left any out, let
993: me know:
994: load, fasl, infile, outfile, fileopen, probef, cfasl, ffasl, chdir
995: sys:access, sys:unlink [these are new functions, see below]
996:
997: 2) liszt will remove its temporary file if given a SIGTERM signal
998: (SIGTERM is sent by default when you give the kill command from the shell)
999:
1000: 3) load will now print a helpful message if an read error occurs when it
1001: is reading a file.
1002:
1003: 4) new functions:
1004:
1005: (lexpr-funcall 'function 'arg1 ... 'argn)
1006: This is a cross between funcall and apply.
1007: The last argument, argn, must be a list (possibly empty).
1008: The element of list argn are stacked and then the function is
1009: funcalled.
1010: For example:
1011: (lexpr-funcall 'list 'a 'b 'c '(d e f))
1012: is the same as
1013: (funcall 'list 'a 'b 'c 'd 'e 'f)
1014:
1015: Also
1016: (lexpr-funcall 'list 'a 'b 'c nil)
1017: is the same as
1018: (funcall 'list 'a 'b 'c)
1019:
1020: (tilde-expand 'st_filename)
1021: returns: symbol whose pname is the filename, with a leading tilde
1022: expanded. if st_filename doesn't begin with a tilde, it
1023: just returns st_filename
1024:
1025: (username-to-dir 'st_name)
1026: returns: the home directory of the given user, if that user exists.
1027: Saves old information so doesn't have to keep searching
1028: the passwd file.
1029:
1030: Some low level system functions. These are listed here for completeness.
1031: The perform a function from the unix library (see the unix manual
1032: for details).
1033: (sys:getpwnam 'st_username)
1034: return passwd file info.
1035: (sys:access 'st_file 'x_mode)
1036: (sys:unlink 'st_file)
1037:
1038:
1039: Bug fixes:
1040: 1) patom will handle prinlevel and prinlength correctly.
1041: 2) it is now safe for an interpreted function to redefine itself.
1042: 3) the information return by 'evalframe' about a funcall'ed function
1043: is now correct.
1044:
1045:
1046:
1047:
1048:
1049:
1050: From jkf Mon Oct 25 14:57:00 1982
1051: Date: 25-Oct-82 14:56:25-PDT (Mon)
1052: From: jkf (John Foderaro)
1053: Subject: 'if' macro: request for comments
1054: Message-Id: <[email protected]>
1055: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1056: id A21567; 25-Oct-82 14:57:00-PDT (Mon)
1057: To: local-lisp
1058: Status: RO
1059:
1060: Would anyone object if we added a macro called 'if' to the default franz
1061: system? 'if' is a common name and I want to make sure that it doesn't
1062: break any existing code before I add it.
1063:
1064: Some background:
1065: At mit the 'if' macro is used all over the place.
1066: Its form is
1067: (if <predicate> <then-expr> [ <else-expr>])
1068:
1069: I've always felt that macros should make the code more readable and
1070: that the 'if' macro makes code more obscure because it isn't easy
1071: to tell in complicated 'if' expressions where the <then-expr>
1072: and <else-expr>'s begin. Also, there is no provision for
1073: an 'elseif' expression.
1074:
1075: I wrote a macro called 'If' which uses keywords to separate clauses.
1076: (If <pred>
1077: then <then-expr>
1078: [elseif <pred> then <then-expr>]*
1079: [else <else-expr>])
1080:
1081: These two macros are not incompatible. one macro could do the job
1082: of both. There is an ambigous case:
1083: (if p then x) could be (cond (p then) (t x))
1084: or (cond (p x))
1085: but it isn't likely that 'if' macro users would write something like
1086: that.
1087:
1088: Thus I propose that we add a macro, if, which act's like 'If' if
1089: its second arg is 'then' or like 'if' it the second arg is not 'then'
1090: and there are two or three arguments. Other cases would cause
1091: an error.
1092:
1093:
1094:
1095:
1096:
1097: From jkf Mon Oct 25 22:37:24 1982
1098: Date: 25-Oct-82 22:37:09-PDT (Mon)
1099: From: jkf (John Foderaro)
1100: Subject: opus 38.36
1101: Message-Id: <[email protected]>
1102: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1103: id A01666; 25-Oct-82 22:37:24-PDT (Mon)
1104: To: local-lisp
1105: Status: RO
1106:
1107: I've added the 'if' macro to franz. If you have any objections, it is still
1108: not too late to voice them.
1109: I've also defined 'If' to be the same as 'if'.
1110:
1111: As I mentioned in my earlier request for comments, the 'if' macro is a
1112: cross between the mit version and a locally written version using keywords.
1113: The following documentation describes the various forms.
1114: As you know, you can test out the 'if' macro by using apply. for example:
1115:
1116: => (apply 'if '(if a then b c elseif d thenret else e))
1117: (cond (a b c) (d) (t e))
1118:
1119:
1120: ;
1121: ; This macro is compatible with both the crufty mit-version and
1122: ; the keyword version at ucb.
1123: ;
1124: ; simple summary:
1125: ; non-keyword use:
1126: ; (if a b) ==> (cond (a b))
1127: ; (if a b c d e ...) ==> (cond (a b) (t c d e ...))
1128: ; with keywords:
1129: ; (if a then b) ==> (cond (a b))
1130: ; (if a thenret) ==> (cond (a))
1131: ; (if a then b c d e) ==> (cond (a b c d e))
1132: ; (if a then b c else d) ==> (cond (a b c) (t d))
1133: ; (if a then b c elseif d thenret else g)
1134: ; ==> (cond (a b c) (d) (t g))
1135: ;
1136: ;
1137: ;
1138: ;
1139: ; In the syntax description below,
1140: ; optional parts are surrounded by [ and ],
1141: ; + means one or more instances.
1142: ; | means 'or'
1143: ; <expr> is an lisp expression which isn't a keyword
1144: ; The keywords are: then, thenret, else, elseif.
1145: ; <pred> is also a lisp expression which isn't a keyword.
1146: ;
1147: ; <if-stmt> ::= <simple-if-stmt>
1148: ; | <keyword-if-stmt>
1149: ;
1150: ; <simple-if-stmt> ::= (if <pred> <expr>)
1151: ; | (if <pred> <expr> <expr>)
1152: ;
1153: ; <keyword-if-stmt> ::= (if <pred> <then-clause> [ <else-clause> ] )
1154: ;
1155: ; <then-clause> ::= then <expr>+
1156: ; | thenret
1157: ;
1158: ; <else-clause> ::= else <expr>+
1159: ; | elseif <pred> <then-clause> [ <else-clause> ]
1160:
1161:
1162:
1163:
1164:
1165:
1166: From jkf Tue Oct 26 09:20:25 1982
1167: Date: 26-Oct-82 09:20:04-PDT (Tue)
1168: From: jkf (John Foderaro)
1169: Subject: no more jkfmacs
1170: Message-Id: <[email protected]>
1171: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1172: id A11552; 26-Oct-82 09:20:25-PDT (Tue)
1173: To: local-lisp
1174: Status: RO
1175:
1176:
1177: Since Franz now has the push, pop, if and msg macros, there is no
1178: reason for jkfmacs to exist. I've removed the code in jkfmacs and
1179: replaced it with a warning message which will be printed if you load it.
1180: If you used the jkfmacs version of 'push' you will have to go through
1181: your code and switch the order of arguments. The Franz version is
1182: (push value stack)
1183: Also, the unpush macro, defined in jkfmacs, no longer exists: just use
1184: pop with one argument.
1185:
1186:
1187:
1188: From jkf Wed Oct 27 20:35:07 1982
1189: Date: 27-Oct-82 20:34:25-PDT (Wed)
1190: From: jkf (John Foderaro)
1191: Subject: liszt 8.16
1192: Message-Id: <[email protected]>
1193: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1194: id A27561; 27-Oct-82 20:35:07-PDT (Wed)
1195: To: local-lisp
1196: Status: RO
1197:
1198: Back on May 6, a modification to liszt was made which turned 'declare'
1199: into a user callable function which provided information to the compiler.
1200: The purpose of the change was to permit one to 'load' a file containing
1201: declarations, instead of 'include'ing it. It turns out that this was a bad
1202: idea since if the compiler were to evaluate an interpreted function with
1203: local declarations, it would assume that those local declarations were
1204: describing the current file being compiled.
1205: Thus declare has it old meaning: it is a no-op unless the compiler is
1206: compiling the form. If one really wants to actively declare something,
1207: we've added the function 'liszt-declare', which looks just like declare
1208: but can be evaluated within the compiler.
1209:
1210: If you are confused by all this, don't worry. There is very little chance
1211: that it will affect you.
1212:
1213:
1214:
1215: From jkf Fri Oct 29 09:34:11 1982
1216: Date: 29-Oct-82 09:33:59-PDT (Fri)
1217: From: jkf (John Foderaro)
1218: Subject: cmacros
1219: Message-Id: <[email protected]>
1220: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1221: id A08411; 29-Oct-82 09:34:11-PDT (Fri)
1222: To: local-lisp
1223: Status: RO
1224:
1225: A week ago, Joe Faletti mentioned that one problem with cmacros is that if
1226: you redefine a function, the cmacro property stays around and thus the
1227: redefinition of the function isn't communicate to the compiler.
1228: He suggested that whenever a function is defined (via 'def' or when fasl'ed
1229: in) any cmacro properties should be remprop'ed. I've been trying to think
1230: of an alternative to this, but I can't think of one. Unless someone
1231: has a better idea, I'll implement his suggestion.
1232: This means that if you want to define the function 'foo' and a cmacro for
1233: 'foo', the cmacro definition must appear later in the file than 'foo's
1234: definition.
1235:
1236:
1237:
1238:
1239: From jkf Fri Oct 29 10:11:36 1982
1240: Date: 29-Oct-82 10:10:54-PDT (Fri)
1241: From: jkf (John Foderaro)
1242: Subject: LetS: An Expressional Loop Notation
1243: Message-Id: <[email protected]>
1244: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1245: id A09176; 29-Oct-82 10:11:36-PDT (Fri)
1246: To: local-lisp
1247: Status: RO
1248:
1249: I've got a copy of a paper by Richard Waters (at mit) describing a system
1250: for writing loops in lisp (and other languages). Basically you describe the
1251: loop in functional programming terms (similar to Backus's FP, or apl) and
1252: the LetS package converts it into an iterative form for efficient execution
1253: in lisp.
1254: We don't have the LetS code here to play with, and we probably won't be
1255: able to get it for a while since our arpanet connection is hopelessly
1256: clogged for anything but tiny messages. However you might be interested in
1257: stopping by my office and looking at the paper.
1258:
1259:
1260:
1261:
1262: From jkf Fri Oct 29 12:06:47 1982
1263: Date: 29-Oct-82 12:06:08-PDT (Fri)
1264: From: jkf (John Foderaro)
1265: Subject: Re: cmacros
1266: Message-Id: <[email protected]>
1267: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1268: id A12141; 29-Oct-82 12:06:47-PDT (Fri)
1269: To: baden, local-lisp
1270: In-Reply-To: Your message of 29 Oct 1982 1159-PDT (Friday)
1271: Status: RO
1272:
1273: I could make it a 'Note'. I would prefer not to make it a warning because
1274: such redefinition is guaranteed to occur when the compiler compiles itself
1275: and the lisp code part of the lisp system.
1276:
1277:
1278:
1279: From fateman Sat Oct 30 09:17:49 1982
1280: To: franz-friends
1281: Subject: fugue # 2
1282: Status: RO
1283:
1284: FUGUE Notes
1285:
1286: An occasional publication of the
1287: Franz Lisp User Group under Unix and Eunice (FUGUE)
1288:
1289: Number 2 (October, 1982)
1290: edited by Richard J. Fateman
1291: University of California
1292: Berkeley CA 94720
1293: USA
1294: fateman@berkeley
1295:
1296: 1. Welcome!
1297:
1298: It seems about time to publish the second of these
1299: newsletters, since we have accumulated a number of new
1300: items. We would also like to relay to others such informa-
1301: tion as has been forwarded to us. The reports of projects at
1302: Berkeley (and elsewhere) may strike sympathetic chords with
1303: other research.
1304:
1305: 2. New programs
1306:
1307: 2.1. OPS-5
1308:
1309: OPS-5 is a "production system" written by Charles Forgy
1310: of CMU. It appears to work just fine in Franz, and is in
1311: wide use. Interested persons may obtain copies of documen-
1312: tation and the program from Charles.Forgy@CMU-10A. ( Charles
1313: Forgy, Computer Science Department, Carnegie-Mellon Univer-
1314: sity, Pittsburgh, PA 15213)
1315:
1316: It is their policy to send it to anyone who wants it free of
1317: charge.
1318:
1319: 2.2. GLISP
1320:
1321: GLISP is a system which provides interesting linguistic
1322: features for generic operations and data abstraction. Writ-
1323: ten by Gordon Novak at Stanford University, it was origi-
1324: nally developed for Interlisp, but has been ported to other
1325: lisps, including Franz.
1326:
1327: 2.3. Flavors
1328:
1329: There are now two distinct implementations, apparently
1330: with identical functionally, of "flavors" as appearing in
1331: the MIT Lisp Machine software. One is described in TR-1174,
1332: ____________________
1333: 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
1334: SRI Int'l, and Univ. of Calif.
1335:
1336:
1337:
1338: 9
1339:
1340:
1341:
1342:
1343:
1344:
1345:
1346:
1347:
1348:
1349: "Franz Flavors" by Richard J. Wood (Dept of C.S., Univ. of
1350: Maryland, College Pk, MD 20742). The other was written by
1351: Juan R. Loaiza of MIT, Laboratory for Computer Science. We
1352: have a copy of the latter on-line here, and expect to
1353: receive a copy of the Maryland one, shortly. Eric Cooper
1354: here at Berkeley is in charge of the flavors situation.
1355:
1356: There is an implementation of closures, mostly compati-
1357: ble with the Lisp Machine specification, announced by John
1358: Foderaro for Opus 38.33. The incompatibility is a result of
1359: what we perceive to be a high performance penalty for eso-
1360: terica.
1361:
1362: 2.4. Database Interfaces
1363:
1364: Jim Larus at UCB has cooked up interfaces to both the
1365: INGRES relational database system, and the simpler TROLL
1366: database system. These will be described in his forthcoming
1367: MS report, along with the next item.
1368:
1369: 2.5. Cursor-control and Menus
1370:
1371: Larus has provided an implementation of screen manage-
1372: ment which uses the UNIX "curses" package for primitive win-
1373: dow management. A menu-based interface has also been
1374: developed as part of this.
1375:
1376: 2.6. Vaxima and Algebraic Manipulation
1377:
1378: A new version of vaxima, the VAX version of the MACSYMA
1379: algebraic manipulation system, was released in July by UCB,
1380: incorporating some bug fixes, improved programs, and a large
1381: number of user-contributed subroutine libraries. This was
1382: made available to test-site licensees. Unfortunately, MIT
1383: has suspended new test-site licensing since about April,
1384: 1982. We hope that MIT will be liberalizing its distribu-
1385: tion policy to non-commercial sites.
1386:
1387: See the note below about MACSYMA being sold.
1388:
1389: As a counterpoint to this, UC Berkeley has received a
1390: substantial grant from the System Development Foundation for
1391: work on Mathematical Representation and Manipulation, which
1392: should result in some more advanced systems for application
1393: of computers to symbolic mathematics. Recruiting for
1394: researchers, staff, and students is underway now, and
1395: interested persons should contact Richard Fateman.
1396:
1397: 2.7. VLSI Design Rule Checker
1398:
1399: Lyra, written in Lisp by Michael Arnold, is a retarget-
1400: able, hierarchical, design rule checker for VLSI circuits.
1401: Lyra features a rule compiler (also written in Lisp of
1402:
1403:
1404:
1405:
1406:
1407:
1408:
1409:
1410:
1411:
1412:
1413:
1414:
1415: course!) which translates symbolic design rule descriptions
1416: to lisp code for checking the rules. Lyra was used for the
1417: RISC project. It is currently being used extensively at
1418: Berkeley, and will be included in the Fall-82 distribution
1419: of of the Berkeley CAD tools. For more information contact
1420: Michael Arnold or John Ousterhout at Berkeley.
1421:
1422: 2.8. Generic Arithmetic
1423:
1424: As a proposed extension to Franz arithmetic, Richard
1425: Fateman, Keith Sklower and Scott Morrison, have written a
1426: simple-minded generic arithmetic package which includes
1427: modules which can be loaded to support exact rational arith-
1428: metic, software-simulated IEEE extended arithmetic, arbi-
1429: trary precision floating point, complex, interval, and mul-
1430: tivariate polynomial. Combinations of some of these are sup-
1431: ported, although the package is as yet incomplete in some
1432: areas. The IEEE arithmetic simulation is written in C.
1433: These packages are probably not in good enough shape for
1434: casual use by others.
1435:
1436:
1437: 3. New features
1438:
1439: Various performance enhancements and bug fixes have
1440: been incorporated in versions of Franz (now on Opus 38.33
1441: and the compiler, Liszt 8.14) These are mentioned in brief
1442: here; more details accompany updates of the system and
1443: manual included in the forthcoming Berkeley 4.2BSD UNIX dis-
1444: tribution.
1445:
1446: 3.1. Franz
1447:
1448: We added a switch to cause the evaluator to save macro
1449: expansions so they need only be expanded once.
1450:
1451: We added vector and vector-immediate data types.
1452:
1453: We rewrote showstack and backtrace so they are easier
1454: to use.
1455:
1456: We made the lisp to foreign function interface more
1457: secure. The system now allows foreign function to call lisp
1458: functions.
1459:
1460: We added closures and support flavors, features from
1461: the Lisp Machine.
1462:
1463: 3.2. Liszt
1464:
1465: Liszt will check the number of arguments to system
1466: functions and user defined functions.
1467: 9
1468:
1469: 9
1470:
1471:
1472:
1473:
1474:
1475:
1476:
1477:
1478:
1479:
1480: Liszt supports local declarations.
1481:
1482: Liszt will automatically compile lambda expressions
1483: headed by the function `function'.
1484:
1485: Liszt supports compiler-only macros and will autoload
1486: macros if necessary.
1487:
1488: 4. MC68000
1489:
1490: Keith Sklower and Kevin Layer have been working on the
1491: MC68000 version of Franz under the UNIX operating system
1492: (using a DUAL System 83). While the current configuration is
1493: a swapping system, the Lisp should be able to use the full
1494: address space of the CPU. We expect to have this system run-
1495: ning on the UNIX 4.2 BSD SUN software, too. The base system
1496: on the DUAL, including the interpreter, reader, bignums,
1497: fasl, works; the compiler is being perfected.
1498:
1499:
1500: 5. Other Lisps
1501:
1502: We now have, in-house tried 4 (other) VAX UNIX lisp
1503: systems: YLISP, Interlisp, PSL, and VLISP. We know that
1504: Interlisp can run also on VMS using the Eunice package.
1505: Interested parties can contact David Dyer at USC-ISI. There
1506: is also a version of lisp which runs on VMS only, namely
1507: NIL, from MIT, which appears to be undergoing limited dis-
1508: tribution. Two other lisps under development under UNIX are
1509: Yale's answer to NIL, namely "T", and Common Lisp, from CMU
1510: and friends.
1511:
1512: Counting Franz, that makes 7 lisp systems for the VAX
1513: computer line. Not counting variants on 2 operating systems.
1514: A Paen to standardization.
1515:
1516: Dick Gabriel states some useful principles for com-
1517: parisons in the conference record of the 1982 ACM Lisp and
1518: Functional Programming Conference, which was held in August.
1519: We understand he now has a collection of some 18 programs
1520: which he is continuing to time on various systems.
1521:
1522: 6. Work in Progress
1523:
1524: 6.1. BITGRAPH SUN AED-512
1525:
1526: Greg Foster at UCB is working on raster-graphics sup-
1527: port in Franz for the 800 by 1000 b/w raster displays of the
1528: BBN Bitgraph and/or the SUN Workstation, and possibly the
1529: color 512 by 512 AED system. We are probably going to han-
1530: dle mice and Bitpad (stylus) input for pointing. There are
1531: lots of projects we hear about with similar systems, e.g.
1532: just recently from the University of Maryland, using UNIX
1533:
1534:
1535:
1536:
1537:
1538:
1539:
1540:
1541:
1542:
1543:
1544:
1545:
1546: and multiplexed files for window management of a 68000-based
1547: home-grown workstation.
1548:
1549: 6.2. RISC-LISP
1550:
1551: Yes, Reduced Instruction Set Computer fans, who else
1552: but UCB would be so bold... Carl Ponder is examining the
1553: issues involved in constructing a fast lisp interpreter and
1554: compiler for the RISC architecture. You see, we have all
1555: these chips...
1556:
1557:
1558: 7. Work Contemplated
1559:
1560: 7.1. Fast Number Compiler
1561:
1562: Undergraduate Jeff Cohen at Berkeley is starting to
1563: look at this. There are several industrial concerns that
1564: have expressed interest in using such a system, but expected
1565: it to be subsidized by someone else.
1566:
1567: 7.2. IBM Franz
1568:
1569: Even more nibbles on this one, but not yet.
1570:
1571: 8. Business News
1572:
1573: 8.1. Eunice SOLD
1574:
1575: Some of you may have heard that the Eunice software
1576: package was sold by SRI to the Wollongong Group, a UNIX sup-
1577: port group in Palo Alto. Prices range from $2k (educa-
1578: tional) to $5k (commercial). Naturally this package is of
1579: interest beyond the availability of Franz Lisp. We have not
1580: compared this product to other similar ones, but we know
1581: that TWG has been distributing a working Franz opus 38.
1582:
1583: As far as alternatives to Eunice, we are aware of a
1584: system developed at Rice University, and another by Human
1585: Computing Resources (HCR) in Toronto. We have not
1586: evaluated either of these.
1587:
1588: 8.2. MACSYMA SOLD
1589:
1590: MIT has sold exclusive rights to MACSYMA, a large alge-
1591: braic manipulation system, to Symbolics, Inc. of Cambridge
1592: Mass. This package runs in Franz Lisp, (among other Lisps)
1593: We hope that soon it will again be available to educational
1594: institutions with VAX systems either from us or Symbolics,
1595: at a nominal charge. We understand that commercial licenses
1596: (from Symbolics) for versions of MACSYMA on PDP-10s, Lisp
1597: Machines, etc. will distributed at non-nominal prices and
1598: offered with maintenance contracts.
1599:
1600:
1601:
1602:
1603:
1604:
1605:
1606: From liz.umcp-cs@UDel-Relay Mon Nov 1 17:43:52 1982
1607: Date: 29 Oct 82 12:04:24 EDT (Fri)
1608: From: Liz Allen <liz.umcp-cs@UDel-Relay>
1609: Subject: Re: Flavor system
1610: To: ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc
1611: Cc: randy.umcp-cs at UDel-Relay
1612: In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley
1613: Via: UMCP-CS; 30 Oct 82 5:40-EDT
1614: Status: RO
1615:
1616: Date: 25 October 1982 16:29-EDT
1617: From: ECC@MIT-MC@Berkeley
1618: Subject: Flavor system
1619: To: FRANZ-FRIENDS at MIT-MC
1620:
1621: Can someone give me a pointer to the Franz flavor system
1622: developed by U. Maryland? I am looking for information on how to
1623: FTP the files -- what machine, whether public, what files, etc.
1624:
1625: Since the U. of Maryland is not (yet) an Arpanet host, you can't
1626: FTP files directly from here. We are right now completing some
1627: documentation for all of our hacks -- including documentation for
1628: some recent improvements for our flavors system. When that
1629: documentation is complete, we will be ready to distribute the
1630: packages developed here. Besides flavors, this includes a top
1631: level called userexec which is based on INTERLISP's top level and
1632: a production system called YAPS similar to but more flexible than
1633: OPS5.
1634:
1635: We are supposed to become an Arpanet host in a few months... (Read
1636: open ended period of time.) Meanwhile, if you would like to get
1637: our code, mail me a tape, and I will mail it back with the code and
1638: documentation on it. I'd appreciate it if someone would volunteer
1639: to let other folks FTP the files from their machine until we do
1640: become an Arpanet host. My address is:
1641:
1642: Liz Allen
1643: Univ of Maryland
1644: Dept of Computer Science
1645: College Park MD 20783
1646: (301) 454-4247
1647: liz.umcp-cs@udel-relay
1648:
1649: -Liz
1650:
1651:
1652:
1653: From jkf Wed Nov 3 15:49:29 1982
1654: Date: 3-Nov-82 15:48:50-PST (Wed)
1655: From: jkf (John Foderaro)
1656: Subject: lisp opus 38.40
1657: Message-Id: <[email protected]>
1658: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1659: id A16460; 3-Nov-82 15:49:29-PST (Wed)
1660: To: local-lisp
1661: Status: RO
1662:
1663: putprop will now put new properties at the head of the property list.
1664:
1665:
1666:
1667:
1668: From ecc@UCBARPA Thu Nov 4 10:28:49 1982
1669: Date: 4-Nov-82 10:19:26-PST (Thu)
1670: From: ecc@UCBARPA (Eric C. Cooper)
1671: Subject: Lisp song
1672: Message-Id: <[email protected]>
1673: Received: by UCBARPA.BERKELEY.ARPA (3.224 [10/16/82])
1674: id A24537; 4-Nov-82 10:19:28-PST (Thu)
1675: Received: from UCBARPA.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1676: id A00305; 4-Nov-82 10:28:49-PST (Thu)
1677: To: local-lisp@kim
1678: Status: O
1679:
1680: [This has been forwarded from uucp through Xerox through info-lispm.]
1681:
1682: >From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
1683:
1684: Another Glitch in the Call
1685: ------- ------ -- --- ----
1686: (Sung to the tune of a recent Pink Floyd song.)
1687:
1688:
1689: We don't need no indirection
1690: We don't need no flow control
1691: No data typing or declarations
1692: Hey! Did you leave the lists alone?
1693:
1694: Chorus:
1695: All in all, it's just a pure-LISP function call.
1696:
1697: We don't need no side effect-ing
1698: We don't need no scope control
1699: No global variables for execution
1700: Hey! Did you leave those args alone?
1701:
1702: (Chorus)
1703:
1704: We don't need no allocation
1705: We don't need no special nodes
1706: No dark bit-flipping in the functions
1707: Hey! Did you leave the bits alone?
1708:
1709: (Chorus)
1710:
1711: We don't need no compilation
1712: We don't need no load control
1713: No link edit for external bindings
1714: Hey! Did you leave that source alone?
1715:
1716: (Chorus, and repeat)
1717:
1718: From jkf Sat Nov 13 20:53:41 1982
1719: Date: 13-Nov-82 20:53:16-PST (Sat)
1720: From: jkf (John Foderaro)
1721: Subject: lisp opus 38.41
1722: Message-Id: <[email protected]>
1723: Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82])
1724: id A00490; 13-Nov-82 20:53:41-PST (Sat)
1725: To: local-lisp
1726: Status: O
1727:
1728: added functions:
1729: (remq 'g_val 'l_list) - just like remove but uses eq instead of equal
1730: (command-line-args) - returns a list of the command line arguments
1731: when lisp was started. This function will return
1732: only those arguments typed by the user, even if the
1733: lisp was started with the autorun feature (liszt -r).
1734: (sys:gethostname) - returns the name of the machine.
1735: (status domain) - returns 'ucb' here.
1736:
1737:
1738:
1739: From Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Sun Nov 28 08:38:06 1982
1740: Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST
1741: Date: 28 Nov 1982 11:47:28-EST
1742: From: Paul.Rosenbloom at CMU-CS-G at CMU-CS-A
1743: Subject: (random) problems
1744: Status: RO
1745:
1746: I am having two problems using (random) in Franz lisp. The first problem is
1747: that I can't find any way to set the seed. Every time I enter lisp, the
1748: generator is in the same state. I have had to resort to cfasling a c
1749: procedure that calls srand() (as (random) seems to be defined in c by a call
1750: on rand()). Is there a way to do this within lisp? The other problem is
1751: more serious. The generator seems to generate tight cycles for (at least)
1752: arguments that are small powers of 2. For example, repeatedly executing
1753: (random 2) yields the sequence 01010101..., and (random 4) yields
1754: 01230123.... These sequences apparently occur no matter to what value I set
1755: the seed. Does anyone one know what I could be doing wrong, or have a
1756: working random number generator?
1757:
1758:
1759: From tim.unc@UDel-Relay Sun Nov 28 20:44:24 1982
1760: Status: O
1761:
1762: From tim.unc@UDel-Relay Sun Nov 28 20:27:43 1982
1763: Date: 28 Nov 82 22:40:14 EST (Sun)
1764: From: Tim Maroney <tim.unc@UDel-Relay>
1765: Subject: rng
1766: To: franz-friends at Ucb-C70
1767: Via: UNC; 28 Nov 82 23:38-EST
1768: Status: O
1769:
1770: To the person who asked about random number generators and deficiencies
1771: in (random) [I can't write mail to you for some reason]:
1772:
1773: You're not doing anything wrong; that's the way the sucker works.
1774: One good way to get random numbers is to do the syscall that gets
1775: you the number of seconds since whenever-it-is, and use the mod
1776: function. This is especially good for getting a random one or zero,
1777: by using the evenp function.
1778:
1779: Tim Maroney
1780: tim@unc@udel-relay
1781:
1782:
1783: From jkf Tue Nov 30 09:21:10 1982
1784: Date: 30-Nov-82 09:21:10-PST (Tue)
1785: From: jkf (John Foderaro)
1786: Subject: opus 38.42
1787: Message-Id: <[email protected]>
1788: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1789: id AA11699; 30-Nov-82 09:21:10-PST (Tue)
1790: To: local-lisp
1791: Status: O
1792:
1793: added: (sys:link 'oldname 'newname) that what the ln program does.
1794:
1795: changed: the order of arguments to the vset functions is now:
1796: (vset 'vector 'index 'value).
1797:
1798: [This shouldn't affect anyone since vectors haven't been officially
1799: released yet and won't be until I make one more major modification]
1800:
1801: setf now knows about vectors. You can say
1802: (setf (vref 'vector 'index) 'value)
1803: and not have to worry about the order of arguments to vset.
1804:
1805:
1806:
1807: From jkf Tue Nov 30 10:42:00 1982
1808: Date: 30-Nov-82 10:42:00-PST (Tue)
1809: From: jkf (John Foderaro)
1810: Subject: Re: opus 38.42
1811: Message-Id: <[email protected]>
1812: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1813: id AA13143; 30-Nov-82 10:42:00-PST (Tue)
1814: To: jeffc, local-lisp
1815: In-Reply-To: Your message of 30 Nov 1982 1036-PST (Tuesday)
1816: Status: O
1817:
1818: It can't do symbolic links (I've only been adding system calls that I had
1819: a use for).
1820:
1821: setf is a generalized setq. The target can be an expression which locates
1822: a value. setf figures out how to store in the target.
1823: for example:
1824:
1825: (setf x 3) == (setq x 3)
1826: (setf (car x) 3) == (rplaca x 3)
1827: (setf (get foo 'bar) 3) == (putprop foo 3 'bar)
1828:
1829: the target must be something it has been 'taught' to understand, or it can
1830: be a macro, in which case setf macro-expands it and takes another look.
1831:
1832: The setf macro (and a list of targets it knows about is in
1833: /usr/lib/lisp/common2.l)
1834:
1835:
1836:
1837:
1838: From jkf@UCBKIM Wed Dec 1 09:13:23 1982
1839: Date: 1-Dec-82 09:13:03-PST (Wed)
1840: From: jkf@UCBKIM (John Foderaro)
1841: Subject: Random Numbers in Franz
1842: Message-Id: <[email protected]>
1843: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1844: id AA03615; 1-Dec-82 09:13:03-PST (Wed)
1845: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82])
1846: id A18406; 1-Dec-82 09:13:23-PST (Wed)
1847: To: franz-friends@berkeley
1848: Status: RO
1849:
1850: Date: 29-Nov-82 15:56:09-PST (Mon)
1851: From: alice!sola!mitch
1852: Subject: Random Numbers in Franz
1853: To: alice!ucbvax!franz-friends
1854:
1855: In general, it is very bad practice to compute a random number between 0
1856: and n by any expression such as (mod (random) n). In fact, Franz's
1857: random function does exactly that, returning the number generated by the
1858: C function rand(3) modulo n. This technique uses only the rightmost
1859: bits of successive calls to rand, and the righmost n bits of congruential
1860: sequences (like that returned by rand(3)) have a period of AT MOST 2**n
1861: (See Knuth vol.2 p. 12). So using the rightmost two bits will indeed give
1862: you sequences of at most period 4. (If your lisp doesn't have this
1863: behavior, you're not using the standard rand.)
1864:
1865: A better way to do it is to use the high order bits, by dividing the entire
1866: range up into n pieces and then seeing where you fall. (This method is
1867: biased if n is of the same order as the range, though.)
1868:
1869: The code I use is:
1870:
1871:
1872: (or (getd '$old-random) (putd '$old-random (getd 'random)))
1873:
1874: (defun random n
1875: (cond ((eq n 0) ($old-random))
1876: ((fix (quotient (boole 1 ($old-random) #o 7777777777)
1877: (quotient #o 7777777777 (arg 1)))))))
1878:
1879: Mitch Marcus
1880:
1881:
1882:
1883:
1884:
1885: From jkf Thu Dec 2 08:04:37 1982
1886: Date: 2-Dec-82 08:04:37-PST (Thu)
1887: From: jkf (John Foderaro)
1888: Subject: Franz Lisp distribution
1889: Message-Id: <[email protected]>
1890: Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82])
1891: id AA14414; 2-Dec-82 08:04:37-PST (Thu)
1892: To: franz-friends, net-lang-lisp@k
1893: Status: O
1894:
1895:
1896: Franz Lisp Distribution
1897:
1898: This note describes our distribution policy for Franz Lisp.
1899:
1900: What is being distributed:
1901: We distribute only source code in order to keep the distribution
1902: small and relatively Unix independent. Makefiles are provided to
1903: build the entire lisp system from source, even if you don't have
1904: a version of lisp running already. This process takes about 3 cpu
1905: hours on a Vax 780. [This version for the Vax only, a 68000 version
1906: is being worked on. Contact ucbkim.sklower@berkeley or
1907: ucbkim.layer@berkeley]
1908:
1909: The following source is provided:
1910: lisp interpreter,
1911: compiler (liszt),
1912: cross reference program (lxref),
1913: lisp manual,
1914: and other utility programs:
1915: trace, step, debug, cmu library functions, (and other minor ones),
1916: and these packages from the MIT lisp library:
1917: defstruct, loop, flavors.
1918: [These programs are provided as a convenience to those who can't
1919: access the arpanet and copy them. There is no documentation for
1920: them in the Franz Lisp manual. The best source of documentation
1921: is the Lisp Machine manual (available from MIT, Symbolics
1922: or LMI)]
1923:
1924: Regarding Flavors: there are two implementations of flavors for
1925: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
1926: and one from the University of Maryland (contact person
1927: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
1928: exactly like flavors on the Lisp Machine (due to differences between
1929: Lisp Machine lisp and Franz Lisp), and the implementations differ
1930: from each other. We incorporated the Mit version into the
1931: standard distribution because the high bandwidth between here and
1932: MIT will insure that it keeps up to date with the current Franz.
1933: This is not to imply that it is the better implementation.
1934: We haven't had enough experience with flavors to judge.
1935: Those seriously interested in Flavors should contact Liz
1936: Allen and ask for the Tech Report on the Univ Of Maryland Flavors
1937: system.
1938:
1939: What is the form of the distribution:
1940: The files are packaged in a giant (2.1Mbyte) shell script. Running this
1941: shell script through 'sh' will result in a directory tree. A ReadMe file
1942: in the current directory will contain instructions on building the lisp
1943: system. The shell script is broken into a number of smaller files.
1944: The current distribution looks like:
1945: % ls
1946: total 2092
1947: 195 opus38.40.aa 195 opus38.40.ae 195 opus38.40.ai
1948: 195 opus38.40.ab 195 opus38.40.af 195 opus38.40.aj
1949: 195 opus38.40.ac 195 opus38.40.ag 142 opus38.40.ak
1950: 195 opus38.40.ad 195 opus38.40.ah
1951:
1952: The '38.40' means Opus 38, minor version 40. These numbers may be different
1953: by the time you get your distribution. In order to extract the lisp
1954: files from this shell script, you need only type:
1955: cat * | sh
1956:
1957:
1958: To get a copy of the distribution:
1959: The distribution may be obtained either using FTP from an arpanet site,
1960: or on a magnetic tape through the U.S Mail.
1961:
1962: Arpanet:
1963: The files are stored on the ucb-c70 (NCP) arpanet host in the
1964: directory /users/lisp/lispuser. If you have an account on the ucb-c70,
1965: you are free to take FTP a copy of these files.
1966: If you do not have an account on the ucb-c70, send me (jkf@berkeley) a
1967: message and I will set up a temporary account for you.
1968: If you are on a TCP host, write me and we will set up an account on one
1969: of our Vax's for you to FTP the files. Eventually we will have an
1970: anonymous login on a TCP machine.
1971:
1972: Mag Tape:
1973: In order to get a copy of the distribution mailed to you, send a check to
1974: cover our tape copying and mailing costs (fees are listed below). We will
1975: purchase the mag tape and you are free to keep it. Please do NOT
1976: send us a tape.
1977:
1978: Fees:
1979: $50 - distribution tape mailed 3rd class
1980: add $10 - a copy of the Lisp Manual (we will only
1981: send one copy, you are free to photocopy it)
1982: add $7 - send tape via 1st class mail.
1983:
1984: -or-
1985: $15 - for just a copy of the Lisp Manual
1986:
1987: The address to send checks to is
1988:
1989: Keith Sklower
1990: EECS/Computer Science Division
1991: 524 Evans Hall
1992: University of California
1993: Berkeley, CA 94720
1994:
1995: All checks should be made out to "Regents, University of California."
1996: We require pre-payment. We will not invoice or process purchase orders.
1997:
1998:
1999:
2000: Disclaimers:
2001: This distribution works on the latest versions of Unix running at
2002: Berkeley (4.1a). We can't guarantee that it will work on older
2003: versions (although, if you are running 4.1, it is almost certain
2004: that it will work, but we have not verified it).
2005: VMS users who are using a typical Unix compatibility package will
2006: probably not be able to build a lisp from this distribution unless they
2007: know a great deal about VMS and their compatibility package.
2008: At least one package (Eunice) supports Franz at this time.
2009:
2010: Redistribution:
2011: If you get a copy of the distribution, you are free to give it to
2012: other people. We appreciate being informed of new sites so they
2013: can be put on a mailing list (electronic and conventional). This
2014: list is used to announce new releases. To be put on this list,
2015: send U.S. Mail to Keith Sklower (address above) or to
2016: franz-friends-request@berkeley or ucbvax!franz-friends-request
2017:
2018:
2019:
2020: From jkf Mon Dec 6 08:50:45 1982
2021: Date: 6-Dec-82 08:50:45-PST (Mon)
2022: From: jkf (John Foderaro)
2023: Subject: opus 38.43
2024: Message-Id: <[email protected]>
2025: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2026: id AA12951; 6-Dec-82 08:50:45-PST (Mon)
2027: To: local-lisp
2028: Status: O
2029:
2030: The size of vectors is now recorded in bytes rather than longwords.
2031: We've imported a few more commands to deal with fclosures.
2032: (symeval-in-fclosure 'fclosure 'symbol)
2033: (set-in-fclosure 'fclosure 'symbol 'value)
2034:
2035: (let-fclosed vars function)
2036:
2037:
2038:
2039:
2040: From jkf Mon Dec 13 10:35:43 1982
2041: Date: 13-Dec-82 10:35:43-PST (Mon)
2042: From: jkf (John Foderaro)
2043: Subject: enhancemants to trace
2044: Message-Id: <[email protected]>
2045: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2046: id AA12160; 13-Dec-82 10:35:43-PST (Mon)
2047: To: local-lisp
2048: Status: O
2049:
2050: The function 'retrace' will insure that all functions which should be
2051: traced are indeed traced. This will solve the problem of reloading
2052: a file whose functions are traced. After you load a file, you can
2053: type (retrace) and those functions which became untraced during the loading
2054: process, will be traced again.
2055:
2056: The top-level-print and top-level-read variables will now take effect
2057: within a trace break.
2058:
2059:
2060:
2061:
2062:
2063: From jkf Tue Dec 14 12:40:41 1982
2064: Date: 14-Dec-82 12:40:41-PST (Tue)
2065: From: jkf (John Foderaro)
2066: Subject: Re: #!, exec and lisp
2067: Message-Id: <[email protected]>
2068: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2069: id AA10379; 14-Dec-82 12:40:41-PST (Tue)
2070: To: lime!burdvax!puder
2071: Cc: franz-friends
2072: In-Reply-To: Your message of 13-Dec-82 14:03:23-PST (Mon)
2073: Status: O
2074:
2075: It is easy to make #! do a zapline. If you have a recent version of
2076: lisp, just execute:
2077:
2078: (defsharp ! (x) (zapline))
2079:
2080: (this could be put in your .lisprc, if you don't want to affect other
2081: people). The problem with adding this to Franz by default is that the
2082: sharpsign macro is shared by a number of lisps and few of them run under
2083: Unix. Therefore, few other lisps are going to want #! to be zapline.
2084:
2085:
2086: Regarding the -f switch: The -f switch is used to communicate between the
2087: bootstrap at the beginning of a fasl file and the lisp interpreter. It
2088: wasn't meant as a general 'fasl this file' switch for users to make use of.
2089: The choice of '-f' was bad, it should have been something more unique like
2090: '-- autorun' so that a user would be unlikely to type it. We have avoided
2091: assigning meanings to switches on lisp's command line because we want to give
2092: each user the opportunity to assign whatever meaning he wants to whatever
2093: switch he wants. It isn't difficult to write a program to scan the command
2094: line.
2095:
2096: Re:
2097: The (setq searchlist (cvtsearchpathtolist (getenv 'PATH))) would not be
2098: necessary, because the exec syscall supplies the full path name, because
2099: the shell has already done the path searching on the command name. The
2100: only place that might have to be searched is the current directory.
2101:
2102: This isn't true. (argv 0) is the command that you typed, not the full path
2103: name to the command. Only by prepending all the directories in the
2104: search list can you find the location of the command.
2105:
2106:
2107: ---john foderaro
2108:
2109:
2110:
2111: From jkf Mon Jan 10 15:04:02 1983
2112: Date: 10-Jan-83 15:04:02-PST (Mon)
2113: From: jkf (John Foderaro)
2114: Subject: opus 38.45
2115: Message-Id: <[email protected]>
2116: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2117: id AA19240; 10-Jan-83 15:04:02-PST (Mon)
2118: To: local-lisp
2119: Status: O
2120:
2121: showstack will again report correctly for compiled calls if the
2122: transfer tables are unlinked (status translink nil).
2123:
2124:
2125:
2126: From jkf Mon Jan 10 19:46:06 1983
2127: Date: 10-Jan-83 19:46:06-PST (Mon)
2128: From: jkf (John Foderaro)
2129: Subject: opus 38.46
2130: Message-Id: <[email protected]>
2131: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2132: id AA24831; 10-Jan-83 19:46:06-PST (Mon)
2133: To: local-lisp
2134: Status: O
2135:
2136: This version incorporates some fixes from mit. You shouldn't notice
2137: any differences but if you do, let me know.
2138:
2139:
2140:
2141:
2142:
2143: From jkf Wed Jan 12 09:03:32 1983
2144: Date: 12-Jan-83 09:03:32-PST (Wed)
2145: From: jkf (John Foderaro)
2146: Subject: opus38.47
2147: Message-Id: <[email protected]>
2148: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2149: id AA01981; 12-Jan-83 09:03:32-PST (Wed)
2150: To: local-lisp
2151: Status: O
2152:
2153: The setf macro will now handle all car and cdr forms (i.e. c{ad}+r).
2154: Thanks to peter norvig for this.
2155:
2156: There is a new macro called 'defvar'. It is used to declare special
2157: variables and optionally to give them an initial value. It is used
2158: at top level in a file (outside of defuns).
2159:
2160: forms:
2161: (defvar foo) ; declares foo to be special
2162: (defvar bar 3) ; declares bar to be special and when this file is read in
2163: ; bar will be given the value 3 if it is unbound.
2164: An advantage of '(defvar foo)' over '(declare (special foo))' is that if
2165: a file containing defvars is loaded (or fasl'ed) in during compilation,
2166: the variables mentioned in the defvar's will be declared special. The only
2167: way to have that effect with '(declare (special foo))' is to 'include'
2168: the file.
2169:
2170: There is a new macro, 'environment', which can be used at the beginning of
2171: a file to specify what sort of environment this file needs in order to be
2172: compiled or run. For example:
2173: (environment (compile eval) (files mymacros othermacros)
2174: (compile) (syntax maclisp))
2175:
2176: says that when compiling or loading into the interpreter, the files
2177: mymacros and othermacros should be loaded (if they aren't loaded already).
2178: When compiling, the maclisp syntax should be used.
2179: The general form of 'environment' is:
2180: (environment when1 what1
2181: when2 what2
2182: ... ...
2183: whenN whatN)
2184: the when's are a subset of (eval compile load), and the symbols have the
2185: same meaning as they do in 'eval-when'.
2186: The what's are either
2187: (files file1 file2 ... fileN)
2188: insure that the named files are loaded. To see if fileX
2189: is loaded, it looks for a 'version' property under
2190: fileX's property list. Thus to prevent multiple loading,
2191: you should put
2192: (putprop 'myfile t 'version) at the end of myfile.l
2193: (syntax type)
2194: type is either maclisp, intlisp, ucilisp, franzlisp
2195: This sets the syntax correctly.
2196:
2197: There are additional macros to set of standard environments:
2198: (environment-maclisp) sets up the maclisp environment. This is what
2199: you would get by using the -m switch to liszt.
2200:
2201: (environment-lmlisp) sets up the lisp machine environment. This is like
2202: maclisp but it has additional macros.
2203:
2204:
2205: It is possible to add when's and what's to the specialized environments,
2206: e.g.
2207: (environment-maclisp (compile eval) (files foo bar))
2208:
2209:
2210:
2211:
2212:
2213:
2214:
2215: From norvig Wed Jan 12 13:12:45 1983
2216: To: jkf local-lisp
2217: Subject: defvar
2218: Status: O
2219:
2220: Shouldn't defvar take any number of arguments, like setq? As it is,
2221: (defvar a 1 b 2) sets a to 1, but ignores the other arguments.
2222:
2223: From fateman Wed Jan 12 13:23:08 1983
2224: To: jkf local-lisp norvig
2225: Subject: Re: defvar
2226: Status: O
2227:
2228: I suspect the extra arguments to defvar are used in other systems for
2229: storage of documentation strings in appropriate places. E.g.
2230: (defvar dozen 12 "initially 12 except in the baker system when it is 13")
2231: causes some association with defvar and documentation should be put on
2232: a file.
2233:
2234:
2235: From jkf Wed Jan 12 14:25:02 1983
2236: Date: 12-Jan-83 14:25:02-PST (Wed)
2237: From: jkf (John Foderaro)
2238: Subject: Re: defvar
2239: Message-Id: <[email protected]>
2240: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2241: id AA13079; 12-Jan-83 14:25:02-PST (Wed)
2242: To: norvig, local-lisp
2243: In-Reply-To: Your message of 12 Jan 1983 1311-PST (Wednesday)
2244: Status: O
2245:
2246: fateman is correct that there is an optional third argument for
2247: documentation. We don't want to add multiple arguments because defvar
2248: it will mean that code we write here can't be transported to
2249: other lisp which only expect one defvar argument.
2250:
2251:
2252:
2253: From jkf Thu Jan 13 09:49:13 1983
2254: Date: 13-Jan-83 09:49:13-PST (Thu)
2255: From: jkf (John Foderaro)
2256: Subject: liszt 8.17
2257: Message-Id: <[email protected]>
2258: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2259: id AA00331; 13-Jan-83 09:49:13-PST (Thu)
2260: To: local-lisp
2261: Status: O
2262:
2263: The vector reference functions are open coded. These are
2264: vref, vrefi-byte, vrefi-word, vrefi-long
2265:
2266:
2267:
2268: From G:alpines Thu Jan 13 20:31:34 1983
2269: Date: 13 Jan 1983 20:24-PST
2270: From: alpines@G (Harry Weeks at Vax-Populi)
2271: Subject: Franz on 68000's
2272: Message-Id: <83/01/13 2024.733@Vax-Populi>
2273: Received: by UCBVAX.BERKELEY.ARPA (3.293 [1/9/83])
2274: id AA12970; 13-Jan-83 20:28:37-PST (Thu)
2275: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2276: id AA14908; 13-Jan-83 20:31:34-PST (Thu)
2277: To: franz@BERKELEY
2278: Cc: franz-friends@BERKELEY
2279: Status: O
2280:
2281: >Date: 13 Jan 1983 20:01-PST
2282: From: G.alpines at Berkeley (Harry Weeks at Vax-Populi)
2283: Subject: Franz on 68000's.
2284: To: franz-friends-request@Berkeley
2285: Message-Id: <83/01/13 2001.733@Vax-Populi>
2286:
2287: Please put me on your mailing list for information concerning
2288: implementation of Franz, esp. on 68000's, but I'd like to keep
2289: informed generally as well. Thanks.
2290:
2291: Harry Weeks
2292: Bytek
2293: 1730 Solano Avenue
2294: Berkeley, CA 94707
2295:
2296: (415) 527-1157
2297:
2298:
2299: From jkf Sun Jan 16 21:22:54 1983
2300: Date: 16-Jan-83 21:22:54-PST (Sun)
2301: From: jkf (John Foderaro)
2302: Subject: change to lisptags program
2303: Message-Id: <[email protected]>
2304: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2305: id AA23656; 16-Jan-83 21:22:54-PST (Sun)
2306: To: local-lisp
2307: Status: O
2308:
2309: lisptags will now surround the search string with /'s instead of ?'s
2310: in order to be compatible with ctags. Both types should work with vi,
2311: emacs people will probably have to make a minor modification to their
2312: tags.ml file.
2313: My version in ~jkf/elib/tags.ml.
2314:
2315:
2316:
2317:
2318:
2319:
2320: From jkf Tue Jan 18 16:43:23 1983
2321: Date: 18-Jan-83 16:43:23-PST (Tue)
2322: From: jkf (John Foderaro)
2323: Subject: lisp opus 38.48, liszt 8.19
2324: Message-Id: <[email protected]>
2325: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2326: id AA10935; 18-Jan-83 16:43:23-PST (Tue)
2327: To: local-lisp
2328: Status: O
2329:
2330: This is a long message so I'll put the most important thing first, in case
2331: you choose not to read the rest of the message:
2332: *** object files generated by liszt 8.19 will not run in any lisp
2333: *** older than 38.48. Object files which were generated by
2334: *** liszt's before 8.19 will continue to work in the new lisp.
2335:
2336:
2337: There were two major changes to lisp and liszt:
2338: 1) compiled functions will test at runtime to make sure that they
2339: are passed the correct number of arguments.
2340:
2341: 2) the lambda list keywords &optional, &rest and &aux are open compiled
2342: in an efficient manner.
2343:
2344: I'll refresh your memory on what the possible forms are for the & keywords:
2345:
2346: the formal parameter list of a def has this form
2347: ( required-args
2348: [ &optional optional-arguments ]
2349: [ &rest rest-argument ]
2350: [ &aux aux-arguments ])
2351:
2352: as in this example which shows all possible forms:
2353:
2354: (def foo
2355: (lambda (a b &optional c (d 23 d-p) (dd (bar)) &rest e &aux (f 12) g)
2356: (compute)))
2357:
2358:
2359: the meaning and forms of the various parts of the formal parameter list are:
2360:
2361: required-args: a sequence of n (zero or more) symbols which will be bound
2362: to the first n actual arguments.
2363:
2364: optional-args: a sequence of m (zero or more) symbols which will be
2365: bound to the next m actual arguments if they are present, or
2366: to default values.
2367: the forms of an optional argument are:
2368:
2369: foo - bind foo to the argument if it present, otherwise bind it
2370: to nil
2371: (foo (expr)) - bind foo to the argument if it is present, otherwise
2372: evaluate (expr) and bind foo to the result.
2373:
2374: (foo (expr) foo-p) - bind foo to the argument if it is present,
2375: otherwise evaluate (expr) and bind foo to the result.
2376: Also, bind foo-p to t if the argument is present, otherwise
2377: bind foo-p to nil. foo-p will be treated like an &aux
2378: variable (see below) but it should NOT be declared in the
2379: &aux list!
2380:
2381: rest-arg : a single symbol which will be bound to a list of the rest of the
2382: arguments. This list is cons'ed up each time the function is called.
2383:
2384: aux-args : these args are just like arguments to let or prog within the
2385: function body so this & keyword isn't really necessary (but there
2386: are few things in lisp that really are necessary).
2387:
2388: the forms of the aux arg are:
2389:
2390: foo - bind foo to nil
2391: (foo (expr)) - evaluate (expr) and bind foo to the result.
2392:
2393:
2394:
2395: The compiler understands the &keywords but the interpreter does not. 'def'
2396: will convert a form with &keywords to a lexpr which is almost equivalent.
2397: The differences are:
2398: The interpreted form, being a lexpr, is allowed to use the 'arg'
2399: function. The compiled form, even with optional args,
2400: is not a lexpr and thus 'arg' is illegal.
2401:
2402: The order that &aux variables are lambda bound is slightly different
2403: between interpreted and compiled code. As long as default
2404: expressions reference no formal parameters after them in the
2405: formal parameter list, there should be no problems.
2406:
2407: The interpreted version will not check for the correct number of
2408: arguments.
2409:
2410: Local functions cannot have &keywords.
2411:
2412: If you have any questions on this, send me mail. This change should
2413: only break functions which expect a variable number of argument and
2414: which don't declare the fact using &optional programs. There may be,
2415: of course, implementation errors. If you notice anything unusual
2416: please let me know right away. The old compiler will be
2417: in /usr/ucb/oliszt for a while.
2418:
2419:
2420:
2421:
2422:
2423:
2424:
2425:
2426:
2427: From layer Thu Jan 20 01:55:55 1983
2428: Date: 20-Jan-83 01:55:55-PST (Thu)
2429: From: layer (Kevin Layer)
2430: Subject: liszt 8.20
2431: Message-Id: <[email protected]>
2432: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2433: id AA17788; 20-Jan-83 01:55:55-PST (Thu)
2434: To: local-lisp
2435: Phone: (415) 652-2405
2436: Status: O
2437:
2438: There are now three new command line features for liszt:
2439:
2440: 1. -E <s-expr>, where <s-expr> will be evaluated before compilation
2441: starts. For example, the setting of constants can be done in this way:
2442:
2443: liszt -E '(setq foobar "***foobar-string***")' foobar.l
2444:
2445: and in the file being compiled, foobar is accessed as '#.foobar.
2446:
2447: 2. -I <include-file>, where <include-file> will be loaded (via load)
2448: before compilation starts.
2449:
2450: 3. A combination of the -S and -o switches will set the .s file, as in:
2451:
2452: liszt -S -o foo.vax.s foo.l
2453:
2454: where previously, the -S determined the name of the .s file (foo.s in
2455: the above example).
2456:
2457:
2458:
2459: From jkf Thu Jan 20 19:42:38 1983
2460: Date: 20-Jan-83 19:42:38-PST (Thu)
2461: From: jkf (John Foderaro)
2462: Subject: some mods to liszt 8.20
2463: Message-Id: <[email protected]>
2464: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2465: id AA07334; 20-Jan-83 19:42:38-PST (Thu)
2466: To: local-lisp
2467: Status: O
2468:
2469: the -E and -I flags are now -e and -i
2470: there may be more than one -i flag given on the command line.
2471:
2472:
2473:
2474: From fateman Thu Jan 20 20:20:31 1983
2475: To: local-lisp
2476: Subject: fame, if not fortune
2477: Status: RO
2478:
2479: In the latest Scientific American, Feb. 1983, Hofstader's column
2480: is the first of several on the programming language "lisp". He
2481: mentions the particular dialect he is using .... Franz !
2482:
2483: From wilensky Thu Jan 20 20:57:27 1983
2484: Date: 20-Jan-83 20:57:27-PST (Thu)
2485: From: wilensky (Robert Wilensky)
2486: Subject: Re: fame, if not fortune
2487: Message-Id: <[email protected]>
2488: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2489: id AA08824; 20-Jan-83 20:57:27-PST (Thu)
2490: To: fateman, local-lisp
2491: In-Reply-To: Your message of 20 Jan 1983 2019-PST (Thursday)
2492: Status: RO
2493:
2494:
2495: On the other hand, being referenced by Hofstader is a dubious honor.
2496:
2497:
2498: From UCBKIM:jkf Fri Jan 21 08:15:04 1983
2499: Date: 21-Jan-83 08:11:01-PST (Fri)
2500: From: UCBKIM:jkf (John Foderaro)
2501: Subject: test message, ignore
2502: Message-Id: <[email protected]>
2503: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2504: id AA18650; 21-Jan-83 08:11:01-PST (Fri)
2505: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2506: id AA24887; 21 Jan 83 08:09:27 PST (Fri)
2507: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2508: id AA18766; 21-Jan-83 08:15:04-PST (Fri)
2509: To: franz-friends@BERKELEY
2510: Status: O
2511:
2512: This will give our mailer a chance to tell me how many of our franz friends
2513: are no longer reachable.
2514:
2515:
2516:
2517: From JTSCHUDY@USC-ISIE Sat Jan 22 16:42:19 1983
2518: Date: 22 Jan 1983 1634-PST
2519: From: JTSCHUDY@USC-ISIE
2520: Subject: MAILINGLIST ADDITION
2521: Message-Id: <[email protected]>
2522: Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2523: id AA01747; 22 Jan 83 16:37:17 PST (Sat)
2524: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2525: id AA18903; 22-Jan-83 16:42:19-PST (Sat)
2526: To: franz-friends@BERKELEY
2527: Status: O
2528:
2529: Hi! My name is Jim. I am presently attending the Naval Post Graduate
2530: School in Monterey California. I am in the Air Force enrolled in a
2531: DOD sponsored graduate degree in Command Control and Communications
2532: Systems Technology.
2533:
2534: i would like to be added to your mailing list. My net address is
2535: JTSCHUDY at ISIE.
2536:
2537: Thanks - Jim.
2538: -------
2539:
2540:
2541: From jkf Sat Jan 22 17:38:41 1983
2542: Date: 22-Jan-83 17:38:41-PST (Sat)
2543: From: jkf (John Foderaro)
2544: Subject: opus 38.49
2545: Message-Id: <[email protected]>
2546: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2547: id AA20020; 22-Jan-83 17:38:41-PST (Sat)
2548: To: local-lisp
2549: Status: O
2550:
2551: A longstanding bug in the determination of the number of free dtpr objects
2552: has been found and fixed. The effect of this bug was that the function
2553: which is responsible for allocating more memory pages didn't allocate
2554: enough dtpr pages because it thought that there were a large number of
2555: cells free.
2556:
2557:
2558:
2559: From MCLINDEN@RUTGERS Mon Jan 24 10:33:14 1983
2560: Date: 24 Jan 1983 1324-EST
2561: From: Sean McLinden <MCLINDEN@RUTGERS>
2562: Subject: Franz Lisp and floating point accelerator
2563: Message-Id: <[email protected]>
2564: Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2565: id AA19602; 24 Jan 83 10:25:06 PST (Mon)
2566: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2567: id AA27143; 24-Jan-83 10:33:14-PST (Mon)
2568: To: franz-friends@UCBVAX
2569: Status: O
2570:
2571:
2572: Has anyone determined if a floating point accelerator speeds up
2573: Vax Franz Lisp jobs in any significant fashion?
2574:
2575: Pointers would be appreciated.
2576:
2577: Sean McLinden
2578: Decision Systems Lab
2579: -------
2580:
2581: From mike@rand-unix Mon Jan 24 18:47:03 1983
2582: Date: Monday, 24 Jan 1983 15:34-PST
2583: From: mike@RAND-UNIX
2584: Subject: emacs interface to franz?
2585: Message-Id: <[email protected]>
2586: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2587: id AA00058; 24 Jan 83 16:08:36 PST (Mon)
2588: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2589: id AA00921; 24-Jan-83 18:47:03-PST (Mon)
2590: To: franz-friends@BERKELEY
2591: Status: O
2592:
2593:
2594: Does anyone have a snazzy interface to emacs for franz?
2595:
2596: Thanks,
2597: Michael
2598:
2599:
2600: From @udel-relay.ARPA,@UDel-Relay:[email protected] Tue Jan 25 16:29:19 1983
2601: Date: 25 Jan 1983 9:58-EST
2602: From: Tim Finin <Tim.UPenn@UDel-Relay>
2603: Subject: emacs interface to franz?
2604: Message-Id: <[email protected]>
2605: Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2606: id AA29320; 25 Jan 83 16:22:57 PST (Tue)
2607: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2608: id AA01561; 25-Jan-83 16:29:19-PST (Tue)
2609: Return-Path: <[email protected]@UDel-Relay>
2610: To: mike@Rand-Unix
2611: Cc: franz-friends@BERKELEY
2612: Via: UPenn; 25 Jan 83 19:21-EST
2613: Status: O
2614:
2615:
2616: We have a simple interface from Franz to Emacs, but I much prefer to go the
2617: other way, i.e. run Franz as a inferior job under Emacs. I believe there
2618: are several Emacs packages which allow one to run inferior jobs in an Emacs
2619: window (I have my own which is, unfortunately totally undocumented). Some of
2620: the benefits of this set up include:
2621:
2622: - one has all of the text editing functions available in Emacs
2623: - one has many lisp-based editing functions available in Emacs
2624: (thru mock-lisp packages like electriclisp)
2625: - one has a history of the session in the editing buffer
2626: - one has an environment which supports multiple concurrent
2627: processes running in seperate windows.
2628: - it is very easy to experiment with new interface features such as
2629: symbol completion and re-evaluation of previously issued commands
2630:
2631: Tim
2632:
2633:
2634: From CARR@UTAH-20 Fri Jan 28 08:19:08 1983
2635: Date: 28 Jan 1983 0912-MST
2636: From: Harold Carr <CARR@UTAH-20>
2637: Subject: franz distribution
2638: Message-Id: <[email protected]>
2639: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2640: id AA20646; 28 Jan 83 08:15:18 PST (Fri)
2641: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2642: id AA16991; 28-Jan-83 08:19:08-PST (Fri)
2643: To: franz-friends@UCBVAX
2644: Status: O
2645:
2646: What is the distribution policy?
2647:
2648: I work for a company that has opus 36 and is now currently running opus 37.
2649: Here at the University of Utah we are running opus 38.04. Is it OK to
2650: make a tape of the University's 38.04 to bring my company more up to
2651: date? Do I have to make it more formal by signing a transfer agreement
2652: or by obtaining the release directly from Berkeley?
2653:
2654: Thanks in advance,
2655: Harold Carr
2656: CARR@UTAH-20
2657: -------
2658:
2659: From UCBKIM:jkf Fri Jan 28 15:09:32 1983
2660: Date: 28-Jan-83 08:34:33-PST (Fri)
2661: From: UCBKIM:jkf
2662: Subject: Re: franz distribution
2663: Message-Id: <[email protected]>
2664: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2665: id AA17319; 28-Jan-83 08:34:33-PST (Fri)
2666: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2667: id AA02275; 28 Jan 83 14:58:37 PST (Fri)
2668: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2669: id AA00402; 28-Jan-83 15:09:32-PST (Fri)
2670: To: CARR@UTAH-20
2671: Cc: franz-friends@UCBVAX
2672: In-Reply-To: Your message of 28 Jan 1983 0912-MST
2673: Status: O
2674:
2675: Here is our current distribution policy. This differs a bit from
2676: the one sent out a month ago [in particular, we now have anonymous ftp]
2677:
2678: -[Fri Jan 28 08:31:45 1983 by jkf]-
2679: Franz Lisp Distribution
2680:
2681: This note describes our distribution policy for Franz Lisp.
2682:
2683: What is being distributed:
2684: We distribute only source code in order to keep the distribution
2685: small and relatively Unix independent. Makefiles are provided to
2686: build the entire lisp system from source, even if you don't have
2687: a version of lisp running already. This process takes about 3 cpu
2688: hours on a Vax 780. [This version for the Vax only, a 68000 version
2689: is being worked on. Contact ucbkim.sklower@berkeley or
2690: ucbkim.layer@berkeley]
2691:
2692: The following source is provided:
2693: lisp interpreter,
2694: compiler (liszt),
2695: cross reference program (lxref),
2696: lisp manual,
2697: and other utility programs:
2698: trace, step, debug, cmu library functions, (and other minor ones),
2699: and these packages from the MIT lisp library:
2700: defstruct, loop.
2701: [These programs are provided as a convenience to those who can't
2702: access the arpanet and copy them. There is no documentation for
2703: them in the Franz Lisp manual. The best source of documentation
2704: is the Lisp Machine manual (available from MIT, Symbolics
2705: or LMI)]
2706:
2707: Regarding Flavors: there are two implementations of flavors for
2708: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
2709: and one from the University of Maryland (contact person
2710: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
2711: exactly like flavors on the Lisp Machine (due to differences between
2712: Lisp Machine lisp and Franz Lisp), and the implementations differ
2713: from each other. The MIT version cannot be distributed by
2714: us (yet) due to licensing problems. If you have a Lisp Machine
2715: Source license from Symbolics, you should be able to get a copy
2716: from MIT.
2717: For a Tech Report on Maryland flavors, write to Liz Allen.
2718:
2719: What is the form of the distribution:
2720: The files are packaged in a giant (2.1Mbyte) shell script. Running this
2721: shell script through 'sh' will result in a directory tree. A ReadMe file
2722: in the current directory will contain instructions on building the lisp
2723: system. The shell script is broken into a number of smaller files.
2724: The current distribution looks like:
2725:
2726: total 2089
2727: 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
2728: 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
2729: 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
2730: 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
2731: 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
2732:
2733: The '38.50' means Opus 38, minor version 50. These numbers may be different
2734: by the time you get your distribution. In order to extract the lisp
2735: files from this shell script, you need only type:
2736: cat * | sh
2737:
2738:
2739: To get a copy of the distribution:
2740: The distribution may be obtained either using FTP from an arpanet site,
2741: or on a magnetic tape through the U.S Mail.
2742:
2743: Arpanet:
2744: The files are stored on the arpanet host 'ucb-vax' [ if you have an out
2745: of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
2746: internet number is 10.2.0.78].
2747: You can login as 'anonymous'. Use your name as the password.
2748: The files are in the subdirectory pub/lisp.
2749:
2750: For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
2751:
2752: Mag Tape:
2753: In order to get a copy of the distribution mailed to you, send a check to
2754: cover our tape copying and mailing costs (fees are listed below). We will
2755: purchase the mag tape and you are free to keep it. Please do NOT
2756: send us a tape.
2757:
2758: Fees:
2759: $50 - distribution tape mailed 3rd class
2760: add $10 - a copy of the Lisp Manual (we will only
2761: send one copy, you are free to photocopy it)
2762: add $7 - send tape via 1st class mail.
2763:
2764: -or-
2765: $15 - for just a copy of the Lisp Manual
2766:
2767: The address to send checks to is
2768:
2769: Keith Sklower
2770: EECS/Computer Science Division
2771: 524 Evans Hall
2772: University of California
2773: Berkeley, CA 94720
2774:
2775: All checks should be made out to "Regents, University of California."
2776: We require pre-payment. We will not invoice or process purchase orders.
2777:
2778:
2779:
2780: Disclaimers:
2781: This distribution works on the latest versions of Unix running at
2782: Berkeley (4.1a). We can't guarantee that it will work on older
2783: versions (although, if you are running 4.1, it is almost certain
2784: that it will work, but we have not verified it).
2785: VMS users who are using a typical Unix compatibility package will
2786: probably not be able to build a lisp from this distribution unless they
2787: know a great deal about VMS and their compatibility package.
2788: At least one package (Eunice) supports Franz at this time.
2789:
2790: Redistribution:
2791: If you get a copy of the distribution, you are free to give it to
2792: other people. We appreciate being informed of new sites so they
2793: can be put on a mailing list (electronic and conventional). This
2794: list is used to announce new releases. To be put on this list,
2795: send U.S. Mail to Keith Sklower (address above) or to
2796: franz-friends-request@berkeley or ucbvax!franz-friends-request
2797:
2798:
2799:
2800: From Kim:fateman Sun Jan 30 02:12:28 1983
2801: Date: 28 Jan 83 08:32:08 PST (Fri)
2802: From: Kim:fateman (Richard Fateman)
2803: Subject: Re: franz distribution
2804: Message-Id: <[email protected]>
2805: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2806: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
2807: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2808: id AA10132; 30-Jan-83 02:12:28-PST (Sun)
2809: To: CARR@UTAH-20
2810: Cc: franz-friends@ucbvax
2811: Status: O
2812:
2813: Our policy is that you may move copies of Franz elsewhere
2814: without notifying us. We continue to be interested in sharing anything
2815: you or your company wish to provide us, in suggestions, programs, etc.
2816:
2817:
2818: From UCBCAD:pettengi Sun Jan 30 02:33:52 1983
2819: Date: 28-Jan-83 10:54:51-PST (Fri)
2820: From: UCBCAD:pettengi (Rob Pettengill)
2821: Subject: emacs interface to franz?
2822: Message-Id: <[email protected]>
2823: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
2824: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
2825: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2826: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
2827: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2828: id AA10578; 30-Jan-83 02:33:52-PST (Sun)
2829: To: mike@rand-unix, franz-friends@ucbvax
2830: Cc: pettengi@UCBCAD
2831: Status: O
2832:
2833: While I was at TI I used a very nice interface that let one start up
2834: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
2835: under our VMS. Try Kashtan@SRI-AI.
2836:
2837: Rob Pettengill
2838: E-Systems, Dallas, Tx.
2839:
2840: From UCBKIM:jkf Sun Jan 30 02:44:27 1983
2841: Date: 28-Jan-83 08:34:33-PST (Fri)
2842: From: UCBKIM:jkf (John Foderaro)
2843: Subject: Re: franz distribution
2844: Message-Id: <[email protected]>
2845: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2846: id AA17319; 28-Jan-83 08:34:33-PST (Fri)
2847: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2848: id AA02275; 28 Jan 83 14:58:37 PST (Fri)
2849: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2850: id AA10772; 30-Jan-83 02:44:27-PST (Sun)
2851: To: CARR@UTAH-20
2852: Cc: franz-friends@UCBVAX
2853: In-Reply-To: Your message of 28 Jan 1983 0912-MST
2854: Status: RO
2855:
2856: Here is our current distribution policy. This differs a bit from
2857: the one sent out a month ago [in particular, we now have anonymous ftp]
2858:
2859: -[Fri Jan 28 08:31:45 1983 by jkf]-
2860: Franz Lisp Distribution
2861:
2862: This note describes our distribution policy for Franz Lisp.
2863:
2864: What is being distributed:
2865: We distribute only source code in order to keep the distribution
2866: small and relatively Unix independent. Makefiles are provided to
2867: build the entire lisp system from source, even if you don't have
2868: a version of lisp running already. This process takes about 3 cpu
2869: hours on a Vax 780. [This version for the Vax only, a 68000 version
2870: is being worked on. Contact ucbkim.sklower@berkeley or
2871: ucbkim.layer@berkeley]
2872:
2873: The following source is provided:
2874: lisp interpreter,
2875: compiler (liszt),
2876: cross reference program (lxref),
2877: lisp manual,
2878: and other utility programs:
2879: trace, step, debug, cmu library functions, (and other minor ones),
2880: and these packages from the MIT lisp library:
2881: defstruct, loop.
2882: [These programs are provided as a convenience to those who can't
2883: access the arpanet and copy them. There is no documentation for
2884: them in the Franz Lisp manual. The best source of documentation
2885: is the Lisp Machine manual (available from MIT, Symbolics
2886: or LMI)]
2887:
2888: Regarding Flavors: there are two implementations of flavors for
2889: Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc))
2890: and one from the University of Maryland (contact person
2891: Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is
2892: exactly like flavors on the Lisp Machine (due to differences between
2893: Lisp Machine lisp and Franz Lisp), and the implementations differ
2894: from each other. The MIT version cannot be distributed by
2895: us (yet) due to licensing problems. If you have a Lisp Machine
2896: Source license from Symbolics, you should be able to get a copy
2897: from MIT.
2898: For a Tech Report on Maryland flavors, write to Liz Allen.
2899:
2900: What is the form of the distribution:
2901: The files are packaged in a giant (2.1Mbyte) shell script. Running this
2902: shell script through 'sh' will result in a directory tree. A ReadMe file
2903: in the current directory will contain instructions on building the lisp
2904: system. The shell script is broken into a number of smaller files.
2905: The current distribution looks like:
2906:
2907: total 2089
2908: 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa
2909: 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab
2910: 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac
2911: 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad
2912: 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae
2913:
2914: The '38.50' means Opus 38, minor version 50. These numbers may be different
2915: by the time you get your distribution. In order to extract the lisp
2916: files from this shell script, you need only type:
2917: cat * | sh
2918:
2919:
2920: To get a copy of the distribution:
2921: The distribution may be obtained either using FTP from an arpanet site,
2922: or on a magnetic tape through the U.S Mail.
2923:
2924: Arpanet:
2925: The files are stored on the arpanet host 'ucb-vax' [ if you have an out
2926: of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its
2927: internet number is 10.2.0.78].
2928: You can login as 'anonymous'. Use your name as the password.
2929: The files are in the subdirectory pub/lisp.
2930:
2931: For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp.
2932:
2933: Mag Tape:
2934: In order to get a copy of the distribution mailed to you, send a check to
2935: cover our tape copying and mailing costs (fees are listed below). We will
2936: purchase the mag tape and you are free to keep it. Please do NOT
2937: send us a tape.
2938:
2939: Fees:
2940: $50 - distribution tape mailed 3rd class
2941: add $10 - a copy of the Lisp Manual (we will only
2942: send one copy, you are free to photocopy it)
2943: add $7 - send tape via 1st class mail.
2944:
2945: -or-
2946: $15 - for just a copy of the Lisp Manual
2947:
2948: The address to send checks to is
2949:
2950: Keith Sklower
2951: EECS/Computer Science Division
2952: 524 Evans Hall
2953: University of California
2954: Berkeley, CA 94720
2955:
2956: All checks should be made out to "Regents, University of California."
2957: We require pre-payment. We will not invoice or process purchase orders.
2958:
2959:
2960:
2961: Disclaimers:
2962: This distribution works on the latest versions of Unix running at
2963: Berkeley (4.1a). We can't guarantee that it will work on older
2964: versions (although, if you are running 4.1, it is almost certain
2965: that it will work, but we have not verified it).
2966: VMS users who are using a typical Unix compatibility package will
2967: probably not be able to build a lisp from this distribution unless they
2968: know a great deal about VMS and their compatibility package.
2969: At least one package (Eunice) supports Franz at this time.
2970:
2971: Redistribution:
2972: If you get a copy of the distribution, you are free to give it to
2973: other people. We appreciate being informed of new sites so they
2974: can be put on a mailing list (electronic and conventional). This
2975: list is used to announce new releases. To be put on this list,
2976: send U.S. Mail to Keith Sklower (address above) or to
2977: franz-friends-request@berkeley or ucbvax!franz-friends-request
2978:
2979:
2980:
2981: From Kim:fateman Mon Jan 31 19:30:20 1983
2982: Date: 28 Jan 83 08:32:08 PST (Fri)
2983: From: Kim:fateman (Richard Fateman)
2984: Subject: Re: franz distribution
2985: Message-Id: <[email protected]>
2986: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
2987: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
2988: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
2989: id AA03502; 31-Jan-83 19:30:20-PST (Mon)
2990: To: CARR@UTAH-20
2991: Cc: franz-friends@ucbvax
2992: Status: O
2993:
2994: Our policy is that you may move copies of Franz elsewhere
2995: without notifying us. We continue to be interested in sharing anything
2996: you or your company wish to provide us, in suggestions, programs, etc.
2997:
2998:
2999: From UCBCAD:pettengi Mon Jan 31 19:55:02 1983
3000: Date: 28-Jan-83 10:54:51-PST (Fri)
3001: From: UCBCAD:pettengi (Rob Pettengill)
3002: Subject: emacs interface to franz?
3003: Message-Id: <[email protected]>
3004: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
3005: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
3006: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3007: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
3008: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3009: id AA03987; 31-Jan-83 19:55:02-PST (Mon)
3010: To: mike@rand-unix, franz-friends@ucbvax
3011: Cc: pettengi@UCBCAD
3012: Status: O
3013:
3014: While I was at TI I used a very nice interface that let one start up
3015: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
3016: under our VMS. Try Kashtan@SRI-AI.
3017:
3018: Rob Pettengill
3019: E-Systems, Dallas, Tx.
3020:
3021: From Kim:fateman Mon Jan 31 21:34:44 1983
3022: Date: 28 Jan 83 08:32:08 PST (Fri)
3023: From: Kim:fateman (Richard Fateman)
3024: Subject: Re: franz distribution
3025: Message-Id: <[email protected]>
3026: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3027: id AA21039; 28 Jan 83 08:31:58 PST (Fri)
3028: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3029: id AA00642; 31-Jan-83 21:34:44-PST (Mon)
3030: To: CARR@UTAH-20
3031: Cc: franz-friends@ucbvax
3032: Status: RO
3033:
3034: Our policy is that you may move copies of Franz elsewhere
3035: without notifying us. We continue to be interested in sharing anything
3036: you or your company wish to provide us, in suggestions, programs, etc.
3037:
3038:
3039: From UCBCAD:pettengi Mon Jan 31 22:12:30 1983
3040: Date: 28-Jan-83 10:54:51-PST (Fri)
3041: From: UCBCAD:pettengi (Rob Pettengill)
3042: Subject: emacs interface to franz?
3043: Message-Id: <[email protected]>
3044: Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82])
3045: id AA26156; 28-Jan-83 10:54:51-PST (Fri)
3046: Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3047: id AA00374; 28 Jan 83 12:53:44 PST (Fri)
3048: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3049: id AA01266; 31-Jan-83 22:12:30-PST (Mon)
3050: To: mike@rand-unix, franz-friends@ucbvax
3051: Cc: pettengi@UCBCAD
3052: Status: O
3053:
3054: While I was at TI I used a very nice interface that let one start up
3055: a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run
3056: under our VMS. Try Kashtan@SRI-AI.
3057:
3058: Rob Pettengill
3059: E-Systems, Dallas, Tx.
3060:
3061: From UCBKIM:jkf Tue Feb 1 10:35:21 1983
3062: Date: 1-Feb-83 10:32:24-PST (Tue)
3063: From: UCBKIM:jkf (John Foderaro)
3064: Subject: multiple messages
3065: Message-Id: <[email protected]>
3066: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3067: id AA00599; 1-Feb-83 10:32:24-PST (Tue)
3068: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3069: id AA00473; 1 Feb 83 10:32:35 PST (Tue)
3070: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3071: id AA00644; 1-Feb-83 10:35:21-PST (Tue)
3072: To: franz-friends@ucbvax
3073: Status: RO
3074:
3075: I'm sorry for the multiple messages. The franz-friends mailing list is
3076: huge and the machine which does the mailing is crashing often. Our local
3077: mail wizard informs me that if it crashes while in the middle of sending
3078: mail it will not have a record of who it sent to before the crash.
3079: I hope you don't get too many copies of this message.
3080:
3081:
3082:
3083:
3084:
3085: From mike@rand-unix Wed Feb 2 05:33:01 1983
3086: Date: Tuesday, 1 Feb 1983 15:06-PST
3087: From: mike@RAND-UNIX
3088: Subject: response to "emacs interface to franz?"
3089: Message-Id: <[email protected]>
3090: Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3091: id AA00221; 2 Feb 83 05:25:50 PST (Wed)
3092: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3093: id AA24463; 2-Feb-83 05:33:01-PST (Wed)
3094: To: franz-friends@BERKELEY
3095: Cc: mike@RAND-UNIX
3096: Status: RO
3097:
3098:
3099: Here are the responses that I received to my question "What's out
3100: there for emacs?"
3101:
3102:
3103: ------- Forwarded Messages
3104:
3105: Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983
3106: Date: Mon 24 Jan 83 22:43:01-PST
3107: From: Jay Lark <[email protected]>
3108: Subject: Re: emacs interface to franz?
3109: To: [email protected]
3110: In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST
3111:
3112: I'm sure you've probably received several messages similar to this one,
3113: but just in case...
3114:
3115: There exists the capability in Unix Emacs to run a process in its own
3116: buffer. Typein can be directed to the process, and output is just sent
3117: right to the buffer. This is an excellent way of running Lisp, because
3118: you get all of the nice Emacs features (paren balancing, local sexpr
3119: editing) at essentially no cost. I have been largely unsuccessful with
3120: trying to run Emacs under Lisp.
3121:
3122: The process package is part of the standard Unix Emacs distribution.
3123:
3124: Jay Lark
3125: -------
3126:
3127:
3128: ------- Message 2
3129:
3130: Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983
3131: Date: 25 Jan 1983 7:20-MST
3132: From: Russ Fish <utah-gr!fish@UTAH-CS> (host 10.0.0.4)
3133: Subject: Re: emacs interface to franz?
3134: To: mike@RAND-UNIX
3135: Cc: utah-gr!galway@UTAH-CS
3136: In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST
3137:
3138: We have been running our PSL (Portable Standard Lisp) in gemacs
3139: (Gosling's emacs) windows for some time. I suspect it would be a minor
3140: hack to convert it to Franz, but haven't done it and am not a Franz
3141: user. I could mail you our .ml code if you wanted to undertake
3142: converting it to Franz (or just using it for inspiration and hacking
3143: your own) and distributing it to Franz folks.
3144:
3145: It works like this: The lisp process is associated with a gemacs
3146: buffer/window. In that window you can carry on a normal line-by-line
3147: conversation, if you wish. <CR> sends the current line, (back to mark,
3148: which is left after the prompt) into the lisp. We mostly use the PSL
3149: in Rlisp syntax, which is algol-like, but this part of the code is just
3150: a wrapping for the new-shell function in process.ml with appropriate
3151: editting syntax set, so you could do the same with no work for any
3152: Lisp.
3153:
3154: You can send an expression, fn def, etc. from any other lisp-mode
3155: window with a single keypress. Echoing as input in the dialog window
3156: is inhibited if a prefix arg is provided, so you don't have to look at
3157: long exprs or fn defs again, just the lisp response.
3158:
3159: Sending multiple line exprs in response to a single prompt depends on
3160: the fact that PSL numbers the prompts for history, like the c-shell. A
3161: gemacs mlisp output filter process monitors the output for toploop
3162: prompts and feeds another line of input if the same prompt number comes
3163: back, instead of printing the prompt.
3164:
3165: The result is pretty classy. You get the full many-window gemacs
3166: editing environment with tags, etc. for random-access navigation and
3167: just send chunks of code as you change them. The extreme of usage is
3168: "menu" like windows which contain debugging code in clusters rather
3169: than sequences. You select exprs with the cursor and send them in any
3170: order.
3171:
3172: We also provide key fns for the common case of sending single lines to
3173: the toploop or single-character commands to the break-loop without
3174: editting them into a buffer.
3175:
3176: Best respond directly to me, since I am not on Franz-Friends.
3177:
3178: -Russ Fish (Fish@Utah-20, utah-cs!fish)
3179:
3180:
3181:
3182: ------- Message 3
3183:
3184: Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983
3185: Return-Path: <israel.umcp-cs@UDel-Relay>
3186: Date: 25 Jan 83 15:13:51 EST (Tue)
3187: From: Bruce Israel <israel.umcp-cs@UDel-Relay>
3188: Subject: Re: emacs interface to franz?
3189: To: mike@RAND-UNIX
3190: In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX
3191: <[email protected]>
3192: Via: UMCP-CS; 25 Jan 83 20:45-EST
3193:
3194: We have a few franz<->emacs interfaces, but I'm not sure what you mean.
3195: One is the process.ml package that comes with gosling's emacs (the emacs
3196: that I assume you are talking about). With this package, you can run
3197: franz inside a window from within emacs and have the facilities of an
3198: editor along with lisp. The other thing we have is a local Franz
3199: package called the load1 package. This package was written for
3200: compiling flavors (like in the lisp machine; another local package)
3201: and has a function called vi. (vi 'lisp-function) will call the
3202: editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the
3203: file which contains the definition of the lisp function, positioning
3204: the editor at the point in the file where the function is defined. Upon
3205: exiting the editor, it asks you if you want to reload the modified file.
3206: To edit a function from a file this way, the file must have been load1'ed
3207: previously so that the info on where the function is stored and what type
3208: it is will have been saved. Load1 will distinguish between different
3209: types of functions, ie. defflavors, defmethods, defmacros, defuns etc.
3210: and will search for the correct definition in the file. Is this what
3211: you mean? If you like I can send you the four or five files necessary.
3212: - Bruce
3213:
3214:
3215: ------- Message 4
3216:
3217: Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983
3218: Date: 27 Jan 1983 09:44-EST
3219: From: Carl.Ebeling@CMU-CS-VLSI
3220: Subject: Re: emacs interface to franz?
3221: To: mike@RAND-UNIX
3222: Message-Id: <412526661/ce@CMU-CS-VLSI>
3223: In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14
3224:
3225: I have an electric lisp package and process package for emacs. It
3226: includes 'zap-function-to-lisp' among other things. It is for
3227: Gosling's emacs and uses the subprocess facility. I can mail them to
3228: you if you like.
3229: Carl
3230:
3231:
3232: ------- End of Forwarded Messages
3233:
3234: From UCBKIM:jkf Wed Feb 2 08:19:19 1983
3235: Date: 2-Feb-83 08:14:21-PST (Wed)
3236: From: UCBKIM:jkf (John Foderaro)
3237: Subject: multiple messages fixed?
3238: Message-Id: <[email protected]>
3239: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3240: id AA25937; 2-Feb-83 08:14:21-PST (Wed)
3241: Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3242: id AA00384; 2 Feb 83 08:10:26 PST (Wed)
3243: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3244: id AA00477; 2 Feb 83 08:14:35 PST (Wed)
3245: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3246: id AA26020; 2-Feb-83 08:19:19-PST (Wed)
3247: To: franz-friends@ucbvax
3248: Status: RO
3249:
3250: I've broken the franz-friends mailing list over two machines. I hope that
3251: this will fix the problem of mail to franz-friends crashing ucbvax every
3252: thirty minutes. If you get multiple copies of this message, please do not
3253: tell me about it, I will already know.
3254:
3255:
3256:
3257:
3258: From jkf Thu Feb 10 21:45:17 1983
3259: Date: 10-Feb-83 21:45:17-PST (Thu)
3260: From: jkf (John Foderaro)
3261: Subject: liszt 8.21
3262: Message-Id: <[email protected]>
3263: Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3264: id AA16021; 10-Feb-83 21:45:17-PST (Thu)
3265: To: local-lisp
3266: Status: O
3267:
3268: more functions open coded: vsize, vsize-byte, vsize-word,
3269: vectorp, vectorip
3270:
3271:
3272:
3273: From PSI.KROHNFELDT@UTAH-20 Fri Feb 11 15:09:11 1983
3274: Date: 11 Feb 1983 1601-MST
3275: From: Jed Krohnfeldt <PSI.KROHNFELDT@UTAH-20>
3276: Subject: cfasl
3277: Message-Id: <[email protected]>
3278: Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3279: id AA07475; 11 Feb 83 15:02:05 PST (Fri)
3280: Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3281: id AA07565; 11 Feb 83 15:06:37 PST (Fri)
3282: Received: from UCBVAX.BERKELEY.ARPA by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82])
3283: id AA14422; 11-Feb-83 15:09:11-PST (Fri)
3284: To: Franz-friends@UCBVAX
3285: Status: O
3286:
3287: I am having trouble using cfasl in franz 38.04. I keep getting the
3288: message "ld: /usr/ucb/lisp : no namelist". Can anyone decipher this
3289: for me? Thanks...
3290: -------
3291:
3292: From apm@cmu-ri-isl Mon Feb 14 07:31:54 1983
3293: Date: 14 Feb 1983 10:24:21-EST
3294: From: Andrew.Mendler@CMU-RI-ISL
3295: Subject: franz lisp under5 vms 3.0
3296: Message-Id: <[email protected]>
3297: Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3)
3298: id AA27879; 14 Feb 83 07:31:54 PST (Mon)
3299: Received: by UCBKIM.ARPA (3.310/3.3)
3300: id AA01172; 14 Feb 83 15:50:41 PST (Mon)
3301: To: [email protected]
3302: Status: O
3303:
3304: Does anyone have a copy of Franz Lisp and the compiler that works under
3305: VMS version 3.0?
3306:
3307: From @udel-relay:tim.unc@UDel-Relay Mon Feb 14 02:52:18 1983
3308: Date: 13 Feb 83 14:34:48 EST (Sun)
3309: From: Tim Maroney <tim.unc@UDel-Relay>
3310: Subject: cfasl: no namelist
3311: Return-Path: <tim.unc@UDel-Relay>
3312: Message-Id: <[email protected]>
3313: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3)
3314: id AA25792; 14 Feb 83 02:52:18 PST (Mon)
3315: Received: by UCBKIM.ARPA (3.310/3.3)
3316: id AA02234; 14 Feb 83 16:18:42 PST (Mon)
3317: To: [email protected]
3318: Via: UNC; 14 Feb 83 5:43-EST
3319: Status: O
3320:
3321: I don't seem to be able to write Jed Krohnfeldt, and this
3322: answer is probably of general interest anyway. The message
3323: "ld: no namelist" means that some well-meaning system admin
3324: has stripped the lisp executable file to save space;
3325: unfortunately, this makes the dynamic loading used by cfasl
3326: impossible. Lisp will have to be recompiled (groan). No Franz
3327: Lisp executable file should EVER be stripped.
3328:
3329: Tim Maroney
3330: tim.unc@udel-relay
3331: decvax!duke!unc!tim
3332:
3333: From Mark.Sherman@CMU-CS-A Sat Feb 12 21:38:46 1983
3334: Date: 13 February 1983 0034-EST (Sunday)
3335: From: Mark.Sherman@CMU-CS-A
3336: Subject: Space and Leakage
3337: Message-Id: <13Feb83 003422 MS40@CMU-CS-A>
3338: Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
3339: id AA07842; 12 Feb 83 21:38:46 PST (Sat)
3340: Received: by UCBKIM.ARPA (3.310/3.3)
3341: id AA02341; 14 Feb 83 16:21:29 PST (Mon)
3342: To: franz-friends@UCB-VAX
3343: Status: O
3344:
3345: Can someone tell me how the maximum amount of storage that franz
3346: lisp uses is decided? I can force the size up to (about) 3050
3347: pages (according to "ps") and then get the message "storage exhausted".
3348: I have been told (and have seen) other jobs get substantially more
3349: space; can franz get more pages as well? (I am using the cshell
3350: and have already used the limit command to raise my process
3351: size up to 32 megabytes, or so I think.)
3352:
3353: I have also been told that the garbage collector leaks, that is,
3354: not all of the garbage is really collected. Does anyone have good
3355: ideas about how much (or fast) this happens, or if there is some way
3356: to minimize the lost space?
3357:
3358: (Please send responses directly to me as I am not on this list.)
3359: -Mark Sherman (Sherman@CMU-CS-A)
3360:
3361: From @udel-relay:Mac.uvacs.Virginia@UDel-Relay Fri Feb 18 21:04:31 1983
3362: Date: 18 Feb 83 12:42:40-EST (Fri)
3363: From: Mac.uvacs@UDel-Relay
3364: Subject: global nonspecial variables
3365: Return-Path: <Mac.uvacs.Virginia@UDel-Relay>
3366: Message-Id: <[email protected]>
3367: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5)
3368: id AA26020; 18 Feb 83 21:04:31 PST (Fri)
3369: Received: by UCBKIM.ARPA (3.310/3.5)
3370: id AA00656; 21 Feb 83 01:59:26 PST (Mon)
3371: To: [email protected]
3372: Via: Virginia; 18 Feb 83 23:58-EST
3373: Status: O
3374:
3375: Does the Liszt compiler have any notion of global variables --
3376: free variables with fast access, without any rebinding?
3377:
3378: I think the MACLISP compiler has something like this for variables
3379: beginning "**".
3380:
3381: Alex Colvin
3382:
3383: uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac
3384: csnet:mac@virginia
3385: arpa: mac.uvacs@udel-relay
3386:
3387: From jkf@UCBKIM Mon Feb 21 09:19:56 1983
3388: Date: 21 Feb 83 09:19:43 PST (Mon)
3389: From: jkf@UCBKIM (John Foderaro)
3390: Subject: Re: global nonspecial variables
3391: Message-Id: <[email protected]>
3392: Received: by UCBKIM.ARPA (3.310/3.5)
3393: id AA02798; 21 Feb 83 09:19:43 PST (Mon)
3394: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
3395: id AA13982; 21 Feb 83 09:11:52 PST (Mon)
3396: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3397: id AA02805; 21 Feb 83 09:19:56 PST (Mon)
3398: To: Mac.uvacs@UDel-Relay, [email protected]
3399: In-Reply-To: Your message of 18 Feb 83 12:42:40-EST (Fri)
3400: Status: O
3401:
3402: I don't understand the distinction between what you call a global variable
3403: and a special variable. A special variable in Franz Lisp (and any other
3404: shallow bound lisp) can be accessed rapidly and is only rebound if you
3405: put it in a lambda, prog or do variable list.
3406:
3407:
3408:
3409: From jkf@UCBKIM Fri Feb 25 08:29:01 1983
3410: Date: 25 Feb 83 08:28:45 PST (Fri)
3411: From: jkf@UCBKIM (John Foderaro)
3412: Subject: research position at edinburgh
3413: Message-Id: <[email protected]>
3414: Received: by UCBKIM.ARPA (3.310/3.5)
3415: id AA00528; 25 Feb 83 08:28:45 PST (Fri)
3416: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5)
3417: id AA00867; 25 Feb 83 08:18:48 PST (Fri)
3418: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3419: id AA00537; 25 Feb 83 08:29:01 PST (Fri)
3420: To: [email protected]
3421: Status: O
3422:
3423:
3424: DEPARTMENT OF ARTIFICIAL INTELLIGENCE
3425: UNIVERSITY OF EDINBURGH
3426:
3427: RESEARCH FELLOW
3428:
3429: A Research Fellowship is available within the Programming Systems Development
3430: Group. The post has been created specifically to provide a modern LISP system
3431: for the Perq computer running under ICL MicroCode UNIX, and is funded by the
3432: Science and Engineering Research Council.
3433:
3434: Experience in implementing systems would be advantageous, as would be a
3435: knowledge of LISP and C. Access will be available to an SERC DECsystem-10
3436: running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as
3437: to Perqs.
3438:
3439: The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds
3440: sterling, according to age and experience. The post is funded for a period of
3441: two years from the date of appointment.
3442:
3443: Further particulars of the post can be obtained from:
3444:
3445: Administrative Assistant
3446: Department of Artificial Intelligence
3447: University of Edinburgh
3448: Forrest Hill
3449: Edinburgh EH1 2QL
3450: SCOTLAND
3451: phone
3452: 031-667-1011 x2554
3453:
3454: or by contacting
3455:
3456: RAE%EDXA%UCL-CS@ISID (Networks permitting)
3457:
3458: Applications should be made by March 17th, 1983.
3459:
3460:
3461:
3462:
3463: From layer Sat Mar 5 20:12:57 1983
3464: Date: 5 Mar 83 20:12:57 PST (Sat)
3465: From: layer (Kevin Layer)
3466: Subject: process function
3467: Message-Id: <[email protected]>
3468: Received: by UCBKIM.ARPA (3.310/3.5)
3469: id AA18927; 5 Mar 83 20:12:57 PST (Sat)
3470: Phone: (415) 652-2405
3471: To: local-lisp
3472: Status: O
3473:
3474: The process function now looks in the environment at the SHELL variable.
3475: If present, it will use this as the default shell to execute your command.
3476: If not present, csh and then sh are tried (in that order).
3477:
3478:
3479: From @udel-relay.ARPA:Pintzuk.UPenn.UPenn@UDel-Relay Tue Mar 8 06:04:10 1983
3480: Date: 8 Mar 1983 2:32-EST
3481: From: Susan Pintzuk <Pintzuk.UPenn@UDel-Relay>
3482: Subject: lisp statistical packages
3483: Return-Path: <Pintzuk.UPenn.UPenn@UDel-Relay>
3484: Message-Id: <[email protected]>
3485: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14)
3486: id AA13004; 8 Mar 83 06:01:54 PST (Tue)
3487: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3488: id AA08297; 8 Mar 83 06:04:10 PST (Tue)
3489: To: [email protected]
3490: Via: UPenn; 8 Mar 83 3:49-EST
3491: Status: O
3492:
3493: do any franz-lisp packages exist which calculate mean, standard deviation,
3494: %n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.? if so, how
3495: do i obtain a copy?
3496:
3497: From jkf Tue Mar 8 09:10:46 1983
3498: Date: 8 Mar 83 09:10:46 PST (Tue)
3499: From: jkf (John Foderaro)
3500: Subject: opus38.56
3501: Message-Id: <[email protected]>
3502: Received: by UCBKIM.ARPA (3.310/3.5)
3503: id AA09423; 8 Mar 83 09:10:46 PST (Tue)
3504: To: local-lisp
3505: Status: O
3506:
3507: If $gcprint is set to a non nil value, then just before a garbage
3508: collection is begun, the message 'gc:' will be printed on the tty.
3509: As before, after the garbage collection is finished, the statistics
3510: message in square brackets will be printed.
3511:
3512:
3513:
3514: From fateman Wed Mar 9 09:54:31 1983
3515: Date: 9 Mar 83 09:54:31 PST (Wed)
3516: From: fateman (Richard Fateman)
3517: Subject: need a job
3518: Message-Id: <[email protected]>
3519: Received: by UCBKIM.ARPA (3.310/3.5)
3520: id AA14754; 9 Mar 83 09:54:31 PST (Wed)
3521: To: local-lisp
3522: Status: O
3523:
3524: porting Lisp, C, Pascal, Fortran ... etc to a Denelcorp HEP
3525: computer? Wanna live in Denver? There is a recruiter in
3526: town from Denelcor at Marriot Inn, Jim Holly. There is an
3527: ad posted on 5th floor bulletin board.
3528:
3529: From jkf Sat Mar 19 17:44:33 1983
3530: Date: 19 Mar 83 17:44:33 PST (Sat)
3531: From: jkf (John Foderaro)
3532: Subject: liszt 8.24
3533: Message-Id: <[email protected]>
3534: Received: by UCBKIM.ARPA (3.310/3.5)
3535: id AA25091; 19 Mar 83 17:44:33 PST (Sat)
3536: To: local-lisp
3537: Status: O
3538:
3539: The vax and 68k versions of liszt have been combined into one set of
3540: source files. This is mainly a textual change, but some functions
3541: in the compiler have been modified in reduce the machine dependent code.
3542: Be on the lookout for strange errors.
3543:
3544:
3545:
3546: From fateman Tue Mar 22 20:52:11 1983
3547: Date: 22 Mar 83 20:52:11 PST (Tue)
3548: From: fateman (Richard Fateman)
3549: Subject: T Lisp
3550: Message-Id: <[email protected]>
3551: Received: by UCBKIM.ARPA (3.310/3.5)
3552: id AA05935; 22 Mar 83 20:52:11 PST (Tue)
3553: To: local-lisp
3554: Status: RO
3555:
3556: I have a preliminary manual for the T dialect of Lisp, created
3557: at Yale. It is being offered for sale by Cognitive Systems, Inc.
3558: for $1000/CPU (educational price). It offers features from Lisp
3559: and Scheme. It runs on VAX and Apollo 68000 systems.
3560:
3561: From jkf Thu Mar 24 08:29:31 1983
3562: Date: 24 Mar 83 08:29:31 PST (Thu)
3563: From: jkf (John Foderaro)
3564: Subject: liszt 8.25
3565: Message-Id: <[email protected]>
3566: Received: by UCBKIM.ARPA (3.310/3.5)
3567: id AA06735; 24 Mar 83 08:29:31 PST (Thu)
3568: To: local-lisp
3569: Status: O
3570:
3571:
3572: If you do this:
3573:
3574: liszt -x a/b/c.l -o x/y/z.o
3575:
3576: then the cross reference file will be put in x/y/z.x
3577: Before this version, it would have gone into a/b/c.x
3578:
3579:
3580:
3581: From jkf Thu Mar 24 15:00:37 1983
3582: Date: 24 Mar 83 15:00:37 PST (Thu)
3583: From: jkf (John Foderaro)
3584: Subject: liszt 8.26
3585: Message-Id: <[email protected]>
3586: Received: by UCBKIM.ARPA (3.310/3.5)
3587: id AA11144; 24 Mar 83 15:00:37 PST (Thu)
3588: To: local-lisp
3589: Status: O
3590:
3591: liszt will now pass the assembler the -V switch. This tells the assembler
3592: to keep its intermediate file in core rather than putting it in /tmp.
3593: This should make assembly slightly faster and also permit large lisp files to
3594: be compiled on systems with small /tmp's.
3595:
3596:
3597:
3598: From @udel-relay.ARPA:tim.unc@UDel-Relay Sat Mar 26 03:41:05 1983
3599: Date: 25 Mar 83 15:03:29 EST (Fri)
3600: From: Tim Maroney <tim.unc@UDel-Relay>
3601: Subject: open coding of (function (lambda ...))
3602: Return-Path: <tim.unc@UDel-Relay>
3603: Message-Id: <[email protected]>
3604: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17)
3605: id AB02371; 26 Mar 83 03:37:13 PST (Sat)
3606: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3607: id AA00854; 26 Mar 83 03:41:05 PST (Sat)
3608: To: [email protected]
3609: Via: UNC; 25 Mar 83 19:43-EST
3610: Status: O
3611:
3612: This doesn't seem to work. I'm using Liszt version 8.10, University
3613: of Maryland distribution. The documentation in the file "lispnews"
3614: is sketchy, but it seems that compiling and loading the file:
3615:
3616: (setq appsum (function (lambda (x) (apply 'sum x))))
3617:
3618: should leave a bcd object in appsum's value, but it doesn't. It
3619: leaves the uncompiled lambda. Am I doing something wrong?
3620:
3621: Tim Maroney
3622: decvax!duke!unc!tim
3623: tim.unc@udel-relay
3624:
3625: From jkf@UCBKIM Sat Mar 26 08:46:44 1983
3626: Date: 26 Mar 83 08:46:28 PST (Sat)
3627: From: jkf@UCBKIM (John Foderaro)
3628: Subject: Re: open coding of (function (lambda ...))
3629: Message-Id: <[email protected]>
3630: Received: by UCBKIM.ARPA (3.310/3.5)
3631: id AA02453; 26 Mar 83 08:46:28 PST (Sat)
3632: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17)
3633: id AA05012; 26 Mar 83 08:42:50 PST (Sat)
3634: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3635: id AA02462; 26 Mar 83 08:46:44 PST (Sat)
3636: To: tim.unc@UDel-Relay
3637: Cc: [email protected]
3638: In-Reply-To: Your message of 25 Mar 83 15:03:29 EST (Fri)
3639: Status: O
3640:
3641:
3642: Liszt only compiles functions, not literals it finds in files.
3643: To make this statement be compiled:
3644: (setq appsum (function (lambda (x) (apply 'sum x))))
3645:
3646: you should surround it with a function defintion:
3647: (defun junk ()
3648: (setq appsum (function (lambda (x) (apply 'sum x)))))
3649:
3650:
3651:
3652: From CARR@UTAH-20 Mon Apr 4 14:53:09 1983
3653: Date: 4 Apr 1983 0922-MST
3654: From: Harold Carr <CARR@UTAH-20>
3655: Subject: Franz/Common lisp
3656: Message-Id: <[email protected]>
3657: Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20)
3658: id AA07020; 4 Apr 83 09:11:40 PST (Mon)
3659: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3660: id AA01683; 4 Apr 83 14:53:09 PST (Mon)
3661: To: [email protected]
3662: Cc: KROHNFELDT@UTAH-20
3663: Status: O
3664:
3665: Does anyone have any sort of Common Lisp compatibility package for Franz?
3666: If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20).
3667: -------
3668:
3669: From jeff@aids-unix Tue Apr 5 12:42:46 1983
3670: Date: 4 Apr 1983 11:06:49 PST (Monday)
3671: From: Jeff Dean <jeff@aids-unix>
3672: Subject: knowledge representation language
3673: Message-Id: <[email protected]>
3674: Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20)
3675: id AA26557; 5 Apr 83 12:42:11 PST (Tue)
3676: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3677: id AA16443; 5 Apr 83 12:42:46 PST (Tue)
3678: To: [email protected]
3679: Status: O
3680:
3681: Does anyone have a knowledge representation language (such as FRL or
3682: KL-ONE) available under Franz Lisp?
3683:
3684: Jeff Dean
3685: arpa: jeff@aids-unix
3686: uucp: ...ucbvax!jeff@aids-unix
3687:
3688:
3689: From jkf Tue Apr 5 13:08:06 1983
3690: Date: 5 Apr 83 13:08:06 PST (Tue)
3691: From: jkf (John Foderaro)
3692: Subject: lisp opus 38.57
3693: Message-Id: <[email protected]>
3694: Received: by UCBKIM.ARPA (3.310/3.5)
3695: id AA16969; 5 Apr 83 13:08:06 PST (Tue)
3696: To: local-lisp
3697: Status: RO
3698:
3699: This version has a number of internal changes to make it compilable
3700: on 68k. If you notice it acting abnormally, let me know.
3701:
3702:
3703:
3704: From FAHLMAN@CMU-CS-C Thu Apr 7 07:50:06 1983
3705: Date: Thu, 7 Apr 1983 10:46 EST
3706: From: Scott E. Fahlman <Fahlman@CMU-CS-C>
3707: Subject: Franz/Common lisp
3708: Message-Id: <[email protected]>
3709: Received: ID <FAHLMAN@CMU-CS-C>; 7 Apr 83 10:46:59 EST
3710: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20)
3711: id AA13873; 7 Apr 83 07:49:42 PST (Thu)
3712: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3713: id AA18082; 7 Apr 83 07:50:06 PST (Thu)
3714: To: Harold Carr <CARR@UTAH-20>
3715: Cc: [email protected]
3716: In-Reply-To: Msg of 4 Apr 1983 11:22-EST from Harold Carr <CARR at UTAH-20>
3717: Status: RO
3718:
3719:
3720: Harold,
3721:
3722: A couple of things make it seem unlikely that anyone would have such a
3723: package right now. First, we don't even have a final Common Lisp manual
3724: yet -- Guy's next draft is due very soon, but there will be some tuning
3725: and hassling after that. Second, there are things in Common Lisp that
3726: would be very tough to fake on Franz: lexical binding, generic
3727: sequences, some of the hairy number types, character objects, etc.
3728: Common Lisp is pretty close to being a superset of Franz, so I would
3729: expect to see Franz compatibility packages in Common Lisp, but not vice
3730: versa. Third, if anyone were writing such a package, they would be
3731: crazy not to have arranged for access to our code that implements all of
3732: the hairy functions, and nobody has done this to my knowledge.
3733:
3734: My standard advice is for people to continue to code in Franz with the
3735: knowledge that they can easily convert their code to Common Lisp
3736: whenever the DEC Common Lisp is available to them. This should be a
3737: one-time conversion, since moving the other way after "going native" in
3738: Common Lisp would be very tough.
3739:
3740: If someone does pop up with a compatibility package -- even a partial
3741: one -- I would be interested in hearing about it.
3742:
3743: -- Scott
3744:
3745: From fateman@UCBKIM Sun Apr 10 19:52:14 1983
3746: Date: 10 Apr 83 19:50:59 PST (Sun)
3747: From: fateman@UCBKIM (Richard Fateman)
3748: Subject: Re: Franz/Common lisp
3749: Message-Id: <[email protected]>
3750: Received: by UCBKIM.ARPA (3.310/3.5)
3751: id AA06176; 10 Apr 83 19:50:59 PST (Sun)
3752: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
3753: id AA10019; 10 Apr 83 19:49:55 PST (Sun)
3754: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3755: id AA06192; 10 Apr 83 19:52:14 PST (Sun)
3756: To: carr@utah-20, fahlman@cmu-cs-c
3757: Cc: [email protected]
3758: Status: RO
3759:
3760: I think that a common-lisp-compatibility package written
3761: in Franz would not be as difficult as all that.
3762:
3763: If Common Lisp (TM of DEC?) were available on all the same
3764: machines at the same price, (appx. $0.) and CL were
3765: in fact a superset of Franz for all practical purposes, and
3766: with similar or better efficiency, etc. Why would anyone bother?
3767:
3768: Of course if CL does not meet all of the objectives (e.g. price, machines),
3769: then a CL-to-Franz "translator" might make sense.
3770:
3771: With that in mind,
3772: I would like to officially request a copy of the Common Lisp
3773: language (as implemented in CL, presumably), as soon as it
3774: becomes available (i.e. no later than when it is a "product"
3775: of DEC, and probably at "beta" test time).
3776: I agree fully with Scott that trying to do this with an incomplete
3777: language specification is unwise.
3778:
3779: I am also not making any commitment to do anything with CL at
3780: Berkeley, but since we are building tools for our own applications,
3781: and CL might be useful, we might consider an efficient merge of
3782: ideas.
3783:
3784: From jkf@UCBKIM Mon Apr 11 08:07:39 1983
3785: Date: 11 Apr 83 06:42:43 PST (Mon)
3786: From: jkf@UCBKIM (John Foderaro)
3787: Subject: mail to this mailing list
3788: Message-Id: <[email protected]>
3789: Received: by UCBKIM.ARPA (3.310/3.5)
3790: id AA11378; 11 Apr 83 06:42:43 PST (Mon)
3791: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21)
3792: id AA07288; 11 Apr 83 08:05:32 PST (Mon)
3793: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5)
3794: id AA11949; 11 Apr 83 08:07:39 PST (Mon)
3795: To: [email protected]
3796: Status: RO
3797:
3798: I'm sorry that people who mail to this mailing list must put up with lots
3799: of mail errors from our local mailer. The problem is not that we have a
3800: lot of illegal addresses, but that over the three day period that the
3801: mailer tries to deliver the mail, some of the destination sites never
3802: respond. I think that this is due primarily to the fact that many sites
3803: are running new mail and networking software. Hopefully this will
3804: improve over time.
3805: john foderaro
3806:
3807:
3808:
3809:
3810: From jkf Fri Apr 22 09:59:09 1983
3811: Date: 22 Apr 83 09:59:09 PST (Fri)
3812: From: jkf (John Foderaro)
3813: Subject: lisp opus 38.59
3814: Message-Id: <[email protected]>
3815: Received: by UCBKIM.ARPA (3.310/3.5)
3816: id AA20996; 22 Apr 83 09:59:09 PST (Fri)
3817: To: local-lisp
3818: Status: RO
3819:
3820: Input like 1.2.3 and 1..2 will now be read as single symbols rather
3821: than two consecutive numbers.
3822:
3823:
3824:
3825: From jkf Sun May 8 00:02:54 1983
3826: Date: 8 May 83 00:02:54 PDT (Sun)
3827: From: jkf (John Foderaro)
3828: Subject: opus 38.60
3829: Message-Id: <[email protected]>
3830: Received: by UCBKIM.ARPA (3.310/3.5)
3831: id AA22344; 8 May 83 00:02:54 PDT (Sun)
3832: To: local-lisp
3833: Cc: rms
3834: Status: RO
3835:
3836: Thanks to some suggestions from rms we are now one step closer to
3837: full closures. fclosures will now work if called recursively.
3838: It is still true that the only way to make fclosures share variables
3839: is to use fclosure-list.
3840:
3841: symeval-in-fclosure may return the wrong value if the closure is
3842: 'active'. This will be fixed eventually.
3843:
3844:
3845:
3846: From mbr@nprdc Sat May 21 07:37:23 1983
3847: Date: 20 May 1983 14:57:55-PDT
3848: From: mbr@NPRDC
3849: Subject: lam9.c and curses
3850: Message-Id: <[email protected]>
3851: Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29)
3852: id AA16172; 21 May 83 07:34:43 PDT (Sat)
3853: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3854: id AA08856; 21 May 83 07:37:23 PDT (Sat)
3855: Reply-To: mbr <mbr@NPRDC>
3856: To: [email protected]
3857: Cc: mbr@NPRDC
3858: Status: O
3859:
3860: When we attempted to cfasl a file that used the curses package
3861: of screen control routines into Franz 38.40, we got the message
3862: _ospeed: /usr/libcurses.a (cr_tty.o) multiply defined.
3863: The apparent cause of this cryptic remark is that in lam9.c
3864: there is an extern variable ospeed. There are a number of
3865: tantalizing routines in this source file dealing with termcaps that
3866: are apparently not called by anyone. Are there plans for these
3867: routines? Does anyone use them (heaven forbid they should be
3868: documented!). Our current fix is to just change ospeed to ospiid
3869: which so far has had no dire effects, but I am interested in others
3870: experience. The curses stuff seems to work fine after this
3871: modification.
3872: Mark Rosenstein
3873:
3874:
3875: From jkf Wed May 25 12:15:54 1983
3876: Date: 25 May 83 12:15:54 PDT (Wed)
3877: From: jkf (John Foderaro)
3878: Subject: opus 38.61
3879: Message-Id: <[email protected]>
3880: Received: by UCBKIM.ARPA (3.340/3.5)
3881: id AA01144; 25 May 83 12:15:54 PDT (Wed)
3882: To: local-lisp
3883: Status: O
3884:
3885: symeval-in-fclosure and set-in-fclosure now work (thanks to keith).
3886:
3887: selectq is now a part of standard franz. selectq is just like
3888: caseq except it allows 'otherwise' as well as 't' for the
3889: key which means 'if nothing else matches, use this clause'.
3890:
3891:
3892:
3893:
3894: From cornwell@nrl-css Wed May 25 12:51:17 1983
3895: Date: Wed, 25 May 83 15:14:19 EDT
3896: From: Mark Cornwell <cornwell@NRL-CSS>
3897: Subject: Franz on the Sun
3898: Message-Id: <[email protected]>
3899: Received: from nrl-css (nrl-css.ARPA) by UCBVAX.ARPA (3.341/3.29)
3900: id AA02600; 25 May 83 12:50:26 PDT (Wed)
3901: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3902: id AA01878; 25 May 83 12:51:17 PDT (Wed)
3903: To: [email protected]
3904: Cc: cornwell@NRL-CSS
3905: Status: O
3906:
3907:
3908: Our group at NRL is planning to purchase Sun workstations. I
3909: currently have a substantial amount of code written in Franz Lisp that
3910: I want to run on the Sun.
3911:
3912: What is the status of the Berkeley group porting Franz to the Sun?
3913: How do I get a copy?
3914:
3915: Also, I have a few concerns about configuring a Sun to run Franz well.
3916: The basic desktop Sun workstation provides 1 Mbyte of physical memory.
3917: This can be extended to 2 Mbyte or one can add an Ethernet interface
3918: *but not both*. Since I am unwilling to give up my Ethernet
3919: interface I may be forced to run Franz in 1 Mbyte and contend with
3920: the added paging overhead (using a 68010 running 4.2bsd and a local disk).
3921:
3922: Has anyone out there had experience running Franz Lisp on a Sun in
3923: such a configuration? Can I get away without the 2 Mbyte extension?
3924: I think your answers would be of general interest.
3925:
3926: -- Mark (caught between a rock and a hard place?) Cornwell
3927:
3928:
3929:
3930: From baden@UCBKIM Wed May 25 13:51:39 1983
3931: Date: 25 May 83 13:32:01 PDT (Wed)
3932: From: baden@UCBKIM (Scott B. Baden)
3933: Subject: Re: Franz on the Sun
3934: Message-Id: <[email protected]>
3935: Received: by UCBKIM.ARPA (3.340/3.5)
3936: id AA02716; 25 May 83 13:32:01 PDT (Wed)
3937: Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29)
3938: id AA03753; 25 May 83 13:50:52 PDT (Wed)
3939: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3940: id AA03002; 25 May 83 13:51:39 PDT (Wed)
3941: To: [email protected]
3942: Cc: cornwell@NRL-CSS
3943: Status: O
3944:
3945: Which sun are you using? My office mate says that
3946: he has seen a sun configured with 2MB of memory AND
3947: an Ethernet board.
3948:
3949: From mike%Rice.Rice@Rand-Relay Fri May 27 19:51:33 1983
3950: Date: Fri, 27 May 83 18:18:47 CDT
3951: From: Mike.Caplinger <mike.rice@Rand-Relay>
3952: Subject: Re: Franz on the Sun
3953: Return-Path: <mike%Rice.Rice@Rand-Relay>
3954: Message-Id: <[email protected]>
3955: Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29)
3956: id AA19088; 27 May 83 19:50:15 PDT (Fri)
3957: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3958: id AA02221; 27 May 83 19:51:33 PDT (Fri)
3959: To: [email protected]
3960: In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed)
3961: Via: Rice; 27 May 83 19:14-PDT
3962: Status: RO
3963:
3964: As I type I'm bringing up the 68K version of Opus 38 (now FTPable from
3965: UCB-VAX) on a SUN running 4.1c. There don't seem to be any major
3966: problems so far, but the compiler doesn't run on a system with all the
3967: net servers on it because it runs out of memory. I've been told this
3968: is because there's a bug in 4.1c that forces it to only use 1/2 of the
3969: swap partition. I'm having to run standalone to compile the compiler;
3970: I don't yet know whether I'll be able to compile other stuff without
3971: this rather extreme fix.
3972:
3973: As I use the system more I will post more info to this group.
3974:
3975: From narain@rand-unix Tue May 31 10:49:00 1983
3976: Date: Tuesday, 31 May 1983 10:45-PDT
3977: From: narain@rand-unix
3978: Subject: Interrupt question
3979: Message-Id: <[email protected]>
3980: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29)
3981: id AA10893; 31 May 83 10:47:26 PDT (Tue)
3982: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
3983: id AA13428; 31 May 83 10:49:00 PDT (Tue)
3984: To: [email protected]
3985: Cc: narain@rand-unix
3986: Status: O
3987:
3988:
3989: Hi, I would be grateful if you could tell me what is the equivalent of
3990: Interlisp's control-h (followed by OK) in Franzlisp. In other words, I
3991: wish to interrupt a Franzlisp program, from time to time, examine its state
3992: and allow it to continue from the interrupted point.
3993:
3994: -- Sanjai
3995:
3996: From [email protected] Tue May 31 19:31:04 1983
3997: Date: 31 May 83 17:28:35 PDT (Tue)
3998: From: [email protected]
3999: Subject: packages
4000: Message-Id: <[email protected]>
4001: Received: by LBL-CSAM.ARPA (3.320/3.21)
4002: id AA16451; 31 May 83 17:28:35 PDT (Tue)
4003: Received: by UCBVAX.ARPA (3.341/3.31)
4004: id AA02877; 31 May 83 19:30:00 PDT (Tue)
4005: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4006: id AA22745; 31 May 83 19:31:04 PDT (Tue)
4007: To: [email protected]
4008: Status: O
4009:
4010:
4011: Does a version of LispMachine ``packages'' or some similar oblist partitioning
4012: scheme exist for franz? Having just integrated several independently coded
4013: modules, I think something like that would be very useful.
4014: -thanks
4015: Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve
4016:
4017:
4018: From fateman Tue Jun 14 11:48:32 1983
4019: Date: 14 Jun 83 11:48:32 PDT (Tue)
4020: From: fateman (Richard Fateman)
4021: Subject: "macsyma on a chip?"
4022: Message-Id: <[email protected]>
4023: Received: by UCBKIM.ARPA (3.340/3.5)
4024: id AA06756; 14 Jun 83 11:48:32 PDT (Tue)
4025: To: macsyma-i@mit-mc
4026: Cc: franz-friends
4027: Status: O
4028:
4029: Well, sort of. We now have Macsyma running on a Motorola 68000 - based
4030: system with 6 megabytes of real memory. The operating system is a
4031: Unisoft UNIX system, which has been ported to some large number (>65) boxes.
4032: The Pixel people were kind enough to lend us a machine with enough
4033: real memory to make virtual memory unnecessary.
4034:
4035: It takes a long time to load up, but once running, it is quite responsive,
4036: and appears to be about 60% of a VAX 11/780 in terms of CPU time.
4037:
4038: We have not shaken down everything, but since the source code is unchanged
4039: from the VAX, we expect the bugs to be limited to lisp compilation
4040: glitches, or differences between versions of the UNIX system.
4041:
4042:
4043: From jkf Wed Jun 15 10:42:05 1983
4044: Date: 15 Jun 83 10:42:05 PDT (Wed)
4045: From: jkf (John Foderaro)
4046: Subject: Opus 38.62
4047: Message-Id: <[email protected]>
4048: Received: by UCBKIM.ARPA (3.340/3.5)
4049: id AA20591; 15 Jun 83 10:42:05 PDT (Wed)
4050: To: local-lisp
4051: Status: O
4052:
4053: There is no longer a limit on the size of bignums, strings or
4054: symbol names which can be read by the reader [other than the size of
4055: virtual memory].
4056:
4057: The value of lisp-library-directory will determine where cfasl finds
4058: its private version of the loader.
4059:
4060: (changes by sklower)
4061:
4062:
4063: From @CMU-CS-C:UI.TYJ@CU20D Wed Jun 15 18:22:55 1983
4064: Date: 14 Jun 1983 1812-EDT
4065: From: Tai Jin <UI.TYJ@CU20D>
4066: Subject: franz mailing liszt
4067: Message-Id: <[email protected]>
4068: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
4069: id AA16599; 14 Jun 83 15:14:36 PDT (Tue)
4070: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4071: id AA28806; 15 Jun 83 18:22:55 PDT (Wed)
4072: To: franz-friends%berkeley@CMCSC
4073: Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC
4074: Status: O
4075:
4076:
4077: Hi, we would like to be added to your mailing list.
4078:
4079: We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS)
4080: running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center
4081: for Computing Activities).
4082:
4083: Is anyone out there working on an UTS/IBM implementation? Any information will
4084: be greatly appreciated.
4085:
4086:
4087: Thanks,
4088:
4089: Tai Jin <UI.TYJ%CU20D@CMCSC>
4090: Travis Winfrey <UI.TRAVIS%CU20D@CMCSC>
4091: -------
4092:
4093: From @CMU-CS-C:Ui.Travis@CU20D Thu Jun 16 09:47:39 1983
4094: Date: 16 Jun 1983 1243-EDT
4095: From: Travis Lee Winfrey <Ui.Travis@CU20D>
4096: Subject: Porting Franz lisp to Amdahl Unix
4097: Message-Id: <[email protected]>
4098: Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33)
4099: id AA25470; 16 Jun 83 09:46:15 PDT (Thu)
4100: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4101: id AA06352; 16 Jun 83 09:47:39 PDT (Thu)
4102: To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC
4103: Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D,
4104: kim.fateman%berkeley@CMCSC
4105: Status: O
4106:
4107: Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's
4108: Unix running on a IBM 4341. We are working from a copy that runs on the VAX.
4109:
4110: We would be very interested in seeing any versions that runs both on the VAX
4111: and some other machine, such as the 68000. We are also interested in seeing
4112: any documentation on other porting efforts, regardless of what machine.
4113:
4114: Thanks,
4115:
4116: Tai Jin <ui.tyj%cu20d@cmu-cs-c>
4117: Travis Winfrey <ui.travis%cu20d@cmu-cs-c>
4118: -------
4119:
4120: From jkf Sun Jun 19 15:43:34 1983
4121: Date: 19 Jun 83 15:43:34 PDT (Sun)
4122: From: jkf (John Foderaro)
4123: Subject: opus 38.63
4124: Message-Id: <[email protected]>
4125: Received: by UCBKIM.ARPA (3.340/3.5)
4126: id AA19626; 19 Jun 83 15:43:34 PDT (Sun)
4127: To: local-lisp
4128: Status: O
4129:
4130: Added functions:
4131: (vputprop 'Vv_vector 'g_value 'g_indicator)
4132: (vget 'Vv_vector 'g_indicator)
4133:
4134: work just like putprop and get, but modify the vector property list.
4135:
4136: Also:
4137: you can determine which function is called by lisp to print a vector
4138: by placing the function to call on the vector's property list under
4139: indicator 'print'. The print function is called with two arguments:
4140: the vector and the port.
4141:
4142: For example:
4143: => (defun printv (v port)
4144: (patom "A vector of size " port)
4145: (print (vsize v) port))
4146: printv
4147: => (setq xx (new-vector 10))
4148: vector[40]
4149: => (vputprop xx 'printv 'print)
4150: printv
4151: => xx
4152: A vector of size 10
4153: =>
4154:
4155:
4156:
4157: From jkf Sun Jun 19 22:47:42 1983
4158: Date: 19 Jun 83 22:47:42 PDT (Sun)
4159: From: jkf (John Foderaro)
4160: Subject: opus 38.64
4161: Message-Id: <[email protected]>
4162: Received: by UCBKIM.ARPA (3.340/3.5)
4163: id AA23164; 19 Jun 83 22:47:42 PDT (Sun)
4164: To: local-lisp
4165: Cc: jpg@Mit-mc
4166: Status: O
4167:
4168:
4169: added the function (^ 'x_a 'x_b) which computes x_a to the x_b
4170: power and always returns a fixnum result (it currently wraps around
4171: on overflow).
4172:
4173:
4174:
4175: From JPG@MIT-MC Sun Jun 19 22:54:00 1983
4176: Date: 20 June 1983 01:53 EDT
4177: From: Jeffrey P. Golden <JPG@MIT-MC>
4178: Subject: ^
4179: Message-Id: <[email protected]>
4180: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.346/3.33)
4181: id AA15160; 19 Jun 83 22:53:57 PDT (Sun)
4182: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4183: id AA23228; 19 Jun 83 22:54:00 PDT (Sun)
4184: To: jkf@UCBKIM
4185: Cc: JPG@MIT-MC, local-lisp@UCBKIM
4186: Status: O
4187:
4188: Date: 19 Jun 83 22:47:42 PDT
4189: From: jkf%UCBKIM@Berkeley
4190: Subject: opus 38.64
4191: To: local-lisp%UCBKIM@Berkeley
4192: Cc: jpg@Mit-mc
4193: added the function (^ 'x_a 'x_b) which computes x_a to the x_b
4194: power and always returns a fixnum result (it currently wraps around
4195: on overflow).
4196: The Maclisp ^ errors out in this case with the message:
4197: ;RESULT LARGER THAN FIXNUM - ^
4198:
4199:
4200: From narain@rand-unix Mon Jun 20 22:09:31 1983
4201: Date: Monday, 20 Jun 1983 22:00-PDT
4202: From: narain@rand-unix
4203: Subject: Re: Interrrupt question
4204: Message-Id: <[email protected]>
4205: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
4206: id AA00276; 20 Jun 83 22:09:20 PDT (Mon)
4207: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4208: id AA09633; 20 Jun 83 22:09:31 PDT (Mon)
4209: To: [email protected]
4210: Cc: narain@rand-unix
4211: Status: O
4212:
4213:
4214: TWIMC
4215: -----
4216:
4217: Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp:
4218: i.e. if you wish to interrupt a Franzlisp computation, browse around the state
4219: and resume computation:
4220:
4221: Hit DEL;
4222: Browse;
4223: (return t)
4224:
4225: This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay).
4226:
4227: -- Sanjai
4228:
4229: From Tim%UPenn.UPenn@UDel-Relay Tue Jun 21 14:52:53 1983
4230: Date: Tue, 21 Jun 83 10:33 EDT
4231: From: Tim Finin <Tim.UPenn@UDel-Relay>
4232: Subject: interrupting Franz
4233: Return-Path: <Tim%UPenn.UPenn@UDel-Relay>
4234: Message-Id: <[email protected]>
4235: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4236: id AA12930; 21 Jun 83 14:52:36 PDT (Tue)
4237: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4238: id AA21097; 21 Jun 83 14:52:53 PDT (Tue)
4239: To: [email protected]
4240: Via: UPenn; 21 Jun 83 17:40-EDT
4241: Status: O
4242:
4243:
4244: Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.
4245:
4246: From jkf Sat Jun 25 13:49:37 1983
4247: Date: 25 Jun 83 13:49:37 PDT (Sat)
4248: From: jkf (John Foderaro)
4249: Subject: opus 38.65
4250: Message-Id: <[email protected]>
4251: Received: by UCBKIM.ARPA (3.340/3.5)
4252: id AA25527; 25 Jun 83 13:49:37 PDT (Sat)
4253: To: local-lisp
4254: Status: O
4255:
4256: If you have automatic case conversion set (i.e. (sstatus uctolc t)),
4257: then symbols with lower case letters will be escaped by print.
4258:
4259:
4260:
4261: From layer Tue Jul 5 00:26:29 1983
4262: Date: 5 Jul 1983 0026-PDT (Tuesday)
4263: From: layer (Kevin Layer)
4264: Subject: lisp opus 38.67
4265: Message-Id: <5390.30.426237985@ucbkim>
4266: Received: by UCBKIM.ARPA (3.340/3.5)
4267: id AA05911; 5 Jul 83 00:26:29 PDT (Tue)
4268: Phone: (415) 652-2405
4269: To: local-lisp
4270: Cc: layer
4271: Status: O
4272:
4273: The function 'sortcar' has been slightly changed: if the second
4274: arg is nil, then the ordering function 'alphalessp' is assumed
4275: ('sort' does it this way).
4276:
4277: Kevin
4278:
4279: From layer Wed Jul 6 00:02:33 1983
4280: Date: 6 Jul 83 00:02:33 PDT (Wed)
4281: From: layer (Kevin Layer)
4282: Subject: liszt opus 8.30
4283: Message-Id: <[email protected]>
4284: Received: by UCBKIM.ARPA (3.340/3.5)
4285: id AA24776; 6 Jul 83 00:02:33 PDT (Wed)
4286: Phone: (415) 652-2405
4287: To: local-lisp
4288: Cc: sklower, jkf
4289: Status: O
4290:
4291: All modifications should be transparent, but if there are problems
4292: relating to the autorun feature (-r flag), please let me know.
4293:
4294: Kevin
4295:
4296:
4297:
4298: From sklower Thu Jul 7 00:27:52 1983
4299: Date: 7 Jul 83 00:27:52 PDT (Thu)
4300: From: sklower (Keith Sklower)
4301: Subject: Franz, opus38.68
4302: Message-Id: <[email protected]>
4303: Received: by UCBKIM.ARPA (3.340/3.5)
4304: id AA10697; 7 Jul 83 00:27:52 PDT (Thu)
4305: To: local-lisp
4306: Status: O
4307:
4308: Franz now escapes UPPER case letters instead of lower case letters when
4309: (status uctolc) is enabled, so that (read (print x)) is an identity operation
4310: on atom printnames. Also, we made (explode) conform to what maclisp does
4311: with opposite-than-normal character-cases.
4312:
4313: From Ira%UPenn.UPenn@UDel-Relay Fri Jul 8 01:46:25 1983
4314: Date: Thu, 7 Jul 83 22:13 EDT
4315: From: Ira Winston <Ira.UPenn@UDel-Relay>
4316: Subject: Eliza
4317: Return-Path: <Ira%UPenn.UPenn@UDel-Relay>
4318: Message-Id: <[email protected]>
4319: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4320: id AA16294; 8 Jul 83 01:45:43 PDT (Fri)
4321: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4322: id AA01687; 8 Jul 83 01:46:25 PDT (Fri)
4323: To: [email protected]
4324: Via: UPenn; 8 Jul 83 3:07-EDT
4325: Status: O
4326:
4327: Does anyone have a version of Eliza that runs under Franz Lisp?
4328:
4329: From layer Fri Jul 8 18:04:10 1983
4330: Date: 8 Jul 1983 1804-PDT (Friday)
4331: From: layer (Kevin Layer)
4332: Subject: lisp opus 38.69
4333: Message-Id: <7031.30.426560643@ucbkim>
4334: Received: by UCBKIM.ARPA (3.340/3.5)
4335: id AA07142; 8 Jul 83 18:04:10 PDT (Fri)
4336: Phone: (415) 652-2405
4337: To: local-lisp
4338: Cc: layer
4339: Status: O
4340:
4341: 'setf' now knows about 'nthelem', and there are two new functions:
4342:
4343: (readdir 's_direct)
4344: returns a list of the contents of the directory s_direct.
4345:
4346: (dirp 's_name)
4347: returns s_name if s_name is a directory. This doesn't
4348: insure that you can read the directory, though (only
4349: uses stat(2)).
4350:
4351: Kevin
4352:
4353: From layer Fri Jul 8 20:57:13 1983
4354: Date: 8 Jul 1983 2057-PDT (Friday)
4355: From: layer (Kevin Layer)
4356: Subject: new function readdir
4357: Message-Id: <465.30.426571029@ucbkim>
4358: Received: by UCBKIM.ARPA (3.340/3.5)
4359: id AA00480; 8 Jul 83 20:57:13 PDT (Fri)
4360: Phone: (415) 652-2405
4361: To: local-lisp
4362: Fcc: record
4363: Status: O
4364:
4365: The function 'readdir' and 'dirp' should not be relied on yet, since
4366: they are provisional, because they are implemented with C library
4367: functions only available on 4.1+ systems.
4368:
4369: Kevin
4370:
4371: From Pwh%GaTech.GATech@UDel-Relay Tue Jul 12 18:08:46 1983
4372: Date: 11 Jul 83 20:36:32-EDT (Mon)
4373: From: <pwh.gatech@UDel-Relay>
4374: Subject: Franz flavors?
4375: Return-Path: <Pwh%GaTech.GATech@UDel-Relay>
4376: Message-Id: <[email protected]>
4377: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4378: id AA03336; 12 Jul 83 18:07:40 PDT (Tue)
4379: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4380: id AA20140; 12 Jul 83 18:08:46 PDT (Tue)
4381: To: [email protected]
4382: Cc: jlk.Gatech@UDel-Relay
4383: Via: GATech; 12 Jul 83 2:43-EDT
4384: Status: O
4385:
4386: We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our
4387: long awaited Symbolics Lisp Machine up and running and are trying to establish
4388: some measure of compatability between Franz and Zeta Lisp (as appropriate).
4389: Janet seems to recall some mention of a flavor package for Franz. Is this
4390: Berkley based or can anyone provide some clues as to where to check next?
4391:
4392: Also, when is the next release of Franz scheduled and what features will it
4393: incorporate?
4394:
4395: If the flavor package is non-existent, we will probably be forced to develop
4396: one here and will, of course, be glad to pass anything useful along.
4397:
4398: phil hutto
4399:
4400: From narain@rand-unix Tue Jul 12 20:10:42 1983
4401: Date: Tuesday, 12 Jul 1983 19:49-PDT
4402: From: narain@rand-unix
4403: Subject: Re: Franz flavors?
4404: Message-Id: <[email protected]>
4405: Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33)
4406: id AA05908; 12 Jul 83 20:09:41 PDT (Tue)
4407: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4408: id AA21387; 12 Jul 83 20:10:42 PDT (Tue)
4409: To: <pwh.gatech@UDEL-RELAY>
4410: Cc: [email protected], jlk.Gatech@UDEL-RELAY
4411: In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon).
4412: <[email protected]>
4413: Status: O
4414:
4415:
4416: We at Rand are interested in developing a set of guidelines for writing
4417: code that will be compatible with each of Zeta- Franz- and PSL Lisps. I
4418: would be grateful if you could tell us of what your experiences have been with
4419: making Franzlisp code work on the Symbolics machine. We would gladly share
4420: our own with you if you wish; incidentally we also have an IJCAI paper on a
4421: related issue.
4422:
4423: -- Sanjai Narain
4424:
4425: From liz.umcp-cs@UDel-Relay Wed Jul 13 00:55:26 1983
4426: Date: 13 Jul 83 03:09:39 EDT (Wed)
4427: From: Liz Allen <liz.umcp-cs@UDel-Relay>
4428: Subject: Re: Franz flavors?
4429: Return-Path: <liz.umcp-cs@UDel-Relay>
4430: Message-Id: <[email protected]>
4431: Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33)
4432: id AA10367; 13 Jul 83 00:54:32 PDT (Wed)
4433: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4434: id AA24477; 13 Jul 83 00:55:26 PDT (Wed)
4435: To: pwh.gatech@UDel-Relay, [email protected]
4436: Cc: jlk.Gatech@UDel-Relay
4437: Via: UMCP-CS; 13 Jul 83 3:23-EDT
4438: Status: O
4439:
4440: Here at the Univ of Maryland, we do have an implementation of
4441: flavors in Franz Lisp and have used it successfully in several
4442: large systems. It doesn't contain all the features of the Lisp
4443: Machine Flavors, but it does implement all the major ones. It is
4444: also different in a few ways that are necessitated by the limitations
4445: of Franz Lisp (shallow binding without invisible pointers or true
4446: closures -- though closures may be in the very newest versions of
4447: Franz -- we have opus 38.26). The package uses a hashing scheme
4448: for looking up methods, and the function <- which is used to send
4449: a message to an object is written in C. Together, this makes it
4450: an efficient implementation.
4451:
4452: We are currently working on a new policy for distributing flavors,
4453: our other lisp packages and our window package. When we have worked
4454: it out, I will announce the details here.
4455:
4456: -Liz
4457:
4458: From @MIT-MC:mdm@cmu-ri-isl Thu Jul 14 11:07:57 1983
4459: Date: 14 Jul 1983 14:03:01-EDT
4460: From: Malcolm.McRoberts@CMU-RI-ISL
4461: Subject: random numbers
4462: Message-Id: <[email protected]>
4463: Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35)
4464: id AA05735; Thu, 14 Jul 83 11:06:45 PDT
4465: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4466: id AA13687; 14 Jul 83 11:07:57 PDT (Thu)
4467: Apparently-To: <franz-friends@UCB-VAX>
4468: Status: O
4469:
4470: I am interested in obtaining a GOOD random number generator that is callable
4471: from Franz. My only real requirements are that it accept a seed (so that I
4472: can duplicate the same series), is fairly good (try doing several (random
4473: 4)'s in Franz and see what you get), and is of intermediate speed. If you
4474: know of such an animal please send me mail telling me how to get it.
4475: thanks
4476:
4477:
4478: From kanderso@bbn-vax Thu Jul 14 12:49:58 1983
4479: Date: 14 Jul 1983 15:47:19 EDT (Thursday)
4480: From: Ken Anderson <kanderso@bbn-vax>
4481: Subject: Random numbers
4482: Message-Id: <[email protected]>
4483: Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35)
4484: id AA06936; Thu, 14 Jul 83 12:48:49 PDT
4485: Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5)
4486: id AA15607; 14 Jul 83 12:49:58 PDT (Thu)
4487: To: [email protected]
4488: Cc: Malcolm.McRoberts@CMU-RI-ISL
4489: Status: O
4490:
4491: Here is a random number generator i use. It seems to work fairly well, but i have
4492: not looked to closely at the statistics. Since it will occasionally require
4493: bignums, it is probably not the fastest either. I was just looking for something
4494: that was likely to be portable between LISP's.
4495: I would be very interested in hearing your evaluation of it.
4496:
4497: k
4498:
4499: ;;; RANDOM NUMBERS
4500: (declare (macros t))
4501: (include math.h)
4502:
4503: (defvar $uniform-a 16807) ; = 7^5
4504: (defvar $mersenne-prime 2147483647) ; = 2^31 - 1
4505: (defvar $mersenne-prime-1 (- $mersenne-prime 1))
4506:
4507: (defmacro with-seed (s-newseed . body)
4508: ; evaluates body with the seed of the random numbers set to s-newseed.
4509: ; the value of s-newseed is updated. Thus this is a way of
4510: ; Keepining several sequences of random numbers with their own seeds
4511: `(let (($uniform-seed ,s-newseed))
4512: (prog1 (progn ,@body)
4513: (setq ,s-newseed $uniform-seed))))
4514:
4515: (defun uniform-basic (previous-fixnum)
4516: ; -> a fixnum 0 < fixnum < 2^31 - 1
4517: ; Repeated calls will generate fixnums in the range
4518: ; 1 -> 2^31 - 2.
4519:
4520: ; The basic idea is new = A^k * old (mod p)
4521: ; where A is a primitive root of p, k is not a factor of p-1
4522: ; and p is a large prime.
4523:
4524: ; This is a good random number generator but is not be the fastest!
4525: ; On FRANZ LISP, and LISP MACHINE it will require bignums since
4526: ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder
4527: ; can be done more efficiently.
4528: ; See: Linus Schrage, A More Portable Fortran Random Number Generator,
4529: ; ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979.
4530: (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime))
4531:
4532: (defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1
4533:
4534: (defun uniform ()
4535: ; -> the next uniform random number in the sequence
4536: ; To have your own sequence, rebind $uniform-seed.
4537: (setq $uniform-seed (uniform-basic $uniform-seed)))
4538:
4539: (defun uniform-between (low-num high-num)
4540: ; -> a uniform random number, x, low-num <= x <= high-num
4541: ; If low-num and high-num are fixnums, a fixnum is returned.
4542: (cond ((not (and (fixp low-num) (fixp high-num)))
4543: (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1))
4544: (-$ high-num low-num))))
4545: (t (+ low-num (// (uniform)
4546: (// $mersenne-prime-1 (max 1 (- high-num low-num -1))))))))
4547:
4548: (defun gaussian-random-1 ()
4549: ; -> a gaussian random variable with mean 0.0 and
4550: ; standard deviation 1.0.
4551: ; Good tails.
4552: (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0))))
4553: (sin (*$ $2pi (uniform-between 0.0 1.0)))))
4554:
4555: (defun gaussian-random (mean standard-deviation)
4556: (+$ mean (*$ (gaussian-random-1) standard-deviation)))
4557:
4558: ;;(defun gaussian (x)
4559: ;; (* (sqrt $2pi)
4560: ;; (exp (minus (// (square x) 2.0)))))
4561:
4562: (defun random-yes-no (fraction-yes)
4563: (<= (uniform-between 0.0 1.0) fraction-yes))
4564:
4565:
4566: From layer Sat Jul 30 15:46:42 1983
4567: Date: 30 Jul 1983 1546-PDT (Saturday)
4568: From: layer (Kevin Layer)
4569: Subject: liszt opus 8.33
4570: Message-Id: <19472.30.428453197@ucbkim>
4571: Received: by UCBKIM.ARPA (3.340/3.5)
4572: id AA19498; 30 Jul 83 15:46:42 PDT (Sat)
4573: Phone: (415) 652-2405
4574: To: local-lisp
4575: Status: O
4576:
4577: Vset is now open coded. There should be no visible change in the
4578: behaviour of vectors, except in speed (greater, that is), and
4579: vsize-{byte,word} work properly now.
4580:
4581: Bugs to me.
4582:
4583: Kevin
4584:
4585: From jkf Mon Aug 1 14:41:28 1983
4586: Received: by ucbkim.ARPA (4.2/4.2)
4587: id AA03743; Mon, 1 Aug 83 14:41:28 PDT
4588: Date: Mon, 1 Aug 83 14:41:28 PDT
4589: From: jkf (John Foderaro)
4590: Message-Id: <[email protected]>
4591: To: local-lisp
4592: Subject: defstruct
4593: Status: O
4594:
4595: defstruct now understands two more types of structures:
4596: :vector
4597: :named-vector
4598:
4599: A named vector has the defstruct structure name on the vector property
4600: list, thus an instance of the foo structure would print as 'foo[8]'.
4601:
4602:
4603: :named-vector is now the default structure type (instead of :hunk).
4604:
4605:
4606:
4607:
4608: From jkf Tue Aug 2 15:20:04 1983
4609: Received: by ucbkim.ARPA (4.2/4.2)
4610: id AA26686; Tue, 2 Aug 83 15:20:04 PDT
4611: Date: Tue, 2 Aug 83 15:20:04 PDT
4612: From: jkf (John Foderaro)
4613: Message-Id: <[email protected]>
4614: To: local-lisp
4615: Subject: lisp opus 38.70
4616: Status: RO
4617:
4618: When a vector is printed, the size in square brackets will be the number
4619: of entries (not the number of bytes). The size printed for vectori
4620: objects will continue to be the number of bytes.
4621:
4622: Also, if the property of a vector is a list with the car being a non nil
4623: symbol, and if that list doesn't have a print property, then that
4624: symbol will be printed rather than 'vector' or 'vectori'.
4625:
4626:
4627:
4628: From layer Thu Aug 4 02:10:12 1983
4629: Received: by ucbkim.ARPA (4.2/4.2)
4630: id AA11660; Thu, 4 Aug 83 02:10:12 PDT
4631: From: layer (Kevin Layer)
4632: Phone: (415) 652-2405
4633: Date: 4 Aug 1983 0210-PDT (Thursday)
4634: Message-Id: <11649.30.428836207@ucbkim>
4635: To: local-lisp
4636: Subject: liszt opus 8.34
4637: Status: RO
4638:
4639: I just installed a new compiler. For the vax, there shouldn't be
4640: any visible changes, though a couple of vector bugs were fixed. For
4641: the 68000, the vector access functions are now open coded, and the
4642: new one was installed on mike, rob, and chip in /usr/ucb.
4643:
4644: Kevin
4645:
4646: From FRD@SU-AI Fri Aug 5 15:57:17 1983
4647: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4648: id AA10610; Fri, 5 Aug 83 15:57:17 PDT
4649: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
4650: id AA10357; Fri, 5 Aug 83 15:54:22 PDT
4651: Message-Id: <[email protected]>
4652: Date: 05 Aug 83 1353 PDT
4653: From: Fred Lakin <FRD@SU-AI>
4654: Subject: Franz & SUNs
4655: To: franz-friends@BERKELEY
4656: Status: RO
4657:
4658: I am interested in connectons between Franz and SUN workstations.
4659: Like how far along is Franz on the SUN? Is there some package
4660: which allows Franz on a VAX to use a SUN as a display device?
4661:
4662: Any info on this matter would be appreciated.
4663: Thnaks, Fred Lakin
4664:
4665:
4666: From tektronix!ogcvax!metheus!tombl Sat Aug 6 09:49:57 1983
4667: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4668: id AA21229; Sat, 6 Aug 83 09:49:57 PDT
4669: Received: by UCBVAX.ARPA (3.347/3.35)
4670: id AA13549; Sat, 6 Aug 83 09:40:11 PDT
4671: Message-Id: <[email protected]>
4672: From: ogcvax!metheus!tombl
4673: To: ogcvax!tektronix!ucbvax!franz-friends
4674: Cc: ogcvax!tektronix!ucbvax!sklower
4675: Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT
4676: Subject: bug in Opus 38.66
4677: Date: Fri Aug 5 20:46:56 1983
4678: Status: O
4679:
4680:
4681: A bug present in previous versions is also present in 38.66 of Franz.
4682: cfasl fails (in most cases) to close the file it reads from.
4683: Consequently, mysterious events occur when the maximum number of open
4684: file descriptors is reached.
4685:
4686: The fix is made in the file ffasl.c. "close(fildes)" should be
4687: prepended to the two return sequences from (the Unix code for)
4688: Lcfasl:
4689:
4690: ------------------------------------------------------------------
4691: Old: 146c146
4692: < {Restorestack(); return(nil);}
4693: ---
4694: Fixed: > {close(fildes); Restorestack(); return(nil);}
4695: 149a150
4696: > close(fildes);
4697: ------------------------------------------------------------------
4698:
4699:
4700: Tom Blenko
4701: Metheus Corp.
4702: ucbvax!tektronix!ogcvax!metheus!tombl
4703: allegra!ogcvax!metheus!tombl
4704:
4705:
4706:
4707: From FRD@SU-AI Sun Aug 7 12:34:43 1983
4708: Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2)
4709: id AA10610; Fri, 5 Aug 83 15:57:17 PDT
4710: Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35)
4711: id AA10357; Fri, 5 Aug 83 15:54:22 PDT
4712: Message-Id: <[email protected]>
4713: Date: 05 Aug 83 1353 PDT
4714: From: Fred Lakin <FRD@SU-AI>
4715: Subject: Franz & SUNs
4716: To: franz-friends@BERKELEY
4717: Status: O
4718:
4719: I am interested in connectons between Franz and SUN workstations.
4720: Like how far along is Franz on the SUN? Is there some package
4721: which allows Franz on a VAX to use a SUN as a display device?
4722:
4723: Any info on this matter would be appreciated.
4724: Thnaks, Fred Lakin
4725:
4726:
4727: From jkf Mon Aug 8 09:06:49 1983
4728: Received: by ucbkim.ARPA (4.2/4.2)
4729: id AA06584; Mon, 8 Aug 83 09:06:49 PDT
4730: Date: Mon, 8 Aug 83 09:06:49 PDT
4731: From: jkf (John Foderaro)
4732: Message-Id: <[email protected]>
4733: To: local-lisp
4734: Subject: opus 38.72
4735: Status: O
4736:
4737: A bug was fixed in defmacro which caused the &protect option and
4738: displace-macros to interact poorly.
4739:
4740:
4741:
4742: From jkf Fri Aug 12 22:11:13 1983
4743: Received: by ucbkim.ARPA (4.2/4.2)
4744: id AA25610; Fri, 12 Aug 83 22:11:13 PDT
4745: Date: Fri, 12 Aug 83 22:11:13 PDT
4746: From: jkf (John Foderaro)
4747: Message-Id: <[email protected]>
4748: To: local-lisp
4749: Subject: opus 38.73
4750: Status: O
4751:
4752: 'equal' will now compare all types of vectors for equality.
4753:
4754: 'copy' will now copy all types of vectors.
4755:
4756:
4757:
4758:
4759: From layer Mon Aug 15 20:03:53 1983
4760: Received: by ucbkim.ARPA (4.2/4.2)
4761: id AA03597; Mon, 15 Aug 83 20:03:53 PDT
4762: From: layer (Kevin Layer)
4763: Phone: (415) 652-2405
4764: Date: 15 Aug 1983 2003-PDT (Monday)
4765: Message-Id: <3556.30.429851029@ucbkim>
4766: To: local-lisp
4767: Subject: liszt opus 8.35
4768: Fcc: record
4769: Status: RO
4770:
4771: Several things have changed:
4772:
4773: 1) Bugs in the open coding of vectors have been fixed.
4774:
4775: 2) Minor re-organization of the compiler source code.
4776:
4777: 3) The routine to determine whether or not tail merging is
4778: possible underwent major modification.
4779:
4780: 4) Lexpr's are compiled differently, or rather the way lexpr args
4781: are accessed has changed. For those that want to know, here is
4782: the nitty gritty:
4783:
4784: Consider a the following lexpr: (defun test nargs ...).
4785: The arguments to the lexpr are stacked on the name stack
4786: (low to high number), and then nargs is stacked. The user
4787: is allowed to change the binding of 'nargs' to anything
4788: he likes, so we have to have another way to access the arguments
4789: on the name stack (i.e., other than an offset from nargs).
4790: Before, a pointer to the argument base was pushed on the
4791: C stack, so that indexing could be done from there.
4792: The addressing modes used to do this are not available
4793: on the MC68000 (something like *n(fp)[Rx]), so now
4794: nargs is pushed on the name stack twice, and the location
4795: of an argument can be easily calculated as an offset from nargs.
4796:
4797: In short, lots of thing changed. The SUN's should be updated
4798: in the next couple of days (after I test it out). Bugs to me...
4799:
4800: Kevin
4801:
4802: From jkf Mon Aug 15 23:11:08 1983
4803: Received: by ucbkim.ARPA (4.2/4.2)
4804: id AA05928; Mon, 15 Aug 83 23:11:08 PDT
4805: Date: Mon, 15 Aug 83 23:11:08 PDT
4806: From: jkf (John Foderaro)
4807: Message-Id: <[email protected]>
4808: To: local-lisp
4809: Subject: opus 38.74
4810: Status: O
4811:
4812:
4813: If a vector has a 'unique' property on it's property list, then it will
4814: not be copied by 'copy'.
4815:
4816: 'untrace' will now autoload /usr/lib/lisp/trace.
4817:
4818: A number of functions and macros were contributed by the bair group:
4819:
4820:
4821:
4822:
4823:
4824:
4825:
4826:
4827: (<= 'fx_arg1 'fx_arg2 ...)
4828: (<=& 'x_arg1 'x_arg2)
4829:
4830: RETURNS: t iff (> 'fx_arg1 'fx_arg2) [or (>& 'x_arg1
4831: 'x_arg2)] is nil, otherwise nil. The general
4832: function, <=, can take more than two argu-
4833: ments.
4834:
4835: (>= 'fx_arg1 'fx_arg2)
4836: (>=& 'x_arg1 'x_arg2)
4837:
4838: RETURNS: t iff (< 'fx_arg1 'fx_arg2 ...) [or (<&
4839: 'x_arg1 'x_arg2)] is nil, otherwise nil.
4840:
4841: NOTE: The general function, >=, can take more than two
4842: arguments.
4843:
4844: (litatom 'g_arg)
4845:
4846: RETURNS: t iff g_arg is an atom, but not a number.
4847:
4848: (nequal 'g_x 'g_y)
4849:
4850: RETURNS: t iff g_x is not equal to g_y, otherwise nil.
4851:
4852: (lineread [['p_port] ['s_flag]])
4853:
4854: RETURNS: a list consisting of s-expressions on a line
4855: from the port p_port (or piport if p_port is
4856: not given). If an s-expression (e.g., a list)
4857: takes more than one line, or a line terminates
4858: in a space or tab, then lineread continues
4859: reading until an expression ends at the end of
4860: a line.
4861:
4862: NOTE: If s_flag is t, then if the first character on a
4863: line is a newline, lineread performs a tyi and
4864: returns nil. If s_flag is nil or not present,
4865: lineread does a read skipping over any blank
4866: lines to make sure that an s-expression is actu-
4867: ally read.
4868:
4869: SIDE EFFECT: lineread uses read, advancing the port
4870: character pointer.
4871:
4872:
4873:
4874:
4875:
4876:
4877:
4878:
4879: 9
4880:
4881: 9
4882:
4883:
4884:
4885:
4886:
4887:
4888:
4889:
4890:
4891:
4892: (defv g_arg1 g_arg2)
4893:
4894: EQUIVALENT TO: (set g_arg1 g_arg2)
4895:
4896: (pp-form 'g_form ['p_port] ['n_lmar])
4897:
4898: RETURNS: nil
4899:
4900: SIDE EFFECT: g_form is pretty-printed to the port
4901: p_port (or poport if p_port is not given).
4902: If pp-form is also supplied with an
4903: integer (n_lmar), that integer will be
4904: used as a left margin setting (0 is the
4905: default). This is the function which pp
4906: uses (n_lmar = 0). pp-form does not look
4907: for function definitions or values of
4908: variables, it just prints out the form it
4909: is given.
4910:
4911: NOTE: This is useful as a top-level-printer, c.f. top-
4912: level in Chapter 6.
4913:
4914: (sload 's_file1 ...)
4915:
4916: SIDE EFFECT: The files named are opened for reading and
4917: each form is read, optionally printed, and
4918: evaluated.
4919:
4920: NOTE: What sload prints is controlled by the special
4921: atom $sldprint. If $sldprint is t (default),
4922: then if a form is recognizable as a function
4923: definition, only the function name is printed,
4924: otherwise the whole form is printed. If
4925: $sldprint is eq to value, then the result of each
4926: form's evaluation will also be printed. Printing
4927: the forms' values can be controlled by setting
4928: sload-print equal to the name of the function to
4929: be called. sload recognizes named functions by
4930: looking at the sloadprintarg property of the
4931: function name. The value of the sloadprintarg
4932: property should be the argument number of the
4933: function name. For the standard Franz Lisp func-
4934: tions, the properties are already set.
4935:
4936: EXAMPLE: (defprop def 1 sloadprintarg) ; This is the
4937: default--declaring that
4938: ; the name of
4939: the function definition is the
4940: ; first argu-
4941: ment.
4942:
4943:
4944: 9
4945:
4946: 9
4947:
4948:
4949:
4950:
4951:
4952:
4953:
4954:
4955:
4956:
4957: The functions described below are an alternative
4958: to the gensym facility. They generate new symbols by
4959: attaching counter numbers to the ends of the symbols'
4960: names. An example follows of how the functions are
4961: used.
4962:
4963:
4964: ____________________________________________________
4965:
4966: -> (initsym joe (john 5)) ; initializing new symbol counters
4967: (joe0 john5)
4968: -> (newsym john) ; create a new symbol
4969: john6
4970: -> (newsym chuck) ; symbol need not be initsym'ed
4971: chuck0
4972: -> (oldsym john) ; get current symbol
4973: john6
4974: -> (allsym john) ; get all symbols between 0 and counter
4975: (john0 john1 john2 john3 john4 john5 john6)
4976: -> (allsym (john 5)) ; get all symbols between 5 and counter
4977: (john5 john6)
4978: -> (remsym joe (john 4)) ; remob all interned symbols
4979: ; associated with joe and from
4980: ; john4 to the current john
4981: ; symbol--returns symbols with symbol counters
4982: ; before doing remsym
4983: (joe0 john6)
4984: -> (symstat joe john)
4985: ((joe nil) (john 3))
4986: ____________________________________________________
4987:
4988:
4989:
4990:
4991: (initsym g_arg1 ...)
4992:
4993: WHERE: g_argi is a list (n_counteri s_argi) or a
4994: string s_argi (which is equivalent to (0
4995: s_argi)).
4996:
4997: RETURNS: a list of interned identifiers using the sym-
4998: bol counters n_counteri, i.e., the result of
4999: concatenating s_argi to n_counteri.
5000:
5001: EXAMPLE: (initsym joe (john 5)) ==> (joe0 john5)
5002:
5003: NOTE: See also newsym, oldsym, allsym, remsym, and sym-
5004: stat functions.
5005:
5006:
5007:
5008:
5009: 9
5010:
5011: 9
5012:
5013:
5014:
5015:
5016:
5017:
5018:
5019:
5020:
5021:
5022: (newsym s_arg)
5023:
5024: RETURNS: an interned identifier formed by concatenating
5025: the name s_arg to the symbol counter for
5026: s_arg. The symbol counter is stored on the
5027: property list of s_arg under symctr. If there
5028: is no counter, a counter of 0 is used and
5029: added to the property list. Thus, a symbol
5030: need not be initsymed.
5031:
5032: EXAMPLE: (initsym joe (john5)) ==> (joe0 john5)
5033: (newsym john) ==> john6
5034: (newsym joe) ==> joe1
5035:
5036: NOTE: See also initsym, oldsym, allsym, remsym, and
5037: symstat functions.
5038:
5039: (oldsym s_arg)
5040:
5041: RETURNS: the identifier using the current symbol
5042: counter for s_arg, rather than creating a new
5043: identifier. If no symbol counter exists for
5044: s_arg, then s_arg is returned.
5045:
5046: NOTE: See also initsym, newsym, allsym, remsym, and
5047: symstat functions.
5048:
5049: (allsym g_arg)
5050:
5051: WHERE: g_arg is a list (s_arg n_counter) or a string
5052: s_arg (equivalent to (s_arg 0)).
5053:
5054: RETURNS: a list of all the created identifiers between
5055: n_counter and the current symbol counter for
5056: s_arg.
5057:
5058: EXAMPLE: (allsym john) ==> (john0 john1 john2)
5059:
5060: NOTE: See also initsym, newsym, oldsym, remsym, and
5061: symstat functions.
5062:
5063: (remsym g_arg1 ...)
5064:
5065: WHERE: g_argi is a list (s_argi n_counteri) or a
5066: string s_argi (which is equivalent to (s_argi
5067: 0)).
5068:
5069: RETURNS: a list of symbols s_argi with the current sym-
5070: bol counters.
5071:
5072: SIDE EFFECT: remsym remob's all the created identifiers
5073: between zero and the current symbol
5074: counter for s_argi.
5075:
5076:
5077:
5078:
5079:
5080:
5081:
5082:
5083:
5084:
5085:
5086:
5087:
5088: NOTE: See also initsym, newsym oldsym, allsym, and sym-
5089: stat functions.
5090:
5091: (symstat s_arg1 ...)
5092:
5093: RETURNS: a list of pairs consisting of (s_argi symctri)
5094: where symctri is s_argi's current symbol
5095: counter.
5096:
5097: NOTE: See also initsym, newsym, oldsym, allsym, and
5098: remsym functions.
5099:
5100:
5101:
5102:
5103:
5104:
5105:
5106:
5107:
5108:
5109:
5110:
5111:
5112:
5113:
5114:
5115:
5116:
5117:
5118:
5119:
5120:
5121:
5122:
5123:
5124:
5125:
5126:
5127:
5128:
5129:
5130:
5131:
5132:
5133:
5134:
5135:
5136:
5137:
5138:
5139:
5140: 9
5141:
5142: 9
5143:
5144:
5145:
5146:
5147:
5148:
5149: From jkf Thu Aug 18 19:25:45 1983
5150: Received: by ucbkim.ARPA (4.2/4.2)
5151: id AA09885; Thu, 18 Aug 83 19:25:45 PDT
5152: Date: Thu, 18 Aug 83 19:25:45 PDT
5153: From: jkf (John Foderaro)
5154: Message-Id: <[email protected]>
5155: To: local-lisp
5156: Subject: opus 38.75
5157: Status: O
5158:
5159: evalhook and funcallhook can now be executed without setting (*rset t)
5160: and (sstatus evalhook t). Although they can be executed, they won't
5161: have any effect unless and until (*rset t) and (sstatus evalhook t) are
5162: done.
5163: The reason for this change is that now one can turn off stepping
5164: by (sstatus evalhook nil) and then continue the evaluation with
5165: evalhook and funcallhook.
5166:
5167: Those who use the new top-level 'tpl' will notice a few new commands
5168: dealing with stepping when you type '?help'. These new commands
5169: are ?step, ?soff, and ?sc. Details of the commands are available
5170: using the help mechanism (e.g. '?help step').
5171:
5172:
5173:
5174:
5175: From jkf Fri Aug 19 13:54:26 1983
5176: Received: by ucbkim.ARPA (4.2/4.2)
5177: id AA20017; Fri, 19 Aug 83 13:54:26 PDT
5178: Date: Fri, 19 Aug 83 13:54:26 PDT
5179: From: jkf (John Foderaro)
5180: Message-Id: <[email protected]>
5181: To: local-lisp
5182: Subject: liszt 8.36
5183: Status: O
5184:
5185: The compiler will now compile the form
5186: (*no-macroexpand* <form>)
5187: in a special way: if <form> is a function call, e.g. (name arg1 ...),
5188: then any macro properties of 'name' will be ignored for this
5189: invocation. This permits one to write macros which attempt
5190: an optimization, and if that fails, then call the standard
5191: function. *no-macroexpand* is not a function that can be called,
5192: thus forms with *no-macroexpand* are likely to be 'cmacros'.
5193: Here is an example:
5194:
5195: (defcmacro length (x &protect (x))
5196: `(if (null ,x)
5197: then 0
5198: elseif (null (cdr ,x))
5199: then 1
5200: else (*no-macroexpand* (length ,x))))
5201:
5202:
5203: [in case you are wondering, the `&protect (x)' means that
5204: should the actual argument to 'length' be a non atom, defcmacro
5205: will lambda bind the value, insuring that it is only evaluated
5206: once]
5207:
5208:
5209:
5210:
5211: From layer Wed Aug 24 22:18:34 1983
5212: Received: by ucbkim.ARPA (4.6/4.2)
5213: id AA12256; Wed, 24 Aug 83 22:18:34 PDT
5214: From: layer (Kevin Layer)
5215: Phone: (415) 652-2405
5216: Date: 24 Aug 1983 2218-PDT (Wednesday)
5217: Message-Id: <12219.30.430636709@ucbkim>
5218: To: local-lisp
5219: Subject: liszt on kim
5220: Status: O
5221:
5222: The liszt that I installed on kim yesterday, compiled eq's wrong
5223: in some rare cases. I installed a new one this evening that fixes
5224: this, but if you compiled any programs with the bad one, you might
5225: consider re-compiling them...
5226:
5227: Kevin
5228:
5229: From fateman Thu Aug 25 13:58:59 1983
5230: Received: by ucbkim.ARPA (4.6/4.2)
5231: id AA21033; Thu, 25 Aug 83 13:58:59 PDT
5232: Date: Thu, 25 Aug 83 13:58:59 PDT
5233: From: fateman (Richard Fateman)
5234: Message-Id: <[email protected]>
5235: To: local-lisp
5236: Status: O
5237:
5238: I have a copy of the latest Common Lisp manual... the Excelsior Edition.
5239:
5240: From patel@UCLA-LOCUS Tue Aug 30 21:58:38 1983
5241: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5242: id AA29417; Tue, 30 Aug 83 21:58:38 PDT
5243: Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4)
5244: id AA06203; Tue, 30 Aug 83 21:50:26 PDT
5245: Message-Id: <[email protected]>
5246: Date: Tue, 30 Aug 83 21:44:13 PDT
5247: From: Dorab Patel <patel@UCLA-LOCUS>
5248: To: franz-friends@BERKELEY
5249: Subject: bug fix for 'insert' in opus 38.50
5250: Status: O
5251:
5252: The function 'insert' in Opus 38.50 does not perform as advertised in
5253: the manual if the last argument is non-nil (i.e. if no duplicates are allowed.
5254: It still insists on putting the duplicate element into the list. The
5255: fix is in /usr/lib/lisp/common2.l. Just change the default setting
5256: of the 'comparefn' to that given below instead of
5257: (function alphalessp). Here is an excerpt from the modified file.
5258:
5259:
5260: [.....]
5261: (def insert
5262: (lambda (x l comparefn nodups)
5263: (cond ((null l) (list x))
5264: ((atom l)
5265: (error "an atom, can't be inserted into" l))
5266: (t (cond
5267: ((null comparefn) (setq comparefn
5268: (function
5269: (lambda (x y)
5270: (or (alphalessp x y)
5271: (equal x y)))))))
5272: (prog (l1 n n1 y)
5273: (setq l1 l)
5274: (setq n (length l))
5275: a (setq n1 (/ (add1 n) 2))
5276: (setq y (Cnth l1 n1))
5277: [..........]
5278:
5279: From jkf Sun Sep 4 09:59:01 1983
5280: Received: by ucbkim.ARPA (4.6/4.2)
5281: id AA03721; Sun, 4 Sep 83 09:59:01 PDT
5282: Date: Sun, 4 Sep 83 09:59:01 PDT
5283: From: jkf (John Foderaro)
5284: Message-Id: <[email protected]>
5285: To: local-lisp
5286: Subject: opus 38.77
5287: Status: O
5288:
5289: The 'error' function used to print its arguments and then call 'err' to
5290: cause the familar 'call to err' error. The problem with this is that
5291: even if you wrap your compuatation with (errset ... nil), the error message
5292: will still be printed. In opus 38.77, this problem has been fixed.
5293:
5294: A new function was added:
5295: (err-with-message 'st_message ['g_value])
5296: This causes an error to be signaled with the given message. The message
5297: will only be printed if an '(errset ... nil)' isn't being executed.
5298: Normally nil is returned from an errset if an error occured. If you provide
5299: g_value, then it will be returned from the errset.
5300: [Not surprisingly, 'error' now uses 'err-with-message']
5301:
5302:
5303: Also, 'error' now takes any number of arguments. In concatenates them,
5304: separated by spaces, and this is the error message passed to
5305: err-with-message.
5306:
5307:
5308:
5309:
5310: From narain@rand-unix Fri Sep 9 13:32:24 1983
5311: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5312: id AA16481; Fri, 9 Sep 83 13:32:24 PDT
5313: Received: from rand-unix (rand-unix.ARPA) by ucbvax.ARPA (4.12/4.7)
5314: id AA11010; Fri, 9 Sep 83 13:31:58 PDT
5315: Message-Id: <[email protected]>
5316: Date: Friday, 9 Sep 1983 10:55-PDT
5317: To: franz-friends@BERKELEY
5318: Cc: narain@rand-unix
5319: Subject: Franzlisp Question
5320: From: narain@rand-unix
5321: Status: O
5322:
5323:
5324: Hello all:
5325:
5326: I would be grateful if you could answer another question regarding Franzlisp.
5327: How does one make Franzlisp continue from an error? For example when Lisp
5328: gives an error message like "x unbound variable", is it possible to
5329: bind x to a value and make Lisp continue from that point? Right now we have
5330: to start over again and it is very time consuming.
5331:
5332: -- Sanjai
5333:
5334: From [email protected] Fri Sep 9 13:46:45 1983
5335: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5336: id AA16843; Fri, 9 Sep 83 13:46:45 PDT
5337: Received: from DEC-MARLBORO.ARPA by ucbvax.ARPA (4.12/4.7)
5338: id AA11248; Fri, 9 Sep 83 13:46:26 PDT
5339: Date: 9 Sep 1983 1427-EDT
5340: From: AUSTIN@DEC-MARLBORO
5341: To: FRANZ-FRIENDS@BERKELEY
5342: Subject: LIST MEMBERSHIP
5343: Message-Id: <"MS10(2124)+GLXLIB1(1136)" 11950297972.20.647.3882 at DEC-MARLBORO>
5344: Status: O
5345:
5346: PLEASE ADD ME TO FRANZ-FRIENDS@BERKELEY DISTRIBUTION.
5347:
5348: MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO.
5349:
5350: THANKS!
5351: --------
5352:
5353: From jkf Sat Sep 10 12:34:14 1983
5354: Received: by ucbkim.ARPA (4.6/4.2)
5355: id AA28421; Sat, 10 Sep 83 12:34:14 PDT
5356: Date: Sat, 10 Sep 83 12:34:14 PDT
5357: From: jkf (John Foderaro)
5358: Message-Id: <[email protected]>
5359: To: local-lisp
5360: Subject: opus 38.78
5361: Status: O
5362:
5363: The new functions contributed by the bair group dealing with symbol
5364: creation have been changed from fexprs to exprs (lambdas) and lexprs.
5365:
5366: The new documentation follows:
5367:
5368:
5369:
5370:
5371:
5372:
5373:
5374: The functions described below are an alternative to the
5375: gensym facility. They generate new symbols by attaching
5376: counter numbers to the ends of the symbols' names. An exam-
5377: ple follows of how the functions are used.
5378:
5379:
5380: ____________________________________________________
5381:
5382: -> (initsym 'joe '(john 5)) ; initializing new symbol counters
5383: (joe0 john5)
5384: -> (newsym 'john) ; create a new symbol
5385: john6
5386: -> (newsym 'chuck) ; symbol need not be initsym'ed
5387: chuck0
5388: -> (oldsym 'john) ; get current symbol
5389: john6
5390: -> (allsym 'john) ; get all symbols between 0 and counter
5391: (john0 john1 john2 john3 john4 john5 john6)
5392: -> (allsym '(john 5)) ; get all symbols between 5 and counter
5393: (john5 john6)
5394: -> (remsym 'joe '(john 4)) ; remob all interned symbols
5395: ; associated with joe and from
5396: ; john4 to the current john
5397: ; symbol--returns symbols with symbol counters
5398: ; before doing remsym
5399: (joe0 john6)
5400: -> (symstat 'joe 'john)
5401: ((joe nil) (john 3))
5402: ____________________________________________________
5403:
5404:
5405:
5406:
5407: (initsym 'g_arg1 ...)
5408:
5409: WHERE: g_argi is a list (n_counteri s_argi) or a
5410: string s_argi (which is equivalent to (0
5411: s_argi)).
5412:
5413: RETURNS: a list of interned identifiers using the sym-
5414: bol counters n_counteri, i.e., the result of
5415: concatenating s_argi to n_counteri.
5416:
5417: EXAMPLE: (initsym 'joe '(john 5)) ==> (joe0 john5)
5418:
5419: NOTE: See also newsym, oldsym, allsym, remsym, and sym-
5420: stat functions.
5421:
5422:
5423:
5424:
5425:
5426:
5427:
5428:
5429:
5430:
5431:
5432:
5433:
5434:
5435:
5436:
5437:
5438:
5439:
5440: (newsym 's_arg)
5441:
5442: RETURNS: an interned identifier formed by concatenating
5443: the name s_arg to the symbol counter for
5444: s_arg. The symbol counter is stored on the
5445: property list of s_arg under symctr. If there
5446: is no counter, a counter of 0 is used and
5447: added to the property list. Thus, a symbol
5448: need not be initsymed.
5449:
5450: EXAMPLE: (initsym 'joe '(john5)) ==> (joe0 john5)
5451: (newsym 'john) ==> john6
5452: (newsym 'joe) ==> joe1
5453:
5454: NOTE: See also initsym, oldsym, allsym, remsym, and
5455: symstat functions.
5456:
5457: (oldsym 's_arg)
5458:
5459: RETURNS: the identifier using the current symbol
5460: counter for s_arg, rather than creating a new
5461: identifier. If no symbol counter exists for
5462: s_arg, then s_arg is returned.
5463:
5464: NOTE: See also initsym, newsym, allsym, remsym, and
5465: symstat functions.
5466:
5467: (allsym 'g_arg)
5468:
5469: WHERE: g_arg is a list (s_arg n_counter) or a string
5470: s_arg (equivalent to (s_arg 0)).
5471:
5472: RETURNS: a list of all the created identifiers between
5473: n_counter and the current symbol counter for
5474: s_arg.
5475:
5476: EXAMPLE: (allsym 'john) ==> (john0 john1 john2)
5477:
5478: NOTE: See also initsym, newsym, oldsym, remsym, and
5479: symstat functions.
5480:
5481: (remsym 'g_arg1 ...)
5482:
5483: WHERE: g_argi is a list (s_argi n_counteri) or a
5484: string s_argi (which is equivalent to (s_argi
5485: 0)).
5486:
5487: RETURNS: a list of symbols s_argi with the current sym-
5488: bol counters.
5489:
5490: SIDE EFFECT: remsym remob's all the created identifiers
5491: between zero and the current symbol
5492: counter for s_argi.
5493:
5494:
5495:
5496:
5497:
5498:
5499:
5500:
5501:
5502:
5503:
5504:
5505:
5506: NOTE: See also initsym, newsym oldsym, allsym, and sym-
5507: stat functions.
5508:
5509: (symstat 's_arg1 ...)
5510:
5511: RETURNS: a list of pairs consisting of (s_argi symctri)
5512: where symctri is s_argi's current symbol
5513: counter.
5514:
5515: NOTE: See also initsym, newsym, oldsym, allsym, and
5516: remsym functions.
5517:
5518:
5519:
5520:
5521:
5522:
5523:
5524:
5525:
5526:
5527:
5528:
5529:
5530:
5531:
5532:
5533:
5534:
5535:
5536:
5537:
5538:
5539:
5540:
5541:
5542:
5543:
5544:
5545:
5546:
5547:
5548:
5549:
5550:
5551:
5552:
5553:
5554:
5555:
5556:
5557:
5558:
5559:
5560:
5561:
5562:
5563:
5564:
5565:
5566:
5567:
5568: From jkf@ucbkim Wed Sep 14 08:04:14 1983
5569: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5570: id AA14801; Wed, 14 Sep 83 08:04:14 PDT
5571: Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7)
5572: id AA04212; Wed, 14 Sep 83 08:03:58 PDT
5573: Received: by ucbkim.ARPA (4.6/4.2)
5574: id AA14786; Wed, 14 Sep 83 08:03:43 PDT
5575: Date: Wed, 14 Sep 83 08:03:43 PDT
5576: From: jkf@ucbkim (John Foderaro)
5577: Message-Id: <[email protected]>
5578: To: franz-friends@BERKELEY
5579: Subject: lisp distribution
5580: Status: O
5581:
5582: A number of you have noticed that ftp'ing the lisp distribution from
5583: ucb-vax can be slow at times. As a result, we've made 'ucb-arpa' the
5584: primary distribution machine. You can ftp from ucb-arpa using an anonymous
5585: login (with your name as password). The files are in the pub/lisp
5586: subdirectory.
5587: john foderaro
5588:
5589:
5590:
5591:
5592: From liz%umcp-cs@UDel-Relay Mon Sep 26 19:41:37 1983
5593: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5594: id AA24055; Mon, 26 Sep 83 19:41:37 PDT
5595: Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7)
5596: id AA07367; Mon, 26 Sep 83 16:28:58 PDT
5597: Message-Id: <[email protected]>
5598: Date: 26 Sep 83 15:22:00 EDT (Mon)
5599: From: Liz Allen <liz%umcp-cs@UDel-Relay>
5600: Return-Path: <liz%umcp-cs@UDel-Relay>
5601: Subject: Maryland software distribution
5602: To: franz-friends@BERKELEY
5603: Via: UMCP-CS; 26 Sep 83 17:46-EDT
5604: Status: O
5605:
5606: This is to announce the availability of the Univ of Maryland software
5607: distribution. This includes source code for the following:
5608:
5609: 1. The flavors package written in Franz Lisp. This package has
5610: been used successfully in a number of large systems at Maryland,
5611: and while it does not implement all the features of Lisp Machine
5612: Flavors, the features present are as close to the Lisp Machine
5613: version as possible within the constraints of Franz Lisp.
5614: (Note that Maryland flavors code *can* be compiled.)
5615: 2. Other Maryland Franz hacks including the INTERLISP-like top
5616: level, the lispbreak error handling package, the for macro and
5617: the new loader package.
5618: 3. The YAPS production system written in Franz Lisp. This is
5619: similar to OPS5 but more flexible in the kinds of lisp expressions
5620: that may appear as facts and patterns (sublists are allowed
5621: and flavor objects are treated atomically), the variety of
5622: tests that may appear in the left hand sides of rules and the
5623: kinds of actions may appear in the right hand sides of rules.
5624: In addition, YAPS allows multiple data bases which are flavor
5625: objects and may be sent messages such as "fact" and "goal".
5626: 4. The windows package in the form of a C loadable library. This
5627: flexible package allows convenient management of multiple
5628: contexts on the screen and runs on ordinary character display
5629: terminals as well as bit-mapped displays. Included is a Franz
5630: lisp interface to the window library, a window shell for
5631: executing shell processes in windows, and a menu package (also
5632: a C loadable library).
5633:
5634: You should be aware of the fact that the lisp software is based on
5635: Franz Opus 38.26 and that we will be switching to the newer version
5636: of lisp that comes with Berkeley 4.2 whenever that comes out.
5637:
5638: ---------------------------------------------------------------------
5639:
5640: To obtain the Univ of Maryland distribution tape:
5641:
5642: 1. Fill in the form below, make a hard copy of it and sign it.
5643: 2. Make out a check to University of Maryland Foundation for $100,
5644: mail it and the form to:
5645:
5646: Liz Allen
5647: Univ of Maryland
5648: Dept of Computer Science
5649: College Park MD 20742
5650:
5651: 3. If you need an invoice, send me mail, and I will get one to you.
5652: Don't forget to include your US Mail address.
5653:
5654: Upon receipt of the money, we will mail you a tape containing our
5655: software and the technical reports describing the software. We
5656: will also keep you informed of bug fixes via electronic mail.
5657:
5658: ---------------------------------------------------------------------
5659:
5660: The form to mail to us is:
5661:
5662:
5663: In exchange for the Maryland software tape, I certify to the
5664: following:
5665:
5666: a. I will not use any of the Maryland software distribution in a
5667: commercial product without obtaining permission from Maryland
5668: first.
5669: b. I will keep the Maryland copyright notices in the source code,
5670: and acknowledge the source of the software in any use I make of
5671: it.
5672: c. I will not redistribute this software to anyone without permission
5673: from Maryland first.
5674: d. I will keep Maryland informed of any bug fixes.
5675: e. I am the appropriate person at my site who can make guarantees a-d.
5676:
5677: Your signature, name, position,
5678: phone number, U.S. and electronic
5679: mail addresses.
5680:
5681: ---------------------------------------------------------------------
5682:
5683: If you have any questions, etc, send mail to me:
5684:
5685: -Liz Allen, U of Maryland, College Park MD
5686: Usenet: ...!seismo!umcp-cs!liz
5687: Arpanet: liz%umcp-cs@Udel-Relay
5688:
5689:
5690: From fateman Thu Sep 29 14:50:17 1983
5691: Received: by ucbkim.ARPA (4.6/4.2)
5692: id AA10806; Thu, 29 Sep 83 14:50:17 PDT
5693: Date: Thu, 29 Sep 83 14:50:17 PDT
5694: From: fateman (Richard Fateman)
5695: Message-Id: <[email protected]>
5696: To: franz-friends
5697: Subject: survey
5698: Cc: fateman
5699: Status: O
5700:
5701: I am trying to collect some statistics on usage of Franz.
5702: I would like to get answers to these questions:
5703: (1) Your location:
5704: (2) The number of computers at your location (actively) running Franz:
5705: (3) Have you produced a locally modified manual? (y/n)
5706: (4) Are other Lisps in use there? (names?)
5707: (5) Do you use Franz for instruction? research?
5708: (6) Are you distributing or selling packages "on top of" Franz?
5709:
5710: (You may also send comments you wish; I will compile results and
5711: redistribute, so please do not respond to "franz-friends", but to me.)
5712: Thanks.
5713:
5714: From jkf Thu Sep 29 23:04:29 1983
5715: Received: by ucbkim.ARPA (4.6/4.2)
5716: id AA04355; Thu, 29 Sep 83 23:04:29 PDT
5717: Date: Thu, 29 Sep 83 23:04:29 PDT
5718: From: jkf (John Foderaro)
5719: Message-Id: <[email protected]>
5720: To: local-lisp
5721: Subject: opus 38.80
5722: Status: O
5723:
5724: Two new functions:
5725:
5726: (character-index 'st_string 'xst_char)
5727:
5728: returns the position of the character xst_char in the string
5729: st_string. The position of the first character is '1'
5730: (1-based indexing was chosen because substring also uses
5731: 1-based indexing).
5732: If the character is not in the string, nil is returned.
5733:
5734: xst_char, as its prefix implies, can either be the fixnum
5735: value of a character (commonly written #/x), or a symbol
5736: or string, in which case the first character is used.
5737:
5738:
5739: (sleep 'x_seconds)
5740: sleep for x_seconds.
5741:
5742:
5743:
5744:
5745: From jkf Sat Oct 1 21:42:29 1983
5746: Received: by ucbkim.ARPA (4.6/4.2)
5747: id AA16280; Sat, 1 Oct 83 21:42:29 PDT
5748: Date: Sat, 1 Oct 83 21:42:29 PDT
5749: From: jkf (John Foderaro)
5750: Message-Id: <[email protected]>
5751: To: local-lisp
5752: Subject: opus 38.81
5753: Status: O
5754:
5755: new function (sys:nice 'x_delta-priority)
5756: this increments your nice value (decrements your process priority)
5757: by x_delta-priority. x_delta-priority can only be negative
5758: if you are root, of course.
5759:
5760:
5761:
5762:
5763: From unmvax!gatech!pwh Tue Oct 4 08:35:04 1983
5764: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5765: id AA23488; Tue, 4 Oct 83 08:35:04 PDT
5766: Received: by ucbvax.ARPA (4.12/4.7)
5767: id AA07616; Tue, 4 Oct 83 08:05:43 PDT
5768: From: unmvax!gatech!pwh
5769: Message-Id: <[email protected]>
5770: Date: 1 Oct 83 19:44:56-EDT (Sat)
5771: Original-From: <pwh@gatech>
5772: To: franz-friends@BERKELEY
5773: Subject: why a HOLE (duck) ?
5774: Status: RO
5775:
5776:
5777: Could someone explain to me what HOLE is all about in the vax dependent
5778: Franz code? I've scrutinized the code and read the preliminary Franz
5779: implementation manual too many times and still can't figure it...
5780:
5781: phil hutto
5782:
5783:
5784:
5785:
5786: From mbr@nprdc Sat Oct 8 15:59:38 1983
5787: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5788: id AA08262; Sat, 8 Oct 83 15:59:38 PDT
5789: Received: from nprdc (nprdc.ARPA) by ucbvax.ARPA (4.12/4.7)
5790: id AA23633; Sat, 8 Oct 83 15:58:02 PDT
5791: Message-Id: <[email protected]>
5792: Date: 8 Oct 1983 15:52:17-PDT
5793: From: Mark Rosenstein <mbr@NPRDC>
5794: Reply-To: mbr@NPRDC
5795: To: franz-friends@BERKELEY
5796: Subject: bugs in liszt 8.36
5797: Status: RO
5798:
5799: Problem:
5800: -I flag doesn't work
5801: Solution??
5802: in file tlev.l change 'i to 'I in line 127
5803: (notice that -i flag includes files and it is imposible to get
5804: into uci mode)
5805:
5806: Problem:
5807: while compiling get message:
5808: Undefined function called from compiled code e-sub2
5809: Solution??
5810: in file tlev.l change e-sub2 to e-sub in line 298
5811: (I don't swear by this solution--my stuff seems to compile ok
5812: but no promises)
5813:
5814: From jkf Wed Oct 12 06:11:15 1983
5815: Received: by ucbkim.ARPA (4.6/4.2)
5816: id AA29652; Wed, 12 Oct 83 06:11:15 PDT
5817: Date: Wed, 12 Oct 83 06:11:15 PDT
5818: From: John Foderaro (on an h19-u) <jkf>
5819: Message-Id: <[email protected]>
5820: To: local-lisp
5821: Subject: New AI language in the works
5822: Cc:
5823: Status: RO
5824:
5825:
5826: From: Skef Wholey <[email protected]>
5827:
5828: >From an article "Computing Women" in a shoddy little pseudo-magazine
5829: called "Ampersand" that was stuck inside CMU's student newspaper this
5830: week:
5831:
5832: Our final tip involves a different kind of research. Is a
5833: breakthough in computing happening right on your own
5834: campus? MIT and Carnegie-Mellon University, for example,
5835: are busy developing a brainchild called Lisp. If
5836: successful, Lisp may become the standard language of
5837: ``artificially intelligent'' computers that ``think''
5838: within a limited sphere on their own. Imagine your
5839: marketability if you've worked with a poineer in this
5840: field. Skip a football game some Saturday afternoon and
5841: see what the Prof is doing with HIS spare time. It could
5842: be profitable to you.
5843:
5844:
5845:
5846:
5847:
5848: From @MIT-MC:apm@cmu-ri-isl1 Fri Oct 14 09:27:56 1983
5849: Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2)
5850: id AA14501; Fri, 14 Oct 83 09:27:56 PDT
5851: Received: from MIT-MC (mit-mc.ARPA) by ucbvax.ARPA (4.12/4.7)
5852: id AA00195; Fri, 14 Oct 83 09:26:15 PDT
5853: Message-Id: <[email protected]>
5854: Date: 14 Oct 1983 12:22:28-EDT
5855: From: Andrew.Mendler@CMU-RI-ISL1
5856: Subject: eunice version of franz
5857: Apparently-To: <franz-friends@UCB-VAX>
5858: Status: RO
5859:
5860: What is the most recent version of franz lisp that is available under eunice?
5861: In particular is opus38.55 available?
5862:
5863: Thanks in advance.
5864:
5865:
5866: From sklower Fri Oct 14 09:45:15 1983
5867: Received: by ucbkim.ARPA (4.6/4.2)
5868: id AA14694; Fri, 14 Oct 83 09:45:15 PDT
5869: Date: Fri, 14 Oct 83 09:45:15 PDT
5870: From: sklower (Keith Sklower)
5871: Message-Id: <[email protected]>
5872: To: franz-friends
5873: Subject: eunice version of franz
5874: Status: RO
5875:
5876: We have opus38.79 working on David Kashtan's machine. The source
5877: is integrated with the vax-unix and 68000 versions, all available
5878: by anonymous ftp, or as the regular tape distribution. I have had
5879: one report from a eunice user that the installation didn't get past
5880: construction the kernel, but it could be due to insufficient quota.
5881:
5882: From jkf Sun Oct 16 16:39:35 1983
5883: Received: by ucbkim.ARPA (4.6/4.2)
5884: id AA03935; Sun, 16 Oct 83 16:39:35 PDT
5885: Date: Sun, 16 Oct 83 16:39:35 PDT
5886: From: John Foderaro (on an aaa-60-s) <jkf>
5887: Message-Id: <[email protected]>
5888: To: local-lisp
5889: Subject: opus 38.82
5890: Cc:
5891: Status: RO
5892:
5893: I'm working on a simple record (destruct-like) package. Consequently,
5894: I've made 'defrecord' autoload my record package. This will cause
5895: problems if there are people who use the name 'defrecord' as a
5896: non-macro function. If this will cause you problems, please speak up.
5897:
5898:
5899:
5900: From procter@UCBMIRO Mon Oct 17 08:59:02 1983
5901: Received: from UCBMIRO.ARPA by ucbkim.ARPA (4.6/4.2)
5902: id AA01206; Mon, 17 Oct 83 08:59:02 PDT
5903: Date: 16 Oct 83 22:56:00 PDT (Sun)
5904: From: procter@UCBMIRO (Steve Procter)
5905: Subject: cfasl
5906: Message-Id: <[email protected]>
5907: Received: by UCBMIRO.ARPA (3.340/3.29)
5908: id AA01323; 16 Oct 83 22:56:00 PDT (Sun)
5909: To: local-lisp@ucbkim
5910: Status: O
5911:
5912: How are arguements passed from lisp to the C routines?
5913: I wrote a program which just printed the arguements passed to it,
5914: and when I cfasl'd it and used it, I got argc > 500000...
5915:
5916: steve procter
5917: procter@ucbmiro
5918:
5919: From jkf Mon Oct 17 10:08:37 1983
5920: Received: by ucbkim.ARPA (4.6/4.2)
5921: id AA02418; Mon, 17 Oct 83 10:08:37 PDT
5922: Date: Mon, 17 Oct 83 10:08:37 PDT
5923: From: John Foderaro (on an h19-u) <jkf>
5924: Message-Id: <[email protected]>
5925: To: procter@UCBMIRO
5926: Subject: Re: cfasl
5927: Cc: local-lisp
5928: In-Reply-To: Your message of 16 Oct 83 22:56:00 PDT (Sun)
5929: Status: O
5930:
5931: Arguments are passed to C functions in the normal C way (on the stack
5932: not as strings on the command line). There are examples in the
5933: lisp manual (in the section on foreign functions).
5934:
5935:
5936:
5937: From whm.Arizona@Rand-Relay Fri Oct 28 05:44:39 1983
5938: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
5939: id AA20395; Fri, 28 Oct 83 05:44:39 pdt
5940: Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
5941: id AA14289; Fri, 28 Oct 83 05:43:48 pdt
5942: Message-Id: <[email protected]>
5943: Date: 28 Oct 1983 01:12:45-PST
5944: From: whm.arizona@Rand-Relay
5945: Return-Path: <whm.Arizona@Rand-Relay>
5946: Subject: Memory management in Franz
5947: Date-Sent: 28 Oct 83 01:12:42 MST (Fri)
5948: To: franz-friends@BERKELEY
5949: Via: Arizona; 28 Oct 83 2:37-PDT
5950: Status: O
5951:
5952: I've got a couple of questions about Franz Lisp storage management that
5953: I wondering if somebody "in the know" might be able to answer. I tried
5954: this on net.lang.lisp, but didn't get any answers.
5955:
5956: First, Franz seems to support non-relocatable data objects such as
5957: external functions. Are such objects managed by having two logical
5958: regions in managed memory, one for relocatable objects and one for
5959: non-relocatable objects? Such a scheme has been used in other systems
5960: that require garbage collection and I was wondering if Franz uses
5961: this or some other scheme.
5962:
5963: Second, I've heard (but not tried) that Franz allows non-relocatable
5964: data to be allocated via brk/sbrk. Is this true?
5965:
5966: (Actually, I suppose I'd like information on any storage management
5967: implementations for any languages (w/ automatic storage management)
5968: that allow non-relocatable data to be dynamically allocated that don't
5969: use the aforementioned scheme.)
5970:
5971: Thanks,
5972: Bill Mitchell
5973: whm.arizona@rand-relay
5974: p.s.
5975: I'm not on the Franz-Friends list, so if you would, please mail me
5976: any replies.
5977:
5978: From whm.Arizona@Rand-Relay Mon Oct 31 04:55:33 1983
5979: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.2)
5980: id AA29912; Mon, 31 Oct 83 04:55:33 pst
5981: Received: from rand-relay.ARPA by ucbvax.ARPA (4.16/4.13)
5982: id AA08771; Mon, 31 Oct 83 04:54:49 pst
5983: Message-Id: <[email protected]>
5984: Date: 31 Oct 1983 00:41:38-PST
5985: From: whm.arizona@Rand-Relay
5986: Return-Path: <whm.Arizona@Rand-Relay>
5987: Subject: Memory management in Franz
5988: Date-Sent: 31 Oct 83 00:41:36 MST (Mon)
5989: To: franz-friends@BERKELEY
5990: Via: Arizona; 31 Oct 83 1:36-PST
5991: Status: O
5992:
5993: [My apologies if this is a repeat; I got some very wierd messages back
5994: from the Berkeley mailer on my first attempt to send this.]
5995:
5996: I've got a couple of questions about Franz Lisp storage management that
5997: I wondering if somebody "in the know" might be able to answer. I tried
5998: this on net.lang.lisp, but didn't get any answers.
5999:
6000: First, Franz seems to support non-relocatable data objects such as
6001: external functions. Are such objects managed by having two logical
6002: regions in managed memory, one for relocatable objects and one for
6003: non-relocatable objects? Such a scheme has been used in other systems
6004: that require garbage collection and I was wondering if Franz uses
6005: this or some other scheme.
6006:
6007: Second, I've heard (but not tried) that Franz allows non-relocatable
6008: data to be allocated via brk/sbrk. Is this true?
6009:
6010: (Actually, I suppose I'd like information on any storage management
6011: implementations for any languages (w/ automatic storage management)
6012: that allow non-relocatable data to be dynamically allocated that don't
6013: use the aforementioned scheme.)
6014:
6015: Thanks,
6016: Bill Mitchell
6017: whm.arizona@rand-relay
6018: p.s.
6019: I'm not on the Franz-Friends list, so if you would, please mail me
6020: any replies.
6021:
6022: From pjt@brl-voc Tue Nov 1 06:52:11 1983
6023: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
6024: id AA03145; Tue, 1 Nov 83 06:52:11 pst
6025: Received: from BRL-VOC (brl-voc.ARPA) by ucbvax.ARPA (4.16/4.13)
6026: id AA01150; Tue, 1 Nov 83 06:51:14 pst
6027: Message-Id: <[email protected]>
6028: Date: Tue, 1 Nov 83 9:44:54 EST
6029: From: Paul Tanenbaum <pjt@brl-voc>
6030: To: Ailist-requests@sri-ai, Franz-Friends@BERKELEY
6031: Cc: pjt@brl-voc
6032: Subject: mailing list
6033: Status: O
6034:
6035: Please cons me onto your mailing list
6036: Thanks,
6037: paul <pjt@brl-voc>
6038:
6039:
6040: From norvig Fri Nov 4 14:14:16 1983
6041: Received: by ucbkim.ARPA (4.16/4.13)
6042: id AA20986; Fri, 4 Nov 83 14:14:16 pst
6043: Date: Fri, 4 Nov 83 14:14:16 pst
6044: From: norvig (Peter Norvig)
6045: Message-Id: <[email protected]>
6046: To: mills@ernie
6047: Subject: Graphics on Suns
6048: Cc: local-lisp
6049: Status: O
6050:
6051: I want a lisp-callable package to display trees and graphs on the suns.
6052: This is for showing semantic nets, and it would also be useful for showing
6053: how procedures call each other, like Interlisp's masterscope. Does anyone
6054: know of such a package?
6055:
6056: From kanderso@bbn-vax Fri Nov 4 19:55:59 1983
6057: Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13)
6058: id AA26540; Fri, 4 Nov 83 19:55:59 pst
6059: Received: from bbn-vax (bbn-vax.ARPA) by ucbvax.ARPA (4.16/4.13)
6060: id AA03738; Fri, 4 Nov 83 19:55:52 pst
6061: Message-Id: <[email protected]>
6062: Date: Fri, 4 Nov 83 22:55 EST
6063: From: Ken Anderson <kanderso@BBN-Vax>
6064: Subject: Why no &keywords in local functions?
6065: To: franz-friends@BERKELEY
6066: Status: O
6067:
6068: With liszt version 8.29 (Opus 38.66 of Franz) I get the following message:
6069:
6070: ?Error: save.l: save-install: local functions can't use &keyword's save-install
6071:
6072: When compiling the function (declared as a localf):
6073:
6074: (defun save-install (thing table &aux type handler)
6075: ; Install thing in hash table, and recursively install its parts.
6076: (cond ((memq (setq type (save-type thing))
6077: '(symbol number))) ; Needn't install
6078: (t (cond ((zerop (save-count++ thing))
6079: ; Increment access count, and install parts of thing if it
6080: ; is being installe
6081: (cond ((setq handler (get type 'save-install-parts))
6082: (funcall handler thing table))
6083: (t (ferror "Don't Know how to save ~S~%" thing))))))))
6084:
6085: This used to work in earlier Opuses (like 38.44). Can you explain the
6086: change.
6087:
6088: From norvig Tue Nov 8 01:51:03 1983
6089: Received: by ucbkim.ARPA (4.16/4.13)
6090: id AA20986; Fri, 4 Nov 83 14:14:16 pst
6091: Date: Fri, 4 Nov 83 14:14:16 pst
6092: From: norvig (Peter Norvig)
6093: Message-Id: <[email protected]>
6094: To: mills@ernie
6095: Subject: Graphics on Suns
6096: Cc: local-lisp
6097: Status: O
6098:
6099: I want a lisp-callable package to display trees and graphs on the suns.
6100: This is for showing semantic nets, and it would also be useful for showing
6101: how procedures call each other, like Interlisp's masterscope. Does anyone
6102: know of such a package?
6103:
6104: From norvig Tue Nov 8 02:03:27 1983
6105: Received: by ucbkim.ARPA (4.16/4.13)
6106: id AA20986; Fri, 4 Nov 83 14:14:16 pst
6107: Date: Fri, 4 Nov 83 14:14:16 pst
6108: From: norvig (Peter Norvig)
6109: Message-Id: <[email protected]>
6110: To: mills@ernie
6111: Subject: Graphics on Suns
6112: Cc: local-lisp
6113: Status: O
6114:
6115: I want a lisp-callable package to display trees and graphs on the suns.
6116: This is for showing semantic nets, and it would also be useful for showing
6117: how procedures call each other, like Interlisp's masterscope. Does anyone
6118: know of such a package?
6119:
6120: From sklower Thu Nov 17 17:03:27 1983
6121: Received: by ucbkim.ARPA (4.16/4.13)
6122: id AA01897; Thu, 17 Nov 83 17:03:27 pst
6123: Date: Thu, 17 Nov 83 17:03:27 pst
6124: From: sklower (Keith Sklower)
6125: Message-Id: <[email protected]>
6126: To: local-lisp
6127: Subject: lisp sources
6128: Status: O
6129:
6130: Franz now resides in /usr/franz.
6131:
6132: From jkf Tue Nov 22 09:33:32 1983
6133: Received: by ucbkim.ARPA (4.16/4.13)
6134: id AA15675; Tue, 22 Nov 83 09:33:32 pst
6135: Date: Tue, 22 Nov 83 09:33:32 pst
6136: From: John Foderaro (on an h19-u) <jkf>
6137: Message-Id: <[email protected]>
6138: To: local-lisp
6139: Subject: liszt 8.39
6140: Cc:
6141: Status: O
6142:
6143: The -W switch has been added to liszt. When specified, if a compilation
6144: causes any warning messages to given (such as a symbol declared special),
6145: then the compiler will not perform the assembly and will return a non-zero
6146: exit status (for 'make's benefit). Liszt will continue to compile after it
6147: has seen a warning, even if -W is given, to permit as many warnings as
6148: possible to be made in each compile.
6149:
6150:
6151:
6152:
6153: From barry%umcp-cs@CSNet-Relay Tue Nov 22 17:14:09 1983
6154: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6155: id AA23508; Tue, 22 Nov 83 17:14:09 pst
6156: Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.21/4.15)
6157: id AA06655; Tue, 22 Nov 83 17:13:29 pst
6158: Message-Id: <[email protected]>
6159: Date: 22 Nov 83 12:48:01 EST (Tue)
6160: From: Barry Perricone <barry%umcp-cs@CSNet-Relay>
6161: Return-Path: <barry%umcp-cs@CSNet-Relay>
6162: Subject: Franz for VMS
6163: To: franz-friends@BERKELEY
6164: Via: UMCP-CS; 22 Nov 83 19:25-EST
6165: Status: O
6166:
6167:
6168: I need to know if anybody has a version of Franz for the Vax series
6169: under VMS which includes 'liszt'. Also one which when a 'dumplisp'
6170: is performed will output a file which can execute as a stand-alone
6171: (i.e., does not need to be "restored"). I would appreciate
6172: any information on this matter, and if one exists information
6173: on how I could obtain a copy of it.
6174:
6175: Thanks in advance,
6176: Barry P.
6177:
6178: From alfred.ct@Rand-Relay Sat Dec 3 22:40:07 1983
6179: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6180: id AA12594; Sat, 3 Dec 83 22:40:07 pst
6181: Received: from rand-relay.ARPA by UCB-VAX.ARPA (4.22/4.16)
6182: id AA06631; Sat, 3 Dec 83 21:43:27 pst
6183: Message-Id: <[email protected]>
6184: Date: 3 Dec 1983 11:58:11-PST
6185: From: alfred.ct@Rand-Relay
6186: Return-Path: <alfred.ct@Rand-Relay>
6187: Subject: Deficiency in Franz GC
6188: To: franz-friends@BERKELEY
6189: Via: ct; 3 Dec 83 12:46-PST
6190: Status: RO
6191:
6192: This really isn't a bug so much as a deficiency
6193: in the code. We are running Opus 38.26 and recently
6194: had need to increase the constant TTSIZE (in config.h)
6195: above the default 10216. It turns out that this
6196: breaks the garbage collector which will fail
6197: to completely clear the array bitmapi
6198: if given a TTSIZE greater 10216 (during the
6199: clearing out of bit maps). The offending code
6200: is in Talloc.c (or alloc.c, depending on your Opus).
6201: The old code is:
6202:
6203: /* try the movc5 to clear the bit maps */
6204: /* the maximum number of bytes we can clear in one sweep is
6205: * 2^16 (or 1<<16 in the C lingo)
6206: */
6207: bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16;
6208: if(bytestoclear > MAXCLEAR)
6209: {
6210: blzero(((int) &bitmapi[((int)beginsweep>>7)]) + MAXCLEAR,
6211: bytestoclear - MAXCLEAR);
6212: bytestoclear = MAXCLEAR;
6213: }
6214: blzero((int)&bitmapi[((int)beginsweep)>>7],bytestoclear);
6215:
6216: and the fixed version that we have been running for several weeks
6217: now is:
6218:
6219: /* try the movc5 to clear the bit maps */
6220: /* the maximum number of bytes we can clear in one sweep is
6221: * 2^16 (or 1<<16 in the C lingo)
6222: */
6223: bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16;
6224: {int count = 0;
6225: while (bytestoclear > 0) {
6226: if(bytestoclear > MAXCLEAR)
6227: {
6228: blzero(((int) &bitmapi[((int)beginsweep>>7)])+count*MAXCLEAR,
6229: MAXCLEAR);
6230: ++count;
6231: }
6232: else
6233: blzero(((int)&bitmapi[((int)beginsweep)>>7]+count*MAXCLEAR),
6234: bytestoclear);
6235: bytestoclear -= MAXCLEAR;
6236: }
6237: }
6238:
6239: The old code is still present in Opus 38.56.
6240:
6241: Alfred Correira
6242: Paul Robertson
6243: ...ucbvax!nbires!ctvax!alfred (UUCP)
6244: alfred.ct@Rand-Relay (CSNET)
6245:
6246: From fateman Tue Dec 13 09:11:00 1983
6247: Received: by ucbkim.ARPA (4.16/4.13)
6248: id AA03666; Tue, 13 Dec 83 08:31:30 pst
6249: Date: Tue, 13 Dec 83 08:31:30 pst
6250: From: fateman (Richard Fateman)
6251: Message-Id: <[email protected]>
6252: To: local-lisp
6253: Cc: pattrsn
6254: Status: O
6255:
6256: I have just received a copy of the new Common Lisp Reference Manual
6257: (The Mary Poppins Edition ... Practically Perfect in Every Way)
6258: ... it is 385 pages long.
6259:
6260: From hoey@nrl-aic Wed Jan 11 12:58:53 1984
6261: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6262: id AA06395; Wed, 11 Jan 84 12:58:53 pst
6263: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
6264: id AA03955; Wed, 11 Jan 84 12:58:55 pst
6265: Message-Id: <[email protected]>
6266: Date: 11 Jan 1984 14:43-EST
6267: From: Dan Hoey <hoey@NRL-AIC>
6268: Subject: Problems with arrays in Franz
6269: Apparently-To: <FRANZ-FRIENDS@berkeley>
6270: Status: O
6271:
6272:
6273:
6274: From hoey@nrl-aic Wed Jan 11 13:10:01 1984
6275: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6276: id AA06529; Wed, 11 Jan 84 13:10:01 pst
6277: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
6278: id AA04150; Wed, 11 Jan 84 13:09:46 pst
6279: Message-Id: <[email protected]>
6280: Date: 11 Jan 1984 14:43-EST
6281: From: Dan Hoey <hoey@NRL-AIC>
6282: Subject: Problems with arrays in Franz
6283: To: FRANZ-FRIENDS@BERKELEY
6284: Status: O
6285:
6286: Hard to believe but it was less than two and a half years ago that
6287: someone was having trouble using Franz arrays...
6288:
6289: Date: 17 Jul 1981 17:06:22-PDT
6290: From: CSVAX.jkf at Berkeley
6291: To: FININ@WHARTON-10
6292: cc: franz-friends at MIT-MC
6293: Subject: Re: ... the maclisp-style array package.
6294: In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday).
6295:
6296: From: FININ@WHARTON-10
6297: Subject: ... the maclisp-style array package.
6298:
6299: ...
6300: [3] We've been having problems with the MacLisp compatable array
6301: package - it doesn't work! Does anyone have a debugged version?
6302:
6303: Can you be more specific? We use it in Vax Macsyma without any problems.
6304: Personally I feel that Maclisp arrays were invented by a madman and no new
6305: code should be written using them.
6306:
6307: -- john foderaro
6308:
6309: Well, I used the Maclisp array package because I didn't want to waste
6310: time writing my own. Instead I spent hours looking for the bug in this
6311: code:
6312:
6313: -> (let ((factorial (*array () () 100.)))
6314: (store (factorial 0) 1)
6315: (do ((i 1 (1+ i)))
6316: ((= i 100.))
6317: (store (factorial i) (times i (factorial (1- i)))))
6318: (factorial 10.))
6319: 285656
6320:
6321: To make a long story short, this lossage is because the second argument
6322: to *array being nil tells the garbage collector not to scan the
6323: array. The factorial of ten gets tossed in the bit bucket, where it
6324: unfortunately looks like a fixnum. To fix the example, change the
6325: first line of the example to
6326:
6327: -> (let ((factorial (*array () t 100.)))
6328:
6329: To save someone else from excruciatingly wrong answers, change the
6330: documentation in Section 2.
6331:
6332: (*array 's_name 's_type 'x_dim1 ... 'x_dimn)
6333: (array s_name s_type x_dim1 ... x_dimn)
6334:
6335: WHERE: s_type may be one of t, nil, fixnum, flonum,
6336: fixnum-block and flonum-block.
6337: ...
6338: < In FRANZ LISP arrays of type t, nil, fix-
6339: < num and flonum are equivalent and the elements of
6340: < these arrays can be any type of lisp object.
6341: ---
6342: > In FRANZ LISP arrays of type t, fixnum,
6343: > and flonum are equivalent and the elements of
6344: > these arrays can be any type of lisp object.
6345: > Type nil arrays may also contain any type of lisp
6346: > object, but they are not marked by the garbage
6347: > collector (see 9.2.2) and can lose data if used
6348: > incorrectly.
6349: Fixnum-block and flonum-block arrays are res-
6350: tricted to fixnums and flonums respectively and
6351: are used mainly to communicate with foreign func-
6352: tions (see 8.4).
6353:
6354: Dan
6355:
6356: From hoey@nrl-aic Wed Jan 11 16:23:56 1984
6357: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6358: id AA06395; Wed, 11 Jan 84 12:58:53 pst
6359: Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19)
6360: id AA03955; Wed, 11 Jan 84 12:58:55 pst
6361: Message-Id: <[email protected]>
6362: Date: 11 Jan 1984 14:43-EST
6363: From: Dan Hoey <hoey@NRL-AIC>
6364: Subject: Problems with arrays in Franz
6365: Apparently-To: <FRANZ-FRIENDS@berkeley>
6366: Status: O
6367:
6368:
6369:
6370: From fateman@ucbdali Sun Jan 15 14:58:17 1984
6371: Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13)
6372: id AA00458; Sun, 15 Jan 84 14:58:17 pst
6373: Received: by ucbdali.ARPA (4.22/4.18)
6374: id AA02865; Sun, 15 Jan 84 14:58:51 pst
6375: Date: Sun, 15 Jan 84 14:58:51 pst
6376: From: fateman@ucbdali (Richard Fateman)
6377: Message-Id: <[email protected]>
6378: To: franz-friends@ucbdali
6379: Subject: FUGUE.3
6380: Status: O
6381:
6382:
6383:
6384:
6385:
6386:
6387:
6388:
6389: FUGUE Notes
6390:
6391: An occasional publication of the
6392: Franz Lisp User Group under Unix and Eunice (FUGUE)
6393:
6394: Number 3 (January, 1984)
6395: edited by Richard J. Fateman
6396: University of California
6397: Berkeley CA 94720
6398: USA
6399: fateman@berkeley
6400:
6401: _1. _W_e_l_c_o_m_e!
6402:
6403: It seems about time to publish the third of these
6404: newsletters, since we have accumulated a number of new
6405: items. We would also like to relay to others such informa-
6406: tion as has been forwarded to us. The reports of projects at
6407: Berkeley (and elsewhere) may strike sympathetic chords with
6408: other research.
6409:
6410: _2. _N_e_w _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s
6411:
6412: Franz now runs on a number of Motorola 68000 and 68010
6413: systems, including DUAL, PIXEL, Apple-LISA (UNIX), and
6414: undoubtedly a large number of other UNISOFT Inc. UNIX ports.
6415: (The LISA has only a 1 megabyte address space, and hence
6416: cannot run the compiler. It can load cross-compiled pro-
6417: grams.) Non-UNISOFT UNIX systems we have Franz running on
6418: include the 4.2BSD" Sun Microsystems operating system.
6419:
6420: Some work is beginning on high-speed VLSI chips for
6421: Lisp, using the reduced instruction set technology which has
6422: been successfully used at UCB in the past. More information
6423: on this will be available in the near future.
6424:
6425: _3. _N_e_w _p_r_o_g_r_a_m_s
6426:
6427: _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
6428:
6429: Macsyma runs on the 68000 workstations with sufficient
6430: memory both virtual and real. At least 4 megabytes of vir-
6431: tual is needed, but benchmarks suggest that anything less
6432: than 2 megabytes of real memory is painful. We recommend 4
6433: or more real megabytes. The PIXEL machine with 6 megabytes
6434: (unpaged) is our fastest real-time Macsyma system, (CPU-time
6435: is about 25% longer than reported VAX-780 CPU time, but more
6436: to the point, CPU-time is equal to real-time). Distribution
6437: ____________________
6438: 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs,
6439: SRI Int'l, and Univ. of Calif.
6440:
6441:
6442:
6443: 9
6444:
6445:
6446:
6447:
6448:
6449:
6450:
6451:
6452:
6453:
6454: of 68000 Macsyma will presumably be done by Symbolics, (con-
6455: tact RP@mit-mc, with a cc to fateman@berkeley if you are
6456: interested).
6457:
6458: Development of a new algebra system and user applica-
6459: tion modules is proceeding, and a programming language
6460: called Newspeak, initially implemented on top of Franz, is
6461: the principal vehicle. This is described in John Foderaro's
6462: PhD dissertation, available from the CS Division at UCB.
6463: (Newspeak is hierarchical, object-oriented, and strongly
6464: typed; is compiler-based, and should provide efficient
6465: access to machine resources). While the algebra code is
6466: progressing well, we are not yet ready to set a release date
6467: for the user-end of the system, tentatively named Xi.
6468:
6469: _4. _N_e_w _f_e_a_t_u_r_e_s
6470:
6471: As usual, various performance enhancements and bug
6472: fixes have been incorporated in versions of Franz (now on
6473: Opus 38.87 and the compiler, Liszt 8.39) Most changes made
6474: it into the recent Berkeley 4.2BSD UNIX distribution, and
6475: reported alterations will not be repeated here.
6476:
6477: _5. _O_t_h_e_r _L_i_s_p_s
6478:
6479: We understand that a version of PSL will be supported
6480: by Hewlett Packard, on its workstations, and that Common
6481: Lisp, from DEC will have initial field-test in January,
6482: 1984. We believe PSL should be available from Utah in a
6483: form for running on 4.2BSD VAX UNIX; similarly for "T" from
6484: Cognitive Systems. We believe that a Common-Lisp support
6485: package for Franz may be constructed, but probably not at UC
6486: under current funding. (see Business news below, though).
6487:
6488: _6. _W_o_r_k _i_n _P_r_o_g_r_e_s_s
6489:
6490: _6._1. _G_r_a_p_h_i_c_s
6491:
6492: Gregg Foster has constructed a graphics Franz Lisp
6493: which includes the full Sun Microsystems Graphics package
6494: for Sun-2 systems, and Keith Sklower has constructed a C-
6495: structure package in Franz to enable programmers to more
6496: easily construct arbitrary C-structures in Lisp, to pass to
6497: C. Various demonstration programs have been written to
6498: access the smooth-curve plotting capabilities, variable-size
6499: fonts, etc.
6500:
6501: _6._2. _I_B_M _F_r_a_n_z
6502:
6503: Still more nibbles on this one, but not yet. We heard a
6504: rumor of work at Columbia University. (also see the next
6505: item.)
6506: 9
6507:
6508: 9
6509:
6510:
6511:
6512:
6513:
6514:
6515:
6516:
6517:
6518:
6519: _7. _B_u_s_i_n_e_s_s _N_e_w_s
6520:
6521: _7._1. _F_r_a_n_z _I_n_c
6522:
6523: A new software company has been formed to support Franz
6524: and application programs, and is seeking customers in 3
6525: categories: (a) manufacturers of hardware wishing to obtain
6526: a Lisp system and/or Lisp support; (b) software producers
6527: who wish to have reliable access to experts in Franz, for
6528: enhancement, support, training or porting of existing code.
6529: (c) end-users who are using Franz or applications written in
6530: Franz and need help in customizing, debugging, conversion to
6531: or from other dialects, etc.
6532:
6533: The University of California will continue to distri-
6534: bute Franz Lisp on its current basis, but your questions
6535: about support in any of these categories, or about future
6536: plans, can be directed to Franz Inc. Most of the principals
6537: at UC will be participating in this venture. Contact Franz
6538: Inc. via fkunze@berkeley, or (to avoid abuse of various net-
6539: work privileges), Fritz Kunze, President, Franz Inc., 6321
6540: Thornhill Drive, Oakland, Ca 94611 (415) 339-1481.
6541:
6542:
6543:
6544:
6545:
6546:
6547:
6548:
6549:
6550:
6551:
6552:
6553:
6554:
6555:
6556:
6557:
6558:
6559:
6560:
6561:
6562:
6563:
6564:
6565:
6566:
6567:
6568:
6569:
6570:
6571: 9
6572:
6573: 9
6574:
6575:
6576:
6577:
6578: From cowan@AEROSPACE Thu Jan 19 09:56:25 1984
6579: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6580: id AA14836; Thu, 19 Jan 84 09:56:25 pst
6581: Received: from aerospace.ARPA by UCB-VAX.ARPA (4.22/4.19)
6582: id AA02684; Thu, 19 Jan 84 09:55:33 pst
6583: Message-Id: <[email protected]>
6584: Date: Thu, 19 Jan 84 09:55:01 PST
6585: From: Ric Cowan <cowan@AEROSPACE>
6586: To: franz-friends@BERKELEY
6587: Subject: Help
6588: Status: O
6589:
6590: Hi,
6591:
6592: I'm starting a new project and would like to use Franz lisp. It is a large
6593: application that needs to:
6594:
6595: (1) Run on a VAX 11/780 under VMS.
6596: (2) Interface with INGRESS.
6597: (3) Support a menu driven interface with VT100 type terminals.
6598:
6599: Is Franz lisp a viable language to use?
6600:
6601: Thanks in advance,
6602:
6603: Ric Cowan
6604:
6605: From levitt@aids-unix Thu Jan 26 17:44:03 1984
6606: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6607: id AA10074; Thu, 26 Jan 84 17:44:03 pst
6608: Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.19)
6609: id AA02121; Thu, 26 Jan 84 17:01:25 pst
6610: Message-Id: <[email protected]>
6611: Date: 26 Jan 1984 16:25:55-PST
6612: From: Tod Levitt <levitt@aids-unix>
6613: To: franz-friends@BERKELEY
6614: Subject: report PAM 124, "Parlez vous Franz..." by James Larus
6615: Cc: levitt@aids-unix
6616: Status: O
6617:
6618: I am trying to obtain a copy of PAM report 124 which discusses
6619: interfacing foreign functions to Franzlisp. Can someone please
6620: point me at a source for this document? Thanks...
6621: Tod Levitt (levitt@aids-unix)
6622:
6623: From jkf@ucbmike Fri Jan 27 08:44:54 1984
6624: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
6625: id AA15308; Fri, 27 Jan 84 08:44:54 pst
6626: Date: Fri, 27 Jan 84 08:44:40 pst
6627: From: John Foderaro (on an h19-u) <jkf@ucbmike>
6628: Message-Id: <[email protected]>
6629: Received: by ucbmike.ARPA (4.17/3.5)
6630: id AA02469; Fri, 27 Jan 84 08:44:40 pst
6631: To: local-lisp@kim
6632: Subject: lisp 38.88
6633: Cc:
6634: Status: O
6635:
6636: The 'msg' macro now accepts the special form (T 'x_column), and it
6637: spaces over to that column (plus 1).
6638:
6639: -> (msg "foo" (T 10) "bar" N "baz" (T 11) "bof" N)
6640: foo bar
6641: baz bof
6642: nil
6643: ->
6644:
6645: Note that the method used to locate the column only works if nothing
6646: has yet been actually written on the line. Problems will occur if you drain
6647: the port in the middle of the line.
6648:
6649: For example:
6650: -> (msg "foo" D (T 10) "bar" N << here we drain after "foo"
6651: "foo" (T 10) "bar" N)
6652: foo bar << thus column 11 turns out to be column 14
6653: foo bar
6654: nil
6655: ->
6656:
6657:
6658: From jkf@ucbmike Tue Jan 31 10:55:51 1984
6659: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13)
6660: id AA20759; Tue, 31 Jan 84 10:55:51 pst
6661: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21)
6662: id AA12296; Tue, 31 Jan 84 10:51:34 pst
6663: Date: Tue, 31 Jan 84 10:51:33 pst
6664: From: John Foderaro (on an sun-e) <jkf@ucbmike>
6665: Message-Id: <[email protected]>
6666: Received: by ucbmike.ARPA (4.17/3.5)
6667: id AA01218; Tue, 31 Jan 84 10:51:33 pst
6668: To: franz-friends@BERKELEY
6669: Subject: LISPcraft, a book on Lisp and Franz.
6670: Cc:
6671: Status: O
6672:
6673: A new Lisp book is due out March 23rd which may be especially interesting
6674: to Franz Lisp users or potential Franz Lisp users. The title
6675: is `LISPcraft' and it was written by Robert Wilensky, a Computer Science
6676: professor at Berkeley who teaches AI programming courses.
6677: The book starts at first principles and teaches Lisp programming, and then
6678: goes on to Franz-specific topics such as debugging, read macros, error
6679: handling, and compilation. Then there are chapters on Lisp
6680: applications: pattern matching and databases. Finally it contains
6681: a complete description of all Franz functions.
6682:
6683: details:
6684: LISPcraft, by Robert Wilensky 385 pages, $19.95
6685: publisher: W. W. Norton, 500 5th Avenue, N.Y. N.Y. 10110
6686: 800-223-2584
6687:
6688:
6689:
6690:
6691: From jkf@ucbmike Fri Feb 3 08:03:58 1984
6692: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.13)
6693: id AA19272; Fri, 3 Feb 84 08:03:58 pst
6694: Date: Fri, 3 Feb 84 08:04:17 pst
6695: From: John Foderaro (on an h19-u) <jkf@ucbmike>
6696: Message-Id: <[email protected]>
6697: Received: by ucbmike.ARPA (4.17/3.5)
6698: id AA02117; Fri, 3 Feb 84 08:04:17 pst
6699: To: local-lisp@kim
6700: Subject: opus 38.89
6701: Cc:
6702: Status: O
6703:
6704: In opus 38.88 the msg macro was extended to make (T n) put the cursor
6705: on column n+1. Others had extended the msg macro in a conflicting way,
6706: so we decided to convert over to their extensions. So forget what
6707: you read in the opus38.88 message, and remember this:
6708: (C n) go to column n. The first column on the line is column 1.
6709: If the cursor is beyond column n, then go to the next line
6710: and go to column n.
6711: (T m) print m tab characters
6712:
6713:
6714:
6715:
6716:
6717: From jkf Thu Feb 16 10:32:03 1984
6718: Received: by ucbkim.ARPA (4.16/4.22)
6719: id AA16308; Thu, 16 Feb 84 10:32:03 pst
6720: Date: Thu, 16 Feb 84 10:32:03 pst
6721: From: John Foderaro (on an sun-e) <jkf>
6722: Message-Id: <[email protected]>
6723: To: local-lisp
6724: Subject: opus 38.90
6725: Cc:
6726: Status: O
6727:
6728: For those of you using the 'tpl' toplevel, the new command ?fast
6729: will set all switches for maximum speed:
6730: (*rset nil)
6731: (sstatus translink on)
6732: (setq displace-macros t)
6733:
6734:
6735:
6736: From wilensky@ucbdali Wed Feb 22 09:58:43 1984
6737: Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22)
6738: id AA16486; Wed, 22 Feb 84 09:58:43 pst
6739: Received: by ucbdali.ARPA (4.22/4.22)
6740: id AA06784; Wed, 22 Feb 84 09:57:21 pst
6741: Date: Wed, 22 Feb 84 09:57:21 pst
6742: From: wilensky@ucbdali (Robert Wilensky)
6743: Message-Id: <[email protected]>
6744: To: andy@aids-unix, franz-friends@ucbdali
6745: Subject: Re: Franz Flavors & software copyright
6746: In-Reply-To: Your message of 21 Feb 1984 16:29-PST
6747: Status: O
6748:
6749:
6750: Thanks for your clarification. Everything you said is consistent with my
6751: understanding of the situation. And you are correct in emphasizing the
6752: complexity of the issue. But I want to stress my main point. This is
6753: that the ``author'' holds the copyright. It may be unclear who the author
6754: is, but it is clearly NOT the university.
6755:
6756: In addition, many pieces of ``university-developed'' software have
6757: contributions by unfunded students, and by faculty, whose salary is not paid
6758: by the gov't (except maybe during the summer). Furthermore, it would seem
6759: to be unclear who the author is if it is, say, a student working as a gov't
6760: sponsored r. a. For example, the student's thesis is presumably his to
6761: copyright, even if the student were paid by the gov't because it was not
6762: part of what he was paid to do. One could argue that a concommitant program
6763: has the same status unless it were specifically contracted for.
6764:
6765: Let me state that my main purpose was not to promote people selling their
6766: code, but rather, to stop the universities from impeding its distribution.
6767: As far as I know, the gov't hasn't tried to prevent us from giving each
6768: other our software, but many universities have. Therefore, we are better
6769: off leaving them out of the picture entirely - legally this seems to be a
6770: sound position.
6771:
6772:
6773: From jkf@ucbmike Wed Mar 14 09:04:55 1984
6774: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
6775: id AA00884; Wed, 14 Mar 84 09:04:55 pst
6776: Date: Wed, 14 Mar 84 08:58:51 pst
6777: From: John Foderaro (on an h19-u) <jkf@ucbmike>
6778: Message-Id: <[email protected]>
6779: Received: by ucbmike.ARPA (4.17/3.5)
6780: id AA03782; Wed, 14 Mar 84 08:58:51 pst
6781: To: fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
6782: Subject: lisps running wild
6783: Cc: local-lisp@kim
6784: In-Reply-To: Your message of Tue, 13 Mar 84 21:45:25 pst
6785: Status: O
6786:
6787: re:
6788: From: chris@ucbcory (Chris Guthrie)
6789: We are having a good deal
6790: of trouble with them being left running instead of dying and killing
6791: the load here.
6792:
6793: The problem is that people are setting a flag in their lisp init files
6794: which instruct lisp to ignore 'end of file' (much like the c shell).
6795: If a connection is broken (ipc connection breaks or modem hangs up), then
6796: lisp is sent a hangup signal (which it ignores) and then a continuous
6797: sequence of 'end of files' which it ignores after a bit of processing.
6798: The solution is this:
6799: If you have something in your init file which instructs lisp to ignore
6800: end of files (such as (sstatus ignoreeof t)), then you should also
6801: have (signal 1 'exit) in the init file so lisp will exit upon a hangup.
6802:
6803:
6804:
6805:
6806: From mcgeer Wed Mar 14 09:37:45 1984
6807: Received: by ucbkim.ARPA (4.16/4.22)
6808: id AA01437; Wed, 14 Mar 84 09:37:45 pst
6809: Date: Wed, 14 Mar 84 09:37:45 pst
6810: From: Rick McGeer (on an aaa-60-s) <mcgeer>
6811: Message-Id: <[email protected]>
6812: To: jkf@ucbmike, chris@cory, layer@ucbdali, sklower@ucbdali, fateman@ucbdali
6813: Subject: Re: lisps running wild
6814: Cc: local-lisp
6815: In-Reply-To: Your message of Wed, 14 Mar 84 08:58:51 pst
6816: Status: O
6817:
6818: John, your top level sets the ignoreeof flag. Does it also set the
6819: appropriate signal, or should your users do that themselves?
6820:
6821:
6822: From jkf@ucbmike Wed Mar 14 09:48:04 1984
6823: Received: from ucbmike.ARPA by ucbkim.ARPA (4.16/4.22)
6824: id AA01603; Wed, 14 Mar 84 09:48:04 pst
6825: Date: Wed, 14 Mar 84 09:42:15 pst
6826: From: John Foderaro (on an h19-u) <jkf@ucbmike>
6827: Message-Id: <[email protected]>
6828: Received: by ucbmike.ARPA (4.17/3.5)
6829: id AA03833; Wed, 14 Mar 84 09:42:15 pst
6830: To: mcgeer@ucbkim, fateman@ucbdali, sklower@ucbdali, layer@ucbdali, chris@cory
6831: Subject: Re: lisps running wild
6832: Cc: local-lisp@ucbkim
6833: In-Reply-To: Your message of Wed, 14 Mar 84 09:37:45 pst
6834: Status: O
6835:
6836: Since ignoreeof is always set in the new top level, I'll make 'exit on
6837: hangup' the default if you use the new top level.
6838:
6839:
6840:
6841:
6842: From [email protected] Sat Mar 17 13:45:58 1984
6843: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22)
6844: id AA05623; Sat, 17 Mar 84 13:45:58 pst
6845: Received: from SU-AI.ARPA by UCB-VAX.ARPA (4.24/4.25)
6846: id AA12441; Sat, 17 Mar 84 13:47:35 pst
6847: Message-Id: <[email protected]>
6848: Date: 17 Mar 84 1347 PST
6849: From: Rod Brooks <[email protected]>
6850: Subject: Don't use Franz sortcar!
6851: To: franz-friends@BERKELEY
6852: Status: O
6853:
6854:
6855: Somewhat bizzarely it seems that Franz Lisp sort and sortcar have
6856: different time complexities. sort is good and sortcar is bad so
6857: I suggest you convert your sortcar's to sort's until someone sorts
6858: this out. The code and transcript below use both sort and sortcar
6859: to sort a list of length n (the list happens to start in precisely
6860: reverse order). A count of the number of calls to the comparison
6861: function is kept. The results show that sort takes n*log(n)
6862: comparisons while sortcar takes n*n. The problem should
6863: be fixable by throwing out code as there must be two sorters lurking
6864: in there!
6865:
6866: ;;;;;;;;;;;;;;;
6867:
6868: (defun gen (n)
6869: (do ((i 0 (1+ i))
6870: (l () (cons (cons i ()) l)))
6871: ((= i n)
6872: l)))
6873:
6874: (defun compare (x y)
6875: (setq *count* (1+ *count*))
6876: (< x y))
6877:
6878: (defun compare-cars (x y) (compare (car x) (car y)))
6879:
6880: (defun count-sort (n)
6881: (let ((*count* 0))
6882: (sort (gen n) #'compare-cars)
6883: *count*))
6884:
6885: (defun count-sortcar (n)
6886: (let ((*count* 0))
6887: (sortcar (gen n) #'compare)
6888: *count*))
6889:
6890: (defun test (n)
6891: (let ((csort (count-sort n))
6892: (csortcar (count-sortcar n)))
6893: (list n
6894: csort
6895: csortcar
6896: (/$ (float csort) (*$ (float n) (log n)))
6897: (/$ (float csortcar) (float (* n n))))))
6898:
6899: ;;;;;;;;;;;;;;;
6900:
6901: Here's the transcript. The lists of 5 elements are:
6902: n
6903: compares for sort
6904: compares for sortcar
6905: compares for sort / n*log(n)
6906: compares for sortcar / n*n
6907:
6908:
6909: Franz Lisp, Opus 38
6910: -> (load 'test)
6911: t
6912: -> (test 3)
6913: (3 3 6 0.910239226626837 0.6666666666666667)
6914: -> (test 100)
6915: (100 460 9900 0.9988773083774791 0.99)
6916: -> (test 200)
6917: (200 1020 39800 0.9625697456705496 0.995)
6918: -> (test 300)
6919: (300 1440 89700 0.8415468193831012 0.9966666666666667)
6920: -> (test 400)
6921: (400 2240 159600 0.9346629619469353 0.9975)
6922: ->
6923:
6924:
6925: From @MIT-MC:smh@MIT-EMS Wed Mar 28 06:11:15 1984
6926: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
6927: id AA06408; Wed, 28 Mar 84 06:11:15 pst
6928: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
6929: id AA23759; Wed, 28 Mar 84 06:10:43 pst
6930: Message-Id: <[email protected]>
6931: Date: 28 Mar 1984 09:09:38-EST
6932: From: <smh@mit-ems@mit-mc>
6933: To: franz-friends@BERKELEY
6934: Subject: Fixes for setf return value problem
6935: Status: O
6936:
6937: As FranzFriends readers will know, my message several days ago
6938: generated a number of comments. The clear consensus was that setf
6939: should be fixed, not the documentation. This was obvious. The reason
6940: I didn't suggest the fix myself was that I felt it was far more
6941: important to preserve compatibility between Franz and the various other
6942: more-or-less-source-compatible Lisps (aka Common Lisps). It was my
6943: impression that code relying on the value returned by setf would not
6944: be portable.
6945:
6946: I have since learned that Common Lisp does indeed define setf to return
6947: the new value (its second argument), and that other implementations
6948: (i.e. MIT and Symbolics Lisp Machines) indeed work this way. (Mind
6949: you, I haven't checked this myself -- the information is second hand.)
6950: The fixes to setf are quite straightforward and are brief enough that I
6951: am including them below. For each case that the setf macro evaluates
6952: to a {rplaca, rplacd, rplacx} the corresponding {car, cdr, cxr} is now
6953: wrapped around it. The Liszt compiler seems smart enough to remove the
6954: extra reference if the value is ignored.
6955:
6956: The new setf functions follow. The starting version is the Opus 38.69
6957: common2 identified by:
6958: ;; common2.l -[Fri Jul 8 17:46:13 1983 by layer]-
6959: (Although only two lines of setf-check-car+d were changed, the entire
6960: function is included because the change is difficult to locate by
6961: context.) I suggest these changes be made in the official sources.
6962: Whoever wants to install them should edit common2.l and remake the
6963: Franz interpreter. The Liszt compiler does not need to be changed.
6964: ====================
6965:
6966: ; modified 27Mar84 SMH@MIT-EMS@MT-MC (see comment below)
6967: ;
6968: (defun setf-check-cad+r (name)
6969: (if (eq (getcharn name 1) #/c)
6970: then (let
6971: ((letters (nreverse (cdr (exploden name)))))
6972: (if (eq (car letters) #/r)
6973: then (do ((xx (cdr letters) (cdr xx)))
6974: ((null xx)
6975: ;; form is c{ad}+r, setf form is
6976: ;; (rplac<first a or d> (c<rest of a's + d's>r x))
6977: (setq letters (nreverse letters))
6978: (eval
6979: `(defsetf ,name (e v)
6980: ; SMH@MIT-EMS@MIT-MC
6981: ; added next line and matching rparen.
6982: (list ',(implode `(#/c ,(car letters) #/r))
6983: (list
6984: ',(concat "rplac" (ascii (car letters)))
6985: (list
6986: ',(implode `(#/c ,@(cdr letters)))
6987: (cadr e))
6988: v)))) ; SMH@MIT-EMS@MIT-MC
6989: t)
6990: (if (not (memq (car xx) '(#/a #/d)))
6991: then (return nil)))))))
6992:
6993: . . .
6994:
6995: ;--- other setf's for car's and cdr's are generated automatically
6996: ;
6997: ; modified 27Mar84 SMH@MIT-EMS@MIT-MC
6998: ; Now whenever setf macro expands to a rplac[adx], the corresponding c[adx]r
6999: ; is now wrapped around it so that setf consistently returns its second arg.
7000: ; The compiler is smart enough to remove the extra operation if the value
7001: ; is not used.
7002: ;
7003: (defsetf car (e v) `(car (rplaca ,(cadr e) ,v)))
7004: (defsetf caar (e v) `(car (rplaca (car ,(cadr e)) ,v)))
7005: (defsetf cadr (e v) `(car (rplaca (cdr ,(cadr e)) ,v)))
7006: (defsetf cdr (e v) `(cdr (rplacd ,(cadr e) ,v)))
7007: (defsetf cdar (e v) `(cdr (rplacd (car ,(cadr e)) ,v)))
7008: (defsetf cddr (e v) `(cdr (rplacd (cdr ,(cadr e)) ,v)))
7009: (defsetf cxr (e v) `(cxr ,(cadr e) (rplacx ,(cadr e) ,(caddr e) ,v)))
7010:
7011: . . .
7012:
7013: (defsetf nth (e v) `(car (rplaca (nthcdr ,(cadr e) ,(caddr e)) ,v)))
7014: (defsetf nthelem (e v) `(car (rplaca (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))
7015: (defsetf nthcdr (e v) `(cdr (rplacd (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v)))
7016:
7017: . . .
7018:
7019: ; (defsetf args (e v) `(args ,(cadr e) ,v)) ; no longer implemented?
7020:
7021: ====================
7022:
7023: Steven Haflich
7024: MIT Experimental Music Studio
7025: (617)253-7441
7026: smh@mit-ems@mit-mc
7027: decvax!genrad!mit-ems!smh
7028:
7029:
7030: From fateman@ucbdali Thu Mar 29 12:07:33 1984
7031: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
7032: id AA20323; Thu, 29 Mar 84 12:07:33 pst
7033: Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.25)
7034: id AA22790; Thu, 29 Mar 84 12:07:08 pst
7035: Received: by ucbdali.ARPA (4.24/4.22)
7036: id AA04139; Thu, 29 Mar 84 12:07:10 pst
7037: Date: Thu, 29 Mar 84 12:07:10 pst
7038: From: fateman@ucbdali (Richard Fateman)
7039: Message-Id: <[email protected]>
7040: To: franz-friends@BERKELEY
7041: Subject: commercialization of Franz
7042: Status: O
7043:
7044:
7045: Some people may have gotten the incorrect impression that
7046: the University of California will cease sending out
7047: tapes of Franz Lisp. We intend to continue distribution
7048: of the latest version which is the property of UCB. This is
7049: currently opus 38.91. This distribution works, so far as we know,
7050: on SUN releases (0.4, 1.0, 1.1) and Masscomp, and VAX 4.2BSD.
7051: Such distributions will continue, and will continue to be unsupported.
7052: Although we have made reasonable efforts to provide a useful,
7053: portable, efficient, and complete system, we have spent too much of
7054: our time and our sponsors' money in answering
7055: questions about installation-dependent difficulties or
7056: (what USUALLY turns out to be non-existent) bugs.
7057: I might point out that many of the questions come from commercial users.
7058:
7059: Franz Inc. was formed to provide a mechanism for support, transportation
7060: of Franz Lisp to new architectures, enhancements, documentation, etc.
7061: It has the (non-exclusive) right to use, distribute, (etc) Franz Lisp,
7062: and intends to produce enhancements that the University does not
7063: have funding for. I expect that if enhancements of Franz Lisp at UCB
7064: are produced, these will next be made available on 4.3 BSD tapes. Earlier
7065: distributions of contributed software or locally produced software
7066: MAY occur, but cannot be promised.
7067:
7068: I expect that there will continue to be a large number of Franz Lisp
7069: users who are satisfied with the university distribution (on 4.2BSD)
7070: or on the separate tapes (e.g. after opus 38.79) that UCB is sending out.
7071: Others will want the enhanced, supported, version from Franz Inc.
7072:
7073: The divergence of versions,
7074: some of which has already occurred with local variants of older
7075: systems being redistributed, seems inevitable regardless of Franz Inc.
7076:
7077: I hope this clarifies UCB's position.
7078:
7079:
7080:
7081: From @MIT-MC:smh@MIT-EMS Wed Apr 4 15:44:42 1984
7082: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
7083: id AA07196; Wed, 4 Apr 84 15:44:42 pst
7084: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25)
7085: id AA01892; Wed, 4 Apr 84 15:14:05 pst
7086: Message-Id: <[email protected]>
7087: Date: 4 Apr 1984 16:44:49-EST
7088: From: <smh@mit-ems@mit-mc>
7089: To: franz-friends@BERKELEY
7090: Subject: Re: recent suggested fix to setf
7091: Status: O
7092:
7093: There was one mistake in my recent posting with fixes for the Franz
7094: setf function. I said that it was not necessary to remake liszt (the
7095: compiler). This was wrong: code compiled with an old copy of liszt
7096: will not use the modified setf definitions.
7097:
7098: The fix is simply to remake liszt after the new Franz interpreter has
7099: been generated.
7100:
7101: Sorry about any confusion.
7102:
7103: Steve Haflich
7104: MIT Experimental Music Studio
7105: decvax!genrad!mit-ems!smh
7106: smh@mit-ems@mit-mc
7107:
7108:
7109: From [email protected] Wed Apr 18 20:37:26 1984
7110: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3)
7111: id AA16547; Wed, 18 Apr 84 20:37:26 pst
7112: Received: from RUTGERS.ARPA (rutgers.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
7113: id AA29663; Wed, 18 Apr 84 20:36:21 pst
7114: Message-Id: <[email protected]>
7115: Date: 18 Apr 84 23:37:14 EST
7116: From: Sean McLinden <[email protected]>
7117: Subject: [Sean McLinden <[email protected]>: Re: Franz on Suns under 4.2?]
7118: To: franz-friends@BERKELEY
7119: Status: O
7120:
7121: Mail-From: MCLINDEN created at 18-Apr-84 23:33:56
7122: Date: 18 Apr 84 23:33:56 EST
7123: From: Sean McLinden <[email protected]>
7124: Subject: Re: Franz on Suns under 4.2?
7125: To: [email protected]
7126: cc: [email protected]
7127: In-Reply-To: Message from "allegra!jdd@Berkeley (John DeTreville)" of 18 Apr 84 13:10:10 EST
7128:
7129:
7130:
7131: I must be missing something with all of this discussion of Franz
7132: Lisp on Suns. We have had no trouble at all running the current
7133: (opus 38.91?) Berkeley release on Suns and have been running Sun
7134: Franz Lisp for nearly a year now.
7135:
7136: The only serious problem that I can recall happened a few sub versions
7137: ago and was due to a logical error in the C-coded algorithm which
7138: determined when to garbage collect (as things would have it, it
7139: never did). The result was that liszt was unable to compile some
7140: of the lisp coded sources due to the 2 Meg/process limit imposed
7141: by the Sun operating system (the bug existed in the Vax version as
7142: well but one would only see it if the lisp image exceeded 6 megs
7143: which is rare for a compiler run).
7144:
7145: Perhaps you could be more explicit in describing what, exactly,
7146: the problem is. The people at Berkeley most probably have Suns
7147: and I am sure that they don't release Sun versions without testing
7148: them.
7149:
7150: Sean McLinden
7151: Decision Systems Lab
7152: University of Pittsburgh
7153: School of Medicine
7154: -------
7155: -------
7156:
7157: From varghese%[email protected] Fri May 25 18:47:11 1984
7158: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
7159: id AA20472; Fri, 25 May 84 18:47:11 pdt
7160: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.27)
7161: id AA23631; Fri, 25 May 84 18:45:35 pdt
7162: Message-Id: <[email protected]>
7163: Received: From colostate.csnet by csnet-relay; 25 May 84 21:17 EDT
7164: Date: Fri, 25 May 84 13:47:24 mdt
7165: From: varghese%[email protected]
7166: Received: by csu-cs.UUCP (4.12/3.14)
7167: id AA11606; Fri, 25 May 84 13:47:24 mdt
7168: To: [email protected]
7169: Subject: Addition to mailing list
7170:
7171:
7172:
7173:
7174: Please add us to the mailing list. Since there will be more than one
7175: person at this site who wants to be on the mailing list we decided to
7176: get everything mailed to one central mailbox.
7177: The mailbox address for this mailing list is
7178:
7179: frnzlist@colostate
7180:
7181: Please note that this is a CSnet address. Thank you,
7182:
7183: Joe Varghese
7184: varghese@colostate
7185:
7186:
7187: From [email protected] Sun Jun 3 19:15:03 1984
7188: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7189: id AA07648; Sun, 3 Jun 84 19:15:03 pdt
7190: Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
7191: id AA24832; Sun, 3 Jun 84 19:13:42 pdt
7192: Date: 3 Jun 1984 22:02-EST
7193: From: [email protected]
7194: Subject: Please add my name to the list
7195: To: FRANZ-FRIENDS@BERKELEY
7196: Message-Id: <455162572/trk@CMU-CS-G>
7197:
7198: Please add my name to the FRANZ-FRIENDS list.
7199: -Todd K.
7200:
7201: From [email protected] Sun Jun 3 23:24:19 1984
7202: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7203: id AA09575; Sun, 3 Jun 84 23:24:19 pdt
7204: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27)
7205: id AA27487; Sun, 3 Jun 84 23:22:53 pdt
7206: Message-Id: <[email protected]>
7207: Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT
7208: Date: 3 Jun 84 23:22 PDT
7209: From: [email protected]
7210: Subject: This is a test
7211: To: Franz-Friends@BERKELEY
7212:
7213: Sorry to bother you -- this is only a test of correct forwarding on this mailing list.
7214:
7215:
7216: From @MIT-MC:[email protected] Mon Jun 18 17:09:37 1984
7217: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7218: id AA21265; Mon, 18 Jun 84 17:09:37 pdt
7219: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7220: id AA19453; Mon, 18 Jun 84 17:07:25 pdt
7221: Message-Id: <[email protected]>
7222: Date: 18 Jun 1984 12:48:57-EDT
7223: From: Simon.Lowenfeld@CMU-RI-ISL1
7224: Subject: old messages
7225: Apparently-To: <franz-friends@UCB-VAX>
7226:
7227: Is there some kind of archive for old postings?
7228: I am interested in the Franz/T argument
7229: from earlier this year.
7230:
7231:
7232: From [email protected] Tue Jun 19 07:36:37 1984
7233: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7234: id AA01983; Tue, 19 Jun 84 07:36:37 pdt
7235: Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7236: id AA01762; Tue, 19 Jun 84 07:34:31 pdt
7237: Message-Id: <[email protected]>
7238: Date: Tue, 19 Jun 84 10:31:27 EDT
7239: From: William K. Cadwallender (LCWSL) <[email protected]>
7240: To: franz-friends@BERKELEY
7241: Subject: Franz for VAX730
7242:
7243: 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.
7244: Bill Cadwallender (wkc@ARDC)
7245:
7246: From RZ@MIT-MC Thu Jun 21 19:26:57 1984
7247: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7248: id AA08546; Thu, 21 Jun 84 19:26:57 pdt
7249: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7250: id AA27996; Thu, 21 Jun 84 19:24:37 pdt
7251: Message-Id: <[email protected]>
7252: Date: 21 June 1984 22:28-EDT
7253: From: Richard E. Zippel <RZ@MIT-MC>
7254: Subject: MIT flavors
7255: To: franz-friends@BERKELEY
7256: Cc: zymelman@MITRE, smh@MIT-VAX
7257: In-Reply-To: Msg of 21 Jun 1984 9:19:16 EDT () from Ari Zymelman <m13676 at mitre>
7258:
7259: I am happy to report than the MIT flavor system is finally available. I
7260: won't try to correct the numerous bits of misinformation that have been
7261: spread about this other than to say that the MIT flavor system can now be
7262: freely distributed, if it is not used for profit, and the MIT copyrights are
7263: maintained in the sources. Berkeley has a copy of the most recent version
7264: of the code and should include it in their standard distributions shortly.
7265:
7266:
7267: From hoey@nrl-aic Wed Jun 27 14:24:24 1984
7268: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7269: id AA19372; Wed, 27 Jun 84 14:24:24 pdt
7270: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7271: id AA13744; Wed, 27 Jun 84 14:21:16 pdt
7272: Message-Id: <[email protected]>
7273: Date: 27 Jun 1984 16:42-EDT
7274: From: Dan Hoey <hoey@NRL-AIC>
7275: Subject: Incorrect "make fromasm" in 68k franz 38.91
7276: To: franz-friends@BERKELEY
7277: Cc: dejong@nrl-aic, franz-bugs@BERKELEY
7278:
7279: Problem:
7280: The "make fromasm" option for franz installation on a 68k does not work
7281: as distributed.
7282:
7283: Diagnosis:
7284: The assembler is used to convert *.s files into *.o. But the output of
7285: as defaults to "a.out" and is not overridden, so no *.o files are
7286: produced.
7287:
7288: Fixes:
7289: Specify the output file in the fromasm: option in lisplib/Makefile and
7290: liszt/68k/Makefile.
7291:
7292: In lisplib/Makefile, and (if make copylibrary has been done) in
7293: /usr/lib/lisp/Makefile, change
7294:
7295: < for i in *.s; do echo $$i; ${LibDir}/as $$i; done
7296: ----
7297: > for i in *.s; do echo $$i; \
7298: > ${LibDir}/as $$i -o `basename $$i .s`.o; done
7299:
7300: In liszt/68k/Makefile, change
7301:
7302: < for i in *.s; do echo $$i; as $$i; done
7303: ----
7304: > for i in *.s; do echo $$i; \
7305: > as $$i -o `basename $$i .s`.o; done
7306:
7307: Bugs:
7308: 1. One version specifies ${LibDir}/as, the other uses vanilla as. I
7309: didn't change it, but perhaps the liszt/68k/Makefile should also
7310: specify ${LibDir}/as.
7311:
7312: 2. Isn't there a cleaner way of doing this? Can a ".s.o:" rule be
7313: specified?
7314:
7315: Dan
7316:
7317: From @MIT-MC:[email protected] Mon Jul 9 22:06:26 1984
7318: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7319: id AA17486; Mon, 9 Jul 84 22:06:26 pdt
7320: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7321: id AA24170; Mon, 9 Jul 84 22:05:52 pdt
7322: Message-Id: <[email protected]>
7323: Date: 9 Jul 1984 21:10:53-EDT
7324: From: Richard.Wallace@CMU-CS-H
7325: Subject: Bell quote
7326: Apparently-To: <franz-friends@UCB-VAX>
7327:
7328: Lisp, designed about 1960 by John McCarthy, impressed me so
7329: much that I included the critcal data access primitives
7330: in the architecture of the DEC System 10 in 1965 (still
7331: about the fastest Lisp computer).
7332:
7333: - C. Gordon Bell
7334: IEEE Computer
7335: June, 1984
7336:
7337:
7338:
7339: From kanderso@bbn-vax Tue Jul 10 11:41:39 1984
7340: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7341: id AA25755; Tue, 10 Jul 84 11:41:39 pdt
7342: Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7343: id AA06454; Tue, 10 Jul 84 11:29:28 pdt
7344: Message-Id: <[email protected]>
7345: Date: Tue, 10 Jul 84 14:28 EDT
7346: From: Ken Anderson <kanderso@bbn-vax>
7347: Subject: Problem compiling flavors in Opus 83.79
7348: To: franz-friends@BERKELEY
7349: Cc: franz-composers@BERKELEY, lbagnall@bbn, jchung@bbn
7350:
7351: When trying to make flavors from the version in pub/lib on ucbkim,
7352: liszt complains about calling an undefined function e-sub2. Here is
7353: the output of my makefile. Any suggestions?
7354:
7355: liszt -a flavorm
7356: Compilation begins with Liszt vax version 8.36
7357: source: flavorm.l, result: flavorm.o
7358: [fasl /usr/lib/lisp/machacks.o]
7359: [autoload /usr/lib/lisp/struct]
7360: [fasl /usr/lib/lisp/struct.o]
7361: flavor-plist
7362: flavor-init-keywords
7363: flavor-initable-instance-variables
7364: flavor-settable-instance-variables
7365: flavor-gettable-instance-variables
7366: flavor-default-handler
7367: flavor-which-operations
7368: flavor-depends-on-all
7369: flavor-includes
7370: flavor-depended-on-by
7371: flavor-depends-on
7372: flavor-method-table
7373: flavor-all-instance-variables
7374: flavor-local-instance-variables
7375: flavor-name
7376: flavor-method-hash-table
7377: flavor-bindings
7378: make-flavor
7379: alter-flavor
7380: instancep
7381: instancep::cmacro:g00079
7382: send
7383: lexpr-send
7384: send-self
7385: lexpr-send-self
7386: g00100::send
7387: %Note: flavorm.l: Compilation complete
7388: %Note: flavorm.l: Time: Real: 0:32, CPU: 0:11.10, GC: 0:0.00 for 0 gcs
7389: %Note: flavorm.l: Assembly begins
7390: %Note: flavorm.l: Assembly completed successfully
7391: liszt -a flavors
7392: Compilation begins with Liszt vax version 8.36
7393: source: flavors.l, result: flavors.o
7394: [fasl /usr/lib/lisp/machacks.o]
7395: [fasl /usr/lib/lisp/lmhacks.o]
7396: [fasl flavorm.o]
7397: defflavor
7398: defun-method
7399: [autoload /usr/lib/lisp/struct]
7400: [fasl /usr/lib/lisp/struct.o]
7401: instance-variable-boundp
7402: instance-flavor
7403: instance-flavor::cmacro:g00068
7404: instance-function
7405: instance-function::cmacro:g00075
7406: get-flavor
7407: instance-typep
7408: flavor-additional-instance-variables
7409: flavor-additional-instance-variables::cmacro:g00101
7410: flavor-instance-variable-initializations
7411: flavor-instance-variable-initializations::cmacro:g00108
7412: flavor-remaining-default-plist
7413: flavor-remaining-default-plist::cmacro:g00115
7414: flavor-remaining-init-keywords
7415: flavor-remaining-init-keywords::cmacro:g00122
7416: flavor-all-initable-instance-variables
7417: flavor-all-initable-instance-variables::cmacro:g00129
7418: g00133::flavor
7419: Undefined function called from compiled code e-sub2
7420: ?Error: flavors.l: : Lisp error during compilation
7421: make: *** Error code 1 ***
7422:
7423: From jkf@ucbmike Tue Jul 10 12:18:28 1984
7424: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7425: id AA27111; Tue, 10 Jul 84 12:18:28 pdt
7426: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
7427: id AA07135; Tue, 10 Jul 84 12:06:28 pdt
7428: Date: Tue, 10 Jul 84 12:07:07 pdt
7429: From: John Foderaro (on an sun) <jkf@ucbmike>
7430: Message-Id: <[email protected]>
7431: Received: by ucbmike.ARPA (4.24ucb/3.5)
7432: id AA03780; Tue, 10 Jul 84 12:07:07 pdt
7433: To: kanderso@bbn-vax, franz-friends@BERKELEY
7434: Subject: Re: Problem compiling flavors in Opus 83.79
7435: Cc: jchung@bbn, lbagnall@bbn, franz-composers@BERKELEY
7436: In-Reply-To: Your message of Tue, 10 Jul 84 14:28 EDT
7437:
7438: This bug was fixed a while back, but apparently after you got your lisp
7439: distribution. You should get the latest lisp distribution.
7440:
7441:
7442:
7443: From @MIT-MC:[email protected] Tue Jul 10 13:29:15 1984
7444: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7445: id AA28822; Tue, 10 Jul 84 13:29:15 pdt
7446: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7447: id AA08350; Tue, 10 Jul 84 13:28:25 pdt
7448: Message-Id: <[email protected]>
7449: Date: 10 Jul 1984 13:46:05-EDT
7450: From: Suzanne.Woolf@CMU-CS-SPICE
7451: Subject: pretty printer
7452: Apparently-To: <franz-friends@UCB-VAX>
7453:
7454: Does anyone out there know of a well-documented pretty printer for lisp? A
7455: friend of mine needs one that can be hacked up. Franz Lisp would be ideal,
7456: but anything similar is fine.
7457:
7458: Please send replies to:
7459: Jaffe@cmu-psy-a
7460:
7461: Thanks.
7462:
7463:
7464:
7465: From @MIT-MC:smh@MIT-EMS Tue Jul 10 15:29:20 1984
7466: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7467: id AA02481; Tue, 10 Jul 84 15:29:20 pdt
7468: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7469: id AA10890; Tue, 10 Jul 84 15:28:30 pdt
7470: Message-Id: <[email protected]>
7471: Date: 10 Jul 1984 18:24:02-EDT
7472: From: <smh@mit-ems@mit-mc>
7473: To: franz-friends@BERKELEY, kanderso@bbnvax
7474: Subject: Re: Problem compiling flavors in Opus 83.79
7475:
7476: A very quick check reveals the following suspiciousness: The function
7477: in flavors.l being compiled when the failure occurs is apparently:
7478:
7479: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS)
7480: (SELECTQ OPERATION
7481: (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE))
7482: (:PRINT-SELF
7483: (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS))
7484: (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF))))
7485: (:DESCRIBE (DESCRIBE-FLAVOR SELF))
7486: (OTHERWISE
7487: (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION))))
7488:
7489: This is the first appearance in the file of defun with a "function
7490: spec" instead of a symbol as the first argument. This is a Lisp
7491: Machine hack which basically means to squirrel the functional object
7492: away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR.
7493: (More precisely, the first arg is the Maclisp compatability syntax for
7494: (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...)
7495:
7496: Liszt could be choking as it tries to store into the
7497: function-definition slot of something other than a symbol. Such
7498: abilities of defun are not documented in Franz, and it might be that
7499: your defun macro in common0.l has not been extended for such usage.
7500: Locally it is defined as follows:
7501:
7502: ;--- defun
7503: ; maclisp style function defintion
7504: ;
7505: (def defun
7506: (macro (l)
7507: (prog (name type arglist body specind specnam)
7508: (setq name (cadr l) l (cddr l))
7509: (cond ((dtpr name)
7510: (cond ((memq (cadr name) '(macro expr fexpr lexpr))
7511: (setq l (cons (cadr name) l)
7512: name (car name)))
7513: (t (setq specnam (car name)
7514: specind (cadr name)
7515: name (concat (gensym) "::" specnam))))))
7516: (cond ((null (car l)) (setq type 'lambda))
7517: ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l)))
7518: ((eq 'expr (car l)) (setq type 'lambda l (cdr l)))
7519: ((eq 'macro (car l)) (setq type 'macro l (cdr l)))
7520: ((atom (car l))
7521: (setq type 'lexpr
7522: l (nconc (list (list (car l)))
7523: (cdr l))))
7524: (t (setq type 'lambda)))
7525: (setq body (list 'def name (cons type l)))
7526: (cond (specnam
7527: (return (list 'progn ''compile
7528: body
7529: (list 'putprop
7530: (list 'quote specnam)
7531: (list 'getd
7532: (list 'quote name))
7533: (list 'quote specind)))))
7534: (t (return body))))))
7535:
7536: You could also check by invoking liszt without arguments and then
7537: asking it
7538: (testmac '(defun (foo bar) () (hello goodbye)))
7539: and seeing if it properly generates
7540: (progn 'compile (defun ... ) (putprop ... ))
7541:
7542: On another matter, I have recently been making a number of minor
7543: bugfixes to the flavor and various other MIT compatibility packages.
7544: These files come indirecly from Maclisp or Lisp Machines, and the ports
7545: have generally never been exercised sufficiently to check all the
7546: obscure features. These fixes postdate the versions Rich Zippel
7547: recently transmitted to Berkeley. I will shortly distribute the
7548: new versions to Berkeley.
7549:
7550: Believe it or not, the flavor system really does work under Franz.
7551: So do hash tables, defstruct, format, etc. I use them every day.
7552:
7553: Steve Haflich, MIT Experimental Music Studio
7554: smh@mit-ems@mit-mc
7555: {decvax!genrad, ihnp4}!mit-eddie!smh
7556:
7557:
7558: From abar@ucbernie Tue Jul 10 23:04:16 1984
7559: Received: from ucbernie.ARPA by ucbkim.ARPA (4.28/4.27)
7560: id AA08764; Tue, 10 Jul 84 23:04:16 pdt
7561: Received: by ucbernie.ARPA (4.28/4.30)
7562: id AA06176; Tue, 10 Jul 84 23:02:56 pdt
7563: Date: Tue, 10 Jul 84 23:02:56 pdt
7564: From: abar@ucbernie (Robert Abarbanel)
7565: Message-Id: <[email protected]>
7566: To: franz-friends@ucbernie
7567: Subject: &optional, &rest, &aux
7568:
7569: Any way to get these &args to work without compilation... that is, when
7570: a function is working interpreted?
7571:
7572: From kanderso@bbn-vax Wed Jul 11 12:25:52 1984
7573: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7574: id AA17391; Wed, 11 Jul 84 12:25:52 pdt
7575: Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7576: id AA19991; Wed, 11 Jul 84 12:24:54 pdt
7577: Message-Id: <[email protected]>
7578: Date: Wed, 11 Jul 84 15:24 EDT
7579: From: Ken Anderson <kanderso@bbn-vax>
7580: Subject: bugs in hash.l and array.l
7581: To: franz-friends@BERKELEY
7582: Cc: lbagnall@bbn, jchung@bbn
7583:
7584: To get Flavors working in Opus 38.91 you will need to fix a bug in
7585: lisplib/hash.l. Change all occurances of "getlength" to "vsize".
7586:
7587: Although unrelated to Flavors, there are several problems with
7588: the functions, fillarray fillarrayarray and listarray in
7589: lisplib/array.l. Here is an ed script produced by diff:
7590:
7591: 285,286c
7592: (cond ((or (arrayp arr) ; KRA
7593: (and (symbolp arr) (arrayp (setq arr (getd arr))))))
7594: .
7595: 282,283c
7596: (lexpr (n)
7597: (prog (arr size typ ret newv)
7598: .
7599: 280a
7600: ; KRA 83-11-2: Arrays need not be symbols.
7601: .
7602: 279c
7603: (replace (arrayref arrto i) (arrayref arrfrom i)))
7604: (return arrto)))) ; KRA
7605: .
7606: 270c
7607: (cond ((cdr ls) (setq ls (cdr ls)))))
7608: (return arr)))) ; KRA
7609: .
7610: 244a
7611: ; KRA 83-11-2: Fillarray and fillarrayarray should return the array!
7612: .
7613:
7614: From jkf@ucbmike Wed Jul 11 13:43:49 1984
7615: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7616: id AA20014; Wed, 11 Jul 84 13:43:49 pdt
7617: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31)
7618: id AA21120; Wed, 11 Jul 84 13:32:32 pdt
7619: Date: Wed, 11 Jul 84 13:32:52 pdt
7620: From: John Foderaro (on an sun) <jkf@ucbmike>
7621: Message-Id: <[email protected]>
7622: Received: by ucbmike.ARPA (4.24ucb/3.5)
7623: id AA05402; Wed, 11 Jul 84 13:32:52 pdt
7624: To: franz-friends@BERKELEY
7625: Subject: Re: &optional, &rest, &aux
7626: Cc: franz-composers@BERKELEY
7627: In-Reply-To: Your message of 11 Jul 1984 15:12:07-EDT
7628:
7629: The problem with the &optional and &rest was due to abar using the
7630: cmufile package, which redefines 'def' and doesn't look for those
7631: keywords.
7632:
7633:
7634:
7635: From [email protected] Wed Jul 11 20:29:28 1984
7636: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7637: id AA25212; Wed, 11 Jul 84 20:29:28 pdt
7638: Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7639: id AA28089; Wed, 11 Jul 84 20:28:27 pdt
7640: Reply-To: [email protected]
7641: Received: by cadre.UUCP (4.12/3.14)
7642: id AA22394; Wed, 11 Jul 84 23:22:09 edt
7643: Date: Wed, 11 Jul 84 23:22:09 edt
7644: From: cadre!sm (Sean McLinden)
7645: Message-Id: <[email protected]>
7646: To: [email protected]
7647: Subject: redefinition of existing flavors
7648: Cc: franz-friends@BERKELEY
7649:
7650:
7651: As distributed by Berkeley, the flavors package on Opus 38.89
7652: appears to work in all cases except when a flavor is redefined
7653: and perform-flavor-redefinition is invoked. The problem, I
7654: thought, was in copy-hunk-contents, since the default structures
7655: (and therefore flavors), in Opus 38.89, are VECTORS, not HUNKS.
7656: However, modifying copy-hunk-contents to copy VECTORS did not,
7657: completely, fix the problem (i.e, the first modification after
7658: redefinition of copy-hunk-contents caused an error, the second
7659: worked but then describe did not work for old instances of the
7660: flavor).
7661:
7662: Before delving into code with which I am unfamiliar are there
7663: any differences between Opus 38.89 and 38.91 which might explain
7664: this?
7665:
7666: Sean McLinden
7667: Decision Systems Lab
7668: University of Pittsburgh
7669:
7670:
7671: From harrison@nrl-aic Thu Jul 12 07:15:39 1984
7672: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7673: id AA28967; Thu, 12 Jul 84 07:15:39 pdt
7674: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7675: id AA07280; Thu, 12 Jul 84 07:14:50 pdt
7676: Date: 12 Jul 1984 10:08-EDT
7677: From: Patrick Harrison <harrison@NRL-AIC>
7678: Subject: Lisp for Honeywell 6060 DPS-8
7679: To: ailist@sri-ai
7680: Cc: franz-friends@BERKELEY
7681: Message-Id: <84/07/12 1008.550@NRL-AIC>
7682:
7683:
7684: Am looking for information on current versions of LISP (FranzLisp,
7685: MacLisp) running in a Honeywell 6060, DPS-8 environment. Would also
7686: like to implement OPS5 on same. Address:
7687:
7688: Dr. Patrick Harrison
7689: Computer Science Department
7690: U.S. Naval Academy
7691: Annapolis, Maryland 21402.
7692:
7693: Responses to above address or <harrison@nrl-aic>
7694:
7695: From @MIT-MC:mhs@MIT-HTVAX Tue Jul 17 12:45:10 1984
7696: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7697: id AA00659; Tue, 17 Jul 84 12:45:10 pdt
7698: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7699: id AA02214; Mon, 16 Jul 84 16:28:19 pdt
7700: Message-Id: <[email protected]>
7701: Date: 16 Jul 1984 16:32:48-EDT
7702: From: mhs@mit-htvax@mit-mc
7703: To: franz-friends@berkeley@mit-mc
7704: Subject: Small bug in flavors.l
7705: Cc: mhs@mit-htvax@mit-mc
7706:
7707: The following test demonstrates a problem with flavors.l as it is
7708: distributed with Release 38.91. (The "a" after the minor number indicates a
7709: couple of changes made locally - mostly involving preloading struct, loop and
7710: such. flavors.l wasn't touched.)
7711:
7712: The problem is that simple method combination doesn't work for trivial
7713: reasons. A fix is suggested below. As the example shows, the combined method
7714: for :PROGN combination is wrong. (:OR, :LIST ... all have the same problem).
7715:
7716: Franz Lisp, Opus 38.91a (with Zetalisp compatability package)
7717: -> (defflavor object
7718: (color)
7719: ()
7720: :gettable-instance-variables
7721: :settable-instance-variables
7722: :initable-instance-variables
7723: (:method-combination (:progn :base-flavor-last :test1)))
7724: object
7725: -> (defmethod (object :test1) ()
7726: (format t "~&object :test1~%"))
7727: (:method object :test1)
7728: -> (defflavor car
7729: (price)
7730: (object)
7731: :gettable-instance-variables
7732: :settable-instance-variables
7733: :initable-instance-variables)
7734: car
7735: -> (defmethod (car :test1) ()
7736: (format t "~&car :test1~%"))
7737: (:method car :test1)
7738: -> (setq car (make-instance 'car))
7739: #<car 591928>
7740: -> (send car ':test1)
7741: |Error:| eval: Undefined function :progn
7742: <1>: (debug)
7743:
7744: <------debug------>
7745:
7746: :bk
7747:
7748: <------debug------> <--- you are here
7749: (eval (debug))
7750: (break-err-handler (|ER%undef| 0 t |eval: Undefined function | :progn))
7751: (:progn (lexpr-funcall (function car-test1-method) .daemon-caller-args.) (lexpr-funcall (function object-test1-method) .daemon-caller-args.))
7752: ((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)))
7753: ,
7754: ,
7755: ,
7756: (send car (quote :test1))
7757: (eval (send car (quote :test1)))
7758: <bottom of stack>
7759:
7760: Look at the combined method:
7761:
7762: (:progn
7763: (lexpr-funcall (function car-test1-method) .daemon-caller-args.)
7764: (lexpr-funcall (function object-test1-method) .daemon-caller-args.))
7765:
7766: I think the problem is caused by the fact that in the older package system,
7767: the keyword package inherited from the global package. Thus :PROGN (in the
7768: keyword package) was the same atom as PROGN (in global). However, this isn't
7769: true in Franz. :PROGN isn't EQ to PROGN, and it shouldn't be. (The same
7770: problem occurs for all of the other simple method combination types too, e.g.
7771: :OR, :LIST ...). One possible fix is to add an alist
7772: (SIMPLE-METHOD-COMBINATION-TYPE-ALIST) to store the correspondence between
7773: :PROGN and PROGN, like so: (I just tested this code locally and it seemed to
7774: work.)
7775:
7776: #+franz
7777: (DEFCONST SIMPLE-METHOD-COMBINATION-TYPE-ALIST
7778: '((:PROGN . PROGN)
7779: (:AND . AND)
7780: (:OR . OR)
7781: (:MAX . MAX)
7782: (:MIN . MIN)
7783: (:+ . +)
7784: (:APPEND . APPEND)
7785: (:NCONC . NCONC)))
7786:
7787: (DEFUN SIMPLE-METHOD-COMBINATION (FL MAGIC-LIST-ENTRY)
7788: (LET ((METHODS (GET-CERTAIN-METHODS MAGIC-LIST-ENTRY NIL NIL NIL NIL))
7789: (WRAPPERS-P (SPECIALLY-COMBINED-METHODS-PRESENT MAGIC-LIST-ENTRY)))
7790: (OR (AND (NOT WRAPPERS-P) (NULL (CDR METHODS)) (CAR METHODS))
7791: (HAVE-COMBINED-METHOD FL MAGIC-LIST-ENTRY)
7792: (MAKE-COMBINED-METHOD FL MAGIC-LIST-ENTRY
7793: ;; In the old package system, :progn maps to progn trivially
7794: ;; via package inheritance (keyword inherits from global).
7795: ;; In Franz, we use an alist to implement the mapping.
7796: (CONS #-franz (CADR MAGIC-LIST-ENTRY)
7797: #+franz (CDR (ASSQ (CADR MAGIC-LIST-ENTRY)
7798: SIMPLE-METHOD-COMBINATION-TYPE-ALIST))
7799: (MAPCAR 'METHOD-CALL
7800: METHODS))))))
7801:
7802:
7803: From "Gladd Tom"@LLL-MFE.ARPA Wed Jul 18 10:44:03 1984
7804: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7805: id AA00765; Wed, 18 Jul 84 10:44:03 pdt
7806: Received: from LLL-MFE.ARPA (lll-mfe.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31)
7807: id AA01412; Wed, 18 Jul 84 10:42:20 pdt
7808: Message-Id: <[email protected]>
7809: Date: Wed, 18 Jul 84 10:35 PDT
7810: From: "Gladd Tom"@LLL-MFE.ARPA
7811: Subject: join list 619-453-6580
7812: To: franz-friends@BERKELEY
7813:
7814: i would like to join your list. i am very interested in list in general
7815: and have been trying to learn it in a near vacuum (small hi-tech company
7816: in sandiego. i am especially interested in advanced coding techniques
7817: (at least beyond the standard texts). my background is theoretical
7818: plasma physics. i have used and am very interested in macsyma.
7819: my address is "gladd tom%cma"@lll-mfe.arpa
7820:
7821: From @MIT-MC:[email protected] Wed Jul 25 10:06:41 1984
7822: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7823: id AA08698; Wed, 25 Jul 84 10:06:41 pdt
7824: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7825: id AA19747; Wed, 25 Jul 84 10:05:06 pdt
7826: Message-Id: <[email protected]>
7827: Date: 25 Jul 1984 12:30:25-EDT
7828: From: Philip.Kasprzyk@CMU-RI-ISL2
7829: Subject: Lisp Speed Benchmarks
7830: Apparently-To: <franz-friends@UCB-VAX>
7831:
7832: ~v
7833: I am interested in determining the absolute speed of execution of a lisp
7834: system. I realize that this is a complicated task that is application
7835: and implementation dependant. Nevertheless I am seeking the following:
7836:
7837: 1) A "gibson mix" style benchmark for lisp based systems.
7838:
7839: 2) Any data that experienced users of lisp may have regarding performance.
7840: (I don't care what machine or dialect of lisp is reported)
7841:
7842: 3) Any method or program which translates a lisp program into another
7843: target high level language with execution speed as its objective.
7844: (I don't mean a normal lisp compiler)
7845:
7846: Can anyone out there help me?
7847:
7848: If so send mail to pmk@isl2.
7849:
7850:
7851:
7852: From mab@aids-unix Fri Jul 27 14:35:21 1984
7853: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7854: id AA29865; Fri, 27 Jul 84 14:35:21 pdt
7855: Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7856: id AA04068; Fri, 27 Jul 84 14:33:40 pdt
7857: Message-Id: <[email protected]>
7858: Date: 27 Jul 84 14:23:47 PDT (Fri)
7859: From: Mike Brzustowicz <mab@aids-unix>
7860: Subject: Benchmarks
7861: To: franz-friends@BERKELEY
7862:
7863: Does anyone have any small LISP programs that can be abused as benchmarks?
7864: (They need to be small is source only.) I need some very soon. Thanks!
7865:
7866: -Mike
7867: <mab@aids-unix>
7868:
7869: From [email protected] Fri Jul 27 15:15:06 1984
7870: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7871: id AA01124; Fri, 27 Jul 84 15:15:06 pdt
7872: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7873: id AA04900; Fri, 27 Jul 84 15:13:09 pdt
7874: Message-Id: <[email protected]>
7875: Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT
7876: Date: 27 Jul 84 15:14 PDT
7877: From: [email protected]
7878: Subject: Re: Benchmarks
7879: In-Reply-To: Mike Brzustowicz <[email protected]>'s message of 27 Jul
7880: 84 14:23:47 PDT (Fri)
7881: To: [email protected]
7882: Cc: franz-friends@BERKELEY
7883:
7884: Here's a good benchmark:
7885:
7886: (defun nilret () nil)
7887:
7888: this is a good test of how fast your lisp returns NIL.
7889:
7890: I also like
7891:
7892: (defun retjunk (x) (cond((junkp x) 'junk)
7893: ((cdr x) (retjunk (car x)))
7894: ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x))))
7895: (t (retjunk (cons 'junk x))))
7896:
7897: (defun junkp (x) (equal (reverse (explode x)) (reverse (explode
7898: 'junk))))
7899:
7900:
7901: This benchmark measures how fast your lisp can return junk, executing
7902: the retjunk function.
7903:
7904: Both of the benchmarks have the adavantage that they are small and can
7905: be abused as benchmarks.
7906:
7907: From @USC-ECL.ARPA:BENSON@ECLD Tue Jul 31 20:02:20 1984
7908: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27)
7909: id AA21521; Tue, 31 Jul 84 20:02:20 pdt
7910: Received: from USC-ECL.ARPA (usc-ecl.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7911: id AA02839; Tue, 31 Jul 84 20:00:29 pdt
7912: Message-Id: <[email protected]>
7913: Received: from ECLD by ECLA with ECLnet; Tue 31 Jul 84 19:56:31-PDT
7914: Date: Tue 31 Jul 84 19:33:52-PDT
7915: From: Eric Benson <BENSON@ECLD.#ECLnet>
7916: Subject: Re: Lisp Speed Benchmarks
7917: To: [email protected]
7918: Cc: BENSON@ECLD.#ECLnet, Franz-Friends@BERKELEY
7919: In-Reply-To: Message from "Philip.Kasprzyk@CMU-RI-ISL2" of Wed 25 Jul 84 09:30:25-PDT
7920:
7921: There is a set of benchmarks which have been run on a variety of Lisp
7922: systems which have been compiled by Richard Gabriel at Stanford. You
7923: should contact Paul Wieneke (PW@SU-AI) for more information.
7924: -------
7925:
7926: From narain@rand-unix Wed Aug 1 12:31:21 1984
7927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
7928: id AA00623; Wed, 1 Aug 84 12:31:21 pdt
7929: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7930: id AA00567; Wed, 1 Aug 84 12:29:40 pdt
7931: Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt
7932: From: Sanjai Narain <narain@rand-unix>
7933: Message-Id: <[email protected]>
7934: Date: 01 Aug 84 11:04:25 PDT (Wed)
7935: To: franz-friends@BERKELEY
7936: Subject: Fast recompiling
7937:
7938:
7939: Often we have files consisting of large numbers of functions which are
7940: compiled. Sometimes, just one of these functions needs to be changed. It
7941: would be nice to recompile just this function, and copy already compiled
7942: functions to produce a fresh version of the compiled file. Is there any
7943: quick method of doing this in Franz Lisp i.e. is there an equivalent of
7944: Interlisp's "recompile" function.
7945:
7946: I would be grateful for your response.
7947:
7948: -- Sanjai Narain
7949:
7950: From fateman@ucbdali Wed Aug 1 13:24:30 1984
7951: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
7952: id AA03438; Wed, 1 Aug 84 13:24:30 pdt
7953: Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33)
7954: id AA01542; Wed, 1 Aug 84 13:06:01 pdt
7955: Received: by ucbdali.ARPA (4.24/4.27)
7956: id AA00994; Wed, 1 Aug 84 13:07:35 pdt
7957: Date: Wed, 1 Aug 84 13:07:35 pdt
7958: From: fateman@ucbdali (Richard Fateman)
7959: Message-Id: <[email protected]>
7960: To: franz-friends@BERKELEY, narain@rand-unix
7961: Subject: Re: Fast recompiling
7962:
7963: This would be an interesting feature, but it is complicated by the
7964: possibility that the compilation environment is built up in a typical
7965: large Franz system, by processing the whole file. I think that the
7966: interlisp situation is usually simpler.
7967: For example, in recompiling Macsyma, sometimes a file itself or
7968: function definitions in it do not change at all. A "macro definition"
7969: file which is included in the compilation environment can, however, change
7970: the generated code, substantially.
7971: Something like UNIX's "make" might be needed.
7972:
7973: Alternatively, you can use smaller files...
7974:
7975: From jkf@ucbmike Thu Aug 2 16:10:04 1984
7976: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
7977: id AA16097; Thu, 2 Aug 84 16:10:04 pdt
7978: Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33)
7979: id AA00501; Thu, 2 Aug 84 16:08:09 pdt
7980: Date: Thu, 2 Aug 84 16:09:45 pdt
7981: From: John Foderaro (on an sun) <jkf@ucbmike>
7982: Message-Id: <[email protected]>
7983: Received: by ucbmike.ARPA (4.24ucb/3.5)
7984: id AA01757; Thu, 2 Aug 84 16:09:45 pdt
7985: To: franz-friends@BERKELEY
7986: Subject: repeated messages
7987: Cc:
7988:
7989: I'm sorry about the repeated messages. Our mailing machine got a bit
7990: overloaded. I've modified the organization of the list to try to
7991: fix the problem.
7992:
7993:
7994:
7995: From NET-ORIGIN@MIT-MC Fri Aug 3 15:15:44 1984
7996: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
7997: id AA26463; Fri, 3 Aug 84 15:15:44 pdt
7998: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
7999: id AA04086; Fri, 3 Aug 84 15:13:41 pdt
8000: Received: from mit-heracles (mit-heracles.ARPA) by mit-charon (4.12/4.7)
8001: id AA13781; Fri, 3 Aug 84 14:32:51 edt
8002: Received: by mit-heracles (4.12/4.7)
8003: id AA20045; Fri, 3 Aug 84 14:35:30 edt
8004: From: yba@mit-heracles (Mark H Levine)
8005: Message-Id: <8408031835.AA20045@mit-heracles>
8006: Date: 3 Aug 1984 1435-EDT (Friday)
8007: To: franz-friends@BERKELEY
8008: Subject: Opus 37.79 building from source
8009:
8010:
8011: Has anyone published a fix to the bug that causes "rawlisp" to take a
8012: memory fault when built from vanilla 4.2bsd sources?
8013:
8014: It seems that the routine "getatom" in franz/alloc.c calls strcmp
8015: with "name" equal to "mod" and "aptr -> a.pname" equal to CNIL (-4).
8016:
8017: This is presumably a side effect of some other error; it still causes
8018: a memory fault in strcmp and prevents building from source. The sources
8019: have some Sept. '83 changes to the library code, but are otherwise con-
8020: sistent with all the 4.2 code I have seen.
8021:
8022: Got a fix handy?
8023:
8024:
8025:
8026: From liz@maryland Mon Aug 6 07:41:41 1984
8027: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8028: id AA16830; Mon, 6 Aug 84 07:41:41 pdt
8029: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33)
8030: id AA06949; Mon, 6 Aug 84 07:39:52 pdt
8031: Received: by maryland.ARPA (4.12/4.7)
8032: id AA01505; Mon, 6 Aug 84 10:40:52 edt
8033: Date: Mon, 6 Aug 84 10:40:52 edt
8034: From: liz@maryland (Liz Allen)
8035: Message-Id: <[email protected]>
8036: To: franz-friends@BERKELEY, yba%[email protected]
8037: Subject: Re: Opus 37.79 building from source
8038:
8039: That sounds like an error I ran into recently -- only it was with Opus
8040: 38.91 and it was also because I was adding more strings to rawlisp.
8041: Anyway, the fix was easy and is probably worth trying. Go into
8042: franz/data.c and change the size of i_strbuf and make it bigger. Ours
8043: was 600, and I made it 1000. You'll also need to change the
8044: initialization for i_strbuf; I changed ours from "i_strbuf + 599" to
8045: "i_strbuf + 999".
8046:
8047: Hope this helps!
8048:
8049: -Liz
8050:
8051: From smotroff@bbncct Wed Aug 8 14:39:03 1984
8052: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8053: id AA23393; Wed, 8 Aug 84 14:39:03 pdt
8054: Received: from bbncct (bbncct.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8055: id AA21105; Wed, 8 Aug 84 14:39:58 pdt
8056: Message-Id: <[email protected]>
8057: Date: Wed, 8 Aug 84 17:28:58 EDT
8058: From: Ira Smotroff <[email protected]>
8059: Subject: add me to the list
8060: To: franz-friends@BERKELEY
8061:
8062: please add my name to the franz-friends list
8063:
8064:
8065: smotroff at bbn
8066:
8067:
8068: From booker@nrl-aic Fri Aug 10 06:18:45 1984
8069: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8070: id AA13113; Fri, 10 Aug 84 06:18:45 pdt
8071: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8072: id AA14441; Fri, 10 Aug 84 06:19:43 pdt
8073: Message-Id: <[email protected]>
8074: Date: 10 Aug 1984 09:09:24-PDT
8075: From: Lashon Booker <booker@NRL-AIC>
8076: To: franz-friends@BERKELEY
8077: Subject: Interlisp Compatibility Package?
8078:
8079: Has anyone written an Interlisp compatibility package
8080: for Franz? Thanks.
8081:
8082: Lashon Booker
8083: booker@nrl-aic
8084:
8085: From @MIT-MC:smh@MIT-EMS Fri Aug 10 13:14:44 1984
8086: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8087: id AA01017; Fri, 10 Aug 84 13:14:44 pdt
8088: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8089: id AA21922; Fri, 10 Aug 84 13:15:43 pdt
8090: Message-Id: <[email protected]>
8091: Date: 10 Aug 1984 16:06:48-EDT
8092: From: smh@mit-ems@mit-mc
8093: To: franz-friends@BERKELEY
8094: Subject: (atom VECTOR): franz vs liszt
8095:
8096: Versions: Franz 38.91, Liszt 8.39, and probably most others.
8097:
8098: Description:
8099: The atom predicate operates inconsistently between compiled and
8100: interpreted code when passed a vector or vectori.
8101:
8102: Repeat-by:
8103: Create and compile a file containing the following definition:
8104: (defun atum(x) (atom x))
8105: After loading it into the interpreter the following results can
8106: be obtained:
8107: (setq v (vector 1 2 3))
8108: (atom v) ===> t
8109: (atum v) ===> nil
8110:
8111: Discussion:
8112: According to the manual, atom returns "t iff g_arg is not a list or
8113: hunk object." By this definition, the interpreter is correct and the
8114: compiler incorrect. However, one can make a strong argument that
8115: vectors, analogously to hunks, should not be considered atoms.
8116: Therefore, the both the documentation and interpreter should be
8117: changed. (It is doubtful very much existing code depends on this.)
8118:
8119: Suggested fix:
8120: Change the definition of atom section 2 of the manual to read:
8121: "t iff g_arg is not a list, hunk, vector, or vectori object."
8122: Add the following definition to franz/h/global.h, after the existing
8123: definition of HUNKP:
8124: #define HUNKORVECP(a1) ((TYPE(a1) >= 11) & (TYPE(a1) <= 19))
8125: Change the definition of Latom in franz/lam1.c:
8126: lispval
8127: Latom()
8128: {
8129: register struct argent *lb = lbot;
8130: chkarg(1,"atom");
8131: ==> if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val)))
8132: return(nil);
8133: else
8134: return(tatom);
8135: }
8136:
8137: Alternative suggested fix:
8138: If franz-composers really feel that atom ought to treat hunks
8139: and vectors differently (sigh?), then fix the compiler instead
8140: of the interpreter and documentation. The most important thing
8141: is that interpreted and compiler do the same thing!
8142: In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition
8143: of the mask constant.
8144:
8145: Random (constructive) flame:
8146: The interpreter definition above has to lookup the type of its
8147: argument expensively in the typetable *three* times, to wit:
8148: #define ATOX(a1) ((((int)(a1)) - OFFSET) >> 9)
8149: #define TYPE(a1) ((typetable+1)[ATOX(a1)])
8150: While compiled code is admirably streamlined, the interpreter
8151: could be made significantly faster here and elsewhere if TYPE
8152: were evaluated only once and held for examination in a
8153: temporary. This would require a bunch more type predicate
8154: DEFINEs operating on TYPE values instead of object addresses.
8155:
8156: Steve Haflich
8157: smh%mit-ems@mit-mc
8158: {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh
8159:
8160:
8161: From [email protected] Mon Aug 13 13:25:44 1984
8162: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8163: id AA03640; Mon, 13 Aug 84 13:25:44 pdt
8164: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8165: id AA05890; Mon, 13 Aug 84 13:26:52 pdt
8166: Message-Id: <[email protected]>
8167: Received: from Semillon.ms by ArpaGateway.ms ; 13 AUG 84 13:24:39 PDT
8168: Date: 13 Aug 84 13:24 PDT
8169: From: [email protected]
8170: Subject: Re: (atom VECTOR): franz vs liszt
8171: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 10 Aug 84 16:06:48
8172: EDT
8173: To: "smh@mit-ems"@MIT-MC.ARPA
8174: Cc: franz-friends@BERKELEY, [email protected], [email protected]
8175:
8176: Perhaps this bug should be forwarded to BUG-LISP@MIT-MC, since the
8177: original design flaw is in MacLisp. The problem is that when Hunks were
8178: first invented, there where some who wanted them as "annotated" list
8179: cells (hence, they weren't ATOMs) while other wanted them as small
8180: VECTORs (hence there should be ATOMs). The resolution was some awful
8181: switch setting for whether or not to treat them as ATOMs, but I don't
8182: remember the default setting, nor the final results.
8183:
8184: -- JonL --
8185:
8186:
8187:
8188:
8189: From ALAN@MIT-MC Mon Aug 13 17:15:11 1984
8190: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8191: id AA07443; Mon, 13 Aug 84 17:15:11 pdt
8192: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8193: id AA10564; Mon, 13 Aug 84 17:16:03 pdt
8194: Message-Id: <[email protected]>
8195: Date: 13 August 1984 20:08-EDT
8196: From: Alan Bawden <ALAN@MIT-MC>
8197: Subject: (atom VECTOR): franz vs liszt
8198: To: JonL.pa@XEROX
8199: Cc: GSB@MIT-MC, franz-friends@BERKELEY, smh@MIT-EMS
8200: In-Reply-To: Msg of 13 Aug 84 13:24 PDT from JonL.pa at XEROX.ARPA
8201:
8202: Date: 13 Aug 84 13:24 PDT
8203: From: JonL.pa at XEROX
8204: ... The resolution was some awful switch setting for whether or not to
8205: treat them as ATOMs, but I don't remember the default setting, nor the
8206: final results.
8207:
8208: There are indeed a couple of switches that control various random aspects
8209: of hunks, but none of them have any effect on their atomic or non-atomic
8210: nature. Hunks are never atoms in MacLisp. Everybody agrees that this is a
8211: loss, but at this point it is rather deeply ingrained into things to think
8212: about changing it.
8213:
8214:
8215: From [email protected] Tue Aug 14 01:53:12 1984
8216: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8217: id AA13476; Tue, 14 Aug 84 01:53:12 pdt
8218: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8219: id AA23091; Tue, 14 Aug 84 01:54:22 pdt
8220: Message-Id: <[email protected]>
8221: Received: From ct.csnet by csnet-relay; 14 Aug 84 4:31 EDT
8222: Date: 13 Aug 1984 20:46:42-PST
8223: From: jmiller%[email protected]
8224: To: franz-friends@BERKELEY
8225: Subject: bug in assoc
8226:
8227: The following illustrates a rather unpleasant bug in Franz's ASSOC (as
8228: of 38.26, anyhow). Be forewarned....
8229:
8230: ------------------------------------------------------------------------------
8231:
8232: 8_(setq l '((a 1) (b 2) (c 3))) ;;set up an a-list
8233: ((a 1) (b 2) (c 3))
8234:
8235: 9_(setq foo 'l) ;;FOO points to the NAME of the a-list
8236: l
8237:
8238: 10_(setq bar 'foo) ;;BAR points to the NAME of the NAME of
8239: foo ;;the a-list
8240:
8241: 11_(assoc 'b l) ;;This does the right thing
8242: (b 2)
8243:
8244: 12_(assoc 'b foo) ;;Gag me with a mouse -- should err
8245: (b 2) ;;with "bad arg to <something>"
8246:
8247: 13_(assoc 'b bar) ;;Double gag me with a mouse!!
8248: (b 2)
8249:
8250: ------------------------------------------------------------------------
8251:
8252: For the record, ASSQ is flawed in the same way.
8253:
8254:
8255: Jim Miller
8256: Computer Thought, Dallas
8257: [email protected]
8258: ...!convex!ctvax!jmiller
8259:
8260: From @MIT-MC:smh@MIT-EMS Tue Aug 14 07:35:27 1984
8261: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8262: id AA14507; Tue, 14 Aug 84 07:35:27 pdt
8263: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8264: id AA26447; Tue, 14 Aug 84 07:36:36 pdt
8265: Message-Id: <[email protected]>
8266: Date: 14 Aug 1984 08:40:00-EDT
8267: From: smh@mit-ems@mit-mc
8268: To: ALAN@mit-mc, GSB@mit-mc, JonL.pa@parc-maxc
8269: Subject: (atom VECTOR): franz vs liszt
8270: Cc: franz-friends@BERKELEY
8271:
8272: Gentlemen, I think we are losing grasp on the original bug report.
8273: This is probably my fault for including a discourse on the philosophy
8274: of hunks (:-) in the bug report.
8275:
8276: Maclisp ain't gonna change about hunks, and it would be a poor idea for
8277: Franz to change. Anyway, the bug is with vectors. In Franz, compiled
8278: and interpreted code disagree whether a vector is an atom. Certainly
8279: no one can defend this!
8280:
8281: Maclisp doesn't *have* vectors, does it?
8282:
8283: Steve Haflich
8284: smh%mit-ems@mit-mc
8285:
8286:
8287: From mcgeer Tue Aug 14 11:03:10 1984
8288: Received: by ucbkim.ARPA (4.24/4.27)
8289: id AA17397; Tue, 14 Aug 84 11:03:10 pdt
8290: Date: Tue, 14 Aug 84 11:03:10 pdt
8291: From: Rick McGeer (on an h19-u) <mcgeer>
8292: Message-Id: <[email protected]>
8293: Phone: (415) 236-8262
8294: To: ALAN@MIT-MC, JonL.pa@XEROX
8295: Subject: Re: (atom VECTOR): franz vs liszt
8296: Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC
8297: In-Reply-To: Your message of 13 August 1984 20:08-EDT
8298:
8299: The predicate atom in Franz appears to be:
8300:
8301: (defun atom(foo)
8302: (if foo
8303: then (not (or (hunkp foo) (dtpr foo)))
8304: else t))
8305:
8306: whereas a more natural implementation, it seems to me, is:
8307:
8308: (defun atom(foo)
8309: (or (symbolp foo) (numberp foo)))
8310:
8311: Since it seems to me that:
8312:
8313: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))
8314:
8315: should always be non-nil for non-nil objects. Or, better put, that vectors,
8316: hunks, dtprs, atoms, and arrays should partition the data space. No?
8317:
8318: Rick.
8319:
8320:
8321:
8322: From mcgeer Tue Aug 14 11:53:28 1984
8323: Received: by ucbkim.ARPA (4.24/4.27)
8324: id AA18832; Tue, 14 Aug 84 11:53:28 pdt
8325: Date: Tue, 14 Aug 84 11:53:28 pdt
8326: From: Rick McGeer (on an h19-u) <mcgeer>
8327: Message-Id: <[email protected]>
8328: Phone: (415) 236-8262
8329: To: jmiller%[email protected], franz-friends
8330: Subject: Re: bug in assoc
8331: Cc:
8332: In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST
8333:
8334: "'Curiouser and curiouser', said Alice". I dug out the source for
8335: assoc (38.79), and here it is:
8336:
8337: (def assoc
8338: (lambda (val alist)
8339: (do ((al alist (cdr al)))
8340: ((null al) nil)
8341: (cond ((null (car al)))
8342: ((not (dtpr (car al)))
8343: (error "bad arg to assoc" al))
8344: ((equal val (caar al)) (return (car al)))))))
8345:
8346: So nothing particularly screwy is going on here. However, when I do the
8347: traces (after setting up stuff the way you did), I get:
8348: => (assoc 'b 'l)
8349: 1 <Enter> assoc (b l)
8350: 1 <EXIT> assoc (b 2)
8351: (b 2)
8352: => (assoc 'b ''l)
8353: 1 <Enter> assoc (b 'l)
8354: Error: bad arg to assoc (quote l)
8355: Form: (assoc 'b ''l)
8356: {1} bar
8357: foo
8358: {1} (assoc 'b 'foo)
8359: |2 <Enter> assoc (b foo)
8360: |2 <EXIT> assoc (b 2)
8361: (b 2)
8362: {1} foo
8363: l
8364: {1} bar
8365: foo
8366: {1} (assoc 'b bar)
8367: |2 <Enter> assoc (b foo)
8368: |2 <EXIT> assoc (b 2)
8369: (b 2)
8370: {1} (assoc 'b ''l)
8371: |2 <Enter> assoc (b 'l)
8372: Error: bad arg to assoc (quote l)
8373: Form: (assoc 'b ''l)
8374: {2}
8375:
8376: Which is certainly *very* odd...
8377:
8378:
8379: From mcgeer Tue Aug 14 12:06:20 1984
8380: Received: by ucbkim.ARPA (4.24/4.27)
8381: id AA19018; Tue, 14 Aug 84 12:06:20 pdt
8382: Date: Tue, 14 Aug 84 12:06:20 pdt
8383: From: Rick McGeer (on an h19-u) <mcgeer>
8384: Message-Id: <[email protected]>
8385: Phone: (415) 236-8262
8386: To: ALAN@MIT-MC, JonL.pa@XEROX
8387: Subject: Re: (atom VECTOR): franz vs liszt
8388: Cc: smh@MIT-EMS, franz-friends, GSB@MIT-MC
8389:
8390: Sorry to anyone who's getting this twice: I can't figure out from
8391: the mailer error message who got it and who didn't...
8392:
8393:
8394: The predicate atom in Franz appears to be:
8395:
8396: (defun atom(foo)
8397: (if foo
8398: then (not (or (hunkp foo) (dtpr foo)))
8399: else t))
8400:
8401: whereas a more natural implementation, it seems to me, is:
8402:
8403: (defun atom(foo)
8404: (or (symbolp foo) (numberp foo)))
8405:
8406: Since it seems to me that:
8407:
8408: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo))
8409:
8410: should always be non-nil for non-nil objects. Or, better put, that vectors,
8411: hunks, dtprs, atoms, and arrays should partition the data space. No?
8412:
8413: Rick.
8414:
8415:
8416:
8417:
8418:
8419:
8420: From PSZ@MIT-MC Tue Aug 14 13:53:19 1984
8421: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8422: id AA20310; Tue, 14 Aug 84 13:53:19 pdt
8423: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8424: id AA03508; Tue, 14 Aug 84 13:54:23 pdt
8425: Message-Id: <[email protected]>
8426: Date: 14 August 1984 16:37-EDT
8427: From: Peter Szolovits <PSZ@MIT-MC>
8428: Subject: on the issue of the "ATOMness" of hunks
8429: To: ALAN@MIT-MC
8430: Cc: GSB@MIT-MC, PSZ@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY, smh@MIT-EMS
8431: In-Reply-To: Msg of 13 Aug 1984 20:08-EDT from Alan Bawden <ALAN>
8432:
8433: I have a small quarrel with Alan Bawden's statement that "hunks never
8434: being atoms in Maclisp" is a universally-agreed bug. There are indeed
8435: useful structures that one would like to build in Lisp that act as CONS
8436: cells (i.e., CAR and CDR are applicable), but that can have further
8437: structure. I have sorely missed such objects in Lisp Machine Lisp and
8438: NIL, where flavor-instances are always atomic, when I wanted to build
8439: Brand X (interned "list structure" and universal property lists). In
8440: Maclisp, I could do this using hunks, though even that was not
8441: completely right because I wanted to be able to disallow RPLACA and
8442: RPLACD while allowing CAR and CDR, and this was hard, given the hunk
8443: abstraction. I would, however, love to have non-atomic flavor-instances
8444:
8445:
8446: From @MIT-MC:smh@MIT-EMS Tue Aug 14 14:28:47 1984
8447: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8448: id AA20792; Tue, 14 Aug 84 14:28:47 pdt
8449: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8450: id AA04288; Tue, 14 Aug 84 14:29:41 pdt
8451: Message-Id: <[email protected]>
8452: Date: 14 Aug 1984 17:13:29-EDT
8453: From: smh@mit-ems@mit-mc
8454: To: mcgeer@ucbkim@BERKELEY
8455: Subject: Re: bug in assoc
8456: Cc: franz-friends@BERKELEY, [email protected]@udel-relay@mit-mc
8457:
8458: As McGeer@ucbkim points out, the code for assoc is (in common0.l):
8459:
8460: (def assoc
8461: (lambda (val alist)
8462: (do ((al alist (cdr al)))
8463: ((null al) nil)
8464: (cond ((null (car al)))
8465: ((not (dtpr (car al)))
8466: (error "bad arg to assoc" al))
8467: ((equal val (caar al)) (return (car al)))))))
8468:
8469: The reason for the reported strange behavior of assoc is as simple as
8470: it is obscure! First a couple hints:
8471: - This code is inside the executable franz interpreter and therefore
8472: runs compiled.
8473: - The same strangeness is exhibited by assq, which is C-coded inside
8474: the Franz kernel.
8475: - Both the cdr of a dtpr and the value of an atom are stored at offset
8476: zero within their respective structures. The car and plist
8477: similarly share the same offset within their structures.
8478: - If you try to run the above assoc definition interpreted, it will
8479: properly fail to work, or rather, it will complain about a bad arg
8480: to car.
8481: - Of course, c[ad]r in the interpreter carfully check their arguments;
8482: In the compiler, they simple indirect through pointers for maximum
8483: speed.
8484:
8485: Finally, in case by now it isn't absolutely clear to everyone what is
8486: going on, assoc is (sort of) comparing val against the plist of bar and
8487: subsequently foo, and then each time automagically effectively doing a
8488: symeval on the atom to continue scanning down the "cdr" of the alist.
8489:
8490: Moral: Although the interpreter tries pretty hard to do the dynamic
8491: typing and implied typechecking for which lisp is famous, type checking
8492: in compiled code is often a myth. Correct code only necessarily works
8493: correctly when given corrent arguments.
8494:
8495: Steve Haflich
8496: MIT Experimental Music Studio
8497: smh%mit-ems@mit-mc
8498: {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh
8499:
8500:
8501: From [email protected] Wed Aug 15 16:33:44 1984
8502: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8503: id AA00784; Wed, 15 Aug 84 16:33:44 pdt
8504: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8505: id AA05115; Wed, 15 Aug 84 14:20:30 pdt
8506: Message-Id: <[email protected]>
8507: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 14:19:35 PDT
8508: Date: 15 Aug 84 14:18 PDT
8509: From: [email protected]
8510: Subject: Re: (atom VECTOR): franz vs liszt
8511: In-Reply-To: Alan Bawden <[email protected]>'s message of 13 Aug 84 20:08
8512: EDT
8513: To: [email protected]
8514: Cc: [email protected], [email protected], franz-friends@BERKELEY,
8515: [email protected]
8516:
8517: [Ah, confusion with Interlisp here].
8518:
8519: I meant to say "The resolution was some awful switch setting for whether
8520: or not to treat them as LISTs" rather than "to treat them as ATOMs".
8521: The switch name is HUNKP.
8522:
8523: Interlisp's ATOM predicate is defined simply as (NOT (LISTP x)), and
8524: LISTP is true only of cons cells [thus (LISTP NIL) is false].
8525:
8526: -- JonL --
8527:
8528:
8529:
8530: From [email protected] Wed Aug 15 18:21:08 1984
8531: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8532: id AA02292; Wed, 15 Aug 84 18:21:08 pdt
8533: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8534: id AA09647; Wed, 15 Aug 84 18:21:57 pdt
8535: Message-Id: <[email protected]>
8536: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT
8537: Date: 15 Aug 84 18:18 PDT
8538: From: [email protected]
8539: Subject: Re: bug in assoc
8540: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29
8541: EDT
8542: To: "smh@mit-ems"@MIT-MC.ARPA
8543: Cc: "mcgeer@ucbkim"@BERKELEY, franz-friends@BERKELEY,
8544: "[email protected]@udel-relay"@MIT-MC.ARPA, [email protected]
8545:
8546: Common Lisp also faces the possibility of inconsistent system code due
8547: to the handling of cases marked "is an error" (see Manual, sec. 1.2.4);
8548: that is, it is undefined as to what happens if you apply CAR to a
8549: non-LISTP. All portable system code should therefore certify the type
8550: of a datum before taking car or cdr. ASSOC (and ASSQ) from the Franz
8551: sources clearly doesn't check the type of the arguments before carcdring
8552: away on them.
8553:
8554: Well, why not "all system code should certify the type before taking
8555: car/cdr . . . " -- it certainly can't hurt to "signal an error" rather
8556: than fall into some undefined morass.
8557:
8558: -- JonL --
8559:
8560:
8561: From [email protected] Wed Aug 15 19:49:22 1984
8562: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8563: id AA02844; Wed, 15 Aug 84 19:49:22 pdt
8564: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8565: id AA10989; Wed, 15 Aug 84 19:50:13 pdt
8566: Message-Id: <[email protected]>
8567: Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 19:48:41 PDT
8568: Date: 15 Aug 84 15:00 PDT
8569: From: [email protected]
8570: Subject: Re: (atom VECTOR): franz vs liszt
8571: In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 08:40:00
8572: EDT
8573: To: "smh@mit-ems"@MIT-MC.ARPA
8574: Cc: [email protected], [email protected], [email protected],
8575: franz-friends@BERKELEY
8576:
8577: MacLisp indeed does have VECTORs, STRINGs, CLASSes, etc. in an extended
8578: SmallTalk-like hierarchy, but they are not in the initial system. Some
8579: of these used to have autoload properties, but I'm not sure about the
8580: state of things now. None of the extended stuff got documented in the
8581: 1983 MacLisp manual, mostly because of Pitman's personal preferences for
8582: not using the extended stuff.
8583:
8584: HUNKs are relevant, because the extended heirarchy uses the USRHUNK
8585: feature in order to cause system functions to "trap out" on hunks,
8586: thereby viewing them in an object-oriented way rather than as lists
8587: (Glaaaag!) or as mere simple vectors.
8588:
8589: -- JonL --
8590:
8591:
8592:
8593: From MLY@MIT-MC Wed Aug 15 22:49:17 1984
8594: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8595: id AA04730; Wed, 15 Aug 84 22:49:17 pdt
8596: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8597: id AA13406; Wed, 15 Aug 84 22:49:59 pdt
8598: Message-Id: <[email protected]>
8599: Date: 16 August 1984 01:49-EDT
8600: From: Richard Mlynarik <MLY@MIT-MC>
8601: Subject: on the issue of the "ATOMness" of hunks
8602: To: PSZ@MIT-MC
8603: Cc: ALAN@MIT-MC, GSB@MIT-MC, JonL.pa@XEROX, franz-friends@BERKELEY,
8604: smh@MIT-EMS
8605: In-Reply-To: Msg of 14 Aug 1984 16:37-EDT from Peter Szolovits <PSZ>
8606:
8607: From: Peter Szolovits <PSZ>
8608:
8609: I have a small quarrel with Alan Bawden's statement that "hunks never
8610: being atoms in Maclisp" is a universally-agreed bug. There are indeed
8611: useful structures that one would like to build in Lisp that act as CONS
8612: cells (i.e., CAR and CDR are applicable), but that can have further
8613: structure. I have sorely missed such objects in Lisp Machine Lisp and
8614: NIL, where flavor-instances are always atomic, when I wanted to build
8615: Brand X (interned "list structure" and universal property lists). In
8616: Maclisp, I could do this using hunks, though even that was not
8617: completely right because I wanted to be able to disallow RPLACA and
8618: RPLACD while allowing CAR and CDR, and this was hard, given the hunk
8619: abstraction. I would, however, love to have non-atomic flavor-instances
8620:
8621: The MIT lisp machine system makes some attempt to "support" this sort
8622: of thing, by sending :CAR, :CDR, etc messages to instances. The result
8623: is that you get an error about an unclaimed message, rather than one
8624: about an attempt to take the car of a non-nil atom. LISTP and CONSP
8625: both still return NIL when applied to an instance. The way to get RPLACA
8626: (or SETF of CAR), etc to not work is simply to not define methods for doing
8627: these operations...
8628:
8629: Is is not really clear to me what the value of such is, unless you get tired
8630: of typing too many "(SEND"'s.
8631:
8632:
8633: From goldfarb%[email protected] Fri Aug 17 16:44:40 1984
8634: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8635: id AA00202; Fri, 17 Aug 84 16:44:40 pdt
8636: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8637: id AA01032; Fri, 17 Aug 84 16:45:24 pdt
8638: Received: From ucf.csnet by csnet-relay; 17 Aug 84 19:26 EDT
8639: Received: by ucf-cs.UUCP (4.12/4.7)
8640: id AA00852; Fri, 17 Aug 84 15:29:05 edt
8641: Date: Fri, 17 Aug 84 15:29:05 edt
8642: From: Ben Goldfarb <goldfarb%[email protected]>
8643: Message-Id: <[email protected]>
8644: To: franz-friends@BERKELEY
8645: Subject: ChangeLog
8646:
8647: The ReadMe file in /usr/src/cmd/ucb/lisp states that there are ChangeLog
8648: files in the subdirectories franz and liszt. We got no such files on
8649: our distribution tape (Berkeley 4.2bsd). I'd appreciate receiving copies
8650: of these files, along with any other documentation of differences between
8651: the 4.2 version and prior versions of Franz Lisp.
8652:
8653: Thanks,
8654:
8655: Ben Goldfarb
8656: University of Central Florida
8657: uucp: {duke,decvax,princeton}!ucf-cs!goldfarb
8658: ARPA: [email protected]
8659: csnet: goldfarb@ucf
8660:
8661: From [email protected] Sun Aug 26 20:48:24 1984
8662: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8663: id AA11969; Sun, 26 Aug 84 20:48:24 pdt
8664: Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8665: id AA18166; Sun, 26 Aug 84 20:46:52 pdt
8666: Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
8667: id AA16455; Sun, 26 Aug 84 23:48:12 edt
8668: Date: Sun, 26 Aug 84 23:45:55 edt
8669: From: [email protected] (Mark Bromley)
8670: Message-Id: <[email protected]>
8671: Received: by CORNELL-GVAX.ARPA (4.30/4.30)
8672: id AA14288; Sun, 26 Aug 84 23:45:55 edt
8673: To: [email protected]
8674: Subject: Bug in open coding of vseti in Liszt 8.36
8675:
8676:
8677: If (vseti vector index expression) gets open coded by the compiler,
8678: the resulting value is the value of index, not the value of expression.
8679: This also holds for vseti-byte and vseti-word.
8680:
8681: The problem is in d_vset in vector.l. The code which builds the return
8682: value for immediate vectors assumes that the value of expression is in
8683: index-reg, but it never gets put there.
8684:
8685: One solution would be to change the lines
8686:
8687: (if g-loc
8688: then (if (eq type 'byte)
8689:
8690: (occuring about 3/4 of the way through d_vset) to
8691: (if g-loc
8692: then (setq temp (cadr (assq type '((byte cvtbl)
8693: (word cvtwl)
8694: (long movl)))))
8695: (e-write3 temp vect-val index-reg)
8696:
8697: (if (eq type 'byte)
8698:
8699: Mark Bromley
8700: bromley@cornell
8701:
8702:
8703: From forwarder@UWVAX Mon Aug 27 14:25:15 1984
8704: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8705: id AA19881; Mon, 27 Aug 84 14:25:15 pdt
8706: Received: from wisc-rsch.arpa (wisc-rsch.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8707: id AA05251; Mon, 27 Aug 84 14:23:30 pdt
8708: Date: Mon, 27 Aug 84 16:26:07 cdt
8709: Message-Id: <[email protected]>
8710: Received: by wisc-rsch.arpa; Mon, 27 Aug 84 16:26:07 cdt
8711: To: franz-friends@BERKELEY
8712: Subject: FRANZ to VI and back
8713: Cc: [email protected]
8714: Sender: forwarder@UWVAX
8715: From: [email protected]
8716:
8717: Escuse me if this is a simple question, but i am a Unix novice.
8718: What is the best way to go between VI & Franz when debugging a
8719: program? The way I currently do it is to ctrl-Z out of Franz,
8720: FG to my VI process, correct my code, FG back to FRANZ, load the
8721: corrected code. Is there a better way (do not tell me about
8722: Emacs because that is not an option)?
8723: -thanks, david
8724:
8725: From rad@mitre-bedford Mon Aug 27 14:52:55 1984
8726: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8727: id AA20435; Mon, 27 Aug 84 14:52:55 pdt
8728: Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8729: id AA05840; Mon, 27 Aug 84 14:51:11 pdt
8730: Message-Id: <[email protected]>
8731: Date: Monday, 27 Aug 1984 17:45-EDT
8732: From: rad@Mitre-Bedford
8733: To: [email protected]
8734: Cc: franz-friends@BERKELEY, [email protected]
8735: Subject: Re: FRANZ to VI and back
8736: In-Reply-To: Your message of Monday, 27 Aug 1984 17:26-EDT.
8737: <[email protected]>
8738:
8739:
8740: >>Escuse me if this is a simple question, but i am a Unix novice.
8741: >>What is the best way to go between VI & Franz when debugging a
8742: >>program? The way I currently do it is to ctrl-Z out of Franz,
8743: >>FG to my VI process, correct my code, FG back to FRANZ, load the
8744: >>corrected code. Is there a better way (do not tell me about
8745: >>Emacs because that is not an option)?
8746:
8747: It's undocumented in the franz opus 37 manual, but may be in the opus
8748: 38: In franz, type (vi foo) and lisp will spin up vi. If it can't
8749: find the file foo, it tries for foo.l before creating a new file. If
8750: you invoke it as (vil foo), it will load foo back in after you exit
8751: from vi. There are similar functions called ex and exl.
8752:
8753: If you're using BSD4.2, you probably have opus 38. A new book is out
8754: called Lispcraft. It is based on franz, opus 38 in particular. You
8755: might want to pick that up. The old standby, Lisp, by Winston and
8756: Horn, documented Maclisp which is close to franz. Their new, 2nd
8757: edition is based on Common Lisp, however, which is different, so watch
8758: out!
8759:
8760: If you don't like ex or vi (say you're an ed-masochist), there are hooks
8761: for other editors. Put the following in the .lisprc file in your home
8762: directory:
8763:
8764: (def ed (nlambda (x)
8765: (exvi 'ed x nil)))
8766: (def edl (nlambda (x)
8767: (exvi 'ed x t)))
8768:
8769: These will give you the same function as ex/vi and exl/vil except
8770: using ed. These functions are found in /usr/lib/lisp/auxfns0.l (opus
8771: 37, anyway).
8772:
8773: Dick Dramstad
8774: rad@mitre-bedford
8775:
8776:
8777: From liz@maryland Tue Aug 28 10:17:28 1984
8778: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8779: id AA28395; Tue, 28 Aug 84 10:17:28 pdt
8780: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8781: id AA24861; Tue, 28 Aug 84 10:15:46 pdt
8782: Received: by maryland.ARPA (4.12/4.7)
8783: id AA20274; Tue, 28 Aug 84 10:59:06 edt
8784: Date: Tue, 28 Aug 84 10:59:06 edt
8785: From: liz@maryland (Liz Allen)
8786: Message-Id: <[email protected]>
8787: To: [email protected], rad@Mitre-Bedford
8788: Subject: Re: FRANZ to VI and back
8789: Cc: franz-friends@BERKELEY
8790:
8791: One feature of our vi functions is to ask (after returning from vi)
8792: whether or not you want to load the file. This gives you the freedom
8793: to decide later when you know if you modified the file. To implement
8794: this, you could change the last line of exvi from:
8795:
8796: (cond (doload (load edit_file)))
8797:
8798: to:
8799:
8800: (cond ((or doload (query "Load " edit_file "? "))
8801: (load edit_file)))
8802:
8803: and define query:
8804:
8805: (defmacro (&rest prompt)
8806: `(progn (msg ,@prompt) (yesp (read))))
8807:
8808: (or something like that). Exvi is defined in common1.l.
8809:
8810: Enjoy!
8811:
8812: -Liz
8813:
8814: PS You could also send me mail asking about getting our software!
8815:
8816:
8817: From @MIT-MC:[email protected] Wed Aug 29 08:09:14 1984
8818: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8819: id AA09035; Wed, 29 Aug 84 08:09:14 pdt
8820: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8821: id AA15198; Wed, 29 Aug 84 08:09:05 pdt
8822: Message-Id: <[email protected]>
8823: Date: 29 Aug 1984 11:06:09-EDT
8824: From: Ingemar.Hulthage@CMU-RI-ISL2
8825: Subject: Vector algebra
8826: Apparently-To: <franz-friends@UCB-VAX>
8827:
8828:
8829: I am writing a package of functions for vector algebra in arbitrary (finite)
8830: dimensions and it occured to me that I ought to post a message to find
8831: out if something like this is alredy available.
8832:
8833: I am looking forward to the replies
8834:
8835:
8836: From @MIT-MC:[email protected] Fri Aug 31 10:16:03 1984
8837: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8838: id AA04497; Fri, 31 Aug 84 10:16:03 pdt
8839: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8840: id AA03527; Fri, 31 Aug 84 10:15:41 pdt
8841: Message-Id: <[email protected]>
8842: Date: 31 Aug 1984 13:15:27-EDT
8843: From: Ingemar.Hulthage@CMU-RI-ISL2
8844: Subject: matrix inversion
8845: Apparently-To: <franz-friends@UCB-VAX>
8846:
8847:
8848: I need to numerically invert matrices of varying sizes and I would
8849: appreciate pointers to any lisp functions that can do that.
8850:
8851:
8852: From mccune@aids-unix Fri Aug 31 10:42:29 1984
8853: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8854: id AA05060; Fri, 31 Aug 84 10:42:29 pdt
8855: Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8856: id AA04133; Fri, 31 Aug 84 10:41:52 pdt
8857: Message-Id: <[email protected]>
8858: Date: 31 Aug 84 10:40:13 PDT (Fri)
8859: From: Brian McCune <mccune@aids-unix>
8860: Subject: Mailing list
8861: To: franz-friends@BERKELEY
8862:
8863: Please remove my name from franz-friends. Thanks.
8864:
8865: Brian McCune
8866: MCCUNE@AIDS-UNIX
8867:
8868: From ucsbcsl!dave@engrvax Tue Sep 4 11:22:20 1984
8869: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8870: id AA10583; Tue, 4 Sep 84 11:22:20 pdt
8871: Received: by UCB-VAX.ARPA (4.24/4.33)
8872: id AA26490; Tue, 4 Sep 84 11:22:10 pdt
8873: From: ucsbcsl!dave@engrvax
8874: Received: from engrvax.UCSB (engrvax.ARPA) by ucsbcsl.UCSB (4.12/3.14.ucsb)
8875: id AA27209; Tue, 4 Sep 84 10:55:08 pdt
8876: Date: Tue, 4 Sep 84 10:55:52 pdt
8877: Message-Id: <[email protected]>
8878: Received: by engrvax.UCSB (4.12/3.14.ucsb)
8879: id AA20764; Tue, 4 Sep 84 10:55:52 pdt
8880: To: franz-friends@BERKELEY
8881: Subject: I have moved.
8882:
8883: Please change my mailing address to be 'ucsbcsl!chi!dave' from 'ucsbcsl!dave'.
8884: Thanks.
8885:
8886: From liz@maryland Wed Sep 5 08:34:45 1984
8887: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
8888: id AA19892; Wed, 5 Sep 84 08:34:45 pdt
8889: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33)
8890: id AA14415; Wed, 5 Sep 84 08:34:27 pdt
8891: Received: by maryland.ARPA (4.12/4.7)
8892: id AA09320; Wed, 5 Sep 84 11:33:56 edt
8893: Date: Wed, 5 Sep 84 11:33:56 edt
8894: From: liz@maryland (Liz Allen)
8895: Message-Id: <[email protected]>
8896: To: franz-friends@BERKELEY
8897: Subject: Maryland software
8898:
8899: I'm mailing the announcement here again since a few things have
8900: changed since I last sent it out here and I have had requests for
8901: it. Currently, we are completing the 4.2 switchover and will
8902: (hopefully) be starting to distribute it by the end of September.
8903:
8904: -Liz Allen
8905:
8906: -----------------------------------------------------------------
8907:
8908: Greetings:
8909:
8910:
8911: This is to announce the availability of the Univ of Maryland
8912: software distribution. This includes source code for the follow-
8913: ing packages which are currently running on a VAX 11/780 under
8914: Berkeley UNIX(tm) 4.1:
8915:
8916: (1) The flavors package written in Franz Lisp. This package has
8917: been used successfully in a number of large systems at Mary-
8918: land, and while it does not implement all the features of
8919: Lisp Machine Flavors, the features present are as close to
8920: the Lisp Machine version as possible within the constraints
8921: of Franz Lisp. (Note that Maryland flavors code *can* be
8922: compiled.)
8923:
8924: (2) Other Maryland Franz hacks including the INTERLISP-like top
8925: level, the lispbreak error handling package, the for macro
8926: and the new loader package.
8927:
8928: (3) The YAPS production system written in Franz Lisp. This is
8929: similar to OPS5 but more flexible in the kinds of lisp
8930: expressions that may appear as facts and patterns (sublists
8931: are allowed and flavor objects are treated atomically), the
8932: variety of tests that may appear in the left hand sides of
8933: rules and the kinds of actions may appear in the right hand
8934: sides of rules. In addition, YAPS allows multiple data
8935: bases which are flavor objects and may be sent messages such
8936: as "fact" and "goal".
8937:
8938: (4) The windows package in the form of a C loadable library.
8939: This flexible package allows convenient management of multi-
8940: ple contexts on the screen and runs on ordinary character
8941: display terminals as well as bit-mapped displays. Included
8942: is a Franz lisp interface to the window library, a window
8943: shell for executing shell processes in windows, and a menu
8944: package (also a C loadable library).
8945:
8946: (5) The phone program. This is a facility to allow two or more
8947: users to type messages to each other in separate windows on
8948: a tty screen. It uses the Maryland window package and CMU's
8949: IPC facility.
8950:
8951: (6) The calend program, an appointment calendar maintainer. It
8952: uses a user file of reminding messages and dates for remind-
8953: ing, and can notify a user by messages printed to his termi-
8954: nal, sending them mail, or nagging them to get off the ter-
8955: minal at a certain time of day. It allows one-time only,
8956: weekly, biweekly, monthly, yearly and other similar methods
8957: for being reminded.
8958:
8959: (7) The bbd program, a multiple bulletin board system loosely
8960: based on the 'msgs' program. It accepts character-oriented
8961: commands and allows user-definable bulletin-boards.
8962:
8963: (8) Rzasm, a relocating Z80 cross-assembler. Running on the vax
8964: it puts out ld-style object files. Its features include,
8965: among others: free-form input; (very) long variable/label
8966: names; conditional assembly; macros (in 'm4' format); digit
8967: labels; global, external, common and local common declara-
8968: tions; data and text segments; support of the "undocumented"
8969: Z80 instructions (that work on high and low bytes of the
8970: index registers separately); expressions using C syntax; and
8971: string constants.
8972:
8973: (9) Zrun, a z80 microprocessor simulator. Zrun simulates the
8974: execution of a z80 with 64k RAM, as directed by user com-
8975: mands. In addition to the essential commands that cause an
8976: rzasm object program to be loaded and executed, there are
8977: commands to examine and set registers, flags, and memory
8978: locations, to set a breakpoint, to single-step through a
8979: program, to re-direct the flow of data through the z80
8980: ports, etc.
8981:
8982: The distribution currently runs under Berkeley Unix 4.1, but we
8983: will be upgrading to 4.2 in early July and the upgrade should be
8984: ready for distribution in September. At that time, we will begin
8985: to put both the 4.1 and 4.2 sources on the distribution tape. If
8986: you are running 4.2 or plan to be running 4.2 in the near future,
8987: it is probably worth your while to wait for it. Also at that
8988: time, the fee for the distribution will go up from $100 to $250.
8989:
8990: We also include Franz Lisp in the distribution since it is
8991: easier to do that than to describe all the small changes that we
8992: have made to the Franz sources. For the 4.1 distribution, we
8993: send Franz Opus 38.26. For the 4.2 distribution, we do not yet
8994: know which Franz we will be mailing, but it will be whichever we
8995: get with our 4.2 Berkeley Unix.
8996:
8997:
8998: How to obtain a tape:
8999:
9000: To obtain the Univ of Maryland distribution tape:
9001:
9002: (1) Fill in the form below and sign it. Please indicate whether
9003: you want just the 4.1 distribution, both the 4.1 and 4.2
9004: distributions or if you will be obtaining the distribution
9005: via a third party or via the Arpanet.
9006:
9007: (2) Make out a check to "University of Maryland Foundation" for
9008: $100 (US dollars) or for $250 (US dollars) if you want the
9009: 4.2 distribution. Mail the check and form to:
9010:
9011: Liz Allen
9012: Univ of Maryland
9013: Dept of Computer Science
9014: College Park MD 20742
9015:
9016:
9017: (3) If you need an invoice, send me mail. Don't forget to
9018: include your non-electronic mailing address.
9019:
9020: Upon receipt of the money, we will mail you a tape containing our
9021: software and the technical reports describing the software. We
9022: will also keep you informed of bug fixes via electronic mail. We
9023: have an electronic mailing address for this kind of thing. It
9024: is:
9025:
9026: Usenet: ...!seismo!umcp-cs!um-software
9027: Arpanet: um-software@maryland
9028:
9029: Please note that bug fixes will be done only insofar they are
9030: consistent with the research purposes of the University of Mary-
9031: land.
9032:
9033: If you have any technical questions, etc, send mail to the
9034: above mailing list. If you have any administrative questions,
9035: contact Diane Miller via electronic mail:
9036:
9037: Usenet: ...!seismo!umcp-cs!despina
9038: Arpanet: despina@maryland
9039:
9040: or via phone at (301) 454-4251.
9041:
9042:
9043: Liz Allen
9044:
9045: Usenet: ...!seismo!umcp-cs!liz
9046: Arpanet: liz@maryland
9047:
9048: -----------------------------------------------------------------
9049:
9050: In exchange for the Maryland software tape, I certify to the fol-
9051: lowing:
9052:
9053: a. I will not use any of the Maryland software distribution in
9054: a commercial product without obtaining permission from Mary-
9055: land first.
9056:
9057: b. I will keep the Maryland copyright notices in the source
9058: code, and acknowledge the source of the software in any use
9059: I make of it.
9060:
9061: c. I will not redistribute this software to anyone without per-
9062: mission from Maryland first.
9063:
9064: d. I will keep Maryland informed of any bug fixes.
9065:
9066: e. I understand that the software I will be receiving has been
9067: developed for research purposes only and may be good for
9068: absolutely nothing. The University of Maryland offers no
9069: warranties of any kind. Bug fixes will be done only insofar
9070: they are consistent with the research purposes of the
9071: University of Maryland.
9072:
9073: f. I am the appropriate person at my site who can make the
9074: guarantees in parts a through e.
9075:
9076: g. I would like the package indicated below:
9077:
9078:
9079: ___ 4.1 distribution only. I have enclosed a check for
9080: $100.
9081:
9082:
9083: ___ 4.1 and 4.2 distribution. I have enclosed a check for
9084: $250. I also understand that the 4.2 distribution is
9085: not yet ready and that there will be a delay until at
9086: least August or September before my tape arrives.
9087:
9088: ___ License and technical reports only. I have enclosed a
9089: check for $100 and will obtain the distribution from a
9090: site that already has the distribtution or will get it
9091: from Maryland via the Arpanet. (Please note specifics
9092: at the bottom of the form.)
9093:
9094:
9095:
9096:
9097: Signature: ______________________________
9098:
9099: Name: ______________________________
9100:
9101: Position: ______________________________
9102:
9103: Company or Organization: ______________________________
9104:
9105: Address: ______________________________
9106:
9107: ______________________________
9108:
9109: Phone number: ______________________________
9110:
9111: Electronic mail address: ______________________________
9112:
9113:
9114: From [email protected] Wed Sep 5 16:11:17 1984
9115: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9116: id AA25823; Wed, 5 Sep 84 16:11:17 pdt
9117: Received: from CORNELL.ARPA (cornell-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33)
9118: id AA21315; Wed, 5 Sep 84 16:10:58 pdt
9119: Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
9120: id AA15943; Wed, 5 Sep 84 19:11:13 edt
9121: Date: Wed, 5 Sep 84 19:06:27 edt
9122: From: [email protected] (Mark Bromley)
9123: Message-Id: <[email protected]>
9124: Received: by CORNELL-GVAX.ARPA (4.30/4.30)
9125: id AA19770; Wed, 5 Sep 84 19:06:27 edt
9126: To: franz-friends@BERKELEY
9127: Subject: Bug in open coding of vseti in Liszt 8.36
9128:
9129: There is a mistake in the open coding of (vseti vector index expression).
9130: When the generated code is executed it returns the value of the index expression
9131: and not the value of expression. The problem is in d_vset in liszt/vector.l.
9132: The code in d_vset that generates the assembler code to compute the
9133: return value assumes that code has been generated to put the value of
9134: expression in index-reg. This assumption is false.
9135:
9136: I don't know the 68000 well enough to suggest a solution for it, but the
9137: following should work for the VAX. Change the lines
9138:
9139: (if g-loc
9140: then (if (eq type 'byte)
9141:
9142: (occuring about 3/4 of the way through d_vset) to
9143:
9144: (if g-loc
9145: then
9146: #+for-vax
9147: (progn
9148: (setq temp (cadr (assq type '((byte cvtbl)
9149: (word cvtwl)
9150: (long movl)))))
9151: (e-write3 temp vect-val index-reg)
9152: )
9153:
9154: #+for-68k
9155: (comment Do the same thing for the 68k)
9156:
9157: (if (eq type 'byte)
9158:
9159: Also, what is the current Berkeley distribution policy. I tried ftp'ing
9160: from ucbvax, but the pub/lisp directory there is empty. I'd like to get my
9161: hands on a distribution that has the flavors package in it.
9162:
9163: Mark Bromley
9164: bromley@cornell
9165:
9166:
9167:
9168:
9169: From jkf@ucbmike Tue Oct 30 12:19:45 1984
9170: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9171: id AA02909; Tue, 30 Oct 84 12:19:45 pst
9172: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31)
9173: id AA23363; Tue, 30 Oct 84 11:43:13 pst
9174: Received: by ucbmike.arpa (4.24ucb/4.33)
9175: id AA04265; Tue, 30 Oct 84 12:43:39 pst
9176: Date: Tue, 30 Oct 84 12:43:39 pst
9177: From: John Foderaro (on a sun) <jkf@ucbmike>
9178: Message-Id: <[email protected]>
9179: To: mrose%[email protected], franz-friends@BERKELEY
9180: Subject: Re: Where is franz-friends-request
9181: In-Reply-To: Your message of 28 Oct 84 10:04:05 EST (Sun)
9182:
9183: franz-friends-request@berkeley is valid. occasionlly the mailer tries
9184: to look in the alias table while it is being updated.
9185:
9186:
9187:
9188: From liz@tove Tue Oct 30 13:18:32 1984
9189: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9190: id AA03406; Tue, 30 Oct 84 13:18:32 pst
9191: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9192: id AA24224; Tue, 30 Oct 84 12:15:01 pst
9193: Received: by tove.ARPA (4.12/4.7)
9194: id AA09504; Thu, 25 Oct 84 16:46:39 edt
9195: From: Liz Allen <liz@tove>
9196: Message-Id: <[email protected]>
9197: Date: 25 Oct 1984 1646-EDT (Thursday)
9198: To: Rene Bach <BACH@su-score>
9199: Cc: franz-friends@BERKELEY
9200: Subject: Re: A question
9201: In-Reply-To: Your message of Thu 25 Oct 84 09:31:09-PDT.
9202: <[email protected]>
9203:
9204: From: Rene Bach <BACH%[email protected]>
9205:
9206: I am new on this list and haven't seen any other messages.
9207:
9208: There isn't too much mail here.
9209:
9210: Is there a way to find out what are all the atoms which
9211: have been defined in Franz (a la mapatoms of INterlisp) ??
9212:
9213: The functions (oblist) returns a list of all the atoms.
9214:
9215: -Liz
9216:
9217: From neves%[email protected] Tue Oct 30 14:38:15 1984
9218: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9219: id AA04963; Tue, 30 Oct 84 14:38:15 pst
9220: Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9221: id AA27563; Tue, 30 Oct 84 14:36:12 pst
9222: Received: from wisc-ai.uwisc by wisc-crys.arpa; Tue, 30 Oct 84 16:35:00 cst
9223: Date: Tue, 30 Oct 84 16:34:59 cst
9224: From: neves%[email protected] (David Neves)
9225: Message-Id: <[email protected]>
9226: Received: by wisc-ai.uwisc; Tue, 30 Oct 84 16:34:59 cst
9227: To: franz-friends@BERKELEY
9228: Subject: vi/franz question
9229:
9230: This is a vi/franz question.
9231: I would like to use "=" in VI to indent my lisp code. When I
9232: type "=" in front of some lisp code I get
9233: No alternate filename to substitute for #0
9234: How do I indent Lisp code (besides using autoindent)?
9235: -Thanks, David
9236:
9237: From Johnson%[email protected] Wed Oct 31 05:54:58 1984
9238: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9239: id AA04156; Wed, 31 Oct 84 05:54:58 pst
9240: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9241: id AA07029; Wed, 31 Oct 84 05:52:24 pst
9242: Message-Id: <[email protected]>
9243: Received: From udel-dewey.ARPA by udel-relay.ARPA id a018834 ;31 Oct 84 8:55 EST
9244: Date: Wed, 31 Oct 84 8:47:19 EST
9245: From: johnson <johnson%[email protected]>
9246: To: franz-friends@BERKELEY
9247: Cc: johnson%[email protected]
9248: Subject: response to lisp/vi question
9249:
9250:
9251: in response to:
9252:
9253: >I would like to use "=" in VI to indent my lisp code. When I
9254: >type "=" in front of some lisp code I get
9255: >No alternate filename to substitute for #0
9256: >How do I indent Lisp code (besides using autoindent)?
9257:
9258: 1. When I type "=" in vi (without :set lisp) I get no response at all.
9259: Is it possible that you defined a macro named "=" ?
9260: {
9261: check your ~/.exrc file for a line beginning:
9262: :map = <something-or-other>
9263: }
9264:
9265: 2. Even after:
9266: :set lisp
9267:
9268: A single "=" does not seem to cause the correct action, however,
9269: two successive "="s do.
9270:
9271: to summarize:
9272: 1. remove any mapping of "=" from ~/.exrc
9273: 2. :set lisp
9274: 3. use "==" rather than "="
9275:
9276: - johnson@udel-ee
9277:
9278:
9279: From raf%[email protected] Wed Oct 31 11:35:57 1984
9280: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9281: id AA07802; Wed, 31 Oct 84 11:35:57 pst
9282: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9283: id AA13682; Wed, 31 Oct 84 11:33:13 pst
9284: Received: from bostonu by csnet-relay.csnet id ac00303; 31 Oct 84 14:27 EST
9285: Received: by csvaxa.ARPA (4.12/4.7)
9286: id AA14678; Wed, 31 Oct 84 13:53:18 est
9287: Date: Wed, 31 Oct 84 13:53:18 est
9288: From: Rafail Ostrovsky <raf%[email protected]>
9289: Message-Id: <[email protected]>
9290: To: FRANZ-FRIENDS%[email protected]
9291: Subject: MAILING LIST
9292:
9293: Hello.
9294: I would like to subscribe to your mailing list.
9295: I am a grad. student at Boston U. My address is:
9296:
9297: raf%[email protected]
9298:
9299: Thank you, -Raf
9300:
9301: From neves%[email protected] Wed Oct 31 12:40:33 1984
9302: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9303: id AA09034; Wed, 31 Oct 84 12:40:33 pst
9304: Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9305: id AA15180; Wed, 31 Oct 84 12:37:38 pst
9306: Received: from wisc-ai.uwisc by wisc-crys.arpa; Wed, 31 Oct 84 14:35:47 cst
9307: Date: Wed, 31 Oct 84 14:35:55 cst
9308: From: neves%[email protected] (David Neves)
9309: Message-Id: <[email protected]>
9310: Received: by wisc-ai.uwisc; Wed, 31 Oct 84 14:35:55 cst
9311: To: franz-friends@BERKELEY
9312: Subject: re: Indenting lisp code in VI
9313:
9314: Thanks for the response on indenting for Franz. It seems as though
9315: our systems people do not use Lisp and so have set up everyone's
9316: .exrc file to map = to something else. Your site might be doing the
9317: same thing to this or other VI/Lisp features! Stop them now.
9318:
9319: From @MIT-MC:[email protected] Wed Oct 31 17:37:36 1984
9320: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9321: id AA14939; Wed, 31 Oct 84 17:37:36 pst
9322: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9323: id AA02960; Wed, 31 Oct 84 17:14:37 pst
9324: Message-Id: <[email protected]>
9325: Date: 31 Oct 84 20:08:41 EST
9326: From: Ingemar.Hulthage@CMU-RI-ISL2
9327: Subject: Floating point division
9328: To: BBoard.Maintainer@CMU-CS-A
9329:
9330:
9331: Is there a pre-defined function in Franz Lisp that never uses integer
9332: division when it differs from floating point division ? Obviously it is easy
9333: to write (quotient (float a) b) or to write a function/macro with the same
9334: effect. However, since Franz does a good job of dealing with different kinds
9335: of numbers in other cases, it is inconvenient and inefficient if such a
9336: function is not available in the system.
9337:
9338:
9339: From eng20201%[email protected] Thu Nov 1 16:02:58 1984
9340: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9341: id AA05698; Thu, 1 Nov 84 16:02:58 pst
9342: Received: from WISCVM.ARPA (wiscvm.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9343: id AA08850; Thu, 1 Nov 84 16:00:19 pst
9344: Message-Id: <[email protected]>
9345: Received: from [email protected] by WISCVM.ARPA on 11/01/84 at
9346: 18:00:40 CST
9347: Date: 1-Nov-84 18:58:53 EST
9348: From: John Sutter <eng20201%[email protected]>
9349: Subject: Pretty typer
9350: To: franz-friends@BERKELEY
9351: Cc: eng20201%[email protected]
9352:
9353: -----
9354:
9355: Does anyone know of a pretty typer for Franz Lisp?..
9356:
9357: If you do, please reply to me directly.
9358:
9359: Thanks
9360:
9361: ---- John
9362:
9363: -----
9364:
9365: From holtz%carleton.cdn%[email protected] Sun Nov 4 14:39:06 1984
9366: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9367: id AA03203; Sun, 4 Nov 84 14:39:06 pst
9368: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9369: id AA04466; Sun, 4 Nov 84 14:36:25 pst
9370: Received: from ubc by csnet-relay.csnet id a004399; 4 Nov 84 15:43 EST
9371: Date: Sun, 4 Nov 84 12:37:03 pst
9372: Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
9373: From: Neal Holtz <holtz%carleton.cdn%[email protected]>
9374: To: franz-friends%[email protected]
9375: Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA
9376: Message-Id: 133:[email protected]
9377: Subject: Franz on Apollos (or, Fritz Kunze, where are you?)
9378:
9379: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
9380: for that matter) can tell me anything about the possibility of
9381: having Franz run on Apollo workstations (under AEGIS) in the
9382: near future, I would be most appreciative.
9383:
9384:
9385: From holtz%carleton.cdn%[email protected] Sun Nov 4 14:39:20 1984
9386: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9387: id AA03212; Sun, 4 Nov 84 14:39:20 pst
9388: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9389: id AA04473; Sun, 4 Nov 84 14:36:37 pst
9390: Received: from ubc by csnet-relay.csnet id a004408; 4 Nov 84 15:45 EST
9391: Date: Sun, 4 Nov 84 12:37:03 pst
9392: Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst
9393: From: Neal Holtz <holtz%carleton.cdn%[email protected]>
9394: To: franz-friends%[email protected]
9395: Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA
9396: Message-Id: 133:[email protected]
9397: Subject: Franz on Apollos (or, Fritz Kunze, where are you?)
9398:
9399: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
9400: for that matter) can tell me anything about the possibility of
9401: having Franz run on Apollo workstations (under AEGIS) in the
9402: near future, I would be most appreciative.
9403:
9404:
9405: From fkunze%ucbopal.CC%[email protected] Sun Nov 4 23:25:12 1984
9406: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9407: id AA03125; Sun, 4 Nov 84 23:25:12 pst
9408: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9409: id AA04781; Sun, 4 Nov 84 23:22:27 pst
9410: Received: from ucb-vax.arpa by csnet-relay.arpa id a006482; 5 Nov 84 2:21 EST
9411: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9412: id AA04236; Sun, 4 Nov 84 22:58:35 pst
9413: Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
9414: by ucbjade.CC.Berkeley.ARPA (4.17/4.27.2)
9415: id AA14292; Sun, 4 Nov 84 22:59:18 pst
9416: Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28)
9417: id AA03601; Sun, 4 Nov 84 22:59:26 pst
9418: Date: Sun, 4 Nov 84 22:59:26 pst
9419: From: Fritz Kunze <fkunze%ucbopal.CC%[email protected]>
9420: Message-Id: <[email protected]>
9421: To: franz-friends%ucb-vax.arpa%[email protected],
9422: holtz%carleton.cdn%ubc.csnet%[email protected]
9423: Subject: Re: Franz on Apollos (or, Fritz Kunze, where are you?)
9424:
9425: We are working on an Apollo port right now. Due to some
9426: non-standard features in the Apollo operating system,
9427: the port is requiring far more time than we originally
9428: anticipated. We are very close to a working interpreter,
9429: but the compiler will require more time. Are you interested
9430: in the Interpreter first?
9431: ---Fritz Kunze
9432: Franz Inc.
9433: 2920 Domingo, suite 203
9434: Berkeley, CA 94705
9435: (415) 540-1224
9436:
9437:
9438:
9439: From abrams@mitre Mon Nov 5 11:41:38 1984
9440: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9441: id AA08762; Mon, 5 Nov 84 11:41:38 pst
9442: Received: from mitre (mitre.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9443: id AA06184; Mon, 5 Nov 84 11:38:18 pst
9444: Message-Id: <[email protected]>
9445: Date: 5 Nov 1984 14:17:36 EST (Monday)
9446: From: Marshall Abrams <abrams@mitre>
9447: Subject: Call for papers: Expert Systems Symposium
9448: To: add1:@mitre
9449: Cc: abrams@mitre
9450:
9451: Call for Papers
9452:
9453: Expert Systems in Government Conference
9454:
9455: October 23-25, 1985
9456:
9457: THE CONFERENCE objective is to allow the developers and implementers
9458: of expert systems in goverenment agencies to exchange information and
9459: ideas first hand for the purpose of improving the quality of
9460: existing and future expert systems in the government sector.
9461: Artificial Intelligence (AI) has recently been maturing so rapidly
9462: that interest in each of its various facets, e.g., robotics, vision,
9463: natural language, supercomputing, and expert systems, has acquired
9464: an increasing following and cadre of practitioners.
9465:
9466: PAPERS are solicited which discuss the subject of the conference.
9467: Original research, analysis and approaches for defining expert
9468: systems issues and problems such as those identified in the
9469: anticipated session topics, methodological approaches for analyzing
9470: the scope and nature of expert system issues, and potential
9471: solutions are of particular interest. Completed papers are to be no
9472: longer than 20 pages including graphics and are due 1 May 1985.
9473: Four copies of papers are to be sent to:
9474:
9475: Dr. Kamal Karna, Program Chairman
9476: MITRE Corporation W852
9477: 1820 Dolley Madison Boulevard
9478: McLean, Virginia 22102
9479: Phone (703) 883-5866
9480: ARPANET: Karna @ Mitre
9481:
9482: Notification of acceptance and manuscript preparation instructions
9483: will be provided by 20 May 1985.
9484:
9485: THE CONFERENCE is sponsored by the IEEE Computer Society and The
9486: MITRE Corporation in cooperation with The Association for Computing
9487: Machinery, The american Association for Artificial Intelligence and
9488: The American Institute of Aeronautics and Astronautics National
9489: Capital Section. This conference will offer high quality technical
9490: exchange and published proceedings.
9491:
9492: It will be held at Tyson's Westpark Hotel, Tysons Corner, McLean,
9493: VA, suburban Washington, D.C.
9494:
9495:
9496: TOPICS OF INTEREST
9497:
9498: The topics of interest include the expert systems in the following
9499: applications domains (but are not limited to):
9500:
9501: 1. Professional: Accounting, Consulting, Engineering,
9502: Finance, Instruction, Law, Marketing,
9503: Management, Medicine
9504: Systems, Intelligent DBMS
9505:
9506: 2. Office Automation: Text Understanding, Intelligent
9507:
9508: 3. Command & Control: Intelligence Analysis, Planning,
9509: Targeting, Communications, Air Traffic
9510: Control
9511:
9512: 4. Exploration: Space, Prospecting, Mineral, Oil
9513:
9514: Archeology
9515:
9516: 5. Weapon Systems: Adaptive Control, Electronic Warfare,
9517: Star Wars, Target Identification
9518:
9519: 6. System Engineering: Requirements, Preliminary Design,
9520: Critical Design, Testing, and QA
9521:
9522: 7. Equipment: Design Monitoring, Control, Diagnosis,
9523: Maintenance, Repair, Instruction
9524:
9525: 8. Project Management: Planning, Scheduling, Control
9526:
9527: 9. Flexible Automation: Factory and Plan Automation
9528:
9529: 10. Software: Automatic Programming, Specifications,
9530: Design, Production, Maintenance and
9531: Verification and Validation
9532:
9533: 11. Architecture: Single, Multiple, Distributed Problem
9534: Solving Tools
9535:
9536: 12. Imagery: Photo Interpretation, Mapping, etc.
9537:
9538: 13. Education: Concept Formation, Tutoring, Testing,
9539: Diagnosis, Learning
9540:
9541: 14. Entertainment and Intelligent Games, Investment and
9542: Expert Advice Giving: Finances, Retirement, Purchasing,
9543: Shopping, Intelligent Information
9544: Retrieval
9545:
9546:
9547:
9548: From decvax!utzoo!dciem!nrcaero!clan.carleton!holtz Mon Nov 5 17:32:56 1984
9549: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9550: id AA14064; Mon, 5 Nov 84 17:32:56 pst
9551: Received: by UCB-VAX.ARPA (4.24/4.39)
9552: id AA14362; Mon, 5 Nov 84 17:30:11 pst
9553: Return-Path: <decvax!utzoo!dciem!nrcaero!clan.carleton!holtz>
9554: Received: by decvax.UUCP (4.12/1.0)
9555: id AA28321; Mon, 5 Nov 84 16:46:11 est
9556: Date: Sun, 4 Nov 84 21:23:59 est
9557: From: Neal Holtz <decvax!carleton!clan.carleton!holtz@clan.>
9558: Message-Id: <8411050223.AA07104@clan. UUCP>
9559: Received: by clan. UUCP (4.12/3.14)
9560: id AA07104; Sun, 4 Nov 84 21:23:59 est
9561: To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends
9562: Subject: Franz on Apollos (or -- Fritz Kunze, where are you?)
9563:
9564: Sorry to send this to the newsgroup, but if Fritz (or anyone else,
9565: for that matter) can tell me anything about the possibility of
9566: having Franz run on Apollo workstations (under AEGIS) in the
9567: near future, I would be most appreciative.
9568:
9569:
9570:
9571:
9572:
9573:
9574:
9575: From [email protected] Tue Nov 6 16:15:33 1984
9576: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9577: id AA25403; Tue, 6 Nov 84 16:15:33 pst
9578: Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9579: id AA06061; Tue, 6 Nov 84 16:12:18 pst
9580: Message-Id: <[email protected]>
9581: Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 122057; Tue 6-Nov-84 19:13:41-EST
9582: Date: Tue, 6 Nov 84 19:11 EST
9583: From: Richard Brenner <[email protected]>
9584: Subject: Job Opportunities
9585: To: maple-sys@BERKELEY, symalg%rand-unix.arpa%[email protected],
9586: franz-friends@BERKELEY
9587: In-Reply-To: The message of 6 Nov 84 15:51-EST from Richard Pavelle <RP at SCRC-TENEX>
9588:
9589:
9590: Symbolics, Inc. of Cambridge is the acknowledged leader in the field of
9591: Symbolic Processing, offering the premier LISP-based Symbolic Processor
9592: for advanced problem-solving applications. We are a fast-growing,
9593: high-tech company with new, modern facilities right in Cambridge. Recent
9594: expansion has created opportunities for the following experienced
9595: professionals:
9596:
9597:
9598: Member of Technical Staff
9599:
9600: You will assist with maintenance and enhancement of MACSYMA, a large
9601: Computer Algebra System written in LISP and used by engineers and
9602: scientists for performing symbolic computations. Immediate projects
9603: could include design and implementation of tools for conversion to
9604: Common LISP, improving modularity, modernizing the user interface,
9605: improving performance, and design and implementation of new mathematical
9606: packages based on the latest available algorithms. Work will be
9607: performed on all versions of MACSYMA using Symbolics 3600 Family Lisp
9608: Machines. A strong background in mathematics and Lisp programming is
9609: preferred. Experience with MACSYMA is desirable.
9610:
9611:
9612: Technical Sales Support Engineer
9613:
9614: You will provide technical support to our internal sales staff, to
9615: customers and to prospective customers. Responsibilities include
9616: assistance at demonstration sites, installations on several kinds of
9617: machines, and a full range of customer support activities. This could
9618: include design, development and delivery of a trainging course for
9619: MACSYMA users. Qualified applicants will have experience with a
9620: high-level language, preferably MACSYMA. Good written and verbal
9621: communication skills and prior software project involvement are desired.
9622: B.S. degree or equivalent and 2 years experience preferred.
9623:
9624:
9625: Qualified candidates should send their resume,in strict confidence,
9626: including salary history, to Gina Setteducati, Personnel Supervisor,
9627: Symbolics, Inc., 11 Cambridge Center, Cambridge, MA 02142. An equal
9628: opportunity employer.
9629:
9630:
9631: From [email protected] Wed Nov 7 19:52:19 1984
9632: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9633: id AA08630; Wed, 7 Nov 84 19:52:19 pst
9634: Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9635: id AA05368; Wed, 7 Nov 84 18:51:47 pst
9636: Received: by uw-beaver.arpa (4.12/2.2)
9637: id AA00936; Wed, 7 Nov 84 17:50:03 pst
9638: Return-Path: <ssc-vax!steve>
9639: Received: by ssc-vax (4.12/4.7)
9640: id AA06915; Wed, 7 Nov 84 17:24:40 pst
9641: Date: Wed, 7 Nov 84 17:24:40 pst
9642: From: [email protected] (Steve White)
9643: Message-Id: <8411080124.AA06915@ssc-vax>
9644: To: uw-beaver!franz-friends@BERKELEY
9645: Subject: readtable within fasl
9646:
9647:
9648: In "fasl.c" before the literals are read back out of the object file,
9649: the readtable is rebound to the 'standard-readtable'. This short-circuits
9650: any type of character macro expansion. Does anyone known a workaround
9651: for this? In NIL you can specify the readtable associated with the object
9652: code, I guess I'm wondering how to mimic this behavior in franz?
9653: thanks
9654: steve white
9655: (ssc-vax!steve@uw-beaver)
9656:
9657: From @MIT-MC:smh@MIT-EDDIE Thu Nov 8 07:49:13 1984
9658: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9659: id AA12925; Thu, 8 Nov 84 07:49:13 pst
9660: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9661: id AA17112; Thu, 8 Nov 84 07:46:31 pst
9662: Message-Id: <[email protected]>
9663: Received: by mit-eddie.Mit-chaos.Arpa id AA20888; Thu, 8 Nov 84 10:33:41 est
9664: Date: Thu, 8 Nov 84 10:33:41 est
9665: From: Steven M. Haflich <smh@mit-eddie>
9666: To: franz-friends@BERKELEY
9667: Subject: Re: readtable within fasl
9668:
9669: I too was bothered by fasl's insistence on using the standard readtable
9670: to process literals in liszt-compiled files until I realized the reason
9671: for this limitation:
9672:
9673: All source input to liszt is processed by `read' -- that is, the
9674: compiler reads only forms, never ascii strings. In order to place a
9675: literal form in an object file, liszt must essentially convert the form
9676: back into ASCII via `print'. (Actually, a somewhat modified version
9677: which knows how to wrap an assembler `.asciz' directive around the
9678: printed representation of the form, etc.) Unfortunately, liszt can make
9679: no easy assumption about what strange readtable is likely to be active
9680: at load time, so the only sane choice is to use the standard readtable.
9681:
9682: In other words, you shouldn't think of literal forms stored in a fasl
9683: object file as external (ASCII) representation of lisp data. Rather,
9684: liszt/fasl use ASCII as a convenient "position-independent" encoding of
9685: a form which has already been processed by read at compile time. This
9686: is entirely analogous to what traditional compilers and assemblers do
9687: with numeric constants represented in ASCII inside a program, except
9688: their compiler-to-loader data format uses the native binary number
9689: representation of the object machine.
9690:
9691: One could argue that this isn't really a limitation provided one is
9692: willing and able to provide the desired readtable at compile time.
9693: Usually this isn't a problem, although I once I had a macro which wanted
9694: to insert into a form a particular uninterned symbol which (obviously)
9695: couldn't even exist until execution time. I was forced to wrap the form
9696: inside another function which would accomplish the substitution at load
9697: time.
9698:
9699: There is no reason liszt could not be made to copy ASCII forms into the
9700: fasl file without read->print translation, but this would require
9701: changes to the compiler and to fasl format, things not to be done
9702: lightly. If you *really* need the facility, and don't need to read huge
9703: volumes of data, you could include ASCII forms inside a fasl file by
9704: encoding them as lisp strings, and seeing that they get processed by an
9705: appropriate function at load time, something like:
9706:
9707: (defun strange-read (str)
9708: (let ((readtable strange-readtable))
9709: (readlist (explodec str))))
9710:
9711: Then you can do things like:
9712: (setq foo (strange-read ") a b )c d( e (")
9713:
9714: [What? You don't like my readtable with the parens reversed?] The
9715: invocation of `strange-read' can, of course, be conveniently macrofied.
9716: If appropriate, automatic printing of literal strings can also be
9717: performed by compile time macros. You will have to deal with the
9718: problem of escaping quotes inside these forms, and you might want to
9719: enable string garbage collection if you do a lot of this sort of thing.
9720:
9721: I know it's ugly, but...
9722:
9723: Steve Haflich
9724:
9725:
9726: From @MIT-MC:smh@MIT-EDDIE Thu Nov 8 12:17:02 1984
9727: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9728: id AA15294; Thu, 8 Nov 84 12:17:02 pst
9729: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9730: id AA22393; Thu, 8 Nov 84 11:59:13 pst
9731: Message-Id: <[email protected]>
9732: Received: by mit-eddie.Mit-chaos.Arpa id AA21531; Thu, 8 Nov 84 12:51:14 est
9733: Date: Thu, 8 Nov 84 12:51:14 est
9734: From: Steven M. Haflich <smh@mit-eddie>
9735: To: franz-friends@BERKELEY
9736: Subject: Re: Re: readtable within fasl
9737:
9738: There was a typo in my previous mailing. The function "explodec"
9739: should have been "exploden".
9740:
9741:
9742: From [email protected] Thu Nov 8 14:24:38 1984
9743: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9744: id AA16474; Thu, 8 Nov 84 14:24:38 pst
9745: Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9746: id AA25584; Thu, 8 Nov 84 14:22:00 pst
9747: Message-Id: <[email protected]>
9748: Date: Thu 8 Nov 84 14:21:16-PST
9749: From: Rene Bach <[email protected]>
9750: Subject: printing delayed in Eunice
9751: To: franz-friends@BERKELEY
9752: Cc: [email protected]
9753:
9754: It appears that printing gets delayed in Eunice. What I mean by that
9755: is that I have a print statement which should indicate that the system
9756: is progressing. However, the system is chugging along, nothing shows
9757: for a long while and then the printing happens ALL at ONCE ! As if the
9758: output was buffered and go printed when something else needed to be
9759: printed.
9760:
9761: As anyone run across this before ? Is there a flag one needs to set ?
9762:
9763: Has it to do with Eunice ? What I am printing is just an atom and a ", ".
9764: When I print longer stuff, no buffering is noticed.
9765:
9766: Thanks
9767: Rene
9768: -------
9769:
9770: From [email protected] Thu Nov 8 16:34:36 1984
9771: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9772: id AA17894; Thu, 8 Nov 84 16:34:36 pst
9773: Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31)
9774: id AA27172; Thu, 8 Nov 84 15:30:06 pst
9775: Message-Id: <[email protected]>
9776: Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 84 15:29:24 PST
9777: Date: 8 Nov 84 15:22 PST
9778: From: [email protected]
9779: Subject: Re: readtable within fasl
9780: In-Reply-To: Steven M. Haflich <[email protected]>'s message of Thu, 8
9781: Nov 84 10:33:41 est
9782: To: [email protected]
9783: Cc: franz-friends@BERKELEY
9784:
9785: The problems with a user-tailorable READ is one of the reasons why, over
9786: 12 years ago, we chose a format for MacLisp's FASL files that is
9787: somewhat akin to a position-independent list encoding. (But in fact, it
9788: was primarily for speed that the READ-oriented option was abandoned).
9789:
9790: However, there was still the need to introduce load-time evaluation, in
9791: order to create structures that can't be known even faintly at compile
9792: time; there is an "internal" marker, accessible to the MacLisp user as a
9793: global variable (named SQUID, I believe), so that the portions of a
9794: structure that need to be eval'd at load time could be marked. E.g.
9795: (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE))))
9796: and the #, signals a spot for load-time evaluation, even though the
9797: overall structure is essentally a QUOTE form.
9798:
9799: One needn't imagine that #, is the only client of this "internal" marker
9800: -- it provides the way to get all but the trivial datatypes into
9801: quotified structures; for example, I may have an input syntax for
9802: arrays, but still PRINT won't put them out (MacLisp PRINT won't, at
9803: least), and certainly not every conceivable datatype needs a special
9804: encoding for the FASL file format; merely a LIST, which is viewed as a
9805: general program by EVAL, is satisfactory to create any createable
9806: datatype instance.
9807:
9808: Interlisp too has a loadtime evaluation construct, but it may only
9809: replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such
9810: as indicated by the #, above. A primary reason for this limitation is
9811: the similarity of Interlisp's and Franz's compiler output formats --
9812: basically an ascii string to which READ is applied. MacLisp's loader
9813: is indeed quite more complex, but it results in a space savings for the
9814: FASL files and a considerable time savings when loading them.
9815:
9816: -- Jon L White --
9817:
9818:
9819:
9820: From @MIT-MC:[email protected] Fri Nov 9 12:09:40 1984
9821: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9822: id AA26238; Fri, 9 Nov 84 12:09:40 pst
9823: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9824: id AA04311; Fri, 9 Nov 84 12:06:51 pst
9825: Message-Id: <[email protected]>
9826: Date: 9 Nov 84 14:02:29 EST
9827: From: Nancy.Skooglund@CMU-RI-ISL3
9828: Subject: opening file for output, append
9829: To: BBoard.Maintainer@CMU-CS-A
9830:
9831: Does anyone know how to open a file for output in Franz lisp and
9832: @i(append) to that file? The function "outfile" always deletes the old
9833: version first.
9834:
9835: Thanks,
9836: Nancy Skooglund
9837:
9838:
9839: From @MIT-MC:[email protected] Sun Nov 11 11:57:03 1984
9840: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9841: id AA16052; Sun, 11 Nov 84 11:57:03 pst
9842: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9843: id AA15747; Sun, 11 Nov 84 11:54:17 pst
9844: Message-Id: <[email protected]>
9845: Date: 11 Nov 84 00:15:49 EST
9846: From: David.Yaskin@CMU-CS-H
9847: Subject: Franz Question
9848: To: BBoard.Maintainer@CMU-CS-A
9849:
9850:
9851: How does one change the depth and length of list returned from functions.
9852: While using CMULisp it keeps returning & instead of my list.
9853:
9854: David Yaskin ( day@h)
9855:
9856:
9857: From Johnson%[email protected] Sun Nov 11 19:11:37 1984
9858: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9859: id AA19376; Sun, 11 Nov 84 19:11:37 pst
9860: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9861: id AA21463; Sun, 11 Nov 84 19:08:46 pst
9862: Message-Id: <[email protected]>
9863: Received: From udel-dewey.ARPA by udel-relay.ARPA id a010044
9864: ;11 Nov 84 22:09 EST
9865: Date: Sun, 11 Nov 84 22:07:41 EST
9866: From: johnson <johnson%[email protected]>
9867: To: [email protected]
9868: Cc: franz-friends@BERKELEY, johnson%[email protected]
9869: Subject: Re: Franz Question
9870:
9871: -------------------- for franz -----------------------------
9872: In franz lisp, 'prinlevel' is a variable controlling the
9873: depth to which the top-level is to print lists, 'prinlength'
9874: controls how many elements of a list are printed by the
9875: top-level. For either variable, a value of 'nil' represents
9876: infinite depth or length.
9877:
9878: If franz is printing expressions as '&' then
9879: prinlevel has a value of 0.
9880:
9881: you should
9882: (setq prinlevel nil)
9883: to print lists of arbitrary depth.
9884: (see Appendix B of the Franz manual)
9885:
9886: ---------------- for CMU --------------------
9887:
9888: In CMULisp, tlprint does the top-level printing, and this is
9889: defined, (in, at least the 2 systems that I use) as:
9890:
9891: '(lambda (x) (printlev x 4))
9892:
9893: if your functions always return &, then perhaps someone has defined
9894: it as '(lambda (x) (printlev x 0))
9895:
9896: if you want to change it you may either:
9897: 1. (sstatus translink nil)
9898: (defun tlprint (x) (printlev x <some-large-number>))
9899:
9900: OR, the solution I prefer:
9901:
9902: 2. (load 'toplevel) ; unnecessary in some installations.
9903: (defun tlprint (x) (top-print x))
9904:
9905: causing 'prinlevel' and 'prinlength' to have
9906: the effect described above for the franz system.
9907:
9908: NB: the tempting solution:
9909: (defun tlprint (x) (printlev x prinlevel))
9910: FAILS in the case that prinlevel is nil
9911:
9912:
9913: -johnson@udel-ee
9914:
9915: From Johnson%[email protected] Sun Nov 11 19:31:52 1984
9916: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9917: id AA19491; Sun, 11 Nov 84 19:31:52 pst
9918: Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9919: id AA21770; Sun, 11 Nov 84 19:29:03 pst
9920: Message-Id: <[email protected]>
9921: Received: From udel-dewey.ARPA by udel-relay.ARPA id a010257
9922: ;11 Nov 84 22:29 EST
9923: Date: Sun, 11 Nov 84 22:21:49 EST
9924: From: johnson <johnson%[email protected]>
9925: To: [email protected]
9926: Cc: franz-friends@BERKELEY, johnson%[email protected]
9927: Subject: Re: opening file for output, append
9928:
9929: In later versions of franz, 'outfile' takes a second argument;
9930: to open a file for appending:
9931:
9932: (setq portname (outfile '<filename> 'a))
9933:
9934: {try:
9935: (help outfile)
9936: for a full description.}
9937:
9938: If this does not work on your version, I have a hack that associates a port
9939: with ANY open file descriptor, but it uses 4.x system calls, - so don't
9940: request it unless the you can't use the new 'outfile' function.
9941:
9942: -johnson@udel-ee
9943:
9944:
9945: From @MIT-MC:[email protected] Mon Nov 12 06:45:39 1984
9946: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9947: id AA22731; Mon, 12 Nov 84 06:45:39 pst
9948: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9949: id AA01316; Mon, 12 Nov 84 06:42:54 pst
9950: Message-Id: <[email protected]>
9951: Date: 12 Nov 84 09:34:14 EST
9952: From: Nancy.Skooglund@CMU-RI-ISL1
9953: Subject: append to file answer found
9954: To: BBoard.Maintainer@CMU-CS-A
9955:
9956: Thanks to all who responded to my Franz lisp question about opening a
9957: file for output and appending to it. Here's how it works:
9958:
9959: (outfile '<filename> 'a)
9960:
9961: 'a may be replaced by any symbol or string whose name begins with a.
9962:
9963: Nancy
9964:
9965:
9966: From [email protected] Tue Nov 13 04:26:24 1984
9967: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
9968: id AA04324; Tue, 13 Nov 84 04:26:24 pst
9969: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
9970: id AA20746; Tue, 13 Nov 84 04:25:59 pst
9971: Received: from wisdom.BITNET
9972: by ucbjade.CC.Berkeley.ARPA (4.17/4.27.5)
9973: id AA10274; Tue, 13 Nov 84 04:24:53 pst
9974: Received: by wisdom.BITNET (4.12/4.7)
9975: id AA01997; Tue, 13 Nov 84 11:29:45 -0200
9976: Date: Tue, 13 Nov 84 11:29:45 -0200
9977: From: [email protected] (Jacob Levy)
9978: Message-Id: <[email protected]>
9979: To: [email protected]
9980: Subject: Announcement of new Lisp for UN*X 4.x VAXen
9981:
9982: I don't know if this is the appropriate place for this announcement, but
9983: here goes anyway :-
9984:
9985:
9986: YLISP, a Coroutine-based Lisp System for VAXen.
9987: -=============================================-
9988:
9989: A friend of mine, Yitzhak Dimitrovski, and myself, wrote a Lisp
9990: system for UN*X 4.x systems on VAXen. It has the following features :-
9991:
9992: o - Coroutines and closures. The system uses these to implement
9993: the user-interface, single-stepping and error-handling. It's
9994: easy to write a scheduler and time-share YLISP between two or
9995: more user programs.
9996: o - Multiple-dimension arrays.
9997: o - Multiple name spaces (oblists) arranged in a tree hierarchy.
9998: This is similar to the Lisp Machine facility.
9999: o - Defstruct structure definition package.
10000: o - Flavors object-oriented programming tools.
10001: o - User-extensible evaluator (it is possible to (re)define the
10002: actions of 'eval', 'apply' and 'print' relative to all user-
10003: and pre-defined types).
10004: o - Integer arithmetic. No floating-point, sorry. don't think that
10005: that's really necessary, but *could* be hacked. No BIGNUMs
10006: either.
10007: o - Good user-interface with history, sophisticated error handling
10008: and function-call and variable-assignment tracing facilities.
10009: o - Extensive library of ported and user-contributed programs,such
10010: as a variant of the Interlisp structure editor, 'loop' macro,
10011: 'mlisp' Pascal-like embedded language, etc.
10012: o - Compiler that generates efficient native assembler code for
10013: the VAXen. The compiler is provided as a separate program,due
10014: to size considerations. The compiler is written entirely in
10015: Lisp, of course.
10016: o - Extensive online documentation, as well as a 400-page manual
10017: describing the whole system from a programmer's point of view.
10018:
10019: The system is named 'YLISP', and was written for 4.1 when we were
10020: students at the Hebrew University at Jerusalem. Since then, Yitzhak has
10021: left for the US and is currently a Ph.D. student in Prof. Schwartz's
10022: Supercomputer group at Courant. I have continued to develop the system on
10023: my own, and have ported it to UN*X 4.2.
10024:
10025: I am looking for a site that is willing to handle the distribution
10026: of this software from the US, by letting one FTP it from their computer.
10027: Alternatively, I am also willing to supply people with magtapes of YLISP,
10028: for the cost of the tape and handling charges (about 70$ a piece). If you
10029: are interested, please respond by electronic mail to one of the addresses
10030: given below. I will be ready to start distributing the system in two
10031: weeks' time.
10032:
10033: Rusty Red (AKA Jacob Levy)
10034:
10035: BITNET: jaakov@wisdom
10036: CSNET and ARPA: jaakov%[email protected]
10037: UUCP: (if all else fails..) ..!decvax!humus!wisdom!jaakov
10038:
10039:
10040:
10041:
10042: From [email protected] Tue Nov 13 06:20:04 1984
10043: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10044: id AA04848; Tue, 13 Nov 84 06:20:04 pst
10045: Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10046: id AA05430; Mon, 12 Nov 84 15:45:22 pst
10047: Received: by uw-beaver.arpa (4.12/2.2)
10048: id AA28549; Mon, 12 Nov 84 15:43:15 pst
10049: Return-Path: <[email protected]>
10050: Received: by ssc-vax (4.12/4.7)
10051: id AA03520; Mon, 12 Nov 84 09:58:10 pst
10052: Date: Mon, 12 Nov 84 09:58:10 pst
10053: From: [email protected] (Steve White)
10054: Message-Id: <8411121758.AA03520@ssc-vax>
10055: To: uw-beaver!JonL.pa@XEROX, uw-beaver!smh@mit-eddie
10056: Subject: Re: readtable within fasl
10057: Cc: uw-beaver!franz-friends@BERKELEY
10058:
10059: My problem was a bit simplier then the general case you mention. In MRS
10060: a 'variable' is really a reader-macro ($) that at read time assigns a special
10061: value to each variable-base-name. Basically it does a
10062: (set (implode `(|$| . ,(explodec name))) 'bl).
10063: for side-effects of marking the symbol as a variable. When compiling files
10064: containing MRS code the compiler would execute the call inside its environment,
10065: placing the *unbound* literals (as .asciz) in the object file to be READ
10066: in at load time... so MRS would get the symbols and treat them as symbols
10067: not variables.
10068:
10069: The only reason i mention this is that the workaround used might be useful
10070: for others seeking side effects within macros etc.
10071: My workaround (h.a.c.k) was to use a special variable
10072: liszt-eof-forms
10073: as a queue of the above SET forms and to provide a different macro expansion
10074: for compile-time. So
10075:
10076: (setsyntax '|$| 'macro
10077: #'(lambda nil (let ((varname (implode `(|$| ,@(explodec (read))))))
10078: (addq `(setq ,varname 'bl) liszt-eof-forms)
10079: varname))) ;; return variable name to liszt!
10080:
10081: [where ADDQ does the correct thing if the variable has already been seen],
10082: adds the following to the object file
10083: .asciz "$xyz"
10084: .asciz "(setq $xyz 'bl)"
10085: which basically works (don't gag!)
10086: steve white
10087:
10088: YAP -- (yet another problem) : does anyone at MIT have a list of fixes
10089: to franz 38.91 to make the zeta-lisp environment work :-) I started fixing
10090: a few things but it looks like something that might MIT may have already
10091: done. ((or any plans to put NIL under UNIX? 8-) ))
10092:
10093: From [email protected] Thu Nov 15 18:09:13 1984
10094: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10095: id AA12102; Thu, 15 Nov 84 18:09:13 pst
10096: Received: by UCB-VAX.ARPA (4.24/4.39)
10097: id AA11658; Thu, 15 Nov 84 18:09:11 pst
10098: Received: from ucscd.UCSC (ucscd.ARPA) by ucscc.UCSC (4.12/4.7)
10099: id AA23553; Thu, 15 Nov 84 10:48:02 pst
10100: Received: by ucscd.UCSC (4.12/4.7)
10101: id AA04900; Thu, 15 Nov 84 10:45:19 pst
10102: Date: Thu, 15 Nov 84 10:45:19 pst
10103: From: [email protected] (05550000)
10104: Message-Id: <[email protected]>
10105: To: [email protected]
10106: Subject: mailing list name change
10107:
10108:
10109: Please stop sending to
10110: ucscc!figgy
10111:
10112: instead add
10113: ucbvax!ucscc!lispers
10114:
10115: Thank you.
10116:
10117: From [email protected] Thu Nov 15 20:51:49 1984
10118: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10119: id AA13810; Thu, 15 Nov 84 20:51:49 pst
10120: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10121: id AA14507; Thu, 15 Nov 84 20:51:52 pst
10122: Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
10123: by ucbjade.CC.Berkeley.ARPA (4.18/4.27.5)
10124: id AA01653; Thu, 15 Nov 84 20:51:05 pst
10125: Received: by ucbruby.CC.Berkeley.ARPA (4.18/4.27.6)
10126: id AA02961; Thu, 15 Nov 84 20:50:39 pst
10127: Date: Thu, 15 Nov 84 20:50:39 pst
10128: From: [email protected] (Harry Weeks)
10129: Message-Id: <[email protected]>
10130: To: franz-friends@BERKELEY
10131: Subject: Lisp implementation details.
10132:
10133: Are there any technical reports or memoranda available which
10134: describe the internal workings of Franz?
10135: -- Harry
10136:
10137: From @MIT-MC:[email protected] Wed Nov 28 11:32:50 1984
10138: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10139: id AA15208; Wed, 28 Nov 84 11:32:50 pst
10140: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10141: id AA14658; Wed, 28 Nov 84 11:32:04 pst
10142: Message-Id: <[email protected]>
10143: Date: 28 Nov 84 14:24:42 EST
10144: From: Timothy.Glavin@CMU-CS-CAD
10145: Subject: cmulisp docs
10146: To: BBoard.Maintainer@CMU-CS-A
10147:
10148: Does anyone know the location of on-line documentation for
10149: cmulisp. If not, is there a source for hard copy documentation?
10150: I have the Foderaro Franz Lisp Manual, I only looking for info
10151: on the CMU ideosyncracies.
10152: -- Tim (tg@cad)
10153:
10154:
10155: From smith@nrl-aic Fri Nov 30 09:17:53 1984
10156: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10157: id AA15087; Fri, 30 Nov 84 09:17:53 pst
10158: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10159: id AA24282; Fri, 30 Nov 84 09:15:33 pst
10160: Date: 30 Nov 1984 11:50-EST
10161: From: Russ Smith <[email protected]>
10162: Subject: bugs using flavors (and more)
10163: To: franz-friends@BERKELEY
10164: Message-Id: <470681409/smith@nrl-aic>
10165:
10166: I recently installed opus 38.91 on our VAX780 under 4.2BSD. The
10167: installation went smoothly. The files used for the installation appear
10168: to be the most recent available from ucbkim. This includes the flavors
10169: stuff with appropriate modifications (for example, fixing hash.l to use
10170: "vsize" instead of "getlength" on a vector). The flavors stuff I scarfed
10171: TODAY was dated October 2nd I believe. Anyway, I tried out some things
10172: with flavors and, in particular, with "describe"...with the
10173: following result (done with "script"):
10174: =============================================================================
10175: % lisp
10176: Franz Lisp, Opus 38.91
10177: -> (defflavor ob () () :settable-instance-variables)
10178: [autoload /usr/lib/lisp/flavors]
10179: [fasl /usr/lib/lisp/flavors.o]
10180: [fasl /usr/lib/lisp/machacks.o]
10181: [fasl /usr/lib/lisp/lmhacks.o]
10182: [fasl /usr/lib/lisp/flavorm.o]
10183: [fasl /usr/lib/lisp/vanilla.o]
10184: ob
10185: -> (describe 'ob)
10186: [autoload /usr/lib/lisp/describe]
10187: [fasl /usr/lib/lisp/describe.o]
10188:
10189: ob has property flavor: flavor[17]
10190: Error: Undefined function called from compiled code defstruct-description-name
10191: <1>: (exit)
10192: =============================================================================
10193: [Well, "defstruct-description-name" is used all over the
10194: "/usr/lib/lisp/struct.l" set of functions...apparently mostly with no
10195: arguments...which, I think, is wrong. One fix made by SMH to "describe.l"
10196: replaced a call on this macro with one with an argument. But that's NOT this
10197: problem anyway.]
10198:
10199: (1) Is there a known fix to get the "describe", or anything else that
10200: uses the "defstruct-description-name" macro, working correctly?
10201:
10202: (2) Could it be that some sort of extended "defflavor" would load in an
10203: appropriate file which on-the-fly defines this macro? That is,
10204: did I do TOO simple a "defflavor"? [For example, doing:
10205:
10206: (load '/usr/pub/lisp/struct.l)
10207:
10208: allows one to "(pp defstruct-description-name)" showing that
10209: it requires an argument...without the "load" it is undefined.]
10210:
10211: (3) Could the copy of the ftpable (???) opus38.91 files we have be out
10212: of date (seem to be from around June 84)?
10213:
10214: Any help would be much appreciated. We are attempting to develop
10215: some stuff for use on both an LMI Lisp Machine and the VAX. This has
10216: thrown the proverbial wrench into the work(s)...
10217:
10218: Russ <Smith@nrl-aic>
10219: Navy Center for Applied Research in Artificial Intelligence (whew!)
10220:
10221: From [email protected] Sat Dec 1 15:40:10 1984
10222: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10223: id AA04698; Sat, 1 Dec 84 15:40:10 pst
10224: Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10225: id AA03439; Sat, 1 Dec 84 14:28:56 pst
10226: Message-Id: <[email protected]>
10227: Date: 30 Nov 84 22:45:59 EST
10228: From: Sean McLinden <[email protected]>
10229: Subject: Re: bugs using flavors (and more)
10230: To: [email protected], franz-friends@BERKELEY
10231: Cc: [email protected]
10232: In-Reply-To: Message from "Russ Smith <[email protected]>" of 30 Nov 84 11:50:00 EST
10233:
10234:
10235: There is a bug in the way that describe is compiled according to the
10236: makefile. Basically the problem is that defstruct-description-name
10237: is a macro which is NOT compiled so that when you fasl the compiled
10238: version of struct (as you are compiling describe), you don't get
10239: the proper definition for defstruct-description-name.
10240:
10241: You can either 1). load struct.l when compiling describe.l or
10242: 2). (declare (macros t)) in struct.l and recompile.
10243:
10244: Sean McLinden
10245: Decision Systems Laboratory
10246: -------
10247:
10248: From sridhar%[email protected] Sat Dec 1 17:03:50 1984
10249: Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
10250: id AA06036; Sat, 1 Dec 84 16:55:15 pst
10251: Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.38)
10252: id AA08322; Sat, 1 Dec 84 16:50:50 pst
10253: Message-Id: <[email protected]>
10254: Received: from wsu by csnet-relay.csnet id a012949; 1 Dec 84 19:41 EST
10255: Date: Sat, 1 Dec 84 12:47 PST
10256: From: "S. Sridhar" <sridhar%[email protected]>
10257: To: [email protected]
10258: Cc: sridhar%[email protected]
10259: Subject: Documentation pblms.
10260:
10261: Hi,
10262: I am an ardent Franz hack here at Wash. St. Univ, Pullman.
10263: I need some specific info on Franz Lisp.
10264:
10265: There is no documentation on 'Structures' in the Franz Lisp manual, that
10266: we have here. (This is dated June 1983. The version we have is Opus 38.69,
10267: June 1983). Specifically I need documentaion on all the macros related to
10268: the use of structures like defstruct. I know for sure that these macros
10269: are available on our system, but I am having problems on their usage. The
10270: on-line documentation does not give any help either. Maybe you have an
10271: updated version of the Franz Lisp manual. Can you help around, please ?
10272:
10273: As another instance, functions relating to hashtables are available here
10274: but there is no documentation for it.
10275:
10276: Thanks.
10277:
10278: Sridhar
10279: ------
10280:
10281: From smith@nrl-aic Mon Dec 3 12:17:10 1984
10282: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10283: id AA04104; Mon, 3 Dec 84 12:17:10 pst
10284: Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10285: id AA16806; Mon, 3 Dec 84 12:14:27 pst
10286: Date: 3 Dec 1984 06:36-EST
10287: From: Russ Smith <[email protected]>
10288: Subject: followup to "flavors bugs (and more)"
10289: To: franz-friends@BERKELEY
10290: Message-Id: <470921820/smith@nrl-aic>
10291:
10292: This is a followup to a previous note I sent requesting help with fixing
10293: Opus 38.91 of Franz and Flavors running on a Vax780 under 4.2BSD.
10294:
10295: First, I want to thank the many people who had helpful suggestions on
10296: what may have been going wrong. Given the small amount of information I
10297: provided on the problem, some of them were remarkably relevant.
10298:
10299: The problem had to do with certain functions such as "describe" going
10300: south when invoked on a FLAVOR object. The solution was (at least) two
10301: fold. One, which I alluded to in the previous note, had to do with the
10302: distributed file "hash.l" containing invalid calls on the intrinsic
10303: "getlength" function with a vector argument. These calls had to be
10304: changed to "vsize" instead (actually "getlength" could probably have
10305: been redefined to allow vectors...). Whatever, that solved that part.
10306:
10307: The second solution had to do with how WE at NCARAI were installing
10308: Franz. We have a set of directories for "local" software into which
10309: we wanted to put the "new" Franz. As such, I went through all the
10310: "Makefile"s and changed default directories for such things as the
10311: libraries and objects, etc. While doing this, it was noted that certain
10312: files in the "lisplib" directory had hard-coded the default names for, for
10313: example, the library. Since our library was not in the same place as
10314: this default, these lines were "commented out" (with an "exit")...with
10315: the result that the Franz and Liszt installations did not go as smoothly
10316: as I thought. It turns out that these lines also should be changed to
10317: reflect the appropriate directory. They are in the files "buildlisp.l",
10318: "common1.l", and "fix.l" in the lisplib directory (possibly others exist as
10319: well). The pertinent lines read something like:
10320:
10321: (or (boundp 'default-library-directory)
10322: (setq default-library-directory '/usr/lib/lisp))
10323:
10324: During the installation (done on a CRT) I was doing something else. Thus
10325: when the mods made (namely changing the "setq" call above into an "exit")
10326: were invoked, I didn't notice later that a number of things which SHOULD have
10327: happened didn't (they'd gone off the screen...). Needless to say, this
10328: caused all sorts of bizarre inconsistencies (especially since our last
10329: installation DID use the default directories...).
10330:
10331: Anyway, notes for the future:
10332:
10333: (1) If ftp'ing Franz from ucbkim be sure to get the stuff in the
10334: "flavors" directory as well. This contains a new "hash.l"
10335: modified by SMH to use "vsize" rather than "getlength".
10336:
10337: (2) If not using the default directories for the installation,
10338: change the names in the above files as well to reflect the
10339: appropriate place(s)...sigh.
10340:
10341: Yours (with an apparently working Franz+flavors),
10342:
10343: Russ <Smith@nrl-aic>
10344: Navy Center for Applied Research in Artificial Intelligence (whew!)
10345:
10346: From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 12:49:49 1984
10347: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10348: id AA20917; Tue, 4 Dec 84 12:49:49 pst
10349: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10350: id AA24636; Tue, 4 Dec 84 12:13:23 pst
10351: Message-Id: <[email protected]>
10352: Received: by mit-eddie.Mit-chaos.Arpa id AA19371; Tue, 4 Dec 84 14:50:26 est
10353: Date: Tue, 4 Dec 84 14:50:26 est
10354: From: Steven M. Haflich <smh@mit-eddie>
10355: To: franz-friends@BERKELEY
10356: Subject: the *real* flavor sources (etc.)
10357:
10358: For some time I have been using and maintaining enhanced versions of the
10359: several Franz lisplib modules which implement various Lisp Machine
10360: compatibilities, most notably, the FLAVOR system and FORMAT output.
10361: jkf@berkeley has authorized me to announce public availability of these
10362: files via anonymous ftp from UCBKIM. These seven files are compatible
10363: with Opus 38.91, but supersede the versions in the 39.91 distribution.
10364: There are a number of bugfixes and new features.
10365:
10366: UCBKIM supports FTP with login "anonymous" and any password. The
10367: files are:
10368: ~anonymous/pub/flavors/Makefile
10369: flavors.l
10370: flavorm.l
10371: vanilla.l
10372: hash.l
10373: describe.l
10374: format.l
10375:
10376: The changes are too many to describe in detail. Many of the FLAVOR
10377: system changes are for compatibility with changes to Franz, although a
10378: few non-working or missing features (but not all) have been bludgeoned
10379: into functionality. In particular, wrappers work. The FORMAT module
10380: fixes a number of format directives which apparently never worked.
10381: However, some of the hairier ones are known still to be defective.
10382:
10383: This "completely unsupported" software is graciously being made
10384: available to all takers without any promises whatever: there is no
10385: promise of correctness, and no promise of support. Also, the sources
10386: total 160K and unsuitable for uucp distribution, and I don't have time
10387: to deal with tape requests [sorry].
10388:
10389: The above notwithstanding, I am as eager as anyone for additional
10390: improvements to the code. Anyone with additional bugfixes is encouraged
10391: to communicate to me, and I will try to integrate the code. I will try
10392: to respond to bug reports, but it may be a rather low priority business.
10393:
10394: Steve Haflich
10395: MIT Experimental Music Studio
10396: ARPA: smh@mit-eddie@mit-mc
10397: UUCP: {ihnp4, decvax!genrad}!mit-eddie!smh
10398:
10399:
10400: From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 19:32:49 1984
10401: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10402: id AA26327; Tue, 4 Dec 84 19:32:49 pst
10403: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10404: id AA26237; Tue, 4 Dec 84 13:26:17 pst
10405: Message-Id: <[email protected]>
10406: Received: by mit-eddie.Mit-chaos.Arpa id AA20260; Tue, 4 Dec 84 15:44:20 est
10407: Date: Tue, 4 Dec 84 15:44:20 est
10408: From: Steven M. Haflich <smh@mit-eddie>
10409: To: franz-friends@BERKELEY
10410: Subject: fix for describe.l
10411: Cc: MCLINDEN@RUTGERS@MIT-MC, smith@nrl-aic@mit-mc
10412:
10413: Previous postings have correctly identified the problem (which was fixed
10414: long ago in the versions announced today). The best fix is to change
10415: the (environment-lmlisp) invocation near the beginning of describe.l to
10416: read as follows, then recompile it:
10417:
10418: (environment-lmlisp (compile eval) (files struct flavorm))
10419:
10420: The struct and flavorm modules do not need to be around when the
10421: compiled describe code is executed, so omitting load from the eval-when
10422: saves some unnecessary fasl's. Describe, by the way, is useful even
10423: when flavors and defstructs are not being used. For instance, it will
10424: report the source module in which a compiled function lives.
10425:
10426: Steve Haflich
10427: smh@mit-eddie@mit-mc
10428: {ihnp4, decvax!genrad}!mit-eddie!smh
10429:
10430:
10431: From @MIT-MC:smh@MIT-EDDIE Tue Dec 4 22:49:05 1984
10432: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10433: id AA29026; Tue, 4 Dec 84 22:49:05 pst
10434: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10435: id AA05974; Tue, 4 Dec 84 20:50:44 pst
10436: Message-Id: <[email protected]>
10437: Received: by mit-eddie.Mit-chaos.Arpa id AA24308; Tue, 4 Dec 84 23:50:01 est
10438: Date: Tue, 4 Dec 84 23:50:01 est
10439: From: Steven M. Haflich <smh@mit-eddie>
10440: To: franz-friends@BERKELEY
10441: Subject: Franz documentation for MIT LM code
10442: Cc: sridhar%wsu.csnet@csnet-relay
10443:
10444: Sorry to report that there really is no official documentation for the
10445: several Franz lisplib modules which implement a measure of compatibility
10446: with Zetalisp, the dialect running on MIT Lisp Machines (and, more or
10447: less, on Symbolics and LMI machines). The Franz source code was adapted
10448: from the MIT Lisp machine code several years ago; there is still
10449: approximate compatibility, although new features and certain semantic
10450: subtleties have diverged. Driven partially by natural evolution and
10451: partially by the standardization efforts of Common Lisp, Lisp Machine
10452: compatibility is something of a moving target.
10453:
10454: But do not despair; there are two standardly available sources for
10455: documentation. Reading them will give a very usable idea about the
10456: packages. Unfortunately, a few unimplemented features and semantic
10457: differences will have to be discovered by experimentation or examination
10458: of the source code. (What do you want for free? :-)
10459:
10460: (1) If you have available a MIT Lisp Machine Manual, the sections on
10461: defstruct, flavors, format, hash, and loop output are still reasonable
10462: approximations of documentation for the Franz versions. Incidentally,
10463: the `Blue' MIT Lisp Machine Manual circa 1981 corresponds most closely
10464: with the Franz inplementation, although a few more recent features have
10465: been retrofitted. If available, Symbolics documentation is probably
10466: only very slightly less good -- the older, the better.
10467:
10468: (2) For defstruct, hash, and format the Guy Steele <Common Lisp: The
10469: Language>, published by Digital Press (a branch of DEC), is usefully
10470: close to the existing Franz code. Again, experimentation and
10471: examination of the source code will resolve the details. Unfortunately,
10472: Flavors and the loop macro are not (yet) part of the Common Lisp
10473: specification, and may well be very different when they are.
10474:
10475: Unofficially, there is another even better hope. The MIT Athena project
10476: will be `releasing' these packages into their standard Franz system this
10477: in another month or two. They are commencing a quick effort to edit
10478: Lisp Machine documentation into proper format for inclusion as
10479: appendixes in the Franz manual. If at all possible, I will attempt to
10480: get the results publically distributed. (Translation: My assistance is
10481: essential to this documentation, so I am in position to insist they be
10482: `reasonable' about it...) But no promises just yet.
10483:
10484: Steve Haflich
10485: MIT
10486:
10487:
10488: From [email protected] Thu Dec 6 13:53:03 1984
10489: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10490: id AA03880; Thu, 6 Dec 84 13:53:03 pst
10491: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10492: id AA27039; Thu, 6 Dec 84 11:43:13 pst
10493: Received: from CUNYVM.BITNET
10494: by ucbjade.CC.Berkeley.ARPA (4.19/4.30)
10495: id AA27252; Thu, 6 Dec 84 11:44:10 pst
10496: Message-Id: <[email protected]>
10497: Received: by CUNYVM id 8508; Thu, 06 Dec 84 14:41:26 EST
10498: Date: Thu, 6 Dec 84 14:39 EST
10499: From: Henry Nussbacher <[email protected]>
10500: To: <[email protected]>, <franz-friends@BERKELEY>,
10501: <ailist-request@sri-ai>, <[email protected]>,
10502: <[email protected]>, <[email protected]>
10503:
10504: Can you please register the following user to your lists:
10505: arpalist%cunyvm.BITNET
10506:
10507: Thank you,
10508: Henry Nussbacher
10509: BITNET Network Information Center
10510:
10511: From [email protected] Thu Dec 6 18:20:03 1984
10512: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10513: id AA07782; Thu, 6 Dec 84 18:20:03 pst
10514: Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10515: id AA05141; Thu, 6 Dec 84 17:55:14 pst
10516: Received: from thule by rice.ARPA (AA02673); Thu, 6 Dec 84 19:41:33 CST
10517: Received: by thule (AA02845); Thu, 6 Dec 84 19:38:53 cst
10518: Date: Thu, 6 Dec 84 19:38:53 cst
10519: From: Mike Caplinger <[email protected]>
10520: Message-Id: <8412070138.AA02845@thule>
10521: To: franz-friends@BERKELEY
10522: Subject: bug in 68k Opus 38.91 arrays
10523:
10524: In 68k Opus 38.91, the expression
10525: (array foo flonum-block 4 4)
10526: generates an "Error: IMPROPER USE OF SET".
10527:
10528: On the VAX, in Opus 38.79, this worked fine. What's happening?
10529:
10530: (I am on a Sun, compiled with sun_4_2.)
10531:
10532: - Mike
10533:
10534: From @MIT-MULTICS.ARPA:[email protected] Sat Dec 8 05:42:09 1984
10535: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10536: id AA25844; Sat, 8 Dec 84 05:42:09 pst
10537: Received: from MIT-MULTICS.ARPA (mit-multics.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10538: id AA22892; Sat, 8 Dec 84 05:39:47 pst
10539: Received: from VANDERBILT.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[email protected]>; 08 Dec 1984 08:36:56 est
10540: Date: 06 Dec 84 15:26 CDT
10541: From: David_Linn%[email protected]
10542: Reply-To: David_Linn%[email protected]
10543: To: "franz-friends"@BERKELEY
10544: Subject: FranzLISP on the S9000
10545: Message-Id: <30788@VUCCG1COM>
10546: In-Reply-To: <30731@VUCCG1COM>
10547:
10548: The AI Group at Vanderbilt would like to join the franz-friends
10549: mailing list. We have version 38.87 running on the IBM Inruments
10550: S9000 under CSOS 1.1, a very non-UNIX opsys. Both interpreter
10551: and compiler are working and a farily large general-purpose
10552: expert system tool set written on a VAX is up and running.
10553:
10554:
10555:
10556: From [email protected] Mon Dec 10 12:06:53 1984
10557: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10558: id AA18655; Mon, 10 Dec 84 12:06:53 pst
10559: Received: from USC-ECLC.ARPA (usc-eclc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10560: id AA04397; Mon, 10 Dec 84 12:04:27 pst
10561: Message-Id: <[email protected]>
10562: Date: Mon 10 Dec 84 12:03:06-PST
10563: From: [email protected]
10564: Subject: array - space
10565: To: franz-friends@BERKELEY
10566: Cc: [email protected]
10567:
10568:
10569: I am working with images stored as fixnum arrays (with delta =1 i.e. four
10570: pixels packed into a word) aux as unmarked arrays. (I am on a VAX under
10571: Eunice). How do I deallocate the array-space once I am done with it?
10572: (I use small-segment to allocate space for the array).
10573:
10574: Also I would appreciate any pointers of how to speed up programs with
10575: nested do loops (order of 512x512 x(5 x 5) itterations).
10576:
10577: Thanks,
10578:
10579: -Rakesh Mohan.
10580: -------
10581:
10582: From [email protected] Mon Dec 10 15:37:50 1984
10583: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10584: id AA20942; Mon, 10 Dec 84 15:37:50 pst
10585: Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10586: id AA08450; Mon, 10 Dec 84 15:35:12 pst
10587: Received: from iapetus by rice.ARPA (AA26746); Mon, 10 Dec 84 17:28:43 CST
10588: Received: by iapetus (AA16942); Mon, 10 Dec 84 17:29:45 CST
10589: Date: Mon, 10 Dec 84 17:29:45 CST
10590: From: Mike Caplinger <[email protected]>
10591: Message-Id: <8412102329.AA16942@iapetus>
10592: To: franz-friends@BERKELEY
10593: Subject: gensym and the compiler
10594:
10595: How does one get code like the following:
10596:
10597: ; construct an identity transformation matrix.
10598: (defun tm-new ()
10599: (let ((name (gensym)))
10600: (*array name 'flonum-block 4 4)
10601: (do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
10602: name)
10603: )
10604:
10605: to work under the compiler? Compiled, this refuses to believe
10606: in the existence of name.
10607:
10608: Do I need to declare it as a lambda? Is there a way to declare arrays?
10609:
10610: - Mike
10611:
10612: From jkf@ucbmike Mon Dec 10 16:03:40 1984
10613: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10614: id AA21396; Mon, 10 Dec 84 16:03:40 pst
10615: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
10616: id AA08955; Mon, 10 Dec 84 16:01:22 pst
10617: Received: by ucbmike.arpa (4.24ucb/4.33)
10618: id AA06150; Mon, 10 Dec 84 16:04:09 pst
10619: Date: Mon, 10 Dec 84 16:04:09 pst
10620: From: John Foderaro (on a sun) <jkf@ucbmike>
10621: Message-Id: <[email protected]>
10622: To: [email protected], franz-friends@BERKELEY
10623: Subject: Re: array - space
10624: Cc: [email protected]
10625: In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST
10626:
10627: You would be better off using immediate vectors (vectori) which
10628: are garbage collected. Items allocated with small-segment aren't
10629: gc'ed.
10630:
10631:
10632:
10633:
10634: From jkf@ucbmike Mon Dec 10 17:08:13 1984
10635: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10636: id AA22000; Mon, 10 Dec 84 17:08:13 pst
10637: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39)
10638: id AA10131; Mon, 10 Dec 84 17:05:36 pst
10639: Received: by ucbmike.arpa (4.24ucb/4.33)
10640: id AA06315; Mon, 10 Dec 84 17:08:19 pst
10641: Date: Mon, 10 Dec 84 17:08:19 pst
10642: From: John Foderaro (on a sun) <jkf@ucbmike>
10643: Message-Id: <[email protected]>
10644: To: [email protected], franz-friends@BERKELEY
10645: Subject: Re: array - space
10646: Cc: [email protected]
10647: In-Reply-To: Your message of Mon 10 Dec 84 12:03:06-PST
10648:
10649: One small correction: small-segment space is garbage collected and
10650: reclaimed, but only as individual elements: adjacent free elements are
10651: not combined. Vectors are different: adjacent free vectors are combined
10652: into larger vectors.
10653:
10654:
10655:
10656: From @MIT-MC:smh@MIT-EDDIE Mon Dec 10 19:02:52 1984
10657: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10658: id AA23540; Mon, 10 Dec 84 19:02:52 pst
10659: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39)
10660: id AA11754; Mon, 10 Dec 84 18:21:17 pst
10661: Message-Id: <[email protected]>
10662: Received: by mit-eddie.Mit-chaos.Arpa id AA03264; Mon, 10 Dec 84 21:20:04 est
10663: Date: Mon, 10 Dec 84 21:20:04 est
10664: From: Steven M. Haflich <smh@mit-eddie>
10665: To: franz-friends@BERKELEY
10666: Subject: re: gensym and the compiler
10667:
10668: <Mike@rice> wants to know how to make this function work:
10669:
10670: ; construct an identity transformation matrix.
10671: (defun tm-new ()
10672: (let ((name (gensym)))
10673: (*array name 'flonum-block 4 4)
10674: (do i 0 (1+ i) (= i 4) (store (name i i) 1.0))
10675: name)
10676: )
10677:
10678: The problem is that send is a macro (see lisplib/array.l), and at
10679: compile time it is impossible for it to determine exactly the "data
10680: type" of name. Therefore, it expands the function to:
10681:
10682: (defun tm-new ()
10683: (let ((name (gensym)))
10684: (*array name 'flonum-block 4 4)
10685: (do i 0 (1+ i) (= i 4) (name 1.0 i i))
10686: name)
10687: )
10688:
10689: Essentially, it just assumes 'name is a symbol which has an array in its
10690: function binding, or else which symevals (possibly recursively) to
10691: something that is either an array, or a symbol with an array in its
10692: function binding. When the compiler compiles the expansion, it assumes
10693: that it wants to call the function-binding of name, not the
10694: function-binding of symeval of name. In the interpreter it happens to
10695: work because eval of a list in the interpreter (but not the compiler) is
10696: defined to repetitively evaluate the car of the list until it finds a
10697: recognizable function or array. (See chapter 4.) But note!! If 'name
10698: also has a function binding, the interpreter will find it instead of the
10699: array!
10700:
10701: What you really want to do, then, is this:
10702:
10703: (defun tm-new ()
10704: (let ((name (gensym)))
10705: (*array name 'flonum-block 4 4)
10706: (do i 0 (1+ i) (= i 4) (funcall name 1.0 i i))
10707: name)
10708: )
10709:
10710: This guarantees that name gets symevaled once before the interpreter
10711: checks for function bindings, which also does the right thing in
10712: compiled code. Unfortunately, you will have to write this out by hand.
10713: I don't see any way that the send macro can be fixed. If it always
10714: returned the extra funcall, then this simple case wouldn't work
10715: compiled:
10716:
10717: (array foo ...)
10718: (store foo ...)
10719:
10720: Did anyone follow any of this?
10721:
10722:
10723: From [email protected] Tue Dec 11 20:05:09 1984
10724: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10725: id AA06334; Tue, 11 Dec 84 20:05:09 pst
10726: Received: from SUMEX-AIM.ARPA (sumex-aim.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10727: id AA15218; Tue, 11 Dec 84 20:03:46 pst
10728: Message-Id: <[email protected]>
10729: Date: Tue 11 Dec 84 20:04:16-PST
10730: From: Rene Bach <[email protected]>
10731: Subject: Porting FRANZ to other OS running C ?
10732: To: franz-friends@BERKELEY
10733:
10734: I am interested in finding out if someone has ported FRANZ to some
10735: other OS than UNIX. A friend of mine is interested in running a LISP
10736: under VMS at no cost. He has C on his machine.
10737: Is this feasible, how much work is involved ?
10738:
10739: What about porting FRANZ to some UNIX look alike ? How much work is
10740: involved ?
10741:
10742: Thanks for any leads
10743: Rene
10744: -------
10745:
10746: From [email protected] Tue Dec 11 20:44:19 1984
10747: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10748: id AA06672; Tue, 11 Dec 84 20:44:19 pst
10749: Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10750: id AA16044; Tue, 11 Dec 84 20:42:36 pst
10751: Message-Id: <[email protected]>
10752: Date: 11 Dec 84 23:41:49 EST
10753: From: Sean McLinden <[email protected]>
10754: Subject: Re: Franz documentation for MIT LM code
10755: To: smh%[email protected], franz-friends@BERKELEY
10756: Cc: sridhar%[email protected], [email protected]
10757: In-Reply-To: Message from "Steven M. Haflich <smh@mit-eddie>" of 4 Dec 84 23:50:01 EST
10758:
10759:
10760:
10761: Regarding the documentation for Franz Lisp and the MIT/Lisp Machine
10762: compatibility packages:
10763:
10764: Another option exists for those who might be interested. We at Decision
10765: Systems Lab have been using a modified version of Opus 38.89 which in-
10766: cludes the defstruct and flavors code already described. It also in-
10767: cludes an Interlisp compatibility package which allows Interlisp
10768: records as well as most of the CLISP forms (these are actually very
10769: easily simulated with LOOP but we chose a strategy which is more
10770: in keeping with the Interlisp implementation of CLISP involving
10771: hashed definitions for CLISP forms.
10772:
10773: The modified Lisp has all of the up-to-date flavors code and an
10774: edited version of the manual which describes the format, defstruct,
10775: and CLISP packages (borrowing heavily from the Laser edition of
10776: the Common Lisp manual by Guy Steele). It also includes a re-organization
10777: of much of the older manual into a more coherent form, and a number
10778: of examples of more difficult concepts.
10779:
10780: If there is any interest I can make this publicly available. It would
10781: be of little value to simply have the additional chapter since it
10782: refers, heavily, to material in other sections. Also, flavors is not,
10783: yet included, since the status of flavors in Franz was uncertain up
10784: to a few months ago.
10785:
10786: For those interested, I will not be prepared to answer requests before
10787: Christmas but after that I'll be around and can handle almost anything.
10788:
10789: Sean McLinden
10790: Decision Systems Laboratory
10791: University of Pittsburgh
10792:
10793: -------
10794:
10795: From @MIT-MC:ZZZ.RLK@MIT-OZ Wed Dec 12 21:51:39 1984
10796: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10797: id AA08208; Wed, 12 Dec 84 21:51:39 pst
10798: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10799: id AA07258; Wed, 12 Dec 84 21:03:56 pst
10800: Message-Id: <[email protected]>
10801: Date: Wednesday, 12 December 1984, 19:53-EST
10802: From: Robert L. Krawitz <ZZZ.RLK@MIT-OZ>
10803: Reply-To: rlk%mit-eecs at mit-mc.arpa
10804: To: franz-friends@BERKELEY
10805:
10806: Hi.
10807:
10808: I'm writing a term paper on the procedure call in various languages,
10809: perhaps on various languages on the VAX, perhaps just on the procedure
10810: call in various dialects of Lisp on the Vax.
10811:
10812: Could someone mail me some info on this subject (i. e. the calling
10813: conventions, how/if the Vax procedure call instructions are used, etc.)
10814: quickly, as this is the last week of classes and I don't want to take
10815: too long on this paper. Thanks.
10816:
10817: Robert^Z
10818:
10819: From psm@mitre-bedford Mon Dec 17 09:05:35 1984
10820: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10821: id AA20993; Mon, 17 Dec 84 09:05:35 pst
10822: Received: from mitre-bedford (mitre-bedford.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10823: id AA19421; Mon, 17 Dec 84 09:04:32 pst
10824: Message-Id: <[email protected]>
10825: Date: 17 Dec 1984 11:56:37-EST
10826: From: psm@Mitre-Bedford
10827: To: franz-friends@BERKELEY
10828: Subject: Please add me to your mailing list.
10829: Cc: psm@Mitre-Bedford
10830:
10831: Hi,
10832:
10833: Would you please add me to your mailing list/ user's group.
10834: (I hope this is the right place to make the request & it's not
10835: franz-friends-request or something like that. Sorry for the
10836: inconvenience if it is.)
10837:
10838: Peter Mager
10839: (psm@mitre-bedford)
10840:
10841: From jkf@ucbmike Mon Dec 17 13:01:48 1984
10842: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10843: id AA00901; Mon, 17 Dec 84 13:01:48 pst
10844: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
10845: id AA24456; Mon, 17 Dec 84 13:00:55 pst
10846: Received: by ucbmike.arpa (4.24ucb/4.33)
10847: id AA15009; Mon, 17 Dec 84 13:03:16 pst
10848: Date: Mon, 17 Dec 84 13:03:16 pst
10849: From: John Foderaro (on a sun) <jkf@ucbmike>
10850: Message-Id: <[email protected]>
10851: To: psm@Mitre-Bedford, franz-friends@BERKELEY
10852: Subject: Re: Please add me to your mailing list.
10853: Cc: psm@Mitre-Bedford
10854: In-Reply-To: Your message of 17 Dec 1984 11:56:37-EST
10855:
10856: I've added you to franz-friends.
10857:
10858:
10859:
10860: From jkf@ucbmike Mon Dec 17 13:06:53 1984
10861: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10862: id AA01005; Mon, 17 Dec 84 13:06:53 pst
10863: Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.40)
10864: id AA24568; Mon, 17 Dec 84 13:05:59 pst
10865: Received: by ucbmike.arpa (4.24ucb/4.33)
10866: id AA15044; Mon, 17 Dec 84 13:08:10 pst
10867: Date: Mon, 17 Dec 84 13:08:10 pst
10868: From: John Foderaro (on a sun) <jkf@ucbmike>
10869: Message-Id: <[email protected]>
10870: To: franz-friends@BERKELEY
10871: Subject: I'll be away
10872: Cc:
10873:
10874:
10875: For the new few weeks I'll be unable to handle franz-friends requests.
10876:
10877: Happy Holidays to all of you.
10878:
10879: john foderaro
10880:
10881:
10882:
10883:
10884: From @MIT-MC:[email protected] Mon Dec 17 13:08:08 1984
10885: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10886: id AA01035; Mon, 17 Dec 84 13:08:08 pst
10887: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10888: id AA24610; Mon, 17 Dec 84 13:07:10 pst
10889: Message-Id: <[email protected]>
10890: Date: 17 Dec 84 16:02:13 EST
10891: From: Wilson.Harvey@CMU-CS-IUS
10892: Subject: appending to files in lisp?
10893: To: BBoard.Maintainer@CMU-CS-A
10894:
10895:
10896: Does anyone have a function that will allow them to append to a file? I
10897: need to open a file and write some data to it then, at a later time, reopen
10898: the same file and add some more data to it. The only things that I could
10899: find in Franz were "infile" and "outfile", and "outfile" truncates the file
10900: when called. It would be nice if the function would create the file if it
10901: didn't already exist, but that is not necessary.
10902:
10903: Thanks. --Wilson
10904:
10905: P.S. I tried writing a C-function to handle this, but I didn't have any luck
10906: passing the FILE pointer back into Franz. It didn't recognize the pointer
10907: as a port, and I don't know how to set it straight.
10908:
10909:
10910: From [email protected] Mon Dec 17 13:31:59 1984
10911: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10912: id AA01357; Mon, 17 Dec 84 13:31:59 pst
10913: Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10914: id AA25405; Mon, 17 Dec 84 13:30:56 pst
10915: Message-Id: <[email protected]>
10916: Date: Mon, 17 Dec 84 16:23:16 EST
10917: From: William K. Cadwallender (LCWSL) <[email protected]>
10918: To: franz-friends@BERKELEY
10919: Subject: Please change my ID
10920:
10921: The computer people here at ARDC have changed my ID: I was wkc@ARDC, I am
10922: now cadwall@ARDC. Please update the franz-friends mailer accordingly.
10923: Thanks,
10924: Bill Cadwallender
10925: (now cadwall@ARDC)
10926:
10927: From liz@tove Tue Dec 18 12:19:24 1984
10928: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10929: id AA00302; Tue, 18 Dec 84 12:19:24 pst
10930: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10931: id AA04349; Tue, 18 Dec 84 11:54:53 pst
10932: Received: by tove.ARPA (4.12/4.7)
10933: id AA26165; Tue, 18 Dec 84 14:54:41 est
10934: From: Liz Allen <liz@tove>
10935: Message-Id: <[email protected]>
10936: Date: 18 Dec 1984 1454-EST (Tuesday)
10937: To: Wilson.Harvey@CMU-CS-IUS
10938: Cc: franz-friends@BERKELEY
10939: Subject: Re: appending to files in lisp?
10940: In-Reply-To: Your message of 17 Dec 84 16:02:13 EST.
10941: <[email protected]>
10942:
10943: To append to a file, use the outfile function's second argument:
10944:
10945: (setq oport (outfile '<filename> 'append))
10946:
10947: This is discussed in the documentation for outfile in the Franz Lisp
10948: Manual.
10949:
10950: -Liz
10951:
10952: From @MIT-MC:[email protected] Tue Dec 18 16:46:44 1984
10953: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10954: id AA02563; Tue, 18 Dec 84 16:46:44 pst
10955: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10956: id AA10079; Tue, 18 Dec 84 16:15:50 pst
10957: Message-Id: <[email protected]>
10958: Date: 17 Dec 84 23:04:24 EST
10959: From: Wilson.Harvey@CMU-CS-IUS
10960: Subject: appendfile question answered
10961: To: BBoard.Maintainer@CMU-CS-A
10962:
10963:
10964: Wow, was that an easy question. All the responces were equally simple (use
10965: "fileopen" with mode = a, or use "outfile" with the extra argument
10966: "append").
10967:
10968: I must have an outdated copy of the manual because I could find none of
10969: these "features" documented. A hearty "Thank you" to all who responded.
10970:
10971: Wilson
10972:
10973:
10974: From [email protected] Wed Jan 2 03:00:04 1985
10975: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
10976: id AA08140; Wed, 2 Jan 85 03:00:04 pst
10977: Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.40)
10978: id AA01144; Wed, 2 Jan 85 02:51:04 pst
10979: Message-Id: <[email protected]>
10980: Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a029713
10981: ;2 Jan 85 5:57 EST
10982: To: franz-friends@BERKELEY
10983: Cc: johnson@udel-dewey
10984: Subject: franz on 68k-based systems? (esp NCR tower)
10985: Date: 02 Jan 85 05:57:37 EST (Wed)
10986: From: johnson <johnson@udel-dewey>
10987:
10988:
10989: Has anyone out there had experience using franz (or similar lisps)
10990: on an NCR tower or tower XP? (or any other 68k-based unix system ?)
10991:
10992: I am interested in answers to these questions:
10993:
10994: 1. What version of (franz) lisp are you using.
10995:
10996: 2. Are there any special problems you've discovered in this system?
10997:
10998: 3. How does this system perform? (compared to franz on a VAX 11/70,
10999: assuming you have had experience with both)
11000:
11001: 4. Where did you obtain your version of (franz) lisp and how?
11002: (what media, what cost, under what terms or license?)
11003:
11004: thanks in advance,
11005: johnson@udel-ee
11006:
11007: From sridhar%[email protected] Thu Jan 24 00:31:15 1985
11008: Received: from ucbernie.ARPA by ucbkim.ARPA (4.24/4.27)
11009: id AA12825; Thu, 24 Jan 85 00:31:15 pst
11010: Received: from csnet-relay (csnet-pdn-gw.ARPA) by ucbernie.ARPA (4.24/4.40)
11011: id AA15268; Thu, 24 Jan 85 00:31:03 pst
11012: Message-Id: <[email protected]>
11013: Received: from wsu by csnet-relay.csnet id a006053; 24 Jan 85 3:16 EST
11014: Date: Wed, 23 Jan 85 21:50 PST
11015: From: "S. Sridhar" <sridhar%[email protected]>
11016: To: cross%[email protected]
11017: Cc: [email protected]
11018: Subject: pretty printing
11019:
11020: Is there any way I can pretty-print Franz lisp function (or files) with all
11021: the comments in tact. Right now when I use the built in pp, it pretty prints
11022: and strips off all comments. I mean is there any built-in function that does
11023: this. Thanks.
11024:
11025: Sridhar (sridhar@wsu)
11026:
11027: From [email protected] Thu Jan 24 05:33:59 1985
11028: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11029: id AA14557; Thu, 24 Jan 85 05:33:59 pst
11030: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11031: id AA00666; Thu, 24 Jan 85 05:16:27 pst
11032: Message-Id: <[email protected]>
11033: Date: Thu, 24 Jan 85 7:59:46 EST
11034: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
11035: To: "S. Sridhar" <sridhar%[email protected]>
11036: Cc: Franz-Friends@BERKELEY
11037: Subject: Re: pretty printing
11038:
11039: Haah,
11040:
11041: Franz's (read) function trashes all comments on input. [Which means
11042: you can document your data files.] You have to pretty-print the
11043: original code before Franz gets it. I don't know of any stand-alone
11044: programs to do this (surely someone has written one). I use
11045: Berkeley's "vi" editor because it has a lisp mode; all input is
11046: automatically pretty-printed if you say
11047: :set ai lisp
11048: (ai stands for autoindent)
11049: Another way is to execute the vi "=" command while in lisp mode. All
11050: of this is documented in the vi manual. Hope this helps.
11051:
11052: dsw, fferd
11053: Fred S. Brundick
11054: USABRL, APG, MD.
11055: <fsbrn@brl-voc>
11056:
11057: From @MIT-MC:smh@MIT-EMS Thu Jan 24 06:01:33 1985
11058: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11059: id AA14651; Thu, 24 Jan 85 06:01:33 pst
11060: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11061: id AA00458; Thu, 24 Jan 85 06:00:41 pst
11062: Message-Id: <[email protected]>
11063: Received: by mit-ems.Mit-chaos.Arpa id AA25956; Thu, 24 Jan 85 08:59:42 est
11064: Date: Thu, 24 Jan 85 08:59:42 est
11065: From: Steven Haflich <smh@mit-ems>
11066: To: franz-friends@BERKELEY, sridhar%wsu.csnet@csnet-relay
11067: Subject: Re: pretty printing
11068:
11069: Since comments are not part of a Lisp form returned by `read', clearly
11070: no pretty-print function can do what you want. Certainly a far more
11071: complicated pretty-printer could be written which would be passed an
11072: ascii file to read and which would somehow preserve comments inside the
11073: form in order to regurgitate them during formatting. The problem has
11074: several complications, however, such as how to handle ascii Lisp text
11075: with conditionalized inclusions (`#+' constructions)...
11076:
11077: Instead, what you want is probably provided the Lisp-mode `grind'
11078: facilities available in several popular text editors -- in particular,
11079: EMACS. (I know CCA EMACS works, and believe Gosling EMACS does also.)
11080: In these editors a couple keystrokes will specify a region of text and
11081: apply one of several Lisp-indentation algorithms to it. They almost
11082: always indent in reasonable ways, and attempt to do reasonable things
11083: with comments, at least. The ones with which I am familiar will *not*,
11084: however, adjust line length length by moving either comment or Lisp
11085: text from line to line. This is not a great problem for normal
11086: human-typed text, such as programs, since one tends not to type
11087: absurdly long lines.
11088:
11089:
11090: From peck@sri-spam Wed Feb 6 12:01:17 1985
11091: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11092: id AA28782; Wed, 6 Feb 85 12:01:17 pst
11093: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11094: id AA04441; Wed, 6 Feb 85 12:00:09 pst
11095: Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
11096: id AA08198; Wed, 6 Feb 85 12:00:05 pst
11097: Message-Id: <[email protected]>
11098: Date: 06 Feb 85 11:59:58 PST (Wed)
11099: To: ailist-request@sri-ai, franz-friends@BERKELEY
11100: Subject: AI, Lisp, Graphics on SUN computers?
11101: From: peck@sri-spam
11102:
11103: I would like to here from anyone using SUN computers
11104: who can supply answers or comments on any of these issues:
11105: Is Franz the only (best) lisp available?
11106: Has anyone used the Maryland Flavors to create useful tools/extensions?
11107: Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
11108: Any differential reports of Prolog (Quintus) vs Lisp ?
11109: Any obvious alternative to SUN? (vendor in same class (Tektronix?))
11110: Worst or hidden problems, pitfalls, gotcha's, etc.
11111: > Can real AI development (even applications) be supported on SUN's? <
11112:
11113: From kessler%utah-orion@utah-cs Wed Feb 6 15:58:12 1985
11114: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11115: id AA03031; Wed, 6 Feb 85 15:58:12 pst
11116: Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11117: id AA06871; Wed, 6 Feb 85 13:46:19 pst
11118: Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1)
11119: id AA03096; Wed, 6 Feb 85 14:37:05 MST
11120: Received: by utah-orion.ARPA (4.42/4.40.1)
11121: id AA10406; Wed, 6 Feb 85 14:36:22 MST
11122: Date: Wed, 6 Feb 85 14:36:22 MST
11123: From: kessler%utah-orion@utah-cs (Robert Kessler)
11124: Message-Id: <[email protected]>
11125: To: [email protected]
11126: Cc: [email protected], franz-friends@BERKELEY
11127: Subject: Re: AI, Lisp, Graphics on SUN computers? (Long Message)
11128: In-Reply-To: Your message of 06 Feb 85 11:59:58 PST (Wed).
11129: <[email protected]>
11130:
11131:
11132: > I would like to here from anyone using SUN computers
11133: > who can supply answers or comments on any of these issues:
11134: > Is Franz the only (best) lisp available?
11135: We have finally finished porting Portable Standard LISP (PSL) to yet
11136: another machine. This time it is now running on the SUN. Initial
11137: timing measurements indicate that its speed is somewhere between a
11138: Vax 750 and 780 (all running PSL), and about twice as fast as Franz running
11139: the REDUCE algebra system test on Suns. We are now running the Gabriel
11140: benchmarks to discover where it fits in the set. For more details
11141: see the announcement at the end of this message.
11142: > Has anyone used the Maryland Flavors to create useful tools/extensions?
11143: PSL provides support for a simple flavors package that seems quite
11144: useful. However, the current version has no inheritance.
11145: > Any support for sun graphics (windows, menus,etc) a la Interlisp-D?
11146: We have oload working which allows you to call externally compiled
11147: routines (like other c sources). So the interface should be easy to
11148: add (but we haven't done it).
11149: > Any differential reports of Prolog (Quintus) vs Lisp ?
11150: None that I know of.
11151: > Any obvious alternative to SUN? (vendor in same class (Tektronix?))
11152: PSL also runs on Apollo's and HP Series 200 (both 68K based machines).
11153: We have also ported a simple "educational" version to the 128K
11154: Macintosh which is used in a beginning programming class. We plan on
11155: moving at least the Standard LISP subset and compiler to the 512K mac
11156: (so if you want to go really cheap...... :-) )
11157: > Worst or hidden problems, pitfalls, gotcha's, etc.
11158: We had a lot of problems with the Sun port. Some were hardware
11159: related, others were differences between Unix 4.2 on the Sun and on the
11160: Vax. After we get some more experience using PSL on the machine, maybe
11161: we could report more.
11162: > > Can real AI development (even applications) be supported on SUN's? <
11163: I think so, as long as you can get one with enough memory. Some of our
11164: applications running on HP 9836's (which doesn't have virtual memory)
11165: really fly (better than a 780 in speed). So, memory is really a key to
11166: a fast machine.
11167: >
11168: Bob.
11169:
11170: PSL 3.2 for the SUN Workstation
11171:
11172: We are pleased to announce that Portable Standard LISP (PSL) version
11173: 3.2 is now available for the Sun workstation. PSL is about the power,
11174: speed and flavor of Franz LISP or MACLISP, with growing influence
11175: from Common LISP. It is recognized as an efficient and portable
11176: LISP implementation with many more capabilities than described in
11177: the 1979 Standard LISP Report. PSL's main strength is its
11178: portability across many different systems, including: Vax BSD
11179: Unix, Vax VMS, Extended Addressing DecSystem-20 Tops-20, Apollo
11180: DOMAIN Aegis, and HP Series 200. A version for the IBM-370 is in
11181: beta test and two Cray versions are being used on an experimental
11182: basis. Since PSL generates very efficient code, it is an ideal
11183: delivery vehicle for LISP based applications (we can also provide PSL
11184: reseller licenses for binary only and source distributions).
11185:
11186: PSL is distributed for the various systems with executables, all
11187: sources, an approximately 500 page manual and release notes. The
11188: release notes describe how to install the system and how to rebuild
11189: the various modules. We are charging $750 for the Sun version of
11190: PSL for Commercial Site licenses. Non-profit institutions and all
11191: other versions of PSL will not be charged a license fee. We are also
11192: charging a $250 tape distribution fee for each system.
11193:
11194: PSL is in heavy use at Utah, and by collaborators at Hewlett-Packard,
11195: Rand, Stanford, Columbia and over 250 other sites. Many existing
11196: programs and applications have been adapted to PSL including
11197: Hearn's REDUCE computer algebra system and GLISP, Novak's object
11198: oriented LISP dialect. These are available from Hearn and Novak.
11199:
11200: To obtain a copy of the license and order form, please send a NET
11201: message or letter with your US MAIL address to:
11202:
11203: Utah Symbolic Computation Group Secretary
11204: University of Utah - Dept. of Computer Science
11205: 3160 Merrill Engineering Building
11206: Salt Lake City, Utah 84112
11207:
11208: ARPANET: CRUSE@UTAH-20
11209: USENET: utah-cs!cruse
11210:
11211: From cas@cvl Thu Feb 21 11:40:59 1985
11212: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11213: id AA17380; Thu, 21 Feb 85 11:40:59 pst
11214: Received: from cvl.ARPA (cvl.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11215: id AA23930; Thu, 21 Feb 85 11:33:27 pst
11216: Received: by cvl.ARPA (4.12/4.7)
11217: id AA09421; Thu, 21 Feb 85 14:38:26 est
11218: Date: Thu, 21 Feb 85 14:38:26 est
11219: From: cas@cvl (Cliff Shaffer)
11220: Message-Id: <[email protected]>
11221: To: franz-friends@BERKELEY
11222: Subject: database system request
11223:
11224:
11225: Does anybody know of a database system written in FRANZ or easily
11226: compatible with FRANZ? We have written a lot of software for a
11227: geographic information system, and may want to redo the section which
11228: handles random bits of information associated with polygons or points
11229: stored in a map. Right now we store this information as a property
11230: list on an atom associated with the polygon or point in question. This
11231: becomes very inefficient when we want to find all such atoms with
11232: a particular value for some arbitrary property. Equally importantly,
11233: there is very little relationship between the set of properties associated
11234: with each polygon or point, so a system storing a fixed length record
11235: for each polygon, with fields for each piece of information, would not work.
11236: Any suggestions?
11237: Cliff Shaffer
11238: cas@cvl
11239:
11240: From layer@ucbdali Thu Feb 21 12:54:14 1985
11241: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
11242: id AA18356; Thu, 21 Feb 85 12:54:14 pst
11243: Received: by ucbdali.ARPA (4.24/4.40)
11244: id AA16858; Thu, 21 Feb 85 12:53:47 pst
11245: Date: Thu, 21 Feb 85 12:53:47 pst
11246: From: layer@ucbdali (Kevin Layer)
11247: Message-Id: <[email protected]>
11248: Phone: (415) 652-2405
11249: To: cas@cvl, franz-friends@kim
11250: Subject: Re: database system request
11251:
11252: You could use the dbm library, as supplied by UNIX (/usr/lib/libdbm.a),
11253: via cfasl and getaddress.
11254:
11255: Kevin
11256:
11257:
11258: From freemant%[email protected] Mon Feb 25 04:50:50 1985
11259: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11260: id AA20175; Mon, 25 Feb 85 04:50:50 pst
11261: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.41)
11262: id AA24603; Mon, 25 Feb 85 04:43:20 pst
11263: Date: Mon, 25 Feb 85 04:43:17 pst
11264: Message-Id: <[email protected]>
11265: Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST
11266: From: freemant%[email protected]
11267: To: franz-friends@BERKELEY
11268:
11269: Hello! Our version of lxref didn't work right when it was passed the -a
11270: option, so I fixed it. Someone may want to use the -a option on lxref one
11271: of these days, so I am mailing you my fixes in hopes that you will
11272: distribute them.
11273:
11274: Things are kind of chaotic around here, so I am not sure that I was working
11275: with the most current version of lxref. Make sure that your current version
11276: of lxref matches the code that I changed before you edit in my changes.
11277:
11278: The origional definition of the function process-annotate-file left files
11279: open. Because the lisp interpreter can only have a finite number of files
11280: open at once, this caused lxref to bomb when it was given a large job to do.
11281: To fix this, I changed the definition of process-annotate-file from:
11282:
11283: (defun process-annotate-file (filename)
11284: (let (sourcep outp)
11285: ; make sure file exists and write annotate file as a
11286: ; file with the prefix #,
11287: (if (null (errset (setq sourcep (infile filename))))
11288: then (msg "will ignore that file " N)
11289: else ; will write to file.A (erasing the final l)
11290: (let ((filen (concat "#," filename)))
11291: (setq outp (outfile filen))
11292: (anno-it sourcep outp)
11293: (close outp)
11294: ; now mv the original filename to #dfilename
11295: ; and the annotated file to the original file
11296: (let ((oldcopy (concat "#." filename)))
11297: (if (null (errset
11298: (progn (if (probef oldcopy)
11299: then (sys:unlink oldcopy))
11300: (sys:link filename oldcopy)
11301: (sys:unlink filename)
11302: (sys:link filen filename)
11303: (sys:unlink filen))))
11304: then (msg "An error occured while mving files around "
11305: N
11306: "files possibly affected "
11307: filename oldcopy filen)))))))
11308:
11309: to:
11310:
11311: (defun process-annotate-file (filename)
11312: (let (sourcep outp)
11313: ; make sure file exists and write annotate file as a
11314: ; file with the prefix #,
11315: (if (null (errset (setq sourcep (infile filename))))
11316: then (msg "will ignore that file " N)
11317: else ; will write to file.A (erasing the final l)
11318: (let ((filen (concat "#," filename)))
11319: (setq outp (outfile filen))
11320: (anno-it sourcep outp)
11321: (close outp)
11322: (close sourcep)
11323: ; now mv the original filename to #dfilename
11324: ; and the annotated file to the original file
11325: (let ((oldcopy (concat "#." filename)))
11326: (if (null (errset
11327: (progn (if (probef oldcopy)
11328: then (sys:unlink oldcopy))
11329: (sys:link filename oldcopy)
11330: (sys:unlink filename)
11331: (sys:link filen filename)
11332: (sys:unlink filen))))
11333: then (msg "An error occured while mving files around "
11334: N
11335: "files possibly affected "
11336: filename oldcopy filen)))))))
11337:
11338: Note that the only change is the insertion of one close statement.
11339:
11340: The other bug I found was that find-func miserably failed to do its job
11341: right. The origional version of the function looked like this:
11342:
11343: (defun find-func (buf)
11344: ; first locate first space or tab
11345: (do ((i 1 (1+ i))
11346: (max (cxr 0 buf))
11347: (die))
11348: ((or (setq die (not (<& i max)))
11349: (memq (cxr i buf) '(#\space #\tab)))
11350: (if die
11351: then nil ; can find it, so give up
11352: else ; find first non blank
11353: (do ((ii i (1+ ii)))
11354: ((or (setq die (not (<& ii max)))
11355: (not (memq (cxr ii buf) '(#\space #\tab))))
11356: (if (or die (eq (cxr ii buf) #\lpar))
11357: then nil
11358: else ; fid first sep or left paren
11359: (do ((iii (1+ ii) (1+ iii)))
11360: ((or (not (<& iii max))
11361: (memq (cxr iii buf)
11362: '(#\space #\tab #\lpar)))
11363: (implode-fun buf ii (1- iii)))))))))))
11364:
11365: Not unsurprisingly, this code didn't work. I discarded it and rewrote the
11366: function in a much simpler fashion:
11367:
11368: (defun find-func (buf)
11369: (let ((i 1)
11370: (max (cxr 0 buf))
11371: (result nil))
11372: (loop until (or (greaterp i max) (memq (cxr i buf) '(#\space #\tab)))
11373: do (setq i (+ i 1)))
11374: (loop while (and (not (greaterp i max))
11375: (memq (cxr i buf) '(#\space #\tab))) do
11376: (setq i (+ i 1)))
11377: (loop until (or (greaterp i max)
11378: (memq (cxr i buf)
11379: '(#\space #\tab #.(getcharn '|(| 1)))) do
11380: (setq result (cons (cxr i buf) result))
11381: (setq i (+ i 1)))
11382: (if result then (implode (reverse result)) else nil)))
11383:
11384: The error in the origional definition of find-func caused the -a option to
11385: always do nothing. It is surprising that no one caught the fact that the -a
11386: option was useless earlier. (However, I am not sure that the source that I
11387: was looking at came from your tape, so perhaps it isn't your fault.) In any
11388: case, my version works.
11389:
11390: Bye!
11391: Tim Freeman
11392: freemant@rpi
11393:
11394: From bane@gymble Wed Feb 27 12:20:08 1985
11395: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11396: id AA19926; Wed, 27 Feb 85 12:20:08 pst
11397: Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11398: id AA13078; Wed, 27 Feb 85 12:12:21 pst
11399: Received: by gymble.ARPA (4.12/4.7)
11400: id AA25775; Wed, 27 Feb 85 15:17:32 est
11401: Date: Wed, 27 Feb 85 15:17:32 est
11402: From: John R. Bane <bane@gymble>
11403: Message-Id: <[email protected]>
11404: To: franz-friends@BERKELEY
11405: Subject: symeval 'feature'
11406:
11407: I've just finished a half-hour "It works interpreted but not compiled"
11408: debugging session with a user who was new to compiling Franz, and I have a
11409: complaint. The function 'symeval' works misleadingly differently interpreted
11410: and compiled.
11411:
11412: Compiled symeval open-codes into a symbol value-cell reference. This
11413: is fine. Interpreted symeval is implemented as a pointer to 'eval'. This
11414: loses because something like (symeval '(+ 1 2)) is not an error interpreted,
11415: and it should be because it turns into the worst kind of bug when compiled,
11416: since it'll return some random pointer from cons node space.
11417:
11418: This 'feature' was observed in Opus 38.91.
11419:
11420: From [email protected] Thu Feb 28 11:37:06 1985
11421: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11422: id AA04105; Thu, 28 Feb 85 11:37:06 pst
11423: Received: from wisc-ai.arpa (wisc-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11424: id AA08982; Thu, 28 Feb 85 11:29:20 pst
11425: Date: Thu, 28 Feb 85 13:34:20 cst
11426: From: [email protected] (David Neves)
11427: Message-Id: <[email protected]>
11428: Received: by wisc-ai.arpa; Thu, 28 Feb 85 13:34:20 cst
11429: To: franz-friends@BERKELEY
11430: Subject: franz to vi & back
11431:
11432: We have a heavily loaded vax on which we run our Lisp classes. It
11433: seems to me that we could lessen the load by not having VI start
11434: up anew every time the student does a VIL in Franz.
11435:
11436: It would be nice to have two processes, one Lisp and the other VI.
11437: There would be a function (like VIL) in Franz that would start up
11438: a VI process if there wasn't one and if there was a VI process just
11439: goto it. When the student is finished editing the file he/she would
11440: hit a key that would save out the file and return to Lisp (without
11441: killing the VI process). I believe that Gosling Emacs had something
11442: like this, only more sophisticated.
11443:
11444: My questions. Has anyone done this for Franz & VI? Would this help
11445: the load average on a VAX? If no one has done it, would it be difficult
11446: to do?
11447: -Thanks, David
11448:
11449: From moore.losangel%[email protected] Thu Feb 28 16:20:09 1985
11450: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11451: id AA08882; Thu, 28 Feb 85 16:20:09 pst
11452: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11453: id AA05586; Thu, 28 Feb 85 16:12:12 pst
11454: Message-Id: <[email protected]>
11455: Received: from ibm-sj by csnet-relay.csnet id ac15203; 28 Feb 85 19:11 EST
11456: Date: Thu, 28 Feb 85 15:34:11 PST
11457: From: Jim moore <moore.losangel%[email protected]>
11458: To: [email protected], franz-friends@BERKELEY
11459: Subject: Can/does Franz exist on PC/IX or VM/IX?
11460:
11461: I am looking for a high quality LISP to run under PC(VM)/IX.
11462:
11463: Is Franzlisp the one? Who & How?
11464:
11465: If not, which?
11466:
11467: Thanks in advance -- Jim Moore
11468:
11469: (MOORE.LOSANGEL@IBM)
11470:
11471: p.s. pls reply directly since I'm not on this list.
11472:
11473:
11474: From [email protected] Fri Mar 1 04:29:27 1985
11475: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11476: id AA17511; Fri, 1 Mar 85 04:29:27 pst
11477: Received: from udel-dewey (udel-dewey.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11478: id AA18449; Fri, 1 Mar 85 04:21:31 pst
11479: Message-Id: <[email protected]>
11480: Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009017
11481: ;1 Mar 85 7:18 EST
11482: To: David Neves <[email protected]>
11483: Cc: franz-friends@BERKELEY, johnson@udel-dewey
11484: Subject: Re: franz to vi & back
11485: In-Reply-To: Your message of Thu, 28 Feb 85 13:34:20 cst.
11486: <[email protected]>
11487: Date: 01 Mar 85 07:18:11 EST (Fri)
11488: From: johnson@udel-dewey
11489:
11490:
11491: Subject: franz to vi & back
11492:
11493: > We have a heavily loaded vax on which we run our Lisp classes. It
11494: > seems to me that we could lessen the load by not having VI start
11495: > up anew every time the student does a VIL in Franz.
11496: >
11497: > It would be nice to have two processes, one Lisp and the other VI.
11498: > There would be a function (like VIL) in Franz that would start up
11499: > a VI process if there wasn't one and if there was a VI process just
11500: > goto it. When the student is finished editing the file he/she would
11501: > hit a key that would save out the file and return to Lisp (without
11502: > killing the VI process). I believe that Gosling Emacs had something
11503: > like this, only more sophisticated.
11504: >
11505: > My questions. Has anyone done this for Franz & VI? Would this help
11506: > the load average on a VAX? If no one has done it, would it be difficult
11507: > to do?
11508: >
11509:
11510: I have developed something similar to what you describe, for franz
11511: running under bsd4.2
11512:
11513: It was moderately difficult at the time, but I was just learning to
11514: exploit job control.
11515:
11516: in this system, the user invokes:
11517: (vif foo)
11518: to edit the function foo.
11519:
11520: when he is finished editing, he saves the current buffer by:
11521: :w
11522: then exits the editor by pressing:
11523: ^Z [NOT wq!!]
11524:
11525: (getting users o use ^Z rather than wq is the biggest difficulty)
11526:
11527: the function is the read from a temporary file which is created
11528: by vif.
11529:
11530: if the user later wishes to modify the SAME function [often the case]
11531: he simply invokes:
11532: (vif)
11533: - and is returned to the [stopped] editing session EXACTLY where
11534: he left it.
11535: [ providing some motivation for putting up with ^Z ]
11536:
11537:
11538: The system people around here aren't too adventurous, so the only people
11539: who use this system are my friends and myself, so I can't say what effect
11540: it has on the load, [but it can only help]
11541:
11542: one problem: files in /tmp may accumulate, as there is no way to force
11543: a user to clean up all editing sessions before exiting lisp.
11544: [but that is what /tmp is for!] you might warn your system people
11545: to remove all VIF files that are over 2days old, or something like that.
11546:
11547:
11548: note: this package knows about changes made by [cmu]edit, and may
11549: be simplified if you are using a system where cmuedit is unavailable.
11550:
11551:
11552: NOTE!!!!!!
11553: Neither the University of Delaware
11554: nor Apperson H. Johnson
11555: relinquishes any rightts toi this software.
11556:
11557: Please do NOT transfer the software without written permission
11558: from both The University of Delaware and Apperson H. Johnson.
11559:
11560:
11561: **********************************************************
11562: setting up the system:
11563:
11564: Script started on Fri Mar 1 06:49:30 1985
11565: % make jced
11566: cc -c jced.c
11567: cc -c eroar.c
11568: ld -o jcedmod.o -r jced.o eroar.o
11569: % lisp
11570: Franz Lisp, Opus 38.79
11571: -> [load 'vif]
11572: [load vif.l]
11573: /usr/lib/lisp/nld -N -x -A /usr/ucb/lisp -T 95800 jcedmod.o -e _jced_ -o /tmp/Li8788.0 -lc
11574: t
11575: -> [dumplisp newlisp]
11576: nil
11577: -> (exit)
11578: script done on Fri Mar 1 06:51:45 1985
11579: *******************************************************************
11580:
11581: "newlisp" is now the lisp to use - you can put it in some directory
11582: in youtr student's path
11583: ---------- here is vif.l --------------------------------
11584: (setq sccid "#(@)vif.l V1.1 johnson@udel 10/13/84")
11585: (eval-when (compile)
11586: (msg "vif doen't work compiled!!!\\ "N) (exit))
11587: (declare (localf sccid))
11588: ;
11589: ; uses job-control to allow ^Z from 'vi' to return to inside of
11590: ; Lisp function
11591: ;
11592:
11593:
11594: ; ::vif::
11595: ;
11596: ; Usage: (vif [<function-name>])
11597: ; returns: t if function is loaded without errors, nil otherwise
11598: ; side-effect: starts vi with temporary file,
11599: ;
11600: ; does NOT REMOVE FILE UNLESS SUCCESSFUL LOAD HAS BEEN MADE
11601: ; AND user has "quit" the editor
11602: ;
11603: ; - allows ~instantaneous return to file being edited if
11604: ; vi has been exited by ^Z (or whatever the susp character is, [see stty.1])
11605: ;
11606: ; NOTE: file and vi session may stay "LIVE" even between invocations!!!
11607: ; eg:
11608: ;
11609: ; (def jnk '(lambda (x) "i am jnk"))
11610: ;
11611: ; (vif jnk)
11612: ; --> vi session, followed by :w, and then ^Z
11613: ; t
11614: ; followed by :
11615: ; (vif jnk )
11616: ; or:
11617: ; (vif)
11618: ; --> INSTANTLY returns to former vi session !!
11619: ;
11620: ;
11621: ;
11622: (declare (special *jced_lastf* *jced_lastc* %changes))
11623:
11624: (def vif
11625: (nlambda (fn)
11626: (prog (res tf er ppflag)
11627: (cond
11628: (fn
11629: (cond
11630: ((or (not (boundp '*jced_lastf*))
11631: (neq *jced_lastf* (car fn)))
11632: (setq ppflag t)
11633: (setq *jced_lastf* (car fn))))))
11634: (cond ((boundp '*jced_lastf*)
11635: (setq tf
11636: (substring (concat '/tmp/VF
11637: (concat (syscall 20)
11638: (concat '_
11639: *jced_lastf*)))
11640: 1))
11641: (cond
11642: ((and (boundp '%changes)
11643: (memq *jced_lastf* %changes)
11644: (or (not (boundp '*jced_lastc*))
11645: (neq *jced_lastc* (memq *jced_lastf* %changes))))
11646: (setq ppflag t)))
11647: (cond
11648: (ppflag
11649: (eval (list 'pp (list 'F tf) *jced_lastf*)))))
11650: (t (msg "vif: edit what ??" N) (return nil)))
11651: lp (setq res (jced_ tf ""))
11652: (setq er nil)
11653: (setq ER%all '(lambda (x)
11654: (setq er t))
11655: )
11656: (cond
11657: ((not (probef tf))
11658: (msg "vif: cannot find " tf)
11659: (cond
11660: ((eq res 1)
11661: (msg " want to return to the editor? {y/n} ")
11662: (cond ((eq (read) 'y) (go lp)))
11663: (return nil)))
11664: (msg " sorry." N)
11665: (makunbound '*jced_lastf*)
11666: (return t)))
11667: (errset (load tf))
11668: (cond
11669: ((boundp '%changes)
11670: (setq *jced_lastc* (memq *jced_lastf* %changes))))
11671: (cond
11672: (er (msg "vif: want to fix " *jced_lastf* "? {y/n} ")
11673: (cond ((eq (read) 'y) (go lp)))))
11674: (cond ((eq res 0)
11675: (makunbound '*jced_lastf*)
11676: (syscall 10 tf)
11677: (return t))
11678: (t (return nil))))))
11679:
11680:
11681: ;
11682: ; include modules written in C
11683: (cfasl 'jcedmod.o '_jced_ 'jced_ "integer-function")
11684:
11685: ; initialization string for jced
11686: (jced_ ":se lisp
11687: " "edinit")
11688:
11689: ; editor to use
11690: (jced_ "/usr/ucb/vi" "editor")
11691:
11692: --------------- ------- jced.c ---------------
11693: static char sccid[] = "@(#)jced.c 1.1 johnson@udel 11/2/84";
11694:
11695: #include <signal.h>
11696: #include <sgtty.h>
11697: #include <errno.h>
11698: #include <sys/wait.h>
11699: #include <sys/types.h>
11700: #include <sys/stat.h>
11701: #include <sys/file.h>
11702: #include <stdio.h>
11703:
11704: #define streq(s1,s2) (0 == strcmp(s1,s2))
11705: #define file_exist(FN) (0 == access(FN,F_OK))
11706: static int chpgrp, pgrp;
11707: static union wait status;
11708: static struct stat st0,st1;
11709: static struct sigvec sv1 = { SIG_IGN, 0, 0};
11710: static struct sigvec sv0;
11711:
11712: static char curname[128];
11713: static char ed_buf[] = "/usr/ucb/vi";
11714: static char init_buf[] = "";
11715: static char myname_buf[] = "jced_";
11716: static char *editor = ed_buf;
11717: static char *edinit = init_buf;
11718: static char *myname = myname_buf;
11719:
11720: /* ::jced_::
11721: *
11722: * Usage: (jced_ "filename" "")
11723: *
11724: * jced_ is a job-control editor
11725: *
11726: * - starts an editor session with "filename"
11727: * (or resumes it if there is a 'living' session with that file)
11728: * - returns 1 if the session remains alive, 0 if the session is over
11729: *
11730: * NOTE: if the SECOND argument is not the EMPTY string,
11731: * then the following special calls may apply:
11732: *
11733: * (jced_ "/usr/ucb/vi" "editor")
11734: * - causes jced to use /usr/ucb/vi as the editor (this is the default)
11735: *
11736: * : (jced_ ":se bla" "edinit")
11737: * - causes jced cause the editor to pretend that the user typed ":se bla"
11738: * every time the editor is invoked (the default is "")
11739: *
11740: * : (jced_ "jced_" "myname")
11741: * - causes jced to use the name "jced_" in its prompts and messages
11742: * (this is the default)
11743: *
11744: */
11745: int
11746: jced_(fname,cmd)
11747: char *fname, *cmd;
11748: {
11749: union wait status;
11750: char resp[2];
11751:
11752:
11753: if (*cmd) {
11754: if (streq(cmd,"editor")) newstring(&editor,fname);
11755: else if (streq(cmd,"edinit")) newstring(&edinit,fname);
11756: else if (streq(cmd,"myname")) newstring(&myname,fname);
11757: else fprintf(stderr,"%s: %s is an unknown command",myname,cmd);
11758: return(0);
11759: }
11760:
11761: if (*curname) {
11762: if (*fname && !streq(fname,curname)) {
11763: if (file_exist(curname))
11764: eroar(unlink(curname),0,"unlink %",curname);
11765: kvil_();
11766: strcpy(curname,fname);
11767: begin_vi(); resume_vi();
11768: } else {
11769: /*
11770: * if file has been modified elsewhere,
11771: * new editing session is needed
11772: */
11773: if (file_exist(curname)) {
11774: eroar(stat(curname,&st1),0,"stat");
11775: if(st0.st_mtime != st1.st_mtime) {
11776: kvil_(); strcpy(curname,fname); begin_vi();
11777: }
11778: }
11779: resume_vi();
11780: }
11781: } else if (*fname) {
11782: strcpy(curname,fname);
11783: begin_vi(); resume_vi();
11784: } else
11785: return(0);
11786:
11787: return((*curname) ? 1 : 0);
11788: }
11789:
11790: /* to be called when a function is modified elsewhwre */
11791: kvil_()
11792: {
11793: eroar(killpg(chpgrp,SIGKILL),0,"killpg %d",chpgrp);
11794: wait3(&status,WUNTRACED,0);
11795: curname[0] = '\0';
11796: }
11797:
11798: static
11799: begin_vi()
11800: {
11801: if (chpgrp = fork()) {
11802: pgrp = getpgrp(0);
11803: eroar(setpgrp(chpgrp,chpgrp),0,"setpgrp");
11804: } else {
11805: fakeinput(edinit);
11806: execlp(editor,editor,curname,0);
11807: fprintf(stderr,"%s: exec of %s failed\n",myname,editor);
11808: }
11809: }
11810:
11811:
11812: static
11813: resume_vi()
11814: {
11815: char dum[2];
11816:
11817: for (;;) {
11818: eroar(sigvec(SIGTTOU,&sv1,&sv0),0,"sigvec -IGN TTOU");
11819: eroar(ioctl(0,TIOCSPGRP,&chpgrp),0,"SPGRP chpgrp");
11820: if (file_exist(curname))
11821: eroar(stat(curname,&st1),0,"stat");
11822: else
11823: st1.st_mtime = 0;
11824: killpg(chpgrp,SIGCONT);
11825: wait3(&status,WUNTRACED,0);
11826: eroar(ioctl(0,TIOCSPGRP,&pgrp),0,"ioctl SPGRP pid");
11827: eroar(sigvec(SIGTTOU,&sv0,0),0,"sigvec -DFL TTOU");
11828: if (file_exist(curname))
11829: eroar(stat(curname,&st0),0,"stat");
11830: else
11831: st0.st_mtime = st1.st_mtime;
11832:
11833: if(!status.w_status) {
11834: curname[0] = '\0'; break;
11835: }
11836: if(st0.st_mtime == st1.st_mtime) {
11837: fprintf(stderr,"%s: %s was not modified, try again? {y/n} ",
11838: myname, curname);
11839: if (1 == scanf("%1s",dum) && dum[0] == 'n') break;
11840: } else
11841: break;
11842: }
11843: }
11844:
11845: static
11846: fakeinput(s)
11847: char *s;
11848: {
11849: int i;
11850: /* pretend s was typed at the terminal */
11851: for(i=0;s[i]; ++i)
11852: ioctl(0,TIOCSTI,s+i);
11853: }
11854:
11855: static
11856: newstring(sptr,s)
11857: char **sptr, *s;
11858: {
11859: char *s2, *malloc();
11860:
11861: if (NULL == (s2 = malloc(1 + strlen(s)))) {
11862: fprintf(stderr,"%s: malloc failed\n",myname);
11863: } else {
11864: strcpy(s2,s);
11865: *sptr = s2;
11866: }
11867: }
11868:
11869: --------------------------- eroar.c --------------------
11870:
11871: static char sccid[] = "@(#)eroar.c 1.0 johnson@udel 10/13/84";
11872:
11873: /* ::eroar.c::
11874: *
11875: * error reporter-handler for faulty system function calls
11876: *
11877: * Usage: eroar( <system-call>, <exit-code>, <printf-pattern>,
11878: * <printf-arg>, <printf-arg>, ...... );
11879: *
11880: * behavior:
11881: * if the system call is successful, returns (1) immediately
11882: * else
11883: * prints out the error message (from the printf pattern)
11884: * and prints an error explanation
11885: * if exit-code is non-zero, exits with that code
11886: * else returns (0)
11887: */
11888:
11889:
11890: #include <errno.h>
11891: #include <stdio.h>
11892: #define ERR_BUFMAX 128
11893:
11894: extern int sys_nerr, errno;
11895: extern char *sys_errlist[];
11896:
11897: eroar(expr,code,s,p1,p2,p3,p4,p5,p6,p7,p8,p9)
11898: int expr,code; char *s;
11899: {
11900: static char errbuf[ERR_BUFMAX];
11901: if (-1 != expr) return(1);
11902: fprintf(stderr,s,p1,p2,p3,p4,p5,p6,p7,p8,p9);
11903: fprintf(stderr,": %s\n",
11904: (0 < errno && errno < sys_nerr) ?
11905: sys_errlist[errno] : "UNKNOWN ERROR");
11906: if (code) exit(code);
11907: return(0);
11908: }
11909:
11910: ----------------- makefile -----------------------
11911:
11912: jced : jcedmod.o
11913:
11914: jcedmod.o : jced.o eroar.o
11915: ld -o jcedmod.o -r jced.o eroar.o
11916: -------------------------------------------------------
11917:
11918: ... (share a little joke with the world) ...
11919:
11920: net: johnson@udel-ee
11921: usmail: Apperson H. Johnson
11922: 618 Lehigh Rd. apt S11
11923: Newark, De. 19711
11924: --------------------------------------------------------
11925:
11926: From jshaver@apg-3 Fri Mar 1 13:37:57 1985
11927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11928: id AA22358; Fri, 1 Mar 85 13:21:35 pst
11929: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11930: id AA28355; Fri, 1 Mar 85 13:13:39 pst
11931: Message-Id: <[email protected]>
11932: Date: 1 Mar 1985 16:15:48 EST (Friday)
11933: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
11934: Subject: Vax availability
11935: To: franz-friends@BERKELEY
11936: Cc: jshaver@apg-3
11937:
11938: Is Franz Lisp available for the VAX? Please respond directly to me, as I am
11939: not on the list. Please add me to the list.
11940:
11941: Thank you.
11942: This is an Otrona Attache 1200 bps
11943:
11944:
11945: John
11946:
11947:
11948: From jshaver@apg-3 Mon Mar 4 06:10:51 1985
11949: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11950: id AA11236; Mon, 4 Mar 85 06:10:51 pst
11951: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11952: id AA03832; Mon, 4 Mar 85 06:05:00 pst
11953: Message-Id: <[email protected]>
11954: Date: 4 Mar 1985 9:09:27 EST (Monday)
11955: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
11956: Subject: Returned mail: User unknown
11957: To: franz-friends@BERKELEY
11958: Cc: jshaver@apg-3
11959:
11960:
11961: ----BEGINNING OF FORWARDED MESSAGES----
11962: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
11963: id AA28859; Fri, 1 Mar 85 13:34:56 pst
11964: Received: by ucbkim.ARPA (4.24/4.27)
11965: id AA00121; Fri, 1 Mar 85 13:37:57 pst
11966: Date: 1 Mar 1985 16:15:48 EST (Friday)
11967: From: MAILER-DAEMON%ucbkim@Berkeley (Mail Delivery Subsystem)
11968: Subject: Returned mail: User unknown
11969: Message-Id: <[email protected]>
11970: To: <jshaver@apg-3>
11971:
11972: ----- Transcript of session follows -----
11973: >>> RCPT To:<[email protected]>
11974: <<< 550 <[email protected]>... User unknown
11975: 550 franz-friends-3@ucbmike... User unknown
11976: >>> RCPT To:<[email protected]>
11977: <<< 550 <[email protected]>... User unknown
11978: 550 franz-friends-score@ucbmike... User unknown
11979:
11980: ----- Unsent message follows -----
11981: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
11982: id AA22358; Fri, 1 Mar 85 13:21:35 pst
11983: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
11984: id AA28355; Fri, 1 Mar 85 13:13:39 pst
11985: Message-Id: <[email protected]>
11986: Date: 1 Mar 1985 16:15:48 EST (Friday)
11987: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
11988: Subject: Vax availability
11989: To: franz-friends@BERKELEY
11990: Cc: jshaver@apg-3
11991:
11992: Is Franz Lisp available for the VAX? Please respond directly to me, as I am
11993: not on the list. Please add me to the list.
11994:
11995: Thank you.
11996: This is an Otrona Attache 1200 bps
11997:
11998:
11999: John
12000:
12001:
12002: ----END OF FORWARDED MESSAGES----
12003: Is it something I'm doing?
12004:
12005:
12006: From jshaver@apg-3 Mon Mar 4 06:16:15 1985
12007: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12008: id AA11275; Mon, 4 Mar 85 06:16:15 pst
12009: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12010: id AA03880; Mon, 4 Mar 85 06:10:25 pst
12011: Message-Id: <[email protected]>
12012: Date: 4 Mar 1985 9:10:31 EST (Monday)
12013: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
12014: Subject: mail request failure
12015: To: franz-friends@BERKELEY
12016: Cc: jshaver@apg-3
12017:
12018:
12019: ----BEGINNING OF FORWARDED MESSAGES----
12020: Received: from CMU-CS-A.ARPA (cmu-cs-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12021: id AA29648; Fri, 1 Mar 85 14:05:23 pst
12022: Message-Id: <[email protected]>
12023: Date: 1 Mar 85 17:8:8 EST
12024: From: Mailer <[email protected]>
12025: To: <@BERKELEY:jshaver@apg-3>
12026: Reply-To: Gripe <[email protected]>
12027: Subject: mail request failure
12028:
12029: ----- Transcript of session follows -----
12030:
12031: Mail being sent from disk area [N900AR0M]
12032: *NMail 1 Mar 85 17:06:02 EST;@UCB-VAX.ARPA:jshaver@apg-3;927920.QED[n900ar0m];mark.stevenson@cmua
12033: 1 Mar 85 17:8:8 EST
12034: ?%No such person as 'mark.stevenson' at CMU-CS-A.
12035:
12036:
12037: ----- Unsent message follows -----
12038: Received: from UCB-VAX.ARPA by CMU-CS-A.ARPA; 1 Mar 85 17:05:57 EST
12039: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
12040: id AA28701; Fri, 1 Mar 85 13:30:28 pst
12041: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12042: id AA22358; Fri, 1 Mar 85 13:21:35 pst
12043: Received: from apg-3 (apg-3.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12044: id AA28355; Fri, 1 Mar 85 13:13:39 pst
12045: Message-Id: <[email protected]>
12046: Date: 1 Mar 1985 16:15:48 EST (Friday)
12047: From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
12048: Subject: Vax availability
12049: To: franz-friends@Berkeley
12050: Cc: jshaver@apg-3
12051:
12052: Is Franz Lisp available for the VAX? Please respond directly to me, as I am
12053: not on the list. Please add me to the list.
12054:
12055: Thank you.
12056: This is an Otrona Attache 1200 bps
12057:
12058:
12059: John
12060:
12061:
12062:
12063: ----END OF FORWARDED MESSAGES----
12064: Try a return address of RREINER@Simtel20. They forward everything to me.
12065:
12066:
12067: From [email protected] Tue Mar 5 08:17:28 1985
12068: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12069: id AA00161; Tue, 5 Mar 85 08:17:28 pst
12070: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12071: id AA09879; Tue, 5 Mar 85 08:11:28 pst
12072: Message-Id: <[email protected]>
12073: Date: Tue, 5 Mar 85 11:13:21 EST
12074: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
12075: To: Franz-Friends@BERKELEY
12076: Cc: Meself <[email protected]>
12077: Subject: Trace bug
12078:
12079: Haah,
12080:
12081: We recently installed some revisions to our 4.2 BSD system, and the
12082: Joseph Lister package is apparently broken. Since our system
12083: administrators don't use Franz, I poked around in the file trace.l.
12084: An error run is shown below:
12085:
12086: -> (getsyntax '\;)
12087: vsplicing-macro
12088: -> (trace intersect)
12089: [autoload /usr/lib/lisp/trace]
12090: [load /usr/lib/lisp/trace.l]
12091: [load /usr/lib/lisp/charmac.l]
12092: Error: Unbound Variable: ;;
12093: <1>: (getsyntax '\;)
12094: vcharacter
12095:
12096: The trace code that is executing is:
12097:
12098: (eval-when (eval)
12099: (setq old-read-table-trace readtable)
12100: (setq readtable (makereadtable t))
12101: (setq old-uctolc-value (status uctolc))
12102: (sstatus uctolc nil) ; turn off case conversion
12103: (load 'charmac)
12104: (setsyntax '\; 'macro 'zapline)
12105: )
12106:
12107: What I think is happening is that the readtable is being clobbered by
12108: the (makereadtable t) line. The file charmac.l starts off with a
12109: comment line, but the definition of ';' has changed in the readtable.
12110: I copied trace.l and reversed the last 2 lines so ';' is macro'd to
12111: zapline BEFORE charmac.l is loaded. I can then load trace.l and
12112: (trace) functions with no trouble.
12113:
12114: My question is: Why did I have to reverse those lines ?? (trace) used
12115: to work fine. Is there a problem with (makereadtable) that I need to
12116: fix ?? We are running Opus 38.79.
12117:
12118: dsw, fferd
12119: Fred S. Brundick
12120: USABRL, APG, MD.
12121: <fsbrn@brl-voc>
12122:
12123: "Me ears are on the wrong side of me 'ead."
12124:
12125: From [email protected] Tue Mar 5 14:55:27 1985
12126: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12127: id AA00189; Tue, 5 Mar 85 14:55:27 pst
12128: Received: from BRL-VOC (brl-voc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12129: id AA16643; Tue, 5 Mar 85 13:15:11 pst
12130: Message-Id: <[email protected]>
12131: Date: Tue, 5 Mar 85 16:14:14 EST
12132: From: "Ferd Brundick (VLD/LTTB)" <[email protected]>
12133: To: Franz-Friends@BERKELEY
12134: Cc: Ferd Brundick <[email protected]>, [email protected]
12135: Subject: Re: Trace bug
12136:
12137: Haah,
12138:
12139: >>Why aren't you loading the compiled version of trace?
12140: >>Would that help?
12141:
12142: That was the what the person who stumbled onto the bug said. (I don't
12143: use the trace package myself because everything works the first time
12144: :-). I don't see how that would matter because compiled code is just
12145: as wrong; it just bombs faster. Besides, my slightly obsolete Franz
12146: manual says "the trace package ... usually in the file
12147: /usr/lib/lisp/trace.l". I'm just wondering why the file doesn't work
12148: any more when it used to. I'd rather fix the problem permanently
12149: instead of patching around it.
12150:
12151: dsw, fferd
12152: Fred S. Brundick
12153: USABRL, APG, MD.
12154: <fsbrn@brl-voc>
12155:
12156: "I think I pulled a muscle in me ear."
12157:
12158: From [email protected] Tue Mar 19 16:50:09 1985
12159: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12160: id AA22357; Tue, 19 Mar 85 16:50:09 pst
12161: Received: from MIT-HTVAX.ARPA (mit-htvax.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12162: id AA05308; Tue, 19 Mar 85 11:49:40 pst
12163: Received: by MIT-HTVAX.ARPA (4.12/4.7)
12164: id AA21434; Tue, 19 Mar 85 14:50:20 est
12165: Date: Tue, 19 Mar 85 14:50:20 est
12166: From: Walter Hamscher <[email protected]>
12167: Message-Id: <[email protected]>
12168: To: Franz-Friends@BERKELEY
12169: Subject: Franz -> Common Lisp ?
12170:
12171: Reply-to: [email protected]
12172:
12173: Is there a common lisp that runs on 4.2 BSD? Seems to
12174: me this is a vacuum that many folks must be trying to fill.
12175:
12176: I am wondering:
12177:
12178: (1) Who's working on one?
12179:
12180: <<None of the following answers win brownie points:
12181: (a) DEC. Their Unix common lisp is only for in-house use.
12182: (b) CCA. Ain't ready yet.
12183: (c) David Betz (XLISP 1.4). Currently only a small subset.
12184: (d) NIL. No Unix implementation planned.>>
12185:
12186: (2) Is there a common lisp compatability package for franz?
12187:
12188: <<Unlikely, I know. Still, how much of common
12189: lisp already exists in compatability packages,
12190: e.g. Lexical scoping :-), Packages, Keyword
12191: arguments, Pathnames, Bit-arrays?>>
12192:
12193: (3) Are folks at UCB thinking of spinning off a common
12194: lisp from the existing franz implementation?
12195:
12196: <<Also unlikely but surely the thought has occurred.>>
12197:
12198: All answers and pointers appreciated.
12199:
12200: Thanks,
12201: Walter Hamscher
12202:
12203: From shebs@utah-cs Wed Mar 20 17:27:57 1985
12204: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12205: id AA08685; Wed, 20 Mar 85 17:27:57 pst
12206: Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12207: id AA11992; Wed, 20 Mar 85 16:51:20 pst
12208: Received: by utah-cs.ARPA (4.42/4.40.2)
12209: id AA01825; Wed, 20 Mar 85 17:48:26 MST
12210: Date: Wed, 20 Mar 85 17:48:26 MST
12211: From: shebs@utah-cs (Stanley Shebs)
12212: Message-Id: <[email protected]>
12213: To: Franz-Friends@BERKELEY, [email protected]
12214: Subject: Re: Franz -> Common Lisp ?
12215:
12216: We have several versions of compatibility stuff for PSL (and it
12217: would work under Franz without much change). We're trying to
12218: get CL while retaining the speed of PSL, so we haven't yet
12219: embarked on a full standalone CL...
12220:
12221: stan shebs
12222:
12223: From [email protected] Thu Mar 21 11:05:39 1985
12224: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12225: id AA18463; Thu, 21 Mar 85 11:05:39 pst
12226: Received: from ucla-locus.arpa (ucla-locus.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12227: id AA12504; Thu, 21 Mar 85 10:37:45 pst
12228: Date: Thu, 21 Mar 85 10:35:28 PST
12229: From: Ingrid Zukerman <[email protected]>
12230: To: franz-friends@BERKELEY
12231: Subject: setq command changes code
12232: Message-Id: <[email protected]>
12233:
12234: I have the following problems:
12235: 1. After performing the command (setq x (list ... )), I noticed that
12236: the code in the function that initializes x was also changed to the
12237: new value. After consulting with my guru, he pointed out that this
12238: might be due to a sharing pattern I am not aware of, or to the way
12239: in which assignments are performed (e.g., by passing a pointer).
12240: I wasn't able to find this information, so my question is were I
12241: could find it in order to avoid such occurrences in the future. Of
12242: course, if somebody up there is terribly curious and wants to look
12243: at a transcript of the session, I'll be very appreciative.
12244: 2. The most updated copy we have of Franz is Opus 38.5. I hear that it
12245: is now Opus 38.91. What should I do in order to get an updated copy?
12246: Please don't advise me to contact the person in charge, because this
12247: person (who no longer wishes to be in charge) told me to contact you.
12248: Thanks very much.
12249: --Ingrid
12250:
12251: From franz!schlafly Mon Mar 25 18:03:33 1985
12252: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12253: id AA20019; Mon, 25 Mar 85 18:03:33 pst
12254: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
12255: id AA21825; Mon, 25 Mar 85 17:57:20 pst
12256: Received: by ucbkim.ARPA (4.24/4.27)
12257: id AA20010; Mon, 25 Mar 85 18:03:19 pst
12258: Received: by franz.uucp (1.2/3.14)
12259: id AA00961; Mon, 25 Mar 85 17:36:52 pst
12260: Date: Mon, 25 Mar 85 17:36:52 pst
12261: From: franz!schlafly (Roger Schlafly)
12262: Message-Id: <[email protected]>
12263: To: franz-friends@BERKELEY
12264: Subject: programs written in Franz Lisp
12265:
12266:
12267: I am compiling a list of expert systems and expert
12268: system building tools which are written in Franz Lisp.
12269:
12270: I would appreciate it if people would send me:
12271: (1) The name of each such program.
12272: (2) A brief description of what it does.
12273: (3) Whether it is available to the public.
12274: (4) An electronic address for obtaining more information.
12275:
12276: I will then make this list available to anyone who requests it.
12277:
12278: Roger Schlafly
12279: ucbvax!franz!schlafly
12280:
12281:
12282: From franz!schlafly Mon Mar 25 20:02:47 1985
12283: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12284: id AA21162; Mon, 25 Mar 85 20:02:47 pst
12285: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
12286: id AA23786; Mon, 25 Mar 85 19:56:37 pst
12287: Received: by ucbkim.ARPA (4.24/4.27)
12288: id AA21150; Mon, 25 Mar 85 20:02:36 pst
12289: Received: by franz.uucp (1.2/3.14)
12290: id AA01276; Mon, 25 Mar 85 19:37:31 pst
12291: Date: Mon, 25 Mar 85 19:37:31 pst
12292: From: franz!schlafly (Roger Schlafly)
12293: Message-Id: <[email protected]>
12294: To: franz-friends@BERKELEY
12295: Subject: programs written in Franz Lisp
12296:
12297:
12298: I am compiling a list of expert systems and expert
12299: system building tools which are written in Franz Lisp.
12300:
12301: I would appreciate it if people would send me:
12302: (1) The name of each such program.
12303: (2) A brief description of what it does.
12304: (3) Whether it is available to the public.
12305: (4) An electronic address for obtaining more information.
12306:
12307: I will then make this list available to anyone who requests it.
12308:
12309: Roger Schlafly
12310: ucbvax!franz!schlafly
12311:
12312:
12313: From carter%[email protected] Tue Mar 26 12:52:24 1985
12314: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12315: id AA00886; Tue, 26 Mar 85 12:52:24 pst
12316: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12317: id AA11893; Tue, 26 Mar 85 12:46:01 pst
12318: Received: from ubc by csnet-relay.csnet id a017378; 26 Mar 85 15:03 EST
12319: Received: from ubc-vision.UUCP by ubc.csnet id AA04906; Tue, 26 Mar 85 12:01:03 pst
12320: Date: Tue, 26 Mar 85 12:00:43 pst
12321: From: Alan Carter <carter%[email protected]>
12322: Message-Id: <[email protected]>
12323: Received: by ubc-vision.UUCP id AA09422; Tue, 26 Mar 85 12:00:43 pst
12324: To: franz-friends@BERKELEY
12325: Subject: Lisp interface to C functions
12326:
12327:
12328:
12329: Does anyone know if there is a problem with calling malloc and free from
12330: C functions which are called by Franz ?
12331:
12332:
12333: Alan Carter
12334: [email protected]
12335:
12336: From mcgeer Tue Mar 26 16:06:57 1985
12337: Received: by ucbkim.ARPA (4.24/4.27)
12338: id AA03620; Tue, 26 Mar 85 16:06:57 pst
12339: Date: Tue, 26 Mar 85 16:06:57 pst
12340: From: Rick McGeer (on an aaa-60-s) <mcgeer>
12341: Message-Id: <[email protected]>
12342: To: prolog@ernie, franz-friends
12343: Subject: Lisp is faster than Prolog?
12344: Cc:
12345:
12346: A number of articles in recent IEEE Spectra have discussed Silicon
12347: Compilation in Prolog, and concluded with a statement to the effect: for
12348: performance reasons, we will go to Lisp for a production version.
12349:
12350: Is Lisp really faster than Prolog? I used to think so. Some time
12351: ago, I wrote a Prolog interpreter in Lisp: after several versions, I gave
12352: up, because I couldn't make my Prolog fast. Its best speed was 100 LIPS
12353: through the append loop on a 780, or about 7% of the speed of C-Prolog (1500
12354: LIPS, according to the literature.
12355:
12356: Then it occured to me that I could not expect my Prolog to run
12357: faster than an equivalent function coded in Lisp. I coded the function, and
12358: the result was the following:
12359:
12360: (def my-append
12361: (lambda (x y)
12362: (cond (x (cons (car x) (my-append (cdr x) y)))
12363: (t y))))
12364:
12365: it can be seen that the time of the computation is invariant with respect to
12366: the second argument. Hence, for all the tests to be mentioned, the second
12367: argument is '(1 2 3 4 5).
12368:
12369: I ran the program on the lists consisting of the first 100, 250, and
12370: 300 integers. The results were the following:
12371:
12372: list length ticks (60/sec) LIPS equivalent
12373: 100 14 429
12374: 250 29 517
12375: 300 34 529
12376:
12377: Or about one-third the published speed of of the same function in CProlog on
12378: a 780. I then wondered how the native Franz append would do. This function
12379: is compiled, and is optimized for tail recursion, so the experiment is not
12380: really fair to CProlog. In any case:
12381:
12382: list length ticks LIPS equivalent
12383: 100 3 2000
12384: 250 8 1875
12385: 300 10 1800
12386:
12387: I don't know what this proves, but I know what it doesn't prove. The Lisp
12388: used, by the way, was Franz version 38.96 on a Vax 11/780 at the University
12389: of California at Berkeley. Despite numerous queries to Edinburgh, we still
12390: don't have a version of C-Prolog for comparative measurement here, so I
12391: can't personally vouch for the 1500 LIPS claim.
12392:
12393: Rick.
12394:
12395:
12396: From chris@maryland Tue Mar 26 16:18:52 1985
12397: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12398: id AA03876; Tue, 26 Mar 85 16:18:52 pst
12399: Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12400: id AA16580; Tue, 26 Mar 85 16:12:34 pst
12401: Received: by maryland.ARPA (4.12/4.7)
12402: id AA23203; Tue, 26 Mar 85 19:17:28 est
12403: Date: Tue, 26 Mar 85 19:17:28 est
12404: From: Chris Torek <chris@maryland>
12405: Message-Id: <[email protected]>
12406: To: carter%[email protected]
12407: Subject: Re: Lisp interface to C functions
12408: Cc: franz-friends@BERKELEY
12409:
12410: I believe that there were. In U of M Franz, we stuck in a version of
12411: malloc and free that uses the Lisp allocator to get unGCable memory,
12412: and a host of problems with the window library went away ... (the
12413: window library uses malloc & free quite, er, freely :-) ).
12414:
12415: Chris
12416:
12417: From narain@rand-unix Tue Mar 26 18:17:38 1985
12418: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12419: id AA06939; Tue, 26 Mar 85 18:17:38 pst
12420: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12421: id AA18369; Tue, 26 Mar 85 17:39:36 pst
12422: Received: by rand-unix.ARPA; Tue, 26 Mar 85 17:33:48 pst
12423: From: Sanjai Narain <narain@rand-unix>
12424: Message-Id: <[email protected]>
12425: Date: 26 Mar 85 17:33:41 PST (Tue)
12426: To: Rick McGeer <mcgeer@ucbkim>
12427: Cc: prolog@ernie, franz-friends@ucbkim, narain@rand-unix
12428: Subject: Re: Lisp is faster than Prolog?
12429: In-Reply-To: Your message of Tue, 26 Mar 85 16:06:57 pst.
12430: <[email protected]>
12431:
12432:
12433: Your first comparison of Prolog and Lisp is not very meaningful. You are
12434: comparing a Prolog implemented in Lisp with a Lisp implemented in C.
12435: Perhaps you could try to compare Lisp in Lisp with Prolog in Lisp.
12436:
12437: In a certain sense, your comparison of Franzlisp and C-Prolog infact
12438: indicates the superiority of C-Prolog. C-Prolog can be used to do append
12439: and all other functional programming at almost the speed of FranzLisp.
12440: However, in C-Prolog, you can do also do deduction, searching, pattern
12441: matching and a lot of other AI-stuff at the same speed. To do these in
12442: Franzlisp you must write Lisp functions and suffer the loss in speed
12443: associated with simulating functionality in a high-level language.
12444:
12445: -- Sanjai
12446:
12447: From mcgeer Tue Mar 26 18:30:58 1985
12448: Received: by ucbkim.ARPA (4.24/4.27)
12449: id AA07153; Tue, 26 Mar 85 18:30:58 pst
12450: Date: Tue, 26 Mar 85 18:30:58 pst
12451: From: Rick McGeer (on an aaa-60-s) <mcgeer>
12452: Message-Id: <[email protected]>
12453: To: narain@rand-unix
12454: Subject: Re: Lisp is faster than Prolog?
12455: Cc: narain@rand-unix, franz-friends, prolog@ernie
12456: In-Reply-To: Your message of 26 Mar 85 17:33:41 PST (Tue)
12457:
12458:
12459: You misunderstood my message. Prolog-in-Lisp really isn't under
12460: examination: the only reason I brought it up was that it provided the
12461: original motivation for the experiment (I wanted to determine a limit on the
12462: speed I could expect out of my Prolog, reasoning that it could not possibly
12463: be faster than native-coded Lisp.)
12464:
12465: The rest of your letter is essentially correct: the figures imply
12466: that CProlog is at least as fast as Franz, since the relevant test is
12467: interpreted code in each language (i.e., the first set of figures).
12468: However, this should not imply that I believe that Prolog is a "better"
12469: language than Lisp (I don't want to get into *that* debate), or imply
12470: that Lisp has no advantages over Prolog. Lisp may have real advantages over
12471: Prolog, but there is no reason to believe that speed is one of them.
12472:
12473: Rick.
12474:
12475:
12476: From hilfingr@ucbrenoir Wed Mar 27 01:06:00 1985
12477: Received: from ucbrenoir.ARPA by ucbkim.ARPA (4.24/4.27)
12478: id AA11390; Wed, 27 Mar 85 01:06:00 pst
12479: Received: by ucbrenoir.ARPA (4.24/4.42)
12480: id AA03594; Wed, 27 Mar 85 01:07:16 pst
12481: Date: Wed, 27 Mar 85 01:07:16 pst
12482: From: hilfingr@ucbrenoir (Paul Hilfinger)
12483: Message-Id: <[email protected]>
12484: To: mcgeer@ucbkim, narain@rand-unix
12485: Subject: Re: Lisp is faster than Prolog? A personal plea
12486: Cc: prolog@ernie, franz-friends@ucbkim
12487: In-Reply-To: Your message of 26 Mar 85 17:33:41PST
12488:
12489:
12490: Please, please, please stop trying to compare the performance of Lisp and
12491: Prolog by considering micro-benchmarks! Even in languages that are
12492: essentially "the same" (from my perspective as a semanticist/language
12493: designer or from the perspective of a Prolog programmer, FORTRAN, Pascal,
12494: Modula 2, and Ada are all the same); such benchmarks are imperfect guides.
12495: When comparing Lisp and Prolog, where the programs one might write to do a
12496: particular problem might be radically different in strategy, anything that
12497: compares the performance of tiny programs conveys almost no useful
12498: information.
12499:
12500: Please, please, please, PLEASE don't try to compare Prolog with Lisp (etc.)
12501: using LIPS as a part of the measure! In comparing Prolog implementations, I
12502: suppose LIPS might be of some interest, but when comparing Lisp with Prolog,
12503: they don't help at all. The reason is simple: if Lisp is not suited for
12504: doing logical inferences (in the Prolog sense) quickly, then the good Lisp
12505: programmer simply does not formulate his solution using logical inferences.
12506: (Patient: Doctor! Doctor! It hurts when I do this. Doctor: Well, then don't
12507: do that.) It's like saying that my APL implementation, which uses lazy
12508: evaluation and a bit of cleverness to compute
12509:
12510: +/ ,((iota n) o.= iota n) x A +.x B
12511:
12512: (the trace of the matrix product of nxn matrices A and B, I think) in time
12513: O(n^2) instead of O(n^3), is "faster" than my FORTRAN implementation, which
12514: requires time O(n^3) to do a direct transcription of this algorithm
12515: (actually forming the full matrix product).
12516:
12517: I think it wrong to say
12518:
12519: "To do [deduction, searching, pattern matching and other AI-stuff] in
12520: Franzlisp you must write Lisp functions and suffer the loss in speed
12521: associated with simulating functionality in a high-level language."
12522:
12523: because one DOESN'T use simulation if one wants speed, but instead goes
12524: after an entirely different kind of solution (I won't argue that this
12525: solution is "just as easy" as the Prolog solution; there are certainly many
12526: instances in which Prolog solutions are simpler, and I haven't the foggiest
12527: notion what the story is for large systems.)
12528:
12529: * * *
12530:
12531: Finally, a question. I was struck by Sanjai Narain's comment:
12532:
12533: "However, in C-Prolog, you can do also do deduction, searching,
12534: pattern matching and a lot of other AI-stuff at the same speed."
12535:
12536: I notice that the Prolog digest is full of interesting puzzles whose
12537: solution involves search. But are these representative? I think pattern
12538: matching is certainly a big part of any Prolog program, but do deduction and
12539: searching really form a big part of actual Prolog applications in practice?
12540:
12541: I recall an article by Drew McDermott called the "The Prolog Phenonmenon"
12542: that appeared (I think) in SIGArt at some point, maybe July '82. He asked
12543: why it was that Prolog had not died out, as had PLANNER, which also
12544: purported to support searching et al. He said some things on what he liked
12545: and disliked about Prolog, and then made the following comment (emphasis
12546: mine):
12547:
12548: "The Europeans went in a different direction [from the Americans
12549: in reaction to the problems of PLANNER-like languages]. What
12550: they liked best about logic was its variable-binding machinery.
12551: Their attitude towards backtracking has been simply that it is a
12552: programmer's duty to remember that his program will be executed
12553: backward as well as forward, that his programs must correct bad
12554: guesses as well as exploit good ones. If the backwards
12555: execution blows up, he must debug his program, not rewrite the
12556: interpreter [the American approach], just as with more prosaic
12557: kinds of infinite loops. Once this burden was shifted away
12558: from the language implementer and onto the programmer, the
12559: logical [!] next step was to freeze the interpreter design
12560: and make it as efficient as possible. THE RESULT IS A
12561: PROGRAMMING LANGUAGE, NOT A PROBLEM SOLVER OR THEOREM PROVER;
12562: it doesn't compete with NOAH, but with Lisp. And it's my
12563: impression that it competes pretty well.
12564:
12565: "The effect is to reverse the usual images of the American
12566: and European computer scientists. In this case, the Americans
12567: have pursued impractical theoretical studies, while the
12568: Europeans have bummed the hell out of a hack."
12569:
12570: (By "backward execution," he is referring to backtracking, I believe). To
12571: put this another way, one doesn't use Prolog's backtracking to do AI-style
12572: (i.e., very large) search, but rather to do very local and carefully-
12573: controlled "search," in the sense of "search this list (tree, ....) for an
12574: element equal to this one" or "try all permutations of this tiny set for one
12575: that satisfies P." Likewise, one doesn't use it to do what an AI
12576: investigator would call "deduction." One CAN convince the Prolog machinery
12577: to do more general AI-style searching efficiently, but only at the expense
12578: of vastly obscuring the original clear, simple, declarative form of the
12579: program.
12580:
12581: Not being a real Prolog hacker (yet) I don't really know how accurate this
12582: view is, and would appreciate some reaction (preferably semi-quantitative).
12583:
12584:
12585:
12586: From franz!jkf Wed Mar 27 08:03:25 1985
12587: Received: by ucbkim.ARPA (4.24/4.27)
12588: id AA13270; Wed, 27 Mar 85 08:03:25 pst
12589: Received: by franz.uucp (1.2/3.14)
12590: id AA06162; Wed, 27 Mar 85 07:59:36 pst
12591: Date: Wed, 27 Mar 85 07:59:36 pst
12592: From: franz!jkf (John Foderaro)
12593: Message-Id: <[email protected]>
12594: To: [email protected], [email protected], [email protected]
12595: Subject: Re: Lisp is faster than Prolog? A personal plea
12596: Cc: [email protected], prolog@ernie
12597: In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst
12598:
12599: While I find the discussion of Prolog vrs Lisp interesting, please do don't
12600: include franz-friends in on the discussion. When the mailing list has
12601: strayed off the topic of Franz Lisp in the past, I've gotten inundated with
12602: complaints. Thanks.
12603: John Foderaro
12604:
12605:
12606:
12607:
12608: From mcgeer Wed Mar 27 10:22:15 1985
12609: Received: by ucbkim.ARPA (4.24/4.27)
12610: id AA15354; Wed, 27 Mar 85 10:22:15 pst
12611: Date: Wed, 27 Mar 85 10:22:15 pst
12612: From: Rick McGeer (on an aaa-60-s) <mcgeer>
12613: Message-Id: <[email protected]>
12614: To: hilfingr@ucbrenoir, narain@rand-unix
12615: Subject: Re: Lisp is faster than Prolog? A personal plea
12616: Cc: franz-friends, prolog@ernie
12617: In-Reply-To: Your message of Wed, 27 Mar 85 01:07:16 pst
12618:
12619: Good point, Paul, but I think you're missing something. First you
12620: plead with us not to use micro-benchmarks, then you point out (correctly)
12621: that the strategy that one would use to write a program in Lisp instead of
12622: Prolog can often differ. I would think that the implication from the latter
12623: observation is that large programs are fundamentally incomparable, and I
12624: think that that is probably correct.
12625:
12626: So if you deny us micro-benchmarks, then we can not measure the
12627: relative performance of these languages at all (or, more precisely, the
12628: standard implementations of these languages on the 11/780). Hence we might
12629: as well accept the statements "Prolog is faster than Lisp" or "Lisp is faster
12630: than Prolog" or "Lisp is faster than assembler" as essentially meaningless
12631: statements, since we can't quantify any of them.
12632:
12633: Let me sputter out making one final point. LIPS is not all that
12634: bad a measure. Perhaps if we called it "cycles through the append loop" or
12635: "function calls per second" (essentially identical statements) I think most
12636: people would agree that this is a fair measure of the performance of any
12637: Lisp. After all, Lisp does nothing other than call functions and manipulate
12638: lists.
12639:
12640: I'm certainly not going to take issue with the rest of your letter,
12641: which is really more directed at Sanjai's claims than mine, and walks rather
12642: closer to debates on programming style than any sane man should dare to go.
12643:
12644:
12645: I remain, sir,
12646:
12647: Y'r obedient servant,
12648:
12649: Rick McGeer.
12650:
12651:
12652: From jeffr@sri-spam Fri Mar 29 16:22:50 1985
12653: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12654: id AA09984; Fri, 29 Mar 85 16:22:50 pst
12655: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12656: id AA04718; Fri, 29 Mar 85 16:16:10 pst
12657: Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
12658: id AA29100; Fri, 29 Mar 85 16:22:32 pst
12659: Message-Id: <[email protected]>
12660: Date: 29 Mar 85 16:22:30 PST (Fri)
12661: To: franz-friends@BERKELEY
12662: Subject: Problems Forking Around
12663: From: jeffr@sri-spam
12664:
12665: I am having problems getting child processes forked from Franz to exit
12666: cleanly. If I execute a simple forking function, such as
12667:
12668: (defun fork_test ()
12669: (prog (pid)
12670: (cond ((setq pid (fork)) (return pid)))
12671: (exit)
12672: ]
12673:
12674: from the Franz interpreter, a zombie process is created which doesn't exit
12675: until I exit the interpreter. The same result holds when fork_test is
12676: called from a compiled Franz daemon which is not associated with a tty.
12677:
12678: It's Friday and I'm out of ideas; any you have, even if only speculation,
12679: would be greatly appreciated.
12680:
12681: - Jeff Rininger
12682: SRI International
12683:
12684: From larus@ucbdali Fri Mar 29 16:50:22 1985
12685: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
12686: id AA10643; Fri, 29 Mar 85 16:50:22 pst
12687: Received: by ucbdali.ARPA (4.24/4.42)
12688: id AA04603; Fri, 29 Mar 85 16:50:11 pst
12689: Message-Id: <[email protected]>
12690: To: [email protected]
12691: Cc: franz-friends@ucbdali
12692: Subject: Re: Problems Forking Around
12693: In-Reply-To: Your message of 29 Mar 85 16:22:30 PST (Fri).
12694: <[email protected]>
12695: Date: 29 Mar 85 16:50:02 PST (Fri)
12696: From: larus@ucbdali
12697:
12698: This is a not-very-well-known bug/feature of Franz/Unix. Try adding a
12699: (wait) call in the main routine and the zombies will go away.
12700:
12701: /Jim
12702:
12703: From [email protected] Fri Mar 29 18:23:00 1985
12704: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12705: id AA11898; Fri, 29 Mar 85 18:23:00 pst
12706: Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12707: id AA07034; Fri, 29 Mar 85 18:16:19 pst
12708: Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA)
12709: by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1)
12710: id AA11566; Fri, 29 Mar 85 18:22:39 pst
12711: Received: by ucbruby.CC.Berkeley.ARPA (4.19/4.34.1)
12712: id AA10320; Fri, 29 Mar 85 18:21:53 pst
12713: Date: Fri, 29 Mar 85 18:21:53 pst
12714: From: [email protected] (Harry Weeks)
12715: Message-Id: <[email protected]>
12716: To: jeffr@sri-spam
12717: Subject: Re: Problems Forking Around
12718: Cc: franz-friends@BERKELEY
12719:
12720: It is a characteristic of Unix that processes do not really die
12721: until they are waited for. Your `zombie' process will not die
12722: until you (wait) for it. The (wait) function returns the dotted
12723: pair (pid . status). Thus the following examples will spawn
12724: children that immediately die.
12725: --Harry
12726:
12727: In simplest terms:
12728:
12729: (def beget
12730: (lambda nil
12731: (cond ((fork) (wait))
12732: (t (exit 0)))))
12733:
12734: In more realistic terms:
12735:
12736: (def beget
12737: (lambda nil
12738: (prog (child)
12739: (setq child (fork))
12740: (cond ((null child)
12741: ; child branch: (fork) evaluated to nil
12742: (exit 0))
12743: ((> child 0)
12744: ; parent branch: (fork) evaluated to pid
12745: (princ "Begot ")
12746: (princ child)
12747: (princ ".")
12748: (terpri)
12749: (return (beget:wait child)))
12750: ((< child 0)
12751: ; error branch
12752: (princ "Birth pain.")
12753: (terpri)
12754: (return child))
12755: (t
12756: ; impossible branch
12757: (princ "Impossible pain.")
12758: (terpri)
12759: (return -1))))))
12760: (def beget:wait
12761: (lambda (child)
12762: (prog (pvec)
12763: (setq pvec (wait))
12764: (cond ((= (car pvec) child)
12765: ; child we are waiting for died
12766: (return (cdr pvec)))
12767: ((< (car pvec) 0)
12768: ; error
12769: (princ "Wait error.")
12770: (terpri)
12771: (return (car pvec)))
12772: (t
12773: ; another child died, keep waiting for ours
12774: (return (beget:wait child)))))))
12775:
12776: From carter%[email protected] Tue Apr 2 16:48:37 1985
12777: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12778: id AA15047; Tue, 2 Apr 85 16:48:37 pst
12779: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12780: id AA26876; Tue, 2 Apr 85 16:48:19 pst
12781: Received: from ubc by csnet-relay.csnet id a008974; 2 Apr 85 19:35 EST
12782: Received: from ubc-vision.UUCP by ubc.csnet id AA06552; Tue, 2 Apr 85 16:28:06 pst
12783: Date: Tue, 2 Apr 85 16:27:59 pst
12784: From: Alan Carter <carter%[email protected]>
12785: Message-Id: <[email protected]>
12786: Received: by ubc-vision.UUCP id AA14795; Tue, 2 Apr 85 16:27:59 pst
12787: To: franz-friends@BERKELEY
12788: Subject: C interface
12789:
12790: Does anyone know if it is OK to call malloc and free from C functions
12791: called by lisp?
12792: -- Alan Carter
12793: [email protected]
12794:
12795: From dennis%[email protected] Wed Apr 3 19:05:09 1985
12796: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12797: id AA09023; Wed, 3 Apr 85 19:05:09 pst
12798: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12799: id AA24595; Wed, 3 Apr 85 19:04:50 pst
12800: Message-Id: <[email protected]>
12801: Received: from boulder by csnet-relay.csnet id af16243; 3 Apr 85 21:51 EST
12802: Received: by boulder.UCBOULDER (4.30/4.7)
12803: id AA10745; Wed, 3 Apr 85 09:58:09 mst
12804: Date: Wed, 3 Apr 85 09:58:09 mst
12805: From: Dennis Heimbigner <dennis%[email protected]>
12806: To: carter%[email protected], franz-friends@BERKELEY
12807: Subject: Re: C interface
12808:
12809: If I recall correctly, the pre-4.2 malloc did not appear to work
12810: with franz because it assumed that it had control
12811: of all of free memory. The malloc for 4.2 uses a buddy
12812: system and should not care if, for example, franz
12813: has pre-empted pieces of virtual memory for its own use.
12814: On the other side, franz only looks at the memory
12815: it gets from sbrk, so it doesn't care about malloc'd
12816: areas of virtual memory.
12817: .lp
12818: More to the point, I have been using malloc inside
12819: cfasl'd code and have not yet seen a problem.
12820:
12821: Dennis Heimbigner
12822: dennis.boulder@csnet-relay.
12823:
12824:
12825: From @seismo.ARPA:[email protected] Fri Apr 5 01:13:08 1985
12826: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12827: id AA27833; Fri, 5 Apr 85 01:13:08 pst
12828: Received: from seismo.ARPA (css-ring-gw.ARPA) by UCB-VAX.ARPA (4.24/4.42)
12829: id AA25779; Fri, 5 Apr 85 01:12:50 pst
12830: Return-Path: <[email protected]>
12831: Received: from prlb2.UUCP by seismo.ARPA with UUCP; Fri, 5 Apr 85 04:12:31 EST
12832: Received: by prlb2.UUCP (4.12/4.7)
12833: id AA01128; Fri, 5 Apr 85 10:36:51 -0200
12834: Date: Fri, 5 Apr 85 10:36:51 -0200
12835: From: [email protected] (Marc Vauclair)
12836: Message-Id: <[email protected]>
12837: To: franz-friends@BERKELEY
12838: Subject: Profiling options in Franz Lisp. Opus 38.91. UoM Var. 3.5.
12839:
12840: Does anyone know how to set up profiling in Franz Lisp ?
12841: We have Franz Lisp of University of Maryland : Opus 38.91, UoM Variation 3.5.
12842:
12843: I have already made the following modifications :
12844:
12845: 1) as stated in the makefile : ../franz/vax/Makefile I have removed the #
12846: in :
12847: ------------------------------------------------------------------------------
12848: ProfFlag = # -XP
12849: ProfFlag2 = # -DPROF
12850: ------------------------------------------------------------------------------
12851:
12852: giving :
12853:
12854: ------------------------------------------------------------------------------
12855: ProfFlag = -XP
12856: ProfFlag2 = -DPROF
12857: ------------------------------------------------------------------------------
12858:
12859: 2) I've changed in ../franz/vax/Makefile the line :
12860:
12861: ------------------------------------------------------------------------------
12862: /lib/cpp $< -I../h |\
12863: ------------------------------------------------------------------------------
12864:
12865: to :
12866:
12867: ------------------------------------------------------------------------------
12868: /lib/cpp ${ProfFlag2} $< -I../h |\
12869: ------------------------------------------------------------------------------
12870:
12871: 3) I've changed in ../franz/vax/Makefile/qfuncl.c the lines :
12872:
12873: ------------------------------------------------------------------------------
12874: #ifdef PROF
12875: .set indx,0
12876: #define Profile \
12877: movab prbuf+indx,r0 \
12878: .set indx,indx+4 \
12879: jsb mcount
12880: #define Profile2 \
12881: movl r0,r5 \
12882: Profile \
12883: movl r5,r0
12884: #else
12885: #define Profile
12886: #define Profile2
12887: #endif
12888: ------------------------------------------------------------------------------
12889:
12890: to :
12891:
12892: ------------------------------------------------------------------------------
12893: #ifdef PROF
12894: .set indx,0
12895: #define Profile \
12896: movab prbuf+indx,r0 ; \
12897: .set indx,indx+4 ; \
12898: jsb mcount
12899: #define Profile2 \
12900: movl r0,r5 ; \
12901: Profile ; \
12902: movl r5,r0
12903: #else
12904: #define Profile
12905: #define Profile2
12906: #endif
12907: ------------------------------------------------------------------------------
12908:
12909: After all these modifications, we have the following error message when
12910: making it slow :
12911:
12912: ------------------------------------------------------------------------------
12913: 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
12914:
12915:
12916: ../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
12917: mcount: ld:/lib/libc.a(mon.o): multiply defined
12918: *** Error code 2
12919:
12920: Stop.
12921: *** Error code 1
12922:
12923: Stop.
12924: ------------------------------------------------------------------------------
12925:
12926: From franz!schlafly Fri Apr 5 11:19:37 1985
12927: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
12928: id AA02221; Fri, 5 Apr 85 11:19:37 pst
12929: Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.42)
12930: id AA04091; Fri, 5 Apr 85 11:18:48 pst
12931: Received: by ucbkim.ARPA (4.24/4.27)
12932: id AA02177; Fri, 5 Apr 85 11:18:45 pst
12933: Received: by franz.uucp (1.2/3.14)
12934: id AA00261; Fri, 5 Apr 85 10:37:18 pst
12935: Date: Fri, 5 Apr 85 10:37:18 pst
12936: From: franz!schlafly (Roger Schlafly)
12937: Message-Id: <[email protected]>
12938: To: franz-friends@BERKELEY
12939: Subject: Franz Lisp applications
12940:
12941:
12942:
12943: Here is my list of Franz Lisp applications. Enough people
12944: requested copies that I am sending it to all franz-friends.
12945: If anyone sees any notable omissions, please send me a
12946: message and I will augment the list.
12947:
12948: Roger Schlafly
12949: ucbvax!franz!schlafly
12950:
12951: ============================================================
12952:
12953:
12954:
12955: AI and Expert System Tools and Applications
12956: Developed or Running under Franz Lisp
12957:
12958:
12959:
12960: + OPS-5
12961: A rule based environment for developing expert systems.
12962: Available from Franz Inc. with Franz LISP at no charge, or
12963: at no charge from Carnegie Mellon University.
12964:
12965: Computer Science Department, Carnegie Mellon University,
12966: Schenley Park, Pittsburgh PA 15213. (412) 578-2592
12967:
12968: + Flavors
12969: An object oriented extension of Lisp, developed at MIT and
12970: the University of Maryland. Used on the Symbolics Lisp
12971: machines. Available from Franz Inc. at no charge to pur-
12972: chasers of Franz Lisp.
12973:
12974: + DUCK
12975: DUCK is an expert systems development environment.
12976:
12977: Available from Smart Systems Technology, 6870 Elm St.
12978: McLean, VA. 22101 (703) 448-8562.
12979:
12980: + Boyer-Moore Theorem Prover
12981: Available from Prof. Robert Boyer, University of Texas, Aus-
12982: tin. Computer Science Department, 3-28 Painter Hall,
12983: University of Texas, Austin, Texas 78712. (512) 471-7316
12984:
12985: + GLISP
12986: GLISP is a high-level language which is based on Lisp and is
12987: compiled into Lisp. It was developed at the University of
12988: Texas at Austin by Prof. Gordon Novak. Object-centered pro-
12989: gramming is supported. Message interpretations can be
12990: looked up at compile time to produce efficient code. A
12991: window-based editor, GEV, is available to inspect and edit
12992: data according to its data structure description. GLISP is
12993: available from Franz Inc. at no charge to purchasers of
12994: Franz Lisp, or from the University of Texas at Austin, Prof.
12995: Gordon Novak, Computer Science Department, 3-28 Painter
12996: Hall, University of Texas, Austin, Texas 78712. (512) 471-
12997: 7316
12998:
12999: + FRL
13000: A frame representation language for AI development.
13001:
13002: Available from Steven Rosenberg, Hewlett Packard (415) 857
13003: 5902
13004:
13005: + MRS
13006: A logic based knowledge representation system. Available
13007: from Stanford University.
13008:
13009: Attention: Pattie McCabe SUMEX Computing Facility, Stanford
13010: University Medical Center, Room TB105, Stanford, California
13011: 94305, (415) 497-5141
13012:
13013: + Macsyma
13014: Developed at MIT, Macsyma is a program that carries out sym-
13015: bolic computation. It will solve all those integrals you
13016: learned about in your calculus class, as well as systems of
13017: differential equations and other mathematical problems.
13018:
13019: + Reduce
13020: Reduce is similar to Macsyma. It was developed at the
13021: University of Utah. Computer Science Department, 3160 Mer-
13022: rill Engineering Bldg. Salt Lake City, Utah 84112. (801)
13023: 484-7651 Ext 205
13024:
13025: + XCON
13026: Digital Equipment's famous expert system, written in OPS-5,
13027: originally ran on top of Franz Lisp. XCON configures com-
13028: puters before shipment.
13029:
13030: + ACE
13031: Automatic Cable Expertise : A knowledge based expert system
13032: that provides trouble-shooting and diagnostic reports for
13033: telephone company managers. Developed by Stolfo, Vesonder
13034: and others at AT&T Bell Labs. For details see "The Fifth
13035: Generation Challenge" Proceedings ACM '84 Annual Conference.
13036:
13037: + Slang
13038: A circuit design and analysis tool. It has been used to
13039: design several integrated circuits at U.C. Berkeley. A
13040: detailed description is in the masters thesis of Korbin Van
13041: Dyke at U.C. Berkeley.
13042:
13043: Available from: Industrial Liason Program, EECS Department,
13044: University of California, Berkeley CA 94720 (415) 642-0253
13045:
13046: + Lyra
13047: A VLSI design rule checker. A description is in the masters
13048: thesis of Michael Arnold at U.C. Berkeley.
13049:
13050: + Pearl
13051: A database and AI representation language written in Franz
13052: Lisp. Available from Franz Inc. at no charge to purchasers
13053: of Franz Lisp.
13054:
13055: + YAPS
13056: Yet Another Production System. Developed by Liz Allen at
13057: the University of Maryland. A forward driven production
13058: rule system similar to OPS-5, but with added flexibility.
13059: YAPS supports objects in facts, and defines an object that
13060: is a complete production system, so you can have more than
13061: one expert around at a time. See "YAPS: A Production System
13062: Meets Object" by Liz Allen in AAAI-83 for more information.
13063: YAPS is available at nominal cost from the Universtiy of
13064: Maryland. The license fee is $100 for BSD 4.1, $250 for
13065: 4.2. It's also Arpanet FTP'able for $100 for either ver-
13066: sion. Contact Bob Bane on Arpanet at bane@maryland or on
13067: Usenet at ...seismo!umcp-cs!bane or contact Liz Allen at
13068: [email protected] or seismo!umcp-cs!liz .
13069:
13070: + GENIE
13071: GENeric Inference Engine. An expert system development
13072: tool. Written by John Dumer, Tim Hanratty, Paul Tanenbaum,
13073: and Fred S. Brundick. For more information contact: Fred S.
13074: Brundick,
13075:
13076: + The Berkeley UNIX Consultant
13077: An expert System incorporating a natural language interface
13078: which answers questions about UNIX. Under development at
13079: U.C. Berkeley. USABRL, APG, MD. <fsbrn@brl-voc>
13080:
13081: + ROSS and SWIRL
13082: ROSS is an object-oriented language developed for building
13083: knowledge based simulations. SWIRL is a program written in
13084: ROSS that embeds knowledge about defensive and offensive air
13085: battle strategies. Developed by Narain, McArthur and Klahr
13086: at The Rand Corporation, 1700 Main Street, Santa Monica CA
13087: 90406. These systems were implemented in various LISP
13088: environments including Franz LISP. A comparison of hte
13089: various environments in terms of CPU usage, real-time usage
13090: and user aids can be found in an article by the above in the
13091: proceedings of the 1983 International Joint Conference on
13092: Artificial Intelligence, Karlsruhe, W. Germany.
13093:
13094: From liz@tove Sat Apr 6 09:35:22 1985
13095: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13096: id AA13697; Sat, 6 Apr 85 09:35:22 pst
13097: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.42)
13098: id AA24792; Sat, 6 Apr 85 09:35:09 pst
13099: Received: by tove.ARPA (4.12/4.7)
13100: id AA10092; Sat, 6 Apr 85 12:36:17 est
13101: Message-Id: <[email protected]>
13102: To: franz!schlafly@BERKELEY (Roger Schlafly)
13103: Cc: franz-friends@BERKELEY
13104: Subject: Re: Franz Lisp applications
13105: In-Reply-To: Your message of Fri, 5 Apr 85 10:37:18 pst.
13106: <[email protected]>
13107: Date: 06 Apr 85 12:36:04 EST (Sat)
13108: From: Liz Allen <liz@tove>
13109:
13110: A correction to one of the entries.
13111:
13112: From: franz!schlafly@Berkeley (Roger Schlafly)
13113:
13114: + Flavors
13115: An object oriented extension of Lisp, developed at MIT and
13116: the University of Maryland. Used on the Symbolics Lisp
13117: machines. Available from Franz Inc. at no charge to pur-
13118: chasers of Franz Lisp.
13119:
13120: Actually, there are two implmentations of flavors available for
13121: Franz; one written at MIT and the other at Univ of Maryland. Franz
13122: Inc distributes the one from MIT and we (at UofM) distribute our
13123: version as part of the Maryland software distribution (which includes
13124: Franz 38.91). For more information about getting our distribution,
13125: contact Bob Bane [email protected] or seismo!umcp-cs!bane.
13126:
13127: -Liz
13128:
13129:
13130: From wfi%[email protected] Tue Apr 9 02:28:37 1985
13131: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13132: id AA07208; Tue, 9 Apr 85 02:28:37 pst
13133: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13134: id AA14376; Tue, 9 Apr 85 02:27:14 pst
13135: Message-Id: <[email protected]>
13136: Received: from ucsc by csnet-relay.csnet id ad14837; 9 Apr 85 5:28 EST
13137: Received: by vger.UCSC (4.12/4.7)
13138: id AA27515; Mon, 8 Apr 85 14:09:04 pst
13139: Date: Mon, 8 Apr 85 14:09:04 pst
13140: From: wfi <@csnet-relay.arpa,@ucsc.CSNET:[email protected] (Wayne F. Iba)>
13141: To: franz-friends@BERKELEY
13142: Subject: franz profiling
13143: Cc: [email protected]
13144:
13145:
13146: There is a short note in the documentation of liszt that "if the lisp
13147: system is built with profiling", then using the -p option will allow
13148: use of the UNIX prof command etc.
13149:
13150: Can someone explain how to rebuild (if necessary) our lisp system
13151: accordingly?
13152:
13153: Thanks
13154: --wayne (wfi%ucsc.csnet)
13155:
13156:
13157: From klahr@rand-unix Tue Apr 9 10:03:37 1985
13158: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13159: id AA09758; Tue, 9 Apr 85 10:03:37 pst
13160: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13161: id AA20618; Tue, 9 Apr 85 10:02:11 pst
13162: Received: by rand-unix.ARPA; Tue, 9 Apr 85 09:41:46 pst
13163: From: Phil Klahr <klahr@rand-unix>
13164: Message-Id: <[email protected]>
13165: Date: 09 Apr 85 09:41:40 PST (Tue)
13166: To: FRANZ-FRIENDS@BERKELEY
13167: Cc: randvax!klahr
13168: Subject: IJCAI-85 Registration -- Please post
13169:
13170:
13171: The International Joint Conference on Artificial Intelligence will be
13172: meeting in Los Angeles (at UCLA) August 18-23, 1985. Conference
13173: brochures (including registration information) have already been mailed
13174: out. If you have not received one, or would like extras, contact
13175:
13176: IJCAI-85
13177: c/o AAAI
13178: 445 Burgess Drive
13179: Menlo Park, CA 94025
13180: 415-328-3123 or 415-321-1118
13181:
13182: Registration will be limited to 5,000 people. Based on early projections,
13183: up to 7,000 people may wish to attend, so early registration is highly
13184: encouraged (if not necessary).
13185:
13186: As a bonus, early registrants will receive a substantial reduction in
13187: registration costs. Through June 28, registration fees are $175 ($80 for
13188: students); for registrations received after June 28 but prior to July 26,
13189: fees will be $225 ($100 for students); and for on-site registration (if
13190: available), fees will be $275 ($125 for students). Substantial reductions
13191: for early tutorial registrations are also in effect.
13192:
13193: Further information on the technical conference, the tutorials, the
13194: exhibition, and housing can be found in the conference brochure.
13195:
13196: From jeffr@sri-spam Tue Apr 9 16:38:17 1985
13197: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13198: id AA00472; Tue, 9 Apr 85 16:38:17 pst
13199: Received: from sri-spam.ARPA (sri-spam.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13200: id AA29765; Tue, 9 Apr 85 16:36:41 pst
13201: Received: by sri-spam.ARPA (4.22/4.16)
13202: id AA05175; Tue, 9 Apr 85 16:37:20 pst
13203: Date: Tue, 9 Apr 85 16:37:20 pst
13204: From: jeffr@sri-spam (Jeff Rininger)
13205: Message-Id: <[email protected]>
13206: To: franz-friends@BERKELEY
13207:
13208: Does anyone know of (or have) a Franz function that returns a character
13209: corresponding to a given fixnum representation, but without the pesky
13210: symbol delimiters that `ascii' returns ?
13211:
13212: From g_keaton%[email protected] Sat Apr 13 23:33:19 1985
13213: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13214: id AA22504; Sat, 13 Apr 85 23:33:19 pst
13215: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13216: id AA13927; Sat, 13 Apr 85 23:32:05 pst
13217: Message-Id: <[email protected]>
13218: Received: from scarolina by csnet-relay.csnet id a013785; 14 Apr 85 2:36 EST
13219: Date: Fri, 12 Apr 85 13:01 EST
13220: From: Bonnell <g_keaton%[email protected]>
13221: To: FRANZ-FRIENDS@BERKELEY
13222: Subject: Problems with *process.
13223:
13224: I am attempting to have a Lisp process talk to a C process using
13225: Lisp's *process function. This function works fine with system commands
13226: such as 'ls' but fails when the C process is a typical user program.
13227: I hope someone has run into similar difficulties and can provide some
13228: enlightenment. We are using a set Sun workstations running Berkley Unix.
13229: The same problem also occurs on our VAX.
13230:
13231: Thanks,
13232: Gar Keaton
13233:
13234: From narain@rand-unix Mon Apr 15 11:33:17 1985
13235: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13236: id AA08082; Mon, 15 Apr 85 11:33:17 pst
13237: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13238: id AA08871; Mon, 15 Apr 85 11:31:51 pst
13239: Received: by rand-unix.ARPA; Mon, 15 Apr 85 11:29:44 pst
13240: From: Sanjai Narain <narain@rand-unix>
13241: Message-Id: <[email protected]>
13242: Date: 15 Apr 85 11:29:40 PST (Mon)
13243: To: Bonnell <g_keaton%[email protected]>
13244: Cc: FRANZ-FRIENDS@BERKELEY, narain@rand-unix
13245: Subject: Re: Problems with *process.
13246: In-Reply-To: Your message of Fri, 12 Apr 85 13:01 EST.
13247: <[email protected]>
13248:
13249:
13250: I once set up a link between Franzlisp and C-Prolog using process instead of
13251: *process and it worked fine. It was on Vax 11/780, but it was most probably
13252: on an earlier version of Unix, rather than 4.2bsd.
13253:
13254: -- Sanjai Narain
13255:
13256: From chin@ucbdali Sat Apr 20 11:50:19 1985
13257: Received: from ucbdali.ARPA by ucbkim.ARPA (4.24/4.27)
13258: id AA03799; Sat, 20 Apr 85 11:50:19 pst
13259: Received: by ucbdali.ARPA (4.24/4.45)
13260: id AA08585; Sat, 20 Apr 85 11:50:12 pst
13261: Date: Sat, 20 Apr 85 11:50:12 pst
13262: From: chin@ucbdali (David N. Chin)
13263: Message-Id: <[email protected]>
13264: To: franz-friends@ucbdali
13265: Subject: profiling
13266:
13267: Does anyone have a profiling package for FRANZ that provides execution
13268: time statistics? The prof.l package in the lisplib only provides call
13269: frequency statistics, and the liszt -p option only works if lisp was
13270: created with profiling (not to mention that you would have to recompile
13271: all your code to use it).
13272:
13273: Thanks in advance,
13274: David Chin
13275: chin@BERKELEY
13276: ucbvax!chin
13277:
13278: From [email protected] Sun Apr 21 14:13:02 1985
13279: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27)
13280: id AA17063; Sun, 21 Apr 85 14:13:02 pst
13281: Received: from mit-eddie.ARPA (mit-eddie.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.45)
13282: id AA03920; Sun, 21 Apr 85 14:11:39 pst
13283: Received: by mit-eddie.ARPA (4.12/4.8) id AA03273; Sun, 21 Apr 85 17:11:05 est
13284: Date: Sun, 21 Apr 85 17:11:05 est
13285: From: Steven M. Haflich <[email protected]>
13286: Message-Id: <[email protected]>
13287: To: franz-friends@BERKELEY
13288: Subject: Gnu EMACS customization for Lisp
13289:
13290: Lisp hackers who use Gnu EMACS might want to try this useful
13291: customization. It emulates the standard keybinding of CCA EMACS
13292: that makes C-Z (i.e. control-Z) a prefix which both CONTROL- and
13293: META-izes to the following keystroke. This is particularly useful
13294: for Lisp because most of the special Lisp editing commands are bound
13295: to ESC CONTROL characters.
13296:
13297: This text can be placed in the personal .emacs file in your home
13298: directory. The suspend-emacs function previously run by C-Z is
13299: still available as either C-X C-Z or C-Z C-Z .
13300:
13301: But first: The two "^Z" strings in the text below have been sanitized
13302: to pass through mailers and, as mailed, contain a two character
13303: sequence representing CONTROL-Z to humans. You will have to edit
13304: them to contain the single literal character C-Z, which can be typed
13305: in EMACS via the two-keystroke sequence: C-Q C-Z .
13306:
13307: ======================================
13308: (defun c-m-prefix ()
13309: "Apply both META and CONTROL to the next command character"
13310: (interactive)
13311: (command-execute
13312: (lookup-key esc-map (char-to-string (logand 31 (read-char))))))
13313:
13314: (define-key global-map "^Z" 'c-m-prefix)
13315: (define-key esc-map "^Z" 'suspend-emacs)
13316:
13317: From @MIT-MC:[email protected] Tue Apr 23 17:48:24 1985
13318: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13319: id AA18909; Tue, 23 Apr 85 17:48:24 pst
13320: Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13321: id AA10636; Tue, 23 Apr 85 17:46:11 pst
13322: Message-Id: <[email protected]>
13323: Received: from CMU-CS-IUS.ARPA by MIT-MC.ARPA; 22 APR 85 12:13:41 EST
13324: Date: 22 Apr 85 12:05:53 EST
13325: From: Wilson.Harvey@CMU-CS-IUS
13326: Subject: #ifdef for liszt?
13327: To: BBoard.Maintainer@CMU-CS-A
13328:
13329:
13330: Is there anything for the lisp compiler akin to the "#ifdef" statement
13331: for the C compiler? Can anyone point me to something similar?
13332: Thanks. -- Wilson
13333:
13334:
13335:
13336: From liz@tove Wed Apr 24 12:02:32 1985
13337: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13338: id AA01778; Wed, 24 Apr 85 12:02:32 pst
13339: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13340: id AA02711; Wed, 24 Apr 85 12:00:04 pst
13341: Received: by tove.ARPA (4.12/4.7)
13342: id AA15012; Wed, 24 Apr 85 15:00:27 est
13343: Message-Id: <[email protected]>
13344: To: Wilson.Harvey@cmu-cs-ius
13345: Cc: franz-friends@BERKELEY
13346: Subject: Re: #ifdef for liszt?
13347: In-Reply-To: Your message of 22 Apr 85 12:05:53 EST.
13348: <[email protected]>
13349: Date: 24 Apr 85 15:00:16 EST (Wed)
13350: From: Liz Allen <liz@tove>
13351:
13352: From: Wilson.Harvey@CMU-CS-IUS
13353:
13354: Is there anything for the lisp compiler akin to the "#ifdef" statement
13355: for the C compiler? Can anyone point me to something similar?
13356: Thanks. -- Wilson
13357:
13358: The reader has built into it a switch that works in both liszt and
13359: lisp. You can tell lisp whether or not to read an expression by
13360: putting before that expression something like:
13361:
13362: #+feature
13363: #-feature
13364: #+(or feature ...)
13365: #+(and feature ...)
13366:
13367: where feature is on iff it is on the "(status features)" list (which
13368: can be modified). Thus you can do something like this:
13369:
13370: #-uomlisp (defun morerecent (file1 file2) ...)
13371:
13372: since uomlisp is turned only in Franz's that contain all our hacks and
13373: morerecent happens to already be defined in our stuff. If you look at
13374: the liszt code, you'll see lots of "#+vax"'s and "#+68k"'s where the
13375: code needs to be different, eg:
13376:
13377: (defun cc-foo (x y z)
13378: (bar #+vax vax-arg
13379: #+68k 68k-arg)
13380: ...)
13381:
13382: It can be quite convenient especially when you have two lisps that are
13383: almost the same, you can maintain just one source containing these
13384: things whenever the sources for the different lisps must be different.
13385:
13386: I know this stuff is documented in the code in charmac.l; I can't
13387: remember right now if it is documented in the Franz reference manual
13388: and I don't have it with me right now to check.
13389:
13390:
13391: Hope this helps.
13392:
13393: -Liz
13394:
13395: From jaffe@CMU-PSY-A Mon Jun 17 13:57:45 1985
13396: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13397: id AA01719; Mon, 17 Jun 85 13:57:45 pdt
13398: Received: from CMU-PSY-A (cmu-psy-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13399: id AA25593; Mon, 17 Jun 85 13:54:08 pdt
13400: Message-Id: <[email protected]>
13401: Date: Monday, 17 Jun 85 16:50:28 EDT
13402: From: jaffe@cmu-psy-a (elliot jaffe)
13403: Subject: Cursor Package?
13404: To: franz-friends@BERKELEY
13405:
13406: Does anyone out there have a working cursor package for franz lisp?
13407:
13408: I know that the franz distribution at one time came with such a package,
13409: but the version that I have does not work. For some reason, a function
13410: called "ospeed" is defined both in franz and in curses.
13411:
13412: I am working on a VMS machine with version 38.91. I've also got franz on
13413: a Sun workstation (version 41.?) but both franzs have the same problem.
13414:
13415: Any help with a cursor package or pointers to such a package would be
13416: greatly appreciated.
13417:
13418: Replies to: [email protected]
13419:
13420: Thanks,
13421: Elliot Jaffe.
13422:
13423: From cornwell@nrl-css Fri Jun 21 09:04:54 1985
13424: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13425: id AA13519; Fri, 21 Jun 85 09:04:54 pdt
13426: Received: from nrl-css (nrl-css.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13427: id AA18873; Fri, 21 Jun 85 09:00:48 pdt
13428: Date: Wed, 19 Jun 85 13:47:52 edt
13429: From: Mark Cornwell <cornwell@nrl-css>
13430: Message-Id: <8506191747.AA09210@nrl-css>
13431: To: [email protected]
13432: Subject: Cursor Package!
13433: Cc: franz-friends@BERKELEY
13434:
13435:
13436: We've been using Jim Larus's franz lisp interface to the Berkeley curses
13437: package for several years. It works fine under UNIX 4.2bsd with
13438: franz 38.91. I recall some twiddling with ospeed a long time back to
13439: make it go. If you are interested I can send you our sources and the
13440: makefile.
13441:
13442: Alan Bull of NRL has put together an emulation of the the curses package
13443: to help us port programs from franz to a symbolics.
13444:
13445: Mark Cornwell
13446: cornwell@nrl-css
13447:
13448: From greep@rand-unix Fri Jun 21 14:35:37 1985
13449: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13450: id AA17578; Fri, 21 Jun 85 14:35:37 pdt
13451: Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13452: id AA24632; Fri, 21 Jun 85 14:31:34 pdt
13453: Received: by rand-unix.ARPA; Wed, 19 Jun 85 23:10:38 pdt
13454: From: Steve Tepper <greep@rand-unix>
13455: Message-Id: <[email protected]>
13456: Date: 19 Jun 85 23:10:20 PDT (Wed)
13457: To: jaffe@cmu-psy-a
13458: Cc: franz-friends@BERKELEY, greep@rand-unix
13459: Subject: Re: Cursor Package?
13460: In-Reply-To: Your message of Monday, 17 Jun 85 16:50:28 EDT.
13461: <[email protected]>
13462:
13463: Just a few days ago I started hacking up a script to convert the
13464: names of the Berkeley curses routines into appropriate cfasl
13465: and getaddress routines for Franz. I also had to hack the
13466: library to change the name "ospeed", as you pointed out --
13467: I did this by modifying the binary (shudder) rather than
13468: recompiling. I just started playing with it so I don't know
13469: if everything works right. One thing I noticed is that in some
13470: cases lisp will hang if one of these functions is called with
13471: the wrong number of arguments. Since there doesn't appear to
13472: be any way of telling lisp how many arguments your C function
13473: takes, you have to be careful.
13474:
13475: Anyway, I'll send it to you in a separate message.
13476:
13477: From peck@sri-spam Mon Jun 24 16:17:46 1985
13478: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13479: id AA12734; Mon, 24 Jun 85 16:17:46 pdt
13480: Received: from sri-spam.ARPA (sri-spam-test.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.46)
13481: id AA04274; Mon, 24 Jun 85 16:13:12 pdt
13482: Received: from localhost by sri-spam.ARPA (5.4/4.16)
13483: id AA11802; Mon, 24 Jun 85 16:15:22 PDT
13484: Message-Id: <[email protected]>
13485: Date: 24 Jun 85 16:15:18 PDT (Mon)
13486: To: franz-friends@BERKELEY
13487: Cc: peck@sri-spam
13488: Subject: Sun Graphics and external data structures
13489: From: Jeff Peck <peck@sri-spam>
13490:
13491: I would like to here from any people who have found a solution
13492: either of the following problems:
13493:
13494: 1) Interfacing with Sun graphics, either SunCore or preferably,
13495: at the Pixwind/Pixrect level. The main problem is that the interface
13496: that sun provides is in terms of C header files defining C "structs".
13497: So a related solution would be:
13498:
13499: 2) A package to allow franz programs to manipulate external structures.
13500: That is, the ability to follow pointers and write into memory that was
13501: not allocated by franz. I can use vectori to create blocks with one can
13502: pass TO a C-program, but when the system returns a pointer to a
13503: structure, franz just see a fixnum and will not treat it as a pointer.
13504: Has anyone extented/subverted the datatyping in franz to allow treating
13505: arbitrary pointers as for example, hunks?
13506:
13507: I will probably attempt to solve these problems, so ANY help or
13508: collaboration will be greatly appreciated.
13509:
13510: j. peck
13511:
13512: From bane@gymble Thu Jun 27 17:03:26 1985
13513: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13514: id AA25488; Thu, 27 Jun 85 17:03:26 pdt
13515: Received: from gymble.ARPA (gymble.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
13516: id AA01585; Thu, 27 Jun 85 13:25:03 pdt
13517: Received: by gymble.ARPA (4.12/4.7)
13518: id AA08257; Thu, 27 Jun 85 16:21:37 edt
13519: Date: Thu, 27 Jun 85 16:21:37 edt
13520: From: John R. Bane <bane@gymble>
13521: Message-Id: <[email protected]>
13522: To: franz-friends@BERKELEY
13523: Subject: Franz-f77 strange I/O?
13524:
13525: A company I'm doing some consulting for wants to use Franz to
13526: drive a Ramtek color display whose graphics routines are written in
13527: Fortran, so they're calling the display routines as foreign functions.
13528: The problem they've been having is this: the output these routines should
13529: generate is going into a file named something like "fort6" instead of to
13530: standard out, and that file's buffers don't flush correctly. Anybody
13531: know what's going on here?
13532: - Bob Bane
13533: (bane@maryland, ...umcp-cs!bane)
13534:
13535: From boyle@anl-mcs Sun Jun 30 19:11:39 1985
13536: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.46)
13537: id AA11920; Sun, 30 Jun 85 19:11:39 pdt
13538: Received: from anl-mcs.ARPA (anl-mcs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
13539: id AA06306; Sun, 30 Jun 85 19:07:20 pdt
13540: Return-Path: <boyle@anl-mcs>
13541: Received: by anl-mcs.ARPA ; Sun, 30 Jun 85 21:11:49 cdt
13542: Date: Sun, 30 Jun 85 21:11:49 cdt
13543: From: boyle@anl-mcs (James M. Boyle)
13544: Message-Id: <[email protected]>
13545: To: [email protected], franz-friends@BERKELEY
13546: Subject: Re: Franz-f77 strange I/O?
13547: Cc: boyle@anl-mcs
13548:
13549: I have seen this problem also. In version 38.44 of Franz, the fortran
13550: output came to standard output, along with that from Lisp. The change
13551: occurred somewhere between version 38.44 and 38.69 or there abouts.
13552: I, too, would kile to know of a fix. It was much better to get the
13553: output on the standard output.
13554:
13555:
13556: From peck@sri-spam Wed Jul 3 15:48:58 1985
13557: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13558: id AA07336; Wed, 3 Jul 85 15:48:58 pdt
13559: Received: from sri-spam.ARPA (sri-spam-test.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
13560: id AA00157; Wed, 3 Jul 85 15:44:06 pdt
13561: Received: from localhost by sri-spam.ARPA (5.4/4.16)
13562: id AA08158; Wed, 3 Jul 85 15:45:45 PDT
13563: Message-Id: <[email protected]>
13564: Date: 03 Jul 85 15:45:42 PDT (Wed)
13565: To: franz-friends@BERKELEY
13566: Subject: "nil" on the sun implementation
13567: From: Jeff Peck <peck@sri-spam>
13568:
13569: On the vax, the location of nil is linked to be location zero
13570: (ie (maknum nil) => 0).
13571: On the sun, the location of nil comes out as 32768
13572: This is true on both v38.91 and v40.03a
13573: Problems i have noticed because of this include are:
13574: 1. some C routines that check for nil shortcut with a zero check
13575: this works on the vax but fails on the sun.
13576: 2. (array ...) and by extension, other storage requests, on the
13577: vax return an array of nil (zero), but on the sun, zero is
13578: a pointer to unknown space, and causes errors.
13579: (array name ...) needs to be followed by (fillarray 'name '(nil))
13580: to have an effect similar to that on the vax.
13581:
13582: Questions: Is this particular to the way I am installing these programs?
13583: (ie, does (maknum nil) return zero on your sun?)
13584:
13585: Is this going to be changed? Has it been changed?
13586: Will (segment) or (small-segment) be modified to return storage
13587: initialized to nil?
13588:
13589: Will someone at FranzInc tell me if this is fixed in current releases?
13590:
13591: J. Peck
13592:
13593: From schlimme@uci-icse Mon Jul 8 10:03:43 1985
13594: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13595: id AA20308; Mon, 8 Jul 85 10:03:43 pdt
13596: Received: from UCI-ICSE (uci-icse.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.48)
13597: id AA03142; Mon, 8 Jul 85 09:58:53 pdt
13598: Message-Id: <[email protected]>
13599: To: franz-friends@BERKELEY
13600: Cc: schlimmer@uci-icse, arango@uci-icse
13601: Subject: Namestack Overflow
13602: Date: 08 Jul 85 10:02:13 PDT (Mon)
13603: From: Jeff Schlimmer <schlimme@uci-icse>
13604: Received: from Localhost by UCI-ICSE; 08 Jul 85 10:02:27 PDT (Mon)
13605:
13606: Several of the graduate students here at UCI are working on a large
13607: Franz Lisp program which requires several hundred levels of recursion.
13608: This causes a namestack overflow error in Franz. Is there a way to
13609: expand the size of the namestack?
13610:
13611: --Jeff Schlimmer
13612: --Guillermo Arango
13613:
13614: From liz@tove Tue Jul 9 08:46:46 1985
13615: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13616: id AA00559; Tue, 9 Jul 85 08:46:46 pdt
13617: Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
13618: id AA09926; Tue, 9 Jul 85 07:46:38 pdt
13619: Received: by tove.ARPA (4.12/4.7)
13620: id AA02537; Tue, 9 Jul 85 10:49:16 edt
13621: Message-Id: <[email protected]>
13622: To: Jeff Schlimmer <schlimme@uci-icse>
13623: Cc: franz-friends@BERKELEY, arango@uci-icse
13624: Subject: Re: Namestack Overflow
13625: In-Reply-To: Your message of 08 Jul 85 10:02:13 PDT (Mon).
13626: <[email protected]>
13627: Date: 09 Jul 85 10:48:56 EDT (Tue)
13628: From: Liz Allen <liz@tove>
13629:
13630: From: Jeff Schlimmer <schlimme@uci-icse>
13631:
13632: Several of the graduate students here at UCI are
13633: working on a large Franz Lisp program which requires
13634: several hundred levels of recursion. This causes a
13635: namestack overflow error in Franz. Is there a way to
13636: expand the size of the namestack?
13637:
13638: Yes, there is. In ../franz/h/global.h, there is a #define for
13639: NAMESIZE which is the size of the name stack. It can be changed
13640: to something larger.
13641:
13642: -Liz
13643:
13644: From boyle@anl-mcs Tue Jul 9 09:29:07 1985
13645: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13646: id AA01193; Tue, 9 Jul 85 09:29:07 pdt
13647: Received: from anl-mcs.ARPA (anl-mcs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
13648: id AA09323; Tue, 9 Jul 85 07:08:27 pdt
13649: Return-Path: <boyle@anl-mcs>
13650: Received: by anl-mcs.ARPA ; Tue, 9 Jul 85 09:12:21 cdt
13651: Date: Tue, 9 Jul 85 09:12:21 cdt
13652: From: boyle@anl-mcs (James M. Boyle)
13653: Message-Id: <[email protected]>
13654: To: arango@uci-icse, franz-friends@BERKELEY, schlimmer@uci-icse
13655: Subject: Re: Namestack Overflow; Large list storage
13656: Cc: boyle@anl-mcs
13657:
13658: In the directory franz/h search for NAMESIZE in the file global.h
13659: and change it; then rebuild the system. (Use a `make clean' first,
13660: because not all the dependencies are in the makefile, I think. You
13661: can rebuild with `make fast' [ha!]).
13662:
13663: I changed the NAMESIZE in our system from 3072 to 16384 without difficulty.
13664:
13665: However, I have a problem, franz-friends--I tried to increase the list
13666: storage (TTSIZE) from the default 6000 or so 512 byte pages to 32000.
13667: When the storage goes above the 10216 pages or so, I get bizzare behavior,
13668: usually culminating in an illegal instruction. Is 10216 somehow a hard
13669: limit on the list storage size? Has anyone built a system bigger than
13670: 10216 and had it work for large jobs? (This is not a problem with our
13671: system datasize limit; it happens before the datasize is exceeded.)
13672:
13673: Thanks.
13674: Jim Boyle
13675:
13676: From [email protected] Thu Jul 11 20:23:07 1985
13677: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13678: id AA01049; Thu, 11 Jul 85 20:23:07 pdt
13679: Received: from MIT-MC.ARPA (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
13680: id AA27795; Wed, 10 Jul 85 09:44:41 pdt
13681: Date: Wed, 10 Jul 85 12:50:05 EDT
13682: From: Jeffrey P. Golden <[email protected]>
13683: Subject: Franz Lisp for Eunice 4.1
13684: To: franz-friends@BERKELEY
13685: Cc: [email protected]
13686: Message-Id: <[MIT-MC.ARPA].570311.850710.JPG>
13687:
13688: We are running Franz Lisp, opus 38.79 in VMS 4.1, Eunice 4.1 .
13689: The way "funny" VMS filenames such as i.am.funny (two dots) and
13690: longfilename.l (more than 9 characters in first-filename) are hashed by
13691: Eunice was changed from version 3.X (HSN/HSH filename extensions) to
13692: version 4.X ($-sign encoding).
13693: The problem is even though we are running in VMS/Eunice 4.1, Franz only
13694: understands the VMS/Eunice 3.X funny filename hashing e.g. for
13695: (load "longfilename.l") . It gives a "file not found error" if the
13696: filename is hashed using the 4.X hashing scheme.
13697: Can anyone clarify this situation for me? I.e. is it likely to be a Franz
13698: problem or a Eunice problem we are facing? We have not rebuilt Franz yet,
13699: but would this help? Would recompiling some C file help? There's a
13700: function cvt_unix_to_vms . Is this the culprit? Is this a Franz function
13701: or a Eunice function? Any advice would be appreciated.
13702:
13703: Also, some .exe files work fine without rebuilding from 3.X . Others
13704: err out with: [EUNICE: $IMGACT failed, Status = %X84d8cbc - Couldn't get
13705: message string]. Does anyone know what this means?
13706:
13707:
13708: From zoll@CMU-PSY-A Mon Jul 15 09:07:27 1985
13709: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13710: id AA04385; Mon, 15 Jul 85 09:07:27 pdt
13711: Received: from CMU-PSY-A (cmu-psy-a.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
13712: id AA08819; Mon, 15 Jul 85 09:02:06 pdt
13713: Message-Id: <[email protected]>
13714: Date: Monday, 15 Jul 85 12:00:57 EDT
13715: From: zoll@cmu-psy-a (john zoll)
13716: Subject: Franz, Eunice, 4.0
13717: To: jpg@mit-mc
13718: Cc: zoll@CMU-PSY-A, franz-friends@BERKELEY
13719:
13720: cvt_unix_to_vms() is not part of the Franz sources: it is a Eunice function.
13721: We don't have 4.0 Eunice yet, but it should be easy to test this function out
13722: of context. Although I don't have the exact specs for 4.0 filenames, I'd guess
13723: that you probably could probably just blow away all calls to cvt_unix_to_vms()
13724: (there's only a few of them). Or writing your own wouldn't be too tough.
13725:
13726: -------
13727:
13728: I suspect the Eunice image activation error message is in reality VMS's
13729: IMG_SIZ error message (found on 2-205 of the 4.0 System Messages Manual).
13730: This means that your image header is fotched. Here's what happened to me:
13731: we've got a bunch of MicroVaxes and VaxStation 100s running various
13732: incarnations of VMS 4.X. Recently I tried to port Franz to them from our 780
13733: (running VMS and Eunice). Initially I just copied the Franz image to the
13734: workstation, but this resulted in the aforementioned image activation error.
13735: So then I copied the components needs to build an interpreted Franz by hand
13736: --- Rawlisp and the 10 or so .l files. This worked, but if I did a (dumplisp)
13737: to save the lisp, I would get the image activation error again. As it turns
13738: out, the code for (dumplisp ...) has a slight bug that has only become
13739: apparent under 4.X.
13740:
13741: The fix is trivial ---- there is a field in image headers that need not be
13742: set under 3.X, but must be set under 4.X. NDumplisp, the routine that creates
13743: a new lisp image, was not setting this field. Below is a fragment of my hack
13744: to NDumplisp:
13745:
13746: File: Fex3.C
13747: Routine: NDumplisp
13748: -------------------------
13749:
13750: /* Setting up the image header... */
13751:
13752: Buffer.Header.Ihd.majorid[1] = '2';
13753: Buffer.Header.Ihd.minorid[0] = '0';
13754: Buffer.Header.Ihd.minorid[1] = '2';
13755:
13756: /* Here's the hack..... */
13757:
13758: Buffer.Header.Ihd.hdrblkcnt = 1;
13759:
13760: /* EOH */
13761:
13762: Buffer.Header.Ihd.imgtype = IHD_EXECUTABLE;
13763: Buffer.Header.Ihd.privreqs[0] = -1;
13764: Buffer.Header.Ihd.privreqs[1] = -1;
13765:
13766: -----
13767:
13768: If anyone is planning to be running on 4.0, you must set this field, or any
13769: lisp created via dumplisp will not run.
13770:
13771: John Zoll
13772: Carnegie-Mellon University
13773: [email protected]
13774:
13775:
13776: From [email protected] Mon Jul 15 13:57:48 1985
13777: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13778: id AA09840; Mon, 15 Jul 85 13:57:48 pdt
13779: Received: from SRI-AI.ARPA (sri-ai.ARPA.ARPA) by UCB-VAX.ARPA (4.24/5.2)
13780: id AA05591; Mon, 15 Jul 85 13:52:21 pdt
13781: Message-Id: <[email protected]>
13782: Date: Mon 15 Jul 85 13:56:28-PDT
13783: From: [email protected]
13784: Subject: Re: Franz, Eunice, 4.0
13785: To: [email protected], [email protected]
13786: Cc: franz-friends@BERKELEY
13787:
13788: Here is a VERY simple "C" program that will patch the VMS image header to
13789: make the "hdrblkcnt" 1 instead of 0. You can use this program any time
13790: you do a dumplisp and want to run it on VMS 4.0 (without having to recompile
13791: the basic Franz Lisp):
13792:
13793: main(argc,argv)
13794: char *argv[];
13795: {
13796: int i;
13797: for(i = 1; i < argc; i++) patch(argv[i]);
13798: }
13799:
13800: patch(filename)
13801: char *filename;
13802: {
13803: int fd;
13804: char hdrblkcnt = 1;
13805:
13806: fd = open(filename,2);
13807: if (fd < 0) {perror("open"); return;}
13808: lseek(fd,16,0);
13809: write(fd,&hdrblkcnt,1);
13810: close(fd);
13811: }
13812:
13813:
13814: David
13815: -------
13816:
13817: From @MIT-MC.ARPA:[email protected] Mon Jul 22 07:23:24 1985
13818: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.48)
13819: id AA29235; Mon, 22 Jul 85 07:23:24 pdt
13820: Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by UCB-VAX.ARPA (4.24/5.3)
13821: id AA22657; Mon, 22 Jul 85 07:17:56 pdt
13822: Message-Id: <[email protected]>
13823: Received: from CMU-CS-A.ARPA by MIT-MC.ARPA 22 Jul 85 10:22:52 EDT
13824: Date: 22 July 1985 1022-EDT
13825: From: Karsten.Schwans@CMU-CS-A
13826: To: BBoard.Maintainer@CMU-CS-A
13827: Subject: FranzLisp IPC
13828: Attention: franzlisp bboard
13829:
13830: We are having trouble with FranzLisp on Berkeley 4.2. We don't
13831: seem to be able to call the Berkeley IPC without causing undue
13832: danamge to the system. Does anyone have a working piece
13833: of code you might send us Thanks, Karsten
13834: P.S.: Pleas send responses to [email protected] or schwans@cmua
13835:
13836:
13837:
13838: From john%[email protected] Mon Aug 19 15:55:07 1985
13839: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
13840: id AA00203; Mon, 19 Aug 85 15:55:07 PDT
13841: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3)
13842: id AA06773; Mon, 19 Aug 85 14:22:12 pdt
13843: Message-Id: <[email protected]>
13844: Received: from mtu by csnet-relay.csnet id a001523; 19 Aug 85 17:23 EDT
13845: Received: by mtu.UUCP (4.12/4.7)
13846: id AA22034; Mon, 19 Aug 85 09:58:17 edt
13847: Date: Mon, 19 Aug 85 09:58:17 edt
13848: From: John Lowther <john%[email protected]>
13849: To: franz-friends@BERKELEY
13850: Subject: List Membership
13851: Cc: [email protected]
13852:
13853: Please add Michigan Technological University ( c/o John Lowther)
13854: to franz-friends@BERKELEY distribution.
13855: Thanks,
13856: Dr. John Lowther
13857: Associate Professor of Computer Science
13858: Computer Science
13859: Michigan Technological University
13860: Houghton, Michigan 49931
13861:
13862: Office: (906) 487-2183
13863: Secretary: (906) 487-2068
13864:
13865: uucp: {lanl, ihnp4, glacier}!mtu!john
13866: arpa/csnet: john%mtu@csnet-relay
13867:
13868:
13869: From leff%[email protected] Tue Aug 27 18:54:44 1985
13870: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
13871: id AA12084; Tue, 27 Aug 85 18:54:44 PDT
13872: Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/5.3)
13873: id AA15443; Tue, 27 Aug 85 18:51:23 pdt
13874: Received: from smu by csnet-relay.csnet id ae17053; 27 Aug 85 21:47 EDT
13875: Received: by csevax.smu (4.12/4.7)
13876: id AA20402; Tue, 27 Aug 85 17:01:03 cdt
13877: Date: 27 Aug 1985 16:55-EST
13878: From: leff%[email protected]
13879: Subject:
13880: To: franz-friends@BERKELEY
13881: Message-Id: <494027757/leff@smu>
13882:
13883: One of our Franz users (Opus 38.79) has gotten the error message
13884:
13885: "Space request would exceed maximum memory allocation
13886: [Storage space totally exhausted]
13887: Error: Space exhausted when allocating list"
13888:
13889: I seem to recall reading in the manual that there was some function
13890: to reconfigure the amount of space used by cons as opposed to
13891: print-name space or something but a search of the manual fails
13892: to turn anything up. Is there anything I can do for our user
13893: short of telling him to write his code to use less memory space."
13894:
13895: (Note to moderator: This sounds like a straightforward question
13896: but it has got us stumped. Perhaps you can forward it to someone
13897: who can answer it without bothering the whole net.)
13898:
13899: Thanks,
13900:
13901:
13902: Leff
13903:
13904:
13905: From sklower@ucbdali Wed Sep 11 17:53:47 1985
13906: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
13907: id AA01203; Wed, 11 Sep 85 17:53:47 PDT
13908: Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3)
13909: id AA00745; Wed, 11 Sep 85 17:49:44 pdt
13910: Received: by ucbdali.ARPA (5.5/4.48)
13911: id AA06062; Wed, 11 Sep 85 17:48:39 PDT
13912: Date: Wed, 11 Sep 85 17:48:39 PDT
13913: From: sklower@ucbdali (Keith Sklower)
13914: Message-Id: <[email protected]>
13915: To: [email protected]
13916: Subject: -H flag
13917: Cc: franz-friends@BERKELEY
13918:
13919: we have built macsyma here at berkeley without using the -H
13920: flag on the sun. The only thing it would buy you is sharing of
13921: text space if two people were running macsyma on the same sun,
13922: a foolish proposition at best. Just link rawlisp to rawhlisp.
13923:
13924: From @CSNET-RELAY.ARPA@BERKELEY Tue Sep 24 16:11:53 1985
13925: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
13926: id AA20743; Tue, 24 Sep 85 16:11:53 PDT
13927: Received: by UCB-VAX.ARPA (5.25/5.9)
13928: id AA14107; Tue, 24 Sep 85 16:11:28 PDT
13929: Message-Id: <[email protected]>
13930: Received: from umn-cs by csnet-relay.csnet id ag03295; 24 Sep 85 19:11 EDT
13931: Received: by umn-cs.UMN (4.12/4.7)
13932: id AA25965; Mon, 23 Sep 85 17:39:06 cdt
13933: Date: Mon, 23 Sep 85 17:39:06 cdt
13934: From: Raj Doshi <doshi%[email protected]>
13935: To: [email protected], franz-friends%[email protected]
13936: Subject: FRANZ-unix question...
13937:
13938:
13939: > In Franz, how can I access the following:-
13940: (1) The user's name (not just the login name, but also
13941: the actual name from the '.plan' (or whatever) file ???
13942: (2) The date.
13943:
13944: Thank you very much.
13945:
13946: --- raj doshi, University of Minnesota
13947:
13948: doshi%[email protected]
13949:
13950: Raj Doshi
13951: 2030 Wilson Avenue, Apt #27
13952: Saint Paul, MN 55119
13953: (612)-739-2353
13954: (612)-739-2151
13955:
13956:
13957:
13958:
13959: From @CSNET-RELAY.ARPA@BERKELEY Tue Sep 24 21:13:35 1985
13960: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
13961: id AA24010; Tue, 24 Sep 85 21:13:35 PDT
13962: Received: by UCB-VAX.ARPA (5.25/5.9)
13963: id AA20438; Tue, 24 Sep 85 21:13:25 PDT
13964: Message-Id: <[email protected]>
13965: Received: from umn-cs by csnet-relay.csnet id ab04924; 25 Sep 85 0:11 EDT
13966: Received: by umn-cs.UMN (4.12/4.7)
13967: id AA17034; Tue, 24 Sep 85 20:58:58 cdt
13968: Date: Tue, 24 Sep 85 20:58:58 cdt
13969: From: Raj Doshi <doshi%[email protected]>
13970: To: [email protected], franz-friends%[email protected],
13971: franz-friends@berkley, [email protected]
13972: Subject: unknown prop.lists ..
13973:
13974:
13975: **** QUESTION about FRANZ-LISP, atoms & their properties :-
13976:
13977: Suppose that I have access to an atom (i.e. I know its NAME).
13978: But I dont know anything more about it.
13979:
13980: Now, is there a FRANZ function, whereby I can
13981: ask franz to RETURN/LIST all the properties,
13982: (given to the atom via PUTPROPs by the user).
13983: if any, (and maybe their values) to me ???
13984:
13985: Maybe the creators of FRANZ didnt see the need for such a function
13986: or maybe they didnot think about this, but,
13987: I am sure FRANZ has to keep track of an atom's properties
13988: (probably in an array or frame like structure).
13989:
13990: HOW DOES FRANZ actually STORE THE properties OF ATOMS ??
13991: If I know this, I could (probably?) write the function myself.
13992:
13993: Thanks in advance.
13994:
13995: --- raj doshi, University of Minnesota
13996:
13997: doshi%[email protected]
13998:
13999: Raj Doshi
14000: 2030 Wilson Avenue, Apt #27
14001: Saint Paul, MN 55119
14002: (612)-739-2353
14003: (612)-739-2151
14004:
14005:
14006:
14007:
14008: From @CSNET-RELAY.ARPA@BERKELEY Tue Sep 24 21:14:14 1985
14009: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
14010: id AA24021; Tue, 24 Sep 85 21:14:14 PDT
14011: Received: by UCB-VAX.ARPA (5.25/5.9)
14012: id AA20453; Tue, 24 Sep 85 21:13:57 PDT
14013: Message-Id: <[email protected]>
14014: Received: from umn-cs by csnet-relay.csnet id ad04924; 25 Sep 85 0:12 EDT
14015: Received: by umn-cs.UMN (4.12/4.7)
14016: id AA18092; Tue, 24 Sep 85 21:53:59 cdt
14017: Date: Tue, 24 Sep 85 21:53:59 cdt
14018: From: Raj Doshi <doshi%[email protected]>
14019: To: [email protected], franz-friends%[email protected],
14020: franz-friends@BERKELEY, [email protected]
14021: Subject: i AND o ....
14022:
14023:
14024: **** Question about CONCURRENT i/o to the SAME file.
14025:
14026: I am trying to do the following in Franz-Lisp:-
14027: I have a file which has some stuff in it (= it is non-empty).
14028: First, I want to *append* something to it (that is, I want
14029: to write something FROM its end-of-file; I want to preserve
14030: its original contents).
14031: Then, I want to read something from the start-of-the-file.
14032: Then, I want to *append* something-new to the new-version
14033: of this file.
14034:
14035: Now, I have tried the following:-
14036: Lets say that the file name is fn.
14037: TRY #1 : setq portout (outfile 'fn)
14038: fseek portout
14039: (filestat:size (filestat 'fn)) ;Filestat take only 2 param.
14040: 0)
14041: (defun p-raj () (patom "Hi-raj" portout))
14042: (p-raj)
14043: (p-raj)
14044: ----------------
14045: The problem with this is that the
14046: >setq portout (outfile 'fn)
14047: seems to AUTOMATICALLY and PERMANENTLY
14048: put the r/w-cursor at the START of the file
14049: (without my permission). Also, once this is
14050: done, FSEEK become impotent. It will always
14051: send back a zero. Also, a FILEPOS has no effect.
14052: Basically, you cannot move the @<@!!# cursor
14053: unless you write (and therefore overwrite the
14054: original contents) something to the file.
14055: Note however that, if I had not done
14056: setq portout (outfile 'fn)
14057: then,
14058: >(filestat:size (filestat 'fn))
14059: does return the true (unix) size of the file.
14060: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
14061: TRY #2 : (setq inout (infile 'fn))
14062: (fileopen 'fn 'w+) ; FILEOPEN takes only 2 parameters.
14063: ; you can also try the following
14064: ; (fileopen 'fn 'a+)
14065: (filepos portio)
14066: [this gives back a zero, which is ok.]
14067: (filestat:size (filestat 'junk))
14068: [this does give its true size, say 232 blocks.]
14069: (filepos portio (filestat:size (filestat 'junk)))
14070: [this does put the r/w-cursor at 232.]
14071: (filepos portio)
14072: [this confirms that.]
14073: (patom "IS this really going to get appended ?" portio)
14074: [this prints the above string on the TERMINAL,
14075: not onto the file fn.]
14076: (filepos portio)
14077: [the cursor is STILL at 232.]
14078: -----------
14079: Basically, I think that the reason it wont write to the file fn,
14080: in this second case is that the <inout> was defined
14081: for reading and not for writing.
14082: {Is this the correct impression ?}
14083:
14084: [I have tried many many different permutations also.]
14085:
14086: SO, in brief, a <setq pi (outfile..>
14087: automatically puts the cursor at the start-of-the-file;
14088: and the FILEOPEN, FILEPOS, FSEEK dont seem to have any effect.
14089: and, a <setq po (infile...>
14090: never allows me to write onto the file atall
14091: even if I do a <FILEOPEN 'fn 'w+>.
14092:
14093: >>>>>> QUESTION: What am I missing here ?? <<<<<<
14094:
14095: Thanks in advance.
14096:
14097:
14098: --- raj doshi, University of Minnesota
14099:
14100: doshi%[email protected]
14101:
14102: Raj Doshi
14103: 2030 Wilson Avenue, Apt #27
14104: Saint Paul, MN 55119
14105: (612)-739-2353
14106: (612)-739-2151
14107:
14108:
14109:
14110:
14111: From @CSNET-RELAY.ARPA@BERKELEY Tue Sep 24 21:14:42 1985
14112: Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (5.5/5.3)
14113: id AA24035; Tue, 24 Sep 85 21:14:42 PDT
14114: Received: by UCB-VAX.ARPA (5.25/5.9)
14115: id AA20463; Tue, 24 Sep 85 21:14:15 PDT
14116: Message-Id: <[email protected]>
14117: Received: from umn-cs by csnet-relay.csnet id ae04924; 25 Sep 85 0:12 EDT
14118: Received: by umn-cs.UMN (4.12/4.7)
14119: id AA18092; Tue, 24 Sep 85 21:53:59 cdt
14120: Date: Tue, 24 Sep 85 21:53:59 cdt
14121: From: Raj Doshi <doshi%[email protected]>
14122: To: [email protected], franz-friends%[email protected],
14123: franz-friends@BERKELEY, [email protected]
14124: Subject: i AND o ....
14125:
14126:
14127: **** Question about CONCURRENT i/o to the SAME file.
14128:
14129: I am trying to do the following in Franz-Lisp:-
14130: I have a file which has some stuff in it (= it is non-empty).
14131: First, I want to *append* something to it (that is, I want
14132: to write something FROM its end-of-file; I want to preserve
14133: its original contents).
14134: Then, I want to read something from the start-of-the-file.
14135: Then, I want to *append* something-new to the new-version
14136: of this file.
14137:
14138: Now, I have tried the following:-
14139: Lets say that the file name is fn.
14140: TRY #1 : setq portout (outfile 'fn)
14141: fseek portout
14142: (filestat:size (filestat 'fn)) ;Filestat take only 2 param.
14143: 0)
14144: (defun p-raj () (patom "Hi-raj" portout))
14145: (p-raj)
14146: (p-raj)
14147: ----------------
14148: The problem with this is that the
14149: >setq portout (outfile 'fn)
14150: seems to AUTOMATICALLY and PERMANENTLY
14151: put the r/w-cursor at the START of the file
14152: (without my permission). Also, once this is
14153: done, FSEEK become impotent. It will always
14154: send back a zero. Also, a FILEPOS has no effect.
14155: Basically, you cannot move the @<@!!# cursor
14156: unless you write (and therefore overwrite the
14157: original contents) something to the file.
14158: Note however that, if I had not done
14159: setq portout (outfile 'fn)
14160: then,
14161: >(filestat:size (filestat 'fn))
14162: does return the true (unix) size of the file.
14163: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
14164: TRY #2 : (setq inout (infile 'fn))
14165: (fileopen 'fn 'w+) ; FILEOPEN takes only 2 parameters.
14166: ; you can also try the following
14167: ; (fileopen 'fn 'a+)
14168: (filepos portio)
14169: [this gives back a zero, which is ok.]
14170: (filestat:size (filestat 'junk))
14171: [this does give its true size, say 232 blocks.]
14172: (filepos portio (filestat:size (filestat 'junk)))
14173: [this does put the r/w-cursor at 232.]
14174: (filepos portio)
14175: [this confirms that.]
14176: (patom "IS this really going to get appended ?" portio)
14177: [this prints the above string on the TERMINAL,
14178: not onto the file fn.]
14179: (filepos portio)
14180: [the cursor is STILL at 232.]
14181: -----------
14182: Basically, I think that the reason it wont write to the file fn,
14183: in this second case is that the <inout> was defined
14184: for reading and not for writing.
14185: {Is this the correct impression ?}
14186:
14187: [I have tried many many different permutations also.]
14188:
14189: SO, in brief, a <setq pi (outfile..>
14190: automatically puts the cursor at the start-of-the-file;
14191: and the FILEOPEN, FILEPOS, FSEEK dont seem to have any effect.
14192: and, a <setq po (infile...>
14193: never allows me to write onto the file atall
14194: even if I do a <FILEOPEN 'fn 'w+>.
14195:
14196: >>>>>> QUESTION: What am I missing here ?? <<<<<<
14197:
14198: Thanks in advance.
14199:
14200:
14201: --- raj doshi, University of Minnesota
14202:
14203: doshi%[email protected]
14204:
14205: Raj Doshi
14206: 2030 Wilson Avenue, Apt #27
14207: Saint Paul, MN 55119
14208: (612)-739-2353
14209: (612)-739-2151
14210:
14211:
14212:
14213:
14214: From [email protected] Mon Oct 7 10:41:27 1985
14215: Received: by ucbkim (5.28/5.12)
14216: id AA02846; Mon, 7 Oct 85 10:41:27 PDT
14217: Received: by UCB-VAX.ARPA (5.28/5.11)
14218: id AA00642; Mon, 7 Oct 85 06:55:41 PDT
14219: Received: by mitre.ARPA (4.12/4.7)
14220: id AA11068; Mon, 7 Oct 85 09:56:30 edt
14221: Message-Id: <[email protected]>
14222: To: franz-friends@BERKELEY
14223: Cc: [email protected]
14224: Subject: arpa list
14225: Date: 07 Oct 85 09:55:24 EDT (Mon)
14226: From: Lisa Sokol <[email protected]>
14227:
14228: Could you please add my name to your mailing list-- sokol@mitre
14229:
14230: Thank youl
14231:
14232: Lisa Sokol
14233:
14234: From [email protected] Fri Oct 11 19:56:25 1985
14235: Received: by kim (5.28/5.12)
14236: id AA06307; Fri, 11 Oct 85 19:56:25 PDT
14237: Received: by UCB-VAX (5.28/5.12)
14238: id AA01765; Fri, 11 Oct 85 19:56:11 PDT
14239: Received: by sdcsvax.ARPA (5.28/4.41)
14240: id AA08044; Fri, 11 Oct 85 15:35:25 PDT hops=0
14241: From: [email protected] (Peter Benson)
14242: Date: Fri, 11 Oct 85 15:14:30 pdt
14243: Message-Id: <[email protected]>
14244: Received: by dcdwest.ITT; Fri, 11 Oct 85 15:14:30 pdt
14245: To: franz-friends@BERKELEY
14246: Subject: Could you ...
14247:
14248: put me on the mailing list ??
14249: Thanks.
14250:
14251: _
14252: Peter Benson | ITT Defense Communications Division
14253: (619)578-3080 | 10060 Carroll Canyon Road
14254: decvax!ittvax!dcdwest!benson | San Diego, CA 92131
14255: ucbvax!sdcsvax!dcdwest!benson |
14256:
14257: From fateman@dali Wed Oct 30 12:22:05 1985
14258: Received: by kim (5.28/5.12)
14259: id AA10131; Wed, 30 Oct 85 12:22:05 PST
14260: Received: by dali.ARPA (5.31/4.48)
14261: id AA19284; Wed, 30 Oct 85 12:21:57 PST
14262: Date: Wed, 30 Oct 85 12:21:57 PST
14263: From: fateman@dali (Richard Fateman)
14264: Message-Id: <[email protected]>
14265: To: franz-friends@kim
14266: Subject: new implementation of Franz?
14267:
14268: Actually, a compatible version of Franz (compatible with VAX/UNIX, and
14269: the 680x0 UNIX systems) might be made available on an as-yet-unannounced
14270: UNIX-based workstation made by a major computer manufacturer.
14271:
14272: It appears that this would be coupled with substantial donations of
14273: the hardware to universities, by the manufacturer.
14274:
14275: If the attractiveness of the workstation TO YOU would be enhanced by the
14276: availability of Franz Lisp, please send me a note. (don't respond
14277: to franz-friends.) As a group, we can lobby more effectively, and
14278: get the manufacturer to supply it. You may also include comments about
14279: the desirability of additional dialects of Lisp.
14280:
14281: Thanks,
14282: Richard Fateman, UC Berkeley.
14283:
14284: From YE15%[email protected] Tue Nov 5 01:29:26 1985
14285: Received: by kim (5.28/5.12)
14286: id AA03832; Tue, 5 Nov 85 01:29:26 PST
14287: Received: by ucb-vax.berkeley.edu (5.31/1.2)
14288: id AA06898; Tue, 5 Nov 85 01:29:03 PST
14289: Received: from mrca.co.uk by 44d.Cs.Ucl.AC.UK via PSS with NIFTP id a006249;
14290: 5 Nov 85 9:24 GMT
14291: From: at GEC Research <YE15%[email protected]>
14292: To: franz-friends <franz-friends%[email protected]>
14293: Date: Tue, 5 Nov 85 09:04
14294: Subject: Receiving "franz-friends"
14295: Message-Id: <05 NOV 1985 09:15:13 [email protected]>
14296:
14297: I would like to get my name added to the distribution
14298: list for "franz-friends". I saw a reference to it in AIList
14299: Digest recently, but couldn't find anyone in the UK who knew
14300: about it. Can you either give me information about how to
14301: receive "franz-friends" or add my name to the list of
14302: recipients, whichever is appropriate. My address is,
14303:
14304: Kevin Poulter (YE15%[email protected])
14305: GEC Research Ltd
14306: Marconi Research Centre
14307: West Hanningfield Road
14308: Great Baddow
14309: Chelmsford
14310: Essex
14311: CM2 8HN
14312: United Kingdom
14313:
14314:
14315: Thanks,
14316:
14317: Kevin Poulter (YE15%[email protected])
14318:
14319:
14320:
14321:
14322: From bzs%buit4%[email protected] Sat Nov 9 16:53:26 1985
14323: Received: by kim (5.28/5.12)
14324: id AA20036; Sat, 9 Nov 85 16:53:26 PST
14325: Received: by ucbvax.berkeley.edu (5.31/1.2)
14326: id AA04628; Sat, 9 Nov 85 16:53:20 PST
14327: Received: from bostonu by csnet-relay.csnet id ac19699; 9 Nov 85 19:45 EST
14328: Received: from buit4.ARPA by bu-cs.ARPA (4.12/4.7)
14329: id AA06442; Sat, 9 Nov 85 19:34:45 est
14330: Return-Path: <bzs@buit4>
14331: Received: by buit4.ARPA (2.2/4.7)
14332: id AA05580; Sat, 9 Nov 85 19:36:36 est
14333: Date: Sat, 9 Nov 85 19:36:36 est
14334: From: Barry Shein <bzs%buit4%[email protected]>
14335: Message-Id: <[email protected]>
14336: To: franz-friends%[email protected]
14337: Subject: Re: IMPROPER USE OF SET error on SUNs
14338:
14339:
14340: I don't know if this was answered (I haven't seen it) but I am
14341: quite sure the problem is in the definition of *array in array.l,
14342: down near the bottom there is a (do ((i size)) ((zerop i))
14343: (set (arrayref tname (setq i......)
14344:
14345: the error is coming I believe from that (set) for fixnum-block type
14346: arrays. If someone can come up with the fix I would appreciate,
14347: (or already has) otherwise I'll try and figure out what should be
14348: there. Thanks in advance.
14349:
14350: -Barry Shein, Boston University
14351:
14352:
14353:
14354: From bzs%buit1%[email protected] Sun Nov 10 12:27:50 1985
14355: Received: by kim (5.28/5.12)
14356: id AA01767; Sun, 10 Nov 85 12:27:50 PST
14357: Received: by ucbvax.berkeley.edu (5.31/1.2)
14358: id AA17353; Sun, 10 Nov 85 12:27:28 PST
14359: Received: from bostonu by csnet-relay.csnet id ai00716; 10 Nov 85 15:16 EST
14360: Received: from buit1.ARPA by bu-cs.ARPA (4.12/4.7)
14361: id AA25424; Sun, 10 Nov 85 14:43:05 est
14362: Return-Path: <bzs@buit1>
14363: Received: by buit1.ARPA (2.2/4.7)
14364: id AA09529; Sun, 10 Nov 85 14:42:43 est
14365: Date: Sun, 10 Nov 85 14:42:43 est
14366: From: Barry Shein <bzs%buit1%[email protected]>
14367: Message-Id: <[email protected]>
14368: To: franz-friends%[email protected]
14369: Subject: minor annoying bug in cfasl
14370:
14371:
14372: If I try to cfasl something with:
14373:
14374: (cfasl 'foo.o '_foo 'foo "whatever")
14375:
14376: I get a ld line that looks like:
14377:
14378: ... /tmp/TMPXYZZY (null) -lc
14379:
14380: that is, a null pointer is being passed to sprintf() and it is putting
14381: '(null)' out (and the sh invoked by system() barks and the whole thing fails.)
14382:
14383: A workaround is to add a null string at the end of the arglist
14384:
14385: (cfasl 'foo.o '_foo 'foo "whatever" "")
14386:
14387: A fix is to go into the file franz/ffasl.c and change: (in function Lcfasl)
14388:
14389: if(work==nil)
14390: largs = 0 ;
14391: to
14392: if(work==nil)
14393: largs = "" ;
14394: I believe (trying it now, takes a while to compile this beast, no?)
14395:
14396: -Barry Shein, Boston University
14397:
14398:
14399: From root%buit1%[email protected] Mon Nov 11 06:50:27 1985
14400: Received: by kim (5.28/5.12)
14401: id AA13546; Mon, 11 Nov 85 06:50:27 PST
14402: Received: by ucbvax.berkeley.edu (5.31/1.2)
14403: id AA04671; Mon, 11 Nov 85 06:50:19 PST
14404: Received: from bostonu by csnet-relay.csnet id af00429; 11 Nov 85 9:38 EST
14405: Received: from buit1.ARPA by bu-cs.ARPA (4.12/4.7)
14406: id AA01783; Mon, 11 Nov 85 01:35:02 est
14407: Return-Path: <root@buit1>
14408: Received: by buit1.ARPA (2.2/4.7)
14409: id AA00418; Mon, 11 Nov 85 01:32:21 est
14410: Date: Mon, 11 Nov 85 01:32:21 est
14411: From: Operator <root%buit1%[email protected]>
14412: Message-Id: <[email protected]>
14413: To: franz-friends%[email protected]
14414: Subject: Re: SET error on 68K
14415:
14416:
14417: I believe the following fix repairs the problem in lisplib/array.l
14418: (I think this only affects you if you are on a 68k)
14419: ---
14420:
14421: in function *array, towards the bottom change:
14422:
14423: ; if type is fixnum or flonum
14424: ; we must intialize to 0 or 0.0
14425: (cond ((or (and (eq 'fixnum type)
14426: (setq rtype 0))
14427: (and (eq 'flonum type)
14428: (setq rtype 0.0))
14429: (and (or (status feature 68k)
14430: (status feature for-68k))
14431: (progn (setq rtype nil) t)))
14432: (do ((i size))
14433: ((zerop i))
14434: (set (arrayref tname (setq i (1- i))) rtype))))
14435: to be:
14436:
14437: ; if type is fixnum or flonum
14438: ; we must intialize to 0 or 0.0
14439: (cond ((or (and (or (eq 'fixnum type)(eq 'fixnum-block type))
14440: (setq rtype 0))
14441: (and (or (eq 'flonum type)(eq 'flonum-block type))
14442: (setq rtype 0.0))
14443: (and (or (status feature 68k)
14444: (status feature for-68k))
14445: (progn (setq rtype nil) t)))
14446: (do ((i size))
14447: ((zerop i))
14448: (store (funcall tname (setq i (1- i))) rtype))))
14449:
14450: The main problem being that the (status) call was testing true.
14451: Without changing the SET to a STORE I was still having troubles,
14452: so I changed that also. Flames welcome, not sure I understand everything
14453: going on here (yet.)
14454:
14455: -Barry Shein, Boston University
14456:
14457: P.S. typical apologies if this has all been solved before.
14458: (while you are in there you might want to fix the spelling of 'intialize')
14459:
14460:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.