stdint.h was added to use exact-width int types[1] but later these were
all moved to .c file.
[1] 89721c5d17
[2] f81a59b592
Change-Id: I06f83b818da1291669c8ab90ac7e8595f144d8a5
We probably want some format tools (like clang-format) in the future,
but for now all these spaces are deleted by sed.
Change-Id: If7e52e75772551406b27f97854cebdebf2da2abf
This allows us to build shared libraries that work across minor CPython
releases. See also: https://docs.python.org/3/c-api/stable.html
To build abi3 wheels, run something like
python setup.py bdist_wheel --py-limited-api=cp35
Change-Id: Iaa747d58c6ac9dd64c5e4d3b5fdd4e56e8e2cb5e
Previously, compiling would complain
warning: comparison of integer expressions of different signedness:
‘int’ and ‘uint32_t’
Change-Id: Ic839ab02189103975985fc0557d6846052635b14
This has been available since Python 2.5, and our old int-based approach
stopped working in Python 3.10. From https://bugs.python.org/issue36381:
Raise warning for # use without PY_SSIZE_T_CLEAN.
* 3.8: PendingDeprecationWarning
* 3.9: DeprecationWarning
* 3.10 (or 4.0): Remove PY_SSIZE_T_CLEAN and use Py_ssize_t always
Change-Id: I5394268aaf4c409a75f795a44c092fd5101178cd
This came up when running the py3 unit tests after adding a test that
(erroneously) tried to encode native strings. At some point, we should
probably enforce tighter type-checking, but I'm not sure what all types
we need (or want) to support.
Change-Id: Ibb1f4f52207be83f842740d9f3c39c2a03fb1396
Currently, there are several implementations of erasure codes that are
available within OpenStack Swift. Most, if not all, of which are based
on the Reed Solomon coding algorithm.
Phazr.IO’s Erasure Coding technology uses a patented algorithm which are
significantly more efficient and improves the speed of coding, decoding
and reconstruction. In addition, Phazr.IO Erasure Code use a non-systematic
algorithm which provides data protection at rest and in transport without
the need to use encryption.
Please contact support@phazr.io for more info on our technology.
Change-Id: I9377fa32426a190efd0a7f0675ecf13d7e90367d
Now, if liberasurecode.so exposes a liberasurecode_get_version function,
we'll use that; otherwise, we'll fall back to reporting the version that
PyECLib was built against.
Note that if your liberasurecode.so doesn't support
the liberasurecode_get_verion function, pyeclib will the version at built
as well as older behavior.
Co-Authored-By: Tim Burke <tim.burke@gmail.com>
Change-Id: I54823183cce6775a83e913baf6bb1eeb94aabc13
Since we allocate the result buffer in hex_encode_string, we're
responsible for freeing it later.
Why didn't we catch it before? Turns out, our tests didn't
loop enough. I wasn't reliably seeing a test failure at 200k
iterations, but 400k seems to be enough?
Closes-Bug: #1634006
Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Related-Change: I678e10008c3c5bc04640f7f19498334d94cb0cd6
Change-Id: I0f6e922ba25ad56142f3d095896b9856a436a81c
This is for supporting ISA-L cauchy based matrix. The difference
from isa_l_rs_vand is only the matrix to use the encode/decode
calculation.
As a known issue, isa_l_rs_vand backend has constraint for the
combinations of the available fragment to be able to
decode/reconstuct. (See related change in detail)
To avoid the constraint, this patch adds another isa-l backend to use
cauchy matrix. The reason I try to add this intead of changing at
sa_l_rs_vand, the isa_l_rs_vand backend may be already used and if we
change the matrix, the current users won't be able to decode the data.
To avoid the problem and keep the backward compatibility, this is in
another isa_l_rs_cauchy namespace.
NOTE: this depends on tag may be meaningless because the depending target
is a c lang project so probably no scripts to install it we have and then,
almost of the tests for isa-l will be skipped due to a lack of isa-l
backend installation.
Related-Change: Icee788a0931fe692fe0de31fabc4ba450e338a87
Depends-On: I6eb150d9d0c3febf233570fa7729f9f72df2e9be
Change-Id: I3a5516545d17ab7ac67a9a3627c85243e2110764
PyDict_SetItems doesn't steal the reference count so that the reference
count of each item in the dict should be decremented via Py_DECREF
*before* returning the dict to Python VM. Otherwise, those items can be
leaked which can never be collected as garbage.
The evicence for memory leak is avaialble for using debug mode python VM like:
https://gist.github.com/bloodeagle40234/f4c0cd267e085cc6224ffdc1b1822631
Plus, this patch add one unit test to check the memory increasement for
many call of get_segment_info.
Closes-Bug: #1604335
Change-Id: I6780efb9718017d296606f3c7e60684910584a1a
Once we have liberasurecode older than depend-on patch, it could make
an invalid mem access if the backend descripter is not available.
(I'm not sure this situation happen in fact, but any other functions in
liberasurecode expecting that failure actually, FWIW)
To recover this failure, this patch fixes to catch the return value from
liberasurecode and if it's an error code, set an error for the return
value to python.
Depends-On: I489f8b5d049610863b5e0b477b6ff70ead245b55
Change-Id: I47d4ec4fa1647c5a4c8d50f0aa6a2df86ca68c80
Plus, we need liberasurecode version handling for a few place because
some tests/engine itself is broken with a lack of backword
compatibility.
Closes-Bug: #1586220
Change-Id: I72adaefa10875a73e3e5304eb40fe5d9f6d2598a
Currently both liberasurecode and PyECLib have fragment size
calculation by dividing alignment data length. However it might cause
size mismatch because of backend specific metadata added to each
fragment. To prevent such a mismatch, we should use
liberasurecode_get_fragment_size which allows to retrieve fragment_size
from liberasurecode directly instead of calculation itself.
pyeclib needs to be installed in order to run unit tests
which shouldn't be the case. We should rely on in-source
modules.
This addresses issue#56.
Signed-off-by: Tushar Gohad <tushar.gohad@intel.com>