Re: for S'Image use Func??

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 16 May 2010 13:56:57 -0700 (PDT), Maciej Sobczak wrote:

> On 16 Maj, 09:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Wrong, unless you clearly define the meaning of "show".
>>
>> That is the point! Show is in each other's head. Some would consider single
>> LF as one empty line, others as two, and some as a broken file.
> 
> So now we can come back to our original subject - what is the added
> value of Text_IO, then?

That you need not count lines by yourself.

> What is the point of abstracting the notion of
> text, if it "is in each other's head"?

It is not. The notion of stream encoding is.

> Shouldn't stream I/O be enough
> and leave the rest to everybody's head in this case?

No, because we count lines differently. Text_IO provides a way to
standardize encodings in inferior operating systems.

>>> And if you give me the freedom to choose my rendering scheme, it will
>>> be:
>>
>>> $ cat -n file.txt
>>
>> It does not work under Windows.
> 
> Of course it does. Cygwin is your best friend.

Nope, cygwin is a horror. Even much less offending MinGW is.

>>> Fine. You still forgot about log files. :-)
>>
>> I don't use UNIX, remember. Our log files are binary.
> 
> The only thing I can say now is that not only you don't use Unix, but
> you also don't use plenty of software packages that exist on Windows.

Right, for example MFC, ActiveX among others.

>>>> You could say: it
>>>> ends when blocked. Not very nice, but, in fact, widely used in network
>>>> communication protocols.
>>
>>> Widely? An example or two, please?
>>
>> Any. You cannot rely on the remote host always sending you graceful
>> disconnect. Many devices we are dealing with don't even have such thing.
>> They just become silent.
> 
> This makes the end of stream indistinguishable from arbitrary delays.

These systems are more or less real-time. It means that if the delay
exceeds the time of service (which is not necessarily microseconds, it
could be seconds), then the game is out anyway.

> Not a good idea. What about the stream of keystrokes? Is the stream
> finished just because I'm thinking what to type next?

The operators have HMI. They don't encourage streams, they do GUIs!

>> As a practical example, load some large text page into the browser. Before
>> it completes, in the middle, pull the Etherenet jack out. Observe the
>> stream end!
> 
> It is not a stream end, it is a communication error. Guess what - some
> protocols are wiser than HTTP and can figure that out, which disproves
> your universal "any" qualifier.

Error is the reason why the stream is or considered ended. Note that the
browser does not crash. It renders that end, you can see it by scrolling
the page down.

> As in the majority of such discussion, we don't have a converging
> thread and we're not likely to come to any conclusion either (and we
> are long ago far away from the original problem, too).
> Is it OK to suggest that we should somehow finish?

Yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de