Jeroen Demeyer | 19 Oct 21:08 2014
Picon

Re: Repeating cdef declarations in derived classes

On 2014-10-18 16:31, Stefan Behnel wrote:
>> Is there even a difference between
>>
>> cdef class Derived(Base):
>>      cdef int foo()
>>      cdef int bar()
>>
>> and
>>
>> cdef class Derived(Base):
>>      cdef int bar()
>
> Yes. It's as in Python. If you redefine a method in a derived class, it
> gets overwritten.
My original question was not so clear, I meant for .pxd declarations.
Does it make a difference there?

--

-- 

--- 
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.

jelle feringa | 19 Oct 11:40 2014
Picon

loading a .pyc file from a cython extesion fails

I'm working on having my module distributed through conda and ran into the following:

fcl.fcl is the cython .so extension
fcl.collision_data is a .py python module

>>> from fcl import fcl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "fcl/fcl.pyx", line 9, in init fcl.fcl (fcl/fcl.cpp:15449)
ImportError: No module named collision_data

[ deletes the collisiont_data.pyc ]

>>> from fcl import fcl

[ all is peachy ]


its likely that the .pyc file was compiled in another directory then the directory where the file currently resides.

it would be cool for a cython module to disregard the .pyc if directory where its corresponding .py file is another one than the .pyc file.
not sure if the .pyc file stores a path to the referenced .py file though...

Best,

-jelle




--

---
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.
Robert Bradshaw | 18 Oct 18:29 2014
Picon

Re: Repeating cdef declarations in derived classes

On Sat, Oct 18, 2014 at 7:31 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
Jeroen Demeyer schrieb am 17.10.2014 um 12:10:
> Suppose I have
>
> cdef class Base:
>     cdef int foo()
>
> If I now create a derived class, should the "cdef int foo()" be repeated?

No.

> Is there even a difference between
>
> cdef class Derived(Base):
>     cdef int foo()
>     cdef int bar()
>
> and
>
> cdef class Derived(Base):
>     cdef int bar()

Yes. It's as in Python. If you redefine a method in a derived class, it
gets overwritten.

(If that's currently not the case in a Cython .pxd file, it's a bug.)

Note that if it is re-declared, they should agree. I've been fixing these in Sage: https://github.com/robertwb/sage/commit/8a45bd072afac01a63a12d38cc77f2f86055c9e6 

I might lean towards simply disallowing unnecessary re-declarations like this, but unfortunately it's been this way for a while: https://github.com/cython/cython/commit/a686fdc49d4813cfccd637697e6155b3e262bf6e (which happens to be the first modification ever). Then maybe we could finally get rid of https://github.com/cython/cython/commit/a48ee51299894459ef2d1f3e46698326a25093ed

- Robert

--

---
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.
Jeroen Demeyer | 17 Oct 15:52 2014
Picon

Optimal return type just for exception propagation

Hello,

I often find myself in the situation where I have a cdef function which 
shouldn't return anything (so "cdef void foo():" would be logical), 
however I do want to propagate exceptions.

What is the recommended return type then (assuming there is a 
recommendation)?

I guess a simple "cdef foo():" with a Python return value of Py_None in 
the non-exception case isn't optimal in terms of efficiency. Should I 
use "cdef int foo() except -1:" and rely on the fact that no return 
value means "return 0"?

I sometimes think we should have a special type "bvoid" or something, 
similar to "bint", which is a C int which is 0 if there was no exception 
and -1 on exception.

--

-- 

--- 
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.

Jeroen Demeyer | 17 Oct 12:10 2014
Picon

Repeating cdef declarations in derived classes

Suppose I have

cdef class Base:
     cdef int foo()

If I now create a derived class, should the "cdef int foo()" be 
repeated? Is there even a difference between

cdef class Derived(Base):
     cdef int foo()
     cdef int bar()

and

cdef class Derived(Base):
     cdef int bar()

--

-- 

--- 
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.

george.trojan | 15 Oct 21:08 2014
Picon

fortran elemental functions

I a writing a Python module to access fortran library that has elemental functions. I came up with the following code (an example):

The library function is fthe(t, p)

I created a fortran wrapper:

! calculate equivalent potential temperature given temperature and
! pressure
subroutine c_fthe(t, nt, p, np, the, nthe) bind(c)
    integer(c_int), intent(in):: nt, np, nthe
    real(c_float), intent(in):: t(nt), p(np)
    real(c_float), intent(out):: the(nthe)
    real(krealfp):: pk(np)
    pk = fpkap(p)  ! another elemental function, not relevant to the discussion
    if (nt.eq.np) then
        the = fthe(t, pk)
    else if (nt.eq.1) then
        the = fthe(t(1), pk)
    else if (np.eq.1) then
        the = fthe(t, pk(1))
    end if
end subroutine

In *.pyx file I have

cdef extern void c_fthe(float *t, int *nt, float *pk, int *npk, float *the, int *nthe)

def pt2the(object p, object t):
    '''Compute equivalent potential temperature at the LCL
    from pressure and temperature.
   Temperature range is 183.16 to 303.16 Kelvin, pressure
    4000 to 110000 Pa.
    Input argument list:
        t:      LCL temperature in Kelvin
        p:      LCL pressure
    Returns equivalent potential temperature in Kelvin.
    Output values outside valid range are masked.
    '''
    t = np.clip(t, 183.16, 303.16)
    p = np.clip(p, 4.0e3, 1.1e5)
    return generic2arg(t, p, &c_fthe)

and the following monstrosity (generic3arg is much worse):

cdef generic2arg(object o1, object o2, f3arg f):
    cdef np.ndarray[np.float32_t, ndim=1, mode='c'] o1c, o2c, oc
    cdef int n1, n2, n
    n1 = o1.size
    n2 = o2.size
    mask1 = o1.mask if hasattr(o1, 'mask') else None
    mask2 = o2.mask if hasattr(o2, 'mask') else None
    mask = None
    if o1.shape == o2.shape:
        n = n1
        shape = o1.shape
        if mask1 is not None and mask2 is not None:
            # if objects are arrays, both must be masked or not masked
            mask = mask1 | mask2
    elif n1 == 1:
        n = n2
        shape = o2.shape
        mask = mask2
    elif n2 == 1:
        n = n1
        shape = o1.shape
        mask = mask1
    else:
        raise ValueError('Invalid dimensions: %d, %d' % (n1, n2))
    if shape == (0,):
        return np.array([], dtype=o1.dtype)
    o1c = np.ascontiguousarray(o1.ravel(), dtype=np.float32)
    o2c = np.ascontiguousarray(o2.ravel(), dtype=np.float32)
    oc = np.ascontiguousarray(np.zeros((n,)), dtype=np.float32)
    f(&o1c[0], &n1, &o2c[0], &n2, &oc[0], &n)
    if mask is not None:
        return np.ma.array(oc.reshape(shape), mask=mask)
    else:
        return oc.reshape(shape)

Is there a better way of handling this? I know C does not know about elemental functions. Googling for "cython fortran elemental functions" produced no hits.

George

--

---
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.
yann che | 15 Oct 17:51 2014
Picon

C++ standard library

Hi everyone,

I'm new to Cython. I'm particularly interested in using C++ standard library, like the "map" data structure.
Strangely, cython calls gcc instead of g++..

Here is my setup.py:

///////////////////////////////////////
p, li { white-space: pre-wra

from distutils.core import setup

from Cython.Build import cythonize

import os

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

////////////////////////////////////////


but it didn't work, because cython does not recognise C++. He runs gcc instead.
To force the use of C++, I add this to my setup.py file:

os.environ["CC"] = "g++"


This is very ugly and generates lots of warning. Is there a proper way to handle this ?



By the way, I'm on Mac 10.9, using Anaconda python distribution

Regards,
yann

--

---
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.
Attachment (main.pyx): application/octet-stream, 135 bytes
Alexander Ebersp├Ącher | 15 Oct 21:19 2014
Picon

Debugging workflow: cygdb, debugging symbols and system Python

Dear list,

I would like to ask for advice on a sensible debugging work-flow - on a system
with a few "boundary conditions" in place.

First of all, I use a Xubuntu 14.04 machine. Here, Python 2.7 is system
default, I also develop against that version. python-dbg is installed. As it
turns out, Ubuntu's gdb is linked against Python 3 (for unknown reasons), so I
decided to install a local gdb that is configured with --with-python2.

In that state, "gdb python-dbg" brings up gdb that happily uses Python 2.7
debug information. However, as it turns out, as soon as my scientific Python
software stack is imported in a script I'd like to debug, I get an error:

ImportError: /usr/local/lib/python2.7/dist-packages/scipy/special/_ufuncs.so: undefined symbol: Py_InitModule4_64

This is apparently due to my packages not being compiled with debugging symbols
[1]. If I was using system default versions here, I'd happily go with the *-dbg
packages from the repositories, however, all of scientific Python is built by
myself.

Actually, all I want is to use cygdb in principle as my project is
Python/Cython/Fortran. However, I can't get cygdb to start with a Python that
has debugging symbols:

    Python was not compiled with debug symbols (or it was stripped). Some functionality may not work (properly).

Even if I could, I'd still probably run into the problem I described above. My own
package is compiled with Cython's --gdb options as well as with -g for all gcc/gfortran.

This is where I appreciated your input. How do you handle Cython debugging?
Does cygdb do the job for you? If so, how? How do you deal with a software
stack that doesn't have debugging symbols at hand?

Thanks for your help with this somewhat tangled problem somewhere in-between
what's possible, what's needed and what's easiest.

Regards

Alex Eberspächer


[1] http://hustoknow.blogspot.de/2013/06/why-your-python-program-cant-start-when.html



--

---
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 | 15 Oct 07:58 2014
Picon

Release candidate for Cython 0.21.1

Hi everyone,

I uploaded a candidate for a 0.21.1 bug fix release.

http://cython.org/release/Cython-0.21.1pre.tar.gz

It adds a few minor new features and some bug fixes and corrections. Please
give it a quick try, especially if you reported problems that this release
should fix. I had to manually select changes from the master branch, so I
hope I didn't forget anything.

Stefan

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

* New ``cythonize`` option ``-a`` to generate the annotated HTML source
  view.

* Missing C-API declarations in ``cpython.unicode`` were added.

* Passing ``language='c++'`` into cythonize() globally enables C++ mode for
  all modules that were not passed as Extension objects (i.e. only source
  files and file patterns).

* ``Py_hash_t`` is a known type (used in CPython for hash values).

* ``PySlice_*()`` C-API functions are available from the ``cpython.slice``
  module.

* Allow arrays of C++ classes.

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

* Reference leak for non-simple Python expressions in boolean and/or
  expressions.

* To fix a name collision and to reflect availability on host platforms,
  standard C declarations [ clock(), time(), struct tm and tm* functions ]
  were moved from posix/time.pxd to a new libc/time.pxd.  Patch by Charles
  Blake.

* Rerunning unmodified modules in IPython's cython support failed.
  Patch by Matthias Bussonier.

* Casting C++ ``std::string`` to Python byte strings failed when
  auto-decoding was enabled.

* Fatal exceptions in global module init code could lead to crashes
  if the already created module was used later on (e.g. through a
  stale reference in sys.modules or elsewhere).

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

* Compilation no longer fails hard when unknown compilation options are
  passed.  Instead, it raises a warning and ignores them (as it did
  silently before 0.21).  This will be changed back to an error in a
  future release.

--

-- 

--- 
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.

Catherine Moroney | 14 Oct 23:17 2014
Picon
Picon

accessing C

Hello,

I'm using Cython to wrap a third-party library (HDF and HDF-EOS for 
those in the satellite data business) and I want to call the HDF error 
reporting function.  

The syntax for the error function is "HEprint(FILE *, 0)" and i'm stuck 
on how I construct and pass a regular C file pointer (which could be stdout) 
into the function within my Cython code.  

If anybody can post some sample code that writes a text string to 
either a C FILE * or stdout within Cython, I would love to see how you do this.

Thanks for any help,

Catherine

--

-- 

--- 
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.

Gregorio Bastardo | 13 Oct 10:38 2014
Picon

Re: debugging external c code

The missing piece of puzzle was the "-s" linker option that is added
by default and removed the debug symbols. After manually linking the
code w/o this option the debugging works fine with gdb.

Now I'd like create a release and a debug version of the same
extension module. Can anyone show a good practice for it (e.g. in
setup.py)? How can I skip the "-s" option in the debug version?

Thanks,
Gregorio

--

-- 

--- 
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