>Leaving aside alternate backends (-MO=...) and the possibility of perl
>lying over and dying during the compile, there\'s still perl -c.
-c is "check syntax" and not "compile".
And there are also -h and -v, but I wouldn't take serious writing something
like "perl can be used for checking syntax
On Tue, Aug 09, 2005 at 01:38:11PM +0200, Piotr Fusik wrote:
> >+A program that compiles and usually executes L scripts. Or is
> >+that L?
>
> s/is that/are they/, I guess, but I may be wrong...
Implied "is that phrase in the previous sentence supposed to be".
"Or are they" would be correct also
>+A program that compiles and usually executes L scripts. Or is
>+that L?
s/is that/are they/, I guess, but I may be wrong...
s/usually //
On Thu, Jul 28, 2005 at 05:43:08PM -0500, David Nicol wrote:
> On 7/28/05, John P. Linderman <[EMAIL PROTECTED]> wrote:
>
> > is there any significant difference between "perl" and "Perl"?
>
> That is exactly the sort of edge case that is under discussion in
> this thread. One possibility is mai
On Thu, Jul 28, 2005 at 06:58:35PM -0400, Horsley, Tom wrote:
> And therefore only Linux will have the 2039 bug.
s/Linux/Unix/
Please let's not start confusing Linux with Unix or Redhat with Linux or
Windows with computers on p5p, too.
--
Michael G Schwern [EMAIL PROTECTED] http://w
> I doubt the wisdom of continuing to talk about Y2K compliance,
> here in Y2K+5. We could talk about Y2100 compliance.
Actually the next crisis is the 2039 problem (which will be utterly
ignored because Y2K was such a bust :-).
Microsoft is no doubt licking its chops and waiting for 2039
since
On Thu, Jul 28, 2005 at 02:55:10PM -0500, David Nicol wrote:
> I like the fact that the perl documentation is peppered
> with correct uses of "effect" as a verb.
>
> I doubt the wisdom of continuing to talk about Y2K compliance,
> here in Y2K+5. We could talk about Y2100 compliance.
I think folk
On 7/28/05, John P. Linderman <[EMAIL PROTECTED]> wrote:
> is there any significant difference between "perl" and "Perl"?
That is exactly the sort of edge case that is under discussion in
this thread. One possibility is maintaining an explicit glossary.pod file
which would not only answer that q
I tried to keep my mouth shut (Steve Hay can verify that).
There's a distinction between maintaining accepted use of
words from eliminating all possibility of misunderstanding
them. Should we eliminate "it's" and "its" and "their"
and "there" and "they're" because somebody can't get them
straight?
I like the fact that the perl documentation is peppered
with correct uses of "effect" as a verb.
I doubt the wisdom of continuing to talk about Y2K compliance,
here in Y2K+5. We could talk about Y2100 compliance.
> > Note that the $year element is I simply the last two digits of
> > -the year.
On 7/24/05, Piotr Fusik <[EMAIL PROTECTED]> wrote:
> --- perl-current/pod/perlfunc.pod Sun Jul 24 11:30:36 2005
> +++ perl-patched/pod/perlfunc.pod Sun Jul 24 11:38:16 2005
Thanks, applied as change #25241.
On Thu, Jul 28, 2005 at 03:50:57AM -0400, Randy W. Sims wrote:
> Usage Note: Affect and effect have no senses in common. As a verb affect
> is most commonly used in the sense of ?to influence? (how smoking
> affects health). Effect means ?to bring about or execute?: layoffs
> designed to effect
On Thu, Jul 28, 2005 at 09:53:18AM -0400, Ronald J Kimball ([EMAIL PROTECTED])
wrote:
> An aside on the whole "affect" vs. "effect" thing...
>
> In fact, both words have both a verb and a noun sense.
Quoting from _The Elements Of Style_, by Strunk & White, in the chapter
"Misused Words and Expre
An aside on the whole "affect" vs. "effect" thing...
In fact, both words have both a verb and a noun sense.
Affect as a verb means to influence or change.
Effect as a verb means to bring about.
Affect as a noun means a feeling or emotion.
Effect as a noun means a result or influence.
Affect has
On Thu, 28 Jul 2005, Steve Hay wrote:
> Nicholas Clark wrote:
>
> >On Thu, Jul 28, 2005 at 11:23:45AM +0100, Steve Hay wrote:
> >
> >>I didn't think it was confusing, but that be a minority opinion.
> >>
> >
> >Well, it's erudite, eloquent English written by someone with good vocabulary.
> >(Did t
Nicholas Clark wrote:
>On Thu, Jul 28, 2005 at 11:23:45AM +0100, Steve Hay wrote:
>
>
>
>>I didn't think it was confusing, but that be a minority opinion.
>>
>>
>
>Well, it's erudite, eloquent English written by someone with good vocabulary.
>(Did tchrist write it?)
>
>However it seems that
On Thu, Jul 28, 2005 at 05:32:56AM -0500, Steve Peters wrote:
> On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
> > I have doubts about the following changes:
> >
Clearly, I need to read my mailbox completely after waking up in the
morning :-/
Steve Peters
[EMAIL PROTECTED]
I've already applied the first patch, with the appropriate tweaks :-)
Steve Peters wrote:
>On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
>
>
>>I have doubts about the following changes:
>>
>>
>> Note that the $year element is I simply the last two digits of
>>-the year. If you a
On Thu, Jul 28, 2005 at 11:23:45AM +0100, Steve Hay wrote:
> I didn't think it was confusing, but that be a minority opinion.
Well, it's erudite, eloquent English written by someone with good vocabulary.
(Did tchrist write it?)
However it seems that
1: If you aren't native speaker, or don't not
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
> I have doubts about the following changes:
>
>
> Note that the $year element is I simply the last two digits of
> -the year. If you assume it is, then you create non-Y2K-compliant
> +the year. If you assume it is and then you creat
Nicholas Clark wrote:
>On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
>
>
>>I have doubts about the following changes:
>>
>>
>
>
>
>> Note that a block by itself is semantically identical to a loop
>>-that executes once. Thus C can be used to effect an early
>>+that executes
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
> I have doubts about the following changes:
> Note that a block by itself is semantically identical to a loop
> -that executes once. Thus C can be used to effect an early
> +that executes once. Thus C can be used to affect an early
>
Steve Peters wrote:
>This patch has it all: passive voice removals; spelling fixes; which vs.
>that change; e.g. fixes; and etc. Thanks to Pod::Simple::RTF and
>and handy grammar checker, this was all made much easier. Enjoy!
>
Thanks, applied as change 25234 with minor tweaks as suggested.
chromatic wrote:
On Thu, 2005-07-28 at 00:37 -0700, Michael G Schwern wrote:
Note that a block by itself is semantically identical to a loop
-that executes once. Thus C can be used to effect an early
+that executes once. Thus C can be used to affect an early
exit out of such a block.
effec
>> Note that a block by itself is semantically identical to a loop
>> -that executes once. Thus C can be used to effect an early
>> +that executes once. Thus C can be used to affect an early
>> exit out of such a block.
>
>effect is a noun. affect is a verb so I think this change is correct.
>
On Thu, 2005-07-28 at 00:37 -0700, Michael G Schwern wrote:
> > Note that a block by itself is semantically identical to a loop
> > -that executes once. Thus C can be used to effect an early
> > +that executes once. Thus C can be used to affect an early
> > exit out of such a block.
>
> effec
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote:
> Note that the $year element is I simply the last two digits of
> -the year. If you assume it is, then you create non-Y2K-compliant
> +the year. If you assume it is and then you create non-Y2K-compliant
> programs--and you wouldn't w
I have doubts about the following changes:
Note that the $year element is I simply the last two digits of
-the year. If you assume it is, then you create non-Y2K-compliant
+the year. If you assume it is and then you create non-Y2K-compliant
programs--and you wouldn't want to do that, would yo
This patch has it all: passive voice removals; spelling fixes; which vs.
that change; e.g. fixes; and etc. Thanks to Pod::Simple::RTF and
and handy grammar checker, this was all made much easier. Enjoy!
Steve Peters
[EMAIL PROTECTED]
--- pod/perlfunc.pod.old2005-07-27 11:57:23.000
On Tue, Jul 26, 2005 at 01:06:27AM -0700, Michael G Schwern wrote:
> Good point. Originally that said "unsuitable for encrypting" so the
> explaination made a bit more sense.
>
> I'd assume crypt() is unsuitable for large amounts of text because the
> hash size is too small and there's a signific
Michael G Schwern <[EMAIL PROTECTED]> writes:
> I'd assume crypt() is unsuitable for large amounts of text because the
> hash size is too small and there's a significant risk of collision, espcially
> if its DES. Anyone care to confirm?
I think it is because traditional versions of crypt would i
On Mon, Jul 25, 2005 at 03:30:52PM -0400, John L. Allen wrote:
> I thinks this last piece is confusing:
>
> The L function is unsuitable for hashing large quantities
> of data, not least of all because you can't get the information
> back. Look at the L module for more robust algorithms.
>
>
I thinks this last piece is confusing:
The L function is unsuitable for hashing large quantities
of data, not least of all because you can't get the information
back. Look at the L module for more robust algorithms.
Hashing is not done with the intent to get the data back, so that can't
be t
On Mon, Jul 25, 2005 at 11:21:24AM +0200, H.Merijn Brand wrote:
> > On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote:
> > > Personally, I don't like the new documentation in this patch. It seems to
> > > put the focus more on correcting the issue about encryption, rather than
> > >
On Sun, 24 Jul 2005 13:49:25 -0700, Michael G Schwern <[EMAIL PROTECTED]>
wrote:
> On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote:
> > Personally, I don't like the new documentation in this patch. It seems to
> > put the focus more on correcting the issue about encryption, rathe
On Sun, 24 Jul 2005 12:55:09 +0200, "Piotr Fusik" <[EMAIL PROTECTED]> wrote:
> I googled "definetely" and it seems to be widely used.
> But I found this:
> http://wikitravel.org/en/Wikitravel:List_of_common_misspellings
My spell checker agreed. Typo changed in #25219
> --- perl-current/pod/perlf
On Sun, Jul 24, 2005 at 11:09:12PM -0400, Ronald J Kimball wrote:
> Cool. I apologize for complaining about the parts that were already
> there.
You only have to apologize if you don't provide a patch. ;)
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me
On Sun, Jul 24, 2005 at 01:49:25PM -0700, Michael G Schwern wrote:
> Attached is a patch with some improvements after reading it through again.
>
> * Move the mentioning of Crypt modules on CPAN up to the point where we
> explain crypt() is not about cryptography instead of at the end.
> * Ment
On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote:
> Personally, I don't like the new documentation in this patch. It seems to
> put the focus more on correcting the issue about encryption, rather than
> actually documenting what crypt() does.
There's much less change then there se
On Sat, Jul 23, 2005 at 05:25:18PM -0700, Michael G Schwern wrote:
> Attached is a patch which replaces the term "encrypt" in the perlfunc/crypt
> documentation with "digest" or "hash" which more accurately describes what
> crypt does. I also added in some better explaination of what crypt does an
I googled "definetely" and it seems to be widely used.
But I found this:
http://wikitravel.org/en/Wikitravel:List_of_common_misspellings
--- perl-current/pod/perlfunc.pod Sun Jul 24 11:30:36 2005
+++ perl-patched/pod/perlfunc.pod Sun Jul 24 12:26:12 2005
@@ -3707,7 +3707,7 @@
platforms are using
> > [...] I wanted to clarify that do {}
> > isn't special for "for"/"foreach" modifiers
> > (they are loop modifiers, aren't they?).
>
> Good point. I guess they are.
>
--- perl-current/pod/perlfunc.pod Sun Jul 24 11:30:36 2005
+++ perl-patched/pod/perlfunc.pod Sun Jul 24 11:38:16 2005
@@ -1220
Attached is a patch which replaces the term "encrypt" in the perlfunc/crypt
documentation with "digest" or "hash" which more accurately describes what
crypt does. I also added in some better explaination of what crypt does and
what one-way hashing is useful for.
I tried to avoid "hash" where poss
Scott R Godin <[EMAIL PROTECTED]> writes:
> Firefox is merely being kind to all the silly web-authors out there who
> think it's a good idea to send XHTML as text/html instead of
> application/xhtml+xml because the latter breaks in nearly every browser
> due to the fact that they aren't prepared t
Rafael Garcia-Suarez wrote:
On 7/19/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
It would probably be better to evaluate the existing POD -> HTML converters
and wrap POD::Html around them, or just leave POD::Html alone and convert
installhtml to use the better module, than to write Yet Ano
Russ Allbery wrote:
Scott R Godin <[EMAIL PROTECTED]> writes:
There's only one real problem with that, however.
Sending XHTML as text/html means the browser is expecting tag-soup. NOT
XHTML..
This is not true if you use XHTML 1.0. Try it in Firefox. You'll see
that the browser reports th
On Jul 19, 2005, at 1:35 PM, Russ Allbery wrote:
Scott R Godin <[EMAIL PROTECTED]> writes:
Sending XHTML as text/html means the browser is expecting tag-soup.
NOT
XHTML..
This is not true if you use XHTML 1.0. Try it in Firefox. You'll see
that the browser reports that it's in standards c
On 7/19/05, Adriano Ferreira <[EMAIL PROTECTED]> wrote:
> On 7/19/05, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > But that doesn't rule out creating a minimal wrapper to provide Pod::Html's
> > interface.
>
> But that would imply that wrapped modules should enter the Perl
> distribution, because
On 7/19/05, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> But that doesn't rule out creating a minimal wrapper to provide Pod::Html's
> interface.
But that would imply that wrapped modules should enter the Perl
distribution, because Pod::Html is core. Right?
Adriano.
On Tue, Jul 19, 2005 at 08:59:33PM +0200, Rafael Garcia-Suarez wrote:
> On 7/19/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote:
> > > I've had this itch to rip Pod::Html to shreds for a while now, and
> > > refactor it to do the j
Michael G Schwern wrote:
On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote:
FAR better would be to use HTML 4.01 Strict instead of XHTML unless you
(because of MathML or some other such) know WHY you need it.
Ok, is there a decent POD -> HTML 4.01 Strict module out there?
oh
On 7/19/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote:
> > I've had this itch to rip Pod::Html to shreds for a while now, and
> > refactor it to do the job more cleanly. Would anyone object to my taking
> > a whack at it?
>
> It w
On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote:
> I've had this itch to rip Pod::Html to shreds for a while now, and
> refactor it to do the job more cleanly. Would anyone object to my taking
> a whack at it?
It would probably be better to evaluate the existing POD -> HTML conver
Michael G Schwern wrote:
On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote:
FAR better would be to use HTML 4.01 Strict instead of XHTML unless you
(because of MathML or some other such) know WHY you need it.
Ok, is there a decent POD -> HTML 4.01 Strict module out there?
If t
Scott R Godin <[EMAIL PROTECTED]> writes:
> There's only one real problem with that, however.
> Sending XHTML as text/html means the browser is expecting tag-soup. NOT
> XHTML..
This is not true if you use XHTML 1.0. Try it in Firefox. You'll see
that the browser reports that it's in standards
On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote:
> FAR better would be to use HTML 4.01 Strict instead of XHTML unless you
> (because of MathML or some other such) know WHY you need it.
Ok, is there a decent POD -> HTML 4.01 Strict module out there?
--
Michael G Schwern [EMA
Offer Kaye wrote:
On 7/12/05, Michael G Schwern wrote:
Patch Pod::Html? Sorry, I have to.. umm.. I have to rearrange my sock
drawer. On Pluto.
As an alternative to taking long interplanetary trips, consider using
Pod::Xhtml instead of Pod::Html. It's better. Really.
Cheers,
There's onl
On Sat, Jul 16, 2005 at 11:43:48AM +0300, Offer Kaye wrote:
> As an alternative to taking long interplanetary trips, consider using
> Pod::Xhtml instead of Pod::Html. It's better. Really.
Maybe we should consider emborging this or another POD -> HTML converter to
finally end Pod::Html's Reign of T
On 7/12/05, Michael G Schwern wrote:
>
> Patch Pod::Html? Sorry, I have to.. umm.. I have to rearrange my sock
> drawer. On Pluto.
>
As an alternative to taking long interplanetary trips, consider using
Pod::Xhtml instead of Pod::Html. It's better. Really.
Cheers,
--
Offer Kaye
Michael G Schwern wrote:
On Tue, Jul 12, 2005 at 08:55:33AM +0100, Steve Hay wrote:
Didn't we conclude it would be better to give Pod::Html the same foo()
recognition magic that Pod::Man has and not have to put C<> around every
function?
Patches welcome!
Patch Pod::Html? Sorry, I have to
On Tue, Jul 12, 2005 at 08:55:33AM +0100, Steve Hay wrote:
> >Didn't we conclude it would be better to give Pod::Html the same foo()
> >recognition magic that Pod::Man has and not have to put C<> around every
> >function?
> >
> Patches welcome!
Patch Pod::Html? Sorry, I have to.. umm.. I have to
Michael G Schwern wrote:
>On Mon, Jul 11, 2005 at 04:45:39PM +0100, Steve Hay wrote:
>
>
>>OTOH, functions are perhaps better written as C because this
>>causes them to be linked when converted to HTML.
>>
>>
>
>Didn't we conclude it would be better to give Pod::Html the same foo()
>recogni
On Mon, Jul 11, 2005 at 09:15:51PM +0200, Piotr Fusik wrote:
> > -sequence of commands indicated by BLOCK. When modified by a loop
> > +sequence of commands indicated by BLOCK. When modified by the
> C loop
> >
> > Which isn't true. do handles both "while" and "until". I think the
> original
>
On Mon, Jul 11, 2005 at 09:29:27PM +0200, Piotr Fusik wrote:
> > Didn't we conclude it would be better to give Pod::Html the same foo()
> > recognition magic that Pod::Man has and not have to put C<> around
> every
> > function?
>
> ActivePerl HTMLs have links to functions even where there are no
>
> Didn't we conclude it would be better to give Pod::Html the same foo()
> recognition magic that Pod::Man has and not have to put C<> around
every
> function?
>
ActivePerl HTMLs have links to functions even where there are no
surrounding C<>.
There is a small drawback, however: "element(s)" appear
> -sequence of commands indicated by BLOCK. When modified by a loop
> +sequence of commands indicated by BLOCK. When modified by the
C loop
>
> Which isn't true. do handles both "while" and "until". I think the
original
> wording should hold. Possibly perlsyn clarifies what a "loop
modifier" i
On Mon, Jul 11, 2005 at 04:45:39PM +0100, Steve Hay wrote:
> OTOH, functions are perhaps better written as C because this
> causes them to be linked when converted to HTML.
Didn't we conclude it would be better to give Pod::Html the same foo()
recognition magic that Pod::Man has and not have to p
Piotr Fusik wrote:
>Here are some cosmetic changes of perlfunc:
>
>1. Documented no-operand versions of chdir, eval, exit, gmtime.
>2. Normalized C to foo().
>3. Normalized $foo to C<$foo>.
>4. Changed "=item import" to "=item import (LIST)".
>
A recent discussion on this list concluded that varia
On Sat, Jul 09, 2005 at 04:21:05PM +0200, Piotr Fusik wrote:
> Here are some cosmetic changes of perlfunc:
>
> 1. Documented no-operand versions of chdir, eval, exit, gmtime.
> 2. Normalized C to foo().
> 3. Normalized $foo to C<$foo>.
> 4. Changed "=item import" to "=item import (LIST)".
This is
Here are some cosmetic changes of perlfunc:
1. Documented no-operand versions of chdir, eval, exit, gmtime.
2. Normalized C to foo().
3. Normalized $foo to C<$foo>.
4. Changed "=item import" to "=item import (LIST)".
Bye,
Piotr
perlfunc.patch.gz
Description: GNU Zip compressed data
On Thu, Jun 09, 2005 at 10:25:50AM +0200, Rafael Garcia-Suarez wrote:
> > --- perl-5.9.3.24699/pod/perlfunc.pod- 2005-06-03 09:56:55 +
> > +++ perl-5.9.3.24699/pod/perlfunc.pod 2005-06-08 09:33:00 +
> > @@ -2315,9 +2315,9 @@ functions will serve you better than wil
> >
> > Imp
Alexey Tourbin wrote:
> Hello,
>
> Unlike "sys/ioctl.ph", "ioctl.ph" is uncommon. Modern Linux have only
> /usr/include/sys/ioctl.h, not /usr/include/ioctl.h. Besides this,
> "sys/ioctl.ph" is mentioned in perlfaq5.pod and perlfaq8.pod.
>
> --- perl-5.9.3.24699/pod/perlfunc.pod-2005-06-
Hello,
Unlike "sys/ioctl.ph", "ioctl.ph" is uncommon. Modern Linux have only
/usr/include/sys/ioctl.h, not /usr/include/ioctl.h. Besides this,
"sys/ioctl.ph" is mentioned in perlfaq5.pod and perlfaq8.pod.
--- perl-5.9.3.24699/pod/perlfunc.pod- 2005-06-03 09:56:55 +
+++ perl-5.9.3.24699/pod
Hernan Perez Masci wrote:
>
> I'm attaching a patch to add the other missing comment to the same pod file
> (the one already patched by Rafael).
Thanks, applied to bleadperl as change #24224.
On Fri, 8 Apr 2005 13:50:00 -0500, Steve Peters wrote (in part):
sp> Does the Linux specific warning belong in perlfunc.pod or should it be
sp> in perlport.pod instead?
It's not specific to Linux. Multiple Unix variants are subject to the
same warning.
--
Spider Boardman (at home)
On Fri, Apr 08, 2005 at 03:28:28PM -0300, Hernan Perez Masci wrote:
> Hello,
>
> I have detected two missing comments about the behaviour of select(2) system
> call, in the description of the select function in perlfunc.pod. Rafael
> Garcia-Suarez has already added one of these comments to the p
Hello,
I have detected two missing comments about the behaviour of select(2) system
call, in the description of the select function in perlfunc.pod. Rafael
Garcia-Suarez has already added one of these comments to the pod file in
bleadperl (see perl-documentation mailling list archive for furthe
On Fri, May 11, 2001 at 11:36:04AM -0400, Benjamin Sugars wrote:
>
> If LIMIT is specified and positive, it represents the maximum number
> -of fields the EXPR will be split into, though the number of fields
> -returned depends on the number of occurrences of PATTERN within EXPR.
> -If LIMIT i
78 matches
Mail list logo
