∂25-FEB-74  0925		1,RFS
 Russ --
 
 Leo Guibas and I have just spent a little time tracking down
 a problem with SAIL.  Apparently, when it compiels code
 for FORTRAN function calls, the ac's are not dumped
 (i.e. SAIL assumes that the FORTRAN function saves
 all used AC's).  This is observed to not be the case in several
 functions we have here.  Is this the way the
 rest of the world works too??
 
 No pressing need, just mentioning a slight annoyance.
 		Cheers
∂22-FEB-74  1035		network site CMU
 Poke from CMU re two bugs that were reported and seemingly ignored:
 (LDE 22-Feb-74)
 
 =A1=
   This is the fact that once a break table is put into "K" (convert
 to upper case) mode, there is no way to reset it.  The fix is simple
 enuff:
   Add a new mode, "F" (Full character-set mode), which is the
 "default" and add the following three lines of code needed:
 
 [IOSER/25]
 1)  change  	XWD NOLINS,ILLSET	;n,,-
     to		XWD NOLINS,LCASE	;n,,f
 
 2)  add at the bottom of the page (following UCASE code):
 	LCASE:	MOVSS  B
 		ANDCAM B,BRKCVT(USER)
 		JRST  RESTR
 
 
 
 =A7=
 	At SGSORT, it is not(!) checking for null strings, thank you.
 It  used to  before DCS  put in dynamic  string space.  Some run time
 routines do create null strings  that are not marked as constants and
 which do not have legal addresses.  (In particular, Realscan seems to
 do this.) In addition, the old manual used to state that if the count
 is zero, then the address is ignored. In any case, something needs to
 be done to this.
 
∂20-FEB-74  0744		network site CMU
 CMU bug report: =A9= LDE 20-Feb-74.  Compiler string stuff still ill.
 	Compiler still sensitive to amount of string space.  Now
 	have a single-file program that exhibits it, both at CMU &
 	Stanford.  BUG2.SAI[CMU,AIL]&[A700SA00] blow up with undeclared
 	id on line 31450/2 with the "standard" string allocation; with
 	more space it goes on (and eventually gets an error which
 	doesn't concern us here, I think).
 
 
∂5-FEB-74  1026		network site CMU
 CMU bug report =A7=  horrible bug in SGSORT:  
 =A7=	[GOGOL/48]	LE03 5-Feb-74
 	At SGSORT, it is not(!) checking for null strings, thank you.
 	It used to before DCS put in dynamic string space.  I have
 	put in a fix, but Stanford may change it?
 	BUG.SAI [CMU,AIL] or [A700SA00] poke at it -- just
 	respond with a CR or 1 character and CR.
 
∂5-FEB-74  0916		network site CMU
 To:	Sail types
 From:	LDE
 
 Apparently #QV (not being able to use string args in an apply) was
 fixed.  However, there is no notation in BUGS to that effect.  The
 fix seems to have included SYM (which was not mentioned in the
 original BUGS entry either).
 		Thanx,	Lee
 

COMMENT ⊗   VALID 00016 PAGES 
RECORD PAGE   DESCRIPTION
 00001 00001
 00003 00002	17-NOV-72  1742		G,MJC
 00008 00003	04-JAN-73  0959		MA,JAM
 00012 00004	05-MAR-73  1151		2,TES
 00014 00005	∂15-MAY-73  0648		GEM,TVR
 00017 00006	∂20-AUG-73  1557		MA,JAM
 00022 00007	∂19-OCT-73  1450		2,MLM AT TTY110 
 00031 00008	∂25-NOV-73  0956		1,LDE
 00034 00009	 
 00042 00010	∂04-DEC-73  1011		1,DCS
 00047 00011	∂6-DEC-73  2339		network site CASE
 00055 00012	∂11-DEC-73  1648		ACT,REG
 00058 00013	∂14-DEC-73  0003		ACT,REG
 00069 00014	To the SAIL hackers--
 00088 00015
 00089 00016	∂04-FEB-74  1748		1,BH
 00090 ENDMK
⊗;
17-NOV-72  1742		G,MJC
A program which I wrote to try to learn a few things (namely SAIL and the
Quam display routines) uncovered a "DRYROT" error.  The program is 
TRY.SAI[G,MJC], and the error occurred in line 2600.  Any suggestions?
					Mike Clancy

JAM again. Sorry, it doesn't go away with
an "IF TRUE THEN", only with an "IF FOO THEN"


I fixed up the file of this morning's message (but still have a listing
in case you want to see it) but it still "DRYROTS".  The file is
TRY.SAI[G,MJC].  Is there something special I should know about for-stmts?
					Mike Clancy
19-NOV-72  0831		1,EMC
HELP!
DON'T PUT UP THE NEW SAIL.
TWO DEMOS ON MONDAY.  THIS WOULD
BE THE 4TH DEMO IN SUCCESSION IMMED
AFTER A SAIL CHANGE.
TOB

20-NOV-72  0341		SLS,DCS
I RAN INTO PROBLEMS WHEN USING THE SAIL DPB COMMAND.
THE CODE GENERATED FOR THE INSTRUCTION
	DPB(A,POINT(11,BUFX[POINTER],10))
	SEEMED TO LOAD A INTO REGESTER 10 AND PROMPTLY DEPOSIT REG 11.
THE PROGRAM IS TEST.SAI ON [1,EMC], AND THE OFFENDING LINE IS IN THE
AIVCT1 PROCEDURE FOUND ON PAGE 4, I BELIEVE.

22-NOV-72  2341		MA,JAM
Dear Ail,
  CASE n OF (ITV, ITV, ... ITV) generates, in at least one case

	<case check>
	JRST	@TABLE(IDX)
	PUSH	P,ITV
	JRST	DONE
	...
	PUSH	P,ITV
	JRST	DONE
TABLE:	.-...
	.-...
	...
	TABLE-2
DONE:	POP	P,TBITS2
	MOVE	A,0			;!!!!!!!!!!!
	....
 This is fairly recent (MOVE s/b MOVE A,TBITS2 or whatever).

DCS

22-NOV-72  2344		MA,JAM
JAM here bringing to you yet another
insidious SAIL bug. There is a program
BUG.SAI[MA,JAM] which compiles the following
code incorrectly (see page 6 of source file):

	BEGIN "FLTO"
	    REAL ARRAY Y[1:LN+GWIDTH];
	    *** LOTS OF STUFF ***
	END "FLTO";
	BEGIN "DPGT"
	    INTEGER ARRAY BUF[1:5500];
	    *** MORE STUFF ***
	END "DPGT";

The following code appears:

DPGT&DPGT.-6/	PUSHJ P,BEXIT
DPGT&DPGT.-5/	PUSH P,3	; LOWER ARRAY BOUND???
DPGT&DPGT.-4/	PUSH P,[=5500]	; THIS IS OK
DPGT&DPGT.-3/	PUSH P,3	; IT SEEMS TO THINK AC3 CONTAINS A 1
DPGT&DPGT.-2/	PUSHJ P,ARRMAK

This, of course, gets a "UPPER BOUND<LOWER BOUND" error
message, for constant bounds yet! Anyway, the problem
goes away if you put an "IF TRUE THEN" in front of
the BEGIN "DPGT". Is that enough?

16-DEC-72  1444		S,JRL
THE 7-LINE PROGRAM BUG.SAI[1,REM] COMPILES INCORRECTLY BY SAIL.
JNAM←CVSIX("[LXGP]"); COMPILES AS MOVSI NIC,0;MOVEM NIC,JNAM;

06-JAN-73  1737		1,REM
Is my observation correct? I have a block full of
CONTINUEs, and I find that the first one jumps to
the second, the second jumps to the third, and so
on to the last one!!???


06-DEC-72  2219		SLS,DCS
NASTY BUG IN SAIL SETBREAK(TABLE,STRDELIM,STRDELETE,SWITCHES);
IF YOU DO A SETBREAK WITH CHARACTERS TO BE DELETED,
THEN LATER IN THE PROGRAM YOU DO ANOTHER SETBREAK ON THE SAME TABLE NUMBER
WITH NULL STRDELETE, IT CONTINUES TO USE THE OLD STRDELETE!!!!

07-DEC-72  1419		H,HJS
K PINGLE FOUND A BUG HAVING TO DO WITH AN ILLEGIT. ARRAY NAME IN AN
ARERR UUO FOR COMPLICATED EXPRS.  SERIOUS ENOUGH TO FIX.  SEE BUG #KR.
DCS

04-JAN-73  0959		MA,JAM
The SAIL error: BEGIN AND END DO NOT MATCH
could be more helpful in telling which are
the BEGIN block names.

19-DEC-72  1609		WRU,TOB
JAM here. I have a SAIL program that I said ↑C - SAVE
to. The dump copy is SAVBUG.DMP[MA,JAM]. If you RUN it,
it generally says "ERROR IN JOB 26, PC EXCEEDS MEM BOUND
AT USER 400013", indicating to me that the second segment
isn't hooked up. If you GET it and START it, sometimes it
works and sometimes not. This doesn't seem to happen if I
SAVE the program before it is ever run for the first time.
If I start it up, then stop it and save it, this often
happens.
	Please delete the file SAVBUG.DMP[MA,JAM] when
you are finished with it.

18-DEC-72  1151		MA,JAM
export version of sail should not have dump never bit on in
rel files created. fancyy technique for writing over ddt doesn't seem
to work with export.
                  jim low

14-JAN-73  1824		1,REM
YOU OUGHT TO FIX SAIL SO YOU CAN SPECIFY ODD FILE NAMES, LIKE [-AP-].DMP
IN AN ENTER.  PERHAPS, ADOPT THE COPY CONVENTION ABOUT ↓ TO SURROUND A
QUOTED NAME.

01-FEB-73  1236		TAP,REG
There is a deeper bug but you can cure your immediate problem by parenthesizing
the expression TK([A⊗O≡V]) in your macro IV. Syntactically the parens are
required since a boolean expression inside a foreach associative context musht
be parenthesized.
	jim

06-FEB-73  1126		S,JRL
	IT USED TO BE THAT INCHWL WAS ONLY TERMINATED BY <CRLF> NOT
BY <ALT> OR <LF> OR BARE <CR> OR ANY OTHER ACTIVATION CHARACTER.
A FEW MONTHS AGO INCHWL BEGAN TO BE TERMINATED BY THE OTHER ACTIVATION
CHARACTERS AS WELL.  THIS LASTED FOR ABOUT A MONTH, THEN RETURNED TO
THE <CRLF> ONLY METHOD.  NOW TONITE I FIND THAT INCHWL IS AGAIN TERMINATED
BY ANY ACTIVATION CHARACTERS.  WHY DOES IT KEEP CHANGING???

06-FEB-73  0124		1,REM
The next person to make a new compiler might have some KVL typos to contend
with (Gen pg 51,52,53 and Hel pg 15) due to implementation of ACCESS.  The
slow system prevents me from making a compiler myself today.
			-peace and love - KVL

06-MAR-73  1430		1,KVL
BOTH OLD AND NEW PUB USE SAISG5 VERSION; BUT THE NEW CORE IMAGE IS
3K BIGGER THAN IT USED TO BE 7 WEEKS AGO.  ANY IDEA WHY?  I ONLY
ADDED A LINE OR TWO OF CODE. (COMPARE PUB2.DMP AND PUB2.OLD
ON [1,3]).
--- LARRY TESLER

05-MAR-73  1151		2,TES
Russ: We need to fix the realin (intin) and any associated code

to handle overflow conditions by having a JFCL immediately following
any instruction which can cause an overflow.  In particular, realin
with a large integer part followed by a large number of fraction part
zerowill cause an overflow.



14-MAR-73  2024		1,PDQ
RUSS: I GOT A "DRYROT AT EFORM" MESSAGE WHEN TRYING TO COMPILE
FILE AESTH.SAI[A,JEG]. DAN SAID IT WAS A COMPILER ERROR AND THAT
YOU ARE THE PERSON TO SEE. SUGGESTIONS? THANKS. 
				   - JIM

07-APR-73  1850		A,JEG
 
∂15-MAY-73  0329		2,TES
 The new version of SAIL will not compile PUB.
 See PPSAV.PUB[2,TES].  I tried twice.
 Larry
 
 
∂15-MAY-73  0202		SLS,DCS
 Larry Tesler couldn't get PUB up with new segment, so I
 managed to get one running with SAISG5.513, SSAVED it
 and changed named of segment to SAISGN -- put it on the
 system.  The old dmp is PUB.DMP[
 (sorry) PUB.DMP[SLS,DCS] if you want to try again, else
 please delete it.  Larry will probably follow advice and
 put it up with the library, at least for a while, soon.
 Dan
 
 

∂15-MAY-73  0648		GEM,TVR
 Thank you for the pleasure of reloading my program because of change to SAISG5!
 
∂04-JUN-73  1245		SLS,DCS AT TTY62 
 Sorry -- wasn't careful enuf in my examination of the problem.  SGLIGN
 is MISSING from HLBSA5, tho PRESENT in LIBSA5!!!!  What a strange
 situation.  I refrained from inserting it, so you could study the
 anomaly in situ if you wished.
   Dan
 
∂04-JUN-73  1025		LDE,DCS
 IS THERE ANY GOOD REASON THAT POW & FPOW ARE NOT MADE "HERE"??  SINCE THE
 COMPILER CALLS THEM DIRECTLY, SOMETIMES, ANYTIME A NEW SEGMENT IS MADE, A
 NEW COMPILER MUST ALSO NEEDS BE MADE.
 		LEE ERMAN
 
∂03-JUN-73  1105		SLS,DCS
 There are no HEAD syms on either library.  Weiss du das?
 
∂13-JUN-73  0204		1,MSW
  HELLO I AM ONE OF JEENA'S COLLEAGUES. IHAVE A SMALLPROGRAM
 ON MIR.SAI WHICH YOU MAY LIKE TO SEE. IT DOES A LOT OF WIERD
 THINGS. TWO COMMENTS IN THE PROGRAM WILL POINT THE PROBLEMS.
 THEY ARE SYSTEM BUGS OR THE DOCUMENTATION WE HAVE IS 
 OUTDATED. I WOULD LIKE TO HEAR YOUR OPINION ON THIS.
 MY NAME SHRIRAM.
 MY FILE MIR.SAI ON [1,MSW]
 THANX.BYE.
∂19-JUL-73  1102		IML,BO AT TTY113 
 SAIL BUG: USING PORTRAN PROCEDURE ATAN2, THE EXPRESSION
 ATAN2(A-B,C-D) USES THE SAME TEMPORARY STORAGE LOCATION FOR
 BOTH OF THE EXPRESSIONS IN THE CALL.
 
∂04-AUG-73  1526		1,LDE
 Please see LEAP.SAI[1,LDE] ( a five line program) for what seems to be
 a ridiculously basic Leap bug.
 _
∂3-AUG-73  0826		network site CMUA
 An ENDC followed by an ELSEC gives a non-helpful error message of
 ILL MEM REF.  (See BADCOM.SAI[1,LDE) for and example.)
 		Lee Erman
 
∂20-AUG-73  1557		MA,JAM
 Hi. JAM here. I think I have discovered a feature,
 but it might well be considered a bug. Try to
 compile SAIBUG.SAI[MA,JAM] and it will get an
 error on page 8 that says "Not enough params supplied
 to procedure". To save you some looking, the statement
 is:
 	P1←PITCH(NLEND(RG1));
 P1 is a real, RG1 is an integer. PITCH is a macro defined
 on page 4 as:
 DEFINE PITCH(PK)="RGET(PK,1)";
 RGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
 of two integer arguements.
 NLEND is a macro defined on page 5 as:
 DEFINE NLEND(R)="PGET(R,2,TRUE)";
 PGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
 of two integer arguements and one boolean arguement.
 	What seems to happen is that the terminal ",1" in
 the expansion of PITCH seems to get lost. If I put in
 REQUIRE "⊂⊃⊂⊃" DELIMITERS; above the call, it gets past that
 point. As I say, this may be a feature, not a bug, but here
 it is anyway.
∂15-OCT-73  1032		network site MAXC
 -------
 Date: 15-OCT-73 1032
 From: SPROULL at PARC-MAXC
 Re:   Bug in INTMOD
 - - - -
 I belive that there is a bug in the export version of
 INTMOD (interrupt handler) in NWORLD.  I was reading the code,
 preparatory to doing some shit for NIH, and I found this
 exciting mask that is commented "insure only legit bits"
 Unless I am very much mistaken, the person that put together
 that mask counted bits from the left beginning at 1, not 0,;;;
 the result is that the mask is WRONG.  Consult page 3-2 of the
 DEC Assembly Language Book, and behold!!!!
 
 Am I right??
 -------
 
∂08-OCT-73  1322		MA,JAM
 JAM again. With reference to my last note, it
 would appear that the problem is not necessarily
 SAIL's but instead the LOADER's problem. That is,
 if I say EX PP/DUMP, it executes fine but the
 dump file is garbaged. If I say LOA PP then
 SAVE, the dump file is OK. OK? Maybe you ought
 to pass this on to whomever 'fixed' the LOADER,
 whoever that is.
 
∂08-OCT-73  1314		MA,JAM
 Hi. JAM here with another SAIL bug. If I SAVE my
 program with the indicated amount of core from the
 LOADER, it gets "RELEASE&: INVALID CHANNEL NUMBER"
 If I SAVE it in one more K than that, it works fine.
 See for yourself. The failing version is BUG.DMP[MA,JAM],
 the winning version is PP.DMP[MA,JAM]. Source file
 is PP and is assembled alone. To run:
 
 RU BUG[MA,JAM]
 Input file:	JJJ.SND[SND,JAM]
 Output file:	FOO.TMP
 Clock rate:	20000
 Lower frequency bound:	50
 Upper frequency bound:	300
 Step in Ms:	5
 stp = 100
 Decay constant =   .9480775
 Min. frequency resolution in Hz:	1
 167 frequency points
 
 at this point, program will either immediately
 fail or start computing ad infinitum. Happy
 hunting. P.S., this is not unique to this program,
 I have several others that exhibit this behavior.
∂19-OCT-73  1450		2,MLM AT TTY110 
 SAIL PEOPLE: Found a DRYROT.  I know what the mistake in the source file
 is, but you might be interested in the compiler problem that causes this
 DRYROT message.  Compile DRYROT.SAI[2,MLM] and you will get message.
 You may copy, delete, etc. this file.
∂21-OCT-73  2140		204,MLM AT TTY110 
 SAIL PEOPLE: Have found another DRYROT; I know what's wrong but again
 thought you might be interested.  Should I bother reporting these as
 the Monitor manual suggests, or are they so common as not to bother?
 All files on [2,MLM] produce DRYROT messages because of stupid mistakes
 (in fact these are stupid programs altogether, the product of my rather
 empirical method for learning SAIL; my apologies to your sensibilities)
 and are yours to play with and delete.
∂25-NOV-73  1426		network site CMU
 ***** FTP mail from [A702SA00] (ERMAN)
 SAIL SAILORS:
 	Suggestions from CMU while you are freebing things:
 
 .Add .FAI extensions to source file names -- most installations do
 not have FAIL as the default compiler but rather FOOTRAN.
 
 .Make sure all the runtimes that the compiler calls are
 HEREd (e.g. POW and FPOW).  It seems silly to have to make
 a new compiler just because some trivial change needs to
 be made to the runtimes.
 
 .The DRYROT that "can't happen" in SYM at INCR3 can happen if
 it is at the top of core and no more room to expand -- the
 error msg should be made more informative thereof.
 
 .CVSIX hacks on [], -- I know why, but can this be handled
 more cleanly.  (In the very least, the manual should state that.)
 
 .Error messages from the compiler should not use non-standard characters
 (such as left single quote) and should translate them (including underbar)
 to their standard ASCII equivalents.  The current state is particularly
 messy on terminals that thing these characters are control characters
 for them.
 
 .The ALLOC request doesn't accept lower case y.
 
 .A missing runtime is CVR -- convert to real.
 Some helpful compile time functions would be:
 CURLINE -- current line number of the source file,
 CURFILE -- current source file name,
 CURDATE -- date of the compilation,
 CURTIME -- time of the compilation.
 
 .REQUIRE MESSAGE should accept a compile-time string expression.
 
 .Device I/O error message should print out the status bits of the channel.
 
 
 For the following things, we already have them in our code under
 a SACSW switch and SAC/NOSAC macros (they can be found in the appropriate
 files on A701SA00/CMUB); if you don't stick them in
 the general system, we will stick them in under our switch:
 
 .A facility for trapping to a user's procedure on certain events --
 currently we have before and after a coreuuo and before and after
 string garbage collection.  Obviously, it would be much nicer to
 integrate these into the new stuff you guys have.
 
 .During a REENTER ALLOC, print out the current values when asking
 for new one.
 
 .A here HERE location in the runtimes called DD.RET which contains
 a  JRST @2,UUO0.  Likewise, a msg is printed out when ones gets to
 DDT (by typing a D to the error msg handler) that one returns
 by typing "DD.RET$G".
 
 .In the error UUO, type out a crlf before beginning the error msg.
 (Besides making things generally neater, this is essential on the
 ARDS if it is in vector mode.)
 
 .Remove that idiocy when string space is exhausted that automatically
 restarts your program, thus making it impossible to rummage around
 (with ddt) and find out where all the string space went.
 (Of course, if the dynamic string space goes in, then this won't be
 necessary.  Dynamic string space will make the facility to inform
 the user of garbage collections and space expansions even more important.)
 
 .HERE on CORGET & friends.
 
 .If running 2 segments, prevent the lower one from expanding past
 400000 -- only chao results.
 
 .In SIMIO, make explicit check for doing buffered I/O with no buffers -- the
 DEC monitor is not as nice about error messages as yours.
 
 .By turning on a funny bit in the left half of the argument when doing
 an OPEN, let him specify that nulls are not to be thrown away when
 doing ASCII input.
 
 .Give error message in OPEN if invalid device name or device
 unavailable only if he asked for error msgs (in the EOF variable).
 For device unavailable, ask him if he wants to try again.
 In any case, make the error continuable, with the EOF variable
 set to TRUE..
 
 .In the OPEN, use the DEVCHR uuo to determine if the device is
 a TTY, not just the name of the device (since one often does a
 logical assignment.
 
 .GETSTS and SETSTS routines:
 STAT←GETSTS(CHNL);		SETSTS(CHNL,BITS);
 
 .An input mode (called K) that converts lowercase alphapetics (a-z only)
 into upper case.  (We also have a mode called F that converts to lower
 case, but I don't think anyone has ever used it.)  Likewise, an integer
 procedure called TTYUP(DOIT) that
 sets conversion of TTYUUO's to do similar conversion on input:  if DOIT
 is true, then doit, else don't.  It returns the old value of the state.
 
 .When coming into ARRYOUT and WORDOUT, set the EOF variable to false.
 
 
 .A routine called INOUT(inchan,outchan,amount) that does direct
 i/o between the channels, thus saving a movement of the data.  If
 amount is negative, then go til hit EOF.  In all cases, set the EOF
 variables as if one were doing arryins/arryouts. (e.g., errors.)
 
  
∂25-NOV-73  1306		1,LDE
 By the way, the correction to my network mailing address never got made on
 the document that got distributed.  It says I'm at CMU-10A -- should be
 CMU-10B.
 		thanx,
 			Lee
 
∂25-NOV-73  0956		1,LDE
 I now have a tiny program that seems to poke the multiple string preload problem:
 see PREBAD.SAI[1,LDE] get an illegal uuo.
 	Lee
 }
∂25-NOV-73  1528		1,KVL
 Everything seems to work properly in the new err stuff.  I've tested
 the compiler version of logging, REQUIRE ERRMODES, <esc>I, and linkage
 to user procedures.  The description of the new stuff is ERRORS.NEW[S,KVL].
 There is a bug in the compiler which I don't think is mine.  The compiler
 always emits a 0 at S.+7.  When this is changed to JFCL, everything runs
 fine. Seems to be independent of what's in the source.  
 
 I probably won't be around for awhile. Give me a call if any bugs develope.
 -Kurt
∂26-NOV-73  1739		S,JRL
 I found the difficulty with LES's program. He had a FORLC of the form
 
 	FORLC X = (A,B,C) DOC
 		⊂ mummbblee   X mummmble ⊃ ENDC
 
 where X had previously been defined as a macro name. Hanan did not turn
 off macro expansion as soon as the FORLC was scanned, but did turn it off
 while scanning the FORLC body, Thus if the macro X had been defined
 
 	DEFINE X = ⊂FOO⊃;
 
 the FORLC was acting like:
 
 	FORLC FOO = (A,B,C) DOC
 		⊂ mummbblee  X mummble ⊃ ENDC
 
 I have not changed the compiler, but have sent a note to Hanan telling him about
 this problem.
 
 		jim
 
∂26-NOV-73  0854		1,PJ AT TTY125   0854
 PRIMES.SAI[1,PJ] CAUSES IO TO UNASSIGNED CHANNEL AT USER 24001.
 I WOULD BE INTERESTED IN YOUR COMMENTS AS TO WHY.
∂27-NOV-73  1257		network site AI
 
 - - - - - - - - - - - -
 
 11/27/73  15:55:37
 From:  PJ@MIT-AI
 
 - - - - - - - - - - - -

 
 WHAT IS JOBENB ALL ABOUT?
∂27-NOV-73  1816		1,LDE
 RUSS:
 THIS IS MARK AT CMU. WE ARE HAVING A LITTLE PROBLEM
 WITH FAIL.  AS I TOLD FW IT LOOKS LIKE A PUSHJ CORINI SHOULD BE DONE
 AFTER THE RESET AT DOAT:.  THIS SEEMS TO LET OUR CCL DO ITS THING.
 HOWEVER WHEN I ASSIGN DSK AS SYS THEN SAY COMP FILE.FAI I GET AN
 ILLEGAL UUO AT PC 7414. THE WORD IS THE TEMPCOR CALLI.  WHEN LOOKING
 AT THE INFO PASSED TO THE CALLI I FOUND A BUFLEN OF 170 WHICH
 WITH THE JOBFF SEEMS TO EXCEED THE CORE THE JOB HAS ALLOCATED, IE.,
 THE JOB HAS 12K WHEN ONE DOES A CORE COMMAND YET THE ADDRESS OF THE
 LAST WORD OF THE BUFFER EXTENDS PAST THE 12K. 
    ANOTHER FUNNY ITEM IS THAT WHEN ONE USES CCL FROM SYS THERE IS NO
 ERROR AND COMPILATION COMPLETES FINE, YET IF IASSIGN DSK
 AS SYS AND THEN RUN COMPIL FROM THERE I GET THE ILLEGAL UUO.
    AM I JUST IGNORANT OF THE FACTS OF FAIL OR IS THIS A BUG?
    COMMENTS WILL BE GREATLY APPRECIATED.
 MARK [A610MM42] PDP-10/B
∂28-NOV-73  0000		IMS,AIL
 THIS IS RLS.  THE FIX IN SYM (FOR THE FORMFEED BUG)
 IS WHAT I DID ALSO.  I WILL TRY TO CONFER ON
 OUR BUGS WHEN WE MERGE.  ALSO I HAVE SOME FEATURE SUGGESTION.
 			BOB SMITH
 
∂28-NOV-73  2232		network site CASE
 -------
 Date: 29-NOV-73 0128-EST
 From: METZGER at CASE-10
 Re:   SAIL ON [S,AIL]
 - - - -
 RUSS, IS THE SAIL ON [S,AIL] IN A STABLE STATE? I'D LIKE TO GET A
 COUPLE OF THE BUG FIXES AND SINCE SO MANY FILES ARE AFFTECTED I THOUGHT
 I'D FTP THE WHOLE WORKS IF THINGS ARE STABLE ENOUGH. WHOULD YOU BE
 INTERESTED IN THE ROUTINES TO DO SOME STRING COMPARES? MANY PEOPLE
 HERE FIND THE EQU ISN'T  ENOUGH SO WE WROTE THINGS TO DO
 LSS("ABC","DEF"), GTR LEQ AND GEQ. WITHOUT SUCH ROUTINES IT'S A LOT
 HARDER TO WRITE SORTING ALGORITMS. I FEEL THAT THE CURRENT MEANING TO
 STRING A < STRING B DOESN'T HAVE MUCH USE AND THAT IT WOULD BE NICE
 IF <,> ETC. WOULD USE THE WHOLE STRING WHEN DOING A COMPARE.
 ALSO WOULD IT BE POSSIBLE TO TO PUT THE "END OF SAIL EXECUTION"
 UNDER A CONDITIONAL ASSEMBLY SWITCH AS MANY PEOPLE HERE USE SAIL TO
 WRITE SYSTEM TYPE PROGRAMS AND DON'T WANT SUCH MESSAGES. IN GENERAL
 THEY DON'T WANT ANY SAIL MESSAGES (PARTICULARLY THE SAIL ERROR MESSAGES
 THAT ASK THE USER TO CONTINE, EXIT OR WHAT EVER AS THESE TEND TO
 CONFUSE NON-SAIL PROGRAMMERS, BUT THIS IS A MORE GLOBAL ISSUE OF THE
 ERROR TRAPPING AND RECOVERY PROBLEM THAT KVL IS WORKING ON).
 HOW IS THE TENEX SAIL GOING? I HAVEN'T BEEN ABLE TO CONTACT BOB SMITH
 IN A WHILE. DID HE GET THE CONTRACT SETTLED YET? PROBABLY THE BEST WAY
 TO ANSER THIS IS TO LOG IN HERE AND USE OUR SNDMSG (UNLESS YOUR MAIL
 PROGRAM CAN SEND TO NET SITES EASILY). THE PASSWORD TO SAIL-TAYLOR IS
 STILL THE SAME AS YOUR BOAT'S NAME.
 			JOHN METZGER
 			METZGER@CASE-10
 -------
∂30-NOV-73  1402		network site CASE
 -------
 Date: 30-NOV-73 1702-EST
 From: METZGER at CASE-10
 Re:   GOT YOUR MESSAGE
 - - - -
 THNKS FOR THE INFO. WILL TRY TO FTP NEW SOURCES WED OR THURS.
 I'LL PUT THE STRING ROUTINES (LSS, GEQ ETC) ON <SAIL-TAYLOR>
 SO YOU MAY LOOK AT THEM AT WHEN YOU GET TIME. FEEL FREE TO GRAB
 ANY FILES YOU WANT FROM OUR SYSTEM (IF WE DON'T WANT SOMETHING
 TO GET OUT WE HAVE IT PROTECTED, SO ANYTHING THAT'S UNPROTECTED IS
 FAIR GAME). THE STRING ROUTINES ARE IN A FILE CALLED COMPAR.
 AL ROSENFELD WILL BE AT NIC, PARC AND ISI ABOUT THE FIRST WEEK OF
 JAN. AND WILL PROBABLY STOP AT SU-AI. I'M NOT SURE IF I'LL BE WITH HIM
 AT THIS TIME. AS WORK IS PROGRESSING ON THE NEW LEAP SYSTEM WE'D LIKE
 TO GET TOGETHER WITH YOU AND JIM LOW, TO FIND SOME OF THE REAL NASTY
 PROBLEMS IN LEAP AND TO HAVE YOU HELP EXPLAIN HOW THE CODE GENERATORS
 ARE ALL PUT TOGETHER. WILL YOU OR JIM BE WILLING TO DO THIS (FOR ABOUT
 A WEEK SOMETIME IN JAN)? CONSULTING FEES MAY BE ARRANGED, I'LL HAVE TO
 TALK TO PEOPLE HERE TO FIND YOU EXACTLY WHAT WOULD BE ACCEPTABLE.
 THE BASIC PROBLEM IS CONVERTING ALL THE CODE GENERATORS TO BELIVE
 ITEMS ARE 27 BITS WIDE INSTEAD OF JUST 18. ALSO DATUMS HAVE TO BE 
 PAGED. WE HAVE IDEAS HOW TO DO THIS, JUST THAT THE INTERNALS
 OF THE CODE GENERATORS IS NON TRIVAL, THE SMALLEST CHANGE SEEMS TO
 CAUSE A GREAT DEAL OF HAVOC AND WOULD LIKE YOUR EXPERT HELP WITH
 THIS STUFF. JIM CALVIN HAS JUST RECENTLY ASDDED SOME CODE TO TOTAL
 AND FRIENDS TO GENERATE A MACHINE LANG. LISTING SIMILAR TO FORTRAN'S
 M OPTION, ANYONE INTERESTED IN SUCH A THING. WE WANT IT TO HELP
 WITH DEBUGGING NEW CODE GENERATORS. THANKS AGAIN. NO HURRY ON A RESPONSE
 I WON'T BE BACK TILL NEXT TUESDAY.
 					JOHN METZGER
 					METZGER@CASE-10
 -------

∂30-NOV-73  0949		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 Russ,
 	Just to confuse you, I think we will bring up the new Sail
 on A700SA00, and leave the old stuff on A702SA00.  In preparation
 for this, I have moved SAIL.LOG to A700.
 	Sorry, again.
 			Lee
 

∂04-DEC-73  1011		1,DCS
 Unfortunately, your fix will not work.  It will cause block name
 mismatches, in fact, if you're not lucky -- and other things too.
 
 The problem is that unless you copy the zeroes accompanying the end
 of identifiers down to new locations when you move the identifiers, what
 is left after some new identifiers will be non-zero characters
 from previous strings.  Since the scanner compares full words,
    things will no longer match.  In addition, if the last string
 is a complete identifier, unless topbyte lines up, there's no guarantee
 that it will face a zeroed set of characters -- this sentence
 doesn't make much sense.  
 
 Anyhow, best is for programs which set SGLIGN to assume that
 topbyte will be aligned after GC.  If it should not be (should point
 to first char after partial ID, for example), the program
 should re-create TOPBYTE using SUBSTR, and the known partial
 length and starting ID byte ponter.  I now recall special hair
 in the GC to make sure TOPBYTE lined up just
  past the last char of the last string moved.  It was
 a true, losing kludge.  I will be happy to try to get SYM fixed
 to do what I suggested above, but am not sure how soon I can do
 it what with vball and no sleep and all.  You could help
 by listing the STRNGC portion of GOGOL and all of SYM, I guess.
 
 Let me know if either you think I'm wrong, or there's something else.
 Also call me at work to discuss this, etc. -- try several times,
 since there's no paging.
 Dan
∂05-DEC-73  1130		1,PDQ AT TTY26   1130
 HEY, ZERO DIVIDE BIT IS NOT GETTING CLEARED IN NEW
 OVERFLOW CODE.  THE MOVSI 440100 AT TRIGIN+37 SHOULD BE
 MOVSI 440140.
∂06-DEC-73  0847		GUN,KKP AT TTY74   0847
 The current global segment still has the bug in the PTY code.  We need
 this fixed if I am going to get the hand/eye monitor running again.
∂06-DEC-73  0954		1,DCS
 Russ,
  Subtle bug (which I actually encountered!):
 
   Consider, if you will,
 	USERCON(UUO1,SAVERET,0);   and its corresponding
 	USERCON(UUO1,SAVERET,1); !!
   The effects are lovely and mysterious.  Try to predict
    them without writing any programs.  This is one nice
    mutation.
 DCS
 
∂6-DEC-73  1914		network site CASE
 -------
 Date:  6-DEC-73 2034-EST
 From: METZGER at CASE-10
 Re:   ANNOUN
 - - - -
 GOT YOUR MESSAGE OK. WHY WAS IT SENT FROM BBN? I ASSUME THAT SINCE
 IT CAME FROM BBN YOU KNOW THAT GOODWIN AND CREW HAVE FINISHED UP
 THERE WORK ON BBN'S VERSION OF TENEX SAIL. NOT MUCH WAS DONE.
 JUST UUO'S OUT OF COMILER AND RUNTIMES, AND NEW COMMAND SCANNER
 THAT TAKES TENEX NAMES (AND FILE COMPLETION) ALSO TENEX FILE
 NAMES IN REQURIES (REQUIRE <SAIL>NAME.EXT INSTEAD OF NAME.EXT[X,Y])
 ALSO COMPAR.FAI (THE SAIL STRING THING TO DO LSS(A,B) ETC.) IS ON
 <SAIL-TAYLOR> IF YOUR INTERESTED.		JPM
 -------
 
∂6-DEC-73  2339		network site CASE
 -------
 Date:  7-DEC-73 0240-EST
 From: METZGER at CASE-10
 Re:   [X,AIL]
 - - - -
 I'D BE GLAD TO GIVE YOU ANY HELP YOU WOULD NEED ROM ME TO
 SET UP X,AIL. IF NONE IS REQUIRED, THEN I'LL FTP THE FILES FROM
 X,AIL EARLY MONDAY MORNING (UNLESS I HEAR FROM YOU THAT I SHOULD
 WAIT) AND WILL TRY TO GET UP A STRAIGHT EXPO SYSTEM, THEN PUT IN
 OUR PATCHES, WHICH FOR RIGHT NOW ARE:
 REMOVE "END OF SAIL EXECUTION" MESSAGE
 ADD OUR LOCAL RUNTIMES (CHANGES TO FOO2 AND ORDER ONE EXTRA FILE
 	CALLED CASE10 WITH ALL THE CODE)
 FIX MINOR EXPO BUGS LIKE LOADVR←←52 IN FILE SAIL (NOT UNDER STANSW
 	OR NO EXPO)
 FIX SCISS TO START FAIL IN INFERIOR FORK. (MINOR CHANGE)
 DON'T HESITATE TO LET ME KNOW IF THERE IS ANY THING I CAN DO TO HELP.
 				JPM
 -------
∂8-DEC-73  1535		network site MAXC
 -------
 Date:  8-DEC-73 1537
 From: SPROULL at PARC-MAXC
 Re:   The usual
 - - - -
 You'll never believe it, but there are no bugs in
 the glorious interrupt handler (that is, i found an overflow
 with a jfcl following it that did the right thing!).  So
 I am farily confident that it is ok.  Furthermore, Gary Knott
 will surely test EVERY possible combination of conditions before
 he "accepts" the new system.
 
 I did discover one small thing.  We put in the entry DD.RET for
 Lee Erman so that you could return from DDT after typing D to
 an error message.  It is a HERE'd symbol, in the error handler
 area.  However, I forgot to make in INTERNAL when putting out
 a library (another minor change the the COMPIL macro for
 SAILUP).
 
 My tapes, they spin slowly.
 -------
∂09-DEC-73  1635		S,LES
 Dan,
 Here is an elaborated version of SAVE_IT that gets around a couple of
 problems.  In order to avoid having to give a Core argument to SSAV,
 the left half of JOBSA is set to JOBREL.
 						LES
 
 PROCEDURE SAVE_IT; BEGIN
 COMMENT If you  are doing no  I/O, you may  call this procedure.   It
 saves  the accumulators, sets up  a new starting  address, and exits.
 If you then say "SSAV <file>" (or "SAVE ..." if you have  no segment)
 then subquently  RUN <file>, it  will start  at the point  where this
 procedure  was called,   thus preserving  all strings,   items, etc.,
 that would  be  cleared in  a normal  start.   Note  that you  cannot
 subsequently  give  ↑C and  start  the  program  again, since  SAIL's
 storage allocation  would become  hopelessly  confused.   To  inhibit
 this,  any such attempt draws an error message. ;
 	SIMPLE PROCEDURE BOMB; BEGIN
 		OUTSTR("
 Sorry, you can't restart this program.  Please get a new copy.
 ");
 		CALL(0,"EXIT");
 		END;
 	START_CODE
 	SAFE OWN INTEGER ARRAY SAVACS[0:'17];
 	EXTERNAL INTEGER JOBSA,JOBREL;
 	LABEL RESTART,RERESTART;
 	MOVE JOBSA;
 	HRRI RERESTART;
 	PUSH '17,0;
 	MOVEM '17,SAVACS['17];
 	MOVEI '17,SAVACS[0];
 	BLT '17,SAVACS['16];
 	HRL JOBREL;
 	HRRI RESTART;
 	MOVEM JOBSA;
 	CALLI 0,'12;
 
 RERESTART:  PUSHJ '17,BOMB;
 RESTART:
 	MOVSI '17,SAVACS[0];
 	BLT '17,'17;
 	POP '17,JOBSA;
 	CALLI 0,0;
 	END
 	END "SAVE_IT";
∂11-DEC-73  1814		network site MAXC
 -------
 Date: 11-DEC-73 1815
 From: SPROULL at PARC-MAXC
 Re:   Sproull in Washington
 cc:   JRL at SU-AI, SWINEHART
 - - - -
 Throught the magic of the ntwork, I come forware to hassle you
 in your peace.  Basically, I was able to read my tapes, and 
 everything works.  However, I have found two bugs, one of
 which is serious:
 
 1. (not serious( JRL>s bug fix PP to check for hiseg arrays
 going 'before' the origina of the rel file fails to check
 the OWN bit before entering the bug check.  There fore,
 I reccommend something along the lines of
          Tnn tbits,own
           jrst .+6
 in ARRAY, just at the beginning of the PP patch.
 
 2. (serious) God damn you Russ talyor, that piece of my
 accumulator-saving code that you 'optimized' because you
 couldn't keep your fucking fingers off the code, you broke.
 When restoring ac's after the call on the error handler
 proc, there is a HRLZI ff,d-15(p) that is wrong, it should
 be HRLZI ff,dxxxxxx scratch that it is now hrlzi ff,15-d(p),
 and should be hrlzi ff,d+1-15(p).   This really fucks
 up the compiler whenever an error message is ussued,
 clobbering PNT, TBITS, and the like.  You should be
 ashamed.
 
 More news later, pehrhaps.  But for now, all is well.
 MLAB runs (wihtout error handler yet), even in a HISEG
 version!!!!  See ya.
 

∂11-DEC-73  1648		ACT,REG
 THE CRETINOUS MANUAL LIES ABOUT THE COMPILER BEING SMART ENOUGH TO GENERATE
 AN ASH FOR DIVISION BY A POWER OF 2! [24L]
 AND WHATEVER ASSHOLE PROGRAMMED IT DIDN'T REALIZE THAT IDIV DOESN'T GIVE
 THE SAME RESULT AS AN ASH. E.G.,  '777770000017 DIV '100000 = -7, NOT
 THE -'10 I'D HAVE GOTTEN FROM AN ASH!
∂12-DEC-73  0658		1,RFS
 R
 Russ -- I hate to pick nits, but the addition you made to LOG
 to explain the fix for the bug in GOGOL is NOT correct. First,
 the HRLZI has a (p) in it, second the From and To forms you gave
 are not right:
 	was:    HRLZI FF,15-d(P)
 	s/b:	HRLZI FF,D+1-15(P)
 Note that one of the most importnat parts of the fix is that
 the old ac's are UP the stack (i.e. the thing should be -mumble(P),
 not +mumble as it was).
∂12-DEC-73  1626		network site MAXC
 -------
 Date: 12-DEC-73 1501
 From: SPROULL at PARC-MAXC
 Re:   Another bug
 cc:   SWINEHART, JRL at SU-AI
 - - - -
 Here is your happy bug finder at work.
 
 The XX variables on page 9 of gogol have a problem (actually 2):
 There is some stuff conditionally assembled with the LOW switch
 near the end of the page; needless to say, this screws the XX
 assignments for the high segments, because the low segment will
 have three more cells in there for the LEAP initialization block.
 Fix is to move the LOW stuff to the end of the page, after the last
 XX.
 
 The other problem, which does not actually make a bug, but which is
 wrong, is that the XX for APRACS (GOGOL/9) does not have its fourth
 argument filled in; it shuld of course be 20.  Thought you all
 might like to fix that.
 
 The first thing shouuld indeed bee fixed.
 
 That's all for now.
 -------
 
 
∂14-DEC-73  0003		ACT,REG
 I SUGGEST THAT SAIL BE MODIFIED TO DO A DSKTIM UUO AND A RENAME ON THE
 REL FILE AFTER DOING THE CLOSE TO GIVE THE REL FILE THE LATEST POSSIBLE
 CREATION DATE.  THIS WILL HELP PREVENT RPG FROM DOING EXTRA COMPILATIONS.
 
∂13-DEC-73  2224		1,DCS
 MACRO bug dix (discovered at CMU) (fix for dix) reported in mail to AIL.
 Pls. don't remove it  without recording it in detail in one of 
 the places where things like this belong (changes, etc.)
 CC: rht;hjs;kvl;jrl
 
∂13-DEC-73  2222		1,RFS
 Russ, please read bugs.rfs[1,rfs]
 		rfs

∂13-DEC-73  2223		1,DCS
 Well, might as well try out the bug reporting method.
 
 The code at DEFCHK and beyond in sym has  been  the  most  consistent
 source of bugs ever.  Now there is another bug.  It didn't used to be
 that STRNGC (via SGCOL) could be called at RANSC1+3, by the nature of
 tests  ahead  of time that assured enough REMCHRs. But now, there's a
 test in RESTOR, coming out of macro actuals, to see if there's enough
 room  for  the  rest  of  the macro, and that can cause GC to happen.
 Anyhow, in the DEFCHK code there's a kludge  whereby  one  string  is
 made  to  look  one  character  too long, to protect a pointer to the
 succeeding byte.  It seems I do this a tad too  early,  because  what
 happens is the STRNGC after RANSC1 happens, and TOPBYTE ends up being
 kicked up one character, so that a null ends up in the macro  string,
 then  some other things happen, and the null stays, but the character
 following the null gets wiped out by the '177/0  thing,  or  someting
 like  that.  Now, at SEEPRM and following, the one extra char. kludge
 is ok, becuase it does protect a random pointer over  gc,  and  later
 TOPBYTE  gets  restored from saved values anyhow.  I include all this
 in hopes you will just ignore it  and  install  the  fix,  with  some
 innocuous comment. It is actually easier by far to understand than to
 explain. The fix goes:
 
 Delete the line, at DEFCHK+6 or so, which says:
 	ADDI	C,1	;TO CARRY XTRA CHAR THROUGH FURTHER STEPS
 
 Replace the instructions at SEEPRM:
   HRRM <-> SUBI <-> PUSH <-> PUSH <-> PUSH      with:
 
 SEEPRM:	PUSH	P,A		;Save bits,
 	PUSH	P,B		;  character, and current total
 	PUSH	P,C		;  macro body string count.
 	ADDI	C,1		;Make PNAME look one longer to protect
 	HRRM	C,PNAME		; end pointer over GC.
 
 finally, change 5 to 4 in COLNEC-1.
 
 I  have  not  made this change in any files anywhere. Thought I'd try
 expo bug reporting scheme.  Oddly, this same fix was necessary for me
 to  compile FILE, which I was asked to recompile here, just as I came
 here last eve. to report bug. Truly surprised that  any  macros  have
 worked recently (since at least last July).
 
 HJS  may  want  to  check  this  over  before  it  is installed.  But
 something has to happen, and I hope this is it.
 
 Have fun. DCS
 
∂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
∂19-JAN-74  1516		network site CMU
 ***** FTP mail from [A610LE03] (ERMAN)
 BUG REPORT:
 	ARRAY does not work properly as an argument to CHECK_TYPE.
 If given as the only argument, an error msg is generated that says it
 is not legal.  If given in conjunction with anther specifier
 (e.g., REAL ARRAY), it seems to be ignored.  This occurs both
 at CMU and SAIL.
 		LDE
⊗;
To the SAIL hackers--

	I have a complaint about a "feature" of SAIL which I maintain is
a "bug" in someone's thinking.  The bone of contention is conditional
expressions; the "feature" is that "If both expressions are of an algebraic
type, the precise type of the entire conditional expression is that of
the "THEN part"." [SAIL manual]

Argument 1.  It was my understanding that ALGOL in general and SAIL in
	particular were intended to free the user from the old FORTRAN II
	bugaboo of having to have all variables and constants be of the
	same type in any given statement.  It seems inconsistent to have
	automatic type conversion to free the user and this @#%$∪!!!
	to trap the user in the same language.

Argument 2.  It is somehow unesthetic that whether or not the statements
		IF FLAG THEN Y←K ELSE Y←X;
		Y←IF FLAG THEN K ELSE X;		
		Y←IF ¬FLAG THEN X ELSE K;		
	will produce the same results depends on the types of Y, K, and X.

Argument 3.  Most of the time, the compiler already has its finger on
	a piece of information which could tell it what type the expression
	is going to be before it starts compiling the expression.  For 
	example, in the above statements, when the compiler gets to the
	conditional expression, it has already seen that there is going to
	be an assignment done, so it could very well pass along the 
	type of the variable as the desired type of the conditional.
	For those pornographic cases where the compiler isn't sure
	(I can't think of one, but I'll bet you can), the compiler can
	pass a default type which won't hurt anyone (like REAL).

	A similar "feature" exists in CASE expressions; the same arguments
apply to it also.  Next time you get the urge to add 6 grand and glorious
new features to SAIL, how about first removing one that screws people?

∂23-JAN-74  1121		CMU,AIL
 	RUSS-
 X,AIL SEEMS TO HAVE THE OLD VERSION OF SCISS, WHILE S,AIL HAS THE NEW.
 IS THIS RIGHT, AND IF SO, WHY?  I WOULD APPRECIATE YOUR NOTIFYING ME, LEE, OR
 SAIL, AS WE'RE BRINGING UP THE NEW COMPILER NOW.
 					PADDY

∂23-JAN-74  0955		network site MAXC
 -------
 Date: 23-JAN-74  957
 From: SWINEHART at PARC-MAXC
 Re:   CREF
 - - - -
 Will have no time until late Thursday.  I'll take a look at it
 with you then if you like.  I've never looked at CREF either, just
 know the format (which you will know too if you read the approp. part
 of SYM). Try it (CREF on same listing) using /S switch.
 This suppresses listing, prints only the cref part.  I suspect it
 will blow in much the same way, but that will help pin it down a little.
 -------

  
∂15-DEC-73  1137		1,DCS
 I have on [AIL,DCS] the files GOGOL, HEAD, and FEATS, copied this date
 	from [S,ail] (note S!)
 
 (I still think all doc. and communic. files should live on [X,AIL] so
  network types need not look elsewhere -- could even be locked out of
  elsewhere).
 
 FEATS documents:
   %AZ% -- my improvements to REENTER, ALLOC sequences.
   %BA% -- new STRNGC
   %BB% -- CMU-style traps.
 
 HEAD contains %BA% changes.
 GOGOL contains changes for all of above.
 
 RHT or JRL will probably want to install these files on [S,AIL], etc., 
 depending on current state of things.  No code changes.  I was afraid
 to edit on [Sxx S,AIL] -- perhaps a document like mine, putting forth
 local protocol ([S,AIL], etc.) would be useful.  Also, what is real
 protocol for other files, as adapted from that paper -- I'm sort of
 out of it.
 
 Handle this as you will, but I'd sort of like to delete these files
 ASAP.
 ghost
 
∂14-DEC-73  1425		1,DCS
 Refer to next bug:
 Another bug:
 The second of those three remaining PUSH 0's (the third
 arg to @.SGCINT) should be PUSH P,SGCCNT(USER).
 ghost
 
∂14-DEC-73  1414		1,DCS
 ANOTHER BUG:
 THERE ARE four PUSH P,0 instructions on lines 25 to
 28 of GOGOL; there should be but three.  The segment could probably be
 patched to get this one, wihtout too much trouble.  Traps  don't
 work right with this bug installed.
 ghost
 
 
∂13-DEC-73  2223		1,DCS
 Well, might as well try out the bug reporting method.
 
 The code at DEFCHK and beyond in sym has  been  the  most  consistent
 source of bugs ever.  Now there is another bug.  It didn't used to be
 that STRNGC (via SGCOL) could be called at RANSC1+3, by the nature of
 tests  ahead  of time that assured enough REMCHRs. But now, there's a
 test in RESTOR, coming out of macro actuals, to see if there's enough
 room  for  the  rest  of  the macro, and that can cause GC to happen.
 Anyhow, in the DEFCHK code there's a kludge  whereby  one  string  is
 made  to  look  one  character  too long, to protect a pointer to the
 succeeding byte.  It seems I do this a tad too  early,  because  what
 happens is the STRNGC after RANSC1 happens, and TOPBYTE ends up being
 kicked up one character, so that a null ends up in the macro  string,
 then  some other things happen, and the null stays, but the character
 following the null gets wiped out by the '177/0  thing,  or  someting
 like  that.  Now, at SEEPRM and following, the one extra char. kludge
 is ok, becuase it does protect a random pointer over  gc,  and  later
 TOPBYTE  gets  restored from saved values anyhow.  I include all this
 in hopes you will just ignore it  and  install  the  fix,  with  some
 innocuous comment. It is actually easier by far to understand than to
 explain. The fix goes:
 
 Delete the line, at DEFCHK+6 or so, which says:
 	ADDI	C,1	;TO CARRY XTRA CHAR THROUGH FURTHER STEPS
 
 Replace the instructions at SEEPRM:
   HRRM <-> SUBI <-> PUSH <-> PUSH <-> PUSH      with:
 
 SEEPRM:	PUSH	P,A		;Save bits,
 	PUSH	P,B		;  character, and current total
 	PUSH	P,C		;  macro body string count.
 	ADDI	C,1		;Make PNAME look one longer to protect
 	HRRM	C,PNAME		; end pointer over GC.
 
 finally, change 5 to 4 in COLNEC-1.
 
 I  have  not  made this change in any files anywhere. Thought I'd try
 expo bug reporting scheme.  Oddly, this same fix was necessary for me
 to  compile FILE, which I was asked to recompile here, just as I came
 here last eve. to report bug. Truly surprised that  any  macros  have
 worked recently (since at least last July).
 
 HJS  may  want  to  check  this  over  before  it  is installed.  But
 something has to happen, and I hope this is it.
 
 Have fun. DCS
 
∂25-JAN-74  1242		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 RUSS,
 	YOUR BUG FIX QK DOES A JRST TO EXTCSE.  THAT IS UNDEFINED
 WHEN ASSEMBLED AT CMU (WITH APPROPRIATE SWITCH SETTINGS) AND I
 COULD NOT FIND THE SYMBOL IN GEN.  I SUSPECT IT IS A TYPO ON
 YOUR PART.  WHERE SHOULD IT JRST TO?
 		LEE
 
∂16-JAN-74  1247		1,LDE
 IT WOULD BE NICE IF WE COULD LOG IN ON CMU,AIL -- THEY
 KEEP CHANGING THE PASSWORD DAILY.  IF SOMEONE COULD
 PUT A PASSOWRD ON THE ACCOUNT (HOW ABOUT "CAS"), THAT
 WOULD PROBABLY BE JUST FINE.
 	THANKS,
 		LEE

∂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
 
∂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.
 
∂19-JAN-74  1516		network site CMU
 ***** FTP mail from [A610LE03] (ERMAN)
 BUG REPORT:
 	ARRAY does not work properly as an argument to CHECK_TYPE.
 If given as the only argument, an error msg is generated that says it
 is not legal.  If given in conjunction with anther specifier
 (e.g., REAL ARRAY), it seems to be ignored.  This occurs both
 at CMU and SAIL.
 		LDE
  
∂24-JAN-74  1019		CMU,AIL
 	WE HAVE A NEW BUG FOR YOU:  TRY RUNNING BADSAI.SAI ON CMU,AIL.
 						PADDY

∂23-JAN-74  1128		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 	MORE ON CHNCDB:  IT ISN'T IN FOO2, SO ITS USE GIVES AN UNDECLARED
 IDENTIFIER ERROR.  ALSO:  LEE HAS NOW DECIDED THAT THE DOCUMENTATION IS
 RIGHT.  SORRY.
 					PADDY
 
 
∂25-JAN-74  0930		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 FOLLOWING SENT TO AIL AND RHT:
 	Yet more CMU reports  LDE 25-Jan-74
 We are trying not be bother you folks too much, but some of
 these problems are fairly mutual.
 
 	Anyway, following are some things.  (Notice that we
 are now generating our own bug numbers for bugs we first
 notice here.  Obviously, you should in general ignore them,
 but it might be convenient for us if you could stick our
 number in your bug file (as well as your number) so that we
 can re-synchronize when merges take place, etc.  In our
 files, we are using =xx=, to contrast to your #xx#.)
 
 
 PTRAN.SAI[X,AIL] is slightly older than the one on [S,AIL] and
 it won't compile the HEL that is on [X,AIL] because EXNO is too
 small.  (The fix is to move the newer PTRAN.SAI over from [S,AIL],
 obviously.)
 
 
 	The bug reported yesterday poked at by BADSAI.SAI[CMU,AIL]
 is incorrect code generated for a logical test.  Looks like the
 old-style NEGAT bugs?  BADSAI is only about five lines long.
 We have given that CMU bug number =A3=.
 
 
 	CMU bug number =A4=  (very low priority, I guess)
 The following bad syntax generates the strange message
 "INSERTING FORGOTTEN SEMI-COLON".  Continuing causes
 an infinite loop of the same.
 BEGIN
 IF TRUE THEN ;ELSE;
 END
 
 
 	Noticed  that PTRAN and  RTRAN run ridiculously  slow -- they
 have many tiny procedures, none of which is declared simple.
 
 One  general problem we are  having is that mail  sent to AIL doesn't
 seem to get noticed -- the mail box is full of old stuff and
 just sending more on top of it feels futile.
 If we send to AIL, it is not clear that anyone will ever look at
 it.  We are loathe to send to individuals, but that seems necessary.
 We shall try to be careful about priorities and importances, but
 would like to be able to send low priority stuff (e.g. =A4= above)
 without offending people.
 
 
  
∂29-JAN-74  1400		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 Russ and AIL,  (from ERMAN@CMUB 29-Jan-74)
 	We still have problems in the compiler that for which all
 indications point to the fact that bug fix =QF= (calling .SONTP)
 does not work (in all cases).  Using more string space fixes them.
 	Aren't you guys ever going to stop finding bugs?  We can't
 keep with all the fixes!!!!  (Although I guess we are also guilty
 of same.)
  
∂29-JAN-74  1343		1,JFR
 ARE YOU GOING TO ASK SPROULL TO FIX COMPILE-TIMME ERROR MODES OR CAN I TRY?
 
 I WOULD LIKE SOME HELP WITH THE EXECS CODE FOR PROCEDURE DECLATIONS AND
 CALLS.  
 
 FOR   WRITEON(P1,P2, ... ,PN   HOW ABOUT SOMED THING LIKE 
     FORC I ε (P1,P2, ... ,PN) DOC
 	START_CODE 
 	PUSH	P,ACCESS(I);
 	PUSHJ	P,proper print routine
 	END
 
∂2-FEB-74  1025		network site CMU
 00100	RUSS, GREG, AND AIL:
 00200		APPLY won't accept procedures with string arguments.  This has been
 00300	tried at CMU and Stanford.  Please refer to APP.SAI on CMU,AIL for a short
 00400	example.  We apparently get the same results with or without the fixes #QU#
 00500	and #QW#.
 00600						Paddy (PB01)
 
∂29-JAN-74  1400		network site CMU
 ***** FTP mail from [A700SA00] (SAIL)
 Russ and AIL,  (from ERMAN@CMUB 29-Jan-74)
 	We still have problems in the compiler that for which all
 indications point to the fact that bug fix =QF= (calling .SONTP)
 does not work (in all cases).  Using more string space fixes them.
 	Aren't you guys ever going to stop finding bugs?  We can't
 keep with all the fixes!!!!  (Although I guess we are also guilty
 of same.)
  
∂28-JAN-74  1105		CMU,AIL
 IN BUG FIX #QT#, ERR125 WAS MISSPELLED AS ER 125 IN HEL.  (HELL!)
 		LEE AND PADDY

∂04-FEB-74  1748		1,BH
 The "T" option in SAIL runtime errors doesn't seem to know to run
 E rather than RPG and use TMPCOR rather than DSK.
 
∂04-FEB-74  1726		ACT,REG
 In the SAIL manual, <CONSTANT> is used, but not defined, and
 not indexed.  There's a section that explains "arithmetic constants" and
 "string constants" but tno where does it state that those are what
 <CONSTANT> refers to.
∂05-FEB-74  1138		ACT,REG
 SAIL manual 19.1 (Page 90 left):
 "compilation errors ..... See section 19 about these."
 should be section 20
 
∂05-FEB-74  1136		ACT,REG
 SAIL manual 19.1.3 "boundary" is misspelled

∂06-FEB-74  0449		THE,RHT
 SEEMINGLY, 
 	∀ | MPROC(A,B,C) DO
 		:
 CAUSES A DRYROT AT FBOUT.
 
 
∂06-FEB-74  0435		THE,RHT
 LEAP BUG: UP LEVEL ADDRESSING ON A LIST VARIABLE DOES NOT WORK.
 E.G. ULLBUG.SAI[THE,RHT] CAUSES A DRYROT AT EVAR.  (MOST LIKELY
 NEEDS AN ACCESS??)
 				RUSS
 
∂13-FEB-74  1022		network site CMU
 CMU bug report -- bad code generated by leap.  CMU bug =A8= LDE 13-Feb-74.
 	Getting bad code generated for STRING ARRAY ITEMVAR ARRAY
 accessing.  LPBUG.SAI[CMU,AIL]&[A700SA00] generates bad code in its second
 access in SLEX!DEX and in its first and last accesses in
 SLEX!INIT.  In all evil cases, an instruction is left out --
 the one which access the array after the bounds checking
 has been done.
 	The evilness occurs both at CMU and STANFORD.