Re: [Cython] Fwd: Re: Cython builds on various Debian platforms
On Wed, 16 Feb 2011, Lisandro Dalcin wrote: > > | AssertionError > > `--- > > what could be done about it or should it be excluded? > I've pushed some fixes. Now this testcase should run from ancient > Python 2.3 to head Python 3.2, both for static and sharedlib builds > (but not in Windows). first of all THANKS for the patch -- I picked it up into 0.14.1-2 debian package. Now tests are enabled and I just uploaded 0.14.1-2 into Debian -- lets see how it would go across architectures ;-) 2nd -- THANKS for ...: at first I got confused why I saw no commits since Dec in HG clone of Cython I had, and then mentioned that you moved to using GIT and github. Awesome and thank you for taking care about my sanity (although unintentionally I guess ;) ) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: Cython builds on various Debian platforms
And here are the first fruits: unittests fail on some platforms (also I have forgotten that $HOME is not guarantee to be writable, but that is a pure packaging-related side-point): All logs are available from https://buildd.debian.org/build.cgi?pkg=cython&dist=sid armel, powerpc, s390 (hppa is not yet done but probably the same) -- big endians: e.g. https://buildd.debian.org/fetch.cgi?pkg=cython;ver=0.14.1-3;arch=armel;stamp=1298052709 I could be wrong but it seems they all boil down to FAIL: Doctest: dictintindex.__test__.test_get_char_neg (line 1) so the others fail as well, e.g. FAIL: Doctest: c_int_types_T255 FAIL: Doctest: c_int_types_T255.__test__.test_char (line 90) FAIL: Doctest: dictintindex.__test__.test_get_char_neg (line 1) otherwise -- amazingly nice ;-) On Thu, 17 Feb 2011, Yaroslav Halchenko wrote: > > > | AssertionError > > > `--- > > > what could be done about it or should it be excluded? > > I've pushed some fixes. Now this testcase should run from ancient > > Python 2.3 to head Python 3.2, both for static and sharedlib builds > > (but not in Windows). > first of all THANKS for the patch -- I picked it up into 0.14.1-2 debian > package. Now tests are enabled and I just uploaded 0.14.1-2 into Debian > -- lets see how it would go across architectures ;-) > 2nd -- THANKS for ...: at first I got confused why I saw no commits > since Dec in HG clone of Cython I had, and then mentioned that you > moved to using GIT and github. Awesome and thank you for taking care > about my sanity (although unintentionally I guess ;) ) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: Cython builds on various Debian platforms
On Fri, 18 Feb 2011, Lisandro Dalcin wrote: > > awesome! I will test it asap -- just let me know if there would be > > another commit for above or I should tune up $HOME ;) > https://github.com/cython/cython/commit/475e9a085654252d5a274dab2118b746e8bda4eb evil you -- and who would address: Caller is responsible for deleting the directory when done with it. ;-) > >> We are very near to be crystal clear... > > yeap > And now we should be crystal clear, finally! Could you confirm? I will... manually first on one of those platforms... I will let you know of cause ;) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: Cython builds on various Debian platforms
> >> > awesome! I will test it asap -- just let me know if there would be > >> > another commit for above or I should tune up $HOME ;) > >> https://github.com/cython/cython/commit/475e9a085654252d5a274dab2118b746e8bda4eb > > evil you -- and who would address: > > Caller is responsible for deleting the directory when done with it. > > ;-) > Well, I decided to not delete it just in case things go wrong and you > need to check the output... I can easily fix that in a tearDown() > method... Should I? Well, that is up to you guys -- I do not think there is anything in Debian policy/guidelines about cleaning up TMPDIR. I, personally, would have preferred them being cleaned up. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fwd: Re: Cython builds on various Debian platforms
confirming now -- built/tested fine manually on s390, uploaded, and now built across nearly all (few still building/testing) archs: https://buildd.debian.org/pkg.cgi?pkg=cython On Fri, 18 Feb 2011, Yaroslav Halchenko wrote: > > >> We are very near to be crystal clear... > > > yeap > > And now we should be crystal clear, finally! Could you confirm? > I will... manually first on one of those platforms... I will let you > know of cause ;) -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bugfix release
just to make sure -- 0.15.1 would come out from 'release' branch, right? (there is motion to get fresh cython into debian and I am arguing that it would be better to take post 0.15 snapshot) On Tue, 13 Sep 2011, Robert Bradshaw wrote: > > I guess we're set for a release then, right? > +1. Should we send a release candidate around, or just cut it (as it > is bugfix-only and hasn't been too long since the last one)? > Also, is there a parameterized jenkins target for the release branch > yet (I'm not seeing it)? -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15.1 release candidate
is this regression or am I missing cython basics (which wouldn't be surprising). while testing 0.15.1 on Debian I have ran into fail-to-build-from-source for dipy package in Debian, failure due to error while running tests: DM2 = pf.bundles_distances_mam(tracksA, tracksB, metric=metric) File "distances.pyx", line 504, in dipy.tracking.distances.bundles_distances_mam (dipy/tracking/distances.c:5710) UnboundLocalError: local variable 'longest_track_lenA' referenced before assignment which worked fine with previous cython and looking at the dipy's .pyx code it seems to be ok (just an untyped cdef... no errors during 'compiling'): def bundles_distances_mam(tracksA, tracksB, metric='avg'): # preprocess tracks cdef: size_t longest_track_len = 0, track_len longest_track_lenA, longest_track_lenB cnp.ndarray[object, ndim=1] tracksA32 ... # some code ... cut if track_len > longest_track_lenA: longest_track_lenA = track_len -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15.1 release candidate
On Mon, 19 Sep 2011, Robert Bradshaw wrote: > > longest_track_lenA, longest_track_lenB > > ... > > if track_len > longest_track_lenA: > See the "Incompatible changes" section of > http://wiki.cython.org/ReleaseNotes-0.15 . This change was made to be > more compatible with Python semantics. Set this variable to None if > you want to use it before you assign it to something else. (Looking at told myself -- "it is too late in the night to ask dummy questions" but did it nevertheless... indeed variable is accessed before assignment first and it is logical to require initialization. Thanks! -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Ahoy, Cython 0.15.1 ho!
FWIW -- 0.15.1 got uploaded to Debian unstable, thanks to Nikolaus Rath for help. Cheers On Mon, 19 Sep 2011, Robert Bradshaw wrote: > Aye, we be happy t' announce t' release o' Cython 0.15.1. Step to, > thar be no better time t' set sails fer http://cython.org or > http://pypi.python.org/pypi/Cython/ t' download the loot. > We be bugfixing-only this release. Arrr, behold the list o' scallywags > sent to Davy Jones' Locker: > http://trac.cython.org/cython_trac/query?group=component&milestone=0.15.1 > . Ye motherload at > https://github.com/cython/cython/compare/0.15...0.15.1 > We be much beholden to ye hearties fer manning ye oars: Stefan Behnel, > Robert Bradshaw, Armon Dadgar, Mark Florisson, Gordin, Angus > McMorland, Vitja Makarov, Ralf Schmitt, and Yury V. Zaytsev. We also > be most grateful to ye landlubbers reports o' sad tails o' bugs. > Fair winds! -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] e: Automatic C++ conversions
I was thinking about updating Debian package for cython 0.16 but ran into the failing unittests so decided first to check with experts: anything obvious which comes to mind from seeing those? ... compiling (c) and running sequential_parallel ... sequential_parallel.c: In function '__pyx_pf_19sequential_parallel_56test_chunksize': sequential_parallel.c:12405:7: warning: variable '__pyx_t_6' set but not used [-Wunused-but-set-variable] sequential_parallel.c:12404:7: warning: variable '__pyx_t_5' set but not used [-Wunused-but-set-variable] sequential_parallel.c:12402:7: warning: variable '__pyx_t_3' set but not used [-Wunused-but-set-variable] sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_25test_nested_break_continue': sequential_parallel.c:5887:29: warning: '__pyx_v_j' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.c:5590:7: note: '__pyx_v_j' was declared here sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef_unnested.isra.29': sequential_parallel.c:8915:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.c:8681:7: note: '__pyx_r' was declared here sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef.isra.30': sequential_parallel.c:8614:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.c:8259:7: note: '__pyx_r' was declared here sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_33test_parallel_exc_cdef': sequential_parallel.c:8222:78: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized] sequential_parallel.c:7946:7: note: '__pyx_r' was declared here sequential_parallel.c:8233:69: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized] sequential_parallel.c:7578:7: note: '__pyx_r' was declared here Fatal Python error: deletion of interned string failed Compiling /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx because it changed. Cythonizing /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx ERROR compiling (cpp) and running sequential_parallel ... sequential_parallel.cpp: In function 'PyObject* __pyx_pf_19sequential_parallel_56test_chunksize(PyObject*)': sequential_parallel.cpp:12402:7: warning: variable '__pyx_t_3' set but not used [-Wunused-but-set-variable] sequential_parallel.cpp:12404:7: warning: variable '__pyx_t_5' set but not used [-Wunused-but-set-variable] sequential_parallel.cpp:12405:7: warning: variable '__pyx_t_6' set but not used [-Wunused-but-set-variable] sequential_parallel.cpp: In function 'PyObject* __pyx_pw_19sequential_parallel_25test_nested_break_continue(PyObject*, PyObject*)': sequential_parallel.cpp:5887:39: warning: '__pyx_v_j' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.cpp:5590:7: note: '__pyx_v_j' was declared here sequential_parallel.cpp: In function 'int _ZL48__pyx_f_19sequential_parallel_parallel_exc_cpdefi.isra.30()': sequential_parallel.cpp:8614:10: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.cpp:8259:7: note: '__pyx_r' was declared here sequential_parallel.cpp: In function 'int _ZL57__pyx_f_19sequential_parallel_parallel_exc_cpdef_unnestedi.isra.29()': sequential_parallel.cpp:8915:10: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized] sequential_parallel.cpp:8681:7: note: '__pyx_r' was declared here sequential_parallel.cpp: In function 'PyObject* __pyx_pw_19sequential_parallel_33test_parallel_exc_cdef(PyObject*, PyObject*)': sequential_parallel.cpp:8222:75: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized] sequential_parallel.cpp:7946:7: note: '__pyx_r' was declared here sequential_parallel.cpp:8233:66: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized] sequential_parallel.cpp:7578:7: note: '__pyx_r' was declared here ERROR ... == ERROR: compiling (c) and running parallel -- Traceback (most recent call last): File "runtests.py", line 707, in run self.run_tests(result) File "runtests.py", line 723, in run_tests self.run_doctests(self.module, result) File "runtests.py", line 729, in run_doctests run_forked_test(result, run_test, self.shortDescription(), self.fork) File "runtests.py", line 778, in run_forked_test (module_name, result_code & 255)) Exception: Tests in module 'parallel' were unexpectedly killed by signal 11 == ERROR: compiling (cpp) and running parallel -- Traceback (most recent ca
[Cython] Exception: Tests in module 'parallel' were unexpectedly killed by signal 11
please pardon my sloppy cut/paste which ruined the subject line in the original post ;) So the topic is: On Mon, 02 Jul 2012, Yaroslav Halchenko wrote: > I was thinking about updating Debian package for cython 0.16 but ran into > the failing unittests so decided first to check with experts: anything obvious > which comes to mind from seeing those? > ... > compiling (c) and running sequential_parallel ... sequential_parallel.c: In > function '__pyx_pf_19sequential_parallel_56test_chunksize': > sequential_parallel.c:12405:7: warning: variable '__pyx_t_6' set but not used > [-Wunused-but-set-variable] > sequential_parallel.c:12404:7: warning: variable '__pyx_t_5' set but not used > [-Wunused-but-set-variable] > sequential_parallel.c:12402:7: warning: variable '__pyx_t_3' set but not used > [-Wunused-but-set-variable] > sequential_parallel.c: In function > '__pyx_pw_19sequential_parallel_25test_nested_break_continue': > sequential_parallel.c:5887:29: warning: '__pyx_v_j' may be used uninitialized > in this function [-Wmaybe-uninitialized] > sequential_parallel.c:5590:7: note: '__pyx_v_j' was declared here > sequential_parallel.c: In function > '__pyx_f_19sequential_parallel_parallel_exc_cpdef_unnested.isra.29': > sequential_parallel.c:8915:3: warning: '__pyx_r' may be used uninitialized in > this function [-Wmaybe-uninitialized] > sequential_parallel.c:8681:7: note: '__pyx_r' was declared here > sequential_parallel.c: In function > '__pyx_f_19sequential_parallel_parallel_exc_cpdef.isra.30': > sequential_parallel.c:8614:3: warning: '__pyx_r' may be used uninitialized in > this function [-Wmaybe-uninitialized] > sequential_parallel.c:8259:7: note: '__pyx_r' was declared here > sequential_parallel.c: In function > '__pyx_pw_19sequential_parallel_33test_parallel_exc_cdef': > sequential_parallel.c:8222:78: warning: '__pyx_r' may be used uninitialized > in this function [-Wuninitialized] > sequential_parallel.c:7946:7: note: '__pyx_r' was declared here > sequential_parallel.c:8233:69: warning: '__pyx_r' may be used uninitialized > in this function [-Wuninitialized] > sequential_parallel.c:7578:7: note: '__pyx_r' was declared here > Fatal Python error: deletion of interned string failed > Compiling > /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx > because it changed. > Cythonizing > /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx > ERROR > ... > == > ERROR: compiling (c) and running parallel > -- > Traceback (most recent call last): > File "runtests.py", line 707, in run > self.run_tests(result) > File "runtests.py", line 723, in run_tests > self.run_doctests(self.module, result) > File "runtests.py", line 729, in run_doctests > run_forked_test(result, run_test, self.shortDescription(), self.fork) > File "runtests.py", line 778, in run_forked_test > (module_name, result_code & 255)) > Exception: Tests in module 'parallel' were unexpectedly killed by signal 11 > == -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] known? 0.16 on varioius platforms: ValueError: Buffer dtype mismatch, expected 'char' but got 'unsigned char' in ...
Hi everyone! 1. uploaded 0.16 to Debian experimental... many platforms fail with smth like ,-- | == | FAIL: Doctest: memslice.__test__.test_padded_structs | -- | Traceback (most recent call last): | File "/usr/lib/python2.6/doctest.py", line 2163, in runTest | raise self.failureException(self.format_failure(new.getvalue())) | AssertionError: Failed doctest test for memslice.__test__.test_padded_structs | File "/build/buildd-cython_0.16-1-armhf-FpFrv7/cython-0.16/build/work-dir/run/cpp/memslice.so", line unknown line number, in test_padded_structs | | -- | File "/build/buildd-cython_0.16-1-armhf-FpFrv7/cython-0.16/build/work-dir/run/cpp/memslice.so", line ?, in memslice.__test__.test_padded_structs | Failed example: | test_padded_structs() | Exception raised: | Traceback (most recent call last): | File "/usr/lib/python2.6/doctest.py", line 1253, in __run | compileflags, 1) in test.globs | File "", line 1, in | test_padded_structs() | File "memslice.pyx", line 42, in memslice.testcase.wrapper (memslice.cpp:3729) | File "memslice.pyx", line 1766, in memslice.test_padded_structs (memslice.cpp:27137) | File "memslice.pyx", line 1779, in memslice._test_padded (memslice.cpp:27284) | ValueError: Buffer dtype mismatch, expected 'char' but got 'unsigned char' in 'ArrayStruct.chars' `--- more here: https://buildd.debian.org/status/package.php?p=cython&suite=experimental I have tested on a sparc box and current master seems to not show this particular problem (see below though) -- does anyone remember this particular issue and commit which fixed it? 2. related question -- what is the way with runtests.py to run a particular unittest? not the full suite (e.g. my specifying memslice in cmdline), but this particular one, e.g.: ,--- | (sid)yoh@vagus:~/deb/cython/cython$ PYTHONPATH=$PWD/install/lib/python2.7/site-packages/ python runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir memslice.__test__.test_padded_structs | Python 2.7.3 (default, Jun 18 2012, 19:31:31) | [GCC 4.6.3] | | Running tests against Cython 0.17pre b0a428d4d438b1ce3e1f5d805b09899377d1ecb5 | Backends: c,cpp | | | -- | Ran 0 tests in 0.001s | | OK | ALL DONE `--- so I could bisect reasonably fast whenever needed... ? 3. FWIW there are some similar and novel failures on a sparc box on current master: http://www.onerussian.com/tmp/tests-cython-sparc-0.16rc1-490-gb0a428d.log I wondered -- do you have any brief instructions on how to setup a local build bot to contribute back to the cython's Jenkins setup? Then I could put a sparc to provide you with CI updates for this platform -- or do you have a similar one already? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] known? 0.16 on varioius platforms: ValueError: Buffer dtype mismatch, expected 'char' but got 'unsigned char' in ...
On Tue, 17 Jul 2012, Yaroslav Halchenko wrote: > I have tested on a sparc box and current master seems to not show this > particular problem (see below though) -- does anyone remember this > particular issue and commit which fixed it? I am sorry -- I got lost among architectures and what fails where and possibly misguided you in my original report -- current master does still have this problem -- this time testing on s390x (it does pass on sparc): (s390x-sid)yoh@zelenka:~/cython/cython$ python runtests.py -vv memoryview_compare_type_pointers Python 2.7.3 (default, Jul 14 2012, 05:19:55) [GCC 4.6.3] Running tests against Cython 0.17pre 0cbc0f4398cb0edbc7a128cfb2b72567f2e5e217 /home/yoh/cython/cython/BUILD/support/temp.linux-s390x-2.7/pyrex/refnanny.c: In function ‘__pyx_f_8refnanny_report_unraisable’: /home/yoh/cython/cython/BUILD/support/temp.linux-s390x-2.7/pyrex/refnanny.c:2309:7: warning: variable ‘__pyx_clineno’ set but not used [-Wunused-but-set-variable] /home/yoh/cython/cython/BUILD/support/temp.linux-s390x-2.7/pyrex/refnanny.c:2308:15: warning: variable ‘__pyx_filename’ set but not used [-Wunused-but-set-variable] /home/yoh/cython/cython/BUILD/support/temp.linux-s390x-2.7/pyrex/refnanny.c:2307:7: warning: variable ‘__pyx_lineno’ set but not used [-Wunused-but-set-variable] Backends: c,cpp runTest (__main__.EndToEndTest) End-to-end memoryview_compare_type_pointers ... /usr/bin/python setup.py build_ext --inplace Compiling test_compare_type_pointers.pyx because it changed. Compiling other_module.pyx because it changed. Cythonizing other_module.pyx Cythonizing test_compare_type_pointers.pyx running build_ext building 'test_compare_type_pointers' extension creating build creating build/temp.linux-s390x-2.7 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c test_compare_type_pointers.c -o build/temp.linux-s390x-2.7/test_compare_type_pointers.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-s390x-2.7/test_compare_type_pointers.o -o /home/yoh/cython/cython/BUILD/memoryview/memoryview_compare_type_pointers/test_compare_type_pointers.so building 'other_module' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c other_module.c -o build/temp.linux-s390x-2.7/other_module.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-s390x-2.7/other_module.o -o /home/yoh/cython/cython/BUILD/memoryview/memoryview_compare_type_pointers/other_module.so test_compare_type_pointers.c:1040:1: warning: useless type name in empty declaration [enabled by default] test_compare_type_pointers.c:1042:1: warning: useless type name in empty declaration [enabled by default] other_module.c:1038:1: warning: useless type name in empty declaration [enabled by default] other_module.c:1040:1: warning: useless type name in empty declaration [enabled by default] other_module.c:1044:1: warning: useless type name in empty declaration [enabled by default] Traceback (most recent call last): File "", line 1, in File "test_compare_type_pointers.pyx", line 3, in init test_compare_type_pointers (test_compare_type_pointers.c:13542) import other_module File "other_module.pyx", line 4, in init other_module (other_module.c:13350) cdef Foo[:] fooview = fooarray ValueError: Buffer dtype mismatch, expected 'char' but got 'unsigned char' in 'Foo.c' FAIL == FAIL: runTest (__main__.EndToEndTest) End-to-end memoryview_compare_type_pointers -- Traceback (most recent call last): File "runtests.py", line 1100, in runTest self.assertEqual(0, res, "non-zero exit status") AssertionError: non-zero exit status -- Ran 1 test in 11.070s FAILED (failures=1) ALL DONE -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 beta 1 released
Congrats on the beta-release! While testing an updated debian package
for cython I have ran into failures with Python 3.2.3 (default, Jul 13 2012,
21:02:37) [GCC 4.7.1] (complete log:
http://neuro.debian.net/_files/_buildlogs/cython/0.17~beta1/cython_0.17~beta1-1_amd64.build)
anything familiar? (I see PY3 fix bf7981fb37b19f08a331c704df8bf25d3b299be5 but
it doesn't look relevant for this one, or am I wrong?)
==
ERROR: test_globals (Cython.Build.Tests.TestInline.TestInline)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Tests/TestInline.py",
line 41, in test_globals
self.assertEquals(inline("return global_value + 1", **self.test_kwds),
global_value + 1)
File "/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Shadow.py",
line 38, in inline
return cython_inline(f, *args, **kwds)
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Inline.py", line
194, in cython_inline
module = imp.load_dynamic(module_name, module_path)
ImportError:
/tmp/cython_inline_zo_0tz/_cython_inline_d0fe156ce72658e73c2b9a9438fd8d6a.cpython-32mu-x86_64-linux-gnu.so:
cannot open shared object file: No such file or directory
==
ERROR: test_locals (Cython.Build.Tests.TestInline.TestInline)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Tests/TestInline.py",
line 38, in test_locals
self.assertEquals(inline("return a+b", **self.test_kwds), 3)
File "/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Shadow.py",
line 38, in inline
return cython_inline(f, *args, **kwds)
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Inline.py", line
194, in cython_inline
module = imp.load_dynamic(module_name, module_path)
ImportError:
/tmp/cython_inline_iktjoo/_cython_inline_6d5c007586530fac3ff8084f3b2d9acd.cpython-32mu-x86_64-linux-gnu.so:
cannot open shared object file: No such file or directory
==
ERROR: test_numpy (Cython.Build.Tests.TestInline.TestInline)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Tests/TestInline.py",
line 59, in test_numpy
self.assertEquals(inline("return a[0,0]", a=a, **self.test_kwds), 10.0)
File "/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Shadow.py",
line 38, in inline
return cython_inline(f, *args, **kwds)
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Inline.py", line
194, in cython_inline
module = imp.load_dynamic(module_name, module_path)
ImportError:
/tmp/cython_inline_ahyyvg/_cython_inline_18c0c6f9842ba6f5ea13e83da4d74e83.cpython-32mu-x86_64-linux-gnu.so:
cannot open shared object file: No such file or directory
==
ERROR: test_pure (Cython.Build.Tests.TestInline.TestInline)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Tests/TestInline.py",
line 49, in test_pure
""", a=3)
File "/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Shadow.py",
line 38, in inline
return cython_inline(f, *args, **kwds)
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Inline.py", line
194, in cython_inline
module = imp.load_dynamic(module_name, module_path)
ImportError:
/tmp/buildd/cython-0.17~beta1/build/.cython/inline/_cython_inline_52bec2971518a5e2af15359227f2254e.cpython-32mu-x86_64-linux-gnu.so:
cannot open shared object file: No such file or directory
==
ERROR: test_simple (Cython.Build.Tests.TestInline.TestInline)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Tests/TestInline.py",
line 27, in test_simple
self.assertEquals(inline("return 1+2", **self.test_kwds), 3)
File "/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Shadow.py",
line 38, in inline
return cython_inline(f, *args, **kwds)
File
"/tmp/buildd/cython-0.17~beta1/build/work-dir/Cy3/Cython/Build/Inline.py", line
194, in cython_inline
module = imp.load_dynamic(module_name, module_path)
ImportError:
/tmp/cython_inline_g42y8n/_cython_inline_2fcb515f029908306e961b3837311541.cpython-32mu-x86_64-linux-gnu.so:
cannot open shared object file: No such file or directory
=
Re: [Cython] Cython 0.17 beta 1 released
NB Sorry for a lengthy reply -- more like notes for myself I guess ;)
Short story -- imp.get_suffixes()[0] != get_config_var('SO')
on Debian multiarch sid
Perspective patch is at the bottom.
On Wed, 25 Jul 2012, Stefan Behnel wrote:
> > anything familiar? (I see PY3 fix bf7981fb37b19f08a331c704df8bf25d3b299be5
> > but
> > it doesn't look relevant for this one, or am I wrong?)
> No, I haven't seen this before.
cool -- I am glad then to bring the freshiest stuff to the table ;)
> > ImportError:
> > /tmp/cython_inline_zo_0tz/_cython_inline_d0fe156ce72658e73c2b9a9438fd8d6a.cpython-32mu-x86_64-linux-gnu.so:
> > cannot open shared object file: No such file or directory
> That's weird, and I don't think this is Cython's fault. According to the
> logs, the shared library file that it built is called
> _cython_inline_d0fe156ce72658e73c2b9a9438fd8d6a.cpython-32mu.so
> i.e. the "cpython-32mu-x86_64-linux-gnu" should be "cpython-32mu".
Thanks for the analysis! Additional suffix comes from
$> cc --print-multiarch
x86_64-linux-gnu
for multiarch Debian support
> The module path that Cython tries (and fails) to load the module from is
> built like this in the code:
> """
> so_ext = [ ext for ext,_,mod_type in imp.get_suffixes()
>if mod_type == imp.C_EXTENSION ][0]
just a note: [0] -- so only the first possible one is considered
> So, apparently, imp.get_suffixes() returns an unexpected result here. Could
> you figure out what exactly that function returns in your Py3.2 build
> environment?
here it is in my local environment:
$> python3 -c 'import imp; print(imp.get_suffixes())'
[('.cpython-32mu.so', 'rb', 3), ('module.cpython-32mu.so', 'rb', 3),
('.abi3.so', 'rb', 3), ('module.abi3.so', 'rb', 3), ('.so', 'rb', 3),
('module.so', 'rb', 3), ('.py', 'U', 1), ('.pyc', 'rb', 2)]
BUT it is with python 3.2.3-2 while sid (the build environment) was with
up-to-date python 3.2.3-3, which according to
http://packages.debian.org/changelogs/pool/main/p/python3.2/python3.2_3.2.3-3/changelog
did:
* Lookup extension modules with a multiarch suffix too.
updated my local env to match the build env:
$> python3 -c 'import imp; print(imp.get_suffixes())'
[('.cpython-32mu-x86_64-linux-gnu.so', 'rb', 3), ('.cpython-32mu.so', 'rb',
3), ('module.cpython-32mu-x86_64-linux-gnu.so', 'rb', 3),
('module.cpython-32mu.so', 'rb', 3), ('.abi3.so', 'rb', 3), ('module.abi3.so',
'rb', 3), ('.so', 'rb', 3), ('module.so', 'rb', 3), ('.py', 'U', 1), ('.pyc',
'rb', 2)]
so here we get it ;):
(gdb) py-down
#3 Frame 0x2814760, for file
/home/yoh/deb/gits/cython/build/work-dir/Cy3/Cython/Build/Inline.py, line 194,
in cython_inline (code='return global_value + 1', get_type=, lib_dir='/home/yoh/.tmp/cython_inline_mr_ml9',
cython_include_dirs=['.'], force=True, quiet=True, locals={'self':
, _testMethodName='test_globals', test_kwds={'lib_dir':
'/home/yoh/.tmp/cython_inline_mr_ml9', 'force': True, 'quiet': True},
_cleanups=[], _type_equality_funcs={:
'assertDictEqual', : 'assertMultiLineEqual', : 'assertTupleEqual', :
'assertSetEqual', : 'assertSetEqual', : 'assertListEqual'}, listing_file=None, _testMethodDoc=None,
echo_file=None) at remote 0x260cfb0>
}, globals={'CythonTest': ls -l
/home/yoh/.tmp/cython_inline_mr_ml9/_cython_inline_7bc6bab54c5c46dc2ccbec2dc048aa42.cpython-32dmu*.so
-rwx-- 1 yoh yoh 49027 Jul 25 14:22
/home/yoh/.tmp/cython_inline_mr_ml9/_cython_inline_7bc6bab54c5c46dc2ccbec2dc048aa42.cpython-32dmu.so*
So -- there is a dichotomy between what is the first in the list of
imp.get_suffixes() and what is the default extension filename from build_ext
which is based on
(Pdb) from distutils.sysconfig import get_config_var
(Pdb) get_config_var('SO')
'.cpython-32dmu.so'
used by .get_ext_filename():
(Pdb) print build_extension.get_ext_filename(module_name)
'_cython_inline_7bc6bab54c5c46dc2ccbec2dc048aa42.cpython-32dmu.so'
So I wonder, wouldn't it be reasonable (i.e. more robust) in cython_inline to
instantiate first build_extension and seek full name for the resultant
extension from it? That should eliminate any possibility to get different
names.
e.g. smth like:
$> quilt diff
--- a/Cython/Build/Inline.py
+++ b/Cython/Build/Inline.py
@@ -139,8 +139,15 @@ def cython_inline(code,
key = orig_code, arg_sigs, sys.version_info, sys.executable,
Cython.__version__
module_name = "_cython_inline_" +
hashlib.md5(str(key).encode('utf-8')).hexdigest()
-so_ext = [ ext for ext,_,mod_type in imp.get_suffixes() if mod_type ==
imp.C_EXTENSION ][0]
-module_path = os.path.join(lib_dir, module_name+so_ext)
+dist = Distribution()
+# Ensure the build respects distutils configuration by parsing
+# the configuration files
+config_files = dist.find_config_files()
+dist.parse_config_files(config_files)
+build_extension = build_ext(dist)
+build_extension.finalize_options()
+
Re: [Cython] Cython 0.17 beta 1 released
On Wed, 25 Jul 2012, Robert Bradshaw wrote:
> One essential feature of cython.inline(...) is that if the code has
> already been compiled (and loaded) it should return very fast. This
> would seem to add significant overhead.
that is what was my concern also with such an approach... I am not sure
if that is a significant overhead -- on my laptop (python 2.7):
In [13]: !cat test_get_ext_time.py
from distutils.core import Distribution
from distutils.command.build_ext import build_ext
def get_ext_filename(module_name):
dist = Distribution()
# Ensure the build respects distutils configuration by parsing
# the configuration files
config_files = dist.find_config_files()
dist.parse_config_files(config_files)
build_extension = build_ext(dist)
build_extension.finalize_options()
return build_extension.get_ext_filename(module_name)
In [14]: %run test_get_ext_time.py
In [15]: %timeit get_ext_filename('/asd/f.asdf/asdf/asd/fasdf/xx')
1000 loops, best of 3: 301 us per loop
of cause it is a relatively big slowdown relatively to 3ms of solution
based on imp.get_suffixes ... and with cython 0.16 full dummy inline:
In [4]: %timeit cython_inline('i=1')
1000 loops, best of 3: 445 us per loop
so I guess indeed 300 us would be a significant overhead
> Is the extension relatively
> consistant? Perhaps it could be cached at module load time.
could indeed be especially given the code of
def get_ext_filename(self, ext_name):
r"""Convert the name of an extension (eg. "foo.bar") into the name
of the file from which it will be loaded (eg. "foo/bar.so", or
"foo\bar.pyd").
"""
from distutils.sysconfig import get_config_var
ext_path = ext_name.split('.')
# OS/2 has an 8 character module (extension) limit :-(
if os.name == "os2":
ext_path[len(ext_path) - 1] = ext_path[len(ext_path) - 1][:8]
# extensions in debug_mode are named 'module_d.pyd' under windows
so_ext = get_config_var('SO')
if os.name == 'nt' and self.debug:
return os.path.join(*ext_path) + '_d' + so_ext
return os.path.join(*ext_path) + so_ext
suggesting only get_config_var and 1 self.debug variable which could affect ..
which are probably would not be changed at run time. Paranoid me
though would still have added some check when extension does get built to
verify that assumption was right and then spit out a warning and adjust
module_name to match so that load_dynamic doesn't fail... or would that be too
much?
would you like me to prep a perspective path or you would like to do that? ;)
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 beta 1 released
actually I have not stated alternative variant since I thought it would
not be wise to 'waste' memory : just store association between a
particular build and target module_name but now I have mentioned that
such code is pretty much there ... but incorrect and not used:
$> grep -e '\Wkey\W' -e '^def cython_inline' -e 'code_cache'
Cython/Build/Inline.py
_code_cache = {}
def cython_inline(code,
key = orig_code, arg_sigs, sys.version_info, sys.executable,
Cython.__version__
module_name = "_cython_inline_" +
hashlib.md5(str(key).encode('utf-8')).hexdigest()
for key, value in literals.items():
module_code = module_code.replace(key, value)
_code_cache[key] = module_name
so
1. key in for loop overrides the key tuple identifying the module_path
2. _code_cache is not used anywhere (but does waste memory although probably
not much since there is not that many values of key I guess which
it would get)
thus I wondered if it is ok to waste memory ( ;) ) should following patch be
used? or should _code_cache be removed altogether (or am I missing its role?)
$> quilt diff
--- a/Cython/Build/Inline.py
+++ b/Cython/Build/Inline.py
@@ -138,13 +138,11 @@ def cython_inline(code,
arg_sigs = tuple([(get_type(kwds[arg], ctx), arg) for arg in arg_names])
key = orig_code, arg_sigs, sys.version_info, sys.executable,
Cython.__version__
module_name = "_cython_inline_" +
hashlib.md5(str(key).encode('utf-8')).hexdigest()
-
-so_ext = [ ext for ext,_,mod_type in imp.get_suffixes() if mod_type ==
imp.C_EXTENSION ][0]
-module_path = os.path.join(lib_dir, module_name+so_ext)
+module_path = _code_cache.get(module_name, None)
if not os.path.exists(lib_dir):
os.makedirs(lib_dir)
-if force or not os.path.isfile(module_path):
+if force or module_path is None or not os.path.isfile(module_path):
cflags = []
c_include_dirs = []
qualified = re.compile(r'([.\w]+)[.]')
@@ -189,7 +187,9 @@ def __invoke(%(params)s):
build_extension.build_temp = os.path.dirname(pyx_file)
build_extension.build_lib = lib_dir
build_extension.run()
-_code_cache[key] = module_name
+# Should we check if module_path is not None either it still matches?
+module_path = os.path.join(lib_dir,
build_extension.get_ext_filename(module_name))
+_code_cache[module_name] = module_path
module = imp.load_dynamic(module_name, module_path)
arg_list = [kwds[arg] for arg in arg_names]
On Wed, 25 Jul 2012, Yaroslav Halchenko wrote:
> On Wed, 25 Jul 2012, Robert Bradshaw wrote:
> > One essential feature of cython.inline(...) is that if the code has
> > already been compiled (and loaded) it should return very fast. This
> > would seem to add significant overhead.
> that is what was my concern also with such an approach... I am not sure
> if that is a significant overhead -- on my laptop (python 2.7):
> In [13]: !cat test_get_ext_time.py
> from distutils.core import Distribution
> from distutils.command.build_ext import build_ext
> def get_ext_filename(module_name):
> dist = Distribution()
> # Ensure the build respects distutils configuration by parsing
> # the configuration files
> config_files = dist.find_config_files()
> dist.parse_config_files(config_files)
> build_extension = build_ext(dist)
> build_extension.finalize_options()
> return build_extension.get_ext_filename(module_name)
> In [14]: %run test_get_ext_time.py
> In [15]: %timeit get_ext_filename('/asd/f.asdf/asdf/asd/fasdf/xx')
> 1000 loops, best of 3: 301 us per loop
> of cause it is a relatively big slowdown relatively to 3ms of solution
> based on imp.get_suffixes ... and with cython 0.16 full dummy inline:
> In [4]: %timeit cython_inline('i=1')
> 1000 loops, best of 3: 445 us per loop
> so I guess indeed 300 us would be a significant overhead
> > Is the extension relatively
> > consistant? Perhaps it could be cached at module load time.
> could indeed be especially given the code of
> def get_ext_filename(self, ext_name):
> r"""Convert the name of an extension (eg. "foo.bar") into the name
> of the file from which it will be loaded (eg. "foo/bar.so", or
> "foo\bar.pyd").
> """
> from distutils.sysconfig import get_config_var
> ext_path = ext_name.split('.')
> # OS/2 has an 8 character module (extension) limit :-(
> if os.name == "os2":
> ext_path[len(ext_path) - 1] = ext_path[len(ext_path) - 1][:8]
> # extensions in debug_mode are named 'module_d.pyd'
Re: [Cython] Cython 0.17 beta 1 released
On Wed, 25 Jul 2012, Robert Bradshaw wrote:
> > module = imp.load_dynamic(module_name, module_path)
> > arg_list = [kwds[arg] for arg in arg_names]
> Compiled modules can persist between sessions as well.
yeah -- figured it down also while working on another version of this
trivial patch ;)
> I like your solution of caching the module name, what if we computed
> the module name iff it wasn't in the cache, then compiled the file iff
> the .so file didn't exist (with a check that the module name was OK).
> Alternatively, could we just rename the compiled library to be what we
> expect if it wasn't already?
we could do that ... but altogether -- do you really like caching the
names? imho it is somewhat wasteful for long-running interactive
sessions where people might try different things. Ok -- here is my next
version (stop me eventually) which just does what you wanted -- cache the
ultimate suffix under assumption that it would not change (also removed unused
_code_cache) (it came out a bit longer simply due to me adding helper function
_get_build_extension() to avoid duplication):
--- a/Cython/Build/Inline.py
+++ b/Cython/Build/Inline.py
@@ -29,8 +29,6 @@ if sys.version_info[0] < 3:
else:
to_unicode = lambda x: x
-_code_cache = {}
-
class AllSymbols(CythonTransform, SkipDeclarations):
def __init__(self):
@@ -94,6 +92,16 @@ def safe_type(arg, context=None):
return '%s.%s' % (base_type.__module__, base_type.__name__)
return 'object'
+def _get_build_extension():
+dist = Distribution()
+# Ensure the build respects distutils configuration by parsing
+# the configuration files
+config_files = dist.find_config_files()
+dist.parse_config_files(config_files)
+build_extension = build_ext(dist)
+build_extension.finalize_options()
+return build_extension
+
def cython_inline(code,
get_type=unsafe_type,
lib_dir=os.path.join(get_cython_cache_dir(), 'inline'),
@@ -139,8 +147,13 @@ def cython_inline(code,
key = orig_code, arg_sigs, sys.version_info, sys.executable,
Cython.__version__
module_name = "_cython_inline_" +
hashlib.md5(str(key).encode('utf-8')).hexdigest()
-so_ext = [ ext for ext,_,mod_type in imp.get_suffixes() if mod_type ==
imp.C_EXTENSION ][0]
-module_path = os.path.join(lib_dir, module_name+so_ext)
+build_extension = None
+if cython_inline.so_ext is None:
+# Figure out and cache current extension suffix
+build_extension = _get_build_extension()
+cython_inline.so_ext = build_extension.get_ext_filename('')
+
+module_path = os.path.join(lib_dir, module_name + cython_inline.so_ext)
if not os.path.exists(lib_dir):
os.makedirs(lib_dir)
@@ -178,23 +191,21 @@ def __invoke(%(params)s):
sources = [pyx_file],
include_dirs = c_include_dirs,
extra_compile_args = cflags)
-dist = Distribution()
-# Ensure the build respects distutils configuration by parsing
-# the configuration files
-config_files = dist.find_config_files()
-dist.parse_config_files(config_files)
-build_extension = build_ext(dist)
-build_extension.finalize_options()
+if build_extension is None:
+build_extension = _get_build_extension()
build_extension.extensions = cythonize([extension], ctx=ctx,
quiet=quiet)
build_extension.build_temp = os.path.dirname(pyx_file)
build_extension.build_lib = lib_dir
build_extension.run()
-_code_cache[key] = module_name
module = imp.load_dynamic(module_name, module_path)
arg_list = [kwds[arg] for arg in arg_names]
return module.__invoke(*arg_list)
+# Cached suffix used by cython_inline above. None should get
+# overridden with actual value upon the first cython_inline invocation
+cython_inline.so_ext = None
+
non_space = re.compile('[^ ]')
def strip_common_indent(code):
min_indent = None
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 beta 1 released
On Wed, 25 Jul 2012, Robert Bradshaw wrote: > > ultimate suffix under assumption that it would not change (also removed > > unused > > _code_cache) (it came out a bit longer simply due to me adding helper > > function > > _get_build_extension() to avoid duplication): > Looks good. Thanks. File a pull request and we'll merge it in. thanks for the blessing -- I will do whenever the full build (+tests against all supported in Debian Python versions) of the patched cython finishes to tell paranoid me that there is no surprises ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
sorry about the delay -- was not monitoring the ML tight enough ;) So it is the commit 8443607d7dffc7c8443d70036e0cce6aaa9c26e2 Author: Stefan Behnel Date: Tue Jul 31 21:49:20 2012 +0200 determine buffer typegroup of integer dtypes based on signedness at C compile time ... I pulled current master and that specific test which failed before passes now: (s390x-sid)yoh@zelenka:~/cython/cython$ git describe --tags 0.16rc1-547-g68811fa (s390x-sid)yoh@zelenka:~/cython/cython$ OPT="-g -O0" /usr/bin/python runtests.py -vv memoryview_compare_type_pointers --no-cleanup Python 2.7.3 (default, Jul 14 2012, 05:19:55) [GCC 4.6.3] Running tests against Cython 0.17.beta1 68811fa9946e4253ad405ba3011512a32807bc7b Backends: c,cpp runTest (__main__.EndToEndTest) End-to-end memoryview_compare_type_pointers ... ok -- Ran 1 test in 8.641s OK ALL DONE Let me run the entire suite and report back if any oddity. Thanks! On Tue, 31 Jul 2012, Stefan Behnel wrote: > Yaroslav, could you give it a try on the Debian build servers? > Stefan > diff -r 0d14a856f2cd Cython/Compiler/Buffer.py > --- a/Cython/Compiler/Buffer.py Tue Jul 31 20:05:37 2012 +0200 > +++ b/Cython/Compiler/Buffer.py Tue Jul 31 21:10:13 2012 +0200 > @@ -680,32 +680,25 @@ > rep = str(dtype) > flags = "0" > - > +is_unsigned = "0" > if dtype.is_int: > -if dtype.signed == 0: -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
ok, the output of running OPT="-g -O0" /usr/bin/python runtests.py -vv --no-cleanup 2>&1 | tee ../0.16rc1-547-g68811fa-tests-output.txt on a cleaned git repository on an s390x boiling down to Ran 6891 tests in 1098.734s FAILED (failures=42, errors=2) is at http://www.onerussian.com/tmp/0.16rc1-547-g68811fa-tests-output.txt.gz especially interesting are failures like: ValueError: Buffer dtype mismatch, expected 'char' but got 'char' in 'UnpackedStruct.a' ;-) or may be I should have invoked tests anyhow differently (build manually first etc)? On Wed, 01 Aug 2012, Yaroslav Halchenko wrote: > sorry about the delay -- was not monitoring the ML tight enough ;) > So it is the > commit 8443607d7dffc7c8443d70036e0cce6aaa9c26e2 > Author: Stefan Behnel > Date: Tue Jul 31 21:49:20 2012 +0200 > determine buffer typegroup of integer dtypes based on signedness at C > compile time > ... > I pulled current master and that specific test which failed before passes now: > (s390x-sid)yoh@zelenka:~/cython/cython$ git describe --tags > 0.16rc1-547-g68811fa > (s390x-sid)yoh@zelenka:~/cython/cython$ OPT="-g -O0" /usr/bin/python > runtests.py -vv memoryview_compare_type_pointers --no-cleanup > Python 2.7.3 (default, Jul 14 2012, 05:19:55) > [GCC 4.6.3] > Running tests against Cython 0.17.beta1 > 68811fa9946e4253ad405ba3011512a32807bc7b > Backends: c,cpp > runTest (__main__.EndToEndTest) > End-to-end memoryview_compare_type_pointers ... ok > -- > Ran 1 test in 8.641s > OK > ALL DONE > Let me run the entire suite and report back if any oddity. Thanks! -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
minor note -- could someone push the tag (annotated or signed preferably) for 0.17rc1? NB I am not sure what is the status on PEP 386 [1] (not yet adopted afaik) but it might be worthwhile following it and/or existing disutils.version.StrictVersion since having In [2]: Cython.__version__ Out[2]: '0.17.beta1' is not digested well by some depending projects -- there were 2 failures to build against this beta release of Cython in Debian due to difficulty with parsing the version -- bzr and xpra I believe [2]. So may be it is worth making it '0.17b1' (and use corresponding tags accordingly)? [1] http://www.python.org/dev/peps/pep-0386/ [2] http://bugs.debian.org/683133 On Wed, 01 Aug 2012, Yaroslav Halchenko wrote: > ok, the output of running > OPT="-g -O0" /usr/bin/python runtests.py -vv --no-cleanup 2>&1 | tee > ../0.16rc1-547-g68811fa-tests-output.txt > on a cleaned git repository on an s390x boiling down to > Ran 6891 tests in 1098.734s > FAILED (failures=42, errors=2) > is at > http://www.onerussian.com/tmp/0.16rc1-547-g68811fa-tests-output.txt.gz > especially interesting are failures like: > ValueError: Buffer dtype mismatch, expected 'char' but got 'char' in > 'UnpackedStruct.a' > ;-) > or may be I should have invoked tests anyhow differently (build manually > first etc)? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
On Wed, 01 Aug 2012, mark florisson wrote: > Thanks for the fix. I also pushed a fix for one more test numpy_test > related to fused types dispatching. That passes all tests for me on 32 > bit linux. > > Yaroslav, could you give it a try on the Debian build servers? FWIW -- 0.16rc1-550-g8880c78 hasn't added nor fixed any of the failures on s390x in comparison to 0.16rc1-547-g68811fa ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
On Thu, 02 Aug 2012, Stefan Behnel wrote:
> Bradley M. Froehle, 01.08.2012 18:35:
> > Yes, this versioning has also impacted mpi4py which had to add some pretty
> > ugly code in setup.py to work around it:
> > https://code.google.com/p/mpi4py/source/detail?r=841e9df
> >> I am not sure what is the status on PEP 386 [1] (not yet adopted afaik)
> It's in state "Accepted".
ah right -- now it is in python3 (but not in python2):
(git)novo:~/proj/misc/cpython[2.7]git
$> git grep NormalizedVersion 2.7
$> git grep NormalizedVersion master
master:Doc/library/packaging.version.rst:.. class:: NormalizedVersion(self, s,
error_on_huge_major_num=True)
master:Doc/library/packaging.version.rst: >>> NormalizedVersion('1.2b1') <
NormalizedVersion('1.2')
master:Doc/library/packaging.version.rst: :class:`NormalizedVersion` is used
internally by :class:`VersionPredicate` to
master:Doc/library/packaging.version.rst: :class:`NormalizedVersion`.
master:Doc/library/packaging.version.rst: >>>
NormalizedVersion("irrational_version_number")
master:Lib/packaging/command/bdist_msi.py:from packaging.version import
NormalizedVersion
master:Lib/packaging/command/bdist_msi.py:class MSIVersion(NormalizedVersion):
master:Lib/packaging/errors.py:See `error_on_huge_major_num` option in
`NormalizedVersion` for details.
master:Lib/packaging/pypi/dist.py:from packaging.version import
(suggest_normalized_version, NormalizedVersion,
master:Lib/packaging/pypi/dist.py:self._version =
NormalizedVersion(version)
master:Lib/packaging/tests/test_version.py:from packaging.version import
NormalizedVersion as V
master:Lib/packaging/tests/test_version.py:
self.assertEqual(repr(V('1.0')), "NormalizedVersion('1.0')")
master:Lib/packaging/tests/test_version.py:TypeError: cannot compare
NormalizedVersion and str
master:Lib/packaging/tests/test_version.py:TypeError: cannot compare
NormalizedVersion and str
master:Lib/packaging/version.py:__all__ = ['NormalizedVersion',
'suggest_normalized_version',
master:Lib/packaging/version.py:class NormalizedVersion:
master:Lib/packaging/version.py:"""Create a NormalizedVersion instance
from a version string.
master:Lib/packaging/version.py:the introduction of
`NormalizedVersion` was version numbers like
master:Lib/packaging/version.py:if not isinstance(other,
NormalizedVersion):
master:Lib/packaging/version.py:if not isinstance(other,
NormalizedVersion):
master:Lib/packaging/version.py:If you have a version string that isn't
rational (i.e. NormalizedVersion
master:Lib/packaging/version.py:- 2312 (53.93%) match NormalizedVersion
without change
master:Lib/packaging/version.py:NormalizedVersion(s)
master:Lib/packaging/version.py:NormalizedVersion(rs)
master:Lib/packaging/version.py:return comp, NormalizedVersion(version)
master:Lib/packaging/version.py:version = NormalizedVersion(version)
> >> parsing the version -- bzr and xpra I believe [2]. So may be it is worth
> >> making it '0.17b1' (and use corresponding tags accordingly)?
> I guess so. That would fit the StrictVersion scheme.
just a side-note -- I didn't know that StrictVersion doesn't play nicely with
LooseVersion to any degree:
$> python -c 'from distutils.version import LooseVersion as LV, StrictVersion
as SV; print SV("0.17") > LV("0.18")'
True
at least in python3 it pukes:
$> python3 -c 'from distutils.version import LooseVersion as LV, StrictVersion
as SV; print(SV("0.17") > LV("0.18"))'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.2/distutils/version.py", line 70, in __gt__
c = self._cmp(other)
File "/usr/lib/python3.2/distutils/version.py", line 179, in _cmp
if self.version < other.version:
TypeError: unorderable types: tuple() < list()
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released
On Thu, 02 Aug 2012, Stefan Behnel wrote:
> > just a side-note -- I didn't know that StrictVersion doesn't play nicely
> > with LooseVersion to any degree:
> > $> python -c 'from distutils.version import LooseVersion as LV,
> > StrictVersion as SV; print SV("0.17") > LV("0.18")'
> > True
> > at least in python3 it pukes:
> > $> python3 -c 'from distutils.version import LooseVersion as LV,
> > StrictVersion as SV; print(SV("0.17") > LV("0.18"))'
> > Traceback (most recent call last):
> > File "", line 1, in
> > File "/usr/lib/python3.2/distutils/version.py", line 70, in __gt__
> > c = self._cmp(other)
> > File "/usr/lib/python3.2/distutils/version.py", line 179, in _cmp
> > if self.version < other.version:
> > TypeError: unorderable types: tuple() < list()
> That's surprising at first sight, but I don't think it hurts all that much.
> People would normally use either of them, not both.
I understand that but absence of error in python2.x case (thus suggesting
supporting such a comparison) is misleading at least
> Anyway, the next release candidate of Cython will be called 0.17c1. Both
> the LooseVersion and the NormalizedVersion should be able to handle that.
not quite:
1.
$> python -c 'from distutils.version import LooseVersion as LV, StrictVersion
as SV; print(SV("0.17") > SV("0.17c1"))'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/distutils/version.py", line 40, in __init__
self.parse(vstring)
File "/usr/lib/python2.7/distutils/version.py", line 107, in parse
raise ValueError, "invalid version number '%s'" % vstring
ValueError: invalid version number '0.17c1'
so it needs to be 0.17b1 I guess
$> python -c 'from distutils.version import LooseVersion as LV, StrictVersion
as SV; print(SV("0.17") > SV("0.17b1"))'
True
2. LooseVersion is too loose to be used with standardized suffixes, so it
would not sort those release candidates appropriately
$> python -c 'from distutils.version import LooseVersion as LV, StrictVersion
as SV; print(LV("0.17") > LV("0.17b1"))'
False
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] remaining open issues for 0.17
On Thu, 09 Aug 2012, Stefan Behnel wrote: > > I thought the 32 bit issue was resolved? You pushed a fix and I fixed > > some tests, so it passed for me. I can run it again to check... > I don't know. Yaroslav replied to your mail saying that your fixes didn't > change anything for the Debian builds. Let's see what he has to say about > the second beta. There might have been a misunderstanding -- I can't recall if I have stated that 32-bit issues were not fixed (but I can be wrong). Probably you meant my reply concerning s390x builds (below)... and I have not uploaded any new revision to Debian since 0.17 beta1. ,--- | Date: Thu, 2 Aug 2012 10:30:32 -0400 | From: Yaroslav Halchenko | To: cython-devel@python.org | Subject: Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released | | | On Wed, 01 Aug 2012, mark florisson wrote: | > Thanks for the fix. I also pushed a fix for one more test numpy_test | > related to fused types dispatching. That passes all tests for me on 32 | > bit linux. | > > Yaroslav, could you give it a try on the Debian build servers? | | FWIW -- 0.16rc1-550-g8880c78 hasn't added nor fixed any of the failures | on s390x in comparison to 0.16rc1-547-g68811fa | ;-) | `--- -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] remaining open issues for 0.17
FWIW -- just double checked -- tests pass (of current master) just fine on an i386 Debian system. On Thu, 09 Aug 2012, Yaroslav Halchenko wrote: > On Thu, 09 Aug 2012, Stefan Behnel wrote: > > > I thought the 32 bit issue was resolved? You pushed a fix and I fixed > > > some tests, so it passed for me. I can run it again to check... > > I don't know. Yaroslav replied to your mail saying that your fixes didn't > > change anything for the Debian builds. Let's see what he has to say about > > the second beta. > There might have been a misunderstanding -- I can't recall if I have stated > that 32-bit issues were not fixed (but I can be wrong). Probably you meant my > reply concerning s390x builds (below)... and I have not uploaded any new > revision to Debian since 0.17 beta1. > ,--- > | Date: Thu, 2 Aug 2012 10:30:32 -0400 > | From: Yaroslav Halchenko > | To: cython-devel@python.org > | Subject: Re: [Cython] [cython-users] Re: Cython 0.17 beta 1 released > | On Wed, 01 Aug 2012, mark florisson wrote: > | > Thanks for the fix. I also pushed a fix for one more test numpy_test > | > related to fused types dispatching. That passes all tests for me on 32 > | > bit linux. > | > > Yaroslav, could you give it a try on the Debian build servers? > | FWIW -- 0.16rc1-550-g8880c78 hasn't added nor fixed any of the failures > | on s390x in comparison to 0.16rc1-547-g68811fa > | ;-) > `--- -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] remaining open issues for 0.17
On Thu, 09 Aug 2012, Stefan Behnel wrote: > > Is it bad to release something that doesn't pass the entire test suite > > on some system? > Given that we already made tons of releases without even knowing that > they'd fail on some systems, I'd say no. :) FWIW -- some time ago 0.15.1 build/passed all the tests across all architectures. https://buildd.debian.org/status/package.php?p=cython&suite=sid -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython Debian builds - failing cygdb tests
On Fri, 10 Aug 2012, mark florisson wrote: > > Is that the expected behaviour? Or is there just something missing in the > > build server setup, maybe something wrong with the gdb Python plugin? It > > looks like it's doing something, though... > IIRC, it parses the gdb version to match against gdb >= 7.2. Something > is clearly going wrong, it needs investigation... FWIW $> gdb --version GNU gdb (GDB) 7.4.1-debian ... seems to be parsed alright by Cython/Debugger/Tests/TestLibCython.py . > Unit testing was > hard enough on top of dealing with a notoriously unstable Python API, > maybe it's using 7.3 and it's backwards incompatible in some subtle > way? could be could be... just in case -- tested with gdb 7.3 -- similar failures. > Or maybe one of the workarounds for gdb bugs were broken by a bug > fix? :) No idea really, the tests used to pass with 7.2, no code in > the debugger changed really. btw -- with runtests.py is there a built-in way to fall into a debugger (pdb) upon failure/exception handling? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython Debian builds - failing cygdb tests
> > IIRC, it parses the gdb version to match against gdb >= 7.2. Something > > is clearly going wrong, it needs investigation... FWIW -- I have built 7.2-1 Debian package (obtained from snapshot.debian.org) under Debian stable squeeze. So I have: ,--- | $> gdb -v | GNU gdb (GDB) 7.2-debian | Copyright (C) 2010 Free Software Foundation, Inc. | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. Type "show copying" | and "show warranty" for details. | This GDB was configured as "x86_64-linux-gnu". | For bug reporting instructions, please see: | <http://www.gnu.org/software/gdb/bugs/>. `--- tests still fail, see http://www.onerussian.com/tmp/0.16rc1-595-g36d8cab-amd64-squeeze-gdb7.2-Debugger-tests-output.txt On Fri, 10 Aug 2012, Yaroslav Halchenko wrote: > > > Is that the expected behaviour? Or is there just something missing in the > > > build server setup, maybe something wrong with the gdb Python plugin? It > > > looks like it's doing something, though... > FWIW > $> gdb --version > GNU gdb (GDB) 7.4.1-debian > ... > seems to be parsed alright by Cython/Debugger/Tests/TestLibCython.py . -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 beta 3 released - release candidate
congrats! my not so wild but still a guess that 0.17b3 corresponds to 5b0e8f8b96e353ac6d12d54f86babee9ff6f1bf8 git commit (never know for sure if there is no tag :-P )? ;) On Thu, 23 Aug 2012, Stefan Behnel wrote: > Hello everyone, > on behalf of the Cython project team, I'm proud to announce the release of > our third beta of Cython 0.17. This is our first and hopefully last release > candidate for 0.17, another major step forward in the development of the > language that will make life easier for a lot of users, rounds up some > rough edges of the compiler and adds (preliminary) support for CPython 3.3 > and PyPy. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 beta 3 released - release candidate
FWIW -- this beta builds/tests ok across nearly all Debian ports but 4 where process unexpectedly terminates for no obvious reason (it built/tested just fine on my local sparc box): https://buildd.debian.org/status/package.php?p=cython&suite=experimental some time I will check WTF (memory? etc) on those intriguing ports. On Thu, 23 Aug 2012, Stefan Behnel wrote: > Hello everyone, > on behalf of the Cython project team, I'm proud to announce the release of > our third beta of Cython 0.17. This is our first and hopefully last release > candidate for 0.17, another major step forward in the development of the > language that will make life easier for a lot of users, rounds up some > rough edges of the compiler and adds (preliminary) support for CPython 3.3 > and PyPy. > Download: http://cython.org/release/Cython-0.17b3.tar.gz > Release notes: http://wiki.cython.org/ReleaseNotes-0.17 > Documentation: http://docs.cython.org/ -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 final released
On Sat, 01 Sep 2012, Stefan Behnel wrote: > Release notes: http://wiki.cython.org/ReleaseNotes-0.17 http://wiki.cython.org/ReleaseHistory references only 0.16 for me ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17 final released
On Tue, 25 Sep 2012, Stefan Behnel wrote: > > Any chance we can tag the official 0.17 release in Github as well? > BTW, do we use lightweight tags or annotated tags in git? And why? you should use annotated -a (and/or signed -s, which are annotated) tags you do not use annotated tags: $> git describe upstream/master fatal: No annotated tags can describe 'd0cf23e7dadebdb31064ef8c1fddeaef049622dc'. However, there were unannotated tags: try --tags. $> git describe --tags upstream/master 0.17.1-26-gd0cf23e why should you use them? http://stackoverflow.com/questions/4971746/why-should-i-care-about-lightweight-vs-annotated-tags -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17.1 released
On Wed, 26 Sep 2012, Stefan Behnel wrote: > http://wiki.cython.org/ReleaseNotes-0.17.1 and a regular contribution: http://wiki.cython.org/ReleaseHistory references only 0.17 for me ;-) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17.2 released
shouldn't there be http://wiki.cython.org/ReleaseNotes-0.17.2 ? ;-) > Complete changelog: > 0.17.2 (2012-11-20) > === > Features added > -- > * ``cythonize()`` gained a best effort compile mode that can be used to > simply ignore .py files that fail to compile. > Bugs fixed > -- > * Replacing an object reference with the value of one of its cdef > attributes could generate incorrect C code that accessed the object after > deleting its last reference. > * C-to-Python type coercions during cascaded comparisons could generate > invalid C code, specifically when using the 'in' operator. > * "obj[1,]" passed a single integer into the item getter instead of a tuple. > * Cyclic imports at module init time did not work in Py3. > * The names of C++ destructors for template classes were built incorrectly. > * In pure mode, type casts in Cython syntax and the C ampersand operator > are now rejected. Use the pure mode replacements instead. > * In pure mode, C type names and the sizeof() function are no longer > recognised as such and can be used as normal Python names. > * The extended C level support for the CPython array type was declared too > late to be used by user defined classes. > * C++ class nesting was broken. > * Better checking for required nullary constructors for stack-allocated C++ > instances. > * Remove module docstring in no-docstring mode. > * Fix specialization for varargs function signatures. > * Fix several compiler crashes. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17.2 released
congrats! please do not forget to push git tag for 0.17.2 ;) On Tue, 20 Nov 2012, Stefan Behnel wrote: > Hi everyone, > I'm happy to announce the release of Cython 0.17.2. This is a (mostly) bug > fix release for the stable 0.17 release series. > http://pypi.python.org/pypi/Cython/0.17.2 > Direct downloads: > http://cython.org/release/Cython-0.17.2.tar.gz > http://cython.org/release/Cython-0.17.2.zip > Github version: > https://github.com/cython/cython/commit/10183d61eb5cf33e6912dec2ab09740498f0947c > Have fun, > Stefan > Complete changelog: > 0.17.2 (2012-11-20) > === > Features added > -- > * ``cythonize()`` gained a best effort compile mode that can be used to > simply ignore .py files that fail to compile. > Bugs fixed > -- > * Replacing an object reference with the value of one of its cdef > attributes could generate incorrect C code that accessed the object after > deleting its last reference. > * C-to-Python type coercions during cascaded comparisons could generate > invalid C code, specifically when using the 'in' operator. > * "obj[1,]" passed a single integer into the item getter instead of a tuple. > * Cyclic imports at module init time did not work in Py3. > * The names of C++ destructors for template classes were built incorrectly. > * In pure mode, type casts in Cython syntax and the C ampersand operator > are now rejected. Use the pure mode replacements instead. > * In pure mode, C type names and the sizeof() function are no longer > recognised as such and can be used as normal Python names. > * The extended C level support for the CPython array type was declared too > late to be used by user defined classes. > * C++ class nesting was broken. > * Better checking for required nullary constructors for stack-allocated C++ > instances. > * Remove module docstring in no-docstring mode. > * Fix specialization for varargs function signatures. > * Fix several compiler crashes. > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] (no subject)
reproduced with cython 0.17.2 (+ few post release fixes), originally detected/reported [1] with 0.17.1 on Debian systems using debug build of Python: $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.foo(42)' python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. [1]12648 abort python-dbg -c $> cat weakfail.pyx import weakref foo_dict = weakref.WeakValueDictionary() cdef class Foo: cdef object __weakref__ def foo(key): obj = Foo() foo_dict[key] = obj return obj it seems to work fine with cython 0.15.2 . Any ideas? requires separate/new bug report? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed
pardon the initial absence of subject On Mon, 03 Dec 2012, Yaroslav Halchenko wrote: > reproduced with cython 0.17.2 (+ few post release fixes), originally > detected/reported [1] with 0.17.1 on Debian systems using debug build of > Python: > $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; > s=weakfail.foo(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion > `gc->gc.gc_refs != 0' failed. > [1]12648 abort python-dbg -c > $> cat weakfail.pyx > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > cdef object __weakref__ > def foo(key): > obj = Foo() > foo_dict[key] = obj > return obj > it seems to work fine with cython 0.15.2 . Any ideas? requires separate/new > bug report? > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] (no subject)
Thank you Bradley, This was easy enough even so that I could fix it (I think) -- just a typo: https://github.com/cython/cython/pull/165 feedback would be welcome ;) On Mon, 03 Dec 2012, Bradley M. Froehle wrote: >I ran `git bisect`: >d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 is the first bad commit >commit d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >Author: Mark Florisson <[1]markflorisso...@gmail.com> >Date: � Tue Apr 10 15:01:00 2012 +0100 >� � Decref memoryview slice class attributes > > [2]https://github.com/cython/cython/commit/d96dfdbb290d23bf3b4a186dc5b1b5d9ee7fcaa5 >-Brad >On Mon, Dec 3, 2012 at 1:10 PM, Yaroslav Halchenko ><[3]li...@onerussian.com> wrote: > reproduced with cython 0.17.2 (+ few post release fixes), originally > detected/reported [1] with �0.17.1 on Debian systems using debug build > of > Python: > $> python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; > s=weakfail.foo(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion > `gc->gc.gc_refs != 0' failed. > [1] � �12648 abort � � �python-dbg -c > $> cat weakfail.pyx > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > � � cdef object __weakref__ > def foo(key): > � � obj = Foo() > � � foo_dict[key] = obj > � � return obj > it seems to work fine with cython 0.15.2 . �Any ideas? �requires > separate/new bug report? > [1] [4]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692313 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] (no subject)
On Wed, 05 Dec 2012, mark florisson wrote: > > Thanks, I merged it. > It'd be nice if you could add this as a testcase in the tests/run > directory as a "don't segfault" kind of test. I would be happy to extend the test battery but my blunt attempt failed, i.e. the test doesn't cause the failure: (git)novo:~deb/cython[remotes/upstream/master~1]git $> rm -rf ~/.pyxbld ; python-dbg ./runtests.py -v -v weakfail; cat tests/run/weakfail.pyx Python 2.7.3 (default, Sep 9 2012, 17:05:18) [GCC 4.7.1] Running tests against Cython 0.18-pre 73895001642d4531d32cac5ad2499f4ed5f3b286 Backends: c,cpp runTest (__main__.CythonRunTestCase) compiling (c) and running weakfail ... test_weakref (line 8) (weakfail.__test__) Doctest: weakfail.__test__.test_weakref (line 8) ... ok runTest (__main__.CythonRunTestCase) compiling (cpp) and running weakfail ... test_weakref (line 8) (weakfail.__test__) Doctest: weakfail.__test__.test_weakref (line 8) ... ok -- Ran 4 tests in 2.015s OK ALL DONE [193903 refs] import weakref foo_dict = weakref.WeakValueDictionary() cdef class Foo: cdef object __weakref__ def test_weakref(key): """ >>> _ = test_weakref(48) """ obj = Foo() foo_dict[key] = obj return obj whenever if I do it manually then -- yeap: (git)novo:~deb/cython[remotes/upstream/master~1]tests/run $> rm -rf ~/.pyxbld ; PYTHONPATH=../../ python-dbg -c 'import pyximport as pi; pi.install(); import weakfail; s=weakfail.test_weakref(42)' python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. [1]5508 abort PYTHONPATH=../../ python-dbg -c so how to make it 'effective'? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] (no subject)
On Wed, 05 Dec 2012, Yaroslav Halchenko wrote: > On Wed, 05 Dec 2012, mark florisson wrote: > > > Thanks, I merged it. > > It'd be nice if you could add this as a testcase in the tests/run > > directory as a "don't segfault" kind of test. > I would be happy to extend the test battery but my blunt attempt failed, > i.e. the test doesn't cause the failure: > (git)novo:~deb/cython[remotes/upstream/master~1]git > $> rm -rf ~/.pyxbld ; python-dbg ./runtests.py -v -v weakfail; cat > tests/run/weakfail.pyx > Python 2.7.3 (default, Sep 9 2012, 17:05:18) > > [GCC 4.7.1] > Running tests against Cython 0.18-pre 73895001642d4531d32cac5ad2499f4ed5f3b286 > Backends: c,cpp > runTest (__main__.CythonRunTestCase) > compiling (c) and running weakfail ... test_weakref (line 8) > (weakfail.__test__) > Doctest: weakfail.__test__.test_weakref (line 8) ... ok > runTest (__main__.CythonRunTestCase) > compiling (cpp) and running weakfail ... test_weakref (line 8) > (weakfail.__test__) > Doctest: weakfail.__test__.test_weakref (line 8) ... ok > -- > Ran 4 tests in 2.015s > OK > ALL DONE > [193903 refs] > import weakref > foo_dict = weakref.WeakValueDictionary() > cdef class Foo: > cdef object __weakref__ > def test_weakref(key): > """ > >>> _ = test_weakref(48) > """ > obj = Foo() > foo_dict[key] = obj > return obj > whenever if I do it manually then -- yeap: > (git)novo:~deb/cython[remotes/upstream/master~1]tests/run > $> rm -rf ~/.pyxbld ; PYTHONPATH=../../ python-dbg -c 'import pyximport as > pi; pi.install(); import weakfail; s=weakfail.test_weakref(42)' > python-dbg: ../Modules/gcmodule.c:366: visit_decref: Assertion > `gc->gc.gc_refs != 0' failed. > [1]5508 abort PYTHONPATH=../../ python-dbg -c > so how to make it 'effective'? no hints from the experts? ;) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] (no subject)
On Mon, 10 Dec 2012, Stefan Behnel wrote: > >> so how to make it 'effective'? > > no hints from the experts? ;) > Usually, running gc.collect() after this kind of test (i.e. as part of the > doctest) is a good way to provoke a crash in time. wasn't it obvious ? ;-) Thanks! https://github.com/cython/cython/pull/167 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17.2 released
On Fri, 14 Dec 2012, Stefan Behnel wrote: > Yaroslav Halchenko, 03.12.2012 17:23: > > shouldn't there be > > http://wiki.cython.org/ReleaseNotes-0.17.2 > > ? ;-) > You can copy it over from > https://github.com/cython/cython/blob/0.17/CHANGES.rst > if you feel like it. :) ah cool -- catch this PR https://github.com/cython/cython/pull/172 then ;) Also, for me 'sdist' failed due to $> git show-ref -s HEAD exiting with -1 with git 1.8.0 in my clone... not sure about this dark side of git, but looking at other projects, git rev-parse HEAD might be a better choice for this purpose would you accept such a fix/PR ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.17.2 released
On Thu, 20 Dec 2012, Robert Bradshaw wrote: > > git rev-parse HEAD > > might be a better choice for this purpose > > would you accept such a fix/PR ? > Yes, please send us a fix. (This was written right when we were moving > to git, before we knew it well.) apparently I did! ;) https://github.com/cython/cython/pull/173 -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython bugfix release
FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be available to Debian folks soon too while trying 0.20.1 across debian/ubuntus I ran into this failure == ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll) -- Traceback (most recent call last): File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py", line 281, in test_all sys.stderr.write(errmsg) UnicodeEncodeError: 'ascii' codec can't encode characters in position 18851-18854: ordinal not in range(128) on debian wheezy i386. it didn't happen on amd64 and on both architectures under debian jessie (testing) and it seemed to happen while testing with python2.6 On Mon, 16 Jun 2014, Robert Bradshaw wrote: > I just pushed another bugfix release for the 0.20.x line, available on > github, cython.org, or and pypi. > == Features added == > * Some optimisations for set/frozenset instantiation. > * Support for C++ unordered_set and unordered_map. > == Bugs fixed == > * Access to attributes of optimised builtin methods (e.g. > [].append.__name__) could fail to compile. > * Memory leak when extension subtypes add a memory view as attribute > to those of the parent type without having Python object attributes or > a user provided dealloc method. > * Compiler crash on readonly properties in "binding" mode. > * Auto-encoding with c_string_encoding=ascii failed in Py3.3. > * Crash when subtyping freelist enabled Cython extension types with > Python classes that use __slots__. > * Freelist usage is restricted to CPython to avoid problems with other > Python implementations. > * Memory leak in memory views when copying overlapping, contiguous slices. > * Format checking when requesting non-contiguous buffers from > cython.array objects was disabled in Py3. > * C++ destructor calls in extension types could fail to compile in clang. > * Buffer format validation failed for sequences of strings in structs. > * Docstrings on extension type attributes in .pxd files were rejected. > == Contributors == > Andreas van Cranenburgh > Ian Bell > Lars Buitinck > Martin Quarda > Mikhail Korobov > Robert Bradshaw > Stefan Behnel > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython bugfix release
and the same issue in current(ish) master: == ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll) -- Traceback (most recent call last): File "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py", line 280, in test_all sys.stderr.write(errmsg) UnicodeEncodeError: 'ascii' codec can't encode characters in position 21001-21004: ordinal not in range(128) -- Ran 8348 tests in 2674.102s On Wed, 18 Jun 2014, Yaroslav Halchenko wrote: > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be available > to Debian folks soon too > while trying 0.20.1 across debian/ubuntus I ran into this failure > == > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll) > -- > Traceback (most recent call last): > File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py", > line 281, in test_all > sys.stderr.write(errmsg) > UnicodeEncodeError: 'ascii' codec can't encode characters in position > 18851-18854: ordinal not in range(128) > on debian wheezy i386. it didn't happen on amd64 and on both architectures > under debian jessie (testing) and it seemed to happen while testing with > python2.6 > On Mon, 16 Jun 2014, Robert Bradshaw wrote: > > I just pushed another bugfix release for the 0.20.x line, available on > > github, cython.org, or and pypi. > > == Features added == > > * Some optimisations for set/frozenset instantiation. > > * Support for C++ unordered_set and unordered_map. > > == Bugs fixed == > > * Access to attributes of optimised builtin methods (e.g. > > [].append.__name__) could fail to compile. > > * Memory leak when extension subtypes add a memory view as attribute > > to those of the parent type without having Python object attributes or > > a user provided dealloc method. > > * Compiler crash on readonly properties in "binding" mode. > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3. > > * Crash when subtyping freelist enabled Cython extension types with > > Python classes that use __slots__. > > * Freelist usage is restricted to CPython to avoid problems with other > > Python implementations. > > * Memory leak in memory views when copying overlapping, contiguous slices. > > * Format checking when requesting non-contiguous buffers from > > cython.array objects was disabled in Py3. > > * C++ destructor calls in extension types could fail to compile in clang. > > * Buffer format validation failed for sequences of strings in structs. > > * Docstrings on extension type attributes in .pxd files were rejected. > > == Contributors == > > Andreas van Cranenburgh > > Ian Bell > > Lars Buitinck > > Martin Quarda > > Mikhail Korobov > > Robert Bradshaw > > Stefan Behnel > > ___ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython bugfix release
that was quite an underwhelming response, now it is "official" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340 and I haven't had yet a chance to recheck master... anyone has a clue before I start digging? On Thu, 19 Jun 2014, Yaroslav Halchenko wrote: > and the same issue in current(ish) master: > == > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll) > -- > Traceback (most recent call last): > File > "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py", > line 280, in test_all > sys.stderr.write(errmsg) > UnicodeEncodeError: 'ascii' codec can't encode characters in position > 21001-21004: ordinal not in range(128) > ------ > Ran 8348 tests in 2674.102s > On Wed, 18 Jun 2014, Yaroslav Halchenko wrote: > > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be available > > to Debian folks soon too > > while trying 0.20.1 across debian/ubuntus I ran into this failure > > == > > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll) > > -- > > Traceback (most recent call last): > > File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py", > > line 281, in test_all > > sys.stderr.write(errmsg) > > UnicodeEncodeError: 'ascii' codec can't encode characters in position > > 18851-18854: ordinal not in range(128) > > on debian wheezy i386. it didn't happen on amd64 and on both architectures > > under debian jessie (testing) and it seemed to happen while testing with > > python2.6 > > On Mon, 16 Jun 2014, Robert Bradshaw wrote: > > > I just pushed another bugfix release for the 0.20.x line, available on > > > github, cython.org, or and pypi. > > > == Features added == > > > * Some optimisations for set/frozenset instantiation. > > > * Support for C++ unordered_set and unordered_map. > > > == Bugs fixed == > > > * Access to attributes of optimised builtin methods (e.g. > > > [].append.__name__) could fail to compile. > > > * Memory leak when extension subtypes add a memory view as attribute > > > to those of the parent type without having Python object attributes or > > > a user provided dealloc method. > > > * Compiler crash on readonly properties in "binding" mode. > > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3. > > > * Crash when subtyping freelist enabled Cython extension types with > > > Python classes that use __slots__. > > > * Freelist usage is restricted to CPython to avoid problems with other > > > Python implementations. > > > * Memory leak in memory views when copying overlapping, contiguous slices. > > > * Format checking when requesting non-contiguous buffers from > > > cython.array objects was disabled in Py3. > > > * C++ destructor calls in extension types could fail to compile in clang. > > > * Buffer format validation failed for sequences of strings in structs. > > > * Docstrings on extension type attributes in .pxd files were rejected. > > > == Contributors == > > > Andreas van Cranenburgh > > > Ian Bell > > > Lars Buitinck > > > Martin Quarda > > > Mikhail Korobov > > > Robert Bradshaw > > > Stefan Behnel > > > ___ > > > cython-devel mailing list > > > cython-devel@python.org > > > https://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] buffmt.__test__.wrongsize gets stuck after common_include_dir?
while trying to re-test Debian package build, in an interactive shell, I get cython test stuck at: ... Doctest: buffmt.__test__.wrongsize ... ok runTest (__main__.EndToEndTest) End-to-end basic_cythonize ... ok runTest (__main__.EndToEndTest) End-to-end basic_distutils ... ok runTest (__main__.EndToEndTest) End-to-end build_dir ... ok runTest (__main__.EndToEndTest) End-to-end common_include_dir ... tests were executed using runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir any clues? is it multiprocessing to blame again? /bin/bash /tmp/hooks/C10shell /bin/bash /usr/bin/make -f debian/rules binary /usr/bin/perl -w /usr/bin/dh binary --with python2,python3 --buildsystem python_distutils /usr/bin/make -f debian/rules override_dh_auto_test /bin/sh -c set -e; for P in 2.7 3.4; do \ echo "PYTHON: $P"; \ export; \ PYTHONPATH=`/bin/ls -d /tmp/buildd/cython-0.20.2/build/lib.*-$P` \ /usr/bin/python$P runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir; \ done /usr/bin/python2.7 runtests.py --no-refnanny -v -v --exclude=parallel --work-dir=build/work-dir /bin/sh -c /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython bugfix release
On Mon, 21 Jul 2014, Julian Taylor wrote:
> I haven't tried it but its possibly related to the C locale the debian
> builders use. Try with LC_ALL=C
that is the one set
> @Yaroslav if this the the case, the workaround would be building with
> LC_ALL=C.UTF-8
good hint, although would not serve us as a workaround but rather possibly
reveals the actual problem if ran in interactive mode (if I pipe the output --
the same error)...
the original error happens in the code which reacts to unsuccessful execution
of GdbDebuggerTestCaseand apparently has a problem with that unicode string
(although it was decoded from UTF-8 without errors). To say the truth, unicode
handling philosophical understanding is not my strongest skill, BUT it seems to
spit out the actual error without failing if I explicitly encode that errmsg
back into UTF-8 and write that. Alternative more generic implementation there
could be get a custom writer for stderr:
class TestAll(GdbDebuggerTestCase):
def test_all(self):
if not test_gdb():
return
out, err = self.p.communicate()
err = err.decode('UTF-8')
exit_status = self.p.returncode
import codecs
stderr = codecs.getwriter('utf8')(sys.stderr)
if exit_status == 1:
stderr.write(err)
elif exit_status >= 2:
border = u'*' * 30
start = u'%s v INSIDE GDB v %s' % (border, border)
end= u'%s ^ INSIDE GDB ^ %s' % (border, border)
errmsg = u'\n%s\n%s%s' % (start, err, end)
stderr.write(errmsg)
With such code it spits out errmsg reliably:
python runtests.py --no-refnanny -v -v --exclude="parallel"
--work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul 4 2014, 13:08:34)
[GCC 4.9.0]
Running tests against Cython 0.20.2
Backends: c,cpp
test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
** v INSIDE GDB v **
warning: .cygdbinit: No such file or directory
EE...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception (u'a',):
EFSystemError: ../Objects/moduleobject.c:50: bad argument to internal function
E...SystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception The program being debugged was signaled
while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
ESystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception The program being debugged was signaled
while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
EE.EEE.E.FFF
==
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 387, in test_cyset
gdb.execute('cy set a = $cy_eval("{None: []}")')
File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1860, in
execute
_execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.
==
ERROR: test_backtrace
(Cython.Debugger.Tests.test_libcython_in_gdb.TestBacktrace)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 292, in test_backtrace
result = gdb.execute('cy bt', to_string=True)
File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1857, in
execute
_execute(command, from_tty)
error: Error occurred in Python command: 'FakeRepr' object has no attribute
'__getitem__'
MORE
> On 21.07.2014 19:46, Robert Bradshaw wrote:
> > I wasn't able to reproduce t
Re: [Cython] Cython bugfix release
apparently relates back to
"Failing cygdb tests on master and 0.19.x"
https://groups.google.com/forum/#!topic/cython-users/SRKdbfftjMM
and https://github.com/cython/cython/pull/264
blind attempt to run with python-dbg build doesn't provide a relief (gdb is
7.7.1-2)
# PYTHONPATH=$PWD/build/lib.linux-x86_64-2.7-pydebug python2.7-dbg runtests.py
--no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul 4 2014, 13:12:00)
[GCC 4.9.0]
Running tests against Cython 0.20.2
Backends: c,cpp
test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
** v INSIDE GDB v **
warning: .cygdbinit: No such file or directory
EF...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception (u'a',):
EFTraceback (most recent call last):
File "", line 1, in
NameError: name 'a' is not defined
F...Traceback (most recent call last):
File "", line 1, in
NameError: name 'a' is not defined
FTraceback (most recent call last):
File "", line 1, in
NameError: name 'some_random_var' is not defined
FE.EEE.E.FFF
==
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 387, in test_cyset
gdb.execute('cy set a = $cy_eval("{None: []}")')
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/libpython.py",
line 1860, in execute
_execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.
==
ERROR: test_inner (Cython.Debugger.Tests.test_libcython_in_gdb.TestClosure)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 420, in test_inner
self.assertEqual(str(self.read_var('a')), "'an object'")
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 72, in read_var
result = gdb.parse_and_eval('$cy_cvalue("%s")' % varname)
error: Error occurred in Python convenience function: (u'a',)
...
On Tue, 22 Jul 2014, Yaroslav Halchenko wrote:
> On Mon, 21 Jul 2014, Julian Taylor wrote:
> > I haven't tried it but its possibly related to the C locale the debian
> > builders use. Try with LC_ALL=C
> that is the one set
> > @Yaroslav if this the the case, the workaround would be building with
> > LC_ALL=C.UTF-8
> good hint, although would not serve us as a workaround but rather possibly
> reveals the actual problem if ran in interactive mode (if I pipe the output --
> the same error)...
> the original error happens in the code which reacts to unsuccessful execution
> of GdbDebuggerTestCaseand apparently has a problem with that unicode string
> (although it was decoded from UTF-8 without errors). To say the truth,
> unicode
> handling philosophical understanding is not my strongest skill, BUT it seems
> to
> spit out the actual error without failing if I explicitly encode that errmsg
> back into UTF-8 and write that. Alternative more generic implementation there
> could be get a custom writer for stderr:
> class TestAll(GdbDebuggerTestCase):
> def test_all(self):
> if not test_gdb():
> return
> out, err = self.p.communicate()
> err = err.decode('UTF-8')
> exit_status = self.p.returncode
> import codecs
> stderr = codecs.getwriter('utf8')(sys.stderr)
> if exit_status == 1:
> stderr.write(err)
> elif exit_status >= 2:
> border = u'*' * 30
> start = u'%s
Re: [Cython] Cython 0.21 released
congrats!
while preparing build for Debian I ran into good old (never got feedback
to my analysis done in Jul/Aug, thread "Cython bugfix release")
==
ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
--
Traceback (most recent call last):
File
"/home/yoh/deb/gits/build-area/cython-0.21/Cython/Debugger/Tests/TestLibCython.py",
line 280, in test_all
sys.stderr.write(errmsg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
23604-23607: ordinal not in range(128)
and few other failures:
==
FAIL: test_typing_function_int_loop (Cython.Tests.TestJediTyper.TestJediTyper)
--
Traceback (most recent call last):
File
"/home/yoh/deb/gits/build-area/cython-0.21/Cython/Tests/TestJediTyper.py", line
85, in test_typing_function_int_loop
self.assertIn(('func', (1, 0)), types)
AssertionError: ('func', (1, 0)) not found in {}
==
FAIL: test_typing_function_int_loop
(Cython.Tests.TestJediTyper.TestTypeInjection)
--
Traceback (most recent call last):
File
"/home/yoh/deb/gits/build-area/cython-0.21/Cython/Tests/TestJediTyper.py", line
85, in test_typing_function_int_loop
self.assertIn(('func', (1, 0)), types)
AssertionError: ('func', (1, 0)) not found in {}
--
Ran 8775 tests in 2249.908s
FAILED (failures=2, errors=1)
are they known/fixed?
On Wed, 10 Sep 2014, Stefan Behnel wrote:
> 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
> an
Re: [Cython] Cython 0.21 released
On Fri, 10 Oct 2014, Stefan Behnel wrote:
> Hi,
> thanks for the feedback.
> Yaroslav Halchenko schrieb am 08.10.2014 um 16:23:
> > while preparing build for Debian I ran into good old (never got feedback
> > to my analysis done in Jul/Aug, thread "Cython bugfix release")
> > ==
> > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> > --
> > Traceback (most recent call last):
> > File
> > "/home/yoh/deb/gits/build-area/cython-0.21/Cython/Debugger/Tests/TestLibCython.py",
> > line 280, in test_all
> > sys.stderr.write(errmsg)
> > UnicodeEncodeError: 'ascii' codec can't encode characters in position
> > 23604-23607: ordinal not in range(128)
> The debugger tests are generally broken at the moment.
thanks! I will try to exclude them then
> > and few other failures:
> > ==
> > FAIL: test_typing_function_int_loop
> > (Cython.Tests.TestJediTyper.TestJediTyper)
> > --
> > Traceback (most recent call last):
> > File
> > "/home/yoh/deb/gits/build-area/cython-0.21/Cython/Tests/TestJediTyper.py",
> > line 85, in test_typing_function_int_loop
> > self.assertIn(('func', (1, 0)), types)
> > AssertionError: ('func', (1, 0)) not found in {}
> > ==
> > FAIL: test_typing_function_int_loop
> > (Cython.Tests.TestJediTyper.TestTypeInjection)
> > --
> > Traceback (most recent call last):
> > File
> > "/home/yoh/deb/gits/build-area/cython-0.21/Cython/Tests/TestJediTyper.py",
> > line 85, in test_typing_function_int_loop
> > self.assertIn(('func', (1, 0)), types)
> > AssertionError: ('func', (1, 0)) not found in {}
> > --
> I faintly recall that there's a version dependency here, so I restricted
> the test runs to Jedi 0.8.1 and later.
cool -- cherry picked that one for the package -- thanks!
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.21 released
On Wed, 10 Sep 2014, Stefan Behnel wrote: > 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. a little change detected while down-stream testing builds in Debian (previous version was 0.20.2 and it built fine) ... vertex_format.last_shader = self for i in xrange(vertex_format.vattr_count): attr = &vertex_format.vattr[i] if attr.per_vertex == 0: continue attr.index = glGetAttribLocation(self.program, attr.name) ^ kivy/graphics/shader.pyx:448:63: Casting temporary Python object to non-numeric non-Python type I wondered if that is an intentional restriction now to restrict such casting only to numeric (and exclude the simplest form -- bytes/chars) or a regression? Cheers! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] kivy patch for: Cython 0.21 released
On Sat, 11 Oct 2014, Stefan Behnel wrote: > Yaroslav Halchenko schrieb am 11.10.2014 um 16:18: > > On Wed, 10 Sep 2014, Stefan Behnel wrote: > >> 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. > > a little change detected while down-stream testing builds in Debian > > (previous version was 0.20.2 and it built fine) > > > > ... > > vertex_format.last_shader = self > > for i in xrange(vertex_format.vattr_count): > > attr = &vertex_format.vattr[i] > > if attr.per_vertex == 0: > > continue > > attr.index = glGetAttribLocation(self.program, > *>attr.name) > >^ > > > > kivy/graphics/shader.pyx:448:63: Casting temporary Python object to > > non-numeric non-Python type > Wow, interesting piece of code. What's that even supposed to do? > Looking up their code, I find that "attr.name" is a char*: > https://github.com/kivy/kivy/blob/master/kivy/graphics/vertex.pxd > So the above code creates a temporary Python bytes object by copying data > from a char*, then gets the char* to the internal object buffer and throws > the object away, thus deleting its buffer. Then it passes that invalidated > char* into a function. I can't see how this makes any sense. And I'm happy > to see that Cython catches this kind of bug now. > > I wondered if that is an intentional restriction now to restrict such > > casting > > only to numeric (and exclude the simplest form -- bytes/chars) or a > > regression? > It seems they fixed their code already: > https://github.com/kivy/kivy/commit/827bd6c7b7d04ec72cb3bdbf0ffcd90630d90008 Gotcha -- THANKS a bunch for a detailed response! CCing kivy maintainers in Debian -- get ready for upcoming cython 0.21 upload - a little patch to pick up! ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] s3ql and llfuse FTBFS Re: Cython 0.21 released
On Wed, 10 Sep 2014, Stefan Behnel wrote:
> 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.
in two packages (s3ql, python-llfuse) so far I have ran into
Traceback (most recent call last):
File "setup.py", line 304, in
main()
File "setup.py", line 182, in main
command_options={ 'sdist': { 'formats': ('setup.py', 'bztar') } },
File "/usr/lib/python3.4/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.4/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.4/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "setup.py", line 228, in run
**options)
File "/usr/lib/python3/dist-packages/Cython/Compiler/Main.py", line 620, in
compile
options = CompilationOptions(defaults = options, **kwds)
File "/usr/lib/python3/dist-packages/Cython/Compiler/Main.py", line 501, in
__init__
', '.join(unknown_options)))
ValueError: got unexpected compilation options: warning_errors, recursive
looking at s3ql those are provided to cython_compile call and packages built
successfully before.
I see that recursive option was removed in 0.20b1~505 so not sure how it built
before with 0.20.2 (probably providing "bogus" options just didn't trigger this
ValueError). Would you advise on the ideal course of patching? (CCing
maintainers of those packages)
P.S. besides those few of manageable failures I have reported, haven't found
any other new hiccups (there also was a failing unittest in bzr but not even
yet sure if cython related or just a fluke), so will shortly upload 0.21 to
Debian sid and backports to -devel repository of NeuroDebian.
Cheers!
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Release candidate for Cython 0.21.1
FWIW -- uploaded to Debian sid. 0.21.0 experienced some issues during tests on some exotic platforms but probably not due to cython's issues (tried manually on sparc -- built fine): https://buildd.debian.org/status/package.php?p=cython&suite=unstable Cheers and thanks for keeping Cython going strong! On Wed, 15 Oct 2014, Stefan Behnel wrote: > Hi everyone, > I uploaded a candidate for a 0.21.1 bug fix release. > http://cython.org/release/Cython-0.21.1pre.tar.gz > It adds a few minor new features and some bug fixes and corrections. Please > give it a quick try, especially if you reported problems that this release > should fix. I had to manually select changes from the master branch, so I > hope I didn't forget anything. > Stefan > Features added > -- > * New ``cythonize`` option ``-a`` to generate the annotated HTML source > view. > * Missing C-API declarations in ``cpython.unicode`` were added. > * Passing ``language='c++'`` into cythonize() globally enables C++ mode for > all modules that were not passed as Extension objects (i.e. only source > files and file patterns). > * ``Py_hash_t`` is a known type (used in CPython for hash values). > * ``PySlice_*()`` C-API functions are available from the ``cpython.slice`` > module. > * Allow arrays of C++ classes. > Bugs fixed > -- > * Reference leak for non-simple Python expressions in boolean and/or > expressions. > * To fix a name collision and to reflect availability on host platforms, > standard C declarations [ clock(), time(), struct tm and tm* functions ] > were moved from posix/time.pxd to a new libc/time.pxd. Patch by Charles > Blake. > * Rerunning unmodified modules in IPython's cython support failed. > Patch by Matthias Bussonier. > * Casting C++ ``std::string`` to Python byte strings failed when > auto-decoding was enabled. > * Fatal exceptions in global module init code could lead to crashes > if the already created module was used later on (e.g. through a > stale reference in sys.modules or elsewhere). > Other changes > - > * Compilation no longer fails hard when unknown compilation options are > passed. Instead, it raises a warning and ignores them (as it did > silently before 0.21). This will be changed back to an error in a > future release. > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] ct_DEF.__test__.large_nums doctest failing in 32bit
was reported in Debian against 0.23.2 so tried blindly freshier snapshot from 0.23.x branch and that one is no go too: == FAIL: large_nums (line 95) (ct_DEF.__test__) Doctest: ct_DEF.__test__.large_nums (line 95) -- Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 2226, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for ct_DEF.__test__.large_nums (line 95) File "/tmp/buildd/cython-0.23.2+git12-g2c9d175/build/work-dir/run/cpp/ct_DEF/ct_DEF.so", line unknown line number, in large_nums (line 95) -- File "/tmp/buildd/cython-0.23.2+git12-g2c9d175/build/work-dir/run/cpp/ct_DEF/ct_DEF.so", line ?, in ct_DEF.__test__.large_nums (line 95) Failed example: print_large_number(n64) Expected: -4294967295 Got: 1 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] ct_DEF.__test__.large_nums doctest failing in 32bit
On Tue, 22 Sep 2015, Stefan Behnel wrote: > > Expected: > > -4294967295 > > Got: > > 1 > I cannot reproduce this locally (even tried a 32bit docker container), so I > blindly changed a couple of minor things in that branch. Could you give it > another try? > If that didn't help, here is a patch that adds a longness suffix to plain > integer literals based on their type (e.g. found after coercions). I'm not > sure yet if that's really a good idea, but would be helpful to know if it > fixes this test. Could you try both and report back? thanks -- will do! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] ct_DEF.__test__.large_nums doctest failing in 32bit
On Wed, 23 Sep 2015, Yaroslav Halchenko wrote: > On Tue, 22 Sep 2015, Stefan Behnel wrote: > > > Expected: > > > -4294967295 > > > Got: > > > 1 > > I cannot reproduce this locally (even tried a 32bit docker container), so I > > blindly changed a couple of minor things in that branch. Could you give it > > another try? > > If that didn't help, here is a patch that adds a longness suffix to plain > > integer literals based on their type (e.g. found after coercions). I'm not > > sure yet if that's really a good idea, but would be helpful to know if it > > fixes this test. Could you try both and report back? > thanks -- will do! reporting: it did need guess_longness.patch to pass Thanks! -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython-0.23.4 build failing on gcc6 for upcoming fedora 24
On Fri, 12 Feb 2016, Stefan Behnel wrote:
> >> ==
> >> FAIL: runTest (__main__.EndToEndTest)
> >> End-to-end asyncio_generators
> >> --
> >> Traceback (most recent call last):
> >> File "runtests.py", line 1417, in runTest
> >> self.assertEqual(0, res, "non-zero exit status")
> >> AssertionError: 0 != 1 : non-zero exit status
> >> --
> >> Not sure about this one (especially why it would be compiler dependent).
> > It's not compiler dependent. It's an incompatibility between Cython and
> > CPython's asyncio. Might be related to the fact that asyncio's Future is
> > both iterable and awaitable. Or something else... I looked into it but
> > couldn't figure it out yet.
> Found it:
> https://github.com/cython/cython/commit/7eed8d8ff9c872bc993a37438beca0f98e3aba38
I saw that one with 0.23.4 so went for that tip 7eed8d8 of 0.23.x and it
resolved it for my builds across releases and architectures UNTIL I got
this bugreport pointing to failure on hurd which is also accompanied with 2
other errors which seems to do with python's incompatibility itself with hurd.
Would those 2 errors lead to the failure of the test in question here? ;)
https://buildd.debian.org/status/fetch.php?pkg=cython&arch=hurd-i386&ver=0.23.4%2Bgit4-g7eed8d8-1&stamp=1455917417
==
ERROR: test_asyncio_1 (test_coroutines_pep492.CoroAsyncIOCompatTest)
--
make[1]: *** [override_dh_auto_test] Error 1
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
Traceback (most recent call last):
File "tests/run/test_coroutines_pep492.pyx", line 1493, in
test_coroutines_pep492.CoroAsyncIOCompatTest.test_asyncio_1
(test_coroutines_pep492.c:66658)
loop = asyncio.new_event_loop()
File "/usr/lib/python3.5/asyncio/events.py", line 636, in new_event_loop
return get_event_loop_policy().new_event_loop()
File "/usr/lib/python3.5/asyncio/events.py", line 587, in new_event_loop
return self._loop_factory()
File "/usr/lib/python3.5/asyncio/unix_events.py", line 49, in __init__
super().__init__(selector)
File "/usr/lib/python3.5/asyncio/selector_events.py", line 49, in __init__
super().__init__()
File "/usr/lib/python3.5/asyncio/base_events.py", line 224, in __init__
self._clock_resolution = time.get_clock_info('monotonic').resolution
OSError: [Errno 1073741846] Invalid argument
==
ERROR: test_asyncio_1 (test_coroutines_pep492.CoroAsyncIOCompatTest)
--
Traceback (most recent call last):
File "tests/run/test_coroutines_pep492.pyx", line 1493, in
test_coroutines_pep492.CoroAsyncIOCompatTest.test_asyncio_1
(test_coroutines_pep492.cpp:7)
loop = asyncio.new_event_loop()
File "/usr/lib/python3.5/asyncio/events.py", line 636, in new_event_loop
return get_event_loop_policy().new_event_loop()
File "/usr/lib/python3.5/asyncio/events.py", line 587, in new_event_loop
return self._loop_factory()
File "/usr/lib/python3.5/asyncio/unix_events.py", line 49, in __init__
super().__init__(selector)
File "/usr/lib/python3.5/asyncio/selector_events.py", line 49, in __init__
super().__init__()
File "/usr/lib/python3.5/asyncio/base_events.py", line 224, in __init__
self._clock_resolution = time.get_clock_info('monotonic').resolution
OSError: [Errno 1073741846] Invalid argument
==
FAIL: runTest (__main__.EndToEndTest)
End-to-end asyncio_generators
--
Traceback (most recent call last):
File "runtests.py", line 1417, in runTest
self.assertEqual(0, res, "non-zero exit status")
AssertionError: 0 != 1 : non-zero exit status
--
Ran 10019 tests in 3019.340s
FAILED (failures=1, errors=2)
Following tests excluded because of missing dependencies on your system:
Cython.Coverage
if interested -- there is few other interesting failures for x32
(https://wiki.debian.org/X32Port) port:
https://buildd.debian.org/status/fetch.php?pkg=cython&arch=x32&ver=0.23.4%2Bgit4-g7eed8d8-1&stamp=1455910693
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
https://mail.python
[Cython] long_double_to_float_int failure on s390x (BE) (0.24.1)
Dear Cython ppl, Didn't spot any obvious commit/log since 0.24.1 so decided just to report: full build log: https://buildd.debian.org/status/fetch.php?pkg=cython&arch=s390x&ver=0.24.1-1&stamp=1470118175 1 test has failed on s390x (only). Quick resolution would help to assure cython's healthy status in debian coming to a freeze point. == FAIL: long_double_to_float_int (line 195) (int_float_builtins_as_casts_T400.__test__) Doctest: int_float_builtins_as_casts_T400.__test__.long_double_to_float_int (line 195) -- Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 2226, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for int_float_builtins_as_casts_T400.__test__.long_double_to_float_int (line 195) File "/«PKGBUILDDIR»/build/work-dir/run/c/int_float_builtins_as_casts_T400/int_float_builtins_as_casts_T400.so", line unknown line number, in long_double_to_float_int (line 195) -- File "/«PKGBUILDDIR»/build/work-dir/run/c/int_float_builtins_as_casts_T400/int_float_builtins_as_casts_T400.so", line ?, in int_float_builtins_as_casts_T400.__test__.long_double_to_float_int (line 195) Failed example: long_double_to_float_int(4.1) Expected: 4.0 Got: 0.0 -- File "/«PKGBUILDDIR»/build/work-dir/run/c/int_float_builtins_as_casts_T400/int_float_builtins_as_casts_T400.so", line ?, in int_float_builtins_as_casts_T400.__test__.long_double_to_float_int (line 195) Failed example: long_double_to_float_int(-4.1) Expected: -4.0 Got: 0.0 -- File "/«PKGBUILDDIR»/build/work-dir/run/c/int_float_builtins_as_casts_T400/int_float_builtins_as_casts_T400.so", line ?, in int_float_builtins_as_casts_T400.__test__.long_double_to_float_int (line 195) Failed example: long_double_to_float_int(4) Expected: 4.0 Got: 0.0 -- Ran 9957 tests in 4237.557s FAILED (failures=1, skipped=2) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] long_double_to_float_int failure on s390x (BE) (0.24.1)
On Wed, 10 Aug 2016, Robert Bradshaw wrote: > Is this a change from 0.24? Do you have any s390x hardware that we > could test on? if anything it is a "change" from 0.23.4+git4-g7eed8d8-2 ... but the thing is that since my email Jakub Wilk reported that he hasn't observed this failure while building on s390x only few days ago, so it might have been some toolchain fluke. I have asked for a rebuild, so let's wait for it and if reproduces, I will see what we could do about access or at least more info to troubleshoot. Cheers -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] long_double_to_float_int failure on s390x (BE) (0.24.1)
On Thu, 11 Aug 2016, Yaroslav Halchenko wrote: > On Wed, 10 Aug 2016, Robert Bradshaw wrote: > > Is this a change from 0.24? Do you have any s390x hardware that we > > could test on? > if anything it is a "change" from 0.23.4+git4-g7eed8d8-2 ... but the > thing is that since my email Jakub Wilk reported that he hasn't > observed this failure while building on s390x only few days ago, so it > might have been some toolchain fluke. I have asked for a rebuild, so > let's wait for it and if reproduces, I will see what we could do about > access or at least more info to troubleshoot. confirming that issue was gone in rebuild: https://buildd.debian.org/status/logs.php?pkg=cython&ver=0.24.1-1&arch=s390x Thank you and Cheers -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] 0.25.1 annotate_html UnicodeDecodeError
Ran into it while building a package for Debian
==
FAIL: annotate_html ()
Doctest: annotate_html
--
Traceback (most recent call last):
File "/usr/lib/python3.5/doctest.py", line 2190, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for annotate_html
File
"/build/cython-0.25.1/build/work-dir/run/cpp/annotate_html/annotate_html.cpython-35m-x86_64-linux-gnu.so",
line 1, in annotate_html
--
File
"/build/cython-0.25.1/build/work-dir/run/cpp/annotate_html/annotate_html.cpython-35m-x86_64-linux-gnu.so",
line 9, in annotate_html
Failed example:
with open(module_path + '.html') as html_file:
html = html_file.read()
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python3.5/doctest.py", line 1321, in __run
compileflags, 1), test.globs)
File "", line 2, in
html = html_file.read()
File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 16904:
ordinal not in range(128)
which then leads also to
--
File
"/build/cython-0.25.1/build/work-dir/run/cpp/annotate_html/annotate_html.cpython-35m-x86_64-linux-gnu.so",
line 13, in annotate_html
Failed example:
assert re.search('', html)
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python3.5/doctest.py", line 1321, in __run
compileflags, 1), test.globs)
File "", line 1, in
assert re.search('', html)
NameError: name 'html' is not defined
I guess some locale setting/assumptions?
btw -- what is the "proper" way to run this doctest alone using
runtests.py?
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
[Cython] lshift_int test failing Re: Cython 0.25.2
On Thu, 17 Nov 2016, Robert Bradshaw wrote: > I'm preparing another bugfix release. Try it out at > https://github.com/cython/cython/archive/966a296ac4e4862dee9a571ee412886ca3c61144.zip on some platforms , e.g. armel: https://buildd.debian.org/status/fetch.php?pkg=cython&arch=armel&ver=0.25.2~b0-1&stamp=1479637337 https://buildd.debian.org/status/fetch.php?pkg=cython&arch=armhf&ver=0.25.2~b0-1&stamp=1479632680 and even https://buildd.debian.org/status/fetch.php?pkg=cython&arch=i386&ver=0.25.2~b0-1&stamp=1479619359 (although there it looks even with other additional failure in the test, please checkout): == FAIL: lshift_int (line 137) (pyintop.__test__) Doctest: pyintop.__test__.lshift_int (line 137) -- Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 2226, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for pyintop.__test__.lshift_int (line 137) File "/«PKGBUILDDIR»/build/work-dir/3/run/c/pyintop/pyintop.so", line unknown line number, in lshift_int (line 137) -- File "/«PKGBUILDDIR»/build/work-dir/3/run/c/pyintop/pyintop.so", line ?, in pyintop.__test__.lshift_int (line 137) Failed example: (2**28) << 3 Expected: 2147483648 Got: 2147483648L -- File "/«PKGBUILDDIR»/build/work-dir/3/run/c/pyintop/pyintop.so", line ?, in pyintop.__test__.lshift_int (line 137) Failed example: (2**30) << 3 Expected: 8589934592 Got: 8589934592L == FAIL: lshift_int (line 137) (pyintop.__test__) Doctest: pyintop.__test__.lshift_int (line 137) -- Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 2226, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for pyintop.__test__.lshift_int (line 137) File "/«PKGBUILDDIR»/build/work-dir/3/run/cpp/pyintop/pyintop.so", line unknown line number, in lshift_int (line 137) -- File "/«PKGBUILDDIR»/build/work-dir/3/run/cpp/pyintop/pyintop.so", line ?, in pyintop.__test__.lshift_int (line 137) Failed example: (2**28) << 3 Expected: 2147483648 Got: 2147483648L -- File "/«PKGBUILDDIR»/build/work-dir/3/run/cpp/pyintop/pyintop.so", line ?, in pyintop.__test__.lshift_int (line 137) Failed example: (2**30) << 3 Expected: 8589934592 Got: 8589934592L -- Ran 2377 tests in 4617.354s FAILED (failures=2) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] 0.25.2b0 with 32bit fixes: (sometimes) Interrupted system call in builtin_subtype_methods_T653
A fresh one I ran into while rebuilding with fixes for 32bit (thanks BTW! sorry for not prompt followup/gratitude) == ERROR: runTest (__main__.CythonRunTestCase) compiling (cpp) and running builtin_subtype_methods_T653 -- Traceback (most recent call last): File "runtests.py", line 998, in run self.run_tests(result, ext_so_path) File "runtests.py", line 1013, in run_tests self.run_doctests(self.module, result, ext_so_path) File "runtests.py", line 1023, in run_doctests run_forked_test(result, run_test, self.shortDescription(), self.fork) File "runtests.py", line 1076, in run_forked_test cid, result_code = os.waitpid(child_id, 0) OSError: [Errno 4] Interrupted system call -- Ran 581 tests in 188.225s FAILED (errors=1) it is not 100% reproducible. Rebuilding the package went smooth without this hiccup. Just wanted to let you know might be related that the tests were ran as set -e; for P in 2.7 3.5; do \ PYTHONPATH=`/bin/ls -d /build/cython-0.25.2~b0/build/lib.*-$P` \ /usr/bin/python$P runtests.py --shard_count=16 \ --no-refnanny -v -v --exclude="(parallel|Debugger|annotate_html)" --work-dir=build/work-dir 2>&1; \ done so testing in parallel to speed up the build of the package. This one was the only failure I have ran into but it built fine before (but there could have been some changes in the core packages since then) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] verify_resolution_GH1533
Dear Cython gurus, How to skip this test? It is causing failures on i386: https://github.com/cython/cython/issues/1548 and I have tried to skip it, so my test running line now is set -e; for P in 2.7 3.5; do \ PYTHONPATH=`/bin/ls -d /build/cython-0.25.2/build/lib.*-$P` \ /usr/bin/python$P runtests.py --shard_count=16 \ --no-refnanny -v -v --exclude="(parallel|Debugger|annotate_html|numpy_test|verify_resolution_GH1533)" --work-dir=build/work-dir 2>&1; \ done NB numpy_test skip due to https://github.com/cython/cython/issues/1589 but the test still runs and fails: FAIL: verify_resolution_GH1533 (line 90) (cpdef_enums.__test__) Doctest: cpdef_enums.__test__.verify_resolution_GH1533 (line 90) -- Traceback (most recent call last): File "/usr/lib/python2.7/doctest.py", line 2226, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for cpdef_enums.__test__.verify_resolution_GH1533 (line 90) File "/build/cython-0.25.2/build/work-dir/15/run/c/cpdef_enums/cpdef_enums.so", line unknown line number, in verify_resolution_GH1533 (line 90) -- File "/build/cython-0.25.2/build/work-dir/15/run/c/cpdef_enums/cpdef_enums.so", line ?, in cpdef_enums.__test__.verify_resolution_GH1533 (line 90) Failed example: verify_resolution_GH1533() Expected: 3 Got: 3L -- Ran 676 tests in 247.426s FAILED (failures=1) quick reply would be appreciate -- running out of time to upload 0.25.2 into debian for stretch full freeze Cheers -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] verify_resolution_GH1533
On Tue, 24 Jan 2017, Robert Bradshaw wrote: > Ah, if the enum is unsigned and has the same size as unsigned long, this > could happen. I pushed > https://github.com/cython/cython/commit/d92a718a26c9354fbf35f31a17de5c069865a447 > for future release. Great -- thank you! meanwhile used the same "workaround" ;) 0.25.2 was uploaded to debian sid with hope for it to migrate to stretch for upcoming release -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.25.2b0 with 32bit fixes: (sometimes) Interrupted system call in builtin_subtype_methods_T653
Dear Robert Sorry that I haven't followed up :-( FWIW -- I haven't observed it recently while building 0.26~b0, detected issues for which I have just filed at https://github.com/cython/cython/issues Cheers, On Wed, 30 Nov 2016, Robert Bradshaw wrote: > When it does reproduce, is it always this particular test? > On Wed, Nov 30, 2016 at 6:46 AM, Yaroslav Halchenko > wrote: > > A fresh one I ran into while rebuilding with fixes for 32bit (thanks > > BTW! sorry for not prompt followup/gratitude) > > == > > ERROR: runTest (__main__.CythonRunTestCase) > > compiling (cpp) and running builtin_subtype_methods_T653 > > -- > > Traceback (most recent call last): > > File "runtests.py", line 998, in run > > self.run_tests(result, ext_so_path) > > File "runtests.py", line 1013, in run_tests > > self.run_doctests(self.module, result, ext_so_path) > > File "runtests.py", line 1023, in run_doctests > > run_forked_test(result, run_test, self.shortDescription(), self.fork) > > File "runtests.py", line 1076, in run_forked_test > > cid, result_code = os.waitpid(child_id, 0) > > OSError: [Errno 4] Interrupted system call > > -- > > Ran 581 tests in 188.225s > > FAILED (errors=1) > > it is not 100% reproducible. Rebuilding the package went smooth without > > this > > hiccup. Just wanted to let you know > > might be related that the tests were ran as > > set -e; for P in 2.7 3.5; do \ > > PYTHONPATH=`/bin/ls -d /build/cython-0.25.2~b0/build/lib.*-$P` \ > > /usr/bin/python$P runtests.py --shard_count=16 \ > > --no-refnanny -v -v --exclude="(parallel|Debugger|annotate_html)" > > --work-dir=build/work-dir 2>&1; \ > > done > > so testing in parallel to speed up the build of the package. This one was > > the > > only failure I have ran into but it built fine before (but there could have > > been some changes in the core packages since then) > > -- > > Yaroslav O. Halchenko > > Center for Open Neuroscience http://centerforopenneuroscience.org > > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > > WWW: http://www.linkedin.com/in/yarik > > ___ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
