Picon

[Cython] Exporting inline functions from a pyx.

Dear Cython developers,
thanks for the awesome compiler!, we recently faced an issue exporting inline functions defined in a .pyx. According to this: http://docs.cython.org/src/tutorial/pxd_files.html
the full inline definition (not just the declaration) should be in the pxd. However, if we put the definition in the .pyx and just its declaration header in the .pxd,  Cython declares a pointer to the inline function similar to:

static CYTHON_INLINE double (*__function_name)(...); /*proto*/

but this causes a compilation error in some platforms (but successfully compiles in others) because variables cannot be declare as inline. You can find a log with the compilation errors here:

I guess it should be possible to detect when a function is inline and in that case remove the CYTHON_INLINE from the pointer declaration, or at least consistently fail in all platforms. Is this a known issue? 

Thank you very much!
With warm regards,
-Omar.
--
"Cada quien es dueño de lo que calla y esclavo de lo que dice"
-Proverbio chino.
"We all are owners of what we keep silent and slaves of what we say"
-Chinese proverb.

http://www.cimat.mx/~omar
<div><div dir="ltr">Dear Cython developers,<div>thanks for the awesome compiler!, we recently faced an issue exporting inline functions defined in a .pyx. According to this:&nbsp;<a href="http://docs.cython.org/src/tutorial/pxd_files.html">http://docs.cython.org/src/tutorial/pxd_files.html</a>
</div>
<div>the full inline definition (not just the declaration) should be in the pxd. However, if we put the definition in the .pyx and just its declaration header in the .pxd, &nbsp;Cython declares a pointer to the inline function similar to:</div>
<div><br></div>
<div>static CYTHON_INLINE double (*__function_name)(...); /*proto*/</div>
<div><br></div>
<div>but this causes a compilation error in some platforms (but successfully compiles in others) because variables cannot be declare as inline. You can find a log with the compilation errors here:</div>
<div>
<a href="http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/shell_5/logs/stdio">http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/shell_5/logs/stdio</a><br>
</div>
<div><br></div>
<div>I guess it should be possible to detect when a function is inline and in that case remove the CYTHON_INLINE from the pointer declaration, or at least consistently fail in all platforms. Is this a known issue?&nbsp;</div>
<div><br></div>
<div>Thank you very much!</div>
<div>With warm regards,</div>
<div>-Omar.<br>-- <br><div class="gmail_signature">"Cada quien es due&ntilde;o de lo que calla y esclavo de lo que dice"<br>-Proverbio chino.<br>"We all are owners of what we keep silent and slaves of what we say"<br>-Chinese proverb.<br><br><a href="http://www.cimat.mx/~omar" target="_blank">http://www.cimat.mx/~omar</a><br>
</div>
</div>
</div></div>
Jeroen Demeyer | 23 May 10:47 2015
Picon

[Cython] Pull request #374 (api mangling prefix) merged in Sage

This has been merged in Sage's version of Cython:
https://github.com/cython/cython/pull/374

The change looks quite innocent, so I so little reason to not merge it 
in Cython master.
Jeroen Demeyer | 21 May 14:21 2015
Picon

[Cython] Broken link to CEP 516

At
http://docs.cython.org/src/reference/compilation.html#compiler-directives
there are two links to "CEP 516" but they are broken.

Jeroen.
Stefan Behnel | 21 May 09:53 2015
Picon

[Cython] a C++ wrapping wishlist

Someone wrote a list of shortcomings after wrapping some C++ code:

http://blog.marcus-brinkmann.de/2014/07/31/cython-trouble/

A couple of these issues are due to misunderstandings (specifically the
"imports" section) or now-fixed bugs (post is almost a year old), but it
seems that some of them are still valid and might be low-hanging fruit.

Stefan
Michael Enßlin | 8 May 14:37 2015

[Cython] Cython generates invalid C code for some generator expressions in cdef functions

Take the following example:

$ cat t2.pyx
cdef void read_callback():
    foo = b"asdf"
    bar = (c for c in foo)

$ cython t2.pyx

$ gcc -I/usr/include/python3.4m t2.c
t2.c: In function ‘__pyx_f_2t2_read_callback’:
t2.c:778:12: error: ‘None’ undeclared (first use in this function)
     return None;
            ^
t2.c:778:12: note: each undeclared identifier is reported only once for
each function it appears in
t2.c:778:5: warning: ‘return’ with a value, in function returning void
     return None;
     ^

Note that the error does not occur for

bar = (c for c in b"asdf")

or

bar = [c for c in b"asdf"]

 ~ mic_e

Take the following example:

$ cat t2.pyx
cdef void read_callback():
    foo = b"asdf"
    bar = (c for c in foo)

$ cython t2.pyx

$ gcc -I/usr/include/python3.4m t2.c
t2.c: In function ‘__pyx_f_2t2_read_callback’:
t2.c:778:12: error: ‘None’ undeclared (first use in this function)
     return None;
            ^
t2.c:778:12: note: each undeclared identifier is reported only once for
each function it appears in
t2.c:778:5: warning: ‘return’ with a value, in function returning void
     return None;
     ^

Note that the error does not occur for

bar = (c for c in b"asdf")

or

bar = [c for c in b"asdf"]

 ~ mic_e

Michael Enßlin | 7 May 15:13 2015

[Cython] Misleading error message when assigning function pointers with differing except* declarations

Hi,

consider the following example:

$ cat demo.pyx
cdef void (*foo)()

cdef void bar() except*:
    pass

foo = bar

$ cython demo.pyx

Error compiling Cython file:
------------------------------------------------------------
...
cdef void (*foo)()

cdef void bar() except*:
    pass

foo = bar
        ^
------------------------------------------------------------

demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)'

this is all expected behavior, but the error message is entirely
misleading; it should be something like

demo.pyx:6:9: Function pointers have incompatible 'except *' declarations.

Note that the same error message also occurs when the pointer is
declared except*, and the function isn't.

~ mic_e

Hi,

consider the following example:

$ cat demo.pyx
cdef void (*foo)()

cdef void bar() except*:
    pass

foo = bar

$ cython demo.pyx

Error compiling Cython file:
------------------------------------------------------------
...
cdef void (*foo)()

cdef void bar() except*:
    pass

foo = bar
        ^
------------------------------------------------------------

demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)'

this is all expected behavior, but the error message is entirely
misleading; it should be something like

demo.pyx:6:9: Function pointers have incompatible 'except *' declarations.

Note that the same error message also occurs when the pointer is
declared except*, and the function isn't.

~ mic_e

Emmanuel Gil Peyrot | 29 Apr 20:11 2015
Picon

[Cython] [PATCH 1/2] Move ~/.pyxbld to $XDG_CACHE_HOME/pyxbld

---
 pyximport/pyximport.py | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/pyximport/pyximport.py b/pyximport/pyximport.py
index 4fd7fe9..710c5eb 100644
--- a/pyximport/pyximport.py
+++ b/pyximport/pyximport.py
 <at>  <at>  -466,9 +466,10  <at>  <at>  def install(pyximport=True, pyimport=False, build_dir=None, build_in_temp=True,
     will not work for most .py files, and will therefore only slow
     down your imports.  Use at your own risk.

-    By default, compiled modules will end up in a ``.pyxbld``
-    directory in the user's home directory.  Passing a different path
-    as ``build_dir`` will override this.
+    By default, compiled modules will end up in a ``pyxbld`` directory
+    in the directory pointed by the ``XDG_CACHE_HOME`` environment
+    variable, or in ``~/.cache/pyxbld`` if ``XDG_CACHE_HOME`` isn’t
+    set.  Passing a different path as ``build_dir`` will override this.

     ``build_in_temp=False`` will produce the C files locally. Working
     with complex dependencies and debugging becomes more easy. This
 <at>  <at>  -501,8 +502,9  <at>  <at>  def install(pyximport=True, pyimport=False, build_dir=None, build_in_temp=True,
     runtime for .py files and Py2 for .pyx files.
     """
     if not build_dir:
-        build_dir = os.path.join(os.path.expanduser('~'), '.pyxbld')
-        
+        build_dir = os.path.join(os.environ.get('XDG_CACHE_HOME',
+            os.path.join(os.path.expanduser('~'), '.cache')), 'pyxbld')
+
     global pyxargs
     pyxargs = PyxArgs()  #$pycheck_no
     pyxargs.build_dir = build_dir
--

-- 
2.3.5

_______________________________________________
cython-devel mailing list
cython-devel <at> python.org
https://mail.python.org/mailman/listinfo/cython-devel
Robert Bradshaw | 27 Apr 20:15 2015
Picon

[Cython] New hosting

Since Cython's inception, we've been able to take advantage of William
Stein's and University of Washington's infrastructure for hosting the
Cython project along side that of Sage. However, due to UW policy,
those days are coming to and end. Maybe it's time--Cython has come a
long way from its birth of SageX + lxml.

So the question is where to move. Our primary needs are not that
large: we've got a site, a bugtracker (trac), and a continuous build
(jenkins) currently being served (the source code and wiki have
already been migrated to github).

I would propose that we look into moving everything we can over to
github. For starters, they now offer serving simple sites from a
repository (cython.org) so that seems an obvious choice. I know their
bug tracking v1 was considered far inferior to trac, but the situation
may be better now (at least worth exploring). We also have travis.ci,
which isn't as configurable as jenkins, but may be good enough. (The
biggest deficiency is that it probably wouldn't allow for building and
testing Sage regularly, or benchmarks, this is the one thing that we
may need to find/provide custom hosting for.)

Thoughts?
Stefan Behnel | 25 Apr 17:40 2015
Picon

[Cython] release preparations for 0.22.1 and 0.23

Hi,

I think it's about time for a new release. I propose to relase 0.22.1 in
the next days, and then start the release cycle for 0.23.

Please make sure everything that you consider a safe bug fix is in the
0.22.x branch. I already copied Jeroen's latest fixes over.

Stefan
Anton D. Kachalov | 23 Apr 11:22 2015
Picon

[Cython] Dash in the executable's filename

Hello.
 
I've found that executable script with dashes in the filename lead to produce wrong cythonized source:
 
   $ touch my-great-script.py
   $ cython my-great-script.py --embed
   $ fgrep PyInit my-great-script.c
PyMODINIT_FUNC PyInit_my-great-script(void); /*proto*/
PyMODINIT_FUNC PyInit_my-great-script(void)
  __Pyx_RefNannySetupContext("PyMODINIT_FUNC PyInit_my-great-script(void)", 0);
          m = PyInit_my-great-script();
 
So, if I don't want to import my final script elsewhere, I'm free to choose any filename for it.
 
--
Anton D. Kachalov
<div>
<div>Hello.</div>
<div>&nbsp;</div>
<div>I've found that executable script with dashes in the filename lead to produce wrong cythonized source:</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; $ touch my-great-script.py</div>
<div>&nbsp;&nbsp; $ cython my-great-script.py --embed</div>
<div>&nbsp;&nbsp; $ fgrep PyInit my-great-script.c<br>PyMODINIT_FUNC PyInit_my-great-script(void); /*proto*/<br>PyMODINIT_FUNC PyInit_my-great-script(void)<br>&nbsp; __Pyx_RefNannySetupContext("PyMODINIT_FUNC PyInit_my-great-script(void)", 0);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m = PyInit_my-great-script();</div>
<div>&nbsp;</div>
<div>So, if I don't want to import my final script elsewhere, I'm free to choose any filename for it.</div>
<div>&nbsp;</div>
<div>-- <br>Anton D. Kachalov</div>
</div>
Michael Enßlin | 22 Apr 22:07 2015

[Cython] Cython produces invalid C code

Hi everybody,

Cython 0.21.1, from Debian Sid, and Cython 0.22, from Gentoo, produce
invalid C Code for the following .pyx file:

$ cat test.pyx
cimport cpython

cdef extern from "test.h":
    cdef void foo(int i = 0)

def bar(self):
    foo(0)

$ cat test.h
void foo(int i);

$ cython test.pyx

$ gcc -c test.c -I/usr/include/python3.4m
test.c: In function ‘__pyx_pf_4test_bar’:
test.c:659:35: error: storage size of ‘__pyx_t_1’ isn’t known
   struct __pyx_opt_args_4test_foo __pyx_t_1;

$ clang test.c -I/usr/include/python3.4m
test.c:659:35: error: variable has incomplete type 'struct
__pyx_opt_args_4test_foo'
  struct __pyx_opt_args_4test_foo __pyx_t_1;
test.c:659:10: note: forward declaration of 'struct
__pyx_opt_args_4test_foo'
  struct __pyx_opt_args_4test_foo __pyx_t_1;

Note that this is a minimal example; removing anything from test.pyx
fixes the issue (the 'cimport' statement, the default value for int i,
and the call to foo). The issue also occurs with --cplus.

Happy debugging,
	mic_e

Hi everybody,

Cython 0.21.1, from Debian Sid, and Cython 0.22, from Gentoo, produce
invalid C Code for the following .pyx file:

$ cat test.pyx
cimport cpython

cdef extern from "test.h":
    cdef void foo(int i = 0)

def bar(self):
    foo(0)

$ cat test.h
void foo(int i);

$ cython test.pyx

$ gcc -c test.c -I/usr/include/python3.4m
test.c: In function ‘__pyx_pf_4test_bar’:
test.c:659:35: error: storage size of ‘__pyx_t_1’ isn’t known
   struct __pyx_opt_args_4test_foo __pyx_t_1;

$ clang test.c -I/usr/include/python3.4m
test.c:659:35: error: variable has incomplete type 'struct
__pyx_opt_args_4test_foo'
  struct __pyx_opt_args_4test_foo __pyx_t_1;
test.c:659:10: note: forward declaration of 'struct
__pyx_opt_args_4test_foo'
  struct __pyx_opt_args_4test_foo __pyx_t_1;

Note that this is a minimal example; removing anything from test.pyx
fixes the issue (the 'cimport' statement, the default value for int i,
and the call to foo). The issue also occurs with --cplus.

Happy debugging,
	mic_e


Gmane