Hi Arts developers,

There was a significant update to the Arts development version merged today.

Please test this where you find it useful.  Note that the new version uses
quite a bit more memory to compile as described in the README.  Check your
system before you use all your cores (you might need to build the
pyarts_cpp target with fewer cores)

If you encounter any problem, let me know immediately.  There are some
known problems to date:

1)  Sometimes GCC pyarts is not interactive in an ipython environment.
This happens on my Mac X86 system.  We have tested it on other Mac X86
systems where everything works just fine.  It works fine also on my system
inside a pure python environment.
2)  Our reliance on GCC 8 is now set to the latest point-iteration of GCC
8.  This is how we have been testing if GCC 8 works online.  There is a bug
in some earlier GCC 8 point release that has since been fixed.  This means
old compilers might have problems building the new python environment.
3)  Assigning a value of an unsupported type to an Arts variable causes
segmentation faults sometimes when Arts is built in debug mode.  It
produces a runtime error in Release mode.  This seems to happen very deep
in the 3rdparty library that does the python bindings.

The solution to the first is not implemented as the error is
non-reproducible.  Oliver made the second problem less problematic by
allowing to build Arts from a pure "forge" environment.  If anyone else
finds themselves in trouble because of one, let us know.  The temporary
solution is to just switch to clang.  We are still investigating (3).

There are some major changes in the operational parts of pyarts:

1)  All classes returned from calling workspace.workspace_variable.value
now return C++ class wrappers.  Before, some of these values were pure
python types.  Especially for the matpack types, this might mean you need
one additional ".value" call to return a numpy array.
2)  These C++ classes are almost always wrapping the actual Arts type quite
directly.  There are two exceptions: Numeric and Index are returned as
wrapped Numeric and Index.  We need this to allow passing them as
references to functions that might change them (python does not allow
passing references of its "int" and "float" types).
3)  Several classes have been reduced in operations to only support the
most basic of operations.  A key difference is that not all classes have
equality comparisons.  The equality comparison instead refers to the python
default, which is basically like a pointer comparison.
4)  The arts_agenda decorator returns two different types: Agenda and
DelayedAgenda.  The former is a proper wrap of the Arts Agenda class.  The
latter is parsed to an Agenda when it is assigned to a workspace variable
somehow.  This might cause some memory leak if you are assigning
DelayedAgenda:s in deeper code.  We did not want the old method of Agenda
definitions because there is a mid-term goal to make it possible to run
several Workspace independently.

We have tried making the matpack types inherit the full behavior of numpy.
This has always worked on all of the machines we own, but it created
problems in the github CI.  We need the CI to work, so when we figure this
out in the future, we will make the matpack types behave as numpy types
again.  There might be some errors in the math of Numeric and Index because
we need this wrapper.  All the operations have to be defined and not
defered to the built-in types...

If there is a feature missing please tell me about it and I will help you
add it.  It is very easy to use the python bindings library once you are
used to it, but it might appear weird if you are not used to the constructs.

As with any major update, some things might break.  We tested this
extensively so hopefully these are small and easy to work around.  Let me
know if you run into any such breaks.

With hope,

Reply via email to