Kevin Thornton | 11 Feb 13:41 2016
Picon

[Cython] Cython 0.23.4 bug: C++ pairs with unsigned values inside other templates

Hi,

I've come across an odd bug while creating interfaces to existing C++ functions via Cython.

If a C++ pair is contained inside of another template type, the pair cannot contain unsigned integers unless a typedef is provided for unsigned.

Examples:

#This works:
cdef vector[pair[char,char]] doit():
    cdef vector[pair[char,char]] rv
    return rv

#This fails:
cdef vector[pair[unsigned,char]] doit2():
    cdef vector[pair[unsigned,char]] rv
    return rv

#But this works:
ctypedef unsigned uint
cdef vector[pair[uint,uint]] doit3():
    cdef vector[pair[uint,uint]] rv
    return rv

#This fails:
cdef void doit4( const vector[pair[unsigned,double]] & x):
    pass

--Kevin
<div><div dir="ltr">Hi,<div><br></div>
<div>I've come across an odd bug while creating interfaces to existing C++ functions via Cython.</div>
<div><br></div>
<div>If a C++ pair is contained inside of another template type, the pair cannot contain unsigned integers unless a typedef is provided for unsigned.</div>
<div><br></div>
<div>Examples:</div>
<div><br></div>
<div>
<div>#This works:</div>
<div>cdef vector[pair[char,char]] doit():</div>
<div>&nbsp; &nbsp; cdef vector[pair[char,char]] rv</div>
<div>&nbsp; &nbsp; return rv</div>
<div><br></div>
<div>#This fails:</div>
<div>cdef vector[pair[unsigned,char]] doit2():</div>
<div>&nbsp; &nbsp; cdef vector[pair[unsigned,char]] rv</div>
<div>&nbsp; &nbsp; return rv</div>
<div><br></div>
<div>#But this works:</div>
<div>ctypedef unsigned uint</div>
<div>cdef vector[pair[uint,uint]] doit3():</div>
<div>&nbsp; &nbsp; cdef vector[pair[uint,uint]] rv</div>
<div>&nbsp; &nbsp; return rv</div>
<div><br></div>
<div>#This fails:</div>
<div>cdef void doit4( const vector[pair[unsigned,double]] &amp; x):</div>
<div>&nbsp; &nbsp; pass</div>
</div>
<div><br></div>
<div>--Kevin</div>
</div></div>
Yury V. Zaytsev | 11 Feb 13:34 2016

[Cython] Compiler crash in AnalyseExpressionsTransform / overload resolution with templates

Hi,

I'm trying to improve the declarations in libcpp.string and cover them 
with unit tests. In this process, I've stumbled upon a compiler crash in 
overload resolution. A simple reproducer below; if the last line is 
uncommented, the code compiles just fine:

     cdef extern from *:
         cdef cppclass string_helper:
             cppclass iterator:
                 pass
             string_helper& insert(size_t, char*, size_t)
             iterator insert[input_iterator](iterator, input_iterator, input_iterator)

     def test_insert():
         cdef string_helper s
         cdef string_helper.iterator it
         s.insert[string_helper.iterator](it, it, it)
         s.insert(0, <char*>0, 0)

zaytsev <at> work:~/src/cython$ ./cython-git/cython.py --cplus crash.pyx

Error compiling Cython file:
------------------------------------------------------------
...

def test_insert():
     cdef string_helper s
     cdef string_helper.iterator it
     s.insert[string_helper.iterator](it, it, it)
     s.insert(0, <char*>0, 0)
            ^
------------------------------------------------------------

crash.pyx:13:12: Compiler crash in AnalyseExpressionsTransform

ModuleNode.body = StatListNode(crash.pyx:1:0)
StatListNode.stats[1] = DefNode(crash.pyx:9:0,
     modifiers = [...]/0,
     name = u'test_insert',
     py_wrapper_required = True,
     reqd_kw_flags_cname = '0',
     used = True)
File 'Nodes.py', line 430, in analyse_expressions: 
StatListNode(crash.pyx:10:4)
File 'Nodes.py', line 4755, in analyse_expressions: 
ExprStatNode(crash.pyx:13:12)
File 'ExprNodes.py', line 519, in analyse_expressions: 
SimpleCallNode(crash.pyx:13:12,
     analysed = True,
     use_managed_ref = True)
File 'ExprNodes.py', line 4938, in analyse_types: 
SimpleCallNode(crash.pyx:13:12,
     analysed = True,
     use_managed_ref = True)
File 'ExprNodes.py', line 4992, in analyse_c_function_call: 
SimpleCallNode(crash.pyx:13:12,
     analysed = True,
     use_managed_ref = True)

Compiler crash traceback from this point on:
   File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/ExprNodes.py", line 4992, in analyse_c_function_call
     entry = PyrexTypes.best_match(args, alternatives, self.pos, env)
   File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/PyrexTypes.py", line 4133, in best_match
     [pattern.type.deduce_template_params(actual) for (pattern, actual) in zip(func_type.args, arg_types)],
   File "/home/zaytsev/src/cython/cython-git/Cython/Compiler/PyrexTypes.py", line 3594, in deduce_template_params
     elif self.empty_declaration_code() == actual.template_type.empty_declaration_code():
AttributeError: 'CIntType' object has no attribute 'template_type'

--

-- 
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev | 10 Feb 11:42 2016

[Cython] Bug: compilation failure with "Template parameter not a type" for pointer & reference types

Hi,

I came across the following bug, while trying to implement iterator 
versions of std::string members, for which a simple reproducer is below.

If the return type of a function is a normal type, then everything is 
fine, but if it's a pointer or reference type, then Cython refuses to 
compile it.

Could something please be done about that? Many thanks!

Error compiling Cython file:
------------------------------------------------------------
...
cdef extern from * nogil:
     cdef cppclass test:
         void assign[input_iterator](input_iterator, input_iterator)
         char assign[input_iterator](input_iterator, input_iterator)
         char* assign[input_iterator](input_iterator, input_iterator)
         char& assign[input_iterator](input_iterator, input_iterator)
                                   ^
------------------------------------------------------------

notatype.pyx:6:35: Template parameter not a type

--

-- 
Sincerely yours,
Yury V. Zaytsev
Yury V. Zaytsev | 9 Feb 22:14 2016

[Cython] iterators / libcpp container definitions cleanup, any clues?

Hi,

I've been looking into libcpp container definitions and found that they
are kind of messy, in particular, iterators are defined as nested
classes for every container.

This leads to code duplication, and for certain containers some
overloaded methods seem to be missing or conversely declared, but not
provided.

I was trying to have a stab at cleaning this up and offering patches,
but I'm confused as to how to proceed.

At first, I thought that I could turn concepts into a hierarchy of
inherited classes in `iterator.pxd` like _ForwardIterator ->
_BidirectionalIterator -> _RandomAccessIterator and inherit container
iterators from those classes.

It seems that this is a bad idea for several reasons:

1) Apparently, there are some problems with inheritance, overload
resolution and type deduction, e.g. such that Cython deduces
`_RandomAccessIterator` as a result type for a + operation instead of
`vector[int].iterator` (which inherits from _RandomAccessIterator).

2) Cython thinks these are real classes and uses them in explicit
template arguments in generated C++ code.

The combination of (1) and (2) causes a lot of fail.

The only other possibility that crossed my mind so far was to use the
old "include" for code reuse and create files like
_RandomAccessIterator.pxi, _RandomAccessIteratorConst.pxi, etc. and
include their contents in the container definitions.

Sounds terrible, and I guess this wouldn't get merged, even if I get
that to work. Now, are there better approaches that I've overlooked?

--

-- 
Sincerely yours,
Yury V. Zaytsev

Raniere Silva | 8 Feb 15:09 2016
Picon

[Cython] Google Summer of Code 2016, GSoC2016

Hi all,

Since Cython is a NumFOCUS affiliated project
and NumFOCUS will apply to be a mentoring organization on GSoC
I want to know (1) if Cython is planning to apply this year
and (2) if want to apply under NumFOCUS umbrella.

Cython is welcome and encouraged to apply as separate mentoring
organizations directly with Google. We're happy to help you fill out your
application and improve your ideas pages, as well as link your page to help
students find you. We may also be able to be a reference for you.
It is totally fine if you want to use the NumFOCUS umbrella org
as a backup plan in case you don't get selected and we do!

Cheers,
Raniere
Hi all,

Since Cython is a NumFOCUS affiliated project
and NumFOCUS will apply to be a mentoring organization on GSoC
I want to know (1) if Cython is planning to apply this year
and (2) if want to apply under NumFOCUS umbrella.

Cython is welcome and encouraged to apply as separate mentoring
organizations directly with Google. We're happy to help you fill out your
application and improve your ideas pages, as well as link your page to help
students find you. We may also be able to be a reference for you.
It is totally fine if you want to use the NumFOCUS umbrella org
as a backup plan in case you don't get selected and we do!

Cheers,
Raniere
Nils Werner | 5 Feb 21:43 2016
Picon
Gravatar

[Cython] import-free setuptools integration

I have implemented some very simple setuptools integration that circumvents
the requirement to `import cython` in `setup.py` entirely, doing away with the
century-old problem of having to importing requirements during installation:


This implementation is inspired by CFFI's setuptools integration:

They do not require you to `import cffi` but simply define an additional keyword
argument `cffi_modules` for `setup()`. This additional keyword argument _does not
raise errors when cffi is not installed yet_ but can be used once cffi is there
(as defined in `setup_requires`). Later setuptools will call cffi and have it do
whatever it wants with the contents of the argument.

Cython can do the exact same. Below you have the usual `setup.py`, with the
chicken and egg `import` problem and a few `Extensions` that need to be `cythonize`d:

    import setuptools
    from Cython.Build import cythonize  # this will fail if cython is not present prior to running `pip install this`
    from setuptools.extension import Extension

    extensions = [
        Extension("fib", ["fib.pyx"]),
        Extension("fib2", ["fib2.pyx"]),
    ]

    setuptools.setup(
        name='example',
        version="1.0.0",
        packages=setuptools.find_packages(),
        setup_requires=['cython'],
        install_requires=['cython'],
        ext_modules=cythonize(extensions),
    )

With the changes I am proposing the usual

    ext_modules=cythonize(extensions),

can be replaced with

    cython_modules=extensions,

removing the need for `from Cython.Build import cythonize` and solving the import problem:

    import setuptools
    from setuptools.extension import Extension

    extensions = [
        Extension("fib", ["fib.pyx"]),
        Extension("fib2", ["fib2.pyx"]),
    ]

    setuptools.setup(
        name='example',
        version="1.0.0",
        setup_requires=['cython'],  # we must later require a Cython version that has this kind of integration
        install_requires=['cython'],
        cython_modules=extensions,
    )

This allows a nicer automated installation of tools that depend on cython and
also allows end users to keep their `setup.py` cleaner and leaner.

Additionally, I have also extended `cythonize()` a bit and thus allow for definitions like:

    import setuptools
    from setuptools.extension import Extension

    extensions = [
        Extension("fib", ["fib.c"]),
        Extension("fib2", ["fib2.c"]),
    ]

    setuptools.setup(
        name='example',
        version="1.0.0",
        extras_require={'cython': ['cython']},
        ext_modules=extensions,
        cython_modules=extensions,
    )

This will automatically compile pyx->c if cython is installed and a re-compilation is
needed. Otherwise it will merely compile c->so.

This allows devs to ship the generated C-code (as you suggest per your docs) but
takes the heuristic to find out whether to compile pyx->C->so or only C->so
completely out of `setup.py` and under control of cython.

The change is written to be backwards compatible:

 - Using `cython_modules` is entirely optional and not using it is sideeffect-free
 - Having `cythonize()` internally automatically compile *.pyx files when *.c files
   are provided is disabled by default and must be enabled using the `replace_extension`
   keyword argument (`cython_modules` enables that option).
<div><div dir="ltr">
<div>I have implemented some very simple setuptools integration that circumvents</div>
<div>the requirement to `import cython` in `setup.py` entirely, doing away with the</div>
<div>century-old problem of having to importing requirements during installation:</div>
<div><br></div>
<div>&lt;<a href="https://github.com/cython/cython/pull/477" target="_blank">https://github.com/cython/cython/pull/477</a>&gt;</div>
<div><br></div>
<div>This implementation is inspired by CFFI's setuptools integration:</div>
<div>&lt;<a href="https://cffi.readthedocs.org/en/latest/cdef.html#distutils-setuptools" target="_blank">https://cffi.readthedocs.org/en/latest/cdef.html#distutils-setuptools</a>&gt;.</div>
<div><br></div>
<div>They do not require you to `import cffi` but simply define an additional keyword</div>
<div>argument `cffi_modules` for `setup()`. This additional keyword argument _does not</div>
<div>raise errors when cffi is not installed yet_ but can be used once cffi is there</div>
<div>(as defined in `setup_requires`). Later setuptools will call cffi and have it do</div>
<div>whatever it wants with the contents of the argument.</div>
<div><br></div>
<div>Cython can do the exact same. Below you have the usual `setup.py`, with the</div>
<div>chicken and egg `import` problem and a few `Extensions` that need to be `cythonize`d:</div>
<div><br></div>
<div>&nbsp; &nbsp; import setuptools</div>
<div>&nbsp; &nbsp; from Cython.Build import cythonize &nbsp;# this will fail if cython is not present prior to running `pip install this`</div>
<div>&nbsp; &nbsp; from setuptools.extension import Extension</div>
<div><br></div>
<div>&nbsp; &nbsp; extensions = [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib", ["fib.pyx"]),</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib2", ["fib2.pyx"]),</div>
<div>&nbsp; &nbsp; ]</div>
<div><br></div>
<div>&nbsp; &nbsp; setuptools.setup(</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; name='example',</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; version="1.0.0",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; packages=setuptools.find_packages(),</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; setup_requires=['cython'],</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; install_requires=['cython'],</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; ext_modules=cythonize(extensions),</div>
<div>&nbsp; &nbsp; )</div>
<div><br></div>
<div>With the changes I am proposing the usual</div>
<div><br></div>
<div>&nbsp; &nbsp; ext_modules=cythonize(extensions),</div>
<div><br></div>
<div>can be replaced with</div>
<div><br></div>
<div>&nbsp; &nbsp; cython_modules=extensions,</div>
<div><br></div>
<div>removing the need for `from Cython.Build import cythonize` and solving the import problem:</div>
<div><br></div>
<div>&nbsp; &nbsp; import setuptools</div>
<div>&nbsp; &nbsp; from setuptools.extension import Extension</div>
<div><br></div>
<div>&nbsp; &nbsp; extensions = [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib", ["fib.pyx"]),</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib2", ["fib2.pyx"]),</div>
<div>&nbsp; &nbsp; ]</div>
<div><br></div>
<div>&nbsp; &nbsp; setuptools.setup(</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; name='example',</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; version="1.0.0",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; setup_requires=['cython'], &nbsp;# we must later require a Cython version that has this kind of integration</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; install_requires=['cython'],</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; cython_modules=extensions,</div>
<div>&nbsp; &nbsp; )</div>
<div><br></div>
<div>This allows a nicer automated installation of tools that depend on cython and</div>
<div>also allows end users to keep their `setup.py` cleaner and leaner.</div>
<div><br></div>
<div>Additionally, I have also extended `cythonize()` a bit and thus allow for definitions like:</div>
<div><br></div>
<div>&nbsp; &nbsp; import setuptools</div>
<div>&nbsp; &nbsp; from setuptools.extension import Extension</div>
<div><br></div>
<div>&nbsp; &nbsp; extensions = [</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib", ["fib.c"]),</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; Extension("fib2", ["fib2.c"]),</div>
<div>&nbsp; &nbsp; ]</div>
<div><br></div>
<div>&nbsp; &nbsp; setuptools.setup(</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; name='example',</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; version="1.0.0",</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; extras_require={'cython': ['cython']},</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; ext_modules=extensions,</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; cython_modules=extensions,</div>
<div>&nbsp; &nbsp; )</div>
<div><br></div>
<div>This will automatically compile pyx-&gt;c if cython is installed and a re-compilation is</div>
<div>needed. Otherwise it will merely compile c-&gt;so.</div>
<div><br></div>
<div>This allows devs to ship the generated C-code (as you suggest per your docs) but</div>
<div>takes the heuristic to find out whether to compile pyx-&gt;C-&gt;so or only C-&gt;so</div>
<div>completely out of `setup.py` and under control of cython.</div>
<div><br></div>
<div>The change is written to be backwards compatible:</div>
<div><br></div>
<div>&nbsp;- Using `cython_modules` is entirely optional and not using it is sideeffect-free</div>
<div>&nbsp;- Having `cythonize()` internally automatically compile *.pyx files when *.c files</div>
<div>&nbsp; &nbsp;are provided is disabled by default and must be enabled using the `replace_extension`</div>
<div>&nbsp; &nbsp;keyword argument (`cython_modules` enables that option).</div>
</div></div>
Neal Becker | 4 Feb 13:04 2016
Picon

[Cython] Cython-0.23.4 build failing on gcc6 for upcoming fedora 24

Anyone able to shed any light on this?   Here are the logs:

https://kojipkgs.fedoraproject.org//work/tasks/4202/12804202/build.log

Marvin Ritter | 1 Feb 23:56 2016
Picon

[Cython] Bug: Typed Memoryview and unicode string typ

Hi,

First off all thanks to all of you for this awesome tool, it is working great and I love it :)
Also the idea looks cool, I haven't been able to use typed memories views as they seem broken for my setup:

Cython 0.23.4
Python 3.4 (and 3.5)
Compiler directive: c_string_type=unicode (which should be the same as str in Python 3.x)

Steps:
cdef int* ptr = <int*>malloc(sizeof(int) * 10)
memView = <int[:n]>ptr 

Result:
Compiles, but will raise a TypeError('expected bytes, str found') at runtime

I attached a minimal example.
Note that if you change the c_string_type to 'bytes' it will work fine.

Best
Marvin
Attachment (cython-string_type.zip): application/zip, 1945 bytes
<div><div dir="ltr">
<span>Hi,</span><div><br></div>
<div>First off all thanks to all of you for this awesome tool, it is working great and I love it :)</div>
<div>Also the idea looks cool, I haven't been able to use typed memories views as they seem broken for my setup:<br>
</div>
<div><br></div>
<div>Cython 0.23.4</div>
<div>Python 3.4 (and 3.5)</div>
<div>Compiler directive: c_string_type=unicode (which should be the same as str in Python 3.x)</div>
<div><br></div>
<div>Steps:</div>
<div>cdef int* ptr = &lt;int*&gt;malloc(sizeof(int) * 10)</div>
<div>memView = &lt;int[:n]&gt;ptr&nbsp;<br>
</div>
<div><br></div>
<div>Result:</div>
<div>Compiles, but will raise a TypeError('expected bytes, str found') at runtime</div>
<div><br></div>
<div>I attached a minimal example.</div>
<div>Note that if you change the c_string_type to 'bytes' it will work fine.</div>
<div><br></div>
<div>Best</div>
<div>Marvin</div>
</div></div>
Marvin Ritter | 2 Feb 00:22 2016
Picon

[Cython] NumPy C API Status?

Hi,

I have to use the NumPy C API for my current project and it seems that Cython 0.23.4 it only shipping definitions for on all version of the API. But I need some of the newer methods.

What are your plans on updating? Is there anything that prevents you?
And if not, how complicated is it? Could a novice like me do it?

Thanks
Marvin
<div><div dir="ltr">Hi,<div><br></div>
<div>I have to use the NumPy C API for my current project and it seems that Cython 0.23.4 it only shipping definitions for on all version of the API. But I need some of the newer methods.</div>
<div><br></div>
<div>What are your plans on updating? Is there anything that prevents you?</div>
<div>And if not, how complicated is it? Could a novice like me do it?</div>
<div><br></div>
<div>Thanks</div>
<div>Marvin</div>
</div></div>
Kevin Thornton | 2 Feb 02:03 2016
Picon

[Cython] C++ structs, namespace, and auto-conversion of struct to dict

Hi,

I recently ran into an issue where I found that Cython will not generate code to auto-convert structs do dicts if the struct is declared in a C++ namespace.


While there are obvious workarounds, none of them are ideal.

Is there a road map for addressing this issue?  If not, what would it take to do so, and where in the code should one start looking?

Thanks, 

Kevin


<div><div dir="ltr">Hi,<div><br></div>
<div>I recently ran into an issue where I found that Cython will not generate code to auto-convert structs do dicts if the struct is declared in a C++ namespace.</div>
<div><br></div>
<div>The issue has also been discussed here:&nbsp;<a href="http://stackoverflow.com/questions/29603562/auto-conversion-of-structs-to-dicts-in-cython">http://stackoverflow.com/questions/29603562/auto-conversion-of-structs-to-dicts-in-cython</a>
</div>
<div><br></div>
<div>While there are obvious workarounds, none of them are ideal.</div>
<div><br></div>
<div>Is there a road map for addressing this issue?&nbsp; If not, what would it take to do so, and where in the code should one start looking?</div>
<div><br></div>
<div>Thanks,&nbsp;</div>
<div><br></div>
<div>Kevin<br><div><br></div>
<div><br></div>
</div>
</div></div>
Elizabeth Fischer | 29 Jan 20:02 2016

[Cython] Cython 0.23.4: Crash with Template Stuff

Cython is crashing on me when I compile.  See below.

-- Elizabeth

cython --version

Cython version 0.23.4


Error compiling Cython file:
------------------------------------------------------------
...
#        cdef int flags

def test_double_blitz(a):
cdef vector[int] v
cdef cblitz.Array[double,1] a_b
a_b = cibmisc.np_to_blitz[double,1](a, b'var', [-1])
                         ^
------------------------------------------------------------

/Users/rpfische/git/ibmisc/pylib/ibmisc.pyx:38:26: Compiler crash in AnalyseExpressionsTransform

ModuleNode.body = StatListNode(ibmisc.pyx:1:0)
StatListNode.stats[3] = StatListNode(ibmisc.pyx:35:0)
StatListNode.stats[0] = DefNode(ibmisc.pyx:35:0,
    modifiers = [...]/0,
    name = 'test_double_blitz',
    num_required_args = 1,
    py_wrapper_required = True,
    reqd_kw_flags_cname = '0',
    used = True)
File 'Nodes.py', line 430, in analyse_expressions: StatListNode(ibmisc.pyx:36:1)
File 'Nodes.py', line 4775, in analyse_expressions: SingleAssignmentNode(ibmisc.pyx:38:36)
File 'Nodes.py', line 4887, in analyse_types: SingleAssignmentNode(ibmisc.pyx:38:36)
File 'ExprNodes.py', line 4640, in analyse_types: SimpleCallNode(ibmisc.pyx:38:36,
    analysed = True,
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 3109, in analyse_types: IndexNode(ibmisc.pyx:38:26,
    is_called = 1,
    is_subscript = True,
    result_is_used = True,
    use_managed_ref = True)
File 'ExprNodes.py', line 3419, in analyse_base_and_index_types: IndexNode(ibmisc.pyx:38:26,
    is_called = 1,
    is_subscript = True,
    result_is_used = True,
    use_managed_ref = True)

Compiler crash traceback from this point on:
  File "/Users/rpfische/macports/mpgompi-4.9.3/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Compiler/ExprNodes.py", line 3419, in analyse_base_and_index_types
    elif len(base_type.templates) != len(self.type_indices):
TypeError: object of type 'NoneType' has no len()
make[2]: *** [pylib/ibmisc.cpp] Error 1
make[2]: *** Deleting file `pylib/ibmisc.cpp'
make[1]: *** [pylib/CMakeFiles/ibmisc_so.dir/all] Error 2
make: *** [all] Error 2

<div><div dir="ltr">Cython is crashing on me when I compile.&nbsp; See below.<div><br></div>
<div>-- Elizabeth<br><div><br></div>
<div>

<p class="">cython --version</p>
<p class="">Cython version 0.23.4</p>
</div>
<div><br></div>
<div>
<div>Error compiling Cython file:</div>
<div>------------------------------------------------------------</div>
<div>...</div>
<div># &nbsp; &nbsp; &nbsp; &nbsp;cdef int flags</div>
<div><br></div>
<div>def test_double_blitz(a):</div>
<div>
<span class="">	</span>cdef vector[int] v</div>
<div>
<span class="">	</span>cdef cblitz.Array[double,1] a_b</div>
<div>
<span class="">	</span>a_b = cibmisc.np_to_blitz[double,1](a, b'var', [-1])</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;^</div>
<div>------------------------------------------------------------</div>
<div><br></div>
<div>/Users/rpfische/git/ibmisc/pylib/ibmisc.pyx:38:26: Compiler crash in AnalyseExpressionsTransform</div>
<div><br></div>
<div>ModuleNode.body = StatListNode(ibmisc.pyx:1:0)</div>
<div>StatListNode.stats[3] = StatListNode(ibmisc.pyx:35:0)</div>
<div>StatListNode.stats[0] = DefNode(ibmisc.pyx:35:0,</div>
<div>&nbsp; &nbsp; modifiers = [...]/0,</div>
<div>&nbsp; &nbsp; name = 'test_double_blitz',</div>
<div>&nbsp; &nbsp; num_required_args = 1,</div>
<div>&nbsp; &nbsp; py_wrapper_required = True,</div>
<div>&nbsp; &nbsp; reqd_kw_flags_cname = '0',</div>
<div>&nbsp; &nbsp; used = True)</div>
<div>File 'Nodes.py', line 430, in analyse_expressions: StatListNode(ibmisc.pyx:36:1)</div>
<div>File 'Nodes.py', line 4775, in analyse_expressions: SingleAssignmentNode(ibmisc.pyx:38:36)</div>
<div>File 'Nodes.py', line 4887, in analyse_types: SingleAssignmentNode(ibmisc.pyx:38:36)</div>
<div>File 'ExprNodes.py', line 4640, in analyse_types: SimpleCallNode(ibmisc.pyx:38:36,</div>
<div>&nbsp; &nbsp; analysed = True,</div>
<div>&nbsp; &nbsp; result_is_used = True,</div>
<div>&nbsp; &nbsp; use_managed_ref = True)</div>
<div>File 'ExprNodes.py', line 3109, in analyse_types: IndexNode(ibmisc.pyx:38:26,</div>
<div>&nbsp; &nbsp; is_called = 1,</div>
<div>&nbsp; &nbsp; is_subscript = True,</div>
<div>&nbsp; &nbsp; result_is_used = True,</div>
<div>&nbsp; &nbsp; use_managed_ref = True)</div>
<div>File 'ExprNodes.py', line 3419, in analyse_base_and_index_types: IndexNode(ibmisc.pyx:38:26,</div>
<div>&nbsp; &nbsp; is_called = 1,</div>
<div>&nbsp; &nbsp; is_subscript = True,</div>
<div>&nbsp; &nbsp; result_is_used = True,</div>
<div>&nbsp; &nbsp; use_managed_ref = True)</div>
<div><br></div>
<div>Compiler crash traceback from this point on:</div>
<div>&nbsp; File "/Users/rpfische/macports/mpgompi-4.9.3/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/Cython/Compiler/ExprNodes.py", line 3419, in analyse_base_and_index_types</div>
<div>&nbsp; &nbsp; elif len(base_type.templates) != len(self.type_indices):</div>
<div>TypeError: object of type 'NoneType' has no len()</div>
<div>make[2]: *** [pylib/ibmisc.cpp] Error 1</div>
<div>make[2]: *** Deleting file `pylib/ibmisc.cpp'</div>
<div>make[1]: *** [pylib/CMakeFiles/ibmisc_so.dir/all] Error 2</div>
<div>make: *** [all] Error 2</div>
</div>
<div><br></div>
</div>
</div></div>

Gmane