In the last weeks, I have been looking into dynamic PMCs in Parrot. They are not very different from Parrot core PMCs.Users just have to look up the dynamic ID, before they can create a instance.
As an example I worked on the GDBMHash PMC. This is a binding the GNU dbm, a file dictionary. The basic implementation was straightforward. The configuration is somewhat akward. I need to check wether 'libgdbm.so' exists. Currently I have added this check to the core Parrot configuration. It would be nicer to have a seperate configuration step for Parrot extensions. It would be cool to do that in PIR, as Parrot already exists when extensions are added.
Looking back, using 'gdbm' for the example was propably not the best choice. Berkely DB seems to be much more widely used. As far as I remember, Bio::Index::Fasta is based on Berkeley DB.
A more interesting dynamic PMC would be access to Piddles.
Piddles are the basis data structure of the Perl Data languages,
Is there any reason the linking and library finding must happen at configuration and compile times? I wonder if you could punt and write a little bit of C code that hooks into NCI to do the linking and loading at runtime. Of course, being able to write dynamic PMCs in PIR would be even easier.
Re:C-level Linking
Bernhard on 2005-01-17T11:55:12
The primary reason is of course that this was the easiest to do. Doing the linking at runtime with NCI is propably possible, but I can't see a real advantage of that. It's nice to be able to do a simple
in order to see that things are well.ldd gdbmhash.soThe most important issue is that distribution to machines without C-compiler is possible. But this is simply a copy of gdbmhash.so to the target machine. When libgdm.so is not available, then gdbmhash.so can't be loaded. Which is a kind of runtime check.
