[svn ci] NCI methods now name-mangled

0 views
Skip to first unread message

Jonathan Worthington

unread,
Apr 3, 2007, 8:33:59 PM4/3/07
to parrot-...@perl.org
Hi,

I was working on starting to move class functionality into v-table
methods, as discussed on list recently. However, I hit an interesting
issue - you cannot have a METHOD or PCCMETHOD with the same name as a
vtable method. We need to be able to do that to implement the interface
specified in PDD15, though.

As of r17967, instead of turning any non-vtable method to:

Parrot_CLASSNAME_METHODNAME

Which could conflict with the vtable method, pmc2c now generates:

Parrot_CLASSNAME_nci_METHODNAME

I had to fix a couple of bits of code that directly called such methods,
but some of them had "this is evil and needs fixing" comments above them
anyway. (Since calling a method directly like this ignores inheritance,
it's generally the wrong thing to do.) The Complex PMC was the only PMC
that needed changing to get Parrot building again after the change.
Therefore I expect the impact of this change will be small.

Anyway, hope this is agreeable, and please do report any issues.

Thanks,

Jonathan

Francois Perrad

unread,
Apr 4, 2007, 2:02:13 PM4/4/07
to Jonathan Worthington, parrot-...@perl.org

This new behavior breaks the build of Lua PMC.

in languages/lua/pmc/luastring.pmc
#line 295
PMC* add (PMC* value, PMC* dest) {
MMD_LuaNumber: {
PMC* n = SELF.tonumber();
if (n->vtable->base_type == dynpmc_LuaNumber) {

in languages/lua/pmc/pmc_luastring.h (generated correct)
#line 109
PARROT_DYNEXT_EXPORT extern PMC* Parrot_LuaString_nci_tonumber(Interp *, PMC*);

in languages/lua/pmc/luastring.c (generated NOT CORRECT)
#line 172 "luastring.c"
PMC*
Parrot_LuaString_add_LuaNumber(Interp *interp, PMC* pmc, PMC* value, PMC* dest)
{
PMC* n = Parrot_LuaString_tonumber(interp, pmc); // need
_nci_ !!!
if (n->vtable->base_type == dynpmc_LuaNumber) {

Regards.

François.

>Thanks,
>
>Jonathan
>
>


Allison Randal

unread,
Apr 4, 2007, 5:52:58 PM4/4/07
to François PERRAD, Jonathan Worthington, parrot-...@perl.org
François PERRAD wrote:
>>
>> Anyway, hope this is agreeable, and please do report any issues.
>
> This new behavior breaks the build of Lua PMC.

For me too, even after a 'make realclean' on Parrot. In the interests of
our developing policy on a stable trunk: Jonathan, fix the problem for
Lua or revert the change before continuing with further development.

Thanks!
Allison

Allison Randal

unread,
Apr 4, 2007, 5:59:09 PM4/4/07
to Jonathan Worthington, parrot-...@perl.org
Jonathan Worthington wrote:
> Hi,
>
> I was working on starting to move class functionality into v-table
> methods, as discussed on list recently. However, I hit an interesting
> issue - you cannot have a METHOD or PCCMETHOD with the same name as a
> vtable method. We need to be able to do that to implement the interface
> specified in PDD15, though.
>
> As of r17967, instead of turning any non-vtable method to:
>
> Parrot_CLASSNAME_METHODNAME
>
> Which could conflict with the vtable method, pmc2c now generates:
>
> Parrot_CLASSNAME_nci_METHODNAME

This is a leftover from the old days when the way to override a vtable
method was to define a method with an '__' name, so they never
conflicted. I expect this assumption will need to be rooted out in
several other places as well, so its worth a thorough review for the PMC
PDD. This is a good enough fix in the meantime. (After Lua is working.)

Allison

Jonathan Worthington

unread,
Apr 4, 2007, 5:10:48 PM4/4/07
to François PERRAD, parrot-...@perl.org
François PERRAD wrote:
> This new behavior breaks the build of Lua PMC.
Argh, sorry. :-( Thanks for the detailed bug report - I know where the
problem is, and am working on a fix.

Jonathan

Jonathan Worthington

unread,
Apr 4, 2007, 6:39:03 PM4/4/07
to Allison Randal, François PERRAD, parrot-...@perl.org
Allison Randal wrote:
> For me too, even after a 'make realclean' on Parrot. In the interests
> of our developing policy on a stable trunk: Jonathan, fix the problem
> for Lua or revert the change before continuing with further development.
Don't really need a policy to tell me that breaking stuff for languages
folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
through the net occasionally. In this case, I wasn't even aware that you
could use SELF.meth(...) to call non-vtable methods, and it's done
nowhere in core PMCs or I'd have noticed it.

Anyway, fixed in r17982. May need a realclean - I had to do one anyway
to run the buildtools tests.

Thanks,

Jonathan

Jonathan Worthington

unread,
Apr 4, 2007, 6:54:05 PM4/4/07
to Allison Randal, parrot-...@perl.org
Allison Randal wrote:
> This is a leftover from the old days when the way to override a vtable
> method was to define a method with an '__' name, so they never
> conflicted.
Not really - this was a conflict in the names of the methods at a C
level. The '__' prefix was a PIR-level thing. In PIR we may have moved
away from using name mangling to prevent the conflict, but in C that's
probably all we've got at our disposal. Note that name of method at a C
level and name of the method for method lookups do not have to be at all
related.

> I expect this assumption will need to be rooted out in several other
> places as well, so its worth a thorough review for the PMC PDD.

Sure, I'm sure there's more than one way to deal with this issue, but
for now this works and unblocks stuff.

Thanks,

Jonathan

Allison Randal

unread,
Apr 4, 2007, 8:59:42 PM4/4/07
to Jonathan Worthington, François PERRAD, parrot-...@perl.org
Jonathan Worthington wrote:
>
> Anyway, fixed in r17982. May need a realclean - I had to do one anyway
> to run the buildtools tests.

Awesome. Works for me even without realclean.

Thanks!
Allison

Leopold Toetsch

unread,
Apr 5, 2007, 6:45:22 PM4/5/07
to perl6-i...@perl.org, Jonathan Worthington, Allison Randal, François PERRAD, parrot-...@perl.org
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington:
> Don't really need a policy to tell me that breaking stuff for languages
> folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
> through the net occasionally. In this case, I wasn't even aware that you
> could use SELF.meth(...) to call non-vtable methods, and it's done
> nowhere in core PMCs or I'd have noticed it.

This could be also read as a notice to language maintainers:

If you are using some "features" of parrot, then please, please submit a core
test for it, if such a test doesn't exist yet. This will help Parrot and You
in the future ...

Thanks.
leo

Joshua Isom

unread,
Apr 6, 2007, 3:58:38 AM4/6/07
to Leopold Toetsch, Perl 6 Internals, p2

Not only to language maintainers, but anyone using parrot where a
"feature" isn't tested. And it also technically falls on whoever
implemented said "feature" in parrot, for not adding a test.

What if we had a repository, ala pugs with it's "open" commits, solely
for people to commit tests. It could help improve bug discovery and
test coverage, as well as ambiguity about features in parrot. Then
developers could just update it and run it seperately(and check it to
make sure nothing malicious gets through which is always a potential of
course).

Chromatic

unread,
Apr 6, 2007, 12:48:26 PM4/6/07
to perl6-i...@perl.org, Joshua Isom, Leopold Toetsch, p2
On Friday 06 April 2007 00:58, Joshua Isom wrote:

> What if we had a repository, ala pugs with it's "open" commits, solely
> for people to commit tests.  It could help improve bug discovery and
> test coverage, as well as ambiguity about features in parrot.  Then
> developers could just update it and run it seperately(and check it to
> make sure nothing malicious gets through which is always a potential of
> course).

Is that a big convenience over mailing patches to the list or nopasting them
for IRC such that people who won't do either of those will happily commit
them?

Are the specifications good and complete enough that tests can be
unambiguously correct?

Who will merge these tests into the standard tree?

Just looking for more information,
-- c

Joshua Isom

unread,
Apr 6, 2007, 5:05:48 PM4/6/07
to chromatic, Perl 6 Internals

On Apr 6, 2007, at 11:48 AM, chromatic wrote:

> On Friday 06 April 2007 00:58, Joshua Isom wrote:
>
>> What if we had a repository, ala pugs with it's "open" commits, solely
>> for people to commit tests.  It could help improve bug discovery and
>> test coverage, as well as ambiguity about features in parrot.  Then
>> developers could just update it and run it seperately(and check it to
>> make sure nothing malicious gets through which is always a potential
>> of
>> course).
>
> Is that a big convenience over mailing patches to the list or
> nopasting them
> for IRC such that people who won't do either of those will happily
> commit
> them?
>

It would add a convenience if we had a web form that just listed what
testing method, the input, and the output for example. If it's
promoted on the main page or somewhere on the site, then someone
wouldn't have the join the list(which they may not want to do for some
reason), or they may not have an irc client. I never really used an
irc client before I started joining #parrot. I was working with parrot
a couple months before I ever joined.

> Are the specifications good and complete enough that tests can be
> unambiguously correct?
>

Reading over a pdd isn't the same as writing code based on that pdd.
Something the ambiguoity isn't intentional and was just missed. Plus
if they're random user tests, we should consider that it might not be
accurate.

> Who will merge these tests into the standard tree?
>

Who merges patches sent to the list into the standard tree? In my
experience, it's almost anyone.

Reply all
Reply to author
Forward
0 new messages