[gnuastro-devel] [task #15156] Programs as library functions

[Mohammad Akhlaghi]

URL:
  <https://savannah.gnu.org/task/?15156>

                 Summary: Programs as library functions 
                 Project: GNU Astronomy Utilities
            Submitted by: makhlaghi
            Submitted on: Thu 17 Jan 2019 01:22:41 PM UTC
         Should Start On: Thu 17 Jan 2019 12:00:00 AM UTC
   Should be Finished on: Thu 17 Jan 2019 12:00:00 AM UTC
                Category: All Gnuastro
                Priority: 5 - Normal
              Item Group: None
                  Status: Postponed
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: makhlaghi
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

High-level command-line programs (as opposed to low-level libraries) are
currently the most common way that Gnuastro is used. 

When considering task #13786 (to use Gnuastro in higher-level languages like
Python, R, or Java), having a library function that can run NoiseChisel (for
example, or any other program) from memory, without having to do a system call
can be very useful.

One major hurdle in this regard until now was managing all the configuration
options necessary for some programs as a function call. 

For each program we can have a library function like: `gal_astnoisechisel'
(prefixing the program name with `gal_' (the common prefix in all gnuastro's
library functions). 

To solve the configuration problem, we can break up the program's user defined
variables (defined in the main structure of `src/*/main.h') into a separate
structure from the generic parameters structure (which currently includes
internal parameters also). 

The library users can have access to the user defined variable structure and
set the values as they like. When the library function is run, it can parse
the configuration files using the same existing functions and fill in any
value that the user hasn't defined base on them.

The rest (actual running of the program) is then trivial. 

After wards, to implement task #13786 (atleast for the programs), we just need
a wrapper for Gnuastro's `gal_data_t' data container to the respective
language container (for example Numpy's in Python).




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/task/?15156>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/