houbaastef . | 31 Jul 00:06 2015
Picon

wrapping around const unsigned char *

Hello,

i'm fairly new to cython, please excuse me if questions look mundane.

I have to write a cython wrapper around a C++ library.

The typical C++ class uses constructor with const char* arguments. Eg:

cdef extern from "bla/ip.h" namespace "blabla":
cdef cppclass cppIP "blabla::IP":
cppIP()
cppIP(const uint8_t *buf, uint32_t total_sz) except +ValueError
I'd like to expose this class to Python space. The user is likely to use different buffer types, for example bytes, bytearray, (normal python) memoryviews. He could also use directly char* buf and size from cython space. Or (cython) typed memoryviews.

I'm looking an efficient way to make the wrapping cython class.

So far here is what i got :

from cython.view cimport memoryview as cy_memoryview

cdef class
IP(object):
def __cinit__(self, buf=None):
if buf is None:
self.ptr = new cppIP()
else:
if isinstance(buf, bytes):
self.ptr = new cppIP(<uint8_t*> buf, <uint32_t> len(buf))
elif isinstance(buf, bytearray):
self.ptr = new cppIP(<uint8_t*> buf, <uint32_t> len(buf))
elif isinstance(buf, memoryview):
# todo: check that buf has the right shape, etc. find pointer to memoryview data.
print("python memoryview")
elif isinstance(buf, cy_memoryview):
# todo: check that buf has the right shape, etc
self.ptr = new cppIP(<uint8_t*> (<cy_memoryview>buf).get_item_pointer([]), <uint32_t> len(buf))

def __dealloc__(self):
if self.ptr != NULL:
del self.ptr

# some "static" helpers

cdef make_IP_from_const_uchar_buf(const uint8_t* buf, int size):
if size == 0:
raise ValueError("size can't be zero")
if buf == NULL:
raise ValueError("buf can't be a NULL pointer")
return IP(buf=make_mview_from_const_uchar_buf(buf, size))

cpdef make_IP_from_typed_memoryview(unsigned char[:] data):
if data is None:
raise ValueError("data can't be None")
return IP(buf=<cy_memoryview> data)
The 'make_mview_from_const_uchar_buf' is a simple wrapper around Python C-API, to build a memoryview from a pointer and size.

# needed cause cython doesn't allow to make read-only typed memoryviews
cdef
object make_mview_from_const_uchar_buf(const unsigned char* buf, int size):
cdef Py_buffer* viewinfo = <Py_buffer*> PyMem_Malloc(sizeof(Py_buffer))
cdef int res
if viewinfo != NULL:
res = PyBuffer_FillInfo(viewinfo, NULL, <void*> buf, size, 1, PyBUF_FULL_RO)
if res == 0:
return PyMemoryView_FromBuffer(viewinfo)
else:
PyMem_Free(viewinfo)
raise RuntimeError("PyBuffer_FillInfo failed with -1")
else:
raise MemoryError
This looks quite cumbersome and verbose and makes me wonder if I tackle the problem in the right way. Any ideas for a more elegant solution ?

Kind regards,
Stephane







--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lee Zamparo | 30 Jul 20:34 2015
Picon

cython does not find appropriate overloaded constructor

I'm trying to compile and run tests of cyrand using cython, but am running into a bizarre compile error when testing overloaded constructors. See this gist for the complete definitions of the files in question.  I'm using python: 2.7.10 (Anaconda 2.0.1) with cython: 0.22.1.


From the gist, I can compile and run example.pyx just fine, which uses the default constructor:

import numpy as np cimport numpy as np cimport cython include "random.pyx" <at> cython.boundscheck(False) def example(n): cdef int N = n cdef rng r cdef rng_sampler[double] * rng_p = new rng_sampler[double](r) cdef rng_sampler[double] rng = deref(rng_p) cdef np.ndarray[np.double_t, ndim=1] result = np.empty(N, dtype=np.double) for i in range(N): result[i] = rng.normal(0.0, 2.0) print result return result


^ this works and runs fine. An example run produces the following output:

$ python test_example.py [ 0.47237842 3.153744849 3.6854932057 ]


Yet when I try to compile and run the test which used a constructor that takes an unsigned long as argument:

import numpy as np cimport numpy as np cimport cython include "random.pyx" <at> cython.boundscheck(False) def example_seed(n, seed): cdef int N = n cdef unsigned long Seed = seed cdef rng r cdef rng_sampler[double] * rng_p = new rng_sampler[double](Seed) cdef rng_sampler[double] rng = deref(rng_p) cdef np.ndarray[np.double_t, ndim=1] result = np.empty(N, dtype=np.double) for i in range(N): result[i] = rng.normal(0.0, 2.0) print result return result

I get the following cython compiler error:

Error compiling Cython file: ----------------------------------------------------------- ... cdef int N = n cdef unsigned long Seed = seed cdef rng_sampler[double] * rng_p = new rng_sampler[double](Seed) ---------------------------------------------------------- example/example_seed.pyx:15:67 Cannot assign type 'unsigned long' to 'mt19937'


I interpret this message, along with the fact that example.pyx compiles and produces a working example.so file, that cython cannot find (or manage) the rng_sampler constructor that takes an unsigned long as input.  Below is the definition of the rng_sampler cppclass: 


import numpy as np cimport numpy as np cimport cython from cython.operator cimport dereference as deref from libcpp cimport bool cdef extern from "boost/random/mersenne_twister.hpp" namespace "boost::random" nogil: # random number generator cdef cppclass mt19937: #init mt19937() nogil #attributes #methods seed(unsigned long) cdef extern from "rng_wrapper.hpp" nogil: # wrapper to distributions ... cdef cppclass rng_sampler[result_type]: #init rng_sampler(mt19937) nogil // <- this constructor works fine in the example.pyx test rng_sampler(unsigned long) nogil // <- this constructor is not found in the example_seed.pyx test rng_sampler() nogil // <- who knows about this one.
# methods (gamma and exp are using rate param) result_type normal(result_type, result_type) nogil result_type gamma(result_type, result_type) nogil result_type uniform(result_type, result_type) nogil result_type exp(result_type) nogil result_type chisq(result_type) nogil ctypedef mt19937 rng



I've not used cython before, and my cpp is middling at best. Can anyone shed light on how to fix this simple problem?


Thanks,


Lee.

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lee Zamparo | 30 Jul 19:02 2015
Picon

cython fails to recognize overloaded constructor

Hi everyone,

I'm new to cython, and was trying to compile a wrapper around a boost-based random number generator (see here).  My full problem description complete with gist is cross-posted to stackoverflow, so I'll only summarize it here:
  1. I'm using python 2.7.10 (Anaconda 2.0.1) and cython 0.22.1.  
  2. random.pyx exposes an interface defined in rng_wrapper.hpp
  3. A test in example.pyx file compiles and runs fine
  4. A very similar test in example_seed.pyx does not compile 
The error reported has to do with an overloaded constructor:  

Error compiling Cython file: ----------------------------------------------------------- ... cdef int N = n cdef unsigned long Seed = seed cdef rng_sampler[double] * rng_p = new rng_sampler[double](Seed) ---------------------------------------------------------- example/example_seed.pyx:15:67 Cannot assign type 'unsigned long' to 'mt19937'

Here is an abridged definition of the rng_sampler class (see the gist for the rest):

#include <ctime>
#include "boost/random/mersenne_twister.hpp"
#include "boost/random/normal_distribution.hpp"
#include "boost/random/gamma_distribution.hpp"
#include "boost/random/exponential_distribution.hpp"
#include "boost/random/uniform_real_distribution.hpp"
#include "boost/random/chi_squared_distribution.hpp"

using namespace boost::random;template<typename float_t=double>
class rng_sampler {

public:
 
typedef float_t result_type;
 
  rng_sampler
(mt19937 &in_R) : R(in_R) {} // <- the copy constructor

  rng_sampler
() {  // <- the default constructor
    R
= mt19937();
    R
.seed(std::clock());
 
}
  rng_sampler
(unsigned long seed) { // <- the constructor which takes an unsigned long
    R
= mt19937();
    R
.seed(seed);
 
}

 
// sampling methods here

private:
  mt19937 R
;

};


And here's the random.pyx file which defines the cppclass:

import numpy as np
cimport numpy
as np
cimport cython

from cython.operator cimport dereference as deref

from libcpp cimport bool

cdef
extern from "boost/random/mersenne_twister.hpp" namespace "boost::random" nogil:
   
# random number generator
    cdef cppclass mt19937
:
       
#init
        mt19937
() nogil
       
#attributes

       
#methods
        seed
(unsigned long)


cdef
extern from "rng_wrapper.hpp" nogil:
   
# wrapper to distributions ...
    cdef cppclass rng_sampler
[result_type]:
       
#init
        rng_sampler
(mt19937) nogil
        rng_sampler
(unsigned long) nogil
        rng_sampler
()  nogil
       
# methods (gamma and exp are using rate param)
        result_type normal
(result_type, result_type) nogil
        result_type gamma
(result_type, result_type) nogil
        result_type uniform
(result_type, result_type) nogil
        result_type exp
(result_type) nogil
        result_type chisq
(result_type) nogil

ctypedef mt19937 rng

As I read it, the code tries to call the overloaded constructor using an unsigned long:

rng_sampler(unsigned long seed) {
    R
= mt19937();
    R
.seed(seed);
 
}

Yet the compiler does not recognize this, and instead fails to call the copy constructor:

rng_sampler(mt19937 &in_R) : R(in_R) {}

Can anyone help me understand why this is the case?  And better yet how to properly declare the unsigned long constructor so that cython recognizes it?

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
slonik | 30 Jul 16:40 2015
Picon

Cython generates incorrect C++ code (does not compile)

Hi All,

I ran into a problem when cython generates incorrect c++ code (--cplus option) which does not compile under clang (MacOSX Mavericks). I think it should not compile under any other C++ compiler, for it seems to generate semantically incorrect C++.

Below I included a minimal test case that triggers the problem. The problem is present in the latest git master (4d115ea66257...) as well as in 0.22.1

### foo.pyx
from libcpp.vector cimport vector
from cython.operator cimport dereference as deref, preincrement as incr

cdef vector[double]* mk_vtr(size_t N):
    return new vector[double](N)

cdef size_t N= 5
cdef double *p_dbl= &deref(mk_vtr(N))[0]

#cdef double[::1] mv1= <double[:N]> p_dbl  #OK
#cdef double[::1] mv2= <double[:N]> <double*> &deref(mk_vtr(N))[0] #OK

cdef double[::1] mv2= <double[:N]>  &deref(mk_vtr(N))[0] #ERROR while compiling c++ code

#foo.cc:13345:11: error: '__pyx_t_1' declared as a pointer to a reference of type 'double &'
#  double &*__pyx_t_1;
#          ^
#1 error generated.
####

Declaring a pointer to a reference does not seem like a good idea. In my Cython code I used '&' as an address operator rather than a reference declarator.

--Leo

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Christoph Groth | 30 Jul 14:56 2015
Picon

Relative cimports not working as expected

Dear all,

Cython 0.22 supports relative cimports.  That’s great, I’ve been looking
forward to this feature for a long time!

I tried to use this in our package “Kwant” [1].  In several pyx and pxd files I changed [2] lines like

  from kwant.graph.defs cimport gint

to

  from .defs cimport gint

The result can be built (with Cython 0.22) and works.

However, one motivation for having relative imports everywhere is to
avoid fixing the name of the package.  With relative imports it should
be possible to install several versions of the same package in Python’s sys.path and then import a
specific one, e.g.

  import kwant_old as kwant

To test whether this works, I made a symlink to the directory containing
our package, effectively renaming it.  The original “kwant” package
remains importable as well.

  ln -s /home/cwg/work/our/src/11/kwant/kwant kwant2

Now when I try to import it with the command

  python -c 'import kwant2'

this fails with the following traceback

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "kwant2/__init__.py", line 31, in <module>
      exec 'from . import {0}'.format(module)
    File "<string>", line 1, in <module>
    File "kwant2/system.py", line 53, in <module>
      _system.hamiltonian_submatrix, None, System)
  AttributeError: 'module' object has no attribute 'hamiltonian_submatrix'

To better see what is going on, I added [3] the following line to the
top-level __init__.py file of the package:

  print 1, __file__

When importing the renamed package through the symlink, I see the
following output

  1 kwant2/__init__.pyc
  1 /home/cwg/local/lib/python/kwant/__init__.pyc

Whereas when importing the package regularly, there is only one such
line.  This shows that somewhere our package is still trying to import
kwant under its usual name.  So let’s try to import “kwant2” but with an
empty PYTHONPATH, so that “kwant” is no longer importable.  This gives
the following traceback

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "kwant2/__init__.py", line 14, in <module>
      from . import _system
    File "kwant/graph/core.pxd", line 15, in init kwant._system (kwant/_system.c:22723)
  ImportError: No module named kwant.graph.core

Line 15 of kwant/_system.pyx [4] is

  from .graph.core cimport CGraph, gintArraySlice

Somehow, Cython must be baking-in the “kwant” name into the _system.so
module so that it wants to import “kwant.graph.core” even if the
relative cimport there is only from “.graph.core”.  Is this really the
way this is supposed to work?

I saw that there are several recent commits to Cython that touch
relative cimports so I tried current Cython from git (from yesterday).
But this even fails to build the package in the first place.  It fails
with many errors like

cythoning kwant/_system.pyx to kwant/_system.c

  Error compiling Cython file:
  ------------------------------------------------------------
  ...
  # http://kwant-project.org/license.  A list of Kwant authors can be found in
  # the AUTHORS file at the top-level directory of this distribution and at
  # http://kwant-project.org/authors.

  cimport numpy as np
  from .defs cimport gint
  ^
  ------------------------------------------------------------

  kwant/graph/core.pxd:10:0: 'kwant/defs.pxd' not found

If any Cython expert is willing to examine these problems directly with
our package, please do

  git clone http://git.kwant-project.org/kwant

to get the source and switch to the branch “cimport”.  Building “kwant”
is straightforward [5].

Any ideas?

Christoph

[1] http://git.kwant-project.org/kwant/?h=cimport
[2] http://git.kwant-project.org/kwant/commit/?h=cimport&id=3c408f5f7b1601055d2044e13aeb9690ff590cad
[3] http://git.kwant-project.org/kwant/commit/?h=cimport&id=76eeaeb9b4a0e1294d70a5d14fb706cbb947bd3c
[4] http://git.kwant-project.org/kwant/tree/kwant/_system.pyx?h=cimport&id=76eeaeb9b4a0e1294d70a5d14fb706cbb947bd3c
[5] http://kwant-project.org/doc/1.0/pre/install#building-and-installing-from-source

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Eric Reynolds | 30 Jul 09:52 2015
Picon

Cdef methods don't get bound to self

Hello, it's me again.

I apologise if this question has already been asked, I tried searching the docs, the UG and the internet for answers but didn't find anything.

Let's start with the code:

cdef class X:
def def_method(self):
print "Hello from a def method"

cpdef cpdef_method(self):
print "Hello from a cpdef method"

cdef cdef_method(self):
print "Hello from a cdef method"

cdef X x = X()

# def methods get bound to self like Python
f = x.def_method
f()

# cpdef methods get bound to self like Python
f = x.cpdef_method
f()

# cdef methods work differently
f = x.cdef_method
f(x)

# this fails
f()

So my question is, why this design choice, if it is indeed intentional? After all creating automatically creating a bound cdef method wrapper object wouldn't be too difficult I would have thought, and access the unbound function could still be available from the class object (i.e. X.cdef_method).

Thanks in advance for all your support, kind regards,

Eric.

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Stefan Behnel | 29 Jul 20:02 2015
Picon

[Cython] Cython 0.23 beta 2 released

Hi everyone,

I just uploaded a second beta for the upcoming Cython 0.23. Please give it
some more testing as there were substantial code changes since the first beta.

You can get the signed release from here:

http://cython.org/release/

http://cython.org/release/Cython-0.23b2.tar.gz

http://cython.org/release/Cython-0.23b2.zip

SHA1 sums:
1d12e335116ba3fcbe731d83ccc5ee5f0f6e5371  Cython-0.23b2.tar.gz
6f063e6b08b6dbecbadd44ed6c6150bc799fa230  Cython-0.23b2.zip

Changes since beta 1 (in addition to general bug fixes):

* The builtin ``type`` type is now declared as PyTypeObject in source,
  allowing for extern functions taking type parameters to have the correct
  C signatures.  Note that this might break code that uses ``type`` just
  for passing around Python types in typed variables.  Removing the type
  declaration provides a backwards compatible fix.

* Support operator bool() for C++ classes so they can be used in if
  statements.

* Installation under CPython 3.3+ no longer requires a pass of the
  2to3 tool.  This also makes it possible to run Cython in Python
  3.3+ from a source checkout without installing it first.
  Patch by Petr Viktorin.

* Coverage analysis and async/await were adapted to recent changes in
  coverage.py and CPython.

Complete changelog follows below.

Since we're in beta phase now, new features should not generally be added
for the release any more, but we can make exceptions for currently
existing pull requests if you can provide a good motivation. If you think
we forgot something, sending a timely reply to this email or reviving an
existing mailing list thread or pull request is a good idea.

Have fun,

Stefan

Features added
--------------

* PEP 492 (async/await) was implemented.
  See https://www.python.org/dev/peps/pep-0492/

* PEP 448 (Additional Unpacking Generalizations) was implemented.
  See https://www.python.org/dev/peps/pep-0448/

* Support for coverage.py 4.0+ can be enabled by adding the plugin
  "Cython.Coverage" to the ".coveragerc" config file.

* Annotated HTML source pages can integrate (XML) coverage reports.

* Tracing is supported in ``nogil`` functions/sections and module init
  code.

* When generators are used in a Cython module and the module imports the
  modules "inspect" and/or "asyncio", Cython enables interoperability by
  patching these modules during the import to recognise Cython's internal
  generator and coroutine types. This can be disabled by C compiling the
  module with "-D CYTHON_PATCH_ASYNCIO=0" or "-D CYTHON_PATCH_INSPECT=0"

* When generators or coroutines are used in a Cython module, their types
  are registered with the ``Generator`` and ``Coroutine`` ABCs in the
  ``collections`` or ``collections.abc`` stdlib module at import time to
  enable interoperability with code that needs to detect and process Python
  generators/coroutines.  These ABCs were added in CPython 3.5 and are
  available for older Python versions through the ``backports_abc`` module
  on PyPI.  See https://bugs.python.org/issue24018

* Adding/subtracting/dividing/modulus and equality comparisons with
  constant Python floats and small integers are faster.

* Binary and/or/xor/rshift operations with small constant Python integers
  are faster.

* When called on generator expressions, the builtins ``all()``, ``any()``,
  ``dict()``, ``list()``, ``set()``, ``sorted()`` and ``unicode.join()``
  avoid the generator iteration overhead by inlining a part of their
  functionality into the for-loop.

* Keyword argument dicts are no longer copied on function entry when they
  are not being used or only passed through to other function calls (e.g.
  in wrapper functions).

* The ``PyTypeObject`` declaration in ``cpython.object`` was extended.

* The builtin ``type`` type is now declared as PyTypeObject in source,
  allowing for extern functions taking type parameters to have the correct
  C signatures.  Note that this might break code that uses ``type`` just
  for passing around Python types in typed variables.  Removing the type
  declaration provides a backwards compatible fix.

* ``wraparound()`` and ``boundscheck()`` are available as no-ops in pure
  Python mode.

* Const iterators were added to the provided C++ STL declarations.

* ``NULL`` is allowed as default argument when embedding signatures.
  This fixes ticket 843.

* When compiling with ``--embed``, the internal module name is changed to
  ``__main__`` to allow arbitrary program names, including those that would
  be invalid for modules.  Note that this prevents reuse of the generated
  C code as an importable module.

* External C++ classes that overload the assignment operator can be used.
  Patch by Ian Henriksen.

* Support operator bool() for C++ classes so they can be used in if
  statements.

Bugs fixed
----------

* Calling "yield from" from Python on a Cython generator that returned a
  value triggered a crash in CPython.  This is now being worked around.
  See https://bugs.python.org/issue23996

* Language level 3 did not enable true division (a.k.a. float division)
  for integer operands.

* Functions with fused argument types that included a generic 'object'
  fallback could end up using that fallback also for other explicitly
  listed object types.

* Relative cimports could accidentally fall back to trying an absolute
  cimport on failure.

* The result of calling a C struct constructor no longer requires an
  intermediate assignment when coercing to a Python dict.

* C++ exception declarations with mapping functions could fail to compile
  when pre-declared in .pxd files.

* ``cpdef void`` methods are now permitted.

* ``abs(cint)`` could fail to compile in MSVC and used sub-optimal code
  in C++.  Patch by David Vierra, original patch by Michael Enßlin.

* Buffer index calculations using index variables with small C integer
  types could overflow for large buffer sizes.
  Original patch by David Vierra.

* C unions use a saner way to coerce from and to Python dicts.

* When compiling a module ``foo.pyx``, the directories in ``sys.path``
  are no longer searched when looking for ``foo.pxd``.
  Patch by Jeroen Demeyer.

* Memory leaks in the embedding main function were fixed.
  Original patch by Michael Enßlin.

* Some complex Python expressions could fail to compile inside of finally
  clauses.

Other changes
-------------

* Changed mangling scheme in header files generated by ``cdef api``
  declarations.

* Installation under CPython 3.3+ no longer requires a pass of the
  2to3 tool.  This also makes it possible to run Cython in Python
  3.3+ from a source checkout without installing it first.
  Patch by Petr Viktorin.

--

-- 

--- 
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sam Amini | 29 Jul 16:10 2015
Picon

error in installing cython

Dear,

I am trying to install cython on my home directory without root access.

The python version I have is Python-2.7.10. It's also installed locally.

Here is what I get from typing in: python setup.py install


Cython/Parser/Grammar: No such file or directory
Traceback (most recent call last):
 File "setup.py", line 288, in <module>
   compile_cython_modules(cython_profile, cython_compile_more, cython_with_refnanny)
 File "setup.py", line 134, in compile_cython_modules
   os.path.join(parser_dir, 'graminit.c'),
 File "/tools/python/Python-2.7.10/Lib/subprocess.py", line 540, in check_call
   raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/tools/python/Python-2.7.10/Include/../Parser/pgen',
'Cython/Parser/Grammar', 'Cython/Parser/graminit.h', 'Cython/Parser/graminit.c']' returned non-zero exit status 1


Could you please let me know what went wrong here?

Kinds regards,
Sam

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Damian Vuleta | 28 Jul 08:12 2015
Picon

Unable to Cythonise .pyx file

I apologise in advance if this is an old topic. I'm new to Cython and am probably overlooking something basic, but I haven't been able to find help elsewhere.

I have a short Python module I wish to Cythonise:

# Define Jumble
def Jumble(TestList[], SequenceX):
    TLen = len(TestList)
    J = 0
    for I in range(TLen):
        J = (J + int(SequenceX[I:I+6])) % TLen
        TestList[I], TestList[J] = TestList[J], TestList[I]
    return TestList

# Define De-Jumble
def DeJumble(TestList, SequenceX):
    TLen = len(TestList)
    J = 0
    for I in range(TLen):
        J = (J + int(SequenceX[I:I+6])) % TLen
    for I in reversed(range(TLen)):
        TestList[I], TestList[J] = TestList[J], TestList[I]
        J = (J - int(SequenceX[I:I+6])) % TLen
    return TestList

(TestList is a list of integers and SequenceX is a text string of numbers.)

I create a basic setup.py file:

from distutils.core import setup
from Cython.Build import cythonize

setup(
    ext_modules = cythonize("JumDe.pyx")
)

and run python3 setup.py build_ext --inplace from Terminal. It produces a .so file (albeit with a lot of warning messages) and I can successfully import it and use it in my main program, with a noticeable speed increase.

When I rename the module with a .pyx suffix, change the setup file and run it again, up comes this error message:

Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    ext_modules = cythonize("JumDe.pyx")
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Build/Dependencies.py", line 754, in cythonize
    aliases=aliases)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Build/Dependencies.py", line 649, in create_extension_list
    for file in nonempty(extended_iglob(filepattern), "'%s' doesn't match any files" % filepattern):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Build/Dependencies.py", line 103, in nonempty
    raise ValueError(error_msg)
ValueError: 'JumDe.pyx' doesn't match any files

This happens whether I put C type declarations in the module or not. So what am I overlooking?

Using Python 3.4.3, Cython 0.22.1, Mac OS X 10.10.4

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
slonik | 27 Jul 23:16 2015
Picon

Compiler crash in AnalyseExpressionsTransform

Hi All,
the following (arguably not very useful code snippet) causes cython to crash. Both git master (0987482...) and 0.22.x seem to be affected:

# foo.pyx
from libcpp.vector cimport vector

def foo(vector[int] iv):
    if  iv is None:
        pass

$ cython -o foo.cc --cplus -2 -f -v foo.pyx

Error compiling Cython file:
------------------------------------------------------------
...
# foo.pyx
from libcpp.vector cimport vector

def foo(vector[int] iv):
    if  iv is None:
          ^
------------------------------------------------------------

foo.pyx:5:11: Invalid types for 'is' (vector[int], Python object)

Error compiling Cython file:
------------------------------------------------------------
...
# foo.pyx
from libcpp.vector cimport vector

def foo(vector[int] iv):
    if  iv is None:
          ^
------------------------------------------------------------

foo.pyx:5:11: Compiler crash in AnalyseExpressionsTransform

ModuleNode.body = StatListNode(foo.pyx:2:0)
StatListNode.stats[0] = DefNode(foo.pyx:4:0,
......
.....[snip]...
.....
Compiler crash traceback from this point on:
  File "/Users/leor/dev/Python/Cython/cython/Cython/Compiler/ExprNodes.py", line 11365, in coerce_to_boolean
    if self.is_pycmp:
AttributeError: 'PrimaryCmpNode' object has no attribute 'is_pycmp'
make: *** [foo.cc] Error 1

--Leo


--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ian Henriksen | 27 Jul 22:28 2015
Picon

cdef-only global variables don't work as expected

Module-level variables declared using cdef are only
declared and used within the functions that use them.
This can be a problem when these variables are used
to store a global value needed in different functions.

For example:

# global_test.pyx
cdef int l = 1
def set_l(int val):
    l = val
def get_l():
    return l

#test.py
import global_test as g
g.set_l(2)
print g.get_l()

Running this test script, strangely enough, prints 1
since the local variable is declared and initialized to 1
inside each function where it is used, rather than being
stored as a module-level value. Even when the variable
is uninitialized, it is set by default to 0 and re-declared
within each function.

This same behavior is preserved, even when the global
variable is declared as extern.

Was this a deliberate design decision to make
Cython's scoping behave more like Python's, or is this
a bug? This strikes me as a case where practicality
beats purity, but I'd be happy to hear other
opinions.

Thanks!
-Ian Henriksen

--

---
You received this message because you are subscribed to the Google Groups "cython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane