[Cython] Gsoc project

[Chris Colbert]

Are you all aware of CWrap? It goes a long way to generating pxd files for
a C libary. It can, for example, generate valid pxd files for the whole of
the Intel IPP library.

This would likely be a good launching point for a GSOC project, unless you
really want to start from scratch.

https://github.com/enthought/cwrap

It's BSD licensed.


On Thu, Mar 29, 2012 at 5:10 AM, mark florisson
<markflorisson88 at gmail.com>wrote:

> On 29 March 2012 04:28, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no>
> wrote:
> > On 03/28/2012 07:58 PM, Philip Herron wrote:
> >>
> >> Hey all
> >>
> >> I am implemented a very crude and simplistic and very badly programmed
> >> version of a pxd generator i think i understand what were after now
> >> but i would appreciate if you look over what i did to make sure i have
> >> grasped the basic idea for now:
> >>
> >> So if i have:
> >>
> >> #include "test.h"
> >>
> >> int add (int x, int y)
> >> {
> >>   return x + y;
> >> }
> >>
> >> #ifndef __TEST_H__
> >> #define __TEST_H__
> >>
> >> extern int add (int, int);
> >>
> >> struct foobar {
> >>   int a;
> >>   unsigned char * b;
> >> };
> >>
> >> #endif //__TEST_H_
> >>
> >> We run gcc -fplugin=./python.so -fplugin-arg-python-script=walk.py
> test.c
> >>
> >> And i output out.pxd:
> >>
> >> cdef extern from "test.h":
> >>        int add (int, int)
> >>
> >>        ctypedef struct foobar:
> >>                int a
> >>                unsigned char * b
> >
> >
> > Nice. But please use 4 spaces (see PEP 8) :-)
> >
> > More ideas for project proposal:
> >
> > Another slight complication is that you should ideally turn
> >
> > #define FOO 3
> > #define BAR 4
> >
> > into
> >
> > cdef extern from "foo.h":
> >    enum:
> >        FOO
> >        BAR
> >
> > so you need to hook in before the preprocessor and after the preprocessor
> > and dig out different stuff.
>
> David, I'm CCing you as this might be of interest to you.
>
> I think the current GCC plugin support doesn't allow you to do much
> with te preprocessor, it operates entirely after the C preprocessor
> has run. So to support macros we have to consider that for this to
> work the gcc plugin may have to be extended, which uses C to extend
> GCC and Python, so it also requires knowledge of the CPython C API.
> David, would you mind elaborating why C was used for this project and
> not (partially) Cython, and would it be possible to extend the plugin
> with Cython?
>
> > Then what happens if you have
> >
> > #ifdef FOO
> > #define BAR 3
> > #else
> > #define BAR 4
> > #endif
> >
> > ?? I'm not saying it is hard, but perhaps no longer completely trivial
> :-)
> >
> > And like Robert hinted at, supporting all the aspects of C++ might take a
> > little more work, there's just so much different syntax in C++, and
> there's
> > several C++ features Cython just does not support and must be either
> ignored
> > or hacked around (e.g., "const").
> >
> > Supporting stuff like
> >
> > #define MACRO(x) ((x)->field*2)
> >
> > probably belongs in the category of "must be done manually".
> >
> >
> >>
> >> So far in a very crude way it understands structs and functions but
> >> nothing else i can see how it could all work but i see now why you see
> >> it could be a very small project David's plugin system has mostly
> >> everything done for you but i would like to add to his plugin for some
> >> tree access code etc...
> >>
> >> Adding a config file for telling the plugin to not care about certain
> >> things would be a nice addition. It seems interesting the clang idea,
> >> it could be interesting porting this to other front-ends of gcc like
> >> gccgo.
> >
> >
> > Does gccgo use the C ABI so that Cython could call it? If so, go for it!
> >
> > (Fortran is actually very much in use in the Cython userbase and would
> get a
> > lot more "customers" than Go, but if you have more of a CS background or
> > similar I can see why you wouldn't be so interested in Fortran. I didn't
> > believe people were still using Fortran either until I started doing
> > astrophysics, and suddenly it seems to be the default tool everybody uses
> > for everything.)
> >
> > Dag
> >
> > _______________________________________________
> > cython-devel mailing list
> > cython-devel at python.org
> > http://mail.python.org/mailman/listinfo/cython-devel
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20120329/cf2e9732/attachment.html>