On Jun 10, 2009, at 6:06 PM, Ondrej Certik wrote: > On Sat, May 30, 2009 at 9:01 AM, Robert > Bradshaw<[email protected]> wrote: >> On May 30, 2009, at 12:23 AM, Stefan Behnel wrote: >> >>> Hi, >>> >>> sorry, was away for a while. >>> >>> Robert Bradshaw schrieb: >>>> On May 20, 2009, at 9:00 AM, Dag Sverre Seljebotn wrote: >>>> >>>>> It seems that there's now a danger of -unstable becoming the main >>>>> development branch; I also think the dangerous things are >>>>> completed >>>>> myself. If so, I think it should replace the current -devel. This >>>>> will >>>>> make a few tickets blockers for the next release though. >>>> >>>> If -unstable has stabilized, I think this makes sense. I >>>> envisioned - >>>> unstable as being for truly unstable things (e.g. closures, temp >>>> allocation rewrites) rather than the main development branch. >>> >>> Same from my side. There are a couple of regressions (failing >>> tests) in the >>> current -unstable that I couldn't easily fix right away. They need >>> some >>> more work before merging it back into -devel. BTW, I'd actually >>> go the >>> opposite way once that's done: merge -devel up into -unstable, drop >>> -devel >>> and rename -unstable. >> >> I'd like to see if there's any major fallout trying to compile sage >> with -unstable before we make the switch though, but assuming things >> aren't catastrophic, let's do that. >> >>> Regarding the -closures branch, IMHO it now works well enough to >>> merge it >>> into cython-unstable. I'd still be happy if others could give it >>> a try >>> first, maybe just run it on some Python code that uses nested >>> functions. >> >> I found an odd bug while demoing closures, so they're not ready yet, >> but I think they're close--certainly ready for other people to start >> trying them out. This is a feature that I would like people to really >> pound on before release. > > The closure branch didn't compile our project (Compiler crash in > GilCheck):
Thanks for the bug report. > for i in range(1, n + 1): > r *= i > return r > > cdef int a(int x): > cdef b(int n): > ^ > ------------------------------------------------------------ > > /home/ondrej/repos/cython-test/fact.pyx:10:17: C function definition > not allowed here > > I guess there is no way to make this work in C, right? Because I could > then pass the pointer to the function "b" to some external C program > and that function still needs to access my outer scope. A closure is more than just an function, it's a function with context (i.e. the x from the outer scope can be accessed). It's unclear what type "b" would have as a cdef function--wouldn't be impossible to do some mangling to make this appear to work in many cases (e.g. it could be a struct with the context as one field and function pointer in another), but it wouldn't be a (PyObject*)(int) for sure. C just doesn't have the concept of "bound" methods. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
