Closed QuLogic closed 6 years ago
It might be safer to use NumPy's C API instead, but I see it's commented out and I'm not sure why.
Mmm... maybe npy_int64
is a safer type than long long
.
I originally was using the Numpy API but I turned it off because I was getting seg-faults from the coords
passed into VectorSet
being freed after calculation, even though it's managed by Python's garbage collection. We can go back to passing objects as 'O'.
I think the constraint there is the types that are accepted by PyArg_ParseTuple
; I don't think npy_int64
is available there.
Alright, thanks for finding the bug. I'll merge this and go revert back to using the Numpy API.
If you revert back to the NumPy API, you wouldn't need the long long
, would you?
Because all files are now builtin to FastNoiseSIMD, this should now compile. However, the tests were still broken due to some trickery with pointers.
A
long long
is bigger than a pointer on 32-bit systems, and thus the values after it inPyArg_ParseTuple
are filled with zeros (since the values are little-endian.)