Next | Query returned 63 messages, browsing 21 to 30 | Previous

History of commit frequency

CVS Commit History:


   2019-11-06 18:24:50 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.13.2

v1.13.2
* re-release because the Linux wheels came with an attached version of libffi
  that was very old and buggy
   2019-10-25 12:21:35 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.13.1

v1.13.1
* deprecate the way to declare in cdef() a global variable with only void *foo;. \ 
You should always use a storage class, like extern void *foo; or maybe static \ 
void *foo;. These are all equivalent for the purposes of cdef(), but the reason \ 
for deprecating the bare version is that (as far as I know) it would always be \ 
mistake in a real C header.
* fix the regression RuntimeError: found a situation in which we try to build a \ 
type recursively.
* fixed issue 427 where a multithreading mistake in the embedding logic \ 
initialization code would cause deadlocks on CPython 3.7.
   2019-10-16 10:12:08 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.13.0

v1.13
* ffi.from_buffer("type *", ..) is now supported, in addition to
  "type[]".  You can then write p.field to access the items, instead
  of only p[0].field.  Be careful that no bounds checking is performed, so
  p[n] might access data out of bounds.
* fix for structs containing unnamed bitfields like int : 1;.
* when calling cdata of "function pointer" type, give a RuntimeError \ 
instead
  of a crash if the pointer happens to be NULL
* support some more binary operations between constants in enum definitions
* silence a warning incorrectly emitted if you use a quote in a preprocessor
  line
* detect a corner case that would throw the C code into an infinite
  recursion, with ffi.cdef("""struct X { void(*fnptr)(struct X); \ 
};""")
   2019-04-26 19:06:21 by Leonardo Taccari | Files touched by this commit (1)
Log message:
py-cffi: Remove no longer needed NetBSD/evbarm aarch64 kludge

__thread works now (8.99.37 but probably also older).
   2019-04-26 17:14:31 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.12.3

v1.12.3
* Fix for nested struct types that end in a var-sized array.
* Add support for using U and L characters at the end of integer
  constants in ffi.cdef().
* More 3.8 fixes.
   2019-02-28 09:51:00 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.12.2

v1.12.2
* Added temporary workaround to compile on CPython 3.8.0a2.
   2019-02-17 00:37:23 by Adam Ciarcinski | Files touched by this commit (3) | Package updated
Log message:
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).
   2018-07-29 12:48:14 by Leonardo Taccari | Files touched by this commit (1)
Log message:
py-cffi: Add a kludge to disable __thread on NetBSD aarch64

__thread ATM is problematic on NetBSD aarch64 and py-cffi users (e.g.
py-requests) ends up crashing due SIGILL at run time.

PKGREVISION++
   2018-03-01 08:59:54 by Adam Ciarcinski | Files touched by this commit (4) | Package updated
Log message:
py-cffi: updated to 1.11.5

v1.11.5

* Issue 357_: fix ffi.emit_python_code() which generated a buggy
  Python file if you are using a struct with an anonymous union
  field or vice-versa.

* Windows: ffi.dlopen() should now handle unicode filenames.

* ABI mode: implemented ffi.dlclose() for the in-line case (it used
  to be present only in the out-of-line case).

* Fixed a corner case for setup.py install --record=xx --root=yy
  with an out-of-line ABI module.  Also fixed Issue 345_.

* More hacks on Windows for running CFFI's own setup.py.

* Issue 358_: in embedding, to protect against (the rare case of)
  Python initialization from several threads in parallel, we have to use
  a spin-lock.  On CPython 3 it is worse because it might spin-lock for
  a long time (execution of Py_InitializeEx()).  Sadly, recent
  changes to CPython make that solution needed on CPython 2 too.

* CPython 3 on Windows: we no longer compile with Py_LIMITED_API
  by default because such modules cannot be used with virtualenv.
  Issue 350_ mentions a workaround if you still want that and are not
  concerned about virtualenv: pass a define_macros=[("Py_LIMITED_API",
  None)] to the ffibuilder.set_source() call.
   2018-01-14 12:09:17 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.11.4

v1.11.4:
* Windows: reverted linking with python3.dll, because virtualenv does not make \ 
this DLL available to virtual environments for now. On Windows only, the C \ 
extension modules created by cffi follow for now the standard naming scheme \ 
foo.cp36-win32.pyd, to make it clear that they are regular CPython modules \ 
depending on python36.dll.

Next | Query returned 63 messages, browsing 21 to 30 | Previous