resizablepmcarray, assign.
Will Coleda
sure if it ever did)
set a [list a b]
set a b
Under the covers, this should create a TclList PMC and assign it to
the global '$a'. It should then discard that value, and replace the
value in '$a' with a String of "b".
However, running this errors with:
"Can't set self from this type"
This error appears in one place in the parrot code base, in
Parrot_ResizablePMCArray_set_integer_native.
I'm trying to figure out how the assign statement that does the swap
(from a trace output)
19552 assign P0, P1 P0=TclList=PMC(0x1cf0640)
P1=String=PMC(0x1cf04f0 Str:"b")
Ends up with the following backtrace:
#0 Parrot_ResizablePMCArray_set_integer_native
(interpreter=0xe00420, pmc=0x28191e8, size=1) at src/pmc/
resizablepmcarray.pmc:40
#1 0x00266090 in Parrot_ResizablePMCArray_push_pmc
(interpreter=0xe00420, pmc=0x28191e8, value=0x28191b8) at src/pmc/
resizablepmcarray.pmc:357
#2 0x0010c35c in new_hll_entry (interpreter=0xe00420) at src/hll.c:93
#3 0x0010c500 in Parrot_register_HLL (interpreter=0xe00420,
hll_name=0xbb9f48, hll_lib=0x0) at src/hll.c:123
#4 0x000b25bc in parrot_global_setup_2 (interpreter=0xe00420) at src/
global_setup.c:172
#5 0x00226778 in Parrot_initialize_core_pmcs (interp=0xe00420) at
src/core_pmcs.c:162
#6 0x000b23d0 in init_world (interpreter=0xe00420) at src/
global_setup.c:125
#7 0x0001a0dc in Parrot_init (interpreter=0xe00420) at src/embed.c:87
#8 0x000188d8 in make_interpreter (parent=0x0,
flags=PARROT_NO_FLAGS) at src/inter_create.c:167
#9 0x0001a084 in Parrot_new (parent=0x0) at src/embed.c:48
#10 0x00004ce4 in main (argc=4, argv=0xbffff794) at compilers/imcc/
main.c:509
Why is assign calling push_pmc?
And, why is RPA missing 'assign_pmc' (found in the plain ole Array) ?
(Though adding this to RPA in my sandbox didn't help.)
languages/tcl/t/tcl_misc.t#27 has a test for this behavior.
Any ideas?
--
Will "Coke" Coleda
wi...@coleda.com
Bob Rogers
Date: Sun, 30 Jul 2006 12:36:08 -0400
This code is not working in Tcl at the moment (at the moment, not
sure if it ever did)
set a [list a b]
set a b
Under the covers, this should create a TclList PMC and assign it to
the global '$a'. It should then discard that value, and replace the
value in '$a' with a String of "b".
It's apparently trying to do so by morphing $a in the
FixedPMCArray:set_pmc method . . .
However, running this errors with:
"Can't set self from this type"
This error appears in one place in the parrot code base, in
Parrot_ResizablePMCArray_set_integer_native.
Hmm . . . I find this message only in Parrot_FixedPMCArray_set_pmc,
which is inherited by ResizablePMCArray.
Why is assign calling push_pmc?
And, why is RPA missing 'assign_pmc' (found in the plain ole Array) ?
(Though adding this to RPA in my sandbox didn't help.)
Both ResizablePMCArray and FixedPMCArray have "does array" . . . but
apparently that is not the same as inheriting from Array. So both seem
to be using the default.pmc method instead, which re-dispatches to the
aforementioned set_pmc method.
languages/tcl/t/tcl_misc.t#27 has a test for this behavior.
What's the generated PIR for this?
-- Bob
Will Coleda
On Jul 30, 2006, at 2:49 PM, Bob Rogers wrote:
> From: Will Coleda <wi...@coleda.com>
> Date: Sun, 30 Jul 2006 12:36:08 -0400
>
> This code is not working in Tcl at the moment (at the moment, not
> sure if it ever did)
>
> set a [list a b]
> set a b
>
> Under the covers, this should create a TclList PMC and assign it to
> the global '$a'. It should then discard that value, and replace the
> value in '$a' with a String of "b".
>
> It's apparently trying to do so by morphing $a in the
> FixedPMCArray:set_pmc method . . .
>
> However, running this errors with:
> "Can't set self from this type"
>
> This error appears in one place in the parrot code base, in
> Parrot_ResizablePMCArray_set_integer_native.
>
> Hmm . . . I find this message only in Parrot_FixedPMCArray_set_pmc,
> which is inherited by ResizablePMCArray.
Whoops.
>
> Why is assign calling push_pmc?
>
> And, why is RPA missing 'assign_pmc' (found in the plain ole
> Array) ?
> (Though adding this to RPA in my sandbox didn't help.)
>
> Both ResizablePMCArray and FixedPMCArray have "does array" . . . but
> apparently that is not the same as inheriting from Array.
Yup. "does" only matters to the "does" opcode.
> So both seem
> to be using the default.pmc method instead, which re-dispatches to the
> aforementioned set_pmc method.
>
> languages/tcl/t/tcl_misc.t#27 has a test for this behavior.
>
> What's the generated PIR for this?
>
To get the pir generated by tcl (at least at the top level - there's
a lot of compiling going on throughout the runtime), do:
../../parrot tcl.pbc --pir -e 'set a [list a b]; set a b'
Bob Rogers
Date: Sun, 30 Jul 2006 15:02:29 -0400
> languages/tcl/t/tcl_misc.t#27 has a test for this behavior.
>
> What's the generated PIR for this?
To get the pir generated by tcl (at least at the top level - there's
a lot of compiling going on throughout the runtime), do:
../../parrot tcl.pbc --pir -e 'set a [list a b]; set a b'
This doesn't work for me, even in a freshly-built (though somewhat
hacked) r13655:
rogers@rgrjr> ../../parrot tcl.pbc --pir -e 'set a [list a b]; set a b'
too many arguments passed (3) - 2 params expected
current instr.: 'compile' pc 19796 (languages/tcl/src/compiler.pir:29)
called from Sub '_main' pc 474 (src/tclsh.pir:185)
rogers@rgrjr>
But I also notice that I can't run "make test" on Tcl because "prove" is
not on my path. I am using Perl 5.8.1, which is rather old, but not
that old, so maybe this is some quirk of the stock SuSE 9.0
configuration?
-- Bob Rogers
Chromatic
> But I also notice that I can't run "make test" on Tcl because "prove" is
> not on my path. I am using Perl 5.8.1, which is rather old, but not
> that old, so maybe this is some quirk of the stock SuSE 9.0
> configuration?
Install a newer version of Test::Harness. The one distributed with 5.8.1 did
not include prove.
-- c
Leopold Toetsch
> Install a newer version of Test::Harness. The one distributed with 5.8.1
> did not include prove.
from the parrot README:
PREREQUISITES
-------------
...
You'll also need Perl 5.6.1 or above to run various configure and build
scripts.
a) Parrot::Bundle provides all and is a prerequisite
b) prove is replaced by more conservative and working alternatives
(c) we keep the pain to be forced to download all possible modules
It's not prove only ...
Thanks,
leo
Will Coleda
On Jul 30, 2006, at 3:55 PM, Bob Rogers wrote:
> From: Will Coleda <wi...@coleda.com>
> Date: Sun, 30 Jul 2006 15:02:29 -0400
>
>> languages/tcl/t/tcl_misc.t#27 has a test for this behavior.
>>
>> What's the generated PIR for this?
>
> To get the pir generated by tcl (at least at the top level -
> there's
> a lot of compiling going on throughout the runtime), do:
>
> ../../parrot tcl.pbc --pir -e 'set a [list a b]; set a b'
>
> This doesn't work for me, even in a freshly-built (though somewhat
> hacked) r13655:
>
> rogers@rgrjr> ../../parrot tcl.pbc --pir -e 'set a [list a b]; set
> a b'
> too many arguments passed (3) - 2 params expected
> current instr.: 'compile' pc 19796 (languages/tcl/src/compiler.pir:
> 29)
> called from Sub '_main' pc 474 (src/tclsh.pir:185)
> rogers@rgrjr>
>
Fixed in r13696. This now generates a 94-line PIR sub.
> But I also notice that I can't run "make test" on Tcl because
> "prove" is
> not on my path. I am using Perl 5.8.1, which is rather old, but not
> that old, so maybe this is some quirk of the stock SuSE 9.0
> configuration?
We're in the middle of converting tcl's test suite over from using
perl to being self-hosting in tcl, and the combination of a parrot
shebang and the parrot-style harness was blowing up. prove doesn't
have this problem. (try perl t/harness t/*.t - you'll see lots of
failures that don't happen with prove at the moment.)
In the meantime, just run an individual test - e.g. "perl t/
cmd_append.t" - perl will automatically handle the shebang (even if
your OS doesn't), and you can run either style test in this fashion.
Bob Rogers
Date: Mon, 31 Jul 2006 05:11:23 -0400
On Jul 30, 2006, at 3:55 PM, Bob Rogers wrote:
> This doesn't work for me, even in a freshly-built (though somewhat
> hacked) r13655:
>
> rogers@rgrjr> ../../parrot tcl.pbc --pir -e 'set a [list a b]; set
> a b'
> too many arguments passed (3) - 2 params expected
> current instr.: 'compile' pc 19796 (languages/tcl/src/compiler.pir:
> 29)
> called from Sub '_main' pc 474 (src/tclsh.pir:185)
> rogers@rgrjr>
Fixed in r13696. This now generates a 94-line PIR sub.
In r13715, I get the following when I try to "make" in languages/tcl:
make: *** No rule to make target `runtime/builtin/set.pir', needed by `runtime/builtins.pir'. Stop.
This was after "make realclean", "svn up", and rebuilding Parrot at the
top level. Do I need a bigger hammer?
I also took the liberty of checking in a change to MANIFEST to drop
languages/tcl/runtime/builtin/set.pir, since Configure.pl complained and
it had been deleted. Was that premature?
-- Bob
Will Coleda
Your timing is impeccable ^_^. Thanks for the MANIFEST fix. Try
upping again, the tcl makefile should be ok. (need to re Configure.pl
to regen the makefile in tcl)
... And thank you for your patience. Tcl has had a lot of commits in
the past week or so, it's been a tad bumpy. =-)
... And in the time it's taken to get this far, we've changed how
we're invoking [set] during the compile phase, so we're up to 196
lines (more inlining in :main)
Regards.
Bob Rogers
Date: Mon, 31 Jul 2006 20:48:06 -0400
On Jul 31, 2006, at 8:13 PM, Bob Rogers wrote:
>
> make: *** No rule to make target `runtime/builtin/set.pir', needed
> by `runtime/builtins.pir'. Stop.
Your timing is impeccable ^_^. Thanks for the MANIFEST fix.
Just my luck. No problem.
Try upping again, the tcl makefile should be ok. (need to re
Configure.pl to regen the makefile in tcl)
Great; it works for me now.
... And thank you for your patience. Tcl has had a lot of commits in
the past week or so, it's been a tad bumpy. =-)
Again, no problem; I know how it feels.
... And in the time it's taken to get this far, we've changed how
we're invoking [set] during the compile phase, so we're up to 196
lines (more inlining in :main)
Actually, I'm getting 153 lines . . . but I'm afraid I can't follow it,
and am out of time to study it. I was hoping something would jump out
at me. Sorry . . .
-- Bob
Bob Rogers
was deficient), and, on a hunch, made the tweak shown below, with the
following result:
rogers@rgrjr> ../../parrot tcl.pbc -e 'set a [list a b]; set x $a; set a b; puts $a; puts $x'
b
a b
rogers@rgrjr>
This tweak may break other stuff (I didn't check), so take it with a
grain of salt. However, this may be a hint that you are better off
using PMCs as values rather than as containers. HTH,
-- Bob Rogers
http://rgrjr.dyndns.org/
------------------------------------------------------------------------
Index: runtime/variables.pir
===================================================================
--- runtime/variables.pir (revision 13852)
+++ runtime/variables.pir (working copy)
@@ -227,6 +227,7 @@
.local pmc scalar
null scalar
scalar = __find_var(name)
+ goto create_scalar
if_null scalar, create_scalar
assign scalar, value
goto return_scalar
Matt Diephouse
> I finally found the definition of __set (my tagfile-building recipe
> was deficient), and, on a hunch, made the tweak shown below, with the
> following result:
>
> rogers@rgrjr> ../../parrot tcl.pbc -e 'set a [list a b]; set x $a; set a b; puts $a; puts $x'
> b
> a b
> rogers@rgrjr>
>
> This tweak may break other stuff (I didn't check), so take it with a
> grain of salt. However, this may be a hint that you are better off
> using PMCs as values rather than as containers. HTH,
assign opcode. This fixes this error, but causes a handful of other
ones.
AFAICT, we have to use assign so that we don't break aliasing (which
is rather important). If you have the same variable in two different
scopes -- or under two different names -- merely replacing one of
those variables with a new PMC (using PMCs as values) won't change the
other variable. You have to use assign to morph the PMC into the new
type. Among other things, this will break Tcl's [global] and
[variable] commands and it isn't really a viable solution.
PMCs *are* containers; they're designed that way.
This leaves two options:
1) Fixing the set_pmc vtable method for TclList and/or
ResizablePMCArray and FixedPMCArray
2) Using a hybrid list/string PMC that behaves in a similar way to
Perl 5's scalars
Option 1 is preferable, IMO, if it's doable. But it's a little out of
my reach as far as C goes, unfortunately. Otherwise I'd have fixed it
already. :-)
Thanks for taking a look at this.
--
Matt Diephouse
http://matt.diephouse.com
Bob Rogers
Date: Sat, 5 Aug 2006 01:22:49 -0400
Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
>
> This tweak may break other stuff (I didn't check), so take it with a
> grain of salt. However, this may be a hint that you are better off
> using PMCs as values rather than as containers. HTH,
Right. So what you did was change Tcl so that we no longer use the
assign opcode. This fixes this error, but causes a handful of other
ones.
I'm not surprised.
AFAICT, we have to use assign so that we don't break aliasing (which
is rather important). If you have the same variable in two different
scopes -- or under two different names -- merely replacing one of
those variables with a new PMC (using PMCs as values) won't change the
other variable. You have to use assign to morph the PMC into the new
type. Among other things, this will break Tcl's [global] and
[variable] commands and it isn't really a viable solution.
PMCs *are* containers; they're designed that way.
Not necessarily . . .
This leaves two options:
1) Fixing the set_pmc vtable method for TclList and/or
ResizablePMCArray and FixedPMCArray
2) Using a hybrid list/string PMC that behaves in a similar way to
Perl 5's scalars
Option 1 is preferable, IMO, if it's doable. But it's a little out of
my reach as far as C goes, unfortunately. Otherwise I'd have fixed it
already. :-)
FWIW, the Common Lisp system I'm writing takes a third tack. It defines
a ParrotObject container associated with the name that refers indirectly
to the current value. Of course, Common Lisp "symbol" objects are part
of the language spec (and aliasing is not), so I have to at least make
it look like I'm doing it this way. But indirection still seems more
natural than morphing -- I don't have to worry about whether morphing
will produce unintended side-effects. And the best thing is that I can
do it all in PIR and Lisp.
So when I said "using PMCs as values rather than as containers," I
really meant to suggest separating the container from the value. But I
have no clue whether this would be easier than the other options.
Thanks for taking a look at this.
No problem; thanks for giving me an excuse to take a look at how Tcl
works.
-- Bob
Matt Diephouse
> FWIW, the Common Lisp system I'm writing takes a third tack. It defines
> a ParrotObject container associated with the name that refers indirectly
> to the current value. Of course, Common Lisp "symbol" objects are part
> of the language spec (and aliasing is not), so I have to at least make
> it look like I'm doing it this way. But indirection still seems more
> natural than morphing -- I don't have to worry about whether morphing
> will produce unintended side-effects. And the best thing is that I can
> do it all in PIR and Lisp.
>
> So when I said "using PMCs as values rather than as containers," I
> really meant to suggest separating the container from the value. But I
> have no clue whether this would be easier than the other options.
but it does work. Technically, any time we use something other than a
TclString PMC it's an optimization.
After looking at the code in the Array, Scalar, and String PMCs, I've
managed to get things working to my satisfaction using an
iterate-and-copy method for array-like objects and morphing for
Strings (and soon for other types as well).
So if anyone ever finds himself or herself in the same position, a
look at TclList's (languages/tcl/src/pmc/tcllist.pmc) assign_pmc
method would probably be in order.