On Tue, Nov 30, 2010 at 10:52 AM, Dag Sverre Seljebotn <[email protected]> wrote: > 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.
Very cool. I'm completely fine with relying on this library (bundled with Python) for our use. The only downside is that documentation seems a bit sparse, but I'm sure we can figure it out. > At any rate, it seems tempting to just make Cython cdef closures simply > be libffi closures. Yep. This would give a nice way to get bound cdef methods as well (though I could see value in being able to go back to the unbound version, not sure how easy that would be). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
