From AGRE Sat Mar 29 00:00:00 1980
From: AGRE (Philip E. Agre)
Date: 29 MAR 1980, 00:00
Subject: No subject
Message-ID:
I think that the "excessive tourist usage may lead to a restricted policy"
clause in the MIT-AI ITS login message sounds like a very unfriendly threat.
I don't think that we have made sufficient efforts yet to explain to
tourists exactly what the state of the world is and what is the behavior
that is expected of members of the MIT-AI community. Such explanations
should be made, and individuals who refuse to cooperate with us should
be singled out for threats rather than just threatening hundreds of our
guests for the misdeeds of a few. (And there ought to be more to this than
an occasional flame by someone who has discovered a new form of tourist
ignorance or misbehavior.) - Phil
From JERRYB Fri Mar 28 00:00:00 1980
From: JERRYB (Gerald R. Barber)
Date: 28 MAR 1980, 00:00
Subject: No subject
Message-ID:
What happened to fido? I hope he didn't die of old age.
From KLH Wed Mar 26 00:00:00 1980
From: KLH (Ken Harrenstien)
Date: 26 MAR 1980, 00:00
Subject: No subject
Message-ID:
SYSMSG should show more stuff. Nowadays things happen so
fast (logins/outs) that if, e.g. my net connection breaks,
by the time I get back 2 minutes later (yes two minutes)
any evidence as to the nature of the lossage has long vanished
from the minor fragments SYSMSG knows about. Foo.
From MOON Tue Mar 25 00:00:00 1980
From: MOON (David A. Moon)
Date: 25 MAR 1980, 00:00
Subject: DIRHNG:
Message-ID:
Date: 25 Mar 1980 1118-EST
From: EBM at MIT-XX
Subject: DIRHNG:
To: bug-its at MIT-AI
I believe that creating new links in a directory should also result
in an interrupt on the channel open to the DIRHNG: device.
It does.
[Also,
I have always believed that one should be able to read the device,
which will result in hanging until a file is closed. The data
returned could be garbage, or 0 -- it does not matter. The point
is that one should not be REQUIRED to use interrupts for such
things if they are unnecessary.]
Maybe, but interrupts are trivial to use.
Having a piece of documentation
available on DIRHNG: would be nice, too. E.g., :call open, or
something.
Yes, it should be.
From EBM Tue Mar 25 00:00:00 1980
From: EBM (EBM)
Date: 25 Mar 1980, 00:00
Subject: DIRHNG:
Message-ID:
I believe that creating new links in a directory should also result
in an interrupt on the channel open to the DIRHNG: device. [Also,
I have always believed that one should be able to read the device,
which will result in hanging until a file is closed. The data
returned could be garbage, or 0 -- it does not matter. The point
is that one should not be REQUIRED to use interrupts for such
things if they are unnecessary.] Having a piece of documentation
available on DIRHNG: would be nice, too. E.g., :call open, or
something.
-------
From agre Mon Mar 24 00:00:00 1980
From: agre (Philip E. Agre)
Date: 24 MAR 1980, 00:00
Subject: No subject
Message-ID:
How about a program that asks all tourists to log out?
From AGRE Mon Mar 24 00:00:00 1980
From: AGRE (Philip E. Agre)
Date: 24 MAR 1980, 00:00
Subject: No subject
Message-ID:
Is there a program that says "change working directory to my home directory"?
From GLSatMIT-AI Mon Mar 24 00:00:00 1980
From: GLSatMIT-AI (Guy L. Steele, Jr.)
Date: 24 March 1980, 00:00
Subject: Comma in ^O filespec loses!!
Message-ID:
It is semi-well-known that a comma ends a filespec in DDT, as does
a CR; CR in addition ends the command. Consider :RENAME, for example;
if you type :RENAME FOO GREPS,BARF GREPS the comma terminates
the first file name and the second altmode redisplays the second
file name. This is actually useful. However, had one used
instead of :RENAME (), then the comma terminates the
command, but the command doesn't "run" until the second altmode
is typed. Moreover, any stuff after the comma is lost -- the second altmode
doesn't redisplay it or anything. Maybe for safety's sake the number
of commas should be counted and a complaint registered if there are
too many. Also, typing an altmode should NEVER cause the command to be run!
The whole point is to be able to see the name of the file you are
about to dastardly mung.
From KLH Fri Mar 21 00:00:00 1980
From: KLH (Ken Harrenstien)
Date: 21 MAR 1980, 00:00
Subject: Comma in ^O filespec loses!!
Message-ID:
Goddamit, I did an ^O and it said that it was about to
delete ".FOO X". I typed in ",FOO X" which was what
i really wanted to delete (the comma was mis-typed in an append
command), and the '"'$)#$)"#%#("$'$ went ahead and screwed me
by flushing the original ".FOO X" file!!!! Snarrrl!!
Just what meaning is a comma supposed to have in a delete
command anyway??? The FN1 wasn't changed at all....
you'd at least have expected it to try deleting "FOO X".
From RICH Thu Mar 20 00:00:00 1980
From: RICH (Charles Rich)
Date: 20 MAR 1980, 00:00
Subject: Device Handling
Message-ID:
Ok, with the help of your replies I think I understand the
problem: the various machines do not recognize THEMSELVES
as a valid device combined with ARn in the same way as
other machines. This makes it much less convenient to write
code which will run on any machine.
For example, on AI
:LISTF AIAR3:RICH;
doesn't work, but on other machines it does.
Ed, you are right, the extra colon was never right;
the form
:LISTF AI:AR3:RICH;
only worked on AI because the first AI: was thrown away.
I now think we have now narrowed this down to an
honest-to-goodness bug.
Thanks, Chuck.
From EDatMIT-AI Thu Mar 20 00:00:00 1980
From: EDatMIT-AI (Ed Schwalenberg)
Date: 20 March 1980, 00:00
Subject: Device Handling
Message-ID:
On AI you type
:LISTF ML:ARn:UNAME;
I can' believe that this ever worked, or could work. It certainly
does not work now.
:LISTF MLARn:UNAME;
This has always been the form recognized by ITS. The unknown device
handler checks to see if the first 2 chars are a machine name, and hands
the rest of the device name to that machine. Inserting an extra : will
cause most filename readers to ignore the ML: by clobbering the device
field with ARn:. The exception is :FIND, which makes a LIST of all
devices (and directories) to be searched. Is it possible you were led
down the garden path by having similar archives on 2 machines? Experiment
with the MLTTY: device and you will see that MLTTY: gives you ML's, ML:TTY:
gives you AI's (TTY:) and TTYML: gives you NO SUCH DEVICE (the FIRST 2 chars
must be the machine name.
From RICH Wed Mar 19 00:00:00 1980
From: RICH (Charles Rich)
Date: 19 MAR 1980, 00:00
Subject: Device Handling
Message-ID:
On AI you type
:LISTF ML:ARn:UNAME;
to refer to an archive on another machine, but
on DM you type it without the extra colon, i.e.
:LISTF MLARn:UNAME;
to get the same effect. The alternative form on
either machine loses. Sigh... it would be nice
if it were compatible, no?
From EDatMIT-AI Mon Mar 17 00:00:00 1980
From: EDatMIT-AI (Ed Schwalenberg)
Date: 17 March 1980, 00:00
Subject: No subject
Message-ID:
Date: 17 MAR 1980 1509-EST
From: AGRE at MIT-AI (Philip E. Agre)
Sent-by: SHADOW at MIT-AI
I did agrectl-s then :xfile agre;agre login on shadow's terminal,
so I could read my mail without logging shadow out. It did all the
gmsgs's right, but when it finally called :rmail, it did it on shadow's
mail file. agrectl-s :rmail works right, so I suspect that
the agrectl-s wasn't able to distribute over the whole :xfile
execution. This led to a rather embarrasing error. Can it be fixed,
or is it a feature? - Phil
>From DDT ORDER:
$^S
causes the next ^K, ^H or :-command, if it runs a program, to
run it "as if were running it". Precisely, its .XUNAME
variable will be instead of you and its .HSNAME will be set to
's HSNAME. If the program follows the current convention, it
will use 's init file, etc. $^S works by setting the ..TUNAME
and ..THSNAME variables.
Since your XFILE runs 2 programs, you lose.
From AGRE Mon Mar 17 00:00:00 1980
From: AGRE (Philip E. Agre)
Date: 17 MAR 1980, 00:00
Subject: No subject
Message-ID:
I did agrectl-s then :xfile agre;agre login on shadow's terminal,
so I could read my mail without logging shadow out. It did all the
gmsgs's right, but when it finally called :rmail, it did it on shadow's
mail file. agrectl-s :rmail works right, so I suspect that
the agrectl-s wasn't able to distribute over the whole :xfile
execution. This led to a rather embarrasing error. Can it be fixed,
or is it a feature? - Phil
From KLH Sat Mar 15 00:00:00 1980
From: KLH (Ken Harrenstien)
Date: 15 MAR 1980, 00:00
Subject: No subject
Message-ID:
Date: 9 February 1980 13:00-EST
From: Earl A. Killian
How about changing the definition of %TDICP n from being "insert
n blanks in the current line" to being "insert next n characters
in the current line"? I suspect that no programs would have to
change (i.e. TECO wouldn't). The reason for the chnage would be
to allow insertion to happen more reasonably on some terminals
(in particular those with an insert character mode), without
making it any less efficient for terminals like TVs or the
Teleray. CRTSTY would make use of the new constraint on what can
follow a %TDICP, and maybe ITS could too.
I don't think it would be a good idea to change the %TDICP definition.
The idea is certainly clever, but I am paranoid about what could
happen if the output stream was interrupted or otherwise disrupted
while counting down these N characters, since this is also in effect
quoting the next N characters. It seems much more robust to have a
way to enter insert-char mode and leave it; then a reset of this mode
would always be effective. It would also be just as efficient, since
a %TDICP N is two characters plus the string, whereas a %TDSIC and
%TDEIC (Start & End insert-char mode) is also just two chars plus the
string. I don't see anything wrong with having more %TD codes, except
that a TTYOPT bit might be needed to say whether the terminal could
handle it or not; if not, ITS would just simulate it with %TDICP's.
From MOON at MIT-MC Fri Mar 14 00:00:00 1980
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 14 Mar 1980 00:00
Subject: Your bug report about translations
Message-ID:
Presumably the underlying cause is that translations don't affect the
RENMWO system call. It is not obvious that they should, or what would
be a consistent way of doing so. Fortunately translations are mainly
useful for devices and directories rather than file names.
From KLH at MIT-MC Fri Mar 14 00:00:00 1980
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 14 Mar 1980 00:00
Subject: No subject
Message-ID:
I think someone has barfed about this before, but...
Is it really the right thing to turn foo < into foo >
when writing??
From TURNIP at MIT-MC Fri Mar 14 00:00:00 1980
From: TURNIP at MIT-MC (TURNIP at MIT-MC)
Date: 14 Mar 1980 00:00
Subject: No subject
Message-ID:
Sigh. This 'feature' of writing to a temp file turns out to affect GMSGS
for ECC ... We were just trying to isolate simpler cases, but the original
('real') attempt was to get GMSGS to output to a different file than
xuname MAIL ... Its writing to a temp file and then Rename-While-Opening
without checking translations is what prompted all this I guess.
From ED at MIT-AI Fri Mar 14 00:00:00 1980
From: ED at MIT-AI (ED at MIT-AI)
Date: 14 Mar 1980 00:00
Subject: No subject
Message-ID:
Both TECO and DDT are too smart for their own good, sometimes.
The file OPENed in both cases (and thus subject to translations)
is KMP;_TECO_ OUTPUT (or _COPY_ for DDT.). When the file is completely
written, it is RENMWOed to FOO BAR, which operation is NOT subject
to translation.
There is a teco command to write output directly without renaming,
search for "core link" in TECO ORDER for suggestions.
From KMP at MIT-MC Fri Mar 14 00:00:00 1980
From: KMP at MIT-MC (KMP at MIT-MC)
Date: 14 Mar 1980 00:00
Subject: No subject
Message-ID:
Doing KMP;FOO BAR,KMP;BAR FOO on MC and then :CREATE'ing KMP;FOO BAR
still creates the file FOO BAR. :COPY TTY:, ... gives similar results
so I doubt this is a Teco problem. When I try to read the file, I get
a file not found error because an input translation has been created but
not an output translation... o ... produces the same results. In the
former case, PEEK shows that there exists an IO translation. In the latter,
it says there is just an output translation -- but in neither does it
keep from writing to FOO BAR as a truename as it should. Can someone please
fix this or tell me why I am misunderstanding what output translations
are capable of? Thanks.
-kmp
From JERRYB Thu Mar 13 00:00:00 1980
From: JERRYB (Gerald R. Barber)
Date: 13 MAR 1980, 00:00
Subject: No subject
Message-ID:
One outcome of the disk storage crunch getting worse and worse is that there
will be more randoms deleting random files.
It seem like a program that would combine the facilities of COMMON;FIND JUNK
and DIRED would be useful. In addition, it would keep track of what files
were deleted and who deleted them. In this way people would be less tempted
to do rash deletions. It might do other things such as refusing
to delete files that have not been backed up, files that are > versions and
files where the file name is of a specific structure etc.
From EB Tue Mar 11 00:00:00 1980
From: EB (Edward Barton)
Date: 11 MAR 1980, 00:00
Subject: No subject
Message-ID:
Why does :COPYing to other machines so often hang up doing
an SAUTH ? That has happened about five times today.
From ___036 at MIT-MC Thu Mar 6 00:00:00 1980
From: ___036 at MIT-MC (___036 at MIT-MC)
Date: 06 Mar 1980 00:00
Subject: TTY hangage
Message-ID:
I don't know if anybody cares, but it's possible to wedge a TTY completely
by doing :SPRT EJS;STYOUT DEBUG on MC. This outputs a random asii file
as 8-bit codes. I don't know if the TTY code claims not to wedge TTY's
in the case of garbage super-image output, but if it does, here's a
counter-example.
From gls Tue Mar 4 00:00:00 1980
From: gls (Guy L. Steele, Jr.)
Date: 4 MAR 1980, 00:00
Subject: No subject
Message-ID:
Last note from RICH was really from GLS.
From RICH Tue Mar 4 00:00:00 1980
From: RICH (Charles Rich)
Date: 4 MAR 1980, 00:00
Subject: No subject
Message-ID:
One obvious application of the Greek/Front key on the PDP-10
is that all such characters could be self-inserting in TEX format;
thus typing would insert "\alpha", etc. I don't know how much
more convenient this would make it to type weird formulas in TEX.
From MOON Mon Mar 3 00:00:00 1980
From: MOON (David A. Moon)
Date: 3 MAR 1980, 00:00
Subject: Use of New Keyboards with ITS.
Message-ID:
I don't think ITS is going to be able to accomodate all of the new
modifier bits. There are no free bits in the present internal
(18-bit) character code. I don't think making Greek input work
is very important, since we certainly aren't going to go to the
very large amount of trouble required to make Greek output work
and have a more-than-7-bit printing-character set.
It would be nice to make Super and Hyper work to ITS, although there
are not enough bits available. Note that shift-lock has already been
recycled. Shift is sort of recycled and sort of vestigially still
there; it could be recycled for this. It isn't necessary to be able to
represent all 16 combinations of the "bucky bits"; for instance there
are 8 combinations of 0, 1, or 2-adjacent buckies.
Since the function keys are there, you may as well make up top+>40
codes for them. Some of the function keys map into keys on the old
keyboard; see the #\ table in LMIO;READ for something from which this
mapping can be derived, as we are doing it on the Lisp machine now.
>From memory, it's clear-screen->form, delete->vt, clear-input->clear,
macro->back-next (but should be system->backnext in your case), terminal->esc.
It's not obvious that new keyboards will ever be attached to the AI TVs.
We might, and we might not. It would involve slowing down the keyboard
scanner substantially, and we might have to put some buffering in the
keyboard microprocessor.
From JLKatMIT-MC Mon Mar 3 00:00:00 1980
From: JLKatMIT-MC (John L. Kulp)
Date: 3 March 1980, 00:00
Subject: Use of New Keyboards with ITS.
Message-ID:
We are going to hook up a new kbd to the PTV system in the next few
days, and the obvious question comes up about how to encode all
the function keys. I suppose they could be handled the way
they are on the old keyboard, namely send chars with the TOP bit +
100 + . In order to distinguish them from the old kbd,
how about encoding them in 140-177? Presumably the extra modifier
bits (SUPER, HYPER, and GREEK) need to be allowed (that uses up
all the bits available in the intelligent terminal protocol, unless
we want to flush SHIFT and SHIFT-LOCK). It doesn't much matter
what the encoding is, as long as its documented. I guess any
part of the system which masks off the high modifier bits or
otherwise depends on them being zero will have to get looked at.
ITS presumably wants to know about the SYSTEM key (treat like BACK/NEXT).
Its about time DDT knew about CLEAR (or CLEAR INPUT on the new kbds) which
should behave like ^D. Also, HELP, STOP OUTPUT (^S, actually this should
probably be defined to do an output hold at the terminal, followed by an
output reset from the remote process (as is currently done)), ABORT (^G), END
(^C), RESUME ($P), etc.
TELNET and SUPDUP should be informed about the NETWORK key.
Various programs should know about END, ABORT, RESUME, BREAK, QUOTE, HELP,
STATUS (I'm not saying every program in the world should be retrofitted
to know about these, but the basic ones -- DDT, TECO, LISP -- probably
should).
I suspect that not much is going to happen on this until AI TV's start
getting new keyboards, but I would at least like to see the encoding
defined now, so that where only simple changes are required, they
can be done quickly when desired.
From AGRE Mon Mar 3 00:00:00 1980
From: AGRE (Philip E. Agre)
Date: 3 MAR 1980, 00:00
Subject: No subject
Message-ID:
The terminal controller still seems to think that CADR-2 is still in 907.
x6765 gets an occasional call looking for the person on CADR-2.
From CFFK at MIT-MC Sat Mar 1 00:00:00 1980
From: CFFK at MIT-MC (CFFK at MIT-MC)
Date: 01 Mar 1980 00:00
Subject: No subject
Message-ID:
In PEEK M mode on a Macsyma I was running gave:
Mem=216, Top=254, Shared=158, Out=-1, Total=215
What does Out=-1 signify?
From KLH at MIT-MC Sat Mar 1 00:00:00 1980
From: KLH at MIT-MC (KLH at MIT-MC)
Date: 01 Mar 1980 00:00
Subject: No subject
Message-ID:
I think FAST-APPEND can win using the following algorithm:
-------------------
If canonical file doesn't exist:
Check for AOS'd version, and rename to canonical.
Find message-EOF of file:
Re-open in read mode if not already in.
Set .ACCESS ptr to file-EOF
Read backwards until a msg-EOF mark is seen (ie ctl-_)
If canonical file already existed, msg-EOF is set to file-EOF.
Re-open file in write-over mode
Set .ACCESS ptr to msg-EOF
Write message.
If IOC for some reason, just stop.
Close channel.
-------------------
Note that there is no need to do anything about RENMWO'ing,
because following attempts will always start at the right place, and
it doesn't matter if the next attempt doesn't quite extend past the
true file EOF, because following appends will still back up to the
new msg-EOF mark.
It would be a LOT more efficient if there
was some way to both read and write the file while it was open;
ironically enough the only way to do this now is to map into the
system buffer and see what's there!! The data is there, but the
system won't let you get at it. Foo.
It would probably be easier to allow some way of doing
this dual I/O ("read-while-locked"?) mode than to hack APPEND mode,
since it doesn't depend on anything fundamental to the UFD.
Another idea is for ITS to support this algorithm internally,
given the EOF delimiter(s) as argument. Might be invoked by an OPEN
mode bit, or a new CALL. This requires even less overhead and
makes the feature generally available. This also
prevents race conditions since presumably one process would be
locked out while the other's APPEND effort progressed; this sort of
system-supported reliability could also make it reasonable to
use FAST-APPEND on normal MAIL files (since the FN2 is just 4 letters
and an AOS will stand out).
I'd claim this is a lot more useful than ECHOIN's hacking TECO buffers!
The amount of really gross disk I/O that the COMSAT does seems to far
exceed the amount of TTY-echo overhead being done, especially on AI.
Any comments on this scheme? (No, I'm not likely to stop trying.)