- 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.
- Cleaned of the eigensystems computations (worker is simpler, decision
at runtime, etc..).
- Fix#119 : When the matrix is in C order, the fortran lapack
sees in fact its conjugate, so we need to conjugate the eigenvectors at the end.
NB : not true if the storage order of the matrix is already fortran of course.
- 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 ?
- detect the use module.
- clean the code specific to wrapper generation from clang_parser.
- add support for default arguments for int, double, char.
- TODO : add more complex default arguments
- Pb was that indices for gf where empty when constructed
with default args from C++.
- changed into : make indices from the shape in the default
case.
- also added more, simpler construction, for the indices
to easy C++ construction.
- the wrapper will now add date and time
at the boundary between C++ and Python.
- using C lib, not C++ (lack of support of C++ chrono functions in gcc).
- hdfarchive : transform the key to string with str
because they can be unicode and C wrapper does not convert python unicode strings.
- gf : Correct the scheme for BlockGf : not very clean, to be improved ?
- Given a C++ file, e.g. a class,
it calls libclang to parse the C++, and retrieve from
its AST the necessary info to write a xxx_desc.py file.
- THIS IS WORK IN PROGRESS. There are several corner cases for which we
may want (or not) the script to do better.
- It is not designed to be used automatically, but to to 90 % of the
boring typesetting work...
- The preamble still needs manual choices
- The properties, methods, functions are automatically declared in
the _desc file, in the simplest possible way.
- An option --properties, -p : to transform some simple methods or
get_x, set_x into python properties, not methods.
Cf doc.
- requires clang (tested on 3.4).
- the script is configured by cmake and installed in
INSTALLATION_DIRECTORY/bin, with some other files.
It can only be used for applications, after the lib has been installed.
It is cmake configured, to include automatically the various include
paths configure in the triqs installation, including the triqs install dir
in order to simplify invocation.
- TODO : improve, and test more in real cases.
- C++14 mode not automatic. Was based on compiler version,
but the version of the C++ lib also matters....
Now, there is an explicit USE_CPP14 option [default =OFF]
to set to compile in c++1y mode.
Solve also #89, i.e. the flags is now in TRIQS_CXX_DEFINITIONS and
therefore pass to applications (including ipython magic).
- Python_use_mpi4py is now ON by default.
Rational : it has been used for a while by e.g. Thomas,
and it is necessary on OS X (boost.mpi.python raises a lot of issues).
Hence we put it as default.
- Rename the option Build_Triqs_General_Tools_Test to a simpler
Build_Tests
- 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.
I also added a test to make sure the time mesh is twice as
long as the frequency mesh. Obviously now some tests don't
pass... I will fix them in the next commit.
- 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.)
