From: Joseph M. Newcomer on
See below...
On Tue, 02 Feb 2010 02:32:48 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:

>Joseph M. Newcomer wrote:
>
>> You seem to be very confused. You are thinking that CR has meaning in parsing text lines.
>> Except in the one rare exception of older Macintosh text files, it has no meaning in
>> parsing text lines. It has relevance in rendering output, but you are confusing storage
>> and rendering here. I was talking about the original topic, the parsing of text lines
>> from Windows-compatible files. I'm not at all sure what you are talking about.
>> joe
>
>Of course you don't because you took something and total
>discombobulated it to show a meaningless point.
>
>Storage/Rendering are parts of the same coin. You are reading or more
>specifically, your LINE READER is done for a purpose, either for
>display, printing or what have you. A generalized line reader
>understands all the conditions for EOL for all platforms.
****
No. Storage is storage. Rendering is rendering. Sometimes, there is an encoding
overlap, but it is purely coincidental. Unix, for example, stores "lines" as sequences of
characters terminated by a newline (\n). The \r is supplied gratuitously when the line is
rendered to a display device. In fact, in Unix it was difficult to get the cursor to move
vertically because you had to override everything and work with pure binary output.

When writing an application that runs on Windows, there is no reason to understand, or in
general, even CARE about, EOL sequences on other platforms. You only have to worry about
the EOL sequence in Windows-based files.
****
>
>You said the \r was meaningless since 1968 when in fact, you were
>incorrect in it value in not only for rendering but storage. You said
>it is ignored, well, first of all, thats not a meaningless action.
>You took it into account. I could only be meaningless if it didn't
>provide value to some rendering or print or output process - a total
>waste in storage and for rendering. This is not reality across the board.
****
No, I said that in 1968 we recognized that in parsing input, \r was meaningless. It was,
and nothing you can say will change the fact that we KNEW it was meaningless noise in
1968; you can't rewrite history to satisfy your specification. I don't understand how you
can make a claim that we were doing things in a way you think we SHOULD have been doing
them, instead of the way we WERE doing them. I was there. This is the way we wrote input
parsers.

By the way, IBM systems stored lines as either fixed-length or variable-length records,
with no terminator. I wrote text editors for those systems. I don't mean 8088-based PCs,
I mean IBM mainframes. They had no carriage return, or line feed, or NUL character
conventions. Records had a length which was determined either by the file type
(fixed-length records) or the individual record (variable-length records).
****
>
>Maybe you might had been attempting to suggest it is "transparent", as
>in a cooked I/O functionality under windows, but thats only because
>the cooked functions themselves do the interpretation for you - that
>is not meaningless.
****
You are still insisting that whitespace noise has meaning. \r is whitespace noise. It
only has value in rendering. It has no semantic content. It is used in edit controls to
force rendering. It is not meaningful when parsing input.
joe
****
>
>Bye
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on
I've been doing more and more C# programming. I find it to be a very rapid
development environment, but not so much because of the syntax. There is
simply more "stuff" readily available in libraries and the VS IDE works so
much better with it. All I've done are dialog type applications with
WinForms and WebForms, so I suspect it may fail some (or not be as easy) to
do SDI or MDI type applications.

Tom

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:u42dmY#oKHA.4648(a)TK2MSFTNGP06.phx.gbl...
> Hector Santos wrote:
>
>> I agree. But I decided I am going to invest in C# for development
>> products but only provide the .NET interface and examples for our server.
>
>
> Correction, "I am NOT...."
>
> --
> HLS

From: Ismo Salonen on
--snip--

> ****
> You are still insisting that whitespace noise has meaning. \r is whitespace noise. It
> only has value in rendering. It has no semantic content. It is used in edit controls to
> force rendering. It is not meaningful when parsing input.
> joe
--snip--

As a side not , in OS/9 (( 20 years ago ?) the \r was used as line
delimiter. Don't know whye they picked different than the \n. Cannot not
remember if the c runtime interbally did change from \n to \r and vice
versa, I could dig old manuals iff I still can find them :-)

ismo
From: Tom Serface on
I think it doesn't matter what character signifies the end of the line. We
just don't really need two of them for each line in flat files. In the old
"terminal" days it made more sense because going to be beginning of a line
was different operation than going down a line, but these days that doesn't
make so much sense from a file point of view.

Tom

"Ismo Salonen" <ismo(a)codeit.fi> wrote in message
news:OIAj3rJpKHA.5508(a)TK2MSFTNGP02.phx.gbl...
> --snip--
>
>> ****
>> You are still insisting that whitespace noise has meaning. \r is
>> whitespace noise. It
>> only has value in rendering. It has no semantic content. It is used in
>> edit controls to
>> force rendering. It is not meaningful when parsing input.
>> joe
> --snip--
>
> As a side not , in OS/9 (( 20 years ago ?) the \r was used as line
> delimiter. Don't know whye they picked different than the \n. Cannot not
> remember if the c runtime interbally did change from \n to \r and vice
> versa, I could dig old manuals iff I still can find them :-)
>
> ismo

From: Hector Santos on
Tom Serface wrote:

> I think it doesn't matter what character signifies the end of the line.
> We just don't really need two of them for each line in flat files. In
> the old "terminal" days it made more sense because going to be beginning
> of a line was different operation than going down a line, but these days
> that doesn't make so much sense from a file point of view.


Tom, I guess at the point, its clear that it really depends on ones
experience and needs as system, protocol, tools and/or application
developers.

Try it yourself, create three flat files:

MAC.TXT <CR>
DOS.TXT <CR><LF>
UNIX.TXT <LF>

each with their natural corresponding EOL requirement. And good power
programmer text editor will support this or write a piece of code to
create example flat files.

Now see how they NATURALLY apply at the application level for a WIDE
degree of usages from simple to more detailed. See how meaningless it is?

At the simplest:

TYPE xxxx
COPY xxxx LPT1:

Or try to read each one with a DOS only based editor, like NotePad
and see how it differs?

Now if you were an internet mail (smtp, pop3, nntp, etc) protocol
author, see how meaningless the STORAGE when these files content have
RFC 2822 information.

I can go on forever, its not a meaningless concept at ANY level.
Protocol authors or implementations have seen enough of these talk
from application developers that its part of reason there were many
goof ups. An application developer take a LIBRARY, doesn't quite get
the "details" but begins to use it simplistically. He will find out
very quickly how "meaningless" its not AT ALL LEVELS and in particular
the STORAGE level.

Why?

For example, assume an application has 1 file per message concept. He
can't just COPYFILE to another sub-system or maybe GATEWAY QUEUE. If
he doesn't take into account what EOL is used, he will RUN into trouble.

I guess, understanding these subtle design points might be related to
one's experience. If you don't deal with this on an everyday basis,
across many protocols and application areas, a wide variety of
interface and integrated considerations, then I can clearly understand
the higher level view point, but that doesn't mean it is or was
meaningless at ANY level.

--
HLS