[perl #50996] [BUG] gc bug with perl6grammar in pdd17pmc branch
Alright, I set up a windows box with MSVC and ActivePerl and did a binary search. The commit that caused the breakage is r25266, when we updated the PMC struct. Tomorrow I'll experiment with reverting parts of that commit.
Re: [svn:parrot] r26236 - trunk/compilers/imcc
On Wednesday 05 March 2008 18:33:24 [EMAIL PROTECTED] wrote: > + if (len && (current[len-1] == '$')) { /* local label */ Better as: current[len - 1] Whitespace is nice. -- c
[perl #51478] PDD17PMC : argument doesn't array
# New Ticket Created by Will Coleda # Please include the string: [perl #51478] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51478 > in PDD17, the following program (which prints "b\n" in trunk), dies: $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]" argument doesn't array. This exception is coming from src/inter_call.c:374 369 dod_register_pmc(interp, st->key); 370 } 371 else { 372 /* src ought to be an array */ 373 if (!VTABLE_does(interp, p_arg, CONST_STRING(interp, "array"))) 374 real_exception(interp, NULL, E_ValueError, "argument doesn't array"); 375 } 376 377 st->src.mode |= CALL_STATE_FLATTEN; 378 st->src.slurp = p_arg; breaking at 374.. (gdb) p *p_arg $1 = {cache = {_b = {_bufstart = 0x835a1ac, _buflen = 3735928559}, _ptrs = { _struct_val = 0x835a1ac, _pmc_val = 0xdeadbeef}, _i = { _int_val = 137732524, _int_val2 = -559038737}, _num_val = -1.1885954149046845e+148, _string_val = 0x835a1ac}, flags = 1146095104, vtable = 0x808a6a0, data = 0x80bc008, pmc_ext = 0x81add58, real_self = 0x835a1c8} (gdb) p p_arg->vtable->base_type $3 = 61 So, the PMC is a Parrot_Object, and since the vtable is healthy, I assume this isn't a GC issue. If I try to ask the PMC what it's type is (so I can figure out where it came from), I get a segfault (gdb) p p_arg->vtable->name(interp,p_arg) #BOOM So I set a conditional breakpoint on pmc_new and did a bt to find that this particular PMC was created during a thaw. (gdb) b src/pmc_new.c:71 if pmc==0x835a1c8 #0 pmc_new (interp=0x804f008, base_type=34) at src/pmc.c:71 #1 0xb7c19fd7 in ft_init (interp=0x804f008, info=0xbff6d228) at src/pmc_freeze.c:958 #2 0xb7c1a081 in todo_list_init (interp=0x804f008, info=0xbff6d228) at src/pmc_freeze.c:983 #3 0xb7c1b1e3 in run_thaw (interp=0x804f008, image=0x8326cd8, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1680 #4 0xb7c1b490 in Parrot_thaw (interp=0x804f008, image=0x8326cd8) at src/pmc_freeze.c:1808 #5 0xb7c15da0 in PackFile_Constant_unpack_pmc (interp=0x804f008, constt=0x812c148, self=0x80c78c0, cursor=0xb6ce9978) at src/packfile.c:3572 And here my limited c-fu petered out. -- Will "Coke" Coleda
Re: [svn:parrot] r26236 - trunk/compilers/imcc
On Mar 6, 2008, at 2:53 AM, chromatic wrote: Better as: current[len - 1] Whitespace is nice. Don't run ack '\w-1\]' or you might cry. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [svn:parrot] r26236 - trunk/compilers/imcc
On Thursday 06 March 2008 07:12:03 Andy Lester wrote: > On Mar 6, 2008, at 2:53 AM, chromatic wrote: > > Better as: > > > > current[len - 1] > > > > Whitespace is nice. > > Don't run ack '\w-1\]' or you might cry. I've been fixing those. Don't even *ask* if some of our code is in logically-formatted paragraphs. -- c
Re: [svn:parrot] r26248 - trunk/src/pmc
On Thursday 06 March 2008 07:41:07 [EMAIL PROTECTED] wrote: > Log: > This started out as spacing out some n-1 constructs for chromatic, but > then I looked around and saw a lot of returns from functions and those > kinda make me sad because it's usually nicer to drain out the bottom of > the function so I did a little block shuffling. Ugh. People can get over being sad, but unless there are resource release considerations, increasing the nesting depth of a function, widening the scope of stack variables, and obscuring the control flow with more if/else constructs seems like a net loss to me. -- c
[perl #50968] [BUG] trouble with perl 6 grammars and capturing '.*?'
On Mon Feb 18 14:00:49 2008, particle wrote: > in rakudo's perl6doc parser > (languages/perl6/src/utils/perl6doc/grammar.pg), i have the following: > > token pod_delimited_block { > ^^ '=' <.unsp>? 'begin' <.ws> * \n > .*? > ^^ '=' <.unsp>? 'end' <.ws> $ \N* > {*} > } > > i'd like to capture '.*?' either via an alias or better, via a > subrule. however, modifying the grammar to something that will > capture, like > (.*?) > or > $=[.*?] > or > > > causes the match to fail. smells like a pge bug to me. Turns out that this isn't a bug, although it is a somewhat unexpected artifact of :ratchet. When :ratchet is active within a regex (as would be the case for 'token' or 'rule'), then placing a grouping construct around .*? effectively makes it non-backtracking. Or, to be more precise, the grouping construct doesn't have an explicit quantifier on it (even though the thing it contains does have one), and thus once the group matches something then :ratchet prevents us from backtracking into it. So, in this specific instance of a token (i.e., :ratchet is in effect), the expression C<< .*? >> performs backtracking and will eagerly match any sequence, but C<< (.*?) >> and C<< [.*?] >> always match exactly the null string because there is an assumed "cut" operation after the parens or brackets. There was a short discussion on IRC about possibly changing this to be somewhat less surprising, but I think we concluded that the current behavior is the "least bad" one for now. Closing ticket. Pm
Re: [svn:parrot] r26248 - trunk/src/pmc
On Mar 6, 2008, at 11:58 AM, chromatic wrote: Ugh. People can get over being sad, but unless there are resource release considerations, increasing the nesting depth of a function, widening the scope of stack variables, and obscuring the control flow with more if/else constructs seems like a net loss to me. Actually, it was to decrease the scope of stack variables. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [svn:parrot] r26248 - trunk/src/pmc
On Thursday 06 March 2008 10:53:00 Andy Lester wrote: > Actually, it was to decrease the scope of stack variables. Carry on then. (As long as it's not "Functions should have one entry and one exit point", at which point I pull out the whiteboard and give my "Does this LOOK like FORTRAN to you?" lecture.) -- c
Re: [svn:parrot] r26248 - trunk/src/pmc
On Mar 6, 2008, at 1:09 PM, chromatic wrote: Actually, it was to decrease the scope of stack variables. Carry on then. (As long as it's not "Functions should have one entry and one exit point", at which point I pull out the whiteboard and give my "Does this LOOK like FORTRAN to you?" lecture.) Well, they should have exit point, ideally. We should also have 100% code coverage, too. And I should be a much better dancer. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [perl #51478] PDD17PMC : argument doesn't array
On Thursday 06 March 2008 06:22:21 Will Coleda wrote: > in PDD17, the following program (which prints "b\n" in trunk), dies: > > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]" > argument doesn't array. > > This exception is coming from src/inter_call.c:374 > > 369 dod_register_pmc(interp, st->key); > 370 } > 371 else { > 372 /* src ought to be an array */ > 373 if (!VTABLE_does(interp, p_arg, CONST_STRING(interp, > "array"))) 374 real_exception(interp, NULL, E_ValueError, > "argument doesn't array"); > 375 } > 376 > 377 st->src.mode |= CALL_STATE_FLATTEN; > 378 st->src.slurp = p_arg; > > breaking at 374.. > > (gdb) p *p_arg > $1 = {cache = {_b = {_bufstart = 0x835a1ac, _buflen = 3735928559}, _ptrs = > { _struct_val = 0x835a1ac, _pmc_val = 0xdeadbeef}, _i = { > _int_val = 137732524, _int_val2 = -559038737}, > _num_val = -1.1885954149046845e+148, _string_val = 0x835a1ac}, > flags = 1146095104, vtable = 0x808a6a0, data = 0x80bc008, > pmc_ext = 0x81add58, real_self = 0x835a1c8} > (gdb) p p_arg->vtable->base_type > $3 = 61 > > So, the PMC is a Parrot_Object, and since the vtable is healthy, I > assume this isn't a GC issue. > > If I try to ask the PMC what it's type is (so I can figure out where > it came from), I get a segfault > > (gdb) p p_arg->vtable->name(interp,p_arg) > #BOOM > > So I set a conditional breakpoint on pmc_new and did a bt to find that > this particular PMC was created during a thaw. > > (gdb) b src/pmc_new.c:71 if pmc==0x835a1c8 > > #0 pmc_new (interp=0x804f008, base_type=34) at src/pmc.c:71 > #1 0xb7c19fd7 in ft_init (interp=0x804f008, info=0xbff6d228) > at src/pmc_freeze.c:958 > #2 0xb7c1a081 in todo_list_init (interp=0x804f008, info=0xbff6d228) > at src/pmc_freeze.c:983 > #3 0xb7c1b1e3 in run_thaw (interp=0x804f008, image=0x8326cd8, > what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1680 > #4 0xb7c1b490 in Parrot_thaw (interp=0x804f008, image=0x8326cd8) > at src/pmc_freeze.c:1808 > #5 0xb7c15da0 in PackFile_Constant_unpack_pmc (interp=0x804f008, > constt=0x812c148, self=0x80c78c0, cursor=0xb6ce9978) at > src/packfile.c:3572 > > And here my limited c-fu petered out. Can you dump the Tcl program to a PIR program, or at least tell me how to do it? I have an idea what this might be. -- c
Re: pdd17pmc branch review
On Tue, Mar 04, 2008 at 06:39:38PM -0800, chromatic wrote: > On Tuesday 04 March 2008 16:48:09 Will Coleda wrote: > > So, language developers (and others); please grab a copy of > > https://svn.perl.org/parrot/branches/pdd17pmc and check out the > > languages to see how they fare compared to their counterparts in > > trunk. > ... > Perl 6: doesn't run As of r26253 it appears that Rakudo is running in the pdd17pmc branch (passes 'make test'). If there's something else that needs testing related to Rakudo, PCT, NQP, PGE, etc., then let me know. Pm
Re: pdd17pmc branch review
> On Tuesday 04 March 2008 16:48:09 Will Coleda wrote: > So, language developers (and others); please grab a copy of > https://svn.perl.org/parrot/branches/pdd17pmc and check out the > languages to see how they fare compared to their counterparts in > trunk. APL doesn't run. I suspect the aplvector.pmc needs to be updated to be pdd17-compliant, but I don't know the details of that conversion. I tried simply converting "does array" to "provides array" as mentioned for the Tcl conversion, which helped, but exposed a problem with generating Iterators on APLVector objects. That puts me at the limit of my understanding of APLVector and PMC generation in pdd17, so hopefully someone else can look at it. Pm
Re: [perl #51478] PDD17PMC : argument doesn't array
On Thu, Mar 6, 2008 at 2:41 PM, chromatic via RT <[EMAIL PROTECTED]> wrote: > > On Thursday 06 March 2008 06:22:21 Will Coleda wrote: > > > in PDD17, the following program (which prints "b\n" in trunk), dies: > > > > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]" > > argument doesn't array. > > > > This exception is coming from src/inter_call.c:374 > > > > 369 dod_register_pmc(interp, st->key); > > 370 } > > 371 else { > > 372 /* src ought to be an array */ > > 373 if (!VTABLE_does(interp, p_arg, CONST_STRING(interp, > > "array"))) 374 real_exception(interp, NULL, E_ValueError, > > "argument doesn't array"); > > 375 } > > 376 > > 377 st->src.mode |= CALL_STATE_FLATTEN; > > 378 st->src.slurp = p_arg; > > > > breaking at 374.. > > > > (gdb) p *p_arg > > $1 = {cache = {_b = {_bufstart = 0x835a1ac, _buflen = 3735928559}, _ptrs = > > { _struct_val = 0x835a1ac, _pmc_val = 0xdeadbeef}, _i = { > > _int_val = 137732524, _int_val2 = -559038737}, > > _num_val = -1.1885954149046845e+148, _string_val = 0x835a1ac}, > > flags = 1146095104, vtable = 0x808a6a0, data = 0x80bc008, > > pmc_ext = 0x81add58, real_self = 0x835a1c8} > > (gdb) p p_arg->vtable->base_type > > $3 = 61 > > > > So, the PMC is a Parrot_Object, and since the vtable is healthy, I > > assume this isn't a GC issue. > > > > If I try to ask the PMC what it's type is (so I can figure out where > > it came from), I get a segfault > > > > (gdb) p p_arg->vtable->name(interp,p_arg) > > #BOOM > > > > So I set a conditional breakpoint on pmc_new and did a bt to find that > > this particular PMC was created during a thaw. > > > > (gdb) b src/pmc_new.c:71 if pmc==0x835a1c8 > > > > #0 pmc_new (interp=0x804f008, base_type=34) at src/pmc.c:71 > > #1 0xb7c19fd7 in ft_init (interp=0x804f008, info=0xbff6d228) > > at src/pmc_freeze.c:958 > > #2 0xb7c1a081 in todo_list_init (interp=0x804f008, info=0xbff6d228) > > at src/pmc_freeze.c:983 > > #3 0xb7c1b1e3 in run_thaw (interp=0x804f008, image=0x8326cd8, > > what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1680 > > #4 0xb7c1b490 in Parrot_thaw (interp=0x804f008, image=0x8326cd8) > > at src/pmc_freeze.c:1808 > > #5 0xb7c15da0 in PackFile_Constant_unpack_pmc (interp=0x804f008, > > constt=0x812c148, self=0x80c78c0, cursor=0xb6ce9978) at > > src/packfile.c:3572 > > > > And here my limited c-fu petered out. > > Can you dump the Tcl program to a PIR program, or at least tell me how to do > it? I have an idea what this might be. > > -- c > > > > Sure. Take the original: > > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]" and just tack a --pir on the end: I verified that saving that out to a .pir file and running *that* through parrot generates the same error. Good luck... -- Will "Coke" Coleda
Re: [perl #51478] PDD17PMC : argument doesn't array
On Thursday 06 March 2008 11:47:41 Will Coleda wrote: > Sure. Take the original: > > > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]" > > and just tack a --pir on the end: I verified that saving that out to a > .pir file and running *that* through parrot generates the same error. Okay, here's what I've found. The attached PIR file runs fine on trunk, but fails in the branch. The problem comes at line 36, where the code calls &concat on a TclConst, attempting to flatten it. The TclConst comes from a previous __list call. I don't know enough about the details of Tcl right now to see if there's some different kind of PMC returned from trunk/branch, but does this help at all? If you can tell me what seems to be different, I can check the C code. -- c concat.pir Description: Troff document
[perl #50996] [BUG] gc bug with perl6grammar in pdd17pmc branch
The problem was in the conversion of pobj_t to the new flattened structure for PDD17. I've reverted that part of r25266 for now (in r26254). The problem is probably an incomplete conversion, with some parts of the code still expecting the multi-level structure. I'll work on a more complete conversion when I get back to the Windows laptop Friday night. In the mean time, please carry on with language testing on Windows. Allison
Re: [svn:parrot] r26248 - trunk/src/pmc
Andy Lester wrote: We should also have 100% code coverage, too. Ah, I'm so glad someone in addition to me said that! ;-) kid51
Re: pdd17pmc branch review
On Thu, Mar 6, 2008 at 2:45 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > > On Tuesday 04 March 2008 16:48:09 Will Coleda wrote: > > So, language developers (and others); please grab a copy of > > https://svn.perl.org/parrot/branches/pdd17pmc and check out the > > languages to see how they fare compared to their counterparts in > > trunk. > > APL doesn't run. I suspect the aplvector.pmc needs to be updated > to be pdd17-compliant, but I don't know the details of that > conversion. > > I tried simply converting "does array" to "provides array" > as mentioned for the Tcl conversion, which helped, but exposed > a problem with generating Iterators on APLVector objects. > That puts me at the limit of my understanding of APLVector and > PMC generation in pdd17, so hopefully someone else can look at it. > > Pm > I applied this change, as well as updating the methods to use the PDD17 conventions (PCCRETURN), etc. Now down to only six failing sub tests. ... I have to ask, if we switched to METHOD instead of PCCMETHOD, why do we have PCCRETURN instead of RETURN? =-) -- Will "Coke" Coleda
Re: pdd17pmc branch review
On Thursday 06 March 2008 18:25:57 Will Coleda wrote: > I applied this change, as well as updating the methods to use the > PDD17 conventions (PCCRETURN), etc. Now down to only six failing sub > tests. Again, if I can get PIR that corresponds to these tests (or find out how to generate it myself), I will try to fix them. Self-hosting test suites which use HLLCompiler are a real boon here. > ... I have to ask, if we switched to METHOD instead of PCCMETHOD, why > do we have PCCRETURN instead of RETURN? =-) Hysterical raisins, as far as I know. -- c