The "loop and a half"
bartc
bc at freeuk.com
Fri Oct 6 13:13:43 EDT 2017
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
More information about the Python-list
mailing list