ctools

The base classes indeed have changed in the meantime. Have you committed all code? If yes I can checkout your branch, fix it, and push it into the 1520-dm-profiles branch of gammalib.

Yes, my nkelhos/gammalib/1520-dm-profiles has all my code comitted. That’d be a great help, thanks.

I was trying to compile a merged nkelhos/gammalib/1520-dm-profiles , but I ran into problems. To try and trace them I tried to compile gammalib/gammalib/1520-dm-profiles, but I get an error:

$ ./autogen.sh && ./configure --prefix=$PWD && make clean && make -j 1 && make install
...
...
building '_model' extension
/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/nkelhos/Software/miniconda3/include -arch x86_64 -I../include -I/opt/local/include -I../inst/mwl/include -I../inst/cta/include -I../inst/lat/include -I../inst/com/include -I/Users/nkelhos/Software/miniconda3/include/python3.5m -c gammalib/model_wrap.cpp -o build/temp.macosx-10.6-x86_64-3.5/gammalib/model_wrap.o
gammalib/model_wrap.cpp:3907:43: error: no member named 'eval_gradients' in 'GModelSpatialRadial'
        return self->GModelSpatialRadial::eval_gradients(photon);
               ~~~~                       ^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
make[3]: *** [build] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

My setup:

$ git remote -v
origin    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (fetch)
origin    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (push)

$ git branch -vv
* 1520-dm-profiles 58af4ad [origin/1520-dm-profiles] Adapt DM radial profile code to new spatial model interface
  devel            c48c64a [origin/devel] Bugfix.

$ git pull
Already up-to-date.

You have probably still the old Python interface.

Try to type make clean, and then ./configure and then make clean again, and then try to recompile.

I changed some time ago the logic for the Python interface to avoid that a user will delete the SWIG wrappers. Now, when you type ./configure with the SWIG wrappers existing, they will never be deleted, even if the interface changes. There is an interface change with the new code, but since the old wrappers are never deleted, you have a conflict. I need to change this behavior for developers ...

I tried this with gammalib/gammalib/1520-dm-profiles where make clean + configure + make clean + make worked. But when I try it with my fork (nkelhos/gammalib/devel), it doesn’t work, and I still get the same error.

/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/nkelhos/Software/miniconda3/include -arch x86_64 -I../include -I/opt/local/include -I../inst/mwl/include -I../inst/cta/include -I../inst/lat/include -I../inst/com/include -I/Users/nkelhos/Software/miniconda3/include/python3.5m -c gammalib/linalg_wrap.cpp -o build/temp.macosx-10.6-x86_64-3.5/gammalib/linalg_wrap.o
gammalib/linalg_wrap.cpp:3697:12: warning: unused function 'var_tuple_to_index' [-Wunused-function]
static int var_tuple_to_index(PyObject *input, int *ptr, int dim) {
           ^
1 warning generated.
/usr/bin/clang++ -bundle -undefined dynamic_lookup -L/Users/nkelhos/Software/miniconda3/lib -arch x86_64 build/temp.macosx-10.6-x86_64-3.5/gammalib/linalg_wrap.o -L../src/.libs -L/opt/local/lib -L/Users/nkelhos/Software/miniconda3/lib -L../src/.libs -L/opt/local/lib -lgamma -lcfitsio -ledit -lcurses -o build/lib.macosx-10.6-x86_64-3.5/gammalib/_linalg.cpython-35m-darwin.so -headerpad_max_install_names
building '_model' extension
/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/nkelhos/Software/miniconda3/include -arch x86_64 -I../include -I/opt/local/include -I../inst/mwl/include -I../inst/cta/include -I../inst/lat/include -I../inst/com/include -I/Users/nkelhos/Software/miniconda3/include/python3.5m -c gammalib/model_wrap.cpp -o build/temp.macosx-10.6-x86_64-3.5/gammalib/model_wrap.o
gammalib/model_wrap.cpp:3907:43: error: no member named 'eval_gradients' in 'GModelSpatialRadial'
        return self->GModelSpatialRadial::eval_gradients(photon);
               ~~~~                       ^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1
make[3]: *** [build] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

But the merge command seems to think everything is up to date.

$ git branch -vv
* devel a8c7750 [origin/devel] merged NEWS for some conflic

$ git remote -v
origin    https://cta-gitlab.irap.omp.eu/nkelhos/gammalib.git (fetch)
origin    https://cta-gitlab.irap.omp.eu/nkelhos/gammalib.git (push)
upstream    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (fetch)
upstream    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (push)

$ git merge upstream/master
Already up-to-date.

That’s because the spatial model interface changed (the eval_gradient() methods don’t exist anymore; gradient is now a boolean flag), and your code is incompatible with this change.

You have to merge the gammalib/gammalib/1520-dm-profiles branch into your branch to make the changes also available on your side.

I think I’ve missed something, because when I do that merge, it says its up-to-date.

$ git branch -vv
* devel a8c7750 [origin/devel] merged NEWS for some conflic
$ git remote -v
origin    https://cta-gitlab.irap.omp.eu/nkelhos/gammalib.git (fetch)
origin    https://cta-gitlab.irap.omp.eu/nkelhos/gammalib.git (push)
upstream    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (fetch)
upstream    https://cta-gitlab.irap.omp.eu/gammalib/gammalib.git (push)
$ git pull
Already up-to-date.
$ git merge remotes/upstream/1520-dm-profiles origin/master
Already up-to-date.

Is that the right way to merge it?

When I did the merge into gammalib I used the actual committed branch in your repo to start with, so in principle you do not have to do any merge on your side. Maybe rename your old 1520-dm-profiles branch and checkout the 1520-dm-profiles from gammalib/gammalib and the push this branch into your fork.

Ok, I think I did all of that, but I still get the same error.

• I renamed nkelhos/gammalib/1520-dm-profiles to 1520-dm-profiles-old
• deleted the existing 1520-dm-profiles (locally and with $ git push origin --delete 1520-dm-profiles)
• checked out remotes/upstream/1520-dm-profiles (though this was only in HEAD mode)
• checked it out as a local branch ($ git checkout -b 1520-dm-profiles)
• pushed this new branch to nkelhos/gammalib
• deleted the entire gammalib directory to start fresh
• cloned nkelhos/gammalib
• checked out origin/1520-dm-profiles

And when I tried autogen.sh + configure + make clean + configure + make clean + make, I still get the same error.

I started over with a fresh fork of gammalib/gammalib, and when I checkout 1520-dm-profiles and compiled it, I still got the same problem, even with make clean, configure, and make clean again.

building '_model' extension
/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/nkelhos/Software/miniconda3/include -arch x86_64 -I../include -I/opt/local/include -I../inst/mwl/include -I../inst/cta/include -I../inst/lat/include -I../inst/com/include -I/Users/nkelhos/Software/miniconda3/include/python3.5m -c gammalib/model_wrap.cpp -o build/temp.macosx-10.6-x86_64-3.5/gammalib/model_wrap.o
gammalib/model_wrap.cpp:3907:43: error: no member named 'eval_gradients' in 'GModelSpatialRadial'
        return self->GModelSpatialRadial::eval_gradients(photon);
               ~~~~                       ^
1 error generated.
error: command '/usr/bin/clang' failed with exit status 1

I can get it to go away if I comment out the eval_gradients extension in $GAMMALIB/pyext/GModelSpatialRadialProfile.i , because (from what I understand) eval_gradients() is being phased out and replaced by eval().

$GAMMALIB/pyext/GModelSpatialRadialProfile.i :

%extend GModelSpatialRadialProfile {
    double eval(const GPhoton& photon) const {
        return self->GModelSpatialRadial::eval(photon);
    }
    /*
    double eval_gradients(const GPhoton& photon) const {
        return self->GModelSpatialRadial::eval_gradients(photon);
    }
    */
};

I am not sure if this has other impacts, but I’m going to use it for now in my own branch of my new fork.

Sorry for that. Yes, this code should be removed. I somehow did not recognise that when I pushed the modifications.

In fact, the code should be changed as follows:

    double eval(const GPhoton& photon, const bool& gradients) const {
        return self->GModelSpatialRadial::eval(photon, gradients);
    }