- the flag is really enforce_copy and should force a copy
- for a view : it is false, no change
- for a regular type : it is true, and now this will enforce the
copy in the call of numpy. numpy does it for us.
- The problematic case was when we construct a regular type
from a complicated view in python, which is an array
but is not C contiguous.
(hence the PyArray_Check was false, and the C_Contiguous flag was not set)
Now it is fine, since we ask numpy to systematically copy the data for us
and build a C contigous array.
--> the constructor from python does not support custom memory layout
because numpy only support C and Fortran
Conflicts:
triqs/arrays/impl/indexmap_storage_pair.hpp
- import arrays in extensions (mako file).
- put import_arrays in converter,
along the lines of our own objects (numpy and triqs uses
the same capsule technique, i.e. the standard technique from python
doc.)
- improve the mem_block and shared_block.
- the reference counting is now done in the mem_block and shared_block, removing the need of shared_ptr.
- speed tests shows that shared_ptr is very slow (due to thread safety?)
the new version is much better, though not perfect.
- Hence introducing weak views.
- also :
-- clean the guard mechanism for python (to allow returning from python without any python ref left).
-- clean code, add documentation for mem_block
-- remove nan init, which was not working, and corresponding test
-- serialisation of view still unchanged (need to forbid serialization of view ??).
- tests ok, incl. valgrind tests.
