Another Perl Task: review PMC compiler

[Leopold Toetsch]

Investigating some recent dynclass/py*.t I found another problem in the
PMC compiler (classes/pmc2c2.pl, lib/Parrot/Pmc2c.pm).

On one computer I have in dynclasses/pylong.c temp_base_vtable

Parrot_default_destroy,

on the second I got:

Parrot_BigInt_destroy,

The latter is correct, as PyLong inherits from BigInt.

Seems to be another ordering problem, where a hash is used instead of an
array with inherited vtable methods. pylong.dump has already the wrong
entry:

'destroy' => 'default',

in the suoer hash.

Thanks,
leo

[Matt Diephouse]

Leopold Toetsch <l...@toetsch.at> wrote:
> Seems to be another ordering problem, where a hash is used instead of an
> array with inherited vtable methods. pylong.dump has already the wrong
> entry:
>
> 'destroy' => 'default',
>
> in the suoer hash.

I don't think it's an ordering problem (and I can say that now that
I've read all the code closely). 'default' isn't used when pmc2c2.pl
is searching for inherited vtable methods: it's only used when none of
the super classes contains a method by that name.

In this case, none of the super classes of PyLong has a destroy
method, so the default is used instead. I'd look at the PMCs involved
to make sure that all the details are right.

--
matt diephouse
http://matt.diephouse.com

[Leopold Toetsch]

Matt Diephouse <mdd...@gmail.com> wrote:
> Leopold Toetsch <l...@toetsch.at> wrote:
>> Seems to be another ordering problem, where a hash is used instead of an
>> array with inherited vtable methods. pylong.dump has already the wrong
>> entry:
>>
>> 'destroy' => 'default',
>>
>> in the suoer hash.

> I don't think it's an ordering problem (and I can say that now that
> I've read all the code closely). 'default' isn't used when pmc2c2.pl
> is searching for inherited vtable methods: it's only used when none of
> the super classes contains a method by that name.

pmclass PyLong extends BigInt dynpmc group python_group {
^^^^^^
void
Parrot_BigInt_destroy(Interp* interpreter, PMC* pmc)
{
...
Parrot_BigInt_destroy,

As the behavior is different on two of my machines, it still smells like
an hash-related ordering issue.

leo

[Peter Sinnott]

I had a quick look and things looked ok. The parents are stored in a
hash but they are retrieved sorted by their value which increments as
parents are added.
What was different between the 2 machines ( perl versions/os/whatever )?

Peter

--
Our mission is to continually administrate performance based resources
in order that we may authoritatively initiate value-added information for
100% customer satisfaction

[Leopold Toetsch]

Peter Sinnott <psinn...@aol.com> wrote:

> I had a quick look and things looked ok. The parents are stored in a
> hash but they are retrieved sorted by their value which increments as
> parents are added.
> What was different between the 2 machines ( perl versions/os/whatever )?

It's ok on:

$ uname -a
Linux thu8 2.2.16 #5 Thu Oct 12 20:07:01 CEST 2000 i686 unknown
$ cat /etc/SuSE-release
SuSE Linux 7.0 (i386)
$ perl -v

This is perl, v5.8.0 built for i686-linux-ld

and broken on:

$ uname -a
Linux giga 2.4.23-xfs #1 SMP Mi Dez 10 22:25:03 CET 2003 i686 GNU/Linux
$ cat /etc/debian_version
testing/unstable
$ perl -v

This is perl, v5.8.2 built for i386-linux-thread-multi

> Peter

leo