pp_negate

[Piotr Fusik]

I see three problems with this function:

1. [#36674] -undef results in -0.0 rather than the expected 0.
This is probably easy to fix, but I don't know if undef is the only value for 
which (!SvIOKp(sv) && !SvNOKp(sv) && !SvPOKp(sv)).

2. [#36675] Strings starting with '-' or '+' are treaded as strings, even when 
they represent numbers. Now I doubt this should be changed, but at least it 
should be clearly documented in perlop and probably perltrap. (imagine someone 
extracts numbers with a regular expression or split, and expects "-100" to be 
treated the same way as "100")

3. There is some special treating of UTF-8 strings: they can be prefixed with 
'-' even when they don't start with an "identifier first" character.
I was unable to provoke this behavior in practice, who knows how to do that?

Re: [perl #36674] -undef() eq '-0'

[Yitzchak Scott-Thoennes]

On Wed, Jul 27, 2005 at 04:53:12PM -0700, Michael G Schwern wrote:
> On Wed, Jul 27, 2005 at 03:43:19PM -0700, Piotr Fusik wrote:
> > The result of the unary minus operator, when applied to
> > an undefined value (e.g. undefined variable) is unexpected:
> > 
> > perl -le 'print for -0,-"",-0.0,-undef'
> > 0
> > 0
> > -0
> > -0
> > 
> > In my opinion, -undef should be identical to -"", i.e. 0, not -0.0.
> 
> I'd say -0 but same end result.  -0 and -undef should probably produce the
> same thing.
> 
> $ perl -MDevel::Peek -wle 'print Dump -undef' 
> Use of uninitialized value in negation (-) at -e line 1.
> SV = NV(0x80de00) at 0x801270
>   REFCNT = 1
>   FLAGS = (PADTMP,NOK,pNOK)
>   NV = -0
> 
> $ perl -MDevel::Peek -wle 'print Dump -0'SV = IV(0x80b520) at 0x801270
>   REFCNT = 1
>   FLAGS = (PADBUSY,PADTMP,IOK,READONLY,pIOK)
>   IV = 0
> 
> Not that it really makes much difference but its curious why undef is being
> numerified as an NV.

$ perl -MDevel::Peek -Minteger -wle 'print Dump -undef'
Use of uninitialized value in integer negation (-) at -e line 1.
SV = IV(0x488258) at 0x461284
  REFCNT = 1
  FLAGS = (PADTMP,IOK,pIOK)
  IV = 0

Presumably because (barring IVUV preservation stuff, which I wouldn't
expect to apply to undef) perl's arithmetic operations are NV based.

Smoke [5.9.3] 25241 FAIL(F) linux 2.6.12-4-686 [debian] (i686/1 cpu)

[steve]

Automated smoke report for 5.9.3 patch 25241
kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu)
onlinux - 2.6.12-4-686 [debian]
using cc version 4.0.2 20050720 (prerelease) (Debian 4.0.1-2ubuntu3)
smoketime 2 hours 45 minutes (average 20 minutes 41 seconds)

Summary: FAIL(F)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25241 Configuration (common) none
--- -
O O 
O O -Duseithreads
F F -DPERL_DEBUG_COW
F F -DPERL_DEBUG_COW -Duseithreads
| +- -DDEBUGGING
+--- no debugging


Failures:
[default] -DPERL_DEBUG_COW
[default] -DDEBUGGING -DPERL_DEBUG_COW
[default] -DPERL_DEBUG_COW -Duseithreads
[default] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads
../t/op/sprintf.t...FAILED 147

-- 
Report by Test::Smoke v1.19#716 running on perl 5.8.7
(Reporter v0.016 / Smoker v0.015)

Re: Y2K docs in the 21st century (was Re: [PATCH] perlfunc.pod grammar fixes)

[Michael G Schwern]

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://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

RE: Y2K docs in the 21st century (was Re: [PATCH] perlfunc.pod grammar fixes)

[Horsley, Tom]

> 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 Windows doesn't use a 4 byte unsigned for its primary
timestamp, and therefore only Linux will have the 2039 bug.
 

Re: [ANNOUNCE] Test::Simple/More/Builder 0.60_01

[Michael G Schwern]

On Thu, Jul 28, 2005 at 05:48:58PM -0500, Peter wrote:
> So, the way I would go about using this would be something like this?
> 
> my $obj=new SomeObj();
> isa($obj, "SomeObj") or BAIL_OUT("It wasn't my object :(");

isa_ok() but you get the idea.  You call it when you think the code is so
busted that its not worth continuing any testing, that means halting the
current test and not running any further test files.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Ahh email, my old friend.  Do you know that revenge is a dish that is best 
served cold?  And it is very cold on the Internet!

Y2K docs in the 21st century (was Re: [PATCH] perlfunc.pod grammar fixes)

[Michael G Schwern]

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 folks understand that Y2K is not just about the year 2000 but about
using truncated years in general and its not necessary to coin a new term.  
Same problem, different century.  Also...


> Note that the $year element is l simply one hundered plus the
> last two digits of the year.  By assuming that it is you will create
> non-Y2100-compliant code and guarantee your grandchildren careers
> in computer maintenance.

I can understand people in 1998 assuming 98 is the last two digits of the 
year and never bothering to look at the docs, but someone mistaking 105 as 
being one hundred plus the last two digits of the year... that seems a bit
contrived.

Possibly the best solution I've seen to this problem was the one employed
in Clinton Pierce's surprisingly well written "Learn Perl In 24 Hours".
Its not a year, stop calling it that.  Its years offset from 1900.  His book
always refers to it as $year_offset or $year_off but never $year.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: [PATCH] perlfunc.pod grammar fixes

[David Nicol]

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 question, but differentiate between
effect, affect, and effect.

Too worn out to get any cuter than that with that, although no doubt some
rube will.

-- 
David L Nicol
"This has been your one free extra mile"

Re: Perl 64bit

[Michael G Schwern]

On Thu, Jul 28, 2005 at 05:06:52PM +0200, Jorge Schrauwen wrote:
> 32bit compiler just fails with perl.
> 64bit compiler works but gives and error about DynaLoader.pm not being found 
> and then quits.

It would be very helpful to see the actual error messages.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>

Re: [PATCH] perlfunc.pod grammar fixes

[John P. Linderman]

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?  After

Date: Tue, 18 Jan 2005 11:43:30 -0500
According to John P. Linderman:
> Barring some sort of formal definitions, the C code determines the
> language (pretty much what happened to trigger this whole thread)
> rather than the language determining the parser, and that just seems
> wrong.  -- jpl

WRT Perl 5, I'm afraid that horse is not only out of the barn, but has
wandered off the ranch, joined a wild herd, and sired several foals.
--
Chip Salzenberg  - a.k.a. -   <[EMAIL PROTECTED]>

is there any significant difference between "perl" and "Perl"?
Above all, is this the most important issue facing [pP]erl?
If so, it's time declare victory and save some other language -- jpl

Smoke [5.9.0] 21539 FAIL(c) openbsd 3.6 (i386/1 cpu)

[Steven Philip Schubiger]

Automated smoke report for 5.9.0 patch 21539
accognoscere.homeunix.org: AMD Athlon(TM) XP 1800+ ("AuthenticAMD" 686-class) 
(i386/1 cpu)
onopenbsd - 3.6
using cc version 2.95.3 20010125 (prerelease, propolice)
smoketime 2 hours 51 minutes (average 9 minutes 32 seconds)

Summary: FAIL(c)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   21539 Configuration (common) none
--- -
O - O - -Uuseperlio
O O O O 
O O O O -Duse64bitint
c - c - -Duselongdouble
c - c - -Dusemorebits
O O O O -Duseithreads
O O O O -Duseithreads -Duse64bitint
c - c - -Duseithreads -Duselongdouble
c - c - -Duseithreads -Dusemorebits
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio  -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio


-- 
Report by Test::Smoke v1.19#716 running on perl 5.8.5
(Reporter v0.016 / Smoker v0.015)

Perl 64bit

[Jorge Schrauwen]

Hi all,

I've been trying to compile perl 64bit (or 32bit)
on windows xp pro x64.

I am using VS.Net 2005 beta.

32bit compiler just fails with perl.
64bit compiler works but gives and error about DynaLoader.pm not being found 
and then quits.

help much apriciated

Jorge

Re: [perl #36667] Lengthy parameter passed to eval leads to bus error on FreeBSD 5.4

[Dominic Dunlop]

On 2005–07–28, at 08:51, Dominic Dunlop wrote:

On 2005–07–27, at 20:31, John Narron wrote:

perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] .  
"\n" . q[

stuff($h, @_);] . "\n}\n\n"; $x x= 7238; $x =~ s/stuff/"stuff" .
++$count/eg; eval $x'



Problem confirmed with the above script on Mac OS X. The tipping  
point for a debugging [EMAIL PROTECTED] with a stack limit of 8192k  
is $x x= 26197. For a 64-bit perl it's somewhat more than half  
that; for a production perl 5.8.6, it's much higher -- somewhere  
between 70 and 80,000.


Another data point: the problem's not specific to eval -- with this  
variant of the program, which pipes the generated script to a child  
perl, the child perl blows its stack at almost exactly the same point  
(21969 vs 21968) as in the original.


./perl -e 'my $x = q[if ($h->{ALPHA}->{BETA}->{q{stuff}}) {] . "\n" . q[
stuff($h, @_);] . "\n}\n\n"; $x x= 26199; $x =~ s/stuff/"stuff" .
++$count/eg;$x .= q(print "done\n";); open P, "|./perl -w" or die  
"Pipe open failed: !$\n"; print P $x; close P'


--
Dominic Dunlop

Re: [PATCH] perlfunc.pod grammar fixes

[David Nicol]

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.  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 you?

Note that the $year element is l simply one hundered plus the
last two digits of the year.  By assuming that it is you will create
non-Y2100-compliant code and guarantee your grandchildren careers
in computer maintenance.




-- 
David L Nicol
"This has been your one free extra mile"

Re: bareword test on ebcdic.

[Yitzchak Scott-Thoennes]

On Thu, Jul 28, 2005 at 12:35:13AM -0700, rajarshi das wrote:
> Nicholas Clark wrote:
>> If you put those 3 bytes directly between the '{' and '}' characters in
>> the EBCDIC version of that 1 liner, does it also print 3500?

> I am unable to put those three bytes in the 1-liner you mentioned above, 
> since I am unable to print the chars corresponding to those bytes 
> (www.kostis.net/charsets/ebc1047.htm) on the command line. 

>> I think that the regression tests tended to do something like
>> 
>> if (ord 'A' == 65) {
>> # Do the ASCII/UTF-8 version
>> } else {
>> # Assume EBCDIC
>> }

I tried to fix the attribution above; apologies if I got it wrong.

I think the way you want to test this is something like:

  $key = "\x{0442}\x{0435}\x{0441}\x{0442}";
  if ( $hash{$key} eq eval "\$hash{$key}" )

It's unclear to me whether $key needs to be different for EBCDIC.

Are you just using perl on z/OS, or are you building it yourself?
If the latter, Dave Mitchell has been looking for someone to test
some parser changes he made on an EBCDIC platform so they can be
integrated into the 5.8.x series.

[PATCH] Fix English error in overload.pm

[Andy Lester]

In Simon's "Advanced Perl Programming, 2e" there's a quote from
overload.pm that warrants a [sic].  This fixed that.

xoxo,
Andy

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
diff -pur bleadperl/lib/overload.pm bw/trunk/lib/overload.pm
--- bleadperl/lib/overload.pm   2004-11-04 03:50:57.0 -0600
+++ bw/trunk/lib/overload.pm2005-07-28 11:26:51.0 -0500
@@ -170,7 +170,7 @@ __END__
 
 =head1 NAME
 
-overload - Package for overloading perl operations
+overload - Package for overloading Perl operations
 
 =head1 SYNOPSIS
 
@@ -717,12 +717,12 @@ Returns C or a reference to the m
 
 =head1 Overloading constants
 
-For some application Perl parser mangles constants too much.  It is possible
-to hook into this process via overload::constant() and 
overload::remove_constant()
-functions.
+For some applications, the Perl parser mangles constants too much.
+It is possible to hook into this process via C
+and C functions.
 
 These functions take a hash as an argument.  The recognized keys of this hash
-are
+are:
 
 =over 8
 

[PATCH] More embed.fnc goodness

[Andy Lester]

* embed.fnc: Adding many NN and NULLOK flags.  I'm down to 280 or so
pointer parameters to clean up.  In at least one case, I fixed one that
was wrong (force_list).

* doio.c: Consting

* op.c: Fixed some indents.  Hoisted a check for non-null outside of an
if-then chain, to improve readability.  Added a couple of consts.

* pp_ctl.c: Consting.

* regcomp.c: Consting.

* regexec.c: Consting.

* sv.c: Fixed indenting.

* util.c: Consting.

xoxo,
Andy

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
diff -pur bleadperl/doio.c bw/trunk/doio.c
--- bleadperl/doio.c2005-07-24 18:04:46.0 -0500
+++ bw/trunk/doio.c 2005-07-28 11:26:53.0 -0500
@@ -747,7 +747,7 @@ Perl_nextargv(pTHX_ register GV *gv)
 #endif
 Uid_t fileuid;
 Gid_t filegid;
-IO *io = GvIOp(gv);
+IO * const io = GvIOp(gv);
 
 if (!PL_argvoutgv)
PL_argvoutgv = gv_fetchpv("ARGVOUT",TRUE,SVt_PVIO);
@@ -802,9 +802,9 @@ Perl_nextargv(pTHX_ register GV *gv)
continue;
}
if (*PL_inplace) {
-   char *star = strchr(PL_inplace, '*');
+   const char *star = strchr(PL_inplace, '*');
if (star) {
-   char *begin = PL_inplace;
+   const char *begin = PL_inplace;
sv_setpvn(sv, "", 0);
do {
sv_catpvn(sv, begin, star - begin);
@@ -2333,7 +2333,7 @@ PerlIO *
 Perl_start_glob (pTHX_ SV *tmpglob, IO *io)
 {
 dVAR;
-SV *tmpcmd = NEWSV(55, 0);
+SV * const tmpcmd = NEWSV(55, 0);
 PerlIO *fp;
 ENTER;
 SAVEFREESV(tmpcmd);
diff -pur bleadperl/embed.fnc bw/trunk/embed.fnc
--- bleadperl/embed.fnc 2005-07-28 08:33:40.0 -0500
+++ bw/trunk/embed.fnc  2005-07-28 14:00:16.0 -0500
@@ -239,7 +239,7 @@ ApdR|char*  |fbm_instr  |NN unsigned char
|NN SV* littlesv|U32 flags
 p  |char*  |find_script|const char *scriptname|bool dosearch \
|const char **search_ext|I32 flags
-p  |OP*|force_list |NN OP* arg
+p  |OP*|force_list |NULLOK OP* arg
 p  |OP*|fold_constants |NN OP* arg
 Afpd   |char*  |form   |NN const char* pat|...
 Ap |char*  |vform  |NN const char* pat|NULLOK va_list* args
@@ -297,7 +297,7 @@ Apd |SV**   |hv_store   |HV* tb|const char* 
 Apd|HE*|hv_store_ent   |HV* tb|SV* key|SV* val|U32 hash
 ApM|SV**   |hv_store_flags |HV* tb|const char* key|I32 klen|SV* val \
|U32 hash|int flags
-Apd|void   |hv_undef   |HV* tb
+Apd|void   |hv_undef   |NULLOK HV* tb
 ApP|I32|ibcmp  |NN const char* a|NN const char* b|I32 len
 ApP|I32|ibcmp_locale   |NN const char* a|NN const char* b|I32 len
 Apd|I32|ibcmp_utf8 |NN const char* a|char **pe1|UV l1|bool u1|NN 
const char* b|char **pe2|UV l2|bool u2
@@ -309,7 +309,7 @@ Ap  |void   |init_tm|struct tm *ptm
 pd |U32|intro_my
 ApPR   |char*  |instr  |NN const char* big|NN const char* little
 pR |bool   |io_close   |NN IO* io|bool not_implicit
-pR |OP*|invert |OP* cmd
+pR |OP*|invert |NULLOK OP* cmd
 dpR|bool   |is_gv_magical  |NN const char *name|STRLEN len|U32 flags
 ApR|I32|is_lvalue_sub
 ApPR   |U32|to_uni_upper_lc|U32 c
@@ -502,7 +502,7 @@ Apa |OP*|newCONDOP  |I32 flags|NN OP* fi
 Apd|CV*|newCONSTSUB|NULLOK HV* stash|NULLOK const char* 
name|NULLOK SV* sv
 Ap |void   |newFORM|I32 floor|NULLOK OP* o|NULLOK OP* block
 Apa|OP*|newFOROP   |I32 flags|char* label|line_t forline \
-   |OP* sclr|OP* expr|OP*block|OP*cont
+   |NULLOK OP* sv|OP* expr|OP*block|OP*cont
 Apa|OP*|newLOGOP   |I32 optype|I32 flags|OP* left|OP* right
 Apa|OP*|newLOOPEX  |I32 type|OP* label
 Apa|OP*|newLOOPOP  |I32 flags|I32 debuggable|OP* expr|OP* block
@@ -510,15 +510,15 @@ Apa   |OP*|newNULLLIST
 Apa|OP*|newOP  |I32 optype|I32 flags
 Ap |void   |newPROG|NN OP* o
 Apa|OP*|newRANGE   |I32 flags|OP* left|OP* right
-Apa|OP*|newSLICEOP |I32 flags|OP* subscript|OP* listop
-Apa|OP*|newSTATEOP |I32 flags|char* label|OP* o
+Apa|OP*|newSLICEOP |I32 flags|NULLOK OP* subscript|NULLOK OP* 
listop
+Apa|OP*|newSTATEOP |I32 flags|NULLOK char* label|NULLOK OP* o
 Ap |CV*|newSUB |I32 floor|OP* o|OP* proto|OP* block
 Apd|CV*|newXS  |NN const char* name|NN XSUBADDR_t f|NN const 
char* filename
 Apda   |AV*|newAV
 Apa|OP*|newAVREF   |NN OP* o
 Apa|OP*|newBINOP   |I32 type|I32 flags|OP* first|OP* last
-Apa|OP*|newCVREF   |I32 flags|OP* o
-Apa|OP*|newGVOP|

Smoke [5.9.3] 25237 FAIL(F) linux 2.6.12-4-686 [debian] (i686/1 cpu)

[steve]

Automated smoke report for 5.9.3 patch 25237
kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu)
onlinux - 2.6.12-4-686 [debian]
using cc version 4.0.2 20050720 (prerelease) (Debian 4.0.1-2ubuntu3)
smoketime 2 hours 39 minutes (average 19 minutes 57 seconds)

Summary: FAIL(F)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25237 Configuration (common) none
--- -
O O 
O O -Duseithreads
F F -DPERL_DEBUG_COW
F F -DPERL_DEBUG_COW -Duseithreads
| +- -DDEBUGGING
+--- no debugging


Failures:
[default] -DPERL_DEBUG_COW
[default] -DDEBUGGING -DPERL_DEBUG_COW
[default] -DPERL_DEBUG_COW -Duseithreads
[default] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads
../t/op/sprintf.t...FAILED 147

-- 
Report by Test::Smoke v1.19#716 running on perl 5.8.7
(Reporter v0.016 / Smoker v0.015)

Re: [PATCH] perlfunc.pod

[Rafael Garcia-Suarez]

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.

Re: [PATCH] Re: [PATCH] support POSIX SA_SIGINFO

[Rafael Garcia-Suarez]

Green, Paul wrote:
> My weekly build of bleedperl failed last night:
> 
> mg.c: In function `Perl_sighandler':
> mg.c:2715: structure has no member named `si_errno'
> 
> I tracked it down to the sa_siginfo changes.
> 
> Stratus VOS implements the 1996 revision of the POSIX standard.  That
> version defines the minimum siginfo_t type to have the members si_code,
> si_signo, and si_value.  The 2001 revision of the POSIX standard adds
> the si_errno, si_pid, si_uid, si_addr, si_status, and si_band members.
> 
> As far as I can tell, the si_errno value is never used in perl.  So I
> hope that I'm not offending anyone by submitting the attached patch that
> moves it under the #if 0 clause as well.

Thanks, applied to bleadperl as change #25240.

Re: [PATCH fresh_perl.t] Being more careful about newlines

[Rafael Garcia-Suarez]

Michael G Schwern wrote:
> Removing the auto-newline appending in fresh_perl_is() exposed some newline
> sloppiness in t/run/fresh_perl.t.
> 
> * When switches were stripped from test code a blank line was left.
>   This confused attempts by fresh_perl to display the first line of the
>   program as a default name.
> 
> * Some programs have no expected output, we only care that they don't
>   segfault.  These would warn as the expected output was undef.
> 
> * Tests with no switches generated undef warnings.
> 
> * Separating the test into the program and the expected part stripped
>   the trailing newline off the program causing a test to fail which
>   ended in a here-doc separator.

Thanks, applied as #25239.

Re: [PATCH] perlfunc.pod grammar fixes

[Michael G Schwern]

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 savings. Thus the sentence These measures may affect 
> savings could imply that the measures may reduce savings that have 
> already been realized, whereas These measures may effect savings implies 
> that the measures will cause new savings to come about.

Forget it.  I'm learning an easier language, like Finnish.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml

Re: [PATCH] perl.h, use STRINGIFY in 25171

[Rafael Garcia-Suarez]

Robin Barker wrote:
> This patch changes my previous patch 25171 
> to use STRINGIFY instead of #n.
> 
> config.h defines CAT2 and STRINGIFY:
> STRINGIFY(n) is used (instead of #n), 
> but CAT2 is rarely used (instead of ##).
> 
> Does this matter?  I guess not.

Thanks, applied as change #25238.

Re: [PATCH] perlfunc.pod grammar fixes

[Andy Lester]

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 Expressions":

Effect: As a noun, means "results"; as a verb, means "to bring about,"
"to accomplish," (not to be confused with I, which means
"to influence").

As a noun, often loosely used in perfunctory writing about fashions,
music, painting, and other arts: "a Southwestern effect"; "effects in
pale green"; "very delicate effects"; "subtle effects"; "a charming
effect was produced."  The writer who has a definite meaning to
express will not take refuge in such vagueness.

See also pages such as
http://owl.english.purdue.edu/handouts/grammar/g_spelprob.html
http://www.wsu.edu/~brians/errors/affect.html

It is perfectly fine, although less common, to say "to effect a sleep of
250 milliseconds."

I also agree that it would be preferable to s/effect/cause/ in the
example above.

xoxo,
Andy

-- 
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Dominic Dunlop]

On 2005–07–28, at 14:52, H.Merijn Brand wrote:


Please rsync, test and pray


Works for me. And I wasn't even praying.
--
Dominic Dunlop

affect/effect (was perlfunc.pod grammar fixes)

[Joe McMahon]

On Jul 28, 2005, at 12:49 AM, Piotr Fusik 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.


effect is a noun.  affect is a verb so I think this change is correct.


-You can effect a sleep of 250 milliseconds this way:
+You can affect a sleep of 250 milliseconds this way:


This is correct.


Hmm...

Both wrong, as Piotr says.  "Effect" means "to cause to exist" in both 
these usages; affect would mean "to change the state of something 
already existing". So in the first case we want an early exit to happen 
that has not yet happened: effect. In the second case we want to make a 
250 ms wait happen: effect. If we wanted to change an existing 250 ms 
wait, then we would be affecting it.


 --- Joe M.

Re: gmake (perl-5.8.6) fails on z/OS

[rajarshi das]

--- Nicholas Clark <[EMAIL PROTECTED]> wrote:

> On Thu, Jul 28, 2005 at 02:37:36AM -0700, rajarshi
> das wrote:
> 
> > However, if I change the first instance to :
> > --- utf8.c  2004-11-17 18:22:09.0
> +0530
> > +++ utf8.c.22005-07-28 13:48:24.0
> +0530
> > @@ -363,6 +363,11 @@ Perl_utf8n_to_uvuni(pTHX_ U8
> *s,
> > STRLEN
> > warning = UTF8_WARN_EMPTY;
> > goto malformed;
> >  }
> > +#ifdef EBCDIC
> > +if (uv == 0xBA) {
> > +   uv = NATIVE_TO_UTF(uv);
> > +}
> > +#endif
> > 
> >  if (UTF8_IS_INVARIANT(uv)) {
> > if (retlen)
> > 
> > This allows gmake to complete. 
> > Thanks for all your help on this.
> 
> Do you have any idea *why* this change makes things
> work?
I havent been able to figure out why.

Meanwhile I have run into something different. Again,
a gmake failure due to the following change (I ran
gmake with the following change as well as the one
mentioned above) : 

--- utf8.c  2004-11-17 18:22:09.0 +0530
+++ utf8.c.32005-07-28 19:42:50.0 +0530
@@ -80,10 +80,15 @@ Perl_uvuni_to_utf8_flags(pTHX_ U8
*d, UV
  Perl_warner(aTHX_ packWARN(WARN_UTF8),
 "Unicode character
0x%04"UVxf" is illegal", uv);
 }
+# ifdef EBCDIC
+if ((uv > 0x9E && uv < 0xFE) &&
(UTF8_IS_INVARIANT(uv))) {
+# else
 if (UNI_IS_INVARIANT(uv)) {
+# endif
*d++ = (U8)UTF_TO_NATIVE(uv);
return d;
 }
+
 #if defined(EBCDIC)
 else {
STRLEN len  = UNISKIP(uv);


Here's a snapshot of the gmake output :
--
gmake[1]: Entering directory
`/usr1/perl-5.8.6/ext/Encode'
Makefile out-of-date with respect to
../../lib/Config.pm
Cleaning current config before rebuilding Makefile...
gmake -f Makefile.old clean > /dev/null 2>&1 ||
/bin/sh -c true
../../miniperl "-I../../lib" "-I../../lib" Makefile.PL
"INSTALLDIRS=perl" "PERL_CO
RE=1" "LIBPERL_A=libperl.a"
Checking if your kit is complete...
Looks good
ERROR from evaluation of
/usr1/perl-5.8.6/ext/Encode/Byte/Makefile.PL: Perl v
32.32.32 required--this is only v5.8.6, stopped at
./Makefile.PL line 1.
BEGIN failed--compilation aborted at ./Makefile.PL
line 1.
gmake[1]: *** [Makefile] Error 113
gmake[1]: Leaving directory
`/usr1/perl-5.8.6/ext/Encode'
gmake config failed, continuing anyway...
gmake[1]: Entering directory
`/usr1/perl-5.8.6/ext/Encode'
gmake[1]: *** No rule to make target `all'.  Stop.
gmake[1]: Leaving directory
`/usr1/perl-5.8.6/ext/Encode'
gmake: *** [lib/auto/Encode/Encode.a] Error 2


Thanks,
Rajarshi.

> 
> Nicholas Clark
> 





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [PATCH] perlfunc.pod grammar fixes

[Ronald J Kimball]

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 the accent on the second syllable when it's a verb, but the
first syllable when it's a noun.

(Also, one definition of the verb affect is "to effect a change". :)

Ronald

Re: [PATCH] perlfunc.pod grammar fixes

[Brad Baxter]

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 tchrist write it?)
> >
> >However it seems that
> >
> >1: If you aren't native speaker, or don't notice these sort of differences,
> >   you won't see anything wrong
> >2: If you notice these differences but don't know the real nitty gritty
> >   subtleties, you think that there is something wrong.
> >   (I certainly did at first)
> >3: Only if you already know the subtly do you think it's fine.
> >   (but you might need to double take)
> >
> >Hence my suggestion to avoid the problem by not using the verb "effect",
> >even when it's correct.
> >
> Fair enough, I guess, but what about all the other places where these
> words are used?
>
> C:\p5p\bleadperl\pod>grep -i effect *.pod | wc -l
> 310
>
> Why bother changing it in 2 places when there are at least 308 other
> places in pod/ alone?

IMHO, to effect a change that affects something isn't erudite at all
(though I think erudite is).  Please, let's leave perfectly good
English alone.

Regards,

Brad

Re: [PATCH] tidy up DieNull and DIE_NULL

[H.Merijn Brand]

On Thu, 28 Jul 2005 14:05:51 +0100, Robin Barker <[EMAIL PROTECTED]>
wrote:

> This patch allows Perl_die to have a NULL argument - corresponding to
> throwing an exception.
> 
> This allows various bits of code (previously complicated by format
> checkery) to be simplified.
> 
> The macros DieNull and DIE_NULL have been removed: they don't appear to
> used in CPAN modules.

Very sensible. Thanks. Applied as change #25237

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] silence compiler warning in mg.c POSIX.xs

[Rafael Garcia-Suarez]

Robin Barker wrote:
> This fixes some compiler warnings in mg.c and POSIX.xs,
> and clarifies some related macro definitions in perl.h

Thanks, applied as #25236.

[PATCH] tidy up DieNull and DIE_NULL

[Robin Barker]

This patch allows Perl_die to have a NULL argument - corresponding to throwing 
an exception.

This allows various bits of code (previously complicated by format checkery) to 
be simplified.

The macros DieNull and DIE_NULL have been removed: they don't appear to used in 
CPAN modules.

Robin

 



---
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
   Hook, Hampshire, United Kingdom  RG27 9UY
---

die_null.patch
Description: Binary data

[PATCH] silence compiler warning in mg.c POSIX.xs

[Robin Barker]

This fixes some compiler warnings in mg.c and POSIX.xs,
and clarifies some related macro definitions in perl.h

Robin 



---
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
   Hook, Hampshire, United Kingdom  RG27 9UY
---

pointer.patch
Description: Binary data

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[H.Merijn Brand]

On Thu, 28 Jul 2005 12:52:01 +0200, Rafael Garcia-Suarez
<[EMAIL PROTECTED]> wrote:

> H.Merijn Brand wrote:
> > > say, it sounds like a Skip for HP-UX 10.20. However, sprintf.t
> > > currently says:
> > >
> > > # we do not load %Config since this test resides in op and needs
> > > # to run under the minitest target even without Config.pm working.
> > 
> > Raphael ruled that removing the comment and using Config is OK.
> 
> Many tests under t/op use Config inconditionnally. This is not an
> ideal situation, using eval { require Config; import Config } like some
> other do is better (and fallback to .* for $Config{osvers} in this test
> maybe ?) (and miniperl isn't broken that often those days)

* I've changed the define-or to ?: in the final patch to easy
  integration to maint
* I've added a piece of comment just before the list
* I've added the special 'all' tag
* I've defaulted $Config{osvers} to "0'
* I've deleted some trailing whitespace
* I've added a optional semicolon
* I've committed the thing in change #25235

Please rsync, test and pray

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Dominic Dunlop]

On 2005–07–28, at 12:44, H.Merijn Brand wrote:

Ho hum. sprintf.t doesn't do Skip and TODO (mea culpa), so I'd have
to hack handling of them into the script, or rewrite the whole thing



I beat you to that :)


No objection whatever. Thanks!



say, it sounds like a Skip for HP-UX 10.20. However, sprintf.t
currently says:

# we do not load %Config since this test resides in op and needs
# to run under the minitest target even without Config.pm working.



Raphael ruled that removing the comment and using Config is OK.

I put this in back in 2000 because I knew from experience of keeping  
perl running on a balky platform that there's a bootstrap problem if  
you can't build a miniperl that's good enough to create Config.pm and  
its lack prevents you from running tests.


On 2005–07–28, at 12:52, Rafael Garcia-Suarez wrote:

Many tests under t/op use Config inconditionnally.


20 of them -- or 21 now. I think I'll file my cause under "Lost".
--
Dominic Dunlop

Smoke [5.9.3] 25231 FAIL(F) bsd/os 4.1 (i386/1 cpu)

[kane]

Automated smoke report for 5.9.3 patch 25231
fixit.xs4all.nl: Pentium II (i386/1 cpu)
onbsd/os - 4.1
using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
smoketime 3 hours 55 minutes (average 1 hour 57 minutes)

Summary: FAIL(F)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25231 Configuration (common) none
--- -
F F - - -Duse64bitint
O F - - 
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio  -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio


Failures: (common-args) none
[stdio] -Duse64bitint
../t/op/int.t...FAILED 11
Inconsistent test results (between TEST and harness):
../lib/Net/hostent.tFAILED at test 4

[perlio] -Duse64bitint
../t/op/int.t...FAILED 11

[perlio] 
../lib/Net/hostent.tFAILED 4-7

-- 
Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503
(Reporter v0.019 / Smoker v0.023)

[PATCH] perl.h, use STRINGIFY in 25171

[Robin Barker]

This patch changes my previous patch 25171 
to use STRINGIFY instead of #n.

config.h defines CAT2 and STRINGIFY:
STRINGIFY(n) is used (instead of #n), 
but CAT2 is rarely used (instead of ##).

Does this matter?  I guess not.

Robin

-Original Message-
From: Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]
Sent: 18 July 2005 14:04
To: Robin Barker
Cc: ''The Perl5 Porters Mailing List ''; John Peacock
Subject: Re: [PATCH] RE: blead: no longer supports %vd format

Thanks, applied as change #25171 to bleadperl.



---
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
   Hook, Hampshire, United Kingdom  RG27 9UY
---

stringify.patch
Description: Binary data

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Hay]

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
>
>1: If you aren't native speaker, or don't notice these sort of differences,
>   you won't see anything wrong
>2: If you notice these differences but don't know the real nitty gritty
>   subtleties, you think that there is something wrong.
>   (I certainly did at first)
>3: Only if you already know the subtly do you think it's fine.
>   (but you might need to double take)
>
>Hence my suggestion to avoid the problem by not using the verb "effect",
>even when it's correct.
>
Fair enough, I guess, but what about all the other places where these 
words are used?

C:\p5p\bleadperl\pod>grep -i effect *.pod | wc -l
310

Why bother changing it in 2 places when there are at least 308 other 
places in pod/ alone?




Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender 
immediately.  The unauthorized use, disclosure, copying or alteration of this 
message is strictly forbidden.  Note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will accept no 
liability for any damage caused by any virus transmitted by this email.

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Rafael Garcia-Suarez]

H.Merijn Brand wrote:
> > say, it sounds like a Skip for HP-UX 10.20. However, sprintf.t
> > currently says:
> >
> > # we do not load %Config since this test resides in op and needs
> > # to run under the minitest target even without Config.pm working.
> 
> Raphael ruled that removing the comment and using Config is OK.

Many tests under t/op use Config inconditionnally. This is not an
ideal situation, using eval { require Config; import Config } like some
other do is better (and fallback to .* for $Config{osvers} in this test
maybe ?) (and miniperl isn't broken that often those days)

-- 
A system is nothing more than the subordination of all aspects of the universe
to any one such aspect.
-- Borges

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Peters]

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]

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[H.Merijn Brand]

On Thu, 28 Jul 2005 12:31:24 +0200, Dominic Dunlop <[EMAIL PROTECTED]>
wrote:

> On 2005–07–28, at 11:07, H.Merijn Brand wrote:
> 
> >>> %.0f<  >-0.1<>-0<  >C library bug: no minus on VMS,  
> >>> HP-UX<
> >>>
> >
> > Which isn't true anymore anyway. I've just tried on SuSE 9.2,  
> > SuSE 9.3, AIX 4.3.3, AIX 5.2.0, HP-UX 11i, and HP-UX 11.00,
> > and all print "-0" on the example below.
> > Only HP-UX 10.20 still prints "0"
>
> OK. Can somebody say what the situation is on (particular versions
> of) VMS? -- copied to John E Malmberg in the hope of help.
>
> >> But anyway, as the C standard has a footnote saying "The results of
> >> all floating conversions of a negative zero, and of negative values
> >> that round to zero, include a minus sign", I've attached a patch for
> >> sprintf.t that adds a test. I fully expect it to fail on a number of
> >> platforms, in which case it can be hoisted into the "problematic"
> >> section. Smokers, let me know of failures please.
> >
> > And, knowing that it fails on those platforms, what do you want to
> > do with it? Skip or TODO?
> 
> Ho hum. sprintf.t doesn't do Skip and TODO (mea culpa), so I'd have
> to hack handling of them into the script, or rewrite the whole thing

I beat you to that :)

> to use test.pl or whatever. I'll look into doing one or the other,
> but in the meantime I'd like to see the patch applied so as to get an
> idea of where this test causes problems.

I'll apply my suggestion, which not only adds your tests, but revalidates the
problematic cases, if noone objects to the suggested patch

> As to the test's disposition, in the hope of action from the OS
> vendor, I'd like it to be a TODO where it fails, but from what you

Adding TODO support would be possible, but for now I only implemented skip

> say, it sounds like a Skip for HP-UX 10.20. However, sprintf.t
> currently says:
>
> # we do not load %Config since this test resides in op and needs
> # to run under the minitest target even without Config.pm working.

Raphael ruled that removing the comment and using Config is OK.

> I think that precludes me from looking at the OS version ($Config
> {osvers}), so it won't be possible to do fine-grained skipping
> according to OS type and version. Well, maybe I could attempt to use
> Config, and only do the fine-grained stuff if %Config gets defined...
> Again, I'll look into it.
>
> > I can assure you that no changes will be made for libc in
> > HP-UX 11.00 or below, so the 10.20 failure will stay there till the
> > end of times (unless we work around it in the perl source, which is
> > not worth the trouble if you want my opinion)
>
> Agreed that it's not worth the trouble.


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Hay]

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 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 you?
>>
>>
>>
>"and" removed.
>  
>
Yep, I did that.

>  
>
>> 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, while "affect" is a verb.  This is a common English
>grammar screw-up.
>  
>
Describing this as a screw-up seems to be a common a screw-up itself.  
"effect" is also a verb and is certainly the correct word here.  See the 
other posts if you didn't know...

>  
>
>>Sets the current position for the C routine on DIRHANDLE.  POS
>>-must be a value returned by C.  Has the same caveats about
>>-possible directory compaction as the corresponding system library
>>+must be a value returned by C.  C also Has the same caveats
>>+about possible directory compaction as the corresponding system library
>> routine.
>>
>>
>>
>"Has" changed to "has".
>  
>
Yep, did that too.

> 
>  
>
>>-You can effect a sleep of 250 milliseconds this way:
>>+You can affect a sleep of 250 milliseconds this way:
>>
>>
>>
>Again, effect vs. affect.  Here, this is a verb, so affect is the right
>word.
>  
>
No.

>  
>
>> the original quicksort was faster.  5.8 has a sort pragma for
>> limited control of the sort.  Its rather blunt control of the
>>-underlying algorithm may not persist into future perls, but the
>>+underlying algorithm may not persist into future Perls, but the
>> ability to characterize the input or output in implementation
>> independent ways quite probably will.  See L.
>>
>>
>
>Removed.
>
I agreed with Schwern that Perl was language and perl was the program, 
and that the above seemed to be referring to the language, so I kept 
your original change to "Perls".




Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender 
immediately.  The unauthorized use, disclosure, copying or alteration of this 
message is strictly forbidden.  Note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will accept no 
liability for any damage caused by any virus transmitted by this email.

Re: [PATCH] perlfunc.pod grammar fixes

[Nicholas Clark]

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 notice these sort of differences,
   you won't see anything wrong
2: If you notice these differences but don't know the real nitty gritty
   subtleties, you think that there is something wrong.
   (I certainly did at first)
3: Only if you already know the subtly do you think it's fine.
   (but you might need to double take)

Hence my suggestion to avoid the problem by not using the verb "effect",
even when it's correct.

Nicholas Clark

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Peters]

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 create non-Y2K-compliant
>  programs--and you wouldn't want to do that, would you?
> 
"and" removed.

>  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, while "affect" is a verb.  This is a common English
grammar screw-up.

> Sets the current position for the C routine on DIRHANDLE.  POS
> -must be a value returned by C.  Has the same caveats about
> -possible directory compaction as the corresponding system library
> +must be a value returned by C.  C also Has the same caveats
> +about possible directory compaction as the corresponding system library
>  routine.
>
"Has" changed to "has".
 
> -You can effect a sleep of 250 milliseconds this way:
> +You can affect a sleep of 250 milliseconds this way:
>
Again, effect vs. affect.  Here, this is a verb, so affect is the right
word.

>  the original quicksort was faster.  5.8 has a sort pragma for
>  limited control of the sort.  Its rather blunt control of the
> -underlying algorithm may not persist into future perls, but the
> +underlying algorithm may not persist into future Perls, but the
>  ability to characterize the input or output in implementation
>  independent ways quite probably will.  See L.

Removed.

Attached below is the updated patch.

Steve Peters
[EMAIL PROTECTED]
--- pod/perlfunc.pod.old2005-07-27 11:57:23.0 -0500
+++ pod/perlfunc.pod2005-07-28 05:32:01.0 -0500
@@ -25,7 +25,7 @@
 of scalar arguments or list values; the list values will be included
 in the list as if each individual element were interpolated at that
 point in the list, forming a longer single-dimensional list value.
-Elements of the LIST should be separated by commas.
+Commas should separate elements of the LIST.
 
 Any function in the list below may be used either with or without
 parentheses around its arguments.  (The syntax descriptions omit the
@@ -139,7 +139,7 @@
 C, C, C, C, C, C,
 C, C, C
 
-=item Keywords related to the control flow of your perl program
+=item Keywords related to the control flow of your Perl program
 
 C, C, C, C, C, C, C,
 C, C, C, C, C, C, C
@@ -337,7 +337,7 @@
 The C<-T> and C<-B> switches work as follows.  The first block or so of the
 file is examined for odd characters such as strange control codes or
 characters with the high bit set.  If too many strange characters (>30%)
-are found, it's a C<-B> file, otherwise it's a C<-T> file.  Also, any file
+are found, it's a C<-B> file; otherwise it's a C<-T> file.  Also, any file
 containing null in the first block is considered a binary file.  If C<-T>
 or C<-B> is used on a filehandle, the current IO buffer is examined
 rather than the first block.  Both C<-T> and C<-B> return true on a null
@@ -351,7 +351,7 @@
 a system call.  (This doesn't work with C<-t>, and you need to remember
 that lstat() and C<-l> will leave values in the stat structure for the
 symbolic link, not the real file.)  (Also, if the stat buffer was filled by
-a C call, C<-T> and C<-B> will reset it with the results of C).
+an C call, C<-T> and C<-B> will reset it with the results of C).
 Example:
 
 print "Can do.\n" if -r $a || -w _ || -x _;
@@ -368,7 +368,7 @@
 
 As of Perl 5.9.1, as a form of purely syntactic sugar, you can stack file
 test operators, in a way that C<-f -w -x $file> is equivalent to
-C<-x $file && -w _ && -f _>. (This is only syntax fancy : if you use
+C<-x $file && -w _ && -f _>. (This is only syntax fancy: if you use
 the return value of C<-f $file> as an argument to another filetest
 operator, no special magic will happen.)
 
@@ -394,7 +394,7 @@
 =item alarm
 
 Arranges to have a SIGALRM delivered to this process after the
-specified number of wallclock seconds have elapsed.  If SECONDS is not
+specified number of wallclock seconds has elapsed.  If SECONDS is not
 specified, the value stored in C<$_> is used. (On some machines,
 unfortunately, the elapsed time may be up to one second less or more
 than you specified because of how seconds are counted, and process
@@ -547,13 +547,13 @@
 in the CLASSNAME package.  If CLASSNAME is omitted, the current package
 is used.  Because a C is often the last thing in a constructor,
 it returns the reference for convenience.  Always use the two-argument
-version if the function doing the blessing might be inherited by a
-derived class.  See L and L for more about the blessing
-(and blessings) of objects.
+version if a derived class might inherit the function doing the blessing.
+See L and L for more about the blessing (and blessings)
+of objects.
 
 Consider

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Dominic Dunlop]

On 2005–07–28, at 11:07, H.Merijn Brand wrote:

%.0f<  >-0.1<>-0<  >C library bug: no minus on VMS,  
HP-UX<




Which isn't true anymore anyway. I've just tried on SuSE 9.2, SuSE  
9.3,
AIX 4.3.3, AIX 5.2.0, HP-UX 11i, and HP-UX 11.00, and all print  
"-0" on

the example below. Only HP-UX 10.20 still prints "0"


OK. Can somebody say what the situation is on (particular versions  
of) VMS? -- copied to John E Malmberg in the hope of help.




But anyway, as the C standard has a footnote saying "The results of
all floating conversions of a negative zero, and of negative values
that round to zero, include a minus sign", I've attached a patch for
sprintf.t that adds a test. I fully expect it to fail on a number of
platforms, in which case it can be hoisted into the "problematic"
section. Smokers, let me know of failures please.



And, knowing that it fails on those platforms, what do you want to  
do with

it? Skip or TODO?


Ho hum. sprintf.t doesn't do Skip and TODO (mea culpa), so I'd have  
to hack handling of them into the script, or rewrite the whole thing  
to use test.pl or whatever. I'll look into doing one or the other,  
but in the meantime I'd like to see the patch applied so as to get an  
idea of where this test causes problems.


As to the test's disposition, in the hope of action from the OS  
vendor, I'd like it to be a TODO where it fails, but from what you  
say, it sounds like a Skip for HP-UX 10.20. However, sprintf.t  
currently says:


# we do not load %Config since this test resides in op and needs
# to run under the minitest target even without Config.pm working.

I think that precludes me from looking at the OS version ($Config 
{osvers}), so it won't be possible to do fine-grained skipping  
according to OS type and version. Well, maybe I could attempt to use  
Config, and only do the fine-grained stuff if %Config gets defined...  
Again, I'll look into it.



I can assure you that no changes will be made for libc in
HP-UX 11.00 or below, so the 10.20 failure will stay there till the  
end of
times (unless we work around it in the perl source, which is not  
worth the

trouble if you want my opinion)


Agreed that it's not worth the trouble.
--
Dominic Dunlop

Re: p5 Configure

[H.Merijn Brand]

On Wed, 27 Jul 2005 23:53:30 -0500 (CDT), <[EMAIL PROTECTED]> wrote:

> Hi, I'd like to know who the current maintainer of the perl5 Configure
> program.

I am.

in fact, we all are, but I'm the one who applies the changes

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[H.Merijn Brand]

On Thu, 28 Jul 2005 10:58:50 +0100, Nicholas Clark <[EMAIL PROTECTED]> wrote:

> On Thu, Jul 28, 2005 at 11:07:37AM +0200, H.Merijn Brand wrote:
> 
> > And, knowing that it fails on those platforms, what do you want to do with
> > it? Skip or TODO? I can assure you that no changes will be made for libc
> > in HP-UX 11.00 or below, so the 10.20 failure will stay there till the
> > end of times (unless we work around it in the perl source, which is not
> > worth the trouble if you want my opinion)
> 
> I think the best we can do is document it as "this isn't portable" and leave
> it at that. The behaviour of negative floating point zero is platform
> specific. For starters, it assumes that your platform's floating point can
> represent it.
> 
> Heck, there was a thread a year or two back on perl6-internals where it
> turned out that the precise choice of CPU instructions by the compiler on
> one platform affected whether a particular C construction produced positive
> or negative floating point zero. This was the vendor compiler, not gcc.

OK, here's my suggestion. The comments in the list of tests can now control
the skip behaviour of the test. The patch enables almost all previously
commented out tests, and adds the one Dominic suggested.
I have tested this on HP-UX 10.20, HP-UX 11.00, HP-UX 11.11, AIX 4.3.3,
AIX 5.2, and SuSE 9.2 & 9.3

ok 145
ok 146
ok 147 # skip No minus, failure expected on hpux 10.20
ok 148

--- t/op/sprintf.t  2005-07-18 15:08:05 +0200
+++ /tmp/sprintf.t  2005-07-28 12:21:22 +0200
@@ -11,8 +11,7 @@ BEGIN {
 @INC = '../lib';
 }
 use warnings;
-# we do not load %Config since this test resides in op and needs
-# to run under the minitest target even without Config.pm working.
+use Config;

 # strictness
 my @tests = ();
@@ -85,9 +84,24 @@ for ($i = 1; @tests; $i++) {
}
 }

+my $skip = 0;
+if ($comment =~ s/\s+skip:\s*(.*)//) {
+   my $os = $1;
+   if ($os =~ /\ball\b/i) {# >comment skip: all<
+   $skip = 1;
+   } elsif ($os =~ /\b$^O(?::(\S+))?\b/i) { # >comment skip: VMS 
hpux:10.20<
+   (my $vsn = $1 // "") =~ s/^(\d+(\.\d+)?).*/$1/;
+   $vsn && $Config{osvers} <= $vsn and $skip = 1;
+   }
+$skip and $comment =~ s/$/, failure expected on $^O $Config{osvers}/;
+}
+
 if ($x eq ">$result<") {
 print "ok $i\n";
 }
+elsif ($skip) {
+   print "ok $i # skip $comment\n";
+}
 elsif ($y eq ">$result<")  # Some C libraries always give
 {  # three-digit exponent
print("ok $i # >$result< $x three-digit exponent accepted\n");
@@ -125,15 +139,8 @@ for ($i = 1; @tests; $i++) {

 =begin problematic

->%.0f<  >-0.1<>-0<  >C library bug: no minus on VMS, HP-UX<
 >%.0f<  >1.5< >2<   >Standard vague: no rounding rules<
 >%.0f<  >2.5< >2<   >Standard vague: no rounding rules<
->%G<>1234567e96<  >1.23457E+102<   >exponent too big for OS/390<
->%G<>.1234567e-101< >1.23457E-102< >exponent too small for OS/390<
->%e<>1234567E96<  >1.234567e+102<  >exponent too big for OS/390<
->%e<>.1234567E-101< >1.234567e-102<>exponent too small for OS/390<
->%g<>.1234567E-101< >1.23457e-102< >exponent too small for OS/390<
->%g<>1234567E96<  >1.23457e+102<   >exponent too big for OS/390<

 =end problematic

@@ -154,6 +161,8 @@ __END__
 >%G<>1234567e96<  >1.23457E+102<
 >%G<>.1234567e-101< >1.23457E-102<
 >%G<>12345.6789<  >12345.7<
+>%G<>1234567e96<  >1.23457E+102<   >exponent too big skip: os390<
+>%G<>.1234567e-101< >1.23457E-102< >exponent too small skip: os390<
 >%H<>''<  >%H INVALID<
 >%I<>''<  >%I INVALID<
 >%J<>''<  >%J INVALID<
@@ -250,6 +259,8 @@ __END__
 >%+12.4e<   >1234.875<> +1.2349e+03<
 >%+-12.4e<  >-1234.875<   >-1.2349e+03 <
 >%+12.4e<   >-1234.875<   > -1.2349e+03<
+>%e<>1234567E96<  >1.234567e+102<  >exponent too big skip: os390<
+>%e<>.1234567E-101< >1.234567e-102<>exponent too small skip: os390<
 >%f<>1234.875<>1234.875000<
 >%+f<   >1234.875<>+1234.875000<
 >%#f<   >1234.875<>1234.875000<
@@ -258,6 +269,7 @@ __END__
 >%#f<   >-1234.875<   >-1234.875000<
 >%6f<   >1234.875<>1234.875000<
 >%*f<   >[6, 1234.875]< >1234.875000<
+>%.0f<  >-0.1<>-0<  >C library bug: no minus skip: VMS<
 >%.0f<  >1234.875<>1235<
 >%.1f<  >1234.875<>1234.9<
 >%-8.1f<>1234.875<>1234.9  <
@@ -282,6 +294,7 @@ __END__
 >%g<>12345.6789<  >12345.7<
 >%+g<   >12345.6789<  >+12345.7<
 >%#g<   >12345.6789<  >12345.7<
+>%.0g<  >-0.0<   >-0< >No minus skip: VMS hpux:10.20<
 >%.0g<  >12345.6789<  >1e+04<
 >%#.0g< >12345.6789<  >1.e+04<
 >%.2g<  >12345.6789<  >1.2e+04<
@@ -307,8 +320,10 @@ __END__
 >%g<>0<   >

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Hay]

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 once.  Thus C can be used to affect an early
>> exit out of such a block.
>>
>>
>
>  
>
>>-You can effect a sleep of 250 milliseconds this way:
>>+You can affect a sleep of 250 milliseconds this way:
>>
>>
>
>On Thu, Jul 28, 2005 at 03:50:57AM -0400, Randy W. Sims wrote:
>  
>
>>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.
>  
>
effect is a noun.  affect is a verb so I think this change is correct.


>>>It's also a transitive verb, so "to effect (some direct object)" is
>>>valid English, if potentially unclear.
>>>  
>>>
>>Yes, they can both be used as tr verbs, but see usage from 
>>
>>
>>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 savings. Thus the sentence These measures may affect 
>>savings could imply that the measures may reduce savings that have 
>>already been realized, whereas These measures may effect savings implies 
>>that the measures will cause new savings to come about.
>>
>>
>
>Which would mean that both proposed changes are indeed incorrect, as they're
>both obout causing things.
>  
>
Both changes are certainly incorrect, so I left them unchanged.

>Could we change both verbs to "cause" or "create" to avoid all confusion?
>
I didn't think it was confusing, but that be a minority opinion.




Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender 
immediately.  The unauthorized use, disclosure, copying or alteration of this 
message is strictly forbidden.  Note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will accept no 
liability for any damage caused by any virus transmitted by this email.

Re: [PATCH] perlfunc.pod grammar fixes

[Nicholas Clark]

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
>  exit out of such a block.

> -You can effect a sleep of 250 milliseconds this way:
> +You can affect a sleep of 250 milliseconds this way:

On Thu, Jul 28, 2005 at 03:50:57AM -0400, Randy W. Sims wrote:
> 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.
> >>
> >>effect is a noun.  affect is a verb so I think this change is correct.
> >
> >
> >It's also a transitive verb, so "to effect (some direct object)" is
> >valid English, if potentially unclear.
> 
> Yes, they can both be used as tr verbs, but see usage from 
> 
> 
> 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 savings. Thus the sentence These measures may affect 
> savings could imply that the measures may reduce savings that have 
> already been realized, whereas These measures may effect savings implies 
> that the measures will cause new savings to come about.

Which would mean that both proposed changes are indeed incorrect, as they're
both obout causing things.

Could we change both verbs to "cause" or "create" to avoid all confusion?

Nicholas Clark

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Nicholas Clark]

On Thu, Jul 28, 2005 at 11:07:37AM +0200, H.Merijn Brand wrote:

> And, knowing that it fails on those platforms, what do you want to do with
> it? Skip or TODO? I can assure you that no changes will be made for libc in
> HP-UX 11.00 or below, so the 10.20 failure will stay there till the end of
> times (unless we work around it in the perl source, which is not worth the
> trouble if you want my opinion)

I think the best we can do is document it as "this isn't portable" and leave
it at that. The behaviour of negative floating point zero is platform
specific. For starters, it assumes that your platform's floating point can
represent it.

Heck, there was a thread a year or two back on perl6-internals where it
turned out that the precise choice of CPU instructions by the compiler on one
platform affected whether a particular C construction produced positive or
negative floating point zero. This was the vendor compiler, not gcc.

Nicholas Clark

Re: [perl #36673] sub foo(@$) {} should generate an error

[Rafael Garcia-Suarez]

Piotr Fusik wrote:
> No characters should be allowed in a subroutine prototype
> after an '@' (but not '\@'). This is because no arguments

and not in a [].

> can be effectively passed to a subroutine after an array argument.
> 
> I insist on an error, but a warning would be better than nothing.

One could add this check to "Malformed prototype", and error that
currently has absolutely no test. I don't even know how to generate it.
Anyone wants to try to write a test for it ?

Or, one could add the check in toke.c and raise the error "Illegal
prototype". More straightforward.

-- 
Fix in six / Fix in six / Sing all the perl-a-holics

Re: [PATCH] perlfunc.pod grammar fixes

[Steve Hay]

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.




Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender 
immediately.  The unauthorized use, disclosure, copying or alteration of this 
message is strictly forbidden.  Note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of Radan Computational Ltd.  The recipient(s) of this message should 
check it and any attached files for viruses: Radan Computational will accept no 
liability for any damage caused by any virus transmitted by this email.

Re: gmake (perl-5.8.6) fails on z/OS

[Nicholas Clark]

On Thu, Jul 28, 2005 at 02:37:36AM -0700, rajarshi das wrote:

> However, if I change the first instance to :
> --- utf8.c  2004-11-17 18:22:09.0 +0530
> +++ utf8.c.22005-07-28 13:48:24.0 +0530
> @@ -363,6 +363,11 @@ Perl_utf8n_to_uvuni(pTHX_ U8 *s,
> STRLEN
> warning = UTF8_WARN_EMPTY;
> goto malformed;
>  }
> +#ifdef EBCDIC
> +if (uv == 0xBA) {
> +   uv = NATIVE_TO_UTF(uv);
> +}
> +#endif
> 
>  if (UTF8_IS_INVARIANT(uv)) {
> if (retlen)
> 
> This allows gmake to complete. 
> Thanks for all your help on this.

Do you have any idea *why* this change makes things work?

Nicholas Clark

Re: gmake (perl-5.8.6) fails on z/OS

[rajarshi das]

--- rajarshi das <[EMAIL PROTECTED]> wrote:

> 
> 
> --- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Jul 26, 2005 at 08:34:02AM -0700, rajarshi
> > das wrote:
> > 
> > > Yes, the second call to NATIVE_TO_UTF is still
> > present
> > > in the modified code. Typically, one wouldnt
> want
> > to
> > > do a NATIVE_TO_UTF(NATIVE_TO_UTF(uv)) which is
> > what I
> > > am doing due to the second call. But does that
> > make a
> > > difference to miniperl ? 
> > 
> > Well, the code is linked into miniperl, so I can
> > only assume that it's
> > getting called.
> > 
> > If so, does removing the second instance of
> > NATIVE_TO_UTF() improve things?
> No it doesnt. The same error messages are generated.
> 
However, if I change the first instance to :
--- utf8.c  2004-11-17 18:22:09.0 +0530
+++ utf8.c.22005-07-28 13:48:24.0 +0530
@@ -363,6 +363,11 @@ Perl_utf8n_to_uvuni(pTHX_ U8 *s,
STRLEN
warning = UTF8_WARN_EMPTY;
goto malformed;
 }
+#ifdef EBCDIC
+if (uv == 0xBA) {
+   uv = NATIVE_TO_UTF(uv);
+}
+#endif

 if (UTF8_IS_INVARIANT(uv)) {
if (retlen)

This allows gmake to complete. 
Thanks for all your help on this.
> 
> Thanks,
> Rajarshi.
> > 
> > Nicholas Clark
> > 
> 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

p5 Configure

[vze47kdb]

Hi, I'd like to know who the current maintainer of the perl5 Configure program.

Thanks,
Dave.

Re: [perl #36672] Swapped warnings for -o and -O file tests

[Rafael Garcia-Suarez]

Piotr Fusik wrote:
> 
> $ perl -we '-o'
> Use of uninitialized value in -O at -e line 1.
> 
> $ perl -we '-O'
> Use of uninitialized value in -o at -e line 1.
> 
> I have no idea if anything other than warnings can be affected by this bug.
> A patch is attached.

Thanks, applied, as #25232, except the test. It's already tested by
warnings.t (in t/lib/warnings/9uninit) and the existing test was
wrong...

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[H.Merijn Brand]

On Thu, 28 Jul 2005 10:55:54 +0200, Dominic Dunlop <[EMAIL PROTECTED]>
wrote:

> On 2005–07–28, at 00:43, Piotr Fusik (via RT) wrote:
> >
> > ActivePerl on Windows prints or stringifies -0.0 to "0",
> > rather than the expected "-0":
> >
> > perl -le "print -0.0"
> > 0
> >
> > This is incompatible with the same version of ActivePerl on Linux.
> >
> This may be related to this comment in t/op/sprintf.t:
> 
> # The following tests are not currently run, for the reasons stated:
> 
> =pod
> 
> =begin problematic
> 
>  >%.0f<  >-0.1<>-0<  >C library bug: no minus on VMS, HP-UX<

Which isn't true anymore anyway. I've just tried on SuSE 9.2, SuSE 9.3,
AIX 4.3.3, AIX 5.2.0, HP-UX 11i, and HP-UX 11.00, and all print "-0" on
the example below. Only HP-UX 10.20 still prints "0"

> ...
> 
> Does Windows (or rather Microsoft's standard C library) have the same  
> issue?
> 
> What does Windows ActivePerl say for
> 
> $ perl -we 'printf "%0.f\n", -0.1'
> -0
> 
> But anyway, as the C standard has a footnote saying "The results of  
> all floating conversions of a negative zero, and of negative values  
> that round to zero, include a minus sign", I've attached a patch for  
> sprintf.t that adds a test. I fully expect it to fail on a number of  
> platforms, in which case it can be hoisted into the "problematic"  
> section. Smokers, let me know of failures please.

And, knowing that it fails on those platforms, what do you want to do with
it? Skip or TODO? I can assure you that no changes will be made for libc in
HP-UX 11.00 or below, so the 10.20 failure will stay there till the end of
times (unless we work around it in the perl source, which is not worth the
trouble if you want my opinion)

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Piotr Fusik]

>What does Windows ActivePerl say for
>
>$ perl -we \'printf "%0.f\\n", -0.1\'
>-0
>
C:\>perl -we "printf '%0.f', -0.1"
-0
C:\>perl -we "printf '%0.f', -0.0"
0

[PATCH] Re: [perl #36676] -0.0 printed as "0" on Windows

[Dominic Dunlop]

On 2005–07–28, at 00:43, Piotr Fusik (via RT) wrote:


ActivePerl on Windows prints or stringifies -0.0 to "0",
rather than the expected "-0":

perl -le "print -0.0"
0

This is incompatible with the same version of ActivePerl on Linux.


This may be related to this comment in t/op/sprintf.t:

# The following tests are not currently run, for the reasons stated:

=pod

=begin problematic

>%.0f<  >-0.1<>-0<  >C library bug: no minus on VMS, HP-UX<
...

Does Windows (or rather Microsoft's standard C library) have the same  
issue?


What does Windows ActivePerl say for

$ perl -we 'printf "%0.f\n", -0.1'
-0

But anyway, as the C standard has a footnote saying "The results of  
all floating conversions of a negative zero, and of negative values  
that round to zero, include a minus sign", I've attached a patch for  
sprintf.t that adds a test. I fully expect it to fail on a number of  
platforms, in which case it can be hoisted into the "problematic"  
section. Smokers, let me know of failures please.

--
Dominic Dunlop


sprintf.t-patch
Description: Binary data

Re: [PATCH] perlfunc.pod grammar fixes

[Randy W. Sims]

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.


effect is a noun.  affect is a verb so I think this change is correct.



It's also a transitive verb, so "to effect (some direct object)" is
valid English, if potentially unclear.


Yes, they can both be used as tr verbs, but see usage from 



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 savings. Thus the sentence These measures may affect 
savings could imply that the measures may reduce savings that have 
already been realized, whereas These measures may effect savings implies 
that the measures will cause new savings to come about.

Re: Re: [PATCH] perlfunc.pod grammar fixes

[Piotr Fusik]

>>  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.
>
>> -You can effect a sleep of 250 milliseconds this way:
>> +You can affect a sleep of 250 milliseconds this way:
>
>This is correct.
>
Hmm...

http://dictionary.reference.com/search?q=effect

tr.v. ef·fect·ed, ef·fect·ing, ef·fects 
To bring into existence. 
To produce as a result. 
To bring about. See Usage Note at affect. 


http://dictionary.reference.com/search?q=affect

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 savings. Thus the sentence These measures may affect savings 
could imply that the measures may reduce savings that have already been 
realized, whereas These measures may effect savings implies that the measures 
will cause new savings to come about.

Re: [PATCH] perlfunc.pod grammar fixes

[chromatic]

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.
> 
> effect is a noun.  affect is a verb so I think this change is correct.

It's also a transitive verb, so "to effect (some direct object)" is
valid English, if potentially unclear.

-- c

Re: [PATCH] perlfunc.pod grammar fixes

[Michael G Schwern]

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 want to do that, would you?

The original looks more correct.  Maybe its using a comma wrong, but it
has the proper meaning.


>  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.


> Sets the current position for the C routine on DIRHANDLE.  POS
> -must be a value returned by C.  Has the same caveats about
> -possible directory compaction as the corresponding system library
> +must be a value returned by C.  C also Has the same caveats
> +about possible directory compaction as the corresponding system library
>  routine.

s/Has/has/


> -You can effect a sleep of 250 milliseconds this way:
> +You can affect a sleep of 250 milliseconds this way:

This is correct.


>  the original quicksort was faster.  5.8 has a sort pragma for
>  limited control of the sort.  Its rather blunt control of the
> -underlying algorithm may not persist into future perls, but the
> +underlying algorithm may not persist into future Perls, but the
>  ability to characterize the input or output in implementation
>  independent ways quite probably will.  See L.

Perl is the language.  perl is the program.  Its a bit hazy which this is
talking about but I think it makes sense that the behavior of a module is
in a future version of the language.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: bareword test on ebcdic.

[rajarshi das]

Nicholas Clark <[EMAIL PROTECTED]> wrote:
On Tue, Jul 26, 2005 at 08:48:10AM -0700, rajarshi das wrote:

> > For the code points being tested
> > ("\x{0442}\x{0435}\x{0441}\x{0442}")
> > does the perl source file contain the correct byte
> > sequence in UTF-EBCDIC?
> Yes it does, since I ran the test, 
> if (($hash{"\x{0442}\x{0435}\x{0441}\x{0442}"}) eq
> ($hash{eval '"\x{0442}\x{0435}\x{0441}\x{0442}"'}))
> print "ok\n";
> and the test ran fine, if that is what you mean by the
> source file containing the correct byte sequence. Or
> am I mistaken ?

You are mistaken, I'm afraid. bareword means no quotes.

In ASCII & UTF-8 land, the 1 liner

$ perl -le 'use utf8; $a{ඬ}++; print map {ord} keys %a'

gives

3500


The 3 bytes in the source code between '{' and '}' are 224, 182 and 172
which are the UTF-8 encoding for the code point 3500.

My question is, what are the bytes in UTF-EBCDIC that encode code point 3500?

The equivalent bytes on UTF-EBCDIC are 186, 84 and 83. 

If you put those 3 bytes directly between the '{' and '}' characters in
the EBCDIC version of that 1 liner, does it also print 3500?
I am unable to put those three bytes in the 1-liner you mentioned above, since 
I am unable to print the chars corresponding to those bytes 
(www.kostis.net/charsets/ebc1047.htm) on the command line. 

> > If so, *that* would explain the failures, and be the
> > thing that needs
> > correcting. The test file would need if/else with a
> > different test on EBCDIC.
> what would you suggest be put in the if/ else ?

I think that the regression tests tended to do something like

if (ord 'A' == 65) {
# Do the ASCII/UTF-8 version
} else {
# Assume EBCDIC
}


Thanks,

Rajarshi.


Nicholas Clark




-
 Start your day with Yahoo! - make it your home page 

Re: [PATCH] Tru64: use -c99 for ccflags if available

[H.Merijn Brand]

On Thu, 28 Jul 2005 08:32:25 +0300, Jarkko Hietaniemi <[EMAIL PROTECTED]>
wrote:

> A better way to declare strict ANSI-C-ness in Tru64 is to use
> the -c99 for ccflags (but still -std1 for the lddlflags), but
> of course use the -c99 only if it is available.
> 
> A useful feature that becomes available with -c99 is the __func__,
> which is handy for the -DPERL_MEM_LOG.

I've applied the second improved patch as change #25231


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org