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
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
> 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'
> 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
> 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
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
> 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.
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
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.
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
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
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 <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
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.