Commit | Line | Data |
---|---|---|
3cdae440 C |
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: <8208141553.9999@UCBKIM.BERKELEY.ARPA> | |
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: <8209022215.10796@UCBKIM.BERKELEY.ARPA> | |
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: <8209040228.9829@UCBKIM.BERKELEY.ARPA> | |
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: <8209060401.6358@UCBKIM.BERKELEY.ARPA> | |
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: <8209081955.4140@UCBKIM.BERKELEY.ARPA> | |
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: <8209121744.29800@UCBKIM.BERKELEY.ARPA> | |
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: <8209122135.5086@UCBKIM.BERKELEY.ARPA> | |
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: <8209200154.195@UCBKIM.BERKELEY.ARPA> | |
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: <8209200550.3968@UCBKIM.BERKELEY.ARPA> | |
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: <8209222246.5610@UCBKIM.BERKELEY.ARPA> | |
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: <8209231558.21572@UCBKIM.BERKELEY.ARPA> | |
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: <8209251956.17542@UCBKIM.BERKELEY.ARPA> | |
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: <8209252157.21567@UCBKIM.BERKELEY.ARPA> | |
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: <8209260537.1666@UCBKIM.BERKELEY.ARPA> | |
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: <8209261620.11552@UCBKIM.BERKELEY.ARPA> | |
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: <8209280335.27561@UCBKIM.BERKELEY.ARPA> | |
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: <8209291634.8411@UCBKIM.BERKELEY.ARPA> | |
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: <8209291711.9176@UCBKIM.BERKELEY.ARPA> | |
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: <8209291906.12141@UCBKIM.BERKELEY.ARPA> | |
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 | \e9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, | |
1334 | SRI Int'l, and Univ. of Calif. | |
1335 | ||
1336 | ||
1337 | ||
1338 | \e9 | |
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 | \e9 | |
1468 | ||
1469 | \e9 | |
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: <8210032349.16460@UCBKIM.BERKELEY.ARPA> | |
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: <8210041819.24539@UCBARPA.BERKELEY.ARPA> | |
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: <8210140453.490@UCBKIM.BERKELEY.ARPA> | |
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: <8210301721.11699@UCBKIM.BERKELEY.ARPA> | |
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: <8210301842.13143@UCBKIM.BERKELEY.ARPA> | |
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: <8211011713.3615@UCBKIM.BERKELEY.ARPA> | |
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: <8211021604.14414@UCBKIM.BERKELEY.ARPA> | |
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: <8211061650.12951@UCBKIM.BERKELEY.ARPA> | |
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: <8211131835.12160@UCBKIM.BERKELEY.ARPA> | |
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: <8211142040.10379@UCBKIM.BERKELEY.ARPA> | |
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: <8300102304.19240@UCBKIM.BERKELEY.ARPA> | |
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: <8300110346.24831@UCBKIM.BERKELEY.ARPA> | |
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: <8300121703.1981@UCBKIM.BERKELEY.ARPA> | |
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: <8300122225.13079@UCBKIM.BERKELEY.ARPA> | |
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: <8300131749.331@UCBKIM.BERKELEY.ARPA> | |
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: <8300170522.23656@UCBKIM.BERKELEY.ARPA> | |
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: <8300190043.10935@UCBKIM.BERKELEY.ARPA> | |
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: <8300200955.17788@UCBKIM.BERKELEY.ARPA> | |
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: <8300210342.7334@UCBKIM.BERKELEY.ARPA> | |
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: <8300210457.8824@UCBKIM.BERKELEY.ARPA> | |
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: <8300211611.18650@UCBKIM.BERKELEY.ARPA> | |
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: <8300230037.1747@UCBVAX.BERKELEY.ARPA> | |
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: <8300230138.20020@UCBKIM.BERKELEY.ARPA> | |
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: <8300241825.19602@UCBVAX.BERKELEY.ARPA> | |
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: <8300250008.58@UCBVAX.BERKELEY.ARPA> | |
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:Tim@UPenn.UPenn 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: <8300260022.29320@UCBVAX.BERKELEY.ARPA> | |
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: <Tim@UPenn.UPenn@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: <8300281615.20646@UCBVAX.BERKELEY.ARPA> | |
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: <8300281634.17319@UCBKIM.BERKELEY.ARPA> | |
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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> | |
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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> | |
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: <8300281634.17319@UCBKIM.BERKELEY.ARPA> | |
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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> | |
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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> | |
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: <8300281631.21039@UCBVAX.BERKELEY.ARPA> | |
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: <8300281854.26156@UCBCAD.BERKELEY.ARPA> | |
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: <8301011832.599@UCBKIM.BERKELEY.ARPA> | |
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: <8301021325.221@UCBVAX.BERKELEY.ARPA> | |
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 <CSD.LARK@SU-SCORE.ARPA> | |
3108 | Subject: Re: emacs interface to franz? | |
3109 | To: mike@RAND-UNIX.ARPA | |
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 | <8300250008.58@UCBVAX.BERKELEY.ARPA> | |
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: <8301021614.25937@UCBKIM.BERKELEY.ARPA> | |
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: <8301110545.16021@UCBKIM.BERKELEY.ARPA> | |
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: <8301112302.7475@UCBVAX.BERKELEY.ARPA> | |
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: <8302141531.27879@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8302141052.25792@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8302190504.26020@UCBVAX.ARPA> | |
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: FRANZ-FRIENDS@BERKELEY.ARPA | |
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: <8302211719.2798@UCBKIM.ARPA> | |
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, FRANZ-FRIENDS@BERKELEY.ARPA | |
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: <8302251628.528@UCBKIM.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8303060412.18927@UCBKIM.ARPA> | |
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: <8303081401.AA13004@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8303081710.9423@UCBKIM.ARPA> | |
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: <8303091754.14754@UCBKIM.ARPA> | |
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: <8303200144.25091@UCBKIM.ARPA> | |
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: <8303230452.5935@UCBKIM.ARPA> | |
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: <8303241629.6735@UCBKIM.ARPA> | |
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: <8303242300.11144@UCBKIM.ARPA> | |
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: <8303261137.AB02371@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8303261646.2453@UCBKIM.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304041711.AA07020@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304052042.AA26557@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304052108.16969@UCBKIM.ARPA> | |
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: <8304071549.AA13873@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304110350.6176@UCBKIM.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304111442.11378@UCBKIM.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8304221759.20996@UCBKIM.ARPA> | |
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: <8305080702.22344@UCBKIM.ARPA> | |
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: <8305211434.AA16172@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8305251915.1144@UCBKIM.ARPA> | |
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: <8305251950.AA02600@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8305252032.2716@UCBKIM.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <1983.05.27.18.18.47.150.08942@dione.rice> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8305311747.AA10893@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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 lbl-csam!steve@ssc-vax.UUCP Tue May 31 19:31:04 1983 | |
3997 | Date: 31 May 83 17:28:35 PDT (Tue) | |
3998 | From: ssc-vax!steve@lbl-csam.UUCP | |
3999 | Subject: packages | |
4000 | Message-Id: <8306010028.AA16451@LBL-CSAM.ARPA> | |
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: ucbvax!franz-friends@lbl-csam.UUCP | |
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: <8306141848.6756@UCBKIM.ARPA> | |
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: <8306151742.20591@UCBKIM.ARPA> | |
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: <8306142214.AA16599@UCBVAX.ARPA> | |
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: <8306161646.AA25470@UCBVAX.ARPA> | |
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: <8306192243.19626@UCBKIM.ARPA> | |
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: <8306200547.23164@UCBKIM.ARPA> | |
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: <8306200553.AA15160@UCBVAX.ARPA> | |
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: <8306210509.AA00276@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8306212152.AA12930@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8306252049.25527@UCBKIM.ARPA> | |
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: <8307060702.24776@UCBKIM.ARPA> | |
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: <8307070727.10697@UCBKIM.ARPA> | |
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: <8307080845.AA16294@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8307130107.AA03336@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8307130309.AA05908@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA, jlk.Gatech@UDEL-RELAY | |
4411 | In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon). | |
4412 | <8307130107.AA03336@UCBVAX.ARPA> | |
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: <8307130754.AA10367@UCBVAX.ARPA> | |
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, franz-friends@BERKELEY.ARPA | |
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: <8307141806.AA05735@UCBVAX.ARPA> | |
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: <8307141948.AA06936@UCBVAX.ARPA> | |
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: franz-friends@BERKELEY.ARPA | |
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: <8308012141.AA03743@ucbkim.ARPA> | |
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: <8308022220.AA26686@ucbkim.ARPA> | |
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: <8308052254.AA10357@UCBVAX.ARPA> | |
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: <8308061640.AA13549@UCBVAX.ARPA> | |
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: <8308052254.AA10357@UCBVAX.ARPA> | |
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: <8308081606.AA06584@ucbkim.ARPA> | |
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: <8308130511.AA25610@ucbkim.ARPA> | |
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: <8308160611.AA05928@ucbkim.ARPA> | |
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 | \e9 | |
4880 | ||
4881 | \e9 | |
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 | \e9 | |
4945 | ||
4946 | \e9 | |
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 | \e9 | |
5010 | ||
5011 | \e9 | |
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 | \e9 | |
5141 | ||
5142 | \e9 | |
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: <8308190225.AA09885@ucbkim.ARPA> | |
5155 | To: local-lisp | |
5156 | Subject: opus 38.75 | |
95f51977 | 5157 | Status: O |
3cdae440 C |
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: <8308192054.AA20017@ucbkim.ARPA> | |
5181 | To: local-lisp | |
5182 | Subject: liszt 8.36 | |
95f51977 | 5183 | Status: O |
3cdae440 C |
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 | |
95f51977 | 5220 | Status: O |
3cdae440 C |
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: <8308252058.AA21033@ucbkim.ARPA> | |
5235 | To: local-lisp | |
95f51977 | 5236 | Status: O |
3cdae440 C |
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: <8308310450.AA06203@ucbvax.ARPA> | |
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 | |
95f51977 | 5250 | Status: O |
3cdae440 C |
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: <8309041659.AA03721@ucbkim.ARPA> | |
5285 | To: local-lisp | |
5286 | Subject: opus 38.77 | |
95f51977 | 5287 | Status: O |
3cdae440 C |
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: <8309092031.AA11010@ucbvax.ARPA> | |
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 | |
95f51977 | 5321 | Status: O |
3cdae440 C |
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 AUSTIN@DEC-MARLBORO.ARPA 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> | |
95f51977 | 5344 | Status: O |
3cdae440 C |
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: <8309101934.AA28421@ucbkim.ARPA> | |
5359 | To: local-lisp | |
5360 | Subject: opus 38.78 | |
95f51977 | 5361 | Status: O |
3cdae440 C |
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 | ||
95f51977 C |
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: <8309141503.AA14786@ucbkim.ARPA> | |
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: <8309262328.AA07367@ucbvax.ARPA> | |
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: <8309292150.AA10806@ucbkim.ARPA> | |
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: <8309300604.AA04355@ucbkim.ARPA> | |
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: <8310020442.AA16280@ucbkim.ARPA> | |
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: <8310041505.AA07616@ucbvax.ARPA> | |
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: <8310082258.AA23633@ucbvax.ARPA> | |
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: <8310121311.AA29652@ucbkim.ARPA> | |
5820 | To: local-lisp | |
5821 | Subject: New AI language in the works | |
5822 | Cc: | |
5823 | Status: RO | |
5824 | ||
5825 | ||
5826 | From: Skef Wholey <Wholey@CMU-CS-C.ARPA> | |
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: <8310141626.AA00195@ucbvax.ARPA> | |
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: <8310141645.AA14694@ucbkim.ARPA> | |
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: <8310162339.AA03935@ucbkim.ARPA> | |
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: <8310170556.AA01323@UCBMIRO.ARPA> | |
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: <8310171708.AA02418@ucbkim.ARPA> | |
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: <8310281243.AA14289@ucbvax.ARPA> | |
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: <8310311254.AA08771@ucbvax.ARPA> | |
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: <8311011451.AA01150@ucbvax.ARPA> | |
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: <8311042214.AA20986@ucbkim.ARPA> | |
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: <8311050355.AA03738@ucbvax.ARPA> | |
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: <8311042214.AA20986@ucbkim.ARPA> | |
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: <8311042214.AA20986@ucbkim.ARPA> | |
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: <8311180103.AA01897@ucbkim.ARPA> | |
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: <8311221733.AA15675@ucbkim.ARPA> | |
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: <8311230113.AA06655@UCB-VAX.ARPA> | |
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: <8312040543.AA06631@UCB-VAX.ARPA> | |
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: <8312131631.AA03666@ucbkim.ARPA> | |
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: <8401112058.AA03955@UCB-VAX.ARPA> | |
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: <8401112109.AA04150@UCB-VAX.ARPA> | |
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: <8401112058.AA03955@UCB-VAX.ARPA> | |
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: <8401152258.AA02865@ucbdali.ARPA> | |
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 | _\b1. _\bW_\be_\bl_\bc_\bo_\bm_\be! | |
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 | _\b2. _\bN_\be_\bw _\bi_\bm_\bp_\bl_\be_\bm_\be_\bn_\bt_\ba_\bt_\bi_\bo_\bn_\bs | |
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 | _\b3. _\bN_\be_\bw _\bp_\br_\bo_\bg_\br_\ba_\bm_\bs | |
6426 | ||
6427 | _\b3._\b1. _\bV_\ba_\bx_\bi_\bm_\ba _\ba_\bn_\bd _\bA_\bl_\bg_\be_\bb_\br_\ba_\bi_\bc _\bM_\ba_\bn_\bi_\bp_\bu_\bl_\ba_\bt_\bi_\bo_\bn | |
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 | \e9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, | |
6439 | SRI Int'l, and Univ. of Calif. | |
6440 | ||
6441 | ||
6442 | ||
6443 | \e9 | |
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 | _\b4. _\bN_\be_\bw _\bf_\be_\ba_\bt_\bu_\br_\be_\bs | |
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 | _\b5. _\bO_\bt_\bh_\be_\br _\bL_\bi_\bs_\bp_\bs | |
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 | _\b6. _\bW_\bo_\br_\bk _\bi_\bn _\bP_\br_\bo_\bg_\br_\be_\bs_\bs | |
6489 | ||
6490 | _\b6._\b1. _\bG_\br_\ba_\bp_\bh_\bi_\bc_\bs | |
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 | _\b6._\b2. _\bI_\bB_\bM _\bF_\br_\ba_\bn_\bz | |
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 | \e9 | |
6507 | ||
6508 | \e9 | |
6509 | ||
6510 | ||
6511 | ||
6512 | ||
6513 | ||
6514 | ||
6515 | ||
6516 | ||
6517 | ||
6518 | ||
6519 | _\b7. _\bB_\bu_\bs_\bi_\bn_\be_\bs_\bs _\bN_\be_\bw_\bs | |
6520 | ||
6521 | _\b7._\b1. _\bF_\br_\ba_\bn_\bz _\bI_\bn_\bc | |
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 | \e9 | |
6572 | ||
6573 | \e9 | |
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: <8401191755.AA02684@UCB-VAX.ARPA> | |
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: <8401270101.AA02121@UCB-VAX.ARPA> | |
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: <8401271644.2469@ucbmike.ARPA> | |
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: <8401311851.1218@ucbmike.ARPA> | |
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: <8402031604.2117@ucbmike.ARPA> | |
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: <8402161832.AA16308@ucbkim.ARPA> | |
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: <8402221757.AA06784@ucbdali.ARPA> | |
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: <8403141658.3782@ucbmike.ARPA> | |
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: <8403141737.AA01437@ucbkim.ARPA> | |
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: <8403141742.3833@ucbmike.ARPA> | |
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 ROD@SU-AI.ARPA 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: <8403172147.AA12441@UCB-VAX.ARPA> | |
6848 | Date: 17 Mar 84 1347 PST | |
6849 | From: Rod Brooks <ROD@SU-AI.ARPA> | |
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: <8403281410.AA23759@UCB-VAX.ARPA> | |
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: <8403292007.AA04139@ucbdali.ARPA> | |
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: <8404042314.AA01892@UCB-VAX.ARPA> | |
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 MCLINDEN@RUTGERS.ARPA 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: <8404190436.AA29663@UCB-VAX.ARPA> | |
7115 | Date: 18 Apr 84 23:37:14 EST | |
7116 | From: Sean McLinden <MCLINDEN@RUTGERS.ARPA> | |
7117 | Subject: [Sean McLinden <MCLINDEN@RUTGERS.ARPA>: 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 <MCLINDEN@RUTGERS.ARPA> | |
7124 | Subject: Re: Franz on Suns under 4.2? | |
7125 | To: allegra!jdd@UCB-VAX.ARPA | |
7126 | cc: MCLINDEN@RUTGERS.ARPA | |
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%colostate.csnet@csnet-relay.arpa 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: <8405260145.AA23631@UCB-VAX.ARPA> | |
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%colostate.csnet@csnet-relay.arpa | |
7166 | Received: by csu-cs.UUCP (4.12/3.14) | |
7167 | id AA11606; Fri, 25 May 84 13:47:24 mdt | |
7168 | To: FRANZ-FRIENDS.BERKELEY@csnet-relay.arpa | |
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 trk@cmu-cs-g.arpa 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: Todd.Kueny@CMU-CS-G.ARPA | |
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 Jonl.pa@Xerox.ARPA 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: <8406040622.AA27487@UCB-VAX.ARPA> | |
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: Jonl.pa@XEROX.ARPA | |
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:sl@cmu-ri-isl1.arpa 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: <8406190007.AA19453@UCB-VAX.ARPA> | |
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 wkc@Ardc.ARPA 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: <8406191434.AA01762@UCB-VAX.ARPA> | |
7238 | Date: Tue, 19 Jun 84 10:31:27 EDT | |
7239 | From: William K. Cadwallender (LCWSL) <wkc@Ardc.ARPA> | |
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: <8406220224.AA27996@UCB-VAX.ARPA> | |
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: <8406272121.AA13744@UCB-VAX.ARPA> | |
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:rsw@cmu-cs-h.arpa 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: <8407100505.AA24170@UCB-VAX.ARPA> | |
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: <8407101829.AA06454@UCB-VAX.ARPA> | |
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: <8407101907.3780@ucbmike.ARPA> | |
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:stw@cmu-cs-spice.arpa 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: <8407102028.AA08350@UCB-VAX.ARPA> | |
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: <8407102228.AA10890@UCB-VAX.ARPA> | |
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: <8407110602.AA06176@ucbernie.ARPA> | |
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: <8407111924.AA19991@UCB-VAX.ARPA> | |
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: <8407112032.5402@ucbmike.ARPA> | |
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 uucp-5@cmu-cs-g.arpa 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: cadre!sm@CMU-CS-G.ARPA | |
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: <8407120322.AA22394@cadre.UUCP> | |
7646 | To: jkf@ucbmike.BERKELEY | |
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: <8407162328.AA02214@UCB-VAX.ARPA> | |
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: <8407181742.AA01412@UCB-VAX.ARPA> | |
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:pmk@cmu-ri-isl2.arpa 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: <8407251705.AA19747@UCB-VAX.ARPA> | |
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: <8407272133.AA04068@UCB-VAX.ARPA> | |
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 Masinter.pa@Xerox.ARPA 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: <8407272213.AA04900@UCB-VAX.ARPA> | |
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: Masinter.pa@XEROX.ARPA | |
7878 | Subject: Re: Benchmarks | |
7879 | In-Reply-To: Mike Brzustowicz <mab@AIDS-UNIX.ARPA>'s message of 27 Jul | |
7880 | 84 14:23:47 PDT (Fri) | |
7881 | To: mab@AIDS-UNIX.ARPA | |
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: <8408010300.AA02839@UCB-VAX.ARPA> | |
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: Philip.Kasprzyk@CMU-RI-ISL2.ARPA | |
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: <8408011804.AA01076@rand-unix.ARPA> | |
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: <8408012007.AA00994@ucbdali.ARPA> | |
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: <8408022309.1757@ucbmike.ARPA> | |
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: <8408061440.AA01505@maryland.ARPA> | |
8036 | To: franz-friends@BERKELEY, yba%mit-heracles@csnet-relay.ARPA | |
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: <8408082139.AA21105@UCB-VAX.ARPA> | |
8057 | Date: Wed, 8 Aug 84 17:28:58 EDT | |
8058 | From: Ira Smotroff <smotroff@BBNCCT.ARPA> | |
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: <8408101319.AA14441@UCB-VAX.ARPA> | |
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: <8408102015.AA21922@UCB-VAX.ARPA> | |
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 JonL.pa@Xerox.ARPA 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: <8408132026.AA05890@UCB-VAX.ARPA> | |
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: JonL.pa@XEROX.ARPA | |
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, GSB@MIT-ML.ARPA, ALAN@MIT-MC.ARPA | |
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: <8408140016.AA10564@UCB-VAX.ARPA> | |
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 jmiller@csnet-relay.csnet 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: <8408140854.AA23091@UCB-VAX.ARPA> | |
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%ct.csnet@csnet-relay.arpa | |
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 | jmiller@ctvax.csnet | |
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: <8408141436.AA26447@UCB-VAX.ARPA> | |
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: <8408141803.AA17397@ucbkim.ARPA> | |
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: <8408141853.AA18832@ucbkim.ARPA> | |
8328 | Phone: (415) 236-8262 | |
8329 | To: jmiller%ct.csnet@csnet-relay.arpa, 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: <8408141906.AA19018@ucbkim.ARPA> | |
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: <8408142054.AA03508@UCB-VAX.ARPA> | |
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: <8408142129.AA04288@UCB-VAX.ARPA> | |
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, jmiller@ct.csnet@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 JonL.pa@Xerox.ARPA 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: <8408152120.AA05115@UCB-VAX.ARPA> | |
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: JonL.pa@XEROX.ARPA | |
8510 | Subject: Re: (atom VECTOR): franz vs liszt | |
8511 | In-Reply-To: Alan Bawden <ALAN@MIT-MC.ARPA>'s message of 13 Aug 84 20:08 | |
8512 | EDT | |
8513 | To: ALAN@MIT-MC.ARPA | |
8514 | Cc: JonL.pa@XEROX.ARPA, GSB@MIT-MC.ARPA, franz-friends@BERKELEY, | |
8515 | smh@MIT-EMS.ARPA | |
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 JonL.pa@Xerox.ARPA 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: <8408160121.AA09647@UCB-VAX.ARPA> | |
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: JonL.pa@XEROX.ARPA | |
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 | "jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA | |
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 JonL.pa@Xerox.ARPA 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: <8408160250.AA10989@UCB-VAX.ARPA> | |
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: JonL.pa@XEROX.ARPA | |
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: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA, JonL.pa@XEROX.ARPA, | |
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: <8408160549.AA13406@UCB-VAX.ARPA> | |
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%ucf.csnet@csnet-relay.arpa 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%ucf.csnet@csnet-relay.arpa> | |
8643 | Message-Id: <8408171929.AA00852@ucf-cs.UUCP> | |
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: goldfarb.ucf-cs@csnet.relay | |
8659 | csnet: goldfarb@ucf | |
8660 | ||
8661 | From gvax.bromley@Cornell.ARPA 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: gvax.bromley@Cornell.ARPA (Mark Bromley) | |
8670 | Message-Id: <8408270345.AA14288@CORNELL-GVAX.ARPA> | |
8671 | Received: by CORNELL-GVAX.ARPA (4.30/4.30) | |
8672 | id AA14288; Sun, 26 Aug 84 23:45:55 edt | |
8673 | To: gvax.arpa-franz@Cornell.ARPA | |
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: <8408272126.AA14734@wisc-rsch.arpa> | |
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: neves@wisc-rsch.arpa | |
8714 | Sender: forwarder@UWVAX | |
8715 | From: neves@wisc-rsch.arpa | |
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: <8408272151.AA05840@UCB-VAX.ARPA> | |
8731 | Date: Monday, 27 Aug 1984 17:45-EDT | |
8732 | From: rad@Mitre-Bedford | |
8733 | To: neves@WISC-RSCH.ARPA | |
8734 | Cc: franz-friends@BERKELEY, neves@WISC-RSCH.ARPA | |
8735 | Subject: Re: FRANZ to VI and back | |
8736 | In-Reply-To: Your message of Monday, 27 Aug 1984 17:26-EDT. | |
8737 | <8408272126.AA14734@wisc-rsch.arpa> | |
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: <8408281459.AA20274@maryland.ARPA> | |
8787 | To: neves@WISC-RSCH.ARPA, 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:iaeh@cmu-ri-isl2.arpa 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: <8408291509.AA15198@UCB-VAX.ARPA> | |
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:iaeh@cmu-ri-isl2.arpa 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: <8408311715.AA03527@UCB-VAX.ARPA> | |
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: <8408311741.AA04133@UCB-VAX.ARPA> | |
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: <8409041755.AA20764@engrvax.UCSB> | |
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: <8409051533.AA09320@maryland.ARPA> | |
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 gvax.bromley@Cornell.ARPA 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: gvax.bromley@Cornell.ARPA (Mark Bromley) | |
9123 | Message-Id: <8409052306.AA19770@CORNELL-GVAX.ARPA> | |
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: <8410302043.AA04265@ucbmike.arpa> | |
9179 | To: mrose%udel-dewey.delaware@udel-relay.ARPA, 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: <8410252046.AA09504@tove.ARPA> | |
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 | <8410251628.AA00848@UCB-VAX.ARPA> | |
9203 | ||
9204 | From: Rene Bach <BACH%su-score.arpa@csnet-relay.ARPA> | |
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%wisc-ai.uwisc@wisc-crys.ARPA 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%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) | |
9225 | Message-Id: <8410302234.AA21547@wisc-ai.uwisc> | |
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%udel-dewey.delaware@udel-relay.ARPA 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: <8410311352.AA07029@UCB-VAX.ARPA> | |
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%udel-dewey.delaware@udel-relay.ARPA> | |
9246 | To: franz-friends@BERKELEY | |
9247 | Cc: johnson%udel-dewey.delaware@udel-relay.ARPA | |
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%bostonu.csnet@csnet-relay.arpa 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%bostonu.csnet@csnet-relay.arpa> | |
9289 | Message-Id: <8410311853.AA14678@csvaxa.ARPA> | |
9290 | To: FRANZ-FRIENDS%ucb-vax.arpa@csnet-relay.arpa | |
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%bostonu.csnet@CSNET-RELAY.CSNET | |
9298 | ||
9299 | Thank you, -Raf | |
9300 | ||
9301 | From neves%wisc-ai.uwisc@wisc-crys.ARPA 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%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) | |
9309 | Message-Id: <8410312035.AA25488@wisc-ai.uwisc> | |
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:iaeh@cmu-ri-isl2.arpa 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: <8411010114.AA02960@UCB-VAX.ARPA> | |
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%BOSTONU.bitnet@WISCVM.ARPA 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: <8411020000.AA08850@UCB-VAX.ARPA> | |
9345 | Received: from ENG20201@BOSTONU.BITNET 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%BOSTONU.bitnet@WISCVM.ARPA> | |
9349 | Subject: Pretty typer | |
9350 | To: franz-friends@BERKELEY | |
9351 | Cc: eng20201%BOSTONU.bitnet@WISCVM.ARPA | |
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%ubc.csnet@csnet-relay.arpa 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%ubc.csnet@csnet-relay.arpa> | |
9374 | To: franz-friends%ucb-vax.arpa@csnet-relay.arpa | |
9375 | Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA | |
9376 | Message-Id: 133:holtz@carleton.cdn | |
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%ubc.csnet@csnet-relay.arpa 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%ubc.csnet@csnet-relay.arpa> | |
9394 | To: franz-friends%ucb-vax.arpa@csnet-relay.arpa | |
9395 | Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA | |
9396 | Message-Id: 133:holtz@carleton.cdn | |
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%ucb-vax.arpa@csnet-relay.arpa 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%ucb-vax.arpa@csnet-relay.arpa> | |
9420 | Message-Id: <8411050659.AA03601@ucbopal.CC.Berkeley.ARPA> | |
9421 | To: franz-friends%ucb-vax.arpa%csnet-relay.arpa@csnet-relay.arpa, | |
9422 | holtz%carleton.cdn%ubc.csnet%csnet-relay.arpa@csnet-relay.arpa | |
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: <8411051938.AA06184@UCB-VAX.ARPA> | |
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 asb@SCRC-STONY-BROOK.ARPA 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: <8411070012.AA06061@UCB-VAX.ARPA> | |
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 <asb@SCRC-CUPID.ARPA> | |
9584 | Subject: Job Opportunities | |
9585 | To: maple-sys@BERKELEY, symalg%rand-unix.arpa%csnet-relay.arpa@SCRC-CUPID.ARPA, | |
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 ssc-vax!steve@uw-beaver.arpa 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: ssc-vax!steve@uw-beaver.arpa (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: <8411081546.AA17112@UCB-VAX.ARPA> | |
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: <8411081959.AA22393@UCB-VAX.ARPA> | |
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 BACH@SU-SCORE.ARPA 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: <8411082222.AA25584@UCB-VAX.ARPA> | |
9748 | Date: Thu 8 Nov 84 14:21:16-PST | |
9749 | From: Rene Bach <BACH@SU-SCORE.ARPA> | |
9750 | Subject: printing delayed in Eunice | |
9751 | To: franz-friends@BERKELEY | |
9752 | Cc: bach@SU-SCORE.ARPA | |
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 JonL.pa@Xerox.ARPA 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: <8411082330.AA27172@UCB-VAX.ARPA> | |
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: JonL.pa@XEROX.ARPA | |
9779 | Subject: Re: readtable within fasl | |
9780 | In-Reply-To: Steven M. Haflich <smh@mit-eddie.ARPA>'s message of Thu, 8 | |
9781 | Nov 84 10:33:41 est | |
9782 | To: smh@mit-eddie.ARPA | |
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:nss@cmu-ri-isl3.arpa 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: <8411092006.AA04311@UCB-VAX.ARPA> | |
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:day@cmu-cs-h.arpa 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: <8411111954.AA15747@UCB-VAX.ARPA> | |
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%udel-dewey.delaware@udel-relay.ARPA 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: <8411120308.AA21463@UCB-VAX.ARPA> | |
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%udel-dewey.delaware@udel-relay.ARPA> | |
9867 | To: David.Yaskin@cmu-cs-h.ARPA | |
9868 | Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA | |
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%udel-dewey.delaware@udel-relay.ARPA 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: <8411120329.AA21770@UCB-VAX.ARPA> | |
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%udel-dewey.delaware@udel-relay.ARPA> | |
9925 | To: Nancy.Skooglund@cmu-ri-isl3.ARPA | |
9926 | Cc: franz-friends@BERKELEY, johnson%udel-eecis1.delaware@udel-relay.ARPA | |
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:nss@cmu-ri-isl1.arpa 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: <8411121442.AA01316@UCB-VAX.ARPA> | |
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 JAAKOV@WISDOM.BITNET 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: jaakov@wisdom.BitNet (Jacob Levy) | |
9978 | Message-Id: <8411130929.AA01997@wisdom.BITNET> | |
9979 | To: franz-list@wisdom.BitNet | |
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%wisdom.bitnet@wiscvm.ARPA | |
10037 | UUCP: (if all else fails..) ..!decvax!humus!wisdom!jaakov | |
10038 | ||
10039 | ||
10040 | ||
10041 | ||
10042 | From ssc-vax!steve@uw-beaver.arpa 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: <ssc-vax!steve@uw-beaver.arpa> | |
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: ssc-vax!steve@uw-beaver.arpa (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 ucscc!pravda@ucscd.ucscc.UUCP 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: ucscc!pravda@ucscd.ucscc.UUCP (05550000) | |
10104 | Message-Id: <8411151845.AA04900@ucscd.UCSC> | |
10105 | To: ucbvax!franz-friends@c.CC | |
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 weeks@ucbruby.CC 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: weeks@ucbruby.CC (Harry Weeks) | |
10129 | Message-Id: <8411160450.AA02961@ucbruby.CC.Berkeley.ARPA> | |
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:tg@cmu-cs-cad.arpa 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: <8411281932.AA14658@UCB-VAX.ARPA> | |
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 <smith@nrl-aic.ARPA> | |
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 MCLINDEN@RUTGERS.ARPA 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: <8412012228.AA03439@UCB-VAX.ARPA> | |
10227 | Date: 30 Nov 84 22:45:59 EST | |
10228 | From: Sean McLinden <MCLINDEN@RUTGERS.ARPA> | |
10229 | Subject: Re: bugs using flavors (and more) | |
10230 | To: smith@NRL-AIC.ARPA, franz-friends@BERKELEY | |
10231 | Cc: MCLINDEN@RUTGERS.ARPA | |
10232 | In-Reply-To: Message from "Russ Smith <smith@nrl-aic.ARPA>" 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%wsu.csnet@csnet-relay.arpa 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: <8412020050.AA08322@ucbernie.ARPA> | |
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%wsu.csnet@csnet-relay.arpa> | |
10257 | To: franz-friends@UCBERNIE.ARPA | |
10258 | Cc: sridhar%wsu.csnet@csnet-relay.arpa | |
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 <smith@nrl-aic.ARPA> | |
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: <8412042013.AA24636@UCB-VAX.ARPA> | |
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: <8412042126.AA26237@UCB-VAX.ARPA> | |
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: <8412050450.AA05974@UCB-VAX.ARPA> | |
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 MAILER@CUNYVM.BITNET 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: <8412061944.AA27252@ucbjade.CC.Berkeley.ARPA> | |
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 <HJNCU@CUNYVM.BitNet> | |
10500 | To: <sf-lovers-request@rutgers.arpa>, <franz-friends@BERKELEY>, | |
10501 | <ailist-request@sri-ai>, <works@rutgers.arpa>, | |
10502 | <info-graphics@utexas-20.arpa>, <prolog-request@su-score.arpa> | |
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 mike@rice.ARPA 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 <mike@rice.ARPA> | |
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:POSTMASTER@VANDERBILT.MAILNET 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 <2648813816713007@MIT-MULTICS.ARPA>; 08 Dec 1984 08:36:56 est | |
10540 | Date: 06 Dec 84 15:26 CDT | |
10541 | From: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA | |
10542 | Reply-To: David_Linn%VANDERBILT.MAILNET@MIT-MULTICS.ARPA | |
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 MOHAN@USC-ECLC.ARPA 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: <8412102004.AA04397@UCB-VAX.ARPA> | |
10562 | Date: Mon 10 Dec 84 12:03:06-PST | |
10563 | From: MOHAN@USC-ECLC.ARPA | |
10564 | Subject: array - space | |
10565 | To: franz-friends@BERKELEY | |
10566 | Cc: mohan@USC-ECLC.ARPA | |
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 mike@rice.ARPA 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 <mike@rice.ARPA> | |
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: <8412110004.AA06150@ucbmike.arpa> | |
10622 | To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY | |
10623 | Subject: Re: array - space | |
10624 | Cc: mohan@USC-ECLC.ARPA | |
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: <8412110108.AA06315@ucbmike.arpa> | |
10644 | To: MOHAN@USC-ECLC.ARPA, franz-friends@BERKELEY | |
10645 | Subject: Re: array - space | |
10646 | Cc: mohan@USC-ECLC.ARPA | |
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: <8412110221.AA11754@UCB-VAX.ARPA> | |
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 BACH@SUMEX-AIM.ARPA 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: <8412120403.AA15218@UCB-VAX.ARPA> | |
10729 | Date: Tue 11 Dec 84 20:04:16-PST | |
10730 | From: Rene Bach <BACH@SUMEX-AIM.ARPA> | |
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 MCLINDEN@RUTGERS.ARPA 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: <8412120442.AA16044@UCB-VAX.ARPA> | |
10752 | Date: 11 Dec 84 23:41:49 EST | |
10753 | From: Sean McLinden <MCLINDEN@RUTGERS.ARPA> | |
10754 | Subject: Re: Franz documentation for MIT LM code | |
10755 | To: smh%MIT-EDDIE@MIT-MC.ARPA, franz-friends@BERKELEY | |
10756 | Cc: sridhar%wsu.csnet@CSNET-RELAY.ARPA, MCLINDEN@RUTGERS.ARPA | |
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: <8412130503.AA07258@UCB-VAX.ARPA> | |
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: <8412171704.AA19421@UCB-VAX.ARPA> | |
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: <8412172103.AA15009@ucbmike.arpa> | |
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: <8412172108.AA15044@ucbmike.arpa> | |
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:wah@cmu-cs-ius.arpa 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: <8412172107.AA24610@UCB-VAX.ARPA> | |
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 cadwall@Ardc.ARPA 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: <8412172130.AA25405@UCB-VAX.ARPA> | |
10916 | Date: Mon, 17 Dec 84 16:23:16 EST | |
10917 | From: William K. Cadwallender (LCWSL) <cadwall@Ardc.ARPA> | |
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: <8412181954.AA26165@tove.ARPA> | |
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 | <8412172107.AA24610@UCB-VAX.ARPA> | |
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:wah@cmu-cs-ius.arpa 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: <8412190015.AA10079@UCB-VAX.ARPA> | |
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 johnson@UDEL-EECIS2.DELAWARE 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: <8501021051.AA01144@UCB-VAX.ARPA> | |
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%wsu.csnet@csnet-relay.arpa 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: <8501240831.AA15268@ucbernie.ARPA> | |
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%wsu.csnet@csnet-relay.arpa> | |
11016 | To: cross%lsu.csnet@csnet-relay.arpa | |
11017 | Cc: franz-friends@UCBERNIE.ARPA | |
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 fsbrn@BRL-VOC.ARPA 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: <8501241316.AA00666@UCB-VAX.ARPA> | |
11033 | Date: Thu, 24 Jan 85 7:59:46 EST | |
11034 | From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA> | |
11035 | To: "S. Sridhar" <sridhar%wsu.csnet@CSNET-RELAY.ARPA> | |
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: <8501241400.AA00458@UCB-VAX.ARPA> | |
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: <8502062000.AA08198@sri-spam.ARPA> | |
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: <8502062136.AA10406@utah-orion.ARPA> | |
11125 | To: peck@sri-spam.ARPA | |
11126 | Cc: ailist-request@sri-ai.ARPA, 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 | <8502062000.AA08198@sri-spam.ARPA> | |
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: <8502211938.AA09421@cvl.ARPA> | |
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: <8502212053.AA16858@ucbdali.ARPA> | |
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%rpi.csnet@csnet-relay.arpa 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: <8502251243.AA24603@UCB-VAX.ARPA> | |
11265 | Received: from rpi by csnet-relay.csnet id a012112; 25 Feb 85 7:24 EST | |
11266 | From: freemant%rpi.csnet@csnet-relay.arpa | |
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: <8502272017.AA25775@gymble.ARPA> | |
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 neves@wisc-ai.arpa 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: neves@wisc-ai.arpa (David Neves) | |
11427 | Message-Id: <8502281934.AA26546@wisc-ai.arpa> | |
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%ibm-sj.csnet@csnet-relay.arpa 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: <8503010012.AA05586@UCB-VAX.ARPA> | |
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%ibm-sj.csnet@csnet-relay.arpa> | |
11458 | To: info-ibmpc@usc-isi.ARPA, 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 johnson@udel-dewey.ARPA 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: <8503011221.AA18449@UCB-VAX.ARPA> | |
11480 | Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a009017 | |
11481 | ;1 Mar 85 7:18 EST | |
11482 | To: David Neves <neves@wisc-ai.arpa> | |
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 | <8502281934.AA26546@wisc-ai.arpa> | |
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!!!\\a\\a "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: <8503012113.AA28355@UCB-VAX.ARPA> | |
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 | \v\v | |
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: <8503041405.AA03832@UCB-VAX.ARPA> | |
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: <8503012137.AA00121@ucbkim.ARPA> | |
11970 | To: <jshaver@apg-3> | |
11971 | ||
11972 | ----- Transcript of session follows ----- | |
11973 | >>> RCPT To:<franz-friends-3@ucbmike.BERKELEY> | |
11974 | <<< 550 <franz-friends-3@ucbmike.BERKELEY>... User unknown | |
11975 | 550 franz-friends-3@ucbmike... User unknown | |
11976 | >>> RCPT To:<franz-friends-score@ucbmike.BERKELEY> | |
11977 | <<< 550 <franz-friends-score@ucbmike.BERKELEY>... 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: <8503012113.AA28355@UCB-VAX.ARPA> | |
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 | \v\v | |
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: <8503041410.AA03880@UCB-VAX.ARPA> | |
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: <8503012205.AA29648@UCB-VAX.ARPA> | |
12023 | Date: 1 Mar 85 17:8:8 EST | |
12024 | From: Mailer <Gripe@CMU-CS-A.ARPA> | |
12025 | To: <@BERKELEY:jshaver@apg-3> | |
12026 | Reply-To: Gripe <Gripe@CMU-CS-A.ARPA> | |
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: <8503012113.AA28355@UCB-VAX.ARPA> | |
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 | \v\v | |
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 fsbrn@BRL-VOC.ARPA 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: <8503051611.AA09879@UCB-VAX.ARPA> | |
12073 | Date: Tue, 5 Mar 85 11:13:21 EST | |
12074 | From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA> | |
12075 | To: Franz-Friends@BERKELEY | |
12076 | Cc: Meself <fsbrn@BRL-VOC.ARPA> | |
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 fsbrn@BRL-VOC.ARPA 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: <8503052115.AA16643@UCB-VAX.ARPA> | |
12131 | Date: Tue, 5 Mar 85 16:14:14 EST | |
12132 | From: "Ferd Brundick (VLD/LTTB)" <fsbrn@BRL-VOC.ARPA> | |
12133 | To: Franz-Friends@BERKELEY | |
12134 | Cc: Ferd Brundick <fsbrn@BRL-VOC.ARPA>, kanderso@bbn-vax.ARPA | |
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 hamscher@MIT-HTVAX.ARPA 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 <hamscher@MIT-HTVAX.ARPA> | |
12167 | Message-Id: <8503191950.AA21434@MIT-HTVAX.ARPA> | |
12168 | To: Franz-Friends@BERKELEY | |
12169 | Subject: Franz -> Common Lisp ? | |
12170 | ||
12171 | Reply-to: hamscher@mit-htvax.arpa | |
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: <8503210048.AA01825@utah-cs.ARPA> | |
12213 | To: Franz-Friends@BERKELEY, hamscher@mit-htvax.arpa | |
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 ingrid@UCLA-LOCUS.ARPA 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 <ingrid@UCLA-LOCUS.ARPA> | |
12230 | To: franz-friends@BERKELEY | |
12231 | Subject: setq command changes code | |
12232 | Message-Id: <480278128-16289-ingrid@UCLA-LOCUS.ARPA> | |
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: <8503260136.AA00961@franz.uucp> | |
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: <8503260337.AA01276@franz.uucp> | |
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%ubc.csnet@csnet-relay.arpa 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%ubc.csnet@csnet-relay.arpa> | |
12322 | Message-Id: <8503262000.AA09422@ubc-vision.UUCP> | |
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 | carter@ubc-vision.UUCP | |
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: <8503270006.AA03620@ucbkim.ARPA> | |
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: <8503270017.AA23203@maryland.ARPA> | |
12406 | To: carter%ubc.csnet@csnet-relay.ARPA | |
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: <8503270133.AA16864@rand-unix.ARPA> | |
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 | <8503270006.AA03620@ucbkim.ARPA> | |
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: <8503270230.AA07153@ucbkim.ARPA> | |
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: <8503270907.AA03594@ucbrenoir.ARPA> | |
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: <8503271559.AA06162@franz.uucp> | |
12594 | To: hilfingr@ucbrenoir.BERKELEY, narain@rand-unix.ARPA, mcgeer@ucbkim.BERKELEY | |
12595 | Subject: Re: Lisp is faster than Prolog? A personal plea | |
12596 | Cc: franz-friends@ucbkim.BERKELEY, 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: <8503271822.AA15354@ucbkim.ARPA> | |
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: <8503300022.AA29100@sri-spam.ARPA> | |
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: <8503300050.AA04603@ucbdali.ARPA> | |
12690 | To: jeffr@sri-spam.ARPA | |
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 | <8503300022.AA29100@sri-spam.ARPA> | |
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 weeks@ucbruby.CC 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: weeks@ucbruby.CC (Harry Weeks) | |
12715 | Message-Id: <8503300221.AA10320@ucbruby.CC.Berkeley.ARPA> | |
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%ubc.csnet@csnet-relay.arpa 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%ubc.csnet@csnet-relay.arpa> | |
12785 | Message-Id: <8504030027.AA14795@ubc-vision.UUCP> | |
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 | carter@ubc-vision.UUCP | |
12794 | ||
12795 | From dennis%boulder.csnet@csnet-relay.arpa 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: <8504040304.AA24595@UCB-VAX.ARPA> | |
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%boulder.csnet@csnet-relay.arpa> | |
12806 | To: carter%ubc.csnet@csnet-relay.arpa, 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:prlb2!vauclair@seismo.ARPA 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: <prlb2!vauclair@seismo.ARPA> | |
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: prlb2!vauclair@seismo.ARPA (Marc Vauclair) | |
12836 | Message-Id: <8504050836.AA01128@prlb2.UUCP> | |
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: <8504051837.AA00261@franz.uucp> | |
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 | liz@tove.arpa 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: <8504061736.AA10092@tove.ARPA> | |
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 | <8504051837.AA00261@franz.uucp> | |
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 bane@gymble.arpa or seismo!umcp-cs!bane. | |
13126 | ||
13127 | -Liz | |
13128 | ||
13129 | ||
13130 | From wfi%ucsc.csnet@csnet-relay.arpa 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: <8504091027.AA14376@UCB-VAX.ARPA> | |
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:wfi@ucsc.CSNET (Wayne F. Iba)> | |
13141 | To: franz-friends@BERKELEY | |
13142 | Subject: franz profiling | |
13143 | Cc: wfi@ucsc.CSNET | |
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: <8504091741.AA17861@rand-unix.ARPA> | |
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: <8504100037.AA05175@sri-spam.ARPA> | |
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%scarolina.csnet@csnet-relay.arpa 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: <8504140732.AA13927@UCB-VAX.ARPA> | |
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%scarolina.csnet@csnet-relay.arpa> | |
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: <8504151929.AA12668@rand-unix.ARPA> | |
13242 | Date: 15 Apr 85 11:29:40 PST (Mon) | |
13243 | To: Bonnell <g_keaton%scarolina.csnet@csnet-relay.ARPA> | |
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 | <8504140732.AA13927@UCB-VAX.ARPA> | |
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: <8504201950.AA08585@ucbdali.ARPA> | |
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 smh@mit-eddie.ARPA 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 <smh@mit-eddie.ARPA> | |
13286 | Message-Id: <8504212211.AA03273@mit-eddie.ARPA> | |
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:wah@cmu-cs-ius.arpa 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: <8504240146.AA10636@UCB-VAX.ARPA> | |
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: <8504242000.AA15012@tove.ARPA> | |
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 | <8504240146.AA10636@UCB-VAX.ARPA> | |
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 | |
3cdae440 | 13394 | |
ca67e7b4 C |
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: <8506172054.AA25593@UCB-VAX.ARPA> | |
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: Jaffe@cmu-psy-a.arpa | |
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: Jaffe@cmu-psy-a.ARPA | |
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: <8506200610.AA09405@rand-unix.ARPA> | |
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 | <8506172054.AA25593@UCB-VAX.ARPA> | |
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: <8506242315.AA11802@sri-spam.ARPA> | |
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: <8506272021.AA08257@gymble.ARPA> | |
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: <8507010211.AA11456@anl-mcs.ARPA> | |
13545 | To: bane@gymble.ARPA, 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: <8507032245.AA08158@sri-spam.ARPA> | |
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: <8507081658.AA03142@UCB-VAX.ARPA> | |
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: <8507091449.AA02537@tove.ARPA> | |
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 | <8507081658.AA03142@UCB-VAX.ARPA> | |
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: <8507091412.AA10613@anl-mcs.ARPA> | |
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 JPG@MIT-MC.ARPA 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 <JPG@MIT-MC.ARPA> | |
13683 | Subject: Franz Lisp for Eunice 4.1 | |
13684 | To: franz-friends@BERKELEY | |
13685 | Cc: JPG@MIT-MC.ARPA | |
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: <8507151602.AA08819@UCB-VAX.ARPA> | |
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 | Zoll@Cmu-Psy-A.Arpa | |
13774 | ||
13775 | ||
13776 | From KASHTAN@SRI-AI.ARPA 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: <8507152052.AA05591@UCB-VAX.ARPA> | |
13782 | Date: Mon 15 Jul 85 13:56:28-PDT | |
13783 | From: KASHTAN@SRI-AI.ARPA | |
13784 | Subject: Re: Franz, Eunice, 4.0 | |
13785 | To: jpg@MIT-MC.ARPA, zoll@CMU-PSY-A.ARPA | |
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:KS20@CMU-CS-A.ARPA 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: <8507221417.AA22657@UCB-VAX.ARPA> | |
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 Schwan@ohio-state.csnet or schwans@cmua | |
13835 | ||
13836 | ||
13837 | ||
13838 | From john%mtu.csnet@csnet-relay.arpa 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: <8508192122.AA06773@UCB-VAX.ARPA> | |
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%mtu.csnet@csnet-relay.arpa> | |
13849 | To: franz-friends@BERKELEY | |
13850 | Subject: List Membership | |
13851 | Cc: john@mtu.CSNET | |
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%smu.csnet@csnet-relay.arpa 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%smu.csnet@csnet-relay.arpa | |
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: <8509120048.AA06062@ucbdali.ARPA> | |
13915 | To: rsm@carl.UTEXAS.EDU | |
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: <8509242311.AA14107@UCB-VAX.ARPA> | |
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%umn.csnet@CSNET-RELAY.ARPA> | |
13935 | To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa | |
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%umn.csnet@csnet-relay.arpa | |
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: <8509250413.AA20438@UCB-VAX.ARPA> | |
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%umn.csnet@CSNET-RELAY.ARPA> | |
13970 | To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa, | |
13971 | franz-friends@berkley, moen@umn.CSNET | |
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%umn.csnet@csnet-relay.arpa | |
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: <8509250413.AA20453@UCB-VAX.ARPA> | |
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%umn.csnet@CSNET-RELAY.ARPA> | |
14019 | To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa, | |
14020 | franz-friends@BERKELEY, moen@umn.CSNET | |
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.]\b | |
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%umn.csnet@csnet-relay.arpa | |
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: <8509250414.AA20463@UCB-VAX.ARPA> | |
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%umn.csnet@CSNET-RELAY.ARPA> | |
14122 | To: ailist@sri-ai.arpa, franz-friends%ucb-vax@csnet-relay.arpa, | |
14123 | franz-friends@BERKELEY, moen@umn.CSNET | |
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.]\b | |
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%umn.csnet@csnet-relay.arpa | |
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 sokol@mitre.ARPA 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: <8510071356.AA11068@mitre.ARPA> | |
14222 | To: franz-friends@BERKELEY | |
14223 | Cc: sokol@mitre.ARPA | |
14224 | Subject: arpa list | |
14225 | Date: 07 Oct 85 09:55:24 EDT (Mon) | |
14226 | From: Lisa Sokol <sokol@mitre.ARPA> | |
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 dcdwest!benson@SDCSVAX.ARPA 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: dcdwest!benson@SDCSVAX.ARPA (Peter Benson) | |
14242 | Date: Fri, 11 Oct 85 15:14:30 pdt | |
14243 | Message-Id: <8510112214.AA04005@dcdwest.ITT> | |
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: <8510302021.AA19284@dali.ARPA> | |
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%mrca.co.uk@ucl-cs.arpa 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%mrca.co.uk@ucl-cs.arpa> | |
14292 | To: franz-friends <franz-friends%ucb-vax.arpa@ucl-cs.arpa> | |
14293 | Date: Tue, 5 Nov 85 09:04 | |
14294 | Subject: Receiving "franz-friends" | |
14295 | Message-Id: <05 NOV 1985 09:15:13 YE15@uk.co.mrca> | |
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%uk.co.mrca@uk.ac.ucl.cs) | |
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%uk.co.mrca@uk.ac.ucl.cs) | |
14318 | ||
14319 | ||
14320 | ||
14321 | ||
14322 | From bzs%buit4%bostonu.csnet@csnet-relay.arpa 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%bostonu.csnet@csnet-relay.arpa> | |
14335 | Message-Id: <8511100036.AA05580@buit4.ARPA> | |
14336 | To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA | |
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%bostonu.csnet@csnet-relay.arpa 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%bostonu.csnet@csnet-relay.arpa> | |
14367 | Message-Id: <8511101942.AA09529@buit1.ARPA> | |
14368 | To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA | |
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%bostonu.csnet@csnet-relay.arpa 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%bostonu.csnet@csnet-relay.arpa> | |
14412 | Message-Id: <8511110632.AA00418@buit1.ARPA> | |
14413 | To: franz-friends%berkeley.CSNET@CSNET-RELAY.ARPA | |
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 |