IO::Select Limitations
IO::Select-select gives no way to detect a timeout. Both timeout and error return the same values. Timeout should return an array with three undef entries. The documentation for IO::Select-select does not document what the return value will be after a timeout. David Austin --- [EMAIL PROTECTED] Robotic Systems Laboratory, Hiroshima '45 Department of Systems Engineering, Chernobyl '86 RSISE, Australian National University Windows '95
Re: better assertion support
On Wed, Sep 07, 2005 at 04:15:58PM +0100, Salvador Fandiño wrote:
Hi,
Nicholas Clark wrote:
Now that the assertion code is (I believe) fully feature complete, I'm
wondering if it can be refactored into a minimal set of core hooks, and an
XS module in ext. Having more hooks increases what is possible for future
authors to achieve as independent modules released to CPAN.
There were two mayor reasons why assertions could not be
implemented outside the core:
1) assertion magic happens at compile time changing the way
assertion calls are compiled inside their callers.
Extending perl to allow customizing how subroutine calls are
compiled, well, that makes me thing about macros, but adding
support for macros to perl5 seems a bit crazy to me :-)
...though some kind of low level macros able to work with OPs
could be used, for instance:
sub sqr : macro {
return B::OPBIN-new(mul, $_[0], $_[0]-clone);
}
Yes, there's no fundamental reason not to add hooks this deep into the
compile time to allow this. If you found you needed this level of flexibility
for assertions, and the core were improved to provide it, who knows what
else CPAN authors (or at least Dr Evil) would be able to come up with.
2) subs and attributes:
currently, subs attributes are very poorly handled, there are
very few things one can do with them, specially because there is
no information about the GLOBs where the subs are going to be stored.
Attribute::Handlers tries to work around that, but it is far from
perfect, mostly because it runs at INIT or CHECK time, and so too
late for attributes that want to influence compile time!
I think this could be done better, maybe adding support for a new
MODIFY_CODEGLOB_ATTRIBUTES hook. Or maybe two, one called before
the sub is defined and another after
(MODIFY_PRECODEGLOB_ATTRIBUTES, MODIFY_POSTCODEGLOB_ATTRIBUTES),
but well, it's a complex matter and all the different possible
cases should be considered.
I don't know enough about how the compile phase works to be able to comment
on the right way to do this.
Nicholas Clark
Re: perl5.004_05 compile problems
On Wed, Sep 14, 2005 at 09:01:20AM +0200, H.Merijn Brand wrote: On Tue, 13 Sep 2005 21:21:23 -0700, Shaun Daredia [EMAIL PROTECTED] wrote: I am trying to compile perl5.004_05 under SLES9 SP2 and I am seeing the following message. make: *** No rule to make target `built-in', needed by `miniperlmain.o'. Stop. You are building a very old perl with a (very) new GNU gcc GNU gcc has changed some of the text it prints, and the build process of newer perls (5.6.2, 5.8.x, 5.9.x) can deal with that, but there has never been an update for 5.005.x Correction: 5.005_04 was updated; 5.004_05 was not. If you *really* need a perl that old, you will have to apply this patch: So this part still applies.
Re: perl5.004_05 compile problems
On Fri, 16 Sep 2005 05:18:04 -0700, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote: On Wed, Sep 14, 2005 at 09:01:20AM +0200, H.Merijn Brand wrote: On Tue, 13 Sep 2005 21:21:23 -0700, Shaun Daredia [EMAIL PROTECTED] wrote: I am trying to compile perl5.004_05 under SLES9 SP2 and I am seeing the following message. make: *** No rule to make target `built-in', needed by `miniperlmain.o'. Stop. You are building a very old perl with a (very) new GNU gcc GNU gcc has changed some of the text it prints, and the build process of newer perls (5.6.2, 5.8.x, 5.9.x) can deal with that, but there has never been an update for 5.005.x Correction: 5.005_04 was updated; 5.004_05 was not. ? If you *really* need a perl that old, you will have to apply this patch: So this part still applies. Maybe with a little fuzz. I just perlbrowse'd to find the original patch that solved this specific issue in blead. I knew that, because I made the patch :) -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Smoke [5.9.3] 25417 FAIL(F) freebsd 5.4-STABLE (i386/6 cpu)
Automated smoke report for 5.9.3 patch 25417 profane.mongueurs.net: Intel Pentium III Xeon (i386/6 cpu) onfreebsd - 5.4-STABLE using cc version 3.4.2 [FreeBSD] 20040728 smoketime 5 hours 19 minutes (average 31 minutes 56 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25417 Configuration (common) none --- - F - F - -Uuseperlio O O O O O O O O -Duse64bitint O O O O -Duseithreads O O O O -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio] -Uuseperlio [stdio] -DDEBUGGING -Uuseperlio ../ext/B/t/concise-xs.t.FAILED 3-779 ../ext/B/t/concise.tFAILED 145-149 ../ext/IO/t/io_sock.t...FAILED 18-26 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
Re: Smoke [5.9.3] 25417 FAIL(F) freebsd 5.4-STABLE (i386/6 cpu)
I think we had said we could always keep useperlio for blead smokes. [EMAIL PROTECTED] wrote: Automated smoke report for 5.9.3 patch 25417 profane.mongueurs.net: Intel Pentium III Xeon (i386/6 cpu) onfreebsd - 5.4-STABLE using cc version 3.4.2 [FreeBSD] 20040728 smoketime 5 hours 19 minutes (average 31 minutes 56 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25417 Configuration (common) none --- - F - F - -Uuseperlio O O O O O O O O -Duse64bitint O O O O -Duseithreads O O O O -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio] -Uuseperlio [stdio] -DDEBUGGING -Uuseperlio ../ext/B/t/concise-xs.t.FAILED 3-779 ../ext/B/t/concise.tFAILED 145-149 ../ext/IO/t/io_sock.t...FAILED 18-26 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
Re: Smoke [5.9.3] 25417 FAIL(F) freebsd 5.4-STABLE (i386/6 cpu)
Rafael Garcia-Suarez wrote: I think we had said we could always keep useperlio for blead smokes. ignore these reports. I was syncing from the wrong repository. David
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
Steve == Steve Peters [EMAIL PROTECTED] writes: Steve I've seen this issue elsewhere but haven't caught whether the Steve problem is with the default Perl installed on OS X 10.4, or if Steve this is a freshly built maint. Which are you seeing this on? Steve The actually cause of the problem lies in how Scalar::Utils is Steve built. The implementation you have was built without compiling Steve the XS portion of Scalar::Utils. If you do a fresh install of Steve Scalar::Utils, the problems are fixed. Yeah, so that's the problem. I install a new Perl, it installs the non-XS version of Scalar::Util. Then I can't install Storable (or many other things) because they say weak isn't supported. Sure, installing Scalar::Util from the CPAN fixes it, but that's not listed as a prereq so it doesn't happen automatically. Thus, Storable's test needs to ignore the weak isn't supported error (right now, that's fatal to the test). This would be the bugreport for P5P. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Fri, Sep 16, 2005 at 10:44:27AM -0700, Randal L. Schwartz wrote: Yeah, so that's the problem. I install a new Perl, it installs the non-XS version of Scalar::Util. Then I can't install Storable (or many other things) because they say weak isn't supported. Sure, installing Scalar::Util from the CPAN fixes it, but that's not listed as a prereq so it doesn't happen automatically. Thus, Storable's test needs to ignore the weak isn't supported error (right now, that's fatal to the test). This would be the bugreport for P5P. And the bug report for the distributor of the perl you installed would be why isn't it installing the XS version of a core module? ? Nicholas Clark
[PATCH] Compress::Zlib 1.39
Syncs core with CPAN Paul zlib-1.39.patch Description: Binary data
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
Nicholas == Nicholas Clark [EMAIL PROTECTED] writes: Nicholas And the bug report for the distributor of the perl you Nicholas installed would be why isn't it installing the XS version Nicholas of a core module? ? What do you mean distributor of the perl you installed? Joking, right? I've said maintperl a few times already. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
This Week on perl5-porters (5-11 September 2005)
This Week on perl5-porters (5-11 September 2005)
The Return of the perl5-porters Summaries
Sébastien Aperghis-Tramoni, Adriano Ferreira and David Landgren have
stepped up to the plate to bring you the weekly p5p summaries. We make
no promises as to how long we can keep this up, but we'll give it a go
for as long as we can.
There has been a lot of action happening in Perl 5 land, and we hope
that these messages will help people keep abreast of the latest
developments.
Onto last week's traffic:
sub _ { ... } and -X _
Peter Dintelmann pondered over the meaning of -X _ when sub _ { ...
} defined, as it can lead to some surprising behaviour. Mark-Jason
Dominus pointed to http://hop.perl.plover.com/errata/byid.cgi/131 and
http://hop.perl.plover.com/~alias/list.cgi?2:mss:264 for more
information on the matter.
http://xrl.us/hkyk
VMS Issues
John E. Malmberg asked for advice on how to deal with File::Copy on
VMS. The library test fails because the copied file ends up with a
timestamp of 'now', which is consistent with the way things are done
in the DCL command shell. Part of the problem was that the test suite
failure message was misleading. John fixed things up as best he could.
http://xrl.us/hkym
He also landed a patch for ExtUtils::CBuilder. After a bit of work, he
and Ken Williams got it working correctly.
http://xrl.us/hkyn
In other VMS news, the current bleadperl is testing fairly well. The
main show-stopper being problems with Compress::Zlib.
http://xrl.us/hkyo
Eliminating arenaroots
Internally, perl uses arenas of memory to allocate fixed-length
objects quickly and efficiently. The current plan is the shrink the
number of roots down to one. Jim Cromie supplied a patch. The test
smokes produced a number of odd results that had people scratching
their heads, until it was realised that the problem was a single
statement if that lost its braces.
http://xrl.us/hkyp
Dying in a grep
Chris Heath noted the following:
$ perl -e 'for (foo) { grep(die, bar) }'
Died at -e line 1.
Attempt to free unreferenced scalar: SV 0x96c61dc, Perl interpreter:
0x96ae008.
Normally, the third line shouldn't appear. And map will do the same
thing. Salvador Fandiño noted that this had already been recorded as
bug #24254.
http://xrl.us/hkyq
eg should be e.g. in the documentation
David Landgren was peeved that *exempli gratia* is often abbreviated
to eg in the documentation, rather than e.g.. Mark-Jason Dominus
wondered why it was not abbreviated to for example. Michael Schwern
brought the discussion to a close by performing a simple cost/benefit
analysis.
http://xrl.us/hkyr
Math::Complex atan2 bug
Steffen Müller observed the following
[...] in the complex plane, we get:
perl -MMath::Complex -e print atan2(0,i)
i/0: Division by zero.
Died at c:/perl/perl58/lib/Math/Complex.pm line 1284.
This is not correct.
Obviously, 0/i is the same as 0/1 which is 0.
Thus atan2(0,i) == atan2(0,1) == atan(0) == 0
Jarkko Hietaniemi said that he'd cook up a patch, but that he had
other outstanding things to do with Math::Complex and Math::Trig.
http://xrl.us/hkys
undefing *foo{CODE}
Ben Tilly reported that undef'ing the CODE slot of a typeglob doesn't
quite work well enough to be useful, and supplied a short snippet of
code showing the problem.
http://xrl.us/hkyt
Dave Mitchell shed some light on what was going on under the covers
the thing continues to exist, but has no useful 'value', and Rafael
Garcia-Suarez noted that
delete mysub
is on the TODO list, but getting it right in all cases is extremely
tricky.
tr// on EBCDIC platforms
Sadahiro Tomoyuki found problems with transliterating Unicode
characters. I can only offer my deepest sympathy.
http://xrl.us/hkyu
New core module releases
Graham Barr released IO version 1.22. There was concern about what the
impact would be on the 5.6 series.
http://search.cpan.org/dist/IO/
Dan Kogai released Encode 2.12...
http://search.cpan.org/dist/Encode/
... and Ruslan U. Zakirov spotted a problem with an example in the
documentation.
The return value of SvUTF8()
In December 2004, Ton Hospel raised bug #32884. The internal perl API
defines SvUTF8() as taking a pointer to an SV, and returning a boolean
value indicating whether the SV contains utf-8 encoded data.
Compilers, casting between chars and ints, can arrive at the situation
whereby...
if (SvUTF8(sv)) { ... }
... and ...
bool utf8 = SvUTF8(sv);
if (utf8) { ... }
... don't behave in the same way. Steve Peters revived interest in the
bug, by asking whether returning a U32 value instead of a bool would
fix matters.
http://xrl.us/hmtr
In Brief
Rajarshi Das found a problem with Encode on EBCDIC. Dan Kogai noted
that the code is not well tested on EBCDIC. There was another
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Fri, Sep 16, 2005 at 02:28:20PM -0700, Randal L. Schwartz wrote: Nicholas == Nicholas Clark [EMAIL PROTECTED] writes: Nicholas And the bug report for the distributor of the perl you Nicholas installed would be why isn't it installing the XS version Nicholas of a core module? ? What do you mean distributor of the perl you installed? Joking, right? I've said maintperl a few times already. No, I'm not, in as much as I don't understand why the perl you installed only had a pure perl List::Utils I agree with the Storable failure being a bug. But I also want to understand the List::Utils part Did I miss the reason for this in an earlier message? Nicholas Clark
[perl #37183] core dump, use encoding 'utf8' and example re
# New Ticket Created by Jim McKim # Please include the string: [perl #37183] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37183 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.7. - [Please enter your report here] This script (three lines, below) caused perl to fault, apparently during a memory allocation operation. The first character in the re is U+00a8. #!/usr/local/bin/perl -w use encoding 'utf8'; my $x = /¨\.\//; As perl aborts, I usually see the message: *** glibc detected *** corrupted double-linked list: 0x08134618 *** gdb on the core dump reports: #0 0xe410 in ?? () #1 0xbfffeafc in ?? () #2 0x0006 in ?? () #3 0x2a2b in ?? () #4 0xb7e576e5 in raise () from /lib/tls/libc.so.6 #5 0xb7e59049 in abort () from /lib/tls/libc.so.6 #6 0xb7e8b7ba in __fsetlocking () from /lib/tls/libc.so.6 #7 0xb7e91717 in malloc_usable_size () from /lib/tls/libc.so.6 #8 0xb7e9268e in free () from /lib/tls/libc.so.6 #9 0xb7e94411 in malloc () from /lib/tls/libc.so.6 #10 0x0809ee55 in Perl_safesysmalloc () #11 0x08104d84 in PerlIOBuf_get_base () #12 0x08104b0d in PerlIOBuf_write () #13 0x080a00b0 in Perl_write_to_stderr () #14 0x080a0b1c in Perl_vwarn () #15 0x080a0d7e in Perl_vwarner () #16 0x080a0e0d in Perl_warner () #17 0x080b5537 in Perl_report_uninit () #18 0x080bddd1 in Perl_sv_2pv_flags () #19 0x080b0160 in Perl_pp_match () #20 0x080ad2ed in Perl_runops_standard () #21 0x080625d5 in perl_run () #22 0x0805e602 in main () [Please do not change anything below this line] - --- Flags: category=core severity=medium --- Site configuration information for perl v5.8.7: Configured by mckim at Wed Aug 31 15:22:51 EDT 2005. Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=linux, osvers=2.6.11-6mdk, archname=i686-linux uname='linux bandersnatch.grc.nasa.gov 2.6.11-6mdk #1 tue mar 22 16:04:32 cet 2005 i686 intel(r) pentium(r) 4 cpu 3.60ghz unknown gnulinux ' config_args='' 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 -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)', 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 -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.7: /usr/local/lib/perl5/5.8.7/i686-linux /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/i686-linux /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl . --- Environment for perl v5.8.7: HOME=/home/mckim LANG=en_US LANGUAGE=en_US:en LC_ADDRESS=en_US LC_COLLATE=en_US LC_CTYPE=en_US LC_IDENTIFICATION=en_US LC_MEASUREMENT=en_US LC_MESSAGES=en_US LC_MONETARY=en_US LC_NAME=en_US LC_NUMERIC=en_US LC_PAPER=en_US LC_SOURCED=1 LC_TELEPHONE=en_US LC_TIME=en_US LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/mckim/bin:/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/usr/lib/jdk-1.4.2_07/bin:/opt/jdk1.5.0_01/bin:/opt/netbeans-4.0/bin/:/usr/local/kde/bin:/usr/lib/ssh:/usr/lib/jdk-1.4.2_07/bin PERL_BADLANG (unset) SHELL=/bin/bash
[perl #37186] push returning total number elements instead of number new elements
# New Ticket Created by David Ljung Madison # Please include the string: [perl #37186] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37186 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.4. - [Please enter your report here] The return value for push is the total number of elements in the array. According to the docs, push: Returns the new number of elements in the array. Example code: my @j = (1..100); print push(@j,42), \n; Should display 1, but it displays 101. [Please do not change anything below this line] - --- Flags: category=core severity=medium --- Site configuration information for perl v5.8.4: Configured by Debian Project at Tue Mar 8 20:31:23 EST 2005. Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=linux, osvers=2.4.27-ti1211, archname=i386-linux-thread-multi uname='linux kosh 2.4.27-ti1211 #1 sun sep 19 18:17:45 est 2004 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.4 -Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-9)', 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=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.4 gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.4: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . --- Environment for perl v5.8.4: HOME=/home/dave LANG=C LANGUAGE (unset) LC_ALL=C LC_CTYPE= LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/home/dave/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/sbin:/WWW/web/MarginalHacks.com/bin PERL_BADLANG (unset) SHELL=/usr/bin/tcsh
RE: [perl #37186] push returning total number elements instead of number new elements
Returns the new number of elements in the array. I believe that should be interpreted the new (total) number of elements in the array rather than the new number of elements added to the array. -- Charles DeRykus
Re: [perl #37186] push returning total number elements instead of number new elements
On Fri, Sep 16, 2005 at 01:38:41PM -0700, David Ljung Madison wrote: The return value for push is the total number of elements in the array. According to the docs, push: Returns the new number of elements in the array. Example code: my @j = (1..100); print push(@j,42), \n; Should display 1, but it displays 101. push returns the new (number of elements) in the array, not the number of (new elements) in the array. Ronald
Re: [perl #37186] push returning total number elements instead of number new elements
On Sep 16, 2005, at 4:38 PM, David Ljung Madison (via RT) wrote: The return value for push is the total number of elements in the array. According to the docs, push: Returns the new number of elements in the array. Right -- the new number of elements, as opposed to the number of new elements. Example code: my @j = (1..100); print push(@j,42), \n; Should display 1, but it displays 101. My reading of the docs you quoted is consistent with the exhibited behavior. The old number of elements is 100 and the new number of elements is 101. Josh
Re: Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
John E. Malmberg wrote: Paul Marquess wrote: Editing 16oneshot.t to remove the './' from the $tmpdir and re-running the script makes it pass all 2544 tests. It appears something is wrong with glob() on VMS. glob(./tmpdir/a*.tmp) is returning t/tmpdir/a1.tmp when the current working directory is t. glob(tmpdir/a*.tmp) is returning tmpdir/a1.tmp as expected. I will need to look at adding the case of ./dir/* to the glob tests. I suspect that it has been broken for a while. I will look at this as I get into updating the file system related functions. This gets me to understanding what is causing all the current failures on blead-perl for VMS. -John [EMAIL PROTECTED] Personal Opinion Only
RE: Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
From: John E. Malmberg [mailto:[EMAIL PROTECTED] John E. Malmberg wrote: Paul Marquess wrote: Editing 16oneshot.t to remove the './' from the $tmpdir and re-running the script makes it pass all 2544 tests. I've removed the leading './' from the all the $tmpdir directory variables in 16oneshot.t It appears something is wrong with glob() on VMS. glob(./tmpdir/a*.tmp) is returning t/tmpdir/a1.tmp when the current working directory is t. glob(tmpdir/a*.tmp) is returning tmpdir/a1.tmp as expected. I will need to look at adding the case of ./dir/* to the glob tests. I suspect that it has been broken for a while. I will look at this as I get into updating the file system related functions. This gets me to understanding what is causing all the current failures on blead-perl for VMS. According to your previous post that means that the only thing left failing is one test in globmapper.t ext/Compress/Zlib/t/globmapper.t 68 of 69 ok I assume the failing test is the one that uses the './' directory prefix? - I'm using that prefix to try to make VMS glob think it should work in UNIX mode so that I can test file globs that include character classes. Paul
Re: odd corruption seen previously with hashes on VMS
Nicholas Clark wrote: With respect to the odd corruption seen previously on VMS, but now no longer visible, might this patch have had something to do with it? I believe that the change I made was correct. If so, then because it removed a large over- allocation, it will show up any other code that failed to allocate sufficient space, hence revealing latent bugs elsewhere. Maybe, but I really could not say for sure. Now that blead on VMS seems to be somewhat stable, I want to start putting in support for the ODS-5 file system and the UNIX compatibility mode of the CRTL. And that will likely result in many changes to VMS::Filespec :-) -John [EMAIL PROTECTED] Personal Opinion Only
Re: Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
At 7:36 PM -0400 9/16/05, John E. Malmberg wrote: John E. Malmberg wrote: It appears something is wrong with glob() on VMS. glob(./tmpdir/a*.tmp) is returning t/tmpdir/a1.tmp when the current working directory is t. glob(tmpdir/a*.tmp) is returning tmpdir/a1.tmp as expected. I will need to look at adding the case of ./dir/* to the glob tests. I suspect that it has been broken for a while. I will look at this as I get into updating the file system related functions. There are certainly limitations to the home-grown glob() on VMS. It basically just converts the '?' wildcard to '%' and calls LIB$FIND_FILE. See Perl_start_glob() in doio.c. Also relevant is trim_unixpath() in [.vms]vms.c, which makes a very modest attempt to pick apart the pieces of a Unix path spec containing wildcards and put them back together again. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: lib/test/simple/t/create.t help with VMS issue needed.
John E. Malmberg wrote: Michael G Schwern wrote: On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote: I can change the test to write to a tied filehandle or I can make sure the new Test::Builder object which outputs to some_file is destroyed before I read from some_file. The later has the nice side effect of testing that destroying a Test::Builder object closes any open filehandles. Try the attached patch and let me know. The patch seems to work fine on my system, and I do not even need to use the feature logical for sharing the file. EAGLE mcr []Perl. -I[-.lib] [-.lib.test.simple.t]create.t 1..8 ok 1 - The object isa Test::Builder ok 2 - create does not interfere with -builder ok 3 -does not interfere with -new ok 4 - The object isa Test::Builder ok 5 - Test::Builder-create makes a new object ok 6 - Changing output() of new TB doesn't interfere with singleton ok 7 ok 8 Anything happening with this for the 5.8.8 timeframe? -John [EMAIL PROTECTED] Personal Opinion Only
Re: Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
Paul Marquess wrote: According to your previous post that means that the only thing left failing is one test in globmapper.t ext/Compress/Zlib/t/globmapper.t 68 of 69 ok That was a typo, there are only 68 tests in globmapper and they are all working for me on VMS now. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
Craig A. Berry wrote: At 7:36 PM -0400 9/16/05, John E. Malmberg wrote: John E. Malmberg wrote: It appears something is wrong with glob() on VMS. glob(./tmpdir/a*.tmp) is returning t/tmpdir/a1.tmp when the current working directory is t. glob(tmpdir/a*.tmp) is returning tmpdir/a1.tmp as expected. I will need to look at adding the case of ./dir/* to the glob tests. I suspect that it has been broken for a while. I will look at this as I get into updating the file system related functions. There are certainly limitations to the home-grown glob() on VMS. It basically just converts the '?' wildcard to '%' and calls LIB$FIND_FILE. See Perl_start_glob() in doio.c. Also relevant is trim_unixpath() in [.vms]vms.c, which makes a very modest attempt to pick apart the pieces of a Unix path spec containing wildcards and put them back together again. As of OpenVMS 7.3-2, the C Library provides a glob() function, so it may be better to use it on Perls built on that release or later rather than trying to fix it a different way. -John [EMAIL PROTECTED] Personal Opinion Only
Re: This Week on perl5-porters (5-11 September 2005)
David Landgren wrote: This Week on perl5-porters (5-11 September 2005) The Return of the perl5-porters Summaries This summary was written by David Landgren. Nicely done!... I did miss these! -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: This Week on perl5-porters (5-11 September 2005)
On Sep 16, 2005, at 4:31 PM, David Landgren wrote: This Week on perl5-porters (5-11 September 2005) The Return of the perl5-porters Summaries Hooray! Thanks for doing! xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: This Week on perl5-porters (5-11 September 2005)
On Sep 17, 2005, at 12:55 , Andy Lester wrote: On Sep 16, 2005, at 4:31 PM, David Landgren wrote: This Week on perl5-porters (5-11 September 2005) The Return of the perl5-porters Summaries Hooray! Thanks for doing! Ditto. Thank you! Dan the Perl5 Porter
