Re: affect/effect (was perlfunc.pod grammar fixes)
On 8/3/05, Joshua Juran [EMAIL PROTECTED] wrote: On Aug 2, 2005, at 4:18 AM, demerphq wrote: On 7/28/05, Joe McMahon [EMAIL PROTECTED] wrote: 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 Clast can be used to effect an early +that executes once. Thus Clast can be used to affect an early exit out of such a block. Perhaps this should use neither affect nor effect. If native english speakers are going to debate which is appropriate then non native speakers shouldnt have to deal with it at all. Change it to Thus Clast can be used to _cause_ an early (without emphasis) and the problem goes away. And IMO reads better anyway. How about Thus Clast can be used to exit out of such a block early.? I find 'effect' slightly more preferable than 'cause' -- it sounds weird to 'cause' something that's entirely under your control anyway. I don't cause a brushing of my teeth; I just brush them. Furthermore, I find this use of 'effect' to be rather affected. :-) Hmm, good point. I wonder if perl documentation authors have a tendency to avoid words that are also perl keywords in their contributions? :-) yves -- perl -Mre=debug -e /just|another|perl|hacker/
RE: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:
From: John E. Malmberg
much snipping
From what I have seen of the other tests, the INC setting when running
these tests is usually inherited from the parent, and I have seen the
tests use a test when deciding to use blib or not.
I did not know the correct fix, just what I needed to stop the script
from failing so soon. The [-.lib] was the only place that I could find
the modules. That is also the setting that was passed on the command
line to 03examples.t.
Is there really any reason that there is VMS specific code here?
What happens if you remove it?
It works the same way as with the last patch. Apparently VMS does not
need to be special cased here.
OK, I'll remove that code from my development copy.
This leaves the case where C::Zlib is built away from the core, which is
what the original code did
$Inc = '-I[.blib.lib] -I[.blib.arch]'
Once someone gets around to building C::Zlib away from the core we can
revisit this.
Tests 8,9,10,12,13 still fail for an unknown reason that I have not had
time to investigate.
Tests 10-13 all pass the STDIN filehandle to zlib. We discussed this earlier
in the thread.
The only thing different about Tests 8 and 9 is that the test uses two
invocations of Perl with a unix pipe between them
$Perl $Inc ${examples}/filtdef $file1 $file2 | $Perl $Inc
${examples}/filtinf 2$stderr
Are there any issue with this on VMS? Perhaps there is an issue with passing
binary data through the pipe?
Paul
[PATCH] Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
On 2005–08–01, at 23:10, Abe Timmerman wrote: It looks like there's more than windows and openbsd3.7: http://www.test-smoke.org/cgi/tsdb? fososver=1farch=1frtext=1rtext=failed +147pversion=5.9.3plcmp=fromlmode=List+reports (sorry, it's slow) Thanks. As well as openbsd 3.7, that adds netbsd 1.5 and Irix 6.2 to the list of failing systems. (Linux 2.6.12 also appears in the smoke failures, but that was due to another issue which should have been fixed by change #25247.) I should like to leave the new test in place and extend its skip list to cover all currently failing platforms. I append a patch which does that, and which makes the message output when the test is skipped better explain what's going on. (Thanks to John E Malmberg for the suggestion.) As Irix is pretty umm, stable -- in the sense set out in Jarkko's .sig -- I've said that all Irixes are expected to fail. For the BSDs, OTOH, I've said that versions up to and including the current are expected to fail. -- Dominic Dunlop sprintf_skip_patch Description: Binary data
Re: [PATCH] Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
On Wed, 3 Aug 2005 12:19:03 +0200, Dominic Dunlop [EMAIL PROTECTED] wrote: On 2005–08–01, at 23:10, Abe Timmerman wrote: It looks like there's more than windows and openbsd3.7: http://www.test-smoke.org/cgi/tsdb? fososver=1farch=1frtext=1rtext=failed +147pversion=5.9.3plcmp=fromlmode=List+reports (sorry, it's slow) Thanks. As well as openbsd 3.7, that adds netbsd 1.5 and Irix 6.2 to the list of failing systems. (Linux 2.6.12 also appears in the smoke failures, but that was due to another issue which should have been fixed by change #25247.) I should like to leave the new test in place and extend its skip list to cover all currently failing platforms. I append a patch which does Thanks, applied as change #25264 that, and which makes the message output when the test is skipped better explain what's going on. (Thanks to John E Malmberg for the suggestion.) As Irix is pretty umm, stable -- in the sense set out in Jarkko's .sig -- I've said that all Irixes are expected to fail. For the BSDs, OTOH, I've said that versions up to and including the current are expected to fail. -- 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: Smoke [5.9.3] 25263 FAIL(F) cygwin_nt-5.0 1.5.18(0.132/4/2) (x86/1 cpu)
On Wed, 3 Aug 2005 08:55 +0200, H.Merijn Brand [EMAIL PROTECTED] wrote: Automated smoke report for 5.9.3 patch 25263 pc03: x86 Family 15 Model 1 Stepping 2, GenuineIntel (x86/1 cpu) oncygwin_nt-5.0 - 1.5.18(0.132/4/2) using gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) smoketime 8 hours 52 minutes (average 1 hour 6 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 25263 Configuration (common) none --- - F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Locally applied patches: DEVEL24148 Failures: (common-args) none [stdio/perlio] [stdio/perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint [stdio/perlio] -Duseithreads [stdio/perlio] -DDEBUGGING -Duseithreads [stdio/perlio] -Duseithreads -Duse64bitint [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../ext/POSIX/t/sigaction.t..FAILED 30 ../t/io/fs.tFAILED 18 I have no clue what to do about these two remaining failures. I was so very happy when I got Cygwin back to full 'O' -- 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
Smoke [5.9.3] 25263 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25263 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 54 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 25263 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
Paul Marquess wrote:
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:
From: John E. Malmberg
much snipping
OK, I'll remove that code from my development copy.
This leaves the case where C::Zlib is built away from the core, which is
what the original code did
$Inc = '-I[.blib.lib] -I[.blib.arch]'
Once someone gets around to building C::Zlib away from the core we can
revisit this.
I would not put in any VMS specific handling for $Inc. VMS should
handle the UNIX case. It does for other modules.
The only reason for any VMS specific code that I can see is needed in
this test is that the command to the child process has an argument that
is enclosed in single quotes.
On VMS, enclosing an argument in single quotes causes the DCL shell to
try to substitute it for a symbol of that name, and if there is no
symbol, it replaces it as blank.
I do not know how I can easily detect this case inside the VMS specific
Perl code that handles it with out breaking Perl scripts that are
specifically written for VMS and depend on this behavior.
Tests 8,9,10,12,13 still fail for an unknown reason that I have not had
time to investigate.
Tests 10-13 all pass the STDIN filehandle to zlib. We discussed this earlier
in the thread.
The only thing different about Tests 8 and 9 is that the test uses two
invocations of Perl with a unix pipe between them
$Perl $Inc ${examples}/filtdef $file1 $file2 | $Perl $Inc
${examples}/filtinf 2$stderr
Are there any issue with this on VMS? Perhaps there is an issue with passing
binary data through the pipe?
As discussed earlier, the error message is that the child perl process
is dying when it tries to add the binary data to the pipe, before any
data gets sent. I have not had time to investigate.
The pipe code in VMS Perl is complex, and I have not had time to
investigate it. It is also adding \n to the data stream at times which
does seem to cause some problems for other Perl scripts which are
special casing for it.
VMS can handle binary data in a pipe. I do not know if VMS Perl can though.
The main reason I am in blead-perl is that I have a number of fixes to
the VMS filename handling code that I want to get merged in, but I need
to get bead-perl stable enough to test them.
Currently in blead-perl, I have about 24 failures to chase down.
I have two data-corruption fixes pending in discussion on this list, and
one of them does not appear to be VMS specific, the other is specific to
a special case of VMS filename handling.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: Smoke [5.9.3] 25245 FAIL(F) MSWin32 Win2000 SP4 (x86/1 cpu)
Abe Timmerman wrote: [sorry, no mail on this box] Steve Hay wrote: Abe Timmerman wrote: Op een mooie zomerdag (Friday 29 July 2005 21:11),schreef Abe Timmerman: Automated smoke report for 5.9.3 patch 25245 neewa: x86 Family 6 Model 5 Stepping 2(~450 MHz) (x86/1 cpu) onMSWin32 - Win2000 SP4 using bcc32 version 5.5.1 smoketime 2 hours 13 minutes (average 1 hour 6 minutes) X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Summary: FAIL(F) ... ../lib/Time/Local.t.FAILED 97-120 Weird. I just tried a smoke with the same version of Borland and the same configurations of perl, and got success: http://www.nntp.perl.org/group/perl.daily-build.reports/29840 The only difference is a few patch levels (which I don't think is relevant) and the OS -- I'm using Win XP. I don't have Win 2000 machine on which I can take a closer look at this. I see that your VC++ smokes on the same Win 2000 machine are successful, though, so it looks like some strange issue with bcc32 + Win 2000. I'm afraid not :-( Do you have a Win XP machine that you could try the bcc32 smoke on to confirm that? Automated smoke report for 5.9.3 patch 25260 ati4: Intel(R) Pentium(R) 4 CPU 2.80GHz(~2793 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using bcc32 version 5.5.1 smoketime 39 minutes 42 seconds (average 19 minutes 51 seconds) Summary: FAIL(F) ... ../lib/Time/Local.t.FAILED 97-120 Oh. Now I'm really confused. I wonder what's different about your machines compared to mine. Here's one straw to clutch at: If you double-click on the time display in the task bar and then go to the Time Zone tab in the Date and Time Properties dialog box that opens, what time zone do your machines say, and are they set to Automatically adjust clock for daylight saving changes or not? 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.
is $[ really deprecated?
There was some debate about whether $[ is deprecated or not at http://perlmonks.org/index.pl?node_id=480333 . perldata says: Version 5 of Perl changed the semantics of $[: files that don't set the value of $[ no longer need to worry about whether another file changed its value. (In other words, use of $[ is ***deprecated***.) but perlvar says: As of release 5 of Perl, assignment to $[ is treated as a compiler directive, and cannot influence the behavior of any other file. (That's why you can only assign compile-time constants to it.) Its use is highly ***discouraged***. which give slightly different messages. And, certainly, changing $[ does not result in deprecation warnings. Should the wording of either of these documents change? Or should $[ produce deprecation warnings? Or should we stop splitting hairs about this and forget about it? ;-) -- ivan
Smoke [5.9.3] 25263 FAIL(F) openbsd 3.7 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25263 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (548 MHz) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 8 hours 37 minutes (average 1 hour 4 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 25263 Configuration (common) none --- - F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] [stdio/perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint [stdio/perlio] -Duseithreads [stdio/perlio] -DDEBUGGING -Duseithreads [stdio/perlio] -Duseithreads -Duse64bitint [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../t/op/sprintf.t...FAILED 147 Compiler messages(gcc): /tmp//ccay4017.o(.text+0x3e): In function `main': /tmp//ccX11475.o(.text+0x5d): In function `main': /tmp//ccG19597.o(.text+0xde): In function `main': op.c: In function `Perl_newCONSTSUB': op.c:4611: warning: null argument where non-null required (arg 1) opmini.c: In function `Perl_newCONSTSUB': opmini.c:4611: warning: null argument where non-null required (arg 1) libperl.a(perlio.o)(.text+0x4ed8): In function `PerlIO_vsprintf': opmini.o(.text+0x316): In function `Perl_allocmy': libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex': libperl.a(op.o)(.text+0x316): In function `Perl_allocmy': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x23e): In function `XS_DynaLoader_dl_load_file': util.o(.text+0x1f3): In function `savestr': str.o(.text+0x5d): In function `str_2ptr': byterun.c: In function `byterun': byterun.c:893: warning: comparison is always false due to limited range of data type ../libperl.a(perlio.o)(.text+0x4ed8): In function `PerlIO_vsprintf': ../libperl.a(op.o)(.text+0x316): In function `Perl_allocmy': ../libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex': /tmp//cca15468.o(.text+0x3e): In function `main': /tmp//ccU23123.o(.text+0x5d): In function `main': /tmp//ccP28335.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x4f98): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x326): In function `XS_DynaLoader_dl_load_file': util.o(.text+0x2c3): In function `savestr': str.o(.text+0x81): In function `str_2ptr': ../libperl.a(perlio.o)(.text+0x4f98): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex': /tmp//ccQm8789.o(.text+0x3e): In function `main': /tmp//ccL19809.o(.text+0x5d): In function `main': /tmp//ccm19179.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x52f4): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex': ../libperl.a(perlio.o)(.text+0x52f4): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex': /tmp//ccV26076.o(.text+0x3e): In function `main': /tmp//ccc23788.o(.text+0x5d): In function `main': /tmp//ccm21196.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x53b4): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x32a): In function `XS_DynaLoader_dl_load_file': ../libperl.a(perlio.o)(.text+0x53b4): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex': /tmp//ccw26528.o(.text+0x3e): In function `main': /tmp//ccdb9944.o(.text+0x5d): In function `main': /tmp//ccZ16281.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x127): In function `PerlIO_debug': opmini.o(.text+0x39d): In function `Perl_allocmy': libperl.a(toke.o)(.text+0x8060): In function `Perl_yylex': libperl.a(op.o)(.text+0x39d): In function `Perl_allocmy': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x302): In function `XS_DynaLoader_dl_load_file': DProf.xs:140: warning: `unused' attribute ignored ../libperl.a(perlio.o)(.text+0x127): In function `PerlIO_debug': ../libperl.a(op.o)(.text+0x39d): In function `Perl_allocmy': ../libperl.a(toke.o)(.text+0x8060): In function `Perl_yylex': /tmp//ccp15203.o(.text+0x3e): In function `main': /tmp//ccf17592.o(.text+0x5d): In function `main': /tmp//ccvJ4346.o(.text+0xde): In function `main': libperl.a(toke.o)(.text+0x8ed0): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x4f6): In function `XS_DynaLoader_dl_load_file':
Re: is $[ really deprecated?
On Wed, 03 Aug 2005 11:05:36 -0400, Ivan Tubert-Brohman [EMAIL PROTECTED] wrote: There was some debate about whether $[ is deprecated or not at http://perlmonks.org/index.pl?node_id=480333 . It is. But indeed, there are no warnings. d3:/u/usr/merijn 103 perl5.6.1 -wle'$[ = 1' d3:/u/usr/merijn 104 perl5.8.0 -wle'$[ = 1' d3:/u/usr/merijn 105 pc09:/home/merijn 110 perl5.8.5 -wle'$[ = 1' pc09:/home/merijn 111 perl5.8.6 -wle'$[ = 1' pc09:/home/merijn 112 perl5.9.2 -wle'$[ = 1' pc09:/home/merijn 113 perldata says: Version 5 of Perl changed the semantics of $[: files that don't set the value of $[ no longer need to worry about whether another file changed its value. (In other words, use of $[ is ***deprecated***.) but perlvar says: As of release 5 of Perl, assignment to $[ is treated as a compiler directive, and cannot influence the behavior of any other file. (That's why you can only assign compile-time constants to it.) Its use is highly ***discouraged***. which give slightly different messages. And, certainly, changing $[ does not result in deprecation warnings. Should the wording of either of these documents change? Or should $[ produce deprecation warnings? Or should we stop splitting hairs about this and forget about it? ;-) -- 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: affect/effect (was perlfunc.pod grammar fixes)
How about Thus Clast can be used to exit out of such a block early.? Thus Clast can be used leave such a block immediately.? Anyone else for putting all the documentation on some kind of heavily modified wiki? The resulting optimized collaborative text editing environment would be a Good Thing in its own right --- maybe I'll write another TPF grant application.
Re: is $[ really deprecated?
On 8/3/05, Ivan Tubert-Brohman [EMAIL PROTECTED] wrote: perldata says: Version 5 of Perl changed the semantics of $[: files that don't set the value of $[ no longer need to worry about whether another file changed its value. (In other words, use of $[ is ***deprecated***.) In other words, in now (in perl 5) a pragma. but perlvar says: As of release 5 of Perl, assignment to $[ is treated as a compiler directive, and cannot influence the behavior of any other file. (That's why you can only assign compile-time constants to it.) Its use is highly ***discouraged***. which give slightly different messages. And, certainly, changing $[ does not result in deprecation warnings. perlvar is correct. Should the wording of either of these documents change? Or should $[ produce deprecation warnings? Or should we stop splitting hairs about this and forget about it? ;-) $[ is a pain when you come across it in the perl internals. It's not deprecated yet, and I see no compelling reason to begin a deprecation cycle and introduce new warnings; but I'm not completely against it either.
[perl #36781] warnings.pm: enabled/warn/warnif functions: bug. (PATCH)
# New Ticket Created by Animator
# Please include the string: [perl #36781]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36781
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.5.
-
[Please enter your report here]
Hello,
Several functions that are part of the warning pragma are buggy.
One of them is warnings::enabled. This functions takes a category and
reports whether or not warnings for that particular category are enabled
or disabled.
What goes wrong is that it checks if the warning was enabled at the
start of the block, in which the warnings::enabled call is. A
consequence of that is that warnings::enabled gives an incorrect return
value when a warning is enabled/disabled in that same block.
Code::
#!/usr/bin/perl
sub sub1 {
sub2();
}
sub sub2 {
use warnings qw/void/;
print warnings::enabled('void');
}
sub1();
Output:
This outputs 0, even though the warning is enabled.
Cause:
The reason why it outputs 0 and not 1 is because the warnings::enabled
checks in what context sub2 is called. sub1 called it, so it uses that
context, using the caller function, and at the moment sub2 was called,
the void-warnings were disabled.
The function that is responsible for that is the __chk function in
warnings.pl/pm.
If I understand the code of this function correctly then it does a trace
and stops at the first function that isn't part of the warnings package.
In the example above it stops at main::sub2. Then it checks the context
of that call, using the built-in caller function, which means it is
actually checking if a warning was enabled in sub1.
Below you find two patches, one for warnings.pl and one for warnings.pm.
The second is only included for the people that are unable to run the
warnings.pl script to re-create the warnings.h and warnings.pm file.
--- old/warnings.pl Fri Jul 29 23:13:36 2005
+++ new/warnings.pl Fri Jul 29 23:14:47 2005
@@ -752,7 +752,7 @@
if !$pkg || $pkg eq $this_pkg ;
}
-my $callers_bitmask = (caller($i))[9] ;
+my $callers_bitmask = (caller($i - 1))[9] ;
return ($callers_bitmask, $offset, $i) ;
}
--- old/lib/warnings.pm Fri Jul 29 23:13:09 2005
+++ new/lib/warnings.pm Fri Jul 29 23:12:54 2005
@@ -440,7 +440,7 @@
if !$pkg || $pkg eq $this_pkg ;
}
-my $callers_bitmask = (caller($i))[9] ;
+my $callers_bitmask = (caller($i - 1))[9] ;
return ($callers_bitmask, $offset, $i) ;
}
A simple test:
#!perl
use Test;
BEGIN { plan tests = 3 }
sub warnings_test {
use warnings;
my $code = sub {
no warnings qw/void/;
ok(warnings::enabled('all') == 0);
ok(warnings::enabled('misc') == 1);
ok(warnings::enabled('void') == 0);
};
$code-();
}
warnings_test();
[Please do not change anything below this line]
-
---
Flags:
category=library
severity=low
---
Site configuration information for perl v5.8.5:
Configured by dennis at Wed Aug 18 16:09:43 CEST 2004.
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=freebsd, osvers=4.10-stable, archname=i386-freebsd
uname='freebsd raiden 4.10-stable freebsd 4.10-stable #0: wed aug 18
13:45:50 cest 2004 [EMAIL PROTECTED]:usrobjusrsrcsysraiden i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-fno-strict-aliasing -pipe -I/usr/local/include',
optimize='-O',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing
-pipe -I/usr/local/include'
ccversion='', gccversion='2.95.4 20020320 [FreeBSD]',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lcrypt -lutil -lc
perllibs=-lm -lcrypt -lutil -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.5:
/usr/local/lib/perl5/5.8.5/i386-freebsd
/usr/local/lib/perl5/5.8.5
/usr/local/lib/perl5/site_perl/5.8.5/i386-freebsd
[perl #36795] Dprof/dprofpp reports incorrect subroutine call count if #Calls 999999
# New Ticket Created by Will Fischer
# Please include the string: [perl #36795]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36795
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.1.
-
Dprof/dprofpp reports incorrect subroutine call count if calls 99
(possibly the problem is in dprofpp)
In this version of Dprof/dprofpp, the #Calls field is apparently
limited to
6 characters: values = 10**6 are truncated (keeping the left-most 6
digits only).
For example, the following one-liner calls a no-op subroutine 1,234,567
times,
but only 123,456 calls are reported:
% perl -d:Dprof -e 'sub just_call_it { return } for (1..1234567) {
just_call_it() }'
% dprofpp
Total Elapsed Time = 6.433940 Seconds
User+System Time =0 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
0.00 - -1.133 123456- - main::just_call_it
I was going crazy trying to figure why my subroutine was slowing down
for different data set,
when in fact there were simply more calls to it
-
---
Flags:
category=utilities
severity=medium
---
Site configuration information for perl v5.8.1:
Configured by root at Fri Sep 12 19:46:46 PDT 2003.
Summary of my perl5 (revision 5.0 version 8 subversion 1 RC3)
configuration:
Platform:
osname=darwin, osvers=7.0, archname=darwin-thread-multi-2level
uname='darwin hampsten 7.0 darwin kernel version 6.0: fri jul 25
16:58:41 pdt 2003;
root:xnu-344.frankd.rootsxnu-344.frankd~objrelease_ppc power macintosh
powerpc '
config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe
-Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-g -pipe -pipe -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -I/usr/local/include',
optimize='-Os',
cppflags='-no-cpp-precomp -g -pipe -pipe -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build
1495)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lc
perllibs=-ldl -lm -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true,
libperl=libperl.dylib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup
-L/usr/local/lib'
Locally applied patches:
RC3
---
@INC for perl v5.8.1:
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
/System/Library/Perl/5.8.1
/Library/Perl/5.8.1/darwin-thread-multi-2level
/Library/Perl/5.8.1
/Library/Perl
/Network/Library/Perl/5.8.1/darwin-thread-multi-2level
/Network/Library/Perl/5.8.1
/Network/Library/Perl
.
---
Environment for perl v5.8.1:
DYLD_LIBRARY_PATH (unset)
HOME=/Users/wfischer
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/sw/bin:/Users/wfischer/scripts:/
Users/wfischer/bin:/Developer/Tools:/usr/local/bin:/Volumes/t10-samba1/
scripts:/Volumes/T10-NET;FLY/scripts:/System/Library/Frameworks/
Python.framework/Versions/2.3/bin:.:/sw/bin:/Users/wfischer/scripts:/
Users/wfischer/bin:/Developer/Tools:/usr/local/bin:/Volumes/t10-samba1/
scripts:/Volumes/T10-NET;FLY/scripts:/System/Library/Frameworks/
Python.framework/Versions/2.3/bin:.:/sw/bin:/Users/wfischer/scripts:/
Users/wfischer/bin:/Developer/Tools:/usr/local/bin:/Volumes/t10-samba1/
scripts:/Volumes/T10-NET;FLY/scripts:/System/Library/Frameworks/
Python.framework/Versions/2.3/bin:.
PERL_BADLANG (unset)
SHELL=/bin/bash
Re: Smoke [5.9.3] 25245 FAIL(F) MSWin32 Win2000 SP4 (x86/1 cpu)
Op een mooie zomerdag (Wednesday 03 August 2005 16:26),schreef Steve Hay: Abe Timmerman wrote: ... Automated smoke report for 5.9.3 patch 25260 ati4: Intel(R) Pentium(R) 4 CPU 2.80GHz(~2793 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using bcc32 version 5.5.1 smoketime 39 minutes 42 seconds (average 19 minutes 51 seconds) Summary: FAIL(F) ... ../lib/Time/Local.t.FAILED 97-120 Oh. Now I'm really confused. I wonder what's different about your machines compared to mine. Here's one straw to clutch at: If you double-click on the time display in the task bar and then go to the Time Zone tab in the Date and Time Properties dialog box that opens, what time zone do your machines say, and are they set to Automatically adjust clock for daylight saving changes or not? Both are are set to Amsterdam... (GMT+1) with automatic dst Rerunning the testsuite without automatic dst (even with rebuild) shows the same failures... Good luck, Abe -- [about random hash-seed] On Windows, I guess we just seed using the user's credit card number as extracted from the registry. Product activation collects that, doesn't it? -- Nicholas Clark on p5p @ 2003-07-07
Re: is $[ really deprecated?
On Wed, Aug 03, 2005 at 10:45:28PM +0200, Rafael Garcia-Suarez wrote: On 8/3/05, Ivan Tubert-Brohman [EMAIL PROTECTED] wrote: perldata says: Version 5 of Perl changed the semantics of $[: files that don't set the value of $[ no longer need to worry about whether another file changed its value. (In other words, use of $[ is ***deprecated***.) In other words, in now (in perl 5) a pragma. but perlvar says: As of release 5 of Perl, assignment to $[ is treated as a compiler directive, and cannot influence the behavior of any other file. (That's why you can only assign compile-time constants to it.) Its use is highly ***discouraged***. which give slightly different messages. And, certainly, changing $[ does not result in deprecation warnings. perlvar is correct. Should the wording of either of these documents change? Or should $[ produce deprecation warnings? Or should we stop splitting hairs about this and forget about it? ;-) $[ is a pain when you come across it in the perl internals. It's not deprecated yet, and I see no compelling reason to begin a deprecation cycle and introduce new warnings; but I'm not completely against it either. What would the gain be if you remove $[? We wouldn't be able to remove $[ before 5.12, and when will that be? 2010? It'll be work to remove it, with the possibility to introduce bugs, it's likely to break some old programs that have been running smootly for years. And it's not that you often see new code using $[. In fact, I cannot recall ever seeing anyone posting code to Usenet or Perlmonks that used $[ - except code using $[ for the sake of using $[. I'd say, let it rest. It seems to be hardly used anyway. The only chance I'd recommend is to _remove_ mentioning of $[ from the documentation in places like 'index' and 'splice'. Describe $[ in perlvar, mention its use is discouraged, and don't mention it in perlfunc or perldata. Abigail pgpymnVcltKQc.pgp Description: PGP signature
Re: is $[ really deprecated?
On Thu, Aug 04, 2005 at 12:26:32AM +0200, Abigail wrote: What would the gain be if you remove $[? The ponie guys might find it useful not having to implement it. Nick? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
