Re: [Cython] Some more optimisations

Hi Robert,

Robert Bradshaw wrote:
> On Jan 24, 2008, at 2:53 AM, Stefan Behnel wrote:
>> What I could imagine, on the other hand, is exploiting the type hint
>> given by
>> *args and **kwargs and propagate that (at least up to the next
>> assignment), so
>> that access to the variables can use straight PyAPI calls. But as Kay
>> noted,
>> we don't currently have a framework for questions like: where is "the
>> next assignment?".
> 
> What we need is special list/dict/tuple types. I know Greg (eventually)
> plans to do something like this too. They would be like extension types,
> though should fail for subtypes (e.g. if one subclasses a list, then one
> can't assign it to a cdef list variable, or it might invalidate using
> the faster api's).

If we require exact types (no subtypes), we would be inconsistent with how
things currently work for extension types (and Python types). The only
exception are plain C types. So here, list/dict/tuple would basically behave
like a C type (but I guess it would be enough to document that...)

> As for the type assignment propagation, I think we need to introduce a
> two-pass analyses_types. There would be a special undeclared type, and
> by tracking assignments one could create a dependancy tree of types. One
> would then use this to resolve all variable types and run analyses_types
> again.
> 

Re: [Cython] Some more optimisations

Stefan Behnel wrote:

> One thing I'm not sure about is how to propagate undeclared function result
> types. If we can figure out what type a function has, we can use that type.
> But the function might be declared later in the code, so we wouldn't have that
> information early enough. I think that's where two passed are required.

I think you're absolutely right, and that's the standard answer to this. 
  Is making a separate pass difficult?

Best,
Martin

Re: [Cython] Some more optimisations

Hi,

Martin C. Martin wrote:
> Stefan Behnel wrote:
> 
>> One thing I'm not sure about is how to propagate undeclared function
>> result
>> types. If we can figure out what type a function has, we can use that
>> type.
>> But the function might be declared later in the code, so we wouldn't
>> have that
>> information early enough. I think that's where two passed are required.
> 
> I think you're absolutely right, and that's the standard answer to this.

Now that I give it another thought, there's one very ugly thing to deal with.
Imagine this:

  cdef f1(a):
      d = f2(a)
      d[1] = 1
      return d

  cdef f2(a):
      d = f3(a)
      d[2] = 2
      return d

  cdef f3(a):
      d = f4(a)

[Cython] Cython code fails to compile with gcc 2.95

Hi,

I know, that's a pretty old compiler, but I know someone with a Solaris
production setup that still uses it. Here is the compile error he gets:

--------------------------------
src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong':
src/lxml/lxml.etree.c:110165: parse error before `long'
src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this function)
src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported only once
src/lxml/lxml.etree.c:110167: for each function it appears in.)
src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong':
src/lxml/lxml.etree.c:110185: parse error before `long'
src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this function)
error: command 'gcc' failed with exit status 1
--------------------------------

The problem lies in the new type conversion functions:

--------------------------------
 110156 static INLINE PY_LONG_LONG __pyx_PyInt_AsLongLong(PyObject* x) {
 110157     if (PyInt_CheckExact(x)) {
 110158         return PyInt_AS_LONG(x);
 110159     }
 110160     else if (PyLong_CheckExact(x)) {
 110161         return PyLong_AsLongLong(x);
 110162     }
 110163     else {
 110164         PyObject* tmp = PyNumber_Int(x); if (!tmp) return
(PY_LONG_LONG)-1;

[Cython] [PATCH] Demos: pyrexc -> cython

# HG changeset patch
# User Kirill Smelkov <kirr@...>
# Date 1201862775 -10800
# Node ID bcc813057f913c757d2629649b35ae999629e5d5
# Parent  be19ff60769b44621e4857435897a635026636fb
Demos: pyrexc -> cython

diff --git a/Demos/Makefile.nodistutils b/Demos/Makefile.nodistutils
--- a/Demos/Makefile.nodistutils
+++ b/Demos/Makefile.nodistutils
 <at>  <at>  -4,7 +4,7  <at>  <at>  PYINCLUDE = \
 	-I$(PYHOME)/$(ARCH)/include/python2.2

 %.c:	%.pyx
-	../bin/pyrexc $<
+	../bin/cython $<

 %.o:	%.c
 	gcc -c -fPIC $(PYINCLUDE) $<
diff --git a/Demos/embed/Makefile b/Demos/embed/Makefile
--- a/Demos/embed/Makefile
+++ b/Demos/embed/Makefile
 <at>  <at>  -9,7 +9,7  <at>  <at>  PYLIB = -L$(PYARCH)/lib/python$(PYVERSIO
 	-ldl -lpthread -lutil -lm

 %.c:	%.pyx
-	../../bin/pyrexc $<
+	../../bin/cython $<

 %.o:	%.c

[Cython] problem running 'make test' (cython 0.9.6.11b)

Hi,

I'm a former Pyrex user and recently I've decided to play with Cython.
Running tests is a problem:

kirr <at> evo:~/src/tools/cython/Cython-0.9.6.11b$ make test
rm -fr BUILD
python runtests.py
Traceback (most recent call last):
  File "runtests.py", line 6, in ?
    from Cython.Distutils.extension import Extension
ImportError: No module named extension
make: *** [test] Ошибка 1

'make test' fails with both
 - Cython-0.9.6.11b, and
 - latest cython-package (be19ff60769b) + cython-devel (93e412adb69a)

--

-- 
    Всего хорошего, Кирилл.
    http://landau.phys.spbu.ru/~kirr/aiv/
_______________________________________________
Cython-dev mailing list
Cython-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev

Re: [Cython] problem running 'make test' (cython 0.9.6.11b)

Hi,

Kirill Smelkov wrote:
> I'm a former Pyrex user and recently I've decided to play with Cython.
> Running tests is a problem:
> 
> kirr <at> evo:~/src/tools/cython/Cython-0.9.6.11b$ make test
> rm -fr BUILD
> python runtests.py
> Traceback (most recent call last):
>   File "runtests.py", line 6, in ?
>     from Cython.Distutils.extension import Extension
> ImportError: No module named extension
> make: *** [test] Ошибка 1
> 
> 'make test' fails with both
>  - Cython-0.9.6.11b, and
>  - latest cython-package (be19ff60769b) + cython-devel (93e412adb69a)

Hmm, interesting. Cython/Distutils/extension.py is no longer under version
control. It still has a data entry in Cython/.hg, though. Robert, do you have
that file? I attached mine, just in case. It's only used to support additional
Extension options starting with "pyrex_".

Stefan

Hi,

Re: [Cython] Cython code fails to compile with gcc 2.95

> Hi,
> 
> I know, that's a pretty old compiler, but I know someone with a Solaris
> production setup that still uses it. Here is the compile error he gets:
> 
> --------------------------------
> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsLongLong':
> src/lxml/lxml.etree.c:110165: parse error before `long'
> src/lxml/lxml.etree.c:110167: `val' undeclared (first use in this function)
> src/lxml/lxml.etree.c:110167: (Each undeclared identifier is reported only once
> src/lxml/lxml.etree.c:110167: for each function it appears in.)
> src/lxml/lxml.etree.c: In function `__pyx_PyInt_AsUnsignedLongLong':
> src/lxml/lxml.etree.c:110185: parse error before `long'
> src/lxml/lxml.etree.c:110187: `val' undeclared (first use in this function)
> error: command 'gcc' failed with exit status 1
> --------------------------------
> 
> The problem lies in the new type conversion functions:
> 
> --------------------------------
>  110156 static INLINE PY_LONG_LONG __pyx_PyInt_AsLongLong(PyObject* x) {
>  110157     if (PyInt_CheckExact(x)) {
>  110158         return PyInt_AS_LONG(x);
>  110159     }
>  110160     else if (PyLong_CheckExact(x)) {
>  110161         return PyLong_AsLongLong(x);
>  110162     }
>  110163     else {
>  110164         PyObject* tmp = PyNumber_Int(x); if (!tmp) return
> (PY_LONG_LONG)-1;

Re: [Cython] Cython code fails to compile with gcc 2.95

Hi,

Sven Berkvens-Matthijsse wrote:
> The problem is that GCC 2.95 does not follow C99 semantics, and the C
> version that it adheres to does not allow variables to be declared in
> the middle of a block. All variables must be declared at the top of a
> block. In the above case:
> 
> 110164         PyObject* tmp = PyNumber_Int(x); if (!tmp) return (PY_LONG_LONG)-1;
> 110165         PY_LONG_LONG val = __pyx_PyInt_AsLongLong(tmp);
> 
> the 'if' statement on line 110164 terminates the end of the variable
> declarations in the block. Line 110165 tries to declare one in the
> middle of some statements, which was not allowed before C99.

Ah, sure, that makes sense. So here's the obvious fix.

Thanks a lot,
Stefan

Hi,

Sven Berkvens-Matthijsse wrote:
> The problem is that GCC 2.95 does not follow C99 semantics, and the C
> version that it adheres to does not allow variables to be declared in
> the middle of a block. All variables must be declared at the top of a
> block. In the above case:

Re: [Cython] Some more optimisations

Stefan Behnel wrote:
> Hi,
> 
> Martin C. Martin wrote:
>> Stefan Behnel wrote:
>>
>>> One thing I'm not sure about is how to propagate undeclared function
>>> result
>>> types. If we can figure out what type a function has, we can use that
>>> type.
>>> But the function might be declared later in the code, so we wouldn't
>>> have that
>>> information early enough. I think that's where two passed are required.
>> I think you're absolutely right, and that's the standard answer to this.
> 
> Now that I give it another thought, there's one very ugly thing to deal with.
> Imagine this:
> 
>   cdef f1(a):
>       d = f2(a)
>       d[1] = 1
>       return d
> 
>   cdef f2(a):
>       d = f3(a)
>       d[2] = 2
>       return d
> 
>   cdef f3(a):