On 11/30/2010 07:28 PM, Robert Bradshaw wrote: > On Tue, Nov 30, 2010 at 2:12 AM, Dag Sverre Seljebotn > <[email protected]> wrote: > >> On 11/30/2010 06:35 AM, Robert Bradshaw wrote: >> >>> On Mon, Nov 29, 2010 at 9:20 PM, Vitja Makarov<[email protected]> >>> wrote: >>> >>> >>>> 2010/11/30 Robert Bradshaw<[email protected]>: >>>> >>>> >>>>> On Mon, Nov 29, 2010 at 12:27 PM, Greg Ewing >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> Stefan Behnel wrote: >>>>>> >>>>>> >>>>>> >>>>>>> * it makes the inner C function directly callable, thus making it >>>>>>> easier to >>>>>>> implement things like cpdef functions and generators on top. >>>>>>> >>>>>>> >>>>>> If you mention the name of such a function without calling it, >>>>>> does it refer to the C function or the Python function? >>>>>> >>>>>> >>>>> That would depend on the context in which it's being used. >>>>> Essentially, the as_variable attribute would be set, allowing it to >>>>> coerce to a Python object if need be. >>>>> >>>>> >>>>> >>>> I see problem with closures here where should scope object be created >>>> in C function or in wrapper? >>>> >>>> >>> The only handle you can get of a closure object is a Python one. >>> (Well, eventually we want to have cdef closures, but we're not there >>> yet, and wouldn't be compatible with cdef functions--we'd probably >>> expose them as structs with a state and function pointer attributes.) >>> >>> >> Just for reference: Carl recently made me aware that ctypes contain some >> code to proxy Python functions to C function pointers. And apparently it >> contains a small compiler that creates new CPU code on demand for this. >> I'm not sure how well that would be exposed for our purposes, if it has >> a C API or not. (I haven't really looked at this myself.) >> >> Being able to create a closure in Cython and pass it as an ordinary C >> function callback, without having to manage the context manually, would >> be a really cool feature! And with such a mini-compiler it is possible. >> >> (Same idea applies to a concept of "pointer to bound cdef method") >> > Wow, that's a pretty interesting idea. Does this limit the > applicability to certain architectures? Of course even if the context > needs to be handled separately, we could make it easier than it is > now. >
Spending five more minutes on this, ctypes uses the libffi library (which is simply bundled with Python, although I haven't probed into whether this means it will always be available in a form we can link with). It appears to be very user-friendly, and has specific routines for creating C closures. Google it to see platform availability. Apparently closures are not available on every platform, but a grep through the source for FFI_CLOSURES seem to indicated that the "moxie", "m32r" and "m68k" platforms are the only ones without closure support. I can live with that :-) Looks to me like libffi lies at the core of a lot of FFI out there so that support is rather good. At any rate, it seems tempting to just make Cython cdef closures simply be libffi closures. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
