http://shootout.alioth.debian.org/

Hi,

Craig Citro just gave a very nice Cython talk (in lieu of Robert
Bradshaw), and there were about 30 questions from the audience, hence
a lot of interest:

   http://sage.math.washington.edu/talks/20090131-seapig/cython.pdf

One question that came up -- could somebody add cython to
http://shootout.alioth.debian.org/
?

It might be fun, since basically C wins every single one of the
language shootouts -- so Cython likely would do very well.

 -- William

--

-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Cython] Cython 0.11 beta fails to install with Python 3.0

Hello,

I just tried to install Cython 0.11 beta with Python 3.0. I get the
following error:

case:~/src/Cython-0.11.beta$ py30 setup.py install
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    from Cython.Compiler.Version import version
  File "/home/case/src/Cython-0.11.beta/Cython/__init__.py", line 2, in <module>
    from Shadow import *
ImportError: No module named Shadow

It does install successfully using Python 2.5 and 2.6. Please let me
know if there is any other information you need.

casevh

Re: [Cython] Cython 0.11 beta fails to install with Python 3.0

Case Vanhorsen wrote:
> Hello,
>
> I just tried to install Cython 0.11 beta with Python 3.0. I get the
> following error:
>
> case:~/src/Cython-0.11.beta$ py30 setup.py install
> Traceback (most recent call last):
>   File "setup.py", line 5, in <module>
>     from Cython.Compiler.Version import version
>   File "/home/case/src/Cython-0.11.beta/Cython/__init__.py", line 2, in <module>
>     from Shadow import *
> ImportError: No module named Shadow
>
> It does install successfully using Python 2.5 and 2.6. Please let me
> know if there is any other information you need.
>   
I had the impression that Cython doesn't support being run under Python 
3 (though Stefan would have the definitive answer on that). I think you 
must install on Python 2.6, and then compile your .pyx to .c under 2.6, 
and THEN you can compile the c file with the Python 3 headers to get a 
Python 3 module.

Dag Sverre

[Cython] fixing refnanny macros to avoid GCC warnings

I'm now getting many warnings like below:

src/petsc4py_PETSc.c: In function '__pyx_f_8petsc4py_5PETSc_asarray':
src/petsc4py_PETSc.c:3793: warning: value computed is not used

A possible fix, written following the way core Python Py_XDECREF,
would be the following:

diff -r 83075bb3a319 Cython/Compiler/ModuleNode.py
--- a/Cython/Compiler/ModuleNode.py	Fri Jan 30 23:10:52 2009 +0100
+++ b/Cython/Compiler/ModuleNode.py	Mon Feb 02 14:08:33 2009 -0300
 <at>  <at>  -2334,7 +2334,7  <at>  <at> 
 #define __Pyx_GOTREF(r) __Pyx_Refnanny_GOTREF(__pyx_refchk, r, __LINE__)
 #define __Pyx_GIVEREF(r) __Pyx_Refnanny_GIVEREF(__pyx_refchk, r, __LINE__)
 #define __Pyx_DECREF(r) __Pyx_Refnanny_DECREF(__pyx_refchk, r, __LINE__)
-#define __Pyx_XDECREF(r) (r ? __Pyx_Refnanny_DECREF(__pyx_refchk, r,
__LINE__) : 0)
+#define __Pyx_XDECREF(r) if((r) == NULL) ; else __Pyx_DECREF(r)
 #define __Pyx_SetupRefcountContext(name) \
   void* __pyx_refchk = __Pyx_Refnanny_NewContext(name, __LINE__)
 #define __Pyx_FinishRefcountContext()
__Pyx_Refnanny_FinishContext(__pyx_refchk)
 <at>  <at>  -2347,6 +2347,6  <at>  <at> 
 #define __Pyx_SetupRefcountContext(name)
 #define __Pyx_FinishRefcountContext() 0
 #endif /* CYTHON_REFNANNY */
-#define __Pyx_XGIVEREF(r) (r ? __Pyx_GIVEREF(r) : 0)
-#define __Pyx_XGOTREF(r) (r ? __Pyx_GOTREF(r) : 0)
+#define __Pyx_XGIVEREF(r) if((r) == NULL) ; else __Pyx_GIVEREF(r)
+#define __Pyx_XGOTREF(r) if((r) == NULL) ; else __Pyx_GOTREF(r)

Re: [Cython] fixing refnanny macros to avoid GCC warnings

Lisandro Dalcin wrote:
> I'm now getting many warnings like below:
> 
> src/petsc4py_PETSc.c: In function '__pyx_f_8petsc4py_5PETSc_asarray':
> src/petsc4py_PETSc.c:3793: warning: value computed is not used
> 
> A possible fix, written following the way core Python Py_XDECREF,
> would be the following:
> 
> 
> diff -r 83075bb3a319 Cython/Compiler/ModuleNode.py
> --- a/Cython/Compiler/ModuleNode.py	Fri Jan 30 23:10:52 2009 +0100
> +++ b/Cython/Compiler/ModuleNode.py	Mon Feb 02 14:08:33 2009 -0300
>  <at>  <at>  -2334,7 +2334,7  <at>  <at> 
>  #define __Pyx_GOTREF(r) __Pyx_Refnanny_GOTREF(__pyx_refchk, r, __LINE__)
>  #define __Pyx_GIVEREF(r) __Pyx_Refnanny_GIVEREF(__pyx_refchk, r, __LINE__)
>  #define __Pyx_DECREF(r) __Pyx_Refnanny_DECREF(__pyx_refchk, r, __LINE__)
> -#define __Pyx_XDECREF(r) (r ? __Pyx_Refnanny_DECREF(__pyx_refchk, r,
> __LINE__) : 0)
> +#define __Pyx_XDECREF(r) if((r) == NULL) ; else __Pyx_DECREF(r)
...
> Can I push this?

Go ahead!

--

-- 
Dag Sverre

Re: [Cython] fixing refnanny macros to avoid GCC warnings

Lisandro Dalcin wrote:
> I'm now getting many warnings like below:
> 
> src/petsc4py_PETSc.c: In function '__pyx_f_8petsc4py_5PETSc_asarray':
> src/petsc4py_PETSc.c:3793: warning: value computed is not used
> 

Does this mean that you compile with CYTHON_REFNANNY though?

--

-- 
Dag Sverre

Re: [Cython] fixing refnanny macros to avoid GCC warnings

On Mon, Feb 2, 2009 at 2:34 PM, Dag Sverre Seljebotn
<dagss@...> wrote:
> Lisandro Dalcin wrote:
>> I'm now getting many warnings like below:
>>
>> src/petsc4py_PETSc.c: In function '__pyx_f_8petsc4py_5PETSc_asarray':
>> src/petsc4py_PETSc.c:3793: warning: value computed is not used
>>
>
> Does this mean that you compile with CYTHON_REFNANNY though?
>
> --

No yet. I'm on the process of trying it. But right now I'm having
trouble surely related to temp allocation, and in the process to send
a example for your consideration.

> Dag Sverre
> _______________________________________________
> Cython-dev mailing list
> Cython-dev@...
> http://codespeak.net/mailman/listinfo/cython-dev
>

--

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

Re: [Cython] possible problems with temp allocation?

See the attached pyx file.

A valgrind run points me to the line where you have
"__Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;" basically, DECREF is being
called with __pyx_t_1 being NULL...

  /* "/u/dalcinl/tmp/foo.pyx":10
 *         out = numpy.asarray(out)
 *         out.flat[:] = array
 *     return out             # <<<<<<<<<<<<<<
 *
 *
 */
  __Pyx_INCREF(__pyx_v_out);
  __pyx_r = __pyx_v_out;
  __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
  goto __pyx_L0;

--

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

See the attached pyx file.

[Cython] comments about refnanny implementation...

Dag, I know that the original idea of the dlopen() with RTLD_GLOBAL
was mine, but you know... I'm so idiot sometimes... This is going to
be a REAL pain to make it work, specially if you want to make this
easily portable to the many platforms out there.... For example, Do
the current implementation work on Windows?

Would you agree to completelly change the way the refnany helper
routines are imported?. I'm thinking on a ad-hoc way of doing that,
similar but simpler to the way Cython extension modules can export API
functions.

The only requisite would be that the 'refnanny.so' extension module
can be imported. Then, when you build Cython extensions with
CYTHON_REFNANNY defined, some special code in the module init function
imports the 'refnanny' module and get the pointer to a struct having
pointers to the various routines... No more need to dlopen() or even
import refnanny in order to enable it....

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

Re: [Cython] possible problems with temp allocation?

Lisandro Dalcin wrote:
> See the attached pyx file.
> 
> A valgrind run points me to the line where you have
> "__Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;" basically, DECREF is being
> called with __pyx_t_1 being NULL...

Does this fix it?

http://hg.cython.org/cython-devel/rev/b9fc866182dc

--

-- 
Dag Sverre