Bug#782275: pre-parsed cffi runtime data structures

2015-04-15 Thread Stefano Rivera
Control: tag -1 upstream

Hi Glyph (2015.04.13_23:46:18_-0400)
> Right now, cffi uses pycparser to parse the declarations for two reasons:
> 
> 1. to generate the .c file which it then compiles, at build time
> 2. to generate the run-time metadata it uses to invoke that library, at run 
> time

Yep. The plan is to serialize the run-time metadata into something at
build time, in cffi 1.0.

Armin is working on this:
https://groups.google.com/forum/#!topic/python-cffi/DKfxxcMmaGw

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#782275: pre-parsed cffi runtime data structures

2015-04-13 Thread Glyph
Right now, cffi uses pycparser to parse the declarations for two reasons:

1. to generate the .c file which it then compiles, at build time
2. to generate the run-time metadata it uses to invoke that library, at run time

there is no intermediary representation of the signatures which pycparser 
produces outside of this parsing, so right now, you still need pycparser no 
matter what.  Perhaps it would be good to generate such a representation so 
that the C code does not need to be parsed?  This would be a pretty major 
change, though.  This might also help with some memory usage issues where lots 
of pycparser internals persist after importing a module which has lots of cffi 
declarations in it.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org