Parrot extensions, or PMC versatility
Darren Duncan
P.S. Please CC any replies to dar...@DarrenDuncan.net as I'm not subscribed to this mailing list.
For background, I am currently building a comprehensive database abstraction framework in pure Perl 5 (search on CPAN for 'Rosetta') which I believe is granular or low-level enough that I should also be doing a compiled C version of it before too long. While I like to think I write efficient (or at least easy to maintain) Perl, I suspect that a compiled version would be necessary to get really good performance for the amount of data I would be processing.
Probably another good reason is to remove a lot of extra layers between my code and the actual compiled database-specific drivers; for one thing, if the drivers normally take SQL and would be parsing it into objects prior to making requests from the db server (rather than the db server doing the parsing), then the use of SQL can be skipped entirely, as I don't have to generate it just for it to be parsed again.
Reasoning is similar as to why the likes of LIBXML or DBI are mostly compiled.
I decided that I shouldn't waste my time with the Perl 5 XS system and go straight to using the corresponding Parrot extension mechanism instead. Partly this is because the latter should be more mature by the time I am ready to write the C, and also because it should be a lot better designed and a joy to work with than XS.
So, some questions:
1. Are PMCs being designed such that compiled Parrot extensions should be using them for all their internal operations where possible, or is it more likely that an extension writer should be using their own structs for most internal operations, and save PMCs mainly for the parts of their code that interface with the Parrot core? Basically, I like that using PMCs internally should save me a lot of work and make writing C more like writing Perl (high-level data structures like sparse arrays and hashes), but I'm concerned whether or not they would use a lot more overhead in resources than would be 'good'.
2. On a related note, if I wanted to implement Rosetta as a standalone C library (like LIBXML) which has Parrot/Perl bindings rather than being designed exclusively as a Parrot extension (should I, *sacrilege*, want it possible to use the library with non-Parrot, eg compiled, applications), is it reasonable to use PMCs as a set of pre-declared data types that are good for use on their own, apart from the Parrot runtime? Of course, I still plan for this library to work on any platform that Parrot does. (Heck, if it hasn't already been done, this setting PMCs free thing could be its own thread.)
3. If it's reasonable to ask, how soon (or how long ago) do you think that Parrot and its official extension interface would stabilize enough that one could start using it in a major way without constant compatability rewrites? (Not that I would be ready for months anyway.) On the other hand, would it actually be helpful for me to write to the current version anyway, as it might help expose deficiencies that would otherwise not show up 'til later?
4. I'm also interested on documentation for writing Parrot extensions, as well as making bindings to the various languages that compile to Parrot bytecode. However, I won't make that an official request as I should RTFM first, so I will do some online searches in the mean time.
Thanks in advance for any answers. -- Darren Duncan
P.S. Please CC any replies to dar...@DarrenDuncan.net as I'm not subscribed to this mailing list.
Benjamin Goldberg
[snip]
> I decided that I shouldn't waste my time with the Perl 5 XS system and
> go straight to using the corresponding Parrot extension mechanism
> instead. Partly this is because the latter should be more mature by
> the time I am ready to write the C, and also because it should be a
> lot better designed and a joy to work with than XS.
Even after perl6 is done and fully released, there will still be many,
many people writing perl5 code.
ISTM that you should write Rosetta as a standalone C library, with perl5
*and* perl6 bindings.
XS isn't *that* horrible -- especially if you design an interface to
your library in such a way that h2xs can convert it without trouble into
something that can be used without further modifications. (In which
case, you don't even need to look at the XS)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Dan Sugalski
>I have a question, and sorry if it is redundant. (I can't seem to
>find a search function on http://archive.develooper.com like I
>thought used to be there.)
Google's got the list, though I don't remember off-hand how to
restrict google searches by URL. (Though it's possible, IIRC)
>So, some questions:
>
>1. Are PMCs being designed such that compiled Parrot extensions
>should be using them for all their internal operations where
>possible, or is it more likely that an extension writer should be
>using their own structs for most internal operations, and save PMCs
>mainly for the parts of their code that interface with the Parrot
>core? Basically, I like that using PMCs internally should save me a
>lot of work and make writing C more like writing Perl (high-level
>data structures like sparse arrays and hashes), but I'm concerned
>whether or not they would use a lot more overhead in resources than
>would be 'good'.
PMCs are mainly for data representation. If you've some sort of data
thingie, hang the functions it should express off a PMC class, though
this can be somewhat limiting if you have other functions. Presumably
those would go in the library somewhere.
>2. On a related note, if I wanted to implement Rosetta as a
>standalone C library (like LIBXML) which has Parrot/Perl bindings
>rather than being designed exclusively as a Parrot extension (should
>I, *sacrilege*, want it possible to use the library with non-Parrot,
>eg compiled, applications), is it reasonable to use PMCs as a set of
>pre-declared data types that are good for use on their own, apart
>from the Parrot runtime? Of course, I still plan for this library
>to work on any platform that Parrot does. (Heck, if it hasn't
>already been done, this setting PMCs free thing could be its own
>thread.)
That one's dodgier. PMCs depend on the core of parrot, and teasing
them out is something I'd expect to be fairly non-trivial. Doable,
certainly, as long as your PMC code didn't actually depend on
anything in the parrot core, but it's tough to work without
allocating any memory. :)
Still, a PMC is just a smallish structure with a table of function
pointers hanging off it. If you could work out a way to allocate the
PMC header, vtable body, and then use only functions that didn't
reference anything in the core, it'd be doable.
>3. If it's reasonable to ask, how soon (or how long ago) do you
>think that Parrot and its official extension interface would
>stabilize enough that one could start using it in a major way
>without constant compatability rewrites? (Not that I would be ready
>for months anyway.) On the other hand, would it actually be helpful
>for me to write to the current version anyway, as it might help
>expose deficiencies that would otherwise not show up 'til later?
It's reasonable to ask. I'm not sure what the reasonable answer is, but... :)
The sane thing to do would be to define the loading mechanism, which
is small, and then start defining the functions Parrot exports and
get that done incrementally.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk