- The issue comes from the fact that the default generated
+= and co by the Python API is the one for immutable types, like int.
- Indeed, in python, for an int :
x=1
id(x)
140266967205832
x+=1
id(x)
140266967205808
- For a mutable type, like a gf, it is necessary to
add explicitly the xxx_inplace_add functions.
- Added :
- the generation of the inplace_xxx functions
- a method in class_ in the wrapper generator that
deduce all += operator from the + operators.
- this assumes that the +=, ... are defined in C++.
- The generation of such operators are optional, with option
with_inplace_operators in the arithmetic flag.
- Also, added the overload g += M and g -= M for
g : GfImfreq, M a complex matrix.
Mainly for legacy Python codes.
- When a type has no python constructor (E.g. parameters)
do not define the xxx_new function.
- Leads to a better error message when trying to construct
such an object in python.
- TODO : check there is no issue with serialization ?
- Add the possibility to give a function "on the fly"
for the precall and postcall of a python wrapped functoin.
- No change for previous code, it is a simple new feature.
- changed test accordingly. See my_module_desc.py for an example.
- For users : only change is :
H5::H5File in apps. to be replaced by triqs::h5::file, same API.
- using only the C API because :
- it is cleaner, better documented, more examples.
- it is the native hdf5 interface.
- simplify the installation e.g. on mac. Indeed, hdf5 is
usually installed without C++ interface, which is optional.
E.g. EPD et al., brew by default.
Also the infamous mpi+ hdf5_cpp bug, for which we have no clean solution.
- clean the notion of parent of a group. Not needed, better iterate function in C LT API.
- modified doc : no need for C++ bindings any more.
- modified cmake to avoid requiring CPP bindings.
- 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.)
- clean the c_name.
- add more refined signature (with c_name optionally in it).
- add some autodoc.
- clean code : move class in nested, remove useless dict call, etc...
- operator2 : move unary - and unit in algebra in general wrapper.
- various name change to make private function start with _, for
autodoc.
- Add to the wrapper generator (add_method) the release_GIL_and_enable_signal option which :
- release the GIL
- save the python signal handler
- enable the C++ triqs signal handler instead.
- undo all of this after the code runs, or in a case of exception.
- used python include, ceval.h, line 72 comments and below.
- reworked the triqs::signal_handler.
simple C like function, no object (no need).
start, stop, received, cf header file.
- clean the call_back.cpp : only place using the signal directly
(qmc uses the callback).
in particular, remove the old BOOST CHRONO, since
the std::chrono works fine on platforms we use now.
- change the constructor wrapper.
- in the new method, leave the pointer _c to NULL.
- in the init, allocate it.
- It seems ok to leave the object in this non initialized state,
but that is not so clear from the doc.
Added check for this pointer == NULL in converters.
- new parameter class :
parameters are viewed as form, built in C++, and filled in C++/python.
Each field of the form as a precise C++ type (erased using standard techniques).
First tests ok, to be reread/checked.
TODO : serialization is commented. Lead to long compilation time & large code
due to boost::serialization. Use h5 when possible.
- wrapper :
- separated the converters of the wrapped type in the TRIQS library
- necessary for parameters (it used outside an .so) and potentially
other codes, outside an .so module
