These are chat archives for SHTOOLS/SHTOOLS

27th
Jul 2016
Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 14:32
Ok. I thing it is enough for today. I added full Fortran compilation support in setup.py and now it is in #31. Btw, sorry for the mess in PR, but I had some inspiration during the day :smile:
I hope someone will check compilation for the different compilers, I have only gfortran, a.k.a. gnu95 in numpy.
The last thing there is docs...
MMesch
@MMesch
Jul 27 2016 14:45
Great!!
I'll test it later
Mark Wieczorek
@MarkWieczorek
Jul 27 2016 15:09
Also, here is a big PR: SHTOOLS/SHTOOLS#32
I'll merge this tomorrow, but if you have any comments beforehand, let me know.
Mark Wieczorek
@MarkWieczorek
Jul 27 2016 15:19
@MMesch Just accept #31 if you are happy with it. I haven't had the time to figure out how setup.py works yet.
Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 15:24
Can we avoid using both from . import _SHTOOLS and from ._SHTOOLS import *? Especially the last one. I think the last for loop is about to add all from _SHTOOLS to the namespace if I understood right...
Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 15:33
I mean, does the redefinition of the PlmIndex and YilmIndexVector affects anything now?
Mark Wieczorek
@MarkWieczorek
Jul 27 2016 15:37
I agree that from . import _SHTOOLS is not needed, but from ._SHTOOLS import * is needed to import everything into the pyshtools namespace (if there's a better way, let me know). The for loop and all don't really do anything. The all statement only determines what gets imported when you do a from pyshtools import *.
And the redefinition of PlmIndex: The problem is that this function exists in the fortran archive, but the indices are off by 1 for python. We just created a new python function that gets used instead of the fortran version.
MMesch
@MMesch
Jul 27 2016 15:40
from . import _SHTOOLS is needed for clarity in my opinion
Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 15:40
Yes, but it is in _SHTOOLS namespace and not in current * space, right?
MMesch
@MMesch
Jul 27 2016 15:40
In my opinion from ._SHTOOLS import * should somehow be avoided
yes. We need to import from _SHTOOLS to the __init__.py namespace
no idea how
unrelated question: do you have a logo for SHTOOLS Mark?
Mark Wieczorek
@MarkWieczorek
Jul 27 2016 15:45
And the one on the twitter feed.
They both suck though.
Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 15:45
I think, one of the possible solutions is to write import by hands
It also would be much clearer what we really import from _SHTOOLS
MMesch
@MMesch
Jul 27 2016 15:49
Agree. Alternatively, if there is a possibility to move individual functions from _SHTOOLS into the main namespace it would avoid a double import statement
but essentially it is the same
MMesch
@MMesch
Jul 27 2016 15:58
Fatal Error: Can't open module file ‘shtools.mod’ for reading at (1): No such file or directory
There is a problem with the include dirs
MMesch
@MMesch
Jul 27 2016 16:04
ok they are just not put in the right directory
MMesch
@MMesch
Jul 27 2016 16:23
@ioshchepkov the libraries and .mod files are built into the build/temp.xy folder. I have no idea how it found this automatically in your case.
Mark Wieczorek
@MarkWieczorek
Jul 27 2016 16:24
We could try importing the _SHTOOLS functions from a list using the __import__ function. Not sure if this is worth doing or not. : http://www.diveintopython.net/functional_programming/dynamic_import.html
MMesch
@MMesch
Jul 27 2016 16:30
Compilation works on my machine now without any make
adict = { 'x' : 'I am x', 'y' : ' I am y' }
locals().update(adict)
This works but the question is whether it is very clean
globals().update(adict)
goes as well ...

@all can you try if

make clean
python setup.py build

works on your machine?

Ilya Oshchepkov
@ioshchepkov
Jul 27 2016 18:16
It worked for me and works now on Arch Linux and Python 3
Also pip install --user . works too