On Wed, Feb 17, 2010 at 11:06 AM, Andrew Whitworth <[email protected]> wrote: > 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.
As an aside, methods on C-based PMCs use NCI thunks, so unless you can shoehorn an API into vtables, you're no further ahead by trying to use PMCs in the current system. > 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. Seems like a good idea to me. I would be willing to do the (small amount) of work to make that happen. > 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. As I understand it, Lorito is supposed to be small. A decent FFI will need to implement at least a large chunk of the types your C compiler works with. Because of the increase in scope (and associated complexity) this causes, I'm not sure that we'd want to push native interfacing into Lorito. Maybe I'm mistaken, please enlighten me if I am (the vision for Lorito has always been a little hazy for me). _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
