On Sat, Oct 7, 2017 at 4:13 AM, bartc <b...@freeuk.com> wrote: > On 06/10/2017 15:55, Chris Angelico wrote: >> >> On Fri, Oct 6, 2017 at 11:38 PM, bartc <b...@freeuk.com> wrote: > > >> Have you ever worked on a slow remote session where a GUI is >> completely impracticable (or maybe even unavailable), and redrawing >> the screen is too expensive to do all the time? You absolutely have to >> work with line-by-line content. > > > Not since about 1977, using 110 baud teletypes and VDUs, on a mainframe not > geared to interactive use so it was unresponsive anyway. > > By 1981 however I was using a memory-mapped text display (of my home-made > computer) which even with its 8-bit processor could update the screen at > 200,000 characters per second. In other words, instantly. > > So what's the excuse for an unresponsive text display in 2017?
Got it. You assume that a system is a coherent computer with its peripherals, rather than being a networked collection of computers, all of them controlled from your laptop in response to a panicked email saying the web site is down. Your terminal exists on your laptop. The programs are being run on any of a number of your servers, possibly several of them concurrently. How do you handle that? >> What text editor do you use there? > > That depends; are we still in the 1970s? Nope. We're in 2017, where the "system" is often a networked collection of computers. > (And since I mainly use my own languages, actually getting hold of 'stdin', > 'stdout' and 'stderr' is not trivial. Creating actual named files is much > easier.) More blub happening right there. You start out by assuming that the standard streams are unimportant, therefore you think that providing them is pointless. It's self-perpetuating. >> Also: can you use your program to write to a file on a different >> computer? I can pipe a program's output into SSH. You can make a crude >> intercom system like this: > > No. I've got no idea about formal networking. (Actually, I walked out of the > computer networks exam in my CS course, as I realised I knew nothing.) It's 2017. You should understand at least a bit about the internet and how to use it. > But as it happens, I could make computers talk to each when I was working > with microprocessors, using home-made interfaces, rs232 or rs423. I wouldn't > know how to do it now because it depends on other people's over-complex > tech. I don't know if you're an idiot or a troll. Using TCP/IP networking is pretty simple (at least if you're using a real language - your own toy languages might have made it unnecessarily hard, for all I know), hardly "over-complex" by comparison to RS-232 programming. >> I'm not sure what you mean by a working pipe system. Yes, the one >> cmd.exe gives you is not nearly as flexible as what bash gives you, >> but for the purposes of the examples given so far, > > > I just don't work that way. The OS is there to launch applications, or to > provide a basic API for common services such as a file system. I don't need > its complicated shells. Blub rears its head again. (Also, the shell isn't part of the OS. It's a separate tool. But still.) >>> BTW if I try: >>> >>> > gcc <program.c >>> >>> it doesn't work (this on Linux). What happened to the generic solution? >> >> >> "It doesn't work" is a terrible way to report this. What's the >> problem? Is it possibly what's described fairly clearly in the error >> message? > > > It says 'no input files'. Presumably it's one of those programs that only > takes input instructions from the command line, and does not look at stdin. Presumably you don't know that a large number of programs accept "-" as a pseudo-filename that means "stdin" or "stdout" depending on context. For instance, you can diff a file with stdin, or send wget's output to stdout. At what point will you acknowledge that there are things you do not understand that are actually useful? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
