On Wed, Mar 5, 2008 at 12:17 PM, jerry gay <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 5, 2008 at 8:44 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Mar 4, 2008 at 10:14 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tuesday 04 March 2008 19:09:48 Will Coleda wrote:
> > >
> > > > On Tue, Mar 4, 2008 at 9:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > >
> > > > > Tcl: doesn't run
> > > > >
> > > > > unable to assign self to this type
> > > > > # current instr.: '__list' pc 25773
> > > > > (languages/tcl/runtime/conversions.pir:27) # called from Sub
> '&proc' pc
> > > > > 22110
> > > > > (languages/tcl/runtime/builtin/proc.pir:106)
> > > > > # called from Sub '_anon' pc 44 (EVAL_4:18)
> > > > > # called from Sub '__load_stdlib' pc 55943
> (runtime/tcllib.pir:291)
> > > > > # called from Sub '_main' pc 3 (src/tclsh.pir:36)
> > > >
> > > > Offending code:
> > > >
> > > > morph value, .Undef
> > > > assign value, $P0
> > > >
> > > > 25772 morph P0, 80 P0=TclString=PMC(0x790080)
> > > > 25775 assign P0, P1 P0=Undef=PMC(0x790080)
> > > > P1=TclList=PMC(0x78ebd4)
> > > >
> > > > This part of tcl still works in trunk.
> > >
> > > r26217 fixes most of that, but I'm no fan of .Undef. (Why does that
> work in
> > > trunk?)
> > >
> > > -- c
> > >
> > >
> >
> > Now that I can build the branch again, I can verify that this did fix
> > most of the issues. One of the biggest failures remaining (cmd_expr.t)
> > is caused by smaller test case:
> >
> > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {bar baz} 1]]"
> > argument doesn't array
> >
> > (prints "baz\n" in trunk)
> >
> > This is coming from src/inter_call.c:374, where it is trying to verify
> > that a given PMC should "does" array. Looks like the offending PMC is
> > a Parrot_Object when this blows up (based on the vtable methods of the
> > PMC in question.)
> >
> > --
> > Will "Coke" Coleda
> >
>
> what was formerly 'does' in the pmclass definition, is now spelled
> 'provides'. change all those declarations in the tcl pmcs and you'll
> be good.
>
>
On Wed, Mar 5, 2008 at 12:17 PM, jerry gay <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 5, 2008 at 8:44 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Mar 4, 2008 at 10:14 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tuesday 04 March 2008 19:09:48 Will Coleda wrote:
> > >
> > > > On Tue, Mar 4, 2008 at 9:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > >
> > > > > Tcl: doesn't run
> > > > >
> > > > > unable to assign self to this type
> > > > > # current instr.: '__list' pc 25773
> > > > > (languages/tcl/runtime/conversions.pir:27) # called from Sub
> '&proc' pc
> > > > > 22110
> > > > > (languages/tcl/runtime/builtin/proc.pir:106)
> > > > > # called from Sub '_anon' pc 44 (EVAL_4:18)
> > > > > # called from Sub '__load_stdlib' pc 55943
> (runtime/tcllib.pir:291)
> > > > > # called from Sub '_main' pc 3 (src/tclsh.pir:36)
> > > >
> > > > Offending code:
> > > >
> > > > morph value, .Undef
> > > > assign value, $P0
> > > >
> > > > 25772 morph P0, 80 P0=TclString=PMC(0x790080)
> > > > 25775 assign P0, P1 P0=Undef=PMC(0x790080)
> > > > P1=TclList=PMC(0x78ebd4)
> > > >
> > > > This part of tcl still works in trunk.
> > >
> > > r26217 fixes most of that, but I'm no fan of .Undef. (Why does that
> work in
> > > trunk?)
> > >
> > > -- c
> > >
> > >
> >
> > Now that I can build the branch again, I can verify that this did fix
> > most of the issues. One of the biggest failures remaining (cmd_expr.t)
> > is caused by smaller test case:
> >
> > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {bar baz} 1]]"
> > argument doesn't array
> >
> > (prints "baz\n" in trunk)
> >
> > This is coming from src/inter_call.c:374, where it is trying to verify
> > that a given PMC should "does" array. Looks like the offending PMC is
> > a Parrot_Object when this blows up (based on the vtable methods of the
> > PMC in question.)
> >
> > --
> > Will "Coke" Coleda
> >
>
> what was formerly 'does' in the pmclass definition, is now spelled
> 'provides'. change all those declarations in the tcl pmcs and you'll
> be good.
>
That appears to be what chromatic already did in r26217.
--
Will "Coke" Coleda
