Another Perl Task: review PMC compiler

0 views
Skip to first unread message

Leopold Toetsch

unread,
Mar 22, 2005, 9:27:32 AM3/22/05
to Perl 6 Internals
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

unread,
Mar 25, 2005, 2:33:35 AM3/25/05
to Leopold Toetsch, Perl 6 Internals
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

unread,
Mar 25, 2005, 5:31:58 AM3/25/05
to ma...@diephouse.com, perl6-i...@perl.org
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

unread,
Mar 25, 2005, 5:48:21 AM3/25/05
to Leopold Toetsch, ma...@diephouse.com, perl6-i...@perl.org

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

unread,
Mar 25, 2005, 8:12:51 AM3/25/05
to Peter Sinnott, perl6-i...@perl.org
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

Reply all
Reply to author
Forward
0 new messages