guy@auspex.UUCP (Guy Harris) (02/14/89)
>>Perhaps we should begin to make a really SERIOUS distinction between >>direct human input and other kinds. > >*DON'T EVEN THINK ABOUT THIS!* The ability to arbitrarily redirect >input and output among devices/files/pipes/networks is what makes >the unix toolbox approach work. Take that away and you would have >a fairly useless operating system. Right. So all OSes that don't let you do that are "fairly useless". Funny, lots of people seem to have uses for them.... There are plenty of UNIX utilities that are intended to be driven by a human being - screen editors, for example. While they might be *able* to be driven from a file or pipe, I, at least, would be inclined to use "ed" or "ex" in that context, not a screen editor (or the screen-editor mode of some editor). It's also not clear how the "don't distinguish" model applies to window-system-style tools, where input doesn't necessarily consist of the sort of stuff you'd stuff into a text file. >Imagine wc working only with typed input - how often would you use it? Lousy example. "wc" takes all its *commands* (i.e., "count characters", "count words", "count lines") from the command-line arguments; it doesn't read *commands* from its standard input, it reads *data*. "ed" would be a better example - and, most of the time, I *don't* use "ed" for editing, I use a screen editor, because it's less of a pain to use. >I don't care to waste any CPU time watching for meaningless transitions >of the <shift> key. None of the systems I've worked with "waste" much CPU time "watching" for "meaningless" transitions of the <shift> key; on Suns, for example, and probably on a lot of other machines, the host is interrupted when a key on the keyboard goes up or down, and, frankly, the keyboard driver is not particularly near the top of the list of functions consuming CPU time on a Sun.
les@chinet.chi.il.us (Leslie Mikesell) (02/15/89)
In article <1016@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >>>Perhaps we should begin to make a really SERIOUS distinction between >>>direct human input and other kinds. >Right. So all OSes that don't let you do that are "fairly useless". >Funny, lots of people seem to have uses for them.... Yes, to run monolithic applications. Unix could do that too, I suppose.. >It's also not clear how the "don't distinguish" model applies to >window-system-style tools, where input doesn't necessarily consist of >the sort of stuff you'd stuff into a text file. How do you write programs to manipulate the stuff, then? As a programmer, I prefer to *eliminate* human input rather than optimizing it. Obviously I don't do freehand graphics. >>Imagine wc working only with typed input - how often would you use it? >Lousy example. "wc" takes all its *commands* (i.e., "count characters", >"count words", "count lines") from the command-line arguments; But it illustrates the point I was trying (and apparently failed) to make. I don't object to fancy interfaces, but they should be a "front-end" that generates a standard interface for other tools. >None of the systems I've worked with "waste" much CPU time "watching" >for "meaningless" transitions of the <shift> key; on Suns, for example, Try executing sar on a '386 machine running VP/ix with a DOS process active. Note that the idle time is 0. Perhaps keyboard scanning is not entirely to blame - does the Sun 386i handle DOS better? Les Mikesell
barmar@think.COM (Barry Margolin) (02/15/89)
In article <1016@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >None of the systems I've worked with "waste" much CPU time "watching" >for "meaningless" transitions of the <shift> key; on Suns, for example, >and probably on a lot of other machines, the host is interrupted when a >key on the keyboard goes up or down, and, frankly, the keyboard driver >is not particularly near the top of the list of functions consuming CPU >time on a Sun. But consider the case in an X Window System environment. Every key transition results in a packet being sent from the server to the client. This causes the client application process to be scheduled so that it can decode the packet, notice that it was just a shift key transition, set some state, and go back to waiting for the next packet. I don't deny that this is wasteful of network and cpu resources, and NeWS probably allows improvement by moving some of these operations into the server when the client doesn't need them. However, X is an important fact of life these days. Boy, have we gotten off the subject of C! Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jamesa@arabian.Sun.COM (JD Allen) (02/15/89)
> None of the systems I've worked with "waste" much CPU time "watching" > for "meaningless" transitions of the <shift> key; This has little to do with setjmp/longjmp (or anything at all really!) but I couldn't pass it up. Run your favorite benchmark on the IBM PC sometime with and without the shift key held down. The degradation due to shift-key-depressed, as I recall, is about 1.5 %. (I am talking about the *original* PC with the *original* keyboard.) This isn't wasting "much" time, but to a perfectionistic, waste is waste. I'm sure the design was "justified" by the idea of making the keyboard "soft"-programmable. But in that case why did the ROM firmware on the same machine handle the "Insert" and "Delete" keybuttons differently? Auto-repeat of "Ins" is disabled, like that of "Shift" and "Ctrl" (although not without wasting the afore-mentioned compute power), while "Del" is treated as a "first-class" keybutton. (Yes, I know this asymettric treatment of Ins/Del is what the typical word processor "wants".) My "complaint" about the shift-key-depressed degradation has an implicit smiley-face, but the Insert/Delete asymettry was quite vexing to me since I took IBM at its word about "configuring your keyboard interface to suit your fancy" and developed an application which wanted Insert/Delete to be handled with symettry. - James Allen P.S.: Why did `postnews' delete `comp.lang.c' from the above Newsgroup line? I won't edit it back in, since the whole posting really should be shoved into `/dev/null.' (Or perhaps I should say "dragged into the trashcan" since the thread was something about keyboard -vs- mouse.)
guy@auspex.UUCP (Guy Harris) (02/16/89)
>>Right. So all OSes that don't let you do that are "fairly useless". >>Funny, lots of people seem to have uses for them.... > >Yes, to run monolithic applications. Unix could do that too, I suppose.. What is a "monolithic application"? "vi", "emacs", or any one of N screen editors? UNIX not only *can* do that, but *does* do it, quite often; if it *couldn't* run such an editor, I'd be pretty ticked off. >How do you write programs to manipulate the stuff, then? As a programmer, >I prefer to *eliminate* human input rather than optimizing it. Obviously >I don't do freehand graphics. Some people do. Some people also edit text. If you've got software to write code and documents for me, without my input, I'd love to have it, as long as I find its output acceptable; otherwise, there are plenty of situations where you won't be able to eliminate human input. Yes, it's *nice* to be able to glue programs together. The existence of many operating systems that, unfortunately, don't let you do that as conveniently as UNIX, but that people can still use, however inconveniently, to get their job done proves that such OSes are not "fairly useless", however. >Try executing sar on a '386 machine running VP/ix with a DOS process >active. Note that the idle time is 0. Perhaps keyboard scanning is >not entirely to blame - does the Sun 386i handle DOS better? Beats me. I know how the Sun keyboard works, though, and there's no "scanning" necessary. You press a key, and it sends a "this key went down" code over the serial port; release the key, and it sends a "this key went up" code over the port. No muss, no fuss, and no CPU cycles spent polling the keyboard. (The parallel-port keyboard on REALLY old Suns may have had to be polled - I've forgotten how it works - but such polling was relatively cheap.) I suspect a lot of other workstations' keyboards work much the same way. It may also be that the DOS process is doing the scanning, and VP/ix is running around like a headless chicken simulating the keyboard. There are a lot of things you can get away with on a single-tasking OS, such as polling your keyboard in a loop, that don't work quite so nicely on a multi-tasking OS.
guy@auspex.UUCP (Guy Harris) (02/16/89)
>I don't deny that this is wasteful of network and cpu resources, and >NeWS probably allows improvement by moving some of these operations >into the server when the client doesn't need them. However, X is an >important fact of life these days. The original complaint was about time wasted "watching" for transitions such as that; X clients don't have to waste lots of time doing that, they are presumably blocked on a "read" or "select" or "poll" or something such as that waiting for an event from the server. (A subsequent posting indicated that the problem was with DOS processes running under VP/ix; it may well be that, as far as the DOS process knows, it owns the whole machine - after all, it's running under DOS, right? - and thus sits in a loop polling the keyboard.) Furthermore, how bad a problem *is* that sort of thing?
les@chinet.chi.il.us (Leslie Mikesell) (02/18/89)
In article <1023@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: [RE: human input vs. programmed] >What is a "monolithic application"? "vi", "emacs", or any one of N >screen editors? UNIX not only *can* do that, but *does* do it, quite >often; if it *couldn't* run such an editor, I'd be pretty ticked off. A monolithic application is one where the user must interact directly with the program, and outputs go to specific devices known by the program. Seems like a nice concept, since everything can be optimized. However in many situations, the user wants to do nearly repetitive operations but there is no way to supply programmed input. For example we have a map-drawing program with a handy-dandy point-and-select interface. The user had prepared maps of each state with data by counties (fortunately the data could be imported). The *only* way to select a map to print is to highlight it's name in a displayed list and select it, and a high-res printout takes about 15 or 20 minutes. So, instead of being able to prepare a list of commands to be issued automatically one after another and going home he has to wait around and use the (easier?) method of visual selection. I could give several other real-world examples, but the principle here is plain. Much work only involves a small variation from the last time a program was run and an extremely easy way to avoid work is to gather up the variable parts first with a separate program that prompts or does a table lookup, merge it with the standard inputs and feed it to the main program without user intervention. With standard unix-type utilities this is generally no problem, and it can easily be allowed by the program itself by making provisions for reading commands from and input file *if* all the commands can be represented in the file data. That's the real problem with human-engineered input styles - how do you represent something dynamic that is highlighted on the screen in a command file, or even something like a key-up event? >Yes, it's *nice* to be able to glue programs together. The existence of >many operating systems that, unfortunately, don't let you do that as >conveniently as UNIX, but that people can still use, however >inconveniently, to get their job done proves that such OSes are not >"fairly useless", however. I'll admit that I should have posed the question above instead of reacting with a flame. Les Mikesell
guy@auspex.UUCP (Guy Harris) (03/01/89)
>That's the real problem with human-engineered input styles - how >do you represent something dynamic that is highlighted on the screen >in a command file, or even something like a key-up event? Perhaps you don't do so directly. Perhaps you have a "little language" for "programming" the application, and a user interface that either sits atop that "little language" or atop the same underlying mechanisms that the "little language" sits atop. Consider EMACS, for example; the underlying "little language" (perhaps not so little...) is MockLISP or ELISP, and the key-binding mechanism sits atop that. Were I required to drop down to the command line and type EMACS commands, or (Mock)LISP, in order to get anything done, I'd be searching for a different editor.... The same could conceivably be done with non-keyboard input. No, it might not be convenient to "program" the application by typing the same stuff you do at the keyboard into a file, and then just run the editor with its input redirected to that file; given the choice between a user interface like that, and a user interface that doesn't quite match what you put into a "command file" but that lets me get the *interactive* editing job done easier, I'd take the latter in a heartbeat (especially given that a given session with the application may include *both* interactive *and* "programmed" usage, so that redirecting the input to a script may be the *wrong* answer).