perm filename AIL.MSG[S,AIL]2 blob
sn#161615 filedate 1975-06-04 generic text, type T, neo UTF8
∂04-JUN-75 0540 CS,MJC
BEGIN
COMMENT The program below I think contains a Sail bug;
REQUIRE 50 NEW_ITEMS;
EXTERNAL PROCEDURE BAIL; REQUIRE "SYS:BAIL.REL" LOAD_MODULE;
SET X;
RECURSIVE SET PROCEDURE XXX(SET X);
BEGIN
INTEGER ITEMVAR U;
BAIL;
COMMENT Dialog at first Bail call (semicolons removed)
1:U
ITEM!139198464 What is this, anyway?
1:X
{ITEM!9, ITEM!10, ITEM!11}
1:!!GO;
U←LOP(X);
BAIL;
COMMENT Dialog at second Bail call
1:U
ITEM!139198464 Replacement apparently not done.
1:X
{ITEM!10, ITEM!11}
1:DATUM(U)
1:!!GO;
RETURN(X);
END;
X←{NEW(1),NEW(2),NEW(3)};
X←XXX(X);
END;
∂19-MAY-75 1459 100,100: HEDRICK@CMUA @ ILL1
WE HAVE TWO POSSIBLE BUGS IN SAIL. FIRST, TYPEIT SEEMS TO BE MISSING
FROM LIBSA, BOTH VERSION 7 AND VERSION 8. IT IS IN SAISG, SO THERE IS
NO PROBLEM RUNNING PROGRAMS (WE JUST USE /Y IN LOADING). SECOND, THE
ARGUMENT LPARRAY FOR CHECK!TYPE SEEMS TO BE MISSING. WE WANT TO
SEE WHETHER SOMETHING IS AN INTEGER ARRAY ITEMVAR. COMPARING IT
WITH CHECK!TYPE(INTEGER ITEMVAR) IS OBVIOUSLY NOT QUITE RIGHT. BUT
INTEGER ARRAY ITEMVAR GIVES A SYNTAX ERROR. WE ASSUMED THAT WHAT WAS
REALLY NEEDED WAS INTEGER LPARRAY ITEMVAR. THAT ALSO GIVES AN ERROR.
WE HAVE TRIED VARIOUS THINGS AND FINALLY GIVEN UP. WE NOW DO LOR OF
[PLESE IGNORE LAST PARTIAL SENTENCE.]
WE NOW DEFINE TWO DUMMY ITEMVARS, ONE INTEGER ARRAY ITEMVAR, AND THE
OTHER REAL ARRAY ITEMVAR. BY DOING LAND OF DECLARATION OF THEM, WE
DERIVE THE BITS FOR ARRAY ITEMVAR. THERE MUST BE A BETTER WAY!
(I THOUGH LEAP!ARRAY MIGHT BE THE CORRECT VERSION OF LPARRAY. HOWEVER,
INTEGER LEAP!ARRAY ITEMVAR HAS THE SAME BIT PATTERN AS INTEGER ITEMVAR.
LEAP!ARRAY TURNS OUT TO BE THE SAME AS ITEMVAR TO CHECK!TYPE.)
WE ARE USING THE CMU SAIL SYSTEM. OUR VERSION 7 IS TAKEN DIRECTLY
FROM THEM, VERSION 8 USES THEIR SOURCES WITH SOME MINOR MODIFICATIONS
TO HANDLE ERROR PROCESSING APPROPRIATELY FOR OUR ENVIORNMENT.
ALSO, IN MAKING THE SOURCE MODIFICATIONS I HAVE RUN INTO PROBLEMS FIGURING
OUT HOW YOU GET VARIABLES IN THE RUNTIMES. WHEN I TRIED TO ADD A NEW ONE
IT ONLY GOT ADDED TO THE COMPILER, NOT THE RUNTIMES, OR SOMETHING LIKE THAT.
IS THERE A DOCUMENT THAT DESCRIBES YOUR PROGRAMMING CONVENTIONS.
(E.G. THE IMPLEMENTATION MANUAL.) IF SO, I WOULD APPRECIATE GETTING A
COPY (PREFERABLY) OR A FILE NAME. I FINALLY ENDED UP USING AN EXISTING
VARIABLE (PPMAX) THAT SEEMED TO BE USED ONLY IN THE EXPORT SAIL SOS
LINKAGE. IF YOU KNOW OF ANY TROUBLE THAT WILL BE CAUSED BY MY CODE
PLAYING WITH THIS VARIABLE (I HAVE REPLACED THE EXPORT SOS LINKAGE),
I WOULD APPRECIATE HEARING ABOUT IT.
THANKS,
CHARLES L. HEDRICK
COORDINATED SCIENCE LAB
UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
URBANA, ILL 61801
$
∂12-MAY-75 0303 1,MJC
PROFIL seems not to like lower-case switches.
∂07-MAY-75 1555 network site CMU
***** FTP mail from [A700SA00] (SAIL)
CMU bug report =E9= LDE 7-May-75
In a construct like:
S←SAR[I]←SPROC;
where S is a string, SAR a string array with variable bounds,
and SPROC a string procedure, bad code gets generated for the
second store (S←SAR) which causes a PDL OV. The address of SAR
gets stored in a temp (over the call to SPROC) with a HRRZM --
it is then moved back into a reg with a MOVE, then POPed into
S, which causes the PDL OV.
E9.SAI[CMU,AIL] and [A700SA00] is a simple example.
-----
∂20-JUL-74 2037 MAP,RF
IN SAIL, WHAT SHOULD I ← (J ← 3) + (J ← 4)
RETURN FOR I? I HAVE THE NASTY FEELLNG IT GETS 8.
∂28-JUN-74 2013 network site CMU
***** FTP mail from [A700SA00] (SAIL)
To: SAIL types
From: ERMAN@CMU-10
Re: mods to GOGOL, IOSER, and PARSE
Date: 28-Jun-74
I have made some fairly trivial fixes to error handling, but
would like to see them get into your S,AIL files so they
won't get lost.
The fixes are described below. I'm sure that
none could be objectionable.
The sources can be found on CMU,AIL as follows:
PARSE.PRT -- the change for PARSE.
IOSER.PRT -- contains replacements for pages 6,7,&9 of IOSER.
GOGOL.PRT -- gives the three changes for GOGOL.
=C2= [GOGOL/32] LDE (28-Jun-74)
Allow call SOS in RPG mode if no file-name specified.
(Totally within CMUSW.)
=C3= [GOGOL/29, PARSE/22] LDE (28-Jun-74)
Under NOSTANFO, when printing error messages, translate
under-bar into "!" and not-equals into "#". This is much
better for non-stanford terminals (although could be
made more general).
=C4= [IOSER/6,7] LDE (28-Jun-74)
Allow null PPN within [] and allow nulls within PPNs, in
FILNAM. (The second occurs frequently at CMU since CVSTRs
are often done on PPNs.)
=C5= [IOSER/9] LDE (28-Jun-74)
Allow lower-case "r" response when device not available in OPEN.
=C6= [GOGOL/31] LDe (28-Jun-74)
Allow lower-case file names when specifying an "E" response
in an error message.
∂25-JUN-74 0124 THE,JRL
Ralph has complained about the fact that SAIL does not reduce
CORE size between compilations.
Also when we have $PDLOV cause an pdlov there is no indication
as to which stack really overflowed. E. g in procedure entry
sequence.
Add p,[xwd mumble, mumble]
skipl p
jsp 15,$pdlov
$pdlov causes an overflow with 14 as stack pointer. User gets
no indication that problem was really with p.
∂24-MAY-74 1125 NET,GUE AT TTY122 : C.BACON @ network site NBST
SAIL COMPILER BUG:
THE FOLLOWING SEQUENCE--
BP ← POINT (6, FOO, -1);
FOO ← GEORGE;
IDPB (0, BP);
GEORGE ← FOO;
-- RESULTS IN NO APPARENT CHAGE TO FOO OR GEORGE.
REASON SEEMS TO BE THAT SAIL 'KNOWS' THAT FOO IS STILL COPIED
IN AN AC, AND DOESN'T NEED TO MOVE AC,FOO BEFORE MOVEM'ING.
OH, WELL, I CAN ALWAYS GET AROUND IT.
FROM C. BACON, N.I.H. DCRT. BETHESDA, MD. INITIALS CRB.
∂25-MAY-74 1000 1,RS
RUSSELL,
On your desk I have left a listing of SAILOW.SRC.
it shows the effects of what we did. As far as I can tell,
all of the globals that are linked to from the user's program
are ok. P.S. What happens when users declare things EXTERNAL
and link to them when they are not in the HERE table -- it
is just the user's own fault for being so dump??
bob
∂01-MAY-74 0221 1,JMG
I seem to get "DRYROT AT EFORM" and cure it without any seeming rationality.
If this is of further interest, mail me a mssg and I'll point to the file.
- jmg.
∂29-APR-74 1244 network site CMU
***** FTP mail from [A700SA00] (SAIL)
CMU bug report =B8=. LDE 29-Apr-74
Bug fix #RN is not complete -- see short file
PROTAC.SAI[CMU,AIL] or [A700SA00] for a test case.
It complains about protecting AC's again.
∂24-MAR-74 0940 network site CMU
***** FTP mail from [A700SA00] (SAIL)
CMU bug report =B5=. LDE 24-Mar-74.
Can get "illegal real constant" errors inside an IFCR FALSE
with a construction like "..". See IFCRBG.SAI[CMU,AIL].
∂19-MAR-74 1125 network site CMU
***** FTP mail from [A700SA00] (SAIL)
00100 RUSS AND OTHERS,
00200 WHAT IS THE STORY WITH "A" AS AN ERROR RESPONSE THE CODE
00300 LOOKS LIKE IT MEANT TO INCLUDE "A", BUT THERE IS A CAILE A,15 THAT
00400 ONLY LETS LINEFEEDS THROUGH (GOGOL 7400/27). USING "A" HERE SETS
00500 THINGS UP SO THAT ONE GETS THE EFFECT OF LINEFEED, BUT ONLY AFTER
00600 BEING COMPLAINED AT, AND HAVING TO TYPE SOMETHING ELSE BACK FIRST.
00700 WHAT'S THE CASE THERE?
00800 PADDY
∂15-MAR-74 1654 network site MAXC
Date: 15 MAR 1974 1656-PDT
From: SPROULL at PARC-MAXC
Subject: Another SAIL bug
- - - -
I have just received information from NIH to the effect that SAIL
crashes the new release of 5.07/6.01 (DEC system). The rason,
it appears, is that the first few locations of the high segment
(the vestigial job data area) are all -1. Glenn Ricart reports
that making them '0' (i.e. the first 8 locations in the high seg)
cures the problem altogether.
I think this should be put in.
bob
-------
∂15-MAR-74 1652 network site MAXC
Date: 15 MAR 1974 1654-PDT
From: SPROULL at PARC-MAXC
Subject: SAIL BUG
- - - -
The following program fucks up looking for a global value.
The problem is that the 'move 2,1(2)' at d+2 should be
(I think....) a 'move 2,(2)' to look back up the stack.
See what you think.
00100 begin "bug"
00200 procedure a(integer i;reference procedure p);
00300 p(i);
00400
00500 procedure t(integer i);
00600 begin procedure d(reference integer i);
00700 outstr("i="&cvs(i));
00800
00900 a(i,d);
01000 end;
01100
01200 t(22);
01300 end
By the way, I would appreciate acknowledgement of my bug reports
so that II know that they have been received.
Good luck.
Bob
-------
∂11-MAR-74 1957 network site CMU
***** FTP mail from [A700SA00] (SAIL)
Continuing bug report. CMU LDE 11-Mar-74
There is still a problem with expanding string space in
the compiler. Unfortunately, we only seem to get it in our
humongous HEARSAYII compilations, which use about 20 or 25
different source files. Our compiler has all the purported bug
fixes for this -- in fact we brought over a complete set of
source files from S,AIL within the last two weeks. If we find
a more compact program that pokes at it, we'll ship it over
and let you know. If someone there gets ambitious and wants to
poke at our thing over the net, we will be glad to give assistance.
I suspect that DCS has some ideas on what the problem might be
(see his message along with a bug that he set up for it -- about
QF, I think).
cheers,
∂06-MAR-74 1144 CMU,AIL
How much of feats if honest? Specifically, %AG, which is in the files, but
has no OK, and isn't in the documentation.
PB01
∂5-MAR-74 1040 network site CMU
CMU BUG REPORT, WITH FIX. LDE=B2= [GOGOL/46] LE03 5-Mar-74
In STRNGC, when releasing old string spaces, DCS was accessing
the header of the space after he released it (with a CORREL) --
this caused ILL MEM REF when the core happened to have really
gone away. Fix required no more code.
RELLUP: MOVEI B,-.HDRSIZ(A) ;Release any spaces which are
;;=B2= LDE CMU 5-MAR-74 BETTER NOT ACCESS IT AFTER IT GOES AWAY
; PUSHJ P,CORREL ; apparently no longer necessary.
; SKIPE A,.NEXT(A)
; JRST RELLUP
MOVE A,.NEXT(A)
PUSHJ P,CORREL
JUMPN A,RELLUP
;;=B2=
∂05-MAR-74 0804 CMU,AIL
PEOPLE:
IF YOU ARE BRINGING OR HAVE BROUGHT UP A SAIL MANUAL UPDATE, I
WOULD APPRECIATE KNOWING ABOUT, AS I AM DOING THE SAME. SEND MAIL TO
BANWELL OR SAIL ON THE CMU/B.
PB01
∂25-FEB-74 1525 R,AJT
HOW ABOUT A BETTER ERROR MSG FOR "APPLY(ITM,LST)"
(NEED DATUM(ITM) HERE). RHT
∂22-FEB-74 1034 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.
∂05-FEB-74 1412 THE,RHT
REG SENT ME SOME BUGS IN THE MANUAL. THE MESSAGES WERE SENT TO MSGLOG[S,AIL]
∂5-FEB-74 0816 network site CMU
CMU Sail bug report (low priority) =A6= LDE 5-Feb-74
A NEEDNEXT block with no NEXT in it gets a dryrot at FBOUT.
(Joe Newcomer bug.)
∂29-JAN-74 0746 CMU,AIL
THE FIX FOR CMU =A1= IS:
XWD NOLINS,LCASE ;N,,F
IN PLACE OF WHAT IS NOW 3000/25 IN IOSER, AND
LCASE: MOVSS B
ANDCAM B,BRKCVT(USER)
JRST RESTR
AFTER UCASE, AT THE END OF /25 IN IOSER. PADDY
∂28-JAN-74 1539 network site CMU
***** FTP mail from [A700SA00] (SAIL)
00100 BUGS IN IOSER
00200 =A1=: ONCE TURNED ON, UPPER CASE CONVERSION CAN'T BE TURNED
00300 OFF. USE OF LCASE GIVES AN ERROR MESSAGE OF UNDEFINED. THIS IS ON
00400 PAGE 26 OF IOSER.
00500 =A5=: WHEN SIMIO INDICES WERE CHANGED BACK TO THEIR OLD
00600 ORDER, THE USBTST TABLE WAS NO LONGER CORRECT. OUR FIX WAS TO ADD
00700 A DUMMY WORD BETWEEN THE TWO ENTRIES. LE03 & PB01
00800
λ