Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
On Wed, Dec 29, 2004 at 10:49:57PM -0600, Craig A. Berry wrote: What's happened here is that MMK has successfully processed the silent prefix but ignored the ignore prefix. It apparently takes whichever one it comes to last when there is space between them. MMS, on the other hand, has successfully processed the ignore prefix but has treated the silent prefix as part of the command; it apparently takes whichever one it comes to first. Furthermore, I can't see any way to make the ignore prefix work as a macro. The decision about whether the success or failure of a command will be taken into account apparently happens before macro substitution in both MMK and MMS. This has been fixed. I've moved back to a literal - and am using -$(NOECHO) command which seems to make everybody happy. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
On Thu, Dec 30, 2004 at 08:36:54AM -0600, Craig A. Berry wrote:
2.) MM_Unix::fixin doesn't seem to clean up properly on VMS. Here's
an example borrowed from the $(INST_SCRIPT)instmodsh target showing
that it successfully creates a new file with the .new extension but
does not rename it back to the original name:
Investigated this. exe files weren't getting installed on VMS as a result.
The problem appears to be a bug in rename() on 5.8.0 (and whatever version
of Perl you're using). It does the following:
rename('[.blib.script]instmodsh.new', '[.blib.script]instmodsh');
rename() returns 1 however the file is not renamed. It appears rename()
will not work unless there's a dot in the filename. So I hacked up a
rename() wrapper that appends a dot onto a filename if it doesn't have one.
I've also add some tests to ensure executables get installed.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Worship the sig file
[ANNOUNCE] ExtUtils::MakeMaker 6.25_07
http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_07.tar.gz or svn://svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you. Release candidate number *mumble* for 6.26. Fixed a bunch of minor VMS issues Craig noticed. Also papered over the dmake problem uncovered by installbase.t in the hopes that an updated dmake becomes available soon and the problem goes away. 6.25_07 Fri Dec 31 03:47:20 EST 2004 - perllocal on VMS was inserting executables twice. - No longer using $(IGNORE) macro. Turns out MMS/K was not honoring it. Using -$(NOECHO) command which seems to make everybody happy. - Executables with no extension weren't getting installed on VMS due to a bug in rename(). Broken sometime in this series of alphas. 6.25_06 Sun Dec 26 17:21:37 EST 2004 - Forgot to define BOOTDEP macro. - .exists files are back. Directories cannot be used directly as targets as their mod time changes too frequently. * Added INSTALLBASE as an alternative to PREFIX but haven't documented it yet. I'll do that next release. 6.25_05 Wed Dec 22 07:59:02 EST 2004 - One of the 6.25 alphas broke BSD make. It doesn't like - @ command. Fixed by adding an $(IGNORE) macro. - 6.25 alphas caused a Makefile to be added to the dist. Fixed. - The new cd() code needed to be dependent on dmake or nmake for Windows. Not Win9x vs WinNT/XP. 6.25_04 Tue Dec 21 00:53:06 EST 2004 - 6.25_03 was always rebuilding XS modules. 6.25_03 Mon Dec 20 23:04:22 EST 2004 - dir_target() is back. Now each directory to be created has its own target like before, but no more .exists or blibdirs.ts files. This ensures that each blib directory is created as necessary and fixes things like SVN's perl bindings. 6.25_02 Mon Dec 20 03:31:49 EST 2004 - Set PM_FILTER as late as possible so it can see all the earlier macro definitions. Necessary for challenged make implementations like nmake. Should fix Mail::SpamAssassin installs on Win32. [rt.cpan.org 4545] - clean and realclean are now more careful about accidentally deleting directories instead of files. [rt.cpan.org 6851] - small fix for parallel builds, make sure pm_to_blib has run before we try to use stuff in blib. [rt.cpan.org 6460] - MAKEFILE=foo appears to have been broken for recursive builds and several other things. I think this was broken by 6.18. 6.25_01 Fri Dec 17 21:29:04 EST 2004 * *.bak added to the default MANIFEST.SKIP. * META.yml will no longer be generated in the build directory. It will only appear in the distdir. This should make it easier on developers, they don't have to worry about checking the file in all the time. * Similarly, the SIGNATURE file will not be updated in the build directory. It will only be generated in the distdir. - A bunch of redundant Win9x and VMS code removed. - 'make test' on Windows no longer pre-expands its list of test files. This caused problems on large distributions like bioperl. Thanks to Tim Bunce for suggesting the obvious fix. 6.25 Wed Dec 15 06:59:46 EST 2004 - Build.PL was being considered like Module_pm.PL. Build.PL is now ignored. [EMAIL PROTECTED] [rt.cpan.org 8809] - Devel::Cover cover_db/ directory now ignored by MANIFEST.SKIP -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ I know you get this a lot, but what's an unholy fairy like you doing in a mosque like this?
[perl #33607] Problems in Perl 5.6.1
# New Ticket Created by Sravanth Kumar Nagunuri # Please include the string: [perl #33607] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33607 Perl Version: This is perl, v5.6.1 built for PA-RISC2.0 We have ported our application from PERL5.0.1 to PERL5.6.1 We got the following error during execution of our perl script. -- Cant locate object method ToUpper via package main (perhaps you forgot to load main?) at /d/nmsopt/nokianms/lib/perl5/5.6.1/utf8_heavy.pl line 30, CONFIG line 59.. Terminating - We could not find method ToUpper in any library of 5.6.1. Basically the error message says that main package is not loaded. We don't have a method ToUpper in our Perl code also. How to locate this method and how to correct this situation? Please let us know how to over come this situation. Regards, Sravanth Kumar Nagunuri Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments.
[perl #33608] Problems in Perl 5.6.1 (Cant locate object method ToUpper via package main (perhaps you forgot to load main?) )
# New Ticket Created by Sravanth Kumar Nagunuri # Please include the string: [perl #33608] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33608 We have ported our application from PERL5.0.1 to PERL5.6.1 We got the following error during execution of our perl script. -- Cant locate object method ToUpper via package main (perhaps you forgot to load main?) at /d/nmsopt/nokianms/lib/perl5/5.6.1/utf8_heavy.pl line 30, CONFIG line 59.. Terminating - We could not find method ToUpper in any library of 5.6.1. Basically the error message says that main package is not loaded. We don't have a method ToUpper in our Perl code also. How to locate this method and how to correct this situation? Please let us know how to over come this situation. Perl Version: This is perl, v5.6.1 built for PA-RISC2.0 Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=hpux, osvers=11.11, archname=PA-RISC2.0 uname='hp-ux turtola b.11.11 u 9000785 2005532668 unlimited-user license ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags =' +z -D_HPUX_SOURCE +DAportable +DS2.0 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae', optimize='-O', cppflags='+z -D_HPUX_SOURCE -Aa +DAportable +DS2.0' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='-L/opt/nokianms/lib -Wl,+vnocompatwarnings -L/usr/local/lib -L/opt/local/lib' libpth=/opt/nokianms/lib /lib/pa1.1 /usr/local/lib /opt/local/lib /lib /usr/lib /usr/ccs/lib libs=-lcl -lpthread -lnsl -lnm -lndbm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec perllibs=-lcl -lpthread -lnsl -lnm -lmalloc -ldld -lm -lc -lndir -lcrypt -lsec libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred -Wl,+s' cccdlflags='+z', lddlflags='-b +vnocompatwarnings -L/opt/nokianms/lib -L/usr/local/lib -L/opt/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under hpux Compiled at Aug 25 2003 21:00:00 %ENV: PERL5LIB=/opt/nokianms/lib/perllib @INC: /opt/nokianms/lib/perllib /opt/nokianms/lib/perl5/5.6.1/PA-RISC2.0 /opt/nokianms/lib/perl5/5.6.1 /opt/nokianms/lib/perl5/site_perl/5.6.1/PA-RISC2.0 /opt/nokianms/lib/perl5/site_perl/5.6.1 /opt/nokianms/lib/perl5/site_perl /opt/nokiaoss/pf3party/perlna/src/wperli/nokianms/lib/perl5/5.6.1 /opt/nokiaoss/pf3party/perlna/src/wperli/nokianms/lib/perl5/5.6.1/PA-RIS C2.0 -- Regards, Sravanth Kumar Nagunuri Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments.
Re: perlpodtut II
David Nicol skribis 2004-12-30 0:17 (-0600): See Lperlpod for discussion of the rarely used F, S, X and Z. I've chosen not to refer to perlpod or perlpodspec or pod2man except in the SEE ALSO section. Otherwise almost every paragraph would need this. Juerd
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/29/2004 10:33:02 PM: Its also hideously insecure. You're running a shell script that could do anything. A problem with any self-extracting archive. From shar(1). SECURITY CONSIDERATIONS It is easy to insert trojan horses into shar files. It is strongly rec- ommended that all shell archive files be examined before running them through sh(1). Archives produced using this implementation of shar may be easily examined with the command: egrep -v '^[X#]' shar.file I find it interesting to note too that the command: perl Makefile.PL can be made to do anything provided a trojan horse has been inserted either directly into the Makefile.PL file or into another file that Makefile.PL either requires or do()'s. It is interesting to note also that these days many folks login to linux as root and they may not even directly run that command after having examined the Makefile.PL since they may be using a convenience utility such as the CPAN shell. While I doubt that: make shdist or: mmk shdist is often used nowadays to prepare somehting for upload to CPAN, I suspect that removing it might adversely affect folks that have to email perl module distributions along 7 bit email relays For those that need that there is uutardist. Or if they really need it they can just uuencode or base64 encode the tarball themselves. Or let their MTA do it as is the current practice. The emailability of Unix shar or VMS share files is one consideration. Another is that the native VMS command @ is all that is needed to unpack a VMS_SHARE prepared file. In fact, the (VMS_)share format is as close to a native VMS compatible dist format as MakeMaker currently offers. All of the others: *.zip, *.tar.gz, *.tar.bz2, etc. require the installation of a special non VMS native unpacking program. (Hmm, perhaps we need a new pcsidist target? Then there is that whole ppm thing that was supposed to be the be all of binary dist formats especially suited to folks that had no compiler... so many dist formats to choose from.) I'd throw shdist out if I didn't think it would be more trouble than its worth. I hope nobody's using it. I think the unportability of shar was its main downfall rather than security concerns. The shar file might be able to unpack with: sh sharfile on SunOS 4.3 but it might not unpack on HP-UX 11.x (most likely since some necessary utility was not on your $PATH). It's not that bad to support, and it is not too popular, some folks might want to have it for some reason that I may or may not have been able to put forth. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
H.Merijn Brand [EMAIL PROTECTED] wrote on 12/30/2004 03:32:31 AM: On Wed 29 Dec 2004 19:49, [EMAIL PROTECTED] wrote: Craig A. Berry [EMAIL PROTECTED] wrote on 12/29/2004 01:09:58 PM: 4.) The following macro is defined and is used in the shdist target: SHAR = vms_share There is no such native command as vms_share. If I knew more about the intention, I might be able to suggest an alternative. The proza below smells like valid information for inclusion in README.vms I am not so sure. Having the VMS_SHARE program installed on VMS is only necessary for folks who will be preparing shdist archives for distribution. The information in README.vms is for folks who will be installing and administering perl on a VMS system. Though that task often includes the unpacking of module or extension distributions (and there is information on where to pick up tar for VMS et alia) it should be noted that a file such as Charles Bailey's on CPAN: authors/id/C/CB/CBAIL/VMS-DCLsym-1_0.share may be unpacked on any VMS V4 or later with the native VMS @ command (@ is analogous to sh or source under csh). Documentation on how to use @ is supplied with the OS's HELP facility as well as on the web, e.g.: http://h71000.www7.hp.com/doc/732FINAL/9996/9996pro_001.html#blue_3 Peter Prymmer P.S. vms_share was on the Freeware 4 CD (but not on 5 or 6). See for example: http://h71000.www7.hp.com/freeware/freeware40/vms_share/
[perl #33619] IO::Socket::INET.pm bug fix
# New Ticket Created by Chris Drake
# Please include the string: [perl #33619]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33619
IO::Socket::INET.pm module cannot do nonblocking connects. ActiveState fixed the
Win32 version a year or so ago. Here's the test script and comments:-
http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/2030994
Here's a corresponding Unix fix (Tested OK on RedHat EL3.0):-
*** /usr/lib/perl5/5.8.0/IO/Socket/INET.pm.ori 2004-06-28 18:40:57.0
+
--- INET.pm 2004-12-30 16:33:23.0 +
***
*** 193,196
--- 193,208
#my $before = time() if $timeout;
+
+ # these 8 lines contributed by Chris Drake:-
+ if(defined $arg-{Blocking}) {
+ if($arg-{Blocking}) {
+ $sock-blocking($arg-{Blocking})
+ } else {
+ $sock-blocking(undef);
+ my $temp = 1; ioctl($sock, 0x8004667E, \$temp); # Don't let it
block us.
+ }
+ }
+
+
undef $@;
if ($sock-connect(pack_sockaddr_in($rport, $raddr))) {
Kind Regards,
Chris Drake
Re: add 'since' availability tags to perlapi.pod?
Marcus Holland-Moritz wrote: On 2004-12-30, at 10:06:55 -0500, Stas Bekman wrote: Marcus Holland-Moritz wrote: Plus, you know that _something_ changed between 5.7.2 and 5.7.3. If it would tell you supported down to 5.6.1, but the API call got an extra parameter with 5.7.3, I think that would be worse. OK, based on this logic, I think the best wording will be: Supported at least starting from perl-5.7.3. or possibly: Supported in perl5.x.y (and perhaps earlier with older/different API)
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/30/2004 03:55:15 PM: Try out the attached patch. With the patch applied I obtained a bare bones mmk test result: All tests successful, 7 tests and 91 subtests skipped. Files=38, Tests=633, 239 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) which was done with perl 5.8.5 running on VMS V7.3-2, Compaq C S6.5-002, and MMK V3.9-6. I might even get to my big module collection test with this Peter Prymmer
Re: [perl #33619] IO::Socket::INET.pm bug fix
In article [EMAIL PROTECTED],
Chris Drake (via RT) [EMAIL PROTECTED] writes:
+ # these 8 lines contributed by Chris Drake:-
+ if(defined $arg-{Blocking}) {
+ if($arg-{Blocking}) {
+ $sock-blocking($arg-{Blocking})
+ } else {
+ $sock-blocking(undef);
+ my $temp = 1; ioctl($sock, 0x8004667E, \$temp); # Don't let it
block us.
This looks horribly unportable !
0x8004667E seems to be windows FIONBIO. Why is it needed beyond the
turning of of blocking ?
+ }
+ }
+
+
io/layers.t
Hi, I found on io/layers.t a little bug testing number of layers: my $n = scalar @$expected; is($n, scalar @$expected, $id - layers == $n); ^^ It should be compared with $result instead of $expected Cheers, Ignasi Roca Carrió
charnames :full under EBCDIC
Hi, On the POSIX-BC under BS2000 O.S. (EBCDIC character set) io/pat.t fails on test #776 while test #774 is ok. Here the code: print $lower =~ m/$UPPER/i ? ok 774\n : not ok 774\n; print $lower =~ m/[$UPPER]/i ? ok 776\n : not ok 776\n; Can somebody say me in which part of perl code shall I investigate (regcomp.c, regexec.c, ...) ? Please detail me as many as you can. Thanks, Ignasi Roca Carrió
Re: Perl setlocale?
-BEGIN PGP SIGNED MESSAGE- Moin, you wrote: Here's some code. Supply as the first argument the locale string under test. I run this under Perl 5.8.6. under Suse (with utf-8 as locale). After removing the Win32 lines, the script outputs: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8 Not sure if this helps you, Tels - -- Signed on Fri Dec 31 13:46:49 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates U.S. patent #5,978,791 http://tinyurl.com/5t6ft -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQdVKpXcLPEOTuEwVAQHYigf/UjlwmI0P+bAlT8Aecw6ouYS5zJMNJyZp ZJWT3uqDAPXu/o/fiz/qaH8ry9gME9m0eQNIZ7a635tF7RL6dB97mR/3T/7V6XaN Pw1rjqK76UYltM9FKugPY1ZgPdTJM4JC/2AmlefYQw3+/VS6/kpYddT1fpnRpNK3 Ri1n5FXRHq2EvCkSnZwHldtv+9OP7Q5q1ucYHcDcgJYzrRbL5Cw0s7bD4sfecgJN jq4CiSmQ2f2on3NC60UYa7G19PZ1vySvNrEmk2SL+1P15HVw5DdImLmce2zCpXFz i+vStm8ANvURyQu+9F0XWu5QdKlhw93e76Zu9xxBAirfH5MLanbydA== =QI0y -END PGP SIGNATURE-
Re: io/layers.t
On Fri, Dec 31, 2004 at 01:23:43PM +0100, Roca Carrio, Ignasi (PO EP) wrote: I found on io/layers.t a little bug testing number of layers: my $n = scalar @$expected; is($n, scalar @$expected, $id - layers == $n); ^^ It should be compared with $result instead of $expected Thanks for reporting this. I think that actually it should be scalar @$result rather than $result, so I've applied that change. Nicholas Clark
Smoke [5.9.2] 23712 FAIL(c) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.2 patch 23712 on bsd/os - 4.1 (i386/1 cpu) (fixit.xs4all.nl) using version Report by Test::Smoke v1.18.09 (perl 5.00503) [3 hours 4 minutes] O = OK F = Failure(s), extended report at the bottom X = test(s) failed 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 23712 Configuration (common) none O O - - - - - - -Duse64bitint c c c c -Duselongdouble c c c c -Dusemorebits - - - - -Duseithreads - - - - -Duseithreads -Duse64bitint c c c c -Duseithreads -Duselongdouble c c c c -Duseithreads -Dusemorebits | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Summary: FAIL(c)
Re: excessive swash init?
Nicholas Clark [EMAIL PROTECTED] wrote: :It looks like this logic is incorrect: : : si = *ary; : a = SvTYPE(ary[1]) == SVt_RV ? ary[1] : 0; : b = SvTYPE(ary[2]) == SVt_PVAV ? ary[2] : 0; [...] :Would it be reasonable to replace that SvTYPE check with an SvROK check? Looks reasonable to me. Do you understand what caused the sv to get upgraded to PVMG? The only problems are likely to occur when the sv actually has magic attached, and it gets passed to one of the standard sv.c functions which will attempt to execute code associated with that magic in a non-reentrant fashion. (I better stop waving my arms now, I think I see Don Quixote taking a run up.) Hugo
Re: charnames :full under EBCDIC
Roca Carrio, Ignasi \(PO EP\) [EMAIL PROTECTED] wrote: :On the POSIX-BC under BS2000 O.S. (EBCDIC character set) :io/pat.t fails on test #776 while test #774 is ok. : :Here the code: :print $lower =~ m/$UPPER/i ? ok 774\n : not ok 774\n; :print $lower =~ m/[$UPPER]/i ? ok 776\n : not ok 776\n; : :Can somebody say me in which part of perl code shall I investigate = :(regcomp.c, regexec.c, ...) ? :Please detail me as many as you can. I'd suggest starting with a standalone equivalent of the failing test run with -Dr (or C use re debug ), which should hopefully be able to tell us whether it is the character class being constructed wrongly, or the matching against the character class failing. Hugo
Re: [perl #33185] UTF-8 string substitution corrupts memory
Nicholas Clark [EMAIL PROTECTED] wrote: :The appended patch seems to cure the problem for me, but I'm not confident :that it's the correct way. I notice that this changes the order things are stacked; I'm not sure if that's ever going to be relevant. In particularly this swaps the first two of the sequence: PUSHSTACKi; ENTER; LEAVE; POPSTACK .. but I'm not sure what they all do without expanding a lot of macros. Hugo
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
Michael G Schwern [EMAIL PROTECTED] wrote on 12/31/2004 03:59:29 AM: http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_07.tar.gz Test obtained. First using perl 5.8.6 and mmk V3.9-6: All tests successful, 7 tests and 94 subtests skipped. Files=38, Tests=639, 239 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Next using perl 5.8.6 and mms V3.2-01: Module will not build. The descrip.mms written out by ExtUtils::MakeMaker::VERSION 6.17 runs into %SYSTEM-F-ACCVIO, access violation and a register dump. I cannot get to MMS TEST. I'll see if installing the mmk built 6.25_07 has any positive effect on helping MMS here. I see that instmodsh was installed: Directory PERL_ROOT:[UTILS] INSTMODSH.;1 Total of 1 file. With that installed a second attempt to build it with mms 3.2-01 still fails with a similar message. I have verified that this MMS can handle rudimentary descrip.mms files. I do not know yet what is causing the trouble. Peter Prymmer
Re: PERL_FLEXIBLE_EXCEPTIONS
On 2004-07-16, at 13:06:51 +0100, [EMAIL PROTECTED] wrote: H.Merijn Brand [EMAIL PROTECTED] wrote: :On Fri 16 Jul 2004 11:12, Nicholas Clark [EMAIL PROTECTED] wrote: : On Thu, Jul 15, 2004 at 11:18:58PM -0500, david nicol wrote: : On Thu, 2004-07-15 at 05:16, H.Merijn Brand wrote: : Do I hear some chainsaw rumblings in the faint distance? : : Your sawdust, sir. : : Thanks, but I'm not convinced that this is needed. I see no particular reason : to take this out as it's all conditionally compiled, so it has no impact on : the code runtime. : :One of Hugo's targets on 5.9/5.10 was code cleanup. :We've done a lot of that already, and I see no reason to leave this in if the :chance of it to ever be working is close to zero Indeed. I'd be happy to see this removed, but it would be handy if it could be replaced with some brief documentation pointing to the removed code and any other useful information (such as this thread) to save the next explorer having to dig the same mineshaft before falling down it. Any preference on where that documentation should go? What about putting the follwing into scope.h instead of the original flexible exceptions documentation? /* * PERL_FLEXIBLE_EXCEPTIONS * * All flexible exceptions code has been removed. * See the following thread for details: * * http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-07/msg00378.html * * The original discussion can be found in this thread: * * http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-03/msg00520.html * * The original patches that introduces flexible exceptions were: * * http://public.activestate.com/cgi-bin/perlbrowse?patch=3386 * http://public.activestate.com/cgi-bin/perlbrowse?patch=5162 */
[PATCH] randbits and randfunc for VMS
We were not setting randbits appropriately when using drand48(), and that was causing 64-bit builds to fail. We were not setting randfunc at all. The attached patch to configure.com corrects these omissions. --- configure.com;-0Fri Dec 24 03:25:30 2004 +++ configure.com Thu Dec 30 22:03:14 2004 @@ -4738,6 +4738,8 @@ $ IF compile_status .EQ. good_compile .AND. link_status .EQ. good_link $ THEN $ drand01 = drand48() +$ randbits = 48 +$ randfunc = drand48 $ randseedtype = long int $ seedfunc = srand48 $ echo4 Good, found drand48(). @@ -4745,6 +4747,8 @@ $ ELSE $ d_drand48proto = undef $ drand01=random() +$ randbits = 31 +$ randfunc = random $ randseedtype = unsigned $ seedfunc = srandom $ OS @@ -4764,6 +4768,7 @@ $ echo4 OK, found random(). $ ELSE $ drand01=(((float)rand())*MY_INV_RAND_MAX) +$ randfunc = rand $ randseedtype = unsigned $ seedfunc = srand $ echo4 Yick, looks like I have to use rand(). @@ -5870,7 +5875,8 @@ $ WC ptrsize=' + ptrsize + ' $ WC quadkind=' + quadkind + ' $ WC quadtype=' + quadtype + ' -$ WC randbits='31' +$ WC randbits=' + randbits + ' +$ WC randfunc=' + randfunc + ' $ WC randseedtype=' + randseedtype + ' $ WC ranlib=' + ' $ WC rd_nodata=' '
Re: PERL_FLEXIBLE_EXCEPTIONS
On 2004-07-14, at 16:08:53 -0700, Gurusamy Sarathy wrote: On Wed, 14 Jul 2004 23:18:29 BST, Nick Ing-Simmons wrote: Nicholas Clark [EMAIL PROTECTED] writes: What is PERL_FLEXIBLE_EXCEPTIONS ? An abstraction which allows setjmp/longjmp to be replaced with C++ try/throw or the Microsoft C near equivalent (Structured Exception Handling or some such). I suggest looking at change#3386 and change#5162. IIRC, the second change essentially disabled the first because the original patch wasn't robust enough to handle exceptions in END blocks properly. Given that the patch doesn't really work, I wouldn't mind seeing it removed if no one is interested in fixing it. The original discussion around this can be found with something like: http://groups.google.com/groups?q=PL_protect+default_protect http://groups.google.com/groups?q=hook+to+allow+perl+to+use+C%2B%2B+try I couldn't find anything useful except for this thread with the above two links... :-/ -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
Re: [perl #33185] UTF-8 string substitution corrupts memory
On Fri, Dec 31, 2004 at 03:04:49PM +, [EMAIL PROTECTED] wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
:The appended patch seems to cure the problem for me, but I'm not confident
:that it's the correct way.
I notice that this changes the order things are stacked; I'm not sure if
that's ever going to be relevant. In particularly this swaps the first
two of the sequence:
PUSHSTACKi; ENTER; LEAVE; POPSTACK
.. but I'm not sure what they all do without expanding a lot of macros.
Aha. I was rather hoping that someone would be able to tell me if the changes
were going to be relevant. The simplest fix appears to be add
save_re_context(); after the ENTER in
if (!gv_fetchmeth(stash, SWASHNEW, 8, -1)) { /* demand load utf8 */
ENTER;
errsv_save = newSVsv(ERRSV);
Perl_load_module(aTHX_ PERL_LOADMOD_NOIMPORT, newSVpvn(pkg,pkg_len),
Nullsv);
if (!SvTRUE(ERRSV))
sv_setsv(ERRSV, errsv_save);
SvREFCNT_dec(errsv_save);
LEAVE;
}
except that seems to be wasteful, as it would mean doing all the save work
twice, because of the existing save_re_context() later in Perl_swatch_init.
I was hoping that there was a good way to save the regexp engine's context
just once for the entire function.
Nicholas Clark
[perl #33630] BigRats with integer values lose sign on numify
# New Ticket Created by Zefram # Please include the string: [perl #33630] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33630 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.4. - [Please enter your report here] $ perl -MMath::BigRat -lwe 'print Math::BigRat-new(-10/3)-numify' -3.33 $ perl -MMath::BigRat -lwe 'print Math::BigRat-new(-10/1)-numify' 10 The latter is obviously incorrect. It's only the numify that's broken; the BigRat itself behaves as negative if used in arithmetic. [Please do not change anything below this line] - --- Flags: category=library severity=high --- Site configuration information for perl v5.8.4: Configured by Debian Project at Mon Oct 25 01:52:37 EST 2004. Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=linux, osvers=2.4.27-ti1211, archname=i386-linux-thread-multi uname='linux kosh 2.4.27-ti1211 #1 sun sep 19 18:17:45 est 2004 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.4 -Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-1)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.4 gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.4: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . --- Environment for perl v5.8.4: HOME=/home/zefram LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/zefram/pub/i686-pc-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/bin:/usr/games:/opt/libunsn/bin PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Re: [perl #33185] UTF-8 string substitution corrupts memory
On Fri, Dec 31, 2004 at 03:04:49PM +, [EMAIL PROTECTED] wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
:The appended patch seems to cure the problem for me, but I'm not confident
:that it's the correct way.
I notice that this changes the order things are stacked; I'm not sure if
that's ever going to be relevant. In particularly this swaps the first
two of the sequence:
PUSHSTACKi; ENTER; LEAVE; POPSTACK
.. but I'm not sure what they all do without expanding a lot of macros.
I'd have thought that the better approach would be to move the
if (!gv_fetchmeth(stash, SWASHNEW, 8, -1)) { /* demand load utf8 */
block further down to just above the line
if (call_method(SWASHNEW, G_SCALAR))
then the call to Perl_load_module is protected by the PUSHSTACKi. Note
that PUSHSTACKi is needed any place where the caller isn't prepared for
the stack to get extended and thus possibly reallocated (thus invalidating
SP etc). It gives you a brand new stack to play with.
--
In England there is a special word which means the last sunshine
of the summer. That word is spring.
Re: [PATCH] randbits and randfunc for VMS
On Fri, Dec 31, 2004 at 09:31:11AM -0600, Craig A. Berry wrote: We were not setting randbits appropriately when using drand48(), and that was causing 64-bit builds to fail. We were not setting randfunc at all. The attached patch to configure.com corrects these omissions. Thanks, applied (23715) Nicholas Clark
[perl #33608] Problems in Perl 5.6.1 (Cant locate object method ToUpper via package main (perhaps you forgot to load main?) )
[EMAIL PROTECTED] - Wed Dec 29 22:35:41 2004]: We have ported our application from PERL5.0.1 to PERL5.6.1 We got the following error during execution of our perl script. -- Cant locate object method ToUpper via package main (perhaps you forgot to load main?) at /d/nmsopt/nokianms/lib/perl5/5.6.1/utf8_heavy.pl line 30, CONFIG line 59.. Terminating - We could not find method ToUpper in any library of 5.6.1. Basically the error message says that main package is not loaded. We don't have a method ToUpper in our Perl code also. How to locate this method and how to correct this situation? Please let us know how to over come this situation. From the message you are getting, there is a bug in your Perl script where you are calling a method called ToUpper like this -ToUpper() and no ToUpper method is defined in your script and the package that ToUpper() is in is not being use'd. From you @INC in your config, your script will only look in the 5.6.1 direcories. If you installed this module in a previous versions directories, it will not be found. Most likely, this is a problem in your installation. This, however, does not appear to be a bug in Perl.
[perl #6757] the walls come crashing down ... (segmentation fault)
[EMAIL PROTECTED] - Fri Apr 06 05:17:05 2001]:
-
Ever since compiling and testing the new perl and installing it,
certain
perl apps - such as PilotManager as well as this script:
eval 'exec /volws/lwv26/ldatae/bin/perl -S $0 ${1+$@}'
if 0; # not running under some shell
use CPAN;
shell;
have been crashing with a segmentation error. When I tried to get
into
dbx to figure out where the problem was occuring, I got no stack
trace (what's the trick to examining a SPARC Solaris 8 core dump
of an interpreter interpreting a script?)
I'm assuming this has been fixed some time in the past, otherwise, perl
-MCPAN -eshell would not be working.
[perl #7121] segmentation fault in Perl_sv_2bool
[EMAIL PROTECTED] - Sun Jun 17 17:21:28 2001]: - [Please enter your report here] I got a segfault, here is the stack trace: #0 0x80c772b in Perl_sv_2bool (sv=0x81fb7b4) at sv.c:2353 #1 0x80b8fac in Perl_pp_cond_expr () at pp_hot.c:123 #2 0x80b863d in Perl_runops_debug () at run.c:53 #3 0x8066ba3 in Perl_amagic_call (left=0x82fea14, right=0x813f958, method=30, flags=0) at gv.c:1588 #4 0x80d6341 in Perl_pp_gt () at pp.c:1181 #5 0x80b863d in Perl_runops_debug () at run.c:53 #6 0x805dd5f in S_run_body (oldscope=1) at perl.c:1471 #7 0x805d931 in perl_run (my_perl=0x8140280) at perl.c:1393 #8 0x805a205 in main (argc=6, argv=0xb944, env=0xb960) at perlmain.c:52 #9 0x4006338b in __libc_start_main () from /lib/libc.so.6 The segfault is caused by a make test in the upcoming release of Class::Date 1.1.0. It got the segfault signal after the 58th test case. The module can be downloaded from http://dlux.sch.bme.hu/Class-Date/trace/ directory. I am not 100% sure, that it is a perl bug, but I think it is. I use operator overloading and autoloading in this package. The problem is disappeared when I run the test case (30_localtime.t) in perl debugger. I was able to install without problems. CPAN Testers also shows that there have been no additional problems going back several years.
[perl #7532] Segmentation faul of perl
[RT_System - Wed Aug 15 03:34:45 2001]: You should have checked 5.6.2-tobe - it's been mended for some time. Mike Guy There is no segmentation fault for this in either 5.6.2 or the 5.8.5/5.8.6's I tested.
[perl #8048] Perl crash! (Segmentation Fault)
[RT_System - Wed Dec 12 08:46:13 2001]: On Wed, Dec 12, 2001 at 12:32:31PM -0800, Pierre Demartines wrote: Hello, That's the first time it happens to me with such a simple program: perl crashes in a Segmentation Fault. I boiled down the program and the data to the minimum possible. I'd be very glad if this can help resolve a bug. I am using perl5.6.0 on linux RedHat7.2 (on this OS, perl5.6.0 is the standard version that comes with the OS; I tried to upgrade another machine to 5.6.1 with CPAN, but it made my whole system very unstable --many scripts wouldn't work anymore; apparently on 5.6.1 the same program seems to work). Anyway, here is the report for perl5.6.0: Confirmed, it does segfault in 5.6.0. The bug's been fixed in 5.6.1 I've confirmed that the segfault no longer occurs.
[perl #8735] Segmentation fault on RH7.2 perl 5.6.0
[RT_System - Fri Mar 01 03:06:11 2002]: On Fri, Mar 01, 2002 at 06:11:17PM -, [EMAIL PROTECTED] wrote: 10 12 [17:50:54] amok!dbcm:~ unset OLDPWD 11 12 [17:50:56] amok!dbcm:~ perldoc -q '$a' Segmentation fault I can only reproduce this with Debian's 5.6.1-7 and Redhat's 5.6.0-9 and not any of my locally compiled versions of 5.6.0, 5.6.1, bleadperl nor with Redhat's 5.6.0-12. So we might want to have a look at what changed between 5.6.0-9 and 5.6.0-12. RedHat 7.2 Perl 5.6.0 from distro 5.6.0-12 is in 7.1, so it looks like this bug went away and then came back. I can't reproduce this in a recent Perl. unset OLDPWD perldoc -q '$a' No documentation for perl FAQ keyword `$a' found This problem seems to have been resolved.
[perl #17418] Segmentation Fault - chop in 5.6.1
[rafael - Thu Sep 19 04:47:50 2002]: marcus davy (via RT) [EMAIL PROTECTED] wrote: Hi, I couldnt find if this had been addressed in the bug tracking for perl 5.8.0 As I do not have 5.8.0 installed could somebody try this please and see if you also get a segmentation fault . perl -e 'chop(foo)' Segmentation fault # On 5.6.1 Linux 2.4.18-3 Red Hat Linux 7.3 Thanks for your report. It appears that this bug has been corrected in 5.8.0 (and it wasn't present in 5.6.0 and before.) This is also fixed in 5.6.2.
[perl #3399] make install fails with Can't locate Carp/Heavy.pm in @INC
[EMAIL PROTECTED] - Mon Jun 19 02:11:44 2000]: make install.man fails on both IRIX 6.3 and HP-UX 9.05 with the same error: Everything is up to date. 'make test' to run test suite. ./perl installman chdir pod mkdir /usr/local/man Can't locate Carp/Heavy.pm in @INC (@INC contains: lib) at lib/Carp.pm line 109. make: *** [install.man] Error 2 HP-UX myconfig: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=hpux, osvers=09.05, archname=PA-RISC1.1 uname='hp-ux santos a.09.05 a 9000725 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-D_HPUX_SOURCE -Aa -I/usr/local/include' ccflags =' -D_HPUX_SOURCE -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ae' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lndbm -ldld -lm -lc -lndir -lcrypt libc=/lib/libc.sl, so=sl, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred ' cccdlflags='+z', lddlflags='-b -L/usr/local/lib' IRIX myconfig: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=irix, osvers=6.3, archname=IP32-irix uname='irix laredo 6.3 12161207 ip32 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc -n32', optimize='-O3', gccversion= cppflags='-D_BSD_TYPES -D_BSD_TIME -OPT:Olimit=0 -I/usr/local/include -DLANGUAGE_C' ccflags ='-D_BSD_TYPES -D_BSD_TIME -woff 1009,1110,1174,1184,1552 -OPT:Olimit=0 -I/usr/local/include -DLANGUAGE_C' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc -n32', ldflags =' -L/usr/local/lib32 -L/usr/local/lib -Wl,-woff,84' libpth=/usr/local/lib /usr/lib32 /lib32 /lib /usr/lib libs=-lm -lc libc=/usr/lib32/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-n32 -shared -L/usr/local/lib32 -L/usr/local/lib' Thanks. The most likely cause is an insufficient number of available file descriptors. Increase your ulimits for descriptors and you should be able to install successfully.
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/30/2004 05:22:30 PM: On Thu, Dec 30, 2004 at 04:47:18PM -0500, [EMAIL PROTECTED] wrote: I might even get to my big module collection test with this Wait for the next alpha. I have to fix that IGNORE problem first. Warning: this message contains long lines that may have been wrapped by my MUA at weird places. With ExtUtils::MakeMaker 6.25_07, perl 5.8.6, mmk V3.9-6, and a test case of a slightly modified DBI 1.45 initially I obtain: %MMK-F-CANTUPD, cannot update target MCR - sources unknown $ MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e cp Changes [.blib.lib.DBI]Changes.pm $ MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e cp Roadmap.pod [.blib.lib.DBI]Roadmap.pm cp [.lib.dbd]dbm.pm [.blib.lib.dbd]dbm.pm cp [.lib.win32]dbiodbc.pm [.blib.lib.win32]dbiodbc.pm cp [.lib.dbi]w32odbc.pm [.blib.lib.dbi]w32odbc.pm herein are many completed commands. In a subsequent attempt to simply run mmk in the directory: $ mmk %MMK-F-CANTUPD, cannot update target MCR - sources unknown $ show symbol $status $STATUS == %X1C14805C It appears that it wants to consider MCR as a target for some reason. A run of mmk/log indicates that it wants to update a file called perl.c (itself apparenty derived from perl.xsi). This is beginning to look like a problem with the XSUBPP macros. Contrast the following search (think grep) done to the descrip.mms generated for DBI 1.45 by MakeMaker 6.17: $ sea descrip.mms xsubpp # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] XSUBPP = $(PERLRUN) $(XSUBPPDIR)xsubpp XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET_NAME).c perl.c dbi.c : $(XSUBPPDEPS) Compared to the same search for the 6.25_07 generated descrip.mms file: $ sea descrip.mms xsubpp # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] XSUBPP = $(PERLRUN) $(XSUBPPDIR)/xsubpp XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap $(XSUBPP) XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap XSUBPP_EXTRA_ARGS = $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET_NAME).c dbi.c perl.c : $(XSUBPPDEPS) If I remove the extraneous $(XSUBPP) macro from the XSUBPPDEPS assignment I now obtain: $ mmk MCR dga2:[perl-5_8_6_root]perl.exe perl_root:[lib.ExtUtils]/xsubpp -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap PERL.xs PERL.C Can't open perl script perl_root:[lib.extutils]/xsubpp: file specification syntax error %RMS-F-SYN, file specification syntax error %MMK-F-ERRUPD, error status %X000186D4 occurred when updating target PERL.C If I correct the XSUBPP path like so: --- descrip.mms Fri Dec 31 12:36:21 2004 +++ descrip.mms;-1 Fri Dec 31 12:34:12 2004 @@ -229,7 +229,7 @@ # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] -XSUBPP = $(PERLRUN) $(XSUBPPDIR)xsubpp +XSUBPP = $(PERLRUN) $(XSUBPPDIR)/xsubpp XSPROTOARG = XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap I now obtain: $ mmk CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/float=ieee/ieee=denorm_results/Define=(DBI_NO_THREADS,V ERSION=1.45,XS_VERSION=1.45)/Include=(perl_root:[lib.VMS_AXP.5_8_6.CORE])/NoList PERL.c %RMS-F-SYN, file specification syntax error ^ %CC-E-DECLARATOR, Invalid declarator. Which looks like a problem with DBI code not MakeMaker. I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM: I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. One other oddity noted with 6.25_07: $ mmk distclean snippage Not in MANIFEST: dbi.opt I am fairly certain that it used to be able to delete the linker options files that it wrote out before. Peter Prymmer
[perl #33631] $^U is readonly
# New Ticket Created by Nicholas Clark # Please include the string: [perl #33631] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33631 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.34 running under perl v5.8.1. - [Please enter your report here] $ ~/Reference/5.8.0/bin/perl5.8.0-32 -wle '$^U = 3' $ ~/Reference/5.8.1/bin/perl5.8.1-32 -wle '$^U = 3' Modification of a read-only value attempted at -e line 1. The unused punctuation variable $^U appears to have become inadvertently made read only by this change: http://public.activestate.com/cgi-bin/perlbrowse?patch=18490 I propose to fix this as part of a general refactoring of gv_fetchpv Nicholas Clark [Please do not change anything below this line] - --- Flags: category=core severity=low --- This perlbug was built using Perl v5.8.1 - Sun Mar 21 10:48:25 GMT 2004 It is being executed now by Perl v5.8.1 - Sun Mar 21 00:14:48 GMT 2004. Site configuration information for perl v5.8.1: Configured by nick at Sun Mar 21 00:14:48 GMT 2004. Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=darwin, osvers=7.3.0, archname=darwin-2level uname='darwin ship-in-a-bottle.local 7.3.0 darwin kernel version 7.3.0: fri mar 5 14:22:55 pst 2004; root:xnuxnu-517.3.15.obj~4release_ppc power macintosh powerpc ' config_args='-Dusedevel=y -Dcc=ccache gcc -Dld=gcc -Ubincompat5005 -Uinstallusrbinperl [EMAIL PROTECTED] [EMAIL PROTECTED] -Dinc_version_list= -Dinc_version_list_init=0 -Dprefix=~/Reference/5.8.1 -Uusethreads -Uuse64bitint -de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='ccache gcc', ccflags ='-pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing', optimize='-Os', cppflags='-no-cpp-precomp -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='' libpth=/usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup' Locally applied patches: --- @INC for perl v5.8.1: /sw/lib/perl5/5.8.1 /sw/lib/perl5 /sw/lib/perl5/darwin /Users/nick/Reference/5.8.1/lib/perl5/5.8.1/darwin-2level /Users/nick/Reference/5.8.1/lib/perl5/5.8.1 /Users/nick/Reference/5.8.1/lib/perl5/site_perl/5.8.1/darwin-2level /Users/nick/Reference/5.8.1/lib/perl5/site_perl/5.8.1 /Users/nick/Reference/5.8.1/lib/perl5/site_perl . --- Environment for perl v5.8.1: DYLD_LIBRARY_PATH (unset) HOME=/Users/nick LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/nick/bin:/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/sbin:/sbin:/usr/sbin PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin PERL_BADLANG (unset) SHELL=/bin/bash
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 01:01:12 PM: [EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM: I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. One other oddity noted with 6.25_07: Here is another oddity. The .exists files are being incorrectly thought of as lib elements. With DBI 1.45 and the two descrip.mms edits I mentioned before a clean build now does the following: $ mmk snip If F$Search([.BLIB.ARCH.AUTO.DBI]DBI.OLB).eqs. Then Library/Object/Create [.BLIB.ARCH.AUTO.DBI]DBI.OLB Library/Object/Replace [.BLIB.ARCH.AUTO.DBI]DBI.OLB DBI.OBJ,[.BLIB.ARCH.AUTO.DBI].EXISTS %LIBRAR-W-OPENIN, error opening P:[CPAN_MODULES_586.DBI-1_45.BLIB.ARCH.AUTO.DBI]DBI.EXISTS; as input -RMS-E-FNF, file not found %MMK-F-ERRUPD, error status %X10861098 occurred when updating target [.BLIB.ARCH.AUTO.DBI]DBI.OLB It should probably not try to lib/obj/replace the .exists file since that file is not an .obj. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 01:01:12 PM: One other oddity noted with 6.25_07: $ mmk distclean snippage Not in MANIFEST: dbi.opt I am fairly certain that it used to be able to delete the linker options files that it wrote out before. I failed to mention this one before but it appears that both mmk clean and mmk distclean are now deleting the source for the EXE_FILES. Note: $ mmk clean MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f *.olb perl.c core core.[0-9] [.blib.arch.auto.DBI]extralibs.all core.[0-9][0-9] DBI.bso dbi.c MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f pm_to_blib.ts core.[0-9][0-9][0-9][0-9] DBI.x DBI.bs perl.exe tmon.out *.obj blibdirs.ts MCR $dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f core.[0-9][0-9][0-9][0-9][0-9] *perl.core core.*perl.*.? Makeaperl.MMS DBI.def perl core.[0-9][0-9][0-9] mon.out MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f libDBI.def perlmain.c perl.exe [.blib.arch.auto.DBI]extralibs.ld so_locations DBI.exp MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_rf dbiproxy.pl dbitrace.log ndtest.prt dbiprof.pl snip $ perl Makefile.PL snip Warning: the following files are missing in your kit: dbiprof.pl dbiproxy.pl Please inform the author. snip $ search Makefile.PL EXE_FILES EXE_FILES = [ dbiproxy$ext_pl, dbiprof$ext_pl ], Peter Prymmer
Re: PERL_FLEXIBLE_EXCEPTIONS
On Fri, 31 Dec 2004 16:32:44 +0100, Marcus Holland-Moritz wrote: On 2004-07-14, at 16:08:53 -0700, Gurusamy Sarathy wrote: The original discussion around this can be found with something like: http://groups.google.com/groups?q=PL_protect+default_protect http://groups.google.com/groups?q=hook+to+allow+perl+to+use+C%2B%2B+try I couldn't find anything useful except for this thread with the above two links... :-/ Looks like the Google index has gotten worse. The significant threads are probably the ones that start here (be sure to follow the whole forest of threads via the followups links if you want to see everything): Joshua's original patches (which weren't applied) and discussion: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01396.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01489.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01491.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01608.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg02144.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg02998.html Chip's reworked patch and discussion: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-03/msg00520.html The flaw in these patches (which went unnoticed at the time) was that they moved some code that could potentially die() out of the region protected by the setjmp()s. This caused exceptions within END blocks and such to not be handled by the correct setjmp(). Sarathy [EMAIL PROTECTED]
Re: [perl #33608] Problems in Perl 5.6.1 (Cant locate object method ToUpper via package main (perhaps you forgot to load main?) )
On Fri, Dec 31, 2004 at 04:18:33PM -, Steve Peters via RT wrote: From the message you are getting, there is a bug in your Perl script where you are calling a method called ToUpper like this -ToUpper() and no ToUpper method is defined in your script and the package that ToUpper() is in is not being use'd. From you @INC in your config, your script will only look in the 5.6.1 direcories. If you installed this module in a previous versions directories, it will not be found. Most likely, this is a problem in your installation. This, however, does not appear to be a bug in Perl. I dunno, this smells like a 5.6.1 Unicode issue. It could be an internal bug in uc() in a Unicode locale. Sravanth, if you are in a Unicode locale, and I suspect you are, I would suggest not bothering with 5.6.1 and jumping straight to the latest stable version, 5.8.6. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ If the enemy is in range, so are you.
Re: [perl #33607] Problems in Perl 5.6.1
On Thu, Dec 30, 2004 at 06:27:57AM -, Sravanth Kumar Nagunuri wrote: We have ported our application from PERL5.0.1 to PERL5.6.1 There was no 5.0.1. Do you mean 5.001m? If so, that was quite an upgrade. If you're upgrading that far don't bother with 5.6.1, go straight to the latest stable version 5.8.6. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Pancakes is the better part of valor. http://www.goats.com/archive/971202.html
[perl #5634] CPAN.pm v1.59 chdirs before looking for perl
[schwern - Tue Jul 15 18:31:18 2003]: The attached patch fixes this bug by the simple method of storing the Perl we started with as an absolute path before anything is done. Then perl() can reference this information. I can't see how this could go wrong on MacOS. I've also taken the liberty of speeding up perl() by caching its result. This is still a problem as of CPAN 1.76.
Re: [perl #33598] sniff, well meaning documentation enhancements never up to snuff
On Thu, Dec 30, 2004 at 06:18:52AM -0800, Joe McMahon wrote: It's partly that they are always change thus, not here's a patch to change this. Try puttig together some patches. You're thinking about this stuff, which us good, but you need to show that it means enough to you, and that it can really be an enhancement, by putting some volunteer work toward making it happen. Bear in mind that we will still not accept the patch if we don't agree with it... -- Never do today what you can put off till tomorrow.
[perl #6776] make problem
[EMAIL PROTECTED] - Sun Apr 08 21:05:08 2001]: In any case, I ./Configure it (I've tried answering all the questions myself and just doing ./Configure -de as well). While some warnings fly past while doing this, it seems ok. I then try to make it and at the very end I get: --- /usr/bin/libtool: internal link edit command failed make: *** [libperl.dylib] Error 1 --- Any suggestions? I tried asking on the perl misc newsgroup but didn't get any (helpful) replies. Many thanks, sorry for bothering you! -James Cummings [EMAIL PROTECTED] --- James Cummings | [EMAIL PROTECTED] | http://www.cursus.uea.ac.uk/~james CURSUS Project, School of Music, University of East Anglia, Norwich, Norfolk, NR4 7TJ,UK If I remember correctly, this was an old problem with the GNU compiler tools on Mac OS X. Upgrading to the most recent versions available for your OS X version should fix the problems.
Re: [perl #33608] Problems in Perl 5.6.1 (Cant locate object method ToUpper via package main (perhaps you forgot to load main?) )
On Fri, Dec 31, 2004 at 04:18:33PM -, Steve Peters via RT wrote: sravanth.nagunuri - Wed Dec 29 22:35:41 2004]: We have ported our application from PERL5.0.1 to PERL5.6.1 We got the following error during execution of our perl script. This makes no sense; there was no perl5.0.1. Did you mean 5.8.1? If so, you appear to be using some of the perl's unicode functionality. This is not going to work the same (if at all) on 5.6.1. -- Cant locate object method ToUpper via package main (perhaps you forgot to load main?) at /d/nmsopt/nokianms/lib/perl5/5.6.1/utf8_heavy.pl line 30, CONFIG line 59.. Terminating - We could not find method ToUpper in any library of 5.6.1. Basically the error message says that main package is not loaded. We don't have a method ToUpper in our Perl code also. How to locate this method and how to correct this situation? Please let us know how to over come this situation. From the message you are getting, there is a bug in your Perl script where you are calling a method called ToUpper like this -ToUpper() and no ToUpper method is defined in your script and the package that ToUpper() is in is not being use'd. From you @INC in your config, your script will only look in the 5.6.1 direcories. If you installed this module in a previous versions directories, it will not be found. Most likely, this is a problem in your installation. This, however, does not appear to be a bug in Perl. Steve, this call is coming from utf8_heavy.pl, part of the perl distribution. In particular, when perl does a uc on utf8 data, it will internally load that file and line 30 there attempts to do a call to main-ToUpper. It is wrapped in an eval, however, so perl shouldn't actually die. I wasn't able to even get that message left in $@ (in case the user's code was doing something like die $@ if $@ to rethrow any errors) on 5.6.2; I don't have a 5.6.1 to try with. Anybody remember a bug like this in 5.6.1?
[perl #7127] File::Find Module (preprocess and postprocess)
[EMAIL PROTECTED] - Mon Jun 18 02:33:43 2001]:
-
[Please enter your report here]
Using the Perl module File::Find (v 5.6.1), I noticed that when
the 'follow' is set the 'preprocess' and 'postprocess' subroutine
is never run.
Here is the code to reproduce the problem:
#!/usr/bin/perl
@ARGV = qw (.) unless @ARGV;
use File::Find;
sub doit {
print Files in $File::Find::dir: @_\n;
return @_;
}
find {
wanted = sub {},
preprocess = \doit,
follow = 1
}, @ARGV;
__END__
This should print the contents of each directory,
but nothing happens.
I use preprocess to ignore specific directory names and this is
when this becomes a serious problem.
Great module otherwise!
From the File::Find documentation
preprocess
The value should be a code reference. This code reference is used to
preprocess the current directory. The name of the currently processed
directory is in $File::Find::dir. Your preprocessing function is called
after readdir(), but before the loop that calls the wanted() function.
It is called with a list of strings (actually file/directory names) and
is expected to return a list of strings. The code can be used to sort
the file/directory names alphabetically, numerically, or to filter out
directory entries based on their name alone. When follow or follow_fast
are in effect, preprocess is a no-op.
The subroutine pointed to by preprocess is not called because you also
have follow = 1 as noted in the documentation. This is not a bug.
Re: PERL_FLEXIBLE_EXCEPTIONS
The perl.org archives only seem to go back through late August 1999. Would it be possible to set up a perl.perl5.porters.old newsgroup and feed in all the older archives from xray? On Fri, Dec 31, 2004 at 11:04:52AM -0800, Gurusamy Sarathy wrote: On Fri, 31 Dec 2004 16:32:44 +0100, Marcus Holland-Moritz wrote: On 2004-07-14, at 16:08:53 -0700, Gurusamy Sarathy wrote: The original discussion around this can be found with something like: http://groups.google.com/groups?q=PL_protect+default_protect http://groups.google.com/groups?q=hook+to+allow+perl+to+use+C%2B%2B+try I couldn't find anything useful except for this thread with the above two links... :-/ Looks like the Google index has gotten worse. The significant threads are probably the ones that start here (be sure to follow the whole forest of threads via the followups links if you want to see everything): Joshua's original patches (which weren't applied) and discussion: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01396.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01489.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01491.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg01608.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg02144.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1998-02/msg02998.html Chip's reworked patch and discussion: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-03/msg00520.html
[perl #7678] substr reference core dump
[RT_System - Wed Sep 12 00:19:22 2001]:
The below at least replaces the core dump with an error:
$ ./perl -wle '$b=abcde; local $k; *k=\substr($b, 2, 1)'
Can't modify non-existent substring.
Change 12005 by [EMAIL PROTECTED] on 2001/09/12 13:14:59
Subject: [ID 20010912.007] substr reference core dump
From: [EMAIL PROTECTED]
Date: 12 Sep 2001 14:11:16 -
Message-Id: [EMAIL PROTECTED]
Affected files ...
... //depot/perl/mg.c#197 edit
Differences ...
//depot/perl/mg.c#197 (text)
Index: perl/mg.c
--- perl/mg.c.~1~ Wed Sep 12 17:17:27 2001
+++ perl/mg.c Wed Sep 12 17:17:27 2001
@@ -1506,7 +1506,7 @@
sv_insert(lsv, lvoff, lvlen, tmps, len);
SvUTF8_on(lsv);
}
-else if (SvUTF8(lsv)) {
+else if (lsv SvUTF8(lsv)) {
sv_pos_u2b(lsv, lvoff, lvlen);
tmps = (char*)bytes_to_utf8((U8*)tmps, len);
sv_insert(lsv, lvoff, lvlen, tmps, len);
End of Patch.
Patch applied and in current Perls.
[perl #7835] strftime time zone bug
[EMAIL PROTECTED] - Mon Oct 22 12:28:09 2001]:
The workaround for NETaa14816 contained in ext/POSIX/POSIX.xs introduces
a different bug, namely that the time zone name and offset reported
by strftime %Z and %z are incorrect -- they report the time zone name and
offset of the current time, even if the time you pass has a different DST
setting.
I have a patch which fixes the problem, at least for our configuration.
I have no idea how portable it is and I have no hope of figuring out all
the ifdefs necessary, but I'll just show you my patch and hope you can
make some use of it (so long as I get credited if you do :-) ). If not,
oh well, and if you've already dealt with it, so much the better.
First, a sample script which demonstrates the problem:
#!/usr/bin/perl
use strict;
use POSIX qw(strftime);
my $t = 1003803105; # approx. 7:12 PM on Oct. 22, 2001, PDT
print_stuff($t);
print \n;
# now add 10 days, which takes us into PST
print_stuff($t+864000);
sub print_stuff
{
my $t = shift;
my ($sec, $min, $hour, $mday, $mon, $year,
$wday, $yday, $isdst) = localtime($t);
printf(%02d/%02d/%04d %02d:%02d:%02d DST: %d\n,
$mon+1, $mday, $year+1900, $hour, $min, $sec, $isdst);
print strftime(%A, %d-%b-%g %I:%M %p %Z %z\n,
$sec, $min, $hour, $mday, $mon, $year, $wday, $yday,
$isdst);
}
Using 5.6.0 on RedHat 6.2, version 2.2.16 of the kernel (also
reproduced on perl 5.6.0/Linux 2.2.14 and perl 5.6.1/linux 2.2.19), the
above script prints out:
10/22/2001 19:11:45 DST: 1
Monday, 22-Oct-01 07:11 PM PDT -0700
11/01/2001 18:11:45 DST: 0
Thursday, 01-Nov-01 06:11 PM PDT -0700
As you can see, for the second date, even though $isdst == 0, %Z and %z
still say PDT and -0700, when they should say PST and -0800. The problem
is that init_tm uses localtime(now) to initialize the tm structure, which
is incorrect when the actual date we are considering is on the other side
of the DST boundary (because 10/22/2001 is in DST, but 11/01/2001 is not).
I've attached my patch (diff against 5.6.0) so that Outlook won't
mangle the
whitespace.
Obviously the patch depends on the correct value of isdst being passed in
to whichever function is calling init_tm, and also on tzname and timezone
being valid. But like I said, it does work for us. Post-patch:
10/22/2001 19:11:45 DST: 1
Monday, 22-Oct-01 07:11 PM PDT -0700
11/01/2001 18:11:45 DST: 0
Thursday, 01-Nov-01 06:11 PM PST -0800
This appears to have been implemented with change 18267.
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
At 2:00 PM -0500 12/31/04, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 12/31/2004 01:01:12 PM: One other oddity noted with 6.25_07: $ mmk distclean snippage Not in MANIFEST: dbi.opt I am fairly certain that it used to be able to delete the linker options files that it wrote out before. I failed to mention this one before but it appears that both mmk clean and mmk distclean are now deleting the source for the EXE_FILES. Note: $ mmk clean MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f *.olb perl.c core core.[0-9] [.blib.arch.auto.DBI]extralibs.all core.[0-9][0-9] DBI.bso dbi.c MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f pm_to_blib.ts core.[0-9][0-9][0-9][0-9] DBI.x DBI.bs perl.exe tmon.out *.obj blibdirs.ts MCR $dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f core.[0-9][0-9][0-9][0-9][0-9] *perl.core core.*perl.*.? Makeaperl.MMS DBI.def perl core.[0-9][0-9][0-9] mon.out MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f libDBI.def perlmain.c perl.exe [.blib.arch.auto.DBI]extralibs.ld so_locations DBI.exp MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_rf dbiproxy.pl dbitrace.log ndtest.prt dbiprof.pl snip $ perl Makefile.PL snip Warning: the following files are missing in your kit: dbiprof.pl dbiproxy.pl Please inform the author. snip $ search Makefile.PL EXE_FILES EXE_FILES = [ dbiproxy$ext_pl, dbiprof$ext_pl ], I think this one is an old problem specific to DBI, and IIRC it's because it expects dbiproxy.PL to be a different file from dbiproxy.pl. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Craig A. Berry [EMAIL PROTECTED] wrote on 12/31/2004 03:34:14 PM:
I think this one is an old problem specific to DBI, and IIRC it's
because it expects dbiproxy.PL to be a different file from
dbiproxy.pl.
Indeed it seems that this is the case. I am sorry for having
reported a spurious problem as though it were MakeMaker's fault.
It would appears that folks on Windows and OS/2 (Mac OS?) would
also have trouble with this case sensitive addition to the
clean target:
$ search makefile.pl dbipr/win
VERSION_FROM= 'DBI.pm',
PREREQ_PM = { Test::Simple = 0.40 },
EXE_FILES = [ dbiproxy$ext_pl, dbiprof$ext_pl ],
DIR = [ ],
dynamic_lib = { OTHERLDFLAGS = $::opt_g },
clean = { FILES= \$(DISTVNAME) Perl.xsi t/zv*_*.t
. dbiproxy$ext_pl dbiprof$ext_pl dbitrace.log
dbi.prof ndtest.prt },
dist = {
DIST_DEFAULT= 'clean distcheck disttest tardist',
Nasty.
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM:
This is beginning to look like a problem with the XSUBPP macros.
I've found a workwaround for this specific problem that I'll
enclose as a diff. Since an OS specific hack inside of
MM_Unix.pm seems completely counter to the whole put overrides
into MM_$^O.pm design philosophy of MakeMaker I do not expect
this diff to be taken at face value as a patch. I am sending it
merely wanted to illustrate concretely where VMS
was experiencing trouble.
--- lib/extutils/mm_unix.pm;-1 Fri Dec 31 08:48:17 2004
+++ lib/ExtUtils/MM_Unix.pm Fri Dec 31 16:26:34 2004
@@ -3518,6 +3518,18 @@
$self-{XSPROTOARG} = unless defined $self-{XSPROTOARG};
+if ($Is_VMS)
+{
+return qq{
+XSUBPPDIR = $xsdir
+XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)xsubpp
+XSPROTOARG = $self-{XSPROTOARG}
+XSUBPPDEPS = @tmdeps
+XSUBPPARGS = @tmargs
+XSUBPP_EXTRA_ARGS =
+};
+}
+else {
return qq{
XSUBPPDIR = $xsdir
XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)/xsubpp
@@ -3526,6 +3538,7 @@
XSUBPPARGS = @tmargs
XSUBPP_EXTRA_ARGS =
};
+}
};
I have not yet found how to fix the .exists into OLB
problem nor the trouble with MMS V3.2-01 reported earlier.
Peter Prymmer
[perl #6949] make test fails on Linux 2.4.3 ReiserFS system
[EMAIL PROTECTED] - Sat May 05 21:50:28 2001]: Something in my setup is causing a problem. Running sh Configure -des make goes smoothly, but make test dies with the following: io/fs..FAILED at test 0 io/inplace. At this point the console displays an invalid operand () message, and the system is seriously hosed. While it will still respond to pings and switch virtual consoles via Alt+Fx, sshd and the console itself do not respond. My guess is something in the Linux hints file configures Perl in a way incompatible with one or more of Linux 2.4.3, ReiserFS, or LVM, but I don't know what that something might be. Could you please provide some suggestions on settings I should change? My apologies if this is a FAQ, but if so, I couldn't find it. Thanks! -Stephen J Gadsby, Multimedia Specialist Web and Multimedia Services, Information Technology Millersville University of Pennsylvania, USA I've been running Perl smoke tests on ReiserFS for a few months now and have not seen the problems in the ticket above. This ticket is resolved.
Re: perlpodtut II
Russ Allbery wrote: ...but yes, generally, AUTHOR does look odd to me. It just doesn't have anything that it can reasonably be combined with, except maybe the copyright information (which wouldn't make it much longer). What about combining AUTHOR with the sections ACKNOWLEDGMENTS, CREDITS, and CONTRIBUTORS? These and AUTHOR have the shared purpose of identifying who contributed to the software, either by actual coding and design or just by providing feedback, patches, or moral support. In fact, AUTHOR is not well named because there can be multiple authors and many types of contributors besides authors. Therefore, CONTRIBUTORS seems most appropriate for encompassing all of these Note that contributing to software does not necessarily provide someone legal rights to it. As I've suggested, anything with legal weight (e.g. copyright) might go in some type of LEGAL section. So, here's how I see the sections outlined, where each main section addresses precisely one major question or concern. NAME - name + one line description identifying the module SYNOPSIS - quick introductory examples _that precede_ the description DESCRIPTION - details on what the module does and lists functions LIMITATIONS (or BUGS, CAVEATS, RESTRICTIONS, TODO) - limitations of the module: what's broken, what can be be improved, common mistakes, whether the module is stable or experimental (e.g. interface subject to change) CONTRIBUTORS (or AUTHOR, CREDITS) - contributors, people to thank. AUTHOR seems appropriate only if the module is the work of largely one person. This may overlap pod2man's HISTORY section a bit if the contributions of the contributors are given. I.e. where did the ideas come from? (e.g. prior art) LEGAL (or LICENSE) - things with legal weight, i.e. for the lawyers to read and contemplate over SEE ALSO - like a bibliography, providing links to resources mentioned in the previous sections. The above sections are not perfect and do not address these other main questions: - Where can I obtain support? e.g. technical questions, provide feedback, submit bug reports and patches. Does the module have a project web site (e.g. on sourceforge)? and specifically - Where can the software be obtained? or downloaded from? what about development snapshots and CVS copies? This might be the AVAILABILITY section mentioned in perlpodtut II. - Has the interface ever changed? What changes affect compatibility? How are version numbers assigned? What provisions or guarantees are made for future changes to the module interface? - What other modules or components does the software depend on? Are there any OS or hardware requirements? (if any). Maybe these are LIMITATIONS. - Where are detailed and practical examples? E.g. like a tutorial or software cookbook showing solutions to common scenarios...things beyond the straightforward DESCRIPTION of the module. -david
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
At 3:59 AM -0500 12/31/04, Michael G Schwern wrote: http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_07.tar.gz or svn://svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you. Release candidate number *mumble* for 6.26. With Perl 5.8.4, OpenVMS Alpha 7.3-1, MMS V3.3-4, MMK 3.9-6, I get the following results. Using MMK, the build goes ok. Most tests pass, except basic.t, which has the following problem: # %DCL-W-TKNOVF, command element is too long - shorten # \DSA0:[SYS0.SYSCOMMON.PERL-5_8_4]PERL.EXE -E chdir 'liar.dir'; system 'MMK/MACRO=(TEST_VERBOSE=1) test /Macro=(LIBPERL_A=LIBPERL.OLB, LINKTYPE=DYNAMIC, OPTIMIZE=/NOLIST, PREFIX=../DUMMY-INSTALL, DESTDIR=, PASTHRU_DEFINE=)' if -f 'Descrip # %MMK-F-ERRUPD, error status %X000382A0 occurred when updating target TEST Aside from the command being too long, there is a problem with having multiple /MACRO qualifiers on the command line; they need to be combined into one qualifier, though in this case all it means is that TEST_VERBOSE will be ignored. With MMS, I can't build MakeMaker at all and get the following error: $ mms %MMS-F-LEXNULLNAME, Encountered null filename on line 365. Line 365 contains: blibdirs : $(INST_LIBDIR) $(INST_ARCHLIB) $(INST_AUTODIR) $(INST_ARCHAUTODIR) $(INST_BIN) $(INST_SCRIPT) $(INST_MAN1DIR) $(INST_MAN3DIR) $(NOECHO) $(NOOP) I believe the INST_* macros are considered null file specifications because they are just directory specs like [.foo.bar] rather than file specs like [.foo]bar.dir. I thought we had gone back to using .exists files rather than directories, so I'm not sure what to suggest here. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: perlpodtut II
David Manura [EMAIL PROTECTED] writes: Russ Allbery wrote: ...but yes, generally, AUTHOR does look odd to me. It just doesn't have anything that it can reasonably be combined with, except maybe the copyright information (which wouldn't make it much longer). What about combining AUTHOR with the sections ACKNOWLEDGMENTS, CREDITS, and CONTRIBUTORS? That was my original intention; you'll notice that none of those other sections appear in the pod2man summary. The description of AUTHORS doesn't mention this, though; I'll add that. NAME - name + one line description identifying the module SYNOPSIS - quick introductory examples _that precede_ the description DESCRIPTION - details on what the module does and lists functions LIMITATIONS (or BUGS, CAVEATS, RESTRICTIONS, TODO) - limitations of the module: what's broken, what can be be improved, common mistakes, whether the module is stable or experimental (e.g. interface subject to change) Personally, I prefer to separate out BUGS from CAVEATS (or RESTRICTIONS), the latter being bugs that won't be fixed. CONTRIBUTORS (or AUTHOR, CREDITS) - contributors, people to thank. AUTHOR seems appropriate only if the module is the work of largely one person. This may overlap pod2man's HISTORY section a bit if the contributions of the contributors are given. I.e. where did the ideas come from? (e.g. prior art) HISTORY is usually used for notes such as first became part of Perl core in Perl 5.005 or (outside of purely Perl documentation) things like first appeared in ANSI C 1989 or based on BSD4.3. I wish that more of the core modules had HISTORY sections stating when the module was first part of Perl core (and I see that my own modules are also missing this -- I should add that), since it matters for knowing when the presence of the module can be relied upon. LEGAL (or LICENSE) - things with legal weight, i.e. for the lawyers to read and contemplate over SEE ALSO - like a bibliography, providing links to resources mentioned in the previous sections. The above sections are not perfect and do not address these other main questions: - Where can I obtain support? e.g. technical questions, provide feedback, submit bug reports and patches. pod2man says this should go into the AUTHOR section if it's just a contact point for the author / maintainer. Does the module have a project web site (e.g. on sourceforge)? and specifically - Where can the software be obtained? or downloaded from? what about development snapshots and CVS copies? This might be the AVAILABILITY section mentioned in perlpodtut II. pod2man says this should go into SEE ALSO. A bug reporting database is sort of ambiguous between the two but really fits SEE ALSO more. - Has the interface ever changed? What changes affect compatibility? How are version numbers assigned? What provisions or guarantees are made for future changes to the module interface? HISTORY might be a worthwhile place to handle the first question, but in general I think this is the sort of thing that belongs in DESCRIPTION, in the main documentation of the module. This is important for anyone using the module and doesn't need to be relegated to one of the other sections at the end. - What other modules or components does the software depend on? Are there any OS or hardware requirements? (if any). Maybe these are LIMITATIONS. I usually add a REQUIREMENTS section at the very top of the documentation, right after SYNOPSIS. I notice that pod2man doesn't mention this and should. - Where are detailed and practical examples? E.g. like a tutorial or software cookbook showing solutions to common scenarios...things beyond the straightforward DESCRIPTION of the module. This is EXAMPLES, one of the sections that you missed in your summary (along with DIAGNOSTICS, ENVIRONMENT, FILES, and NOTES). Documentation for scripts should also contain an OPTIONS section and a RETURN VALUE section if the script returns specific status codes in some circumstances. Moving outside the realm of pure Perl documentation, man pages for function interfaces should include ERRORS and RETURN VALUE sections. I really need to write up a more comprehensive web page on all of this, particularly since I think we really want at least two slightly different standards (one for programs and one for modules) since the sections aren't the same (and I'd probably add a couple of other standards, one for function descriptions and one for configuration files, for the people who use POD to write man pages for things that aren't Perl-related). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: perlpodtut II
Juerd [EMAIL PROTECTED] writes: Discussing the sections is a very good idea, IMO, and eventually you could come up with formal standard for them, but perlpodtut is not the thing that should change the world. It should lag behind common practice. If this new formal standard can be made detailed enough, we can perhaps start having smarter indexers, that can eventually be used by editors to provide word completion and context based help in a more structured way than is already possible. However, perlpodtut really isn't the right context for philosophy about sections. Agreed on all counts, for the record. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: perlpodtut II
Discussing the sections is a very good idea, IMO, and eventually you could come up with formal standard for them, but perlpodtut is not the thing that should change the world. It should lag behind common practice. If this new formal standard can be made detailed enough, we can perhaps start having smarter indexers, that can eventually be used by editors to provide word completion and context based help in a more structured way than is already possible. However, perlpodtut really isn't the right context for philosophy about sections. Juerd
Re: [perl #32967] Re: More B bugs: svref_2object
AT == Alexey Tourbin [EMAIL PROTECTED] writes:
AT Brief description: consequent svref_2object calls produce wrong
AT B objects in certain cases. Detailed explanation and test cases
AT are available via the following links:
AT http://www.nntp.perl.org/group/perl.perl5.porters/96593
AT http://www.nntp.perl.org/group/perl.perl5.porters/96600
SMcC I think your diagnosis is correct. The B module in general, and
SMcC svref_2object in particular, does not increase the reference
SMcC count of the SV and OP objects the B::SV and B::OP proxies point
SMcC to, so bad things happen if the proxy is used after the
SMcC underlying object is freed. (I bet with more experimentation you
SMcC could get a segfault, for instance).
AT Okay, thanks a lot for this clarification. Unfortunately I don't quite
AT grok reference counting mechanism in Perl (for now). I just have a code
AT that has a kludge that apparently fixes the mechanism for perl-5.8.x.
AT The code is as follows:
AT [...] [snip]
AT To examine the real code, you may want to take a look at
AT http://search.cpan.org/dist/rpm-build-perl/ (only PVMG version
AT strings seems to break things). My original post has a very
AT simple example, though.
I think I can explain more easily what's going on in your simple
example. For the readers playing along at home, your short example
was:
AT my $v1 = 0.17;
AT my $v2 = 0.1.7;
AT sub get_sv {
AT my $v = shift;
AT my $sv = svref_2object(\$v);
AT return $sv;
AT }
AT Dump get_sv($v1);
AT get_sv($v2);
AT Dump get_sv($v1);
The first Dump shows that its argument is a reference to a B::NV
object, while the second shows its to be a reference to a B::PVMG.
What I think may be confusing about this example is that get_sv
doesn't actually tell you about its argument SV. Rather, it returns a
B::SV object that describes its local $v variable. When, as in the
unmodified example, no reference to $v escapes the subroutine (the
reference count of $v is 1 on leaving the subroutine), perl doesn't
bother to free the local; rather, it keeps it around to reuse the next
time the subroutine is called. This allows it to save time that would
otherwise be spent reallocating and upgrading the local on the next
sub call; it assumes that if you made an SV big and complicated on one
invocation, you likely will again.
Thus all three calls to get_sv return B::SV objects referring to the
same SV. When a PVMG is passed in the second get_sv() call, $v is
upgraded to accommodate it, and it stays upgraded for the third call.
If you change the code to pass the variable by reference, i.e.
sub get_sv {
my $vref = shift;
my $sv = svref_2object($vref);
return $sv;
}
Dumpget_sv(\$v1);
get_sv(\$v2);
Dumpget_sv(\$v1);
you'll see that $v1 stays an NV.
To sharpen what I was saying above, I don't think your bug comes from
an SV being freed to soon; rather, the SV is being reused
unexpectedly. Making another reference to the variable is a workaround
because it disables the reuse optimization; perl allocates a new SV,
which your code handles better.
On to how you might fix your real bug (note I've added a bit more
context in the first sub):
AT sub extract_version {
AT [...]
AT my $version = ;
AT [...]
AT use B qw(svref_2object);
AT our $perlbug32967 = \$version;
AT my $v = sv_version(svref_2object(\$version));
AT # process $v
AT [...]
AT use B qw(class);
AT sub sv_version ($) {
AT my $sv = shift;
AT my $class = class($sv);
AT if ($class eq IV or $class eq PVIV) {
AT return $sv-int_value;
AT }
AT if ($class eq NV or $class eq PVNV) {
AT return $sv-NV;
AT }
AT if ($class eq PVMG) {
AT for (my $mg = $sv-MAGIC; $mg; $mg = $mg-MOREMAGIC) {
AT next if $mg-TYPE ne V;
AT my @v = $mg-PTR =~ /(\d+)/g;
AT return $v[0] + $v[1] / 1000 + $v[2] / 1000/1000;
AT }
AT }
AT if ($sv-can(PV)) {
AT my $v = $sv-PV;
AT if ($v =~ /^\s*\.?\d/) {
AT $v =~ s/_//g;
AT return $v + 0;
AT }
AT }
AT return undef;
AT }
I think the real problem with sv_version is that its logic is wrong:
it's trying to switch on the representation type of the SV, rather
than the contents. Just because an SV is a PVMG doesn't mean it has
magic now (in particular, because SVs can't be downgraded).
For a single invocation that shows this problem, try:
my $x = 3;
study $x;
$x = 4;
print sv_version(svref_2object(\$x)), \n;
The first three lines make $x a PVMG with no string value or V magic
whose value is stored as an integer, but your code skips the branch
that would have called $sv-int_value because it's deciding based on
the SV's class.
I'd
