#471 compiling python bindings on macos BigSur

[Stefan Oslowski]

I'm having trouble compiling the python bindings on macos 11.6.8 bigsur, with gcc/gfortran 10.2, python 3.9.4, and swig 4.1.0.

Compilation fails with:

In file included from ../../local_include/Pulsar/Integration.h:21,
                 from ../../local_include/Pulsar/IntegrationExpert.h:14,
                 from psrchive_wrap.cxx:3242:
../../Util/epsic/src/util/Jones.h:30:50: error: no matching function for call to 'std::complex<double>::complex(const SwigValueWrapper<Jones<double> >&)'

I attach a more complete output.

Any tips appreciated!

[Stefan Oslowski]

Downgrading to SWIG 3.012 resolved the issue. I'm leaving this open as probably worth fixing compatibility with SWIG 4?

[Paul Demorest]

I ran into this also while trying to update the conda-forge package (swig 4.1.1, gcc 11.3.0). This was on linux so it's not MacOS-specific, more likely due to swig version as Stefan found. I spent some time looking into it, the problem is swig's scheme for wrapping generic objects is failing on Jones and the complicated constructor rules in Jones.h. In particular, C++ is insisting on trying to use this constructor to cast the wrapped-Jones back to real-Jones:

  //! Construct from a castable type
  template<typename U> explicit Jones (const U& scalar)
    : j00(scalar), j01(0.0), j10(0.0), j11(scalar) { }

which totally fails. I'm not sure how to tell it to do the right thing.

A couple possible solutions:

1. Just ignore (ie do not wrap) any functions that return a Jones instance. In my testing so far it looked like the only relevant ones are: FrontendCorrection::get_transformation, FrontendCorrection::get_basis, FrontendCorrection::get_projection.
2. Write a typemap for Jones to/from numpy arrays (or some similar thing) so these functions can be used in python.

I'd prefer #1 (due to laziness), does anyone really need these functions in python?

[Paul Demorest]

PS @sixbynine was the one who added FrontendCorrection to the python interface, maybe he could comment?

[Mike Keith]

So the FrontendCorrection is important if anyone wants to calibrate data using the python interface. We use it in the meertime singlepulse pipeline, but really I think it is widely needed. However, I think the most important thing is to be able to call the calibrate(Archive) method, as this is what actually applies the calibration.

The python interface is a bit of a mess as it is developed piecemeal, so for sure I have no objection to just removing functions that return a Jones object. Probably someone will want it one day, but the same goes for the hundreds of other functions not wrapped for similar reasons.

At some point I think it would be worth a major overhaul of the python interface to clean up exactly what is and is not wrapped etc, but doesn't have to start today.

[Paul Demorest]

OK, thanks, I will go ahead and make that change in order to get it building again.

More generally, the python interface started out as a way to get the basic data-container classes (Archive, Integration, Profile) available in python. That was a pretty well-defined scope, and it was not intended to cover all possible psrchive functionality. Of course since then many people (including me!) have added other stuff in as needed. Definitely worth considering if there is a better approach, it's been a few years since I looked into it. The problem always seems to be the large amount of time needed to deal with all the weird special cases / workarounds (this bug for example).