[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
macperl-porters-digest v01.n003
From: owner-macperl-porters-digest@macperl.org (macperl-porters-digest)
To: macperl-porters-digest@macperl.org
Subject: macperl-porters-digest V1 #3
Reply-To: macperl-porters@macperl.org
Sender: owner-macperl-porters-digest@macperl.org
Errors-To: owner-macperl-porters-digest@macperl.org
Precedence: bulk
macperl-porters-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-Porters] 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-porters-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 13:35:04 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: 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-porters-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 15:14:01 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: 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-porters-request@macperl.org
------------------------------
Date: Mon, 1 Mar 1999 13:52:10 -0600
From: David Steffen <steffen@biomedcomp.com>
Subject: 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-porters-request@macperl.org
------------------------------
Date: Tue, 2 Mar 1999 20:46:38 -0500
From: Chris Nandor <pudge@pobox.com>
Subject: [MacPerl-Porters] possible bug on #! line, PERL5OPTS
I cannot put anything after an -MSome::Module on the #! line or in
$ENV{PERL5OPTS}.
Works:
#!perl -w -MData::Dumper
print Dumper {%ENV}
Doesn't:
#!perl -MData::Dumper -w
print Dumper {%ENV}
This should work, and does work under Unix. The greatest problem is when I
want to put multiple -M flags in PERL5OPTS.
- --
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-porters-request@macperl.org
------------------------------
End of macperl-porters-digest V1 #3
***********************************
==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-porters-request@macperl.org