perm filename MSGLOG.MSG[S,AIL]10 blob
sn#085164 filedate 1974-02-06 generic text, type T, neo UTF8
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