Re: @array = $scalar
On 8/31/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, @array = $scalar;# really means @array = ($scalar,); # same as If list construction is via the infix:, operator, does that mean a blasphemous sinner could create infix:,= as a synonym for push? @array ,= $foo ; @array = @array, $foo; Ashley Winters
Re: Call for B0rked
On Wed, Aug 31, 2005 at 07:37:01PM -0400, Will Coleda wrote: However, I vote for the following, which are more specific: Unfinished Opcodes: https://rt.perl.org/rt3//Ticket/Display.html?id=32544 (split) [should be doable if we s/regexp/perl 6 rule/ and use PGE.] In recent discussions (and for a variety of reasons) I've been advocating that the definition of the split opcode should be modified so that it separates based on a constant string rather than a regular expression or perl 6 rule. There are several places where this would be helpful to PGE, and separating on constant strings ought to be optimizable to be a lot faster than what a p6 rule can do. For splitting on regular expressions, PGE can then provide its own split method or function that doesn't require hooking into the opcode vtable. What's more, it would potentially be able to do splits on any pattern expression, not just those written with perl 6 rules syntax. o Add rules engines for perl5-ish RE's in PGE: (I specifically want http://www.tcl.tk/man/tcl8.5/TclCmd/re_syntax.htm, but having a perl5- ish one I can subclass would be just dandy. =-) Oh, we can probably work on this one. :-) Pm
Re: Operator sub names are not special
On Wed, Aug 31, 2005 at 13:43:57 -0600, Luke Palmer wrote:
Uh yeah, I think that's what I was saying. To clarify:
sub foo (prefix:+) { 1 == 2 }# 1 and 2 in numeric context
foo(say); # nothing printed
But:
sub foo (prefix:+) { +1 == +2 }
foo(say);# 1 and 2 printed
Luke
Furthermore, even if:
sub infix:== ($x, $y) { +$x == +$y }
sub foo (prefix:+) { 1 == 2 }
foo(say); # nothing printed
but if
sub foo (*prefix:+) { 1 == 2 }
then what?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does a karate-chop-flip: neeyah!!
pgppXjgXKwsYS.pgp
Description: PGP signature
Re: @array = $scalar
On 01/09/05, Ashley Winters [EMAIL PROTECTED] wrote: If list construction is via the infix:, operator, does that mean a blasphemous sinner could create infix:,= as a synonym for push? If the self-assignment metaoperator works the way I think it does[1], then you shouldn't even need to create infix:,= yourself -- it should work automatically. Stuart [1] i.e. magically applies itself to any valid infix operator, just like »« and [] do
Re: @array = $scalar
Ashley Winters skribis 2005-09-01 0:58 (-0700): If list construction is via the infix:, operator, does that mean a blasphemous sinner could create infix:,= as a synonym for push? You could do that even without , being a list constructor. However, in general, chained operators like comma, junction constructors and infix zip, don't get an op= variant. There's something nice in $foo = 42; $foo |= .bar for @quux; as an alternative for $foo = any 42, @quux.bar; though Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: @array = $scalar
Stuart Cook skribis 2005-09-01 22:49 (+1000): [1] i.e. magically applies itself to any valid infix operator, just like »« and [] do , is not a normal binary infix operator. It's not even binary, although it can of course be used with only two operands. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: GMC release
After svn up, realclean, configure; make: ~/research/gmc wcoleda$ make parrot Invoking Parrot to generate runtime/parrot/include/config.fpmc -- cross your fingers ./miniparrot config_lib.pasm runtime/parrot/include/config.fpmc make: *** [runtime/parrot/include/config.fpmc] Error 138 Running through gdb, I get the following backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0004 0x00049ff4 in gc_gmc_copy_gen (from=0xd06a10, dest=0xd139e0) at src/ gc_gmc.c:879 879 PMC_body(Gmc_PMC_hdr_get_PMC(ptr)) = Gmc_PMC_hdr_get_BODY(ptr); (gdb) bt #0 0x00049ff4 in gc_gmc_copy_gen (from=0xd06a10, dest=0xd139e0) at src/gc_gmc.c:879 #1 0x0004a1b0 in gc_gmc_more_bodies (interpreter=0xd00180, pool=0xd056a0) at src/gc_gmc.c:933 #2 0x00049898 in gc_gmc_new_body (interpreter=0xd00180, pool=0xd056a0, size=40, aggreg=4) at src/gc_gmc.c:705 #3 0x00049a00 in gc_gmc_get_free_object_of_size (interpreter=0xd00180, pool=0xd056a0, size=40, aggreg=4) at src/ gc_gmc.c:741 #4 0x00049c3c in gc_gmc_get_free_typed_object (interpreter=0xd00180, pool=0xd056a0, base_type=62) at src/gc_gmc.c:796 #5 0x000a3b18 in new_pmc_alloc_header (interpreter=0xd00180, flags=132096, is_typed=1, base_type=62) at src/headers.c:270 #6 0x000a3d14 in new_pmc_typed_header (interpreter=0xd00180, flags=132096, base_type=62) at src/headers.c:343 #7 0x000307d8 in get_new_pmc_header (interpreter=0xd00180, base_type=62, flags=132096) at src/pmc.c:231 #8 0x0003090c in constant_pmc_new (interpreter=0xd00180, base_type=62) at src/pmc.c:310 #9 0x000b2514 in mmd_create_builtin_multi_meth_2 (interpreter=0xd00180, func_nr=5, type=33, right=-100, func_ptr=0x22dea0 Parrot_Complex_i_multiply_int) at src/mmd.c:2116 #10 0x000b26a0 in mmd_create_builtin_multi_meth (interpreter=0xd00180, type=33, entry=0x2c6f40) at src/mmd.c:2138 #11 0x000b27ec in Parrot_mmd_register_table (interpreter=0xd00180, type=33, mmd_table=0x2c6de0, n=35) at src/mmd.c:2182 #12 0x0022f220 in Parrot_Complex_class_init (interp=0xd00180, entry=33, pass=1) at classes/complex.c:1389 #13 0x0020c4a4 in Parrot_initialize_core_pmcs (interp=0xd00180) at src/core_pmcs.c:126 #14 0x000a2b24 in init_world (interpreter=0xd00180) at src/ global_setup.c:85 #15 0x0001505c in Parrot_init (interpreter=0xd00180) at src/embed.c:84 #16 0x00014870 in make_interpreter (parent=0x0, flags=PARROT_NO_FLAGS) at src/inter_create.c:165 #17 0x00015004 in Parrot_new (parent=0x0) at src/embed.c:47 #18 0x3a54 in main (argc=2, argv=0xb9bc) at imcc/main.c:452 Regards. On Aug 31, 2005, at 8:28 PM, Nattfodd wrote: Will Coleda wrote: On Aug 31, 2005, at 7:03 PM, Nattfodd wrote: If people are willing to test real programs with it, it would really be nice ! Thought I'd give languages/tcl a whirl, but after a fresh checkout of the GMC branch: % perl Configure.pl; make SNIP perl build_tools/jit2h.pl ppc src/jit_cpu.c jit2h: 121 (+ 143 vtable) of 1390 ops are JITed. src/jit_cpu.c src/jit_debug.c src/jit_debug.c: In function 'write_types': src/jit_debug.c:159: error: parse error before '-' token src/jit_debug.c:160: error: parse error before '-' token make: *** [src/jit_debug.o] Error 1 Hi, it builds fine here (x86)... I guess this makes sense, as jit is arch-dependant. However, I fear I won't be able to fix it (I understand next to nothing to jit). For now, I replaced those two entries by -1. As it is only debug, it shouldn't be very important and should be hopefully fixed soon by a jit(i) master (hahaha, hum, it's getting late). Please try to svn up... Regards, Alexandre
TypeCheck 1.0
I have released TypeCheck 1.0: The uploaded file Devel-TypeCheck-1.0.tar.gz has entered CPAN as file: $CPAN/authors/id/B/BA/BARGLE/Devel-TypeCheck-1.0.tar.gz size: 34411 bytes md5: 0de38ecd71d35205b17a22c8d3666fc8 Features of this version: -Aggregate data types (hashes and arrays) -More readable output -Numerous bug fixes -Better documentation Please let me know if there is anything I can clarify. -- Gary
Re: GMC release
On Thu, 1 Sep 2005, Nattfodd wrote: today is the deadline for the google summer of code projects, and it's time anyway for a release of GMC. GMC is a generational garbage collector for parrot that allows copying of objects and thus copying GC schemes. Thanks for submitting this. I also appreciated the extensive comments in the source (even if I didn't actually read most of them :-). svn co https://svn.perl.org/parrot/branches/gmc First, I needed the following simple patch to MANIFEST --- gmc/MANIFESTThu Sep 1 09:12:48 2005 +++ parrot-andy/MANIFESTThu Sep 1 10:19:20 2005 @@ -1639,6 +1639,7 @@ src/exec_start.c [] src/exit.c[] src/extend.c [] +src/gc_gmc.c [] src/gc_gms.c [] src/gc_ims.c [] src/generic_register.c[] After that, with Sparc/Solaris 8, with Sun's CC, I got a core dump even on a simple ./miniparrot -h I rebuilt with debugging, and it again core dumped (although somewhere else). Here's the backtrace: (dbx) run -h Running: miniparrot -h (process id 21433) [EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in gc_gmc_copy_gen at line 879 in file gc_gmc.c 879 PMC_body(Gmc_PMC_hdr_get_PMC(ptr)) = Gmc_PMC_hdr_get_BODY(ptr); (dbx) where current thread: [EMAIL PROTECTED] =[1] gc_gmc_copy_gen(from = 0x32dbe8, dest = 0x4d31f8), line 879 in gc_gmc.c [2] gc_gmc_more_bodies(interpreter = 0x2b6ce8, pool = 0x31d860), line 933 in gc_gmc.c [3] gc_gmc_new_body(interpreter = 0x2b6ce8, pool = 0x31d860, size = 40U, aggreg = 4), line 705 in gc_gmc.c [4] gc_gmc_get_free_object_of_size(interpreter = 0x2b6ce8, pool = 0x31d860, size = 40U, aggreg = 4), line 741 in gc_gmc.c [5] gc_gmc_get_free_typed_object(interpreter = 0x2b6ce8, pool = 0x31d860, base_type = 62), line 796 in gc_gmc.c [6] new_pmc_alloc_header(interpreter = 0x2b6ce8, flags = 132096U, is_typed = 1, base_type = 62), line 270 in headers.c [7] new_pmc_typed_header(interpreter = 0x2b6ce8, flags = 132096U, base_type = 62), line 343 in headers.c [8] get_new_pmc_header(interpreter = 0x2b6ce8, base_type = 62, flags = 132096U), line 231 in pmc.c [9] constant_pmc_new(interpreter = 0x2b6ce8, base_type = 62), line 310 in pmc.c [10] mmd_create_builtin_multi_meth_2(interpreter = 0x2b6ce8, func_nr = 5, type = 33, right = -100, func_ptr = 0x1edce0 = Parrot_Complex_i_multiply_int()), line 2116 in mmd.c [11] mmd_create_builtin_multi_meth(interpreter = 0x2b6ce8, type = 33, entry = 0xffbef444), line 2139 in mmd.c [12] Parrot_mmd_register_table(interpreter = 0x2b6ce8, type = 33, mmd_table = 0xffbef2e4, n = 35), line 2182 in mmd.c [13] Parrot_Complex_class_init(interp = 0x2b6ce8, entry = 33, pass = 1), line 1390 in complex.c [14] Parrot_initialize_core_pmcs(interp = 0x2b6ce8), line 126 in core_pmcs.c [15] init_world(interpreter = 0x2b6ce8), line 85 in global_setup.c [16] Parrot_init(interpreter = 0x2b6ce8), line 84 in embed.c [17] make_interpreter(parent = (nil), flags = PARROT_NO_FLAGS), line 165 in inter_create.c [18] Parrot_new(parent = (nil)), line 47 in embed.c [19] main(argc = 2, argv = 0xffbefa8c), line 452 in main.c I #defined GMC_DEBUG and BIG_DUMP, and the last entries may be relevant: Copying gen (32e730,32f760) to gen (4d3d40,4d4d70) copy_gen: ptr 4c0904, old_body 32f554, new_body 4d4b64, struct_val: deadbeef copy_gen: ptr 47e078, old_body 32f57c, new_body 4d4b8c, struct_val: deadbeef copy_gen: ptr 46f7bc, old_body 32f5a4, new_body 4d4bb4, struct_val: deadbeef copy_gen: ptr 4683d8, old_body 32f5cc, new_body 4d4bdc, struct_val: deadbeef copy_gen: ptr 46845c, old_body 32f5f4, new_body 4d4c04, struct_val: deadbeef copy_gen: ptr 4684d4, old_body 32f61c, new_body 4d4c2c, struct_val: deadbeef copy_gen: ptr 3555a4, old_body 32f644, new_body 4d4c54, struct_val: deadbeef copy_gen: ptr 3555b0, old_body 32f66c, new_body 4d4c7c, struct_val: deadbeef copy_gen: ptr 355820, old_body 32f694, new_body 4d4ca4, struct_val: deadbeef Overall, I wonder if it's an alignment issue, since SPARC tends to be much more sensitve to that than x86. I haven't looked deeply at the code at all, but do you do anything special to ensure that the blocks of memory you are moving around maintain their aligment? -- Andy Dougherty [EMAIL PROTECTED]
Re: Operator sub names are not special
On 9/1/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Wed, Aug 31, 2005 at 13:43:57 -0600, Luke Palmer wrote:
Uh yeah, I think that's what I was saying. To clarify:
sub foo (prefix:+) { 1 == 2 }# 1 and 2 in numeric context
foo(say); # nothing printed
But:
sub foo (prefix:+) { +1 == +2 }
foo(say);# 1 and 2 printed
Luke
Furthermore, even if:
sub infix:== ($x, $y) { +$x == +$y }
sub foo (prefix:+) { 1 == 2 }
foo(say); # nothing printed
but if
sub foo (*prefix:+) { 1 == 2 }
then what?
Um, you can't do that. You can't lexically bind a global; that's why
it's global. You could do:
sub foo (plus) { temp *prefix:+ = plus; 1 == 2 }
And then something would be printed... maybe, depending on the
implementation of == (with your implementation above, it would).
Luke
Re: GMC release
Andy Dougherty wrote: On Thu, 1 Sep 2005, Nattfodd wrote: today is the deadline for the google summer of code projects, and it's time anyway for a release of GMC. GMC is a generational garbage collector for parrot that allows copying of objects and thus copying GC schemes. Thanks for submitting this. I also appreciated the extensive comments in the source (even if I didn't actually read most of them :-). svn co https://svn.perl.org/parrot/branches/gmc First, I needed the following simple patch to MANIFEST --- gmc/MANIFESTThu Sep 1 09:12:48 2005 +++ parrot-andy/MANIFESTThu Sep 1 10:19:20 2005 @@ -1639,6 +1639,7 @@ src/exec_start.c [] src/exit.c[] src/extend.c [] +src/gc_gmc.c [] src/gc_gms.c [] src/gc_ims.c [] src/generic_register.c[] After that, with Sparc/Solaris 8, with Sun's CC, I got a core dump even on a simple ./miniparrot -h If only miniparrot is called without arguments, the GC is never called, which narrows much the place to look for the bug... I rebuilt with debugging, and it again core dumped (although somewhere else). Here's the backtrace: (dbx) run -h Running: miniparrot -h (process id 21433) [EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in gc_gmc_copy_gen at line 879 in file gc_gmc.c 879 PMC_body(Gmc_PMC_hdr_get_PMC(ptr)) = Gmc_PMC_hdr_get_BODY(ptr); (dbx) where current thread: [EMAIL PROTECTED] =[1] gc_gmc_copy_gen(from = 0x32dbe8, dest = 0x4d31f8), line 879 in gc_gmc.c [2] gc_gmc_more_bodies(interpreter = 0x2b6ce8, pool = 0x31d860), line 933 in gc_gmc.c [3] gc_gmc_new_body(interpreter = 0x2b6ce8, pool = 0x31d860, size = 40U, aggreg = 4), line 705 in gc_gmc.c [4] gc_gmc_get_free_object_of_size(interpreter = 0x2b6ce8, pool = 0x31d860, size = 40U, aggreg = 4), line 741 in gc_gmc.c [5] gc_gmc_get_free_typed_object(interpreter = 0x2b6ce8, pool = 0x31d860, base_type = 62), line 796 in gc_gmc.c [6] new_pmc_alloc_header(interpreter = 0x2b6ce8, flags = 132096U, is_typed = 1, base_type = 62), line 270 in headers.c [7] new_pmc_typed_header(interpreter = 0x2b6ce8, flags = 132096U, base_type = 62), line 343 in headers.c [8] get_new_pmc_header(interpreter = 0x2b6ce8, base_type = 62, flags = 132096U), line 231 in pmc.c [9] constant_pmc_new(interpreter = 0x2b6ce8, base_type = 62), line 310 in pmc.c [10] mmd_create_builtin_multi_meth_2(interpreter = 0x2b6ce8, func_nr = 5, type = 33, right = -100, func_ptr = 0x1edce0 = Parrot_Complex_i_multiply_int()), line 2116 in mmd.c [11] mmd_create_builtin_multi_meth(interpreter = 0x2b6ce8, type = 33, entry = 0xffbef444), line 2139 in mmd.c [12] Parrot_mmd_register_table(interpreter = 0x2b6ce8, type = 33, mmd_table = 0xffbef2e4, n = 35), line 2182 in mmd.c [13] Parrot_Complex_class_init(interp = 0x2b6ce8, entry = 33, pass = 1), line 1390 in complex.c [14] Parrot_initialize_core_pmcs(interp = 0x2b6ce8), line 126 in core_pmcs.c [15] init_world(interpreter = 0x2b6ce8), line 85 in global_setup.c [16] Parrot_init(interpreter = 0x2b6ce8), line 84 in embed.c [17] make_interpreter(parent = (nil), flags = PARROT_NO_FLAGS), line 165 in inter_create.c [18] Parrot_new(parent = (nil)), line 47 in embed.c [19] main(argc = 2, argv = 0xffbefa8c), line 452 in main.c I #defined GMC_DEBUG and BIG_DUMP, and the last entries may be relevant: Copying gen (32e730,32f760) to gen (4d3d40,4d4d70) copy_gen: ptr 4c0904, old_body 32f554, new_body 4d4b64, struct_val: deadbeef copy_gen: ptr 47e078, old_body 32f57c, new_body 4d4b8c, struct_val: deadbeef copy_gen: ptr 46f7bc, old_body 32f5a4, new_body 4d4bb4, struct_val: deadbeef copy_gen: ptr 4683d8, old_body 32f5cc, new_body 4d4bdc, struct_val: deadbeef copy_gen: ptr 46845c, old_body 32f5f4, new_body 4d4c04, struct_val: deadbeef copy_gen: ptr 4684d4, old_body 32f61c, new_body 4d4c2c, struct_val: deadbeef copy_gen: ptr 3555a4, old_body 32f644, new_body 4d4c54, struct_val: deadbeef copy_gen: ptr 3555b0, old_body 32f66c, new_body 4d4c7c, struct_val: deadbeef copy_gen: ptr 355820, old_body 32f694, new_body 4d4ca4, struct_val: deadbeef Overall, I wonder if it's an alignment issue, since SPARC tends to be much more sensitve to that than x86. I haven't looked deeply at the code at all, but do you do anything special to ensure that the blocks of memory you are moving around maintain their aligment? Actually, no, I don't ensure it in any way... I don't know exactly what alignment constraints are, but here, a whole memory zone is allocated (in gc_gmc_gen_init() called from gc_gmc_more_bodies()). Then all the content of the old memory zone is memcpyed to the content of the new one in a single instruction (src/gc_gmc.c:871). Both old and new have
for $arrayref {...}
Hi,
my $arrayref = a b c;
for @$arrayref {...};# loop body executed three times, of course
for ($arrayref,) {...}; # loop body executed only one time
for ($arrayref) {...}; # loop body executed one or three times?
for $arrayref {...}; # loop body executed one or three times?
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: GMC release
On Thu, 1 Sep 2005, Nattfodd wrote:
Andy Dougherty wrote:
On Thu, 1 Sep 2005, Nattfodd wrote:
today is the deadline for the google summer of code projects, and it's
time
anyway for a release of GMC.
GMC is a generational garbage collector for parrot that allows copying of
objects and thus copying GC schemes.
Thanks for submitting this. I also appreciated the extensive comments in
the source (even if I didn't actually read most of them :-).
svn co https://svn.perl.org/parrot/branches/gmc
First, I needed the following simple patch to MANIFEST
--- gmc/MANIFESTThu Sep 1 09:12:48 2005
+++ parrot-andy/MANIFESTThu Sep 1 10:19:20 2005
@@ -1639,6 +1639,7 @@
src/exec_start.c []
src/exit.c[]
src/extend.c []
+src/gc_gmc.c []
src/gc_gms.c []
src/gc_ims.c []
src/generic_register.c[]
After that, with Sparc/Solaris 8, with Sun's CC, I got a core dump
even on a simple
./miniparrot -h
If only miniparrot is called without arguments, the GC is never called, which
narrows much the place to look for the bug...
I get the same crash without arguments, i.e., with a plain ./miniparrot.
Overall, I wonder if it's an alignment issue, since SPARC tends to be
much more sensitve to that than x86. I haven't looked deeply at the
code at all, but do you do anything special to ensure that the blocks
of memory you are moving around maintain their aligment?
Actually, no, I don't ensure it in any way... I don't know exactly what
alignment constraints are, but here, a whole memory zone is allocated (in
gc_gmc_gen_init() called from gc_gmc_more_bodies()). Then all the content of
the old memory zone is memcpyed to the content of the new one in a single
instruction (src/gc_gmc.c:871). Both old and new have exactly the same size.
So I imagine that if the start of the two zones are aligned in the same way
(does the fact that both are obtained from malloc guaranty that ?), then so
does every object in it...
On SPARC, doubles should be aligned on 8-byte boundaries. The compiler
normally handles this correctly and automatically (e.g. by adding padding
within structures as necessary, etc.) but if you're playing memory games
and casting everything to (char *) and manipulating addresses, then the
compiler obeys your commands and does what you request.
If indeed you're just copying one contiguous block from one malloc()-ed
spot to another, and the size is obtained from sizeof(), then you should
be fine. Malloc() is supposed to return memory suitably aligned for any
use.
But I begin to have serious doubts about objects being correctly aligned in
the first place. I'll try to see if I can make sure of alignment tonight...
On the other hand, I think compaction can break alignment, as bodies can have
variable size (even if it's not yet the case here).
However, the output you give seems to indicate that this is not corruption, as
pointers all seem to be valid (I had a lot of errors here earlier, but it was
always with either ptr or hdr-pmc being set to NULL).
I initially suspected alignment because with a optimized compile, I get
signal BUS (invalid address alignment) in gc_gmc_more_bodies at
0x7c278
I added a GMC_NO_GC_RUN symbol that you can define if you want to disable it
completely (to be sure that compaction is not responsible).
Defining that (on an optimized compile) changes the specific type of
crash:
signal SEGV (no mapping at the fault address) in gc_gmc_more_bodies at
0x7c258
One last thought about alignment: In macros such as the following one
in include/parrot/smallobject.h
#define Gmc_PMC_hdr_get_BODY(pmc_hdr)
((PMC_BODY*)((char*)(pmc_hdr) + sizeof(Gc_gmc_hdr)))
you have to be very careful about alignment and padding issues. That
is, if you have a struct p { int a, double b }, you can't assume that
'b' is located at p + sizeof(a). There might be padding. Instead,
use the offsetof() macro.
--
Andy Dougherty [EMAIL PROTECTED]
Re: for $arrayref {...}
Ingo Blechschmidt skribis 2005-09-01 20:29 (+0200):
for ($arrayref,) {...}; # loop body executed only one time
Yes: scalar in list context.
for ($arrayref) {...}; # loop body executed one or three times?
Same thing: scalar in list context. So once.
for $arrayref {...}; # loop body executed one or three times?
Same thing: scalar in list context. So once.
Scalars only automatically dereference in *specific* contexts. An
arrayref not used in Array context is still an arrayref, a hashref not
used in Hash context is still a hashref.
Pay attention to list context not being Array context. It does not
dereference anything.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
[perl #37049] [PATCH] Use ExtUtils::Commands more consistently
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #37049]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37049
Hi,
ExtUtils::Command provides Unix commands on several platforms.
So it make sense to use ExtUtils::Command per default and not only for
Win32.
The attached makes use of 'rm_f', 'rm_rf', 'cp' and 'touch' from
ExtUtils::Command.
Could some kind souls test the patch on some platforms before I commit it?
CU, Bernhard
Index: config/init/data.pl
===
--- config/init/data.pl (Revision 9118)
+++ config/init/data.pl (Arbeitskopie)
@@ -117,8 +117,8 @@
perl = $^X,
test_prog = 'parrot',
-rm_f = 'rm -f',
-rm_rf = 'rm -rf',
+rm_f = '$(PERL) -MExtUtils::Command -e rm_f',
+rm_rf = '$(PERL) -MExtUtils::Command -e rm_rf',
ar= $Config{ar},
ar_flags = 'cr',
ar_out= '', # for Win32
@@ -135,7 +135,7 @@
platform_asm = 0, # if platform has a .s file that needs to be assembled
as= 'as',# assembler
-cp= 'cp',
+cp= '$(PERL) -MExtUtils::Command -e cp',
lns = $Config{lns},# soft link
# On all platform slash == slash_exec, except with MinGW
# slash_exec is needed by pathname of executable in test or makefile
Index: config/init/hints/mswin32.pl
===
--- config/init/hints/mswin32.pl (Revision 9118)
+++ config/init/hints/mswin32.pl (Arbeitskopie)
@@ -18,8 +18,6 @@
my $is_bcc = grep { $cc eq $_ } ( qw(bcc32 bcc32.exe) );
Configure::Data-set(
- rm_f = '$(PERL) -MExtUtils::Command -e rm_f',
- rm_rf = '$(PERL) -MExtUtils::Command -e rm_rf',
PQ= '',
make_c= '$(PERL) -e chdir shift @ARGV; system \'$(MAKE)\', @ARGV; exit $$? 8;',
ncilib_link_extra = '-def:src/libnci_test.def',
@@ -52,7 +50,6 @@
ld_out = '-out:',
ldflags= '-nologo -nodefaultlib',
blib_lib_libparrot_a = 'blib/lib/libparrot_s$(A)',
- cp = 'copy',
ar_flags = '',
ar_out = '-out:',
slash = '\\',
@@ -100,7 +97,6 @@
ld_out = '-out:',
ldflags= '-nologo -nodefaultlib',
blib_lib_libparrot_a = 'blib/lib/libparrot_s$(A)',
- cp = 'copy',
ar = 'xilib',
ar_flags = '',
ar_out = '-out:',
@@ -143,7 +139,6 @@
link = ${cc},
linkflags = '',
- cp = 'copy',
ar = 'tlib',
ar_flags = '',
ar_out = '',
@@ -163,7 +158,6 @@
'ar' = 'ar',
'cc' = 'gcc',
'ccflags' = '-DWIN32 ',
-'cp' = '$(PERL) -MExtUtils::Command -e cp',
'ld' = 'g++',
'ld_load_flags' = '-shared ',
'ld_share_flags' = '-shared ',
@@ -185,7 +179,6 @@
} elsif ($make =~ /dmake/i) {
# mingw Perl
Configure::Data-set(
-'cp' = '$(PERL) -MExtUtils::Command -e cp',
'ld_load_flags' = '-shared ',
'ld_share_flags' = '-shared ',
'make' = 'mingw32-make',
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in (Revision 9118)
+++ config/gen/makefiles/root.in (Arbeitskopie)
@@ -84,7 +84,7 @@
AR_CR = ${ar} ${ar_flags}
RANLIB = ${ranlib}
PERL = ${perl}
-TOUCH = $(PERL) -e ${PQ}open(A,qq{$$_}) or die foreach @ARGV${PQ}
+TOUCH = $(PERL) -MExtUtils::Command -e touch
YACC = ${yacc}
LEX= ${lex}
# do not die when dir already exits
Re: no 6;
On 9/1/05, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: I just commited into bleadperl a patch that implements this : $ ./perl -e 'no 5' Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. That is, the exact opposite of the current use VERSION syntax. Does this mean that we have to implement perl4 compatability? perl5 -e 'no 5; print [EMAIL PROTECTED]'
no 6;
I just commited into bleadperl a patch that implements this : $ ./perl -e 'no 5' Perls since v5.0.0 too modern--this is v5.9.3, stopped at -e line 1. BEGIN failed--compilation aborted at -e line 1. That is, the exact opposite of the current use VERSION syntax. One of the uses I had in mind for it is to put no 6 at the top of modules or programs that are too tightly bound to Perl 5 that there wouldn't be beneficial to port them to Perl 6. B::* or Safe come to mind. Of course, that would mean that Perl 6 should also recognize and handle the no 6 idiom. That's why I'm cc:ing p6l. Comments ? The patch can be found at http://public.activestate.com/cgi-bin/perlbrowse?patch=25344
Re: Call for B0rked
On Wed, Aug 31, 2005 at 04:04:45PM -0700, chromatic wrote: Hi all, In a recent discussion with Chip and Leo, the idea came up to ask for a list of very specific TODO items -- specifically things that should work but don't. Not very specific, but: whatever Ponie needs most. I'm sure Nicholas can come up with something more specific! Tim.
Re: for $arrayref {...}
On 9/1/05, Juerd [EMAIL PROTECTED] wrote:
Ingo Blechschmidt skribis 2005-09-01 20:29 (+0200):
for ($arrayref,) {...}; # loop body executed only one time
Yes: scalar in list context.
for ($arrayref) {...}; # loop body executed one or three times?
Same thing: scalar in list context. So once.
for $arrayref {...}; # loop body executed one or three times?
Same thing: scalar in list context. So once.
Scalars only automatically dereference in *specific* contexts. An
arrayref not used in Array context is still an arrayref, a hashref not
used in Hash context is still a hashref.
I would probably say that scalars never automatically dereference.
It's lists and hashes that automatically dereference/enreference.
That is, everything is a scalar, really, but if you have an @ or a %
on the front of your variable, that means that you flatten yourself
into specific kinds of contexts.
Luke
[RELEASE] WWW::Kontent 0.02: Release and revelations
= WWW::Kontent 0.02 I am happy to announce the release of WWW::Kontent 0.02: File: $CPAN/authors/id/B/BR/BRENTDAX/WWW-Kontent-0.02.tar.gz Size: 62121 bytes MD5: 513018f0f2f8a0533a79d0b642323f2b http://search.cpan.org/~brentdax/WWW-Kontent-0.02/ Please note that it may take some time for the distribution to reach your local CPAN mirror. Kontent is a flexible web content management system written in Perl 6 and executable with Pugs. I am writing it with the help of The Perl Foundation and Google's Summer of Code program. This release is an early alpha, largely feature-complete but requiring a good deal of work, including security work. However, it is suitable to be tested out and run on localhost. In its initial configuration, Kontent looks quite similar to a wiki, with the ability to create and edit pages through a web interface and view a revision history. Examination of the code, however, will reveal a fairly sophisticated architecture capable of giving each page unique behavior and rendering the same content in multiple formats. A command-line tool is provided which can manipulate pages at a low enough level to change a page's class. Although the distribution is on the CPAN, it cannot be automatically installed by CPAN.pm or CPANPLUS, largely because I haven't decided what should be installed where. I recommend you simply download the tarball and extract it in your home directory. The INSTALL file included in the distribution will explain how to get it running. Note that you will need both a copy of Pugs configured with Perl 5 interop, and a copy of Parrot to execute Perl 6 regular expressions. You will also need a SQL database engine and the Perl 5 DBI drivers to access it. = Perl 6 Notes Part of the purpose of this project was to test Perl 6, and I'm happy to report that it passed with flying colors. Perl 6 feels like a much-enhanced Perl 5, with all the wrinkles removed and very few new ones added. It seems to be a very solid design, and is a joy to program in. A few specific points: * gather/take is one of the hidden wins of Perl 6. If you've ever written a function that builds up data throughout its entire body (for example, a bunch of [X|HT]ML), you will *adore* gather/take. It turns what used to require declaring a variable and repeatedly pushing (or concatenating) into something akin to good ol' fashoned print statements. * Object programming is a dream. The new object system fits together very well; I never felt that I wanted to do something Perl 6 wouldn't let me do (although there are some things I want to do that Pugs doesn't implement yet). Although roles aren't really available to me yet, I can already see some very useful places to to use them in later versions of this system. Two comments on the object system, however: * In one class, I wanted to initialize an attribute with data that wouldn't be available until its subclass had its turn BUILDing; I ended up having to write a private method to initialize the attribute and then arrange to call it before using the attribute anywhere in the class, which wasn't exactly optimal. There may be a place for some sort of POSTBUILD method which is called after the entire BUILD chain is finished. * Prior to writing Kontent, I saw submethods as something of a hack, and actual use of Perl 6 hasn't changed my opinion about them. I never used or wanted to use a submethod except to handle BUILD, DESTROY, and the like; it might be better to replace submethods with some sort of cascade method construct which implicitly calls all the way up the inheritence tree. * Junctions are useful just the way they are. I only used junctions a few times, but where I used them they saved a lot of code duplication. I sometimes, but certainly not always, found myself using them simply for their autothreading side effect and ignoring the boolean meaning of the junction. I don't think junctions were ever critical to the system's logic, but they helped reduce duplication and made things quite a bit clearer. * The new pattern-matching engine is a win for small regexes, too. Due to its half-implemented state, I was not able to write a substantial grammar (although I definitely have a place I can use one). However, I did use the Perl 6 pattern engine wherever I could, and even on short regexes it resulted in clearer, more concise code than the Perl 5 equivalent. I could not have done this project without the support of Google and the Perl Foundation, especially my mentor at TPF, Ovid. Nor would this project be possible wtihout the efforts of the Perl 6 design team and the Pugs implementation team. Thanks to everyone involved. Share and enjoy, -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Optimizer Documentation
As part of my Summer of Code project, I wanted to improve the
documentation of the optimizer. This was especially relevant for me
since I had to learn it my self by trial and error and asking
questions. So here is my first draft of the optimizer documentation.
I tried to include the most important information for someone new to
the project or this area.
I would appreciate some Parroters to take a look, whether you are
familiar with this area of Parrot or not, since it is most useful to
newcomers. Which parts are/are not interesting/relevant? Does it
raise any pertinent questions that are not answered? Anything
missing? Anything just plain wrong?
Also, this is in plain text format. What is the standard way to
convert a document to POD format?
Thanks!
-Curtis
Begin Optimizer Documentation-
OPTIMIZER
-ABSTRACT
This document describes how the IMCC optimizer works.
-OVERVIEW
The objective of the IMCC optimizer is to take a PASM function as
input and apply code-improving transformations to it to be more
efficient, i.e. improving execution time and reducing code size. It
must do this while preserving the same code behavior.
-DATA STRUCTURES
The optimizer uses a number of data structures to build a model of the
code to be optimized.
IMC_Unit
The IMC_Unit structure contains all the information known about a
function.It is passed in to each optimizer method.
Instruction
Each instruction line has an Instruction structure. Pointers to the
first and last Instruction are stored in IMC_Unit. Instructions are
stored as a linked list. To iterate through all Instructions, use:
Instruction *ins;
for (ins = unit-instructions; ins; ins = ins-next) {
...
}
Basic_block
Basic blocks are the most important structure for optimization. A
basic block identifies a block of instructions that will all execute
in sequence without jumps into or out of that block. All labels will
appear at the beginning of a block, and all conditional or
unconditional jumps will appear at the end. Basic_block structures
are stored as an array of pointers, each with an index that denotes
their position in the array. Block 0 is implicitly the top block. To
iterate through all Basic_blocks, use:
int i;
for (i = 0; i unit-n_basic_blocks; i++) {
...
}
Edge
Edges denote the flow of control between Basic_blocks. Edges and
Basic_blocks together make up the basic CFG. Each Basic_block has
*pred_list and *succ_list pointer to the first predecessor edge and
successor edge, respectively. Each edge has a *to and *from pointer
to the Basic_blocks it joins. To iterate through all predecessor
Edges, use:
Edge *pred;
for (pred = to-pred_list; pred; pred=pred-pred_next) {
...
}
Loop_info
Loop_info structures denote the presence of loops in the instructions.
They are found by identifying backedges, where control passes from a
tail block to the head of the loop. Loop_info stores the header,
preheader, exit blocks, and depth of the loop.
Set
Set is a useful structure for defining sets of integers, which map to
indexes of structures. This is used most often to create sets of
Basic_blocks. Dominators, dominance frontiers, and loops use Set. A
Set must be a defined size, and cannot grow or shrink. Most standard
set operations are implemented: add, contains, copy, equal, union, and
intersection.
-OPTIMIZATIONS
Optimizations are organized into an optimization loop within
imc_reg_alloc() in reg_alloc.c. The ordering is based on the amount
of CFG information needed by each group of optimizations:
pre_optimize(), cfg_optimize(), and optimize(). Each optimization
function (group and individual) returns an int, with TRUE denoting
that an optimization has been performed and a change to the code has
been made. The power of the optimizer is that performing one
optimization may often allow another to be performed as well. Once
all optimizations have been run without changes, the optimizer is
finished.
The optimizer loop works as follows:
1. Run all pre_optimize() optimizations until none make a change.
2. Build basic block info.
3. Run all cfg_optimize() optimizations. If one makes a change, go to step 1.
4. Build all other CFG info (dominators, loops, life analysis).
5. Run all optimize() optimizations. If one makes a change, go to step 1.
Two cfg_optimize() or optimize() optimizations cannot be run in a row.
This is because most of these make the CFG information invalid when a
change is performed, and the CFG must be rebuilt.
Pre optimizer
Optimizations using only Instruction info, no CFG constructed.
strength_reduce() - converts an expensive instruction to a simpler one
if_branch() - Convert if/branch/label constructs to a simpler form
CFG optimizer
Optimizations using Basic_block info. These functions invalidate the
CFG when a change is made.
branch_branch() - Replaces a branch directly to another branch with a
single branch to the end of the chain
unused_label() - Removes unused
Re: Optimizer Documentation
Also, this is in plain text format. What is the standard way to
convert a document to POD format?
By rewriting it. Only took me a few minutes:
=head1 NANE
optimizer.pod - About the IMCC optimizer
=head1 ABSTRACT
This document describes how the IMCC optimizer works.
=head1 DESCRIPTION
The objective of the IMCC optimizer is to take a PASM function as
input and apply code-improving transformations to it to be more
efficient, i.e. improving execution time and reducing code size. It
must do this while preserving the same code behavior.
=head2 Data Structures
The optimizer uses a number of data structures to build a model of the
code to be optimized.
=over 4
=item IMC_Unit
The IMC_Unit structure contains all the information known about a
function.It is passed in to each optimizer method.
=item Instruction
Each instruction line has an Instruction structure. Pointers to the
first and last Instruction are stored in IMC_Unit. Instructions are
stored as a linked list. To iterate through all Instructions, use:
Instruction *ins;
for (ins = unit-instructions; ins; ins = ins-next) {
...
}
=item Basic_block
Basic blocks are the most important structure for optimization. A
basic block identifies a block of instructions that will all execute
in sequence without jumps into or out of that block. All labels will
appear at the beginning of a block, and all conditional or
unconditional jumps will appear at the end. Basic_block structures
are stored as an array of pointers, each with an index that denotes
their position in the array. Block 0 is implicitly the top block. To
iterate through all Basic_blocks, use:
int i;
for (i = 0; i unit-n_basic_blocks; i++) {
...
}
=item Edge
Edges denote the flow of control between Basic_blocks. Edges and
Basic_blocks together make up the basic CFG. Each Basic_block has
*pred_list and *succ_list pointer to the first predecessor edge and
successor edge, respectively. Each edge has a *to and *from pointer
to the Basic_blocks it joins. To iterate through all predecessor
Edges, use:
Edge *pred;
for (pred = to-pred_list; pred; pred=pred-pred_next) {
...
}
=item Loop_info
Loop_info structures denote the presence of loops in the instructions.
They are found by identifying backedges, where control passes from a
tail block to the head of the loop. Loop_info stores the header,
preheader, exit blocks, and depth of the loop.
=item Set
Set is a useful structure for defining sets of integers, which map to
indexes of structures. This is used most often to create sets of
Basic_blocks. Dominators, dominance frontiers, and loops use Set. A
Set must be a defined size, and cannot grow or shrink. Most standard
set operations are implemented: add, contains, copy, equal, union, and
intersection.
=back 4
=head2 Optimizations
Optimizations are organized into an optimization loop within
imc_reg_alloc() in reg_alloc.c. The ordering is based on the amount
of CFG information needed by each group of optimizations:
pre_optimize(), cfg_optimize(), and optimize(). Each optimization
function (group and individual) returns an int, with TRUE denoting
that an optimization has been performed and a change to the code has
been made. The power of the optimizer is that performing one
optimization may often allow another to be performed as well. Once
all optimizations have been run without changes, the optimizer is
finished.
The optimizer loop works as follows:
=over 4
=item 1. Run all pre_optimize() optimizations until none make a change.
=item 2. Build basic block info.
=item 3. Run all cfg_optimize() optimizations. If one makes a
change, go to step 1.
=item 4. Build all other CFG info (dominators, loops, life analysis).
=item 5. Run all optimize() optimizations. If one makes a change, go
to step 1.
=back 4
Two cfg_optimize() or optimize() optimizations cannot be run in a row.
This is because most of these make the CFG information invalid when a
change is performed, and the CFG must be rebuilt.
=head3 Pre optimizer
Optimizations using only Instruction info, no CFG constructed.
=over 4
=item strength_reduce()
converts an expensive instruction to a simpler one
=item if_branch()
Convert if/branch/label constructs to a simpler form
=back 4
=head3 CFG optimizer
Optimizations using Basic_block info. These functions invalidate the
CFG when a change is made.
=over 4
=item branch_branch()
Replaces a branch directly to another branch with a
single branch to the end of the chain
=item unused_label()
Removes unused labels
=item dead_code_remove()
Removes unreachable code
=back 4
=head3 Optimizer
=over 4
=item constant_propagation()
conservative constant propagation, i.e.
replaces 1 + 2 with 3
=item clone_remove()
remove a clone, TURNED OFF
=item used_once()
removes an instruction when the register written is only
used once (only appears in that instruction)
=item loop_optimization()
Re: GMC release
Andy Dougherty wrote:
Overall, I wonder if it's an alignment issue, since SPARC tends to be
much more sensitve to that than x86. I haven't looked deeply at the
code at all, but do you do anything special to ensure that the blocks
of memory you are moving around maintain their aligment?
Actually, no, I don't ensure it in any way... I don't know exactly what
alignment constraints are, but here, a whole memory zone is allocated (in
gc_gmc_gen_init() called from gc_gmc_more_bodies()). Then all the content of
the old memory zone is memcpyed to the content of the new one in a single
instruction (src/gc_gmc.c:871). Both old and new have exactly the same size.
So I imagine that if the start of the two zones are aligned in the same way
(does the fact that both are obtained from malloc guaranty that ?), then so
does every object in it...
On SPARC, doubles should be aligned on 8-byte boundaries. The compiler
normally handles this correctly and automatically (e.g. by adding padding
within structures as necessary, etc.) but if you're playing memory games
and casting everything to (char *) and manipulating addresses, then the
compiler obeys your commands and does what you request.
If indeed you're just copying one contiguous block from one malloc()-ed
spot to another, and the size is obtained from sizeof(), then you should
be fine. Malloc() is supposed to return memory suitably aligned for any
use.
But I begin to have serious doubts about objects being correctly aligned in
the first place. I'll try to see if I can make sure of alignment tonight...
On the other hand, I think compaction can break alignment, as bodies can have
variable size (even if it's not yet the case here).
However, the output you give seems to indicate that this is not corruption, as
pointers all seem to be valid (I had a lot of errors here earlier, but it was
always with either ptr or hdr-pmc being set to NULL).
I initially suspected alignment because with a optimized compile, I get
signal BUS (invalid address alignment) in gc_gmc_more_bodies at
0x7c278
I added a GMC_NO_GC_RUN symbol that you can define if you want to disable it
completely (to be sure that compaction is not responsible).
I added in the last revision some very basic memory alignment control
(basically, headers and bodies are rounded up to the nearest multiple of
GMC_ALIGN, which has a value of 8 now but can be changed at will. As
headers were previously using 12 bytes, this may solve your problem (I
hope so...).
There are assert for alignment pretty much everywhere in object
allocation, so that should help too.
However, it seems to strongly disagree with the compaction functions,
and causes t/library/md5_6.pir, for instance, to segfault. I spent some
hours trying to find the bug without success, but it should be fine as
long as you define GMC_GC_RUN (at least to see if it can run correctly
miniparrot).
Defining that (on an optimized compile) changes the specific type of
crash:
signal SEGV (no mapping at the fault address) in gc_gmc_more_bodies at
0x7c258
One last thought about alignment: In macros such as the following one
in include/parrot/smallobject.h
#define Gmc_PMC_hdr_get_BODY(pmc_hdr)
((PMC_BODY*)((char*)(pmc_hdr) + sizeof(Gc_gmc_hdr)))
you have to be very careful about alignment and padding issues. That
is, if you have a struct p { int a, double b }, you can't assume that
'b' is located at p + sizeof(a). There might be padding. Instead,
use the offsetof() macro.
I would have liked to use offsetof but I don't think it will be
possible, because we are not using a structure. This is because we want
a field to have the size we decided without using a pointer (which would
be useless as body is always just after the header). If you see some way
to declare a struct or an union with a variable sized field, I would be
really grateful...
We just have to pray here that Gmc_align(sizeof(Gc_gmc_hdr)) includes
all the padding (and if needed increase GMC_ALIGN).
Regards,
Alexandre
Re: GMC release
On 9/2/05, Nattfodd [EMAIL PROTECTED] wrote: ...but it should be fine as long as you define GMC_GC_RUN (at least to see if it can run correctly miniparrot)... err, it was GMC_NO_GC_RUN, of course. Now I'll really use some sleep :)
Re: GMC release
Much better on OS X now! parrot: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/pyclass.t1 256 61 16.67% 6 t/dynclass/pyfunc.t 1 256 41 25.00% 4 t/library/dumper.t 1 256261 3.85% 6 t/library/getopt_long.t 1 256 11 100.00% 1 t/library/md5.t 2 512 62 33.33% 5-6 t/library/streams.t12 307220 12 60.00% 9-20 t/native_pbc/integer.t 1 256 11 100.00% 1 t/native_pbc/number.t 1 256 11 100.00% 1 t/op/debuginfo.t1 256 81 12.50% 7 t/op/gc.t 12 307219 12 63.16% 1 3-4 9-12 15-19 t/op/interp.t 1 256111 9.09% 9 t/op/spawnw.t 1 256 71 14.29% 7 t/op/stacks.t 2 512562 3.57% 6 24 t/op/string.t 16 4096 156 16 10.26% 100 111 122-134 136 t/p6rules/anchors.t26 665626 26 100.00% 1-26 t/p6rules/backtrack.t 15 384015 15 100.00% 1-15 t/p6rules/builtins.t 41 1049641 41 100.00% 1-41 t/p6rules/capture.t38 972838 38 100.00% 1-38 t/p6rules/cclass.t 18 460818 18 100.00% 1-18 t/p6rules/escape.t 19 486419 19 100.00% 1-19 t/p6rules/subrules.t5 1280 55 100.00% 1-5 t/p6rules/ws.t 19 486419 19 100.00% 1-19 t/pmc/eval.t3 768143 21.43% 12-14 t/pmc/fixedstringarray.t1 256131 7.69% 13 t/pmc/freeze.t 23 588826 23 88.46% 1-4 6-16 18-19 21-26 t/pmc/hash.t2 512362 5.56% 9 28 t/pmc/io.t 3 768313 9.68% 3 23 31 t/pmc/objects.t 1 256621 1.61% 13 t/pmc/perlhash.t1 256371 2.70% 27 t/pmc/perlstring.t 10 256068 10 14.71% 49-58 t/pmc/string.t 10 256035 10 28.57% 17-26 t/pmc/sub.t 1 256511 1.96% 24 t/pmc/sys.t 1 256 11 100.00% 1 t/pmc/timer.t 2 512 82 25.00% 6-7 t/src/hash.t1 256101 10.00% 6 t/src/sprintf.t 1 256 31 33.33% 3 3 tests and 70 subtests skipped. Failed 36/163 test scripts, 77.91% okay. 294/2719 subtests failed, 89.19% okay. partcl, however, was most displeased: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/cmd_append.t 8 2048 88 100.00% 1-8 t/cmd_array.t 13 332813 13 100.00% 1-13 t/cmd_break.t2 512 22 100.00% 1-2 t/cmd_catch.t8 2048 98 88.89% 2-9 t/cmd_concat.t 6 1536 66 100.00% 1-6 t/cmd_continue.t 2 512 22 100.00% 1-2 t/cmd_error.t1 256 11 100.00% 1 t/cmd_eval.t 1 256 11 100.00% 1 t/cmd_exit.t 1 256 11 100.00% 1 t/cmd_expr.t40 1024043 40 93.02% 1-40 t/cmd_for.t 1 256 11 100.00% 1 t/cmd_foreach.t 9 2304 99 100.00% 1-9 t/cmd_format.t 1 256 11 100.00% 1 t/cmd_global.t 3 768 33 100.00% 1-3 t/cmd_if.t 8 2048 98 88.89% 1-7 9 t/cmd_incr.t 5 1280 55 100.00% 1-5 t/cmd_inline.t 3 768 33 100.00% 1-3 t/cmd_join.t 7 1792 77 100.00% 1-7 t/cmd_lappend.t 4 1024 44 100.00% 1-4 t/cmd_lindex.t 3 768 33 100.00% 1-3 t/cmd_linsert.t 4 1024 54 80.00% 1 3-5 t/cmd_list.t15 384015 15 100.00% 1-15 t/cmd_llength.t 5 1280 55 100.00% 1-5 t/cmd_lrepeat.t 4 1024 44 100.00% 1-4 t/cmd_proc.t 3 768 43 75.00% 1-3 t/cmd_puts.t 2 512 22 100.00% 1-2 t/cmd_rename.t 2 512 22 100.00% 1-2 t/cmd_return.t 1 256 11 100.00% 1 t/cmd_set.t 4 1024 44 100.00% 1-4 t/cmd_source.t 1 256 21 50.00% 2 t/cmd_string.t 32 819237 32 86.49% 1-14 17-32 36-37 t/cmd_unset.t2 512 32 66.67% 1 3 t/cmd_while.t1 256 11 100.00% 1 t/tcl_backslash.t 14 358416 14 87.50% 1-11 13 15-16 t/tcl_command_subst.t9 2304109 90.00% 1-9 t/tcl_misc.t11 281612 11 91.67% 1-11 t/tcl_pir_compiler.t 2 512 32 66.67% 1-2 t/tcl_var_subst.t8 2048 88 100.00% 1-8 (1 subtest UNEXPECTEDLY SUCCEEDED). Failed 38/39 test scripts, 2.56% okay. 246/266 subtests failed, 7.52% okay.
