[Cython] Gsoc project

2012-03-27 Thread Philip Herron
Hey

I got linked to your idea
http://groups.google.com/group/cython-users/browse_thread/thread/cb8aa58083173b97/cac3cf12d438b122?show_docid=cac3cf12d438b122&pli=1
by David Malcolm on his plugin mailing list.

I am looking to apply to Gsoc once again this year i have done gsoc
2010 and 2011 on GCC implementing my own GCC front-end for python
which is still in very early stages since its a huge task. But i am
tempted to apply to this project to implement a more self contained
project to give back to the community more promptly while that hacking
on my own front-end on my own timer. And i think it would benefit me
to get to understand in more detail different aspects of python which
is what i need and would gain very much experience from.

I was wondering if you could give me some more details on how this
could all work i am not 100% familiar with cython but i think i
understand it to a good extend from playing with it for most of my
evening. I just want to make sure i understand the basic use case of
this fully, When a user could have something like:

-header foo.h

extern int add (int, int);

-source foo.c

#include "foo.h"

int add (int x, int y)
{
  return x+y;
}

We use the plugin to go over the decls created and create a pxd file like:

cdef int add (int a, int b):
return a + b

Although this is a really basic example i just want to make sure i
understand whats going on. Maybe some more of you have input? I guess
this would be best suited as a proposal for Python rather than GCC?

--Phil
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] Gsoc project

2012-03-28 Thread Philip Herron
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

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.

--Phil
import gcc
import re
from pprint import pformat
from gccutils import get_src_for_loc, cfg_to_dot, invoke_dot

decls = []

def decl_location_get_file (decl):
repr = ('%r' % decl.location)
idx = repr.index ('file=')
idy = repr.index ('line=')
file_string = ""
for i in range (idx+6, idy-3):
file_string += repr[i]
return file_string

def generate_pxd_decl_function (fd, decl):
fmt = "%s" % decl.type
ident = '%s' % decl
if re.search ("<.*>", fmt):
func = re.sub ("<.*>", ident, fmt)
fd.write ("cdef extern from \"%s\":\n" % decl_location_get_file (decls[0]))
fd.write ('\t%s\n' % func)

def decl_identifier_node_to_string (node):
repr = ('%r' % node)
idx = repr.index ('name=')
idy = repr.index (')')
retval = ""
for i in range (idx+6, idy-1):
retval += repr [i]
return retval

def generate_pxd_decl_type (fd, decl):
if ('%s' % type (decl.type)) == "":
ident = decl_identifier_node_to_string (decl.type.name)
fd.write ("\tctypedef struct %s:\n" % ident)
for f in decl.type.fields:
fd.write ("\t\t%s %s\n" % (f.type, f.name))

def generate_pxd_data (T, fd, decl):
if T == "":
return generate_pxd_decl_function (fd, decl)
elif T == "":
return generate_pxd_decl_type (fd, decl)
else:
print "unhandled type <%s>!\n" % T

def walk_generate_pxd_decls ():
if len (decls) > 0:
fd = open ('out.pxd', 'w')
for decl in decls:
print('%r:%s:%s' % (decl.location, decl, decl.type)) 
decl_type = '%s' % type (decl)
generate_pxd_data (decl_type, fd, decl)
fd.write ("\n")
fd.close ()

def on_pass_execution (p, fn):
if p.name == '*free_lang_data':
for u in gcc.get_translation_units ():
for decl in u.block.vars:
f = decl_location_get_file (decl)
if f != '':
decls.append (decl)
walk_generate_pxd_decls ()

gcc.register_callback (gcc.PLUGIN_PASS_EXECUTION, on_pass_execution)
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] new FFI library for Python

2012-06-18 Thread Philip Herron
On 18 June 2012 15:12, Stefan Behnel  wrote:
> Hi,
>
> the PyPy folks have come up with a new FFI library (called cffi) for
> CPython (and eventually PyPy, obviously).
>
> http://cffi.readthedocs.org/
>
> It borrows from LuaJIT's FFI in that it parses C declarations at runtime.
> It then builds a C extension to access the external code, i.e. it requires
> a C compiler at runtime (when running in CPython).
>
> Just thought this might be interesting.
>
> Stefan
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel

I have been using libffi in my gccpy runtime wonder why they decided
to make a new one and not use libffi

--Phil
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel


[Cython] GCC Pxd

2014-04-30 Thread Philip Herron
Hey all,

Some of you may remember a project i worked on for GSoC 2012, i wasn't
really happy with the project over all for a long time it basicaly
required at the time people to be running GCC from latest SVN/GIT for
it to work correctly.

Now gcc >= 4.7 is becoming more normal, so i went back into it and
rewrote it from scratch now and its shaping up to look fairly decent
and usable now.

https://github.com/redbrain/cython/tree/master/Tools/gccpxd

So the idea for this project is that you write a small configuration
file and it will integrate with your C/C++ build system for example
you could do:

./configure CC=cygcc ...
make
...

And you will get a project.pxd file after the build of your software.
the cygcc is simply a wrapper over GCC that shoves in the fplugin
arguments so you can run:

cygcc -g -O2 -Wall -c test.c -o test.o

So build systems wont really notice anything different it should just
think its gcc. The configuration file example in the folder .cygcc:

$ cat .cygcc
header = 'test.h' # the header to get declaratiosn for
inputs = ['test.h', 'test.c'] # any locations of declarations that
would be involved
output = 'test.pxd'  # the output

The cygcc compiler looks for this in the current director or looks up
at the parent directory untill it finds it or it will fail with an
error message.

It will only ouput once if the test.pxd file exists in the current
working directory it wont do anything.

$ cat test.pxd
cdef extern from "test.h":
  int test (int, int)
  int global_variable
  int static_variable # this is a bug but hey...
  struct bla:
int a
float b

So far for the example code in there its working pretty well the gcc
python plugin has stabalized alot and so has some of gcc's bits a
bobs. I will try and keep you all updated i think the plugin is doing
alot more work now so this doesnt have to do so much.

Thanks to Robert Bradshaw for baring with me in the whole thing
because i probably wasn't the easiest to work with ;) lol.

Thanks everyone cython is awesome.

--Phil
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel


Re: [Cython] GCC Pxd

2014-05-09 Thread Philip Herron
Just small update i think i have got most of C code working now, but
working on C++ generation again its all shaping up to look pretty
usable. I wonder by the off chance is there a python library that can
parse the C preprocessor if anyone knows or not i am looking at
https://code.google.com/p/pypreprocessor/ to try and parse cpp as this
information is lost at the Middle-end level in GCC where the plugin
runs.

On 1 May 2014 14:01, Stefan Behnel  wrote:
> [forwarding Philip's mail to the Cython users mailing list]
>
> Hey all,
>
> Some of you may remember a project i worked on for GSoC 2012, i wasn't
> really happy with the project over all for a long time it basicaly
> required at the time people to be running GCC from latest SVN/GIT for
> it to work correctly.
>
> Now gcc >= 4.7 is becoming more normal, so i went back into it and
> rewrote it from scratch now and its shaping up to look fairly decent
> and usable now.
>
> https://github.com/redbrain/cython/tree/master/Tools/gccpxd
>
> So the idea for this project is that you write a small configuration
> file and it will integrate with your C/C++ build system for example
> you could do:
>
> ./configure CC=cygcc ...
> make
> ...
>
> And you will get a project.pxd file after the build of your software.
> the cygcc is simply a wrapper over GCC that shoves in the fplugin
> arguments so you can run:
>
> cygcc -g -O2 -Wall -c test.c -o test.o
>
> So build systems wont really notice anything different it should just
> think its gcc. The configuration file example in the folder .cygcc:
>
> $ cat .cygcc
> header = 'test.h' # the header to get declaratiosn for
> inputs = ['test.h', 'test.c'] # any locations of declarations that
> would be involved
> output = 'test.pxd'  # the output
>
> The cygcc compiler looks for this in the current director or looks up
> at the parent directory untill it finds it or it will fail with an
> error message.
>
> It will only ouput once if the test.pxd file exists in the current
> working directory it wont do anything.
>
> $ cat test.pxd
> cdef extern from "test.h":
>   int test (int, int)
>   int global_variable
>   int static_variable # this is a bug but hey...
>   struct bla:
> int a
> float b
>
> So far for the example code in there its working pretty well the gcc
> python plugin has stabalized alot and so has some of gcc's bits a
> bobs. I will try and keep you all updated i think the plugin is doing
> alot more work now so this doesnt have to do so much.
>
> Thanks to Robert Bradshaw for baring with me in the whole thing
> because i probably wasn't the easiest to work with ;) lol.
>
> Thanks everyone cython is awesome.
>
> --Phil
>
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel