Re: [perl #36075] Adding malloc_size/malloc_good_size to Configure
On Sat, 10 Sep 2005 17:59:00 -0700, Steve Peters via RT [EMAIL PROTECTED] wrote: [nicholas - Wed Jun 01 08:09:31 2005]: This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.9.3. - [Please enter your report here] Darwin provides 2 extra malloc() functions: The malloc_size() function returns the size of the memory block that backs the allocation pointed to by ptr. The memory block size is always at least as large as the allocation it backs, and may be larger. The malloc_good_size() function rounds size up to a value that the allo- cator implementation can allocate without adding any padding and returns that rounded up value. It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size It would be useful to probe for them, because if they either are found it would allow efficiency savings in various places. Specifically when buffers allocated for SvPVX() we could set SvLEN() to the true maximum length, and AV storage extension could be tuned to use all the memory malloc() actually gave us. Adding the detection for these function is pretty simple, and Configure doesn't need to do anything more that standard libc scanning. I'm guessing it would be easy to add to Metaconfig to check. The following patches can do it for playing with, but don't apply to p4. Merijn, do you need any more information for the Metaconfig changes? --- Configure.old Tue Sep 6 09:38:43 2005 +++ Configure Sat Sep 10 19:44:50 2005 @@ -550,6 +550,8 @@ d_lseekproto='' d_lstat='' d_madvise='' +d_malloc_size='' +d_malloc_good_size='' d_mblen='' d_mbstowcs='' d_mbtowc='' @@ -14247,6 +14249,14 @@ set madvise d_madvise eval $inlibc +: see if malloc_size exists +set malloc_size d_malloc_size +eval $inlibc + +: see if malloc_size_good exists +set malloc_good_size d_malloc_good_size +eval $inlibc + : see if mblen exists set mblen d_mblen eval $inlibc @@ -21112,6 +21122,8 @@ d_lseekproto='$d_lseekproto' d_lstat='$d_lstat' d_madvise='$d_madvise' +d_malloc_size='$d_malloc_size' +d_malloc_size_good='$d_malloc_size_good' d_mblen='$d_mblen' d_mbstowcs='$d_mbstowcs' d_mbtowc='$d_mbtowc' --- config_h.SH.old Tue Jun 21 14:56:18 2005 +++ config_h.SH Sat Sep 10 19:22:05 2005 @@ -3889,6 +3889,18 @@ */ #$d_libm_lib_version LIBM_LIB_VERSION /**/ +/* HAS_MALLOC_SIZE + * This symbol, if defined, indicates that the malloc_size + * routine is available for use. + */ +#$d_malloc_size HAS_MALLOC_SIZE /**/ + +/* HAS_MALLOC_GOOD_SIZE + * This symbol, if defined, indicates that the malloc_good_size + * routine is available for use. + */ +#$d_malloc_good_size HAS_MALLOC_GOOD_SIZE /**/ + /* HAS_NL_LANGINFO: * This symbol, if defined, indicates that the nl_langinfo routine is * available to return local data. You will also need langinfo.h I'll see. Looks complete. I'll also have to add this to handy.h, unless you have a real location where these new `things' are referenced. -- 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: [perl #36075] Adding malloc_size/malloc_good_size to Configure
On Mon, Sep 12, 2005 at 08:37:27AM +0200, H.Merijn Brand wrote: On Sat, 10 Sep 2005 17:59:00 -0700, Steve Peters via RT [EMAIL PROTECTED] wrote: [nicholas - Wed Jun 01 08:09:31 2005]: It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size Adding the detection for these function is pretty simple, and Configure doesn't need to do anything more that standard libc scanning. I'm guessing it would be easy to add to Metaconfig to check. The following patches can do it for playing with, but don't apply to p4. --- config_h.SH.old Tue Jun 21 14:56:18 2005 +++ config_h.SH Sat Sep 10 19:22:05 2005 @@ -3889,6 +3889,18 @@ */ #$d_libm_lib_version LIBM_LIB_VERSION /**/ +/* HAS_MALLOC_SIZE + * This symbol, if defined, indicates that the malloc_size + * routine is available for use. + */ +#$d_malloc_size HAS_MALLOC_SIZE /**/ + +/* HAS_MALLOC_GOOD_SIZE + * This symbol, if defined, indicates that the malloc_good_size + * routine is available for use. + */ +#$d_malloc_good_size HAS_MALLOC_GOOD_SIZE /**/ + /* HAS_NL_LANGINFO: * This symbol, if defined, indicates that the nl_langinfo routine is * available to return local data. You will also need langinfo.h I'll see. Looks complete. I'll also have to add this to handy.h, unless you have a real location where these new `things' are referenced. Whilst I realise that we can only probe for names we know, as is this doesn't suggest a framework for how to cope with the functions having a different name. Do we define 2 names for them that are actually macros in handy.h, that use malloc_size()/malloced_size() and malloc_good_size()/undef ? Nicholas Clark
RE: Encode on EBCDIC patch( Doesn't Work)
Thanks, that ouput looks a bit strange. Can you get me the results from all
the DBM_Filter tests please? I need to see if the problems you are getting
are encoding specific or if the other filters have the same problem.
On Unix this will do the trick
./TEST -v ../lib/DBM_Filter/t/01error.t
./TEST -v ../lib/DBM_Filter/t/02core.t
./TEST -v ../lib/DBM_Filter/t/compress.t
./TEST -v ../lib/DBM_Filter/t/int32.t
./TEST -v ../lib/DBM_Filter/t/null.t
./TEST -v ../lib/DBM_Filter/t/utf8.t
./TEST -v ../lib/DBM_Filter/t/
cheers
Paul
_
From: Sastry [mailto:[EMAIL PROTECTED]
Sent: 12 September 2005 06:28
To: [EMAIL PROTECTED]; Dan Kogai
Cc: Perl Porters 5
Subject: Re: Encode on EBCDIC patch( Doesn't Work)
Hi Paul
Here is the verbose output of the test
ok 1 - use DBM_Filter;
ok 2 - use SDBM_File;
ok 3 - use Fcntl;
ok 4 - use charnames;
ok 5 - tied to SDBM_File
ok 6 - push an illigal filter
ok 7 - push an 'encode' filter (default to utf-8)
ok 8 - StoreData called from lib/DBM_Filter/t/encode.t, line 47
ok 9 - Store Data is a hash reference
ok 10 - Storing to tied hash
ok 11 - VerifyData called from lib/DBM_Filter/t/encode.t, line 57
ok 12 - Expected data is a hash reference
ok 13 - Verifying a tied hash
not ok 14 - Expected == Actual
# Failed test (/u/isldev3/perl-5.8.6/lib/dbm_filter_util.pl at line 48)
Wide character in print at /u/isldev3/perl-5.8.6/lib/Test/Builder.pm line
910.
# Expected does not match actual
# No Match from Expected:
# 'beta' = '©ß'
# 'alpha' = '©ì'
# '©Â' = 'gamma'
#
ok 15 - pop the 'utf8' filter
ok 16 - push an 'encode' filter (specify iso-8859-16)
ok 17 - StoreData called from lib/DBM_Filter/t/encode.t, line 72
ok 18 - Store Data is a hash reference
ok 19 - Storing to tied hash
ok 20 - untie without inner references
ok 21 - tied to SDBM_File
ok 22 - VerifyData called from lib/DBM_Filter/t/encode.t, line 90
ok 23 - Expected data is a hash reference
ok 24 - Verifying a tied hash
not ok 25 - Expected == Actual
# Failed test (/u/isldev3/perl-5.8.6/lib/dbm_filter_util.pl at line 48)
# Expected does not match actual
# No Match from Expected:
# 'beta' = 'ó¥'
# 'ó·' = 'gamma'
# 'alpha' = 'ó£'
# 'euro' = 'u'
#
# No Match from Actual:
# '/Ä,' = 'u'
# 'ea' = '©ß'
# '©Â' = 'am'
# 'lh' = '©ì'
#
ok 26 - untie without inner references
# Looks like you failed 2 tests of 26.
On 9/9/05, Paul Marquess [EMAIL PROTECTED] wrote:
Are you saying that the 4 byte string euro(ASCII hex 65 75 72 6F) is being
stored as '/Ä,' (hex 2F C4 3E 2C) ?
The value I am getting on EBCDIC is \x61\x63\x6E\x6B which has no relation
to iso-8859-16 codepoints! Do you have any thoughts as why this is
happening?
Can you post the verbose output from running the lib/DBM_Filter/t/encode.t
test harness please?
See the output above
Not sure how different EBDCIC platforms are from Unix-land, but this is how
you would run it on a Linux/Unix box.
Running the test is similar
$ cd t
$ ./TEST -v ../lib/DBM_Filter/t/encode.t
Paul
-Original Message-
From: Sastry [mailto: [EMAIL PROTECTED]
Sent: 08 September 2005 14:15
To: Dan Kogai
Cc: Perl Porters 5
Subject: Re: Encode on EBCDIC patch( Doesn't Work)
Hi Dan
The patch you had provided calls
$_ebcdic_coder-decode($str);
and subsequenly calls my $octets = $enc-encode($string,$check);
Do you think it is how it is supposed to call on EBCDIC platform? Seems
like this is a work around
But there is another test case(lib/DBM_Filter/t/encode.t) in the test
suite
that fails because of this encoding module
Here is the snippet of that test case
eval { $db1-Filter_Push('encode' = 'iso-8859-16') };
is $@, '', push an 'encode' filter (specify iso-8859-16) ;
use charnames qw{:full};
StoreData(\%h1,
{
'euro' = \N{EURO SIGN},
});
VerifyData(\%h2,
{
'euro' = \xA4,
});
The 'euro' gets stored as /Ä,
instead of the 'euro' itself.
Please check if there is a work round for this too or any pointers in the
source code where there could be a fix for it!
-Sastry
On 8/24/05, Dan Kogai [EMAIL PROTECTED] wrote:
Sastry and EBCDIC porters,
On Aug 24, 2005, at 21:30 , Dan Kogai wrote:
+ sub _utf8_ebcdic($){
+ my $str = shift; # UTF-8
+ $str = # UTF-EBCDIC
+ $_ebcdic_coder-encode($str);
+ _utf8_on($str); # Dirty Trick
+ return $str;
I'm not sure if this part works as advertised. The yet another patch
below tries the different approach.
The problem is that I know so little of UTF-EBCDIC and its
implementation. I feel like building a ship in the bottle in the
dark
Dan the Encode Maintainer
===
RCS file: Encode.pm http://Encode.pm,v
retrieving revision 2.11
diff -u -r2.11 Encode.pm http://Encode.pm
--- Encode.pm http://Encode.pm
Re: [perl #36075] Adding malloc_size/malloc_good_size to Configure
On Mon, 12 Sep 2005 10:36:55 +0100, Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Sep 12, 2005 at 08:37:27AM +0200, H.Merijn Brand wrote: On Sat, 10 Sep 2005 17:59:00 -0700, Steve Peters via RT [EMAIL PROTECTED] wrote: [nicholas - Wed Jun 01 08:09:31 2005]: It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size Adding the detection for these function is pretty simple, and Configure doesn't need to do anything more that standard libc scanning. I'm guessing it would be easy to add to Metaconfig to check. The following patches can do it for playing with, but don't apply to p4. --- config_h.SH.old Tue Jun 21 14:56:18 2005 +++ config_h.SH Sat Sep 10 19:22:05 2005 @@ -3889,6 +3889,18 @@ */ #$d_libm_lib_version LIBM_LIB_VERSION /**/ +/* HAS_MALLOC_SIZE + * This symbol, if defined, indicates that the malloc_size + * routine is available for use. + */ +#$d_malloc_size HAS_MALLOC_SIZE /**/ + +/* HAS_MALLOC_GOOD_SIZE + * This symbol, if defined, indicates that the malloc_good_size + * routine is available for use. + */ +#$d_malloc_good_size HAS_MALLOC_GOOD_SIZE /**/ + /* HAS_NL_LANGINFO: * This symbol, if defined, indicates that the nl_langinfo routine is * available to return local data. You will also need langinfo.h I'll see. Looks complete. I'll also have to add this to handy.h, unless you have a real location where these new `things' are referenced. Whilst I realise that we can only probe for names we know, as is this doesn't suggest a framework for how to cope with the functions having a different name. Do we define 2 names for them that are actually macros in handy.h, that use malloc_size()/malloced_size() and malloc_good_size()/undef ? That's beyond my scope, but if you can come up with such a scheme, I can incorporate that in the base patch, instead of the need to patch handy.h twice. I *need* a ref to it in order to have the new symbols being included in the generated files, unless ... (/me starts experimenting with another scheme ...) -- 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: [perl #32884] API doc for SvUTF8
Steve Peters via RT wrote: Acutally, everything looking a return value from SvFLAGS(sv) should be looking for a U32. Since I'd like to automate these changes as much as possible, how does the following look? Fine, but probably all other docs for SvFLAGS bit tests need the same change, no ? --- sv.h.oldSat Sep 10 20:30:54 2005 +++ sv.hSat Sep 10 20:30:47 2005 @@ -703,8 +703,8 @@ SvFLAGS(sv) |= (SVf_NOK|SVp_NOK)) /* -=for apidoc Am|bool|SvUTF8|SV* sv -Returns a boolean indicating whether the SV contains UTF-8 encoded data. +=for apidoc Am|U32l|SvUTF8|SV* sv +Returns a U32 value indicating whether the SV contains UTF-8 encoded data. =for apidoc Am|void|SvUTF8_on|SV *sv Turn on the UTF-8 status of an SV (the data is not changed, just the flag). There will probably need to be some changes in the core as well where any of Sv*OK-like macros are on the right side of an assignment.
Re: ZLIB 2.0 / Blead 25366 on VMS
In message [EMAIL PROTECTED] Paul Marquess [EMAIL PROTECTED] wrote: Thanks John. I've CCed Tom Hughes for the IO:Zlib results. The external gzip support in IO::Zlib is all Jarkko's work and nothing to do with me I'm afraid. The external.t test script does have this comment at the top however: # Test this only iff we have an executable /usr/bin/gzip # AND we have /usr/bin in our PATH # AND we have a useable /usr/bin directory. # This limits the testing to UNIX-like # systems but that should be enough. That is a much stronger constraint than the IO::Zlib module seems to make however, as that just tries to run gzip as a command using open. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
[perl #37144] Data crash when executing substitution on the Perl debugger
# New Ticket Created by Hiroshi MANABE
# Please include the string: [perl #37144]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37144
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.35 running under perl v5.8.7.
# Here is a sample code for what's happening
for ($i = 0; $i 10; ++$i) {
$temp = \x{100}X; # X is an arbitrary character; \x{100} is an arbitrary
character over \x{100}
$temp =~ s/[^X]+//; # data crash on the second (or so) iteration when run on
the debugger
# or sometimes the Perl itself crashes;
# or sometimes it simply do nothing (no replacement)
# It's quite unpredictable.
}
---
Flags:
category=core
severity=critical
---
Site configuration information for perl v5.8.7:
Configured by builder at Mon Jun 6 13:36:05 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
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='cl', ccflags
='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT -DBUILT_BY_ACTIVESTATE -DNO_HASH_SEED -DUSE_
SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='12.00.8804', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-libpath:I:\Perl\lib\CORE -machine:x86'
libpth=\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib
odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf
-libpath:I:\Perl\lib\CORE -machine:x86'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
# if !defined(PERL_DARWIN)
Iin_load_module moved for compatibility with build 806
# endif
# if defined(__hpux)
Avoid signal flag SA_RESTART for older versions of HP-UX
# endif
PerlEx hacks for CGI::Carp
Less verbose ExtUtils::Install and Pod::Find
instmodsh upgraded from ExtUtils-MakeMaker-6.25
24699 ICMP_UNREACHABLE handling in Net::Ping
21540 Fix backward-compatibility issues in if.pm
---
@INC for perl v5.8.7:
I:/Perl/lib
I:/Perl/site/lib
.
---
Environment for perl v5.8.7:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=I:\Perl\bin\;i:\program
files\imagemagick-6.0.7-q16;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;I:\perl\bin;I:\jperl\5.00503\bin\MSWin32-x86;E:\cygwin
\bin;C:\Fonix\FRE\Win32\Lib;C:\gs\gs8.14\bin;C:\gs\gs8.14\lib;C:\Program
Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program
Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft
Visual Studio\Common\Tools;C:\Program Files\Microsoft
Visual Studio\VC98\bin;I:\EmEditor3;I:\Program Files\kakasi\bin;
PERL_BADLANG (unset)
SHELL (unset)
Re: [perl #32884] API doc for SvUTF8
On Mon, Sep 12, 2005 at 12:41:23PM +0200, Rafael Garcia-Suarez wrote: Steve Peters via RT wrote: Acutally, everything looking a return value from SvFLAGS(sv) should be looking for a U32. Since I'd like to automate these changes as much as possible, how does the following look? Fine, but probably all other docs for SvFLAGS bit tests need the same change, no ? Yes, they do. They have nearly identical API doc listings, though, so this is just the sample change.
Re: [perl #37133] perl crash related to threads and lock()
On Sat, Sep 10, 2005 at 01:58:33PM -0700, sgromoll @ grad. physics. sunysb. edu
wrote:
When perl crashes it gives one of the following errors, depending on the
platform:
==
panic: destruct destroyed thread [EMAIL PROTECTED]@l0@ during global
destruction.
Segmentation fault
I get this. So I an it under valgrind. I got something stranger:
$ PERL_CORE=1 valgrind --db-attach=yes --db-command='gdb %f %p'
--num-callers=20 --tool=memcheck ./perl -Ilib bug37133==22320== Memcheck, a
memory error detector for x86-linux.==22320== Copyright (C) 2002-2004, and GNU
GPL'd, by Julian Seward.==22320== Using valgrind-2.1.1, a program supervision
framework for x86-linux.==22320== Copyright (C) 2000-2004, and GNU GPL'd, by
Julian Seward.==22320== For more details, rerun with: -v==22320==
vg_alloc_ThreadState: no free slots available
Increase VG_N_THREADS, rebuild and try again.
valgrind: the `impossible' happened:
VG_N_THREADS is too low
Basic block ctr is approximately 12330
==22320==at 0xB802A070: vgPlain_core_panic (in /usr/lib/valgrind/stage2)
==22320==by 0xB802A06F: panic (in /usr/lib/valgrind/stage2)
==22320==by 0xB802A084: vgPlain_core_panic (in /usr/lib/valgrind/stage2)
==22320==by 0xB800CB7D: vg_alloc_ThreadState (in /usr/lib/valgrind/stage2)
==22320==by 0xB800F514: do__apply_in_new_thread (in
/usr/lib/valgrind/stage2)
==22320==by 0xB8011A03: do_client_request (in /usr/lib/valgrind/stage2)
==22320==by 0xB800DF33: vgPlain_scheduler (in /usr/lib/valgrind/stage2)
==22320==by 0xB802567B: main (in /usr/lib/valgrind/stage2)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==22320==at 0x3C0A3061: pthread_create (vg_libpthread.c:927)
==22320==by 0x3C0260D4: Perl_ithread_create (threads.xs:521)
==22320==by 0x3C0268F3: XS_threads_new (threads.xs:686)
==22320==by 0x80FA247: Perl_pp_entersub (pp_hot.c:2788)
==22320==by 0x80D1C7A: Perl_runops_debug (dump.c:1597)
==22320==by 0x80673A4: S_run_body (perl.c:2274)
==22320==by 0x8066DAA: perl_run (perl.c:2201)
==22320==by 0x806061D: main (perlmain.c:103)
Thread 2: status = WaitJoiner, associated_mx = 0x0, associated_cv = 0x0
==22320==at 0x3C0A2BD0: thread_exit_wrapper (vg_libpthread.c:732)
==22320==by 0x3C0A2D7E: thread_wrapper (vg_libpthread.c:838)
==22320==by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 3: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320==at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320==by 0x3C025819: Perl_ithread_run (threads.xs:326)
==22320==by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320==by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 4: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320==at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320==by 0x3C025819: Perl_ithread_run (threads.xs:326)
==22320==by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320==by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 5: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320==at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320==by 0x3C0249AD: Perl_ithread_destruct (threads.xs:105)
==22320==by 0x3C0257CB: Perl_ithread_run (threads.xs:322)
==22320==by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320==by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
[and so on]
Thread 99: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320==at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320==by 0x3C0249AD: Perl_ithread_destruct (threads.xs:105)
==22320==by 0x3C0257CB: Perl_ithread_run (threads.xs:322)
==22320==by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320==by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: valgrind.kde.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
Am I right in thinking that this suggests that the threads implementation has a
deadlock of some sort here?
Even taking out the obvious deadlock doesn't make the bug go away:
//depot/perl/ext/threads/threads.xs#86 -
/home/nick/p4perl/perl/ext/threads/threads.xs
--- /tmp/tmp.23174.02005-09-12 12:07:37.0 +0100
+++ /home/nick/p4perl/perl/ext/threads/threads.xs 2005-09-12
12:03:23.0 +0100
@@ -96,6 +96,7 @@ Perl_ithread_destruct (pTHX_ ithread* th
PerlInterpreter *freeperl = NULL;
MUTEX_LOCK(thread-mutex);
if (!thread-next) {
+ MUTEX_UNLOCK(thread-mutex);
Perl_croak(aTHX_ panic: destruct destroyed thread %p (%s),thread,
why);
}
if (thread-count != 0) {
The alternative crash
Re: [perl #37110] compiling perl 5.8.7 for win32 using free microsoft tools
Hi Steve, Many thanks for your prompt answer! Steve Hay via RT wrote: Are you sure that you installed the correct SDK components? I believe that the Core and MDAC components are all that is required, but perhaps something else is too. Try installing other components if you haven't already installed them all and let us know if some other component provides the missing files. After installing ALL components the src files are still missing :-( Note that the PSDK is a constantly moving target, and so are the links to it. (I should probably update the instructions to simply direct users to the MS download website and tell them what to search for.) The latest version, suitable for XP and 2003, is the 2003 SP1 version currently available here: http://www.microsoft.com/downloads/details.aspx?familyid=EBA0128F-A770-45F1-86F3-7AB010B398A3displaylang=en I have this installed at the moment, and it definitely contains the required src files. (I'm surprised that you say the XPSP2 version doesn't, because I thought I'd successfully used that one in the past myself.) Thanks for this very useful hint. I was not aware that the Windows® Server 2003 SP1 Platform SDK can be used with WinXP (SP2). I have unfortunately not seen the remark on the downloadpage: This edition of the SDK replaces the previous SDKs for Windows XP SP2 and Windows Server 2003 and can be used to develop applications for those platforms. I think it would be a good idea to remove the link to PSDK for Win XPSP2 within the README.win32 file, because this PSDK seems really not to work and for Win XPSP2 mislead that this PSDK is the one and only suitable for WinXP (SP2). --- The Windows® Server 2003 SP1 PSDK indeed provides the src files within the CORE component. Unfortunately the compilation of perl 5.8.7 aborts because of another missing file: delayimp.lib See below the error message: ... link -dll -def:perldll.def -base:0x2800 -out:..\perl58.dll @C:\DOKU E~1\WERNER~1\LOKALE~1\Temp\nm17F.tmp LINK : fatal error LNK1181: cannot open input file 'delayimp.lib' NMAKE : fatal error U1077: 'link' : return code '0x49d' Stop. FYI, I have installed all components of Windows® Server 2003 SP1 PSDK on a new vmware machine and searched for the missing file. There is just a version of delayimp.lib in \Lib\ia64 and \Lib\AMD64 but no one in \Lib itself. At last I was able to built perl 5.8.7 with a borrowed delayimp.lib from a second vmware machine with an installed visual studio 2003. Do you know a free source of supply for this missing file? Many thanks in advacnce. Best regards, Werner
Re: Encode on EBCDIC patch( Doesn't Work)
Hi Paul
Here is the verbose output of the test
ok 1 - use DBM_Filter;
ok 2 - use SDBM_File;
ok 3 - use Fcntl;
ok 4 - use charnames;
ok 5 - tied to SDBM_File
ok 6 - push an illigal filter
ok 7 - push an 'encode' filter (default to utf-8)
ok 8 - StoreData called from lib/DBM_Filter/t/encode.t, line 47
ok 9 - Store Data is a hash reference
ok 10 - Storing to tied hash
ok 11 - VerifyData called from lib/DBM_Filter/t/encode.t, line 57
ok 12 - Expected data is a hash reference
ok 13 - Verifying a tied hash
not ok 14 - Expected == Actual
# Failed test (/u/isldev3/perl-5.8.6/lib/dbm_filter_util.pl at line 48)
Wide character in print at /u/isldev3/perl-5.8.6/lib/Test/Builder.pm line
910.
# Expected does not match actual
# No Match from Expected:
# 'beta' = '(c)ß'
# 'alpha' = '(c)ì'
# '(c)Â' = 'gamma'
#
ok 15 - pop the 'utf8' filter
ok 16 - push an 'encode' filter (specify iso-8859-16)
ok 17 - StoreData called from lib/DBM_Filter/t/encode.t, line 72
ok 18 - Store Data is a hash reference
ok 19 - Storing to tied hash
ok 20 - untie without inner references
ok 21 - tied to SDBM_File
ok 22 - VerifyData called from lib/DBM_Filter/t/encode.t, line 90
ok 23 - Expected data is a hash reference
ok 24 - Verifying a tied hash
not ok 25 - Expected == Actual
# Failed test (/u/isldev3/perl-5.8.6/lib/dbm_filter_util.pl at line 48)
# Expected does not match actual
# No Match from Expected:
# 'beta' = 'ó¥'
# 'ó·' = 'gamma'
# 'alpha' = 'ó£'
# 'euro' = 'u'
#
# No Match from Actual:
# '/Ä,' = 'u'
# 'ea' = '(c)ß'
# '(c)Â' = 'am'
# 'lh' = '(c)ì'
#
ok 26 - untie without inner references
# Looks like you failed 2 tests of 26.
On 9/9/05, Paul Marquess [EMAIL PROTECTED] wrote:
Are you saying that the 4 byte string euro(ASCII hex 65 75 72 6F) is
being
stored as '/Ä,' (hex 2F C4 3E 2C) ?
The value I am getting on EBCDIC is \x61\x63\x6E\x6B which has no
relation to iso-8859-16 codepoints! Do you have any thoughts as why this is
happening?
Can you post the verbose output from running the lib/DBM_Filter/t/encode.t
test harness please?
See the output above
Not sure how different EBDCIC platforms are from Unix-land, but this is how
you would run it on a Linux/Unix box.
Running the test is similar
$ cd t
$ ./TEST -v ../lib/DBM_Filter/t/encode.t
Paul
-Original Message-
From: Sastry [mailto:[EMAIL PROTECTED]
Sent: 08 September 2005 14:15
To: Dan Kogai
Cc: Perl Porters 5
Subject: Re: Encode on EBCDIC patch( Doesn't Work)
Hi Dan
The patch you had provided calls
$_ebcdic_coder-decode($str);
and subsequenly calls my $octets = $enc-encode($string,$check);
Do you think it is how it is supposed to call on EBCDIC platform? Seems
like this is a work around
But there is another test case(lib/DBM_Filter/t/encode.t) in the test
suite
that fails because of this encoding module
Here is the snippet of that test case
eval { $db1-Filter_Push('encode' = 'iso-8859-16') };
is $@, '', push an 'encode' filter (specify iso-8859-16) ;
use charnames qw{:full};
StoreData(\%h1,
{
'euro' = \N{EURO SIGN},
});
VerifyData(\%h2,
{
'euro' = \xA4,
});
The 'euro' gets stored as /Ä,
instead of the 'euro' itself.
Please check if there is a work round for this too or any pointers in
the
source code where there could be a fix for it!
-Sastry
On 8/24/05, Dan Kogai [EMAIL PROTECTED] wrote:
Sastry and EBCDIC porters,
On Aug 24, 2005, at 21:30 , Dan Kogai wrote:
+ sub _utf8_ebcdic($){
+ my $str = shift; # UTF-8
+ $str = # UTF-EBCDIC
+ $_ebcdic_coder-encode($str);
+ _utf8_on($str); # Dirty Trick
+ return $str;
I'm not sure if this part works as advertised. The yet another patch
below tries the different approach.
The problem is that I know so little of UTF-EBCDIC and its
implementation. I feel like building a ship in the bottle in the
dark
Dan the Encode Maintainer
===
RCS file: Encode.pm http://Encode.pm http://Encode.pm,v
retrieving revision 2.11
diff -u -r2.11 Encode.pm http://Encode.pm http://Encode.pm
--- Encode.pm http://Encode.pm http://Encode.pm 2005/08/05
10:58:25 2.11
+++ Encode.pm http://Encode.pm http://Encode.pm 2005/08/24
12:49:18
@@ -136,6 +136,27 @@
return Storable::dclone($obj);
}
+sub _ebcdic_utf8($);
+sub _utf8_ebcdic($);
+
+if ($ON_EBCDIC){
+ my %WHICH_EBCDIC = ( 176 = 'cp37', 95 = 'cp1047', 106 =
'posix-bc' );
+ my $_ebcdic_coder = find_encoding($WHICH_EBCDIC{ord ^});
+ sub _ebcdic_utf8($){
+ my $str = shift; # UTF-EBCDIC
+ _utf8_off($str); # Dirty Trick
+ return # UTF-8
+ $_ebcdic_coder-decode($str);
+ }
+ sub _utf8_ebcdic($){
+ my $str = shift; # UTF-8
+ $str = # EBCDIC
+ $_ebcdic_coder-encode($str);
+ return # UTF-EBCDIC;
+ find_encoding(Unicode)-decode($str);
+ }
+}
+
sub encode($$;$)
{
my ($name, $string,
Smoke [5.9.3] 25383 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25383 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 56 minutes (average 1 hour 58 minutes) Summary: FAIL(XF) 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 25383 Configuration (common) none --- - F F - - -Duse64bitint X F - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 [stdio] 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: Transliteration operator(tr//)on EBCDIC platform
Hi Sadahiro
On 9/11/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
On Wed, 31 Aug 2005 19:53:37 +0530, Sastry [EMAIL PROTECTED] wrote
Hi Sadahiro
The patch has resolved four tests that were failing previously but one
more test is stilling failing(which was failing even before applying the
patch).
Here is the test case
($a = v300.196.172.302.197.172) =~ tr/\x{12c}-\x{130}/\xc0-\xc4/;
is($a, v192.196.172.194.197.172, 'UTF range');
# got 'DÐDEÐ'
# expected '{DÐBEÐ'
Can you suggest some pointers towards fixing this?
-Sastry
This EBCDIC-specific problem is based on how to treat with code values
including Unicode (\x{12c}-\x{130} is surely Unicode) on EBCDIC platform.
Native code values in EBCDIC (for example 'A' == 193) almost differs
from the range of 0..255 in Unicode (for example 'A' == 65) which
coincides with ASCII/Latin1.
Thus the middle part of a character range is gererally different
between EBCDIC and Unicode.
For example consider a character range \xc0-\xc4. Since the mappings
\xc0 to '{' (an open curly) and \xc4 to D in EBCDIC are definite,
the range \xc0-\xc4 is equivalent to {-D on EBCDIC platform.
In EBCDIC {-D (\xc0-\xc4) can be expanded to \xc0\xc1\xc2\xc3\xc4,
but in Unicode {-D cannot be expanded, as the Unicode scalar values
of the endpoints are reverse ('{' = U+007B, D = U+0044).
Actually the current perl implementation is confused:
in the parse time (see toke.c#scan_const) perl treats the range
in EBCDIC order and then does not catch as Invalid range,
though in the compile time (see op.c#pmtrans) and the run time
(see doop.c#do_trans_simple_utf8 and its friends) perl treats
the range in Unicode order and then generates a strange result.
For this test since the min max in scan_const, as per their Unicode
values, should we complain warning, in which case the test case is wrong in
EBCDIC platform! Am I correct?
In my opinion it is necessary to determine how to expand character
ranges with Unicode (whether the native EBCDIC order or Unicode order).
I'm not sure using the native encoding (ASCII/Latin1/EBCDIC) everytime
(that is same as no Unicode within 0..255) makes people happy.
Do you think that perl-5.8.6 is not expanding the character ranges with
Unicode? If so how is this test case working?
($a = \x{12d}\x{12e}\x{12f}\x{130}) =~ tr/\x{12c}-\x{130}/Y/;
All the bytes are translated to Y
regards
-Sastry
Regards,
SADAHIRO Tomoyuki
Re: Encode on EBCDIC patch( Doesn't Work)
Hi Paul Here are the results of the tests t/../lib/DBM_Filter/t/01error1..21 ok 1 - use DBM_Filter; ok 2 - use SDBM_File; ok 3 - use Fcntl; ok 4 - tied to SDBM_File ok ok 5 - croak if not parameters passed to Filter_Push ok 6 - croak on unknown class ok 7 - croak on unknown fully qualified class ok 8 - croak if not passing even number or params to Filter_Push # runFilter bad1 ok 9 - croak if none of Filter/Fetch/Store in filter # runFilter bad2 ok 10 - croak if Filter doesn't return hash reference # runFilter bad3 ok 11 - croak if bad keyword returned from Filter # runFilter bad4 ok 12 - croak if not a code reference # runFilter bad5 ok 13 - croak if neither fetch or store is present # runFilter bad6 ok 14 - croak if store is present but fetch isn't # runFilter bad7 ok 15 - croak if fetch is present but store isn't # runFilter bad8 ok 16 - croak if Fetch, Store and Filter # runFilter bad9 ok 17 - croak if Store and Filter # runFilter bad10 ok 18 - croak if Fetch and Filter # runFilter bad11 ok 19 - croak if Fetch but no Store # runFilter bad12 ok 20 - croak if Store but no Fetch ok 21 - untie without inner references ok All tests successful. u=0.14 s=0.04 cu=0.28 cs=0.09 scripts=1 tests=21 t/../lib/DBM_Filter/t/02core1..189 ok 1 - use DBM_Filter; ok 2 - use SDBM_File; ok 3 - use Fcntl; ok 4 - tied to SDBM_File ok 5 - read eq written ok 6 - read eq written ok 7 - push 'append_A' filter ok 8 - read eq written ok 9 - read eq written ok 10 - read eq written ok 11 - untie without inner references ok 12 - tied to SDBM_File ok 13 - Raw hash is ok ok 14 - untie without inner references ok 15 - tied to SDBM_File ok 16 - read eq written ok 17 - read eq written ok 18 - push 'append_A' filter ok 19 - read eq written ok 20 - read eq written ok 21 - read eq written ok 22 - untie without inner references ok 23 - tied to SDBM_File ok 24 - Raw hash is ok ok 25 - untie without inner references ok 26 - tied to SDBM_File ok 27 - read eq written ok 28 - read eq written ok 29 - push 'append_A' filter ok 30 - read eq written ok 31 - read eq written ok 32 - read eq written ok 33 - untie without inner references ok 34 - tied to SDBM_File ok 35 - Raw hash is ok ok 36 - untie without inner references ok 37 - tied to SDBM_File ok 38 - read eq written ok 39 - read eq written ok 40 - push 'append_A' filter ok 41 - push 'append_B' filter ok 42 - read eq written ok 43 - read eq written ok 44 - read eq written ok 45 - untie without inner references ok 46 - tied to SDBM_File ok 47 - Raw hash is ok ok 48 - untie without inner references ok 49 - tied to SDBM_File ok 50 - read eq written ok 51 - read eq written ok 52 - push 'append_A' filter ok 53 - push 'append_B' filter ok 54 - push 'append_C' filter ok 55 - push 'append_D' filter ok 56 - read eq written ok 57 - read eq written ok 58 - read eq written ok 59 - untie without inner references ok 60 - tied to SDBM_File ok 61 - Raw hash is ok ok 62 - untie without inner references ok 63 - tied to SDBM_File ok 64 - read eq written ok 65 - read eq written ok 66 - push 'append_B' filter ok 67 - push 'append_D' filter ok 68 - read eq written ok 69 - read eq written ok 70 - read eq written ok 71 - untie without inner references ok 72 - tied to SDBM_File ok 73 - Raw hash is ok ok 74 - untie without inner references ok 75 - tied to SDBM_File ok 76 - read eq written ok 77 - read eq written ok 78 - push 'append_A' filter ok 79 - push 'append_C' filter ok 80 - read eq written ok 81 - read eq written ok 82 - read eq written ok 83 - untie without inner references ok 84 - tied to SDBM_File ok 85 - Raw hash is ok ok 86 - untie without inner references ok 87 - tied to SDBM_File ok 88 - read eq written ok 89 - read eq written ok 90 - push 'append_A' filter ok 91 - push 'append_C' filter ok 92 - push 'append_D' filter ok 93 - read eq written ok 94 - read eq written ok 95 - read eq written ok 96 - untie without inner references ok 97 - tied to SDBM_File ok 98 - Raw hash is ok ok 99 - untie without inner references ok 100 - tied to SDBM_File ok 101 - read eq written ok 102 - read eq written ok 103 - push 'append_A' filter ok 104 - push 'append_B' filter ok 105 - push 'append_C' filter ok 106 - read eq written ok 107 - read eq written ok 108 - read eq written ok 109 - untie without inner references ok 110 - tied to SDBM_File ok 111 - Raw hash is ok ok 112 - untie without inner references ok 113 - tied to SDBM_File ok 114 - read eq written ok 115 - read eq written ok 116 - push 'append_A' filter ok 117 - push 'append_B' filter ok 118 - push 'append_C' filter ok 119 - read eq written ok 120 - read eq written ok 121 - read eq written ok 122 - untie without inner references ok 123 - tied to SDBM_File ok 124 - Raw hash is ok ok 125 - untie without inner references ok 126 - tied to SDBM_File ok 127 - read eq written ok 128 - read eq written ok 129 - push 'append_A' filter ok 130 - push 'append_B' filter ok 131 - push 'append_C' filter ok 132 - read eq written ok 133 - read eq written ok 134 - read eq written ok
Re: Transliteration operator(tr//)on EBCDIC platform
On Mon, 12 Sep 2005 16:12:45 +0530, Sastry [EMAIL PROTECTED] wrote
Hi Sadahiro
On 9/11/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
Do you think that perl-5.8.6 is not expanding the character ranges with
Unicode? If so how is this test case working?
($a = \x{12d}\x{12e}\x{12f}\x{130}) =~ tr/\x{12c}-\x{130}/Y/;
All the bytes are translated to Y
regards
-Sastry
Beyond 255 (\x{ff}), I think it will be correctly expanded.
\x{12c}-\x{130} is beyond 255, and thus no problem.
In the range of 0..255 (inclusive), I think generally no for EBCDIC.
(Why I don't say always no is that there are some cases where
a character range in EBCDIC coincides with that in Unicode:
for example 0-9 can be successfully expanded into 0123456789
in both encodings)
I attribute the failure in tr/\x{12c}-\x{130}/\xc0-\xc4/; to
such an ambiguity of \xc0-\xc4. In this expression the left part
\x{12c}-\x{130} parsed before coerces \xc0-\xc4 into Unicode,
and results in the failure.
In contrast, I attribute the success in tr/\xc0-\xc4/\x{12c}-\x{130}/;
to that \xc0-\xc4 is parsed before \x{12c}-\x{130}, and then
\xc0-\xc4 is expanded into \xc0\xc1\xc2\xc3\xc4 as EBCDIC
before the character list is coerced into Unicode.
Well, how about the tese case B? (It has \x{100} at first and
then both sides are coerced into Unicode.)
#test case A # now resolved
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/;
is($c, 8);
is($a, );
#test case B # On ASCII platform, of course successful
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x{100}\x89-\x91/X/;
is($c, 8);
is($a, );
I think the current perl on EBCDIC does not translate gap characters
for the test case B, which works like tr/\x{100}i-j/X/
and results in $c == 2, and $a eq X\x8a\x8b\x8c\x8d\x8f\x90X;
because i's next character is j in Unicode.
And then try this:
#test case C # On ASCII platform, of course successful
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91\x{100}/X/;
is($c, 8);
is($a, );
I think the test case C would success even on EBCDIC, because
the expansion from \x89-\x91 to \x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91
will be done before the parser finds \x{100}.
Regards,
SADAHIRO Tomoyuki
Re: [perl #37142] h2xs skips enums with negative values
Aaron Kaplan (via RT) wrote:
h2xs doesn't generate any code for an enum constant with an explicitly
declared negative value, e.g. enum foo { bar = -1 }, because the
regular expression for parsing enums doesn't allow for the minus sign.
Here's a patch.
--- h2xs-5.9.2 2005/09/11 12:40:25 1.1
+++ h2xs-5.9.2 2005/09/11 12:43:38 1.2
Thanks, applied as change #25388.
5.8.8
If there's a plan for 5.8.8, it goes roughly like this 0: All changes that apply to maint are integrated from blead 1: Changes should be in blead by midnight (GMT) on the 16th October 2005 2: RC1 will probably appear within a week I'll be out of the country for the first week in October, and probably mostly incommunicado. I'll be in the country for the second week, but again mostly incommunicado. This definitely isn't a problem, as a: how patches get into blead *isn't* my direct concern b: stable stuff isn't done as a last minute rush job [You may read this as if not being able to get patches into maint at the last minute worries you, then those patches will by definition worry me] Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then those patches have to go direct to maint. But I believe that little else does. Nicholas Clark
Re: [perl #37039] perlref documentation about optional - is too vague
On Mon, Sep 05, 2005 at 08:10:20AM -0700, Yitzchak Scott-Thoennes wrote:
On Mon, Sep 05, 2005 at 04:41:56PM +0200, Rafael Garcia-Suarez wrote:
On 9/5/05, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote:
Any other feedback on making
(LIST)[LIST]-
not need the -?
I think I like the idea, and the patch seems safe. What I don't like,
though, is the lack of tests for this patch. Also, a minor concern is
that people might unknowingly write non-backwards-compatible code with
5.10 by using this construct.
Some basic tests:
--- t/op/ref.t.orig 2005-01-06 10:11:05.0 -0800
+++ t/op/ref.t 2005-09-05 08:05:18.629808000 -0700
@@ -8,7 +8,7 @@
require 'test.pl';
use strict qw(refs subs);
-plan (89);
+plan (96);
# Test glob operations.
@@ -425,6 +425,23 @@
'Accessing via a different NUL-containing name gives nothing');
}
+# test derefs after list slice
+
+is ( ({foo = bar})[0]{foo}, bar, 'hash deref from list slice w/o -' );
+is ( ({foo = bar})[0]-{foo}, bar, 'hash deref from list slice w/ -' );
+is ( ([qw/foo bar/])[0][1], bar, 'array deref from list slice w/o -' );
+is ( ([qw/foo bar/])[0]-[1], bar, 'array deref from list slice w/ -' );
+is ( (sub {bar})[0](), bar, 'code deref from list slice w/o -' );
+is ( (sub {bar})[0]-(), bar, 'code deref from list slice w/ -' );
+
+# deref on empty list shouldn't autovivify
+{
+local $@;
+eval { ()[0]{foo} };
+like ( $@, Can't use an undefined value as a HASH reference,
+ deref of undef from list slice fails );
+}
+
# Bit of a hack to make test.pl happy. There are 3 more tests after it
leaves.
$test = curr_test();
curr_test($test + 3);
As to your minor concern, that may be a reason to not include it in maint.
(Whether it's a bugfix or enhancement depends on how you interpret the doc.)
Ping?
RE: ZLIB 2.0 / Blead 25366 on VMS
[ John, I've combined responses to two of your messages into one here]
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:
...
I see that the majority of the failures match those that Abe Timmerman
reported earlier today. Apart from running with bleed what else is
different
between the two versions that could account for the extra failures you
are
seeing? Is it anything to do with running the VMS C library in UNIX
emulation mode that you mentioned?
I am not running the VMS C Library in UNIX mode.
Oops. Cut-n-paste error - I should have said NOT running the VMS C library
in UNIX emulation mode.
I am trying to get all
unknown blead issues on VMS resolved so that I can start getting Perl to
work when the C library is in that mode.
Sorry if I'm showing my ignorance of VMS, but does this mean that when you
run Perl on VMS you will/do have the choice of running the C library under
UNIX emulation mode or in VMS native mode?
Abe, does your copy of Perl run in UNIX emulation mode?
It might have been one of my changes, or it might just be something that
is different between our environments.
See what happens below to the external.t test when I create a path
logical name which has no meaning to VMS. Before it was silently
skipped, and now it is a failure.
And this is still with out the C library in UNIX mode.
I will try to look at this some more later, I have blead perl and this
module all built in debug so I should be able to find the real reason
for these errors. Once I find the reason, it is likely that I could
really use help for the correct fix.
If the problem is in my code I want to know about it and I'll certainly help
out. If it's someplace else I'll still try to help if I can.
There are a number of places that the VMS specific code is failing
silently because of a bug, and this is not detected because there is
some fallback code that compensates. But there are also consequences to
fixing those bugs as they expose others.
Ugh!
lib/IO/Zlib/t/external.t
1..0 # Skip: no /usr/bin/gzip
If the GNV package is installed on VMS, then gzip is
available at /bin/gzip. As I had nothing in /usr, I
set up a logical name so that /usr/bin/gzip should
find a gzip. This test still produced the same output.
Also gzip may (or may not) be present anywhere on the
system with a foreign command (shell alias) or the
DCL$PATH search list used to find it.
The test is verifying that '/usr/bin' is in $ENV{PATH}, an environment
variable generally ignored on VMS. Easy to hack, but then the test
fails later:
lib/IO/Zlib/t/external.t
ok 17
: non-translatable vms error code: 0x186D4
%rms-f-syn, file specification syntax error
PROJECT_ROOT:[PERL-BLEAD.t]test.gz;: no such file or directory
ok 18
not ok 21
ok 22
Can't call method gzread on an undefined value at ../lib/IO/Zlib.pm
line 472.
%RMS-E-FNF, file not found
Although it would be good to have these tests running on VMS, I'm not sure
if it is really necessary right now if you are going to be guaranteed to
have Compress::Zlib available in the core. The code it is exercising will
only kick in if Compress::Zlib is unavailable.
ext/Compress/Zlib/t/04def.t fails on test 102 and dies.
not ok 102 - create IO::Gzip
# Failed test ([-.ext.compress.zlib.t]04def.t at line 322)
Can't call method fileno on an undefined value at
[-.ext.compress.zlib.t]04def.t line 324.
# Looks like you planned 1781 tests but only ran 102.
# Looks like your test died just after 102.
%SYSTEM-F-ABORT, abort
Not sure why this is failing for you but passing for Abe.
I will have to investigate. There are enough Phase-of-Moon issues
involved that it could be anything.
This code is writing to a file via a *FH style filehandle.
ext/Compress/Zlib/t/05examples.t
not ok 21 - exit status is 0
# Failed test ([-.ext.compress.zlib.t]05examples.t at line 152)
# got: '512'
# expected: '0'
not ok 22 - no stderr
# Failed test ([-.ext.compress.zlib.t]05examples.t at line 153)
# got: '71'
# expected: '0'
ok 23 - gzcat
ok 24 - exit status is 0
not ok 25 - content is ok
# Failed test ([-.ext.compress.zlib.t]05examples.t at line 158)
# got: '%RMS-E-FNF, file not found
# '
# expected: 'helloext/Compress/Zlib/t/06gzsetp.t
snip
# Looks like you failed 3 tests of 25.
Again this code is using a filehandle of the form *FH.
Of this script, tests 31,48,52,56,60,68 are expected behavior
on VMS when the C library is not in a UNIX emulation mode.
I do not have blead Perl able to fully work in this mode yet.
At the time that I wrote this, I had forgotten that readdir() seems to
suppresses the trailing . so this is an inconsistency.
There is a problem with readdir() suppressing the trailing dot on a NULL
file type in VMS mode. In some cases it is significant because if it is
not present, VMS may add a
RE: ZLIB 2.0 / Blead 25366 on VMS
From: Tom Hughes [mailto:[EMAIL PROTECTED] In message 20050911232132.CDZH22901.aamta10- [EMAIL PROTECTED] Paul Marquess [EMAIL PROTECTED] wrote: Thanks John. I've CCed Tom Hughes for the IO:Zlib results. The external gzip support in IO::Zlib is all Jarkko's work and nothing to do with me I'm afraid. OK, CC'ed Jarkko as well :-) Jarkko, you been paying attention? Paul
Re: 5.8.8
On Mon, Sep 12, 2005 at 05:29:39PM +0100, Nicholas Clark wrote: If there's a plan for 5.8.8, it goes roughly like this 0: All changes that apply to maint are integrated from blead 1: Changes should be in blead by midnight (GMT) on the 16th October 2005 2: RC1 will probably appear within a week I'll be out of the country for the first week in October, and probably mostly incommunicado. I'll be in the country for the second week, but again mostly incommunicado. This definitely isn't a problem, as a: how patches get into blead *isn't* my direct concern b: stable stuff isn't done as a last minute rush job [You may read this as if not being able to get patches into maint at the last minute worries you, then those patches will by definition worry me] Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then those patches have to go direct to maint. But I believe that little else does. The only other exception would be changes to re-entrant functions through reentr.pl, where the generated code is quite different than that in bleadperl. Steve Peters [EMAIL PROTECTED]
[MAINT24637] fails make test on OSX 10.4 (lib/locale.t)
At least it fails on only one thing... lib/locale FAILED at test 99 If you'd like the (rather longish) verbose output, let me know. Perhaps this is enough: # # The locale definition # # be_BY.CP1131 # # on your system may have errors because the locale test 99 # failed in that locale. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 105 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 106 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 108 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 109 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 113 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # # The locale definitions # # eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8 # # on your system may have errors because the locale test 115 # failed in those locales. # # If your users are not using these locales you are safe for the moment, # but please report this failure first to [EMAIL PROTECTED] using the # perlbug script (as described in the INSTALL file) so that the exact # details of the failures can be sorted out first and then your operating # system supplier can be alerted about these anomalies. # # The following locales # # C C POSIX POSIX af_ZA af_ZA.ISO8859-1 af_ZA.ISO8859-15 # af_ZA.UTF-8 am_ET am_ET.UTF-8 be_BY be_BY.CP1131 be_BY.CP1251 # be_BY.ISO8859-5 be_BY.UTF-8 bg_BG bg_BG.CP1251 bg_BG.UTF-8 # ca_ES ca_ES.ISO8859-1 ca_ES.ISO8859-15 ca_ES.UTF-8 cs_CZ # cs_CZ.ISO8859-2 cs_CZ.UTF-8 da_DK da_DK.ISO8859-1 da_DK.ISO8859-15 # da_DK.UTF-8 de_AT de_AT.ISO8859-1 de_AT.ISO8859-15 # de_AT.UTF-8 de_CH de_CH.ISO8859-1 de_CH.ISO8859-15 # de_CH.UTF-8 de_DE de_DE.ISO8859-1 de_DE.ISO8859-15 # de_DE.UTF-8 el_GR el_GR.ISO8859-7 el_GR.UTF-8 en_AU # en_AU.ISO8859-1 en_AU.ISO8859-15 en_AU.US-ASCII en_AU.UTF-8 # en_CA en_CA.ISO8859-1 en_CA.ISO8859-15 en_CA.US-ASCII # en_CA.UTF-8 en_GB en_GB.ISO8859-1 en_GB.ISO8859-15 # en_GB.US-ASCII en_GB.UTF-8 en_IE en_IE.UTF-8 en_NZ # en_NZ.ISO8859-1 en_NZ.ISO8859-15 en_NZ.US-ASCII en_NZ.UTF-8 # en_US en_US.ISO8859-1 en_US.ISO8859-15 en_US.US-ASCII # en_US.UTF-8 es_ES es_ES.ISO8859-1 es_ES.ISO8859-15 # es_ES.UTF-8 et_EE et_EE.ISO8859-15 et_EE.UTF-8 fi_FI # fi_FI.ISO8859-1 fi_FI.ISO8859-15 fi_FI.UTF-8 fr_BE # fr_BE.ISO8859-1 fr_BE.ISO8859-15
Re: [perl #37117] Math::Complex atan2 bug
Hence, I'd suggest patching the behaviour one way or another. There's three things I'd consider sensible to do: - atan2($z1, $z2) = atan($z1/$z2) (same order as with the normal atan2) - remove the atan2($z1, $z2) alltogether and just carp() instead. - atan2($z1, $z2) = atan(Re($z1)/Re($z2)) (Same as MATLAB) Either way, the behaviour should be documented. And IMHO it shouldn't be what it is now. Maybe there are other sensible things atan2 could do. Tell me which you consider the best and I'll write the patch. I'll work out a patch... I have other outstanding things to do for Math::Complex and Math::Trig. Best regards, Steffen
Re: ZLIB 2.0 / Blead 25366 on VMS
The external gzip support in IO::Zlib is all Jarkko's work and nothing to do with me I'm afraid. OK, CC'ed Jarkko as well :-) Jarkko, you been paying attention? Not awfully so, I don't read p5p actively. [rereading the thread] Off-hand I'd say the easy thing to do would be just skip the IO::Zlib external test in VMS. The VMS environment seems to be tantalizingly close to a real POSIX/UNIX environment, but not quite. There *might* be some easy (and portable enough between VMS releases) magic trick that could be done, but my VMS-fu never was strong and whatever little I ever had has faded over the years, sadly. Paul
RE: ZLIB 2.0 / Blead 25366 on VMS
I've just uploaded Compress::Zlib 2.000_03 onto CPAN. This should hopefully silence some of the failures on VMS. http://search.cpan.org/CPAN/authors/id/P/PM/PMQS/Compress-Zlib-2.000_03.tar. gz Paul
Re: ZLIB 2.0 / Blead 25366 on VMS
Paul Marquess wrote: From: John E. Malmberg [mailto:[EMAIL PROTECTED] Paul Marquess wrote: Sorry if I'm showing my ignorance of VMS, but does this mean that when you run Perl on VMS you will/do have the choice of running the C library under UNIX emulation mode or in VMS native mode? It is quite a bit more grey than that. There a number of feature settings that will determine how UNIXish or VMSish that the C library will behave. In most cases the defaults are for backward compatibility with existing applications. Abe, does your copy of Perl run in UNIX emulation mode? I do not think it will run too well. Too much of Perl is assuming that when $^O eq 'VMS' that it will always see a VMSish file specification. I only have about 1/3 of the fixes checked into blead right now. If the problem is in my code I want to know about it and I'll certainly help out. If it's someplace else I'll still try to help if I can. Thanks. There are a number of places that the VMS specific code is failing silently because of a bug, and this is not detected because there is some fallback code that compensates. But there are also consequences to fixing those bugs as they expose others. Ugh! Not to mention, in some cases the VMS specific code is apparently depending on UNIX code failing before it falls back to the VMS code, and as the C library or the underlying VMS support code gets fixed, some of these failures will stop automatically happening. I have already seen a case of VMS specific code depending on access to '/dev/tty' failing, and in the future that may not fail. Although it would be good to have these tests running on VMS, I'm not sure if it is really necessary right now if you are going to be guaranteed to have Compress::Zlib available in the core. The code it is exercising will only kick in if Compress::Zlib is unavailable. I am going to ignore that for now, but it shows that as I fix things in VMS, I have to make sure that tests are not inadvertently skipped simply because they are running on VMS. ext/Compress/Zlib/t/04def.t fails on test 102 and dies. not ok 102 - create IO::Gzip # Failed test ([-.ext.compress.zlib.t]04def.t at line 322) Can't call method fileno on an undefined value at [-.ext.compress.zlib.t]04def.t line 324. # Looks like you planned 1781 tests but only ran 102. # Looks like your test died just after 102. %SYSTEM-F-ABORT, abort This code is writing to a file via a *FH style filehandle. I do not have access to the system i am running the tests on at the moment, but did look at this a bit last night. The *FH filehandle was opened, and then something tried an operation to set a variable named $x. That failed for a reason that I have not determined. I was stepping through the code in the debugger, and suddenly was in sub destroy. This leaves the method $x-fileno undefined as was in the subsequent error message. There may or may not be useful information in the screen buffer of my terminal emulator. ext/Compress/Zlib/t/05examples.t not ok 21 - exit status is 0 # Failed test ([-.ext.compress.zlib.t]05examples.t at line 152) # got: '512' # expected: '0' not ok 22 - no stderr # Failed test ([-.ext.compress.zlib.t]05examples.t at line 153) # got: '71' # expected: '0' ok 23 - gzcat ok 24 - exit status is 0 not ok 25 - content is ok # Failed test ([-.ext.compress.zlib.t]05examples.t at line 158) # got: '%RMS-E-FNF, file not found # ' # expected: 'helloext/Compress/Zlib/t/06gzsetp.t snip # Looks like you failed 3 tests of 25. Again this code is using a filehandle of the form *FH. So I need to find out why this is failing. On VMS, all filenames have a period to delimit where the name part ends and the extension (also known as file type). If there is a NULL type, then the period still is returned. There is another special rule about specifying filenames with a NULL type. If a utility gets a file with out the type specified, it will append a default type, unless the NULL type is explicitly specified by a trailing period. But this behavior could be considered a bug in the VMS code because it is leaving the trailing period in glob, but it is removing it with readdir() on Perl. Not consistent behavior. So is the trailing period issue something that will be fixed at your end, or do I need to rework my tests to always use filenames with extensions/file type? Yes or no. It is a bit grey. And I am not sure how to fix it and keep everyone happy. I think that you may need to always use a non-null file type. This is the problem: If the filenames are being presented in VMS mode, then the trailing dot should be present. If they are presented in UNIX mode it should not be. And also according to both the Perl (most routines) and VMS C library routines manual, if you supply a VMS format name as input, you should get a VMS format name on output, and if
Re: [perl #37117] Math::Complex atan2 bug
Hi Jarkko, You wrote: Another good reference on these matters, MATLAB ignores the complex parts of atan2() arguments. Well, that's fine. (Though not how I'd like to use the function.) Right now, however, the behaviour is clearly wrong. We have: atan2($real1, $real2) == atan($real1/$real2) and: atan2($cplx1, $cplx2) == atan($cplx2/$cplx1) (Due to overloading, it doesn't matter if any one of the $cplxX is actually real, but you know that, of course.) I understand your argument that atan2 of complex arguments isn't well defined. But the current behaviour isn't even treating the parameter order as with real numbers. That's just wrong. (Which is, in fact, well defined, but still bad. ;-) Hence, I'd suggest patching the behaviour one way or another. There's three things I'd consider sensible to do: - atan2($z1, $z2) = atan($z1/$z2) (same order as with the normal atan2) - remove the atan2($z1, $z2) alltogether and just carp() instead. - atan2($z1, $z2) = atan(Re($z1)/Re($z2)) (Same as MATLAB) Either way, the behaviour should be documented. And IMHO it shouldn't be what it is now. Maybe there are other sensible things atan2 could do. Tell me which you consider the best and I'll write the patch. Best regards, Steffen
RE: ZLIB 2.0 / Blead 25366 on VMS
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
...
ext/Compress/Zlib/t/04def.t fails on test 102 and dies.
not ok 102 - create IO::Gzip
# Failed test ([-.ext.compress.zlib.t]04def.t at line 322)
Can't call method fileno on an undefined value at
[-.ext.compress.zlib.t]04def.t line 324.
# Looks like you planned 1781 tests but only ran 102.
# Looks like your test died just after 102.
%SYSTEM-F-ABORT, abort
This code is writing to a file via a *FH style filehandle.
I do not have access to the system i am running the tests on at the
moment, but did look at this a bit last night. The *FH filehandle was
opened, and then something tried
an operation to set a variable named $x.
That failed for a reason that I have not determined. I was stepping
through the code in the debugger, and suddenly was in sub destroy.
I must be triggering object destruction too soon for some reason. If working
with the full test harness is too cumbersome, this should be the equivalent
of the test that is failing
use strict;
use warnings;
use blib;
use IO::Gzip;
my $name = abc.def;
open FH, $name
or die Cannot open $name: $!\n;
my $x = new IO::Gzip *FH
or die Cannot create IO::Gzip object\n;
...
On VMS, all filenames have a period to delimit where the name part ends
and the extension (also known as file type). If there is a NULL type,
then the period still is returned.
There is another special rule about specifying filenames with a NULL
type. If a utility gets a file with out the type specified, it will
append a default type, unless the NULL type is explicitly specified by a
trailing period.
But this behavior could be considered a bug in the VMS code because it
is leaving the trailing period in glob, but it is removing it with
readdir() on Perl. Not consistent behavior.
So is the trailing period issue something that will be fixed at your
end, or
do I need to rework my tests to always use filenames with
extensions/file
type?
Yes or no. It is a bit grey. And I am not sure how to fix it and keep
everyone happy.
I think that you may need to always use a non-null file type.
I'm sure can live with that.
t/16top.
glob failed (can't start child: invalid argument) at /P5M/
COMPRESS-ZLIB-2_000_01
/blib/lib/Compress/Zlib/Common.pm line 232.
legal or die??? at /P5M/COMPRESS-ZLIB-2_000_01/blib/lib/Compress/Zlib/
Common.pm
line 237.
That is tripping over file globbing. The test is failing when I try to
execute this
glob in[1234]
and there are 4 matching files in1, in2, in3 and in4.
Hmm, just had a read at perlvms.pod -- is VMS complaining because
[1234]
looks like a directory or does it not support '[1234]' as a wildcard
character class?
Most likely. Currently in most places that Perl is trying to determine
if a filename is in UNIX format or VMS, it is only looking for
m{[]:;}. The caret character should also be added to that mix as that
is used on escape extended characters.
The other test that is used to determine if a file is UNIX is to see if
it contains a '/' character.
Also glob on VMS is done in C code, not by passing the glob through to
the shell.
I realise that VMS perl is trying to steer a middle course and have glob
work both with Unix filenames and VMS native filenames, but the
parameter to
glob isn't a filename - it's a cut down regular expression. I assume
thought
with the [] characters you are faced with a major culture clash -- it
can't be both a VMS directory and a character class at the same time.
Yep. With ODS-5 it is even worse. / is a legal character in a VMS
format file specification.
Some rules need to be documented and enforced on how path names are to
be interpreted. If both UNIX and VMS path names are to be mixed, then
some rule is needed to decide the ambiguous cases.
The fun is doing it with out breaking any existing Perl scripts.
Assuming character classes are supported, is it possible to either make
VMS
think that the glob is a Unix filename or to escape the [] characters so
that they will be used as character class delimiters?
For example, if prefix the globs with ./ like this
glob ./in[1234]
will it go into VMS mode or Unix mode?
I do not know with out trying it, or code inspection. It depends on
what particular check that the code is making. If it is checking for a
/ then it will go into UNIX mode.
Well the 2.000_03 release has used the ./ prefix for the tests that need
character classes.
I'll try to get an updated version of my module out tonight or tomorrow
with
all of the fixes applied.
Please let me know what files you change and where I should put them in
blead because that is where I am set up to test them.
The only things you need to bother with are the test files. I'd just delete
all the files in
Zlib 2.00_03 / Blead 25366 on VMS + patched vms.c
I finally got a download of 2.00_03, and I have locally patched vms.c to
fix the fstat()/Perl_cando() issue.
So here are the results.
I probably will not have time to investigate the failure tonight as I
need to submit the patch to vms.c.
ext/Compress/Zlib/t/01version.t 2 of 2 ok
ext/Compress/Zlib/t/02zlib.t 242 of 242 ok
ext/Compress/Zlib/t/03zlib-v1.t 351 of 351 ok
ext/Compress/Zlib/t/04def.t 1781 of 1781 ok
ext/Compress/Zlib/t/05examples.t 25 of25 ok
ext/Compress/Zlib/t/06gzsetp.t 51 of51 ok
ext/Compress/Zlib/t/07bufsize.t 288 of 288 ok
ext/Compress/Zlib/t/08encoding.t 16 of16 ok
ext/Compress/Zlib/t/09gziphdr.t 790 of 790 ok
ext/Compress/Zlib/t/10defhdr.t595 of 595 ok
ext/Compress/Zlib/t/11truncate.t 2374 of 2374 ok
ext/Compress/Zlib/t/12any.t63 of63 ok
ext/Compress/Zlib/t/13prime.t 10612 of 10612 ok
ext/Compress/Zlib/t/14gzopen.t212 of 212 ok
ext/Compress/Zlib/t/15multi.t 575 of 575 pass.
ext/Compress/Zlib/t/16oneshot.t fails at 1460 and dies.
not ok 1460 - Compressed ok
# Failed test ([-.ext.compress.zlib.t]16oneshot.t at line 729)
# input file 't/tmpdir1/a1.tmp' does not exist
ok 1461
not ok 1462 - got all files
# Failed test ([-.ext.compress.zlib.t]16oneshot.t at line 740)
# got: '1'
# expected: '0'
ok 1463 - IO::Gzip::gzip - From FileGlob to Buffer files [a1]
not ok 1464 - Compressed ok
# Failed test ([-.ext.compress.zlib.t]16oneshot.t at line 747)
# input file 't/tmpdir1/a1.tmp' does not exist
buffer is undef at ../ext/compress/zlib/t/MyTestUtils.pm line 326
main::anyUncompress('ARRAY(0xa8bc08)') called at
[-.ext.compress.zlib.t]16oneshot.t line 752
# Looks like you planned 2544 tests but only ran 1464.
# Looks like your test died just after 1464.
ext/Compress/Zlib/t/17isize.tSkipped.
ext/Compress/Zlib/t/18lvalue.t 10 of 10 ok
ext/Compress/Zlib/t/19destroy.t23 of 23 ok
ext/Compress/Zlib/t/20tied.t 731 of 732 ok
ext/Compress/Zlib/t/21newtied.t 242 of 242 ok
ext/Compress/Zlib/t/22merge.t 490 of 490 ok
ext/Compress/Zlib/t/23misc.t 29 of 29 ok
ext/Compress/Zlib/t/99pod.tskipped.
1..0 # Skip Test::Pod 1.00 required for testing POD
ext/Compress/Zlib/t/globmapper.t 68 of 69 ok
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: [EMAIL PROTECTED] VMS fixes for cbuilder
Ken Williams wrote: Thanks, John. I've applied your patch (in a slightly modified form) and released a new beta, 0.13_01. It would be great if you (and/or a couple other people on the vmsperl list) could try it out, and then I can release 0.14 when it checks out. It is not yet showing up on CPAN, I will look again tomorrow evening. It looks like I am finally close to starting to get the file spec handling in Perl up to speed with current VMS versions. In File::Spec::VMS, would it be appropriate to use a syntax like below to switch VMS into case sensitive mode if the underlying version of VMS Perl supported it? case_tolerant=0 VMS, and a few others also need a method to set/indicate the status of case preserved. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [perl #37101] my $v if (0); leaves $v around
On Wed, Sep 07, 2005 at 05:19:55PM -0700, brucer @ gsg-lnx-bld1. cisco. com wrote: The following program invokes beta once instead of twice. Extremely non-intuitive. moving the #' down one line fixes it. 1) seems like it shouldn't compile. 2) $c is static and keeps its value between invocations if one instead of if (0) one has if ($b) This is boiled down from a real program, of course. The short answer is don't do that. Cmy $v if 0; has already been deprecated in the development version of Perl because its behavior is too confusing. The behavior cannot be changed because too many people rely on it. $ bleadperl -wle 'my $v if 0;' Deprecated use of my() in false conditional at -e line 1. -- 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: ZLIB 2.0 / Blead 25366 on VMS
Paul Marquess wrote: I've just uploaded Compress::Zlib 2.000_03 onto CPAN. This should hopefully silence some of the failures on VMS. http://search.cpan.org/CPAN/authors/id/P/PM/PMQS/Compress-Zlib-2.000_03.tar.gz Unfortunately search.cpan.org and nttp.cpan.org seem to be down right now. But I am on the track for the problem. The Perl_cando() routine in vms.c is working on the wrong filename usr:[share.misc]termcap because of a bug in vms.c. fstat() and stat()/lstat() are sharing a stat cache, and when the cache is holding a value returned by fstat(), the cached name of the last stat()/lstat() is not being changed, and that is then used to check if ACLs are affecting the access permissions. It looks like I need to change vms.c and build a new Perl. -John [EMAIL PROTECTED] Personal Opinion Only
Re: PathTools 3.10 released
On Sep 12, 2005, at 4:22 PM, Michael G Schwern wrote: On Sun, Sep 11, 2005 at 07:39:46PM -0500, Ken Williams wrote: I thought I supplied an implementation with that. Yes - your implementation worked for everything except /.. - /, so I just added one line that did that. The rest of the implementation is yours verbatim. Oh, ok. The wording of your original post made it sound like you had to implement the whole thing. Yeah, you're right. I think when I wrote that summary I had forgotten how the exchange went, but prospective was the wrong word to use. -Ken
Stop fiddling with the bloody grammar (was Re: exempli gratia is e.g.)
On Wed, Sep 07, 2005 at 01:04:00PM -0400, Mark Jason Dominus wrote: I was struck by one of my own: exempli gratia being abbreviated to eg or eg., rather than e.g. I would like to suggest that Latin is obscure, and latin abbreviations are doubly obscure. There is no space constraint that should require us to use e.g. in place of for example. Using i.e. in place of that is is even sillier. (57% sillier, in fact.) If you're going to do the work of locating these locutions, can I suggest that you get rid of the unnecessary abbreviations entirely? I'm going to come at this from a different angle. One that says leave it as ie/eg or perhaps simply who cares? because the effort to correct all the ie's and eg's and it's and [ae]ffects just doesn't seem worth the effort. I will quote Donald Norman. What about noon: How shall it be labeled, AM or PM? In a clever essay on the topic, the engineer Henry Petroski argues that 12 noon should be labeled 12M, for after all, the history of AM and PM is that they mean Ante Meridiem (before the middle of the day) and Post Meridiem (after midday). Noon is the meridiem, the midday, so it is neither before nor after. It should be labeled M: 12M. Yikes! That is putting principle first, and damn the consequences. I hate to disagree so strongly with one of my favorite authors, but I splutter at the thought of using M to mark noon in order to distinguish it from midnight! In English, if any letter is to be used to denote noon, it should be N. M ought to stand for midnight. The mark of M for noon makes historical sense, but it makes practical sense only if the everyday user of time understands the original meanings of the terms AM and PM. How Long Is Noon? published in Turn Signals Are The Facial Expressions Of Automobiles p 89 The point being, most people don't know that P.M., i.e. and e.g. are abbreviations for Latin phrases so it doesn't matter one bit to the reader of the Perl documentation whether its ie or i.e.. While neither option causes confusion, as 12M for 12 noon does, neither one adds anything over the other except perhaps niggling grammatical correctness. What it does add is MAINTENANCE COST. Maintaining an extreme level of grammatical correctness and consistency over a large collection with multiple authors takes time and effort not just from the person doing the initial grammar fix but from all the CPAN authors who now have to reapply that patch and retrain their writing style. Not to mention all the mailing list noise it inevitably generates (remember the [ae]ffect thread?) Effort is spent with a near 0 benefit to the user. While I thank you very much for the effort to scan the documentation to find grammar nits, and I realize Open Source is about scratching an itch, software is about change management. Which is why I say to stop fiddling with the (ie/i.e.)'s, the (eg/e.g.)'s, the (its/it's)'s and the ([ae]ffects). There's FAR more important things to be done in the Perl documentation. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
RE: Encode on EBCDIC patch( Doesn't Work)
Dan, I'm not sure what is going on here. Can I walk through one of the failing
test to see if it rings any bells with you?
I'll use the utf8.t test, because it is a bit more straightforward.
I first write these key/value pairs to the DBM file with a utf8 encoding filter
in place
undef() = undef(),
beta = \N{beta},
'alpha' = \N{alpha},
\N{gamma}= gamma,
Then I remove the utf8 filter and read the raw data from the DBM file to check
that the bytes actually written to the DBM file have been encoded correctly. SO
I expect to get these k/v pairs back
'alpha' = \xCE\xB1,
'beta' = \xCE\xB2,
\xCE\xB3= gamma,
= ,
But this is what I actually read from the DBM file.
'beta' = '¸ž'
'alpha' = '¸¨'
'¸ß' = 'gamma'
Any ideas?
Paul
Re: PathTools 3.10 released
On Sun, Sep 11, 2005 at 07:39:46PM -0500, Ken Williams wrote: I thought I supplied an implementation with that. Yes - your implementation worked for everything except /.. - /, so I just added one line that did that. The rest of the implementation is yours verbatim. Oh, ok. The wording of your original post made it sound like you had to implement the whole thing. I'm not sure why I needed to add that case you didn't see a failure on your side, though. Cuz I didn't check for it? :) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
[EMAIL PROTECTED] vms/vms.c Perl_cando fix.
The VMS specific Perl_cando() on open file handles was returning the
results for a previous file that a stat()/lstat() that was done instead
of for the open file.
This was causing failures in the Compress-Zlib tests on my system.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- vms/vms.c_25388 Mon Sep 12 23:24:29 2005
+++ vms/vms.c Mon Sep 12 21:45:06 2005
@@ -7692,7 +7692,16 @@
Perl_flex_fstat(pTHX_ int fd, Stat_t *statbufp)
{
if (!fstat(fd,(stat_t *) statbufp)) {
-if (statbufp == (Stat_t *) PL_statcache) *namecache == '\0';
+if (statbufp == (Stat_t *) PL_statcache) {
+char *cptr;
+
+ /* Save name for cando by name in VMS format */
+ cptr = getname(fd, namecache, 1);
+
+ /* This should not happen, but just in case */
+ if (cptr == NULL)
+ namecache[0] = '\0';
+}
statbufp-st_dev = encode_dev(aTHX_ statbufp-st_devnam);
# ifdef RTL_USES_UTC
# ifdef VMSISH_TIME
Re: Encode on EBCDIC patch( Doesn't Work)
On Sep 13, 2005, at 07:42 , Paul Marquess wrote:
Dan, I'm not sure what is going on here. Can I walk through one of
the failing test to see if it rings any bells with you?
Before that I would like to make sure if I understand the scope of
the problem correctly. We are talking about the problem in EBCDIC
platform, not DBM_Filter vs. Encode at alarge, right?
I wrote a simple script and there seems no problem on ASCII platforms.
SO I expect to get these k/v pairs back
'alpha' = \xCE\xB1,
'beta' = \xCE\xB2,
\xCE\xB3= gamma,
But this is what I actually read from the DBM file.
'beta' = '¸ž'
'alpha' = '¸¨'
'¸ß' = 'gamma'
On ASCII platforms I got what you've expected.
Sastry, would you clarify the problem a little bit more? If that's
the problem of Encode vs. EBCDIC, say so. It occurs to me DBM_Filter
is not guilty for this case.
Dan the Encode Maintainer.
#
use strict;
use charnames 'greek';
use DBM_Filter;
use Fcntl;
use DB_File;
use SDBM_File;
my %file = (
DB_File = 'test.db',
SDBM_File = 'test.sdbm',
);
my %hash = (
beta = \N{beta},
'alpha' = \N{alpha},
\N{gamma}= gamma,
);
sub perlqq{
join '', map { chr($_) =~ /\w/ ? chr $_ : sprintf \\x%02X,
$_ } unpack C*, shift;
}
for my $dbmtype (keys %file){
print $dbmtype\n;
tie my %db, $dbmtype, $file{$dbmtype}, O_RDWR|O_CREAT, 0644
or die $dbmtype - $file{$dbmtype} : $!;
%db = (); # clear
tied(%db)-Filter_Push('utf8');
for my $k (keys %hash){
$db{$k} = $hash{$k};
printf \$k = %s(%d), \$db{\$k} = %s(%d)\n,
perlqq($k), Encode::is_utf8($k), perlqq($db{$k}),
Encode::is_utf8($db{$k});
}
untie %db;
tie my %db, $dbmtype, $file{$dbmtype}, O_RDONLY, 0644
or die $dbmtype - $file{$dbmtype} : $!;
while(my ($k, $v) = each %db){
printf \$k = %s(%d), \$v = %s(%d)\n,
perlqq($k), Encode::is_utf8($k), perlqq($v),
Encode::is_utf8($v);
}
untie %db;
}
__END__
Re: [EMAIL PROTECTED] VMS fixes for cbuilder
Thanks, John. I've applied your patch (in a slightly modified form)
and released a new beta, 0.13_01. It would be great if you (and/or a
couple other people on the vmsperl list) could try it out, and then I
can release 0.14 when it checks out.
-Ken
p.s. - I wish all novices were as capable as you. ;-)
On Sep 10, 2005, at 11:24 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Ken Williams wrote:
Hi John,
After my last email I reworked the patch so that all the
modifications are in Platform/VMS.pm. Could you confirm that it
still works for you and I haven't broken it?
Hello Ken,
As I previously wrote to you, both my patch and this patch do not work.
While my patch fixed the ParseXS/t/basic that I was working on, it
broke three other tests.
I have requested that Change 25364 be regressed from blead.
I have rerun all the lib/Extutils/ tests with this latest patched
version of CBuilder/Platform/VMS.pm and the original CBuilder/base.pm.
In this patch:
sub need_prelink is left to return 0, because the VMS specific sub
do_link has to set up the pre-link option file when needed.
In sub arg_include_dirs, I think I have fixed the it to properly
extract the include directories from the $self-{config}{ccflags}.
I am still quite a novice in Perl programming.
Not only is the '/inc' case insensitive as you noted, it can be any
thing from: '/inc=[]' to '/include_directory=([],[foo])'.
Next is that I needed to create a VMS specific sub lib_file and put
the Dynaloader::mod2fname() code into it to set the name of the shared
image.
The VMS specific sub _do_link that you provided needed to have the
name changing code removed from it and put into lib_file as I
mentioned above, so that test CBuilder/t/02-link will pass.
I also had to make the addition of the link option files conditional
on if you are building a loadable image.
