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.)