On 29 March 2012 04:28, Dag Sverre Seljebotn <d.s.seljeb...@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@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
