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, //Richard
