Re: should push (etc) be available via extend.h ?
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
should push (etc) be available via extend.h ?
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
Re: should push (etc) be available via extend.h ?
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. And should they eventually even be autogenerated ;) Nicholas Clark leo
Re: should push (etc) be available via extend.h ?
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
Re: should push (etc) be available via extend.h ?
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
Re: should push (etc) be available via extend.h ?
On Tue, May 03, 2005 at 10:35:50AM -0700, chromatic wrote:
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?
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 CParrot_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
