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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
