perm filename MSGLOG.MSG[S,AIL]8 blob
sn#080190 filedate 1974-01-08 generic text, type T, neo UTF8
00100 COMMENT ⊗ VALID 00005 PAGES
00200 C REC PAGE DESCRIPTION
00300 C00001 00001
00400 C00002 00002
00500 C00013 00003 ∂15-MAY-73 0648 GEM,TVR
00600 C00032 00004
00700 C00052 00005 -------
00800 C00053 ENDMK
00900 C⊗;
00100
00200 I fixed up the file of this morning's message (but still have a listing
00300 in case you want to see it) but it still "DRYROTS". The file is
00400 TRY.SAI[G,MJC]. Is there something special I should know about for-stmts?
00500 Mike Clancy
00600
00700 17-NOV-72 1742 G,MJC
00800 A program which I wrote to try to learn a few things (namely SAIL and the
00900 Quam display routines) uncovered a "DRYROT" error. The program is
01000 TRY.SAI[G,MJC], and the error occurred in line 2600. Any suggestions?
01100 Mike Clancy
01200
01300 JAM again. Sorry, it doesn't go away with
01400 an "IF TRUE THEN", only with an "IF FOO THEN"
01500
01600 22-NOV-72 2344 MA,JAM
01700 JAM here bringing to you yet another
01800 insidious SAIL bug. There is a program
01900 BUG.SAI[MA,JAM] which compiles the following
02000 code incorrectly (see page 6 of source file):
02100
02200 BEGIN "FLTO"
02300 REAL ARRAY Y[1:LN+GWIDTH];
02400 *** LOTS OF STUFF ***
02500 END "FLTO";
02600 BEGIN "DPGT"
02700 INTEGER ARRAY BUF[1:5500];
02800 *** MORE STUFF ***
02900 END "DPGT";
03000
03100 The following code appears:
03200
03300 DPGT&DPGT.-6/ PUSHJ P,BEXIT
03400 DPGT&DPGT.-5/ PUSH P,3 ; LOWER ARRAY BOUND???
03500 DPGT&DPGT.-4/ PUSH P,[=5500] ; THIS IS OK
03600 DPGT&DPGT.-3/ PUSH P,3 ; IT SEEMS TO THINK AC3 CONTAINS A 1
03700 DPGT&DPGT.-2/ PUSHJ P,ARRMAK
03800
03900 This, of course, gets a "UPPER BOUND<LOWER BOUND" error
04000 message, for constant bounds yet! Anyway, the problem
04100 goes away if you put an "IF TRUE THEN" in front of
04200 the BEGIN "DPGT". Is that enough?
04300
04400 22-NOV-72 2341 MA,JAM
04500 Dear Ail,
04600 CASE n OF (ITV, ITV, ... ITV) generates, in at least one case
04700
04800 <case check>
04900 JRST @TABLE(IDX)
05000 PUSH P,ITV
05100 JRST DONE
05200 ...
05300 PUSH P,ITV
05400 JRST DONE
05500 TABLE: .-...
05600 .-...
05700 ...
05800 TABLE-2
05900 DONE: POP P,TBITS2
06000 MOVE A,0 ;!!!!!!!!!!!
06100 ....
06200 This is fairly recent (MOVE s/b MOVE A,TBITS2 or whatever).
06300
06400 DCS
06500
06600 20-NOV-72 0341 SLS,DCS
06700 I RAN INTO PROBLEMS WHEN USING THE SAIL DPB COMMAND.
06800 THE CODE GENERATED FOR THE INSTRUCTION
06900 DPB(A,POINT(11,BUFX[POINTER],10))
07000 SEEMED TO LOAD A INTO REGESTER 10 AND PROMPTLY DEPOSIT REG 11.
07100 THE PROGRAM IS TEST.SAI ON [1,EMC], AND THE OFFENDING LINE IS IN THE
07200 AIVCT1 PROCEDURE FOUND ON PAGE 4, I BELIEVE.
07300 19-NOV-72 0831 1,EMC
07400 HELP!
07500 DON'T PUT UP THE NEW SAIL.
07600 TWO DEMOS ON MONDAY. THIS WOULD
07700 BE THE 4TH DEMO IN SUCCESSION IMMED
07800 AFTER A SAIL CHANGE.
07900 TOB
08000 07-DEC-72 1419 H,HJS
08100 K PINGLE FOUND A BUG HAVING TO DO WITH AN ILLEGIT. ARRAY NAME IN AN
08200 ARERR UUO FOR COMPLICATED EXPRS. SERIOUS ENOUGH TO FIX. SEE BUG #KR.
08300 DCS
08400
08500 06-DEC-72 2219 SLS,DCS
08600 NASTY BUG IN SAIL SETBREAK(TABLE,STRDELIM,STRDELETE,SWITCHES);
08700 IF YOU DO A SETBREAK WITH CHARACTERS TO BE DELETED,
08800 THEN LATER IN THE PROGRAM YOU DO ANOTHER SETBREAK ON THE SAME TABLE NUMBER
08900 WITH NULL STRDELETE, IT CONTINUES TO USE THE OLD STRDELETE!!!!
09000
09100 06-JAN-73 1737 1,REM
09200 Is my observation correct? I have a block full of
09300 CONTINUEs, and I find that the first one jumps to
09400 the second, the second jumps to the third, and so
09500 on to the last one!!???
09600
09700 04-JAN-73 0959 MA,JAM
09800 The SAIL error: BEGIN AND END DO NOT MATCH
09900 could be more helpful in telling which are
10000 the BEGIN block names.
10100
10200 19-DEC-72 1609 WRU,TOB
10300 JAM here. I have a SAIL program that I said ↑C - SAVE
10400 to. The dump copy is SAVBUG.DMP[MA,JAM]. If you RUN it,
10500 it generally says "ERROR IN JOB 26, PC EXCEEDS MEM BOUND
10600 AT USER 400013", indicating to me that the second segment
10700 isn't hooked up. If you GET it and START it, sometimes it
10800 works and sometimes not. This doesn't seem to happen if I
10900 SAVE the program before it is ever run for the first time.
11000 If I start it up, then stop it and save it, this often
11100 happens.
11200 Please delete the file SAVBUG.DMP[MA,JAM] when
11300 you are finished with it.
11400
11500 18-DEC-72 1151 MA,JAM
11600 export version of sail should not have dump never bit on in
11700 rel files created. fancyy technique for writing over ddt doesn't seem
11800 to work with export.
11900 jim low
12000
12100 16-DEC-72 1444 S,JRL
12200 THE 7-LINE PROGRAM BUG.SAI[1,REM] COMPILES INCORRECTLY BY SAIL.
12300 JNAM←CVSIX("[LXGP]"); COMPILES AS MOVSI NIC,0;MOVEM NIC,JNAM;
12400
12500 14-JAN-73 1824 1,REM
12600 YOU OUGHT TO FIX SAIL SO YOU CAN SPECIFY ODD FILE NAMES, LIKE [-AP-].DMP
12700 IN AN ENTER. PERHAPS, ADOPT THE COPY CONVENTION ABOUT ↓ TO SURROUND A
12800 QUOTED NAME.
12900
13000 01-FEB-73 1236 TAP,REG
13100 There is a deeper bug but you can cure your immediate problem by parenthesizing
13200 the expression TK([A⊗O≡V]) in your macro IV. Syntactically the parens are
13300 required since a boolean expression inside a foreach associative context musht
13400 be parenthesized.
13500 jim
13600
13700 06-FEB-73 1126 S,JRL
13800 IT USED TO BE THAT INCHWL WAS ONLY TERMINATED BY <CRLF> NOT
13900 BY <ALT> OR <LF> OR BARE <CR> OR ANY OTHER ACTIVATION CHARACTER.
14000 A FEW MONTHS AGO INCHWL BEGAN TO BE TERMINATED BY THE OTHER ACTIVATION
14100 CHARACTERS AS WELL. THIS LASTED FOR ABOUT A MONTH, THEN RETURNED TO
14200 THE <CRLF> ONLY METHOD. NOW TONITE I FIND THAT INCHWL IS AGAIN TERMINATED
14300 BY ANY ACTIVATION CHARACTERS. WHY DOES IT KEEP CHANGING???
14400
14500 06-FEB-73 0124 1,REM
14600 The next person to make a new compiler might have some KVL typos to contend
14700 with (Gen pg 51,52,53 and Hel pg 15) due to implementation of ACCESS. The
14800 slow system prevents me from making a compiler myself today.
14900 -peace and love - KVL
15000
15100 06-MAR-73 1430 1,KVL
15200 BOTH OLD AND NEW PUB USE SAISG5 VERSION; BUT THE NEW CORE IMAGE IS
15300 3K BIGGER THAN IT USED TO BE 7 WEEKS AGO. ANY IDEA WHY? I ONLY
15400 ADDED A LINE OR TWO OF CODE. (COMPARE PUB2.DMP AND PUB2.OLD
15500 ON [1,3]).
15600 --- LARRY TESLER
15700
15800 05-MAR-73 1151 2,TES
15900 Russ: We need to fix the realin (intin) and any associated code
16000
16100 to handle overflow conditions by having a JFCL immediately following
16200 any instruction which can cause an overflow. In particular, realin
16300 with a large integer part followed by a large number of fraction part
16400 zerowill cause an overflow.
16500
16600
16700
16800 14-MAR-73 2024 1,PDQ
16900 RUSS: I GOT A "DRYROT AT EFORM" MESSAGE WHEN TRYING TO COMPILE
17000 FILE AESTH.SAI[A,JEG]. DAN SAID IT WAS A COMPILER ERROR AND THAT
17100 YOU ARE THE PERSON TO SEE. SUGGESTIONS? THANKS.
17200 - JIM
17300
17400 07-APR-73 1850 A,JEG
17500
17600 ∂15-MAY-73 0329 2,TES
17700 The new version of SAIL will not compile PUB.
17800 See PPSAV.PUB[2,TES]. I tried twice.
17900 Larry
18000
18100
18200 ∂15-MAY-73 0202 SLS,DCS
18300 Larry Tesler couldn't get PUB up with new segment, so I
18400 managed to get one running with SAISG5.513, SSAVED it
18500 and changed named of segment to SAISGN -- put it on the
18600 system. The old dmp is PUB.DMP[
18700 (sorry) PUB.DMP[SLS,DCS] if you want to try again, else
18800 please delete it. Larry will probably follow advice and
18900 put it up with the library, at least for a while, soon.
19000 Dan
19100
19200
00100 ∂15-MAY-73 0648 GEM,TVR
00200 Thank you for the pleasure of reloading my program because of change to SAISG5!
00300
00400 ∂04-JUN-73 1245 SLS,DCS AT TTY62
00500 Sorry -- wasn't careful enuf in my examination of the problem. SGLIGN
00600 is MISSING from HLBSA5, tho PRESENT in LIBSA5!!!! What a strange
00700 situation. I refrained from inserting it, so you could study the
00800 anomaly in situ if you wished.
00900 Dan
01000
01100 ∂04-JUN-73 1025 LDE,DCS
01200 IS THERE ANY GOOD REASON THAT POW & FPOW ARE NOT MADE "HERE"?? SINCE THE
01300 COMPILER CALLS THEM DIRECTLY, SOMETIMES, ANYTIME A NEW SEGMENT IS MADE, A
01400 NEW COMPILER MUST ALSO NEEDS BE MADE.
01500 LEE ERMAN
01600
01700 ∂03-JUN-73 1105 SLS,DCS
01800 There are no HEAD syms on either library. Weiss du das?
01900
02000 ∂13-JUN-73 0204 1,MSW
02100 HELLO I AM ONE OF JEENA'S COLLEAGUES. IHAVE A SMALLPROGRAM
02200 ON MIR.SAI WHICH YOU MAY LIKE TO SEE. IT DOES A LOT OF WIERD
02300 THINGS. TWO COMMENTS IN THE PROGRAM WILL POINT THE PROBLEMS.
02400 THEY ARE SYSTEM BUGS OR THE DOCUMENTATION WE HAVE IS
02500 OUTDATED. I WOULD LIKE TO HEAR YOUR OPINION ON THIS.
02600 MY NAME SHRIRAM.
02700 MY FILE MIR.SAI ON [1,MSW]
02800 THANX.BYE.
02900 ∂19-JUL-73 1102 IML,BO AT TTY113
03000 SAIL BUG: USING PORTRAN PROCEDURE ATAN2, THE EXPRESSION
03100 ATAN2(A-B,C-D) USES THE SAME TEMPORARY STORAGE LOCATION FOR
03200 BOTH OF THE EXPRESSIONS IN THE CALL.
03300
03400 ∂04-AUG-73 1526 1,LDE
03500 Please see LEAP.SAI[1,LDE] ( a five line program) for what seems to be
03600 a ridiculously basic Leap bug.
03700 _
03800 ∂3-AUG-73 0826 network site CMUA
03900 An ENDC followed by an ELSEC gives a non-helpful error message of
04000 ILL MEM REF. (See BADCOM.SAI[1,LDE) for and example.)
04100 Lee Erman
04200
04300 ∂20-AUG-73 1557 MA,JAM
04400 Hi. JAM here. I think I have discovered a feature,
04500 but it might well be considered a bug. Try to
04600 compile SAIBUG.SAI[MA,JAM] and it will get an
04700 error on page 8 that says "Not enough params supplied
04800 to procedure". To save you some looking, the statement
04900 is:
05000 P1←PITCH(NLEND(RG1));
05100 P1 is a real, RG1 is an integer. PITCH is a macro defined
05200 on page 4 as:
05300 DEFINE PITCH(PK)="RGET(PK,1)";
05400 RGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
05500 of two integer arguements.
05600 NLEND is a macro defined on page 5 as:
05700 DEFINE NLEND(R)="PGET(R,2,TRUE)";
05800 PGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
05900 of two integer arguements and one boolean arguement.
06000 What seems to happen is that the terminal ",1" in
06100 the expansion of PITCH seems to get lost. If I put in
06200 REQUIRE "⊂⊃⊂⊃" DELIMITERS; above the call, it gets past that
06300 point. As I say, this may be a feature, not a bug, but here
06400 it is anyway.
06500 ∂15-OCT-73 1032 network site MAXC
06600 -------
06700 Date: 15-OCT-73 1032
06800 From: SPROULL at PARC-MAXC
06900 Re: Bug in INTMOD
07000 - - - -
07100 I belive that there is a bug in the export version of
07200 INTMOD (interrupt handler) in NWORLD. I was reading the code,
07300 preparatory to doing some shit for NIH, and I found this
07400 exciting mask that is commented "insure only legit bits"
07500 Unless I am very much mistaken, the person that put together
07600 that mask counted bits from the left beginning at 1, not 0,;;;
07700 the result is that the mask is WRONG. Consult page 3-2 of the
07800 DEC Assembly Language Book, and behold!!!!
07900
08000 Am I right??
08100 -------
08200
08300 ∂08-OCT-73 1322 MA,JAM
08400 JAM again. With reference to my last note, it
08500 would appear that the problem is not necessarily
08600 SAIL's but instead the LOADER's problem. That is,
08700 if I say EX PP/DUMP, it executes fine but the
08800 dump file is garbaged. If I say LOA PP then
08900 SAVE, the dump file is OK. OK? Maybe you ought
09000 to pass this on to whomever 'fixed' the LOADER,
09100 whoever that is.
09200
09300 ∂08-OCT-73 1314 MA,JAM
09400 Hi. JAM here with another SAIL bug. If I SAVE my
09500 program with the indicated amount of core from the
09600 LOADER, it gets "RELEASE&: INVALID CHANNEL NUMBER"
09700 If I SAVE it in one more K than that, it works fine.
09800 See for yourself. The failing version is BUG.DMP[MA,JAM],
09900 the winning version is PP.DMP[MA,JAM]. Source file
10000 is PP and is assembled alone. To run:
10100
10200 RU BUG[MA,JAM]
10300 Input file: JJJ.SND[SND,JAM]
10400 Output file: FOO.TMP
10500 Clock rate: 20000
10600 Lower frequency bound: 50
10700 Upper frequency bound: 300
10800 Step in Ms: 5
10900 stp = 100
11000 Decay constant = .9480775
11100 Min. frequency resolution in Hz: 1
11200 167 frequency points
11300
11400 at this point, program will either immediately
11500 fail or start computing ad infinitum. Happy
11600 hunting. P.S., this is not unique to this program,
11700 I have several others that exhibit this behavior.
11800 ∂19-OCT-73 1450 2,MLM AT TTY110
11900 SAIL PEOPLE: Found a DRYROT. I know what the mistake in the source file
12000 is, but you might be interested in the compiler problem that causes this
12100 DRYROT message. Compile DRYROT.SAI[2,MLM] and you will get message.
12200 You may copy, delete, etc. this file.
12300 ∂21-OCT-73 2140 204,MLM AT TTY110
12400 SAIL PEOPLE: Have found another DRYROT; I know what's wrong but again
12500 thought you might be interested. Should I bother reporting these as
12600 the Monitor manual suggests, or are they so common as not to bother?
12700 All files on [2,MLM] produce DRYROT messages because of stupid mistakes
12800 (in fact these are stupid programs altogether, the product of my rather
12900 empirical method for learning SAIL; my apologies to your sensibilities)
13000 and are yours to play with and delete.
13100 ∂25-NOV-73 1426 network site CMU
13200 ***** FTP mail from [A702SA00] (ERMAN)
13300 SAIL SAILORS:
13400 Suggestions from CMU while you are freebing things:
13500
13600 .Add .FAI extensions to source file names -- most installations do
13700 not have FAIL as the default compiler but rather FOOTRAN.
13800
13900 .Make sure all the runtimes that the compiler calls are
14000 HEREd (e.g. POW and FPOW). It seems silly to have to make
14100 a new compiler just because some trivial change needs to
14200 be made to the runtimes.
14300
14400 .The DRYROT that "can't happen" in SYM at INCR3 can happen if
14500 it is at the top of core and no more room to expand -- the
14600 error msg should be made more informative thereof.
14700
14800 .CVSIX hacks on [], -- I know why, but can this be handled
14900 more cleanly. (In the very least, the manual should state that.)
15000
15100 .Error messages from the compiler should not use non-standard characters
15200 (such as left single quote) and should translate them (including underbar)
15300 to their standard ASCII equivalents. The current state is particularly
15400 messy on terminals that thing these characters are control characters
15500 for them.
15600
15700 .The ALLOC request doesn't accept lower case y.
15800
15900 .A missing runtime is CVR -- convert to real.
16000 Some helpful compile time functions would be:
16100 CURLINE -- current line number of the source file,
16200 CURFILE -- current source file name,
16300 CURDATE -- date of the compilation,
16400 CURTIME -- time of the compilation.
16500
16600 .REQUIRE MESSAGE should accept a compile-time string expression.
16700
16800 .Device I/O error message should print out the status bits of the channel.
16900
17000
17100 For the following things, we already have them in our code under
17200 a SACSW switch and SAC/NOSAC macros (they can be found in the appropriate
17300 files on A701SA00/CMUB); if you don't stick them in
17400 the general system, we will stick them in under our switch:
17500
17600 .A facility for trapping to a user's procedure on certain events --
17700 currently we have before and after a coreuuo and before and after
17800 string garbage collection. Obviously, it would be much nicer to
17900 integrate these into the new stuff you guys have.
18000
18100 .During a REENTER ALLOC, print out the current values when asking
18200 for new one.
18300
18400 .A here HERE location in the runtimes called DD.RET which contains
18500 a JRST @2,UUO0. Likewise, a msg is printed out when ones gets to
18600 DDT (by typing a D to the error msg handler) that one returns
18700 by typing "DD.RET$G".
18800
18900 .In the error UUO, type out a crlf before beginning the error msg.
19000 (Besides making things generally neater, this is essential on the
19100 ARDS if it is in vector mode.)
19200
19300 .Remove that idiocy when string space is exhausted that automatically
19400 restarts your program, thus making it impossible to rummage around
19500 (with ddt) and find out where all the string space went.
19600 (Of course, if the dynamic string space goes in, then this won't be
19700 necessary. Dynamic string space will make the facility to inform
19800 the user of garbage collections and space expansions even more important.)
19900
20000 .HERE on CORGET & friends.
20100
20200 .If running 2 segments, prevent the lower one from expanding past
20300 400000 -- only chao results.
20400
20500 .In SIMIO, make explicit check for doing buffered I/O with no buffers -- the
20600 DEC monitor is not as nice about error messages as yours.
20700
20800 .By turning on a funny bit in the left half of the argument when doing
20900 an OPEN, let him specify that nulls are not to be thrown away when
21000 doing ASCII input.
21100
21200 .Give error message in OPEN if invalid device name or device
21300 unavailable only if he asked for error msgs (in the EOF variable).
21400 For device unavailable, ask him if he wants to try again.
21500 In any case, make the error continuable, with the EOF variable
21600 set to TRUE..
21700
21800 .In the OPEN, use the DEVCHR uuo to determine if the device is
21900 a TTY, not just the name of the device (since one often does a
22000 logical assignment.
22100
22200 .GETSTS and SETSTS routines:
22300 STAT←GETSTS(CHNL); SETSTS(CHNL,BITS);
22400
22500 .An input mode (called K) that converts lowercase alphapetics (a-z only)
22600 into upper case. (We also have a mode called F that converts to lower
22700 case, but I don't think anyone has ever used it.) Likewise, an integer
22800 procedure called TTYUP(DOIT) that
22900 sets conversion of TTYUUO's to do similar conversion on input: if DOIT
23000 is true, then doit, else don't. It returns the old value of the state.
23100
23200 .When coming into ARRYOUT and WORDOUT, set the EOF variable to false.
23300
23400
23500 .A routine called INOUT(inchan,outchan,amount) that does direct
23600 i/o between the channels, thus saving a movement of the data. If
23700 amount is negative, then go til hit EOF. In all cases, set the EOF
23800 variables as if one were doing arryins/arryouts. (e.g., errors.)
23900
24000
24100 ∂25-NOV-73 1306 1,LDE
24200 By the way, the correction to my network mailing address never got made on
24300 the document that got distributed. It says I'm at CMU-10A -- should be
24400 CMU-10B.
24500 thanx,
24600 Lee
24700
24800 ∂25-NOV-73 0956 1,LDE
24900 I now have a tiny program that seems to poke the multiple string preload problem:
25000 see PREBAD.SAI[1,LDE] get an illegal uuo.
25100 Lee
25200 }
25300 ∂25-NOV-73 1528 1,KVL
25400 Everything seems to work properly in the new err stuff. I've tested
25500 the compiler version of logging, REQUIRE ERRMODES, <esc>I, and linkage
25600 to user procedures. The description of the new stuff is ERRORS.NEW[S,KVL].
25700 There is a bug in the compiler which I don't think is mine. The compiler
25800 always emits a 0 at S.+7. When this is changed to JFCL, everything runs
25900 fine. Seems to be independent of what's in the source.
26000
26100 I probably won't be around for awhile. Give me a call if any bugs develope.
26200 -Kurt
26300 ∂26-NOV-73 1739 S,JRL
26400 I found the difficulty with LES's program. He had a FORLC of the form
26500
26600 FORLC X = (A,B,C) DOC
26700 ⊂ mummbblee X mummmble ⊃ ENDC
26800
26900 where X had previously been defined as a macro name. Hanan did not turn
27000 off macro expansion as soon as the FORLC was scanned, but did turn it off
27100 while scanning the FORLC body, Thus if the macro X had been defined
27200
27300 DEFINE X = ⊂FOO⊃;
27400
27500 the FORLC was acting like:
27600
27700 FORLC FOO = (A,B,C) DOC
27800 ⊂ mummbblee X mummble ⊃ ENDC
27900
28000 I have not changed the compiler, but have sent a note to Hanan telling him about
28100 this problem.
28200
28300 jim
28400
28500 ∂26-NOV-73 0854 1,PJ AT TTY125 0854
28600 PRIMES.SAI[1,PJ] CAUSES IO TO UNASSIGNED CHANNEL AT USER 24001.
28700 I WOULD BE INTERESTED IN YOUR COMMENTS AS TO WHY.
28800 ∂27-NOV-73 1257 network site AI
28900
29000 - - - - - - - - - - - -
29100
29200 11/27/73 15:55:37
29300 From: PJ@MIT-AI
29400
29500 - - - - - - - - - - - -
00100
00200 WHAT IS JOBENB ALL ABOUT?
00300 ∂27-NOV-73 1816 1,LDE
00400 RUSS:
00500 THIS IS MARK AT CMU. WE ARE HAVING A LITTLE PROBLEM
00600 WITH FAIL. AS I TOLD FW IT LOOKS LIKE A PUSHJ CORINI SHOULD BE DONE
00700 AFTER THE RESET AT DOAT:. THIS SEEMS TO LET OUR CCL DO ITS THING.
00800 HOWEVER WHEN I ASSIGN DSK AS SYS THEN SAY COMP FILE.FAI I GET AN
00900 ILLEGAL UUO AT PC 7414. THE WORD IS THE TEMPCOR CALLI. WHEN LOOKING
01000 AT THE INFO PASSED TO THE CALLI I FOUND A BUFLEN OF 170 WHICH
01100 WITH THE JOBFF SEEMS TO EXCEED THE CORE THE JOB HAS ALLOCATED, IE.,
01200 THE JOB HAS 12K WHEN ONE DOES A CORE COMMAND YET THE ADDRESS OF THE
01300 LAST WORD OF THE BUFFER EXTENDS PAST THE 12K.
01400 ANOTHER FUNNY ITEM IS THAT WHEN ONE USES CCL FROM SYS THERE IS NO
01500 ERROR AND COMPILATION COMPLETES FINE, YET IF IASSIGN DSK
01600 AS SYS AND THEN RUN COMPIL FROM THERE I GET THE ILLEGAL UUO.
01700 AM I JUST IGNORANT OF THE FACTS OF FAIL OR IS THIS A BUG?
01800 COMMENTS WILL BE GREATLY APPRECIATED.
01900 MARK [A610MM42] PDP-10/B
02000 ∂28-NOV-73 0000 IMS,AIL
02100 THIS IS RLS. THE FIX IN SYM (FOR THE FORMFEED BUG)
02200 IS WHAT I DID ALSO. I WILL TRY TO CONFER ON
02300 OUR BUGS WHEN WE MERGE. ALSO I HAVE SOME FEATURE SUGGESTION.
02400 BOB SMITH
02500
02600 ∂28-NOV-73 2232 network site CASE
02700 -------
02800 Date: 29-NOV-73 0128-EST
02900 From: METZGER at CASE-10
03000 Re: SAIL ON [S,AIL]
03100 - - - -
03200 RUSS, IS THE SAIL ON [S,AIL] IN A STABLE STATE? I'D LIKE TO GET A
03300 COUPLE OF THE BUG FIXES AND SINCE SO MANY FILES ARE AFFTECTED I THOUGHT
03400 I'D FTP THE WHOLE WORKS IF THINGS ARE STABLE ENOUGH. WHOULD YOU BE
03500 INTERESTED IN THE ROUTINES TO DO SOME STRING COMPARES? MANY PEOPLE
03600 HERE FIND THE EQU ISN'T ENOUGH SO WE WROTE THINGS TO DO
03700 LSS("ABC","DEF"), GTR LEQ AND GEQ. WITHOUT SUCH ROUTINES IT'S A LOT
03800 HARDER TO WRITE SORTING ALGORITMS. I FEEL THAT THE CURRENT MEANING TO
03900 STRING A < STRING B DOESN'T HAVE MUCH USE AND THAT IT WOULD BE NICE
04000 IF <,> ETC. WOULD USE THE WHOLE STRING WHEN DOING A COMPARE.
04100 ALSO WOULD IT BE POSSIBLE TO TO PUT THE "END OF SAIL EXECUTION"
04200 UNDER A CONDITIONAL ASSEMBLY SWITCH AS MANY PEOPLE HERE USE SAIL TO
04300 WRITE SYSTEM TYPE PROGRAMS AND DON'T WANT SUCH MESSAGES. IN GENERAL
04400 THEY DON'T WANT ANY SAIL MESSAGES (PARTICULARLY THE SAIL ERROR MESSAGES
04500 THAT ASK THE USER TO CONTINE, EXIT OR WHAT EVER AS THESE TEND TO
04600 CONFUSE NON-SAIL PROGRAMMERS, BUT THIS IS A MORE GLOBAL ISSUE OF THE
04700 ERROR TRAPPING AND RECOVERY PROBLEM THAT KVL IS WORKING ON).
04800 HOW IS THE TENEX SAIL GOING? I HAVEN'T BEEN ABLE TO CONTACT BOB SMITH
04900 IN A WHILE. DID HE GET THE CONTRACT SETTLED YET? PROBABLY THE BEST WAY
05000 TO ANSER THIS IS TO LOG IN HERE AND USE OUR SNDMSG (UNLESS YOUR MAIL
05100 PROGRAM CAN SEND TO NET SITES EASILY). THE PASSWORD TO SAIL-TAYLOR IS
05200 STILL THE SAME AS YOUR BOAT'S NAME.
05300 JOHN METZGER
05400 METZGER@CASE-10
05500 -------
05600 ∂30-NOV-73 1402 network site CASE
05700 -------
05800 Date: 30-NOV-73 1702-EST
05900 From: METZGER at CASE-10
06000 Re: GOT YOUR MESSAGE
06100 - - - -
06200 THNKS FOR THE INFO. WILL TRY TO FTP NEW SOURCES WED OR THURS.
06300 I'LL PUT THE STRING ROUTINES (LSS, GEQ ETC) ON <SAIL-TAYLOR>
06400 SO YOU MAY LOOK AT THEM AT WHEN YOU GET TIME. FEEL FREE TO GRAB
06500 ANY FILES YOU WANT FROM OUR SYSTEM (IF WE DON'T WANT SOMETHING
06600 TO GET OUT WE HAVE IT PROTECTED, SO ANYTHING THAT'S UNPROTECTED IS
06700 FAIR GAME). THE STRING ROUTINES ARE IN A FILE CALLED COMPAR.
06800 AL ROSENFELD WILL BE AT NIC, PARC AND ISI ABOUT THE FIRST WEEK OF
06900 JAN. AND WILL PROBABLY STOP AT SU-AI. I'M NOT SURE IF I'LL BE WITH HIM
07000 AT THIS TIME. AS WORK IS PROGRESSING ON THE NEW LEAP SYSTEM WE'D LIKE
07100 TO GET TOGETHER WITH YOU AND JIM LOW, TO FIND SOME OF THE REAL NASTY
07200 PROBLEMS IN LEAP AND TO HAVE YOU HELP EXPLAIN HOW THE CODE GENERATORS
07300 ARE ALL PUT TOGETHER. WILL YOU OR JIM BE WILLING TO DO THIS (FOR ABOUT
07400 A WEEK SOMETIME IN JAN)? CONSULTING FEES MAY BE ARRANGED, I'LL HAVE TO
07500 TALK TO PEOPLE HERE TO FIND YOU EXACTLY WHAT WOULD BE ACCEPTABLE.
07600 THE BASIC PROBLEM IS CONVERTING ALL THE CODE GENERATORS TO BELIVE
07700 ITEMS ARE 27 BITS WIDE INSTEAD OF JUST 18. ALSO DATUMS HAVE TO BE
07800 PAGED. WE HAVE IDEAS HOW TO DO THIS, JUST THAT THE INTERNALS
07900 OF THE CODE GENERATORS IS NON TRIVAL, THE SMALLEST CHANGE SEEMS TO
08000 CAUSE A GREAT DEAL OF HAVOC AND WOULD LIKE YOUR EXPERT HELP WITH
08100 THIS STUFF. JIM CALVIN HAS JUST RECENTLY ASDDED SOME CODE TO TOTAL
08200 AND FRIENDS TO GENERATE A MACHINE LANG. LISTING SIMILAR TO FORTRAN'S
08300 M OPTION, ANYONE INTERESTED IN SUCH A THING. WE WANT IT TO HELP
08400 WITH DEBUGGING NEW CODE GENERATORS. THANKS AGAIN. NO HURRY ON A RESPONSE
08500 I WON'T BE BACK TILL NEXT TUESDAY.
08600 JOHN METZGER
08700 METZGER@CASE-10
08800 -------
08900
09000 ∂30-NOV-73 0949 network site CMU
09100 ***** FTP mail from [A700SA00] (SAIL)
09200 Russ,
09300 Just to confuse you, I think we will bring up the new Sail
09400 on A700SA00, and leave the old stuff on A702SA00. In preparation
09500 for this, I have moved SAIL.LOG to A700.
09600 Sorry, again.
09700 Lee
09800
09900
10000 ∂04-DEC-73 1011 1,DCS
10100 Unfortunately, your fix will not work. It will cause block name
10200 mismatches, in fact, if you're not lucky -- and other things too.
10300
10400 The problem is that unless you copy the zeroes accompanying the end
10500 of identifiers down to new locations when you move the identifiers, what
10600 is left after some new identifiers will be non-zero characters
10700 from previous strings. Since the scanner compares full words,
10800 things will no longer match. In addition, if the last string
10900 is a complete identifier, unless topbyte lines up, there's no guarantee
11000 that it will face a zeroed set of characters -- this sentence
11100 doesn't make much sense.
11200
11300 Anyhow, best is for programs which set SGLIGN to assume that
11400 topbyte will be aligned after GC. If it should not be (should point
11500 to first char after partial ID, for example), the program
11600 should re-create TOPBYTE using SUBSTR, and the known partial
11700 length and starting ID byte ponter. I now recall special hair
11800 in the GC to make sure TOPBYTE lined up just
11900 past the last char of the last string moved. It was
12000 a true, losing kludge. I will be happy to try to get SYM fixed
12100 to do what I suggested above, but am not sure how soon I can do
12200 it what with vball and no sleep and all. You could help
12300 by listing the STRNGC portion of GOGOL and all of SYM, I guess.
12400
12500 Let me know if either you think I'm wrong, or there's something else.
12600 Also call me at work to discuss this, etc. -- try several times,
12700 since there's no paging.
12800 Dan
12900 ∂05-DEC-73 1130 1,PDQ AT TTY26 1130
13000 HEY, ZERO DIVIDE BIT IS NOT GETTING CLEARED IN NEW
13100 OVERFLOW CODE. THE MOVSI 440100 AT TRIGIN+37 SHOULD BE
13200 MOVSI 440140.
13300 ∂06-DEC-73 0847 GUN,KKP AT TTY74 0847
13400 The current global segment still has the bug in the PTY code. We need
13500 this fixed if I am going to get the hand/eye monitor running again.
13600 ∂06-DEC-73 0954 1,DCS
13700 Russ,
13800 Subtle bug (which I actually encountered!):
13900
14000 Consider, if you will,
14100 USERCON(UUO1,SAVERET,0); and its corresponding
14200 USERCON(UUO1,SAVERET,1); !!
14300 The effects are lovely and mysterious. Try to predict
14400 them without writing any programs. This is one nice
14500 mutation.
14600 DCS
14700
14800 ∂6-DEC-73 1914 network site CASE
14900 -------
15000 Date: 6-DEC-73 2034-EST
15100 From: METZGER at CASE-10
15200 Re: ANNOUN
15300 - - - -
15400 GOT YOUR MESSAGE OK. WHY WAS IT SENT FROM BBN? I ASSUME THAT SINCE
15500 IT CAME FROM BBN YOU KNOW THAT GOODWIN AND CREW HAVE FINISHED UP
15600 THERE WORK ON BBN'S VERSION OF TENEX SAIL. NOT MUCH WAS DONE.
15700 JUST UUO'S OUT OF COMILER AND RUNTIMES, AND NEW COMMAND SCANNER
15800 THAT TAKES TENEX NAMES (AND FILE COMPLETION) ALSO TENEX FILE
15900 NAMES IN REQURIES (REQUIRE <SAIL>NAME.EXT INSTEAD OF NAME.EXT[X,Y])
16000 ALSO COMPAR.FAI (THE SAIL STRING THING TO DO LSS(A,B) ETC.) IS ON
16100 <SAIL-TAYLOR> IF YOUR INTERESTED. JPM
16200 -------
16300
16400 ∂6-DEC-73 2339 network site CASE
16500 -------
16600 Date: 7-DEC-73 0240-EST
16700 From: METZGER at CASE-10
16800 Re: [X,AIL]
16900 - - - -
17000 I'D BE GLAD TO GIVE YOU ANY HELP YOU WOULD NEED ROM ME TO
17100 SET UP X,AIL. IF NONE IS REQUIRED, THEN I'LL FTP THE FILES FROM
17200 X,AIL EARLY MONDAY MORNING (UNLESS I HEAR FROM YOU THAT I SHOULD
17300 WAIT) AND WILL TRY TO GET UP A STRAIGHT EXPO SYSTEM, THEN PUT IN
17400 OUR PATCHES, WHICH FOR RIGHT NOW ARE:
17500 REMOVE "END OF SAIL EXECUTION" MESSAGE
17600 ADD OUR LOCAL RUNTIMES (CHANGES TO FOO2 AND ORDER ONE EXTRA FILE
17700 CALLED CASE10 WITH ALL THE CODE)
17800 FIX MINOR EXPO BUGS LIKE LOADVR←←52 IN FILE SAIL (NOT UNDER STANSW
17900 OR NO EXPO)
18000 FIX SCISS TO START FAIL IN INFERIOR FORK. (MINOR CHANGE)
18100 DON'T HESITATE TO LET ME KNOW IF THERE IS ANY THING I CAN DO TO HELP.
18200 JPM
18300 -------
18400 ∂8-DEC-73 1535 network site MAXC
18500 -------
18600 Date: 8-DEC-73 1537
18700 From: SPROULL at PARC-MAXC
18800 Re: The usual
18900 - - - -
19000 You'll never believe it, but there are no bugs in
19100 the glorious interrupt handler (that is, i found an overflow
19200 with a jfcl following it that did the right thing!). So
19300 I am farily confident that it is ok. Furthermore, Gary Knott
19400 will surely test EVERY possible combination of conditions before
19500 he "accepts" the new system.
19600
19700 I did discover one small thing. We put in the entry DD.RET for
19800 Lee Erman so that you could return from DDT after typing D to
19900 an error message. It is a HERE'd symbol, in the error handler
20000 area. However, I forgot to make in INTERNAL when putting out
20100 a library (another minor change the the COMPIL macro for
20200 SAILUP).
20300
20400 My tapes, they spin slowly.
20500 -------
20600 ∂09-DEC-73 1635 S,LES
20700 Dan,
20800 Here is an elaborated version of SAVE_IT that gets around a couple of
20900 problems. In order to avoid having to give a Core argument to SSAV,
21000 the left half of JOBSA is set to JOBREL.
21100 LES
21200
21300 PROCEDURE SAVE_IT; BEGIN
21400 COMMENT If you are doing no I/O, you may call this procedure. It
21500 saves the accumulators, sets up a new starting address, and exits.
21600 If you then say "SSAV <file>" (or "SAVE ..." if you have no segment)
21700 then subquently RUN <file>, it will start at the point where this
21800 procedure was called, thus preserving all strings, items, etc.,
21900 that would be cleared in a normal start. Note that you cannot
22000 subsequently give ↑C and start the program again, since SAIL's
22100 storage allocation would become hopelessly confused. To inhibit
22200 this, any such attempt draws an error message. ;
22300 SIMPLE PROCEDURE BOMB; BEGIN
22400 OUTSTR("
22500 Sorry, you can't restart this program. Please get a new copy.
22600 ");
22700 CALL(0,"EXIT");
22800 END;
22900 START_CODE
23000 SAFE OWN INTEGER ARRAY SAVACS[0:'17];
23100 EXTERNAL INTEGER JOBSA,JOBREL;
23200 LABEL RESTART,RERESTART;
23300 MOVE JOBSA;
23400 HRRI RERESTART;
23500 PUSH '17,0;
23600 MOVEM '17,SAVACS['17];
23700 MOVEI '17,SAVACS[0];
23800 BLT '17,SAVACS['16];
23900 HRL JOBREL;
24000 HRRI RESTART;
24100 MOVEM JOBSA;
24200 CALLI 0,'12;
24300
24400 RERESTART: PUSHJ '17,BOMB;
24500 RESTART:
24600 MOVSI '17,SAVACS[0];
24700 BLT '17,'17;
24800 POP '17,JOBSA;
24900 CALLI 0,0;
25000 END
25100 END "SAVE_IT";
25200 ∂11-DEC-73 1814 network site MAXC
25300 -------
25400 Date: 11-DEC-73 1815
25500 From: SPROULL at PARC-MAXC
25600 Re: Sproull in Washington
25700 cc: JRL at SU-AI, SWINEHART
25800 - - - -
25900 Throught the magic of the ntwork, I come forware to hassle you
26000 in your peace. Basically, I was able to read my tapes, and
26100 everything works. However, I have found two bugs, one of
26200 which is serious:
26300
26400 1. (not serious( JRL>s bug fix PP to check for hiseg arrays
26500 going 'before' the origina of the rel file fails to check
26600 the OWN bit before entering the bug check. There fore,
26700 I reccommend something along the lines of
26800 Tnn tbits,own
26900 jrst .+6
27000 in ARRAY, just at the beginning of the PP patch.
27100
27200 2. (serious) God damn you Russ talyor, that piece of my
27300 accumulator-saving code that you 'optimized' because you
27400 couldn't keep your fucking fingers off the code, you broke.
27500 When restoring ac's after the call on the error handler
27600 proc, there is a HRLZI ff,d-15(p) that is wrong, it should
27700 be HRLZI ff,dxxxxxx scratch that it is now hrlzi ff,15-d(p),
27800 and should be hrlzi ff,d+1-15(p). This really fucks
27900 up the compiler whenever an error message is ussued,
28000 clobbering PNT, TBITS, and the like. You should be
28100 ashamed.
28200
28300 More news later, pehrhaps. But for now, all is well.
28400 MLAB runs (wihtout error handler yet), even in a HISEG
28500 version!!!! See ya.
28600
00100 -------
00200
00300 ∂11-DEC-73 1648 ACT,REG
00400 THE CRETINOUS MANUAL LIES ABOUT THE COMPILER BEING SMART ENOUGH TO GENERATE
00500 AN ASH FOR DIVISION BY A POWER OF 2! [24L]
00600 AND WHATEVER ASSHOLE PROGRAMMED IT DIDN'T REALIZE THAT IDIV DOESN'T GIVE
00700 THE SAME RESULT AS AN ASH. E.G., '777770000017 DIV '100000 = -7, NOT
00800 THE -'10 I'D HAVE GOTTEN FROM AN ASH!
00900 ∂12-DEC-73 0658 1,RFS
01000 R
01100 Russ -- I hate to pick nits, but the addition you made to LOG
01200 to explain the fix for the bug in GOGOL is NOT correct. First,
01300 the HRLZI has a (p) in it, second the From and To forms you gave
01400 are not right:
01500 was: HRLZI FF,15-d(P)
01600 s/b: HRLZI FF,D+1-15(P)
01700 Note that one of the most importnat parts of the fix is that
01800 the old ac's are UP the stack (i.e. the thing should be -mumble(P),
01900 not +mumble as it was).
02000 ∂12-DEC-73 1626 network site MAXC
02100 -------
02200 Date: 12-DEC-73 1501
02300 From: SPROULL at PARC-MAXC
02400 Re: Another bug
02500 cc: SWINEHART, JRL at SU-AI
02600 - - - -
02700 Here is your happy bug finder at work.
02800
02900 The XX variables on page 9 of gogol have a problem (actually 2):
03000 There is some stuff conditionally assembled with the LOW switch
03100 near the end of the page; needless to say, this screws the XX
03200 assignments for the high segments, because the low segment will
03300 have three more cells in there for the LEAP initialization block.
03400 Fix is to move the LOW stuff to the end of the page, after the last
03500 XX.
03600
03700 The other problem, which does not actually make a bug, but which is
03800 wrong, is that the XX for APRACS (GOGOL/9) does not have its fourth
03900 argument filled in; it shuld of course be 20. Thought you all
04000 might like to fix that.
04100
04200 The first thing shouuld indeed bee fixed.
04300
04400 That's all for now.
04500 -------
04600
04700
04800 ∂14-DEC-73 0003 ACT,REG
04900 I SUGGEST THAT SAIL BE MODIFIED TO DO A DSKTIM UUO AND A RENAME ON THE
05000 REL FILE AFTER DOING THE CLOSE TO GIVE THE REL FILE THE LATEST POSSIBLE
05100 CREATION DATE. THIS WILL HELP PREVENT RPG FROM DOING EXTRA COMPILATIONS.
05200
05300 ∂13-DEC-73 2224 1,DCS
05400 MACRO bug dix (discovered at CMU) (fix for dix) reported in mail to AIL.
05500 Pls. don't remove it without recording it in detail in one of
05600 the places where things like this belong (changes, etc.)
05700 CC: rht;hjs;kvl;jrl
05800
05900 ∂13-DEC-73 2222 1,RFS
06000 Russ, please read bugs.rfs[1,rfs]
06100 rfs
06200
06300 ∂13-DEC-73 2223 1,DCS
06400 Well, might as well try out the bug reporting method.
06500
06600 The code at DEFCHK and beyond in sym has been the most consistent
06700 source of bugs ever. Now there is another bug. It didn't used to be
06800 that STRNGC (via SGCOL) could be called at RANSC1+3, by the nature of
06900 tests ahead of time that assured enough REMCHRs. But now, there's a
07000 test in RESTOR, coming out of macro actuals, to see if there's enough
07100 room for the rest of the macro, and that can cause GC to happen.
07200 Anyhow, in the DEFCHK code there's a kludge whereby one string is
07300 made to look one character too long, to protect a pointer to the
07400 succeeding byte. It seems I do this a tad too early, because what
07500 happens is the STRNGC after RANSC1 happens, and TOPBYTE ends up being
07600 kicked up one character, so that a null ends up in the macro string,
07700 then some other things happen, and the null stays, but the character
07800 following the null gets wiped out by the '177/0 thing, or someting
07900 like that. Now, at SEEPRM and following, the one extra char. kludge
08000 is ok, becuase it does protect a random pointer over gc, and later
08100 TOPBYTE gets restored from saved values anyhow. I include all this
08200 in hopes you will just ignore it and install the fix, with some
08300 innocuous comment. It is actually easier by far to understand than to
08400 explain. The fix goes:
08500
08600 Delete the line, at DEFCHK+6 or so, which says:
08700 ADDI C,1 ;TO CARRY XTRA CHAR THROUGH FURTHER STEPS
08800
08900 Replace the instructions at SEEPRM:
09000 HRRM <-> SUBI <-> PUSH <-> PUSH <-> PUSH with:
09100
09200 SEEPRM: PUSH P,A ;Save bits,
09300 PUSH P,B ; character, and current total
09400 PUSH P,C ; macro body string count.
09500 ADDI C,1 ;Make PNAME look one longer to protect
09600 HRRM C,PNAME ; end pointer over GC.
09700
09800 finally, change 5 to 4 in COLNEC-1.
09900
10000 I have not made this change in any files anywhere. Thought I'd try
10100 expo bug reporting scheme. Oddly, this same fix was necessary for me
10200 to compile FILE, which I was asked to recompile here, just as I came
10300 here last eve. to report bug. Truly surprised that any macros have
10400 worked recently (since at least last July).
10500
10600 HJS may want to check this over before it is installed. But
10700 something has to happen, and I hope this is it.
10800
10900 Have fun. DCS
11000
∂03-JAN-74 1340 S,KVL
MERGING: FEATS,HEAD,GOGOL,STRSER from AIL,DCS to S,AIL. There will
exist GOGOL.OL, HEAD.OL , and STRSER.OL. Also adding a new switch under
STANFO called BAISW for future Bail stuff. No uses of this switch in
S,AIL files yet.
∂03-JAN-74 1129 S,KVL
Hi Russ,
Something appears to be wrong with feature %AY% -- <esc> I in the compiler
isn't working (e.g. we couldn't generate a scanner break in SAILDD). -kvl
CC:JRL
∂30-DEC-73 1723 1,DCS
I fixed LDE's CAT/STRNGC bug. It is BUG QE, entered in BUGS
on [S,AIL]. The fix is in STRSER[AIL<DCS] because I couldn't
run TV from home (will need /V to install). I got it 12-30-73 at 1730,
so SRCCOM if you need to. Bug QF is a similar, but not-yet encountered
bug in compiler.
My adornments of HEAD and GOGOL and FEATS still exist only on [AIL,DCS].
Decoration only, no code changes. I am afraid if they do not get put on
[S,AIL] etc. soon they may be harder to install.
I'll send LDE the patch to CAT, and have him try it.
∂29-DEC-73 1222 network site CMU
***** FTP mail from [A700SA00] (SAIL)
This is being sent to DCS as well as the SAIL types at STANFO,
(because of his abiding interest in this particular bug) --
I assume that your synchronization procedures are sufficient
to keep it from being fixed twice.
We have found a bug caused by the interaction of the new
string garbage collector with the CAT routine:
When the STRGC gets called at ONLY1+5, if the collector has added
a new block, then topbyte(user) points to the new one, but the
first string is still in the old block. This causes the second
string to get CATed onto the wrong thing, leaving garbage at the
end of the now longer first string.
I'm not sure what the correct thing to do is at this point --
maybe at ONLY1, if a collection is necessary, it should then
assume that two strings have to move, ask for enuff space,
then clean up the world and go someplace to move both of them.
If someone does come up with a fix, I would appreciate if we
can be notified of it as soon as possible, because our current
fix is to pretend that string space is only 1 block long and
ask for all we need. A pointer to the bug fix number is
sufficient notification.
I hope that there are not other places that call the garb col
that assume that what used to be at the top of string space
will still be there after calling the col?!!!!!!
Thanks for the help.
Lee (ERMAN@CMU-10B)
∂06-JAN-74 1812 S,KVL
I've stowed a couple pages of code need to output symbols for BAIL in
GEN and SAIL on S,AIL. It all works nicely, but that shouldn't matter
since it's all under the switch BAIL, which is turned off. See you
again toward the end of the quarter. (c.f. %BC%)
--KVL
∂8-JAN-74 1125 network site CMU
***** FTP mail from [A610HS11] (HEARSAY-2)
RUSS
I HAVE FTP'D OUR TEST PROGRAM FOR THE NEXT BUG INTO [CMU,AIL]. AS WE
FIGURE IT, THE OUTPUT SHOULD BE SOMETHING LIKE BEFORE:1 AFTER:2 BEFORE:3 4,
WHICH IT IS NOT. THE FILE IS NXTTST.SAI. LET ME KNOW IF ANYTHING COMES
OF IT.
PADDY