5 Feb 22:57
[Cython] OpenCL support
Hey, I created a CEP for opencl support: http://wiki.cython.org/enhancements/opencl What do you think? Mark
2 Feb 13:19
[Cython] memoryview slices can't be None?
I just realized that cdef int[:] a = None raises an exception; even though I'd argue that 'a' is of the "reference" kind of type where Cython usually allow None (i.e., "cdef MyClass b = None" is allowed even if type(None) is NoneType). Is this a bug or not, and is it possible to do something about it? Dag Sverre
2 Feb 09:21
[Cython] Cython's view on a common benchmark suite (was: Re: [Speed] Buildbot Status)
Brett Cannon, 01.02.2012 18:25: > to prevent this from either ending up in a dead-end because of this, we > need to first decide where the canonical set of Python VM benchmarks are > going to live. I say hg.python.org/benchmarks for two reasons. One is that > Antoine has already done work there to port some of the benchmarks so there > is at least some there that are ready to be run under Python 3 (and the > tooling is in place to create separate Python 2 and Python 3 benchmark > suites). Two, this can be a test of having the various VM contributors work > out of hg.python.org if we are ever going to break the stdlib out for > shared development. At worst we can simply take the changes made at > pypy/benchmarks that apply to just the unladen benchmarks that exists, and > at best merge the two sets (manually) into one benchmark suite so PyPy > doesn't lose anything for Python 2 measurements that they have written and > CPython doesn't lose any of its Python 3 benchmarks that it has created. > > How does that sound? +1 FWIW, Cython currently uses both benchmark suites, that of PyPy (in Py2.7) and that of hg.python.org (in Py2.7 and 3.3), but without codespeed integration and also without a dedicated server for benchmark runs. So the results are unfortunately not accurate enough to spot minor changes even over time. https://sage.math.washington.edu:8091/hudson/view/bench/ We would like to join in on speed.python.org, once it's clear how the benchmarks will be run and how the data uploads work and all that. It already proved a bit tricky to get Cython integrated with the benchmark(Continue reading)
2 Feb 01:53
[Cython] distutils extension pxd problem
Hey everyone,
I bumped into an issue where my .pyx file doesn't see its matching
.pxd file. Here's a build test to show the problem If I change my
target package from `b.a` to just `a`, it works as expected. Running
`cython src/a.pyx` works as expected as well, but not the Extension.
----
PYTHON setup.py build_ext --inplace
PYTHON -c "from b import a"
######## setup.py ########
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
ext_modules = [
Extension("b.a", ["src/a.pyx"])
]
setup(
cmdclass = {'build_ext': build_ext},
ext_modules = ext_modules
)
######## b/__init__.py ########
######## src/a.pxd ########
(Continue reading)
30 Jan 22:03
[Cython] Upcoming issues with NumPy deprecated APIs and Cython's sizeof checks
I'm testing my code with numpy-dev. They are trying to discourage use of deprecated APIs, this includes direct access to the ndarray struct. In order to update your code, you have to pass -DNPY_NO_DEPRECATED_API to the C compiler (or #define it before including NumPy headers). However, they have implemented this feature by exposing the ndarray type with just the Python object header: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/ndarraytypes.h#L695 Obviously, this interact bad with Cython's sizeof check, I'm getting this runtime warning: build/lib.linux-x86_64-2.7/petsc4py/lib/__init__.py:64: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility I think there is nothing Cython can do about this (other than special-casing NumPy to disable this VERY useful warning). I've tried the patch below with success, but I'm not convinced... Does any of you have a suggestion for NumPy folks about how to improve this? diff --git a/numpy/core/include/numpy/ndarraytypes.h b/numpy/core/include/numpy/ndarraytypes.h index 0288272..1fcbf52 100644 --- a/numpy/core/include/numpy/ndarraytypes.h +++ b/numpy/core/include/numpy/ndarraytypes.h @@ -695,6 +695,7 @@ typedef struct tagPyArrayObject_fields { #ifdef NPY_NO_DEPRECATED_API(Continue reading)
29 Jan 15:10
[Cython] Bug in multiplied tuple optimization
Investigating sage-tests segfaults I found that this code causes sigsegv:
def foo():
return (0,) * len('abc')
foo()
--
--
vitja.
26 Jan 18:56
[Cython] Slow traceback reconstruction in IPython between 0.15.1 and master
Just wanted to bring this issue to your guys' attention in case you knew what was responsible for this: https://github.com/ipython/ipython/issues/1317#issuecomment-3652550 I traced down the problem (with git bisect) to a seemingly innocuous commit referenced in that GitHub thread. The issue seemed to only present itself in IPython, so likely there was some problem with inspecting the Cython frames for giving context around the full traceback. best, Wes
24 Jan 21:58
[Cython] inline defnode calls
I just noticed the inline defnode call code. When I try to compile
with 'cython -Xoptimize.inline_defnode_calls=True test.pyx' with the
following code:
def foo(x): print foo
foo(10)
I get
Error compiling Cython file:
------------------------------------------------------------
...
def foo(x):
print x
foo(10)
^
------------------------------------------------------------
test.pyx:4:3: Compiler crash in InlineDefNodeCalls
ModuleNode.body = StatListNode(test.pyx:1:0)
StatListNode.stats[2] = ExprStatNode(test.pyx:4:3)
ExprStatNode.expr = SimpleCallNode(test.pyx:4:3,
result_is_used = True,
use_managed_ref = True)
Compiler crash traceback from this point on:
File "/Users/mark/cy/Cython/Compiler/Visitor.py", line 176, in _visitchild
result = handler_method(child)
(Continue reading)
24 Jan 20:18
Re: [Cython] Bug in Cython producing incorrect C code
On 01/24/2012 08:05 PM, Vitja Makarov wrote: > 2012/1/24 mark florisson<markflorisson88@...>: >> On 24 January 2012 18:30, Vitja Makarov<vitja.makarov@...> wrote: >>> 2012/1/24 Robert Bradshaw<robertwb@...>: >>>> On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov<vitja.makarov@...> wrote: >>>>> 2012/1/24 mark florisson<markflorisson88@...>: >>>>>> On 24 January 2012 11:37, Konrad Hinsen<konrad.hinsen@...> wrote: >>>>>>> Compiling the attached Cython file produced the attached C file which >>>>>>> has errors in lines 532-534: >>>>>>> >>>>>>> __pyx_v_self->xx = None; >>>>>>> __pyx_v_self->yy = None; >>>>>>> __pyx_v_self->zz = None; >>>>>>> >>>>>>> There is no C symbol "None", so this doesn't compile. >>>>>>> >>>>>>> I first noticed the bug in Cython 0.15, but it's still in the latest >>>>>>> revision from Github. >>>>>>> >>>>>>> Konrad. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cython-devel mailing list >>>>>>> cython-devel@... >>>>>>> http://mail.python.org/mailman/listinfo/cython-devel >>>>>>> >>>>>> >>>>>> Hm, it seems the problem is that the call to the builtin float results(Continue reading)
24 Jan 12:37
[Cython] Bug in Cython producing incorrect C code
Compiling the attached Cython file produced the attached C file which has errors in lines 532-534: __pyx_v_self->xx = None; __pyx_v_self->yy = None; __pyx_v_self->zz = None; There is no C symbol "None", so this doesn't compile. I first noticed the bug in Cython 0.15, but it's still in the latest revision from Github. Konrad.
RSS Feed