*start* 00689 00071 UUm @00045 01536 ftffffffffffffffffffffffffffffff @Date: 7 APR 84 23:04 PST From: MASINTER.PA Subject: LispUsers packages To: DONC@ISIF cc: lispsupport Don, I don't know if I ever answered your message about LispUsers packages. I've got ALL, COMMENT, and a few others. I think the Pasadena support staff has adopted a new policy tht they're not going to distribute stuff without testing it out. Maybe we should set up a separate real LISPUSERS directory tht everybody in the Interlisp world could contribute to , and then you would just FTP the files there (I'm worried for example tht we don't have the most recent versions. Wanna check out [maxc]? *start* 02592 00071 UUm @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: DONC@USC-ISIF Received: from USC-ISIF by Xerox.ARPA ; 09 APR 84 10:58:06 PST Date: 9 Apr 84 10:55:55 PST Subject: Re: LispUsers packages From: Don.Cohen To: MASINTER.PA, DONC@USC-ISIF.ARPA cc: lispsupport.PA In-Reply-To: (Message from "MASINTER.PA@XEROX" of 7 APR 84 23:04 PST) I can't tell what's up-to-date on maxc (I can do a directory thru ftp, but not a vdir, and can't login as anonymous thru telnet...), so I'll let you see what's current and what's not. Judging from my collection of .tty files, I have the following packages (here's my vdirectory): [USC-ISIF] 9-Apr-84 10:38:31 PS: TRACEIN..18;P775252 7 16673(7) 14-Mar-84 10:37:51 DONC .TTY.5;P775252 5 10706(7) 19-Dec-83 16:00:23 DONC ALL.COM.12;P775252 4 9588(7) 20-Dec-82 17:00:31 DONC .LISP.35;P775252 3 7171(7) 20-Dec-82 16:59:12 DONC .TTY.4;P775252 1 2483(7) 10-May-82 10:21:30 DONC COMMENTS..5;P775252 3 7611(7) 21-Dec-82 17:44:42 DONC .COM.5;P775252 4 9041(7) 21-Dec-82 17:45:38 DONC .TTY.1;P775252 3 5532(7) 7-Dec-82 11:40:48 DONC WAKEUP..11;P775252 1 1281(7) 20-Dec-82 17:33:39 DONC .COM.2;P775252 1 1840(7) 20-Dec-82 17:38:45 DONC .TTY.1;P775252 1 419(7) 2-Dec-82 13:21:02 DONC LOSTLISTS..17;P775252 3 6090(7) 11-Apr-82 09:50:51 DONC .COM.8;P775252 3 5839(7) 11-Apr-82 09:51:09 DONC .TTY.4;P775252 3 5793(7) 11-Apr-82 10:36:42 DONC PQUOTE..5;P775252 1 1352(7) 9-Apr-84 10:25:41 DONC .TTY.2;P775252 1 931(7) 9-Apr-84 10:33:23 DONC Total of 44 pages in 16 files I welcome testing, especially if I can get the feedback. As a summary of these packages: PQUOTE is, I think, a better version of the PQUOTE that you have (and perhaps ought to be part of the standard Interlisp). LostLists is only for Interlisp-10 (but it's quite useful there). Wakeup is fairly trivial, only useful if your terminal can beep. Comments is a documentation package (see how you like it). All simply organizes files by the word being defined, rather than by filepkgtype. Tracein is a very useful debugging facility - one could make a pretty good argument that it should be part of standard interlisp (the same argument would hold for EVALHOOK.) - works in every interlisp as far as I know. ------- *start* 00424 00071 UUm @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Apr 84 18:55:19 PST (Wednesday) From: masinter.PA Subject: Re: LispUsers packages In-reply-to: DONC's message of 9 Apr 84 10:55:55 PST To: Don.Cohen cc: LispSupport, 1100Support What I meant to say was: Note that Interlisp-D now has an EVALHOOK package (that I wrote) and if you get a chance, I'd like you to test it. *start* 01133 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: masinter.pa Date: 24-Apr-84 7:47:17 PST Subject: query from potential user To: LispSupport answer follows. Can you answer the one about GettingStarted (e.g., make an Interpress version?) ---------- Date: 23 Apr 84 11:49:32 PST (Monday) From: Schiller.PA Subject: Re: Symbolic Manipulation In-reply-to: Your message of 19 Apr 84 16:23:22 PST (Thursday) To: Masinter cc: Schiller I have some questions: Is there an interpress or text version of gettingStarted.press (I tried using PressToInterpress on it but the result isn't very readable)? What is gettingStarted.doc? It appears to be a binary file. I assume 12K pages is the absolute minimum for an interlisp-d volume. This would imply that performance would be better if the volume is bigger. Would say, a 16K or 14K volume be worth the space for this type of application? Does the interLisp volume have to have a particlaur name? Could I use, say, the star user volume on my machine? Could I use InstallLisp.othello for this purpose by changing some names in that file? thanks, stephen *start* 01055 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: masinter.pa Date: 24-Apr-84 7:53:33 PST Subject: Re: Symbolic Manipulation In-reply-to: Your message of 23 Apr 84 11:49:32 PST (Monday) To: Schiller cc: LispSupport reply-to: LispSupport We'll try to make an interpress version of GettingStarted. The .doc file is produced by the Interlisp text editor. It looks like it is binary but the text is all at the beginning (there is some binary formatting information at the end.) having a bigger volume doesn't make lisp run any faster -- it just means that it takes less time before you run out of room. The Maximum that will do any good is 16200 pages. While you use Othello to install it (and can install it on your User volume by changing the name in the Othello scriopt since Lisp doesn't care what volume name you use, don't put it on the same volume with any data that you care about. So: sure, put it on User, but if you want Star to use User, then erase the whole volume first. You must have 768K words = 1536K bytes. *start* 01366 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 24 Apr 84 13:19 EST From: Hannaway.wbst Subject: Lisp: Questions about 1108 To: LispSupport.pa cc: Hannaway.wbst I'm working with someone designing (large) interfaces with Trillium on a Dandelion. He's been having a lot of problems getting 9915 errors, and once they occur, there seems to be no way to even save all his work. They come with no warning and the only commonality that I can see is that they happen after working for a long time with one sysout. My questions are: 1. What is a 9915? We can't find any documentation on it. I know that you can use Teleraid from another machine after getting this error, but I haven't been able to figure out anything useful to do from it. Any suggestions? 2. The only reason I can think of for these problems is that he runs out of virtual memory. Is there any way to check for that? On the Dolphins, you at least get a break window or sent into Raid when your virtual memory is full. Do the Dandelions do that? 3. What is the maximum number of pages that the Lisp volume be on the Dandelion? I'd really appreciate any help you can give. I'm tired of watching people lose 8 hours of work! Thanks a lot. Pat P.S. For my own information, what is the maximum number of pages for the Lisp.Virtualmem on a Dolphin? Thanks. *start* 01759 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 24 Apr 84 16:38:33 PST (Tuesday) Subject: Re: Lisp: Questions about 1108 In-reply-to: Hannaway.wbst's message of 24 Apr 84 13:19 EST To: Hannaway.wbst cc: LispSupport From: LispSupport.pa Reply-To: LispSupport.pa "What is a 9915?" -- 9915 is the MP code for "Raid", a catch-all error for a variety of internal lisp system errors. Gradually, some of these errors are being given seperate MP codes of their own, in the range 9300-9399. Using Teleraid from a DLion, the most useful things you could do would be to type ^B, which will (usually) return to lisp and cause a break. From this break, you can find out what the stack was at the time of the error. It is very important to tell us this information when you report a bug --- "my machine gets a lot of MP 9915 errors" could be anything. "Is there any way to check for ... running out of virtual memory" -- typing (STORAGE) will give a printout of the amounts of allocated and free pages for the various datatypes. The most important numbers are in the summary at the very end; (STORAGE NIL 9999) will just print the summary. If the number of "free" pages is low, you could indeed have a problem with running out of virtual memory. If this does seem to be the problem (unlikely), the program may be holding on to a lot of information it doesn't need, and the working set may be expanding unnecessarily. "What is the maximum number of pages that the Lisp volume be on the Dandelion?" -- the virtual memory expands up to 16200 pages, at which point the virtual address space runs out. Therefore, there is no point in configuring a DLion lisp volume with more than 16200 pages, though it is possible. *start* 00683 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: SCHOEN@SUMEX-AIM.ARPA Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 24 APR 84 18:51:38 PST Date: Sun, 22 Apr 84 14:50:58 PST From: Eric Schoen Subject: Interlan software To: 1100users@SUMEX-AIM.ARPA Interlan and Technology Concepts Inc (which uses Interlan hardware) together might be able to help. While developing Etherway, TCI wrote an intermediate software layer called ECDRIVER which sorts out Ethernet protocol types and gives them to the appropriate consumer. Check with TCI about getting that layer of protocol. Eric ------- *start* 01604 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Wed, 2 May 84 14:28 PDT Sender: Sannella.PA From: Masinter.pa Subject: [Kluger.PA: Press to Interpress] To: lispsupport --------------------------- Date: 27 Mar 84 15:05 PST From: Masinter.pa Subject: [Kluger.PA: Press to Interpress] To: LispCore^, sheil A press-> Interpress converter in mesa ----- Forwarded Messages ----- Date: 23 Mar 84 10:56:10 PST (Friday) From: Kluger.PA Subject: Press to Interpress To: Internet^.wbst Reply-To: Kluger.PA As is so often the case, Victor came through with the information! Larry ---------------------------------------------------------------- Date: 23 Mar 84 09:19:36 GMT (Friday) From: Schwartz.rx Subject: Re: The internet In-reply-to: Kluger.PA's message of 22 Mar 84 21:38:03 PST (Thursday) To: Kluger.PA cc: Schwartz, ljmiller.WBST, Cooper Larry, Sorry if you've already received 18 zillion replies on this one, but a Press to Interpress converter already exists. I was surprised to discover this too. I just found out about it LAST WEEK! It's on: [IGOR]10.0>tools>PressToInterpress.Bcd 10.0>Doc>PressToInterpress.Doc I assume someone could easily convert it to 11.0. (Author is ljmiller.WBST , creation 1-Dec-83). Martin Cooper (here in SDD-RX) has used this tool, and it works quite well (although there are 1 or 2 things which should be fixed up.) Victor ---------------------------------------------------------------- ----- End of Forwarded Messages ----- ------------------------------------------------------------ *start* 00998 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 15 May 84 10:46 PDT From: Sannella.pa Subject: [Sannella.PA: Blank AR] To: lispsupport ----- Forwarded Messages ----- Date: 10 May 84 11:38:55 PDT (Thursday) From: Sannella.PA Subject: Blank AR To: Masinter cc: Sannella It appears that the AR that you submitted at 9-May-84 17:29:48 is totally blank (size =0 chars). This is probably the one refered to in the message below. Could you please resubmit this information. I don't know how AR.FORM could have permitted this, but I am investigating. Did you abort the AR.FORM prematurely, or do something else unusual? ----- Date: 9 May 84 17:31 PDT From: masinter.pa Subject: AR submitted: include documentation on how to use VAX w/4.2 BSD unix To: PYoung.pasa cc: vanMelle, Raim.pasa, LispSupport I submitted an AR (using AR.FORM) about this, including the documentation that Schmidt put together for using Safe. ----- End of Forwarded Messages ----- *start* 00296 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 20 MAY 84 14:32 PDT From: MASINTER.PA Subject: documentation on using a Unix as a file server name To: lispsupport I dunno what happened. The documentation is available from Chris Schmidt. The AR is attn to PYoung. *start* 00484 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 21 May 84 15:18:29 PDT (Monday) Subject: need documentation on using Safe To: SCHMIDT@SUMEX-AIM.ARPA cc: LispSupport.pa From: LispSupport.pa Reply-To: LispSupport.pa A few weeks ago, Larry Masinter got some info from you on "how to use VAX w/4.2 BSD unix". Apparently, that documentation has gotten lost. Could you please forward it to LispSupport.pa (or give me a pointer). Thanks. *start* 00695 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 21 MAY 84 17:55:03 PDT Date: Mon, 21 May 84 17:54:50 PDT From: Christopher Schmidt Subject: Re: need documentation on using Safe To: LispSupport.pa In-Reply-To: Message from "LispSupport.pa@XEROX.ARPA" of Mon 21 May 84 15:18:29-PDT Sorry, I haven't re-written our help file to reflect unix 4.2 yet. I don't know what Larry gave you. Perhaps my letter to our users? It's not particularly good, but I can find a copy if you want. I'll send you a not when I re-write it; probably next week. --Christopher ------- *start* 00964 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 30 May 84 16:53 PDT From: Masinter.pa Subject: Re: DSK device on 1108 In-reply-to: Ueda.FX's message of 29 May 84 18:10:19 PDT (Tuesday) To: Ueda.FX cc: Masinter.PA, Kamibayashi.FX, Ikeo.FX, 1100Support.pasa, LispSupport I was speaking with Dr. Kamibayashi about the Carol release, which is in system test and scheduled to be shipped to customers relatively soon. I believe it would be simple for you to become a 'beta tester' since the files are on [phylum]Current>. I have insured that all members of the "FX" registry can add themselves to the "LispUsers^.pa" distribution list. You should probably add your personal mailboxes (using the MAINTAIN lispusers package in Interlisp-D, or Maintain under Laurel) to get internal announcements about Interlisp-D versions and LispUsers packages. You might reply to this message if you have trouble getting access to the files. *start* 00592 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 30 May 84 17:22:52 PDT (Wednesday) From: Ueda.FX Subject: LispUsers distribution list In-reply-to: Masinter.pa's message of 30 May 84 16:53 PDT To: Masinter.pa cc: Ueda, Kamibayashi, Ikeo, 1100Support.pasa, LispSupport.pa We (Dr. Kamibayashi, Mr. Ikeo and I) have already included our mail account names into the distribution list. But we are told to refrain from retrieving files from IFS's in Xerox, because the agreement of technology transfer between XC and FX has not been esatblished yet. // Yoshihiro Ueda *start* 00439 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 30 May 84 21:00 PDT From: Sheil.pa Subject: Re: fyi, FX agreement still not signed? In-reply-to: masinter.pa's message of 30-May-84 20:31:42 PDT To: masinter.pa cc: lispsupport The situation with Fuji is in great turbulence. I'll happily brief you off line. In the meantime, please do not get involved or make any change in FX access, distribution, etc. Beau *start* 00618 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 10:07 PDT From: Masinter.pa Subject: Re: Lisp Directories In-reply-to: Ueda.FX's message of 10 Jun 84 22:37:09 PDT (Sunday) To: Ueda.FX cc: Masinter.PA, Kamibayashi.FX, Yokota.FX, LispSupport, 1100Support.pasa reply-to: LispSupport.pa, 1100Support.pasa We have a new file server, Eris. The files are on [Eris], which you should be able to read. I am going away for two weeks so you should message LispSupport.PA and 1100Support.PASA if you have further troubles, as I will not be able to read my mail sooner than that. *start* 00829 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 10:08 PDT From: Masinter.pa Subject: [Ueda.FX: Lisp Directories] To: lispSupport, 1100Support.pasa fyi ----- Begin Forwarded Messages ----- Date: 10 Jun 84 22:37:09 PDT (Sunday) From: Ueda.FX Subject: Lisp Directories To: Masinter.PA cc: Kamibayashi, Yokota, Ueda You told me that the new version of Lisp is stored on [phylum]Current>, but the directory is not open to LispUsers^.PA. I would like to get access (read) right of and other directories such as . Could you please tell me the names of directories which you think are useful to the users of Interlisp-D? And I will make a formal request to give me the access right of th e directories. // Yoshihiro ----- End Forwarded Messages ----- *start* 00556 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 16:16:23 PDT (Monday) From: Ueda.FX Subject: Re: New home for Lisp-related files In-reply-to: Sybalsky.pa's message of 8 Jun 84 14:59 PDT To: Sybalsky.pa cc: Ueda, LispSupport.pa, 1100Support.pasa, Yokota, Kamibayashi Please tell me the names of the directories moved to {Eris} and their access privileges. And which of them you think are useful to the users of Interlisp-D? I would like to make a formal request to give me their access privileges. // Yoshihiro Ueda *start* 00827 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 16:32 PDT From: Sybalsky.pa Subject: Re: New home for Lisp-related files In-reply-to: Ueda.FX's message of 11 Jun 84 16:16:23 PDT (Monday) To: Ueda.FX cc: Sybalsky.pa, LispSupport.pa, 1100Support.pasa, Yokota.FX, Kamibayashi.FX The directories , , , and were moved to {ERIS}. They retained the same protection that they had before. Since you got the announcement, you are at least on LispUsers^.pa, which has read access to the directories and . The other directories for keeping internal files; you should only need access to them if you are actively developing lisp itself. If you find that you can't get to {Eris} or , please let me know. --John Sybalsky *start* 00495 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 17:16:05 PDT (Monday) From: Ueda.FX Subject: Re: New home for Lisp-related files In-reply-to: Sybalsky.pa's message of 11 Jun 84 16:32 PDT To: Sybalsky.pa cc: Ueda, LispSupport.pa, 1100Support.pasa, Yokota, Kamibayashi How about ? Dr. Masinter said, "I believe it would be simple for you to become a 'beta tester' (of Carol release) since the files are on [phylum]Current>." // Yoshihiro *start* 00466 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jun 84 17:27 PDT From: Sybalsky.pa Subject: Re: New home for Lisp-related files In-reply-to: Ueda.FX's message of 11 Jun 84 17:16:05 PDT (Monday) To: Ueda.FX cc: Sybalsky.pa, LispSupport.pa, 1100Support.pasa, Yokota.FX, Kamibayashi.FX Indeed so. is also on {Eris}, and can be read by anyone on LispUsers^.pa. Let me know if you have any trouble reading from there. --John *start* 02055 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jun 84 11:38:43 PDT (Tuesday) From: JFung.pasa Subject: Re: UTexas In-reply-to: Raim's message of Mon, 11 Jun 84 19:03 PDT To: Raim cc: Wogulis, 1100Support, LispSupport.PA, Masinter.PA Re: "As for PUPFTP, only a LispCore'er such as Larry or Bill van Melle can tell you where to look." Jim, Pup documents are also available at [rose]PUP>*.press Opening connection to rose ... Done. XSIS 1.38.1L, File server of February 14, 1984; 3 users out of 9 pup ALTOBOOT.PRESS!1 19456 3-Sep-79 17:52:42 PDT CACHEROUTE.PRESS!1 17920 3-Sep-79 17:52:47 PDT COPYDISK.PRESS!1 25600 12-Nov-80 15:34:40 PST EFTPSPEC.PRESS!1 16384 3-Sep-79 18:50:12 PDT ERROR.PRESS!1 7168 3-Sep-79 17:52:57 PDT EVENTREPORT.PRESS!1 11776 3-Sep-79 17:53:01 PDT FTPSPEC.PRESS!3 75264 29-Sep-83 11:54:45 PDT GATEWAYINFORMATION.PRESS!1 17920 3-Sep-79 17:53:05 PDT IFSFORWARDING.PRESS!1 20480 30-Nov-78 19:31:09 PST LOOKUPFILE.PRESS!1 5632 10-Sep-82 9:41:55 PDT MAILTRANSFER.PRESS!1 21504 3-Sep-79 18:09:07 PDT MISCSERVICES.PRESS!1 21504 8-Feb-80 13:42:13 PST NETCONSTANTS.PRESS!1 12800 12-Aug-83 13:30:49 PDT NETDIRUPDATE.PRESS!1 7168 3-Sep-79 17:53:21 PDT PDP-SOFTWARE.PRESS!1 20992 15-Oct-79 12:30:16 PDT PUPDIRECTORY.PRESS!1 25088 3-Sep-79 17:53:29 PDT PUPNAME.press!1 23040 3-Sep-79 17:53:35 PDT PUPPAPER.PRESS!1 112640 26-Oct-79 15:41:08 PDT PUPSPEC.PRESS!1 51200 3-Sep-79 18:50:20 PDT rtpstates.press!1 17920 3-Sep-79 18:50:25 PDT SPRUCEPROTOCOLS.PRESS!1 9728 3-Sep-79 17:53:39 PDT STATISTICS.PRESS!1 5120 3-Jul-78 0:09:36 PDT SYNCTRANSPORT.PRESS!1 18432 3-Sep-79 19:02:11 PDT TELESWAT.PRESS!1 15360 3-Sep-79 17:53:45 PDT TELNET.PRESS!1 13312 3-Sep-79 17:53:49 PDT Total of 25 files *start* 03719 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Mon, 11 Jun 84 19:03 PDT From: Raim.pasa Subject: UTexas To: Wogulis cc: 1100Support, LispSupport.PA, Masinter.PA Jim, The address for Network Systems: Xerox Corp. Office products Division Network Sustems Administrators Office 3333 Coyote Hill road Palo Alto, CA 94304 As for PUPFTP and Leaf: Sources for LEAF should be on {eris}fugue6>sources>leaf. As for PUPFTP, only a LispCore'er such as Larry or Bill van Melle can tell you where to look. As to specifications for Leaf: I have Jeff Mogul's "Leaf and Sequin Protocols" of March 1981. I don't know if there is anything more recent. You can copy it and send it to UTexas. --Marty --------------------------- Date: 7 Jun 84 14:04:04 PDT (Thursday) From: Masinter.PA Subject: PUP documentation, sources for PUPFTP To: 1100Support.pasa cc: LispSupport reply-to: CS.Chee@UTexas-20, ICS.Stuart@UTexas-20, Masinter Can you mail or point Don Stuart and/or Chee to sources for PUPFTP and Leaf? Also, to the documentation such as it exists for those protocols? Also, inform them that you will be happy to try to find the answers to any question they have? Also, to tell ICS.Stuart the address at OSD to write to for documentation on the NS protocols (remind him that the set of documentation costs $250.) Thanks Larry ---------------------------------------------------------------- Return-Path: Received: from UTEXAS-20.ARPA by Xerox.ARPA ; 07 JUN 84 13:18:31 PDT Date: Thu, 7 Jun 84 15:18:32 CDT From: Chee Subject: [Don Stuart : PUP] To: MASINTER.PA cc: cs.chee@UTEXAS-20.ARPA Hi, Don Stuart (the one that came in late with red curly hair, who's working on the PUP proctocols on a Symbolics 3600) is nearing completion of network project and would like additional info. on the PUP FTP. I'm not very familiar with all these network stuff so I'm forwarding his request verbatim to you in case I miss out/misinterpret the request. I'd very much appreciate it if you'd look into the request and see what you all can or cannot give. Also, John Quarterman, our other hacker working on the Vax 4.2 PUP stuff is making some progress and I anticipate he might have some questions too, should I continue sending (or rather forwarding) questions about networking to you? Thanx. - Chee - --------------- Mail-From: ICS.STUART created at 6-Jun-84 01:22:10 Date: Wed 6 Jun 84 01:22:10-CDT From: Don Stuart Subject: PUP To: cs.chee@UTEXAS-20.ARPA cc: cmp.cohen@UTEXAS-20.ARPA, cs.rich@UTEXAS-20.ARPA At the meeting with Xerox two weeks ago someone (perhaps Masinter) said that we did not have but could get the sources for the Interlisp-D implementation of the PUP FTP protocol. There was also some discussion of the specifications or code for leaf (spelling?) which I understood to be a more comprehensive file service protocol. Can you arrange to get us an actual copy of that information? If it is to be useful, we need it as soon as possible, within the next week or two at the latest. While it is not necessary for this project, I would personally be very interested in seeing whatever information they care to release about the corresponding XNS protocols (in NS jargon, any protocol above the level of Packet Exchange or Courier). You should use your judgment on asking for this information, don't push your luck. Don ---------------------------------------------------------------- ------------------------------------------------------------ *start* 01093 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Tue, 12 Jun 84 16:21 PDT From: Raim.pasa Subject: Re: Response to UTexas In-reply-to: "Sheil.pa's message of 9 Jun 84 22:16 PDT" To: Sheil.pa cc: Raim, Masinter.pa, Pahlavan, Wogulis, sannella.pa 1. I, too, advocate a uniform policy on sources with UTexas and Syntelligence being the first beneficieries. Marcel verbally assured me our standard software license covers release of sources, based on his communication with El Segundo.  (I'd like that assurance in writing.) 2. I will encourage Jim to follow up on this. I believe he should get the  HCPRVR sources from Chee, make sure they load and run on our widebodied DLion, and , if necessary, consult with a PARC person on possible gross inefficiencies in the code. THEN invite Chee to witness the benchmarking. 3. I don't recall seeing your proposed policy on urgent questions and appreciate your definitive answer. I will forward it to 1100Support. It is our policy not to furnish customers with names/phone numbers of LispCore^ people. --Marty *start* 00942 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jun 84 16:19:05 PDT (Tuesday) From: JFung.pasa Subject: Carol Installation Files To: LispSupport.pa cc: 1100Support, JFung Mike, Here are the versions of the files just to make sure we all are in sync. A. Installation Utility Floppy: Mesa.db 65535 37042 6-Mar-83 21:02:39 PST 29-Jun-83 10:09:56 PDT DLion.germ 65535 15360 24-Sep-82 18:10:58 PDT 29-Jun-83 10:10:04 PDT TajoDLion.boot 65535 1012736 8-Mar-83 20:02:44 PST 29-Jun-83 10:10:10 PDT LISP10SAX000INITIAL.DB 65535 8644 2-Mar-84 5:19:41 PST 13-Jun-84 1:47:58 PDT B. Diagnostics Files Floppy: (these are filed at [rose]carol>installation>). prometheus.script 65535 5253 6-Jun-84 13:32:43 PDT 7-Jun-84 10:02:22 PDT LispInstallationTool.bcd65535 114688 1-Jun-84 12:24:11 PDT 1-Jun-84 16:35:50 PDT *start* 00406 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jun 84 16:32:29 PDT (Tuesday) From: JFung.pasa Subject: Re: Carol Installation Files In-reply-to: JFung's message of 12 Jun 84 16:19:05 PDT (Tuesday) To: LispSupport.pa cc: JFung Mike, Corrections: I got the names of the floppies wrong. A should be Diagnostics Files Floppy and B should be Installation Utility Floppy. *start* 00373 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jun 84 17:24:28 PDT (Tuesday) From: lispar.auto Subject: Re: Carol Installation Files In-reply-to: JFung.pasa's message of 12 Jun 84 16:19:05 PDT (Tuesday) To: JFung.pasa cc: LispSupport.pa, 1100Support.pasa Yes, we are in sync. Our versions of these files all have the same creation dates. *start* 01231 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jun 84 17:40 PDT From: Sheil.pa Subject: Request for documentation change To: 1100support.pasa cc: martino.pasa, lispsupport, vanmelle During their visit Monday, Boeing asked why they could not run color on a Dolphin that had both sets of net ucode. I found out that the two net ucode configuration was only released to support gateways and that it wasnt intended to support a normal workstation. Especially not color, which takes so much of the memory bandwidth that a gateway running color would be ghastly. But they just wanted a workstation that lived on both nets and didnt understand why it didnt work. Turns out that it's because there is no room. When this was explained to them, they were only a little mollified and demanded to know why this limitation was not in the documentation (where it is explained that the floating point doesnt fit in this configuration). I calmed them down by saying that I'd get it included next release (of documentation). I think this is Guide, rather than Lisp manual, documentation. If so, could whoever maintains this please respond indicating whether they are willing to make this minor change? Beau *start* 00546 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Tue, 12 Jun 84 18:45 PDT From: Raim.pasa Subject: Re: Request for documentation change In-reply-to: "Sheil.pa's message of 12 Jun 84 17:40 PDT" To: Sheil.pa cc: 1100support, martino, lispsupport.pa, vanmelle.pa Beau, My guess is that the Guide, like the ILM, was done at PARC. As such, we would have no control over it from Pasadena. When the responsible party does step forward, I will happily identify what should be done to bring the Guide up-to-date. --Marty *start* 01299 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 13 Jun 84 12:04:14 PDT (Wednesday) From: Sannella.PA Subject: Re: Request for documentation change In-reply-to: Raim.pasa's message of Tue, 12 Jun 84 18:45 PDT To: Raim.pasa cc: Sheil.pa, 1100support.pasa, martino.pasa, lispsupport.pa, vanmelle.pa There is a little confusion here. The only "guide" currently maintained is the "1108 Users Guide". There is no users guide for the 1100 & 1132 --- except for old green-covered users guide, which isn't being sent out anymore (right?). There certainly should be an "1100/1132 Users Guide", but lets not worry about that until the Harmony release. The only documentation on the various 1100 microcodes that I was able to find is in the Fugue.6 release notes, created by Pasadena. I believe that this is the documentation that the Boeing people referred to On the last page, it says: "* Microcode for 1100 (dolphin) [new]: DolphinLispMC.eb for 3MB Ethernet XMBDolphinLispMC.eb for 10MB Ethernet X3DolphinLispMC.eb both 3 and 10MB Ethernet, but no floating point." For the Carol release, I think that the only documentation change needed would be to change the last line to "X3DolphinLispMC.eb both 3 and 10MB Ethernet, but no floating point or Color microcode." *start* 00665 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Wed, 13 Jun 84 14:55 PDT From: Raim.pasa Subject: Re: Request for documentation change In-reply-to: "Sannella.PA's message of 13 Jun 84 12:04:14 PDT (Wednesday)" To: Sannella.PA cc: Raim, Sheil.PA, 1100support, martino, lispsupport.PA, vanmelle.PA There IS an 1100 Users Guide, apparently of unknown parentage, which describes such 1100 specifics as MP codes and the Alto exec. It DOES go out because there's nothing to replace it. One of these days (after I get back) someone will rip out everything except Chapter 1 and the appendices and call that "The 1100 Users Guide." --Marty *start* 01530 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 2 Jul 84 14:55 EDT From: Hannaway.wbst Subject: Lisp: Suspected compiler bug To: LispSupport.pa cc: AHenderson.pa, Hannaway.wbst Lisp-System-Date: 25-Jun-84 13:07:37 Machine-Type: Dolphin I am running Trillium in the latest version of Lisp. There is an NLambda function, Trillium.Printout, that prints messages to the promptwindow. Functions which call Trillium.Printout seem to be compiling incorrectly. When they pass a local variable to Trillium.Printout, a break window pops up with the message "Unbound atom" on the variable. When these functions are run interpretively or when the versions compiled under the old Lisp are run, they behave correctly - the value of the variable is printed. I have included a section of code which causes a break window to pop up, and the section of Trillium.Printout that does the printing. From the Trillium function Create.New.Interface: (PROG (NEW.NAME NEW.INTERFACE BITMAP.ITEM) (TRILLIUM.PRINTOUT "Creating new interface; Name of new interface: ") (SETQ NEW.NAME (PROMPT.READ)) (COND ((NOT (ATOM NEW.NAME)) (TRILLIUM.PRINTOUT "Name must be one word") (RETURN)) ((FIND.INTERFACE NEW.NAME) (TRILLIUM.PRINTOUT "The name " NEW.NAME " is already in use") (RETURN)))) From Trillium.Printout: (for SPEC in SPCS do (COND ((EQ SPEC T) (TERPRI PROMPTWINDOW)) ((STRINGP SPEC) (TRILLIUM.PRINTOUT.STRING SPEC)) ((NUMBERP SPEC) (SPACES SPEC PROMPTWINDOW)) (T (PRIN1 (EVAL SPEC) PROMPTWINDOW)))) Thanks, Pat *start* 01575 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 2 Jul 84 12:34:28 PDT (Monday) Subject: LLPARAMS is on the way To: Shulman@rutgers.arpa cc: le.pasa, LispSupport.pa From: LispSupport.pa Reply-To: LispSupport.pa Thu -- I am sending a hardcopy of the file LLPARAMS down with Judy. Could you please mail it to Jeff as soon as you get it. Thanks. --- Michael ---------------------------------------------------------------- Date: 1 Jul 84 14:32 PDT From: vanMelle.pa Subject: [Jeffrey Shulman : \KEYHANDLER1 problem] To: LispSupport cc: vanMelle.pa Would you provide Mr. Shulman with a copy of LLPARAMS from LispCore>Next? The new LLKEY slipped into Carol to provide 2-button mouse support requires the version of the MISCSTATS record found there to compile. ----- Begin Forwarded Messages ----- Return-Path: Received: from RUTGERS.ARPA by Xerox.ARPA ; 01 JUL 84 12:22:43 PDT Date: 1 Jul 84 15:23:19 EDT From: Jeffrey Shulman Subject: \KEYHANDLER1 problem To: vanmelle.pa I am trying to recompile \KEYHANDLER1 with my mouse/keyboard package stuff in it. It breaks with an undefined field name DLMOUSETIMER and DLMOUSETEMP in the prog var initialization. I can't seem to find any record declaration (let alone MISCSTATS) that has these fields defined (I'm looking in EXPORTS.ALL.) Can you help me out? Thanks. Jeff ------- ----- End Forwarded Messages ----- ---------------------------------------------------------------- *start* 01849 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: MASINTER.pa Date: 4-Jul-84 1:15:38 PDT Subject: fyi, query on Vax<->Interlisp communication To: LispSupport, Jellinek, 1100Support.pasa, Catton.RX, HThompson I certainly don't mind of Christer Haggstrom (RX Sweden) sends me questions direct. I thought I would cc all of you folks because you are supposedly on the official 'support' path (well, Herb Jellinek is cc:'d because he has something to contribute maybe and Catton.RX and HThompson.PA are cc'd because Martin Gittins' mail account is no more.) Reply follows ---------- From: Haggstrom.rx Date: 4-Jul-84 4:06:47 EDT Subject: 1108 as a slave to VAX? To: Masinter.pa Larry, yesterday we visited another part of KTH called PS LAB (Production systems). They are interested in getting one or more 1108's. They are in the CAD/CAM business. They have a VAX 780/VMS, they have a old system called Picture rotating 3 dimensional objects on large screens. They use FORTRAN, and a subset of Interlisp they have created themselves (in FORTRAN). The want to use the 1108 for two purposes: First; for developing software, which is fine, of course. Second; for running a number of processes for the VAX, controlled by the VAX. Two questions: 1. I have a feeling that having an 1108 standing unattended running a number of processes as a slave maching to the VAX might not give us a happy customer. What do you think? 2. They want direct communication between an 1108 process and a VAX process, just file transferring is not enough. Is that something that can be done? Easily? By PSLAB? Sources? Please copy Bremander.rx, I will leave for vacation soon. --- Christer PS. Yes, KTH, Linkoping and KTH have all ITS accounts. Just that I haven't got hold of the people in Linkoping yet. (Sweden is closed in July.) *start* 00960 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: MASINTER.pa Date: 4-Jul-84 1:20:13 PDT Subject: Re: 1108 as a slave to VAX? In-reply-to: Your message of 4-Jul-84 4:06:47 EDT To: Haggstrom.rx cc: Jellinek, LispSupport, 1100Support.pasa, Bremander.RX, Catton.RX, HThompson We have had other users in a similar position (having old programs on a VAX that they want to interact with on the 1108). There are a couple of possibilities: a) modify CHAT to emulate whatever terminal they used to have -- if it was a Tektronix, they may be in luck because we are developing a Tektronix emulation package (right, Herb?) b) right a special purpose package based on Courier or their own encoding on top of BSP. The VAX/1108 connection is more general than just 'File transfer', because it gives also 'remote terminal' (known as Chat); a lower level stream interface is also available, I believe. Anyone else have more info or ideas? *start* 00548 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 4 Jul 84 11:29 PDT From: Acuff.pa Subject: Re: 1108 as a slave to VAX? In-reply-to: MASINTER.pa's message of 4-Jul-84 1:20:13 PDT To: MASINTER.pa cc: Haggstrom.rx, Jellinek.pa, LispSupport.pa, 1100Support.pasa, Bremander.RX, Catton.RX, HThompson.pa, PYoung.pasa, vanMelle.pa, Acuff.pa It sounds like they want to use the 1108 as a *slave* rather than as a dumb terminal. They might be able to make good use of EvalServer, as well as a stream interface. -- Rich *start* 00509 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 4 JUL 84 18:58 PDT From: HTHOMPSON.PA Subject: Re: 1108 as a slave to VAX? To: MASINTER, Haggstrom.rx cc: Jellinek, LispSupport, 1100Support.pasa, Bremander.RX,, Catton.RX In response to the message sent 4-Jul-84 1:20:13 PDT from MASINTER.pa Seems to me RPC is the right answer conceptually - whether it would be feasible technically is another question - Swinehart has an implementation in C which might port easily? ht *start* 00697 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 4 Jul 84 21:41 PDT From: Masinter.pa Subject: Re: 1108 as a slave to VAX? In-reply-to: HTHOMPSON.PA's message of 4 JUL 84 18:58 PDT To: HTHOMPSON.PA cc: MASINTER.PA, Haggstrom.rx, Jellinek.PA, LispSupport.PA, 1100Support.pasa, Bremander.RX, Catton.RX I think RPC is far too complex for what they need. Compare how Silicon Graphics handles the IRIS -- the IRIS looks like a terminal, except that the remote host encodes escape sequences in the stream to cause the 'terminal' to behave differently. Given what I think they want to do (in which 'control' really means 'use the 1108 as a programmable graphics terminal), *start* 00906 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jun 84 10:07:36 PDT (Monday) From: JFung.pasa Subject: Setting VMem in a full lisp volume To: LispSupport.pa, Stansbury.pa cc: Dering, Poduska, 1100Support, JFung Mike & Tayloe, The current setting of a full lisp volume to 16200 pages, leaves 16189 free pages after partitioning and before sysout is installed. Running the SetVMem command from Lisp Installaton Tool, the tool finds out the max. approximat VMem size to use is 16081 pages. Setting VMem to 16081 (an error) and later on running the lisp results an MPC 9318. Since max. addressable space is limited to 16000 pages, there are two remedies we can do. 1. Insure LIT SetVMem will not use any number exceed 16000 pages, even though there is room. 2. Decress Lisp Volume size say down to 16000 pages from Prometheus script. Any comments. Thanx. Jerry *start* 00464 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: Received: from RUTGERS.ARPA by Xerox.ARPA ; 15 JUN 84 17:24:57 PDT Date: 15 Jun 84 12:13:05 EDT From: Jeffrey Shulman Subject: EVALSERVER To: lispsupport.pa cc: jonl.pa, SHULMAN@RUTGERS.ARPA EVALSERVER.DCOM does't seem to work under Fugue.6. Can you please make the latest sources available to me? Thanks. Jeff ------- *start* 02997 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 May 84 17:07 PDT From: Sannella.pa Subject: [MASINTER.PA: character set proposal] To: lispsupport ----- Begin Forwarded Messages ----- Date: 5 MAY 84 22:30 PDT From: MASINTER.PA Subject: character set proposal To: Sybalsky, Nuyens cc: LispCore^ It turns out I've been scheduled to attend another meeting Tuesday 10 AM May 8. I thought I would try to type in my opinions about th NS character set. The requirement of the Systems Integration Board is that Interlisp use the NS character set as *one of* its *external* representations in files. It says nothing about the *internal* representation, and puts not limit on alternate external representations. The purpose of this meeting is to decide how far to adopt the NS character set as an INTERNAL representation of Interlisp-D. I propose the following going-in position: a) little or no performance or space penalty -- we should look for representations which don't have large overhead. b) upward compatibility with current code -- users won't have to rewrite files and current programs will continue to work unchanged. I think these goals can be met. I think we should consider possibilities that don't meet them only after we've exhausted the ones that do. Algorithms follow representations. The key is to describe the representations, and then examine the algorithms to see if there is any kind of penalty. There are several separate representations to design: strings, atoms, and files. (TEdit buffers may be another.) The major functions affected are: NCHARS, STRPOS, NTHCHAR(CODE), RPLCHAR(CODE), FILEPOS, GETFILEPTR, SETFILEPTR, BIN, BOUT, .... Design choice 1: BIN really means Binary In. It gets an 8 bit byte, and does no translation. Likewise, GETFILEPTR and SETFILEPTR really count bytes, and not 'characters'. (I don't think we can get away from that). NS characters are represented using the 'standard' run coding as documented in the standard. Either form is acceptable on input, although the single escape will probably be used on output. (We may want to put some limits and constraints on what we accept if we want FILEPOS to run acceptably fast) For internal strings and symbols, we have a couple of choices: a) have 8-bit strings and 16-bit strings b) runcode strings (and symbols)? b makes NTHCHAR(CODE) etc. slower a) wastes some space, and complicates some algorithms. I see absolutely no point in allowing syntax and terminal tables to talk about anything outside of character set 0. We should Avoid Useless Generalities when they are Expensive. I'm sure there is more. I think the best outcome of this meeting would be to generate and flesh out a couple of different design alternatives, with the result being some charter on what kind of data on usage and space need to be gathered to decide between them. One interesting question we've avoided: How does Mesa Do It? ----- End Forwarded Messages ----- *start* 03696 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 4 Jun 84 12:24 PDT From: masinter.pa Subject: [kamibayashi.FX: JLISP and NS characters Codes] To: lispcore^ cc: sheil fyi ----- Begin Forwarded Messages ----- Date: 4 Jun 84 02:17:17 PDT (Monday) From: kamibayashi.FX Subject: JLISP and NS characters Codes To: Kaplan.pa cc: Masinter.pa,Becker.pa,Ueda.fx,Ikeo.fx, kamibayashi.FX Ron, I would like to thank you for your kind advices to our activities such as Interlisp-D, JLISP and LFG. This is my answer to your message at end of MAY. Now, we are designing and implementing JLISP. Our JLISP is based on your JLISP but we redesigned all functions of prototype JLISP. The major modifications we try are the followings: For performance improvement 1)New Kana-kanji dictionary structure (added a new field to check grammer) 2)New access method to Kana-kanji dictionary (reduced disk accesses) For user interface improvement and new facilities 3)Kana-kanji conversion with tail conversion facility 4)String extention(wild card) 5)Short term memory(STM) based compound-word conversion facility 6)The other new ideas I was very happy when at PARC, you told me that Interlisp-D would employ 16 bit internal code. This is very lucky for handling large charcter set languages such as Japanese and Chinese. You know, LISP is very suitable for Symbolic manupulation and natural language manupulation. Therefore, in Japan we need LISP with the capability of Japanese language to develop any expert systems and the other applications. And because of the nature of LISP, it is very easy to incoporate Japanese handling capabilty to the original Interlisp-D. We have described the functional spec of JLISP in Japanese. Do you need this document? We will inform you our requirments on internal representation of Interlisp-D. Our concerns on consonance with JLISP are the followings (we had alredy disucussed them with Dr. Masinter): 1)Tedit 2)TTYIN 3)Press & Interpress Now, our approach is to introduce 16 bit JIS code representation as only JLISP access code to kana-kanji dictionary. Current JLISP environments JLISP based on NS Character codes Internal code: ASCII NS code JLisp internal Code: JIS JIS code File: ASCII(JIS) NS code Display: ASCII(JIS) NS code Press & InterPress: ASCII(JIS) NS code In case of Current Interlisp-D(JLISP) environments, we must develop some JIS code base pragrams (DISPLAY, PRINTING) to handle Japanese. However, in case of JLISP based on NS Character codes, we develop only JLisp internal programs(Keybord, Kana-kanji dictionary access and conversion to NS code streams such as Display, etc). As the result of our study, we have decided that these JLisp internal codes should be flat 16 bit code(JIS) for the efficiency of dictionary access and JLISP should convert the code from JIS to NS in case of transferring data to Interlisp-D world (DISPLAY, PRINTING). We have a plan to develop JTedit and JInterPress after we have completed JTyping/JEdit on Interlisp-D. But if Interlisp-D will introduce NS character code as internal representation, I think these programs are not required. If you have some questions on our JLISP approach, please contact us (me, Mr.Ueda, Mr.Ikeo) Thank you attention! Best regards //Nori P.S. I hope to continue positive communication and cooperation between your group and our group. You have any good ideas ? ---------------------------------------------------------------- ---------------------------------------------------------------- ----- End Forwarded Messages ----- *start* 03231 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 5 Jun 84 10:48 PDT From: masinter.pa Subject: [kamibayashi.FX: Futher discussion on Re: JLISP and NS characters Codes] To: LISPCORE^ Reply-to: masinter.pa ----- Begin Forwarded Messages ----- Date: 4 Jun 84 20:58:58 PDT (Monday) From: kamibayashi.FX Subject: Futher discussion on Re: JLISP and NS characters Codes In-reply-to: Becker.PA's message of 4 Jun 84 10:26:08 PDT (Monday) To: Becker.PA cc: Kamibayashi, Kaplan.PA, Masinter.PA, Ueda, Ikeo Joe, I would like to thank you for your valuable suggestion to code representation of JLISP. We understand well that NS codes are EXACTLY THE SAME AS JIS codes for all Japanese characters. But we will point out that internal representation of NS code is difefrent from FLAT 16 BIT CODE that is JIS code we mean. You know well,we have to represent NS code with special seperater characters such as Character Set Selecter Code(377-octal). This representation is different from that of flat 16 bit code. Our CONVERT means that in case of transferring data encoded by flat 16 bit code to DISPLAY Streams from JLISP Typing program, we have to add some Special Character codes to original data for making NS codes sequence. Also, we have some ideas on internal representation of JLISP. One is that Interlisp-D should support 2 byte string only encoding defined by NS Character encoding. This encoding use Special Character string , that is 377 377 000. After this codes, we can express only 2 byte strings that is actually the same as Flat JIS code we means. For example (ai)(jin)(shi)(gan) in Japanese(kanji) code 377 377 000 [Character set ID for (ai)][code for (ai)][Character set ID for (jin)][code for (jin)][Character set ID for (shi)][code for (shi)][Character set ID for (gan)][code for (gan)] If Interlisp -D will employ this 2 byte string only encoding as one of NS code encoding, we can transfer data of Jlisp Typing program to the other streams without any modification. However,if Interlisp -D will not employ this encoding, only support normal encording of NS code, we have to add some Special characters to data of JLISP and transfer to Interlisp -D world. For example of Normal encoding of NS (ai)(jin)(shi)(gan) in Japanese(kanji) code 377 [Character set ID for (ai)][code for (ai)] 377 [Character set ID for (jin)]  [code for (jin)] 377 [Character set ID for (shi)][code for (shi)] 377 [Character set ID for (gan)] [code for (gan)] We think that best solution on NS characters encoding is that Interlisp -D should support 2 byte string only encoding as one of NS encoding in addition to the normal encoding. This is not our final opinion. we need futher discussion on thie issues. Please tell us your ideas. I would like to thank you again for your advice and interesting. Your encouragements meke clear our design specs and Interlisp-D NS encoding requirement for handling Japanese. Best regards //Nori ---------------------------------------------------------------- ----- End Forwarded Messages ----- *start* 00883 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 5 Jun 84 10:48 PDT From: masinter.pa Subject: [KAPLAN.pa: Re: Futher discussion on Re: JLISP and NS characters Codes] To: LISPCORE^ Reply-to: masinter.pa ----- Begin Forwarded Messages ----- From: KAPLAN.pa Date: 4-Jun-84 23:10:08 PDT Subject: Re: Futher discussion on Re: JLISP and NS characters Codes In-reply-to: kamibayashi.FX's message of 4 Jun 84 20:58:58 PDT (Monday) To: kamibayashi.FX cc: Becker, Kaplan, Masinter, Ueda.FX, Ikeo.FX In our design for upgrading Interlisp to the NS character set, we are carefully distinguishing the internal representation of NS characters in atoms and strings from any particular external representation (for example, symbolic files, text files, interpress files). The internal representation must support a variety of special Interlisp operations that *start* 01235 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jun 84 12:46 PDT From: Shrager.pa Subject: Lisp: Chat hangs on MAXC To: LispSupport.pa cc: Rweaver Lisp System Date: 10-Jun-84 18:41:09 Machine: Dorado (Shrager) Microcode version: 24,4 Memory size: 10000 Frequency: Intermittent Impact: Seriously Annoying Very often, when I'm chatting to MAXC and Teleneted to CMUA, or elsewhere, I get hung for an indefinite period of time for no obvious reason. I used to think that this was due to MAXC or the ethernet or something being overloaded, but it has happened to me at all hours of the day and night, including this morning at something like 4am. I'm not sure, but I don't think that this is in the telnet connection, because I believe I've experienced it just to MAXC. However, my main use of Maxc is as a chat gateway, so I can't be certain of this assertion. -- Jeff (PS: Please don't tell me that "Maxc is going away so it doesn't matter." I really really really really hate answers like that, which are given all to often by computer support. If that's really what you think about the problem say: "We'll look into it. Thanks for the report." and then just take your time about it. -- Jeff) *start* 01961 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jun 84 17:08:41 PDT (Monday) From: JFung.pasa Subject: EMI test with Lisp10Test1BankInitial uCode To: Purcell.pa cc: JFung, LispSupport.pa, 1100Support Reply-To: JFung Steve, Wendy said she obtained the Lisp10Test1BankInitial.db file from you for her EMI test. She will be doing on a standalone system, thus she can only use floppies. If she needs two uCode files, then the scrip needs to be modified to accomodate this. I will make necessay changes for her. Advice me if you see anything improper. Thanks. Jerry ---------------------------------------------------------------- Date: Mon, 18 Jun 84 16:35 PDT From: WendyLee.ES Subject: Lisp Installation To: JFung.pasa cc: WendyLee Jerry, First I have to thank you for all the help, it was very much appreciated. The EMI test we'll be doing in East coast for the 1108 (the DandeTiger, we call it) requires a software program to run the system continuously to test the functionalities of the CPE and the Memory modules and the Emission of the Display. That's why we need the Demo.sysout installed in the Interlisp-D to meet this requirement. The Floattest.sysout is installed to test the Floating Point Functionality of the CPE module before setting up the system for EMI. Since the company where we're going to do our EMI test does not have an Ethernet environment, I need the floppy tools to install both sysouts into two separate Lisp volumes. Also, the Floattest.sysout created by Steve Purcell requires a different Initial microcode - [ivan]Lisp10Test1BankInitial.db; therefore, the floppy may need to be modified in order to accomodate this difference. My mailing address is as follow: Wendy P. Lee Xerox Corporation 701 South Aviation Boulevard, M/S A2-20 El Segundo, California 90245 Thanks again! ~Wendy ---------------------------------------------------------------- *start* 01012 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Tue, 19 Jun 84 10:41:30 PDT From: McCall.pa Subject: Re: TTYINMETA etc. In-Reply-To: "Sannella's message of Thu, 14 Jun 84 14:41:35 PDT" To: LispSupport cc: RICHER@SUMEX-AIM.ARPA I originally thought that 'Xerox1100UsersGroup^.PA' had something to do with the users of Xerox 1100's. It appears, due most recently to Mark Richer's indiscriminate use of the list to solicit help with LISP-specific questions and 1108 hardware questions that this list has becomesomething quite different. Could you either adopt and announce a policy to restrict the use of the list to topics closer to its original purpose or remove me from the list. It seems to me that there were good reasons to have an 1100-users-group list. I would like it if this list could be returned to its original purpose or another list could be set up to serve those of us who don't want to deal with the new deluge of LISP-related mail and 1108 questions. Thanks, Kim*start* 00962 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: <@SUMEX-AIM.ARPA:Sannella.PA@Xerox.ARPA> Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 14 JUN 84 14:51:51 PDT Received: from Xerox.ARPA by SUMEX-AIM.ARPA with TCP; Thu 14 Jun 84 14:41:05-PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 84 14:41:43 PDT Sender: Sannella.PA Date: 14 Jun 84 14:41:35 PDT (Thursday) Subject: Re: TTYINMETA etc. In-reply-to: RICHER's message of Wed, 13 Jun 84 16:13:02 PDT To: Mark Richer cc: 1100users@SUMEX-AIM.ARPA From: LispSupport.pa Reply-To: LispSupport.pa On the Dlion, the red "STOP" key can be used as the meta key after doing (TTYINMETA T). "can anyone tell me how to get the same key to be a delete key on the both in lisp and when your chatting to tops-20 let's say" You can reset the delete char in Interlisp with (SETSYNTAX 'CHARDELETE (GETTERMTABLE)). *start* 00823 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 14 JUN 84 17:35:06 PDT Date: Thu, 14 Jun 84 17:33:41 PDT From: Mark Richer Subject: edit key for 1108 To: 1100users@SUMEX-AIM.ARPA cc: lispsupport.PA OKay, if I execute (TTYINMETA T) on my dandelion the STOP key acts the same as the bottom blank on my dolphin. What confused me is that we have (TTYINMETA T)in one of our init files that is part of the sysout image). If I load that image into a dolphin or dorado the bottom blank key works as an edit key, but when I boot up the same image on the dandelion (the sysout was made on a dorado) it does not work .. unless I do (TTYINMETA T) again. ------- *start* 01073 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 15 JUN 84 17:06:01 PDT Date: Thu, 14 Jun 84 19:45:55 PDT From: Mark Richer Subject: The STOP key : and finally To: 1100users@SUMEX-AIM.ARPA cc: lispsupport.PA The STOP key has special properties before you make it an edit key by calling TTYINMETA T. It's been described to be equivalent to going into raid and returning with a control-d. It definitely acts that way and is a necessary feature since the dandelion tends to hang up fairly frequently (won't respond to mouse or keyboard) and the way out has been to hit the STOP key. If I change it to an edit key then I lose its other functions. I'd like both. ONe solution would be to define a different key to be an edit key, but I still don't understand how to do that. A note from ERIC SCHOEN seems to imply indirectly that the function KEYACTION could be used perhaps? thanks, Mark ---- ------- *start* 01189 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Return-Path: <@SUMEX-AIM.ARPA:VANBUER@USC-ECL.ARPA> Redistributed: Xerox1100UsersGroup^.PA Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 18 JUN 84 22:12:25 PDT Received: from USC-ECL.ARPA by SUMEX-AIM.ARPA with TCP; Mon 18 Jun 84 21:59:00-PDT Date: 18 Jun 84 21:59 PDT From: VANBUER@USC-ECL.ARPA Subject: Re the STOP key and RAID To: 1100users@SUMEX-AIM.ARPA Mail-From: VANBUER created at 16-Jun-84 08:01:32 Date: 16 Jun 1984 0801-PDT From: VANBUER@USC-ECL.ARPA Subject: Re: The STOP key : and finally To: RICHER@SUMEX-AIM cc: VANBUER@USC-ECL In response to your message sent 14 Jun 1984 2026-PDT I've been playing with our (new) Dandelion's a bit more, and the use of the STOP key as META doesn't seem to interfere with it's use in giving the machine a kick to get going again. Generally, when the machine seems dead, it's because it's slipped into RAID (much tidier on our Dolphins, the screen changes). RAID does its own keyboard interpretation, and there STOP means hard reset to lisp toplevel. If it's not in RAID, other, gentler prods work (ctrl-H, ctrl-E, ctrl-B and ctrl-D). Darrel ------- ------- *start* 00429 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jul 84 17:20 PDT From: vanMelle.pa Subject: Re: non-numeric arg NIL under \NSFILING.GETFILE .... In-reply-to: LispSupport.pa's message of 18 Jul 84 16:45:29 PDT (Wednesday) To: LispSupport.pa Oops, I misinterpreted "Are any outstanding problems solved?" I have fixed a handful of NS related AR's. None of the hard ones yet, unfortunately. Bill *start* 01178 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 18 Jul 84 16:24:30 PDT (Wednesday) Subject: Re: Lisp: Can't get WImage hardcopy In-reply-to: ckiparsky's message of 17 Jul 84 13:35 PDT To: ckiparsky cc: LispSupport.pa From: LispSupport.pa Reply-To: LispSupport.pa Yes, you are complaining to the correct people. In particular, if you could send more information about the breaks you received, it will be forwarded to the appropriate people. As far as the problem you are really concerned about: "How can I print out my screen image" --- From what you say, it seems that the printer LispPrint: was not up. LispPrint: has been causing a lot of trouble recently. Some people such as Mitch Lichtenberg or Larry Masinter have put it up in the past, but there is no one person responsible for keeping it running. If you find yourself in need of screen images, and LispPrint: is down, is Quake sufficient? If you edit the variable DEFAULTPRINTINGHOST to remove LispPrint:, the background menu window command Hardcopy will send to quake. Of course, Quake images are not of as high quality as LispPrint:, so it may not be useful. *start* 00477 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 18 Jul 84 16:45:29 PDT (Wednesday) Subject: Re: non-numeric arg NIL under \NSFILING.GETFILE .... In-reply-to: vanMelle's message of 18 Jul 84 10:32 PDT To: vanMelle cc: LispSupport From: LispSupport.pa Reply-To: LispSupport.pa by the way... Have you tried using file servers with Services 8.0 from Interlisp? Have there been any problems? Are any outstanding problems solved? *start* 00693 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jul 84 17:11 PDT From: vanMelle.pa Subject: Re: non-numeric arg NIL under \NSFILING.GETFILE .... In-reply-to: LispSupport.pa's message of 18 Jul 84 16:45:29 PDT (Wednesday) To: LispSupport.pa I have at present no unsolved problems with Services 8.0 (and in fact, all the problems I've had have been independent of server version). I hope to merge my version into the sysout soon, probably tomorrow, since I don't have time today. I had wanted to also add code to take advantage of improved functionality (real versions, pathnames) in Services 8.0, but haven't gotten to that yet, and might not in time. Bill *start* 00429 00071 UUm @00045 01536 ftffffffffffffffffffffffffffffff @Date: 18 Jul 84 17:20 PDT From: vanMelle.pa Subject: Re: non-numeric arg NIL under \NSFILING.GETFILE .... In-reply-to: LispSupport.pa's message of 18 Jul 84 16:45:29 PDT (Wednesday) To: LispSupport.pa Oops, I misinterpreted "Are any outstanding problems solved?" I have fixed a handful of NS related AR's. None of the hard ones yet, unfortunately. Bill *start* 01513 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 21 Jun 84 12:02 PDT From: MikeDixon.pa Subject: Lisp: i'm losing again To: LispSupport.pa Lisp System Date: 10-Jun-84 18:41:09 Machine: Dandelion (-569759550) Microcode version: 24,4 Memory size: 5777 Frequency: Intermittent Impact: Fatal my DLion just crashed with an MP 9305. tele-raid -> ctrl-B doomed me: MP said 1108, cursor was normal, but it didn't track & the keyboard didn't respond to anything. the crash occurred while trying to select a paragraph in TEdit. my DLion seems to crash three or four times a week. so far this week (i.e. since tuesday morning) i've had a 9318 and a 9016 as well as this 9305. I haven't been able to recover from any of them. this level of unreliability is not very satisfactory. i'm inclined to suspect the problem is NOT a hardware problem, since (a) i use the DLion a lot, and would expect a higher failure rate, and (b) most (all) of the crashes seem to happen while i'm in TEdit or Lafite, and not when the machine's compute-bound. what should i be doing to try to diagnose/prevent these problems? i've phoned Lisp support people (primarily Mike Sanella) fairly frequently to be tele-raided, and submitted a few AR's, but i get the feeling no-one has much idea why i'm dying & how it's going to be fixed (yet). i'd certainly like to help track down & eliminate what ever is causing this, but i'm not sure what to do to accomplish this. .mike. *start* 00894 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 29 Jun 84 10:05:09 PDT (Friday) Subject: Re: Lisp: atoms In-reply-to: Koomen.wbst's message of 28 Jun 84 16:51 EDT To: Koomen.wbst cc: LispSupport.pa From: LispSupport.pa Reply-To: LispSupport.pa There are two problems here: (1) System loops in MKATOM when it runs out of atoms. This problem will be fixed in the next release. The system will cause an error when atom space gets low, and go into RAID when there are no more atoms left. (2) System has rigid limits on max # atoms, and it doesn't GC atoms. This is a serious problem, as more and more people run into the atom limit. In the short term, it should be possible to increase the max number of litatoms. In the mean time, all that I can suggest is that you examine your programs, and see if you are creating atoms unnecessarily. *start* 00577 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 30 Jun 84 01:03 PDT From: Masinter.pa Subject: Interlisp-10 bug reports To: Deutsch, Kaplan cc: LispSupport For the record: given the planned demise of maxc locally, and of the DEC-20 series generally, I'm officially marking as 'Declined' all bug reports relating to Interlisp-10. I had considered it, but unless someone appears who wants to take it over, I'm not going to do anything to Interlisp-10 unless it is a problem shared with Interlisp-D. I've marked AR#564, among others, as Declined. *start* 00433 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: deutsch.pa Date: 30-Jun-84 8:17:38 PDT Subject: Re: Interlisp-10 bug reports In-reply-to: Masinter's message of 30 Jun 84 01:03 PDT To: Masinter cc: Deutsch, Kaplan, LispSupport Your message is a little disquieting. I thought that SUMEX or somebody was going to take over maintenance of Interlisp-10/20. Aren't you going to pass on the AR list to them? *start* 00642 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @From: masinter.pa Date: 30-Jun-84 14:22:06 PDT Subject: Re: Interlisp-10 bug reports In-reply-to: deutsch's message of 30-Jun-84 8:17:38 PDT To: deutsch cc: Masinter, Kaplan, LispSupport Peter, I got Sumex to agree to keep the files. However, I've not found anyone who is willing to do any work, even the minimal work of re-compiling and reloading the files of Interlisp-10 that are shared with Interlisp-D. When I go thru the list of sites that were using Interlisp-10, almost all have moved off onto either Interlisp-Vax or Interlisp-D or other lisp alternatives. *start* 01513 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 2 Jul 84 15:16 PDT From: Masinter.pa Subject: [Eric Schoen : Re: Dorado Othello] To: 1100Support.Pasa cc: LispSupport, JonL The situation at Schlumberger explained: the problem is the T315 in Austin that got delivered with *old* microcode which only knows about 5 partitions. ----- Begin Forwarded Messages ----- Return-Path: Received: from SUMEX-AIM.ARPA by Xerox.ARPA ; 01 JUL 84 20:31:19 PDT Date: Sun, 1 Jul 84 20:30:09 PDT From: Eric Schoen Subject: Re: Dorado Othello To: Masinter.pa In-Reply-To: Message from "Masinter.pa@XEROX.ARPA" of Sun 1 Jul 84 09:58:00-PDT Schlumberger has one Dorado with a T80 (at Ridgefield), and one Dorado with a T315 (in Austin). The Austin Dorado predates the release of the 19 partition microcode (or at least I was told when we originally installed that machine in Ridgefield that "there would soon be new microcode that let us use the entire disk"); we received the machine around the first of the year. We have a version of Dorado Othello which doesn't quite work; when it comes up, it flashes "Cedar Othello" and dies immediately with 915 in the cursor "maintenance panel." If I shut off the disk, it hangs forever with the Cedar Othello display, and then dies when I spin up the disk. I assume I need a different version of Othello for non-Cedar disks. Eric ------- ----- End Forwarded Messages ----- *start* 01690 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 10 Jul 84 15:11:21 PDT (Tuesday) Subject: Re: Lisp: Suspected compiler bug In-reply-to: Hannaway.wbst's message of 2 Jul 84 14:55 EDT To: Hannaway.wbst cc: LispSupport, AHenderson From: LispSupport.pa Reply-To: LispSupport.pa I don't think that this is a compiler bug. From the symptoms, it looks like the local variable NEW.NAME as a LOCALVAR instead of a SPECVAR (see p12.4 of the reference manual). This means that the variable name was not put on the stack, so that Trillium.Printout could not see it. I am not sure WHY this happened to you, since the default is to assume that variables are specvars (which are put on the stack). By any chance did you compile the Trillium files with BCOMPL (which changes the default variable compilation to LOCALVARS)? Some solutions: 1) Put (DECLARE (SPECVARS NEW.NAME)) after the variable list of the PROG in Create.New.Interface. This will insure that the variable is compiled as a SPECVAR. Of course, it is a pain to remember to do this every place you want to use Trillium.Printout. 2) Define Trillium.Printout with a macro that generates the appropriate code. Since the code will be in the function that Trillium.Printout is called from, there aren't any problems with LOCALVARS vs. SPECVARS. Of course, there will be a slight space penalty --- any code which calls Trillium.Printout will be a little larger. This may be a consideration. In general, this sort of problem comes up whenever you try EVALing arguments to an NLAMBDA function. (sorry I took so long to answer --- this place was closed up the latter half of last week) *start* 00765 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jul 84 10:53 EDT From: Pirish.wbst Subject: Re: Lisp: Suspected compiler bug In-reply-to: Hannaway.wbst's message of Wed, 11 Jul 84 10:31 EDT To: LispSupport.pa cc: Irish.wbst, AHenderson.pa, Hannaway.wbst Pat Hannaway and I would like to know why things have changed such that we now need the DECLARE statement you suggested. Functions compiled under versions of Carol released before June 14 worked, and those compiled under the last two releases do not. We have not compiled anything with BCOMPL. You are right; it is a pain to remember to use the DECLARE when we want to use TRILLIUM.PRINTOUT, not to mention the 200 functions that already call it at this time. Peggy Irish *start* 01473 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jul 84 10:07 PDT Sender: Sannella.pa Subject: Re: Lisp: Suspected compiler bug In-reply-to: Pirish.wbst's message of 11 Jul 84 10:53 EDT To: Pirish.wbst cc: LispSupport.pa, Irish.wbst, AHenderson.pa, Hannaway.wbst From: LispSupport.pa To the best of my knowledge, nothing in the compiler, including how variables are compiled, has changed in the last six months. Do you have a set of files which work when compiled in the old sysouts, but the EXACT same files don't work when compiled in new sysouts? Are you sure that the files have not been changed? If you have such a file or files, give me a pointer to them, and I will try it myself. Talking to AHenderson, he mentioned that some people in WBST may be trying to make trillium run faster. Are you sure that they haven't been changing the variable declarations so that the default is to compile variables as LOCALVARS? Re: solution to your problem: Obviously, it is not practical to put in put in a declaration whereever you pass a local variable to TRILLIUM.PRINTOUT. I really suggest that it would be better to implement TRILLIUM.PRINTOUT with a macro. Perhaps the easiest way would be create a macro which constucts a call to a lambda-nospread function, so that all of the local variables would be evaluated in their own environment. This would also be faster (when running) than calling EVAL from within TRILLIUM.PRINTOUT. *start* 01037 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 16 Jul 84 15:53 EDT From: Pirish.wbst Subject: Re: Lisp: Suspected compiler bug In-reply-to: LispSupport.pa's message of 11 Jul 84 10:07 PDT To: LispSupport.pa cc: Pirish.wbst, Koomen.wbst, AHenderson.pa, Hannaway.wbst After poking around in Trillium, we (the WBST folks) found that the default has indeed been set to compile variables as LOCALVARS. [Austin - See in TRILLIUM: (DECLARE: DOEVAL@LOAD (LOCALVARS . T)...] This explains our current problem with TRILLIUM.PRINTOUT, and other problems that have cropped up lately with NLAMBDAs. However, we still can't figure out why earlier versions of Trillium did not have this problem, since LOCALVARS is the default at least as far back as June, 1983. The only thing we can think of is that one of the Trillium files that loads after TRILLIUM turned LOCALVARS off, and recently that file was changed. Sorry to bother you with all of this. We will have to work it out in Trillium. Thanks, Peggy *start* 01077 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Mon, 2 Jul 84 09:56 PDT From: PYoung.pasa Subject: Re: Testing VMS DEI In-reply-to: "MASINTER.PA's message of 1 JUL 84 19:41 PDT" To: MASINTER.PA cc: PYoung, Sheil.PA, LispSupport.PA We have a VMS VAX here, recently installed, now with a private net and an 1108. I have been spending almost all of my time verifying DEI 6.1 (the candidate for the next release) and revising installation procedures and documentation. I don't know the exact reasons why GSL didn't upgrade to DEI 6.0 (the current release) when it was announced but I can guess: DEI 6.0 contains a substantial change in architecture and new code at the device driver level. This increases the chances of crashing VMS, an event unpopular with system managers and users of large systems. We have indeed experiencedsome system crashes with DEI 6.0 and have attempted to rid DEI 6.1 of all of their causes. I would expect GSL to upgrade once they are convinced DEI 6.x is stable: it's performance greatly outstrips that of DEI 5.0. Phil *start* 00519 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 2 Jul 84 15:26 PDT From: Masinter.pa Subject: Re: Testing VMS DEI In-reply-to: PYoung.pasa's message of Mon, 2 Jul 84 09:56 PDT To: PYoung.pasa cc: MASINTER.PA, Sheil.PA, LispSupport.PA Phil, I will help encourage GSL to update, so that we can participate in 6.1 testing, once you've completed testing. Can you come and help install the software and/or reassure their folks about its reliability (once you can do so with a straight face?) *start* 00512 00071 UUm @00045 01536 ftffffffffffffffffffffffffffffff @Date: 1 JUL 84 19:41 PDT From: MASINTER.PA Subject: Testing VMS DEI To: PYoung.pasa cc: Sheil, LispSupport Phil, After you've done preliminary testing, or even before, it would *really* help to shake down the VMS code by installing it on the GSL Vax at Parc. GSL offered a long time ago to give us accounts for testing purposes. Right now, GSL is running DEI 5.0 with its known problems.... have there been problems in updating it? *start* 00593 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 11 Jul 84 17:11 PDT From: Masinter.pa Subject: Jim Helman query about new DEI To: DEI-Support^.es, PYoung.pasa, LispSupport Reply-to: MASINTER.PA From: HELMAN 25-APR-1984 15:51 * To: BOYCE,BACHRACH,MASINTER,HELMAN Subj: DEI SOFTWARE BUG TO WHOMEVER IS ON THE DEI MAILING LIST: EL SEGUNDO SAYS THEY HAVE A FIX FOR THE BUG WHICH CAUSED SEVERAL SYSTEM CRASHES WHILE WE TRIED TO RUN VERSION 6.00. THEY WILL BE ANNOUNCING DISTRIBUTION SOON. IF YOU GET ANY DETAILS, PLEASE LET ME KNOW. THANKS, JIM H. *start* 22749 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 12 Jul 84 00:23 PST From: ckiparsky.pa Subject: [ckiparsky.pa: TEdit: causes break] To: TEditSupport.pa cc: ckiparsky.pa Format: TEdit Throw away the one I just sent - this is a correction. ----- Begin Forwarded Messages ----- Date: 11 Jul 84 23:47 PDT From: ckiparsky.pa Subject: TEdit: causes break To: TEditSupport.pa cc: ckiparsky.pa Format: TEdit TEdit System Date: 19-Jun-84 02:57:16 Lisp System Date: 3-Jul-84 23:02:11 Machine: Dandelion (-569758442) Microcode version: 24,4 Memory size: 16000 Frequency: everywhere in a certain window Impact: bad I copied some text (T) into an editW. For some reason it refused to submit to copying by shift-selection, so I took a picture of it using <^O>. Thereafter every , regardless of distance from the bitmap, brought up this delight: (1 0) (456 172 "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO@OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO@OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGIOOCCOI@@B@AN@@GHGO@CH@CLL@CH@CL@O@@GNGOOOOL@CO@@NAO@OHGLCOOOOIOLO@CLONGOCOH@@" "@CH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGIOOCAOICONGLFGONCALGIIOILLOIOIOANCCOCNGONFGOOCOOLLLNFGCCIIOOOOHOLLGHLGNGOAOH@@" "@GH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGIOOC@OICONGNFGOLOLLOLIOLLLOLOIOCOCCOINGONFGONGOOIINDOBGICLOOOOHGLLOLLCNGO@OH@@" "@CHOGCHLNCCMO@@@@@@@@@@@@@@@@@@@@@CONGIOOCBGICONGOBGOLOLIOLIOLLLOLOINGOICOINGO@@AOLOOOCINDOBGICLOOOOICLIONDINGOBGH@@" "@CHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CONGIOOCCCICONGOBGONGOIOOIOILLOLOINGOICOCNGOLLOOLOOOCOLLOBGICLOOOOIILIONDLNGOCCH@@" "@CHHDJEBIDB@D@@@@@@@@@@@@@@@@@@@@@CONGIOOCCCI@@FGOB@@O@CIOOH@ALLOIOINGOI@@CNGOLLOOIOONGN@LOBGICLOOOOIILIONDLNGOCCH@@" "@CHNGCIBNCCHD@@@@@@@@@@@@@@@@@@@@@COHOIOOCCIICONGOBGOOOIIOOIOLLL@COINGOICOIOAOIIOOIOONGONDOBGICLOOOOILLIONDNFGOCIH@@" "@CHHEBIBJ@J@D@@@@@@@@@@@@@@@@@@@@@CONGIOOCCLICONGOBGOOOLIOLIOLLLOOOINGOICOINGOIIOOIOONGINDOBGICLOLAOINDIONDOBDACLH@@" "@GHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CONGIOOCCNACONGNFGOLOLLOLIOLLLOOOIOCOCCOINGL@@GOCOOLOINDOBGICLOOOOIO@LOLLOHGOCN@@@" "@AHODJDLICCLD@@@@@@@@@@@@@@@@@@@@@CONGIOOCCOACONGLFGONGILGIIOLLLOOOIOANCCOINGOCCOOCOALOLLNFGCCIIOOOOIOHLGHLOLGOCO@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGH@CCCOI@@B@AN@@G@CO@CIOLLLOOOIOL@OCOINGOCCOOCOALONAO@OHGLCOOOOIOLO@CLONGOCOH@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGOOOOOOOIOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CONGOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOONGOOOOOOOIOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AHNGCLDIA@@@@@@@@@@@@@@@@@@@@@@@@COO@OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO@OOOOOOOOCOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AHIDJ@JJC@@@@@@@@@@@@@@@@@@@@@@@@COOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOON@@" "@AHIDJ@JLA@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHNGCHJLA@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHIEBAOJA@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHIDJAAIA@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHNDKMAHKH@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOOKHNOHBELNACON@CAILOGJD@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@BEBIBHI@@DJEBHDCD@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@BEBIBHI@@DBABHDCL@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGBDDB@BELIBHIL@CBALNGCL@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@BE@IGLI@@@JADHDBL@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDBBBE@IDDI@DDJEBHDBL@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGKHNBBAI@NDDINDCAIBOGJD@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLDDGAA@@DDHIACNGHG@N@@A@O@N@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLFDHII@@FDHIKB@DDBAA@@BHHIA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLFDHII@@FDHIKB@DDBAA@@BHHIA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOOKHNOHAMBFGKIO@DKILBGOLLFGCMNICLEDHIE@@EDHIECLGHBA@@@BHOA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@@IJIDBDD@DJEBEABABIDJA@MCLEDHIECNEDHIEB@E@BA@@@DDJAG@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@@INHDBDD@DJEBEABA@HDJA@OCLDLHIC@@DLHIEB@DHBAA@@GLIAA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGBDDB@@INFGCHD@DKIBEACHLHGCILOCLDLHIC@@DLHIEB@DDBAA@@DDHIA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@@IFADBHD@DJABOIB@BHEBA@KCLDDGAA@@DDGAACNDDG@N@@DDHHN@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDBB@IFIDBDDDDJABHIBABIDJA@KCL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGKHNBBAMBFGJDDDCBALHICLLFDKMNICL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@L@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLA@H@NBBGLOAOALCHO@NCLGLGAN@HADOH@CNCHG@NAL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOOKHNOHB@NICCMLOH@@@@@@@@@@@@@@CLA@H@DCBD@HI@BBDDHHDBBA@HIA@HAD@H@@BDDHIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@B@DMDJABB@@@@@@@@@@@@@@@CLA@H@DCBD@HI@BBDDHHDBBA@HIA@HGNA@@@D@DIICBF@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@A@DODBABB@@@@@@@@@@@@@@@CLA@H@DBJGHHINAHD@O@DBBA@HIN@HBHA@@@DCHJIEBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGBDDB@A@DOCCILB@@@@@@@@@@@@@@@CLF@H@DBJD@HI@@DD@J@DCLA@HID@FBHB@@@H@DJIEBJ@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDB@@HDK@JADB@@@@@@@@@@@@@@@CLA@H@DBFD@HI@BBDDI@DB@A@HIB@HOLB@@@H@DLIICB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBDBDDBB@HDKDJABB@@@@@@@@@@@@@@@CLA@H@DBFD@HI@BBDDHHDB@A@HIA@HE@D@LA@DDHIABB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHBGKHNBB@DNICCMBB@@@@@@@@@@@@@@@CLA@OHNBBGLOAOALCHHHNB@A@GAA@HE@D@DA@CHG@NAL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@D@@@@@@@@@@@@@@@@@@@@@@CLA@@@@@@@@@@@@@@@@@@@@@@@@@@H@@@@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@L@@@@@@@@@@@@@@@@@@@@@@@@C@@@@@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOGCHLNCCMO@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@CHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@CHHDJEBIDB@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@OHNGCIBNCCHD@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHEBIBJ@J@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHODJDLICCLD@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOGCHLNCCMO@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDB@D@@@@@@@@@@@@@@@@@@@@@CL@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHNGCIBNCCHD@@@@@@@@@@@@@@@@@@@@@CLA@OIOCLCHOH@BBGHO@DCNGL@@NALGHOIOBB@@H@@@@D@@@@@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHEBIBJ@J@D@@@@@@@@@@@@@@@@@@@@@CLA@BA@BBA@B@@BBDDHHJ@HD@@AABBDDHA@CB@@H@@@@D@@@@@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CLB@BA@BBA@B@@BBDDHHJ@HD@@AABBDDHA@CB@@KAFALDHGAF@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHODJDLICCLD@@@@@@@@@@@@@@@@@@@@@CLB@BANBBA@B@@BBDDHHJ@HGH@@LB@GHOANBJ@@LIIBBE@HII@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLB@BA@BBA@B@@BBGHHIA@HD@@@BB@E@HA@BJ@@HI@BBF@OIA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLB@BA@BBA@B@@BBD@HIO@HD@@AABBDHHA@BF@@HI@BBE@HAA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLB@BA@BBA@B@DBBD@HIA@HD@BAABBDDHA@BF@@LI@BBDHHIA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOGCHLNCCMO@@@@@@@@@@@@@@@@@@@@@CLA@BAOCLCHB@DALD@OAA@HGLB@NALDDOIOBB@@KA@ALDDGAA@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CLA@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDB@D@@@@@@@@@@@@@@@@@@@@@CL@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@A@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHNGCIBNCCHD@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHEBIBJ@J@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CLCHOH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHODJDLICCLD@@@@@@@@@@@@@@@@@@@@@CLDD@H@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@DA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CLCHA@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@DB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOGCHLNCCMO@@@@@@@@@@@@@@@@@@@@@CL@DB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CLDDD@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDB@D@@@@@@@@@@@@@@@@@@@@@CLCHD@D@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHNGCIBNCCHD@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHEBIBJ@J@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHHDJEBIDJ@D@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHODJDLICCLD@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHOH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AHB@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@AH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@GH@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@CL@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@") The first time I had tried to put a return in front of the bitmap, which usually works fine. The text in question (T) is: **** Hit . With the entry completely specified for agreement, you can try the parse again. To save some typing, type in the top level _REDO Assuming you have typed nothing in to the top since the parse ***** carol ----- End Forwarded Messages ----- c TIMESROMAN  TIMESROMAN TIMESROMAN 6 TIMESROMAN - TIMESROMAN < TIMESROMAN P BMOBJ.GETFN‹ TIMESROMAN ì TIMESROMAN i TIMESROMAN  TIMESROMAN ì TIMESROMAN ì TIMESROMAN  TIMESROMAN ì TIMESROMAN ì8 TIMESROMAN  TIMESROMAN ì TIMESROMAN ì TIMESROMAN ì TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN ( TIMESROMAN  TIMESROMAN TÖ&z¸*start* 01477 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Sender: Sannella.PA Date: 17 Jul 84 14:52:05 PDT (Tuesday) Subject: FMEMB loops forever in TypeInMethods To: LoopsCore^.pa cc: LispSupport.pa, Foster.pa From: LispSupport.pa Reply-To: LispSupport.pa In the message below, Foster.pa reported a place where he got an infinite loop in FMEMB (apparently, FMEMB was passed an "improper" list, which it doesn't detect). Eventually, he gave me some hardcopies of his break window, which enabled me to discover that there seems to be a Loops bug inside of the function TypeInMethods. The stack is: ... (PPW (_Remote)) ... (WHEREIS 1421 'FNS) (INFILECOMS? 1421 'FNS) (TypeInMethods ...) (FMEMB ... 1421) --> loops until It is a bug for TypeInMethods to call FMEMB with a second argument that is not a list. Even if you replaced MEMB for FMEMB, this would just cause an error rather than looping. There seems to be a real bug in Loops. ---------------------------------------------------------------- Date: 16 Jul 84 17:27 PDT From: Foster.pa Subject: Lisp: FMEMB loops forever and doesn't block To: LispSupport.pa cc: Foster.pa Lisp-System-Date: 3-Jul-84 16:48:16 Machine-Type: Dorado Somewhere underneath WHEREIS there was a call to FMEMB with odd argument (non-standard list). CDR loops without blocking. Lisp-System-Date is really 21-jun-84 (3-Jul-84 is the LOOPS date). --Gregg ---------------------------------------------------------------- *start* 00518 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: 17 Jul 84 23:56 PDT From: masinter.pa Subject: Re: FMEMB loops forever in TypeInMethods In-reply-to: LispSupport.pa's message of 17 Jul 84 14:52:05 PDT (Tuesday) To: LispSupport.pa cc: LoopsCore^, Foster To make (FMEMB 'A 'B) cause an error (ADVISE '\CDR.UFN '(AND X (NLISTP X) (ERRORX (LIST 4 X] I'm going to put this in as an available option on CAR/CDR errors, to have (CAR non-list) return {garbage}, but make (CDR non-list) error. *start* 00385 00071 UU @00045 01536 ftffffffffffffffffffffffffffffff @Date: Fri, 20 Jul 84 22:33 PDT Sender: Raim.pasa Subject: New software loadup To: Arpa1100Users^.pasa From: 1100Support cc: 1100Support Reply-To: 1100Support The 1100USERS account on Maxc has been temporarily disabled due to the transition from Fugue.6 to Carol. 1100USERS will be enabled on Tuesday, July 24. *start* 01645 00024 US Date: 26 Jul 84 09:24 EDT From: Gocek.henr Subject: Lisp: DLion configuration problems To: LispSupport.pa cc: Gocek, Boesl, Goetz, Evanitsky, Hill, PSWall Lisp-System-Date: 21-Jun-84 10:50:28 Machine-Type: Dandelion, 43 MB, two button mouse Configuration program: Othello 9.0d Attempted logical volume configuration: Diagnostics - debugger - 4000 pages Lisp - normal - 16200 Lisp2 - normal - 16200 Lisp3 - normal - 7000 Lisp4 - normal - 10000 Dsk - normal - 11874 I had planned on using InstallLispTool to do Remote-Boots. Lisp3 would be my clean volume for the Lisp working volume, and Lisp4 would be the clean volume for the Lisp2 working volume. DLion.Germ, Mesa.db, and TajoDLion.boot were installed on Diagnostics. The Initial Microcode was Lisp>Current>Lisp10SAx000Initial.db. Sysouts were installed using Diagnostic Microcode Fetch for all four Lisp volumes. I brought Lisp>Current>Full.Sysout up on Lisp, i.e. I successfully started it. Lisp told me that it had created a CoreDevice named DSK. Problems: (VOLUMEDISPLAY 'ON) brought up the window, but the only volume that showed any attributes was Diagnostics. Not even the names of the other five volumes appeared in the window. There were six lines in the window, but the last five implied that the volumes weren't created. (MKDIR 'DSK) resulted in a message saying that Lisp did not recognize a volume named DSK. (CURRENTVOLUME) caused a 9016 maintenance panel code, and locked up the keyboard and mouse. I fixed this problem by reconfiguring my Dandelion so that Dsk was the first logical volume in the list instead of the last. Thanks, Gary *start* 02414 00024 US Date: 26 Jul 84 10:03 EDT From: Gocek.henr Subject: Lisp and/or Trillium: MAKESYS problems To: LispSupport.pa, TrilliumCore^.PA cc: AHenderson.PA, Gocek, Boesl, Goetz, KMatysek, Garnaat, McFarland, PSWall Lisp-System-Date: 21-Jun-84 10:50:28 Trillium-Version: {Aztec}Birthday84>Alpha Machine-Type: Dandelion, 43 MB My logical volume configuration follows: Dsk: 13175 pages Diagnostics: 3500 Lisp: 16200 BootCurrent: 16200 BootTrillium: 16200 I use InstallLispTool to do Remote-Boots from the two Boot volumes into the Lisp volume. The Lisp volume is the only volume that I Start. Initial Microcode Fetch:Current>Lisp10sax000initial.db. My problems stem from trying to create a sysout on Dsk (bigtrillium.sysout). 1. Load {aztec}Birthday84>Alpha>Trillium.DCOM. 2. Load local Trillium itemtypes, etc. 3. Add a Trillium report form to LafiteSpecialForms 4. Masterscope Analysis of Trillium 5. Connect to Dsk 6. (TRILLIUM.MAKESYS T) (MKDIR 'DSK) had previously worked correctly. (VOLUMEDISPLAY 'ON) showed over 12500 free pages on DSK prior to step 6. I turned off the VOLUMEDISPLAY before I entered step 6. TRILLIUM.MAKESYS asks a few questions and then does a MAKESYS. After confirming the filename (bigtrillium.sysout) the promptwindow and top level typescript window were blanked. The cursor remained an arrow and showed swap reads, i.e. a line flashed at the top of the arrow. I let this run from 11:30 am to 9:00 am. I couldn't break out, although I could move the cursor. I had to boot out. {DSK}BigTrillium.Sysout did not exist. So, I cleaned up and loaded everything again and successfully wrote a sysout to {Aztec} in about two and a half hours, and I successfully reinitialized Lisp with that sysout. We tried to reinit two different 1100's with the new sysout. We double checked the versions of the microcode and Lisp.Run, but Lisp would not come up. The FTP cursor diddled its way down the blank Alto exec screen, and turned into an hourglass. The whole 15" screen then turned white, the cursor changed to an arrow, and the systems stopped there. The cursor could be moved, but Lisp would not appear. The sysout appears to work on the Dlions, but not on the 1100's. It is stored as {Aztec}Birthday84>Beta>BigTrillium.Sysout. Note the Beta subdirectory, as opposed to Alpha. The file is 9800+ pages long. Thanks, Gary *start* 01028 00024 US Sender: Sannella.PA Date: 27 Jul 84 14:26:25 PDT (Friday) Subject: Re: Lisp: DLion configuration problems In-reply-to: Gocek.henr's message of 26 Jul 84 09:24 EDT To: Gocek.henr cc: LispSupport, Boesl.henr, Goetz.henr, Evanitsky.henr, Hill.henr, PSWall.henr From: LispSupport.pa Reply-To: LispSupport.pa Something is seriously wrong here. If the VOLUMEDISPLAY window did not show all of the volume names, then the local file system can't be interpreting the disk correctly. Have you tried formatting your disk with Othello 10.0? That is the installation tool that we have used here. I that there are no incompatible changes between 9.0 and 10.0, but I may be wrong. When you put DSK as the first volume on the disk, can you use the local file system? Have you tried creating files, listing the directory, etc. to the volume DSK? Are you sure that it is going to the disk volume DSK, rather than to a lisp coredevice DSK (i.e. do the files on {DSK} disappear if you load in a new lisp sysout?)? *start* 00927 00024 US Sender: Sannella.PA Date: 27 Jul 84 14:34:28 PDT (Friday) Subject: Re: Lisp and/or Trillium: MAKESYS problems In-reply-to: Gocek.henr's message of 26 Jul 84 10:03 EDT To: Gocek.henr cc: LispSupport, TrilliumCore^, AHenderson, Boesl.henr, Goetz.henr, KMatysek.henr, Garnaat.henr, McFarland.henr, PSWall.henr cc: Stansbury From: LispSupport.pa Reply-To: LispSupport.pa (1) SYSOUT to {DSK}. See my previous message about the local file system. If the local file system is not interpreting your disk correctly, SYSOUT to DSK could not possibly work. (2) Loading 1108 SYSOUT on 1100. This is a known bug. Due to the way that the stack is aligned when running Interlisp on a Dlion, it is not possible to run an 1108 sysout on an 1100. All other translations work (1132->1108, 1132->1100, 1100->1132, 1100->1108, 1108->1132). This is a very hard problem, and it is unlikely to be fixed anytime soon. *start* 00807 00024 US Date: 30 Jul 84 09:52 EDT From: Gocek.henr Subject: Re: Lisp: DLion configuration problems In-reply-to: LispSupport.pa's message of 27 Jul 84 14:26:25 PDT (Friday) To: LispSupport.pa cc: Gocek.henr When DSK was made the first volume of my 1108 configuration, it became available as a rigid disk storage device. That was not the case when DSK was the last logical volume. I am positive that I can store to disk now, as opposed to a coredevice. Since this is the case, I'm not really willing to try to run Othello 10.0 to repartition my disk again. As far as I can tell, the order of the volumes is the only difference is my two attempts at configuring the 1108. Since the problem was completely solved by changing the order, I am willing to accept the problem as a fluke. Gary