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):

$ make
[ 74%] Built target hermes2d-real
[ 75%] Cython source

Error converting Pyrex file to C:
------------------------------------------------------------
...
    ctypedef scalar (*BiFormFnVol)(RealFunction *fu, RealFunction *fv,
            RefMap *ru, RefMap *rv)

    ctypedef scalar (*LiFormFnVol)(RealFunction *fv, RefMap *rv)

    cdef BiFormFnVol BF_SYM = <BiFormFnVol> 1
                             ^
------------------------------------------------------------

/home/ondrej/repos/hermes2d/python/hermes2d/_hermes2d.pxd:110:30:
Compiler crash in GilCheck

ModuleNode.body = StatListNode(_hermes2d.pxd:1:0)
StatListNode.stats[5] = CDefExternNode(_hermes2d.pxd:31:5,
    include_file = 'hermes2d.h')
CDefExternNode.body = StatListNode(_hermes2d.pxd:34:4)
StatListNode.stats[5] = SingleAssignmentNode(_hermes2d.pxd:110:9)
SingleAssignmentNode.rhs = TypecastNode(_hermes2d.pxd:110:30)
File 'ExprNodes.py', line 4006, in gil_check: TypecastNode(_hermes2d.pxd:110:30)

Compiler crash traceback from this point on:
  File "/home/ondrej/usr/lib/python/Cython/Compiler/ExprNodes.py",
line 4007, in gil_check
    if self.type.is_pyobject and self.is_temp:
AttributeError: 'NoneType' object has no attribute 'is_pyobject'
make[2]: *** [python/hermes2d/_forms.cpp] Error 1
make[1]: *** [python/hermes2d/CMakeFiles/_forms.dir/all] Error 2
make: *** [all] Error 2



But otherwise this works:


cdef int a(int x):
    def b(int n):
        cdef int r
        r = x + n
        return r
    return b(3)

Just curious question -- if I apply this patch:

$ git diff
diff --git a/fact.pyx b/fact.pyx
index 0cadb8d..518d3ba 100644
--- a/fact.pyx
+++ b/fact.pyx
@@ -7,7 +7,7 @@ cdef int factorial(int n):
     return r

 cdef int a(int x):
-    def b(int n):
+    cdef b(int n):
         cdef int r
         r = x + n
         return r


cython will complain:

Error converting Pyrex file to C:
------------------------------------------------------------
...
    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.


Ondrej
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to