Re: Dumb questions about array slicing...
Mark J. Reed wrote: I didn't see anything in the issue tracker, nor did any tests fail, There are failing (but TODOed) tests somewhere below t/spec/S02-builtin_data_types/ but am I correct in assuming that array slicing is simply not implemented yet in Rakudo? Correct. $ ./perl6 -e 'my @a = (1,2,3); say @a[0 .. 1];' 3 it takes the range in item context, which is the size of the range, and uses that as an index. The PIR is pretty straightforward: $I22 = infix:..($P20, $P21) ... set $P24, $P23[$I22] Is that supposed to work? Is the PIR subscript operation supposed to be smart enough to do the right thing with a subscript that happens to be a Range? Or does that onus fall on the Perl6 compiler to generate PIR that handles it more manually? I don't know that, but I know that Perl 6 needs some extra smartness for the subscript operation anyway, because it supports funky stuff with the Whatever star (@array[*-2] etc). Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Dumb questions about array slicing...
Good point on the other special subscript values. The PIR as currently being generated couldn't work anyway, since the subscript is being put in an Int register instead of a PMC one. On 9/30/08, Moritz Lenz [EMAIL PROTECTED] wrote: Mark J. Reed wrote: I didn't see anything in the issue tracker, nor did any tests fail, There are failing (but TODOed) tests somewhere below t/spec/S02-builtin_data_types/ but am I correct in assuming that array slicing is simply not implemented yet in Rakudo? Correct. $ ./perl6 -e 'my @a = (1,2,3); say @a[0 .. 1];' 3 it takes the range in item context, which is the size of the range, and uses that as an index. The PIR is pretty straightforward: $I22 = infix:..($P20, $P21) ... set $P24, $P23[$I22] Is that supposed to work? Is the PIR subscript operation supposed to be smart enough to do the right thing with a subscript that happens to be a Range? Or does that onus fall on the Perl6 compiler to generate PIR that handles it more manually? I don't know that, but I know that Perl 6 needs some extra smartness for the subscript operation anyway, because it supports funky stuff with the Whatever star (@array[*-2] etc). Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/ -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
[perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though. -- callgrind output
Attached is callgrind output from trying to compile rakudo with this patch. As you can see, the most-called functions by far are: /home/sweeks/src/parrot/compilers/imcc/sets.c:set_add /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominance_frontiers Profile data file 'callgrind.out.10513' (creator: callgrind-3.3.0) I1 cache: D1 cache: L2 cache: Timerange: Basic block 0 - 241100 Trigger: Program termination Profiled target: ../../parrot -o perl6.pbc perl6.pir (PID 10513, part 1) Events recorded: Ir Events shown: Ir Event sort order: Ir Thresholds: 99 Include dirs: User annotated: Auto-annotation: off Ir 25,725,945,395 PROGRAM TOTALS Ir file:function 13,455,028,108 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_add [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 11,209,537,812 /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominance_frontiers [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 135,234,114 /home/sweeks/src/parrot/compilers/imcc/imclexer.c:yylex [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 128,962,606 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_contains [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 88,825,729 /home/sweeks/src/parrot/compilers/imcc/imcparser.c:yyparse [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 70,349,560 /home/sweeks/src/parrot/compilers/imcc/instructions.c:instruction_reads [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 65,814,257 /home/sweeks/src/parrot/compilers/imcc/cfg.c:compute_dominators [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 56,483,518 /home/sweeks/src/parrot/compilers/imcc/instructions.c:instruction_writes [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 48,013,979 ???:_int_malloc [/lib64/libc-2.8.so] 46,419,350 /home/sweeks/src/parrot/compilers/imcc/pbc.c:constant_folding [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 33,201,086 /home/sweeks/src/parrot/compilers/imcc/sets.c:set_intersec_inplace [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 29,624,696 /home/sweeks/src/parrot/compilers/imcc/symreg.c:hash_str [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 20,719,320 ???:calloc [/lib64/ld-2.8.so] 18,291,953 /home/sweeks/src/parrot/compilers/imcc/cfg.c:bb_check_set_addr [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 17,404,418 /home/sweeks/src/parrot/compilers/imcc/reg_alloc.c:compute_one_du_chain [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 13,809,278 /home/sweeks/src/parrot/compilers/imcc/imcc.l:yylex 12,337,246 /home/sweeks/src/parrot/src/ops/core_ops.c:hash_str [/home/sweeks/src/parrot/blib/lib/libparrot.so.0.7.1] 12,162,840 ???:memcpy [/lib64/ld-2.8.so] 11,450,969 ???:strcmp'2 [/lib64/ld-2.8.so]
[perl #59472] [TODO] Randomize hash seed
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #59472] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59472 In src/hash.c:816 there is a TODO comment: /* TODO randomize */ hash-seed = 3793; This needs to be investigated and probably implemented.
[perl #46667] [TODO] [C] Do we need properties in the default object system?
This check can be removed from default.pmc. Property values should not be returned by get_attr_str. Done in r31509
[perl #57690] [BUG] make headerizer breaks build
On Mar. Ago. 12 15:05:57 2008, Whiteknight wrote: This probably isn't headerizer's fault, it's more likely the fault of IMCC for being so damn complicated. We could change all the function definitions in the IMCC related files to use struct _IMC_Unit instead of IMC_Unit which would resolve the problem. Alternatively, we could rearrange the way the header files are ordered/created, and ensure all function prototypes are included after all data type definitions. Or we can declare the typedef for IMC_Unit in imc.h before the #include of the other imcc headers, with a forward declaration of _IMC_Unit. Done in r31517. Ticket let opened to hear possible problems.
[perl #46083] [TODO] Fix memory leak in src/pmc/parrotio.pmc:open()
Fixed in r31508
Re: [perl #59112] Failing test in t/examples/library.t
James (): Let's start with an elementary question: What does Configure.pl say for you at this step: auto::pcre - Does your platform support pcre auto::pcre - Does your platform support pcreyes, 7.7. // Carl
[perl #43851] [CAGE] All calls to stack_entry need to be NULL-checked
On Fr. 13. Jul. 2007, 16:21:54, rgrjr wrote: Are there any? The only ones I can find that that Splint might be complaining about are the derefs in rotate_entries, but the code explicitly checks that stack_height is large enough such that stack_entry will never return NULL. True? Looks like it. Furthermore, as rotate_entries() isn't used anywhere I propose to remove the function rotate_entries(). This will quiet the complaints from Splint for good. Any comments? -- /* [EMAIL PROTECTED] */
