Re: Missing Python.h

Re: Segfault with 0.14.1 but not 0.13

On Fri, Mar 4, 2011 at 11:52 AM, Keith Goodman <kwgoodman <at> gmail.com> wrote:
> On Fri, Mar 4, 2011 at 10:37 AM, Robert Bradshaw
> <robertwb <at> math.washington.edu> wrote:
>> On Fri, Mar 4, 2011 at 9:10 AM, Keith Goodman <kwgoodman <at> gmail.com> wrote:
>>>
>>> Not knowing what to do, I upgraded to cython 0.14.1 with the hope that
>>> the problem would go away. Now I'm having problems on my computer. The
>>> package compiles fine but the binary segfaults. Same thing happens
>>> with cython grabbed from github an hour ago.
>>>
>>> I'm sure I'm not providing useful info, but I'm lost and don't know
>>> where to start.
>>
>> What would help is if you can whittle down your module to a minimal
>> example that segfaults and then send us the code.
>
> I use a dictionary where the key is a tuple of things like numpy array
> data type and number of dimensions and the values are cython
> functions. Well, I defined the dictionary in the pyx file before I
> defined the functions. Works in cython 0.13 but not cython 0.14.1+. Or
> at least changing the order makes things run in cython 0.14.1+.
>
> Thanks for the suggestion to use some common sense. It worked!

Glad you got it working, but we shouldn't be segfaulting... at the
very lease we should be raising an error that the name is not (yet)
defined (just as one would in Python). This has to do with the changes
that made

if condition():
    def foo(x):
        pass
else:
    ...

possible.

> BTW, is there a better and/or faster way to do function selection than
> with a dictionary?

Not for complicated keys. If you're condition is an enum or something,
you can do cascaded if statements which get translated into a C case
statement.

- Robert

Re: Missing Python.h

On Fri, Mar 4, 2011 at 12:00 PM, Hector <hector1618 <at> gmail.com> wrote:
>
>
> On Wed, Jan 19, 2011 at 10:01 AM, Robert Bradshaw
> <robertwb <at> math.washington.edu> wrote:
>>
>> On Tue, Jan 18, 2011 at 7:44 PM, Hector troy <hector1618 <at> gmail.com> wrote:
>> > Hello everyone,
>> > I am a newbie to Cython and tried to run first program with Cython. It
>> > converted .pyx file into .c file but when I tried to run .c file with
>> > gcc it
>> > gave me following error.
>> >
>> > $hector <at> hector:~/Desktop/Programs/Cython$ time gcc test1.c
>> > test1.c:4: fatal error: Python.h: No such file or directory
>> > compilation terminated.
>> >
>> > I tried to update Python2.6-dev but its already in the newest form.
>> > Any help regarding the same will be very helpful.
>>
>> For someone just getting started, I would suggest using distuitls via
>> a setup.py file or using pyximport. There are a slew of options that
>> you need to pass gcc, many of which depend on your platform and/or how
>> Python was compiled.
>>
>> - Robert
>
> Hi Robert,
> I tried and made setup.py files and can run my code with it. It is nice but
> kind of irritating to write setup.py files for everything.

Once you have one, you can copy it from there. In fact if you use
http://wiki.cython.org/enhancements/distutils_preprocessing then you
can almost have a single setup.py for all your projects. Pyximport is
supposed to make this easier, and is great when it works, but hard to
debug when it doesn't.

> And I can't look time improvement with all imports.

I'm not following you here.

> Can you please give me some hint or reference where to start looking for
> missing Python.h or for starting with gcc?

If you run the setup.py file, it prints out the various gcc commands
it uses with all the gory flags. You can then use those directly if
you think that's easier. Note, however, that the exact flags and paths
to use vary from system to system.

- Robert

errors with numpy 1.5.1

Hello --

I recently upgraded from python 2.6 -> 2.7, cython 0.13 -> 14.1, and
numpy 1.4.1 -> 1.5.1.  Unfortunately, one of my cython modules no
longer works.

I tracked my bug and used the web to see that there is already a
ticket for exact same bug with the new buffer interface in numpy
1.5.1.

http://trac.cython.org/cython_trac/ticket/630

This is precisely the bug I am observing.

Let me know if there is an easy patch, or if a release is planned that
addresses this in the near future.

Best regards,
Matthew

Re: Segfault with 0.14.1 but not 0.13

Robert Bradshaw, 04.03.2011 21:05:
> at the very lease we should be raising an error that the name is not (yet)
> defined (just as one would in Python).

It's worth noting that Vitja is working on this already, so it may make it 
into 0.15.

>> BTW, is there a better and/or faster way to do function selection than
>> with a dictionary?
>
> Not for complicated keys. If you're condition is an enum or something,
> you can do cascaded if statements which get translated into a C case
> statement.

I've been stumbling over this use case several times already. It would be 
cool if Cython could optimise at least a couple of common cases where a 
constant dict with string or int keys is created inside of the very 
function that does the dispatch. It's a somewhat common idiom in Python but 
translates to very inefficient C code. If we could determine that the dict 
is only used for that, and then unpack it into a cascade of if statements, 
that would speed things up a lot, likely even for small sets of key strings.

There are several drawbacks, though. For one, this case isn't easy to find. 
And then, Python semantics dictate that the dict is evaluated before 
evaluating the lookup, i.e. all target values must be put into temps, etc. 
Also, we wouldn't be able to optimise global dicts used for dispatching, 
which I expect to be a common use case as well. So it's not easy and it 
won't apply to all code that uses the idiom...

Stefan

C++ nested class name cannot be accessed

According to the documentation
(http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html#nested-class-declarations),
Cyhon support wrapped c++ declaration (and the idea of native c++
support is really cool). But I found that the inner class name can be
accessed only if the outer class is defined  with template.

Here is an example:

a.h
------
template<typename T>
class A
{
public:
    class B
    {};
};

class C
{
public:
    class B
    {};
};

test.pyx
---------
cdef extern from "a.h":
    cdef cppclass A[T]:
        cppclass B:
            pass

    cdef cppclass C:
        cpplcass B:
            pass

def main():
    cdef A[int].B a_b  # ok
    cdef C.B c_b        # error: 'C' is not a cimported module

I thought the way of accessing the name of nested class was using '.'
compared to c++'s '::', and the 'C.B' above was interpreted as getting
attribute of a module.
Or am I doing something wrong here?

Re: C++ nested class name cannot be accessed

On Sat, Mar 5, 2011 at 12:41 AM, Wei Wu <canri62 <at> gmail.com> wrote:
> According to the documentation
> (http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html#nested-class-declarations),
> Cyhon support wrapped c++ declaration (and the idea of native c++
> support is really cool). But I found that the inner class name can be
> accessed only if the outer class is defined  with template.
>
> Here is an example:
>
> a.h
> ------
> template<typename T>
> class A
> {
> public:
>    class B
>    {};
> };
>
> class C
> {
> public:
>    class B
>    {};
> };
>
>
> test.pyx
> ---------
> cdef extern from "a.h":
>    cdef cppclass A[T]:
>        cppclass B:
>            pass
>
>    cdef cppclass C:
>        cpplcass B:
>            pass
>
>
> def main():
>    cdef A[int].B a_b  # ok
>    cdef C.B c_b        # error: 'C' is not a cimported module
>
>
>
> I thought the way of accessing the name of nested class was using '.'
> compared to c++'s '::', and the 'C.B' above was interpreted as getting
> attribute of a module.
> Or am I doing something wrong here?

Looks like a bug (or not implemented feature) in C++ support.
http://trac.cython.org/cython_trac/ticket/659

- Robert

Re: STL map

On Thu, Mar 3, 2011 at 8:00 PM, Kunal Puri <kunal.r.puri <at> gmail.com> wrote:
> hi,
>     I have a question pertaining to STL containers in Cython:
> I have a class defined in C++ which I wrap to cython using the "cdef extern
> from " statement.
>
> cdef extern from "some_header.h":
>     cdef cppclass MyClass
>         MyClass()
>         int ....
>
> Now I want to define a map with value, a pointer to this class: This map is
> an instance of a class I declare with Cython
> from libcpp.map cimport map
> cdef class Class()
>     cdef map[int, MyClass*] my_map
>
>
> what I get upon a compilation is:
> cdef class Class:
>     cdef map[ int, MyClass* ] *my_map
>                               ^
> ------------------------------------------------------------
> /home/kunalp/work/nnps/nnps_cpp.pxd:40:31: Expected an identifier or literal
> ,
> is this possible using Cython? I'm using version 0.14

No, this is not supported as the STL map won't handle the ref counting
correctly. You'll need to make a map[int, PyObject*] and then
cast/uncast and manually make sure the refcounts are sufficient.

- Robert

Re: building 64bit cython extensions on windows7 with mingw

Den 03.03.2011 17:46, skrev Yoav Goldberg:
> Hello,
> I am not a windows user.
> And I am having some trouble building my cython extension for a 64bit
> windows7 machine (this may well be a python / mingw question).
>
> It starts with many warning which I did not have on linux, and then
> complains about " skipping incompatible c:\Python27\libs/libpython27.a
> when searching for -lpython27" and hell brakes loose.
>
> Any idea how to make this work?

Short answer: Don't.

There are issues with the mingw runtime conflicting with the MSVC 
runtime on Windows 64. That is the reason the import libraries are omitted.

Use the free C/C++ platform compiler from Microsoft. Specifically, use 
Windows 7 SDK for .NET 3.5, not later versions! Later or earlier 
versions of the SDK will link with the wrong C runtime. (Feel free to 
complain the Redmond for creating C runtime DLL hell on Windows, they 
should be flogged.)

You do not need Visual Studio 2008 Express, as indicated in an earlier 
post to this list.

Make sure you have an environment variable DISTUTILS_USE_SDK defined and 
set to 1, so distutils will use the platform C/C++ compiler. Otherwise 
it will use the compiler shipped with Microsoft Visual C++.

If you need Fortran (e.g. for f2py or fwrap), Intel, Absoft and Portland 
have compilers compatible with Microsoft's C compiler and linker.

Regards,
Sturla

Re: building 64bit cython extensions on windows7 with mingw

Den 06.03.2011 04:35, skrev Sturla Molden:
>
> There are issues with the mingw runtime conflicting with the MSVC 
> runtime on Windows 64. That is the reason the import libraries are 
> omitted.
>

Also observe that while you can get 64-bit mingw builds from e.g. 
TDM-GCC, mingw-w64 is still in "beta" and there is no offcial 64-bit 
mingw release. Unless you need the compiler's source code, this is not a 
problem because Microsoft will give you a better C/C++ compiler for 
free. The C/C++ compiler in the Windows platform SDK is the same 
optimizing compiler shipped with Visual Studio professional and 
enterprise, not the crippled compiler shipped with Visual Studio standard.

Sturla