Re: [Cython] Type inference and C++
Vitja Makarov, 23.07.2012 07:13: > Here is part of original testcase: > > from cython.operator cimport dereference as d > from cython.operator cimport preincrement as incr > from libcpp.vector cimport vector > > def reverse_iteration_test(L): > v = new vector[int]() > for a in L: > v.push_back(a) > it = v.rbegin() > while it != v.rend(): > a = d(it) > incr(it) > print(a) > > It doesn't work with local type inference enabled since `a` in > for-loop is infered as pyobject and in while loop it's inferred as > reverse_iterator. > > Then I tried to comment out for loop and compile it with > upstream/master, same error here: > > note: cpp_stl_vector.pyx:8:6: inferred 'v' to be of type 'vector[int] *' > note: cpp_stl_vector.pyx:11:7: inferred 'it' to be of type 'reverse_iterator' > note: cpp_stl_vector.pyx:13:10: inferred 'a' to be of type 'reverse_iterator' > > Error compiling Cython file: > > ... > v = new vector[int]() > #for a in L: > #v.push_back(a) > it = v.rbegin() > while it != v.rend(): > a = d(it) > ^ > > > cpp_stl_vector.pyx:13:13: Cannot assign type 'int &' to 'reverse_iterator' > > Error compiling Cython file: > > ... > #v.push_back(a) > it = v.rbegin() > while it != v.rend(): > a = d(it) > incr(it) > print(a) > ^ > > > cpp_stl_vector.pyx:15:15: Cannot convert 'reverse_iterator' to Python object > > > I think it's not correct to infer `a` as reverse_iterator because it's > not an iterator it's vector's item. Right. DereferenceNode should implement infer_type(). Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Type inference and C++
Stefan Behnel, 24.07.2012 12:43: > Vitja Makarov, 23.07.2012 07:13: >> Here is part of original testcase: >> >> from cython.operator cimport dereference as d >> from cython.operator cimport preincrement as incr >> from libcpp.vector cimport vector >> >> def reverse_iteration_test(L): >> v = new vector[int]() >> for a in L: >> v.push_back(a) >> it = v.rbegin() >> while it != v.rend(): >> a = d(it) >> incr(it) >> print(a) >> >> It doesn't work with local type inference enabled since `a` in >> for-loop is infered as pyobject and in while loop it's inferred as >> reverse_iterator. >> >> Then I tried to comment out for loop and compile it with >> upstream/master, same error here: >> >> note: cpp_stl_vector.pyx:8:6: inferred 'v' to be of type 'vector[int] *' >> note: cpp_stl_vector.pyx:11:7: inferred 'it' to be of type 'reverse_iterator' >> note: cpp_stl_vector.pyx:13:10: inferred 'a' to be of type 'reverse_iterator' >> >> Error compiling Cython file: >> >> ... >> v = new vector[int]() >> #for a in L: >> #v.push_back(a) >> it = v.rbegin() >> while it != v.rend(): >> a = d(it) >> ^ >> >> >> cpp_stl_vector.pyx:13:13: Cannot assign type 'int &' to 'reverse_iterator' >> >> Error compiling Cython file: >> >> ... >> #v.push_back(a) >> it = v.rbegin() >> while it != v.rend(): >> a = d(it) >> incr(it) >> print(a) >> ^ >> >> >> cpp_stl_vector.pyx:15:15: Cannot convert 'reverse_iterator' to Python object >> >> >> I think it's not correct to infer `a` as reverse_iterator because it's >> not an iterator it's vector's item. > > Right. DereferenceNode should implement infer_type(). ... and not only DereferenceNode. Pretty much all C++ operators do not properly implement type inference. I'll take a look. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Type inference and C++
2012/7/24 Stefan Behnel : > Stefan Behnel, 24.07.2012 12:43: >> Vitja Makarov, 23.07.2012 07:13: >>> Here is part of original testcase: >>> >>> from cython.operator cimport dereference as d >>> from cython.operator cimport preincrement as incr >>> from libcpp.vector cimport vector >>> >>> def reverse_iteration_test(L): >>> v = new vector[int]() >>> for a in L: >>> v.push_back(a) >>> it = v.rbegin() >>> while it != v.rend(): >>> a = d(it) >>> incr(it) >>> print(a) >>> >>> It doesn't work with local type inference enabled since `a` in >>> for-loop is infered as pyobject and in while loop it's inferred as >>> reverse_iterator. >>> >>> Then I tried to comment out for loop and compile it with >>> upstream/master, same error here: >>> >>> note: cpp_stl_vector.pyx:8:6: inferred 'v' to be of type 'vector[int] *' >>> note: cpp_stl_vector.pyx:11:7: inferred 'it' to be of type >>> 'reverse_iterator' >>> note: cpp_stl_vector.pyx:13:10: inferred 'a' to be of type >>> 'reverse_iterator' >>> >>> Error compiling Cython file: >>> >>> ... >>> v = new vector[int]() >>> #for a in L: >>> #v.push_back(a) >>> it = v.rbegin() >>> while it != v.rend(): >>> a = d(it) >>> ^ >>> >>> >>> cpp_stl_vector.pyx:13:13: Cannot assign type 'int &' to 'reverse_iterator' >>> >>> Error compiling Cython file: >>> >>> ... >>> #v.push_back(a) >>> it = v.rbegin() >>> while it != v.rend(): >>> a = d(it) >>> incr(it) >>> print(a) >>> ^ >>> >>> >>> cpp_stl_vector.pyx:15:15: Cannot convert 'reverse_iterator' to Python object >>> >>> >>> I think it's not correct to infer `a` as reverse_iterator because it's >>> not an iterator it's vector's item. >> >> Right. DereferenceNode should implement infer_type(). > > ... and not only DereferenceNode. Pretty much all C++ operators do not > properly implement type inference. I'll take a look. > Ok, thanks! -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Type inference and C++
Vitja Makarov, 24.07.2012 14:48: > 2012/7/24 Stefan Behnel: >> Stefan Behnel, 24.07.2012 12:43: >>> Vitja Makarov, 23.07.2012 07:13: Here is part of original testcase: from cython.operator cimport dereference as d from cython.operator cimport preincrement as incr from libcpp.vector cimport vector def reverse_iteration_test(L): v = new vector[int]() for a in L: v.push_back(a) it = v.rbegin() while it != v.rend(): a = d(it) incr(it) print(a) I think it's not correct to infer `a` as reverse_iterator because it's not an iterator it's vector's item. >>> >>> Right. DereferenceNode should implement infer_type(). >> >> ... and not only DereferenceNode. Pretty much all C++ operators do not >> properly implement type inference. I'll take a look. > > Ok, thanks! Here's my fix. https://github.com/cython/cython/commit/43f3d87d9760d3c7e7fa6a127d0bdaf549880621 It became a bit more involved than I had anticipated, including some cleanups and fixes for a couple of quirks that I ran into. It's really too bad that the Sage build is currently broken. The C++ code in there would be a good exercise for this change (even if it won't benefit from the type inference). At least, so far, it doesn't seem like it has broken more than what was broken before. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Type inference and C++
2012/7/24 Stefan Behnel : > Vitja Makarov, 24.07.2012 14:48: >> 2012/7/24 Stefan Behnel: >>> Stefan Behnel, 24.07.2012 12:43: Vitja Makarov, 23.07.2012 07:13: > Here is part of original testcase: > > from cython.operator cimport dereference as d > from cython.operator cimport preincrement as incr > from libcpp.vector cimport vector > > def reverse_iteration_test(L): > v = new vector[int]() > for a in L: > v.push_back(a) > it = v.rbegin() > while it != v.rend(): > a = d(it) > incr(it) > print(a) > > I think it's not correct to infer `a` as reverse_iterator because it's > not an iterator it's vector's item. Right. DereferenceNode should implement infer_type(). >>> >>> ... and not only DereferenceNode. Pretty much all C++ operators do not >>> properly implement type inference. I'll take a look. >> >> Ok, thanks! > > Here's my fix. > > https://github.com/cython/cython/commit/43f3d87d9760d3c7e7fa6a127d0bdaf549880621 > > It became a bit more involved than I had anticipated, including some > cleanups and fixes for a couple of quirks that I ran into. > > It's really too bad that the Sage build is currently broken. The C++ code > in there would be a good exercise for this change (even if it won't benefit > from the type inference). At least, so far, it doesn't seem like it has > broken more than what was broken before. > And sorry for stupid question: do we support multiple overloaded operators of the same kind? -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Type inference and C++
Vitja Makarov, 24.07.2012 18:42: > 2012/7/24 Stefan Behnel: >> Vitja Makarov, 24.07.2012 14:48: >>> 2012/7/24 Stefan Behnel: Stefan Behnel, 24.07.2012 12:43: > Vitja Makarov, 23.07.2012 07:13: >> Here is part of original testcase: >> >> from cython.operator cimport dereference as d >> from cython.operator cimport preincrement as incr >> from libcpp.vector cimport vector >> >> def reverse_iteration_test(L): >> v = new vector[int]() >> for a in L: >> v.push_back(a) >> it = v.rbegin() >> while it != v.rend(): >> a = d(it) >> incr(it) >> print(a) >> >> I think it's not correct to infer `a` as reverse_iterator because it's >> not an iterator it's vector's item. > > Right. DereferenceNode should implement infer_type(). ... and not only DereferenceNode. Pretty much all C++ operators do not properly implement type inference. I'll take a look. >>> >>> Ok, thanks! >> >> Here's my fix. >> >> https://github.com/cython/cython/commit/43f3d87d9760d3c7e7fa6a127d0bdaf549880621 >> >> It became a bit more involved than I had anticipated, including some >> cleanups and fixes for a couple of quirks that I ran into. >> >> It's really too bad that the Sage build is currently broken. The C++ code >> in there would be a good exercise for this change (even if it won't benefit >> from the type inference). At least, so far, it doesn't seem like it has >> broken more than what was broken before. > > And sorry for stupid question: do we support multiple overloaded > operators of the same kind? I'm sure we're lacking a test for that. At least in the change above, I'm using "lookup_operator_for_types()", which should do the right thing. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Bug, or changed array assignment in 0.17beta1?
Hello All, The exact behavior of array assignment was never entirely clear to me, but I am certain the following behavior did not occur in 0.16: bug.pyx-- def foo(): cdef int i cdef int* p1 = [4, 4] cdef int* p2 = [5, 5] print "p1:", for i in range(2): print p1[i], print "\np2:", for i in range(2): print p2[i], - which in Cython 0.17beta1 gives me >>>import bug >>>bug.foo() p1: 5 5 p2: 5 5 while in Cython 0.16 I get >>>import bug >>>bug.foo() p1: 4 4 p2: 5 5 Has the syntax of array assignment changed, or is this a bug? If the former, how do you assign to an array literal? Thanks for your all your efforts, Mike ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug, or changed array assignment in 0.17beta1?
Hi, thanks for the report. Mike Zaletel, 25.07.2012 00:40: > The exact behavior of array assignment was never entirely clear to me Yes, it's not entirely obvious. > but I am certain the following behavior did not occur in 0.16: > > bug.pyx-- > > def foo(): >cdef int i >cdef int* p1 = [4, 4] >cdef int* p2 = [5, 5] > >print "p1:", >for i in range(2): >print p1[i], >print "\np2:", >for i in range(2): >print p2[i], > > - > > which in Cython 0.17beta1 gives me > > >>> import bug > >>> bug.foo() > p1: 5 5 > p2: 5 5 > > > while in Cython 0.16 I get > > >>> import bug > >>> bug.foo() > p1: 4 4 > p2: 5 5 The problem is that the same (temporary) local array variable is used in both cases to build the array, and then only a pointer is assigned, i.e. p1 and p2 then point to the same array, which gets overwritten with the new values in the second assignment. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug, or changed array assignment in 0.17beta1?
Stefan Behnel, 25.07.2012 07:40: > Mike Zaletel, 25.07.2012 00:40: >> bug.pyx-- >> def foo(): >>cdef int i >>cdef int* p1 = [4, 4] >>cdef int* p2 = [5, 5] >> >>print "p1:", >>for i in range(2): >>print p1[i], >>print "\np2:", >>for i in range(2): >>print p2[i], >> - >> >> which in Cython 0.17beta1 gives me >> >> >>> import bug >> >>> bug.foo() >> p1: 5 5 >> p2: 5 5 >> >> >> while in Cython 0.16 I get >> >> >>> import bug >> >>> bug.foo() >> p1: 4 4 >> p2: 5 5 > > The problem is that the same (temporary) local array variable is used in > both cases to build the array, and then only a pointer is assigned, i.e. p1 > and p2 then point to the same array, which gets overwritten with the new > values in the second assignment. Oh, just in case I wasn't clear: you've found a bug. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug, or changed array assignment in 0.17beta1?
Stefan Behnel, 25.07.2012 07:40: > Mike Zaletel, 25.07.2012 00:40: >> bug.pyx-- >> >> def foo(): >>cdef int i >>cdef int* p1 = [4, 4] >>cdef int* p2 = [5, 5] >> >>print "p1:", >>for i in range(2): >>print p1[i], >>print "\np2:", >>for i in range(2): >>print p2[i], >> >> - >> >> which in Cython 0.17beta1 gives me >> >> >>> import bug >> >>> bug.foo() >> p1: 5 5 >> p2: 5 5 >> >> >> while in Cython 0.16 I get >> >> >>> import bug >> >>> bug.foo() >> p1: 4 4 >> p2: 5 5 > > The problem is that the same (temporary) local array variable is used in > both cases to build the array, and then only a pointer is assigned, i.e. p1 > and p2 then point to the same array, which gets overwritten with the new > values in the second assignment. Looking into this some more, the problem arises from the pointer assignment, because the left side is a pointer variable whereas the right side is a temp value. Temps aren't really made for an enduring life. Here, the array temp variable is being freed after the assignment and then reused. We could fix it by not freeing the temp, or at least by not reusing it, but the problem is really in the syntax. The LHS should be an array, not a pointer. It broke (and I broke it) when I fixed pointer type comparisons and made pointer and array types properly hashable. I think it was already subtly broken before in Py2 and just didn't show because it's sufficiently unlikely that two equal array types that use the default hash by object id() end up in the same dict bucket. Only then would the __eq__() comparison strike to reuse the same temp for both types. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
