From stefan_ml at behnel.de Mon Sep 1 12:14:58 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 01 Sep 2014 12:14:58 +0200 Subject: [Cython] build failure on windows with 0.21b2 windows py27 x64 In-Reply-To: References: Message-ID: <54044722.2040504@behnel.de> Dirk Rothe schrieb am 01.09.2014 um 09:55: > the Problem reported by Ian Bell on v0.21b1 seems still to be there. With > v0.21a1 from https://github.com/cython/cython/releases/tag/0.21a1 > everything seems to be fine. So maybe it's related to the method call > optimisations, you've mentioned. > > I've also tested with windows+py27+x64 and I get the same errors; > > configobj.c(42437) : error C2121: '#' : invalid character : possibly the > result of a macro expansion > configobj.c(42437) : error C2146: syntax error : missing ')' before > identifier 'ifdef' > configobj.c(42437) : error C2121: '#' : invalid character : possibly the > result of a macro expansion > configobj.c(42439) : error C2059: syntax error : 'else' > configobj.c(42449) : error C2059: syntax error : '}' > configobj.c(42463) : error C2121: '#' : invalid character : possibly the > result of a macro expansion > configobj.c(42463) : error C2121: '#' : invalid character : possibly the > result of a macro expansion > error: command '"C:\Program Files (x86)\Microsoft Visual Studio > 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2 Could you copy lines 42430-42463 (i.e. the error lines plus a bit of preceding context) from the generated C file and send them to me? (Please make sure it's clear which lines are the offending ones.) Thanks, Stefan From thecere at gmail.com Mon Sep 1 09:55:21 2014 From: thecere at gmail.com (Dirk Rothe) Date: Mon, 01 Sep 2014 09:55:21 +0200 Subject: [Cython] build failure on windows with 0.21b2 windows py27 x64 Message-ID: Hello Stefan, the Problem reported by Ian Bell on v0.21b1 seems still to be there. With v0.21a1 from https://github.com/cython/cython/releases/tag/0.21a1 everything seems to be fine. So maybe it's related to the method call optimisations, you've mentioned. I've also tested with windows+py27+x64 and I get the same errors; configobj.c(42437) : error C2121: '#' : invalid character : possibly the result of a macro expansion configobj.c(42437) : error C2146: syntax error : missing ')' before identifier 'ifdef' configobj.c(42437) : error C2121: '#' : invalid character : possibly the result of a macro expansion configobj.c(42439) : error C2059: syntax error : 'else' configobj.c(42449) : error C2059: syntax error : '}' configobj.c(42463) : error C2121: '#' : invalid character : possibly the result of a macro expansion configobj.c(42463) : error C2121: '#' : invalid character : possibly the result of a macro expansion error: command '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2 I've cythonized the following Code: http://bpaste.net/show/a10f8b244c2d with a setup.py like: --------------------- import sys from setuptools import setup from setuptools.extension import Extension from Cython.Distutils import build_ext extensions = [Extension("configobj", ["configobj.py"])] setup_info = dict(ext_modules=extensions, cmdclass={'build_ext': build_ext}) sys.argv.extend(["build_ext", "-i"]) setup(**setup_info) --dirk From thecere at gmail.com Mon Sep 1 12:25:04 2014 From: thecere at gmail.com (Dirk Rothe) Date: Mon, 01 Sep 2014 12:25:04 +0200 Subject: [Cython] build failure on windows with 0.21b2 windows py27 x64 In-Reply-To: <54044722.2040504@behnel.de> References: <54044722.2040504@behnel.de> Message-ID: On Mon, 01 Sep 2014 12:14:58 +0200, Stefan Behnel wrote: > Dirk Rothe schrieb am 01.09.2014 um 09:55: >> the Problem reported by Ian Bell on v0.21b1 seems still to be there. >> With >> v0.21a1 from https://github.com/cython/cython/releases/tag/0.21a1 >> everything seems to be fine. So maybe it's related to the method call >> optimisations, you've mentioned. >> >> I've also tested with windows+py27+x64 and I get the same errors; >> >> configobj.c(42437) : error C2121: '#' : invalid character : possibly the >> result of a macro expansion >> configobj.c(42437) : error C2146: syntax error : missing ')' before >> identifier 'ifdef' >> configobj.c(42437) : error C2121: '#' : invalid character : possibly the >> result of a macro expansion >> configobj.c(42439) : error C2059: syntax error : 'else' >> configobj.c(42449) : error C2059: syntax error : '}' >> configobj.c(42463) : error C2121: '#' : invalid character : possibly the >> result of a macro expansion >> configobj.c(42463) : error C2121: '#' : invalid character : possibly the >> result of a macro expansion >> error: command '"C:\Program Files (x86)\Microsoft Visual Studio >> 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2 > > Could you copy lines 42430-42463 (i.e. the error lines plus a bit of > preceding context) from the generated C file and send them to me? (Please > make sure it's clear which lines are the offending ones.) Here we go, I have annotated the start/end with line numbers: #if CYTHON_COMPILING_IN_CPYTHON ## Line 42431 static CYTHON_INLINE PyObject* __Pyx_PyObject_CallOneArg(PyObject *func, PyObject *arg) { if (likely(PyCFunction_Check(func) #ifdef __Pyx_CyFunction_USED || PyObject_TypeCheck(func, __pyx_CyFunctionType) #endif ) && likely(PyCFunction_GET_FLAGS(func) & METH_O)) { return __Pyx_PyObject_CallMethO(func, arg); } else { PyObject *result; PyObject *args = PyTuple_New(1); if (unlikely(!args)) return NULL; Py_INCREF(arg); PyTuple_SET_ITEM(args, 0, arg); result = __Pyx_PyObject_Call(func, args, NULL); Py_DECREF(args); return result; } } #else static CYTHON_INLINE PyObject* __Pyx_PyObject_CallOneArg(PyObject *func, PyObject *arg) { PyObject* args = PyTuple_Pack(1, arg); return (likely(args)) ? __Pyx_PyObject_Call(func, args, NULL) : NULL; } #endif ## Line 42455 #if CYTHON_COMPILING_IN_CPYTHON static CYTHON_INLINE PyObject* __Pyx_PyObject_CallNoArg(PyObject *func) { if (likely(PyCFunction_Check(func) #ifdef __Pyx_CyFunction_USED || PyObject_TypeCheck(func, __pyx_CyFunctionType) #endif ) && likely(PyCFunction_GET_FLAGS(func) & METH_NOARGS)) { return __Pyx_PyObject_CallMethO(func, NULL); } else { return __Pyx_PyObject_Call(func, __pyx_empty_tuple, NULL); } } #endif ## Line 42469 --dirkse From stefan_ml at behnel.de Thu Sep 4 09:20:54 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 04 Sep 2014 09:20:54 +0200 Subject: [Cython] planned C-API for decimal in Py3 Message-ID: <540812D6.3060502@behnel.de> Hi, there's CPython ticket (actually two of them) about providing a C level API for the decimal implementation in Py3.3+, which is based on a separate C library (libmpdec). This would allow unboxing Decimal objects and working directly with the underlying libmpdec values. "access to cdecimal / libmpdec API" http://bugs.python.org/issue22194 "Add capsule API to _decimal" http://bugs.python.org/issue15237 Direct access to libmpdec (which is linked into _cdecimal on some platforms) requires exporting the symbols. If anyone has experience with that on less common or less straight forward platforms, a comment in the first ticket would certainly be appreciated. Stefan From stefan_ml at behnel.de Fri Sep 5 20:47:47 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 05 Sep 2014 20:47:47 +0200 Subject: [Cython] build failure on windows with 0.21b2 windows py27 x64 In-Reply-To: References: <54044722.2040504@behnel.de> Message-ID: <540A0553.50708@behnel.de> Dirk Rothe schrieb am 01.09.2014 um 12:25: >>> I've also tested with windows+py27+x64 and I get the same errors; >>> >>> configobj.c(42437) : error C2121: '#' : invalid character : possibly the >>> result of a macro expansion >>> configobj.c(42437) : error C2146: syntax error : missing ')' before >>> identifier 'ifdef' >>> configobj.c(42437) : error C2121: '#' : invalid character : possibly the >>> result of a macro expansion >>> configobj.c(42439) : error C2059: syntax error : 'else' >>> configobj.c(42449) : error C2059: syntax error : '}' >>> configobj.c(42463) : error C2121: '#' : invalid character : possibly the >>> result of a macro expansion >>> configobj.c(42463) : error C2121: '#' : invalid character : possibly the >>> result of a macro expansion >>> error: command '"C:\Program Files (x86)\Microsoft Visual Studio >>> 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2 > > Here we go, I have annotated the start/end with line numbers: > > #if CYTHON_COMPILING_IN_CPYTHON ## Line 42431 > static CYTHON_INLINE PyObject* __Pyx_PyObject_CallOneArg(PyObject *func, > PyObject *arg) { > if (likely(PyCFunction_Check(func) > #ifdef __Pyx_CyFunction_USED > || PyObject_TypeCheck(func, __pyx_CyFunctionType) > #endif > ) && likely(PyCFunction_GET_FLAGS(func) & METH_O)) { > return __Pyx_PyObject_CallMethO(func, arg); > } else { > PyObject *result; > PyObject *args = PyTuple_New(1); > if (unlikely(!args)) return NULL; > [...] Thanks. My guess is that the macro nesting is a bit too heavy for MSVC here. I pushed a change to the master branch that simplifies it. Could you give it another try? https://github.com/cython/cython/commit/2a1f74aac867fee81e2ddf073f16519f3f454bac Stefan From stefan_ml at behnel.de Fri Sep 5 21:39:08 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 05 Sep 2014 21:39:08 +0200 Subject: [Cython] preparing a release candidate, pending issues Message-ID: <540A115C.5090403@behnel.de> Hi, current master looks good enough to plan for a release candidate next week. There are only a couple of pending issues that I'm aware of that may or may not get looked into for the release. One thing is cygdb and its tests - are they working again? They seem to work for me, but I don't know what the last status was there. Given how long they must have been broken, it doesn't look all too critical, though. This one should be resolved now: "build failure on windows with 0.21b2 windows py27 x64" http://thread.gmane.org/gmane.comp.python.cython.devel/15424 This isn't, but the solution isn't currently obvious (and I think it can wait until the first bugfix release if we can't find a fix in time): "Buffer dtype mismatch error" http://thread.gmane.org/gmane.comp.python.cython.user/11603 These are open, but don't feel like they should block the release: "error LNK2001: unresolved external symbol PyInit_init" http://thread.gmane.org/gmane.comp.python.cython.devel/15392/focus=15415 "Memory leak with vector of memoryviews" http://thread.gmane.org/gmane.comp.python.cython.user/11704/focus=11705 "how to have hashable extension types in pure python mode ? (__eq__ error)" http://thread.gmane.org/gmane.comp.python.cython.user/11731/focus=11732 This isn't finished but is a new feature which can wait: "Automatic conversion with fixed-size C arrays" https://github.com/cython/cython/pull/308 This hasn't lead anywhere, apparently, but can wait as well: "OpenMP thread private variable not recognized (bug report + discussion)" http://thread.gmane.org/gmane.comp.python.cython.devel/15382 So, nothing critical, but I might have forgotten something. If nothing else comes up, I'll just wait a couple of more days and then start preparing RC and final release. Stefan From jrobertray at gmail.com Sat Sep 6 01:05:01 2014 From: jrobertray at gmail.com (J Robert Ray) Date: Fri, 5 Sep 2014 16:05:01 -0700 Subject: [Cython] Bug: operator[] does not respect except + In-Reply-To: References: Message-ID: I looked into at least adding a unit test to verify "except +" behavior for all operators and I found that aside from operator(), it seems that all operators ignore "except +". I have C++ code that can throw exceptions inside operator[] and sadly this ends up causing the python interpreter to abort. On Fri, Aug 8, 2014 at 7:04 PM, J Robert Ray wrote: > I apologize for not having a working demonstration, but I have found this > bug and verified it is still an issue in Cython 0.20.2. No try/catch block > is generated for operator[]. In contrast, a try/catch block does get > generated for operator(). > > If it is any use, here is a paraphrasing of the pyx code and the generated > cpp code. > > cdef extern from "blah.h" namespace "blah": > cdef cppclass Blah: > int operator[](int) except + > > ... > > cdef class PyBlah: > ... > def demo(self, int index): > return deref(self.thisptr)[index] > > ... > > /* "Blah.pyx":107 > * def demo(self, int index): > * return deref(self.thisptr)[index] # <<<<<<<<<<<<<< > */ > __Pyx_XDECREF(__pyx_r); > __pyx_t_1 = > __Pyx_PyInt_From_int(((*__pyx_v_self->thisptr)[__pyx_v_index])); if > (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 107; > __pyx_clineno = __LINE__; goto __pyx_L1_error;} > __Pyx_GOTREF(__pyx_t_1); > __pyx_r = __pyx_t_1; > __pyx_t_1 = 0; > goto __pyx_L0; > > > Please let me know if I'm doing anything wrong. Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Sat Sep 6 01:15:54 2014 From: robertwb at gmail.com (Robert Bradshaw) Date: Fri, 5 Sep 2014 16:15:54 -0700 Subject: [Cython] Bug: operator[] does not respect except + In-Reply-To: References: Message-ID: Yes, this is a bug. On Fri, Sep 5, 2014 at 4:05 PM, J Robert Ray wrote: > I looked into at least adding a unit test to verify "except +" behavior for > all operators and I found that aside from operator(), it seems that all > operators ignore "except +". > > I have C++ code that can throw exceptions inside operator[] and sadly this > ends up causing the python interpreter to abort. > > > On Fri, Aug 8, 2014 at 7:04 PM, J Robert Ray wrote: >> >> I apologize for not having a working demonstration, but I have found this >> bug and verified it is still an issue in Cython 0.20.2. No try/catch block >> is generated for operator[]. In contrast, a try/catch block does get >> generated for operator(). >> >> If it is any use, here is a paraphrasing of the pyx code and the generated >> cpp code. >> >> cdef extern from "blah.h" namespace "blah": >> cdef cppclass Blah: >> int operator[](int) except + >> >> ... >> >> cdef class PyBlah: >> ... >> def demo(self, int index): >> return deref(self.thisptr)[index] >> >> ... >> >> /* "Blah.pyx":107 >> * def demo(self, int index): >> * return deref(self.thisptr)[index] # <<<<<<<<<<<<<< >> */ >> __Pyx_XDECREF(__pyx_r); >> __pyx_t_1 = >> __Pyx_PyInt_From_int(((*__pyx_v_self->thisptr)[__pyx_v_index])); if >> (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 107; >> __pyx_clineno = __LINE__; goto __pyx_L1_error;} >> __Pyx_GOTREF(__pyx_t_1); >> __pyx_r = __pyx_t_1; >> __pyx_t_1 = 0; >> goto __pyx_L0; >> >> >> Please let me know if I'm doing anything wrong. Thanks! > > > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > From andriy.kornatskyy at live.com Sat Sep 6 06:43:33 2014 From: andriy.kornatskyy at live.com (Andriy Kornatskyy) Date: Sat, 6 Sep 2014 07:43:33 +0300 Subject: [Cython] preparing a release candidate, pending issues In-Reply-To: <540A115C.5090403@behnel.de> References: <540A115C.5090403@behnel.de> Message-ID: Stefan, Any update to the following? "Compiler crash in RemoveUnreachableCode" http://thread.gmane.org/gmane.comp.python.cython.devel/15184 Thanks. Andriy Kornatskyy On Sep 5, 2014, at 10:39 PM, Stefan Behnel wrote: > Hi, > > current master looks good enough to plan for a release candidate next week. > There are only a couple of pending issues that I'm aware of that may or may > not get looked into for the release. > > One thing is cygdb and its tests - are they working again? They seem to > work for me, but I don't know what the last status was there. Given how > long they must have been broken, it doesn't look all too critical, though. > > > This one should be resolved now: > > "build failure on windows with 0.21b2 windows py27 x64" > http://thread.gmane.org/gmane.comp.python.cython.devel/15424 > > > This isn't, but the solution isn't currently obvious (and I think it can > wait until the first bugfix release if we can't find a fix in time): > > "Buffer dtype mismatch error" > http://thread.gmane.org/gmane.comp.python.cython.user/11603 > > > These are open, but don't feel like they should block the release: > > "error LNK2001: unresolved external symbol PyInit_init" > http://thread.gmane.org/gmane.comp.python.cython.devel/15392/focus=15415 > > "Memory leak with vector of memoryviews" > http://thread.gmane.org/gmane.comp.python.cython.user/11704/focus=11705 > > "how to have hashable extension types in pure python mode ? (__eq__ error)" > http://thread.gmane.org/gmane.comp.python.cython.user/11731/focus=11732 > > > This isn't finished but is a new feature which can wait: > > "Automatic conversion with fixed-size C arrays" > https://github.com/cython/cython/pull/308 > > > This hasn't lead anywhere, apparently, but can wait as well: > > "OpenMP thread private variable not recognized (bug report + discussion)" > http://thread.gmane.org/gmane.comp.python.cython.devel/15382 > > > So, nothing critical, but I might have forgotten something. If nothing else > comes up, I'll just wait a couple of more days and then start preparing RC > and final release. > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel From stefan_ml at behnel.de Sat Sep 6 07:35:17 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 06 Sep 2014 07:35:17 +0200 Subject: [Cython] preparing a release candidate, pending issues In-Reply-To: References: <540A115C.5090403@behnel.de> Message-ID: <540A9D15.8040202@behnel.de> Andriy Kornatskyy schrieb am 06.09.2014 um 06:43: > Any update to the following? > > "Compiler crash in RemoveUnreachableCode" > http://thread.gmane.org/gmane.comp.python.cython.devel/15184 Is that still as issue with the beta releases (or latest master)? If so, then no, there's no update. I still have no idea what easy_install does here and why the modules would get reinitialised. That part needs debugging first. Stefan From andriy.kornatskyy at live.com Sat Sep 6 08:01:27 2014 From: andriy.kornatskyy at live.com (Andriy Kornatskyy) Date: Sat, 6 Sep 2014 09:01:27 +0300 Subject: [Cython] preparing a release candidate, pending issues In-Reply-To: <540A9D15.8040202@behnel.de> References: <540A115C.5090403@behnel.de> <540A9D15.8040202@behnel.de> Message-ID: On Sep 6, 2014, at 8:35 AM, Stefan Behnel wrote: > Is that still as issue with the beta releases (or latest master)? Yes, with the latest master. Andriy From thecere at gmail.com Sat Sep 6 10:02:53 2014 From: thecere at gmail.com (Dirk Rothe) Date: Sat, 06 Sep 2014 10:02:53 +0200 Subject: [Cython] build failure on windows with 0.21b2 windows py27 x64 In-Reply-To: <540A0553.50708@behnel.de> References: <54044722.2040504@behnel.de> <540A0553.50708@behnel.de> Message-ID: On Fri, 05 Sep 2014 20:47:47 +0200, Stefan Behnel wrote: > Dirk Rothe schrieb am 01.09.2014 um 12:25: >>>> I've also tested with windows+py27+x64 and I get the same errors; >>>> >>>> configobj.c(42437) : error C2121: '#' : invalid character : possibly >>>> the >>>> result of a macro expansion >>>> configobj.c(42437) : error C2146: syntax error : missing ')' before >>>> identifier 'ifdef' >>>> configobj.c(42437) : error C2121: '#' : invalid character : possibly >>>> the >>>> result of a macro expansion >>>> configobj.c(42439) : error C2059: syntax error : 'else' >>>> configobj.c(42449) : error C2059: syntax error : '}' >>>> configobj.c(42463) : error C2121: '#' : invalid character : possibly >>>> the >>>> result of a macro expansion >>>> configobj.c(42463) : error C2121: '#' : invalid character : possibly >>>> the >>>> result of a macro expansion >>>> error: command '"C:\Program Files (x86)\Microsoft Visual Studio >>>> 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2 >> >> Here we go, I have annotated the start/end with line numbers: >> >> #if CYTHON_COMPILING_IN_CPYTHON ## Line 42431 >> static CYTHON_INLINE PyObject* __Pyx_PyObject_CallOneArg(PyObject *func, >> PyObject *arg) { >> if (likely(PyCFunction_Check(func) >> #ifdef __Pyx_CyFunction_USED >> || PyObject_TypeCheck(func, __pyx_CyFunctionType) >> #endif >> ) && likely(PyCFunction_GET_FLAGS(func) & METH_O)) { >> return __Pyx_PyObject_CallMethO(func, arg); >> } else { >> PyObject *result; >> PyObject *args = PyTuple_New(1); >> if (unlikely(!args)) return NULL; >> [...] > > Thanks. My guess is that the macro nesting is a bit too heavy for MSVC > here. I pushed a change to the master branch that simplifies it. Could > you > give it another try? > > https://github.com/cython/cython/commit/2a1f74aac867fee81e2ddf073f16519f3f454bac Thanks Stefan! The latest Trunk works fine for me now. --dirk From robertwb at gmail.com Sat Sep 6 20:02:15 2014 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 6 Sep 2014 11:02:15 -0700 Subject: [Cython] preparing a release candidate, pending issues In-Reply-To: <540A115C.5090403@behnel.de> References: <540A115C.5090403@behnel.de> Message-ID: On Fri, Sep 5, 2014 at 12:39 PM, Stefan Behnel wrote: > Hi, > > current master looks good enough to plan for a release candidate next week. > There are only a couple of pending issues that I'm aware of that may or may > not get looked into for the release. > > One thing is cygdb and its tests - are they working again? They seem to > work for me, but I don't know what the last status was there. Given how > long they must have been broken, it doesn't look all too critical, though. > > > This one should be resolved now: > > "build failure on windows with 0.21b2 windows py27 x64" > http://thread.gmane.org/gmane.comp.python.cython.devel/15424 +1, though I don't have any ideas here. > This isn't, but the solution isn't currently obvious (and I think it can > wait until the first bugfix release if we can't find a fix in time): > > "Buffer dtype mismatch error" > http://thread.gmane.org/gmane.comp.python.cython.user/11603 The only solution I can think of, short of fixing NumPy, is adding a directive to not do the check. > These are open, but don't feel like they should block the release: > > "error LNK2001: unresolved external symbol PyInit_init" > http://thread.gmane.org/gmane.comp.python.cython.devel/15392/focus=15415 > > "Memory leak with vector of memoryviews" > http://thread.gmane.org/gmane.comp.python.cython.user/11704/focus=11705 > > "how to have hashable extension types in pure python mode ? (__eq__ error)" > http://thread.gmane.org/gmane.comp.python.cython.user/11731/focus=11732 Agreed. > This isn't finished but is a new feature which can wait: > > "Automatic conversion with fixed-size C arrays" > https://github.com/cython/cython/pull/308 Yeah, this isn't done yet. > This hasn't lead anywhere, apparently, but can wait as well: > > "OpenMP thread private variable not recognized (bug report + discussion)" > http://thread.gmane.org/gmane.comp.python.cython.devel/15382 > > > So, nothing critical, but I might have forgotten something. If nothing else > comes up, I'll just wait a couple of more days and then start preparing RC > and final release. +1 From stefan_ml at behnel.de Sat Sep 6 22:18:27 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 06 Sep 2014 22:18:27 +0200 Subject: [Cython] Compiler crash in RemoveUnreachableCode In-Reply-To: References: Message-ID: <540B6C13.3040308@behnel.de> Andriy Kornatskyy schrieb am 19.01.2014 um 21:00: > The cython compiler crash report below. Steps to reproduce: > > 1. virtualenv env > 2. env/bin/easy_install cython > 3. env/bin/easy_install wheezy.http > > The wheezy.http has dependency on wheezy.core. If I install those two packages separately there is no error, only if through dependencies. I tried "pip install wheezy.http" instead of "easy_install wheezy.http" and it works as expected. This sounds like a good work-around to me. Stefan From stefan_ml at behnel.de Sun Sep 7 09:14:20 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 07 Sep 2014 09:14:20 +0200 Subject: [Cython] preparing a release candidate, pending issues In-Reply-To: References: <540A115C.5090403@behnel.de> Message-ID: <540C05CC.1090905@behnel.de> Robert Bradshaw schrieb am 06.09.2014 um 20:02: > On Fri, Sep 5, 2014 at 12:39 PM, Stefan Behnel wrote: >> "Buffer dtype mismatch error" >> http://thread.gmane.org/gmane.comp.python.cython.user/11603 > > The only solution I can think of, short of fixing NumPy, is adding a > directive to not do the check. Sounds good enough to me. Essentially, it gives users a way to work around incorrect buffer implementations at their own risk (although there may not be all that many complex buffer providers out there that would expose such a problem...). We should document the obvious drawbacks, though, i.e. no validation, all crashes you get are entirely your own. Stefan From andriy.kornatskyy at live.com Sun Sep 7 09:17:18 2014 From: andriy.kornatskyy at live.com (Andriy Kornatskyy) Date: Sun, 7 Sep 2014 10:17:18 +0300 Subject: [Cython] Compiler crash in RemoveUnreachableCode In-Reply-To: <540B6C13.3040308@behnel.de> References: <540B6C13.3040308@behnel.de> Message-ID: On Sep 6, 2014, at 11:18 PM, Stefan Behnel wrote: > I tried "pip install wheezy.http" instead of "easy_install wheezy.http" and > it works as expected. This sounds like a good work-around to me. Yes, confirmed. Thanks. Andriy From stefan_ml at behnel.de Mon Sep 8 19:51:51 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 08 Sep 2014 19:51:51 +0200 Subject: [Cython] Cython 0.21 beta 1 released In-Reply-To: <201408311029.06233.Arfrever.FTA@gmail.com> References: <53DA81B2.10805@behnel.de> <201408141018.19490.Arfrever.FTA@gmail.com> <53FF777A.4030301@behnel.de> <201408311029.06233.Arfrever.FTA@gmail.com> Message-ID: <540DECB7.7040405@behnel.de> Hi, thanks again for testing. Arfrever Frehtes Taifersar Arahesis schrieb am 31.08.2014 um 10:29: > 2014-08-28 20:39 Stefan Behnel napisa?(a): >> Arfrever Frehtes Taifersar Arahesis schrieb am 14.08.2014 um 10:18: >>> Results of test suite of Cython 0.21 beta 1 with different versions of Python: >>> Python 2.6: 1 error, 2 failures >>> Python 2.7: 1 error, 0 failures >>> Python 3.2: 1 error, 0 failures >>> Python 3.3: 1 error, 0 failures >>> Python 3.4: 1 error, 0 failures >>> >>> The 1 error is the same with all versions of Python. >>> Output with Python 2.6: >>> >>> ====================================================================== >>> ERROR: compiling (c) and running bufaccess >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "runtests.py", line 1022, in run >>> check_thread_termination() >>> File "runtests.py", line 1633, in check_thread_termination >>> raise PendingThreadsError("left-over threads found after running test") >>> PendingThreadsError: left-over threads found after running test >>> >>> ====================================================================== >> >> There should be some output in the log where the test is run that shows >> what threads are still running here. Could you look that up? > > Output for Cython 0.21 beta 2: > > compiling (c) and running bufaccess ... Doctest: bufaccess.__test__.acquire_failure1 ... ok > [...] > warning: left-over threads found after running test: > ... > ERROR That's from the IPython tests. It seems to start that thread automatically, don't know if we can do anything about it. In any case, it's not harmful and the rest of the test has passed. >>> ====================================================================== >>> FAIL: Doctest: double_dealloc_T796 >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib64/python2.6/doctest.py", line 2163, in runTest >>> raise self.failureException(self.format_failure(new.getvalue())) >>> AssertionError: Failed doctest test for double_dealloc_T796 >>> File "/tmp/Cython-0.21b1/tests-2.6/run/cpp/double_dealloc_T796/double_dealloc_T796.so", line unknown line number, in double_dealloc_T796 >>> >>> ---------------------------------------------------------------------- >>> File "/tmp/Cython-0.21b1/tests-2.6/run/cpp/double_dealloc_T796/double_dealloc_T796.so", line ?, in double_dealloc_T796 >>> Failed example: >>> del x >>> Expected: >>> SimpleGarbage(1) __dealloc__ >>> Collector.__dealloc__ >>> collect 0 >>> Got: >>> SimpleGarbage(1) __dealloc__ >>> Collector.__dealloc__ >>> collect 128 >> >> This might just be a problem with the test. Does this patch help? >> >> ========================================= >> diff -r f7b5d79a04e6 -r e2f2cf8efcc7 tests/run/double_dealloc_T796.pyx >> --- a/tests/run/double_dealloc_T796.pyx Thu Aug 28 20:21:14 2014 +0200 >> +++ b/tests/run/double_dealloc_T796.pyx Thu Aug 28 20:31:06 2014 +0200 >> @@ -1,4 +1,5 @@ >> """ >> +>>> gc.collect() >> >>> x = SimpleGarbage() >> SimpleGarbage(1) __cinit__ >> >>> del x >> ========================================= > > This patch does not help (for Cython 0.21 beta 2). Then I hope that this fixes it: https://github.com/cython/cython/commit/268810da652f702415a18c846b98ee376df8d011 Stefan From stefan_ml at behnel.de Mon Sep 8 20:03:54 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 08 Sep 2014 20:03:54 +0200 Subject: [Cython] Cython 0.21 beta 1 released In-Reply-To: <540DECB7.7040405@behnel.de> References: <53DA81B2.10805@behnel.de> <201408141018.19490.Arfrever.FTA@gmail.com> <53FF777A.4030301@behnel.de> <201408311029.06233.Arfrever.FTA@gmail.com> <540DECB7.7040405@behnel.de> Message-ID: <540DEF8A.8090704@behnel.de> Stefan Behnel schrieb am 08.09.2014 um 19:51: > Arfrever Frehtes Taifersar Arahesis schrieb am 31.08.2014 um 10:29: >> 2014-08-28 20:39 Stefan Behnel napisa?(a): >>> Arfrever Frehtes Taifersar Arahesis schrieb am 14.08.2014 um 10:18: >>>> Results of test suite of Cython 0.21 beta 1 with different versions of Python: >>>> Python 2.6: 1 error, 2 failures >>>> Python 2.7: 1 error, 0 failures >>>> Python 3.2: 1 error, 0 failures >>>> Python 3.3: 1 error, 0 failures >>>> Python 3.4: 1 error, 0 failures >>>> >>>> The 1 error is the same with all versions of Python. >>>> Output with Python 2.6: >>>> >>>> ====================================================================== >>>> ERROR: compiling (c) and running bufaccess >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "runtests.py", line 1022, in run >>>> check_thread_termination() >>>> File "runtests.py", line 1633, in check_thread_termination >>>> raise PendingThreadsError("left-over threads found after running test") >>>> PendingThreadsError: left-over threads found after running test >>>> >>>> ====================================================================== >>> >>> There should be some output in the log where the test is run that shows >>> what threads are still running here. Could you look that up? >> >> Output for Cython 0.21 beta 2: >> >> compiling (c) and running bufaccess ... Doctest: bufaccess.__test__.acquire_failure1 ... ok >> [...] >> warning: left-over threads found after running test: >> ... >> ERROR > > That's from the IPython tests. It seems to start that thread automatically, > don't know if we can do anything about it. Seems like we can: https://github.com/cython/cython/commit/33cabb92abe015a3c2ccda136df4fc9ea681d406 Stefan From stefan_ml at behnel.de Mon Sep 8 22:23:49 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 08 Sep 2014 22:23:49 +0200 Subject: [Cython] Cython 0.21 release candidate Message-ID: <540E1055.7020501@behnel.de> Hi all, I uploaded a release candidate for 0.21. There were a couple of more changes and cleanups since the last beta, so please give it another quick round of testing. http://www.cython.org/release/Cython-0.21rc1.tar.gz http://www.cython.org/release/Cython-0.21rc1.tar.gz.asc Complete changelog: https://github.com/cython/cython/blob/8337b8aec2ecbb4480d551e12b1faf9b21ba2cb1/CHANGES.rst Stefan From stefan_ml at behnel.de Tue Sep 9 11:47:47 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 09 Sep 2014 11:47:47 +0200 Subject: [Cython] [cython-users] Re: Cython 0.21 release candidate In-Reply-To: <7ab97636-670e-46dc-bb1c-08d867f5f7b1@googlegroups.com> References: <540E1055.7020501@behnel.de> <7ab97636-670e-46dc-bb1c-08d867f5f7b1@googlegroups.com> Message-ID: <540ECCC3.5030406@behnel.de> Ivan Smirnov schrieb am 09.09.2014 um 11:32: > Hi Stefan, a minor detail: might make sense to mention addition of the new > posix headers (stat.pxd etc) to the changelog? Agreed, that's worth mentioning. https://github.com/cython/cython/commit/05466cbe6c177f647de2f2f75fd00904a8545851 Thanks! Stefan From stefan_ml at behnel.de Wed Sep 10 18:40:37 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Wed, 10 Sep 2014 18:40:37 +0200 Subject: [Cython] Cython 0.21 released Message-ID: <54107F05.7080105@behnel.de> Hi all, on behalf of the Cython dev team, I'm pleased to announce the release of Cython 0.21, a major feature release. Thanks everyone who contributed code, documentation improvements, test feedback, bug reports and/or otherwise helpful insights for this release. I copied the complete changelog of this release below, but here are the major highlights, in addition to the many bug fixes and general improvements in this release. * Legacy code and support for old CPython versions was removed, baselines are now Python 2.6 and 3.2. * cdef functions finally support inner Python functions with closures. * C enums can now be declared as "cpdef" to publish them to Python space. * Python method calls, boolean "and/or" operators and cascaded assignments were optimised to streamline calls and type coercions. * The annotated HTML code output is syntax highlighted and beautified. Have fun, Stefan Downloads: https://pypi.python.org/pypi/Cython/0.21 http://cython.org/release/Cython-0.21.tar.gz http://cython.org/release/Cython-0.21.zip Signatures: http://cython.org/release/Cython-0.21.tar.gz.asc http://cython.org/release/Cython-0.21.zip.asc Changelog: https://github.com/cython/cython/blob/c67e895414aac90dfe9f789530143cff5b2ec7ad/CHANGES.rst Documentation: http://docs.cython.org/ 0.21 (2014-09-10) ================= Features added -------------- * C (cdef) functions allow inner Python functions. * Enums can now be declared as cpdef to export their values to the module's Python namespace. Cpdef enums in pxd files export their values to their own module, iff it exists. * Allow @staticmethod decorator to declare static cdef methods. This is especially useful for declaring "constructors" for cdef classes that can take non-Python arguments. * Taking a ``char*`` from a temporary Python string object is safer in more cases and can be done inside of non-trivial expressions, including arguments of a function call. A compile time error is raised only when such a pointer is assigned to a variable and would thus exceed the lifetime of the string itself. * Generators have new properties ``__name__`` and ``__qualname__`` that provide the plain/qualified name of the generator function (following CPython 3.5). See http://bugs.python.org/issue21205 * The ``inline`` function modifier is available as a decorator ``@cython.inline`` in pure mode. * When cygdb is run in a virtualenv, it enables the same virtualenv inside of the debugger. Patch by Marc Abramowitz. * PEP 465: dedicated infix operator for matrix multiplication (A @ B). * HTML output of annotated code uses Pygments for code highlighting and generally received a major overhaul by Matthias Bussonier. * IPython magic support is now available directly from Cython with the command "%load_ext cython". Cython code can directly be executed in a cell when marked with "%%cython". Code analysis is available with "%%cython -a". Patch by Mart?n Gait?n. * Simple support for declaring Python object types in Python signature annotations. Currently requires setting the compiler directive ``annotation_typing=True``. * New directive ``use_switch`` (defaults to True) to optionally disable the optimization of chained if statement to C switch statements. * Defines dynamic_cast et al. in ``libcpp.cast`` and C++ heap data structure operations in ``libcpp.algorithm``. * Shipped header declarations in ``posix.*`` were extended to cover more of the POSIX API. Patches by Lars Buitinck and Mark Peek. Optimizations ------------- * Simple calls to C implemented Python functions/methods are faster. This also speeds up many operations on builtins that Cython cannot otherwise optimise. * The "and"/"or" operators try to avoid unnecessary coercions of their arguments. They now evaluate the truth value of each argument independently and only coerce the final result of the whole expression to the target type (e.g. the type on the left side of an assignment). This also avoids reference counting overhead for Python values during evaluation and generally improves the code flow in the generated C code. * The Python expression "2 ** N" is optimised into bit shifting. See http://bugs.python.org/issue21420 * Cascaded assignments (a = b = ...) try to minimise the number of type coercions. * Calls to ``slice()`` are translated to a straight C-API call. Bugs fixed ---------- * Crash when assigning memory views from ternary conditional expressions. * Nested C++ templates could lead to unseparated ">>" characters being generated into the C++ declarations, which older C++ compilers could not parse. * Sending SIGINT (Ctrl-C) during parallel cythonize() builds could hang the child processes. * No longer ignore local setup.cfg files for distutils in pyximport. Patch by Martin Teichmann. * Taking a ``char*`` from an indexed Python string generated unsafe reference counting code. * Set literals now create all of their items before trying to add them to the set, following the behaviour in CPython. This makes a difference in the rare case that the item creation has side effects and some items are not hashable (or if hashing them has side effects, too). * Cython no longer generates the cross product of C functions for code that uses memory views of fused types in function signatures (e.g. ``cdef func(floating[:] a, floating[:] b)``). This is considered the expected behaviour by most users and was previously inconsistent with other structured types like C arrays. Code that really wants all type combinations can create the same fused memoryview type under different names and use those in the signature to make it clear which types are independent. * Names that were unknown at compile time were looked up as builtins at runtime but not as global module names. Trying both lookups helps with globals() manipulation. * Fixed stl container conversion for typedef element types. * ``obj.pop(x)`` truncated large C integer values of x to ``Py_ssize_t``. * ``__init__.pyc`` is recognised as marking a package directory (in addition to .py, .pyx and .pxd). * Syntax highlighting in ``cython-mode.el`` for Emacs no longer incorrectly highlights keywords found as part of longer names. * Correctly handle ``from cython.submodule cimport name``. * Fix infinite recursion when using super with cpdef methods. * No-args ``dir()`` was not guaranteed to return a sorted list. Other changes ------------- * The header line in the generated C files no longer contains the timestamp but only the Cython version that wrote it. This was changed to make builds more reproducible. * Removed support for CPython 2.4, 2.5 and 3.1. * The licensing implications on the generated code were clarified to avoid legal constraints for users. From stefan_ml at behnel.de Thu Sep 11 14:02:49 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 11 Sep 2014 14:02:49 +0200 Subject: [Cython] finding the Cython version (was: Cython 0.21 released) In-Reply-To: <16333d04-196f-4c4b-b8f1-e9c65beda60f@googlegroups.com> References: <54107F05.7080105@behnel.de> <16333d04-196f-4c4b-b8f1-e9c65beda60f@googlegroups.com> Message-ID: <54118F69.3030104@behnel.de> Alex K schrieb am 11.09.2014 um 13:49: > tables 3.0.0 (maybe later version too) fails to install with `pip install > tables==3.0.0` due to changes in naming. PyTables's build script expects > Cython.Compiler.Main.Version, and gives an error when it doesn't find it. > Cython 0.21 provides Cython.Compiler.Main.version. The right way to check for the Cython version is Cython.__version__ as with most Python packages. For backwards compatibility with old Cython versions that didn't have it yet, you can use Cython.Compiler.Version.version Relying on a re-exported import like "Cython.Compiler.Main.Version" is like asking for "os.sys" to work because the "os" module happens to do "import sys". Stefan From yury at shurup.com Thu Sep 11 15:41:35 2014 From: yury at shurup.com (Yury V. Zaytsev) Date: Thu, 11 Sep 2014 15:41:35 +0200 Subject: [Cython] [cython-users] finding the Cython version (was: Cython 0.21 released) In-Reply-To: <54118F69.3030104@behnel.de> References: <54107F05.7080105@behnel.de> <16333d04-196f-4c4b-b8f1-e9c65beda60f@googlegroups.com> <54118F69.3030104@behnel.de> Message-ID: <1410442895.2821.12.camel@newpride> On Thu, 2014-09-11 at 14:02 +0200, Stefan Behnel wrote: > The right way to check for the Cython version is > > Cython.__version__ > > as with most Python packages. Hi Stefan, I've just send a pull request to PyTables to fix this: https://github.com/PyTables/PyTables/pull/387 I would appreciate if you could chime in and vet it in the case that it looks sane to you. Thanks, -- Sincerely yours, Yury V. Zaytsev From stefan_ml at behnel.de Thu Sep 11 19:49:44 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 11 Sep 2014 19:49:44 +0200 Subject: [Cython] finding the Cython version In-Reply-To: <36fb8361-cedf-4338-9d94-b40bf4bf359b@googlegroups.com> References: <54107F05.7080105@behnel.de> <16333d04-196f-4c4b-b8f1-e9c65beda60f@googlegroups.com> <54118F69.3030104@behnel.de> <36fb8361-cedf-4338-9d94-b40bf4bf359b@googlegroups.com> Message-ID: <5411E0B8.4050309@behnel.de> Alex K schrieb am 11.09.2014 um 14:28: > I am a user that can not install tables 3.0.0 with cython 0.21. Tables can > be installed with cython up to 0.20.2. Can you please consider to add > Cython.Compiler.Main.Version back so that users of old tables could still > use latest cython? Normally, users should not have to use (or have) Cython themselves when they want to install a Cython implemented package. Instead, the package should ship the generated C sources and do a normal extension module build by default, without running Cython at all. That avoids a build dependency and makes sure that users really get exactly what the code maintainers wanted to release and what they have properly tested before doing so. That being said, we try to keep things working for users, unless there's an actual reason to break something. I've definitely seen way worse compatibility hacks than an unused import. https://github.com/cython/cython/commit/43342ab90704f5f850733544288485048160003d Stefan From joel.nothman at gmail.com Sun Sep 14 13:06:03 2014 From: joel.nothman at gmail.com (Joel Nothman) Date: Sun, 14 Sep 2014 21:06:03 +1000 Subject: [Cython] Variable shadows type name in posix/time.pxd Message-ID: a struct and a double are defined with the name 'timezone' in posix/time.pxd. Hence from posix.time cimport timeval, timezone, gettimeofday cdef timeval tv cdef timezone tz gettimeofday(&tv, &tz) fails with 'timezone' is not a type identifier It would be nice if there were a test for duplicate names in pxd files. Thanks for the awesome tool, Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Tue Sep 23 19:17:48 2014 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 23 Sep 2014 19:17:48 +0200 Subject: [Cython] Variable shadows type name in posix/time.pxd In-Reply-To: References: Message-ID: <5421AB3C.7020605@behnel.de> Joel Nothman schrieb am 14.09.2014 um 13:06: > a struct > > and a double > > are defined with the name 'timezone' in posix/time.pxd. Hence > > from posix.time cimport timeval, timezone, gettimeofday > cdef timeval tv > cdef timezone tz > gettimeofday(&tv, &tz) > > fails with 'timezone' is not a type identifier Thanks. https://github.com/cython/cython/commit/4562c6b5501ec17b2e11f04be10b5d8c3d728ba3 > It would be nice if there were a test for duplicate names in pxd files. Agreed. http://trac.cython.org/cython_trac/ticket/835 > Thanks for the awesome tool, Joel :) Stefan