From robertwb at gmail.com Wed Jan 4 01:46:28 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 3 Jan 2017 22:46:28 -0800 Subject: [Cython] Changing the default value of exception propagation Message-ID: By default a cdef (or cpdef) function returning C type suppresses all exceptions, which is quite surprising to new (and old) users, and makes debugging difficult. I would propose that we make exception propagation the default. The primary motivation to not do this would be for fear of performance regression, especially for external functions that can't possibly raise exceptions. While the the catch-all "except *" does seem to have non-trivial overhead, the "except? value" version looks indistinguishable from no exception throwing at all (in tight loops, yay branch prediction, would be interested in what other people see [1]). Does this sound like a reasonable proposal? There are still some open questions, e.g. - What value should we pick. We want something unlikely, but recognizable to external code (e.g. 0xBadBad). - What about non-numeric/pointer/reference types; are there other sentinel values we could use? - Should we default to except * in that case? Presumably these are likely to be more expensive functions anyways (making the relative cost lower). - Or could we use, essentially, reinterpret_cast to get a possible error value? This could work for PODs (including C structs) but destructors could wreck havoc here. - Should we add syntax (e.g. "except -") to manually obtain the old behavior? Or should such be done by surrounding the entire block with an try/bare except statement? This wouldn't catch argument-parsing errors. (Another crazy idea, though I'm not sold, is lifting an initial try and with block that spans the full function body to above the argument parsing--this could simply the gil syntax as well.) - Robert [1] https://gist.github.com/robertwb/0ef6bfaa3c9b2ea11ed64d1c1a0bda43 time_with_nothing 0.0322368144989 3.22368144989e-08 time_with_star 0.097442150116 9.7442150116e-08 time_with_value 0.0940091609955 9.40091609955e-08 time_with_maybe_value 0.10076379776 1.0076379776e-07 time_with_nothing 0.0767869949341 3.8393497467e-08 time_with_star 0.189253091812 9.46265459061e-08 time_with_value 0.176230192184 8.81150960922e-08 time_with_maybe_value 0.179567098618 8.97835493088e-08 time_with_nothing 0.110851049423 3.69503498077e-08 time_with_star 0.268408060074 8.9469353358e-08 time_with_value 0.254024982452 8.46749941508e-08 time_with_maybe_value 0.244876861572 8.16256205241e-08 time_with_nothing 0.138132095337 3.45330238342e-08 time_with_star 0.345059156418 8.62647891045e-08 time_with_value 0.329736948013 8.24342370033e-08 time_with_maybe_value 0.341785907745 8.54464769363e-08 time_with_nothing 0.0680961608887 6.80961608887e-10 time_with_star 0.285541057587 2.85541057587e-09 time_with_value 0.0707340240479 7.07340240479e-10 time_with_maybe_value 0.0762150287628 7.62150287628e-10 time_with_nothing 0.148243904114 7.41219520569e-10 time_with_star 0.560220956802 2.80110478401e-09 time_with_value 0.136430978775 6.82154893875e-10 time_with_maybe_value 0.143126964569 7.15634822845e-10 time_with_nothing 0.211837053299 7.06123510997e-10 time_with_star 0.812189102173 2.70729700724e-09 time_with_value 0.197682142258 6.58940474192e-10 time_with_maybe_value 0.203264951706 6.7754983902e-10 time_with_nothing 0.283420085907 7.08550214767e-10 time_with_star 1.09991884232 2.74979710579e-09 time_with_value 0.281104803085 7.02762007713e-10 time_with_maybe_value 0.288016080856 7.20040202141e-10 DONE From stefan_ml at behnel.de Thu Jan 5 05:31:00 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 5 Jan 2017 11:31:00 +0100 Subject: [Cython] Changing the default value of exception propagation In-Reply-To: References: Message-ID: <393d57f4-58ef-e353-73a9-d9f0a1dc2a3e@behnel.de> Hi Robert! Robert Bradshaw schrieb am 04.01.2017 um 07:46: > By default a cdef (or cpdef) function returning C type suppresses all > exceptions, which is quite surprising to new (and old) users, and > makes debugging difficult. I would propose that we make exception > propagation the default. > > The primary motivation to not do this would be for fear of performance > regression, especially for external functions that can't possibly > raise exceptions. While the the catch-all "except *" does seem to have > non-trivial overhead, the "except? value" version looks > indistinguishable from no exception throwing at all (in tight loops, > yay branch prediction, would be interested in what other people see > [1]). > > Does this sound like a reasonable proposal? Sounds good to me. > There are still some open questions, e.g. > > - What value should we pick. We want something unlikely, but > recognizable to external code (e.g. 0xBadBad). Depends on the value type, obviously. Seems like there should be one error value per C type, e.g. pointer: NULL? (or maybe 1 ?) char: 0xEF short: 0xBad int/long/etc.: 0xBadBad What about C++ in general? Should we also default to catching C++ exceptions? (Separate proposal, but IIRC that's also still an open issue?) > - What about non-numeric/pointer/reference types; are there other > sentinel values we could use? I can't see a way to handle struct/union. Well, we could handle a union that involves an integer, but returning a plain union is fairly unlikely to occur in practice, so the main thing here are structs (and pass-by-value C++ objects, I guess). > - Should we default to except * in that case? Presumably these are > likely to be more expensive functions anyways (making the relative > cost lower). Depends on how the C compiler implements them. If it inlines a function that returns a struct (e.g. because the function is only called in one place), the overhead of "returning" that struct would become negligible and the exception check overhead could easily show up. But I agree with your intuition that returning something non-trivial from a function suggests a non-trivial implementation of the function. > - Or could we use, essentially, reinterpret_cast to get a possible > error value? This could work for PODs (including C structs) but > destructors could wreck havoc here. A solution for C would already help, regardless of anything we could or could not do for C++. > - Should we add syntax (e.g. "except -") to manually obtain the old > behavior? Question is: when would we want that? Should we really trade the weird WriteUnraisable() behaviour for speed here? I think, an unraisable exception is always a bug, even if it doesn't appear in practice. If there's not enough memory, exceptions can occur in any place, and shadowing them in unexpected places can do arbitrary harm to your system, especially if it doesn't crash but continues running in an inconsistent state. > Or should such be done by surrounding the entire block with > an try/bare except statement? This wouldn't catch argument-parsing > errors. Argument parsing errors cannot occur for cdef functions and C level calls to cpdef functions, as they would appear on caller side, before even calling the function. For Python level calls, I don't think we need to care. > (Another crazy idea, though I'm not sold, is lifting an > initial try and with block that spans the full function body to above > the argument parsing--this could simply the gil syntax as well.) This is unprecedented in Python. If you pass positional arguments into a function that only accepts keyword arguments, for example, you will get a TypeError regardless of what your function body looks like. We could restrict it to argument type conversion, but that would still make things less understandable. My preference (for now) would be to switch and wait for real world legacy use cases to show up. Stefan From robertwb at gmail.com Thu Jan 5 13:12:34 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 5 Jan 2017 10:12:34 -0800 Subject: [Cython] Changing the default value of exception propagation In-Reply-To: <393d57f4-58ef-e353-73a9-d9f0a1dc2a3e@behnel.de> References: <393d57f4-58ef-e353-73a9-d9f0a1dc2a3e@behnel.de> Message-ID: On Thu, Jan 5, 2017 at 2:31 AM, Stefan Behnel wrote: > Hi Robert! > > Robert Bradshaw schrieb am 04.01.2017 um 07:46: >> By default a cdef (or cpdef) function returning C type suppresses all >> exceptions, which is quite surprising to new (and old) users, and >> makes debugging difficult. I would propose that we make exception >> propagation the default. >> >> The primary motivation to not do this would be for fear of performance >> regression, especially for external functions that can't possibly >> raise exceptions. While the the catch-all "except *" does seem to have >> non-trivial overhead, the "except? value" version looks >> indistinguishable from no exception throwing at all (in tight loops, >> yay branch prediction, would be interested in what other people see >> [1]). >> >> Does this sound like a reasonable proposal? > > Sounds good to me. > > >> There are still some open questions, e.g. >> >> - What value should we pick. We want something unlikely, but >> recognizable to external code (e.g. 0xBadBad). > > Depends on the value type, obviously. Seems like there should be one error > value per C type, e.g. > > pointer: NULL? (or maybe 1 ?) > char: 0xEF > short: 0xBad > int/long/etc.: 0xBadBad It'd be nice if it were consistent, e.g. (type)0xBadBad when possible. But I think we'll need to do this per type. > What about C++ in general? Should we also default to catching C++ > exceptions? (Separate proposal, but IIRC that's also still an open issue?) I think the primary surprise is from Python users who make (or convert) a couple of c[p]def functions and are surprised in the change in behavior. Hadn't thought about wrapping every single C function call in a try...catch statement. Wonder what the overhead (time and space) of that would be. >> - What about non-numeric/pointer/reference types; are there other >> sentinel values we could use? > > I can't see a way to handle struct/union. Well, we could handle a union > that involves an integer, but returning a plain union is fairly unlikely to > occur in practice, so the main thing here are structs (and pass-by-value > C++ objects, I guess). > >> - Should we default to except * in that case? Presumably these are >> likely to be more expensive functions anyways (making the relative >> cost lower). > > Depends on how the C compiler implements them. If it inlines a function > that returns a struct (e.g. because the function is only called in one > place), the overhead of "returning" that struct would become negligible and > the exception check overhead could easily show up. > > But I agree with your intuition that returning something non-trivial from a > function suggests a non-trivial implementation of the function. > > >> - Or could we use, essentially, reinterpret_cast to get a possible >> error value? This could work for PODs (including C structs) but >> destructors could wreck havoc here. > > A solution for C would already help, regardless of anything we could or > could not do for C++. We need to consider C++ though, especially as things declared as structs may actually be C++ classes, or contain C++ class members. >> - Should we add syntax (e.g. "except -") to manually obtain the old >> behavior? > > Question is: when would we want that? Should we really trade the weird > WriteUnraisable() behaviour for speed here? I think, an unraisable > exception is always a bug, even if it doesn't appear in practice. If > there's not enough memory, exceptions can occur in any place, and shadowing > them in unexpected places can do arbitrary harm to your system, especially > if it doesn't crash but continues running in an inconsistent state. There is the case that the function in question is a callback with no ways to report errors--one might prefer to at least print something. >> Or should such be done by surrounding the entire block with >> an try/bare except statement? This wouldn't catch argument-parsing >> errors. > > Argument parsing errors cannot occur for cdef functions and C level calls > to cpdef functions, as they would appear on caller side, before even > calling the function. For Python level calls, I don't think we need to care. > >> (Another crazy idea, though I'm not sold, is lifting an >> initial try and with block that spans the full function body to above >> the argument parsing--this could simply the gil syntax as well.) > > This is unprecedented in Python. If you pass positional arguments into a > function that only accepts keyword arguments, for example, you will get a > TypeError regardless of what your function body looks like. > > We could restrict it to argument type conversion, but that would still make > things less understandable. Good point about argument parsing not being needed for cdef functions. Given the other issues, I agree it's best not to do this. > My preference (for now) would be to switch and wait for real world legacy > use cases to show up. Sounds good. From stefan_ml at behnel.de Fri Jan 6 04:41:36 2017 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 6 Jan 2017 10:41:36 +0100 Subject: [Cython] Changing the default value of exception propagation In-Reply-To: References: <393d57f4-58ef-e353-73a9-d9f0a1dc2a3e@behnel.de> Message-ID: <0ab72e56-0f3a-28de-bea1-9ebcc5ac013a@behnel.de> Robert Bradshaw schrieb am 05.01.2017 um 19:12: > On Thu, Jan 5, 2017 at 2:31 AM, Stefan Behnel wrote: >> Robert Bradshaw schrieb am 04.01.2017 um 07:46: >>> By default a cdef (or cpdef) function returning C type suppresses all >>> exceptions, which is quite surprising to new (and old) users, and >>> makes debugging difficult. I would propose that we make exception >>> propagation the default. >>> [...] >>> - Should we add syntax (e.g. "except -") to manually obtain the old >>> behavior? >> >> Question is: when would we want that? Should we really trade the weird >> WriteUnraisable() behaviour for speed here? I think, an unraisable >> exception is always a bug, even if it doesn't appear in practice. If >> there's not enough memory, exceptions can occur in any place, and shadowing >> them in unexpected places can do arbitrary harm to your system, especially >> if it doesn't crash but continues running in an inconsistent state. > > There is the case that the function in question is a callback with no > ways to report errors--one might prefer to at least print something. Ah, yes. For some reason, I hadn't thought of callbacks when I wrote that. The current behaviour is for void functions to print the exception and return, and for non-void functions to print the exception and return the default value of the return type, usually -1. We would change that to keeping the exception and returning a different value (if non-void). The different return value might have an impact on the calling code, although it could be argued that even returning -1 can already trigger bugs. There are a couple of patterns for exception handling in callbacks. 1) Print and ignore exception. This is what happens currently, with the caveat of returning -1 or NULL behind the user's back. There is currently no way to change that value, but it can be dealt with in the same way as the example in 3) below, also for void functions. 2) Keep the exception alive, so that some outer caller can handle it. This can be done with the "except" signature declarations. 3) Store exception away and return. This is actually more tricky than you might think, as storing away (or printing or logging) the exception might fail and raise a new exception. There is a code pattern for this, though: cdef int callback(): error = True try: do_stuff() error = False except: store_raised_exception() # might raise! finally: # swallow any further exceptions return -1 if error else 0 Explicitly returning from a finally clause eats the exception, whereas otherwise the except clause might raise its own exceptions, even just while trying to retrieve the current exception (i.e. before even entering the body of the except clause). By leaving out the except clause, any exception will be silently ignored, but I'd obviously not encourage doing that. Unless I missed something above, I think all use cases can be handled either via an except signature declaration or via try-except-finally in the body of the callback function. Since I'd also argue that the current behaviour is most likely broken if users don't do anything special already, I'd still vote for doing the switch and letting users fix their (already buggy) code. One drawback: currently, we can issue a warning when exceptions cannot be propagated, which allows users to take action and fix their code more easily. In the future, we would no longer be able to warn because Cython cannot know what functions are callbacks and which aren't. That would actually make it more difficult for users to adapt to the new behaviour. Stefan From matti.picus at gmail.com Sat Jan 7 12:25:33 2017 From: matti.picus at gmail.com (Matti Picus) Date: Sat, 7 Jan 2017 19:25:33 +0200 Subject: [Cython] trying to understand why PyString_GET_SIZE cannot be cimport-ed Message-ID: I am working on a branch of PyPy 2.7 to support Pandas (default PyPy is missing some CAPI support that enables the parts of cython used in Pandas). Pandas code has these lines (in lib.pyx) try: from cpython cimport PyString_GET_SIZE except ImportError: from cpython cimport PyUnicode_GET_SIZE as PyString_GET_SIZE For some reason, PyPy fails to cimport PyString_GET_SIZE, but successfully cimports PyUnicode_GET_SIZE. The substitution causes problems for PyPy, I could solve those in a different way, but I would like to understand what is going on. My cython Foo is improving but still too weak to understand why the cimport fails, could someone help me out with a hint? Matti From matti.picus at gmail.com Sun Jan 8 00:17:59 2017 From: matti.picus at gmail.com (Matti Picus) Date: Sun, 8 Jan 2017 07:17:59 +0200 Subject: [Cython] trying to understand why PyString_GET_SIZE cannot be cimport-ed In-Reply-To: References: Message-ID: <21c935f7-7483-3367-d6b5-8229524e2763@gmail.com> On 07/01/17 19:25, Matti Picus wrote: > I am working on a branch of PyPy 2.7 to support Pandas (default PyPy > is missing some CAPI support that enables the parts of cython used in > Pandas). > Pandas code has these lines (in lib.pyx) > > try: > from cpython cimport PyString_GET_SIZE > except ImportError: > from cpython cimport PyUnicode_GET_SIZE as PyString_GET_SIZE > > > For some reason, PyPy fails to cimport PyString_GET_SIZE, but > successfully cimports PyUnicode_GET_SIZE. > The substitution causes problems for PyPy, I could solve those in a > different way, but I would like to understand what is going on. > > My cython Foo is improving but still too weak to understand why the > cimport fails, could someone help me out with a hint? > > Matti Sorry for the noise, this would appear to be more appropriate for cython-users and also is just wrong, I will file a bug report with pandas. Matti From lists at onerussian.com Tue Jan 24 11:56:28 2017 From: lists at onerussian.com (Yaroslav Halchenko) Date: Tue, 24 Jan 2017 11:56:28 -0500 Subject: [Cython] verify_resolution_GH1533 Message-ID: <20170124165628.GA5583@onerussian.com> 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 From robertwb at gmail.com Tue Jan 24 19:53:52 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 24 Jan 2017 16:53:52 -0800 Subject: [Cython] verify_resolution_GH1533 In-Reply-To: <20170124165628.GA5583@onerussian.com> References: <20170124165628.GA5583@onerussian.com> Message-ID: Disabling only works on full test suites, e.g. you'd have to disable all of cpdef_enums. What kind of machine turns this into a long? On Tue, Jan 24, 2017 at 8:56 AM, Yaroslav Halchenko wrote: > 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 at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Tue Jan 24 20:01:52 2017 From: robertwb at gmail.com (Robert Bradshaw) Date: Tue, 24 Jan 2017 17:01:52 -0800 Subject: [Cython] verify_resolution_GH1533 In-Reply-To: References: <20170124165628.GA5583@onerussian.com> Message-ID: 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. On Tue, Jan 24, 2017 at 4:53 PM, Robert Bradshaw wrote: > Disabling only works on full test suites, e.g. you'd have to disable all > of cpdef_enums. > > What kind of machine turns this into a long? > > On Tue, Jan 24, 2017 at 8:56 AM, Yaroslav Halchenko > wrote: > >> 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 at python.org >> https://mail.python.org/mailman/listinfo/cython-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Wed Jan 25 08:47:22 2017 From: lists at onerussian.com (Yaroslav Halchenko) Date: Wed, 25 Jan 2017 08:47:22 -0500 Subject: [Cython] verify_resolution_GH1533 In-Reply-To: References: <20170124165628.GA5583@onerussian.com> Message-ID: <20170125134722.GB5583@onerussian.com> 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