[32315] in Perl-Users-Digest
Perl-Users Digest, Issue: 3582 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 6 21:09:31 2012
Date: Fri, 6 Jan 2012 18:09:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 6 Jan 2012 Volume: 11 Number: 3582
Today's topics:
Re: how is the string encoded <ben@morrow.me.uk>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded (Seymour J.)
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <hjp-usenet2@hjp.at>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <hjp-usenet2@hjp.at>
Re: how is the string encoded (Seymour J.)
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <hjp-usenet2@hjp.at>
Re: how is the string encoded <rweikusat@mssgmbh.com>
Re: how is the string encoded <kaz@kylheku.com>
Re: how is the string encoded <ben@morrow.me.uk>
PhD Positions at ETH Zurich <jobs.ethz.pm@gmail.com>
Re: POD module synopses? (Seymour J.)
use statements in packages <sigzero@gmail.com>
Re: use statements in packages <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 4 Jan 2012 23:51:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how is the string encoded
Message-Id: <d85ft8-07f.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
> >
> > It is very useful to know that perl assumes the source to be
> > ISO8859-1.
>
> This is not quite correct. Without 'use utf8', perl assumes your source
> is an unspecified superset of ASCII, not ISO-8859-1. The character codes
> are the same, but the semantics are different. For example, if your
> script was encoded in ISO-8859-1, "ä" would result in string consisting
> of a single byte with the value 0xE4, but that byte is not equivalent to
> the character "ä" - it doesn't match \w, [:lower:] or any of the other
> classes "LATIN SMALL LETTER A WITH DIAERESIS" should match. It cannot be
> uppercased. It is just a meaningless byte, not a character.
Aieiee, this is where we run bang smack into The Unicode Bug. Yes, that
string doesn't match \w, but as soon as you do anything that causes it
to be upgraded, it will. If you actually care about the distinction
between ISO8859-1 and ASCII you need to use 5.14 and the /a switch.
> > What I needed was 'use Encode' which is what I am doing now.
>
> Please don't unless you really understand what it does. Encode does a
> couple of different things and it isn't entirely consistent. It seemed
> like a good idea at the time and it may have been useful for converting
> pre-5.8-code, but I really wouldn't use it for new code.
Are you (either of you, in fact) thinking of 'use encoding'? That pragma
is, as I said originally, a Bad Idea. Encode, OTOH, is perfectly
reliable, and cannot be avoided if you want to use data in any encoding
other than UTF-8.
Ben
------------------------------
Date: Thu, 05 Jan 2012 01:23:00 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87y5tn6iyz.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
[...]
>> > What I needed was 'use Encode' which is what I am doing now.
>>
>> Please don't unless you really understand what it does. Encode does a
>> couple of different things and it isn't entirely consistent. It seemed
>> like a good idea at the time and it may have been useful for converting
>> pre-5.8-code, but I really wouldn't use it for new code.
>
> Are you (either of you, in fact) thinking of 'use encoding'? That pragma
> is, as I said originally, a Bad Idea.
This would then be another documented Perl which managed to run afoul
of someone's opinions. Is their actually any other reason than "it's a
convenient way to do what shalt not be done"?
------------------------------
Date: Thu, 05 Jan 2012 10:29:10 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: how is the string encoded
Message-Id: <4f05c1c6$11$fuzhry+tra$mr2ice@news.patriot.net>
In <87y5tn6iyz.fsf@sapphire.mobileactivedefense.com>, on 01/05/2012
at 01:23 AM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>This would then be another documented Perl which managed to run
>afoul of someone's opinions.
No.
>Is their actually any other reason than "it's a
>convenient way to do what shalt not be done"?
Yes.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 05 Jan 2012 16:06:27 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87ty4am8vw.fsf@sapphire.mobileactivedefense.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> at 01:23 AM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>
>>This would then be another documented Perl which managed to run
>>afoul of someone's opinions.
>
> No.
It's documented:
[rw@sapphire]/tmp $whatis encoding
encoding (3perl) - allows you to write your script in non-ascii or non-utf8
But according to the opinion of someone, it shouldn't be used.
>>Is their actually any other reason than "it's a
>>convenient way to do what shalt not be done"?
>
> Yes.
And - as usual - no reasons beyond 'thou shalt do as I bid you and not
ask silly questions' are given.
------------------------------
Date: Thu, 5 Jan 2012 19:10:34 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how is the string encoded
Message-Id: <slrnjgbpsq.hbo.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-04 23:51, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
>> >
>> > It is very useful to know that perl assumes the source to be
>> > ISO8859-1.
>>
>> This is not quite correct. Without 'use utf8', perl assumes your source
>> is an unspecified superset of ASCII, not ISO-8859-1. The character codes
>> are the same, but the semantics are different. For example, if your
>> script was encoded in ISO-8859-1, "ä" would result in string consisting
>> of a single byte with the value 0xE4, but that byte is not equivalent to
>> the character "ä" - it doesn't match \w, [:lower:] or any of the other
>> classes "LATIN SMALL LETTER A WITH DIAERESIS" should match. It cannot be
>> uppercased. It is just a meaningless byte, not a character.
>
> Aieiee, this is where we run bang smack into The Unicode Bug. Yes, that
> string doesn't match \w, but as soon as you do anything that causes it
> to be upgraded, it will.
Yup, but unless you do something which causes it to be upgraded, it
won't. So if you care about it being ISO-8859-1, you have to either
force an upgrade or decode it. So I prefer to think of it as an
"unspecified superset of ASCII" and not as "almost but not quite
ISO-8859-1".
>> > What I needed was 'use Encode' which is what I am doing now.
>>
>> Please don't unless you really understand what it does. Encode does a
>> couple of different things and it isn't entirely consistent. It seemed
>> like a good idea at the time and it may have been useful for converting
>> pre-5.8-code, but I really wouldn't use it for new code.
>
> Are you (either of you, in fact) thinking of 'use encoding'?
Yes, sorry. I misread what dn.perl@gmail.com wrote.
> That pragma is, as I said originally, a Bad Idea. Encode, OTOH, is
> perfectly reliable, and cannot be avoided if you want to use data in
> any encoding other than UTF-8.
Right. I use that quite frequently, actually.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Thu, 05 Jan 2012 18:43:59 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87hb0am1lc.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2012-01-04 23:51, Ben Morrow <ben@morrow.me.uk> wrote:
>>
>> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>>> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
>>> >
>>> > It is very useful to know that perl assumes the source to be
>>> > ISO8859-1.
>>>
>>> This is not quite correct. Without 'use utf8', perl assumes your source
>>> is an unspecified superset of ASCII, not ISO-8859-1. The character codes
>>> are the same, but the semantics are different. For example, if your
>>> script was encoded in ISO-8859-1, "ä" would result in string consisting
>>> of a single byte with the value 0xE4, but that byte is not equivalent to
>>> the character "ä" - it doesn't match \w, [:lower:] or any of the other
>>> classes "LATIN SMALL LETTER A WITH DIAERESIS" should match. It cannot be
>>> uppercased. It is just a meaningless byte, not a character.
>>
>> Aieiee, this is where we run bang smack into The Unicode Bug. Yes, that
>> string doesn't match \w, but as soon as you do anything that causes it
>> to be upgraded, it will.
>
> Yup, but unless you do something which causes it to be upgraded, it
> won't. So if you care about it being ISO-8859-1, you have to either
> force an upgrade or decode it. So I prefer to think of it as an
> "unspecified superset of ASCII"
Assuming that locale information isn't being used, it is ASCII and not
'a superset of ASCII' since no byte value outside the subset of
possible byte values used by the ASCII encoding has any 'character
properties' (except being considered 'a non-word character', that is).
------------------------------
Date: Fri, 6 Jan 2012 11:54:32 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how is the string encoded
Message-Id: <slrnjgdkn8.l4h.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-05 18:43, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2012-01-04 23:51, Ben Morrow <ben@morrow.me.uk> wrote:
>>> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>>>> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
>>>> >
>>>> > It is very useful to know that perl assumes the source to be
>>>> > ISO8859-1.
>>>>
>>>> This is not quite correct. Without 'use utf8', perl assumes your source
>>>> is an unspecified superset of ASCII, not ISO-8859-1. The character codes
>>>> are the same, but the semantics are different.
[...]
>>> Aieiee, this is where we run bang smack into The Unicode Bug. Yes, that
>>> string doesn't match \w, but as soon as you do anything that causes it
>>> to be upgraded, it will.
>>
>> Yup, but unless you do something which causes it to be upgraded, it
>> won't. So if you care about it being ISO-8859-1, you have to either
>> force an upgrade or decode it. So I prefer to think of it as an
>> "unspecified superset of ASCII"
>
> Assuming that locale information isn't being used, it is ASCII and not
> 'a superset of ASCII' since no byte value outside the subset of
> possible byte values used by the ASCII encoding has any 'character
> properties' (except being considered 'a non-word character', that is).
ASCII is a 7 bit code. As soon as you have a byte with value >= 0x80 it
isn't ASCII any more.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Thu, 05 Jan 2012 18:02:13 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: how is the string encoded
Message-Id: <4f062bf5$4$fuzhry+tra$mr2ice@news.patriot.net>
In <87ty4am8vw.fsf@sapphire.mobileactivedefense.com>, on 01/05/2012
at 04:06 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>It's documented:
What's documented, the feature or the claim that the only reason to
not use it is because it ran afoul of someone's opinion. Or do you
consider bug reports to be only opinions?
>But according to the opinion of someone, it shouldn't be used.
Well, the opinions of the people who tried to fix the bugs.
>And - as usual - no reasons beyond 'thou shalt do as I bid you and
>not ask silly questions' are given.
And, as usual, you are inventing claims that nobody actually made. If
you can't paraphrase in an accurate fashion then use exact quotes.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 06 Jan 2012 20:53:42 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87hb08h7s9.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2012-01-05 18:43, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>> On 2012-01-04 23:51, Ben Morrow <ben@morrow.me.uk> wrote:
>>>> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>>>>> On 2012-01-04 07:38, dn.perl@gmail.com <dn.perl@gmail.com> wrote:
>>>>> >
>>>>> > It is very useful to know that perl assumes the source to be
>>>>> > ISO8859-1.
>>>>>
>>>>> This is not quite correct. Without 'use utf8', perl assumes your source
>>>>> is an unspecified superset of ASCII, not ISO-8859-1. The character codes
>>>>> are the same, but the semantics are different.
> [...]
>>>> Aieiee, this is where we run bang smack into The Unicode Bug. Yes, that
>>>> string doesn't match \w, but as soon as you do anything that causes it
>>>> to be upgraded, it will.
>>>
>>> Yup, but unless you do something which causes it to be upgraded, it
>>> won't. So if you care about it being ISO-8859-1, you have to either
>>> force an upgrade or decode it. So I prefer to think of it as an
>>> "unspecified superset of ASCII"
>>
>> Assuming that locale information isn't being used, it is ASCII and not
>> 'a superset of ASCII' since no byte value outside the subset of
>> possible byte values used by the ASCII encoding has any 'character
>> properties' (except being considered 'a non-word character', that is).
>
> ASCII is a 7 bit code. As soon as you have a byte with value >= 0x80 it
> isn't ASCII any more.
As soon as a byte with value > 127 is considered to be some character,
it isn't ASCII anymore but a superset of ASCII.
------------------------------
Date: Fri, 06 Jan 2012 21:00:10 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87d3awh7hh.fsf@sapphire.mobileactivedefense.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> In <87ty4am8vw.fsf@sapphire.mobileactivedefense.com>, on 01/05/2012
> at 04:06 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>
>>It's documented:
>
> What's documented the feature or the claim that the only reason to
> not use it is because it ran afoul of someone's opinion.
Try an educated guess based on the content of the text I wrote. I'm
giving you a gratis hint: I quoted the 'name' section of the encoding
manual page.
[...]
>>But according to the opinion of someone, it shouldn't be used.
>
> Well, the opinions of the people who tried to fix the bugs.
The mere fact that somebody failed at doing something ('tried to fix a
bug') doesn't really make that someone authoritative on anything.
>>And - as usual - no reasons beyond 'thou shalt do as I bid you and
>>not ask silly questions' are given.
>
> And, as usual, you are inventing claims that nobody actually made.
That claim was implicit in your refusal to give a reason.
------------------------------
Date: Fri, 6 Jan 2012 22:26:52 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how is the string encoded
Message-Id: <slrnjgepos.og4.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-06 20:53, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2012-01-05 18:43, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>> So I prefer to think of it as an "unspecified superset of ASCII"
>>>
>>> Assuming that locale information isn't being used, it is ASCII and not
>>> 'a superset of ASCII' since no byte value outside the subset of
>>> possible byte values used by the ASCII encoding has any 'character
>>> properties' (except being considered 'a non-word character', that is).
>>
>> ASCII is a 7 bit code. As soon as you have a byte with value >= 0x80 it
>> isn't ASCII any more.
>
> As soon as a byte with value > 127 is considered to be some character,
> it isn't ASCII anymore but a superset of ASCII.
Glad you agree.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 07 Jan 2012 00:13:11 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how is the string encoded
Message-Id: <87r4zcjroo.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2012-01-06 20:53, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>> On 2012-01-05 18:43, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>>> So I prefer to think of it as an "unspecified superset of ASCII"
>>>>
>>>> Assuming that locale information isn't being used, it is ASCII and not
>>>> 'a superset of ASCII' since no byte value outside the subset of
>>>> possible byte values used by the ASCII encoding has any 'character
>>>> properties' (except being considered 'a non-word character', that is).
>>>
>>> ASCII is a 7 bit code. As soon as you have a byte with value >= 0x80 it
>>> isn't ASCII any more.
>>
>> As soon as a byte with value > 127 is considered to be some character,
>> it isn't ASCII anymore but a superset of ASCII.
>
> Glad you agree.
I don't: Since bytes with values > 127 are not considered to be
characters, it doesn't make sense to refer to this as 'superset of
ASCII': It would need some character outside of the ASCII range, not
just numbers which can also be stored in bytes because of the
hardware.
------------------------------
Date: Sat, 7 Jan 2012 00:39:28 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: how is the string encoded
Message-Id: <20120106163801.715@kylheku.com>
On 2012-01-07, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2012-01-06 20:53, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>> On 2012-01-05 18:43, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>>> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>>>>>> So I prefer to think of it as an "unspecified superset of ASCII"
>>>>>
>>>>> Assuming that locale information isn't being used, it is ASCII and not
>>>>> 'a superset of ASCII' since no byte value outside the subset of
>>>>> possible byte values used by the ASCII encoding has any 'character
>>>>> properties' (except being considered 'a non-word character', that is).
>>>>
>>>> ASCII is a 7 bit code. As soon as you have a byte with value >= 0x80 it
>>>> isn't ASCII any more.
>>>
>>> As soon as a byte with value > 127 is considered to be some character,
>>> it isn't ASCII anymore but a superset of ASCII.
>>
>> Glad you agree.
>
> I don't: Since bytes with values > 127 are not considered to be
> characters
That's not grounds to disagree. The union of the set of all bicycles and the
set of ASCII characters is a superset of the set of ASCII characters.
Also, the set of ASCII characters is a superset of the set of ASCII
characters (albeit not a proper superset).
:)
------------------------------
Date: Sat, 7 Jan 2012 00:58:04 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how is the string encoded
Message-Id: <sthkt8-p3l1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> The mere fact that somebody failed at doing something ('tried to fix a
> bug') doesn't really make that someone authoritative on anything.
I am not authoritative on anything. I have never claimed to be. I am
attempting to convey what I believe was the consensus on p5p, in the
hope that people here might find the information useful.
You are free to ignore me. I, and probably everyone else, would very
much rather you did.
Ben
------------------------------
Date: Thu, 5 Jan 2012 04:50:37 -0800 (PST)
From: =?ISO-8859-1?Q?Peter_M=FCller?= <jobs.ethz.pm@gmail.com>
Subject: PhD Positions at ETH Zurich
Message-Id: <d8d424ff-a7d4-4857-929e-976807265edf@ck5g2000vbb.googlegroups.com>
PhD Positions at ETH Zurich
The Chair of Programming Methodology is recruiting PhD students to do
research in the following areas:
=95 Static program analysis, especially abstract interpretation for
mobile TouchDevelop applications
=95 Verification of concurrent programs, especially Scala programs
=95 Programming languages
=95 Programming environments
More information about our research can be found at www.pm.inf.ethz.ch.
Key requirements for successful applications:
=95 Strong commitment to research
=95 Interest in combining theory and practice
=95 Proficiency in English and excellent communication skills, both oral
and written
=95 Excellent M.Sc. degree in Computer Science or in a related subject
with a strong Computer Science component. We will also consider
outstanding candidates with a B.Sc. degree.
Applications and questions should be sent to Prof. Peter M=FCller at
jobs-pm@inf.ethz.ch. The application should include a CV and a
description of research interests. We will consider applications until
the positions are filled. The start date is negotiable.
More details about the positions:
=95 A PhD or a postdoc position is a regular job with attractive salary
and social benefits
=95 A position is for a maximum of 6 years.
=95 ETH as one of the top computer science departments in the world: CS
University Rankings
=95 Zurich is consistently ranked among the top destinations in the
world for quality of life
=95 General information on doctoral studies at ETH is available at
www.ethz.ch/doctorate/index_EN and www.inf.ethz.ch/education/ds
------------------------------
Date: Thu, 05 Jan 2012 07:35:45 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: POD module synopses?
Message-Id: <4f059921$8$fuzhry+tra$mr2ice@news.patriot.net>
In <3f1ft8-6kd.ln1@anubis.morrow.me.uk>, on 01/04/2012
at 10:46 PM, Ben Morrow <ben@morrow.me.uk> said:
>OK. If you have (or can acquire) a decent understanding of the IPF
>file format, you may find it easier to start again using the
>Pod::Simple modules, in particular Pod::Simple::Search.
IPF is very similar to GML, the forerunner of SGML. It normally[1]uses
tags starting with ":" and ending with ".", and ending tags have an
"E" rather than a "/" at the beginning. The problems I've had so far
have not been because of IPF issues, but with problems in the build,
the code or the POD markup.
IPF expects subheadings to have a level exactly one greater than the
containing heading level. "Standard Perl modules" has cases where
=head4 directly follows =head2 or =heaq5 directly follows =head3. Is
that acceptable style that pod2ipf should handle, or is it improperly
formatted documentation that I should report?
Some things that are definitely bugs in pod2ipf are
1. It does not escape peiod in column 1 to &per.
2. It sometimes generates an empty :i1. tag
3. It needs to truncate long text in the :i1. tag.
5. It sometimes converts ":" to "&.colon." instead of "&colon."
Note: there's a minor bug in the HTML escape table; Aelig should be
AElig. It's possible that the same error exists in pod2html, since the
table was originally taken from there.
[1] For historical reasons some tags are a period in column 1
followed by two letters or by an asterisk[2].
[2] .* in column 1 designates a comment
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 5 Jan 2012 05:07:30 -0800 (PST)
From: Robert <sigzero@gmail.com>
Subject: use statements in packages
Message-Id: <c50d1f12-5f1e-4154-b87b-ac6b328d1417@t30g2000vbx.googlegroups.com>
So I was reading up on Dist::Zilla and I see a code snippet like:
use strict;
use warnings;
package Your::Library;
1;
I was always under the impression the "package" statement was the
first thing. Is there some advantage to having the use statements
above the package declaration?
Bob
------------------------------
Date: Thu, 5 Jan 2012 13:54:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: use statements in packages
Message-Id: <clmgt8-u1q.ln1@anubis.morrow.me.uk>
Quoth Robert <sigzero@gmail.com>:
> So I was reading up on Dist::Zilla and I see a code snippet like:
>
> use strict;
> use warnings;
> package Your::Library;
>
> 1;
>
> I was always under the impression the "package" statement was the
> first thing. Is there some advantage to having the use statements
> above the package declaration?
No, it make no difference. Pragmas like 'strict' and 'warnings' are
lexically-scoped rather than package-scoped, so any code that follows
them in the file will be affected, regardless of which package it's in
(unless they're overridden with a 'no <foo>', of course).
I wouldn't write them like that, simply because I tend to put modules
like 'Carp' next to strict and warnings, and in that case it *does* make
a difference: if you 'use Carp' in the wrong package, the subs will be
exported to the wrong place.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3582
***************************************
