The "loop and a half"

[bartc]

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?

> What text editor do you use there?

That depends; are we still in the 1970s?

> That's why we have the stderr stream as well as stdout. You can
> redirect stdout and still have messages go to the screen (via stderr);
> or you can redirect stderr as well, sending those messages to a
> logging facility. How do you do THAT with your program?

I said the output was complex. Then there might be more than one output 
file, and one or more of the outputs need to be in an actual file.

Just blithely sending /everything/ to stdout, even mixed up with stderr, 
might be something I'd do for a quick throwaway program, not a major 
application.

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


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

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

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

In which case you wouldn't be able to pipe source code into it. You 
might actually have to tell it the name of a discrete file you want to 
compile.

-- 
bartc