The "loop and a half"

[Chris Angelico]

On Sat, Oct 7, 2017 at 4:13 AM, bartc <bc at freeuk.com> wrote:
> On 06/10/2017 15:55, Chris Angelico wrote:
>>
>> On Fri, Oct 6, 2017 at 11:38 PM, bartc <bc at 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