Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_3_19910112
-
midas/bug.mail
There are no other files named bug.mail in the archive.
6-Apr-85 17:27:21-PST,569;000000000000
Return-Path: <@MIT-MC:GUMBY@MIT-MC>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Sat 6 Apr 85 17:27:17-PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 6 APR 85 20:28:49 EST
Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Apr 85 20:28-EST
Date: Sat, 6 Apr 85 20:28:10 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject: should midas kill itself
To: bug-midas@MIT-OZ
Message-ID: <[MIT-MC].445177.850406202842.GUMBY>
Would anyone complain if I changed twenex midas to kill itself off when
done if invoked with jcl? I like this behaviour on ITS.
7-Apr-85 13:47:05-PST,974;000000000000
Return-Path: <@MIT-MC:MRC@SU-SCORE>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Sun 7 Apr 85 13:47:01-PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:48:31 EST
Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:47-EST
Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:48:10 EST
Date: Sun 7 Apr 85 13:47:38-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: should midas kill itself
To: GUMBY@MIT-MC.ARPA
cc: bug-midas%MIT-OZ@MIT-XX.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" of Sun 7 Apr 85 01:22:08-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
What do you mean "kill itself off when done"? If you mean to RSCAN%
back a RESET command a number of people will be quite pissed, since
very often MIDAS is run ephemerally or (in my environment) from a PCL
command file. That RSCAN%'ing hack causes some other fork to be smashed!
-------
7-Apr-85 13:54:41-PST,936;000000000000
Return-Path: <@MIT-MC:MRC@SU-SCORE>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Sun 7 Apr 85 13:54:38-PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 16:55:03 EST
Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 16:54-EST
Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 7 APR 85 16:49:34 EST
Date: Sun 7 Apr 85 13:49:00-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: should midas kill itself
To: GUMBY@MIT-MC.ARPA
cc: bug-midas%MIT-OZ@MIT-XX.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" of Sun 7 Apr 85 01:22:08-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Why don't you write a PCL procedure to invoke MIDAS. You can even get it
to grok filename completion that way. There is also the SET PROGRAM EPHEMERAL
feature. Let's not have any more programs which magically RSCAN% stuff
back to the EXEC.
-------
7-Apr-85 18:03:29-PST,1572;000000000000
Return-Path: <@MIT-MC:GUMBY@MIT-MC>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Sun 7 Apr 85 18:03:24-PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 APR 85 21:04:43 EST
Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Apr 85 21:04-EST
Date: Sun, 7 Apr 85 21:04:10 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject: should midas kill itself
To: MRC@SU-SCORE
cc: bug-midas@MIT-OZ
In-reply-to: Msg of Sun 7 Apr 85 13:49:00-PST from Mark Crispin <MRC at SU-SCORE.ARPA>
Message-ID: <[MIT-MC].446043.850407210413.GUMBY>
Date: Sun 7 Apr 85 13:47:38-PST
From: Mark Crispin <MRC at SCORE>
What do you mean "kill itself off when done"? If you mean to RSCAN%
back a RESET command a number of people will be quite pissed, since
very often MIDAS is run ephemerally or (in my environment) from a PCL
command file. That RSCAN%'ing hack causes some other fork to be smashed!
Date: Sun 7 Apr 85 13:49:00-PST
From: Mark Crispin <MRC at SCORE>
Why don't you write a PCL procedure to invoke MIDAS. You can even get
it to grok filename completion that way. There is also the SET PROGRAM
EPHEMERAL feature. Let's not have any more programs which magically
RSCAN% stuff back to the EXEC.
VALRET (i.e. RSCAN%) is bogus. So is PCL. What's wrong with using PRARG
(the TNX equivalent of .BREAK)? Those systems whose execs ignore it won't
notice; the MIT-exec at least will do the right thing.
Setting it ephemeral is NOT the right thing! What if the compilation
terminates abnormally?
7-Apr-85 21:19:39-PST,1715;000000000000
Return-Path: <@MIT-MC:MRC@SU-SCORE>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Sun 7 Apr 85 21:19:33-PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 8 APR 85 00:20:56 EST
Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Apr 85 00:20-EST
Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 8 APR 85 00:20:26 EST
Date: Sun 7 Apr 85 21:19:51-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: should midas kill itself
To: GUMBY@MIT-MC.ARPA
cc: bug-midas%MIT-OZ@MIT-XX.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" of Sun 7 Apr 85 18:06:54-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Okay, at least you are talking about PRARG% instead of
RSCAN%. I still remember the day I did a SEND on OZ and found
that some wonderful (sic) person had "improved" SEND to RSCAN%
out a RESET...since my environment ran it ephemerally it reset my
EMACS. That was the last day I tried to do anything serious on
OZ...
Re: "PCL is bogus". The implementation is bogus, but
certainly something of that functionality is needed. Or are you
happy only when you are modifying the internals of the operating
system and command decoder?
You needn't tell me "VALRET is bogus". I remember when on
ITS that was the only way to communicate between a program and
DDT. .BREAK <n> (I forget the value of n) was an improvement,
but it was still bogus. I bugged RMS for something better, and
one day .LOGOUT 1, appeared...
"What if the compilation terminates abnormally?"...well I
don't see how the MIDAS fork is useful, unless you mean MIDAS
blowing up. I didn't think MIDAS did that any more.
-------
8-Apr-85 13:35:03-PST,777;000000000000
Return-Path: <KLH@MIT-MC>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Mon 8 Apr 85 13:34:58-PST
Date: Mon, 8 Apr 85 16:36:02 EST
From: Ken Harrenstien <KLH@MIT-MC>
Subject: should midas kill itself
To: GUMBY@MIT-MC
cc: BUG-MIDAS@MIT-MC
Message-ID: <[MIT-MC].447245.850408163630.KLH>
If there is some safe way of making this happen, I suppose it is all
right. The problem is that I have never seen any documentation which
explains the standard conventions for using PRARG%. I tried to find this once,
so I could make MIDAS work with COMPILE-class commands, but gave up;
that is one of the most obscure pieces of mumbo-jumbo I have
encountered in quite a while. Now you are talking about PRARG% in the
OTHER direction too? Argh... give me a .break....
9-Apr-85 23:15:50-PST,1059;000000000000
Return-Path: <GUMBY@MIT-MC>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Tue 9 Apr 85 23:15:34-PST
Date: Wed,10 Apr 85 01:56:35 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject: should midas kill itself
To: KLH@MIT-MC
cc: BUG-MIDAS@MIT-MC
In-reply-to: Msg of Mon 8 Apr 85 16:36:02 EST from Ken Harrenstien <KLH>
Message-ID: <[MIT-MC].449503.850410.GUMBY>
Date: Mon, 8 Apr 85 16:36:02 EST
From: Ken Harrenstien <KLH>
If there is some safe way of making this happen, I suppose it is all
right. The problem is that I have never seen any documentation which
explains the standard conventions for using PRARG%. I tried to find this once,
so I could make MIDAS work with COMPILE-class commands, but gave up;
that is one of the most obscure pieces of mumbo-jumbo I have
encountered in quite a while. Now you are talking about PRARG% in the
OTHER direction too? Argh... give me a .break....
I don't see what the hassle is for that...the COMPILE commands just RSCAN%
the filename to MIDAS?
9-Apr-85 23:51:26-PST,733;000000000000
Return-Path: <@MIT-MC:MRC@SU-SCORE.ARPA>
Received: from MIT-MC by SRI-NIC.ARPA with TCP; Tue 9 Apr 85 23:51:23-PST
Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 10 APR 85 02:48:11 EST
Date: Tue 9 Apr 85 23:31:50-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: should midas kill itself
To: GUMBY@MIT-MC.ARPA
cc: KLH@MIT-MC.ARPA, BUG-MIDAS@MIT-MC.ARPA
In-Reply-To: Message from "David Vinayak Wallace <GUMBY@MIT-MC>" of Tue 9 Apr 85 23:18:20-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
No, the COMPILE commands do not RSCAN% the filename to MIDAS. They use
PRARG% which for TOPS-10 compilers is used by PA1050's support of the
TOPS-20 TMPCOR UUO.
-------
1-Jun-85 15:48:33-PDT,600;000000000000
Return-Path: <@MIT-MC.ARPA:Gumby@MIT-MC.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Sat 1 Jun 85 15:48:30-PDT
Received: from MIT-JIMI by MIT-MC via Chaosnet; 1 JUN 85 18:49:39 EDT
Date: Sat, 1 Jun 85 18:48 EDT
From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
Subject: new midas for twenex
To: info-midas@MIT-MC.ARPA
Message-ID: <850601184814.1.GUMBY@JIMI>
Twenex Midas now kills itself (via PRARG) when done. I think this will
only affect MIT users, but if any other site's exec recognises the same
PRARG options, ftp the file oz:ss:<sys.midas>TSRTNS.MID.232.
david
18-Jun-85 21:33:09-PDT,1208;000000000000
Return-Path: <CSTACY@MIT-MC.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Tue 18 Jun 85 21:33:03-PDT
Date: Wed, 19 Jun 85 00:33:28 EDT
From: Christopher C. Stacy <CSTACY@MIT-MC.ARPA>
Subject: system bits
To: BUG-MIDAS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].549329.850619.CSTACY>
I was writing an init file for someone today and I wanted to make use
the the ITS bit named %TYRLM. The bit is defined in SYSTEM;BITS but
DDT did not know about it. DDT does not appear to explicitly include
the BITS, so I assume it guess it gets its system symbols from MIDAS.
MIDAS did not know about my bit either, and there seem to have been
many changes to MIDAS lately, so I went to assemble a new MIDAS.
I found and fixed two trivial MIDAS bugs in the TSRTNS module.
The CORGET routine had an ill-formed system call, and the CMD routine
was confused about JCL handling. I did not audit the numerous changes
which have been made, and did NOT install MIDAS 458, which at least
seems to work now.
However, the %TYRLM bit is still not known to MIDAS (or a TS DDT
assembled by same). I am not familiar with MIDAS at all.
What do I need to do to get this bit known by MIDAS?
19-Jun-85 19:40:58-PDT,755;000000000000
Return-Path: <@MIT-MC.ARPA:MRC@SIMTEL20.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Wed 19 Jun 85 19:40:54-PDT
Received: from SIMTEL20.ARPA by MIT-MC.ARPA 19 Jun 85 21:20:35 EST
Date: Wed 19 Jun 85 06:51:18-MDT
From: Mark Crispin <MRC@SIMTEL20.ARPA>
Subject: Re: system bits
To: CSTACY@MIT-MC.ARPA
cc: BUG-MIDAS@MIT-MC.ARPA
In-Reply-To: Message from "Christopher C. Stacy <CSTACY@MIT-MC.ARPA>" of Tue 18 Jun 85 22:37:21-MDT
I was under the (perhaps mistaken) impression that system definitions
are snarfed from the operating system, which would imply that you
would need to install a new version of ITS. At least that's the way
FAIL on WAITS gets UUO definitions, and I thought MIDAS on ITS worked
the same way.
-------
5-Aug-85 09:51:03-PDT,958;000000000000
Return-Path: <@MIT-MC.ARPA:budne%mrfort.DEC@decwrl.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Mon 5 Aug 85 09:50:50-PDT
Received: from decwrl.ARPA by MIT-MC.ARPA 4 Aug 85 18:36:09 EDT
Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34)
id AA03542; Sun, 4 Aug 85 15:36:11 pdt
Message-Id: <8508042236.AA03542@decwrl.ARPA>
Date: Sunday, 4 Aug 1985 15:35:23-PDT
From: budne%mrfort.DEC@decwrl.ARPA (Phil Budne)
To: bug-midas@mit-mc.ARPA
Subject: New program CVTUUO
----- Delivered by TOPS-20 Message Services ---
Date: 4 Aug 1985 1830-EDT
From: Phil Budne <BUDNE at MRFORT>
To: """bug-midas@mit-mc.arpa""" at DECWRL
Subject: New program CVTUUO
Message-ID: <"MS11(2411)+GLXLIB5(0)" 12132532256.137.48.52511 at MRFORT>
MC: GUEST0; BUDD CVTUUO contains a version of MRC's CVT program
that runs under TOPS-10, and sucks in UNV:UUOSYM.UNV and UNV:MACTEN.UNV
to produce DECDFS.MID.
-Phil Budne
--------
18-Oct-85 04:47:48-PDT,1679;000000000000
Return-Path: <@MIT-MC.ARPA:KLH@SRI-NIC.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 04:47:39-PDT
Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT
Date: Fri 18 Oct 85 03:51:31-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: * and & in macro defs
To: bug-midas@MIT-MC.ARPA
Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA>
There is a possible bug in the way * and & (and perhaps other such
switches) are implemented, or at least in the way they are documented.
One is given the impression that there are several orthogonal attributes
an argument can have, and that once you turn on a certain attribute, that
applies to all following arguments until explicitly turned off again.
However, it appears that for some (most?) cases the "turn-off" switch actually
does a global reset back to type "normal" instead of merely turning off
its specific attribute. I found this when trying to figure out why
a macro definition of this form
DEFINE FOO ?BAR,&STR&,ETC,ETC2
resulted in ETC and ETC2 being normal-syntax instead of balanced.
Really screws one up when FOO is invoked as a parenthesized call with
2 args! During the debug process I stared at the documentation
several times without catching on.
MIDAS macro syntax is so baroque that it would probably be handy to
have a pseudo-op like .DEFINE which acted like DEFINE but which also
generated, in the listing output, a readable description of its
arguments so that you know exactly what MIDAS thinks you did.
.DEFINE'd macros could also have additional helpful listing output
when being expanded. Oh well, who's going to bother anyway.
-------
18-Oct-85 04:49:23-PDT,1679;000000000000
Return-Path: <@MIT-MC.ARPA:KLH@SRI-NIC.ARPA>
Received: from MIT-MC.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 04:49:17-PDT
Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Oct 85 06:49:06 EDT
Date: Fri 18 Oct 85 03:51:31-PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: * and & in macro defs
To: bug-midas@MIT-MC.ARPA
Message-ID: <12152065869.17.KLH@SRI-NIC.ARPA>
There is a possible bug in the way * and & (and perhaps other such
switches) are implemented, or at least in the way they are documented.
One is given the impression that there are several orthogonal attributes
an argument can have, and that once you turn on a certain attribute, that
applies to all following arguments until explicitly turned off again.
However, it appears that for some (most?) cases the "turn-off" switch actually
does a global reset back to type "normal" instead of merely turning off
its specific attribute. I found this when trying to figure out why
a macro definition of this form
DEFINE FOO ?BAR,&STR&,ETC,ETC2
resulted in ETC and ETC2 being normal-syntax instead of balanced.
Really screws one up when FOO is invoked as a parenthesized call with
2 args! During the debug process I stared at the documentation
several times without catching on.
MIDAS macro syntax is so baroque that it would probably be handy to
have a pseudo-op like .DEFINE which acted like DEFINE but which also
generated, in the listing output, a readable description of its
arguments so that you know exactly what MIDAS thinks you did.
.DEFINE'd macros could also have additional helpful listing output
when being expanded. Oh well, who's going to bother anyway.
-------
12-Jun-87 22:10:08-PDT,760;000000000000
Return-Path: <@AI.AI.MIT.EDU:SRA@XX.LCS.MIT.EDU>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 12 Jun 87 22:10:02-PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 13 Jun 87 01:09:13 EDT
Date: Sat, 13 Jun 1987 01:06 EDT
Message-ID: <SRA.12310075961.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Bug-MIDAS@AI.AI.MIT.EDU
Subject: TSRTNS.MID.233 (20X @COMPILE command support)
I added support for the crufty PRARG%/TMPCOR CCL kludge to MIDAS, so
that @COMPILE will work right on MIDAS files on Twenex. I installed
TSRTNS.MID.233 on XX, OZ, and AI, installed new MIDAS.EXE on XX only.
Support for MIDAS has been in the Stanford EXEC for ages, I just added
it to the MIT EXEC as of version MIT160.