should push (etc) be available via extend.h ?

[Nicholas Clark]

Should There be a Parrot_PMC_push_pmc() [and friends?] in extend.h to allow
parrot-extending code direct access to those vtable methods?

Eventually, should extend.h contain methods to make calls on all public vtable
methods?

Nicholas Clark

[Leopold Toetsch]

Yep. Think so. But note that all "vtables" denoted MMD_ aren't vtable
functions.

And should they eventually even be autogenerated ;)

> Nicholas Clark

leo

[Nicholas Clark]

On Tue, May 03, 2005 at 02:55:22PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> >Should There be a Parrot_PMC_push_pmc() [and friends?] in extend.h to allow
> >parrot-extending code direct access to those vtable methods?
> >
> >Eventually, should extend.h contain methods to make calls on all public
> >vtable
> >methods?
>
> Yep. Think so. But note that all "vtables" denoted MMD_ aren't vtable
> functions.

I added 4 push variants to extend.h and extend.c

> And should they eventually even be autogenerated ;)

Now, that bit I agree with. A task for someone who likes writing perl?

Nicholas Clark

[Chromatic]

On Tue, 2005-05-03 at 14:48 +0100, Nicholas Clark wrote:

> > And should they eventually even be autogenerated ;)
> Now, that bit I agree with. A task for someone who likes writing perl?

I like writing Perl. Where can I find the source information, where
should I write it, and how should it look?

-- c

[Nicholas Clark]

I don't know the full spec for the task. What I do know is that there are many
vtable methods, defined in vtable.tbl, accessible via Parrot::Vtable, and for
all the appropriate ones, a C wrapper would be useful. Currently they're
prototyped in include/parrot/extend.h and defined in src/extend.c. Those two
files also contain prototypes and definitions for some other non-vtable
functions useful to extenders. I assume that if the C wrappers are
autogenerated, then than would mean a new 100% autogenerated header file
#included by "parrot/extend.h", and a new C file, leaving just the other
non-vtable functions in the existing 2 files.

I don't know what the list of appropriate functions to wrap is. I assume that
Leo/Chip can make a definitive criteria, but I'm guessing that it could be
most vtable methods except for the MMD ones, given what Leo has already
said.

For example, vtable.tbl defines:

INTVAL get_integer_keyed_int(INTVAL key)

The C code that wrap this is:

/*

=item C<Parrot_Int
Parrot_PMC_get_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc,
Parrot_Int key)>

Return the keyed, signed integer value of the value in the PMC.

=cut

*/

Parrot_Int Parrot_PMC_get_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc, Parrot_Int key) {
Parrot_Int retval;
PARROT_CALLIN_START(interp);
retval = VTABLE_get_integer_keyed_int(interp, pmc, key);
PARROT_CALLIN_END(interp);
return retval;
}

and looks like it can be autogenerated fairly easily from the parameter types
and return type declared in vtable.tbl, *except* for that choice of
name. Should we be regularising the C wrappers to have the same names as the
vtable entries?
ie s/Parrot_PMC_get_intval_intkey/Parrot_PMC_get_integer_keyed_int/
and similarly for quite a few other functions in extend.c?

Nicholas Clark

[Chromatic]

On Tue, 2005-05-03 at 22:36 +0100, Nicholas Clark wrote:

> I don't know what the list of appropriate functions to wrap is. I assume that
> Leo/Chip can make a definitive criteria, but I'm guessing that it could be
> most vtable methods except for the MMD ones, given what Leo has already
> said.

Seems reasonable to me. I have a short program now based on
Parrot::Vtable that dumps out really naive functions.

void init_pmc(PMC* initializer)

becomes:

void Parrot_PMC_init_pmc( Parrot_INTERP interp, Parrot_PMC pmc,
Parrot_PMC initializer )
{
void retval;
PARROT_CALLIN_START( interp );
retval = VTABLE_init_pmc( interp, pmc, initializer );
PARROT_CALLIN_END( interp );
return retval;
}

I'll make it keep the other functions in extend.c and see what happens.

> Should we be regularising the C wrappers to have the same names as the
> vtable entries?

Seems reasonable to me.

> ie s/Parrot_PMC_get_intval_intkey/Parrot_PMC_get_integer_keyed_int/
> and similarly for quite a few other functions in extend.c?

I can make a patch that does this if it's valuable.

-- c