On Wed, Feb 17, 2010 at 7:27 AM, NotFound <[email protected]> wrote: >> * parrot core should only contain the minimum necessary to run and be >> extended > > 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.
The 2 major ways to extend parrot, dynpmcs and dynops, already need a C compiler. For machines without a C compiler, there must be a C compiler somewhere or else you wouldn't have parrot. Additional static signatures would not be difficult to add at parrot's compile time - modify call_list.txt, regenerate src/nci.c, and recompile (what we have now btw). But static signatures have a cost of requiring the interpreter to haul around a hash (~400 elements) of thunks that are hardly ever used. These bloat both the gc pool and the code size. For users that don't need it, why have it? > 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. perl5 extensions would be great at this point. Our nci system doesn't even have that yet. There's an important point to perl5 extensions that we're lacking - a boilerplate generator. And that's what nativecall.pir provides. >> * 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. A number of people seem to believe that this better way is a runtime thunk generator. That won't work everywhere. There will always be some architecture to which whatever ffi library you use has not yet been ported. That's not to say that a runtime thunk mechanism isn't worthwhile, just that it excludes potential platforms. We should provide a way that is fully generic, if a bit cumbersome for some. > 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 mis-characterizes what NCI in parrot is right now. NCI in parrot currently only works for a narrow set of libraries that have been registered in config/gen/call_list/misc.in. If the library you want isn't there, and you've created bindings that "work", they only work by accident. And the set of currently supported signatures isn't that great either. I initially got into the nci system because I was trying to embed parrot and a simple 3 argument signature I was trying to use wasn't supported. I could have added my project and associated signatures to config/gen/call_list/misc.in and been on my merry way, but that's a band-aid solution. Whether we should call this a native call interface or not doesn't really matter to me. If it doesn't do what people expect an nci system to do, we could just as easily call it something else so people don't get any misleading expectations. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
