Re: Rakudo test miscellanea
HaloO, On Thursday, 26. June 2008 18:46:25 Larry Wall wrote: > Neither "is" nor "does" is quite right here, because the mathematicians > have seen fit to confuse representation semantics with value semantics. :) Hmm, but the uppercase types should hide the representation type. IOW, there's only one Int but int8 to int64 or so. Same with Num and num32 to num128 and perhaps num8 and num16 in the OpenGL world. > I think what we want is something more like > > Int as Rat > Rat as Num > Num as Complex So, how does this auto-coercion interact with dispatch? And how do these in turn interact with generic function/type instanciation? I imagine a first round of dispatch then some well defined second attempt after "standard" coercions. Note that there might be coercion conflicts if several paths of conversion are available. Then we need some concept of "coercion distance" that favors more direct paths over longer ones and less lossy ones over lossier ones. The tricky part then becomes the interaction of coercion with dispatch. E.g. if there is an Int arg and two dispatch targets for Rat and Num and two conversions Int as Rat (lossless) and Int as Num (lossy?). OTOH, I regard Complex as a structural type like e.g. Vector or Matrix that is built on top of other numeric types. That is we have Complex[Int] as the Gaussian Integers and Complex[Rat] and Complex[Num] in the same coercive relations as the underlying Rat and Num. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #56330] [BUG] incorrectly quote context on parse failure
Closing ticket, thanks! Pm
[perl #56448] [BUG] tailcalls cause segfault when invoked from C
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #56448] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56448 > Parrot segfaults when C functions invoke PIR functions that perform tailcalls. Here's a demo test: Here's a demo test: .sub 'main' :main .local pmc array array = new 'ResizablePMCArray' push array, 4 push array, 5 push array, 3 push array, 2 push array, 5 push array, 1 $S0 = join ' ', array say $S0 ## sort using a non-tailcall function $P0 = get_global 'cmp_normal' $P1 = clone array $P1.sort($P0) $S0 = join ' ', $P1 say $S0 ## sort using a tailcall function $P0 = get_global 'cmp_tailcall' $P1 = clone array $P1.sort($P0) $S0 = join ' ', $P1 say $S0 .end .sub 'cmp_func' .param pmc a .param pmc b $I0 = cmp a, b .return ($I0) .end .sub 'cmp_normal' .param pmc a .param pmc b $P0 = 'cmp_func'(a, b) .return ($P0) .end .sub 'cmp_tailcall' .param pmc a .param pmc b .return 'cmp_func'(a, b) .end Here, we perform a sort using Parrot's built-in sort method for PMC arrays, using either 'cmp_normal' or 'cmp_tailcall' as the comparison function. The only difference between the two functions is the use of a tailcall in the return statement. The output when the above is run is: $ ./parrot tc.pir 4 5 3 2 5 1 1 2 3 4 5 5 Segmentation fault This segmentation fault seems to occur anytime a PIR subroutine that performs a tailcall is called from C -- in particular, PIR methods marked with :vtable segfault whenever they return a value via a tailcall. Pm
[RFC] merge stack_common.c and stacks.c
After all the efforts to simplify Parrot's stack situation, it seems to me like src/stack_common.c and src/stacks.c can be merged. After a quick search, none of the functions from stack_common.c are used anywhere except in stacks.c. Some functions from the former are completely redundant. For instance, src/stack_common.c:register_new_stack is only used as a tail call in src/stacks.c:new_stack. There are a few other simplifications that I think can be made also. For instance, in calculating the size of a new Stack_Chunk_t, we use the convoluted equation "size = sizeof(Stack_Entry_t) + offsetof(Stack_Chunk_t, u.data)", which is much more easily written as "size = sizeof(Stack_Chunk_t)". I assume, based on this complexity, that the size of a stack chunk's payload was variable, but it appears now that there is only one kind of stack, and one size of payload. Merging these two files together, there are a lot of simplifications that could easily be made. We wouldn't want to oversimplify if it was our intention to add new stacks and new types of stacks in the future, but there is a lot we could do without limiting our future options. --Andrew Whitworth
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
On Sunday 29 June 2008 06:52:12 [EMAIL PROTECTED] wrote: > Modified: >trunk/languages/perl6/tools/test_summary.pl > > Log: > [rakudo]: > * Update test_summary.pl script to use -G, > record aborted test runs as failed tests. > Modified: trunk/languages/perl6/tools/test_summary.pl > === > --- trunk/languages/perl6/tools/test_summary.pl (original) > +++ trunk/languages/perl6/tools/test_summary.pl Sun Jun 29 06:52:09 2008 > @@ -58,7 +58,7 @@ > } > close($th); > printf "%s%s..%4d", $tfile, '.' x ($max - length($tfile)), $plan; > -my $cmd = "../../parrot perl6.pbc $tfile"; > +my $cmd = "../../parrot -G perl6.pbc $tfile"; > my @results = split "\n", `$cmd`; > my ($test, $pass, $fail, $todo, $skip) = (0,0,0,0,0); > my %skip; This change bugs me; are there other tickets for segfaults and crashes in Parrot affecting Rakduo besides RT #56448, or am I misunderstanding the purpose of the change? If the default behavior is to work around problems, I fear that we won't get the problems fixed. (See also "Why alternate runcores break far too frequently.) -- c
Should C and C work in C ?
Do C and C act like the C method, in that they work for C object and not just objects of type C? In other words,, should C< $x.grep(...) > work even if $x isn't normally a list type? Pm
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
chromatic wrote: > On Sunday 29 June 2008 06:52:12 [EMAIL PROTECTED] wrote: > >> Modified: >>trunk/languages/perl6/tools/test_summary.pl >> >> Log: >> [rakudo]: >> * Update test_summary.pl script to use -G, >> record aborted test runs as failed tests. >> Modified: trunk/languages/perl6/tools/test_summary.pl >> === >> --- trunk/languages/perl6/tools/test_summary.pl (original) >> +++ trunk/languages/perl6/tools/test_summary.pl Sun Jun 29 06:52:09 2008 >> @@ -58,7 +58,7 @@ >> } >> close($th); >> printf "%s%s..%4d", $tfile, '.' x ($max - length($tfile)), $plan; >> -my $cmd = "../../parrot perl6.pbc $tfile"; >> +my $cmd = "../../parrot -G perl6.pbc $tfile"; >> my @results = split "\n", `$cmd`; >> my ($test, $pass, $fail, $todo, $skip) = (0,0,0,0,0); >> my %skip; > > This change bugs me; are there other tickets for segfaults and crashes in > Parrot affecting Rakduo besides RT #56448, or am I misunderstanding the > purpose of the change? I know of #55782. From time to time I encounter some GC weirdnesses, but so far I didn't care to report them all, because I have no way of to know if they have all the same root or not. And as long as even the simplest programs in rakudo (like '1') fail with the gcdebug runcore I don't really know how to identify an offending construct in Perl 6 (if there is one). > If the default behavior is to work around problems, I fear that we won't get > the problems fixed. (See also "Why alternate runcores break far too > frequently.) > > -- c -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
On Sunday 29 June 2008 15:03:24 Moritz Lenz wrote: > I know of #55782. From time to time I encounter some GC weirdnesses, but > so far I didn't care to report them all, because I have no way of to > know if they have all the same root or not. > And as long as even the simplest programs in rakudo (like '1') fail with > the gcdebug runcore I don't really know how to identify an offending > construct in Perl 6 (if there is one). Let me repeat my offer from RT #55782: if someone hands me some PIR which demonstrates any memory problem or crash in Parrot, I'll fix it. They almost definitely won't get fixed unless they're reported, and they probably won't get fixed without simpler PIR examples. -- c
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
On Sun, Jun 29, 2008 at 02:21:20PM -0700, chromatic wrote: > On Sunday 29 June 2008 06:52:12 [EMAIL PROTECTED] wrote: > > --- trunk/languages/perl6/tools/test_summary.pl (original) > > +++ trunk/languages/perl6/tools/test_summary.pl Sun Jun 29 06:52:09 2008 > > @@ -58,7 +58,7 @@ > > -my $cmd = "../../parrot perl6.pbc $tfile"; > > +my $cmd = "../../parrot -G perl6.pbc $tfile"; > > This change bugs me; are there other tickets for segfaults and crashes in > Parrot affecting Rakduo besides RT #56448, or am I misunderstanding the > purpose of the change? > > If the default behavior is to work around problems, I fear > that we won't get the problems fixed. I think this question requires a longish reply -- apologies in advance for the length. First, r28816 is not related to RT#56448; the segfault in RT#56448 occurs regardless of the presence/absence of the -G flag. There exists in Parrot a category of segfaults that I now refer to as "-G bugs", because they magically disappear when Parrot is run with the -G option. Unfortunately, they also magically disappear if you make seemingly any sort of minor change to the source code (either PIR or HLL) or input data, which makes them very difficult to track or locate. This is likely the case for RT#54116 and RT#55782, both of which report segfaults that disappear with -G. In each of those tickets chromatic asks an appropriate question -- "Can you reproduce it with the generated PIR?" -- and this goes unanswered. In the general case I speculate (and will confirm shortly in each of those tickets) that the segfault will _not_ appear when run from the generated PIR, because running the generated PIR directly will be a sufficient enough change in the order of operations that the -G bug disappears. In other words, these bugs often act like true "heisenbugs" -- they disappear as soon as you start perturbing the system to find them. I grant that they probably are trackable using the --gcdebug runcore, but for Rakudo-compiler-related segfaults that can take a _really_ long time. It has also been my experience that the -G bugs appear and disappear in the normal course of development -- when a -G bug appears, it sticks around only until something else is changed in the source, at which point it disappears again. So, the only way to reproduce the error is to use the exact same Parrot revision as the original, and it may even require the same build platform. In the case of the r28816 patch, I chose to add -G to the test_summary.pl script because my primary use of that script is to measure how Rakudo is performing with respect to the official test suite. The -G bugs distort that measurement a fair bit, since they aren't really bugs with Rakudo, and since they cause test files to abort early. However, having the the -G option in test_summary.pl doesn't cause them to go completely hidden, because they still show up with the standard "make spectest_regression" and "make fulltest" targets, and of course someone running rakudo from a command line will still be exposed to any bugs. I agree entirely with the concept that we should not be working around problems -- and I even hesitated for a week or so on this very point before adding the -G to test_summary.pl . But ultimately I decided that since we still have the bugs appearing via normal usage and the standard 'make spectest_regression' and 'make fulltest' targets, it wouldn't be a big problem to have -G here. If after reading the above the hardcoded -G in test_summary.pl is still seen as a problem, then I'll see about switching it to be a command line option or environment variable for my purposes. Or, even better, if we finally track down the source of the -G bugs, then I'm sure we'll see -G much less often. :-) Thanks, Pm
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
chromatic wrote: > On Sunday 29 June 2008 15:03:24 Moritz Lenz wrote: > >> I know of #55782. From time to time I encounter some GC weirdnesses, but >> so far I didn't care to report them all, because I have no way of to >> know if they have all the same root or not. > >> And as long as even the simplest programs in rakudo (like '1') fail with >> the gcdebug runcore I don't really know how to identify an offending >> construct in Perl 6 (if there is one). > > Let me repeat my offer from RT #55782: if someone hands me some PIR which > demonstrates any memory problem or crash in Parrot, I'll fix it. So far I've never been able to do reproduce any of my bugs in PIR. I tried it a few times, but to no avail. > They almost definitely won't get fixed unless they're reported, and they > probably won't get fixed without simpler PIR examples. So how do we get simpler PIR examples? And should I just report all GC issues even if they can't be reproduced in PIR? Do we even know if they *can* be reproduced in PIR at all? I'm not too familiar with parrot's internals, but I could well imagine that a small memory corruption or GC oddity appears in some of the code that loads pbc files, or during any other operation that isn't executed (or executed differently) when loading and compiling PIR files. If we are truly out of luck, it might be some arithmetic bug which only manifests itself for larger bytecode files. I don't say it's likely to be any of the above cases, but at least it would explain why nobody found out what went wrong. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #54116] update for r28833
Some updates as of r28833, (kubuntu 8.04, x86)
Simple ranges seem to work:
$ ./parrot perl6.pbc -e '1..1000' # works
$ ./parrot perl6.pbc -e 'say 1..1000' # works
The original test case segfaults after 214 iterations:
$ cat x
for 1..1000 -> $a { say $a }
$ ./parrot perl6.pbc x
1
2
3
[...4 through 211...]
212
213
214
Segmentation fault
But it works with the -G flag:
$ ./parrot -G perl6.pbc x
1
2
3
[...4 through 997...]
998
999
1000
If we read the program via the -e flag, it segfaults after 174 iterations:
$ ./parrot perl6.pbc -e "$(cat x)"
1
2
3
[...4 through 171...]
172
173
174
Segmentation fault
Somewhat surprisingly, both reading from a file and executing via -e
produce the exact same PIR output:
$ ./parrot perl6.pbc --target=pir x >x.pir
$ ./parrot perl6.pbc --target=pir -e "$(cat x)" >e.pir
$ diff e.pir x.pir
$
To turn the generated .pir file into standalone executable,
add a load_bytecode 'perl6.pbc' opcode inside of the first
sub. This then segfaults after 352 iterations:
$ vi x.pir
...
$ head -6 x.pir
.namespace
.sub "_block11"
load_bytecode 'perl6.pbc'
.lex "$_", $P12
.lex "$/", $P13
$ ./parrot x.pir
1
2
3
[...4 through 349...]
350
351
352
Hope this helps,
Pm
[perl #55782] update for r28833
[Oops! I accidentally sent this message to the wrong ticket (#54116) --
this resends it to the correct one.]
Some updates as of r28833, (kubuntu 8.04, x86)
Simple ranges seem to work:
$ ./parrot perl6.pbc -e '1..1000' # works
$ ./parrot perl6.pbc -e 'say 1..1000' # works
The original test case segfaults after 214 iterations:
$ cat x
for 1..1000 -> $a { say $a }
$ ./parrot perl6.pbc x
1
2
3
[...4 through 211...]
212
213
214
Segmentation fault
But it works with the -G flag:
$ ./parrot -G perl6.pbc x
1
2
3
[...4 through 997...]
998
999
1000
If we read the program via the -e flag, it segfaults after 174 iterations:
$ ./parrot perl6.pbc -e "$(cat x)"
1
2
3
[...4 through 171...]
172
173
174
Segmentation fault
Somewhat surprisingly, both reading from a file and executing via -e
produce the exact same PIR output:
$ ./parrot perl6.pbc --target=pir x >x.pir
$ ./parrot perl6.pbc --target=pir -e "$(cat x)" >e.pir
$ diff e.pir x.pir
$
To turn the generated .pir file into standalone executable,
add a load_bytecode 'perl6.pbc' opcode inside of the first
sub. This then segfaults after 352 iterations:
$ vi x.pir
...
$ head -6 x.pir
.namespace
.sub "_block11"
load_bytecode 'perl6.pbc'
.lex "$_", $P12
.lex "$/", $P13
$ ./parrot x.pir
1
2
3
[...4 through 349...]
350
351
352
Hope this helps,
Pm
Re: [perl #54116] update for r28833
Oops! My message above went to the wrong ticket, see RT#55782 for that case. As for RT#54116 (this ticket) -- I do not get a segfault when running r27472 on my system (kubuntu 8.04, x86). Nor do I get a segfault on the current head (r28833). However, if someone wants to generate standalone PIR, do the following. First, generate the PIR: $ ./parrot perl6.pbc --target=pir t/00-parrot/05-var.t >05-var.pir Then, modify the 05-var.pir file to replace the first 9 lines with a load_bytecode 'perl6.pbc' opcode. It should look something like .namespace .sub "_block10" load_bytecode 'perl6.pbc' new $P15, "Perl6Str" assign $P15, "1..12" "say"($P15) ... I've attached my copy of the generated PIR from r27472 to this message. As mentioned before, it doesn't segfault. Pm .namespace .sub "_block10" load_bytecode 'perl6.pbc' new $P15, "Perl6Str" assign $P15, "1..12" "say"($P15) new $P16, "Perl6Str" assign $P16, "ok 1" new $P17, "Undef" .lex "$o1", $P17 copy $P17, $P16 find_lex $P18, "$o1" unless_null $P18, vivify_128 new $P18, "Undef" vivify_128: "say"($P18) new $P19, "Undef" .lex "$o2", $P19 new $P20, "Perl6Str" assign $P20, "ok 2" find_lex $P21, "$o2" unless_null $P21, vivify_129 new $P21, "Undef" store_lex "$o2", $P21 vivify_129: copy $P21, $P20 find_lex $P22, "$o2" unless_null $P22, vivify_130 new $P22, "Undef" vivify_130: "say"($P22) new $P23, "Int" assign $P23, 3 new $P24, "Undef" .lex "$a", $P24 copy $P24, $P23 new $P25, "Perl6Str" assign $P25, "ok " "print"($P25) find_lex $P26, "$a" unless_null $P26, vivify_131 new $P26, "Undef" vivify_131: "say"($P26) new $P27, "Undef" .lex "$b", $P27 new $P28, "Int" assign $P28, 4 find_lex $P29, "$b" unless_null $P29, vivify_132 new $P29, "Undef" store_lex "$b", $P29 vivify_132: copy $P29, $P28 new $P30, "Perl6Str" assign $P30, "ok " "print"($P30) find_lex $P31, "$b" unless_null $P31, vivify_133 new $P31, "Undef" vivify_133: "say"($P31) new $P32, "Int" assign $P32, 5 get_global $P33, "$x" unless_null $P33, vivify_134 new $P33, "Undef" set_global "$x", $P33 vivify_134: copy $P33, $P32 new $P34, "Perl6Str" assign $P34, "ok " get_global $P35, "$x" unless_null $P35, vivify_135 new $P35, "Undef" vivify_135: "say"($P34, $P35) get_global $P47, "_block36" newclosure $P47, $P47 $P47() get_global $P50, "$x" unless_null $P50, vivify_138 new $P50, "Undef" vivify_138: new $P51, "Int" assign $P51, 2 $P52 = "infix:+"($P50, $P51) new $P53, "Int" assign $P53, 7 $P49 = "infix:=="($P52, $P53) chain_end_139: if $P49, if_48 goto if_48_end if_48: get_global $P65, "_block54" newclosure $P65, $P65 $P64 = $P65() if_48_end: get_global $P88, "_block66" newclosure $P88, $P88 $P88() new $P89, "Int" assign $P89, 9 find_lex $P90, "$b" unless_null $P90, vivify_145 new $P90, "Undef" store_lex "$b", $P90 vivify_145: copy $P90, $P89 new $P93, "Perl6Str" assign $P93, "ok " find_lex $P94, "$b" unless_null $P94, vivify_146 new $P94, "Undef" vivify_146: n_concat $P95, $P93, $P94 new $P96, "Perl6Str" assign $P96, "ok 9" $P92 = "infix:eq"($P95, $P96) chain_end_147: if $P92, if_91 goto if_91_end if_91: new $P97, "Perl6Str" assign $P97, "ok 9" $P98 = "say"($P97) if_91_end: new $P101, "Perl6Str" assign $P101, "ok $b" new $P102, "Perl6Str" assign $P102, "ok 9" $P100 = "infix:ne"($P101, $P102) chain_end_148: if $P100, if_99 goto if_99_end if_99: new $P103, "Perl6Str" assign $P103, "ok 10" $P104 = "say"($P103) if_99_end: new $P105, "Perl6Str" assign $P105, "0x0b" find_lex $P106, "$b" unless_null $P106, vivify_149 new $P106, "Undef" store_lex "$b", $P106 vivify_149: copy $P106, $P105 new $P109, "Perl6Str" assign $P109, "ok " find_lex $P110, "$b" unless_null $P110, vivify_150 new $P110, "Undef" vivify_150: n_concat $P111, $P109, $P110 new $P112, "Perl6Str" assign $P112, "ok 0x0b" $P108 = "infix:eq"($P111, $P112) chain_end_151: if $P108, if_107 goto if_107_end if_107: new $P113, "Perl6Str" assign $P113, "ok 11" $P114 = "say"($P113) if_107_end: new $P115, "Perl6Str" assign $P115, "not ok 12" get_global $P116, "$x" unless_null $P116, vivify_152 new $P116, "Undef" set_global "$x", $P116 vivify_152: copy $P116, $P115 get_global $P125, "_block117" newclosure $P125, $P125 $P125() get_global $P126, "$x" unless_null $P126, vivify_155 new $P126, "Undef" vivify_155: $P127 = "say"($P126) .return ($P127) .end .nam
Re: [perl #55782] update for r28833
On Sunday 29 June 2008 16:03:08 Patrick R. Michaud wrote:
> [Oops! I accidentally sent this message to the wrong ticket (#54116) --
> this resends it to the correct one.]
>
> Some updates as of r28833, (kubuntu 8.04, x86)
>
> Simple ranges seem to work:
>
> $ ./parrot perl6.pbc -e '1..1000' # works
>
> $ ./parrot perl6.pbc -e 'say 1..1000' # works
>
> The original test case segfaults after 214 iterations:
>
> $ cat x
> for 1..1000 -> $a { say $a }
> $ ./parrot perl6.pbc x
> To turn the generated .pir file into standalone executable,
> add a load_bytecode 'perl6.pbc' opcode inside of the first
> sub. This then segfaults after 352 iterations:
Fixed in r28836. Thanks for the instructions on how to reproduce it!
-- c
Re: [RFC] merge stack_common.c and stacks.c
On Jun 29, 2008, at 1:23 PM, Andrew Whitworth wrote: After all the efforts to simplify Parrot's stack situation, it seems to me like src/stack_common.c and src/stacks.c can be merged. Are you saying you want to do it, or asking someone else to? I'd be glad to do that. C-level source, that I can handle. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[perl #56166] [BUG] [PATCH] Perl::Critic Version Problems
On Sun Jun 22 19:35:27 2008, coke wrote: > Attached find a first pass at converting our perlcritic.t into using > Test::Perl::Critic. > > This patch: > > - requires Test::Perl::Critic to do anything useful with the test. (We > can add it to > Bundle::Parrot) > - creates a new perlcritic.conf file that represents declaratively a > large chunk of the code we > used to use to manage the policy list. > - removes the ability to list the policies. (you have the conf file) > - removes the ability to specify a specific policy (you can roll your > own with themes) > - removes the ability to specify a directory to run the policies > against (but if we do, let's do it > without File::Find, and just key off the MANIFEST like we do now.) > - keeps the ability to specify a "group" of tests, but calls it a > theme, following the lead set by > Perl::Critic. > - reports each file as a test, not each policy. > > I think the last item there is a big reason we started down the path > we did, but given how > much simpler this script is, I don't think it's worth worrying about. > > I've tested this on Perl::Critic 1.086; I'd be interested to hear > feedback on older versions of > P::C before I apply. (The old version I had installed is no longer > available for easy download > on the CPAN) > > Feedback in general, as well: This is a reduction in features from the > original version, but I > think it's a step forward. Applied in r28839, closing ticket. Thanks to kid51++ for testing. -- Will "Coke" Coleda
[perl #43413] [TODO] Pass options to policies from perlcritic.t command line
On Thu Jun 28 07:22:38 2007, pcoch wrote:
> Hi,
>
> In perlcritic.t i'd like to find a way to pass options to perlcritic
> policies from the command line. Options are passed as anonymous
> hashes. Basically, we want to be able to do something like:
>
> perl t/codingstd/perlcritic.t --list
> --policy=CodeLayout::ProhibitHardTabs=>{'allow_leading_tabs'=>0}
>
> and it to give the output:
>
> CodeLayout::ProhibitHardTabs => \{
>'allow_leading_tabs' => 0
> }
>
> Such that the option of *not* allowing leading tabs is passed on to
> perlcritic.
>
> Regards,
>
> Paul
Rejected. New version of t/codingstd/perlcritic.t (r28839) now uses the
standard
perlcritic.conf file as the way to set options on various policies.
--
Will "Coke" Coleda
[perl #56454] [BUG] Another -G bug. With PIR
# New Ticket Created by luben karavelov
# Please include the string: [perl #56454]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56454 >
The source of the program (dumb fibonacci numbers) is as follows:
use v6;
sub fib( $n ){
if ( $n < 2 ) {
$n;
} else {
fib($n-1)+fib($n-2);
}
}
say fib(11);
it dies with segmentation fault if run without -G option:
./parrot languages/perl6/perl6.pbc fib
Segmentation fault
I have generated the corresponding PIR like this:
./parrot languages/perl6/perl6.pbc --target=pir --output=fib.pir fib
In order to run the PIR code I have added load_bytecode
'languages/perl6/perl6.pbc'
in the first sub and I have deleted the ':instanceof("Perl6Sub")' declaration
for
sub "fib".
When I run it in parrot it works as expected. But If I change the requested
fibonacci number to 12 it starts to segfault again. If run with -G option it
works.
Attanched is the PIR source
[perl #41606] [TODO] Add flag to do runtime check on deprecated ops
On Fri Jun 27 08:01:57 2008, coke wrote: > On Thu Jun 26 22:21:22 2008, [EMAIL PROTECTED] wrote: > > On Thursday 26 June 2008 20:02:18 Will Coleda via RT wrote: > > > > > Attached, find a patch that allows us to specify a ":deprecated" > > flag (post > > > op, ala :flow). It also adds a new parrot warning (configurable with > > > warningson) level called PARROT_WARNING_DEPRECATED_FLAG. The patch > > only > > > applies this flag to getclass. > > > > > > Comments welcome. (Hopefully sooner than it took me to comment on > > kjs's > > > last send on this ticket. =-). The one thing I'm not sure about is > > that I'm > > > just using fprintf as in kjs's original sample. Could probably stand > > to > > > actually use parrot IO. I'm also not happy that it doesn't show the > > > location of the opcode, but I can live with that for now. > > > > +1 from me as-is. ParrotIO stuff will likely have to change in the > > medium-term anyway, so we'll probably have to modify this code (if we > > don't > > remove the ops altogether) at some point anyway. > > > > -- c > > > > Here's a more extensive version of the patch, marking other ops as > deprecated, and updating DEPRECATED.pod. > > However, running this, the new deprecation warnings are triggered during > 'make test'. Which is nifty, but not something we want turned on by > default yet, I think. This was because when using t/harness, Test::Harness::runtests was adding the '-w' option.. which is usually harmless with both perl and parrot, but since we're adding a level of warnings we don't want enabled by default for parrot, I've disabled this in r28843. Rest of the patch applied in r28844. Closing ticket. -- Will "Coke" Coleda
Re: [perl #56454] [BUG] Another -G bug. With PIR
On Sunday 29 June 2008 18:17:16 luben karavelov wrote:
> The source of the program (dumb fibonacci numbers) is as follows:
>
> use v6;
>
> sub fib( $n ){
> if ( $n < 2 ) {
> $n;
> } else {
> fib($n-1)+fib($n-2);
> }
> }
>
> say fib(11);
>
> it dies with segmentation fault if run without -G option:
>
> ./parrot languages/perl6/perl6.pbc fib
> Segmentation fault
>
> I have generated the corresponding PIR like this:
> ./parrot languages/perl6/perl6.pbc --target=pir --output=fib.pir fib
>
> In order to run the PIR code I have added load_bytecode
> 'languages/perl6/perl6.pbc' in the first sub and I have deleted the
> ':instanceof("Perl6Sub")' declaration for sub "fib".
>
> When I run it in parrot it works as expected. But If I change the requested
> fibonacci number to 12 it starts to segfault again. If run with -G option
> it works.
I can reproduce it if I back out r28836, but I can't reproduce it after that.
The crash is in the same place, so I think it's the same bug. Can you update
to r28836 or later and confirm that it's fixed?
-- c
