py-cffi: updated to 1.12.1
v1.12.1
CPython 3 on Windows: we again no longer compile with Py_LIMITED_API by default because such modules still cannot be used with virtualenv. The problem is that it doesn’t work in CPython <= 3.4, and for technical reason we can’t enable this flag automatically based on the version of Python.
Like before, Issue 350 mentions a workaround if you still want the Py_LIMITED_API flag and either you are not concerned about virtualenv or you are sure your module will not be used on CPython <= 3.4: pass define_macros=[("Py_LIMITED_API", None)] to the ffibuilder.set_source() call.
v1.12
Direct support for pkg-config.
ffi.from_buffer() takes a new optional first argument that gives the array type of the result. It also takes an optional keyword argument require_writable to refuse read-only Python buffers.
ffi.new(), ffi.gc() or ffi.from_buffer() cdata objects can now be released at known times, either by using the with keyword or by calling the new ffi.release().
Windows, CPython 3.x: cffi modules are linked with python3.dll again. This makes them independant on the exact CPython version, like they are on other platforms. It requires virtualenv 16.0.0.
Accept an expression like ffi.new("int[4]", p) if p is itself another cdata int[4].
CPython 2.x: ffi.dlopen() failed with non-ascii file names on Posix
CPython: if a thread is started from C and then runs Python code (with callbacks or with the embedding solution), then previous versions of cffi would contain possible crashes and/or memory leaks. Hopefully, this has been fixed.
Support for ffi.cdef(..., pack=N) where N is a power of two. Means to emulate #pragma pack(N) on MSVC. Also, the default on Windows is now pack=8, like on MSVC. This might make a difference in corner cases, although I can’t think of one in the context of CFFI. The old way ffi.cdef(..., packed=True) remains and is equivalent to pack=1 (saying e.g. that fields like int should be aligned to 1 byte instead of 4).
2019-02-17 00:37:23 +01:00
|
|
|
@comment $NetBSD: PLIST,v 1.8 2019/02/16 23:37:23 adam Exp $
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/${EGG_INFODIR}/PKG-INFO
|
|
|
|
${PYSITELIB}/${EGG_INFODIR}/SOURCES.txt
|
|
|
|
${PYSITELIB}/${EGG_INFODIR}/dependency_links.txt
|
2015-05-28 09:06:32 +02:00
|
|
|
${PYSITELIB}/${EGG_INFODIR}/entry_points.txt
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/${EGG_INFODIR}/not-zip-safe
|
|
|
|
${PYSITELIB}/${EGG_INFODIR}/requires.txt
|
|
|
|
${PYSITELIB}/${EGG_INFODIR}/top_level.txt
|
py-cffi: update to 1.11.0
v1.11
Support the modern standard types char16_t and char32_t. These work like wchar_t: they represent one unicode character, or when used as charN_t * or charN_t[] they represent a unicode string. The difference with wchar_t is that they have a known, fixed size. They should work at all places that used to work with wchar_t (please report an issue if I missed something). Note that with set_source(), you need to make sure that these types are actually defined by the C source you provide (if used in cdef()).
Support the C99 types float _Complex and double _Complex. Note that libffi doesn’t support them, which means that in the ABI mode you still cannot call C functions that take complex numbers directly as arguments or return type.
Fixed a rare race condition when creating multiple FFI instances from multiple threads. (Note that you aren’t meant to create many FFI instances: in inline mode, you should write ffi = cffi.FFI() at module level just after import cffi; and in out-of-line mode you don’t instantiate FFI explicitly at all.)
Windows: using callbacks can be messy because the CFFI internal error messages show up to stderr—but stderr goes nowhere in many applications. This makes it particularly hard to get started with the embedding mode. (Once you get started, you can at least use @ffi.def_extern(onerror=...) and send the error logs where it makes sense for your application, or record them in log files, and so on.) So what is new in CFFI is that now, on Windows CFFI will try to open a non-modal MessageBox (in addition to sending raw messages to stderr). The MessageBox is only visible if the process stays alive: typically, console applications that crash close immediately, but that is also the situation where stderr should be visible anyway.
Progress on support for callbacks in NetBSD.
Functions returning booleans would in some case still return 0 or 1 instead of False or True. Fixed.
ffi.gc() now takes an optional third parameter, which gives an estimate of the size (in bytes) of the object. So far, this is only used by PyPy, to make the next GC occur more quickly (issue 320). In the future, this might have an effect on CPython too (provided the CPython issue 31105 is addressed).
Add a note to the documentation: the ABI mode gives function objects that are slower to call than the API mode does. For some reason it is often thought to be faster. It is not!
2017-09-30 15:09:47 +02:00
|
|
|
${PYSITELIB}/_cffi_backend.so
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/__init__.py
|
|
|
|
${PYSITELIB}/cffi/__init__.pyc
|
|
|
|
${PYSITELIB}/cffi/__init__.pyo
|
py-cffi: update to 1.11.0
v1.11
Support the modern standard types char16_t and char32_t. These work like wchar_t: they represent one unicode character, or when used as charN_t * or charN_t[] they represent a unicode string. The difference with wchar_t is that they have a known, fixed size. They should work at all places that used to work with wchar_t (please report an issue if I missed something). Note that with set_source(), you need to make sure that these types are actually defined by the C source you provide (if used in cdef()).
Support the C99 types float _Complex and double _Complex. Note that libffi doesn’t support them, which means that in the ABI mode you still cannot call C functions that take complex numbers directly as arguments or return type.
Fixed a rare race condition when creating multiple FFI instances from multiple threads. (Note that you aren’t meant to create many FFI instances: in inline mode, you should write ffi = cffi.FFI() at module level just after import cffi; and in out-of-line mode you don’t instantiate FFI explicitly at all.)
Windows: using callbacks can be messy because the CFFI internal error messages show up to stderr—but stderr goes nowhere in many applications. This makes it particularly hard to get started with the embedding mode. (Once you get started, you can at least use @ffi.def_extern(onerror=...) and send the error logs where it makes sense for your application, or record them in log files, and so on.) So what is new in CFFI is that now, on Windows CFFI will try to open a non-modal MessageBox (in addition to sending raw messages to stderr). The MessageBox is only visible if the process stays alive: typically, console applications that crash close immediately, but that is also the situation where stderr should be visible anyway.
Progress on support for callbacks in NetBSD.
Functions returning booleans would in some case still return 0 or 1 instead of False or True. Fixed.
ffi.gc() now takes an optional third parameter, which gives an estimate of the size (in bytes) of the object. So far, this is only used by PyPy, to make the next GC occur more quickly (issue 320). In the future, this might have an effect on CPython too (provided the CPython issue 31105 is addressed).
Add a note to the documentation: the ABI mode gives function objects that are slower to call than the API mode does. For some reason it is often thought to be faster. It is not!
2017-09-30 15:09:47 +02:00
|
|
|
${PYSITELIB}/cffi/_cffi_errors.h
|
2015-05-28 09:06:32 +02:00
|
|
|
${PYSITELIB}/cffi/_cffi_include.h
|
2016-01-18 23:55:13 +01:00
|
|
|
${PYSITELIB}/cffi/_embedding.h
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/api.py
|
|
|
|
${PYSITELIB}/cffi/api.pyc
|
|
|
|
${PYSITELIB}/cffi/api.pyo
|
|
|
|
${PYSITELIB}/cffi/backend_ctypes.py
|
|
|
|
${PYSITELIB}/cffi/backend_ctypes.pyc
|
|
|
|
${PYSITELIB}/cffi/backend_ctypes.pyo
|
2015-05-28 09:06:32 +02:00
|
|
|
${PYSITELIB}/cffi/cffi_opcode.py
|
|
|
|
${PYSITELIB}/cffi/cffi_opcode.pyc
|
|
|
|
${PYSITELIB}/cffi/cffi_opcode.pyo
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/commontypes.py
|
|
|
|
${PYSITELIB}/cffi/commontypes.pyc
|
|
|
|
${PYSITELIB}/cffi/commontypes.pyo
|
|
|
|
${PYSITELIB}/cffi/cparser.py
|
|
|
|
${PYSITELIB}/cffi/cparser.pyc
|
|
|
|
${PYSITELIB}/cffi/cparser.pyo
|
Updated py-cffi to 1.10.0.
v1.10
Issue #295: use calloc() directly instead of PyObject_Malloc()+memset()
to handle ffi.new() with a default allocator. Speeds up
ffi.new(large-array) where most of the time you never touch
most of the array.
Some OS/X build fixes (“only with Xcode but without CLT”).
Improve a couple of error messages: when getting mismatched
versions of cffi and its backend; and when calling functions
which cannot be called with libffi because an argument is a
struct that is “too complicated” (and not a struct pointer,
which always works).
Add support for some unusual compilers (non-msvc, non-gcc,
non-icc, non-clang)
Implemented the remaining cases for ffi.from_buffer. Now all
buffer/memoryview objects can be passed. The one remaining check
is against passing unicode strings in Python 2. (They support
the buffer interface, but that gives the raw bytes behind the
UTF16/UCS4 storage, which is most of the times not what you
expect. In Python 3 this has been fixed and the unicode strings
don’t support the memoryview interface any more.)
The C type _Bool or bool now converts to a Python boolean when
reading, instead of the content of the byte as an integer. The
potential incompatibility here is what occurs if the byte
contains a value different from 0 and 1. Previously, it would
just return it; with this change, CFFI raises an exception in
this case. But this case means “undefined behavior” in C; if
you really have to interface with a library relying on this,
don’t use bool in the CFFI side. Also, it is still valid to use
a byte string as initializer for a bool[], but now it must only
contain \x00 or \x01. As an aside, ffi.string() no longer works
on bool[] (but it never made much sense, as this function stops
at the first zero).
ffi.buffer is now the name of cffi’s buffer type, and ffi.buffer()
works like before but is the constructor of that type.
ffi.addressof(lib, "name") now works also in in-line mode, not
only in out-of-line mode. This is useful for taking the address
of global variables.
Issue #255: cdata objects of a primitive type (integers, floats,
char) are now compared and ordered by value. For example, <cdata
'int' 42> compares equal to 42 and <cdata 'char' b'A'> compares
equal to b'A'. Unlike C, <cdata 'int' -1> does not compare equal
to ffi.cast("unsigned int", -1): it compares smaller, because
-1 < 4294967295.
PyPy: ffi.new() and ffi.new_allocator()() did not record “memory
pressure”, causing the GC to run too infrequently if you call
ffi.new() very often and/or with large arrays. Fixed in PyPy
5.7.
Support in ffi.cdef() for numeric expressions with + or -.
Assumes that there is no overflow; it should be fixed first
before we add more general support for arbitrary arithmetic on
constants.
2017-04-05 17:54:26 +02:00
|
|
|
${PYSITELIB}/cffi/error.py
|
|
|
|
${PYSITELIB}/cffi/error.pyc
|
|
|
|
${PYSITELIB}/cffi/error.pyo
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/ffiplatform.py
|
|
|
|
${PYSITELIB}/cffi/ffiplatform.pyc
|
|
|
|
${PYSITELIB}/cffi/ffiplatform.pyo
|
2013-11-26 15:04:49 +01:00
|
|
|
${PYSITELIB}/cffi/lock.py
|
|
|
|
${PYSITELIB}/cffi/lock.pyc
|
|
|
|
${PYSITELIB}/cffi/lock.pyo
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/model.py
|
|
|
|
${PYSITELIB}/cffi/model.pyc
|
|
|
|
${PYSITELIB}/cffi/model.pyo
|
2015-05-28 09:06:32 +02:00
|
|
|
${PYSITELIB}/cffi/parse_c_type.h
|
py-cffi: updated to 1.12.1
v1.12.1
CPython 3 on Windows: we again no longer compile with Py_LIMITED_API by default because such modules still cannot be used with virtualenv. The problem is that it doesn’t work in CPython <= 3.4, and for technical reason we can’t enable this flag automatically based on the version of Python.
Like before, Issue 350 mentions a workaround if you still want the Py_LIMITED_API flag and either you are not concerned about virtualenv or you are sure your module will not be used on CPython <= 3.4: pass define_macros=[("Py_LIMITED_API", None)] to the ffibuilder.set_source() call.
v1.12
Direct support for pkg-config.
ffi.from_buffer() takes a new optional first argument that gives the array type of the result. It also takes an optional keyword argument require_writable to refuse read-only Python buffers.
ffi.new(), ffi.gc() or ffi.from_buffer() cdata objects can now be released at known times, either by using the with keyword or by calling the new ffi.release().
Windows, CPython 3.x: cffi modules are linked with python3.dll again. This makes them independant on the exact CPython version, like they are on other platforms. It requires virtualenv 16.0.0.
Accept an expression like ffi.new("int[4]", p) if p is itself another cdata int[4].
CPython 2.x: ffi.dlopen() failed with non-ascii file names on Posix
CPython: if a thread is started from C and then runs Python code (with callbacks or with the embedding solution), then previous versions of cffi would contain possible crashes and/or memory leaks. Hopefully, this has been fixed.
Support for ffi.cdef(..., pack=N) where N is a power of two. Means to emulate #pragma pack(N) on MSVC. Also, the default on Windows is now pack=8, like on MSVC. This might make a difference in corner cases, although I can’t think of one in the context of CFFI. The old way ffi.cdef(..., packed=True) remains and is equivalent to pack=1 (saying e.g. that fields like int should be aligned to 1 byte instead of 4).
2019-02-17 00:37:23 +01:00
|
|
|
${PYSITELIB}/cffi/pkgconfig.py
|
|
|
|
${PYSITELIB}/cffi/pkgconfig.pyc
|
|
|
|
${PYSITELIB}/cffi/pkgconfig.pyo
|
2015-05-28 09:06:32 +02:00
|
|
|
${PYSITELIB}/cffi/recompiler.py
|
|
|
|
${PYSITELIB}/cffi/recompiler.pyc
|
|
|
|
${PYSITELIB}/cffi/recompiler.pyo
|
|
|
|
${PYSITELIB}/cffi/setuptools_ext.py
|
|
|
|
${PYSITELIB}/cffi/setuptools_ext.pyc
|
|
|
|
${PYSITELIB}/cffi/setuptools_ext.pyo
|
2013-09-30 19:19:59 +02:00
|
|
|
${PYSITELIB}/cffi/vengine_cpy.py
|
|
|
|
${PYSITELIB}/cffi/vengine_cpy.pyc
|
|
|
|
${PYSITELIB}/cffi/vengine_cpy.pyo
|
|
|
|
${PYSITELIB}/cffi/vengine_gen.py
|
|
|
|
${PYSITELIB}/cffi/vengine_gen.pyc
|
|
|
|
${PYSITELIB}/cffi/vengine_gen.pyo
|
|
|
|
${PYSITELIB}/cffi/verifier.py
|
|
|
|
${PYSITELIB}/cffi/verifier.pyc
|
|
|
|
${PYSITELIB}/cffi/verifier.pyo
|