Re: resolving methods at compile time
One problem was that if you pass in something which inherits from Apache2::Connection you'd expect it to work. However if the object overrides foo() it will be ignored, which is probably not what you want to happen. A bit like static methods in C++, F On 8/17/05, Stas Bekman [EMAIL PROTECTED] wrote: A few years ago Doug MacEachern started to write code like: my Apache2::Connection $c = shift; $c-foo; # should be already resolved i.e. adding an explicit class name before the object. If I remember correctly he was saying that perl was supposed to optimise method lookups at compile-time. My question is: does it really work or is it still a wannabe? and if the latter what are the plans for making it really work? Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Smoke [5.9.0] 25300 FAIL(m) openbsd 3.6 (i386/1 cpu)
Automated smoke report for 5.9.0 patch 25300 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 25300 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)
Smoke [5.9.3] 25301 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
Automated smoke report for 5.9.3 patch 25301 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 19 minutes (average 15 minutes 29 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25301 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 O 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 Compiler messages(MSWin32): ..\numeric.c(900) : warning C4090: 'initializing' : different 'const' qualifiers 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: autouse.pm: check stub, use goto in stub
Alexey Tourbin wrote:
Hello,
$ perl -e 'use autouse Pod::Usage = pod2usage((); pod2usage()'
Undefined subroutine main::pod2usage called at -e line 1.
$
--- autouse.pm- 2004-07-04 21:32:39 +
+++ autouse.pm2005-08-18 05:01:52 +
Thanks, both autouse patches applied as change #25302.
@@ -63,7 +62,8 @@ sub import {
};
if (defined $proto) {
- *$closure_import_func = eval sub ($proto) { \$load_sub };
+ *$closure_import_func = eval sub ($proto) { goto \$load_sub }
+ || die;
} else {
*$closure_import_func = $load_sub;
}
End of patch
$ perl -e 'use autouse Pod::Usage = pod2usage((); pod2usage()'
Prototype not terminated at (eval 1) line 1.
...propagated at /usr/lib/perl5/autouse.pm line 65.
BEGIN failed--compilation aborted at -e line 1.
$
I guess the latter behaviour is more appropriate. I also see no reason
for saving a stub frame, so using goto should be ok.
Re: [PATCH] Re: Transliteration operator(tr//)on EBCDIC platform
SADAHIRO Tomoyuki wrote: 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. Thanks, applied as change #25303 to bleadperl.
New and improved Text::Tabs::expand()
Hi David and porters,
I took the time to write a Text::Tabs::expand() replacement which
performs well in the presence of newlines (see “BUGS” in the
POD). Attached is a benchmark script containing the old and new
functions.
I've taken care to ensure that the rewritten function works
*exactly* like the original. It is consistently faster even when
using arrays (by about 145% on my machine) and always degrades
linearly with the input size, regardless of whether it’s
processing a single string or a an array. The original function
has O(n²) performance for multiline strings. You can observe
these points by progressively increasing the size of the test
data. With the included test data, the rewrite is about 145×
faster than the original, but that doesn’t say much, as the
disparity grows further and further the longer the input grows.
[Please CC replies to me, as I’m not subscribed to the list.]
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
tabs.pl
Description: tabs-bench.pl
[perl #36937] Perl Bug durring test stage of install on Windows XP -- included source of error and possible fix
# New Ticket Created by Brent Hostetler # Please include the string: [perl #36937] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36937 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] There are some problems in the follwing test when doing an install in windows: * ../ext/IO/t/io_dup.t * comp/multiline.t * io/dup.t All there errors are related to the following syntax of code: $out = (($^O eq 'MSWin32') || $^O eq 'NetWare' || $^O eq 'VMS') ? `type Comp.try` If you have installed cygwin, or unix utils http://unxutils.sourceforge.net/ you end up with a type cmd in the path which is executed instead of the cmd.exe shell version of type and results in errors in the previously listed tests. I believe this could be fixed using something such as: ? `cmd.exe /C type Comp.try` The tests run fine if I temporarily remove the type.exe from my path. Thanks. Brent Hostetler [EMAIL PROTECTED] [Please do not change anything below this line] - --- Flags: category=install severity=high --- Site configuration information for perl v5.8.7: Configured by Brent at Wed Aug 17 20:52:38 2005. Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=MSWin32, osvers=5.1, 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='gcc', ccflags ='-s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='3.4.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags ='-s -Lc:\perl\lib\CORE -LC:\MinGW\lib' libpth=C:\MinGW\lib libs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 perllibs= -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 libc=-lmsvcrt, so=dll, useshrplib=yes, libperl=libperl58.a gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -Lc:\perl\lib\CORE -LC:\MinGW\lib' Locally applied patches: --- @INC for perl v5.8.7: C:/src/perl-5.8.7/lib . --- Environment for perl v5.8.7: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\perl\bin;c:\ MinGW\bin;c:\usr\local\wbin\;c:\bin;C:\Program Files\Symantec\pcAnywhere\ PERL_BADLANG (unset) SHELL (unset)
Re: [PATCH] 5.9.x (and 5.8.x): Symbian update
[EMAIL PROTECTED] wrote: The 5.9.x patch is against the patch level 25301, and contains minor const-change induced changes, plus adding Compress::Zlib to the set of supported extensions (also adding IO::Zlib). Thanks, applied as #25304 to bleadperl; including the C::Zlib changes. Note the changes to Zlib.xs: firstly because there can be no modifiable data in Symbian DLLs, secondly because I don't understand how the printf()s could have been working (the Symbian port uses PerlIO, meaning among other things that using of bare printf()s is an error), thirdly because I also can't see how the myperl context could have been visible (hence the added dTHXs). The 5.8.x patch is against the patch level 24695, and of course is a large one since the Symbian patches have not been (and should not be) integrated into the maint proper. I will also upload these to the symbianperl sf.net site, once I get a round tuit. We had a lot of those at OSCON. Maybe ask TPF to ship a box of tuits to Finland ?
Smoke [5.9.3] 25301 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25301 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 55 minutes (average 1 hour 57 minutes) Summary: FAIL(XF) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25301 Configuration (common) none --- - F F - - -Duse64bitint X O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 [stdio] Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
make test of perl 5.8.7 failed on icc9
I build perl with icc9, but got message some tests failed.
hints/linux.sh cannot detect icc9 as icc.
diff -urN perl-5.8.7.orig/hints/linux.sh perl-5.8.7/hints/linux.sh
--- perl-5.8.7.orig/hints/linux.sh 2005-04-05 05:08:31.0 +0900
+++ perl-5.8.7/hints/linux.sh 2005-08-18 17:37:46.0 +0900
@@ -75,7 +75,7 @@
# Check if we're about to use Intel's ICC compiler
case `${cc:-cc} -V 21` in
-*Intel(R) C++ Compiler*)
+*Intel(R) C++ Compiler*|*Intel(R) C Compiler*)
# This is needed for Configure's prototype checks to work correctly
ccflags=-we147 $ccflags
# If we're using ICC, we usually want the best performance
$ /opt/intel/cc/9.0/bin/icc -V
Intel(R) C Compiler for 32-bit applications, Version 9.0Build 20050722Z
Package ID: l_cc_c_9.0.024
Copyright (C) 1985-2005 Intel Corporation. All rights reserved.
--
YAMASHINA Hio [EMAIL PROTECTED]
Re: make test of perl 5.8.7 failed on icc9
YAMASHINA Hio wrote:
I build perl with icc9, but got message some tests failed.
hints/linux.sh cannot detect icc9 as icc.
diff -urN perl-5.8.7.orig/hints/linux.sh perl-5.8.7/hints/linux.sh
--- perl-5.8.7.orig/hints/linux.sh 2005-04-05 05:08:31.0 +0900
+++ perl-5.8.7/hints/linux.sh 2005-08-18 17:37:46.0 +0900
@@ -75,7 +75,7 @@
# Check if we're about to use Intel's ICC compiler
case `${cc:-cc} -V 21` in
-*Intel(R) C++ Compiler*)
+*Intel(R) C++ Compiler*|*Intel(R) C Compiler*)
Thanks, applied as #25305 to bleadperl.
RE: [PATCH] 5.9.x (and 5.8.x): Symbian update
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] The 5.9.x patch is against the patch level 25301, and contains minor const-change induced changes, plus adding Compress::Zlib to the set of supported extensions (also adding IO::Zlib). Note the changes to Zlib.xs: firstly because there can be no modifiable data in Symbian DLLs, secondly because I don't understand how the printf()s could have been working (the Symbian port uses PerlIO, meaning among other things that using of bare printf()s is an error), thirdly because I also can't see how the myperl context could have been visible (hence the added dTHXs). Thanks, patch applied to my development copy. Paul ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: New and improved Text::Tabs::expand()
On Thu, Aug 18, 2005 at 11:53:08AM +0200, A. Pagaltzis ([EMAIL PROTECTED]) wrote: I've taken care to ensure that the rewritten function works *exactly* like the original. It is consistently faster even when using arrays (by about 145% on my machine) and always degrades This sounds great. I don't see a patch, though. How did you make sure that it works *exactly* like the original? Did you write tests for it? Can we turn those tests in .t files? xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: resolving methods at compile time
On 8/17/05, Dave Mitchell [EMAIL PROTECTED] wrote: On Wed, Aug 17, 2005 at 03:37:13PM -0500, David Nicol wrote: which could also AIUI benefit /slightly/ from binding the subroutine's entry point directly to the node that calls it instead of looking the entry point up in a hash, This would not work. The same sub entry op may call many different functions: $_-foo() for qw(A B C::D); Under discussion is optimizing in the case of typed localized variables. my dog $iggy; $iggy-make_sound; # bound early to dog::make_sound due to declared type not a general early binding. [unifying ops and SVs] would be a Dumb Thing. Do they have reference counts? I guess I can look at the source for once. BASEOP in op.h does not appear to define reference count field. Being able to recycle optree memory is another thing that would be more trouble than its worth. But repeated eval-strings isn't a memory leak --- how do we do that now? Mark and sweep? Return opnodes to a pool after an eval-string unless they get referred to by something external to the eval?
Re: resolving methods at compile time
On Thu, Aug 18, 2005 at 01:54:23PM -0500, David Nicol wrote: This would not work. The same sub entry op may call many different functions: $_-foo() for qw(A B C::D); Under discussion is optimizing in the case of typed localized variables. my dog $iggy; $iggy-make_sound; # bound early to dog::make_sound due to declared type not a general early binding. @Dog::ISA = qw(Mammal); ... my Mammal $x = new Dog; $x-foo(); # may be Dog::foo() or Mammal::foo() [unifying ops and SVs] would be a Dumb Thing. Do they have reference counts? I guess I can look at the source for once. BASEOP in op.h does not appear to define reference count field. Being able to recycle optree memory is another thing that would be more trouble than its worth. But repeated eval-strings isn't a memory leak --- how do we do that now? Mark and sweep? Return opnodes to a pool after an eval-string unless they get referred to by something external to the eval? ops are in a tree of ops that are attached to a CV. The head of the op tree has a refcnt, so that the tree can be shared amongst several CVs. When the last CV is freed, the tree is freed. Each OP struct is usually indivdually malloced or freed, although there is code, not normally enabled, to allocate them from arenas. This is of course irrelvant as to whether unifying OPs and SVs would be a good thing. -- In the 70's we wore flares because we didn't know any better. What possible excuse does the current generation have?
Re: resolving methods at compile time
On 8/18/05, Dave Mitchell [EMAIL PROTECTED] wrote: @Dog::ISA = qw(Mammal); ... my Mammal $x = new Dog; $x-foo(); # may be Dog::foo() or Mammal::foo() As I hid in the middle of a wordy paragraph a few posts back in this thread, [the proposed optimization] would break subclassing in the absense of explicitly marked virtual methods by the way, unless the explicit marking of the virtual methods would be done by the compiler, as in D The optimizer would only optimize an op when there was only one possible call, so it would have to not optimize when there's a chance of ambiguity. When a method of the same name appears in a subclass, that method in the base class gets flagged as virtual and may not be optimized. We can't control later addition of subclasses, but we can switch the optree to a new CV and assign the old CV to the 'deoptimize thyself' routine, when a method that has not been virtual before becomes virtual due to appearing in a newly added subclass. Which implies tracking @ISBASEOF as well as @ISA. Or does it? When a new routine is defined, in the presence of an @ISA, @ISA gets traversed and any colliding routines would get flagged as virtual and get slapped if they have been flagged as having optimized calls to them somewhere. So in the example above, $x-foo could be optimized only if there are no foo() methods in any classes that inherit from Mammal, or also inherit from wherever Mammal got its foo method from. In the list of features to abandon in C++, (http://www.digitalmars.com/d/overview.html), Digital Mars has this to say: Non-virtual member functions. In C++, a class designer decides in advance if a function is to be virtual or not. Forgetting to retrofit the base class member function to be virtual when the function gets overridden is a common (and very hard to find) coding error. Making all member functions virtual, and letting the compiler decide if there are no overrides and hence can be converted to non-virtual, is much more reliable. In Perl, of course, all functions are virtual. When, and only when, there are no overrides, a conversion to a tighter binding may be appropriate. And when an override appears later, we would need to be able to revert. But what about -- @upper::ISA = qw(middle); @middle::ISA = qw(lower); @lower::ISA = (); when subs lower::foo and middle::foo both exist but no upper::foo exists, a call (my middle $x = new upper)-foo could be optimized, since lower::foo has been overridden but middle::foo has not, and $x is guaranteed to be a middle or something that inherits from middle. (my lower $x = new upper)-foo could not be optimized. Cost: Two new flags on a CV, one flag for has-been-overridden and one flag for has-been-optimized, and code to check all these flags all the time Benefit: it becomes possible to make a non-noticeable performance improvement when special syntax is used Executive vote: more trouble than its worth (but D looks interesting) ops are in a tree of ops that are attached to a CV, [which is a kind of SV.] Thanks.
Re: resolving methods at compile time
On Thu, Aug 18, 2005 at 04:10:50PM -0500, David Nicol wrote: Executive vote: more trouble than its worth (but D looks interesting) This is the conclusion I'm coming to for just about all speed optimisations, where the intent is to buy more speed by increasing complexity. I feel that we'd be much better served by attempting to simplify the current code base (without losing functionality) and see whether that opens up any new insights. (As well as fixing bugs and generally increasing maintainability and accessibility) Nicholas Clark
Re: resolving methods at compile time
Nicholas Clark wrote: On Thu, Aug 18, 2005 at 04:10:50PM -0500, David Nicol wrote: Executive vote: more trouble than its worth (but D looks interesting) This is the conclusion I'm coming to for just about all speed optimisations, where the intent is to buy more speed by increasing complexity. I feel that we'd be much better served by attempting to simplify the current code base (without losing functionality) and see whether that opens up any new insights. (As well as fixing bugs and generally increasing maintainability and accessibility) Nicholas Clark I'll take this opportunity to note the existence of B::Generate optimizer.pm, with which you can do various function replacements / optimizations. (btw, I have patches for them, so they properly compile run, on 5.6.2-nothread, 5.8.x-nothread, 5.9.3-thread) I did so once, but I modified only Class-methods so that I didnt inadvertently hose someone elses $flaregun-warn() calls. At this time, I would like to ask that fold_constants be added to the API, or to some sort of meta-stable privileged API, so that *deep magic* like that done by B::Generate, not be forever relegated to a backwater / podunk / redhead-stepchild status. Those 2 modules are too cool to let languish. thanks jimc
RFC - eliminate discrete arenaroots
attached is an almost-there patch which:
replaces most arena-root pointers with an array of them
replaces same root pointers with array.
simplifies several macros using them.
the line-count doesnt shrink much, but it simplifies source code, and
shrinks object code:
-rw-rw-r-- 1 jimc jimc 573992 Aug 18 15:23 array-arena-bld/sv.o
-rw-rw-r-- 1 jimc jimc 576724 Aug 17 08:02 ../bleadperl/sv.o
$VAR1 = {
'Perl_sv_free_arenas' = [
'032b',
'0161'
],
'S_sv_unglob' = [
'014a',
'013d'
],
'Perl_sv_upgrade' = [
'0874',
'07b5'
],
'S_more_bodies' = [
'009d',
'0100'
],
'Perl_ptr_table_store' = [
'011c',
'010f'
],
'perl_clone' = [
'3bee',
'3ae6'
],
'S_new_body' = [
'0042',
'0064'
],
'sizeof_body_by_svtype' = [
'0040'
],
'Perl_sv_clear' = [
'0bf9',
'0bfa'
],
'Perl_sv_dup' = [
'1397',
'138f'
]
};
I know theres more code-shrink to do here
some macros will probably shrink or disappear
some switches will probably collapse some ( I did a bunch of cases
in sv_upgrade)
but Id like to solve (or have solved for me) the following failures on a
threaded build.
t/op/taintok
t/op/threads..sh: line 1: 29472 Segmentation
fault /home/jimc/perl/core/dev/array-arena-bld/perl -I../lib
misctmp006 21
# PROG:
# use threads;
# threads-new(sub { my %h=(1,2); delete $h{1}})-join for 1..2;
# print ok;
# EXPECTED:
# ok
# GOT:
# STATUS: 35584
# Failed at op/threads.t line 26
sh: line 1: 29474 Segmentation fault
/home/jimc/perl/core/dev/array-arena-bld/perl -I../lib misctmp006 21
# PROG:
# use threads;
# use Scalar::Util;
# my $data = a;
# my $obj = \$data;
# my $copy = $obj;
# Scalar::Util::weaken($copy);
# threads-new(sub { 1 })-join for (1..1);
# print ok;
# EXPECTED:
# ok
# GOT:
# STATUS: 35584
# Failed at op/threads.t line 35
FAILED at test 1
t/op/tie..ok
ext/threads/shared/t/0nothreadok
ext/threads/shared/t/av_refs..FAILED--expected 11 tests, saw 3
ext/threads/shared/t/av_simpleFAILED--expected 43 tests, saw 9
ext/threads/shared/t/cond.FAILED--expected 31 tests, saw 1
ext/threads/shared/t/disabled.ok
ext/threads/shared/t/hv_refs..FAILED--expected 17 tests, saw 3
ext/threads/shared/t/hv_simpleFAILED--expected 15 tests, saw 2
ext/threads/shared/t/no_share.FAILED--expected 5 tests, saw 3
ext/threads/shared/t/shared_attr..FAILED--expected 81 tests, saw 2
ext/threads/shared/t/sv_refs..FAILED--expected 10 tests, saw 6
ext/threads/shared/t/sv_simpleFAILED--expected 10 tests, saw 3
ext/threads/shared/t/wait.FAILED--expected test 6, saw
test 1
ext/threads/t/basic...FAILED--expected 19 tests, saw 1
ext/threads/t/end.FAILED--expected 6 tests, saw 1
ext/threads/t/joinFAILED--expected 14 tests, saw 1
ext/threads/t/libcFAILED--expected 11 tests, saw 0
ext/threads/t/listFAILED--expected 8 tests, saw 2
ext/threads/t/problemsFAILED--expected 14 tests, saw 0
ext/threads/t/stress_cv...FAILED--expected 64 tests, saw 3
ext/threads/t/stress_re...FAILED--expected 64 tests, saw 3
ext/threads/t/stress_string...FAILED--expected 64 tests, saw 3
ext/threads/t/thread..FAILED--expected 31 tests, saw 1
ext/Time/HiRes/t/HiResok
diff -ruN -X exclude-diffs ../bleadperl/intrpvar.h array-arena-bld/intrpvar.h
--- ../bleadperl/intrpvar.h 2005-06-29 02:41:56.0 -0600
+++ array-arena-bld/intrpvar.h 2005-08-18 14:59:30.0 -0600
@@ -245,18 +245,10 @@
PERLVAR(Isighandlerp, Sighandler_t)
-PERLVAR(Ixnv_root, NV *) /* free xnv list */
-PERLVAR(Ixpv_root, xpv_allocated *)/* free xpv list */
-PERLVAR(Ixpviv_root,
[EMAIL PROTECTED] Constant.t fix for VMS.
This test script was not using the same names for the VMS specific files
descrip.mms and descrip.mms_old that the rest of Makemaker was doing.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- lib/ExtUtils/t/Constant.t_25305 Thu Aug 18 20:33:20 2005
+++ lib/ExtUtils/t/Constant.t Thu Aug 18 20:30:23 2005
@@ -48,7 +48,7 @@
# Renamed by make clean
my $makefile = ($^O eq 'VMS' ? 'descrip' : 'Makefile');
my $makefile_ext = ($^O eq 'VMS' ? '.mms' : '');
-my $makefile_rename = $makefile . ($^O eq 'VMS' ? '.mms' : '.old');
+my $makefile_rename = $makefile . ($^O eq 'VMS' ? '.mms_old' : '.old');
my $output = output;
my $package = ExtTest;
@@ -250,7 +250,7 @@
check_for_bonus_files ('.', @$files, $output, $makefile_rename, '.', '..');
- rename $makefile_rename, $makefile
+ rename $makefile_rename, $makefile . $makefile_ext
or die Can't rename '$makefile_rename' to '$makefile': $!;
unlink $output or warn Can't unlink '$output': $!;
Re: [EMAIL PROTECTED] Constant.t fix for VMS.
- rename $makefile_rename, $makefile + rename $makefile_rename, $makefile . $makefile_ext or die Can't rename '$makefile_rename' to '$makefile': $!; Shouldn't that be or die Can't rename '$makefile_rename' to '$makefile$makefile_ext': $! xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
