On Fri, 13 Aug 2004 16:40:12 -0400 Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:24 AM -0700 8/13/04, Michel Pelletier wrote:
> >I've been developing Parakeet on a month old Parrot build, so today I
> >decided to update to a recent checkout, and Parakeet broke two ways.
> >
> >The first is multi-inheritance stopped working, but that's not as big
> >a deal as the new problem.
>
> Gack -- it's a very big deal, and the test suite should've picked
> that up. D'you have a code snippet that demonstrates it, so we can
> fix the problem and get a test to help keep it happening in the
> future?
I should have been more clear, *Parakeet* multi-inheritance breaks, I
have no proof that Parrot's is broke, or it just changed out from under
me the way I'm using it. I'll try to come up with a simple test case
tonight. Here's where it breaks in Parakeet:
class C
extends A
meth testMethod 2 end
end
C new var c
c -> testMethod println # prints 2
# another for multi-inheritance
class X
meth xciting "exciting!" end
end
# multi-inheritance
class D
extends C
extends X
end
D new var d
d -> testMethod println
d -> xciting println # seg-faults here after printing "exciting!"
I ran into a seg-fault in the same place a couple weeks ago on my old
build, but fixed it because each of my compiled functions and methods
included my "macros.imc" file, which I didn't realize was totally
redundant (I figured every use of the compile opcode started with a
fresh compiler state, but I guess that's not the case, thank God).
So speaking of pathalogical test cases, un-comment the last two lines of
the following example to seg-fault (note that my macros.imc file, which
I attached, is, weird).
.sub _main @MAIN
.local pmc pir
.local pmc mysub
compreg pir, "PIR"
newclass $P0, "one"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"one\"]\n"
newclass $P1, "two"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"two\"]\n"
newclass $P2, "three"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"three\"]\n"
newclass $P3, "four"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"four\"]\n"
newclass $P4, "five"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"five\"]\n"
newclass $P5, "six"
compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"six\"]\n"
# uncomment to seg-fault
# newclass $P6, "seven"
# compile mysub, pir, ".include \"cruft/macros.imc\"\n.namespace[\"seven\"]\n"
.end
Include my macros.imc file more than seven times and boom.
> >Print a prompt, read a line, print the line, print the prompt, a
> >simplification of Parakeet's interpreter loop. it works on a month
> >old parrot checkout just fine, but on a checkout done this afternoon
> >it prints the prompt *after* it reads the line.
>
> This one looks like an autoflush problem.
That was my first guess too.
> I don't think we've ever
> formally defined what happens when you don't set the autoflush
> properties of filehandles,and I think some of Leo's IO optimizations
> for the piethon are causing a problem here. Doesn't look like we've
> defined how to set autoflushing for filehandles, so we'd best go do
> that.
Hmm, I'm suprised this didn't break a lot more stuff since it's just a
simple input to output loop one would find about anywhere. Well, I'll
wait for the configurable autoflush features and step back to the old
build for now.
-Michel
macros.imc
Description: Binary data
