gmane.comp.python.cython.devel

[Cython] new idea for typedef integrals

As posted some time ago, here you have some work (BTW, awaiting
review) http://trac.cython.org/cython_trac/ticket/333

But recently I was thinking on something... What about a parser
modification to accept code like the below one?:

cdef extern from *: # note the "?" annotation
    ctypedef singed MyIntType1?
    ctypedef singed MyIntType2? "something"

Perhaps the uses knows that some typedef ACTUALLY match the extern
one. And then, we should not second-guess the user.

Moreover, this is fully backwards... The new unknow-size handling code
will only be used if a typedef is explicitly marked as an unknow-size
type.

What do you think?

--

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

headers

Dag Sverre Seljebotn | 2 Jul 19:30

Re: [Cython] To raise or not to raise

I'm taking this to the list...

Kurt Smith wrote:
> Dag,
> 
> When an exception or an error needs to be generated, what are the
> guidelines?  It seems Errors.error() is normally called, although an
> exception isn't raised at this point, & compilation continues -- the
> errors are collected and reported at the end of everything then.  A
> few other times I see a 'raise CompileError' or 'raise InternalError'
> instead.  When should these be raised instead of just calling
> Errors.error()?  I seem to recall that InternalError is an error with
> the compiler itself, while CompileError is raised when there's
> something wrong with the source.

I wouldn't trust these rules to be followed everywhere, but:

In general, exceptions should not be raised, but compilation go on while 
"ignoring" what caused the error.

In e.g. declaration analysis, the right procedure is to call 
Errors.error and set "self.type" to PyrexTypes.error_type (or similar). 
Then code which need to use the type should check if it is error_type 
and if so, return early (i.e. "ignore" this part of the tree; 
compilation will be aborted later anyway).

Some places though an exception may still be the right thing -- if it is 
trapped further out in the node tree. I.e. to recover from an error in a 
subnode it might be proper to use exception to go back to a parent node, 
then that parent node is skipped and its sibling processed next.

(Continue reading)

headers

Chris Colbert | 2 Jul 01:10

[Cython] how to allow access to data in a C array?

I'm thinking this may be what the new array type is for, but i'm not sure.

say I have a C struct which I wrap as a class:

#mycfile.h
struct Foo
{
       int* data[32];
};

#my_dec_file.pxd
cdef exter from "mycfile.h":

     cdef struct Foo:
           int* data[32]

#my_cy_file.pxd
cimport my_dec_file

cdef class Foo:
       cdef my_dec_file.Foo* thisptr

#my_cy_file.pyx
cimport my_dec_file

cdef class Foo:
    property data:
    def _get_(self):
         return self.thisptr.data   <----i dont think this will work

(Continue reading)

headers

Lisandro Dalcin | 1 Jul 20:57

[Cython] Fwd: Search paths for definition files

---------- Forwarded message ----------
From: Lisandro Dalcin <dalcinl@...>
Date: Wed, Jul 1, 2009 at 3:56 PM
Subject: Re: [Cython] Search paths for definition files
To: Sebastien Binet <seb.binet@...>

On Wed, Jul 1, 2009 at 4:02 AM, Sebastien Binet<seb.binet@...> wrote:
>
>> Other way (not recommended, not portable for POSIX/Windows):
>> add a setup.cfg file alongside your setup.py file, and write inside it
>> (use ";" to separate on Windows):
>
> I am a bit surprised by this non-portable behaviour.
> is it a (stdlib) distutils overlook or a Cython.Distutils one ?
>

It is (stdlib) distutils behaviour, and Cython.Distutils just followed
the rules... Though I would not say that is an overlook, but a
feature...

>
> IIRC one can standardize on the POSIX syntax for path-separators and friends,
> and have the posixpath module do the conversion for us:
>
>>>> import posixpath
>>>> assert posixpath.pathsep == ':'
>>>> assert posixpath.sep == '/'
>
> so always using the POSIX syntax in xyz.cfg files would be portable.
>

(Continue reading)

headers

Chris Colbert | 1 Jul 19:50

[Cython] how would I wrap something like this in a .pxd file

In wrapping a C library, I come across many #define statements that I
need to use elsewhere. When they simply define a constant, I use an
anonymous enum and all is well.

But how would I wrap something like this that shown up in a header
file that i'm cdef extern'ing from:

#define CV_TREE_NODE_FIELDS(node_type)                               \

    int       flags;                \

    int       header_size;          \

    struct    node_type* h_prev;      \

    struct    node_type* h_next;     \

    struct    node_type* v_prev;       \

    struct    node_type* v_next ;

or something like this:

#define CV_IS_STORAGE(storage)  \

    ((storage) != NULL &&       \

    (((CvMemStorage*)(storage))->signature & CV_MAGIC_MASK) ==
CV_STORAGE_MAGIC_VAL)

(Continue reading)

headers

Ondrej Certik | 1 Jul 02:25

[Cython] accessing ctype array's b_ptr

Hi,

I need to access ctype array's b_ptr. The array is defined in
Python-2.6.2/Modules/_ctypes/ctypes.h  as:

struct tagCDataObject {
    PyObject_HEAD
    char *b_ptr;        /* pointer to memory block */
    int  b_needsfree;   /* need _we_ free the memory? */
    CDataObject *b_base;    /* pointer to base object or NULL */
    Py_ssize_t b_size;  /* size of memory block in bytes */
    Py_ssize_t b_length;    /* number of references we need */
    Py_ssize_t b_index; /* index of this object into base's
                   b_object list */
    PyObject *b_objects;    /* dictionary of references we need to
keep, or Py_None */
    union value b_value;
};

So I wrote this cython code:

cdef extern from "Python.h":
    ctypedef void PyTypeObject

cdef struct CDataObject:
    Py_ssize_t ob_refcnt
    PyTypeObject *ob_type
    char *b_ptr

and then I use it like this:

(Continue reading)

headers

Elliott Slaughter | 30 Jun 22:35

[Cython] Search paths for definition files

Hi,

The manual states that "the Cython compiler searches for a file called modulename.pxd along the search path for include files, as specified by -I command line options" [1].

I'm wondering if there is any way to get this behavior with distutils (i.e. from inside a setup.py script). The build_ext command doens't seem to support using the -I option in the same way that Cython does.

$ cython -Idir foo.pyx

$ python setup_foo.py build_ext -c mingw32 -i
running build_ext
error: file 'bar.pxd' does not exist

$ mv dir/bar.pxd .

$ python setup_foo.py build_ext -c mingw32 -i
running build_ext
building 'foo' extension
... compiles successfully ...

$ cat foo.pyx
cimport bar

$ cat bar.pxd

$ cat setup_foo.py
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext

setup(
cmdclass = {'build_ext': build_ext},
ext_modules = [Extension('foo', ['foo.pyx'])]
)

This is with Python 2.5.4, Cython 0.11.2, and MinGW from Cygwin on Windows.

Thanks.

[1] http://docs.cython.org/docs/sharing_declarations.html#search-paths-for-definition-files

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

<div><p>Hi,<br><br>The manual states that "the Cython
compiler searches for a file called modulename.pxd along the search path for include files, as specified by -I command line options" [1].<br><br>I'm wondering if there is any way to get this behavior with distutils (i.e. from inside a setup.py script). The build_ext command doens't seem to support using the -I option in the same way that Cython does.<br><br>$ cython -Idir foo.pyx<br><br>$ python setup_foo.py build_ext -c mingw32 -i<br>running build_ext<br>error: file 'bar.pxd' does not exist<br><br>$ mv dir/bar.pxd .<br><br>$ python setup_foo.py build_ext -c mingw32 -i<br>
running build_ext<br>building 'foo' extension<br>... compiles successfully ...<br><br>$ cat foo.pyx<br>cimport bar<br><br>$ cat bar.pxd<br><br>$ cat setup_foo.py<br>from distutils.core import setup<br>from distutils.extension import Extension<br>
from Cython.Distutils import build_ext<br><br>setup(<br>&nbsp;&nbsp;&nbsp; cmdclass = {'build_ext': build_ext},<br>&nbsp;&nbsp;&nbsp; ext_modules = [Extension('foo', ['foo.pyx'])]<br>)<br><br>This is with Python 2.5.4, Cython 0.11.2, and MinGW from Cygwin on Windows.<br><br>Thanks.<br><br>[1] <a href="http://docs.cython.org/docs/sharing_declarations.html#search-paths-for-definition-files">http://docs.cython.org/docs/sharing_declarations.html#search-paths-for-definition-files</a><br clear="all"><br>-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br></p></div>

headers

Sébastien Barthélemy | 30 Jun 16:19

[Cython] ImportError: ./pycdd.so: undefined symbol: __gmpq_init

Hello,

after a months-long pause, I'm giving a new try to libcdd wrappers,
and have a few related questions.

first, is it possible to put compile-time definitions (DEF) outside
the file? As an option to cython or to the Cython.Distutil? It would
be useful to reflect #ifdef option in cython from the build script and
avoid some redundancy.

second, is there a way to acces the C file descriptor of python file
types from cython? I could not find it in cython documentation nor in
python C-API reference.

Third, ... well..., it does not work, and I don't understand why. When
I import my module, it fails with the following traceback.

>>> import pycdd
ImportError                               Traceback (most recent call last)
/home/seb/Devel/pypolyhedra/pycdd/≤ipython console> in <module>()
ImportError: ./pycdd.so: undefined symbol: __gmpq_init

any idea of what might happen ?

here is the compile log.

$ LANG=C python setup.py build_ext --inplace && ipython test.py
running build_ext
cythoning pygmp.pyx to pygmp.c
building 'pygmp' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c pygmp.c -o
build/temp.linux-i686-2.6/pygmp.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-i686-2.6/pygmp.o -lgmp -o pygmp.so
cythoning pycdd.pyx to pycdd.c
building 'pycdd' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -Icddlib-094f/lib-src-gmp
-I/usr/include/python2.6 -c pycdd.c -o
build/temp.linux-i686-2.6/pycdd.o
pycdd.c: In function '__pyx_pf_5pycdd_13CddPolyhedron_get_hrep':
pycdd.c:1061: warning: passing argument 1 of
'__pyx_convert__to_py_mpq_t' from incompatible pointer type
pycdd.c:1168: warning: passing argument 1 of
'__pyx_convert__to_py_mpq_t' from incompatible pointer type
pycdd.c: In function '__pyx_f_5pycdd__hrep_to_cdd_matrix':
pycdd.c:1533: warning: passing argument 1 of '__gmpq_set' from
incompatible pointer type
pycdd.c:1595: warning: passing argument 1 of '__gmpq_neg' from
incompatible pointer type
pycdd.c: In function '__pyx_convert__to_py_mpq_t':
pycdd.c:2353: warning: label 'bad' defined but not used
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-i686-2.6/pycdd.o -Lcddlib-094f/lib-src-gmp -lcddgmp
-o pycdd.so

The program is available in there:
 http://perso.crans.org/barthelemy/pycdd.tar.gz
 http://perso.crans.org/barthelemy/pycdd.git/

but I'was expecting to get it a little bit further before asking for a review.

Thank you for any help !

headers

Elliott Slaughter | 29 Jun 20:12

[Cython] Compiling with MinGW

Hi,

I just tried to install Cython with Python 2.5.4 (from the binary installer) on Windows. Since I don't have MSVC installed, I get this message:

C:\...\Cython-0.11.2>python setup.py install
...
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.

But the -c option isn't actually recognized by setup.py:

C:\...\Cython-0.11.2>python setup.py -c mingw32 install
...
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option -c not recognized

And setup.py --help doesn't give any relevant suggestions.

I would appreciate it if someone could point me in the right direction.

Thanks.

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

<div><p>Hi,<br><br>I just tried to install Cython with Python 2.5.4 (from the binary installer) on Windows. Since I don't have MSVC installed, I get this message:<br><br>C:\...\Cython-0.11.2&gt;python setup.py install<br>...<br>

error: Python was built with Visual Studio 2003;<br>extensions must be built with a compiler than can generate compatible binaries.<br>Visual Studio 2003 was not found on this system. If you have Cygwin installed,<br>you can try compiling with MingW32, by passing "-c mingw32" to setup.py.<br clear="all"><br>But the -c option isn't actually recognized by setup.py:<br><br>C:\...\Cython-0.11.2&gt;python setup.py -c mingw32 install<br>...<br>usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]<br>&nbsp;&nbsp; or: setup.py --help [cmd1 cmd2 ...]<br>

&nbsp;&nbsp; or: setup.py --help-commands<br>&nbsp;&nbsp; or: setup.py cmd --help<br><br>error: option -c not recognized<br><br>And setup.py --help doesn't give any relevant suggestions.<br><br>I would appreciate it if someone could point me in the right direction.<br><br>Thanks.<br><br>-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br></p></div>

headers

Dag Sverre Seljebotn | 29 Jun 18:25

[Cython] [Fwd: Re: Surprise: A bool isn't a bool]


-------- Original Message --------
Subject: Re: Surprise: A bool isn't a bool
Date: Mon, 29 Jun 2009 18:26:58 +0200
From: Bjarke Roune <bjarke@...>
To: Dag Sverre Seljebotn <dagss@...>
References:
<mailman.42053.1246289710.27370.cython-dev@...> 
  <4f74ca650906290836t4c2a6f27i45b5b436abe4951c@...>	 
<4A48E772.8030603@...>

> Indeed. The question is whether it is possible to find such a way. Perhaps
> disallow "bool" in cdef extern functions? Although that would add an
> unecesarry typecheck if a C library in fact did return a Python boolean
> object... (like many C functions in Python's standard library might).
>
Perhaps let there be a switch to turn the error or warning off, and
some kind of instruction in a Cython file that turns it off for only
that file.

Cheers
Bjarke

--

-- 
Dag Sverre

headers

Dag Sverre Seljebotn | 29 Jun 18:10

Re: [Cython] Surprise: A bool isn't a bool

Bjarke Roune wrote:
> There seems to be no better way to report issues in Cython than send
> it to someone on the project (I suggest a better way be made that
> doesn't require signing up for something). Here you go.

It is to avoid spam (both on trac and the mailing list). Anyway, thanks 
for reporting. See below.

> On Mon, Jun 29, 2009 at 5:35 PM, <cython-dev-owner@...> wrote:
>> You are not allowed to post to this mailing list, and your message has
>> been automatically rejected.  If you think that your messages are
>> being rejected in error, contact the mailing list owner at
>> cython-dev-owner@...
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Bjarke Roune <bjarke@...>
>> To: cython-dev@...
>> Date: Mon, 29 Jun 2009 17:31:16 +0200
>> Subject: Surprise: A bool isn't a bool
>> I was wrapping a C++ function in Cython, and ran into a mysterious
>> segmentation fault, and the cause turned out to be quite a trap for
>> beginning Cython programmers wrapping C++ libraries. Let's say there
>> was a function like this:
>>
>> bool foo() {
>>    return true;
>> }
>>
>> I then declared it in Cython as
>>
>> cdef extern from "bar.h":
>>    bool foo()
>>
>> and I used the function in code such as
>>
>> if (foo()):
>>    print "baz"
>>
>> This crashed my program with a segmentation violation and no explanation.
>>
>> After a while of looking through my C++ code trying to find the
>> pointer error, I realized that a C++ bool is not a Cython bool, and
>> that since a Cython bool is an object, mismatching the two can lead to
>> a memory error. I replaced bool with bint and everything was fine
>> (though I wonder if Cython ever puts anything other than 0 and 1 into
>> a bint, since only 0 and 1 are valid values for a C++ bool).
>>
>> It is surprising and confusing to a beginning Cython user such as me
>> that a bool isn't a bool, and if there is any way to issue some sort
>> of warning about mismatching a C++ bool with a Cython bool, I think
>> that would be a good idea.

Indeed. The question is whether it is possible to find such a way. 
Perhaps disallow "bool" in cdef extern functions? Although that would 
add an unecesarry typecheck if a C library in fact did return a Python 
boolean object... (like many C functions in Python's standard library 
might).

--

-- 
Dag Sverre

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31