[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
macperl-modules-digest v01.n003
From: owner-macperl-modules-digest@macperl.org (macperl-modules-digest)
To: macperl-modules-digest@macperl.org
Subject: macperl-modules-digest V1 #3
Reply-To: macperl-modules@macperl.org
Sender: owner-macperl-modules-digest@macperl.org
Errors-To: owner-macperl-modules-digest@macperl.org
Precedence: bulk
macperl-modules-digest Wednesday, March 3 1999 Volume 01 : Number 003
----------------------------------------------------------------------
Date: Mon, 1 Mar 1999 14:04:44 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: [MacPerl-Modules] Need authoritative Apple refs for EOL == CR
I could use some help on this, big time. This has come up before, and
probably will again.
Enno Derksen, who authors XML::XQL, started this \n and \xA business off
again on the Perl-XML list a few days ago. I planted the seed in his mind
a few months back and I don't think he's let go of it. :-)
The consensus now appears to be this: XML does NOT require \n == \xA
internally, but according to the spec an XML processor _must_ pass \xA out
to an application, in place of \xD\xA or \xA. Despite the fact this is not
so attractive for us on the MacOS side, I have to reluctantly concur with
this interpretation, after really carefully re-reading the EOL handling
section in the XML spec. (It sort of helps that Larry Wall pointed this
out in the first place... :-))
Note that this also means that a lot of XML module tests aren't properly
written, as they are Unix-centric. So this is not an interpretation that
currently has Perl XML extension authors overjoyed either. (The reason
the tests are flawed is because they are comparing original content
directly to returned XML - this works on Unix only).
So far the discussion has been quite reasonable (Larry appears to be
supportive, in particular), but just today Tim Bray, who is directly
responsible for this chunk of the spec, also joined in. He clearly is not
aware that \n != \xA on MacOS, and I need a good, solid authoritative ref
from Apple docs (more than one is even better) saying that the line
terminator for Mac apps is a CR (\xD), which I can refer him to. I've
looked at IM:Text, IM:Printing, IM:Files, searched on the Apple Developers
site, and I can't find a thing, except one ancient Tech Note pertaining to
A/UX <=> HFS file translations. So, help! :-)
The reason I'm fired up is that the argument has moved away from what Perl
XML modules should be doing to an examination of whether the XML spec is
correct or reasonable with respect to EOL's, there appears to be at least
some willingness to accept that the XML spec could be modified in this
regard (if not active proponency), and if I can insert some factual basis
for asserting that \n == CR on MacOS into the debate, there may be some
hope for getting an actual mod to the XML spec itself. I'm not holding my
breath, but I'd like to try.
Thanks for any help. Arved
P.S. I don't know about anybody else, but I have to sort of wonder what
Apple is up to. Here's something as important as the XML spec, and one of
the lead people working on it (Tim Bray), with specific responsibilities
pertaining to the EOL issue, hasn't even been apprised that things are a
little bit different over on Macs. Maybe Apple is thinking that it'll
become a non-issue with MacOS X: I certainly hope that's not it, though.
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 13:35:04 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
At 13.04 -0500 1999.03.01, Arved Sandstrom wrote:
>The consensus now appears to be this: XML does NOT require \n == \xA
>internally, but according to the spec an XML processor _must_ pass \xA out
>to an application, in place of \xD\xA or \xA. Despite the fact this is not
>so attractive for us on the MacOS side, I have to reluctantly concur with
>this interpretation, after really carefully re-reading the EOL handling
>section in the XML spec. (It sort of helps that Larry Wall pointed this
>out in the first place... :-))
I'm not sure I follow. What is the consensus? That XML::Parser should
return \xA, but that string methods should convert to \n? Or that it
should indeed return \xA in string methods?
>So far the discussion has been quite reasonable (Larry appears to be
>supportive, in particular), but just today Tim Bray, who is directly
>responsible for this chunk of the spec, also joined in. He clearly is not
>aware that \n != \xA on MacOS, and I need a good, solid authoritative ref
>from Apple docs (more than one is even better) saying that the line
>terminator for Mac apps is a CR (\xD), which I can refer him to. I've
>looked at IM:Text, IM:Printing, IM:Files, searched on the Apple Developers
>site, and I can't find a thing, except one ancient Tech Note pertaining to
>A/UX <=> HFS file translations. So, help! :-)
Why doesn't he just take the word of everyone who obviously knows it to be
true? How about a Mac program that prints the value of \n as its numeric
equivalent? :)
I did some searching and could not find anything. I will let you know if I do.
>P.S. I don't know about anybody else, but I have to sort of wonder what
>Apple is up to. Here's something as important as the XML spec, and one of
>the lead people working on it (Tim Bray), with specific responsibilities
>pertaining to the EOL issue, hasn't even been apprised that things are a
>little bit different over on Macs. Maybe Apple is thinking that it'll
>become a non-issue with MacOS X: I certainly hope that's not it, though.
Well, most people use CW for most stuff, so it doesn't matter for them,
since \n usually means \xA.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 15:14:01 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
On Mon, 1 Mar 1999, Chris Nandor wrote:
> At 13.04 -0500 1999.03.01, Arved Sandstrom wrote:
> >The consensus now appears to be this: XML does NOT require \n == \xA
> >internally, but according to the spec an XML processor _must_ pass \xA out
> >to an application, in place of \xD\xA or \xA. Despite the fact this is not
> >so attractive for us on the MacOS side, I have to reluctantly concur with
> >this interpretation, after really carefully re-reading the EOL handling
> >section in the XML spec. (It sort of helps that Larry Wall pointed this
> >out in the first place... :-))
>
> I'm not sure I follow. What is the consensus? That XML::Parser should
> return \xA, but that string methods should convert to \n? Or that it
> should indeed return \xA in string methods?
>
Sorry, should have explained that more clearly. Enno Derksen originally
started out by talking about stringification methods, but that particular
topic is sort of by the wayside at the moment. We're back to a more
fundamental discussion of: what is \n on various platforms?
The consensus, if I may refer to it as such, is that a conforming XML
processor, such as XML::Parser, must (is required by the XML spec) return
\xA to an XML application. This is actually quite clear.
I'm leaving stringification methods for round 2. Things like this are
covered in the DOM spec (such as 'toString'), and I'm re-reading that
myself.
Where the first source of difficulty arises is in convincing XML extension
authors that if original content is being processed by XML::Parser s.t.
EOL's are getting made into \xA characters, they can't just pass the XML
back out and compare it to the original content. Well, obviously on Unix
they can. I'm trying to argue, over on Perl-XML, that under MacOS you
can't.
>
> >So far the discussion has been quite reasonable (Larry appears to be
> >supportive, in particular), but just today Tim Bray, who is directly
> >responsible for this chunk of the spec, also joined in. He clearly is not
> >aware that \n != \xA on MacOS, and I need a good, solid authoritative ref
> >from Apple docs (more than one is even better) saying that the line
> >terminator for Mac apps is a CR (\xD), which I can refer him to. I've
> >looked at IM:Text, IM:Printing, IM:Files, searched on the Apple Developers
> >site, and I can't find a thing, except one ancient Tech Note pertaining to
> >A/UX <=> HFS file translations. So, help! :-)
>
> Why doesn't he just take the word of everyone who obviously knows it to be
> true? How about a Mac program that prints the value of \n as its numeric
> equivalent? :)
>
> I did some searching and could not find anything. I will let you know if I do.
>
I didn't mean to suggest that Tim Bray has taken a position that I, or
anyone else trying to clarify the MacOS situation, are full of it. So far
he just indicated in a post that he's completely unaware that \n != \xA.
I'm just thinking that an official Apple reference or two would be more
helpful, something he can look up himself, than me or anyone else just
telling him that this is how it is.
But thanks for anything you can dig up. Arved
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 13:52:10 -0600
From: David Steffen <steffen@biomedcomp.com>
Subject: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
> At 13.04 -0500 1999.03.01, Arved Sandstrom wrote:
>I need a good, solid authoritative ref
>from Apple docs (more than one is even better) saying that the line
>terminator for Mac apps is a CR (\xD), which I can refer him to. I've
>looked at IM:Text, IM:Printing, IM:Files, searched on the Apple Developers
>site, and I can't find a thing, except one ancient Tech Note pertaining to
>A/UX <=> HFS file translations.
It seemed so odd to me that this should even be a question that I gave some
thought to the issue of what it means to say that on a Mac, \n == \xD.
Three possibilities:
1) Majority vote. Then all you need to do is list all the applications you
know of that use \xD as \n. [Counter example: I use BBEdit as my primary
text editor, and it is happy to use \xD, \xA, or \xD\xA as \n. However, it
allows you to save with Unix, Mac, or PC line ends, with the expected
definitions thereof, so BBEdit could be used as an explicit example as
well.]
2) There is an Apple guideline somewhere that urges developers to use this
convention. I have not been able to locate such, but I don't have ready
access to much of this information.
3) TextEdit uses this convention. Since TextEdit is used so extensively in
the MacOS interaction with text, this would effectively mandate that \xD ==
\n. Looking at my very, very old version of IM (the "phone book"
promotional version of the original IM draft), I come across the following
two quotes:
(Under discussion of Destination and View Rectangles for text display)
"Normally, at the right edge of the destination rectangle, the text
automatically wraps around to the left edge to begin a new line. A new
line also begins where explicitly specified by a Return character in the
text."
(Under discussion of the TERec Data Type)
"The crOnly field specifies whether or not text wraps around at the right
edge of the destination rectagle, as shown in Figure 5. If crOnly is
positive, text does wrap around. If crOnly is negative, text lines are
specified explicitly by the Return characters only."
(It is clear from context that the plural in "Return characterS", above,
refers to multiple instances of \xD in the text, not multiple possible
values for \n.)
Does this help?
- -David-
David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 16:05:05 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
On Mon, 1 Mar 1999, David Steffen wrote:
>
[ Examples snipped ]
> Does this help?
>
It's an excellent start. Thanks. Certainly the kind of stuff I can use.
That thing about TeachText is pretty conclusive. I think Chris Nandor was
sort of alluding to the same thing.
I've got IM:Text at home in DocViewer so I'll look at that later. The way
Apple has some of their online docs now is not nearly so nice. Personally
I thought DocViewer was fine, but they seem to be moving more and more
over to PDF, which makes me want to buy more and more of the real books on
paper. ;-)
Arved
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 15:31:56 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
Here we go.
http://developer.apple.com/techpubs/mac/Text/Text-55.html
# You can replace the address of the default end-of-line hook routine with
# the address of your own routine that determines an end-of-line character
# if you want the end-of-line to be defined by a character other than the
# carriage return.
#
# The default routine compares a given character with $0D (a carriage
# return) to determine whether it is an end-of-line character, and returns
# with the appropriate status flags (either TRUE or FALSE) in the status
# register.
Also:
http://developer.apple.com/techpubs/mac/Text/Text-516.html
Shows Return key mapped to $0D.
Interesting note from:
http://developer.apple.com/technotes/tb/tb_12.html
# * The Macintosh International keyboard and the ISO ADB keyboards have an
# extra key that is not present on the domestic keyboards. This key
# produces virtual keycode $0A.
Cool. :) And finally:
http://developer.apple.com/techpubs/mac/Files/Files-16.html
# You can also read a continuous stream of characters or a line of
# characters from a file. In the first case, you ask the File Manager to
# read a specific number of bytes: When that many have been read, or when
# the mark reaches the logical end-of-file, the read operation terminates.
# In the second case, called newline mode, the read operation terminates
# when either of the above conditions is met or when a specified
# character, the newline character, is read. The newline character is
# usually Return (ASCII code $0D), but it can be any character.
# Information about newline mode is associated with each access path to a
# file and can differ from one access path to another. See the chapter
# "File Manager" in this book for more information about newline mode.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 15:42:29 -0500
From: "Paul J. Schinder" <schinder@pobox.com>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
On Mon, Mar 01, 1999 at 04:05:05PM -0400, Arved Sandstrom wrote:
} On Mon, 1 Mar 1999, David Steffen wrote:
} >
} [ Examples snipped ]
}
} > Does this help?
} >
} It's an excellent start. Thanks. Certainly the kind of stuff I can use.
}
} That thing about TeachText is pretty conclusive. I think Chris Nandor was
} sort of alluding to the same thing.
Whoa. Now, I'm confused. What is it exactly that you are asking?
That MacOS uses \015 as end-of-line is easily demonstrated. That
MacPerl uses \n == \015 is also easily demonstrated, and that it
*should be* that way takes only a little thought. That \n is always
\015 in every Mac application that uses C-like escapes is simply
wrong. Alpha is a counter example; they use \r == \015.
So what is it that you are trying to prove? That MacOS uses \015 as
end of line, that MacPerl uses \n == \015, or that \n == \015 is a
general MacOS convention? I've never seen any Official Documentation
(TM) that says that MacOS end of line is \015, but anyone with a Mac
and MacPerl can easily demonstrate that it is by looking at any of the
README's that come with Apple software. Why anyone would want to
argue with you about that is beyond me.
}
} I've got IM:Text at home in DocViewer so I'll look at that later. The way
} Apple has some of their online docs now is not nearly so nice. Personally
} I thought DocViewer was fine, but they seem to be moving more and more
} over to PDF, which makes me want to buy more and more of the real books on
} paper. ;-)
}
} Arved
}
}
}
} ==== Want to unsubscribe from this list?
} ==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
}
- --
Paul Schinder
schinder@pobox.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 15:52:25 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
At 15.42 -0500 1999.03.01, Paul J. Schinder wrote:
>So what is it that you are trying to prove? That MacOS uses \015 as
>end of line, that MacPerl uses \n == \015, or that \n == \015 is a
>general MacOS convention?
Basically.
>I've never seen any Official Documentation
>(TM) that says that MacOS end of line is \015, but anyone with a Mac
>and MacPerl can easily demonstrate that it is by looking at any of the
>README's that come with Apple software. Why anyone would want to
>argue with you about that is beyond me.
I don't think that anyone is disputing it, but they want documentation,
especially since they probably don't have Macs to test with.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 06:11:43 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
On Mon, 1 Mar 1999, Paul J. Schinder wrote:
> On Mon, Mar 01, 1999 at 04:05:05PM -0400, Arved Sandstrom wrote:
> } That thing about TeachText is pretty conclusive. I think Chris Nandor was
> } sort of alluding to the same thing.
>
> Whoa. Now, I'm confused. What is it exactly that you are asking?
> That MacOS uses \015 as end-of-line is easily demonstrated. That
> MacPerl uses \n == \015 is also easily demonstrated, and that it
> *should be* that way takes only a little thought. That \n is always
> \015 in every Mac application that uses C-like escapes is simply
> wrong. Alpha is a counter example; they use \r == \015.
>
> So what is it that you are trying to prove? That MacOS uses \015 as
> end of line, that MacPerl uses \n == \015, or that \n == \015 is a
> general MacOS convention? I've never seen any Official Documentation
> (TM) that says that MacOS end of line is \015, but anyone with a Mac
> and MacPerl can easily demonstrate that it is by looking at any of the
> README's that come with Apple software. Why anyone would want to
> argue with you about that is beyond me.
The discussion over on Perl-XML has, I think, gotten to a crux. There is
general agreement that in a Perl script (including module tests) which
uses Perl XML modules, that returned XML _must_ contain \012 characters
for the line-ends.
Up to this point most (not all) of the XML module authors and users have
been able to get away with a lot - they've been returning XML and
comparing it directly to original content, because this works on Unix. I
just finished building XML::Parser-2.20 - there was one test failure there
due to the fact that '.' was being used in a RE to identify XML line-ends.
Again, only on Unix.
There will be some serious revision of tests aand scripts and what have
you in order to make them portable, which by Perl's def'n of \n these
folks will have to do. I anticipate that they will want some solid
evidence, like Chris and David located, that the MacOS line-end is indeed
\015, before they change their mindset.
There was also some murmuring that the XML spec is flawed in this regard.
It seemed to me that Larry Wall took a position with respect to this that
is quite supportive of MacOS, and some Windows guys were helping out, too.
It was quite indicative of how things are at the moment that Tim Bray, who
figures prominently in XML spec development, clearly believed that XML
lineends were being crunched to '\n' on all OS's. So to promote some
education here I'd also like to have good refs handy.
I propose not to ever mention Alpha, or BBEdit, or Codewarrior, etc, in
this thread over on Perl-XML. It muddies the waters, I think. These are
sophisticated text editors that accept any line-ends. If I mention them,
it's just ammo for the other side that wants to say, "Well, if those apps
can handle it, why can't they all?"
Hope that clarifies matters. Arved
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 08:09:55 -0500
From: "Paul J. Schinder" <schinder@pobox.com>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
On Tue, Mar 02, 1999 at 06:11:43AM -0400, Arved Sandstrom wrote:
}
} There will be some serious revision of tests aand scripts and what have
} you in order to make them portable, which by Perl's def'n of \n these
} folks will have to do. I anticipate that they will want some solid
} evidence, like Chris and David located, that the MacOS line-end is indeed
} \015, before they change their mindset.
But that's simply nuts. These arrogant clowns won't simply believe a
regular MacOS user about end-of-line? They won't take the few minutes
it takes to verify this? (You could, for example, ftp an official
Apple SimpleText document in binary mode if they can't find a Mac.)
Maybe it's my training as a scientist, but what end-of-line is used is
an empirical fact that is easily determined by experiment. There's no
need for documentation here. I'd be hard pressed to find a document
that says that Unix uses \012, and it'd be a waste of my time, because
it's a matter of seconds to type "od -a /etc/passwd" and look.
(Kernighan and Ritchie may say that, but K & R isn't a description of
Unix, and K & R is wrong about what \n means.)
}
} There was also some murmuring that the XML spec is flawed in this regard.
} It seemed to me that Larry Wall took a position with respect to this that
} is quite supportive of MacOS, and some Windows guys were helping out, too.
} It was quite indicative of how things are at the moment that Tim Bray, who
} figures prominently in XML spec development, clearly believed that XML
} lineends were being crunched to '\n' on all OS's. So to promote some
} education here I'd also like to have good refs handy.
}
} I propose not to ever mention Alpha, or BBEdit, or Codewarrior, etc, in
} this thread over on Perl-XML. It muddies the waters, I think. These are
} sophisticated text editors that accept any line-ends. If I mention them,
} it's just ammo for the other side that wants to say, "Well, if those apps
} can handle it, why can't they all?"
That's fine. That's not the question you're trying to answer. The
question you're trying to convince them of is the trivial one.
Amazing. Laziness may be one of the virtues of a programmer, but it
can go too far.
}
} Hope that clarifies matters. Arved
}
}
- --
Paul Schinder
schinder@pobox.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 02 Mar 1999 08:26:11 -0500
From: "Mark L. Boriack" <mboriack@sito.saic.com>
Subject: Re: [MacPerl-Modules] Re: [MacPerl-Porters] Need authoritative Apple refs for EOL == CR
While the following reference does not carry the authority of, say, a
specification, a newly posted Apple Technote (on the dangers of using
println in Java) discusses the end-of-line situation:
The link is:
http://developer.apple.com/technotes/tn/tn1157.html
- -mark
- --
==================================================================
Mark L. Boriack
Science Applications International Corporation
5400 Shawnee Road
Suite 110
Alexandria, VA 22312-2300
Email : mboriack@sito.saic.com
Voice : 703-333-5430
FAX : 703-354-5227
+++++ SAIC - An Employee-Owned Company +++++
==================================================================
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 10:57:49 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: Re: [MacPerl-Modules] Re: Need authoritative Apple refs for EOL == CR
On Tue, 2 Mar 1999, Paul J. Schinder wrote:
> On Tue, Mar 02, 1999 at 06:11:43AM -0400, Arved Sandstrom wrote:
> }
> } There will be some serious revision of tests aand scripts and what have
> } you in order to make them portable, which by Perl's def'n of \n these
> } folks will have to do. I anticipate that they will want some solid
> } evidence, like Chris and David located, that the MacOS line-end is indeed
> } \015, before they change their mindset.
>
> But that's simply nuts. These arrogant clowns won't simply believe a
> regular MacOS user about end-of-line? They won't take the few minutes
> it takes to verify this? (You could, for example, ftp an official
> Apple SimpleText document in binary mode if they can't find a Mac.)
>
Well, it may come to that. :-) I don't want to give the impression that
anyone party to this Perl-XML discussion has actually come out and said
they don't believe that \n != \xA on Macs. So, as I stated above, I asked
for assistance in getting some refs in _anticipation_ of people asking for
hard proof. It may or may not be requested.
Most of the folks involved in this discussion are in my time zone give or
take 4 hours or so. A lot of the real nitty-gritty got hashed out
yesterday, but I'd bet that after last-night's sleep the implications of
this line-end thing are maybe starting to sink in. It's been really
convenient for the Unix types up to now that are writing and using Perl
XML modules; XML EOL's match Unix EOL's, so they've beem writing module
tests and what have you with careless abandon, comparing returned XML to
original content, with not a thought that this ain't gonna work on all
OS's.
It's been rather revealing, also, to find out that when the XML spec was
done up, that they decided, let's crunch all line-ends into \xA, because
that's \n, and hence it'll be handy for everyone. It's not that there
wasn't an awareness that \xD is EOL on Macs, and \xD\xA on Windows, but I
really get the impression that they thought that \n == \xA on *all*
systems, but that Macs use \r for EOL, and Windows uses \r\n.
So it seems to me that the XML folks thought that, OK, as long as the Mac
programmer parses XML using \n, he or she is OK. Basically a
misunderstanding: they thought that \n == \xA, when actually \n ==
'logical newline'.
> Maybe it's my training as a scientist, but what end-of-line is used is
> an empirical fact that is easily determined by experiment. There's no
> need for documentation here. I'd be hard pressed to find a document
> that says that Unix uses \012, and it'd be a waste of my time, because
> it's a matter of seconds to type "od -a /etc/passwd" and look.
> (Kernighan and Ritchie may say that, but K & R isn't a description of
> Unix, and K & R is wrong about what \n means.)
Well, I agree. My background is physics, and I'm pretty happy with
preponderance of proof myself. I don't think *I* could easily locate a
hypothetical doc that says Unix NL == \012 either.
One reason I'm pre-arming myself with refs and docs is this: once you've
been doing XML for just a little while (it doesn't take more than a few
weeks), you quickly realize that the XML working groups and their W3C
counterparts are worse than gov't when it comes to generating paper. It
appears that they can't decide whether to go to the bathroom without
forming a Steering Committee, establishing a few spinoff Working Groups,
which then generate Technical Notes, probably with Official Errata, all of
which then comes together as a Recommendation. :-)
Most of the Perl+XML guys aren't this anal. They're actually trying to
usefully implement XML. But this discussion went over into the realm of
"Is XML flawed?", there's a few straight-XML types involved, and like I
say, I have a hunch that *they* will ultimately want paper. That's
assuming that they don't just ignore the whole problem.
Arved
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 10:19:28 -0500
From: "Paul J. Schinder" <schinder@pobox.com>
Subject: Re: [MacPerl-Modules] Re: Need authoritative Apple refs for EOL == CR
On Tue, Mar 02, 1999 at 10:57:49AM -0400, Arved Sandstrom wrote:
}
} Most of the Perl+XML guys aren't this anal. They're actually trying to
} usefully implement XML. But this discussion went over into the realm of
} "Is XML flawed?", there's a few straight-XML types involved, and like I
} say, I have a hunch that *they* will ultimately want paper. That's
} assuming that they don't just ignore the whole problem.
OK, now I understand the problem. (The best thing to do with
bureaucrats is to ignore them if you can, but you can't.) It'd help
if *Apple* would get it right; did you look at the TechNote mentioned
this morning? I'm not interested enough to dig into my Java book and
see if \n is hardwired to \012 in the Java spec (p.s. well, ok. I
did. It is. That's nuts. No wonder they need a println.) . But if
it isn't, then Apple fouls up again, since the TN assumed it was.
You know the relevant section of the ISO C standard, right? Matthias
posted it to the list a long time ago (so long ago that it may be in
Sandra Silcot's archive). As I recall, it says that \n is a platform
dependent symbol for end-of-line straight out, and is not a hard wired
constant. I don't know of a reference offhand, but if you can find
it, that would seem to me to be a show stopper. (Precedence by
another official committee and all that.) Then ask them to consider
how portable code itself would be if \n were a hardwired constant but
EOL differed (as they are beginning to realise, it sounds like).
}
} Arved
}
}
}
}
- --
Paul Schinder
schinder@pobox.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 12:59:03 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: Re: [MacPerl-Modules] Re: Need authoritative Apple refs for EOL == CR
On Tue, 2 Mar 1999, Paul J. Schinder wrote:
> On Tue, Mar 02, 1999 at 10:57:49AM -0400, Arved Sandstrom wrote:
> }
> } Most of the Perl+XML guys aren't this anal. They're actually trying to
> } usefully implement XML. But this discussion went over into the realm of
> } "Is XML flawed?", there's a few straight-XML types involved, and like I
> } say, I have a hunch that *they* will ultimately want paper. That's
> } assuming that they don't just ignore the whole problem.
>
> OK, now I understand the problem. (The best thing to do with
> bureaucrats is to ignore them if you can, but you can't.) It'd help
> if *Apple* would get it right; did you look at the TechNote mentioned
> this morning? I'm not interested enough to dig into my Java book and
> see if \n is hardwired to \012 in the Java spec (p.s. well, ok. I
> did. It is. That's nuts. No wonder they need a println.) . But if
> it isn't, then Apple fouls up again, since the TN assumed it was.
>
Yeah, I did look at that Technote, then I wished I hadn't. ;-)
For my part, if someone says ASCII newline (NL), then I *always*
understand that to be octal 12, decimal 10, and hex \xA. But I no longer
understand '\n' to be ASCII newline, and it's unfortunate that Java seems
to have made it that way.
> You know the relevant section of the ISO C standard, right? Matthias
> posted it to the list a long time ago (so long ago that it may be in
> Sandra Silcot's archive). As I recall, it says that \n is a platform
> dependent symbol for end-of-line straight out, and is not a hard wired
> constant. I don't know of a reference offhand, but if you can find
> it, that would seem to me to be a show stopper. (Precedence by
> another official committee and all that.) Then ask them to consider
> how portable code itself would be if \n were a hardwired constant but
> EOL differed (as they are beginning to realise, it sounds like).
I'm going to be locating it with a quickness. :-) You're quite right - an
official pronouncement pertaining to ISO C would carry some serious
weight.
For what it's worth, let me inject a note of optimism here. As Chris
Nandor already knows, Clark Cooper incorporated changes into the latest
XML::Parser (2.20) that recognize this issue. In point of fact, the new
version builds without porting (although some of the tests still need to
be ported, mostly because of filepath things). Furthermore, as I alluded
to before, the problem really isn't with the XML module authors. A fair
amount of them have weighed in on this, thee seems to be willingness to
work towards a solution, and we'll see what happens.
Unfortunately it looks like the XML spec authors out-clevered themselves.
If, as seems likely, they had the idea that the XML line-break should be
\n, then they were on the right track. But they blew it when they thought
that \n == \xA, and hardwired in the latter (and indeed, the XML spec says
\xA). If they'd just left it at \n, we'd be laughing. But I'm going to hit
them with the ISO C thing, and shake 'em up. :-) [ Mind you, it didn't
hurt that Larry Wall came right out and said maybe there's problems with
the spec, not with the Perl implementation of it. :-) ]
Arved
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 15:36:16 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] Other MMP stuff
I was thinking about this the other day, and it came up with XML::Parser.
What to do to check out a new version of an existing module? Maybe I
should have a separate column for "download", where you can get the
existing port? So even if nothing is in the "done" column, you could
download an old version if present.
What say you?
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 15:33:53 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Modules] MMP
What do people think about making a link on the MMP page for people to send
ideas for new modules to port/build and feedback on existing ports/builds,
that would be sent to macperl-modules@perl.org?
Two issues: one, do we want the traffic coming to this list, and two, is
the list enabled for such outside mails.
Or do we want a separate mailing list (yet another!), maybe
mmp@macperl.org? I personally thing that the existing list should be fine
until the traffic increases to the point where it no longer makes sense.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 16:04:32 -0500
From: "Paul J. Schinder" <schinder@pobox.com>
Subject: Re: [MacPerl-Modules] Other MMP stuff
On Tue, Mar 02, 1999 at 03:36:16PM -0500, Chris Nandor wrote:
} I was thinking about this the other day, and it came up with XML::Parser.
} What to do to check out a new version of an existing module? Maybe I
} should have a separate column for "download", where you can get the
} existing port? So even if nothing is in the "done" column, you could
} download an old version if present.
}
} What say you?
Something like this should be done. I'm not sure whether "download"
is the right word. Then again, I'm not sure whether "Done" is the
right word. Maybe "current port" and "previous port"?
}
} --
} Chris Nandor mailto:pudge@pobox.com http://pudge.net/
} %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
- --
Paul Schinder
schinder@pobox.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 17:20:21 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Modules] Other MMP stuff
At 16.04 -0500 1999.03.02, Paul J. Schinder wrote:
>Something like this should be done. I'm not sure whether "download"
>is the right word. Then again, I'm not sure whether "Done" is the
>right word. Maybe "current port" and "previous port"?
I figure just one link to the most recent available download is sufficient.
Maybe it isn't. I am willing to entertain discussion.
I did have another thought as I looked at the site. I am thinking about
not linking directly to the distribution, but just linking to cpan.perl.com
as we do now, which links to the most recent distribution. And then adding
another link to CPAN Testers. Problem with CPAN Testers is that we go by
distribution there, where on MMP and cpan.perl.com we go by module name.
So maybe the slot now that contains link to the distribution could be
instead the distribution name, which would make it easy to link to CPAN
Testers.
Why link to CPAN Testers at all? Because we can. More interoperability.
- --
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 20:54:01 -0500
From: "Paul J. Schinder" <schinder@pobox.com>
Subject: Re: [MacPerl-Modules] Other MMP stuff
On Tue, Mar 02, 1999 at 05:20:21PM -0500, Chris Nandor wrote:
} At 16.04 -0500 1999.03.02, Paul J. Schinder wrote:
} >Something like this should be done. I'm not sure whether "download"
} >is the right word. Then again, I'm not sure whether "Done" is the
} >right word. Maybe "current port" and "previous port"?
}
} I figure just one link to the most recent available download is sufficient.
} Maybe it isn't. I am willing to entertain discussion.
One link probably is fine, so long as it can be made clear that
"what's available for MacPerl at the moment isn't a port of the latest
version". Since you insist on using new fangled lynx unfriendly
tables :-), maybe make it a little more lynx unfriendly and use color
coded text or something to indicate "this isn't the latest yet"?
Maybe even an icon :-) ?
}
} I did have another thought as I looked at the site. I am thinking about
} not linking directly to the distribution, but just linking to cpan.perl.com
} as we do now, which links to the most recent distribution. And then adding
} another link to CPAN Testers. Problem with CPAN Testers is that we go by
} distribution there, where on MMP and cpan.perl.com we go by module name.
} So maybe the slot now that contains link to the distribution could be
} instead the distribution name, which would make it easy to link to CPAN
} Testers.
Module name isn't always a good idea, anyway. For example, libnet,
Mailtools, etc.
}
} Why link to CPAN Testers at all? Because we can. More interoperability.
Sounds good to me.
}
} --
} Chris Nandor mailto:pudge@pobox.com http://pudge.net/
} %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
}
- --
Paul Schinder
schinder@pobox.com
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org
------------------------------
End of macperl-modules-digest V1 #3
***********************************
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-modules-request@macperl.org