On Wed, Feb 17, 2010 at 7:27 AM, NotFound <[email protected]> wrote: > Be extended how? Generating and compiling C code is a big NO. That way > NCI is not native at all. It kills the posibility of installing pir > modules that use NCI in machines without a C compiler, forcing you to > use some development system and reinstall parrot or parts of it.
That's how Parrot is now, except when we want to add a new NCI signature we need to recompile all of Parrot. Because of the Perl5 dependency, it's actually harder to do this than just compile a shared library. Compilation of C code libraries is a chore, but it's only one option. Using libjit, libffi, or other libraries would make the process significantly easier in the future. These alternatives could be pluggable once the system is cleaned up and we remove static thunks. > And we don't need a native interface to do that, the extension can > just provide functions with signatures that parrot expects or > provides. Just like perl5 extensions. Now that's quite an interesting idea, but limiting. We need some kind of way to construct a call frame in order to provide a thin wrapper around an external library. If we create a more "thick" wrapper instead, such as a PMC class to wrap the interface, or a set of ops, we can do what you suggest. I don't like the idea of restricting what kinds of add-ons we can support, however. Some libraries don't lend themselves to being wrapped by a PMC or even a set of PMCs. >> * there will be a new, more flexible (IMHO better) way to get >> signature thunks for extenders/embedders > > Fine, but in that case let's keep the current way until we have that > other new way. As a middle-ground first step, howabout we break the non-necessary NCI signatures into a dynlib in the repo. That way we still have them in the repo if needed in the interim, we have a way to run tests on the mechanism locally, and we prepare for the larger refactors that Peter is suggesting. > I like to be able to access any public function in any dynamic library > of the system from pure pir, hand written or generated, without > compiling and installing anything, even with a parrot buit before that > library existed. That's what I believe a Native interface is. > Otherwise is just an extension mechanism. That's what we all want, but we cannot do that now. What we do now is really the worst possible solution, and making loadable libraries of NCI thunks is a huge improvement over that. In reality, we're probably not going to have proper dynamic native calls without one of two things: an existing dynamic interface (using libffi or libjit) or Lorito. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
