At the initial GSoC proposal level, do you have to go to such low-level implementation details?

It would be better if you include a link to the respective Python documentation, so we can see exactly what you are referring to ;-).

The basic idea is that Numpy (like Python) is written in C. Numpy's main data structure (which is a C structure) is very similar to our `gal_data_t' (but much more general). So, the way I see it now is that the whole conversion function should be in C: you don't want to invent an alternative to Numpy ;-). Once the two way "Numpy <---> gal_data_t" converter is written (fully in C), we can start writing C functions that interface with Python.

But this is just my general view now, I have only read about it, probably during implementation some things will be different.

Is that task enough or should I find more ?

I am planning to write a Julia wrapper for GNUAstro. Mose has already ensured that GNUAstro compiles on all platforms Julia supports. I intend to provide a direct interface to access the C library for those who are interested and a Julia style interface as well for others.

I think a two month time span is reasonable enough to accomplish this. In the spare time, I think I can either do a Java wrapper or complete some tasks to improve GNUAstro iteslf.

makhlagi, is a java wrapper desirable ? Do you think this is a good plan ?

Yes, even the users of Gnuastro's C library don't have access to the functions declared in the headers of `lib/gnuastro-internal'.

Both contain headers. The headers in `lib/gnuastro' get installed (as art of the library and are well documented in the book!). The ones in `lib/gnyastro-internal' don't get installed: they are only for "internal" Gnuastro operations while its being built. Their documentation is only as comments in the code.

Yes ;-)! So far, I think this it the cleanest and lowest-level way: at the start of the function we have some special functions to convert framework to C (while keeping the originally allocated array: not making an extra copy), do the main job in C through any number of calls to any library, and then convert the output data structures back to Python and return them.

Python is a language that evolves/changes a lot! Numpy evolves even faster than Python!!! So if you want your work to used in a more generic/longer-term manner, it is best to minimize the exposure of your work to this changing environment and just update the conversion tools when they change.

However, as you go deeper into it (during the implementation), you may find that for some cases/situations, it may be better to make Python classes, you'll definitely figure this out as you go ahead during implementation ;-).

As you have cited, the core of the work is writing a function to convert `gal_data_t' to Numpy's data container structure.

Then functions that are called by Python can follow this scenario: call this function to convert the data container (without changing the array pointers ideally: to allocate more space), call the Gnuastro library functions in any specific order, then convert them back to Numpy's data container and return it to Numpy/Python.

I hope you find this link useful. It is a basic quick tutorial for this project and might be useful for your specific query as well;-)

Following the Libtool guidelines, the library header files were corrected to also be usable in C++. The change has been pushed to my personal (development) repository. As you see in the Libtool page, this is much more comprehensive than the suggested addition in the first comment of this task.

A small test C++ program was also added (in `tests/lib/versioncpp.cpp'). It will just do the simplest possible job of printing the version number of Gnuastro, but the important thing is that it is done within C++ which would fail with the headers before this commit.

I tried temporarily renaming the `g++' executable file to see what would happen if we don't have a C++ compiler, but apparently Autoconf is too smart for that and was able to use `gcc' for the C++ compilation. I currently don't have much experience with C++, but if it is possible to only have a C compiler (without C++), then it would be great if we could detect that at configure time and skip this (and possible future) test(s) if the user can't compile C++.

After task #13765 (Convert static libraries to shared libraries) is done, add the proper tools to allow the libraries to be used by other languages.

Most pipelines today use Python and most programmers use C++, being a very low-level tool, Gnuastro should be available to them also, not just C users. So it would be great to allow the users of these (and other languages) also use Gnuastro's libraries.

For C++ it is very streightforward, just add the lines below on the top and bottom of the header files:

Top:
#ifdef __cplusplus
extern "C"{
#endif


Bottom:
#ifdef __cplusplus
}
#endif



For other languages, SWIG seems to be an interesting solution. From what I understood of SWIG, we can even write a specific Makefile for making shared libraries for any language that it supports. So for example as options to "./configure". The user can run something like "./configure --forpython --forperl". Then the Makefile can run SWIG in the proper way and generate the shared library that can be used in that language. Finally "make install" can install those libraries besides the actual libraries and executable programs so the user can use Gnuastro in what-ever languate they like.

If we have enough interested people to help, we can even write test-suites for these libraries.