This should be replaced with Dtool_GetPyTypeObject, hiding the implementation details a bit so that we can more easily change the underlying structure if we need later
Also adds Py_NewRef to py_compat.h, backporting from master
This is more idiomatic, simplifies the code, makes it easier to port to eg. HPy later on, and makes it easier to use the limited ABI (where it can be optimized to a tail call) later on
A polyfill is provided for compatibility with Python versions 3.8 and 3.9
This vector implementation does is optimized for the case of having only a small number of elements, which are stored directly on the vector object rather than being allocated from the heap. If the capacity exceeds this small number, then a heap allocation is done.
This should improve performance in a couple of cases where vectors typically store 1 element and rarely more than that.
These hashes are used in various places in the Panda codebase (for integrity checks, not for crypto), so using an internal implementation allows retaining this functionality when building Panda without OpenSSL.
Based on the following public domain implementation:
https://github.com/B-Con/crypto-algorithms
init_memory_hook() is no longer required, eliminating static initialization order issues
This required moving the DeletedBufferChain map elsewhere, which now also has a const-initialized array for relatively small allocations.
Also, deletedChain.T has been renamed to deletedChain.I
Fixes#539
This typedefs to std::atomic<> when building with true threading, and uses a dummy implementation without.
This lets us use the full range of atomic operations offered by C++11, including explicit specification of memory fences. Using barriers lets the compiler generate more optimal code since currently we are using the quite strict sequential-consistent memory ordering for all operations. ReferenceCount has been changed to use the correct barriers (I hope). This may especially make a difference on weak ordering systems such as ARM.
Over time we should gradually replace the use of AtomicAdjust with the new patomic file.
See #1140 - I may revert this if someone can demonstrate a compelling use case (for current directory, you can use "." instead), but it seems to have the potential to cause unintuitive behavior.
rdb
kamgha
Disyer
Frang
Cary Sandvig