Re: [perl #6749] Perl debugger outputs ctrl-\ wrongly
On Tue, 12 Jul 2005 15:36:54 -0700, "Michael G Schwern via RT" <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] - Thu Apr 05 19:58:47 2001]: > > The Perl debugger outputs strings containing the character > > ctrl-\ wrongly when using the "x" command. For example, > > x chr(28) results in "\c\" and x "\c\\" results in "\c\\\". > > The results, however, are not valid Perl and will result in > > "string terminator not found before end of line". > > The problem is in dumpvar.pl which x uses. The attached patch fixes this. Thanks, applied as change #25130 -- 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: Can we assume 5005threads are dead?
On Tue, 12 Jul 2005 18:19:25 -0700, Michael G Schwern <[EMAIL PROTECTED]> wrote: > Configure sez: > > The 5005threads version is effectively unmaintained and will probably be > removed in Perl 5.10, so there should be no need to build a Perl using it > unless needed for backwards compatibility with some existing 5.005threads > code. > > Can I assume, for the purposes of closing bugs and deleting code, that > this is true and we're go for removing all the 5005threads code in 5.10? There is effectively no 5005threads code left in blead. Only Configure itself still supports it, because the same Configure is also used for 5.8.x and 5.6.x It was my first chainsaw -- 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
[PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give "masked" warning
On Tue, Jul 12, 2005 at 08:29:58PM -0700, Michael G Schwern via RT wrote:
>
> This is still an issue in 5.9.x. I'd agree, there should be a warning
> particularly because all other combinations issue a warning:
>
> $ bleadperl -lwe 'my $x = 42; our $x = 23; print $x'
> 23
> $ bleadperl -lwe 'my $x = 42; my $x = 23; print $x'
> "my" variable $x masks earlier declaration in same scope at -e line 1.
> 23
> $ bleadperl -lwe 'our $x = 42; my $x = 23; print $x'
> "my" variable $x masks earlier declaration in same scope at -e line 1.
> 23
> $ bleadperl -lwe 'our $x = 42; our $x = 23; print $x'
> "our" variable $x masks earlier declaration in same scope at -e line 1.
> 23
I agree too. The following patch will make the first case warn too.
Note that it also changes this current behaviour:
% perl -wle 'our $p; package X; our $p;'
% perl -wle 'our $p; package X; my $p;'
"my" variable $p masks earlier declaration in same scope at -e line 1.
so that the second case doesn't warn. I can't see any reason for the
second case to warn if the first doesn't.
--
Rick Delaney
[EMAIL PROTECTED]
diff -ruN perl-current/pad.c perl-current-dev/pad.c
--- perl-current/pad.c 2005-07-12 20:49:00.0 -0400
+++ perl-current-dev/pad.c 2005-07-13 01:44:01.477332772 -0400
@@ -515,8 +515,7 @@
&& sv != &PL_sv_undef
&& !SvFAKE(sv)
&& (SvIVX(sv) == PAD_MAX || SvIVX(sv) == 0)
- && (!is_our
- || ((SvFLAGS(sv) & SVpad_OUR) && GvSTASH(sv) == ourstash))
+ && (!(SvFLAGS(sv) & SVpad_OUR) || GvSTASH(sv) == ourstash)
&& strEQ(name, SvPVX_const(sv)))
{
Perl_warner(aTHX_ packWARN(WARN_MISC),
diff -ruN perl-current/t/lib/warnings/pad perl-current-dev/t/lib/warnings/pad
--- perl-current/t/lib/warnings/pad 2003-11-14 18:55:28.0 -0500
+++ perl-current-dev/t/lib/warnings/pad 2005-07-13 01:49:09.614260624 -0400
@@ -33,18 +33,27 @@
my $x ;
my $x ;
my $y = my $y ;
+my $p;
+package X;
+my $p;
+package main;
no warnings 'misc' ;
my $x ;
my $y ;
EXPECT
"my" variable $x masks earlier declaration in same scope at - line 4.
"my" variable $y masks earlier declaration in same statement at - line 5.
+"my" variable $p masks earlier declaration in same scope at - line 8.
# pad.c
use warnings 'misc' ;
our $x ;
our $x ;
our $y = our $y ;
+our $p;
+package X;
+our $p;
+package main;
no warnings 'misc' ;
our $x ;
our $y ;
@@ -57,6 +66,10 @@
our $x ;
my $x ;
our $y = my $y ;
+our $p;
+package X;
+my $p;
+package main;
no warnings 'misc' ;
our $z ;
my $z ;
@@ -66,18 +79,22 @@
"my" variable $y masks earlier declaration in same statement at - line 5.
# pad.c
-# TODO not implemented yet
use warnings 'misc' ;
my $x ;
our $x ;
my $y = our $y ;
+my $p;
+package X;
+our $p;
+package main;
no warnings 'misc' ;
my $z ;
our $z ;
my $t = our $t ;
EXPECT
-"our" variable $x masks earlier declaration in same scope at - line 5.
-"our" variable $y masks earlier declaration in same statement at - line 6.
+"our" variable $x masks earlier declaration in same scope at - line 4.
+"our" variable $y masks earlier declaration in same statement at - line 5.
+"our" variable $p masks earlier declaration in same scope at - line 8.
# pad.c
use warnings 'closure' ;
@@ -219,6 +236,13 @@
use warnings 'misc' ;
+my $x;
+{
+my $x;
+}
+EXPECT
+
+use warnings 'misc' ;
our $x;
{
our $x;
@@ -227,6 +251,20 @@
"our" variable $x redeclared at - line 4.
(Did you mean "local" instead of "our"?)
+use warnings 'misc' ;
+our $x;
+{
+my $x;
+}
+EXPECT
+
+use warnings 'misc' ;
+my $x;
+{
+our $x;
+}
+EXPECT
+
# an our var being introduced should suppress errors about global syms
use strict;
use warnings;
Re: [perl #17765] UTF-8 in the debugger
On Jul 12, 2005, at 4:13 PM, Michael G Schwern via RT wrote:
[joemcmahon - Fri Jun 03 15:00:45 2005]:
Same program in the debugger:
% perl -de '
$_ = "\x{100}";
s/[\x{100}]/o/;
print "$_\n";
'
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:2): $_ = "\x{100}";
DB<1> c
Wide character in print at -e line 4.
?
This seems to fix the problem; it just adds ":utf8" to the debugger's
output filehandle.
The problem is not the "wide character in print" warning. The problem
is that $_ is not 'o' as it is when run outside the debugger.
Right, wrong problem solved. :)
--- Joe M.
[perl #3269] no warnings "foo" without "use warnings" turns off all warnings.
> [EMAIL PROTECTED] - Fri May 19 04:23:23 2000]: > > $ perl -wle 'foo.bar' > Unquoted string "foo" may clash with future reserved word at -e > line 1. > Unquoted string "bar" may clash with future reserved word at -e > line 1. > Useless use of concatenation (.) in void context at -e line 1. > $ perl -wle 'no warnings "bareword"; foo.bar' > $ It seems that 'no warnings "foo"' without a preceding "use warnings" turns off all warnings even if -w is given! > The latter should warn about the void use of concatenation. > > $ perl -wle 'use warnings "all"; no warnings "bareword"; foo.bar' > Unquoted string "foo" may clash with future reserved word at -e > line 1. > Unquoted string "bar" may clash with future reserved word at -e > line 1. > Useless use of concatenation (.) in void context at -e line 1. > $ > > And this should have warned only about the void use of concatenation. No, "Unquoted string..." is a "reserved" warning.
Re: [perl #2269] unpack(NaN) big baddaboom
On Tue, Jul 12, 2005 at 10:17:46PM -0500, Steve Peters wrote:
> > Anyone have a FreeBSD machine handy with a recent Perl on it to try this
> > out?
>
> Testdrive probably does.
They do but they're not accepting connections.
SourceForge's compile farm has one... FreeBSD 4.10-BETA running 5.5.3, great.
[EMAIL PROTECTED]:~$ perl
my $packed = "\0\0\xc0\x7f";
print STDERR "len: ", length($packed), " bytes: ",
\ unpack("H*", $packed), "\n";
my $float = unpack("f", $packed);
print STDERR "float done\n";
print STDERR "float: $float\n";
exit 0;
len: 4 bytes: SCALAR(0x804e054)
float done
float: NaN
--
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!
[perl #2915] my $x; our $x; does not give "masked" warning
> [EMAIL PROTECTED] - Thu Mar 30 21:52:59 2000]: > > Shouldn't > > perl5.6.0 -we 'my $x; our $x; $x=0' > > generate some sort of "redeclared" warning?The other cases > (two "my"s or two "our"s or "our" before "my") all do. This is still an issue in 5.9.x. I'd agree, there should be a warning particularly because all other combinations issue a warning: $ bleadperl -lwe 'my $x = 42; our $x = 23; print $x' 23 $ bleadperl -lwe 'my $x = 42; my $x = 23; print $x' "my" variable $x masks earlier declaration in same scope at -e line 1. 23 $ bleadperl -lwe 'our $x = 42; my $x = 23; print $x' "my" variable $x masks earlier declaration in same scope at -e line 1. 23 $ bleadperl -lwe 'our $x = 42; our $x = 23; print $x' "our" variable $x masks earlier declaration in same scope at -e line 1. 23 > And is it appropriate that > > perl5.6.0 -we 'our $x' > > generates a "used only once", but the corresponding "my" does not? This appears to have been resolved.
Re: [perl #2269] unpack(NaN) big baddaboom
On Tue, Jul 12, 2005 at 08:09:07PM -0700, Michael G Schwern via RT wrote:
> > [EMAIL PROTECTED] - Mon Mar 06 02:33:55 2000]:
> >
> > Running following program causes "Floating point exception" on
> > FreeBSD 3.2-STABLE *and* 4.0-CURRENT #0: Tue Feb 29 02:11:52 AST 2000
> > (but not on Linux "2.3.44 #12 SMP") (all 5.00503)
> >
> > ===8<==8<==8<==8<
> > #!/usr/bin/perl
> >
> > my $packed = "\0\0\xc0\x7f";
> > print STDERR "len: ", length($packed), " bytes: ", unpack("H*",
> >$packed), "\n";
> > my $float = unpack("f", $packed);
> > print STDERR "float done\n";
> > print STDERR "float: $float\n";
> >
> > exit 0;
> > ===8<==8<==8<==8<
> > hayek$ ./moo.pl
> > len: 4 bytes: c07f
> > float done
> > Floating point exception
> > hayek$ echo $?
> > 136
> > hayek$
> > ===8<==8<==8<==8<
>
> Anyone have a FreeBSD machine handy with a recent Perl on it to try this
> out?
>
Testdrive probably does.
perldoc segfaulting in XS_UNIVERSAL_VERSION
$ /usr/local/perl/bleadperl/bin/perldoc5.9.3 -m Fcntl.pm Bus error ++ungood 0 /usr/local/perl/bleadperl/bin$ gdb ./perl5.9.3 GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin". Reading symbols for shared libraries .. done (gdb) set args perldoc5.9.3 Fcntl (gdb) run Starting program: /usr/local/perl/bleadperl/bin/perl5.9.3 perldoc5.9.3 Fcntl Reading symbols for shared libraries . done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x00041548 in XS_UNIVERSAL_VERSION () (gdb) bt #0 0x00041548 in XS_UNIVERSAL_VERSION () #1 0x00057e58 in Perl_pp_entersub () #2 0x000d1e5c in Perl_runops_standard () #3 0x0001e394 in S_run_body () #4 0x0001dff4 in perl_run () #5 0x2d60 in main () #6 0x2780 in _start (argc=3, argv=0x0, envp=0xec09c) at /SourceCache/Csu/Csu-47/crt.c:267 #7 0x8fe1a278 in __dyld__dyld_start () (gdb) $ bleadperl -V Summary of my perl5 (revision 5 version 9 subversion 3 patch 25129) configuration: Platform: osname=darwin, osvers=7.9.0, archname=darwin-thread-multi-2level uname='darwin windhund.schwern.org 7.9.0 darwin kernel version 7.9.0: wed mar 30 20:11:17 pst 2005; root:xnuxnu-517.12.7.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dprefix=/usr/local/perl/bleadperl -Dccflags=-I/sw/include -Dldflags=-L/sw/lib [EMAIL PROTECTED] -Uinstallusrbinperl -Dusedevel -Duseithreads' hint=recommended, useposix=true, d_sigaction=define usethreads=define 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 ='-I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1671)', 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='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/sw/lib -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=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-L/sw/lib -bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: DEVEL24148 Built under darwin Compiled at Jul 12 2005 19:21:18 %ENV: PERL5LIB="/sw/lib/perl5:/sw/lib/perl5/darwin" @INC: /sw/lib/perl5 /sw/lib/perl5/darwin /usr/local/perl/bleadperl/lib/5.9.3/darwin-thread-multi-2level /usr/local/perl/bleadperl/lib/5.9.3 /usr/local/perl/bleadperl/lib/site_perl/5.9.3/darwin-thread-multi-2level /usr/local/perl/bleadperl/lib/site_perl/5.9.3 /usr/local/perl/bleadperl/lib/site_perl . -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
[perl #2269] unpack(NaN) big baddaboom
> [EMAIL PROTECTED] - Mon Mar 06 02:33:55 2000]:
>
> Running following program causes "Floating point exception" on
> FreeBSD 3.2-STABLE *and* 4.0-CURRENT #0: Tue Feb 29 02:11:52 AST 2000
> (but not on Linux "2.3.44 #12 SMP") (all 5.00503)
>
> ===8<==8<==8<==8<
> #!/usr/bin/perl
>
> my $packed = "\0\0\xc0\x7f";
> print STDERR "len: ", length($packed), " bytes: ", unpack("H*",
>$packed), "\n";
> my $float = unpack("f", $packed);
> print STDERR "float done\n";
> print STDERR "float: $float\n";
>
> exit 0;
> ===8<==8<==8<==8<
> hayek$ ./moo.pl
> len: 4 bytes: c07f
> float done
> Floating point exception
> hayek$ echo $?
> 136
> hayek$
> ===8<==8<==8<==8<
Anyone have a FreeBSD machine handy with a recent Perl on it to try this
out?
[perl #2106] multi-threaded perl segfaults
5.005 threads are due to be eliminated in 5.10. Closing this bug.
[perl #1760] regexp causes SIGSEGV (stack overflow?)
Still a problem in [EMAIL PROTECTED]
[perl #2032] Problem in documentation of Fcntl constants
> [EMAIL PROTECTED] - Tue Jan 25 02:26:08 2000]: > > After a discussion in the perl.misc newsgroup, everyone agreed that the > operation should be a logical OR, not an ADD. I'm submitting this as a > documentation bug, in hopes that this is the appropriate channel to get the > document changed. In conjunction with the bug in the definition of the > constants themselves (reported in my previous Email), this caused me > tremendous problems. Anyone remember what this bug was all about? I read what information is in the tracker but it rapidly devolves into an autoload discussion.
[perl #1997] DynaLoader doesn't dlclose XS code on interpreter exit
> [EMAIL PROTECTED] - Tue Jan 18 07:49:50 2000]: > > DynaLoader assumes that exiting of the perl interpreter is the same > thing as > exit of the entire application. In the case where perl is built as a > .so and > embedded inside something else (e.g. Apache/mod_perl) it is certainly > not the > same thing. > > The failure of DynaLoader to dlclose the XS modules leads to a very > insiduous > bug. The XS modules are left loaded in memory, and if the perl > libperl.so is > subsequently reloaded via dlopen, it is often loaded into a different > address. > The orphaned XS .so files are still in memory, linked to a 'ghost' of > the perl > libperl.so. This causes all sorts of insiduous memory and heap > corruption > problems. > > DynaLoader maintains a list of opened .so files in dl_librefs - on > exit it > should dlunload all the objects in this list. Looking at DynaLoader and skimming the discussion of this bug it seems like it has been applied and fixed. Could someone more familiar with DynaLoader please confirm?
[perl #1987] ISA not supported
> [EMAIL PROTECTED] - Thu Jan 13 10:55:24 2000]: > > I check it on > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-09/msg1.html > but didn't help me much, is it a bug ? And is there any work around for > this? There has been a lot of improvements done on h2ph in recent years, its probable this bug has been resolved but I cannot check without a copy of isa_defs.h. Can you provide it?
[perl #1844] FindBin fails if all directories in cwd are not readable
> [EMAIL PROTECTED] - Wed Dec 01 06:23:20 1999]: > > Possible solutions: > Fix Cwd::abs_path(), so it doesn't do that. Possibly, rather > than warning and returning, it should use fast_abs_path() instead, > which should handle warnings if they need to be given. > Alternatively, have FindBin use a fallback if abs_path() > fails. I am unable to replicate this behavior on OS X using 5.4.5 or 5.5.4. As the implementation of Cwd::abs_path() changes on different operating systems I cannot be sure this bug does not still exist. Can you tell us what operating system you were using, and version of Perl? Can you also try this out on a newer version of Perl?
[perl #1807] chomp() can be confusing
> [EMAIL PROTECTED] - Thu Nov 18 23:18:09 1999]:
>
> Is there any possibility of having chomp() be modified to recognize
\n, \r,
> and \r\n as line-endings to chomp?
Do you mean that chomp(), rather than being equivalent to:
s{$/\z}{};
should be:
s{(\r|\n|\r\n)\z}{};
?
[perl #1784] 2 problems with File::Spec::Win32
> [EMAIL PROTECTED] - Mon Nov 15 05:50:21 1999]: > > 1. rel2abs goes into an infinite loop if the $base parameter is omitted. Confirmed a bug in 5.5.4. Confirmed fixed in 5.8.6 if not earlier. > 2. canonpath does not support the optional $reduce_ricochet parameter. $reduce_ricochet has been removed from File::Spec.
[perl #1693] CPAN::shell to work in XEmacs M-x shell
"perl -MCPAN -e shell" works for me with GNU emacs 21.2.1 and XEmacs 21.4 (patch 15) on OS X using perl 5.8.6.
[perl #1662] Perl on HP-UX
> [EMAIL PROTECTED] - Tue Oct 19 00:35:42 1999]: > > Alvin White > BellSouth Telecommunications > > Lacking any information there's nothing to be done but close this bug.
[perl #1503] Re: [PATCH perl5.004_67] Add Errno in ext/
> [RT_System - Mon Sep 20 05:51:22 1999]:
>
> For some obscure reasons I did test the %! auto-require stuff yesterday
> and found that it doesn't work (in Perl 5.005_03 and 5.005_61). Well
> actually it does work at runtime, just not at compile-time, exactly as the
> comments indicate. But isn't this quite confusing:
>
> print "$_\n" foreach keys %{'!'};
>
> works (loads Errno.pm), but
>
> print "$_\n" foreach keys(%!);
>
> doesn't.
This appears to be resolved in 5.8.6 and probably earlier.
[perl #1500] Re: The extent of double-quotish interpolation
> [RT_System - Mon Sep 20 02:46:44 1999]: > > >Ah, I think I see what you mean now. You want these to behave differently: > > > > DB<1> print $count = @array = ((undef) x 3)[0,1,2] > >0 > > DB<2> print $count = @array = ()[0,1,2] > >0 > > > >You'd have the first version start returning three, but leave the second > >version alone. The potential for breakage here is certainly reduced > >compared to what I misunderstood the original request to be, since there > >are fewer cases that would change. And it's quite possible that it's > >the latter case that people rely upon more than it is the former one. > >Whether it's exclusively the latter case that matters, I wonder. But you > >can't know what color the yolk is until you break the egg. > > Omlette makers can sometimes tell without breaking anything. :-) And they do behave differently. 0 ~/tmp$ perl -le 'print $count = @array = ((undef) x 3)[0,1,2]' 3 0 ~/tmp$ perl -le 'print $count = @array = ()[0,1,2]' 0 So I guess whatever this was about its been resolved.
[perl #23098] core dump -> "perl in malloc(): error: recursive call"
> [EMAIL PROTECTED] - Wed Jul 23 08:17:50 2003]: > > > Hello! > > i want to consult with you about strange > behavior of perl v5.6.1 on FreeBSD 5.1 beta. > may be something is wrong ... with perl or with me =) > > i wrote a small mail proxy which listens connections > from local network and redirects clients to outside. > this proxy forks 2 processes: first for writing queries > from local client to outer mail server, second for > writing queries from outer mail server to local client. > i think it is ordinary. this scheme is simple and it works, > but ... but sometimes it all dumps with 'perl.core' and error > like this 'perl in malloc(): error: recursive call', but all > processes are still alive. there is no any regularity in this dumps. > i don't think that this errors are because of me. may be kernel? > or may be perl? please help me to solve this problem! > > ps. > the _same_ code in C (POSIX is POSIX =) works great, > of course with out any dumps. > > pss. > if you don't want to look into this, please tell me > where i can know more about my problem. We're happy to look into core dumps more deeply. Can you please provide some sample code to replicate the problem, or possibly, a backtrace of the coredump?
[perl #1442] Missing Label and -w
> [RT_System - Sun Sep 19 20:00:34 1999]:
>
> This is with _61 ( perl -wc doesn't report any errors )
>
> use strict;
>
> for my $i (1..5) {
> if ( $i == 2 ) { next Loop; }
> }
I presume you're reporting that "perl -cw" does not report the lack of a
loop label as an error? This is correct because a loop label could be
created at run time. Its odd but can happen.
$label = "Loop";
eval qq[$label: for(1..5) {
foo();
print "Never run"
}];
sub foo { for (1..5) { next Loop } }
One of the facts of life living with such a dynamic language.
[perl #22959] missing symbols from embed.h when testing B::Generate
> [jimc - Sun Jul 13 22:36:22 2003]: > > When doing 'make test' on B::Generate on 5.8.1-19893, > I get missing symbols, which are defined in embed.h, > and used successfully in core. For me at least, theyre > not available to this XS module (though other non-CORE > XS's build ok). > I dunno whether its a bug in CORE, in B::Generate, or > a PEBCAK error, but I thought it safest to flag it, > in case it impacts 5.8.1. > [EMAIL PROTECTED] maintperl]$ grep -r fold_constants * > embed.fnc:p |OP*|fold_constants |OP* arg > embed.h:#define fold_constants Perl_fold_constants > embed.h:#define fold_constants(a) Perl_fold_constants(aTHX_ a) > op.c:Perl_fold_constants(pTHX_ register OP *o) > op.c:return fold_constants(o); > op.c:return fold_constants((OP *) unop); > op.c:return fold_constants((OP *)binop); > op.c:o = fold_constants(o); > op.c: return fold_constants(o); > proto.h:PERL_CALLCONV OP* Perl_fold_constants(pTHX_ OP* arg); > [EMAIL PROTECTED] B-Generate-1.06-mod]$ make > /usr/local/bin/perl5.8.1 ./Build > lib/B/Generate.pm -> blib/lib/B/Generate.pm > cc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno- strict-aliasing - > \ I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -I/usr/include/ gdbm -g -O2 > \ -I/usr/local/lib/perl5/5.8.1/i686-linux-thread-multi/CORE -o > lib/B/Generate.o > \ lib/B/Generate.c > lib/B/Generate.bs -> blib/arch/auto/B/Generate/Generate.bs > cc -shared -L/usr/local/lib -o blib/arch/auto/B/Generate/Generate.so > lib/B/Generate.o > [EMAIL PROTECTED] B-Generate-1.06-mod]$ make test > /usr/local/bin/perl5.8.1 ./Build test > testCan't load 'blib/arch/auto/B/Generate/Generate.so' for module > \ B::Generate: blib/arch/auto/B/Generate/Generate.so: undefined symbol: > fold_constants at > \ /usr/local/lib/perl5/5.8.1/i686-linux-thread-multi/DynaLoader.pm line 229. at test.pl line 4 The issue here is that C is not part of the public API and is supposed to only be available only in the Perl core. A more complete look at embed.h shows #ifdef PERL_CORE #define find_script Perl_find_script #define force_list Perl_force_list #define fold_constants Perl_fold_constants #endif So, given this, I'd say this is a bug in B::Generate, rather than the Perl core.
[perl #1376] Memory leak in IO::Socket ?
> [RT_System - Sun Sep 19 18:30:17 1999]:
>
> I appear to be running into a memory leak in IO::Socket which I can't
> fix. The
> following example:
>
> #!/usr/bin/perl -w
> use strict;
> use IO::Socket;
>
> my $RemoteHost = 'localhost';
> while (1) {
>my $Socket = new IO::Socket::INET(PeerAddr => $RemoteHost,
> PeerPort => 80,
> Proto => 'tcp',
> Type => SOCK_STREAM,
> );
>$Socket->close();
>undef $Socket;
> }
>
> I can't see anything obviously wrong with this.
I cannot replicate this on OS X using 5.4.5 and 5.5.4. Are you still
having this problem in newer Perls and versions of IO?
Can we assume 5005threads are dead?
Configure sez: The 5005threads version is effectively unmaintained and will probably be removed in Perl 5.10, so there should be no need to build a Perl using it unless needed for backwards compatibility with some existing 5.005threads code. Can I assume, for the purposes of closing bugs and deleting code, that this is true and we're go for removing all the 5005threads code in 5.10? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett
Re: demacroize ckWARN*
On Sat, Jul 02, 2005 at 04:53:35PM +0100, Dave Mitchell wrote:
> On Sat, Jul 02, 2005 at 04:52:43PM +0100, [EMAIL PROTECTED] wrote:
> > If I remember right, a lot of code tests whether the warning is enabled
> > before testing whether the warning case applies, on the assumption that
> > the first check is quick. Many of those cases may want to be re-evaluated
> > in the light of this patch.
>
> I was going to save that for another day :-)
That day has now arrived:
--
There's a traditional definition of a shyster: a lawyer who, when the law
is against him, pounds on the facts; when the facts are against him,
pounds on the law; and when both the facts and the law are against him,
pounds on the table.
-- Eben Moglen referring to SCO
Change 25129 by [EMAIL PROTECTED] on 2005/07/13 00:21:13
make the expensive ckWARN() be called as late as possible
reorganise
if (ckWARN(FOO) && should_not_happen_condition)
to
if (should_not_happen_condition && ckWARN(FOO))
Affected files ...
... //depot/perl/doio.c#274 edit
... //depot/perl/gv.c#258 edit
... //depot/perl/op.c#696 edit
... //depot/perl/pad.c#64 edit
... //depot/perl/perlio.c#279 edit
... //depot/perl/pp.c#473 edit
... //depot/perl/pp_hot.c#410 edit
... //depot/perl/pp_pack.c#104 edit
... //depot/perl/pp_sys.c#431 edit
... //depot/perl/regcomp.c#380 edit
... //depot/perl/regexec.c#357 edit
... //depot/perl/sv.c#955 edit
... //depot/perl/toke.c#580 edit
Differences ...
//depot/perl/doio.c#274 (text)
@@ -566,7 +566,9 @@
}
}
if (!fp) {
- if (ckWARN(WARN_NEWLINE) && IoTYPE(io) == IoTYPE_RDONLY && strchr(name,
'\n'))
+ if (IoTYPE(io) == IoTYPE_RDONLY && strchr(name, '\n')
+ && ckWARN(WARN_NEWLINE)
+ )
Perl_warner(aTHX_ packWARN(WARN_NEWLINE), PL_warn_nl, "open");
goto say_false;
}
@@ -1079,7 +1081,7 @@
if (!io)
return TRUE;
-else if (ckWARN(WARN_IO) && (IoTYPE(io) == IoTYPE_WRONLY))
+else if ((IoTYPE(io) == IoTYPE_WRONLY) && ckWARN(WARN_IO))
report_evil_fh(gv, io, OP_phoney_OUTPUT_ONLY);
while (IoIFP(io)) {
@@ -1392,7 +1394,7 @@
s = SvPVX_const(PL_statname); /* s now NUL-terminated */
PL_laststype = OP_STAT;
PL_laststatval = PerlLIO_stat(s, &PL_statcache);
- if (PL_laststatval < 0 && ckWARN(WARN_NEWLINE) && strchr(s, '\n'))
+ if (PL_laststatval < 0 && strchr(s, '\n') && ckWARN(WARN_NEWLINE))
Perl_warner(aTHX_ packWARN(WARN_NEWLINE), PL_warn_nl, "stat");
return PL_laststatval;
}
@@ -1418,8 +1420,8 @@
return (PL_laststatval = -1);
}
}
-else if (ckWARN(WARN_IO) && PL_laststype != OP_LSTAT
- && (PL_op->op_private & OPpFT_STACKED))
+else if (PL_laststype != OP_LSTAT
+ && (PL_op->op_private & OPpFT_STACKED) && ckWARN(WARN_IO))
Perl_croak(aTHX_ no_prev_lstat);
PL_laststype = OP_LSTAT;
//depot/perl/gv.c#258 (text)
@@ -547,8 +547,9 @@
/*
* Inheriting AUTOLOAD for non-methods works ... for now.
*/
-if (ckWARN2(WARN_DEPRECATED, WARN_SYNTAX) && !method &&
- (GvCVGEN(gv) || GvSTASH(gv) != stash))
+if (!method && (GvCVGEN(gv) || GvSTASH(gv) != stash)
+ && ckWARN2(WARN_DEPRECATED, WARN_SYNTAX)
+)
Perl_warner(aTHX_ packWARN2(WARN_DEPRECATED, WARN_SYNTAX),
"Use of inherited AUTOLOAD for non-method %s::%.*s() is deprecated",
packname, (int)len, name);
//depot/perl/op.c#696 (text)
@@ -1767,11 +1767,12 @@
OP *o;
bool ismatchop = 0;
-if (ckWARN(WARN_MISC) &&
- (left->op_type == OP_RV2AV ||
+if ( (left->op_type == OP_RV2AV ||
left->op_type == OP_RV2HV ||
left->op_type == OP_PADAV ||
- left->op_type == OP_PADHV)) {
+ left->op_type == OP_PADHV)
+ && ckWARN(WARN_MISC))
+{
const char *desc = PL_op_desc[(right->op_type == OP_SUBST ||
right->op_type == OP_TRANS)
? right->op_type : OP_MATCH];
@@ -1960,8 +1961,8 @@
;
#endif
else {
- if (ckWARN(WARN_PARENTHESIS)
- && PL_bufptr > PL_oldbufptr && PL_bufptr[-1] == ',')
+ if ( PL_bufptr > PL_oldbufptr && PL_bufptr[-1] == ','
+ && ckWARN(WARN_PARENTHESIS))
{
char *s = PL_bufptr;
bool sigil = FALSE;
@@ -3528,7 +3529,7 @@
if (first->op_type == OP_CONST) {
if (first->op_private & OPpCONST_STRICT)
no_bareword_allowed(first);
- else if (ckWARN(WARN_BAREWORD) && (first->op_private & OPpCONST_BARE))
+ else if ((first->op_private & OPpCONST_BARE) && ckWARN(WARN_BAREWORD))
Perl_warner(aTHX_ packWARN(WARN_BAREWORD), "Bareword found in
conditional");
if ((type == OP_AND && SvTRUE(((SVOP*)first)->op_sv)) ||
(type == OP_OR && !SvTRUE(((SVOP*)first)->op_sv)) ||
@@ -3564,8 +3565,8 @
Smoke [5.9.3] 25128 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
Automated smoke report for 5.9.3 patch 25128 TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu) onMSWin32 - WinXP/.Net SP1 using cl version 12.00.8804 smoketime 2 hours 16 minutes (average 4 minutes 15.188 seconds) Summary: FAIL(M) 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 25128 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - M M M M -Dusemymalloc M M -Duselargefiles M M -Duselargefiles -Dusemymalloc M M -Duseithreads -Uuseimpsys M M -Duseithreads -Uuseimpsys -Dusemymalloc M M -Duseithreads -Uuseimpsys -Duselargefiles M M -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' M M -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [minitest] [minitest] -DDEBUGGING [minitest] -Dusemymalloc [minitest] -DDEBUGGING -Dusemymalloc [minitest] -Duselargefiles [minitest] -DDEBUGGING -Duselargefiles [minitest] -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/utftaint...dubious [minitest] -Duseithreads -Uuseimpsys [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys [minitest] -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious 13/111 unexpectedly succeeded op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/threadsdubious DIED. FAILED tests 1-3 op/utftaint...dubious -- Report by Test::Smoke v1.19_70 build 861 running on perl 5.8.7 (Reporter v0.021 / Smoker v0.024) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the
[perl #36428] Problem with the debugger with conjunction to Encoding
> [EMAIL PROTECTED] - Wed Jun 29 15:20:13 2005]:
>
> - the script starts here --
> use Encode qw/encode decode/;
>
> my $var = "+AQUBBQEF-/b+AXwBfAF8-";
> my $decoded = decode ("UTF-7", $var);
> my $encoded = encode ("UTF-7", $decoded);
> print $encoded;
> - the script ends here -
>
> when the script is run without the debugger (without perl -d),
> the output is - as expected - exactly the value of $var. However,
> trying to run the same program with -d makes Perl prematurely exit
> from the debugger or crash. Thorough debugging shows, that the problem
> occurs in line 36 of UTF7.pm (this file is part of the Perl
> distribution)
Confirmed. On OSX 5.8.6 I get:
main::(-:3):my $var = "+AQUBBQEF-/b+AXwBfAF8-";
DB<1> c
*** malloc_zone_malloc[1462]: argument too large: 4281226766
Out of memory!
And with [EMAIL PROTECTED] it simply hangs but does not consume additional
memory.
[perl #36206] t/op/pack leaking warnings in debugging bleadperl
> [nicholas - Tue Jun 07 14:40:34 2005]: > > Thanks for the report. Rafael also spotted this about 8 hours ago. It's > my fault (change 24714) and should be fixed by 24732. Was it?
[perl #23651] Debugger dump failed for blessed REF object
Joe's patch appears to have gone in.
$ bleadperl -de 1
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 1
DB<1> x bless {}, "Foo"
0 Foo=HASH(0x810850)
empty hash
DB<2> x bless \{}, "Foo"
0 Foo=REF(0x8a8ce0)
-> HASH(0x8a8cf0)
empty hash
[perl #22758] debugger command "|x" swallows all output
> [EMAIL PROTECTED] - Sun Jun 22 23:53:28 2003]: > > - > The debugger command "x" works as expected, but "|x" shows no output > at all: I am unable to reproduce this problem. What pager does the debugger think you're using? You can find out with this: $ perl -de 1 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 1 DB<1> print DB::pager |/usr/bin/less
[perl #17765] UTF-8 in the debugger
> [joemcmahon - Fri Jun 03 15:00:45 2005]:
>
> > Same program in the debugger:
> > % perl -de '
> > $_ = "\x{100}";
> > s/[\x{100}]/o/;
> > print "$_\n";
> > '
> >
> > Loading DB routines from perl5db.pl version 1.19
> > Editor support available.
> >
> > Enter h or `h h' for help, or `man perldebug' for more help.
> >
> > main::(-e:2): $_ = "\x{100}";
> > DB<1> c
> > Wide character in print at -e line 4.
> > ?
>
> This seems to fix the problem; it just adds ":utf8" to the debugger's
> output filehandle.
The problem is not the "wide character in print" warning. The problem
is that $_ is not 'o' as it is when run outside the debugger.
[perl #8276] cannot interrupt accept call in debugger
This appears to have been fixed in the 5.8 track. With 5.8.6 I can ctrl-c at the accept() call and I am dumped into the debugger at the proper place. With 5.5.4 it didn't respond to ctrl-c at all, I wasn't dumped into the debugger nor did the process exit. So I'm reasonably sure this is resolved. Please let us know if it is not.
[perl #8622] hash trouble in the perl debugger
Still an issue in 5.8.6 and [EMAIL PROTECTED]
[perl #9472] Rebless, overloads and the debugger
This appears to have been fixed in the latest development version of perl.
Re: [perl #36507] File::Copy::copy($foo, $foo) dies
On Tue, Jul 12, 2005 at 06:19:48PM -0400, Randy W. Sims wrote:
> Michael G Schwern via RT wrote:
> >The attached patch changes copy() so that it carps instead of croaking
> >when its asked to copy identical files. This is better because asking
> >to copy identical files is not an error (and the operation suceeds) its
> >just dubious.
>
> Shouldn't it be fatal if the destination is a link? If the user expects
> to copy over a link in order to edit the copy, it would issue a warning
> and merrily trash the original file.
That was the original behavior before the link check and croak was put in.
The link check still remains. copy() simply warns and returns true rather
than trash the original file.
An alternative behavior is for copy() to unlink the destination if it is a
link and then copy() the source. This runs counter to what cp does and the
behavior of copy() generally honoring links.
Finally, copy could warn and return false in the view that if failed to
make a real copy of the file. It certainly shouldn't die, leave the error
handling to the caller.
I'm liking the final choice. Here's another patch.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml
--- lib/File/Copy.pm2005/07/12 21:28:49 1.1
+++ lib/File/Copy.pm2005/07/12 22:50:36
@@ -37,6 +37,11 @@
goto &Carp::croak;
}
+sub carp {
+require Carp;
+goto &Carp::carp;
+}
+
my $macfiles;
if ($^O eq 'MacOS') {
$macfiles = eval { require Mac::MoreFiles };
@@ -78,7 +83,10 @@
: (ref(\$to) eq 'GLOB'));
if ($from eq $to) { # works for references, too
- croak("'$from' and '$to' are identical (not copied)");
+ carp("'$from' and '$to' are identical (not copied)");
+# The "copy" was a success as the source and destination contain
+# the same data.
+return 1;
}
if ((($Config{d_symlink} && $Config{d_readlink}) || $Config{d_link}) &&
@@ -87,7 +95,8 @@
if (@fs) {
my @ts = stat($to);
if (@ts && $fs[0] == $ts[0] && $fs[1] == $ts[1]) {
- croak("'$from' and '$to' are identical (not copied)");
+ carp("'$from' and '$to' are identical (not copied)");
+return 0;
}
}
}
@@ -182,7 +191,10 @@
}
sub move {
+croak("Usage: move(FROM, TO) ") unless @_ == 2;
+
my($from,$to) = @_;
+
my($fromsz,$tosz1,$tomt1,$tosz2,$tomt2,$sts,$ossts);
if (-d $to && ! -d $from) {
@@ -209,6 +221,7 @@
{
local $@;
eval {
+local $SIG{__DIE__};
copy($from,$to) or die;
my($atime, $mtime) = (stat($from))[8,9];
utime($atime, $mtime, $to);
--- lib/File/Copy.t 2005/07/12 21:30:56 1.1
+++ lib/File/Copy.t 2005/07/12 22:50:43
@@ -9,7 +9,7 @@
my $TB = Test::More->builder;
-plan tests => 48;
+plan tests => 60;
# We're going to override rename() later on but Perl has to see an override
# at compile time to honor it.
@@ -19,6 +19,16 @@
use File::Copy;
use Config;
+
+foreach my $code ("copy()", "copy('arg')", "copy('arg', 'arg', 'arg', 'arg')",
+ "move()", "move('arg')", "move('arg', 'arg', 'arg')"
+ )
+{
+eval $code;
+like $@, qr/^Usage: /;
+}
+
+
for my $cross_partition_test (0..1) {
{
# Simulate a cross-partition copy/move by forcing rename to
@@ -92,7 +102,7 @@
# The destination file will reflect the same difficulties.
my $mtime = (stat("copy-$$"))[9];
- ok move "copy-$$", "file-$$", 'move';
+ ok move("copy-$$", "file-$$"), 'move';
ok -e "file-$$", ' destination exists';
ok !-e "copy-$$", ' source does not';
open(R, "file-$$") or die; $foo = ; close(R);
@@ -114,9 +124,14 @@
is $foo, "ok\n";
unlink "lib/file-$$" or die "unlink: $!";
- eval { copy("file-$$", "file-$$") };
- like $@, qr/are identical/;
- ok -s "file-$$";
+ {
+my $warnings = '';
+local $SIG{__WARN__} = sub { $warnings .= join '', @_ };
+ok copy("file-$$", "file-$$");
+
+like $warnings, qr/are identical/;
+ok -s "file-$$";
+ }
move "file-$$", "lib";
open(R, "lib/file-$$") or die "open lib/file-$$: $!"; $foo = ; close(R);
@@ -131,8 +146,12 @@
print F "dummy content\n";
close F;
symlink("file-$$", "symlink-$$") or die $!;
-eval { copy("file-$$", "symlink-$$") };
-like $@, qr/are identical/;
+
+my $warnings = '';
+local $SIG{__WARN__} = sub { $warnings .= join '', @_ };
+ok !copy("file-$$", "symlink-$$");
+
+like $warnings, qr/are identical/;
ok !-z "file-$$",
'rt.perl.org 5196: copying to itself would truncate the file';
@@ -147,8 +166,12 @@
print F "dummy content\n";
close F;
link("file-$$", "hardlink-$$") or die $!;
-eval { copy("file-$$", "hardlink-$$") };
-like $@, qr/are identical/
[perl #6749] Perl debugger outputs ctrl-\ wrongly
> [EMAIL PROTECTED] - Thu Apr 05 19:58:47 2001]: > The Perl debugger outputs strings containing the character > ctrl-\ wrongly when using the "x" command. For example, > x chr(28) results in "\c\" and x "\c\\" results in "\c\\\". > The results, however, are not valid Perl and will result in > "string terminator not found before end of line". The problem is in dumpvar.pl which x uses. The attached patch fixes this. dv.patch Description: Binary data
Re: [perl #20353] Perl 5.8.0 fails "make test" on Cobalt Raq4 in Math::BigInt
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Tuesday 12 July 2005 23:46, Steve Peters via RT wrote:
> > [EMAIL PROTECTED] - Thu Jan 16 06:33:13 2003]:
> >
> > The standard melody for building Perl 5.8.0 fails at "make test" on
> > Cobalt Raq4:
> >
> > My input:
> >
> > rm -f config.sh Policy.sh
> > sh Configure -de
> > make
> > make test
> >
> > It fails here:
> >
> > lib/Math/BigInt/t/bare_mbf...ok
> > lib/Math/BigInt/t/bare_mbi...ok
> > lib/Math/BigInt/t/bare_mif...FAILED at test 511
> > lib/Math/BigInt/t/bigfltpm...make[2]: *** [_test_tty] Error
> > 139
[snipabit]
> > ("make test" for Perl 5.6.1, built in the same way, on the same
> > machine, reports no problems.)
> >
> > Greetings, Norbert.
>
> Tels,
>
> Does this problem look familiar to you?
No, that is a new one.
Perl 5.6.1 does have an ancient BigInt version, so you can't compare
testfailures to v5.8.0 in a meaningfull way.
Norbert, do the tests pass for Perl 5.8.6 (the latest stable version,
including the latest BigInt)? And if they fail, too, what does BigInt
testsuite alone (from search.cpan.org) say?
Best wishes,
Tels
- --
Signed on Wed Jul 13 00:23:31 2005 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Duke Nukem Forever is a 1999 game and we think that timeframe matches
very well with what we have planned for the game." - George Broussard,
1998 (http://tinyurl.com/6m8nh)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQtRDr3cLPEOTuEwVAQFONgf9HNRFyzUros/0aOVHx/z8xNEhs5DCH5hV
dcy8xk7fymQbPjBUH3uqiO6Ai/D8xWkXiAyC7SaI5j9Qppyvx7XqXZBpza96jq26
8f1u99DFnFFG/MPdGAcbzNQI1I5GbVMZSp5vEEjdQ3kyHOhp2pmdQfTxfUBXii2/
gi3oKhfepXFxWtYDluz9lclE3hYtrfAre4zXoQCkA+LU8hAQLSATtNjHkYwJNCji
IvcYo81Ypwc5b+fOJhC3Dwq2g3pIEnNyMB3+hKQ+5+q3nLIj/Mh+ZAQ1NQlTt1r6
JhrdUt6qcqc5J4dJmDepp6giPM1fHX3GPDT/vIbpIYvWHMz6uUlw/Q==
=kckU
-END PGP SIGNATURE-
Re: [perl #36507] File::Copy::copy($foo, $foo) dies
Michael G Schwern via RT wrote: The attached patch changes copy() so that it carps instead of croaking when its asked to copy identical files. This is better because asking to copy identical files is not an error (and the operation suceeds) its just dubious. Shouldn't it be fatal if the destination is a link? If the user expects to copy over a link in order to edit the copy, it would issue a warning and merrily trash the original file. Randy.
[perl #21999] Unsuccessful regex still alters $1
> [EMAIL PROTECTED] - Sat Apr 19 08:32:56 2003]:
>
> I was raised on the belief that "an unsuccessful regex match leaves $1
> and
> friends at their previous values." So I was surprised to discover an
> exception to that rule. It's been around for a long time, so perhaps
> I'm
> missing something. OTOH, if this is not expected behavior, perhaps
> there's
> a bug.
>
> % cat foo
> #!/usr/bin/perl
> for (qw(843 foo 23skidoo bar 345)) {
>print /^(\d+)$/ ? "$_ matched" : "$_ didn't match";
>print "; \$1 = $1\n";
> }
>
> % ./foo
> 843 matched; $1 = 843
> foo didn't match; $1 = 843
> 23skidoo didn't match; $1 = 8
> bar didn't match; $1 = 8
> 345 matched; $1 = 345
>
> In the case of the unsuccessful match against 23skidoo, $1 is
> truncated to
> the first character of its previous value. This is in 5.6.1, 5.8.0,
> and 5.9.0.
>
> Just as a historical point of reference: In 5.004_04, $1 is set to the
> first character of 23skidoo, and is undef on an unsuccessful match:
>
> 843 matched; $1 = 843
> foo didn't match; $1 =
> 23skidoo didn't match; $1 = 2
> bar didn't match; $1 =
> 345 matched; $1 = 345
>
>
>From perlre.pod
"...failed matches in Perl do not reset the match variables."
so the above is a bug. My guess, and this is just a guess, is that on
the failed match, SvCUR_set() is getting called somewhere. Looking at
the results with Devel::Peek...
843 matched; $1 = 843
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 "843"\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 "1"
foo didn't match; $1 = 843
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 "843"\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 "1"
23skidoo didn't match; $1 = 8
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 "8"\0
CUR = 1
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 "1"
bar didn't match; $1 = 8
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 "8"\0
CUR = 1
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 "1"
345 matched; $1 = 345
SV = PVMG(0x801ae3c0) at 0x8812a6f4
REFCNT = 1
FLAGS = (GMG,SMG,READONLY,pPOK)
IV = 0
NV = 0
PV = 0x85bf0300 "345"\0
CUR = 3
LEN = 4
MAGIC = 0x7df8efa0
MG_VIRTUAL = &PL_vtbl_sv
MG_TYPE = PERL_MAGIC_sv(\0)
MG_OBJ = 0x8812a6e0
MG_LEN = 1
MG_PTR = 0x7c1a19c0 "1"
Re: [PATCH] perlfunc.pod
Michael G Schwern wrote: On Tue, Jul 12, 2005 at 08:55:33AM +0100, Steve Hay wrote: Didn't we conclude it would be better to give Pod::Html the same foo() recognition magic that Pod::Man has and not have to put C<> around every function? Patches welcome! Patch Pod::Html? Sorry, I have to.. umm.. I have to rearrange my sock drawer. On Pluto. Whoof, you ain't jokin', Son. I looked in there briefly, awhile back, while looking over the Pod::Pdf and pod2html/Pod::Html docs to see if I could re-do a better version of pod2pdf but gave it up. THEN I looked closer at Pod::Html =8-o with CGI.pm being part of the perl core, it would seem to me to make far more sense to take advantage of its ability (with the function-oriented interface) to generate clean html on the fly, as part of the refactoring. I mean, it WOULD be really swell to have clean & compliant 'html 4.01 Strict' (+ inline/external CSS2) doc generation... :) um.. yeah.. I'll be .. right back.. sometime. :)
[perl #3177] perl -d treats $array[0..3] differently than non-debugger
The debugger no longer sets $. $ perl -de 0 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB<1> print $. DB<2> The code works the same in the debugger as it does on the command line: $ perl -de 0 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB<1> @a = qw(A B C); DB<2> x $a[0..3], $a[1..3] 0 'B' 1 'A' DB<3> $ perl -wle '@a = qw(A B C); print $a[0..3], $a[1..3]' Use of uninitialized value in range (or flip) at -e line 1. Use of uninitialized value in range (or flop) at -e line 1. Use of uninitialized value in range (or flip) at -e line 1. Argument "" isn't numeric in array element at -e line 1. BA
[perl #2145] Debugger terminal handling
> [EMAIL PROTECTED] - Sun Feb 13 23:29:43 2000]: > When going "out of range" at the prompt in the debugger - i.e. > pressing > ctrl-n when there is no next line, or backspace when I'm at the start > of the > line, it crashes. I am unable to reproduce this but using 5.5.4 and Term::ReadLine::Gnu 1.08. Are you still experiencing the problem with newer perls and Term::ReadLine::Gnus?
[perl #1726] Debugger: Break gets set on wrong subroutine
This problem still exists in 5.8.6 and [EMAIL PROTECTED]
[perl #1542] debugger space leak using conditional breakpoints
This bug appears to have been resolved somewhere before 5.8.6. The construct no longer consumes additional memory.
[perl #20353] Perl 5.8.0 fails "make test" on Cobalt Raq4 in Math::BigInt
> [EMAIL PROTECTED] - Thu Jan 16 06:33:13 2003]:
>
> The standard melody for building Perl 5.8.0 fails at "make test" on
> Cobalt Raq4:
>
> My input:
>
> rm -f config.sh Policy.sh
> sh Configure -de
> make
> make test
>
> It fails here:
>
> lib/Math/BigInt/t/bare_mbf...ok
> lib/Math/BigInt/t/bare_mbi...ok
> lib/Math/BigInt/t/bare_mif...FAILED at test 511
> lib/Math/BigInt/t/bigfltpm...make[2]: *** [_test_tty] Error
> 139
> make[2]: Leaving directory `/home/software/perl-5.8.0'
> make[1]: *** [_test] Error 2
> make[1]: Leaving directory `/home/software/perl-5.8.0'
> make: *** [test] Error 2
>
> repeating "make test" gives the same result.
>
>
> [EMAIL PROTECTED]:perl-5.8.0 > ./myconfig
> Summary of my perl5 (revision 5.0 version 8 subversion 0)
> configuration:
> Platform:
> osname=linux, osvers=2.2.14c11, archname=i586-linux
> uname='linux tasc.surrogacy.org 2.2.14c11 #2 wed jun 28 00:55:51
> pdt 2000 i586 unknown '
> 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 ='-fno-strict-aliasing -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
> optimize='-O3',
> cppflags='-fno-strict-aliasing -I/usr/local/include
> -I/usr/include/gdbm'
> ccversion='', gccversion='2.95.2 19991024 (release)',
> 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 =' -L/usr/local/lib'
> libpth=/usr/local/lib /lib /usr/lib
> libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil
> perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil
> libc=/lib/libc-2.1.3.so, so=so, useshrplib=false,
> libperl=libperl.a
> gnulibc_version='2.1.3'
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-
> rdynamic'
> cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
>
> ("make test" for Perl 5.6.1, built in the same way, on the same
> machine, reports no problems.)
>
> Greetings, Norbert.
>
>
Tels,
Does this problem look familiar to you?
[perl #36507] File::Copy::copy($foo, $foo) dies
The attached patch changes copy() so that it carps instead of croaking
when its asked to copy identical files. This is better because asking
to copy identical files is not an error (and the operation suceeds) its
just dubious.
I also added a check in move() to ensure it gets the right number of
arguments to match copy(). This revealed a mistake in the tests of
move() getting too many args.
Also the cross-partition fallback-to-copy code in move() is made safer
by guarding against a $SIG{__DIE__}.
FC.patch
Description: Binary data
[perl #15995] regexp test failures on win32 with VC++ 5.0
> [wjones - Thu Jun 19 10:30:36 2003]: > > This patch works for me. > > Index: regcomp.c > === > RCS file: /usr0/sweng/src/active/CVS.repo/perl/regcomp.c,v > retrieving revision 1.1.1.4 > retrieving revision 1.4 > diff -u -r1.1.1.4 -r1.4 > --- regcomp.c 29 Jul 2002 16:20:00 - 1.1.1.4 > +++ regcomp.c 19 Jun 2003 17:10:39 - 1.4 > @@ -19,6 +19,17 @@ > * with the POSIX routines of the same names. > */ > > +/* > + * Turn off all optimization with MS Visual C under Windows. > + * Optimization makes tests 495 and 496 fail in op/regexp.t. > + * This is a fix for Perl bug #15995 (really a bug in MSC). > + * _MSC_VER == 1100 indicates MS Visual C 5.0. Other versions > + * of the compiler may or may not have the same bug. > +*/ > +#if defined(WIN32) && defined(_MSC_VER) && _MSC_VER == 1100 > +#pragma optimize( "", off ) > +#endif > + > #ifdef PERL_EXT_RE_BUILD > /* need to replace pregcomp et al, so enable that */ > # ifndef PERL_IN_XSUB_RE > Can anyone confirm whether these failures still occur on Windows with VC++ 5.0 and if this patch fixes the problem?
[perl #3149] 5.6 File::Glob documentation insufficient for use
Some documentation of the meta characters has been added to File::Glob but not much else. Just how much documentation of globbing do we want to put in the docs and how much can be "go read X"? Maybe a reference to a Unix tutorial on how globbing works?
[perl #27052] File::Spec->canonpath("a\\..\\..\\b") returns wrong value for Win 32
Ok, enough dithering. Let's kill this bug. File::Spec::Win32->canonpath() currently contains code to collapse .. so whether or not it should continue to do so in the future is outside the scope of this bug. That code is also busted and is the source of this bug. Attached is a patch to fix this bug. It replaces the collapsing code in canonpath() with a more reliable method. It also moves the code into its own method to simplify canonpath(). _collapse() goes into File::Spec::Unix because it is not platform specific. Tests have been added for this bug in both Win32 and Unix. fs.patch Description: Binary data
Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
On Tue, Jul 12, 2005 at 05:25:07PM +0100, Steve Hay wrote:
> Why doesn't this work out for you?
Because it should never do that search. In your example you got lucky
because the relative Perl you ran CPAN.pm with happened to match the one in
$Config{binexp}. What if that's not true? Consider the following.
$ cd ~/tmp/
$ which perl
/sw/bin/perl
$ perl -v
This is perl, v5.8.6 built for darwin-thread-multi-2level
$ ln -s /usr/bin/perl5.8.1 perl
$ ./perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)
$ ./perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.76)
ReadLine support enabled
cpan> test Text::Metaphone
CPAN: Storable loaded ok
Going to read /Users/schwern/.cpan/Metadata
Database was generated on Mon, 11 Jul 2005 22:03:40 GMT
Running test for module Text::Metaphone
Running make for M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
...etc...
CPAN.pm: Going to build M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Text::Metaphone
cp Metaphone.pm blib/lib/Text/Metaphone.pm
gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -pipe -Os -DVERSION=\"1.96\" -DXS_VERSION=\"1.96\"
"-I/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE" my_memory.c
^
Ding ding ding ding ding! I ran CPAN.pm with 5.8.1 but its building with
5.8.6. Because it chdir'd to the build directory before trying to resolve
my relative $^X it could not find it. So in desperation it started looking
through my PATH and found /sw/bin/perl.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
Re: [perl #28385] minor bug in cpan -- the i command does not find author
On Tue, Jul 12, 2005 at 07:14:06AM -0400, Tolkin, Steve wrote: > Thank you for providing the patch. > Is there any easy way to learn when it has been added to a distribution? Somebody will come along and say "thanks, applied" which means its in the development version and will be in the next 5.9.x release. As for stable you'll just have to watch the Changes log of the next 5.8.x release. And hopefully this will make it into the CPAN version of CPAN.pm. -- 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!
[PATCH] Re: Documentation error in IO::Socket
On Tue, Jul 12, 2005 at 12:11:33PM +0100, Andrew Benham wrote:
> Perl 5.8.6
>
> File /usr/lib/perl5/5.8.6/i386-linux-thread-multi/IO/Socket.pm on
> Fedora Core 4.
>
> Line 407 (which is part of the POD) states:
>
> $sock->read(1024,$data) until $sock->atmark;
>
> I don't believe the arguments to the read() method are in the
> correct order.
You're right, they're not.
--- lib/IO/Socket.pm2005/07/12 20:18:07 1.1
+++ lib/IO/Socket.pm2005/07/12 20:18:12
@@ -404,7 +404,7 @@
use IO::Socket;
my $sock = IO::Socket::INET->new('some_server');
-$sock->read(1024,$data) until $sock->atmark;
+$sock->read($data, 1024) until $sock->atmark;
Note: this is a reasonably new addition to the family of socket
functions, so all systems may not support this yet. If it is
--
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: PERL_DONT_CREATE_GVSV needs to be #define'd somewhere else
On Tue, Jul 12, 2005 at 02:01:51PM +0100, Steve Hay wrote: > My big worry, though, is that miniperl is compiled with different > options than perl, e.g. here's the command-lines used to compile av.c in > miniperl and perl respectively: > > cl -c -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 > -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi > -DNDEBUG -O1 -DPERL_EXTERNAL_GLOB -Fo.\mini\av.obj ..\av.c > > cl -c -I.. -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 > -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi > -DNDEBUG -O1 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO > -DPERL_MSVCRT_READFIX -Fo..\av.obj ..\av.c > > The differences arise because win32/Makefile uses > > $(CC) -c $(CFLAGS) -DPERL_EXTERNAL_GLOB ... > > to compile miniperl, but > > $(CC) -c -I$( > to compile perl, so miniperl doesn't get the BUILDOPT extras. I'm not > sure why this is, but it leads to the above miniperl -V output missing, > for example, PERL_IMPLICIT_SYS which would have a big impact on > makedef.pl's actions! > > Is miniperl built with different options to perl on other systems? On "Unix" (well, everything built by Configure and the Makefile generated by Makefile.SH which includes such non Unix(R) systems as Linux, OS/2 and VOS) all the object files are used for both miniperl and perl, except for 1: perlmain.o rather than miniperlmain.o (perlmain.c is generated from miniperlmain.c) 2: op.o (op.c is copied to opmini.c and opmini.o is built with -DPERL_EXTERNAL_GLOB in addition to the regular C flags) So this sounds quite unlike the way Windows work. Is Windows building a single threaded non-shared lib miniperl, then using that to bootstrap a (usually) multithreaded (usually) shared library perl. I *think* that this can still all work, provided that the "interesting" defines are either in the C flags that Config.pm knows about, or were already defined at the time of miniperl. It makes a lot of sense to modify the output of -V to include all the #defines that affect things like symbol export. Once -DPERL_DONT_CREATE_GVSV is an option on maint, I'd like to know from -V if someone built with it, as it might be the cause of "bugs". Nicholas Clark
Re: [perl #24119] CPAN.pm error in Win32: uses rename() not File::Copy::move
Michael G Schwern via RT wrote: >The attached patch changes all the unsafe uses of rename() to >File::Copy::move(). These are the ones which move a path to a different >directory. All the rest work within the same dir and should be safe. > Thanks. Applied as change 25125. 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: [perl #17487] ncftp only handles http
Michael G Schwern via RT wrote: >>[EMAIL PROTECTED] - Tue Sep 07 06:28:44 2004]: >>I disagree with the final thought there. My machine did have a copy >>of wget on it so that wasn't the problem in my case (though it would be >>for a stock install of the current version of Mac OS X). Since it does >>present a problem for certain configurations, I would recommend requiring >>at least one FTP site be chosen. At very least, it could have given a >>warning. >> >> > >Requiring an FTP site is a coarse solution likely to just lead to a new >set of complaints that CPAN.pm requires an FTP mirror. No, that's not >the way. > >You mention that you have wget. CPAN.pm triest wget last after trying >ncftp*. As its the most capable of all the options available it should >be tried first. Then lynx. Then finally ncftp*. A patch for this is >attached. > Thanks. Applied as change 25124. 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: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
Michael G Schwern via RT wrote:
>>[schwern - Tue Jul 15 18:31:18 2003]:
>>The attached patch fixes this bug by the simple method of storing the
>>Perl we started
>>with as an absolute path before anything is done. Then perl() can
>>reference this
>>information. I can't see how this could go wrong on MacOS.
>>
>>I've also taken the liberty of speeding up perl() by caching its
>>result.
>>
>>
>
>This patch was never applied.
>
>I've attached a better patch which simply moves the find perl logic from
>individual CPAN::Distribution objects to be a function of the CPAN. The
>location of Perl is simply cached in a global.
>
The (new) patch looks fine to me (not that I'm any CPAN.pm expert), but
before I apply it I'm just curious to understand why the existing code
doesn't work.
On my Win32 system, if I set the PATH to be just
"C:\WINDOWS;C:\WINDOWS\system32" and cd to C:\perl then the command
bin\perl -MCPAN -e shell
followed by, say, "make Sort::Versions" works fine. (My perl binary is
installed as C:\perl\bin\perl.exe)
CPAN::Distribution::make does indeed chdir to the build directory before
calling CPAN::Distribution::perl, but that succeeds in finding perl
(C:\perl\bin\perl.exe) even though there is no bin\perl in the build
directory.
It continues to work even after I insert
$^X = 'bin\\perl'
at the start of CPAN::Distribution::perl to simulate an OS that doesn't
set $^X to an absolute path.
It works because the
DIST_PERLNAME: foreach $perl_name ($^X, 'perl', 'perl5', "perl$]") {
PATH_COMPONENT: foreach $component (File::Spec->path(),
$Config::Config{'binexp'}) {
loops succeed when $perl_name is 'perl' and $component is
$Config::Config{'binexp'} (in my case, 'C:\perl\bin').
Why doesn't this work out for you?
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.
[perl #36517] Re: File::Spec and leading/trailing space
# New Ticket Created by Ken Williams
# Please include the string: [perl #36517]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36517 >
On Jul 12, 2005, at 1:40 AM, Michael G Schwern wrote:
> rt.perl.org 24691 is about CPAN.pm saying that a path with a leading
> space
> is not absolute. The issue is File::Spec... maybe.
> file_name_is_absolute() i
> does not recognize " /foo" as being absolute.
>
> $ perl -wle 'use File::Spec; print
> File::Spec->file_name_is_absolute(" /foo")'
>
> $ perl -wle 'use File::Spec; print
> File::Spec->file_name_is_absolute("/foo")'
> 1
>
> canonpath() does not clean up leading or trailing space.
>
> $ perl -wle 'use File::Spec; print File::Spec->canonpath("/foo")'
> /foo
>
> $ perl -wle 'use File::Spec; print File::Spec->canonpath(" /foo")'
> /foo
> $ perl -wle 'use File::Spec; print q["].File::Spec->canonpath(" /foo
> ").q["]'
> " /foo "
>
> Should it? Does leading and trailing space have any meaning in a Unix
> path?
The current behavior is correct. The space is just like any other
filename. " /foo" is a file (or possibly a directory) called "foo" in
a directory called " ".
-Ken
Documentation error in IO::Socket
Perl 5.8.6 File /usr/lib/perl5/5.8.6/i386-linux-thread-multi/IO/Socket.pm on Fedora Core 4. Line 407 (which is part of the POD) states: $sock->read(1024,$data) until $sock->atmark; I don't believe the arguments to the read() method are in the correct order. -- Andrew Benham [EMAIL PROTECTED] [EMAIL PROTECTED] Finchley, London N3 2QQ, U.K. Tel: 020 8495 6343 Fax: 020 8495 6037
RE: [perl #28385] minor bug in cpan -- the i command does not find author
Thank you for providing the patch. Is there any easy way to learn when it has been added to a distribution? Steve -- Steve TolkinSteve . Tolkin at FMR dot COM 617-563-0516 Fidelity Investments 82 Devonshire St. V4D Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. -Original Message- From: Michael G Schwern via RT [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 3:16 AM To: Tolkin, Steve Subject: [perl #28385] minor bug in cpan -- the i command does not find author > [EMAIL PROTECTED] - Thu Apr 08 15:07:50 2004]: > In the cpan shell help says that the command > i > provides information about any of authors, bundles, distributions, > modules > But it does not find authors; It does find authors, but unlike "a", "i" does not automatically upcase your search string. cpan> i MSCHWERN Strange distribution name [MSCHWERN] Author id = MSCHWERN EMAIL[EMAIL PROTECTED] FULLNAME Michael G Schwern cpan> i mschwern Strange distribution name [mschwern] No objects found of any type for argument mschwern The attached patch makes "i" upcase its argument when its searching for authors. PS That "Strange distribution name" warning is part of a sanity check when searching for distributions. The check is not aware that its being run via "i" and thus is normal to be given strange names. But that's for another bug.
[perl #36516] attributes.pm documentation is recursive and incomplete
# New Ticket Created by Mark Stosberg # Please include the string: [perl #36516] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36516 > Hello, This bug report is valid at least until Perl 5.8.7. I was just trying to understand the 'attributes.pm' documentation. My first problem was that the documentation was recursive. As an /explanation/ of how it worked, it gave me this example: use attributes __PACKAGE__, \&foo, 'method'; But I can't see that it explains what this syntax does. As if to further clarify, it uses an example of calling its import method, which is undocumented. attributes::->import(__PACKAGE__, \$x, 'Bent'); Mark -- http://mark.stosberg.com/
Re: Scalar leaked in 'local $0' under ithreads + taint mode
Dave Mitchell wrote: >On Mon, Jul 11, 2005 at 01:29:37PM +0100, Steve Hay wrote: > > >>The patch below fixes it, and all tests still pass. Is it OK? >> >> > >looks good to me > Marvellous. Now applied. 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 fails on z/OS
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 11, 2005 at 04:56:51AM -0700, rajarshi
> das wrote:
> > Hi,
> > Here's a build failure that I am facing on z/OS
> > (perl-5.8.6).
> >
> > I do the following steps :
> >
> > 1) sh Configure -Dmake=gmake
> > 2) modify sv.c
> > 3) gmake
> > gmake[1]: Leaving directory `/perl-5.8.6'
> > ./miniperl -Ilib configpm configpm.tmp
> > sh mv-if-diff configpm.tmp lib/Config.pm
> > mv: configpm.tmp: EDC5129I No such file or
> directory.
> > gmake: *** [lib/Config.pm] Error 1
> >
> > Why does the gmake fail ?
>
> I don't know. Did
>
> ./miniperl -Ilib configpm configpm.tmp
>
> generate a file configpm.tmp in the current
> directory?
No it didnt.
I made the modifications to perlio.c instead of sv.c.
Gmake however gives the same result (fails).
The two changes that I made to perlio.c are :
in PerlIOBuf_fill()
#ifdef EBCDIC
int i;
#endif
also at line no. 3609,
else {
avail = PerlIO_read(n, b->ptr, b->bufsiz);
#ifdef EBCDIC
for(i=0;iptr++) {
if (*b->ptr == 0x41) {
*b->ptr = 0x42;
break;
}
}
# endif
Following is the output of gmake :
`sh cflags "optimize='-g'" perlio.o` perlio.c
CCCMD = c89 -DPERL_CORE -c -DMAXSIG=38
-DOEMVS -D_OE_SOCKETS -D_XOPEN_
SOURCE_EXTENDED -D_ALL_SOURCE -DYYDYNAMIC -DDEBUGGING
-I/usr/local/include -W 0,f
loat(ieee) -g
rm -f libperl.a
/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o uti
l.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o
scope.o pp_ctl.o pp_sys.o do
op.o doio.o regexec.o utf8.o taint.o deb.o universal.o
xsutils.o globals.o perlio
.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o
c89 -Wl,EDIT=NO -L/usr/local/lib -o miniperl \
miniperlmain.o opmini.o libperl.a -lm -lc
./miniperl -w -Ilib -MExporter -e '' || gmake
minitest
Exporter.pm did not return a true value.
BEGIN failed--compilation aborted.
gmake[1]: Entering directory `/perl-5.8.6'
gmake[2]: Entering directory `/perl-5.8.6'
./miniperl -Ilib configpm configpm.tmp
sh mv-if-diff configpm.tmp lib/Config.pm
mv: configpm.tmp: EDC5129I No such file or directory.
gmake[2]: *** [lib/Config.pm] Error 1
gmake[2]: Leaving directory `/perl-5.8.6'
gmake[1]: [minitest.prep] Error 2 (ignored)
You may see some irrelevant test failures if you have
been unable
to build lib/Config.pm, lib/lib.pm or the Unicode data
files.
cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \
&& ./perl TEST -minitest base/*.t comp/*.t
cmd/*.t run/*.t io/*.t op/*.t
uni/*.t ptr == 0x41) {
*b->ptr++ = 0x42;
break;
}
}
# endif
the build goes through, but this doesnt serve my
purpose.
Looks like a b->ptr++ in the for loop isnt allowed ?
Thanks,
Rajarshi.
>
> Nicholas Clark
>
__
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Re: Scalar leaked in 'local $0' under ithreads + taint mode
On Mon, Jul 11, 2005 at 01:29:37PM +0100, Steve Hay wrote: > The patch below fixes it, and all tests still pass. Is it OK? looks good to me -- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in "Star Trek" #9
Re: PERL_DONT_CREATE_GVSV needs to be #define'd somewhere else
Nicholas Clark wrote: >On Mon, Jul 11, 2005 at 10:53:43AM +0100, Steve Hay wrote: > > >>Nicholas Clark wrote: >> >> > > > >>>gcc's C pre-processor can be made to output (only) the defined symbols at the >>>end of processing. I've no idea if other compilers can do this, specifically >>>all the windows compilers. But if they could, it would make makedef.pl much >>>more robust. >>> >>> >>> >>How do you instruct gcc to do that? I'll have a look to see if cl and >>bcc32 can do something similar. >> >> > >-dM > >So > > echo '#include ' | gcc -E - -dM > >produced rather a lot for me. :-) > > Ah. I saw that kind of thing recently when hacking ext/Errno/Errno_pm.PL. That script contains -dM stuff when gcc is in use but not otherwise, which makes me think that cl & bcc32 don't have an equivalent. And I can't see anything like it looking at their options. > > >>>Alternatively, a wholescale refactoring to cause it to output >>>a C file with something recognisable in each #ifdef block (eg the names to >>>export) that it then (at least) preprocessed that file, then we'd get the >>>list of conditional symbols from the horse's mouth, so to speak. >>> >>>But this is lots more work. >>> >>> >>> >>Indeed. Looks like an option in Makefile is the best fix for now. >>It'll have to be enabled by default in blead (and disabled by default >>when merged into maint), and switching it off in blead will actually >>break the build because of that hard-coded #define currently in perl.h! >>So the sooner we drop the conditional stuff from blead the better. >> >> > >I had another idea. Can we run the mkdef stuff immediately after miniperl >and Config.pm are built? > > makedef.pl is already run immediately after miniperl is built. >In which case we run ./miniperl -Ilib -V and parse this bit: > >Characteristics of this binary (from libperl): > Compile-time options: DEBUGGING USE_LARGE_FILES > >ensuring that all the compile time options that affect the presence/absence >of symbols are either in %Config or that section. > (I assume you meant config.h rather than %Config there?) Output of miniperl -Ilib -V is currently no good: ... Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT ... Contrast that with the list of #defines output by makedef.pl: PERL_MALLOC_WRAP USE_STDIO_BASE USE_DYNAMIC_LOADING PL_OP_SLAB_ALLOC HAVE_DES_FCRYPT NO_STRICT USE_STRUCT_COPY PERL_IMPLICIT_SYS USE_THREADS USE_STDIO_PTR PERL_INC_VERSION_LIST _CONSOLE MULTIPLICITY PERL_RELOCATABLE_INC USE_ITHREADS USE_PERLIO PERL_MSVCRT_READFIX WIN32 PERL_TARGETARCH USE_LARGE_FILES NDEBUG PERL_IMPLICIT_CONTEXT So the -V handling code in perl.c would need expanding to test for many more #define's, namely all those affecting exported symbols that aren't already in config.h. My big worry, though, is that miniperl is compiled with different options than perl, e.g. here's the command-lines used to compile av.c in miniperl and perl respectively: cl -c -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi -DNDEBUG -O1 -DPERL_EXTERNAL_GLOB -Fo.\mini\av.obj ..\av.c cl -c -I.. -nologo -Gf -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERLDLL -DPERL_CORE -MD -Zi -DNDEBUG -O1 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -Fo..\av.obj ..\av.c The differences arise because win32/Makefile uses $(CC) -c $(CFLAGS) -DPERL_EXTERNAL_GLOB ... to compile miniperl, but $(CC) -c -I$(
Re: PERL_DONT_CREATE_GVSV needs to be #define'd somewhere else
On Mon, Jul 11, 2005 at 10:53:43AM +0100, Steve Hay wrote: > Nicholas Clark wrote: > >gcc's C pre-processor can be made to output (only) the defined symbols at the > >end of processing. I've no idea if other compilers can do this, specifically > >all the windows compilers. But if they could, it would make makedef.pl much > >more robust. > > > How do you instruct gcc to do that? I'll have a look to see if cl and > bcc32 can do something similar. -dM So echo '#include ' | gcc -E - -dM produced rather a lot for me. :-) > >Alternatively, a wholescale refactoring to cause it to output > >a C file with something recognisable in each #ifdef block (eg the names to > >export) that it then (at least) preprocessed that file, then we'd get the > >list of conditional symbols from the horse's mouth, so to speak. > > > >But this is lots more work. > > > Indeed. Looks like an option in Makefile is the best fix for now. > It'll have to be enabled by default in blead (and disabled by default > when merged into maint), and switching it off in blead will actually > break the build because of that hard-coded #define currently in perl.h! > So the sooner we drop the conditional stuff from blead the better. I had another idea. Can we run the mkdef stuff immediately after miniperl and Config.pm are built? In which case we run ./miniperl -Ilib -V and parse this bit: Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES ensuring that all the compile time options that affect the presence/absence of symbols are either in %Config or that section. Would this work? Nicholas Clark
Re: [perl #36502] File::Copy::mv fails to replicate behavior of Unix mv
Michael G Schwern via RT wrote: >Attached is a test patch to test File::Copy while copying/moving across >partitions. It simulates this by overriding rename() so that it always >fails. All tests are done twice, once with a working rename, once without. > Thanks - applied as change 25122. 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] Cleanup File::Copy tests
Michael G Schwern wrote:
>Attached is a patch to clean up File::Copy's tests to use Test::More instead
>of ad-hoc prints in anticipation of adding more tests.
>
Thanks. Applied as change 25121.
I fixed the SKIP: {} blocks to say $how_many tests they are skipping to
stop some warnings coming out the final count being wrong.
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.
Smoke [5.9.3] 25114 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25114 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 25114 Configuration (common) none --- - F F - - -Duse64bitint O F - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../lib/Net/hostent.tFAILED 4-7 ../t/op/int.t...FAILED 11 [perlio] -Duse64bitint ../t/op/int.t...FAILED 11 Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 [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)
Re: [perl #36502] File::Copy::mv fails to replicate behavior of Unix mv
Michael G Schwern wrote: >On Mon, Jul 11, 2005 at 10:30:54AM -0700, kynn jones wrote: > > >>File::Copy::mv does not preserve the file's mtime across NFS-mounted >>filesystems. This differs from the behavior of the Unix mv(1) >>command, and is not documented in the man page for File::Copy. >> >> > >You're right. And the problem affects any cross-partition move. mv() >falls back to copy() if it cannot rename, as in the case of moving across >partitions, but it does not adjust the mtimes to match. > >The attached patch should fix this by setting the atime and mtime of the >copied file. > Thanks. Applied as change 25120. 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: [perl #36508] Core dump in 5.8.6 ia64 double-free in PerlIOStdio_close
From a parallel universe, Nicholas Clark via RT <[EMAIL PROTECTED]> scrawled. > If you own an opteron machine and are allowed to install Fedora Core 4? Ack... it was late when I filed this. Wrong machine - it's an ia32, sorry.. > Given that the XS code for Ogg::Vorbis has this: > > OggVorbis_File* > new(CLASS) > char *CLASS > CODE: > RETVAL = (OggVorbis_File*) malloc(sizeof(OggVorbis_File)); > OUTPUT: > RETVAL > > void > DESTROY(self) > OggVorbis_File *self > CODE: > safefree(self); > > > but no form of copy constructor, the bug is almost certainly in the module > rather than the perl core. Have you reported it to the module's author? I have not, but will do so now... thank you! -paulb === [EMAIL PROTECTED] There are 10 kinds of people in the world - those who understand binary math, and those who don't. pgpdj1gja4ZZM.pgp Description: PGP signature
[perl #36514] Add curl support to CPAN.pm
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36514] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36514 > This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. - [Please enter your report here] It would be nice if CPAN.pm supported curl as a download method. Particularly because OS X ships with *none* of the currently handled methods (wget, lynx, ncftp*). The code for handling curl can be stolen from CPANPLUS. [Please do not change anything below this line] - --- Flags: category=library severity=wishlist --- Site configuration information for perl v5.8.6: Configured by schwern at Tue May 10 16:13:13 PDT 2005. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=darwin, osvers=7.9.0, archname=darwin-thread-multi-2level uname='darwin windhund.schwern.org 7.9.0 darwin kernel version 7.9.0: wed mar 30 20:11:17 pst 2005; root:xnuxnu-517.12.7.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dcc=gcc-3.3 -Dcpp=gcc-3.3 -E -Dprefix=/sw -Dvendorprefix=/sw -Dccflags=-I/sw/include -Dldflags=-L/sw/lib -Dperladmin=none -Uinstallusrbinperl -Dprivlib=/sw/lib/perl5-core/5.8.6 -Dman3dir=/sw/lib/perl5-core/5.8.6/man/man3 -Dman3ext=3pm -Dvendorlib=/sw/lib/perl5/5.8.6 -Dvendorman3dir=/sw/lib/perl5/5.8.6/man/man3 -Duseithreads -Dinc_version_list=5.8.1 5.8.0 5.6.0 -Adefine:startperl=#!/sw/bin/perl5.8.6 -Dotherlibdirs=/Library/Perl' 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='gcc-3.3', ccflags ='-I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe', optimize='-Os', cppflags='-no-cpp-precomp -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1671)', 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='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/sw/lib -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=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-L/sw/lib -bundle -undefined dynamic_lookup -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.6: /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.6 /sw/lib/perl5/5.8.1 /sw/lib/perl5 /sw/lib/perl5/darwin /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level /sw/lib/perl5-core/5.8.6 /sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/site_perl/5.8.6 /sw/lib/perl5/site_perl /sw/lib/perl5/5.8.6/darwin-thread-multi-2level /sw/lib/perl5/5.8.6 /sw/lib/perl5/5.8.1 /sw/lib/perl5 /Library/Perl/5.8.1 /Library/Perl . --- Environment for perl v5.8.6: DYLD_LIBRARY_PATH (unset) HOME=/Users/schwern LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/schwern/bin:/usr/local/bin:/Users/schwern/bin:/usr/local/bin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/schwern:/usr/X11R6/bin:.:. PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin PERL_BADLANG (unset) SHELL=/bin/bash
Re: CGI: Bug or Feature?
Alberto Manuel Brandão Simões wrote:
>Suppose you have a CGI, and param("foo") is "bar".
>
>if (param("foo") eq "bar") {
>print start_form;
>print hidden("foo","ugh"); ## prints "bar" as the value, not "ugh"
>print end_form;
>}
>
>
It is a feature. All form element output methods (not just hidden())
behave in this "sticky" way. It is useful for simply passing through
existing values of CGI params without having to get their values first:
print hidden("foo");
If you supply a second argument to hidden() then it is only used as a
default value in the absence of an existing value. (And indeed, using
the named parameter style, the second argument is named -default rather
than, say, -value.)
If you want to change the existing value then either call param() first
(as you found), or use the -override argument:
print hidden(-name => "foo", -default => "ugh", -override);
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: CGI: Bug or Feature?
Interesting is that if I change that print hidden() by a print of the
real html code, the value printed is not the correct either.
So, it seems the browser is confused when rendering the page. CGI posts
al the defined variables back again?
Alberto
Alberto Manuel Brandão Simões wrote:
Suppose you have a CGI, and param("foo") is "bar".
if (param("foo") eq "bar") {
print start_form;
print hidden("foo","ugh"); ## prints "bar" as the value, not "ugh"
print end_form;
}
To correct the behaviour...
if (param("foo") eq "bar") {
print start_form;
param("foo", "ugh");
print hidden("foo","ugh"); ## prints "bar" as the value, not "ugh"
print end_form;
}
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
CGI: Bug or Feature?
Suppose you have a CGI, and param("foo") is "bar".
if (param("foo") eq "bar") {
print start_form;
print hidden("foo","ugh"); ## prints "bar" as the value, not "ugh"
print end_form;
}
To correct the behaviour...
if (param("foo") eq "bar") {
print start_form;
param("foo", "ugh");
print hidden("foo","ugh"); ## prints "bar" as the value, not "ugh"
print end_form;
}
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
Re: [perl #17487] ncftp only handles http
On Tue, Jul 12, 2005 at 05:09:15AM -0500, Steve Peters wrote: > On Tue, Jul 12, 2005 at 12:00:02PM +0200, Rafael Garcia-Suarez wrote: > > On 7/12/05, Michael G Schwern via RT <[EMAIL PROTECTED]> wrote: > > > You mention that you have wget. CPAN.pm triest wget last after trying > > > ncftp*. As its the most capable of all the options available it should > > > be tried first. Then lynx. Then finally ncftp*. A patch for this is > > > attached. > > > > Can you include curl in it ? At the beginning or something ? It's > > extremely capable and has excellent error reporting. > > Since curl is included by default on Mac OS X and wget and lynx is not, I'd > like to see curl a little farther up the list as well. Sure, but this involves new code. As the code for handling different download methods has more spagetti than an Italian resturaunt I'd like to finish this bug up and tackle curl as a separate bug. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
RE: blead: no longer supports %vd format
John > I'm sorry that I didn't notice when you submitted the original patches > that you were nuking the VDf support. Is there some reason that the > '%-1p' hack cannot be re-added so that VDf could be supported in the > core as well as in XS modules? Because its a nasty hack that I never meant to go "mainstream" :-) > John Can you give me some C code/patch that generates something to be printed with %vd, perhaps the perl version stuff. I'll look at reinstating a hack for implementing VDf. 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 ---
Re: [perl #17487] ncftp only handles http
On Tue, Jul 12, 2005 at 12:00:02PM +0200, Rafael Garcia-Suarez wrote: > On 7/12/05, Michael G Schwern via RT <[EMAIL PROTECTED]> wrote: > > You mention that you have wget. CPAN.pm triest wget last after trying > > ncftp*. As its the most capable of all the options available it should > > be tried first. Then lynx. Then finally ncftp*. A patch for this is > > attached. > > Can you include curl in it ? At the beginning or something ? It's > extremely capable and has excellent error reporting. > Since curl is included by default on Mac OS X and wget and lynx is not, I'd like to see curl a little farther up the list as well. Steve Peters [EMAIL PROTECTED]
Re: [perl #17487] ncftp only handles http
On 7/12/05, Michael G Schwern via RT <[EMAIL PROTECTED]> wrote: > You mention that you have wget. CPAN.pm triest wget last after trying > ncftp*. As its the most capable of all the options available it should > be tried first. Then lynx. Then finally ncftp*. A patch for this is > attached. Can you include curl in it ? At the beginning or something ? It's extremely capable and has excellent error reporting.
Re: [perl #36510] File::Spec and leading/trailing space
Michael G Schwern (via RT) <[EMAIL PROTECTED]> wrote:
:rt.perl.org 24691 is about CPAN.pm saying that a path with a leading space
:is not absolute. The issue is File::Spec... maybe. file_name_is_absolute() i
:does not recognize " /foo" as being absolute.
:
:$ perl -wle 'use File::Spec; print File::Spec->file_name_is_absolute(" /foo")'
:
:$ perl -wle 'use File::Spec; print File::Spec->file_name_is_absolute("/foo")'
:1
:
:canonpath() does not clean up leading or trailing space.
:
:$ perl -wle 'use File::Spec; print File::Spec->canonpath("/foo")'
:/foo
:
:$ perl -wle 'use File::Spec; print File::Spec->canonpath(" /foo")'
: /foo
:$ perl -wle 'use File::Spec; print q["].File::Spec->canonpath(" /foo ").q["]'
:" /foo "
:
:Should it? Does leading and trailing space have any meaning in a Unix path?
Yes: I can happily create and act on files and directories with spaces
(even consisting only of spaces) as long as I protect them from the shell.
This seems perfectly correct to me.
As far as I know a unix directory entry is one or more characters in the
range \x1..\xff excluding '/', no other restrictions except for maximum
length.
Hugo
Re: [perl #36508] Core dump in 5.8.6 ia64 double-free in PerlIOStdio_close
On Mon, Jul 11, 2005 at 06:24:44PM -0700, paulb @ cajun. nu wrote: > Trying to install Ogg::Vorbis using CPAN on perl 5.8.6 on > amd64 Fedore Core 4, with latest OS updates. Easily reproducable. If you own an opteron machine and are allowed to install Fedora Core 4? > chmod 755 blib/arch/auto/Ogg/Vorbis/Vorbis.so > cp Vorbis.bs blib/arch/auto/Ogg/Vorbis/Vorbis.bs > chmod 644 blib/arch/auto/Ogg/Vorbis/Vorbis.bs > cp pogg blib/script/pogg > /usr/bin/perl "-MExtUtils::MY" -e "MY->fixin(shift)" blib/script/pogg > Manifying blib/man1/pogg.1 > Manifying blib/man3/Ogg::Vorbis.3pm > /usr/bin/make -- OK > Running make test > PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl > 1..12 > ok 1 > ok 2 > ok 3 > ok 4 > ok 5 > ok 6 > ok 7 > ok 8 > warning: invalid comment field #0 > ok 9 > ok 10 > ok 11 > ok 12 > *** glibc detected *** /usr/bin/perl: double free or corruption (!prev): > 0x089fd448 *** Given that the XS code for Ogg::Vorbis has this: OggVorbis_File* new(CLASS) char *CLASS CODE: RETVAL = (OggVorbis_File*) malloc(sizeof(OggVorbis_File)); OUTPUT: RETVAL void DESTROY(self) OggVorbis_File *self CODE: safefree(self); but no form of copy constructor, the bug is almost certainly in the module rather than the perl core. Have you reported it to the module's author? Nicholas Clark
[Tom Christiansen] perl's automagic CPAN.pm shell ignores job control
Start of forwarded message Date: Tue Jul 12 08:45:26 2005 From: Tom Christiansen <[EMAIL PROTECTED]> Subject: perl's automagic CPAN.pm shell ignores job control Topics: Re: perl's automagic CPAN.pm shell ignores job control Re: perl's automagic CPAN.pm shell ignores job control perl's automagic CPAN.pm shell ignores job control -- Date: Tue, 29 Aug 2000 09:14:43 -0600 From: Tom Christiansen <[EMAIL PROTECTED]> cc: Andreas Koenig <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: perl's automagic CPAN.pm shell ignores job control Message-ID: <[EMAIL PROTECTED]> Note that this job-control zapping also affects the perl debugger, which can no longer be controlled! % perl -de 0 Default die handler restored. Default die handler restored. warn set to 0, die set to 0 Loading DB routines from perl5db.pl version 1.07 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB<1> x \%INC 0 HASH(0xa90cc) '/home/tchrist/.perldb' => '/home/tchrist/.perldb' 'AutoLoader.pm' => '/usr/local/lib/perl5/5.6.0/AutoLoader.pm' 'Carp.pm' => '/usr/local/lib/perl5/5.6.0/Carp.pm' 'DynaLoader.pm' => '/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/DynaLoader.pm' 'Exporter.pm' => '/usr/local/lib/perl5/5.6.0/Exporter.pm' 'SelfLoader.pm' => '/usr/local/lib/perl5/5.6.0/SelfLoader.pm' 'Term/Cap.pm' => '/usr/local/lib/perl5/5.6.0/Term/Cap.pm' 'Term/ReadKey.pm' => '/usr/local/lib/perl5/site_perl/5.00554/OpenBSD.i386-openbsd/Term/ReadKey.pm' 'Term/ReadLine.pm' => '/usr/local/lib/perl5/5.6.0/Term/ReadLine.pm' 'Term/ReadLine/Perl.pm' => '/usr/local/lib/perl5/site_perl/5.6.0/Term/ReadLine/Perl.pm' 'Term/ReadLine/readline.pm' => '/usr/local/lib/perl5/site_perl/5.6.0/Term/ReadLine/readline.pm' 'dumpvar.pl' => '/usr/local/lib/perl5/5.6.0/dumpvar.pl' 'perl5db.pl' => '/usr/local/lib/perl5/5.6.0/perl5db.pl' DB<2> system "ls", "-lct", values %INC -r--r--r-- 1 root users3799 Aug 29 08:43 /usr/local/lib/perl5/site_perl/5.6.0/Term/ReadLine/Perl.pm - r--r--r-- 1 root users 109615 Aug 29 08:43 /usr/local/lib/perl5/site_perl/5.6.0/Term/ReadLine/readline.pm - r--r--r-- 1 root users 84629 Mar 27 17:02 /usr/local/lib/perl5/5.6.0/perl5db.pl - r--r--r-- 1 root users 11982 Mar 27 17:02 /usr/local/lib/perl5/5.6.0/dumpvar.pl - rw-r--r-- 1 tchrist wheel 294 Mar 25 11:13 /home/tchrist/.perldb - r--r--r-- 1 root users 14164 Mar 25 09:27 /usr/local/lib/perl5/site_perl/5.00554/OpenBSD.i386-openbsd/Term/ReadKey.pm - r--r--r-- 1 root users 27554 Mar 25 09:24 /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd/DynaLoader.pm - r--r--r-- 1 root users 12043 Mar 25 09:23 /usr/local/lib/perl5/5.6.0/SelfLoader.pm - r--r--r-- 1 root users 10377 Mar 25 09:23 /usr/local/lib/perl5/5.6.0/Exporter.pm - r--r--r-- 1 root users4166 Mar 25 09:23 /usr/local/lib/perl5/5.6.0/Carp.pm - r--r--r-- 1 root users 10167 Mar 25 09:23 /usr/local/lib/perl5/5.6.0/AutoLoader.pm - r--r--r-- 1 root users 10011 Mar 25 09:21 /usr/local/lib/perl5/5.6.0/Term/ReadLine.pm - r--r--r-- 1 root users 11745 Mar 25 09:21 /usr/local/lib/perl5/5.6.0/Term/Cap.pm -- Date: Tue, 29 Aug 2000 09:07:05 -0600 From: Tom Christiansen <[EMAIL PROTECTED]> To: Andreas Koenig <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: perl's automagic CPAN.pm shell ignores job control Message-ID: <[EMAIL PROTECTED]> I resent that message because it seemed to fall into a black hole; that is, I got back neither acknowledgement nor a copy of the bug report submitted. I imagine the job control annihilation is really a function of some of the tty reading modules that CPAN.pm is using. As for the installation times, this is certainly debatable, but I found it surprising. - -tom -- Date: Tue, 29 Aug 2000 08:55:23 -0600 From: Tom Christiansen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Andreas Koenig <[EMAIL PROTECTED]> Subject: perl's automagic CPAN.pm shell ignores job control Message-ID: <[EMAIL PROTECTED]> I decided to (try) use CPAN to install LWP, since there are millions of dependencies. After some dicey configuration foo, it appeared to work. So for the first time, I took its suggestion to install an updated CPAN bundle, too. It of course installed a *lot* of stuff. Twenty minutes later, after reload CPAN, I could no longer type ^Z to suspend the job, ^D to provide an EOF, etc. This is very annoying. It shouldn't destroy my ability to use job control! Here's what version it was: % perl -MCPAN -le 'print CPAN->VERSION()' 1.57 Also, I can't simply figure out what got installed, because the mtimes are all
[perl #36507] copy($foo, $foo) dies
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #36507]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36507 >
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.6.
-
[Please enter your report here]
copy() will die (not warn) if you attempt to copy a file to itself.
0 ~$ perl -MFile::Copy -wle 'copy("this", "this"); print "After death"'
'this' and 'this' are identical (not copied) at -e line 1
It even goes so far as to check if they're linked (soft or hard).
0 /tmp$ touch foo
0 /tmp$ ln foo bar
0 /tmp$ perl -MFile::Copy -wle 'copy("foo", "bar"); print "After death"'
'foo' and 'bar' are identical (not copied) at -e line 1
This behavior was introduced in rt.perl.org 5196 and patch #11526.
http://public.activestate.com/cgi-bin/perlbrowse?patch=11526
While I have no problem with the check, I feel dying is unwarrented.
Nothing failed to work. The copy succeeded in that both files contain the
same data. The fact that trying to copy one linked file over another dies
can lead to surprises as programs die on otherwise innocent operations.
Copying a file over itself is dubious but not an error. That's what warnings
are for. It should be downgraded to a warning.
[Please do not change anything below this line]
-
---
Flags:
category=library
severity=low
---
Site configuration information for perl v5.8.6:
Configured by schwern at Tue May 10 16:13:13 PDT 2005.
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=darwin, osvers=7.9.0, archname=darwin-thread-multi-2level
uname='darwin windhund.schwern.org 7.9.0 darwin kernel version 7.9.0: wed
mar 30 20:11:17 pst 2005; root:xnuxnu-517.12.7.obj~1release_ppc power macintosh
powerpc '
config_args='-des -Dcc=gcc-3.3 -Dcpp=gcc-3.3 -E -Dprefix=/sw
-Dvendorprefix=/sw -Dccflags=-I/sw/include -Dldflags=-L/sw/lib -Dperladmin=none
-Uinstallusrbinperl -Dprivlib=/sw/lib/perl5-core/5.8.6
-Dman3dir=/sw/lib/perl5-core/5.8.6/man/man3 -Dman3ext=3pm
-Dvendorlib=/sw/lib/perl5/5.8.6 -Dvendorman3dir=/sw/lib/perl5/5.8.6/man/man3
-Duseithreads -Dinc_version_list=5.8.1 5.8.0 5.6.0
-Adefine:startperl=#!/sw/bin/perl5.8.6 -Dotherlibdirs=/Library/Perl'
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='gcc-3.3', ccflags ='-I/sw/include -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -pipe',
optimize='-Os',
cppflags='-no-cpp-precomp -I/sw/include -fno-common -DPERL_DARWIN
-no-cpp-precomp -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1671)',
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='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/sw/lib
-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=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-L/sw/lib -bundle -undefined dynamic_lookup
-L/usr/local/lib'
Locally applied patches:
---
@INC for perl v5.8.6:
/sw/lib/perl5/5.8.6/darwin-thread-multi-2level
/sw/lib/perl5/5.8.6
/sw/lib/perl5/5.8.1
/sw/lib/perl5
/sw/lib/perl5/darwin
/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level
/sw/lib/perl5-core/5.8.6
/sw/lib/perl5/site_perl/5.8.6/darwin-thread-multi-2level
/sw/lib/perl5/site_perl/5.8.6
/sw/lib/perl5/site_perl
/sw/lib/perl5/5.8.6/darwin-thread-multi-2level
/sw/lib/perl5/5.8.6
/sw/lib/perl5/5.8.1
/sw/lib/perl5
/Library/Perl/5.8.1
/Library/Perl
.
---
Environment for perl v5.8.6:
DYLD_LIBRARY_PATH (unset)
HOME=/Users/schwern
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/Users/schwern/bin:/usr/local/bin:/Users/schwern/bin:/usr/local/bin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/schwern:/usr/X11R6/bin:.:.
PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin
PERL_BADLANG (unset)
SHELL=/bin/bash
[perl #36508] Core dump in 5.8.6 ia64 double-free in PerlIOStdio_close
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36508] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36508 > This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. - [Please enter your report here] Trying to install Ogg::Vorbis using CPAN on perl 5.8.6 on amd64 Fedore Core 4, with latest OS updates. Easily reproducable. chmod 755 blib/arch/auto/Ogg/Vorbis/Vorbis.so cp Vorbis.bs blib/arch/auto/Ogg/Vorbis/Vorbis.bs chmod 644 blib/arch/auto/Ogg/Vorbis/Vorbis.bs cp pogg blib/script/pogg /usr/bin/perl "-MExtUtils::MY" -e "MY->fixin(shift)" blib/script/pogg Manifying blib/man1/pogg.1 Manifying blib/man3/Ogg::Vorbis.3pm /usr/bin/make -- OK Running make test PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl 1..12 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 warning: invalid comment field #0 ok 9 ok 10 ok 11 ok 12 *** glibc detected *** /usr/bin/perl: double free or corruption (!prev): 0x089fd448 *** === Backtrace: = /lib/libc.so.6[0x20a424] /lib/libc.so.6(__libc_free+0x77)[0x20a95f] /lib/libc.so.6(fclose+0x148)[0x1fbf30] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(PerlIOStdio_close+0x87)[0x9ee3f7] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(PerlIO__close+0x39)[0x9ecfa1] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(Perl_PerlIO_close+0x26)[0x9ecff5] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(Perl_io_close+0xa1)[0x9cd471] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(Perl_do_close+0xe9)[0x9cd5bf] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_close+0x5b)[0x9b9cfa] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(Perl_runops_debug+0x141)[0x95f6e1] /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so(perl_run+0x445)[0x911fe1] /usr/bin/perl(main+0x130)[0x80493f4] /lib/libc.so.6(__libc_start_main+0xc6)[0x1bbde6] /usr/bin/perl[0x8049241] === Memory map: 00189000-001a3000 r-xp 03:03 5597861/lib/ld-2.3.5.so 001a3000-001a4000 r-xp 00019000 03:03 5597861/lib/ld-2.3.5.so 001a4000-001a5000 rwxp 0001a000 03:03 5597861/lib/ld-2.3.5.so 001a7000-002cb000 r-xp 03:03 5597862/lib/libc-2.3.5.so 002cb000-002cd000 r-xp 00124000 03:03 5597862/lib/libc-2.3.5.so 002cd000-002cf000 rwxp 00126000 03:03 5597862/lib/libc-2.3.5.so 002cf000-002d1000 rwxp 002cf000 00:00 0 002d3000-002f5000 r-xp 03:03 5597865/lib/libm-2.3.5.so 002f5000-002f6000 r-xp 00021000 03:03 5597865/lib/libm-2.3.5.so 002f6000-002f7000 rwxp 00022000 03:03 5597865/lib/libm-2.3.5.so 002f9000-002fb000 r-xp 03:03 5597864/lib/libdl-2.3.5.so 002fb000-002fc000 r-xp 1000 03:03 5597864/lib/libdl-2.3.5.so 002fc000-002fd000 rwxp 2000 03:03 5597864/lib/libdl-2.3.5.so 00314000-00322000 r-xp 03:03 5597863/lib/libpthread-2.3.5.so 00322000-00323000 r-xp d000 03:03 5597863/lib/libpthread-2.3.5.so 00323000-00324000 rwxp e000 03:03 5597863/lib/libpthread-2.3.5.so 00324000-00326000 rwxp 00324000 00:00 0 00328000-0032c000 r-xp 03:03 1225076/usr/lib/libogg.so.0.5.2 0032c000-0032d000 rwxp 3000 03:03 1225076/usr/lib/libogg.so.0.5.2 0032f000-00348000 r-xp 03:03 1225102/usr/lib/libvorbis.so.0.3.0 00348000-00357000 rwxp 00019000 03:03 1225102/usr/lib/libvorbis.so.0.3.0 00359000-0035f000 r-xp 03:03 1223516/usr/lib/libvorbisfile.so.3.1.0 0035f000-0036 rwxp 5000 03:03 1223516/usr/lib/libvorbisfile.so.3.1.0 00493000-0049c000 r-xp 03:03 5597866 /lib/libgcc_s-4.0.0-20050520.so.1 0049c000-0049d000 rwxp 9000 03:03 5597866 /lib/libgcc_s-4.0.0-20050520.so.1 0049f000-004ae000 r-xp 03:03 6121699/lib/libresolv-2.3.5.so 004ae000-004af000 r-xp e000 03:03 6121699/lib/libresolv-2.3.5.so 004af000-004b rwxp f000 03:03 6121699/lib/libresolv-2.3.5.so 004b-004b2000 rwxp 004b 00:00 0 004d6000-004d7000 r-xp 004d6000 00:00 0 00509000-0050b000 r-xp 03:03 6121747/lib/libutil-2.3.5.so 0050b000-0050c000 r-xp 1000 03:03 6121747/lib/libutil-2.3.5.so 0050c000-0050d000 rwxp 2000 03:03 6121747/lib/libutil-2.3.5.so 006b4000-006bf000 r-xp 03:03 5335989 /root/.cpan/build/libvorbis-perl-0.05/blib/arch/auto/Ogg/Vorbis/Vorbis.so 006bf000-006c rwxp a000 03:03 5335989 /root/.cpan/build/libvorbis-perl-0.05/blib/arch/auto/Ogg/Vorbis/Vorbis.so 008eb000-00a2a000 r-xp 03:03 458319 /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so 00a2a000-00a35000 rwxp 0013e000 03:03 458319 /usr/lib/perl5/5.8.6/i386-linux-thread-multi/CORE/libperl.so 00a35000-00a37000 rwxp 00a35000 00:00 0 00a3e000-00a43000 r-xp 03:03 5597871
Re: [perl #36510] File::Spec and leading/trailing space
On Mon, Jul 11, 2005 at 11:41:04PM -0700, Michael G Schwern wrote:
> rt.perl.org 24691 is about CPAN.pm saying that a path with a leading space
> is not absolute. The issue is File::Spec... maybe. file_name_is_absolute() i
> does not recognize " /foo" as being absolute.
>
> $ perl -wle 'use File::Spec; print File::Spec->file_name_is_absolute("
> /foo")'
>
> $ perl -wle 'use File::Spec; print File::Spec->file_name_is_absolute("/foo")'
> 1
>
> canonpath() does not clean up leading or trailing space.
>
> $ perl -wle 'use File::Spec; print File::Spec->canonpath("/foo")'
> /foo
>
> $ perl -wle 'use File::Spec; print File::Spec->canonpath(" /foo")'
> /foo
> $ perl -wle 'use File::Spec; print q["].File::Spec->canonpath(" /foo ").q["]'
> " /foo "
>
> Should it? Does leading and trailing space have any meaning in a Unix path?
Certainly.
$ mkdir ' '
$ touch ' /foo '
$ ls -lRQ
".":
total 4
drwxrwxr-x 2 pjcj pjcj 4096 2005-07-12 11:01 " "
"./ ":
total 0
-rw-rw-r-- 1 pjcj pjcj 0 2005-07-12 11:01 "foo "
So it seems to me that File:Spec is doing the right thing here.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: [PATCH] perlfunc.pod
On Tue, Jul 12, 2005 at 08:55:33AM +0100, Steve Hay wrote: > >Didn't we conclude it would be better to give Pod::Html the same foo() > >recognition magic that Pod::Man has and not have to put C<> around every > >function? > > > Patches welcome! Patch Pod::Html? Sorry, I have to.. umm.. I have to rearrange my sock drawer. On Pluto. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
[perl #36513] Pod::Html exports two undocumented functions
# New Ticket Created by Michael G Schwern # Please include the string: [perl #36513] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36513 > Pod::Html exports two undocumented functions htmlify() and anchorify(). It probably shouldn't. Only one thing on CPAN uses htmlify() (Win32::GUI). Only installhtml in the perl core uses anchorify(). Its not really hurting anything to have them exported, but it would be nice if they were documented. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
Re: Perl 5 Bug Summary
On Mon, Jul 11, 2005 at 09:55:46PM -0700, Robert Spier wrote: > 36428 Problem with the debugger with conjunction to Encoding > 36430 Sort within a sort does not set $a, $b > 36448 configuring ranlib for perl on osx with xcode 2.1 36430 didn't hit the list. I remember 36448. Not sure about 36428, but like 36430 Google groups doesn't find it. Nicholas Clark
Re: [patch: handy.c] update Newx API pod to mention PERL_MEM_LOG build opt
Jim Cromie wrote: >Ought this build option be added to Configure somehow ? >or is it just for folk who know how to use -Acc etc in builds ? > >And perhaps exposed in POD somewhere too ? > Thanks - applied as change 25115. I moved the changed block of text into the Newx() description itself where it makes more sense, and linked Newxc() and Newxz() to it. I also added a link to perlhack/PERL_MEM_LOG. 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
Michael G Schwern wrote: >On Mon, Jul 11, 2005 at 04:45:39PM +0100, Steve Hay wrote: > > >>OTOH, functions are perhaps better written as C because this >>causes them to be linked when converted to HTML. >> >> > >Didn't we conclude it would be better to give Pod::Html the same foo() >recognition magic that Pod::Man has and not have to put C<> around every >function? > Patches welcome! 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: handy.c] update Newx API pod to mention PERL_MEM_LOG build opt
H.Merijn Brand wrote: >On Mon, 11 Jul 2005 19:18:02 -0600, Jim Cromie <[EMAIL PROTECTED]> wrote: > > >>And perhaps exposed in POD somewhere too ? >> >> > >perlhack maybe > It is already documented in perlhack.pod. Look for "=head2 PERL_MEM_LOG". 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: handy.c] update Newx API pod to mention PERL_MEM_LOG build opt
On Mon, 11 Jul 2005 19:18:02 -0600, Jim Cromie <[EMAIL PROTECTED]> wrote: > > Ought this build option be added to Configure somehow ? I would not know why, how, and where :) > or is it just for folk who know how to use -Acc etc in builds ? Look in the Porting/ folder. Most files there are generated. Would your patch be viable for the Glossary? > And perhaps exposed in POD somewhere too ? perlhack maybe -- 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
[perl #28385] minor bug in cpan -- the i command does not find author
Forgot to CC p5p with my patch. Pumpkings and pumpkinglets, there's a patch for this bug. Please have a look at it in RT.
[perl #24691] leading spaces on cpan configuration causes failure
> [EMAIL PROTECTED] - Thu Dec 18 15:43:42 2003]: > When I started cpan for the first time on perl-5.8.2 and started the > configuration process I was cutting and pasting from a file. I grabbed >the > cpan directory location with leading spaces and pasted it. > > The results were this as the next prompt > > first line > CPAN build and cache directory? [/login/warrend/.cpan] >/proj/wdtold/warrend/cpan_perl-5.8.2_sun5.8 > The path ' /proj/wdtold/warrend/cpan_perl-5.8.2_sun5.8' is not an >absolute path. Please specify an absolute path The attached patch makes CPAN::FirstTime consistent in its stripping of leading and trailing spaces by building it directly into its prompt() function rather than hoping the caller deals with it. In two places I've left the input unstripped, the proxy username and password. Concievably one could have a username and password which begins or ends with spaces so its best to leave that unaltered. CPAN_FirstTime.patch Description: Binary data
