Re: Time::HiRes::nanosleep support for Solaris [PATCH]
On 15 Aug 2005 21:05:22 -0700, Gisle Aas [EMAIL PROTECTED] wrote:
I noticed that our Solaris builds ends up with a Time::HiRes module
that does not support nanosleep. This happens because the Solaris
hints file for Time::HiRes tries to use the POSIX module that is not
available when the module is built as part of the core. This is what
I see in our build logs:
Thanks, applied as change #25295
Making Time::HiRes (realclean)
Configuring Time::HiRes...
Using hints hints/solaris.pl...
Looking for gettimeofday()... found.
Looking for setitimer()... found.
Looking for getitimer()... found.
You have interval timers (both setitimer and getitimer).
Looking for ualarm()... found.
Looking for usleep()... found.
Looking for nanosleep()... Processing hints file hints/solaris.pl
Can't locate POSIX.pm in @INC (@INC
contains: . ../../../lib
/tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda/lib/5.8.7/sun4-solaris-thread-multi
/tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda/lib/5.8.7
/tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda/lib/site_perl/5.8.7/sun4-solaris-thread-multi
/tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda/lib/site_perl/5.8.7
/tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda/lib/site_perl
.)
at hints/solaris.pl line 1. BEGIN failed--compilation aborted at
hints/solaris.pl line 1. NOT found. [...]
The following patch fixes this problem:
Index: ext/Time/HiRes/hints/solaris.pl
--- ext/Time/HiRes/hints/solaris.pl.~1~ Mon Aug 15 21:02:15 2005
+++ ext/Time/HiRes/hints/solaris.pl Mon Aug 15 21:02:15 2005
@@ -1,6 +1,7 @@
-use POSIX qw(uname);
# 2.6 has nanosleep in -lposix4, after that it's in -lrt
-if (substr((uname())[2], 2) = 6) {
+my $r = `/usr/bin/uname -r`;
+chomp($r);
+if (substr($r, 2) = 6) {
$self-{LIBS} = ['-lposix4'];
} else {
$self-{LIBS} = ['-lrt'];
End of Patch.
--Gisle
--
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] 25294 FAIL(XF) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
Automated smoke report for 5.9.3 patch 25294 Mugwump.uk.radan.com: Intel(R) Pentium(R) 4 CPU 3.40GHz(~3391 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using cl version 12.00.8804 smoketime 10 hours 20 minutes (average 15 minutes 31 seconds) 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 25294 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - O O O O -Dusemymalloc O O -Duselargefiles O O -Duselargefiles -Dusemymalloc O O -Duseithreads -Uuseimpsys O O -Duseithreads -Uuseimpsys -Dusemymalloc O O -Duseithreads -Uuseimpsys -Duselargefiles O O -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc F F -Duseithreads F F -Duseithreads -Duselargefiles O O -Accflags='-DPERL_COPY_ON_WRITE' O O -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc O O -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles O O -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc O O -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys O O -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc X O -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles O O -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc F F -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads F F -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Locally applied patches: DEVEL24148 Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [default] -Duseithreads [default] -DDEBUGGING -Duseithreads [default] -Duseithreads -Duselargefiles [default] -DDEBUGGING -Duseithreads -Duselargefiles [default] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [default] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads [default] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles [default] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Duselargefiles ../lib/Test/Simple/t/threads.t..FAILED 2-6 [default] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles Inconsistent test results (between TEST and harness): ../lib/Benchmark.t..dubious Compiler messages(MSWin32): LINK : warning LNK4089: all references to SHELL32.dll discarded by /OPT:REF FastCalc.xs(397) : warning C4244: 'function' : conversion from 'double ' to 'long ', possible loss of data FastCalc.xs(399) : warning C4244: '+=' : conversion from 'double ' to 'unsigned int ', possible loss of data -- Report by Test::Smoke v1.19_72 build 895 running on perl v5.9.3 (Reporter v0.026 / Smoker v0.026) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: Time::HiRes::nanosleep support for Solaris [PATCH]
On 15 Aug 2005 21:05:22 -0700, Gisle Aas [EMAIL PROTECTED] wrote: /tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda Thats quite the directory name there, must be a bitch to type yves -- perl -Mre=debug -e /just|another|perl|hacker/
Smoke [5.9.3] 25294 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25294 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(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 25294 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../t/op/int.t...FAILED 11 Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 [perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: lib/test/simple/t/create.t help with VMS issue needed.
sebb [EMAIL PROTECTED] wrote on 08/15/2005 08:34:31 PM: Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? I meant for READ access only here. The performance impact of altering perl's open() to use the CRTL shr would be significant. Ordinary perl usage would slow to a crawl. Folks who want shr can load and use VMS::Stdio::vmsopen() and pay the performance penalty. Peter Prymmer
Fw: Re: [PATCH] Re: Transliteration operator(tr//)on EBCDIC platform
perl5 porters,
There is a response in approval from Sastry to my proposed patch.
I'll forward it and now submit the proposal (on my prev mail) to p5p.
Regards,
SADAHIRO Tomoyuki
Forwarded by SADAHIRO Tomoyuki [EMAIL PROTECTED]
--- Original Message ---
From:Sastry [EMAIL PROTECTED]
To: SADAHIRO Tomoyuki [EMAIL PROTECTED]
Date:Tue, 16 Aug 2005 15:27:45 +0530
Subject: Re: [PATCH] Re: Transliteration operator(tr//)on EBCDIC platform
Hi
The patch works now as expected.
Thanks
-Sastry
On 8/11/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
On Wed, 10 Aug 2005 23:56:31 -0700 (PDT), rajarshi das [EMAIL PROTECTED]
wrote
Hi,
This is Rajarshi expressing Sastry's viewpoints since he's on vacation.
SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
According to the above statement in perlebcdic.pod,
s/[\x89-\x91]/X/g must substitute \x8e with X.
But it doesn't concern whether tr/\x89-\x91/X/ would substitute \x8e
with X or not, since tr/// does not use brackets, [ ].
Though I think ranges in [ ] and ranges in tr/// should coincide
and agree that tr/\x89-\x91/X/ should substitute \x8e with X,
that is just my opinion.
I don't know whether it is true and correct.
Is there some way we can confirm if this is correct (and expected behaviour)
since there isnt any explicit documentation for the tr operator ?
Since t/op/tr.t already has a test case (cf. Change 9038)
which Sastry previously pointed out its failing on EBCDIC Platform,
I assume that at least the then pumpking thought it to be correct.
By the way, when you say If I specify [\x89-\x91], does it
mean s/[\x89-\x91]/X/g or tr/\x89-\x91/X/ ? I'm confused.
We mean tr/\x89-\x91/X/.
We are first informed by you that gapped characters are not
substituted with X by tr/\x89-\x91/X/.
And you said s/[\x89-\x91]/X/g substituted all the characters
including gapped characters with X, hadn't you?
Yes.
If so, I assume your [\x89-\x91] which doesn't matching any of
the gapped characters to be tr/\x89-\x91/X/.
That's correct. We mean tr/\x89-\x91/X/.
The following is a part of the current core tests from op/pat.t.
I believe they should be passed.
Yes all the following tests pass. I think the following tests are in the
context of the
s/[]/X/ operator and hence pass.
Thanks,
Rajarshi.
OK. To me, it is confirmed that s/[]/X/ is fine and tr/// has a problem.
Since I don't have any EBCDIC machine, I can't ensure the following
patch will really makes sense.
Regards,
SADAHIRO Tomoyuki
! t/op/tr.t, toke.t
diff -ur perl~/t/op/tr.t perl/t/op/tr.t
--- perl~/t/op/tr.t Mon Aug 01 17:17:24 2005
+++ perl/t/op/tr.t Thu Aug 11 23:41:22 2005
@@ -295,18 +295,15 @@
# (i-j, r-s, I-J, R-S), [\x89-\x91] [\xc9-\xd1] has to match them,
# from Karsten Sperling.
-# Not working in EBCDIC as of 12674.
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/;
is($c, 8);
is($a, );
-
-# Not working in EBCDIC as of 12674.
+
$c = ($a = \xc9\xca\xcb\xcc\xcd\xcf\xd0\xd1) =~ tr/\xc9-\xd1/X/;
is($c, 8);
is($a, );
-
-SKIP: {
+SKIP: {
skip not EBCDIC, 4 unless $Is_EBCDIC;
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/i-j/X/;
diff -ur perl~/toke.c perl/toke.c
--- perl~/toke.cMon Jul 18 04:31:02 2005
+++ perl/toke.c Thu Aug 11 22:55:18 2005
@@ -1368,6 +1368,9 @@
I32 has_utf8 = FALSE; /* Output constant is UTF8 */
I32 this_utf8 = UTF; /* The source string is
assumed to be UTF8 */
UV uv;
+#ifdef EBCDIC
+UV literal_endpoint = 0;
+#endif
const char *leaveit = /* set of acceptably-backslashed characters */
PL_lex_inpat
@@ -1417,8 +1420,9 @@
}
#ifdef EBCDIC
- if ((isLOWER(min) isLOWER(max)) ||
- (isUPPER(min) isUPPER(max))) {
+ if (literal_endpoint == 2
+ ((isLOWER(min) isLOWER(max)) ||
+(isUPPER(min) isUPPER(max {
if (isLOWER(min)) {
for (i = min; i = max; i++)
if (isLOWER(i))
@@ -1437,6 +1441,9 @@
/* mark the range as done, and continue */
dorange = FALSE;
didrange = TRUE;
+#ifdef EBCDIC
+ literal_endpoint = 0;
+#endif
continue;
}
@@ -1455,6 +1462,9 @@
}
else {
didrange = FALSE;
+#ifdef EBCDIC
+ literal_endpoint = 0;
+#endif
}
}
@@ -1788,6 +1798,10 @@
s++;
continue;
} /* end if (backslash) */
+#ifdef EBCDIC
+ else
+ literal_endpoint++;
+#endif
default_action:
/* If we started with encoded form, or already know we want it
###END OF PATCH
Getopt::Long bundling bug
On Tue, Aug 16, 2005 at 05:55:02AM +0400, Alexey Tourbin wrote: Does this make any sense? Now I use Pod::Usage in my scripts, and it works almost fine. Here is another issue: I use Getopt::Long, too. $ perl -MGetopt::Long=GetOptions -e 'GetOptions(v|verbose+=$v)' -- --verbosex Unknown option: verbosex $ perl -MGetopt::Long=GetOptions,:config,bundling -e 'GetOptions(v|verbose+=$v)' -- --verbosex Unknown option: v $ perl -MGetopt::Long=GetOptions,:config,gnu_getopt -e 'GetOptions(v|verbose+=$v)' -- --verbosex Unknown option: v $ I believe the latter error message is inappropriate. First, the option is --verbosex, not -v. Second, option -v is known, not unknown. pgphA4pKpvLzK.pgp Description: PGP signature
RE: lib/test/simple/t/create.t help with VMS issue needed.
sebb wrote: JEM wrote: Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? I'll jump in here with my own 2-cents worth. On VMS, the default behavior makes sense. VMS is a multi-user system, and when you open a file, the default access is exclusive. VMS has rich file sharing semantics, so it is easy to change this behavior; but a VMS user expects default access to be exclusive. Changing this behavior to conform to perl usage on other OSes could be a configuration option; but the default no surprise behavior should be exclusive access. Most of the files I use within Perl are flat text files where file sharing would not be feasible. If a VMS programmer is working on a VMS RMS indexed or RMS relative file organization, then a different sharing option might be appropriate, but that needs to be dealt with in VMS-specfic .xs files that manipulate those files. Again, just my 2 cents. Carl Friedberg [EMAIL PROTECTED] +1.212.233.5470 www.comets.com
Re: lib/test/simple/t/create.t help with VMS issue needed.
On 16/08/05, John E. Malmberg [EMAIL PROTECTED] wrote: sebb wrote: On 14/08/05, John E. Malmberg [EMAIL PROTECTED] wrote: Tests 7 and 8 for this script are failing on VMS. Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? Carl Friedberg explained about the VMS default behavior. The logical name DECC$FILE_SHARING will locally change the behavior of applications to be follow it, and this can be turned on and off locally inside of a Perl script on VMS now. It turns off all file locking by applications that open files through the C runtime support. Yes, I just think this should not be necessary. The issue that I can not work around is the one that you did not quote, and that is that data from the test module has not yet been written to the disk because the file is not closed, or an fsync() call has not been made for it. Sounds as though the test may perhaps not be valid... I.e. is it sensible for the test to assume that the file will have been flushed? -John [EMAIL PROTECTED] Personal Opinion Only
Re: lib/test/simple/t/create.t help with VMS issue needed.
On 16/08/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: sebb [EMAIL PROTECTED] wrote on 08/15/2005 08:34:31 PM: Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? I meant for READ access only here. The performance impact of altering perl's open() to use the CRTL shr would be significant. Ordinary perl usage would slow to a crawl. Folks who want shr can load and use VMS::Stdio::vmsopen() and pay the performance penalty. I've not noticed vmsopen() causing any read performance problems, and I don't recall this being mentioned in regard to DECC$FILE_SHARING. Is this true with recent CRTLs?
[perl #36908] ?{ ...}) code loses local vars on subsequent matches
# New Ticket Created by Dan Dascalescu
# Please include the string: [perl #36908]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36908
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]
If you set a local my variable in a (?{ ... }) regexp code chunk,
its value will be lost upon exiting the regexp, on subsequent
matches of that regexp. The variable properly retains its value
after the first match of the regexp.
Please find test case below.
#! perl -w
# (?{ ... }) regexp code loses local variables on subsequent euns
use strict;
for(1..3) {
my $R = 'local'; # make it global to work
print $R ne 'local' ? ok : not ok, $_\n
if 'x foo y' =~ m{ (foo)
(?{ #warn Matched $^N and \$^R is about to be set to:\n;
$R = last regexp code result
})
}x;
}
Hope that helps,
Dan Dascalescu
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=low
---
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:D:\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:D:\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:
D:/Perl/lib
D:/Perl/site/lib
.
---
Environment for perl v5.8.7:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=D:\Perl\bin\;c:\jdk1.3.1\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program
Files\Microsoft Visual Studio\VC98\Bin;C:\Program Files\Microsoft
Visual Studio\Common\MSDev98\Bin
PERL5LIB=D:\Perl\lib\
PERLDB_OPTS=RemotePort=127.0.0.1:2000
PERL_BADLANG (unset)
SHELL (unset)
Re: lib/test/simple/t/create.t help with VMS issue needed.
On 15/08/05, Carl Friedberg [EMAIL PROTECTED] wrote: sebb wrote: JEM wrote: Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? I meant for READ access only here. I'll jump in here with my own 2-cents worth. On VMS, the default behavior makes sense. VMS is a multi-user system, and when you open a file, the default access is exclusive. VMS has rich file sharing semantics, so it is easy to change this behavior; but a VMS user expects default access to be exclusive. I use VMS and I don't ... For example, the VMS TYPE command allows one to look at the contents of batch LOG files, but Perl cannot _read_ the same file without the work-round above (or vmsopen() with suitable parameters). Changing this behavior to conform to perl usage on other OSes could be a configuration option; but the default no surprise behavior should be exclusive access. IMO, the surprise in this case is that Perl can't open a file that TYPEs OK ... Most of the files I use within Perl are flat text files where file sharing would not be feasible. Not even _read_ access? If a VMS programmer is working on a VMS RMS indexed or RMS relative file organization, then a different sharing option might be appropriate, but that needs to be dealt with in VMS-specfic .xs files that manipulate those files. Again, just my 2 cents. Carl Friedberg [EMAIL PROTECTED] +1.212.233.5470 www.comets.com
Re: lib/test/simple/t/create.t help with VMS issue needed.
On 14/08/05, John E. Malmberg [EMAIL PROTECTED] wrote: Tests 7 and 8 for this script are failing on VMS. Test 7 is failing because normally on VMS, unless you specify otherwise, you get exclusive access to the file, so the second open is failing. The logical name DECC$FILE_SHARING defined as ENABLE will change VMS behavior to that of UNIX which will allow test 7 to pass. I can probably come up with some code to have the script on VMS make sure that that value is set and to clear it on exit. Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? S.
Re: Getopt::Long bundling bug
On Tue, Aug 16, 2005 at 06:27:46PM +0400, Alexey Tourbin wrote:
$ perl -MGetopt::Long=GetOptions -e 'GetOptions(v|verbose+=$v)' --
--verbosex
Unknown option: verbosex
$ perl -MGetopt::Long=GetOptions,:config,bundling -e
'GetOptions(v|verbose+=$v)' -- --verbosex
Unknown option: v
$ perl -MGetopt::Long=GetOptions,:config,gnu_getopt -e
'GetOptions(v|verbose+=$v)' -- --verbosex
Unknown option: v
$
I believe the latter error message is inappropriate. First, the option
is --verbosex, not -v. Second, option -v is known, not unknown.
This appears to be fixed in Getopt-Long-2.34_04, with the following hunk:
@@ -903,7 +959,7 @@ sub FindOption () {
unless ( defined $ctl ) {
return (0) if $passthrough;
# Pretend one char when bundling.
- if ( $bundling == 1) {
+ if ( $bundling == 1 length($starter) == 1 ) {
$opt = substr($opt,0,1);
unshift (@ARGV, $starter.$rest) if defined $rest;
}
pgpVv28Vby3EY.pgp
Description: PGP signature
Re: lib/test/simple/t/create.t help with VMS issue needed.
Sebb wrote: On 15/08/05, Carl Friedberg [EMAIL PROTECTED] wrote: sebb wrote: On VMS, the default behavior makes sense. VMS is a multi-user system, and when you open a file, the default access is exclusive. VMS has rich file sharing semantics, so it is easy to change this behavior; but a VMS user expects default access to be exclusive. I use VMS and I don't ... For example, the VMS TYPE command allows one to look at the contents of batch LOG files, but Perl cannot _read_ the same file without the work-round above (or vmsopen() with suitable parameters). You are only seeing that behavior because of that the log files for batch jobs explicitly were opened in a way that allows other programs to read them. Note that a large amount of data in the log file may not have yet been written to disk, and is unavailable to the type command. If you write an application that opens a file with the default options and then sleeps, you will find that TYPE and other non-privileged applications will not be able to access the file at all. Changing this behavior to conform to perl usage on other OSes could be a configuration option; but the default no surprise behavior should be exclusive access. IMO, the surprise in this case is that Perl can't open a file that TYPEs OK ... Perl can access any file that TYPEs ok. That is not the issue here. Type has no more privileges or features than Perl does in this case. If pause the lib/test/simple/t/create/t test in the debugger just before Perl tries to open it again for read access, and then spawn to DCL or use another terminal session, you will find that Type also has no access to that file. If you define DECC$FILE_SHARING ENABLE before the running the test again, you will find that both perl and Type will be able to access the file, except that they both may display it as empty. A change in behavior in Perl by default would break any existing scripts on VMS that depend on the traditional VMS behavior. A very high probability of data corruption could result. John Malmberg wrote: : The issue that I can not work around is the one that you did not quote, : and that is that data from the test module has not yet been written to : the disk because the file is not closed, or an fsync() call has not been : made for it. Sounds as though the test may perhaps not be valid... I.e. is it sensible for the test to assume that the file will have been flushed? If it is assuming that the platform it is running on is compliant with the X/Open Single Unix Specification for such I/O, it should not assume that the file has been flushed unless the file is closed or fsync() has been called. Usually when I have encountered a program that does not work on VMS because the program is expecting a different behavior than documented by X/Open or other official UNIX/ANSI/ISO standards, with in a year, I see of report of a real UNIX implementation where that program does not work for the same reason. On 16/08/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The performance impact of altering perl's open() to use the CRTL shr would be significant. Ordinary perl usage would slow to a crawl. Folks who want shr can load and use VMS::Stdio::vmsopen() and pay the performance penalty. I've not noticed vmsopen() causing any read performance problems, and I don't recall this being mentioned in regard to DECC$FILE_SHARING. Is this true with recent CRTLs? I am not aware of any performance penalty for turning off the file locking. The vmsopen() probably allows even better tuning of the open request to the use of the file than the Perl open() routine. If there is a performance penalty between the two calls, I would look for a different cause. -John
Smoke [5.9.0] 25294 FAIL(m) openbsd 3.6 (i386/1 cpu)
Automated smoke report for 5.9.0 patch 25294 accognoscere.homeunix.org: AMD Athlon(TM) XP 1800+ (AuthenticAMD 686-class) (i386/1 cpu) onopenbsd - 3.6 using cc version 2.95.3 20010125 (prerelease, propolice) smoketime 3 minutes 1 seconds (average 22.625 seconds) Summary: FAIL(m) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25294 Configuration (common) none --- - m - m - m - m - -Duse64bitint m - m - -Duseithreads m - m - -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio -- Report by Test::Smoke v1.19#716 running on perl 5.8.5 (Reporter v0.016 / Smoker v0.015)
[perl #36909] $^R undefined on matches involving backreferences
# New Ticket Created by Dan Dascalescu
# Please include the string: [perl #36909]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36909
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]
The LAST_REGEXP_CODE_RESULT ($^R) variable appears to not be set
in regexp matches involving a backreference. In the example below,
if you uncomment one of the two commented regexps and comment the
'(foo|bar)\1+' regexp, $^R will be properly set.
#! perl -w
# $^R undefined on matches involving backreferences
use strict;
print $^R, \n if 'x foofoo y' =~ m{
#(foo) # $^R correctly set
#(?:foo|bar)+ # $^R correctly set
(foo|bar)\1+ # $^R undefined
(?{ warn Matched, defined $^N? $^N:,
and \$^R is about to be set to:\n; last regexp code result
})
}x
Hope that helps,
Dan Dascalescu
[Please do not change anything below this line]
-
---
Flags:
category=core
severity=low
---
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:D:\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:D:\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:
D:/Perl/lib
D:/Perl/site/lib
.
---
Environment for perl v5.8.7:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=D:\Perl\bin\;c:\jdk1.3.1\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program
Files\Microsoft Visual Studio\VC98\Bin;C:\Program Files\Microsoft Visual
Studio\Common\MSDev98\Bin
PERL5LIB=D:\Perl\lib\
PERLDB_OPTS=RemotePort=127.0.0.1:2000
PERL_BADLANG (unset)
SHELL (unset)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Time::HiRes::nanosleep support for Solaris [PATCH]
demerphq [EMAIL PROTECTED] writes: On 15 Aug 2005 21:05:22 -0700, Gisle Aas [EMAIL PROTECTED] wrote: /tmp/perl-aekojpkufyzuasapckiyadszkxhdobbloqazueglxwkksqoohxylbukriemwutaerimizyjbxfnynbotpkfurxdgmkhwefhqxhyptjatvzulotpskbfuda Thats quite the directory name there, must be a bitch to type Yeah, but remember that we have a whole room full of monkeys to do the typing for us :) ActivePerl is actually built with prefixes like the one above. At install time we patch up the binaries with the path where perl is installed. --Gisle
Re: [perl #36839] \xA0 (non-breaking space) does and doesn't matc h \s
Konovalov, Vadim wrote: However, this is *the* unfixable UTF-8 bug in Perl 5 - the fact that 1 bit is used as a flag that both signals buffer is encoded as UTF-8 and string should use Unicode rather than bytes semantics But may be those two concepts should be considered synonyms in this context? You can convert from bytes to Unicode. The problem is that perl silently assumes latin-1 encoding when doing so, for backwards compatibility reasons. The module encoding::warnings, which is core in bleadperl, is actually quite helpful in those cases, as it will detect potential bugs. -- Only what happens every three hundred nights is true. -- Borges
Re: Time::HiRes::nanosleep support for Solaris [PATCH]
H.Merijn Brand wrote: On 15 Aug 2005 21:05:22 -0700, Gisle Aas [EMAIL PROTECTED] wrote: I noticed that our Solaris builds ends up with a Time::HiRes module that does not support nanosleep. This happens because the Solaris hints file for Time::HiRes tries to use the POSIX module that is not available when the module is built as part of the core. This is what I see in our build logs: Thanks, applied as change #25295 Time::HiRes 1.73 uploaded. --Gisle
[perl #36918] Sed 2 perl (s2p) bug report file attached
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36918] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36918 Hi People: A perlbug report document generated by perlbug is attached. The report, as well as this email, contains suggested work arounds for problems I encountered with s2p on Win98SE. I had problems in sending the report through perlbug probably due to issues with the linkage between my perl tools and my email program. The following is from an forum entry I made on one of the CPAN forums. The response from Graham Barr via RT [EMAIL PROTECTED] suggesting I send it to perlbug is shown below. [ JJ: I have recently installed the downloaded and installed the ActivePerl distribution for Win32. I intend to used Perl to replace some DOS BATCH files which in turn use AWK and Sed scripts. ] 1: The s2p page at: http://search.cpan.org/perldoc?s2p is missing. [ GB: /perldoc is currently undergoing some changes to prevent namespace hijacking. Thanks for letting me know that some documents are not working. For issues with s2p you need to report them with perlbug. This forum is only for feedbackabout the search site. Graham.] 2: s2p does not run [ well ] on Win98Se. [ JJ: I tried making a C:\tmp directory (like there is on UNIX) and it looks like s2p like this. Perhaps this could be included in the ENVIRONMENT section in the document at: http://www.perl.com/doc/manual/html/x2p/s2p.html ] [ JJ: After creating the directory C:\tmp s2p ran but did not pipe its output to the Win96SE DOS Standard Output to create a Perl file using the format perl s2p sedfile newperlfile . I was able to find the Perl scripts generated by s2p in the C:\tmp directory created above. ] 3: s2p does not have a help display like a2p. [ JJ: I have not yet moved to working on the AWK scripts but the Perl code generated by s2p for even a simple Sed script is more complex than I expected and I am rethinking the move to Perl from Sed and AWK. ] Thanks John Johnson [EMAIL PROTECTED]This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.33 running under perl v5.6.1. - [Please enter your report here] 1: The s2p page at: http://search.cpan.org/perldoc?s2p is missing. JJ: answered by Graham Barr paraphrased as: thanks for the information on the page error. The rest should go to perlbug. 2: s2p does not run [ well ] on Win98Se. Work around: add the C:\tmp directory, like there is on Unix (see below). 3: s2p does not have a help display like a2p. 4: s2p (ActiveState win32 port) does not send its output to the Win32 stanbard output. Work around: I found s2p output in C:\tmp. Explanations: I did look around for FAQs and other information; see No. 1 above. I have recently installed the downloaded and installed the ActivePerl distribution for Win32. I intend to used PERL to replace some DOS BATCH files which in turn use AWK and SED scripts. After writing and testing some PERL scripts I went to use s2p to convert the SED scripts to PERL scripts. s2p would not run and retunrned the message : Can't open temp file: null No Such file or directory I think I am going to have to modify S2P.BAT in C:\PERL\BAT to get it to work. I tried making a C:\tmp directory (like there is on UNIX) and it looks like s2p like this. Perhaps this could be included in the ENVIRONMENT section in the document at: http://www.perl.com/doc/manual/html/x2p/s2p.html With C:\tmp I could get s2p to run but the following would not work as documented: perl sp2 sedfile perlfile perlfile would be created but would be 0 length, i.e. the output of s2p would not be directed to the standard output or the ^Z (close stream) would not be output. The output of s2p was however directed to the screen. I have not yet moved to working on the AWK scripts. Thanks John Johnson [EMAIL PROTECTED] [Please do not change anything below this line] - --- Flags: category=utilities severity=low --- Site configuration information for perl v5.6.1: Configured by ActiveState at Tue Apr 13 19:24:10 2004. Summary of my perl5 (revision 5 version 6 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cl', ccflags ='-nologo -O1 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX',
Re: lib/test/simple/t/create.t help with VMS issue needed.
On 16/08/05, John E. Malmberg [EMAIL PROTECTED] wrote: Sebb wrote: On 15/08/05, Carl Friedberg [EMAIL PROTECTED] wrote: sebb wrote: On VMS, the default behavior makes sense. VMS is a multi-user system, and when you open a file, the default access is exclusive. VMS has rich file sharing semantics, so it is easy to change this behavior; but a VMS user expects default access to be exclusive. I use VMS and I don't ... For example, the VMS TYPE command allows one to look at the contents of batch LOG files, but Perl cannot _read_ the same file without the work-round above (or vmsopen() with suitable parameters). Actually it seems to depend on the log file - see below. You are only seeing that behavior because of that the log files for batch jobs explicitly were opened in a way that allows other programs to read them. Note that a large amount of data in the log file may not have yet been written to disk, and is unavailable to the type command. Agreed. If you write an application that opens a file with the default options and then sleeps, you will find that TYPE and other non-privileged applications will not be able to access the file at all. Changing this behavior to conform to perl usage on other OSes could be a configuration option; but the default no surprise behavior should be exclusive access. IMO, the surprise in this case is that Perl can't open a file that TYPEs OK ... Perl can access any file that TYPEs ok. That is not the issue here. With Perl 5.5A3 I get: $ perl -n -e print sys$manager:operator.log Can't open sys$manager:operator.log: file currently locked by another user With 5.6.1, I get: $ perl -n -e print sys$manager:operator.log Can't open sys$manager:operator.log: error in directory name. Both work OK if I define DECC$FILE_SHARING Type has no more privileges or features than Perl does in this case. Indeed, but presumably it opens the file slightly differently. If pause the lib/test/simple/t/create/t test in the debugger just before Perl tries to open it again for read access, and then spawn to DCL or use another terminal session, you will find that Type also has no access to that file. If you define DECC$FILE_SHARING ENABLE before the running the test again, you will find that both perl and Type will be able to access the file, except that they both may display it as empty. A change in behavior in Perl by default would break any existing scripts on VMS that depend on the traditional VMS behavior. A very high probability of data corruption could result. In which case the data corruption could also be caused by a non-Perl program, surely? Or indeed a Perl program run with file-sharing enabled. [...] On 16/08/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The performance impact of altering perl's open() to use the CRTL shr would be significant. Ordinary perl usage would slow to a crawl. Folks who want shr can load and use VMS::Stdio::vmsopen() and pay the performance penalty. I've not noticed vmsopen() causing any read performance problems, and I don't recall this being mentioned in regard to DECC$FILE_SHARING. Is this true with recent CRTLs? I am not aware of any performance penalty for turning off the file locking. The vmsopen() probably allows even better tuning of the open request to the use of the file than the Perl open() routine. If there is a performance penalty between the two calls, I would look for a different cause. -John
Re: lib/test/simple/t/create.t help with VMS issue needed.
On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote:
There does not seem to be a method of explicitly closing or flushing the
output stream being written to by Test::Builder.
Any ideas on how to resolve this?
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.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- Lords and Ladies by Terry Prachett
=== t/create.t
==
--- t/create.t (revision 2525)
+++ t/create.t (local)
@@ -16,22 +16,24 @@
use Test::Builder;
my $more_tb = Test::More-builder;
-my $new_tb = Test::Builder-create;
-
-isa_ok $new_tb, 'Test::Builder';
isa_ok $more_tb, 'Test::Builder';
-isnt $more_tb, $new_tb, 'Test::Builder-create makes a new object';
-
is $more_tb, Test::More-builder, 'create does not interfere with -builder';
is $more_tb, Test::Builder-new, ' does not interfere with -new';
-$new_tb-output(some_file);
-END { 1 while unlink some_file }
+{
+my $new_tb = Test::Builder-create;
-$new_tb-plan(tests = 1);
-$new_tb-ok(1);
+isa_ok $new_tb, 'Test::Builder';
+isnt $more_tb, $new_tb, 'Test::Builder-create makes a new object';
+$new_tb-output(some_file);
+END { 1 while unlink some_file }
+
+$new_tb-plan(tests = 1);
+$new_tb-ok(1);
+}
+
pass(Changing output() of new TB doesn't interfere with singleton);
ok open FILE, some_file;
Re: [perl #36853] -Dx can crash bleadperl
Dominic Dunlop (via RT) wrote: The following is seen in a debugging [EMAIL PROTECTED], but not in a debugging perl5.8.7: $ ./perl -Ilib -Dx -MConfig -e 1 # or -Mstrict, or ... Thanks, fixed by change #25296. [...] Segmentation fault
[perl #36922] perl crash on cygwin
# New Ticket Created by Anton Ivanov
# Please include the string: [perl #36922]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36922
This is perl, v5.8.7 built for cygwin-thread-multi-64int
The code is basically doing this:
sub merge {
#map tokens to arrays of datums that contain them.
my %token_map;
foreach my $darr (@_) {
foreach my $d (@$darr) {
my $t = $d-token;
$token_map{$t} = [] unless defined $token_map{$t};
push @{$token_map{$t}}, $d;
}
}
#construct a counts hash by averaging the percentiles across those
#arrays
my %counts;
my $total = 0.0;
foreach my $t (keys %token_map) {
my $val = avrg(map {$_-perc} @{$token_map{$t}});
$total += $val;
$counts{$t} = $val;
}
#do something with the counts hash
#DistDatum::dist_from_counts(\%counts, $total);
}
merge gets called with 3 array references, the largest of which contains
363477 items. If I call it on 2 somewhat smaller arrays, the crash does
not happen.Exception: STATUS_ACCESS_VIOLATION at eip=610C4914
eax= ebx=0004 ecx=0001 edx= esi=611A83F8 edi=
ebp=0022E9F8 esp=0022E9EC program=C:\cygwin\bin\perl.exe, pid 2068, thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function Args
0022E9F8 610C4914 (, 611A83F8, 0004, 6109A563)
0022EA38 6100275E (, , 0022EB2C, )
0022EA68 61050C8E (61157DB0, , 4A70, 0001)
0022EB78 610516E4 (, 1000, 0001, 0022)
0022EBA8 61051F79 (, 1000, 0003, 0022)
0022EC48 610AB36C (0022EC80, DF0DF047, , )
0022EC78 6104ED0A (0008, 2000, 0022EF88, 7C8399F3)
0022EC98 610844FF (0008, , , )
0022ECC8 6E8C0A4E (10010248, 032A0E80, 0008, )
0022ED18 6E8D68E3 (10010248, 032A0E80, 24F78624, 0012)
0022ED48 6E8D7CED (10010248, 24F78624, 00063792, 032A0E74)
0022EDB8 6E8B46E1 (10010248, 10010248, 0022EEE8, 6E847845)
0022EDC8 6E8B1B89 (10010248, , 0022EEC8, 0001)
0022EEE8 6E847845 (10010248, 00401190, 0003, 61159490)
0022EF18 00401170 (0003, 61159490, 10010090, 7C919AF0)
0022EFD8 61004DD2 (0022EFF0, , , )
End of stack trace (more stack frames may be present)
File::Temp: euid in _is_safe(); safe_level(MEDIUM) for taint mode
Hello,
The patch is explained below.
--- File/Temp.pm- 2005-04-03 15:27:16 +
+++ File/Temp.pm2005-08-16 22:50:39 +
@@ -679,11 +679,11 @@ sub _is_safe {
return 1 if $^O eq 'VMS'; # owner delete control at file level
# Check to see whether owner is neither superuser (or a system uid) nor me
- # Use the real uid from the $ variable
+ # Use the effective uid from the $ variable
# UID is in [4]
- if ($info[4] File::Temp-top_system_uid() $info[4] != $) {
+ if ($info[4] File::Temp-top_system_uid() $info[4] != $) {
-Carp::cluck(sprintf uid=$info[4] topuid=%s \$=$ path='$path',
+Carp::cluck(sprintf st_uid=$info[4] topuid=%s euid=$ path='$path',
File::Temp-top_system_uid());
$$err_ref = Directory owned neither by root nor the current user
@@ -2241,4 +2241,10 @@ security enhancements.
=cut
+{
+no strict 'refs';
+File::Temp-safe_level(MEDIUM)
+if ${\cTAINT};
+}
+
1;
End of patch
First, real/effective UID distinction is essential for setuid scripts.
Filesystem permissions are controlled by the effective UID of the
process. When a privileged script is checking if the directory is safe,
it should check that the directory is *not* owned by the caller.
Otherwise, the user can replace a temporary file created by the
privileged process, which is almost certainly not what we want.
Second, I suggest to enable MEDUM security level for taint mode,
which is on when running setuid/setgid scripts. It's only on MEDUM
level that the above _is_safe() security check is performed.
pgpCpP9VmHh0V.pgp
Description: PGP signature
Re: lib/test/simple/t/create.t help with VMS issue needed.
Michael G Schwern wrote: On Sat, Aug 13, 2005 at 10:33:45PM -0400, John E. Malmberg wrote: There does not seem to be a method of explicitly closing or flushing the output stream being written to by Test::Builder. Any ideas on how to resolve this? 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 -John [EMAIL PROTECTED] Personal Opinion Only
Ping? [PATCH] Re: [perl #36654] Inconsistent treatment of NaN
Can the patches in: http://nntp.perl.org/group/perl.perl5.porters/103801 and http://nntp.perl.org/group/perl.perl5.porters/103906 be applied (or receive feedback)? Thanks.
