[Cython] Bug in Cython producing incorrect C code
Compiling the attached Cython file produced the attached C file which has errors in lines 532-534: __pyx_v_self->xx = None; __pyx_v_self->yy = None; __pyx_v_self->zz = None; There is no C symbol "None", so this doesn't compile. I first noticed the bug in Cython 0.15, but it's still in the latest revision from Github. Konrad. bug.pyx Description: Binary data bug.c.gz Description: GNU Zip compressed data ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
On 24 January 2012 11:37, Konrad Hinsen wrote: > Compiling the attached Cython file produced the attached C file which > has errors in lines 532-534: > > __pyx_v_self->xx = None; > __pyx_v_self->yy = None; > __pyx_v_self->zz = None; > > There is no C symbol "None", so this doesn't compile. > > I first noticed the bug in Cython 0.15, but it's still in the latest > revision from Github. > > Konrad. > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Hm, it seems the problem is that the call to the builtin float results in SimpleCallNode being replaced with PythonCApiNode, which then generates the result code, but the list of coerced nodes are CloneNodes of the original rhs, and CloneNode does not generate the result code of the original rhs (i.e. allocate and assign to a temp), which results in a None result. Maybe CascadedAssignmentNode should replace CloneNode.arg with the latest self.rhs in generate_assignment_code? I'm not entirely sure. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
2012/1/24 mark florisson : > On 24 January 2012 11:37, Konrad Hinsen wrote: >> Compiling the attached Cython file produced the attached C file which >> has errors in lines 532-534: >> >> __pyx_v_self->xx = None; >> __pyx_v_self->yy = None; >> __pyx_v_self->zz = None; >> >> There is no C symbol "None", so this doesn't compile. >> >> I first noticed the bug in Cython 0.15, but it's still in the latest >> revision from Github. >> >> Konrad. >> >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > Hm, it seems the problem is that the call to the builtin float results > in SimpleCallNode being replaced with PythonCApiNode, which then > generates the result code, but the list of coerced nodes are > CloneNodes of the original rhs, and CloneNode does not generate the > result code of the original rhs (i.e. allocate and assign to a temp), > which results in a None result. > > Maybe CascadedAssignmentNode should replace CloneNode.arg with the > latest self.rhs in generate_assignment_code? I'm not entirely sure. May be it's better to run OptimizeBuiltinCalls before AnalyseExpressionsTransform? I have a patch that initializes NameNode's entry at ControlFlowAnalysis stage. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov wrote: > 2012/1/24 mark florisson : >> On 24 January 2012 11:37, Konrad Hinsen wrote: >>> Compiling the attached Cython file produced the attached C file which >>> has errors in lines 532-534: >>> >>> __pyx_v_self->xx = None; >>> __pyx_v_self->yy = None; >>> __pyx_v_self->zz = None; >>> >>> There is no C symbol "None", so this doesn't compile. >>> >>> I first noticed the bug in Cython 0.15, but it's still in the latest >>> revision from Github. >>> >>> Konrad. >>> >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >>> >> >> Hm, it seems the problem is that the call to the builtin float results >> in SimpleCallNode being replaced with PythonCApiNode, which then >> generates the result code, but the list of coerced nodes are >> CloneNodes of the original rhs, and CloneNode does not generate the >> result code of the original rhs (i.e. allocate and assign to a temp), >> which results in a None result. >> >> Maybe CascadedAssignmentNode should replace CloneNode.arg with the >> latest self.rhs in generate_assignment_code? I'm not entirely sure. > > > May be it's better to run OptimizeBuiltinCalls before > AnalyseExpressionsTransform? Doesn't OptimizeBuiltinCalls take advantage of type information? ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
2012/1/24 Robert Bradshaw : > On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov > wrote: >> 2012/1/24 mark florisson : >>> On 24 January 2012 11:37, Konrad Hinsen wrote: Compiling the attached Cython file produced the attached C file which has errors in lines 532-534: __pyx_v_self->xx = None; __pyx_v_self->yy = None; __pyx_v_self->zz = None; There is no C symbol "None", so this doesn't compile. I first noticed the bug in Cython 0.15, but it's still in the latest revision from Github. Konrad. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel >>> >>> Hm, it seems the problem is that the call to the builtin float results >>> in SimpleCallNode being replaced with PythonCApiNode, which then >>> generates the result code, but the list of coerced nodes are >>> CloneNodes of the original rhs, and CloneNode does not generate the >>> result code of the original rhs (i.e. allocate and assign to a temp), >>> which results in a None result. >>> >>> Maybe CascadedAssignmentNode should replace CloneNode.arg with the >>> latest self.rhs in generate_assignment_code? I'm not entirely sure. Seems like a hack to me. >> >> >> May be it's better to run OptimizeBuiltinCalls before >> AnalyseExpressionsTransform? > > Doesn't OptimizeBuiltinCalls take advantage of type information? Yes, it does :( So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list is created before rhs is updated. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
On 24 January 2012 18:30, Vitja Makarov wrote: > 2012/1/24 Robert Bradshaw : >> On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov >> wrote: >>> 2012/1/24 mark florisson : On 24 January 2012 11:37, Konrad Hinsen wrote: > Compiling the attached Cython file produced the attached C file which > has errors in lines 532-534: > > __pyx_v_self->xx = None; > __pyx_v_self->yy = None; > __pyx_v_self->zz = None; > > There is no C symbol "None", so this doesn't compile. > > I first noticed the bug in Cython 0.15, but it's still in the latest > revision from Github. > > Konrad. > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Hm, it seems the problem is that the call to the builtin float results in SimpleCallNode being replaced with PythonCApiNode, which then generates the result code, but the list of coerced nodes are CloneNodes of the original rhs, and CloneNode does not generate the result code of the original rhs (i.e. allocate and assign to a temp), which results in a None result. Maybe CascadedAssignmentNode should replace CloneNode.arg with the latest self.rhs in generate_assignment_code? I'm not entirely sure. > > Seems like a hack to me. > >>> >>> >>> May be it's better to run OptimizeBuiltinCalls before >>> AnalyseExpressionsTransform? >> >> Doesn't OptimizeBuiltinCalls take advantage of type information? > > Yes, it does :( > > So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list > is created before rhs is updated. > I think deferring the CloneNode creation to code generation time works (are there any known problem with doing type coercions at code generation time?). E.g. save 'env' during analyse_types and in generate_assignment_code do rhs = CloneNode(self.rhs).coerce_to(lhs.type, self.env) rhs.generate_evaluation_code(code) lhs.generate_assignment_code(rhs, code) Seems to work. > > -- > vitja. > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
2012/1/24 mark florisson : > On 24 January 2012 18:30, Vitja Makarov wrote: >> 2012/1/24 Robert Bradshaw : >>> On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov >>> wrote: 2012/1/24 mark florisson : > On 24 January 2012 11:37, Konrad Hinsen > wrote: >> Compiling the attached Cython file produced the attached C file which >> has errors in lines 532-534: >> >> __pyx_v_self->xx = None; >> __pyx_v_self->yy = None; >> __pyx_v_self->zz = None; >> >> There is no C symbol "None", so this doesn't compile. >> >> I first noticed the bug in Cython 0.15, but it's still in the latest >> revision from Github. >> >> Konrad. >> >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > > Hm, it seems the problem is that the call to the builtin float results > in SimpleCallNode being replaced with PythonCApiNode, which then > generates the result code, but the list of coerced nodes are > CloneNodes of the original rhs, and CloneNode does not generate the > result code of the original rhs (i.e. allocate and assign to a temp), > which results in a None result. > > Maybe CascadedAssignmentNode should replace CloneNode.arg with the > latest self.rhs in generate_assignment_code? I'm not entirely sure. >> >> Seems like a hack to me. >> May be it's better to run OptimizeBuiltinCalls before AnalyseExpressionsTransform? >>> >>> Doesn't OptimizeBuiltinCalls take advantage of type information? >> >> Yes, it does :( >> >> So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list >> is created before rhs is updated. >> > > I think deferring the CloneNode creation to code generation time works > (are there any known problem with doing type coercions at code > generation time?). Coercion errors at code generation time? > E.g. save 'env' during analyse_types and in > generate_assignment_code do > > rhs = CloneNode(self.rhs).coerce_to(lhs.type, self.env) > rhs.generate_evaluation_code(code) > lhs.generate_assignment_code(rhs, code) > > Seems to work. > Yeah, that's better. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
On 01/24/2012 08:05 PM, Vitja Makarov wrote: 2012/1/24 mark florisson: On 24 January 2012 18:30, Vitja Makarov wrote: 2012/1/24 Robert Bradshaw: On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov wrote: 2012/1/24 mark florisson: On 24 January 2012 11:37, Konrad Hinsen wrote: Compiling the attached Cython file produced the attached C file which has errors in lines 532-534: __pyx_v_self->xx = None; __pyx_v_self->yy = None; __pyx_v_self->zz = None; There is no C symbol "None", so this doesn't compile. I first noticed the bug in Cython 0.15, but it's still in the latest revision from Github. Konrad. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel Hm, it seems the problem is that the call to the builtin float results in SimpleCallNode being replaced with PythonCApiNode, which then generates the result code, but the list of coerced nodes are CloneNodes of the original rhs, and CloneNode does not generate the result code of the original rhs (i.e. allocate and assign to a temp), which results in a None result. Maybe CascadedAssignmentNode should replace CloneNode.arg with the latest self.rhs in generate_assignment_code? I'm not entirely sure. Seems like a hack to me. May be it's better to run OptimizeBuiltinCalls before AnalyseExpressionsTransform? Doesn't OptimizeBuiltinCalls take advantage of type information? Yes, it does :( So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list is created before rhs is updated. I think deferring the CloneNode creation to code generation time works (are there any known problem with doing type coercions at code generation time?). Coercion errors at code generation time? Apologies up front for raising my voice, as my knowledge of the internals are getting so rusty...take this with a grain of salt. I'm +1 on working towards having the code generation phase be pure code generation. I did some refactorings to take mini-steps towards that once upon a time, moving some error conditions to before code generation. My preferred approach would be to do away with CascadedAssignmentNode at the parse tree stage: a = b = c = expr goes to tmp = expr c = tmp b = tmp a = tmp and so on. Of course it gets messier; (expr1)[expr2] = (expr3).attr = expr4 But apart from getting the time of evaluating each expression right the transform should be straightforward. One of the tempnodes/"let"-nodes (I forgot which one, or if they've been consolidated) should be able to fix this. Takes some more work though than a quick hack though... Dag E.g. save 'env' during analyse_types and in generate_assignment_code do rhs = CloneNode(self.rhs).coerce_to(lhs.type, self.env) rhs.generate_evaluation_code(code) lhs.generate_assignment_code(rhs, code) Seems to work. Yeah, that's better. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
On 24 January 2012 19:18, Dag Sverre Seljebotn wrote: > On 01/24/2012 08:05 PM, Vitja Makarov wrote: >> >> 2012/1/24 mark florisson: >>> >>> On 24 January 2012 18:30, Vitja Makarov wrote: 2012/1/24 Robert Bradshaw: > > On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov > wrote: >> >> 2012/1/24 mark florisson: >>> >>> On 24 January 2012 11:37, Konrad Hinsen >>> wrote: Compiling the attached Cython file produced the attached C file which has errors in lines 532-534: __pyx_v_self->xx = None; __pyx_v_self->yy = None; __pyx_v_self->zz = None; There is no C symbol "None", so this doesn't compile. I first noticed the bug in Cython 0.15, but it's still in the latest revision from Github. Konrad. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel >>> >>> Hm, it seems the problem is that the call to the builtin float >>> results >>> in SimpleCallNode being replaced with PythonCApiNode, which then >>> generates the result code, but the list of coerced nodes are >>> CloneNodes of the original rhs, and CloneNode does not generate the >>> result code of the original rhs (i.e. allocate and assign to a temp), >>> which results in a None result. >>> >>> Maybe CascadedAssignmentNode should replace CloneNode.arg with the >>> latest self.rhs in generate_assignment_code? I'm not entirely sure. Seems like a hack to me. >> >> >> May be it's better to run OptimizeBuiltinCalls before >> AnalyseExpressionsTransform? > > > Doesn't OptimizeBuiltinCalls take advantage of type information? Yes, it does :( So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list is created before rhs is updated. >>> >>> I think deferring the CloneNode creation to code generation time works >>> (are there any known problem with doing type coercions at code >>> generation time?). >> >> >> Coercion errors at code generation time? > > > Apologies up front for raising my voice, as my knowledge of the internals > are getting so rusty...take this with a grain of salt. > > I'm +1 on working towards having the code generation phase be pure code > generation. I did some refactorings to take mini-steps towards that once > upon a time, moving some error conditions to before code generation. > > My preferred approach would be to do away with CascadedAssignmentNode at the > parse tree stage: > > a = b = c = expr > > goes to > > tmp = expr > c = tmp > b = tmp > a = tmp > > and so on. Of course it gets messier; > > (expr1)[expr2] = (expr3).attr = expr4 > > But apart from getting the time of evaluating each expression right the > transform should be straightforward. One of the tempnodes/"let"-nodes (I > forgot which one, or if they've been consolidated) should be able to fix > this. > > Takes some more work though than a quick hack though... > > Dag > In principle it was doing the same thing, apart from the actual rewrite. I suppose the replacement problem can also be circumvented by manually wrapping self.rhs in a CoerceToTempNode. The problem with coerce_to_temp is that it does not create this node if the result is already in a temp. Creating it manually does mean an extra useless assignment, but it is an easy fix which happens at analyse_types time. Instead we could also use another node that just proxies a few things like generate_result_code and the result method. I like the idea though, it would be nice to only handle things in SingleAssignmentNode. I recently added broadcasting (inserting leading dimensions) and scalar assignment to memoryviews, and you can only catch that at the assignment point. Currently it only supports single assignments as the functionality is only in SingleAssignmentNode. I must say though, the following would look a bit weird: a = b[:] = c[:, :] = d as you always expect a kind of "cascade", e.g. you expect c[:, :] to be assignable to b[:], or 'a', but none of that may be true at all. So I'm fine with disallowing that, I think people should only use cascaded assignment for variables. >> >>> E.g. save 'env' during analyse_types and in >>> generate_assignment_code do >>> >>> rhs = CloneNode(self.rhs).coerce_to(lhs.type, self.env) >>> rhs.generate_evaluation_code(code) >>> lhs.generate_assignment_code(rhs, code) >>> >>> Seems to work. >>> >> >> Yeah, that's better. >> >> > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/l
[Cython] inline defnode calls
I just noticed the inline defnode call code. When I try to compile with 'cython -Xoptimize.inline_defnode_calls=True test.pyx' with the following code: def foo(x): print foo foo(10) I get Error compiling Cython file: ... def foo(x): print x foo(10) ^ test.pyx:4:3: Compiler crash in InlineDefNodeCalls ModuleNode.body = StatListNode(test.pyx:1:0) StatListNode.stats[2] = ExprStatNode(test.pyx:4:3) ExprStatNode.expr = SimpleCallNode(test.pyx:4:3, result_is_used = True, use_managed_ref = True) Compiler crash traceback from this point on: File "/Users/mark/cy/Cython/Compiler/Visitor.py", line 176, in _visitchild result = handler_method(child) File "/Users/mark/cy/Cython/Compiler/Optimize.py", line 1656, in visit_SimpleCallNode if not function_name.cf_state.is_single: AttributeError: 'NoneType' object has no attribute 'is_single' ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.16 release
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson wrote: > Hey, > > It's been almost three months since we talked about a 0.16 release, I > think it's quite ready. It would already be a big release, it would be > good to see how people like it, and to catch any issues etc before we > pile on more features. I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed? The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/lastSuccessfulBuild/artifact/log.txt ) which we need to get to the bottom of. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] inline defnode calls
2012/1/25 mark florisson : > I just noticed the inline defnode call code. When I try to compile > with 'cython -Xoptimize.inline_defnode_calls=True test.pyx' with the > following code: > > def foo(x): print foo > foo(10) > > I get > > Error compiling Cython file: > > ... > def foo(x): > print x > > foo(10) > ^ > > > test.pyx:4:3: Compiler crash in InlineDefNodeCalls > > ModuleNode.body = StatListNode(test.pyx:1:0) > StatListNode.stats[2] = ExprStatNode(test.pyx:4:3) > ExprStatNode.expr = SimpleCallNode(test.pyx:4:3, > result_is_used = True, > use_managed_ref = True) > > Compiler crash traceback from this point on: > File "/Users/mark/cy/Cython/Compiler/Visitor.py", line 176, in _visitchild > result = handler_method(child) > File "/Users/mark/cy/Cython/Compiler/Optimize.py", line 1656, in > visit_SimpleCallNode > if not function_name.cf_state.is_single: > AttributeError: 'NoneType' object has no attribute 'is_single' Thanks for the report! The feature is still experimental and by default is disabled. Anyway it wouldn't work for your example. It works when we know what exactly function is referred by the name so it's closure case: def foo(): def bar(): pass bar() -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug in Cython producing incorrect C code
2012/1/25 mark florisson : > On 24 January 2012 19:18, Dag Sverre Seljebotn > wrote: >> On 01/24/2012 08:05 PM, Vitja Makarov wrote: >>> >>> 2012/1/24 mark florisson: On 24 January 2012 18:30, Vitja Makarov wrote: > > 2012/1/24 Robert Bradshaw: >> >> On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov >> wrote: >>> >>> 2012/1/24 mark florisson: On 24 January 2012 11:37, Konrad Hinsen wrote: > > Compiling the attached Cython file produced the attached C file > which > has errors in lines 532-534: > > __pyx_v_self->xx = None; > __pyx_v_self->yy = None; > __pyx_v_self->zz = None; > > There is no C symbol "None", so this doesn't compile. > > I first noticed the bug in Cython 0.15, but it's still in the latest > revision from Github. > > Konrad. > > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > Hm, it seems the problem is that the call to the builtin float results in SimpleCallNode being replaced with PythonCApiNode, which then generates the result code, but the list of coerced nodes are CloneNodes of the original rhs, and CloneNode does not generate the result code of the original rhs (i.e. allocate and assign to a temp), which results in a None result. Maybe CascadedAssignmentNode should replace CloneNode.arg with the latest self.rhs in generate_assignment_code? I'm not entirely sure. > > > Seems like a hack to me. > >>> >>> >>> May be it's better to run OptimizeBuiltinCalls before >>> AnalyseExpressionsTransform? >> >> >> Doesn't OptimizeBuiltinCalls take advantage of type information? > > > Yes, it does :( > > So as Mark said the problem is CascadedAssignmentNode.coerced_rhs_list > is created before rhs is updated. > I think deferring the CloneNode creation to code generation time works (are there any known problem with doing type coercions at code generation time?). >>> >>> >>> Coercion errors at code generation time? >> >> >> Apologies up front for raising my voice, as my knowledge of the internals >> are getting so rusty...take this with a grain of salt. >> >> I'm +1 on working towards having the code generation phase be pure code >> generation. I did some refactorings to take mini-steps towards that once >> upon a time, moving some error conditions to before code generation. >> >> My preferred approach would be to do away with CascadedAssignmentNode at the >> parse tree stage: >> >> a = b = c = expr >> >> goes to >> >> tmp = expr >> c = tmp >> b = tmp >> a = tmp >> >> and so on. Of course it gets messier; >> >> (expr1)[expr2] = (expr3).attr = expr4 >> >> But apart from getting the time of evaluating each expression right the >> transform should be straightforward. One of the tempnodes/"let"-nodes (I >> forgot which one, or if they've been consolidated) should be able to fix >> this. >> >> Takes some more work though than a quick hack though... >> >> Dag >> > > In principle it was doing the same thing, apart from the actual > rewrite. I suppose the replacement problem can also be circumvented by > manually wrapping self.rhs in a CoerceToTempNode. The problem with > coerce_to_temp is that it does not create this node if the result is > already in a temp. Creating it manually does mean an extra useless > assignment, but it is an easy fix which happens at analyse_types time. > Instead we could also use another node that just proxies a few things > like generate_result_code and the result method. > > I like the idea though, it would be nice to only handle things in > SingleAssignmentNode. I recently added broadcasting (inserting leading > dimensions) and scalar assignment to memoryviews, and you can only > catch that at the assignment point. Currently it only supports single > assignments as the functionality is only in SingleAssignmentNode. > > I must say though, the following would look a bit weird: > > a = b[:] = c[:, :] = d > > as you always expect a kind of "cascade", e.g. you expect c[:, :] to > be assignable to b[:], or 'a', but none of that may be true at all. So > I'm fine with disallowing that, I think people should only use > cascaded assignment for variables. > >>> E.g. save 'env' during analyse_types and in generate_assignment_code do rhs = CloneNode(self.rhs).coerce_to(lhs.type, self.env) rhs.generate_evaluation_code(code) lhs.generate_assignment_code(rhs, code) Seems to work. >>> >>> Yeah, that's better. >>> >>> >> I don't like idea of transforming cascade assignment into N single assignment since we might
Re: [Cython] Bug in Cython producing incorrect C code
mark florisson, 24.01.2012 14:53: > On 24 January 2012 11:37, Konrad Hinsen wrote: >> Compiling the attached Cython file produced the attached C file which >> has errors in lines 532-534: >> >> __pyx_v_self->xx = None; >> __pyx_v_self->yy = None; >> __pyx_v_self->zz = None; >> >> There is no C symbol "None", so this doesn't compile. >> >> I first noticed the bug in Cython 0.15, but it's still in the latest >> revision from Github. > > Hm, it seems the problem is that the call to the builtin float results > in SimpleCallNode being replaced with PythonCApiNode, which then > generates the result code, but the list of coerced nodes are > CloneNodes of the original rhs, and CloneNode does not generate the > result code of the original rhs (i.e. allocate and assign to a temp), > which results in a None result. Back to the old idea of separating the type analysis into 1) a basic typing, inference and entry creation step and 2) a proper type analysis, coercion, etc. step. The type driven optimisations would then run in between the two. That would simplify the optimisations (which would no longer have to unpack wrapped nodes) and improve the type analysis because it could work with the optimised types, e.g. return types of optimised builtin functions. I'm not entirely sure where the type inference should run. It may make more sense to move it after the tree optimisations to make use of optimised function calls. While we're at it, we should also replace the current type inference mechanism with a control flow based one. Sounds like a good topic for a Cython hacking workshop. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
