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
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
>
>
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
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
Anyway, fixed in r17982. May need a realclean - I had to do one anyway
to run the buildtools tests.
Thanks,
Jonathan
> 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
Awesome. Works for me even without realclean.
Thanks!
Allison
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
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).
> 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
> 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.