CFFI 1.0.0 beta 1

[Armin Rigo]

Hi all,

CFFI 1.0.0 beta 1 has been released. Feedback welcome!

http://morepypy.blogspot.com/2015/05/cffi-10-beta-1.html

...and thank you to the PSF for the financial support :-)


Armin

[Ryan Gonzalez]

So, I think I asked this before, but will these changes affect us who are just using ffi.dlopen, not ffi.verify?

Armin

--
-- python-cffi: To unsubscribe from this group, send email to python-cffi...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/python-cffi?hl=en
---
You received this message because you are subscribed to the Google Groups "python-cffi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-cffi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ryan

[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.

http://kirbyfan64.github.io/

 

[Armin Rigo]

Hi Ryan,

On 5 May 2015 at 20:13, Ryan Gonzalez <rym...@gmail.com> wrote:
> So, I think I asked this before, but will these changes affect us who are
> just using ffi.dlopen, not ffi.verify?

Maybe later, but not in this version. (It would be possible to
produce a flat file that is not a C source file, but still contains
the pre-parsed encoded version of the cdef(), using a separate "build"
step. It would massively reduce the import times for large cdefs even
if you're using ffi.dlopen().)


A bientôt,

Armin.

[Daniel Holth]

I've just tried it here with my pysdl2-cffi binding on Python 2.7 on Ubuntu 15.04. This is just an extremely rough hack to try to make something work. Previously pysdl2-cffi only used 'dlopen'. The full binding does use .include() to pull the base SDL2 into the optional image, mixer, and ttf libraries.

I run "python -m _sdl.cdefs" to compile the extension, then I can run "python tests/testdrawchessboard.py" to draw a chess board. It starts up instantly, wonderful! SDL2 is big enough that startup on older cffi is very slow.

https://bitbucket.org/dholth/pysdl2-cffi/commits/c521ee1052dec3e79177f2fe9b1d0e465a8e3a06

[Armin Rigo]

Hi Daniel,

On 7 May 2015 at 04:47, Daniel Holth <dho...@gmail.com> wrote:
> I've just tried it here with my pysdl2-cffi binding on Python 2.7 on Ubuntu
> 15.04.

Thanks for the feedback!

The PyPy version is soon ready, and I'll then write docs. The planned
release date is next week. Here's a preview of what I'd like to put
in the docs:

* I was pointed out that the current docs recommend
``ext_package=".."`` in setup.py in large projects using ffi.verify().
Remember to remove that (or to handle its effect manually) when you
are switching to ffi.set_source(). Note that the latter lets you use
a full package path, as in ``ffi.set_source("myproj._myext", ...)``.

* in addition to the distutils and setuptools solutions presented (see
blog post), you can also just produce statically and distribute the C
file (it is a completely regular C extension module then). Note that
an identical C file should be generated on any platform you run the
build script on --- but, of course, only if the way you assemble the
cdef() and the set_source() arguments is independent on the
environment. If it is not (e.g. you are checking some library version
to know if some extra cdef() lines should be included), then you
cannot distribute a static C file.

TO-DOs that will likely be done only in the next cffi version:

* the "cffi-runtime" package. For now just list "cffi" as a
setuptools dependency, both in setup_requires and install_requires.

* if you use ffi.dlopen(), you don't call any compiler, but you might
also have startup-time issues because of ``pycparser`` working its way
through a big cdef(). The idea to improve it would be to also move
the cdef() to a build.py script, but call ``ffi.set_source("module",
source=None)``. This would tell CFFI to produce a .py file instead of
a .c file. The .py file would contain a line like ``ffi =
_cffi_backend.FFI("big-string")``, where the big string is the
preprocessed binary representation of the cdef() --- a Python
equivalent to what is written in the .c file with set_source("module",
"source").

* ffi.new("xyz"), ffi.cast("xyz"), etc.: these calls always cache the
mapping from the string "xyz" to the <ctype object>. It always used
to, but in cffi < 1.0 this cache would be freed in some circumstances;
now the cache is really immortal. This might be improved in the
future, maybe by using a WeakValueDictionary-like solution. Note that
it is recommended that the type strings be constants anyway, so this
is for people who really need "int[%d]" % size. (For reference, you
can sometimes say it differently: for example, ``ffi.new("int[]",
size)``. But there is no such alternative for "int[%d][%d]" % (size1,
size2).)


A bientôt,

Armin

[Floris Bruynooghe]

Hi Armin,

Thanks for working on this!

On 5 May 2015 at 18:45, Armin Rigo <ar...@tunes.org> wrote:
> CFFI 1.0.0 beta 1 has been released. Feedback welcome!
>
> http://morepypy.blogspot.com/2015/05/cffi-10-beta-1.html

One thing that stands out to me is the syntax for the cffi_modules
parameter of the setuptools integration. It requires the "module:ffi"
syntax where the "ffi" part is said to be a global variable.
Unfortunately that forces one to have ffi as a global variable, in
turn forcing a lot of code to be executed at import time. Would it
not be possible to say the "ffi" part must be either the cffi.FFI
instance or a callable which will return such an instance? For my
personal taste that would allow a cleaner structure of the
foo_build.py module. I also suspect that as this module grows it
would give you more flexibility to construct the required object.


Best Regards,
Floris

[Armin Rigo]

Hi Floris,

On 9 May 2015 at 12:57, Floris Bruynooghe <fl...@devork.be> wrote:
> One thing that stands out to me is the syntax for the cffi_modules
> parameter of the setuptools integration. It requires the "module:ffi"
> syntax where the "ffi" part is said to be a global variable.
> Unfortunately that forces one to have ffi as a global variable, in
> turn forcing a lot of code to be executed at import time. Would it
> not be possible to say the "ffi" part must be either the cffi.FFI
> instance or a callable which will return such an instance?

Yes, I can add this. It's a matter of taste, because foo_build.py
should only be imported by this setup code which will need the ffi
immediately anyway. It can also be done, obviously, by adding the
line "ffi = myfunc()" at the end of foo_build.py. But anyway, added
in 13a728b641ba.

Thanks for the feedback!
Armin.

[Ryan Gonzalez]

Ok, just wanted to insert something quickly. Is there a particular reason CFFI uses pycparser? I might be wrong, but all I ever see in cdefs are function prototypes, typedefs, and structs. The rest of C is never there. Couldn't CFFI use a custom parser that's design for that limited subset of C99?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Armin Rigo]

Hi Ryan,

On 9 May 2015 at 17:33, Ryan Gonzalez <rym...@gmail.com> wrote:
> Ok, just wanted to insert something quickly. Is there a particular reason
> CFFI uses pycparser?

You're correct, it uses a subset only. By the way, that means it
doesn't need to handle the keywords specific to statements (say "for"
and "while"), but that's about it. Almost all the rest of the
messiness of parsing C can be found in declarations of types and
globals.

More importantly, CFFI 1.0 already contains a custom parser, for the
types given e.g. in ffi.new("int[10]"). So CFFI 1.0 only uses
pycparser when it needs the rest of the Python code of CFFI, which
is/should-soon-be only at build time. There is really no incentive
left to rewrite pycparser at this point.


A bientôt,

Armin.